Prototypage basé sur une plateforme reconfigurable
pour vérification des systèmes monopuces
A Sasongko
To cite this version:
A Sasongko. Prototypage basé sur une plateforme reconfigurable pour vérification des systèmes monopuces. Micro et nanotechnologies/Microélectronique. Université Joseph-Fourier - Grenoble I, 2004.
Français. �tel-00008274�
HAL Id: tel-00008274
https://tel.archives-ouvertes.fr/tel-00008274
Submitted on 27 Jan 2005
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
UNIVERSITE JOSEPH FOURRIER – GRENOBLE1
SCIENCE & MEDICINE
N° attribué par la bibliothèque
|_|_|_|_|_|_|_|_|_|_|
THESE
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITE JOSEPH FOURIER
Spécialité : Microélectronique
Présentée et soutenue publiquement
Par
Arif SASONGKO
Le 15 Octobre 2004
Titre
Prototypage basé sur une plateforme reconfigurable pour la
vérification des systèmes monopuces
Directeur de thèse : Ahmed Amine JERRAYA
JURY
Marc RENAUDIN
Fabrice KORDON
Michel ROBERT
Ahmed A. JERRAYA
Frédéric ROUSSEAU
Président
Rapporteur
Rapporteur
Directeur de thèse
Co-directeur de thèse
Thèse préparée au sein du laboratoire Technique de l’Informatique et de la
Microélectronique pour l’Architecture des ordinateurs - TIMA
Sommaire
SOMMAIRE
Sommaire .............................................................................................................................i
Liste des figures................................................................................................................v
Liste des tableaux ...........................................................................................................vii
Chapitre 1 : Introduction..................................................................................................1
1.1 Contexte : conception des systèmes multiprocesseurs monopuces......................................................2
1.1.1 Introduction............................................................................................................................................. 2
1.1.2 La conceptions des systèmes monopuces ........................................................................................... 3
1.2 Nécessité de la vérification............................................................................................................................5
1.3 Les techniques de vérification des systèmes monopuces .......................................................................6
1.4 Nécessité du prototypage pour réduire le temps de conception...........................................................7
1.5 Contributions...................................................................................................................................................9
1.5.1 Définition d’un flot de prototypage basé sur une plateforme reconfigurable................................. 9
1.5.2 Automatisation du flot du prototypage................................................................................................ 9
1.5.3 Proposition d’une solution de co-émulation basée sur une plateforme reconfigurable ................ 9
1.6 Plan du mémoire...........................................................................................................................................10
Chapitre 2 : Vérification des systèmes monopuces : techniques et
comparaison ...........................................................................................................11
2.1 Introduction...................................................................................................................................................12
2.2 Objectif de la vérification d’un système monopuce..............................................................................12
2.2.1 Vérifier la spécification fonctionnelle ............................................................................................... 13
2.2.2 Vérifier l’architecture du système ...................................................................................................... 13
2.2.3 Vérifier l’implémentation des composants du système................................................................... 13
2.2.4 Vérifier l’intégration de composants hétérogènes ........................................................................... 14
2.2.5 Détecter tous les bogues avant la fabrication ................................................................................... 14
2.3 Difficultés de la vé rification d’un système monopuce ..........................................................................15
2.3.1 Hétérogénéité........................................................................................................................................ 15
2.3.2 Complexité............................................................................................................................................ 15
2.3.3 Il n’existe pas encore d'outils de déboguage de systèmes multiprocesseurs ................................ 16
2.4 Diverses techniques de vérification des systèmes monopuces ............................................................16
2.4.1 Critères de comparaison des techniques de vérification des systèmes monopuces..................... 16
2.4.2 La vérification formelle ....................................................................................................................... 18
2.4.3 La simulation sur ordinateur............................................................................................................... 20
2.4.4 L’émulation........................................................................................................................................... 23
2.4.5 Le prototypage...................................................................................................................................... 25
2.4.6 Synthèse des différentes techniques .................................................................................................. 28
2.5 Le prototypage basé sur une plateforme reconfigurable ....................................................................30
2.5.1 Intérêt du prototypage pour les systèmes monopuces ..................................................................... 30
2.5.2 Intérêt du prototypage basé sur une plateforme reconfigurable..................................................... 30
2.5.3 Intérêt de la co-émulation basée sur une plateforme reconfigurable............................................. 31
2.5.4 Exemples de flot de prototypage industrielle ................................................................................... 31
i
Sommaire
2.6 Conclusion......................................................................................................................................................37
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme
reconfigurable.........................................................................................................39
3.1 Introduction...................................................................................................................................................40
3.2 Définition du prototypage d’un système monopuce sur une plateforme reconfigurable ...........40
3.2.1 Modèle de système monopuce........................................................................................................... 40
3.2.2 Modèle générique d’une plateforme de prototypage....................................................................... 42
3.2.3 Modèle d’une plateforme idéale pour le prototypage...................................................................... 43
3.3 Les plateformes reconfigurables et les flots de prototypage existants..............................................46
3.3.1 La classification des plateformes selon l'utilisation......................................................................... 46
3.3.2 La classification de la plateforme reconfigurables par le nombre de domaine d'application
supporté par la plateforme ................................................................................................................ 46
3.3.3 La classification des plateformes reconfigurables selon la configuration ou les types de
composants configurables dans la plateforme................................................................................ 47
3.4 Flot de prototypage simple .........................................................................................................................48
3.4.1 Allocation.............................................................................................................................................. 48
3.4.2 Génération de code.............................................................................................................................. 49
3.4.3 Exemple ................................................................................................................................................. 49
3.5 Flot de prototypage proposé.......................................................................................................................51
3.5.1 Configuration........................................................................................................................................ 52
3.5.2 Adaptation............................................................................................................................................. 54
3.6 Conclusion......................................................................................................................................................56
Chapitre 4 : Applications...............................................................................................57
4.1 Introduction...................................................................................................................................................58
4.2 Plateforme ARM Integrator ......................................................................................................................58
4.2.1 La carte mère de plateforme ARM Integrator.................................................................................. 59
4.2.2 La carte processeur de la plateforme ARM Integrator.................................................................... 60
4.2.3 La carte FPGA de la plateforme ARM Integrator........................................................................... 60
4.2.4 Le Bus AMBA...................................................................................................................................... 61
4.2.5 Outil de déboguage : Multi-ICE......................................................................................................... 61
4.2.6 Logiciel de développement et de déboguage.................................................................................... 62
4.2.7 Les caractéristiques de la plateforme ARM Integrator.................................................................... 63
4.3 Prototypage du VDSL sur la plateforme avec un réseau de communication fixé .........................64
4.3.1 Description de l’application................................................................................................................ 64
4.3.2 Spécification de l’application............................................................................................................. 64
4.3.3 Architecture logicielle matérielle ....................................................................................................... 65
4.3.4 Objectif du prototypage et contraintes............................................................................................... 65
4.3.5 Allocation.............................................................................................................................................. 66
4.3.6 Configuration........................................................................................................................................ 67
4.3.7 Adaptation............................................................................................................................................. 69
4.3.8 Génération de code.............................................................................................................................. 69
4.3.9 Résultats ................................................................................................................................................ 70
4.4 Prototypage du DivX ...................................................................................................................................71
4.4.1 Description de l’application................................................................................................................ 71
4.4.2 Objectif du prototypage et contraintes............................................................................................... 72
4.4.3 La spécification et l’architecture RTL............................................................................................... 73
4.4.4 Allocation.............................................................................................................................................. 76
4.4.5 Configuration........................................................................................................................................ 77
4.4.6 Adaptation............................................................................................................................................. 77
4.4.7 Génération du code.............................................................................................................................. 81
4.4.8 Résultats et analyse.............................................................................................................................. 81
ii
Sommaire
Chapitre 5 : Analyse et perspectives..........................................................................83
5.1 Introduction...................................................................................................................................................84
5.2 Evaluation des exemples .............................................................................................................................84
5.2.1 VDSL..................................................................................................................................................... 84
5.2.2 DivX....................................................................................................................................................... 85
5.2.3 Synthèse................................................................................................................................................. 86
5.3 Automatisation de l’adaptation pour accélérer le développement du logiciel................................87
5.3.1 Les outils de génération automatique du flot ROSES ..................................................................... 87
5.3.2 L’automatisation de l’adaptation........................................................................................................ 93
5.3.3 Avantages et limitations...................................................................................................................... 96
5.3.4 Conclusion sur l’adaptation................................................................................................................ 98
5.4 Co-émulation .................................................................................................................................................98
5.4.1 Exemple de co-émulation en utilisant la plateforme ARM Integrator.......................................... 98
5.4.2 Evaluation ...........................................................................................................................................104
5.4.3 Perspectives.........................................................................................................................................105
Chapitre 6 : Conclusion.............................................................................................. 107
Bibliographie ................................................................................................................. 111
Publications................................................................................................................... 117
iii
Liste des figures
LISTE DES FIGURES
Figure 1 Représentation de système monopuce ....................................................................3
Figure 2 Flot de conception des systèmes monopuces ..........................................................4
Figure 3 Effet du prototypage sur la conception d’un système monopuce ............................8
Figure 4 Création d'un produit numérique ..........................................................................12
Figure 5 Le System Explorer d’Aptix.................................................................................32
Figure 6 Les phases dans la conception des système monopuces d'Aptix...........................33
Figure 7 Flot de prototypage d'APTIX ...............................................................................34
Figure 8 La plateforme de prototypage FlexBench.............................................................35
Figure 9 La topologie de FlexBench...................................................................................36
Figure 10 Flot de prototypage FlexBench...........................................................................37
Figure 11 Modèle d'architecture d’un système monopuce ..................................................41
Figure 12 Modèle générique de plateforme de prototypage ................................................42
Figure 13 L'implémentation d'une plateforme idéale ..........................................................44
Figure 14 modèle de notre implémentation de la plateforme idéale ....................................45
Figure 15 Flot de prototypage simple .................................................................................48
Figure 16 Exemple de l’allocation......................................................................................49
Figure 17 Génération du code.............................................................................................51
Figure 18 Flot de prototypage .............................................................................................52
Figure 19 Exemple de configuration ..................................................................................53
Figure 20 Configuration.....................................................................................................54
Figure 21 Adaptation..........................................................................................................55
Figure 22 Plateforme ARM Integrator avec 3 cartes processeur et 2 cartes FPGA .............58
Figure 23 La carte mère......................................................................................................59
Figure 24 La carte processeur .............................................................................................60
Figure 25 La carte FPGA ...................................................................................................61
Figure 26 La configuration typique d’une bus AMBA .......................................................61
Figure 27 Multi-ICE...........................................................................................................62
Figure 28 Modem VDSL....................................................................................................65
Figure 29 Architecture logiciel/matériel de modem VDSL au niveau RTL........................66
Figure 30 Configuration de l’application VDSL.................................................................68
v
Liste des figures
Figure 31 Convertisseur .....................................................................................................69
Figure 32 La génération de code.........................................................................................70
Figure 33 Schème de DivX encodeur .................................................................................71
Figure 34 La spécification de départ de l'application DivX ................................................73
Figure 35 L’architecture logicielle/matériel de l’application DivX ....................................74
Figure 36 Décomposition des donnée.................................................................................74
Figure 37 Implémentation de la partie communication de l’exemple DivX........................75
Figure 38 Allocation de DivX ............................................................................................76
Figure 39 Revenir à la spécification plus haut niveau.........................................................78
Figure 40 Génération d’interface logicielle ........................................................................78
Figure 41 Implémentation de la partie communication sur le prototype de l’application DivX
...............................................................................................................................79
Figure 42 Interface lo giciel/matériel...................................................................................88
Figure 43 Le flot ROSES ...................................................................................................89
Figure 44 Un exemple de modules, de liens, et de ports .....................................................90
Figure 45 Un exemple d’entée du flot ROSES ...................................................................91
Figure 46 ASOG ................................................................................................................92
Figure 47 Génération des interfaces matérielles par ASAG................................................93
Figure 48 Abstraction et modification de paramètres .........................................................94
Figure 49 Génération de la couche d’abstraction du matériel.............................................95
Figure 50 L'adaptation pour développer le logiciel.............................................................97
Figure 51 Co-simulation avec SystemC .............................................................................99
Figure 52 Connexion entre une simulation SystemC et un émulateur ................................99
Figure 53 Co-émulation en utilisant une connexion multi-ICE.........................................100
Figure 54 Co-émulation en utilisant une carte réseau.......................................................100
Figure 55 Co-émulation en utilisant un pont PCI/PCI ......................................................101
Figure 56 Co-émulation en utilisant une connexion USB.................................................102
Figure 57 L’expérimentation sur co-émulation.................................................................103
vi
Liste des tableaux
LISTE DES TABLEAUX
Tableau 1 Evolution de la technologie d’intégration sur silicium [Cha99] ...........................7
Tableau 2 Tableau récapitulatif de technique de vérification..............................................29
Tableau 3 Allocation de l'architecture du VDSL sur la plateforme ARM Integrator ..........67
vii
Liste des tableaux
viii
Chapitre 1 : Introduction
CHAPITRE 1 : INTRODUCTION
1.1 Contexte : conception des systèmes multiprocesseurs monopuces......................................................2
1.1.1 Introduction............................................................................................................................................. 2
1.1.2 La conceptions des systèmes monopuces ........................................................................................... 3
1.2 Nécessité de la vérification............................................................................................................................5
1.3 Les techniques de vérification des systèmes monopuces .......................................................................6
1.4 Nécessité du prototypage pour réduire le temps de conception...........................................................7
1.5 Contributions...................................................................................................................................................9
1.5.1 Définition d’un flot de prototypage basé sur une plateforme reconfigurable................................. 9
1.5.2 Automatisation du flot du prototypage................................................................................................ 9
1.5.3 Proposition d’une solution de co-émulation basée sur une plateforme reconfigurable ................ 9
1.6 Plan du mémoire...........................................................................................................................................10
1
Chapitre 1 : Introduction
1.1 Contexte : conception des systèmes multiprocesseurs monopuces
1.1.1 Introduction
Cette thèse s’inscrit dans le contexte de la conception des systèmes monopuces. Ces
systèmes intègrent sur une même puce plusieurs processeurs ainsi que des composants
complexes et hétérogènes (mémoires, périphériques, unités de calcul spécifiques). On utilise
le terme « Multiprocessor System-on-Chip/MPSoC » en anglais pour décrire ces systèmes.
Ces systèmes prennent une place de plus en plus importante dans l’industrie de la
microélectronique. Les prévisions d’ITRS prévoient qu’en 2005, 70 % des ASIC intégreront
au moins un processeur. Cela se confirme par l’existence de nombreuses applications
complexes telles que les téléphones portables, les «set-top box», les consoles de jeux, les
appareilles photos numériques qui intègrent des systèmes monopuces comprenant un ou
plusieurs processeurs. Toutes ces applications correspondent à des productions de masse et
requièrent des performances très élevées, ce à quoi répondent les systèmes monopuces. Ces
systèmes semblent devenir les systèmes pilote de l’ind ustrie microélectronique du futur.
Les systèmes monopuces sont généralement dédiés à des applications spécifiques.
Comme les systèmes embarqués classiques, ils comportent des parties logicielles
(programme s’exécutant sur un processeur, DSP, ou autre type de processeur) et des parties
matérielles (composants spécifiques). Les fonctionnalités offertes par les parties logicielles et
matérielles sont spécifiquement adaptées pour respecter les objectifs (coût, performance,
consommation,…).
La Figure 1 présente un système monopuce avec des parties matérielles et des parties
logicielles. Pour répondre aux contraints de temps de mise sur le marché et de coût,
l’architecture matérielle d’un système multiprocesseur monopuce est obtenue par
l’assemblage de composants connectés à travers un réseau de communication.
Le développement des parties logicielles devient tellement complexe, qu’il est
nécessaire de le commencer le plus tôt possible, et ne plus attendre que le circuit (en fait les
parties matérielles) soit disponible s. Le logiciel est organisé en couches. Chaque couche
traite un aspect différent : abstraction du matériel, gestion des ressources, protocoles de
communication, etc.
2
Chapitre 1 : Introduction
Gestion de ressources
Gestion de la communication
Système
d’exploitation
Couches logicielles
Code de l’application
Logiciel spécifique
à une fonctionnalité
Abstraction du matériel
Architecture locale
(DSP et mémoire locale)
Architecture matérielles
Architecture locale
(Processeur et mémoire locale)
Sous -système
(processeurs)
IP
Mémoire
globale
Sous -système
(DSP)
Adaptateur de
communication
Adaptateur de
communication
Adaptateur de
communication
Adaptateur de
communication
Réseau de communication
Figure 1 Représentation de système monopuce
1.1.2 La conceptions des systèmes monopuces
La complexité des systèmes multiprocesseurs monopuces et l'hétérogénéité des
composants sont telles que les méthodes de conception d’ASIC ou de systèmes embarqués
ne peuvent plus s’appliquer. Il a donc fallu trouver une nouvelle façon de concevoir ces
systèmes. Leur conception se décompose en plusieurs étapes (Figure 2) et commence à un
haut niveau d’abstraction, ce qui permet de s’affranchir de nombreux détails.
A un haut niveau d’abstraction, on s’intéresse à la fonctionnalité, indépendamment de
l’implémentation finale, ce qui correspond à la conception de niveau système. A ce niveau de
conception, on recherche des algorithmes et des représentations de données les plus adaptés
pour réaliser la spécification. On obtient une spécification fonctionnelle que l'on valide
généralement par simulation.
Quand la spécification fonctionnelle est correcte, l’étape suivante consiste à trouver
une architecture efficace. C’est l’exploration d’architectures qui détermine l’implémentation
logicielle ou matérielle de tous les composants. Grossièrement, les composants qui
nécessitent des performances élevées sont implémentés en matériel, et ceux qui nécessitent
de la flexibilité sont implémentés en logiciel. On choisit aussi dans cette étape les
composants physiques (processeur, DSP), qui exécuteront les parties logicielles, ainsi que
3
Chapitre 1 : Introduction
l’architecture mémoire, la gestion des E/S, …. A la fin de cette étape, on obtient les
spécifications de chaque composant matériel et logiciel.
Spécification
du système
Conception
de niveau système
(1) Vérification de la spécification
fonctionnelle
Spécification
fonctionnelle
Exploration
d’architecture
(2) Vérification de l’architecture du
système
Spécification
des parties matérielles
Spécification
des parties logicielles
Conception
du matériel
Conception
du logiciel
Composants
matériels
Composants
logiciels
(3) Vérification de l’implémentation
des composants du système
Intégration
logiciel-matériel
(4) Vérification de l’intégration de
composants hétérogènes
SoC
(5) Vérification finale du système
(détecter tous les bogues avant
fabrication)
Figure 2 Flot de conception des systèmes monopuces
Les étapes suivantes sont la conception du matériel et du logiciel. Le principe est de
réutiliser des composants existants, ce qui permet de gagner du temps par rapport à une
conception complète de tout le système. Pour les composants matériels qui n'existent pas, la
conception peut suivre le flot de conception traditionnel avec les différentes étapes de
synthèse (comportementale, logique puis physique). Le logiciel est implémenté en couche
pour séparer les différentes fonctionnalités. Au plus bas niveau, des pilotes ("Hardware
Abstraction Layer") permettent d'accéder aux ressources matérielles. Au dessus, le système
d'exploitation gère l'exécution des différentes taches de l'application, ainsi que les E/S. Enfin
le code de l'application s'exécute à travers le système d'exploitation (Figure 1).
4
Chapitre 1 : Introduction
La dernière phase est la phase d'intégration logiciel/matériel. Il s'agit d'une part de
vérifier que le logiciel s'exécute correctement sur les composants programmables, mais aussi
que les échanges d'informations entre les composants sont corrects. Pour ces échanges
d'informations, des composants d'interface (adaptateur de communication) sont nécessaires
et sont placés entre les composants et le réseau de communication pour adapter les différents
protocoles et le type de données. Entre un processeur et le réseau de communication, ces
adaptateurs de communication peuvent être complexes avec une partie logic ielle (pilotes du
processeur) et une partie matérielle (composant d'interface). La réalisation de ces composants
d'interface est une des difficultés de la conception de SoC, et leur génération automatique est
un des axes de recherche de l'équipe SLS du laboratoire TIMA. Ceci facilite l'exploration
d'architectures, accélère la conception, et réduit les erreurs lors de la conception de ces
interfaces.
1.2 Nécessité de la vérification
A chaque étape de la conception, le concepteur doit s’assurer que les nouveaux
composants ou les nouveaux détails de réalisation qu’il rajoute font que la nouvelle
description du système respecte toujours les spécifications.
La vérification des systèmes monopuces est un processus exigeant. A cause de leur
complexité et de leur hétérogénéité, il faut des techniques qui permettent de vérifier plusieurs
aspects : aspects fonctionnel et architectural, aspects logiciel et matériel, et la
communication. Naturellement, les concepteurs qui effectuent ces vérifications doivent
posséder toutes ces compétences techniques.
La vérification de tels systèmes est une étape clé dans leur conception. La vérification
s’applique autour d’au moins cinq points montrés sur la Figure 2 :
1. Pour vérifier la fonctionnalité
2. Pour vérifier l’architecture du système
3. Pour vérifier les fonctionnalités et la compatibilité des composants hétérogènes
4. Pour vérifier l’intégration des composants.
5. Pour tester le système dans son environnement avant sa fabrication.
5
Chapitre 1 : Introduction
Le coût de vérification des systèmes monopuces est très élevé surtout en terme d’effort
et de temps. En effet, on estime que 70 % du temps de conceptions est passé pour effectuer la
vérification.
Le coût financier de la conception est aussi très élevé. Le prix d’un jeu de masques
dans une technologie avancée étant de l’ordre de 0,5 millions d’euros, une erreur détectée
après la fabrication du circuit entraîne un surcoût. Pour cette raison, le système doit être
rigoureusement vérifié avant sa fabrication, ce qui permet de réduire de façon significative
son coût.
1.3 Les techniques de vérification des systèmes monopuces
Il existe plusieurs techniques de vérifications : la vérification formelle, la simulation,
l’émulation, et le prototypage. Chacune de ces techniques utilise un modèle différent. La
vérification formelle emploie des notations formelles pour représenter les caractéristiques du
système qui permettent de vérifier certaines propriétés. La technique de simulation emploie
des modèles d'exécution et des modèles de calcul sur ordinateur. L’émulation emploie des
modèles physiques qui imitent le comportement du matériel. Et le prototypage combine ces
divers modèles et composants matériels.
Chacune de ces techniques possède ses caractéristique s, ce qui leur donne plus ou
moins d’intérêt selon ce qui est attendu de la vérification. Par exemple, la simulation est
considérée comme d’une grande flexibilité, puisque changer le modèle d’une fonction ou
d’un composant dans la représentation du système est très facile. C’est actuellement la
technique la plus utilisée. Mais on atteint ses limites de performances dès qu’il s’agit d’une
simulation à bas niveau d’abstraction (avec tous les détails de réalisation) en recherchant une
précision élevée.
Le prototypage consiste à réaliser le système sur une architecture différente de celle
prévue pour la réalisation finale. Tous les composants ou sous-systèmes de la description
sont soit remplacés par des composants physiques (logiciel ou matériel), soit émulés ou
simulés. Le développement d’un prototype spécifique à une application est très coûteux, et
on préfère une plateforme « générique », permettant de réaliser plusieurs applications.
Un autre problème apparaît dans la vérification quand un composant physique n’est
pas encore disponible. Ceci repousse la réalisation du prototype et augmente aussi le temps
6
Chapitre 1 : Introduction
de conception. Dans ce cas, une solution mixte basée sur le prototypage et la simulation (coémulation) semble plus appropriée.
1.4 Nécessité du prototypage pour réduire le temps de conception
Malgré la comple xité des applications, les réalités du marché exigent un temps de
conception de plus en plus court. En effet, la compétition pour un marché de masse est
exigeante et l’évolution des applications est très rapide. Le Tableau 1 donne une idée de
l’évolution des applications, de leur coût et de leur temps de développement dans les 8
dernières années [CHA99]. On peut voir que la capacité d’intégration et la complexité de
l’application ont augmentées rapidement. Mais le temps de conception des nouveaux
produits et des produits dérivatifs est réduit.
Pour avoir un idée de l’importance du temps de conception et de détection des bogues
avant fabrication, on peut revenir sur un exemple provenant de NEC [DAL00]. Pour
fabriquer son circuit « set-top box », le coût des trente masques nécessaire était de 1,2
million dollars américain, en technologie 0,13 micron. A cette époque, NEC prévoyait un
retard de deux mois dans le lancement de son circuit, ce qui devait lui coûter plus de 50
millions de dollars en terme de vente.
1997
1998
1999
2002
0,35 µm
0,25 µm
0,18 µm
0,13 µm
1,5-2,0 milliards
2,0-3,0 milliards
3.0-4,0 milliards
> 4,0 milliards
18 - 12 mois
12 - 10 mois
10 - 8 mois
8 - 6 mois
temps de conception d'un
produit dérivé
8 - 6 mois
6 - 4 mois
4 - 2 mois
3 - 2 mois
capacitè d'intégration sur
silicium
200 K - 500 K portes
logiques
1 M - 2 M portes
logiques
4 M - 6 M portes
logiques
10 M - 25 M portes
logiques
applications internet
contrôleur interconnecté
et intelligent
technologie du process
cout d'instalation de l'usine
(en dollar américain)
temps de conception
application typique
telephone portable, PDA, Set-top boxes, PDA sans
DVD
fil
Tableau 1 Evolution de la technologie d’intégration sur
silicium [Cha99]
Les systèmes monopuces contiennent à la fois des composants matériels complexes
(processeur, décodeurs vidéo, audio, etc.) et une énorme quantité de logiciel. On entend par
logiciel le programme de l’application, mais aussi les systèmes d’exploitation et les pilotes
d’E/S. Le logiciel devient tellement complexe que sa vérification n’est plus réaliste en
7
Chapitre 1 : Introduction
utilisant des approches classiques de simulation basée sur des ISS (simulateur de processeur
en instruction près, Anglais : instruction set simulator). En effet, l’enquête de EDC découvre
que 70 % des concepteurs de système embarqué dépense plus de 50% du temps de
(c)
Avec prototypage
basé sur une
plateforme
reconfigurable
Conception de
niveau système
(b)
Avec prototypage
spécifique à
l’application
Conception de
niveau système
(a)
Sans
prototypage
Conception du matériel
Conception du matériel
Conception de
niveau système
conception pour développer de la partie logiciel [EVA03].
Conception du matériel
Fabrication
de la puce
L’intégration logicielle
matérielle
Conception du logiciel
Fabrication
de la puce
L’intégration logicielle
matérielle
Prototypage
Conception du logiciel
Prototypage &
co-émulation
Fabrication
de la puce
L’intégration logicielle
matérielle
Conception du logiciel
12
18
24 mois
Figure 3 Effet du prototypage sur la conception d’un système
monopuce
La Figure 3 montre l’intérêt du prototypage en raccourcissant le temps de conception.
Attendre la réalisation de l’architecture matérielle pour développer le logiciel et vérifier
l’intégration logiciel/matériel (Figure 3.a) entraîne un temps de conception très long. Le
prototype est une solution pour diminuer le temps de conception. En effet, un prototype peut
être employé pour effectuer la vérification logiciel/matériel et développer le logiciel avant
que le circuit ne soit disponible (Figure 3.b), mais le développement d’un prototype
spécifique à l’application requiert lui aussi beaucoup de temps et d’effort. On peut réduire ce
temps et cet effort en utilisant une plateforme reconfigurable, ce qui revient à modifier
légèrement l’architecture de la plateforme pour faire fonctionner chaque nouvelle application
(Figure 3.c).
8
Chapitre 1 : Introduction
1.5 Contributions
1.5.1 Définition d’un flot de prototypage basé sur une plateforme reconfigurable
Pour réduire le temps et l’effort de développement du prototype, nous proposons une
solution basée sur l'utilisation d'une plateforme reconfigurable et un flot pour transposer
l'architecture du système monopuce sur cette plateforme reconfigurable. L'approche
proposée permet de prototyper systématiquement des applications. Le processus prend en
entrée un modèle de niveau RTL de l'application. L'application et la plateforme
reconfigurable doivent être adaptées pour obtenir le prototype. Nous décomposons le
processus de prototypage en quatre étapes: (1) assigner chaque partie de l'application à la
plateforme, (2) configurer la plateforme pour être aussi proche que possible de l’architecture
du système, (3) adapter l’architecture du système (si c’est encore nécessaire), et (4) cibler
(compilation, synthèse, routage, …) l’architecture adaptée sur la plateforme configurée. Les
solutions
proposées
tiennent
compte des contraintes typiques des plateformes
reconfigurable s existantes.
1.5.2 Automatisation du flot du prototypage
La recherche d’une automatisation du flot de prototypage est une contribution
importante, puisque le but est d’une part de facilité la tâche du concepteur en lui évitant des
tâches difficiles et répétitives, et d’autre part de réduire le temps d’obtention du prototype.
La configuration de la plateforme et l’adaptation de la description du système sont les deux
étapes auxquelles nous nous sommes intéressés.
L’adaptation est une étape très difficile, car elle demande de la part du concepteur de
modifier le code de bas niveau de l’application. Mais cette étape est facilitée par l’utilisation
d’outils de génération automatique développés au sein de l’équipe SLS pour la conception
des SoC. On peut donc s’appuyer sur ces outils de production pour adapter le code à la
plateforme, ce qui revient à modifier la spécification de ce code en tenant compte des
caractéristiques de la plateforme.
1.5.3 Proposition d’une solution de co-émulation basée sur une plateforme
reconfigurable
Pour résoudre le problème de non disponibilité de composants physiques, nous
pouvons combiner la simulation, l'émulation, et l'ut ilisation de vrais composants (co9
Chapitre 1 : Introduction
émulation). Une co-émulation employant la plateforme reconfigurable est une solution bon
marché pour la vérification matériel/logiciel. Cette technique est appliquée en utilisant la
plateforme ARM Integrator et un simulateur SystemC.
1.6 Plan du mémoire
La suite de ce mémoire est composée de six chapitres :
•
Le chapitre 2 présente les techniques de vérification qui sont utilisées dans la
conception de systèmes multiprocesseurs monopuces, ainsi que leurs intérêts, leurs
points forts, et leurs défauts.
•
Le chapitre 3 définit le flot de prototypage sur une plateforme reconfigurable. Nous
discutons du modèle utilisé, du cas idéal, et du flot typique.
•
Le chapitre 4 décrit le prototypage d’applications (VDSL et DivX).
•
Le chapitre 5 porte sur l’évaluation des applications du chapitre 4. Ce chapitre donne
une formalisation de l’automatisation du flot de prototypage et des perspectives
autour de la co-émulation.
•
Enfin, chapitre 6 conclut ces travaux et donne des perspectives.
10
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
CHAPITRE 2 : VERIFICATION DES SYSTEMES
MONOPUCES : TECHNIQUES ET
COMPARAISON
2.1 Introduction...................................................................................................................................................12
2.2 Objectif de la vérification d’un système monopuce..............................................................................12
2.2.1 Vérifier la spécification fonctionnelle ............................................................................................... 13
2.2.2 Vérifier l’architecture du système ...................................................................................................... 13
2.2.3 Vérifier l’implémentation des composants du système................................................................... 13
2.2.4 Vérifier l’intégration de composants hétérogènes ........................................................................... 14
2.2.5 Détecter tous les bogues avant la fabrication ................................................................................... 14
2.3 Difficultés de la vérification d’un système monopuce ..........................................................................15
2.3.1 Hétérogénéité........................................................................................................................................ 15
2.3.2 Complexité............................................................................................................................................ 15
2.3.3 Il n’existe pas encore d'outils de déboguage de systèmes multiprocesseurs ................................ 16
2.4 Diverses techniques de vérification des systèmes monopuces ............................................................16
2.4.1 Critères de comparaison des techniques de vérification des systèmes monopuces..................... 16
2.4.2 La vérification formelle ....................................................................................................................... 18
2.4.2.1 Coût................................................................................................................................................. 19
2.4.2.2 Modèle ............................................................................................................................................ 19
2.4.2.3 Flexibilité........................................................................................................................................ 19
2.4.2.4 Utilité............................................................................................................................................... 20
2.4.3 La simulation sur ordinateur............................................................................................................... 20
2.4.3.1 Coût................................................................................................................................................. 22
2.4.3.2 Modèle ............................................................................................................................................ 22
2.4.3.3 Flexibilité........................................................................................................................................ 23
2.4.3.4 Utilité............................................................................................................................................... 23
2.4.4 L’émulation........................................................................................................................................... 23
2.4.4.1 Coût................................................................................................................................................. 24
2.4.4.2 Modèle ............................................................................................................................................ 25
2.4.4.3 Flexibilité........................................................................................................................................ 25
2.4.4.4 Utilité............................................................................................................................................... 25
2.4.5 Le prototypage...................................................................................................................................... 25
2.4.5.1 Coût................................................................................................................................................. 27
2.4.5.2 Modèle ............................................................................................................................................ 27
2.4.5.3 Flexibilité........................................................................................................................................ 27
2.4.5.4 Utilité............................................................................................................................................... 28
2.4.6 Synthèse des différentes techniques .................................................................................................. 28
2.5 Le prototypage basé sur une plateforme reconfigurable ....................................................................30
2.5.1 Intérêt du prototypage pour les systèmes monopuces ..................................................................... 30
2.5.2 Intérêt du prototypage basé sur une plateforme reconfigurable..................................................... 30
2.5.3 Intérêt de la co-émulation basée sur une plateforme reconfigurable............................................. 31
2.5.4 Exemples de flot de prototypage industrielle ................................................................................... 31
2.5.4.1 Aptix................................................................................................................................................ 31
2.5.4.2 Flexbench........................................................................................................................................ 35
2.6 Conclusion......................................................................................................................................................37
11
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
2.1 Introduction
Ce chapitre introduit dans un premier temps les objectifs de la vérification d’un
système monopuce tout au long du flot de conception. Les difficultés et les différentes
techniques de vérification sont ensuite développées, en insistant plus particulièrement sur le
prototypage sur une plateforme reconfigurable. La dernière partie de ce chapitre décrit
quelque méthodes et flot de prototypage issus de technologies industrielles.
2.2 Objectif de la vérification d’un système monopuce
Dans la création des systèmes numériques, on doit s'assurer que les produits finaux
fonctionnent correctement. La création de ces produits consiste en deux phases [WEB99C]
principales : la conception et la fabrication (Figure 4). Ces deux phases exigent chacune un
processus de vérification : la vérification de la conception (en anglaise : design verification)
et le test ou diagnostic de la fabrication (en anglaise : manufacturing test and diagnosis). Le
premier processus est là pour s'assurer que le système est correctement conçu, c'est-à-dire
que le système correspond exactement à ce que l’on veut. Le deuxième permet de s'assurer
que le produit fabriqué est identique au système conçu.
La spécification
La Conception
la vérification de
la conception
La Fabrication
le test et le
diagnostic de la
fabrication
Un système numérique
Figure 4 : Création d'un produit numérique
L’objectif du groupe SLS étant de concevoir des systèmes monopuces, on s’intéresse
uniquement à la partie vérification de la conception. La vérification s’applique à chaque
étape de la conception, et plus particulièrement pour vérifier la spécification fonctionnelle,
l’architecture du système, l’implémentation des composants, l’intégration des composants et
le système complet avant sa fabrication. Ces cinq critères sont abordés dans les paragraphes
suivants.
12
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
2.2.1 Vérifier la spécification fonctionnelle
A partir de la spécification du système, on obtient une spécification fonctionnelle en
développant une solution. Elle consiste à développer les algorithmes et à définir les
représentations de données, ce qui correspond à une première optimisation. Les solutions
retenues vont affecter tout le processus de conception et la performance du système. Ainsi,
l’optimisation a un effet beaucoup plus significatif à cette étape que si elle est effectuée à bas
niveau tel qu’au niveau porte logique.
Il faut vérifier aussi que toutes les contraintes fonctionnelles sont respectées. Il y a
deux types de contraintes fonctionnelles : celles qui sont imposées par l’environnement et
celles exigées par les clients/utilisateurs. Un exemple de contraintes imposées par
l’environnement est le protocole utilisé pour connecter le système à un réseau existant. Un
exemple de contraintes exigées par l’utilisateur est la compatibilité avec une ancienne
version. Mais il faut tenir compte de ces contraintes dès le début de la conception.
2.2.2 Vérifier l’architecture du système
Quand une bonne spécification fonctionnelle est trouvée, les concepteurs cherchent
une architecture pour l’implémenter. Si plusieurs architectures sont possibles, les
concepteurs ont besoin d'évaluer la qualité et de vérifier la performance de chaque
architecture. Cette étape correspond à l’exploration d’architecture.
A cette étape, le découpage de l’algorithme est fait. Les composants sont choisis pour
exécuter chaque fonction. La spécification de chaque composant est définie. Il reste à vérifier
que les autres contraintes (non fonctionnelles) sont respectées. Les contraintes sont par
exemple : la fréquence maximum, la surface maximum autorisée, la consommation
d’énergie, …
2.2.3 Vérifier l’implémentation des composants du système
Quand la spécification de chaque composant est fixée, les composants sont développés
(l'implémentation). Les développements sont effectués par des équipes différentes, mais on
peut aussi réutiliser des composants existants. La fonctionnalité de tous les composants doit
être vérifiée individuellement, pour s'assurer qu'ils respectent bien les spécifications. Même
s’ils seront vérifiés après l’intégration, la vérification de chaque composant est très
13
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
importante, car il est beaucoup plus facile de localiser la source d’un bogue à ce niveau
qu'après l’intégration.
Du fait de la provenance variée des composants, il faut aussi vérifier la compatibilité
entre ces composants (protocoles et échanges de données entre les composants par exemple).
Dans le cas contraire, la performance du système peut fortement baisser.
2.2.4 Vérifier l’intégration de composants hétérogènes
L’étape suivante dans la conception est l’intégration de ces composants. C'est une
étape très délicate, du fait que les composants peuvent provenir de sources différentes. Il faut
développer des interfaces de communication pour permettre l'échange de données et la
synchronisation entre les composants. Ces interfaces comprennent des parties matérielles et
des parties logicielles.
A cette étape, les concepteurs vérifient : (1) les interfaces développées, (2) la
fonctionnalité des composants et la compatibilité entre les composants, et (3) la performance
du système après l’intégration. Les fonctionnalités et les compatibilités des composants sont
vérifiées encore une fois car c’est souvent pendant l'intégration que les bogues apparaissent.
La performance du système après l’intégration est mesurée car les interfaces utilisées
entraînent des délais qui peuvent réduire les performances.
2.2.5 Détecter tous les bogues avant la fabrication
Quand toutes les étapes de la conception sont effectuées, une dernière vérification est
nécessaire avant la fabrication. Il s'agit de mettre en œuvre le système complet pour vérifier
que tous les aspects de ce système sont conformes à la spécification dans toutes les
conditions. Normalement, une longue séquence de test est appliquée.
Cette étape de vérification est la dernière étape avant la fabrication. Ce qui signifie que
les erreurs non détectées seront présentes sur le système réel. Les erreurs non détectées avant
la fabrication augmente considérablement le coût du système et retarde la mise sur le marché
d’une version non boguée.
Dans cette dernière étape de vérification, les concepteurs testent le système dans son
environnement physique. Cet environnement est celui ou il sera utilisé (par exemple, on teste
un prototype de téléphone portable sur un réseau GSM). Si c’est possible, le système doit
être testé par un futur utilisateur. L’environnement physique et le comportement de
14
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
l’utilisateur en manipulant le système complexe sont souvent imprévisibles, ce qui est
difficile à réaliser avec une séquence de test.
2.3 Difficultés de la vérification d’un système monopuce
2.3.1 Hétérogénéité
Une des difficultés dans la vérification d’un système monopuce provient de
l’hétérogénéité des objets ou concepts manipulés. En effet, il faut vérifier les composants
physiques mais aussi les programmes (système d’exploitation, application, interface
utilisateur) qui s’exécutent sur les composants programmables. Et tous ces objets possèdent
leurs propres critères à vérifier.
Mais certains compromis sont difficiles à évaluer. Pour illustrer ceci, supposons un
système qui traite les commandes reçues d’un utilisateur. Si la spécification indique que le
système doit répondre rapidement, les concepteurs diminueront la latence des interruptions.
Mais si ce même système, dans sa partie traitement du signal à haut débit ne doit pas être
interrompu dans une partie critique du code, alors une interruption attendra l’exécution d’une
partie du code moins critique pour être prise en compte. Comment vérifier dans ce cas le
compromis fait par les concepteurs ?
Les difficultés peuvent venir aussi de la nature des composants, surtout, si ils ont été
développés par plusieurs équipes. Par exemple, un nom différent donné à un même signal
devient une source de confusion pour la vérification.
Les niveaux d’abstraction entraînent aussi des difficultés. Si les composants d’un
système sont décrits à différents niveaux d’abstraction (description comportementale d’un IP
pour la simulation, modèle synthétisable pour d’autres), la simulation devient une simulation
mixte (ou co-simulation) qui n’est pas toujours facile à mettre en œuvre.
2.3.2 Complexité
La complexité des systèmes monopuces est aussi une source de difficulté. Les erreurs
dans une grande quantité de matériel sont très difficiles à trouver car les concepteurs ne
peuvent observer qu’un nombre limité de signaux en même temps. Même si les concepteurs
connaissent les signaux à observer, ils ne peuvent pas observer ces signaux pendant une très
longue période car les outils n’enregistrent l’évolution de ces signaux que pendant un temps
15
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
limité. Le déboguage du matériel est un jeu qui consiste à observer les bons signaux au bon
moment.
Quand une erreur est détectée sur un signal, il faut trouver l’origine du problème. Pour
se faire, on sélectionne un nouvel ensemble de signaux et on recommence la séquence de
vérification avec les mêmes vecteurs de test.
Les logiciels complexes sont aussi difficiles à déboguer et coûtent un temps important.
Le parallélisme de tâches, les exceptions, et la dépendance d’exécution du code à des
données rendent la reproduction d'une erreur très difficile. On a alors besoin de nombreux
vecteurs de test pour reproduire cette erreur, et il faut une exécution pas à pas pour trouver la
source d’erreur.
A cela s'ajoute le fait qu'un système complexe offre beaucoup de possibilités
d’utilisation. Comme le comportement de l’utilisateur peut être imprévisible, il est
impossible de créer des séquences de test correspondant à toutes les utilisations possibles.
2.3.3 Il n’existe pas encore d'outils de déboguage de systèmes multiprocesseurs
Même si dans le flot de conception, les parties matérielles et logicielles peuvent être
développées en même temps, en réalité, il est difficile de développer le logiciel sans avoir le
matériel pour l'exécuter. De plus, on a besoin d'outils pour contrôler et observer l’exécution
des programmes. Comme ces outils n’existent pas encore, les concepteurs doivent utiliser
des outils de déboguage de systèmes monoprocesseurs. Et cette technique n’est pas très
efficace.
2.4 Diverses techniques de vérification des systèmes monopuces
2.4.1 Critères de comparaison des techniques de vérification des systèmes monopuces
La plus grande différence entre un système monopuce et un ASIC traditionnel est la
grande quantité de logiciel exigée par le système. Ce logiciel inclut le SE, les pilotes de
périphériques, la partie logicielle de l'interface de communication, et le logiciel de
l'application. Pour vérifier le logiciel lors du développement, il existe plusieurs techniques.
Par exemple, on peut utiliser la simulation pour valider le développement de certains pilotes
de périphériques de bas niveau avec des performances de l’ordre de quelques centaines de
kilohertz. Cependant, pour les autres parties de logiciel, il est nécessaire de mettre en œuvre
16
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
d’autres techniques avec d’autres caractéristiques pour vérifier le système avant fabrication
et pour vérifier l’intégration du logiciel sur le matériel.
Dans ce chapitre, nous décrivons quatre techniques de vérification qui utilisent
différents modèles. Ces techniques sont la vérification formelle, la simulation, l’émulation, et
le prototypage. La discussion est abordée du point de vue théorique. Dans l'utilisation
pratique, ces techniques sont combinées et les termes sont très souvent mélangés. Par
exemple, ce qui s'appelle la simulation avec un accélérateur de matériel est dans la pratique
une combinaison de technique de simulation et d'émulation.
Il y a quatre caractéristiques principales permettant de comparer des techniques de
vérification de systèmes monopuces : coût, modèle, flexibilité, et utilité.
Le coût en terme d’argent, de temps, et d'effort est naturellement la caractéristique la
plus importante puisque toutes ces techniques visent à réduire le coût. Il y a principalement
deux facteurs qui constituent le coût: (1) le coût pour établir le modèle, et (2) le coût du
procédé de vérification qui utilise ce modèle.
D'une façon générale, le coût pour détecter un problème plus tôt dans la conception et
pour le corriger est beaucoup moins élevé que si il est découvert plus tard. Le coût pour
résoudre un problème matériel est beaucoup plus élevé que pour un problème logiciel.
Souvent, on préfère résoudre un problème matériel en utilisant une solution logicielle quand
c’est possible.
Le modèle est la caractéristique principale qui différencie ces différentes techniques.
La vérification formelle emploie des notations formelles. La technique de simulation emploie
des modèles d'exécutions et des modèles de calcul sur ordinateur. L’émulation emploie des
modèles physiques qui imitent le comportement du matériel. Et le prototypage combine ces
divers modèles et composants matériels.
La flexibilité correspond à la facilité de changer, d'adapter ou de modifier le modèle
du système. Elle est très importante, particulièrement quand la conception n'est pas encore
trop avancée, et que des modifications sont nécessaires. Normalement, la technique est plus
flexible quand il faut moins d'effort et de ressources pour arriver au modèle. Il est facile de
comprendre que le logiciel est beaucoup plus flexible que le matérie l. Par conséquent, une
technique utilisant des modèles logiciels est beaucoup plus flexible.
17
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Par exemple, supposons que des développeurs de logiciels détectent un problème qui
est très difficile à résoudre avec un nombre de registres donné, mais qui devient trivial si au
moins un registre supplémentaire est disponible. Si la puce est fabriquée, les développeurs
n’ont pas d’autres alternatives que de corriger le problème avec une solution logicielle,
même si celle ci dégrade les performances. Au contraire, si le logiciel est développé sur une
architecture matérielle flexible, le registre supplémentaire est ajouté et le problème est résolu
plus facilement.
L’utilité d'une technique est déterminée par les facteurs suivants : précision, vitesse,
observabilité, et objectif de la vérification. Les trois premiers facteurs (précision, vitesse, et
observabilité) déterminent si une technique convient à un objectif donné. Pour un objectif
donné, il y a un niveau approprié de ces trois facteurs requis.
La précision est associée à l'exactitude, à la granularité des événements, et à la
granularité du temps. L'observabilité est associée à la capacité d’observer et de contrôler
l'état du modèle. La vitesse indique le temps nécessaire pour effectuer la vérification du
modèle.
La suite de cette section décrit les quatre techniques que sont la vérification formelle,
la simulation, l’émulation et le prototypage du point de vue des caractéristiques
précédemment citées.
2.4.2 La vérification formelle
Il y a deux types de vérification fo rmelle [STA94] : le déboguage de la spécification et
la vérification de l’implémentation. Le premier type vérifie si la spécification est bien décrite
et si tous les besoins sont bien inclus. Le deuxième type vérifie si la spécification est bien
implémentée.
Jusqu’à présent, la technique de vérification formelle n’est pas encore largement
utilisée dans la conception de systèmes monopuces. Les obstacles principaux sont [ROS98] :
(1)
La complexité du processus de vérification est très grande donc elle est utilisée dans des
cas simples.
(2)
Cette technique a besoin d’interactions entre les concepteurs et les outils, donc
l’automatisation est le point faible de cette technique. Ce point faible implique que cette
technique est difficile à utiliser pour les systèmes complexes.
18
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
(3)
Il est difficile de prendre en compte l’environnement.
(4)
Les techniques utilisées pour le matériel et le logiciel sont différentes à cause de leurs
caractéristiques différentes. Le matériel est traité en tant que système parallèle
synchrone. Par exemple, en vérification formelle, le matériel est décrit en utilisant les
«binary decision diagram (BDD)». Les procédures de vérifications exploitent des
régularités et des «localisations». Le logiciel est traité en tant que système asynchrone
sériel. La technique de vérifications utilise une méthode « partial order reduction». La
vérification matériel/logiciel est très rarement effectuée car le nombre d’étapes nécessaire
pour vérifier le matériel et pour vérifier le logiciel est très différent. On peut avoir besoin
de cent étapes de vérification du matériel pour chaque étape du logiciel.
2.4.2.1 Coût
Le coût financier est faible, mais il est élevé en terme d’effort et de temps,
particulièrement si le système est complexe. Ce problème existe car il n’y a pas
d’automatisation pour prouver l’exactitude du système.
2.4.2.2 Modèle
La vérification formelle utilise un ensemble de notations prédéfinis pour construire le
modèle. Ce modèle s’appelle le modèle formel. L’utilisation d’une notation formelle donne
une précision élevée de la description du système. Malheureusement, elle est très complexe
donc difficile en mettre en œuvre.
La vérification formelle utilise des modèles différents pour le matériel et le logiciel.
Elle utilise les BDD pour le matériel et des modèles asynchrones sériels pour le logiciel
(algorithme ou organigramme). Il existe quelques travaux [POLIS] pour traiter la vérification
matériel/logiciel mais ils ne sont pas encore largement acceptés ou utilisés. Un autre
problème de la vérification formelle est la difficulté à l’intégrer avec d’autres techniques de
vérification car le procédé de vérification est différent. Au lieu de valider le système en
utilisant des vecteurs de test, son fonctionnement correct doit être prouvé formellement.
2.4.2.3 Flexibilité
Le modèle formel est très flexible. Il peut être utilisé pour un large éventail de
systèmes en utilisant une granularité variée. Le modèle est facile à modifier parce qu’il est
19
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
construit à la main. Il n’est pas nécessaire de passer par des procédés tels que la compilation
ou la synthèse, donc les modifications sont faciles à faire.
2.4.2.4 Utilité
La vérification formelle est très rapide quand elle est appliquée à un petit système
parce qu’avec cette technique, le système n’est pas validé en utilisant des vecteurs de test
mais prouvé formellement. Mais, la preuve d’un système complexe est un travail long et
fastidieux :
1. Modéliser un système complexe est long et difficile.
2. Il y a très peu d'automatisation dans le procédé de vérification donc des interactions
massives entre l’outil et le concepteur sont nécessaires. Ceci implique qu'il est trop
laborieux pour être appliqué aux systèmes complexes.
La précision de cette technique est très grande quand le système est décrit à un niveau
d’abstraction bas. L’observabilité de la vérification formelle est plutôt bonne. Les états du
système évalué peuvent être observés dans des situations variées. Pour un système simple,
les trois caractéristiques sont élevées mais pour
un système complexe, sa vitesse de
vérification est très faible.
2.4.3 La simulation sur ordinateur
Littéralement, la simulation est une approche basée sur un modèle pour l’analyse des
systèmes. Dans la conception des systèmes numériques, la simulation équivaut à tester le
comportement des systèmes en les exposant à des vecteurs de test, sauf que les systèmes sont
remplacés par un modèle sur ordinateur. Les modèles utilisés peuvent être des modèles de
calculs ou des modèles d’exécution.
La simulation est la technique la plus largement employée pour vérifier les systèmes
monopuces, les ASIC, et plus généralement les systèmes numériques et analogiques. Il y a
divers types de simulation, ils s’étendent de la simulation comportementale de haut niveau à
la simulation électrique/physique de très bas niveau. La précision et la vitesse de ces
simulations sont également variées. La simulation de plus bas niveau donne une excellente
précision jusqu'au temps physique de l’ordre de la pico seconde, mais à une vitesse très
réduite. La simulation de niveau plus élevé donne une précision moins bonne mais avec un
temps d'exécution plus rapide. Donc, il y a toujours un compromis entre vitesse et précision.
20
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Il y a beaucoup de travaux qui combinent ces différents types de simulation. Généralement,
les concepteurs combinent ces différents types de simulation pour profiter des avantages de
chaque niveau de simulation.
Il existe plusieurs classifications de niveau de simulation. Le nombre de niveaux et la
frontière entre ces niveaux sont différents, mais à un niveau élevé correspond une abstraction
élevée, donc une granularité moins fine et bien sur une précision moins bonne, mais la
vitesse d’exécution est plus rapide.
Par exemple, nous présentons six niveaux d’abstractions de la simulation [CLO02]
pour illustrer le compromis dans la simulation :
Le niveau fonctionnel modélise le comportement prévu du système, sans précision sur
la façon dont il sera réalisé. Ce niveau de simulation aide à comprendre le système. Un
exemple de ce niveau de simulation est l’exécution de la spécification de l'application. Cette
simulation aide les concepteurs à analyser les besoins du système.
Le niveau architectural saisit toute l'information nécessaire pour programmer le
matériel. Ce niveau de simulation aide les concepteurs à vérifier le logiciel pour le système,
particulièrement pour les parties qui sont indépendantes du matériel. L'exemple de cette
simulation est la simulation du modèle au niveau transactionnel (TLM). Ce niveau de
simulation peut être employé pour commencer le développement du logiciel (pour la partie
indépendante de matériel) et pour l'exploration d'architecture.
Le niveau micro architecture permet de faire une simulation avec une précision au
niveau cycle. Ce niveau de simulation est employé par les concepteurs pour commencer le
développement des pilotes de bas niveau, et pour mesurer les performances du système.
Le niveau RTL est évidemment un niveau d'abstraction qui décrit le système comme
un ensemble de registres et de relations logiques entre les registres avec des notions de temps
précis au cycle prés. Ce niveau est difficile à distinguer du niveau micro architecture puisque
normalement pour simuler au niveau cycle, le système doit être décrit au niveau RTL.
L’objectif principal de ce niveau est le point d'entrée des outils pour implémenter la partie
matérielle.
Le niveau porte logique décrit le système sous forme de portes logiques et de
registres. Ce niveau est utilisé par les outils de synthèse pour optimiser le matériel.
21
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Normalement, les concepteurs de matériel ne travaillent pas à ce niveau. Ce sont les outils
qui raffinent l’application de niveau RTL à ce niveau.
Le niveau de layout (dessin au micron) est le niveau le plus bas de simulation. Ce
niveau d'abstraction est employé pour extraire les paramètres physiques et les paramètres
électriques du matériel. La technologie d’implémentation est prise en compte à ce niveau
d’abstraction
Comme conclusion, il faut noter que : (1) le concepteur ne peut pas avoir une vitesse et
une précision élevées en même temps et également, (2) qu’il est difficile d'intégrer
l’environnement physique.
2.4.3.1 Coût
Les coûts financiers de simulation sont très divers. Ces coûts correspondent au coût de
l’ordinateur, le coût des outils de simulation, le coût de construction du modèle. Si le coût
des machines est indépendant du type de simulation, le coût des outils contribue fortement au
coût financier. Ce coût est varié et dépend au niveau d’abstraction et des outils ou vendeurs
choisis.
L'effort et le temps nécessaire pour effectuer la simulation dépendent du niveau de la
simulation. La simulation de plus bas niveau nécessite un effort plus élevé que les niveaux
plus hauts, parce que le modèle utilisé est plus difficile à construire (on a besoin d’écrire un
modèle de bas niveau ou d’extraire des paramètres pour ce modèle). Le temp s nécessaire
pour effectuer une simulation de bas niveau est plus long car le modèle utilisé est plus
complexe.
2.4.3.2 Modèle
Les modèles utilisés pour la simulation sont variés selon de niveaux d’abstraction
utilisés. Les langages de programmation (ou leurs extensions) sont utilisés pour décrire les
modèles de haut niveau d’abstraction (niveau fonctionnelle), niveau architecture, et niveau
micro architecture). Au niveau fonctionnel, on décrit le comportement du système dans le
modèle. Au niveau architecture et au niveau micro architecture, on décrit le modèle du
système comme un ensemble des composants interconnectés.
Au niveau RTL et au niveau porte logique, les systèmes sont décrits dans un langage
de description de matériel (par exemple : VHDL, Verilog, EDIF).
22
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Au plus bas niveau (layout), on décrit le système comme un ensemble de polygones en
plusieurs couches. Afin de simuler ce système, on doit extraire le circuit et ses paramètres.
Le résultat de cette extraction est un fichier qui décrit le système comme un circuit électrique
composé de composants électroniques élémentaires (transistor, diode, condensateur,
inducteur, résistance, etc.).
2.4.3.3 Flexibilité
La simulation est une technique très flexible car il est facile de modifier un modèle de
simulation. De plus, on peut combiner des modèles de différents niveaux.
2.4.3.4 Utilité
Selon les niveaux d’abstraction, vitesse et précision sont différentes. Le point faible de
la simulation est qu’une vitesse élevée et une précision élevée ne peuvent pas être obtenues
en même temps. L'observabilité de la simulation est bonne car on peut récupérer toute
l’évolution des états des signaux du système simulé. Pour la simulation de bas niveau, le
point faible est la vitesse tandis que pour la simulation de haut niveau, le point faible est sa
précision.
2.4.4 L’émulation
Le terme « émulation » est normalement associé à l’émulation logique, mais il est aussi
utilisé dans un sens différent dans le domaine de l’électronique numérique. Par exemple, un
émulateur en circuit (« In-Circuit Emulator » / ICE) est un outil de déboguage qui remplace
un microprocesseur par une prise et un câble reliés au PC.
La technique d'émulation est employée dans deux cas :
(1) Pour vérifier de comportement du matériel émulé en observant les entrées/sorties,
typiquement en utilisant une technologie basée sur des FPGA.
(2) Pour vérifier d’autres parties du système. On peut observer les comportements des autres
parties du système en regardant ses interactions avec le composant émulé. Par exemple
avec un «processor-ICE », les concepteurs vérifient le logiciel exécuté par le processeur
émulé.
L’émulation présente deux avantages par rapport à la simulation : elle permet un
nombre de vecteurs de test plus grand grâce à sa vitesse d’exécution plus rapide, et elle
permet une connexion à l’environnement physique. Mais il existe aussi quelques points
23
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
faibles de l’émulation. Il est difficile d’observer l’état des signaux internes, une erreur
temporelle est difficile à détecter, l’effort demandé est plus important (flot de
compilation/synthèse), le coût plus élevé (un émulateur coûte relativement cher) et il faut
décrire le système à un bas niveau. A cause de ces caractéristiques, l’émulation est employée
après plusieurs étapes de simulation (quand la conception du matériel est déjà avancée).
L'environnement d'émulation se compose de trois parties [WEB99b] : le matériel
programmable (l’émulateur), un compilateur, et le logiciel pour observer et contrôler
l'émulateur. Le matériel programmable agit comme un modèle du système à émuler. Le
compilateur accepte une description du système à émuler et il configure l’émulateur pour
modéliser le système. Le logiciel d'instrumentation et de contrôle est employé pour
commander et observer les entrées/sorties de l'émulateur.
Il existe plusieurs types de ma tériels utilisés [ROS98] pour l’émulation :
(1) l'émulateur basé sur un processeur. Ce type d’émulateur est composé d’un processeur
et d’un ensemble de registres. Les registres gardent l’état en cours du système. Le
processeur sert à calculer le prochain état du système et les sorties du système.
Quickturn CoBalt [SAW96] et Synopsys Arkos sont des émulateurs basés sur un
processeur.
(2) l'émulateur basé sur des FPGA. [ROS98] contient une illustration de plusieurs types
d’émulateur s basées sur des processeurs et des FPGA. Un exemple d’émulateur basé
sur FPAG est Mercury system de Quickturn.
(3) l'émulateur basé sur des composants programmables spécifiquement conçus pour
l’émulation. Des exemples de ce type d’émulateur sont Aptix prototyping system
[APT02] et Celaro de Mentor Graphics [MEN00]. Aptix utilise ses composants
spécifiques appelés FPIC (en Anglais : Field Programmable Interconnect Component)
pour construire un émulateur avec plusieurs FPGA. Mentor Graphics développe aussi
des composants spécifiques pour son émulateur (Celaro et VStation).
2.4.4.1 Coût
Le coût financier de l’émulation est très élevé. Le coût d'un émulateur logique
performant est de l’ordre de plusieurs centaines de milliers d’euros. L’effort et le temps
nécessaires pour émuler un système sont aussi élevés car les concepteurs doivent développer
24
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
un modèle du système qui respecte les contraints de synthèse/compilation, optimisation,
placement et routage.
2.4.4.2 Modèle
L'émulation utilise un modèle physique pour imiter le matériel émulé. Les
implémentations de ces modèles sont variées. Essentiellement, il y a deux types
d'implémentation d'émulateur : en utilisant du matériel configurable, et en employant un
processeur. Le point de départ de la plupart des techniques d'émulation est un modèle de
niveau RTL ou portes logiques.
2.4.4.3 Flexibilité
L’émulation est moins flexible que la simulation car il faut un modèle du système à
concevoir décrit à un bas niveau d’abstraction. Il faut aussi toujours passer par les étapes de
compilation/synthèse et placement et routage.
2.4.4.4 Utilité
L'observabilité de l'émulation est très faible puisque on ne peut observer que les
entrées-sorties du système. L'émulation est beaucoup plus rapide que la simulation. La
précision de l'émulation est très bonne (précis au cycle prés) car le système est décrit au
niveau RTL. La vitesse et la précision sont élevées mais l'observabilité reste faible.
2.4.5 Le prototypage
Dans la conception de systèmes monopuces, le prototypage est une réalisation
préliminaire d’un système sur une cible différente de la cible de réalisation finale
[HAR97a][CHA99]. Tous les composants de l'architecture doivent être inclus dans le
prototype. La réalisation de ces composants peut être diverse : vrais composants
logiciel/matériel, composants émulés, ou même composants simulés. Il existe aussi des
travaux pour intégrer la vérification formelle sur prototypage [KOR01]. Basée sur la
réalisation de ces composants, on peut définir plusieurs types de prototypage:
a. Le prototypage virtuel
L’implémentation d'un prototype virtuel se fait par simulation de tous les composants
qui constituent le système. On trouve également le terme de co-simulation, car
fondamentalement, il s'agit d'une simulation avec plusieurs simulateurs. On combine
25
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
alors dans cette technique les simulations basées sur des ISS, des simulations de niveau
RTL, des simulations de niveau fonctionnel, et des simulations de niveau transactionnel.
Le point faible d'un prototype virtuel est sa vitesse. En effet, on utilise les simulations
pour implémenter les composants, donc la vitesse n’est pas aussi élevée qu’en utilisant
des émulateurs ou des composants physiques. En plus, il est difficile de connecter un
prototype virtuel avec l’environnement physique du système.
L’avantage est sa flexibilité et son coût puisqu’il s’agit de simulatio n. Ce qui permet
aussi d’introduire des modèles de haut niveau.
b. Le prototypage matériel
Le prototypage matériel utilise des modèles physiques de composants pour réaliser le
système. Il existe deux types de prototype matériel : le prototype spécifique à
l’application et le prototype basé sur une plateforme reconfigurable.
•
Le prototype spécifique à l’application
L’implémentation de ce prototype emploie des composants matériels spécifiques.
Ce prototype est dédié spécifiquement à la modélisation d'une application spécifique.
Chaque module matériel dans le système est remplacé par une composante physique.
Les connexions sont réalisées par des fils ou des liaisons sur un circuit imprimé.
Les points faibles sont son coût et sa flexibilité. Il faut plus de temps et plus d’effort
pour développer ce type de prototype que les autres. De plus, si les composants requis
ne sont pas toujours disponibles, ce prototype ne peut pas être développé. Il n’est pas
flexible, et les modifications sont difficiles à effectuer si l' on modifie le système.
L’avantage de ce prototype est sa performance puisque qu'on peut obtenir un
prototype dont l'architecture est très proche de celle du système final.
•
Le prototype reconfigurable
L’implémentation de ce prototype est une plateforme reconfigurable. On utilise des
composants configurables pour implémenter les composants physiques et les
connexions.
Le point faible de ce type de prototype est le point d’entrée, puisqu’il faut une
description de niveau RTL ou de niveau porte logique de tous les composants.
26
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Malheureusement, les descriptions de niveau RTL pour implémenter les parties
matérielles ne sont pas toujours disponibles.
L’avantage de ce prototype est qu’il est beaucoup moins cher en terme d’effort,
d’argent, et de temps nécessaire pour la mise en oeuvre grâce aux parties matérielles
physiques qui sont déjà développées.
c. Le prototypage mixte
L’implémentation d'un tel prototype consiste à combiner la simulation, l’émulation, et
l’utilisation de composants réels. Une des difficultés est de réaliser les connexions entre
les différents ordinateurs et les parties émulées. En effet, il faut mettre en œuvre un
mécanisme efficace pour faire communiquer les composants réels et les simulateurs.
Les points faibles de la co-émulation sont sa vitesse et la difficulté à l’utiliser. La vitesse
est limitée par la vitesse de simulation et par les performances des connexions. Cette
technique demande aussi une connaissance multiple de la part des concepteurs.
L’avantage de la co-émulation repose sur un compromis entre simulation et émulation.
La partie simulée correspond aux composants qui requièrent une grande flexibilité, une
observabilité élevée ou un modèle de haut niveau. La partie émulée permet d’avoir une
bonne vitesse d’exécution pour les autres composants.
2.4.5.1 Coût
Le coût du prototypage en terme d’argent, d’effort, et de temps dépend du choix
d’implémentation. En général, un prototype reconfigurable, un prototype virtuel ou la coémulation coûtent beaucoup moins cher en conservant une précision, une vitesse, et une
observabilité acceptables.
2.4.5.2 Modèle
Le prototypage combine divers modèles pour profiter des avantages de chaque
technique. On utilise des modèles de calcul pour les parties simulées, des émulateurs et des
composants physiques pour les autres parties.
2.4.5.3 Flexibilité
La flexibilité du prototypage dépend de la façon dont il est implémenté. Un prototype
reconfigurable, un prototype virtuel, et la co-émulation sont plus flexibles qu'un prototype
spécifique.
27
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
2.4.5.4 Utilité
Le prototypage offre la possibilité de faire des compromis entre observabilité, vitesse,
et précision. L’observabilité est obtenue soit en ajoutant une interface de déboguage au
composant matériel soit par la simulation. La vitesse est obtenue par l’émulation et
l’utilisation de composants physiques, et la précision est obtenue soit avec une simulation de
bas niveau, soit à partir d’émulation du composant.
2.4.6 Synthèse des différentes techniques
Parmi les quatre techniques que l’on a comparées précédemment, chacune a ses
propres caractéristiques. Chaque technique peut alors être utilisée efficacement dans une
étape différente du flot de conception des systèmes monopuces.
La vérification formelle est une technique flexible et elle a une bonne utilité (bonne
précision, bonne observabilité, et vitesse de vérification élevée). Malheureusement, elle est
trop complexe à utiliser à bas niveau d’abstraction. De plus, il est difficile de l’utiliser pour
vérifier du logiciel et du matériel en même temps. Cette technique est efficace au début de la
conceptio n pour vérifier la description de haut niveau.
La simulation est une technique très flexible qui offre une bonne observabilité. Cette
qualité a permis la généralisation de son utilisation. Ainsi, aujourd’hui, on ne peut plus
développer un système monopuce sans simulation. Le défaut principal de cette technique est
l’impossibilité de concilier vitesse de simulation et précision. Son autre défaut est la
difficulté à intégrer l’environnement physique. Cette technique est alors aussi lente pour le
développement d’un logiciel complexe devant être exécuté par plusieurs processeurs.
A l’opposé, l’émulation est une technique qui permet d’allier une vitesse élevée et une
bonne précision. C’est une bonne technique pour les tests dans un environnement physique.
Les défauts de cette technique sont sa faible flexibilité, sa mauvaise observabilité, et son
coût. Cette technique n’est alors utilisable que lorsque la conception est déjà bien avancée et
que la majorité des bogues est déjà éliminée.
28
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Technique
Coût
Modèle
Flexibilité
Utilité
Dans quel cas l'utiliser
Vérification formelle
Observabilité
- faible coût financier
(ordinateur, outil de
vérification formelle)
- effort et le temps de
vérification
considérables
ensemble de
notations
prédéfinies
Très flexible
- verification la spécification
des systèmes monopuces
système
complexe
Vitesse
Précision
système très simple
Observabilité
Simulation
- faible coût financier
(ordinateur, outil de
simulation)
- effort et temps faibles
comparés aux autres
techniques
modèle
d'exécution/de
calcul sur
l'ordinateur
Simulation de
haut niveau
Très flexible
Simulation de
bas niveau
Vitesse
- toutes les étapes de
conception des systèmes
monopuces
Précision
Emulation
Observabilité
- élevé (financiers,
temps, et efforts)
un modèle
physique qui se
comporte comme le
composant émulé
- vérification avec un trés long
vecteur de test
- vérification finale (quand le
système n'a plus trop de
bogues)
Pas flexible
Vitesse
Précision
Prototype
Observabilité
- dépend de la
réalisation du
prototype
combine divers
modèles pour
profiter des
avantages de
chaque modèle
Pas flexible en
matériel, et
flexible avec la
simulation
- quand la conception est déjà
avancée (on n'a plus
beaucoup de bogues)
Vitesse
Précision
Tableau 2 Tableau récapitulatif de technique de vérification
Le prototypage combine les avantages de chaque technique. On peut avoir une bonne
observabilité, une bonne précision, ainsi qu’une vitesse élevée. De plus, on peut développer
un logiciel sur le prototype et effectuer un test sur environnement physique. Le problème du
prototypage se situe au niveau de son développement qui est difficile et coûteux. Le Tableau
2 résume des caractéristiques des ces techniques. L’utilité est représentée par un triangle
unique en fonction des valeurs des trois facteurs que sont l’observabilité, la précision et la
vitesse.
Afin d’accélérer la conception des systèmes monopuces et pour éviter l’apparition de
bogues après fabrication, on a besoin de deux choses : un développement du logiciel plus tôt
29
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
et une vérification rapide permettant d’utilisation d’un long vecteur de test pour assurer une
élimination complète de bogues. Le prototypage sur une plateforme reconfigurable et la coémulation permettent de répondre à ces besoins avec un coût raisonnable.
2.5 Le prototypage basé sur une plateforme reconfigurable
2.5.1 Intérêt du prototypage pour les systèmes monopuces
Sur les cinq points décrits dans le paragraphe 2.1, le prototypage présente un intérêt
pour quatre d’entre eux : on peut utiliser le prototypage pour évaluer l’architecture du
système (point 2), pour vérifier la fonctionnalité et la compatibilité des composant s (point 3),
pour vérifier l’intégration des composants (point 4), et tester le système avant fabrication
(point 5).
L’évaluation de l’architecture est faite en simulant chaque composant. A cette étape,
on ne possède que l’architecture du système et les spécifications de chaque composant. On
ne peut alors que simuler le comportement de ces composants. Aussi, seul un prototypage
virtuel (co-simulation) est possible. On peut aussi faire une co-émulation si certains
composants sont disponibles.
La vérification de la fonctionnalité et de la compatibilité des composants peut être faite
par prototypage sous certaines conditions. Pour développer la partie logicielle, on peut
utiliser le prototype matériel pour exécuter ces programmes. Pour développer un composant
matériel, on peut utiliser une technique de co-émulation si d'autres composants sont déjà
disponibles. On simule le composant développé et on le connecte avec d’autres composants.
On peut aussi vérifier l’intégration des composants, et tester le système complet en
utilisant un prototype. Tous les composants sont prêts à cette étape. Donc, on peut
développer un prototype spécifique ou un prototype basé sur une plateforme reconfigurable.
Avec ce prototype, on teste le système dans son environnement physique. Pour cette
vérification, les entrées utilisées sont les mêmes que celles que rencontrera le système final.
Ce prototype permet de faire des tests d'une durée beaucoup plus longue.
2.5.2 Intérêt du prototypage basé sur une plateforme reconfigurable
Les avantages à utiliser une plateforme reconfigurable sont évidents. Le coût de
prototypage est réduit. On ne doit pas financer le développent pour chaque application grâce
30
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
à la réutilisation du matériel. Le processus de prototypage est plus rapide car on n’a pas
besoin de concevoir et de fabriquer le matériel physique. Ainsi, l'effort est réduit.
Grâce à ce développent plus rapide, les concepteur peuvent commencer le
développement des parties logicielle plus tôt, ce qui raccourcit le temps de conception.
2.5.3 Intérêt de la co-émulation basée sur une plateforme reconfigurable
La co-émulation est utile quand les concepteurs ont besoin de vérifier le système
complet et si ils n’ont pas encore tous les composants à leur disposition. Dans ce cas, les
composants non existants peuvent être simulés, le reste des composants étant émulé.
Pour observer précisément le comportement d’un composant, il est quelques fois utile
d’utiliser la co-émulation. En effet, ce composant est alors simulé, ce qui permet d’étudier
l’évolution des signaux internes, en émulant le reste du système pour des raisons de
performance.
2.5.4 Exemples de flot de prototypage industrielle
2.5.4.1 Aptix
Un exemple de flot de prototypage mis en œuvre dans le milieu industrielle est le flot
de prototypage de Aptix Corp [APT02]. Aptix propose un flot de prototypage et un ensemble
d’outil nommé Aptix Prototype Studio. Ces outils de prototypage visent à trois plateformes
de prototypage : la plateforme System Explorer, la plateforme Software Integration Station et
un circuit imprime spécifique (custom PCB). En plus, le flot permet aussi utilisation de coémulation en utilisant la plateforme System Explorer.
System Explorer (Figure 5) est une plateforme de prototypage pour réaliser un
prototype matériel. Cette plateforme est basée sur un composant d’interconnexion
réconfigurable (FPIC). Ce composant permet d’obtenir des connexions configurables entre
les cartes montées sur cette plateforme. Il permet aussi d’observer les signaux avec un
analyseur logique. De plus, cette plateforme peut être connecté aussi à une simulation RTL
pour effectuer une co-émulation. Aussi cette plateforme convient très bon pour le déboguage
de matériel.
31
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPGA
FPIC
140
FPIC
140
FPIC
140
(a) L’architecture des interconnexions
Figure 5 Le System Explorer d’Aptix
Software Integration Station est une plateforme basée sur FPIC aussi, mais sans la
possibilité de déboguer du matériel. Elle n’a pas de connexions pour analyseur logique, ni
d’interface de co-émulation. Le point fort de cette plateforme est sa vitesse très élevée. De
plus, cette plateforme est beaucoup moins cher que le System Explorer. Cette plateforme est
alors utilisée pour réaliser un environnement d’exécution (matériel) pour le développement
du logiciel.
Aptix propose une gamme de plateforme de prototypage pour toutes les phases de la
conception de système (Figure 6)
32
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
System Explorer
Software Integration Station
PCB
Phase 0
Phase 1
Vérification d’algorithme
Exploration d’architecture
Développement d’IP
Déboguage du matériel
Phase 2
Phase 3
Développement des pilotes Développement de logiciel
Portage d’SE
Tes sur environnement
Phase 3
Test avec les clients
Figure 6 Les phases dans la conception des système monopuces
d'Aptix
La phase 0 est la phase de conception de niveau système. Les concepteurs vérifient
l’algorithme utilisé et explorent l’architecture. Dans cette phase, le coût de prototype n’est
pas important. Les plus importantes caractéristiques dans cette phase sont la vitesse,
l’observabilité, et la flexibilité car la description du système n’est généralement pas encore
stable. Normalement, il y a beaucoup de modifications à ce niveau. La simulation ou le
prototypage virtuel est alors préféré.
La phase 1 est la phase de conception classique du matériel. Comme la phase 0, le coût
du prototypage est moins important que l’observabilité et la flexibilité. Mais, la vitesse dans
cette phase n’est pas très importante car le vecteur de test dans cette phase n’est pas très long.
L’Aptix propose alors d’utiliser System Explorer.
La phase 2 est la phase de développement du logiciel de bas niveau. La vitesse devient
importante car le logiciel commence à être complexe. Parfois, on a encore besoin d’observer
les caractéristiques matérielles. Aptix propose d’utilisation de System Explorer pour coémulation, et puis de Software Integration Station.
La phase 3 est la phase de développement du logiciel de l’application. Les prototypes
sont utilisés pour exécuter le logiciel. Dans cette phase, le coût devient important car
plusieurs prototypes sont utilisés par les différentes équipes de conception. La vitesse devient
importante aussi car les parties logicielles sont vraiment complexes. Par contre, la flexibilité
et l’observabilité du matériel deviennent moins nécessaires car le matériel est déjà stable
dans cette phase. L’utilisation de Software Integration Station est alors proposée.
33
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Dans la phase 4, les prototypes sont testés par les utilisateurs. Des nombreux
prototypes sont nécessaires. Le coût des prototypes est alors très important. La vitesse
d’exécution doit être proche à la vitesse finale du produit. Par contre, on n’a pas besoin
d’observabilité et de fle xibilité. Les prototypages en utilisant Software Integration Station et
les prototypages sur circuits imprimés convient bien.
Les outils de prototypage d’Aptix consistent en des plateformes matériels et des outils
logiciels. Les plateformes matériels sont environnement d’exécution. Les outils logiciels sont
pour automatiser le flot de prototypage : Design Pilot, Explorer, FPGA Connector, et
Module Verification Platform , auxquels s’ajoutent les outils de synthèse pour FPGA et pour
la conception des circuits imprimés (Figure 7).
Description du système
(RTL)
Design Pilot
System Explorer
Description adaptée à
Explorer
Description adaptée à
FPGA connector
Description
adaptée pour coémulation
Explorer
FPGA Connector
Module Verification
Platform
Circuit imprimé
(PCB)
Co-émulation
Software Integration Station
Figure 7 Flot de prototypage d'APTIX
Design Pilot est un logiciel pour adapter la description de matériel en RTL à la
structure de FPGA. De plus, cet outil effectue aussi le partitio nnement de matériel en
plusieurs FPGA, l’optimisation des pattes (en ajoutant des circuits additionnels) et
l’encapsulation des modules réalisés dans un FPGA.
Explorer est le logiciel pour configurer, contrôler, et observer le matériel de
prototypage d’Aptix (System Explorer et Software Integration Station). Ce logiciel transpose
34
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
la description partitionnée en un fichier pour configurer la plateforme de prototypage. Cette
configuration consiste à établir les bonnes connexions entre les cartes. Ces connexions sont
établies en utilisant FPIC.
FPGA Connector est un logiciel qui permet de développer de circuit imprimé (PCB)
pour prototypage. Ce logiciel transforme la description partitionné par le Design Pilot au
format utilisable par les outils de conceptio n de circuit imprimé comme ORCAD ou
PROTEL.
Module Verification Platform/MVP est un logiciel qui facilité l’obtention d’un
environnement de co-émulation avec la plateforme System Explorer et un simulateur de
modèle RTL.
2.5.4.2 Flexbench
Un autre exemple de pla teforme de prototypage est Flexbench Prototype Equipment
(Figure 8). Cette plateforme est développée par un consortium de six entreprises. Elle pour
objectif un prototype avec une vitesse de plus de 100 MHz.
Figure 8 La plateforme de prototypage FlexBench
La plateforme Flexbench est très modulaire. Elle consiste en plusieurs types de
modules : générateur d’horloge, bus PCI, FPGA, FPIC, support de mémoire (memory
socket), support de processeur (processor socket), etc. Les connexions entre ces modules se
35
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
font à travers une carte mère appelée FlexMother. Tous ces modules sont montés dans un
râtelier (rack). On peut monter aussi plusieurs types de module de déboguage. Ces modules
de déboguage permettent d’observer les signaux dans chaque module en utilisant un
analyseur logique.
La topologie des connexions sur la carte mère est basée sur une structure à trois
dimensions. La Figure 9 illustre cette structure. Les connexions entres les modules sont
configurables. Toutes les connexions ont des délais identiques de 4ns jusqu’à 5 ns. Ce qui
donne une fréquence de100 MHz. Les détails de réalisation de ces connexions sont brevetés.
Ils ne sont pas alors divulgués au public.
Figure 9 La topologie de FlexBench
Le prototypage en utilisant cette plateforme est commencé dès que le processus de
conception arrive au niveau RTL. A partir de la description RTL de l’application, les
concepteurs doivent effectuer un partitionnement pour utiliser plusieurs modules FPGA.
L’outil Certify aide ce partitionnement. Les résultats de partitionnements sont utilisés pour
faire le routage des connexions de la plateforme FlexBench en utilisant un outil DiaFlex. Si
l’outil Diaflex n’arrive pas de faire routage, il peut produire un retour pour aider l’outil
Certify à repartitionner l’application. Si le partitionnement est fait correctement, les
concepteurs peuvent faire le placement et le routage pour chaque FPGA. Les résultats de
placement, de routage, et la configuration de FlexBench sont téléchargés à la plateforme. La
Figure 10 montre ce flot de prototypage.
36
Chapitre 2 : Vérification des systèmes monopuces : techniques et comparaison
Description en RTL
(VHDL ou Verilog)
Partitionnement Multi-FPGA
(Synplicity Certify)
Configuration de Flexbench
(DiaFlex)
Placement et Routage de
chaque FPGA
(Xilinx)
Téléchargement
(DiaFlex)
Prototypage
(FlexBench)
Figure 10 Flot de prototypage FlexBench
2.6 Conclusion
La vérification dans la conception de systèmes monopuces est un processus exigeant. Il
existe plusieurs étapes dans la conception, et chaque étape exige une vérification avec des
caractéristiques spécifiques.
Il existe aussi plusieurs techniques de vérification. Chaque technique possède ses
avantages, et ses défauts. Et à chaque étape de la conception correspondent une ou plusieurs
techniques de vérification.
L’émulation et le prototypage sur une plateforme reconfigurable accélèrent le
processus de conception car ces deux techniques permettent de commencer le
développement du logiciel plus tôt. En plus, elles sont utilisées pour tester le système dans
son environnement physique. Ainsi, on réduit les possibilités de laisser des bogues dans le
système. L’utilisation d’une plateforme reconfigurable permet de développer un prototype
rapidement, avec moins d’efforts et pour un coût plus faible qu’un prototype spécifique.
37
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
CHAPITRE 3 : DEFINITION D’UN FLOT DE
PROTOTYPAGE SUR UNE PLATEFORME
RECONFIGURABLE
3.1 Introduction...................................................................................................................................................40
3.2 Définition du prototypage d’un système monopuce sur une plateforme reconfigurable ...........40
3.2.1 Modèle de système monopuce........................................................................................................... 40
3.2.2 Modèle générique d’une plateforme de prototypage....................................................................... 42
3.2.3 Modèle d’une plateforme idéale pour le prototypage...................................................................... 43
3.3 Les plateformes reconfigurables et les flots de prototypage existants..............................................46
3.3.1 La classification des plateformes selon l'utilisation......................................................................... 46
3.3.2 La classification de la plateforme reconfigurable par le nombre de domaines d'application
supporté par la plateforme ................................................................................................................ 46
3.3.3 La classification des plateformes reconfigurable selon la configuration ou les types de
composant configurables dans la plateforme ................................................................................. 47
3.4 Flot de prototypage simple .........................................................................................................................48
3.4.1 Allocation.............................................................................................................................................. 48
3.4.2 Génération de code.............................................................................................................................. 49
3.4.3 Exemple ................................................................................................................................................. 49
3.5 Flot de prototypage proposé.......................................................................................................................51
3.5.1 Configuration........................................................................................................................................ 52
3.5.2 Adaptation............................................................................................................................................. 54
3.6 Conclusion......................................................................................................................................................56
39
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
3.1 Introduction
Le chapitre 2 a montré l’intérêt du prototypage par rapport aux autres techniques de
vérification. On a aussi montré qu’une solution de prototypage basée sur une plateforme
reconfigurable représentait un bon compromis entre coût et performance.
Pour réaliser un prototype à partir du modèle RTL de l’application, il est nécessaire
d’avoir une méthode pour enchaîner les étapes des transformations du modèle RTL et de la
plateforme. C’est le flot de prototypage.
Ce chapitre propose donc un flot de prototypage sur une plateforme reconfigurable. La
première partie définit ce qu’est un flot de prototypage sur une plateforme reconfigurable et
présente les modèles utilisés. La deuxième et la troisième parties présentent respectivement
un flot de prototypage simple, et un flot de prototypage dans le cas réel.
3.2 Définition du prototypage d’un système monopuce sur une plateforme
reconfigurable
Le prototypage d’une application sur une plateforme reconfigurable consiste à réaliser
toutes les parties de l’application avec les composants disponibles sur la plateforme. Les
composants matériels de l’application (processeurs, circuits spécifiques) sont réalisés avec
des composants programmables (FPGA). Les composants logiciels sont réalisés par des
programmes exécutés par un ou plusieurs processeurs. Selon la nature de l’application et
l’architecture de la plateforme, ce processus est plus ou moins complexe.
3.2.1 Modèle de système monopuce
La Figure 11 (a) montre le modèle d’architecture générique d’un système monopuce que
nous utilisons pour le prototypage. Le développement de ce modèle est basé sur le fait que ces
systèmes sont représentés par un ensemble de taches. Après plusieurs étapes de raffinement, la
conception atteint le niveau RTL. A ce niveau, quelques unes des tâches sont exécutées par des
processeurs, et les autres tâches sont effectuées par des composants matériels spécifiques (IP).
Aussi, le modèle d’un système monopuce comprend deux types de nœuds de calcul. Le premier
type de nœud contient un processeur, et le logiciel exécuté par ce processeur. Ce type de nœud
est appelé nœud de calcul logiciel. Le deuxième type de nœud contient un « IP ». Ce type de
nœud est appelé nœud de calcul matériel.
40
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Les données sont échangées entre les nœuds de calcul logiciel et matériel à travers un
(ou plusieurs) réseau de communication, qui peut être un bus partagé, des connexions point à
point, des « crossbars », un réseau sur puce ou une combinaison de ces éléments.
Logicielde
del’application
l’application
Logiciel
Noeud de
calcul
logiciel
Systèmed’exploitation
d’exploitation
Système
Couched’abstraction
d’abstractiondu
dumatériel
matériel
Couche
Processeur
Processeur
Noeud de
calcul
logiciel
ApplicationSw
Sw
Application
Logiciel
de l’application
OS
OS
Système d’exploitation
HAL
HAL
Couche d’abstraction
du matériel
Interfacedu
duprocesseur
processeur
Interface
Réseau de communication
Noeud de
calcul
matériel
IP
IP
IP
Processor
Processor
Processeur
Réseau de
communication
Wrapper
InterfaceWrapper
du processeur
Wrapper
Wrapper
Interface
de l’IP
Interfacede
del’IP
l’IP
Interface
IP
IP
Réseau de communication
Noeud de
calcul
matériel
(b)
(a)
Figure 11 Modèle d'architecture d’un système monopuce
Le nœud de calcul logiciel contient le logiciel de l’application, un système
d’exploitation (SE), une couche d’abstraction du matériel (en anglais : hardware abstraction
layer/HAL), le processeur, et l’interface du processeur. Le logiciel de l’application, la couche
d’abstraction du matériel, et le SE sont les parties logicielles de l’application. Ces logiciels
sont exécutés par le processeur. Le logiciel d’application est un ensemble de tâches utilisé
pour construire le comportement de l’application décrit dans la spécification fonctionnelle.
Le SE et la couche d’abstraction du matériel sont les parties logicielles qui gèrent l’exécution
de ces tâches et l’utilisation de ressources partagées par les tâches. Ceci inclut l’utilisation du
matériel. La couche d’abstraction du matériel est séparée du SE pour permettre de porter
facilement le SE et le logiciel de l’application sur différentes architectures. Quelques parties
de la couche d’abstraction du matériel doivent être écrites en assembleur. Les autres parties
de la couche d’abstraction du matériel et les autres programmes sont écrits en langage de
41
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
programmation de haut niveau (C ou C++). L’interface du processeur est là pour adapter
l’interface du processeur au réseau de communication.
Le nœud de calcul matériel consiste en un IP et son interface. L’IP est un composant
matériel qui effectue un calcul spécifique ou une tâche spécifique. L’interface de l’IP adapte
l’interface physique de l’IP au réseau de communication. Ces nœuds de calculs sont décrits
au niveau RTL ou au niveau portes logiques pour permettre le prototypage. La Figure 11 (b)
montre une autre représentation de ce modèle que l’on utilise dans la suite de ce paragraphe.
3.2.2 Modèle générique d’une plateforme de prototypage
La plateforme de prototypage comporte des nœuds pour exécuter les logiciels, et des
nœuds pour effectuer les tâches matérielles. La Figure 12 montre un modèle de plateforme
pour le prototypage. Dans ce modèle, on divise la plateforme de prototypage en trois parties :
les nœuds de prototypage logiciel, les nœuds de prototypage matériel, et le réseau de
prototypage de communication.
Le nœud de prototypage logiciel contient au minimum un processeur et des mémoires.
Le logiciel est ainsi chargé en mémoire et exécuté par le processeur. Ce noeud contient aussi
l’interface pour se connecter au réseau de prototypage de communication.
Software
Software
Module
d’exécution
Execution
Execution
duModule
Module
logiciel
Noeud de
prototypage
logiciel
Interface du module
d’exécution du logiciel
Réseau de
prototypage de
communication
Réseau de
communication
reconfigurable
Interface du matériel
reconfigurable
Noeud de
prototypage
matériel
Reconfigurable
Reconfigurable
Matériel
Hardware
Hardware
reconfigurable
Figure 12 Modèle générique de plateforme de prototypage
42
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Le nœud de prototypage matériel contient au moins un composant reconfigurable. La
fonctionnalité d’un composants spécifique de l’application est reproduite par ce composant
reconfigurable sous certaines conditions (description niveau RTL, …). Ce nœud a besoin
aussi d’une interface pour se connecter au réseau de prototypage de communication.
Ces nœuds de prototypage logiciel et matériel sont connectés à travers un réseau de
prototypage de communication, qui permet de reproduire un ou plusieurs schémas de
communication.
Pour être capable de modéliser des architectures variées, une plateforme
reconfigurable doit avoir les caractéristiques suivantes :
1. Etre modulaire, ce qui signifie que les concepteurs peuvent choisir les types et le nombre
de nœuds de la plateforme.
2. Le nœud de prototypage logiciel peut remplacer tous les types de processeur et son
architecture locale pour modéliser un nœud de calcul logiciel.
3. Le nœud de prototypage matériel est capable de modéliser un IP et son interface.
4. Le réseau de communication entre les nœuds peut être configuré pour réaliser divers types
de communication.
3.2.3 Modèle d’une plateforme idéale pour le prototypage
Comme déjà mentionné précédemment, une plateforme idéale pour le prototypage doit
être modulaire. Donc, chaque noeud est implémenté sur un circuit imprimé séparé pour avoir
de la modularité. Malheureusement, les connexions entre les modules sont toujours
physiquement fixées (sur un circuit imprimé). On a besoin d’un mécanisme pour utiliser ces
connexions fixées permettant d’émuler les connexions entre plusieurs nœuds de prototypage
logiciel/matériel et nœuds de prototypage de la communication. Dans le cas de nœuds de
prototypage logiciel, ce mécanisme doit émuler des connexions entre le processeur et le
réseau de communication reconfigurable. Dans le cas de nœud de prototypage matériel, ce
mécanisme doit émuler des connexions entre l’IP et le réseau de communication
reconfigurable. Ce mécanisme est appelé protocole de prototypage. Ce protocole consiste en
des connexions fixées entre des nœuds, un adaptateur à chaque nœud pour utiliser ce
protocole, et un contrôleur pour gérer l’utilisation du bus partagé.
43
Noeud de
prototypage logiciel
Architecture
locale
Noeud de
prototypage logiciel
Architecture
locale
Mémoire
Mémoire
Processeur
Processeur
Point d’accès du
noeud (PAN)
Noeud de
prototypage matériel
Noeud de
prototypage matériel
Composants
reconfigurable (FPGA)
Composants
reconfigurable (FPGA)
IP
IP
Point d’accès du
noeud (PAN)
Point d’accès du
noeud (PAN)
Point d’accès du
noeud (PAN)
Point d’accès de
communication
(PAC)
Point d’accès de
communication
(PAC)
Point d’accès de
communication
(PAC)
Contrôleur
Point d’accès de
communication
(PAC)
Protocole de
prototypage
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Réseau de communication reconfigurable
Noeud de prototypage de communication
Figure 13 L'implémentation d'une plateforme idéale
La Figure 13 montre un exemple de réalisation d’une plateforme de prototypage
idéale. Cette plateforme est composé de trois types de nœuds :
•
Le nœud de prototypage logiciel. Il contient un processeur, et l’architecture locale de
ce processeur. Il faut que le nœud permette aux concepteurs de sélectionner ou de
configurer le processeur et l’architecture locale utilisée. Il contient aussi un bloc
pour connecter l’interface du processeur aux composants de communication. On
appelle ce bloc un point d’accès de nœud (PAN).
•
Le nœud de prototypage matériel. Ce nœud contient un composant reconfigurable
pour émuler l’IP. Il contient aussi un bloc pour connecter les interfaces des
composant matériels aux composants de communication en utilisant le protocole de
prototypage. On l’appelle aussi le point d’accès du nœud (PAN) comme pour le
nœud de prototypage logiciel.
•
Le nœud de prototypage de communication. Ce nœud est utilisé pour implémenter
les composants de communication : des bus, des connexions point à point, des
« cross bars ». Pour la réalisation de ce composant, on utilise des composants
reconfigurables (FPGA). Ce nœud contient aussi des blocs point d’accès de
communications (PAC) pour connecter ces composants de communication aux points
d’accès des nœuds (PA N).
44
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Les communications entre les nœuds sont implémentées en utilisant un protocole de
prototypage qui consiste en des connexions fixées entre des nœuds, des adaptateurs dans
chaque nœud (PAN et PAC), et un contrôleur. Pour chaque cycle :
•
Le PAN encode l’information issue d’un processeur ou d’un IP et décode
l’information provenant d’un PAC.
•
Le PAC encode (et décode) l’information envoyée par une PAN à travers le réseau
de communication.
•
Les connexions physiques sont partagées par plusieurs PAC et PAN.
•
Le contrôleur gère le partage des connexions physiques par les PAC et les PAN, et
puis, quand toutes les communications sont effectuées, il envoie des signaux à tous
les nœuds pour faire avancer d’un cycle d’horloge.
La plateforme idéale détaillée dans la Figure 13 peut aussi se représenter sous une
forme plus simple et plus proche du modèle générique de la Figure 12. Cette représentation
(Figure 14) fait apparaître les nœuds de prototypage logiciel comportant de la mémoire et un
processeur, les nœuds de prototypage matériel comportant un composant reconfigurable, et
un nœud de prototypage de communication. Les points d’accès (PAN et PAC) sont réalisés
avec des composants programmable (FPGA).
Software
Software
Module
Execution
d’exécution
Execution
duModule
logiciel
Module
Mémoire
Mémoire
Processeur
Processeur
Interface du module
d’exécution du logiciel
Nœud de
prototypage
logiciel
FPGA
FPGA
(pour
(pour PAN)
PAN)
Réseau de
communication
reconfigurable
PAC
réseau de
communication
reconfigurable
Nœud de
prototypage de
communication
(sur FPGA)
PAC
Interface du matériel
reconfigurable
FPGA
FPGA
(pour
(pourPAN)
PAN)
FPGA
FPGA
Reconfigurable
Reconfigurable
Matériel
Hardware
Hardware
reconfigurable
(a)
modèle générique de
plateforme de prototypage
pour réaliser
l’IP
Nœud de
prototypage
matériel
(b)
modèle de la plateforme idéale
Figure 14 Modèle de notre implémentation de la plateforme idéale
45
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
3.3 Les plateformes reconfigurables et les flots de prototypage existants
Ce paragraphe décrit quelques classifications de plateformes reconfigurables et
quelques flots de prototypage.
Les plateformes reconfigurables existantes peuvent être classifiées selon trois points de
vues : (1) selon l'utilisation faite de la plateforme, (2) selon le nombre de domaines
d'application supporté par la plateforme, (3) selon la configurabilité ou les types de
composants reconfigurables dans la plateforme.
3.3.1 La classification des plateformes selon l'utilisation
Une plateforme reconfigurable peut être employée comme architecture finale du
système ou comme émulateur. Si elle est employée comme architecture finale, l'exploration
d'architecture du système est fortement limitée par la plateforme. Mais ce type de plateforme
fournit aussi beaucoup d'autres facilités pour accélérer le processus de conception, par
exemple des IP, un SE adapté et une topologie spécifique de communication. Un exemple de
ce type de plateforme est la plateforme PrimeXsys de ARM [ARM01]. Cette plateforme est
conçue pour des applications sans fil. Le processeur ARM 926EJ-S est à la base du noeud de
prototypage logiciel. Les autres noeuds de traitement peuvent être ajoutés comme des
périphériques (compteur de temps, contrôleur d'interruption, etc..), comme un IP spécifique à
l’application (MPEG, DBS, etc..). La communication entre ces noeuds est basée sur six
couches de bus AMBA AHB.
Comme émulateur, la plateforme configurable est employée pour valider et explorer
des solutions pour l'application. Le système de prototypage proposé par M. Dorfel [DOR01]
est un exemple de ce type de plateforme. L'auteur utilise le multiprocesseur basé sur VME et
le PC pour exécuter les tâches logicielles. Un FPGA est utilisé pour réaliser les tâches en
matériel. Des communications entre les noeuds sont exécutées par des connexions entre
FPGAs et le bus VME.
3.3.2 La classification de la plateforme reconfigurables par le nombre de domaine
d'application supporté par la plateforme
Nous pouvons distinguer deux classes : la plateforme configurable pour un domaine
d'application spécifique, et la plateforme reconfigurable non spécifique. LOPIOM [MOS96]
est un exemple de plateforme reconfigurable non spécifique.
46
Elle est conçue pour le
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
prototypage des différents domaines de l'application. Des tâches de logiciel sont exécutées
par un processeur Motorola MC68331. Quatre FPGA Xilinx composent les noeuds de
prototypage matériels. Des communications entre les noeuds sont faites avec composant
d’interconnexions programmables (FPIC) et un bus VME.
Dans le cas d'une plateforme spécifique, les composants et l'architecture sont
spécialement adaptés aux spécificités des applications. Un exemple d'une telle plateforme est
décrit par A. Ramanathan [RAM01]. Le noeud de prototypage logiciel supporte un
StrongArm, et les noeuds de prototypage matériels contiennent deux FPGA APEX, CNA,
I/Q, et un contrôleur Ethernet. La communication est obtenue à l'aide d'un bus standard
(données, adresses, signaux de contrôle), d'un lien Ethernet et de quelques signaux de
commande dédiés.
3.3.3 La classification des plateforme s reconfigurables selon la configuration ou les
types de composants configurables dans la plateforme
On a trois types de plateforme basées sur ce critère. Une plateforme avec des
composants matériels reconfigurables, une plateforme avec des composants programmables
pour exécuter du logiciel, et une plateforme avec des connexions reconfigurables.
Un plateforme avec matériel reconfigurable utilise différents types varies de
composants reconfigurable : FPGA, CPLD, PLA, … . Elle permet alors de réaliser de
nombreux modules matériels. Il existe aussi des plateformes avec des composants matériels
reconfigurables moins classiques, dont la granularité moins fine, comme par exemple FPAA
(Field programmable ALU array, une composant reconfigurable composé par un ensemble
d’unités arithmétiques et logiques) [HAR97b], un autre exemple est la plateforme décrite en
[SAS03d]. Un exemple de ce type de plateforme est décrit par K. Adaeis [ADA98]. Cette
plateforme possède quatre FPGA. Ces FPGA sont connectés par quelques fils, dont certains
sont partagés par plusieurs FPGA..
Une plateforme avec des composants programmables est composée d’un ou plusieurs
processeurs. Cette plateforme peut aussi avoir quelques modules matériels mais ils ne sont
pas reconfigurables. Un exemple est WinSystems Embedded PC [WINSY]. Cette plateforme
utilise des processeurs utilisés dans le PC (Pentium d’Intel, AMD, …). Le système
d’exploitation est mis dans un composant nommé Disc-On-Chip (DoC). Ce composant agit
comme un disque dur.
47
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Le troisième type de plateforme possède des connexions configurables. La réalisation
des connexions reconfigurables est fait soit en utilisant des composants reconfigurables
comme FPIC, soit en utilisant d’une architecture spécifique. Une plateforme APTIX et la
plateforme Flexbench présentées dans le paragraphe 2.5.4 sont des exemples de ce type de
plateforme. Evidemment, une plateforme peut correspondre à sur plusieurs classes de
reconfigurabilité si elles ont plusieurs composants configurables ou programmables.
3.4 Flot de prototypage simple
Le flot de prototypage est très simple si l’architecture de la plateforme est très proche
de l’architecture de l’application. Dans ce cas, le flot de prototypage se limite à une étape
d’allocation («assignment» en anglais) suivie d’une étape de génération de code, compilation
et synthèse («targeting» en anglais) (Figure 15).
Architecture
logiciel/matériel du
système monopuce
Plateforme
reconfigurable
Allocation
Génération
de code
Prototype
Figure 15 Flot de prototypage simple
3.4.1 Allocation
Dans l’étape d’allocation, les concepteurs associent chaque partie de l’architecture à un
nœud de prototypage de la plateforme. Ces associations indiquent sur quelles parties de la
plateforme reconfigurable sont réalisées les parties de l’architecture de l’application. Le
résultat de cette étape est un tableau d’association. Ce tableau guide toute la suite du
processus de prototypage.
48
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Les décisions prises pour faire ces associations sont basées sur les objectifs du
prototypage et les contraintes imposées par la plateforme. Ce n’est pas du partitionnement
logiciel/matériel car l’application est déjà décrite à un bas niveau d’abstraction.
3.4.2 Génération de code
La génération de code (« ciblage») est la dernière étape dans le flot de prototypage. On
le fait si chaque partie de l’application a une correspondance directe avec les composants de
la plateforme. Cette étape consiste en processus standard tels que la compilation et l’édition
de lien des logiciels, la synthèse logique, le placement sur FPGA, et le routage.
3.4.3 Exemple
La Figure 16 donne un exemple d’allocation du prototypage d’une application sur une
plateforme reconfigurable. L’application est décrite en plusieurs couches, avec le code
d’application, le système d’exploitation et la couche d’abstraction du matériel s’exécutant sur
un processeur. Ce processeur est connecté au réseau de communication à travers un
composant d’adaptation (interface du processeur). Le composant matériel spécifique est lui
aussi connecté au réseau par un adaptateur d’IP.
Logiciel de l’application
Mémoire
Système d’exploitation
Couche d’abstraction du matériel
Processeur
Processeur
Nœud de
prototypage
logiciel
FPGA
(pour PAN)
Interface du processeur
PAC
réseau de
communication
reconfigurable
PAC
Réseau de communication
Nœud de
prototypage de
communication
(sur FPGA)
Interface
Interfacede
del’IP
l’IP
FPGA
FPGA
(pour
(pourPAN)
PAN)
FPGA
FPGA
pour réaliser
l’IP
IP
IP
(a) L’application
(b) La plateforme
Figure 16 Exemple de l’allocation
49
Nœud de
prototypage
matériel
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Supposons que l’on veuille prototyper cette application sur la plateforme idéale
présentée dans le paragraphe 3.2.3. et que les interfaces entre les nœuds de prototypage
logiciel/matériel et le nœud de prototypage de communication sont mis en œuvre par des
FPGA. L’étape d’allocation est ici simple. Elle consiste à dire que les programmes sont
placés dans la mémoire programme du processeur, le processeur de l’application est émulé
par le processeur de la plateforme, l’adaptateur du processeur, l’adaptateur du IP, et le réseau
de communication sont réalisés par le réseau de communication de l’application. Le
composant IP est réalisé par le FPGA du nœud de prototypage matériel.
L’étape de génération de code se décompose en plusieurs parties (Figure 17) :
•
Pour la partie logicielle : la génération du code consiste à ajouter un module de
déboguage (si nécessaire), puis à faire la compilation et l’édition de lien.
•
Pour le processeur, on choisir un processeur pour exécuter la partie logicielle. Le PAN de
ce nœud de prototypage logiciel est alors configuré pour encoder (et décoder) les signaux
des entrées/sorties du processeur. Ce PAN est un module VHDL paramétrable. On
configure le PAN, suivi de la synthèse et du placement et routage avant le chargement
sur FPGA de ce nœud.
•
Les interfaces des IP et des processeurs et aussi le réseau de communication sont réalisés
par le réseau de communication réconfigurable.
•
Les IPs sont implémentés sur un ou plusieurs FPGA (dans les nœuds de prototypage
matériel). Pour faire le partitionnement de ces IP, on doit d’abord faire d’une estimation
des tailles des IPs. Basé sur les tailles estimées, on décide le nombre de nœuds de
prototypages matériel dont on a besoin et ensuite, on partitionne les IP sur ces nœuds.
Pour chaque nœud, on doit ajouter un PAN, et éventuellement un module de déboguage
si c’est nécessaire. Le module de plus haut niveau est ensuite ajouté à chaque nœud pour
encapsuler tous les modules (Les IP, PAN, et les modules de déboguages). Enfin, on fait
la synthèse et le placement-routage pour chaque nœud.
50
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Logiciel de
l’application
Système
d’exploitation
Addition du
module de
déboguage
Édition
de lien
Compilation
Mémoire
Mémoire
Couche d’abstraction
du matériel
Processeur
Configuration
du PAN
Interface du
processeur
synthèse
Processeur
Processeur
Placement
et routage
FPGA
FPGA
(pour
(pour PAN)
PAN)
Addition du
module de
déboguage
Réseau de
communication
synthèse
Configuration
des PACs et
le contrôleur
Placement
et routage
PAC
réseau de
communication
reconfigurable
PAC
Interface
Interfacede
del l’IP
’IP
IP
IP
Addition du
module du
plus haut
niveau pour
chaque
FPGA
Addition
du PAN
estimation
synthèse
Placement
et routage
FPGA
FPGA
(pour
(pourPAN)
PAN)
FPGA
FPGA
pour réaliser
l’IP
partitionnement
(a) L’application
Addition du
module de
déboguage
(b) La plateforme
Figure 17 Génération du code
3.5 Flot de prototypage proposé
Malheureusement, le flot de prototypage simple présenté précédemment s’applique
quand l’architecture de la plateforme est proche de l’architecture de l’application, ce qui est
rarement le cas dans la réalité. De nombreuses différences peuvent exister : le réseau de
communication de la plateforme fixé n’est pas celui de l’application, les processeurs ne sont
pas du même type, la carte mémoire est différent et dans certains cas les programmes de
démarrage, le traitement des exceptions et la gestion des interruptions sont à reconsidérer.
Dans ce cas, pour prototyper l’application sur la plateforme reconfigurable, il est
nécessaire de réorganiser la plateforme et éventuellement d’apporter quelques modifications
à l’architecture de l’application.
Ainsi nous proposons un flot avec quatre étapes (Figure 18) : (1) allouer chaque partie
de l’application à la plateforme, (2) configurer la plateforme pour qu’elle convienne à
l’architecture de l’application, (3) adapter l’architecture de l’application si nécessaire, (4)
générer le code pour les nœuds de prototypage de la plateforme.
51
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Architecture
logiciel/matériel de
système monopuce
Plateforme
reconfigurable
Allocation
Adaptation
Configuration
Architecture
adaptée
Plateforme
configurée
Génération
de code
Prototype
Figure 18 Flot de prototypage
Dans l’étape d’allocation dans le flot de prototypage réel, les concepteurs doivent
décider des parties de l’application qui seront vraiment implémentées, et choisir les parties
dont on doit émuler les fonctionnalités différemment. Dans cette étape, on décide aussi
comment on fait l’adaptation et la configuration. Ces décisions dépendent des objectifs du
prototypage.
3.5.1 Configuration
Après l’étape d’allocation, les deux étapes suivantes sont la configuration et
l’adaptation. On peut définir la configuration comme la réorganisation de la plateforme
reconfigurable. On modifie la plateforme reconfigurable pour que son architecture soit plus
proche de celle de l’architecture de l’application.
La Figure 19 montre un exemple de configuration. Dans cet exemple, on veut
prototyper une architecture (Figure 19.a) qui contient un processeur, un IP, et un bus X. La
plateforme disponible consiste en un nœud de prototypage logiciel contenant le même type
de processeur, et un nœud de prototypage matériel contenant un FPGA qui permet de réaliser
l’IP. Malheureusement, la communication entre le processeur et le FPGA est différente (bus
Y) et fixée. On doit alors implémenter le bus X dans le FPGA. Afin de le faire, on a besoin
d’un convertisseur pour cacher le bus Y.
52
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Processeur
Processeur
Bus Y (fixé)
Bus X
IP
FGPA
L’architecture de l’application
(a)
La plateforme reconfigurable
(b)
Processeur
On ajoute un convertisseur qui
permet d’implémenter le Bus X dans
le FPGA
Bus Y (fixé)
Convertisseur X-Y
Bus X
(c)
IP
Figure 19 Exemple de configuration
On peut appliquer cet exemple à partir de la structure en couche de l’application et de
la plateforme, en reprenant le principe de la Figure 16. Sur la Figure 20, la plateforme
possède un réseau de communication fixé pour connecter le nœud de prototypage matériel au
nœud de prototypage logiciel.
Si l’objectif du prototypage suppose de réaliser le bus X, alors il apparaît évident de
placer le bus X ainsi que tous le composants d’interface de l’application dans le nœud de
prototypage matériel. Il est donc nécessaire d’ajouter une couche de conversion entre le
réseau Y et le bus X. Le réseau fixé devient transparent pour l’IP grâce à ce convertisseur en
terme de protocole entre l’IP vers le processeur. Ceci n’est pas vrai pour les communications
du processeur vers l’IP, puisque le nœud de prototypage logiciel est connecté au réseau Y.
Dans ce cas là, la configuration consiste à développer le convertisseur entre le réseau
fixé de la plateforme et l’interface du processeur. Ce convertisseur est réutilisable si on
utilise la même plateforme.
53
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Logiciel de
l’application
Système
d’exploitation
Couche d’abstraction
du matériel
Processeur
Interface du
processeur
Mémoire
Mémoire
Processeur
Processeur
Interface du
processeur
(fixé)
Interface du
processeur
(fixé)
Configuration
réseau de
communication
Fixé
réseau de
communication
Interface
FPGA du
FPGA
(pour
PAN)
(fixé)
Interface
FPGA du
FPGA
(pour
PAN)
(fixé)
Convertisseur
FPGA
FPGA
FPGA
pour réaliser
l’IP
Fixé
Nœud de
prototypage
logiciel
Nœud de
prototypage de
communication
(sur FPGA)
Réseau de
communication
Interface
Interfacede
del’IP
l’IP
IP
IP
(a)
L’application
FPGA
pour réaliser
l’IP
(c)
La plateforme
configurée
Nœud de
prototypage
matériel
(b)
La plateforme
Figure 20 Configuration
3.5.2 Adaptation
L’adaptation consiste à modifier l’application pour satisfaire aux caractéristiques de la
plateforme reconfigurable. Cette étape est effectuée si la plateforme ne peut pas être
configurée pour s’adapter aux besoins de l’application. Par exemple si la plateforme a un
plan mémoire fixé, la couche d’abstraction du matériel et le système d’exploitation doivent
être modifiés.
La Figure 21 montre un exemple d’adaptation dans lequel la plateforme reconfigurable
possède un plan d’adresses fixé différent de celui de l’application. Dans ce cas, les
concepteurs modifient le plan mémoire de l’application. Cette modification correspond à
l’adaptation de l’architecture de l’application à la plateforme.
54
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
Logiciel de
l’application
adaptation
Système
d’exploitation
Couche d’abstraction
du matériel
Mémoire
(avec plan
d’adresse fixé)
Couche d’abstraction
du matériel adapté
Processeur
Processeur
Nœud de
prototypage
logiciel
FPGA
(pour PAN)
Interface du
processeur
PAC
réseau de
communication
reconfigurable
Réseau de
communication
Nœud de
prototypage de
communication
(sur FPGA)
PAC
Interface
Interfacede
del’IP
l’IP
FPGA
(pour PAN)
FPGA
FPGA
pour réaliser
l’IP
IP
IP
Nœud de
prototypage
matériel
(b)
La plateforme
(a)
L’application
Figure 21 Adaptation
L’adaptation est une étape très laborieuse et complexe. Dans cette étape, les
concepteurs doivent modifier l’architecture de l’application qui est déjà décrite à un bas
niveau d’abstraction. Cette tâche est difficile, les concepteurs ont besoin de beaucoup de
connaissances sur l’application, l’architecture, et la description de bas niveau. Une
automatisation sur cette étape serait donc très utile.
La configuration est préférée à l’adaptation, si les étapes sont toutes les deux possibles
pour résoudre une incompatibilité, ce qui évite de modifier le code de l’application. On peut
alors vérifier toutes les parties du code de l’application car il est inchangé. De plus, on
préfère ne pas modifier le code de l’application, car c’est souvent difficile à faire.
Après la configuration et l’adaptation, l’étape de génération de code correspond à la
synthèse logique, le placement et routage pour réaliser les composants matériels, le réseau de
communication et l’interface de conversion. Pour la partie logicielle, le processus est
identique à celui du prototypage simple : compilation et édition de lien et chargement.
55
Chapitre 3 : Définition d’un flot de prototypage sur une plateforme reconfigurable
3.6 Conclusion
Nous avons présenté dans ce chapitre un flot de prototypage simple et un flot de
prototypage réel. Ce dernier est le plus utilisé car généralement, l’architecture de la
plateforme ne correspond pas exactement à celle de l’application, et la plateforme possède
des contraintes. Ce qui oblige les concepteurs à reconfigurer la plateforme et à adapter
l’application pour réaliser son prototype.
L’étape d’allocation est faite manuellement car elle nécessite des prises de décisions
que seuls les concepteurs peuvent faire. De plus, cette étape fait appel à la créativité.
La configuration dépend fortement de la plateforme utilisée et de ces possibilités de
reconfigurabilité.
L’adaptation est une étape qui est difficile à faire, car les concepteurs doivent travailler
avec un code de bas niveau. L’automatisation est donc très utile pour réduire le temps de
développement du prototypage.
La génération du code consiste en des processus standard tels que la compilation,
l’édition de lien, la synthèse logique, et le routage sur FPGA. Ces processus sont déjà
automatiques.
Parmi les étapes de prototypage, l’adaptation est l’étape la plus délicate. Donc, son
automatisation serait très utile et permettait un gain de temps important.
56
Chapitre 4 : Applications
CHAPITRE 4 : APPLICATIONS
4.1 Introduction...................................................................................................................................................58
4.2 Plateforme ARM Integrator ......................................................................................................................58
4.2.1 La carte mère de la plateforme ARM Integrator.............................................................................. 59
4.2.2 La carte processeur de la plateforme ARM Integrator.................................................................... 60
4.2.3 La carte FPGA de la plateforme ARM Integrator........................................................................... 60
4.2.4 Le Bus AMBA...................................................................................................................................... 61
4.2.5 Outil de déboguage : Multi-ICE......................................................................................................... 61
4.2.6 Logiciel de développement et de déboguage.................................................................................... 62
4.2.7 Les caractéristiques de la plateforme ARM Integrator.................................................................... 63
4.3 Prototypage du VDSL sur la plateforme avec un réseau de communication fixé .........................64
4.3.1 Description de l’application................................................................................................................ 64
4.3.2 Spécification de l’application............................................................................................................. 64
4.3.3 Architecture logicielle matérielle ....................................................................................................... 65
4.3.4 Objectif du prototypage et contraintes............................................................................................... 65
4.3.5 Allocation.............................................................................................................................................. 66
4.3.6 Configuration........................................................................................................................................ 67
4.3.7 Adaptation............................................................................................................................................. 69
4.3.8 Génération du code.............................................................................................................................. 69
4.3.9 Résultats ................................................................................................................................................ 70
4.4 Prototypage du DivX à l’aide d’une phase d’adaptation automatique............................................71
4.4.1 Description de l’application................................................................................................................ 71
4.4.2 Objectif du prototypage et contraints ................................................................................................ 72
4.4.3 La spécification et l’architecture RTL............................................................................................... 73
4.4.4 Allocation.............................................................................................................................................. 76
4.4.5 Configuration........................................................................................................................................ 77
4.4.6 Adaptation............................................................................................................................................. 77
4.4.7 Génération du code.............................................................................................................................. 81
4.4.8 Résultats et analyse.............................................................................................................................. 81
57
Chapitre 4 : Applications
4.1 Introduction
Dans le chapitre précédent, nous avons proposé un flot de prototypage en utilisant une
plateforme reconfigurable. Ce flot nous permet d’obtenir un prototype même si l’architecture
de la plateforme est différente de celle de l’application. Ce flot consiste en quatre étapes :
allocation, configuration, adaptation, et génération de code.
Ce chapitre présente des exemples d’utilisation des ces techniques. Une plateforme
ARM Integrator est utilisée comme plateforme de prototypage. Après avoir décrit la
plateforme ARM Integrator, on montrera, à travers le prototypage d’une application VDSL
et d’une application DivX les différentes phases du flot de prototypage et l’effort à faire pour
concevoir un prototype.
4.2 Plateforme ARM Integrator
La plateforme ARM Integrator est une plateforme matérielle conçue par ARM Holding
Plc pour développer une application sur des processeurs ARM autour d’un bus AMBA. Cette
plateforme contient trois types de carte : une carte mère (nommée « ARM Integrator AP »),
une carte processeur (nommée « core module »), et une carte FPGA (nommée « logic
module »). Sur la carte mère, on peut monter cinq autres cartes (des cartes processeurs ou des
cartes FPGA), mais on ne peut pas monter plus de quatre cartes d’un même type (quatre
cartes processeur ou quatre cartes de FPGA). La Figure 22 montre une version simplifiée de
cette plateforme avec trois cartes processeurs et deux cartes FPGA.
Carte processeur(Core Module)
Processeur
Mémoire
JTAG
JTAG
JTAG
Processor
Processor
FPGA
FPGA
C o r e Modu
le
Interface
AMBA
C o r e Module
BUS AMBA
PCI bus
Périph érique
Mémoire
Carte mère de la plateforme ARM Integrator
FPGA
JTAG
mémoire
Entré/sortie
Logic Module
Carte FPGA (Logic Module)
Figure 22 Plateforme ARM Integrator avec 3 cartes
processeur et 2 cartes FPGA
58
Chapitre 4 : Applications
4.2.1 La carte mère de plateforme ARM Integrator
La carte mère de la plateforme ARM Integrator [ARM99b] contient un bus AMBA, un
bus PCI, quelques périphériques et de la mémoire. Le bus AMBA est découpé en deux
parties (AHB et APB) connectées par un pont (en anglais : bridge). Le bus AMBA AHB
connecte les sous-systèmes principaux : cartes du processeur, carte FPGA, bus PCI, et la
mémoire. Le bus AMBA APB connecte les autres périphériques. Le bus PCI permet de
connecter trois cartes PCI et une extension de bus PCI. Les mémoires sur la carte mère
consistent en une mémoire flash, une SRAM, et une ROM. Ces mémoires sont connectées à
un bus AMBA à travers un contrôleur de mémoire statique. On peut aussi connecter une
mémoire additionnelle. Les périphériques connectés au bus AMBA APB sont : un compteur
de temps (timer), une horloge temps réel (RTC), des entrés/sorties (GPIO), deux liaisons
série (UART), un contrôleur clavier et une souris, un écran, un contrôleur d’interruptions, et
quelques registres de contrôle. La Figure 23 donne une vue détaillée de la carte mère de la
plateforme ARM Integrator.
Logic module connector
External bus
interface
Core module connector
AHB Bus
PCI Slot
PCI bridge
local
interface
Static
memory
controller
External bus
interface
PCI
host
bridge
FLASH
AHB/APB
bridge
SRAM
Boot
ROM
APB Bus
Counter/ti
mer
RTC
GPIO
UART
PS/2
Keyboard/
mouse
interface
LED/
display/
switch
Interrupt
controller
PCI Bus
PCI
PCI
bridge
External bus interface
PCI bridge
controller
Compact PCI
Status
and
control
register
FPGA
Peripheral input/output
Figure 23 La carte mère
Toutes les cartes (processeur ou FPGA) peuvent accéder à tous les sous-systèmes de la
carte mère. Il existe un seul plan mémoire. Ce plan mémoire comprend aussi les mémoires
locales à chacune des cartes, qui sont donc partagées.
59
Chapitre 4 : Applications
4.2.2 La carte processeur de la plateforme ARM Integrator
La carte processeur [ARM99d] contient principalement un processeur, des mémoires,
et une interface du bus AMBA (Figure 24). On peut choisir le type du processeur ARM
(ARM 7 et ARM 9). Il y a deux mémoires connectées au bus mémoire du processeur :
SSRAM et SDRAM. L’interface du bus AMBA connecte le bus mémoire du processeur au
bus AMBA sur la carte mère. On trouve aussi un contrôleur de remise à zéro, un générateur
de signal d’horloge, et un module JTAG pour le déboguage.
SSRAM
Générateur
du signal
d’horloge
Contrôleur
de l’horloge
Bus mémoire
Contrôleur
SSRAM
Processeur
ARM
JTAG
Contrôleur
du reset
Contrôleur
SDRAM
SDRAM
Interface
du bus
AMBA
FPGA
Connecteur à la carte mère
Figure 24 La carte processeur
4.2.3 La carte FPGA de la plateforme ARM Integrator
La carte FPGA [ARM99c] contient un FPGA, une interface JTAG et quelques
périphériques (Figure 25). Le FPGA est connecté à tous les autres modules. Ce FPGA est
configuré à partir d’ordinateur ou à partir d’une image téléchargée sur une mémoire flash. La
mémoire SSRAM est connectée directement au FPGA sans décodeur adresses ou contrôleur
mémoire. On doit alors réaliser ce décodeur adresses sur le FPGA. Des périphériques
d’entrées/sorties sont connectés au FPGA : diodes électroluminescentes, interrupteurs, et un
bouton poussoir. Le connecteur à la carte mère est relié directement au FPGA. On doit alors
écrire une interface du bus AMBA pour connecter le matériel réalisé sur le FPGA à la carte
mère.
60
Chapitre 4 : Applications
JTAG
SSRAM
Commutateur
FPGA
LED
Bouton poussoir
Connecteur à la carte mère
Figure 25 La carte FPGA
4.2.4 Le Bus AMBA
Les communications sont principalement réalisées par le bus AMBA [ARM99a]. Ce
bus a été conçu par ARM pour les systèmes monopuces. Il existe en fait trois types de bus :
AHB, ASB, APB. Le bus AHB accepte plusieurs maîtres, a des performances élevées et
permet des transferts de données par paquets (mode burst). Le bus ASB possède les mêmes
caractéristiques mais ne permet pas les transferts par paquets. Le bus APB est plus simple et
moins performant. Il n’autorise qu’un seul maître, mais il consomme moins d’énergie (« low
power »). [ARM99a] décrit le spécification des bus AMBA en détail. La Figure 26 illustre
une configuration typique d’un bus AMBA.
Mémoire
haut débit
Processeur
L’interface à la
mémoire
externe de
haut débit
p
o
n
t
AHB/ASB
UART
Timer
Clavier
Entrées/sorties
APB
DMA
Figure 26 La configuration typique d’une bus AMBA
4.2.5 Outil de déboguage : Multi-ICE
Multi ICE [ARM99f] est un outil qui permet de connecter plusieurs logiciels de
déboguage aux composants de la plateforme. On peut ainsi déboguer la partie logicielle de
61
Chapitre 4 : Applications
chacun des processeurs dans une même exécution. Pour déboguer la partie matérielle (dans
le FPGA), il faut ajouter une interface JTAG. Multi ICE est aussi utilisé pour télécharger des
programmes en mémoire sur les cartes (programmation des FPGA par exemple). La Figure
27 illustre l’utilisation de multi-ICE.
Débogueur 1
Débogueur 2
Débogueur 3
Serveur
Multi -ICE
Unité d’interface
Multi -ICE
Composant 1
Composant 2
Composant 3
Figure 27 Multi-ICE
4.2.6 Logiciel de développement et de déboguage
Deux types de logiciels sont nécessaires pour utiliser la plateforme : les logiciels de
développement et les logiciels de déboguage. Pour le développement, nous avons un
compilateur (armcc pour compiler un code C, armcpp pour compile un code C++, armasm
pour langage assembleur, tcc pour compiler un code C en mode 16 bit/thumb, tcpp pour un
code C++ en 16 bit), un éditeur du lien (armlink), et une interface graphique pour gérer un
projet (code warrior).
Pour le déboguage, nous avons un logiciel de déboguage [ARM99e] (AXD, un
débogueur qui peut être connecté à la plateforme, avec un simulateur), et deux simulateurs
(armsd, et ARMulator). La connexion entre le déboguer et la plateforme est à travers du
Multi-ICE. On peut al ncer plusieurs débogueurs connectés à plusieurs processeurs sur la
plateforme.
62
Chapitre 4 : Applications
4.2.7 Les caractéristiques de la plateforme ARM Integrator
Nous avons vu que la plateforme ARM Integrator est conçue avec trois types de
cartes : carte mère, carte FPGA et carte processeur. Ces trois cartes correspondent aux trois
nœuds dans le modèle de la plateforme de prototypage (paragraphe 3.2.2). Dans la
plateforme, la carte processeur représente le nœud de prototypage logiciel, la carte FPGA
représente le nœud de prototypage matériel, et la carte mère représente le nœud de
prototypage de communication.
Contrairement à la plateforme de prototypage idéale, on trouve beaucoup de
limitations dans cette plateforme. Les limitations principales sont sur la partie
communication, le contrôleur d’interruptions, et sur le plan de mémoire.
Sur cette plateforme, la communication entre les cartes est fixée au bus AMBA ASB.
Cette limitation existe sur la carte mère, mais aussi sur la carte processeur et sur la carte
FPGA. Sur la carte processeur, les entrées/sorties passent par l’interface du bus AMBA. Sur
la carte FPGA, les broches du FPGA sont directement connectées au bus AMBA de la carte
mère.
Le plan mémoire globale de la plateforme permet à tous les nœuds de prototypage
d’accéder à tous les composants mémoire, et plus généralement à l’ensemble des ressources
de toutes les cartes. Ce plan mémoire est figé. Par exemple, l’espace d’adressage des cartes
FPGA est fixé de 0xC000 0000 à 0xFFFF FFFF et l’adresses des mémoire partagées sont
fixée entre 0x8000 0000 jusqu’à 0xBFFF FFFF.
Le contrôleur d’interruptions est fixé et centralisé. De plus, une seule broche du FPGA
permet d’envoyer une interruption aux quatre processeurs. C’est une limitation importante
pour le développement d’un prototype.
Malgré ces limitations, la plateforme ARM Integrator est un bon outil pour déboguer le
logiciel, surtout, si l’application utilise un bus AMBA. Mais, il n’est pas facile de déboguer
le matériel avec cette plateforme. En effet, cette plateforme est conçue pour le
développement du logiciel et du matériel connecté au bus AMBA. Elle n’est pas conçue pour
développer d’autres architectures. Dans la suite de ce chapitre, nous allons décrire nos
expérimentations en utilisant cette plateforme.
63
Chapitre 4 : Applications
4.3 Prototypage du VDSL sur la plateforme avec un réseau de
communication fixé
4.3.1 Description de l’application
DSL (Digital Subscriber Line) est une application pour utiliser une ligne de
communication téléphonique (analogique) pour transférer un signal numérique entre deux
appareils. L’utilisation d’un signal numérique permet le transfert de données de haut débit et
permet d’augmenter la fiabilité. VDSL est une version du DSL. Le VDSL possède une très
haute performance mais suppose une distance réduite entre deux appareils.
La version du VDSL utilisée dans ce chapitre vient de [MES00]. Cette version utilise
le codage DMT (Discret Multi Tone) qui découpe la bande de fréquences initiale en sousbandes de transmission simultanée. Le « Zipper » découpe la bande de fréquence en 2048
sous-bandes qui sont allouées dynamiquement par logiciel, à différents utilisateurs.
4.3.2 Spécification de l’application
Pour des raisons de disponibilité du code source, seule une partie du système a été
réalisée. La spécification de départ est donc composée de trois modules (M1, M2, et M3).
Une version simplifiée de M3 était donnée. Le reste de l’application a été découpé en 9
tâches, réparties dans les modules M1 et M2. Les communications entre les tâches respectent
les mécanismes de communication Unix (tube/pipe, signaux, mémoire partagée). Il a été
décidé de réaliser M1 et M2 à l’aide de processeurs ARM7 et M3 est un composant
spécialisé (IP).
Dans ce cas d’étude, nous utilisons une partie du modem VDSL comme l’application.
Cette application contient deux processeurs ARM 7 et un composant spécialisé. Le premier
processeur exécute trois taches et le deuxième processeur exécute cinq tâches. Les
communications entre les tâches et entre les processeurs et l’IP sont très intenses. La Figure
28 (a) montre la partie de modem VDSL implémentée et La Figure 28 (b) montre
l’architecture de départ.
64
Chapitre 4 : Applications
M2: processeur Arm 7
M1: processeur Arm 7
pipe
PC
T2
T4
I
O
I
O
O
pipe
pipe
pipe
I
O
pipe
Arm 7
Mémoire
partagé
Processeur
du
traitement
du signal
I
T1
T5
O
T8
O
O
I
M3: IP
shm
I
O
I/O
sig
T6
O
I
Arm 7
T3
Asics/FPGA
I/O
O
I/O
gshm
I
T7
pipe
O
I/O
O
I/O
T6p
sig
I/O
La partie analogique du modem
(a) La partie de modem VDSL implémenté
(b) L’architecture de départ
Figure 28 Modem VDSL
4.3.3 Architecture logicielle matérielle
L’outil ROSES de group SLS TIMA permet de générer les interfaces logicielles et
matérielles de cette application et de raffiner la spécification (architecture virtuelle) en une
architecture RTL. Cet outil sera décrit en détaille dans le prochain chapitre (paragraphe
5.3.1). Au niveau RTL, on a deux processeurs ARM 7 et un IP. Chaque processeur ARM 7
exécute un logiciel se composé en logiciels d’applications (les tâches), un système
d’exploitation minimal, et une couche d’abstraction du matériel. Les systèmes d’exploitation
et les couches d’abstraction du matériel sont spécifiques aux processeurs et aux
communications utilisées, mais aussi aux services requis par les tâches. Ils sont donc
différents. Toutes les communications sont réalisées en utilisant des connexions point à
point. Les protocoles utilisés sont variés : registre gardé (“guarded register”), poigné du main
(“handshake”), et FIFO. La Figure 29 (a) décrit l’architecture logiciel/matériel de ce modem
VDSL au niveau RTL. La Figure 29 (b) montre une autre représentation de cette
architecture.
4.3.4 Objectif du prototypage et contraintes
Le flot de prototypage commence à partir de cette architecture. Nous utilisons la
plateforme ARM Intergrator pour réaliser le prototype. Dans ce cas d’étude, l’objectif du
prototypage est de vérifier les interfaces logiciel/ma tériel générées automatiquement par
ROSES. On doit alors réaliser toutes les interfaces sur la plateforme.
65
Chapitre 4 : Applications
Tache 8
Tache 7
Tache 6p
Tache 6
Tache 5
Tache 4
M2
Tache 3
Ta che 1
Tache 2
M1
système d’exploitation 1
système d’exploitation 2
Couche d’abstraction
matériel -SOC 1
Couche d’abstraction matériel SOC 2
ARM 7
Interface matériel 1
Interface matériel 2
ARM7 Bus Adpt.
ARM7 Bus Adpt.
HSK
Rg
HSK
Rg
Rg
(M2 )
Logiciel de
l’application
(taches 4- 8)
Système
d’exploitation 1
Système
d’exploitation 2
Couche d’abstraction
du matériel
Couche d’abstraction
du mat ériel
Processeur ( Arm 7)
Processeur (Arm7)
M3
IP
ARM 7
Rg
clk rst
(M1)
Logiciel de
l ’application
(taches 1-3)
Interface du
Interface du
processeur
processeur
(interface matérielle 1) (interface matérielle 2)
Fifo
Réseau de communication
Réseau de communication
IP
(M3)
À PC
(a)
(b)
Figure 29 Architecture logiciel/matériel de modem VDSL au
niveau RTL
La contrainte principale provient du réseau de communication de la plateforme qui est
fixé. Le problème est de savoir comment réaliser les interfaces matérielles et sur quel nœud
de prototypage.
4.3.5 Allocation
Dans l’étape d’allocation, on détermine les parties de la plateforme qui vont réaliser
chaque partie de l’application. Puisque l’architecture de l’application se compose de deux
processeurs ARM 7 et un IP, on décide alors d’utiliser deux modules de processeur avec
ARM 7 pour réaliser ces deux processeurs. Pour l’IP, nous décidons de le réaliser sur le
FPGA.
Pour la validation des interfaces, il faut les réaliser, en contournant le bus AMBA
imposé par la plateforme. Nous avons alors décidé d’implémenter les interfaces matérielles
et le réseau de communication sur le FPGA. Dans ce cas, les interfaces matérielles ne seront
plus directement connectées aux processeurs, mais doivent d’être connectée au bus AMBA.
La plateforme nécessite alors une phase de configuration pour cacher le bus AMBA.
Concrètement, on introduit un convertisseur de protocole entre l’interface matérielle et le bus
AMBA
66
Chapitre 4 : Applications
L’allocation des parties logicielles est plus facile dans ce cas. Tout le logiciel du
processeur M1 est exécuté sur le module du processeur 1 (nœud de prototypage logiciel 1), et
tout le logiciel de processeur M2 est exécuté sur module processeur 2. Comme la plateforme
ARM Integrator possède un plan d’adressage fixé différent de celui de l’application, on
modifie l’application pour respecter cette contrainte imposée par la plateforme. Nous
adaptons alors la couche d’abstraction du matériel. Le tableau 2 résume l’allocation de cette
application.
L'application
La plateforme
Processeur M1
Processeur M2
Logiciel de M1
Logiciel de M2
IP (M3)
Les interfaces matériel
Réseau de communication
Configuration :
Adaptation :
Carte du Processeur 1 (Arm7)
Carte du Processeur 2 (Arm7)
Exécuter par processeur 1
Exécuter par processeur 2
Module de FPGA
Module de FPGA
Module de FPGA
Convertisseur de bus AMBA
L'adressage sur la couche
d'abstraction matériel
Tableau 3 Allocation de l'architecture du VDSL sur la
plateforme ARM Integrator
4.3.6 Configuration
Dans ce cas, la configuration consiste à ajouter un convertisseur de protocole pour
cacher le bus AMBA de la plateforme. Une donnée du processeur vers l’interface matérielle
traversera consécutivement le bus AMBA, puis le convertisseur (AMBA vers ARM7). La
Figure 30 illustre cette configuration.
67
Chapitre 4 : Applications
(b)
Modèle simplifié de la plateforme Arm Integrator
( M1)
Logiciel de
l’application
(taches 1-3)
Système
d’exploitation 1
( M2)
Logiciel de
l’application
(taches 4-8)
Système
d’exploitation 2
Couche d’abstraction
du matériel
Couche d’abstraction
du matériel
Processeur 1 (Arm 7)
Processeur 2 (Arm7)
Carte processeur(Core Module)
Carte processeur(Core Module)
Processeur Arm 7
Processeur Arm 7
Interface AMBA
Interface AMBA
BUS AMBA
Interface du
Interface du
processeur
processeur
(interface matérielle 1) (interface matérielle 2)
Carte mère de la plateforme
Réseau de communication
FPGA
IP
(M3)
Carte FPGA (Logic Module)
(a) L’architecture de l’application
Logiciel de
l’application
(taches 1-3)
Système
d’exploitation 1
Logiciel de
l’application
(taches 4-8)
Système
d’exploitation 2
Couche d’abstraction
du matériel
Couche d’abstraction
du matériel
On ajoute un convertisseur qui
cache le bus AMBA
Carte processeur(Core Module)
Carte processeur(Core Module)
Processeur Arm 7
Processeur Arm 7
Interface AMBA
Interface AMBA
(c)
Architecture avec
convertisseur qui permet
cacher le bus AMBA
BUS AMBA
Carte mère de la plateforme
Convertisseur
Interface matériel 1
Interface matériel 2
Réseau de communication
M3 : IP
Carte FPGA (Logic Module)
Figure 30 Configuration de l’application VDSL
La Figure 31 donne l’architecture de ce convertisseur. Le bus AMBA AHB est
connecté à deux modules : un esclave par défaut et un pont AHB/APB à travers un décodeur
adresses (pour le bus d’adresses), et un multiplexeur (pour le bus de données). Les interfaces
matérielles sont connectées aux ponts AHB/APB à travers un bus APB. En plus de ces
modules, on utilise aussi un contrôleur d’interruptions pour gérer et multiplexer des
interruptions des interfaces matérielles car on n’a qu’une seule broche d’interruption à la
sortie du FPGA.
68
Chapitre 4 : Applications
Broche du FPGA
Donnée
(32 bit)
Adresse
(32 bit)
Décodeur d’adresses
Esclave par défaut
Pont AHB/APB
Contrôleur
d’interruption
s
Bus APB
(contient l’arbitre
et le décodeur
adresses)
Interface
Interface
Figure 31 Convertisseur
Ce convertisseur a été développé à partir des spécifications du bus AMBA et des
caractéristiques d’E/S des processeurs ARM 7, mais il est facilement réutilisable pour
d’autres prototypes sur cette plateforme. Il faut ajouter ou supprimer des interfaces (en
fonction du nombre d’interfaces matérielles) et modifier le décodeur d’adresses et l’arbitre
de bus APB (un seul fichier VHDL synthétisable).
4.3.7 Adaptation
L’adaptation dans cette expérimentation est très simple et se décompose en deux
parties. Il s’agit d’une part de modifier l’adresse de l’interface matérielle (des processeurs)
pour respecter celle imposée par la plateforme pour tous les FPGA. D’autre part, un
contrôleur d’interruptions qui multiplexe plusieurs sources d’interruptions est ajouté. Toutes
ces modifications sont faites dans la partie logicielle d’abstraction du matériel.
4.3.8 Génération de code
On divise l’étape de génération de code en deux parties : la partie matérielle et la partie
logicielle. La partie matérielle consiste en toutes les interfaces, le réseau de communication
et l’IP que l’on met sur le FPGA. La partie logicielle consiste en programmes que l’on
charge en mémoire pour les processeurs ARM 7.
69
Chapitre 4 : Applications
Pour la partie matérielle, la génération de code consiste en une addition du module de
plus haut niveau, suivie par la synthèse logique, et le placement routage. Le module de plus
haut niveau est un fichier VHDL qui encapsule tous les composants et modules que l’on met
sur le FPGA. La synthèse logique est effectuée en utilisant l’outil «FPGA compiler» de
Synopsys. Enfin, le placement routage est effectué en utilisant l’outil « Quartus 2 » de
Altera.
L’étape de génération de code pour la partie logicielle consiste en une addition d’un
module de déboguage, la compilation et l’édition de lien. Le module de déboguage permet
de connecter les programmes à un ordinateur pour afficher quelques messages de déboguage.
La compilation et l’édition de lien sont effectués en utilisant les outils de développement de
ARM (armcc, armcpp, armasm, et armlink). La Figure 32 montre le processus de génération
de code.
Compilation,
Édition du lien
Logiciel de
l’application
(taches 4-8)
Logiciel de
l’application
(taches 1-3)
Système
d’exploitation
Couche
d’abstraction du
matériel adapté
Système
d’exploitation
Couche
d’abstraction du
matériel adapté
Processeur
Processeur
Carte du processeur(Core Module)
Carte du processeur(Core Module)
Processeur
Mémoire
Processor
Processor
Processeur
Mémoire
Processor
Processor
JTAG
JTAG
JTAG
JTAG
JTAG
JTAG
FPGA
FPGA
FPGA
FPGA
Interface AMBA
Interface AMBA
BUS AMBA
Interface du
processeur
Interface du
processeur
PCI bus
Pé riphé rique
Mé moire
Carte mère de plateforme ARM Integrator
Convertiseur
Réseau de communication
FPGA
IP
Synthèse,
placement et routage
JTAG
mémoire
Entré/sortie
Carte du FPGA (Logic Module)
Figure 32 La génération de code
4.3.9 Résultats
La partie logicielle contient 106 fichiers (4915 lignes de code C/C++, et 597 lignes
assembleur), et après l’étape de génération du code, elle occupe 24,9 K Octets de ROM et
1,8 K Octets de RAM. La partie matérielle utilise 7107 éléments logiques, et prend 18 % de
70
Chapitre 4 : Applications
ressources du FPGA. La vitesse d’exécution de ce prototype est de 20 MHz (le processeur, la
partie matérielle dans le FPGA, et le bus AMBA).
La vitesse d’exécution (20 MHz) est très supérieure à celle obtenue avec co-simulation
en utilisant un ISS (quelques KHz). On décèle ainsi certains bogues qui apparaissent après de
nombreux vecteurs de test, ce qui est trop long en co-simulation. Mais bien sur, l’exécution
de ce prototype n’est pas précise au cycle prés.
La difficulté de cette expérimentation est la conception du convertisseur pour la
configuration. En effet il faut connaître en détail le fonctionnement du bus AMBA et les
protocoles d’entrées/sorties des processeurs. Néanmoins, ce convertisseur est largement
réutilisable.
4.4 Prototypage du DivX
4.4.1 Description de l’application
Le DivX est une technologie pour compresser un fichier vidéo sans réduire la qualité
visuelle. Cette technologie est basée sur le standard de compression MPEG 4. Elle permet de
compresser un fichier au format MPEG-2 (le format utilisé sur le DVD) jusqu'à 10 % de sa
taille d’origine. Malheureusement, l’encodeur est très complexe et l’implémentation temps
réel devient extrêmement difficile. La Figure 33 montre le schéma de l’encodeur DivX
[DIV01].
I Frame
DCT
Quant.
Zig-Zag
Huffman
Motion
Vectors
P Frame
Motion Estimation
Bitstream
Packing
DeQuant
Frame Buff.
Bitstream Output
IDCT
Motion Compensation
Figure 33 Schème de DivX encodeur
71
Chapitre 4 : Applications
L’encodeur DivX accepte en entrée une séquence d’images au format YUV 4:1:1. Ce
format présente l’image en utilisant trois matrices pour décrire luminances et chrominance.
La matrice Y décrit la luminance, et les matrices U et V présentent respectivement la
chrominance blanc-rouge et la chrominance blanc-bleu. La technologie exp loite les
réductions des redondances spatiale et temporelle. La redondance temporelle est réduite en
décrivant une image par ses différences seulement par rapport à l’image précédente. L’image
compressée de cette façon est appelée image P. La redondance spatiale est réduite en
utilisant la compression JPEG.
Le DivX est une application très complexe. La version gratuite de cette application est
appelée OpenDivX. L’OpenDivX peut être compilé en utilisant un compilateur standard de
C (comme gcc) et exécuté sur PC. Cette application contient environ 10000 lignes de code C.
Le temps d’exécution de ce programme prend environ une seconde pour une séquence de 20
petites images (format QCIF : 176 x 144) sur un processeur Athlon 4 à 1200 MHz. C’est très
loin des besoins de la plupart des formats vidéo qui nécessitent 30 images par seconde avec
des formats beaucoup plus grands (CCIR 720 x 576, CIF 352 x 288, HDTV 1280 x 720 – 60
images par seconde).
4.4.2 Objectif du prototypage et contraintes
Nous voulons développer un système multiprocesseur monopuce de l’OpenDivX
pour l’encodage en temps réel. Afin d’accélérer le temps d’exécution, le code de
l’application doit être parallélisé et son exécution doit être partagée entre plusieurs
processeurs. Une mécanisme de communication doit être alors inséré.
Avant de réaliser cette application sur une puce, on souhaite développer un prototype
sur une plateforme ARM Integrator. Les objectifs sont (1) de vérifier le code parallélisé, (2)
de vérifier le système d’exploitation pour être sur qu’il marche sur une configuration
multiprocesseur, et (3) d’insérer un mécanisme de communication.
Le prototype n’aura pas la même performance que le système monopuce final. En
effet, la fréquence d’horloge du processeur sur la plateforme ARM Integrator est beaucoup
plus lente (20 MHz), et le réseau de communication sur la plateforme est fixé à un bus
AMBA qui a une bande passante très limitée.
72
Chapitre 4 : Applications
4.4.3 La spécification et l’architecture RTL
L’encodeur divX est partitionné en deux modules avec une configuration maître et
esclave (Figure 34). Le maître effectue le processus du calcul de plus haut niveau. L’esclave
effectue le calcul du vecteur de mouvement et la compensation du mouvement. Un protocole
MPI [MPI95] (Anglais : Message Passing Interface) est choisi comme protocole de
communication.
I Frame
DCT
Quant.
Zig-Zag
Huffman
Motion
Vectors
P Frame
Motion Estimation
Bitstream
Packing
DeQuant
Frame Buff.
Bitstream Output
Motion Compensation
(b)
IDCT
Processeur Arm 9
Slave
(a)
tâche maître
tâche esclave
Processeur Arm 7
Figure 34 La spécification de départ de l'application DivX
MPI est une interface standard pour la communication entre plusieurs tâches sur une
machine parallèle. Dans notre application, nous n’implémentons que deux primitives :
MPI_send et MPI_receive. Ces deux fonctions permettent de réaliser des communications
bloquantes entre les taches en utilisant des FIFO. Chaque paire d’émetteur/récepteur a besoin
de deux FIFO : une FIFO pour garder le message, et la deuxième FIFO pour garder le tag.
Le tag est un identificateur du message.
La Figure 35 montre l’architecture logiciel/matériel de l’application. La partie
logicielle correspond aux tâches, aux systèmes d’exploitation, aux parties logicielles de
l’implémentation du protocole MPI, et aux couches d’abstraction du matériel. La partie
matérielle consiste en deux processeurs et au réseau de communication comprenant la partie
matérielle d’implémentation du protocole MPI.
73
Chapitre 4 : Applications
maître
esclave
Tache maître
Tache esclave
MPI
(partie logicielle)
Couche d’abstraction du
matériel
MPI
(partie logicielle)
Couche d’abstraction du
matériel
SE
SE
Processeur 1
Processeur 2
Interface matérielle 1
Contrôleur de FIFO
Interface matérielle 2
Contrôleur de FIFO
FIFO
donnée 1
FIFO
TAG1
FIFO
donnée 2
FIFO
TAG 2
Réseau de communication
Figure 35 L’architecture logicielle/matériel de l’application
DivX
Dans le standard MPI, les tâches (logiciel de l’application) émettent ou reçoivent des
données. Un message est un ensemble de données auquel s’ajoute des informations de
contrôle (entête, CRC,…). Un message est découpé en cellules. La taille d’une cellule est
fixée par la taille du bus de données. Pour profiter d’un mode de communication par paquets
(mode burst). On regroupe les cellules en paquets pour profiter des performances du réseau.
La Figure 36 illustre ce concept.
MPI_Send(@data,count,datatype,dest,tag,comm)
élément
Count x élément
cellule
Paquet
Figure 36 Décomposition des donnée
74
Chapitre 4 : Applications
La Figure 37 montre notre implémentation de la communication. Cette implémentation
est le résultat de la génération automatique en utilisant ASAG et ASOG. Sur la partie
logicielle, les fonctions MPI_Send et MPI_Receive sont fournies par l’élément
MPI_Std_SendRecv de la bibliothèque d’ASOG. Cet élément utilise des fonctions
Write_packet et Read_Packet qui sont fournis par l’élément packet_operation. L’élément
packet_operation a besoin des fonctions read_cell et write_cell fournies par l’élément
cell_operation. Enfin, l’élément cell_operation utilise des fonctions read et write (de la
couche d’abstraction du matériel) pour envoyer les données à la FIFO à travers le contrôleur
et le décodeur d’adresses de la FIFO. Le contrôleur de la FIFO gère l’état de la FIFO (la tête,
la queue) et informe le processeur si il y a un changement d’état de la FIFO (par exemple si
la FIFO devient pleine ou vide).
MPI_Send
MPI_receive
MPI_Std_sendRecv
Read_packet
Packet_operation
Write_cell
Read_cell
La partie logicielle
Write_packet
Cell_operation
Write
Read
Fonction de base de la couche
d’abstraction du matériel
La partie matérielle
Contrôleur et
décodeur de FIFO
(b) Notre implémentation de communication
Figure 37 Implémentation de la partie communication de
l’exemple DivX
75
Chapitre 4 : Applications
4.4.4 Allocation
A l’étape d’allocation, nous décidons de réaliser le plus possible de fonctions en
logiciel. Cette décision est dirigée par les contraintes de la plateforme ARM Integrator où le
réseau de communication est fixé. Toutes les fonctionnalités de MPI sont réalisées en
logiciel parce que l’on ne peut pas ajouter du matériel connecté directement aux processeurs.
La Figure 38 illustre le processus d’allocation. Il s’agit de faire correspondre chaque
partie de l’application avec une partie de la plateforme. Dans cette application, les deux
processeurs (processeur 1 pour le maître, et processeur 2 pour l’esclave) sont alloués à des
cartes processeurs (avec ARM 9 pour le maître et ARM 7 pour l’esclave). Les logiciels sur
ces processeurs sont respectivement exécutés par ces processeurs.
maître
esclave
Tache maître
MPI
(partie logicielle)
Couche d’abstraction du
matériel
SE
Processeur 1
Tache esclave
MPI
(partie logicielle)
Couche d’abstraction du
matériel
SE
Carte processeur( Core Module)
Carte processeur( Core Module)
Processeur
Mémoire
Arm7
Processor
Processor
Processeur
Mémoire
Arm9
Processor
Processor
JTAG
JTAG
JTAG
FPGA
FPGA
Processeur 2
FPGA
FPGA
Interface AMBA
Interface AMBA
Interface matérielle 1
Contrôleur de FIFO
JTAGJTAG
JTAG
Interface matérielle 2
Contrôleur de FIFO
BUS AMBA
FIFO
donn ée 1
FIFO
TAG1
FIFO
donn ée 2
FIFO
TAG 2
PCI bus
P ériphérique
Mémoire
Carte mère de plateforme ARM Integrator
Réseau de communication
FPGA
Allocation
JTAG
mémoire
Entré/sortie
Carte FPGA ( Logic Module)
Composant/ Element
Allocation
Processeur 1
ARM 9
Processeur 2
ARM 7
Tache maître
Exécuté par ARM 9
Tache esclave
Exécuté par ARM 7
Contrôleur de FIFO
Distribu é dans Proc 1 & 2
FIFO
Mémoire partagée
Non utilisé
Logic module
Tableau
d’allocation
Figure 38 Allocation de DivX
Le problème que l’on doit résoudre, provient de la partie de communication. On ne
peut pas réaliser les FIFO et ses contrôleurs en matériel à coté des processeurs. Pour obtenir
le prototype rapidement, les FIFO sont réalisées dans la mémoire partagée, et les
fonctionnalités de son contrôleur sont émulées par logiciel.
76
Chapitre 4 : Applications
4.4.5 Configuration
Il n’y a pas de configuration dans cette expérimentation. Toutes les difficultés sont
résolues par l’adaptation.
4.4.6 Adaptation
Après l’étape d’allocation, il existe encore une différence entre l’architecture du
système et celle de la plateforme ARM Integrator pour la partie communication. Le système
utilise des connexions point-à-point avec FIFO encapsulées par le protocole MPI. La
plateforme supporte uniquement un bus AMBA AHB pour la communication entre les
nœuds de prototypage.
Afin de résoudre ce problème, nous réalisons le comportement de la partie
communication en logiciel en gardant le même protocole. C'est-à-dire que les FIFO sont
réalisées sur les mémoires partagées, et les contrôleurs sont distribués dans les couches
d’abstraction du matériel. Comme nous souhaitons valider l’application et le système
d’exploitation, une réalisation différente de la communication ne devrait pas poser de
problème du point de vue de l’application.
Il s’agit donc de modifier les couches logicielles de bas niveau (couche d’abstraction
du matériel). Cette modification semble assez difficile car d’une part une partie de cette
couche est écrite en assembleur et nécessite de bien connaître le caractéristiques des cartes de
prototypage (processeur et FPGA), et d’autre part, cette couche logicielle est issue d’un
processus de génération automatique à l’aide des outils développés dans le groupe SLS. Pour
cette raison, j’ai modifié les outils de génération automatique, ce qui facilite cette étape
d’adaptation. Ceci est détaille au chapitre 5.
Le processus de cette adaptation consiste à revenir à la spécification de plus haut
niveau, à modifier cette spécification, et à régénérer une nouvelle couche d’abstraction du
matériel. La Figure 39 montre cette spécification. En effet, ce que nous faisons est de revenir
à l’abstraction précédente, car cette architecture est le résultat du raffinement de cette
spécification.
Dans cette spécification, chaque processeur possède une tâche : tâche maître et tâche
esclave. Ces tâches demandent des services de communication : MPI_send et MPI_receive.
Ces services sont indiqués dans les paramètres de port des tâches (service = MPI_send).
77
Chapitre 4 : Applications
L’implémentation de la partie logicielle de ce service est faite en utilisant l’élément
packet_operation de la bibliothèque ( Figure 37). La partie matérielle utilise des FIFO. Ces
éléments sont décrits sur les paramètres des ports externe et interne des processeurs.
maître
esclave
Tache maître
MPI
(partie logicielle)
Couche d’abstraction du
matériel
SE
processeur
Tache esclave
MPI
(partie logicielle)
Couche d’abstraction du
matériel
SE
Processeur 1
Processeur 2
Interface matérielle 1
Contrôleur de FIFO
Interface mat érielle 2
Contrôleur de FIFO
FIFO
donné e 1
FIFO
TAG1
FIFO
donnée 2
tâche maître
tâche esclave
FIFO
TAG 2
SoftPortType : Packet_operation
Service : MPI_send
HardPortType : FIFO
Réseau de communication
Figure 39 Revenir à la spécification plus haut niveau
Afin de générer l’interface logicielle adaptée à la plateforme, on doit modifier les
paramètres dans cette spécification. Le paramètre de SoftPortType est remplacé par
Packet_operation_on_plateforme.
Ce
paramètre
indique
l’implémentation
de
la
communication du coté logiciel. Coté matériel, nous ne générons pas d’interface matérielle,
nous utilisons le matériel existant de la plateforme.
Bibliothèque
processeur
tâche maître
Service : MPI_send
tâche esclave
- Implémentation de MPI sur laplateforme
- Couche d’abstraction du matériel de la plateforme
Arm
Générateur d’interfaces
logiciel/ASOG
SoftPortType : Packet_operation_on_plateforme_Arm
tâche maître
tâche esclave
MPI
SE
(partie logicielle)
couche d’abstraction du
matériel de la plateforme
MPI
(partie logicielle)
couche d’abstraction du
matériel de la plateforme
SE
Carte du processeur( Core Module)
Carte du processeur( Core Module)
Processeur
JTAG
Mémoire JTAG
JTAG
Arm7
Processor
Processor
Processeur
JTAG
Mémoire JTAG
Arm9
JTAG
Processor
Processor
FPGA
FPGA
Interface AMBA
FPGA
FPGA
Interface AMBA
HardPortType : Bus_AMBA_on_plateforme_Arm
BUS AMBA
PCI bus
Périphérique
Mémoire
Carte mère de plateforme ARM Integrator
Figure 40 Génération d’interface logicielle
La Figure 41 illustre la réalisation de la communication sur la plateforme. Du point de
vue du logiciel de l’application, la communication a le même comportement. Mais la
78
Chapitre 4 : Applications
réalisation de cette fonction est différente. Les fonctions write_cell et read_cell envoyent la
donnée à la FIFO sur la mémoire à la place de la FIFO physique. Ces fonctions logicielles
doivent gérer cette FIFO, c’est-à-dire mettre à jour les registres qui gèrent le nombre
d’éléments stocké dans à FIFO, l’adresse de la tête, et l’adresse de la queue de la FIFO. En
plus, ces fonctions envoye nt une interruption à l’autre processeur quand ils changent l’état de
la FIFO : à partir de l’état plein à l’état non plein (quand on récupère des
données/read_packet ), et à partir de l’état vide à l’état non vide (quand on envoie des
données/write_packet ). On a besoin alors de fonctions permettant d’envoyer des
interruptions aux autres processeurs. Cette fonction est une partie de la couche d’abstraction
du matériel.
MPI_Send
MPI_receive
MPI_Std_sendRecv
Parite logicielle
Write_packet
Read_packet
Packet_operation_on_plateform_ARM
Read_cell
Write_cell
Interrupt_processeur
Cell_operation
Write
Read
Fonction de base de la couche
d’abstraction du matériel
FIFO
Registre interrupt-num
Bus AMBA
Mémoire partagée
Figure 41 Implémentation de la partie communication sur le
prototype de l’application DivX
79
Partie matérielle
Interface de bus AMBA
Chapitre 4 : Applications
4.4.6.1 L’adaptation de la couche d’abstraction du matériel pour la partie MPI
Comme ce qui est illustré dans la Figure 41, le protocole MPI est réalisé en matériel et
en logiciel dans le système monopuce finale. La partie logicielle effectue deux tâches :
couper (ou fusionner) les messages envoyés à la taille de la FIFO et (2) envoyer ces
messages à la FIFO. La partie matérielle consiste en un décodeur d’adresses, deux FIFO et
un contrôleur de FIFO. Le décodeur d’adresses sélectionne les FIFO, le contrôleur de FIFO
enregistre et met à jour l’état de la FIFO (la tête, la queue, et le nombre d’éléments mémorisé
dans la FIFO). Ce contrôleur envoie des interruptions aux processeur s s’il y a des
changements d'état de la FIFO : de l’état plein à l’état non plein ou de l’état vide à l’état non
vide.
On ne peut pas connecter directement un FPGA/matériel aux processeurs (via le bus
AMBA) sur la plateforme, aussi toutes les fonctions requises par MPI sont faites en logiciel
ou plus précisément par une fonction dans la couche d’abstraction du matériel. La
fonctionnalité de la partie logicielle de MPI n’est pas changée. Dans cette couche logicielle,
les FIFO sont placées sur la mémoire partagé. On ne doit pas alors ajouter de FIFO
matérielles et le décodeur d’adresses pour ces FIFO. Les fonctionnalités du contrôleur de
FIFO sont distribuées en logiciel : La mise à jour des registres qui indique le nombre
d’éléments dans la FIFO est faite par les émetteurs/récepteurs dans la même temps ou ils
accèdent à la FIFO. L’interruption est envoyée de l’émetteur au récepteur si la FIFO n’est
plus vide. Ça se fait si l’émetteur envoie des nouvelles données à une FIFO vide.
L’interruption est envoyée du récepteur à l’émetteur si la FIFO n’est plus pleine. Ca se fait si
le récepteur retire des données d’une FIFO pleine.
4.4.6.2 L’adaptation de la couche d’abstraction du matériel pour un autre matériel
Les différences entre la partie matérielle de l’application et de la plateforme entraînent
quelques adaptations aussi sur la couche d’abstraction du matériel. Les différences
principales sont : le contrôleur d’interruption, et le plan de mémoire.
Dans l’application finale sur puce, le processeur ne doit pas envoyer des interruptions
aux autres processeurs car le contrôleur de FIFO gère l’état de la FIFO. Dans le prototype,
chaque processeur a besoin d’envoyer des interruptions aux autres processeurs qui
communiquent avec lui s’il change l’état de la FIFO. Le processeur a alors besoin d’un
espace dans la mémoire partagée pour communiquer le numéro d’interruption entre deux
80
Chapitre 4 : Applications
processeurs. Ces besoins entraînent : une fonction pour interrompre un autre processeur, une
sous-routine de traitement d’interruption pour contrôler le numéro d’interruption à la place
du registre dans le contrôleur de FIFO, et une synchronisation entre processeurs.
4.4.7 Génération du code
Le processus de raffinement génère les codes pour la couche d’abstraction du matériel,
le système d’exploitation et MPI. Ces codes et le code de tâches sont compilés, et téléchargés
sur le carte de processeur. Les codes C sont compilés en utilisant armcc, les codes C++ avec
armcpp, les codes assemble ur avec armasm. Enfin, nous faisons de l’édition du lien de tous
les codes pour avoir une image exécutable pour chaque processeur.
4.4.8 Résultats et analyse
L'expérimentation montre que le prototype peut être développé en moins de deux
semaines si la plupart des bibliothèques sont prêtes. Ces bibliothèques sont réutilisables, par
conséquent, nous ne devons les développer qu’une seule fois. Le prototype nous a donné le
moyen d’atteindre notre objectif : développer le logiciel de l’application (les tâches). Nous
avons validé le code parallélisé de l'application. De nombreux de bogues ont été trouvés et
corrigés. Le prototype traite environ 100 images au format QCIF par heure (3 images par
l’heure si on utilise une ISS).
Le système d’exploitation a été partiellement validé pour tourner sur la configuration
multiprocesseur. La plupart des problèmes que nous avons corrigés sont liés à la
synchronisation et au partage de ressources entre les processeurs. Il n'est pas facile trouver ce
genre de problèmes avec la simulation parce qu'ils ne se produisent pas à chaque exécution.
Par conséquent, cela prend un long temps d'exécution pour détecter ce problème en utilisant
la simulation.
81
Chapitre 5 : Analyse et perspectives
CHAPITRE 5 : ANALYSE ET PERSPECTIVES
5.1 Introduction...................................................................................................................................................84
5.2 Evaluation des exemples .............................................................................................................................84
5.2.1 VDSL..................................................................................................................................................... 84
5.2.2 DivX....................................................................................................................................................... 85
5.2.3 Synthèse................................................................................................................................................. 86
5.3 Automatisation de l’adaptation pour accélérer le développement du logiciel................................87
5.3.1 Les outils de génération automatique du flot ROSES ..................................................................... 87
5.3.2 L’automatisation de l’adaptation........................................................................................................ 93
5.3.3 Avantages et limitations...................................................................................................................... 96
5.3.4 Conclusion sur l’adaptation................................................................................................................ 98
5.4 Co-émulation .................................................................................................................................................98
5.4.1 Exemple de co-émulation en utilisant la plateforme ARM Integrator.......................................... 98
5.4.2 Evaluation ...........................................................................................................................................104
5.4.3 Perspectives.........................................................................................................................................105
83
Chapitre 5 : Analyse et perspectives
5.1 Introduction
Le chapitre 4 a décrit deux applications prototypées sur la plateforme ARM Integrator
en utilisant le flot de prototypage donné dans le chapitre 3.
Ce chapitre cherche maintenant à évaluer ces exemples, et voir dans quels cas il est
possible de réaliser un prototypage automatique. Pour cela, on s’intéresse plus
particulièrement à l’étape adaptation dont l’automatisation n’est pas triviale. On termine ce
chapitre par une extension de la proposition à la co-émulation.
5.2 Evaluation des exemples
5.2.1 VDSL
Le premier exemple donné est l’application VDSL. Dans ce cas d’étude, nous voulions
vérifier les fonctionnalités des interfaces en utilisant le prototypage. Afin d’obtenir le
prototype, nous avons effectué les quatre étapes du flot de prototypage.
La première étape est l’allocation. Dans cette étape, la principale difficulté est d’avoir
un réseau de communication différent entre la plateforme et l’application. Pour vérifier la
fonctionnalité des interfaces, il faut introduire un modèle du réseau de l’application dans le
nœud de prototypage matériel. Ce qui nécessite aussi un convertisseur entre le protocole du
réseau de communication imposé par la plateforme et celui de l’application. Il faut donc
modifier la couche logicielle d’abstraction du matériel. C’est dans cette étape d’allocation
que sont prises les décisions concerna nt l’adaptation et la configuration. La principale
difficulté présentée par cette application peut être résolue en introduisant un convertisseur de
protocole ; ceci concerne la configuration de la plateforme.
La deuxième difficulté est la partie matérielle différente entre la plateforme et
l’application. Ces différences sont concernant le contrôleur d’interruption et le plan mémoire.
Ce problème se résout en modifiant le modèle RTL, notamment la couche d’abstraction du
matériel de l’application.
L’étape suivante est la configuration. Pour l’application VDSL, on a développé un
convertisseur pour cacher le bus AMBA et l’interface AMBA. Le modèle de ce
convertisseur est synthétisable, puisqu’il est réalisé dans le FPGA d’un nœud de prototypage
matériel. Il a été écrit d’une façon générique et peut se connecter à plusieurs processeurs
84
Chapitre 5 : Analyse et perspectives
ARM de type différent (ARM 7 et ARM 9). La conception de ce convertisseur n’est pas
difficile et il est réutilisable sur une même plateforme.
L’adaptation consiste à modifier une partie de l’application qui est généralement la
couche logicielle de plus bas niveau. En effet, il n’est pas possible d’insérer une autre couche
logicielle pour détourner les incompatibilités, puisque cette couche logicielle communique
directement avec le matériel. Dans le cas du VDSL, cette modification n’est pas très difficile,
mais le concepteur doit connaître toutes les adresses utilisées dans le code (assembleur
généralement). Il peut aussi être amené à modifier les routines de traitement des
interruptions. Aussi, une automatisation faciliterait cette phase de prototypage.
La dernière étape est la génération de code pour laquelle de nombreuses phases sont
déjà automatisées : synthèse, placement routage, compilation, édition de lien, chargement.
Dans la partie matérielle, il faut cependant ajouter le module de plus haut niveau, et dans la
partie logicielle, il faut ajouter des fonctions de déboguage. Ces deux tâches ne sont pas
automatisées, mais elles ne présentent que peu de difficulté.
5.2.2 DivX
Dans la deuxième expérience, nous avons développé le prototype de l’application
DivX pour faciliter le développement du logiciel de l’application. Dans ce cas, nous ne nous
intéressons pas au détail de réalisation de la partie matérielle, ni de la couche logicielle de
bas niveau. Comme on souhaite valider les tâches, il faut respecter la spécification de
l’échange des informations entre les tâches, indépendamment de la réalisation physique et
des protocoles. On n’a donc pas besoin ici que le réseau de communication de la plateforme
soit proche ou identique à celui de l’application finale.
Dans l’étape d’allocation, le problème porte toujours sur le réseau de communication
de la plateforme différent de celui de l’application. Même si l’objectif du prototypage, la
validation du logiciel de l’application n’impose pas d’avoir le même réseau de
communication, il faut modifier l’application pour utiliser le bus AMBA de la plateforme et
les mémoire partagées, et émuler les fonctionnalités du contrôleur de FIFO en logiciel. Tout
ceci entraîne d’importantes modifications dans la partie logicielle d’abstraction du matériel.
Les décisions prises pendant l’allocation guide le reste du processus de prototypage.
85
Chapitre 5 : Analyse et perspectives
Dans cet exemple, il n’y a pas de configuration car on n’a pas besoin de réaliser le
réseau de communication étant donné l’objectif du prototypage.
La difficulté dans le prototypage du DivX était la modification des couches logicielles
de bas niveau dépendant du matériel pour réaliser les protocoles de communication MPI. A
cela s’ajoute le fait de ne pas utiliser le nœud de prototypage matériel, ce qui empêche de
réaliser les FIFO de façon matérielle. Il a donc fallu trouver une nouvelle méthode pour
réaliser les fonctions MPI entièrement en logiciel, et réécrire toute la partie logicielle de bas
niveau. On a donc essayé de trouver une technique pour automatiser ces transformations
délicates et source d’erreurs.
Comme ces couches logicielles de bas niveau sont obtenues automatiquement avec
l’outil ASOG à partir d’une spécification du système, on a donc réorganisé la spécification et
généré ces couches logicielles adaptées à la plateforme. Mais cette transformation n’est pas
aisée. Cette technique est décrite dans le paragraphe 5.3.
Comme dans l’exe mple précédent, l’étape de génération du code est entièrement
automatisée.
5.2.3 Synthèse
Enfin, on peut conclure que :
•
La décision principale est prise dans l’étape d’allocation. Cette décision dépend des
contraintes imposées par la plateforme, et de l’objectif du prototypage.
•
Dans l’étape de configuration et d’adaptation, on implémente les décisions prises dans
l’étape d’allocation.
•
Le convertisseur utilisé dans l’étape de configuration est réutilisable sur la même
plateforme.
•
L’adaptation est une étape très laborieuse. L’automatisation est nécessaire pour simplifier
cette étape.
•
L’étape de génération du code est déjà automatique.
86
Chapitre 5 : Analyse et perspectives
5.3 Automatisation de l’adaptation pour accélérer le développement du
logiciel
Le développement du logiciel est devenu un goulot d’étranglement dans le flot de
conception des systèmes monopuces. En effet, il représente une part très importante du
temps de développement du système, mais aussi, il ne peut être validé que si l’on a le
matériel pour l’exécuter. Ce qui signifie que les concepteurs retardent sa validation jusqu’à
l'obtention du circuit. Aussi, une plateforme de prototypage est une alternative si celle-ci est
utilisée comme un environnement pour développer ce logiciel. Elle permet alors d'accélérer
la conception du système.
Dans le chapitre précèdent, nous avons montre un exemple de prototypage de
l’application DivX (paragraphe 4.4). Ce prototypage avait pour objectif de valider le logiciel
de l’application le plus tôt possible. L’objectif de ce paragraphe est alors de présenter
l’automatisation de l'adaptation en utilisant le flot ROSES.
Ce paragraphe décrit le flot ROSES, ainsi que son utilisation pour l’étape d’adaptation.
On discute ensuite des avantages et des limitations de cette technique.
5.3.1 Les outils de génération automatique du flot ROSES
Le flot ROSES du groupe SLS permet la génération automatique d’interfaces
logiciel/matériel des systèmes monopuces. L’interface logiciel/matériel (Figure 42) générée
est un adaptateur de communication entre les taches exécutées par le processeur et les
ressources matérielles. Plus précisément l’interface logicielle permet au code de l’application
d’accéder aux ressources matérielles du processeur (typiquement pour faire des E/S) et
l’interface matérielle permet au processeur d’accéder au réseau de communication.
Les interfaces matérielles prises en compte par ROSES concernent les processeurs
[LYO03], mais aussi la mémoire [GHA03], et les composants matériels spécifiques
[GRA04]. Les interfaces logicielles sont les systèmes d’exploitation [GAU01] et les couches
de communications [PAV04]. L’intérêt de ROSES est la génération automatique des
interfaces à partir d’une spécification du système et de quelques caractéristiques pour guider
la conception (protocoles, adressage, et autres paramètres). De plus, ce flot permet une
validation à plusieurs niveaux d’abstraction à l’aide de mécanismes de co-simulation
[NIC02].
87
Chapitre 5 : Analyse et perspectives
Logiciel de l’application
Interface
logiciel
Système d’exploitation
Couche d’abstraction du matériel
IP
Processeur
Interface
matériel
Interface du processeur
Interface de l’IP
Réseau de communication
Figure 42 Interface logiciel/matériel
Le principe le plus important dans ce flot est la conception d’un système complet par
assemblages d’éléments [CES02]. Que ce soit pour composer les parties logicielles des
interfaces ou les parties matérielles mais aussi le développement des modèles de simulation,
la technique reste la même : cela consiste en un assemblage d’éléments de bibliothèque.
Le flot de conception ROSES est composé principalement de trois outils : ASAG,
ASOG, et Cosimix.
•
ASAG est l’outil de génération des interfaces matérielles.
•
ASOG est l’outil de génération des interfaces logicielles.
•
Cosimix est l’outil de génération des interfaces pour simulation.
La Figure 43 montre le flot qui permet la génération d’interfaces à partir d’un système
décrit au niveau architecture vers une description au niveau RTL. L’entrée du flot est décrite
en langage de spécification développé par le groupe SLS. Ce langage est une extension de
SystemC [SYS00] nommé VADeL pour Virtual Architecture Description Language pour
faire référence au concept de modules virtuels décrit prochainement.
88
Chapitre 5 : Analyse et perspectives
Description de
l’architecture
(en VADel)
A
B
CosimX
SIMULATION
C
description en Colif
ASAG
ASOG
A
C
Système d’exploitation
CosimX
Couche d ’abstraction du matériel
SIMULATION
B
Processeur
Interface du processeur
Interface de l’IP
Réseau de communication
architecture RTL
Figure 43 le flot ROSES
VADel [CES01] est un langage construit à partir de C++ : il est donc orienté objet. Le
C++, avec son concept de classes d’objets permet de développer facilement de nouvelles
structures de données. En fait, VADeL n’est pas une extension directe de C++, mais c’est
une extension de SystemC, un langage de description de matériel pour la simulation.
La première étape du flot consiste à traduire la spécification en VADel annotée en
COLIF [CES01]. La spécification en COLIF décrit un système comme un ensemble d’objets
interconnectés de trois types : les modules, les ports et les liens (en anglais : net). Un objet,
quel que soit son type, est composé de deux parties. La première partie, nommée «entity»,
permet la connexion avec les autres objets. La deuxième partie, nommée «content», fournit
89
Chapitre 5 : Analyse et perspectives
une référence à un comportement ou des instances d’autres objets. Cette possibilité
d’instancier des éléments permet le développement de modules, ports et liens hiérarchiques.
port
Tache (module
logiciel)
IP
(module matériel)
Tache (module
logiciel)
lien
processeur
(module matériel)
Figure 44 Un exemple de modules, de liens, et de ports
La Figure 44 montre un modèle décrit en COLIF. Les boites carrées représentent les
modules, les petits boites foncées représentent les ports, et les lignes représentent les liens.
Les fonctionnalités de chaque élément sont les suivantes :
1. Le module représente un composant matériel ou logiciel. Son «entity» donne son type et
les ports par lequel il communique. Son «content» peut, être caché (boite noire), contenir
des références à un comportement (ex : fichier C ou VHDL/matériel connu), mais peut
aussi être un sous-système décrit sous forme de modules, ports et liens.
2. Le port représente un point de communication pour un module. Son «content» est
composé de deux parties : l’une est en relation avec l’intérieur du module et l’autre avec
l’extérieur. Ces deux parties peuvent être cachées, contenir des références à un
comportement ou des instanciations de ports.
3. Le lien (Anglais : net) représente une connexion entre plusieurs ports. De la même façon,
un lien peut contenir des références à un comportement ou contenir d’autres liens.
En utilisant cette description COLIF, le système est décrit au niveau architecture pour
l’entrée du flot ROSES. En ce point, le système est décrit comme un ensemble de modules
virtuels communicants par des canaux virtuels à travers des ports virtuels (Figure 45).
90
Chapitre 5 : Analyse et perspectives
modules virtuels
port interne
tache
module
matériel
tache
processeur
port virtuel
port externe
canal virtuel
port de tache
Figure 45 Un exemple d’entée du flot ROSES
Un canal virtuel est un canal de communication de haut niveau d’abstraction (on utilise
aussi le terme de canal abstrait) qui représente un ou plusieurs canaux de bas niveau
d’abstraction. Les caractéris tiques de ce canal sont connues (le protocole utilisé, la taille du
bus, la taille de la FIFO, ….) mais les détails de réalisation n’apparaissent pas explicitement
(le bus de données, les signaux de contrôle, d’adresses, …). On utilise la notion de lien en
COLIF pour spécifier le canal virtuel.
Ce canal virtuel permet la communication entre les modules virtuels. Le module virtuel
encapsule des composants. Ce composant virtuel accède au canal virtuel en traversant un
port virtuel. Un port virtuel est composé de ports internes (connectés aux composants) et de
ports externes (connectés aux canaux virtuels). Les ports virtuels adaptent les protocoles et
les niveaux d’abstractions entre les ports externes et les ports internes. Ceci permet aux
composants de modules virtuels de ne pas être décrits au même niveau d’abstraction, et de
pouvoir s’échanger des informations.
A partir de ce modèle, vient une étape de génération d’interfaces matérielles (outils
ASAG). Un autre outil (ASOG) permet la génération des interfaces de communication
logicielles. Il existe aussi un outil de génération d’interface de simulation utilisable à partir
du modèle haut niveau et de modèle raffiné (CosimX).
L’outil ASOG a été développé par Lovic Gauthier dans son travaille de thèse
[GAU01]. Cet outil génère l’interface logicielle qui consiste en un système d’exploitation
91
Chapitre 5 : Analyse et perspectives
minimal et la couche d’abstraction du matériel à partir de paramètres donnés dans les ports.
Les paramètres des ports de taches décrivent les services de communication demandés et
requis par la tache. Les paramètres de ports internes indiquent l’implémentation de
l’interface logicielle.
Service = MPI_Send
tache
Sélection de
composants
Analyse
d’architecture
Expansion de
composants
tache
tache tache
OS
couche
d’abstraction
matériel
processeur
processeur
SoftPortType : Guarded_Register
Lecture de
bibliothèque
Description des
dépendances
d’éléments
bibliothèque
Figure 46 ASOG
La Figure 46 montre les quatre actions exécutées par ASOG pour générer l’interface
logicielle : analyse de l’architecture, lecture de la bibliothèque, sélection des composants, et
expansion des composants. A l’étape analyse de l’architecture, l’outil recherche le matériel
utilisé (le processeur), les services requis (paramètres des ports de tâche), et
l’implémentation de ce service (paramètres des ports internes du processeur). Et puis, l’outil
sélectionne les éléments de bibliothèque nécessaires pour construire ces services. Enfin, les
éléments de bibliothèque sont paramétrés pour obtenir le code de l’interface logicielle.
L’outil ASAG a été développé par Damien Lyonnard dans son travaille de thèse
[LYO03]. Cet outil prend en entrée, la description structurelle de l’application en COLIF.
ASAG possède deux bibliothèques. L’une contient des structures génériques d’interfaces et
l’autre des fichiers décrivant le comportement des composants assemblés. En sortie, on
obtient une description COLIF au niveau RTL de l’architecture de l’interface et de celle de
l’architecture locale du processeur. On obtient aussi le code synthétisable VHDL ou
SystemC de l’architecture.
92
Chapitre 5 : Analyse et perspectives
tache
IP
tache
processeur
Description en Colif
Bibliothèque
de structures
- Architectures
locales
- Adaptateurs de
canaux
Bibliothè que
de comportement
Lecture de la
bibliothèque
Lecture de la
description
Raffinement de
module
Raffinement de
canal
- Processeur
- Communication
Génération de code
ASAG
Code des interfaces en
VHDL ou SystemC
Description Colif de
l’ architecture RTL
Figure 47 Génération des interfaces matérielles par ASAG
L’outil CosimX est utilisé pour valider les systèmes décrits à plusieurs niveaux
d’abstraction. Il permet de rendre exécutable la description VADeL du système. L’exécution
du système avant génération des interfaces permet de valider le comportement des tâches,
des IP ainsi que le choix des services de communication. CosimX offre aussi la possibilité de
tester le fonctionnement du système après le raffinement partiel ou complet du système (cosimulation).
5.3.2 L’automatisation de l’adaptation
Après le développement des composants et la génération des interfaces, on peut
commencer le prototypage. Dans cette phase, les concepteurs possèdent toutes les parties de
l’application au niveau RTL. Les parties matérielles sont décrites en langage de description
de matériel. Elles sont synthétisables. Les parties logicielles sont en langage C/C++ ou en
langage assembleur.
Les parties logicielles ne correspondent pas encore à la version finale (celle
implémentée sur la puce), car leur validation est faite sur la plateforme de prototypage, puis
sur la puce finale. Mais ce prototypage suppose de repenser les couches du logiciel
dépendant du matériel, ce qui constitue l’adaptation de l’application à la plateforme.
93
Chapitre 5 : Analyse et perspectives
La modification manuelle de programmes est une tache difficile. Mais l’outil ASOG
capable de générer un système d’exploitation minimal et la couche d’abstraction du matériel
peut être utilisé pour régénérer une couche d’abstraction du matériel adaptée à la plateforme.
Cette transformation peut être vue comme une abstraction des couches logicielles de bas
niveau à extraire de l’architecture RTL de l’application pour permettre une nouvelle
génération. Cette abstraction est relativement facile dans notre cas puisque ces couches
logicielles sont déjà le résultat d’une génération automatique ASOG. Ce qui est fait, est de
revenir en arrière dans le flot de conception, et de changer les paramètres pour obtenir les
couches basses du logiciel adaptée à la plateforme en conservant les même services appelés
par les taches. Comme on l’a déjà mentionné à plusieurs reprises, cette phase d’adaptation
est difficile à faire manuellement. Et enfin, générer du code automatiquement pour ensuite le
modifier à la main est une perte de temps qui pourrai être évitée. Cette nouvelle génération
doit être transparente du point de vue du logiciel de l’application, et les concepteurs ne
doivent pas voir les différences d’implémentation de la partie matérielle.
Service: Get_Protocole_X_with FIFO
tâche
tâche
Hard_PortType :_P2P_with_FIFO_
SE
couche
d’abstraction
matériel
=
tâche1
tâche2
processeur
processeur
Interface matériel
SoftPortType : _software_impl_of_prot_ X
Nouveau paramètres
Service: Get_Protocole_X_with FIFO
Hard_PortType :_reconfigurable_plateforme
tâche1
tâche2
processeur
SoftPortType : _software_impl_of_prot_X_with_FIFO
Figure 48 Abstraction et modification de paramètres
La Figure 48 illustre un exemple de cette adaptation. Dans cet exemple, un appel de
service get_protocole_X_with FIFO est requis par une tache. Cet appel est une demande de
94
Chapitre 5 : Analyse et perspectives
donnée au port qui utilise un protocole X. Ce port est implémenté en logiciel et en matériel.
Le paramètre SoftPortType dans le port interne du processeur indique l’implémentation
logicielle de ce protocole. Le paramètre HardPortType dans le port externe du processeur
indique une réalisation matérielle de l’interface. Dans ce paramètre, on trouve que ce port
est implémenté en utilisant une connexion point-à-point et une FIFO.
Pour avoir une nouvelle couche d’abstraction du matériel, on modifie les paramètres
des ports interne et externe du processeur en gardant le même paramètre de port de tache.
Dans cet exemple, on garde le paramètre de service get_protocole_X_with FIFO dans le port
de la tache, mais les implémentations logiciel/matérie l sont changées. On n’utilise plus une
connexion point-à-point avec une file (FIFO), on utilise le réseau de communication
disponible dans la plateforme reconfigurable. L’implémentation de la FIFO est déplacée en
logiciel. Le logiciel doit alors abstraire l’implémentation du matériel et émuler la FIFO
matérielle en mémoire.
Spécification de l’application
Spécification du prototype
Service: Get_Protocole_X_with FIFO
Service: Get_Protocole_X_with FIFO
Hard_PortType :_reconfigurable_plateforme
Hard_PortType :_P2P_with_FIFO_
tâche1
tâche1
IP
ADAPTATION
Changement de paramètres
IP
tâche2
tâche2
processeur
processeur
SoftPortType : _software_impl_of_prot_X_with_FIFO
SoftPortType : _software_impl_of_prot_X
ASOG
ASAG
ASOG
tâche
tâche
tâche
SE
couche
d’abstraction
matériel
processeur
tâche
SE
Nouvelle
couche
d’abstraction
du matériel
Processeur
(nœud prototypage
logiciel)
IP
IP
FPGA
(nœud prototypage
matériel)
Interface matérielle
Réseau de communication fixée
Plateforme réconfigurable
Figure 49 Génération de la couche d’abstraction du matériel
La Figure 49 montre la génération de la nouvelle couche d’abstraction du matériel pour
le prototype. On génère une nouvelle couche d’abstraction du matériel à partir d’un nouveau
modèle (modèle de haut niveau adapté). Avec cette nouvelle couche, le logiciel pilote le
95
Chapitre 5 : Analyse et perspectives
matériel de la plateforme en utilisant le même appel de service. En plus, cette couche émule
la fonctionnalité de la partie matérielle qu’on ne peut pas réaliser sur la plateforme. Dans cet
exemple, la FIFO matérielle est émulée par cette couche.
5.3.3 Avantages et limitations
5.3.3.1 Accélération du processus du prototypage
Le prototype développé dans la paragraphe précèdent permet d’accélérer l’adaptation
grâce à l’utilisation d’outil de génération automatique ASOG. On peut donc obtenir plus
rapidement le prototype. De plus, la génération automatique permet la réutilisation des
éléments de bibliothèque. Ils ne sont alors développés qu’une seule fois.
La réutilisation et la génération automatique permettent aussi d’éviter des erreurs. Si la
bibliothèque est correcte, on a juste besoin de modifier les paramètres pour générer la bonne
couche d’abstraction du matériel.
5.3.3.2 Nécessité de la bibliothèque
Pour utiliser cette technique, la bibliothèque doit avoir les éléments pour réaliser tous
les services requis sur la plateforme. Ces éléments doivent avoir les mêmes comportements
que sur la puce finale.
L’utilisation d’élément de bibliothèque est décrite sur [GAU01]. A partir d’un service
requis par une tâche, l’outil ASOG détermine l’élément utilisé. Il est possible d’avoir
plusieurs réalisations de cet élément. Le outil ASOG décide alors de choisir une réalisation
avec les bons paramètres. Ce choix et la valeur des paramètres dépendent des paramètres
associés aux ports interne et externe.
Chaque élément doit posséder dans la bibliothèque au moins deux solutions de
réalisation, l’une pour le système monopuce, l’autre pour la plateforme. En pratique, il y en a
plus car un élément ou un service peut être découpé en parties logicielle et matérielle avec
des frontières différentes [PAV04]. Il faut aussi s’assurer de la validation de ces éléments de
bibliothèque et leur compatibilité, ce qui reste une difficulté non abordée dans cette thèse.
5.3.3.3 Limitation des possibilités de validation
L’intérêt d’une adaptation automatique est d’obtenir au plus vite le prototype pour
développer et valider ou optimiser au plus tôt les parties logicielles. La Figure 50 montre
96
Chapitre 5 : Analyse et perspectives
qu’une couche d’abstraction du matériel est nécessaire pour exécuter le logiciel à développer
sur la plateforme.
L’exécution du logiciel d’application sur ce prototype présente des avantages par
rapport à la co-simulation. La co-simulation en utilisant un ISS et un simulateur (VHDL par
exemple) est très lent. Il est alors difficile de vérifier le logiciel d’application, souvent très
complexe et dont l’exécution peut prendre beaucoup de temps. La plateforme permet
d’observer les vrais effets du parallélisme et de valider la synchronisation entre les tâches.
Logiciel à développer
Logiciel de l’application
Système d’exploitation
Logiciel de l ’application
Adaptation
Système d’exploitation
Couche d’abstraction du matériel
Couche d’abstraction du matériel
IP
IP
Processeur
Interface du processeur
Processeur
Interface de l ’IP
Interface du processeur
Réseau de communication
(sur le système monopuce final)
Interface de l ’IP
Réseau de communication
(sur la plateforme de prototypage)
Matériel avec différent implémentation
Figure 50 L'adaptation pour développer le logiciel
On peut aussi vérifier les parties du système d’exploitation qui sont complètement
indépendantes de matériel : l'ordonnanceur, les sémaphores, la pile, …… Mais, ce qui
dépend du matériel est difficile, voire même impossible à vérifier : le latence d’une
d’interruption, compteur de temps, …. .
Le prototypage tel que décrit dans cette thèse ne permet pas le développement ou la
validation de la couche logicielle d’abstraction du matériel.
5.3.3.4 Nécessité d’un bon découpage en couches logicielles
Cette technique d’adaptation repose sur le principe que la partie logicielle de
l’application est structurée en couches bien différenciées. Dans ce cas, seule la partie
dépendante du matériel est modifiée, ce qui laisse la partie applicative et le système
d’exploitation identiques sur le prototype et sur l’application finale.
97
Chapitre 5 : Analyse et perspectives
5.3.4 Conclusion sur l’adaptation
Dans ce paragraphe, on a discuté d’une méthode de prototypage sur une plateforme
reconfigurable qui permet d’avancer le développement du logiciel. Afin d’obtenir
rapidement un prototype, on utilise le flot ROSES de l’équipe SLS pour automatiser l’étape
d’adaptation. Ce flot permet de générer une couche d’abstraction du matériel. Cette couche
est utilisée pour remplacer celle qui n’est pas compatible avec la plateforme. On peut alors
prototyper l’application sur cette plateforme reconfigurable. Ce prototype est alors utilisé
comme un environnement pour exécuter le logiciel d’application. Le développement du
logiciel le plus tôt possible écourte le temps de conception global des systèmes monopuces
car les concepteurs développent le logiciel sur un environnement de développement presque
similaire à la puce finale.
5.4 Co-émulation
5.4.1 Exemple de co-émulation en utilisant la plateforme ARM Integrator1
Un moyen pour réaliser un prototype est la co-émulation. La co-émulation consiste à
mélanger la simulation et l’émulation pour prendre les avantages des deux techniques de
vérification. La simulation donne une bonne observabilité et des possibilités d’utiliser des
niveaux d’abstraction élevés. L’émulation permet une exécution rapide.
Dans ce paragraphe, nous allons faire une expérience de co-émulation en utilisant la
plateforme ARM Integrator. Comme exemple de l’application, nous utilisons l’application
DivX expliquée dans le paragraphe 4.4.1.
5.4.1.1 Les principes
Avant d’aborder la co-émulation, je vais discuter un peu de co-simulation en utilisant
SystemC puisque notre expérimentation est basée sur le même principe. Dans le schéma de
principe de la Figure 51, le module SystemC de plus haut niveau encapsule plusieurs sousmodules SystemC (représentant le comportement de l’application) et un module non
SystemC, appelé adaptateur SystemC. Ce module est une interface avec un autre simulateur
1
Un travail commun avec M. Jinyong Jung
98
Chapitre 5 : Analyse et perspectives
(simulateur VHDL, ISS, …) appelé pour simuler une partie du système. Ce module
adaptateur SystemC communique avec le simulateur en utilisant une mémoire partagée.
Adaptateur
SystemC
(module
NonSystemC)
Sous module
SystemC
Autre
Simulateur
SystemC module
Figure 51 Co-simulation avec SystemC
Ce même principe est utilisé pour la co-émulation. L’adaptateur SystemC communique
avec une interface de co-émulation qui elle est connectée à l’émulateur (Figure 52).
L’interface de co-émulation est un pilote (logiciel) qui gère la communication physique avec
la plateforme. Cette interface est spécifique selon, le type de connexion mis en œuvre (port
série, USB,….) et le système d’exploitation (Windows, Linux,…).
Sous module
SystemC
Adaptateur
SystemC
Interface de
co-émulation
Émulateur/
Plateforme
SystemC module
Figure 52 Connexion entre une simulation SystemC et un
émulateur
5.4.1.2 Connections physiques avec l’ARM Integrator
Pour la co-émulation, on a besoin d’établir une connexion entre l’ordinateur et la
plateforme que l’on utilise. Nous analysons cinq solutions possibles de connexions
physiques que l’on peut utiliser sur ces plateforme. Le choix des connexions est très
dépendant de la plateforme utilisée.
99
Chapitre 5 : Analyse et perspectives
5.4.1.2.1
Connexion multi- ICE
Le premier choix est le multi-ICE et les interfaces JTAG sur la carte processeur et la
carte FPGA (Figure 53). On connecte l’environnement de simulation SystemC au serveur
multi-ICE à travers l’interface de co-émulation. Cette interface de co-émulation agit comme
client de multi-ICE.
Carte du processeur
Carte du FPGA
JTAG
JTAG
Sous
module
SystemC
Interface de
co-émulation
(client de
multi ICE)
adaptateur
SystemC
Serveur
de
Multi-ICE
Unité
d’interface
Multi-ICE
Processeur
FPGA
BUS AMBA
SystemC module
PCI bus
Carte mère de plateforme ARM Integrator
Figure 53 Co-émulation en utilisant une connexion multi-ICE
La partie à développer dans ce schéma est l’interface de co-émulation (client de multiICE) et un contrôleur JTAG pour la carte FPGA. Le goulot d’étranglement de cette
connexion est la vitesse du JTAG sur multi-ICE qui est 20 K bits par seconde.
5.4.1.2.2
Connexion en utilisant de carte réseau
Le deuxième choix est d’utiliser d’une carte réseau (carte Ethernet). On utilise des
cartes réseau des deux cotés : sur l’ordinateur et sur la plateforme. La carte réseau est insérée
sur le bus PCI de la plateforme. Le processeur ARM et la carte FPGA communiquent alors
avec la carte réseau à travers le bus AMBA et bus PCI (Figure 54). La connexion entre les
deux cartes réseau est réalisée à travers un réseau local d’ordinateurs (LAN : local area
network).
Carte processeur
Carte FPGA
JTAG
JTAG
Sous
module
SystemC
Adaptateur
SystemC
Processeur
Interface de
co-émulation
(carte
réseau)
FPGA
BUS AMBA
SystemC module
PCI bus
Carte mère de plateforme ARM Integrator
Carte
réseau PCI
Figure 54 Co-émulation en utilisant une carte réseau
100
Chapitre 5 : Analyse et perspectives
Pour réaliser cette configuration, on doit développer les fonctions du protocole TCP/IP
(protocole pour internet/réseau), et un pilote pour la carte réseau sur la plateforme. La vitesse
maximum de cette connexion est limitée à 10 Mbits/s.
5.4.1.2.3
Connexion en utilisant un pont PCI/PCI
Une alternative de connexion que l’on peut développer est un pont de bus PCI/PCI.
L’ordinateur et la plateforme possèdent des bus PCI et des connecteur s PCI (PCI slot). On
peut donc les connecter directement à travers un pont. Cette connexion est inhabituelle car
on a deux hôtes : le processeur de la plateforme et l’ordinateur.
Pour connecter deux bus PCI (celui de la plateforme et celui du PC), il faut développer
une carte PCI/PCI et les fonctions associées à ce protocole pour les processeurs et les FPGA
de la plateforme, et dans l’interface de co-émulation. La vitesse de cette connexion est
limitée à 133 Mbits/s.
Carte processeur
Carte du FPGA
JTAG
JTAG
Sous
module
SystemC
Adaptateur
SystemC
Interface de
co-émulation
(bus PCI
dans
l’ordinateur)
Processeur
FPGA
BUS AMBA
SystemC module
PCI bus
Carte mère de plateforme ARM Integrator
Pont
PCI/PCI
Figure 55 Co-émulation en utilisant un pont PCI/PCI
5.4.1.2.4
Connexion en utilisant une carte USB PCI
Une autre solution est d’utiliser une carte USB PCI (une carte USB insérée sur le
connecteur PCI) pour connecter la plateforme à l’environnement de simulation
(l’ordinateur).
101
Chapitre 5 : Analyse et perspectives
Carte du processeur
Carte du FPGA
JTAG
JTAG
Sous
module
SystemC
Processeur
Adaptateur
SystemC
Interface de
co-émulation
(carte USB)
FPGA
BUS AMBA
SystemC module
PCI bus
Carte mère de plateforme ARM Integrator
Carte USB
Figure 56 Co-émulation en utilisant une connexion USB
Pour réaliser cette co-émulation, on ne doit développer que le pilote de la carte USB
[BRO03] sur la plateforme. Ce pilote sera réalisé en logiciel et en matériel. Le pilote logiciel
est utilisé par le processeur, et le pilote matériel est utilisé par le FPGA. La vitesse maximum
de cette connexion et 6 Mbit/s.
C’est cette solution qui sera mise en œuvre pour des raison de simplicité et de
performances.
5.4.1.3 Cas d’étude avec l’application VDSL
Dans cet expérience, nous utilisons le même application avec la section précèdent :
VDSL avec le même architecture. Dans cette expérimentation, un seul des processeurs
s’exécute sur la plateforme ARM Integrator pendent que l’on simule les autres parties du
système dans un ordinateur en utilisant systemC. Dans la simulation systemC, la partie
émulée est représentée par un module systemC appelé Adaptateur SystemC. Ce module
communique avec le processeur sur la plateforme à travers une connexion USB. Afin
d’envoyer et de recevoir des données de la carte USB, cet adaptateur utilise des appels de
fonctions de pilote USB. La carte USB de l’ordinateur est reliée à la carte USB PCI, ellemême connectée sur la plateforme ARM Integrator. Pour envoyer et recevoir des données,
cette carte doit alors traverser le bus PCI, le pont de PCI/AMBA-AHB, et bus AHB. Avant
arriver au tâches de l’application, les données sont décodés/encodés par une couche d’E/S.
Cette couche initialise la connexion USB et gère les échanges de données entre le processeur
et la partie émulée. La Figure 57 illustre cette expérimentation.
102
Chapitre 5 : Analyse et perspectives
ARM integrator
Tâches
SE
Couche
E/S
Câble USB
Sous
module
SystemC
Adaptateur
SystemC
SystemC module
Interface de
co-émulation
(carte USB
& son pilot)
bus
PCI
Pont de
PCI
ARM7
“msg”
Carte
USB PCI
AMBA bus
Appel de fonction
(de pilot)
Figure 57 L’expérimentation sur co-émulation
Il existe deux types de communication entre la plateforme et la partie simulée :
o la partie émulé initie une communication avec la partie simulée
o la partie simulée initie une communication avec la partie émulée
Quand la partie émulée souhaite communiquer avec la partie simulée, c'est-à-dire,
quand le processeur veut envoyer ou prendre des donnés, il s’effectue les actions suivantes :
o Pour envoyer les données, le processeur formate les données (couche logicielle de
bas niveau), les écrits sur bus AMBA vers la carte USB/PCI. Ces informations
sont récupérées par le simulateur qui demande à la carte USB de générer une
interruption à l’attention du processeur pour acquitter de la réception. Pendant ce
temps, le processeur attend l’acquittement. Cette interruption ne fait pas partie de
l’application, seulement du protocole de communication entre le simulateur et
l’émulateur.
o Pour recevoir une donnée, le principe est le même, mais le simulateur envoie les
données et demande à la carte USB de générer une interruption. A la réception de
l’interruption, le processeur lit les donnés sur le bus AMBA.
Quand la partie simulée souhaite communiquer avec la partie émulée, il faut envoyer
une interruption au processeur émulé. Le traitement de cette interruption se fait par une
couche logicielle de bas niveau spécifique. On vérifie par exemple si l’interruption reçue est
103
Chapitre 5 : Analyse et perspectives
une interruption de l’application ou un acquittement. Si l’interruption est une interruption de
l’application, le processeur exécute le traitement de l’interruption issue de l’application.
5.4.1.4 Difficultés, résultats, et analyse
Dans cette expérimentation, on obtient une vitesse d’échange de données de 8 Kbits/s.
Cette vitesse dépend de l’application, plus précisément, de la taille des données envoyée.
Cette vitesse est beaucoup plus faible que la vitesse de connexion USB à cause de la latence
introduit par la couche E/S et l’interface de co-émulation. Malgré tout, le goulot
d’étranglement de cette co-émulation est sur la partie simulée.
En utilisant cette co-émulation, on peut vérifier plus facilement la partie matérielle
simulée sur l’ordinateur. Cette vérification est plus facile à faire que si l’on réalise la partie
matérielle avec un FPGA car tous les signaux de matériel simulé sont là. On n’a pas besoins
de sélectionner et de registrer quelques signaux avant l’exécution en utilisant analyseur
logique. De plus, on ne doit pas réaliser de circuit de déboguage pour observer des signaux à
l’intérieur de module.
5.4.2 Evaluation
La co-émulation combine plusieurs techniques de vérification pour avoir les avantages
de chaque technique. On peut considérer la co-émulation comme un prototypage avec
quelques composants simulés.
En co-émulation, il y a deux sujets à aborder : la communication et la synchronisation.
La communication est abordée dans la partie perspective qui suit ce paragraphe. En effet, de
part la nature de l’application et l’objectif de prototypage, une synchronisation par échanges
de données convenait parfaitement. Dans l’expérimentation de co-émulation, on explore
plusieurs solutions sur le sujet de communication. On trouve trois problèmes à résoudre sur
ce sujet : (1) définir la connexion physique entre le simulateur (ordinateur) et la plateforme,
(2) développer une couche logicielle entre le simulateur et la connexion physique (dans notre
exemple : adaptateur SystemC), et (3) définir une couche logicielle entre le logiciel exécuté
sur la plateforme et la connexion physique (dans notre exemple : la couche d’E/S).
La connexion physique choisie est une liaison USB. 2.0, pour une raison de simplicité
de mise en œuvre, un coût extrêmement réduit (achat une carte PCI/USB) et une bande
passante très supérieure à ce que peut fournir un simulateur. Dans la connexion USB, on a
104
Chapitre 5 : Analyse et perspectives
deux cotés différents : un hôte USB et un client USB (anglais : USB host et USB device). Le
coté hôte prendre le contrôle de la communication entre deux cartes USB. Dans l’expérience,
l’ordinateur s’agit comme coté hôte, et la plateforme agit comme la coté client. On utilise
alors une carte USB/PCI normale sur l’ordinateur, mais on utilise une carte PCI/USB Net
2280 de Netchip [NET03]. Cette carte est conçue pour le développement de client USB.
Cette carte alors peut être configurée comme un client USB (Une carte USB normale agit
toujours comme hôte). Cette configuration est prise pour faciliter le développement de
couches logicielles sur le simulateur (interface de co-émulation) et sur le processeur ARM.
La couche logicielle entre le simulateur et la connexion physique consistait à réécrire
des pilotes USB sous Linux en partant de pilotes existants et trouvés sur Internet [BRO03].
En utilisant ces pilotes, l’adaptateur SystemC configure la communication entre les deux
cartes USB et aussi envoie et reçoit des données codées (des messages). De plus, on peut
utiliser quelques fonctions fournies avec la carte USB Netchip utilisée pour le
développement.
Sur le processeur ARM, la couche E/S consiste de deux parties. La première partie est
le pilote de la connexion, et la deuxième est la partie qui effectue le codage et le décodage.
Le pilote de connexion configure la connexion entre processeur ARM et la carte USB.
Etablir la communication n’est pas très facile. D’abord, il faut configurer le pont
AMBA/PCI, et puis configurer la carte PCI/USB. On utilise une partie des pilotes existants
fournis avec la carte USB/PCI et un exemple de configuration de bus PCI. La deuxième
partie effectue le codage et le décodage de données. Il y deux types de communication. Le
première type est quand le processeur envoie ou reçoit des données. La deuxième type est
quand la partie simulée (le sous module systemC) envoie une interruption au processeur
ARM. Cette deuxième partie de couche E/S s’occupe les deux types de communication.
5.4.3 Perspectives
Pour aller plus loin sur la co-émulation, on peut avoir plusieurs techniques de
synchronisation entre la partie simulée et la plateforme : synchronisation basée sur des
événements discrets, synchronisation basée sur des délais annotés, synchronisation au cycle
près. La précision et la vitesse de la co-émulation dépendent de cette technique de
synchronisation.
105
Chapitre 5 : Analyse et perspectives
Dans la synchronisation basée sur des événements discrets, l’environnement de
simulation et la plateforme s’échangent les donnée seulement quand il y a des événements
tels que des interruptions ou écritures/lectures des données. On ne peut que vérifier la
fonctionnalité avec ce type de co-émulation, mais avec une vitesse élevée.
Dans la synchronisation basée sur des délais annotés, on utilise un délai prédéterminé
pour la synchronisation. Dans ce cas là, on doit fixer le délai avant l’exécution.
Dans la synchronisation au cycle près, les échanges des données sont effectués à
chaque cycle. Afin de les faire, le simulateur et la plateforme doivent s’exécuter cycle par
cycle. Cette co-émulation est très précise, mais aussi très lente.
106
Chapitre 6 : Conclusion
CHAPITRE 6 : CONCLUSION
La technologie microélectronique facilite l’intégration de nombreux composants sur
une même puce, ce qui permet d’atteindre les performances et de répondre aux besoins de
fonctionnalité exigés par les applications. La tendance dans la conception de tels systèmes,
appelés systèmes monopuces, est à l’augmentation de la complexité. On observe une très
grande hétérogénéité des composants, spécifiques pour certaines fonctionnalités, ou
programmables (processeur). La partie logicielle devient elle aussi très complexe et requière
une organisation sous forme de couches pour assurer la portabilité du programme de
l’application.
Les applications utilisant ces systèmes monopuces sont sur un marché très
concurrentiel, et l’arrivée rapide du produit sur le marché est très importante. Ceci entraîne
une énorme pression pour réduire le temps de conception et de validation. De plus, le coût lié
à la conception des parties matérielles et logicielles est très élevé. Et détecter une erreur après
fabrication entraîne un surcoût financier et de temps non acceptable.
Ceci nous entraîne vers les deux problèmes explorés dans ce travail de thèse : s’assurer
que la système est correct avant sa fabrication et accélérer le processus de conception.
Après d’avoir évalué plus ieurs techniques de vérification, nous pensons que le
prototypage sur une plateforme reconfigurable est une bonne solution pour résoudre les
problèmes mentionnés. Ce type de prototypage permet de vérifier rigoureusement les
systèmes grâce à la vitesse élevée, et de tester le système dans son environnement physique
d’utilisation. Il accélère aussi le processus de conception en permettent le développement de
certaines couches logicielles avant que le système soit près. Dans ce cas, le prototype est une
plateforme d’exécution pour le logiciel développé.
Pour obtenir rapidement un prototype à partir d’une description RTL d’une
application, nous proposons un flot de prototypage basé sur une plateforme reconfigurable et
composé de quatre étapes. Ces étapes sont : allocation, configuration de la plateforme,
adaptation de l’application, et génération du code.
107
Chapitre 6 : Conclusion
Dans l’allocation, les concepteurs associent chaque partie de l’architecture à un nœud
de prototypage de la plateforme. Ces associations indiquent sur quelles parties de la
plateforme reconfigurable sont réalisées les parties de l’architecture de l’application. La
configuration est la réorganisation de la plateforme reconfigurable. L’adaptation consiste à
modifier l’application pour satisfaire aux caractéristiq ues de la plateforme reconfigurable.
Cette étape est effectuée si la plateforme ne peut pas être configurée pour s’adapter aux
besoins de l’application. Enfin, la dernière étape est la génération du code . Cette étape
consiste en processus standard tels que la compilation et l’édition de lien des logiciels, la
synthèse logique, le placement sur FPGA, et le routage.
Ce flot est validé en réalisant le prototypage des applications VDSL et DivX. La
plateforme utilisée est une plateforme ARM Integrator avec une carte mère, quatre modules
processeurs ARM, et un module FPGA. La communication entre les modules se fait à travers
un bus AMBA AHB.
Le développement d’une application VDSL multiprocesseur avait pour objectif de
valider les interfaces logicielles/matérielles générées automatiquement par l’outil ROSES du
groupe SLS. Pour cette application, la configuration de la plateforme était nécessaire pour
contourner le problème du bus AMBA fixé par la plateforme. Une adaptation de
l’application était aussi nécessaire pour prendre en compte l’espace adressage de la
plateforme différent de celui du VDSL. L’adaptation ne concerne que la couche logicielle la
plus basse, dite couche d’abstraction du matériel. Ce prototype a été utilisé pour valider les
interfaces matérielles et le système d’exploitation.
Une application DivX est utilisée dans la deuxième expérience. L’architecture de
l’application consiste en quatre processeurs qui communiquent en utilisant un protocole MPI
réalisé en logiciel et en matériel. L’objectif de cette expérience est d’obtenir une plateforme
pour valider le logiciel de l’application. La difficulté du prototypage repose sur la différence
de réalisation du protocole MPI dans le système final et sur la plateforme. En effet,
l’architecture de la plateforme ne permet pas qu’une partie de ce mécanisme de
communication soit réalisé en matériel. Il faut donc le faire entièrement en logiciel, ce qui
doit être invisible du point de vue de l’application. Dans cette expérience, l’adaptation était
une partie critique et délicate, consistant à modifier la couche logicielle d’abstraction du
matériel. Cette expérience a permis de valider les tâches de l’application sur les processeurs.
108
Chapitre 6 : Conclusion
L’adaptation consiste donc principalement à modifier la couche logicielle d’abstraction
du matériel. Comme cette couche logicielle d’abstraction est obtenue automatiquement à
l’aide de l’outil ASOG développé dans le groupe SLS, il nous semblait possible
d’automatiser l’étape d’adaptation, en modifiant non pas la couche logicielle, mais l’entrée
de l’outil ASOG. Cet outil étant basé sur une bibliothèque de fonctions, il a été nécessaire de
développer de nombreux éléments.
En addition des deux expériences de prototypage, une expérience de co-émulation a été
faite pour explorer les difficultés et les avantages de cette technique. L’avantage principal
est qu’on peut profiter de l’observabilité de la simulation et de la vitesse de l’émulation. De
plus, la co-émulation permet de réaliser un prototype même si on n’a pas tous les
composants. Il y a deux problèmes techniques liés à la co-émulation : la communication et la
synchronisation entre la partie simulée et la partie émulée. Une solution matérielle et
logicielle est proposée dans cette thèse pour la partie communication. Mais la partie
synchronisation n’est pas abordée.
Ce travail de thèse montre que l’on peut obtenir rapidement un prototype en utilisant le
flot proposé sur une plateforme reconfigurable. Un tel prototype est très utile pour valider de
nombreux aspects de la conception : interfaces de communication, système d’exploitation,
partie matériel, logiciel de l’application, … . L’avantage d’une plateforme reconfigurable est
aussi de faciliter le développement des parties logicielles, donc accélérer la conception.
Ce travail n’est qu’un début d’exploration des possibilités offertes par le prototypage
pour valider les systèmes monopuces. Il reste de nombreux points à étudier ou à approfondir.
Concernant les plateformes de prototypage, le point faible semble être le manque de
configurabilité de la partie communication pour mettre en œuvre différents mécanismes et
protocoles de communication entre les nœuds de prototypage. Il faut aussi penser à intégrer
ce flot de prototypage dans le flot classique de conception de systèmes monopuces. En effet,
on constate que tous les flots de prototypage existants sont des flots séparés qui introduisent
une rupture dans la conception. A noter aussi que le prototypage requiert l’utilisation de
nombreux outils (chaîne de compilation, partitionnement, synthèse, placement routage) ce
qui ne facilite pas l’intégration.
La co-émulation semble être un début de réponse aux deux problèmes décrits
précédemment. La partie simulation d’un système co-émulé permet de modéliser des
109
Chapitre 6 : Conclusion
mécanismes de communication de complexes, et offre en plus une grande flexibilité sur le
modèle. Et cette partie simulation fait le lien avec le flot de conception classique ou la
simulation est la principale technique de vérification. On peut alors travailler de façon
incrémentale en déplaçant les composants de la simulation vers la plateforme en fonction de
l’avancement de la conception.
110
20/12/2004
Bibliographie
BIBLIOGRAPHIE
[ADA98]
Adaies K., Alexiou G.P., Kanopoulos N.,"An Extensible, Low Cost Rapid
Prototyping Environment based on a Reconfigurable Set of FPGA" 9th Rapid
System Prototyping (RSP), Leuven, 1998
[APT02]
Aptix Corp., “Prototype Studio: RTL to PSP Pre Silicon Prototypes for Systemon-chip
Designs”,
http://www.aptix.com/products/product_overview.htm.,
Aptix Corp., 2002
[ARM99a] ARM Limited, “AMBA Specification (Rev 2.0)”, ARM Limited, 1999
[ARM99b] ARM Ltd., “Integrator/AP User Guide”, ARM Limited, 1999
[ARM99c] ARM Limited, “Integrator/LM-XCV600E+ Integrator/LM-EP20K600E+ User
Guide”, ARM Limited, 1999
[ARM99d] ARM Limited,”Integrator/CM7TDMI User Guide”, ARM Limited, 1999
[ARM99e] ARM Limited, “ARM Developer Suite AXD and armsd Debuggers Guide”,
ARM Limited, 1999
[ARM99f]
ARM Limited, “Multi-ICE User Guide”, ARM Limited, 1999
[ARM02]
http://www.arm.com/armtech/primeXsys
[BRO03]
David Brownell, “Linux and USB 2.0”, http://linux-usb.org/usb3.html, 2003
[CAR98]
Cardelli S., Chiodo M., Giusto P., Jurecska A., Lavagno L., SangiovanniVincentelli A., “Rapid-Prototyping of Embedded System via Reprogrammable
Device”, dans DAES volume 3, pages : 149-161, Kluwer Academic Publisher,
1998
[CES01]
Cesario W., Nicolescu G., Gauthier L., Lyonnard D., “Colif: a Multi Design
Representation for Application-Specific Multiprocessor System-on-Chip
Design”, 12th Rapid System Prototyping (RSP), California, 2001
111
20/12/2004
[CES02]
Bibliographie
W. Cesário, A. Baghdadi, L. Gauthier, D. Lyonnard, G. Nicolescu, Y. Paviot,
S. Yoo, A. A. Jerraya, “Component-Based Design Approach for Multicore
SoCs”, Design Automation Conference (DAC), New Orleans, 2002
[CHA99]
Chang H., Cooke L., Hunt M, Martin G, McNelly A, Todd L., “Surviving the
SOC Revolution – A Guide to Plateforme-Based Design”, Kluwer Academic
Publisher, 1999
[CLO02]
Clouard A., Mastrorocco G., Carbognani F., Perrin A., Ghenassia F., “Toward
Bridging the Precision Gap between SoC Transactional and Cycle-Accurate
Levels”, Design automation and Test in Europe (DATE), Paris, 2002
[DAL00]
Mitchel
Dale,
“The
Value
of
the
Hardware
Emulation”,
http://www.mentor.com/emulation, Mentor Graphics, 2000
[DIV01]
Project Mayo, http://www.projectmayo.com, 2001
[DOR01]
Dorfel M., Hofmann R.,"A Prototyping System for High Performance
Communication System" ,12th Rapid System Prototyping (RSP), Leuven, 2001
[EVA03]
Evans Data Corporation, ”Embedded Systems Development Survey, Volume 1,
2003”,
http://www.evansdata.com/n2c/surveys/embedded_toc_03_2.shtml,
2003
[ROS98]
Wolfgang Rosentiel, “Rapid Prototyping, Emulation and Hw/Sw Codebugging”, une chapitre dans : A. A. Jerraya et J. Mermet, “System Level
Synthesis”, pages : 219-262, Kluwer Academic Publisher, 1998
[HAR97a] Hardt W., Rosentiel W., “Prototyping of Tightly Coupled Hardware/Software
System”, dans DAES volume 2, pages : 283-317, Kluwer Academic Publisher,
1997
[HAR97b] Hartenstein R.W., Becker J., Herz M., Nageldinger U., "An Innovative
Reconfigurable Platform for Embedded System Design" The Workshop
ZES’97, Rostock, 1997.
[GAU01]
Lovic Gauthier, “Génération de système d’exploitation pour le ciblage de
logiciel multitâche sur des architectures multiprocesseurs hétérogènes dans le
cadre des systèmes embarqués spécifiques“, Thèse de Doctorat INPG,
Spécialité Microélectronique, laboratoire TIMA, 2001
112
20/12/2004
[GHA03]
Bibliographie
Ferid Gharsalli, “Conception des interface logiciel- matériel pour l’intégration
des mémoires globales dans les systems monopoces”, Thèse de doctorat, INPG,
Spécialité Informatique, laboratoire TIMA, 2003
[GRA04]
Grasset A., Rousseau F., Jerraya A.A.
“Network Interface Generation for
MPSOC: from Communication Service Requirement ti RTL Implementation”,
15th Rapid System Prototyping (RSP), 2004
[GRA04]
Grasset A., Rousseau F., Jerraya A.A. “Network Interface Generation for
MPSOC: from Communication Service Requirement ti RTL Implementation”,
15th Rapid System Prototyping (RSP), 2004
[KUR02]
Kurshan R.P., Levin V., Minea M., Peled D., Yenigün H., “Combining
Software and Hardware Verification Techniques”, Kluwer Academic Pub lisher,
2002
[KOR01]
Kordon F., Munier I., Paviot-Adet E., Reged D.,“Formal Verification of
Embedded Distributed Systems in a Prototyping Approach”, dans Monterey
Workshop 2001 : on Engineering Automation for Software Intensive System
Integration, 2001.
[LYO03]
Damien
Lyonnard, “Approche
d’assemblage
d’interface pour la generation d’architectures
systématique
d’élément
multiprocesseurs”, Thèse de
doctorat, INPG, Spécialité Microélectronique, laboratoire TIMA, 2003
[MEN03]
Mentor Emulation Division, “Accelerated SoC Verification Solutions”
http://www.mentor.com/emulation, Mentor Graphics, 2003
[MES00]
Mestdagh D.J.G., Isakson M.R., Odling P., Zipper VDSL: A Solution for
Robust Duplex Communication over Telephone Lines, IEEE Communication
Magazine, pp. 90-96, mai ,2000
[MOS96]
Mosanya E., Goeke M., Linder J., Perrier J.Y., Rampogna F., Sanchez E.
"Platform for Codesign and cosynthesis based on FPGA", 12th Rapid System
Prototyping (RSP), Thessaloniki, 1996
[MPI95]
“The
Message
Passing
Interface
unix.mcs.anl.gov/mpi/, Version 1.1, 1995
113
(MPI)
standard”,
http://www-
20/12/2004
[NET03]
Bibliographie
NetChip Tehnology, Inc., “Getting started with Netchip’s NET2280 PCI-RDK
USB Host et USB Device Software”, NetChip Technology Inc., 2003
[NIC02]
Eugenia G. N. Nicolescu, “Spécification et validation des systèmes hétérogènes
embarqués” , Thèse de doctorat, INPG, Spécialité Microélectronique,
laboratoire TIMA, 2002
[PAV01]
Pavesi M., Gemelli R., Ferloni M., Deroux-Dauphin P., Bazillz B., Moreau JP., Moussa I, Sbarra G., Gesano A., Costo- loni A., Vacca P., “FlexBench™:
Design Flow of a Novel Platform for Rapid Prototyping”, Design Automation
and Test Europe, Munich, 2001
[PAV04]
Yanick Paviot, “Implémentations mixtes logicielles/matérielles des services de
communication pour l’exploration du partitionnement logiciel/matériel”, Thèse
de doctorat, INPG, Spécialité Microélectronique, laboratoire TIMA, 2004
[POLIS]
http://www-cad.eecs.berkeley.edu/~polis
[RAM01]
Ramanathan A., Teisser R., McLaughin D., "Acquisition of Sensing Data on a
Reconfigurable Platform", International Geosciences and Remote Sensing
Symposium, Sidney, 2001
[SAS03a]
Sasongko A, Baghdadi A., Rousseau F., Jerraya A.A., “Prototyping of
Embedded Applications to Configurable Platform Driven by Communication
Constraints”, 14th Rapid System Prototyping (RSP), San Diego, USA, 2003
[SAS03b]
Sasongko A., Baghdadi A., Rousseau F., Jerraya A.A., “Towards SoC
Validation through Prototyping: A Systematic Approach Based on
Configurable Platform”, dans DAES volume 8 numero 2/3, pages : 115-173,
Kluwer Academic Publisher, 2003
[SAS03c]
Sasongko A, Baghdadi A., Rousseau F., Jerraya A.A., “SoC Validation trough
Prototyping on Arm Integrator Platform”, in une journaux : “Information
Quarterly”, ARM, 2003
[SAS03d]
Sassatelli G, Torres L., Benoit P., Gil T., Robert M., Cambon G., Galy J.,
"Highly Scalable Dynamically Reconfiguable Ring-Architecture for DSP
Application" 5th edition Sophia Antipolis Forumon Microelectronics, Sophia
Antipolis, 2003.
114
20/12/2004
[SAW96]
Bibliographie
Sanjay Sawant, “RTL Emulation: The next Leap in System Verification”,
Design Automation Conference (DAC), Las Vegas, 1996
[STA94]
Jorgen Staunstrup,”A Formal Approach to Hardware Design”, Kluwer
Academic Publisher, 1994
[SYS99]
Synopsys Inc., SystemC disponible à http://www.systemc.org/
[WEB00a] John G. Webster, “Modeling and Simulation”, dans “Wiley Encyclopedia of
Electrical and Electronics Engineering”, volume 13, pages : 404-416, John
Wiley and Son, 1999
[WED00b] John G. Webster, “Emulator”, dans “Wiley Encyclopedia of Electrical and
Electronics Engineering”, volume 7, pages : 79-92, John Wiley and Son, 1999
[WEB00c] John G. Webster, “Design Verification and Fault Diagnosis in Manufacturing”,
dans “Wiley Encyclopedia of Electrical and Electronics Engineering” volume
5, pages : 221-233, John Wiley and Son, 1999
[WEB00d] John G. Webster, “Rapid Prototyping System”, dans “Wiley Encyclopedia of
Electrical and Electronics Engineering”, volume 18, pages : 234-241, John
Wiley and Son, 1999
[WINSY]
http://www.winsystems.com
[YOU04]
Youssef M. W., Yoo S., Sasongko A., Paviot Y., Jerraya A.A., “Debugging
HW/SW Interface for MPSoC: Video Encoder System Design Case Study”,
Design Automation Conference(DAC), San Diego, 2004
115
20/12/2004
Publications
PUBLICATIONS
1. SASONGKO A, BAGHDADI A., ROUSSEAU F., JERRAYA A. A., “Prototyping of
Embedded Applications to Configurable Platform Driven by Communication Constraints”,
dans “Proceeding of Workshop on Rapid System Prototyping”, San Diego, Etats-unis, 2003
2. SASONGKO A, BAGHDADI A., ROUSSEAU F., JERRAYA A. A., “Towards SoC
Validation through Prototyping: A Systematic Approach Based on Configurable Platform”,
dans une revue internationale, “Design Automation of Embedded System Vol. 8 No2/3”,
Kluwer Academics Publisher, 2003
3. SASONGKO A, BAGHDADI A., ROUSSEAU F., JERRAYA A. A., “SoC Validation
trough Prototyping on Arm Integrator Platform”, dans un journal, “Information Quarterly”,
ARM, 2003
4. YOUSSEF M. W., YOO S., SASONGKO A., PAVIOT Y., JERRAYA A. A., “Debugging
HW/SW Interface for MPSoC: Video Encoder System Design Case Study”, dans “The
proceeding of 41st Design Automation Conference”, San Diego, Etats-unis, 2004
117
RESUME
La technologie facilite l’intégration de nombreux composants sur une puce pour atteindre les performances et les besoins
exigés par les applications. La tendance est à l’augmentation de la complexité et de l’hétérogénéité de tels systèmes, appelés
systèmes monopuces.
Les systèmes monopuces sont sur un marché très concurrentiel, et l’arrivée rapide du produit sur le marché est très
importante. De plus, le coût lié à la conception des parties matérielles et logicielles est très élevé. Détecter une erreur après
fabrication entraîne un surcoût financier et de temps non acceptable. Ceci nous entraîne vers les deux problèmes traités dans
ce travail de thèse : s’assurer que la système est correct avant sa fabrication et accélérer le processus de conception.
Après avoir évalué plusieurs techniques de vérification, nous pensons que le prototypage sur une plateforme reconfigurable
est une solution adaptée pour les problèmes mentionnés. Ce prototypage permet de vérifier rigoureusement les systèmes
grâce à une vitesse élevée, et de tester le système dans son environnement d’utilisation. Il accélère aussi la conception en
permettent le développement de certaines couches logicielles avant que le système soit fini.
Pour obtenir rapidement un prototype à partir d’une description RTL d’une application, nous proposons un flot de
prototypage basé sur une plateforme reconfigurable. Ce flot est composé de quatre étapes : allocation, configuration de la
plateforme, adaptation de l’application, et génération du code.
Dans l’allocation, les concepteurs associent chaque partie de l’architecture à un nœud de prototypage de la plateforme. Ces
associations indiquent sur quelles parties de la plateforme reconfigurable sont réalisées les parties de l’architecture de
l’application. La configuration est la réorganisation de la plateforme reconfigurable. L’adaptation consiste à modifier
l’application pour satisfaire aux caractéristiques de la plateforme reconfigurable. Cette étape est effectuée si la plateforme ne
peut pas être configurée pour s’adapter aux besoins de l’application. Enfin, la génération du code est un processus standard
tel que la compilation et l’édition de lien des logiciels, la synthèse logique, le placement sur FPGA, et le routage.
Ce flot a été validé en réalisant le prototypage des applications VDSL et DivX. La plateforme utilisée est une plateforme
ARM Integrator avec une carte mère, quatre modules processeurs ARM, et d’un module FPGA communiquant à travers un
bus AMBA AHB. Une expérience de co-émulation a également été réalisée pour explorer les difficultés et les avantages de
cette technique. L’avantage principal est qu’on peut profiter de l’observabilité de la simulation et de la vitesse de l’émulation.
Ce travail de thèse montre que l’on peut obtenir rapidement un prototype en utilisant le flot propose sur une plateforme
reconfigurable et aussi faciliter le développement des parties logicielles pour accélérer la conception. La configurabilité de
plateforme de prototypage et l’intégration du flot de prototypage sur un flot de conception des systèmes restent des
problématiques à approfondir.
ABSTRACT
The technology facilitates integration of many components onto a single chip to achieve performances and requirements
needed by the application. The complexity and the heterogeneity of this system, called system-on-chip (SoC), tend to
increase.
The market of SoC is very competitive, so early appearance on the market is very important. Furthermore, the cost chip
fabrication is very high, therefore, detecting a bug after fabrication can cause unacceptable overhead. These facts bring us to
two problems addressed in this thesis: assuring the correctness of the system and accelerating the design process.
After evaluating several verification techniques, we conclude that prototyping based on reconfigurable platform is a solution
for the two problems mentioned. This prototyping allows us to verify rigorously the system since the speed which is very
high. It allows us also to test the system in his operating environment. Furthermore, prototyping accelerate the design process
by allowing development of several software layers before the chip fabrication.
To obtain quickly a prototype from RTL description of the application, we propose a prototyping flow based on
reconfigurable platform. This flow consists of four steps: assignment, configuration, adaptation, and code generation.
In the assignment step, the designer associates each part of the architecture to the prototyping node of the prototyping
platform. These associations indicate parts of the prototyping platform which will implement the components of the
application. Configuration is reorganization of the reconfigurable platform. Adaptation consists of modify the application
to satisfy constraints of the platform. This step is needed when the platform can not be configured to adapt the requirements
of the application. Finally, the code generation is standard process such as compilation, logic synthesis, and placement and
route.
This flow is validated by realizing two p rototypes of application: VDSL and DivX encoder. In these experiments, we used
ARM Integrator platform. This platform consists of a main board, four processor boards, an FPGA board. These boards
communicate each others through bus AMBA -AHB. A co-emulation experiment is also performed using this platform for
exploring the difficulties and the advantages of this technique. The main advantage is that we can obtain the observability of
simulation while preserving the speed of emulation.
This PhD work shows that we can obtain a prototype using the proposed flow on a reconfigurable platform and also facilitate
the development the software part to accelerate the design process. The configurability of the platform and the integration of
the prototyping flow with design flow of the SoC are left as subjects to be treated. ISBN 2-84813-054-7

1232613

1226089

1232643

1226618

1229840

1230714

1226624

1229143

1227202

1226623

1230603

1231443

1227222

1228687

1226622

1226641

1226648

1230338

1226617

1229262

1232679

1228902