26/03/2010 1 Gestion de l’alimentation dans les systèmes multiprocesseurs sur silicium Contact : Raphaël DAVID Plan • Introduction aux architecture multicœurs • Gestion de la consommation dans les architectures multicoeurs • Architectures multicœurs sur puce • Cas de l’architecture SCMP • Les nouveaux Challenges 2 26/03/2010 2 LIST – DTSI – Evolution des besoins applicatifs dans les systèmes embarqués 1 GOPS 0.1 10 100 1 TOPS HD Audio Multimedia OpenGL1.1 OpenGL 2.0 H264 Digital TV Mobile multimedia MPEG2 3D Graphics Vision application Lane detection High-performance Video restauration Face recognition Moving picture recognition Pedestrian detection Missile Seeker Airborne Radar UAV Signals intelligence Spectrale band Replication (SBR) Military application UMTS (3G) EDGE (2.5G+) GPRS (2.5G) GSM (2G) wimax OFDM (3GPP-LTE) Software Defined Radio (SDR) Telecom DVB-S2 Observation • Le parallélisme d’instructions atteint ses limites Difficulté de l’extraction logicielle Complexité de l’exploitation matérielle • Une rupture est nécessaire Evolution de la performance des processeurs 32 bits Watts/cm 2 1 10 100 1000 1.5μ 1.5μ 1.5μ 1.5μ 1μ 1μ 1μ 1μ 0.7μ 0.7μ 0.7μ 0.7μ 0.5μ 0.5μ 0.5μ 0.5μ 0.35μ 0.35μ 0.35μ 0.35μ 0.25μ 0.25μ 0.25μ 0.25μ 0.18μ 0.18μ 0.18μ 0.18μ 0.13μ 0.13μ 0.13μ 0.13μ 0.1μ 0.1μ 0.1μ 0.1μ 0.07μ 0.07μ 0.07μ 0.07μ i386 i386 i486 i486 Pentium® Pentium® Pentium® Pro Pentium® Pro Pentium® II Pentium® II Pentium® III Pentium® III Hot plate Hot plate Nuclear Reactor Nuclear Reactor Pentium® 4 Pentium® 4 Evolution de la densité de puissance des processeurs 32 bits d’Intel Rocket Nozzle
21
Embed
Telecom Multimedia Vision application - ecofac2010.irisa.frecofac2010.irisa.fr/cours-david.pdf · ... (3G) EDGE (2.5G+) GPRS (2.5G) GSM (2G) wimax OFDM ... tâches sur les PEs et
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
26/03/2010
1
Gestion de l’alimentation dans les systèmes multiprocesseurs sur silicium
Contact : Raphaël DAVID
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
• Les nouveaux Challenges
2
26/03/2010
2
LIST –DTSI –
Evolution des besoins applicatifs dans les systèmes embarqués
1 GOPS0.1 10 100 1 TOPS
HD AudioMultimedia
OpenGL1.1OpenGL 2.0
H264 Digital TVMobile multimedia MPEG2 3D Graphics
Vision applicationLane detection High-performance
Video restaurationFace recognition
Moving picturerecognition
Pedestrian detection
Missile SeekerAirborne Radar
UAV
Signals intelligence
Spectrale band Replication (SBR)Military application
UMTS (3G)EDGE (2.5G+)
GPRS (2.5G)
GSM (2G)
wimaxOFDM (3GPP-LTE)
Software Defined Radio (SDR)Telecom
DVB-S2
Observation
• Le parallélisme d’instructions atteint ses limites
� Difficulté de l’extraction logicielle
� Complexité de l’exploitation matérielle
• Une rupture est nécessaire
Evolution de la performance des processeurs 32 bits
� Bus encoding � lots of intentions but few results
Technological optimizations
• Interconnexions length
• Path balancing
• Transistor sizing, pass transistors using
• Multiples Vt, VDD
• SoI
� Reduce parsitic capacitance
� Increase density
• Clock management
� Optique
� GALS
� Asynchronism
26/03/2010
9
Objectifs du cours
• Les méthodes d’optimisation aux niveaux technologique et logique sont indépendantes de l’architecture
• En terme d’architecture multi-coeurs, la conception de solution faible consommation est un problème secondaire aujourd’hui
� Les architectures multi-coeurs sont aujourd’hui peu matures et les industriels se focalisent sur l’objectif de faire fonctionner de manière cohérente de mutliples ressources de calcul
• L’objectif du cours est
� de dresser un bilan des architectures multicoeurs pour l’embarqué et en particulier les systèmes de vision
� De parcourir les solutions de gestion de la consommation au niveau système
• Gestion de la consommation dans les architectures multicoeurs
� Modes de veille et DVFS
� Gestion hors ligne
� Gestion en ligne
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
• Les nouveaux Challenges
18
26/03/2010
10
La consommation dans les systèmes numériques
• Paramètres technologiques
� Ktech, St, C
• Paramètres architecturaux
� Kdesign, N
• Paramètres dépendants de l’application
� α, Fclk, VDD, VT
• Il devient technologiquement possible d’ajuster les paramètres dépendants de l’application au cours de l’exécution
� DFS : Dynamic Frequency Scaling� Up to Clock gating
� DVS : Dynamic Voltage Scaling� Up to power gating
2DDclkDyn .Vα.C.FP = DD
S
V
techdesstat .V.10.kN.kP t
T−
=
Optimisation de la consommation au niveau tâche
TTii
ai : arrival time
s i : WCET
d i : deadline
s i
d i
ai
TTii
Temps
Puissance
Choix du mode basse conso. Idéal ���� TIDLE
Choix du Facteur de ralentissement Idéal ���� TIDLE
TTii
s i
d i
ai
Temps
Puissance
IDLE
TTii
d i
ai
Temps
Puissance
IDLEPSMi
Speed upSlow downSleep Wake up
DPMDPM DVSDVS
26/03/2010
11
Optimisation de la consommation au niveau tâche
• Décider du meilleur Etat basse consommation :• Choisir l’état S qui minimise l’énergie totale consommée en
tenant compte de:� L’énergie de transition: ETR� L’énergie consommée dans l’état S: ES
• Le µP peut être modélisé sous forme d’une machine d’états qui représente les transitions entre ses états basse consommation: PSM (Power State Machine).� Paramètres d’un état basse consommation:
� PS = Puissance consommée dans cet état.� ETR = Energie consommée dans la transition � TTR =Temps passé dans la transition� TBE = Break-Event Time: Temps minimum à passer à l’état S pour que la transition soit intéressante.
PSM du StrongARM SA1100
TTii
s i
d i
ai
Temps
Puissance
S
Sleep Wake up
Modes faible consommation des processeurs
Lower Envelop Algorithm (LEA) [Irani03]
- b1 = TBE(State1)
- b2 = TBE(State2)
- b3 = TBE(State3)
26/03/2010
12
TTii
d i
ai
Temps
Puissance
Speed upSlow down
IDLE
Optimisation de la consommation au niveau tâche
)( ii
i
ad
sFRi
−=
• Pour un µP à plusieurs couples tension fréquence � Intel XScale PXA27x:
Gestion des modes de veilles des processeurs de calcul
• Le problème de la gestion de la consommation des processeurs est de déterminer pour une profil d’exécution donnée le mode faible consommation le plus efficace du point de vue de l’énergie� Gestion hors ligne si les profils sont déterminés hors-ligne� Gestion dynamique si ces profils sont déterminés (de manière sûre ou non) lors de
l’exécution • Une gestion de consommation optimale ne peut être espérée sans une
connaissance complète de la trace réelle d’exécution� Deux grandes approches
� Statique : vision complète du flot d’exécution de l’application� En-ligne : vision des caractéristiques locales des tâches (temps d’exécutions réels ≠ WCET)
ERun
DeadlinePower
Time
E=Erun+EidlenEIdlen
ET1
Deadlinesleep
wakePower
TimeE=ET1+EToSleep+PSleepxTSleep+EWake
Erun_low
Deadline
Slow down Speed up
TimeEIdlel
E=ESlowdown +Erun_low +EIdle_low +ESpeedup
Power
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
� Modes de veille et DVFS
� Gestion hors ligne
� Gestion en ligne
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
• Les nouveaux Challenges
26
26/03/2010
14
Gestion hors ligne de l’alimentation des processeurs
• Sur la base d’un ordonnancement donné (statique, EDF, RM, ...), il existe deux grandes stratégies pour exploiter les périodes d’inactivités des ressources de calcul
� Calcul d’un ralentissement global à l’application
� Calcul de ralentissements locaux aux tâches
1
2
4
6
8
5
3
7
9
1PE1
PE2
2
3 7
4 5
6
8 9
deadline
t0 t1
t3
Périodes d’inactivités
Ralentissement global
• Déterminer un facteur de ralentissement global à l’application pour un ordonnancement donné
� Evaluation, en fonction du FR du mode de fonctionnement à appliquer aux processeurs juste suffisant au respect de la contrainte temps réel� Simple à appliquer� Temps et coût des changements de modes peu influents sur l’efficacité
de la méthode� Gains limités
� Sur chaque Chemin critique, un FR différent peut être déterminé et des stratégies d’alimentation différentes être appliquées
Deadline
WCETFR i
TiCC∑=
1
2
4
6
8
5
3
7
9
PE1
PE23 7 6
1 2 4 5 8 9
deadline
1 2
3 7
4 5
6
8 9
26/03/2010
15
Ralentissements locaux
• Déterminer des facteurs de ralentissement pour chaque tâche� Permet d’appliquer des FR différents pour chaque tâche en fonction
de leur contribution aux chemins critiques de l’application
� Gain plus élevé� Analyse plus complexe� Pertinence de la méthode très dépendante des vitesses et des coûts
de changement de mode
∑
∑
+=
=
−=
=
−=
max
1
1
)(
niTi
n
iTi
Ti
Ti
WCETDeadlineALAP
WCETASAP
ASAPALAP
WCETFRi
PE1
PE2
1 2
3 7
4
5
6 8 9
deadline
1
2
4
6
8
5
3
7
9
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
� Modes de veille et DVFS
� Gestion hors ligne
� Gestion en ligne� Pour le DPM
� Pour le DVFS
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
• Les nouveaux Challenges
30
26/03/2010
16
gestion dynamique de la consommation
• La gestion dynamique de la consommation vise à exploiter les périodes d’inactivité constatées lors de l’exécution
� La difficulté consiste lors d’une période d’inactivité à prédire le mode faible consommation le plus efficace
� Le mode le plus pertinent du point de vue de la consommation est donné par la LPE (Lower Power Enveloppe)
� La difficulté est donc de prédire le temps d’inactivité
Lower Power Enveloppe Lower Power Enveloppe Lower Power Enveloppe Lower Power Enveloppe [Gupta][Gupta][Gupta][Gupta]
gestion dynamique de la consommation
• La gestion dynamique de la consommation vise à exploiter les périodes d’inactivité réelles lors de l’exécution
� La difficulté consiste lors d’une période d’inactivité à prédire le mode faible consommation le plus efficace
� Le mode le plus pertinent du point de vue de la consommation est donné par la LPE (Lower Power Enveloppe)
� La difficulté est donc de prédire le temps d’inactivité
• Il existe trois catégories de méthodes de gestion de l’alimentation
� Prédiction statique
� Prédiction dynamique
� Adaptation
26/03/2010
17
Prédiction statique
• La solution statique consiste à provoquer le passage dans un mode faible consommation suite au dépassement d’une durée d’inactivité fixe� Simple à mettre en œuvre
� Logique de contrôle peut être déportée au niveau de chaque processeur� La prédiction est réussie si la pénalité temporelle est suffisamment faible vis-
à-vis du temps d’inactivité et si le coût d’adaptation des fréquence et tension d’alimentation est amortie lors de la phase de repos
� Détermination du seuil complexe� Si trop bas � pénalités temporelles et/ou énergétique due à l’ adaptation des
fréquences et tensions d’alimentation� Si trop haut � Sous efficacité de la méthode
� Pour limiter la pénalité temporelle, il est également possible de prédire une date de réveil
alimentation et adaptation de la fréquence
repos
oisif t
nopT1 T2 T1 T2 T1 T2
D1
t0 tt0
D1énergie (J) énergie (J)
tt0
énergie (J) D1
oisif oisif
PDynamique PStatique
a) b) c)
mise au repos et adaptation de la fréquence
Prédiction dynamique
• Prédiction de la durée d’inactivité en fonction du passé
� Une prédiction pertinente peut être complexe à implémenter � La détermination de la fonction de régression Φ est complexe et très dépendant du contexte
applicatif
� Analogie avec les mécanismes de prédiction de branchement des processeurs programmables
� Le nombre de branchements possibles est cependant cette fois potentiellement >> à 2 (tout dépendant de la précision souhaitée pour l’estimation du temps)
• La prédiction peut également prendre en compte les dernières périodes d’activités
� Si la dernière période d’activité est courte, on suppose que la période d’inactivité sera longue et l’on passe immédiatement dans un mode d’endormissement
),,...,( 1 mnidle
nidle
nidlepred TTTT −−= φ
26/03/2010
18
Techniques adaptatives 1/2
• Basées sur une prédiction statique de l’endormissement
� Endormissement si Tidle > TTh• Adaptation de la valeur du timeout TTh en fonction des mauvaises
prédictions passées
� Une mauvaise prédiction peut être due à un TTh trop élevé (gain en consommation sous-optimal) ou trop faible (pénalité temporelle)
� Analogie une fois encore possible avec les techniques de prédiction de branchement des processeurs programmable avec des modèles à 2 voire 3 bits
� On augmente la confiance dans la prédiction à mesure que l’on accumule les bonnes prédictions
� On abaisse cette confiance à chaque mauvaise prédiction
111 )1( −−
− −+= nth
nidlen
nth TTT αα
Techniques adaptatives 2/2
• Apprendre la distribution à partir de l’historique des TInactivité
� Estimer le prochain TInactivité:� Dernier TInactivité
� Moyenne exponentielle des précédents TInactivité [Hwan96]
� Sliding window [Chung02] : fenêtre glissante des derniers Tinactiv
� Learning Trees [Chung99] ~= prédiction de branchement…
� Intéressantes pour desapplications qui ont une charge àprofil stationnaire (ex. HD:Comportement déterministe, accèsbasés sur des sessions de hauteactivité séparées par de longsintervalles de repos)
� Un nombre relativement important de mise en mode repos erronés.
� Une prédiction pertinente peut être complexe à implémenter
����
����
26/03/2010
19
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
� Modes de veille et DVFS
� Gestion hors ligne
� Gestion en ligne� Pour le DPM
� Pour le DVFS
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
• Les nouveaux Challenges
37
Ordonnancement par partitionnement
(Assignation à un unique processeur de façon permanente)
|Ramène le problème au cas monoprocesseur
Ordonnancement Global
(l’ordonnanceur sélectionne les tâches à partir d’une un ique file de tâches prêtes à s’exécuter avec/sans possibilité de
migration d’un processeur à l’autre)
Gestion en ligne du DFVS
• Principe :
� Exploiter les excédents de temps « slacks » générés par une tâche pour réduire dynamiquement le voltage/fréquence des tâches suivantes
� se baser sur des algorithmes d’ordonnancement de tâches qui ont un effet non négligeable sur leurs performances
� Avec contrôle CDFG [Xie01, Shi03, Wu03, Mal07, Ven06],
� Architectures homogènes� µP à Vitesses indépendamment ajustables [Che04, Yan05a]
� µP à Vitesses égales [Che05a],
� Architectures hétérogènes [Luo02, Ven06]
� µP idéaux (spectre de vitesse de fonctionnement est continu entre la vitesse minimale et la vitesse maximale) [Che06b],
� µP non-idéaux (spectre discret) [Zhu03, Ven06]
� Prise en compte du comportement de décharge de la batterie [Luo01, Chow05, Chow02],
Les techniques DVFS – Ordonnancement global (1/4)
• Global Scheduling with Greedy Slack Reclamation GSSR [Zhu03] :
� Extension de GSR [Moss00] :� Architecture multiprocesseur
� Chaque excédent est attribué à la tâche suivante du même processeur
� Tâches indépendantes
� Prêtes à t=0
� Même échéance D
� Non préemptive
� LTF (Largest Task First)
� Anomalie de fonctionnement� Violation de contraintes temporelles
� Exemple : T={T1(5,2), T2(4,4), T3(3,3), T4(2,2), T5(2,2), T6(2,2)}
26/03/2010
21
Les techniques DVFS – Ordonnancement global (2/4)
• Global Scheduling with Shared Slack Reclamation GSSR [Zhu03] :
� Principe :� Partager les slacks entre des tâches de processeurs différents
� Performances :� Garantie le temps réel
� Résultats intéressants pour une complexité réduite (O(n))
� Modèles de tâches indépendantes
• List Scheduling with Shared Slack Reclamation LSSR [Zhu03] :
� Extension de GSSR :� Tâches dépendantes
� Anomalie de fonctionnement� Dépassement de l’échéance
� Ordre d’activation des tâches
• Fixed-order List Scheduling with Shared Slack Reclamation FLSSR:
� LSSR avec ordre d’exécution fixé par le pire cas.
(a) LSSR (b) FLSSR
Les techniques DVFS – Ordonnancement global (3/4)
26/03/2010
22
����
����
Les techniques DVFS – Ordonnancement global (4/4)
• Performances :
� Garantie des contraintes temps réel
� Preuve d’ordonnançabilité par construction
� Complexité comparable aux GSR et LSSR
� Sous exploitation des excédents.
� Ordre d’exécution fixe: � Pas conçu pour gérer des graphes conditionnels
� Manque de réactivité (Hypothèses : Pas de préemption, Pas de migration) par rapport à des tâches de haut niveau de priorité qui demandent à être exécutées
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
• Architectures multicœurs sur puce
� Problématique des systèmes de vision
� Espace de conception des architecture MPSOC
� Les points durs
• Cas de l’architecture SCMP
• Les nouveaux Challenges
44
26/03/2010
23
Image reconstruction pipeline
• Noise reduction
� Linear filters
� Non linear filters
� Bi-/tri-lateral filters
� Inverses approaches (Wiener)
Raw
Image
Noise reduction
Image reconstruction pipeline
Raw
Image
Noise reduction
Dynamicimprovement
• Dynamic improvement
� Histogram based correction
� Gamma correction
� Localy adaptative corrections
� HDR (High Dynamic Range Imaging)
� Statisctical methods
26/03/2010
24
Image reconstruction pipeline
Raw
Image
Noise reduction
Dynamicimprovement
Color reconstruction
V
V
VV
V V
V V
V
V
V
V
R
R
R
RB
B
B
B
B
B
B
B
B
?
? ?
?
? ?
?
? ?
?
?
?
?
?
?
?
?
? ?
?
?
?
?
?
? ???
?
?? ? ?
?
?
??
?
?
?
? ? ???B
V
V
VV
V V
V V
V
V
V
V
B
B
B
B
B
B
B
B
R
R
R
R
?
?
?
?
?
• Color reconstruction
� White Balance� Grey World
� Grey-Edge
� CIE
� Retinex
� Demosaïcing� Bilinear
� Temporal approaches
� Frequencial approaches
� Shade constant
Image reconstruction pipelineR
aw Im
age
Noise reduction
Dynamicimprovement
Image enhancement
Color Im
age
Color reconstruction
• Image enhancement
• Edge raising
• Constrast raising
• Brightness adjust
26/03/2010
25
Vision application trends
• Huge amount of services� Road or public building monitoring � Video watching� Advance Driver Assistance System (ADAS)� Non destructive Industrial Control� Automatic guidance� …
• Based on a wide set of technologies � Segmentation, Morphological analysis� Attribute extraction (shapes, colors, textures, …) � Classification and recognition� Learning methods� Stereovision, calibration� Interest point matching� Object tracking� Motion detection� ….
Seat Occupancy
Blind spot detection
Lane
Tracking
Pedestrian detection
Rear ViewCamera
PassiveNightvision
Pre-Crash
1990
Extr.High
VeryHigh
2000
PedestrianDetection
2010
Lane DepartureWarning
CollisionMitigation
Side-ImpactDetection
EU Goal:50% Less
Traffic Deaths
Car safety ACC 1G
High
ACCStop&Go
Pedestrian Protection
Adv. Parking
Aid
ActiveNightvision
SystemComplexity
Road monitoring
Infrastructre monitoring
Pedestrian detection application example
SmoothingDe-noising
Contour extraction
ObjectSignature
Classification
for given sub images
Pre
proc
essi
ngO
bjec
t det
ectio
n an
d re
cogn
ition
Progressive scale matching and complexity improvements
Model-based object signature
1 2 3 4
Reject sub image
+-
Cascade of classifiers
Complexity
TrackingTemporal analysis Reject false alarms
26/03/2010
26
Image to vision application
• From image reconstruction to analysis, a wide set of constraints
� Low-level image processing benefits from a hudge amount a fine grain parallelism
� Manage pixels
� Very regular processing
� Very high spatial locality in data accesses
� High level analysis in vision application has task level parallelism� Manage objects
� Irregular control flows, data dependant processings
� Random memory access (or at least complex object manipulation)
Connected component labeling execution time for a parallelization on 8 processors (128 tasks)
• Software management of task is however not for free
� Low reactivity
� Low transistor and silicon efficiency
� Overhead hardly predictible becausee of its dependancies regarding workload
• Advantages in hardware acceleration
� Overlapping between control and computation activities
� Determinism
� Reactivity
� Low cost
Hardware support for the control
The Scheduler and the time tick processing overheads in MicroC/OS-II on a PowerPC, A Configurable Scheduler for Real-Time Systems – ERSA03
TâcheTâcheTâche
System interface
Processeur
API
Task
Application
Interrupt/ signaling
HMI
TâcheTâcheTâchetask
Application
ProcesseurProcesseurProcesors
Allocation and scheduling
Synchronizations
MemoryMgnt
File mgnt
Systemmessaging
Task mgnt Time Mgnt
IO mgnt Internal com mgnt
Resources sharing
HAL
Réseau d’interconnexion
Mémoire
Processeur monotâche
Mémoire
Processeur monotâche
Contrôle
Mémoire
Systèmed’exploitation(processeur)
Calcul
HW-RTOS
26/03/2010
31
Hardware support for task management
• Full Hardware solution� For asymmetric approaches
� May need several 100kgate but support very aggressive real time scheduling approaches
• Shared accelerator� For SMP systems
� Less than 100kgate � Not so smart but allow secured sharing
of system information and a centralized signalization scheme
• Mix approach � For multi-purpose asymmetric approaches� Based on a small RISC processor with optimized coprocessor interface
61
PE and MemoryAllocation
Selection
Control Interface / CPL (CI)
Task Exec. and Synch.
CPU Mgnt
Scheduling
PECtrl
Fault-toleranceMgr
L1
Interconnect
Core
L1
Core
L1
Memory Interface
On/O
ff control
Clustermonitors
Core
Cluster monitors
Event/InterruptManager
It MgrC/S Regs
Fault-ToleranceC/S Registers
PowerMgt
Internal Registers
Prog. NotifierC/S Registers
ProgrammableNotifier
SynchronizationC/S Registers
Synchro RegsUpdater
PowerC/S regs
Mem
ory
(L2,
L3,
Ext
ern)
Data Management
• Image and vision applications manage huge amount of data• Particular attention must be paid on memory subsystem• Try to avoid know problems of traditional approaches
� Caches� Power consumption� Silicon density � Predictability� Low spatial locality in multi-dimensional data
� Scratchpads � Performance overhead due to SW memory management (Allocation, data fetching)� Not User friendly
� In both case there is no overlapping between data fetching and computations• Basic principles of an efficient memory subsystem
� Use simple memory primitives � Add hardware support for memory management with efficient synchronization schemes� Use this potential parallelism to forecast data fetching (don’t wait for a cache miss to fetch
a data !) and ease application software pipelining
LOAD
EXE
STORE
LOAD
EXE
STORE
LOAD
EXE
STORE
N
Prolog
Epilog
26/03/2010
32
Smart data prefetcher for scratchpad memories
• Smart prefetch engines built on top of 4 modules :
� Standard SRAM
� Data Access control� Data routing
� Synchronization
� Programmable Address Generator� Data access pattern generation
supporting complex object manipulation
� Built on the basis of a 16-bit RISC datapath
� Transfer job management� Support speculation by managing
transfer job addition, suppression, reordering, …
ProcessingElement
ProcessingElement
Data Access ControlData Access Control
SRAMSRAM
To/From Shared Memory Space
Programmable Address
Generator
Programmable Address
Generator
Transfer jobs mgntTransfer jobs mgnt
Implementation results
• Standalone implementation of the Programmable Address Generator in HCMOS9� 0.03mm²@400MHz
• Integration of a complete DPS with a SPARC V8 core and a 8k scratchpad memory on FPGA platforms� EVE technology (Virtex IV)
• Strong improvement in data hit rate for standard image processing algorithms � e.g. 45% for a basic three-step motion estimation algorithm by using both prefetching
and speculation
64
54%
25%
13%8%
AG Core
Request Ctrl
Transfer Ctrl
Job control
26/03/2010
33
SCMP Architecture
• SCMP framework
� Explicit separation between control and computing activities
� Producer-consumer execution model
� Dynamic storage and processing units allocation
� Physical distribution of shared memory space
CPUOperating System (real-time)
SCMP
System Bus
Interconnection Resource
PE
meminstrmem data
PE
meminstrmemdata
mem
controller I/O
I/O
mem mem mem
PE
meminstrmemdata
mem mem mem
instr instr instr instr instr
Memory Configu-ration and Manage-ment Unit
GA GA GA GA
controller I/O
GA
I/O
OSoC : HW Controller
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
� Présentation générale
� Service de gestion dynamique de la consommation� Pour la gestion de modes DVFS
� Pour la gestion de modes d’endormissement
• Les nouveaux Challenges
66
26/03/2010
34
• Slack Reclamation methods
� FLSSR (Fixed-order List Scheduling with Shared Slack Reclamation)
� RSSR (Restricted Sharing Slack Reclamation)
DVFS technique in SCMP
0 1 2 3 4 5 6 7 8 9 10 11 12
T0
925747
260IDLE
T3T4
IDLE
T1 T2 T5
925747
260
P(mW)
T(ms)
D
T0 T1 T2 T3 T4 T5
Ready time 0 2 3 6
Queue
0 1 2 3 4 5 6 7 8 9 10 11 12
T0
925747
222T3
T1 T2 T5
925
P(mW)
T(ms)T4
IDLE
D
T4
�
�
� Poor slack exploitation.
� Fixed execution order:
�Can’t handle conditional graphs
� Lack of reactivity (No preemption, migration)
� Slack loss at the convergences
� A single frequency / task job
� Based on ELLF scheduling policy
DVFS technique in SCMP
T0 T1
T2
T3T5T4
(1/3) (2/2)
(5/5)(4/6) (2/3)
(4/4)
T6 T7
(2/2)(2/2)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
T0
925
260
T1 T2
T4
925
P(mW)
T(ms)
T3 T6
T7T5
D = 14
-a- -b-
IDLE
�
�
(AET/WCET)
26/03/2010
35
DVFS technique in SCMP
• Principle :
� Assign the slack to the next task on the same processor (% resource dependency)
� Associated Scheduling policy:� Global with dynamic priority (ELLF)
� Preemptive with migration
• Algorithm
1: For ( each processorp ) do2: If ( Tj finishes execution on p )3: Slackon processorp: Sp= sj ;4: End If5: If ( Ti is allocated on p with the initial DVFS level#n)6: Compute the remaining execution time:r i
#n(t);7: The reclaimed slack:R_slack = min(Sp, li(t));
8: If ( ∃ a better DVFS level#m considering R_slack+ri#n )
9: Update Ti’s laxity:
10: Update Ti’s DVFS level= level#m;11: End If12: Else13: Decrement the processor slackSp ;14: End If15: End For
DVFS technique in SCMP
T0
925747570
186
T5T1 T2
T3
925
570
186
P(mW)
T(ms)
D
T4 T6T4
T7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
IDLE
IDLE
�
�T0 T1
T2
T3T5T4
(1/3) (2/2)
(5/5)(4/6) (2/3)
(4/4)
T6 T7
(2/2) (2/2)
D = 14
Vs.
RSSRRSSR
FLSSRFLSSR
T0 T1 T2 T3 T4 T5
Readytime 0 2 3 6 8 12
Queue T6 T7
T0
925747
260
T1 T2
925747
260
P(mW) D
T4 T6
T7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
IDLE
�
�
T5
T(ms)IDLET3
IDLE
Ordre partiel
26/03/2010
36
DVFS technique in SCMP
T0
925747570
186
T5T1 T2
T3
925
570
186
P(mW)
T(ms)
D
T4 T6T4
T7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
IDLE
IDLE
�
�
T0
925747570
186
T1 T2
T3
925
312
P(mW) D
T4 T6T4
T7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
IDLE
�
�
T5
T(ms)
T0 T1
T2
T3T5T4
(1/3) (2/2)
(5/5)(4/6) (2/3)
(4/4)
T6 T7
(2/2) (2/2)
D = 14
Vs.
RSSRRSSR
[Tha08] [Tha08]
Plan
• Introduction aux architecture multicœurs
• Gestion de la consommation dans les architectures multicoeurs
• Architectures multicœurs sur puce
• Cas de l’architecture SCMP
� Présentation générale
� Service de gestion dynamique de la consommation� Pour la gestion de modes DVFS
� Pour la gestion de modes d’endormissement
• Les nouveaux Challenges
72
26/03/2010
37
Idle mode Management in SCMP
• Context :
� Periodic, aperiodic Applications
� Multi-application, Multi-instances of applications
• Principle:
� Characterize offline (using WCET) the variation of the parallelism rate of each application
� Detect online these variations and deduce the Idle periods.
� Activate the ideal low power mode (modified LEA) and predict the corresponding awakening time.
Idle mode Management in SCMP
• Characterize offline the variation of the parallelism rate of the application
� Labeling procedure:� A new label is created at each root Task ;
� At a convergence, the label construction continues according to a branch and other labels are created for the other branches ;
� A label expansion stops at a convergence ;
� Each tasks belongs to a single label;
� Labels are homogeneous in terms of processor type.
� Parallelism_rate structure construction� Pick up the date of each label worst case arrival time (WCAT);
� Pick up the number of needed processors at that date.
26/03/2010
38
Idle mode Management in SCMP
• Detect online these variations and deduce the Idle periods
� If (Nactive ≥ Nready)� At an end of label, search in the parallelism_rate table the next time Tnext the system needs
N processors ≥ Nactive.
� Tidle = Tnext – Tcurrent
• Activate the ideal low power mode (modified LEA) and predict the corresponding awakening time