WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Mise en oeuvre de l'auto-reconfiguration partielle et dynamique sur FPGA Xilinx Virtex-II pro

( Télécharger le fichier original )
par Guy WASSI
Université Pierre et Marie Curie (Paris VI Jussieu) - Master informatique industrielle et systèmes automatisés 2005
  

précédent sommaire suivant

3.3.3 Conception sous ISE du design global «Top » suivant le Modular Design Flow

A ce stade nous supposons que le module système à processeur a été testé et validé sous EDK. Nous rappelons que l'environnement intégré ISE ne permet que la synthèse des designs dans tout le Modular Design Flow. Après la création des fichiers sources vhdl et la synthèse avec XST sous ISE, nous déroulerons les étapes suivantes du Modular Design Flow par des scripts.

a) Création des codes sources

Les designs (compteurs et clignotants) destinés au module reconfigurable de gauche peuvent être écrits, synthétises, placés, routés, testés et validés individuellement sur le FPGA dans un flot intégré sous ISE suivant le flow standard Figure, et ce dans des projets séparés. Ensuite leurs codes sources vhdl (compteur_lent.vhd, compteur_rap.vhd, clignotant_lent.vhd,

cignotant_rap.vhd, voir annexe 4) sont rajoutés, chacun a un projet de niveau Top. Chaque projet Top contient donc le même module fixe (system) et un des designs du module reconfigurable. Dans ces fichiers sources du module reconfigurable, les entités doivent porter un nom unique (compteur) et les mêmes interfaces (entrées/sorties).

Pour les codes vhdl du module fixe (system) et de ses composantes (IPs), ils ont été générés par EDK et se trouvent dans le répertoire hdl du projet EDK. En outre, les fichiers netlists des sous-modules se trouvent dans le répertoire Implementation du projet EDK et sont automatiquement ajoutés au projet ISE vers lequel le module fixe est exporté (sous ISE 6.1.i il faut les ajouter manuellement au projet ISE).

Pour la création du code source top.vhd, les étapes préliminaires sont :

- Créer un projet avec Project Navigator [27] de ISE (ou ouvrir le projet exporté).

- Choisir comme répertoire de travail le même où le module systeme à processeur (system) validé a été exporté (répertoire ISE de la Figure 27(a) par exemple).

- Copier le fichier hdl/system_sub.vhd vers le répertoire ISE de travail, le renommer top.vhd et y changer le nom de l'entite system_stub en top. En effet lors de l'exportation du module system de EDK vers ISE, un fichier system_stub.vhd est automatiquement généré dans le répertoire hdl. Ce fichier est un modèle d'instantiation du module system comme composant d'une entité nommée system_stub.

- Ajouter au projet le fichier top.vhd.

- A ce niveau, il faut compléter le fichier top.vhd en y ajoutant le module reconfigurable

(composant compteur) ainsi que ses interfaces (Buffers I/Os, clk et signaux) de connexion en s'inspirant de l'insertion du module system.

NB. Les buffers d'entrées/sorties doivent être ajoutés manuellement dans le fichier top.vhd (voir Etapes de synthèse ci-dessous).

Dans cette application, les deux modules sont synchrones et fonctionnent à la même fréquence (voir la distribution d'horloge aux modules dans le fichier top.vhd, annexe 4. 1).

b) Etape de synthèse des fichiers sources

Nous avons réalisé la synthèse incrémentale (voir modular design flow plus haut) des modules et du Top sous ISE 7.2.i avec l'outil de synthèse XST. Cette synthèse génère des fichiers de netlist du type nom_entite.ngc, un pour chaque design du module reconfigurable et un pour le top (les netlists du module system ayant été déjà générés sous EDK et ajoutés au projet ISE). Elle se déroule dans cet ordre :

(i) Synthèse de chaque module ; pour éviter que XST les instancie dans les modules lors de la synthèse, les buffers I/O sont désactivés (Synthesize - Properties - I/O Disabled). En

effet, lors de l'ajout du module reconfigurable dans le fichier top.vhd, les buffers d'Entrées/Sorties et de clock doivent être inserrés manuellement comme des composants (component IBUF/OBUF/IOBUF/BUFGP is...) au niveau top du design, sur le modèle du fichier system_stub.vhd. La synthèse génère dans chacun des répertoires les fichiers de netlist system.ngc et compteur.ngc.

(ii) Synthèse du Top ; l'outil XST fait la synthèse de la logique globale (connexions inter-modules par bus macros, connexions entre les modules et les pins externes, etc...), charge automatiquement les fichiers de netlist (.ngc) de tous les composants déclarés et instanciés dans le top (modules et Buffers I/Os et de clock), puis génère le fichier de synthèse du design complet (top.ngc). Tous les composants déclarés au niveau Top ont l'attribut « Black_Box » (voir top.vhd annexe 4.1). Cet attribut indique à XST de ne pas refaire la synthèse des modules concernés lors de la synthèse du Top, et de charger directement leur netlist (.ngc).

