验证工程师和设计工程师读同一份 spec，但脑子里想的东西往往是不同的。

设计工程师在想”怎么实现”，验证工程师在想”哪里会出错”。

但有一类问题，是两边都容易漏掉的：spec 没有明确写出来、但实际上隐含了某种假设的行为。

隐含假设从哪里来

设计工程师在写 RTL 的时候，会做大量的隐式假设。这些假设有的来自常识，有的来自”显而易见”的判断，有的则是因为 spec 写得不够细，自己脑补填进去的。

这些假设通常不会出现在 spec 里，但会体现在 RTL 的实现上。

几个典型场景：

• 顺序假设
  ：设计工程师假设某两个信号一定是先 A 再 B 的顺序到达，于是只处理了这种顺序，没有处理反过来的情况。
• 互斥假设
  ：设计工程师假设两个请求不会同时到来，所以没有设计仲裁逻辑，同时到达时行为未定义。
• 初始状态假设
  ：设计工程师假设某个寄存器在使用前一定会被初始化，但实际使用中没有强制保证。

场景：阅读一个协议解析模块的 spec，发现里面描述了正常包的处理，但对”包长度字段为 0”的情况只字未提。这几乎可以确定设计工程师对这种情况有一个隐含假设（”不会出现”）。专门针对这种情况补一条用例，大概率能找到 bug。

从设计工程师的视角读 spec

读 spec 的时候，要同时站在两个角度：你自己是验证工程师，但你需要猜测设计工程师当时在想什么。

他认为理所当然的地方，就是验证要重点覆盖的地方。他没有描述的场景，正是用例最需要去触达的地方。

这需要和设计工程师多沟通。不要只在发现 bug 之后才沟通，在写用例之前就去聊”这个模块你有什么假设””这个信号有没有可能同时有效”，这类问题的答案，直接决定了你能不能把最有价值的用例写出来。