M.C.S.E 13
2
Méthodologie de co-design et
estimation des performances
Dans le chapitre précédent nous avons présenté le problème du co-design comme celui du
développement d’une méthodologie de conception et des outils supports. Nous avons montré
qu’une approche système est nécessaire pour déterminer les parties du système relevant de
l’activité de co-design. Le développement de ces parties se distingue des approches système
par la nécessité d’une interaction forte entre les développements de la partie logicielle et de la
partie matérielle.
Lorsque les parties du système relevant de l’activité de co-design ont été clairement
identifiées et spécifiées, le concepteur doit effectuer la sélection d’une architecture matérielle
et l’allocation des constituants fonctionnels sur les unités matérielles de l’architecture choisie.
L’espace des solutions possibles apparaît très vaste. Les choix du concepteur doivent satisfaire
à un nombre important de critères (performances, flexibilité, testabilité, reutilisabilité, sécurité,
etc). Il s’agit de la problématique du partitionnement matériel/logiciel. En limitant le nombre
de critères et en figeant l’architecture cible, le problème se réduit à un problème d’allocation
qui peut se résoudre automatiquement avec une heuristique basée sur une fonction pondérée
dont les coefficients dépendent des critères retenus. Dans le cas général (architecture cible
hétérogène et nombre de critères élevé), il faut aider le concepteur en lui offrant des moyens
d’estimations rapides des performances statiques et/ou dynamiques du partitionnement choisi.
Le niveau de description des modèles utilisés ainsi que le niveau de granularité du
partitionnement sont alors très influents sur les moyens et les résultats obtenus. L’estimation
des performances statiques telles que la surface de silicium occupée, la puissance consommée
repose sur des techniques de synthèse qui nécessitent une description au moins du niveau
algorithmique. Pour estimer les performances dynamiques, il faut recourir à une analyse des
contraintes temporelles ou à l’utilisation d’un modèle de performance. L’analyse temporelle
nécessite une description sous la forme de diagramme de flot de données et/ou flot de contrôle
Chapitre 2
14 M.C.S.E
et permet de calculer une approximation des caractéristiques des processeurs. L’utilisation
d’un modèle de performance ne nécessite pas une description aussi détaillée que pour les
estimateurs cités précédemment et permet d’extraire un nombre plus important de résultats de
performances dynamiques du partitionnement choisi: temps de latence, débit sur un bus, taux
d’occupation d’une ressource, nombre moyen de messages dans un port de communication,
etc.
Ces résultats de performances s’obtiennent généralement par une approche analytique
(réseau de files d’attente, réseau de Petri stochastique) ou par simulation. La complexité des
systèmes que nous considérons sort souvent du domaine d’application strict des modèles
analytiques et la simulation reste alors la seule alternative possible. Comme le modèle de
performance représente à la fois la partie logicielle et la partie matérielle résultant du
partitionnement, il s’agit en fait d’une technique de co-simulation.
Ce chapitre présente la méthodologie de co-design préconisée au sein de l’équipe MCSE
caractérisée par sa méthode de partitionnement et sa technique de co-simulation. Avant de
décrire le principe de partitionnement qui repose sur une démarche itérative et sur une
évaluation des performances dynamiques du système, nous passons en revue différentes
méthodes de partitionnement. L’évaluation des performances dynamiques est effectuée par une
co-simulation. Nous présentons donc ensuite un panorama des techniques de co-simulation
existantes et celle retenue par l’équipe qui est macroscopique et non interprétée. Le terme
macroscopique signifie que le système n’a pas besoin d’être entièrement détaillé. Le terme
non-interprété signifie que seul le temps des opérations et les dépendances temporelles sont
pris en compte. Pour cette co-simulation, le modèle de performance de MCSE est transcrit en
un code VHDL. Nous allons donc aussi nous intéresser aux techniques de génération de code
et à la modélisation des performances dynamiques des systèmes. Pour la modélisation des
performances des systèmes, différentes classes de modèles de performances des systèmes et
leurs outils les plus représentatifs sont décrits et analysés. L’analyse des modèles de
performances présentés montre qu’ils ne sont pas bien adaptés au co-design. En effet, ils ne
distinguent pas clairement la vue fonctionnelle du système de sa vue architecturale. Or à notre
avis, cette séparation des deux vues est indispensable pour permettre l’exploration correcte du
domaine des solutions possibles lors du partitionnement.
2.1 PRESENTATION DE LA METHODOLOGIE DE CO-DESIGN
Les méthodologies proposées pour le co-design se distinguent essentiellement par:
- les concepts de modélisation utilisés de la spécification du système au produit final,
- les modèles de l’architecture cible. L’architecture cible peut être une architecture
mono-processeur constituée d’un processeur, d’un ensemble de composants matériels
spécifiques (ASIC, FPGA) et éventuellement une mémoire commune. Il peut s’agir
aussi d’une architecture distribuée composée d’un réseau de processeurs matériels
(ASIC, FPGA) et de processeurs logiciels (microprocesseur, DSP, ASIP).
-laméthode de partitionnement (interactif, semi-automatique ou automatique).
- La méthode et technique de co-vérification.
-Latechnique de co-synthèse où l’on retrouve la synthèse du logiciel, du matériel et des
interfaces matériel/logiciel.
Méthodologie de co-design et estimation des performances
M.C.S.E 1 5
Notre méthodologie de co-design basée sur la méthodologie MCSE est caractérisée par une
approche système, une modélisation selon 3 vues (fonctionnelle, comportementale et
architecturale), une architecture cible hétérogène et non figée, une méthode de partitionnement
interactif basée sur une évaluation des performances dynamiques, une technique de
co-simulation macroscopique et non-interprétée basée sur un modèle d’attributs et une
technique de co-synthèse incluant la génération des interfaces matériel/logiciel qui repose sur
un modèle de bus (protocole) générique et l’utilisation d’une librairie de fonctions d’adaptation
vers un bus spécifique (VME, PCI, I2C, etc.) [MULLER-96].
Nous recommandons l’utilisation de la méthodologie MCSE pour faire tout d’abord
l’approche système nécessaire afin de rechercher une solution si possible globalement optimale
vis-à-vis de l’ensemble des contraintes. La solution fonctionnelle développée servira alors
comme base pour identifier les parties qui relèvent du co-design. La description fonctionnelle
de chaque partie sert ainsi de spécification. L’architecture de la solution complète se déduit par
MCSE. Les parties de l’architecture plus spécifiques du co-design seront décidées selon les
contraintes à satisfaire. Une description détaillée et la justification de cette approche est
expliquée dans [CALVEZ-96e] et [CALVEZ-97a].
2.1.1 Rappel de la méthodologie MCSE
MCSE est une solution possible comme schéma d'organisation pour tout développement de
systèmes électroniques et informatiques à caractère temps-réel. Cette méthodologie conduit à
la conception et la réalisation de composants, de cartes, de systèmes à la fois pour les aspects
matériel et logiciel, ainsi qu’au développement de logiciels en divers langages de manière à
particulariser le matériel pour que celui-ci réponde aux fonctionnalités exigées de l'application
[CALVEZ-90], [CALVEZ-93a].
Un développement, selon MCSE, est décomposé en 4 étapes (figure 2.1):
- l'étape de Spécification qui a pour objectif d'élaborer une description externe la plus
complète possible du système à concevoir, et ceci à partir du cahier des charges.
-Figure 2.1- Démarche de développement avec MCSE.
Niveau 1
Niveau 2
Niveau 3
Niveau 4
Abstrait
Concret
PRODUIT
Temps
DEFINITION
de la
REALISATION
REALISATION
Spécifications
Description fonctionnelle
Description exécutive
Modèles
Spécification
Modèle
fonctionnel
Modèle
d’exécution
Spécifications
Spécifications
fonctionnelles
et opératoires
CHARGES
CAHIER
DES
technologiques
CONCEPTION
FONCTIONNELLE
Spécifications technologiques de réalisation
SPECIFICATION
Partie incluant
le co-design
Chapitre 2
16 M.C.S.E
- l'étape de Conception fonctionnelle. Elle conduit à rechercher une solution pour le
système sous la forme d'un ensemble de fonctions et de relations entre celles-ci. Cette
solution est une vue orientée vers l'application et se doit d'être indépendante de la
technologie.
- l'étape de Définition de la réalisation. Il s'agit d'introduire la répartition géographique
et les interfaces physiques pour satisfaire les contraintes technologiques, puis après
avoir défini le partitionnement matériel/logiciel compte-tenu des contraintes de temps
et autres contraintes de réalisation, de déterminer les spécifications des parties
matérielles et logicielles.
- l'étape de Réalisation qui consiste à développer le matériel et le logiciel à partir des
spécifications de l'étape précédente.
A chaque niveau de description correspond un modèle bien formalisé qui sert d’interface et
de documentation entre les étapes successives. L’étape 3 sert à identifier les spécifications de
la réalisation. Aussi, c’est dans cette étape que se situe l’activité de co-design.
2.1.2 Démarche pour la définition de la réalisation
L’étape de Définition de la Réalisation de MCSE est décomposée en 3 phases:
-Transformation de la solution fonctionnelle pour satisfaire les spécifications
technologiques de répartition géographique et d’interfaces. Il en résulte une solution
fonctionnelle détaillée et optimisée.
-Partitionnement au niveau système, qui vise à identifier à partir de la solution
fonctionnelle complète la partie purement logicielle, la partie purement matérielle, la
partie concernée par le co-design.
-Spécifications de réalisation pour le logiciel, le matériel et la partie co-design. Les 3
parties sont considérées conjointement. Une vérification et une analyse des propriétés
de la solution achèvent cette phase et l’étape pour s’assurer du respect de l’ensemble des
contraintes.
La figure 2.2 montre l’organisation de la démarche pour cette étape. Une partie des
spécifications technologiques est considérée ici. Il s’agit des contraintes de distance entre
constituants ou/et entre entrées/sorties, des contraintes d’interfaces physiques et d’interfaces
homme/machine, des contraintes de performances, de sûreté, de coût.
Durant l’activité de répartition géographique, un premier partitionnement est déjà effectué.
Il se base exclusivement sur les distances imposées entre certains constituants du système. Il
s’agit d’un partitionnement fonctionnel c’est-à-dire vis-à-vis de l’objectif à satisfaire. La
phase 1 amène ainsi à déformer la solution fonctionnelle de l’étape précédente au sens de son
enrichissement par des détails en vue de satisfaire des contraintes d’ordre technologique.
La phase 2 concerne cette fois le partitionnement du système complet et donc sa solution
fonctionnelle vis-à-vis de la technologie de réalisation, c’est-à-dire matériel ou logiciel. Les
contraintes influentes que sont les performances, la sûreté de fonctionnement au sens large du
terme, le coût, servent de base pour déterminer la ou les parties qui conduisent à une réalisation
purement logicielle, à une réalisation purement matérielle, à une réalisation où une variation
est possible entre le matériel et le logiciel (partie qualifiée de co-design). Ce partitionnement
est de niveau système et se comprend bien lorsque l’on considère un système possédant le
Méthodologie de co-design et estimation des performances
M.C.S.E 1 7
qualificatif de complexe. La séparation radicale matériel ou logiciel est généralement assez
simple pour une grande partie du système. La partie restante (frontière à délimiter) qui se veut
plus délicate est celle relevant du co-design.
-Figure 2.2- Description de la démarche pour l’étape de définition de la réalisation.
La phase 3 vise à déterminer les spécifications les plus complètes possible de chacune des
parties et les interfaces entre elles. En suivant la méthodologie MCSE, la spécification du
matériel pour le système complet se fait en définissant le support d’exécution (ou architecture
matérielle) et toutes ses propriétés. La spécification du logiciel s’obtient en définissant le
schéma d’implantation du logiciel pour chaque processeur programmable de l’architecture
matérielle. Il reste alors chaque partie co-design qui nécessite une démarche plus affinée pour
aboutir à sa spécification détaillée permettant ensuite la vérification et la réalisation. Le détail
de cette démarche est décrit dans le paragraphe suivant.
L’activité de vérification et d’analyse globale vise à garantir au mieux que les concepteurs
disposent de spécifications de réalisation complètes, cohérentes et optimales vis-à-vis des
contraintes permettant d’aboutir à un système complet en accord avec les spécifications du
niveau système et donc en accord avec toutes les exigences du client. Cette activité est basée
sur l’emploi d’un modèle de description mixte matériel-logiciel exécutable de la solution, ou
tout au moins des parties critiques.
L’intérêt fondamental de cette démarche basée sur MCSE pour faciliter le travail de
co-design est de se poser réellement la question d’un partitionnement système (logiciel ou
matériel ou les deux simultanément) pour l’ensemble de l’application de manière à
correctement isoler les seules parties qui sont du ressort du co-design. D’une manière générale,
la spécification en entrée de l’activité de co-design se doit d’être le résultat d’une démarche
d’un niveau supérieur qui est le niveau système. Ceci correspond au fait qu’une bonne
résolution d’un problème passe d’abord par son “immersion” dans un problème plus global.
Spécifications Description fonctionnelle
Contraintes interfaces
Spécifications de la réalisation complète
Spécifications
Description fonctionnelle détaillée et optimisée
Phase 1
Phase 2
Phase 3
Corrections
Améliorations
pour
vérification
Partitionnement géographique
Introduction des interfaces physiques et IHM
Synthèse
interfaces
Partitionnement système
Evaluation globale
Distances
Partie(s)
matérielle(s) Partie(s)
logicielle(s) Partie(s)
co-design
Performances, sûreté,
coût
1 / 38 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !