Plan de l'Exposé

Publié par

Cm2, Primaire, CM2
  • mémoire - matière potentielle : virtuelle
  • exposé - matière potentielle : introduction
  • mémoire
  • mémoire - matière potentielle : locale
  • mémoire - matière potentielle : parallèle
  • mémoire - matière potentielle : off
  • mémoire - matière potentielle : locales
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff 1 Introduction à la Conception de SoC Michel Auguin Laboratoire I3S - Université de Nice Sophia Antipolis, CNRS I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff 2 Plan de l'Exposé Introduction : Contexte et Besoins Evolution des Méthodes de conception Modélisation des applications Vérification Compilation Analyses et Estimations Architectures adaptées : exemple des NoC Exploration d'architectures Plateforme et IP Exemple : la plateforme TI- OMAP Conclusion I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff 3 Introduction Le nombre de SoC produits croît (~30% par an) en fonction
  • abstraite transformations par modèle cosimulation
  • i3s
  • vdd φ φ
  • besoins evolution des méthodes de conception modélisation des applications vérification
  • sram sdram
  • temps réel
  • temps réels
  • conception
  • conceptions
  • modèle
  • modèles
Publié le : mardi 27 mars 2012
Lecture(s) : 87
Source : irisa.fr
Nombre de pages : 12
Voir plus Voir moins

