ModelSim optimiert Signale weg - wie verhindern?

[Markus (Gast)]

Hallo

ich habe folgendes Problem:
Ich habe eine Design Unit die ich mittels Testbench testen will. Soweit 
steht das alles.

Die Simulation wird über DO-Files (Makros) gesteuert. Die Simulation 
soll terminieren wenn ein Testbench-internes Signal (stop_simulation, 
Typ std_logic) getriggert ist.

Das Problem ist jetzt, dass das Signal beim Compilieren rausoptimiert 
wird und später nicht mehr als solches im Simulator verfügbar ist.

Wie kann ich das unterbinden? Ich habs schon mit Compileswitch -O0 
probiert. Bringt aber leider nichts. Ich will mir auch ungern wilde 
Konstrukte überlegen, die Modelsim irgendwie dazu veranlassen das 
Signal drin zu lassen (und evtl. noch in meine DUT rein spuken).

Geht das irgendwie einfacher?

Vielen Dank schonmal.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Markus schrieb:
> Das Problem ist jetzt, dass das Signal beim Compilieren rausoptimiert
> wird und später nicht mehr als solches im Simulator verfügbar ist.
Machst du eine Verhaltenssimulation oder eine Timingsimulation?

> Die Simulation wird über DO-Files (Makros) gesteuert. Die Simulation
> soll terminieren wenn ein Testbench-internes Signal (stop_simulation,
> Typ std_logic) getriggert ist.
Hast du da mal einen einfachen Sourcecode, der das Verhalten zeigt?

[Markus (Gast)]

Lothar Miller schrieb:
> Markus schrieb:
>> Das Problem ist jetzt, dass das Signal beim Compilieren rausoptimiert
>> wird und später nicht mehr als solches im Simulator verfügbar ist.
> Machst du eine Verhaltenssimulation oder eine Timingsimulation?
>

Sorry, steh gerade aufm Schlauch. Was meinst du mit Timingsimulation 
genau?

Ich verifiziere das Verhalten. Einmal auf RTL-Ebene (VHDL Code) einmal 
auf Netlist ebene (Back Annotation File nach Synthese).

>> Die Simulation wird über DO-Files (Makros) gesteuert. Die Simulation
>> soll terminieren wenn ein Testbench-internes Signal (stop_simulation,
>> Typ std_logic) getriggert ist.
> Hast du da mal einen einfachen Sourcecode, der das Verhalten zeigt?

Ist n ziemlich großes Teil, aber ich probiers mal:

Ausschnitt aus DO-Makro:

[...]
run 1 us

when -label l_break {stop_simulation='1'} { echo "Stop Simulation" stop }
[...]

Der Code rennt tatsächlich 1 us und dann terminiert die Simulation 
mit...

# ---------Loading std wave  .. 
# ** Error: (vsim-3561) No objects found matching 'stop_simulation'.
# Error in macro ./dofiles/run_test.do line 25
# ** Error: (vsim-3561) No objects found matching 'stop_simulation'.
#     while executing
# when -label l_break {stop_simulation='1'} { echo "Stop Simulation" stop }

Und wenn ich in der ModelSim GUI nach dem Signal schaue sehe ich auch, 
dass es nicht unter den Objects aufgelistet ist, also rausgeflogen.

