Architectures haute-performance et embarquées Evolutions des

Transcription

Architectures haute-performance et
embarquées
Evolutions des architectures versus
autres contraintes
Nathalie Drach
Equipe ASIM
Laboratoire d’Informatique de Paris 6 (LIP6)
Université de Pierre et Marie Curie
1
Définitions
Embedded Processor (EP) :
processeur embarqué, processeur
enfoui, processeur spécifique.
General-purpose Processor (GP) :
processeur généraliste, des PC aux
stations haute-performance,
dimmensionnement.
Processeur embarqué = Système
embarqué = processeurs + applications +
OS = indissociables.
Système embarqué : système inclus
(embarqué) dans un système plus large et
son existence comme « ordinateur » n’est
pas apparente.
Différences : applications, volume de production (marché) et
contraintes d’utilisation.
Similitudes : architectures et applications émergeantes.
2
Applications
GP : applications bureautiques, applications
scientifiques.
EP : produits de consommation courante, équipements
audio-vidéo de la maison, portables, systèmes
multimédia, consommables électroniques,
périphériques, infrastructures de communications,
systèmes de contrôle, ...
3
Marché
$30B
GP représente 1% de tous les
processeurs
vendus chaque
année (~ 100
millions de GP).
EP représente
99% des ventes!
32-bit
micro
32 bit DSP
$5.2B/17%
$1.2B/4%
DSP
$10B/33%
16-bit
micro
$5.7B/19%
8-bit
micro
$7.9B/27%
Ominiprésence

ì... the New York Times has estimated
that the average American comes into
contact with about 60 microprocessors
every day....î [Camposano, 1996]

Latest top-level BMWs contain over 100
micro-processors [Personal
communication]
4
La performance, mais aussi…

Consommation/dissipation,
Côut,
Taille du code,
Temps réel,
Fiabilité, sécurité, flexibilité, ...
Performance versus délai de propagation.
5
Dissipation et Consommation

Processeurs embarqués
(consommation) :
• Traitements de plus en plus
complexes à des cadences de
plus en plus rapides.
• Durée des batteries.
Feature size (nm)
Logic trans/cm2
Cost/trans (mc)
#pads/chip
Clock (MHz)
Chip size (mm2)
Wiring levels
Power supply (V)
High-perf pow (W)
Battery pow (W)
1999 2002 2005 2008 2011 2014
180
6.2M
1.735
1867
1250
340
6-7
1.8
90
1.4
130
18M
.580
2553
2100
430
7
1.5
130
2
100
39M
.255
3492
3500
520
7-8
1.2
160
2.4
70
50
35
84M 180M 390M
.110 .049 .022
4776 6532 8935
6000 10000 16900
620
750
900
8-9
9
10
0.9
0.6
0.5
170
175
183
2.8
3.2
3.7
SIA RoadMap
Year
Processeurs généralistes et hauteperformance (dissipation) :
• Augmentation de la fréquence,
de la densité d’intégration.
• Coût du matériel de
refroidissement.
Puissance
Puissance max
Watt

Durée batterie
Temps
Consommation
6
Consommation d’Energie

Consommation = Puissance x Temps.
Puissance = P statique + P dynamique (Watt).
• P statique (courant de fuite) actuellement
négligée (-10% consommation totale).
• P dynamique = ½ x C x a x Fréquence x
(Tension)2 (dépend de l'activité de la porte,
c'est à dire, elle dépend des transitions
des entrée/sortie).
•
“Plus le transistor est petit moins cela chauffe,
0.13
mais plus on peut en mettre”.
•
Activité : détermine le nombre de transitions
par cycle.

Consommation importante :
• Gestion de l’horloge.
• Gestion des instructions.
• Accès aux caches.
7
Mais aussi : processeurs performants
Meilleure performance : temps d’exécution réduit.
Dissipation plus élevée : plus de traitements simultanément.
Perf2
Dissipation
Perf1 > Perf2
Temps
8
Integer Program Power Analysis
Rename
2%
Power Distribution-Int workloads
Bpred
2%
ROB
1%
Fp-clock
13%
Icache
7%
FP resultbus
2%
FP mult
2%
Fr-end clock
9%
FP add
5%
LSQ
3%
FP regfile
3%
Int issueq
3%
FP issueq
1%
Int regfile
4%
Int add
8%
Int-clock
21%
Int mult
1%
L2 cache
5%
Rename
Bpred
ROB
Icache
Fr-end clock
LSQ
Int issueq
Int regfile
Int add
Int mult
Int resultbus
L1D cache
L2 cache
Int-clock
FP issueq
FP regfile
FP add
FP mult
FP resultbus
Fp-clock
Int resultbus
3%
L1D cache
5%
9
Floating Point Program Power Analysis
Power Distribution-Fp workloads
Rename
2%
Bpred
2%
Fp-clock
10%
ROB
1%
Icache
7%
FP resultbus
3%
Fr-end clock
7%
FP mult
5%
LSQ
3%
FP add
9%
Int issueq
3%
Int regfile
5%
FP regfile
4%
FP issueq
2%
Int add
8%
Int mult
1%
Int-clock
17%
L2 cache
4%
Int resultbus
2%
Rename
Bpred
ROB
Icache
Fr-end clock
LSQ
Int issueq
Int regfile
Int add
Int mult
Int resultbus
L1D cache
L2 cache
Int-clock
FP issueq
FP regfile
FP add
FP mult
FP resultbus
Fp-clock
L1D cache
6%
10
Evolution de la puissance
11
Comparaison généraliste / embarqué
Comparaison performance / consommation (MIPS / Watt)
Comparaison répartition
(ASIC)
12
Capacité des batteries

