SystemVerilog线程控制专题：fork/join家族与automatic变量深度解析

第一次在SystemVerilog代码里看到 fork/join 的时候，我脑子里蹦出来的念头是：这怎么长得跟多线程编程一样？后来在调试一个总线功能模型时，才彻底想明白——验证平台天生就是并发系统。激励要产生，接口要驱动，协议要采样，参考模型要跑，计分板要比对，这些活儿要是排成一个串行队列，一个仿真永远跑不完。线程控制，就是用来管理这一堆同时存在的执行流的。

这篇对应SV基础阶段的线程控制专题，我会把 fork/join 家族、wait fork、disable fork、进程对象、automatic 变量这些内容串起来讲。如果你是 Verilog 背景转过来学验证的，重点看 fork/join 和 automatic 的关系；如果你已经在写 class 组件，重点看进程对象和线程泄漏的部分；要是你正在被"仿真退不出来"和"仿真提前跑完"折磨，直接跳到最后章节。

1. 验证平台为什么天生是多线程的：从always块思维到事务级并发

1.1 硬件并行基因与软件串行习惯的冲突

写RTL的时候，我们习惯的是每个 always 块、每段 assign 连续赋值各自独立并行运行。这是硬件描述语言刻在骨子里的基因。可一旦开始写验证，很多人会下意识地把 Testbench 描述成一段"先给复位、再发激励、再等结果"的流水账。这个思路在极简单的定向测试里勉强能跑，但只要场景一复杂，串行写法就会卡住自己。

SystemVerilog 的 initial 块本身只是表示一个仿真时间上的起点，它内部默认还是顺序执行的。真正支撑并发的，是 fork/join 这样的显式并行块。很多人在这里的第一个认知偏差是：觉得 initial 块多了，或者 always 块多了，就是并发。其实每个 initial/always 确实是一个独立的进程，但在一个 initial 块内部，如果你不主动写 fork，它永远是一条道走到黑。

1.2 一个典型的并发验证场景

假设现在要给一个 DUT 做基本的功能验证，需要同时做三件事：给复位、产生事务激励、在总线上监听响应。用串行写法的痛苦在于，监听响应是一件持续要做的事情，你不可能"先发完激励再开始监听"，因为很多协议错误就发生在激励发送过程中。

一个自然的写法是：

initial begin fork reset_dut(); gen_transactions(); monitor_bus(); join $display("[%0t] all done", $time); end

这个例子里，reset_dut、gen_transactions、monitor_bus 三个任务会并行执行。join 的语义是等三个都结束后，initial 才继续往下走。看起来很合理，但实际工程里，我们往往需要的是"同时运行、互不等待"，或者"等其中一个先完成就继续"。线程控制解决的就是这一类问题：哪些任务一起跑，等到什么程度算结束，中途如何停止，停止谁而不误伤谁。

1.3 线程控制在整个验证知识体系中的位置

如果把验证环境比作一家餐厅，线程就是厨师和服务员。主线程是店长，fork/join 是排班方式，wait fork 是打烊时等所有岗位收工，disable fork 是紧急停业时把所有岗都拉掉。你后面要学的 sequence 机制、组件之间的启动关系，本质上都建立在这套线程控制能力上。

理解了这一层，再看后面 UVM 里那些 start、run 方法，就不会觉得它们是凭空冒出来的魔法。所有组件里的 task，早就是在线程框架里运行的，只是框架把细节藏起来了。这也是为什么基础阶段一定要把这个专题啃透——它不是孤立的知识点，而是后面所有并发验证代码的地基。

2. fork/join 三兄弟：选错一个整轮回归就崩

2.1 基本语法与"每行一个线程"的执行语义

先看最基础的 fork/join。它和 begin/end 正好是一对：begin/end 是顺序块，里面的语句一条接一条执行；fork/join 是并行块，里面的每一条语句或每一个块，都会作为独立线程并发执行。

initial begin $display("[%0t] test start", $time); fork begin #20; $display("[%0t] thread A", $time); end begin #10; $display("[%0t] thread B", $time); end join $display("[%0t] test end", $time); end

