• Aucun résultat trouvé

Traduction des blocs HiLeS en VHDL-AMS

3. Une plate-forme de conception amont

3.5 Passerelle HiLeS Designer vers VHDL-AMS

3.5.1 Traduction des blocs HiLeS en VHDL-AMS

Une première étape fondamentale de la transformation d’un projet HiLeS Designer en VHDL- AMS est la traduction des blocs structuraux et fonctionnels. Ces deux types de blocs permettent de définir la structure d’un projet et doivent être cohérents avec une structure standard VHDL-AMS construite à base d’entités et d’architectures.

Ici, notre objectif est de montrer la manière dont l’on peut modéliser en VHDL-AMS les différents éléments du formalisme HiLeS. Cette étape est tout à fait nécessaire pour permettre à l’approche HiLeS de parvenir au stade souhaité du prototype virtuel. Le langage VHDL-AMS paraît le

mieux adapté à ce niveau général. En effet le langage de description matériel VHDL-AMS permet de décrire des modèles multi-abstractions, pluridisciplinaires, hiérarchiques continus et discrets.

3.5.1.1 L’interprétation du niveau zéro

Avant de rentrer dans les équivalences précises de chaque type de bloc, il est pertinent d’analyser le cas particulier de notre premier niveau de représentation : le niveau zéro. Celui ci va représenter le système dans son contexte. Nous pouvons considérer l’environnement du projet ou niveau zéro, proposé précédemment (§3.3.1), non seulement comme son environnement opérationnel mais aussi comme son environnement de test. Dans ces conditions, la représentation de plus haut niveau du projet créé sous HiLeS Designer peut être modélisée sous VHDL-AMS comme une entité

TestBench. L’utilisateur pourra aussi le réutiliser avec d’autres configurations du système grâce à

notre implémentation des architectures multiples (§2.9.1.3) tout à fait cohérente avec le langage VHDL-AMS. Le concept de TestBench sert à modéliser un système et son environnement afin d’en évaluer son fonctionnement. Nous pouvons établir ce rapprochement entre les concepts de niveau zéro HiLeS et le testbench de VHDL-AMS car l’un comme l’autre représentent le niveau d’abstraction le plus élevé de chaque modélisation, qui va permettre de modéliser le système et son environnement. L’architecture de ce niveau zéro va être décrite de manière structurelle en instanciant et en reliant les différents blocs entre eux via les différents canaux. La création des signaux, quantités, terminaux locaux en VHDL-AMS sont réalisés automatiquement lorsque l’utilisateur relie les différents blocs entre eux par le biais de l’interface graphique.

La Figure 3-10 a, b, montre un exemple de schématique type créé sous HiLeS Designer. A gauche un exemple de niveau zéro, le réseau de pétri cadence l’exécution des actions dans l’environnement du système. Pour simplifier la lisibilité de ce niveau, nous pourrions imaginer cette procédure construite avec des réseaux de Pétri regroupée en un seul bloc de commande, comme le suggère le pointillé rouge de la figure. Le bloc Test_F_1 et le réseau de Petri comportent l’environnement du « System ». A droite nous présentons l’architecture du bloc « System ».

a. Exemple de niveau zéro b. Détail du bloc Structural_1, niveau -1

Figure 3-10. A gauche, une possible représentation d’un TestBench sous HiLeS. A droite, le contenu du bloc « System ».

Chapitre 3 : Une plate-forme de conception amont 87

3.5.1.2 Interprétation des blocs structurels

En général, nous modélisons les blocs structurels comme des entités dont l’architecture est décrite de manière structurelle en instanciant et en reliant les différents blocs contenus à l’intérieur. Dans notre exemple, l’architecture de « System » est montré dans la Figure 3-10b. L’entité possède des entrées/sorties qui interviennent dans l’architecture qui correspondent à celles qui ont été définies au niveau zéro. Ainsi au niveau 0, nous réalisons la définition du nom de l’entité lors de la création du bloc, son « port map » et son « generic map ». Tel que nous l’avons déjà présenté (Figure 2-32), la section d’information de chaque bloc, l’outil HiLeS Designer permet de créer et de définir les paramètres génériques.

Concernant les ports, les interfaces développées permettent de spécifier le nom, l’objet (signal, terminal, quantité), le type (std_ulogic, bit, etc…) ou la nature (electrical, thermal, etc…). L’utilisateur a la possibilité de choisir une ou plusieurs bibliothèques à utiliser lui donnant accès à des natures et des types. Il peut aussi appeler une bibliothèque non prédéfinie. Pour s’assurer une meilleure compatibilité avec les principaux outils existants, il est préférable de laisser à l’utilisateur le soin d’inscrire les bibliothèques qu’il souhaite utiliser pour son modèle. Initialement notre objectif était de ne pas associer HiLeS Designer à un simulateur en particulier, mais au fur et a mesure que nous progressons dans le projet, nous pensons à la possibilité de proposer des « templates » ou formats prédéfinis orientés vers le logiciel de simulation souhaité par l’utilisateur. Cette solution s’impose car les noms des bibliothèques varient suivant l’outil que l’on utilise pour faire la simulation.