Plan de l’Exposé
Introduction : Contexte et Besoins
Evolution des Méthodes de conception
Modélisation des applications
Introduction à la Conception de SoC
Vérification
Compilation
Analyses et Estimations
Michel Auguin
Architectures adaptées : exemple des NoC
Exploration d’architectures
Plateforme et IP
Laboratoire I3S - Université de Nice Sophia Antipolis, CNRS
Exemple : la plateforme TI- OMAP
1 2
Conclusion
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Evolution des besoins en puissances de traitement intégrées
Introduction
MIPS
Bande de base de récepteurs de type Wireless
Le nombre de SoC produits croît (~30% par an) en fonction des
10000
avancées de la technologie et des besoins des applications
1000
Les traitements dans les applications sont de plus en plus
100
complexes. La mobilité renforce les contraintes (coûts, énergie)
10
GPS
BlueTooth GSM GPRS EDGE UMTS
Puissance de Calcul
GSM/GPRS/EDGE/UMTS
2
WLAN SpecInt92
W/Cm
PDA 4
3
MIPS/Watt
10
10
MP3
3
2
10
10
MPEG4
2
MIPS/mm
2
Internet (Java) 1
10
10
IHM
1
3 4
10
1
Reconnaisance vocale
Mémoire intégrée
Jeux .....
86 90 94 98 02 86 90 94 98 02
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoffo
o
o
o
o
o
Compromis Performances/Consommation Architecture d’un SOC
BlueTooth
GPRS
APPLICATION
Agenda
MIPS/Watt
Internet
BIOS :
Basic I/O System
ASIC
MiddleWare
RTOS :
Architecture
FPGA
Real Time OS
Logicielle
RTOS &
BIOS &
DSP
Drivers Drivers
MCU
Nombreux Choix
MPU
HW/SW
Performances ?
Flexibilité
Temps Réel ?
Architecture
800 MHz : 1,65V 1100 MIPS/W Best Effort ?
Matérielle
5 6
Processeur
Consommation ?
400 MHz : 1 V
1250 MIPS/W
Intel XScale
Coûts ?
150 MHz : 0,75 V
4500 MIPS/W
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Flot classique de conception
Spécification Produits
APPLICATION
Manuel
BlueTooth
Ensemble de Tâches
Décomposition en blocs fonctionnels
Test opérationnel & Production
GPRS
Agenda
Internet
Spécification de chaque bloc
Test système
Tâches de type
Tâches orientées contrôle
Conception détaillée de chaque bloc Intégration et test
Traitement du Signal et Images
Protocole réseau
Bande de base GSM
Power Management
MPEG4
Test de chaque bloc
Réalisation de chaque bloc
IHM
Opérations graphiques
Chaque bloc est conçu de façon indépendante
Les tâches se partagent les ressources du SoC Matériel
7 8
Blocs Logiciel
Techniques de vérification : (co-)simulation
Contraintes Temps, Consommation, Coûts vérifiées ? Communication
Test des communications : en phase d’intégration
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Plusieurs GIPS/W
DSP TMS320C54x : 1600 MIPS/W
StrongArm : 880 MIPS/W
PowerPC 603 : 53MIPS/W
DEC Alpha 21264 : 50 MIPS/W
Correctionso
o
o
o
o
Approche "Langage" de conception de chaque bloc fonctionnel Conception verticale suivant chaque langage
e.g. Gestion réseau (C) e.g. IHM (java) Approche traditionnelle :
e.g. Rake Receiver UMTS (Matlab)
Décomposition en blocs fonctionnels et conception verticale
Sous-système 2 Sous-système n
Sous-système 1
Langage ad hoc Langage ad hoc
Langage ad hoc
Vérification des erreurs intra-blocs
Processus
Transformations
Transformations Transformations
de conception
Représentation
Représentation Représentation
interne
interne interne
Environnement de validation : cosimulation Implémentation
Intégration
Cosimulation C - VHDL
Langage Langage Langage Langage
Cosimulation Assembleur (ISS) - VHDL
1 2 3 4
Aucune optimisation globale : optimisations par sous-système (dépendant langage)
9 Vérification des erreurs inter-blocs 10
Nécessite de décrire précisément les communications et les interfaces
Intégration explicite : communications détaillées
Les migrations éventuelles entre sous-systèmes ne sont pas aisées
Cosimulation
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Vérification par co-simulation Limitations de l’approche "Langage"
Modèle vhdl d’un ASIC
ARM9
TDMI
if ((ahbsi.hready and ahbsi.hsel) = ’1’) then
Optimisations locales
v.size := ahbsi.hsize(1 downto 0); v.area := area;
v.hburst := ahbsi.hburst; v.htrans := ahbsi.htrans;
v.address := ahbsi.haddr;
Vérification en simulation de chaque bloc
if (brmw = ’1’) then v.read := ’1’;
else v.read := not ahbsi.hwrite; end if;
v.hwrite := ahbsi.hwrite;
Absence de vérification globale hors cosimulation
v.busw := busw;
v.brmw := brmw;
end if;
Difficultés pour déterminer a priori les performances globales
• Temps réel vérifié ?
• Temps d’exécution satisfaisant ?
Communications
• Consommation d’énergie maîtrisée ?
Synchronisations
Simulateur ISS
Simulateur VHDL
du processeur
Le debugging est délicat
(jeu instructions)
• Localisation des erreurs
e.g. sockets, IPC
11 12
• Couverture de test
Précision “cycle accurate”
Comment accélérer les simulations ?
Précision “Bit accurate”
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Optimisation - Validation
Optimisation - Validation
Interface
Optimisation - Validation
Niveaux d’abstractionOù les choses se compliquent encore : les communications Et n’oublions pas la contrainte du Time to Market
Temps de communication sur les fils dépendent de la conception :
Durée de vie
Nombre d’unités connectées sur le bus
Bénéfices
Incertitude sur les temps de propagation dans les fils
Système produit en accord avec le marché
Le bruit dans le chip
Production en décalage
Temps de propagation
augmente avec le courant
Buffer
Temps
# Watt augmente avec
Faible courant
le courant
Buffer
Time To Market
Fort courant
Buffer
Nb Unités connectées
Les produits ont une durée de plus en plus faible
Bus
13 14
Réduire le «time to market»
Les performances réelles sont connues tardivement
Réutilisation pour concevoir d’autres produits (rentabiliser)
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Comment aborder ce challenge ?
Plan de l’Exposé
Introduction : Contexte et Besoins
Améliorer le flot de conception
Evolution des Méthodes de conception
• Méthodes qui opèrent sur des descriptions hétérogènes
• Vérification formelle Modélisation des applications
Vérification
• Compilation
Compilation
• Analyse plus précises : WCET, consommation, ordonnançabilité
Analyses et Estimations
• Architectures adaptées : NoC
Architectures adaptées : exemple des NoC
Méthodes d’exploration multi-critères : temps/consommation/coûts
Exploration d’architectures
Plateforme et IP
Renforcer la réutilisaton
Exemple : la plateforme TI- OMAP
• Notion d’IP et de Plate-forme
15 16
Conclusion
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoffo
o
o
o
o
o
o
o
o
o
o
o
Evolution souhaitée des méthodes de conception
Approche “Modèle”
Approche de modélisation intégrée :
L’environnement permet des raffinements “sans coutures”
Sous-système 1 Sous-système 2 Sous-système n
Modèle 1 Modèle 2 Modèle n
Optimisations Optimisations Optimisations
Vérification des erreurs intra-modèle
Processus
de conception
Optimisations Environnement d’acceuil (modèle)
Validations
Transformations
Outils de conception
par modèle
Implémentation
Cosimulation
Intégration
Modèle Modèle Modèle Modèle
1 2 3 4
Optimisations locales et globales
17 18
Vérification des erreurs inter-modèles :
Exploration de l’espace de conception plus aisée
Communications inter-modèles : types prédéfinis
Les communications et interfaces sont décrites de manière plus abstraite
[www.vptinc.com]
Vérifications sémantiques
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Les modèles diffèrent par leur sémantique Choix du modèle de spécification en fonction du type de l’application
Calcul analogique, équations différentielles (temps continu - Matlab)
Classiquement les concepteurs considèrent qu’un système est dominé :
L’évolution du modèle s’effectue dans l’ensemble des réels (ordre total)
Temps échantillonné (équation aux différences) Par le contrôle
Systèmes à événements discrets
L’évectue dans un sous-ensemble des réels (ordre total)
Systèmes réactifs synchrones
Réactions à des événements discrets :
Machine d’Etats Finis
Systèmes à événements discrets
Système cadencé par les événements
Réseaux de Petri
Acteur 1
Idem
Processus concurrents
Réseaux de Processus (Kahn), Graphes Flots de Données Contrôle/Commande de processus
Acteur 2
Ordre partiel sur les événements
Processus séquentiels avec rendez-vous (CSP)
Evénements discrets
Par les données
Ordre par
Acteur 1 Sorties fonctionnellement dépendantes des entrées : Kahn Process Networks
Systèmes réactifs synchrones (Esterel)
e1 e2 e3
Dataflow Process Networks
(Ordre total)
Entrées périodiques ou pseudo-périodiques
e4 e5 e6
Acteur 2
19 20
Codesign Finite State Machine (CFSM)
Ordre partiel
Traitement du signal et des images
(Globalement partiel, localement total)
Réactif synchrone
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Niveaux d’abstractionLangages associés aux modèles Environnements pour applications hétérogènes
Un seul modèle de calcul est insuffisant pour décrire toute l’application
Codesign
Systèmes réactifs synchrones Esterel, Lustre, Signal, ECL
Finite
Exemples d’approches globales proposées :
State
Systèmes à événements discrets VHDL, Verilog
Machine
ROSETTA
Langage et sémantique pour
Machine d’Etats Finis *Charts (StateCharts, ...) Projet de l’initiative SLDL
accueuillir différents VHDL-AMS
SDL
System Level Description Language
modèles de calcul
(Standard de
Processus concurrents CSP, Occam, Lotos http://www.inmet.com/SLDL/
l’ITU)
Systèmes réactifs synchrones
Dynamic Data Flow
Dataflow Process Networks
Machines d’Etats Finis hiérarchisées
Kahn Process Networks
Synchronous Data Flow
Plusieurs modèles de calcul intégrés
Processus communicants
PTOLEMY
dans un même environnement
Dataflow Process Networks
Modèle Objet Java, C++, OO-VHDL
Systèmes à événements discrets
SPW, COSSAP, Matlab
SystemC : Classes C++ pour décrire réactivité, Kahn Process Networks, CSP
21 22
Hormis les techniques à base de cosimulation, il existe peu de méthodes
de conception unifées qui opèrent sur une description hétérogène.
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Vérification Formelle
Spécification Vérification par preuve formelle de propriétés
Manuel
Nb d’erreurs
Décomposition en blocs fonctionnels
identifiées
Simulation : analyse "parallèle" du modèle
Spécification de chaque bloc
Vérification Formelle de propriétés
analyse en profondeur
Conception détaillée de chaque bloc
Temps
Difficulté pour le concepteur : déterminer les propriétés qui font du sens
Réalisation de chaque bloc
MATERIEL
LOGICIEL
Vérification par équivalence de modèles
Comment s’assurer que chaque niveau de description est correct ?
Approche classique : Simulation i.e. animation du modèle
23 24
Comportements
Modèle abstrait
Modèle après raffinement
Exécution sur des séquences de test
“Equivalents” ?
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Vérifications
Correctionsm
a
S
a
o
o
m
a
m
m
S
Compilation pour Cœurs de Processeurs Analyses et estimations plus précises
Analyses temporelles
Les échéances des tâches critiques
Techniques classiques de compilation : processeurs hautes performances
sont elles vérifiées ?
BlueTooth
GPRS
APPLICATION
• Mémoire virtuelle, caches données et instructions
Agenda
Déterminer les WCET des tâches
Internet
• Fichiers de registres homogènes
Worst Case Execution Time
MiddleWare
• Renommage, lancement dans le désordre ...
BIOS & RTOS &
Déterminer si tâches ordonnançables
Drivers
Drivers
Cœurs de processeurs :
Deadline T2
Deadline T1
• Mémoire locale vs Cache et mémoire off-chip
T2 T1
T2 & T1 Ready Temps
• Mémoire parallèle on-chip et Registres spécifiques répartis (DSP)
Analyse d’ordonnançabilité
• Temps réel et Consommation
• RTOS
Problèmes : Architectures peu déterministes (Caches, branchements, ...)
Politique d’ordonnancement (Mono vs Multiprocesseur)
25 26
Les contraintes et objectifs sont différents
Gestion d’événements sporadiques
Comportement des autres tâches ? (Agenda, IHM ...)
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Optimisation de la Consommation
Analyses Consommation
2
P = P + P
dynamique court-circuit commutation Pour Réduire V F C
dd i i
Technologie, Choix des composants
Due à l’activité du circuit
Prépondérante en fonctionnement
Limiter les changements d’états inutiles
P = P + P
dynamique court-circuit commutation
(Clock Gating, encodage d’adresses, mise en veille)
Changements de modes de
90% de la consommation globale
l’Intel StrongARM
400 mW
2
P = V F C
commutation dd i i
RUN
10 s
90 s
10 s 160 ms
: activité moyenne de chaque élément logique
i
C : capacité chargée et déchargée à chaque variation d’état de l’élément logique 27 IDLE SLEEP 28
i
90 s
F : fréquence de fonctionnement
160 mW 50 mW
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - RoscoffF
a
×
S
F
D
F
F
a
a
S
S
2
Puissance = V F C
Parallélisme (ou pipeline) réduit l’énergie 2
dd i i
Pour Réduire V F C
dd i i
P
P
Réduire V implique de réduire F donc la performance : Voltage Scaling V
dd dd
Puissance P, Fréquence F
2T
T
Temps exécution T I
T
En effet, temps de réponse d’une porte :
Tension alimentation V
dd
V’ V
2
V dd dd
t
C V ()V – V
P
L dd dd t
C
L
T = ---------------------- - I = ------------------------------- -
V : tension de seuil
t
d
I k
kC V
L dd
Délai = ---------------------------- -
2
Exemple avec V = 0,7V et V passe de 5V à 1,5V : Temps de réponse x 8
T t dd
()V – V
dd t
Permet de fixer V’
dd
Puissance par :
Gestion Dynamique de la fréquence et de la tension (DVS)
2
0,5V’ F C
On se ramène au temps T :
dd i i
Fréquence F/2
Ex : V = 3,7V; V = 0,7V
dd t
Tension alimentation V’ 29 30
dd Gain en puissance :
V’ = 2,4V
dd
2 2
V /V’
dd dd Gain en puissance 2,36
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Architectures Adaptées : Exemple des NoC (Network On Chip)
Gestion par OS de la vitesse et de la tension d’alimentation du processeur
Architecture à base de bus : Temps de communication dépendent de la conception
Vitesse et tension d’alimentation processeur : Intel Xscale 4 V et 11 clocks
dd
Charge du processeur
Solution
Microréseau
Sonics
Diminution de la tension et de la fréquence
Communications via Agents avec protocole OCP (Open Core Protocol)
Réseau : Bus pipeliné avec gestion TDMA, latence fixe
Bande passante configurable à allocation statique
31 32
Reconfiguration dynamique possible
Temps d’exécution plus longs : échéances toujours respectées ?
Outils logiciels de configuration et de synthèse du réseau (et agents)
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Délai Porte
Puissance•

