fork-join_none

Module 14 · Page 14.3

fork-join_none spawns threads and immediately returns — the parent does not wait at all. Every spawned thread runs entirely in the background. This is the right tool for launching continuous monitors, clock generators, coverage samplers, and N-channel stimulus loops where N is determined at runtime. The critical rule juniors miss: $finish kills background threads instantly — if you need them to complete their last work, use wait fork first.

1. Engineering Problem — Why fork-join_none Exists

Every real testbench has three classes of work that must run concurrently:

• Persistent infrastructure — a clock generator that toggles forever, a protocol monitor that captures every transaction, a coverage sampler that fires every cycle. These threads have no termination; they live for the entire simulation.
• Variable-count parallel stimulus — "drive N channels concurrently" where N comes from the test's config object, the regression seed, or a runtime calculation. fork-join cannot express "N parallel threads where N is a variable" because the threads must be listed literally.
• Fire-and-continue spawning — start a long task and let the parent immediately move to the next step; pick up the spawned task's result later via an event or wait fork.

fork-join (the previous-previous lesson) cannot do any of these because it blocks until every thread completes. fork-join_any (the previous lesson) blocks until one completes. fork-join_none is the IEEE 1800 answer to "spawn threads and immediately continue, don't block on anything."

2. Mental Model — Fire-and-Continue

The picture every engineer carries:

fork-join_none is a daemon spawner. Every thread inside it goes to a background process pool. The parent thread crosses the join_none bar in zero simulation time — no waiting, no checking, no synchronisation. The threads run independently of the parent from the instant of spawning.

Three invariants this picture preserves:

• Zero blocking. The parent advances to the statement after join_none in the same time slot, before any spawned thread has executed even one statement. This is the defining behaviour — and the source of the "I forgot the spawn hasn't happened yet" bug.
• Background threads outlive their spawn site. A fork-join_none inside a task: spawned threads keep running after the task returns. A fork-join_none inside a class method: threads outlive the method call (and need careful object-lifetime management — §7).
• $finish is a guillotine. Every background thread is killed the instant $finish runs, with no chance to drain. If a monitor is mid-check, the check is abandoned. The fix is wait fork before $finish, or an explicit drain window.

3. Visual Explanation — The join_none Bar

The figure captures the canonical daemon-spawn pattern: a clock generator, a protocol monitor, and a finite per-channel driver — all spawned together and the parent immediately moves on. The JOIN_NONE variant is the default-shape sibling of join and join_any precisely because of this "spawn then continue" behaviour.

4. Syntax & Semantics — fork, join_none, wait fork

4.1 The basic form

// ── Syntax ────────────────────────────────────────────────────
fork
    thread_1;
    thread_2;
    thread_3;
join_none
// parent resumes HERE immediately — before any thread has run
next_statement;   // executes right away
 
// ── Concrete demonstration of the immediate-return behaviour ──
$display("[MAIN] Before fork at t=%0t", $time);
 
fork
    begin #20; $display("[A] done at t=%0t", $time); end
    begin #10; $display("[B] done at t=%0t", $time); end
join_none
 
$display("[MAIN] After fork-join_none at t=%0t — threads not done yet!", $time);
#30;
$display("[MAIN] t=%0t — both threads have completed in background", $time);
 
// Output:
//   [MAIN] Before fork at t=0
//   [MAIN] After fork-join_none at t=0  ← parent continues INSTANTLY at t=0
//   [B] done at t=10                    ← background thread completes
//   [A] done at t=20                    ← background thread completes
//   [MAIN] t=30

4.2 The three join variants — final side-by-side

4.3 wait fork — the complement to join_none

wait fork blocks the calling process until every thread spawned in the current scope has completed. It's the only way to "wait for N background threads where N was determined at runtime."

initial begin
    // Spawn 5 background threads
    for (int i = 0; i < 5; i++) begin
        automatic int idx = i;
        fork
            begin
                repeat (idx + 1) @(posedge clk);
                $display("Thread %0d done at %0t", idx, $time);
            end
        join_none
    end
 
    $display("[MAIN] All 5 threads spawned, now waiting...");
 
    wait fork;   // blocks here until ALL 5 threads have completed
 
    $display("[MAIN] All threads done at %0t", $time);
    $finish;
