CO-SIMULATION

Cette est une présentation générale d’un nouvel outil de CAO électronique qui permet de combiner à la fois un simulateur logiciel et un simulateur matériel.

La lecture de ce document s’adresse principalement à ceux qui ont des notions de conception électronique,

Bonne lecture

BigRem 2000.

Généralités

I. Objectif

Le sujet de ce rapport concerne la mise en œuvre d’un démonstrateur de Co-Simulation, à partir de l’outil SEAMLESS CVE (Co-Verification Environnement) de la société Mentor Graphics.

Le but de la Co-Simulation est de gagner du temps sur la réalisation et la validation d’un prototype physique, en essayant de trouver, et donc de résoudre, d’éventuels problèmes en amont de ces phases, lors de la conception. Le gain de temps estimé est de l’ordre de 20%.

Il répond aussi à différents besoins émanant de différents groupes :

La Testabilité/IMS désire vérifier plus tôt l’équipement électronique afin d’y déceler plus rapidement les éventuelles erreurs matérielles ou logicielles. Il s’agit aussi de pouvoir debugger leurs logiciels de test

la conception d’ Asic désire approfondir la simulation entre un cœur CPU et un Asic (vérification du premier niveau des accès E/S), permettant ainsi une meilleure intégration des composants spécifiques sur le circuit imprimé (PCB).

L’architecture chargé de l’élaboration du schéma électrique veut avoir la possibilité de pouvoir essayer facilement différents processeurs afin de déterminer rapidement l’architecture la plus appropriée et de pouvoir évaluer plus facilement la performance des cartes.

La Méthode pour évaluer son intérêt au niveau du Co-Design, de la réutilisation…

D’un aspect général, la Co-Simulation doit permettre une validation au plus tôt (tests unitaires de routines inchangés), en intégration éviter les reprises matériel/logiciel (ex : accès 32 bits au lieu de 8 bits, asynchronisme…), améliorer le suivi de la carte (bibliothèques de tests…).

Le matériel testé est celui embarqué, mais le logiciel utilisé est un logiciel de test chargé de vérifier le fonctionnement correct de la carte (et non pas le logiciel final embarqué).

II. Normes pour le matériel

La mise en œuvre de l’outil de Co-Simulation s’inscrit dans un contexte bien défini. Pour résoudre les problèmes d’intégration des circuits de plus en plus nombreux avec les problèmes de sécurité et de certification qui en résultent nous devons respecter, entre autres, la norme qui concerne tout l’équipement matériel complexe embarqué (carte ASIC, FPGA...):

1. Un équipement doit remplir son rôle.

2. Tout doit être conçu pour qu’une panne n’interdise pas la poursuite du vol.

3. Toute panne qui affaiblit l’avion doit être improbable.

Il est donc souhaitable de rechercher des erreurs de conception, d’évaluer le niveau de criticité (fonction, taille du circuit, sûreté de fonctionnement), de définir les moyens pour concevoir l’équipement (composants standards, réutilisés), et enfin obtenir la qualification des outils.

La Co-Simulation, qui permet une vérification fonctionnelle de la carte, s’inscrit tout à fait dans cette démarche

La notion de Co-Simulation permet de vérifier la cohérence entre un logiciel, exécuté par un microprocesseur, et le matériel, pour lequel il s’exécute, sans passer par un prototype physique.

Nous allons étudier la mise en œuvre d’une carte électronique afin de mesurer l’intérêt de la Co-Simulation aujourd’hui, et du Co-Design demain.

III. Processus de développement d’une carte électronique.

Pour saisir l’intérêt de la Co-Simulation, il est intéressant d’étudier le processus de développement d’une carte électronique afin de mettre en relief les points améliorables par ce nouvel outil d’aide à la conception.

Le processus de développement se fait en 3 étapes :

1. Spécification et conception : architecture matérielle globale du système.

2. Etape de réalisation : tous les sous-ensembles matériels implantés.

3. Etape de validation des sous-ensembles, intégration, qualification.

Dans la première étape, on décompose l’ensemble matériel en 5 sous-ensembles :

1. Cartes et circuits hybrides Numériques/Analogiques.

2. Circuits spécifiques ASICS.

3. Alimentation.

4. Fond de panier.

5. Sous-ensemble mécanique.

La spécification fixe les exigences et offre une représentation, globale et détaillée, en termes de fonctionnalités et de contraintes.

Les deuxièmes et troisièmes étapes peuvent être optimisées par les processus de Co-Design et Co-Simulation.

Etapes de développement avec et sans Co-Simulation :

IV. Co-design

Actuellement, la conception d’une carte électronique respecte le schéma suivant :

1. Matériel élaboré et vérifié.

2. Logiciel débuggé.

3. Intégration du logiciel et du matériel. Une modification du matériel en cas de conflit est une étape coûteuse et longue qui peut prendre la moitié du temps du projet. Nous ne modifions pas le logiciel, car nous considérons les modifications à lui apporter plus complexes que pour le matériel.

4. Validation du matériel.

Nous pouvons dissocier deux types de sous-ensembles électroniques numériques :

