验证方法及周期

验证方法

动态仿真

• 该方式是通过测试序列和激励生成器给入待验设计适当的激励，伴随着仿真时间，进而判断输出是否符合预期。
• 动态仿真需要仿真器来配合这一工作，验证人员也需要查看比较结果和仿真波形，最终来判定测试用例是否通过。
• 按照激励生成方式和检查方式，可以将动态仿真进一步划分为：

1. 定向测试。
2. 随机测试。
3. 参考模型检查。
4. 断言检查。

静态检查

• 与动态仿真相对的是静态检查，其本身不需要仿真、波形激励，通过工具的辅助，验证人员即可以发现设计中存在的问题。
• 静态检查可以细分出更多的种类：语法检查、语义检查、跨时钟域检查、形式验证。

1. 语法检查：绝大多数仿真编译器都会帮助检查语法错误，例如拼写、声明、引用、例化、连接、定义等等常见的语法错误。
2. 语义检查：和语法检查相比，其是在设计可行性上做深入检查的（前提是首先通过了语法检查），语义检查通过专用的工具来协助完成，包括的范围有：常见的设计错误、影响覆盖率收敛的问题、可能会产生X值以及受其影响的设计部分。
   其便捷之处在与，可以在早期发现一些功能实现以外的设计问题，而且也有助于完善设计代码，以便提高有效覆盖率以及RTL与网表的逻辑一致性（例如寄存器未初始化或者固定赋值）。
3. 跨时钟域检查：
   首先是跨时钟域的概念，大多数复杂的设计都拥有不止一个时钟，多个时钟之间也常表现为异步的关系，对于设计中的不同功能模块，如果被不同的时钟驱动，那么就会形成不同的时钟域。
   对于单一时钟域的模块而言，它的设计方式和验证环境都较为简单。拥有多时钟域的硬件，它的跨时钟域的逻辑通讯就需要考虑同步问题了。之所以需要同步是考虑到不同时钟域的信号采样问题，当时钟域A的信号进入时钟域B被采样时，每个周期都会有相对时钟B不同的延迟，这种随机性可能会导致建立时间或者保持时间无法满足，进而导致不可预期的功能失败。
   这种跨时钟域问题无法通过常规的验证方法分析，例如动态仿真，也不能被静态时序分析判断出来，而通过静态的看跨时钟域检查就可以分析这一问题，该方法可以在早期的RTL阶段来识别出跨时钟域的通信电路上面是否有合适的同步处理，可以保证所有的CDC信号都能够得到正确的同步。
4. 形式验证：形式验证分为两种方式：
   等价检查：用来保证两个电路的行为是等价的，可以用来检查不同抽象级的电路是否一致，例如RTL级和网表。
   属性检查：又称为模型检查。电路的行为通过验证语言来描述其属性，随后通过静态方式来证明在所有状态空间下都满足该条件，否则举出反例来证明设计行为不符合属性描述。

虚拟模型

• 虚拟模型即高抽象级的硬件模型，软件模型可以依赖虚拟模型在早期开发并且将反馈交给硬件设计。
• 通过虚拟模型，硬件可以更早地获取软件反馈而对设计进行修改。这种硬件和软件更紧密的协作方式可以贡献更多的优势，例如利用虚拟模型获取的性能数据可以对硬件早期结构提供参考意见，或者判断硬件和软件的协同任务是否可以满足功耗目标。
• 在目前多核的手机移动平台上，一个增长的需求就是将不同的任务合理的分配到多核上面来取得更好的性能，而这种软件层面的评估就可以在虚拟建模阶段完成。
• 目前我们通过多项虚拟建模的技术例如协同设计、协同仿真和验证，试图在早期就可以发现设计缺陷，使得修改这些缺陷可以在相对容易实施的阶段完成。通过这种将设计问题更早期暴露出来的方式来使得芯片可以达到成功流片的目标。

硬件加速

