功能验证在设计中的重要性

当一家公司决定研发一款芯片时，起初架构师和几位顶层设计一起创建一些需求、规范文档。

例如各种寄存器、接口、使用手册等等。不管文档是否清晰规范，这些文档就是各个模块设计的起点。模块设计拿着这些起始的需求规格文件，使用RTL建模实现预期的功能。

当然，实际的项目进程一般不会这么直接，很多东西存在变化和迭代。例如需求的变化、上下游模块接口的变化，甚至整个芯片的架构变化等等。

功能验证过程也和设计一样，伴随着各种变化。因为验证就是设计的另一双眼睛，和设计具有同样一个需求起点（理论上）。

很多时候，设计会比验证更早地接触需求，但是有责任的验证需要通过各类检视活动从设计规格中追溯到原始需求，然后再将原始需求作为验证起点。

简单来说，设计工程师需要实现预期的需求（功能、性能、安全性、可靠性等等）， 验证工程师需要确保设计正确地完成了这项工作。

验证工程师可以说是设计的第二双眼睛，理论上两个人可以比一个人看得更加清楚。（但是不排除1+1<2的情况）。

验证工程师和设计工程师并行地开发需求的模型（设计开发RTL模型，验证开发参考模型和checker）。如果实现了真正的并行独立开发，那出错的概率就很小了，但是很多时候验证模型为了和设计RTL模型比对，就会削弱独立性，导致验证模型和设计RTL模型错成一样。

验证工程师和设计工程师，哪个看得更加清楚，因人而异，和职业本身没有绝对的关系。

有时设计会验证自己的设计，甚至选择放弃第2双眼睛（不需要验证）。例如，需求要求实现2+2=4，但是设计理解成2+2=5，并将硬件实现为2+2=5。然后，设计自我验证的参考模型预期依然是2+2=5。这个时候就需要第2双眼睛的方法，另外引入一个验证工程师独立地理解需求，再次理解成2+2=5的概率就很小的，很大概率可以发现这个设计的bug。

真实的芯片项目中，会有多个层级的验证，模块级别EDA、系统级EDA、加速器和FPGA等等。所有人都错的概率几乎为零。

真实项目中的bug来源千奇百怪，可能来自代码编写错误、可能来自需求本身不合理无法实现、可能是系统配合等等原因，甚至可能是工具的bug导致芯片的bug。

审核编辑：刘清