SystemVerilog clocking block：用 skew 声明 testbench 的同步采样与驱动

更新时间：2026-09-25。本文是「集成电路大类 · 芯片设计 · 数字验证」实操序列的入门专题，接在 SystemVerilog Testbench 实战 之后。上一篇解决了「平台怎么搭」，这一篇往里深入一层，回答一个写过几个 testbench 就一定会撞上的问题：为什么同样在 posedge clk 上动作，testbench 直接采样有时读到旧值、有时读到 X，而换成 clocking block 就稳定了。interface 与 clocking 的完整接线见 SystemVerilog interface 与 clocking block，本文专注 clocking block 的 skew 语义本身。

本文要回答的问题

• 不用 clocking block 时，testbench 在时钟沿同时驱动和采样，竞争到底是怎么发生的？
• clocking block 里的 default input #1step output #0 各自是什么意思，1step 是多长？
• 为什么 input 要在时钟沿「之前」提前采样，output 要在时钟沿「之后」驱动？
• 配合 virtual interface，class 里做同步驱动的完整写法长什么样？
• 裸 interface 加 #1 人为错开的土办法，和 clocking block 差在哪？

一、先看竞争：没有 clocking block 时 testbench 在赌调度顺序

先看一段每个验证新手都写过的代码。DUT 在时钟上升沿用非阻塞赋值（NBA，Nonblocking Assignment）采样输入，testbench 也在同一个上升沿驱动和采样：

// RTL：标准时序逻辑写法
always @(posedge clk) begin
  q <= d;
end

// testbench：同一个 posedge 上既驱动又采样
always @(posedge clk) begin
  d   = $random();          // 阻塞驱动
  tmp = q;                  // 想采样 DUT 的输出
  $display("q = %0d", tmp);
end

问题在于：在时钟沿这一仿真时刻，RTL 的 q <= d 进入 NBA 区域更新，而 testbench 的 tmp = q 在 Active 区域执行。两者的先后由仿真器调度决定，testbench 极可能在 q 还是旧值时就读走了；更糟的是 testbench 用阻塞赋值驱动 d，若排在 RTL 的 Active 事件之前，RTL 同一沿就可能读到刚写入的新值——你以为激励要下一拍才生效，实际当拍就穿进去了。同一套代码换仿真器、换 seed，读到的结果可能不同。

这张图就是竞争的本质：时钟沿不是一个「瞬间完成」的点，SystemVerilog 在这个时刻内部划分了 Active、NBA、Reactive、Postponed 等多个调度区域，所有在沿上发生的事按区域排队，但写在同一区域里的 testbench 与 RTL 事件没有约定先后。要根治它，有两种思路。一种是土办法：testbench 统一在沿后延迟一小段时间动作，比如 #1 再采样、#1 再驱动，用人为错开保证看到稳定值；另一种就是把「相对时钟沿什么时候采样、什么时候驱动」显式声明出来，让语言和仿真器替你保证——这正是 clocking block 的设计目的。调度区域的完整讲解见 program block、final block 与 SystemVerilog 调度区域。

二、clocking block 的声明：时钟、信号与 skew

clocking block 是一块以某个时钟为基准定义的同步信号集合，声明在 interface（或 module）内部。一个最常见的写法如下：

interface dut_if (input logic clk);
  logic [7:0] d;
  logic [7:0] q;

  // 以 clk 上升沿为同步基准
  clocking cb @(posedge clk);
    default input #1step output #0;   // 默认 skew
    input  q;                          // testbench 经 cb 采样的信号
    output d;                          // testbench 经 cb 驱动的信号
  endclocking
endinterface

这段声明做了三件事。第一，@(posedge clk) 给整块信号钉死一个同步事件，之后对 cb.q、cb.d 的一切访问都相对这个沿定义时序。第二，default input #1step output #0 给出默认 skew（偏斜）：所有 input 信号在时钟沿前 1step 采样，所有 output 信号在时钟沿后 0 时间单位驱动；个别信号还可以单独写 input #2 q 覆盖默认值。第三，信号列表的方向是站在 testbench 视角的：testbench 读 DUT 输出，所以 q 是 input；testbench 驱动 DUT 输入，所以 d 是 output，这与 RTL 端口方向恰好相反，新手最容易在这里写反。