¤
¤
¤
¤
Méthodes d’Exploration Multi-Critères Renforcer la réutilisation : IP et Plateformes
Illustration des difficultés
Déduire l’effort de conception : privilégier réutilisation et flexibilité
Graphe flots de données
Allocation et ordonnancement ?
A
C D
P1 A C D
B
Réutilisation, flexibilité Logiciel
B
P2
1
SoC
Quelle Architecture ? MPU Reconfigurable ?
DSP
Temps
1 2 B
P1
D
Performances Matériel
Conso.
coprocesseur coprocesseur
P2 Surface
A C
2
MPU
DSP MPU
34 5 B
P1
3
Conception de SoC par assemblage d’IP (Intellectual Property)
DSP MPU DSP
P2 A C D
Eléments architecturaux dans un SOC : Temps
0 SoC pour une classe d’applications : les Plateformes
Contrainte
RISC, DSP, coprocesseurs, accélérateurs Hw
33 34
de Temps
Mémoires locales/externes : data & programme
"Solution industrielle"
Caches
Ordonnancement statique non préemptif
Ports I/O, caractéristiques des bus ...
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Plateforme : Factoriser les efforts
Utilisation de la Technologie Reconfigurable
Norme A0
Effort de Production
conception A0
Opérateurs
802.11.a temps DSP
RAM ROM
Reconfigurables
Norme A1
Interconnexion Reconfigurable
Effort de Production
conception A1
Hiperlan2
RISC
IP
matériel
Norme A
Production norme A0
Effort de
802.11.a
Production norme A1
conception A
Compromis Performances/Consommation/Surface/Flexibilité
&
35 36
Hiperlan2
Outils pour le Reconfigurable ?
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - RoscoffPlan de l’Exposé Exemple de Plateforme : OMAP de Texas Instruments
Introduction : Contexte et Besoins
“Espace”
Evolution des Méthodes de conception
Application
Modélisation des applications
Vérification
Compilation
Plateforme
Analyses et Estimations
Architectures adaptées : exemple des NoC
Exploration d’architectures
“Espace”
Plateforme et IP
Architecture
Exemple : la plateforme TI- OMAP
37 38
Conclusion
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
TI-OMAP1510 DSP vs RISC
SDRAM FLASH
Exemples de comparaison RISC/DSP (Texas Instruments)
DSP
SRAM I-Cache
Timer
DSP TI320C55
High
SRAM
Memory MMU Applications ARM9E StrongARM 1100 TMS320C5510
Speed
UART
Interface
Bus
Annulation Echos (16bits) 24 39 4
SRAM
DMA
Annulation Echos (32 bits) 37 41 15
GPIO
ROM
DMA
I-MMU D-MMU
Multi-Ports décodage MPEG4/H263 33 34 17
QCIF 15 fps
DSP Int.
API
codage MPEG4/H263 179 153 41
I-Cache D-Cache
QCIF 15 fps
Bus Système
décodage JPEG QCIF 2.1 2.06 1.2
Bus Périphérique
décodage MP3 19 20 17
ARM925T
39 40
Millions cycles/S
LCD Ctrl Timer
Watchdog ARM Int. USB
RISC
I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff I3S - Université de Nice Sophia Antipolis - CNRS Ecole Thématique 2003 - Roscoff
Memory Interf
ace
Bridge
Bridge
Bus Périphérique

Soyez le premier à déposer un commentaire !

17/1000 caractères maximum.