Méthodologie de co-design et estimation des performancesheller/these/chap2.pdf · M.C.S.E 13 2 Méthodologie de co-design et estimation des performances Dans le chapitre précédent

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 dudé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 del’activité de co-design. Le développement de ces parties se distingue des approches systèmepar la nécessité d’une interaction forte entre les développements de la partie logicielle et de lapartie matérielle.

Lorsque les parties du système relevant de l’activité de co-design ont été clairementidentifiées et spécifiées, le concepteur doit effectuer la sélection d’une architecture matérielleet 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 nombrede critères et en figeant l’architecture cible, le problème se réduit à un problème d’allocationqui peut se résoudre automatiquement avec une heuristique basée sur une fonction pondéréedont les coefficients dépendent des critères retenus. Dans le cas général (architecture ciblehétérogène et nombre de critères élevé), il faut aider le concepteur en lui offrant des moyensd’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é dupartitionnement sont alors très influents sur les moyens et les résultats obtenus. L’estimationdes performances statiques telles que la surface de silicium occupée, la puissance consomméerepose sur des techniques de synthèse qui nécessitent une description au moins du niveaualgorithmique. Pour estimer les performances dynamiques, il faut recourir à une analyse descontraintes temporelles ou à l’utilisation d’un modèle de performance. L’analyse temporellené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 lesestimateurs cités précédemment et permet d’extraire un nombre plus important de résultats deperformances dynamiques du partitionnement choisi: temps de latence, débit sur un bus, tauxd’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é dessystèmes que nous considérons sort souvent du domaine d’application strict des modèlesanalytiques et la simulation reste alors la seule alternative possible. Comme le modèle deperformance représente à la fois la partie logicielle et la partie matérielle résultant dupartitionnement, 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 MCSEcaractérisée par sa méthode de partitionnement et sa technique de co-simulation. Avant dedé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érentesméthodes de partitionnement. L’évaluation des performances dynamiques est effectuée par uneco-simulation. Nous présentons donc ensuite un panorama des techniques de co-simulationexistantes et celle retenue par l’équipe qui est macroscopique et non interprétée. Le termemacroscopique signifie que le système n’a pas besoin d’être entièrement détaillé. Le termenon-interprété signifie que seul le temps des opérations et les dépendances temporelles sontpris en compte. Pour cette co-simulation, le modèle de performance de MCSE est transcrit enun code VHDL. Nous allons donc aussi nous intéresser aux techniques de génération de codeet à la modélisation des performances dynamiques des systèmes. Pour la modélisation desperformances des systèmes, différentes classes de modèles de performances des systèmes etleurs outils les plus représentatifs sont décrits et analysés. L’analyse des modèles deperformances présentés montre qu’ils ne sont pas bien adaptés au co-design. En effet, ils nedistinguent pas clairement la vue fonctionnelle du système de sa vue architecturale. Or à notreavis, cette séparation des deux vues est indispensable pour permettre l’exploration correcte dudomaine 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 architecturemono-processeur constituée d’un processeur, d’un ensemble de composants matérielsspécifiques (ASIC, FPGA) et éventuellement une mémoire commune. Il peut s’agiraussi 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 desinterfaces matériel/logiciel.

14 M.C.S.E


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 etarchitecturale), une architecture cible hétérogène et non figée, une méthode de partitionnementinteractif basée sur une évaluation des performances dynamiques, une technique deco-simulation macroscopique et non-interprétée basée sur un modèle d’attributs et unetechnique de co-synthèse incluant la génération des interfaces matériel/logiciel qui repose surun modèle de bus (protocole) générique et l’utilisation d’une librairie de fonctions d’adaptationvers un bus spécifique (VME, PCI, I2C, etc.) [MULLER-96].
Nous recommandons l’utilisation de la méthodologie MCSE pour faire tout d’abordl’approche système nécessaire afin de rechercher une solution si possible globalement optimalevis-à-vis de l’ensemble des contraintes. La solution fonctionnelle développée servira alorscomme base pour identifier les parties qui relèvent du co-design. La description fonctionnellede chaque partie sert ainsi de spécification. L’architecture de la solution complète se déduit parMCSE. Les parties de l’architecture plus spécifiques du co-design seront décidées selon lescontraintes à satisfaire. Une description détaillée et la justification de cette approche estexpliqué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 desystè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 aspectsmaté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 pluscomplète possible du système à concevoir, et ceci à partir du cahier des charges.

-Figure 2.1- Démarche de développement avec MCSE.

Niveau 1

Niveau 2

Niveau 3

Niveau 4

Abstrait

Concret

PRODUIT

Temps

DEFINITIONde la

REALISATION

REALISATION

Spécifications

Description fonctionnelle

Description exécutive

ModèlesSpécification

Modèlefonctionnel

Modèled’exécution

Spécifications

Spécificationsfonctionnelleset opératoires

CHARGES

CAHIER

DES

technologiques

CONCEPTION

FONCTIONNELLE

Spécifications technologiques de réalisation

SPECIFICATION

Partie incluantle co-design

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. Cettesolution est une vue orientée vers l'application et se doit d'être indépendante de latechnologie.
- l'étape de Définition de la réalisation. Il s'agit d'introduire la répartition géographiqueet les interfaces physiques pour satisfaire les contraintes technologiques, puis aprèsavoir défini le partitionnement matériel/logiciel compte-tenu des contraintes de tempset autres contraintes de réalisation, de déterminer les spécifications des partiesmatérielles et logicielles.

- l'étape de Réalisation qui consiste à développer le matériel et le logiciel à partir desspécifications de l'étape précédente.

A chaque niveau de description correspond un modèle bien formalisé qui sert d’interface etde documentation entre les étapes successives. L’étape 3 sert à identifier les spécifications dela 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écificationstechnologiques de répartition géographique et d’interfaces. Il en résulte une solutionfonctionnelle détaillée et optimisée.

- Partitionnement au niveau système, qui vise à identifier à partir de la solutionfonctionnelle complète la partie purement logicielle, la partie purement matérielle, lapartie concernée par le co-design.

- Spécifications de réalisation pour le logiciel, le matériel et la partie co-design. Les 3parties sont considérées conjointement. Une vérification et une analyse des propriétésde la solution achèvent cette phase et l’étape pour s’assurer du respect de l’ensemble descontraintes.

La figure 2.2 montre l’organisation de la démarche pour cette étape. Une partie desspécifications technologiques est considérée ici. Il s’agit des contraintes de distance entreconstituants ou/et entre entrées/sorties, des contraintes d’interfaces physiques et d’interfaceshomme/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. Ils’agit d’un partitionnement fonctionnel c’est-à-dire vis-à-vis de l’objectif à satisfaire. Laphase 1 amène ainsi à déformer la solution fonctionnelle de l’étape précédente au sens de sonenrichissement 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 solutionfonctionnelle vis-à-vis de la technologie de réalisation, c’est-à-dire matériel ou logiciel. Lescontraintes influentes que sont les performances, la sûreté de fonctionnement au sens large duterme, le coût, servent de base pour déterminer la ou les parties qui conduisent à une réalisationpurement logicielle, à une réalisation purement matérielle, à une réalisation où une variationest possible entre le matériel et le logiciel (partie qualifiée de co-design). Ce partitionnementest de niveau système et se comprend bien lorsque l’on considère un système possédant le

16 M.C.S.E


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 veutplus délicate est celle relevant du co-design.
-Figure 2.2- Description de la démarche pour l’étape de définition de la réalisation.

La phase 3 vise à déterminer les spécifications les plus complètes possible de chacune desparties et les interfaces entre elles. En suivant la méthodologie MCSE, la spécification dumatériel pour le système complet se fait en définissant le support d’exécution (ou architecturematérielle) et toutes ses propriétés. La spécification du logiciel s’obtient en définissant leschéma d’implantation du logiciel pour chaque processeur programmable de l’architecturematérielle. Il reste alors chaque partie co-design qui nécessite une démarche plus affinée pouraboutir à sa spécification détaillée permettant ensuite la vérification et la réalisation. Le détailde 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 concepteursdisposent de spécifications de réalisation complètes, cohérentes et optimales vis-à-vis descontraintes permettant d’aboutir à un système complet en accord avec les spécifications duniveau système et donc en accord avec toutes les exigences du client. Cette activité est baséesur l’emploi d’un modèle de description mixte matériel-logiciel exécutable de la solution, outout au moins des parties critiques.

