Timing Simulation Quartus+ModelSim mit Testbench - Signale gehen in unbesimmten Zusand

[Dustin F. (nudeleisen)]

Hi Jungs!

Ich hab das Problem, dass meine funktionale Simulation von meiner Logik 
super mit meiner Testbench geht, aber die Timing-Simulation einfach 
nicht will. Dazu folgendes:

Wenn man Quartus gesagt hat, dass die Timing-Simulation mit ModelSim 
gemacht werden soll, fallen bei der Synthese *.vho Datein für Slow- und 
Fast-Model sowie SDO-Dateien raus. In den Dateien ist das Verhalten der 
originalen VHDL Dateien noch einmal mit den durch die Bibliotheken des 
FPGA-Chips ermittelten Signallaufzeiten nachgebildet oder?

So... funktionale Simulation ist easy: Projekt-VHDL-Dateien und 
anschließend die Testbench kompilieren und dann die Testbench einfach 
ausführen und schauen was passiert.

Wenn ich eine Timing Simulation machen möchte, mache ich folgendes:

- im Modelsim ein neues Projekt anlegen
- in dem Projekt alle benötigten Dateien rein schmeißen
  - vho-Datei
  - sdo-Datei
  - Testbench
- beim Hinzufügen der sdf-Datei muss wegen der Testbench noch eine 
Instanz angegeben werden, auf die sich die SDF-Datei beziehen soll
- alles kompilieren
- anschließend das Projekt simulieren (weil Testbench - einfach auf 
"Feuer" drücken)

Beim Kompilieren der SDO Datei wurden keine Fehler angezeigt.

Folgendes soll passieren:

Nachdem durch das von der Testbench erzeugte Input-Signal eine FSM im 
DUT gestartet wurde, soll das Ausgangssignal "abc" vom DUT von '0' auf 
'1' wechseln. Nach 3 Takten ist die FSM in einem anderen Zustand, 
wodurch das Signal "abc" wieder '0' wird.

Folgendes passiert:

"abc" = '0'
Eingangssignal von TB wird am DUT angelegt
FSM startet
"abc" = x
nach drei Takten
"abc" = '0'

Und das passiert mit allen andern Signalen auch.

Also entweder bin ich zu blöd ein Design zu machen, oder zu doof es zu 
Simulieren.
Wenn ich nur die vho Datei mit dem SDF File im Projekt einbinde, dann 
geht alles. Nur kann ich dann meine Testbench nicht benutzen, sondern 
müsste tcl Skripte schreiben. Das wäre aber wieder doof für meine 
Studienarbeit.


Ich schau alles nochmal durch. Wenn ihr auf Anhieb keine Ideen habt, was 
ich falsch mache, mach ich den Code nochmal bisschen schön und reich den 
noch nach, wenn das besser ist.

Dank euch schon mal im Voraus!!

[Duke Scarring (Gast)]

Dustin F. schrieb:
> Wenn ich eine Timing Simulation machen möchte, mache ich folgendes:
Abgesehen von Deinem konkreten Problem: Warum möchtest Du eine 
Timingsimulation machen?

Man braucht schon einen guten Grund für eine Timingsimulation. Ich habe 
die Timingssimulation vor ein paar Jahren das letzte Mal gebraucht, um 
Synthesefehler im XST aufzuspüren...

Mit den passenden Timingconstraints und einem synchronen Design kann man 
auf die Timingsimulation verzichten.

Duke

[SuperWilly (Gast)]

Zeig doch mal ein paar Screenshots des Wave-Verlaufes...

Vg, SuperWilly

[SuperWilly (Gast)]

... für die funktionale und Timing-Simulation.

Vielleicht noch den Code-Teil dazu, der die Zutandswechsel zeigt.

[Dustin F. (nudeleisen)]

Duke Scarring schrieb:
> Dustin F. schrieb:
>> Wenn ich eine Timing Simulation machen möchte, mache ich folgendes:
> Abgesehen von Deinem konkreten Problem: Warum möchtest Du eine
> Timingsimulation machen?
>

