学习记录28（验证执行）

1.冒烟测试的目的
确认 RTL 代码和测试平台（TB）没有语法错误，且环境能够基本运行起来。
通过APB/AXI总线连接DUT内寄存器，控制寄存器的读写，输入数据并能正确读出，保证数据通路的正常。
验证DUT的复位引脚能正常拉高拉低。状态机处于初始状态。
验证时钟信号能正常反转，并能驱动内部的逻辑。

2.冒烟测试之后是什么流程

注意：冒烟测试在测试之前的数据transaction等一定是准备好的，在冒烟测试跑通之后就要根据验证计划来写测试用例。测试用例如果有问题要对验证环境/case以及设计问题进行逐一排查，这一步也就是调试bug。最后一步就是变换随机种子对已经完善的用例，也就是回归测试。

3.常见的测试用例

• 系统验证用例：基于C的测试用例，基于C&UVM的测试用例，基于HVL的测试用例
• 子系统/模块验证：基于UVM的测试用例、只要子系统含有core就能用c来写测试用例

4.基于C的测试用例

• c语言写好程序编译得到可执行二进制文件，
• 将二进制文件加载到DUT的CPU memory中
• 在DUT上电复位后，CPU从存储器中读取二进制代码（主要是指令和数据）

5.回归测试

• 在找bug的过程中,缺陷被发现，RTL/TB代码也有可能不断更新，这时候不仅要跑原来已经跑过的测试用例来验证修改之后的设计没有引入新的错误或者修改导致其他功能产生错误，同时也要通过随机种子寻找新的bug。
• 随机验证每次产生的仿真激励，会让每次仿真都会对覆盖率有一定的贡献，但是到验证后期可能也会出现多次测试不涨覆盖率的现象，这属于正常。

芯片级更加复杂，需要考虑回归流程、质量、效率等问题，上述可能不大适用。在芯片级（SoC级）仿真中，为了缩短测试时间，可以采取以下策略加速启动过程：
策略：

• 长测试切成小测试：一个验证多个功能的序列切成多个小的序列来分别测试不同功能，这样多个用例可以实现并行提交测试，避免耗时过长，且也容易debug。
• 快速跳转到特定状态：对于不需要完整上电复位和初始化过程的测试，可以通过强制置位硬件寄存器或状态位，使设计直接跳转到目标状态，从而跳过漫长的启动阶段。
• 分阶段验证：将测试分为两个阶段，第一阶段验证从复位到特定状态的跳转逻辑，检查状态跳转条件是否满足；一旦验证通过，后续的测试用例可省略第一阶段，直接设置成该状态，直接进入该状态下功能测试。
• 抽样完整启动：在所有测试用例中，仅挑选少量（如5%）进行完整的上电、复位、时钟使能及代码搬运流程，其余大部分用例采用快速启动方式以节省资源。

回归测试表

• 基本功能回归列表（基本测试用例）
• 专用功能回归列表（专用测试用例）
• 高级功能回归列表（高级功能、附加功能）
• 随机测试回归列表（大规模随机测试）

测试用例要有轻重缓急，加上一些标签，哪些是简单的，哪些是复杂的，哪些是直接测试/随机测试，形成一个回归列表。