SystemVerilog Clocking Blocks Part 2

Always check your active timescale when using bare numbers for skew — the same #2 can mean very different things depending on what's in effect for that file.

The Special Case: #1step

#1step is the most commonly used input skew, and it's worth understanding precisely. Instead of specifying a time offset, it tells the simulator to sample the signal in the Preponed region of the current time step. This region runs before any active logic evaluates at that time — which means you're guaranteed to read the value the signal had at the end of the previous time step, before any new changes take effect.

In practical terms: #1step gives you the last stable, settled value of the signal just before the clock edge fires. It's the safest choice for inputs because it completely sidesteps race conditions.

clocking cb @(posedge clk);
  input #1step req;   // sample req in the Preponed region — always safe
endclocking

The Special Case: Output with #0 or No Skew

Outputs declared with #0 or with no skew at all are driven in the Re-NBA region of the same time step as the clock edge. The Re-NBA region runs after all non-blocking assignments in the design have settled. This ensures your testbench output doesn't interfere with what the design is computing on the same edge. It isn't simply "zero nanoseconds" — it's a deliberate scheduling position that keeps testbench and design updates separated.

A Complete Example

Let's build a working example step by step. The design is a simple request-grant module: it asserts gnt as soon as it sees req high.

module des (input logic req, clk, output logic gnt);
  always @(posedge clk)
    gnt <= req ? 1 : 0;
endmodule

The interface bundles the signals and the clocking block together. Here, gnt gets an input skew of 1ns (sampled 1ns before the positive edge), and req gets an output skew of 5ns (driven 5ns after the positive edge):

interface req_gnt_if (input logic clk);
  logic gnt;
  logic req;

  clocking cb @(posedge clk);
    input  #1ns gnt;   // sample gnt 1ns before posedge
    output #5ns req;   // drive  req 5ns after  posedge
  endclocking
endinterface

The testbench drives req through the clocking block and then reads back gnt:

module tb;
  logic clk;

  initial clk = 0;
  always #10 clk = ~clk;   // 20ns period, posedge at 10, 30, 50 ...

  logic req_val = 0;       // testbench copy of req: an output clockvar cannot be read back

  req_gnt_if vif (.clk(clk));
  des dut (.clk(clk), .req(vif.req), .gnt(vif.gnt));

  initial begin
    vif.cb.req <= req_val;

    // Toggle req several times at random intervals
    repeat (5) begin
      repeat ($urandom_range(1,3)) @(vif.cb);
      req_val = ~req_val;
      vif.cb.req <= req_val;
    end

    #40 $finish;
  end
endmodule

From a waveform viewer, you'd see that every time the testbench assigns vif.cb.req, the actual change on the wire appears 5ns after the positive clock edge — not at the edge itself. This is the output skew at work.

Output Skew in Detail

To make output skew very visible, here's an interface with three clocking blocks that all share the same clock but each have a different output skew:

interface _if (input logic clk);
  logic req;

  clocking cb_0 @(posedge clk);
    output #0ns req;    // driven in Re-NBA region (same edge)
  endclocking

  clocking cb_1 @(posedge clk);
    output #2ns req;    // driven 2ns after posedge
  endclocking

  clocking cb_2 @(posedge clk);
    output #5ns req;    // driven 5ns after posedge
  endclocking
endinterface

cb_0, cb_1, and cb_2 are all declared on the exact same @(posedge clk) event, side by side — SystemVerilog allows multiple clocking blocks to reference the same clock event, each maintaining its own independent skew, which is exactly what this example (and the next one) relies on to demonstrate different skews side by side.

The testbench iterates through three rounds, using a different clocking block each time to assert req:

module tb;
  logic clk;

  initial clk = 0;
  always #10 clk = ~clk;

  _if vif (.clk(clk));

  initial begin
    for (int i = 0; i < 3; i++) begin
      repeat (2) @(vif.cb_0);   // wait 2 posedges

      case (i)
        0: vif.cb_0.req <= 1;   // driven at Re-NBA of posedge
        1: vif.cb_1.req <= 1;   // driven 2ns after posedge
        2: vif.cb_2.req <= 1;   // driven 5ns after posedge
      endcase

      repeat (2) @(vif.cb_0);
      vif.req <= 0;             // direct reset between rounds (no clocking block skew intended here)
    end
    #20 $finish;
  end