Nja, das wollte ich machen um mein Studienprojekt zu Verifizieren. Ich 
dachte, dass ich einfach meine TBs auf die neuen vho Files los lasse, 
und wenn das passt, dann hab ich meine Back-End Verifikation.

> Mit den passenden Timingconstraints und einem synchronen Design kann man
> auf die Timingsimulation verzichten.

Das Design ist synchron gehalten und Constraints hab ich für die Clocks 
bisschen eingestellt... Weil die Eingänge alle Schalter sind und die 
Ausgänge vom FPGA (incl. clk) zum ASIC gehen hab ich überall delays von 
0 gesetzt. Die Summary von Quartus ist zumindest zufrieden.


Ja ich komm gerade auch immer mehr von dieser Zeitsimulation hab. 
Vielleicht mach ich die Backen-Verifikation einfach mit Wireshark - istn 
Ethernetsendecontroller - oder so. Aber das wurmt mich trotzdem, dass 
das nich so geht wie ich will :/

[Dustin F. (nudeleisen)]

SuperWilly schrieb:
> ... für die funktionale und Timing-Simulation.
>
> Vielleicht noch den Code-Teil dazu, der die Zutandswechsel zeigt.

Ich hab das Augenmerk mal auf "start_tx" gelegt. Das ist das erste was 
geprüft wird und mir komisch aufgefallen ist. rst_n_cnt ist allerdings 
auch komisch und wird im zweiten Prozess generiert. Ich hab im Bild das 
Signal ctrl_in(2) vergessen. Das ist die ganze Zeit '0'....


Syntehese-Logik

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.numeric_std.ALL;
USE WORK.memory_pkg.ALL;

entity frame_ctrl is

  port  (

    clk     : in std_logic;    
    rst_n    : in std_logic;
    saddr_in  : in std_logic_vector(memory_depth-1 downto 0);
    eaddr_in  : in std_logic_vector(memory_depth-1 downto 0);
    ctrl_in    : in std_logic_vector(15 downto 0);
    tx_done    : in std_logic;
    start_tx  : out std_logic;
    rst_n_cnt  : out std_logic;
    frame_addr  : out std_logic_vector(memory_depth-1 downto 0);
    frame_ctrl_done  : out std_logic;
    failure    : out std_logic_vector(2 downto 0)
  );

end frame_ctrl;


architecture rtl of frame_ctrl is

signal reset   : std_logic:= '1';
--signal fsm_state     : unsigned (3 downto 0) := (others => '0');

type state_type is (resetSTATE, 
      idleSTATE, 
      waitSTATE, 
      loopSTATE, 
      delaySTATE);
signal currentstate  : state_type := resetSTATE;

type cyco_type is (  resetCYCO, 
      idleCYCO, 
      execCYCO);
signal currentCYCO  : cyco_type := resetCYCO;

signal start_fsm   : std_logic := '0';
signal loop_en     : std_logic;

signal delay_en     : std_logic;

begin


reset <= not(rst_n);
start_fsm <= ctrl_in(0);


  transmit_count : process (clk, reset)
  begin

    if reset = '1' then
      currentstate <= resetSTATE;
      frame_addr <= (others => '0');
      failure <= "000";
    elsif rising_edge(clk) then

      case currentstate is
        
        when resetSTATE =>
          -- alle Signales werden resettet-spar ich an der Stelle mal aus
          currentstate <= idleSTATE;
        when idleSTATE => -- fsm_state <= "0000";
          start_tx <= '0';
          if start_fsm = '1' then
            frame_ctrl_done<='0';
            loop_en <= ctrl_in(1);
            currentstate <= waitSTATE;
            end if;
          else 
            currentstate <= idleSTATE;
          end if;

        when waitSTATE => -- fsm_state <= "0001";
          
          if tx_done = '1' then
            currentstate <= loopSTATE;
          end if;
          
        when loopSTATE => -- fsm_state <= "0010";

          if loop_en = '0' then              -- erster Fall : loop = 0; nur Paketfolge!
            start_tx <= '1';
            currentstate <= delaySTATE;
          end if;

        when delaySTATE => -- fsm_state <= "0100";

          start_tx <= '0';

.....


