有一类bug，RTL没错，仿真全过，硅后功能也正常，但客户用起来就是不对。

追下去，发现是文档里寄存器的bit定义写反了，或者操作时序图少画了一个步骤。客户按文档写的代码，当然跑不通。

这种锅，最后很难说清楚算谁的。

在绝大多数芯片项目里，文档验证的优先级排在最末尾。项目收尾阶段，大家都在赶最后几个bug，文档的事能拖就拖，能对付就对付。

但文档是芯片交付物的一部分，准确性不比RTL低。客户拿到的不是你的仿真环境，不是你的testplan，他们拿到的是芯片加一份datasheet。文档错了，对客户来说就是芯片坏了。

这个逻辑很简单，但很多团队在资源分配上并不这么想。

文档错误长什么样

最常见的是寄存器描述和RTL不一致。复位值写错、字段宽度写错、读写属性标注错误——这三类问题在每个项目里几乎都能找到。

有个真实的场景：某控制寄存器的bit 3，文档写的是”写1触发操作”，RTL实现的是”写0触发”。设计工程师在某次改版时改了逻辑，但忘了更新文档。验证工程师写testcase是对着RTL行为写的，仿真通过了。文档的错误一直到客户集成阶段才暴露。

还有一类更隐蔽——时序图和文字描述不一致。图里画的握手时序和文字说明有出入，读者理解的意思可能完全相反，但两者单独看都说得通。

谁来做文档验证，这个问题本身就是矛盾

现实里，文档通常是设计工程师写的，然后自己检查一遍就发出去了。这种模式从根本上就不可靠——写文档的人和验证文档的人不能是同一个人，因为惯性思维会让人看不见自己的错误。

验证工程师其实是做文档验证最合适的角色。原因很直接：验证工程师对spec的理解要求本来就是独立于设计的，而且在验证过程中本来就在持续对比”文档说的”和”RTL做的”之间有没有差异。

把这个对比过程显式化、系统化，就是文档验证。

问题是这件事现在没有人明确负责，设计说文档是我写的我负责，验证说我验的是功能不是文档，产品说发现问题再改就好了。到最后，客户踩坑了，三方都有理由推责任。

一份错误的datasheet，损害的不只是这一次客户体验，而是客户对整个产品线的信任度。客户被坑过一次，下次拿到新版文档，第一反应是怀疑。这种信任损耗，很难用几个修订版本修复回来。

文档的准确性，本质上是产品质量的外部可见面。RTL对不对，客户感知不到，文档对不对，客户每天都在感知。

所以文档验证这件事，值得在项目计划里给它一个正式的位置，分配真实的人力和时间，而不是让它永远挂在”有空再说”的清单里。

条件允许的话，推动团队建立寄存器模型的单一数据源，从源头上解决RTL和文档不一致的问题——IP-XACT或者SystemRDL都是成熟方案，生成RTL和文档都从同一份定义来，不一致的概率从根本上降低。