D- Flip Flop using blocking assignments
module RisingEdge_DFlipFlop_SyncReset(D,clk,sync_reset,Q);
input D; // Data input
input clk; // clock input
input sync_reset; // synchronous reset
output reg Q; // output Q
always @(posedge clk)
begin
if(sync_reset==1'b1)
Q = 1'b0;
else
Q = D;
end
endmodul
e
**
D Flip Flop using Non Blocking assignments**__
module RisingEdge_DFlipFlop_SyncReset(D,clk,sync_reset,Q);
input D; // Data input
input clk; // clock input
input sync_reset; // synchronous reset
output reg Q; // output Q
always @(posedge clk)
begin
if(sync_reset==1'b1)
Q <= 1'b0;
else
Q <= D;
end
endmodule
How does above code differ with respect to synthesis . To what logic does above code with blocking assignment get synthesized to .
In reply to ritheshraj:
LMSTFY using Xilinx Vivado.
As the two images show, in this case blocking or non-blocking assignments do not affect the results of synthesis.
In reply to sbellock:
Although in this case there is no difference in synthesized results, there may be a difference in simulation results. So always use non-blocking assignments if one process writes, and another process reads the same variable synchronized to the same clock edge.
As Dave mentioned, in this case there is no difference in the synthesis result. But for the below code the implementation will change.
##Blocking Assignment
always @(posedge clk or negedge rst) begin
if(!rst) begin
a = 0;
b = 0;
end else begin
a = d;
b = a;
end
end
##Non-Blocking Assignment
always @(posedge clk or negedge rst) begin
if(!rst) begin
a <= 0;
b <= 0;
end else begin
a <= d;
b <= a;
end
end
BLocking assignment code will have only single flop while nonblocking assignment will have two flops.
In reply to dave_59:
Hey Dave,
I tried synthesizing both codes one using blocking assignment and another using non-blocking assignment. I observed that there is no change in hardware but I was failed to observe change in simulation result. Can you please tell me what is the difference if I simulate the code with different assignments?
Thank you.
In reply to Payal_Ashar:
The problem may appear when you connect the output of this DFF to the input of another DFF. I say may because it is a race condition. See a simpler example I gave here.