Synthèse logique et vérification avec Design - Enseirb
Transcription
Synthèse logique et vérification avec Design - Enseirb
Tutorial: Synthèse logique et vérification avec Design Compiler et ModelSim Camille Leroux 1 Introduction Ce tutorial a pour objectif l’apprentissage des outils de conception Design Compiler (Synopsys) et ModelSim SE (Mentor Graphics) dédiés à la conception et à la simulation d’ASICs numériques. Le logiciel Design Compiler permet la synthèse logique grâce aux outils design_vision (en mode graphique) et dc_shell (en mode ligne de commande). Le logiciel ModelSim SE permet la simulation temporelle d’un circuit au niveau comportemental ou au niveau porte, à partir des langages VHDL ou Verilog. D’autres outils équivalents existent mais ces deux outils font références dans l’industrie des circuits integrés numériques. Le tutorial va vous permettre, dans un premier temps, d’appréhender ces outils en présentant leurs principales composantes. Ensuite, nous nous appuierons sur un exemple concret : la synthèse logique et la vérification d’un compteur 6 bits. 2 Flot de conception/vérification Design Compiler + Modesim L’outil Design Compiler (DC) fait la traduction d’une description VHDL en un réseau de portes logiques (netlist) : c’est ce que l’on appelle la synthèse logique. Les portes logiques utilisées dans la netlist sont habituellement fournies par un fondeur de circuit (AMS, ST Microelectronics, Intel, Samsung, etc...) sous forme de librairie : c’est ce que l’on appelle la Librairie de Cellules Standards ou bien le Design Kit. La Figure 1 représente les principales étapes du flot de conception ASIC avec l’outil Design Compiler (pour la synthèse logique) et Modelsim (pour la vérification). La librairie de cellules standards que nous allons utiliser est une librairie AMS 0.35µm. analyze : Cette première étape charge le ou les fichier(s) vhdl à lire et effectue une vérification synthaxique du fichier d’entrée (counter.vhdl). L’outil vérifie non1 Figure 1 – Flot de conception seulement les erreurs de synthaxes mais il s’assure également que le VHDL est synthetisable. elaborate : Cette phase correspond à une traduction du VHDL comportemental en une version structurelle du design. Les portes logiques constituants la netlist générée sont génériques (GTECH) indépendantes de la technologie. Durant cette étape l’outil réalise déjà un certain nombre d’optimisations. compile : Il s’agit de l’étape de synthèse logique à proprement parlé. L’outil traduit la netlist générique en une netlist constituée des cellules de la librairie standard. L’outil effectue un grand nombre d’optimisations combinatoires pour pouvoir respecter les contraintes imposées par l’utilisateur dans le fichier de contraintes (contrainte.tcl). write : A l’issue de cette étape de synthèse technologique, il est possible de sauvegarder le design au format vhdl et de générer un fichier d’annotations temporelles (*.sdf). Ces deux fichiers seront utilisés pour l’étape de vérification post-synthèse dans l’outil ModelSim. report : A l’issue de la synthèse logique, il est possible de générer tout un tas de rapports de synthèses qui permettent de quantifier les performances du circuit généré (fréquence max, analyse du chemin critique, consommation de puissance, surface,...). vsim : C’est le processus de vérification post-synthèse dans lequel le concep2 teur vérifie que la netlist générée par l’outil a bien un comportement strictement équivalent à la description VHDL comportementale d’entrée. Les simulations sont faites avec l’outil ModelSim Dans ce TP nous allons appliquer ce flot de conception à un compteur binaire 6 bits. 3 3.1 Préparation de l’espace de travail Mise en place de l’environnement Récupérez le fichier tuto_synopsys.tar.gz se trouvant sur la page web de votre enseignant : cleroux.vvv.enseirb-matmeca.fr/. — Créez un répertoire tuto_synopsys/, — Copiez y le fichier tuto_synopsys.tar.gz et décompressez le avec la commande tar -zxvf tuto_synopsys.tar.gz. 3.2 Paramétrage des fichiers de configuration de Design Compiler Avant de faire des synthèses logiques il est nécessaire de dire à l’outil où se trouve la librairie standard. Les chemins des librairies standards sont spécifiés dans un script ./scripts/synopsys_dc.setup. Le design kit que nous utilisons est fourni par la société AMS. Il s’agit d’une technologie CMOS avec une caractéristique de 0.35µm. Ouvrez et examinez le fichier de configuration synopsys_dc.setup. Déduisez-en les caractéristiques de la librairie standard utilisée. Quelles autres librairies avons-nous à disposition ? Pourquoi avoir plusieurs librairies ? 4 Structuration du répertoire de travail De manière générale l’utilisation d’outils de conception implique la manipulation d’un grand nombre de fichiers (crées par l’utilisateur ou bien générés par l’outil). Pour s’y retrouver, il est donc primordial de définir une structure de répertoire de travail qui permette de s’y retrouver facilement. Voici la structure de répertoire que vous devrez utiliser : — ./scripts : pour mettre vos scripts de synthèse 3 — ./sim : pour mettre tous les fichiers liés à la simulation dans modelsim (avant et après synthèse) : test benches vhdl, netlist, fichiers .sdf, ... — ./source : pour mettre vos fichiers source à synthétiser (.vhdl) — ./work : contient les fichiers générés par DC. Ce repertoire est crée par l’outil, nul besoin de le créer vous-même. — ./report : pour mettre les rapports de synthèse contenant les informations de timing, surface, conso de puissance, etc... Remarque : DC n’utilise comme point d’entrée que des fichiers de type VHDL (ou Verilog). Il n’existe pas de méthode de saisie graphique pour décrire un système numérique. Les netlists issues de la synthèse logique peuvent etre exportées sous différents formats : VHDL, Verilog, edif, ddc, ... 5 Synthèse logique Ce tutorial s’appuie sur l’exemple d’un compteur 6 bits dont nous allons réaliser l’analyse complète en détaillant toutes les étapes de la synthèse logique et de la vérification post-synthèse. 5.1 Lancement et fermeture de l’outil IMPORTANT : Placez vous toujours dans votre répertoire de travail ($HOME/tuto_synopsys/counter) AVANT de lancer Design Compiler. Pour lancer l’outil : 1. ouvrez un terminal 2. placez vous dans votre répertoire de travail : ($HOME/tuto_synopsys/counter) 3. tapez : launch_design_vision L’outil doit se lancer. A partir de là, vous pouvez taper les commandes de design compiler : 1. dans l’invite de commande de l’interface graphique 2. ou bien directement dans le terminal à partir duquel vous avez lancé l’outil Dans le 2ème cas, vous devez voir le préfixe suivant dans le terminal : design_vision> Pour fermer l’outil : IMPORTANT : Une fermeture mal faite peut générer des problèmes (lancement multiple de l’outil). Si vous vous contentez de cliquer sur la 4 croix, ce n’est pas suffisant pour fermer correctement DC.. Deux solutions pour fermer DC : 1. Dans l’interface graphique : File > Exit 2. Dans le terminal à partir duquel vous avez lancé l’outil : tapez exit 5.2 Chargement et analyse d’un fichier VHDL à synthétiser dans Design Vision Après avoir lancé l’outil, la première chose à faire est de spécifier à l’outil ou se trouve la librairie standard que l’on souhaite utiliser pour la synthèse. Les chemins vers la librairie standard et différentes options sont spécifiées dans le script synopsys_dc.setup. Pour exécuter ce script, tapez la commande : source ./scripts/synopsys_dc.setup . On peut alors lancer la phase d’analyse du fichier .vhd : Dans l’interface graphique faire File > Analyze > Add, puis sélectionnez le fichier ./source/counter.vhdl, spécifier le format VHDL, la librairie WORK et cliquez sur OK. L’outil vérifie la synthaxe du ou des fichiers VHDL et crée un certain nombre de fichiers intermédiaires dans le répertoire ./work. La commande dc_shell équivalente est : analyze -f vhdl counter.vhdl IMPORTANT : Après chaque commande il est primordial de vérifier qu’aucune erreur n’a été détectée dans l’onglet de Log. Vous pouvez retrouver l’historique des commandes dans l’onglet history. 5.3 Phase d’élaboration du modèle VHDL (synthèse logique technoindépendante) La phase d’élaboration correspond à une synthèse logique indépendante de la technologie utilisée, il s’agit de générer une vue RTL du design à partir de sa description VHDL. Pour lancer la phase d’élaboration : File > Elaborate. Choisissez le circuit à synthétiser dans la bibliothèque de travail WORK, si vous utilisez une entité generic, précisez la valeur des variables générique, puis lancez l’élaboration (OK). Vérifiez qu’aucune erreur n’est détectée pendant cette phase. Le schéma correspondant peut être alors visualisé : Schematic > New Schematic view La commande dc_shell équivalente est : elaborate counter -arch "RTL" -lib WORK -update 5 Ouvrez une vue schématique du circuit après cette première étape de synthèse. Identifiez chaque ressource générée par l’outil (bascules, logique combinatoire, arithmétique, port d’entrée sortie, ...) et faites le lien avec la description VHDL du compteur. 5.4 Mise en oeuvre des contraintes Les contraintes sont des déclarations explicites qui définissent les objectifs à atteindre pour le circuit considéré. L’outil propose de jouer sur les contraintes de temps, de surface et de consommation de puissance. Par défaut, l’outil tente de minimiser la surface en respectant la contrainte de temps imposée. Lors de la phase d’optimisation, DC utilise deux modèles de contraintes : — les contraintes implicites, qui sont imposées par la bibliothèque technologique ; — les contraintes d’optimisation (ou contraintes explicites) imposées par l’utilisateur. Il existe trois manières de spécifier les contraintes : par ligne de commande, par l’interface graphique ou bien directement dans le fichier VHDL. Nous utiliserons la première méthode. Les contraintes sont réunies dans le fichier ./scripts/contrainte.tcl : # Create user defined variables set CLK_PORT [get_ports clk] set CLK_PERIOD 40.00 set CLK_SKEW 0.0 set MAX_AREA 380000 # Time Budget create_clock -period $CLK_PERIOD -name my_clock $CLK_PORT set_dont_touch_network my_clock set_clock_uncertainty $CLK_SKEW [get_clocks my_clock] # Area Constraint set_max_area $MAX_AREA Pour exécuter toutes les commandes contenues dans ce fichier, tapez : source ./scripts/contrainte_counter.tcl 6 5.5 Compilation et optimisation du design (synthèse logique technodépendante) Pour se rendre compte de l’importance de l’étape de synthèse il est nécessaire d’observer les résultats de compilation avant optimisation (cf section sur l’élaboration). On applique maintenant l’étape d’optimisation pour la technologie ciblée : Design > Compile Design. Ouvrez ensuite le nouveau schéma. On observe que le design est maintenant un réseau de portes logiques de la bibliothèque AMS. La commande dc_shell équivalente est : compile Après avoir vérifier qu’aucune erreur n’est détectée par l’outil, nous allons sauvegarder le résultat de synthèse en vue d’une simulation du design synthétisé au niveau porte. Exécuter les commandes suivantes dans la ligne de commande design_vision : — write_sdf ./sim/source/counter_syn.sdf permet d’écrire dans un fichier les temps de propagations à travers chaque porte logique du design synthétisé. — write -hierarchy -format vhdl -output ./sim/source/counter_syn.vhdl permet de sauvegarder la netlist générée au format .vhdl. Nous utiliserons cette netlist ainsi que le fichier .sdf pour la simulation post-synthèse dans Modelsim. Ouvrez le fichier VHDL généré et comparez le à la vue schématique. Ouvrez le fichier .sdf. Quelles informations retrouve t-on dans ce fichier ? 5.6 Caractéristiques du circuit obtenu Pour obtenir les caractéristiques temporelles du circuit, tapez : report_timing . Les informations sur le chemin critique s’affiche dans l’invite de commande de l’outil. Il est possible de rediriger ces résultats dans un fichier texte : report_timing > ./report/counter.timing . Il est également possible de voir le chemin critique dans l’interface graphique : Timing > Path Slack > Ok. Un histogramme des chemins critiques apparait, sélectionnez la barre la plus à gauche. Une liste de chemins apparait. Clique droit sur le premier chemin, puis Path Schematic. Comparer le chemin graphique avec le chemin décrit dans le rapport 7 de timing. Ou se trouve le chemin critique ? Quelle est la fréquence cible ? Quelle est la fréquence maximale de fonctionnement de ce circuit ? Est-il possible que cette fréquence soit effectivement atteinte une fois le circuit fabriqué ? Pourquoi ? Pour obtenir les caractéristiques de surface du circuit, tapez : report_area > ./report/counter.area . A quoi correspondent les différentes composantes de la surface (combinationnal logic, non-combinationnal logic, etc...) ? Pour obtenir les caractéristiques de conso. de puissance du circuit, taper : report_power > ./report/counter.power . Identifiez les différentes composantes de la consommation de puissance ? Quelle est le rapport entre consommation statique et dynamique ? Comment évoluerait ce rapport pour une technologie plus fine (45nm par exemple) Pour obtenir des infos sur les cellules standards instanciées dans le design, taper : report_cell > ./report/counter.cell Quelle est la surface d’une porte NAND à 2 entrées dans cette technologie ? Pour obtenir des infos sur le fanout de l’arbre d’horloge : report_clock_fanout > ./report/counter.clock Quel type de cellule est concernée par ce rapport ? Pour obtenir un résumé des caractéristiques du circuit généré : report_qor > ./report/counter.qor Quel est le nombre max de cellules traversées sur le chemin critique ? 5.7 Script dc_shell Les étapes décrites jusqu’ici sont très similaires d’un design à un autre. Il est donc très commode d’utiliser des scripts qui permettent d’automatiser la synthèse logique et donc de gagner du temps ! Les étapes décrites dans ce tutorial sont rassemblées dans deux scripts : ./scripts/run.tcl qui contient les com8 mande de synthèse (analyze, elaborate, compile), les commandes de reporting (report_area, report_timing, etc). D’autre part, ce script appele le script qui contient les contraintes explicites à appliquer au circuit ./scripts/contrainte.tcl. Pour exécuter l’ensemble de ces commandes, il suffit d’executer le script run.tcl : source ./scripts/run.tcl 1. Notez la valeur de la fréquence maximum atteignable par le circuit synthétisé. 2. Notez également sa surface et sa consommation de puissance. 3. Fixez une fréquence cible de 200 MHz 4. Relancer le script de synthèse 5. Relever, la fréquence max, la surface et la consommation de puissance. 6. Expliquer les différences de valeurs obtenues. 6 6.1 Simulation pré/post synthèse avec Modelsim Pourquoi simuler ? Modelsim est un outil de simulation de systèmes numériques développé par la société MentorGraphics. C’est un outil très largement utilisé dans l’industrie. Nous allons utiliser Modelsim pour simuler notre système avant synthèse (simulation comportementale) et après synthèse (simulation de la netlist générée par DC). La simulation post-synthèse permet d’une part de valider l’étape de synthèse logique en s’assurant que la netlist générée par DC a bien le même comportement que la description comportementale. D’autre part, Modelsim permet de simuler notre système avec une contrainte de temps (fréquence d’horloge fixée) afin de vérifier que notre système peut fonctionner avec la fréquence maximum annoncée par DC. 6.2 Simulation pré-synthèse La simulation pré-synthèse permet de vérifier le fonctionnement de notre système, c’est à dire de s’assurer que le VHDL/Verilog que l’on a écrit permet bien de faire ce que l’on souhaite (un comptage modulo 64). L’invocation de l’outil modelsim se fait par la commande launch_modelsim. Une fois l’outil lancé, assurez-vous d’être dans le répertoire de simulation : File > Change Directory et choisir le répertoire $HOME/tuto_synopsys/counter/sim. 9 Figure 2 – Simulation pré-synthèse Notez que le répertoire sim/ contient un sous répertoire source/ qui contiendra les différents fichiers source nécessaire à la simulation. Pour préparer la simulation du compteur au niveau comportemental (avant synthèse) : — Créez un nouveau projet que l’on nommera par example simu_counter dans le répertoire sim/ : File > New > Project, puis : Browse > $HOME/tuto_synopsys/counter/sim/ — Ajouter au projet le fichier VHDL contenant la description comportementale du compteur : Project > Add To Project > Existing File : $HOME/tuto_synopsys/counter/source/counter.vhdl — Ajouter également le test bench qui se trouve dans le répertoire sim/source $HOME/tuto_synopsys/counter/sim/source/tb_counter.vhdl — Compiler tous les fichiers : Compile > Compile All Votre système est alors prêt à être simulé. Pour lancer la simulation : — Ouvrir la fenêtre de simulation : Simulate > Start Simulation — Dans l’onglet Design, sélectionner l’architecture behavior du test bench — Cliquez sur OK, la simulation se lance 10 — Faites glisser les signaux que vous souhaitez visualiser dans l’onglet wave. — Dans l’invite de commande de modelsim, tapez : restart, puis run 1us. Vérifiez que la sortie value du compteur correspond bien à un comptage modulo sur 6 bits. 6.3 Simulation post-synthèse SANS annotations de timing Figure 3 – Simulation post-synthèse avec annotations temporelles. Pour faire une simulation post-synthèse dans Modelsim, nous avons besoin de trois éléments : 1. Un test bench (tb_counter.vhdl). Celui-ci se trouve déjà dans le projet. 2. Une netlist de notre circuit générée par Design Compiler utilisant les portes logiques de la librairie AMS : counter_syn.vhdl 3. Une description fonctionnelle de chaque porte logique de la librairie AMS : fichiers vhdl ou verilog se trouvant dans le répertoire /net/ens/cleroux/libs_ams (c35_CORELIB.v et c35_UDP.v) Ajout de la netlist : — Enlevez la description comportementale du compteur : dans l’onglet Project, clique droit sur counter.vhdl puis Remove from Project — Ajouter la description au niveau porte : Project > Add to Project > Existing File > $HOME/synopsys/counter/sim/source/counter_syn.vhdl Compilation de la librairie : — Créez une bibliothèque : Dans l’invite de commande de Modelsim, tapez : vlib c35_corelib . 11 Une bibliothèque est normalement créee dans l’onglet Library et un répertoire c35_corelib est crée dans $HOME/synopsys/counter/sim/. — Compilez les fichiers verilog dans la librairie c35_corelib : tapez vlog -work c35_corelib /net/ens/cleroux/libs_ams/c35_CORELIB.v , puis vlog -work c35_corelib /net/ens/cleroux/libs_ams/c35_UDP.v Compilation et simulation du design Nous allons maintenant simuler le fonctionnement du circuit synthétisé : — Compilez : Compile > Compile All — Ouvrez la fenêtre de simulation : Simulation > Start Simulation — Dans l’onglet Librairies rajouter la librairie que vous venez de compiler : c35_corelib — Dans l’onglet Design, sélectionnez une résolution en ns, décochez la case enable optimization et lancez la simulation du testbench. Vérifiez que le circuit synthétisé implémente effectivement un compteur modulo 64. 6.4 Simulation post-synthèse AVEC annotations de timing A l’issue de la synthèse logique, vous avez généré un fichier .sdf qui contient les temps de propagation de toutes les portes logiques contenues dans votre netlist. Nous allons maintenant integrer ces informations de temps de propagations dans la simulation post-synthèse du circuit. Compilation et simulation du design avec annotations de timing Nous allons maintenant simuler le fonctionnement du circuit synthétisé en incluant les annotations temporelles calculées pendant la synthèse logique (counter_syn.sdf) : — Compilez : Compile > Compile All — Ouvrez la fenêtre de simulation : Simulation > Start Simulation — Dans l’onglet SDF, chargez le fichier d’annotations temporelles à appliquer au composant à tester (/tb_counter/uut) : — Browse > counter_syn.sdf — Apply to Region > tb_counter/uut (on applique les temps spécifiés dans le fichier .sdf uniquement au counter se trouvant dans le test bench) — Sélectionnez les temps de propagation min : Delay > max 12 — Dans l’onglet Librairies rajouter la librairie que vous venez de compiler : c35_corelib — Dans l’onglet Design, sélectionnez une résolution en ns, décochez la case enable optimization et lancez la simulation du testbench Le compteur fonctionne t-il correctement ? 7 Annexe Voici une liste non exhaustive des fichiers utilisés dans design compiler : — Extension des fichiers sources — les fichiers .v sont des fichiers source en langage Verilog — les fichiers .vhd/.vhdl sont des fichiers source en langage VHDL — les fichiers .edif sont des fichiers source au format EDIF — Extension des fichiers de synthèse et de script — les fichiers .sdf (standard delay format) sont des fichiers contenant les temps de propagations extraits après synthèse — les fichiers .scr/.sh/.tcl sont des fichiers script — Extension des fichiers de rapport de compilation et de login — les fichiers .log sont des fichiers contenant toutes les commandes et alias de l’application. Fichier très utile pour tracer les erreurs lors de la synthèse. — les fichiers .db/.ddc sont répertoriés dans la base de données du logiciel. C’est également l’extension par défaut de DDC. 13