VCS仿真下SystemVerilog线程控制：不靠猜，靠懂
你有没有遇到过这样的场景？
一个UVM test在VCS里跑得稳如泰山，换到Questa就死锁；fork/join_any明明该在10ns返回，却卡在15ns才唤醒；disable写了，波形上看线程确实停了，但$display还在打印——仿佛它没听见；
又或者，wait (valid && data)在AXI monitor里偶尔“失明”，明明信号变了却不触发……
这些不是bug，也不是环境问题。它们是SystemVerilog线程模型与VCS工程实现之间那层薄而关键的膜被捅破时发出的响声。
而这张膜，恰恰是大多数验证工程师从未真正掀开看过的部分。
先说清楚：VCS不是“执行LRM”的翻译器，而是带调度引擎的编译器
很多工程师潜意识里把VCS当成一个“忠实执行SystemVerilog语法”的黑盒——写对了语法，就该有对应行为。但现实是：VCS在编译阶段就重写了你的线程逻辑。
它不做解释性执行，而是：
- 把fork块编译成静态调度图（SSG）节点，每个节点带优先级、依赖关系和资源标签；
- 把wait表达式拆解为信号敏感列表（sensitive list）+ 评估函数指针，并决定是否启用“零延迟合并”或“保守重估”；
- 把disable编译成带中断点标记的跳转指令，而非立即kill——就像CPU不会在一条指令中间断电，VCS也不会在@(posedge clk)的采样沿上强行撕裂线程。
所以，谈VCS下的线程控制，本质是在谈：如何与它的编译器对话，而不是跟语言手册吵架。
fork/join：别只记语法，要看它怎么“画图”
fork/join三兄弟（join/join_any/join_none）常被当成同步开关，但在VCS里，它们首先是调度图生成指令。
关键事实，不是建议：
fork ... join→ 编译器生成一个汇聚节点（join node），所有子线程必须到达此节点才能释放父线程。若任一子线程卡在@(negedge rst_n)，整个图就挂起——VCS不会绕过它。fork ... join_any→ 生成首个完成即触发的分支出口（first-exit edge）。但注意：这个“完成”指的是线程自然退出，不是被disable中断。VCS中，disable后的线程状态是DISABLED，不算DONE，所以join_any不会因此返回。fork ..