end
 
// ── wait fork with a timeout (combine with fork-join_any) ─────
fork
    wait fork;                       // wait for all background threads
    #1_000_000 $fatal(1, "timeout"); // give up after 1M time units
join_any
disable fork;

Critical scoping rule: wait fork waits for threads spawned in the calling process's scope — not globally. Inside a task, it waits only for threads spawned by that task call, not for threads spawned by the caller.

5. Simulation View — When the Parent Continues, Where the Spawns Go

At the fork keyword, the simulator:

1. Spawns every statement inside the block as a separate process, sharing the parent's local variables (subject to the loop-capture bug — §8.1).
2. Schedules all spawned threads at the current simulation time in the Active region.
3. Does not suspend the parent at join_none — the parent continues to the next statement in the same Active region, before any spawned thread has executed even one statement.
4. The spawned threads run only when the simulator's normal scheduling reaches them — typically after the parent advances or yields.

The "spawn order vs execution order" subtlety matters: if the parent's next statement is $display, the spawned threads have not yet executed their bodies when the display runs. The threads are scheduled but not started.

wait fork blocks the calling process in the Active region of the time slot where the call is made. The process resumes only when every previously-spawned background thread in the same scope has completed (including ones spawned via nested forks). disable fork from the calling process kills every still-running background thread spawned by that process.

6. Waveform — Parent Continues at t=0, Threads Resolve Later

The waveform below shows the §4.1 example. The parent forks 3 threads at cycle 0 and immediately moves on in the same time slot — there is no parent-blocked window at all. The threads resolve at cycles 2, 4, 6 entirely in the background while the parent is already executing post-fork work.

The parent row is RUN for every cycle — there is no BLOCKED window like in fork-join (where the parent waited for the last thread) or fork-join_any (where the parent waited for the first).

7. Synthesis — Not Applicable

fork-join_none is a procedural simulation construct. It has no hardware footprint and no place in synthesisable RTL — synthesis tools reject it outright. This section is intentionally omitted; the topic does not warrant it.

The corresponding hardware idiom for "run these N things in parallel forever" is just always @(posedge clk) begin ... end blocks per concurrent activity — the synthesisable equivalent is built into RTL semantics, not a procedural primitive.

8. Verification View — The Canonical Patterns

8.1 The loop-spawn pattern with wait fork

The combination fork-join_none inside a loop + wait fork after the loop is the only way to spawn a runtime-variable number of parallel threads and then synchronise on their completion. The same automatic loop-variable capture discipline from fork-join applies.

parameter N = 8;
for (int i = 0; i < N; i++) begin
    fork
        drive_channel(i);   // all 8 see i=8!
    join_none
end
wait fork;

parameter N = 8;
for (int i = 0; i < N; i++) begin
    automatic int ch = i;   // NEW per iteration
    fork
        drive_channel(ch);
    join_none
end
wait fork;

8.2 The standard testbench skeleton

The canonical SV testbench uses fork-join_none to launch all persistent infrastructure (clock, monitors, coverage) in one block, then runs the test sequence on the main thread alongside them.

module tb;
logic clk = 0, rst_n;
 
// ── Phase 1: launch all persistent background processes ───────
initial fork
    begin forever #5 clk = ~clk;                       end  // clock
    begin forever monitor_apb();                       end  // APB monitor
    begin forever monitor_irq();                       end  // IRQ monitor
    begin forever @(posedge clk) sample_cov();         end  // coverage
join_none
 
// ── Phase 2: reset ────────────────────────────────────────────
initial begin
    rst_n = 0;
    repeat (4) @(posedge clk);
    rst_n = 1;
 
    // ── Phase 3: directed tests ───────────────────────────────
    test_register_access();
    test_burst_mode();
    test_error_injection();
 
    // ── Phase 4: random tests with parallel channels ──────────
    for (int i = 0; i < 4; i++) begin
        automatic int ch = i;
        fork random_test_channel(ch); join_none
    end
    wait fork;   // wait for all 4 channel tests
 
    // ── Phase 5: drain and check ──────────────────────────────
    repeat (100) @(posedge clk);
    check_final_scoreboard();
    $display("[TB] TEST PASSED at %0t", $time);
    $finish;   // monitors get killed here — that is fine for end-of-test