L’intérêt fondamental de cette démarche basée sur MCSE pour faciliter le travail deco-design est de se poser réellement la question d’un partitionnement système (logiciel oumaté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émarched’un niveau supérieur qui est le niveau système. Ceci correspond au fait qu’une bonnerésolution d’un problème passe d’abord par son “immersion” dans un problème plus global.

Spécifications Description fonctionnelle

Contraintes interfaces

Spécifications de la réalisation complète

Spécifications

Description fonctionnelle détaillée et optimisée

Phase 1

Phase 2

Phase 3

CorrectionsAméliorations

pourvérification

Partitionnement géographique

Introduction des interfaces physiques et IHM

Synthèseinterfaces

Partitionnement système

Evaluation globale

Distances

Partie(s)matérielle(s)

Partie(s)logicielle(s)

Partie(s)co-design

Performances, sûreté,

coût

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 dela 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écificationsnon-fonctionnelles de cette partie. Il en résulte en sortie la spécification détaillée et complètede 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.

-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 unepartie 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 desfonctions sur les composants,

• Evaluation et vérification de la solution vis-à-vis des spécificationsnon-fonctionnelles imposées, ce qui implique une co-simulation.

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,

Description fonctionnelle détaillée de

Architecture

Performances,

Specification pour la réalisation

Contraintes

Phase 1

Phase 2

Corrections,améliorations

Contraintes de temps,

Spécifications non-fonctionnelles

workload

localesCorrections

globalesCorrections

Partitionnement approprié

Rétro-annotationModélisation et évaluation Performances

(Co-vérification non-interprétée)

Partitionnement, allocation

Evaluation détaillée(Co-vérification interprétée)

SynthèseMatériel

SynthèseLogiciel

Correctionsla partie concernée par le co-design

Contraintes deréalisation Synthèse

interfaces

technologiques

18 M.C.S.E


• 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 supportde la description fonctionnelle détaillée et qui va permettre d’aboutir à une solutionopé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 permetd’identifier les fonctions qui peuvent être implantées en logiciel et les fonctions à implanterobligatoirement en matériel.

Avec la méthodologie MCSE, nous proposons de suivre une démarche de partitionnementinteractif assuré par le concepteur car il peut aisément décider pour chaque fonction le meilleurchoix, 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 à implantersous la forme d’une architecture de composants matériels, les fonctions logicielles sur un ouplusieurs microprocesseurs en fonction des contraintes de temps, de coût et de répartition. Desliens nécessaires pour le couplage entre le matériel et le logiciel doivent alors être spécifiéspour l’implantation des relations fonctionnelles. D’une manière générale, la structured’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 etl’allocation choisis ainsi que les caractéristiques de l’architecture matérielle permettent desatisfaire toutes les exigences attendues et écrites dans le document de spécification sous levocable spécifications non-fonctionnelles. Pour ce faire, le résultat est transcrit sous la formedu 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]. Unemodé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 confiancedans 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: ladescription de l’architecture matérielle en y incluant la description de tous les composantsspé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. Lepremier 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 estconventionnelle et s’obtient par l’emploi d’outils de saisie de schémas. Ce schéma permetensuite la réalisation directe par assemblage ou la réalisation de carte(s) imprimée(s) commesupport(s) des composants ou même la réalisation d’un "System on a chip". Le deuxièmeniveau concerne la description de chaque ASIC. Cette description est à faire de préférence enlangage de haut-niveau tel que VHDL de manière à pouvoir utiliser un synthétiseurarchitectural ou de haut niveau.

Pour la partie logicielle, très souvent, une organisation multi-tâches doit être retenue parsuite de l’existence de plusieurs fonctions asynchrones à implanter sur un mêmemicroprocesseur. 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 deressources. Une solution intermédiaire existe en utilisant judicieusement les qualités de ces 2méthodes [CALVEZ-97b].
Des interfaces correctes entre le matériel et le logiciel doivent aussi être générées pour uneimplantation appropriée et efficace des relations fonctionnelles. Ces interfaces sont produitespar synthèse à partir des caractéristiques du couplage matériel entre le microprocesseur et sonenvironnement. 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érificationdétaillée de toutes ses propriétés: propriétés fonctionnelles et non-fonctionnelles. Unetechnique de co-simulation est alors appropriée pour ce type de vérification. Un modèle del’environnement est à nouveau nécessaire. Il résulte du travail déjà effectué pour l’ensemble dusystème au niveau fonctionnel. Il s’agit donc d’exploiter le modèle fonctionnel complet etoptimisé pour lequel la partie co-design du système qui vient d’être conçue est remplacée parle résultat de cette phase 2.

Le résultat issu de cette étape de co-design peut ensuite être prototypé, vérifié et validé puisinté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-designn’est pas une activité isolée de la conception de l’ensemble du système. Faisant partieintégrante de l’étape de définition de la réalisation, le travail de co-design est appliqué sur uneou des parties qui ont été pleinement identifiées comme justifiant d’une telle approche. Enamont, 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 granderépartition matériel ou logiciel si possible optimale globalement. Il en résulte une identificationde zones intermédiaires qui nécessitent un travail plus approfondi qui est alors typiquement duressort du co-design. Pour ces parties, un optimum local est alors recherché. Une telle approchesystème en 2 temps évite les écueils du “défaut de myopie” qui amènerait à trouver un optimumlocal pour une spécification donnée sans s’être assuré que la spécification résulte elle aussid’un optimum pour le niveau système.

Bien entendu, lorsqu’un problème posé est seulement du ressort du co-design, seule ladémarche décrite par la figure 2.3 est suffisante à condition de disposer des spécificationscorrectes et complètes de l’objet à concevoir. Pour décider de la bonne démarche à suivre, unequestion importante à se poser est de savoir si le problème est ou non “immergé” dans unproblème plus vaste. On constate aujourd’hui que la plupart des problèmes sont présentésisolés alors qu’en réalité ils ne le sont pas. MCSE impose une démarche plus globale neserait-ce qu’en imposant d’abord une analyse et une modélisation de l’environnement del’objet à concevoir, modélisation bien utile en final pour la vérification et la qualification dusystè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. Lechoix de l’architecture matérielle est un élément de décision essentiel et la démarche diffèreselon que l’architecture se trouve imposée ou choisie d’emblée ou que l’architecture et les

20 M.C.S.E


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’unmicroprocesseur, d’un ensemble de circuits matériels programmables ou d’ASICs et d’unemémoire commune. Le problème du partitionnement se réduit alors à un problème departitionnement binaire matériel/logiciel pour l’allocation des éléments fonctionnels sur lesconstituants de l’architecture et peut se résoudre de manière automatique. Nous nousintéressons à la deuxième situation plus complexe et plus proche de la réalité industrielle. Dansce cas, face à la nature hétérogène de l’architecture cible et à la diversité des contraintesimposées, une démarche itérative et guidée par le concepteur s’impose. Il s’agit alors d’offrirau concepteur des moyens rapides d’estimation des propriétés de l’implantation résultant duchoix de l’architecture, du partitionnement et de l’allocation pour vérifier si celles-ci répondaux contraintes imposées. Pour les parties du système relevant du co-design, les contraintesimposées sont surtout des contraintes de performances. En effet, les contraintes telles que laflexibilité, la testabilité, l’utilisation de composants du commerce ou de technologiesmaîtrisées par l’entreprise, la sûreté de fonctionnement et les coûts interviennentprincipalement au niveau du partitionnement système qui a pour but le découpage du systèmeen un ensemble de partitions où chaque partition devra s’exécuter soit en logiciel soit enmatériel. Les contraintes de performances sont de nature statique ou dynamique. L’estimationdes performances statiques telles que la surface de silicium occupée, la puissance consomméerepose sur des techniques de synthèse. La plupart des travaux de la communauté du co-designsur l’estimation des performances dynamiques d’un partitionnement, sont basés sur uneanalyse des contraintes temporelles et un calcul de la charge du processeur par des techniquesproches de celles utilisées en ordonnancement de tâches pour des systèmes temps-réels. Nousproposons une autre alternative qui consiste à utiliser un modèle de performance. La simulationde ce modèle de performance permet d’extraire un ensemble d’estimations de performancesplus 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 partiedu système relevant de l’activité co-design en une architecture composée d’une partiematérielle et d’une partie logicielle. Les spécifications considérées sont en réalité unedescription fonctionnelle détaillée résultant d’une approche système. Cette transformations’effectue habituellement en deux phases: la sélection d’une architecture matérielle etl’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 descontraintes au partitionnement matériel/logiciel (redondance de composants matérielset de tâches logicielles par exemple),

