www.mikrocontroller.net

Forum: FPGA, VHDL & Co. MODELSIM assert von internen Signalen


Autor: Matthias Krüßelin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bin gerade dabei eine größere Testbench zu schreiben.
Mir ist bekannt, dass man alle Signale, auch von Komponenten
auflisten und im Wave anzeigen lassen kann.
Ist es nun möglich irgendwie darauf mittels assert(...='0')
zuzugreifen?

z.B:
ENTITY tb_user_logic IS
END tb_user_logic;
 
ARCHITECTURE behavior OF tb_user_logic IS 
 
    -- Component Declaration for the Unit Under Test (UUT)
 
    COMPONENT user_logic
    PORT(
       ...
       );
    END COMPONENT;
BEGIN

  -- Instantiate the Unit Under Test (UUT)
   uut: user_logic 
   PORT MAP (
     ...
     );

   clk_process :process
   begin
    Bus2IP_Clk <= '0';
    wait for clk_period/2;
    Bus2IP_Clk <= '1';
    wait for clk_period/2;
   end process;
 
   -- Stimulus process
   stim_proc: process
   begin    
        Bus2IP_Reset <= transport '1';
        -- hold reset state for 3ns.
        wait for clk_period*3; --totaltime: 3ns   
        Bus2IP_Reset <= transport '0';
        assert (IP2Bus_Ack='1') report "IP2Bus_Ack!=1, by RAM read Test, Addr:2" severity failure;

        wait for clk_period*3; --totaltime: 3ns   
        assert (???='1') report "/tb_user_logic/uut/x_motor/ready='1'" severity failure;
        wait;
   end process;
END
---

