Soutenance mémoire
Conception de systèmes logiciels et matériels
La conjonction des contraintes du marché des systèmes électroniques et de l’évolution des technologies de fabrication des circuits intégrés nous amène aujourd’hui à concevoir des circuits de plus en plus complexes (3,9 milliards de transistors dans la même puce FPGA : l’Altera Stratix R V [Alt11]), dans un délai toujours plus court (time to market de quelques mois). C’est le problème actuel du concepteur de système : repenser le processus de conception allant de l’idée au produit. Composés initialement de quelques milliers de portes électroniques, les circuits sont maintenant des systèmes complexes structurés et intégrés sur une seule et même puce électronique. Chacune peut contenir un système complet avec un très grand nombre de processeurs, des mémoires, des périphériques évolués de technologies hétérogènes, plusieurs bus de communication jusqu’au « réseau sur puce » pour répondre à des contraintes de performance, de coût et de consommation électrique de plus en plus fortes. Les outils de conception ont évolué pour automatiser au maximum la conception des puces et de leurs masques de gravure. Le principe de la conception de tels systèmes (sur une seule puce ou non) commence généralement par la spécification de haut niveau pour aller vers leur réalisation physique. Malgré cela, ces puces ne sont pas encore assez puissantes en regard de la complexité et de la puissance de calcul nécessaires aux applications envisagées dans de nombreux projets de recherche [Sys]. Cette complexité est telle qu’aujourd’hui on parle même de systèmes de systèmes [Jam05], pour décrire un ensemble de systèmes en interaction mais surtout de conceptions hétérogènes, la dernière évolution étant la possibilité de reconfigurer dynamiquement des parties matérielles. En ouvrant des possibilités nouvelles, cette combinaison de dynamicité logicielle et de flexibilité matérielle engendre encore plus de possibilités de comportements difficilement prédictibles voire aléatoires dans de tels systèmes. Nous allons voir qu’il est nécessaire aujourd’hui, devant de tels comportements aléatoires, de vérifier le fonctionnement dès la phase de conception, et pour cela d’élaborer de nouveaux outils/méthodes/méthodologies le permettant. Outre les enjeux humains, les enjeux économiques de cette garantie de fonctionnement sont à la hauteur des sommes colossales risquant d’être perdues pour un masque de circuit inutilisable ou mal conçu. Non seulement les outils de conception actuels imposent une vérification fonctionnelle après coup, obligeant à réitérer le processus de conception, mais de plus ils permettent difficilement l’intégration de nouveaux composants matériels flexibles ainsi que la partie logicielle, pour évaluer ces aspects dynamiques. Intégrer à la fois des parties logicielles s’exécutant sur des processeurs, mais aussi d’autres parties matérielles, implémentées à l’aide de logique reconfigurable dynamiquement, oblige à repenser la validation de ces systèmes dès leur conception. Le processus de conception dans ce contexte ne peut se contenter d’une exploration au niveau matériel mais doit s’effectuer au niveau du système.
Évaluer le comportement de la solution par simulation
Le comportement des applications portées sur une plateforme sur puce multi-processeur varie grandement selon l’OS utilisé. En effet, les paramètres d’ordonnancement et les services diffèrent selon les OS, ce qui peut changer le comportement final d’une application. Les services fournis par un OS sont de plusieurs ordres :
– Abstraire le matériel et ses spécificités : fournir une interface simplifiée pour garantir une utilisation unifiée et cohérente de nœuds d’exécution matériels hétérogènes (gestion des interruptions, de la mémoire et des périphériques).
– Gérer le matériel : allouer intelligemment des ressources comme la mémoire, les périphériques, et surtout l’accès au processeur comme ressource de calcul en simulant de multiples flux d’exécution (time sharing impliquant donc l’ordonnancement de processus) lorsque le processeur ne sait exécuter qu’une instruction à la fois (ou un nombre trop limité par rapport au nombre de flux).
– Fournir un modèle de programmation (niveau logique) : fournir et garantir des fonctionnalités de communication et synchronisation, ainsi que la sécurité. Les OS peuvent être évalués succinctement en regardant leurs caractéristiques :
– préemptif ou non,
– politique d’ordonnancement (liste non exhaustive : Priority Based, Earliest Deadline First, Round Robin, MEDF),
– redéclenchement de l’ordonnanceur selon les services (bloquants ou non),
– latence de l’ordonnanceur, scalabilité et complexité algorithmique de son implémentation,
– latence du traitement des interruptions,
– comportement multi-processeur : répartition de charge avec possiblité de mettre en veille un processeur et donc de de migrer des tâches, . . .
Les OS eCos [ocb] et Linux [oca], pour ne citer qu’eux, divergent dans leurs fonctionnements et leurs temps de réponse pour certains services identiques. Dans l’étude de Lubbers [LP08], les simples services de lock et unlock de mutex 7 prennent jusqu’à dix fois plus de temps sous Linux que sous eCos sur PowerPC. De plus, les OS utilisés sont en constante évolution, et rien ne garantit que la version n + 1 aura le même ordonnanceur ou se comportera de la même manière sur la nouvelle architecture support. Mais les caractéristiques de l’OS ne sont pas les seuls facteurs de performances. Selon les systèmes (les processeurs modernes ont déjà des systèmes complexes intégrant en leur sein de nombreuses fonctionnalités autrefois externes), une partie des services d’OS a été déportée au niveau matériel (MMU , DMA , contrôleur d’interruption, mode superviseur, etc.), ce qui facilite grandement le travail de l’OS et améliore les performances globales. Certains services de partage de ressources, assez contraignants lorsqu’on utilise la virtualisation (hyperviseur), commencent à être intégrés à même le processeur (cas d’instructions dédiées pour les systèmes « virtualisés » [UNR+05]). Tous ces facteurs de variation de performances montrent qu’il devient nécessaire d’intégrer les caractéristiques du système d’exploitation au plus tôt dans le flot de développement global d’un SoC, afin de décider du choix des services, et de leur implémentation potentiellement câblée au sein du processeur ou de la puce.
Explorer les services d’exploitation de plateforme pour concevoir les MPSoC
Dans la mesure où les systèmes-sur-puce intègrent aujourd’hui plusieurs cœurs de processeurs, mais aussi de nombreux nœuds d’exécution/accélérateurs spécifiques, la gestion cohérente du système devra être assurée par un système d’exploitation distribué. La distribution multi processeurs et l’hétérogénéité des systèmes périphériques augmentent les besoins de services de communication, de synchronisation et de cohérence des données. Avec la distribution des tâches sur de multiples nœuds d’exécution, on voit (ré)apparaître des besoins comme la synchronisation entre tâches réparties sur des multicores, le partage de ressources mémoire (cache mémoire de niveau 3 commun sur les Dual Core c d’Intel, ou cache avec cohérence sur les MP-core CortexA9), ou encore les problèmes de répartition de charges qui peuvent évoluer dynamiquement. Les problèmes de communication et de synchronisation deviennent même centraux, du fait que nombre de plateformes MPSoC sont constituées de multiples processeurs et accélérateurs hétérogènes ( processeurs différents et zones reconfigurables). De surcroît il n’existe pas de standard pour la gestion des interactions entre les tâches logicielles et les accélérateurs câblés de fonctions de calcul dédié. Les puces comprenant des centaines de processeurs sont déjà à l’étude (le processeur TILE−Gx de Tilera comporte 100 cœurs de processeur[Til09]), et la gestion des ces multicores n’est pas évidente. La capacité des OS actuels à être déployés sur un aussi grand nombre de cœurs n’est pas triviale, ni certaine, car généralement on utilise un OS maître qui gère les autres. Or à cette échelle la centralisation de certains services n’est plus possible, car cela crèe un goulet d’étranglement. Afin de concevoir les nouveaux services d’OS spécifiques à la gestion de la distribution des tâches et afin de gérer la répartition des services, il est nécessaire d’intégrer le ou les OS tôt dans le flot de conception. L’idéal serait de les simuler et ainsi permettre de tester leur distribution aisément sur un grand nombre d’unités de calcul, pour des architectures encore inexistantes.
Historique de l’évolution des systèmes électroniques
Le développement architectural des systèmes électroniques suit selon Makimoto [Mak00] des cycles, comme indiqué sur cette représentation en figure 2.2. La dernière vague technologique annoncée par Makimoto est celle des systèmes reconfigurables. On peut noter Tredennick [Tre95] décrit l’évolution de la micro-électronique au premier stade comme étant à ressource et algorithme fixes, puis l’apparition des processeurs avec la partie algorithmique variable (paradigme Von Neumann) et enfin l’actuelle évolution des ressources maintenant variables en plus de l’algorithmique grâce à la reconfiguration matérielle. Tredennick rejoint Makimoto dans cette remise en cause du paradigme de programmation classique Von Neumann, en ce sens que les systèmes configurables sont basés sur les flux de données et n’ont plus besoin d’instructions. Ce changement de paradigme est même approfondi dans les travaux de Becker et Hartenstein [Har01, BH03] qui introduisent les termes de Configware et Morphware pour le décrire. Cela nous amène à présenter une certaine classification des systèmes embarqués, qui correspond plus ou moins aussi aux générations successives de systèmes matériels embarqués, du fait de l’évolution conjointe des technologies et des besoins applicatifs, qui vont du simple système aux many-cores reconfigurables.
L’intégration dans une même puce : les systèmes-sur-puce
La loi de Moore stipulant le doublement du nombre des transistors par puce tous les 18 mois s’étant révélée valable empiriquement, on peut aujourd’hui fondre sur la même puce l’ensemble des composants d’une carte (cf. Figure 2.4(b)). Ainsi il est techniquement possible d’intégrer toutes les fonctions (ou presque) d’un système embarqué, hormis quelques composants analogiques comme les cristaux de quartz générant les horloges. Les technologies ont même tellement évolué que des composants périphériques analogiques (des antennes, des capteurs de position, de températures etc.) voire mécaniques (MEMs) ou opto-électronique peuvent être intégrés dans le silicium. On parle alors de systèmes hétérogènes au sens de l’intégration dans la même puce des composants numériques et non numériques (analogiques, mécaniques, …). Les technologies de gravures ou le type de substrat silicium étant assez différentes, certains fabricants conçoivent maintenant les puces par empilement de puces de différentes technologies interconnectées dans le même boîtier, technique nommée SiP (System in Package). Nous ne nous intéresserons pour notre part qu’à la partie numérique. Partie matérielle des SoC La demande en puissance de calcul et en flexibilité a amené à concevoir des systèmes comportant de plus en plus de processeurs. On peut qualifier ces architectures de multi maîtres/multi esclaves, car la centralisation de la gestion ne peut plus être supportée par un seul processeur principal. La complexité de tels systèmes fait que l’on ne recommence pas à zéro le développement de chaque nouveau système sur puce, mais que l’on procède plutôt par assemblage de composants déjà créés et testés. On regroupe généralement sous le terme de propriété intellectuelle ou IP2 ces blocs fonctionnels ainsi assemblés. Cela peut être un simple processeur comme une fonction câblée d’accélération d’un algorithme particulier, comme un codeur/décodeur de fichier MP3, un bloc de cryptage/décryptage de données transmises,ou une transformée de Fourrier inverse. La puissance de calcul étant répartie sur de nombreux processeurs, elle suffit généralement aux besoins des applications. En revanche, le goulet d’étranglement se situe maintenant au niveau des communications mémoire. Ces communications sont les facteurs qui décident souvent de l’architecture envisagée. De nombreuses formes d’architecture de communication sur puce (multi-bus, barres connectées, réseau de communication) sont développées pour améliorer les capacités des circuits. Le principal défi est d’interfacer les IP en fonction des protocoles d’échanges désirés, selon le ou les bus ou réseaux sur puce (NoC 3) utilisés et ceux des IP. En général on doit rajouter des transacteurs (wrapper) entre les différents protocoles des bus et ceux particuliers des IP, comme on le fait avec des ponts entre bus distincts. L’architecture des calculateurs et processeurs doit être définie en fonction des besoins spécifiques de chaque partie de l’application et l’évaluation de la configuration optimale peut être fastidieuse. Par ailleurs, l’architecture mémoire joue un rôle déterminant dans les charges de transfert de données entre les processeurs, les mémoires, et les périphériques ; il faut décider leur localisation en fonction de leur partage ou non par un ensemble de processeurs. On utilise par exemple de plus en plus souvent des mémoires double port, capables d’être lues ou écrites par deux processeurs simultanément, ainsi que des blocs DMA 4 permettant de décharger les processeurs des transferts de données, en leur indiquant uniquement la fin de ces derniers par interruption.Partie logicielle des SoC La part du logiciel dans ces architectures est de plus en plus importante, car il apporte de la flexibilité aux plateformes, et bien évidemment participe à la gestion des ressources distribuées. De plus il devient nécessaire d’utiliser des systèmes d’exploitation afin de masquer la complexité du système au programmeur. Cette complexité est ainsi reportée au développement des couches support que sont l’OS et ses pilotes de périphériques. Les OS sont alors déclinés selon les besoins en un ou plusieurs OS coopérant entre eux. Cette dernière solution est la plus répandue du fait de l’hétérogénéité des processeurs présents dans le même design mais elle est plus complexe à mettre en œuvre, si on veut utiliser leurs pleines capacités spécifiques. La répartition des tâches logicielles entre les différents processeurs et son adaptation continue pendant l’exécution devient aussi un problème complexe, que les OS commencent à prendre en charge. Pour des raisons d’efficacité ou de consommation électrique, on peut vouloir migrer une tâche d’un processeur à un autre, afin de changer la configuration de la charge par processeur et éventuellement mettre les cœurs inutilisés en veille.
|
Table des matières
1 Problématique de la conception de systèmes sur puce
1.1 Conception de systèmes logiciels et matériels
1.2 Contexte et enjeux des systèmes sur puce multi-processeurs hétérogènes
1.3 Comment faciliter l’exploration architecturale d’un système ?
1.3.1 Évaluer le comportement de la solution par simulation
1.3.2 Explorer les services d’exploitation de plateforme pour concevoir les MPSoC
1.4 Exploration architecturale par co-simulation logicielle/matérielle
2 État de l’art
2.1 Introduction
2.2 Étude des systèmes temps-réel embarqués
2.2.1 Historique de l’évolution des systèmes électroniques
2.2.1.1 Les systèmes embarqués simples
2.2.1.2 Les systèmes embarqués distribués
2.2.1.3 L’intégration dans une même puce : les systèmes-sur-puce
2.2.1.4 La génération actuelle : la flexibilité
2.2.2 Modèle conceptuel simple actuel
2.2.2.1 Influence de la représentation sur la création
2.2.2.2 Modularité pour répondre aux contraintes de flexibilité
2.2.3 Conception et exploration conjointe de MPSoC
2.2.3.1 Cycle classique de conception
2.2.3.2 Autres méthodes/flots de conception
2.3 Modélisation des solutions à base de calculateurs
2.3.1 Les modèles de calcul parallèle
2.3.1.1 Modèles de calcul
2.3.1.2 Modèles de calcul classiques
2.4 Méthodes d’exploration et validation
2.4.1 Modélisation hétérogène et niveau de précision
2.4.2 Langages de design matériel et système
2.4.2.1 SystemC et la librairie TLM
2.4.2.2 Autres langages de design matériel et système
2.5 Les simulateurs et modèles conjoints pour l’évaluation de systèmes
2.5.1 Les frameworks de co-simulation intégrés
2.5.2 Simulation de système d’exploitation
2.5.2.1 Techniques de validation de logiciel embarqué
2.5.2.2 Modélisation conjointe d’architecture et OS à haut niveau
2.5.2.3 Gestion de la reconfiguration
2.6 Synthèse
3 Modélisation de systèmes embarqués basée sur l’OS
3.1 Introduction
3.2 Définition du modèle de système basé sur les services d’OS
3.2.1 Choix de conception pour l’exploration architecturale du système
3.2.2 Caractéristiques nécessaires pour l’exploration
3.2.2.1 Support de l’exploration des services : la modularité
3.2.2.2 Support au MPSoC et la distribution des services
3.2.2.3 Support de la reconfiguration matérielle
3.2.2.4 Raffinement de l’OS
3.2.3 Le principe de séparation des préoccupations
3.2.4 Niveau d’abstraction et modélisation Service Accurate + Time (SAT)
3.2.5 Support de la simulation
3.3 Construction du modèle d’OS
3.3.1 Modélisation en SystemC de logiciel multi-tâches
3.3.2 Gestion du temps garantissant un fil d’exécution unique
3.3.2.1 Modélisation des tâches et du temps avec les Blocs de Base (BB)
3.3.2.2 Gestion de la non concurrence, fil d’exécution unique
3.3.2.3 Modélisation des interruptions et préemption
3.3.3 Gestion des fils d’exécution
3.3.3.1 Création dynamique de tâches
3.4 Modularité et interactions entre services
3.4.1 Découpage en services
3.4.1.1 Service core ou de simulation
3.4.1.2 Service d’ordonnancement
3.4.1.3 Service de gestion des tâches
3.4.1.4 Service IRQ
3.4.1.5 Service de gestion du temps
3.4.1.6 Service de synchronisation
3.4.2 Gestion de concurrence de certains services
3.4.3 Gestion de multiples flux, le multithreading et les tâches matérielles
3.4.4 Interactions entre services
3.5 Instrumentation et exploration simple du modèle pour son évaluation
3.5.1 Instrumentation du modèle
3.5.2 Simulation comportementale
3.5.3 Exploration comportementale d’un service de synchronisation
3.6 Validation du modèle sur un cas concret de vision robotique
3.6.1 Une application robotique de perception et de navigation visuelle
3.6.1.1 L’application de détection d’amer d’une vidéo en temps-réel
3.6.1.2 Description de l’application logicielle
3.6.2 Un RTOS dédié comme solution d’implémentation spécifique au domaine
3.6.3 Intégration de l’application dans le modèle simple non temporel
3.6.4 Rétroannotation de l’application et du modèle
3.6.5 Validation du modèle rétroannoté par rapport à la mesure réelle
3.7 Conclusion du chapitre
4 Modélisation de distribution de services pour MPSoC
4.1 OS distribués et services distribués, définition
4.2 Multi-OS hétérogènes indépendants
4.2.1 Gestion du mapping
4.2.1.1 Contexte d’exécution de tâches
4.2.1.2 Localisation dynamique des appels système : get_OS
4.2.1.3 Localité des SC_THREADs créés
4.2.2 Multi OS hétérogènes indépendants
4.3 Service partagé et connexion de services distants
4.3.1 Modélisation des communications dans les systèmes distribués
4.3.2 Modélisation de services distants partagés
4.3.3 Exemple de services partagés : la synchronisation
4.4 Communications Génériques
4.4.1 Utilisation de TLM
4.4.2 Utilisation du Calling Abstraction Service (CAS) interne
4.4.2.1 Schéma simplifié du modèle d’OS distribué et du CAS
4.4.3 Connexion générique : le CAS de haut niveau
4.4.4 Raffinement du CAS externe
4.5 Exploration d’architecture MPSoC
4.5.1 Distribution et exploration matérielle d’un service de synchronisation partagé
4.5.2 Modélisation et distribution d’une application de vision robotique
4.5.3 Exploration de son architecture logicielle
4.5.4 Exploration avec un mapping matériel
4.5.5 Évaluation du surcoût de simulation du modèle d’OS
4.6 Conclusion du chapitre
5 Intégration et validation du modèle dans deux projets de collaboration
5.1 Introduction
5.2 Travaux dans le projet OveRSoC
5.2.1 Objectifs du projet OveRSoC
5.2.2 Méthodologie OveRSoC de conception et d’exploration globale
5.2.2.1 Modèle de spécification
5.2.2.2 Modèle exécutif
5.2.2.3 Modèle de Distribution
5.2.2.4 Modèle d’implémentation
5.2.3 L’outil DOGME
5.2.4 Consolidation du modèle de temps, utilisation d’un ISS
5.2.5 Multi OS hétérogènes, utilisation du modèle d’ARD
5.2.6 Conclusion du projet OveRSoC
5.3 Exemple de déploiement du modèle : Travaux dans le projet Ter@Ops
5.3.1 Objectifs du projet Ter@OPS
5.3.2 Architecture retenue
5.3.3 Simulateur de l’Architecture
5.3.3.1 Architecture globale du simulateur
5.3.4 Architecture logicielle et simulation
5.3.4.1 Buts de la Machine Virtuelle (MV)
5.3.4.2 Modèles de programmation de la MV
5.3.4.3 Les services de la MV
5.3.4.4 Construction de la MV sur le modèle d’OS en SystemC
5.3.4.5 Intégration de l’OS dans l’architecture de communication OCP
5.3.5 Gestion de la mémoire et implications pour la modélisation
5.3.6 Conclusion
5.4 Conclusion du chapitre
6 Conclusion et perspectives
6.1 Bilan
6.2 Perspectives
A Service de sémaphore partagé autonome
A.0.1 Contexte et problématique
A.1 L’IP Sémaphore matériel
A.1.1 Description fonctionnelle
A.1.2 Description VHDL
A.1.3 Intégration au LEON 3
A.2 Résultats
A.2.1 Module de sémaphores matériel
A.2.2 Interface aux bus AMBA et Avalon
A.3 Conclusion
B Résultats d’explorations de l’application de vision pour différents ARD
Télécharger le rapport complet