- la flexibilité: l’implantation logicielle d’une fonction offre des possibilités d’évolutionplus 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 composantsmaté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 quipermettent à partir des contraintes à satisfaire et des spécifications du système de générerdirectement 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 automatiquepar 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 cibleimposée et mono-processeur, une heuristique et l’utilisation d’une fonction de coût dont lescoefficients de pondération dépendent de critères tels que ceux cités précédemment. Lepartitionnement interactif cible généralement vers une architecture hétérogène à définir ets’appuie sur des estimateurs de performances statiques et/ou une estimation des performancesdynamiques 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émarcheentièrement automatique,

- Les critères influençant le choix d’un partitionnement (contraintes statiques oudynamiques, 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 dusystème à partitionner et de l’architecture matérielle allant d’une modélisationmacroscopique à une modélisation architecturale détaillée.

Pour les spécifications d’entrée d’un partitionnement, trois niveaux de granularité dupartitionnement sont habituellement utilisés: le niveau tâche, le niveau procédure et le niveauinstruction. Pour le niveau tâche (coarse-grain partitioning), l’unité d’allocation est la fonctionqui 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équencesd’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 petitepossible puisqu’il s’agit d’une instruction. L’utilisation d’un niveau de granularité fineconcerne plutôt des systèmes de faible complexité ou une conception architecturale avancéequi 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 complexedépendant d’un grand nombre de paramètres. Pour résoudre ce problème, la plupart desmé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èresretenus.

22 M.C.S.E


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 estprésenté par Rousseau, Bergé et Israel [ROUSSEAU-95]. On peut citer en autres (liste nonexhaustive):
- l’algorithme gourmand (Greedy algorithm) utilisé dans VULCAN [GUPTA-95] pourlequel toutes les fonctions sont initialement implantées en matériel et sont migrées versle processeur logiciel en vérifiant les contraintes temporelles. La fonction de coûtutilisé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. Lesfonctions sont au départ toutes implantées en logiciel puis migrées vers le matérieljusqu’au respect des contraintes de performances.

- Les algorithmes utilisés dans Co-Saw [ADAMS-95] et dans SpecSyn [VAHID-95] sontbasés sur la construction progressive de groupes de fonctions (clustering basedalgorithm) 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 lafonction de coût) des caractéristiques de l’architecture cible choisie. Souvent l’architecturecible 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 unearchitecture 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 heuristiquebasée sur la construction progressive de groupes de process (clustering based algorithm) dontla fonction de coût dépend de la communication inter-processeurs, des temps de commutationde contexte (approche préemptive et non synchrone) et du taux d’utilisation des ressources. Lesrésultats obtenus sont très dépendants des coefficients de la fonction de coût: "the cost functionplays an important role in our partitioning approach" [ERNST-93].

L’architecture générique mono-processeur et constituée d’un ensemble de FPGAcorrespond peu à la réalité industrielle. Les composants programmables ont des performancesplus faibles (surface de silicium occupée, fréquence maximale de fonctionnement) et un coûtplus é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’uncoeur de DSP et d’un coeur de microcontroleur (MCU). Ces techniques de partitionnementautomatique ne sont donc intéressantes que pour le prototypage rapide [WENDLING-94] surune carte constituée d’un microprocesseur, d’un ensemble de FPGA et éventuellement unemémoire commune. Mais pour ce type d’application, la rapidité d’obtention d’uneimplantation est un critère aussi important que la qualité du partitionnement obtenu: Il s’agitavant tout de faire une vérification fonctionnelle et non une réelle analyse des performances dufutur produit industriel.

Les techniques de partitionnement automatique souffrent généralement du fait qu’elle neprennent 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. Leconcepteur peut facilement faire un partitionnement grossier du système avant de se concentrersur les parties délicates. Or les techniques de partitionnement automatique considèrent lesystè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’unpartitionnement interactif. Inclure le concepteur dans la boucle de recherche de la solutionoptimale d’un partitionnement, offre aussi un avantage plus subtil: cela permet d’éliminer lasuspicion des concepteurs face aux résultats obtenus par un partitionnement automatique. Eneffet, la nature humaine est ainsi faite qu’elle a souvent tendance à vouloir prouver qu’elle peutobtenir un résultat meilleur que celui obtenu par une méthode automatique. De plus, leconcepteur 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émentexplorer plusieurs alternatives de partitionnement du système en manipulant une hiérarchied’automates à états finis concurrents représentée selon le formalisme SOLAR. Un ensemble deprimitives de transformations d’états (déplacement, regroupement, décomposition,...) estdisponible. Cette approche est intéressante mais pour l’instant le concepteur dispose de peu derésultats quantitatifs en retour pour évaluer la partie logicielle (statistiques sur lesinterconnexions et les variables partagées) et la partie matérielle (statistiques sur le nombred’états et sur le nombre d’opérateurs de la partie opérative) obtenues de manière à les compareraux 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 departitionnement utilisent des estimateurs basés sur:

- une analyse des contraintes temporelles, ce qui nécessite de représenter lecomportement des fonctions à un niveau interprété et très détaillé. Généralement, lecomportement d’une fonction est représentée sous la forme d’un flot de donnée et d’unflot de contrôle (CDFG). L’analyse des graphes [WOLF-94] [GUPTA-96] permetd’extraire une approximation du temps d’exécution de chaque fonction et de vérifier lerespect 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èmestemps 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 parl’algorithme de base RMS "Rate Monotonic Scheduling". Le problème se compliquelorsque 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 unedescription des fonctions au moins au niveau algorithmique (synthèse haut niveau) pourextraire des caractéristiques [NARAYAN-92b] telles que la surface de siliciumoccupée, la puissance dissipée, le nombre de broches, la taille du programme code, lataille de la mémoire nécessaire, etc.

Très peu de techniques de partitionnement sont basées sur un modèle plus abstrait etnon-interprété d’un système. Ambrosio [AMBROSIO-94] propose une technique departitionnement basée sur un modèle "système". Les processeurs sont représentés par des

24 M.C.S.E


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 nombred’instructions donné. Romdhani [ROMDHANI-96] propose une méthode de partitionnementmatériel/logiciel où l’évaluation des performances dynamiques du système est effectuée avecl’outil SES/Workbench.
2.2.5 La méthode de partitionnement proposée

Notre approche consiste à considérer que le partitionnement se fait à un niveaud’abstraction le plus élevé possible afin de considérer le système dans sa globalité et doitexploiter au mieux le bon sens et l’expérience des concepteurs. Ainsi impliqué dans leprocessus 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 pourl’instant d’estimateurs statiques puisque ceux-ci nécessitent une description détaillée etinterprétée du comportement des fonctions. L’évaluation d’un partitionnement repose sur lasimulation d’un modèle des performances du système. Contrairement aux approchesanalytiques, la simulation n’est pas limitée par la complexité du système et elle permetd’obtenir un ensemble d’estimations de performances plus important.

La méthode de partitionnement proposée repose sur la démarche itérative suivante: Comptetenu des divers critères qui lui sont imposés, le concepteur définit une première architecturematérielle. Les critères tel que la flexibilité, la testabilité, l’utilisation de composants ducommerce (COTS) ou technologies maîtrisées par l’entreprise, la sûreté de fonctionnement, lecoût et l’expérience du concepteur influent directement sur cette première implantation. Unefois cette architecture matérielle définie, le concepteur alloue les fonctions à très fortescontraintes temporelles aux processeurs matériels et le reste des fonctions aux processeurslogiciels 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 chaquefonction et sa fréquence maximale d’activation (hypothèse de tâches périodiques). Puis, laco-simulation reposant sur la transcription en VHDL du modèle de performance du systèmedonne en retour des mesures de performances tels que le temps de réponse des fonctions, letemps de latence de messages, le débit sur un bus ou encore le taux d’occupation d’uneressource. L’analyse de ces performances permet de vérifier le respect ou non des contraintesde performances à satisfaire et d’identifier les ressources critiques. Le concepteur modifie alorsl’implantation des fonctions et ressources jugées critiques et réévalue le modèle. Il peut aussirevenir sur l’architecture matérielle en changeant sa constitution et/ou des caractéristiques deses composants.

