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.Blocking and Non-blocking difference is specific to simulation, it does not affect synthesis.
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.
The problem is that you don't understand blocking and non-blocking for combinatorial logic. The synthesis tool is correct.A synthesis tool should obey blocking and nonblocking assignments nature of verilog.
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.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?
See: https://www.edaboard.com/threads/211977/#post898959Although 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.
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.But we can very clearly conclude from this paper about the simulation results for the given code because it does not have complexity.
The problem is that you don't understand blocking and non-blocking for combinatorial logic. The synthesis tool is correct.
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.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" ?
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?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?
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.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 fear, I'm getting tired of contradicting this assumption. Synthesis does take care of. This way, synthesis results are consistent with simulation.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?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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?