Profil UML pour TLM: contribution à la formalisation et à l automatisation du flot de conception et vérification des systèmes-sur-puce.

Dimension: px
Commencer à balayer dès la page:

Download "Profil UML pour TLM: contribution à la formalisation et à l automatisation du flot de conception et vérification des systèmes-sur-puce."

Transcription

1 INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE N attribué par la bibliothèque T H È S E pour obtenir le grade de DOCTEUR DE L INPG Spécialité : «Micro et Nano Électronique» préparée au laboratoire CEA LIST/DTSI/SOL/LISE dans le cadre de l École doctorale «ÉLECTRONIQUE, ÉLECTROTECHNIQUE ET TRAITEMENT DU SIGNAL» présentée et soutenue publiquement par Sébastien REVOL le xx xxxx 2008 Titre : Profil UML pour TLM: contribution à la formalisation et à l automatisation du flot de conception et vérification des systèmes-sur-puce. Directeur de thèse : François Terrier JURY Frédéric Pétrot Charles André Pierre Boulet François Terrier Sébastien Gérard Alain Clouard Président Rapporteur Rapporteur Directeur de thèse Examinateur Examinateur Sébastien Revol Thèse de doctorat 1/161

2 2/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

3 Table des matières 1 Introduction Contexte du travail Problématiques abordées Approche envisagée Organisation du document I Problématique, et analyse de l état de l art 11 2 La conception des systèmes sur puce Spécificité des systèmes sur puce Présentation du flot de conception des systèmes sur puce Spécifications clients Modèle fonctionnel Analyse d architecture Développement Logiciel Développement Matériel TLM et IP-XACT : accélérateurs du flot Présentation de la modélisation transactionnelle Présentation du formalisme IP-XACT Les limites actuelles de l accélération du flot de conception Présentation générale de l Ingénierie Dirigée par les Modèles Modèles et Méta-modèles La notion de modèle La notion de méta-modèle Quatre niveaux d instanciation Apports de l IDM Définition de langages Le meilleur langage dans la meilleure syntaxe Les langages spécifiques au domaine et les langages généralistes Automatisation fournie par l IDM Aspect méthodologique Les différents espaces technologiques W3C et XML Les standards de l OMG pour l IDM

4 Table des matières 3.4 Présentation de l Unified Modeling Language Historique Les différents diagrammes Extensibilité d UML : la notion de profil UML et IDM comme support de méthodologies Les bénéfices de l IDM et UML Un langage adapté aux besoins de l utilisateur Diminution du nombre de formats Interopérabilité des formats Automatisation grâce à l IDM Réutilisation des spécifications Conclusion Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC Contexte de l étude Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce Les méthodologies UML pour les systèmes sur puce Exigences du système et spécifications fonctionnelles Analyse Architecture Pour le flot logiciel Pour la modélisation matérielle et génération de code Résumé de l étude Solution proposée : le profil Electronic System Level Présentation générale Positionnement dans le flot de spécifications Conclusion II Définition et exploitation d un profil UML pour la modélisation au niveau Système Electronique (ESL) 63 5 Le profil UML pour la modélisation au niveau Système Electronique Organisation des concepts Le paquetage Component Présentation générale Contenu du paquetage Portage sur le langage UML Le paquetage Register Map Présentation générale Motivations Les modèles de registres Le modèle de domaine du paquetage Register Map Le sous-paquetage TLM Behaviour Portage sur la syntaxe UML : définition des stéréotypes Le paquetage BusInterface Présentation générale Motivations /161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

5 Table des matières Les modèles d interconnections Définition du paquetage BusInterface Le paquetage Hierarchy Présentation générale L approche IP-XACT de la hiérarchie Les approches UML Définition du paquetage Hiérarchie Le paquetage Implementation Présentation générale Principe de l association Conclusion Exploitation du langage ESL Aperçu de l implémentation Les transformations L environnement d implémentation Générateur de code SystemC/C Présentation générale Architecture du générateur Syntaxe abstraite et génération de code Les profils C++ et SystemC associés Transformation ATL d UML vers la syntaxe abstraite C++/SystemC Intégration dans Eclipse Transformation d IP-XACT vers le profil ESL Motivations Principes de la transformation Implémentation de la transformation Transformation du profil ESL vers les profils SystemC-C Présentation générale La création des modules Création des registres Implémentation des fonctions Read/Write Conclusion III Etude de cas et évaluation Evaluation et discussion Cas d évaluation Spécification du cas d étude Les composants modélisés Principes d évaluation Présentation de la méthode d évaluation Détermination des critères d évaluation Evaluation Comparaison UML-ESL et IP-XACT Comparaison des modèles UML-ESL et UML-SystemC Sébastien Revol Thèse de doctorat 5/161

6 Table des matières Complétude du code généré Comparaison du code généré avec le code original Evaluation de l effort de modélisation et du temps de conception Conclusion de l étude Résumé des résultats Discussion sur les limites de notre étude Conclusion Conclusion et perspectives Bilan Ouvertures Gestion du comportement Raffinement depuis un niveau plus abstrait Ouverture vers différents niveaux d abstraction Génération de tests Connexion avec des méthodes formelles Utilisation dans une approche d analyse Bibliographie 151 6/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

7 Chapitre 1 Introduction Sommaire 1.1 Contexte du travail Problématiques abordées Approche envisagée Organisation du document Contexte du travail Les systèmes électroniques sont de plus en plus présents dans notre vie quotidienne. Les progrès de miniaturisation permettent de concevoir des puces embarquant un nombre incessamment croissant de fonctionnalités. Ainsi un téléphone portable de troisième génération (3G) est maintenant capable de permettre la réception et la transmission simultanées d un flux audio (la voix) et vidéo (visiophonie). En plus de ces fonctionnalités qui nécessitent d importants traitements d encodage et décodage de données, ces même téléphones intègrent de nombreuses fonctionnalités supplémentaires, comme le GPS, la radio, l accès à internet, etc. La puce qui centralise tout ces traitement numériques regroupe donc en son cœur un ensemble d éléments, qui peuvent être comparés à ceux que l on retrouve dispersés et interconnectés via la carte mère d un ordinateur classique. On parle ainsi de Système sur Puce (ou SoC pour System on Chip). La téléphonie mobile n est pas le seul domaine dans lequel on retrouve des SoC, et ceux-ci envahissent de plus en plus d objets de la vie courante (transport, électroménager, médical, hi-fi etc.). Une caractéristique commune à tous ces domaines est certainement le contexte économique et concurrentiel très pressant qui oblige les industries à fournir des produits toujours plus novateurs à moindre prix et dans un temps le plus court possible. Ce sont bien sûr les progrès réalisés dans le domaine de la conception physique des puces, dans les technologies exploitant le silicium, qui permettent de supporter cette incessante évolution. Ainsi, la célèbre loi de Moore prédit que le nombre de transistors intégrables sur une seule puce double tous les dix-huit mois. Ceci revient à dire qu une puce peut doubler ses performances tous les ans et demi. Cependant cette croissance exponentielle de productivité ne concerne que cette couche physique de bas niveau. Lorsque l on raisonne sur le travail amont, pendant lequel les fonctionnalités du systèmes sont définies, réalisées et testées, on s aperçoit que la productivité de ces méthodes de conception ne suit pas une évolution aussi rapide. Ainsi, si la réalisation physique d une nouvelle génération de puce peut se faire dans les mêmes contraintes de temps et de coûts que les précédentes, le temps 7

8 Chapitre 1. Introduction nécessaire (et donc le coût) à toute la conception en amont de cette réalisation augmente fortement. Le constat de ce fossé technologique, appelé Design Gap, fait qu actuellement de nombreuses initatives de recherche se penchent sur cette problématique, afin d augmenter la productivité des méthodes de conceptions et de satisfaire les contraintes économiques et techniques toujours plus pressantes dans ce milieu. 1.2 Problématiques abordées Les difficultés pour augmenter l efficacité du flot de conception proviennent principalement du grand nombre d étapes et des différentes spécialités mises en jeu tout au long de ce processus. Chacune de ces phases, telles que la définition des fonctionnalitées attendues du système, la détermination de l architecture permettant leur réalisation, puis le développement effectif du logiciel et du matériel sont autant de challenges technologiques. Pour chacun de ceux-ci, la recherche s active à trouver des solutions permettant de faciliter le travail des développeurs. La modélisation des circuits au niveau transactionnel (Transactionnal Level Modeling, TLM) [46] en est un exemple. Maintenant grandement adopté par l industrie, cette modélisation permet l obtention rapide de circuit virtuels sur lesquels le logiciel peut être développé avant même que le circuit soit réalisé. De plus, elle facilite aussi la vérification de ces circuits et fournit un moyen de valider rapidement que le système satisfera bien les exigences qui lui sont demandées. Le standard IP-XACT [113] est un autre exemple d accélérateur du flot. Le but de celui-ci est de favoriser la réutilisation et l intégration dans un nouveau circuit de composants existants. Cependant, la plupart de ces solutions n apportent qu une réponse locale à un point spécifique du flot. Elles exploitent des outils spécifiques, se basant sur des formats particuliers ne facilitant pas la communication entre équipes ni la réutilisation de leur travaux. De ce fait, la transition entre les différentes étapes du processus de conception implique de nombreuses opérations de traductions, de réinterprétation, qui sont autant de pertes de temps et de sources d erreurs potentielles. L Unified Modeling Language (UML) [91] a récemment été pressenti comme une solution pour apporter une unification visant à fluidifier les différentes étapes de conceptions. En effet, le spectre couvert par ce langage, augmenté par son mécanisme de spécialisation via des profils en font un candidat idéal pour apporter des vues adaptées à la plupart des étapes de ce flot de conception. Les techniques de l Ingénierie Dirigées par le Modèles (IDM) sur lesquelles reposent ce langage proposent de plus des moyens efficaces d exploiter les modèles qu il permet de construire, notamment par le biais de transformations de modèles et de génération de code. Ainsi de nombreuses initiatives se sont focalisées sur la définition de moyens pour l exploitation de ce langage dans la conception des SoC. Cependant ici aussi la complexité du flot se fait sentir et la plupart de ces initiatives ne peuvent généralement se concentrer que sur un point particulier de celui-ci. Ainsi le profil SysML [93], conçu pour faciliter l ingénierie système, paraît bien adapté pour les toutes premières étapes de modélisation des SoC. Le récent standard MARTE [89] attache une attention particulière à l analyse du système permettant de faire son dimensionement. Le profil UML for SystemC [101] apporte quant à lui un moyen efficace pour la génération du code de plateformes simulables. L intégration de ces différentes techniques dans une approche de conception globale, d une manière complémentaire aux standards de l industrie tels qu IP-XACT ou la modélisation transactionnelle reste cependant encore une problématique à explorer. 8/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

9 1.3. Approche envisagée 1.3 Approche envisagée L approche proposée consiste à définir un langage pivot s appuyant sur UML, permettant l intégration et l interopérabilité entre les différentes briques existantes afin de fluidifier le flot. Plus précisémment, nous viserons à assurer : L intégration d un flot UML avec les techniques industrielles basées sur IP-XACT : nous analyserons les atouts que fournissent chacun de ces langages dans un flot de conception, déterminerons comment les utiliser de manière complémentaire et fournirons le moyen d assurer l interopérabilité. La diminution du nombre de modèles et leur cohérence : au cours du flot de réalisation des SoC, les différents concepteurs réalisent chacun des modèles du même système focalisant sur des aspects différents de celui-ci. Nous montrerons comment ce langage pivot permet de centraliser de nombreuses informations dans un unique modèle de spécifications. Nous proposerons de plus un moyen de gérer la cohérence entre ce modèle et les différents modèles d implémentation. L automatisation du flot de conception : nous montrerons comment l usage d un langage adapté, assisté par les technologies de l IDM permettent d obtenir un gain de temps important pour la réalisation de modèles d implémentation des composants. Afin de s insérer dans les méthodes de travail de la société STMicroelectronics, nos développements se sont particulièrement focalisés sur la génération de modèles SystemC-TLM. 1.4 Organisation du document Ce document est organisé en trois grandes parties. Dans la première, intitulée Problématique et analyse de l état de l art, nous analysons ce qui nous a amené à définir le périmètre de notre contribution. Pour ceci, nous rappelons dans le chapitre 2 le flot de conception des systèmes sur puces et identifions les limitations de celui-ci. Dans le chapitre suivant, nous nous intéressons aux différentes techniques offertes par les technologies de l Ingénierie Dirigée par les Modèles, en mettant en valeur l intérêt qu elle peuvent procurer dans le cadre général d un flot de conception. Enfin, le chapitre 4 se focalise plus particulièrement sur les initiatives portant sur l utilisation d UML et de l IDM pour la conception des SoC. Nous en faisons l analyse et proposons un flot visant à les utiliser au mieux. Cependant, c est aussi cette analyse qui nous permet d aboutir au besoin d un langage de modélisation au niveau système électronique (Electronic System Level, ESL). Notre première partie de thèse se conclut par le positionnement de notre objectif dans ce flot de conception. La seconde partie de ce mémoire, appelée Définition et exploitation d un profil UML pour la modélisation au niveau Système Electronique constitue le cœur de cette thèse. C est en effet dans le premier de ses chapitres, le chapitre 5, que nous définissons de manière détaillée les spécifications de notre langage puis sa projection sur UML. Dans le chapitre suivant, nous nous basons sur les besoins induits par les méthodes de développements de l entreprise STMicroelectronics pour la réalisations de transformations de modèles et de générateurs de codes exploitant notre langage. Nous nous appuierons ainsi sur les Sébastien Revol Thèse de doctorat 9/161

10 Chapitre 1. Introduction notions introduites dans le chapitre 3 pour exposer comment nous avons implémenté ces diverses opérations. Enfin la troisième partie du manuscrit, intitulée Etude de cas et évaluation propose une évaluation cherchant à valider l intérêt de notre approche. Celle-ci à consisté en la spécification et l implémentation via notre flot de différents composants d une plateforme SystemC-TLM utilisée dans un contexte industriel chez STMicroelectronics. Nous avons ainsi pu substituer les composants existants par ceux obtenus grâce à notre flot. Ensuite, par la définition de critères objectifs, nous avons apporté différentes métriques permettant de quantifier les bénéfices et les limitations de notre approche. Le dernier chapitre de cette partie conclut ce mémoire en rappelant les points essentiels de notre contribution, discutant des points à compléter et, plus généralement, en proposant des ouvertures pour des travaux futurs. 10/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

11 Première partie Problématique, et analyse de l état de l art 11

12

13 Chapitre 2 La conception des systèmes sur puce Sommaire 2.1 Spécificité des systèmes sur puce Présentation du flot de conception des systèmes sur puce Spécifications clients Modèle fonctionnel Analyse d architecture Développement Logiciel Développement Matériel TLM et IP-XACT : accélérateurs du flot Présentation de la modélisation transactionnelle Présentation du formalisme IP-XACT Les limites actuelles de l accélération du flot de conception La miniaturisation et la dissémination toujours croissantes des systèmes électroniques dans notre quotidien se sont traduites ces dernières années par une généralisation de l utilisation des systèmes sur puces. En effet, la particularité de ces systèmes est de concentrer sur un seul support, la puce, un maximum de fonctionnalités. Grâce à ceux-ci, nos objets de tous les jours tels que l électroménager, les outils de télécommunications, les matériels multimédia ou médicaux, les transports, les consoles de jeux ou les assistants personnels sont de plus en plus performants. Cette croissance de complexité a été rendue possible par les incessants progrès des technologies d intégration des transistors sur une puce. Ainsi la loi de Moore, qui n a pour l instant jamais été contredite depuis plusieurs dizaines d années prédit que le nombre de transistors contenus sur une seule puce augmente de 50% par an. Bien qu il soit prévu que cette progression finisse un jour par plafonner, il est attendu qu elle se poursuive pendant encore de nombreuses années. Cette progression est cependant à double tranchant : les systèmes qu elle permet de réaliser sont en effet des systèmes de plus en plus sophistiqués, mais deviennent par la même occasion de plus en plus difficiles à concevoir. Or il a été estimé que la productivité des développeurs n augmentait elle que de 30% par an. Il existe donc un écart croissant entre l évolution des capacités physiques des puces et la quantité de code que peuvent produire les concepteurs : cet écart a été baptisé design gap. Celui-ci est un réel problème et la recherche dans de nouvelles méthodes de conceptions prend donc de plus en plus d importance. Dans ce chapitre, après avoir présenté rapidement quelles sont les spécificités propres à la réalisation des systèmes sur puces, nous identifierons les grandes étapes de leur flot de conception 13