Pour le Modular Design Flow, Xilinx suggère une arborescence de répertoires facilitant la lisibilité du projet [22], les fichiers générés étant très nombreux et variés. Nous nous en sommes inspirés pour adopter celle de la Figure 27. Ainsi on a les répertoires et les projets suivants:

- Le répertoire « ISE » est le principal répertoire contenant le projet ISE (top.ise) vers lequel

le module system a été exporté depuis EDK. Il implémente le design Top constitué des modules system (fixe) et compteur_lent (reconfigurable, avec pour nom d'entité compteur) et contient les fichiers générés à la synthèse sous ISE.

- Les répertoires ISE2, ISE3 et ISE4 qui contiennent chacun une réplique du projet ISE

précédent (top.ise), mais plutôt avec comme module reconfigurable un design différent (compteur_rap, cignotant_lent, cignotant_rap) mais de noms d'entité (compteur) et d'entrées/sorties identiques.

- Le répertoire « HDL_ISE » qui contient tous les fichiers sources vhdl du top et des designs

(compteur_lent, compteur_rap, cignotant_lent, cignotant_rap) du module reconfigurable.

- Le répertoire « Modular » dont chaque sous-répertoire Figure 27.b renvoie à une étape du

Modular Design Flow et permet de mieux comprendre les phases d'implémentation des modules et de génération des bitstreams partiels et total.

Remarque : On peut aussi procéder autrement en créant un projet ISE unique, en y synthétisant tour à tour le module fixe et chacun des designs du module reconfigurable, et en sauvegardant chaque netlist compteur.ngc dans des répertoires différents en vue d'une utilisation lors de la phase active d'implémentation. En effet, le modular design suggère la création de plusieurs projets pour permettre simplement de générer séparément la netlist de chaque design (sans Buffer I/Os) en vue de leur implémentation individuelle, ce que le flot standard ne permet pas.

c) Etape d'Initial budgetting

Apres l'étape de synthèse, l'Initial budgetting se réalise dans le répertoire Top/Initial (Figure 27.b) et a pour but de :

- Déterminer approximativement la taille de chaque module.

- Attribuer une zone sur la cible pour chaque module à implémenter.

- Contraindre les I/O du Top communicant avec l'extérieur, et positionner les BUFG et

BUFGP.

- Positionner toute la logique du niveau Top, spécialement les Bus macros (bus

d'interconnexion entre modules) qui sont positionnés sur des TBUFs du FPGA.

En premier on exécute la commande «ngdbuild -modular initial top.ngc » (voir initial.batch en annexe 4.5) qui prend en entrée la netlist du Top (top.ngc) et la convertit en un format Xilinx top.ngd.

Ensuite on édite le fichier de contrainte (.ucf) du projet (voir top.ucf annexe 4.3) . Les outils Constraints Editor (pour les contraintes de temps) et Floorplanner (pour les contraintes de placement et de dimensionnement des modules et composants) permettent d'éditer automatiquement ce fichier. Mais pour la reconfiguration partielle quelques contraintes spécifiques dont celles ci-dessous doivent être insérrées manuellement dans le fichier ucf :

(i) Déclaration du caractère reconfigurable d'un module

AREA_GROUP "AG_nom_instance_module" MODE = RECONFIG;

Tous les modules sont en mode RECONFIG qu'ils soient reconfigurables ou fixes.

(ii) Contrainte de placement des bus macros

INST "nom_instance_bus_macro" LOC = "TBUF_X56Y24" ;

[28] est le document de référence pour l'édition des fichiers de contrainte.

Il est à noter que des broches du FPGA sont physiquement connectés à des périphériques (SRAM, LEDs, SDRAM 32Mo, Ethernet, RS-232, etc...Figure 25) présents sur la carte de développement. La position et la dimension d'un module sur le FPGA sont donc fortement dépendant du périphérique auquel on souhaite le connecter. C'est ainsi que nous n'avons pas pu utiliser la SDRAM 32 Mo présente sur la carte comme mémoire de stockage des bitsreams, car elle est connectée au FPGA par les broches du côté gauche, opposé au côté du système à processeur. Dans tous les cas, éditer un fichier de contrainte dans une application comme celle-ci se fait en grande partie manuellement, et demande une bonne connaissance de la carte de développement utilisée. Pour la carte Memec Design Virtex-II ProTM, nous avons conjointement utilisé [24] et [29]. Il en a resulté le fichier top.ucf en annexe 4.3.

d) Etape d'Active Module Implémentation

Chaque design est implémenté séparément dans un sous-répertoire d'implémentation se trouvant chacun dans le répertoire Modules (par exemple Modules/compteur_rap, Figure 27.b). Pour implémenter chaque design, on utilise en entrée son fichier <nom_entité_module.ngc> généré lors de la synthèse ainsi que les fichiers .ucf et .ngc du Top. Ces fichiers doivent donc être dans le sous-répertoire d'implémentation courant du design. Pour le module system, tous les fichiers .ngc de ses composantes (fichiers xxx_wrapper.ngc, etc) doivent également être recopiés dans son répertoire d'implémentation.

La phase active nécessite plusieurs commandes (voir fichiers active.batch annexe 4.5):

