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

[ASIC_int]

How can the synthesis tool infer the second blocking statement first and then the first blocking statement in the following 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

 

[std_match]

Your code describes a purely combinatorial circuit, and the synthesis result will in this case be the same regardless of the order of the 2 lines.
Manually draw the schematic corresponding to your code. You will see that there is only one way to do it.

Simulation can be confused since you forgot to put temp in the sensitivity list.
Simulation should also be correct if you switch the 2 lines.

The synthesis result will always be correct since it doesn't use the sensitivity list.

 

[lostinxlation]

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

Why not ?
By parsing the code, the tool can clearly see the intent of the code.

 

[ASIC_int]

Hi std_match

By verilog construct it is said a blocking assignment is evaluated one after another. So if the synthesis tool obeys that property of blocking statement it will execute the first bloking statement initially and then will go to the second blocking statement 'temp = c & d'.

How can the synthesis result be same because it is a combinational logic? Can you please explain more about your statement "Your code describes a purely combinatorial circuit, and the synthesis result will in this case be the same regardless of the order of the 2 lines." Can you teach me about your comment that is in quotaion now?

Regards

 

[std_match]

By verilog construct it is said a blocking assignment is evaluated one after another.

Verilog is a simulation language. The simulator will evaluate the expressions in the specified order. Synthesized hardware does everything in parallel. Again, if you try to draw the schematic of the design you will see that there is only one way to do it.

 

[ASIC_int]

But I heard that synthesis tool is capable of obeying blocking nature of 'bloking statements'. In that case it should evaluate the sequentially and not in parallel as you wrote.

Please correct me if I am wrong about my understanding of bloking statements interpretation by synthesis tools.

Even to keep sequential nature of blocking statements, if I draw schematic, the temp input should get a feedback from putput to produce the older value of temp in the first line. Is not it?

 

[std_match]

But I heard that synthesis tool is capable of obeying blocking nature of 'bloking statements'. In that case it should evaluate the sequentially and not in parallel as you wrote.

As I mentioned earlier, the design is combinatorial, so the "sequential" evaluation only applies to the simulator.

The order of the 2 lines would make a difference in a sequential design.

 

[FvM]

But I heard that synthesis tool is capable of obeying blocking nature of 'bloking statements'. In that case it should evaluate the sequentially and not in parallel as you wrote.

The synthesis tool will take the blocking nature into consideration as far it changes the synthesis result. I agree with std_match, that this isn't the case in the present example.

P.S.: Here's the RTL netlist for code2a. How should it synthesize different?

 

[ASIC_int]

Hi std_match

Can u produce a document that supports that synthesis tool evaluate blocking statements nonblocking way?

---------- Post added at 12:08 ---------- Previous post was at 12:00 ----------

FVM

What do u mean by "The synthesis tool will take the blocking nature into consideration as far it changes the synthesis result"?

 

[std_match]

Even to keep sequential nature of blocking statements, if I draw schematic, the temp input should get a feedback from putput to produce the older value of temp in the first line. Is not it?

What do you mean with "older value of temp". Remember, there is no register in the design. Without a register there is only one value for temp, the current value (c & d).

 

[ASIC_int]

What I mean is that: The simulation will take the older value of temp because it happens in the line 1 and the temp is assigned in the second line and the assignments here has bloking assignments.

Clear?

 

[FvM]

I tried to make an example, that shows the difference between blocking and non-blocking assignments in a combinational always block. Please don't ask if it would be used in a resonable design. But you can see, how the blocking nature will be obeyed by the synthesis tool.

always @(a or b or c or d or temp) begin
temp = a & b;
o = temp | c & d;
temp = a & !b;
end

always @(a or b or c or d or temp) begin
temp <= a & b;
o <= temp | c & d;
temp <= a & !b;
end

 

[ASIC_int]

Fvm

how is the last blocking statement being ignored in the first example and how is the first nonbloking statement is being ignored in second example?

 

[FvM]

The synthesis result is matching the behavrioral description. In the non-blocking case, the assignment to temp is updated after the always block is finished, thus the last assignment gets effective. In the blocking case, temp is updated immediately, so the first assignment is valid.

I'm not quite sure, but I assume that multiple assignments to the same variable, as in this example, are the only case where blocking behaviour respectively statement order matters in combinational code.

 

[ASIC_int]

FVM

In case of nonblocking multiple assignments the last one is assigned. But you also claim that for multiple blocking assignments the first one is assigned. How do you know this that for multiple blocking assignments the first one is assigned? Do the IEEE Spec say so?