Dans la plupart des cas, la mise à jour du modèle portera essentiellement sur des attributsdes modèles fonctionnel et architectural et l’allocation des fonctions. En effet, comme nous leverrons plus tard le modèle de performance étant basé sur le concept d’attribut, unemodification 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 auxattributs des éléments du modèle de performance permet de parcourir un espace assez vaste dessolutions 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 lesperformances 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 lepartitionnement effectué, le concepteur effectue généralement une vérification fonctionnelledu résultat obtenu. Lors de l’analyse des résultats de cette co-simulation, la détection éventuelled’erreurs nécessite un retour vers les phases précédentes et notamment vers la phase departitionnement matériel/logiciel. La co-simulation n’est pas la seule technique disponiblepour 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'évaluationanalytique (méthodes formelle), la simulation, l'observation et la mesure (monitoring) sur unprototype ou un émulateur.

Le problème de la définition des vecteurs de test ou stimuli et de leur validité estgénéralement peu abordé alors qu’il est essentiel. Il faut tenir compte de tous les cas de scénariode charge du système. Il est bon de noter que pour cet aspect de la co-simulation, notreapproche se distingue par une modélisation du système et de son environnement avec le modèlede performance de MCSE. Cette approche évite de passer des stimuli au simulateur et permetsurtout de modéliser plus facilement les comportements éventuellement complexes des entitésde 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 partiematérielle d’un système et de leurs interactions. Elle est utilisée pour observer le comportementdu système complet qui se compose de quatre classes d’objets: les processeur matériels ouco-processeur dédiés, les processeurs logiciels, le logiciel s’exécutant sur les processeurslogiciels et la logique d’interface (communication inter-processeurs).

Un système complet peut être simulé à différents niveaux de détail. Par exemple, unprocesseur logiciel peut être décrit comme un ordonnanceur de tâches et le logiciel comme unensemble de tâches. Mais le processeur logiciel peut aussi être représenté par une descriptionarchitecturale détaillée (pipeline, cache, registre, ALU...) et le logiciel par une séquenced’instructions du jeu d’instructions du processeur. Généralement, plus le développement estavancé, plus la co-simulation est détaillée. Au cours du cycle de développement, laco-simulation repose donc sur différents modèles et vise plusieurs objectifs: elle sert à faire unevérification fonctionnelle ou comportementale détaillée (modèle interprété), une évaluationdes 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 plusieurstechniques de co-simulation: une co-simulation non-interprétée pour l’analyse desperformances 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) pourvalider 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 langageunique ou non et par le niveau d’abstraction du modèle de description matérielle (VHDLcomportemental, 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


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 dumodèle des processeurs logiciels (modèle d’attributs, modèle flot de ressource, modèle ISA dujeu 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 partiesmatérielles et logicielles, reposent sur la coopération de simulateurs. On parle alors desimulation 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 etl’exécution d’une description algorithmique de haut niveau de la partie logicielle. Le langageVHDL 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 aveclequel a été également écrit le noyau du simulateur VHDL auquel on accède via un ensemblede primitives spécifiques. L’interface entre l’API du simulateur VHDL et l’environnement deprogrammation C (compilateur, debuggeur, etc) utilise des mécanismes de communicationinter-process (IPC d’unix) [THOMAS-93] [VALDER.-95]. Lorsque le simulateur VHDLreçoit une information de l’exécution de la partie C (socket), il met à jour les signaux concernésaprès un délai d’attente qui correspond au temps d’exécution de la partie C. Ainsi, l’exactitudede la simulation est préservée: "The hardware simulator thus serves as a supervisor, ensuringthat 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é sousla 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èmed’exploitation (ordonnanceur de tâches à priorité fixe décrit en VHDL) et le logiciel estmodé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, lelogiciel doit être compilé pour le microprocesseur cible. Il n’est pas toujours possible d’obtenird’un fabricant de microprocesseurs, un modèle de simulation basé sur le jeu d’instruction duprocesseur. Parfois pour protéger la propriété intellectuelle du fabricant, le modèle desimulation du microprocesseur est uniquement un modèle de bus (bus level model). Un modèlede 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 jeud’instructions d’un processeur, un simulateur de modèle de bus d’un processeur ou l’exécutiond’une description algorithmique de la partie logicielle, on peut également utiliser un fond depanier 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 auproblè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élisationparticulière du bus du processeur un simulateur du jeu d’instructions du microprocesseur (outilXRAY 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 desimulation, 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 cedernier cas, il faut recourir à un émulateur matériel. L’emploi d’un émulateur matériel acependant 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 quela fréquence nominale de fonctionnement. Par exemple, l’émulation du processeurMicroSPARCII (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 deco-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 fairede la co-simulation distribuée en Intranet (sockets) ou en Internet (applet Java et utilisation duprotocole 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 demodélisation et le degré d’abstraction du modèle des processeurs qui varie en fonction de lafinalité 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 sonarchitecture qui peut être plus ou moins détaillée (modélisation d’un cache mémoire, pipelined’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’instructionsvirtuel et d’une architecture générique qui permettent de cibler sur différents processeursspécifiques. Ce type de co-simulation souffre d’un temps de simulation important mais offreun avantage au niveau de la synthèse logicielle: la qualité du code obtenu en appliquant lestechniques de synthèse (allocation des registres, ordonnancement,...) directement sur unmodèle de jeu d’instructions est meilleur que le résultat obtenu par compilation d’unedescription algorithmique de haut niveau tel que le langage C. Dans le projet RASSP, leprocesseur est aussi modélisé par son jeu d’instructions [ROSE-95], mais le modèle est plusgrossier, est non-interprété et sert uniquement à l’analyse des performances dynamiques d’unsystème (outil Cosmos de Omniview présenté plus loin).

Le processeur logiciel peut aussi être modélisé comme une ressource active caractérisée parun 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 unmodèle d’architecture dont tous les éléments sont caractérisés par des attributs temporels telque le modèle de performance de MCSE [CALVEZ-96d].

28 M.C.S.E


2.3.4 La technique de co-simulation utilisée

La technique de co-simulation retenue par l’équipe MCSE repose sur la transcription dumodèle de performance de la méthodologie MCSE en une description VHDL et l’utilisationd’un simulateur VHDL du commerce.

La figure suivante illustre le principe de co-simulation retenu.

-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’unesaisie graphique sert de point d’entrée à un générateur de code (MCSE-GEN) qui le transformeen un code VHDL simulable. La simulation du code généré produit un fichier de tracereprésentant l'évolution des fonctions et des relations inter-fonctions (mécanismes decommunication et de synchronisation). Ce fichier est alors directement exploitable par un outild’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érielledu 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 prisen compte ce qui permet un parcours rapide du domaine des solutions possibles d’unpartitionnement 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 leprocesseur logiciel pour la co-simulation, est représenté par sa puissance qui intervientcomme un facteur multiplicatif du temps d’exécution des opérations (attribut ‘Power),son degré de concurrence (attribut ‘Concurrency), sa politique d’ordonnancement destâ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 codenon-interprété pour l’évaluation des performances. En effet, en remplaçant le temps desopérations élémentaires par une description algorithmique on obtient alors un modèle VHDLinterprété qui permet de faire en plus une vérification fonctionnelle du système. Le codealgorithmique des opérations doit alors être saisi manuellement par le concepteur. Mais commeVHDL est un langage très déclaratif, le générateur produira entre 60-80% du code

Configuration

Fichiers pour la simulation

MCSE-GEN ResultatsMCSE-SIMMCSE-PERF

Modèle MCSE

VHDL VHDLTrace

Ordre de l’utilisateur

de la trace

Controle du simulateur

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 dansl’équipe MCSE. Il s’agit de transcrire le modèle de performance en un code C++ et d’obtenirles résultats par exécution du programme C++. Cette technique a été testée sur l’exemple dusystème de communication présenté dans le chapitre 7 et a permis de constater une réductiondes temps de simulation d’un facteur 4 environ par rapport à l’utilisation d’une simulationVHDL.

2.4 GENERATION DE CODE

Compte tenu de la solution décrite dans le paragraphe précédent, le problème de laco-simulation devient un problème de génération de code. Il s’agit de transcrire le modèletextuel 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 detranscription. Ce travail pour le langage VHDL fait l’objet du chapitre 4. Ensuite, il s’agit dechoisir la technique à utiliser pour effectuer les transformations de textes. Dans les paragraphessuivants, nous passons en revue différentes solutions. La solution retenue par l’équipe estparticuliè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 ouutiliser 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 desinformations d’un texte source et les reformatter. Contrairement à awk, Perl (PraticalExtraction and Report Language) permet d’utiliser des hashtables très utiles pour trier etrechercher 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. Parcontre, comme ils utilisent seulement un buffer de ligne (pas de structure interne complète destockage) et que l’accès au fichier source est séquentiel, ils sont peu appropriés pour notreproblè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éalisantcette décomposition en différentes unités s’appelle un analyseur lexical (ou scanner). Desexpressions régulières définissent les tokens à reconnaître et l’analyseur lexical est souventimplanté par une machine à états finis.

Les relations possibles entre les différentes unités significatives d’un langage constituentles règles grammaticales de ce langage. Une grammaire dite libre de tout contexte définit lesphrases correctes. La syntaxe d’entrée est souvent au format BNF (Backus Naur Form). L’outilré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èglegrammaticale soit complète. Par défaut, lorsqu’une règle est complétée, l’analyseur syntaxique

30 M.C.S.E


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 chaqueréduction de règle, on peut associer une action permettant par exemple de produire oucomplé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 plusd’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. Lastructure traditionnelle d’un compilateur est la suivante.

-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’uninterpréteur) ou transcrite en un langage cible (cas d’un compilateur). L’outil MetaGenprésenté dans le chapitre 5 est capable de fonctionner dans les deux modes: interpréteur dulangage 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 parexemple), une optimisation et une génération de code (optimisation du code, analyse du flot dedonnée et allocation des ressources).