Aus Synthesesicht macht das Sinn den das Signal macht im Prinzip nix.
Wird nur am Ende durch ein Flag scharf geschalten.

    p_stop : process
    begin
        stop_simulation <= '0';
        wait until (stop_simulation_flag'event and stop_simulation_flag = '1');
        stop_simulation <= '1';
        wait for 10 ns;
        wait;
  end process p_stop;

[Karl Könner (Gast)]

vcom -O0 -norangecheck +acc -work {deineLib} {deinFile}


+acc steuert die Sichtbarkeit von internenen Signalen, die sonst 
wegoptimierten werden ("Enable access to certain objects which might 
otherwise be optimized away.")

MfG,

[Karl (Gast)]

p_stop : process
    begin
        stop_simulation <= '0';
        wait until (stop_simulation_flag'event and stop_simulation_flag 
= '1');
        stop_simulation <= '1';
        wait for 10 ns;
        wait;
  end process p_stop;



DAS ist aber nichts synthesefähiges.

[Thomas (Gast)]

Liegt es vlt. daran, dass stop_simulation_flag nirgendwo gesetzt wird... 
dann würde es auch sinn machen stop_simulation wegzuoptimieren.

Ansonsten hab ich die Vermutung, dass der Prozess eh sinnlos ist (sofern 
du nicht irgendwelche komplizierteren Bedingeng für die Beendigung der 
Simulation verwendest/brauchst).

wie wärs mit sowas in der art?

  -- clock process
  clk_gen_process : process
  begin

    clk <= '0';

    wait until sim_finish = '0';

    loop
      clk <= not clk;
      wait for CLOCK_CYCLE / 2.0;
      exit when sim_finish = '1';
    end loop;

    wait;

  end process clk_gen_process;

  -- test process
  test_process : process is
  begin

    sim_finish <= '0';

    <Testcases...>

    sim_finish <= '1';

    report " END OF TEST" severity note;
    wait;
    
  end process test_process;

[Markus (Gast)]

Karl Könner schrieb:
> vcom -O0 -norangecheck +acc -work {deineLib} {deinFile}
>
>
> +acc steuert die Sichtbarkeit von internenen Signalen, die sonst
> wegoptimierten werden ("Enable access to certain objects which might
> otherwise be optimized away.")

Vielen Dank! Das werde ich mal ausprobieren.

Karl schrieb:
> p_stop : process
>     begin
>         stop_simulation <= '0';
>         wait until (stop_simulation_flag'event and stop_simulation_flag
> = '1');
>         stop_simulation <= '1';
>         wait for 10 ns;
>         wait;
>   end process p_stop;
>
>
>
> DAS ist aber nichts synthesefähiges.

Schon klar, ist ja auch nur als Simulations-Stop-Signalisierung gedacht. 
Den Sprung bezüglich "Synthesesicht" machte ich nur wegen der 
Optimierung.

Thomas schrieb:
> Liegt es vlt. daran, dass stop_simulation_flag nirgendwo gesetzt wird...
> dann würde es auch sinn machen stop_simulation wegzuoptimieren.
>
> Ansonsten hab ich die Vermutung, dass der Prozess eh sinnlos ist (sofern
> du nicht irgendwelche komplizierteren Bedingeng für die Beendigung der
> Simulation verwendest/brauchst).
>
> wie wärs mit sowas in der art?
>
> [...]

Das stop_simulation_flag wird im Code gesetzt.
Der Sinn hinter dem Prozess ist, den Inhalt der Testcases (es wird viele 
geben) von festen Simulationsteilen zu trennen. Also möglichst wenig 
Simulations-Ablaufsteuerung mit Testcase spezifischem Ablauf 
verwurschteln. Darum der separate Prozess. Am Ende des 
Testcase-Durchlaufs muss dann nur einmal das Flag gesetzt werden. 
Zumindest so der Plan ;-)

Aber falls es doch widererwarten weiter rausoptimiert wird werd ichs mal 
so versuchen.

Komme "leider" erst wieder am Dienstag dazu das zu probieren. Bis dahin 
frohe Ostern :-)

[berndl (Gast)]

pack das Signal einfach mal in deinen Toplevel als Ausgang, zur Not mit 
'translate_off' und 'translate_on' (heisst, nur fuer Simulation, einfach 
mal googlen). Dann kann niemand das Signal wegoptimieren...

[Markus (Gast)]

Hallo Zusammen,

habs nun mit Karls Lösung probiert.

Karl Könner schrieb:
> vcom -O0 -norangecheck +acc -work {deineLib} {deinFile}
>

Funktioniert wunderbar. Vielen Dank für alle die mir hier geholfen 
haben!

[Duke Scarring (Gast)]

berndl schrieb:
> pack das Signal einfach mal in deinen Toplevel als Ausgang, zur Not mit
> 'translate_off' und 'translate_on' (heisst, nur fuer Simulation, einfach
> mal googlen). Dann kann niemand das Signal wegoptimieren...
So mache ich das auch seit geraumer Zeit. Das funktioniert auch sehr 
gut.

Duke

[Andreas (Gast)]

Hallo,

in meinen Designs verhindere ich die Optimierungen zur Compilezeit mit 
dem parameter +acc=v und zusätzlich lässt sich die Simulation mit dem 
Argument -novopt starten, dass ebenfalls Optimierungen verhinern soll.

Viele Grüße
Andreas