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

[ASIC_int]

STD_MATCH

As you can see, I have not put temp in the sensitivity list as there is no temp in the sensitivity list in original example. So there will be simulation and synthesis mismatch. My question is why is the synthesis tool not produce a netlist that can match the simulation result?
The example was taken from this page number4 of the attached document
Regards

 

[FvM]

I agree with std_match, that omitting temp from the sensitivity list is the point, that can bring up simulation to synthesis mismatch. Unfortunately, the quoted paper is unclear in this point, because it doesn't tell which simulation result the author expects. The author however has no doubts about the synthesis result, he knows well, that the statement order doesn't change it.

I wonder, if the author possibly misinterpreted the expectable simulation result? Although chapter title is "Complete sensitivity list", it quotes a warning about an incomplete sensitivity list (missing "temp", see page 5).

 

[gurucharapathy]

Blocking and Non-blocking difference is specific to simulation, it does not affect synthesis. The definition of blocking, non-blocking involves simulation delta cycles which are not relevant to synthesis. So the designer has to take this into account and ensure that the design is modeled correctly for simulation.

 

[permute]

I think the hidden remark is that "temp" is intended to be left out of the sensitivity list. it is an intermediate signal that does not need to trigger any always blocks. If this is done everywhere, the simulation time might be improved. Assuming no optimizations are otherwise done by the simulator. If temp is added, then the block updates temp and then is immediately re-evaluated. This second evaluation isn't needed if the statements are ordered differently and temp is omitted from the sensitivity list.

Keep in mind that modern simulators (eg, ones made since 1999) might perform enough optimizations to realize that the statements can be safely re-ordered (temp would still need to be added to the sensitivity list).

as for why this is a warning and not an error, I'm not sure.

 

[FvM]

Blocking and Non-blocking difference is specific to simulation, it does not affect synthesis.

Post #12 has an example where it affects synthesis. Generally, blocking statements are required for intermediate results that need to be calculated immediately. They are often used in complex HDL designs and it's important to get consistent simulation results for it.

 

[ASIC_int]

FVM

IEEE Spec for verilog write that verilog is for simulation. So bloking & nonbloking natures are obeyed in simulation. But how do we claim that bloking & nonbloking natures are obeyed in synthesis also? I agree that your exmple shows a diference when you did the experiment with one of the synthesis tools may be Design Compiler. But only a single example is not sufficient enough to claim "bloking & nonbloking natures are obeyed in synthesis also". So how do you claim "bloking & nonbloking natures are obeyed in synthesis also"? Do you have ant document to support this claim as to support that bloking & nonbloking natures are obeyed in simulation there is the IEEE spec file.


However you wrote "Unfortunately, the quoted paper is unclear in this point, because it doesn't tell which simulation result the author expects."

But we can very clearly conclude from this paper about the simulation results for the given code because it does not have complexity.
Regards

 

[std_match]

You must accept that in this case, the simulation is wrong and the synthesis is correct.

Why is the simulation wrong? - Because "temp" is missing in the sensitivity list. A correct simulation depends on a correct sensitivity list. If the evaluation isn't executed when it should, the simulation will be wrong.

Why is the synthesis correct? - Because the sensitivity list isn't used by the synthesis tools. The hardware evaluates everything in parallel, so it doesn't need a hint from the sensitivity list about when to evaluate.

 

[ASIC_int]

std_match

We are not saying simulation is wrong rather we are saying there will be mismatch between simu and synth in this case because temp is not there in sensitivity list.

Why is the synthesis correct? - Because the sensitivity list isn't used by the synthesis tools. The hardware evaluates everything in parallel, so it doesn't need a hint from the sensitivity list about when to evaluate.

Can you please explain more if you have knowledge of what synthesis tool do on blocking and nonblocking assignments? What do you mean by "The hardware evaluates everything in parallel"? A synthesis tool should obey blocking and nonblocking assignments nature of verilog. So for a nonblocking assignment the synthesis tool should evaluate the assignments sequentially and not in parallel as you claimed. Is not it? To get clarity on this we are continuing the discussion on this thread.

Regards

 

[std_match]

A synthesis tool should obey blocking and nonblocking assignments nature of verilog.

The problem is that you don't understand blocking and non-blocking for combinatorial logic. The synthesis tool is correct.

 

[FvM]

IEEE Spec for verilog write that verilog is for simulation. So bloking & nonbloking natures are obeyed in simulation. But how do we claim that bloking & nonbloking natures are obeyed in synthesis also?

I think that the below statement from the IEEE specification, that I quoted in one of your previous threads, gives a clearer image. It doesn't just say "Verilog is for simulation". It says, that the syntax is based on it. It's however only the introducting statement to adetailed discussion of event simulation. If you have doubts about what the Sverilog syntax involves for synthesis, you should refer to the details as well.

Although the Verilog HDL is used for more than simulation, the semantics of the language are defined for simulation, and everything else is abstracted from this base definition.

See: https://www.edaboard.com/threads/211977/#post898959

