如果你在设计一款计算器，除了加减乘除的基本功能以外，在科学计算层面上，你需要注意到三角函数、取模、阶乘、幂运算、开根号等等复杂运算。

如果你在设计一款处理器，你需要考虑将其拆分成为运算器（算术逻辑运算单元，ALU，Arithmetic Logic Unit）和高速缓冲存储器（Cache）及实现它们之间联系的数据（Data）、控制及状态的总线（Bus）。

如果你在设计一款系统集成芯片(SoC, System-on-Chip)，那么它可能包括的子系统包括有处理器，片上网络(NoC, Network-on-Chip)，存储器，I/O控制器（多种类，例如USB，PCIe，I2C, I2S）等等。

你会发现，随着系统集成度的提高，系统自身的复杂性也在随之增加，而且结合实际工程项目来看，系统复杂度的提高对于功能验证的要求是首当其冲的。由于功能验证在芯片全流程中占据关键位置，对于一名验证工程师而言，他需要充分理解系统验证的全过程，这个过程就是功能验证的生命周期。功能验证在项目的延续中（目前的芯片之所以迭代周期越来越短，就是采取剪裁以前项目来做快速的芯片设计流程），可以得到不断的提升；同时功能验证处于所在项目中时，也需要考虑如何完善验证流程和环境。

那么我们本文将带大家从芯片完整开发流程进入，来检视芯片验证在整个项目中的地位和作用。

一般来讲，新的芯片项目都是首先从市场人员与目标客户沟通开始的。这中间，市场人员会收集客户对于芯片的要求（主要包括功能、尺寸、功耗、性能），这些指标会被记录在设计结构和产品文档中去。随后，客户关心的系统层面的功能要求会被系统设计人员按照功能进一步划分为各个独立的子系统模块，这些子系统如果本身过于庞大，也会被进一步划分为功能模块，直到被划分的尺寸可以被小的设计团队进行硬件设计。

在这中间，如果硬件设计人员一般会按照芯片的功能模块划分来分成不同的功能小组，同时系统设计人员的数目也会随着系统复杂程度的升高而增加。在硬件设计过程中，硬件设计工程师会将具体的功能描述文本通过逻辑翻译成为硬件描述语言(HDL，Hardware Description Language)，目前使用广泛的HDL语言VHDL和Verilog均被各个大的EDA(Electornic Design Automation)公司支持。同时，由于SystemVerilog语言本身具有Verilog的语言属性和在此之上添加的硬件设计语言的额外属性，SystemVerilog的部分子集也被归纳到了可以用来综合的硬件设计语言当中。

当细分的合适大小模块初步完成RTL级（寄存器级别，Register Transfer Level）的硬件描述语言文件之后，功能验证人员会在这个时候做几项工作来检查硬件设计：

1. HDL硬件描述文件是否正确按照功能描述文档去实施了？

2. 硬件设计人员是否有遗漏掉的额外情况（corner case）？

3. 硬件设计是否足够稳定来处理一些错误的情况（error response）？

实际项目中，硬件设计人员和功能验证人员的合作是紧密的，这具体表现在了：

1. 当系统设计团队将功能需求翻译为功能描述以后，硬件设计团队和功能验证团队需要围绕着功能描述文档分别展开硬件设计和功能验证工作。

2. 硬件设计团队在初步翻译出硬件描述文件以后，功能验证团队需要将硬件描述文件搭建验证环境展开各个功能点的验证。

3. 当验证环境测试出实际结果与预期结果不符合的情况下可以分为

1. 如果硬件设计与功能描述文档存在明显不符时，功能验证人员会报告出存在的设计缺陷，同时硬件设计人员会修复硬件描述文件，这样从验证到设计再转回到验证即完成一个缺陷检测和修正周期。

2. 当实际结果和预期结果有模糊的边界时（例如时序问题，状态机跳转问题），验证人员和设计人员会就同一份功能描述文件的理解存在分歧，此时他们会做初步的讨论，来确定哪一方的理解有偏差。当讨论依旧无法判定理解分歧的时候，双方最终会找到系统设计人员进行“裁决”，来明确本来的系统设计思想，进而统一双方对功能描述的理解。

因此，硬件设计的完成度和缺陷率会在设计人员和验证人员的迭代周期中不断得到完善，最终达到目标。关于功能验证目标的定义，我们会在以后的文章“验证的任务和目标”详细讲述。

当功能验证完成以后，后端人员会将RTL文件综合生成门级网表文件（gate netlist），同时也会为了目标速度来进行布局布线，最终可以使得门级电路可以在设定的时钟频率上面工作。在后端的各种流程当中，与前端验证人员联系紧密的当属标准延时格式（SDF，Standard Delay Format）文件，该文件会包含门级网表中各个门单元之间的延时情况用来准确描述实际电路。

