Outils d’exploration d’architectures

L’exploration d’architecture consiste en l’élaboration de l’architecture la plus propice à répondre aux exigences de performances et aux contraintes de coûts (surface, consommation, etc...). Elle nécessite un grand nombre d’essais [5], chacun permettant de fournir des évaluations fidèles d’architectures diverses. Aussi la disponibilité d’un outil semi-automatisant cette exploration resterait fortement appréciée des architectes systèmes. De tels outils génèrent une architecture en partant d’un modèle fonctionnel de l’application et cherchent à répondre aux besoins de celle-ci tout en respectant un jeu de contraintes. Généralement, ils sont constitués d’un ensemble d’étapes permettant 1ode fixer les composants et la structure de l’architecture et 2ode déterminer l’organisation de cette dernière par l’assignation des fonctions de la description initiale de l’application aux composants de l’architecture. Un modèle générique d’un tel outil est représenté par la figure 3.8. On distingue trois types d’entrées admises par l’outil :

1. la spécification des fonctionnalités de l’application ;

2. les contraintes que doivent respecter la future implémentation de ces fonctionnalités ; 3. le modèle architectural utilisé pour composer et personnaliser cette implémentation.

L’architecture résultante est structurée en un ensemble de composants spécifiques à un traitement, et son organisation assure l’utilisation de ces composants de façon cohérente et convergente vers la fonctionnalité de l’application. Le flot est itératif et semi-automatique. Il contient une boucle permettant l’évaluation d’un modèle de performance de l’architecture afin de vérifier le respect des contraintes, puis de décider et de localiser des améliorations.

Quelques outils d’exploration parmi les plus représentatifs de ce domaine sont étudiés dans les paragraphes suivants. Ces outils sont Cosyma de l’université de Braunschweig, Archimate de TNI-Valiosys, VCC de Cadence. Les différences entre ces outils peuvent être qualifiées en fonction de :

1. la flexibilité des plateformes architecturales supportée. Leur définition peut être soit externe, ce qui amène une grande flexibilité, soit implicite car noyée dans les algorithmes de l’outil, limitant ainsi fortement l’espace de solution.

2. les axes de recherche qui permettent de réduire l’espace de solution en des sous espaces de tailles plus réduites. Cette capacité est directement reliée à la richesse des contraintes supportées par l’outil. Cependant, la diversité et la nature de ces contraintes telles que la Testabilité, la Réutilisabilité et la Flexibilité, rendent difficile la

définition de métriques capables de guider l’exploration par la recherche de leurs extremums.

3. les niveaux d’abstraction pouvant être utilisés pour exprimer le modèle d’entrée de l’application. Ce critère reflète essentiellement le découplage entre l’expression des fonctionnalités de l’application et une quelconque implémentation, exprimant ainsi la liberté d’action de l’outil. Les différences suivantes doivent donc être mises en évidence :

(a) l’abstraction du découpage des fonctionnalités et l’allocation – assignation de composants architecturaux ; (b) l’abstraction structurelle et protocolaire de la communication de l’allocation – affectation de réseaux ou bus

de communication.

4. le niveau d’abstraction des modèles de sorties qui renseignent sur l’effort restant à apporter pour implémenter le système.

5. la méthode d’exploration de l’espace de solution qui peut être :

– manuelle, l’outil n’apportant alors qu’une aide à la manipulation de modèle fastidieux ; – exhaustive et basée sur des algorithmes conduisant à une solution optimale sous contraintes ; – heuristique et conduisant à une solution acceptable, possiblement optimale.

6. la méthode d’évaluation est elle-aussi un critère de distinction. Elle peut-être :

– statique et basée sur une analyse globale de l’assignation fonctionnalitésô ressources de calculs et de communications ;

– dynamique par la simulation/exécution d’un modèle de performance de cette assignation, puis une analyse à posteriori des réponse de ce modèle.

Cosyma TNI Valiosys VCC Flexibibilité Architecture fixe ^{Architecture générique}

Point-à-point

Plateforme définie par l’utili-sateur

Axe

d’optimisation ^{Surface/vitesse Évaluation de la vitesse à posteriori.} Modèle d’entrée ^{CDFG unique, pas de}

