Cette étape constitue à la fois la phase terminale de conception et la phase de réalisation.
D.1 Partitionnement ! D.2 Co-simulation ! D.3 Co-validation ! D.4 Réalisation ! D.5 Test
98 La démarche de la méthode DIAMOND
5.5.1 Le partitionnement (D.1)
La principale utilisation du co-design figure dans le partitionnement logiciel/matériel qui sera fait des différents composants se rapportant aux différents axes de la décomposition AEIO.
Il devra être fait manuellement (dans notre cas) en accord avec les spécifications technologiques. Il inclura, à terme, la co-simulation pour la co-synthèse. Cette étape produit les spécifications du logiciel et du matériel. D.1.1 Déterminer si la question du partitionnement se pose ! D.1.2 Hiérarchiser les critères ! D.1.3 Déterminer le choix du partitionnement ! D.1.4 Définir les interfaces logicielles/matérielles
Il nous est indispensable de nous interroger sur les critères qui vont orienter nos décisions vers leur implémentation logicielle ou matérielle. Nous pensons qu’il y a deux niveaux à prendre en compte : tout d’abord on va commencer par écarter les composants pour lesquelles la question du partitionnement ne se pose pas (D.1.1). Pour chacun des composants pour lesquels se pose la question du partitionnement, on va hiérarchiser les critères que l’on souhaite satisfaire (D.1.2). On en déduira le choix du partitionne-ment (D.1.3) et on s’interrogera quant aux interfaces logicielle/matérielle à implépartitionne-menter4(D.1.4).
Déterminer si la question du partitionnement se pose (D.1.1). Dans ce premier niveau de sélection
du partitionnement on va déterminer les parties de l’agent pour lesquelles la question du partitionnement ne se pose pas. En effet certains éléments, par essence même, devront être matériels. Comme on peut le voir sur la figure 5.17, c’est le cas des périphériques d’entrées/sorties comme par exemple les capteurs et les actionneurs.
Hiérarchiser les critères (D.1.2). Ce second niveau de sélection du partitionnement concerne les
éléments pour lesquels il y a réellement plusieurs choix d’implémentation (fig. 5.17, zones partagées par le co-design et le logiciel ou le matériel). Pour ceux-là différents paramètres vont entrer en jeu : les critères de partitionnement peuvent être plus ou moins subjectifs. Nous présentons dans le tableau 5.4 ceux que nous avons jugés pertinents pour les agents à partir de différents travaux effectués dans le co-design [De Micheli, 1995, Ismail, 1996, Berrebi, 1997, Koudil, 2002, Kumar, 2002] et de notre propre expérience.
Déterminer le choix du partitionnement (D.1.3). Le tableau 5.4 définit plusieurs critères et indique
la partitionnement qui sera incité. Il est possible d’avoir des indications contradictoires : c’est la raison pour laquelle les critères ont été hiérarchisés. C’est le concepteur qui devra déterminer la pertinence d’une ou l’autre solution. Un autre critère non mentionné précédemment est à prendre en compte : ce qui a déjà été réalisé par l’entreprise. En effet, certains composants ont éventuellement pu être construits d’un point de vue purement matériel ou purement logiciel. Le concepteur pourra donc être incité à choisir cette solution. Un autre critère qui n’entre pas dans le niveau précédent provient de la nécessité de créer des interfaces entre le logiciel et le matériel. Selon ce que propose l’outil, il peut être compliqué d’interfacer
L’étape d’implantation (étape D) 99
FIG. 5.17 – Aperçu du partitionnement prévu pour les axes de la méthode AEIO
logiciel et matériel. Ainsi, on évitera d’avoir une succession de composants logiciels, puis matériels, puis logiciels etc.
Définir les interfaces logicielles/matérielles (D.1.4). Lorsque l’on fait collaborer du logiciel et du
matériel il est nécessaire de définir des interfaces. Généralement on établit une norme pour tout compo-sant et on fournit un bus.
Documentation liée à ce processus D.1 . Une partie partitionnement est créée. Elle regroupe une
fiche de critère de partitionnement qui indique la hiérarchisation des critères. De plus une fiche de par-titionnement précise pour chaque composant la déclinaison choisie. Il peut exister plusieurs
implémen-tations différentes logicielles ou matérielles d’un même composant : la référence de l’implémentation choisie est précisée et ce choix doit être motivé. Si des contraintes influant sur le partitionnement sont spécifiées dans les fiches de contraintes techniques et technologiques, elles ne devront pas être violées.
5.5.2 Les activités de co-simulation (D.2) et de co-validation (D.3)
Ces deux activités sont centrés sur les agents et non sur le système.
La co-simulation est une simulation simultanée des parties logicielles et des parties matérielles sans
oublier leurs interactions. Elle permet d’analyse les propriétés dynamiques du système comme les temps d’exécution. Elle permet de co-vérifier le système c’est-à-dire de garantir que :
100 La démarche de la méthode DIAMOND
TAB. 5.4 – Les critères intervenants dans le choix du partitionnement Critère Description
Coût Critère omniprésent pendant tout le processus de conception du système. Sur de très petites séries c’est le coût du développement du système logiciel et du matériel que l’on va chercher à diminuer autant que possible tandis que dans le cas de grandes séries, c’est la diminution des coûts de fabrication qui revêtira une grande importance.
Performance Son importance varie selon les problèmes traités. Les applications temps-réel et pour lesquelles la robustesse est fonction du temps d’occupation processeur sont celles pour lesquelles ce critère est capital. C’est alors un partitionnement maté-riel qui sera à privilégier autant que possible.
Flexibilité Ce critère qui joue en faveur du logiciel. En effet, les effets de bords liés aux modifications du logiciel ont généralement un impact moins important sur le sys-tème global que dans le cas du matériel. Cependant, la flexibilité des EPLD et autre FPGA s’améliore grandement et ils sont même re-programmables in-situ, c’est-à-dire que l’on peut modifier leur programme sans les extraire de la carte électronique sur laquelle ils sont fixés.
Tolérance aux pannes internes
De part leur nature les systèmes logiciels sont moins tolérants aux pannes. En effet, les microcontrôleurs, sur lesquels ils reposent, utilisent des mémoires, des structures de piles sujettes au débordement etc. Ce critère qui jouera en faveur d’un partitionnement matériel.
Ergonomie Il regroupe toutes les caractéristiques physiques du système (le poids, le volume, la consommation énergétique, le dégagement thermique etc.). Selon l’application ce critère peut être hautement critique (cas des applications relevant des métiers de l’aéronautique). C’est au concepteur d’apprécier correctement ce critère. Complexité
algorith-mique
Plus une tâche est complexe, plus il y aura de chance pour que l’on s’oriente vers un partitionnement logiciel. La synthèse matérielle des tâches hautement cognitives par exemple est beaucoup trop compliquée.
– Que des déviations du fonctionnement n’aient pas été introduits par les différentes étapes du pro-cessus de co-design.
La co-validation 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.
Documentation liée aux processus D.2 et D.3 . Dans cette partie de la documentation doivent figurés
les protocoles mis en jeu et les résultats commentés des différentes simulations et validations (fiches de
co-simulation et fiches de co-validation).
5.5.3 La réalisation (D.4)
Elle sera réalisée à terme grâce à un outil associé en cours de développement. Chaque composant est spécifié grâce à une notation graphique commune pour la partie matérielle et la partie logicielle. Pour chacun de ces composants le concepteur choisit s’il désire une implémentation matérielle ou logicielle.
L’étape d’implantation (étape D) 101
L’outil pourra prendre en charge la génération automatique du code pour les composants dont il a été choisi une implémentation logicielle. Le code sera écrit dans un langage portable comme le langage Java ou le langage C (facilement embarquable). Pour ce qui est des composants matériels une spécification en VHDL5sera générée. Après cela, la compilation des différents codes et la synthèse matérielle des différentes spécifications en VHDL seront réalisées comme l’illustre la figure 5.18. Cette figure met en évidence le traitement d’un composant matériel et d’un composant logiciel.
FIG. 5.18 – Synthèse logicielle et matérielle des composants
Le composant matériel est décrit avec un langage de haut niveau prévu à cet effet (ici le VHDL). On y voit sa description externe (Component entity) et le début de sa description interne (Component ar-chitecture). Par "synthèse logique", nous entendons synthèse comportementale qui traduit la description matérielle en une construction fonctionnelle du circuit (logique combinatoire, machine d’états, registres etc.) suivie de la synthèse RTL qui prend en compte le déroulement temporel des traitements. La synthèse "layout" permet la création de masques. Le résultat de ces traitements est un composant matériel.
102 La démarche de la méthode DIAMOND
Le composant logiciel voit son fonctionnement codé via un langage de haut niveau (ici le langage C). La compilation permet la traduction du programme en instructions machines. Ces instructions primi-tives dépendent généralement du processeur cible. L’édition de liens permet d’ajouter des bibliothèques d’exécution, contenant principalement la gestion mémoire, et de faire la jonction avec le système d’ex-ploitation pour les primitives. Le résultat de ces traitements est un code binaire qui sera placé en mémoire et exécuté par un processeur.
Documentation liée à ce processus D.4 . La documentation consiste en :
– fiches de code sources qui est une copie textuelle des codes générés,
– fiches de description architecturale matérielle qui rend compte des spécifications matérielles gé-nérées,
– fiches de co-synthèse qui rend compte des interfaces entre les différentes parties logicielles, les différentes parties matérielles et les parties logicielles/matérielles.
5.5.4 Le test (D.5)
Ce processus est centré sur le système et non sur les agents. Dans ce processus on va s’intéresser à tester le produit finalisé logiciel/matériel. On va s’attacher à vérifier la conformité entre la spécification initiale et le produit réalisé. On portera une attention particulière aux critères soulevés dans l’activité de hiérarchisation des critère.
Documentation liée à ce processus D.5 . Une Fiche de conformité est saisie. Elle servira de support
aux personnes chargées de mesurer la satisfaction du demandeur.