Revue des environnements co-design

Il existe de nombreux environnements de co-design [Ismail, 1996, Berrebi, 1997, Valderrama, 1998, Zurawski, 2005] dont un aperçu non exhaustif est présenté dans le tableau 4.1. Pour chacune des mé-thodes, le tableau présente l’outil de spécification, le type d’application visé ainsi que les cibles poten-tielles pour la réalisation.

TAB. 4.1 – Apercu des différents environnements de co-design

Outils Spécification Type d’application Architecture cible

Castel

[Theißinger et al., 1994]

C Traitement du signal ASIP

Codes

[Buchenrieder et al., 1993]

SDL, StateCharts Système de communication Multiprocesseurs, FPGA ,ASIC

Cosmos[Ismail, 1996] SDL Système de contrôle, com-munication etc.

Multi-processeurs,ASIC, FPGA

Cosyma

[Ernst et al., 1993]

Cx Systèmes complexes CPU, ASIC

CoWare

[De Man et al., 1995]

POPE Traitement du signal Multi-processeurs, ASIC

Lyos[Grode et al., 1998] C CPU + ASIC

MCSE

[Calvez et al., 1997]

Formalisme personnel Système de contrôle et de communication

Monoprocesseur, DSP, ASIP

Ptol emy[Eker et al., 2003] Blocs interconnecté multi-langage

Traitement du signal et sys-tèmes de communications

Mono-processeur

Rapid

[Rethman and Wilsey, 1993]

VHDL Système de communication

et de contrôle

Au moins un processeur (pour le logiciel)

RASSP

[Sedmak and Evans, 1995]

VHDL Traitement du signal CPU + DSP

SAW[Thomas et al., 1988] CSP Optimisation de fonctions

logicielles

CPU + (FPGA,ASIC)

SpeSyn

[Gajski et al., 1998]

SpecCharts Système de contrôle et de communication

Mono-processeurs et ASIC

SynDex [Sorel, 1994, Niang et al., 2004]

SIGNAL Traitement du signal Multi-processeurs

Tosa[Allara et al., 2000] SpeedChart Systèmes de communication Mono-processeur avec co-processeur

Vul an

[Gupta and De Micheli, 1993]

HardwareC Système temps réel CPU, ASIC

Formalismes de spécification. Un des intérêts de cette revue est de permettre l’identification de for-malismes de spécification. On remarque que les outils démarrent avec des modèles de spécification de bas niveau par rapport au niveau système afin de réduire la distance entre le modèle de spécification et le prototype.

Certaines approches ont étendu des langages pour supporter des concepts matériels et la communi-cation comme Cosyma (Cx est une extension du langage C qui intègre des contraintes temporelles et le

Le co-design 61

parallélisme) et Vulcan (HardwareC est une extension au langage C pour intégrer le parallélisme et des aspects pour la description matérielle). Lycos et Castle utilisent le langage C.

Certains travaux sur le codesign utilisent des langages de spécification issus des langages de spécifi-cation de systèmes distribués tels que SDL (traduction de modèle SDL en VHDL [Glunz et al., 1993]), LOTOS (processus LOTOS traduit en automate à états finis VHDL [Carreras et al., 1995]) ou ESTELLE (traduction de ESTELLE en VHDL [Wytrebwicz and Budkowski, 1995]).

StateCharts [Harel, 1987] est un langage synchrone ayant un formalisme visuel et permettant de décrire des machines à états finis ainsi que leur contrôle dans le temps.