end
 
endmodule

Two initial blocks: one for persistent infrastructure (everything in fork-join_none), one for the sequential test phases. The wait fork in phase 4 is scoped to the test-initial's spawns, so it waits for the 4 channel tests without trying to wait for the persistent monitors (which would block forever — see §10).

8.3 Class-based agent pool

ApbAgent agents [4];
 
initial begin
    // Construct all agents
    foreach (agents[i]) agents[i] = new();
 
    // Start all agents as background tasks
    foreach (agents[i]) begin
        automatic int idx = i;
        fork
            agents[idx].run();   // each agent runs independently
        join_none
    end
 
    // Main test runs while agents are active
    do_test_stimulus();
 
    // Signal all agents to stop
    foreach (agents[i]) agents[i].stop();
 
    // Wait for all agent threads to finish their cleanup
    wait fork;
    $display("[TB] All agents stopped");
    $finish;
end

The agents own their lifetime via their start() / stop() API (§9). The testbench spawns the run() task via fork-join_none, does its work, signals stop, then wait forks for the agents to drain.

8.4 The $finish race — drain or lose

$finish terminates simulation immediately. Every background thread is killed without warning. Monitors mid-check, scoreboards mid-compare, coverage samplers mid-sample — all are abandoned.

initial begin
    fork
        begin : monitor
            forever begin
                @(posedge clk iff valid);
                check_output();
            end
        end
    join_none
 
    send_100_packets();
    repeat (50) @(posedge clk);    // drain: allow last transactions to propagate
    check_scoreboard_empty();      // verify all packets were checked
    $finish;                       // now safe to finish
end

The drain window (50 cycles after the last stimulus) lets the in-flight packets reach the monitor and get checked. Without it, the last few packets often arrive after send_100_packets() returns but before the next statement — and $finish cuts off the monitor mid-flow.

9. Class-Method Spawning — Object Lifetime Discipline

