What is the difference between begin end and fork join with respect to non-blocking statements?

Question

We know that the difference between blocking statements and non-blocking statements is: blocking statements executes sequentially (execution of next statement is blocked until present one completes) and are used to perform in combinational circuits.

Example:

always@(*) begin

c = A & B;

D = C/A;

end

Here all the statements executes sequentially (blocking statement)

Whereas non-blocking statements execute parallelly (execution of next statement is not blocked) and are used to perform in sequential circuits.

Example: Take an example of shift register

always@posedge(clk) begin

A<=B;

B<=C;

C<=D;

end

Here all the statements executes parallely because it is non-blocking and we have used posedge clk

Now if you see the difference between begin end and fork join, the difference is: in begin end, statements are executed in the order they are listed (i.e. sequentially), whereas in fork join, statements are executed parallelly.

My question here is, in the above example of non-blocking statement, we have used begin end but the statements are been executed parallelly not sequentially, but if you see in the difference between begin end and fork join it says begin end executes the statements one after another.

Could someone explain with a clear answer to this?

Read about the difference between synthesizable and non-synthesizable code. If you intend to ever actually build something, write synthesizable code. — TomServo, Sep 24 '20 at 21:47

score 0 · Answer 1 · answered Sep 23 '20 at 10:35

in the above example of non-blocking statement, we have used begin end but the statements are been executed parallelly not sequentially

That is not true. In the above example of non-blocking statement, we have used begin-end and the statements are executed sequentially. However, in spite of that, the order of execution doesn't matter. A subtle but important distinction.

When a line of code containing a non-blocking assignment is executed, it is executed immediately, but the left-hand-side of the assignment (the target) does not get its new value immediately. So, any other statements in the same begin-end block that read a variable assigned to using a non-blocking assignment will use the old value of that variable. As a consequence, the order of statements using non-blocking assignments inside begin-end blocks often does not matter. That is the case with your example.

So, when does the left-hand-side of a non-blocking assignment get updated?

System-Verilog has 9 so-called scheduler regions:

from prev time step
        |
     PREPONED
        |
      ACTIVE
        |
     INACTIVE
        |
       NBA
        |
     OBSERVED
        |
    RE-ACTIVE
        |
   RE-INACTIVE
        |
      RE-NBA
        |
    POSTPONED
        |
        V  to next time step

and Verilog has 4:

from prev time step
        |
      ACTIVE
        |
     INACTIVE
        |
       NBA
        |
    POSTPONED
        |
        V  to next time step

Think of this like a flow chart that gets executed at every timestep. (A timestep is a particular simulation time - 12345ns or whatever.) The lines of code in your begin-end block get executed in the ACTIVE region (ie early), however, the left-hand-side of your non-blocking assignments doen't get updated until the NBA region, ie later.

This is a very useful correction to an error in the assumptions stated in the question. However, it doesn't actually address the question. This answer was marked down (perhaps because of that) I marked it back up to zero as correcting the assumptions is useful. — Mac, Sep 29 '20 at 17:59

Serge · Answer 2 · 2020-09-25T01:47:42.403

your description of non-blocking assignments is not correct. All statements inside procedural blocks (always, initial, final) are always executed sequentially, including statements with non-blocking assignments. Multiple statements are enclosed within begin/end pairs.

The difference between blocking and non-blocking assignments is when the value gets assigned to a left hand side variable. Non-blocking assignment cause delayed assignment. It is done sequentially as well but in the delayed scheduling region. This is a simulation artifact.

The fork/join pair causes all statements inside to be executed in parallel. They belong to test-bench and are not synthesizable. Usually they are used to run multiple test-bench tasks in parallel in simulation.

score -1 · Answer 3 · answered Sep 29 '20 at 18:27

Serge is correct. You can think of the fork .. join as splitting each expression into its own action block. So if you recoded your eample:

always@posedge(clk) begin
   A<=B;
   B<=C;
   C<=D;
end

as

always@posedge(clk) fork
   A<=B;
   B<=C;
   C<=D;
join

A simulator would interpret the above as if it had been written as:

always@posedge(clk) A<=B;
always@posedge(clk) B<=C;
always@posedge(clk) C<=D;

Which in this case would happen to behave exactly as if it were in the begin .. end pair.

As others have noted, a synthesis tool would typically reject the fork .. join construct, as while you are not using them here, the fork join provides additional features that are designed for efficient test bench coding. As an example, code execution stops at the join until each of the the forked blocks has completed execution.

What is the difference between begin end and fork join with respect to non-blocking statements?

3 Answers3