提升验证效率一些事项

1、验证环境的注意事项

       验平台应该像RTL一样（可综合）。

       经验通常可以避免犯错，经验也可以在编码指南中起到作用；这些指南有助于确保所开发的代码的一致性。如果没有这些编码指南，许多常见的错误通常会花费验证团队的不少时间，这有时会转化为压力。

       如今，这些设计规模正变得越来越大。许多项目通常通过使用仿真或硬件加速器来帮助实现项目上的回归所需的吞吐量。这种方法通常意味着验证平台的一部分实际上留在模拟器或加速器中。仿真或加速活动开始于项目中间的某个地方，如果在开发周期的早期得到注意，那么就可以尽量减少将验证平台移植到加速器时所涉及的问题。

   验证平台如果移植到加速器上，部分代码在服务器上运行，部分在加速器上运行，两者之间的通信开销非常大，最终导致加速器起不到加速效果，因此在设计验证平台时尽量考虑到后续移植加速器的问题，减少服务器和加速器的通信开销（共享缓存的方式、全部可综合），从而达到加速的效果。

2、三态总线与其处理。

当多驱动驱动总线时，验证环境就需要使用三态总线，一个驱动驱动总线其他总线置为高阻态，在验证平台一侧有一个单独处理模块处理三态总线，保证总线不会出现冲突。可以在驱动中加一些内部信号监控驱动方便debug。

3、处理内部信号

内部信号是验证环境中的“必要的罪恶”之一。有时，设备的I/O引脚可能无法提供足够的信息，以允许验证平台执行某些任务。在这种情况下，可能需要访问一些内部信号来简化开发验证平台的任务。

确保所有内部信号都维护在验证环境中的一个文件或固定位置中；同时需要考虑这些内部信号是否是必须的，以及在不同层次平台中移植问题（可以一个地方采用宏的方式）；另外需要考虑引用的内部信号不会被综合工具优化掉（尽量使用reg、或module的port口，因为在综合和后端实现是可以采用保留Hier）。

尽量不要force信号，除非实在是不可避免的情况下（force 尽量采用宏包含位置定位信息方便项目组后期review，亦可以采用加仿真选项把force信息汇总需要周期性的review其必要性）

4、环境考虑因素

环境要易于使用：易用是验证环境的一个主要考虑因素，开发工程师可能会使用验证环境，并且开发用例和开发环境可能不是同一个人。

如果验证环境使用不容易的话，环境很大且很复杂，那么每次设计人员都会向验证工程师求助，以便在环境中运行测试。那么验证工程师不仅需要维护一个复杂的环境，而且还要有效地指导设计者运行测试，将会花费很多时间，最终影响验证效率和质量。

如果环境中使用非标准的调试信息或广泛使用宏的话。会使环境的调试变得非常困难和复杂；这对验证环境的owner是很不利，因为任何修改都必须owner本人进行，别人有时很难处理。

确保环境可以使用RTL开发的工具进行调试：环境是RTL和平台的组合，开发出的环境是为了验证RTL的，环境也是存在bug的，所以必须能够快速识别出在RTL或验证环境中存在的错误，平台必须考虑自身的诊断手段。

用例在测试失败时，必须要捕获一些基本数据，以方便定位；具体数据如下：

1.仿真使用的种子号；

2.仿真的命令行选项；

3.仿真log

4.仿真debug信息和监控信息

当测试用例失败时，调试过程通常从解析log文件开始，以查看是否存在任何可以指示故障点的相关线索。有时，将所有合适的数据记录到log文件中变得不可能和困难，当仿真时间很长，而生成的日志文件也很大。在这种情况下，尽量使用uvm的打印等级进行log打印。

   确保环境同时支持RTL和平台的独立调试：验证平台和rtl一样，都是代码，因此一定存在bug，因此需要支持平台独立调试，可以采用一些定向用例激发平台某些特性，已实现平台自验证。

   确保可以dump波形：dump波形的大小需要考虑，同时考虑dump的灵活性。

   用例优先级问题：时间一直是验证比较关注的问题，如果TO时间优于验证时间的话，就需要考虑优先测试高优先级功能。

   确保测试是自检的：有几种方法可以测试验证用例是否确实创建了它应该创建的场景，以及响应是否适当。最常见的方法：

