Flot de conception de systèmes sur puces

Flot de conception de systèmes sur puces 

Un SOPC incorpore un ou plusieurs processeurs, de la mémoire sur puce et des blocs logiques qui représentent des accélérateurs matériels. L’approche de conception des systèmes embarqués hétérogène (logiciels/matériels), souvent appelée co-design, comporte des parties de conception matérielle et logicielle. La conception d’un SOPC combine alors des composants logiciels (SW) implémentés sur les processeurs de la plateforme et des composants matériels (HW) intégrés sur la partie logique. L’approche de développement SOPC sur FPGA présente deux avantages par rapport à l’approche SOC sur ASIC . En premier lieu, une plateforme SOPC présente un développement associé à un prototypage rapide de l’application embarquée. En deuxième lieu, dans une plateforme SOPC l’application dispose de ressources reconfigurables au cours de l’exécution de l’application.

La conception d’un système sur puce exige généralement un important travail de conception et une grande expertise pour fixer l’architecture adéquate (au niveau des deux cotés matériel et logiciel), choisir les interfaces et gérer les périphériques de la plateforme. La diversité au niveau des choix de la conception du système complet offre un large espace d’architectures à explorer par le concepteur. Plusieurs travaux ont été ainsi proposés pour fixer un flot de conception standard pour l’implémentation d’un SOPC qui supporte les nouveaux challenges de conceptions notamment la reconfiguration dynamique [3].

Plateforme d’implémentation reconfigurable de type FPGA

L’apparition des premiers circuits reconfigurables remonte aux années 1980 (le premier FPGA le XC2000 est introduit par Xilinx [5] en 1984) sous la forme de circuits logiques programmables simples. Les circuits les plus récents de type FPGA offrent une surface d’implémentation matérielle importante pouvant s’étendre sur des millions de portes logiques programmables et s’exécutant à des fréquences de fonctionnement pouvant atteindre les 420MHZ. Une plateforme FPGA est constituée d’un ensemble de blocs logiques qui peuvent être interconnectés par programmation pour réaliser des circuits différents. Un bloc logique dans ce cas peut être aussi simple qu’un transistor ou aussi complexe qu’un microprocesseur. L’interconnexion des blocs logiques est assurée par une architecture de routage selon laquelle les segments de raccordement sont positionnés pour permettre le câblage des différentes unités logiques. On distingue plusieurs architectures de FPGA proposées par un nombre de fabricants de composants tels que Actel [4], Xilinx [5] et Altera [6]. Les composants FPGA comportent de plus en plus de portes logiques, de composants (blocs mémoire, processeurs) tout en optimisant la fréquence de fonctionnement. A titre d’exemple, le composant VirtexII [7] de Xilinx comporte 8M de portes logiques et pouvant atteindre une fréquence de fonctionnement de 420MHz, des blocs de mémoire à porte double qui varient entre 4 et 168 blocs.

Flot de conception classique de SOPCs 

Un flot de conception d’un système sur puce regroupe plusieurs niveaux d’abstraction. Dans chaque niveau, le concepteur s’intéresse à la résolution d’un problème lié à la spécification de l’application, la définition de l’architecture ou à l’implémentation du design sur circuit spécifique. Les méthodologies de conception SOPC peuvent être divisées en trois familles : conception dirigée par les contraintes temporelles (TDD ), la conception basée sur des blocs fonctionnels (BBD ), la conception basée sur des plateformes déjà implémentées (PBD). La méthodologie TDD représente une méthodologie itérative d’optimisation de la performance du design. La méthodologie de conception BDD est la plus utilisée dans la littérature. Idéalement, en BBD la modélisation comportementale est réalisée au niveau système, où on effectue les compensations HW/SW et la Co-vérification fonctionnelle du système hétérogène en utilisant la simulation SW et/ou l’émulation du HW. Les nouveaux composants conçus sont alors partagés et implémentés sur les blocs fonctionnels RTL spécifiés. Ces composants doivent respecter les contraintes de performances, de puissance, et de surface. Comme la BBD, la méthodologie de conception PBD est une méthodologie de conception hiérarchique qui commence au niveau système. Là où la PBD diffère de la BBD est qu’elle atteint le maximum de sa productivité à travers une extension planifiée du concept de la réutilisation de composants.