执行顺序是：time 0 打印 test start，然后两个线程并发跑，time 10 打印 thread B，time 20 打印 thread A，time 20 之后打印 test end。注意 final display 是等到两个线程全部结束后才执行的，这是 join 和另外两个兄弟最大的区别。

一个很容易被忽略的细节：fork 下面如果只写了一行语句而不是 begin/end 块，那一行语句本身也是一个独立线程。所以下面这种写法里，两个 $display 理论上都可能先执行，顺序不确定。工程上我一般建议，fork 下每条分支都显式写成 begin/end 块，层级清楚，也方便后面给块命名。

2.2 join_any：等任意一个先来

join_any 的语义是：父线程等着，只要 fork 里任意一条分支线程结束，父线程就立刻继续往下走。剩下的分支线程不会被取消，它们还在后台继续跑。

initial begin fork begin #100; $display("[%0t] slow task done", $time); end begin #30; $display("[%0t] fast task done", $time); end join_any $display("[%0t] parent continues", $time); end

这段代码里，time 30 时 fast task 先结束，父线程立刻打印 parent continues，但 slow task 没有死，time 100 时还会打印 slow task done。

join_any 最常见的用途是"等待多个条件里最先满足的那个"。比如等待中断信号，或者等待外部事件，同时设一个超时看门狗，哪个先来就按哪个处理。但是注意，如果只写了 join_any 而没有配套的线程清理动作，那个没跑完的线程可能会在仿真结束时造成意想不到的问题，这一点后面会细说。

2.3 join_none：放出去就不管，前提是仿真别结束

join_none 的语义最轻：父线程根本不等，fork 一执行，父线程立刻继续往下走，子线程们在后台自己玩。

initial begin fork begin #50; $display("[%0t] background task", $time); end join_none $display("[%0t] parent immediately continues", $time); #100; $display("[%0t] test end", $time); end

打印顺序会是：time 0 父线程继续，time 50 后台任务打印，time 100 test end。子线程不会影响父线程的执行节奏。

很多人对 join_none 的理解止步于"不等待"，但真正的重点是：从 fork/join_none 执行那一刻起，父线程和子线程就分道扬镳了。如果父线程在 join_none 之后没有任何延时，直接跑到 initial 末尾结束，而仿真事件队列里又没有其他需要调度的事件，子线程可能根本没机会执行就被仿真器终止。这是初学者最容易踩的坑，后面调试章节还会再展开。

2.4 三张面孔的对比

选择这三兄弟，本质上是在回答一个问题：父线程愿意等在哪个同步点上。选错了不会导致编译失败，但会导致仿真行为和你预期完全不同，而且这种错误往往在回归测试里才爆发。

2.5 嵌套fork与命名块的组合实战

fork 是可以嵌套的。一个分支线程内部，还可以继续 fork 出一组并行的子线程。这种情况下，外层 join 等的是整个内层 fork/join 块的完成。

task run_all(); fork begin : t1 fork driver_a(); driver_b(); join end begin : t2 monitor_c(); end join endtask

t1 内部那两个 driver 都跑完了，t1 这个线程才算结束，外层才会继续。这种嵌套写法在真实测试环境里很常见，比如一个激励任务内部又拆成了多个并行的子协议序列。给 begin 块起名字是个好习惯，因为后面可以用名字来做定点终止操作，这一点在下一章会详细说。

3. 等线程与杀线程：wait fork、disable fork 的边界和误伤

3.1 wait fork：全体集合的哨声

wait fork 的语义是：当前线程阻塞，直到它派生的所有后代线程全部结束。注意关键词是"所有"和"后代"。

initial begin fork begin #50; $display("[%0t] sub thread 1", $time); end begin #80; $display("[%0t] sub thread 2", $time); end join_none // 做一些别的事 #20; wait fork; $display("[%0t] all sub threads finished", $time); end

父线程在前 20 个时间单位里干别的事，然后 wait fork 等着两个子线程都结束。time 50 第一个子线程结束，time 80 第二个子线程结束，父线程才继续。

wait fork 的实用价值在于：你既想启动一堆后台线程，又不想立刻等它们，但又不希望在仿真结束前把它们丢掉。典型场景是测试主流程完成后，需要确保所有后台监控线程都收尾了再结束仿真。

3.2 wait fork 的适用范围和容易踩的误区