Wie kann ich nun also auf das Signal "ready" der Componente x_motor der 
Componente uut zugreifen???
Folgendes habe ich probiert, geht aber alles NICHT!!!:
assert("/tb_user_logic/uut/x_motor/ready"='1')
assert("/tb_user_logic/uut/x_motor.ready"='1')
assert(/tb_user_logic/uut/x_motor/ready='1')
assert(/tb_user_logic/uut/x_motor.ready"='1')
assert(tb_user_logic/uut/x_motor/ready='1')
assert(tb_user_logic/uut/x_motor.ready"='1')
assert(uut/x_motor/ready='1')
assert(uut/x_motor.ready"='1')

Vielen Dank im voraus,
Matthias Krüßelin

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Möglichkeit gibt es in VHDL nicht. Mit einem Assert-Statement kann 
nur ein Signal innerhalb desselben Moduls überwacht werden. Deshalb 
musst Du die assert-Statements in den einzelnen Modulen "verteilen".

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aus der ModelSim-Doku (manchmal lohnt es sich eine Doku tatsächlich):

"init_signal_spy()
The init_signal_spy() utility mirrors the value of a VHDL signal or 
Verilog register/net onto an
existing VHDL signal or Verilog register. This allows you to reference 
signals, registers, or nets
at any level of hierarchy from within a VHDL architecture (such as a 
testbench).
See init_signal_spy for complete details."

Gruß
Joko

Autor: Matthias Krüßelin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Deshalb musst Du die assert-Statements in den einzelnen Modulen
> "verteilen".

"verteilen" - wie ist das gemeint?
Klar, ich kann jedes Modul separat testen.
Aber ich kann nicht in den "normalen" VHDL-Code,
also in einer erzeugten Komponente, Asserts einfügen;
wie soll das gehen?

Ist die einzige Möglichkeit benötigte Signale bis auf
die oberste Instanz durchzuschleifen?
Dann müsste ich die ganzen Components,Entity's usw. ergänzen,
was ja doch sehr aufwändig sein wird...

Modelsim kennt ja die internen Signale,
und kann diese präsentieren,
daher kann ich nicht ganz verstehen, weshalb ich aus
der Testbench nicht darauf zugreifen kann...

Vielleicht hilft ein kleines Beispiel...

Danke und Grüße
Matthias Krüßelin

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias Krüßelin

>Ist die einzige Möglichkeit benötigte Signale bis auf
>die oberste Instanz durchzuschleifen?

Nein - siehe meine Antwort oben: genau DAS macht "init_signal_spy"

Gruß

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

>Aber ich kann nicht in den "normalen" VHDL-Code,
>also in einer erzeugten Komponente, Asserts einfügen;
>wie soll das gehen?

klar kannst Du: mit

-- synthesis translate_off
  blablabla
-- synthesis translate_on

kannst Du jede beliebigen Code für die Synthese
unsichtbar machen - der ist dann nur noch für die
Simulation relevant

Gruß

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch besser:

Du definierst für deine Simulation ein globales Package mit globalen
Signalen:

package global_probes is
signal probe_ls_signal_in_deep_hierarchy : std_logic;
end package;


Das Signal, das du beobachten willst, wird diesem globalen Signal
zugewiesen (in der Komponente)


--synthesis_off
probe_ls_signal_in_deep_hierarchy <= ls_signal_of_interest;
--synthesis_on


In deiner Testbench und in deiner Komponente bindest du nun das globale 
Package ein:

library work;
use work.global_probes.all;

Nun kannst du bequem in der Testbench deine Assert-Abfragen vornehmen:

assert probe_ls_signal_in_deep_hierarchy='0' ....

Gruß,
SuperWilly

Autor: Matthias Krüßelin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
@Joko: vielen Dank, habe Deinen Beitrag erst nach meinem Eintrag 
gelesen, sorry...

Vielen Dank für die schnelle Hilfe :-)

Grüße
Matthias Krüßelin



Nun zur Vervollständigung:

VHDL Syntax
init_signal_spy(<src_object>, <dest_object>, <verbose>, <control_state>)
Verilog Syntax
$init_signal_spy(<src_object>, <dest_object>, <verbose>, <control_state>)
SystemC Syntax
init_signal_spy(<src_object>, <dest_object>, <verbose>, <control_state>)

noch ein Beispiel:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
library modelsim_lib;
use modelsim_lib.util.all;

ENTITY tb_user_logic IS
END tb_user_logic;
 
ARCHITECTURE behavior OF tb_user_logic IS 
 
    -- Component Declaration for the Unit Under Test (UUT)
 
    COMPONENT user_logic
    PORT(
       ...
       );
    END COMPONENT;

    signal x_motor_ready : std_logic := '0';

BEGIN

  -- Instantiate the Unit Under Test (UUT)
   uut: user_logic 
   PORT MAP (
     ...
     );

   -- Signal Spy Process 
   spy_proc: process 
   begin
    init_signal_spy("/tb_user_logic/uut/x_motor/ready", "/tb_user_logic/x_motor_ready", 1, 1);
    wait;
   end process;


   clk_process :process
   begin
    Bus2IP_Clk <= '0';
    wait for clk_period/2;
    Bus2IP_Clk <= '1';
    wait for clk_period/2;
   end process;
 
   -- Stimulus process
   stim_proc: process
   begin    
        Bus2IP_Reset <= transport '1';
        -- hold reset state for 3ns.
        wait for clk_period*3; --totaltime: 3ns   
        Bus2IP_Reset <= transport '0';
        assert (IP2Bus_Ack='1') report "IP2Bus_Ack!=1, by RAM read Test, Addr:2" severity failure;

        wait for clk_period*3; --totaltime: 3ns   
        assert (x_motor_ready='1') report "/tb_user_logic/uut/x_motor/ready='1'" severity failure;
        wait;
   end process;
END


Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorteile der Global-Package-Variante:

1. Simulator unabhängig
2. Design-Hierarchien können beliebig verändert werden

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SuperWilly wrote:
> Du definierst für deine Simulation ein globales Package mit globalen
> Signalen:
>
> package global_probes is
> signal probe_ls_signal_in_deep_hierarchy : std_logic;
> end package;
>
> Das Signal, das du beobachten willst, wird diesem globalen Signal
> zugewiesen (in der Komponente)
> --synthesis_off
> probe_ls_signal_in_deep_hierarchy <= ls_signal_of_interest;
> --synthesis_on

Wie funktioniert das mit dem global package dann, wenn von einer 
Komponente mehrere Instanzen vorhanden sind?
Gibt es dann nicht einen Namenskonflikt?

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie funktioniert das mit dem global package dann, wenn von einer
>Komponente mehrere Instanzen vorhanden sind?
>Gibt es dann nicht einen Namenskonflikt?

Wenn man die Instanz eindeutig (bspw. über ein Generic) identifizieren 
kann, so kann man in der Komponenten-Beschreibung folgendes machen:

--Beispiel: 5 Instanziierungen einer Komponente, nur das Signal in 
--Instanziierung 1 soll sichtbar gemacht werden.

p_ProbeMap: process(ls_signal_of_interest)
begin
    if gComponentNumber=1 then
       probe_ls_signal_in_deep_hierarchy <= ls_signal_of_interest;
    else
       probe_ls_signal_in_deep_hierarchy <= 'Z';
    end if;
end process p_ProbeMap;


Muss man halt entscheiden, in welchem Stadium sich das Design befindet
(bezüglich der Hierarchie), ob eine oder mehrere Instanzen einer
Komponente verwendet werden (hier könnte die "init_signal_spy"-Variante
von Vorteil sein, weil man keine Generics mitführen muss).

Gruß,
SuperWilly

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennt jemand das Pendant zu "init_signal_spy" in ActiveHDL von Aldec ?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.