Il existe dans les domaines universitaire et commercial un certain nombre d’outils quiregroupent un générateur d’analyseur lexical, un générateur d’analyseur syntaxique et destructure interne et une interface de programmation (API C/C++). On peut citer par exemplePCCTS, SORCERER, Gentle Compile-Compiler et Eli Compiler Construction System[GRAY-92]. Ces outils se distinguent par le format de spécification de la grammaire etl’algorithme d’analyse syntaxique utilisé. Eli Computer Construction System est le pluscomplet car il fournit également des outils pour les phases d’optimisation et de génération decode.

Analyse Lexicale (Scanner)

Analyse Syntaxique (Parser)

Analyse Sémantique

Structure de Donnée Interne (Parse Tree)

Optimisation de Code

Génération de Code

Langage Source

Langage Cible

Analyse

Synthèse(Back-End)

(Front-End)

Interpréteur

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 etsyntaxique 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 langageBackus Naur Form (BNF) est un méta-modèle puisqu’il permet de spécifier des grammairesqui constituent déjà un modèle de texte.

Le terme "template" représente ici un fichier écrit dans le langage cible souhaité etcontenant toutes les constructions nécessaires pour la translation texte à texte. Il s’agit d’unmodèle générique du résultat attendu.

La structure interne construite à partir d’un fichier texte par un analyseur syntaxique, est lecoeur du générateur à concevoir. Pour que notre générateur soit indépendant des langagessource et cible, il faut que cette structure soit construite selon un modèle générique. Nous avonspour cela défini le méta-modèle de toute structure de données. La réponse a été trouvée toutsimplement dans le formalisme BNF. En effet, une grammaire se décrit elle même selon unegrammaire qui est alors appelée méta-grammaire. Or, le formalisme BNF spécifie unegrammaire 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 diversesformes, 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, unprogramme peut s’écrire uniquement à l’aide des trois structures de contrôle que sont laséquence, l’itération et la sélection. On s’aperçoit que l’élément optionnel du méta-modèle dedonnée a disparu. Ceci est normal car le modèle de composition hiérarchique est le modèled’une structure de donnée qui est une instance de notre méta-modèle et pour laquelle l’élémentoptionnel 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 conceptsde méta-modèle et de template. Le principe était le suivant: Le générateur charge sous la formede structure interne le texte source et le fichier template. Puis, la production de la structure desortie consiste à parcourir la structure de données du modèle source, copier des parties de lastructure du template puis les mettre à jour. La figure 2.6 illustre le principe de génération decode.

En prenant du recul par rapport à cette figure, nous avons pu trouver un principe généralapplicable pour tous les générateurs de code ou même de texte. Il est possible de spécifier del’extérieur de l’outil les transformations à faire sur la structure de donnée interne pour obtenirle résultat escompté en sortie. Pour cela, nous avons développé le concept de Script qui est unlangage de description des manipulations à effectuer sur les structures de données

32 M.C.S.E


[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 deparcours de la structure de données du script et d’exécution des opérations élémentaires qu’ilspé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 lechapitre 5.
-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 scriptcorrespondant à un générateur en un programme JAVA équivalent. Cette possibilité est trèsintéressante pour produire un générateur plus rapide que l’interprétation du script par leméta-générateur. Le choix du langage JAVA pour l’implantation offre un certain nombred’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, lemodè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 etco-simulation), VHDL de niveau RTL pour la synthèse matérielle et C avec l’emploi d’unexé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écritspar un script, il est apparu judicieux de décomposer tous les scripts en une partie analyse dumodèle source et une partie génération. Le chapitre 6 sur le générateur VHDL pour lesperformances décrit une partie analyse qui a été développée de façon suffisamment génériquepour qu’elle soit commune à tous les générateurs. La difficulté repose alors sur la sélection desinformations pertinentes pour la génération et le choix de l’emplacement des appels des règlesde génération. La qualité de la partie analyse est importante car elle conditionne la partiegénération et influe directement sur l’efficacité et la qualité d’écriture d’un générateur.

ModèleMCSE

ModèleGénérique du code

Parcours

Analyse

Analyse etTransformation

Sauvegarde Ascii

Analyse

CodeGénéré

à générer

Syntaxique Syntaxique

Ordonné

Reverse-Codingpossible

Copie

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 avoirdéfini un nouveau modèle de performance alors qu’il existe déjà un éventail assez large demodèles de performance? Nous commencerons par décrire les principaux modèles deperformances existants et les outils les plus représentatifs qui leur sont associés. Puis pourconclure, nous justifierons le développement d’un nouveau modèle de performance lié à lamé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 demodélisation doit être restreint mais suffisant pour décrire n’importe quel système pour ledomaine concerné. Pour mieux interpréter les différences existant entre les modèles deperformance qui vont être présentés dans ce chapitre, considérons l’espace de modélisationtri-dimensionnel représenté par la figure 2.7 [CALVEZ-96d].

-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 pourla description des solutions intermédiaires entre le besoin et le produit final. Les niveauxhabituellement considérés sont: le niveau système ou spécification, le niveaufonctionnel, 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 pourla description. Trois modèles, chacun exprimant un point de vue, sont usuels : le modèlestructurel, 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.

Interprétation

interprété

non-interprété

Abstrait

Concret

Spécification

niveau fonctionnel

niveau architectural

niveau physique

Niveaux de description

StructureComportement Donnée/Objet Représentation

1 2

34 M.C.S.E


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épendancestemporelles entre les sorties et les entrées sont observées. Les valeurs en entrée et cellesdes données internes ne sont pas prises en compte. Les entrées et les données internesinfluencent le comportement du système uniquement par l’intermédiaire d’attributs. Parexemple, les attributs Size (taille) et Id (destinataire) d’un message remplace le contenudu message.

- et les modèles interprétés pour lesquels les valeurs des données sont considérées. Cesmodèles décrivent un comportement fonctionnel représenté le plus souvent sous laforme 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 utilepour l’évaluation des performances. Un modèle approprié pour l’évaluation des performancesest de type non-interprété. Il doit associer la vue structurelle pour représenter la décompositionou l’organisation du système et la vue comportementale pour décrire les propriétés temporellesde chaque constituant.