wait fork 有一个显而易见的限制：它不能指定某一个线程，只能无差别地等所有后代线程。如果你启动了线程 A 和线程 B，你只想等线程 A 结束，wait fork 是做不到的。这时候要么用事件做显式同步，要么用进程对象做精细化控制，后面 3.5 会讲。

还有一点经常被忽略：wait fork 只会等待"当前线程派生的后代线程"。如果子线程自己又派生出了孙子线程，孙子线程也在等待范围内，这个没问题；但别的 initial 块里派生出来的线程，不归你管，wait fork 也等不到它们。理解这一点，对排查"我明明 wait fork 了，为什么仿真还在跑"这类问题有很大帮助。

3.3 disable fork：无差别终止的误伤现场

disable fork 的坑，我见过太多次了。它的语义是：终止当前线程派生的所有活动子线程，包括它们的后代线程。注意，是"所有"，不是"某一个"。

看这个经典翻车例子：

initial begin fork begin : load_cfg #100; $display("[%0t] config loaded", $time); end begin : wait_irq wait(irq == 1); $display("[%0t] irq received", $time); end join_any disable fork; // 你以为只杀了 wait_irq，其实 load_cfg 也被干掉了 end

写这个代码的人本意是：两个任务谁先完成就继续，另一个别管了。如果 irq 在 time 30 到来，wait_irq 先结束，join_any 让父线程继续，然后 disable fork 想把还没跑完的 load_cfg 终止掉。但事实上，disable fork 把 load_cfg 和 wait_irq 全部终止了。如果 load_cfg 此时已经完成，那还好；如果它还在中途，配置加载就被打断了，后面所有依赖这个配置的代码都会开始出错。

这种 bug 最恶心的地方在于：它不一定每次仿真都触发。irq 来得早，load_cfg 还没跑完就被杀了；irq 来得晚，load_cfg 已经跑完了，disable fork 这一刀下去没伤到它。于是同一个测试，有时候正常，有时候挂，典型的自己都说不清楚的问题。

3.4 用命名块 + disable 实现定点清除

那到底怎么精确终止某一个线程？SV 的老办法是给 begin/end 块起名字，然后用 disable 加块名来定点终止。

initial begin fork begin : cfg_thread // 加载配置 #100; end begin : irq_thread wait(irq == 1); end join_any disable irq_thread; end

disable 定点终止命名块是合法的，它只会终止那个命名块对应的线程。irq_thread 如果已经结束，disable 不会有任何副作用；如果还没结束，它会被干净地干掉，cfg_thread 不受影响。

需要注意，disable 在这里针对的是命名块，不是进程对象。如果两个不同的 initial 里出现了同名的块，disable 到底终止哪个，取决于 disable 语句所在的层次语境。工程上我会尽量避免这种歧义，给块起足够独特的名字，或者干脆用下一节讲的进程对象。

3.5 process类：握在手里的线程句柄

SystemVerilog 提供了一套进程对象机制，可以拿到线程自己的句柄，然后做精确控制。这是现代验证代码里更推荐的方式。

process p; initial begin fork begin p = process::self(); forever begin #10; $display("[%0t] worker alive", $time); end end join_none #50; if (p.status != process::KILLED) begin p.kill(); end $display("[%0t] worker killed", $time); end

这段代码里，后台线程在内部通过 process::self() 拿到自己的句柄，赋值给外面声明的 p。父线程等了 50 个时间单位后，调用 p.kill() 把它终止。process::self() 必须在要获取句柄的线程内部调用，如果在父线程里调用，拿到的就是父线程自己的句柄，这一点非常容易搞错。

process 类的 status() 方法可以返回线程的当前状态，比较有用的几个值是 FINISHED、RUNNING、WAITING、KILLED。kill() 之前先检查一下状态，是为了避免对已经结束的线程重复操作。这种做法比 disable fork 精细得多，也更适合在 class 组件里做线程生命周期管理。

4. 循环变量与automatic：十个fork join_none有九个死在这里

4.1 捕获的是变量还是值：经典打印翻车

几乎所有学 SV 的人都写过这个代码：

initial begin for (int i = 0; i < 4; i++) begin fork $display("Thread %0d", i); join_none end end

