Piloter des bancs de test VHDL depuis des fichiers de stimulus externes avec TEXTIO

Lire des données de stimulus depuis un fichier externe est un moyen puissant de contrôler un Device‑Under‑Test (DUT) en VHDL. En scriptant une séquence de valeurs de signaux et de temps de simulation dans un fichier texte brut, les concepteurs peuvent rapidement échanger des motifs de test sans modifier la logique du banc de test. Cet article, le second d'une série sur l'accès aux fichiers en VHDL, montre comment lire un fichier de stimulus avec la bibliothèque TEXTIO et appliquer ses valeurs à un multiplexeur 4 entrées.

Vue d'ensemble du cas de test

Le DUT est un multiplexeur 4‑vers‑1 standard, asynchrone, avec des mots de données de 8 bits. Le banc de test ne fait aucune vérification de sortie — il pilote simplement les entrées pour que la forme d'onde puisse être examinée manuellement. La déclaration d'entité est reproduite ci-dessous pour référence.

 entity mux_4 is port( din_0 : in unsigned(7 downto 0); din_1 : in unsigned(7 downto 0); din_2 : in unsigned(7 downto 0); din_3 : in unsigned(7 downto 0); sel : in unsigned(1 downto 0); dout : out unsigned(7 downto 0)); end entity; 

Les signaux qui se connectent au DUT sont déclarés dans l'architecture du banc de test et instanciés avec l'étiquette DUT :

 signal din_0 : unsigned(7 downto 0); signal din_1 : unsigned(7 downto 0); signal din_2 : unsigned(7 downto 0); signal din_3 : unsigned(7 downto 0); signal sel : unsigned(1 downto 0); signal dout : unsigned(7 downto 0); DUT: entity work.mux_4(rtl) port map ( din_0 => din_0, din_1 => din_1, din_2 => din_2, din_3 => din_3, sel => sel, dout => dout ); 

Conception du fichier de stimulus

Bien que de nombreux formats soient possibles, l'exemple ci-dessous illustre une disposition claire et lisible par l'homme. Chaque ligne représente une étape de simulation et contient :

• wait_time – délai depuis l'étape précédente (ex: 10 ns)
• sel – valeur du sélecteur 2 bits
• din_0 à din_3 – valeurs de données 8 bits en hexadécimal
• Commentaire de fin de ligne optionnel commençant par # pour affichage console

Les commentaires qui commencent une ligne sont ignorés par le banc de test ; les commentaires qui suivent un jeu de données sont affichés sur la console du simulateur.

 # Description des colonnes : # wait_time | sel | din_0 | din_1 | din_2 | din_3 # Affichage console optionnel 0 ns 0 AA BB CC DD # Setting initial values 10 ns 1 AA BB CC DD # Testing by changing the selector signal 10 ns 2 AA BB CC DD 10 ns 3 AA BB CC DD 10 ns 3 A1 B1 C1 D1 # Testing by changing all data inputs 10 ns 3 A2 B2 C2 D2 10 ns 3 A3 B3 C3 D3 10 ns 3 00 00 00 D2 # Changing all unselected inputs 10 ns 3 01 02 03 D2 10 ns 3 11 22 33 D2 1 ns 0 CC DD EE FF # Changing all inputs fast 1 ns 1 DD EE FF CC 1 ns 2 EE FF CC DD 1 ns 3 FF CC DD EE 10 ns 0 00 00 00 00 # Simulation stop 

Lecture du fichier avec TEXTIO

Voici le processus principal qui ouvre le fichier de stimulus, analyse chaque ligne, affecte les valeurs aux entrées du DUT, et gère les commentaires. L'exemple suppose un fichier bien formaté — un espace sépare les colonnes, et le caractère # est suivi d'un seul espace.

 PROC_SEQUENCER : process file text_file : text open read_mode is "stimulus.txt"; variable text_line : line; variable ok : boolean; variable char : character; variable wait_time : time; variable selector : sel'subtype; variable data : dout'subtype; begin while not endfile(text_file) loop readline(text_file, text_line); -- Ignorer lignes vides et commentaires de ligne seule if text_line.all'length = 0 or text_line.all(1) = '#' then next; end if; read(text_line, wait_time, ok); assert ok report "Read 'wait_time' failed for line: " & text_line.all severity failure; hread(text_line, selector, ok); assert ok report "Read 'sel' failed for line: " & text_line.all severity failure; sel <= selector; hread(text_line, data, ok); assert ok report "Read 'din_0' failed for line: " & text_line.all severity failure; din_0 <= data; hread(text_line, data, ok); assert ok report "Read 'din_1' failed for line: " & text_line.all severity failure; din_1 <= data; hread(text_line, data, ok); assert ok report "Read 'din_2' failed for line: " & text_line.all severity failure; din_2 <= data; hread(text_line, data, ok); assert ok report "Read 'din_3' failed for line: " & text_line.all severity failure; din_3 <= data; wait for wait_time; -- Afficher commentaire de fin de ligne sur console, s'il y en a read(text_line, char, ok); -- Ignorer nouvelle ligne attendue read(text_line, char, ok); if char = '#' then read(text_line, char, ok); -- Ignorer nouvelle ligne attendue report text_line.all; end if; end loop; finish; end process; 

Sortie de simulation

Lors de l'exécution dans ModelSim, la console affiche les commentaires de fin de ligne avec le temps de simulation cumulatif. L'extrait suivant montre la séquence des notes imprimées :

 # ** Note: Setting initial values # Time: 0 ns Iteration: 1 Instance: /file_stim_tb # ** Note: Testing by changing the selector signal # Time: 10 ns Iteration: 0 Instance: /file_stim_tb # ** Note: Testing by changing all data inputs # Time: 40 ns Iteration: 0 Instance: /file_stim_tb # ** Note: Changing all unselected inputs # Time: 70 ns Iteration: 0 Instance: /file_stim_tb # ** Note: Changing all inputs fast # Time: 91 ns Iteration: 0 Instance: /file_stim_tbf # ** Note: Simulation stop # Time: 104 ns Iteration: 0 Instance: /file_stim_tb # Break in Process PROC_SEQUENCER at file_stim_tb.vhd line 98 

La forme d'onde produite par le banc de test reflète le timing et les valeurs de données du fichier, permettant aux concepteurs de vérifier le comportement du DUT visuellement.

Points clés à retenir

• Les fichiers de stimulus externes donnent aux concepteurs un contrôle granulaire sur les séquences de test sans modifier le code du banc de test.
• L'utilisation de TEXTIO garde le banc de test concis, mais exige un formatage de fichier discipliné.
• Incluez toujours un mécanisme d'auto-vérification — soit en comparant avec un modèle comportemental, soit en intégrant les sorties attendues dans le fichier de stimulus.

En suivant l'exemple ci-dessus, vous pouvez exploiter toute la flexibilité du TEXTIO de VHDL pour piloter des scénarios de test complexes tout en maintenant une structure de banc de test propre et maintenable.