Modélisation du comportement d'un projet Quartus sur Verilog dans l'environnement ModelSim

Dans le dernier article, nous avons fait un module assez complexe. Bien sûr, j'ai inséré le résultat déjà débogué dans le corps de l'article. Mais il m'a semblé que c'est assez étrange quand l'auteur dit «fais ce que je fais», mais ne montre pas un processus très important. Laissez-moi vous montrer comment vous déboguez généralement un système par simulation. De plus, le prochain article contiendra des informations que même moi je ne connaissais pas il y a une semaine. Mais pour y arriver, vous devez comprendre les principes de base. Alors. Voyons comment préparer et lancer tout aussi rapidement le processus de modélisation dans l'environnement ModelSim.









Comment fonctionne un programme informatique ordinaire? Il existe un certain environnement externe (le moniteur et le clavier avec "souris" sont les représentants les plus typiques de cet environnement même). Le programme interagit avec eux. Lors du débogage, vous pouvez créer de véritables influences à partir de l'environnement externe, ou vous pouvez les émuler. Nos testeurs écrivent souvent toutes sortes de scripts qui ne font qu'émuler des influences externes. Après cela, les analyseurs de journaux sont lancés, qui vérifient que les réponses sont correctes mercredi.



Et si tout était bogué dans ce programme informatique? Vous pouvez définir des points d'arrêt et examiner un instantané du système au moment où ils frappent. Une tranche du système correspond aux valeurs des variables. Peut-être les états de divers mutex et autres objets de synchronisation. En général, un instantané des paramètres internes du système débogué.



Lors du débogage des FPGA, vous pouvez faire la même chose. Certes, si l'environnement est réel, alors s'arrêter et étudier une partie du système est problématique, bien que possible. Dans le cadre de l'histoire de Redd, je continue à promouvoir l'idée que tout doit être simple et rapide. Nous ne concevons pas de systèmes complexes. Nous faisons une sorte de modules, comme ce qui a été fait dans le dernier article . C'est sophistiqué, mais très, très simple. En général, nous ferons sa modélisation comportementale.



Et ici se pose la question de l'environnement extérieur. Comment le simuler? Les modèles viennent à notre aide. Verilog (ainsi que VHDL et d'autres similaires) est tout à fait possible de décrire le comportement de quoi que ce soit. Nous fabriquons un système qui fonctionne avec la puce ULPI ... Donc, pour tester son fonctionnement, il doit y avoir quelque chose à l'autre extrémité qui se comporte exactement comme l'ULPI. Autrement dit, le modèle ULPI. Mais ce n'est pas assez. Notre bloc réagit aux commandes du bus ALAVON_MM. C'est ce bus qui fait vivre le bloc. Par conséquent, nous devons également ajouter le modèle de bus AVALON_MM, et ce modèle doit être actif. C'est elle qui soumettra des influences de test.







En fin de compte, nous devons créer un tel système. Et puis nous pourrons enregistrer des chronogrammes de signaux sur tous ses bus et même à l'intérieur de n'importe lequel de ses modules. Si une erreur se produit, nous pouvons définir des points d'arrêt et examiner des instantanés du système pour trouver l'ennemi. Bien que, personnellement, je ne règle généralement pas ces points d'arrêt, le plus souvent l'analyse des chronogrammes suffit. Le fait est que les signaux peuvent être visualisés non seulement les signaux d'interface, mais tous les signaux internes. En extrayant une douzaine ou deux signaux internes sur le graphique, vous pouvez généralement deviner ce qui est mal implémenté dans la logique.



Le but de l'article d'aujourd'hui n'est pas de parler de ce qu'est la modélisation en général (c'est une longue histoire), mais de montrer comment faire cette modélisation le plus rapidement. Et nous considérerons cela non pas sur une mission de combat, mais sur un exemple simple. Nous allons créer un système de test très simple pour que dans le prochain article, nous comprenions déjà d'où viennent les jambes d'une version plus complexe de celui-ci, car lors de la lecture, il est plus pratique de ne pas s'asseoir et de se demander: «Pourquoi fait-il cela?», Mais connaître tous les principes de base, dont les complications découlent déjà ... Soit dit en passant, récemment, il s'est avéré qu'une de mes connaissances, bien qu'elle possède l'habileté de la modélisation, ne savait pas que l'environnement Quartus avait des mécanismes intégrés qui vous permettent de le faire facilement et naturellement. Il y a consacré beaucoup plus d'efforts que nécessaire. Alors peut-être que quelqu'un aussi apprendra maintenant quelque chose de nouveau sur les possibilités inhérentes à Quartus. Alors,Commençons.

