Wrong sampling from register during functional simulation

Altera_Forum · ‎01-30-2015

Hello everyone,

During a functional simulation (zero-delay) of my design I experienced a problem related to the correct timing of my registers.

When I run the functional simulation of a single register, sampling occurs the same clock period during which my "enable" signal is active (high), as shown in the "right_sampling" picture.

http://www.alteraforum.com/forum/attachment.php?attachmentid=10082&stc=1

However, when I use that same register (same VHDL code) in a more complex design, sampling occurs one clock period later, when my "enable" signal has gone "low", as as shown in the "wrong_sampling" picture.

http://www.alteraforum.com/forum/attachment.php?attachmentid=10083&stc=1

The only difference in the usage of the register is the following: during the simulation of the single register clock, enable and data are direct input from my testbench file, whereas in my design the register belongs to a datapath and the enable signal come from a control unit.

Thanks very much in advance!

Altera_Forum · ‎01-30-2015

I suspect simulation delta issues - post the code and Im sure we can help.

Altera_Forum · ‎01-30-2015

TO_BE_DONE

Altera_Forum · ‎02-18-2015

You have made a classic synchronization error.

You have described a simple enabled flip-flop. The data and the enable are assumed synchronous to the clock.

Now, in your test bench, you create a clock, which is fine. But your test stimulus -- the data and the enable, are generated asynchronous to that clock. By doing the wait for 10 ns; between changing your data, it looks like they change on the clock edge, but they really don't.

Rather than doing wait for 10 ns; put a wait until rising_edge(clock); before each data change:

enable_process : process --it keeps enable signal cycling every clock period
begin
    wait until rising_edge(clk);
    enable <= '1';
    wait until rising_edge(clk);
    enable <= '0'; 
    wait until rising_edge(clk);
    enable <= '1'; 
    wait until rising_edge(clk);
    enable <= '0'; 
    -- etc 
end process enable_process;
D_in_process: process --random inputs
begin
    wait until rising_edge(clk);
    wait until rising_edge(clk);
    wait until rising_edge(clk);
    wait until rising_edge(clk);
    wait until rising_edge(clk);
    D_in <= "001"; 
    wait until rising_edge(clk);
    D_in <= "010"; 
    wait until rising_edge(clk);
    D_in <= "011"; 
    wait until rising_edge(clk);
    D_in <= "100"; 
    wait until rising_edge(clk);
    D_in <= "101"; 
    wait until rising_edge(clk);
    D_in <= "110"; 
    wait until rising_edge(clk);
    D_in <= "111"; 
end process D_in_process;

So your next question: "How is this different?"

Answer: it has to do with how VHDL schedules updates.

When you do the wait for 10 ns; thing, the process suspends for 10 ns, and then immediately after waking back up it makes the assignment. But what if other processes are doing the same thing? You don't know the order which the scheduler has chosen to do these updates. Maybe the clock updates before the data, maybe it updates afterwards. You don't, and can't, know.

So waiting until the edge of the clock, rather than just waiting some time that happens to be the clock period -- just like you do with code that you expect to synthesize into flip-flops! -- you synchronize all of those various data assignments to that clock.

Here's what happens with the clock-edge paradigm. Each of the data-assignment processes hits something like D_in <= "111"; and D_in changes to "111" as you expect. Then the process suspends until the rising edge of the clock. Now consider that EACH of those data and enable and whatever assignments do the same thing.

As noted, in your unit under test, you have the standard synchronous flip-flop description. What happens there? It waits until the rising edge of the clock. At that instant, it looks at all of the right-hand sides of the assignments and evaluates them. After they are all evaluated, only then does the update of the left-hand side occur.

Try it and see :)