Sur la figure 2.7, il y a également une séparation nette entre un modèle de structure et unmodè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 typesde modèle sont nécessaires et complémentaires. De plus, un modèle de comportement peut seremplacer par un modèle de structure lors d’une opération de raffinement et réciproquement unmodèle de structure peut se remplacer par un modèle de comportement lors d’une opérationd’abstraction. Dans le formalisme utilisé par la méthodologie MCSE, la vue structurelleregroupe la vue fonctionnelle et la vue architecturale ou exécutive.

Enfin, un modèle de performance peut être élaboré et utilisé pour trois niveaux dedescription: les spécifications (étude de faisabilité), la conception fonctionnelle(dimensionnement des éléments internes du système) et la conception architecturale (aide aupartitionnement logiciel/matériel).

Selon l’approche de modélisation que doit faire le concepteur, les modèles de performancespeuvent ê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 lesréseaux de Petri: modèle UVa, SES/WorkBench, Bones... Ces modèles ont l’avantagede s’appuyer sur un formalisme mathématique qui dans certains cas permet d’extrairedes informations sans qu’une simulation dynamique soit nécessaire.

- le modèle d’architecture: RD100, Cosmos de Omniview appelé encore récemmentPerformance Modeling WorkBench. Le modèle UVa est aussi un modèle d’architecturemais il s’appuie également sur le formalisme des réseaux de Petri pour le comportementde 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 dedistribution 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 processeursdistribué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 auprocesseur par l’intermédiaire d’une file d’attente. Le nombre d’utilisateurs est fixe et doit êtreinférieur à la taille des files d’attente. Une fois que le processeur a effectué le travail désiré, latransaction accède aléatoirement à l’un des deux disques du système modélisés comme leprocesseur par la combinaison d’une file d’attente et d’un noeud de service. Puis la transactionpasse 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 taillemoyenne des files d’attente, le temps moyen de service, le temps moyen d’attente pour unservice, 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 franchissableque si toutes les places précédentes possèdent au moins 1 jeton, et lorsqu’elle est franchie, unjeton 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 des’assurer que tous les états sont atteignables. Pour étendre l’usage des réseaux de Petriclassiques à 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 temporeld’exécution de la transition.

- soit au niveau des places. Dans ce cas, une transition n’est franchie que si toutes lesplaces 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 dedurée pour faciliter l’étude du comportement temporel d’un système. Lorsque cette duréedépend d’une loi aléatoire, le réseau de Petri est appelé réseau de Petri stochastique.

36 M.C.S.E


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) estprésentée dans [STOY-94]. Les réseaux de Petri représentent le flot de contrôle et le flot dedonnées des parties matérielles et logicielles. La simulation des réseaux de Petri permet devérifier le respect des contraintes temporelles et de faire une évaluation des performances dusystème. Cette évaluation des performances est alors utilisée par une heuristique et unefonction de coût pour réaliser le partitionnement matériel/logiciel. Puis, un outil de synthèsehaut niveau nommé CAMAD transforme les réseaux de Petri en une netlist pour l’implantationen matériel et en un programme C pour l’implantation en logiciel. Le nombre d’états et detransition croit très rapidement en fonction de la complexité du système étudié. L’approcheproposé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 devenirrapidement complexe lorsque la taille de l’application augmente. De plus, l’évaluationanalytique n’est possible que sur une classe limitée de systèmes et ne permet pas d’analysercorrectement 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èlesutilisent principalement la simulation et non l’évaluation analytique pour faire une estimationdes performances. Il existe de nombreux outils spécifiques aux réseaux de files d’attente et/ouaux réseaux de Petri stochastiques: TimeNet [KELLING-95], QNAP2, Bones, SimScript. Cesoutils se composent généralement d’une interface graphique pour la modélisation etl’animation des réseaux, d’un langage algorithmique de haut niveau pour décrire lecomportement de certains noeuds et d’un générateur de code automatique à partir de ladescription 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 lesperformances d’un partitionnement logiciel/matériel car ils ne permettent pas de représenter lavue 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 deconstituants,

- 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 descriptioncomportementale 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éparationplus 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 lesplus utilisés des modèles de flot de transactions et d’architectures. Pour chaque outil de cetteliste non exhaustive, on s’intéresse plus aux propriétés des modèles de performancesconsidé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 andEngineering 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’unensemble de noeuds auquels on peut éventuellement associer une forme graphique et desmé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. Lenoeud de service est constitué d’une file d’attente et d’un temps de traitement. Commeil 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 denoeud permet de modéliser un processeur logiciel ou une ressource active. Le noeud deressource (réservoir de jeton) permet de modéliser une ressource passive telle qu’unemé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 ladescription suit le chemin parcouru par une transaction.

-Figure 2.9- Exemple de modélisation sous SES/Workbench.

New_Work

-+

Get_memoryDisk1

Disk2

Cpu

not finished

Release_memory

End_WorkExec

ServiceAllocationSource

DésallocationRéference

Destruction

Rafinement

38 M.C.S.E


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 lamodélisation (flot de transactions) et de générer (API et langage de requêtes) des rapportsstatistiques (valeur min, max, moyenne, histogramme de fréquence,...) sur les performancesdes divers noeuds du modèle.
Romdhani [ROMDHANI-96] a utilisé SES/Workbench pour faire une évaluation desperformances dynamiques d’un système lors d’un partitionnement matériel/logiciel. Ilmodélise en parallèle un flot de données (axe fonctionnel) décrivant les transformations sur lesdonnées et un flot de contrôle décrivant les ressources utilisées (axe architectural). Lasynchronisation 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 partiecontrôle dans lesquelles la vue fonctionnelle et la vue architecturale sont complètementamalgamées. Par conséquent, même si l’architecture matérielle cible est figée, unemodification de l’allocation d’une fonction nécessite au minimum de redessiner le flot dedonnées, ce qui est plutôt contraignant lorsque l’on doit parcourir un domaine assez vaste dessolutions possibles.

Le modèle de SES/wokbench est plus riche en concepts de modélisation que le modèle deperformance que nous avons développé. A ce titre, il est capable de modéliser n’importe quelmodèle de performance MCSE. Mais la différence essentielle entre les deux modèles résidedans l’approche de modélisation. SES/workbench est orienté flot de transactions: le concepteurdé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 deuxconséquences. En premier, la méthode de modélisation est différente de celle utilisée par lesconcepteurs en co-design (description du modèle fonctionnel, puis du modèle architectural etallocation), ce qui implique un surcoût de temps pour exploiter les concepts de SES et obtenirles 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 cemodèle, la description d’une phase de conception ne peut pas être enrichie ou détaillée enremplaçant le modèle comportemental d’un composant par son raffinement structurel. L’outilest 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 pourl’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 ducode 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 quelautre 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 surun 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 uncomportement décrit par un réseau de Petri écrit en VHDL. L’interconnexion entre ces blocsse fait par un passage de jeton selon un protocole de communication du type rendez-vous. Unecouleur est associée au jeton. Ce concept de couleur caractérise le modèle comme étant noninterprété et est proche du concept d’attribut associé aux échanges d’information de notremodèle MCSE.
Pour l’évaluation des performances, les blocs prédéfinis sont classés en trois groupesprincipaux. Il y a tout d’abord les modules de contrôle (19 différents): ils agissent uniquementsur l’état du jeton. Il y a par exemple les “Source”, les “Sink”, les “Switch” ou les "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”.

-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 lemê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.

-Figure 2.12- Exemples de modules de Délai.

La plupart des blocs ont un comportement non-interprété. Mais le modèle comporte aussides blocs d’analyse de fautes (13), de collecte d’informations (4), et des blocs hybrides (7) quipermettent 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 fonctionnementd’un système. La description d’une architecture avec ce modèle se fait à l’aide d’un outilADEPT [KUMAR-94] basé sur l’utilisation d’outils graphiques de CAO (Mentor GraphicsDesign Architect). La vérification fonctionnelle et l’évaluation des performances est faite parsimulation du programme VHDL. Les possibilités d’évaluation sont importantes car il estpossible d’observer l’état de chaque bloc et de chaque jeton.

Signaux de données

Signaux de contrôleSO

Source

OUT_1

SI

Sink

IN_1SW

Switch

IN_1 OUT_1

IN_C1

OUT_1IN_1

IN_2 J

Junction

RC

Read Color

IN_1 OUT_1

OUT_C

SC_D

Set Color

IN_1 OUT_1

IN_C

CP

Comparator

IN_1 IN_2