Verilog

Les gens se divisent en deux catégories. Ceux qui aiment tout créer à partir de zéro avec leurs mains et ceux qui aiment le faire avec la souris. Tout créer avec vos mains est plus correct. Vous pouvez contrôler chaque action et faire tout ce que vous savez parfaitement. Mais la mémoire n'est pas fiable. Si elle fait la même chose tout le temps, elle garde les détails à l'esprit, et si elle doit changer de langue tout le temps, après un mois ou deux, elle doit se souvenir de ce qui doit être fait là-bas. Par conséquent, travailler avec l'option "bricoler avec la souris" a le droit d'exister, ne serait-ce qu'à cause de cela. Encore une fois, si le module en cours de débogage a une douzaine de signaux d'interface, je suis toujours ennuyé de faire le travail de routine de les re-déclarer et de les transmettre. Par conséquent, nous allons maintenant examiner comment créer un modèle en utilisant la "souris". Et puis - chacun décidera pour lui-même si cela lui suffit ou s'il doit passer au travail manuel.



Donc, nous voulons simuler un module. Ce qui est «simuler» dépasse le cadre de notre cycle, vous pouvez écrire un grand cycle séparé sur ce sujet. Autrement dit, dans le cadre de cette section, nous supposons que vous connaissez la méthodologie de développement d'un modèle. Mais alors tout doit être inclus dans le projet ... Ou pas? Curieusement, vous n'avez même pas besoin de créer votre propre projet pour modéliser un module. Nous pouvons nous attacher en tant que parasite à n'importe quel projet sans y inclure quoi que ce soit de nouveau, mais uniquement en créant une suite de tests qui ne participera en aucune façon à l'assemblage principal.



Par souci d'intérêt, attachons à notre projet ULPI un module aussi amusant sur SystemVerilog, écrit par moi spécifiquement à des fins d'illustration et n'a rien à voir avec l'analyseur développé. Il y a quelque temps, j'ai eu beaucoup de problèmes avec le calcul des sommes de contrôle, alors cela m'est venu à l'esprit.

module sum(
input         clk,
input [7:0]   data,
input         we,
input         sof,
output [15:0] sum
);

logic [15:0] temp;

always @ (posedge clk)
begin
     if (we) 
     begin
         if (sof)
             temp <= data;
         else
             temp <= temp + data;
     end
end

//   - 
//assign sum = (~temp)+1;
//    :
assign sum = temp;
endmodule

On peut voir que les données y parviennent via un bus, qui rappelle très loin AVALON_MM, et sont simplement sorties en code parallèle.



Mettons le fichier résultant dans le répertoire avec notre projet, mais nous ne l'inclurons pas dans le projet de Quartus. Au lieu de cela, nous allons créer une suite de tests spécialement pour cela. Pour ce faire, sélectionnez l'élément de menu Assignments—> Settings:







et dans l'arborescence qui apparaît, recherchez l'élément EDA Tools Settings—> Simulation:







A propos du type de simulation mis en évidence par le cadre vert. Peut-être que quelqu'un se souvient que dans les premiers articles j'ai dit que lors de la création d'un projet, par pure habitude, je choisis ModelSim Altera? C'était l'arme même sur la scène qui, tôt ou tard, devait tirer. Cependant, si le type de modélisation n'a pas été sélectionné lors de la création du projet, vous pouvez le sélectionner ou le modifier ici.



Nous continuons à créer une suite de tests. Basculez le bouton radio sur Compiler le banc de test (au fait, comment ce terme se traduit-il magnifiquement en russe? Je ne peux pas me résoudre à écrire "banc de test", car je ne vois pas de banc) et appuyez sur le bouton Bancs de test :







dans la boîte de dialogue qui s'ouvre, appuyez sur Nouveau :