When a class method uses fork-join_none, the spawned threads outlive the method call. They continue running after the method returns. If the threads access this (the object's properties) and the object goes out of scope, the threads dangle on a soon-to-be-garbage-collected object.

The canonical pattern is to give the class an explicit start() / stop() lifecycle:

class ApbAgent;
    bit running = 0;
 
    task start();
        running = 1;
        fork
            begin : drive_loop
                forever drive_next_txn();
            end
            begin : monitor_loop
                forever monitor_response();
            end
        join_none
        // start() returns immediately; both loops run in background
    endtask
 
    task stop();
        running = 0;
        disable drive_loop;     // kill the drive thread by name
        disable monitor_loop;   // kill the monitor thread by name
    endtask
endclass
 
initial begin
    ApbAgent agent = new();
    agent.start();           // threads start running in background
    #10_000;                 // object stays alive (still in scope)
    agent.stop();            // cleanly kill the threads
    $finish;
end

The start() / stop() discipline keeps thread lifetime explicit:

• The agent's threads live exactly between start() and stop().
• stop() uses named-block disable (disable drive_loop;) to kill exactly the threads this agent spawned — not every background thread in the testbench (which disable fork would do).
• The agent's handle stays in scope through start() → ... → stop(), so the threads never reference a garbage-collected object.

10. Industry Usage — Where fork-join_none Lands in Real Verification

• UVM run_phase() infrastructure — every uvm_component's run_phase() spawns its driver / monitor / sequencer threads via fork-join_none internally; the component tree's spawn cascade is what gives UVM its "everything starts together at run_phase" behaviour.
• UVM monitor tasks — every uvm_monitor::run_phase() ends with forever sample() inside a fork-join_none; the monitor lives for the entire run phase. Stopping it requires phase.drop_objection() (which kicks off a controlled shutdown).
• Coverage collectors — forever @(posedge clk) cg.sample(); inside fork-join_none is the standard pattern for cycle-accurate coverage sampling, surviving alongside the rest of the test.
• Multi-channel protocol VIPs — APB / AHB / AXI / DDR / PCIe / Ethernet agents start their per-channel monitors and drivers via fork-join_none at agent construction; the agents live for the test duration.
• uvm_objection drain time — the canonical way to give a forever-loop monitor time to flush before $finish is phase.phase_done.set_drain_time(this, 1us); under the hood this is the same drain-before-$finish pattern from §8.4.
• Regression-level reset injectors — a reset-injection sequence spawned via fork-join_none runs alongside the main stimulus, injecting random resets at random times without blocking the test's foreground path.
• Per-seed instrumentation — performance probes, transaction recorders, and lint-collectors all run as fork-join_none daemons in serious verification environments.

11. Design Review Notes — What a Senior Will Flag

The single highest-value rule: fork-join_none is for daemons or runtime-variable spawning — not "I want fork-join but lazier." If the spawned work is finite and you eventually need its completion, use fork-join_none + wait fork explicitly, not fork-join_none and hope.

12. Debugging Guide — Real Failures, Real Fixes

fork
    begin : monitor
        forever begin
            @(posedge clk iff valid);
            check_output();
        end
    end
join_none
 
send_100_packets();
$finish;            // BUG: monitor killed mid-flight

initial begin
    fork forever monitor(); join_none      // background monitor
    for (int i = 0; i < N; i++) begin
        automatic int ch = i;
        fork drive_channel(ch); join_none
    end
    wait fork;                              // BUG: includes the monitor
    $finish;
end

fork
    init_memory();          // BUG: spawned, NOT executed yet
join_none
configure_dut();            // runs immediately — sees old memory

for (int i = 0; i < 8; i++) begin
    fork drive_channel(i); join_none   // captures shared i
end
wait fork;

class ApbAgent;
    task start();
        fork
            forever drive_next_txn();
            forever monitor_response();
        join_none
    endtask
    task stop();
        running = 0;
        // BUG: never killed the spawned threads
    endtask
endclass

13. Interview Insights — What Interviewers Actually Probe

14. Exercises

1. Design — testbench skeleton (Foundation)
Write a complete module tb; with two initial blocks: one launches a clock generator + APB monitor + coverage sampler via fork-join_none; the other does reset → 3 directed tests → 4 parallel channels via fork-join_none + wait fork → drain → $finish. Use the canonical pattern from §8.2 as your skeleton.

2. Debug — the missing transactions (Intermediate)
A test sends 1000 packets and the monitor spawned with fork-join_none is supposed to check each one. The scoreboard reports 994 checked. Walk through the diagnostic: what is the most likely cause, what 2 lines fix it, and what is the second-best fix using an event?

3. Code review — the agent lifecycle (Intermediate)
A teammate submits an ApbAgent class with task start(); fork forever drive(); forever monitor(); join_none endtask and task stop(); /* empty */ endtask. The agent's threads keep running after stop() is called. Identify all three bugs and propose the canonical fix.

4. Trade-off — fork-join_none + wait fork vs fork-join (Advanced)
A junior teammate proposes a coding rule: "always use fork-join for parallel work, never fork-join_none + wait fork — fewer lines, less error-prone." Argue the case against. Construct a real verification scenario where the proposed rule cannot express what's needed, and explain why the two-step pattern is fundamentally more powerful.

15. Summary

fork-join_none spawns threads and immediately returns — the parent does not block. Every thread runs in the background from the moment of spawning. The two canonical patterns are daemons (clock generators, monitors, coverage samplers in forever loops) and loop-spawned variable-N agents (fork-join_none inside a for loop, then wait fork; to converge).

Defaults to memorise. Use fork-join_none for daemons and runtime-variable spawning, never for "I want fork-join but lazier." Pair the loop pattern with wait fork; for synchronisation. Drain before $finish — the guillotine kills background threads mid-check. Apply the same automatic loop-capture discipline as fork-join. Use named-block disable in class agents' stop() methods to kill exactly the agent's threads without nuking the rest of the testbench.

This closes the three join variants. Together with the previous lessons, the rule is: join for "wait for all," join_any for "wait for first," join_none for "don't wait." Most testbenches use all three.

Next up: 14.4 — disable fork & wait fork — the deeper rules for selectively killing fork branches by name, the disable fork vs disable <named_block> distinction, and the cleanup discipline that keeps long-running testbenches from leaking background threads.