OUT_C

FD

Fixed Delay

IN_1 OUT_1DD

Dependent Delay

IN_1 OUT_1R

Random

IN_1 OUT_1

40 M.C.S.E


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 descriptionscomportementales. Par conséquent, le concepteur doit faire un effort important pour trouverl’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 estsimilaire à la distinction qui existe entre la description comportementale de haut-niveau d’uncircuit 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 anécessité pas moins de 2000 blocs.
A notre point de vue, un modèle non accompagné d’une démarche favorisant l’élaborationde solutions n’est pas suffisant. Récemment, l’université de Virginie a pris conscience de lanécessité d’avoir une démarche système: "a local optimization made at the structural level ofDesign may have a detrimental effect on overall system performance" [KUMAR-96]. Elle aalors développé une méthodologie complète de conception appelée ISPME (IntegratedSpecification and Performance Modeling Environment). Cette méthodologie repose surl’association du modèle de "StateChart" pour couvrir les phases de spécification et conceptionfonctionnelle et du modèle UVa pour la conception architecturale et l’évaluation desperformances. L’utilisation de modèles hybrides a pour but de faciliter la transition d’une phasede 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.

-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 denoeuds de process représentant une transformation sur les données et de noeuds debranchement conditionnels. Chaque bloc F utile pour modéliser l’aspect fonctionnel possèdeune 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 derecherche et décodage d’instruction, d’une mémoire de stockage et d’un ensemble de branchesd’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

F

F

N

N

F

F

TRUE FALSE

TRUEFALSE

ELEMENTS

DE

ROUTAGE

MEMOIRE

FETCH

EXECUTE1

EXECUTEN

Modèle logiciel Modèle matériel

Delai

Machine Virtuelle

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é à lamachine 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 surl’évaluation des performances dans le cadre du projet RASSP. Un couplage entre les deuxmodèles de performances a été réalisé: les blocs hybrides [KUMAR-97] permettent en effet derelier le modèle UVa avec le modèle de performance de Honeywell Technology Center qui faitpartie 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]. Ilpermet la saisie du cahier des charges, l’élaboration des spécifications, l’analyse fonctionnelleet 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 connudans ce domaine d’application, il a ensuite été enrichi pour couvrir la phase de conceptionfonctionnelle (modèle interprété) et la phase de définition de la réalisation comportant ladéfinition de l’architecture matérielle et l’allocation des éléments fonctionnels sur cettearchitecture. Basé sur différents formalismes, il a été développé en tenant compte derecommandations 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]. Cetteefficacité est due à la base de données de RDD100 construite sur le modèleEntité-Relation-Attributs (ERA). Ce modèle de description permet de représenter l’applicationen 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. Lesentités sont regroupées par type d’entités (catégorie). Chaque type d’entité possède ses propresattributs (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 ladescription du comportement du système vis à vis de son environnement, le modèle ERA de labase 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). Lacohérence entre les différentes vues est gérée par l’outil de manière transparente pourl’utilisateur. Le formalisme utilisé est proche de celui de la méthode OMT ou plutôt de laméthode unifiée puisque lors de l’analyse fonctionnelle on retrouve également un conceptproche de celui du concept de scénario (ou Use Cases au sens de Jackobson) qui permetd’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 vuestructurel (topologie du système), le point de vue des données (flot de donnée) et le point de

42 M.C.S.E


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 etproduisent des données. Elles peuvent s’exécuter en séquence ou en parallèle. Lesconstructions de type itération, boucle, sélection, réplication, décomposition, agrégation sontautorisées.
Parmi les données échangées, on trouve les messages et les variables d’état. Les messagespermettent 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 deuxfonctions commencent leur exécution simultanément. La fonction A envoie un message M. Lafonction B en attente du message M commence alors son exécution. Une file d’attente estassocié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 dumodèle MCSE où l’on retrouve les concepts de fonctions et de port de communication.

-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 lessupports physiques de transmission pour les messages.

-D- Evaluation des performances

Pour faire une évaluation des performances, l’utilisateur peut affecter des temps detraitements aux fonctions. Une ressource active est caractérisée par sa puissance qui intervientcomme un facteur multiplicatif de la durée de traitement d’une opération et son degré deconcurrence. Un support de communication est caractérisé par sa capacité et chaque messagepar sa taille.

La simulation des modèles saisis repose sur la génération et l’exécution d’un programmeSmalltalk. L’outil permet de présenter les résultats sous la forme d’un déroulement temporel

&

Function A Function BM

&

ProcProd ProcConsCC1

a) Diagramme de comportement

Partition etAllocation

b) Architecture matérielle

EvolutionTemporelle

Flot de données

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èlepour l’évaluation d’un partitionnement matériel/logiciel et la co-simulation: il n’est paspossible 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 aussiredessiner 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 dessystèmes utilisé dans le projet RASSP [FRY96]. Il est complété par l’outil Price System pourl’analyse de coûts et les outils RAM-ILS (Reliability, Availability, Maintainability, IntegratedLogistic Support) pour l’analyse de la sûreté de fonctionnement, la fiabililité et lamaintenabilité d’un système. Actuellement, cette intégration d’outils permet de couvrir toutesles phases de développement d’un système et de faire du suivi de projet (gestion des ressourceshumaines, 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’unsystème composé de deux vues [OMNIVIEW-97]:

- une vue matérielle qui correspond à une version simplifiée du modèle exécutif ouarchitectural de MCSE,

- une vue logicielle qui correspond à une association simplifiée de la vue fonctionnelle etla vue comportementale de MCSE. L’outil COSMOS n’est en effet pas capable demodéliser le comportement d’une fonction implantée en matériel puisque la vuelogicielle ne permet de décrire que le comportement de tâches logicielles.

La figure ci-dessous montre différentes vues de l’outil Cosmos.

-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 surl’interconnexion de blocs et l’utilisation d’une librairie VHDL (modèle de performance deHoneywell Technology Center) dont les composants sont paramétrables. Cette librairiecontient les modèles de performances de 4 types d’éléments: les processeurs, les mémoires, les

a) Modèle logiciel b) Modèle matériel

File d’attente

TachePeriodique

Matrice d’interconnection

Bloc raffiné

44 M.C.S.E


é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. Unordonnanceur 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èsmémoire nécessaires à son exécution. L’instruction simple ou multiple peut être définiepréemptive et dans ce cas il faut aussi définir les temps de préemption et de réallocation. Lesaccè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 pourdéterminer si un accès mémoire se fera avec ou sans cache (tirage aléatoire ou valeurmoyenne). Pour accélérer la simulation du modèle logiciel, l’outil calcule le temps totalnécessaire à l’exécution d’une instruction. Il commence par calculer le nombre de cyclesnécessaires aux accès mémoire en tenant compte de l’utilisation éventuelle d’un cache etadditionne ce résultat aux cycles de l’instruction. Le modèle ne modélise pas un étage depipeline d’instructions. Mais un étage de pipeline d’instructions a moins d’influence sur lesperformances du processeur que la modélisation d’un cache mémoire et la prise en compte desinterruptions: "Caches affect CPU performance even more than pipelining within the executionunit. Interrupt latency, the time required for the CPU to execute the first instruction of ainterrupt 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 architecturematérielle se fait par transition d’un jeton. Le concept de jeton est ici très proche du jeton dumodèle UVa puisqu’il s’agit d’une donnée non interprétée caractérisée par un certain nombred’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 dansl’architecture matérielle. C’est le rôle des sources de jetons ("InputDevice") qui définissent ledestinataire du jeton, sa taille et son débit. La taille et le débit peuvent être fixes ou tirésaléatoirement selon des distributions uniformes, gaussiennes, de poisson, etc. Par dualité, ilexiste aussi des consommateurs de jetons ("OutputDevice") et des réflecteurs de jetons. Lesréflecteurs (disques, mémoire, pipeline, file d’attente) de jetons retournent un jeton après uncertain délai. Enfin, comme pour le modèle UVa, des opérateurs de contrôle du flot de jetonstel 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 pourmodé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 sontdécrits sous la forme d’une tâche. Il y a 2 types de tâches: les tâches périodiques et les tâchesapériodiques en attente de l’occurrence d’un message.