In my opinion, simulation that can't achieve consistency with hardware synthesis is effectively worthless. If you get simulation to synthesis mismatch in some cases, it's a consequence of bad considered simulation models rather than a language feature.

But we can very clearly conclude from this paper about the simulation results for the given code because it does not have complexity.

As far as I understand, your conclusion has been yet different from observed synthesis behaviour. And I don't see a conclusion of the author.

 

[ASIC_int]

std_match

The problem is that you don't understand blocking and non-blocking for combinatorial logic. The synthesis tool is correct.

Can u please provide me an idea about blocking and nonblocking for combinatorial logic since you think that I do not know this. Can you please provide any document on this? Or, can you please explain me?

 

[ASIC_int]

FVM

"Although the Verilog HDL is used for more than simulation, the semantics of the language are defined for simulation, and everything else is abstracted from this base definition."


What is "everything else " in the above quotaion. IEEE spec does not clearly say so? What abstraction does the above quotaion mean when it says "everything else is abstracted from this base definition" ?

I agree with you with your statement "In my opinion, simulation that can't achieve consistency with hardware synthesis is effectively worthless. If you get simulation to synthesis mismatch in some cases, it's a consequence of bad considered simulation models rather than a language feature."

I did not try to oppose with this in any of the earlier posts. Probably things are not being understood in proper way. However this was not my intention of continuing with this thread. Please answer this "What is "everything else " in the above quotaion. IEEE spec does not clearly say so? What abstraction does the above quotaion mean when it says "everything else is abstracted from this base definition" ? This is more towards my intention to continue and initiate this topic.

 

[FvM]

What is "everything else " in the above quotaion. IEEE spec does not clearly say so? What abstraction does the above quotaion mean when it says "everything else is abstracted from this base definition" ?

Related to this discussion, "everything else" means particularly RTL synthesis. "Abstracted from the base definition" means, that syntax elements, that can be applied for "elsewhere" Verilog usage are applied.

Application of Verilog to synthesis is mainly a simplification. Many properties, that exist in simulation are discarded, ignored or replaced by equivalent logic, e.g. 'X' state, internal 'Z' state, timing statements, sensitivity lists. In my opinion, we shouldn't read too much into "abstraction from the base definition".

 

[std_match]

Can u please provide me an idea about blocking and nonblocking for combinatorial logic since you think that I do not know this. Can you please provide any document on this? Or, can you please explain me?

The information is available in this thread. Your problem boils down to that you think there is a "previous value" that can be used as an input to a gate. How can you keep the "previous value" stable without a storage element?

The "previous value" exists for a short moment in the simulation, until the simulator (with a correct sensitivity list) realizes that it must do the evaluation again. This happens in "zero time" and the end result is the same as for the synthesized logic.

You MUST provide a correct sensitivity list to the simulator.

 

[ASIC_int]

std_match

The information that is available in this thread provided by FVM is well understood and known. The reason I asked you to provide us some more knowledge about blocking and nonblocking for combinatorial logic if you are aware and so you wrote "The problem is that you don't understand blocking and non-blocking for combinatorial logic. The synthesis tool is correct."


The attached paper wants to show simulation and synthesis mismatch. So the author picked up an example.

You are right to state that with temp, not in the sensitivity list, the synthesis tool may need to realize with flipflops/latches. But why does not the synthesis tool do that.? That is the question in this thread.

 

[std_match]

You are right to state that with temp, not in the sensitivity list, the synthesis tool may need to realize with flipflops/latches. But why does not the synthesis tool do that.? That is the question in this thread.

It is already mentioned in this thread that the synthesis tool doesn't use the sensitivity list. This means that you can't change the design by changing the sensitivity list. Only the simulation result will change. You will only get a correct simulation result with a complete sensitivity list.

 

[FvM]

You are right to state that with temp, not in the sensitivity list, the synthesis tool may need to realize with flipflops/latches. But why does not the synthesis tool do that.? That is the question in this thread.

I already explained in post #18, why I don't see a feedback and thus no option for the synthesis tool to infer a latch. A FF can't be generated without an edge sensitive event anyway.

 

[ASIC_int]

std_match


It is known and well understood and you are correct that it has been discussed in this thread that "synthesis tool doesn't use the sensitivity list".

We are here discussing about how synthesis tool interpretes the blocking statements so that it does not take care of the bloking nature of verilog.

 

[FvM]

so that it does not take care of the bloking nature of verilog

I fear, I'm getting tired of contradicting this assumption. Synthesis does take care of. This way, synthesis results are consistent with simulation.

 

[std_match]

We are here discussing about how synthesis tool interpretes the blocking statements so that it does not take care of the bloking nature of verilog.

This is why I say you don't understand blocking/non-blocking for combinatorial logic. If you have a source file describing purely combinatorial logic with no feedback path, why do you think a latch/flip-flop is necessary to implement it?

You get different simulation results when you change the sensitivity list. Which one do you think is correct? With or without "temp" in the sensitivity list?
We already agree that it doesn't matter for the synthesis.