Verilog Inter and Intra Assignment Delay

The previous article showed how a # delay pauses a procedural block. A delay can be placed in two different positions in an assignment: on the left of the statement, before the whole assignment, or on the right of the assignment operator, before the expression. The two positions look similar, but they change when the right-hand side is evaluated, which can give a completely different result.

10 min read | Beginner Level

What You'll Learn

• The difference between inter-assignment and intra-assignment delays
• Why an intra-assignment delay can miss values updated by nonblocking assignments
• How blocking and nonblocking intra-assignment delays affect the rest of the block
• How to use intra-assignment delays to model wire delays without losing short pulses

Inter-assignment Delays

An inter-assignment delay is written on the left side of the statement. It delays the execution of the whole statement: the block waits first, and then evaluates the right-hand side and assigns the result, as if the delay were a separate statement. This is the most common way to use a delay.

// Delay is specified on the left side
#<delay> <LHS> = <RHS>

In the example below, a and c are set to 1 at T=5 with nonblocking assignments, and q is assigned 5 time units later:

module tb;
  reg  a, b, c, q;

  initial begin
    $monitor("[%0t] a=%0b b=%0b c=%0b q=%0b", $time, a, b, c, q);

    // Initialize all signals to 0 at time 0
    a <= 0;
    b <= 0;
    c <= 0;
    q <= 0;

    // Inter-assignment delay: Wait for #5 time units
    // and then assign a and c to 1. Note that 'a' and 'c'
    // gets updated at the end of current timestep
    #5  a <= 1;
        c <= 1;

    // Inter-assignment delay: Wait for #5 time units
    // and then assign 'q' with whatever value RHS gets
    // evaluated to
    #5 q <= a & b | c;

    #20;
  end

endmodule

xcelium> run
[0] a=0 b=0 c=0 q=0
[5] a=1 b=0 c=1 q=0
[10] a=1 b=0 c=1 q=1
xmsim: *W,RNQUIE: Simulation is complete.

q becomes 1 at T=10. The right-hand side is evaluated at T=10, after the delay, and by then a and c have long been updated to 1, so a & b | c gives 1 & 0 | 1 = 1.

Synthesis result: Synthesis ignores the delay, so #5 q <= a & b | c; becomes the same AND-OR logic as q <= a & b | c;. Inter-assignment delays are used in testbenches to space out stimulus.

Intra-assignment Delays

An intra-assignment delay is written on the right side of the assignment operator. The right-hand side is evaluated immediately, the result is held, and it is assigned to the left-hand side only after the delay:

// Delay is specified on the right side
<LHS> = #<delay> <RHS>

A blocking intra-assignment delay behaves like this pair of statements, with a hidden temporary variable:

q = #5 a & b | c;

// is equivalent to:
temp = a & b | c;    // Evaluate now
#5 q = temp;         // Assign later

Here is the same testbench with the delay moved to the right side of the q assignment:

module tb;
  reg  a, b, c, q;

  initial begin
    $monitor("[%0t] a=%0b b=%0b c=%0b q=%0b", $time, a, b, c, q);

    // Initialize all signals to 0 at time 0
    a <= 0;
    b <= 0;
    c <= 0;
    q <= 0;

    // Inter-assignment delay: Wait for #5 time units
    // and then assign a and c to 1. Note that 'a' and 'c'
    // gets updated at the end of current timestep
    #5  a <= 1;
        c <= 1;

    // Intra-assignment delay: First execute the statement
    // then wait for 5 time units and then assign the evaluated
    // value to q
    q <= #5 a & b | c;

    #20;
  end
endmodule

xcelium> run
[0] a=0 b=0 c=0 q=0
[5] a=1 b=0 c=1 q=0
xmsim: *W,RNQUIE: Simulation is complete.

There is no line for T=10, so q never became 1. The reason is in the order of events at T=5:

