Les étapes du co-design

Les étapes mises en jeu dans le co-design sont différentes des étapes que l’on rencontre dans les méthodes de conception traditionnelles. Le graphique de synthèse établi par [Koudil, 2002] montre l’en-chaînement de celles-ci (voir figure 4.3).

Il est important de mettre en évidence la comparaison du processus de co-design (figure 4.3)) et du processus de conception traditionnel (figure 4.2). Dans le cycle de vie traditionnel on a, dès le cahier des charges effectué, procédé au partitionnement en établissant deux cahiers des charges distincts. C’est

7. Les anglophones utilisent indifféremment les notations Hw/Sw design ou Hw/Sw co-design ou co-design

8. On appelle espace de conception l’ensemble des solutions logicielles, matérielles ainsi que tous les compromis pour accomplir la tâche incombant au système

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

FIG. 4.3 – Approche co-design "type" pour le développement d’un système mixte

à ce niveau qu’a été faite une grande partie des choix matériels et logiciels. L’essentiel du travail de conception et de développement peut alors être fait (conception logicielle et matérielle en parallèle).

Avec une méthode de co-design, à partir du cahier des charges on va décrire le fonctionnement du système sans discriminer le logiciel et le matériel. Le partitionnement peut se faire de manière automa-tique pour optimiser certains critères: plusieurs configurations logicielles/matérielles peuvent être testées, ce qui ne serait pas si simple avec un cycle traditionnel (cela impliquerait le développement de plusieurs solutions en parallèle). De plus, un changement de spécification ne remettra pas autant de travail en cause que dans le cas d’un développement traditionnel pour lesquels, au fur et à mesure de la conception, des contraintes sont définitivement adoptées. Il en est de même pour l’ajout de fonctionnalités.

Voici une description succincte de ces différentes étapes :

Etape de co-spécification Tout comme dans les méthodes traditionnelles de conception, la première étape de la méthode consiste à s’intéresser aux besoins des utilisateurs et donc à leur spécification. Dans le contexte des systèmes mixtes, il faut nous attacher à utiliser un langage assez puissant pour spécifier le logiciel, le matériel ainsi que toutes les contraintes⁹ imposées aux systèmes.

Trois différents points de vue se confrontent alors :

– Celui qui consiste à utiliser un formalisme existant (et un seul) pour spécifier l’intégralité du sys-tème mixte. Dans ce cas, ce sont les langages de description matérielle qui sont le plus souvent utilisés entre autres parce que de nombreux outils de synthèse logique et de haut niveau existent [Olukotun et al., 1994].

– Celui qui consiste à créer de nouveaux formalismes dédiés à la co-spécification comme Promela [Tripakis and Courcoubetis, 1996], Ruby [Jones and Sheeran, 1990] etc.

– Celui qui consiste à faire collaborer différents formalismes issus du logiciel classique (Fortran,C) éventuellement spécialisé (Hardware C [Ku and De Micheli, 1990], Cx [Ernst et al., 1993], ...),

Le co-design 59

des langages de description des systèmes distribués (SDL (Specification and Description

Lan-gage [Turner, 1992]), Estelle [Turner, 1992], Lotos [ISO/IEC, 1988], CCS (Calculus of Commu-nicating Systems [Milner, 1985]), CSP (CommuCommu-nicating Sequential Process [Hoare, 2004]) ...,

des langages synchrones (Esterel [Berry and Gonthier, 1992], Lustre [Caspi et al., 1987], Lucid

[Ashcroft and Wadge, 1977]) et parallèles (OCCAM [Pountain, 1987]) voire, depuis peu, des

ap-proches orientées objet (C++, Java).

Le VHDL¹⁰ [Aumiaux, 2000] et Verilog [E. Sternheim, 1993] sont les langages de description de matériel les plus populaires et sont donc devenus, de ce fait, les outils de spécification de système mixtes les plus répandus.

Etape de modélisation De très nombreux formalismes sont utilisés pour la modélisation des systèmes mixtes (FSM (Finite State Machine), DFD (Data Flow Diagrams), RDP (Réseaux de Petri) ...). Le for-malisme qui apparaît comme étant le plus utilisé pour la modélisation des systèmes matériels sont les machines à états finis. Ces dernières étant aussi très utilisés en logiciel, la modélisation des systèmes mixtes repose souvent sur elles. Le co-design utilise donc très majoritairement les machines à états finis.

Etape de partitionnement logiciel/matériel Le rôle de cette étape est la création d’une architecture composée d’une partie matérielle et d’une partie logicielle à partir des spécifications de la partie système relevant de l’activité du co-design. Les paramètres de cette transformation sont par exemple:

– Les contraintes statiques qui sont le coût financier, la consommation énergétique, la surface de silicium maximale, la taille du code et de la mémoire,

– Les contraintes dynamiques qui sont essentiellement les contraintes temporelles,

– La sûreté de fonctionnement qui peut par exemple entraîner une redondance de composants maté-riels et/ou logiciel voire l’utilisation de mécanisme proche des techniques de réplication utilisées en logiciel,

– La testabilité qui va ajouter des composants matériel supplémentaire ou l’ajout d’instructions, – La réutilisation.

Cette étape peut être manuelle, lorsque le partitionnement est réalisé par l’utilisateur, interactif lors-qu’il est assisté par des outils, automatique lorsque lors-qu’il est traité intégralement par des outils. Généra-lement ces derniers utilisent des approches heuristiques. Il est à noter que s’agissant d’un problème NP complet, le nombre de critères doit être limité lors de recherches automatiques.

Etape de co-synthèse Cette étape permet la co-synthèse de la communication entre les différentes par-ties indépendantes du système partitionné. Les sous-systèmes mis en jeu ont des besoins en communi-cation : il est nécessaire de permettre celle-ci. Les principales approches de synthèse d’interface utilisent des protocoles de communication, des systèmes d’exploitation, des primitives ou des bibliothèques de communication.

Etape de co-vérification La co-vérification utilise la co-simulation qui permet une simulation simulta-née des parties logicielles et des parties matérielles sans en oublier leurs interactions. Cette co-simulation permet d’analyser les propriétés dynamiques du système. Elle permet de co-vérifier le système c’est-à-dire de garantir :

– Les performances et fonctionnalités du système à concevoir sont conformes aux co-spécifications.

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

– Que des déviations du fonctionnement (contraintes temporelles, contraintes ergonomiques etc.) n’aient pas été introduites par les différentes étapes du processus de co-design.

Par ailleurs, il est possible de procéder à de la co-validation. Elle se fait à l’aide d’outils formels. Elle seule permet de vérifier que le système réalisé respecte toutes les contraintes fixées : elle est cependant très difficile à mettre en oeuvre.