skew 与信号方向的配对关系是：input 方向配「沿前采样」规则，output 方向配「沿后驱动」规则，两条规则合起来把上一节的竞争从根上消掉。所谓 1step，是 SystemVerilog 的一个特殊时间单位，等于仿真时间精度（timescale precision）所定义的一个最小时间步，通常是 1ps 甚至更小。它不是一个拍脑袋的「很短延迟」，而是保证落在时钟沿前最后一个可表达时刻（Preponed 区域）的语言级手段：在这个时刻采样，时钟沿上发生的任何新变化都还没发生，读到的必然是沿前已经稳定的值。

三、input skew：沿前采样为什么能消除竞争

把 input skew 的时序展开看。#1step 意味着每次 clocking 事件触发时，cb.q 的采样值在时钟沿之前的一个时间步就被锁定：

这张时序图值得逐段解读。在上升沿前的 1step，clocking 把 q 的值取走并固定为 cb.q；随后时钟沿到来，RTL 在 Active/NBA 区域把 q 更新成新值，但这次更新与 testbench 已经无关——testbench 整个时钟周期内读到的 cb.q 都是沿前锁定的那份。于是「testbench 和 RTL 谁先谁后」的问题消失了：无论调度器怎么排，沿前 1step 都严格早于沿上的一切事件。这也符合 testbench 应有的视角：你在这一拍检查的，本就该是 DUT 上一拍激励产生的结果，而不是同一沿上正在变化中的半成品。

如果不写 #1step 而写正数延迟，比如 input #2 q，含义变成时钟沿之后延迟 2 个时间单位再采样，用于模拟真实世界中带输出延迟的接口信号；写负数如 input #-1 则是沿前 1 个时间单位采样。1step 与具体时间数的区别在于它随 timescale 精度自适应，不会因为模块换了时间单位就错位，这也是默认值选它的原因。

四、output skew：沿后驱动，避开 RTL 的同沿采样

output 一侧的规则正好对称。默认 output #0 表示在时钟沿之后驱动，新值进入沿后的调度区域（Re-NBA），而不是 Active 区域：

解读这张图：testbench 在本拍通过 clocking 写入 d，值在沿后才真正落到信号上，RTL 在当前沿的 NBA 采样无论如何都赶不上它，必然在下一个上升沿才读到新值。这就给出了一条确定的因果链——本拍驱动，下拍生效，与 RTL 综合后的真实硬件行为一致：寄存器之间，沿上更新的值本来就只能被后续沿的寄存器捕获。土办法里 testbench 用阻塞赋值在沿上直接写、导致同沿穿透的隐患，被 output skew 从调度区域层面堵死。

在 clocking 上驱动有专用语法。对 clocking 信号做非阻塞赋值用 <=，若赋值的是时钟沿表达式之外的普通值，也可以用阻塞形式；主流规范推荐统一用 cb.d <= val;，语义是「把 val 安排到下一次 clocking 事件沿后驱动」，可以在一次事件里对多个信号同时赋值而不会有先后问题。还可以用 ##n cb.d <= val; 延迟 n 个时钟事件再驱动，这比在代码里散布 #10、repeat(2) @(posedge clk) 更干净——所有节拍都以时钟事件为单位，改时钟周期时 testbench 一行都不用动。举例说，要表达「拉高二拍、第三拍拉低、再空四拍后写下一个数」，写出来是 cb.v <= 1; ##1 cb.v <= 0; ##4 cb.d <= data;，整段时序自解释，读代码的人数 clocking 事件就能还原波形，不必在脑子里换算任何纳秒数。同步驱动还有一个附带收益：因为一切时序都挂在同一个 clocking 事件上，driver 与 monitor 之间不会再出现「驱动已经发出、检查还没对齐到沿」的错位，事务级的激励与采样天然错开整整一拍，恰好对应 RTL 中激励被寄存一拍后才产生输出的数据通路。