Energie = durée de vie des batteries.
Amélioration des batteries : * 2,5 en 30 ans.
Batterie Lithium-Ion : 220 Watts-heure / Kg, mais amélioration
limitée dans les prochaines années.
Pile à combustible : pas pour demain (coût, maîtrise de
l’hydrogène, extraction de l’hydrogène, poids) !
∼ Loi de Shannon
∼ Loi de Moore
Capacité des Batteries
13
Concevoir et évaluer pour réduire la
consommation
Niveau
Fonctionnel
Logiciel
Niveau
Portes
Exactitude de l’estimation de consommation
Rapidité de simulation/d’évaluation
Potentiel pour l’optimisation de consommation
14
Niveau logiciel ou comportemental
Configuration
matérielle
Modèle
de consommation
Simulateur
fonctionnel
Enregistrement
des accès aux unités
à chaque cycle
d’horloge
Estimation de
la consommation
Estimation de
la performance
Programme
de test
David Brooks, Vivek Tiwari, and Margaret Martonosi. "Wattch: A Framework for ArchitecturalLevel Power Analysis and Optimizations," 27th International Symposium on Computer
Architecture (ISCA), 2000
int Regs
fp Regs
ICache
Fetch
Decode
RS(int)
RS(fp)
DCache
vect Regs
RS(vect)
RS(L/S)
ROB
VPerm
VFU
15
Techniques matérielles et logicielles
pour réduire consommation / dissipation

Réduire la consommation/dissipation en
réordonnançant/transformant le code :
• ordonnancer les instructions pour réduire les
commutations.
• transformer simplement le programme.
• ordonnancement l’exécution des instructions
(ILP) pour contrôler la dissipation.
Réduire la consommation des opérations qui
consomment beaucoup :
• réduire le nombre d’accès à la mémoire,
• réduire la consommation des caches.
• réduire le nombre de transitions sur le bus.
Généraliste –
HautePerformance
Réduire le surcoût généré par la spéculation.
16
Réduire la fréquence/le voltage

Le plus direct (P dynamique = ½ x C x a x Fréquence x (Tension)2 ):
• Réduire la fréquence,
• Réduire le voltage.
Dissipation
F > F’
Exemples :

F’
Temps
Processeur Intel Mobile Pentium III avec la technologie SpeedStep : changement
dynamique de fréquence et de tension (500Mhz, 1.35 V ou 600/650Mhz, 1.6 V) selon
mode d’alimentation (batterie ou courant). Modes : Battery Optimized ou Maximum
Performance.
Processeurs Mobile AMD-K6-2+ and Mobile AMD-K6-III+ avec la technologie AMD
PowerNow (3 modes : High-Performance Mode, Battery Saver Mode, Automatic
Mode).
Processeur Crusoe de Transmeta avec la technologie LongRun (600MHz/300MHz et
1.6/1.3 V).
17
Réduire les commutations

Techniques :
• Générer le code en utilisant les
instructions qui consomment le
moins.
• Ordonner les instructions afin de
minimiser l’activité de
commutation.
• Sélection des instructions basées
sur des mesures réelles.
Inconvénients :
• Processus qui consiste à mesurer
la consommation pour toutes les
paires d’instructions très long.
• Table de grande taille utilisée pour
stocker toutes les valeurs de
puissance.
Tiwari, S. Malik, A. Wolfe and M. Lee, "Instruction
Level Power Analysis and Optimization of
Software", Journal of VLSI Signal Processing,
1996.
18
Transformation du code
Le logiciel détermine la puissance dissipée par le processeur.
19
Gérer l’ILP pour réduire la dissipation

Ordonnancement classique : augmenter les performances i.e.
augmenter l’ILP.
I1
I2
I3
I1
I4
Avant

I5
I2
I3
I4
Après
I5
Ordonnancement guidé par la dissipation :
• Sacrifier des gains de performance afin d’obtenir la
dissipation désirée.
• Des valeurs de dissipation sont associées à chaque unité
fonctionnelles.
I1
M.C. Toburen, T.M. Conte, and M. Reilly, "Instruction Scheduling for
Low Power Dissipation in High Performance Processors", In the
Power Driven Microarchitecture Workshop in conjunction with the
25th International Symposium on Computer Architecture, 1998.
I2
I3
I4
I5 Après
20
Réduire les accès à la mémoire

Transformations pour réduire le nombre d’opérations de lecture et
d’écriture en mémoire.

