Soutenance mémoire
Modélisation d’un système intégré sur puce
Les applications multimédia (télévision numérique, DVD, …) ou les applications orientées télécommunications (processeurs réseau, terminaux mobiles) sont implantées sur des architectures matérielles, intégrant à l’intérieur d’une même puce, du logiciel qui s’exécute sur un ou plusieurs processeurs et un petit nombre d’accélérateurs matériels. La modélisation d’un système intégré sur puce nécessite la modélisation de l’architecture matérielle et la description de l’application logicielle puis le déploiement du logiciel sur ce matériel. Les sections suivantes illustrent ces différentes étapes en s’appuyant sur l’exemple d’une application de décompression Motion JPEG (MJPEG).
Spécification de l’application logicielle
Pour exploiter le parallélisme gros grain des applications logicielles, les applications sont souvent décrites sous la forme d’un graphe de tâches (processus ou threads). Les tâches communiquent entre elles par des canaux de communication point à point. Les noeuds du graphe représentent les tâches. Les arcs représentent les canaux de communication. Le modèle théorique est celui des réseaux de processus de Kahn [Kah74]. Les applications sont généralement spécifiées entièrement sous forme logicielle pour pouvoir être directement exécutées et validées sur une station de travail. Le langage C/C++ est couramment utilisé pour la spécification. La figure 1.1 présente une application de décompression d’un flux d’images MJPEG. La tâche Traffic Generator fournit l’image dont les informations, contenues dans l’entête, sont lues par la tâche Demux. La tâche Variable Length Decoder (VLD) effectue un décodage d’Huffman. La tâche Inverse Quantification (IQ) multiplie les données par un quantum puis la tâche ZigZag (ZZ) change l’ordre des données. La tâche Inverse Discrete Cosine Transform (IDCT) calcule la transformation inverse permettant de reconstruire un bloc de l’image. Enfin, la tâche LineBuilder construit les lignes d’image. La tâche Display affiche l’image résultant de la décompression.
Modélisation de l’architecture matérielle
L’architecture matérielle est typiquement multiprocesseur, comportant plusieurs bancs mémoire, un ou plusieurs coprocesseurs spécialisés, organisés autour d’un micro réseau d’interconnexions ou d’un bus.
L’architecture est représentée sous la forme d’un schéma dans lequel les composants matériels sont connectés par un signal ou bien par une nappe de signaux. Les modèles de composants matériels sont appelés modules. Chaque module est décrit à l’aide d’un langage de description de matériel tels que Very High Speed Integrated Circuits Hardware Description Language (VHDL), Verilog, ou SystemC.
Déploiement du logiciel sur l’architecture matérielle
Les tâches peuvent être implantées soit en matériel, soit en logiciel. Le déploiement consiste à définir le placement des tâches logicielles sur les processeurs programmables et/ou sur les accélérateurs matériels. L’exemple, figure 1.3, décrit un déploiement possible de l’application de décompression MJPEG sur une architecture matérielle multiprocesseur. Les tâches logicielles DEMUX, VLD, IQ, ZZ, et LineBuilder sont déployées sur des processeurs programmables. Les tâches Traffic Generator et Display qui correspondent aux entrées et sorties du flux vidéo sont implantées sur des composants matériels. De plus, la tâche IDCT qui est très gourmande en temps de calcul, est implantée sur un accélérateur matériel. Le résultat du déploiement est une solution au problème de placement des tâches logicielles sur une architecture matérielle. La recherche de solutions de déploiement s’appelle l’exploration architecturale.
Exploration Architecturale
L’exploration architecturale consiste à chercher la meilleure solution de déploiement d’une application logicielle sur une architecture matérielle paramétrable. Les principaux critères d’optimisation sont :
• la surface de silicium occupée ;
• la consommation d’énergie du système intégré ;
• les performances en nombre de cycles.
L’architecture matérielle possède de nombreux paramètres tels que le nombre et la puissance des processeurs programmables, la capacité et la stratégie des caches, la latence et le débit des canaux de communication, le type de composant d’interconnexion, etc. En raison du grand nombre de paramètres de l’architecture matérielle et des choix dans le déploiement du logiciel sur l’architecture, l’espace des solutions est gigantesque. L’exploration architecturale est un problème d’optimisation NP-difficile. Ce problème est généralement résolu manuellement par le concepteur. Celui-ci évalue et compare la qualité de l’architecture pour un nombre restreint de solutions. Le concepteur obtient ainsi une bonne solution de déploiement mais il n’a toutefois pas la garantie que cette solution soit la meilleure. Une des principales méthodes pour évaluer la surface, la consommation, et les performances d’une solution est la simulation architecturale. Le travail d’optimisation se déroule en plusieurs passes au cours desquelles le concepteur simule, observe puis ajuste l’architecture.
Simulation architecturale
La simulation architecturale est la fonction de coût de l’exploration architecturale. La simulation de systèmes intégrés sur puce est de type temps discret. Autrement dit, l’algorithme calcule, de manière itérative, l’état du système pour chaque unité de temps. L’accroissement de la taille et de la complexité des systèmes intégrés sur puce implique des temps de simulation très importants pouvant atteindre plusieurs jours de calculs. L’exploration architecturale s’en trouve alors très ralentie. L’objectif de cette thèse est d’accélérer l’exploration architecturale pour converger plus rapidement vers un bon choix d’architecture. Pour cela, nous souhaitons réduire les temps de simulation. La durée de la simulation dépend principalement de la vitesse d’exécution des modèles, ainsi que du moteur de simulation. Les sections suivantes traitent du choix du niveau d’abstraction des modèles matériels puis du moteur du simulateur pour la simulation rapide.
Niveaux d’abstraction des modèles matériels avec représentation du temps
Nous pouvons distinguer quatre principaux niveaux d’abstraction pour la modélisation de composants matériels :
• le niveau porte ;
• le niveau Register Transfer Level (RTL);
• le niveau Cycle Accurate, Bit Accurate (CABA);
• le niveau Transaction Level Modeling with Time (TLM-T).
Chacun des niveaux de modélisation offre un compromis que nous présentons dans les sections suivantes.
Niveau porte
Un composant matériel est décrit comme une interconnexion de portes logiques caractérisées pour un procédé de fabrication choisi. Pour chaque type de porte, la surface de silicium occupée, les capacités, et les temps de propagation du courant électrique sont connus. La simulation à partir d’une telle description est lente. La modélisation au niveau porte permet d’obtenir des informations telle que la fréquence d’horloge du circuit par exemple.
Niveau RTL
L’horloge et les registres de l’architecture sont identifiés. Les modèles au niveau RTL décrivent le comportement en termes de transferts entre registres. La simulation de composants à ce niveau est plus rapide que celle des composants au niveau porte. De plus, ce type de modèle est en règle générale synthétisable : les outils de synthèse logique sont capables de convertir un modèle de niveau RTL vers le niveau porte.
Niveau CABA
Les modèles au niveau CABA sont précis au bit et au cycle près sur les interfaces. Un tel composant peut être vu comme une boite noire. Ces modèles ne sont pas directement synthétisables. La simulation au niveau CABA est plus rapide qu’au niveau RTL.
Niveau TLM-T
Les communications entre les modules matériels sont modélisées sous forme de transactions datées. La simulation au niveau TLM-T est la plus rapide à l’heure actuelle. La fonctionnalité de l’architecture est fidèlement modélisée mais la précision en nombre de cycles n’est pas garantie.
|
Table des matières
1 Problématique
1.1 Modélisation d’un système intégré sur puce
1.2 Exploration Architecturale
1.3 Simulation architecturale
1.4 Conclusions
2 Modélisation CABA
2.1 État de l’art
2.2 Modèle d’architecture en CFSM
2.3 Représentation en SystemC
2.4 Conclusions
3 Ordonnancement statique
3.1 État de l’art
3.2 Hypothèses de modélisation des modules
3.3 Construction de l’ordre d’exécution des processus
3.4 Résultats expérimentaux
3.5 Conclusions
4 Génération de modèle en CFSM
4.1 État de l’art
4.2 Principe de la méthode proposée
4.3 Techniques utilisées par VASY
4.4 Construction d’un automate et génération
4.5 Résultats expérimentaux
4.6 Conclusions
5 Vérification sémantique
5.1 Approche dynamique
5.2 Principe de la vérification sémantique
5.3 Construction de l’arbre de syntaxe abstraite
5.4 Construction du support des variables
5.5 Identification des constantes architecturales
5.6 Vérification des contraintes de modélisation
5.7 Mise en œuvre
5.8 Résultats expérimentaux
5.9 Conclusions
6 Conclusions
Télécharger le rapport complet
