# Question regarding the generate block

**URL:** <https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592>\
**Category:** SystemVerilog\
**Tags:** SystemVerilog\
**Created:** [March 30, 2026, 8:48am UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592 "2026-03-30T08:48:19Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![doggkin](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/d/7993a0/32.png) [@doggkin](https://verificationacademy.com/forums/u/doggkin)\
**Post date:** [March 30, 2026, 8:48am UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/1 "2026-03-30T08:48:19Z")

</div>

Hi All,

```verilog
module tb;
  generate
    genvar i;
    for(i=0; i<10; i=i+1) begin
      initial begin 
        #1ns;
        haha(i);
      end
    end
  endgenerate

  task haha(int i);
      // #10ns;
      $display("haha_%0d", i);
  endtask
endmodule

```

Regarding the code snippet above, when I don’t use #10ns in the task, the final output is haha0…haha9; but after using #10ns, it changes to haha9…haha9.  
Could you please explain the reason for this in detail?

BR

---

<div class="post-metadata">

**Author:** ![mr.verification.0](https://verificationacademy.com/forums/user_avatar/verificationacademy.com/mr.verification.0/32/1441_2.png) [@mr.verification.0](https://verificationacademy.com/forums/u/mr.verification.0)\
**Post date:** [March 30, 2026, 11:10am UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/2 "2026-03-30T11:10:10Z")

</div>

the unexpected behavior is caused by task lifetime. Tasks are static unless declared as automatic, which means all task calls share the same storage for their local variables.

multiple initial blocks are generated using a for loop, and each one calls the same task “haha(i)” after a small delay.

The reason is that the task haha is static, and therefore its argument “i” is also stored in a shared memory location. When the simulation reaches time 1ns, all initial blocks call the task almost at the same time. Each call assigns a new value to the same shared variable i"”.

each invocation is suspended before it reaches the $display statement. During this waiting period, other task calls continue to execute and overwrite the same i variable. By the time the delay finishes at 11ns, the value of i has already been overwritten multiple times, and the last assigned value 9 remains. all task instances print the same value.

my recommendation: if you expect a sequential print and want to use #10ns, your task define with the ‘ **automatic** ‘ so that the i variable allocates a different memory location in each call, returning the relevant task based on the current variable value.

You can follow about topic and answer: [SystemVerilog Tasks - Verification Guide](https://verificationguide.com/systemverilog/systemverilog-tasks/)

---

<div class="post-metadata">

**Author:** ![doggkin](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/d/7993a0/32.png) [@doggkin](https://verificationacademy.com/forums/u/doggkin)\
**Post date:** [March 30, 2026, 11:26am UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/3 "2026-03-30T11:26:49Z")

</div>

Thanks for your reply.  
I understand the concept of a static lifetime that you mentioned, but if I remove the delay from the task, the final output doesn’t behave like a static lifetime — it prints haha\_0…haha\_9. Why is that?

---

<div class="post-metadata">

**Author:** ![doggkin](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/d/7993a0/32.png) [@doggkin](https://verificationacademy.com/forums/u/doggkin)\
**Post date:** [March 30, 2026, 2:04pm UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/4 "2026-03-30T14:04:25Z")

</div>

After giving it some thought, I think I might know the reason.

This has nothing to do with the delay in the `initial` block; let’s remove the delay from it.

`generate` creates 10 `initial` blocks, and the corresponding `genvar i` in each `initial` block ranges from 0 to 9.

When there is no delay in the `task`, at 0 ns, because 10 `initial` blocks are called simultaneously, they all call the `task` and pass `genvar i` to the formal parameter `i`, since `i` is a static variable, a race condition is triggered. It’s possible that the output is printed immediately after `i` is assigned 0; it’s also possible that it’s printed immediately after `i` is assigned 0, 1, 9 in sequence. In short, multiple print results may occur.

When there is a 10ns delay in the task, a race condition for the formal parameter `i` is similarly triggered at 0 ns. However, after 0 ns has elapsed, the outcome of the race condition for `i` has already been determined—it could be any number from 0 to 9. Since the display statement occurs at 10 ns, the value printed will always be the same (from 0 to 9).

I’m not sure if I’ve understood this correctly, so I hope @dave_59 can clarify it for us.

---

<div class="post-metadata">

**Author:** ![dave\_59](https://verificationacademy.com/forums/user_avatar/verificationacademy.com/dave_59/32/4499_2.png) [@dave\_59](https://verificationacademy.com/forums/u/dave_59)\
**Post date:** [March 30, 2026, 5:42pm UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/5 "2026-03-30T17:42:25Z")

</div>

You’re correct. It’s worth noting that different tools and even different versions of the same tool may select different execution orderings for the `initial` blocks. However, the same tool will consistently use the same ordering. Consequently, the race condition becomes exceedingly difficult to detect.

---

<div class="post-metadata">

**Author:** ![mr.verification.0](https://verificationacademy.com/forums/user_avatar/verificationacademy.com/mr.verification.0/32/1441_2.png) [@mr.verification.0](https://verificationacademy.com/forums/u/mr.verification.0)\
**Post date:** [March 30, 2026, 6:33pm UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/6 "2026-03-30T18:33:49Z")

</div>

You said: “the outcome of the race condition for i has already been determined–it could be any number from 0 to 9.”

Theoretically true, but in practice this value is almost always 9 — and not by chance. It’s actually a deterministic outcome.

Here’s why: the simulator schedules all 10 initial blocks at T=0 on a single thread, in elaboration order. So haha(0) is called and i=0 is written, then immediately haha(1) is called and i=1 overwrites it, and so on until haha(9) writes i=9. At that point all blocks have entered their #10ns wait, and nothing touches i during that time. When they all wake up at T=10ns, they read deterministically 9. It’s not a random race condition outcome — it’s the last writer winning in a predictable order.

You touched on this but didn’t fully explain it. The reason it works correctly without a delay isn’t luck — it’s this: even with a static task, when there’s no delay, the assignment to i and the $display happen “within the same delta cycle”, uninterrupted.

Nothing can slip in between the assignment and the display call. The moment you add a delay, a 10ns window opens between those two operations, and every other call overwrites i during that window.

> So your core diagnosis, static task, shared i, race condition is spot on. The only thing worth refining is that “any number from 0 to 9” almost always manifests as 9 in practice, and the reason the no-delay case works correctly is slightly different from what you described.

---

<div class="post-metadata">

**Author:** ![dave\_59](https://verificationacademy.com/forums/user_avatar/verificationacademy.com/dave_59/32/4499_2.png) [@dave\_59](https://verificationacademy.com/forums/u/dave_59)\
**Post date:** [March 30, 2026, 7:38pm UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/7 "2026-03-30T19:38:27Z")

</div>

Technically, this is not correct. There’s no assurance that the order of elaboration leads to the order of execution. In fact, some implementations have opted for the reverse order in some cases. As more people experiment with multicore execution, it might seem like other statements in one process are inserted between the statements of another process.

---

<div class="post-metadata">

**Author:** ![doggkin](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/d/7993a0/32.png) [@doggkin](https://verificationacademy.com/forums/u/doggkin)\
**Post date:** [March 31, 2026, 1:34am UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/8 "2026-03-31T01:34:07Z")

</div>

There are two key points here:

1. Regarding the execution order of `initial` blocks: There is no doubt that the order in which parallel `initial` blocks enter the Active Region is indeterminate.

2. Regarding the execution order of statements within an `initial` block: As Dave pointed out, there is no guarantee that once an `initial` block begins execution, the statements within it will execute atomically until they are blocked.

We may have observed seemingly consistent results no matter how many times we run the simulation, but this might simply be because our simulators use the same strategy for handling race conditions. However, as Dave noted, different simulators may produce different results.

---

<div class="post-metadata">

**Author:** ![doggkin](https://verificationacademy.com/forums/letter_avatar_proxy/v4/letter/d/7993a0/32.png) [@doggkin](https://verificationacademy.com/forums/u/doggkin)\
**Post date:** [March 31, 2026, 1:35am UTC](https://verificationacademy.com/forums/t/question-regarding-the-generate-block/51592/9 "2026-03-31T01:35:27Z")

</div>

Thanks Dave.