Si faire cas de test manuellement, vous pouvez remplir les champs en une seule passe. Mais puisque nous faisons tout avec la "souris", maintenant nous ne remplissons qu'une partie des champs, et nous remplirons le reste plus tard. Dans le champ Nom du banc d'essaiJ'ai tapé le mot Parazit (que pouvez-vous appeler un test qui ne fait que parasiter le projet?). Le mot Parazit en dessous était rempli automatiquement. Maintenant, nous ne le changerons pas, mais à l'avenir, nous devons encore le faire. Aussi, en utilisant le bouton "...", j'ai sélectionné le fichier sum.sv avec le code de l'additionneur à déboguer, puis, en utilisant le bouton Ajouter , je l'ai poussé dans la liste des fichiers de test. Pour l'instant, c'est tout. Fermer la boîte de dialogue ...







Ensuite, nous continuerons à former le test dans l'environnement ModelSim. Pour ce faire, sélectionnez l'élément de menu Outils -> Exécuter les outils de simulation -> Simulation RTL:







La fenêtre ModelSim s'ouvre. Peut-être que des erreurs seront trouvées dans le code Verilog, alors vous devez fermer ModelSim, corriger les erreurs et rouvrir. Mais tôt ou tard, la liste des erreurs deviendra purement organisationnelle. Cela me ressemble:







Aucun module de niveau supérieur trouvé. C'est normal. Nous ne l'avons pas encore créé simplement. Par conséquent, nous allons travailler dans la liste des bibliothèques et l'ouvrir. Le voici, notre additionneur.







Survolez-le, appuyez sur le bouton droit de la souris et sélectionnez l'élément de menu Créer une vague. Tout cela est tellement ennuyeux dans le texte, si je tournais une vidéo, tout le processus prendrait des dizaines de secondes, alors ne vous inquiétez pas, mais surveillez vos mains plus loin. Alors, Create Wave ...







Les signaux d'interface du module sont automatiquement déplacés vers le graphique:







Il est nécessaire d'attribuer une valeur à l'un d'entre eux. Peu importe lequel, il est important de nommer. Le très ancien environnement de modélisation de Quartus était bon pour générer des signaux d'horloge. Hélas, il a été retiré de la livraison il y a longtemps, depuis qu'ils ont commencé à attacher ModelSim, et ici tout n'est pas si beau avec quelque chose comme ça. Je n'ai pas vu l'intérêt de générer un générateur ici, donc je ne le montrerai même pas. Alors ... Eh bien, mettons la ligne que nous avons à zéro. Nous visons le signal, appuyez sur le bouton droit, sélectionnez l'élément de menu Edit—> Wave Editor—> Create / Modify WaveForm.







Dans la boîte de dialogue qui apparaît, sélectionnez Constante . Et en même temps, nous changerons l'heure, disons, de 100 microsecondes:







Ensuite, nous indiquons la valeur 0:







Nous avons créé l'ensemble de données minimum requis, et le reste sera plus facile à faire avec des stylos. Nous exportons le fichier. Pour ce faire, sélectionnez l’élément de menu







Fichier - > Exporter -> Forme d’onde: sélectionnez le type de fichier Verilog Testbench (d’ailleurs, il est dommage que ce ne soit pas SystemVerilog, mais à l’avenir, il sera possible de le corriger avec des stylos). Nous définissons également le nom du fichier. Je l'ai nommé parazit_tb , en suivant le "pourquoi pas?"







Voilà, ModelSim peut être fermé, tandis que la maison temporaire n'a pas besoin d'être sauvée.

Que faire ensuite avec le modèle

Voici un fichier Verilog tellement tordu, mais toujours prêt à l'emploi, le système créé pour nous:

`timescale 1ns / 1ns
module parazit_tb  ; 
 
  reg    sof   ; 
  reg    we   ; 
  wire  [15:0]  sum   ; 
  reg  [7:0]  data   ; 
  reg    clk   ; 
  sum  
   DUT  ( 
       .sof (sof ) ,
      .we (we ) ,
      .sum (sum ) ,
      .data (data ) ,
      .clk (clk ) ); 



// "Constant Pattern"
// Start Time = 0 ns, End Time = 100 us, Period = 0 ns
  initial
  begin
  end

  initial
	#0 $stop;
endmodule

L'automatisation nous a évité d'écrire des blocs de construction. De plus, s'il y avait plus de signaux d'interface, l'automatisation enregistrerait et connecterait docilement tous les circuits. Personnellement, lorsque je crée manuellement des suites de tests, c'est le processus de description des signaux et de leur transmission qui est déprimant. Maintenant, dans ce fichier, nous allons maintenant créer un modèle d'environnement qui affectera le module de somme débogué .



Comme vous pouvez le voir, il n'y a aucun sens à définir les constantes faites par l'oscillateur. Mais tout de même, tous les circuits ont été créés, le module à tester est connecté, même la section initiale a été créée. Affinons le code. La première consiste à supprimer le point d'arrêt en supprimant les lignes:

  initial
	#0 $stop;

Ensuite, nous ajouterons un modèle de générateur d'horloge (comme il me manque un merveilleux générateur, qui a été fabriqué par les anciens Quartus! Là, vous pouvez régler la fréquence en mégahertz et ne pas penser à la recalculer dans une période, et plus encore - une demi-période)

  always 
  begin
      clk = 0;
      #5;
      clk = 1;
      #5;
  end

Nous devons maintenant envoyer des octets de données. Le moyen le plus simple de le faire est directement dans la section initiale , mais si j'écris chaque phase d'accès au bus là-bas, le code de cette section deviendra déroutant. Par conséquent, je vais faire la tâche suivante (c'est elle qui fait office de modèle de pneu):

task SendByte (input reg[7:0] D);
    begin
        data = D;
        we = 1;
        @(posedge clk);
        #1
        we = 0;
   end
endtask

Eh bien, je vais écrire le but des constantes et l'appel de cycles pour travailler avec le bus dans le bloc initial . Permettez-moi de vous rappeler que le type d'enregistrement # 123 signifie "attendre 123 unités de temps". Nous l'avons en nanosecondes. Je vous rappelle également que puisque les affectations sont séquentielles, nous utilisons l'opération "égal" et non la "flèche". Donc, nous avons le code de test principal suivant:



Au total, notre code de module complet ressemble à ceci:

Terminer la préparation du scénario de test

Il est temps d'ajouter ce texte à la suite de tests. Pour ce faire, accédez à la boîte de dialogue que nous connaissons déjà, mais







maintenant nous ne créons pas notre ensemble, mais le sélectionnons dans la liste. À l'avenir, la liste s'agrandira au fur et à mesure que les ensembles seront ajoutés ... Après avoir sélectionné, appuyez sur le bouton Modifier. J'ai apporté trois modifications aux paramètres:

1. Ajout du fichier parazit_tb.v à la liste.
2. Puisque dans le fichier parazit_tb.v , le module de niveau supérieur porte le nom parazit_tb (vous pouvez vous en assurer en regardant la source de la section précédente), j'ai entré ce nom dans le module de niveau supérieur dans la ligne du banc de test .
3. J'ai dit d'exécuter la simulation pendant 10 microsecondes, puis de faire une pause. Si quoi que ce soit, je le ferai en appuyant sur les boutons de commande manuelle.

Total

Nous fermons tout. Exécutez à nouveau ModelSim. On voit que tout fonctionne correctement. Les données arrivent et sont comptées dans le montant. S'il n'y a pas de données sur l'horloge ( nous sommes à zéro), le montant n'augmente pas.







L'utilisation de l'environnement de modélisation lui-même fait l'objet de plusieurs articles. Et plutôt au format vidéo. Mais en général, nous nous sommes familiarisés avec la méthode de préparation et de réalisation rapide des tests en langage Verilog depuis l'environnement Quartus.



Maintenant que nous savons comment exécuter rapidement la simulation, nous pouvons esquisser un modèle d'environnement pour notre tête d'analyseur USB et tester son fonctionnement. Dans le même temps, nous n'avons pas mémorisé un seul sort ModelSim, puisque Quartus vous permet de tout configurer à l'aide de la "souris". Il génère lui-même tous les scripts nécessaires et appelle lui-même l'environnement ModelSim. Nous avons également créé la base du modèle en mode automatique, bien que nous ayons ensuite dû la modifier manuellement.



Hélas et ah. L'un des éléments de l'environnement externe est le module ULPI. Pour développer vous-même son modèle, vous devez tout d'abord bien comprendre la logique de fonctionnement de ce microcircuit. Et dans l'article précédent, j'ai dit que c'était très délicat. Et, deuxièmement, vous devez passer beaucoup de temps à développer le code du modèle. Et l'élimination des erreurs ... Il est clair qu'il est plus facile de trouver quelque chose de tout fait. Mais le modèle prêt à l'emploi n'a été trouvé que dans le langage SystemC. Par conséquent, dans le prochain article, nous allons apprendre à modéliser un système en utilisant ce langage.