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