五、完整写法：clocking block 配合 virtual interface

clocking block 本身声明在静态的 interface 里，而激励通常写在动态的 class 中，两者之间靠 virtual interface（虚接口）连接。完整链路如下：

interface dut_if (input logic clk);
  logic [7:0] d;
  logic [7:0] q;
  clocking cb @(posedge clk);
    default input #1step output #0;
    output d;
    input  q;
  endclocking
endinterface

class driver;
  virtual dut_if vif;              // 虚接口句柄，不拥有物理信号

  task drive(input bit [7:0] data);
    vif.cb.d <= data;              // 经 clocking 同步驱动
    @(vif.cb);                     // 等待下一次 clocking 事件
  endtask

  task sample(output bit [7:0] out);
    @(vif.cb);                     // 先对齐到沿
    out = vif.cb.q;                // 读到沿前锁定的稳定值
  endtask
endclass

数据流可以画成下图：

图中关键点是 class 永远不直接碰物理信号，所有访问都经过 vif.cb 这一层，于是 skew 规则对 class 代码自动生效：class 里不需要写任何 #1，也不需要知道时钟周期是多少，@(vif.cb) 就是「等一个时钟事件」的全部写法。虚接口的赋值、重配与多接口数组等进阶用法见 SystemVerilog 虚接口。这种分层还有一个直接好处：换接口频率、换时钟相位，只改 clocking 声明一处，driver、monitor、sequence 全部时序自动跟着变。

monitor 一侧的写法完全对称，而且更能体现「沿前采样」的价值。monitor 每拍把接口事务打包发给 scoreboard，它读到的每个字段都必须属于同一个时钟周期：

class monitor;
  virtual dut_if vif;
  task run;
    forever begin
      @(vif.cb);                       // 对齐到沿
      tx.data_out = vif.cb.q;          // 沿前锁定值
      mon_port.write(tx);              // 事务各字段同源同拍
    end
  endtask
endclass

如果 monitor 直接读物理信号，在 DUT 输出恰好在沿上更新时，一个事务的两个字段可能一个读到旧值、一个读到新值，拼出一个真实世界不存在的事务。经 clocking 读取，所有字段在沿前同一刻锁定，这种「撕裂读」在语法层面就不可能发生。另外可以在 module 或 interface 内写 default clocking cb;，之后 @(cb)、cb.d <= v 可直接省略层次前缀，program/module 级的时钟同步代码会更短；class 中仍然必须带 vif.cb 前缀，因为 class 没有默认 clocking 的作用域。

六、与裸 interface 加 #1 的土办法对比

最后正面回答选题里的对比。不用 clocking block 的工程里，常见的规避写法是给所有沿上动作统一加延迟：

// 土办法：沿后 #1 再采样，沿后 #1 再驱动
task drive_and_check();
  @(posedge clk);
  #1 d = data;          // 错开 Active 区域
  @(posedge clk);
  #1 if (q !== expect) $error("mismatch");
endtask

它确实能在多数情况下跑对，但问题是 1 这个数字承载了它不该承载的语义。第一，它是绝对时间：时钟周期从 10ns 改成 2ns，#1 从「很短」变成「半个周期」，整套 testbench 逐个排查；加上时钟抖动或门级延迟后，#1 甚至可能落在信号还没稳定的窗口。第二，规则只存在于程序员的脑子里和代码评审中，任何一个新加的 task 漏写 #1，竞争立刻回归，而且不报错——只是偶尔读到 X。第三，它没有区分方向：采样要避开沿上更新、驱动要避开沿上 RTL 采样，是两条不同的义务，一个 #1 把两者混成一锅。