It is not still clear to me what you mean by "The synthesis tool will take the blocking nature into consideration as far it changes the synthesis result"? How does the above example support you statement that I put in quotaion in the previous sentence.

However my example which is there in my first thread does not show any multiple blocking assignement. I am not still getting how in my example in my first thread the blocking assignments are not evaluated sequentially by synthesis tool.
How many yrs of exp. do u have? Which field do u work in?

Regards

 

[FvM]

The synthesis tool will take the blocking nature into consideration as far it changes the synthesis result

Strictly spoken, it's a tautology. It says, that in some cases the synthesis result will be different between blocking and non-blocking assignments. My example shows, that this happens with a real synthesis tool (Altera Quartus). I claim, that this result is according to the Verilog language rules and will be also observed in simulation.

The fact, that the first assignment "wins" in the blocking case simply shows the sequential evaluation of statements. Because it's blocking, the left-hand-side will be updated immediately and used in the next line. The second assignment to temp is simply ignored.

In the non-blocking case, the statements are also evaluated sequentially, but without updating the LHS. The first assigment is ignored, because it's overwritten by the second one. temp is updated after finishing the delta cycle. The temp result will be used in the next delta cycle to produce the final output value.

You'll notice, that I speak in simulation terms to describe the design's behaviour. But that's how Verilog works. In simulation, the two delta cycles are actualy calculated sequentially. But in synthesized (combinational) hardware, they work in parallel.

So far my understanding of the problem. But regardless of whether my explanation is comprehensible or not, you should be able to retrieve the said evaluation rules in the Verilog language specification.

I'm working in different fields of electronic and system design and started FPGA design about 10 years ago.

I am not still getting how in my example in my first thread the blocking assignments are not evaluated sequentially by synthesis tool.

They are evaluated sequentially, but the result is the same. As I already asked, which different result do you expect?

 

[ASIC_int]

FVM

"They are evaluated sequentially, but the result is the same. As I already asked, which different result do you expect?"

Even to keep sequential nature of blocking statements, if I draw schematic, the temp input should get a feedback from putput to produce the older value of temp in the first line. Is not it? This is the different circuit I expect due to sequential nature of bloking statements.

Yoou wrote "The fact, that the first assignment "wins" in the blocking case simply shows the sequential evaluation of statements. Because it's blocking, the left-hand-side will be updated immediately and used in the next line. The second assignment to temp is simply ignored."

Why cannot the second assignment win? The second assignment if it wins then it shows the blocking nature of assignments.

 

[FvM]

In some cases, combinational logic defines feedback, which is synthesized as latch. But none of the said examples contains a feedback. Check with your example:

o = a & b | temp;
temp = c & d;

a,b or temp don't depend on o => no feedback
c or d don't deend on temp => no feedback either

Why cannot the second assignment win?

The second assignment comes to nothing. It's result isn't used in a succeeding term, because there's none. Of course, if you delete the first assignment, than the result of the second is remembered and used in the next delta cycle.

 

[ASIC_int]

For my code, I take it in this way:

Since temp is updated in the second line, when the always block is entered the first line o = a & b | temp will be evaluated first. Now when this first line is evaluated it will evaluate the previous vale of temp as bothe statements inside the always block are bloking. After evaluation of first bloking assignment the second assignment will be evaluated. So the synthesized net list should be such that it will be able to bring out the previous value of temp at the output 'o'. This is the way the simulator will work. So the synthesis tool since it pbeys bloking nature of verilog, it will also be able to match the simulation result. Hope it clears to you.


You wrote "The second assignment comes to nothing." I wanted to say the second assgnment will also come at the last and should also win as verilog IEEE standard does not disallow of non execution or non winning of second assignment. According to verilog standard blocking statements will be evaluated one after another and so when the second assignment come at the last in the evaluation cycle, it should win.

Regards

 

[std_match]

After evaluation of first bloking assignment the second assignment will be evaluated. So the synthesized net list should be such that it will be able to bring out the previous value of temp at the output 'o'. This is the way the simulator will work. So the synthesis tool since it pbeys bloking nature of verilog, it will also be able to match the simulation result.

The synthesis is correct. As I mentioned earlier, if you get a mismatch with simulation, it it probably because you forgot to put temp in the sensitivity list.

Both lines synthesize to gates. The output from the second line is used as an input to the first line. Since there is no storage element in the design, the output from the second line will immediately affect the output from the first line.