- NGDBUILD lancée en mode actif pour chaque design dans son sous-répertoire

d'implémentation et qui génère le fichier .ngd du module.

ngdbuild -modular module -active <nom_entite_module> -uc top.ucf top.ngc

- MAP et PAR qui font le Placement et Routage du module à partir du fichier .ngd généré

plus haut.

map < nom_entite_module.ngd> par -w < nom_entite_module.ncd>

- PIMCREATE qui crée un sous-répertoire par module dans le répertoire PIMS

(Physically Implemented Modules, Figure 27.b) et y publie tous les fichiers décrivant l'implémentation physique du module ;

pimcreate -ncd « nom_entite_module.ncd » ..\..\Pims

Ces informations servent lors de l'assemblage final du Top (Final Assembly). Tous les designs du module reconfigurable ayant des I/Os identiques, il n'est pas nécessaire de lancer cette commande pour chacun de ces designs, car elle publierait les mêmes informations.

- BITGEN permet de générer le bitstream partiel (fichier .bit). L'option -g ActiveReconfig

permet la reconfiuration dynamique. L'option -d est utilisée pour ne pas lancer DRC (Design Rule Check) lors du bitgen, et l'option -b permet de générer la version ASCII du fichier bitstream. Cette version est plus facile à manipuler et à stocker dans la mémoire SRAM de la carte en vue de la reconfiguration dynamique.

Remarque : Avant la phase active d'un module, son fichier .ngc et celui de ses composantes (cas du module system avec ses composantes xxx_wrapper.ngc, etc..) doivent être recopié dans son sous-répertoire d'implémentation, ainsi que les fichiers .ucf et . ngc du top.

e) Etape de Final Assembly (annexe 4.5)

Cette phase finale sert à assembler tous les modules indépendamment implémentés dans un design Top unique (voir fichiers assemble.batch annexe 4.5). Tous les modules sont ainsi placés et routés dans un design Top unique, puis le bitstream complet est généré. Les commandes d'assemblage sont exécutées dans le répertoire Top/Assemble (figure 27b) et utilisent les fichiers publiés en phase précédente dans les sous-répertoires du répertoire PIMS. Les commandes sont identiques à celles utilisées en phase active pour implémenter les modules (voir fichier assemble.batch en annexe 4.5), la commande Pimcreate en moins. La difference majeure vient des options utilisées.

Lors du BITGEN on doit avoir l'option -g startupclk:jtagclk pour s'assurer que le FPGA démarrera sur le clock du Jtag après configuration. L'option -d n'est pas utilisée en phase d'assemblage. L'option -b également (on n'a pas besoin de la version ASCII du fichier bitstream). Le fichier bistream généré permet de configurer le FPGA.

On peut souhaiter faire plusieurs assemblages afin de générer plusieurs bitstreams complets (par exemple on peut associer compteur_lent et system dans Assemble/Top, et associer cignotant_lent et system dans Assemble/Top1).

Remarque :Pour reconfigurer partiellement le FPGA, il faut au préalable l'avoir programmé avec un bitstream total.

f) Etape de génération du bitstream final

Apres la phase d'assemblage (voir repertoire Top/Assemble), le fichier bitstream (assemble.bit et/ou assemble.rbt) permettant de reconfigurer les ressources logiques (CLBs, BRAMs, etc...) du FPGA est généré. Mais pour notre application qui comporte en outre une partie logicielle a exécuter sur le processeur embarqué, il convient:

- de configurer les ressources logiques du FPGA (avec le fichier bitstream de la phase

d'assemblage).

- de charger l'exécutable destiné au processeur PPC405 en mémoire de programme

du processeur et d'initialiser ce dernier.

Ce dernier point nécessite :

- le fichier executable.elf produit suivant les phases de développement décrites plus

haut (création de la plate-forme logicielle), et

- un fichier.bmm (system.bmm pour l'entité system) indiquant les coordonnées

exactes des BRAMs (ressources FPGA) qui ont été associées au processeur via le
bus PLB lors de la phase d'implémentation active du module fixe (système à

processeur) ; en effet c'est dans cette mémoire que seront chargés le code de démarrage du processeur ainsi que l'exécutable de notre application.

Le fichier .bmm est édité manuellement, les outils ne permettant pas encore sa génération automatique. Les coordonnées des BRAMs associés au processeur sont obtenus en éditant avec l'outil FPGA Editor le design placé et routé (phase d'implémentation active) du module « système à processeur » et en répérant lesdites coordonnées dans une des fenêtres indiquant le placement des composants instanciés dans le FPGA. On peut aller plus vite en complétant simplement le fichier system_stub.bmm se trouvant dans le répertoire Implementation. L'annexe 2 détaille avec un exemple visuel les étapes de création du fichier .bmm.

En annexe 4.5 se trouve la ligne de commande permettant d'associer un fichier .bmm nomme system, un fichier bitsream_complet.bit et un fichier executable.elf pour générer un fichier unique (chargement.bit) permettant de configurer totalement le FPGA et démarrer le processeur.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy