Co-Conception de Systèmes Spécialisés sur

Transcription

Co-Conception de Systèmes Spécialisés sur Composant
Michel Auguin
Les Algorithmes / Bâtiment Euclide B
2000 route des Lucioles, BP 121, 06903 Sophia-Antipolis Cedex
1
Michel Auguin - I3S, Université de Nice Sophia Antipolis - CNRS
Ecole Thématique sur les Systèmes Enfouis, novembre 2000
Plan de l’exposé
1 - Pourquoi la co-conception (codesign)
2 - Modélisation des applications
3 - Les architectures enfouies
4 - Estimation logicielle et matérielle
5 - Partitionnement
Partitionnement manuel
Partitionnement automatique
6 - Synthèse des communications
7 - Conclusion
2
Nombre moyen de processeurs enfouis
POURQUOI LA CO-CONCEPTION DE SYSTEMES ENFOUIS (CODESIGN)
98% des processeurs vendus en 1998 équipent des systèmes enfouis
Applications
domestiques
250
Applications
domestiques
200
150
100
Bureau
50
Automobile
1970
1980
1990
2000
[G. De Micheli]
Estimations pour l’année 2003
Téléphone/Fax
Répondeurs
Sécurité
Téléphone mobile
Portes garage
TV, set top box
Jeux vieo
Camescopes
Magnetoscopes
Instruments musique
Jouets
Réfrigérateurs/Fours
Bureau
Automobile
Téléphones
PC
Fax
Sécurité
Imprimantes
Photocopieurs
PDA
Calculateur de bord
Airbags
ABS
Sécurité
Transmission
Climatisation
GPS
Injection
1 milliard de téléphones portables
3
200 millions de PC
Divergence entre Possibilités d’Intégration et Coûts de Conception
A ce rythme on ne
pourra plus exploiter
les possibilités
de la technologie
coûts trop élevés
4
International Technology Roadmap for Semiconductors (1999)
Spécificités des architectures enfouies
Les systèmes enfouis imposent des contraintes qui conditionnent leur conception :
❏ Faibles marges de coûts (1$ sur un portable)
❏ Contraintes de temps sévères
❏ Consommation d’énergie (portables, PDA ...)
❏ Sécurité (automobile, aviation)
❏ Poids, taille (UMTS vs GSM)
La technologie permet des évolutions rapides des produits
❏ Architecture plus intégrée :
performances augmentées,
coûts de fabrication réduits
❏ Le coût global en vaut-il la peine ?
Vaste choix possibles offrant divers compromis performances/coûts
❏ RISC, DSP, ASIP, ASSP, IP, ASIC, FPGA, Analogique, MEMS
5
DSP 16, 20, 24, 32, 64 bits, Mono/MultiMac, supersclaires, VLIW
❏ Superscalaires & instructions SIMD (stations de base UMTS ?)
Les architectures des systèmes enfouis évoluent
A320
A340
1992
1982
1987
Composants numériques
77
102
115
Taille du code embarqué
4 Mo
10 Mo
20 Mo
60 MIPS
160 MIPS
250 MIPS
Puissance de calcul
20
106 dollars
DSP
16 bits
8 bits
Les solutions architecturales évoluent 10
2
1990
Dilemme du concepteur :
Architecture Généraliste ou Spécialisée ?
Spécialisation
4 bits
µcontrôleurs
Exemple : Avions Airbus
A310
2000
Meilleur rapport coûts/performances
Energie, poids, taille optimisés
Coût de conception augmentés
Flexibilité réduite
Réutilisation réduite
Correction d’erreurs coûteuse
6
Application,Technologie et Architecture évoluent,... et les Méthodes de Conception ?
Evolution des méthodes et outils de conception :
❏ Systèmes hétérogènes (RISC, DSP, ASIC, ASIP, IP)
❏ Réutilisation
❏ Exploration de solutions architecturales
SANS OUTIL DE CO-CONCEPTION
❏ Vérification et test
Effort de Conception ($)
Time to Market
AVEC OUTIL DE CO-CONCEPTION
Réduction de l’effort
de conception ($).
Time to Market
Construction de
plusieurs solutions.
Coût (mm2)
Coût (mm2)
7
Performances (µs)
Performances (µs)
Méthode d’aide à la conception : Quelle architecture, Quelles caractéristiques ?
Quel type de bus ?
Dédié, standard ?
I/Os
MPEG
DSP
Bus de données
Existe t-il un IP
MPEG2 ?
DSP VLIW ?
Quel type de DSP ?
Choix dépend des traitements
Traitements dépendent du choix du DSP
RAM
Off-core
RAM
Taille de RAM On-core / Off-core
Répartition données/code
Contrôle
Décodeur
Audio
Cache
Faut-il un décodeur spécifique ?
Exécution sur DSP ? Contrôleur ?
RAM
Quel processeur : ARM7, SH4 ?
Vitesse de l’IHM ?
Cache ? Quelle taille/gestion ?
8
Méthode d’aide à la conception : Quelle répartition des traitements
Tuner
QAM
Demod
Cond.
Access
MPEG2
Demux
Decrypt
Channel
QPSK
Tuner
QPSK
Demod
TV
MPEG2
Video
Decod
NTSC
Encod
AC3
Audio
Decod
Audio
Interf.
Control
Transport
Processing
User
Interface
Applis.
QPSK
Mod
I/Os
Dépendance Architecture/Traitements
Bus de données
MPEG
DSP
RAM
Off-core
RAM
Contrôle
Décodeur
Audio
Cache
RAM
9
Les contraintes sont vérifées ?
Les objectifs sont atteints ?
Flot classique de co-conception
Sélection types et nombres des
unités de traitement Hw & Sw
Partitionnement
Allocation des fonctionnalités
sur les unités
Ordonnancement
Sélection et synthèse des
supports de communication
SW
Génération
de code
temps réel
Synthèse des interfaces
Hw et Sw
HW
Synthèse VHDL
Contraintes temporelles, consommation, surface
VERIFICATION
Spécification
10
Plan de l’exposé
5 - Partitionnement
7 - Conclusion
11
MODÉLISATION DES APPLICATIONS
Spécification initiale
Avant tout : Modéliser
Validation
Transformations
Raffinements
Spécification
Langage ?
Modèle ?
Validation
Transformations
Raffinements
Spécification
Processus Top-Down de Conception
Spécification d’implémentation
Validation
12
Les applications sont hétérogènes : Approche pragmatique
❏ Utiliser un langage adapté en fonction du niveau de spécification
(e.g. VHDL pour décrire un système matériel niveau RTL)
❏ Mais changer de modèle dans le processus de conception peut poser des difficultes.
Exemple :
Modèle réactif synchrone
Temps implicite (événements)
Modèle abstrait
Preuves de
propriétés
Sémantique ?
Synthèse
Temps explicite
Evénements estampilliés
Modèle de description
du processus physique
Modèle VHDL
Simulation
Placement/Routage
13
Modèle d’implémentation
Les applications sont hétérogènes et parallèles. Comment les prendre en compte ?
Sous-système 1
Langage 1
Transformations
Représentation
interne
Sous-système 2
Langage 2
Transformations
Représentation
interne
Optimisation - Validation
La spécification est décomposée en sous-systèmes (manuellement)
Approche “langage”
Sous-système n
Langage n
Transformations
Représentation
interne
Environnement de validation : cosimulation
Cosimulation C - VHDL
Cosimulation Assembleur (ISS) - VHDL
❏ Aucune optimisation globale : optimisations par sous-système (dépendant langage)
❏ Nécessite de décrire précisément les communications et les interfaces
❏ Les migrations éventuelles entre sous-systèmes ne sont pas aisées
14
Approche “modèle”
Sous-système 1
Modèle 1
Optimisations
Optimisations
Validations
Sous-système 2
Modèle 2
Optimisations
Sous-système n
Modèle n
Optimisations
Environnement d’acceuil (modèle)
Outils de conception
Transformations
par modèle
Cosimulation
❏ Optimisations locales et globale
15
❏ Exploration de l’espace de conception plus aisée
❏ Les communications et interfaces sont décrites de manière plus abstraite
Modélisation d’une application hétérogène
❏ Quel(s) modèle(s) pour décrire la spécification initiale ?
Ce choix est guidé par plusieurs considérations, par exemple :
• Type de traitements dans l’application
• Possibilité d’exécuter ou d’animer le modèle
• Disponibilité et efficacité des outils d’analyse et de synthèse
Preuve formelle de propriétés - Simulation - Synthèse/Compilation
• Possibilité de décrire des spécifications non-fonctionnelles
• Intégration dans un processus complet de conception (sans rupture)
Verticale
Les raffinements par transformations
ne nessécitent pas de changements
de modèles qui impliquent le concepteur
Horizontale
Possibilité d’effectuer des vérifications
entre plusieurs modèles décrivant
différentes parties du système
(par exemple temps continu et temps discret)
16
Choix du modèle de spécification en fonction du type de l’application
Classiquement les concepteurs considèrent qu’un système est dominé :
Par le contrôle
Réactions à des événements discrets :
Pas d’hypothèse sur l’occurence des événements
Tous les événements doivent être pris en compte
Systèmes à événements discrets
Systèmes réactifs synchrones
Machine d’Etats Finis
Réseaux de Petri
Processus concurrents
Contrôle/Commande de processus
Par les données
Les sorties sont fonctionnellement dépendantes des entrées :
Kahn Process Networks
Dataflow Process Networks
Les occurences des valeurs sur les entrées sont périodiques
17
Traitement du signal et des images
Langages associés aux modèles
Esterel, Lustre, Signal, ECL
VHDL, Verilog
Machine d’Etats Finis
*Charts (StateCharts, ...)
Processus concurrents
CSP, Occam, Lotos
Kahn Process Networks
Dynamic Data Flow
Synchronous Data Flow
Approche objet
Java, C++, OO-VHDL
Codesign Finite State Machine
SDL (Standart de l’ITU)
Exemple d’outils associés:
VCC de Cadence : asynchronisme des CFSM, C, C++, ECL
CoCentric de Synopsis : SystemC - Classes C++ pour décrire réactivité, processus concurrents
CoWare : Classes C++ pour décrire des processus concurrents (RPC)
18
Environnements pour applications hétérogènes
Un seul modèle de calcul est insuffisant pour décrire toute l’application
Deux approches proposées :
Langage et sémantique pour
accueuillir différents
modèles de calcul
Plusieurs modèles de calcul intégrés
dans un même environnement
ROSETTA
Projet de l’initiative SLDL
System Level Description Language
http://www.inmet.com/SLDL/
PTOLEMY
VHDL-AMS
Machines d’Etats Finis hiérarchisées
Processus communicants
SPW, COSSAP, CoWare, Matlab
19
Hormis les techniques à base de cosimulation, il n’existe pas actuellement
de méthodes de conception unifées qui opèrent sur une description hétérogène.
Conception verticale par domaine (modèle de calcul)
Approche traditionnelle :
Décomposition en sous-systèmes et conception verticale
Processus
de conception
Niveaux d’abstraction
Vérification des erreurs intra-domaine
Implémentation
Intégration
Domaine
1
Domaine
2
Domaine
3
Domaine
4
Vérification des erreurs inter-domaine :
❏ Intégration explicite : communications inter-domaine
❏ Cosimulation
[www.vptinc.com]
20
Evolution souhaitée des méthodes de conception
Approche intégrée :
L’environnement permet des raffinements “sans coutures”
Processus
de conception
Niveaux d’abstraction
Vérification des erreurs intra-domaine
Implémentation
Intégration
Domaine
1
Domaine
2
Domaine
3
Domaine
4
Vérification des erreurs inter-domaine :
❏ Communications inter-domaine : types prédéfinis
❏ Vérifications sémantiques
21
[www.vptinc.com]
Représentation d’informations non-fonctionnelles.
La description d’un système : comportement + informations non fonctionnelles
par exemple des contraintes : temps, surface, consommation, time-to-market...
Exemple dans la norme de communication Bluetooth
❏ Temps d’exécution global à considérer = 312,5 µs,
c.a.d. une demi-fenêtre : 2 paquets peuvent être produits
par fenêtre de 625 µs.
❏ Contrainte sur la partie bande de base :
321,5 - (Tvco + Tpower_up + Tuncertainty_window + Taccess_code)
❏ Consommation et surface minimum, coût réduit
Plusieurs modèles ou langages sont étendus pour décrire des contraintes
Exemple 1 : Langage ROSETTA (SLDL)
Types physiques et opérations associées : spécification des contraintes
Un système = composition de facettes : contraintes du système
22
Exemple 2 : Modéle SPI, Single Model with Intervals (Université de Braunschweig)
En SPI un système est un ensemble de processus communicants
Communications par :
FIFO : lecture destructive, écriture non-destructive
Registre : lecture non-destructive, écriture destructive
latp1
r1
P1
Ap1
latc1
s1
C1, C2
latp2
r2
C1
dc1,init dc1
P2
latx : temps de latence
s2
dx : nombre de jetons
Ap2
sx : jetons produits
C2
Ax : règle d’exécution
rx : jetons consommés
P1 : Si m1,1 ^ C2.tag = y
Les jetons peuvent être étiquetés (tag)
Les processus : différents modes (mi,j)
alors m1,2 ; s1= 2; C1.tag = z ; latp1=3ms
P2 : Si m2,1 ^ C.tag = z
alors m2,2 ; s2= 1; C2.tag=y; r2=1; latp2 = 1,5ms
23
Contraintes temporelles : LC (C1,C2) = [latmin,latmax]
Analyse statique des séquences possibles d’exécution (recherche de cas pire)
Plan de l’exposé
5 - Partitionnement
7 - Conclusion
24
ARCHITECTURES ENFOUIES
Les méthodes de codesign ciblent généralement des systèmes embarqués/enfouis (SOC)
Ces systèmes impliquent des contraintes :
Mais il faut aussi privilégier :
produits largement diffusés : coûts réduits
la réutilisation
contraintes temporelles strictes
la flexibilité : modifications tardives,
corrections d’erreurs
consommation d’énergie
taille, poids
sûreté de fonctionnement (e.g. aéronautique)
MOPS/mm2
MOPS/mW
MOPS/kg
Flexibilité
Performance
Architecture
complètement
spécialisée
Architecture
usage général
25
Recherche de compromis
Très grande diversité des composants
❏ Les systèmes embarqués deviennent de plus en plus complexes.
Le nombre de cœurs de processeurs dans un SOC de 1996 à 1998 chez IBM :
1996 : 2 en moyenne, 3 max
1998 : 9 en moyenne, 30 max
❏ Grande variété de composants disponibles :
Cœurs de processeurs
Fonctions logicielles
Fonctions matérielles (ASIC)
Bus standardisés
IP: Intellectual Property
ASIP : Application Specific Instruction-set Processor
ASSP : Application Specific Standard Product
Microcontroleurs
RISC
DSP : Digital Signal Processors
26
Composants reconfigurables
SPGA : System Programmable Gate Array - FPGA + IP)
ASIP et ASSP
ASIP : Application Specific Instruction set Processor
❏ Processeur spécialisé à l’exécution d’une (ou quelques) application (par exemple Modem)
❏ Jeu d’instruction et ensemble des ressources adaptés à l’application
❏ Meilleurs rapports MIPS/mW et MIPS/mm2 que RISC et DSP
❏ Mais compilateur plus délicat, time-to-market plus long qu’avec des processeurs standards
ASSP : Application Specific Standard Product
❏ Composant complexe qui réalise une fonction spécifique (compression vidéo, modem)
❏ ASSP et interface standardisée : IP
27
Les Processeurs embarqués RISC
Grande variété de processeurs RISC disponibles sous forme d’IP (ARM, Hitachi, MIPS, LSI Logic)
Exemple : RISC 32 bits de Advanced Risc Machines (ARM) : Famille ARM7 : 3 étages de pipeline
Surface
ARM7TDMI
0,54
ARM7TDMI-S
synthétisable
ARM7720T
0,8
mm2
Puissance
Horloge
MIPS
Cache
0,25mW/MHz
110 MHz
59 MIPS
-
-
-
-
8k unifié
mm2
2,9 mm2
0,65 mW/MHz
75 MHz
ARM7TDMI : Thumb Instruction Set
Compression sur 8 ou 16 bits d’une partie des instructions 32 bits
Décompression à l’exécution
Espace mémoire
réduit de 30%
Famille ARM9 : 5 étages de pipeline
2,7 mm2, 1,8 mW/MHz, 160MHz, 176 MIPS en 0,25 µm
28
Processeurs disponibles sur le Web : OpenCore, Leon
Processeurs embarqués RISC et mémoire cache : recherche de compromis
Choix des vitesses relatives
cache/mémoire
Performance des caches
Surface
Taux de “hit”
Mémoire rapide
Cache
Taille de cache
Temps
accès
DRAM
Mémoire lente
Taille de blocs
surface du cœur
Surface totale
solution avec mémoire rapide
et cache petite taille
Taille mémoire
Application
Taille
Quelle taille et quelle gestion de cache pour optimiser :
Performances
Performances
mm2
mW
29
2
Surface cœur ARM720T : 0,54 mm
Surface cache 8K octets : 2,3 mm2
Les processeurs de traitement du signal DSP
Il existe de nombreux constructeurs : nombreux DSP et leurs variantes chez chacun d’eux
DSP virgule fixe 16
bits
DSP568xx, C54x, ADSP21xx, OakDSP,
DSP16xx, Carmel, PalmDSP
Les plus communs.
(Télécom. embarqué)
DSP virgule fixe 20
bits ou 24 bits
DSP563xx, PalmDSP
Applications audio
DSP virgule fixe et
flottante
TigerSharc
Calcul intensif, précision
DSP flottant
ADSP2106x, C30,C40
Précision
DSP superscalaire
TigerSharc (4) , StarCore (6)
Calcul intensif
DSP VLIW
C62xx, C67xx (8), TriMedia (5), REAL (instructions ASI), Carmel (instructions CLIW)
Calcul intensif. Traitement //
sur octets
DSP flexible
REAL (unités AXU)
Unités fonct. dédiées
DSP hybride
Tricore, ST100
Applications diverses
Un DSP peut étre particulièrement adapté à un type d’application (exemple : DSP56009, TMS320C54x)
Les performances des DSP peuvent varier significativement :
exemple : localisation des données en mémoire, localisation du code
30
Les performances des DSP sont très variables
Mesure de performance
des DSP : BDTImark™
Source:
Berkeley Design Technology, Inc.
Temps exécution de 12
applications test
(pas de compilation)
Mesure de performance
Performances très variables
Choix DSP important
31
Un système : ensemble d’unités interconnectées
L’interconnexion devient un problème crucial dans la conception de circuits complexes
“Interconnect performance bottleneck”
Les constructeurs de SOC s’orientent depuis quelques années vers l’utilisation
de bus génériques : protocoles de transferts de données bien définis.
Exemple la proposition AMBA de ARM : Advanced Microcontroller Bus Architecture
Bus Système : AHB ou ASB
bus rapide, multi-maître, transferts pipelines ou en mode burst,
priorité sur les transferts
Bus Périphérique : APB
bus adapté à la connexion de périphériques “lents”,
non-pipeline, pas de priorité, optimisé en consommation
Interfaces entre bus : Bridges
La conception d’interface de communication est réduite
32
Les temps de communication dépendent des bus et des modes de transfert utilisés.
Système d’exploitation temps réel embarqué
Cond.
Access
QAM
Demod
MPEG2
Demux
Decrypt
Channel
QPSK
Demod
AC3
Audio
Decod
Audio
Interf.
Control
Transport
Processing
User
Interface
Applis.
τ2
QPSK
Mod
on/
Autentification
Set-top-box
s1
F
τ3
τ6
Alert
a/c
Tmax(τ5)
T
T
τ1
Select
QPSK
Tuner
NTSC
Encod
Switch
Tuner
TV
MPEG2
Video
Decod
τ4
τ5
F
c
of/
s2
a/c,b
a/c
¬a
a
s2
s2
¬a/b
s1
Start Menu Message
¬a/c
s2
¬a
Stop
Hétérogénéité des traitements :
Ensemble de tâches ayant leurs propres
caractérisitques et leurs propres contraintes temporelles
33
Pay
Interactive
Services
Play
FFw
Rw
Video
on Demand
Pause
Gestion des tâches par exécutif temps réel (RTOS)
Le comportement du système dépend des caractéristiques du RTOS
Non préemptif
p1
ou préemptif ?
p2
p1
p2
t
t
Ordonnancement statique ou dynamique ?
❏ ordonnancement dynamique : actuellement peu ou pas d’analyse du comportement global
❏ ordonnancement statique : quel politique ? Rate monotonic, Earliest Deadline First, ...
Pb de l’nversion de priorité
Priorité (p1) > Priorité (p2)
p1 & p2 : ressource commune R
p1
34
p2
t
Changement de contexte entre deux tâches : consomme du temps
Choix de la granularité des tâches, choix des événements
Ordonnancement avec réduction de la consommation d’énergie
Passer de actif <-> mise en veille d’un processeur nécessite du temps
on
Processeur1
Processeur2
1
on
off
2
3
on
off
4
5
on
Processeur1
1
on
off
2
3
Processeur2
5
4
Ordonnancement monoprocesseur ou distribué ?
Analyse comportement global avec ordonnancement distribué : plus délicat
Peu de vérification de propriétés : exemple toutes les tâches vérifient elles leur deadline ?
35
Conclusion sur les architectures
❏ Concevoir les architectures embarquées à partir des composants les mieux adaptés
vis à vis des traitements à éxécuter
❏ Objectifs : globalement performances, consommation, time-to-market,... sont optimisés
❏ Hétérogénéité et évolution des composants : microcontroleur, DSP, ASSP, ASIP
Stations de base UMTS : DSP VLIW ou multi-MAC ou superscalaire + SIMD ?
Portable UMTS : RISC + DSP basse consommation + reconfigurable + accélerateurs HW
Migration progressive des accélérateurs dans le chemin de données du DSP
❏ Des constructeurs proposent des architectures mixtes
Philips/VLSI Technology VVS3771 : ARM7TDMI + OakDSPCore
Motorola DSP56651 : RISC M-CORE + DSP56600
❏ Optimiser l’organisation et l’utilisation de la mémoire des composants
La mémoire sur le composant : rapide mais coûteuse en surface
Accès en mémoire externe au composant : moins cher mais plus lent et plus coûteux en énergie
Défaut de cache : consomme environ 6 fois plus d’énergie qu’une opération ALU
36
❏ Manque d’efficacité des compilateurs pour les processeurs DSP, ASIP
Evolutions ? architecture plus régulière, progrès en compilation
Spécialisation diminue : performances/mm2 diminue aussi
❏ Le comportement global dépend de l’exécutif temps réel (RMS, EDF, ...)
❏ Adéquation Algorithme/Architecture
Choix des couples <fonctions, composants>
Algorithme plus rapide sur composant plus lent ?
❏ Devant la diversité des solutions, choisir les composants d’un système est délicat
❏ Est-ce que le système va satisfaire les contraintes temporelles de l’application ?
❏ Peut-on trouver une solution plus optimisée en surface, en consommation ?
❏ Le time-to-market est-il allongé ?
❏ L’architecture est-elle aisément testable ?
❏ Est-elle flexible pour supporter des corrections d’erreurs, des évolutions ?
37
Plan de l’exposé
5 - Partitionnement
7 - Conclusion
38
ESTIMATION LOGICIELLE ET MATÉRIELLE
Pour guider le choix des composants et l’allocation des traitements il faut connaître les
caractéristiques de mise en œuvre des traitements sur ces composants.
Traitement
Composant
Temps exécution
Modèle d’implantation
Surface, Taille mémoire
Consommation
Deux cas :
❏ Modèles d’implantation connus :
IP précisément caractérisés
Code optimisé disponible
Cas pire identifié
❏ Modèles d’implantation non disponibles:
On fait le pari que cela va marcher
On utilise des techniques d’estimation
performances, consommation, surface
Estimation Logicielle
39
Estimation Matérielle
Estimation logicielle
L’estimation logicielle est très utile pour les DSP :
❏ Les taux d’expansion des compilateurs pour DSP sont très variables (de 1 à 50 )
❏ Il existe une grande variété de DSP, le choix du DSP est sensible
Estimation par compilation/exécution-simulation
Code source
Compilation
Séquence
de test
❏ Temps d’exécution :
Tailles code, variables
Exécution
Mesures
Simulateur
niveau instruction
Processeur hôte
avec annotation
CFG - code source
Temps exécution
Cas pire ?
❑ thérorique
❑ pratique
❏ Mesure en simulation :
plusieurs heures/jours
40
Estimation du temps d’exécution maximum : Approche par programmation linéaire
[Malik 95]
Flux entrant = Flux sortant
d1
x1 = d1 = d2
x2 = d2 + d3 = d4 + d5
x3 = d5 = d6
x1
i=0
d3
d2
While i<nb_pass x2
d5
j=0
d4
x3
d7
d6
While j<nb_grp x4
d8
x1.c1 + x2.c2 + ... + x9.c9 Maximum
d9
x5 nb_grp=nb_grp*2
i++
Contraintes
structurelles
x8 = d12 = d7
x9 = d13 = d11
x2 = nb_pass * x1
x4 = nb_grp * x3
x7 = nb_btfl * x6
k=0
(ci = nb cycles pour exécuter le bloc i)
x6
d11
Surestimation de 500% pour N = 1024
d10
x7 While k<nb_btfl
d12
d13
x8
nb_btfl=nb_btfl/2
j++
Ajout de 2 contraintes :
nb_grp * nb_btfl = N/2
x6 = N * x1
x9 k++
nb_pass = log2(N)-1
nb_grp = N/2 -1
nb_btfl = 1
Contraintes
fonctionnelles
On obtient les valeurs des xi correctes
41
Estimation avec cache d’instruction
[Malik 95]
Exemple avec 3 blocs de base
Bloc
B1
B1,1
B1,2
B1,3
B2,1
B2,1
Lignes de
cache
Ligne de
cache
Bloc
B2
Blocs de base
0
B1,1
B3,1
1
B1,2
B3,2
2
B1,3
Conflits
B2,1
B2,1
3
Contraintes supplémentaires
Bloc
B3
hit
B3,1
pi,j;i,j = xi,j
s
B3,2
p1,3;1,3
ps;1,3
ps;2,1
p2,1;1,3
B1,3
p1,3;e
B2,1
p1,3;2,1
e
p2,1;e
p2,1;2,1
xi = Σ pu,v;i,j = Σ pi,j;u,v
u,v
pi,j;u,v ≤ min(xi,xu)
Σ ps;u,v = 1
u,v
42
La méthode suppose les valeurs des ci connues.
Estimation logicielle : Estimateur reciblable
Code source
[Malik 95]
Séquence
de test
Valeurs des xi
Compilation
+ exécution
des contraintes
fonctionnelles
“constantes”
Analyse
statique
ILP Solver
Valeurs
des ci
Estimateur
Recyblable
des ci
Description
Processeur
Estimations
[Ernst 97]
[Pegatoquet 99]
[Ghazal 00]
43
Estimateur reciblable: VESTIM (I3S - Philips Semicondutors Sophia)
Code C
Compilateur pour DSP basé sur GNU C
Génération
Représentation intermédiaire
(RTL)
Traitements générés
inutiles
Optimisation des boucles
Opérations arithmétiques
sur adresses dans
boucles régulières
Analyse flots de données
Décalage de 1 après
multiplication
Décalage pour accéder
partie haute d’un mot
Allocation des registres
Spilling : cause d’environ 30%
du taux d’expansion.
Ordonnancement instructions
44
Code Assembleur
[Pegatoquet 99]
Estimateur reciblable : VESTIM
Description RTL du code
Représentation par CFG / DAG
Orientée “RISC”
Règles de réécriture
suppression traitements inutiles
Représentation DAG
Orientée “DSP”
Description
processeur cible
List Scheduling
Annotation par priorité
Opérations exécutables en //
➪ même priorité
Ordonnancement
Allocation
Description macroscopique
Estimation
xi*ci
Seules les ressources utiles
à l’estimation
e.g. registres abstraits
45
Ordonnancement au niveau opération (adapté aussi aux DSP VLIW, multi-MAC)
Estimateur reciblable : VESTIM
Demi-papillon de la FFT
MAC
Val
XRam
Const
5
CG
@indirect
5
Val
XRam
Align
4
Mpy
3
4
P
Val
YRam
Val
XRam
Mpy
Shft
Add
ALU
3
MAC
1
Shift
3
Bit
Op.
ACC
2
Y
MPY
P
Add
3
X
@indirect
@indirect
Add
Const
Bus Y
Bus X
4
4
5
ACC
3
Val
YRam
3
Mux
A0
A1
Sub
Assign
XRam
1 Assign
YRam
ACC : A0 ou A1
OakDSPCore
46
List-scheduling avec insertion en-tête
Résultats d’estimation
Nb lignes de code
C
(x 1000)
Code ASM
optimisé
(MIPS)
Code ASM
généré
(MIPS)
Code estimé
(MIPS)
Durée
Encodeur G728
1,1
23
62,3
26,7
2s
G729
5,6
12,2
21
15,7
1,5 mn
G723.1
2,7
23,5
32
22
2 mn
Décodeur audio AC3
4
39,5
75
32
1 mn
Modem V22bis
19
4
10
5,2
1s
Les estimations d’un code assembleur optimisé sont précises
L’architecture reste assez simple (pas de cache, parallélisme ILP intra-bloc de base)
47
Conclusion sur l’estimation
La complexité des architectures rend difficile le problème de l’estimation
Estimation logicielle :
Aléas de pipeline, lancement dynamique des instructions, superscalaire
Hiérarchie mémoire : caches, répartition des données
Système d’exploitation, communications (DMA)
Des approches existent pour des cas simples
Approche pratique : mesures sur l’architecture elle-même : développer le code
Estimation matérielle :
Estimation temps à opérateurs connus ou estimation opérateurs à temps fixé
Influence du placement/routage, influence de la technologie
Approche IP caractérisé avec précision : disponibilité ? (e.g. rake receiver UMTS)
Et pourtant avec des estimations précises, la conception devient plus simple et rapide
Au LESTER : Estimation hiérarchisée
48
Estimations systèmes : caractérisation macroscopique
Estimation architecturale : caractérisation détaillée
Plan de l’exposé
5 - Partitionnement
7 - Conclusion
49
PARTITIONNEMENT
Sélection types et nombres des
unités de traitement Hw & Sw
Partitionnement
manuel/interactif
automatique
Allocation des fonctionnalités
sur les unités
Ordonnancement
Sélection et synthèse des
supports de communication
Réduction difficulté
par utilisation d’IP
Synthèse des interfaces
Hw et Sw
HW
Synthèse VHDL
SW
Génération
de code
temps réel
Contraintes temporelles, consommation, surface
VERIFICATION
Spécification
ESTIMATIONS
Flot classique de conception
Problème peu abordé
(temps vs surface vs consommation)
50
Partitionnement manuel : CoWare
Conception de SOC par partitionnement manuel : utilise généralement la cosimulation
Exemple : l’environnement CoWare
Spécification
Simulation fonctionnelle
Processus concurrents (RPC)
C/C++
Architecture
Partitionnement
Manuel
Code C
Connexions point à point
Synthèse
Interfaces
Code VHDL
Cosimulation
51
Partitionnement manuel : Tima/Arexsys
Environnement de conception à partir de SDL : Specification & Description Language
❏ Standard ITU-T
❏ Langage graphique : Processus communicants, par passage de messages
❏ Description de protocoles
Spécification SDL
Partitionnement Manuel
Architecture
Cosimulation VHDL-C
VHDL
C
C
vhdl2c
Simulateur
Codes C
Allocation HW/SW Manuelle
ASIC
µcontrôleur 1
µcontrôleur 2
Cosimulation “cycle true”
Connections de simulateurs
Communications, estampillage
52
Partitionnement manuel : exemple l’environnement POLIS (Berkeley)
❏ POLIS : environnement de codesign pour des applications orientées contrôle/commande
Spécification : CFSM
FSM, Esterel
Ptolemy
Co-simulation
Estimations
Partitionnement
manuel
Vérification formelle
VIS, [Balarin-99]
Spécification partitionnée
Synthèse Hw
Synthèse Sw
Synthèse
interfaces
Représentation
interne
S-graph
Synthèse OS
FSM
Code C des tâches
Hw optmisé
53
Code C global
Modèle CFSM de POLIS
1) Un module : Machine d’état étendue
événement = <valeur,instant d’occurence>
2) réseau de modules (avec partitionnement)
localement synchrone, globalement asynchrone
Wait
Key =On =>
Start
End = 5 =>
Alarm = On
M2
Key =Off or
Belt = On
Alarm
OFF
End = 10 or
Belt = On or
Key = Off =>
Alarm = Off
M1
Synchrone
HW
M3
Comportement réactif synchrone
Vivant
3) Analyse de l’ordonnançabilité
Etimations temps exécution
Politique d’ordonnancement
Ensemble de contraintes temporelles
Aucun événement perdu ? [F. Balarin]
Polling
IRQ
Gelé
SW
RTOS : RMS, EDF
54
Réseau de Modules : outil VCC de Cadence
Description d’un Module : C, C++ ou ECL
Conception manuelle vs cosimulation vs partitionnement
SANS OUTIL
COSIMULATION
PARTITIONNEMENT AUTOMATIQUE
EXPLORATION ESPACE CONCEPTION
Effort de
Conception ($)
Effort de
Conception ($)
Coût (mm2)
Performances
Performances
Performances
Effort de conception
Réduit ($).
Construction de
Effort de conception
Réduit ($).
55
Partitionnement automatique : nombreuses techniques proposées
Comparaisons de quelques techniques
Modèle/Granularité
Architecture
Objectif
Technique
Contrôle
Nombre
solutions
COSYMA [Ernts 93]
C étendu/Instruction
Figée: 1 proc. 1
Asic
Temps
Recuit Simulé,
SW -> HW
nonpréemptif
compile time
1
Vulcan [De Micheli 94]
C/Instruction
Figée: 1 proc. 1
Asic
Temps
HW -> SW Glouton
nonpréemptif
1
GCLP [Kalavade 94]
DFG/Tâche
Figée: 1 proc. 1
Asic
Temps/Surface
List scheduling
modifié
nonpréemptif
compile time
1
[Vahid 97]
C/Fonction
Figée: 1 proc. 1 Temps/Surface/
Asic
IO
Min Cut
nonpréemptif
compile time
Exploration
[Teich 97]
C/Fonction
Algorithme génétique
?
Exploration
COSYN [Dave 97]
Graphe de tâches
Clustering
préemptif/nonpréemtif
1
[Karkowski 98]
[Kuchcinski 99]]
C/boucles
multi-ASIP
Temps/nb proc.
Enumération
séquentiel
Exploration
DFG/Tâche
SOC
Temps/Surface
Prog. par contraintes
compile time
Exploration
[Li 00]
SynDEx [Sorel]
C/boucles
1 proc. 1 FPGA
Temps
Clustering
compile time
1
DFG/Tâche
multiprocesseur
Temps
List Scheduling
modifé
nonpréemptif
compile time
1
[Oh 99]
[Wolf 95]
SOC
Temps
Multiprocesseur Temps/Consommation
56
Graphe de Tâches
multiprocesseur Temps/Surface Ordonnançabilité
préemptif
1
Graphe de Tâches
multiprocesseur Temps/Surface Ordonnançabilité
préemptif
1
Méthode développée dans CODEF (I3S - Philips Semiconductors Sophia)
Description de l’application
Graphe de flots de données conditionnels
♦ Architectures candidates
♦ Librairies unités Hw & Sw
♦ Allocation tâches sur architecture
Partitionnement
♦ Contraintes
♦ Ordonnancement des tâches
♦ Paramètres exploration
♦ Architecture prédéfinie
optionnelle
Synthèse
Communications
Spécification
partie matérielle
Spécification
Interconnexion
Spécification
partie logicielle
CODEF opère en deux étapes
♦ Partitionnement/Ordonnancement : exploration de l’espace de conception
♦ Synthèse des Communications : ressources, protocoles pour réaliser les transferts
57
Problèmes : sélection architecture/partitionnement/ordonnancement
Graphe flots de données
A
Allocation et ordonnancement ?
C
D
B
P1
Quelle Architecture ?
coprocesseur
coprocesseur
1
4
5
MPU
P1
B
P2
A
D
C
2
P1
B
P2
A
3
DSP
Eléments architecturaux dans un SOC :
♦ RISC, DSP, coprocesseurs, accélérateurs Hw
♦ Mémoires locales/externes : data & programme
♦ Caches
♦ Ports I/O, caractéristiques des bus ...
❷
MPU
MPU
DSP
DSP
D
B
P2
2
1
3
C
MPU
DSP
❶
A
0
C
D
Temps
Contrainte
de Temps
Ordonnancement statique non préemptif
58
Modèle de l’application dans CODEF
Graphe de flots de données conditionnels (C-DFG)
c2
B
e0
c3
a,b
A
FSM (node A):
a/c0
e0
¬b^a/c1c2
1
a^¬b/c1c3
a/c3
s1
s2
c4
s3
E
Tmax=1000
F
Tmax=1000
K
Tmax=1000
L
c6
¬a^b/
s1
1
e1
¬a^¬b/c0
2
c3
0
Switch
input
D
C
Switch
s0
¬a/c2
b/c2
1
c1
c0
0
Switch
♦ Exemple :
Select
0
s0
Switch
c1
Tmax=1000
a,b,c4,c5 ,c6: external signals
(c4,c5) ≠ (1,1)
G
s2
Application de traitement du signal
(SPW, Ptolemy)
1
H
s3
J
Switch
e1
Select
Switch
0
2
59
I
Les nœuds des FSM ont la sémantique DFG :
une seule transition à chaque activation du FSM.
c4
c5
c6
Librairies des modèles d’implantation
A
input
b/c2
a^¬b/c1c3
a/c3
2
¬a^¬b/c0
Switch
Tmax=1000
G
1
E
C
0
K
0
Switch
1
D
1
H
J
Switch
¬b^a/c1c2
1
Select
a/c0
0
Switch
FSM (nœud A):
B
Select
Switch
0
¬a/c2
Tmax=1000
c3
c1
c0
2
Switch
a,b
F
Tmax=1000
Tmax=1000
Tmax
L
Contraintes
temporelles
I
c4
¬a^b/
c5
c6
a,b,c4,c5 ,c6: signaux externes
(c4,c5) ≠ (1,1)
♦ Librairies:
Surfaces des cœurs
Sw1
6.66
Sw2
6.35
HwA HwD HwE HwF HwK HwL
2.31 0.59 1.82 1.89 1.91 1.83
Caractéristiques des modèles d’implantation.
Nodes
A
B
C
D
E
F
G
H
I
J
K
L
Sw1
329/1.16
410/1.55
324/0.21
328/1.17
385/0.97
402/0.77
379/0.67
357/1.15
435/0.94
292/0.11
300/1.13
339/0.90
Sw2
409/1.09
250/1.10
188/0.42
458/1.40
346/1.33
318/1.04
283/0.84
432/0.93
407/1.17
264/1.02
371/0.87
257/1.06
HwA
38
HwD
HwE
HwF
HwK
HwL
44
53
74
60
70
69
Temps exécution/surface mémoire. Temps exécution des accélérateurs
Principe de partitionnement d’un C-DFG
Objectif : Simplifier le problème
C-DFG
Analyse des comportements
Analyse des états et sorties
des FSM
Identification
comportements “critiques”
(DFG)
Quels états doivent être
considérés
Partitionnement des
comportements “critiques”
On se ramène au cas du
partitionnement de graphes
de flots de données
61
Partitionnement de graphes de flots de données statiques (DFG)
♦ On considère une heuristique basée sur le List Scheduling
Phase d’Analyse
Analyse
DFG
Phase de Synthèse
Tâches
ordonnançables
• Chemins longueur Minimum et Maximum *
Sélection tâche
la plus critique
Allocation et
Ordonnancement
Mesures globales
• Urgence temporelles des tâches
• Surfaces pondérées des unités
Path Analysis Partitoning Algorithm (PA2)
[Bianco-99]
* Extension de [P. Bjørn-Jørgensen, J. Madsen - 1997]
62
Phase d’analyse de PA2
♦ Evaluation récursive des longueurs des chemins
∀τi une tâche et ∀ uk une unité (HW ou SW)
pl
 tc