Parmi les formalismes propriétaire, on compte SpecCharts [Narayan et al., 1992] qui est un langage de spécification au niveau système semblable à StateCharts avec des instructions issues du VHDL (des-cription comportementale). Speedchart [Belhadj, 1994] est un langage de des(des-cription graphique et textuel qui utilise le formalisme StateCharts. POPE [De Man et al., 1995] est un formalisme qui sépare stricte-ment le comportestricte-ment fonctionnel et la communication. Le modèle repose sur des processus qui décrit le comportement des ports qui permet aux composants de communiquer, les protocoles qui définissent la sémantique de la communication et des canaux qui permettent de connecter des ports. Ptolemy est un des premiers framework à utiliser des blocs interconnectés [Buck et al., 1994] pour décrire le fonc-tionnement d’une application. Ces blocs permettaient de cacher des objets écrits en C++, ce qui était à l’époque très novateur.

Type d’applications. Comme on peut le voir dans le tableau 4.1, les différents outils de co-design ne visent généralement qu’un champ d’application (système de contrôle, système de traitement, système de communication etc.). Deux paramètres en sont à l’origine. Tout d’abord, ces outils sont généralement associés à des méthodes, et les méthodes sont créées par des équipes qui travaillent sur des applications spécifiques. Ce sont donc les applications qui ont dirigé les méthodes. Le deuxième point est que les mé-thodes demandent souvent beaucoup de bibliothèques (de composants, de fonctions). Ces bibliothèques, lourdes à développer, sont créées pour ces mêmes types d’application initialement visées.

Architectures cibles. Un processeur (noté CPU) exécute, à chaque top d’horloge, une action corres-pondant à une instruction ou une partie d’instruction. Ces instructions sont des opérations élémentaires que le processeur peut accomplir. Ces instructions, stockées dans une mémoire réservée au code (géné-ralement de type ROM), nécessitent de pouvoir manipuler des données stockées temporairement dans une mémoire (généralement de type RAM). Ces processeurs peuvent avoir plusieurs architectures dont les plus connues sont les architectures CISC (Complex Instruction Set Computer) dans lesquels des ins-tructions complexes (difficilement faisables avec les insins-tructions de bases) sont câblées en dur dans le processeur et RISC (Reduced Instruction Set Computer) optimisé pour des cycles d’horloge courts mais qui ne tolèrent qu’un jeu d’instruction réduit.

Les ASIP (Application Specific Instruction Set Processor) sont des processeurs programmables spé-cifiques qui sont développés pour des applications données (optimisation de leurs architectures internes, de leurs jeux d’instructions).

Les ASIC (Application Specific Integrated Circuit) sont des circuits spécifiques qui sont construits pour des applications spécifiques. Ces composants sont généralement utilisés pour accélérer certaines des tâches que doit faire un système à processeur (ils peuvent cependant être utilisé d’une manière autonome). Les DSP (Digital Signal Processor) sont des processeurs de signal numérique et sont optimisés pour les calculs type traitement de signal. En terme de structure, un DSP est un processeur, ou calculateur, dont l’architecture est optimisée pour effectuer des calculs complexes en un coup d’horloge, mais aussi pour accéder très facilement à un grand nombre d’entrées-sorties.

62 Conception de systèmes mixtes logiciel/matériel

Les FPGA (Field Programmable Gate Array) sont des circuits intégrés qui peuvent être reprogram-més. Ils sont plus lents que les ASIC et consomment plus d’énergie. Leur temps de développement est cependant plus court et leurs coût inférieur pour de petites séries. Il est souvent possible de transformer un FPGA en une version ASIC plus rapide et consommant moins.

Les PAL (Programmable Array Logic), les PLD (Programmable Logic Device), les EPLD (Erasable Programmable Logic Device) et les EEPLD (Electrically Erasable Programmable Logic Device) sont des réseaux logiques programmables. Leur programmation consiste à établir des connexions en imposant un courant supérieur aux courants de fonctionnement normaux (claquage de fusibles ou de jonctions). Les circuits logiques programmables incluent un grand nombre de solutions, toutes basées sur des variantes de l’architecture des portes ET, OU et l’utilisation de bascules pour la mémorisation.

4.3 Conclusion

Les objectifs de ce chapitre étaient de définir le vocabulaire que nous utiliserons dans la méthode, de définir que ce que l’on entend par système embarqué et de présenter le co-design.

Lorsqu’on s’intéresse à la production de systèmes mixtes logiciel/matériel, il semble important d’uni-fier en un même cycle de vie le développement des deux parties. L’objectif est d’éviter les écueils habi-tuels de leur conception et de profiter des avantages d’une telle harmonisation des cycles de vie des deux parties (vu en 4.2.2).

L’inconvénient des méthodes traditionnelles de co-design est leur trop grande spécialisation : une méthode est faite pour un type de problème (codec, module de transmission, module de traitement de si-gnal etc.) et qu’elles sont axés sur l’implémentation. Pour notre type de problème il faut que la démarche co-design commence dès l’analyse: le co-design ne doit pas se limiter à la construction de l’agent.

Il y a de nombreux formalismes : le choix d’un formalisme de spécification dépend généralement du critère que l’on souhaite privilégier. Les formalismes les plus faciles à prendre en main reposent sur des notations graphiques. Cependant, la diversité des problèmes que l’on doit pouvoir envisager tend à penser qu’il ne faut pas autoriser la collaboration de plusieurs formalismes.

Une méthode peut ne pas imposer un formalisme particulier mais se comporter comme un guide. Cependant, au niveau de l’outil, le choix d’un formalisme est important.

L’idée de blocs interconnectés (Ptolemy) est très séduisante pour décrire le fonctionnement d’une entité d’un système. L’inconvénient est que seule la richesse des bibliothèques disponibles rend une telle approche réellement consistante. D’autre part, les machines à états finis sont un outil efficace pour mo-déliser un fonctionnement et permettre sa traduction en code logiciel ou en une description de matériel.

63

Chapitre 5

La démarche de la méthode DIAMOND

Ce n’est pas assez de faire des pas qui doivent un jour conduire au but, chaque pas doit être lui-même un but en même temps qu’il nous porte en avant.

Johann Wolfgang von Goethe

Ce chapitre expose notre méthode pour la réalisation de systèmes complexes physiques ouverts. Dans un avant-propos, nous présentons les rôles des différents intervenants de la méthode et nous présentons rapidement les normes documentaires que nous adoptons. Le cycle de vie en spirale est présenté puis le détail des processus et des activités est effectué. En fin de chapitre, une discussion de notre méthode en comparaison avec d’autres est proposée. Une synthèse des activités de la méthode figure en annexe C.