Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

how this RTL infer in synthesis

Status
Not open for further replies.
K

kil

Member level 5
Joined
Feb 15, 2006
Messages
89
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,286
Location
banglore
Activity points
2,032
Hi All,

How the below code infer during the synthesis....


module infer (q,d,clk);

input d,clk;
output q;
reg q,p;

always @(posedge clk)
begin
q = p;
p = d;

end

always @(posedge clk)
begin
q <= p;
p <= d;

end

always @(posedge clk)
begin
p <= d;
q <= p;

end

always @(posedge clk)
begin
p = d;
q = p;

end

How this above logic will infer...... since it consists of blocking and non blocking statemnets .....

Please give your feedback on this

regards
kil
 

The first three behave equal (q pipelined), blocking action occurs only in the last example, where q receives immediately the d state.
 

Hi,

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.....

Thanks
KIL
 

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.

A classical paper about blocking/non-blocking:
 

Hi FvM,

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 ........

Regards
Kil
 

Hi,

Here 4th will infer a single flop with d->q

2nd and 3rd are equivalent since non blocking can be put in any order and they will infer two register with d->p->q

1st will also infer two flops d->p-> q .
 

always @(posedge clk)
begin
q <= p;
p <= d;

end

always @(posedge clk)
begin
p <= d;
q <= p;

end

how this works?does it give any error???

Added after 2 minutes:

two always blocks in a single module will be execued parallaly.right???
 

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.
 

hi,

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.
Click to expand...

Hope it helps
 

Hi ALL,

Thanks for you valuble feed back it helped me alot...

Regards
KIL
 

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...
 

nikhilindia85 said:
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...
Click to expand...

Yes, I believe that is correct.

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.
 

look in the attached file.

you will find the accurate answer in Page 6.

Also you can search this doc in google for zero point.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top