parallé-lisme

Modèle fonctionnel avec parallèlisme et communication abstraite

Modèle de sortie ^{HW RTL et 1 SW} statique-ment ordonnancé HW RTL et n SW statique-ment ordonnancés Modèle de performance de l’architecture Méthode d’exploration Partitionnement automatique avec architecture monopro-cesseur

Assignation directe groupes de tâches fonctionnelles ô unités matérielles

Partitionnement manuel sur plateforme prédéfinie. Méthode

d’évaluation ^{Analyse statique}

Analyse dynamique par simulation de modèles de perfor-mances

Remarque

Projet très ambitieux, mais la modélisation par un CDFG unique rend difficile la gé-nération d’architectures effi-caces

Le raffinement s’opère par simple transposition sans aucune optimisation. Les résultats dépendent grandement de la qua-lité du modèle d’entrée.

Exploration Contraintes Specifications Plateforme Architecturale Macro− Architecture Evaluation ^{NOk ?} Ok ? Architecture Micro−

FIG. 3.8 – Modèle générique d’un outil d’exploration d’architecture.

Cosyma

COSYMA [110, 35, 9, 27] de l’université de Braunschweig est un environnement de co-conception permettant la mise en œuvre d’architecture limitée à un processeur logiciel RISC et plusieurs accélérateurs matériels. L’ensemble communique par des mémoires partagées. Le modèle d’entrée est ici un graphe unique de tâches, le Control & Data Flow Graph (CDFG). Le comportement de chacune est exprimé en langage C. Cosyma permet en plus de la génération d’une architecture spécifique, d’analyser les performances de cette dernière. Les sorties de cet outil sont d’une part le code binaire prêt à être exécuté sur le microprocesseur et d’autre part le code VHDL de niveau RTL décrivant le comportement des accélérateurs.

TNI-Valiosys Archimate

Archimate est un outil d’exploration d’architecture issu des travaux de recherche [104, 45]. Il permet la génération d’un

modèle RTL de l’architecture matérielle ainsi que la génération de code logiciel en langage C destiné à être exécuté par un ou plusieurs processeurs. L’entrée de cet outil est une description structurelle de l’application en termes de modules concurrents inter-connectés. Ces modules peuvent être spécifiés à des niveaux d’abstractions différents et avec des langages différents[37] tels que C, Cossap, Matlab, HDL, SDL.

Les sorties de cet outil sont :

– Une description structurelle raffinée de l’architecture matérielle. Les canaux de communication sont implémentés par des liens et des protocoles point-à-point ;

– Une implémentation logicielle de parties de l’application en hiérarchie de machines d’états entrelaçant le comportement de plusieurs tâches (machine d’états feuilles). Ces machines d’états sont codées en langage C. – Des modèles RTL en VHDL pour les implémentations matérielles de sous-systèmes de l’application. – Des modèles RTL en VHDL et du code C pour les interfaces logicielô matériel.

assigné de manière bijective une unique ressource de calcul (processeur de logiciel ou processeur matériel). Les implémentations de la communication restent malheureusement trop simpliste pour autoriser l’utilisation de cet outil dans un but autre que l’exploration architecturale. En effet, on déplore l’absence d’intergiciel pour l’adaptation logicielle des communications, une topologie et des solutions architecturales figée.

Cadence VCC

Virtual Component Codesign (VCC)[15] de Cadence est un outil d’exploration d’architecture qui suit le flot générique de la figure 3.8. La plateforme architecturale est définie indépendamment de l’application. Le concepteur décrit les fonctionnalités de son application sous la forme de graphe de tâches et peut exprimer des contraintes de vitesse d’exécution. Il doit ensuite assigner manuellement ces fonctionnalités aux différents composants de l’architecture. L’outil lui fourni alors l’évaluation d’un modèle de performance dont l’acuité dépend directement de la précision des annotations de chaque composant constituant la plate-forme architecturale. Aux vues de ces résultats, le concepteur peut aisément identifier les composants (processeurs, périphériques, bus et mémoires) pénalisant l’ensemble de l’architecture et apporter les corrections nécessaires. Aucun modèle dédié à l’implémentation n’est disponible.