3
\$\begingroup\$

I have always wondered, what is the right solution to the D flip flop when the input changes right at the rising edge of the clock? I have found two solutions of these online but have no clue which is the right one.

Image 1

or

Image 2

I think the right answer should be image 1 (on top) where the output q appears at next rising clock edge. This is what flip flop should do, i.e create a delay of one cycle.

But I always get image 2 (bottom image) when I run my Verilog code. My code is:

module beh(q,d,en,clk);
input q,clk,en;
output d;
reg d;
always@(posedge clk)
begin
if(en==1)
d<=q;
end
endmodule

What am I doing wrong?

\$\endgroup\$
3
\$\begingroup\$

First one is generally how it is supposed to look as the output level AFTER the active clock edge should reflect the input level BEFORE the active clock edge. However, when the input transition falls ON the active clock edge, it's ambiguous as it is technically a violation of the setup and hold time. In this case, the difference between using <= and = in your testbench will determine if you get #1 or #2. This is because of the way delta cycles work. If you use = in the testbench, then the new value will be reflected at the input of the flip-flop immediately at the beginning of the cycle and you will get #2. However, if you use <=, then the new value will be reflected at the end of the update cycle and you will get #1.

I went through several different testbench iterations to find the most effective one. At first, I used = in the testbench for the clock generator and for the testbench logic and the testbench logic ran on the falling edge instead of the rising edge. This made the traces in the simulator a bit more obvious (halfway between your #1 and #2), however I ran into some timing issues when trying to get some deeper interaction between the testbench and the DUT. I ended up moving on to using = in the clock generator and <= in the testbench and switching the testbench over to using the rising edge of the clock. This ended up looking like your #1, and it solved the interaction issues I was having. Now, I use the Python-based MyHDL for the functional part of the testbench with a verilog wrapper for the DUT, but that's a completely different story.

\$\endgroup\$
6
  • \$\begingroup\$ "it's ambiguous as it is technically a violation of the setup and hold time." It all depends on the hardware. In FPGA's, zero hold time specs are common. In 7400 logic, a positive hold time is required. I don't work in ASICs so I can't speak to that. \$\endgroup\$
    – The Photon
    Sep 17 '14 at 4:03
  • \$\begingroup\$ Yeah, I suppose it's not a violation in all cases. I think it's a bigger issue in simulation than in a real circuit because the setup and hold in the simulator is basically zero as it checks the level in a very specific simulator cycle, and not any earlier or later. \$\endgroup\$ Sep 17 '14 at 4:31
  • \$\begingroup\$ When the input changes right at the clock edge, the real hardware's non-zero setup time spec is violated. Hold time spec is often 0, but I've never seen an FPGA or other real digital logic with zero setup time. (The real setup time varies from part to part and varies with temperature.) Simulation should try to match reality, otherwise what's the point. I'll bet if you run simulation on the post-synthesis model instead of the ideal behavioral model, you should see the correct waveform (Q output delayed one clock cycle). \$\endgroup\$
    – MarkU
    Sep 17 '14 at 6:31
  • \$\begingroup\$ @MarkU, if you treat simultaneous transitions on clock and data as a zero hold time, then the setup time is a full clock cycle. \$\endgroup\$
    – The Photon
    Sep 17 '14 at 10:52
  • \$\begingroup\$ Great! How about if i want the image 1 solution in VHDL what changes go in Test bench there? \$\endgroup\$
    – Curious
    Sep 17 '14 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.