(τ , u ) = t
( τ , u ) + Max  Min
( τ , τ ) + pl
( τ , u ) 

min i k
exe i k
τ j ∈ succ ( τ i ), u l  u k, u l i j
min j l  
Exemple simplifié
1
τ1
Temps d’exécution des
tâches sur 3 unités
1
τ2
τ5
2
5
τ3
Temps de communication
si τ1 et τ5 sont allouées
sur différentes unités
2
τ7
τ6
Chemin depuis τ5
10
τ4
Tâche
τ1
τ2
τ3
τ4
τ5
τ6
τ7
U1
U2
U3
2
4
6
5
3
6
3
1
1
2
3
3
2
1
2
3
3
4
2
3
1
63
plmin(τ5,U1) = 3 + Max(Min((0+6,2+2,2+3),Min(0+3,2+1,2+1)) = 7
Phase de synthèse de PA2 : Urgence temporelle
♦ Allocation de τ4 sur U3
plmax
τ1
τ2
τ3
τ5
τ4
plmin
Disponibilité
des données
τ6
τ7
U1
τ1
1->3
U2
τ2
2->3 2->4
U3 ..................... τ3
Disponibilité
de U3
Contrainte
Temporelle
Temps disponible
de τ4 sur U3
τ4
Ta(τ4,U3)
plmin(τ4,U3)
Ta(τi,uk) = Max (Disponibilité data, Disponibilité uk)
plmax(τ4,U3)
• Comparaison de Ta(τi,uk) avec plmin et plmax ➱ Mesure de l’urgence de τi sur uk
64
Phase de synthèse de PA2 : Surface pondérée
♦ Unités logicielles
Tâche τi allouée sur unité logicielle uk :
Surface fonctionnelle σ(τi,uk)
= Σ des tailles RAM et ROM
Variables de τi
τ3
τ2
τ1
Surface ROM
∑
τ3
τ2
τ1
Code + constantes de τi
σ ( τ i, u k )
tâche τ sur u
i
k
Surface RAM
Surface Pondérée
s ( u ) + Σσ ( τ , u )
k
i k
S ( τ , u ) = ---------------------------------------------i k
β(τ , u )
i k
Surface du cœur s(uk)
65
Facteur de pondération pour tenir compte de la
réutilisation potentielle de uk dans l’intervalle Ta(τi,uk)
Phase de synthèse de PA2 : Algorithme de partitionnement
Ensemble des (τi,uk) / τi ordonnançable
uk existe dans l’architecture
Pas d’urgence
Liste L1reuse
urgence < Treuse
uk est une nouvelle instance
urgence ≥ Treuse urgence < Tnew urgence ≥ Tnew
Liste L2reuse
Listes triées par ordre décroissant de l’urgence
Liste Lnew
Liste Lothers
Listes triées par ordre décroissant de Ω
Selection dans les listes de la meilleure implantation de la tâche la plus critique
66
Ω = α(urgence relative) + (1-α)(surface pndérée relative)
Tnew, Treuse, α: trois paramètre définis par l’utilisateur
Phase de synthèse de PA2 : Exploration automatique de l’espace de conception
♦ L’algorithme de partitionnement/ordonnancement est récursif
A l’exécution N les variations minimum sur Tnew and Treuse sont calculées
telles qu’à l’exécution N+1 une allocation différente soit réalisée
♦ L’algorithme construit un ensemble de solutions qui correspondent à différentes
répartitions des tâches dans le temps (ordonnancement) et/ou dans l’espace (allocation)
Construction de
Coût (mm2)
67
Performances (s)
Partitionnement statique : Exemple d’un décodeur audio AC3 (3 canaux)
mantissas (16 bits)
256
256
5 bits
C1
256
4 bits
C2
256
7 bits
Left
256
256
L0
256
L1
R0
256
R1
256
256
18 bits
Coupling
216 G0
216
Exp: Exponent
BA: BitAlloc
G1
3
512
18 bits
R2
216
216
G2
216
18 bits
DM : Decode
Mantissas
C5
256
18 bits
256
L2 18 bits
256
256
Right
256
256
18 bits
4
RX: Rematrixing
C0
DC: Decoupling
Center
256
18 bits
L5
256
18 bits
R5
256
18 bits
256
18 bits
Contrainte temporelle : 1,5 ms
256
18 bits
ITDAC
Temps d’execution(µs), ROM (octets), RAM (octets) des tâches
Unités:
2 processeurs P1, P2
1 accelérateur HW
Unité
Surface Cœur
P1
11 mm2
P2
mm2
HW
5
3.5 mm2
Processeur P1
Processeur P2
Exp
Sw: 69 / 774 / 258
Sw: 81 / 920 / 258
accelérateur HW
-
BA
Sw:532 / 1092 / 200
Sw: 589 /1680 /200
Hw: 73 / 0 / 0
Sw+coprocessor: 197/800/200
DM
Sw: 237 / 274 / 150
Sw: 213 / 392 / 150
-
DC
Sw: 47 / 120 / 48
Sw: 52 / 190 / 48
-
RX
Sw:10 / 20 / 0
Sw: 13 / 42 / 0
-
ITDAC
Sw: 130 / 776 / 384
-
-
Sw+coprocessor: 31 /311/384
68
Résultats de l’exploration de l’espace de conception
Temps
Exécution
Contrainte temporelle
50 solutions générées en 3 s
(Sun Ultra 5)
Area
P1 + itdac copro. + HW
P2 + P1 + itdac copro. + BA copro.
P1
P1
2xP1 + itdac copro. + BA copro.
P1#1
69
HW
P1#2
P2
Exemple d’optimisation interactive
Tâche DM
Rom: 512 octets
copro.
Itdac
off-core
Ram: 256 octets
P1
HW
P2
Mémoire de
communication
256 octet
Input
Application
Architecture
Prédéfinie
CODEF
Architecture
Suppression P2
Output
P1 + P2 + itdac copro. + HW
P1 + HW + itdac copro.
P1
P1
P2
HW
70
HW
Conclusions sur le partitionnement statique
♦ L’algorithme de partitionnement prend en compte :
❏ Unités logicielles, matérielles, Coprocesseurs, Accelerateurs matériels
❏ Mémoire cache (L1) des processeurs (modèle simple)
❏ Mémoires RAM/ROM locales ou externes des processeurs
❏ Répartition des données et programmes dans les hiérarchies mémoires (glouton)
❏ L’architecture prédéfinie optionnelle peut contenir :
- Instances d’unités HW & SW
- Allocations de tâches à ces instances
- Hiérarchie mémoire des processeurs,
- Interconnexion
♦ Mais partitionner un C-DFG avec PA2 peut être inefficace (surface, consommation)
71
Exemple d’inefficacité : le C-DFG considéré comme un DFG
A
E
F
Sw2#2
C
0
G
1
Switch
D
Switch
Select
B
1
Tmax=1000
Select
1
Tmax=1000
G
B
Sw2#1
H
Sw2#0
I
E
J
C
L
F
K
0
Switch
input
Switch
Switch
0
Tmax
Unit
Tmax=1000
c3
c1
c0
H
Tmax=1000
J
Switch
a,b
2
HwA
L
HwD
I
c4
c5
c6
HwK
200
400
600
800
1000
Temps
♦ Architecture résultat : Sw2, Sw2, Sw2, HwA, HwD, HwK.
♦ L’exécution systèmatique de tous les nœuds n’est pas nécessaire à chaque itération
72
Architecture surdimensionnée
Partitionnement de graphes de flots de données conditionnels (C-DFG)
♦ Par rapport à un DFG, seuls les nœuds autorisés par les contrôles
doivent être exécutés dans un C-DFG
♦ On considère une approche incrémentale de partitionnement :
Détermination des états de l’application
Réduction aux états premiers
Analysis globale des états premiers
urgence temporelle : ordre
sélection d’une architecture initiale
73
Partitionnement incrémental des états premiers
[Capella-00]
Analyse des états de l’application
♦ De l’analyse des états et des sorties des FSM on déduit :
E6:
Etats
E0
E1
E2
E3
E4
E5
E6
E7
E8
E9
E10
E0:
c0,...,c6
1---000
1---001
1---010
1---011
1---100
1---101
0000--0001--0010--0101--0110---
a,b
sous-graphes
AGJK
AGJKL
AHJK
AHJKL
AIJK
AIJKL
ABDEF
ABDE
ABDF
ACDE
ACDF
E2:
G
J
E1:
H
J
A
Tmax=1000
E3:
a,b
input
Tmax=1000
A
B
D
E
K
input
H
Tmax=1000
J
a,b
E8:
E9:
A
II
A
Tmax=1000
input
J
a,b
B
D
F
A
Tmax=1000
Tmax=1000
input
K
a,b
L
c4, c5, c6
Tmax=1000
E5:
a,b
input
C
D
K
E
Tmax=1000
A
J
Tmax=1000
L
74
K
input
c4, c5, c6
a,b
c4, c5, c6
A
G
Tmax=1000
D
F
E7:
K
input
B
K
c4, c5, c6
c4, c5, c6
a,b
Tmax=1000
A
E
input
input
Tmax=1000
input
a,b
A
Tmax=1000
E4:
A
a,b
II
c4, c5, c6
J
Tmax=1000
E10:
a,b
A
Tmax=1000
L
input
C
D
F
Réduction des états de l’application : les états premiers
Remarque :
♦ Si une architecture respecte les contraintes temporelles pour un DFG,
elle les respecte aussi pour tout sous-graphe de ce DFG.
L’approche statique est basée sur cette remarque.
♦ On ne considère que les états premiers pour déduire l’architecture finale :
Un état premier est un état non inclus dans tout autre état de l’application.
Etat inclus
E0:
Etat premier
.
E1:
a,b
a,b
A
Tmax=1000
A
K
Tmax=1000
input
G
J
input
K
G
Tmax=1000
J
L
c4, c5, c6
c4, c5, c6
75
Etats premiers de l’exemple
Etats
c0,...,c6
Sousgraphes
E0
E1
E2
E3
E4
E5
E6
E7
E8
E9
E10
1---000
1---001
1---010
1---011
1---100
1---101
0000--0001--0010--0101--0110---
GJK
GJKL
HJK
HJKL
IJK
IJKL
BDEF
BDE
BDF
CDE
CDF
E0:
a,b
Etat
englobant
E1
E6:
E2:
A
input
E3
H
a,b
K
E7:
c4, c5, c6
A
input
Tmax=1000
A
B
D
E
K
input
E6
E6
H
Tmax=1000
J
a,b
J
E8:
Tmax=1000
E9:
A
II
A
input
J
B
a,b
D
F
A
Tmax=1000
Tmax=1000
input
K
a,b
L
c4, c5, c6
E4:
input
C
D
K
E
c 4, c 5, c 6
Tmax=1000
A
G
a,b
Tmax=1000
E3:
a,b
E5:
a,b
Tmax=1000
A
K
input
Tmax=1000
D
F
J
c4, c5, c6
E5
c4, c5, c6
E1:
B
Tmax=1000
input
A
G
Tmax=1000
A
E
a,b
Tmax=1000
input
a,b
J
Tmax=1000
L
K
input
II
c4, c5, c6
J
E10:
a,b
76
A
Tmax=1000
L
Tmax=1000
input
C
D
F
Partitionnement incrémental
♦ Choix d’une approche incrémentale : contexte industriel
Nombre d’états et taille du graphe d’applications industrielles
Compromis qualité des solutions/ temps exécution du partitionnement
Utilisation de l’entrée architecture prédéfinie de CODEF
Architecture
prédéfinie
Architecture
résultat
CODEF
PA2
DFG
♦ Conception incrémentale :
Architecture
Prédéfinie
CODEF
CODEF
CODEF
CODEF
CODEF
CODEF
PA2
PA2
PA2
PA2
PA2
PA2
DFG E9
DFG E5
DFG E1
DFG E3
DFG E6
Architecture
Finale
77
DFG E10
Le partitionnement incrémental est sous-optimal
♦ Exemple :
Ex:
Ey:
Surface
Cœurs
A
B
A
B
P1
100
40
110
P2
100
100
30
P3
100
60
40
250
230
200
Surface Mémoire
♦ Partitionner Ex avant Ey ➱ P1 est sélectionné ➩ 250 unités de surface
♦ Partitionner Ey avant Ex ➱ P2 est sélectionné ➩ 230 unités de surface
Ey->Ex meilleur ordre que Ex->Ey
Les résultats dépendent de l’ordre d’analyse des états premiers
Mais la solution avec 200 unités de surface (i.e. P3) ne peut être trouvée
78
Amélioration du partitionnement incrémental
Dans l’architecture prédéfinie initiale on place l’unité avec le meilleur compromis
surface/réutilisation potentielle, en fonction des contraintes temporelles.
s ( u ) + Σσ ( τ , u )
k
i k
S ( τ , u ) = ----------------------------------------------i k
β(τ , u )
i k
∀ état premier
∀ uk
Les états premiers sont partitionnés dans l’ordre décroissant de leur criticité
Min
 Min  Max ( T ( τ , u ) – pl
( τ , u ) ) 
états 
τi 
uk a i k
min i k  
Sur l’exemple à 6 états premiers
Unité avec
meilleur HwD
compromis
CODEF
CODEF
CODEF
CODEF
CODEF
CODEF
PA2
PA2
PA2
PA2
PA2
PA2
E5
E3
E6
E1
Ordre suivant
criticité
E10
Architecture
Finale
79
E9
Résultats
♦ On obtient une architecture composée de
E1:
Unités
Sw2
❹
HwA
E3:
❷
E5:
❶
❸
E9:
➏
♦ Sur les 720 ordres on a :
Surface solutions
avec HwD dans A0.
≤
surface solutions
partitionnée A0 vide
Sw2
H
J
L
I
J
L
HwA
Sw2
HwA
HwK
E6:
♦ L’architecture obtenue n’a pas la plus
petite surface. Seulement 20% des 720
ordres possibles ont une surface
plus petite (la meilleure : - 10%)
E10:
➎
Sw2
B
F
E
HwD
HwA
Sw2
C
E
HwD
HwA
Sw2
C
F
80
HwA
HwD
Temps
200
L
HwK
Sw2, Sw2, Sw2, HwA, HwD, HwK
Deux processeurs en moins
J
HwK
Sw2, HwA, HwD, HwK
♦ Partitionnement du DFG complet
G
400
600
800
1000
Etapes de la conception système avec CODEF
❶
❶
Modèle application
& contraintes
Graphe Flots de
Données Conditionnels
❶
Contraintes
Systèmes
des
❷ Contenu
librairies
Réalisations
précédentes
Estimateurs
(Debugger,VESTIM)
Expérience
du concepteur
❸
❷
espace
❸ Exploration
de conception
Libraries:
❐ Unités Hw & Sw
❐ Modèles de
réalisation des
tâches
Mise à jour ➎
caractéristiques des
Modèles de réalisation
des
➍ Implémentation
tâches SW & HW
➎
CODEF
Spécification Système
Implémentation des tâches (Hw,Sw)
➍
Mise à jour des
➎ modèles, vérification
contraintes avec
CODEF
81
CODEF : Vérification des contraintes pendant les étapes de raffinement système (❸,➎)
Plan de l’exposé
5 - Partitionnement
7 - Conclusion
82
SYNTHÈSE DES COMMUNICATIONS
La spécification d’une architecture
spécialisée inclut l’interconnexion
❏ Déterminer une interconnexion implique :
❏ Choisir les ressources de communication : types et nombres de bus, FIFO, Dual-Port, Arbitre de bus ...
❏ Allouer les communications de l’application sur les ressources sélectionnées
protocole de transfert : mode burst, pipeline, ...
❏ Choisir des modes de transfert :
transfert synchrone ou asynchrone
priorités allouées aux transferts
❏ Classiquement la synthèse des communications est réalisée :
83
❏ Pendant le partitionnement (modèle simplifié utilisé)
❏ Après partitionnement
La réalisation des communications conditionne le comportement global
Maître
Esclave1
Esclave3
Exemple :
Maître1
Maître2
Contrainte Temporelle
Esclave2
Maître3
Maître4
84
Respecter les contraintes temporelles et minimiser surface de silicium/Consommation
FIFO, Dual-Port, Drivers,...
Synthèse des communications pendant le partitionnement
Partitionnement HW/SW
Problèmes d’allocation/ordonnancement
Sythèse des communications
P1
1
2
Allocation/Ordonnancement
1,2,3
2
P2
3
1
3
P1
1
2
Allocation/Ordonnancement
1,3,2
P2
3
2
1
❏ Parcours exhaustif de toutes les solutions [Freund 98]
❏ Détermination de protocoles dans PACE [Knudsen 99]
3
85
Programmation dynamique - 1 processeur + 1 ASIC ( blocs de base)
Synthèse des communications intégrée au partitionnement
[Knudsen 99]
Architecture Cible :
canal
SW
Partitionnement
(Programmation dynamique)
HW
Driver HW
Driver SW
Transferts en mode “Burst”
B1
Communications
données
données
données
B2
B3
SW
B4
❏ Prise en compte des communications :
Nombre de burst
Nombre de données par burst
Débit sur le canal
B5
HW
B6
Horloge des drivers
Overhead d’appel des drivers
Cycles d’overhead du contrôle des transferts
Objectif : Meilleure accélération
Taille des mots transférés
Largeur du canal
86
Synthèse des communications aprés partitionnement (CODEF)
2
Mémoire de communication
émission
1
P1
4
3
1
2
3
P2
P2
Bus
réception
Transfert Asynchrone (A)
Le plus coûteux
surface, consommation
Attente
P1
Transfert Synchrone (B)
Le moins coûteux
P1
4
émission
1
2
P1
3
P2
P2
Bus
4
réception
émission
Transfert Synchrone
par interruption (C)
P1
1
P2
3
2
3
P1
4
P2
Bus
87
réception
Privilégier B puis C puis A
[Cuesta-00]
Synchronisation par utilisation des mobilités
Après partitionnement :
1
2
3
5
7
6
SW
SW
1
2
3
4
7
Synchronisation 7 -> 4 et 6 -> 7
Transfert 5 -> 3 asynchrone
6
SW
Contrainte temporelle
1
HW
U2
Volume données arcs asynchrones
-----------------------------------------------------------------------------------Volume données arcs synchrones
2
3
4
synchrones
5
7
asynchrone
6
Synchronisation 5->3 et 7->4
Transfert 6 -> 7 asynchrone
1) Synchronisation des arcs qui ne provoquent pas de transferts asynchrones
2) Synchronisation des arcs
Mobilités des tâches
7
U1
synchrones
6
4
5
U1
U2
HW
3
HW
ei,j
1
2
asynchrone
5
U1
U2
4
Volume données transférées e i, j
------------------------------------------------------------------------------Mobilité de e i, j
[Gogniat-97]
88
Synchronisation par interruptions
2
émission
1
P1
1
P2
3
2
Interruption provoquée par l’émetteur
4
3
3
4
réception
Durée de vie
données transférées
Mémoire RAM du récepteur P2 de taille suffisante ?
Profiter de la mémoire “scratch” des tâches
P1
P2
Bus
Nécessite un
réordonnancement
émission
P1
1
P2
3
2
2
Interruption provoquée par le récepteur
4
89
réception
Durée de vie
données transférées
Synthése des supports de communication
COMMUNICATION SYNCHRONE
ÉMETTEUR
COMMUNICATION ASYNCHRONE
RÉCEPTEUR
ÉMETTEUR
➊
➊
RÉCEPTEUR
➋
➌
Buse
Bus
DURÉE DE VIE DU buse
DURÉE DE VIE
Vi
Vj
➊
RÉCEPTEUR
ÉMETTEUR
tdebutbus
Busr
tfinbus
Vi
ÉMETTEUR
tdebutbuse
Vj
tfinbusr
Mémoire
ALGORITHME DE BIPARTITE
MATCHING PONDÉRÉ
DURÉE DANS LA MÉMOIRE
tdebutmémoire
RÉCEPTEUR
tdebutbusr
➋
Vi
Vj
➌
tri,j
➊
tei,j
tfinbuse
ei,j
DURÉE DE VIE DU busr
tfinmémoire
90
Exemple de résultats avec CODEF
Application considérée :
Sous-ensemble d’un set-top-box : décodeur audio AC3 5.1 et un modem.
Contraintes de temps :
1er décodeur AC3
0
5
5 ms
253 nœuds
335 arcs
2ème décodeur AC3
5 ms
10 ms
Contrainte Temporelle
Unités de la librairie :
❐ ARM7TDMI (100 MHz),
❐ OAKDspCore (80 MHz),
❐ coprocesseurs & accélérateurs matériels
Problème : Architecture, Allocation, Ordonnancement ?
91
Surface
Exploration de l’espace de conception
ARM + OAK
+ Accelerateur
+ 2 coprocesseurs
Utilisation moyenne
30%!
Solution la plus
rapide
Temps
1er AC3 & modem
2ème AC3
Surface la
plus petite
92
ARM + OAK + 1 coprocesseur
ARM + OAK + 2 coprocesseurs
Optimisation et synthèse des communications
Temps d’exécution de la solution avec la plus petite surface : 8.3 ms.
Optimizations possibles : contrainte = 10 ms
On modifie cette solution qui est réutilisée dans CODEF.
Modifications :
OAKDspCore : 40 MHz au lieu de 80 MHz
Mémoires RAM et ROM Off-core : 50 ns de temps d’accès
ARM7TDMI : 80 MHz au lieu de 100 MHz
Meilleure exploitation
parallélisme entre
les 2 processors.
On obtient
DFG
Conditionnel
Contraintes
Librarie :
CODEF
❐ Unités Hw & Sw
❐ Modèles
d’mplantation
3 bus, 1 mémoire :
Modifications
Architecture
à améliorer !
93
Architecture Système
Conclusion sur la synthèse des communications
❏ Peu d’études sur la synthèse des communications
U2
Protocole p2
❏ Plusieurs travaux abordent la synthèse d’interface
U1
Protocole p1
U2
❏ Les modèles considérés dans le partitionnement sont en général simples
[Knudsen 99]
❏ Avancées basées sur des bus standardardisés (AMBA, Bus Core)
94
❏ Travaux sur les composants virtuels (IP)
CONCLUSION
Le processus de conception d’un système embarqué est complexe
❏ Grande variété de réalisation des traitements
Microcontrolleurs, RISC, DSP, ASIP, ASIC, algorithmes, RTOS
Hiérarchie et structure mémoire, ressources de communication (DMA, bus...)
❏ Hétérogénéité des traitements
Flots de données
signal : pression sur traitement/mémoire
image : pression sur mémoire
Contrôle : pression sur réactivité, temps de réponse
❏ Contraintes fortes (différentes pour chaque produit)
temps, surface, consommation, time-to-market, flexibilité, coûts, poids...
95
Privilégier la réutilisation
Problèmes importants d’actualité en co-conception
❏ Environnement de modélisation unique : éviter de fractionner la spécification/conception
❏ Partitionnement des fonctionnalités de l’application
❏ Vérification/preuve plutôt que (co-) simulation (ordonnançabilité, réactivité, comportement)
❏ Estimations de caractéristiques SW, HW : performances, surface, consommation...
❏ Définition d’interfaces standardisées des composants virtuels (IP)
❏ La synthèse des communications (Bus Core)
❏ Intégration avec d’autres technologies : optique, analogique ...
96

Co-Conception de Systèmes Spécialisés sur

Transcription

Documents pareils

Schéma d`un territoire de l`innovation : le technopôle de Sophia

Transport

Programme 10 mars autour des images

Modélisation 3D dense temps réel par approche directe

BON DE COMMANDE 99 € HT/Mois

Laboratoire d`Informatique, Signaux

DEVELOPPEUR LOGICIEL Compétences en Informatique

UNIVERSITE DE NICE (SOPHIA ANTIPOLIS) Référence GALAXIE