L’IDM pour la conception des systèmes embarqués

5.1.3 Profil MARTE . . . 110

5.2 Proposition d’une méthode d’utilisation de MARTE pour mppSoC . . . . 112

5.2.1 Intégration dans Gaspard . . . 113 5.2.2 Modélisation de mppSoC . . . 115

5.3 Chaîne pour la génération du code VHDL synthétisable . . . 124

5.3.1 Organisation de mppSoCLib . . . 125 5.3.2 Transformation depuis un modèle Deployed vers du code VHDL . . 126

5.4 Expérimentation sur FPGA : traitement vidéo temps réel . . . 127

5.4.1 Plateforme de prototypage . . . 128 5.4.2 Chaîne de traitement vidéo à base de mppSoC . . . 128 5.4.3 Application de conversion de couleur . . . 133 5.4.4 Application de convolution . . . 137

5.5 Comparaison de mppSoC avec d’autres systèmes . . . 140 5.6 Conclusion . . . 143

5.1 Introduction à l’IDM et automatisation de la génération de code 107

Les flots de développements et les outils de conception de SoC n’ont pas été aussi prompts à suivre les grandes évolutions matérielles ainsi que logicielles. Il en résulte au-jourd’hui un gap de productivité accentué par les lois économiques. En effet, les méthodes et outils de conception et de vérification couramment utilisés ne sont pas adaptés à gérer la complexité croissante des systèmes et de leur support physique. Une récente étude de l’ITRS [51] illustrée dans la figure 5.1 montrait que la demande du logiciel double chaque dix mois. Le même rapport mentionnait que les capacités d’intégration des SoC double chaque 36 mois et la productivité du logiciel double aussi chaque cinq ans. D’où le fossé entre capacité d’intégration théorique et pratique ne cesse de se creuser. Pour réduire les temps et les coûts de développement, deux aspects orthogonaux se révèlent indispensables : la montée dans les niveaux d’abstraction pour la spécification du système et la réutilisation des blocs pré-définis communément appelés IPs. Alors que le premier aspect encourage à s’abstraire des détails d’implémentation, le second aspect encourage à capitaliser des développements qui ont aboutit à la validation d’un bloc.

Afin d’accélérer la conception de SoC, des approches de spécification orientées modèles sont alors apparues. La modélisation permet d’abstraire les aspects les plus importants pour les communiquer, les analyser et les valider avant toute implémentation. L’Ingénierie Dirigée par les Modèles (IDM) se situe dans ce cadre. Dans ce chapitre, nous allons montrer comment une approche dirigée par les modèles peut faciliter le développement du système mppSoC. Une démonstration de génération de code VHDL automatique à partir de la modélisation de l’architecture parallèle à un très haut niveau d’abstraction montrera tout le potentiel en matière de développement de ce type de systèmes embarqués et l’intégration dans un FPGA pour une évaluation réelle.

Ce chapitre présentera les grandes lignes de notre flot de conception de mppSoC. En premier lieu, nous brosserons un aperçu des standards OMG qui ont contribué à la réalisa-tion de notre flot de concepréalisa-tion. À ce titre, nous nous attarderons sur les différents concepts de l’ingénierie dirigée par les modèles ainsi que le profil MARTE. Après avoir brièvement présenté l’environnement GASPARD, nous ferons un petit tour d’horizon des métamodèles que cet environnement utilise pour la génération automatique du code. Une description bien détaillée de la modélisation de mppSoC sera ensuite donnée. Le dernier maillon de notre tra-vail est la génération du code. Une illustration des étapes suivies afin d’aboutir à ce code sera alors mentionnée. La section d’après présentera les résultats expérimentaux de l’utilisation de mppSoC pour la définition d’une chaîne de traitement vidéo. Dans la dernière section, nous discuterons les performances de mppSoC en comparaison avec d’autres systèmes.

5.1 Introduction à l’IDM et automatisation de la génération de

code