reset_cyco : process (clk, reset)
  begin
    if reset = '1' then
      currentCYCO <= resetCYCO;

    elsif rising_edge(clk) then
      case currentCYCO is
      
        when resetCYCO =>
          rst_n_cnt <= '0';
          currentCYCO <= idleCYCO;
        
        when idleCYCO =>
          rst_n_cnt <= '1';
          if ctrl_in(2) = '1' then
            rst_n_cnt <= '0';
            currentCYCO <= execCYCO;
          end if;
        
        when execCYCO =>
          rst_n_cnt <= '1';
          if (ctrl_in(2)) = '0' then
            currentCYCO <= idleCYCO;
          end if;
          
        when others =>
    
      end case;
    end if;
  end process;
end architecture;

Testbenchschnipsel

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.numeric_std.ALL;
USE WORK.memory_pkg.ALL;

entity frame_ctrl_tb is end frame_ctrl_tb;

architecture TestBench of frame_ctrl_tb is

component frame_ctrl
  port  (clk, rst_n, tx_done  : in std_logic;
    saddr_in, eaddr_in  : in std_logic_vector(memory_depth-1 downto 0);
    ctrl_in      : in std_logic_vector(15 downto 0);
    start_tx, rst_n_cnt, frame_ctrl_done  : out std_logic;
    frame_addr    : out std_logic_vector(memory_depth-1 downto 0);
    failure      : out std_logic_vector(2 downto 0));
end component;

signal clk, rst_n, tx_done    : std_logic;
signal sending_done1, sending_done2  : std_logic;
signal saddr_in, eaddr_in    : std_logic_vector(memory_depth-1 downto 0);
signal ctrl_in        : std_logic_vector(15 downto 0);
signal start_tx, rst_n_cnt, frame_ctrl_done  : std_logic;
signal frame_addr      : std_logic_vector(memory_depth-1 downto 0);
signal failureX        : std_logic_vector(2 downto 0):=(others => '0');

signal count_delay                    : std_logic;
signal count_quant                    : integer := 0;

signal sending_done_process  : std_logic;

signal failure_process_en  : std_logic;


begin

------------- <Portmap Anfang> ------------- 

DUT: frame_ctrl
port map (  clk=>clk, 
        rst_n=>rst_n, 
        tx_done=>tx_done, 
        saddr_in=>saddr_in, 
        eaddr_in=>eaddr_in, 
        ctrl_in=>ctrl_in, 
        start_tx=>start_tx, 
        rst_n_cnt=>rst_n_cnt, 
        frame_ctrl_done=>frame_ctrl_done, 
        frame_addr=> frame_addr, 
        failure=>failureX);

------------- <Portmap Ende> ------------- 

stimClk: process
  begin
    clk <= '1'; wait for 20 ns;
    clk <= '0'; wait for 20 ns;
  end process stimClk;


