Méthodologie de co-design et estimation des - Lab

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
M.C.S.E
13
Chapitre 2
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).
- la méthode de partitionnement (interactif, semi-automatique ou automatique).
- La méthode et technique de co-vérification.
- La technique de co-synthèse où l’on retrouve la synthèse du logiciel, du matériel et des
interfaces matériel/logiciel.
14
M.C.S.E
Méthodologie de co-design et estimation des performances
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.
Abstrait
CAHIER
DES
CHARGES
SPECIFICATION
Modèles
Spécification
Spécifications
Niveau 1
Spécifications
fonctionnelles
et opératoires
CONCEPTION
Modèle
fonctionnel
Partie incluant
le co-design
FONCTIONNELLE
Niveau 2
Description fonctionnelle
Spécifications
technologiques
DEFINITION
de la
REALISATION
Description exécutive
Niveau 3
Spécifications technologiques de réalisation
Concret
Modèle
d’exécution
PRODUIT
REALISATION
Niveau 4
Temps
-Figure 2.1- Démarche de développement avec MCSE.
M.C.S.E
15
Chapitre 2
- 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
16
M.C.S.E
Méthodologie de co-design et estimation des performances
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.
Spécifications
Distances
Description fonctionnelle
Partitionnement géographique
Phase 1
Contraintes interfaces
Introduction des interfaces physiques et IHM
Description fonctionnelle détaillée et optimisée
Performances, sûreté,
Partie(s)
matérielle(s)
pour
vérification
Spécifications
Phase 2
Partitionnement système
coût
Partie(s)
Synthèse
logicielle(s)
interfaces
Partie(s)
co-design
Corrections
Améliorations
Phase 3
Evaluation globale
Spécifications de la réalisation complète
-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.
M.C.S.E
17
Chapitre 2
2.1.3 Démarche pour le co-design
Le travail de co-design s’intègre ici comme un sous-ensemble de l’étape 3 de définition de
la réalisation de la méthodologie MCSE. Les données d’entrée en tant que spécifications sont:
la description fonctionnelle détaillée de la partie concernée par le co-design, les spécifications
non-fonctionnelles de cette partie. Il en résulte en sortie la spécification détaillée et complète
de la solution de réalisation.
La figure 2.3 représente les différentes phases de la démarche de co-design [CALVEZ-94]
[CALVEZ-96c]. On notera bien entendu l’importance de la phase de partitionnement matériel/
logiciel et d’allocation pour aboutir aux spécifications des 2 parties.
Description fonctionnelle détaillée de
la partie concernée par le co-design
Spécifications non-fonctionnelles
Corrections
Phase 1
Contraintes de temps,
Performances,
workload
Partitionnement, allocation
Corrections,
améliorations
Modélisation et évaluation Performances
(Co-vérification non-interprétée)
Architecture
Contraintes de
réalisation
Rétro-annotation
Partitionnement approprié
Corrections
locales
Synthèse
Matériel
Synthèse
interfaces
Synthèse
Logiciel
Corrections
globales
Evaluation détaillée(Co-vérification interprétée)
Phase 2
Contraintes
technologiques
Specification pour la réalisation
-Figure 2.3- Démarche de co-design avec maîtrise des performances.
La démarche de co-design est décomposée en 2 phases:
Phase 1: Partitionnement et allocation, évaluation
• Décomposition de la solution fonctionnelle d’entrée en une partie logicielle et une
partie matérielle compte-tenu des performances et des contraintes de temps à
satisfaire,
• Spécification de la structure d’exécution (architecture matérielle) et allocation des
fonctions sur les composants,
• Evaluation et vérification de la solution vis-à-vis des
non-fonctionnelles imposées, ce qui implique une co-simulation.
spécifications
Phase 2: Synthèse, génération, évaluation
• Conception architecturale et synthèse de la partie matérielle,
• Spécification et génération de la partie logicielle,
• Synthèse et génération des interfaces entre le matériel et le logiciel,
18
M.C.S.E
Méthodologie de co-design et estimation des performances
• Evaluation et vérification du comportement fonctionnel et des performances.
Ces phases sont décrites plus en détail ci-après.
-A- Partitionnement, allocation et évaluation
La phase 1 concerne la recherche d’une architecture matérielle appropriée comme support
de la description fonctionnelle détaillée et qui va permettre d’aboutir à une solution
opérationnelle qui satisfait les contraintes de performances, les contraintes de temps, le coût,
etc. Le partitionnement de la structure fonctionnelle est la première tâche qui permet
d’identifier les fonctions qui peuvent être implantées en logiciel et les fonctions à implanter
obligatoirement en matériel.
Avec la méthodologie MCSE, nous proposons de suivre une démarche de partitionnement
interactif assuré par le concepteur car il peut aisément décider pour chaque fonction le meilleur
choix, en particulier après une modélisation et une évaluation des performances.
La structure d’exécution peut alors être définie: les fonctions matérielles sont à implanter
sous la forme d’une architecture de composants matériels, les fonctions logicielles sur un ou
plusieurs microprocesseurs en fonction des contraintes de temps, de coût et de répartition. Des
liens nécessaires pour le couplage entre le matériel et le logiciel doivent alors être spécifiés
pour l’implantation des relations fonctionnelles. D’une manière générale, la structure
d’exécution résulte d’un travail d’abstraction fait sur la structure fonctionnelle détaillée.
Le résultat de ce travail doit être vérifié. Il s’agit de s’assurer que le partitionnement et
l’allocation choisis ainsi que les caractéristiques de l’architecture matérielle permettent de
satisfaire toutes les exigences attendues et écrites dans le document de spécification sous le
vocable spécifications non-fonctionnelles. Pour ce faire, le résultat est transcrit sous la forme
du modèle de performances de MCSE. Il s’agit d’un modèle non-interprété qui, par simulation,
permet de déduire les propriétés de performance [CALVEZ-96b] [CALVEZ-96d]. Une
modélisation de l’environnement est faite pour simuler les conditions d’utilisation (workload).
D’autres moyens de vérification et d’analyse peuvent être ajoutés pour augmenter la confiance
dans la solution retenue.
-B- Génération, synthèse, évaluation
La phase 2 concerne la génération de l’ensemble de la solution, ce qui comprend: la
description de l’architecture matérielle en y incluant la description de tous les composants
spécifiques et/ou programmables (ASICs), les programmes pour tous les microprocesseurs.
Pour la description du matériel, il faut distinguer 2 parties et donc 2 niveaux de détail. Le
premier niveau concerne le schéma d’interconnexion des composants retenus pour la solution:
microprocesseur(s), mémoires, EPLD, FPGA, etc. La description d’un tel schéma est
conventionnelle et s’obtient par l’emploi d’outils de saisie de schémas. Ce schéma permet
ensuite la réalisation directe par assemblage ou la réalisation de carte(s) imprimée(s) comme
support(s) des composants ou même la réalisation d’un "System on a chip". Le deuxième
niveau concerne la description de chaque ASIC. Cette description est à faire de préférence en
langage de haut-niveau tel que VHDL de manière à pouvoir utiliser un synthétiseur
architectural ou de haut niveau.
Pour la partie logicielle, très souvent, une organisation multi-tâches doit être retenue par
suite de l’existence de plusieurs fonctions asynchrones à implanter sur un même
microprocesseur. Une méthode efficace consiste à définir un schéma d’implantation logicielle
(voir MCSE) sans utiliser d’exécutif temps-réel. Une autre méthode consiste à utiliser un
M.C.S.E
19
Chapitre 2
exécutif temps-réel. Dans ce cas, chaque fonction est implantée comme une tâche et les
relations entre fonctions utilisent les mécanismes de sémaphore, de boite à lettre, de partage de
ressources. Une solution intermédiaire existe en utilisant judicieusement les qualités de ces 2
méthodes [CALVEZ-97b].
Des interfaces correctes entre le matériel et le logiciel doivent aussi être générées pour une
implantation appropriée et efficace des relations fonctionnelles. Ces interfaces sont produites
par synthèse à partir des caractéristiques du couplage matériel entre le microprocesseur et son
environnement. Des modèles génériques de bus sont ici exploitables (bus VME, bus PCI,....).
L’ensemble de la solution - matériel, logiciel, interfaces - sert ensuite pour une vérification
détaillée de toutes ses propriétés: propriétés fonctionnelles et non-fonctionnelles. Une
technique de co-simulation est alors appropriée pour ce type de vérification. Un modèle de
l’environnement est à nouveau nécessaire. Il résulte du travail déjà effectué pour l’ensemble du
système au niveau fonctionnel. Il s’agit donc d’exploiter le modèle fonctionnel complet et
optimisé pour lequel la partie co-design du système qui vient d’être conçue est remplacée par
le résultat de cette phase 2.
Le résultat issu de cette étape de co-design peut ensuite être prototypé, vérifié et validé puis
intégré dans la solution d’ensemble du système complet.
2.1.4 Bilan
La présentation faite dans ce paragraphe montre clairement que la démarche de co-design
n’est pas une activité isolée de la conception de l’ensemble du système. Faisant partie
intégrante de l’étape de définition de la réalisation, le travail de co-design est appliqué sur une
ou des parties qui ont été pleinement identifiées comme justifiant d’une telle approche. En
amont, en plus d’un partitionnement géographique réalisé durant la conception préliminaire,
un travail de partitionnement au niveau système conduit à décider d’une première grande
répartition matériel ou logiciel si possible optimale globalement. Il en résulte une identification
de zones intermédiaires qui nécessitent un travail plus approfondi qui est alors typiquement du
ressort du co-design. Pour ces parties, un optimum local est alors recherché. Une telle approche
système en 2 temps évite les écueils du “défaut de myopie” qui amènerait à trouver un optimum
local pour une spécification donnée sans s’être assuré que la spécification résulte elle aussi
d’un optimum pour le niveau système.
Bien entendu, lorsqu’un problème posé est seulement du ressort du co-design, seule la
démarche décrite par la figure 2.3 est suffisante à condition de disposer des spécifications
correctes et complètes de l’objet à concevoir. Pour décider de la bonne démarche à suivre, une
question importante à se poser est de savoir si le problème est ou non “immergé” dans un
problème plus vaste. On constate aujourd’hui que la plupart des problèmes sont présentés
isolés alors qu’en réalité ils ne le sont pas. MCSE impose une démarche plus globale ne
serait-ce qu’en imposant d’abord une analyse et une modélisation de l’environnement de
l’objet à concevoir, modélisation bien utile en final pour la vérification et la qualification du
système placé dans son environnement.
2.2 METHODES DE PARTITIONNEMENT
Le problème du partitionnement matériel/logiciel est au coeur de l’activité de co-design. Le
choix de l’architecture matérielle est un élément de décision essentiel et la démarche diffère
selon que l’architecture se trouve imposée ou choisie d’emblée ou que l’architecture et les
20
M.C.S.E
Méthodologie de co-design et estimation des performances
composants de celle-ci sont à déterminer. La première situation est la plus commune et la plus
simple. L’architecture matérielle est généralement une architecture générique constituée d’un
microprocesseur, d’un ensemble de circuits matériels programmables ou d’ASICs et d’une
mémoire commune. Le problème du partitionnement se réduit alors à un problème de
partitionnement binaire matériel/logiciel pour l’allocation des éléments fonctionnels sur les
constituants de l’architecture et peut se résoudre de manière automatique. Nous nous
intéressons à la deuxième situation plus complexe et plus proche de la réalité industrielle. Dans
ce cas, face à la nature hétérogène de l’architecture cible et à la diversité des contraintes
imposées, une démarche itérative et guidée par le concepteur s’impose. Il s’agit alors d’offrir
au concepteur des moyens rapides d’estimation des propriétés de l’implantation résultant du
choix de l’architecture, du partitionnement et de l’allocation pour vérifier si celles-ci répond
aux contraintes imposées. Pour les parties du système relevant du co-design, les contraintes
imposées sont surtout des contraintes de performances. En effet, les contraintes telles que la
flexibilité, la testabilité, l’utilisation de composants du commerce ou de technologies
maîtrisées par l’entreprise, la sûreté de fonctionnement et les coûts interviennent
principalement au niveau du partitionnement système qui a pour but le découpage du système
en un ensemble de partitions où chaque partition devra s’exécuter soit en logiciel soit en
matériel. Les contraintes de performances sont de nature statique ou dynamique. L’estimation
des performances statiques telles que la surface de silicium occupée, la puissance consommée
repose sur des techniques de synthèse. La plupart des travaux de la communauté du co-design
sur l’estimation des performances dynamiques d’un partitionnement, sont basés sur une
analyse des contraintes temporelles et un calcul de la charge du processeur par des techniques
proches de celles utilisées en ordonnancement de tâches pour des systèmes temps-réels. Nous
proposons une autre alternative qui consiste à utiliser un modèle de performance. La simulation
de ce modèle de performance permet d’extraire un ensemble d’estimations de performances
plus riches que les approches analytiques: débit sur un bus, taux d’occupation d’une ressource,
temps de latence d’un message, détection du non respect d’une contrainte temporelle, etc.
2.2.1 Le partitionnement matériel/logiciel
Le partitionnement matériel/logiciel assure la transformation des spécifications de la partie
du système relevant de l’activité co-design en une architecture composée d’une partie
matérielle et d’une partie logicielle. Les spécifications considérées sont en réalité une
description fonctionnelle détaillée résultant d’une approche système. Cette transformation
s’effectue habituellement en deux phases: la sélection d’une architecture matérielle et
l’allocation des éléments (fonctions et éléments de relations) du modèle fonctionnel sur les
éléments de cette architecture. Plusieurs critères peuvent intervenir sur le double choix
(architecture et allocation) d’un partitionnement tels que par exemple:
- les performances statiques (consommation, surface de silicium, coûts, taille du code,
taille de la mémoire, etc) et dynamiques (contraintes de temps, débit, temps de latence,
taux d’occupation, etc). Elles influent surtout sur l’allocation des fonctions.
- la sécurité: La prise en compte de la sûreté de fonctionnement peut induire des
contraintes au partitionnement matériel/logiciel (redondance de composants matériels
et de tâches logicielles par exemple),
- la flexibilité: l’implantation logicielle d’une fonction offre des possibilités d’évolution
plus importantes qu’une implantation matérielle,
M.C.S.E
21
Chapitre 2
- la réutilisation: La réutilisation de composants est un facteur important de productivité,
mais introduit des contraintes au niveau du partitionnement,
- la testabilité: l’extraction d’informations en temps-réel nécessite l’ajout de composants
matériels supplémentaires (Bist, Boundary Scan) ou l’ajout d’instructions de capture.
Actuellement, il n’existe pas de méthodes formelles réellement opérationnelles qui
permettent à partir des contraintes à satisfaire et des spécifications du système de générer
directement une répartition matériel/logiciel. La difficulté du problème est liée à la diversité
des contraintes à satisfaire et des possibilités de sélection d’architecture puis d’allocation.
Le partitionnement s’effectue par des approches successives soit de manière automatique
par le biais d’algorithmes de recherche soit de manière interactive avec l’aide du concepteur.
La plupart des techniques de partitionnement automatique repose sur une architecture cible
imposée et mono-processeur, une heuristique et l’utilisation d’une fonction de coût dont les
coefficients de pondération dépendent de critères tels que ceux cités précédemment. Le
partitionnement interactif cible généralement vers une architecture hétérogène à définir et
s’appuie sur des estimateurs de performances statiques et/ou une estimation des performances
dynamiques du système pour guider le concepteur dans le choix d’une répartition.
Les techniques de partitionnement décrites dans la littérature peuvent être classées par:
- leur degré d’automatisation allant d’une démarche manuelle à une démarche
entièrement automatique,
- Les critères influençant le choix d’un partitionnement (contraintes statiques ou
dynamiques, sûreté de fonctionnement, flexibilité, testabilité, coûts),
- le choix de l’architecture cible figée ou libre,
- le degré d’abstraction du modèle représentant les éléments de la spécification du
système à partitionner et de l’architecture matérielle allant d’une modélisation
macroscopique à une modélisation architecturale détaillée.
Pour les spécifications d’entrée d’un partitionnement, trois niveaux de granularité du
partitionnement sont habituellement utilisés: le niveau tâche, le niveau procédure et le niveau
instruction. Pour le niveau tâche (coarse-grain partitioning), l’unité d’allocation est la fonction
qui est considérée indivisible et dont le comportement n’est pas obligatoirement séquentiel.
Pour le niveau procédure, une fonction est décomposée en un ensemble de séquences
d’instructions appelées procédures et qui peuvent être allouées sur des processeurs différents.
Pour le niveau instruction (fine-grain partitioning), l’unité d’allocation est la plus petite
possible puisqu’il s’agit d’une instruction. L’utilisation d’un niveau de granularité fine
concerne plutôt des systèmes de faible complexité ou une conception architecturale avancée
qui se situe relativement tard dans le cycle de développement.
2.2.2 Le partitionnement automatique
Le problème du partitionnement est souvent présenté comme un problème NP complexe
dépendant d’un grand nombre de paramètres. Pour résoudre ce problème, la plupart des
méthodes automatiques réduit le nombre des paramètres (prise en compte d’un nombre limité
de critères) et utilise une heuristique basée sur une fonction de coût pondérée par les critères
retenus.
22
M.C.S.E
Méthodologie de co-design et estimation des performances
Actuellement de nombreuses heuristiques de partitionnement ont été développées. Une
synthèse des méthodes et algorithmes de partitionnement matériel/logiciel automatiques est
présenté par Rousseau, Bergé et Israel [ROUSSEAU-95]. On peut citer en autres (liste non
exhaustive):
- l’algorithme gourmand (Greedy algorithm) utilisé dans VULCAN [GUPTA-95] pour
lequel toutes les fonctions sont initialement implantées en matériel et sont migrées vers
le processeur logiciel en vérifiant les contraintes temporelles. La fonction de coût
utilisée est pondérée par la surface du matériel, la taille du programme de code
(mémoire) et le taux d’occupation du processeur.
- l’approche de COSYMA [ERNST-93] est opposée à celle utilisée dans VULCAN. Les
fonctions sont au départ toutes implantées en logiciel puis migrées vers le matériel
jusqu’au respect des contraintes de performances.
- Les algorithmes utilisés dans Co-Saw [ADAMS-95] et dans SpecSyn [VAHID-95] sont
basés sur la construction progressive de groupes de fonctions (clustering based
algorithm) pouvant partager la même ressource matérielle ou logicielle.
Les algorithmes cités précédemment dépendent fortement (coefficient de pondération de la
fonction de coût) des caractéristiques de l’architecture cible choisie. Souvent l’architecture
cible est composée d’un seul processeur logiciel couplé à un ou plusieurs FPGA ou ASICs et
éventuellement une mémoire commune. Peu de techniques de partitionnement ciblent vers une
architecture hétérogène composée d’un ensemble de processeurs logiciels (microprocesseur,
DSP, ASIP) et matériels (FPGA, ASIC). Hou [HOU-96] propose cependant une heuristique
basée sur la construction progressive de groupes de process (clustering based algorithm) dont
la fonction de coût dépend de la communication inter-processeurs, des temps de commutation
de contexte (approche préemptive et non synchrone) et du taux d’utilisation des ressources. Les
résultats obtenus sont très dépendants des coefficients de la fonction de coût: "the cost function
plays an important role in our partitioning approach" [ERNST-93].
L’architecture générique mono-processeur et constituée d’un ensemble de FPGA
correspond peu à la réalité industrielle. Les composants programmables ont des performances
plus faibles (surface de silicium occupée, fréquence maximale de fonctionnement) et un coût
plus élevé (production en grande série) que les circuit non programmables. De plus, même les
"System on a chip" ne sont pas mono-processeur car ils disposent de plus en plus souvent d’un
coeur de DSP et d’un coeur de microcontroleur (MCU). Ces techniques de partitionnement
automatique ne sont donc intéressantes que pour le prototypage rapide [WENDLING-94] sur
une carte constituée d’un microprocesseur, d’un ensemble de FPGA et éventuellement une
mémoire commune. Mais pour ce type d’application, la rapidité d’obtention d’une
implantation est un critère aussi important que la qualité du partitionnement obtenu: Il s’agit
avant tout de faire une vérification fonctionnelle et non une réelle analyse des performances du
futur produit industriel.
Les techniques de partitionnement automatique souffrent généralement du fait qu’elle ne
prennent pas en compte l’expérience et le bon sens des concepteurs. Dans la réalité industrielle,
le partitionnement d’un système ne pose problème que pour une petite partie du système. Le
concepteur peut facilement faire un partitionnement grossier du système avant de se concentrer
sur les parties délicates. Or les techniques de partitionnement automatique considèrent le
système dans son ensemble et n’utilise pas le fait que le concepteur peut fournir un
M.C.S.E
23
Chapitre 2
partitionnement initial proche de la solution. Elles vont donc balayer un ensemble
d’alternatives inutiles et dans certains cas sont moins efficaces (temps de recherche) qu’un
partitionnement interactif. Inclure le concepteur dans la boucle de recherche de la solution
optimale d’un partitionnement, offre aussi un avantage plus subtil: cela permet d’éliminer la
suspicion des concepteurs face aux résultats obtenus par un partitionnement automatique. En
effet, la nature humaine est ainsi faite qu’elle a souvent tendance à vouloir prouver qu’elle peut
obtenir un résultat meilleur que celui obtenu par une méthode automatique. De plus, le
concepteur a aussi la maîtrise complète de la solution retenue avec toutes ses justifications.
2.2.3 Le partitionnement interactif
Ismail [ISMAIL-94a] [ISMAIL-94b] propose une technique de partitionnement interactive
(PARTIF) permettant de cibler sur une architecture hétérogène. Le concepteur peut aisément
explorer plusieurs alternatives de partitionnement du système en manipulant une hiérarchie
d’automates à états finis concurrents représentée selon le formalisme SOLAR. Un ensemble de
primitives de transformations d’états (déplacement, regroupement, décomposition,...) est
disponible. Cette approche est intéressante mais pour l’instant le concepteur dispose de peu de
résultats quantitatifs en retour pour évaluer la partie logicielle (statistiques sur les
interconnexions et les variables partagées) et la partie matérielle (statistiques sur le nombre
d’états et sur le nombre d’opérateurs de la partie opérative) obtenues de manière à les comparer
aux contraintes imposées.
2.2.4 L’analyse des propriétés d’un partitionnement
Pour analyser les propriétés d’un partitionnement, la plupart des techniques de
partitionnement utilisent des estimateurs basés sur:
- une analyse des contraintes temporelles, ce qui nécessite de représenter le
comportement des fonctions à un niveau interprété et très détaillé. Généralement, le
comportement d’une fonction est représentée sous la forme d’un flot de donnée et d’un
flot de contrôle (CDFG). L’analyse des graphes [WOLF-94] [GUPTA-96] permet
d’extraire une approximation du temps d’exécution de chaque fonction et de vérifier le
respect des contraintes temporelles. Puis pour une implantation logicielle de la fonction,
on applique les algorithmes utilisés dans les problèmes d’ordonnancement des systèmes
temps réels pour calculer la charge du processeur. Formulé sous sa forme la plus simple
(mono-processeur et tâches périodiques), le problème se résoud souvent par
l’algorithme de base RMS "Rate Monotonic Scheduling". Le problème se complique
lorsque les tâches peuvent être sporadiques ou lorsque le système est distribué
[WOLF-94] [MALIK-95].
- une analyse statique basée sur des résultats de techniques de synthèse qui nécessite une
description des fonctions au moins au niveau algorithmique (synthèse haut niveau) pour
extraire des caractéristiques [NARAYAN-92b] telles que la surface de silicium
occupée, la puissance dissipée, le nombre de broches, la taille du programme code, la
taille de la mémoire nécessaire, etc.
Très peu de techniques de partitionnement sont basées sur un modèle plus abstrait et
non-interprété d’un système. Ambrosio [AMBROSIO-94] propose une technique de
partitionnement basée sur un modèle "système". Les processeurs sont représentés par des
24
M.C.S.E
Méthodologie de co-design et estimation des performances
ressources caractérisées par une taille mémoire et le temps d’exécution d’une instruction. La
partie logicielle est représentée par des tâches utilisant une quantité de mémoire et un nombre
d’instructions donné. Romdhani [ROMDHANI-96] propose une méthode de partitionnement
matériel/logiciel où l’évaluation des performances dynamiques du système est effectuée avec
l’outil SES/Workbench.
2.2.5 La méthode de partitionnement proposée
Notre approche consiste à considérer que le partitionnement se fait à un niveau
d’abstraction le plus élevé possible afin de considérer le système dans sa globalité et doit
exploiter au mieux le bon sens et l’expérience des concepteurs. Ainsi impliqué dans le
processus de partitionnement, le concepteur continue à accumuler une expérience et à
développer ses compétences.
Pour élever le niveau d’abstraction des modèles du système, nous n’utilisons pas pour
l’instant d’estimateurs statiques puisque ceux-ci nécessitent une description détaillée et
interprétée du comportement des fonctions. L’évaluation d’un partitionnement repose sur la
simulation d’un modèle des performances du système. Contrairement aux approches
analytiques, la simulation n’est pas limitée par la complexité du système et elle permet
d’obtenir un ensemble d’estimations de performances plus important.
La méthode de partitionnement proposée repose sur la démarche itérative suivante: Compte
tenu des divers critères qui lui sont imposés, le concepteur définit une première architecture
matérielle. Les critères tel que la flexibilité, la testabilité, l’utilisation de composants du
commerce (COTS) ou technologies maîtrisées par l’entreprise, la sûreté de fonctionnement, le
coût et l’expérience du concepteur influent directement sur cette première implantation. Une
fois cette architecture matérielle définie, le concepteur alloue les fonctions à très fortes
contraintes temporelles aux processeurs matériels et le reste des fonctions aux processeurs
logiciels en limitant si possible les communications inter-processeurs. Avec MCSE,
l’alternative logiciel/matériel se détermine par le temps d’exécution approximatif de chaque
fonction et sa fréquence maximale d’activation (hypothèse de tâches périodiques). Puis, la
co-simulation reposant sur la transcription en VHDL du modèle de performance du système
donne en retour des mesures de performances tels que le temps de réponse des fonctions, le
temps de latence de messages, le débit sur un bus ou encore le taux d’occupation d’une
ressource. L’analyse de ces performances permet de vérifier le respect ou non des contraintes
de performances à satisfaire et d’identifier les ressources critiques. Le concepteur modifie alors
l’implantation des fonctions et ressources jugées critiques et réévalue le modèle. Il peut aussi
revenir sur l’architecture matérielle en changeant sa constitution et/ou des caractéristiques de
ses composants.
Dans la plupart des cas, la mise à jour du modèle portera essentiellement sur des attributs
des modèles fonctionnel et architectural et l’allocation des fonctions. En effet, comme nous le
verrons plus tard le modèle de performance étant basé sur le concept d’attribut, une
modification de l’architecture matérielle ne nécessite pas forcément une nouvelle saisie
(graphique ou textuelle) du modèle: l’utilisation de paramètres génériques associés aux
attributs des éléments du modèle de performance permet de parcourir un espace assez vaste des
solutions possibles d’une architecture.
M.C.S.E
25
Chapitre 2
2.3 TECHNIQUES DE CO-SIMULATION
Les problèmes de la co-simulation et du partitionnement matériel/logiciel sont souvent liés.
Par exemple, notre méthode de partitionnement repose sur une co-simulation pour extraire les
performances dynamiques du système puisque le modèle de performance qui est simulé
représente à la fois la partie matérielle et la partie logicielle du système. De plus, une fois le
partitionnement effectué, le concepteur effectue généralement une vérification fonctionnelle
du résultat obtenu. Lors de l’analyse des résultats de cette co-simulation, la détection éventuelle
d’erreurs nécessite un retour vers les phases précédentes et notamment vers la phase de
partitionnement matériel/logiciel. La co-simulation n’est pas la seule technique disponible
pour vérifier la conception et l’implantation d’un système. D'une manière générale,
l'observation des propriétés d'un système peut résulter de 3 techniques différentes: l'évaluation
analytique (méthodes formelle), la simulation, l'observation et la mesure (monitoring) sur un
prototype ou un émulateur.
Le problème de la définition des vecteurs de test ou stimuli et de leur validité est
généralement peu abordé alors qu’il est essentiel. Il faut tenir compte de tous les cas de scénario
de charge du système. Il est bon de noter que pour cet aspect de la co-simulation, notre
approche se distingue par une modélisation du système et de son environnement avec le modèle
de performance de MCSE. Cette approche évite de passer des stimuli au simulateur et permet
surtout de modéliser plus facilement les comportements éventuellement complexes des entités
de l’environnement du système.
2.3.1 La co-simulation
Une co-simulation est une simulation simultanée de la partie logicielle et de la partie
matérielle d’un système et de leurs interactions. Elle est utilisée pour observer le comportement
du système complet qui se compose de quatre classes d’objets: les processeur matériels ou
co-processeur dédiés, les processeurs logiciels, le logiciel s’exécutant sur les processeurs
logiciels et la logique d’interface (communication inter-processeurs).
Un système complet peut être simulé à différents niveaux de détail. Par exemple, un
processeur logiciel peut être décrit comme un ordonnanceur de tâches et le logiciel comme un
ensemble de tâches. Mais le processeur logiciel peut aussi être représenté par une description
architecturale détaillée (pipeline, cache, registre, ALU...) et le logiciel par une séquence
d’instructions du jeu d’instructions du processeur. Généralement, plus le développement est
avancé, plus la co-simulation est détaillée. Au cours du cycle de développement, la
co-simulation repose donc sur différents modèles et vise plusieurs objectifs: elle sert à faire une
vérification fonctionnelle ou comportementale détaillée (modèle interprété), une évaluation
des performances (modèle non interprété) ou les deux simultanément (modèle hybride).
Nous considérons qu’une méthodologie de co-design repose sur l’utilisation de plusieurs
techniques de co-simulation: une co-simulation non-interprétée pour l’analyse des
performances lors de la phase de recherche de l’architecture et du partitionnement matériel/
logiciel, une co-simulation fonctionnelle détaillée après synthèse (ou co-vérification) pour
valider l’implantation. On parle alors de vérification d’un prototype virtuel.
Les techniques de co-simulation se distinguent par l’utilisation d’un modèle ou langage
unique ou non et par le niveau d’abstraction du modèle de description matérielle (VHDL
comportemental, RTL, netlist) et logicielle (C, jeu d’instruction, microcode) [CHANG-95].
Pour les techniques basées sur différents modèles de représentation des parties matérielles et
26
M.C.S.E
Méthodologie de co-design et estimation des performances
logicielles, il faut faire communiquer différents simulateurs (IPC d’unix [THOMAS-93], fond
de paniers de simulateurs, Ptolemy [KALAVADE-95], interface via le bus du microprocesseur
[McCabe-94]). Les techniques mono-modèle se distinguent par le degré d’abstraction du
modèle des processeurs logiciels (modèle d’attributs, modèle flot de ressource, modèle ISA du
jeu d’instructions [BALBONI-95]).
2.3.2 Les techniques multi-langages
Les techniques basées sur des modèles ou langages différents de représentation des parties
matérielles et logicielles, reposent sur la coopération de simulateurs. On parle alors de
simulation hétérogène.
La plupart des projets de co-design (COSMOS du groupe TIMA [ISMAIL-94b]
[LIEM-97], Co-Saw [THOMAS-93]) utilisent une simulation VHDL de la partie matérielle et
l’exécution d’une description algorithmique de haut niveau de la partie logicielle. Le langage
VHDL permet en effet d’intégrer une description écrite dans un langage autre que VHDL grâce
à l’interface Foreign Language Interface (VHDL’93). Il s’agit souvent du langage C avec
lequel a été également écrit le noyau du simulateur VHDL auquel on accède via un ensemble
de primitives spécifiques. L’interface entre l’API du simulateur VHDL et l’environnement de
programmation C (compilateur, debuggeur, etc) utilise des mécanismes de communication
inter-process (IPC d’unix) [THOMAS-93] [VALDER.-95]. Lorsque le simulateur VHDL
reçoit une information de l’exécution de la partie C (socket), il met à jour les signaux concernés
après un délai d’attente qui correspond au temps d’exécution de la partie C. Ainsi, l’exactitude
de la simulation est préservée: "The hardware simulator thus serves as a supervisor, ensuring
that data is accessed in correct order" [GAJSKI-95].
Le processeur logiciel qui est l’élément clef de la co-simulation est souvent représenté sous
la forme d’une machine virtuelle. Cette machine virtuelle peut se décrire à différents niveaux:
système d’exploitation multi-tâches, jeu d’instructions, architecture physique [KUMAR-96].
Dans le projet COBRA [SOININEN-94], la machine virtuelle est modélisée au niveau système
d’exploitation (ordonnanceur de tâches à priorité fixe décrit en VHDL) et le logiciel est
modélisé par un ensemble de tâches écrites en C (couplage avec l’API du simulateur VHDL).
Le plus souvent la machine virtuelle est modélisée par son jeu d’instructions. Dans ce cas, le
logiciel doit être compilé pour le microprocesseur cible. Il n’est pas toujours possible d’obtenir
d’un fabricant de microprocesseurs, un modèle de simulation basé sur le jeu d’instruction du
processeur. Parfois pour protéger la propriété intellectuelle du fabricant, le modèle de
simulation du microprocesseur est uniquement un modèle de bus (bus level model). Un modèle
de bus simule les cycles requis pour une transaction sur le bus (accès en lecture ou écriture)
mais ne modélise pas les actions d’une instruction.
Pour faire communiquer un simulateur HDL (VHDL, Verilog) et un simulateur du jeu
d’instructions d’un processeur, un simulateur de modèle de bus d’un processeur ou l’exécution
d’une description algorithmique de la partie logicielle, on peut également utiliser un fond de
panier de simulateur tel que Ptolemy [KALAVADE-92] ou simMatrix de Precedence Inc.
Enfin, les vendeurs d’outils EDA fournissent aujourd’hui des solutions spécifiques au
problème de la co-simulation (Seamless CVE de Mentor, Eagle i de Viewlogic). Par exemple,
l’outil Seamless CVE de Mentor Graphics permet de synchroniser par une modélisation
particulière du bus du processeur un simulateur du jeu d’instructions du microprocesseur (outil
XRAY de Microtec) et un simulateur VHDL ou Verilog.
M.C.S.E
27
Chapitre 2
L’utilisation d’un simulateur VHDL pour la partie matérielle et éventuellement pour la
partie logicielle augmente sensiblement les temps de simulation. Pour réduire les temps de
simulation, il faut élever le niveau d’abstraction des modèles. Ceci est possible pour une
évaluation des performances mais pas pour une vérification fonctionnelle détaillée. Dans ce
dernier cas, il faut recourir à un émulateur matériel. L’emploi d’un émulateur matériel a
cependant deux inconvénients majeurs:
- les émulateurs sont très chers,
- ils ne permettent d’émuler le système qu’à une fréquence 10 à 100 fois plus faible que
la fréquence nominale de fonctionnement. Par exemple, l’émulation du processeur
MicroSPARCII (Sun) sur le système de prototypage QuickTurn n’a pu s’effectuer qu’à
une fréquence de fonctionnement maximale de 750 Khz.
Pour la co-simulation hétérogène, l’équipe MCSE a expérimenté une technique de
co-simulation basée sur une implantation en Java des éléments de relations du modèle MCSE
(port de communication et variable partagée) pour coupler différents simulateurs
[COUSINS-97]. Cette approche se caractérise par une portabilité multi plate-forme
(l’utilisation de Java permet de cibler sur tout type de plate-forme) et par la possibilité de faire
de la co-simulation distribuée en Intranet (sockets) ou en Internet (applet Java et utilisation du
protocole Remote Method Invocation).
2.3.3 Les techniques mono-langage ou mono-modèle
Les techniques mono-modèle ou mono-langage se distinguent par leur concept de
modélisation et le degré d’abstraction du modèle des processeurs qui varie en fonction de la
finalité de la co-simulation (évaluation des performances et/ou vérification fonctionnelle).
Le processeur logiciel est encore souvent modélisé par son jeu d’instructions et son
architecture qui peut être plus ou moins détaillée (modélisation d’un cache mémoire, pipeline
d’instructions, gestion des interruptions, registres, ALU, etc.). Dans le projet TOSCA
[ANTONIA.-94], un processeur est modélisé pour la description VHDL d’un jeu d’instructions
virtuel et d’une architecture générique qui permettent de cibler sur différents processeurs
spécifiques. Ce type de co-simulation souffre d’un temps de simulation important mais offre
un avantage au niveau de la synthèse logicielle: la qualité du code obtenu en appliquant les
techniques de synthèse (allocation des registres, ordonnancement,...) directement sur un
modèle de jeu d’instructions est meilleur que le résultat obtenu par compilation d’une
description algorithmique de haut niveau tel que le langage C. Dans le projet RASSP, le
processeur est aussi modélisé par son jeu d’instructions [ROSE-95], mais le modèle est plus
grossier, est non-interprété et sert uniquement à l’analyse des performances dynamiques d’un
système (outil Cosmos de Omniview présenté plus loin).
Le processeur logiciel peut aussi être modélisé comme une ressource active caractérisée par
un ensemble d’attributs influençant son comportement temporel. Le système est alors modélisé
soit par un flot de transactions (modèle de SES/workbench [ROMDHANI-96]) soit par un
modèle d’architecture dont tous les éléments sont caractérisés par des attributs temporels tel
que le modèle de performance de MCSE [CALVEZ-96d].
28
M.C.S.E
Méthodologie de co-design et estimation des performances
2.3.4 La technique de co-simulation utilisée
La technique de co-simulation retenue par l’équipe MCSE repose sur la transcription du
modèle de performance de la méthodologie MCSE en une description VHDL et l’utilisation
d’un simulateur VHDL du commerce.
La figure suivante illustre le principe de co-simulation retenu.
Controle du simulateur
Modèle MCSE
Resultats
MCSE-SIM
MCSE-GEN
MCSE-PERF
VHDL
VHDL
Trace
Ordre de l’utilisateur
Fichiers pour la simulation
Configuration
de la trace
-Figure 2.4- Principe de co-simulation retenu.
Le modèle de performance de MCSE décrit sous une forme textuelle ou résultant d’une
saisie graphique sert de point d’entrée à un générateur de code (MCSE-GEN) qui le transforme
en un code VHDL simulable. La simulation du code généré produit un fichier de trace
représentant l'évolution des fonctions et des relations inter-fonctions (mécanismes de
communication et de synchronisation). Ce fichier est alors directement exploitable par un outil
d’analyse de performances (MCSE-PERF) pour la présentation des résultats.
Le modèle de performance capable de modéliser la partie logicielle et la partie matérielle
du système est détaillé dans le chapitre 3. Il s’agit d’un modèle:
- macroscopique: le système n’a pas besoin d’être entièrement détaillé ce qui autorise à
faire une évaluation des performances très tôt dans le cycle de développement.
- non-interprété: seuls les temps des opérations et des dépendances temporelles sont pris
en compte ce qui permet un parcours rapide du domaine des solutions possibles d’un
partitionnement tout en évitant l’écriture des parties algorithmiques des opérations.
- évolutif: la notion d’attributs permet d’enrichir le modèle. L’élément délicat qui est le
processeur logiciel pour la co-simulation, est représenté par sa puissance qui intervient
comme un facteur multiplicatif du temps d’exécution des opérations (attribut ‘Power),
son degré de concurrence (attribut ‘Concurrency), sa politique d’ordonnancement des
tâches (attribut ‘Policy) et son temps de commutation de tâches (attribut ‘Overhead).
Le générateur de code VHDL ne se limite pas à la génération automatique d’un code
non-interprété pour l’évaluation des performances. En effet, en remplaçant le temps des
opérations élémentaires par une description algorithmique on obtient alors un modèle VHDL
interprété qui permet de faire en plus une vérification fonctionnelle du système. Le code
algorithmique des opérations doit alors être saisi manuellement par le concepteur. Mais comme
VHDL est un langage très déclaratif, le générateur produira entre 60-80% du code
M.C.S.E
29
Chapitre 2
automatiquement car il se charge de traduire toute l’organisation (ou composante structurelle)
du modèle.
Une autre technique de co-simulation est également en cours de développement dans
l’équipe MCSE. Il s’agit de transcrire le modèle de performance en un code C++ et d’obtenir
les résultats par exécution du programme C++. Cette technique a été testée sur l’exemple du
système de communication présenté dans le chapitre 7 et a permis de constater une réduction
des temps de simulation d’un facteur 4 environ par rapport à l’utilisation d’une simulation
VHDL.
2.4 GENERATION DE CODE
Compte tenu de la solution décrite dans le paragraphe précédent, le problème de la
co-simulation devient un problème de génération de code. Il s’agit de transcrire le modèle
textuel MCSE en un langage cible (VHDL, C++). Pour réaliser cette transformation de textes,
le premier travail du développeur d’un générateur consiste en la définition des règles de
transcription. Ce travail pour le langage VHDL fait l’objet du chapitre 4. Ensuite, il s’agit de
choisir la technique à utiliser pour effectuer les transformations de textes. Dans les paragraphes
suivants, nous passons en revue différentes solutions. La solution retenue par l’équipe est
particulière et sera détaillée dans les chapitres 5 et 6.
Pour manipuler du texte, on peut utiliser des langages dédiés à la manipulation de texte ou
utiliser un générateur d’analyseur syntaxique.
2.4.1 Les langages dédiés à la manipulation de texte
Ces langages interprétés (Perl et awk par exemple) sont utilisés pour extraire des
informations d’un texte source et les reformatter. Contrairement à awk, Perl (Pratical
Extraction and Report Language) permet d’utiliser des hashtables très utiles pour trier et
rechercher des informations selon des mots clés.
Ces outils sont optimisés pour générer de la documentation à partir d’un modèle textuel. Par
contre, comme ils utilisent seulement un buffer de ligne (pas de structure interne complète de
stockage) et que l’accès au fichier source est séquentiel, ils sont peu appropriés pour notre
problème car les transformations sont complexes.
2.4.2 Technique des compilateurs
Les compilateurs de code utilisent un analyseur lexical et un analyseur syntaxique.
Le code source est décomposé en unités significatives appelées tokens. L’outil réalisant
cette décomposition en différentes unités s’appelle un analyseur lexical (ou scanner). Des
expressions régulières définissent les tokens à reconnaître et l’analyseur lexical est souvent
implanté par une machine à états finis.
Les relations possibles entre les différentes unités significatives d’un langage constituent
les règles grammaticales de ce langage. Une grammaire dite libre de tout contexte définit les
phrases correctes. La syntaxe d’entrée est souvent au format BNF (Backus Naur Form). L’outil
réalisant la vérification grammaticale d’un texte s’appelle un analyseur syntaxique (ou parser).
Le principe de fonctionnement est le suivant: l’analyseur lexical envoie une par une les unités
à l’analyseur syntaxique qui les stocke (utilisation d’une pile) jusqu’à ce qu’une règle
grammaticale soit complète. Par défaut, lorsqu’une règle est complétée, l’analyseur syntaxique
30
M.C.S.E
Méthodologie de co-design et estimation des performances
désempile les unités concernées et empile le symbole (ou unité) correspondant à la règle réduite
(on parle de réduction car le nombre d’éléments stockés dans la pile a diminué). A chaque
réduction de règle, on peut associer une action permettant par exemple de produire ou
compléter une structure de données: la structure de données est alors construite au fur et à
mesure de la vérification syntaxique. Elle se termine quand l’analyseur lexical n’émet plus
d’unités et que la pile de l’analyseur syntaxique est vide.
Les analyses lexicale et syntaxique ne constituent que la phase d’analyse d’un compilateur,
phase qui est ensuite suivie par une phase de synthèse pour la production du code cible. La
structure traditionnelle d’un compilateur est la suivante.
Langage Source
Analyse Lexicale (Scanner)
Analyse
(Front-End)
Analyse Syntaxique (Parser)
Structure de Donnée Interne (Parse Tree)
Analyse Sémantique
Optimisation de Code
Interpréteur
Génération de Code
Synthèse
(Back-End)
Langage Cible
-Figure 2.5- Structure traditionnelle d’un compilateur.
Généralement la structure de donnée interne s’appelle un "parse tree" ou encore
"intermediate code representation". Cette structure interne peut alors être interprétée (cas d’un
interpréteur) ou transcrite en un langage cible (cas d’un compilateur). L’outil MetaGen
présenté dans le chapitre 5 est capable de fonctionner dans les deux modes: interpréteur du
langage Script et compilateur du langage Script en code Java. Pour un compilateur classique,
elle est utilisée pour faire des contrôles sémantiques (vérification du type des opérandes par
exemple), une optimisation et une génération de code (optimisation du code, analyse du flot de
donnée et allocation des ressources).
Il existe dans les domaines universitaire et commercial un certain nombre d’outils qui
regroupent un générateur d’analyseur lexical, un générateur d’analyseur syntaxique et de
structure interne et une interface de programmation (API C/C++). On peut citer par exemple
PCCTS, SORCERER, Gentle Compile-Compiler et Eli Compiler Construction System
[GRAY-92]. Ces outils se distinguent par le format de spécification de la grammaire et
l’algorithme d’analyse syntaxique utilisé. Eli Computer Construction System est le plus
complet car il fournit également des outils pour les phases d’optimisation et de génération de
code.
M.C.S.E
31
Chapitre 2
Certains outils de ce type sont en plus capables de générer un éditeur orienté par la syntaxe.
C’est le cas de LEdit de Parallax et de Synthesizer Generator [REPS-88] de la société
GrammaTech.
2.4.3 Technique retenue pour la génération de code
La technique que nous avons développée pour la génération utilise un analyseur lexical et
syntaxique et repose sur deux concepts: le concept de méta-modèle et le concept de template.
Un méta-modèle est un modèle de modèle. Par exemple, le langage de définition de langage
Backus Naur Form (BNF) est un méta-modèle puisqu’il permet de spécifier des grammaires
qui constituent déjà un modèle de texte.
Le terme "template" représente ici un fichier écrit dans le langage cible souhaité et
contenant toutes les constructions nécessaires pour la translation texte à texte. Il s’agit d’un
modèle générique du résultat attendu.
La structure interne construite à partir d’un fichier texte par un analyseur syntaxique, est le
coeur du générateur à concevoir. Pour que notre générateur soit indépendant des langages
source et cible, il faut que cette structure soit construite selon un modèle générique. Nous avons
pour cela défini le méta-modèle de toute structure de données. La réponse a été trouvée tout
simplement dans le formalisme BNF. En effet, une grammaire se décrit elle même selon une
grammaire qui est alors appelée méta-grammaire. Or, le formalisme BNF spécifie une
grammaire uniquement à l’aide de quatre éléments de base que sont:
- la séquence d’éléments (Y := A B C),
- l’optionel (Y := [ A ]),
- l’alternative (Y:= A | B | C),
- la liste ou ensemble (Y := {A})
Dans la littérature sur la modélisation des données, on retrouve d’ailleurs sous diverses
formes, un modèle dit de composition hiérarchique basé sur les opérateurs de composition,
alternative et ensemble [CALVEZ-90]. Par analogie et pour la compréhension du lecteur, un
programme peut s’écrire uniquement à l’aide des trois structures de contrôle que sont la
séquence, l’itération et la sélection. On s’aperçoit que l’élément optionnel du méta-modèle de
donnée a disparu. Ceci est normal car le modèle de composition hiérarchique est le modèle
d’une structure de donnée qui est une instance de notre méta-modèle et pour laquelle l’élément
optionnel est remplacé soit par la valeur A soit par l’élément nul.
Dans un premier temps, notre principe de génération reposait uniquement sur les concepts
de méta-modèle et de template. Le principe était le suivant: Le générateur charge sous la forme
de structure interne le texte source et le fichier template. Puis, la production de la structure de
sortie consiste à parcourir la structure de données du modèle source, copier des parties de la
structure du template puis les mettre à jour. La figure 2.6 illustre le principe de génération de
code.
En prenant du recul par rapport à cette figure, nous avons pu trouver un principe général
applicable pour tous les générateurs de code ou même de texte. Il est possible de spécifier de
l’extérieur de l’outil les transformations à faire sur la structure de donnée interne pour obtenir
le résultat escompté en sortie. Pour cela, nous avons développé le concept de Script qui est un
langage de description des manipulations à effectuer sur les structures de données
32
M.C.S.E
Méthodologie de co-design et estimation des performances
[CALVEZ-98b]. Comme le script est un texte, il est à son tour analysé et chargé sous la forme
d’une structure de données. L’exécution du script est alors le résultat d’un automate de
parcours de la structure de données du script et d’exécution des opérations élémentaires qu’il
spécifie. Un générateur est donc le résultat de l’écriture d’un script fourni à un programme
(automate d’exécution). Nous avons appelé ce programme MetaGen. Il est décrit dans le
chapitre 5.
Modèle
Générique du code
à générer
Modèle
MCSE
Analyse
Syntaxique
Analyse
Syntaxique
Reverse-Coding
possible
Copie
Parcours
Ordonné
Analyse et
Transformation
Sauvegarde Ascii
Code
Généré
-Figure 2.6- Principe de la génération de code.
Le méta-générateur MetaGen est aussi capable de transcrire automatiquement le script
correspondant à un générateur en un programme JAVA équivalent. Cette possibilité est très
intéressante pour produire un générateur plus rapide que l’interprétation du script par le
méta-générateur. Le choix du langage JAVA pour l’implantation offre un certain nombre
d’avantages et notamment la garantie d’avoir un outil multi plate-forme.
Dans la plate-forme d’outils en cours de développement pour la méthodologie MCSE, le
modèle de performance de MCSE est ou doit être transcrit vers différents langages cibles:
VHDL comportemental ou C++ pour l’évaluation des performances (partitionnement et
co-simulation), VHDL de niveau RTL pour la synthèse matérielle et C avec l’emploi d’un
exécutif temps-réel pour la synthèse logicielle.
Comme tous ces générateurs utilisent le même modèle d’entrée et sont (ou seront) décrits
par un script, il est apparu judicieux de décomposer tous les scripts en une partie analyse du
modèle source et une partie génération. Le chapitre 6 sur le générateur VHDL pour les
performances décrit une partie analyse qui a été développée de façon suffisamment générique
pour qu’elle soit commune à tous les générateurs. La difficulté repose alors sur la sélection des
informations pertinentes pour la génération et le choix de l’emplacement des appels des règles
de génération. La qualité de la partie analyse est importante car elle conditionne la partie
génération et influe directement sur l’efficacité et la qualité d’écriture d’un générateur.
M.C.S.E
33
Chapitre 2
2.5 MODELISATION DES PERFORMANCES DES SYSTEMES
Les paragraphes qui suivent ont pour but de répondre à la question suivante: pourquoi avoir
défini un nouveau modèle de performance alors qu’il existe déjà un éventail assez large de
modèles de performance? Nous commencerons par décrire les principaux modèles de
performances existants et les outils les plus représentatifs qui leur sont associés. Puis pour
conclure, nous justifierons le développement d’un nouveau modèle de performance lié à la
méthodologie MCSE et approprié à la problématique du co-design.
2.5.1 Catégories de modèles de performance
Tout modèle est construit sur la base d’un ensemble de concepts de modélisation.
L’efficacité d’un modèle dépend directement de ces concepts: l’ensemble des concepts de
modélisation doit être restreint mais suffisant pour décrire n’importe quel système pour le
domaine concerné. Pour mieux interpréter les différences existant entre les modèles de
performance qui vont être présentés dans ce chapitre, considérons l’espace de modélisation
tri-dimensionnel représenté par la figure 2.7 [CALVEZ-96d].
Interprétation
interprété
non-interprété
Comportement
Structure
Donnée/Objet
Représentation
Abstrait
Spécification
niveau fonctionnel
1
niveau architectural
2
niveau physique
Concret
Niveaux de description
-Figure 2.7- Espace de modélisation des systèmes.
La classification des modèles pour les systèmes électroniques se fait selon trois axes:
- l’axe des niveaux de description, qui représente les degrés d’abstraction possibles pour
la description des solutions intermédiaires entre le besoin et le produit final. Les niveaux
habituellement considérés sont: le niveau système ou spécification, le niveau
fonctionnel, le niveau architectural, le niveau logique et/ou physique,
- l’axe de représentation, qui considère les différents types de modèles utilisables pour
la description. Trois modèles, chacun exprimant un point de vue, sont usuels : le modèle
structurel, le modèle comportemental, et le modèle donnée ou objet,
- l’axe d’interprétation, qui représente le niveau de détail du modèle.
34
M.C.S.E
Méthodologie de co-design et estimation des performances
Une séparation nette apparaît sur l’axe Interprétation entre :
- les modèles non-interprétés pour lesquels seul le comportement ou les dépendances
temporelles entre les sorties et les entrées sont observées. Les valeurs en entrée et celles
des données internes ne sont pas prises en compte. Les entrées et les données internes
influencent le comportement du système uniquement par l’intermédiaire d’attributs. Par
exemple, les attributs Size (taille) et Id (destinataire) d’un message remplace le contenu
du message.
- et les modèles interprétés pour lesquels les valeurs des données sont considérées. Ces
modèles décrivent un comportement fonctionnel représenté le plus souvent sous la
forme d’un flot de données et d’un flot de contrôle.
La zone grisée de la figure 2.7 correspond à la zone de modélisation que nous estimons utile
pour l’évaluation des performances. Un modèle approprié pour l’évaluation des performances
est de type non-interprété. Il doit associer la vue structurelle pour représenter la décomposition
ou l’organisation du système et la vue comportementale pour décrire les propriétés temporelles
de chaque constituant.
Sur la figure 2.7, il y a également une séparation nette entre un modèle de structure et un
modèle de comportement. Le premier est une description spatiale ou topologique du système.
Le second est une description temporelle. Pour modéliser un système complexe, les deux types
de modèle sont nécessaires et complémentaires. De plus, un modèle de comportement peut se
remplacer par un modèle de structure lors d’une opération de raffinement et réciproquement un
modèle de structure peut se remplacer par un modèle de comportement lors d’une opération
d’abstraction. Dans le formalisme utilisé par la méthodologie MCSE, la vue structurelle
regroupe la vue fonctionnelle et la vue architecturale ou exécutive.
Enfin, un modèle de performance peut être élaboré et utilisé pour trois niveaux de
description: les spécifications (étude de faisabilité), la conception fonctionnelle
(dimensionnement des éléments internes du système) et la conception architecturale (aide au
partitionnement logiciel/matériel).
Selon l’approche de modélisation que doit faire le concepteur, les modèles de performances
peuvent être classés en deux catégories:
- le modèle de flot de transaction basé sur la modélisation des files d’attentes et/ou les
réseaux de Petri: modèle UVa, SES/WorkBench, Bones... Ces modèles ont l’avantage
de s’appuyer sur un formalisme mathématique qui dans certains cas permet d’extraire
des informations sans qu’une simulation dynamique soit nécessaire.
- le modèle d’architecture: RD100, Cosmos de Omniview appelé encore récemment
Performance Modeling WorkBench. Le modèle UVa est aussi un modèle d’architecture
mais il s’appuie également sur le formalisme des réseaux de Petri pour le comportement
de chaque bloc.
2.5.2 Modélisation par réseau de files d’attente
Le modèle basé sur la théorie des files d’attente [BORDEW.-93] se compose:
- d’une source d’événements ou jetons (source) caractérisée par une distribution
(Uniforme, Normale, Erlang, Poisson, etc...),
- une file d’attente caractérisée par sa taille et sa discipline de stockage (LIFO, FIFO),
M.C.S.E
35
Chapitre 2
- des serveurs caractérisés par un temps de service (fixe, uniforme ou exponentiel),
- des mécanismes de synchronisation: la divergence (fork) caractérisée par une loi de
distribution et le regroupement (join).
- d’un mécanisme d’élimination du jeton (sink).
La figure 2.8 représente un exemple de modélisation d’une architecture de processeurs
distribuée [MOHANTY-94].
-Figure 2.8- Modélisation par réseau de files d’attente d’une architecture parallèle.
Dans ce modèle, un utilisateur est représenté par une transaction (ou jeton) qui accède au
processeur par l’intermédiaire d’une file d’attente. Le nombre d’utilisateurs est fixe et doit être
inférieur à la taille des files d’attente. Une fois que le processeur a effectué le travail désiré, la
transaction accède aléatoirement à l’un des deux disques du système modélisés comme le
processeur par la combinaison d’une file d’attente et d’un noeud de service. Puis la transaction
passe par un service d’affichage (probabilité p) ou retourne directement au début du réseau.
Ce type de modélisation permet d’obtenir le taux d’utilisation des processeurs, la taille
moyenne des files d’attente, le temps moyen de service, le temps moyen d’attente pour un
service, le temps total passé par une transaction dans le système, etc.
2.5.3 Réseau de Petri stochastique
Ce modèle est également basé sur un principe de jetons: une transition n’est franchissable
que si toutes les places précédentes possèdent au moins 1 jeton, et lorsqu’elle est franchie, un
jeton est retiré de toutes les places en amont et un jeton est ajouté dans toutes les places en aval.
Il permet donc de contrôler les cycles, de détecter l’existence de blocages éventuels et de
s’assurer que tous les états sont atteignables. Pour étendre l’usage des réseaux de Petri
classiques à l’évaluation de performances temporelles, un paramètre temps leur a été associé:
- soit au niveau des transitions, ce qui permet alors d’exprimer l’intervalle temporel
d’exécution de la transition.
- soit au niveau des places. Dans ce cas, une transition n’est franchie que si toutes les
places précédentes sont marquées et si le temps associé à chacune est écoulé.
Les réseaux de Petri ont donc été étendus (Extended Timed Petri Net) avec un attribut de
durée pour faciliter l’étude du comportement temporel d’un système. Lorsque cette durée
dépend d’une loi aléatoire, le réseau de Petri est appelé réseau de Petri stochastique.
36
M.C.S.E
Méthodologie de co-design et estimation des performances
Une approche de modélisation, d’évaluation des performances et de co-synthèse des
systèmes matériel/logiciel basée sur l’utilisation des réseaux de Petri étendu (ETPN) est
présentée dans [STOY-94]. Les réseaux de Petri représentent le flot de contrôle et le flot de
données des parties matérielles et logicielles. La simulation des réseaux de Petri permet de
vérifier le respect des contraintes temporelles et de faire une évaluation des performances du
système. Cette évaluation des performances est alors utilisée par une heuristique et une
fonction de coût pour réaliser le partitionnement matériel/logiciel. Puis, un outil de synthèse
haut niveau nommé CAMAD transforme les réseaux de Petri en une netlist pour l’implantation
en matériel et en un programme C pour l’implantation en logiciel. Le nombre d’états et de
transition croit très rapidement en fonction de la complexité du système étudié. L’approche
proposée par Stoy est donc surtout intéressante pour les systèmes de faible complexité.
Les deux modèles précédents s’appuient sur un formalisme mathématique qui peut devenir
rapidement complexe lorsque la taille de l’application augmente. De plus, l’évaluation
analytique n’est possible que sur une classe limitée de systèmes et ne permet pas d’analyser
correctement ou facilement un certain nombre de constructions tels que:
- les politiques d’ordonnancement avec priorité,
- les ressources passives (disques, mémoire),
-
les mécanismes de synchronisation (join, fork),
- les protocoles de communications complexes (et non une simple transition de jeton),
- les interruptions,
- les requêtes d’accès simultanés à une ressource.
C’est pourquoi, la plupart des outils d’analyse de performances basés sur ces modèles
utilisent principalement la simulation et non l’évaluation analytique pour faire une estimation
des performances. Il existe de nombreux outils spécifiques aux réseaux de files d’attente et/ou
aux réseaux de Petri stochastiques: TimeNet [KELLING-95], QNAP2, Bones, SimScript. Ces
outils se composent généralement d’une interface graphique pour la modélisation et
l’animation des réseaux, d’un langage algorithmique de haut niveau pour décrire le
comportement de certains noeuds et d’un générateur de code automatique à partir de la
description graphique et algorithmique. Basé uniquement sur un flot de transaction ou jeton,
ces modèles sont moins appropriés que les modèles d’architecture pour étudier les
performances d’un partitionnement logiciel/matériel car ils ne permettent pas de représenter la
vue structurelle du système.
2.5.4 Modélisation d’architectures
Ces modèles permettent de décrire un système selon deux vues:
- une vue structurelle qui décrit le système sous la forme d’une interconnexion de
constituants,
- une vue comportementale qui permet de décrire le comportement de chaque constituant.
Des attributs sont associés aux constituants et aux éléments de description
comportementale pour permettre l’étude du comportement temporel du système.
Le modèle d’architectures est un modèle naturel pour le concepteur. Offrant une séparation
plus nette entre la partie matérielle et logicielle du système, il est aussi mieux adapté au
M.C.S.E
37
Chapitre 2
co-design que le modèle de transactions qui est surtout utilisé pour l’analyse de solutions
existantes.
2.6 PANORAMA DES MODELES ET OUTILS DE PERFORMANCES
Dans ce paragraphe, nous présentons succinctement les outils les plus représentatifs ou les
plus utilisés des modèles de flot de transactions et d’architectures. Pour chaque outil de cette
liste non exhaustive, on s’intéresse plus aux propriétés des modèles de performances
considérés qu’aux caractéristiques de l’outil support.
2.6.1 SES/Workbench
SES/workbench est un environnement de simulation vendu par SES (Scientific and
Engineering Software Inc). Il permet de modéliser des systèmes complexes et de faire une
évaluation des performances [SES-89].
Le modèle est spécifié graphiquement par une hiérarchie de graphes composés d’un
ensemble de noeuds auquels on peut éventuellement associer une forme graphique et des
méthodes écrites en C. Le principe de description repose sur l’évolution d’une transaction à
travers les divers noeuds d’un graphe.
Un ensemble de librairies de noeuds prédéfinis est disponible. Une des librairies dédiée à
l’analyse de l’architecture des systèmes regroupe des noeuds pour modéliser:
- la gestion de ressources: service, ressource, retards, allocation et désallocation, etc. Le
noeud de service est constitué d’une file d’attente et d’un temps de traitement. Comme
il est possible de définir la politique d’ordonnancement des transactions (préemptif,
non-préemptif, temps partagé,...) et le temps de commutation (overhead), ce type de
noeud permet de modéliser un processeur logiciel ou une ressource active. Le noeud de
ressource (réservoir de jeton) permet de modéliser une ressource passive telle qu’une
mémoire, un bus, etc.
- le contrôle du flot de transactions: source, destruction, boucle, divergence, jonction,
interruption, reprise d’activité, etc.
Pour illustrer le modèle, la figure 2.9 décrit un exemple qui montre clairement que la
description suit le chemin parcouru par une transaction.
Destruction
Réference
not finished
New_Work
Get_memory
Exec
Disk1
End_Work
-
+
Release_memory
Cpu
Source
Désallocation
Allocation
Service
Disk2
Rafinement
-Figure 2.9- Exemple de modélisation sous SES/Workbench.
38
M.C.S.E
Méthodologie de co-design et estimation des performances
La technique d’évaluation repose sur l’exécution d’un programme en C++ généré à partir
des descriptions graphiques et algorithmiques du modèle. L’outil permet d’animer la
modélisation (flot de transactions) et de générer (API et langage de requêtes) des rapports
statistiques (valeur min, max, moyenne, histogramme de fréquence,...) sur les performances
des divers noeuds du modèle.
Romdhani [ROMDHANI-96] a utilisé SES/Workbench pour faire une évaluation des
performances dynamiques d’un système lors d’un partitionnement matériel/logiciel. Il
modélise en parallèle un flot de données (axe fonctionnel) décrivant les transformations sur les
données et un flot de contrôle décrivant les ressources utilisées (axe architectural). La
synchronisation entre les deux flots est réalisée à l’aide de noeuds du type "Interrupt Node" et
"Resume Node". Le système est alors décrit sous la forme d’une partie opérative et une partie
contrôle dans lesquelles la vue fonctionnelle et la vue architecturale sont complètement
amalgamées. Par conséquent, même si l’architecture matérielle cible est figée, une
modification de l’allocation d’une fonction nécessite au minimum de redessiner le flot de
données, ce qui est plutôt contraignant lorsque l’on doit parcourir un domaine assez vaste des
solutions possibles.
Le modèle de SES/wokbench est plus riche en concepts de modélisation que le modèle de
performance que nous avons développé. A ce titre, il est capable de modéliser n’importe quel
modèle de performance MCSE. Mais la différence essentielle entre les deux modèles réside
dans l’approche de modélisation. SES/workbench est orienté flot de transactions: le concepteur
décrit explicitement le chemin suivi par chaque transaction et les ressources qu’elle utilise.
L’absence de dimension structurelle stricte (zone 2 de la figure 2.7) a au moins deux
conséquences. En premier, la méthode de modélisation est différente de celle utilisée par les
concepteurs en co-design (description du modèle fonctionnel, puis du modèle architectural et
allocation), ce qui implique un surcoût de temps pour exploiter les concepts de SES et obtenir
les résultats appropriés. En second, il n’y a pas continuité du modèle d’une phase de conception
à l’autre: un nouveau modèle doit être réécrit à chaque étape de conception. En effet, avec ce
modèle, la description d’une phase de conception ne peut pas être enrichie ou détaillée en
remplaçant le modèle comportemental d’un composant par son raffinement structurel. L’outil
est donc très efficace pour faire une analyse des performances d’un système figé ou existant,
mais convient nettement moins pour une démarche de modélisation incrémentale et pour
l’exploration du domaine des solutions possibles lors d’un partitionnement logiciel/matériel.
Sous l’impulsion du projet RASSP, SES/Workbench est maintenant capable de générer du
code C et du code VHDL. L’outil offre aussi une interface de co-simulation appelée SES/
Co-sim. Elle permet au simulateur de SES/Workbench de communiquer avec n’importe quel
autre processus unix externe (simulateur par exemple). L’interface définit les données à
échanger et le mode de synchronisation.
2.6.2 Le modèle UVa/ADEPT
SES/Workbench et ADEPT sont relativement proches car ils sont tous les deux basés sur
un principe de modélisation par flot de transactions.
M.C.S.E
39
Chapitre 2
Le modèle UVa est présenté dans [AYLOR-92]. Il génère un programme VHDL simulable
à partir d’un ensemble de blocs prédéfinis ou composants spécialisés. Ces blocs ont chacun un
comportement décrit par un réseau de Petri écrit en VHDL. L’interconnexion entre ces blocs
se fait par un passage de jeton selon un protocole de communication du type rendez-vous. Une
couleur est associée au jeton. Ce concept de couleur caractérise le modèle comme étant non
interprété et est proche du concept d’attribut associé aux échanges d’information de notre
modèle MCSE.
Pour l’évaluation des performances, les blocs prédéfinis sont classés en trois groupes
principaux. Il y a tout d’abord les modules de contrôle (19 différents): ils agissent uniquement
sur l’état du jeton. Il y a par exemple les “Source”, les “Sink”, les “Switch” ou les "Junction".
OUT_1 IN_1
OUT_1
SO
SW
Source
IN_1
IN_C1
Switch
OUT_1
IN_1
Signaux de données
J
IN_2
SI
Signaux de contrôle
Sink
Junction
-Figure 2.10- Exemple de modules de contrôle du modèle UVa.
Il y a ensuite les modules de gestion des couleurs (9). Ils n’agissent que sur la couleur:
lecture, modification, comparaison, addition et soustraction. Il y a par exemple les modules
“Read Color”, “Set Color” ou “Comparator”.
OUT_1
IN_1
OUT_1 IN_1
IN_1
RC
Read Color
SC_D
OUT_C
Set Color
IN_2
CP
IN_C
Comparator
OUT_C
-Figure 2.11- Exemple de modules de gestion des couleurs.
Il y a enfin les modules Délais (4). Il y a par exemple “Fixed Delay” qui fournit toujours le
même retard, “Dependent Delay” qui introduit un délai dépendant de la couleur du jeton et
“Random” qui introduit des délais aléatoires.
IN_1
OUT_1
IN_1
OUT_1
IN_1
OUT_1
FD
DD
R
Fixed Delay
Dependent Delay
Random
-Figure 2.12- Exemples de modules de Délai.
La plupart des blocs ont un comportement non-interprété. Mais le modèle comporte aussi
des blocs d’analyse de fautes (13), de collecte d’informations (4), et des blocs hybrides (7) qui
permettent de connecter au modèle des descriptions comportementales (modèle interprété).
Ainsi, le modèle UVa permet d’analyser la tolérance aux fautes et la sûreté de fonctionnement
d’un système. La description d’une architecture avec ce modèle se fait à l’aide d’un outil
ADEPT [KUMAR-94] basé sur l’utilisation d’outils graphiques de CAO (Mentor Graphics
Design Architect). La vérification fonctionnelle et l’évaluation des performances est faite par
simulation du programme VHDL. Les possibilités d’évaluation sont importantes car il est
possible d’observer l’état de chaque bloc et de chaque jeton.
40
M.C.S.E
Méthodologie de co-design et estimation des performances
Le modèle est surtout un modèle structurel (zone 2 de la figure 2.7). La description se fait
à un niveau d’abstraction beaucoup moins élevé que celui des spécifications et des descriptions
comportementales. Par conséquent, le concepteur doit faire un effort important pour trouver
l’architecture basée sur les blocs disponibles même s’il veut simplement analyser un système
à un niveau fonctionnel abstrait. La comparaison avec notre modèle de performance est
similaire à la distinction qui existe entre la description comportementale de haut-niveau d’un
circuit et sa description architecturale basée sur des registres, additionnneurs, compteurs, etc.
Par exemple, dans [KUMAR-94], l’auteur présente la modélisation d’un cache mémoire qui a
nécessité pas moins de 2000 blocs.
A notre point de vue, un modèle non accompagné d’une démarche favorisant l’élaboration
de solutions n’est pas suffisant. Récemment, l’université de Virginie a pris conscience de la
nécessité d’avoir une démarche système: "a local optimization made at the structural level of
Design may have a detrimental effect on overall system performance" [KUMAR-96]. Elle a
alors développé une méthodologie complète de conception appelée ISPME (Integrated
Specification and Performance Modeling Environment). Cette méthodologie repose sur
l’association du modèle de "StateChart" pour couvrir les phases de spécification et conception
fonctionnelle et du modèle UVa pour la conception architecturale et l’évaluation des
performances. L’utilisation de modèles hybrides a pour but de faciliter la transition d’une phase
de conception à une autre.
Pour mieux répondre à la problématique du co-design et du partitionnement logiciel/
matériel, le modèle UVa a également été enrichi du concept de machine virtuelle
[KUMAR-92] [KUMAR-96] dont le principe est schématisé par la figure suivante.
F
FALSE
TRUE
N
FALSE
TRUE
N
E
L
E
M
E
N
T
S
Machine Virtuelle
MEMOIRE
D
E
F
F
F
Modèle logiciel
R
O
U
T
A
G
E
EXECUTE1
Delai
FETCH
EXECUTEN
Modèle matériel
-Figure 2.13- Principe de co-simulation avec le modèle UVa.
Pour modéliser l’exécution du logiciel sur un processeur, le modèle UVa a été enrichi de
noeuds de process représentant une transformation sur les données et de noeuds de
branchement conditionnels. Chaque bloc F utile pour modéliser l’aspect fonctionnel possède
une entrée/sortie supplémentaire pour l’asservir à un noeud de ressource.
La machine virtuelle représentant le processeur logiciel est composée d’un étage de
recherche et décodage d’instruction, d’une mémoire de stockage et d’un ensemble de branches
d’exécution. Le nombre de flots d’exécution représente le degré de parallélisme du processeur.
Une branche est un flot d’exécution composé de noeuds de ressource qui peuvent être actifs
M.C.S.E
41
Chapitre 2
(noeud de service avec file d’attente) ou passifs (unité arithmétique et logique). La machine
virtuelle permet donc l’exécution simultanée de plusieurs tâches ou opérations logicielles.
Mais, les délais d’attente ne sont pas préemptibles et il n’y a pas d’ordonnanceur associé à la
machine virtuelle, ce qui réduit son intérêt pour les modélisations multi-tâches.
L’université de Virginie et Honeywell Technology Center ont travaillé en commun sur
l’évaluation des performances dans le cadre du projet RASSP. Un couplage entre les deux
modèles de performances a été réalisé: les blocs hybrides [KUMAR-97] permettent en effet de
relier le modèle UVa avec le modèle de performance de Honeywell Technology Center qui fait
partie de l’outil Cosmos de Omniview.
2.6.3 RDD 100
RDD100 est un outil de la société Ascent Logic Inc [ALFORD-91] [ALFORD-92]. Il
permet la saisie du cahier des charges, l’élaboration des spécifications, l’analyse fonctionnelle
et la décomposition physique des systèmes. L’outil a d’abord été développé pour décrire et
évaluer les spécifications d’un système dans le domaine de l’ingénierie système. Bien connu
dans ce domaine d’application, il a ensuite été enrichi pour couvrir la phase de conception
fonctionnelle (modèle interprété) et la phase de définition de la réalisation comportant la
définition de l’architecture matérielle et l’allocation des éléments fonctionnels sur cette
architecture. Basé sur différents formalismes, il a été développé en tenant compte de
recommandations et standards de principe d’ingénierie système tel que la norme IEEE1220.
Un des points caractéristiques de cet outil est son efficacité de gestion de la traçabilité
d’une exigence des spécifications jusqu’aux tests d’implantation [PENCOLE-96]. Cette
efficacité est due à la base de données de RDD100 construite sur le modèle
Entité-Relation-Attributs (ERA). Ce modèle de description permet de représenter l’application
en terme d’entités, leurs attributs et les relations (ou associations) entre ces entités. Une entité
est un objet conceptuel pour le système. Il peut s’agir d’un objet physique ou fonctionnel. Les
entités sont regroupées par type d’entités (catégorie). Chaque type d’entité possède ses propres
attributs (ou propriétés), qui permettent de différencier les entités entre elles.
-A- Analyse des exigences et Spécification
Le modèle ERA est bien adapté pour décrire les constituants d’un système. Pour faciliter la
description du comportement du système vis à vis de son environnement, le modèle ERA de la
base de données a été enrichi avec les concepts de l’approche objet, tel que:
- l’agrégation (démarche ascendante)/décomposition (démarche descendante) qui permet
éventuellement de définir des structures récursives,
- la généralisation/spécialisation derrière laquelle se trouve la notion d’héritage.
Les entités peuvent être représentées selon plusieurs vues (saisie graphique et textuelle). La
cohérence entre les différentes vues est gérée par l’outil de manière transparente pour
l’utilisateur. Le formalisme utilisé est proche de celui de la méthode OMT ou plutôt de la
méthode unifiée puisque lors de l’analyse fonctionnelle on retrouve également un concept
proche de celui du concept de scénario (ou Use Cases au sens de Jackobson) qui permet
d’associer un comportement ("Behavior Diagram") aux entités (ou objets).
-B- Analyse fonctionnelle
Pour réaliser une analyse fonctionnelle, 3 points de vue sont à considérer: le point de vue
structurel (topologie du système), le point de vue des données (flot de donnée) et le point de
42
M.C.S.E
Méthodologie de co-design et estimation des performances
vue comportement (évolution temporelle ou flot de contrôle). RDD100 permet de représenter
simultanément ces trois points de vue en un seul diagramme appelé "Behavior Diagram". Un
"Behavior Diagram" est constitué d’un ensemble de fonctions. Les fonctions consomment et
produisent des données. Elles peuvent s’exécuter en séquence ou en parallèle. Les
constructions de type itération, boucle, sélection, réplication, décomposition, agrégation sont
autorisées.
Parmi les données échangées, on trouve les messages et les variables d’état. Les messages
permettent de contraindre l’activation d’une fonction et donc de contrôler son comportement.
Les variables d’état permettent de mémoriser l’état d’une fonction.
Le figure 2.14 représente un exemple simple de modélisation. Sur cette figure deux
fonctions commencent leur exécution simultanément. La fonction A envoie un message M. La
fonction B en attente du message M commence alors son exécution. Une file d’attente est
associée aux messages d’entrée d’une fonction. La taille de cette file d’attente peut varier de 0
(Rendez-vous) à l’infini. Ce modèle de comportement est relativement proche de celui du
modèle MCSE où l’on retrouve les concepts de fonctions et de port de communication.
a) Diagramme de comportement
&
Partition et
Allocation
b) Architecture matérielle
CC1
M
Function A
ProcProd
Function B
ProcCons
&
Flot de données
Evolution
Temporelle
-Figure 2.14- Exemple de modélisation sur RDD100.
-C- Analyse architecturale
La description de l’architecture matérielle permet de déclarer les ressources (mémoire,
processeur...) puis l’allocation des fonctions de manière à identifier les interfaces et donc les
supports physiques de transmission pour les messages.
-D- Evaluation des performances
Pour faire une évaluation des performances, l’utilisateur peut affecter des temps de
traitements aux fonctions. Une ressource active est caractérisée par sa puissance qui intervient
comme un facteur multiplicatif de la durée de traitement d’une opération et son degré de
concurrence. Un support de communication est caractérisé par sa capacité et chaque message
par sa taille.
La simulation des modèles saisis repose sur la génération et l’exécution d’un programme
Smalltalk. L’outil permet de présenter les résultats sous la forme d’un déroulement temporel
M.C.S.E
43
Chapitre 2
ou "TimeLine" qui permet de visualiser l’état des fonctions et la trace des messages. On peut
également visualiser l’évolution temporelle du taux d’occupation d’une ressource.
Le nombre réduit d’attributs associés à une ressource active limite l’intérêt de ce modèle
pour l’évaluation d’un partitionnement matériel/logiciel et la co-simulation: il n’est pas
possible de définir la politique d’ordonnancement car une ressource active est non préemptible,
le temps de commutation de tâches est nulle, etc. Après allocation, le concepteur doit aussi
redessiner un modèle pour faire apparaître explicitement les fonctions d’interfaces matériel/
logiciel.
L’outil RDD100 est l’outil central d’un ensemble d’outils intégrés pour l’ingénierie des
systèmes utilisé dans le projet RASSP [FRY96]. Il est complété par l’outil Price System pour
l’analyse de coûts et les outils RAM-ILS (Reliability, Availability, Maintainability, Integrated
Logistic Support) pour l’analyse de la sûreté de fonctionnement, la fiabililité et la
maintenabilité d’un système. Actuellement, cette intégration d’outils permet de couvrir toutes
les phases de développement d’un système et de faire du suivi de projet (gestion des ressources
humaines, analyse des risques, des coûts et des délais) [ALFORD-93].
2.6.4 COSMOS
L’outil COSMOS de la société Omniview exploite une modèle de représentation d’un
système composé de deux vues [OMNIVIEW-97]:
- une vue matérielle qui correspond à une version simplifiée du modèle exécutif ou
architectural de MCSE,
- une vue logicielle qui correspond à une association simplifiée de la vue fonctionnelle et
la vue comportementale de MCSE. L’outil COSMOS n’est en effet pas capable de
modéliser le comportement d’une fonction implantée en matériel puisque la vue
logicielle ne permet de décrire que le comportement de tâches logicielles.
La figure ci-dessous montre différentes vues de l’outil Cosmos.
Tache
Periodique
File d’attente
Matrice d’interconnection
Bloc raffiné
a) Modèle logiciel
b) Modèle matériel
-Figure 2.15- Exemple de modélisation sous Cosmos.
-A- Représentation de la vue matérielle
La saisie du modèle d’architecture matérielle graphique et hiérarchique repose sur
l’interconnexion de blocs et l’utilisation d’une librairie VHDL (modèle de performance de
Honeywell Technology Center) dont les composants sont paramétrables. Cette librairie
contient les modèles de performances de 4 types d’éléments: les processeurs, les mémoires, les
44
M.C.S.E
Méthodologie de co-design et estimation des performances
éléments de communication et les éléments d’Entrée/Sortie [ROSE-95]. Les blocs
décomposables peuvent avoir plusieurs raffinement possibles.
L’élément clef, c’est à dire le processeur, est défini par son jeu d’instructions. Un
ordonnanceur est associé à chaque processeur et permet de modéliser du multi-tâches
[ROSE-96]. Chaque instruction est définie par le nombre de cycles et le nombre d’accès
mémoire nécessaires à son exécution. L’instruction simple ou multiple peut être définie
préemptive et dans ce cas il faut aussi définir les temps de préemption et de réallocation. Les
accès à la mémoire inclut le chargement de l’instruction (fetch) et les accès en lecture et/ou
écriture de l’instruction. Chaque instruction peut utiliser jusqu’à 3 bancs mémoires différents.
Ces bancs mémoires sont caractérisés par leur temps d’accès et l’utilisation ou non d’un cache.
Chaque cache est défini par un temps d’accès et son taux nominal d’utilisation utile pour
déterminer si un accès mémoire se fera avec ou sans cache (tirage aléatoire ou valeur
moyenne). Pour accélérer la simulation du modèle logiciel, l’outil calcule le temps total
nécessaire à l’exécution d’une instruction. Il commence par calculer le nombre de cycles
nécessaires aux accès mémoire en tenant compte de l’utilisation éventuelle d’un cache et
additionne ce résultat aux cycles de l’instruction. Le modèle ne modélise pas un étage de
pipeline d’instructions. Mais un étage de pipeline d’instructions a moins d’influence sur les
performances du processeur que la modélisation d’un cache mémoire et la prise en compte des
interruptions: "Caches affect CPU performance even more than pipelining within the execution
unit. Interrupt latency, the time required for the CPU to execute the first instruction of a
interrupt handler after an interrupt is raised can significantly affect performance."
[WOLF-94].
La communication entre les différents éléments (blocs et composants) d’une architecture
matérielle se fait par transition d’un jeton. Le concept de jeton est ici très proche du jeton du
modèle UVa puisqu’il s’agit d’une donnée non interprétée caractérisée par un certain nombre
d’attributs tels que priorité, taille, source, destination, date de création, etc.
Pour pouvoir analyser le modèle d’architecture seule, il faut injecter des jetons dans
l’architecture matérielle. C’est le rôle des sources de jetons ("InputDevice") qui définissent le
destinataire du jeton, sa taille et son débit. La taille et le débit peuvent être fixes ou tirés
aléatoirement selon des distributions uniformes, gaussiennes, de poisson, etc. Par dualité, il
existe aussi des consommateurs de jetons ("OutputDevice") et des réflecteurs de jetons. Les
réflecteurs (disques, mémoire, pipeline, file d’attente) de jetons retournent un jeton après un
certain délai. Enfin, comme pour le modèle UVa, des opérateurs de contrôle du flot de jetons
tel que les divergences ("split"), les convergences ("join") et les matrices d’interconnexions
("crossbar") sont disponibles. Les producteurs et consommateurs de jetons sont très utiles pour
modéliser l’environnement du système à étudier.
-B- Représentation de la vue logicielle
Il s’agit d’un modèle de process communicants. Les process qui ne sont pas raffinés sont
décrits sous la forme d’une tâche. Il y a 2 types de tâches: les tâches périodiques et les tâches
apériodiques en attente de l’occurrence d’un message.
La communication entre tâches se fait par transfert de messages qui englobent un jeton et
via une file d’attente. La file d’attente chargée de gérer l’ordre et la priorité des messages est
caractérisée par sa taille et sa politique de gestion des messages (ordre d’arrivée, taille du
message, priorité fixe, date de création...). Le protocole d’envoi de message peut être du type
port à N places ("loosely coupled") ou du type rendez-vous ("highly coupled"). Pour une tâche
M.C.S.E
45
Chapitre 2
périodique, l’attente de message n’est pas strictement bloquante: La tâche périodique
recommence son cycle même si elle est en attente d’un message et qu’elle n’a pas reçu ce
message durant la période d’activation.
Les tâches ont un comportement purement séquentiel. Ce comportement est décrit sous la
forme d’un diagramme de flot ou sous le forme d’un programme VHDL saisi manuellement
par l’utilisateur (utilisation d’un ensemble de primitives prédéfinies). Le diagramme de flot est
plutôt un diagramme de flot de contrôle qu’un diagramme de flot de données. Le diagramme
de flot se compose en effet d’opérateurs de branchement conditionnel, d’itération, de point de
sortie et de blocs de code constitués d’une séquence d’instructions saisie avec un éditeur
orienté par la syntaxe. Graphiquement, on ne peut pas parler de flot de données puisque
l’attente et la génération de messages se font par des instructions de code saisies manuellement.
Un bloc de code est aussi constitué d’instructions du jeu d’instruction du processeur.
Tout comme pour l’architecture matérielle, on peut analyser la vue logicielle seule.
-C- Allocation
L’outil ne se contente pas d’aider le concepteur à optimiser les performances des parties
matérielle ou logicielle séparément. Il permet aussi d’allouer les tâches logicielles sur les
processeurs matériels et par une démarche itérative basée sur une évaluation des performances,
de trouver la meilleure répartition des tâches entre les différents processeurs.
Le modèle d’architecture permet de modéliser des processeurs matériels (ASIC et FPGA)
mais ne permet pas d’allouer des éléments du modèle logiciel sur ces processeurs. Ainsi, l’outil
ne permet pas d’explorer le domaine des solutions possibles d’un partitionnement logiciel/
matériel. Il permet uniquement de trouver la meilleure répartition des tâches logicielles entre
les différents processeurs logiciels.
-D- Analyse des résultats
L’outil permet d’animer les modèles
graphiques, ce qui permet d’avoir une vue
globale des ressources matérielles critiques. La
visualisation des résultats se fait sous la forme
d’histogrammes (temps de latence, débit, taux
d’utilisation) ou sous la forme d’un diagramme
temporel qui permet d’observer les temps
d’exécution des différents tâches d’un
processeur. Le diagramme de déroulement
temporel est assez limité car il ne représente que
l’état actif d’une tâche. On ne sait pas si la tâche
est bloquée en attente d’un message, prête à être
exécutée mais en attente du processeur ou bien
inactive. Il ne représente pas les émissions de
messages. Il ne permet pas de mesurer les temps
de réponse. Enfin, il ne facilite pas la
compréhension des dépendances d’activation
entre tâches et la recherche des éventuels
problèmes d’ordonnancement (non respect de
contrainte de temps, interblocage)
46
-Figure 2.16- Déroulement temporel.
M.C.S.E
Méthodologie de co-design et estimation des performances
2.6.5 Bilan
En conclusion de cette analyse de l’existant, on peut affirmer que la plupart des modèles de
performance ne sont pas complètement appropriés pour la problématique du co-design car les
modèles recensés ne distinguent pas précisément la vue fonctionnelle et la vue exécutive. Or
une séparation nette entre ces deux vues s’avère indispensable pour explorer facilement
l’espace des solutions possibles pour l’architecture exécutive et pour le partitionnement
matériel/logiciel. Avec le modèle de performance de MCSE qui nous présentons en détail dans
le chapitre 3, le concepteur n’a pas besoin de définir un modèle différent pour chaque
alternative du partitionnement. Il doit juste redéfinir l’allocation des éléments fonctionnels sur
les éléments de la structure exécutive (mapping).
Les modèles de performances existants (Ses/Workbench, UVa) ont surtout été developpés
pour faire l’analyse des performances de systèmes existants alors que le modèle de
performances de MCSE a été développé pour répondre à la problématique du partitionnement
matériel/logiciel. Il est en effet basé sur deux vues complémentaires et orthogonales: la vue
structurelle et la vue comportementale. Le modèle de la vue structurelle est utilisé pour
représenter l’architecture du système selon les 2 niveaux fonctionnel et exécutif (ou
architectural). Le modèle comportemental spécifie le séquencement temporel d’un ensemble
d’opérations et d’activités. Il s’agit d’un modèle graphique où l’axe vertical représente
l’évolution temporelle et l’axe horizontal le flot de données. Les deux modèles sont enrichis
avec des attributs pour spécifier les caractéristiques de chaque composant.
2.7 CONCLUSION
Actuellement, les efforts de la communauté du co-design concernent essentiellement le
développement d’une méthodologie de conception complète et de ses outils support. Par
exemple, le projet américain RASSP développe actuellement une méthodologie de co-design
en se basant sur l’utilisation d’un ensemble d’outils commerciaux et universitaires pour couvrir
toutes les phases de développement d’un projet et en utilisant le langage VHDL comme format
d’échange entre les différents outils [HEIN-95].
Comme l’activité de co-design concerne rarement un système complet, une approche
système est tout d’abord nécessaire pour déterminer la partie du système relevant de l’activité
co-design. Pour l’approche système, la méthodologie présentée dans ce chapitre repose sur
l’utilisation de la méthodologie MCSE. Durant l’étape de définition de la réalisation ou de
conception architecturale de la méthodologie MCSE, un partitionnement système identifie la
partie purement matérielle, la partie purement logicielle et la partie où une variation entre le
matériel et le logiciel est possible. La solution fonctionnelle de cette partie délicate sert alors
de spécification pour l’activité de co-design.
A ce stade le concepteur fait face à la problématique de partitionnement matériel/logiciel.
Il doit définir l’architecture matérielle cible et l’allocation des éléments de la solution
fonctionnelle sur cette architecture. Notre approche de partitionnement en 2 temps
(partitionnement système et partitionnement matériel/logiciel) évite les écueils du “défaut de
myopie” qui amènerait à trouver un optimum local pour une spécification donnée sans s’être
assuré que la spécification résulte elle aussi d’un optimum pour le niveau système: "a local
optimization made at the structural level of Design may have a detrimental effect on overall
system performance" [KUMAR-96].
M.C.S.E
47
Chapitre 2
Alors que la plupart des méthodes de partitionnement sont automatiques et ciblent vers une
architecture mono-processeur et multi-ASICs du type maître/esclave, nous considérons que
dans la réalité industrielle l’architecture cible est quelconque et notamment hétérogène et
distribuée. Nous pensons également qu’il est indispensable d’inclure le concepteur dans la
boucle de recherche d’un partitionnement optimum pour le responsabiliser et profiter de son
expérience. Le plus important est alors de fournir au concepteur des outils d’estimation rapides
des propriétés du partitionnement choisi. Comme de nombreux travaux ont déjà été effectués
sur les estimateurs analytiques (analyse des contraintes temporelles, technique de synthèse,
réseaux de Petri stochastiques et de files d’attente) nous avons opté pour une technique
différente et complémentaire: l’évaluation des performances dynamiques d’un partitionnement
par co-simulation.
L’évaluation des performances dynamiques d’un système par co-simulation n’est pas
limitée par la complexité du système et permet d’extraire un ensemble de résultats de
performances plus riche que les approches analytiques tels que le débit sur un bus, le taux
d’occupation d’une ressource (processeurs logiciels, disques, bus,...), le temps de latence d’un
message, la détection du non respect d’une contrainte temporelle, un temps de retard au
démarrage,... Cependant, la co-simulation souffre généralement d’un temps de simulation trop
long. Pour réduire les temps de simulation, il faut augmenter le niveau d’abstraction des
modèles. Notre technique de co-simulation repose donc sur la simulation d’un modèle de
performance mascroscopique et non interprété.
Contrairement à la plupart des modèles de performances existants qui ne distinguent pas
nettement la vue fonctionnelle et la vue exécutive d’un système, notre modèle de performance
est adapté à la problématique du partitionnement matériel/logiciel. Il est en effet composé du
modèle fonctionnel et du modèle exécutif préconisés par la méthodologie MCSE et d’un
modèle comportemental qui décrit le comportement de chaque fonction de la vue fonctionnelle
sous forme d’une composition d’activités dynamiques. Ce modèle de performance est décrit
dans le chapitre 3. L’unicité du modèle de description facilite la transition entre les phases de
conception, diminue les risques d’erreur liés à une transcription de modèle (pas de déformation
ou perte d’information) et améliore la traçabilité.
La technique de co-simulation retenue pour l’évaluation des performances dynamiques des
systèmes repose sur la transcription du modèle de performance en une description VHDL et
l’utilisation d’un simulateur du commerce. Pour transcrire le modèle de performance en un
code VHDL simulable, il faut tout d’abord définir les règles de transcription ce qui fait l’objet
du chapitre 4 et ensuite les implanter dans un générateur de code.
La technique de génération de code développée repose sur les concepts d’analyseur
syntaxique et de méta-structure avec lesquels on obtient une structure de données image d’un
texte source, le concept de template qui est un modèle générique du résultat attendu et le
langage de description des manipulations à effectuer sur les structures de données que nous
avons nommé Script. Un générateur est alors le résultat de l’écriture d’un script qui est
interprété ou transcrit en code JAVA par un programme nommé MetaGen et décrit dans le
chapitre 5.
48
M.C.S.E
Méthodologie de co-design et estimation des performances
Les points essentiels à retenir sont pour l’instant les suivants:
- 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, une méthode de partitionnement
interactif basée sur une évaluation des performances dynamiques et une technique de
co-simulation macroscopique et non-interprétée.
- la technique de co-simulation a nécessité le développement d’un générateur de code
VHDL qui a été réalisé selon un principe générique de développement de générateurs
de code ou d’outils de transformation de textes. Ce principe a été implanté dans un outil
qui constitue un générateur de générateurs de code ou méta-générateur exploitable pour
tout type de générateur de code.
M.C.S.E
49
Chapitre 2
50
M.C.S.E