Tasks in Verilog — Procedures with Any I/O and Optional Timing

Chapter 15 · Section 15.2 · Tasks & Functions

1. The Engineering Problem

A repeated procedure — a multi-cycle bus write, a reset sequence, a computation with several outputs — needs packaging, and a function can't do it (one value, no timing). A task can:

A task is a procedure with any number of inputs/outputs/inouts and optional timing, called as a statement — the tool for multi-step and timed operations.

This page drills the task.

2. Mental Model — A Procedure with Arbitrary I/O and Optional Timing

3. Defining a Task

   // a task with inputs and outputs (no timing → synthesizable):
   task minmax;
       input  [7:0] a, b;
       output [7:0] mn, mx;        // multiple outputs
       begin
           mn = (a < b) ? a : b;
           mx = (a < b) ? b : a;
       end
   endtask
 
   // a timed task (testbench bus write — simulation-only):
   task do_write;
       input [7:0] addr, data;
       begin
           bus_addr = addr; bus_data = data; we = 1;
           @(posedge clk);         // timing → simulation-only
           we = 0;
       end
   endtask

• A task declares its inputs, outputs, and inouts; results come back through the output arguments.
• The body is a sequence of statements (in begin...end).
• Timing (@(posedge clk)) makes a task simulation-only; without it, the task is synthesizable.

4. Calling a Task

   // as a statement, with arguments mapped to the task's I/O:
   minmax(x, y, low, high);        // low, high receive the outputs
 
   // a timed task in a testbench:
   initial begin
       do_write(8'h10, 8'hA5);
       do_write(8'h11, 8'h3C);
       $finish;
   end

A task is called as a statement; its arguments map to the task's inputs (passed in) and outputs (received back). Timed tasks are the backbone of testbench stimulus — a do_write / do_read pair turns a bus protocol into reusable calls (Chapter 9.5).

Visual A — a task is a callable procedure

5. Task vs Function — Recap

• Function (15.1) — one return value, no timing, in an expression; combinational reuse.
• Task — any I/O, optional timing, a statement; procedure reuse.
• A task can call functions and tasks; a function can call only functions.
• A synthesizable task has no timing; a timed task is testbench-only.

Choose a task when you need multiple outputs, timing, or a multi-step procedure; choose a function for a single value computed instantly.

6. Common Mistakes

1. Using a function where multiple outputs are needed — use a task (§5).
2. Expecting a synthesizable task with timing — timing makes it simulation-only (§3).
3. Calling a task in an expression — tasks are statements, not expressions (§4).
4. Static task corrupted by concurrent calls — use automatic for reentrancy (15.3/15.4).

7. Debugging Lab

// A task that drives one channel: latch the data, wait a cycle, drive the bus.
// It is STATIC by default, so it has ONE shared set of locals for ALL calls.
task drive_channel;                 // static (default)
  input integer ch;
  input [7:0]   data;
  reg   [7:0]   local_buf;        // ONE shared copy across every call
  begin
      local_buf = data;
      @(posedge clk);            // <-- the task suspends here, in time
      bus[ch] = local_buf;
  end
endtask

// The testbench drives several channels CONCURRENTLY:
initial fork
  drive_channel(0, 8'hA1);
  drive_channel(1, 8'hB2);
  drive_channel(2, 8'hC3);
join

// Because the task is static, all three calls share the SAME 'local_buf'.
// Call 0 sets local_buf = A1, then suspends at @(posedge clk). While it is
// suspended, call 1 runs and overwrites local_buf = B2, then call 2 sets
// local_buf = C3. When the clock edge arrives, ALL THREE resume and each
// writes the (now shared) local_buf — so every channel gets C3 instead of
// its own data. The channels corrupt each other through the shared local.

task automatic drive_channel;       // automatic → per-call storage (re-entrant)
  input integer ch;
  input [7:0]   data;
  reg   [7:0]   local_buf;        // a SEPARATE copy for every call
  begin
      local_buf = data;
      @(posedge clk);
      bus[ch] = local_buf;
  end
endtask

// With 'automatic', each of the three concurrent calls gets its own
// 'local_buf', so channel 0 keeps A1, channel 1 keeps B2, channel 2 keeps C3
// across the suspension — no cross-corruption. Any task that can be called
// concurrently (from fork...join, multiple always blocks, or recursively)
// must be 'automatic'. (Static vs automatic storage — 15.3; re-entrancy — 15.4.)

8. Interview Q&A

9. Exercises

Exercise 1 — Write a task

Write a synthesizable task swap that takes two 8-bit inputs and returns them swapped via two outputs.

Exercise 2 — Testbench task

Write a timed task do_read that drives a read on a bus and captures the result one clock edge later.

Exercise 3 — Task or function?

For (a) computing a CRC value and (b) applying a 3-cycle reset, which construct fits each?

10. Summary

A task is a reusable procedure:

• Any I/O — multiple inputs/outputs/inouts; results via output arguments.
• Optional timing — can consume simulation time (#/@/wait); synthesizable only without timing.
• Called as a statement — do_write(addr, data);.
• Use for procedures, multi-output operations, and testbench stimulus.

The next sub-topic covers storage behaviour: Chapter 15.3 Static & Automatic Behaviour drills how task/function locals are shared (static) or per-call (automatic).

Related Tutorials

• Function — Chapter 15.1; the value-returning construct (contrast).
• Tasks & Functions — Chapter 15 overview; task vs function.
• Testbench Creation Techniques — Chapter 9.5; tasks structuring stimulus.
• Timing Controls — Chapter 14.4; the timing a task may contain.