01

60 秒回答模板

reference model 是 scoreboard 判断 DUT 对错的 oracle，最重要的是独立性和规格一致性。如果直接由同一设计人员按同一思路写，很容易把设计里的误解、边界遗漏或简化假设复制到 model 里，DUT 和 model 一起错，scoreboard 也比不出来。更合理的做法是验证人员基于 spec、架构文档和协议独立实现，必要时和设计评审接口和模糊点，但不要照抄 RTL 或共享核心算法代码。设计人员可以提供规格解释、算法说明和 review，验证人员负责把它转成独立可检查模型，并用 directed case、随机激励和覆盖率验证模型本身。

考点 独立 oracle
难度 真实面经题
回答目标 说明 reference model 的独立性、验证与设计职责边界、设计参与方式和模型自身质量保障。
02

深入解析

01

reference model 是 oracle

scoreboard 用 reference model 的输出判断 DUT 行为是否正确。如果 oracle 本身和 DUT 共享同一错误，验证环境会给出假通过，这是非常危险的。

02

独立性防止共因失效

设计人员写 RTL 时形成的理解、假设和 corner 处理可能被带入 model。独立实现能从不同角度解读 spec，提升发现歧义和错误的概率。

03

不是拒绝设计参与

设计人员应参与规格澄清、算法解释和模型评审，但不应直接复制 RTL 思路或代码。验证需要保留独立判断，并记录 spec 冲突和假设。

04

模型也要验证

reference model 需要单元测试、边界用例和与已知结果比对。复杂算法可和高层模型或文档示例互相校验，避免模型自身成为新的错误源。

03

易错点

  • 认为设计最懂功能，所以 model 让设计写一定最可靠。
  • reference model 直接照抄 RTL，scoreboard 只能证明两份代码一样。
  • 验证人员不读 spec，只按设计口头描述写模型。
  • model 没有单独测试，出错后误判 DUT。
04

面试官追问

如果算法很复杂，验证人员不会写怎么办？

可以让设计解释算法和规格，或复用经过认证的高层模型，但验证侧仍要独立封装、审查输入输出契约和边界条件。

reference model 和 RTL 可以共享代码吗？

原则上不应共享核心行为代码，否则会产生共因失效。可以共享协议定义、常量或经过评审的规格描述，但行为判断应独立。

怎样证明这个验证写法真的覆盖到了目标场景？

要看断言、功能覆盖、代码覆盖、错误注入和回归日志是否对应题目里的关键路径；如果只是组件能跑起来，但没有覆盖目标状态和异常分支，验证价值是不够的。