Cet article décrira l'installation et l'utilisation de logiciels gratuits de modélisation de circuits logiques numériques dans Verilog comme alternative aux produits commerciaux Incisve de Cadense et ModelSim de MentorGraphics. Comparaison des simulations dans ModelSim et Verilator. Une méthodologie de vérification universelle, UVM, sera également envisagée.
Installation du logiciel SystemC UVM
1. Le vérificateur
Verilog est l'un des langages de description du matériel. Vous pouvez écrire un module dans cette langue.
Par exemple, il existe un schéma de compteur:
Son code ressemblera Ă ceci:
reg [3:0]counter; always @(posedge clk or posedge reset) if(reset) counter <= 4'd0; else counter <= counter + 1'd1;
Après la simulation, nous obtenons les formes d'onde:
On peut voir que la valeur suivante, une de plus que la précédente, sera écrite dans les registres de compteur le long du front de fréquence d'horloge.
Un module écrit peut avoir une structure plus complexe, qui sera difficile à vérifier manuellement tous les états de. Nous aurons besoin de tests automatisés. Pour cela, il est nécessaire de développer un environnement de test dans l'un des langages de programmation. L'environnement de test nous donnera l'opportunité de procéder à un contrôle fonctionnel complet de l'appareil.
Pour tester le code du projet, en plus des langages tels que Verilog, SystemVerilog, Python (pour écrire des modèles), vous pouvez utiliser le langage
SystemC . SystemC est un langage de conception et de vérification de niveau système pour les modèles de niveau système implémentés en tant que bibliothèque C ++ open source.
Une façon de vérifier les modules Verilog à l'aide de SystemC consiste à traduire les fichiers Verilog en C ++. Aidez-nous avec ce Verilator.
Verilator est le simulateur Verilog HDL gratuit le plus rapide qui surpasse la plupart des simulateurs commerciaux. Verilator compile SystemVerilog synthétisé (généralement ce n'est pas du code de banc d'essai), ainsi que certaines instructions de SystemVerilog et Synthesis en code C ++ ou SystemC à un seul thread ou à plusieurs threads. Verilator a été conçu pour les grands projets où les performances de simulation sont primordiales et est particulièrement adapté à la génération de modèles de processeurs exécutables pour les équipes de développement de logiciels embarqués. Verilator est utilisé pour simuler de nombreuses conceptions de passerelles de plusieurs millions de dollars avec des milliers de modules et est pris en charge par de nombreux fournisseurs de technologie IP, y compris IP d'Arm et tous les fournisseurs IP renommés RISC-V.
Verilator peut ne pas être le meilleur choix si vous vous attendez à un remplacement complet de NC-Verilog, VCS ou un autre simulateur Verilog commercial, ou un simulateur de comportement Verilog pour un très petit projet. Cependant, si vous cherchez un moyen de porter Verilog synthétisé sur C ++ ou SystemC, et que votre équipe est libre d'écrire uniquement du code C ++, ceci est un compilateur Verilog gratuit pour vous.
Pour installer la dernière version sur Ubuntu: tĂ©lĂ©chargez l'archive Ă
partir du lien du site officiel .
Installer:
2. GTK Wave
GTKWave est un visualiseur de forme d'onde complet et vous permet Ă©galement de convertir des fichiers du format vcd au format fst, plus pratique et plus rapide.
Installer:
sudo apt-get install gtkwave
3. SYSTEMC
Un langage pour concevoir et vérifier des modèles au niveau du système implémentés sous la forme d'une bibliothèque C ++ open source.
Comme mentionné précédemment, verilator prend en charge systemc, vous devez donc créer un projet dans lequel le test de référence sera décrit sur systemc, et les fichiers source sur verilog synthétisé. Pour ce faire, nous avons besoin des bibliothèques de compilateur g ++ fournies par Accelera. Accellera Systems Initiative est une organisation indépendante à but non lucratif dédiée à la création, au support, à la promotion et à la promotion de normes de conception, de simulation et de vérification au niveau du système pour une utilisation dans l'industrie électronique mondiale.
Téléchargez l'archive:
http://accellera.org/images/downloads/standards/systemc/systemc-2.3.1a.tar.gzInstaller:
tar -xvf systemc-2.3.1a.tar.gz cd systemc-2.3.1a mkdir objdir sudo ./configure --prefix=/usr/local/systemc-2.3.1a/ sudo make sudo make install cd ../
4. UVM pour SYSTEMC
Cet article passe en revue un projet qui implémente des outils de vérification UVM. La vérification est une confirmation de la conformité du produit final aux exigences de référence prédéfinies. L'un de leurs outils de vérification peut être des tests. Afin d'exécuter des séquences de test sur des modèles d'appareils réels au niveau des descriptions RTL, il est nécessaire de développer un environnement de test.
UVM - (Universal Verification Methodology) est une méthodologie de vérification universelle, une norme qui permet le développement et la réutilisation efficaces d'environnements de validation de blocs IP. UVM est une méthodologie de vérification dont les tâches incluent l'organisation d'un environnement efficace autour de l'unité testée. Ses avantages:
- structure claire sous forme de blocs dédiés décidant de
- tâches
- la capacité de réutiliser des blocs dans des projets ultérieurs;
- l'automatisation maximale possible de la vérification;
- les informations de reporting les plus complètes permettant, en cas d'erreur, d'identifier ses causes aussi rapidement et précisément que possible et de proposer des solutions.
Les méthodologies UVM se composent de deux parties: un ensemble de règles pour la construction d'un environnement de test et une bibliothèque de blancs de bloc pour la vérification, par exemple, un générateur de texte, un collecteur de statistiques, etc. Le principal avantage d'UVM est sa polyvalence et sa compatibilité avec les environnements tiers.
Puisque systemc prend en charge la méthodologie UVM, passons à l'installation des bibliothèques nécessaires.
Téléchargez l'archive:
https://www.accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-beta2.tar.gzInstaller:
tar -xvf uvm-systemc-1.0-beta2.tar.gz cd uvm-systemc-1.0-beta2/ mkdir objdir sudo ./configure --prefix=/usr/local/systemc_uvm/ --with-systemc=/usr/local/systemc-2.3.1a sudo make sudo make install
Nous créons une alliance:
sudo mkdir /usr/local/uvm_systemc_aliance
Copiez le contenu des dossiers / usr / local / uvm_systemc_aliance / et /usr/local/systemc-2.3.1/ dans ce dossier
Téléchargez le projet terminé sur le lien:
https://github.com/paprikun/SYSTEMC/Ouvrez le dossier d'exemples du verilator.
Le dossier rtl contient une description de l'appareil. Dans cet exemple, il s'agit d'un contrĂ´leur PWM.
Dans le dossier sim fichier makefile pour la construction du projet.
Dans le dossier tb se trouve le code du vérificateur. Le dossier tb / uvm contient un exemple d'environnement uvm. Le fichier principal est un point d'entrée dans les tests; il connecte le périphérique testé à l'environnement uvm.
Nous essayons de construire le projet Ă partir du dossier sim avec la commande make all. Nous voyons une erreur:
/usr/local/uvm_systemc_aliance//include/systemc.h:120:16: error: 'std::gets' has not been declared using std::gets;
Nous le réparons en remplaçant la ligne 120:
#if defined(__cplusplus) && (__cplusplus < 201103L) using std::gets; #endif
Encore une fois, nous essayons d'exécuter le banc de test et tombons sur l'avertissement:
/usr/local/uvm_systemc_aliance//include/sysc/packages/boost/get_pointer.hpp:21:40: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] template<class T> T * get_pointer(std::auto_ptr<T> const& p)
Remplacez auto_ptr par unique_ptr.
Assemblage et simulation de projet
Maintenant que les bibliothèques sont installées et fonctionnent, nous construisons le projet: tout faire. Le fichier exécutable simu devrait apparaître dans le dossier sim. Il s'agit d'un objet créé par le compilateur. Nous commençons avec l'équipe ./simu. Les informations suivantes devraient apparaître:
SystemC 2.3.1-Accellera --- Jun 28 2019 11:39:29 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED Universal Verification Methodology for SystemC (UVM-SystemC) Version: 1.0-beta2 Date: 2018-10-24 Copyright (c) 2006 - 2018 by all Contributors See NOTICE file for all Contributors ALL RIGHTS RESERVED Licensed under the Apache License, Version 2.0 UVM_INFO @ 0 s: reporter [RNTST] Running test ... simulation real time = 9 sec UVM_INFO uvm_default_report_server.cpp(666) @ 179490249010 ps: reporter [UVM/REPORT/SERVER] --- UVM Report Summary --- ** Report counts by severity UVM_INFO : 1 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 UVM_INFO @ 179490249010 ps: reporter [FINISH] UVM-SystemC phasing completed; simulation finished
Ă€ la fin de la simulation, l'enregistrement du wafeform se termine. Le fichier simu.vcd peut ĂŞtre ouvert avec gtkwave:
Pour afficher les signaux à gauche, sélectionnez SystemC, puis maintenez la touche Maj enfoncée et sélectionnez les signaux, puis cliquez sur Ajouter. Des info-bulles s'affichent dans la barre d'outils lorsque vous survolez. Le défilement de la souris fonctionne, vous devez maintenir shift ou cntrl.
Il existe Ă©galement des moyens de convertir ce fichier en un autre plus petit.
S'il existe des modèles, la conversion sera effectuée. Dans le terminal, entrez la commande vsim. Dans le terminal modelsim:
vcd2wlf simu.vcd simu.wlf
Ou en utilisant gtkwave dans un terminal Linux:
vcd2lxt simu.vcd simu.lxt vcd2lxt2 simu.vcd simu.lxt2
Pour comparer le temps de simulation, un projet similaire a été créé, mais déjà pour
Modelsim . Dossier modelsim_example. Environnement UVM créé de la même manière. La syntaxe est similaire malgré le fait que différentes langues. Si vous avez installé Modelsim avec le support uvm, vous pouvez exécuter la commande make all.
En plus de l'environnement dans les deux projets, une simulation en temps réel des mesures a été prise.
Avec le temps, la différence s'est avérée:
Comme vous pouvez le voir sur le tableau, le verilator a un avantage. Les données sont présentées pour un PC avec 8 Go de RAM, un processeur 8 cœurs, 800 MHz, chargeant un cœur.
Comparez la taille du fichier:
Ici le verilateur perd, mais vous pouvez expérimenter la création de formes d'onde et la profondeur de trace, la période d'enregistrement (le début et la fin de l'enregistrement de la forme d'onde peuvent être décalés). Le fichier à utiliser dépend de vous.
Au cours des tests, en plus de l'heure de la simulation elle-même, une différence a été trouvée dans la lecture des données d'entrée du bus d'entrée. Si les données du bus d'entrée changent pendant le front clk, Modelsim lit les données après le front, vérificateur avant:
input clk; input [7:0] in; reg [7:0] in_last_ ; ... always @(posedge clk) begin ... in_last_ <= in; ... end
Pendant les tests, ce point doit être pris en compte, car une partie de l'environnement de test pour différents simulateurs fonctionnera différemment.
De plus, le vérificateur ne prend pas en compte l'état "x" du signal et traduit tout à "0";
UVM TESTBENCH
Considérez l'environnement de test, le dossier tb / uvm.
Le banc d'essai UVM est l'environnement au-dessus de l'appareil. Dans cet exemple, le périphérique est un contrôleur PWM. Diagramme d'environnement UVM:
Comme vous pouvez le voir dans le diagramme, UVM se compose de blocs (classes). Chaque bloc remplit ses fonctions. L'exemple montre l'une des dispositions possibles de l'environnement de test. Le nom et la fonctionnalité de chaque classe correspondent à la classe dont elle est héritée. Examinons chaque classe plus en détail.
Fichier d'environnement env.h ou env.svh. Il s'agit d'une classe qui peut contenir une ou plusieurs classes d'agent, dans lesquelles trois classes sont connectées: séquenceur, pilote, moniteur. Il n'y a pas d'agent dans l'exemple, mais sa fonction est implémentée dans la classe env. Pour le test, nous devons écrire une séquence d'actions - séquençage.
Passons au code de démarrage du séquençage:
sequence_[n]->start(sqr, NULL);
Sequencer (sequencer) - fichier sequncer.h. Dans le système verilog, il s'est avéré utiliser le séquenceur par défaut. Une classe qui contient une ou plusieurs séquences (séquence) (fichiers sequence_a.h, sequence_a.svh). Chaque séquence est une chaîne d'actions. L'une de ces actions peut être l'envoi d'une transaction. Transaction - transfert de données d'une classe à une autre. La classe dans laquelle les transactions sont décrites est bus_trans. Vous trouverez ci-dessous une description de deux classes, chacune ayant idéologiquement ses propres fonctions spécifiques: pilote et moniteur.
Driver - fichier drv.h, drv.svh. Une classe qui reçoit des transactions d'un séquenceur et les traduit en signaux. Le pilote sert d'assistant séquenceur à un niveau inférieur. Pensez à envoyer un colis.
La séquence ouvre une fenêtre de transaction, le pilote détecte cet événement et commence à recevoir des données. La séquence attend une réponse du conducteur. Le pilote simule les signaux de l'appareil, puis signale au séquenceur que la fenêtre peut être fermée. L'idée est que le séquenceur fonctionne à un niveau élevé et le pilote à un niveau inférieur.
Les signaux sont connectés via le bus d'interface à l'appareil. L'interface est décrite dans les fichiers vip_if.h, vip_if.svh.
Ensuite, vous devez vérifier si les signaux de sortie correspondent à ceux attendus. Il existe deux solutions:
- Écrire un modèle pour un appareil
- VĂ©rification du signal via UVM Agent
Dans l'exemple, la deuxième option est considérée. Pour tester l'appareil au niveau fonctionnel, il est nécessaire de comparer la sortie avec celle attendue. L'exigence de l'appareil était l'exactitude du rapport cyclique donné du signal et la période du signal. Pour surveiller les signaux de sortie, une nouvelle classe est écrite - Monitor (fichier monitor.h, monitor.svh). Habituellement, dans un environnement de test, le moniteur transfère les signaux de la transaction (à un niveau supérieur) et est envoyé à la classe de comparaison - tableau de bord.
Dans cet exemple, les signaux sont vérifiés immédiatement. En cas de divergence entre la valeur attendue et la mesure, le test s'arrête.