所以，对于功能验证流程而言，我们所说的仿真可以根据项目的实施流程将其划分为前端仿真和后端仿真：

1. 前端仿真指的是进行RTL仿真，在这种仿真当中是没有真实延时情况的。对于一个寄存器（register），它的输出端（Q port）相对它的时钟输入端（Clk port）的延时为零延时（delta delay）。

2. 后端仿真指的是进行Gate仿真。在实际项目中，由于后端综合进而产生SDF文件本身需要不断迭代周期，我们进一步又将门级仿真划分为零延时仿真和SDF仿真。

1. 零延时仿真是只有门级网表参与仿真，没有SDF文件来具体反向标注（back annotation）门级延时情况，所以门之间的延时仍然为零延时，这个时候门级零延时仿真与RTL仿真的区别仅在于前者是后者的逻辑映射，从寄存器级别到门级的逻辑转译，这一步是由后端的综合工具（synthesis tooling）完成的。

2. 当后端随后产生出SDF文件时，我们会将门级网表反向标注上SDF文件中包含的每一条门单元之间路径的延时，最终进行有真正延时电路的仿真。

从验证完整性而言，前端仿真和后端仿真均需要在项目中实施，而它们侧重的目标也有不同。前端仿真是为了检测出功能逻辑的缺陷，而后端仿真是为了检测出实际门级电路中由于延时问题可能导致采样失败进而产生的功能缺陷。也因此验证人员不能将前端仿真的功能缺陷检测任务下移到后端仿真阶段，因为就效率问题而言，前端仿真要显著高于后端仿真；同时，后端仿真之所以不能忽略是因为它可以协助后端人员来测试出实际生成电路中是否有时序不满足的问题。

当完成后端仿真以后，我们会将后端生成的标准格式文件最终交付给芯片生产商进行流片（tape out）。从上面的描述来看，这是一个完整的芯片从定义、分块、设计、验证和后端的硅前（pre-silicon）流程，同时芯片在流片以后所面临的硅后流程（post-silicon）也是一个完整的周期，这其中包括了组件测试，驱动，系统固件和应用软件编写等等。由于功能验证处在硅前流程当中，我们在这里主要阐述该流程，同时，我们也将一些相对独立的部分略去（这并不代表它们不重要），例如可测试性设计（DFT，Design for Test）。

至此，芯片的硅前流程就结束了。考虑到验证人员同设计人员在实际工作中的密切结合，我们举出一个生活中的例子来情景演绎出设计验证流程是如何进行的。

我女儿蒙蒙三岁了，小姑娘喜欢吃糖，她妈妈每次碰到她索要糖果也是没有什么好办法。这个时候，她的工程师爸爸给出了一个流程图来应对蒙蒙要吃糖的情况。

这张图画了出来给蒙妈看了一下，蒙妈看过以后笑着讲，你先试试看你这一套有没有用吧。

等到小家伙过了一会儿又来要糖的时候，我问她，你是不是之前刚吃过啊？蒙蒙点了点头，说是。我接着问，可是还需要等4个小时才可以吃下一颗啊。蒙蒙这时候不懂4个小时是多久，只是她一听到“小时”两个字就大约知道应该会挺久的，要知道她可等不了那么久。于是乎，不属于下面这个决策流程中的一幕发生了，小家伙一开始央求我，后来觉着不灵就索性哭了。好吧，工程师爸爸的流程设计存在缺陷，于是，就把蒙蒙揽到怀里，给她讲了一个故事。蒙蒙听完故事，满意地又去别的地方玩儿了，仿佛忘了刚才还在因为一颗糖哭得一把眼泪。看到这招管用，于是我就把这个流程图该成后来的样子，经过亲身经历，又交给蒙妈看了看，这次蒙妈点了点头，笑着说，知道孩子不好带了吧……

是啊，即使作为一名有经验的设计人员（Rocker），在面对新问题的时候（蒙蒙要吃糖），也不能对自己的设计太过自信，只有经过验证人员（蒙蒙）充分验证的设计才是经得起时间考验的。说到这里，看着我才修改的这张流程图，我还是自信不起来，因为晓得讲故事的套路说不定哪天就不管用了。如果到了那个时候，新的设计缺陷一旦暴露出来，那设计人员还是得再进一步完善设计，确保它的功能良好啊。

所以讲，我和蒙蒙也是紧密协作的，就同设计人员和验证人员一样，当设计发生了问题，我不能生气，不能太过自信，我需要坐下来同蒙蒙交谈，找出缺陷在什么地方，再将缺陷补上，下一次再交给蒙蒙，直到蒙蒙最终可以不用哭也能开心地吃到糖，同时我也不会因为她频繁吃糖而担心她的牙齿会坏掉。所以从这个角度来看，设计人员和验证人员能够在一起，是上辈子就修来的福分啊，不就像我跟蒙蒙一样吗？

下一篇文章，我们将会来谈一谈验证的处境。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。