Les caches permettent de réduire le nombre d’accès à la mémoire.
21
Réduire les accès à la mémoire :
caches sur les DSP

Les PM (Program Memory) et DM caches sont situés sur la
même puce que le CPU afin de réduire la consommation due
aux accès au bus données reliant le tout au système mémoire
principal.

Exemple : StrongARM 110 : 2 caches instructions et données
séparés avec 16 bancs.
22
Réduire les transitions sur le bus
23
Cache Energy
2000
1800
1600
Energy (pJ)
1400
1200
4-way
1000
2-way
800
1-way
600
400
200
0
4K
8K
16K
32K
64K
Cache Size

Obtenir plus de performance : augmenter la taille du cache, l’associativité et la
taille de la ligne.
Limiter la consommation : réduire la taille du cache et l’associativité. Mais aussi
réduire le nombre d’accès à la mémoire.
Compromis…
Rapport consommation due aux accès mémoire / consommation due aux accès
cache :

Rapport grand : se focaliser sur l’amélioration du taux de succès.

Rapport petit : se focaliser sur minimiser la consommation d’énergie
des accès au cache.
24
Différentes politiques d’accès au cache
Sequential
Fallback-regular
cycle 1
cycle 1
Phased cache
cycle 1
cycle 2
cycle 2
cycle 2
cycle 3
Predictive-Phased
Fallback-Phased
cycle 1
cycle 2
cycle 1
cycle 2
cycle 3
25
0.67
0.68
0.78
0.69
0.72
0.68
0.67
0.74
0.69
0.98
1.01
1.05
0.8
4-way Sequential
4-way FallBackReg
4-way Phased
4-way FallBackPha
4-way PredictPha
0.68
Normalize Baseline
1
0.99
1.05
Performance
0.6
0.4
0.2
0
Delay
Energy
E*D
A. Hasegawa et al., « SH3: High Code Density, Low Power », In IEEE Micro, 1995.
K. Inoue , T. Ishihara, and K. Murakami, ``Way-Predicting Set-Associative Cache for High
Performance and Low Energy Concumption,'' In the International Symposium on Low Power
Electronics and Design (ISLPED'99) , 1999.
26
Surcoût des instructions spéculatives
(exemple : prédiction de
branchement)
• Augmentation de la dissipation et de l’énergie.
• Limiter la spéculation, mais réduire performance.
27
Contrôler / limiter la prédiction : un
exemple

Technique du « pipeline gating ».
"Pipeline Gating: Speculation Control For Energy Reduction" , Srilatha Manne, Artur Klauser and Dirk
Grunwald, ISCA-98.
28
Technologie : une technique efficace

Supprimer les commutations des blocs qui n’ont pas besoin
d’être rechargés.
Quand pas d’activité (pas d’utilisation), pas de dissipation
dynamique.
Composants inutilisés éteints (clock gating).
29
D’autres problèmes : gestion de
l’horloge

Consommation de
puissance pour la gestion
de l’horloge augmente
avec :
• la taille de la puce et la
capacité des portes,
• avec la fréquence.

DEC 21164 : 40-50% de
la consommation pour
gérer l’horloge.
30
Conclusion
performance / consommation sur EP

Augmentation de la demande pour des calculs rapides et des
fonctionnalités complexes (exemple : communication sans fil,
traitement d’images).

Mais la consommation excessive limite le nombre de
transistors intégrés, donc les performances.

Question : comment trouver le point pour lequel l’énergie
économisée est suffisante tout en maintenant des
performances acceptables ?
31
Coût
Coût dépendant de plusieurs paramètres :
• coût d’un transistor (le coût d’un transistor est
proportionnel à la racine carrée de sa taille).
• coût de la chaîne de conception et des différentes
solutions matérielles adoptées.
• coût des développements logiciels.
32
Coût des développements logiciels
« Historiquement » :
développement en assembleur
notamment pour les parties
critiques.
Développement HL langage (C
et C++) :
• Coût des développements
logiciels et aussi :
• Augmentation de la
complexité des programmes,
• Portabilité,
• Progrès des compilateurs,
• Evolution des architectures.
C-Code
(DSP) C-Code
(µController)
Assembler
(DSP)
Assembler
(µController)
[Paulin, 1995]
33
Développements logiciels
vs Performance
34
Taille du code
Problème :
• Coût, taille et puissance.
Coût de certaines machines embarquées = coût
de la mémoire (et non du processeur).
La mémoire instructions domine en taille et en
consommation de puissance.
• Faire tenir le programme sur la mémoire on-chip.
35
Taille du code (suite)
Les alternatives :
Compilateurs vs assembleur :
• Taille/vitesse d’optimisation, portabilité, coûts de
développements.
Compression des programmes:
• Tenir compte des répétitions.
• Compromis performance/densité de code.
• Utiliser des processeurs meilleur marché avec des
mémoires on-chip plus petites.
36
Compresser les codes

Choix du jeu d’instructions (spécialisés ou non).
Utiliser des techniques “classiques” de compression :
• Statistique :
Chaque codage représente un caratère. Exemple :
codage d’“Huffman”.
37
Choix du jeu d’instructions

RISC vs CISC : densité de code + CICS, mais pour RISC des
solutions…
SuperH (Hitachi), M•Core (Motorola) :
• 16-bit instructions, 32-bit data.
Thumb (ARM), MIPS-16 (SGI)
• Instructions 16 bits sous-ensemble du jeu d’instructions de
base.
• Réduire la taille des instructions de 32 bits à 16 bits.
TriCore (Siemens), V8xx (NEC)
• 16-bit and 32-bit instructions peuvent être mixées.
38
Méthode du dictionnaire : par
instruction
39
Modification architecture
40
Méthode du dictionnaire :
par bloc de base

Mettre dans un dictionnaire des séquences d’instructions communes
(une séquence ne peut pas dépasser un bloc de base).
Puis, remplacer les séquences du programme avec les codes du
dictionnaire.
Le programme final contient le code compressé et le dictionnaire.
Original
lbz
rlwinm
addi
cmpli
ble
cmpli
bgt
lwz
stb
b
lbz
rlwinm
addi
cmpli
r9,0(r28)
r11,r9,0,24,31
r0,r11,1
cr1,0,r0,8
cr1,401c8
cr1,0,r11,7
cr1,41d34
r9,4(r28)
r18,0(r28)
41d38
r9,0(r28)
r11,r9,0,24,31
r0,r11,1
cr1,0,r0,8
Compressed
CODEWORD
ble
cmpli
bgt
CODEWORD
b
CODEWORD
#1
cr1,L1
cr1,0,r11,7
cr1,L2
#2
L3
#1
Dictionary
1
2
lbz
rlwinm
addi
cmpli
lwz
stb
r9,0(r28)
r11,r9,0,24,31
r0,r11,1
cr1,0,r0,8
r9,4(r28)
r18,0(r28)
T. Mudge, http://www.eecs.umich.edu/~tnm/compress
41
Temps réel (définition)

Système temps réel : système dépendant non
seulement de la fiabilité des résultats, mais
aussi de l’instant où les résultats sont
produits.
« Deadline soft » (soft real-time systems),
temps réel mou :
• Multimédia,
• Jeux vidéo intéractifs.
Ex: Missing deadlines in real-time video leads
to unacceptable picture quality resulting
in a failed product.
« Deadline hard » (hard real-time systems),
temps réel dur :
• Aviation,
• Nucléaire,
• Médical.
Ex: Advanced variable-cycle jet engines can
explode if correct control inputs are not
applied every 20-50 ms.
42
Analyse du temps

Analyse du temps pour les différentes tâches du
système :
• Temps pour chaque tâche.
• Temps lié à l‘ordonnancement des tâches du
système : relations de précédences entre les
tâches, synchronisation, communication,
priorités, ...
Conditions pour analyser le temps d’une tâche :
• Données d’entrée disponibles au début.
• Pas de synchronisation, ni de communication
à l’intérieur de la tâche.
• Résultats disponibles à la fin de la tâche.
Mais le temps d’exécution d’une tâche est
variable en fonction des données et de l’état
d’entrée :
• Estimation du temps.
Données
Etat
Tâche
Etat
Résultats
43
Estimation du temps
•
•
•
•

Estimer le temps d’exécution d’une
tâche/application donnée. Estimation à
architecture et compilateur fixés.
Soft real-time systems : estimation du temps
moyen d’exécution.
Hard real-time systems : estimation du WCET
(Worst-Case Execution Time), temps d’exécution
maximum.
Le WCET estimé doit être :
• Sûr (safe) i.e. WCET estimé > WCET.
• Juste (accurate) i.e. (WCET estimé – WCET)
petit. Ressources sous-utilisées, dimensionner
le système.
Industrie :
• utilisation de mesures (tests sur les systèmes cibles),
profilers, analyseurs logiques pour exhiber le pire
comportement de l’application.
• Mais : coûteux en temps, difficile à mettre en œuvre,
dépendant de la qualité des cas testés, pas sûrs, …
Jakob Engblom and al., « Towards Industry Strength Worst-Case Execution Time
Analysis », In Swedish National Real-Time Conference SNART'99, August 1999.
44

Tendance actuelle/future :
obtention du temps
d’exécution au pire cas par
analyse statique du
programme (sûre,
automatique) en intégrant
des caractéristiques de
l’architecture (analyse bas
niveau).
Mais :
• Certaines caractéristiques
des programmes posent
problème (nombre
d’itérations inconnu,
« profondeur » de la
récursivité, …).
• Certaines caractéristiques
des architectures posent
problème (cache, pipeline,
…).
Difficulté pour prédire/estimer le temps
WCET
DSP
VLIW
Scalaire
Superscalaire IO
Superscalaire
OO
45
Analyser le programme

Analyse du programme source : génération
de l'arbre syntaxique (fonction, boucles, …).
Eliminer les chemins « infaisables ».

Graphe de flots de contrôle : déterminer le
temps d’exécution des blocs de base des
différentes fonctions, boucles, … Une
fonction a des temps d’exécution différents
selon les valeurs d’entrée.
Temps d’un bloc de base :
• facile pour les DSP « simples » ou
microcontrôleur (une somme).
• plus difficile pour les processeurs
modernes ; temps d’exécution d’une
instruction variable (pipeline, cache, …).

WCET : déterminer la séquence de blocs
de base la plus longue. Programmation
linéaire en nombre entiers sous contraintes.
46
Prédire le temps
dans les processeurs modernes

Les variations temporelles des processeurs modernes
entraînent des estimations très pessimistes (exemples : un
accès à une donnée ou à une instruction est toujours un échec
sur le cache, pas de recouvrement entre instructions, …),
donc :
• une réduction importante des performances effectives
(jusqu’à 90% des capacités du système non utilisées) et,
• une sur-estimation des ressources nécessaires (sousutilisées).

Comment prendre en compte les phénomènes dynamiques
des processeurs modernes pour obtenir des WCET plus
proches de la réalité ?
47
Sources de variations temporelles
dans les processeurs modernes

Eléments de mémorisation : caches, TLB (Translation
Lookaside Buffer), branch target buffer, writebuffer, etc.

Prédiction de branchement.

Temps entre instructions dépendantes :
• Multiplication, division, etc.

Pipeline instructions.

Intéractions complexes du pipeline :
• Réordonnancement dynamique des instructions,
• Renommage de registres.
DSP amélioré, VLIW, processeur superscalaire IO.
Processeur superscalaire OO.
48
Variations temporelles :
système mémoire
Non prévisibles :
Taux d’échecs.
Temps d’accès aux données :
• dépendant du niveau
mémoire dans lequel se
trouve la donnée.
• si writebuffer plein, délai
supplémentaire.
• si nombre d’échecs en
suspend atteint, délai
supplémentaire.
Perturbations (pour une
application donnée) dues aux
exceptions et au
rafraîchissement de la
mémoire.
Système mémoire : caches instructions
et données, TLB, branch target buffer,
writebuffer, etc.
TLB
Processeur
Cache
Mémoire
Write
Buffer
49
Analyse des caches
d’instructions

Hypothèse : échec est toujours le pire des cas.
Effet global.
Adresses des instructions connues, le problème essentiel :
les branchements.

Catégoriser les accès : first-miss, always-miss, first-hit,
always-hit.
Exemple : Always-hit - si instruction dans bloc de base
appartient à la ligne de cache L déjà référencée dans le
même bloc de base (modulo la taille du bloc de base).
Simuler un cache (préciser tous les paramètres).
Etre « conservatif » : une instruction sur un chemin qui ne
sera peut-être pas pris, échec.

"Bounding Pipeline and Instruction Cache Performance" by C. A. Healy, R. D.
Arnold, F. Mueller, D. B. Whalley, and M. G. Harmon in IEEE Transactions on
Computers, 01/1999, pages 53-70.
50
Analyse des caches de données

Même hypothèse : échec est toujours le pire des cas.
Effet global.
Problème pour connaître les adresses : pointeurs, allocation
dynamique, … Egalement problème des branchements.

Analyse des localités spatiale et temporelle des références.
Similaire à l’analyse de performance.
Déterminer l’ensemble des accès indépendants des données
d’entrée. Mais problème de conflits potentiels avec autres
données.
Une solution : rendre non « cacheable » les accès non
prévisibles.

Thomas Lundqvist and Per Stenström: "A Method to Improve the Estimated WorstCase Performance of Data Caching," in the 6th International Conference on
Real-Time Computing Systems and Applications (RTCSA'99), 1999.
51
Analyse des pipelines

Temps d’un bloc de base : sous-estimation. Il faut analyser les
recouvrements entre blocs de base.
Effet local.
Pipeline et cache dépendants (pas d’arrêt du pipeline en cas
d’échec).
Calculer le plus long chemin <> déterminer la séquence de
blocs de base la plus longue (l’enchaînement de 2 blocs de base
peut être plus long que la somme des 2 blocs de base).
Une solution : garder des informations sur tous les blocs de
base qui peuvent se terminer avant un bloc de base donné.
Relativement complexe
"Bounding Pipeline and Instruction Cache Performance" by C. A. Healy, R. D. Arnold,
F. Mueller, D. B. Whalley, and M. G. Harmon in IEEE Transactions on Computers,
01/1999, pages 53-70.
52
Les branchements

A cause des branchements, on ne sait pas a priori quelle
séquence de code est exécutée : accès instructions, accès
données, recouvrement pipeline, …
Chemin le plus long calculé après estimation du temps des
blocs de base.
Pénalités liées aux pipelines (délais en cas de mauvaise
prédiction) et à la prédiction de branchement utilisée
(efficacité).
Une première solution pour les pénalités : tous les
branchements sont mal prédits.
Une autre solution : analyser le comportement des
branchements dans le BTB et faire une analyse similaire au
cache. Première approche…
A. Colin, I. Puaut, « Worst Case Execution Time Analysis for a Processor with Branch
Prediction ». Real-Time Systems, Special issue on worst-case execution time
analysis, 18(2):249-274, 2000.
53
Processeurs superscalaires OO
Anomalies temporelles :
le pire des cas ne donne pas le pire
des temps!
Etude de cas : superscalaire de
degré 2, 2 stations de
réservations par unité, 3 unités
distinctes.
« Timing Anomalies in Dynamically
Scheduled Microprocessors », by
Thomas Lundqvist, Per Stenström, in
the 20th IEEE Real-Time Systems
Symposium, 1998.
54
Anomalies temporelles:
succès = WCET
Code exécuté
1er cas : A est un succès. 12
cycles.
2ème cas : A est un échec. 11
cycles.
1er cas < 2ème cas.
55
Anomalies temporelles :
pénalité d’échec augmentée
Code exécuté
C : toujours un échec.
1er cas : A est un succès. 16
cycles.
2ème cas : A est un échec.
27 cycles.
16 + 8 = 24 <> 27 cycles.
56
Optimisations à la compilation

Tenir compte dans le calcul du WCET des optimisations à la
compilation (exemples : pipeline logiciel ou déroulage de boucle
particulièrement importantes pour les architectures VLIW).

Remonter l’information jusqu’à l’arbre syntaxique. Problème de
correspondance (exemple : boucle déroulée et nombre d’itérations).
57
Conclusion
le temps réel

Solutions « acceptables » pour les caches et les pipelines.
Tenir compte des optimisations à la compilation.
Donc processeurs pipelines, VLIW, superscalaires IO avec
hiérarchie mémoire, envisageables pour le temps réel dur…
avec des améliorations.

Eléments globaux comme la hiérarchie mémoire : influence
également sur les changements de contexte. Des solutions :
• Allouer des portions de cache différentes pour les tâches
indépendantes (réduire l’efficacité du cache).
• Stocker le contenu du cache à chaque changement de
contexte et revenir en l’état (surcoût important).
Analyse du WCET peut guider les optimisations et vice-versa.
Permet le dimensionnement du système.

58
Conclusion
le temps réel (suite)

Mais pour l’instant difficile d’intégrer les processeurs
superscalaires OO :
• Anomalies empêchent de considérer le pire des cas et de
considérer des calculs locaux sur les blocs de base.
• Un solution : supposer une exécution séquentielle des
instructions. Approche très pessimiste.
• Autre solution : synchroniser (arrêter le pipeline) à chaque
instruction posant problème. WCET peu « juste ».
• Ne parlons pas de tous les autres mécanismes spéculatifs :
prédiction de branchement, prédiction de valeur, « reuse »
instruction, etc.
59
Délai de propagation
Die reachable (%)
Year of 1st shipment
Local Clock (GHz)
Across Chip (GHz)
Chip Size (mm²)
Dense Lines (nm)
Number of chip I/O
Transistors per chip
1997 1999 2002 2005 2008 2011 2014
0,75 1,25
2,1
3,5
6
10 16,9
0,75
1,2
1,6
2
2,5
3 3,674
300 340 430 520 620 750 901
250 180 130 100
70
50
35
1515 1867 2553 3492 4776 6532 8935
11M 21M 76M 200M 520M 1,4B 3,62B
100
90
80
70
60
50
40
30
20
10
0
1 clock
2 clocks
4 clocks
8 clocks
16 clocks
0,25
0,18
0,13
0,1
0,08
Processor generation (m icrons)
0,06
60
« Critical-path »
Motivation :
• le délai de propagation du signal sur la puce
augmente (technologie).
• la fréquence d’horloge augmente.
• la complexité fonctionnelle de la puce (complexité
des composants) augmente.
=> Certains traitements ne peuvent pas/plus se faire en
un cycle.
Concrètement :
• 40% des opérandes sources utilisent le “forwarding”
dans un processeur superscalaire de degré 8
(simulation, SPEC95).
• les techniques impléméntées pour augmenter les
performances complexifient les composants.
61
Temps d’accès augmenté
Exemple : les registres
Délai pour le « register file » (0.18 micron)
« Complexity-Effective Superscalar
Processors », by S. Palacharla, N. P.
Jouppi et J. E. Smith, In the 24th
Annual International Symposium on
Computer Architecture, 1997.
62
Solutions
Concevoir pipelines qui tolèrent les latences dues au délai de
propagation.
Regrouper des éléments (cluster) avec délai intra-cluster
court et délai inter-cluster plus long similaire à
communication locale rapide, communication à distance plus
longue (mais sur la puce).
63
Augmenter la taille du pipeline
Front-end : instruction fetch, registre rename et register file access opérations.
Execute : window wakeup, window selection et data bypass opérations.
Cache access : cache operations.

Ajout de 1 et 2
étages de pipeline.
Processeur simulé :
8-way out-of-order,
fenêtre instructions =
64 entrées, fichier de
registres = 120
entrées, + Gshare.
« Complexity-Effective Superscalar Processors », by S. Palacharla, N. P. Jouppi et J. E. Smith, In the 24th
Annual International Symposium on Computer Architecture, 1997.
64
Clusters d’unités de même type

DEC 21264.
4 instructions entières
exécutables en même temps
=> 8 ports lecture + 6 ports.
Pallier au problème de temps
d’accès aux registres.
Six unités de calcul groupées
en 3 « clusters ».
Dupliquer banc de registres
entiers : 4 ports lecture + 3
ports écritures. 1 cycle
supplémentaire pour
synchroniser bancs de
registres.
65
Cluster d’unités de types différents (1)
Cluster d’UF :
regroupement
d’unités
fonctionnelles
hétérogènes (peut
travailler sur des
morceaux de code
indépendants).
But : réduire au
maximum les délais
entre les blocs
dépendants.
« Function Unit Clustering in Wide-issue Superscalar Processors », by M.
Postiff. http://www-personal.umich.edu/~postiffm/papers/papers.html

66
Cluster d’unités de types différents (2)
VLIW en clusters : séparation FUs, registres, caches
E. Gibert, J. Sánchez and A. González, ICS 2002
67
Cluster d’UF et fenêtre d’instructions
« Complexity-Effective Superscalar Processors », by S.
Palacharla, N. P. Jouppi et J. E. Smith, In the 24th Annual
International Symposium on Computer Architecture, 1997.

Unité de « steering » :
sélectionne à quel cluster/UF
l’instruction sera envoyée en
essayant de minimiser le
nombre d’utilisation interclusters.
• Complexité augmentée
pour sélectionner les
clusters qui généreront le
moins de délai.
• Sélection difficile à cause
des problèmes de
latences des UF et des
caches non déterminées.

Heuristique : RPT (Register
Producer Table). Association
entre registre logique et
cluster.
• Cluster ayant produit la
dernière valeur du
registre.
• Indexée par numéros de
registres sources.
• Généralement, instruction
envoyée à un cluster
ayant produit un de ses
opérandes source.
68
Architecture multicluster

Registres locaux : assignés à un cluster.
Registres globaux : assigné aux 2 clusters.
2 registres physiques.

Eléments distribués sur les
clusters :
• les queues de « dispatch »,
• les registres (à chaque
cluster est assigné un sousensemble de registres
matériels),
• les UF .
Les instructions exécutées sur le
cluster C ont été distribuées par
le cluster C et peuvent lire et
écrire les registres du cluster C.
Les caches données et
instructions sont partagés.
Avantage : chaque cluster
exécute peu d’instructions par
cycle, donc moins de logique
d’ordonnancement, les registres
d’un cluster demande peu de
lecture/écriture.
« The Multicluster Architecture: Reducing Cycle Time Through Partitioning », by K. I.
Farkas et al., in the International Journal of Parallel Programming , volume 27, number 5,
October 1999.
69
Architecture multicluster
Une autre architecture « naturellement » multicluster : CMP.
Mais problème avec cluster, tend à réduire l’ILP.
70
Fiabilité-sécurité / Flexibilité

Fiabilité : très grande importance/place des machines embarquées
dans la vie quotidienne.
Sécurité : effet de bord. De plus en plus confiance dans les
systèmes embarqués.
Flexibilité :
• Capacité d’intégration.
• Composants standards.
71
Graphes de dépendances sur les
contraintes
Performance
Consommation
Temps réel
Taille code
Coût
Graphe complet !
72
Intégrer GP dans EP
DSP futur
Besoin de performance - Ajouter plus de
DSP
fonctionnalités et des fonctionnalités bien
• Timing fixé – Temps prévisible.
ciblées - Augmentation de la complexité
Notamment, placement
des systèmes :
mémoire fixé.
• Processeur de base plus performant.
• Consommation faible.
• Processeur de base avec extensions
multimédia.
• Mais :
– distancé côté performance,
• Utilisation de la mémoire virtuelle.
– faible côté outils logiciels.
Réduire les temps/coûts de développement
:
– systèmes figés,
• Utiliser composant standard fabriqué en
– difficile à modifier pour des
grande quantité. Off-The-Shelf
événements non prévus
Technology.
(redesign).
• Utilisation des outils logiciels (vs
assembleur).
• Possibilité de suivre les améliorations
technologiques. Mise à jour plus facile.
73
Spécificités des EP (DSP)

Une instruction par cycle.
Mémoire on-chip permettant
plusieurs accès
Opérations spécialisées.
Plusieurs opérations par
cycle. Exemple : MAC.
Modes d’adressage
spécialisés.
Calculs virgule fixe et virgule
flottante.
Bas coût, basse
consommation et faible
utilisation de la mémoire.
74
Architectures pour les EP (DSP)

Améliorer les architectures DSP + ajout
du SIMD :
• Lucent DSP16xxx, Motorola
DSP56300, ADI ADSP2116x,…
Utiliser l’approche VLIW :
• TI TMS320C6200, Philips TM1000,
Trimédia, Siemens Infineon Carmel,
StarCore 140, …
• VLIW + SIMD : AD TigerSHARC, …
Utiliser l’approche processeur
superscalaire :
• DSP superscalaire : ZSP 164xx.
Utiliser une approche hybride : Piccolo
+ ARM7, SH-DSP, TriCore, …
DSP classique
Améliorer les DSP
SIMD
DSP VLIW
DSP superscalaire
Approche hybride
Superscalaire
SIMD
75
Améliorer les architectures DSP

Générer plus de parallélisme en
ajoutant des unités fonctionnelles.
Spécialiser davantage le matériel,
ajouter des co-processeurs (exemple
: filtrage FIR, décodeur Viterbi).
+ : performance en maintenant coût,
consommation et densité de code,
compatibilité, …
- : difficulté de programmation, pas
de compilateur adapté, …
Lucent DSP16xx et DSP16xxx
76
Ajouter des fonctionnalités SIMD

Deux façons d’implémenter le
SIMD :
• Séparer les unités d’exécution
(comme extensions
processeurs généralistes).
• Plusieurs unités d’exécution
(ou chemins de données).
Exemple : AD ADSP 2116X, …
Challenge : tirer partie du SIMD
dans les algorithmes et
l’organisation des données.
- : besoin d’une large bande
passante.
Analog Device ADSP 2106X et 2116X
77
Utiliser l’approche VLIW

Plusieurs opérations
indépendantes par cycle.
Exemples : TI TMS320C6200,
Philips TM1000, Trimédia, Siemens
Infineon Carmel, StarCore 140, …
+ : augmenter la performance.
Architecture « régulière » plus
facile à programmer. Meilleur
compilateur que DSP classiue.
Redimensionnable (?).
- : tenir compte des pipelines et
de la latence des instructions pour
la performance. Augmentation de
la taille du code. Problème de
bande passante. Consommation.
TI C62xx
78
Un exemple : StarCore SC140

DSP VLIW 16 bits de
Lucent/Motorola.
Utilise instructions 16 bits (au
lieu de 32) : densité de code.
Pipeline très simple (5 étages
au lieu de 11 comme dans le
C62xx), un cycle de latence
pour toutes les instructions.
Architecture plus efficace côté
consommation et différents
niveaux de tension.
79
Un exemple VLIW + SIMD :
AD TigerSHARC
4 instructions 32 bits en parallèle.
Architecture Load/store.
8 MACs 16 bits par cycle (40 bits),
2 MACs 32 bits cycle with (80
bits), …
128 registres généraux.
Instructions SIMD (Singe
Instruction, Multiple Data).
Exécution prédiquée pour toutes les
instructions.
80
Utiliser l’approche superscalaire

Intégrer prédiction de
branchement, cache, ILP,
RISC.
Exemple (le seul) : ZSP
164xx.
+ : très bonne performance,
facile à programmer, outils
supportés, taille code
raisonnable, compatibilité
binaire, …
- : problème pour prédire le
temps, consommation, …
ZSP164xx : DSP superscalaire 4-way (IO).
RISC. Deux MACs et deux ALUs. Caches.
81
Comparaison des performances
(exemple : FIR)
82
VLIW
Enhanced conv + SIMD
enhanced conventional
VLIW
conventional
Comparaison de la consommation
(exemple : FIR)
83
superscalar
VLIW
VLIW
conventional
Comparaison de la taille
mémoire (exemple : FIR)
84
Approches hybrides

Beaucoup d’applications sont un mélange de traitements de
contrôle (microcontrôleur) et de signal (DSP). Jusqu’à
récemment 2 processeurs distincts.
Utiliser un seul processeur pour implémenter les différentes
fonctionnalités : conception plus simple, réduire taille et
consommation, réduire coût du système.
Exemples : Piccolo + ARM7, Hitachi SH-DSP, Siemens
TriCore, …
85
GP à la place de EP

Ajout sur les processeurs généralistes actuelles d’extensions
SIMD (Single Instruction Multiple Data) adaptées au
traitement des applications multimédia (vidéo , audio,
graphique, animation, ...).

Exemples :
• Sun (UltraSPARC 1/2) avec VIS (Visual Instruction Set).
• Intel (Pentium I/II/III/IV) avec MMX + SSE (ajout du
flottant).
• Motorola (PowerPC) avec AltiVec.
• ...

GP peuvent exécuter des tâches de traitement du signal plus
vite...
86
GP à la place de EP (suite)
Mais coût, consommation, prévision du temps d’exécution, …
87
Applications multimédia

Applications multimédia : codage, décodage vidéo, graphisme,
audio, reconnaissance et synthèse de la parole,
modulation/démodulation.
2 classes d’applications multimédia :
• statiques : images, son, ... challenges mineurs qui seront
sans doute rapidement satisfaits. Ce que peut percevoir
l’homme est limité...
• dynamiques : vidéoconférence, graphisme 3D, animation,
reconnaissance de la parole, de l’écriture, …challenges
majeurs.
Puissance de calcul.
Intéressent “fortement” les 2 mondes... “Point de rencontre” ?
88