刚接触 SystemVerilog 那几年，我最怕的不是写断言，也不是搭 UVM 环境，而是被问到"这段逻辑你为什么不写成 function"。systemverilog 里的 function 和 task 看着像一对双胞胎，语法都长得差不多，但真到代码评审的时候，选错一个关键字，轻则编译报错，重则仿真挂死、数据串味、波形上全是红色的 X。我自己就在这两者上摔过不少跟头：把#10写进 function 导致编译直接拒收；在 fork 里并发调用一个 static task，两个线程往同一个变量里写，结果比对全错，查了整整一个下午。

这篇内容想干的事情很具体：把 SystemVerilog 中 function 和 task 的边界、语法、参数传递、automatic 与 static 的坑、以及真实项目里的选型逻辑，从头到尾捋一遍。不管你是刚学 SV 语法、还在纠结"到底哪个该用哪个"的新手，还是已经写了几年验证代码、但一直靠肌肉记忆在选择的老手，都能从里面找到能直接抄的写法和能立刻避开的坑。我不打算讲空泛的语法定义，而是按照一个验证工程师实际的编码路径来展开：先讲怎么判断该用哪个，再讲各自的核心约束，然后用一个寄存器配置与回读校验的完整例子把两者串起来，最后把常见报错和排查思路做成速查表。

1. 先搞清楚 function 和 task 到底在解决什么问题

1.1 一段仿真挂死引发的思考

我最早意识到这两者不能随便混用，是因为一个很典型的场景。当时的验证环境里有一个用来等待总线空闲的代码块，我图省事写成了一个 function，里面用了wait(bus_idle)。编译的时候工具直接抛出 "Function cannot contain timing control"，我当时的反应是"凭什么不让写"。后来才明白，这个限制不是工具在为难人，而是语言层面的一条硬边界。

SystemVerilog 把子程序分成两类，本质上是按照"能不能让时间往前走"来划分的。function 被设计成纯计算单元，执行过程中仿真时间必须保持静止，调用它的那一刻到返回的那一刻之间，时钟不会跳变、事件不会触发。task 则相反，它天然被允许消耗时间，可以等时钟、可以延时、可以挂起自己等待某个信号。

这个区别带来的后果是连锁的。因为 function 不消耗时间，所以它可以被放进表达式里，可以参与连续赋值，可以在断言里、在约束里、在常量函数中被调用。而 task 因为可能挂起，它只能作为一条独立的语句存在，你不能写x = my_task()，语法上就不成立。想明白这一层，后面所有的规则其实都是这条边界的自然延伸。

1.2 时间是否流动：唯一的分界线

如果把这条边界再具体化一点，可以这么理解：function 的执行过程中，仿真器的时钟指针必须冻结。这意味着所有会推进时间或者等待事件的操作都是禁区——#延时、@边沿等待、wait语句、fork...join系列。反过来，只要你的代码里出现了这几样东西中的任何一样，它就只能是 task。

有一个容易被忽略的点：$display、$time、$realtime、$random这些系统函数，在 function 里是可以用的。很多新手会误以为"但凡带$的都不能在 function 里写"，这不对。判断标准始终只有一个——这个操作会不会让时间前进，或者会不会导致当前进程被挂起。$display只是往日志里打一行字，不涉及时间，所以它完全合法。我见过有人在 function 里用$display打调试信息，被同事提醒"function 里不能有系统任务"，其实那位同事记混了规则。

1.3 选型时的三个决策点

实际写代码的时候，我不会去逐条比对语法手册，而是问自己三个问题，基本能在三秒内定下来。

第一个问题是：这段逻辑需要等时间吗？需要等待时钟边沿、需要延时、需要等某个信号翻转，那没什么可犹豫的，直接 task。不需要等，纯粹是数据变换，那就往 function 上靠。

第二个问题是：这段逻辑需要往外传几个值？如果只需要传一个结果，function 的返回值机制最干净；如果需要同时传出两三个结果，比如"读回来的数据 + 一个成功标志 + 一个错误码"，那 task 配合 output 参数写起来更自然，虽然 SV 也允许 function 带 output 参数，但可读性会打折扣。

