3.3 Outils et méthodologies de conception d’architectures
3.3.3 Outils de synthèse de réseaux de communication
Motif architectural figé Intégration Architecture Abstraite Composants − Mémoire
− Calcul d’adaptationPrimitives
Arcitecture d’implémentation
− Protocole
FIG. 3.9 – Modèle générique d’un outil d’intégration de composants avec synthèse du réseau de communication. La génération d’architectures détaillées d’implémentation à partir du modèle de référence par les outils d’intégration de composant est représentée dans la figure 3.9. Les fonctions principales de ceux-ci sont :
1. le raffinement de l’architecture abstraite consiste en un remplacement systématique des modèles abstraits des composants de calcul et de mémorisation par les implémentations correspondantes. Ces modèles sont
généralement constitués d’une instance d’un modèle réalisable du composant (processeur ou bloc mémoire) et d’un chapelet de composants périphériques nécessaire à son fonctionnement (mémoires locales, décodeurs d’adresses, bus et arbitres, contrôleurs de rafraîchissement ...). Cet ensemble constitue une Architecture Locale (AL).
2. la synthèse des réseaux de communication à partir de modèles virtuels (liens logiques ou composants abstraits) vers des modèles implémentables.
3. l’adaptation éventuelle des composants au réseau de communication par l’insertion entre ces deux entités d’adaptateurs matériels.
Parmi les outils disponibles, seuls N2C, Program et Gaut seront étudiés. Un récapitulatif des caractéristiques de ces outils, telles que les modèles de composants manipulés, la nature du réseau de communication, l’adaptation des composants et la génération d’un modèle du réseau d’interconnexion, est donné par le tableau 3.3.
CoWare Napkin-to-Chip
CoWare Napkin-to-Chip (N2C)[106, 105, 107] est un environnement de co-simulation et de génération d’interfaces. La méthodologie de CoWare s’articule autour d’un langage unique permettant la description de logiciel et de matériel à différents niveaux d’abstraction. Ce langage, le CoWareC est le fruit d’une extension de C, capable de modéliser la structure et le comportement d’une architecture à travers les quatre niveaux d’abstraction suivants :
– Le niveau UnTimed (UT) permettant une modélisation fonctionnelle d’applications, sans notion de temps. Les communications sont implicites, les ports sont manipulés comme des variables C volatiles. Ce niveau est donc équivalent au niveau Transaction introduit en 3.2.3.
– Le niveau Bus Cycle Accurate (BCA) ; dans ce niveau d’abstraction, le comportement des tâches est séquencé par une horloge, et contrôlé par un signal d’initialisation (reset). Ce niveau est équivalent au niveau Micro-architecture présenté en 3.2.3.
– Le niveau Bus Cycle Accurate Shell (BCASH) ; ce niveau apporte une enveloppe BCA aux modules d’abstraction UT, afin de les connecter à un environnement BCA.
Les applications sont modélisées dans ce langage en utilisant le modèle de calcul Remote Procedure Call (RPC) où ne subsistent que deux concepts d’exécution, les tâches maîtres et les tâches esclaves. Deux tâches n’appartenant pas au même module ne peuvent communiquer qu’au travers de leurs ports et d’un canal implicitement déclaré. Chaque tâche communiquant par un port se voit assigner une relation de maître ou (exclusif) d’esclave vis-à-vis de ce port. Elle peut soit :
– initier la communication, si elle est maîtresse du port et se geler en attendant la réponse en provenance de l’entité distante ;
– être activée uniquement lorsqu’une tâche maîtresse distante initie une communication débouchant sur le port esclave. Elle s’exécute alors complètement puis le port esclave envoie un acquittement implicite à sa contrepartie maîtresse. Le réseau de communication est donc formé de connexions point-à-point maître-esclave.
Les architectures ciblées par N2C (figure 3.10) sont monoprocesseurs, les périphériques sont individuellement connectés au bus natif du processeur au travers d’instances d’adaptateurs (Bridge) dont les largeurs de données véhiculées et le nombre de cycles d’attentes sont statiquement configurables.
ÀwÀwÀwÀ ÀwÀwÀwÀ ÀwÀwÀwÀ ÀwÀwÀwÀ ÀwÀwÀwÀ ÀwÀwÀwÀ ÀwÀwÀwÀ ÁwÁwÁ ÁwÁwÁ ÁwÁwÁ ÁwÁwÁ ÁwÁwÁ ÁwÁwÁ Bridge 5 ÂwÂw ÂwÂw ÂwÂw ÂwÂw ÂwÂw ÂwÂw ÃwÃwà ÃwÃwà ÃwÃwà ÃwÃwà ÃwÃwà ÃwÃwà ÄwÄwÄ ÄwÄwÄ ÄwÄwÄ ÄwÄwÄ ÄwÄwÄ ÄwÄwÄ ÅwÅwÅ ÅwÅwÅ ÅwÅwÅ ÅwÅwÅ ÅwÅwÅ ÅwÅwÅ ÆwÆwÆwÆ ÆwÆwÆwÆ ÆwÆwÆwÆ ÆwÆwÆwÆ ÆwÆwÆwÆ ÆwÆwÆwÆ ÆwÆwÆwÆ ÇwÇwÇ ÇwÇwÇ ÇwÇwÇ ÇwÇwÇ ÇwÇwÇ ÇwÇwÇ ÈwÈwÈwÈ ÈwÈwÈwÈ ÈwÈwÈwÈ ÈwÈwÈwÈ ÈwÈwÈwÈ ÈwÈwÈwÈ ÉwÉwÉ ÉwÉwÉ ÉwÉwÉ ÉwÉwÉ ÉwÉwÉ ÉwÉwÉ ÊwÊwÊwÊ ÊwÊwÊwÊ ÊwÊwÊwÊ ÊwÊwÊwÊ ÊwÊwÊwÊ ÊwÊwÊwÊ ËwËwË ËwËwË ËwËwË ËwËwË ËwËwË ËwËwË ÌwÌwÌwÌ ÌwÌwÌwÌ ÌwÌwÌwÌ ÌwÌwÌwÌ ÌwÌwÌwÌ ÌwÌwÌwÌ ÌwÌwÌwÌ ÍwÍwÍ ÍwÍwÍ ÍwÍwÍ ÍwÍwÍ ÍwÍwÍ ÍwÍwÍ ÎwÎwÎwÎ ÎwÎwÎwÎ ÎwÎwÎwÎ ÎwÎwÎwÎ ÎwÎwÎwÎ ÎwÎwÎwÎ ÎwÎwÎwÎ ÏwÏwÏwÏ ÏwÏwÏwÏ ÏwÏwÏwÏ ÏwÏwÏwÏ ÏwÏwÏwÏ ÏwÏwÏwÏ ÐwÐwÐwÐ ÐwÐwÐwÐ ÐwÐwÐwÐ ÐwÐwÐwÐ ÐwÐwÐwÐ ÐwÐwÐwÐ ÑwÑwÑwÑ ÑwÑwÑwÑ ÑwÑwÑwÑ ÑwÑwÑwÑ ÑwÑwÑwÑ ÑwÑwÑwÑ ÒwÒwÒwÒ ÒwÒwÒwÒ ÒwÒwÒwÒ ÒwÒwÒwÒ ÒwÒwÒwÒ ÒwÒwÒwÒ ÓwÓwÓwÓ ÓwÓwÓwÓ ÓwÓwÓwÓ ÓwÓwÓwÓ ÓwÓwÓwÓ ÓwÓwÓwÓ ARM7TDMI MUX A DOUT DATA nIRQ IPE CS Bridge 2 Scenario 2 Bridge 1 Scenario 1 Bridge 3 Scenario 3 Bridge 4 ROM RAM Peripheral 3 Peripheral 2 Peripheral 1 ÔwÔwÔ ÔwÔwÔ ÔwÔwÔ ÔwÔwÔ ÔwÔwÔ ÔwÔwÔ ÔwÔwÔ ÔwÔwÔ ÕwÕwÕ ÕwÕwÕ ÕwÕwÕ ÕwÕwÕ ÕwÕwÕ ÕwÕwÕ ÕwÕwÕ ÕwÕwÕ
FIG. 3.10 – Architecture cible de Napkin-to-Chip
Les bibliothèques utilisées sont dénommées Processor Support Packages (PSP) et contiennent un modèle générique d’AL spécifique à un processeur et les modèles d’adaptateurs spécifiques aux protocoles. Ces protocoles sont
implémentés par des connexions point-à-point physiques suffisantes pour satisfaire au modèle de calcul RPC adopté par CoWare. Le choix des protocoles supportés est le suivant :
NoHndshk : Utilisation d’un unique signal véhiculant les données. Aucun signal de contrôle, de synchronisation ou de sécurisation (parité) n’est utilisé. Les consommateurs de données échangées avec ce protocole doivent
Ce protocole voit donc son utilisation restreinte à la configuration de processeurs matériels par un processeur de logiciel.
EnHndshk : Ce protocole synchrone (partage d’un même signal d’horloge par les deux terminaisons du canal) utilise en plus du signal de donnée, un signal « Enable » autorisant sa prise en compte. Cette autorisation est
matérialisée par l’affirmation de ce signal durant les cycles d’horloge voyant la donnée valide.
La donnée devant être prête lors de l’autorisation, ce protocole ne saurait être conseillé que pour les cas suivants : – C’est le producteur de données qui initie la communication (« outmaster inslave ») ;
– La latence de réponse du producteur esclave (« outslave inmaster ») est fixe et connue.
FullHndshk : ou protocole rendez-vous à quatre phases permet la synchronisation des deux terminaisons à l’aide d’un signal d’initiation (« request ») et d’un signal d’acquittement (« acknowledge »).
MemEnHndshk : ce protocole est une évolution du protocole EnHndshk auquel un signal d’adresse a été ajouté. Il est ainsi possible de communiquer avec un processeur matériel comme avec un bloc de mémoire SRAM.
MemFullHndshk : l’ajout d’un signal d’adresse au protocole FullHndshk permet l’accès à une donnée dans un tableau enfoui dans le processeur matériel, tout en synchronisant cet échange par un mécanisme de rendez-vous.
Cette approche comporte plusieurs limitations. La restriction de modélisation du comportement au modèle de calcul RPC permettant à N2C la mise en place de l’ordonnancement de l’exécution des différentes fonctionnalités
concurrentes sur des ressources restreintes (le processeur logiciel). Les communications sont restreintes au modèle point-à-point ; Les données échangées sont des vecteurs de bits (à tous les niveaux d’abstraction), ce qui suppose que les tâches applicatives doivent elles-même préparer et éventuellement découper les données en mots pouvant ëtre transmis. De plus ceci impose une représentation unifiée des données dès le niveau UT et restreint fortement les solutions d’implémentation des communications. L’absence d’un niveau d’abstraction équivalent au niveau
« Message » (cf. 3.2.3) est implicitement traduite par une limitation de l’outil à ne supporter qu’un ensemble restreint d’architectures cibles, toutes issues du modèle générique monoprocesseur et à communications point-à-point.
L’absence de découplage entre les ressources de calcul (le processeur de logiciel) et le contrôle des communications ne permet l’exécution concurrente de fonctionnalités de calcul et des communications. L’utilisation de ressources allouées et assignées bijectivement aux canaux de communication interdit le partage de ressources matérielles (telles que des contrôleurs de DMA, d’encodeur, etc...) par plusieurs communications.
O’Nils et Program
[67, 68] présentent une méthodologie de conception d’architecture matérielle à base de processeurs communicants par des protocoles différents. Ces travaux traitent de la spécification et de la génération de ces adaptateurs de
communications, mais cette opération n’est pas globalement automatisée.
Cependant un environnement de cosynthèse et de prototypage est proposé : [94]. Dans cet environnement, la génération d’adaptateurs matériels de composants est adressée par Program[65]. Conscient que les approches Interface-Based (telles que [79]) sont limitées par la disponibilité de bibliothèques suffisamment fournies pour adapter toute la diversité de protocoles existants, Program présente une nouvelle approche pour la spécification d’interface matérielle de communication, basée sur la modélisation du comportement de l’interface par une grammaire régulière. Un outil est alors utilisé pour générer un automate de reconnaissance des lexèmes, conceptuellement très proche des outils d’aide à la conception d’analyseur syntaxique pour les compilateurs tels que GNU Yacc. Il en résulte un modèle VHDL RTL, implémentant par des machines d’états finies, les automates de reconnaissance.
La contribution principale de ces travaux est une méthodologie et un outil de conception d’adaptateur basée sur une modélisation « grammaticale » du comportement de l’adaptateur, certes plus concise que par l’utilisation d’un HDL, mais encore manuelle.
Protocol Compiler[88, 80] de Synopsys est un autre exemple très similaire de cette approche basée sur des expressions
régulières.
GAUT
GAUT[4] est un outil de synthèse comportementale (cf. figure 3.11(a)). Il permet la génération des interfaces matérielles appelées Communication Unit (UCOM). Le réseau d’interconnexions mis en œuvre est une nappe de connexions point-à-point reliant un unique processeur de logiciel à plusieurs accélérateurs matériels. Il est basée sur
une analyse formelle des communications de l’application et sur leur assignation à des protocoles faisant partie des spécifications. Il permet de générer des modèles VHDL RTL synthétisable tant pour les accélérateurs que pour les unités d’adaptation. Gaut est orienté architecture monoprocesseur (cf. figure 3.11(b)). L’utilisation de cet outil est envisageable dans le cadre d’architectures multiprocesseurs, si son analyse globale des communications peut supporter la complexité des réseaux embarqués. De plus l’utilisation de connexions point-à-point rend coûteuse la mise à l’échelle du modèle architectural et donc son utilisation pour des systèmes multiprocesseurs fortement communicants.
GAUT Component Library Asic Design * Processing Unit * Control Unit * Memory Unit Hardware Interface Generation Commercial CAD Structural Synthesis * Busses * Protocols
* Processor I/O Transfert sequences
Specifications Interface Software Module Generation System Specification Partitioning Step VHDL Specification
PU I/O Transfertsequences
(a) Flot de conception.
UCOM Processor PU IN_FIFO OUT_FIFO REGISTERS Asic Controller (FSM) Internal Busses I/O Busses Control links Hardware Interface (b) Architecture cible.