Matériel: modélisé en VHDL (base de données pour la fonderie pour un ASIC...

Logiciel : L’image que doit exécuter le microprocesseur. Il est spécifié en langage évolué ou en code assembleur (microprocesseur fixé au départ).

Une fois la spécification réalisée, nous pouvons introduire le terme de CO-DESIGN qui permet de partitionner l’algorithme obtenu entre ce qui doit être fait en matériel (HW) ou en logiciel (SW).

En effet, comme il y a plus de similarités que de différences entre la conception logicielle (C) et VHDL, il est envisageable de ne plus différencier les groupes de recherches en utilisant le même outil. Cet outil devra prendre en compte l’interface et les limites qu’apportent le matériel.

3 approches sont alors envisageables :

1. Approche orientée matériel : On suppose que tout est fait en HW et on voit ce qui pourrait être fait en SW avec le critère du temps.

2. Approche orientée logiciel : Opération inverse, mais la solution est moins bonne car elle dépend de l’algorithme retenu.

3. Approche constructive : On n'a pas d’à priori. On construit le sous-ensemble de façon progressive (méthode par clusters).

On construit alors un prototype virtuel qui permet la validation conjointe du matériel et du logiciel. Nous arrivons ainsi à la notion de CO-SIMULATION pour l’instant numérique, aujourd’hui première étape vers le CO-DESIGN qui permet de conduire parallèlement les outils de compilation (C) et les outils de synthèse (VHDL).

V. Co-Simulation

V.a - Principe

Un co-simulateur permet de faire le lien entre un microprocesseur et le matériel qui lui est associé. Les simulateurs numériques actuels nécessitent, pour la vérification d’un ASIC par exemple, de rentrer des vecteurs de test et de comparer le résultat avec la réponse attendue, ce qui est fastidieux.

Nous introduisons alors le principe de «prototype virtuel » pour le matériel, qui permet au SW de tourner sur le HW sans réalisation physique de celui-ci.

L’idée est de transformer le code C/C++, en vecteur de test pour le HW. Ainsi le même processus fait tout (émulateur).

Un des problèmes qui se pose est que, pour un modèle fonctionnel, le fonctionnement du matériel est plus rapide que pour le logiciel (HW en ns et SW en ms), alors que les outils de simulation numériques actuels réalisent l’inverse : Un simulateur numérique est de l’ordre de 1 -> 100 instructions/s, alors qu’un simulateur logiciel est de l’ordre de 100 000 instructions/s.

Le concepteur doit être capable de simuler le HW à une vitesse suffisamment rapide pour que le logiciel puisse fonctionner. Ainsi le debug du SW et du HW sont proches.

Comme on est incapable d’augmenter considérablement la vitesse des simulateurs HW, l’idée de l’outil de Co-Simulation est de décharger le simulateur numérique (lent) de tâches qui présentent peu d’intérêt pour le test vers le simulateur logiciel qui lui travaille beaucoup plus rapidement.

Ainsi, en mettant du code HW (code et références données par exemple) en SW, une partie du HW n’est plus simulé par son simulateur. L’inconvénient est que l’on considère cette partie HW passée en SW comme parfaite (exempte d’erreurs de conceptions).

SEAMLESS CVE permet différents niveaux de précision, qui permettent de paramétrer ces passages. En effet, utilisant le principe d’allocation mémoire dynamique, quand les références mémoires et leurs effets ne sont pas importants, on peut les mettre dans le domaine SW, et plus tard les remettre dans le domaine HW tout en conservant un niveau de performance et de détails élevés dans la simulation HW.

L’outil simule donc le système entier avec des outils de debuggage. Il synchronise le SW et le HW avec la possibilité d’y inclure des breakpoints HW ou SW. On peut optimiser le temps en réduisant les opérations SW sur le simulateur logique.

On peut ainsi mettre en œuvre deux méthodes différentes :

1. Celles qui n’utilisent pas de modèle de microprocesseur. On a une description algorithmique du logiciel, avec un protocole de synchronisation entre les deux processus utilisant les mécanismes de synchronisation inter-processus.

2. Celles qui utilisent un modèle de microprocesseur qui exécute le logiciel. La solution est alors d’émuler l’ensemble des instructions du microprocesseur, ce qui épargne à l’outil de simulation de simuler ce qui se passe à l’intérieur du microprocesseur [pipeline, décodage, adressage...]. On atteint ainsi l’ordre de 2000 -> 20 000 instruction/s. Cette solution a été retenue par Mentor Graphics pour l’outil SEAMLESS CVE.

V.b - Langage logiciel

Le fait de programmer le logiciel en langage évolué (pour SEAMLESS le C), nous permet d’essayer différents microprocesseur, ce qui nous permettra d’estimer la performance du logiciel (temps d’exécution, espace mémoire programme/données). Le langage C/C++ a été retenu car il utilise les compilateurs les plus performants. De plus, avec l’utilisation de microprocesseur pipeliné, l’utilisation de l’assembleur n’a plus d’objet.

V.c - Exemple concret

Un automate, intégré dans un ASIC en dialogue avec un microprocesseur, reste pour une raison indéterminée dans une boucle infinie. L’outil de Co-Simulation renseigne précisément l’opérateur sur l’état du SW et du HW. Dans ce cas-ci par exemple, la solution peut être une écriture dans une mauvaise adresse RAM par le SW entraînant une mauvaise interprétation du HW.

C - CARTE - CIBLE

I. Choix de la carte

L’hypothèse de base est de choisir une carte-cible et qui est actuellement opérationnelle sur un calculateur embarqué. Sur cette carte, il est nécessaire d’y trouver des composants types pour lesquels la Co-Simulation apporte des avantages en terme de coûts et de temps de développement tels que les circuits programmables.

De plus, ces composants doivent présenter un intérêt pour le futur et donc ne doivent pas être obsolètes.

Le calculateur est composé de 5 cartes, dont 3 sous-ensembles électroniques :

1. La carte CPU pilote le calculateur.

2. La carte IO gère les entrées/sorties du système.

3.Carte communication ARINC

4. L’alimentation

5. Le fond de panier.

I.a - Carte retenue.

A partir des critères précédemment cités, nous avons retenu la carte CPU qui a l’avantage d’être relativement simple électriquement et complète. En effet, nous y trouvons :

1 microprocesseur (microprocesseur) 486 DX 4 nécessaire à la Co-Simulation et disponible dans la bibliothèque CVE.

2 circuits logiques programmables FPGA développés en VHDL.

des SRAMs, des EEPROMs, des buffers...

I.b - Cartes rejetées.

Les cartes alimentations (PSM), fond de panier (BPC) et IOM ne possèdent pas de microprocesseur donc présentent un intérêt faible pour la Co-Simulation.

La carte communication s’articule principalement entre un ASIC un microprocesseur obsolète

Mais il faut noter qu’une nouvelle version de cette carte s’articule entre l’ASIC et un DSP C31. Mais pour l’instant l’outil de Co-Simulation SEAMLESS ne supporte pas ce type de composant. Ce qui explique que cette carte est pour l’instant rejetée mais présente un intérêt pour l’avenir.

II. Choix de l’ASIC.

Sur la carte CPU nous ne trouvons pas d’ASIC. Suite à un entretien avec le service ASIC, cette idée, en terme de complexité de mise en œuvre et d’intérêt pour ce service, a été abandonnée au profit de l’utilisation d’un ASIC expérimental BigAsic. Nous abandonnons alors l’idée de co-simuler une carte parfaitement connue. Ce choix implique deux contraintes :

1. Il ne possède pas de logiciel de test (IMS). Il faudra développer un nouveau module de test.

2. Son comportement dans un circuit est inconnu.

Un avantage non négligeable est que ces inconvénients permettront une première évaluation réelle et justifiée de la Co-Simulation pour l’intégration et la validation d’un circuit spécifique.

III. Présentation détaillée

Nous allons présenter les différentes fonctionnalités du matériel que nous allons co-simulé, pour ensuite aborder le schéma électrique retenu pour la Co-Simulation.

III.a - Blocs fonctionnels

Notre première intention était de co-simuler la carte CPU1_486 entièrement avec le module BIGASIC. Mais le risque d’avoir une carte trop complexe pour le simulateur nous a fait abandonner le bloc fonctionnel en rapport avec l’interface du bus ECSB, chargé de gérer les communications entre les différentes cartes du calculateur. Le schéma bloc fonctionnel retenu est :

CODE VHDL

FPGA

Prog.VHD

ASIC

FPGA

Les principales caractéristiques de chaque bloc sont :

CPU_CORE:

CPU 486 DX 4 : Cœur Microprocesseur, 60 Mhz.

Horloge : Cadence le système à 20Mhz

Contrôle L0 : FPGA chargé du contrôle du cœur CPU (Accès FLASH, µP) et de la gestion des interruptions. Cadencé à 40Mhz

FLASH : EEPROMs où sera stocké le logiciel de test.

L1_CORE:

Interface_L1 : Buffers entre les bus LO et L1 cadencés à 20 Mhz.

Contrôle_L1 : FPGA chargé de l’accès aux ressources du bus L1, des 2 liaisons RS232, gestion de 2 horloges temps réel et du contrôle activité du microprocesseur. Cadencé à 20Mhz.

EEPROM : Mémoire où seront stockés les résultats des tests.

RAM : Mémoire vive nécessaire au fonctionnement (Minimum 2 Mo).

CMD : Port de commande en écriture.

COM / STAT : Port de status en lecture.

MODULE BIGASIC: : Emission radio. La partie numérique composée de RAMs, jouant le rôle de FIFO, et d’un FPGA qui sera un terme un ASIC.

Pour limiter la complexité du schéma électrique, une simplification de certains blocs fonctionnels a eu lieu en accord avec le service Numérique :

Seules 4 EEPROM FLASH sur 8 ont été retenues.

4 RAM sur 20 suffisent. Seules les RAMs sauvegardées ont été conservées.

IV. Schéma électrique

IV.a - Saisie du schéma

Sous chaîne IAO, nous reprenons le schéma électrique de la carte CPU.

IV.b - Outils XAO

Un compte sur les stations Sun de développement XAO a été créé sur lequel ont été rapatriés tous les schémas de saisie nécessaires.

Sur cette chaîne de développement, nous aurons besoin de :

Design Architect V8. Saisie du schéma électrique.

Design view point. Adaptation des fichiers du schéma au simulateur logiciel.

Config view point. Rajoute des propriétés CVE à la schématique.

SEAMLESS CVE. Outil de Co-Simulation, réalise le lien SW / HW.

XRAYPRO. Il joue le rôle d’ISS et de débugger logiciel.

QUICKSIM II. Simulateur matériel.

QHPRO (combinaison de QUICKSIM II et QUICKHDL). Simulateur numérique. Quicksim II simule le schéma électrique et QUICKHDL est nécessaire pour simuler et débugger le VHDL contenu dans les FPGAs et ASICs.

IV.c - Bloc fonctionnel électrique.

Sur le schéma bloc retenu, Nous y retrouvons les 3 grands blocs fonctionnels qui incluent les fonctionnalités décrites précédemment :

V. Identification de la partie logicielle

Le logiciel à simuler doit permettre avant tout de mettre en valeur le mieux possible le Démonstrateur. Il doit de ce fait s’adapter à l’architecture du matériel cible. Ce logiciel se compose d’une interface visuelle et de plusieurs modules de tests appelés IMS.

D’une part, l’ interface visuelle est chargée de gérer le déroulement du logiciel et donne accès aux différentes commandes relatives aux tests en permettant d’activer les fonctions matérielles du calculateur.

D’autre part, les modules de tests IMS permettent de vérifier le fonctionnement de ces dernières. Chaque module teste une fonction particulière du calculateur telles que les lectures/écritures mémoires, le test des entrées/sorties, des timers, etc…

D - SEAMLESS CVE

La carte cible maintenant identifiée, nous allons en œuvre l’outil de simulation. Ce chapitre a pour but d’expliquer cet outil. Le choix s’est porté sur SEAMLESS CVE de la société MENTOR GRAPHICS pour deux raisons.

Ce produit est un produit phare (80% du marché de la Co-Simulation).

La chaîne de développement XAO du Département Electronique utilise principalement des produits Mentor Graphics. En particulier pour la chaîne IAO, saisie de schéma (DESIGN ARCHITECT) et la simulation numérique (QUICKSIM II).

SEAMLESS utilise le modèle BLMS (Behavorial Language Models) qui permet de décrire le comportement d’un symbole graphique en C, puis de le simuler à l’aide de QUICKSIM II. Ainsi, il utilise le Bus Interface Model (BIM) qui simule les Entrées/Sorties du processeur.

Seamless CVE peut être décomposé en 3 parties distinctes :

Co-Simulation kernel : Il s’agit du noyau de la Co-Simulation qui contrôle les communications entre le logiciel et le matériel. Il permet de configurer plusieurs aspects de la Co-Simulation à travers la CONFIGURATION MANAGER.

Instruction Set Simulator (ISS) ou Host Code Execution (HCE) s’occupe de la partie logicielle.

ISS exécute le code machine fournit par le compilateur du processeur spécifique.

HCE est un logiciel écrit en haut niveau et compilé pour une exécution directe sur la station de travail.

Debugger Interface contrôle l’exécution des ISS et HCE exécute les opérations comme le pas à pas, examine les registres et la mémoire et d’autres fonctions de debuggage.

Hardware Simulator Interface et Hardware Simulation Kernel se charge de la partie matérielle. Le noyau exécute un schéma avec 1 ou plusieurs BIMs et les modèles mémoires (sRAM, dRAM, FIFO…) CVE.

Synoptique Seamless CVE.

I. ISS (Instruction Set Simulator)

Il s’agit d’une modélisation abstraite, spécifique, d’un processeur. Il est rapide car il n’a pas à calculer tous les signaux de transitions.

Il charge, décode et exécute l’instruction. En utilisant une interface de debug, on peut contrôler et visualiser l’exécution du logiciel dans le système.

Un modèle exécutable, qui contient le code machine pour le processeur visé, est chargé dans l’ISS (ce qui signifie l’espace d’adresse du processeur).

Ce module exécutable, peut être généré à partir d’un langage haut niveau, d’assembleur ou un mélange des deux, qui est compilé puis linké. Nous pouvons ainsi utiliser des logiciels de tests écrits soit en assembleur, soit en C.

La première étape consiste donc à éditer le logiciel (ici, les IMS). Ensuite nous devons compiler ce programme pour fournir le code exécutable à l’ISS. Ce code devra être au format du microprocesseur utilisé (i486DX pour la carte cible).

Le logiciel appelé à cette étape joue à la fois le rôle d’ISS et de debugger. Il s’agit de XRAYPRO de Microtec. Nous chargeons dans XRAY le programme exécutable préalablement compilé et linké. Nous avons ensuite la possibilité de faire du pas à pas, de placer des points d’arrêt…

La chaîne de compilation et de linkage n’est pas fourni par CVE. Nous devons prendre en compte que XRAY (xhcx86) n’autorise que certains formats :

IEEE 695 (format de debug standard).

COFF (Unix system V antérieure version 4).

ELF (Unix system V version 4).

DWARF (Extension de ELF incorporant des instructions de debug utiles pour XRAY).

Stabs (DSB debugger Unix).

OMF386 (Intel).

La chaîne de compilation actuelle, sous VAX, nous permet d’utiliser le format Intel OMF386. Comme ce format n’était pas mentionné dans la documentation CVE comme compatible, le service logiciel s’en est assuré auprès de MRI (éditeur de XRAY).

Nous pouvons utiliser aussi la chaîne GNU (gcc –o –gdwarf …) de CYGNUS, ou LYNX, mais cela entraîne une adaptation des différentes bibliothèques. Il est donc préférable, pour des questions de commodités, d’utiliser la chaîne VAX.

II. HCE (Host Code Execution)

Une autre solution pour la partie logicielle est le HCE. Cette méthode utilise les ressources de la station de travail. On utilise en effet le compilateur intégré au système UNIX pour développer le logiciel adapté au matériel. Le programme est ainsi compilé et exécuté directement par la station. On a alors un gain de vitesse par rapport à l’ISS.

Cette solution permet en plus de tester directement le langage haut-niveau avec le simulateur matériel sans avoir de code machine disponible. Pour lier la simulation matérielle avec le logiciel, on passe à travers les API (Application Program Interface) qui exporte le code compilé vers le BIM.

Concrètement, on place en appel dans le code source haut niveau les fonctions API (librairie CVE). On compile alors le langage haut-niveau sur les stations de travail. On obtient ainsi un module exécutable pour la station de travail qui peut fonctionner avec le simulateur matériel.

Le debuggage peut être fait en utilisant un debug standard sur Unix type.

Nous verrons plus tard que certaines optimisations (WARP) ne sont pas possible dans ce mode.

III. BIM (Bus Interface Model)

III.a – Principe

Au niveau matériel, un processeur apparaît comme un composant muni d’Entrées/Sorties liées à des ressources.

Pour CVE, cette interaction est modélisée avec le BIM, qui est le module microprocesseur intégré sur le schéma de la carte cible et simulé sur un simulateur logique.

BIM ne simule que les transitions sur les broches en délaissant la logique interne du processeur. La vitesse est ainsi plus grande, mais on considère ce processeur comme parfait.

Il y a un BIM spécifique pour chaque microprocesseur supporté par CVE. On y retrouve les mêmes caractéristiques que sur le modèle physique, notamment en ce qui concerne les broches.

Le BIM exécute toutes les opérations usuelles d’un processeur :

Lecture / Ecriture en mémoire.

Lecture / Ecriture E/S.

Lecture-modify-ecriture.

Reset et Halt.

Exceptions, interruptions et erreurs.

Requête et validation du bus.

Les accès données Lecture/Ecriture mémoire ou E/S respectent le data book du processeur. Les demandes logiciels sont traduites du ISS ou HCE et les timings sont calqués sur l’horloge du processeur.

Les cycles du bus concernant les accès données sont souvent indicatives et minimales dans les data book, et dans la réalité ces cycles peuvent beaucoup plus longs. CVE prend en compte ce problème, et le BIM renseigne l’ISS afin de déterminer la longueur du cycle désiré.

Le BIM assure l’interface vers le logiciel en ce qui concerne les exceptions tels que les interruptions.

Le BIM assure la simulation des périphériques de microprocesseur tel que :

Timers,

Contrôleur d’interruption,

DMA,

DAC et ADC,

…

Pour chacun des microcontrôleurs utilisés par CVE, ces périphériques sont modélisés.

III.b – Configuration du BIM

Pour la programmation, il est nécessaire de connaître les capacités du BIM, car d’une part nous utilisons un modèle DX et non DX4 et d’autre part le modèle de Co-Simulation, bien qu’il soit fidèle au modèle physique, possède certaines caractéristiques particulières.

On ne peut pas lui rajouter un co-processeur extérieur.

Il ne possède pas de cache pour la mémoire paginée.

Il est conseillé de le nommer (CVE_NAME) pour pouvoir l’utiliser.

Il est possible de configurer XRAY pour avoir les 3 modes de fonctionnement possible (mode réel, linéaire 32, protégé).

Il est possible de régler les délais des broches (référencés en ns par rapport au front montant de l’horloge, par défaut 5ns).

IV. Modèle mémoire CVE.

Si nous désirons profiter des fonctions d’optimisations de CVE, nous devons placer sur le schéma des modèles CVE de mémoires. Pour ceux-ci, nous privilégierons le modèle QUICKHDL de ces modèles.

Nous avons deux possibilités de les adapter.

A partir de da_lms, nous initialisons aux bonnes valeurs les propriétés des composants cve.

A partir de memmaker, nous construisons notre modèle cve de mémoire.

Les modèles de mémoire CVE ont des caractéristiques spéciales qui permettent une vision de la mémoire entre le matériel et le logiciel. Ils peuvent se placer dans le schéma IAO de la carte cible et être simulé comme n’importe quel autre modèle.

En effet, durant la simulation, quand on utilise un modèle conventionnel de mémoire placé sur le schéma IAO, son contenu n’est pas directement accessible par le simulateur logiciel car il faut nécessairement passer par le simulateur matériel. Ainsi, tous les accès à cette mémoire doivent être simulés comme matériel, ce qui est coûteux en termes de calcul et de temps.

Un modèle mémoire CVE permet un accès direct soit par le simulateur logiciel, soit par le simulateur matériel. Il est alors possible d’optimiser ces régions mémoires, comme de permettre de ne pas simuler des accès matériels quand ils ne sont pas nécessaires au simulateur logiciel (accès DMA par exemple), et ainsi permettre plusieurs niveaux de détails.

CVE est fourni avec des modèles génériques de RAM, SRAM, FIFO, REGISTRE. Ces modèles sont paramétrables (Adresse, taille du bus de données, délai d’accès…). Ils peuvent servir de base pour le développement de nouveaux modèles.

Ces modèles sont à 2 états (0 ou 1). L’option indéterminée « X » est possible, utile dans la simulation matérielle. Par exemple, on peut surveiller et déclencher une alarme dès que « X » est écrit dans la mémoire.

V. Optimisations

Une Co-Simulation détaillée peut être très (trop) longue. La version CVE incluant l’ISS peut simuler l’interaction logiciel/matériel à un haut degré de précision tout en permettant une vitesse optimum (déchargement du simulateur numérique, gain de temps). L’idée est de conserver pour la simulation matérielle qui est lente, que les cycles bus CPU utiles pour elle. Par exemple en conservant les lectures/écritures en zone I/O et en supprimant les accès, traitant aux zones mémoires.

Cette optimisation s’articule donc autour de 3 points:

Optimisation de l’instruction FETCH : Toute instruction que doit exécuter le processeur doit être lue en mémoire. En mode détaillé, le simulateur numérique doit prendre en compte cet accès mémoire. CVE permet d’optimiser toutes (ou en partie) les instructions fetchs en masquant la zone mémoire concernée.(Gain de 5x)

Optimisation des accès de données : On peut masquer le simulateur matériel sur des adresses ou zones d'adresses. La majorité des accès mémoires sont nécessaires pour le logiciel lui-même mais n’ont aucune incidence sur le matériel. Mais pour conserver un timing correct, on va respecter le nombre de tops d’horloges (boucle d’attente au niveau matériel), mais permettre l’accès direct mémoire au niveau logiciel. Le fait de conserver le même nombre de top d’horloge ne remet pas en cause l’optimisation car ainsi on a déchargé le simulateur matériel et qui peut donc exécuter d’autres tâches, donc accélérer le processus.(Gain de 10x)

Optimisation du temps (WARP). La simulation logicielle est plus rapide que la simulation matérielle. On place des points de synchronisation à chaque instruction en mode non optimisé (détaillé). (Gain de 100x)

Quand la précision est peu importante, CVE permet d’accélérer le processus en permettant au simulateur logiciel de ne pas attendre le simulateur matériel quand il fait des accès données non optimisés. CVE permet 3 types d’optimisation de temps :

I. Full : Le simulateur matériel s’exécute seulement quand le logiciel lui en donne l’ordre (demande d’un cycle bus). Autrement seul le simulateur logiciel s’exécute.

II. Asynchronous : Logiciel et matériel sont deux processus s ‘exécutant indépendamment.

III. Ratio : Permet de sélectionner le ratio de cycles logiciels par rapport au cycle matériel. Le premier paramètre demande le nombre de tops d’horloges que l’ISS est autorisé à effectuer avant que la simulation numérique ne s’exécute. Le deuxième indique le nombre de tops que le simulateur peut exécuter avant de rendre la main à l’ISS.

Exemple :

ce qui donne :

L’optimisation de temps n’est pas possible en mode HCE. HCE a le contrôle exclusif en mode synchrone ou asynchrone (par défaut).

VI. Mapping mémoire

Le plan mémoire configure une session de Co-Simulation afin de maintenir la cohérence entre les accès logiciels et matériels. Ce plan mémoire est fait manuellement par l’utilisateur, CVE ne vérifie que sa cohérence. Il y a deux types de plan mémoire :

Address range mapping : On définit les zones mémoires et comment elles sont accédées.

Memory Instance Mapping : Indique quel composant est adressé, par quel logiciel sur quel processeur.

VI.a - Address Range Mapping

On partitionne l’espace mémoire en 5 zones. On affecte à ces zones un label (facultatif) afin de pouvoir les cibler avec la CONFIGURATION MANAGER quand on voudra afficher le plan mémoire courant.

On retrouve 4 zones types différentes:

1. Software : L’ISS ne génère jamais de cycle BUS sur le BIM pour accéder à cette zone. Le matériel n’a aucune influence sur cette zone. Si le matériel adresse cette zone, le résultat ne sera pas vu par le logiciel et celui-ci sera purement la conséquence d’un traitement du simulateur matériel. C’est la zone ou l'on pourra placer les accès logiciels qui n’ont pas d’influence intéressante sur le matériel. (Co-Simulation rapide mais pas détaillée).

2. Hardware : Dans cette zone, des cycles de bus BIM seront toujours générés par le logiciel qui pilote la Co-Simulation. Cette zone est idéal pour les I/O, et les mémoires qui ne respectent pas le modèle CVE. (Co-Simulation lente mais détaillée).

3. Optimizable : Cette zone mémoire est optimisante. On va y placer naturellement les composants modèles CVE, afin de modifier selon les besoins les différentes résolutions de Co-Simulation. Le Co-Simulation kernel maintient une visualisation cohérente des accès données.

4. Illegal : Le logiciel ne doit jamais adresser dans cet espace mémoire. En cas d’adressage frauduleux de la part du logiciel, un message d’erreur est généré. Le matériel peut adresser cette zone, mais le résultat sera géré par son simulateur et ne sera pas pris en compte par le cosimulateur.

En mode software et optimizable, on peut rajouter 2 paramètres :

Read Wait states : c’est le nombre de cycles d’attentes à rajouter à chaque instruction simulé qui lit la mémoire dans cette zone.

Write wait states : idem en écriture.

VI.b – Memory Instance Mapping

Les modèles CVE doivent être stockés dans la zone optimisante car seuls les modèles CVE sont capables de communiquer directement avec le Co-Simulation Kernel. Pour ce travail, CVE a besoin de savoir comment les mémoires sont connectés avec le processeur. Ce travail est fait dans la Memory Instance Mapping, qui est une procédure nécessaire pour configurer un nouveau matériel.

Quand nous exécutons la Configuration check, elle nous prévient que nous devons placer dans la totalité de la région optimisante des mémoires CVE. Dans le cas contraire, c’est acceptable bien que la vision de la mémoire devienne sans objet.

VIII. Configuration Manager.

Le MANAGER de CONFIGURATION est responsable de la communication entre l’ISS et le BIM exécutant la partie matérielle de la Co-Simulation.

En utilisant la Configuration Manager, on peut initialiser plusieurs aspects de la simulation :

Associer un logiciel avec le BIM correspondant.

Fixer le Mapping-memory.

Fixer les modèles CVE dans la zone optimisante.

Optimiser les régions mémoires et le temps de simulation.

Démarrer les simulateurs logiciels et matériels.

On communique à travers l’interface :

On y retrouve les commandes suivantes :

File menu, qui permet d’ouvrir l’éditeur, set up, appeler les simulateurs et quitter CVE.

Menu SetUp, qui permet de configurer le simulateur matériel comme les opérations CPU Setup.

Optimize, permet de fixer les optimisations.

View, configure les checks, et les sorties du simulateur.

Help.

Tool bar, avec des raccourcis sur les principaux setup. Il est divisé en 4 parties :

1. General : ouverture de fichier de configuration, sauve, et démarrer le simulateur matériel.

2. CPU : execution logiciel, memory access-ranges, mapping memory instances.

3. Optimization : fetch, data access, time.

4. Run :exécution d’une session de Co-Simulation.

Fenêtre avec la liste des processeurs dans le schéma.

Au début de la session de Co-Simulation, les BIM et les modèles CVE sont reconnues par le Configuration Manger quand le simulateur numérique charge le schéma.

On lance la Co-Simulation en cliquant sur RUN de la fenêtre CONFIGURATION MANAGER.

Ensuite nous avons le choix de piloter la Co-Simulation par le simulateur matériel ou logiciel. Si nous nous plaçons dans le deuxième cas, nous lançons la simulation hard pendant une durée donnée.

Celui-ci attend les directives venant de CVE qui lui-même obéit au simulateur logiciel car il synchronise les 2 simulateurs.

Nous nous plaçons ensuite dans le simulateur logiciel et pouvons exécuter dans le mode désiré la Co-Simulation (pas à pas…).

Pour visualiser les résultats sur le simulateur hard, nous devons bloquer la simulation en tapant la commande « ss cve break » dans XRAY.

VIII. Lancement de CVE.

Pour lancer une Co-Simulation à partir de CVE, nous devons respecter plusieurs étapes :

1. Mettre à jour la CONFIGURATION_MAP. En particulier le pointeur $CVE_HOME. Ce pointeur est nécessaire pour saisir un schéma appelant des modèles CVE ou pour simuler ce schéma sous QUICKSIM II ou QHPRO.

2. Se placer dans l’environnement de travail sous Unix.

3. Rapatrier les fichiers sources et exécutables de la chaîne VAX.

4. Se mettre dans un répertoire de travail. Nous devons y trouver le design (élaborer sous da_lms). Les fichiers sources (.c) et exécutable (.x)

5. Lancer CVE : cve.

Il s’agit de la configuration minimum pour lancer CVE. Nous préconisons un type d’organisation qui sera plus longuement détaillée dans le chapitre suivant.

E - DEMONSTRATEUR CO-SIMULATION

Dans ce chapitre, nous allons détailler toutes les étapes pratiques pour la réalisation du démonstrateur. Nous commencerons par la configuration de l’environnement, pour ensuite étudier les différentes modifications à apporter au schéma et au logiciel de test et pour finir les paramétrages de CVE.

Dans un deuxième temps, nous expliciterons la méthode qui nous paraît la plus intéressante pour utiliser la Co-Simulation au sein de A/SE, ainsi qu’un bilan global sur l’ensemble du projet.

I. Environnement Unix

Il faut, en premier lieu, configurer convenablement les variables pour l’environnement Unix. Celui-ci est composé de (dans l’ordre d’appel) :

1. Atelier A1.( Atelier_1.0_env). Accès à l’atelier de IAO.

2. Mentor B2.( Mentor_B2_env). Accès aux outils Mentor Graphics dont QUICKSIM II, QHPRO et Design View Point.

3. Synopsys 41.( Synopsys_41_env). Accès aux propriétés des composants Synopsys pour la simulation matérielle.

4. Seamless 23.( Seamless_2.3_env). Accès aux outils de Co-Simulation Seamless CVE, XRay, Config view point et Memmaker.

Pour éviter un mauvais positionnement des pointeurs lors de changement de répertoire, il est souhaitable de créer un alias dans le « .kshrc » (voir annexe) qui rappelle cette configuration.

Nous avons créé une arborescence qui délimite la partie matérielle de la partie logicielle.

Dans la partie matérielle hard, nous plaçons :

La schématique. Pour le démonstrateur, nous avons deux schématiques, dérivées de la CPU V1 utilisant respectivement QUICKSIM II et QHPRO :

V1.1sert pour une simulation purement matérielle afin de vérifier la carte à « l’ancienne ».

V1.2 sert pour la Co-Simulation. Certains de ces composants sont des modèles CVE (BIM, RAM, FLASH).

Un répertoire library contenant 2 bibliothèques de composants spécifiques que nous avons dû construire :

composants_cve.

composants_qhpro.

Un répertoire simulation contenant les fichiers nécessaires à la simulation.

Un répertoire source_vhdl qui nous permet de construire des modèles QHPRO.

Dans la partie logicielle soft, nous plaçons :

Dans le répertoire ims :

les fichiers sources « .c » et « .asm ». Transférés de la chaîne VAX (via un ftp en ASCII).

Les fichiers exécutables, transférés de la chaîne VAX (via ftp en binaire) issus des sources avec l’extension « .x ».

Dans le répertoire ims_verif :

Une schématique contenant le BIM 486 avec un fichier de configuration cve, mémoire en mode logiciel. Ce schéma permet d’effectuer une première vérification du code exécutable.

II. Adaptation du schéma : da_lms.

Nous avons récupéré le schéma électrique de la carte-cible CPU, élaboré sous le système Mentor V7 (Saisie de schéma : Neted, Simulation QUICKSIM). Il s’agit de l’adapter à la Co-Simulation.

II.a – Modifications dues au portage V7 -> V8

L’utilisation de Design Architect (da_lms) nous a fait constater les problèmes suivants :

Le portage a entraîné une modification du schéma après le passage à la moulinette (commande cvt sous v7). Des composants ont été déplacés ce qui a entraîné des connections erronées.

La modification en parallèle des bibliothèques de composants, qui a eu lieu dans l’atelier IAO, nous a obligés à remettre régulièrement à jour la carte et à faire modifier certains composants défectueux (Les buffers et les FPGAs).

L’utilisation de QUICKSIM II nous a fait constater le problème suivant :

Les composants FPGAs pointent sur les fichiers « .adl » qui contient l’exécutable du VHDL synthétisés par la chaîne actel. Cette synthèse est faite sous V8. Pour pouvoir simuler sous V7 les FPGAs, ces fichiers ont été simplifiés via une procédure (moulinette). Il est donc nécessaire de restaurer l’original pour la simulation sous v8.

L’utilisation de QHPRO nous a fait constater les problème suivant :

Il y a une incompatibilité dans le type des signaux (simple et std logic) au sujet des équations VHDL des 2 FPGAS qui empêchent les connexions directes entre ceux-ci. Pour résoudre ce problème :

Soit on modifie les types des signaux en supprimant la mixité de ceux-ci qui a le désavantage d’entraîner des modifications (donc des sources d’erreurs) dans le code VHDL.

soit on « coupe la connexion directe » sur la schématique, c’est à dire que l’on insère une résistance en série sur le fil. Cette insertion doit respecter la règle suivante : « le côté marqué par un « l » sur la résistance doit être placé du côté du FPGA (entrée ou sortie) ».

Une fois la carte mise aux normes V8, nous allons procéder aux modifications ci-dessous pour pouvoir lancer la phase de Co-Simulation.

II.b – Modifications particulières à la carte –cible CPU

A cette étape, nous mettons en pratique les modifications abordées lors du chapitre C, qui consiste principalement à retirer tous les composants analogiques, ainsi que de la mémoire et l’interface ECSB.

Cette simplification est nécessaire car nous nous sommes rendu compte que si nous voulions faire une simulation logique, via QUICKSIM II, de la carte entière, les stations de travail, d’une part, n’avaient pas assez de mémoire et d’autres part les « warning » générés par l’utilisation de ces composants étaient susceptibles de masquer des erreurs.

II.c – Règles générales

II.c.1 – Substitution SYNOPSYS Ö CVE.

Nous devons substituer certains modèles de composants « classiques » (par exemple SYNOPSYS) par des modèles de type CVE. Il s’agit du cœur microprocesseur et des modèles de mémoires.

Il est obligatoire de placer sur le design le Bus Interface Model (BIM) du microprocesseur désiré afin de pouvoir utiliser l’outil de Co-Simulation CVE. En effet c’est lui qui permet de faire le lien entre les 2 simulateurs. La Co-Simulation est impossible sans cet élément.

Il est conseillé de placer des modèles de mémoires (RAM, FLASH…) sur le schéma si on veut avoir accès aux fonctions d’optimisation de CVE. En cas d’absence de ces éléments, la Co-Simulation est possible :

Soit en plaçant la zone mémoire correspondante, dans le Configuration Manager, en mode logiciel. Nous avons utilisé cette technique pour vérifier la bonne conformité de l’exécutable indépendamment du matériel (sous soft/ims_verif).

Soit en réalisant une Co-Simulation non optimisée mais très longue. Cette technique nécessite de stocker le boot dans les RAMs SYNOPSYS par l’intermédiaire de leur propriété MEMFILE. Cette méthode nous semble peu intéressante dans l’optique du démonstrateur (RAMs correctement adressées donc ne nécessitant pas de vérifications).

Il est souhaitable que ces substitutions entraînent un minimum de modifications sur le schéma afin de garantir l’intérêt de l’outil. Ainsi, pour respecter la schématique, nous avons construit la géométrie du symbole CVE pour être identique à la géométrie du symbole SYNOPSYS.

Pour résumer, à partir de da_lms, nous remplaçons le bloc logique représentant le microprocesseur ou les mémoires type SYNOPSYS par les modèles correspondants CVE dont nous adapterons les E/S au schéma.

II.c.2 – Construction des modèles CVE.

Une bibliothèque de composants CVE est disponible, fournie avec le logiciel SEAMLESS. Des modèles QUICKSIM ou VHDL sont disponibles.

Si des composants non existants dans cette bibliothèque sont nécessaires, il est possible de créer des modèles CVE à partir de memmaker fourni avec SEAMLESS. Sa documentation est fourni avec le pack CVE.

Lors de l’adaptation du BIM avec le symbole SYNOPSYS 486 DX4, des broches sont restées non connectées mais cela n’entraîne pas un comportement différent.

II.c.3 – Utilisation de QHPRO.

L’intérêt de la Co-Simulation est de pouvoir débugger une carte électronique. Le fait de pouvoir débugger le VHDL contenu dans un FPGA ou un ASIC nous incite à utiliser QHPRO. Mais pour cela nous devons redéfinir les composants FPGA afin d’avoir accès au niveau RTL (les composants programmables doivent être au format QHPRO).

Ainsi nous avons créé la librairie composants_qhpro.

III. Mise en conformité du schéma

Une fois le schéma saisi et vérifié, nous le mettons aux normes de la Co-Simulation. Design View Point (DVE) indique le type de simulateur matériel visé (Quicksim II ou QHPRO) et Config View Point met à jour les informations utiles à CVE.

IV. Initialisation du CONFIGURATION MANAGER (CVE)

Après avoir lancé l’outil de Co-Simulation, la première étape consiste à appeler le simulateur matériel afin de reconnaître les composants CVE retenus sur le design.

Lors de cet appel il y est intéressant d’y inclure un fichier dofile (.dof) qui permet une configuration du simulateur lors de son appel (schéma ouvert, traces, stimuli…).

Le démonstrateur utilise comme simulateur matériel QUICKSIM II et QHPRO., car nous Co-Simulons un schéma électrique contenant des modèles VHDL (FPGAs ACTEL, ASIC BIGASIC, Mémoires CVE).

Ensuite, la reconnaissance des composants faite, nous configurons les zones mémoires comme désirées. Les composants CVE sont placés dans la zone optimisante, les composants classiques en zone matérielle, et tout ce qui est inintéressant à visualiser ou à analyser en zone logicielle.

La configuration mémoire achevée, nous pouvons appeler le simulateur logiciel XRAY (xhcx86).

V. ETAPE LOGICIELLE

Il existe deux méthodes pour simuler le logiciel sur CVE. L’ISS et le HCE. Pour des raisons de précision et de facilité de mise en œuvre (peu de modifications des IMS) nous avons retenu dans un premier temps la méthode ISS. La méthode HCE ne sera donc pas abordée lors cette étape du démonstrateur.

La chaîne de compilation, disponible sous VAX, délivre du code OMF386. Nous compilons ainsi le source pour obtenir l’exécutable. Cet exécutable est ensuite transféré vers le répertoire logiciel de la station de travail.

V.a – Chaîne de compilation

V.a.1 – Principe

Nous nous servons, pour le démonstrateur, de la chaîne de compilation dans l’environnement VAX où les modules de tests IMS ont été développés, stockés et compilés.

Par ailleurs, cela présente l’avantage d’utiliser les ressources mêmes de l’atelier. L’acquisition d’une nouvelle chaîne ne permettrait pas en effet de répondre au mieux aux besoins des services du département pour des applications futures, en particulier pour le service des IMS puisque cela supposerait une réadaptation des procédures de compilation et de testabilité.

Cependant, pour certains services, compiler sur une autre chaîne leur permettrait d’utiliser leur propre station de travail, de développer leur code C et de le compiler directement en évitant de passer par la chaîne VAX (chaîne gnu par exemple ou compilateurs gcc de la station).

Le processus de compilation de l’atelier s’effectue sous le système d’exploitation VAX. Il est composé de:

le compilateur « ic386 ».

le linker « bnd386 ».

le builder « bld386 ».

Le fichier de boot et les fichiers sources sont tout d’abord compilés un à un à l’aide de la commande « ims_compil.com », qui les transforme en fichier objet . Ensuite, la commande « ims_link.com » est lancée et permet de combiner ces fichiers objets en un seul fichier de type « .bnd ». Ce dernier fichier est alors transformé en exécutable par l’intermédiaire de la commande « obrm_build.com ».

Nous disposons finalement du fichier exécutable 2 ims.x qui pourra être utilisé par le debugger Xray.

V.a.2 – Organisation

Comme le logiciel de test IMS du calculateur ATSU a été développé sous l’environnement VAX, nous avons décidé de travailler sous le même système d’exploitation pour développer la partie logicielle de notre démonstrateur en respectant le mieux possible les méthodes de travail habituelles utilisées au sein de l’atelier. Il est donc intéressant de décrire ici en détail l’environnement que nous nous sommes créé.

Afin de ne pas perturber les fichiers d’origine, un répertoire de travail (0 cosimul) qui représente notre racine a été réalisé. On peut y accéder directement en entrant la commande « cosim » sous le prompt.

Tous les fichiers de test IMS propre à la co-simulation ont été rapatriés dans ce répertoire ce qui nous permet d’effectuer les modifications et les adaptations nécessaires.

Une librairie contenant toutes les bibliothèques utilisées ainsi que celles qui ont été créées, a été également conçue (0 library).

Les fichiers de compilation et les fichiers sources ont été regroupés en un seul et même répertoire (0 test_ims).La figure suivante représente l’arborescence sous VAX :

V.b – Elaboration du source, adaptation des IMS.

Le logiciel à simuler doit permettre de mettre en valeur le mieux possible le Démonstrateur. Il doit ainsi s’adapter à l’architecture du matériel cible.

Notre deuxième souci est d’utiliser des programmes assez simples pour faciliter le débuggage et la mise en route du démonstrateur dans un premier temps et, dans un deuxième temps permettre une utilisation facile, rapide et souple de la chaîne VAX, travail qui servira de base pour les Groupes Asics et Numérique. Ce travail a aussi pour but de recenser tous les fichiers nécessaires dans l’optique de changer la chaîne de compilation.

L’objectif est de modifier le moins possible les IMS afin de sauvegarder la compatibilité du code, ainsi vérifié, avec l’étape du prototype physique couplé avec l’émulateur (intégration).

Le logiciel est prévu pour fonctionner avec un banc manuel ou avec un banc automatique. Le choix du mode de travail dépendait de l’utilisateur et du test à effectuer. Dans notre cas, nous travaillons en mode manuel, la sélection des différents IMS dans le programme principal se fera par une lecture de la zone mémoire que nous paramètrerons suivant les modules désirés.

Notre objectif est de créer un module logiciel capable de s’exécuter sur l’interface de debbugage XRay et d’utiliser au mieux ce dernier pour le démonstrateur.

Puisque XRay permet de visualiser le code source, il semble logique d’utiliser cette caractéristique et donc de créer un programme général source en « C » qui constitue le module principal et auquel est rattaché l’ensemble des IMS de l’ATSU.

L’utilisation d’un module principal permet de simplifier les travaux, étant donné que la Co-Simulation ne nécessite plus l’utilisation de la visualisation entrainant par conséquent l’inutilité des commandes d’affichage et de lecture console.

On supprime ainsi tous les accès au moniteur par l’intermédiaire de fonctions vides (inclusion d’un fichier « 2cosim_lib.h »

La stratégie que nous avons adopté pour la création de ce logiciel s’opère en plusieurs étapes :

La première consiste à n’utiliser qu’un seul IMS afin de valider le logiciel sous l’interface XRay, pour ne pas alourdir la Co-Simulation par l’utilisation d’un code trop important. Notre choix s’est porté sur l’IMS114 de test des mémoires RAM puisqu’il consiste à lire et écrire simplement en zone mémoire.

La seconde étape a pour objectif de se rapprocher du logiciel de test d’origine en intégrant la totalité des modules IMS de l’ATSU de base.

Cette méthode de conception permettra également de vérifier chaque module séparément sans avoir à exécuter le logiciel ATSU en une seule et même étape. Nous intégrons en effet un à un chacun de ces IMS.

Nous avons décider également de rester le plus fidèle à l’architecture logicielle de base en supprimant le moins d’éléments possible. Aussi, dans cette perspective, l’architecture de notre logiciel adapté est la suivante :

Nous disposons d’un module principal, développé en C (2 main_ims.c) auquel nous ajoutons les modules IMS contenant les différents tests à effectuer (2 ims114.c, 2 ims110.c, etc.).

Les modifications apportées aux fichiers sources IMS resteront minimes. Seules quelques directives du préprocesseur comme l’inclusion de certaines librairies ou fichiers relatifs a la visualisation par exemple seront éliminées (2 noyau.h, 2 terminal.h et 2 utilitaires.h).

Nous avons de même créé une librairie (2 cosim_lib.h) qui contient toutes les fonctions d’accès au moniteur de visualisation que nous avons simplement remplacées par des fonctions vides.

Ainsi, le programme général n’est pas perturbé et les modifications à effectuer par rapport au logiciel ATSU de base sont simples et minimes. Les fichiers de base tels que les fichiers de déclaration logicielle et matérielle peuvent également être réutilisés sans aucunes modifications à apporter.

Le schéma précédent n’est pas exhaustif, aussi d’autres bibliothèques sont à ajouter en fonction des IMS utilisés (2 i86.h, 2 i386.h, 2 drivers.h...).

La suppression de la console supposera cependant la création et l’utilisation d’une zone réservée d’accès mémoire qui fera office de menu. On chargera ainsi dans la zone FLASH (propriété memfile des composants SYNOPSYS), devenue inutile car l’exécutable n’est plus chargé dans celles-ci, différentes valeurs permettront notamment à l’utilisateur de sélectionner le test ou les tests.

Ceci n’est bien entendu valable que lorsque la deuxième étape sera mise en œuvre, c’est à dire lorsque le logiciel contiendra plus d’un IMS.

VI. LANCEMENT DE LA CO-SIMULATION

Maintenant que le design et le logiciel sont prêts et que le configuration manager est correctement réalisé, on sauvegarde ce dernier et on lance la Co-Simulation en cliquant sur RUN de la fenêtre CONFIGURATION MANAGER.

Les deux interfaces sont chargées. Il faut ensuite lancer le simulateur matériel pour accéder au simulateur logiciel (RUN pour QUICKSIM II). Après avoir vérifié la connexion des deux processus, nous pouvons charger l’exécutable.

Nous nous déplaçons dans le logiciel à l’aide des commandes du debugger. Nous pouvons interrompre ce processus pour visualiser le simulateur matériel en tapant « ss cve break ».

Pour relancer la simulation on relance par un « run » le simulateur logique. Pendant la Co-Simulation il est possible de modifier les paramètres de simulation pour accélérer ou détailler celle-ci.

VIII. Méthodes.

Voici nos recommandations pour l’utilisation de SEAMLESS CVE.

VIII.a – Outils

Nous avons été confrontés à des problèmes de mémoire à partir des terminaux X, c’est pourquoi il est préférable de lancer une Co-Simulation à partir d’une station de travail.

Le fait que nous fassions des accès réseaux pour accéder à nos fichiers augmentent considérablement le temps de simulation. Deux solutions sont envisageables :

1. Celle qui a notre préférence est de dédier une station de travail , coupée du réseau, aux processus réclamants des simulations importantes comme SEAMLESS, QUICKFAULT ou SABER. Cela a l’avantage de ne pas perturber les autres utilisateurs des stations de travail mais a l’inconvénient d’être onéreuse car on monopolise une station pour finalement peu d’utilisateurs et de nécessiter un transfert de fichier (schématique) entre la saisie de schéma et la Co-Simulation.

2. La seconde solution est de rapatrier tous les fichiers nécessaires à la Co-Simulation dans un répertoire de la station de travail (par exemple le temporaire) afin de supprimer les accès réseaux:

Cela revient à utiliser la même station pour tout le processus si on ne veut pas retransférer systématiquement les fichiers (solution 1).

Le fait d’utiliser le répertoire temporaire augmente le risque de perdre les informations (lors d’un nettoyage par exemple).

On est perturbé par les autres utilisateurs de la station (et réciproquement).

Modifie la stabilité des fichiers de développement (on transfert le design vers le répertoire temporaire).

Peu onéreuse.

VIII.b – Organisation des données

Sous Design Architect, une bibliothèque spécifique pour les composants CVE (mais aussi QHPRO), nécessaire à la Co-Simulation, serait utile afin de remplacer rapidement sur le schéma les composants intéressants.

L’utilisation de SEAMLESS nous oblige à gérer de nombreux fichiers. Il nous paraît nécessaire de devoir organiser ceux-ci pour éviter des erreurs d’initialisation.

Sous le répertoire sources, nous créons 2 sous répertoires distinguant le logiciel du matériel. Ensuite, dans ce dernier, il est conseillé de tout nommer sous le même nom, l’extension faisant la différence pour éviter de mélanger un fichier ayant trait à une version de carte avec une autre.

L’appel de CVE se fait sous le répertoire matériel, avec XRAY nous irons chercher les fichiers exécutables et sources correspondants dans le répertoire logiciel.

Une organisation minimale s’orchestrerait autour de l’arborescence suivante :

		DESIGN	SIMULATION
IMS	IMS_VERIF

	Cpu1 Cpu1.attr Cpu1.dof Cpu1.cve
cpu.x Ims114.c Boot386.asm

Macros

Actel

Rams

Flashs

L’appel de CVE se fait sous le répertoire DESIGN. Avec XRAY nous irons chercher les fichiers exécutables et sources correspondants dans le répertoire logiciel.

VIII.c – Type de schéma à Co-Simuler

A priori, la Co-Simulation permet de simuler des schémas complexes associés à un logiciel complet. Mais les temps de simulation sont proportionnels à la taille des données.

Ainsi, une simulation de la carte CPU complète sous QUICKSIM II ne peut excéder actuellement 250µs alors que la version simplifiée nous permet d’aller beaucoup plus loin (1 seconde voir plus).

De plus, un circuit complexe, entraîne un nombre important de signaux à vérifier et un nombre trop important de composants entraîneraient une trop grande complexité.

C’est pourquoi, nous pensons que le logiciel est plutôt adapté à la vérification de petits circuits auxquels sont associés un ou deux IMS.

Nous le préconisons pour les petits modules tels que le dialogue :

CPU Ö FPGA.

CPU Ö ASIC.

IX. BILAN

IX.a – Mise en œuvre

Nous pouvons dresser un bilan sur les différents problèmes qui sont apparues durant la durée de ce projet.

Nous avons pu compter sur le support des différents groupes qui nous ont permis d’avoir une bonne prise en main des outils que nous ne maîtrisions pas et qui n’ont pas hésité à nous épauler quand c’était nécessaire.

La formation que nous avons reçu sur SEAMLESS CVE était utile pour la prise en main de l’outil et nous a permis d’avoir une interlocutrice pour aborder les problèmes rencontrés par la suite.

En ce qui concerne Mentor Graphics, nous avons donc pu compter sur leur soutien et leur réactivité quand on leur soumettait un problème. L’inconvénient principal a été les erreurs dans le logiciel qui nous ont beaucoup retardé.

Ces erreurs en cours de traitement chez eux concerne essentiellement le BIM 486 et son ISS. Il est à noter que nous sommes un des premiers à travailler sur ces produits et nous avons été obligés d’identifier les « bugs » du programme au fur et à mesure que nous les avons rencontrés.

Comme il est difficile de cerner le(s) problème(s) erreur(s) provenant de notre carte, de notre logiciel ou de SEAMLESS, nous avons perdu beaucoup de temps à isoler le(s) défaut(s). En particulier, nous déplorons la légèreté du manuel de décodage des erreurs, surtout pour XRay.

Nous avons généralement rencontré des problèmes dont il est difficile de déterminer le fautif. En effet, pour une Co-Simulation, nous utilisons plusieurs logiciels qui chacun individuellement sont susceptibles de créer des problèmes.

Dans cet ordre d’idée, SEAMLESS CVE génère très peu de warning ou sont mal placés. En effet, ils apparaissent une fois que nous avons interrompu une Co-Simulation. On peut ainsi lancer des processus qui sont faux mais qui nous paraissaient justes.

Nous pouvons prendre l’exemple de la vérification du code de l’exécutable. Le problème est :

« XRay n’arrive pas à lire, ou à interpréter, le code exécutable de l’ims »

Nous avons pensé que la chaîne de compilation ne délivrait pas un code conforme (OMF386) ce qui contredisait les affirmation de Microtec (voir D.I). L’inconvénient est que XRay générait différentes informations qui nous laissait penser que soit le problème était soit le design, soit le mapping mémoire, soit les modèles CVE de mémoires ou bien XRay lui-même.

En fait, le problème était que nous faisions un transfert FTP qui n’était pas en binaire.

Si XRay nous avait clairement indiqué qu’il ne reconnaissait pas le code et que le problème était seulement là, nous aurions été plus prompts à résoudre ce problème.

La coordination entre les opérateurs est bonne car les rôles ont été clairement définis. Nous avons perdu du temps car nous ne maîtrisions pas forcément tous les outils (synthèse du VHDL, utilisation QHPRO, QUICKSIM II pour générer des symboles, prise en main de VAX pour compiler l’exécutable, de l’émulateur pour vérifier celui-ci…) et le manque d’expèrience nous a bloqué sur certaines difficultés (transfert ftp…). Néanmoins, les différents groupes (mention aux Outils) nous ont bien aidé.

Notre principale erreur a été de considéré SEAMLESS CVE comme correct et de vouloir expliquer tous les problèmes rencontrés par des défauts sur nos données. Ainsi, le problème de l’instruction défaillante dans le logiciel, bien que repérée tôt, n’a été soumis en tant que tel à Mentor Graphics que tardivement.

IX.b –Co-Simulation

Seamless CVE autorise une plus grande souplesse dans la vérification de circuits électroniques :

1. Permettre de tester l’intéraction logiciel Û matériel plus tôt dans le processus, tout en offrant de meilleures possibilités de débuggage (matériel/logiciel) permettant de déceler et de résoudre rapidement d’éventuels défauts au niveau des fonctionnalités.

2. Permettre de nous affranchir dans bien des cas du prototype physique, offrant ainsi un gain de temps non négligeable pour tout ce qui concerne les attentes dues à la disponibilité du prototype (celui-ci sert à différents services et n’est pas forcément disponible immédiatement), de son environnement de test (espace réservé au laboratoire…). Seamless étant disponible immédiatement sur station de travail (suivant le nombre de licences accordés).

3. Développer à partir de Seamless un processus de simulation de fautes au niveau de la carte (logiciel QUICKFAULT).

Le fait de pouvoir travailler avec plusieurs types de simulateurs logiques nous offre en plus la possibilité de nous en servir comme outil de développement. :

Soit en logiciel (mise au point du logiciel de test).

Soit en matériel (débuggage du VHDL avec QHPRO par exemple). Cette option nous semble en particulier très intéressante pour le groupe ASIC.

Il nous permet aussi de travailler au niveau carte ou VHDL (suivant le type de simulateur matériel souhaité), contrairement à d’autres produits plutôt axé Asic qui travaille avec des simulateurs HDL, VHDL….(Cadence Eaglei association de Synopsys et ViewLogic, etc…).

Mais l’outil de Co-Simulation est un outil relativement nouveau et possède les défauts de sa jeunesse. En effet, bien que SEAMLESS CVE offre un choix important de processeurs modélisés, le peu d’intérêt qu’il offre actuellement pour les projets de l’Aérospatiale A/S reste son principal défaut (relatif car c’est un projet à long terme). Pour les groupes Asics et Numérique, c’est un réel inconvénient car :

1. Il n’existe que peu de DSP pour l’instant au catalogue Seamless et le groupe ASIC désire Co-Simuler avec ce type de composants. Mentor Graphics est conscient de cet état de fait et travail actuellement sur des modèles de DSP qui offriront les mêmes possibilités d’analyse que sur leurs modèles µP.

2. Au niveau des µP, deux sont pour l’instant intéressants pour A/S : Le 486 DX et le COLDFIRE.

3. Le comportement des BIMS reste « artificiel ». Par exemple sur le BIM 486 on ne trouve pas de mémoires caches, ce qui rend SEAMLESS inintéressant pour le groupe DIGITAL qui souhaite faire de l’évaluation de performance.

Pour cette raison, il pourrait être intéressant d’étudier d’autres outils de Co-Simulation, afin d’évaluer surtout le type de processeurs modélisés.

IX.c – Démonstrateur

L’utilisation du démonstrateur nous a montré l’intérêt évident de cet outil dans le processus de vérification logiciel/matériel :

Gain de temps pour les premières vérifications. Il permet un débuggage plus tôt dans le processus de développement.

Plus grande souplesse pour les tests. Il nous permet de changer des paramètres, des designs et de vérifier ces modifications sans avoir recours à la grosse structure du prototype physique couplé à un émulateur.

Son utilisation est assez aisée et nécessite finalement peu de modifications. La carte saisie sous IAO n’est modifiée que par la substitution des modèles type SYNOPSYS par les modèles CVE, alors que le code source des IMS reste quasiment inchangé : la suppression des fonctions spécifiques telles que la visualisation se fait par l’intermédiaire de l’inclusion d’un fichier de « define ».

La durée d’une Co-Simulation non optimisée est un inconvénient car on respecte tous les timings (par exemple 10µs pour exécuter 5 instructions assembleur « mov »), et on atteint rapidement, même avec un petit logiciel, des durées non négligeables pour le simulateur matériel. Dès lors, l’inclusion des modèles CVE sur le design permettant les optimisations, même s’ils ne sont pas obligatoires, devient pratiquement incontournable.

La taille du design devra respecter la puissance des stations de travail.

X. EVOLUTIONS FUTURES

Le sujet du stage consiste en la mise en œuvre du démonstrateur. L’objectif final du démonstrateur est de valider une carte électronique par l’utilisation de la Co-Simulation. Ceci nécessite donc une analyse détaillée de la carte.

Plusieurs solutions sont envisageables pour la suite du démonstrateur afin d’évaluer complètement l’intérêt de la Co-Simulation et du produit SEAMLESS CVE lui-même.

Au niveau matériel, on peut inclure le module SCREEN sur le design (modèle BLM fourni par Mentor Graphics). Ce module permet de visualiser immédiatement le contenu d’une adresse. Il peut être très utile en mode HCE quand nous n’avons pas de debugger disponible.

L’avantage est que nous pouvons vérifier, sans interrompre le simulateur matériel, le contenu d’une zone mémoire.

L’inconvénient et que l’on modifie :

1. Le schéma, ce qui signifie que nous aurons un design spécifique à la Co-Simulation. Cet inconvénient est limité si nous devons construire la schématique par étapes (utiliser un design hiérarchique).

2. Le mapping mémoire pour inclure ce module.

Il s’agit aussi d’inclure le module BIGASIC. Les différents problèmes que nous avons rencontré nous ont empêché de l’étudier. Il s’agira de l’adapter au bus L1 et d’édifier le mapping mémoire.

Au niveau logiciel, il s’agira bien sûr d’évaluer le code HCE, qui est pour l’instant très peu utilisé (source Mentor Graphics).

Mais aussi, de finir la simplification de la chaîne VAX afin de rendre son utilisation plus aisée (pour le Groupe ASIC et Digital par exemple)

L’intérêt d’une nouvelle chaîne de compilation (GNU…) est aussi envisageable car on pourrait par exemple générer du code x86 directement sur la station de travail (et ainsi supprimer le ftp entre vax, unix, windows…).

BIBLIOGRAPHIE

Conception des systèmes mixtes SW/HW temps-réel: le co-design INP-ENSEEIHT

François Clouté novembre 1997

Thèse Ingénierie des systèmes complexes – codesign INPG

Mohamed ROMDHANI 1996

Co-verification handles... Electronic Design

Arnold S.BERGER 9 mars 1998

HW & SW co-verification - key to co-design Electronic design

Serge LEEF 9 mars 1998

Démonstrateur Co-Simulation ENAC

Olivier JOSEPH Novembre 1998

Logiciel adapté à la Co-Simulation Maîtrise EEA, Université Toulouse III Paul Sabatier

Arnaud Teulier Septembre 1998

Seamless CVE User’s and Reference Manual Mentor Graphics

1998

Getting Started With Seamless CVE Manual Mentor Graphics

1998

CVE Training Manual, Software Version 2.0 Mentor Graphics

Février 1998

XRAY Debugger, Quick Reference Microtec

1998

XRAY Debugger, Manual Reference Microtec

1998

XRAY Debugger, Getting Started Microtec

1998

CVE Training Manual, Software Version 2.0 Mentor Graphics

Février 1998

Memmaker, Memory Modeler’s User’s Guide Denali

1997

GLOSSAIRE

ABD:

Ensemble de documents regroupant les exigences de AIRBUS Industries.

Architecture:

Configuration intégrée formée par des sous-ensembles matériels et logiciels permettant de réaliser une ou plusieurs fonctions avioniques.

ARINC (Aeronautical Radio Inc.):

Organisme international de normalisation de protocoles de communications en aéronautique.

BITE (Built In Test Equipment):

Equipement d’autotest d’un calculateur.

Co-Simulation:

Simulation conjointe du matériel et du logiciel.

ECSB :Embedded Computer System Bus.

IMS : Integrated Maintenance Software.

Panne:

Anomalie de fonctionnement d’un équipement avion.

Partitionnement:

Décision de découpage d’un ensemble de fonctions en deux sous-ensembles: fonctions à réaliser en matériel et fonctions à réaliser en logiciel.

RTL (Register Transfert Level):

Représentation d’une fonctionnalité au niveau transfert de registres (Architecture fonctionnelle)

RC / NRC:

Coût de développement, coût de production.

Système (Avionique):

Ensemble de constituants (matériel, logiciel, communication) permettant de réaliser un ensemble de fonctions avioniques.

MDM:

Méthodes de développement matériel.

XAO:

Composé de IAO (Ingénierie Assistée par Ordinateur) et CAO (Conception Assistée par Ordinateur)

Annexes

Processeurs supportés par SEAMLESS CVE (au 31/09/98)

Analog Devices ad21020

AVR CORE

Intel i386EX

Intel i386SX

Intel i486DX

Intel i960HX

Intel i960JX

Intel i960KX

Intel i960RP

Intel i960SA

Intel i960CX

Intel i960SX

Motorola 68000

Motorola 68020

Motorola 68030

Motorola 68040

Motorola 68302

Motorola 68340

Motorola 68360

Motorola Coldfire5200M

Motorola Coldfire2

Motorola mpc740

Motorola mpc750

Motorola mpc860

Power PC 603 E

Power PC 604 E

Hitachi 7034

Hitachi 7050

Hitachi 7604

Hitachi 7708

Hitachi SH1

Hitachi SH2

Hitachi SH3

ST 20

Nec VR 4300

Nec V851

LSI LOGIC TinyRISC

LSI LOGIC TR4101

TMS 320C58

ARM 7 tdmi

VLSI Z80

COMMANDES POUR UNE CO-SIMULATION

Ce chapitre recense toutes les commandes à taper pour réaliser la Co-Simulation d’une carte.

· A partir d’une nouvelle schématique appelé nouveau_circuit :

Cd hard/repertoire_nouveau_circuit	On se place dans le répertoire de travail
Deb23	Rappel de l’environnement, alias dans le .kshrc
Ø Da_lms	Saisie du schéma nouveau_circuit
Ø Dve nouveau_circuit	Design view point du schéma (on fixe le type de simulateur matériel (QUICKSIM II, QHPRO)
Config_view_point nouveau_circuit/default	Mise à jour attribut du schéma pour CVE
Ø Cve	Appel et lancement de cve

· A partir du démonstrateur utilisant le simulateur matériel Quicksim II.

Cd hard/v6.42_cve/v6.42_qsim	On se place dans le répertoire de travail
Deb23	Rappel de l’environnement, alias dans le .kshrc
Ø Cve config.cve	Appel et lancement de cve

UTILISATION DE DESIGN ARCHITECT (da_lms)

Sous le XTERM, nous désirons saisir un nouveau schéma ou le modifier :

Da_lms	Appel de l’outil
Open sheet	Ouverture de la schématique
Choose symbol	On insère dans le schéma les composants cve (QHPRO). Vous avez le choix entre :
$TMP_MNT/home/BigRem/hard/library/library_cve $TMP_MNT/home/BigRem/hard/library/library_qhpro	Bibliothèque que nous avons créé à partir des modèles qsim fourni par SEAMLESS ou des sources VHDL des FPGAs et qui reprend le masque des composants SYNOPSYS (BIM 486, SRAM)
$CVE_HOME/qsim	Bibliothèque fourni par Mentor pour le simulateur QUICKSIM II (attention peuvent être faux voir le report d’erreur)
Check sheet	Vérification de la schématique.

Des composants QUICKSIM II peuvent être créés à partir de la bibliothèque $CVE_HOME/qhdl_vhdl et insérés ensuite sur la schématique.

Vous pouvez créer vos propres mod èles CVE à l’aide de Memmaker (voir la bibliographie).

UTILISATION DE DESIGN VIEW POINT (dve)

Sous XTERM, une fois placé sous le bon répertoire de travail et après avoir réinitialisées les variables d’environnement, vous lancez dve.

N Dve

N Set view point

Vous choisissez alors le type de simulateur matériel désiré.

UTILISATION DE SEAMLESS CVE (cve)

Vous lancez le configuration manager en tapant « cve » sous le XTERM. Vous constatez que la fenêtre ci-dessous apparaît et que sous le XTERM un prompt « > » se met en place.

En effet toutes les commandes que nous allons passer en revue peuvent être éditées sous ce prompt. Nous ne détaillerons pas ces commandes que vous pouvez retrouver dans la documentation SEAMLESS (voir la bibliographie).

A partir d’une nouvelle schématique, vous devez faire le lien entre :

le simulateur matériel.

Le simulateur logiciel.

Le mapping mémoire.

Les optimisations.

> Le configuration manager se présente ainsi :

> Appel du simulateur matériel :

Vous tapez la séquence suivante :

quicksim cve_func_block –tim typ < V1.2_qsim.dof

Vous trouverez dans ces annexes un exemple de « .dof » qui reprend tous les stimuli de test lors de l’initialisation.

Lors d’un nouveau design, vous lancez un RUN a cette étape afin que les composants CVE soient reconnues qui permet ensuite de faire appel au simulateur logiciel et pouvoir accéder à la configuration mémoire.

> Appel du simulateur logiciel XRAY :

Vous tapez la séquence suivante :

xhcx86

> Configuration des zones mémoire :

Vous définissez la zone mémoire et son type :

Nous vous conseillons de placer un label sur vos zones afin de les repérer plus facilement.

Seul des composants CVE peuvent être placés dans la zone optimisante.

Dans la zone hardware, vous placerez des composants dont vous désirez avoir des informations via le simulateur matériel.

Dans la zone software, on ne fait pas appel au simulateur matériel.

> Mapping des composants CVE :

Vous sélectionnez le composant, indiquez sa position sur le bus ainsi que son adresse. Ensuite vous cliquez sur « map » et il est enregistré. Cette option ne concerne que les composants CVE de mémoire.

> Réglage des optimisations :

Ensuite vous pouvez régler les optimisations que vous souhaitez :

Fetch :

Data :

Une fenêtre s’ouvre qui vous demande de sélectionner la zone mémoire optimisante que vous désirez optimisé. Ici non optimisée.

ici optimisée :

Temps :

Pour faire appel aux optimisations de temps, vous cliquez sur :

> Sauvegarde :

Pour éviter refaire cette partie assez fastidieuse à chaque appel de cve, nous vous conseillons de sauvegarder votre configuration (n’oubliez l’extension « .cve »).

> Exécution :

Vous pouvez maintenant lancer la co-simulation en cliquant sur RUN.

Si vous avez déjà un « .cve », vous pouvez lancer directement la co-simulation en tapant la commande sous XTERM:

Ex : « cve cpu486.cve »

> Gestion de la Co-Simulation:

Si QUICKSIM II n’a pas encore été lancé, il sera le premier simulateur à s’ouvrir et respectera les instructions contenues dans le « .dof ».

Parallèlement le simulateur logiciel XRAY s’ouvre. Pour pouvoir charger le code exécutable (que vous avez préalablement rapatrié), il faut lancer QUICKSIM II par un RUN.

XRAY récupère la main, vous chargez le « .x » et pouvez faire toutes les instructions du debugger, visualiser les registres, etc….

Si vous désirez interrompre le simulateur matériel pour visualiser l’état des signaux, vous tapez la commande « ss cve break » sous XRAY et le simulateur matériel récupère la main.

Vous relancez le processus par un autre run de Quicksim II.

BigRem, Olivier J et Arnaud T., Toulouse - Septembre 1998.