第三个问题是：这段逻辑会被并发调用吗？如果它可能在 fork 出来的多条线程里同时执行，那 automatic 几乎是必须的，而且要重新审视内部有没有共享的静态变量。这个点后面会单独展开，因为它是最容易埋雷的地方。

2. function 的语法骨架与四个关键约束

2.1 从最简单的 function 写法说起

先看一个我平时写工具函数时最常用的形态，用来做位掩码的合并：

function automatic logic [31:0] pack_field(input logic [31:0] val, input int unsigned lsb, input int unsigned width, input logic [31:0] base); logic [63:0] mask; mask = ((64'd1 << width) - 64'd1) << lsb; return (base & ~mask[31:0]) | ((val << lsb) & mask[31:0]); endfunction

这段代码里几个细节值得说。返回类型写在function关键字后面，参数列表里的input其实是默认方向，写不写都行，但我习惯显式写出来，方便阅读。函数体里可以声明局部变量，可以做赋值、循环、条件判断，只要不涉及时间控制。return是 SV 引入的写法，比传统 Verilog 那种"给函数名赋值"的方式清晰得多。

说到函数名赋值，这里有个真实踩过的坑。在 Verilog-2001 风格里，函数名本身在函数体内被当作一个变量，最后它的值就是返回值。这个特性在 SV 里仍然保留，但会带来一个隐患：如果你在函数体里声明了一个跟函数同名的变量，或者不小心在某个分支里忘了给这个隐式变量赋值，返回值就可能是不确定的。我曾经写过一个带 if-else 的 function，其中一个分支只写了return后面的表达式，另一个分支用了老式赋值，结果两种风格混在一起，读代码的人一脸懵。现在的做法是统一只用return，不再用函数名赋值，除非是在维护老的 Verilog 代码。

2.2 返回值：函数名变量、return 与 void

SV 的 function 在返回值这件事上比 Verilog 灵活很多。返回类型可以是任意数据类型：整型、向量、结构体、枚举、动态数组，甚至是类句柄。这一点在搭建验证环境时特别有用，比如写一个根据寄存器名返回配置结构体的 function，返回类型直接写成 struct，调用方拿到的就是结构化数据，不用再传一堆 output 参数。

另一个常被忽略的能力是void返回类型。写成function void之后，这个函数就不需要返回值，只靠 output 或者 ref 参数往外传数据。这在需要"多返回值但是又不需要等时间"的场景下很好用。我做过一个地址解析的 function，输入一个完整的地址，同时输出基地址、偏移量和区域编号，用 void function 加三个 output 参数实现，代码比拆成三个独立 function 干净得多。

不过这里要提醒一句：SV 允许 function 带 output 和 inout 参数，这是相对 Verilog 的扩展，但不同工具的支持程度略有差异。我在两个主流仿真器上都验证过没问题，但如果你在用比较老的版本，最好先跑个最小例子确认一下。稳妥起见，能用一个返回值搞定的，就别搞多个 output。

2.3 automatic 与 static：递归和多线程的生死线

这是 function 里最容易出问题的地方，也是我认为最值得单独拎出来讲的一点。

在 module、interface、package 这些作用域里定义的 function，默认是 static 的。static 意味着什么？意味着这个函数内部声明的局部变量，在整个仿真期间只有一份存储空间，每次调用都复用同一份。单线程顺序调用的时候看不出问题，因为上一次调用已经结束了，变量值被覆盖也无所谓。但一旦涉及递归或者并发调用，灾难就来了。

先看递归。写一个求阶乘的 function：

// 错误示范：static 版本，递归会出错 function int unsigned fact_bad(int unsigned n); if (n <= 1) return 1; else return n * fact_bad(n - 1); endfunction

这个写法在仿真时会得到莫名其妙的结果，因为每一层递归都在改同一个n，外层还没用完，内层就把它覆盖了。正确写法只需要加一个automatic：

function automatic int unsigned fact(int unsigned n); if (n <= 1) return 1; else return n * fact(n - 1); endfunction

加上 automatic 之后，每次调用都会在栈上分配一套全新的局部变量，递归层次之间互不干扰。这也是为什么我现在的习惯是：所有自己写的 function 和 task，一律显式加 automatic。多打七个字母的成本，换来的是再也不用去担心变量共享问题。

并发调用的情况更隐蔽。假设你有一个 function 内部用了循环变量i，而它被 fork 出来的两条线程同时调用：

function void do_something_bad(); int i; for (i = 0; i < 8; i++) begin // 一些处理 end endfunction

两条线程同时在跑这个循环，共用同一个i，循环次数会完全乱掉，甚至可能死循环。这种 bug 在波形上极难定位，因为变量只在 function 内部，你连波形都抓不到它。我在一个项目里就遇到过类似问题，最后是通过把 function 改成 automatic 才解决的，前后对比之下才发现原来 static 版本在多线程下根本没跑对。

2.4 function 里绝对不能出现的东西

把禁区列清楚，比记规则更容易：

有一个细节很多人不知道：$finish这类系统任务在 function 里其实工具不一定报错，但语义上是危险的，因为它会终止仿真，而 function 的执行上下文被假设为不改变仿真状态。我的建议是，凡是涉及仿真流程控制的操作，统统放在 task 或者 initial 块里，不要往 function 里塞。

3. task 的执行特性与时序控制

3.1 task 骨架与"无返回值"的正确理解

task 的声明方式和 function 很像，区别在于它没有返回类型。很多刚学 SV 的人会误以为"没有返回值就等于不能传出数据"，这是个误解。task 完全可以通过 output、inout、ref 参数往外传值，只是不能像 function 那样写在表达式里。

task automatic apb_write(input logic [31:0] addr, input logic [31:0] data, output logic ok, output logic [31:0] rd_data); @(posedge clk); psel <= 1'b1; penable<= 1'b0; pwrite <= 1'b1; paddr <= addr; pwdata <= data; @(posedge clk); penable<= 1'b1; @(posedge clk); ok = (pready === 1'b1); psel <= 1'b0; penable<= 1'b0; @(posedge clk); rd_data = prdata; endtask

注意这里ok和rd_data的赋值用的是阻塞赋值=而不是非阻塞<=。这不是随手写的，而是有明确理由：output 参数在 task 返回的那一刻才会被复制回调用方，用阻塞赋值能让这个复制行为更符合直觉。如果用非阻塞，赋值会推到 NBA 区域，虽然多数情况下也能工作，但在 task 即将返回的边界上容易出意外的时序竞态。我的经验是，output 参数一律用阻塞赋值，这是条很值得固化的习惯。

3.2 三大类时序控制怎么写

task 里可以用的时序控制基本分成三类，用法和适用场景不太一样。

第一类是边沿等待，也就是@(posedge clk)或者@(signal)。这是验证代码里最常见的，用来让 task 跟随时钟节拍推进。写总线事务的时候，几乎每一步都是"等一个时钟沿，然后改信号"。这里有个实践细节：我习惯在 task 的一开始就先等一个时钟沿，目的是让所有信号的变化都对齐到时钟，避免在时钟边沿附近产生毛刺导致采样不确定。

第二类是延时，#10ns或者#(CYCLE/2)。用在跟真实时序模型交互的场景，比如模拟某个器件上电后的稳定时间。需要注意的是，延时和边沿等待混用时要小心，因为延时不跟时钟对齐，累积下来可能让整个序列偏出时钟节拍。我一般只在初始复位阶段用延时，进入正常事务流程后就切换成纯边沿等待。

第三类是条件等待，wait(cond)或者wait fork。wait(sig == 1)用来等某个条件成立，wait fork用来等所有 fork 出去的子线程结束。后者在写超时保护的时候特别有用。

3.3 参数方向：input、output、ref 的取舍

task 的参数方向有四种：input、output、inout、ref。前三种在 Verilog 时代就有，ref 是 SV 新增的。

它们的复制语义差别很大。input 参数在进入 task 的时候复制一份值进去，之后外面怎么变都不影响 task 内部。output 参数在进入时被初始化，在 task 返回时把值复制出来。inout 是两者结合，进也复制、出也复制。

ref 则是完全不同的一类，它传的是引用，不复制。task 内部对这个参数的修改会立刻反映到调用方那边，不用等到 task 返回。这个特性有两个用处：一是传大数组的时候避免复制开销，二是需要在 task 执行过程中就修改外部变量时很方便。

task automatic monitor_burst(ref logic [63:0] fifo[$], input int expect_num); logic [63:0] beat; for (int i = 0; i < expect_num; i++) begin @(posedge clk); if (data_valid) fifo.push_back(data_bus); end endtask

用 ref 传队列，整个过程中不产生任何复制，性能上比 input 好很多。但反过来说，ref 参数也更容易写出意料之外的副作用，所以我个人的原则是：只在性能确实需要，或者语义上确实要求实时可见的时候才用 ref，普通的小数据量参数老老实实用 input。

还有一条硬性规则要记住：ref 参数要求所在子程序是 automatic 的。如果你在默认 static 的 module 作用域里写了一个带 ref 参数的 task，多数工具会直接报错。这也是我建议所有子程序都加 automatic 的另一个原因。

3.4 static task 的共享变量陷阱

和 function 一样，task 在 module 作用域里默认也是 static。但 task 的 static 问题比 function 更危险，因为 task 天生会被并发调用——fork 出多条线程同时跑同一个 task，是验证环境里的常规操作。

举个我实际遇到过的例子。早期写的一个激励产生 task，内部用一个局部变量记录当前发送的包序号：

// 危险写法 task send_packet(input int ch); static int pkt_id = 0; pkt_id = pkt_id + 1; $display("[ch%0d] send packet id=%0d", ch, pkt_id); // 后续发送逻辑 endtask

这个写法在单通道的时候完全正常，序号依次递增。但当我 fork 出四个通道同时调用它时，四个通道打出来的序号开始重复、跳号，因为pkt_id只有一份，四个线程在互相抢。更麻烦的是$display打出来的顺序看起来还挺正常，你很难从日志上直接看出问题，只有做覆盖率统计的时候才会发现序号总数对不上。

解决方式有两种。一种是加 automatic，让每个调用有独立的 pkt_id，但这样一来序号就不共享了，如果本意就是要全局递增，那得换个思路。另一种是用 ref 参数从外面传一个共享计数器进来，把"是否共享"这件事显式化。我现在的做法是：需要跨调用共享的状态，就用 ref 参数或者类成员显式传递；不需要共享的，一律 automatic。让共享这件事变成代码里看得见的东西，而不是藏在 static 默认值里。

4. 一张表说清 function 与 task 的差异

4.1 核心差异对照表

写了这么多年，我发现大部分纠结都可以靠下面这张表解决。建议存下来，写代码的时候扫一眼。

表格里最容易被忽视的两行，是"能否用于表达式"和"能否在断言中调用"。SVA 序列和属性里只能调用 function，不能调用 task，这是很多人在写断言时踩过的坑。约束块里也一样，约束求解器需要一个纯函数语义的调用，task 进不去。

4.2 为什么 function 不能调用 task

这条规则我在前面提过，但它值得单独展开，因为理解了它，其他规则就都顺了。

假设 function 里允许调用 task，而这个 task 里又有一个@(posedge clk)。那么调用这个 function 的时候，时间就会前进，进程就会挂起。可问题是，调用它的一方可能是在一个表达式里，比如：

assign result = my_func(a, b);

连续赋值语句是仿真器在每个信号变化时重新求值的地方，它没有"挂起"这个概念。如果 function 在这里挂了，仿真器就不知道该怎么办了。同样的道理，断言、约束、常量表达式里也可能调用 function，这些上下文都不接受时间消耗。

所以这条规则不是限制，而是保护。它保证了 function 在所有可能出现的位置都是安全的、可预测的。反方向就没问题，task 里调用 function 是天经地义的，因为 task 自己就在一个可以挂起的上下文里。

4.3 典型场景选型清单

把常见场景列一下，基本覆盖了日常编码的绝大部分情况：

用 function 的场景：位域拼装与提取、地址对齐计算、CRC 与校验和计算、数据类型转换、字符串格式化、根据枚举返回名称、随机数的后处理、断言中的条件判断函数、约束中的辅助计算。

用 task 的场景：总线读写事务、复位序列、上电初始化流程、等待某个信号稳定、发送包并等待响应、带超时的握手、驱动多个信号并保持若干周期、覆盖率采样中的时序相关操作。

有一类场景比较特殊：既需要计算又需要等待。比如"计算一个包的校验和，然后发送出去"。这种情况下我会拆成两个部分，校验和使用 function 算，发送用 task 包起来，task 里先调用 function 算出校验和，再走发送流程。这种拆分方式比硬塞进一个 task 里更清晰，因为计算部分可以被单独复用和测试。

5. 实战：寄存器配置与回读校验模块

5.1 需求拆解与接口定义

光讲语法没意思，我拿一个实际写过的模块来说明。需求是这样的：要对一组寄存器做配置写入，写完立刻回读校验，确保写入生效。寄存器地址是 32 位字节地址，但硬件只认 4 字节对齐的地址；数据是 32 位，但实际有效的字段只占其中若干位，写入前需要保留其他位的原值。

接口定义如下：

class reg_checker; virtual apb_if vif; logic [31:0] shadow[logic [31:0]]; // 影子寄存器 function automatic logic [31:0] align_addr(input logic [31:0] addr); return {addr[31:2], 2'b00}; endfunction function automatic logic [31:0] pack_field(input logic [31:0] val, input int unsigned lsb, input int unsigned width, input logic [31:0] base); logic [63:0] mask; mask = ((64'd1 << width) - 64'd1) << lsb; return (base & ~mask[31:0]) | ((val << lsb) & mask[31:0]); endfunction

align_addr干的事情很简单，把低两位清掉，保证地址 4 字节对齐。用{addr[31:2], 2'b00}这种拼接写法比addr & 32'hFFFF_FFFC更直观，一眼就能看出是"保留高位、低位补零"。

5.2 用 function 做地址对齐和字段拼装

pack_field是这个模块里最值得说的一个 function，因为里面藏着一个非常经典的位宽陷阱。

看这一行：

mask = ((64'd1 << width) - 64'd1) << lsb;

为什么要用 64 位而不是 32 位？因为当width等于 32 的时候，如果写成(32'd1 << 32)，在 32 位算术里移位超过位宽是未定义行为，多数工具会得到 0，那么0 - 1就变成了32'hFFFF_FFFF，掩码完全错掉。用 64 位容器做中间计算，64'd1 << 32得到64'h1_0000_0000，减一之后是64'hFFFF_FFFF，再左移lsb，最后截取低 32 位，逻辑就对了。

这个坑我在两个不同的项目里都踩过，第一次是因为写了一个width = 32的全字段写操作，掩码算成 0，等于什么都没写进去；第二次是在做掩码复用的时候，从别的地方拷了一段 32 位的代码过来，没注意位宽。现在的习惯是：凡是要对掩码做移位运算，中间容器一律用 64 位宽，最后再按需截断。

再补一个实操细节。mask[31:0]这种取位写法，是为了把 64 位的中间结果明确截断成 32 位，避免工具给出位宽不匹配的警告。虽然大多数时候隐式截断也能工作，但显式写出来更安全，也更能表达意图。

5.3 用 task 做总线写与回读比对

配置写入和回读校验这两个动作需要等时钟，所以必须是 task。下面是我实际用的写法：

task automatic write_reg(input logic [31:0] addr, input logic [31:0] val, input int unsigned lsb, input int unsigned width, output logic ok); logic [31:0] a; logic [31:0] old_val; logic [31:0] new_val; a = align_addr(addr); if (!shadow.exists(a)) begin old_val = read_reg_raw(a); shadow[a] = old_val; end else begin old_val = shadow[a]; end new_val = pack_field(val, lsb, width, old_val); ok = apb_write_raw(a, new_val); if (ok) shadow[a] = new_val; endtask task automatic readback_check(input logic [31:0] addr, input logic [31:0] expect, input int unsigned lsb, input int unsigned width, output logic pass); logic [31:0] a; logic [31:0] actual; logic [31:0] mask; a = align_addr(addr); actual = read_reg_raw(a); mask = ((64'd1 << width) - 64'd1) << lsb; pass = (((actual & mask) >> lsb) === expect); if (!pass) begin $display("[FAIL] addr=%08h expect=%08h actual=%08h mask=%08h", a, expect, actual, mask); end endtask

这段代码把 function 和 task 混着用，分工很清楚：地址对齐和字段拼装交给 function，因为它们不需要等时间，而且可以单独拿出来做单元测试；总线操作和回读比对交给 task，因为它们要等时钟。

readback_check里用了一个技巧，就是先算 mask 再比对。这样只校验目标字段，忽略其他位的值。如果不做这个掩码，回读的时候很容易因为其他字段的默认值不符而误报失败。我早期写校验的时候就被这个问题坑过，明明自己写入的字段是对的，但因为整个寄存器的其他位有默认值，直接做 32 位全等比较就失败了。

5.4 位宽与参数计算过程

把上面涉及的计算再捋一遍，方便你直接代入自己的场景。

地址对齐的计算逻辑是：硬件寄存器通常是 4 字节对齐，所以有效地址是addr & 32'hFFFF_FFFC。这个操作的等价写法是(addr / 4) * 4，但用位运算更快也更直观。如果寄存器是 8 字节对齐，那就是addr & 32'hFFFF_FFF8，清掉低三位。

字段掩码的计算逻辑是：先构造一个width位全 1 的值，左移到lsb位置。(1 << width) - 1得到width位全 1，这是标准做法，但前提是中间容器要够宽。我一般直接按 64 位算，因为 SV 里 64 位以内的移位都是单条指令，性能上没有区别。

回读比对的计算逻辑是：先算 mask，把实际值和期望值都截到目标字段上再比。这里有个细节，期望值本身可能超出width位，需要先截断，否则比对会失败。我上面用actual & mask保证两边都在同一基准上。

6. 常见问题与排查实录

6.1 高频报错速查表

这些年我整理了一份报错对照表，基本上新手会遇到的都在里面了。

最后一行值得单独说。output 参数如果某条执行路径上没有被赋值，task 返回时它保持调用前的值，这个行为在 SV 里是允许的，但会给你一个"沉默的错误"。我就遇到过因为一个 if 分支忘了给 output 赋值，导致调用方拿到上一次的旧值，还以为操作成功了。解决办法很简单，task 开头先把所有 output 参数赋个默认值，比如ok = 1'b0;，这样最坏情况下也能拿到明确的失败信号。

6.2 仿真挂起与 X 传播的定位思路

挂起是最难查的一类问题，因为仿真器不会报错，就是不动了。定位思路我一般是这么走的。

先看是不是卡在某个 task 里。做法是在 task 的入口和出口各加一条$display，把参数打出来。如果只看到入口没看到出口，说明就卡在里面。然后逐步往内缩，把 task 里的每一处@或wait前后都加上打印，看是哪一步过不去。

X 传播则更隐蔽，因为它不一定导致挂起，而是让结果算错。我常用的手段是在关键 function 的返回值上做断言式的检查：

function automatic logic [31:0] safe_pack(input logic [31:0] val, input int unsigned lsb, input int unsigned width, input logic [31:0] base); logic [31:0] r; r = pack_field(val, lsb, width, base); if (^r === 1'bx) begin $display("[WARN] X detected in safe_pack: val=%h base=%h lsb=%0d width=%0d", val, base, lsb, width); end return r; endfunction

^r === 1'bx这个写法用的是归约异或来判断有没有 X。只要结果里有任何一位是 X，归约异或就是 X，比较结果就是真。这个方法在调试阶段很好用，比一行行看波形快得多。调试结束之后把这些检查去掉或者用宏包起来，避免影响性能。

6.3 我踩过的几个坑

第一个坑：在 function 里用 for 循环处理动态数组，循环次数依赖数组长度，而数组恰好是空的，结果循环体一次都没进，返回值是未初始化的。这个问题的根源是没有给返回值一个默认值。现在的习惯是，function 开头先给返回变量赋一个明确的默认值，不管后面逻辑怎么走，至少有确定的兜底。

第二个坑：把带时序的初始化逻辑写成了 function，然后又把它包在一个 task 里调用。看起来 task 里调用 function 是允许的，但因为这个 function 内部本身就有@(posedge clk)，编译阶段就直接报错了，根本没机会跑到运行时。这提醒我，判断标准永远看的是被调用的那个子程序自身，而不是调用它的地方。

第三个坑：在 class 里写了一个 function，理所当然地以为它是 automatic 的，结果在 fork 出去的线程里并发调用时发现数据串了。后来查手册才确认，class 里的方法确实默认 automatic，但我那个 function 是在 module 作用域里定义的顶层函数，被 class 里的方法调用，它自己还是 static 的。这是个很有迷惑性的场景，因为代码读起来就像在类里面。

第四个坑：用 ref 参数传队列的时候，在 task 内部对队列做了delete()，调用方那边也同步被清空了，而我原本以为这只是内部操作。这个不算 bug，是 ref 的正确行为，但它提醒我 ref 参数要有明确的注释说明，否则后面维护的人会以为是在操作副本。

7. 更上一层：类中的 function 与 task

7.1 类方法默认 automatic 意味着什么

这一条我觉得值得单独拎出来讲，因为它跟 module 作用域的默认值正好相反。在 class 里定义的方法，不管是 function 还是 task，默认都是 automatic 的。也就是说，每一个类实例调用方法时，内部的局部变量都是独立的。

这个设计很合理，因为面向对象本来就强调封装和独立性。但它也带来一个反直觉的后果：如果你想让某个类方法内部维护跨调用的状态，就必须显式用 static 成员变量，而不是靠局部变量。

class pkt_gen; static int total_count = 0; // 显式共享 int local_count = 0; // 每个实例独立 function automatic int next_id(); total_count++; local_count++; return total_count; endfunction endclass

这里total_count是所有实例共享的，因为加了 static；local_count是每个实例各自的。理解了这一点，就不会在类里写出"以为共享其实没共享"或者"以为独立其实共享了"的代码。

7.2 virtual 与 pure virtual

类里的 function 和 task 还可以加 virtual 修饰，表示可以被派生类覆盖。写成pure virtual就是不实现，强制派生类去实现。这两个关键字在搭 UVM 验证环境的时候用得很多，比如基类定义事务发送接口，具体协议的子类各自实现。

这里有个跟 function/task 相关的约束：pure virtual 的 function 不能有函数体，pure virtual 的 task 也不能有任务体，只能在派生类里给出具体实现。如果你的基类里写了一个 pure virtual function 又想给它一个默认实现，那就不能加 pure，只能写成普通的 virtual function。这个细节在写代码生成器或者事务基类的时候容易搞混。

还有一个点是，覆盖的时候签名必须匹配。如果你在基类里写的是function void send(int a)，在派生类里写成task send(int a)，这不是覆盖，而是两个完全不同的东西，工具可能会给出警告甚至报错。我在一次重构中把某个方法的类型从 function 改成了 task，忘了同步改派生类，结果新方法根本没被调用到，花了不少时间才定位出来。

7.3 覆盖率和断言里的使用边界

覆盖率相关的采样逻辑，通常放在 task 里，因为采样往往需要等待特定的时钟沿或者条件。而断言里的条件判断，只能调用 function，因为断言在被求值的时候不允许时间推进。

这两者的边界在使用中经常被混淆。我见过有人在 covergroup 的sample()方法里调用一个带@(posedge clk)的 task，结果仿真行为变得很怪异。covergroup 的 sample 方法应该是一个纯粹的数据采集动作，往里塞时序控制是危险的做法。正确的方式是在 task 里等待到合适的时刻，然后调用 covergroup 的sample()，而不是反过来。

写断言的时候还有一个限制值得注意：断言里可以调用 function，但这个 function 必须是可以在零时间内完成的，不能有循环次数依赖运行时长的不确定性逻辑。我一般会在断言里只调用最简单的比较和位运算 function，稍微复杂点的逻辑先算好放到变量里，再在断言里引用变量。

踩过几次坑之后，我现在写任何子程序之前都会先问自己那句老话：这段逻辑要不要等时间。要等的，task；不等的，function；可能被并发调用的，automatic；需要跨调用共享状态的，用 ref 参数或者类成员显式声明。这四条规则覆盖了我日常编码里九成以上的选择，剩下那一成，翻翻手册基本也就清楚了。