La miniaturisation des composants électroniques a permis de concevoir des puces de plus en plus petites, plus performantes, consommant moins d’énergie et offrant un nombre de fonctionnalités toujours croissant [1]. Les puces électroniques se retrouvent généralement au centre de systèmes complexes et sont chargées de gérer les données provenant de différents capteurs et modules. Par exemple, le microcontrôleur STM32 F2 peut se retrouver au centre de la montre connectée Pebble. Bien que ce circuit ne mesure que 16mm², il centralise les données des différents capteurs de mouvement (LIS3DH de STMicroelectronics) et gère la connexion avec un téléphone par Bluetooth tout en offrant des performances et une autonomie de batterie importante.
Ces systèmes centraux regroupant à la fois du logiciel et du matériel sur une même puce sont appelés Systèmes sur Puce (ou SoC pour System on Chip). Un SoC est comparable à un ordinateur classique, à la différence que les éléments d’un ordinateur sont réparties sur plusieurs cartes (carte son, carte graphique, carte mère, RAM …) tandis que le SoC contient tous ces éléments sur une seule et même puce. Nous pouvons aisément comprendre la complexité de réalisation de ce type de puce où tous les éléments sont développés et intégrés en une seule fois.
Le développement d’un système sur puce nécessite l’intervention de plusieurs centaines d’acteurs répartis autour du monde. Outre les raisons économiques de cette distribution, cela permet de spécialiser chaque équipe sur un aspect particulier du développement (marketing, développement matériel, développement logiciel, documentation…) et ainsi paralléliser les développements. Ces différents intervenants vont s’intéresser à différents aspects ou points de vue particuliers du système à développer, nécessitant une expertise sur différents corps de métier et la gestion d’outils et de langages spécifiques permettant d’exprimer leurs idées. En effet, le développement d’un SoC peut nécessiter l’utilisation de plus de cinquante formats de documents différents.
Maintenir la cohérence du corpus documentaire nécessaire au développement des systèmes sur puce
Aujourd’hui, les systèmes sur puces développés par STMicroelectronics sont composés de plusieurs processeurs, d’une centaine de blocs de propriété intellectuelle, de dizaines de millions de lignes de codes et peuvent mobiliser plusieurs centaines d’employés. Le temps de mise sur le marché (Time To Market ou TTM) des systèmes sur puce est une contrainte de développement très importante afin de s’assurer une bonne part de marché et un bon prix unitaire du produit.
Maintenir la cohérence du corpus documentaire est primordial afin de conserver un bon TTM. Les incohérences sont sources de bogues qu’il faudra corriger, impactant donc le temps de développement et le cout du projet. Les documents, créés par les différents acteurs impliqués dans le développement d’un système sur puce, ne sont pas indépendants les uns des autres. En effet, les nouveaux documents sont généralement créés en se référant à des documents pré-existants. Dans ce contexte, la modification d’un document est susceptible d’impacter la cohérence du corpus documentaire, causant une perte de temps afin de réconcilier les documents. Nous entendons par les termes « réconciliation » ou « réalignement » l’action de synchronisation nécessaire afin qu’aucun document n’en contredise un autre.
De plus, en observant les méthodes de travail de STMicroelectronics, nous avons identifié trois points qui pourront devenir bloquants dans les prochaines années, si les méthodologies de maintenance de cohérence et de propagation de changements utilisées ne sont pas changées. Ces caractéristiques semblent inhérentes au développement de systèmes complexes comme le confirme Bézivin et al. dans [4] :
• De nombreux formats de documents sont nécessaires afin d’exprimer et de spécifier les différents aspects d’un système sur puce mais cette hétérogénéité accroit la difficulté de maintenance de cohérence des documents.
• La distribution des tâches et des équipes est obligatoire afin de faire décroitre le temps de mise sur le marché des produits mais ce parallélisme des tâches nécessite une allocation de temps de la part des employés afin de résoudre les problèmes de réconciliation des documents.
• Les méthodes agiles et les processus itératifs sont appliqués afin de gérer plus efficacement la complexité toujours croissante des systèmes et pour s’adapter plus rapidement aux changements de spécifications. Cependant, ces pratiques basent la maintenance de cohérence sur des réunions fréquentes entre les équipes, ce qui n’est pas toujours possible dans le contexte d’une grande entreprise où les équipes sont réparties tout autour du monde. Ceci nécessite des méthodes ou des outils de propagation de changements appropriés.
Complexité des systèmes sur puces
Nous retrouvons ainsi un microcontrôleur (ST40-300) accompagné de ses différents niveaux de mémoire cache et contenant également de nombreux composants classiques tels que les Timers (pour la gestion du temps), un contrôleur d’interruption (Interrupt) et de nombreux contrôleurs d’entrées/sorties (comme USB, Ethernet, mémoires, flash, cartes SD, Sata, Audio, vidéo analogique, HDMI). Nous retrouvons également des blocs spécifiques à des applications particulières, comme le décodage du flux audio et vidéo (Audio decoder et Video decoder) tous deux basés sur un microcontrôleur ST231, un démodulateur de signal numérique (DVB-C/T/T2 demodulator) ou pour des composants de traitement d’images (Blitter, Graphic planes, Tile SRAM).
Afin de pouvoir inter-opérer, tous ces éléments sont interconnectés entre eux (ST Bus). À la différence d’un ordinateur classique, où ces éléments seraient répartis sur des puces et cartes différentes assemblées entre elles (carte mère, carte son, carte graphique, barrettes de RAM), ici tous les éléments sont rassemblés sur une seule et unique puce.
Il est important de noter que le développement du logiciel peut se faire en même temps que le développement du matériel grâce à la co-simulation. En effet, la partie logicielle définie lors de la phase de spécification est souvent très dépendante de la partie matérielle et surtout du fonctionnement des composants matériels. Le logiciel ne peut donc pas être développé et exécuté sur des ordinateurs classiques. Il faudrait théoriquement attendre que la puce soit entièrement réalisée avant de commencer le développement du logiciel. Cependant, ceci entrainerait un temps avant la mise sur le marché de la puce beaucoup trop long. En outre, l’exécution du logiciel fait très souvent apparaitre des défauts de spécification ou de conception du matériel. C’est pourquoi des techniques ont été développées afin de permettre au logiciel de s’exécuter sur des modélisations du matériel. En effet, le principal intérêt du modèle TLM est de pouvoir exécuter le logiciel sur un modèle haut-niveau du composant, plus rapidement et plus tôt que sur les modèles RTL.
|
Table des matières
Chapitre 1 Introduction
1.1 Contexte du travail
1.2 Problématique abordée
1.3 Contributions
1.4 Organisation du document
Chapitre 2 Maintenir la cohérence du corpus documentaire nécessaire au développement des systèmes sur puce
2.1 Complexité des systèmes sur puces
2.2 Présentation du flot de conception des systèmes sur puce
2.2.1 Spécifications clients
2.2.2 Modèle fonctionnel et matériel
2.2.3 Analyse d’architecture SoC
2.2.4 Développement Logiciel
2.2.5 Développement Matériel
2.3 Conséquences des incohérences
2.4 Spécificités du flot
2.4.1 Hétérogénéité des formats
2.4.2 Distribution des équipes
2.4.3 Les développements itératifs et les méthodes agiles
2.5 Analogie entre flot de conception des systèmes sur puce et systèmes distribués
2.5.1 Présentation de l’analogie
2.5.2 Modèles de cohérence appliqués au flot de conception
2.5.3 Analyse du modèle de cohérence du flot de conception
2.6 Conclusion
Chapitre 3 Gestion des sources d’incohérences dans le flot de conception des systèmes sur puce
3.1 Outils collaboratifs
3.1.1 Gestion des exigences
3.1.2 Gestion de versions
3.1.3 Moteur de production
3.1.4 Logiciel de suivi de problèmes
3.1.5 Outils de centralisation des ressources
3.2 Gestionnaire d’incohérence (inconsistency checking)
3.3 Description d’architecture
3.3.1 Aperçu du standard ISO/IEC/IEEE 42010
3.3.2 Description d’Architecture, acteurs et préoccupations
3.3.3 Vue et Point de vue architectural
3.3.4 Correspondance architecturale
3.3.5 Langages de description d’architecture
3.4 Conclusion
Chapitre 4 Une approche pragmatique des problèmes de cohérence
4.1 Duplication des informations dans le flot de conception
4.2 Transformation de modèles appliquée au flot de conception des systèmes sur puce
4.3 Expliciter les transformations entre les documents
4.3.1 Définition des transformations
4.3.2 Approche basée sur ISO/IEC/IEEE 42010
4.3.3 Création des liens dans les pratiques de travail classique
4.3.4 Rendre les systèmes de gestion de version conscients de l’architecture des systèmes sur puce
4.3.5 Granularité des fragments
4.4 Exploitation des liens pour propager les modifications
4.4.1 Adaptation du système en réponse aux actions des utilisateurs
4.4.2 Émergence de processus
4.5 Modèle de cohérence induit par l’approche
4.6 Adaptation du standard de description d’architecture
4.6.1 Représentation des documents
4.6.2 Représentation des correspondances
4.6.3 Propagation des changements
4.7 Conclusion & Discussion
Chapitre 5 Conclusion