endmodule

The line vif.req <= 0; bypasses the clocking block intentionally — it's used here only to reset the signal between test rounds, not as part of the timed stimulus. In a real testbench, always drive stimulus through the clocking block; direct assignments skip the skew entirely and should only be used for housekeeping tasks like initialization or reset.

In a waveform viewer, all three rounds show req going high at different offsets from the clock edge: immediately (Re-NBA region), 2ns later, and 5ns later. The clock edge itself is the same in all three cases — only the output skew differs.

Input Skew in Detail

Input skew controls when the clocking block takes a snapshot of a signal. To demonstrate this clearly, we use a design that drives a random 4-bit value every 1ns — so the signal is changing quickly, and different sampling times will capture different values:

module des (output logic [3:0] gnt);
  always #1 gnt <= $random;
endmodule

The interface has four clocking blocks, each sampling gnt at a different point relative to the positive clock edge:

interface _if (input logic clk);
  logic [3:0] gnt;

  clocking cb_0 @(posedge clk);
    input #0     gnt;      // sample at posedge, in Observed region
  endclocking

  clocking cb_1 @(posedge clk);
    input #1step gnt;      // sample in Preponed region (just before posedge)
  endclocking

  clocking cb_2 @(posedge clk);
    input #1ns   gnt;      // sample 1ns before posedge
  endclocking

  clocking cb_3 @(posedge clk);
    input #2ns   gnt;      // sample 2ns before posedge
  endclocking
endinterface

The testbench launches four parallel threads. Each thread waits for its own clocking block's edge and then prints the sampled value:

module tb;
  logic clk;

  initial clk = 0;
  always #5 clk = ~clk;   // 10ns period

  _if    vif (.clk(clk));
  des    dut (.gnt(vif.gnt));

  initial begin
    fork
      begin @(vif.cb_0); $display("cb_0 (#0    ): gnt = 0x%0h", vif.cb_0.gnt); end
      begin @(vif.cb_1); $display("cb_1 (#1step): gnt = 0x%0h", vif.cb_1.gnt); end
      begin @(vif.cb_2); $display("cb_2 (#1ns  ): gnt = 0x%0h", vif.cb_2.gnt); end
      begin @(vif.cb_3); $display("cb_3 (#2ns  ): gnt = 0x%0h", vif.cb_3.gnt); end
    join
    #10 $finish;
  end
endmodule

Example output (exact values depend on the simulation seed):

cb_3 (#2ns  ): gnt = 0x9
cb_2 (#1ns  ): gnt = 0x3
cb_1 (#1step): gnt = 0x3
cb_0 (#0    ): gnt = 0xd

Why are the values different? The design is changing gnt every 1ns. The testbench's clock starts at 0 and first toggles high 5ns later, so the first positive edge actually lands at 5ns, not a round number like 10ns. At that edge:

• cb_3 samples at 3ns — it sees whatever value was present 2ns before the edge
• cb_2 samples at 4ns — it sees the value from 1ns before the edge
• cb_1 samples in the Preponed region at 5ns — it captures the last settled value before any active logic fires at the edge. This is why it gets the same result as cb_2 here: both saw the same stable value set at 4ns, with nothing changing gnt again before 5ns
• cb_0 samples at the edge itself, in the Observed region — it may catch a value already updated by active events at 5ns, which is why it differs from the others

This illustrates exactly why #1step is preferred for testbench inputs: it's designed to give you the last clean, settled value rather than a potentially mid-update snapshot.

Choosing the Right Skew: Practical Guidelines

• For inputs, always prefer #1step unless you have a specific reason to sample at a precise time offset. It gives the cleanest, race-free read.
• For outputs, use a small positive time value (like #1ns or #2ns) that still satisfies the setup time of the design but clearly places the drive event after the clock edge. Avoid #0 unless you understand the Re-NBA scheduling implications.
• Match your skew to your clock period. Driving an output #8ns after the edge of a 10ns clock means it arrives very close to the next edge — this could violate setup time on the design side.
• Use bare numbers with caution. Always confirm the active timescale in the file so you know what a bare #2 actually means.

Common Beginner Mistakes