这张对比图概括了选型结论：#1 是用人为约定模拟同步，clocking block 是把同步语义写进语言。二者的差距在小 testbench 上不明显，在几十上百个 sequence、多个接口、可能还要跑门级仿真的项目里就是「偶尔抽风的环境」和「时序行为可推理的环境」之间的差距。这也是为什么 UVM 的 agent 一律通过 virtual interface 上的 clocking block 与 DUT 交互——它要保证任何 VIP 在任何集成方的时钟方案下，采样与驱动的相对时序都不依赖具体时间数字。接口协议层面的时序义务则进一步交给断言，写法见 valid ready 握手验证。

七、使用 clocking block 的几个高频坑

第一个坑是信号方向写反。clocking 列表的方向站在 testbench 一侧，与 RTL modport 相反：DUT 的输出在 clocking 里是 input，DUT 的输入是 output。写反后仿真器通常不报错，只是你发现某个信号怎么都驱动不动——因为那块信号对你而言是只读的。排查办法很简单：看到驱动无效，先回 clocking 声明核对方向。

第二个坑是在 clocking 信号上混用阻塞与非阻塞赋值。对 cb 信号连续做阻塞赋值（cb.d = a; cb.d = b;），后者会立即覆盖前者，丢掉「安排到沿后驱动」的同步语义。规范做法是 testbench 侧一律 <=，把每次写入当作沿后生效的调度；需要多拍驱动时用 ##n cb.d <= v;，让延迟以时钟事件表达，而不是绝对延迟。

第三个坑是异步复位与时钟块错配。复位通常异步生效、不受时钟沿管辖，经 clocking 驱动复位会让「立即拉低复位」被迫等到下一个沿，复位序列变得别扭。常见做法是复位信号留在 clocking 列表之外，testbench 直接经虚接口驱动它，只有协议数据信号走 clocking——同步信号与异步信号各走各的通道。

第四个坑是多时钟接口想塞进一个 clocking。一块 clocking 只能有一个时钟事件；跨时钟域的接口要为每个时钟域分别声明 clocking，各自定义 skew，monitor 也分别对齐。跨域验证的整体思路见 异步 FIFO 与 CDC 验证。这几个坑的共同特征是都不报错，只表现为「偶尔不对」，所以环境搭建初期就该把方向、赋值风格、复位归属定成约定，而不是等回归出现诡异波形再回头查。

第五个坑值得单独说：把 clocking 信号名当成普通线网在组合表达式里读取。clocking 列表里的 input 带 skew 语义，读到的是沿前采样值，直接参与 testbench 的组合判断会与 RTL 侧当前值错开一拍，调试时波形上两个值明明相等、比较结果却是失配。需要当前值时应直接读虚接口上的物理信号（vif.d），clocking 信号只用于按拍采样的同步逻辑。把「同步采样值」和「物理当前值」在命名上区分开（例如分别叫 cb_d 与 vif.d），这类错拍问题基本能在代码评审阶段就被发现。

这一篇在知识体系里的位置

本文处在 testbench 基座层：先有 SystemVerilog Testbench 实战 搭起平台，clocking block 为它定义「相对时钟沿如何采样与驱动」的同步语义。想看 interface、modport 与 clocking 的整体接线，读 SystemVerilog interface 与 clocking block；想理解 skew 背后的调度区域，读 program block、final block 与 SystemVerilog 调度区域；class 如何拿到物理接口，读 SystemVerilog 虚接口。再往后，UVM agent 中的 driver/monitor 就是把本文的同步驱动模式组件化，序列见 UVM 组件与 phase。

总结

SystemVerilog clocking block 把 testbench 的同步语义从「人脑约定加 #1」升级为语言声明：用 @(posedge clk) 钉住同步事件，用 default input #1step output #0 规定 input 在时钟沿前一个时间步提前采样、读到沿前稳定值，output 在沿后驱动、保证本拍驱动下拍生效，从调度区域层面彻底消除驱动与采样的竞争；class 经 virtual interface 上的 cb 访问信号，所有节拍以时钟事件为单位，改时钟频率只动声明一处——这就是可预测、可复用的 testbench 同步时序基础。