La communication entre tâches se fait par transfert de messages qui englobent un jeton etvia une file d’attente. La file d’attente chargée de gérer l’ordre et la priorité des messages estcaractérisée par sa taille et sa politique de gestion des messages (ordre d’arrivée, taille dumessage, priorité fixe, date de création...). Le protocole d’envoi de message peut être du typeport à 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 cemessage durant la période d’activation.
Les tâches ont un comportement purement séquentiel. Ce comportement est décrit sous laforme d’un diagramme de flot ou sous le forme d’un programme VHDL saisi manuellementpar l’utilisateur (utilisation d’un ensemble de primitives prédéfinies). Le diagramme de flot estplutôt un diagramme de flot de contrôle qu’un diagramme de flot de données. Le diagrammede flot se compose en effet d’opérateurs de branchement conditionnel, d’itération, de point desortie et de blocs de code constitués d’une séquence d’instructions saisie avec un éditeurorienté par la syntaxe. Graphiquement, on ne peut pas parler de flot de données puisquel’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 partiesmatérielle ou logicielle séparément. Il permet aussi d’allouer les tâches logicielles sur lesprocesseurs 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’outilne 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 entreles différents processeurs logiciels.

-D- Analyse des résultats

L’outil permet d’animer les modèlesgraphiques, ce qui permet d’avoir une vueglobale des ressources matérielles critiques. Lavisualisation des résultats se fait sous la formed’histogrammes (temps de latence, débit, tauxd’utilisation) ou sous la forme d’un diagrammetemporel qui permet d’observer les tempsd’exécution des différents tâches d’unprocesseur. Le diagramme de déroulementtemporel est assez limité car il ne représente quel’état actif d’une tâche. On ne sait pas si la tâcheest bloquée en attente d’un message, prête à êtreexécutée mais en attente du processeur ou bieninactive. Il ne représente pas les émissions demessages. Il ne permet pas de mesurer les tempsde réponse. Enfin, il ne facilite pas lacompréhension des dépendances d’activationentre tâches et la recherche des éventuelsproblèmes d’ordonnancement (non respect decontrainte de temps, interblocage)

-Figure 2.16- Déroulement temporel.

46 M.C.S.E


2.6.5 Bilan

En conclusion de cette analyse de l’existant, on peut affirmer que la plupart des modèles deperformance ne sont pas complètement appropriés pour la problématique du co-design car lesmodèles recensés ne distinguent pas précisément la vue fonctionnelle et la vue exécutive. Orune séparation nette entre ces deux vues s’avère indispensable pour explorer facilementl’espace des solutions possibles pour l’architecture exécutive et pour le partitionnementmatériel/logiciel. Avec le modèle de performance de MCSE qui nous présentons en détail dansle chapitre 3, le concepteur n’a pas besoin de définir un modèle différent pour chaquealternative du partitionnement. Il doit juste redéfinir l’allocation des éléments fonctionnels surles éléments de la structure exécutive (mapping).

Les modèles de performances existants (Ses/Workbench, UVa) ont surtout été developpéspour faire l’analyse des performances de systèmes existants alors que le modèle deperformances de MCSE a été développé pour répondre à la problématique du partitionnementmatériel/logiciel. Il est en effet basé sur deux vues complémentaires et orthogonales: la vuestructurelle et la vue comportementale. Le modèle de la vue structurelle est utilisé pourreprésenter l’architecture du système selon les 2 niveaux fonctionnel et exécutif (ouarchitectural). Le modèle comportemental spécifie le séquencement temporel d’un ensembled’opérations et d’activités. Il s’agit d’un modèle graphique où l’axe vertical représentel’évolution temporelle et l’axe horizontal le flot de données. Les deux modèles sont enrichisavec 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 ledéveloppement d’une méthodologie de conception complète et de ses outils support. Parexemple, le projet américain RASSP développe actuellement une méthodologie de co-designen se basant sur l’utilisation d’un ensemble d’outils commerciaux et universitaires pour couvrirtoutes les phases de développement d’un projet et en utilisant le langage VHDL comme formatd’échange entre les différents outils [HEIN-95].

Comme l’activité de co-design concerne rarement un système complet, une approchesystè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 surl’utilisation de la méthodologie MCSE. Durant l’étape de définition de la réalisation ou deconception architecturale de la méthodologie MCSE, un partitionnement système identifie lapartie purement matérielle, la partie purement logicielle et la partie où une variation entre lematériel et le logiciel est possible. La solution fonctionnelle de cette partie délicate sert alorsde 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 solutionfonctionnelle sur cette architecture. Notre approche de partitionnement en 2 temps(partitionnement système et partitionnement matériel/logiciel) évite les écueils du “défaut demyopie” qui amènerait à trouver un optimum local pour une spécification donnée sans s’êtreassuré que la spécification résulte elle aussi d’un optimum pour le niveau système: "a localoptimization made at the structural level of Design may have a detrimental effect on overallsystem 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 quedans la réalité industrielle l’architecture cible est quelconque et notamment hétérogène etdistribuée. Nous pensons également qu’il est indispensable d’inclure le concepteur dans laboucle de recherche d’un partitionnement optimum pour le responsabiliser et profiter de sonexpérience. Le plus important est alors de fournir au concepteur des outils d’estimation rapidesdes propriétés du partitionnement choisi. Comme de nombreux travaux ont déjà été effectuéssur 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 techniquedifférente et complémentaire: l’évaluation des performances dynamiques d’un partitionnementpar co-simulation.
L’évaluation des performances dynamiques d’un système par co-simulation n’est paslimitée par la complexité du système et permet d’extraire un ensemble de résultats deperformances plus riche que les approches analytiques tels que le débit sur un bus, le tauxd’occupation d’une ressource (processeurs logiciels, disques, bus,...), le temps de latence d’unmessage, la détection du non respect d’une contrainte temporelle, un temps de retard audémarrage,... Cependant, la co-simulation souffre généralement d’un temps de simulation troplong. Pour réduire les temps de simulation, il faut augmenter le niveau d’abstraction desmodèles. Notre technique de co-simulation repose donc sur la simulation d’un modèle deperformance mascroscopique et non interprété.

Contrairement à la plupart des modèles de performances existants qui ne distinguent pasnettement la vue fonctionnelle et la vue exécutive d’un système, notre modèle de performanceest adapté à la problématique du partitionnement matériel/logiciel. Il est en effet composé dumodèle fonctionnel et du modèle exécutif préconisés par la méthodologie MCSE et d’unmodèle comportemental qui décrit le comportement de chaque fonction de la vue fonctionnellesous forme d’une composition d’activités dynamiques. Ce modèle de performance est décritdans le chapitre 3. L’unicité du modèle de description facilite la transition entre les phases deconception, diminue les risques d’erreur liés à une transcription de modèle (pas de déformationou perte d’information) et améliore la traçabilité.

La technique de co-simulation retenue pour l’évaluation des performances dynamiques dessystèmes repose sur la transcription du modèle de performance en une description VHDL etl’utilisation d’un simulateur du commerce. Pour transcrire le modèle de performance en uncode VHDL simulable, il faut tout d’abord définir les règles de transcription ce qui fait l’objetdu 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’analyseursyntaxique et de méta-structure avec lesquels on obtient une structure de données image d’untexte source, le concept de template qui est un modèle générique du résultat attendu et lelangage de description des manipulations à effectuer sur les structures de données que nousavons nommé Script. Un générateur est alors le résultat de l’écriture d’un script qui estinterprété ou transcrit en code JAVA par un programme nommé MetaGen et décrit dans lechapitre 5.

48 M.C.S.E


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 parune approche système, une modélisation selon 3 vues (fonctionnelle, comportementaleet architecturale), une architecture cible hétérogène, une méthode de partitionnementinteractif basée sur une évaluation des performances dynamiques et une technique deco-simulation macroscopique et non-interprétée.

- la technique de co-simulation a nécessité le développement d’un générateur de codeVHDL qui a été réalisé selon un principe générique de développement de générateursde code ou d’outils de transformation de textes. Ce principe a été implanté dans un outilqui constitue un générateur de générateurs de code ou méta-générateur exploitable pourtout type de générateur de code.

M.C.S.E 49

Chapitre 2

50 M.C.S.E

Documents

Méthodologie de co-design et estimation des performancesheller/these/chap2.pdf · M.C.S.E 13 2 Méthodologie de co-design et estimation des performances Dans le chapitre précédent