—— 为什么 stimulus 要被设计成“可调度对象”？
聚焦 RISC-V / CPU / SoC 验证实践。
所有结论，默认都——得验。
在 UVM 里，Sequencer / Sequence往往是最早被“学会用”、却最晚被真正理解的一部分。
很多工程师对它的理解停留在：
“Sequence 生成 transaction，Sequencer 发给 driver。”
但当你开始读源码、或者维护一个复杂 SoC 级验证环境时，会慢慢意识到：
UVM 把 stimulus 设计成“可调度对象”，不是为了写法优雅，而是为了防止主动侧失控。
一、一个被忽略的事实：Stimulus 本身就是“系统资源”
我们先跳出 UVM，看一个更底层的问题：
在 SoC 级验证中，stimulus 真的是“随便发”的东西吗？
答案显然是否定的。
在真实系统里：
总线有仲裁
端口有优先级
通道有带宽限制
不同 master 之间存在竞争关系
Stimulus 本身，就是对系统资源的争抢行为。
如果 stimulus 只是：
driver 里随便
forktest 里直接
send_item
那你得到的并不是“更自由”，而是：
不可控的并发 + 不可复现的时序 + 架构层级的混乱。
二、为什么 UVM 不让 Sequence 直接连 Driver？
这是理解 sequencer 的第一把钥匙。
如果只从“功能”看，完全可以设计成：
sequence → driver但 UVM 偏偏在中间插了一个sequencer，而且职责还不轻。
从源码角度看，sequencer 的真实角色是：
stimulus 的调度中心，而不是数据通道。
它做的事情包括：
多 sequence 仲裁
优先级管理
phase 绑定
生命周期管理
与 driver 的同步协议
这已经非常接近一个微型调度器（scheduler）。
三、Sequence 不是“脚本”，而是“可调度行为单元”
这是很多人长期误解的地方。
在 UVM 的设计里：
sequence ≠ testcase 脚本
sequence ≠ stimulus 生成函数
而是：
一个“可以被挂起、恢复、仲裁、复用”的行为对象。
你从源码里可以清楚看到：
sequence 有状态
sequence 受 sequencer 控制
sequence 不拥有执行权
这本质上是一个非常典型的软件工程思想：
把“做什么”与“什么时候做”彻底分离。
四、为什么要支持多个 Sequence 并行？
从源码和设计目标看，UVM 明确假设一件事：
复杂系统里，stimulus 一定是多源并发的。
典型场景包括：
多个 master 同时发起 transaction
background traffic + directed test
功能测试 + stress 测试叠加
如果没有 sequencer 的仲裁机制，这些场景要么：
写不出来
要么全靠人工约定，极易失控
Sequencer 的存在，是在主动侧引入“秩序”。
五、Virtual Sequence 的真实意义：跨 agent 的“调度编排层”
很多人觉得 virtual sequence：
抽象
难调
写起来不直观
但它解决的，其实是一个非常现实的问题：
谁来负责“多个 agent 的协同行为”？
答案是：
不能是 driver
不能是 env
也不能是 test 里的零散代码
于是，UVM 给了一个明确的位置：
Virtual Sequence = 跨 agent 的 stimulus 编排层
从架构角度看，它非常像：
测试场景的 orchestration layer
而不是底层动作执行者
六、从 Phase 的角度看：Sequence 不是随时都“合法”的
这是 sequence 被设计成对象而不是函数的另一个原因。
Sequence：
可以绑定到 phase
可以被 phase 自动启动 / 停止
可以响应 phase 跳转
这意味着：
Stimulus 被纳入了整个验证生命周期管理。
这在 power / reset / error recovery 场景下尤其重要。
七、为什么很多工程实践“低估了” Sequencer？
现实原因很简单：
在简单环境里，Sequencer 的价值不会显现。
如果：
单 agent
单 sequence
无仲裁
无并发
那 sequencer 看起来确实“多余”。
但一旦进入：
多 master
多协议
多团队协作
Sequencer 往往是：
最后一个还能兜住复杂度的结构性组件。
八、一句话总结
UVM 把 stimulus 设计成“可调度对象”，是为了让主动侧具备“系统级秩序感”。
Sequence：
描述“我要做什么”
Sequencer：
决定“现在轮到谁做”
Driver：
只负责“怎么做”
这三者的分离，是 UVM 在主动侧做出的最重要的一次架构切分。
写在最后
如果你把 sequence 当成：
写 testcase 的工具
driver 的附属品
那 sequencer 永远显得复杂又多余。
但如果你从SoC 并发行为 + 架构演进的角度再看一次，你会发现：
Sequencer 不是为“现在这个 case”设计的，而是为“未来的复杂性”预留的。
