SystemVerilog Process Class

disable fork and wait fork both act on every process spawned by the current process at once — there's no way to target just one of them. SystemVerilog's built-in process class fills that gap: it gives you a handle to one specific process, letting you check its status and control it individually, without touching anything else running alongside it.

7 min read | Intermediate Level

What You'll Learn

• What the process class is, and how process::self() gives you a handle to the currently executing process
• The different states a process can be in, and how to check them with status()
• How to suspend, resume, and kill one specific process without affecting any others
• How process::kill() differs from disable fork in scope

What Is the process Class?

Every thread — an initial or always block, or a thread spawned by fork — has a built-in process object associated with it automatically. You can't create a process object yourself with new(); SystemVerilog creates one internally whenever a process is spawned. To get a handle to a process, you call the static method process::self() from within that process — it always returns a handle to whichever process is calling it, never to some other thread.

Process States

A process object's status() method returns one of five states:

Basic Syntax

The built-in process class provides these members:

class process;
  typedef enum { FINISHED, RUNNING, WAITING, SUSPENDED, KILLED } state;

  static function process self();      // handle to the calling process
  function state status();             // current state of this process
  function void suspend();             // pause this process
  function void resume();              // resume a suspended process
  function void kill();                // terminate this process and its descendants
  task await();                        // wait for this process to finish
  function void srandom (int seed);            // reseed this process's own random generator
  function string get_randstate();             // save this process's random state
  function void set_randstate (string state);  // restore a previously saved random state
endclass

Parameters:

• self() — a static method, called as process::self(), with no arguments
• All other methods are called on a process handle you've already obtained, such as my_proc.status()

A Complete Example

A common pattern is to spawn a background task with fork...join_none, capture its own process handle from inside itself, and store that handle somewhere the rest of the code can reach:

module tb;
  process bg_proc;

  task background_task ();
    bg_proc = process::self();   // capture this task's own process handle

    forever begin
      #10 $display ("[%0t] Background task running", $time);
    end
  endtask

  initial begin
    fork
      background_task ();
    join_none

    #25;
    $display ("[%0t] Status before kill: %s", $time, bg_proc.status().name());

    bg_proc.kill();
    $display ("[%0t] Background task killed", $time);

    #20 $finish;
  end
endmodule

background_task captures its own handle into bg_proc the moment it starts, then loops forever, printing every 10ns. The main thread, meanwhile, continues immediately after join_none, waits 25ns, then checks bg_proc's status. At that point, background_task has already printed at 10ns and 20ns, and is currently blocked inside its third #10 delay — so status() returns WAITING. Calling bg_proc.kill() right after terminates it for good, so it never reaches its next scheduled print at 30ns.

Suspending and Resuming a Process

suspend() pauses a process without terminating it, and resume() lets it continue from exactly where it left off:

initial begin
  process p;

  fork
    begin
      p = process::self();
      forever #5 $display ("[%0t] Tick", $time);
    end
  join_none

  #12 p.suspend();   // pause the ticking process mid-cycle
  #20 p.resume();    // let it continue from where it left off
end

Unlike kill(), suspend() doesn't lose the process's place — once resume() is called, it picks back up exactly where it was paused.

process vs disable fork: Which Should You Use?

disable fork terminates every active descendant of the calling process at once — a blunt, all-or-nothing tool. A process handle lets you target one specific process instead, which matters when a single parent has spawned several independent background threads and you only want to stop one of them. That said, kill() isn't perfectly surgical either: killing a process also terminates all of its own descendant processes, so it's scoped to one process's subtree, not just that single process in isolation.

Common Beginner Mistakes

module tb;
  process proc_a, proc_b;

  task monitor_a ();
    proc_a = process::self();
    forever #5 $display ("[%0t] Monitor A", $time);
  endtask

  task monitor_b ();
    proc_b = process::self();
    forever #5 $display ("[%0t] Monitor B", $time);
  endtask

  initial begin
    fork
      monitor_a ();
      monitor_b ();
    join_none

    #22 proc_a.kill();
    $display ("[%0t] Monitor A killed, Monitor B still running", $time);

    #20 $finish;
  end
endmodule