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

blocking nature of blocking statements are not cared here-why?

Status
Not open for further replies.
FvM said:
I fear, I'm getting tired of contradicting this assumption. Synthesis does take care of. This way, synthesis results are consistent with simulation.
Click to expand...
FVM

The statement was written to std_match on his context and not to you. I did not wrote that synthesis does not take care of bloking nature of verilog. I agree that synthesis does not take care of bloking nature of verilog.

---------- Post added at 15:48 ---------- Previous post was at 15:44 ----------

std_match

I think you are completely wrong in understanding the essence of this discussion and that is resulting in you stating "This is why I say you don't understand blocking/non-blocking for combinatorial logic." I write in the earlier post that I understand blocking/non-blocking for combinatorial logic as far as you want others to know. However u could not provide more knowlede on it.

I think you are in the last making useless discussion irrelavant to the topic.
 

ASIC_int:

1. How old are you?
2. How long have you been using Verilog?
3. Are you using Verilog at work, in education, or is it a hobby?

Please draw a circuit diagram to show what you want the synthesis tool to generate.
 

std_match

All these questions from 1-3 and also stating "Please draw a circuit diagram to show what you want the synthesis tool to generate. " are fully irrelavant to this thread. Request to you to go to the initial post I raised in this thread to understand what I asked there.

Thanks
 
Last edited:

ASIC_int said:
std_match

All these questions from 1-3 and also stating "Please draw a circuit diagram to show what you want the synthesis tool to generate. " are fully irrelavant to this thread. Request to you to go to the initial post I raised in this thread to understand what I asked there.

Thanks
Click to expand...

Hi ASIC_int,

Just look at post#15 of this thread and you have asked : "How many yrs of exp. do u have? Which field do u work in?"

There shouldnt be different rules for different people. I hope you understood what i meant. Be polite and gain knowledge making meaningful discussions.

Regards,
dcreddy
 

How can the synthesis tool infer the second blocking statement first and then the first blocking statement in the following code?
Click to expand...

Strictly speaking, it can't. But it will do so anyways. It is well known that the synthesis tools will do this, they even provide this as a warning.

Code: 
module code2a (o, a, b, c, d);
  output o;
  input a, b, c, d;
  reg o, temp;
  always @(a or b or c or d) begin
    o = a & b | temp;
    temp = c & d;
  end
endmodule
Leaving out a signal in the sensitivity list often _describes_ a complicated latch. for example, if a,b,c,d = 0, then c,d=1, then a,b,c,d = 1,1,0,1: o would become latched to 1, while temp is zero. at this point if ANY input changes, o will transition to 0. eg, if c changes to 1, then o would use the last value of temp. if a,b go to zero then the same happens. if d goes to 0, the same. You can also show the same by keeping a,b at zero through the above three steps. At which point the circuit would need to change when a or b go to 1 as well.

The above circuit would be impractical if the synthesis tool was able to generate it. It is far more likely that the RTL simply has a missing element in the sensitivity list that it is for the above behavior to be desired.

And again, from a simulation perspective, had temp been added to the sensitivity list, the simulator would need to re-evaluate the logic. eg, pass one causes temp to change, triggering pass two. If the statements are ordered differently, the simulator can evaluate the entire process once. temp would not need to be in the sensitivity list, and the synthesis tools would behave exactly the same as the simulator.
 

Strictly speaking, it can't. But it will do so anyways. It is well known that the synthesis tools will do this, they even provide this as a warning.
Click to expand...
I never saw a different synthesis tool warning than about temp missing in the sensitivity list. As previously discussed, the synthesis tool doesn't care for the sensitivity list, so the warning is actually adressing a potential simulation mismatch rather than a synthesis problem.

In my view, the synthesis behaviour is simple and straightforward. It produces the same result as the simulator would with a complete sensitivity list. The handling of the second assignment can be better understand as re-evaluation rather than reordering of statements in my view. Simulation wise, a second delta cycle is performed to get the final result. Because delta means no time in synthesis, it can be seen as a parallel processing as well.

I keep however my opinion, that no latch respectively logic loop can be generated in synthesis, unless a signal feedback is explicitely specified. Obviously this isn't the case here.
 

I agree with FvM. The sensitivity list is only there to help the simulator. Without it, a lot of simulation time would be wasted. This is more important for clocked processes, where you normally put only clock and reset in the sensitivity list. You are free to include more signals, but that will only slow down the simulation.

To describe complicated logic by doing tricks with incomplete sensitivity lists is an abuse and misuse of the language, IMO. Most posters in this thread accept that such tricks don't work for synthesis.
 
  • Like
Reactions: FvM

    FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
dcreddy1980 said:
Hi ASIC_int,

Just look at post#15 of this thread and you have asked : "How many yrs of exp. do u have? Which field do u work in?"

There shouldnt be different rules for different people. I hope you understood what i meant. Be polite and gain knowledge making meaningful discussions.

Regards,
dcreddy
Click to expand...

dcreaddy1980

I have asked "How many yrs of exp. do u have? Which field do u work in?" neither to you nor to std_match for whom you suddenly interferred. The reason I asked this question to a person, because to that person I asked I have currently lot of conversations with that person and so just in a friendly manner I asked this.

If I am not making any mistake nearly 3 years back I also asked this questions to you because at that time we had many long discussions with you.