Spécification haut niveau 

La spécification d’un système à implémenter au niveau fonctionnel fixe les fonctions principales et dérivées exigées par l’utilisateur. En spécifiant le système, le concepteur doit tenir compte des exigences de performances techniques (performance du traitement) et économiques (coût d’implémentation) du système sur puce à implémenter. L’objectif de l’étape de spécification est de fixer un modèle fonctionnel et de le tester tout en vérifiant les contraintes d’implémentation de l’application. La création d’un modèle fonctionnel s’intéresse à l’organisation ou la structuration du comportement de l’architecture au cours du temps. La spécification de l’application dépend des contraintes imposées par la plateforme d’implémentation.

Les concepteurs de systèmes embarqués disposent d’une large variété de modèles de spécification fonctionnelle tels que Statechart, les réseaux de pétri et UML (Unified Modeling Language). Ces modèles de spécification, qui sont capables de représenter les fonctionnalités d’un système, restent inadaptés pour exprimer les contraintes non fonctionnelles de l’application telles que les performances temporelles (durée, latence et débit) et les ressources d’implémentation nécessaires (énergie, mémoire et surface d’implémentation). La vérification de l’intégrité fonctionnelle de l’application nécessite l’utilisation d’un langage de description haut niveau associé à un noyau de simulation comme SystemC [12].

Partitionnement logiciel / matériel 

L’étape de partitionnement logiciel/matériel [13] détermine les tâches qui vont être implémentées sur un ou plusieurs processeurs et les tâches de traitement effectuées par des accélérateurs matériels. Durant cette étape de partitionnement, le concepteur fixe également les interfaces entre la partie HW et SW. L’étape de partitionnement est une étape déterminante dans le processus de conception d’un SOPC car elle fixe l’architecture finale du système ainsi que ses performances. Plusieurs algorithmes de partitionnement ont été proposés pour automatiser cette étape. Le défit majeur des activités de recherche est de proposer une méthodologie standard de conception SOPC conjointe, automatique et flexible. l’étape de partitionnement se base sur des estimations de performances de chaque partie du design. L’étape d’estimation déploie des blocs fonctionnels d’IPs complexes pouvant être réutilisés dans plusieurs designs. Ces blocs représentent des IPs matériels qui sont des implémentations physiques dépendant d’une technologie très optimisée et des IP logiciels décrits en langage de description haut niveau comme VHDL  ou SystemC souvent paramétrables et synthétisable. L’étape de partitionnement est effectuée généralement dans un environnement de développement de codesign, co simulation et co-vérification adapté.

L’étape de partitionnement automatique d’une spécification est un problème complexe (un problème NP-complet). Afin de décomposer ce problème, on peut subdiviser ce processus en trois parties principales :
♦ Une partie qui effectue l’allocation en fixant le type et le nombre nécessaire de ressources matérielles et logicielles. Dans le cas d’un processus d’allocation statique, le concepteur dimensionne à un niveau d’abstraction très haut l’architecture globale de l’application embarquée. Le concepteur fixe ainsi la limite de performance du design qui dépend des composants déployés dans l’architecture.
♦ Une partie qui effectue le partitionnement spatial ou temporel en affectant les tâches qui constituent l’application sur la partie matérielle ou logicielle. Cette partie se limite souvent à un problème de partitionnement spatial dans lequel on affecte les différentes tâches aux différents composants fonctionnels. Cependant, dans le cas des architectures reconfigurables, une nouvelle notion s’intercale : c’est la notion temps. Pour résoudre le problème de partitionnement dynamique, le concepteur doit effectuer un partitionnement temporel en agençant les tâches matérielles reconfigurables dans des segments temporels différents. Dans cette étape, le concepteur définit les délais d’occupation de chaque composant et favorise par la suite le principe de réutilisation des composants.
♦ Une partie qui effectue l’ordonnancement de l’exécution et de la reconfiguration des différentes tâches ainsi que la communication entre elles. A ce niveau, le concepteur doit explorer l’espace de solution afin de sélectionner une architecture qui respecte les contraintes de traitement temps réel imposées. La complexité de la tâche d’ordonnancement augmente en tenant compte de l’aspect de reconfiguration dynamique du design.

