# Synthesizeable D Flip flop for FPGA

Having played around with Verilog for some time now, I decided to graduate to implementing designs on Alltera CycloneIV FPGA using the Quartus suite.

Starting with a simple D flip flop, I face the first road block.

Problem Statement: The output(Q) of a D-FF is required follow the input signal (as it should be), and here goes the code:

//----------------------------------------
//module D flip flip
//-----------------------------------------

module d(q_w,q0_w,d,c);
output q_w,q0_w;
input c,d;

//wire c;
reg q,q0;
wire q_w,q0_w;
assign q_w=q;
assign q0_w=q0;

initial
begin
q=1'b0; q0=1'b1;
end
always @ (posedge c)
begin
q<=d;
q0<= ~d;
end
endmodule


The input signal 'd' also transitions at the same positive edge of a common clock signal ('c' for module D-FF). This is causing the circuit to not behave properly as the transition and testing happens at same edge of clock. Also that I have read it is better to stick to one edge of clock in designs (as a good practice) and am hence abstained from using negative edge of the clock.

Having encountered the same issue when simulating I used a delay to do away with the problem

always @ (posedge c)
begin
#2 q=d;
q0= ~d;
end


Despite searching a lot I cant figure out a way to implement the functionality as required in the hardware. I tried adding buffer elements before the clock signal enters D-FF module but in vain.

PS: I haven't yet burnt any of this on the FPGA yet. My apprehensions are marked by the results of Quartus Simulation.

I have manually tweaked the input D at point to check the follow up of the circuit

What @duskwuff is pointing out is that when you implemented your test waveform (c and d) you have d transitioning at the exact same time as c. This is not how whatever is driving your flip-flop will really work. The input has to be set up before the clock edge. If the input is transitioning at the clock edge--remember that while the edges look square in the logic analyzer, in reality the voltage takes a certain amount of time to transition from one state to another--your flip-flop may read high, low, or some intermediate voltage that may really confuse your logic.

At the first positive clock edge, d transitions from low to high. But because the new value of d (high) was not set up before the clock edge, your flip-flop sees the original value (low) and outputs that on q. The same thing happens on the second positive clock edge.

However, between the second and third positive clock edges, at 140ns, you change d from low to high. So when the clock goes positive the third time at 150ns, it sees the high value, and then q goes high about 8ns later.

Your test sequence should look something like:

1. set clock high
2. wait 1/4 clock cycle
3. set d to some value
4. wait 1/4 clock cycle
5. set clock low
6. wait 1/2 clock cycle
7. set clock high (it's now been one full cycle from last positive edge)
8. wait 1/4 clock cycle
9. check q
• Thanks for the elaborate explanation. It helped. I may change the test waveforms as per what you mentioned. But still, how do I make sure that the waveform is actually shifted in the hardware so as to avoid the problem. Or will this code run just fine on hardware as there will automatically be delays? – Prateek Sharma Mar 11 '16 at 5:20
• As long as everything is driven from the same clock you'll be fine. It's trickier when dealing with asynchronous signals, like from an external serial line. Cross that bridge when you come to it. – Willis Blackburn Mar 11 '16 at 12:19
• How about an up vote? :-) – Willis Blackburn Mar 11 '16 at 12:19
• Sry was away over the weekend. Anywho, just to clarify one last time. This piece of code will run perfectly on the hardware without me requiring any changes? is that right. Thanks again – Prateek Sharma Mar 14 '16 at 8:36
• It should work. But don't take my word for it, synthesize it and see for yourself. – Willis Blackburn Mar 14 '16 at 11:47

First: don't use delays in implementations. Delays cannot be synthesized in hardware; they should be confined to testbench code.

Second: the situation you're testing, where d changes at a clock edge, is a timing violation. Failing under these circumstances is perfectly normal; virtually all flip-flops will fail or exhibit inconsistent behavior when subjected to this input. Adjust your testbench to move the transitions of d such that they don't coincide with the clock edges.

• So do you mean to say that if I run my contentious code on actual FPGA then the result would be consistent?Secondly, aren't tetstbenches, purely simulation tool? If yes, whats the point of tweaking the testbench code. If not necessarily, then how so I 'move the transitions of d such that they don't coincide with the clock edges' if not by using delays. Thanks – Prateek Sharma Mar 11 '16 at 2:16
• Having run on simulation tools earlier, I am now looking only to make it work on actual hardware. Beats me. – Prateek Sharma Mar 11 '16 at 2:32
• Changing the D input to any flip-flop during a clock transition will cause unpredictable behavior. Don't do this in your tests. Edit the input waveform such that this doesn't happen. – duskwuff -inactive- Mar 11 '16 at 3:12
• Thanks. Even though, I may edit the wave form for testing, how do I make sure that the waveform is actually 'shifted' when run on the hardware. – Prateek Sharma Mar 11 '16 at 5:18
• Checking for these timing violations is a part of standard timing analysis, and the software will take care of that for you under most circumstances. – duskwuff -inactive- Mar 11 '16 at 5:55