But in the first always block the q = p; p = d;the first statement will block the second statement right so the q will not get the present sate d input value .... right.....
In the first example, nothing is "blocked". So it works identical to regular non-blocking statement. Personally, I follow the recommendation not to use blocking assignments in edge sensitive always blocks (sequential code), except for special cases. The behaviour of blocking assignments is similar to using variables in VHDL, my favourite HDL. Sometimes they are useful to create intermediate results.
can u plz elaborate it as in the first statements the q = p;is blocking this statment => p = d; but first d has to assign to p right then p in turn has to assign to q .... thats the way right..........
will the first three statements will give the same results ........
The synthesis-result depends on the synthesis-tool.
Synopsys Design Compiler will usually understand any code inside an always@(posedge clk) to be a latch or register, regardless of blocking/non-blocking assignment.
Other tools might incorrectly map your RTL into a combinatoinal circuit. (Cadence Ambit Buildgates used to do that a lot.)
If you are handed a lot of RTL from an unknown source, it's a good idea to run all of it through a LINTing tool -- the LINTing tool will catch these kind of mechanical coding errors and hazards.
Some thing to share.
I have tried it on LeonardoSpectrum.
The result is all above code are registered. It works as Synopsys DC.
As mentioned by boardlanguage,
Synopsys Design Compiler will usually understand any code inside an always@(posedge clk) to be a latch or register, regardless of blocking/non-blocking assignment.
though a blocking statement in always with posedge clk sttement always infers Flip-Flopo only.A latch with posedge senistivity is not possible.correct me if i am wrong...
though a blocking statement in always with posedge clk sttement always infers Flip-Flopo only.A latch with posedge senistivity is not possible.correct me if i am wrong...
However, I was pointing out that some synthesis tools produce unexpected results if you mix blocking & non-blocking assignments inside the always-block. So even though the 'written RTL description' implies a flipflop, the gate-level output may not match. This is an issue with the synthesis-tool, and it's why the EdA-vendors publish "HDL modeling guidelines" for their synthesis-tools.