Table des matières

I. Introduction générale
II. Méthodologies Statique et Dynamique de Conception et Synthèse de Systèmes sur Puces Reconfigurables
II.1. Introduction
II.2. Flot de conception de systèmes sur puces
II.2.1. Plateforme d’implémentation reconfigurable de type FPGA
II.2.2. Flot de conception classique de SOPCs
II.2.2.1. Spécification haut niveau
II.2.2.2. Partitionnement logiciel / matériel
II.2.2.3. Synthèse de la partie matérielle
II.2.2.4. Partie software et processeurs embarqués
II.3. Systèmes sur puces reconfigurables dynamiquement
II.3.1. Evaluation d’une architecture reconfigurable
II.3.2. Caractérisation d’une architecture reconfigurable
II.3.2.1. La granularité des ressources de traitement
II.3.2.2. La communication processeur – accélérateur
II.3.2.3. La reconfigurabilité
II.3.2.4. L’organisation mémoire
II.3.3. Reconfiguration au niveau système
II.3.4. Reconfiguration au niveau fonctionnel
II.3.5. Reconfiguration au niveau portes logiques
II.4. Méthodologies statiques de partitionnement logiciel/matériel
II.4.1. Partitionnement manuel
II.4.2. L’algorithme de partitionnement GCLP
II.4.3. L’algorithme de partitionnement MAGELLAN
II.4.4. L’algorithme de partitionnement COSYN
II.5. Méthodologies statiques de synthèse d’architectures de systèmes sur puce
II.5.1. Construction de l’architecture
II.5.1.1. Ordonnancement
II.5.1.2. Affectation des ressources
II.5.2. Techniques d’exploration et d’évaluation
II.5.3. Objectif d’optimisation
II.6. Méthodologies dynamiques de synthèse de systèmes sur puce dynamiquement reconfigurables
II.6.1. Construction d’une architecture reconfigurable
II.6.2. Méthodologies de gestion des configurations de l’architecture
II.7. Limitations des méthodologies statiques/dynamiques de conception de systèmes sur puce
II.8. Conclusion
II.9. Références
III. Application Adaptative et Variabilité des Charges de Travail
III.1. Introduction
III.2. Domaine d’application
III.3. Aspects variables des charges de travail
III.3.1. Variabilité dirigée par la nature des données
III.3.2. Variabilité dirigée par l’environnement d’exécution du système
III.3.3. Variabilité dirigée par la diversité des applications
III.4. Origines de la variabilité des microarchitectures des processeurs embarqués
III.4.1. Mémoire cache
III.4.2. Branchement
III.4.3. Impact sur le CPI
III.5. Analyse de la variabilité des charges de travail
III.5.1. Détection et prédiction de phases
III.5.2. Analyse de la variabilité
III.6. Conclusion
III.7. Références
IV. Méthodologie d’implémentation de systèmes sur puce reconfigurables à base d’estimateurs de performances
IV.1. Introduction
IV.2. Décomposition multi résolutions et multi composants d’un SOPC reconfigurable
IV.2.1. Architecture d’un SOPC reconfigurable au niveau système
IV.2.2. Décomposition multi résolutions d’un SOPC
IV.3. Méthodologie de reconfiguration multi résolutions
IV.3.1. Analyse multi niveaux de la variabilité
IV.3.1.1. Variabilité au niveau application
IV.3.1.2. Variabilité au niveau des modules
a) Architecture et algorithme d’apprentissage
b) Implémentation et environnement de test
c) Analyse de variabilité
IV.3.1.3. Variabilité au niveau instruction
a) Extraction des traces d’instructions
b) Caractéristiques des traces d’instructions
IV.3.2. Flot de conception dynamique de systèmes sur puce reconfigurables
IV.4. Techniques de prédiction
IV.4.1. Techniques de prédiction statistiques
IV.4.2. Techniques de prédiction à base de réseaux de neurones
IV.4.2.1. Réseaux de neurones et algorithme d’apprentissage
IV.4.2.2. Application des réseaux de neurones à la prédiction des séries temporelles
IV.4.3. Prétraitement
IV.5. Conclusion
IV.6. Références
V. Conclusion générale

Télécharger le rapport complet