Par rapport à la définition de l’architecture, l’utilisateur peut aller à l’intérieur du bloc en utilisant la fonction « Go Inside » (décrite en §2.9.1.1). Cette option permet de définir le nom de l’architecture ou de choisir parmi d’autres déjà définies pour l’entité ou bloc père du niveau supérieur. Les ports d’entrées\sorties sont répertoriés et transcrits automatiquement au niveau de l’architecture en cours de définition (Figure 3-10 b).

A terme, nous pourrons envisager l’utilisation d’un bloc déjà créé et disponible dans une bibliothèque, ayant la possibilité de choisir son architecture s’il en existe plusieurs et préciser ses paramètres génériques. Cela équivaut en VHDL-AMS à instancier une entité déjà compilée et stockée dans une bibliothèque.

3.5.1.3 Interprétation des blocs fonctionnels

Ainsi que les blocs structurels, les blocs fonctionnels représentent eux aussi une entité. Lors de leur création sous HiLeS Designer on peut nommer l’entité et définir le « generic map ». Le « port map » est généré automatiquement par HiLeS Designer en fonction des connexions du niveau supérieur. Concernant l’architecture de l’entité, elle est accessible directement par le biais de l’interface présentée en §2.9.1.6. L’utilisateur peut écrire directement l’architecture VHDL-AMS en utilisant l’éditeur inclus dans l’outil. Rappelons ici que ce type de bloc ne comporte pas, au niveau de HiLeS, des propriétés hiérarchiques. Toutefois, cela n’empêche pas le concepteur de définir des hiérarchies directement dans le code en instanciant des composants précédemment compilés.

A l’heure actuelle, HiLeS Designer ne permet qu’une architecture par bloc fonctionnel, mais on peut envisager de créer plusieurs architectures pour une même entité (bloc). Le choix de l’architecture pourrait se faire parmi une liste d’architectures disponibles, de la même façon dont nous pouvons définir l’architecture par défaut (§2.9.1.3) d’un bloc structurel. La traduction de cette possibilité en

VHDL-AMS consiste à la création d’une configuration ou d’une instanciation du type : composant : entité(architecture).

Pour profiter pleinement de la norme VHDL-AMS, il est préférable de raisonner en terme d’unité de conception (code compilable seul). Ainsi il existe cinq types d’unité de conception : l’entité, l’architecture, la configuration, le paquetage (déclaration et corps). Néanmoins, telle architecture ne pourra être compilée que si l’entité à laquelle elle est associée à déjà été compilée. Il faut mettre en place un système d’étiquettes afin qu’une unité de conception faisant appel à une autre ne soit pas compilée avant celle-ci.

3.5.1.4 Interprétation des canaux

Sous HiLeS Designer, l’utilisateur peut nommer le canal, mais aussi lui donner un type ou une nature. Ces caractéristiques sont étroitement liées avec celles des ports auxquels est relié le canal. Ainsi si l’on relie le canal à un port possédant un type déjà défini, le canal possédera automatiquement ce type. La norme VHDL-AMS impose un typage fort qui permet de ne connecter ensemble que les choses compatibles.

Selon le sens des canaux HiLeS, les sens des ports sont forcés en mode in ou en mode out, sauf dans le cas des terminaux qui, par définition de la norme, n’ont pas de mode. Dans ce dernier cas, la direction des canaux a du sens uniquement au niveau de la représentation graphique comme une guide pour le concepteur. En spécifiant le champ type d’un port, on force le type des canaux reliés à ce port et inversement. Il est très souhaitable d’élargir la vérification de cohérence des connexions sous HiLeS. Pour l’instant, nous vérifions uniquement le type dit HiLeS (continu, discret ou arche de réseau de Petri) et non leur contenu proprement dit, leur définition VHDL-AMS. Ceci est nécessaire pour garantir la cohérence entre niveaux hiérarchiques et dans les connexions entre éléments de même niveau. Dans la version actuelle de HiLeS Designer, nous avons inclu la possibilité d’accéder aux caractéristiques des ports. Lors de la création d’un port, l’utilisateur peut le configurer en utilisant l’interface suivante :

Chapitre 3 : Une plate-forme de conception amont 89

3.5.1.5 Problème : Les bibliothèques du projet

Une des difficultés importantes lors de l’implémentation d’une passerelle avec le langage VHDL-AMS est l’utilisation des bibliothèques dans les projets. Le concepteur doit pouvoir choisir les différentes bibliothèques utiles à son entité. Cependant ce choix est fortement lié à l’outil final de simulation. En l’état, l’utilisateur doit définir lui-même les bibliothèques qu’il utilise dans chaque bloc. Cette méthode permet à HiLeS de ne pas être dépendant d’un outil de simulation et permet aussi à l’utilisateur d’appeler ses propres bibliothèques. En revanche, elle exige un effort supplémentaire de sa part au moment de compiler le projet en utilisant un logiciel en particulier car les noms de ces bibliothèques et de ces packages peuvent varier d’un outil de simulation à un autre. En conséquence, une adaptation spécifique du projet est impérative. Tel que nous l’avons mentionné précédemment (§3.5.1.2) nous envisageons la définition de « templates » ou formats spécifiques pour rendre possible la pré-configuration d’un projet HiLeS Designer selon l’outil ciblé.