14 Chapitre 2. La conception des systèmes sur puce et reviendrons sur des moyens déjà adoptés pour en accélérer le processus. Enfin nous chercherons à identifier quelles sont leurs lacunes et approfondirons les points restant encore à améliorer. 2.1 Spécificité des systèmes sur puce Afin de mieux comprendre la complexité des systèmes sur puce, observons la figure 2.1. FIG. 2.1 Exemple d architecture de système sur puce Elle représente l architecture d une puce conçue par STMicroelectronics que l on retrouve au cœur des téléphones portables de troisième génération. Son architecture est en de nombreux points semblables à celle que l on retrouve dans les ordinateurs classiques. On retrouve ainsi un processeur (ARM926EJ) accompagné des ses différents niveaux de mémoire cache et de nombreux contrôleurs d entrées/sorties (USB, LCD, mémoire flash, cartes SD, mémoire RAM etc.). On retrouve aussi des nombreux composants classiques tels que les Timers (pour la gestion du temps), un contrôleur d interruption (Interrupt Controller ou encore des contrôleurs d accès direct à la mémoire (DMA Controller), ainsi que des blocs spécifiques à des applications particulières, comme le décodage de flux audio ou vidéo (Smart Audio Accelerator et Smart Video Accelerator) ou pour le traitement d image (Smart Graphics Accelerator et Smart Imaging Accelerator). On constate de plus qu afin de pouvoir inter opérer, tous ces éléments sont interconnectés entre eux par un ou plusieurs canaux de communications. Cependant, à la différence d un ordinateur classique où ces éléments sont répartis sur des puces et des cartes différentes assemblées entre elles (telles que la carte mère, la carte son, la carte graphique etc.), ici tous les composants sont rassemblés sur une seule et unique puce. On comprend ainsi la complexité de la tâche de la réalisation de ce type de puce. Pour un ordinateur, ce sont des constructeurs différents qui fournissent des composants clairement définis et interconnectables via des interfaces et protocoles standards tels que le PCI 1, fournissant aussi les pilotes permettant au logiciel d accéder aux services fournis par ce composant. Dans le cas d un système sur puce, tous ces éléments doivent être développés et intégrés en une seule fois. Le coût d un masque, 1 Peripheral Component Interconnect : interconnection de composants périphériques 14/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

15 2.2. Présentation du flot de conception des systèmes sur puce permettant la phase finale de conception d une puce par la gravure des transistors dans le silicium peut dépasser le million d euros. A cette phase là, il est donc impératif que la puce soit entièrement opérationnelle, sans vice de fonctionnement caché, et qu elle réponde parfaitement aux exigences attendues par le client, en termes de performance, de consommation d énergie ou de fonctionnalité. Il faut noter que ces contraintes sont souvent très fortes pour ce type de systèmes, auxquels on demande toujours plus de fonctionnalités pour un encombrement toujours plus petit et une autonomie de plus en plus grande. A ces pressions se rajoutent celles imposées par le contexte économique et concurrentiel : le système doit être le moins coûteux possible, et doit être toujours plus innovant, et prêt plus rapidement que celui des concurrents Présentation du flot de conception des systèmes sur puce Nous allons maintenant nous intéresser au flot de réalisation qui peut se résumer par la figure 2.2. Avant de rentrer dans les détails de chacune des étapes de ce flot, regardons l allure générale de celui-ci. On peut voir qu il se décompose en deux phases principales : la partie du haut, s arrêtant après l étape d analyse architecturale est la phase de spécifications. C est dans celle-ci que l on va identifier les besoins auxquels la puce devra répondre, tout d abord de manière textuelle puis en rentrant dans le détail des fonctionnalités qu elle devra accomplir. Elle se termine par la phase d exploration architecturale. Au cours de celle-ci, la tâche de l architecte système est de déterminer quelle configuration matérielle, en termes de blocs assemblés sur la puce (tels que dans la figure 2.1 de la section précédente), sera nécessaire pour subvenir aux besoins exprimés précédemment. Cette phase se termine donc par un partitionnement Matériel/Logiciel qui consiste à déterminer quelle proportion de la réalisation des fonctionnalités de la puce sera attribuée respectivement au matériel et au logiciel (nous reviendrons plus en détail sur cette étape et ses enjeux dans la section 2.2.3). Après cette phase, l architecture du système est déterminée, la phase d implémentation du système peut donc commencer. On peut remarquer qu elle se réalise en deux branches parallèles : le développement logiciel et le développement matériel. Le développement matériel, qui consiste à l élaboration de la partie physique de la puce, se réalise à travers différents niveaux de modélisation dont nous avons rapporté les principaux : le niveau transactionnel (Transactional Level Modeling), le niveau cycle (Cycle Accurate), et le niveau transfert de registres (Register Transfert Level). Si certains de ces niveaux sont optionnels et ne sont là que pour faciliter le flot, le dernier (RTL) est lui obligatoire. C est en effet celui-ci qui décrit de manière la plus précise comment fonctionnera l intégralité des composants présents sur la puce, et qui pourra être automatiquement synthétisé en une combinaison d opérations logiques élémentaires (portes logiques) dont l implémentation est alors réalisée par le biais des transistors et des fils gravés sur le circuit. Il faut noter que si le développement du logiciel peut se faire en même temps que celui du matériel, c est grâce à la simulation conjointe. En effet, le logiciel spécifié à l issue de la phase de partitionnement est souvent très dépendant du fonctionnement des composants matériels. Il ne peut donc pas être développé et exécuté sur des ordinateurs classiques et il faudrait théoriquement attendre que la puce soit complètement réalisée pour pouvoir commencer son implémentation. Outre le fait que cela augmenterait considérablement le temps de mise sur le marché de la puce, il arrive couramment que l exécution du logiciel fasse 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 2 Cette contrainte est une des plus fortes dans le domaine de l électronique, et il en est souvent fait allusion à travers l anglicisme : Time to Market, pour temps de mise sur le marché. Sébastien Revol Thèse de doctorat 15/161

16 Chapitre 2. La conception des systèmes sur puce Matlab C/C++ Algos de référence Spécifications client (textuelles) Modèle fonctionnel (exécutable) Modèle Matériel Base de composants et plateformes Analyse Statique (Excel) Analyse Dynamique (Simulations) Analyse Architecturale Itérations Dev. Matériel Développement Logiciel Syst. d'exploitation Intergiciel Code bas niveau Simulation Conjointe Modèles TLM Modèles CA Modèles de Référence (Drivers et Firmware) Modèles RTL Synthèse Programmation Portes Logiques FIG. 2.2 Aspect du flot de conception des systèmes sur puce 16/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

17 2.2. Présentation du flot de conception des systèmes sur puce modèles virtuels du matériel. C est d ailleurs un des rôles principaux de la modélisation transactionnelle, sur laquelle nous reviendrons plus en détail. Nous allons maintenant reprendre un peu plus en détail chacune des étapes du flot de conception des systèmes sur puce afin d en comprendre les enjeux et concepts mis en jeu Spécifications clients La première des étapes du flot est bien-sûr l expression des besoins auxquels doit répondre la puce. Cette expression est généralement faite de manière informelle à travers des documents textuels. Même si un système sur puce rassemble un grand nombre de fonctionnalités sur un seul composant, il est généralement destiné à être intégré dans un système encore plus complexe, et devra interagir avec d autres composants, tels que les périphériques d acquisition ou d affichage, les modules de gestion d alimentation électrique etc. Les spécifications client peuvent donc à la fois porter sur les fonctionnalités attendues de la puce, mais aussi sur les contraintes qui lui sont imposées par son environnement. Ces contraintes peuvent être d ordre de sûreté de fonctionnement (lorsque la puce est destinée à être utilisée dans des systèmes critiques), de sécurité de protection des données (par exemple pour les puces des carte bancaires), mais aussi de consommation d énergie, d encombrement (surface), de dissipation de chaleur, de performance et bien sûr, de coût. Toutes ces contraintes seront alors à prendre en compte pour la conception de la puce Modèle fonctionnel A l issue de la spécification des exigences, les fonctionnalités attendues du systèmes sont généralement implémentées dans différents modèles exécutables. Ceux-ci ne sont que purement fonctionnels par extension logiciels : il décrivents quelles seront les fonctions et algorithmes principaux que la puce devra réaliser, mais en aucun cas comment ils seront effectivement exécutés sur la puce. Le but de ce genre de modèles est multiple. Ils permettent tout d abord de valider avec le client, en visualisant le rendu de l exécution d un algorithme, que celui-ci correspond bien à ses attentes. De tels modèles sont généralement écrits dans un langage comme le C ou le C++, ou alors avec des outils spécialisés comme Matlab [70]. Ils intègrent des algorithmes spécialement conçus pour une nouvelle fonctionnalité, ou reprennent des modèles de références, comme on en trouve dans les standards tels que le décodage ou l encodage de vidéos MPEG4. Un modèle fonctionnel aboutit donc une description architecturale en termes de fonctionnalités du système. On identifie ainsi des blocs fonctionnels, interagissant entre eux, mettant en évidence leurs interdépendances et créant donc des besoins de communication qui peuvent être évalués en terme de débit de données, de temps de réponse, de qualité de service etc. On comprend alors le second rôle de ce modèle fonctionnel, qui va pouvoir être utilisé dans l étude d architecture physique de la puce Analyse d architecture Cette étape est un point crucial, déterminant le reste du flot de conception. Comme nous l avons introduit précédemment, c est à ce moment là que les architectes système doivent déterminer comment sera constituée la puce pour qu elle réponde aux exigences spécifiées dans la phase précédente. Un des principaux paramètres pour cette détermination est le partitionnement Logiciel/Matériel. En effet, il existe plusieurs manières d exécuter un algorithme spécifié dans un modèle fonctionnel. Cette tâche peut être attribuée à un processeur, et l algorithme reste alors sous forme logicielle. Cette possibilité est en général la plus facile et donc la moins coûteuse à réaliser, offrant de plus Sébastien Revol Thèse de doctorat 17/161

18 Chapitre 2. La conception des systèmes sur puce beaucoup de souplesse, puisque même après la conception finale de la puce il est possible de la reprogrammer pour effectuer une éventuelle modification de l algorithme. Cependant, lorsque l algorithme est trop complexe, les processeurs ne sont souvent pas assez performants, ou sont trop gourmands en énergie pour satisfaire les exigences requises. L alternative est donc de créer des composants dédiés, optimisés pour le traitement d un ou plusieurs algorithmes spécifiques. C est par exemple le cas des blocs appelés Accelerator dans la figure 2.1. Ces composants spécifiques sont alors beaucoup plus performants et proposent une consommation d énergie optimum. Cependant ils sont beaucoup plus complexes à réaliser et ces algorithmes sont alors figés dans le silicium, ne pouvant plus être modifiés 3. Ce choix de partitionnement conditionne de plus d autres paramètres sur lequel l architecte doit prendre des décisions. Ainsi le placement des tâches sur tel ou tel processeurs, ainsi que le type d interconnection utilisé pour permettre la communication entre les éléments du système sont aussi très importants. Afin d effectuer leur choix, les architectes disposent de plusieurs moyens. L analyse de l exécution du modèles fonctionnels (Profiling) ainsi que l extraction du parallélisme potentiel pour le traitement des diverses opérations leur permettent d identifier quels seront les besoins en termes de ressources d exécution et de communication. La méthode générale consiste identifier des cas d utilisations du système, et à estimer les performances requises pour leur exécution. Les architectes peuvent alors créer une plateforme candidate et tenter d analyser si celle-ci va permettre l exécution effective de ces cas d utilisations. Actuellement, cette analyse de l influence des différents paramètres se fait encore simplement à l aide de tableaux dynamiques Excel. Cette étape est donc itérative, les architectes effectuant à plusieurs reprises des opérations de projection sur différents prototypes de plateformes. Une méthode complémentaire à cette analyse statique est une analyse dynamique. Dans ce cas là, les architectes utilisent des modèles simulables des composants comportant des informations temporelles, tels que les modèles TLM-PVT ou des générateurs de trafic simulant une utilisation du système [46] (cf. section 2.3.1). L utilisation d outils pour l analyse des résultats de simulation, notamment pour l encombrement de l utilisation des moyens de moyens de communication peut alors s avérer une aide précieuse pour les architectes, permettant éventuellement de reporter les estimations obtenues par la simulation dans les modèles purement analytiques. Enfin on aura remarqué sur la figure 2.2 que le modèle d architecture utilisé pour la projection du modèle fonctionnel n est pas reconstruit de zéro pour chaque nouvelle puce. En effet les blocs qui constituent un système sur puce sont généralement conçus pour être réutilisables, et une nouvelle architecture intègre très souvent des composants, voire des assemblages de composants déjà existants. Lorsque cette réutilisation prend une part importante du flot de réalisation on parle de conception basée sur les plateformes ou Platform Based Design [105]. Le processus d analyse d architecture aboutit donc sur la détermination d un système dont la partie logicielle a été spécifiée, ainsi que les composants qui devront l exécuter. Leurs phases de développement respectives peuvent donc commencer. 3 Une solution intermédiaire consiste à concevoir des macro-blocs comportant à la fois un processeur et une partie matérielle spécifique. Dans ce cas là, seulement une partie de l algorithme est figée, et la part estimée variable peut, elle, être reprogrammée sur le processeur. Une autre alternative en cours de développement est l utilisation d architectures matérielles dynamiquement reconfigurables, où le silicium n est alors plus figé, solution intermédiaire en terme de performance et de consommation 18/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

19 2.2. Présentation du flot de conception des systèmes sur puce Développement Logiciel La tendance actuelle de l évolution des architectures des systèmes sur puce, avec la généralisation des architectures multiprocesseurs tend à donner une part de plus en plus importante au logiciel. On en retrouve ainsi à plusieurs niveaux. Premièrement la plupart des processeurs doivent comporter un système d exploitation (Operating System), qui doit donc être porté pour l architecture matérielle ciblée. Ceci inclut le développement de code de bas niveau spécifique à l architecture matérielle ciblée, nécessaire par exemple pour le processus d initialisation de l OS. De plus les OS incluent généralement des couches d abstraction du matériel, permettant aux logiciels d accéder plus facilement aux services fournis par les ressources matérielles. Celles-ci sont donc très dépendantes des composants utilisés sur la puce et doivent être développées spécifiquement pour eux. De plus nous avons vu que certains macro blocs peuvent être constitués de composants dédiés jumelés avec des processeurs, parfois très simples, mais qui doivent donc exécuter un code embarqué (Firmware). Ceux-ci peuvent être notamment les algorithmes du modèle fonctionnel, qu il faut donc porter pour qu ils soient exécutés efficacement sur des ressources parfois limitées, nécessitant généralement un travail d optimisation. On notera que l utilisation des systèmes sur puce se fait généralement dans des systèmes dit embarqués, interagissant avecn leur environnement. La plupart des puces développées par STMicroelectronics sont plus destinés à des produits de consommation tels que les téléphones portables ou les décodeurs vidéo où la sureté de fonctionnement n est pas un élément critique. Cependant, lorsque ces puces sont utilisées dans des systèmes où la panne peut être très lourde de conséquences (transports, aérospatiale, contrôle de centrales nucléaires etc.) il est impératif que les logiciels développés garantissent cette sûreté de fonctionnement, rajoutant de nombreuses contraintes sur son développement Développement Matériel Comme nous l avons vu, la phase d analyse d architecture se termine généralement par la détermination des composants qui réaliseront physiquement le système sur puce. Le processus de développement matériel vise donc à créer cette implémentation. Heureusement, tous les composants ne sont pas à recréer complètement pour chaque puce, et la tendance actuelle vise à réutiliser au maximum des composants déjà existants. Nous verrons par la suite qu il s agit d un des objectifs principaux du formalisme IP-XACT [113]. Le travail de développement matériel consiste donc à la réalisation au niveau RTL dans un langage synthétisable tel que le VHDL des nouveaux composants issus de l analyse d architecture, et à la création de la plateforme finale, intégrant ces composants, ainsi que ceux qui ont été réutilisés. Cette intégration requiert des développements importants car il faut s assurer que tous les composants vont bien pouvoir interagir entre eux correctement. Une part importante de ce travail de développement matériel, estimée à environ 70% du temps total de conception d un système sur puce est consacrée au test et à la vérification. En effet il est capital d être certain que les circuits que l on va envoyer en production ne présentent pas de dysfonctionnement. Le test de ceux-ci se réalise généralement par des simulations de modèles. Comme on peut le voir dans la figure 2.2, il existe plusieurs niveaux de modélisation des composants matériels (TLM, CA, RTL). Le niveau le plus évident pour la simulation est le RTL puisqu il décrit l intégralité du comportement de tous les composants. Cependant, ce niveau de détail a un prix : la vitesse de simulation. Afin de pouvoir l accélérer, il est possible d abstraire le comportement de certains composants en modélisant avec du code C, dont la simulation fournira le même résultat observable. Ainsi une mémoire peut être représentée à l aide d un simple tableau ou un processeur peut être remplacé par un simulateur de jeu d instructions. Cette technique, consistant à simuler un mélange de description Sébastien Revol Thèse de doctorat 19/161

20 Chapitre 2. La conception des systèmes sur puce RTL et de modèle C, est appelée cosimulation [107]. Il est de plus possible d abstraire d un niveau supplémentaire les composants en retirant la notion d horloge. L élément le plus fin traduisant l évolution du système plus le cycle d horloge mais la transaction, c est à dire le transfert de données d un composant à l autre. Ce niveau de modélisation est donc appelé Transaction Level Modeling (TLM). Il permet de simuler l intégralité d un système à une vitesse suffisamment rapide, pour que ces modèles soient exploités pour le développement du logiciel embarqué. Cependant, grâce à l utilisation d adaptateurs appelé Transacteurs [22], la cosimulation d un système majoritairement modélisé en TLM avec un composant à tester en RTL reste possible, et fournit un moyen de tester rapidement ce composant dans un environnement proche de la réalité, incluant notamment le logiciel embarqué devant interagir avec lui. Pour en finir avec ce panorama des techniques de simulation, notons la possibilité de l utilisation d émulateurs matériels. Tout comme les FPGA, il s agit de composant matériel reprogrammable, c est-à-dire que les liaisons entre cellules logiques élémentaires peuvent êtres modifiées électroniquement [132]. Ils permettent donc simuler un système comme s il avait été synthétisé, avec un niveau de détail maximum. Cependant, les machines suffisamment puissantes pour simuler un système sur puce complexe sont malheureusement très coûteuses, et n offrent que peu de possibilités pour le débogage (contrairement au RTL [56]). Leur principale utilisation consiste à faire tourner de larges batteries de tests de façon automatique, dans l espoir de trouver les derniers bugs avant la création des masques (voir par exemple [44, 54]). La figure 2.3 récapitule les performances des différentes techniques de simulations pour le décodage d une image MPEG4. FIG. 2.3 Comparaison du temps de simulation du décodage d une image MPEG4 Le développement matériel consiste donc en la création ou la réutilisation d une série de modèles de composants, testés et assemblés entre eux jusqu à obtenir une description synthétisable de la plateforme. Le processus de synthèse permet ensuite l obtention d une description au niveau portes logiques, qui après des derniers tests et optimisations peut être envoyé en fabrication pour la création des masques et ainsi graver le silicium de la puce. 2.3 TLM et IP-XACT : accélérateurs du flot Nous allons maintenant revenir un peu plus en détails sur deux technologies, grandement déployées chez STMicroelectronics visant à accélérer ce flot de conception : la modélisation transactionnelle et le format IP-XACT. 20/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

21 2.3. TLM et IP-XACT : accélérateurs du flot Présentation de la modélisation transactionnelle Présentation générale La modélisation transactionnelle peut être considérée comme la première représentation des composants matériels après le partitionnement Logiciel/Matériel. Du fait de son niveau d abstraction élevé, il permet de concevoir une représentation simulable d un système sur puce complet beaucoup plus rapidement qu au niveau RTL. Il existe plusieurs niveaux de détails au sein de la représentation transactionnelle (identifiés par exemple dans [97, 26]). Chez STMicroelectronics les deux principaux niveaux de détails utilisés sont la modélisation PV (pour Programmer s View) et PVT (Programmer s View + Timing). Le principe de base de la modélisation transactionnelle est de fournir une représentation fonctionnelle exécutable de chacun des composants. Par représentation fonctionnelle, il est entendu que les composants doivent fournir les mêmes entrées-sorties que le composant réel, comme par exemple le décodage d une image MPEG4. Afin de pouvoir représenter fidèlement ces entrées-sorties, et de pouvoir être utilisés pour la programmation du logiciel embarqué, les composants TLM doivent présenter les mêmes interfaces que les composants réels, notamment en termes de points de connections (interfaces de bus) et de configuration par l intermédiaire des registres (dont nous présenterons le fonctionnement plus en détails dans la section 5.3). Le mécanisme d adressage permettant d accéder à un registre d un composant particulier du système est donc respecté, et les éléments sont de ce fait interconnectés entre eux par un type particulier de composant, le bus de communication. Cependant, le respect de la réalité s arrête là. Comme nous l avons dit précédemment, afin d accélérer la vitesse de simulation la notion d horloge a été retirée. Ainsi dans les modèles PV purement fonctionnels, l exécution d un calcul à l intérieur d un composant, où le transfert d une quantité arbitraire de données à travers les bus de communications (i.e. les transactions) sont considérés comme instantanés. Dans les modèles PVT, la notion de temps peut tout de même être introduite en associant à une opération une durée approximative (qui se traduit par la suspension des processus pour la durée estimée)[34]. Le langage le plus couramment utilisé pour l implémentation et l exécution de modèles transactionnels est le désormais standard IEEE SystemC [95], défini par l Open SystemC Initiative (OSCI 4 ). Il s agit en réalité d une bibliothèque de classes C++ permettant la création rapide de modules représentant les composants, accompagnée d un noyau de simulation permettant de recréer le parallélisme afin de représenter le fait que les composants exécutent chacun des traitements simultanés. La modélisation transactionnelle s appuye de plus sur d autres classes spécifiques, elles aussi définies par l OSCI, dont le processus de standardisation est toujours en cours [127]. Le fait que SystemC-TLM soit basé sur le C++ facilite son intégration dans le flot de conception. En effet, il devient possible de récupérer les algorithmes des modèles fonctionnels généralement écrits en C ou C++, en les encapsulant à l intérieur de la coquille que représente un module SystemC. Il ne reste alors plus qu à définir comment cet algorithme interagit avec le reste du composant en échangeant par exemple ses données d entrée-sortie par l intermédiaire des registres ou des ports, ou en le synchronisant avec d autres algorithmes s exécutant en parallèle par l intermédiaire des processus et des événements SystemC. Sébastien Revol Thèse de doctorat 21/161

22 Chapitre 2. La conception des systèmes sur puce FIG. 2.4 Utilisations de la modélisation transactionnelle Utilisation du TLM Le niveau d abstraction transactionnel a été introduit au début des années 2000 afin d accélérer le processus de conception des systèmes électroniques. La figure 2.4 résume les utilisations que l on peut faire de cette modélisation, en distinguant les modèles purement fonctionnels (PV) et les modèles temporisés (PVT). Les modèles fonctionnels sont utilisés pour : la vérification fonctionnelle : en implémentant une fonctionnalité identique aux composants réels, les modèles TLM permettent de construire rapidement des systèmes de référence. Il permettent donc de valider la spécification de ce qui est attendu des composants, mais aussi de comparer ultérieurement dans le processus de conception que les composants de niveaux de précision supérieurs fournissent de manière observable le même résultat. le développement du logiciel embarqué : comme nous l avons dit précédemment, en fournissant aux développeurs une vue de la plateforme identique à celle d un circuit réel, avec de plus une vitesse de simulation se rapprochant de la vitesse réelle, les modèles PV rendent possible le développement anticipé du logiciel embarqué, qui n a plus besoin d attendre la réalisation finale de la puce. Ce développement est d autant plus favorisé car contrairement à un système réel opaque dont il est difficile de connaître en détail son état interne, les simulateurs, par le mécanisme de débogage offrent une visibilité totale, permettant de mieux comprendre les interactions entre le logiciel et le matériel. Co-simulation : nous avons déjà détaillé ce point : la modélisation TLM permet de construire très rapidement des bancs de tests pour les composants RTL qui sont alors simulés dans un environnement proche de la réalité. Les modèles temporisés sont eux plus utilisés pour : l optimisation du logiciel embarqué : dans les systèmes temps réels, le temps d un traitement ou la durée d une communication sont des informations importantes pour valider que le logiciel s exécutera dans le temps qui lui est imparti. Alors que les modèles PV ne permettent qu un développement fonctionnel du logiciel (représentant en général sa grande majorité), les informations temporelles ajoutées dans les modèles PVT permet de prendre en compte cette dimension. l étude architecturale : là aussi les modèles PV ne sont d aucune utilité pour l analyse d architecture. En effet trop idéalisés, les transactions étant immédiates et de grandeurs arbitraires, 4 22/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

23 2.3. TLM et IP-XACT : accélérateurs du flot il est impossible d en extraire des informations sur les performances du système. Dans les modèles PVT, la taille des données transférées ainsi que les durées de leur transfert peuvent être fixés, et la notion de pipelining peut être représentée. De plus la durée des traitements peut aussi être estimée, permettant au final à l architecte d avoir une bien meilleure idée des performances d une plateforme donnée Présentation du formalisme IP-XACT Le standard IP-XACT est un autre moyen d accélérer le flot de conception des systèmes sur puce. Conçu par un groupement d acteurs majeurs de l industrie électronique, regroupés sous le consortium SPIRIT 5, le but principal de ce format est de favoriser l échange et la réutilisation de composants des systèmes sur puces. En effet, le format final d un composant est généralement sa description dans un langage d implémentation synthétisable tel que le VHDL et Verilog. Les informations sur les interfaces de ces implémentations, définissant leur connectivité et donc leur intégrabilité dans un système sont noyées dans les détails du code. Il est alors nécessaire d ouvrir ces fichiers et de les interpréter pour savoir si tel composant peut être connecté à tel autre, et ces connections sont alors à faire à la main en retrouvant quel signal entrant ou sortant d un composant doit être connecté à tel autre. Le but premier du standard IP-XACT est donc de faciliter cette interprétation en encapsulant ces implémentations dans une description basée sur le langage XML [29] (cf. section pour une présentation plus détaillée de ce langage). Ainsi en identifiant d une manière facilement lisible par un ordinateur ces informations sur les interfaces des composants, il devient possible d utiliser des outils graphiques pour manipuler et interconnecter ces composants. Ces outils CAD (pour Computer Aided Design) peuvent alors générer automatiquement l implémentation RTL de la netlist instanciant et interconnectant physiquement les différents composants Par extension, le consortium SPIRIT a cherché à identifier et regrouper un maximum de caractéristiques des composants matériels le plus indépendamment possible du langage et du niveau d abstraction des composants afin de favoriser le plus possible l automatisation des mécanismes récurrents dans la conception de systèmes sur puce. La figure 2.5 présente l architecture générale des fichiers impliqués dans un processus IP-XACT. 5 Sébastien Revol Thèse de doctorat 23/161

24 Chapitre 2. La conception des systèmes sur puce FIG. 2.5 Architecture des fichiers IP-XACT On peut voir que les principaux fichiers XML définis par le standard sont : spirit : component : c est le fichier qui encapsule les implémentations des composants. Il fait office de spécification du composant, et peut en réalité encapsuler plusieurs implémentations différentes, dans différents langages. Il peut aussi référer vers des spirit :design pour spécifier une vue hiérarchique d un composant, en réalité constitué d instances de sous-composants. Comme on le voit, ces fichiers peuvent être importés dans des outils CAD. spirit : design : c est le fichier qui permet de définir un système comme un assemblage d instances de composants. C est principalement ce type de fichiers qui peut être créé et édité dans un outil CAD à partir des composants importés. spirit : busdefinition : ce type de fichier permet d identifier les types des protocoles de communications entre composant. Il spécifie de plus comment doivent être constituées en termes de ports les interfaces des composants qui veulent être interconnectés via ce protocole. Il est donc utilisé pour typer les interfaces des composants définis dans les spirit :component et permet de contraindre les interconnections dans un spirit :design. spirit : generator : ce dernier type de fichier permet d encapsuler des exécutables dans une description XML. Ces exécutables peuvent être des outils permettant de configurer un type particulier de composant au moment de son instanciation, tel qu un bus de communication qui peut être généré, en incluant son algorithme de décodage une fois que tous les composants lui sont connectés et que leur adresse est spécifiée. Cependant, ces exécutables peuvent aussi être des programmes de génération d un nouveau composant, tel que la description RTL de la plateforme instanciant tous les composants du design. On voit qu une interface standard, appelée TGI (pour Tight Generator Interface) a été définie pour permettre à n importe quel outil conforme au standard de communiquer avec n importe quel générateur accompagné de sa description IP-XACT, quelque soit son langage d implémentation. On voit ainsi que le standard IP-XACT a été réalisé pour briser les frontières entre les différents acteurs de l électronique : un intégrateur peut ainsi récupérer des composants venant de différents fournisseurs, en utilisant n importe quel outil CAD conforme au standard, et pouvant appeler des outils spécialisés fournis par d autres entreprises. Initialement conçu pour manipuler des descriptions au niveau RTL, sa dernière version (1.4) inclut 24/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

25 2.4. Les limites actuelles de l accélération du flot de conception la possibilité d utiliser des composants implémentés dans un niveau d abstraction supérieur, et plus particulièrement la modélisation TLM 6. Ceci conclut notre présentation du standard IP-XACT. Dans le chapitre 5, nous reviendrons plus en détail sur certains des mécanismes mis en jeu dans son utilisation. 2.4 Les limites actuelles de l accélération du flot de conception A travers ce chapitre nous avons pu aborder différentes méthodes permettant d accélérer le processus de conception des systèmes sur puce. La modélisation SystemC-TLM raccourcit beaucoup ce flot, en permettant un développement anticipé du logiciel embarqué, en facilitant la vérification des composants ou en apportant une aide précieuse pour l analyse d architecture. De même le standard IP-XACT favorise la réutilisation de composants, et automatise certaines étapes d intégration et de configuration de ces composants. Certaines informations contenues dans une description IP-XACT peuvent de plus être utilisées pour le développement du logiciel embarqué, et des générateurs spécifiques peuvent être utilisés pour le configurer pour un type de matériel précis. Cependant, de nombreux points semblent pouvoir être encore améliorés. Par exemple, le formalisme des spécifications des systèmes, que ce soit dès le début du flot pour l expression des besoins du client ou à des niveaux inférieurs pour la spécification de chacun des composants matériels, reste généralement un format textuel classique. Ainsi la communication entre différentes équipes de développement ne se fait que par lecture et écriture de ces spécifications papier. Par exemple, les personnes chargées de créer un modèle fonctionnel du système devront interpréter les spécifications du client pour comprendre les fonctionnalités attendues. Un architecte devra comprendre et interpréter ces mêmes spécifications pour savoir les contraintes qui lui sont imposées. A l issu du partitionnement logiciel/matériel, ces fonctionnalités sont retranscrites dans des nouvelles spécifications pour chacune des deux branches de développement. Pour le matériel, il faudra donc créer de nouvelles spécifications pour un nouveau composant, et utiliser celles accompagnants des composants existants pour procéder à l intégration. Ces spécifications sont alors lues par les développeurs logiciels qui doivent écrire les pilotes (Drivers) dialoguant avec le matériel. Elles doivent aussi être comprises par les développeurs de modèles RTL pour concevoir ces composants. Enfin les équipes de vérification, elles aussi, doivent interpréter ces spécifications pour le développement de modèles TLM, et pour essayer de déterminer des plans de tests permettant de détecter d éventuelles erreurs dans le codage des composants. Autant de lecture de spécifications, autant d interprétations possibles, source à chaque fois d erreur de modélisation et nécessitant aux utilisateurs de savoir où précisément trouver l information nécessaire. Un développeur de modèle TLM utilise actuellement les mêmes spécifications que le développeur de modèles RTL. Il doit donc lui-même faire le tri entre les informations qui sont judicieuses pour ce niveau d abstraction et celles relevant du niveau inférieur. Ce processus est d autant plus complexe lorsque l on sait que le même modèle, réalisé par une tierce personne peut être utilisé par une équipe de vérification et une équipe de développement logiciel, qui ne cherchent pas forcément à mettre en avant les mêmes propriétés du composant. Un autre problème au cours de ce flot est la disparité et la non-interopérabilité des formats mis en jeux. Les spécifications papier en sont bien entendu un exemple flagrant, mais même si des standards tels qu IP-XACT tendent à l améliorer en proposant une uniformisation du formalisme d échange des composants, de nombreux outils spécifiques à un point particulier du processus de conceptions n offrent pas d interopérabilité avec les autres, nécessitant la réécriture multiple des informations. 6 En pratique, STMicroelectronics utilise déjà IP-XACT pour la manipulation de composants TLM en se basant sur le mécanisme d extension fourni par le standard. Sébastien Revol Thèse de doctorat 25/161

26 Chapitre 2. La conception des systèmes sur puce C est par exemple le cas pour l analyse d architecture, où des parties de modèles fonctionnels peuvent être écrits à l aide d un logiciel comme Matlab, d autre directement en C etc. Les spécificités issues de l analyse de ces modèles, en termes d exigences de temps de calcul (Profiling) seront fournies dans un format propre à l outil utilisé pour cette analyse. Ces informations sont alors à rentrer dans l outil qui permet d effectuer les calculs pour aider au choix d une architecture. Cet outil devra aussi intégrer des informations sur les modèles de plateformes construits pour effectuer la projection, qui ne sont malheureusement pas contenues dans des descriptions IP-XACT. On voit ainsi qu il sera nécessaire de recréer un modèle de plateforme finale issue de ce partitionnement pour l envoyer en développement, ou pour constituer un modèle PVT pour réaliser une simulation temporisée. De même les résultats de cette simulation seront analysés par un nouvel outil, et il sera encore une fois nécessaire de retranscrire ces informations dans les modèles d analyse. Comme on peut le voir, même si la partie basse du flot a pu être grandement automatisée, plus on remonte ce flot, moins cette automatisation est présente et plus les formats sont hétérogènes. Cependant, depuis quelques années, la recherche pour la conception des systèmes électroniques s est orientée vers l utilisation de techniques issues du génie logiciel : l Ingénierie Dirigée par les Modèles et le langage de modélisation unifié UML. Ces techniques permettent en effet d apporter à l utilisateur un lanagage adapté à leur besoin, et ouvrent la porte à de nombreuses possibilités d automatisation. Dans le prochain chapitre, nous allons présenter les concepts de cette ingénierie. Puis dans le chapitre suivant, nous étudierons les différentes initiatives basées sur cette technologie cherchant à combler les défauts que nous venons de mettre en évidence dans ce chapitre. Nous concluerons enfin sur les points qui restent à lever, nous ayant conduit à la proposition de notre contribution. 26/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

27 Chapitre 3 Présentation générale de l Ingénierie Dirigée par les Modèles Sommaire 3.1 Modèles et Méta-modèles La notion de modèle La notion de méta-modèle Quatre niveaux d instanciation Apports de l IDM Définition de langages Le meilleur langage dans la meilleure syntaxe Les langages spécifiques au domaine et les langages généralistes Automatisation fournie par l IDM Aspect méthodologique Les différents espaces technologiques W3C et XML Les standards de l OMG pour l IDM Présentation de l Unified Modeling Language Historique Les différents diagrammes Extensibilité d UML : la notion de profil UML et IDM comme support de méthodologies Les bénéfices de l IDM et UML Un langage adapté aux besoins de l utilisateur Diminution du nombre de formats Interopérabilité des formats Automatisation grâce à l IDM Réutilisation des spécifications Conclusion La disparité des langages impliqués dans les étapes du flot de conception des SoC est une des causes du fossé technologique constaté dans la conception des SoC. Elle constitue en effet un facteur limitant la communication entre les différentes équipes impliquées dans ce processus, restreignant de plus les possibilités d automatisation. Pour cette raison la recherche dans le domaine de 27

28 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles l électronique s est intéressée récemment à l Ingénierie Dirigée par les Modèles. Le but de cette discipline est précisément de faciliter la définition et la manipulation de langages, offrant de nombreuses possibilités d automatisation. Plus particulièrement, le langage de modélisation unifié (UML) nous donne le moyen d utiliser un formalisme unique hautement spécialisable pour de nombreuses activités, telles que celles que l on retrouve dans la conception des systèmes sur puce. Dans ce chapitre, nous allons tout d abord introduire les concepts de base sur lesquels reposent l IDM, ainsi que diverses techniques d automatisation qu elle fournit. Par la suite, nous nous intéresserons plus particulièrement au langage UML, et mettrons en évidence les avantages que peut procurer son utilisation dans un flot de conception. 3.1 Modèles et Méta-modèles L Ingénirie Dirigée par les Modèles, apparue vers la fin des années 1990, s est particulièrement développée lors de la parution de l initiative Model Driven Architecture [73] de l Object Management Group. Comme son nom l indique, l IDM est une approche dont l élément clé est la notion de modèle La notion de modèle Le but d un modèle est de proposer une représentation simplifiée de l élément modélisé, en omettant certains détails et ne laissant apparaître que les informations qui seront utiles à l utilisateur du modèle. Dans [25], Jean Bezivin fournit une présentation très détaillée des principaux concepts de l IDM. Il illustre notamment la notion de modèle en nous donnant l exemple de la carte géographique. En effet une carte est un modèle de la réalité, une simplification du monde réel dans lequel on ne va laisser apparaître de manière compréhensible qu un nombre limité d informations. Il est alors possible de faire plusieurs modèles de la même réalité, chacun portant sur un domaine précis. Ainsi une personne désirant obtenir des informations sur un territoire va alors utiliser différents types de cartes suivant qu elle s intéresse à la géopolitique, l économie, la géologie ou encore la circulation routière. Dans un domaine plus proche de cette thèse, les différentes représentations d un circuit électronique que l on retrouve au cours d un flot de conception des circuits peuvent toutes être considérées comme des modèles du circuit final. Tout particulièrement, les modèles SystemC sont des représentations simplifiées des vraies puces constituées de silicium, dans lesquelles un grand nombre de détails ont été omis. Là encore, en utilisant un même formalisme (SystemC), on va pouvoir représenter différents types de modèles d un même composant électronique ne contenant pas les même informations, suivant le niveau d abstraction souhaité, chacun ayant pour but des types d analyse différentes (par exemple en TLM : PV pour la fonctionnalité, PVT pour avoir des informations de timing etc.). Il est de plus intéressant de noter qu un modèle ne représente pas forcément un système réel, et qu il est notamment possible de réaliser le modèle d un autre modèle. C est par exemple ce qui arrive dans le format IP-XACT. En effet ce dernier contient des informations servant à abstraire les détails d un modèle tel qu une description SystemC (cela peut d ailleurs être un autre langage de modélisation du matériel que SystemC, tel que vhdl ou Verilog). Ainsi une description IP-XACT va porter dans un formalisme standard des informations qui étaient enfouies dans le code des modèles d implémentation, informations qui pourront par la suite être utilisées par des outils spécialisés pour faire des nombreuses opérations, tel que nous l avons décrit dans L IDM caractérise explicitement la relation qu il existe entre un élément modélisé et son modèle, que nous appellerons estreprésentépar. Celle-ci est la première des deux relations fondamentales 28/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

29 3.1. Modèles et Méta-modèles sur lesquelles reposent les principes de l Ingénierie Dirigée par les Modèles La notion de méta-modèle La deuxième de ces relations est appelée estconformea. Elle s applique entre le modèle et ce qui définit quelles sont les informations que l on va retrouver dans ce modèle. Ainsi, pour reprendre l exemple de la carte, celle-ci doit être conforme à une légende. En effet c est cette légende qui va définir quels types de données on va retrouver dans une carte, telles les villes, les différents types d axes routiers, etc. D une manière générale l IDM appelle méta-modèle toute représentation visant à définir les éléments que l on va retrouver dans un modèle ainsi que les relations qu il existe entre ces éléments, de telle sorte que tout modèle estconformea un méta-modèle. Dans le cas de SystemC, la création de composants, de ports et d interfaces se fait par l instanciation de classes C++ prédéfinies par le standard [95]. Cet ensemble de classes, définit en quelque sorte le méta-modèle de tout modèle SystemC, et l on saura par exemple que toute instance d une classe sc module sera la représentation SystemC d un composant. Il faut noter que dans l IDM, tout est modèle. En particulier un méta-modèle est lui aussi un modèle, et doit donc être conforme à son méta-modèle. Par exemple, chez un éditeur de cartes, les différents types de cartes possèdent très souvent le même type de légende, qui consiste généralement en l association d une ou plusieurs formes géométriques et d un texte expliquant à quoi correspond cette forme. Ainsi si toutes les légendes des différentes cartes sont conformes à un même méta-modèle de légende, l utilisateur ne sera pas perdu d une carte à l autre, il saura tout de suite lire la légende, et comprendre par la suite quelles sont les informations contenues dans la carte. En résumé, on voit donc que le méta-modèle de la légende d une carte définit les notion de couleurs, formes géométriques et de texte, et que pour un type particulier, tel qu une carte routière, une légende particulière conforme à ce méta-modèle introduira la notion de ville, de route nationale, départementale etc. La carte elle-même sera alors un modèle conforme au méta-modèle ainsi défini Quatre niveaux d instanciation La relation estconformea pourrait donc s appliquer un nombre indéfini de fois, chaque métamodèle étant lui-même un modèle conforme à un méta-modèle supérieur. Cependant, on comprend aisément qu un trop grand nombre de ces couches pourrait être inefficace, rajoutant de la complexité plus difficilement exploitable. Ainsi il semblerait que dans le domaine de l informatique, le nombre optimal de niveaux soit de 4 en incluant le niveau M0 identifiant le système à modeliser comme le montre la figure 3.1. Sébastien Revol Thèse de doctorat 29/161

30 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles FIG. 3.1 Architecture en 4 couches employée par l IDM Pour borner le nombre de couches superposables, on détermine un type de méta-modèle particulier appelé méta-méta-modèle. La particularité de celui-ci est qu il est capable de s auto-décrire : il est donc conforme à lui-même. En effet, un méta-méta-modèle est un méta-modèle introduisant des notions permettant de définir des méta-modèles : on va donc pouvoir utiliser ces notions pour définir le méta-méta-modèle. 3.2 Apports de l IDM On voit donc qu implicitement les notions de modèle et de méta-modèle ont toujours existé. En les identifiant clairement, l IDM place le modèle au centre de son approche pour l ingénierie logicielle. En relevant le niveau d abstraction auquel travaille l utilisateur, celui-ci se focalise sur les concepts qu il veut manipuler et bénéficie par la suite de nombreux outils lui permettant d automatiser de nombreuses étapes propres à l ingénierie logicielle, comme la création de langages pour exprimer ces concepts, la génération de code ou encore la transformation de modèles Définition de langages La notion de méta-modèle dans l IDM est assez proche de la notion de grammaire dans la théorie classique des langages. En effet, les grammaires classiques, telles que l EBNF [108], permettent d identifier les concepts que l on va exprimer à travers le langage, mais aussi les règles de syntaxe de ce langage, c est à dire la façon correcte de construire les phrases de ce langage. Le méta-modèle lui, ne définit que les éléments que devra exprimer le langage, et les relations qu il peut y avoir entre eux, comme la notion de composition ou de référence, voire plus selon le type de méta-méta-modèle utilisé. Il définit donc quels éléments devra comporter une phrase bien construite, mais pas comment ils seront exprimés : on parle de syntaxe abstraite. L avantage du méta-modèle est qu il permet généralement de mieux exprimer les relations entre les différents concepts d un langage. De plus il devient aussi possible d associer à un même méta-modèle différentes syntaxes concrètes. Ces syntaxes pourront être textuelles, mais aussi graphiques. 30/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

31 3.2. Apports de l IDM FIG. 3.2 Exemple de méta-modèle Pour illustrer ceci, considérons la figure 3.2. Elle décrit un méta-modèle permettant de modéliser d une manière simpliste la structure d un système électronique. Ce méta-modèle est exprimé en MOF [84], un méta-méta-modèle que nous présenterons mieux dans la section L élément racine de ce méta-modèle est la notion de système. Un système possède un nom, et peut être composé de deux types d éléments différents : des composants et des connections. La relation de composition est exprimée via l association avec un diamant noir, et l étoile présente au bout de chacune de ces associations spécifie que le nombre des éléments associés est indéfini. Un composant possède aussi un nom, et peut être composé de un ou plusieurs ports. Un port possède aussi un nom, et un autre attribut appelé direction. Celui-ci est de type TypeDeDirection, un énuméré qui peut avoir pour valeur Entrant, Sortant ou Bidirectionnel. Enfin les connections d un système sont des éléments ayant deux attributs, cible et source, tous les deux de type port : une connexion se fait donc entre deux ports. FIG. 3.3 Exemple de modèle utilisant une syntaxe graphique La figure 3.3 est maintenant un exemple de modèle instanciant ce méta-modèle via une syntaxe graphique. Une représentation graphique de chaque élément du méta-modèle a été ainsi définie. On voit donc dans la figure une instance de Système appelée MonSystème, lui-même instanciant deux composants interconnectés. On remarquera que la syntaxe du langage de cette illustration n est pas entièrement graphique, car la définition des attributs d un port est faite suivant une syntaxe textuelle définie : < direction >:< nom >, la direction s écrivant in pour Entrant, out pour Sortant et inout pour bidirectionnel. Enfin la figure 3.4 représente une autre instanciation de ce méta-modèle, définissant les mêmes composants que pour la figure 3.3 mais cette fois-ci à l aide d un langage textuel. Sébastien Revol Thèse de doctorat 31/161

32 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles System MonSystème{ Component Composant1{ Port in portc1; } Component Composant2{ Port out portc2; } Binding Composant2.portC2 Composant1.portC1; } FIG. 3.4 Exemple de modèle utilisant une syntaxe textuelle Il est à noter qu en plus d attribuer une syntaxe concrète à un méta-modèle, la définition complète d un langage se fait aussi en lui associant une sémantique. Le rôle de celle-ci est de préciser le sens des concepts introduits par le méta-modèle. L IDM n apporte à l heure actuelle pas de solution précise sur ce point, mais on peut dénombrer trois manières d y parvenir : la sémantique dénotationnelle, qui associe les termes du langage à un contexte mathématique formel, la sémantique axiomatique qui transforme le langage en un ensemble de propriétés logiques, et enfin la sémantique opérationnelle, qui définit l exécution d un langage dans une machine abstraite Le meilleur langage dans la meilleure syntaxe Cette dissociation entre la syntaxe abstraite et concrète, jumelée à la possibilité de pouvoir créer différents modèles d un même système permet de choisir la meilleure représentation convenant au but de l utilisateur. Par exemple, la syntaxe graphique, en rajoutant des dimensions supplémentaires via la géométrie et les couleurs rend généralement un langage plus expressif et synthétique, permettant au modélisateur de se donner une meilleure représentation, plus intuitive, de ce qu il est en train de modéliser. En revanche, une syntaxe textuelle est plus facilement utilisable, ne nécessitant pas d éditeur spécialisé, et c est de plus cette dernière qui est utilisée pour le stockage des informations dans un fichier compréhensible par un programme. En effet, un programme ne sera par exemple pas capable de comprendre le contenu d un diagramme comme celui de la figure 3.2 s il est stocké dans un format graphique tel que JPEG ou PNG. C est le rôle des éditeurs spécialisés de transformer la syntaxe graphique en syntaxe textuelle qui pourra par la suite être exploitée par différents programmes, comme le fait par exemple un éditeur UML [91] qui transcrira la modèle en XMI [92] (cf. section 3.3.2) Les langages spécifiques au domaine et les langages généralistes On retrouve deux principales approches dans l élaboration de langages, et plus particulièrement lorsqu il s agit de langages graphiques. La première approche consiste à créer un méta modèle, c est à dire une syntaxe abstraite, pour chaque domaine que l on souhaite modéliser (Domain Specific Language ou DSL). En y associant une ou plusieurs syntaxes concrètes et une sémantique propre à ce domaine, on crée alors un langage sur mesure, collant parfaitement aux concepts que l on désire représenter. Un exemple d un tel langage pourrait être le standard XML IP-XACT, qui a été développé pour répondre aux besoins de l électronique. Cependant, l inconvénient d un tel langage, surtout lorsqu il est graphique, est outre le fait qu il nécessite un apprentissage particulier de ses concepts, leur sémantique et leur syntaxe, il requiert de plus la création d éditeurs spécialisés. L autre approche, consiste à créer des langages de modélisations dits généralistes. C est par exemple le cas de l Unified Modeling Language [91] (cf section 3.3.2), qui comme son nom l indique est une unification 32/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

33 3.2. Apports de l IDM des différentes tendances de modélisation que l on retrouve de le domaine de l ingénierie logicielle. Ainsi la particularité d un langage généraliste est d être constitué d un méta-modèle couvrant un large spectre de concepts de la modélisation logicielle, comme les spécifications, la description structurelle ou comportementale d un système. Les avantages et inconvénients de cette approche sont alors les duaux de ceux des DSL. En effet, il évite la multiplication des langages, et donc de leur apprentissage, (un langage comme l UML est maintenant largement enseigné dans les écoles d informatique) et favorise ainsi la communication des informations. De plus, il n est plus nécessaire de multiplier les éditeurs, tous les aspects d un système pouvant être couverts dans le même langage. En revanche, le revers de la médaille est alors que le méta-modèle de ce type de langage devient complexe à comprendre dans son ensemble, avec une sémantique parfois (volontairement) vague, et peut introduire une complexité superflue lorsqu il s agit de modéliser un domaine relativement simple. De plus lorsque l on touche à un domaine très spécifique, il se peut que le langage ne soit pas suffisamment généraliste, et que la modélisation des concepts visés devienne fastidieuse à l aide de ce langage. Nous verrons par la suite qu UML palie en partie à cette faiblesse en proposant un mécanisme de spécialisation par le biais de profils, en proposant un moyen standard d étendre son méta-modèle. Quoiqu il en soit, le choix entre l utilisation d un DSL ou d un langage généraliste est discutable, chacun présentant ses atouts. Ce choix devra se faire en tenant compte des contraintes liées au contexte dans lequel le langage sera utilisé, comme par exemple l existant, les possibilités de formation, ou encore la compatibilité des concepts que l on désire modéliser avec un langage généraliste. Dans notre cas nous verrons par la suite que le choix a été fait d adopter UML pour une grande partie de notre flot, tout en y intégrant la possibilité d interagir de manière complémentaire avec le DSL IP-XACT, grâce aux différentes techniques que proposent l ingénierie des modèle Automatisation fournie par l IDM Un des principaux atouts de l Ingénierie Dirigée par les Modèlesest la grande possibilité d automatisation qu elle nous fournit. En effet de nombreuses méthodes ont été développées pour assister le développement logiciel et tirant partie de la formalisation des niveaux de modélisation que propose l IDM. Les principaux types d outils que l on retrouve sont les suivants : Implémentation des couches Méta Différents environnements d édition logicielle, tels que la plateforme Eclipse [24], NetBeans [1] ou encore Visual Studio [32] proposent une implémentation logicielle de la couche M3, en représentant les concepts d un méta-méta-modèle à l aide d un langage exécutable tel que Java. De la sorte, il devient possible de manipuler ces concepts, et de créer des instances dynamiques, vivantes, de méta-modèles par le biais d éditeurs spécialisés par exemple. De plus ces environnements proposent généralement des générateurs de codes capables de parcourir ces instances et les informations qu elles contiennent, permettant de créer une implémentation logicielle de la couche M2 que l on vient de définir. Les classes ainsi obtenues seront à leurs tours utilisables pour créer des instances dynamiques des modèles conformes au méta-modèle que l on vient de définir Sérialisation et désérialisation La sérialisation d un modèle consiste en la traduction d une instance dynamique de celui-ci dans une syntaxe concrète textuelle permettant de stocker de manière persistante les informations que contient cette instance. Par exemple, lorsque l on crée une instance de méta-modèle à l aide d un Sébastien Revol Thèse de doctorat 33/161

34 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles éditeur spécialisé comme nous venons de le présenter ci-dessus, la sérialisation va permettre de stocker dans un fichier les informations que l on vient de rentrer. Inversement, la désérialisation permettra de recréer cette instance dynamique à partir du fichier obtenu. Un exemple de format de sérialisation est le XMI (cf section 3.3.2) qui définit une syntaxe concrète pour le méta-méta-modèle MOF [84] Génération d éditeurs/compilateurs Les environnements IDM associent donc de manière automatique une syntaxe concrète à un méta- (méta-)modèle. Cependant il existe aussi des outils permettant aussi de leur en associer une autre. Par exemple les outils comme Textual Concrete Syntax (TCS [58]), ou Xtext de la suite OpenArchitectureWare [125] vont permettre de définir une syntaxe concrète et de l associer à un méta-modèle. Il en résultera la création automatique des sérialiseurs/désérialiseurs dans cette nouvelle syntaxe, ainsi que celle d éditeurs spécialisés proposant par exemple la coloration syntaxique, l auto-complétion, ou encore la validation syntaxique. De même, des outils comme le Graphical Modeling Framework d Eclipse (GMF [126]) ou VisualStudio vont permettre la définition d une syntaxe concrète graphique pour un méta-modèle donné. De cette association résultera alors la génération automatisée d éditeurs graphiques permettant d instancier les concepts du méta-modèle Génération de code Nous l avons vu, les environnements IDM utilisent souvent des générateurs de code. Ils fournissent aussi le moyen d en créer de nouveaux. Contrairement au processus de sérialisation, qui n est qu une simple reformulation dans une syntaxe donnée des instances de concepts définis dans un métamodèle, la génération de code au sens large consiste en la récupération des informations contenues dans un modèle, et en leur injection dans différents fichiers textuels après une éventuelle analyse. Par exemple l outil GMF introduit précédemment a été réalisé à l aide d un outil de génération de code. Celui-ci parcourt le modèle d association du méta-modèle à sa syntaxe graphique, et crée en fonction des informations contenues dans celui-ci les différents fichiers implémentant l éditeur graphique résultant. Des exemples de tels outils sont Acceleo [82], Xpand de la suite OpenArchitectureWare [125] ou encore Java Emission Template (JET)[39] Saisie et validation de contraintes Les langages de méta-méta-modélisation permettent de définir les concepts que l on va vouloir manipuler dans un langage, ainsi que les relations qu il existe entre ces concepts. Cependant, ils sont parfois insuffisants pour exprimer certaines contraintes que l on désire imposer sur ces concepts. Considérons par exemple le méta-modèle de la figure 3.2. Nous y avons défini le fait qu une connexion pointait vers une source et une cible, tous deux étant des ports. Nous avons aussi défini qu un port avait un attribut direction qui pouvait être soit entrant, sortant ou bidirectionnel. Imaginons maintenant que nous voulions introduire une contrainte supplémentaire s énonçant de la manière suivante : la direction d un port source doit obligatoirement être sortante ou bidirectionnelle et celle d un port cible doit être entrante ou bidirectionnelle Le langage MOF que nous avons utilisé dans notre exemple ne permet pas d exprimer cette contrainte. C est pour cela que des langages spécifiques de contraintes tel que l Object Constraint Language [88] (cf section 3.3.2) ont été introduit. Ainsi l OCL va permettre d associer des contraintes 34/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

35 3.2. Apports de l IDM supplémentaires aux éléments d un (méta-)modèle, et celle que nous venons de définir pourra s exprimer sous la forme d un invariant dans le contexte d une connexion : context Connection inv: self.source.direction<>#entrant and self.cible.direction<>#sortant Les environnements de modélisation proposent alors différents types d outils pour exprimer et associer ces contraintes à des éléments d un méta-modèle, ainsi que pour les évaluer dynamiquement ou statiquement lors de l édition ou du chargement d un modèle, afin d informer l utilisateur que son modèle n est pas conforme le cas échéant Transformation de modèles La transformation de modèles est probablement une des opérations qui révèle le plus les possibilités d automatisations de l IDM. Son principe consiste en l élaboration de règles de correspondance entre des méta-modèles d entrée et de sortie. Comme le montre la figure 3.5, ces règles sont contenues dans un modèle de transformations, conforme à un méta-modèle de transformation. FIG. 3.5 Principes de la transformation de modèles C est le rôle du moteur de transformation de charger un modèle conforme au méta-modèle d entrée (ModèleA), et d interpréter les règles pour créer des instances d éléments du méta-modèle de sortie (ModèleB). Dans le cas de notre exemple, figure, la transformation ne prend en entrée et en sortie qu un seul modèle. Il peut en être autrement, et il est ainsi possible d avoir plusieurs modèles conformes à différents méta-modèles en entrée comme en sortie, ou alors un unique méta-modèle en entrée et sortie (pour du raffinement de modèle par exemple). Les applications pour les transformations de modèles sont nombreuses : en les associant avec les différents outils que nous venons de présenter (sérialisation, génération de code), il devient plus aisé d écrire des règles de réécriture d un langage vers un autre, favorisant l interopérabilité des formats. Dans le cas d un processus de raffinement d un système, les règles vont pouvoir analyser les modèles d entrée et créer des modèles de sortie dans lesquels des informations propres à un processus métier particulier auront été rajoutées. Les transformations ne sont pas forcément bijectives, mais elles peuvent permettre de créer rapidement des squelettes de modèles à partir des informations contenues dans les modèles d entrée. Il faut Sébastien Revol Thèse de doctorat 35/161

36 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles aussi noter que le fait d énoncer les règles de transformations dans un modèle lui-même conforme à un méta-modèle permet de créer dans transformations de niveau supérieur, dont le modèle de sortie est lui-même une transformation. De nombreux outils de transformation de modèles existent sur le marché, dans différents contextes technologiques. Nous noterons plus particulièrement l outil ATL (Atlas Transformation Language) [59], qui est à ce jour l un des plus puissants d entre eux, et l un des plus proches du standard Query View Transform [87] défini par l OMG Aspect méthodologique Nous venons de le voir, le méta-modèle est au centre de tous les outils développés pour l IDM. En effet c est autour de lui que tout se construit : éditeur, générateur de code, transformation etc. Ainsi tout est fait pour que la manipulation des langages de modélisation soit décomposée en opérations simples et automatisées, avec au centre de celle-ci la connaissance du domaine dans lequel l utilisateur opère : le méta-modèle. Ainsi toute approche IDM commence généralement par la construction ou l étude du méta-modèle qu il désire manipuler, le forçant ainsi à prendre du recul sur les concepts mis en jeu avant de se jeter dans le développement. De cet investissement initial découle une meilleure organisation du développement logiciel qui fera au final gagner du temps non seulement grâce aux nombreuses automatisations qui vont en découler, mais aussi par l évitement de travaux inutiles ou inadaptés. 3.3 Les différents espaces technologiques Il existe dans l état de l art différents espaces technologiques dans lequel les principes de l IDM sont normalisés et mis en pratique. Nous revenons ici sur deux d entre eux, que nous avons exploités au cours de cette thèse : les normes du World Wide Web consortium autour du langage XML, et les standards définis par le l Object Management Group W3C et XML Le World Wide Web Consortium est un organisme visant à standardiser les langages et à définir des bonnes pratiques pour le développement d application Web. Parmi les standards qu il a définis, figure le langage extanded Markup Language (XML). Celui-ci possède la particularité de posséder une syntaxe à la fois simple et très structurée, avec des notions de balises, qui en a fait le langage de prédilection pour le stockage de données, car facilement parcourable par un désérialiseur. Le standard Data Object Model définit la syntaxe élémentaire que doit posséder tout document XML, en introduisant par exemple la notion de namespace, d élément ou encore d attribut, faisant que tout document XML présente le même aspect caractéristique. Par dessus cette première abstraction figure la notion de schéma, successeur de la grammaire DTD. Le schéma XML peut être vu comme un méta-modèle. En effet c est lui qui va permettre de définir comment va être structuré un type de document XML particulier. On peut ainsi grâce à lui définir des types d éléments particuliers, en lui associant des attributs eux aussi typés, mais aussi des sous éléments, des références vers d autres éléments etc. On parle cependant de grammaire XML et non pas simplement de méta-modèle, car du fait de la couche DOM standardisée, un schéma définit à la fois ce méta-modèle, mais aussi la syntaxe dans laquelle le modèle XML correspondant devra être écrit. Il faut noter que conformément aux préceptes de l IDM, un schéma est lui-même un document XML, conforme à une grammaire définie dans le fichier standard schema.xsd, qui est une grammaire XML 36/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

37 3.3. Les différents espaces technologiques FIG. 3.6 Exemple d éditeur de grammaire XML qui décrit comment écrire une grammaire XML. IL s agit donc d un méta-méta-modèle, puisque cette grammaire-là est décrite avec les concepts qu elle définit (schema.xsd estconformea schema.xsd). Dans ce contexte technologique, on retrouve alors différents outils et langages pour exploiter les concepts de l IDM. Des éditeurs graphiques comme celui de la figure 3.6 permettent par exemple de créer et visualiser des grammaires. Des checkers vont aussi permettre de vérifier qu un document XML est bien conforme à sa grammaire. XMLBeans [124] va permettre la génération de classes Java implémentant les concepts définis dans la grammaire (implémentation de la couche M2 cf 3.2.4) ainsi que des sérialiseurs instanciant ces classes et des désérialiseurs correspondants. Des langages comme Xpath [30] permettent de naviguer à travers ces modèles, et le langage XSLT [31] permet d effectuer des transformations de modèles en effectuant des requêtes Xpath sur un document et en en injectant le contenu dans un nouveau fichier XML reformaté Les standards de l OMG pour l IDM L Object Management Group 1 est un autre grand organisme de standardisation, plus particulièrement porté sur les concepts relatifs à l approche Orientée Objet. Avec la publication de l initiative Model Driven Architecture (MDA, [73]) dans la fin des années 1990, cet organisme figure parmi les précurseurs dans l uniformisation des techniques de manipulation des modèles. Il a en effet organisé une refonte de ses standards de modélisation déjà existants pour les rendre conformes à l approche IDM (passage en version 2.x des principaux standards), et en a aussi défini de nouveaux qui font aujourd hui référence en matière d Ingénierie Dirigée par les Modèles. Nous introduisons ici les standards fondamentaux pour la mise en pratique de l IDM, sur lesquels nous nous appuierons dans la suite de mémoire pour décrire notre contribution. 1. Le Meta Object Facility (MOF [84]) : Il s agit du méta-méta-modèle au sommet de la pyramide des langages de l OMG. C est avec celui-ci que vont être définis tous les autres langages standards. 2. Le XML Metadata Interchange (XMI [92]) : ce n est pas à proprement parler la spécification d un langage, mais il s agit de la définition de la transcription des concepts du MOF en XML. 1 Sébastien Revol Thèse de doctorat 37/161

38 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles Elle permet alors de créer une grammaire (schéma) XML pour tout méta-modèle défini en MOF. Ainsi, tout langage défini à partir du MOF possède automatiquement une syntaxe concrète permettant sa sérialisation, et donnant un moyen direct de vérifier qu un modèle fait dans ce langage est bien conforme à son méta-modèle (via les checkers XML). 3. L Object Constraint Language (OCL [88]) : à l origine, l OCL est un langage destiné à exprimer des contraintes sur les éléments d un modèle UML. Le MOF et UML possédant un noyau commun, l OCL définit un sous-ensemble appelé EssentialOCL permettant aussi de spécifier des contraintes sur les éléments d un méta-modèle conforme au MOF. 4. Query View Transform (QVT [87]) : Ce standard définit un langage de transformations de modèles. Il propose deux principales méthodes pour déclarer des règles de transformation : une déclaration opérationnelle et une relationnelle. La première méthode s exprime d un manière proche des langages impératifs classiques, ou l utilisateur doit parcourir le modèle d entrée pour appeler une suite de transformations créant des éléments conformes aux méta-modèles de sortie. La deuxième méthode déclare de règles de correspondance entre les éléments des méta-modèles d entrée et de sortie. 5. MOF Model to Text Transformation Language [86] : Ce standard spécifie un langage de génération de code permettant de parcourir les modèles compatibles MOF, en extraire des informations, et les injecter dans des fichiers textuels. Ce langage se base sur la notion de template, correspondant à des zones de texte pré-écrites, dans lesquelles des mots sont dynamiquement remplacés par le résultat de requêtes sur le modèle. Ceci n est pas une liste exhaustive des différents standards de l OMG pour la modélisation et la méta-modélisation. Il en existe ainsi d autres, définis pour exploiter au mieux les concepts de l IDM. En plus de définir des technologies et langages pour la manipulation de modèles comme ceux que nous venons de présenter, l OMG propose aussi différents langages de modélisation, certains étant spécifiques à un domaine. Cependant l un des langages phares de l OMG est son langage de modélisation généraliste : l Unified Modeling Language. 3.4 Présentation de l Unified Modeling Language Historique L Unified Modeling Language est un langage de modélisation généraliste né de la fusion de différentes initiatives pour la définition de méthodologies de génie logiciel. En effet, le besoin de proposer des méthodes de conception logicielle pour faire face à une complexité des systèmes informatiques déjà croissante est apparu dès les années 1970 [135, 37, 96]. La généralisation de l approche objet dans les années 80 accéléra le nombre de ces initiatives, jusqu à ce que leur nombre atteigne plus de 50 propositions différentes au milieu des années 90. Pour tenter d apporter un peu d unification dans cette effervescence, Rational Software engagea trois auteurs de méthodologies différentes : James Rumbaugh [104], Grady Booch [17, 18] et Ivar Jacobson [57]. S apercevant qu une méthodologie de conception logicielle ne pouvant être universelle et couvrir tous les différents aspects métiers, leur initiative de méthodologie unifiée se transforma en la définition d un langage de modélisation orienté objet, unifiant les différents besoins de représentation que l on retrouvait à travers les diverses méthodologies. Ce travail aboutit en 1996 à la version 0.9 de l Unified Modeling Language. Ce travail fut repris par l OMG pour un processus de standardisation, tout en continuant son évolution, l enrichissant progressivement de nouveaux concepts et aboutissant à sa version actuelle 2.1 en /161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

39 3.4. Présentation de l Unified Modeling Language FIG. 3.7 Organisation des paquetages du méta-modèle d UML Les différents diagrammes Le méta-modèle d UML se décompose en différents paquetages interdépendants que l on peut regrouper en deux principales catégories : ceux relatifs à la description structurelle, et ceux relatifs à la description comportementale. Chaque paquetage introduit alors des concepts, et pour certains d entre eux 2, une ou plusieurs syntaxes graphiques pour les exprimer à travers des diagrammes. L organisation des principaux paquetages est décrite dans la figure 3.7. Voici une brève description de chacun d entre eux, en commençant par la partie structurelle : Classes : Ce paquetage introduit les concepts de base de la modélisation UML, avec en particulier la notion de Class. C est de certains de ses sous-paquetages qu est constitué le noyau commun entre le MOF et UML. Les diagrammes associés sont bien sûr le diagramme de classe, mais aussi le diagramme d objet, destiné à représenter une instanciation particulière des classes définies dans un diagramme de classe. C est aussi sur ces paquetages que s appuie la syntaxe du diagramme de paquetages comme celui de la figure 3.7. Le paquetage (Package) sert à structurer les modèles en regroupant les éléments par catégories, en y associant un espace de nommage. Le diagramme de paquetage décrit alors leur organisation, en décrivant notamment leur différents types d interdépendances. CompositeStructures : Ce paquetage définit une meilleure façon d exprimer la composition entre les classes et leur sous-éléments [16]. Il définit notamment la notion de port et de connecteur, permettant d éditer des diagrammes de structure composite. Comme nous le verrons par la suite, c est celui-ci qui semble le plus adapté pour la description d architecture matérielles. Components : Ce paquetage spécialise le précédent, et permet d apporter les concepts de la programmation orientée composants [23] à UML. Un composant permet de représenter l abstraction d un ensemble de classes accomplissant un groupe de fonctionnalités. Le diagramme de composants permet alors de représenter comment s organise un système constitué de ces abstractions, en mettant en évidence leur communication via des interfaces. 2 Certaines méta-classes du méta-modèle d UML définissent des concepts abstraits qui seront par la suite spécialisés. Ce sont ces spécialisations qui seront représentées graphiquement, les classes abstraites n ayant pas vocation à être instanciées directement. De plus certains concepts comportementaux sont aussi introduits dans la sémantique d action d UML sans pour autant avoir de syntaxe concrète pour les exprimer. Sébastien Revol Thèse de doctorat 39/161

40 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles Deployments : Le but de ce paquetage est principalement d exprimer comment vont être implémentés et physiquement répartis les logiciels que l on a spécifiés à l aide des diagrammes précédents, et plus particulièrement le diagramme de composants. Le diagramme de déploiement est ainsi utile pour avoir une bonne représentation d un système réparti, en identifiant les infrastructures d exécution et de communication sur lesquels va être déployé le code exécutable (ou artéfact) du programme spécifié. Voici maintenant les paquetages impliqués dans la partie comportementale du standard UML : CommonBehaviors : Ce paquetage introduit les notions de base pour la définition comportementale d UML, en définissant par exemple la notion d exécution et les principes de communication. Ces notions seront ensuite raffinées dans les paquetages suivants. UseCases : Ce paquetage introduit les concepts nécessaires au diagramme de cas d utilisation. Ce dernier permet d identifier les fonctionnalités que l on attend d un système, et d identifier les acteurs externes au système impliqués dans ces fonctionnalités. Il est généralement utilisé dans les phases initiales de spécification. Interactions : Le paquetage Interactions introduit de nombreuses notions pour spécifier ou illustrer comment des instances d objet vont communiquer entre elles. UML définit différents diagrammes se basant sur ces principes : le diagramme de séquence, le diagramme d interactions globales 3, le diagramme de communication ou encore le diagramme temporel 4. Ces différentes représentations sont redondantes, chacune mettant l emphase sur un certain aspect de la communication. L utilisateur pourra donc choisir parmi ceux-ci en fonction de ce qu il souhaite représenter. StateMachines : Le paquetage StateMachines introduit les notions permettant de décrire des aspects comportementaux à l aide de machines d état-transition. Il s agit d une intégration des StateCharts de Harel [49, 50]. UML définit deux catégories de machines d états : les machines comportementales et les machines de protocoles. Les premières servent à directement spécifier le comportement d une entité, alors que les secondes se focalisent sur le protocole en contraignant l ordre des interactions entre différents éléments du système. Activities : Les activités permettent de spécifier le comportement d un système en se focalisant sur l enchainement et la coordination d actions élémentaires. Elles permettent de représenter des modèles de flot de contrôle ou flot d objets, par l intermédiaire du diagramme d activités. Actions : L occurrence d un comportement peut-être vu comme la succession d actions élémentaires. Ce paquetage identifie et définit une sémantique à toutes ces actions élémentaires. Les machines d états et les activités peuvent être vues comme des structures de contrôle spécifiant un contexte dans lequel les actions vont avoir lieu. Bien qu un grand nombre de concepts soient identifiés dans ce paquetage, permettant de porter leur sémantique sur la plupart des environnements d exécution (Java, C/C++ dans différents OS etc.), la norme UML ne définit pas de syntaxe pour un grand nombre d entre eux. Cependant, différentes initiatives ont défini un langage d action à UML [79, 71, 133]. De tels langages permettent l obtention de modèles UML complètement exécutables sans avoir à rajouter de code spécifique à un langage d exécution particulier, de telle sorte que l on puisse par la suite générer différentes implémentations exécutables dans différents langages à partir d un unique modèle [72]. 3 Interaction overview 4 Timing Diagram 40/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

41 3.4. Présentation de l Unified Modeling Language FIG. 3.8 Classification des 13 diagrammes du langage UML En résumé de cette présentation, la figure 3.8 propose une classification des 13 diagrammes du langage UML. (Les classes dont le nom est en italique représentent des classes abstraites, identifiant une catégorie de diagrammes.) Extensibilité d UML : la notion de profil UML est un langage de modélisation généraliste. Comme nous l avons introduit dans la section 3.4.1, son méta-modèle vise à couvrir tous les aspects de la modélisation logicielle. Cependant, il arrive qu en pratique son utilisation telle quelle ne soit pas adaptée pour modéliser les concepts d un domaine bien particulier. Conscients de ce problème, les auteurs de ce langage y ont introduit la possibilité de le spécialiser par le mécanisme de profil, permettant ainsi d utiliser UML non plus comme un langage généraliste, mais plutôt comme un DSL (cf section 3.2.3). FIG. 3.9 Spécialisation d UML par le mécanisme de profil Pour spécialiser UML, un profil joue sur différents points : Extension du méta-modèle Le mécanisme offre un moyen d étendre le méta-modèle d UML par l utilisation de stéréotypes. Un stéréotype permet d étendre toute méta-classe du langage UML (sauf la méta-classe stéréotype elle-même 5 ) et de créer ainsi une nouvelle méta-classe héritant 5 En empêchant la spécialisation de la notion de stéréotype, UML s empêche de modifier son mécanisme de spécialisation, ce qui permet de pouvoir interpréter un profil de manière systématique, mais qui a aussi pour effet de limiter les possibilités de spécialisation Sébastien Revol Thèse de doctorat 41/161

42 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles de toutes les propriétés de la méta-classe étendue. Il devient aussi possible d ajouter des nouvelles propriétés à cette nouvelle méta-classe à l aide de tagged values. Il est à noter qu il est possible d obliger l utilisation de stéréotypes sur la méta-classe, de telle sorte que l utilisateur ne soit plus autorisé à employer la méta-classe originale dans un modèle. Fermeture de points de variation sémantique : En vue de pouvoir s adapter dans différents domaines, la norme UML laisse délibérément certains points de sémantique ouverts. Lorsque l on étend une méta-classe, on hérite de sa sémantique. Pour que le langage que l on crée soit bien défini, il faut donc veiller à fixer ses points de variation sémantique si elle en a, en fonction de la spécialisation que l on en fait. Ajout de contraintes OCL : La nouvelle méta-classe que l on crée à l aide d un stéréotype s utilise a priori en respectant les contraintes appliquées à la méta-classe étendue. Cependant, il est possible d ajouter des contraintes supplémentaires en associant des contraintes OCL au stéréotype. Un éditeur UML suffisamment évolué sera capable d interpréter ces contraintes et de signaler une erreur de modélisation. Spécialisation de la syntaxe graphique : Le mécanisme de profil prévoit qu il est possible d associer une forme visuelle particulière au stéréotype que l on définit. Ainsi, on peut spécialiser la syntaxe graphique en spécialisant les diagrammes. Là aussi, un éditeur évolué tel que [28] permet de charger dynamiquement ces images et d éditer directement ce nouveau type de diagramme. Définition d une méthodologie de modélisation : Enfin lorsque l on définit un profil, il paraît nécessaire de bien le documenter, notamment en identifiant clairement les diagrammes avec lesquels ce profil est fait pour être utilisé. En effet un stéréotype ne précise pas par lui-même dans quel diagramme il doit être utilisé. Lorsqu un élément d un méta-modèle peut apparaître dans différents diagrammes, le stéréotype qui l étend le peut aussi. Or la transformation d UML en un DSL cherche à choisir les représentations les plus expressives pour le domaine que l on vise, notamment lorsqu il existe plusieurs diagrammes redondants. Cela passe donc par la définition de bonnes pratiques, voire l interdiction d utiliser certains éléments du méta-modèle d origine. Pour illustrer le mécanisme de profil, imaginons que l on veuille exprimer avec UML les concepts du méta-modèle de la figure 3.10 que nous avons utilisé précédemment en exemple. La figure 3.11 montre la définition du profil correspondant. FIG Exemple de méta-modèle 42/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

43 3.4. Présentation de l Unified Modeling Language FIG Exemple de profile pour le méta-modèle de l exemple On voit que l on spécialise la notion de classe avec le stéréotype "<dsl Systeme">, qui servira à représenter la notion de Système introduite dans notre méta-modèle. De même le stéréotype "<dsl Composant"> étend la notion de property d UML et le stéréotype "<dsl Port"> la notion de port. On voit de plus qu une tagged value est ajoutée à ce dernier afin de spécifier la direction de notre "<dsl Port">, notion qui n existe pas dans le méta-modèle original d UML. Enfin le stéréotype "<dsl Connection"> étend la notion de connector d UML. En effet, la norme UML laisse un point de sémantique ouvert pour les connecteurs : il est dit que ce qui rend des éléments connectables compatibles est un point de variations. Dans notre cas, nous pouvons le préciser en disant, comme nous l avions énoncé dans la section 3.2.4, que les éléments connectables doivent être des "<dsl Port">, et qu ils ne peuvent être connectés que si leurs directions exprimées par les tagged values sont complémentaires. Ceci pourrait de plus se décrire à l aide d une contrainte OCL afin qu elle soit évaluée et que l outil UML puisse vérifier qu elle est respectée. La figure 3.12 montre enfin le même exemple de plateforme que dans la section 3.2.1, modélisé cette fois à l aide de notre profil dans un éditeur UML. Le diagramme utilisé est le diagramme de structure composite. Les stéréotypes des éléments apparaissent entre chevrons au dessus de leur nom, sauf pour les ports dont nous avons modifié la syntaxe graphique. La valeur de leur tagged value est affichée dans un commentaire, mais l éditeur fournit un champ spécifique permettant de la modifier, et fournissant automatiquement un choix entre les 3 valeurs possibles. FIG Exemple d application de profil UML Sébastien Revol Thèse de doctorat 43/161

44 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles Il est à noter que l éditeur utilisé nous fournit aussi la possibilité d éditer une palette d outils permettant d instancier directement des éléments stéréotypés, ainsi que d imposer des règles de vérification (en plus des contraintes OCL) empêchant directement l utilisateur de créer des modèles mal formés. On voit que de telles possibilités de spécialisation du langage et de l outil permettent d utiliser UML non plus comme un langage généraliste, mais bel et bien comme un DSL UML et IDM comme support de méthodologies Comme nous l avons vu, bien que l origine historique de l Unified Modeling Language réside dans la définition d une méthodologie universelle de développement logiciel, l UML n est pas en lui-même une méthodologie mais bien un langage. Cependant, le spectre de son méta-modèle et de ses diagrammes, son mécanisme de spécialisation ainsi que son fondement sur les théories de l Ingénierie Dirigée par les Modèles en font un candidat idéal pour l expression de méthodologies de développement pour un domaine particulier. L élaboration d une telle méthodologie consiste principalement en l identification d une succession d étapes de réalisation bien précises, regroupant diverses activités comme la spécification, l analyse, la conception, la vérification ou encore le test. Pour chacune de ces activités, UML va permettre de définir la ou les représentations les plus adaptées. De plus, en s appuyant sur les technologies de l IDM, il devient possible de spécialiser des outils pour une méthodologie. Ainsi les passages d une étape à l autre peuvent être partiellement ou même entièrement automatisés, par exemple via des transformations de modèles. L une des méthodologies les plus répandues est le Rational Unified Process [63]. Il s agit d un processus générique, itératif et incrémental, s appuyant à l origine sur les diagrammes de cas d utilisation. Elle propose notamment trois catégories de modèles : le modèle d analyse, de conception et de déploiement. De nombreuses variantes se sont par la suite inspirées de ce patron pour des métiers particuliers. Ainsi la méthodologie ACCORD UML [48, 118] dévéloppée dans le laboratoire LISE du CEA, dans lequel s est déroulé ma thèse, s en inspire pour la conception de systèmes temps réel embarqués. Largement outillée, les différentes étapes sont automatisées, avec notamment la génération automatique du modèle d implémentation, et de son code exécutable associé, ou encore celle de modèles de test à l aide d outils d analyse formelle [67]. 3.5 Les bénéfices de l IDM et UML Maintenant que nous connaissons les grands concepts de l Ingénierie Dirigée par les Modèles, ainsi que du langage UML, nous allons résumer les principaux bénéfices que ces techniques et langages apportent à leurs utilisateurs. Dans le chapitre suivant, nous étudierons plus particulièrement leur mise en application dans le flot de spécifications des systèmes sur puce Un langage adapté aux besoins de l utilisateur Les différents diagrammes introduits dans UML permettent de définir la représentation la plus adaptée possible aux besoins de l utilisateur, que ce soit pour la définition de spécifications, de modèle structurel ou comportemental. Il favorise ainsi la dissociation des préoccupations : le nombre de diagrammes réalisables pour un même modèle est illimité. On peut ainsi ne laisser apparaître que les informations utiles à une description particulière, et chaque nouveau diagramme permet d enrichir un même modèle qui centralise toutes les informations spécifiées. 44/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

45 3.6. Conclusion Diminution du nombre de formats En utilisant un seul langage pour les différents aspects d un flot de conception, le nombre de formats de données mis en jeux s en trouve considérablement réduit. Cela favorise grandement la communication entre les différents corps de métiers impliqués qui peuvent s échanger directement des modèles à travers un outil UML. Cette capacité de communication est d autant plus favorisée par la standardisation du format XMI, qui n impose plus aux différents acteurs de posséder le même outil Interopérabilité des formats Même si le langage général d un flot de conception devient unifié grâce à UML, il s avère que certains outils spécifiques à une opération requièrent un format particulier des données qu ils prennent en entrée, comme pour la vérification formelle, l analyse d architecture etc. UML sert alors de pivot centralisant toutes les données. Grâce aux mécanismes de l IDM tels que la transformation de modèles ou la génération de codes, ces données peuvent être beaucoup plus facilement extraites, réécrites puis complétées dans le format adéquat Automatisation grâce à l IDM L import-export n est qu un exemple des possibilités d automatisation fournies par l IDM. Cellesci peuvent aussi grandement automatiser certaines phases de conception en assistant l utilisateur. Certaines opérations systématiques propres à une activité spécifique qui devaient être réalisées manuellement peuvent ainsi être codées dans une transformation de modèles ou un flot de génération de code. Ceci a pour effet non seulement d accélérer de manière considérable le processus, mais aussi d empêcher les erreurs qu une opération manuelle aurait pu causer Réutilisation des spécifications L approche objet, sur laquelle repose le langage UML, permet d envisager la réutilisation d éléments de conception à différents niveaux d un flot de conception. En effet l encapsulation et la notion d héritage proposées par cette approche permettent d isoler et d étendre des spécifications exprimées par exemple à l aide de diagrammes de Cas d utilisation, de diagrammes de séquences etc. Ces propriétés ont notamment été utilisées pour introduire la notion de familles de produits [123, 137], qui permet de spécifier plusieurs déclinaisons d un système intégrant plus ou moins de fonctionnalités, basées sur un noyau commun. 3.6 Conclusion Dans ce chapitre nous avons introduit les concepts de base de l IDM, et présenté un de ses plus grands représentants, le langage UML. Nous venons aussi de mettre en valeur les avantages que procurent l utilisation conjointe de ce langage avec les différentes techniques d automatisation qu il nous autorise. Dans le prochain chapitre, nous allons effectuer le rapprochement entre le flot de conception des SoC présenté au chapitre précédent et l IDM. Nous verrons ainsi les solutions proposées pour améliorer ce flot, et identifierons certaines de leurs limites, nous permettant d introduire notre contribution. Sébastien Revol Thèse de doctorat 45/161

46 Chapitre 3. Présentation générale de l Ingénierie Dirigée par les Modèles 46/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

47 Chapitre 4 Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC Sommaire 4.1 Contexte de l étude Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce Les méthodologies UML pour les systèmes sur puce Exigences du système et spécifications fonctionnelles Analyse Architecture Pour le flot logiciel Pour la modélisation matérielle et génération de code Résumé de l étude Solution proposée : le profil Electronic System Level Présentation générale Positionnement dans le flot de spécifications Conclusion Dans le second chapitre de cette thèse, nous avons étudié le flot de conception des systèmes sur puce, mis en valeur certaines solutions visant à améliorer sa productivité, et identifé leurs limitations actuelles. Dans le chapitre suivant, nous avons effectué une présentation générale des solutions technologiques proposées par l Ingénierie Dirigée par les Modèles. Dans ce nouveau chapitre, nous allons analyser les différentes initiatives visant à utiliser les moyens offerts par l IDM pour répondre aux problématiques du flot de conception des SoC. Pour ce faire, nous préciserons dans un premier temps le cadre industriel dans lequel s est déroulée cette thèse et les contraintes qui en découlent. C est sous ce regard que nous évaluerons les solutions de l état de l art, identifiant celles qui sont adaptées à nos besoins mais aussi les lacunes persistantes. Enfin, l identification de ces lacunes nous permettra d introduire la contribution de cette thèse que nous présenterons en détails dans le chapitre suivant. 4.1 Contexte de l étude Le contexte industriel de cette thèse impose des contraintes influençant le regard que nous allons porter sur les différentes initiatives visant à exploiter UML et l IDM pour la conception des systèmes 47

48 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC sur puce. Notre objectif final est d identifier un flot idéal exploitant au mieux les différentes approches tout en tenant compte des contraintes suivantes : La nature des systèmes ciblés : dans notre cas les produits ciblés sont des systèmes embarqués multimédia. Ils se caractérisent principalement par une architecture hétérogène, et des contraintes de sûreté de fonctionnement moins critiques que dans certains secteurs tels que l avionique ou l automobile. Possibilités d intégration dans les méthodes de travail existantes : l ampleur d une entreprise comme STMicroelectonics impose des contraintes sur la mise en application de nouvelles méthodes, qui ne peut se faire que progressivement, sans avoir à remettre entièrement en cause les pratiques existantes. Intégration avec les standards de l électronique : dans notre approche, des outils fortement employés tels que Matlab/Simulink, le langage C, ainsi que les standards tels qu IP-XACT ou la modélisation SystemC-TLM, et les techniques qui les exploitent ne peuvent être remis en question. Notre étude ne doit pas chercher à les remplacer mais à les intégrer au mieux, en facilitant leur utilisation. Nous précisons aussi que notre étude se focalise principalement sur l aspect langage, notamment en termes de profils employés tout au long du flot de conception. Nous ne cherchons par exemple pas à redéfinir une nouvelle méthode de partitionnement matériel-logiciel, mais à positionner les méthodes existantes dans un flot général. Enfin, bien que notre étude cherche à donner une vision globale du flot de conception, les activités de l équipe System Platform Group de STMicroelectronics dans laquelle notre thèse s est déroulée influencent notre point de vue. Ainsi notre analyse sur les lacunes du flot se portera plus particulièrement après le partitionnement matériel-logiciel, sur la partie du développement matériel avec en ligne de mire l intégration des technologies de modélisation transactionnelle. 4.2 Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce L intérêt qu a porté la communauté électronique au langage UML a été assez immédiat. Il a notamment crû avec le besoin d avoir une représentation d un système électronique dans son intégralité (Electronic System Level). Cette croissance a finalement abouti en 2004 à l organisation du premier atelier de travail (workshop) UML-SoC en marge d une des plus grandes conférences internationales dans le domaine de la conception électronique (Design Automation Conference). Ce séminaire, dont les publications ont par la suite donné lieu à l édition du livre UML for SoC Design [69] a permis de grandement médiatiser les initiatives existantes et de susciter l intérêt non seulement des académiques, mais aussi des acteurs majeurs de l électronique. C est aussi à cette époque qu a été adopté le standard OMG UML for SoC Profile [85]. Actuellement, nous ne pouvons pas encore dire que l utilisation d UML soit généralisée dans l industrie électronique. Cependant quelques publications telles que [45, 136], ainsi que la commercialisation d outils spécialisés dans l utilisation d UML pour la conception des SoC [66, 14] montrent qu une adoption progressive est en train d avoir lieu. De plus la création ces dernières années de différents projets de recherche toujours en cours, tels que SPRINT [114], MARTES [98] ou MoPCoM [75] laisse espérer de nombreux progrès et une adoption plus généralisée de ce langage pour les prochaines années. Nous vous invitons à lire la publication UML for ESL design : basic principles, tools, and applications [80], dans laquelle les auteurs proposent un résumé des principes mis en jeux à la conception des systèmes sur puce. 48/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

49 4.2. Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce Les méthodologies UML pour les systèmes sur puce FIG. 4.1 Méthodologie IDM pour le flot de conception des SoC La définition et l implémentation d une méthodologie pour couvrir l intégralité du flot de conception des systèmes sur puce est en quelque sorte un objectif ultime. En effet, cela sous-entend que tous les points du flot que nous rappelons dans la figure 4.1 ont été couverts, avec en conséquence la définition de profils adaptés, accompagnés d outillages adéquats. Le laboratoire NEC et l université de Lugano ont figuré parmi les premiers à proposer dans [64] une méthodologie, nommée ACES, cherchant à couvrir une grande partie du flot de conception avec des représentations UML adaptées. Le projet européen de recherche appelé Prompt2Implementation, exploita la notion de flot en Y [19] décrit dans la figure 4.3, impliquant la définition d un modèle UML fonctionnel, d un modèle d architecture matérielle et d un modèle d association des deux précédents pour l analyse d architecture et la génération de code. Depuis les projets MARTES ou MoPCoM continuent de travailler afin de spécifier des profils et des techniques associées pour la couverture d un flot complet. On pourra noter que le projet MoPCoM propose de s inspirer de méthodologies existantes pour le développement logiciel [61], telles que HARMONY [120] intégrée dans l outil UML Rhapsody [119]. Cette dernière s inspire d ailleurs du Processus Unifié [63], partant notamment de l expression de cas d utilisations pour la construction du système. De la même manière, Sara Bocchio et al., travaillant dans la division Advanced System Technology de STMicroelectronics proposent eux aussi une méthodologie de conception appelée UPSoC [103] s inspirant de ce processus unifié. Cette méthodologie exploite de plus le profil spécifique à SystemC [101] ainsi que l outil qu ils ont spécialisé pour son utilisation. La définition de méthodologies, surtout lorsqu elle a lieu dans le cadre de projets de recherche collaboratifs vise donc à intégrer de manière cohérente les différentes initiatives de travail sur des points spécifiques du flot de conception. Il est en effet difficile de pouvoir, dans un même travail, aborder les nombreux points qui doivent être couverts pour entièrement implémenter un flot basé sur des technologies IDM. Nous allons donc maintenant dans notre panorama tenter de situer plus précisément sur quel aspect du flot se sont concentrées les principales initiatives de l état de l art. Sébastien Revol Thèse de doctorat 49/161

50 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC Exigences du système et spécifications fonctionnelles FIG. 4.2 Spécifications intiales du flot de conception des SoC Les méthodologies se basant sur UML commencent fréquemment par l expression de cas d utilisation, permettant de définir ce qui est attendu du système. Klaus Kornlof et Ian Oliver, de la société Nokia, proposent dans [62] un moyen de définir des cas d utilisation exécutables pour les systèmes sur puce. De plus, dans leur approche, les spécifications textuelles ne sont pas complètement exclues, mais exprimées à l aide d un outil spécialisé comme DOORS [121], permettant d organiser de manière plus efficace ces exigences. Ils proposent alors d exploiter les capacités offertes par certains outils UML comme TAU [122] ou Rhapsody pour établir un lien de traçabilité entre ces exigences textuelles et les cas d utilisations définis en UML. Cette volonté d intégrer dans le modèle des exigences textuelles a été reprise et standardisée par le profil SysML [93]. En effet ce dernier est un profil UML spécialisé pour l ingénierie système (System Modeling Language), et se révèle être un bon candidat pour les premières étapes du flot de conception des systèmes sur puce [128]. Le diagramme d exigences (Requirement Diagramm) est ainsi une spécialisation du diagramme de classe servant à exprimer et organiser structurellement des exigences textuelles. En les portant au niveau du modèle, il est alors possible de les connecter, via des liens de dépendance particuliers, vers d autres éléments du modèle implémentant le système, permettant de garder un lien de traçabilité entre ces exigences et les éléments qui ont été définis pour y répondre. Ce profil spécialise aussi le diagramme de structure composite, lui donnant une connotation Flot de données, et définit un autre type de représentation appelé diagramme paramétrique. Ces spécialisations donnent à ces représentations une sémantique proche de celle utilisée dans Matlab/Simulink [70]. Ainsi comme nous le précise Yves Vanderperren dans [129, 80], des connections entre cet outil et des outils UML/SysML ont pu être établies. Ces connections permettent une intégration directe des modèles de spécifications exécutables des systèmes sur puce fréquemment réalisés avec Matlab/Simulink dans un flot de conception basé sur UML. On notera que certaines initiatives, telles que [99] cherchent aussi à exploiter une modélisation structurelle et comportementale avec SysML pour la génération de modèles fonctionnels exécutables grâce à SystemC. La création de spécifications exécutables est aussi l un des axes de développement 50/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

51 4.2. Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce de la société Mentor Graphics, propriétaire de l outil UML BridgePoint [72]. Ils exploitent dans celuici le langage d action qu ils ont défini pour spécifier un modèle UML exécutable et simulable avant partitionnement Matériel/Logiciel et indépendant de tout langage d implémentation, permettant donc de dériver des parties de celui-ci soit vers un flot de développement matériel, soit vers un flot de développement logiciel. Cependant cette dernière solution ne nous paraît pas exploitable car elle impose de réécrire dans leur langage des algorithmes existant déjà sous la forme de code C/C++. C est bel et bien le C/C++ qui est devenu le langage d action standard dans le flot de spécifications, et depuis lequel certaines initiatives telles que [43, 3, 4] proposent des solutions de synthèse de haut niveau. L équipe de Jean-Luc Dekeyser et Pierre Boulet de l INRIA 1, travaille sur une approche reposant sur la notion de modèle fonctionnel offrant le choix d une implémentation logicielle ou matérielle. Reposant sur le modèle en Y [19], la particularité de leur approche est de s appuyer à travers UML sur le langage Array-OL [20], offrant une sémantique d exécution intégrant de manière native le parallélisme massif. Cette approche trouve particulièrement son intérêt dans les applications de traitement du signal intensif, où les algorithmes peuvent être fortement parallélisés et projetés sur des plateformes matérielles d exécution présentant une architecture répétitive. L outil Gaspard2 développé par cette équipe est alors capable de prendre en entrée un modèle fonctionnel, un modèle d architecture et un modèle d allocation entre ceux-ci. Ces modèles sont alors interprétés et permettent la génération de logiciel embarqué ou de composants matériels implémentant les fonctionnalités définies, soit en SystemC au niveau PVT, soit directement en VHDL. On notera que le profil utilisé pour l expression de ces modèles fonctionnels était à l origine un profil spécifique appelé Gaspard [13], dont de nombreux concepts comme la description de la répétitivité structurelle ont été depuis intégrés dans le standard MARTE [89] de l OMG. Cette plateforme Gaspard semble donc apporter une solution innovante et efficace pour les systèmes de traitement intensif du signal. Cependant les architectures multimédia actuelles, bien que de plus en plus complexes, ne présentent pas encore une répétitivité permettant d exploiter cette approche Analyse Architecture FIG. 4.3 Analyse d architecture dans le flot des spécification des SoC Un grand nombre d initiatives se sont portées sur le problème de l analyse d architecture, un des points cruciaux du flot de conception des systèmes sur puce. Dans la très grande majorité des cas, 1 Institut National de Recherche en Informatique Appliquée Sébastien Revol Thèse de doctorat 51/161

52 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC ce processus suit ici aussi le schéma du modèle en Y de la figure 4.3, exploitant la projection d un modèle fonctionnel sur un modèle d architecture. Dans ce cas, le modèle fonctionnel doit pouvoir faire ressortir le parallélisme potentiel dans le traitement des opérations, ainsi que contenir des informations sur les paramètres contraignant le choix d une architecture, tels que les durées maximales d exécutions (Worst Case Execution Time, WCET), leur périodicité, mais aussi les besoins en puissance de calcul, en mémoire etc. De même le modèle d architecture doit lui aussi posséder des informations relatives à ses performances et ayant une influence sur les contraintes spécifiées, telles que la fréquence de calcul, la taille des mémoires, les latences des bus de communication etc. La méthodologie MCSE [27] implémentée par l outil Cofluent Studio [5] est un exemple d exploitation de cette approche. Cet outil permet de spécifier rapidement des modèles fonctionnels annotés ainsi que des modèles de plateformes matérielles, et permet d évaluer analytiquement puis dynamiquement par simulation le résultat d un choix particulier de projection entre ces deux modèles. Le langage utilisé pour ces descriptions et annotations est graphique et ressemble fortement aux concepts proposés par UML. Par l intermédiaire d outils de traduction, l approche MCSE a ainsi été adoptée par Nokia dans la continuité de l approche de spécifications présentée dans [62] (cf. section 4.2.2). Des travaux sont actuellement en cours, notamment dans le projet MARTES pour effectuer un rapprochement et une meilleure interopérabilité entre ces deux langages. D autres initiatives, telles que [130, 110] proposent de s appuyer sur SysML et utilisent des outils ad hoc pour effectuer des analyses d exploration architecturale. Teros Kangas et al. de l université de Tampere en Finlande proposent un environnement d exploration automatique appelé Koski, utilisant un profil UML appelé TUT profile [60]. Cet environnement propose une approche mêlant analyse statique et simulatoire, se basant sur une bibliothèque de composants dont les caractéristiques non fonctionnelles liées à la performance sont paramétrables, permettant de créer rapidement un modèle simulable de la plateforme. Les caractéristiques obtenues après simulations peuvent être par la suite automatiquement réinjectées dans le modèle d analyse statique, afin de pouvoir raffiner cette opération. L outil explore ainsi automatiquement certaines politiques de placement de tâches dans le circuit, lorsque celui-ci comporte plusieurs processeurs, afin de déterminer la meilleure configuration. La méthodologie Adéquation Algorithme Architecture (AAA) [47] supportée par l outil Syndex [111] se base aussi sur une approche en Y. Cet outil, développé sous l initiative d Yves Sorel de l INRIA permet en effet d effectuer une projection d un modèle de spécifications vers un modèle de plateforme tous deux annotés. Ainsi il implémente des heuristiques visant à calculer la projection la plus efficace du modèle fonctionnel sur un modèle de plateforme matérielle donné, afin de répondre au mieux aux contraintes imposées. Des travaux actuels sont réalisés pour que cet outil puisse prendre en entrée des modèles décrits avec le profil UML MARTE pour générer automatiquement le code d une partie des logiciels embarqués ou du code synthétisable implémentant le comportement d un composant particulier. Cependant, le niveau de détails requis pour la construction du modèle fonctionnel semble trop important pour permettre de décrire simplement toutes les fonctionnalités d un système sur puce multimédia. Elle reporte en effet le travail d implémentation dès cette phase du flot de conception. Ainsi cette méthode semble plus adaptée pour des systèmes logiciels/matériels de contrôle-commande tels qu on en retrouve dans l avionique, où le nombre de fonctionnalités est plus réduit, mais impose une sûreté de fonctionnement plus élevée, avec notamment la garantie que les traitements requis seront exécutés dans les délais qui leur sont impartis. Le standard MARTE, dont le nom français est Modélisation et l Analyse des Systèmes Temps Réel Embarqués et dont la version préliminaire a été approuvée en juin 2007 devrait apporter une unification syntaxique des différentes initiatives. Ce profil, conçu pour succéder à son prédécesseur appelé profile for Scheduling, Performance and Time Specification (SPT [83]), introduit en effet de nombreux concepts permettant d annoter un système logiciel ou matériel en vue de l analyser. Tout comme UML 52/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

53 4.2. Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce ne propose pas de méthodologie de conception, MARTE ne fournit pas non plus de méthode particulière pour les activités qu il supporte. Il s organise en différents paquetages fournissant un ensemble d éléments de notations facilitant l utilisation d UML pour la modélisation et l analyse des systèmes temps réels embarqués. FIG. 4.4 Structure du profil MARTE Comme on peut le voir dans la figure 4.4, ce profil est composé de trois paquetages principaux : MARTE Foundations : c est le cœur du profil, sur lequel les autres paquetages s appuyent. Il contient entre autres une définition précise des différentes notions de temps que l on retrouve dans les systèmes temps réel. On notera aussi le sous-paquetage Allocation, introduisant les concepts pouvant être utilisés pour la spécification d une projection d un modèle fonctionnel sur une architecture matérielle. Le sous-paquetage Non Functional Properties fournit quant à lui un ensemble de notions pour exprimer différentes grandeurs comme le temps, la fréquence, la puissance, incluant les unités de mesure correspondantes. Real Time and Embedded Design : ce paquetage fournit les éléments nécessaires à la description d applications, en se basant sur deux sous-paquetages spécifiques : Software Resources pour la modélisation du logiciel et Hardware Resources pour la modélisation du matériel. Real Time and Embedded Analysis : ce dernier paquetage se focalise sur les activités d analyse des systèmes embarqués. On voit qu il identifie deux sous-activités particulières : l ordonnancement (Schedulability) et la performance (Performance). Bien que ce profil soit récent, on retrouve dans l état de l art différentes initiatives l exploitant. Le laboratoire du CEA List dans lequel s est déroulée cette thèse a été fortement impliqué dans la constitution de ce standard, et propose différentes solutions pour l exploiter. Huascar Espinoza, contributeur entre autre des paquetages Non Functional Properties et Schedulability propose dans sa thèse [40] une méthodologie pour construire et annoter des modèles pour l analyse de systèmes temps réel. Safouan Taha, contributeur du paquetage Hardware Resource s est intéressé à l utilisation de ce profil pour décrire des plateformes matérielles contenant des caractéristiques paramétrables, permettant d obte- Sébastien Revol Thèse de doctorat 53/161

54 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC nir rapidement un simulateur afin de valider le portage d une application logicielle sur cette plateforme [115, 116] Pour le flot logiciel FIG. 4.5 Aspect logiciel du flot de conception des SoC La conception logicielle est bien sûr l activité native pour laquelle UML a été conçu. Bien qu il s agisse d un langage généraliste ne visant pas de domaine particulier de l ingénierie logicielle, la communauté de l embarqué a rapidement montré de l intérêt envers UML, permettant de mieux gérer la complexité toujours croissante de ces systèmes. La construction du standard a d ailleurs été fortement influencée par des approches objet pour l embarqué telles que ROOM définie par Bran Sélic [109]. Celui-ci a par la suite été à l initiative du profil UML-RT [2] exploité par l outil Rose-RT de la société Rational. Depuis d autres outils exploitent différents profils spécialisés, tels que Rhapsody avec le profil RT UML [38], permettant de générer du code pouvant être exécutés sur des systèmes embarqués. L exploitation des technologies de l IDM pour la conception de logiciel embarqué est l activité originelle du projet de recherche ACCORD UML du CEA, dans lequel s est déroulé cette thèse. La thèse de Sébastien Gérard [48], soutenue en octobre 2000, a ainsi donné naissance à la définition d une méthodologie se basant sur UML, partant depuis l expression des besoins jusqu à l obtention du code embarqué exécutable sur une machine virtuelle pouvant être adaptée sur différents types de noyaux temps-réel embarqué. Cette méthodologie a été depuis instrumentée et différentes phases de conceptions ont ainsi été automatisées grâces aux technologies de l IDM, comme la transformation de modèles ou la génération de code [118]. La nature de plus en plus complexe et hétérogène des systèmes sur puce, embarquant plusieurs processeurs parfois interconnectés par un véritable réseau sur puce (Network on Chip, ou NoC) mène les développeurs logiciels à se porter sur des solutions de l embarqué pour des systèmes répartis. Des approches telles que AADL [42] ou Autosar [6], respectivement pour l avionique et l automobile, proposent par exemple des modèles de programmation basés sur la notion de composant logiciel. Ces approches, accompagnées de profils UML pour les utiliser, permettent de mieux gérer la complexité 54/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

55 4.2. Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce en représentant le logiciel comme un ensemble de briques interchangeables, déployables sur un ensemble d unités de calcul (Electronic Computing Unit ou ECU) interconnectées. Ces spécifications de déploiement peuvent par la suite être interprétées pour la génération ou la configuration d intergiciels (MiddleWare) permettant la communication entre ces éléments, facilitant l accès aux services fournis par des ressources physiques, et tenant compte des contraintes temps réel imposées. Il existe encore bien d autres exemples d utilisations d UML pour le logiciel embarqué. Nous invitons le lecteur à lire UML for Real [65], édité par Bran Selic et Lavagno, proposant un panorama plus détaillé des différentes approches Pour la modélisation matérielle et génération de code FIG. 4.6 Aspect matériel du flot de conception des SoC Dans le domaine de la conception matérielle, les capacités de génération de code fournies par UML ont ici aussi beaucoup été exploitées. Certaines approches telles que [8] ont cherché à utiliser le langage UML pour représenter la structure et le comportement des composants électroniques à un niveau proche du RTL, permettant la génération de code synthétisable. Tim Schattkowsky et al. dans [106] proposent d exploiter le diagramme d activités pour obtenir une description comportementale des composants permettant la génération de Handel-C [3]. Ce langage, est en fait une spécialisation d un sous ensemble du langage C, pouvant être interprété par des compilateurs et synthétisé au niveau portes logiques. Nous pouvons aussi noter les approches basées sur les langages synchrones pour la conception de matériel. Par exemple, l outil Esterel Studio exploite le langage Esterel [15] pour la génération de descriptions matérielles en SystemC au niveau Cycle Accurate ou directement en VHDL au niveau RTL. La particularité de ce langage est de reposer sur des fondements mathématiques solides permettant d effectuer des vérifications formelles et de générer du code optimisé respectant les propriétés vérifiées. La description Esterel peut être réalisée graphiquement à l aide des SyncChart [10], une classe particulière d automates à états-transitions. Bien que la syntaxe graphique de ces automates soit proche de celle des State Machine du standard UML, leurs sémantiques d éxécution diffèrent 2. Le 2 Une des grandes différences entre les SyncChart et les State Machine vient de la notion de simultanéité de l occurence Sébastien Revol Thèse de doctorat 55/161

56 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC projet de recherche AOSTE de l INRIA contribue activement aux travaux de standardisation d UML et notamment dans le profil MARTE, en apportant par exemple une meilleure définition de la notion de temps qui laisse entrevoir une intéropérabilité entre Esterel et UML. Dans le même temps que cette thèse, l équipe SPG a aussi investigué sur des techniques de génération de code se basant sur les spécifications IP-XACT des composants. Ainsi elle a mis en place un flot appelé TLMSkeleton permettant d obtenir la génération automatique d une grande partie de l implémentation SystemC-TLM d un composant TLM au niveau PV. Le flot de génération se décompose ainsi en deux étapes principales : le point initial est une description textuelle des interfaces et des registres du composant dans un format de fichier texte standard défini par l outil FrameMaker. De celui-ci, une première transformation génère une description IP-XACT de ces informations. C est alors la deuxième partie du flot de génération qui a pour charge de transformer les informations IP- XACT en leur implémentation en SystemC-TLM. Les interfaces du composant sont par exemple transformées en ports TLM. Les informations sur les registres sont aussi capitales pour l implémentation du composant en TLM PV. Elles permettent de générer automatiquement un algorithme de décodage de l adresse d un accès en écriture ou en lecture pour stocker ou restituer une donnée. Cette initiative démontre les possibilités de l exploitation de données exprimées dès le niveau de spécifications, mais reste malheureusement déconnectée d un flot de sépcifications UML intégrant d autres étapes spécifiques. SystemC est probablement la cible favorite des flots de génération de code à partir de spécialisations d UML pour la description matérielle [68, 134, 81, 35, 131, 101, 99, 9]. Reposant sur une bibliothèque de classes C++, il intègre directement l approche objet, et le code SystemC peut être obtenu à partir de générateurs de code C++ classiques légèrement adaptés. Ces adaptations portent principalement sur la représentation de la notion de port, et de connections entre ports, dont la représentation en UML a été rendue possible grâce au diagramme de structure composite [16]. D autre part, les diagrammes comportementaux d UML doivent également être adaptés pour permettre une génération de code tenant compte de la sémantique d éxécution proposée par le noyau SystemC. On retrouve des profils UML qui sont spécifiques à un niveau d abstraction donné (par exemple CA, RTL, TLM, processus communiquants), issus d initiatives diverses. On distinguera deux profils particuliers parmi ces initiatives : le standard de l OMG UML for SoC, ainsi que le profil UML pour SystemC de Sara Bocchio et al. Le standard UML for SoC, propose une manière de décrire la structure des systèmes sur puce exploitant les concepts du diagramme de structure composite. Bien que se voulant indépendant du niveau d abstraction ainsi que du langage d implémentation, on constate que les concepts et la sémantique proposés par ce standard sont très proches de ceux de SystemC. Il peut ainsi être confronté au profil UML for SystemC [101] défini par Sara Bocchio et al, qui transcrit de manière exhaustive les concepts de SystemC en UML. Ce dernier propose de plus une description comportementale permettant de générer du code exécutable à tout niveau d abstraction. Il couvre également des concepts structurels ( sc export ) introduits dans la version 2.1 de SystemC. Ce profil se distingue donc des autres approches par le niveau de granularité qu il offre pour la modélisation de SystemC. Certaines initiatives cherchent à définir une représentation adaptée au modèle de calcul d un niveau d abstraction particulier, se traduisant par des constructions prédéfinies d éléments SystemC/C++ lors de la génération de code. Le profil UML for SystemC, par une transcription un-pour-un de tous les concepts SystemC, autorise la modélisation en UML de tous les niveaux d abstractions supportés par SystemC. Cette approche permet d avoir grâce à UML une meilleure vue de la structure et du comportement d une d évènements proposée par l approche synchrone. Celle-ci est incompatible avec l approche proposée par UML qui impose une occurence séquentialisée des évènements 56/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

57 4.2. Panorama de l utilisation de l IDM et d UML pour la conception des systèmes sur puce système, et autorise l analyse de ceux-ci avant la phase de génération de code. Cependant, le revers de cette finesse syntaxique est que la construction de composants complexes peut s avérer très fastidieuse, et rebuter les développeurs de C++ expérimentés qui préfèreront conserver leurs méthodes de développement traditionnelles Résumé de l étude FIG. 4.7 Les profils de l état de l art dans un flot de spécifications IDM Cette étude nous autorise à conclure qu UML peut être un langage adapté et exploitable par les technologies de l IDM pour chacune des grandes étapes du flot de spécification des systèmes sur puce. La figure 4.7 illustre l enchaînement des profils que nous proposons d utiliser. SysML pour la saisie de specifications textuelles, l identification de cas d utilisations, la création d un modèle fonctionnel éventuellement interopérable avec des outils tels que MAT- LAB/Simulink ou Scicos/Scilab. MARTE peut ensuite être exploité pour le processus d exploration architecturale. Ainsi il permet la spécification de propriétés non fonctionnelles à la fois sur le modèle fonctionnel conçu précédemment 3 mais aussi sur un premier modèle d architecture. Il fournit par la suite tous les concepts nécessaires pour effectuer de l analyse. Le développement de logiciel embarqué peut se faire en partant de ces modèles fonctionnels et matériels, en adoptant des approches spécifiques à l embarqué pour la génération de code, comme les profils ACCORD UML, Autosar ou AADL. Pour le développement matériel, MARTE offre les moyens de décrire un assemblage de composants et de spécifier le rôle de ceux-ci en vue d annotations non fonctionnelles. Cependant il 3 Le modèle fonctionnel est alors modélisé par l application de deux profils : MARTE et SysML Sébastien Revol Thèse de doctorat 57/161

58 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC n offre pas le même niveau de détail que le profil UML for SystemC qui sera préféré pour la génération de code. IP-XACT reste le format d échange pour les composants, et peut être considéré comme la description la plus naturelle pour le stockage des composants. C est aussi sur ce standard que s appuyent de nombreux outils CAD pour la création de plateformes virutelles pour la simulation : si UML est un bon langage de spécifications et de conceptions, IP-XACT reste le meilleur pour effectuer l instanciation de composants. Toutefois, cet enchaînement présente à nos yeux encore quelques lacunes, principalement identifiées par les croix rouges que nous avons insérées dans notre nouveau flot de la figure 4.7. Nous les décrivons dans les sous-sections suivantes Les intéractions avec IP-XACT inexistantes Comme nous l avons spécifié au début de ce chapitre, IP-XACT est une donnée que nous devons prendre en compte : c est aujourd hui le format d échange de composants le plus utilisé. Il propose de plus des méthodes d identification des composants et des protocoles permettant d établir des règles de connections très strictes. Celles-ci permettent de garantir l assemblage des composants, et les profils tels que MARTE ou UML for SystemC n adressent malheureusement pas aussi bien cette problématique. A titre d exemple, là où IP-XACT introduit jusqu à 6 catégories de points de connection différents pour un composant (appelés BusInterface : Master, Slave etc. ), le standard MARTE ne propose qu un seul stéréotype appelé HWEndPoint. En UML for SystemC, les contraintes de connection sont précisément celles du langage SystemC, et imposent donc de descendre au niveau de l implémentation pour savoir si deux composants sont effectivement interconnectables (dépendant donc du niveau d abstraction manipulé). Reproduire ces mécanismes d IP-XACT permet de s assurer que l intégration de composants existants dans le flot de conception sera effectivement possible. De plus, un import depuis IP-XACT vers UML permettrait d inclure dans un flot UML des composants venant de vendeurs externes, par exemple en les annotant avec le profil MARTE pour de l analyse d architecture. Enfin un export d UML vers IP-XACT peut aussi être appréciable, permettant d insérer des nouveaux composants générés à partir UML dans des outils CAD classiques Support de plusieurs vues pour un composant Dans le flot de conception, nous avons vu qu un même composant va être représenté par plusieurs vues. L analyse d architecture impose par exemple la réalisation d un modèle annoté de propriétés non fonctionnelles grâce à MARTE, mais ne rentrant pas dans les détails de l implémentation du composant. A contrario, lorsque l on désire créer des modèles simulables, un profil se focalisant sur l implémentation tel qu UML for SystemC peut être utilisé, permettant de créer des vues TLM PV,PVT ou encore Cycle Accurate. Nous voyons qu un seul composant peut être accompagné d au moins quatre descriptions différentes. Ce nombre peut de plus augmenter lorsqu on manipule des composants hiérarchiques, qui peuvent être vu suivant les cas comme des boîtes noires, ou comme un assemblage de composants. Il semble donc important de fournir une manière cohérente de gérer ces différents modèles. De plus, dans cette approche, ces modèles sont autant de réécritures et de réinterprétations de spécifications à différents niveaux d abstraction. Il nous paraît capital de limiter ces réécritures et de fournir un moyen d en automatiser le maximum. 58/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

59 4.3. Solution proposée : le profil Electronic System Level 4.3 Solution proposée : le profil Electronic System Level Présentation générale Les travaux que nous avons réalisés au cours de cette thèse ont donc porté sur la résolution de ces problématiques. La solution que nous proposons est d introduire dans ce flot un nouveau profil, appelé profil ESL. Le but de celui-ci est multiple : Fournir une interopérabilité avec le format IP-XACT en import et export ; Fournir des règles de connexions précises garantissant le respect de contraintes de compatibilité ; Fournir un meilleur moyen de dissocier les spécifications d un composant de ses diverses implémentations. Nous proposons pour ceci la réalisation d un unique modèle de spécifications comportant un maximum d informations communes à toutes les implémentations possibles (incluant notamment la carte des registres des composants), et d automatiser grâce à l IDM le passage de ce modèle de spécifications vers des modèles d implémentation exploitant des profils particuliers à un langage ou à un niveau d abstraction donné. Fournir un moyen de garder un lien de traçabilité entre le modèle de spécifications et les modèles d implémentations Positionnement dans le flot de spécifications FIG. 4.8 Positionnement du profil ESL dans le flot de spécifications La figure 4.8 nous montre comment se situe le langage que nous avons défini dans le flot de conceptions. Nous proposons de l utiliser conjointement avec le profil MARTE pour la création de modèles d architectures. Le format IP-XACT étant le format standard accompagant les codes d implémentation des composants existants, notre profil va donc permettre l import de ceux-ci dans un flot UML. Le respect des règles de connexions proposées par ce standard de l électronique nous garantit que les architectures construites dans les modèles UML d exploration prendront en compte les contraintes de compatibilités nécesaires à l intégration effective des composants dans une plateforme. Ces composants pourront alors être annotés de propriétés non fonctionnelles avec les stéréotypes du profil MARTE Sébastien Revol Thèse de doctorat 59/161

60 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC pour effectuer les opérations d analyse d architecture (ces informations ne sont effet pas supportées par IP-XACT). Une des particularités d IP-XACT est de proposer une dissociation entre les informations qui caractérisent un composant quel que soit le langage et le niveau d abstraction de ses implémentations, et la façon dont elles sont effectivement implémentées. C est par exemple le cas des points de connexion du composant (BusInterface) qui sont typés par un procotole de communication (BusDefinition). Ces protocoles sont définis une fois pour tout niveau d abstraction (TLM ou RTL) et ce n est qu ensuite qu il est précisé comment le code du composant manipulé implémente réellement ces points de connections (opération de PortMap, éventuellement à travers la notion de abstractiondefinition cf section ). Notre flot se basant sur une approche générative, nous proposons de ne garder dans le profil ESL que les informations communes à toute implémentation. Celles-ci pourront alors être interprétées par des transformations de modèles pour créer une grande partie du modèle d implémentation. L expérience fournie par l outil TLMSkeleton de STMicroelectronics nous a en effet conforté dans l idée qu une description IP-XACT, incluant aussi la carte de registres des composants, permettait d obtenir une part importante de l implémentation SystemC-TLM du composant seulement à partir de sa description IP-XACT (nous verrons dans le chapitre 7 Etude de cas de ce mémoire que cette part peut monter à plus de 97% du code). Ainsi si la procédure d analyse d architecture a mené à la définition d un nouveau composant, celui-ci pourra être spécifié à l aide du profil ESL, et son modèle d implémentation dans un langage spécifique et dans un niveau d abstraction en sera partiellement déduit. La maturation du standard IP-XACT étant relativement récente (présentation officielle de la version 1.4 intégrant des concepts ESL en mars 2008), les solutions de l état de l art ne proposaient jusqu à peu aucun positionnement clair entre ce standard et UML. Notre initiative peut tout de même être comparée à cette référence [11] proposée par les membre du projet AOSTE de l INRIA lors d un workshop dédié à MARTE en marge de la conférence internationale DATE 4. Si nos motivations sont assez semblables, nous noterons que nous avons plus insisté sur la dissociation entre un modèle de spécifications et un modèle d implémentation, se traduisant par une traduction légèrement différente des concepts d IP-XACT en UML. Dans notre approche, la dissociation entre spécification et implémentation se fait par l utilisation de profils spécifiques à un langage, comme le profil UML for SystemC. Ainsi nous proposons d utiliser des transformations générant ces modèles spécifiques à une implémentation en interprétant les informations fournies par le profil ESL dans le modèle de spécification. De plus nous introduisons dans notre profil le moyen d établir des liens de traçabilité entre les éléments spécifiés dans les modèles ESL, et les éléments correspondants dans le modèle d implémentation. Ceci nous permet à la fois de garder une tracabilité au cours de l évolution du flot pour gérer les nombreuses vues impliquées, mais aussi d obtenir la description complète du fichier IP-XACT permettant de manipuler l implémentation d un composant nouvellement généré. Actuellement, la solution que nous proposons se focalise essentiellement sur la partie structurelle de la spécification des composants. Le comportement de ceux-ci est alors à complèter pour chaque niveau d abstraction des implémentations ciblées, directement dans le profil UML for SystemC. Cependant, comme nous le verrons par la suite, les informations structurelles telles que les descriptions de registres, mais aussi le type de protocole de communication (lorsque celui-ci est un protocole courant) peuvent être interprétés par la transformation générant alors une grande partie du comportement dans le modèle d implémentation. De plus les notions introduites par le profil ESL nous laissent entrevoir la proposition d un modèle de description comportementale à plus haut niveau d abstraction 4 Cette conférence a eu lieu en mars 2008, alors même que nous étions en train de rédiger ce manuscrit 60/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

61 4.4. Conclusion qu UML for SystemC. Ce modèle aurait pour but de faciliter l intégration d algorithmes spécifiés dans les modèles fonctionnels des étapes précédentes du flot, et permettrait de générer automatiquement des constructions SystemC intégrant ce comportement. Cette approche semble particulièrement prometteuse pour la réalisation rapide de modèle TLM-PV, dont le but est précisemment d encapsuler et d interfacer via les port et les registres des composants matériels les algorithmes de traitement provenant de standards et de spécifications antérieures. 4.4 Conclusion Au cours de ces trois derniers chapitres, nous avons pu comprendre les principes du flot de conception des systèmes sur puce et étudier comment un flot basé sur les technologies de l IDM pouvait améliorer certaines lacunes. En se basant sur notre analyse de l état de l art, nous avons pu identifier des solutions mais aussi des points encore manquants à la réalisation d un flot IDM pour la conception des systèmes sur puce. Ainsi nous proposons d utiliser un nouveau langage visant principalement à apporter dans une approche UML certains bénéfices offerts par le standard IP-XACT, toute en permettant une interopérabilité et une complémentarité avec ce format. L objectif principal de ce profil est de fournir des informations complémentaires à celles offertes par le standard MARTE pour la description du matériel. Nous cherchons ainsi à obtenir un unique modèle de spécification des composants et des plateformes concentrant un maximum d informations à la fois fonctionnelles et non fonctionnelles, offrant une base solide pour les développements en aval du flot. Pour ceux-ci, et plus particulièrement pour le développement matériel, nous proposons ensuite d intégrer les travaux fournis par différentes équipes de STMicroelectronics, en se reposant sur le profil UML for SystemC notamment pour la génération de modèles au niveau transactionnel. Dans les chapitres suivants de ce manuscrit, nous allons maintenant nous attacher à décrire en détails comment nous avons construit notre profil ESL. Nous présenterons ensuite comment nous avons pu au cours de cette thèse exploiter ce langage pour l intégrer efficacement dans les méthodes de conceptions de STMicroelectronics. Ceci s est principalement effectué par le développement de transformations de modèles et de générateurs de code que nous présenterons. Enfin, par le biais d une étude de cas, nous viserons à évaluer les avantages fournis par notre approche, et discuterons aussi de ses limitations et possibles ouvertures. Sébastien Revol Thèse de doctorat 61/161

62 Chapitre 4. Analyse de l utilisation d UML et l IDM dans les flots de spécification des SoC 62/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

63 Deuxième partie Définition et exploitation d un profil UML pour la modélisation au niveau Système Electronique (ESL) 63

64

65 Chapitre 5 Le profil UML pour la modélisation au niveau Système Electronique Sommaire 5.1 Organisation des concepts Le paquetage Component Présentation générale Contenu du paquetage Portage sur le langage UML Le paquetage Register Map Présentation générale Motivations Les modèles de registres Le modèle de domaine du paquetage Register Map Le sous-paquetage TLM Behaviour Portage sur la syntaxe UML : définition des stéréotypes Le paquetage BusInterface Présentation générale Motivations Les modèles d interconnections Définition du paquetage BusInterface Le paquetage Hierarchy Présentation générale L approche IP-XACT de la hiérarchie Les approches UML Définition du paquetage Hiérarchie Le paquetage Implementation Présentation générale Principe de l association Conclusion L analyse de l état de l art réalisée dans les chapitres précédents nous a amené au besoin d introduire un langage pivot facilitant l intégration des approches reposant sur UML dans le contexte 65

66 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique industriel de l ingénierie électronique. Nous allons dans cette partie présenter le profil que nous avons développé pour répondre à ce besoin. La construction de celui-ci s est réalisée en deux principales étapes. Dans un premier temps, nous avons réalisé un modèle de domaine identifiant, à la manière d un méta-modèle, les concepts que l on désire exprimer par notre langage. Un modèle de domaine diffère d un méta-modèle dans le sens où il ne tient pas compte de tous les éléments propres au langage sur lequel sont portés les concepts. Dans notre cas, le méta-modèle est au final celui d UML augmenté de notre profil, alors que le modèle de domaine se focalise uniquement sur les concepts métiers à représenter. Nous avons par la suite porté ces concepts sur la syntaxe UML par le biais du mécanisme de profil. Comme nous l avons précisé dans 4.3.2, ce langage se situe à l intersection d un flot UML topdown, de l approche de réutilisation proposée par IP-XACT et de la modélisation comportementale telle qu elle est proposée par l approche SystemC-TLM. De ce fait, les concepts introduits dans notre langage vont se rapporter à chacun de ces domaines. Ce chapitre est structuré de la manière suivante : dans un premier temps, nous allons identifier les éléments clés de notre profil, permettant de dégager la structure de ce langage en termes de paquetages. Par la suite, nous reviendrons sur chacun de ces paquetages en en détaillant le contenu. Nous prendrons soin pour chacun des concepts introduits de préciser les raisons qui nous ont poussé à les définir. De plus nous justifierons la manière dont nous les avons portés sur le langage UML en nous référant à des approches similaires retrouvées dans l état de l art. 5.1 Organisation des concepts Comme nous venons de l introduire, la première étape de la contruction de notre langage a été d identifier les concepts que nous désirions manipuler à travers celui-ci. Plus particulièrement, puisqu un de nos objectif était d assurer une interopérabilité avec IP-XACT, il nous a fallu déterminer les concepts de ce standard que nous voulions restranscrire au niveau UML. Interopérabilité ne signifie pas équivalence : tout comme certaines notions d UML ne sont pas exprimables en IP-XACT, le portage en UML des concepts d IP-XACT ne s est fait que sur un sous-ensemble de son méta-modèle. Le but étant alors de tirer profit des atouts de ces deux langages tout en assurant une cohérence entre des modèles exprimés dans chacun de ces deux formats. Les mécanismes d IP-XACT pour l identification des composants et la définition de contraintes strictes de connexions entre ceux-ci sont des points clés qui ne sont pas aussi bien abordés dans les approches UML classiques. Ils permettent en effet de garantir l intégration effective des composants finaux dans une plateforme, et nous avons donc choisi des les reporter dans notre langage. Les concepts correspondants ont été ainsi regroupés dans 3 paquetages : Component introduisant la notion centrale de composant matériel, et la façon dont celui-ci compose les autres concepts introduits dans les différents paquetages. Bus Interface définissant les concepts permettant l identification et le typage des procoles de bus, afin d assurer des mécanismes de connexion entre les composants. Hierachy décrivant comment exprimer la hiérarchie dans notre langage, permettant ainsi de considérer un assemblage de composants comme un composant de niveau hiérarchique supérieur. De plus, la notion de registre (que nous détaillerons dans la section 5.3) est un élément important dans la modélisation structurelle mais aussi comportementale des composants. En effet, les registres reflètent généralement l état d un composant à un instant donné et fournissent un moyen aux autres 66/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

67 5.1. Organisation des concepts éléments du systèmes de communiquer avec lui par des opérations de lecture et d écriture. IP-XACT fournit un moyen de décrire de manière précise les cartes de registres d un composant. Nous avons donc décidé de le retranscrire dans notre langage afin de pouvoir l exploiter ses concepts à travers UML et les technologies IDM. Ces notions ont été regroupées dans un quatrième paquetage appelé Register. Enfin, nous avons annoncé qu un de nos objectifs était de fournir une dissociation nette entre les modèles de spécification et d implémentation et d assurer la gestion entre ces différentes vues. IP-XACT aborde ce sujet en apportant un moyen d exprimer dans ses modèles des informations spécifiques à chacun des fichiers de code qu il encapsule. Dans le cadre d un flot UML, l approche est légèrement différente, et nous avons décidé de reposer sur des profils spécifiques à un langage, tel qu UML for SystemC pour spécifier ces informations. Toutefois, nous désirons être capable de pouvoir réinjecter dans des outils CAD des composants issus d un flot de génération se basant sur UML, et avons donc besoin de la description IP-XACT correspondante. Plutôt que de retranscrire dans les modèles de spécification des informations se trouvant dans les modèles d implémentation, nous avons défini dans notre langage un moyen d établir des liens entre ces deux types de modèles. Ces associations nous procurent le double avantage de pouvoir obtenir la description IP-XACT encapsulant les fichiers issus de la génération de code depuis les modèles d implémentation, et de garder un lien de traçabilité facilitant la gestion entre les différentes vues d un composant. Ces concepts ont été regroupés dans un nouveau paquetage appelé Implementation. L organisation de ces paquetages est représentée dans la figure 5.1. On remarquera que les relations de dépendance (import) entre ceux-ci sont linéaires : chaque paquetage introduit des notions sur lesquelles se basent les éléments des paquetages suivant dans l ordre des imports. Toutefois, nous commencerons notre description par le paquetage Component qui nous permettra d avoir une vue globale de la strcture de notre langage. Puis nous continuerons notre description en reprenant l ordre des imports successifs. FIG. 5.1 Organisation des paquetages du langage ESL Sébastien Revol Thèse de doctorat 67/161

68 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique 5.2 Le paquetage Component Présentation générale Le paquetage Component est le point central du profil. Nous le présentons en premier car il va nous permettre d introduire toutes les notions qui seront développées dans chacun des paquetages suivants. Une des caractéristiques principales de notre langage est qu il ne fournit aucune information sur la fonctionnalité d un composant. Dans les approches visant l analyse d architecture telles que [47, 5, 115, 94, 60], le rôle que va jouer tel ou tel composant dans le système est une information importante. Ainsi, les notions de ressource d exécution, de communication ou de stockage, accompagnées de caractéristiques qui leur sont propres telles la capacité, la latence, la fréquence etc. apparaissent fréquemment dans les langages qui accompagnent ces approches. Le modèle de matériel sert dans ces cas de support pour l expression du déploiement d un modèle fonctionnel sur une architecture, afin de permettre une étude sur la qualité de services système résultant, sa consommation énergétique etc. Comme nous l avons introduit dans la section 4.3.2, le but de notre profil est autre. Alors que les profils d analyse décrivent généralement les composants comme une boîte noire possédant certaines caractéristiques, le but du langage ESL est d ouvrir cette boîte et de décrire comment est fait le composant. Ainsi, tout comme SystemC qui n introduit qu une seule classe sc module pour définir un composant, il n y aura dans notre profil qu un seul stéréotype, HW- Component, pour déterminer tout composant. En s appuyant sur le travail du consortium SPIRIT pour l élaboration du standard IP-XACT, le langage va alors recenser un certain nombre de caractéristiques communes à tout type de composant, quelle que soit sa fonctionnalité, donnant des informations sur la façon dont il est implémenté physiquement. De plus, un des challenges de notre langage est de retranscrire ces informations sans prendre partie d un niveau de modélisation particulier (RTL, TLM, BCA etc.), ni du langage d implémentation du composant, afin de permettre une dérivation automatique vers plusieurs types d implémentations à partir d une même description Contenu du paquetage FIG. 5.2 Structure générale d un composant dans le langage ESL. 68/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

69 5.2. Le paquetage Component La figure 5.2 montre l intérieur du paquetage Component. En réalité, la seule classe introduite dans ce paquetage est la classe HWComponent, les autres étant importées des autres paquetages qui constituent le modèle de domaine de notre langage. Afin d assurer la compatibilité avec le format IP-XACT, nous avons doté les composants matériels des identifiants Vendor, Library, Name, Version, sur lequel repose le système de référence d IP-XACT. En effet, dans le contexte de l ingénierie électronique, les composants évoluent constamment, et leurs caractéristiques avec. Aussi, dans une approche de réutilisation, l identification précise du composant est essentielle, une version antérieure ou ultérieure n étant pas forcément compatible pour une intégration dans un système donné. Nous verrons par la suite que d autres notions telles que la définition d un protocole de bus (BusDefinition) ou l assemblage de composants (Design) possèdent elles aussi cet identifiant. On voit alors dans la figure comment un composant est relié aux autres éléments que nous allons définir dans notre langage. On peut constater que par l attribut ownedregmap un composant peut contenir des cartes de registres que nous présenterons dans la section On peut aussi remarquer qu un composant peut posséder des interfaces de bus (par le rôle ownedbusifs), qui comme nous le verrons dans la section 5.4 correspondent aux points de connexion du composant. Nous verrons aussi dans cette section que nous en distinguons deux catégories (interfaces initiatrices et interface cibles) et qu elles s utilisent conjointement avec des contrôleurs d interface de bus (InitiatorBusIfCtrlr et MasterBusIfCtrlr). Nous expliquerons pourquoi une carte de registre peut être considérée comme un type particulier de contrôleur d interface de bus cible. Enfin, la section 5.5 démontrera comment un composant peut être utilisé dans une vue hiérarchique (HierarchyRef ) et la section 5.6 comment il peut être connecté à un modèle d implémentation (ComponentImpl) Portage sur le langage UML Nous traitons ici de la façon dont nous avons décidé de représenter la notion de composant matériel. Le langage UML propose dans son méta-modèle plusieurs alternatives potentiellement exploitables, avec notamment le diagramme de déploiement, le diagramme de composants et le diagramme de structure composite. La représentation d un composant matériel dans chacun de ces diagrammes exige de choisir une méta-classe UML à spécialiser différente : le Node pour le déploiement, le Component pour le diagramme de composants, qui peut aussi se représenter avec la Class dans le diagramme de structure composite. Nous discuterons plus en détail dans la section sur les modèles d interconnexion du paquetage BusInterface quel est le diagramme le plus adapté. Chacun présente en effet des moyens différents d exprimer et de contraindre les interconnections entre des instances d entités communicantes. Nous verrons que comme dans la plupart des approches récentes, nous avons choisi le diagramme de structure composite. Ce dernier diagramme autorisant la représentation de l instanciation des Components et des Class, la discussion porte sur le choix entre l une de ces deux méta-classes. Il faut savoir que depuis la version 2.0 d UML, le Component est défini comme un type particulier de Class, héritant ainsi de toutes ses caractéristiques. Cependant, la sémantique du composant UML spécialise celle de la classe, afin de le considérer comme une abstraction, une coquille servant à regrouper entre elles un ensemble de classes remplissant un groupe cohérent de fonctionnalités. En conséquence, le mécanisme de définition/instanciation que l on utilise notamment dans le diagramme de structure composite pour déterminer la structure interne d une classe est lui aussi étendu par un étage supplémentaire. Ainsi la structure d un composant peut consister en la définition de ses réalisations, c est à dire en la définition de classes (et non plus d instances) qui constituent la fonctionnalité identifiée par le composant. Dans ce cas-là une instance de Component n a pas de réalité en Sébastien Revol Thèse de doctorat 69/161

70 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique soi, et elle se traduit en fait par l instanciation de toutes les classes qui définissent sa réalisation 1. Bien que ces capacités du composant puissent être exploitables pour la modélisation matérielle, notamment pour la dissociation entre spécification et implémentation, leur sémantique est fortement influencée par les concepts retrouvés dans la conception logicielle à base de composants tels qu EJB, DOTNET etc. (cf. profils inclus à la fin de la norme d UML [91]). Ainsi même si certains profils comme le profil Gaspard de l INRIA [13] ont décidé d étendre la notion de Component pour représenter les composants matériels, ils n exploitent en réalité que les capacités héritées de la classe. De ce fait, nous avons décidé de représenter notre notion de HWComponent en étendant directement la méta-classe Class comme le montre la figure 5.3. FIG. 5.3 Le stéréotype HWComponent 5.3 Le paquetage Register Map Présentation générale La notion de registre est un point important dans la modélisation d un composant électronique. D une manière générale, un registre est un moyen de stockage élémentaire de champs de bits. Un composant qui contient des registres va donc s en servir pour lire ou écrire des données temporaires. De plus un registre peut généralement être accédé depuis l extérieur du composant, par exemple par un programme s exécutant sur un processeur connecté au même médium de communication que le composant possédant le registre. Plusieurs politiques d accès existent, certains ne peuvent être que lus, d autres qu écrits, d autres autorisent les deux. Le registre représente un des mécanismes les plus élémentaires pour la transmission d informations entre les éléments d un circuit, servant tout particulièrement pour la communication entre le logiciel et le matériel. En effet, bien que l on retrouve souvent différentes couches d abstraction du matériel dans un système d exploitation, permettant au programmeur d avoir recours aux fonctionnalités d un composant sans avoir à rentrer dans ce niveau de détail, la majorité des appels à ces fonctionnalités se traduisent dans les logiciels de bas niveau par une succession de lectures et d écritures dans les registres de ce composant. La description d un carte de registres d une IP constitue en quelque sorte le mode d emploi de ce composant. Considérons par exemple le tableau 5.4. Il montre une description simplifiée d une carte de registres d un Timer, composant servant à décompter une valeur d une manière continue au cours du temps. Trois registres sont décrits dans ce 1 Le méta-modèle d UML traduit cette possibilité par l introduction de l attribut isindirectlyinstantiated dans la métaclasse Component. 70/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

71 5.3. Le paquetage Register Map Carte de registres Décalage Registre Champs du registre X00 TimerLoad Valeur sur 16 bits Accès RW 0X02 TimerControl Non définis TE TM IE P TS OC Accès RW RW RW RW RW RW 0X04 TimerValue Valeur sur 16 bits Accès RO FIG. 5.4 Exemple de tableau décrivant une carte de registres tableau : TimerLoad, TimerControl et TimerValue. On voit que chacun de ces registres comporte 16 bits. TimerLoad représente la valeur initiale à partir de laquelle le timer va décompter. Elle est codée sur 16 bits, et est en accès RW (Read-Write), ce qui signifie que le programmeur peut lire et modifier cette valeur. TimerControl est un registre de contrôle. Il va permettre d influencer le comportement du timer. On voit dans ce tableau que certains bits ou groupes de bits sont distingués les uns des autres. Par exemple le bit numéro 6, TE (pour Timer Enable) permet d activer ou désactiver le timer, suivant qu on positionne ce bit à 1 ou 0. Le champ P (Prescale) comportant les deux bits 3 et 2, sert à moduler la vitesse du décompte. Il peut posséder plusieurs valeurs : 00 signifie qu il décompte à la même vitesse que la fréquence d horloge, 01 signifie que la fréquence est divisée par 16, 10 que la fréquence est divisée par 256. La valeur 11 n est pas définie, et le comportement du timer lorsque le champ est à cette valeur est indéterminé. De même on voit que les bits de 7 à 15 ne sont pas définis, ce qui signifie que leur valeur n a pas de sens en soi, leur écriture ne devant pas influencer le comportement. TimerValue représente la valeur courante du décompte. Elle est seulement accessible en lecture seule, car en constante modification par le timer lorsqu il est activé, elle ne peut pas être modifiée de l extérieur. Cet exemple nous procure un aperçu des concepts mis en jeu dans la description d une carte de registres d un composant. Notons que chaque registre est accédé par une adresse. Celle-ci est généralement désignée à l aide d un nombre hexadécimal, spécifié dans notre exemple dans la colonne décalage. Cette adresse est relative par rapport à l adresse de base de la carte à laquelle le registre appartient. En effet un composant peut comporter différents champs de registres, chacun situé à une adresse de base différente. De plus, chaque composant comporte lui-même une adresse de base qui lui est attribuée lors de sa connexion à un médium de communication, si bien qu au final l adresse d un registre vaut : addr reg = addr comp + addr carte + addr décalage Motivations Au point du flot global de conception des SoCs où se situe notre langage, la carte des registres est une caractéristique importante de la modélisation matérielle. Comme nous l avons dit dans la section 4.3.2, le profil ESL se situe dans la branche matérielle du flot de conception, tout de suite après le partitionnement Logiciel/Matériel. Avant cette phase, il n est généralement pas nécessaire Sébastien Revol Thèse de doctorat 71/161

72 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique de connaître les registres d un composant, car le rôle de ceux-ci est principalement de permettre une communication entre le logiciel et le matériel. En revanche, dès que le système est partitionné, il est primordial que cette interface soit figée pour permettre le développement parallèle du matériel et du logiciel. Ce n est d ailleurs pas pour rien que le premier niveau de représentation du matériel dans la modélisation transactionnelle, qui est chez STMicroelectronics la première modélisation du matériel après le partitionnement Matériel/Logiciel, s appelle la Programmer s View (PV), vue du programmeur en Français. Celle-ci doit fournir une implémentation fidèle de la carte des registres de chaque composant pour que le vrai logiciel embarqué puisse être simulé sur ces modèles. Ainsi cette carte doit non seulement être connue du développeur logiciel, mais aussi du développeur de modèles du matériel au niveau TLM et pour tous les niveaux de précision supérieure. Il nous est donc paru important d incorporer dans notre langage cette caractéristique propre aux composants, et indépendante de leur langage d implémentation. Nous verrons par la suite dans le partie 6.4 que c est d ailleurs cette description qui va être à l origine de la partie la plus importante du code généré des modèles TLM, partie qui est aussi une des plus fastidieuses à développer à la main, lorsque l on sait que certaines IP peuvent posséder plusieurs centaines de registres Les modèles de registres Les concepts que nous introduisons dans notre langage s inspirent très fortement de ceux proposés par le standard IP-XACT. En effet, celui-ci propose un moyen très complet de faire la description de la carte des registres d un composant. Dans une approche de réutilisation, cette description peut jouer le rôle de documentation de l IP et peut être visualisée et éditée dans des éditeurs spécialisés tels que Magillem [7]. Elle favorise aussi l automatisation, en permettant par exemple l utilisation de générateurs se basant sur cette description pour la configuration automatique du logiciel embarqué. Dans une approche de conception, le modèle IP-XACT des registres de l IP peut aussi être exploité pour la génération de son implémentation dans un langage particulier, comme le fait l outil TLM-Skeleton de STMicroelectronics. Cependant, il est à noter qu étrangement la notion de registre n existe pas du tout dans le langage SystemC, ni même dans les bibliothèques de classes du standard TLM. Les concepteurs de modèles PV sont laissés libres dans leur implémentation de ce concept, qui peut par exemple se faire en codant les 32 bits d un registre sur les 32 bits d une variable de type int. Dans le cadre du flot IP-XACT vers SystemC-TLM de STMicroelectronics, des classes de registres spécifiques ont été réalisées, facilitant la génération d une partie du code d implémentation, et unifiant aussi la façon de modéliser et manipuler les concepts de registre. Cette absence de notion de registre dans SystemC se retrouve dans les profils UML destinés à la génération de code. En effet, le profil SystemC est une transcription un-pour-un des concepts de SystemC au niveau UML. De ce fait la notion de registre n y est pas introduite, et l utilisateur du profil devra user des mêmes techniques que celles d un développeur C++ classique pour les modéliser. De même, le profil SoC de l OMG [136, 85], lui aussi très proche de SystemC n aborde pas ces concepts. Les profils destinés à l analyse d architecture ne rentrent pas, eux non-plus, dans ce niveau de détail, la description structurelle du matériel visant plus à identifier des caractéristiques non-fonctionnelles de celui-ci qu à exprimer des informations sur son implémentation. Au final, nous n avons à ce jour pas identifié de profil UML proposant une représentation exploitable de la notion de registre. 72/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

73 5.3. Le paquetage Register Map Le modèle de domaine du paquetage Register Map FIG. 5.5 Modèle de domaine du paquetage Register Map La figure 5.5 décrit les concepts manipulés par le paquetage Register Map de notre langage. Ce paquetage s articule autour de 3 concepts principaux : la RegisterMap, le Register et le Field. Cependant, comme on peut le voir, chacun des ces concepts se divise en deux méta-classes, exprimant la relation type/instance. Ainsi, la création d un registre va se faire en deux étapes : sa définition et son instanciation. Ce mécanisme peut sembler complexifier la tâche. IP-XACT par exemple ne propose pas ce mécanisme : la création d un registre s y fait par l entrée systématique de toutes ses caractéristiques. Cependant, il s avère que de nombreux composants proposent des structures répétitives. Par exemple, un contrôleur d accès direct en mémoire (DMA) peut comporter plusieurs dizaines de canaux de communications, chacun possédant plusieurs registres de contrôle identiques pour chaque canal. La définition de ces registres en IP-XACT va se faire en rentrant pour chaque canal des données identiques, les registres ne variant que par leur adresse de décalage, ce qui peut devenir une tâche très fastidieuse. Le mécanisme type/instance résout ce problème. Ainsi, nous avons identifié pour chacun des concepts les caractéristiques qui sont propres à l instance, de celles qui peuvent être génériques à plusieurs instances de registres. Considérons la classe RegisterMap. Elle représente l instance d une carte de registres. Elle possède un nom (name), ainsi qu un attribut addressoffset spécifiant son adresse de décalage. Pour simplifier l édition, nous n avons pas créé de type particulier pour les adresses et d une manière générale les nombres hexadécimaux. Comme ces derniers contiennent des lettres, nous les avons simplement représentés sous forme d une chaîne de caractère. Une solution plus précise aurait été de procéder à l image du Value Specification Language du profil MARTE, en définissant des types primitifs ainsi qu une grammaire associée permettant de vérifier la conformité des valeurs spécifiées. Ce point devra être traité dans le version opérationnelle du profil et de l outil support. De plus, la classe RegisterMap possède un attribut def pointant vers son type RegisterMapDef. Celui-ci possède trois autres attributs particuliers : le nom name, l attribut addressrange, qui permet de spécifier la plage d adresses dans laquelle vont se situer les différents registres qu elle va posséder, ceux-ci étant identifiés par le dernier attribut ownedregs. Ainsi, la dissociation type/instance va permettre à un composant de posséder différentes instances d une même définition de carte de registres, chacune possédant un nom différent et une adresse de décalage différente. L attribut accesstype per- Sébastien Revol Thèse de doctorat 73/161

74 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique met de définir comment il sera possible d accéder à la carte de registres. Il est typé par l énuméré AccessType, qui peut être de valeur Read-Only pour un accès en lecture seule, Write-Only pour un accès en écriture seule, et Read-Write pour un accès mixte. Notons que la cardinalité de l attribut ownedregs est, ce qui signifie que le nombre de registres dans une carte peut varier entre 0 et l infini. Le cas particulier où le nombre est 0 correspond à une plage d adresses accessible (déterminée par addressrange, et permet de définir une zone de mémoire. Sur le même principe de dissociation type/instance, une instance de registre est déterminée par la classe Register, et son type par la classe RegisterDef. La définition d un type de registre va permettre de spécifier les champs de bits que contient le registre (désigné par l attribut ownedfields, son nom (name)), sa taille en nombre de bits (size), sa valeur au reset (resetvalue) ainsi que son type d accès (accesstype). Il faut noter qu une certaine cohérence est à respecter entre la valeur du type d accès des registres et celui de la carte qui le contient : une carte ne peut posséder de registre avec un accès en écriture que si elle autorise elle-même l accès en écriture, et de même pour la lecture. Ceci se traduit par la contrainte OCL suivante : context RegisterMapDef inv: self.ownedregs->select(r r.def.accesstype<>#read-only)->notempty() implies self.accesstype<>#read-only and self.ownedregs->select(r r.def.accesstype<>#write-only)->notempty() implies self.accesstype<>#write-only Tout comme une instance de RegisterMap, une instance de Register possède un nom en propre, ainsi qu une adresse de décalage (relative à la carte à laquelle elle appartient). On notera ici aussi qu un registre peut ne posséder aucun champ de bit (cardinalité du champ ownedfields). Cela est en fait un raccourci pour spécifier que le registre possède un unique champ dont la taille est directement égale à la taille du registre (comme par exemple le registre TimerLoad dans le tableau 5.4). Enfin, les champs de bits à l intérieur des registres se construisent eux aussi sur le même principe. La classe FieldDef caractérise la définition d un tel champ. Elle possède un nom, l attribut bitwidth, permettant de spécifier la taille du champ en nombre de bits, un type d accès, et peut définir des valeurs (fieldvalues). Celles-ci, se constituant d une paire (nom, valeur) permettent d identifier des valeurs particulières que peut prendre un champ de bit. Dans notre exemple de la section 5.3.1, nous avons vu que le champ P du registre TimerControl définit trois de ces valeurs, que l on peut caractériser par les couples suivants : (DivideBy1, 00), (DivideBy16, 01) et (DivideBy256, 10). Une instance de champ se caractérisera, elle, par son nom et son décalage en nombre de bits dans le registre (par exemple 2 pour le champ P du registre TimerControl). Enfin, nous noterons qu ici aussi, une cohérence doit être respectée sur les types d accès des champs et de celui du registre qui les contient : context RegisterDef inv: self.ownedfields->select(f f.def.accesstype<>#read-only)->notempty() implies self.accesstype<>#read-only and self.ownedfields->select(f f.def.accesstype<>#write-only)->notempty() implies self.accesstype<>#write-only On peut aussi rajouter une contrainte supplémentaire sur la taille et le décalage d un champ en fonction de la taille du registre qui le contient : un champ ne doit pas déborder du registre. Cela se traduit par la contrainte suivante : 74/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

75 5.3. Le paquetage Register Map FIG. 5.6 Le registre du paquetage TLM-Behaviour context RegisterDef let regsize: Integer = self.size in inv: self.ownedfields->forall(f f.bitoffset + f.def.size <= regsize) Le sous-paquetage TLM Behaviour Comme nous l avions introduit dans la présentation du langage, il ne nous a pas été possible de spécifier la partie comportementale de la modélisation des composants matériels au cours de cette thèse. Cependant, nous avons pu introduire rapidement quelques concepts comportementaux facilement éditables, pouvant être pris en compte par un générateur de code. La notion de registre est en effet un point clé à la frontière entre la structure et le comportement d une IP. Tout particulièrement, les registres dits de contrôle ont un effet direct sur le comportement du composant. Considérons par exemple le registre TimerControl du tableau 5.4. Nous avons décrit que son champ TE permettait d activer ou désactiver le décompte du Timer. En matière de codage SystemC-TLM, cela peut se traduire par le déclenchement d un événement interne au composant réveillant ou arrêtant son processus chargé d effectuer le décompte lors d une opération d écriture. Nous appellerons effet de bord cette capacité pour un registre d influencer le comportement du composant, et afin de couvrir tous les cas possibles que l on retrouve dans le comportement du matériel, on différenciera l effet de bord en lecture de l effet de bord en écriture. En effet, il arrive que cela soit uniquement l accès en lecture dans un registre qui déclenche un nouveau comportement du composant, ou uniquement son écriture. Comme le montre la figure 5.6, nous avons donc étendu le registre du paquetage Register Map, en lui rajoutant plusieurs attributs, et parmi eux les deux booléens hasreadsideeffect et haswritesideeffect. Nous le verrons dans la section 6.4, ces attributs seront interprétés et pris en compte dans le processus de génération de code. Ces deux attributs ne sont pas les seuls que nous avons rajoutés à notre modèle de domaine. Ainsi, nous pouvons voir que la classe Register étendue possède aussi deux autres attributs booléens issynchroread et issynchrowrite. Ces deux attributs viennent d un autre concept comportemental lié à la modélisation SystemC-TLM, et quelque part indirectement liée à la notion d effet de bord. Sébastien Revol Thèse de doctorat 75/161

76 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique En pratique, la détermination d un registre comme point de synchronisation permet de positionner un marqueur dans la transaction qui accède à ce registre afin de forcer une préemption de l ordonnanceur SystemC. En effet, du fait de sa politique d ordonnancement particulière et des principes de modélisation TLM, il se peut que certains processus (internes ou externes au composant contenant le registre) normalement influencés par la modification de ce registre ne soient jamais informés de celle-ci. L ajout de points de synchronisations permet d y remédier en une certaine mesure, mais il a le fâcheux inconvénient de ralentir fortement la vitesse de simulation, qui est pourtant le principal objectif de la modélisation transactionnelle. A l heure actuelle, la détermination à bon escient des points de synchronisation est toujours à la tâche du développeur de modèles TLM, et fait l objet de recherche notamment dans le cadre de partenariats entre STMicroelectronics et le laboratoire Vérimag [33]. Les attributs issynchroread et issynchrowrite d un registre seront donc eux-aussi pris en compte dans le processus de génération de code par l ajout d un marqueur de synchronisation dans la transaction. Nous insistons tout de même sur le fait qu il ne s agit là que d une solution temporaire dans notre flot UML. Bien que l ajout de ces notions ait quelques effets bénéfiques, comme améliorer la partie automatisée du flot, mais aussi proposer une meilleure analyse de comportement de l IP au développeur avant que celui-ci ne se plonge dans le code d implémentation, nous sommes conscients que ce paquetage rajoute des concepts propres à une implémentation particulière dans un langage qui se veut pourtant agnostique. Ces éléments nous fournissent une piste pour l élaboration d une partie comportementale au langage ESL. Par exemple, il semblerait judicieux d insérer directement dans le langage la notion d accès à un registre sur lequel des processus pourraient être sensibles. Une représentation de ce genre pourrait alors être interprétée en une succession d opérations en SystemC au moment de la génération de code, avec notamment l analyse des communications pour l insertion automatique des points de synchronisation, et ainsi intégrer le fruit des travaux de la collaboration en cours avec Vérimag. Enfin nous noterons aussi le dernier attribut keepfactorized, qui lui aussi est un patch spécifique au langage SystemC-TLM, permettant de spécifier au générateur de code comment représenter dans le code un ensemble d instances de registres du même types, regroupés ou non dans un vecteur. Cette notion temporaire est normalement de l ordre de la paramétrabilité de la transformation, comme nous en discuterons dans la section Portage sur la syntaxe UML : définition des stéréotypes Nous allons maintenant décrire comment nous avons porté les concepts du paquetage RegisterMap sur la syntaxe UML par l introduction de stéréotypes. Le mécanisme clé de notre approche pour la représentation des cartes de registres est la relation type/instance. C est tout naturellement que ce processus va s implémenter avec cette même relation définie dans le méta-modèle d UML entre la méta-classe Class (type) et la méta-classe Property (instance). Comme le montrent les figures 5.7 et 5.8, tous les concepts relatifs à la notion de définition étendent donc la méta-classe Class et ceux relatifs à l instance étendent la méta-classe Property. On note que cela est fait indirectement pour les stéréotypes RegisterMapDef et RegisterMap, car comme nous le verrons dans la section 5.4, une carte de registre est un type particulier de contrôleur d interface bus. On remarque que tous attributs du modèle de domaine deviennent des attributs des stéréotypes (tagged values), à l exception de chacune des relations de composition que l on retrouve par exemple entre la définition d une carte de registres et les registres qu elle possède (l attribut ownedregs de la classe RegisterMapDef ). En effet cette relation s appuie sur la même relation qui existe entre une 76/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

77 5.3. Le paquetage Register Map FIG. 5.7 Stéréotypes de définitions pour la carte de registres FIG. 5.8 Stéréotypes étendant le méta classe Property Class et une Property. Afin de garantir le respect du modèle de domaine, en plus de traduire sur le méta-modèle UML les contraintes que nous avons énoncé précédemment, il est nécessaire d en ajouter de nouvelles. En effet, tel qu il l est spécifié par le profil, n importe quelle Class peut posséder une Property stéréotypée Register. Ce n est bien sûr pas le cas, et seules les Class stéréotypées MemoryMapDef peuvent en posséder. De plus cette association entre Class et Property doit dans ce cas être de type Composite. Cela se traduit ainsi : context Register inv: self.base Property.class.isStereotyped( RegisterMapDef ) and self.base Property.aggregation = #composite Le même genre de contraintes sont définies pour les stéréotypes Field, FieldValue ainsi que RegisterMap, cette dernière ne peut être contenue que par un HWComponent (cf. 5.2). La figure 5.9 illustre l utilisation du profil pour l exemple du Timer, auquel nous avons apporté une légère modification : dans notre cas, le composant comporte en fait deux compteurs. De ce fait, tous les registres sont dédoublés. Ceci se voit sur la figure par la multiplicité des attributs de la classe TimerRegMap. Afin de pouvoir tout de même spécifier la valeur du décalage d adresse de chacune Sébastien Revol Thèse de doctorat 77/161

78 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG. 5.9 Exemple de définition de carte de registres des instances de registre, nous utilisons la tagged value addressoffsetmap du stéréotype Register. Il s agit d une collection ordonnée de valeurs de décalage, chacune de ces valeurs correspondant à un des registres de la collection correspondante. Ce mécanisme permet d éviter de passer par l approche classique d UML qui aurait consisté en un nouveau diagramme d objet spécifiant l instanciation de chacun des registres. Il procure ainsi un raccourci syntaxique, très efficace lorsque l on sait que le nombre d instance peut quelques fois atteindre plusieurs dizaines. Dans le cas de notre exemple, TimerControl[1] se trouve à l offset 0X002 et TimerControl[2] à l offset 0X008. Enfin on notera que presque tous les champs du registre ControlRegister sont typés par la même définition OneBitRWFieldType, ce qui démontre même dans ce petit exemple l utilité de la dissociation type/instance, évitant à l utilisateur de rentrer plusieurs fois les mêmes informations. 5.4 Le paquetage BusInterface Présentation générale Le paquetage BusInterface contient les concepts nécessaires à assurer le mécanisme d interconnexion entre les composants. Tout particulièrement, il va fournir les moyens d identifier de manière précise les contraintes permettant de spécifier que deux composants vont pouvoir effectivement être interconnectés. En effet, lorsque l on cherche à intégrer différents composants, venant parfois de différents vendeurs, dans un circuit, il faut être sûr qu il n y aura pas d incompatibilité et qu ils pourront communiquer. Les terminologies et concepts définis dans ce paquetage sont fortement inspirés de ceux employés par le standard IP-XACT, aussi très proches de ceux que l on retrouve dans la modélisation transactionnelle. Cependant nous verrons que certains concepts supplémentaires ont été introduits pour assurer un portage sur le langage UML, afin notamment d assurer les bases pour établir une description comportementale des communications (qui n a malheureusement pas pu être développée pendant cette thèse). Nous verrons aussi qu un effort particulier a été réalisé pour que cette description des sémantiques de connections reste indépendante du langage mais aussi du niveau d abstraction dans lequel le composant va être implémenté. 78/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

79 5.4. Le paquetage BusInterface Bien que ce mécanisme puisse s appliquer à d autres types d interconnects comme des réseaux sur puce (NoC) ou des connections point à point, les termes employés reprennent ceux définis par le type d interconnexion encore le plus courant de nos jours : le bus de communication. Ainsi le nom du paquetage BusInterface signifie littéralement interface de bus qui comme nous le verrons désigne le point de connexion d un composant à un bus de communication Motivations Nous touchons là le coeur de ce qui a motivé l initiative du consortium SPIRIT pour la définition du standard IP-XACT. En effet, dans une approche de réutilisation, il est essentiel de savoir si un composant va pouvoir effectivement s interfacer avec notre système. Fort de l expérience dans la conception électronique des nombreux partenaires qui figurent parmi les plus grandes compagnies mondiales dans le domaine, leur travail a permis d identifier des concepts clés pour parvenir à fournir une abstraction des interfaces des composants, et d assurer des règles de compatibilité pour leur interconnexion. Ces règles restent suffisamment génériques pour pouvoir s adapter à différents niveaux de modélisation, indépendamment du langage dans lequel seront implémentés les composants. C est donc assez naturellement que nous nous sommes tournés vers ce standard pour s inspirer des concepts qui nous ont semblé plus adaptés que ceux que l on retrouve dans les approches UML connues (cf section 5.4.3). Cependant, ils n ont pas été purement copiés, mais adaptés pour pouvoir tirer bénéfice du langage UML. Comme nous l avons dit dans la section 4.3.2, les objectifs d utilisation ne sont pas les mêmes pour UML et IP-XACT, et de ce fait certains concepts propres à l interconnexion dans IP-XACT n ont pas été portés dans UML, de même que d autres ont au contraire été introduits, alors qu ils ne figurent pas de le standard du consortium SPIRIT, le but étant de trouver le noyau commun permettant d assurer un usage complémentaire des deux approches Les modèles d interconnections On retrouve dans l état de l art différentes approches visant à exprimer des interconnections entre des instanciations d entités communicantes. Toutes ont pour but d identifier des chemins de communication entre ces entités, mais comme nous allons le voir, le moyen de le représenter, ainsi que la sémantique associée à ces représentations peuvent sensiblement varier d une approche à l autre. Le principal objectif de notre langage est de fournir une représentation intuitive pour les utilisateurs, permettant d introduire des mécanismes de contraintes de compatibilité d interconnections, et ceci le plus indépendamment possible du langage et du niveau d abstraction de l implémentation finale. Nous observerons dans un premier temps comment le formalisme IP-XACT y parvient, puis nous verrons à travers les différentes approches UML existantes, comment reproduire un mécanisme compatible dans ce langage L approche IP-XACT Le mécanisme d interconnexion proposé par IP-XACT reproduit assez fidèlement l approche que l on trouve dans la réalité lorsque l on cherche à connecter des composants à travers un bus de communication. Un bus impose un protocole de communication, tels que les protocoles AXI, AMBA APB ou AHB de la compagnie ARM, ou encore le STBus défini par STMicroelectronics. Si l on désire que différents composants puissent communiquer entre eux à travers un bus donné, il est impératif que chacun d entre eux respecte le protocole imposé par ce bus. Généralement, les composants matériels Sébastien Revol Thèse de doctorat 79/161

80 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique ne sont conçus que pour un type de protocole donné, si bien que ce protocole caractérise fortement le composant. C est donc cette contrainte qui est la base de tous les mécanismes définis par IP-XACT. Ainsi le standard a introduit un moyen d identifier précisément un protocole, avec la notion de définition de bus, appelée BusDefinition qui, tout comme les composants, va être marquée par le quatuor VLNV (Vendor, Library,Name, Version). Contrairement à ce que l on pourrait croire, une définition de bus ne va pas servir à représenter directement le bus en lui-même. En effet, IP-XACT considère au final un bus comme n importe quel composant matériel, possédant des points de connexion, et dont le rôle est d établir des communications entre ces différents points. Ce qu une définition de bus spécifie, c est un mécanisme de typage et de spécification de contraintes sur les points de connexion que vont devoir posséder les composants. Ces points de connections sont appelés BusInterface (pour interface de bus), qu IP-XACT classifie en différentes catégories, les principales étant les BusInterface dites Master (maître) et celles dites Slave (esclave). Cette qualification permet de spécifier l initiative des communications que va avoir l interface de bus dans le protocole : une interface maître va être capable d initier des communications, alors qu une interface esclave ne peut que répondre à une communication initiée par un maître 2. En réalité, une interface de bus est une abstraction d un ensemble de signaux que possède le composant. En effet lorsque l on raisonne au niveau de modélisation le plus fin, les entrées et sorties d un composant sont implémentées par des signaux, pouvant être entrant, sortant ou bidirectionnel. La connexion d un composant à un bus se fait en pratique par la connexion d un ensemble de ces signaux à ceux qui leur correspondent du côté du bus. Par exemple, un bus pourrait définir 32 signaux pour coder une donnée, 32 autres pour coder l adresse, un signal d horloge, plus un ensemble de signaux permettant de définir un protocole de communication ( prendre la main, signaler que les données sont prêtes, etc.). La figure 5.10 illustre ce principe. On peut voir que les composants A et B possèdent tous deux une interface de bus maître. Celle-ci est composée de quatre signaux (qu IP-XACT appelle Port), trois de ceux-ci étant sortants, l autre étant entrant. La mémoire possède elle une interface esclave composée de trois signaux : deux entrants et un sortant. En effet, il arrive fréquemment que l interface bus maître et esclave soient différentes dans un protocole. On remarque alors que dans ce cas, les interfaces de bus doivent être connectées à leur interface conjuguée, appelée MirroredMaster et MirroredSlave. Celles-ci ont la particularité de posséder les même signaux, mais avec des directions opposées. On remarquera que dans le cas de la connexion directe entre le composant A et le composant B, qui définit un protocole simple sur un seul fil, on effectue directement un lien entre un maître et un esclave, qui dans ce cas particulier est aussi le conjugué. 2 IP-XACT définit aussi les interfaces dites System, pour les cas particuliers qui ne peuvent pas être qualifiés de maîtres, ni d esclaves 80/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

81 5.4. Le paquetage BusInterface FIG Mécanisme de connexion défini par IP-XACT Le mécanisme de définition de bus permet donc d identifier un type de protocole particulier et de définir les différents types d interfaces de bus impliqués dans ce protocole, en énumérant notamment les signaux que chaque interface définit. Ainsi on voit qu IP-XACT définit un mécanisme de connexion à deux étages : chaque composant va déclarer les interfaces de bus qu il possède, en précisant leur type (référence vers une BusDefinition) ainsi que leur catégorie, (Master, Slave, MirroredMaster etc.). Cette information est suffisante à un outil compatible avec le standard pour effectuer des interconnexions. Cependant, en interne de chaque composant, un deuxième niveau de connexion est effectué (une fois pour toute) : appelé PortMap, il permet de spécifier pour une interface de bus donnée la correspondance entre les signaux (Ports) que possède le composant et ceux qui sont définis par la définition de bus. Ce mécanisme procure plusieurs avantages. En effet, en plus d être un raccourci efficace pour spécifier les interconnections (il n y a plus qu une connexion à exprimer là où il y en aurait normalement eu plusieurs dizaines), l abstraction fournie par les interfaces de bus permet de dissocier clairement la partie qui est générale à toute implémentation d un composant (les interfaces de bus), de ce qui est spécifique d une implémentation, dans un niveau d abstraction donné (les ports). La solution que nous allons proposer va s inspirer de cette dissociation, mais va fournir un mécanisme légèrement différent pour l exprimer, afin de coller au mieux à une approche UML, tout en prenant garde à rester compatible Les solutions proposées par UML UML fournit dans son méta-modèle différentes façons d exprimer des interconnections entre des éléments communicants. Avant la parution de la version d UML 2.0, l utilisateur possédait principalement deux méthodes pour exprimer graphiquement ces interconnexions : le diagramme de composant et le diagramme de déploiement. Sébastien Revol Thèse de doctorat 81/161

82 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Exemple de représentation structurelle avec le diagramme de déploiement Le diagramme de déploiement introduit en effet des notions élémentaires pour la description architecturale. Il permet de décrire un système sous forme de nœuds (Nodes), correspondant à des systèmes matériels, et des chemins de communications (CommunicationPath). La figure 5.11 montre comment pourrait être représenté l exemple que nous venons d illustrer (cf figure 5.10) avec ce diagramme. Certains travaux, généralement antérieurs à la version 2.0 d UML, ont proposé des profils tels que les standards Schedulability Performance and Time [83] et Software Radio [90], spécialisant ces méta-classes pour décrire des architectures matérielles. Cependant, même si ce diagramme supporte en partie la représentation hiérarchique (un nœud peut contenir d autres nœuds), il ne propose pas de moyen simple de spécifier des points de connections entre les composants (tels que les interfaces de bus d IP-XACT), ni de règles de connections entre les nœuds, et utilise une syntaxe graphique assez éloignée de ce que l on retrouve dans les langages spécifiques à la description architecturale. En réalité, le diagramme de déploiement n est pas conçu pour spécifier en détail des architectures matérielles complexes, mais vise plutôt à fournir une représentation simplifiée des supports d exécution et de communication impliqués dans le déploiement d un système logiciel réparti. Ainsi, ce diagramme s utilise en complémentarité avec un autre diagramme représentant l organisation en briques logicielles d un système informatique : le diagramme de composants. FIG Exemple de diagramme de composants UML La figure 5.12 montre un exemple de diagramme de composants. Afin d assurer la décomposabilité d un système en briques élémentaires interchangeables, UML reprend dans son métamodèle la notion d interface. Une interface est en effet un moyen de spécifier de manière abstraite un ensemble de propriétés structurelles et comportementales (StructuralFeatures et BehaviouralFeatures), telles qu une variable ou une opération qui vont être le moyen d interactions entre deux briques que représentent les composants. Une interface peut alors être implémentée par un composant : 82/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

83 5.4. Le paquetage BusInterface cela signifie qu il va posséder les variables et fournir une implémentation du code des opérations spécifiées par l interface. On dit dans ce cas que l interface est fournie par le composant (Provided Interface). Un autre composant qui aura besoin de ces opérations pourra les utiliser. On dit que l interface est requise (Required interface) pour ce type de composant. L interface joue donc le rôle d une représentation intermédiaire qui permet aux développeurs de coder leurs composants en se référant à celle-ci plutôt qu à l entité qui fournira effectivement le service. Un diagramme de composants comme celui de la figure 5.12 sert donc à illustrer l organisation d un système constitué de composants. L accent est particulièrement mis sur l expression des interdépendances entre les composants, par la représentation sous la forme ball and socket des interfaces : une interface fournie est incarnée par une boule sur laquelle peuvent se connecter les interfaces requises correspondantes, représentées sous la forme d un réceptacle. S il est bien adapté pour la modélisation de systèmes logiciels, le diagramme de composants n a pas été adopté pour la description matérielle. En effet, comme nous l avons dit dans la section 5.2 la sémantique du composant dans les versions antérieures d UML était uniquement de représenter une abstraction, une coquille autour d un ensemble d éléments remplissant un ensemble de fonctionnalités. Bien qu identifiant des règles de compatibilités entre ces composants, les interfaces restent elles aussi des concepts abstraits regroupant un ensemble de fonctionnalités fournies ou requises par le regroupement des éléments constituant un composant, et leur représentation dans le diagramme ne sert qu à exprimer comment ces relations de dépendances émergentes vont être assouvies dans le système. Cette approche s applique bien lorsque la connexion entre les composants est dématérialisée, lorsque c est par exemple l environnement d exécution qui va se charger d établir la connexion entre les interfaces au moment de l exécution. Cependant, dans certains domaines, et tout particulièrement dans celui de la modélisation matérielle, le point par lequel un composant va interagir avec l extérieur, et le chemin suivant lequel ces interactions vont avoir lieu représentent des caractéristiques structurelles que le modélisateur peut vouloir exprimer. Ces lacunes de la version originale du diagramme de composants ont été comblées par l introduction dans la version 2.0 d UML de la notion de port et de connecteur. Dans la nouvelle version d UML, le composant est un type de classe particulier, auquel les capacités d abstraction telles qu elles étaient définies dans la version précédente ont été rajoutées. Ainsi la classe et le composant héritent de la classe abstraite Encapsulated Classifier. Cette classe encapsulée peut posséder un type particulier de propriété structurelle, le port. Ce port est alors défini comme un point d interaction particulier entre la classe et son environnement. Différentes variantes de ports existent, modulables avec les attributs isservice et isbehaviour, qui permettent de préciser la manière dont le port et la classe qui le possède interagissent. De plus la classe encapsulée dérive de la notion abstraite de StructuredClassifier. Cette dernière introduit des concepts comme le Part et le Connector élargissant les possibilités d UML pour décrire l organisation de propriétés structurelles d une classe (Properties) [16]. Tous ces nouveaux concepts s expriment alors dans un nouveau type de diagramme : le diagramme de structure composite. Avec un tel diagramme, il devient possible de montrer comment un composant hiérarchique instancie des sous-composants, et de montrer comment ceux-ci sont physiquement connectés entre eux par des ports et des connecteurs. Ces concepts correspondent parfaitement à la représentation de matériel, et c est d ailleurs leur parution dans la version 2.0 d UML qui a confirmé l intérêt de ce langage dans le domaine de la description matérielle. Ainsi la majorité des profils que nous avons présentés dans 4.2 exploitent cette notation. Suivant leur but, l attention portée aux règles d interconnexion a été plus ou moins développée, les profils visant à la génération d une implémentation dans un langage donné étant généralement plus poussées [136, 101]. Dans ce UML2, le port a été introduit de manière à être compatible avec les notions d interfaces Sébastien Revol Thèse de doctorat 83/161

84 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Exemple de connections possibles avec le profil UML pour SystemC fournies et requises d un composant. En effet, il devient possible d associer ces interfaces au point d interaction particulier qu incarne le port. Ainsi le port peut devenir le moyen d accéder aux services définis par la ou les interfaces qu il expose. De même, la classe qui possède un port avec une ou plusieurs interfaces requises devra passer par ce port pour faire appel aux services requis. C est alors le connecteur qui va permettre de spécifier vers quelle implémentation de l interface requise sera dirigé l appel à un service. Cette implémentation peut être soit directement une instance de classe qui implémente l interface, soit un port qui expose l interface. Ce mécanisme est typiquement celui que l on retrouve dans la sémantique de connexion de SystemC. En effet, SystemC introduit deux types de ports pour définir les points de connections pour les composants : le sc port et le sc export. Un sc port doit être connecté à une implémentation de sc interface extérieure au composant qui le possède. Le sc export, lui, doit être connecté à une implémentation interne au composant qui le possède. La figure 5.13 illustre comment le profil UML pour SystemC [101] représente ces mécanismes en UML. On voit que les sc interface sont des interfaces requises aux sc port, alors qu elles sont fournies par les sc export. SystemC spécifie alors deux types de connections possibles. Les composants CompA et CompB sont reliés par l intermédiaire d un sc signal, un type particulier de canal primitif (primitive channel) implémentant les deux interfaces requises par les ports in et out (resp. sc in if et sc out if). Dans ce cas, le connecteur relie directement les ports au sc signal. Dans l autre cas, typique à la modélisation transactionnelle, l interface tlm transport if requise par le port initiator du composant Master est directement implémentée par le composant Slave et est exposée par son port target. Le connecteur peut ainsi relier directement le sc port au sc export. La différence entre l utilisation du canal primitif ou la connexion directe réside dans la sémantique d exécution sous-jacente, qui devra passer par un mécanisme de notification événementiel dans le premier cas, alors que le deuxième cas permet au composant initiateur d appeler directement des fonctionnalités du composant cible. On notera que le connecteur ne représente plus la même réalité physique dans les deux situations. Si dans le deuxième cas il peut être assimilé à la notion de fil reliant les deux ports, dans la première configuration c est bien le sc signal qui incarne ce fil. Le connecteur ne sert alors qu à exprimer à quel fil sont reliés les ports. De plus, on remarquera aussi que dans cette configuration, le langage n apporte aucune information sur la direction des communications. 84/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

85 5.4. Le paquetage BusInterface Pour la connaître, il faut aller regarder le type des interfaces mises en jeu. Le profil UML for Soc [85] définit une sémantique de connexion très semblable à la configuration avec les sc signal 3. Il propose de rajouter l information sur la direction de l interface en rajoutant une tagged value direction pouvant prendre les valeurs Input ou Output. Cependant les notations graphiques qu il introduit sont discutables par rapport au respect du standard UML. En effet, il donne à l implémentation d interface une notation et une utilisation proche de celle d un port, court-circuitant ainsi la notion d interface fournie par un port. Il autorise l établissement d un connecteur entre un port et une interface, qui n est pourtant pas considérée comme un élément connectable dans le standard. De plus il propose aussi une notation raccourcie permettant de représenter une instance de channel primitif (tel que le sc signal de notre exemple) comme un simple connecteur. Ceci va aussi à l encontre de la sémantique UML, un connecteur ne pouvant être normalement typé que par une association. Le mécanisme d interfaces n est cependant pas le seul moyen de contraindre des connections en UML, et comme nous l avons énoncé dans la section 3.4.3, ce qui rend deux éléments connectables compatibles est un point de variation. Un autre mécanisme très employé dans les profils est de se baser sur le typage des ports : deux ports ne pourront être connectés entre eux que s ils ont le même type. Généralement, ces profils introduisent en plus un moyen d identifier la direction des communications, et de l utiliser pour contraindre un peu plus la connexion (un port en entrée ne pouvant être connecté qu à un port en sortie). Dans le profil Gaspard [13] défini par l INRIA, cette différenciation se fait par l introduction deux stéréotypes différents, un pour le port In, l autre pour le port Out. Dans le standard SysML [93], la contrainte se fait en rajoutant une tagged value direction sur le stéréotype définissant un FlowPort, et renforce ce mécanisme avec la notion de port conjugué par la tagged value isconjugated. Ces concepts sont aussi repris et étendus dans le modèle de composants génériques du standard MARTE [89] Définition du paquetage BusInterface Afin de bénéficier au mieux de la base des mécanismes d interconnexion fournie par UML, notre modèle de domaine a été fortement influencé par le méta-modèle d UML. Dans cette section, nous allons donc introduire de manière continue les concepts que nous avons identifiés et comment nous les avons porté sur UML Dissociation entre spécification et implémentation Comme nous l avons introduit dans la section 4.3.1, le langage ESL vise à exprimer le plus de caractéristiques possible d un composant, caractéristiques qui doivent être communes à toutes les implémentations, que ce soit par rapport au niveau de modélisation ou au langage d implémentation. Nous avons pu voir vu dans la présentation du modèle de connections d IP-XACT de la section que celui-ci propose ce genre de dissociation en différenciant le point de connexion du composant que représente l interface de bus des signaux qui le constituent. Nous allons donc procéder de la même manière, et notre modèle d interconnection va se porter au niveau de l interface de bus. Nous verrons ensuite dans la section 5.6 comment cette spécification pourra par la suite être connectée à un modèle d implémentation. 3 Bien que le profil se veuille indépendant de tout langage d implémentation, la sémantique de connexion est celle de SystemC, et les exemples de génération de code donnés à partir de profil sont d ailleurs en SystemC. Cependant, il n inclut pas la notion de sc export, celle-ci étant apparue dans la version 2.1 du standard [95] publiée après la définition du profil. Sébastien Revol Thèse de doctorat 85/161

86 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Les deux catégories d interfaces de bus La notion de BusInterface Le langage ESL introduit donc la notion d interface de bus comme point de connexion d un composant. Comme le montre la figure 5.14, nous allons distinguer deux catégories d interfaces de bus différentes : les interfaces initiatrices (InitiatorBusIf ), qui seront à l origine d une communication entre deux composants, et les interfaces de bus cibles (TargetBusIf ), qui répondront à ces communications. Comme le laissent deviner leurs attributs respectifs required et provided, nous avons décidé de baser notre modèle d interconnexion sur la notion d interface requise et fournie. En effet, ce mécanisme nous semble très compatible avec les notions d initiateurs et de cibles, un initiateur ayant besoin d un service que fournit la cible pour pouvoir communiquer. De plus, comme nous allons le présenter dans les sections à venir, ce mécanisme va nous permettre de profiter de concepts intéressants introduits par UML, comme la notion de délégation de l implémentation d interface, nous fournissant des bases pour une future spécification du modèle comportemental. Ainsi, comme dans le modèle de connexion d IP-XACT, c est la notion de définition de bus (Bus- Definition) qui va nous permettre de spécifier la compatibilité d interconnexion entre une interface de bus initiatrice et une interface de bus cible. Afin de permettre de l identifier de manière unique, nous avons aussi reporté sur notre notion de BusDefinition les attributs d identification du protocole défini par IP-XACT, à savoir le quatuor Vendor, Library, Name et Version. Nous lui avons de plus donné des attributs optionnels permettant de spécifier le nombre de bits sur lequel seront codées les adresses dans ce protocole (addresswidth) ainsi que les données (datawidth). Ces attributs sont en effet optionnels, car il se peut que dans le cas d un protocole très simple, comme les connections point à point, il n y ait pas de mécanisme d adressage. Cependant, ces informations, lorsqu elles ont lieu d exister sont normalement générales à toute implémentation. Comme on peut le deviner, la notion de définition de bus sera donc portée sur la notion d interface d UML et la notion d interface de bus, définissant un point de connexion du composant, sera portée sur la notion de port. Ainsi la BusDefinition sera une interface requise par le port initiateur et fournie par le port cible. La terminologie employée peut paraître déstabilisante, une interface de bus représentant un port et non pas une interface au sens UML, mais nous avons préféré garder les termes employés 86/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

87 5.4. Le paquetage BusInterface par le standard IP-XACT Les interfaces de bus cibles FIG Les concepts autour de l interface de bus cible Comme nous l avons introduit dans la section , certains protocoles ont besoin de la notion d interface de bus conjuguée, une interface maître ne pouvant être connectée directement à une interface esclave. Dans ce cas, l interface conjuguée à l interface maître (MirroredMasterBusIf ) a un rôle de cible, puisqu elle va recevoir la communication initiée par la MasterBusIf. De la même manière, une interface MirroredSlave pourra être considérée comme une interface initiatrice. La figure 5.15 montre quels sont les concepts relatifs à une interface de bus cible. On peut y voir que nous avons introduit la notion de contrôleur d interface cible (TargetBusIfCtrlr). Cette entité vise à représenter l élément qui va prendre en charge les transactions arrivant sur l interface de bus cible, et il existe une association entre une interface cible et son contrôleur. Cette notion de contrôleur peut sembler superflue : on pourrait imaginer que c est directement l interface cible qui va prendre en charge la transaction, ou bien le composant qui la possède. Cependant, nous l avons introduite car elle va nous permettre de mettre en exergue un phénomène que l on retrouve fréquemment dans les composants matériels. Il arrive en effet qu un composant puisse posséder plusieurs interfaces de bus, et puisse être ainsi connecté soit à plusieurs bus, soit plusieurs fois à un même bus. Suivant l interface par laquelle le bus accède au composant, il se peut qu il ne puisse pas accéder à la même carte de registres de celui-ci. Ce fait est d ailleurs pris en compte par le standard IP-XACT qui permet d associer une carte de registres spécifique à chaque interface de bus esclave. Pour reproduire ce phénomène, nous avons défini la carte de registres comme type de contrôleur d interface cible (cf figure 5.2). Cette abstraction du comportement consiste à dire que c est elle qui va être chargée d effectuer le décodage des adresses pour effectuer les opérations de lecture et d écriture dans les registres qu elle possède. Chaque interface pouvant donner accès à des registres devra donc être connectée à une instance de carte de registres qui sera son contrôleur. Ainsi comme le montre la figure 5.16, nous pouvons avoir plusieurs combinaisons, et représenter par exemple que deux interfaces esclaves (slaveb et slavec) vont donner accès à une même carte de registre mapb, alors que l interface SlaveA va donner accès à une autre carte de registres, mapa. Afin de coller avec la sémantique d UML, le type contrôleur d interface cible (SlaveBusIfCtrlr- Def ) doit réaliser l interface (au sens UML, cf figure 5.17) qui spécifie la définition de bus. Afin 4 Les effets de cette différence de nommage pourront notamment être amoindris par la spécialisation de l éditeur UML employé, en créant par exemple une palette de boutons spécialisée portant le nom de BusInterface, et instanciant directement un port avec stéréotype correspondant. Sébastien Revol Thèse de doctorat 87/161

88 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Exemple de composant comportant plusieurs contrôleurs d interface cible FIG Implémentation des définitions de bus par des définitions de carte de registres d exprimer que l interface de bus cible exporte cette busdefinition, le port UML qui la représente doit être directement typé par elle 5. C est le connecteur qui effectue alors la délégation entre l interface cible et le contrôleur, en acheminant vers celui-ci les requêtes arrivées sur l interface cible. C est en grande partie ce mécanisme de délégation qui nous a encouragé à utiliser les notions d interfaces fournies et requises comme système de contraintes des connections. La carte de registre est un type particulier de contrôleur d interface cible. Afin de pouvoir supporter des protocoles n exploitant pas la notion d adresse et de registre, nous avons introduit les stéréotypes SlaveBusIfCtrlr et SlaveBusIfCtrlrDef dont héritent respectivement RegisterMap et RegisterMapDef, en se basant sur la même dissociation type/instance. Ainsi toute classe stéréotypée comme SlaveBusIfCtrlrDef ou son sous-type doit implémenter une interface stéréotypée BusDefinition. On notera enfin que le typage direct d un port représentant une interface de bus cible par une classe stéréotypée SlaveBusIfCtrlrDef est permis, et permet de considérer que le port est lui-même le contrôleur d interface. De plus, on peut aussi faire réaliser l interface de définition de bus directement par le composant lui-même. Dans ce cas là c est lui qui se charge de gérer les transactions, et toutes les interfaces de bus cibles (ports) typées par cette définition de bus transmettront les requêtes au composant. 5 Bien que certains outils UML le permettent, les interface requises et fournies d un port sont des attributs dérivés, et ne sont pas éditables directement. Une interface devient fournie soit lorsque le port est typé par celle-ci (et il doit alors être connecté à une instance de classe implémentant l interface) soit typé par une classe implémentant l interface. Pour qu une interface soit requise, il faut que le port soit typé par une classe exprimant une dépendance vers cette interface. 88/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

89 5.4. Le paquetage BusInterface Les interfaces de bus initiatrices FIG Définition des contrôleurs d interface de bus initiatrices Les interfaces de bus initiatrices sont construites sur le même modèle, décrit dans la figure Comme nous l avons déjà énoncé, nous en identifions deux types : les interfaces maîtres ainsi que les interfaces esclaves conjuguées. Dans ce cas, le type du contrôleur d interface doit exprimer une dépendance d usage envers l interface UML stéréotypées comme définition de bus. On peut voir dans le figure 5.16 un exemple d interface de bus initiatrice avec le port master. Lors de nos travaux la question a été posée de laisser ou pas la dissociation entre un contrôleur d interface de bus initiatrice et l interface elle-même, du fait que le phénomène d accès multiples à une carte de registres n a pas lieu d être dans le sens initiateur des communications. Nous l avons toutefois laissée, mais nous encourageons une modélisation confondue de ces deux concepts en typant directement les ports initiateurs par une définition de contrôleur de bus (qui, rappelons-le, doit exprimer une dépendance d usage envers la définition de bus, cf figure 5.17). On notera enfin qu une interface de bus esclave conjuguée (MirroredSlaveBusIf ) possède l attribut baseaddress. En effet, on retrouve beaucoup ce type d interface de bus sur des composant implémentant le bus de communication lui-même. Cet attribut sert alors à spécifier à quelle adresse se situera l interface esclave du composant connecté à l autre extrémité. Sébastien Revol Thèse de doctorat 89/161

90 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Stéréotypes introduits par le paquetage Bus Interface Le sous-paquetage Protocol Definition Tel que nous l avons défini, le mécanisme d interfaces requises et fournies nous permet de contraindre des connections entre une interface de bus initiatrice et une interface de bus cible. Cependant rien ne permet de spécifier quel type d interface initiatrice (master ou mirrored slave) doit être connecté avec quel type d interface cible (slave et mirrored). Le fait de devoir utiliser ou non la notion d interface de bus conjuguée, est propre à chaque protocole. Nous nous sommes inspirés de ce que propose le profil UML for SoC [85] pour introduire dans ce paquetage les moyens de le préciser, en s appuyant sur la notion de collaboration, introduite avec le diagramme de structure composite d UML. En effet une collaboration UML sert à représenter une configuration d instances de classifiers remplissant une fonctionnalité à un instant donné, en ne se concentrant que sur les informations importantes pour cette fonctionnalité, et en permettant d omettre toute information qu il n est pas nécessaire de représenter dans le cadre de cette collaboration. FIG Exemple de définition de protocole à l aide d une collaboration 90/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

91 5.5. Le paquetage Hierarchy La figure 5.20 montre un exemple d une collaboration telle que nous proposons de l utiliser. Les éléments représentables dans une collaboration sont ceux qui héritent de la méta-classe abstraite ConnectableElement. Nous pouvons donc y représenter nos ports stéréotypés. Cependant, puisque nous ne parlons pas d instances de ports appartenant à un composant en particulier, nous proposons dans cette situation abstraite de typer tous les ports directement avec l interface du protocole. Les connections permettent alors de spécifier à quelle interface de bus devra être connectée à telle autre interface de bus. De plus, notez que la multiplicité des rôles de cette collaboration a un sens : elle permet en effet de spécifier si une interface de bus source ou cible supporte les connections multiples. Dans notre exemple (qui ne décrit pas le fonctionnement réel du STBus), on peut ainsi voir que notre protocole doit utiliser des interfaces de bus conjuguées, et qu une interface de bus MirroredSlave peut être connectée à un nombre arbitraire d interfaces Slave. On associe ensuite cette collaboration à l interface de définition de bus par l intermédiaire d un usage de collaboration (CollaborationUse), que peut posséder tout classifier UML (le classifier est un type abstrait dont l interface est un sous-type). 5.5 Le paquetage Hierarchy Présentation générale Le paquetage Hierarchy définit les concepts nécessaires à la description de systèmes hiérarchiques, c est à dire de pouvoir considérer un composant comme un assemblage d instances de sous-composants. Notre approche s inspire beaucoup des approches classiques exploitant le diagramme de structure composite. Celui-ci permet en effet de décrire la structure interne d une classe ou d un composant UML en représentant les instances des sous-composants comme des boîtes interconnectées par leur ports via des connecteurs. Cependant, ce que nous proposons diffère légèrement afin d assurer la compatibilité avec IP-XACT, et de permettre d associer à un seul composant plusieurs vues hiérarchiques différentes. De plus, nous verrons que toutes les approches UML n exploitent pas de la même manière le diagramme de structure composite, notamment lorsque la multiplicité des instances interconnectées ou de leurs ports est supérieure à 1. Nous verrons donc comment nous abordons ce point L approche IP-XACT de la hiérarchie La hiérarchie dans IP-XACT est un peu particulière dans le sens où elle fait une distinction claire entre un assemblage d instances de composants (spirit :design) de la définition d un composant (spirit :component) qui se fait dans deux fichiers distincts. En effet, IP-XACT considère une définition hiérarchique comme une des implémentation possibles de la spécification du composant. La figure 5.21 illustre le modèle de hiérarchie proposé par IP-XACT. La description d un composant possède une section particulière appelée Model. Celle-ci permet de spécifier les informations relatives aux différentes implémentations que le composant peut avoir. On voit que c est à cet endroit qu on spécifie les ports qui implémentent les interfaces de bus (cf section ), mais aussi, par la notion de vue (View), les différentes implémentations possibles du composant. Il existe alors deux types de vues différentes : soit il s agit d une référence vers un ensemble de fichiers (FileSet) qui implémentent le fichier dans un langage donné (SystemC, vhdl, etc.), soit c est une référence vers un fichier de design, identifié par son VLNV. Un design permet alors de spécifier des instances de composants, ainsi que des interconnections entre les interfaces de bus de ceux-ci (non représentées dans notre figure). Il permet de plus de spécifier des connections hiérarchiques entre les interfaces de Sébastien Revol Thèse de doctorat 91/161

92 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Modèle de la hiérarchie définie par IP-XACT bus de la spécification de composant qui instancie le design et les composants instanciés dans le design. Nous remarquerons qu il s agit d un certain défaut d IP-XACT : si le design peut être considéré comme une entité autonome lorsqu il s agit de la vue hiérarchique la plus haute (non incluse dans un composant), il doit forcément posséder une référence vers le composant qui l instancie lorsqu il est inclus à un niveau inférieur de hiérarchie. De ce fait, un design ne peut en théorie pas être réutilisé tel quel dans la vue hiérarchique de différents composants. L intérêt de cette façon de procéder est de permettre l association de plusieurs implémentations hiérarchiques à une spécification, avec plusieurs niveaux de détails possibles (boîte noire, boîte blanche), ce qui arrive fréquemment dans le design électronique Les approches UML Comme nous l avons présenté, le diagramme de structure composite est le moyen le plus couramment utilisé pour représenter la hiérarchie. En effet il propose une alternative au diagramme de classe pour représenter de manière plus précise comment s organisent les rôles que possède une classe, c est à dire les éléments typés qu elle contient (les instances de la méta-classe Property). Ainsi tout comme le diagramme de classe, le diagramme de structure composite se place au niveau de la définition d une classe, et non pas de son instanciation. Celle-ci doit toujours se faire au niveau du diagramme d objets afin de spécifier explicitement l instanciation de chacun des sous-objets (appelés Slots en UML) que contient une classe. Considérons la figure Le diagramme du haut est un diagramme de structure composite au niveau classe. On voit que de la même façon que dans un classique diagramme de classe, on peut attribuer une multiplicité supérieure à 1 aux Properties d un classe. Ainsi, la multiplicité du composant compb est de 2, ainsi que celle du port porta du composant compa. On peut alors voir que les connecteurs établis à ce niveau de représentation ne permettent pas de spécifier complètement quelles vont être les interconnections réelles au moment de l instanciation. Les deux diagrammes sous-jacents démontrent ainsi deux interprétations possibles (il y en a d autres) d instanciation de cette même définition. On voit donc que le standard UML impose pour la spécification complète d un système 92/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

93 5.5. Le paquetage Hierarchy FIG Exemples d instanciations possibles d un diagramme de structure composite hiérarchique au moins deux diagrammes, un pour sa définition, l autre pour son instanciation. C est notamment le cas dans les exemples que propose le profile UML pour SystemC [101]. Une première solution pour contrer ce problème est d imposer une multiplicité de 1 à tous les rôles. Dans ce cas, les diagrammes de classe et d instances sont à peu près équivalents, si l on considère par exemple que le nom de l instance prend le nom du rôle qu elle joue dans la classe (dans le cas où la multiplicité est plus grande, le nom du rôle est celui de l ensemble qui contient les instances, chacune pouvant avoir un nom différent). Cependant, cette méthode impose toujours de spécifier chacun des éléments, ce qui au niveau des ports peut se révéler laborieux, quand on sait qu un composant peut parfois en compter plusieurs centaines. Le profil UML for SoC propose une autre alternative, en associant au composant des contraintes OCL afin de spécifier explicitement ces connexions en donnant les index des tableaux de ports auxquels sont reliés les connecteurs. Cependant, le standard n est pas très explicite sur la manière de procéder et impose à l utilisateur (venant généralement du monde du matériel) d apprendre un langage complexe et peu intuitif au premier abord. L INRIA, avec le profil Gaspard [13, 36] dont les principes ont été inclus dans le standard MARTE [89, 21] propose une alternative beaucoup plus élaborée, en définissant un ensemble de stéréotypes s appliquant principalement aux connecteurs (mais aussi, aux ConnectorEnd, extrémités du connecteur, et MultiplicityElement, notion qui permet de spécifier la multiplicité d un rôle). Ces notations reprennent les concepts introduits par le langage ArrayOL [20] permettant de spécifier des comportements dans des exécutions massivement parallèles. Si les possibilités que donnent cette représentation sont très grandes, et notamment pour les architectures répétitives et massivement parallèles, nous n avons pas introduit ces notions dans notre profil. En effet compte tenu du type d architecture visé à l heure actuelle, nous avons préféré définir une solution alternative un peu plus naïve, certes moins puissante mais plus facile à aborder pour un utilisateur. Cependant, compte tenu de l évolution actuelle des architectures matérielles qui exploitent de plus en plus le parallélisme, nous gardons en mémoire la solution apportée par le profil Gaspard qui nous semble un moyen efficace de contrer ce problème. Nous allons donc dans la prochaine partie présenter la solution que nous avons définie, ainsi que la manière dont nous avons abordé la possibilité d associer plusieurs implémentations hiérarchiques à une même définition de composants, restant compatible avec l approche IP-XACT, qui à notre Sébastien Revol Thèse de doctorat 93/161

94 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Modèle de la hiérarchie dans le langage ESL connaissance n a fait à ce jour l objet d aucun autre travail de recherche particulier Définition du paquetage Hiérarchie La figure 5.23 montre comment nous avons abordé la hiérarchie dans le langage ESL. On peut voir que tout comme IP-XACT nous avons dissocié les notions de design et de composant. Cependant dans notre cas, la dissociation n est que partielle. En effet nous avons défini un design comme un type particulier de composant. A ce titre, nous rappelons sur le diagramme qu il bénéficie lui aussi d un VLNV, qui servira à assurer son identification. En procédant de la sorte, nous n autorisons que les composants de type design à instancier des sous composants. La figure 5.23 décrit ainsi comment sont instanciés et connectés les composants. Comme nous l avions précédemment dit, la connexion doit se faire entre les interfaces de bus en respectant la compatibilité imposée par la définition de bus(ce que nous avons exprimé par le rôle compliance de la classe Connector). Nous avons aussi repris la notion de connecteur hiérarchique (non visible sur la figure) permettant de connecter une interface de bus appartenant au design à celle d une instance de composant. Dans ce cas, la contrainte pour établir la connexion est que les BusInterfaces doivent être de même nature (Master, Slave etc.) et de même type. Nous pouvons aussi voir que, comme dans le méta-modèle UML, un connecteur possède deux ConnectorEnd, chacun étant relié à une interface de bus (l attribut boundinstance est un attribut dérivé, sa valeur désignant l instance du composant contenant l interface de bus connectée). Nous lui avons cependant rajouté deux attributs, busifindex et componentindex permettant de spécifier respectivement l index de l interface de bus et celui de l instance de composant quand leur multiplicité est supérieure à 1. C est en effet la solution que nous proposons pour répondre au problème des instances multiples dans le diagramme de structure composite. Cela se traduit par la définition d un stéréotype ESLConnectorEnd, étendant la méta classe ConnectorEnd et comportant les deux attributs que nous avons spécifiés. En faisant de la sorte nous réduisons l impact de la surcharge de notations qu implique la spécification complète des connections d instances multiples en n imposant que la duplication des connecteurs là où la notation originale imposait la duplication de tous les éléments multiples. La figure 5.24 nous donne un petit exemple d une représentation utilisant ce stéréotype. 94/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

95 5.5. Le paquetage Hierarchy FIG Exemple de représentation hiérarchique avec le profil ESL On voit que la multiplicité du composant compc est de 2, ainsi que celles des ports masterb et Master. En dupliquant les connecteurs entre masterb et slavec, nous pouvons spécifier via les tagged values sur le stéréotype de chaque extrémité de connecteur, que par exemple, le port masterb[2] est connecté au port compc[2].portc (l index commençant à 1). On peut aussi voir sur la figure comment nous avons traduit la notion de référence hiérarchique entre un composant et un design en nous basant sur la notion d héritage. Ainsi un Design hérite du composant pour lequel il spécifie une représentation hiérarchique. Ainsi conformément à l approche d IP-XACT, il est possible de spécifier un nouvel identificateur VLNV à cette représentation, et le nombre de Design représentant un composant n est pas limité. De plus, par la relation d héritage, le Design obtient toutes les caractéristiques de son composant, et plus particulièrement les interfaces de bus qui ne sont pas à redéfinir et peuvent être directement exploitées pour représenter une connexion hiérarchique. On notera que la carte de registre est elle aussi héritée. L interface de bus Slave se retrouve ainsi connectée à la fois à cette carte de registre et à l interface de bus slaveb. Ce cas de figure est un point de variation sémantique d UML, qui laisse ouvert la spécification de l entité vers laquelle sont acheminées les communications arrivant sur le port. Nous le précisons donc en spécifiant qu elles seront de préférence redirigées vers l interface de bus cible connectée. Nous imposons cependant une contrainte supplémentaire en spécifiant qu une interface de bus cible ne peut être hiérarchiquement connectée qu à une seule autre interface du même type. Dans notre exemple, c est donc le composant compa qui implémente en réalité la carte de registre. Le fait que le design la possède aussi n est pas choquant, car cela correspond à une de ses caractéristiques vue de l extérieur. Pour conclure sur le paquetage Hierarchy, la figure 5.25 propose un résumé des stéréotypes introduits pour la représentation de la hiérarchie. Sébastien Revol Thèse de doctorat 95/161

96 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique FIG Résumé des stéréotypes introduits dans le paquetage Hierarchy 5.6 Le paquetage Implementation Présentation générale Le paquetage implémentation vise à spécifier comment relier les informations relatives à une implémentation du composant dans un langage particulier à son modèle de spécification. En effet IP- XACT fournit une abstraction des fichiers d implémentation afin de permettre leur manipulation par des outils. Dans la figure 5.21, les informations spécifiques à une implémentation sont représentées par la classe FileSet. Le détail de leur contenu n est pas représenté, il s agit en fait d informations sur le langage et le nom des fichiers d implémentation, mais aussi des détails plus poussés, tels que les paramètres du constructeur dans le cas d un fichier SystemC/C++, le nom des variables représentant les ports, si celle-ci sont des pointeurs etc. En bref : toutes les informations requises pour qu un outil tel qu un générateur de NetList puisse générer l implémentation d un fichier Design dans un langage donné. Comme nous l avons présenté, notre stratégie propose de reposer sur des profils spécifiques à un langage d implémentation. En effet un profil comme UML for SystemC est une retranscription 1 pour 1 des concepts SystemC/C++ au niveau UML. Un modèle UML réalisé avec ce profil fournit déjà une abstraction très détaillée d une implémentation, puisqu il contient tous les détails nécessaires à la génération de code exécutable, ainsi qu à celle de NetLists. Le but du paquetage Implementation est donc de fournir le moyen de recoller un modèle dans un langage spécifique au modèle de spécification directement écrit dans le profil ESL. Ceci permet d en dériver automatiquement un fichier IP-XACT complet contenant les informations sur la spécification et l implémentation obtenue par génération de code depuis le profil spécifique au langage. Ainsi cela permet de manipuler ce code généré dans des outils IP-XACT et de l insérer dans un flot de conception matériel basé sur ce standard Principe de l association Nous ne présenterons pas ici le détail du contenu du paquetage, mais présenterons le principe du mécanisme que nous proposons, avec quelques exemples de stéréotypes, montrés dans la figure /161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

97 5.6. Le paquetage Implementation FIG Exemple de stéréotypes connectant une implémentation à sa spécification Le principe de base de notre mécanisme d association est d aller apposer sur les éléments du modèle d implémentation des stéréotypes contenant éventuellement des références vers l élément du modèle de spécification qu il implémente, ainsi que les informations complémentaires nécessaires à l obtention du fichier IP-XACT complet. La figure 5.26 nous donne deux exemples de ces stéréotypes. Afin de ne pas imposer de décision sur la façon d implémenter tel ou tel concept de la spécification, nous pouvons voir que nos stéréotypes étendent simplement la méta-classe abstraite NamedElement, permettant ainsi de les apposer sur n importe quel élément du modèle d implémentation possédant un nom (lorsque celui-ci est un attribut requis pour effectuer l association, sinon on pourra étendre directement la méta-classe Element). Le stéréotype ComponentImpl est ainsi à apposer sur l élément du modèle implémentant le composant spécifié. Il possède donc un attribut specification qui pointera vers celui-ci. Le stéréotype PortImpl quant à lui sert à identifier les ports qui implémentent l interface de bus du modèle ESL. Il possède donc lui aussi un attribut specification permettant d identifier l interface de bus implémentée. On notera qu afin d être compatible avec la nouvelle approche que propose la version 1.4 d IP-XACT, nous introduisons la notion de BusDefinitionAbstraction. En effet dans l approche IP-XACT classique, la définition de bus spécifie les signaux (appelés Ports) des interfaces de bus au niveau RTL. Afin de permettre de représenter et d assembler des composant décrit à un niveau d abstraction plus élevé, tel que la modélisation transactionnelle, il introduit la notion d abstraction de définition de bus. Celle-ci pointe vers la définition de bus qu elle étend, et redéfinit les ports que doivent posséder les implémentations des interfaces de bus à ce niveau d abstraction. L opération de mapping des ports (PortMap, cf section ) entre l implémentation et la spécification ne se fait alors plus vers les ports définis par la définition de bus originale, mais vers ceux redéfinis par son abstraction. Nous traduisons ce principe en spécialisant le stéréotype BusDefinition par le stéréotype Bus- DefinitionAbstraction étendant donc lui aussi la méta-classe Interface, et lui rajoutant une référence vers la définition de bus qu elle abstrait. Ainsi, le mécanisme de mapping des ports entre l implémentation et la spécification peut se faire soit directement vers les ports que définit une BusDefinition pour chaque type d interface de bus, soit vers ceux définis par l abstraction qui est effectivement implémentée. En pratique ce mapping s effectue par l attribut portmap du stéréotype PortImpl, qui doit donner le nom du port qu il implémente. En effet, afin de proposer une séparation plus nette entre la spécification et l implémentation et de fournir une indépendance du modèle de spécification par rapport au niveau d abstraction dans lequel sera effectué le composant, nous n avons pas donné la possibilité à notre langage de définir les ports des implémentations de chaque interface de bus. Le mapping doit donc se faire en recopiant le nom directement depuis la spécification complète d une Sébastien Revol Thèse de doctorat 97/161

98 Chapitre 5. Le profil UML pour la modélisation au niveau Système Electronique BusDefinition d un fichier IP-XACT, cette information n étant pas contenue dans son équivalent UML. Ceci explique le type String de l attribut portmap du stéréotype PortImpl. 5.7 Conclusion Ceci conclut la présentation du langage ESL que nous avons spécifié. Il reproduit une grande partie des mécanismes fournis par le standard IP-XACT, en cherchant à tirer profit des possibilités offertes par UML. Ainsi la dissociation plus nette entre les modèles de spécification et d implémentation, qui permet d exploiter des initiatives de profils spécifiques à un langage comme UML for SystemC résout le problème d IP-XACT qui impose de fournir plusieurs spécifications différentes suivant le niveau d abstraction visé pour l implémentation. De plus les possibilités offertes par le méta-modèle d UML, avec par exemple la dissociation entre le type et l instance ainsi que la notion de multiplicité fournit des raccourcis syntaxiques très efficaces par rapport aux modèles IP-XACT où tous les éléments tels que les interfaces de bus, les registres ou les instances de composants doivent être complètement spécifiés individuellement, avec de nombreuses duplications d informations. Le fait de porter les concepts d IP-XACT au niveau UML nous permet de bénéficier de l énorme travail fourni par le consortium SPIRIT pour la modélisation des composants électroniques. Il positionne ainsi notre profil comme un des plus complets de l état de l art des initiatives équivalentes en UML, en proposant par exemple plusieurs vues hiérarchiques possibles pour une même spécification, et surtout en introduisant une grande quantité d informations exploitables pour en dériver automatiquement un modèle d implémentation (registres, interfaces de bus), sans prendre pour autant parti sur le niveau d abstraction ni le langage dans lequel cette implémentation aura lieu. Nous allons donc illustrer dans le prochain chapitre comment exploiter ces informations pour l automatisation du flot de conception des Systèmes sur Puce en nous appuyant sur les techniques de l IDM. Puis, dans la dernière partie de cette thèse, nous évaluerons l intérêt que l association de notre langage et des outils que nous avons développés procure dans le contexte industriel de STMicroelectronics. Nous discuterons par la suite des limitations de notre étude puis concluerons ce mémoire en analysant les ouvertures que nous laissent entrevoir ces travaux. 98/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

99 Chapitre 6 Exploitation du langage ESL Sommaire 6.1 Aperçu de l implémentation Les transformations L environnement d implémentation Générateur de code SystemC/C Présentation générale Architecture du générateur Syntaxe abstraite et génération de code Les profils C++ et SystemC associés Transformation ATL d UML vers la syntaxe abstraite C++/SystemC Intégration dans Eclipse Transformation d IP-XACT vers le profil ESL Motivations Principes de la transformation Implémentation de la transformation Transformation du profil ESL vers les profils SystemC-C Présentation générale La création des modules Création des registres Implémentation des fonctions Read/Write Conclusion Nous présentons dans ce chapitre les différents outils que nous avons réalisés autour du profil ESL. Essentiellement basés sur la transformation de modèles et la génération de code, ces outils tentent d intégrer le langage ESL dans l environnement méthodologique et technologique de STMicroelectronics. Après avoir donné un aperçu général des transformations que nous avons implémentées et discuté du choix des outils pour les réaliser nous rentrerons un peu plus en détail dans chacune d entre elles. 99

100 Chapitre 6. Exploitation du langage ESL 6.1 Aperçu de l implémentation Les transformations Comme nous l avons présenté dans la section 4.3.2, le niveau d abstraction auquel se trouve le langage ESL nous a semblé le meilleur pour introduire de manière directement exploitable la modélisation UML et les possibilités de l IDM dans le contexte technologique de l équipe System Platform Group (SPG) de STMicroelectronics. FIG. 6.1 Transformations de modèles autour du profil ESL La figure 6.1 montre comment nous avons cherché à intégrer le profil dans les méthodes de développement de l équipe. La transformation de modèles Transfo1 établit une passerelle permettant d importer des modèles IP-XACT existants dans une représentation UML-ESL équivalente. La deuxième transformation, Transfo2 vise quant à elle à transformer un modèle de spécification réalisé avec le profil ESL en un modèle d implémentation, toujours au niveau UML, grâce au profil UML for SystemC et un profil C++ maison permettant de paramétrer la génération de code. En effet, nous avons aussi dans le cadre de la thèse développé un générateur de code C++ (GenCode) capable d interpréter un modèle UML appliquant ces deux derniers profils, afin de générer le code exécutable SystemC-TLM des composants issus de la transformation précédente (Transfo2). Enfin nous avons aussi spécifié la transformation permettant d interpréter les informations du paquetage Implémentation du profil ESL connectant le modèle de spécification à un modèle d implémentation afin de générer la description IP-XACT correspondante au code d implémentation généré. Malheureusement, cette dernière transformation n a pas pu être implémentée au cours de la thèse. Dans les parties qui suivent, après nous être attardés sur la justification du choix de l environnement et des outils avec lequels nous avons implémenté nos transformations, nous reviendrons un peu plus en détail sur chacune d entre elles L environnement d implémentation L environnement sur lequel nous nous sommes basés pour l implémentation de nos transformations est la plateforme Eclipse, et plus particulièrement l Eclipse Modeling Framework (EMF) [24]. Les raisons qui ont justifié notre choix sont nombreuses. Tout d abord, l EMF est en passe de devenir 100/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

101 6.1. Aperçu de l implémentation à ce jour l environnement de référence pour l Ingénierie Dirigée par les Modèles. En effet, comme nous l avons dit dans la section 3.2.4, il propose une implémentation des couches Méta fournissant une base solide sur laquelle la plupart des outils issus de la recherche dans le domaine de l IDM sont implémentés. Ainsi nous avons pu choisir parmi eux ceux qui correspondaient le plus à nos besoins et contraintes. Pour la génération de code, notre choix s est porté sur l outil XPand de la chaîne OpenArchitectureWare. Bien que sensiblement équivalent à d autres outils tel qu Acceleo [82], XPand nous a paru plus facile d accès et plus engagé dans les initiatives de modélisation des projets Eclipse (le projet Generative Modeling Technologies, GMT), étant notamment directement utilisé dans des projets phares comme le Graphical Modeling Framework. En ce qui concerne la transformation de modèles, là aussi notre choix s est porté sur l un des projets les plus adoptés par la communauté Eclipse : le moteur de transformation ATL [59]. En effet, ce moteur fournit une implémentation proche du standard Query View Transform (QVT) [87] de l OMG, supportant à la fois l énonciation déclarative et impérative des règles de transformation (cf. section 3.2.4). Il fournit de plus un environnement de développement évolué, permettant par exemple le débogage interactif des transformations et le report direct dans le code des erreurs de compilation. De plus, il est à noter que ces deux outils que nous avons choisis, ainsi que la plateforme Eclipse en elle-même, sont des outils open source ayant acquis une certaine pérennité. Ceci nous assure une meilleure capitalisation du travail réalisé, qui reste indépendant de tout outil commercial fournissant des services IDM. Cependant, tout en étant indépendant des outils commerciaux, notre travail reste dans une certaine mesure compatible avec eux. En effet, Eclipse étant la référence dans l IDM, l implémentation du standard d échange des modèles XMI (cf ) que fournit l EMF devient lui aussi le format de référence 1 vers lequel de plus en plus d outils UML commerciaux fournissent un import-export. De ce fait, il reste possible d éditer les modèles UML dans un autre environnement qu un outil intégré à Eclipse, et d exporter ces modèles pour les exploiter avec nos outils. Cependant, dans notre cas, nous avons développé l intégralité de nos modèles UML (ceux qui ont été nécessaires au développement des transformations et générateurs ainsi que ceux qui nous ont servi d exemple ont été développé avec l outil UML Papyrus [28] développé dans le laboratoire LISE du CEA où ma thèse s est déroulée, outil reposant lui-même sur la plateforme Eclipse. On remarquera que nos outils pour la manipulation de modèles ont été eux aussi réalisés grâce à des technologies IDM, et une partie de leur code a été généré grâce à des modèles. L aspect open source et gratuit de ces outils, exécutables sur la plupart des systèmes d exploitation par leur implémentation en Java nous fournit de plus un moyen supplémentaire de favoriser l adoption de nos travaux au sein de STMicroelectronics. En effet, le rôle de l équipe SPG est de développer des nouveaux outils pour le développement des Systèmes sur Puce, et de les promouvoir au sein de l entreprise, aux risques parfois de bouleverser les habitudes de développement de certains utilisateurs. De ce fait, l adoption par ceux-ci n est jamais acquise, et le fait que les outils ne nécessitent aucun investissement supplémentaire est bien sûr un facteur évident pour la favoriser. Cette optique d adoption est d autant plus favorisée par la fait que nos outils s intègrent parfaitement dans l environnement de développement intégré (IDE) de plateformes SystemC-TLM basé lui aussi sur Eclipse spécialisé que développe l équipe SPG. Celui-ci, notamment par la spécialisation des outils de développement C++ (C Development ToolKit ou CDT), propose un ensemble de facilités pour développer, compiler, paramétrer mais aussi déboguer des plateformes. Il inclut notamment une intégration avec les outils de développement de logiciel embarqué pour des processeurs spécifiques, et permet par exemple le débogage simultané du logiciel embarqué et du code SystemC simulant les 1 Malgré les efforts de standardisation en cours, l interopérabilité des modèles entre outils UML n est en pratique pas encore une chose acquise! Sébastien Revol Thèse de doctorat 101/161

102 Chapitre 6. Exploitation du langage ESL composants. Ceci propose l avantage énorme de pouvoir visualiser à un instant donné de la simulation à la fois l état du logiciel s exécutant sur le processeur simulé, mais aussi celui de toute la plateforme, avec la possibilité de visualiser la valeur dynamique des registres de tous les composants simulés, à partir notamment d une interprétation des fichiers IP-XACT correspondants 2. L intégration d IP- XACT est aussi faite par l inclusion dans cet environnement de l éditeur Magillem [7], un outil dédié à ce formalisme permettant d assembler graphiquement entre eux des composants, et d interagir avec des générateurs dédiés comme on en trouve pour des composants configurables à l instanciation. En basant nos outils sur Eclipse, leur ajout dans cet environnement se fait de manière très transparente. Il devient en effet possible d obtenir en quelques clics la description UML d un composant IP-XACT que l on visualisait avec Magillem, ou encore la visualisation directe ainsi que la compilation assistée du code généré pour un nouveau composant à partir d une description UML. 6.2 Générateur de code SystemC/C Présentation générale La création du générateur de code C++ a été le premier de nos travaux d implémentation. Cette création s est justifiée par les volontés d indépendance et d intégration que nous venons de présenter. Nous nous sommes initialement posé la question d exploiter les travaux de Sara Bocchio et Alberto Rosti, travaillant dans une autre division de STMicroelectronics et auteurs du profil UML for SystemC. Ils proposent avec celui-ci un environnement de développement basé l outil UML Entreprise Architect [112, 102], spécialisant son interface pour faciliter l édition de modèles appliquant leur profil, et intégrant un générateur de code SystemC-C++. Cependant, outre le fait que nous devenions dépendant de cet outil, des modifications sur la génération de code auraient été à apporter afin de respecter les nombreuses règles de codage recommandées par l équipe SPG. En effet, afin de garantir une certaine homogénéité dans l aspect et la qualité des modèles TLM, l équipe recommande fortement de respecter certaines règles, telle que l évitement de l utilisation de pointeurs pour les variables membres d une classe (incluant donc les ports d un module), l initialisation de celles-ci par un chainage direct à l appel du constructeur de la classe ou encore le respect des espaces de nommage en rappelant à chaque fois le nom complet d une variable plutôt que d utiliser des clauses d imports (using namespace). Ainsi nous avons jugé que plutôt que de passer du temps à apporter ces modifications sur un outil propriétaire, il nous serait à terme plus bénéfique de profiter des capacités offertes par les outils de l Eclipse Modeling Framework pour implémenter un générateur sur mesure que nous maîtrisons totalement. Encore une fois, la génération d un code propre ressemblant à celui qu aurait écrit un expert du SystemC-TLM comme ceux qui constituent l équipe SPG était un moyen supplémentaire de favoriser l adoption de nos travaux au sein de l entreprise. De plus, comme nous allons le voir dans la section suivante, nous avons architecturé ce générateur afin qu il soit facilement réutilisable pour d autres générations de code, que ce soit à partir d UML mais aussi de tout autre méta-modèle compatible avec le format de l EMF. 2 Ceci souligne un des avantages de la simulation transactionnelle, qui propose une vitesse de simulation proche de la vitesse réelle, mais avec une visibilité totale sur la plateforme que n offre pas un véritable circuit. En effet celui-ci est une boîte noire difficilement pénétrable (ou alors avec une instrumentation très lourde) alors que la simulation permet de visualiser, mais aussi de modifier à tout instant l état du système. 102/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

103 6.2. Générateur de code SystemC/C++ FIG. 6.2 Architecture du générateur de code SystemC-C Architecture du générateur La figure 6.2 illustre l architecture de notre générateur de code. Comme on peut le constater, le processus de génération depuis un modèle UML (Modèle Utilisateur) se passe en réalité en deux étapes, illustrées par les flèches Transfo et GenCode. En effet une des caractéristiques de notre générateur est de reposer sur un méta-modèle intermédiaire, proposant une syntaxe abstraite (quelque peu simplifiée) du C/C++. Les générateurs de code comme on en retrouve dans les outils commerciaux ([112, 119, 12]) ne proposent généralement pas cette architecture. Comme nous l avons introduit dans la section sur les outils de l IDM (3.2.4), le processus de génération de code consiste en la récupération des informations contenues dans un modèle et en leur injection dans des fichiers textes après une éventuelle analyse. Dans les outils UML que nous avons cités, les modèles que l on parcourt sont directement des instances du méta-modèle UML. Les phases d analyse du modèle (comme le calcul des fichiers à inclure par la clause #include) et de génération sont alors confondues, et l on doit manipuler dans les fichiers squelettes (template) des concepts propres au méta-modèle UML pour les incorporer dans le code C++. Notre implémentation, avec l utilisation d une syntaxe abstraite dissocie plus clairement ces deux étapes. Ainsi la phase d analyse du modèle d entrée se trouve dans la transformation ATL qui va avoir pour but de construire une instance du méta-modèle de la syntaxe abstraite. Dans une deuxième étape, cette instance est alors sérialisée par l outil XPand. Il ne s agit cependant pas d une sérialisation pure comme nous en avons parlé dans la section , se basant sur une description EBNF [108] pour générer le code associé à un méta-modèle. En effet la complexité de la syntaxe du C++ nous a poussé à en réaliser une simplification, impliquant alors certains motifs de génération de code. En d autres termes, bien que nous soyons proches de la syntaxe élémentaire du C++, l outil génère toujours quelques phrases préconstruites de code. Il n y a donc pas de transcription un-pour-un entre la grammaire C++ et la syntaxe abstraite du méta-modèle intermédiaire. Cependant, la richesse de notre méta-modèle intermédiaire nous fournit tout de même une très Sébastien Revol Thèse de doctorat 103/161

104 Chapitre 6. Exploitation du langage ESL grande souplesse dans la génération de code. Il contient d ailleurs au final plus d informations sérialisables que ce nous en exprimerons à travers le langage UML associé aux profils utilisés. Cela met en valeur un deuxième avantage de notre choix d architecture. En effet, grâce à cette riche syntaxe abstraite automatiquement sérialisable, la réalisation d un nouveau générateur de code C/C++ à partir d un autre méta-modèle (par exemple un autre profil UML ou un DSL tel qu IP-XACT) ne va plus passer que par la réalisation d une nouvelle transformation de modèles, la partie sérialisation étant déjà fournie. Des applications sont déjà entrevues pour l exploitation de ce back-end dans l équipe SPG, comme la génération de code C pour le logiciel enfouis (Firmware) à partir de description sous forme d automates (nous avons inclus la possibilité de sérialiser du C), mais aussi la réalisation de générateurs IP-XACT ad-hoc, comme on en retrouve pour les composants configurables Syntaxe abstraite et génération de code Afin de pouvoir être utilisée en sortie de la première transformation de modèles et en entrée de la phase de sérialisation, notre pseudo syntaxe abstraite du C++ a été implémentée comme un métamodèle de l Eclipse Modeling Framework. Son édition a été intégralement réalisée en UML, avec l outil Papyrus [28]. En effet, comme nous l avons présenté dans le paragraphe 3.3.2, la syntaxe concrète du MOF est un sous-ensemble de la syntaxe d UML. Cependant, comme Papyrus est un éditeur UML, les méta-classes qu il instancie et sérialise dans un modèle sont celles du méta-modèle d UML et non pas du méta-modèle du MOF. Nous avons donc utilisé une transformation de modèles fournie dans l Eclipse Modeling Framework, capable de convertir des modèles UML en modèles Ecore, ce format étant l implémentation du MOF que fournit l EMF 3. Une fois le méta-modèle obtenu, nous avons utilisé un autre outil fourni par l EMF permettant de générer le code Java implémentant notre méta-modèle. C est ce code qui permettra de créer à l exécution des instances dynamiques contenant les informations sur la syntaxe abstraite d un modèle C++ particulier, les données étant écrites par la transformation amont et lues par le processus de génération de C++. On notera qu en plus de fournir l implémentation du méta-modèle, l EMF génère aussi un éditeur graphique arborescent permettant de créer des instances de notre méta-modèle. Ceci nous a été très utile, en nous permettant de créer des modèles exemples mis en entrée de l opération de sérialisation de notre générateur, qui a ainsi pu se faire parallèlement à la définition du méta-modèle. Au final, le méta-modèle que nous avons développé contient environ une centaine d éléments décrivant les concepts du langage C++. Sans entrer dans ce niveau de détail, nous allons en préciser les principales caractéristiques. La figure 6.3 montre par exemple la partie du méta-modèle introduisant la notion de fichier. Ainsi le design C++ (CppDesign) est l élément racine de notre méta-modèle, peut contenir deux types de fichiers différents : ceux de définition (HeaderFile) et ceux d implémentation (CppFile). On notera que nous avons défini un type particulier de fichier d implémentation, le TemplateFile qui correspond à l implémentation des opérations d une classe paramétrée (template) 4. La clause d inclusion d un fichier de définition se situant au début de tout fichier C++ est traduite par le rôle IncludeFile de la 3 L Eclipse Modeling Framework propose en effet une implémentation du méta-méta-modèle MOF apportant de très légères modifications au standard défini par l OMG, et l a baptisé Ecore. C est sur ce méta-méta-modèle que tous les autres méta-modèles sont implémentés dans l EMF, y compris UML. Les différences entre l Ecore et le MOF ne concernent que certains détails d implémentation, et n ont pour nous pas été sensibles du tout. 4 L équipe SPG conseille de séparer comme pour une classe normale la partie définition et implémentation d une classe template, bien qu en pratique le compilateur parcourt la définition et de l implémentation des classes template dans la même passe, la véritable compilation de l implémentation ayant lieu lors de l instanciation de celle-ci. Ceci a pour conséquence le rajout d une inclusion vers le fichier.tpp à la fin du fichier de définition, que nous avons traduite par le rôle includetpp de la méta-classe HeaderFile. 104/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

105 6.2. Générateur de code SystemC/C++ FIG. 6.3 Exemple des classes définies dans le méta-modèle méta-classe file. Celui-ci pointe vers un fichier de définition (rôle headerfile), mais possède aussi des attributs spécifiques qui ne sont pas directement inclus dans la syntaxe C++, comme la liste des types qui sont implicitement importés par l inclusion (similairement à la clause import du langage Java). Cette liste, construite au moment de la transformation ATL nous a été utile notamment pour la définition de déclarations anticipées de types dans les fichiers de définition (le rôle forwarddecl), qui est parfois nécessaire pour la compilation de fichiers interdépendants (lorsque deux fichiers s incluent réciproquement). Nous détaillerons un peu plus loin comment nous avons procédé cette analyse dans la transformation ATL. Le générateur de code va donc charger une instance de ce méta-modèle, et en partant de l élément racine (CPPDesign) va appeler des règles différentes suivant qu il s agisse de fichiers de définition ou d implémentation. La figure 6.4 nous montre un aperçu de ce que peut contenir un fichier, et plus précisément la notion de classe. On voit que nous supportons deux types d opérations pouvant être définies à l intérieur d une classe (ClassOperation ou à l extérieur (Operation), celle-ci permettant de générer du code C. Dans tous les cas, les opérations sont impliqués dans deux associations bidirectionnelles permettant de définir le nom du fichier dans lequel elles sont définies et implémentés (la relation étant bidirectionnelle, un fichier connait les définitions et les implémentations qu il contient). Bien que cela ne soit pas représenté sur notre figure, ces mêmes relations existent pour la notion de Type, dont la méta-classe Class est une spécialisation. Nous ne montrerons pas tout notre méta-modèle, mais nous noterons que nous avons introduit la notion d espace de nom NameSpace dont la Class est aussi une spécialisation. Nous supportons aussi, la notion d élément typé, et en avons distingué des sous-catégories, en introduisant par exemple la notion de pointeur, et aussi de conteneur, permettant d accéder à d autres éléments typés qu ils contiennent. Ces éléments peuvent de plus être d un type paramétrable (TemplateableInstance), dont nous supportons la définition et l instanciation. En ce qui concerne le corps des opérations, nous n avons pas la finesse du code C++ notamment pour la manipulation des variables. Ainsi le code contenu dans une opération peut être considéré comme une suite ordonnée d OperationBodyElement. Ceux-ci peuvent être simplement une chaine de caractères que le générateur insérera directement dans l implémentation de l opération. Cependant, Sébastien Revol Thèse de doctorat 105/161

106 Chapitre 6. Exploitation du langage ESL FIG. 6.4 Définition de la notion de classe dans le méta-modèle de C++ nous avons aussi introduit d autres catégories d OperationBodyElement, telles que la notion de bloc de contrôle afin de pouvoir identifier et sérialiser les structures algorithmiques du C++ comme les blocs If, While, Switch etc. Ceux-ci possèdent des attributs tels que la garde, l initialisation de boucle etc. mais peuvent aussi contenir, de manière récursive d autres OperationBodyElement, pouvant être à leur tour des chaines de caractères ou d autres blocs de contrôles. Nous avons dû aussi implémenter la possibilité d effectuer des appels d opérations. Ceci a impliqué l implémentation de la notion d instance d élément typé, afin de pouvoir accéder aux opérations définies par le type de cette instance. Le générateur de code va prendre en compte si l élément typé est un conteneur et pointeur, pour automatiquement décider si l accès à une variable ou une fonction membre d une classe doit se faire par l opérateur. ou ->. Ceci nous permet par exemple de générer automatiquement des fragments de code tels que : porta[0]->bind(*portb[0]) ; portc[1].bind(portd[1]) ; Dans ce cas, porta et portb sont des vecteurs de pointeurs de port, alors que portc et portd sont des vecteurs de ports 5. Dans le premier cas, le générateur a tenu compte du fait que les éléments contenus étaient de type pointeur, et que l on s adressait à l instance de ce qui est pointé par ceux-ci pour insérer automatiquement les opérateurs -> et *. Enfin nous préciserons que nous avons introduit dans le méta-modèle des notions propres à SystemC, comme étant des notions dérivées du C++. Ainsi nous identifions le sc module comme un type particulier de classe, pouvant contenir des types particuliers d attributs et d opérations tels les ports, les sc method et les sc thread. Ces informations sont utilisées par le générateur de code pour insérer des macros particulières 6, ainsi que pour spécifier un ordre précis dans la déclaration de ces 5 Le SystemC pur ne permet pas de faire des vecteur classiques (std :: vector) de ports sans passer par des pointeurs, les types de ports ne possédant pas de constructeurs de recopie. Les développeurs de l équipe SPG ont résolu ce problème en définissant un conteneur particulier : le tlm object vector. 6 On notera ici que la notion de macro n a pas été prise en compte dans le méta-modèle, et les macros spécifiques à SystemC sont inscrites en dur dans le générateur de code. 106/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

107 6.2. Générateur de code SystemC/C++ FIG. 6.5 La notion de connexion (Binding) dans le méta-modèle de C++ variables particulières. Par exemple, dans une définition de module on déclarera d abord les ports puis les exports, suivis de tous les attributs normaux de la classe. De plus, cette introduction de concepts SystemC nous apporte le bénéfice de simplifier la transformation de modèles amont, en rendant les concepts de l implémentation plus proches de ceux de leur représentation en UML. Ceci est illustré dans la figure 6.5 qui définit la notion de connexion (SCBinding) en SystemC. Ainsi, ce concept qui se représente à l aide de connecteurs en UML est implémenté par des appels d opérations dans le corps du constructeur du module qui contient ces connections. Le SCBinding étend donc la notion d appel d opération, et ses attributs source et target redéfinissent respectivement les attributs operationcontainer (l instance de l attribut dont le type définit l opération appelée) et parametervaluespecification (la valeur que l on donne à un paramètre défini dans une opération). Ainsi la création de connexion se fait plus intuitivement dans la transformation, en se référant directement aux attributs source et target d un SCBinding. La différentiation entre les différents types de ces SCBindings est alors une fois de plus utilisée pour spécifier l ordre dans lequel ils seront automatiquement insérés dans le corps du constructeur du module Les profils C++ et SystemC associés Une fois notre méta-modèle réalisé, nous avons défini la manière d en exprimer les concepts en UML. Comme nous pouvons le voir dans la figure 6.2, ceci s est fait grâce à deux profils qui peuvent être appliqués sur les modèles utilisateurs : le profil UML for SystemC, ainsi qu un profil C++ (ST- CppProfile) que nous avons défini afin de permettre l ajout d informations spécifiques à ce langage. Cependant, nous tenons à souligner que l application de ces deux profils est optionnelle. En effet nous avons défini une sémantique par défaut à la plupart des notions que l on peut retrouver dans un diagramme de classes d UML afin de permettre une édition de code C++ en UML rapide et intuitive. Par exemple, la définition d une classe créera automatiquement un ou deux fichiers (suivant qu elle possède des implémentations d opérations) portant respectivement les noms nom-de-la-classe.h et nom-de-la-classe.cpp pour y insérer les définitions et les implémentations. Le profil C++ sert alors à paramétrer ce comportement par défaut, ainsi qu à rajouter des information spécifiques du C++ que ne permettait pas d exprimer facilement la syntaxe UML. Sébastien Revol Thèse de doctorat 107/161

108 Chapitre 6. Exploitation du langage ESL FIG. 6.6 Exemple de stéréotypes C Le profil C++ La figure 6.6 illustre quelques-uns des stéréotypes du profil C++. Nous étendons par exemple la notion de type en permettant de spécifier le nom du fichier dans lequel il est défini avec la tagged value definitionfile. Le booléen generate nous permet quant-à lui de spécifier si l on veut que l outil génère le code pour ce type. Ceci a été notamment utilisé pour la définition de bibliothèques de modèles, représentant des classes déjà existantes dans le système (telle la Standard Template Library (STL). On voit aussi que nous avons spécialisé l Operation UML. On peut ainsi spécifier si celle-ci est const (signifiant qu elle n a pas d effets de bords), virtuelle ou virtuelle pure (pour obliger l implémentation de son corps pour la classe qui en hérite. On remarquera la tagged value includedfiles qui permet de rajouter des fichiers de définition à inclure en plus par le fichier d implémentation de l opération. En effet bien que la gestion des inclusions soit en grande partie automatisée (chaque type étant associé à un nom de fichier de définition), le corps des opérations peut être spécifié par des chaines de caractères qui ne sont pas analysées par le générateur. De ce fait, il est dans ce cas à la charge de l utilisateur de spécifier le noms des fichiers définissant des types auxquels il fait appel dans ces parties de l implémentation des opérations. Enfin on voit sur la figure que les attributs d une classe on été aussi spécialisés, permettant notamment de spécifier des valeurs pour les paramètres de son constructeur, dont l appel peut être directement chaîné à celui du constructeur de la classe qui contient cet attribut (tagged values ParamValSpec et constructortochain). Les stéréotypes présentés là ne sont pas les seuls, et nous avons notamment redéfini un mécanisme de paramétrisation (template) un peu plus simple et plus proche de ce que l on retrouve dans le langage C++, spécialisé l héritage pour spécifier des appels aux constructeurs de la classe héritée chaînés au constructeur de la classe fille, ou encore ajouté la notion de pointeur sur les éléments typés. De plus nous avons spécialisé les paquetages (Package) avec la notion d espace de nommage (Namespace). En effet, bien qu UML identifie un paquetage à un Namespace, nous avons permis son utilisation comme un simple moyen d organiser le contenu d un modèle. Ainsi seuls les éléments contenus dans un paquetage stéréotypé CppNamespace seront effectivement définis dans un espace de nommage C++ correspondant Le profil SystemC Le profil SystemC que nous avons implémenté est celui qui a été défini par Sara Bocchio et al. Nous vous invitons à lire les nombreuses publications à son sujet et notamment [101, 102] pour en obtenir une présentation plus détaillée. Son principe est de réaliser une transcription un-pourun des concepts de SystemC en UML. On retrouve par exemple les stéréotypes sc module, sc port, 108/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

109 6.2. Générateur de code SystemC/C++ sc export ou encore sc interface afin de représenter ces notions en UML. On notera que le profil permet d exploiter des informations spécifiques au diagramme de structure composite et que l on ne retrouve pas dans un diagramme de classes. C est bien sur le cas des Connectors, qui représentent les interconnections entre les composants, et qui seront traduits en SCBindings de notre méta-modèle. De plus, le profil permet lui aussi de spécialiser les opérations d UML afin d identifier les processus SystemC : les sc threads et sc methods. La spécification du comportement des opérations est aussi spécialisée, en introduisant la possibilité de l exprimer à l aide du diagramme de machines à états d UML. Ainsi les stéréotypes qu il définit spécialisent la notion d état, de transition etc. Ils permettent de représenter des algorithmes C++ en insérant directement dans ce diagramme la notion de bloc for, switch, if etc. De plus les états de suspension des processus SystemC (wait) peuvent être aussi représentés, ainsi que les événements qui leur permettront d en sortir. Le langage d action, permettant de spécifier le comportement des activités à l intérieur d un état est directement le C++. La génération de code tient donc compte de l organisation de ces états à l aide des pseudo-états algorithmiques (for, switch, etc.) et des transitions pour en générer le code correspondant et insérer le corps des activités spécifiées directement en C++ à l intérieur des états. Nous précisons bien que ces machines d état algorithmiques ne sont qu une notation alternative permettant de mettre en valeur un algorithme particulier ainsi que les moments où les processus sont suspendus, mais qu il est toujours possible de décrire directement le corps d une opération directement en C++ à l aide d un OpaqueBehaviour UML Les bibliothèques de modèles Enfin comme le montre la figure 6.2, le modèle utilisateur en entrée du générateur de code peut aussi faire appel à des bibliothèques de modèles (ModelLibrary). Ces bibliothèques n ont aucune influence sur le comportement du générateur. Il s agit simplement d une liste de types et d opérations prédéfinis pouvant être utilisés par la personne qui réalise un modèle SystemC/C++. Ainsi nous avons défini une bibliothèque purement C++ pour représenter les classes de la STL, ainsi qu une bibliothèque SystemC-TLM, représentant les nombreux types et classes définis par le standard SystemC [95] (en plus de ceux identifiés comme éléments du langage par le profil), ainsi que ceux définis par le standard TLM [127]. Nous y avons aussi inclus des classes propres à l équipe SPG, telles les définitions de protocoles TLM utilisés pas STMicroelectronics ainsi que des classes facilitant l édition des modèles comme le tlm object vector ou le tlm register. En étant importées dans le modèle à générer, ces bibliothèques permettent ainsi de typer des éléments ou d hériter de classes qu elles contiennent, sans avoir à les redéfinir dans chaque modèle. Tout les éléments des bibliothèques sont stéréotypés avec les informations nécessaires, par exemple sur leurs fichiers de définition pour que le générateur de code retranscrive ces informations. Celui-ci considère donc les éléments des bibliothèques importées comme des éléments du modèle à générer, et c est simplement la tagged value generate qui va décider ou non de la génération de ceux-ci Transformation ATL d UML vers la syntaxe abstraite C++/SystemC Comme nous l avons introduit, la transformation ATL en première partie de la phase de génération de code sert donc à convertir le modèle UML sur lequel sont éventuellement appliqués les profils C++ et SystemC vers une instance du méta-modèle intermédiaire. C est dans cette transformation que se trouve l intelligence du traitement des informations contenues dans le modèle pour obtenir du C++ compilable. Ainsi la transformation se décompose en deux grandes parties. La première se base sur des règles de correspondances (matched rules) transformant les concepts d UML en leur correspondant Sébastien Revol Thèse de doctorat 109/161

110 Chapitre 6. Exploitation du langage ESL sur le méta-modèle C++. Ces règles peuvent être parfois simples, comme par exemple le fait de dire qu une Class d UML correspond à une Class du méta-modèle, mais peuvent inclure des phases plus complexes, comme pour le traitement des machines à état qu il faut parcourir en détectant par exemple les boucles, et nous a forcé à utiliser la syntaxe impérative du langage de transformation. La deuxième partie de la transformation est un traitement a postériori, qui est effectué une fois que tous les éléments ont été créés. On retrouve dans cette partie l analyse des interdépendances entre les fichiers à générer afin de pouvoir positionner s il y a lieu des déclarations anticipées de type (forward declaration) pour que la compilation des fichiers puisse se dérouler correctement. De plus, c est aussi dans cette phase que nous effectuons la substitution des types dans le mécanisme de template du C++. En effet lorsqu une classe hérite d une autre classe paramétrée par un type, l héritage en C++ peut spécifier quel type réel va remplacer celui qui était en paramètre de la classe mère. Ce type est alors à propager sur tous les éléments hérités dans la classe fille, comme le type des paramètres d une opération ou de certains attributs. Le langage OCL employé par ATL a été très utile dans cette partie impérative de la transformation, nous permettant d effectuer de puissantes requêtes sur les modèles pour en effectuer l analyse Intégration dans Eclipse Le générateur de code a été intégré dans l environnement de travail basé sur Eclipse réalisé par ST- Microelectronics, le STWorkbench, sous la forme de plugins. Les parties transformation et génération ont été insérés dans deux plugins différents indépendants, de telle sorte que la partie sérialisation puisse-être utilisée par d autres plugins. Un troisième plugin, contenant des extensions de l interface graphique a aussi été réalisé pour sélectionner facilement le modèle à générer ainsi que le répertoire de destination. Nous avons aussi réalisé un petit générateur de code annexe, permettant de créer un fichier de configuration (tlm local depend.txt), lui-même servant d entrée au générateur de makefile réalisé dans l équipe SPG. On voit dans la figure 6.7 qu il est possible de spécifier des dépendances supplémentaires à celles détectées dans le modèle par notre petit générateur, celui-ci n étant pas capable de lire le code C++ directement inséré dans les modèles. 6.3 Transformation d IP-XACT vers le profil ESL Nous allons maintenant présenter les principes de la transformation de modèles Transfo1 de la figure 6.1. Cette transformation partant d un fichier IP-XACT pour obtenir une description dans le profil ESL, a été elle aussi implémentée en ATL, et fut la plus simple à réaliser du fait de la grande ressemblance entre les deux méta-modèles. Nous présenterons dans un premier temps ce qui nous a motivé à développer cette transformation, puis rentrerons un peu dans les détails de celle-ci Motivations Dans une approche de flot de conception Top-Down des systèmes sur puce, le profil ESL se positionne comme un moyen de spécifier rapidement les caractéristiques d un composant, et d en dériver via le flot de génération de code (notamment grâce à la transformation suivante ESL-UMLSystemC que nous allons présenter par la suite) une grande partie de son implémentation dans un niveau de modélisation et un langage donné, accompagnée de sa description IP-XACT. Cependant, nous avons trouvé utile d implémenter une transformation allant en quelque sorte dans l autre sens, capable de transformer la description IP-XACT existante d un composant en une description UML- 110/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

111 6.3. Transformation d IP-XACT vers le profil ESL FIG. 6.7 Capture d écran de l interface de configuration du générateur de code ESL équivalente. Nous voyons en effet deux principaux cas d utilisation où cette transformation peut s avérer utile. La première, qui arrive assez fréquemment chez STMicroelectronics à l heure actuelle, est lorsque la description IP-XACT existe déjà et que l implémentation du composant dans le langage désiré n est elle pas encore réalisée. Cela peut se produire par exemple lorsqu un concepteur veut intégrer dans son système un composant vendu par un fournisseur externe. Celui-ci peut ne vendre que le modèle au niveau RTL (celui qui sera effectivement synthétisé sur la puce) accompagné de se description IP- XACT. Si maintenant l intégrateur requiert un modèle TLM de ce composant pour par exemple effectuer des simulations d analyse architecturale ou pour engager le développement parallèle du logiciel embarqué avant la réalisation de la puce, l enchaînement de la transformation Transfo1, Transfo2 et de la génération de code lui permet d obtenir très rapidement une grande partie de l implémentation du modèle TLM. A l heure actuelle, l équipe SPG exploite déjà le même genre de flot de génération grâce à un outil interne appelé TLM Skeleton. Le format intermédiaire que fournit le profil ESL dans notre cas peut être aussi un avantage par rapport à cet outil, dans le cas où l on désire générer une implémentation à un autre niveau d abstraction, où même dans un autre langage que le SystemC- TLM, puisque dans notre cas seule la deuxième partie du flot de génération est à redéfinir. Un autre cas où la spécification IP-XACT existe avant le modèle TLM visé arrive chez STMicroelectronics. Il s inscrit dans un flot d automatisation partant d un format de spécification des composants encore plus abstrait qu IP-XACT : les spécifications textuelles (Data Sheet) écrites dans le format du logiciel d édition FrameMaker. STMicroelectronics a en effet défini une manière standard de spécifier les tableaux de registres tels que celui du tableau 5.4 dans ce format, afin de pouvoir générer la description IP-XACT correspondante, et de l enchainer après complétion avec le flot de génération de code. En se servant d IP-XACT comme format intermédiaire, il nous est aussi possible Sébastien Revol Thèse de doctorat 111/161

112 Chapitre 6. Exploitation du langage ESL de se greffer sur la sortie de l analyse des spécifications textuelles. On peut cependant espérer qu un jour un flot de spécification entièrement basé sur UML existera, partant de l exigence des clients jusqu à l implémentation. Dans ce cas là, la documentation d un composant pourrait être réalisée en même temps que sa spécification à l aide d UML, et la transformation la plus courante se ferait alors dans l autre sens : depuis le modèle UML vers sa Data Sheet en format textuel. Une deuxième motivation nous a poussé à développer cette transformation de modèles. En effet même lorsque la description IP-XACT d un composant ainsi que ses différents modèles d implémentation existent, le portage au niveau UML de ses spécifications peut s avérer utile. En effet il permet alors de bénéficier de travaux issus d autres initiatives, comme celles autour du standard MARTE [41] pour effectuer par exemple des études architecturales. Nous reviendrons sur ce point dans la partie en montrant qu il est possible d appliquer simultanément deux profils sur le même modèle, permettant ainsi d utiliser celui-ci à la fois dans une approche de conception (par le flot de génération que nous avons défini) et d analyse. Ainsi l import des descriptions IP-XACT existantes permet d obtenir très rapidement un support pour des annotations complémentaires, et exprimer par exemple le portage d une application sur une architecture matérielle donnée pour en analyser les performances Principes de la transformation La transformation depuis IP-XACT vers le profil ESL consiste en l extraction des informations non spécifiques à une implémentation contenues dans un fichier IP-XACT, telles que l identifiant VLNV, les interfaces de bus et la carte des registres. Nous avons de plus développé une bibliothèque de modèles au niveau ESL, contenant des définitions de bus (BusDefinition) ainsi que les types des contrôleurs d interface (MasterBusIfCtrlrDef, SlaveBusIfCtrlrDef etc.) associés. Ainsi cette bibliothèque est un paramètre d entrée de la transformation pour que cette dernière puisse vérifier si les définitions de bus du modèle IP-XACT d entrée y figurent (par comparaison de VLNV). Si c est le cas, elle créera automatiquement un import de cette bibliothèque dans le modèle généré, et les types utilisés seront ceux qu elle définit. Si ce n est pas le cas, la transformation créera dans le modèle cible ces définition de bus et types de contrôleurs correspondants. L essentiel de la transformation est écrit de manière déclarative, à l aide de règles de correspondance entre les concepts d IP-XACT et du profil ESL qui sont assez proches. Cependant, une partie d analyse un peu plus complexe a ici aussi été réalisée dans la transformation, permettant de factoriser les interfaces de bus, les registres et les champs qu ils contiennent. En effet, comme nous l avons précisé dans la présentation du profil ESL, IP-XACT ne propose pas une dissociation systématique de la forme Type/Instance. Ceci implique une réécriture multiple de la même information, qui va être factorisée par notre analyse. Considérons le fragment de code IP-XACT du listing 6.1. Il définit deux champs PERCK0 et PERK1 dans un registre. En regardant attentivement, on voit que seuls le nom et la valeur de l offset varient entre ceux-ci, étant de même largeur (1 bit), possédant un même type d accès (read-only), et pouvant prendre les même valeurs. L analyse définie dans la transformation va donc parcourir tous les champs et étudier les valeurs que nous avons qualifiées comme déterminantes d un type de champ (ces valeurs correspondent aux tagged values des stéréotypes permettant la définition de types, RegisterMapDef, RegisterDef et FieldDef, cf. section pour les concepts de la carte de registre). Pour la création des instances de ces types, deux possibilités ont été données, basées sur l analyse des noms. Si les noms de deux entités identifiées comme ayant le même type (champ, registre ou carte de registres) sont identiques à un index numérique près (pouvant se situer n importe où dans le nom), ces deux entités vont être regroupées dans un vecteur portant le nom sans l index, et l attribut offsetmap 112/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

113 6.3. Transformation d IP-XACT vers le profil ESL <spirit:field> 2 <spirit:name>perck0</spirit:name> <spirit:bitoffset>0</spirit:bitoffset> 4 <spirit:bitwidth>1</spirit:bitwidth> <spirit:access>read-only</spirit:access> 6 <spirit:description> <spirit:values> 8 <spirit:value>0x0</spirit:value> <spirit:name>b_0x0</spirit:name> 10 </spirit:values> <spirit:values> 12 <spirit:value>0x1</spirit:value> <spirit:name>b_0x1</spirit:name> 14 </spirit:values> </spirit:field> 16 <spirit:field> <spirit:name>perck1</spirit:name> 18 <spirit:bitoffset>1</spirit:bitoffset> <spirit:bitwidth>1</spirit:bitwidth> 20 <spirit:access>read-only</spirit:access> <spirit:values> 22 <spirit:value>0x0</spirit:value> <spirit:name>b_0x0</spirit:name> 24 </spirit:values> <spirit:values> 26 <spirit:value>0x1</spirit:value> <spirit:name>b_0x1</spirit:name> 28 </spirit:values> </spirit:field> Listing 6.1 Exemple de code de champs de registres IP-XACT Sébastien Revol Thèse de doctorat 113/161

114 Chapitre 6. Exploitation du langage ESL FIG. 6.8 Exemple de résultat du processus de factorisation des champs de registre contiendra la liste ordonnée des décalages (bitoffset dans le cas des champs). Si les noms sont trop différents, on créera une instance pour chacune des entités. La figure 6.8 montre le résultat de la factorisation en UML de notre exemple. On voit que les noms étant proches, les champs du registre SRC PCKSR ont tous été factorisés dans l attribut PERCK (il y en avait en réalité 32 identiques). On notera que pour le type du champ, qui peut être partagé par de nombreuses instances portant des noms tout à fait différents, le nom est généré à partir des caractéristiques qui définissent ce type. Précisons que même dans le cas d une factorisation dans un vecteur, la transformation ne perd aucune information. En effet nous avons pris soin de générer un commentaire associé au vecteur, dans lequel est rappelé de manière facilement parcourable le nom original des éléments factorisés en correspondance avec leur index, permettant d effectuer si besoin un processus de défactorisation regénérant le même fichier que l original. Ce processus de factorisation-défactorisation montre l intérêt que peut présenter l édition d un composant avec le profil ESL. Pour le composant complexe dont est extrait l exemple que nous avons illustré, la transformation a déterminé qu il y avait 35 types de registres différents parmi les 39 registres originaux, mais seulement 18 types différents de champs parmi les 550 définis dans la description originale, et seulement 2 types d interface de bus regroupés en trois vecteurs parmi les 193 que le composant comportait originalement Implémentation de la transformation Cette transformation s effectue entre le méta-modèle d IP-XACT et le méta-modèle d UML augmenté du profil ESL. La définition du profil a été réalisée tout comme celle des profils C++ et SystemC, grâce à l outil UML Papyrus, reposant sur l implémentation du méta-modèle d UML native à l Eclipse Modeling Framework. En revanche il nous a fallu définir un méta-modèle d IP-XACT. Ceci a été en fait très aisé grâce aux outils fournis par l EMF. En effet, le standard IP-XACT est délivré sous la forme d un schéma XML 7. Comme nous l avons présenté dans la section 3.3.1, un schéma peut être considérée comme un méta-modèle dans le contexte technologique défini par le World Wild Web Consortium (W3C). L Eclipse Modeling Framework fournit parmi ces outils une passerelle capable d effectuer une transcription entre le format des schémas et le méta-méta-modèle Ecore d Eclipse. Ainsi cette passerelle permet de générer les classes Java implémentant ce méta-modèle et permettant de l instancier dynamiquement dans Eclipse. De plus, le processus de sérialisation/désérialisation est aussi adapté. En effet, le format natif de l EMF pour le chargement et la sauvegarde des modèles est 7 Ce schéma est téléchargeable librement sur site 114/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

115 6.3. Transformation d IP-XACT vers le profil ESL FIG. 6.9 L interface de paramétrage de la transformation IP-XACT vers ESL normalement le XMI ([92], cf section 3.3.2). Dans le cas où le méta-modèle a été importé depuis une grammaire XML, les classes de sérialisation et désérialisation sont automatiquement adaptées afin de pouvoir charger et sauvegarder des modèles conformes à la grammaire originale plutôt que dans le format XMI. Grâce à cela, le chargement des fichiers IP-XACT en entrée de notre transformation, ainsi que le parcourt de ces éléments n a nécessité aucun développement. Enfin nous préciserons que tout comme pour la génération de code, la transformation a été encapsulée dans un plugin pour être intégrée à Eclipse. Celui-ci présente une interface 8 qui permet de lancer simplement la transformation. Ceci est notamment fait depuis la même extension de l interface graphique que pour la génération de code, dans un onglet différent. La figure 6.9 montre cet onglet. On remarquera les deux options, Facorize Registers and Field Values et Factorize Ports qui nous permettent de spécifier si nous désirons que la transformation effectue la factorisation. Il se peut en effet, notamment lorsque les interfaces de bus ne sont pas nombreuses, que l on désire qu elles ne soient pas factorisées. Dans ce cas, la transformation ne place pas les instances dans un vecteur, et dans le cas des cartes de registres, un type et une instance sont créées pour chaque registre ou champ. Techniquement parlant, la paramétrisation d une transformation ATL reste dans le cadre de l IDM. Il faut en effet utiliser un modèle de paramètres, qui va être placé en entrée de la transformation, pouvant ainsi être lu comme tout autre modèle et influencer les règles de transformations. Ainsi la sélection ou non des options de factorisation dans l interface graphique entraîne une génération à la volée d un fichier XML, chargé en entrée de la transformation ATL avec les autres modèles vers lesquels la transformation fait référence (le modèle IP-XACT à transformer, 8 L architecture de plugins dans Eclipse est un parfait exemple de programmation orientée composants, chaque plugin présentant des interfaces fournies et requises vis à vis des autres plugins Sébastien Revol Thèse de doctorat 115/161

116 Chapitre 6. Exploitation du langage ESL son méta-modèle, le méta-modèle d UML, le profil ESL et la bibliothèque de classes ESL). 6.4 Transformation du profil ESL vers les profils SystemC-C Présentation générale Nous abordons maintenant la transformation Transfo2 de la figure 6.1. Celle-ci prend en entrée un modèle de spécification réalisé avec le profil ESL pour générer le modèle d implémentation correspondant. Celui-ci est au niveau d abstraction TLM-PV (Programmer s View) et s appuie sur les profils SystemC et C++ que nous avons présentés dans la section La transformation peut-être vue comme une écriture en dur du savoir-faire des membres de l équipe SPG pour interpréter une spécification de composant et en dériver un modèle TLM. Le profil ESL ne comportant à l heure actuelle pas de concepts pour la description comportementale, c est essentiellement un modèle structurel qui en est dérivé. Cependant, comme nous allons le voir, les informations contenues dans la carte de registres d un composant permettent d implémenter automatiquement les mécanismes d accès en écriture et lecture dans les registres. Cette partie, souvent fastidieuse à réaliser à la main par le concepteur de modèles TLM, fournit une base solide pour la complétion du modèle. Le code qui peut-être généré à l issu de cette transformation a été réalisé pour que l utilisateur n ait plus qu à se focaliser sur les concepts comportementaux du composant, en ajoutant dans celui-ci les processus qui réalisent son comportement, ainsi qu en complétant le code des registres identifiés comme ayant un effet de bord (cf 5.3.5). Le fait que le modèle de sortie de la transformation reste au niveau UML procure aussi plusieurs avantages. On aurait en effet pu imaginer générer le code directement après la transformation sans passer par un modèle UML intermédiaire. Cependant, le profil UML for SystemC permet encore de gagner du temps comparativement à l édition manuelle du code source. Par exemple, la création d une sc_thread ou d une sc_method se fait plus directement en UML, le générateur de code répercutant les différentes macros et opérations d initialisation. Le corps des ces processus peut de plus être représenté à l aide des machines d état du profil UML for SystemC. Nous gardons ainsi tous les avantages que décrivent Sara Bocchio et al. pour l utilisation de leur profil, sans en avoir les inconvénients causés par son niveau d abstraction trop près de l implémentation, qui peut rendre la réalisation complète d un composant TLM très fastidieuse. Enfin le fait de rester au niveau UML permettra aussi, lorsque la transformation sera implémentée, de générer une description IP-XACT complète pour un nouveau composant. Celleci contenant des information à la fois sur la spécification et l implémentation, l association des deux modèles ESL et UML for SystemC est nécessaire à l obtention d une description complète. A l heure actuelle, les concepteurs de modèles TLM doivent reporter eux-mêmes, à la main, les informations spécifiques à leur implémentation dans un fichier IP-XACT. Avec le modèle UML for SystemC, la modification du nom d un port, l ajout d un paramètre au constructeur du composant etc. pourront être automatiquement retranscrits dans la description IP-XACT La création des modules Nous allons maintenant rentrer un peu plus dans les détails de l interprétation qui est faite du modèle de spécification. Nous allons pour ceci reprendre l exemple du timer qui nous avait servi de support lors de la présentation du paquetage sur les cartes de registres du profil ESL (section 5.3). Nous avions représenté dans la figure 5.9 la carte de registres de ce timer. Dans la figure 6.10, nous montrons comment elle est instanciée dans ce composant, et reliée à son interface de bus esclave 116/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

117 6.4. Transformation du profil ESL vers les profils SystemC-C++ FIG Spécification d un timer dans le profil ESL SLAVE AHB. De plus nous voyons aussi que nous avons doté le timer de deux ports maîtres (IN- TERRUPT[2]), représentant des signaux d interruption. Nous avons aussi utilisé la tagged values has- WriteSideEffect définies par le stéréotype Register du sous-paquetage TLMBehaviour pour spécifier que le registre de control ControlRegister a un effet de bord lorsqu il est accédé en écriture. A titre d exemple, nous avons de plus précisé par la tagged value keepfactorized de ce même stéréotype que nous voulions que les deux registres déclarés par le vecteur TimerLoad ne soit pas laissés factorisés dans l implémentation. La figure 6.11 montre le résultat de la transformation. Les classes grisées font partie de la bibliothèque de modèles TLM. Elles ont été représentées dans la figure pour comprendre le mécanisme d héritage mis en jeux dans la transformation. La modélisation des communications au niveau TLM-PV chez STMicroelectronics repose essentiellement sur deux protocoles : TAC et Synchro [46]. Le protocole TAC (pour Transaction Accurate Communication) est une abstraction des modèles de communications se basant sur le mécanisme d adressage. Ainsi comme on peut le voir dans la figure 6.11, il introduit par l intermédiaire de l interface tac if un ensemble de fonctions telles que read(address, data,...) ou write(address, data,...) qui devront être implémentées par tout composant esclave voulant fournir un accès en lecture et/ou écriture à ses registres ou à un espace de mémoire qu il contient. Ces fonctions seront alors appelées par les composants maîtres voulant y accéder, éventuellement à travers un composant représentant le bus chargé d acheminer les communications. En pratique, ce protocole est utilisé pour représenter toutes les transactions se faisant un travers un bus de communication. Le protocole Synchro est quant à lui une abstraction des communications point-à-point. Il est essentiellement utilisé pour représenter les signaux d interruption reliant directement deux composants. L interface tlm synchro if (non représentée sur la figure) définit alors une seule fonction synch(data) que doit implémenter l esclave, et qui est appelée par le maître qui veut transmettre une donnée. Toute BusDefinition du profil ESL doit être transformée vers un de ces deux protocoles. Le choix entre l un est l autre est effectué par la spécification d une valeur dans la tagged value optionnelle addresssize du stéréotype BusDefinition. Ainsi lorsqu un composant possède un contrôleur d interface de bus cible implémentant une BusDefinition où cet attribut n a pas été spécifié, il sera automatiquement considéré comme un esclave du protocole Synchro et implémentera la fonction Sync. Si une valeur a été spécifiée, cela signifie que les communications se font par un mécanisme d adressage : le composant est alors considéré comme un esclave TAC, et la transformation fournira à celui-ci une implémentation de l interface tac if. Sébastien Revol Thèse de doctorat 117/161

118 Chapitre 6. Exploitation du langage ESL «sc_export» AHB_SLAVE: tac_target_port [1] tac_if + read(,,,,, ) + write(,,,,, ) + read_block(,,,,,,, ) + write_block(,,,,,,, ) + get_target_info(,,, ) + set_target_info(,,, ) ADDRESS : DataType DATA : DataType «cpptemplatebinding» «cpptemplatebinding» tac_slave_base + transport() ADDRESS : DataType DATA : DataType «sc_interface» tlm_transport_if REQ : DataType RSP : DataType + transport() «CppTemplateBinding» boundtypes = [Timer_ControlRegisterTyp e_tlm_register] «CppTemplateBinding» boundtypes = [tlm_uint32_t, tlm_uint16_t] «CppProperty» isconst = true «sc_module» Timer_base # TimerLoad_0: Timer_Reg16BitsRWType_tlm_register # TimerLoad_1: Timer_Reg16BitsRWType_tlm_register # TimerControl: tlm_register_vector # TimerValue: tlm_register_vector «cppproperty» # TIMERLOAD_0_OFFSET: int «cppproperty» # TIMERLOAD_1_OFFSET: int «cppproperty» # TIMERCONTROL_0_OFFSET: int «cppproperty» # TIMERCONTROL_1_OFFSET: int «cppproperty» # TIMERVALUE_0_OFFSET: int «cppproperty» # TIMERVALUE_1_OFFSET: int # endianness_c: tlm_endianness # reset() # value_with_be_16(, ) «cppconstructor» + Timer_base(, ) «destroy» + Timer_base() # decode_read_timerregmap(,,,, ) # decode_write_timerregmap(,,,, ) # TimerLoad_0_read(,,,,, ) # TimerLoad_0_write(,,,,, ) # TimerLoad_1_read(,,,,, ) # TimerLoad_1_write(,,,,, ) # TimerControl_read(,,,,,, ) # TimerControl_write(,,,,,, ) # TimerValue_read(,,,,,, ) # TimerValue_write(,,,,,, ) + read(,,,,, ) + write(,,,,, ) + read_block(,,,,,,, ) + write_block(,,,,,,, ) + get_target_info(,,, ) + set_target_info(,,, ) «sc_export» AHB_SLAVE:tac_target_port [1] «sc_port» INTERRUPT:synchro_initiator_port [2] «sc_module» Timer «cppconstructor» + Timer(, ) «destroy» + Timer() + reset() # TimerControl_write(,,,,,, ) FIG Modules générés par la transformation 118/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

119 6.4. Transformation du profil ESL vers les profils SystemC-C++ Dans notre exemple, nous avons spécifié une définition de bus avec une addresssize de 32 bits et une datasize de 16 bits (correspondant à la taille des registres). L interface UML de cette définition de bus est implémentée par la carte de registres, qui rappelons-le est un type particulier de SlaveBusIfCtrlr, spécifiant ainsi que la carte de registres supporte ce protocole. Le connecteur rappelle par quelle interface de bus la carte de registre est accessible. De ce fait, la transformation considérera notre composant comme un esclave TAC. Lorsqu un développeur TLM réalise un composant à la main, il dispose d une classe de base tac_slave_base fournie dans les bibliothèque TLM qu il peut étendre pour développer plus rapidement son composant esclave, celle-ci lui fournissant déjà une implémentation de la couche de transport sur laquelle repose le protocole TAC. En général, un développeur réalisera son composant dans une classe héritant directement de la classe tac_slave_base, en y implémentant notamment les fonctions définies par la tac_if. Comme on peut le voir dans le figure 6.11, la transformation de modèle procède un peu différemment, en rajoutant une classe de base intermédiaire timer_base. C est dans celle-ci que la majorité du code généré par la transformation est implémenté, avec notamment la déclaration et instanciation des ports, mais aussi l implémentation des fonctions de l interface TAC (nous reviendrons sur ce point dans la section 6.4.4). Ainsi, le code à compléter par l utilisateur est dissocié du code qui est déjà implémenté, celui-ci restant accessible par le mécanisme d héritage. Le développeur complètera donc le code de son composant dans la classe Timer, en y rajoutant par exemple les processus qui constituent son comportement. On notera que les informations sur la taille de l adresse et des données (addresssize et datasize) sont interprétées et retranscrites par la substitution (CppTemplateBinding) des types paramétriques ADDRESS et DATA par des types prédéfinis dans la bibliothèque TLM (tlm_uint32_t et tlm_uint16_t). Cette substitution se fait notamment dans l héritage de la classe tac_slave_base<address, DATA> et dans l instanciation du port AHB SLAVE de type tac_target_port<address, DATA> Toutes ces manipulations sont réalisées au cours de la transformation ATL. Ceci inclut l implémentation du corps des opérations. En effet, le langage ATL fournit de puissantes primitives de manipulation de chaines de caractères. Ainsi nous avons pu générer directement le code de certaines opérations au cours de la transformation, ce code étant stocké dans un OpaqueBehaviour UML et associé à l opération implémentée. Bien que nous ne gérions pas de modèle de comportement au niveau ESL, le code généré correspond à l interprétation des informations contenues dans les cartes de registres. On le retrouve principalement dans deux endroits du modèle : l implémentation des registres qui se fait dans des classes générées à part (non représentées dans la figure 6.11), mais aussi dans le code des opérations read(address, data...) et write(address,data...) de la classe Time base Création des registres Chaque registre défini dans le profil ESL est interprété par la transformation. Son type est transformé en une classe héritant de la classe de base de la bibliothèque TLM : tlm_register. La classe générée instancie les champs qui ont été définis dans la RegisterDef, et implémente des fonctions de lecture et d écriture permettant d accéder à la valeur du registre. Le listing 6.2 montre un exemple de code généré dans les fonctions read() write(data) du registre TimerControl. Le registre étant de la taille des données datasize, sa valeur est stockée sur 16 bits, implémentée par la type tlm_uint16_t. La lecture de la valeur de ce registre doit donc se faire en recollant la valeur des champs qui le constituent (OC, TS, P, IE, TM et TE). Ce décalage est calculé par la valeur du bitoffset contenu dans le stéréotype Field du profil ESL. L écriture est basée sur le même principe. Sébastien Revol Thèse de doctorat 119/161

120 Chapitre 6. Exploitation du langage ESL Ces opérations, automatiquement générées à partir d une description de la carte des registres grâce au profil ESL évite au développeur de modèles TLM-PV une gymnastique compliquée. Les informations sur le type d accès (read-only etc.) sont aussi prises en compte dans l implémentation, empêchant par exemple la modification d un champ défini comme accessible seulement en lecture. Lorsque c est un registre entier dont le type d accès en cours n est pas autorisé, une erreur est générée, renvoyée dans le status de la transaction. virtual void write(tlm_uint16_t value){ virtual tlm_uint16_t read(){ OC.write(value >> 0); value = OC.read() << 0; TS.write(value >> 1); value = TS.read() << 1; P.write(value >> 2); value = P.read() << 2; IE.write(value >> 4); value = IE.read() << 4; TM.write(value >> 5); value = TM.read() << 5; TE.write(value >> 6); value = TE.read() << 6; return; return(value); }; }; Listing 6.2 Exemple de code généré dans la fonction d accès en lecture à un registre Ces registres ainsi définis sont instanciés dans la classe de base du composant. Lorsque leur multiplicité est supérieure à 1 et que l on a choisi de les garder dans une forme factorisée, ils sont stockés dans un conteneur particulier, le tlm_register_vector (cf les attributs Timer- Value et TimerControl de la classe (Timer base) dans la figure 6.11). Des constantes sont aussi générées dans la classe pour identifier l adresse de décalage de chacun des registres, comme l attribut TIMER_LOAD_0_OFFSET Implémentation des fonctions Read/Write L implémentation des fonctions de l interface tac_if est réalisée dans la classe de base du composant. Un accès de type read(address, data) par une interface de bus esclave correspond à l accès en lecture d un registre particulier identifié par son adresse. Ainsi, après quelques vérification sur la compatibilité des types de données utilisés par la transaction, la fonction read appelle la fonction decode_read_timerregmap, dont le rôle est de retrouver le bon registre en fonction de l adresse. switch (address){ case TIMERLOAD_0_OFFSET : TimerLoad_0_read(address, data, status, error_reason, byte_enable, target_port_id); if(status.is_ok()) REG_READ_REPORT( "\t%s:\tread data: 0x%x in TimerLoad_0 at address: 0x%x from \"%s\" at T:%9.9f\n", name(), (unsigned int)data, (unsigned int)address, sc_get_curr_simcontext()->get_curr_proc_info()->process_handle->name(), (float)(sc_time_stamp().to_seconds()) ); else ERROR_REPORT(2,"\t%s:\t%s \n", name(),error_reason.get_reason().c_str()); break; Listing 6.3 Fragment de code de la fonction decode read TimerRegMap 120/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

121 6.5. Conclusion Le listing 6.3 montre un fragment de cette fonction. On voit qu elle est constituée d un choix switch(address) dont les cas sont les constantes de décalage définies pour chaque registre. On voit à la ligne 3 qu une fonction de lecture TimerLoad_0_read correspondant au registre concerné est appelée. Par la suite, des informations complètes pour le débogage sont aussi renvoyées. La fonction TimerLoad_0_read est une fonction elle aussi implémentée par la classe de base. C est dans celle-ci qu est vérifié le type d accès du registre et que la fonction de lecture implémentée par l instance de registre correspondant est appelée. Cependant, cette fonction intermédiaire entre le décodage de l adresse et la lecture ou l écriture du registre a aussi un autre rôle. C est en effet dans celle-ci que les effets de bords des accès au registre vont pouvoir être implémentés. Dans notre exemple, nous avions spécifié que le registre TimerControl avait un effet de bord en écriture. Cela s est traduit dans la transformation par la surcharge de l opération TimerControl_write dans la classe utilisateur Timer. L utilisateur pourra utiliser cette fonction pour spécifier ce qu il se produit lors de l accès en écriture du registre, comme par exemple la notification d un événement qui pourra réveiller un process en attente, ou la modification directe de la valeur d autres registres 9. Grâce au mécanisme de surcharge, cette fonction modifiée sera appelée automatiquement par la fonction de décodage, et fait que l utilisateur n a plus du tout à se soucier de celui-ci. Ce mécanisme simplifie au maximum le travail restant pour le développeur qui n a donc plus qu à se concentrer sur la partie comportementale du composant en rajoutant les processus et les effet de bord des accès aux registres. Nous verrons dans le chapitre suivant sur des exemples concrets que ce travail restant peut s avérer très minime pour certains composants. 6.5 Conclusion Nous terminons avec cette transformation le chapitre sur l outillage que nous avons pu réaliser au cours de cette thèse pour l exploitation du profil ESL. Cet outillage a été fait avec le but principal de s intégrer au mieux dans les méthodes de développement prodiguées par l équipe SPG au sein de STMicroelectronics. Les transformations démontrent la possibilité d interaction entre IP-XACT et le profil ESL, et illustrent comment les informations que ce profil contient peuvent être exploitées pour une implémentation spécifique. Nous allons maintenant dans le chapitre prochain présenter un cas d étude concret dans le contexte industriel de STMicroelectronics afin d évaluer l intérêt de notre approche. Nous analyserons les résultats de cette étude et discuterons des limitations et des ouvertures possibles. 9 Ceci se produit fréquemment dans le comportement du matériel, notamment avec les registres de status Sébastien Revol Thèse de doctorat 121/161

122 Chapitre 6. Exploitation du langage ESL 122/161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

123 Troisième partie Etude de cas et évaluation 123

124

125 Chapitre 7 Evaluation et discussion Sommaire 7.1 Cas d évaluation Spécification du cas d étude Les composants modélisés Principes d évaluation Présentation de la méthode d évaluation Détermination des critères d évaluation Evaluation Comparaison UML-ESL et IP-XACT Comparaison des modèles UML-ESL et UML-SystemC Complétude du code généré Comparaison du code généré avec le code original Evaluation de l effort de modélisation et du temps de conception Conclusion de l étude Résumé des résultats Discussion sur les limites de notre étude Conclusion Afin de vérifier la validité de notre approche, nous allons présenter dans ce chapitre une étude de cas. Pour ceci nous avons pris un des systèmes les plus complexes dont l équipe SPG possédait un modèle TLM, et nous avons respécifié certains de ses composants à l aide du profil ESL. Ensuite, les nouveaux composants obtenus par génération de code et complétés manuellement ont été insérés dans la plateforme existante, et un même résultat de simulation qu avec la plateforme originale a été obtenu. Après avoir présenté un peu plus en détails la plateforme et les composants étudiés, nous discuterons des critères d évaluation permettant de juger l adéquation de notre méthode et son apport vis-à-vis des approches et des outils de développement classique. Enfin nous tenterons d avoir un regard objectif sur les limitations actuelles de notre flot et essaierons d envisager des ouvertures possibles pour celui-ci. 7.1 Cas d évaluation Spécification du cas d étude La plateforme que nous avons utilisée pour notre étude de cas est un des modèles les plus complexes réalisés dans l équipe SPG. Il s agit d une puce appelée STi7200 [117] utilisée dans les 125

126 Chapitre 7. Evaluation et discussion FIG. 7.1 Architecture simplifiée de la plateforme STi /161 STMicroelectronics/CEA List xx xxxx 2008 Sébastien Revol

Technologies SOC (System On Chip) (Système sur une seule puce)

Technologies SOC (System On Chip) (Système sur une seule puce) Technologies SOC (System On Chip) (Système sur une seule puce) Pierre LERAY et Jacques WEISS Équipe de recherche ETSN Supélec Campus de Rennes février, 02 Technologies SoC ; P. Leray, J. Weiss 1 Évolution

Plus en détail

SDL: 20 ans de programmation basée modèle

SDL: 20 ans de programmation basée modèle SDL: 20 ans de programmation basée modèle Emmanuel Gaudin emmanuel.gaudin @ pragmadev.com Principes MDE, MDA et MDD: Approche orienté modèle PIM: Platform Independant Model PDM: Platform Definition Model

Plus en détail

MÉTHODOLOGIE DE CONCEPTION DES CIRCUITS INTÉGRÉS DIGITAUX

MÉTHODOLOGIE DE CONCEPTION DES CIRCUITS INTÉGRÉS DIGITAUX MODULE: SYSTEMES NUMERIQUES COMPLEXES Cours 1 MÉTHODOLOGIE DE CONCEPTION DES CIRCUITS INTÉGRÉS DIGITAUX H.Boumeridja 1 Introduction Méthodologie de conception des circuits intégrés digitaux: approche descendante

Plus en détail

Une approche modèle dans la conception de systèmes sur puce hétérogènes

Une approche modèle dans la conception de systèmes sur puce hétérogènes Une approche modèle dans la conception de systèmes sur puce hétérogènes Jean-Luc Dekeyser et Lossan Bondé FETCH 07 IP dans le SoC 100% Réutilisé 80% Spécifique 60% 40% 20% 0% 1999 2002 2005 2008 2011 2014

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

Plus en détail

Prototypage virtuel de système sur puce pour une simulation rapide et fidèle

Prototypage virtuel de système sur puce pour une simulation rapide et fidèle Prototypage virtuel de système sur puce pour une simulation rapide et fidèle Séminaire Collège de France, 29 Janvier 2014 Laurent Maillet-Contoz STMicroelectronics Laurent.Maillet-Contoz@st.com Matthieu

Plus en détail

Architectures logicielles pour les systèmes embarqués temps réel

Architectures logicielles pour les systèmes embarqués temps réel ETR 07 4 septembre 2007 Architectures logicielles pour les systèmes embarqués temps réel Jean-Philippe Babau, Julien DeAntoni jean-philippe.babau@insa-lyon.fr 1/31 Plan Architectures logicielles pour les

Plus en détail

Définition de portabilité en termes de modèle d exécution pour la simulation des systèmes sur puces

Définition de portabilité en termes de modèle d exécution pour la simulation des systèmes sur puces Définition de portabilité en termes de modèle d exécution pour la simulation des systèmes sur puces Giani Velasquez 1, Giovanni Funchal 2,3, and Matthieu Moy 2 1 UJF M1-INFO Stage TER 2 Verimag, 2, avenue

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

CPU ou UCT. Circuit Intégré. Processor (data processing)

CPU ou UCT. Circuit Intégré. Processor (data processing) CPU ou UCT Processor (data processing) Le processeur est une unité d exécution, plus précisément appelée unité centrale de traitement (désignée en franç.par UCT, en ang. CPU (Central Processing Unit) CPU+mémoire

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

Proposition d un plan d étude pour l option «informatique embarquée»

Proposition d un plan d étude pour l option «informatique embarquée» Proposition d un plan d étude pour l option «informatique embarquée» Motivation : L informatique embarquée est un sous ensemble de l informatique qui est en pleine croissance. Elle intègre plusieurs aspects

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Architecture des calculateurs

Architecture des calculateurs Chapitre 1 Architecture des calculateurs 1.1 Introduction Ce paragraphe n a pas la prétention de présenter un cours d informatique. D une manière générale, seuls les caractéristiques architecturales qui

Plus en détail

AADL. un langage pour la modélisation et la génération d applications. Thomas Vergnaud, thomas.vergnaud@enst.fr

AADL. un langage pour la modélisation et la génération d applications. Thomas Vergnaud, thomas.vergnaud@enst.fr AADL un langage pour la modélisation et la génération d applications, thomas.vergnaud@enst.fr Les langages de description d architecture la conception des systèmes devient complexe difficulté de compréhension

Plus en détail

Processeur JAP. Le langage JAVA

Processeur JAP. Le langage JAVA Processeur JAP Ce document présente les dernières nouveautés concernant le processeur JAVA de la société AED. Il commence par un rappel sur les caractéristiques du processeur actuel, puis présente les

Plus en détail

Cours FPGA 02/01/2014. L architecture SOPC Des FPGAs

Cours FPGA 02/01/2014. L architecture SOPC Des FPGAs L architecture SOPC Des FPGAs 1 Ce document aborde l architecture moderne des FPGA et notamment la technologie SOPC (system on programmable chip). Cette technologie SOPC permet d associer des structures

Plus en détail

GEL 1001 Design I (méthodologie)

GEL 1001 Design I (méthodologie) GEL 1001 Design I (méthodologie) Technique 2 Systèmes embarqués et fiabilité Hiver 2013 Département de génie électrique et de génie informatique Plan Système embarqué Ordinateur et architecture Von Neumann

Plus en détail

Les systèmes embarqués et les tendances technologiques: une évolution constante, une innovation continue!

Les systèmes embarqués et les tendances technologiques: une évolution constante, une innovation continue! Les systèmes embarqués et les tendances technologiques: une évolution constante, une innovation continue! Vasiliki Sfyrla Une approche des systèmes embarqués Les systèmes embarqués existent depuis longtemps.

Plus en détail

Gestion du serveur WHS 2011

Gestion du serveur WHS 2011 Chapitre 15 Gestion du serveur WHS 2011 Les principales commandes Windows Home Server 2011 reprend l ergonomie de Windows 7 et intègre les principales commandes de Windows Server 2008 R2. Les commandes

Plus en détail

Parallélisation Automatique

Parallélisation Automatique Parallélisation Automatique Paul Feautrier ENS de Lyon Paul.Feautrier@ens-lyon.fr 8 septembre 2008 1 / 23 Pourquoi la parallélisation automatique? Les gains de performances dus à la technologie s amenuisent

Plus en détail

Etre capable de réaliser et simuler avec Quartus II un compteur en mode schématique Logiciels QuartusII Logique de base, architecture de FPGA

Etre capable de réaliser et simuler avec Quartus II un compteur en mode schématique Logiciels QuartusII Logique de base, architecture de FPGA Cyclone QuartusII design Cyclone Quartus base Quartus II - Schematic Objectif Moyens Préliminaire Théorie Matériel Durée Etre capable de réaliser et simuler avec Quartus II un compteur en mode schématique

Plus en détail

Développer des solutions technologiques basées sur de l électronique

Développer des solutions technologiques basées sur de l électronique Altronic Tunisie ALTRONIC s attache à faciliter la diffusion et le transfert des technologies et des connaissances en électronique vers les laboratoires de recherche publics, industriels, les start-up

Plus en détail

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Notion de méthode de conception de SI Méthodes OO de conception Généralités sur les méthodes

Plus en détail

Soutenance de Thèse. Analyses statistiques des communications sur puce

Soutenance de Thèse. Analyses statistiques des communications sur puce Soutenance de Thèse Analyses statistiques des communications sur puce Antoine Scherrer LIP - ENS Lyon Equipe Compsys 11 décembre 26 A. Scherrer - Analyses statistiques des communications sur puce 1 / 4

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Unity. du changement pour les projets d automatisme. p.1 Présentation. p.2 L environnement Unity. p.3 Les premiers pas avec Unity Pro

Unity. du changement pour les projets d automatisme. p.1 Présentation. p.2 L environnement Unity. p.3 Les premiers pas avec Unity Pro Le magazine Schneider Electric de l enseignement technologique et professionnel Juin 2006 p.1 Présentation p.2 L environnement Unity p.3 Les premiers pas avec Unity Pro p.4 Un besoin de communication p.5

Plus en détail

Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises

Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises Jihed Touzi, Frédérick Bénaben, Hervé Pingaud Thèse soutenue au Centre de Génie Industriel - 9

Plus en détail

Modélisation: outillage et intégration

Modélisation: outillage et intégration Modélisation: outillage et intégration Emmanuel Gaudin emmanuel.gaudin@pragmadev.com Un réel besoin Le logiciel double tous les deux ans. Le volume final rend extrêmement difficile de garantir le niveau

Plus en détail

Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation?

Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation? Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation? L I S EDF Electricité de France technicatome THOMSON-CSF Philippe

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

Plus en détail

Conception des systèmes répartis

Conception des systèmes répartis Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan

Plus en détail

Cible de sécurité CSPN. TRANGO Hypervisor. Sommaire. Tableau de révision. TRANGO Virtual Processors

Cible de sécurité CSPN. TRANGO Hypervisor. Sommaire. Tableau de révision. TRANGO Virtual Processors Cible de sécurité CSPN TRANGO Hypervisor TRANGO Virtual Processors Sommaire Tableau de révision...1 1 Identification du produit...2 2 Glossaire...2 3 Argumentaire (description) du produit...2 3.1 Description

Plus en détail

IBM Cognos TM1. Fiche Produit. Aperçu

IBM Cognos TM1. Fiche Produit. Aperçu Fiche Produit IBM Cognos TM1 Aperçu Cycles de planification raccourcis de 75 % et reporting ramené à quelques minutes au lieu de plusieurs jours Solution entièrement prise en charge et gérée par le département

Plus en détail

Ordonnancement de systèmes parallèles temps-réel

Ordonnancement de systèmes parallèles temps-réel Numéro d ordre : 4108 Université des Sciences et Technologies de Lille Thèse présentée pour obtenir le titre de docteur spécialité Informatique par Éric Piel Ordonnancement de systèmes parallèles temps-réel

Plus en détail

Thème 3 Conception et vérification d architectures de systèmes sur puce

Thème 3 Conception et vérification d architectures de systèmes sur puce Thème 3 Conception et vérification d architectures de systèmes sur puce Conception et simulation Frédéric Pétrot Vérification Laurence Pierre Conception et vérification d architectures de systèmes sur

Plus en détail

Utilisation de SystemC pour la conception des SoC

Utilisation de SystemC pour la conception des SoC Utilisation de SystemC pour la conception des SoC aniela ragomirescu 1,2, Roberto Reyna 3 1 - Université de Toulouse : INSA Toulouse, 135 Av. de Rangueil Toulouse cedex 4 2-LAAS-CNRS ; Université de Toulouse,

Plus en détail

Structure en couches des systèmes informatiques

Structure en couches des systèmes informatiques Structure en couches des systèmes informatiques Vue simplifiée d un système informatique Ce que le simple utilisateur perçoit «à première vue» d un système informatique : Le boîtier (tour, desktop ou portable)

Plus en détail

Catalogue des PFE 2013. CodinTek Park Technologique Elgazala 2088 Cité Technologique Elgazala Ariana

Catalogue des PFE 2013. CodinTek Park Technologique Elgazala 2088 Cité Technologique Elgazala Ariana Catalogue des PFE CodinTek Park Technologique Elgazala 2088 Cité Technologique Elgazala Ariana Présentation de la société CodinTek est une start-up Tunisienne spécialisée dans l innovation en traitement

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

La co-simulation logicielle/matérielle des systèmes MPSoC à des niveaux d abstraction élevés.

La co-simulation logicielle/matérielle des systèmes MPSoC à des niveaux d abstraction élevés. Chapter 1 État de l art 1.1 Introduction Comme ceci a été indiqué précédemment, la motivation principale de notre travail est la mise au point d outils permettant d un côté de réduire le temps de simulation

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

Spring IDE. Mise en œuvre. Eclipse

Spring IDE. Mise en œuvre. Eclipse A Spring IDE Bien que Spring mette à disposition d intéressants mécanismes afin d améliorer l architecture des applications Java EE en se fondant sur l injection de dépendances et la programmation orientée

Plus en détail

MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE

MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE m Notations : diagrammes m Diagrammes de transition d'états m Méthodes d'analyse de flot de m Conventions pour diagrammes données objet m Diagrammes de

Plus en détail

Supervision des réseaux et services pair à pair

Supervision des réseaux et services pair à pair Supervision des réseaux et services pair à pair Présentation des travaux de Thèse Guillaume Doyen LORIA - Université Henri Poincaré pour l obtention du Doctorat en Informatique de l université Henri Poincaré

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Chapitre 1 : Introduction aux Systèmes d Exploitation (SE)

Chapitre 1 : Introduction aux Systèmes d Exploitation (SE) 1. Introduction Chapitre 1 : Introduction aux Systèmes d Exploitation (SE). 1 système informatique est un ensemble constitué de matériels et de logiciels et qui assure le traitement des données.. Les pgms

Plus en détail

SoC : Système on Chip. C est le concept d intégrer une fonction électronique dans un composant programmable.

SoC : Système on Chip. C est le concept d intégrer une fonction électronique dans un composant programmable. 0 Présentation du TP : Pré-requis : Durée estimée : Objectif : Avoir suivi les TP_description_schématic_compteur-FPGA et TP_compteur_VHDL_virtual_instruments-FPGA. Connaissance du langage C ANSI. 2 heures.

Plus en détail

Supports d exécution matériels pour l embarqué. Jean-Philippe Babau

Supports d exécution matériels pour l embarqué. Jean-Philippe Babau Supports d exécution matériels pour l embarqué Jean-Philippe Babau Département Informatique, INSA Lyon Les contraintes Coût de quelques euros à quelques centaines d'euros Contraintes d énergie (mobilité,

Plus en détail

CTE Éditeur de classification arborescente pour spécifications du cas de test

CTE Éditeur de classification arborescente pour spécifications du cas de test Tessy Test d intégration et unitaire dynamique automatisé pour des applications embarquées CTE Éditeur de classification arborescente pour spécifications du cas de test Le meilleur outil de test unitaire

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Conception d Applications Réparties

Conception d Applications Réparties Jean-François Roos LIFL - équipe GOAL- bâtiment M3 Extension - bureau 206 -Jean-Francois.Roos@lifl.fr 1 Objectifs du Cours Appréhender la conception d applications réparties motivations et concepts architectures

Plus en détail

White Paper - Livre Blanc

White Paper - Livre Blanc White Paper - Livre Blanc Développement d applications de supervision des systèmes d information Avec LoriotPro Vous disposez d un environnement informatique hétérogène et vous souhaitez à partir d une

Plus en détail

PTSI PT ÉTUDE DES SYSTEMES

PTSI PT ÉTUDE DES SYSTEMES PTSI PT ÉTUDE DES SYSTEMES Table des matières 1 - PRESENTATION GENERALE... 1 1.1 - Définition d'un système... 1 1.2 - Exemples... 1 1.3 - Cycle de vie d'un système... 1 1.4 Langage de description SysML...

Plus en détail

Modèles et simulation des systèmes sur puce multiprocesseurs - Estimation des performances et de la consommation d énergie

Modèles et simulation des systèmes sur puce multiprocesseurs - Estimation des performances et de la consommation d énergie Université des sciences et technologies de lille THÈSE présentée et soutenue publiquement le Mars 2008 pour obtenir le titre de Docteur en informatique par Rabie Ben Atitallah Modèles et simulation des

Plus en détail

J O U R N E E S NEPTUNE

J O U R N E E S NEPTUNE J O U R N E E S NEPTUNE Les journées NEPTUNE ont eu lieu le 6 et 7 Juin 2012 à Télécom ParisTech. Cette conférence est un lieu de rencontre des acteurs du génie logiciel et de l ingénierie des systèmes.

Plus en détail

QUELQUES MOTS CLES ET DEFINITIONS.

QUELQUES MOTS CLES ET DEFINITIONS. CH. 2 QUELQUES MOTS CLES ET DEFINITIONS. ASIC : Application Spécific Integrated Circuit = HW circuit intégré pour application spécifique SOC : System On Chip = HW et SW Système sur puce IP : FPGA : CAD

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Conception de SoPC pour applications multimédia

Conception de SoPC pour applications multimédia Conception de SoPC pour applications multimédia Auteurs : Michael Guarisco, Nicolas Marques, Eric Dabellani, Yves Berviller, Hassan Rabah, Serge Weber Laboratoire d Instrumentation Electronique de Nancy.

Plus en détail

Industrialisation du logiciel Temps Réel Critique

Industrialisation du logiciel Temps Réel Critique Industrialisation du logiciel Temps Réel Critique Sommaire Projets opérationnels Les outils du marché utilisés et les contraintes associées CS et les méthodes CS et la R&D Conclusion RdV de l'innovation

Plus en détail

Table des Matières. Table des Figures 7. Introduction Générale 9. Chapitre 1 - Langages de description d architectures matérielles hybrides 23

Table des Matières. Table des Figures 7. Introduction Générale 9. Chapitre 1 - Langages de description d architectures matérielles hybrides 23 Table des Figures 7 Introduction Générale 9 1. Outils et plate-formes de construction d application 9 2. Intégration de paradigmes de conception dans le cycle de vie 10 2.1. Equilibrage de charge et équilibrage

Plus en détail

TaskMapper Gestion de projet : Analyse

TaskMapper Gestion de projet : Analyse Gestion de projet : Analyse P. Combier, V. Comiti, M. Hubert, R. Jamet, M. Le Du, P. Lelouette, J. L Hermitte, A. Morvan, N. Premillieu, L. Ren, C. Souti, F. Tesniere, Y. Zhao Encadrés par S. Derrien 11

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

Portage de l environnement de simulation d un composant FPGA développé pour l aéronautique (DO254 DAL-A) vers un banc de validation physique

Portage de l environnement de simulation d un composant FPGA développé pour l aéronautique (DO254 DAL-A) vers un banc de validation physique Portage de l environnement de simulation d un composant FPGA développé pour l aéronautique (DO254 DAL-A) vers un banc de validation physique L objectif Réaliser la vérification physique d'un composant

Plus en détail

Maîtriser les patterns experts : les patterns d application virtuelle

Maîtriser les patterns experts : les patterns d application virtuelle Maîtriser les patterns experts : les patterns d application virtuelle Comment les patterns d application virtuelle IBM PureSystems peuvent accélérer le déploiement, simplifier la gestion, réduire le risque

Plus en détail

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013 UML Mise en œuvre dans un projet 2013 Introduction Rôles et activités dans un projet Définir la méthode de votre projet Adapter la modélisation à la méthode de votre projet Conseils de mise en œuvre de

Plus en détail

M a c h i n e V i r t u e l l e R a d i o

M a c h i n e V i r t u e l l e R a d i o M a c h i n e V i r t u e l l e R a d i o Riadh Ben Abdallah riadh.ben-abdallah@inria.fr Laboratoire CITI, Équipe Systèmes Embarqués Séminaire des thésards, 20 Mars 2008 1 Le Contexte radio logicielle

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 38 NFP111 Systèmes et Applications Réparties Cours 11 - Les Enterprise Java Beans (Introduction aux Enterprise Claude Duvallet Université du Havre UFR Sciences

Plus en détail

X2BIRT : Mettez de l interactivité dans vos archives

X2BIRT : Mettez de l interactivité dans vos archives Présentation Produit Présentation Produit X2BIRT : Mettez de l interactivité dans vos archives L accès à l information est capital pour les affaires. X2BIRT, la dernière innovation d Actuate, prend le

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

Résultats des projets CARROLL. Bilan et perspectives. Ingénierie logicielle orientée modèle MDD

Résultats des projets CARROLL. Bilan et perspectives. Ingénierie logicielle orientée modèle MDD Résultats des projets CARROLL Bilan et perspectives Ingénierie logicielle orientée modèle MDD Serge Salicki, THALES Workshop CARROLL 23 septembre 2005 THALES et le MDE Le MDE est dans la strategie de THALES

Plus en détail

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES

Résumé CONCEPTEUR, INTEGRATEUR, OPERATEUR DE SYSTEMES CRITIQUES Aristote ----- Cloud Interopérabilité Retour d'expérience L A F O R C E D E L I N N O V A T I O N Résumé Les systèmes d'information logistique (SIL) sont des outils qui amènent des gains de productivité

Plus en détail

Introduction aux systèmes temps réel. Iulian Ober IRIT ober@iut-blagnac.fr

Introduction aux systèmes temps réel. Iulian Ober IRIT ober@iut-blagnac.fr Introduction aux systèmes temps réel Iulian Ober IRIT ober@iut-blagnac.fr Définition Systèmes dont la correction ne dépend pas seulement des valeurs des résultats produits mais également des délais dans

Plus en détail

Développement J2EE. avec Eclipse. et WSAD. Karim Djaafar. Olivier Salvatori. avec la contribution de. Groupe Eyrolles, 2003, ISBN 2-212-11285-8

Développement J2EE. avec Eclipse. et WSAD. Karim Djaafar. Olivier Salvatori. avec la contribution de. Groupe Eyrolles, 2003, ISBN 2-212-11285-8 Développement J2EE avec Eclipse et WSAD Karim Djaafar avec la contribution de Olivier Salvatori Groupe Eyrolles, 2003, ISBN 2-212-11285-8 Avant-propos Depuis la sortie de la plate-forme J2EE (Java 2 Entreprise

Plus en détail

G en om3: Building middleware-independent robotic components. Comparaison de middleware: YARP, MS Robotics Dev Studio, URBI, OpenRTM-aist, ROS

G en om3: Building middleware-independent robotic components. Comparaison de middleware: YARP, MS Robotics Dev Studio, URBI, OpenRTM-aist, ROS G en om3: Building middleware-independent robotic components Comparaison de middleware: YARP, MS Robotics Dev Studio, URBI, OpenRTM-aist, ROS Pablo Rauzy 15 février 2011 Table des matières 1 G en om3 :

Plus en détail

Stockage : capacité, performances

Stockage : capacité, performances Stockage : capacité, performances Intervenant :Thomas Robert C234-4 thomas.robert@telecom-paristech.fr Transparents : Thomas Robert Institut Mines-Télécom Lectures possibles Chapitre 7.2 de : http://ceit.aut.ac.ir/~amirkhani/

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Configuration et Déploiement d Applications Réparties par Intégration de l Hétérogénéité des Implémentations dans un Langage de Description d

Configuration et Déploiement d Applications Réparties par Intégration de l Hétérogénéité des Implémentations dans un Langage de Description d Configuration et Déploiement d Applications Réparties par Intégration de l Hétérogénéité des Implémentations dans un Langage de Description d Architecture Doctorant: Directeurs de thèse: Bechir ZALILA

Plus en détail

LTE dans les transports: Au service de nouveaux services

LTE dans les transports: Au service de nouveaux services LTE dans les transports: Au service de nouveaux services 1 LTE dans les transports: Au service de nouveaux services Dr. Cédric LÉVY-BENCHETON Expert Télécom, Egis Rail cedric.levy-bencheton@egis.fr Résumé

Plus en détail

Master Informatique Aix-Marseille Université

Master Informatique Aix-Marseille Université Aix-Marseille Université http://masterinfo.univ-mrs.fr/ Département Informatique et Interactions UFR Sciences Laboratoire d Informatique Fondamentale Laboratoire des Sciences de l Information et des Systèmes

Plus en détail

Plus efficace que jamais : le logiciel de test CEM R&S EMC 32 avec de nouvelles extensions

Plus efficace que jamais : le logiciel de test CEM R&S EMC 32 avec de nouvelles extensions Plus efficace que jamais : le logiciel de test CEM R&S EMC 32 avec de nouvelles extensions Le logiciel de test CEM R&S EMC 32 voit sa polyvalence considérablement renforcée grâce à de nouvelles options

Plus en détail

AVATAR. Un profil SysML temps réel outillé

AVATAR. Un profil SysML temps réel outillé AVATAR Un profil SysML temps réel outillé Ludovic Apvrille, Pierre de Saqui-Sannes ludovic.apvrille@telecom-paristech.fr pdss@isae.fr SysML France, 6 décembre 2010 Agenda De TURTLE à AVATAR Le langage

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Introduction au développement du logiciel

Introduction au développement du logiciel Introduction au développement du logiciel Vers le génie logiciel Université de Nantes Master Miage M1 Plan 1 Introduction 2 Génie logiciel 3 Projet informatique 4 Méthode de développement 5 Qualité Bibliographie

Plus en détail

Conception des Systèmes Numériques et Mixtes

Conception des Systèmes Numériques et Mixtes Conception des Systèmes Numériques et Mixtes Daniela Dragomirescu 1,2, Michael Kraemer 1,2, Marie-Line Boy 3, Philippe Bourdeau d Aguerre 3 1 - Université de Toulouse : INSA Toulouse, 135 Av. de Rangueil

Plus en détail

CA Server Automation. Vue d ensemble. Avantages. agility made possible

CA Server Automation. Vue d ensemble. Avantages. agility made possible FICHE PRODUIT : CA Server Automation CA Server Automation agility made possible La solution intégrée CA Server Automation permet d automatiser le provisioning, la correction et la configuration des composants

Plus en détail

ENTREPÔTS ET MAGASINS

ENTREPÔTS ET MAGASINS Michel Roux ENTREPÔTS ET MAGASINS Tout ce qu il faut savoir pour concevoir une unité de stockage Cinquième édition, 1995, 2001, 2003, 2008, 2011 ISBN : 978-2-212-55189-1 2 LES PHASES DE SIMULATION DE VALIDATION

Plus en détail

VERIFICATION DE SOC SOUS VELOCE

VERIFICATION DE SOC SOUS VELOCE VERIFICATION DE SOC SOUS VELOCE Fabrice Muller (1), Gilles Jacquemod (1), Rachid Bouchakour (2) Pôle CNFM PACA Polytech Nice-Sophia (1), Polytech Marseille (2) 1.1 Introduction La vérification des SoC

Plus en détail

GENERALITES SUR LES SYSTEMES D EXPLOITATION

GENERALITES SUR LES SYSTEMES D EXPLOITATION CHAPITRE 1 : GENERALITES SUR LES SYSTEMES D EXPLOITATION Objectifs spécifiques Connaître la définition d un système d exploitation Connaître le rôle d un système d exploitation Connaître les classes des

Plus en détail

RTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com

RTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com RTDS G3 Emmanuel Gaudin emmanuel.gaudin@pragmadev.com PragmaDev Dédiée au développement d un AGL pour le développement des applications temps réel et embarquées. Réseau de partenaires: Formations, Service,

Plus en détail

La programmation concurrente

La programmation concurrente La programmation concurrente Jean-Ferdy Susini Maître de Conférences - CNAM Département Informatique Sources : Android Developpers, Wikipedia Paris, 06/05/2015 Architecture matérielle 2 Considérons l architecture

Plus en détail

Guide pratique des solutions d automatisation des processus métier Avril 2014

Guide pratique des solutions d automatisation des processus métier Avril 2014 Guide pratique des solutions d automatisation des processus métier Avril 2014 Kemsley Design Limited Kemsley Design Limited www.kemsleydesign.com www.column2.com www.kemsleydesign.com www.column2.com Présentation

Plus en détail

Visual TOM 5.0 Fonctionnalités

Visual TOM 5.0 Fonctionnalités The job scheduling Company Visual TOM 5.0 Fonctionnalités 0 Interfaces existantes Xvision Mode multi-fenêtre Vision spécifique par écran Vision technique / hiérarchique Difficulté à faire évoluer 1 Interfaces

Plus en détail

1 Le vocabulaire de l informatique

1 Le vocabulaire de l informatique 1 Le vocabulaire de l informatique I Les systèmes informatiques Les ordinateurs sont omniprésents dans notre environnement quotidien. Conçus pour traiter de manière générale des informations, ils ne se

Plus en détail

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet CNAM UV 19357 Année 2003-2004 David Delahaye David.Delahaye@cnam.fr Conception et Développement Orientés Objets Cours 1 : Introduction 1 Présentation de la valeur Ce cours s adresse à toute personne ayant

Plus en détail

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA Denis Conan et Jean-Luc Raffy CSC 4002 Octobre 2015 CSC4002 : Introduction à la conception et à

Plus en détail

Cours en ligne Développement Java pour le web

Cours en ligne Développement Java pour le web Cours en ligne Développement Java pour le web We TrainFrance info@wetrainfrance Programme général du cours Développement Java pour le web Module 1 - Programmation J2ee A) Bases de programmation Java Unité

Plus en détail

Méthode de conception rapide d architecture massivement parallèle sur puce: de la modélisation à l expérimentation sur FPGA

Méthode de conception rapide d architecture massivement parallèle sur puce: de la modélisation à l expérimentation sur FPGA Méthode de conception rapide d architecture massivement parallèle sur puce: de la modélisation à l expérimentation sur FPGA Mouna Baklouti Kammoun 18 Décembre 2010 Mouna Baklouti Kammoun Soutenance de

Plus en détail

Modélisation des processus métiers et standardisation

Modélisation des processus métiers et standardisation Modélisation des processus métiers et standardisation Octobre 2004 Table des matières Introduction... 3 Processus métier : un même mot, plusieurs domaines d application... 4 Les critères pour un standard

Plus en détail