1.目测：直观地查看测试结果，以确定测试是否确实完成了其目标

2.输出与期望输出比较。

人工检查一定存在犯错的，因此平台尽量做到自动化比对，使用机器的程序性检查来避免人为错误。

    编译仿真中warning和error必须正确识别和解决：优先解决log中的所有warning和error

    开发平台需要同时考虑前仿和后仿的适用性：验证分为前仿和后仿，前期阶段主要是RTL仿真，RTL仿真结束后95%网表之后就会考虑网表的仿真事宜，因此在创建子系统或系统级平台是需要同步考虑平台后仿时需要变更的地方，以减轻后仿平台的debug时间。

5、寄存器验证

使用uvm的寄存器模型进行验证平台搭建，不同层次的验证平台下用例移植会很方便，使用统一脚本进行寄存器模型生成和统一脚本进行寄存器模型集成，可以进行快速验证，加速寄存器相关验证。

6、时钟处理

创建参数化的时钟module，可以生成带skew、jitter的时钟，项目组使用统一的时钟产生模块（考虑频率时间截位等操作影响，设置合适timescale），时钟的产生尽量在验证一开始进行波形确认。

7、驱动设计（driver设计）

Driver必须覆盖接口的所有信号。

一个驱动程序必须功能单一

驱动程序尽量模块化

驱动程序仅驱动边界信号，不驱动内部信号。

驱动输入信号仅在需要的时候进行驱动，不能长时间保持，以避免掩盖一些错误（常见在val有效驱动无效时恢复不定态）

可以从某个中心位置禁用driver（采用全局变量或cfg_db机制）

Check程序和driver程序不要放在一个文件中（checker和driver使用相同信号情况下，为节约时间很可能会把checker和driver代码放在一个文件中进行维护）对后续移植可能造成一定困难（单一文件单一功能）

8、设计调试

调试需要花费大量的时间；

找到问题根因并消除掉是很重要的。（bug系统分类，以及闭环）

在debug之前先确认和上次运行测试哪些存在变化，如果第一次编写测试并针对RTL运行，那么问题可能出现在任何地方。这构成了一个重大的挑战。许多人倾向于通过使用某种适合当前情况的算法来对问题进行分类。

理解正在测试的场景，将其进行分类，以消除以下广泛类别的问题

自从上次测试运行以来，发生了什么变化？

已开发的测试代码

任何类似的未决错误。

如果代码未被测试，则为RTL本身。

环境问题

不可重复的问题

等等。这些想法是为了快速确定一些已知的问题是否已经存在，或者是否出现了一个新的问题。识别问题的常见方法通常是从查看日志文件以寻找是否存在问题的明显迹象开始。任何编写良好的环境都将有由详细级别控制的详细日志记录。在设计中嵌入的失败的断言有助于快速识别问题。

平台考虑错误类别和错误位置定位（uvm已支持）

调试级别（开发调试信息进行级别分类，方便在不同阶段进行不同级别的调试）

9、profile分析

根据profile report检查仿真时间消耗在哪些地方，尽量精简平台消耗的时间进行平台优化（内存也是一个关注要素）。

10、回归管理

回归是每个验证工程师的必要工作，回归是周期性进行，可以使用脚本或jenkins实现定时启动回归操作，同时回归也需要在组内进行交叉回归测试，以防止个人长时间回归出现倦怠（验证平台尽量做到全自动化），对随机化验证一定要保证有covergroup进行测量随机激励的是否真正cover到，回归结果需要定期发送到相关人（开发工程师、项目经理、验证经理、自己）的邮箱。

1.再次回归前必须处理完上次回归的全部错误。

2.不要对某些特性推迟验证（推迟的特性可能会影响验证平台和用例）

3.回归时关闭不必要的打印、debug等级、波形dump可以加速仿真速度也可以节省磁盘空间。