1. a <= 1 and c <= 1 are nonblocking, so their updates are scheduled for the end of the T=5 time step.
2. The block moves straight on to q <= #5 a & b | c and evaluates the right-hand side at once. At this point a and c still hold their old value 0, so the result is 0.
3. At the end of the time step, a and c become 1, which is what the [5] line shows.
4. At T=10, the saved value 0 is assigned to q. q was already 0, so nothing changes and $monitor prints nothing.

If a and c are assigned with blocking assignments instead, they are updated immediately, before the q statement evaluates its right-hand side:

  ...

  // Non-blocking changed to blocking and rest of the
  // code remains the same
  #5  a = 1;
      c = 1;

  q <= #5 a & b | c;

  ...

xcelium> run
[0] a=0 b=0 c=0 q=0
[5] a=1 b=0 c=1 q=0
[10] a=1 b=0 c=1 q=1
xmsim: *W,RNQUIE: Simulation is complete.

Now the right-hand side sees a = 1 and c = 1 at T=5, evaluates to 1, and q becomes 1 at T=10. The diagram compares the three cases:

Synthesis result: Intra-assignment delays are also ignored by synthesis. q <= #5 a & b | c; synthesizes to the same logic as q <= a & b | c;, which is why a design that depends on the timing of a delay can behave differently after synthesis.

Blocking vs Nonblocking Intra-assignment Delays

An intra-assignment delay can be used with both kinds of assignment, and they affect the rest of the block very differently:

initial begin
  q1 = #5 d;     // Blocking: the block waits here for 5 units
  x  = 1;        // Runs at T=5
end

initial begin
  q2 <= #5 d;    // Nonblocking: the update is scheduled for T=5
  y  = 1;        // Runs at T=0, without waiting
end

The last row is special: q <= #5 d evaluates d, schedules the update for later, and the block continues at once. Several such statements in a row can schedule several future updates, even of the same variable, and each one keeps its own value.

initial begin
  q <= #10 1;
  q <= #20 0;
  q <= #30 1;
end

Modeling Wire Delays

A common use of intra-assignment delays is to model the delay of a wire or a buffer in a testbench, so that a signal arrives at its destination some time after it leaves its source. The way the delay is written decides whether short pulses survive:

// Nonblocking intra-assignment delay: every change is
// scheduled 5 units later, so pulses are kept
always @(in) out1 <= #5 in;

// Delay before a blocking assignment: the block is busy
// for 5 units and misses any change that happens meanwhile
always @(in) #5 out2 = in;

Consider an input that pulses high from T=10 to T=13, and again from T=30 to T=40:

• out1 copies both pulses exactly, 5 units later. Each change of in schedules its own update, so even a pulse shorter than the delay passes through. This is called a transport delay.
• out2 misses the first pulse. The block wakes up at T=10, then waits until T=15 and copies in, which by then is 0 again. The fall at T=13 happened while the block was waiting, so nothing triggered the block for it.

Event-Based Intra-assignment Control

The control on the right side of an assignment does not have to be a delay. It can also be an event, which evaluates the right-hand side now and assigns it when the event happens:

// Sample d now, assign it to q at the next rising clock edge
q = @(posedge clk) d;

// Sample d now, assign it to q after three rising clock edges
q = repeat (3) @(posedge clk) d;

This is mostly used in testbenches and behavioral models, for example to capture a value at one moment and apply it a fixed number of clock cycles later. Like delays, these event controls are not synthesizable in this form.

Common Beginner Mistakes

a <= 1;
q <= #5 a;     // Expecting q to become 1 at T+5

module tb;
  reg [3:0] a, x, y, z;

  initial begin
    $monitor("[%0t] a=%0d x=%0d y=%0d z=%0d", $time, a, x, y, z);
    a = 1; x = 0; y = 0; z = 0;

    x <= #4 a;      // Statement 1
    #2 a = 2;
    y = #4 a;       // Statement 2
    #2 z <= a;      // Statement 3
    a = 3;
  end
endmodule

[0] a=1 x=0 y=0 z=0
[2] a=2 x=0 y=0 z=0
[4] a=2 x=1 y=0 z=0
[6] a=2 x=1 y=2 z=0
[8] a=3 x=1 y=2 z=2