本来预期打印 Thread 0、Thread 1、Thread 2、Thread 3，实际运行起来，你看到的可能是一堆 Thread 4，或者是 Thread 2、Thread 3、Thread 4 这种乱七八糟的组合。

原因是：for 循环变量 i 在迭代之间共享同一个存储位置。fork/join_none 只是把执行代码的线程放到后台，它并不是在 fork 那一刻把 i 的值快照进来。等到这些子线程真正被调度执行时，循环可能早就跑完了，i 已经是 4。线程看到的是变量，不是创建那一刻的值。

4.2 automatic变量快照：每次迭代一份新存储

解决办法是在循环内部声明一个 automatic 变量，把当前值抄一份，再让线程去读这个副本。

initial begin for (int i = 0; i < 4; i++) begin automatic int idx = i; fork $display("Thread %0d", idx); join_none end end

automatic 变量的特点是，每次进入声明它的作用域时，都会创建一份独立的存储。循环每次迭代进入 begin 块，idx 就有一份属于本次迭代的副本。子线程读到的，是自己那份副本，而不是共享的 i。这个写法是创建动态线程时铁打的标配。

4.3 task里的静态变量串扰同样致命

循环变量只是最显眼的一处。另一个极其常见的坑是：task 或 function 内部声明的局部变量，默认情况下是静态存储，所有并发线程调用同一个 task 时，访问的是同一份变量。

task do_print(); string name; name = get_name(); // 假设不同线程会传入不同的名字 #100; $display("%s", name); endtask

如果 thread A 和 thread B 同时调用 do_print，它们会互相覆盖 name。A 刚把名字写进去，B 后脚就把它改掉了。等到 100 个时间单位后打印时，A 和 B 看到的可能是同一个名字。这个问题的本质和循环变量完全一样：静态共享存储。

解决办法有两种。一是把 task 声明成 automatic task，这样 task 内的所有局部变量都自动变成每次调用独立一份；二是显式把变量声明为 automatic。我自己的习惯是，新建 task 时一律用 automatic task，只有明确需要在线程间共享的静态变量，才用特殊标记。

4.4 哪些场景需要主动写automatic

总结一下需要主动用 automatic 的场景：循环里用 fork/join_none 创建多份线程并且依赖循环变量时；并发线程会调用同一个 task 且 task 内有跟线程相关的局部数据时；以及任何你不确定变量会被多少线程访问、但希望它保持独立的情况。

反过来，class 成员变量不要机械套 automatic。class 本身是动态对象，它的成员变量的生命周期和对象绑定，跟线程里的局部变量是两码事。该用类成员的地方，正常声明就行。

5. class中的线程管理：测试环境里线程泄漏的真相

5.1 在class里启动线程的标准姿势

面向对象写测试环境后，我们很少直接在 initial 里堆 fork。更常见的做法是：class 提供一个启动任务，内部用 fork/join_none 把长任务挂到后台。

class transaction_generator; task start(); fork generate_loop(); join_none endtask task generate_loop(); forever begin #10; // 产生并发送一笔事务 end endtask endclass

start() 调用后立即返回，generate_loop 在后台线程里跑。好处是，测试主流程可以按照自己的节奏启动多个组件，而不需要一个个等它们先跑起来。

5.2 线程泄漏是如何发生的

线程泄漏这个词听起来抽象，其实现象非常具体：测试主流程已经跑完了，你期望仿真结束，但仿真器就是退不出去，或者明明把所有对象都置空了，后台还在疯狂打印。

原因就是那个 forever 线程。class 对象被释放，只意味着你失去了对对象的引用，但线程本身是仿真内核的调度单位，它和对象没有生命周期绑定。只要那个 forever 循环还在跑，它就会不断产生新的延时事件，仿真事件队列永远不会空，仿真就永远结束不了。

5.3 用事件协作关闭线程：比kill安全

正确的关闭方式是在 class 内部提供一个停止任务，用事件告诉线程"该收工了"，让线程自己从循环里干净地退出来。

class driver; event stop_ev; task run(); fork begin while (1) begin if (stop_ev.triggered) break; drive_one_pkt(); #10; end end join_none endtask task stop(); -> stop_ev; endtask endclass