• 动态仿真和静态检查方法各自具有优势，然而它们都不具备的一个优势在于速度。尤其是在SOC的设计体量越来越大的时候，仿真速度就成为制约验证进度的重要障碍。
• 由于仿真速度的限制，一些真实的用例也无法在RTL级仿真很快的呈现结果，这种困难在硅后软件测试发现问题反馈给硬件团队时更加明显，因为通常这意味着硬件团队需要将耗时（仿真时间）很长的软件进行分析，找到可能的问题点，拆分软件场景，进而在硬件仿真上尝试重现问题。仿真速度的限制使得无法通过仿真在早期测试软件，而这一任务一般交给虚拟模型平台或者硬件加速。
• 一般需要等到硬件设计初步稳定，进而将其映射到可配置的硬件加速平台上面，这种方式相比于RTL仿真速度已经有了质的提升。 目前业界主要的硬件加速方式分为两种，即FPGA和专用的模拟器 (emulator）。FPGA主要是为软件开发提供平台，而模拟器则是为了硬件和软件协同验证和整个系统的测试。

效能验证

在移动时代，硬件提升性能的方式主要表现为以下几种：

1. 提升原有处理器性能、存储器空间、数据总线带宽或者采取多核处理方式。
2. 增加额外的协处理单元，或者新的功能模块（例如Video/GPU单元）。
3. 在后端允许的情况下提高工作时钟频率。
4. 提升工艺制程。

随着性能的提升，能耗也会逐步提高，这在过去的PC时代还不是一个显著问题，但是到了移动时代，就越发要求硬件在性能有提升的基础上，同时要考虑能耗是否也可以接受。
针对硅前设计阶段进行效能验证，涉及的流程可分为两个部分：

• 功能验证：主要采用PA (Power Aware）（主要包括有UPF (Unified Power Format)或者CPF (Comment Power Format））方式，通过与仿真器结合，模拟电源域的开关进行设计检查。
• 功耗预测与优化：通过第三方功耗分析工具，结合仿真数据(FSDB/VCD/SAIF)，进行功耗预测，并且给出分析结果。

移动芯片节能（省电）技术是一项全方位的改进流程，从工艺制程、电路、封装到模块设计、SoC设计、系统和应用软件开发等等，整个环节都需要有效利用能量。

性能验证

• 在性能验证中离不开大量的运算或者数据传输。我们之前提到过，硅前RTL验证的瓶颈之一在于仿真速度，而且一旦过了芯片级仿真，这一因素就更进一步放大了。
• 在产品定义过程中，对于系统的运算和数据传输都有要求，如果可以在产品实现阶段尽早地得出一些性能有关数据，，这不但可以帮助提前验证硬件性能是吞满定要求，在进度充许的情况下还可以修改硬件设计完善其性能。
• 这种将性能测试提前的方式也可以使得硅前验证与硅后测试采用一致的测试用例，从而得出可比对的性能数据。
• 性能验证是用来衡量一个系统在特定工作负载下它的响应能力和稳定性，同时性能报告也可以用来分析和优化系统的质量标准例如可靠性和资源使用能力。
• 性能验证是一门实用的计算机科学工程方法，在软件工程测试中分类较多，譬如有负载测试 (load testing)、压力测试(stress testing）、浸泡测试 (soak testing）、尖峰冲击测试 (spike testing)配置测试 (configuration testing)、隔断测试 (isolation testing）等。
• 目前在硅前验证阶段，性能验证还是一个新颖的概念，一方面由于业界对这一测试还没有形成统一标准，另外也是由于性能验证更多地是在衡量指标，而与验证（判断设计是否与功能描述一致）本身的聚焦不太重合。但同时，对一些性能要求严格的硬件设计，我们确实希望在更早期就得出一些数据，而且最好能够赶上给设计做出反馈并加以完善，以此来降低开发成本。

验证周期

具体的验证周期可以分为以下几个阶段：

• RTL0：芯片框架和模块功能定义完成，指定验证的策略。
• RTL1：模块和子系统的功能信号定义完成，定制需要的存储模型。
• RTL2：完成所有模块的设计，以及80%以上的模块和子系统的验证，核心功能全部完成验证。
• RTL3：完成芯片系统的连线集成和验证，覆盖所有的功能验证点。
• GLS：完成门级网表的验证。
• TO：回顾验证的各项检查清单，最终流片。

在每个阶段需要做的具体任务如下：

1. RTL0

2. RTL1

3. RTL2

4. RTL3

5. GLS

6. TO