why does ModelSim capture at the same edge

Question

Hi All!   Currently I'm seeking for understanding why ModelSim 6.6d is capturing my data partly at the following (as expected) and the same edge of the clock: I'm trying to simulate the behaviour of a source synchronous interface (in VHDL) and generated some data in a testbench which I feed into the UUT. The unit is only expected to capture the data:      process (ep_clk, nreset)
begin
  if nreset = '0' then
    local_data  &lt;= (others =&gt; '0');
    local_de    &lt;= '0';
    local_hsync &lt;= '0';
    local_vsync &lt;= '0';
  elsif rising_edge(ep_clk) then
    local_data  &lt;= ep_data;
    local_de     &lt;= ep_de;
    local_hsync &lt;= ep_hsync;
    local_vsync &lt;= ep_vsync;
  end if;
end process;All signals are std_logic(_vector), ep_* are inputs, local_* are outputs. Running the simulation using a 166MHz clock shows that de, hsync and vsync are captured at the same clock edge (which i did not expected). The 48bit ep_data is split: the upper 24 are captured at the next edge while the lower 24 bits are at the same. (If I delay the ep_* signals at the generator the capture is all at the following edge.)   Can anymore please explain this behaviour to me? I would have expected that all data is captured always at the following edge in behaviour simulations. What can I do to force capture at the following edge?   Thank You!    Pauliman

altera_forum · Answer

As expected, your code should be capturing all of ep_data in the same clock edge as everything else.

There's no black magic VHDL behaviour there.

Are you running a RTL or gate level simulation?

If it's gate level, there's a (unlikely) possibility it's due to delays.

But I'd wager it's a subtle bug somewhere before that's delaying half of ep_data one more clock -- been there, done that. :)

Are you looking at the actual ep_data and local_data signals in Modelsim?

altera_forum · Answer

You are probably experiencing simulation 'delta' delays, where the simulator is evaluating several simulation events during zero elapsed time, and the cycle where the rising edge is detected is occurring when not all signals are in their new (or old) state.

You should launch ep_clk slightly before or after the other ep_xx signals to ensure that its simulation cycle is unique, eg., use an after 1 ns delay.

Cheers,

Dave

altera_forum · Answer

This can be easy to do an annoying when you first see it - but a common problem can be the testbench. Can I guess you have something like this?  
ep_clk &lt;= not ep_clk after 10 ns; --or whatever it is for 166MHz
ep_hsync &lt;= '0', '1' after 10ns;
You see the problem is here is that hsync will change at the same time as the clock. BUT - because the rising edge function (and 'event detection) take that extra delta to fire, when local_hsync is assigned it has already changed to '1'.  So, the best thing to do is synchronise the hsync input to the clock in the testbench, and dont use direct time amounts.  
process
begin
  ep_hsync &lt;= '0';
  
  wait until rising_edge(ep_clk);
  ep_hsync &lt;= '1';
  wait;
end process;

altera_forum · Answer

Many thanks for all your answers and suggestions.

rbugalho: I'm doing just gate level simulations.

dwh: is there any way to force this delay everywhere?

Tricky: I'm launching the data using ep_clk (actually an equivalent signal in the testbench). So launch and latch clock are the same.

Yesterday I thought I'd found the problem: ep_clk was generated using ep_clk <= clk and nReset, so that ep_* is launched at clk and latched at ep_clk. Unfortunately feeding ep_clk directly by clk does not change the situation.

Adding a delay between launch and clock leads to the expected result, data is latched one cycle after launch.

What puzzles me most is, that if the launch/latch conditions are unexpected at this point in code, is it the same elsewhere? If so, my simulations results would be quite useless...

Is there any way to force more precise evaluation or add a general delay to all data assignments so that latching is always one clock cycle after launch?

altera_forum · Answer

are you aware that asignments add 1 delta cycle? so assigning clocks from other clocks can cause the same problem.

was the data input using clk or ep_clk? if you used clk, then it would be 1 delta before ep_clk, and cause the problem you are describing.

Forum Discussion

why does ModelSim capture at the same edge

9 Replies

Recent Discussions

log signal to signal tap

Quartus Prime Pro 26.1 - Where to find Documentation of new Signaltap features

Quartus did not start

How can I use Quartus Pro 25.1 sopc-create-header-files tool to generate a jtag master header file?

recovery timing issue