stop() 被调用后，事件触发，run 循环在下一轮检查到 stop_ev.triggered，退出循环，线程自然结束。这比直接调用 kill() 安全，因为线程有机会做完当前这笔事务的收尾，不会在驱动总线的半中间突然消失，留下一个悬空的时序状态。

5.4 测试环境退出的标准动作：stop后wait fork

拿到线程句柄后直接用 kill() 也不是不行，但除非你非常确定线程当前停在哪个位置，否则我仍然建议事件协作。工程里标准的收尾动作是：

initial begin env = new(); env.start(); // 跑若干测试用例 env.stop(); wait fork; end

stop 让所有循环线程都收到退出信号，wait fork 保证它们真正退出、把收尾动作做完，然后仿真才允许自然结束。这个模式组合了线程控制和自动变量之外的另一块核心拼图——线程间协调。如果你之前已经会用事件做同步，这个套路就是水到渠成的事。

6. 调试线程Bug的思路：仿真退不出来和提前跑完怎么查

6.1 现象一：仿真卡死，时间不再前进

仿真的时间戳停在一个点上不动，事件队列里剩下的一大堆线程都在等永远等不到的条件。最常见的两类根因：一是某个线程在 wait 一个不会被触发的事件，二是 join 在等一个后台线程，而那个线程因为饥饿或者死循环一直不结束。

排查思路是先定位到底是哪个线程卡住了。我的习惯是在关键任务的入口和出口打带时间的打印：

$display("[%0t] %m enter task reset_dut", $time);

%m 会打印当前模块实例和任务的层次路径，配合时间戳，能很快看出哪些任务进去了但没出来。如果所有该打印的出口都打了，那就把注意力放在事件和信号上，查那个 wait 条件是否真的有人负责改变。

6.2 现象二：仿真提前结束，后台线程没跑完

这个和上一个正好相反。你明明用 join_none 放了一个线程出去，它还有活要干，但仿真器提前宣布结束，后台线程被强行终止。

原因是：仿真器决定结束的条件是"没有更多事件需要调度"。如果主线程跑完了，剩下一堆等信号的线程没有产生任何未来事件，仿真就会结束。不是你想让线程活着它就能活着，调度器只认事件。

解决办法很朴素：主流程不要裸奔结束，最后加一个 wait fork，或者显式等待一个收尾事件。把期望的后台线程完成时间放到事件队列里，仿真不会提前退出。

6.3 现象三：变量被多个线程改得乱七八糟

某几个信号或变量的值飘忽不定，换个随机种子就变更扭曲的方向。第一反应不要怀疑 DUT，先查验证代码里的共享静态变量。

排查时在变量被写入的地方加打印，打印里带上 %m 和线程标识。如果可以，用 process::self() 拿到线程句柄，把句柄字符串打出来，看看到底是谁在改。大概率最后会定位到某个 task 里的局部变量没有 automatic，或者循环里的 fork/join_none 还在共享同一个循环索引。

6.4 一张排查对照表

6.5 打印优先于断点的调试经验

在线程相关的代码里，断点反而不如打印好用。因为线程是并发的，你停住一个线程，其他线程还在跑，你用调试器看到的现场很可能已经和问题时刻对不上了。我更推荐先把带时间戳、带层次、带线程标识的打印埋好，跑一轮收集信息，再决定在哪里加断点。

还有一个小技巧：调试时如果一堆 forever 线程让仿真停不下来，先不要逐个去断，而是临时把 forever 改成可退出循环，用一个最大迭代次数或者事件来控制，先让仿真能干净结束，再做进一步排查。否则你一边加断点，一边还有几十个线程在刷屏，很容易把自己绕进去。

最后再说点个人的体会。线程控制是 SV 验证从"会写"到"能设计"的一道坎。我自己的习惯是，新建 task 一律用 automatic，需要跨线程共享的变量再专门声明成静态或者类成员。这么多年下来，因为这个习惯，少踩了不知道多少次变量共享的坑。如果你现在正被 fork/join 三兄弟绕得头晕，不用急，把本章的代码敲一遍，再故意制造几次线程泄漏和误杀，亲身感受一下那些坑，这个知识点就算是真长在你身上了。