blocking statement in combinational always during synthesis

[fragnen]

Does the synthesis tool synthesize always combinational blocks obeying the blocking nature of blocking statement? By obeying the blocking nature of blocking statement here refers to the presence of multiple blocking statements one after another inside the combinational always block, and execution of each blocking statements one after the another while synthesizing the logic. It is known that simulation tool will obey the blocking nature of blocking statement. Does the synthesis tool obey that?

 

[dave_59]

The blocking nature of a blocking assignment refers to a functionality that synthesis tools do no pay attention to, and have little purpose when compared to the functionality of non-blocking assignments.

If you use an intra-assignment delay, like A = #10 B; that statement evaluates RHS variable B, the blocks the combinational always process for 10 time units, then assigns the value to the LHS variable A and proceeds to the next statement. But the key point about a blocking assignment is the LHS variable gets its value before proceeding to the next statement. That means the order you put your blocking assignments in is very important. You need to make sure assignments to the LHS variable happen before you can read the same variable on the RHS in the same always process. Otherwise you are not describing combinational logic.

 

[FvM]

Does the synthesis tool synthesize always combinational blocks obeying the blocking nature of blocking statement?

Yes, as far as as we are talking about synthesizable code. Variables assigned by blocking statements represent unregistered combinational logic, respectively each blocking assignment result used in succeeding expressions increases combinational delay and reduces fmax.

 

[fragnen]

The blocking nature of a blocking assignment refers to a functionality that synthesis tools do no pay attention to, and have little purpose when compared to the functionality of non-blocking assignments.

Just to understand this better. Below is the copied Verilog code from anther post in this forum as below. The following code synthesizes as a 3 input AND gate with a,b,c as three inputs of the AND gate and y as the output of the AND gate. The reason synthesis tool synthesizes the below code as a 3 input AND gate because the synthesis tool obeys the blocking nature of blocking statement and hence only it synthesizes the below code as 3 input AND gate. In this way we can think of separate several Verilog rtls with each of such Verilog rtl using several blocking statements inside an always block and the question remain whether the synthesis tool will obey the blocking nature of blocking statements or not for all such scenarios as it is found that a simulator will obey blocking nature of blocking statements in all such scenarios.

input wire a, b, c;
output reg y;

always @(*)
begin
y = a;
y = y & b;
y = y & c;
end

 

[FvM]

It's potentially misleading that dave_59 refers to a non-synthesizable Verilog feature, the timing statement.

You'll find that any synthesis tool will "obey the blocking nature" by using the LHS of the preceeding assignments when evaluating the RHS. Respectively your example

y = a;
y = y & b;
y = y & c;

will be translated this way:

y = a & b & c;

What's unclear about it?

 

[fragnen]

You'll find that any synthesis tool will "obey the blocking nature" by using the LHS of the preceding assignments when evaluating the RHS. Respectively your example

y = a;
y = y & b;
y = y & c;

will be translated this way:

y = a & b & c;

What's unclear about it?

Do you want to mean that a synthesis tool will obey the blocking nature of blocking statements in any rtl where several blocking statements are coded one after another in a combinational always block as we see one such example in the above code?

 

[FvM]

Yes. I didn't yet experience synthesis tools failure in this regard.