Toute personne ayant déjà tenté de lire et de comprendre du code afin de le réutiliser ou de le modifier pour répondre à ses besoins, sait à quel point cette tâche est longue et difficile quelque soit le langage de programmation et malgré les indispensables lignes de commentaires. La solution est donc de combler cette rupture sémantique par des abstrac-tions qui nous permettront de spécifier notre programme dans un langage métier proche du domaine en question (DSL : Domain Specific Language). De plus, la spécification du système à un tel niveau d’abstraction permet d’abstraire les détails et techniques d’implémentation. Pour répondre efficacement au défi de conception posé par mppSoC, un important

ingré-FIGURE5.1 – Gap entre la conception du matériel et du logiciel [51]

dient doit être pris en compte : les moyens de conception à un haut niveau d’abstraction. Ces moyens permettraient d’aborder les systèmes tout en s’affranchissant, des détails qui font leur complexité. En revanche, ils doivent impérativement être accompagnés de proces-sus de raffinement. L’ingénierie dirigée par les modèles vient répondre à ce besoin d’abstrac-tion en plaçant les modèles au centre de développement logiciel. L’IDM permet de répondre à la complexité croissante des systèmes, en améliorant l’expressivité, la portabilité, la lisi-bilité et la communication des intentions entre flots de conception. Elle autorise également la séparation de préoccupations et la réutilisation. Forte de ces avantages, l’IDM recherche l’efficacité dans le processus de développement et se traduit par des gains en temps appré-ciables. L’IDM utilise en général le formalisme de spécification UML pour la description des modèles. Bien que l’IDM repose sur des concepts fondateurs (abstraction, modélisation, méta-modélisation, etc.) posés depuis longtemps, il s’agit avant tout d’un paradigme ras-semblant de nombreux principes et pratiques existants autour de la notion centrale de mo-dèle et cherchant à généraliser la proposition MDA [77] de l’OMG. MDA est une variante particulière de l’IDM. Le principe de base du MDA est l’élaboration de différents modèles, en partant d’un modèle métier indépendant de l’informatisation (CIM : Computation Inde-pendent Model), la transformation de celui-ci en modèle indépendant de la plate-forme (PIM : Platform Independent Model) et enfin la transformation de ce dernier en modèle spécifique à la plate-forme cible (PSM : Platform Specific Model) pour l’implémentation concrète du système. Les techniques employées sont donc principalement des techniques de modélisation et des techniques de transformation de modèles.

Dans le paragraphe suivant, nous exposerons les concepts fondamentaux de l’IDM.

5.1.1 L’IDM pour la conception des systèmes embarqués

De façon générale, l’IDM peut être définie autour de trois concepts de base : les modèles, les méta-modèles et les transformations.

Modèle : un modèle est une abstraction d’un système, modélisé sous la forme d’un en-semble de faits construits dans une intention particulière. Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système modélisé.

Métamodèle : un métamodèle est un modèle qui définit le langage d’expression d’un mo-dèle, ç.à.d. le langage de modélisation. Un modèle représente une vue abstraite de la réalité et est conforme à un métamodèle qui définit précisément les concepts présents

5.1 Introduction à l’IDM et automatisation de la génération de code 109

FIGURE5.2 – Principe de transformation de modèle à ce niveau d’abstraction ainsi que les relations entre ces concepts.

Transformation de modèles : présente un autre point clé de l’IDM. Elle permet de passer d’un modèle source décrit à un certain niveau d’abstraction à un modèle destination décrit éventuellement à un autre niveau d’abstraction. Ces modèles source et destina-tion sont conformes à leur métamodèle respectif (métamodèle source et destinadestina-tion) et le passage de l’un à l’autre (i.e. la transformation) est décrit par des règles de transfor-mation. Ces règles sont exécutées sur les modèles source afin de générer les modèles destination, comme illustré à la figure 5.2.

Dans notre travail, nous avons utilisé le langage de modélisation UML qui sera décrit dans la sous section suivante.