watchFAILURE: process
  variable i : integer;
  begin
    wait until (clk'event and clk = '1');
    if failure_process_en = '1' then
      if failureX /= "000" then
        assert false report "FAiLuRE!!!!!!!!!!!!!!!" severity FAILURE;
      end if;
    end if;
  end process watchFAILURE;
  
process

  variable i,j : integer;

  begin
    rst_n <= '1'; wait for 100 ns;
    rst_n <= '0'; wait for 100 ns;
    rst_n <= '1'; wait for 100 ns;

    failure_process_en <= '1';

    report "______________________________________________________ Test 1.0 : package single, no delay, no loop";
    frame_ctrl_test ("00000", "00000", x"02", x"1", '0', '0', '0', saddr_in, eaddr_in, ctrl_in, start_tx, rst_n_cnt, frame_addr, frame_ctrl_done,  sending_done_process, count_quant, count_quant);
    report "______________________________________________________ Test 1.0 : successful";
    wait for 18000 ns;

Die Testbench generiert die signale in einer Prozedur und gibt die Werte 
dann auf die Signale.

Was noch aufgefallen ist, ist dass ModelSim nicht ganz ohne Warnings 
tut:

# Loading instances from 
C:/altera/workspace/Verifikation/nwft_ohne_nios/simulation/modelsim/netw 
ork_frame-transmitter_vhd.sdo
# Loading timing data from 
C:/altera/workspace/Verifikation/nwft_ohne_nios/simulation/modelsim/netw 
ork_frame-transmitter_vhd.sdo
# ** Warning: Design size of 2 instances exceeds ModelSim ALTERA 
recommended capacity.
# This may because you are loading cell libraries which are not 
recommended with
# the ModelSim Altera version. Expect performance to be adversely 
affected.
# ** Note: (vsim-3587) SDF Backannotation Successfully Completed.
#    Time: 0 ps  Iteration: 0  Instance: /frame_ctrl_tb File: 
C:/altera/workspace/Verifikation/nwft_ohne_nios/simulation/modelsim/fram 
e_ctrl_tb.vhd
run
run
run
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.067 ns; At : 203.093 ns
#    Time: 203093 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\cycletime[1]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\start_addr[0]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[7]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[6]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[4]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\cycletime[2]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\start_addr[2]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\start_addr[1]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns
#    Time: 203106 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[5]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.089 ns; At : 203.116 ns
#    Time: 203116 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\frame_ctrl_done~reg0\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.089 ns; At : 203.116 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[7]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.094 ns; At : 203.117 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[6]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.094 ns; At : 203.117 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[5]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.094 ns; At : 203.117 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[4]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.094 ns; At : 203.117 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[2]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.094 ns; At : 203.117 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[1]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.094 ns; At : 203.117 ns
#    Time: 203117 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[0]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.103 ns; At : 203.137 ns
#    Time: 203137 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\cycleend[0]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.103 ns; At : 203.137 ns
#    Time: 203137 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\quant_cnt[1]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.103 ns; At : 203.137 ns
#    Time: 203137 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\quant_cnt[0]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.103 ns; At : 203.137 ns
#    Time: 203146 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\frame_diff[1]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.129 ns; At : 203.146 ns
#    Time: 203146 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\frame_diff[3]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.129 ns; At : 203.146 ns
#    Time: 203146 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\frame_diff[4]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.129 ns; At : 203.146 ns
#    Time: 203146 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\frame_diff[5]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.129 ns; At : 203.146 ns
#    Time: 203146 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\frame_diff[0]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.126 ns; At : 203.147 ns
#    Time: 203147 ps  Iteration: 0  Instance: /frame_ctrl_tb/DUT/loop_en
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.146 ns; At : 203.181 ns
#    Time: 203189 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[1]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.167 ns; At : 203.189 ns
#    Time: 203189 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[0]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.167 ns; At : 203.189 ns
#    Time: 203189 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loop_cnt[3]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.167 ns; At : 203.189 ns
#    Time: 203189 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[2]\
# ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
#   Expected := 0.186 ns; Observed := 0.167 ns; At : 203.189 ns
#    Time: 203189 ps  Iteration: 0  Instance: 
/frame_ctrl_tb/DUT/\loops[3]\


Bild im Anhang.


Ich geh langsam so bisschen von VDHL-Designfehlern aus. Komisch ist nur: 
praktisch läuft das ganze Super und die funktionale Simulation funzt 
auch super....

Ach Kopf-->Tisch!

Dank´ euch schon mal fürs lesen!!

Ist das halbwegs lesbar?

[bko (Gast)]

wo kommt dein Reset her?

Du hast asynchrone resets
>reset_cyco : process (clk, reset)
>  begin
>    if reset = '1' then
Siehe auch:
Beitrag "Re: Xilinx und die Resets"

In der Testbench sehe ich Ihn hier:
>  rst_n <= '1'; wait for 100 ns;
>  rst_n <= '0'; wait for 100 ns;
>  rst_n <= '1'; wait for 100 ns;

Der TB-Reset wird inaktiv bei positiver Taktflanke, deswegen die 
Hold-time Verletzung(en), und bei einer solchen wird das
"getroffene" Flipflop vom  Simulator auf 'X' gesetzt...
>#   Expected := 0.186 ns; Observed := 0.067 ns; At : 203.093 ns  <==
>#    Time: 203093 ps  Iteration: 0  Instance:
>/frame_ctrl_tb/DUT/\cycletime[1]\
># ** Warning: */DFFEAS HOLD  Low VIOLATION ON ENA WITH RESPECT TO CLK;
>#   Expected := 0.186 ns; Observed := 0.086 ns; At : 203.106 ns

>komisch ist nur: praktisch läuft das ganze Super
Evtl. verbirgt sich hier Zukünftig ein: "komisch-manchmal hängt die 
Schaltung....

[Dustin F. (nudeleisen)]

bko schrieb:
> wo kommt dein Reset her?
>

Der rst_n Input wird negiert auf reset. Steht gleich nach dem Begin. Ist 
damit ich nicht durcheinander komme mit negiert und nicht negiert.


> Du hast asynchrone resets
>>reset_cyco : process (clk, reset)
>>  begin
>>    if reset = '1' then

Genau

> Siehe auch:
> Beitrag "Re: Xilinx und die Resets"
>

Weiß noch nicht worauf du hinaus willst.

Zum reset: im Asynchronen reset-Teil wird alles sofort ausgeführt. Bei 
meiner FSM hab ich nochmal einen reset-State ... der ist überflüssig 
oder? weil er ja erst wieder ausgeführt wird wenn der async-reset weg 
ist und dann u.U. erst ein Takt später ausgeführt wird, oder?



> In der Testbench sehe ich Ihn hier:
>>  rst_n <= '1'; wait for 100 ns;
>>  rst_n <= '0'; wait for 100 ns;
>>  rst_n <= '1'; wait for 100 ns;
>
> Der TB-Reset wird inaktiv bei positiver Taktflanke, deswegen die
> Hold-time Verletzung(en), und bei einer solchen wird das
> "getroffene" Flipflop vom  Simulator auf 'X' gesetzt...

Ach krass. Da muss ich beim schreiben meiner Testbench die su- und 
hold-time quasi mit berücksichtigen?! Auweia.... Wobei doch da aber auch 
der Reset async erlaubt sein sollte? Muss ich das dann in den 
Constraints beachten?
Der Reset im eigentlichen Design kann vom nem Taster oder vom Nios am 
Ende erfolgen.

>>komisch ist nur: praktisch läuft das ganze Super
> Evtl. verbirgt sich hier Zukünftig ein: "komisch-manchmal hängt die
> Schaltung....

Gut zu wissen :/

[bko (Gast)]

Wie alle alle asyncronen Signale sollten auch Resets
einsyncronsisiert werden, und um mir Tipparbeit zu sparen
hab ich den Link genommen, da steht vieles zum Thema Reset
(zwar für Xilinx, gilt aber auch für Altera) einer der Beiträge
ist von Lothar und ich kanns nicht besser formulieren, deshalb noch
ein Link:
Beitrag "Re: Reset für mehrere Komponenten"

Darum die Frage, wo kommt dann in deiner Schaltung der Reset her (nicht 
in der Testbench):
>Der Reset im eigentlichen Design kann vom nem Taster oder vom Nios am
>Ende erfolgen.
Also kann er tatsächlich asyncron zum Takt sein..

>Ach krass. Da muss ich beim schreiben meiner Testbench die su- und
>hold-time quasi mit berücksichtigen?! Auweia.... Wobei doch da aber auch
>der Reset async erlaubt sein sollte? Muss ich das dann in den
>Constraints beachten?
Wenn du eine Timingsimulation machst -ja-, für den Anfang reicht es alle
Stimuli mit der fallenden Taktflanke zu ändern.

In der realen Schaltung musst du asyncrones einsyncronisieren ...
Warum, steht auch schon bei Lothar M, darum also noch ein Link:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

[Dustin F. (nudeleisen)]

bko schrieb:
> Wie alle alle asyncronen Signale sollten auch Resets
> einsyncronsisiert werden, und um mir Tipparbeit zu sparen
> hab ich den Link genommen, da steht vieles zum Thema Reset
> (zwar für Xilinx, gilt aber auch für Altera) einer der Beiträge
> ist von Lothar und ich kanns nicht besser formulieren, deshalb noch
> ein Link:
> Beitrag "Re: Reset für mehrere Komponenten"
>

Krass, danke! Hatte gerade noch bisschen gelesen und gesehen, dass das 
mit dem asynch-reset nicht so einfach abzuhandeln ist.

> Also kann er tatsächlich asyncron zum Takt sein..
>

Ja. Ich spiel wegen der Problematik mit dem Gedanke, die asnychronen 
Signale über ne einfache Impuls-Detektion zu machen, damit der 
Arbeitsaufwand nicht noch weiter ausartet:

Wenn Impuls detektiert, dann gebe für einen Takt ein high-signal aus und 
sperre für paar Takte den Impuls-Detektor.
Die Smarte Lösung wäre natürlich das richtige einsynchronisieren mit 2-3 
FF :/


>>Ach krass. Da muss ich beim schreiben meiner Testbench die su- und
>>hold-time quasi mit berücksichtigen?! Auweia.... Wobei doch da aber auch
>>der Reset async erlaubt sein sollte? Muss ich das dann in den
>>Constraints beachten?

> Wenn du eine Timingsimulation machst -ja-, für den Anfang reicht es alle
> Stimuli mit der fallenden Taktflanke zu ändern.
>

nice to know!!

> http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

Danke dir! Ach FPGAs programmieren kann halt doch nich jeder^^
Neuer ToDo auf der Liste...

Mein Timing-Simulations-Problem ( siehe "start_tx" ) rührt aber woanders 
her oder?!

[SuperWilly (Gast)]

Zeig doch mal zum Vergleich das Wave der funktionalen Simulation ...

[Dustin F. (nudeleisen)]

SuperWilly schrieb:
> Zeig doch mal zum Vergleich das Wave der funktionalen Simulation ...

gern

[SuperWilly (Gast)]

Was passiert, wenn Du "ctrl_in" in der Testbench bei der 
Signal-Deklaration vorinitialisierst (mit x"0000") ?

[SuperWilly (Gast)]

Was passiert, wenn Du die Stimuli (wie bereits vorgeschlagen) mit der 
fallenden Flanke der Taktes änderst?

[Dustin F. (nudeleisen)]

SuperWilly schrieb:
> Was passiert, wenn Du "ctrl_in" in der Testbench bei der
> Signal-Deklaration vorinitialisierst (mit x"0000") ?

Hiho,

krass, lag wirklich nur an der Signalinitialisierung! Die Hold-Time 
Verletzungen beim Reset sind auch weg. Habs danach nochmal mit Anlegen 
der andern Signale bei fallender Flanke probiert. Schaut auch gut aus! 
Muss nur nochmal die assertion-check-delay wegen der Signallaufzeiten 
anpassen.

Super danke! Auch wenn es mich jetzt ärgert, weil ich da auch selbst 
hätte drauf kommen können.
Zudem ist ärgerlich, dass ich die Initialisierungen vorher alle mal drin 
hatte. Nachdem ich dann eine Vorlesung hatte, in der unser Lehrer gesagt 
hat, dass wir alles über einen reset initialisieren sollen und nicht 
über := Zuweisungen hab ich das alles wieder raus geschmissen und nach 
reset verlagert. In den Hardwarebeschreibungs-Vorlesungen hat auch 
niemand mal was vom einsynchronisieren von asynchronen Signalen 
gesagt... na toll... und sowas als Etechniker.

Als ToDo ist jetzt also noch offen, dass die asynchronen resets in 
synchrone umgeschrieben werden müssen und das Signal vorher mit 2-3 FF 
einsynchronisiert werden muss.
Mit ist leider aufgefallen, dass die Eingänge an dem frame_ctrl Modul 
alle async sind, weil die vom NiosII über eine simple PIO-Schnittstelle 
erzeugt werden.

Hach, wieder viel gelernt. Danke!

[Duke Scarring (Gast)]

Dustin F. schrieb:
> Mit ist leider aufgefallen, dass die Eingänge an dem frame_ctrl Modul
> alle async sind, weil die vom NiosII über eine simple PIO-Schnittstelle
> erzeugt werden.
Der NIOS läuft doch auch mit einem Takt. Und die PIO-Ausgänge sind zu 
diesem Takt synchron. Asynchron wird es erst, wenn Du im fram_ctrl-Modul 
eine andere Taktquelle verwendest.

Duke