Rather the question from 1-3 which are there in post no. 42 are entirely different questions from "How many yrs of exp. do u have? Which field do u work in?"

I do not disagree with you that "There shouldn't be different rules for different people". I also agree with you that to "Be polite and gain knowledge making meaningful discussions." To do meaningful discussions only I wrote that those question from 1-3 did not had any meaningful discussion and hence irrelavant to the topic of discussion of this thread which I atarted. It is very sad that you are making a mistake by calling me that I am not polite. Where did you find lack of politeness in me? Which of my comments shows I am not polite?

Suddenly you brought a post no. 44 which contradicts to your statement that we should only do meanigful discussion. For your kind information post no. 44 has nothing to do with the meaningful discussion.

However I only writes this irrelavant thread to stop this irrelavant discussion. Just think the whole matter with a cold drinks before blaming persons unnecessarily.

It does not look good that you suddenly blame persons without any proper reason. Think off!

Regards
 
Last edited:

Hi ASIC_Int,

I am assuming you expect the code runs as in C programming, so the output at end of block shall be:
o = a & b | (previous value of temp);
temp = c & d;

I am verilog newbie. Having confusion on blocking & Non-blocking as well. According to this site: Blocking And Nonblocking In Verilog
I think by using non-blocking statements instead can give you the desired result (which as i assumed as above)

Thanks.
 

Let us ask a basic question. How doe synthesis tool parse the HDL code to synthesize? Does it first write algebric equations?
 

ASIC_int said:
Let us ask a basic question. How doe synthesis tool parse the HDL code to synthesize? Does it first write algebric equations?
Click to expand...
The synthesis tool is smart. It assumes a complete (= correct) sensitivity list and calculates what the end result will be. It will then generate this "end result" with a minimum of logic. Once again, it doesn't matter what you put in the sensitivity list, the synthesis result will be the same. The sensitivity is only there as a hint to the simulator, so it can know when it should do the evaluation.
 
  • Like
Reactions: FvM

    FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
ASIC_int said:
Let us ask a basic question. How doe synthesis tool parse the HDL code to synthesize? Does it first write algebric equations?
Click to expand...
My guess would be "no", or at least "not fully". mainly because some structures might have efficient implementations that are easy to infer without writing any logic expressions on a bit-by-bit basis. ROMs/RAMs would be an example.

I'm also not sure how it is relevant. I'd suspect that the synthesis tool's documentation will have a section that explains that the sensitivity lists are handled in a specific manner.

If your question on parsing was unrelated to the previous 49 posts, this might be better as a new thread. Otherwise many will assume you are still trying to debate the issues with the sensitivity list and/or blocking assignments. The debate in which the answer isn't dictated by the strict definition of the language, but by the tool vendors. They have spoken and said that they will ignore any logical implications of incomplete sensitivity lists (and delay statements, and a few other things). no matter how much the language would seem to indicate a different behavior -- one that matched simulation -- it simply isn't what the synthesis tool will actually do.

...where you normally put only clock and reset in the sensitivity list. You are free to include more signals...[/code]
I don't think verilog allows that. after all the "clock" isn't part of the if-else structure directly. so always@(posedge clk, a) s <= a^s; would result in evaluation of the "non-reset" case any time "a" changes. (the synthesis tool would probably fail on the above code for one reason or another)
Click to expand...
 
  • Like
Reactions: FvM

    FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
"...where you normally put only clock and reset in the sensitivity list. You are free to include more signals..." I don't think verilog allows that.
Click to expand...
Yes, the comment rather applies to VHDL sensitivity lists, but doesn't consider the specialities of Verilog edge sensitive event syntax.

Mixing edge and level sensitive conditions is mentioned in examples from the Verilog specification, but I agree that it doesn't seem to describe synthesizable logic. The new IEEE 1364.1 IEEE Standard for Verilog® Register Transfer Level Synthesis has been mentioned in other related threads. The standard tries to fix a portable subset of the Verilog language to be understood by all synthesis tools. It clearly distinguishes between an always @ syntax for combinational and edge sensitive logic. It states related to the former:

Combinational logic shall be modeled using a continuous assignment or a net declaration assignment or an always statement.

When using an always statement, the event list shall not contain an edge event (posedge or negedge). The event list does not affect the synthesized netlist. However, it may be necessary to include in the event list all the variables read in the always statement to avoid mismatches between simulation and synthesized logic.
Click to expand...

Related to the said "basic question": I don't know exactly. I'm satisfied with mostly guessing the synthesis result correctly for code of practical importance, both Verilog and VHDL.
 

well i have a practical answer for differentiate blocking and non-blocking


suppose if u see a running race we have some types


relay running race and normal race


in normal race all start in a same time.

simply i define it as non-blocking statements which start executing in 0time.



considering relay running race (a group running race which a runner1 handles a flag to runner2 and it follows..........)

i define it as a blocking statement

the runner2 has to wait for the runner 1 to handover the flag it to him/her.

coming to technically blocking statements also executes same

it waits for the above statement to execute and start executing.



now we take an example and apply the race rule on it


a<=b;
b<=a;

here 2 racers running simultaniously from 2 locations a,b
and reaches 2 other locations b,a respectively(swaping of two numbers )


a=b;
b=a;

here the case is different the runner1 in location b have to handle flag to runner2 in a location
until the runner1 reaches a location runner2 has to wait then he proceed
here the final value of b is b;
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top