学习记录25（数字验证概念策略和方法）

1.验证策略

两个维度：广度（按照层次）和深度（按照透明度也就是计分板对比scoreboard）

2.测试方法

黑盒测试：

这是一种验证方法，其中设计实现的内部细节不会暴露给验证。通过仅访问暴露的接口信号来完成验证，从而使其实现独立。如果需要debug具体错误位置（定位）就要向开发商购买licence，加到仿真选项中，这样用verdi才能看到代码
显然，验证对于设计的内部实现细节或系统状态是不可见的。这种方法最适合发现解释级别的问题，如字节序检查、协议误解和互操作性测试。

白盒测试：

在这种验证方法中，可以访问设计的内部状态、信号和接口。在这种情况下，调试任何设计问题都非常容易，因为测试平台可以根据预期跟踪信号驱动器。
这种方法最适合于检查低层次的特定于实现的场景和设计角落，在那里他们可以针对具有潜在问题的场景进行设计并调试它们，例如FIFO指针翻转、计数器溢出等。知道内部每根信号线/寄存器名，跳过物理引脚，直接焊接到内部节点（force 内部信号），主动强制内部信号翻转，指哪打哪。

白盒测试知道底层门级/寄存器传输级实现，通过仿真器的后门权限（force/deposit）强行改变内部任意节点（信号/寄存器）的值，以激活正常外部序列极难覆盖的内部逻辑路径，并观测该强制动作通过组合逻辑向内传播和向输出端口传递的完整行为，包括检查时序毛刺、异常输出和内部状态畸变。我不仅看RTL代码，我还记住了第 128 行那个 if (a && b) 的分支很难覆盖。我直接写 force tb.dut.a = 1; force tb.dut.b = 0; 来强行跑那个分支。我看代码，并用后门指令（force）强行操作代码里的内部节点。

灰盒测试：
这种方法介于黑盒和白盒验证技术之间。知道内部状态机/寄存器定义，依然从外部物理引脚灌入，利用内部知识设计外部序列（如灌 32 个包打满 FIFO）。根据内部地图调整外部约束，驱动外部序列撞进去
通常，第一级测试使用黑盒方法作为目标，并评估功能覆盖率。为了提高覆盖率，如果需要，通过白盒方法，测试场景被测试。

灰盒测试关注的是状态机状态和 FIFO 状态以及寄存器状态，外部设计激励时进行约束。例如我仔细阅读 RTL 代码，发现内部有一个 3 位状态机，还有 FIFO 的空满计数器。我利用这些内部信息，去写 covergroup 盯着状态机跳转，去调整随机约束让 FIFO 更容易满。我看代码，但我不改代码（不改内部信号）

系统级和模块级验证的侧重点是什么？

模块级：模块级验证侧重于单个模块的功能正确性。如果模块内部功能有误，集成到子系统或SOC后必然会导致整体错误，在模块级验证中，验证人员可以直接看到RTL代码，属于白盒验证，便于深入检查内部逻辑、状态机跳转及代码覆盖率，保证子系统正确。
系统级：系统级验证不再关注单个模块的内部细节，而是侧重于各个子系统之间、模块与总线（NoC）之间的连接是否正确。重点在于验证上下电流程、复位序列、中断处理、带宽性能以及数据通路（如DMA搬运数据）在不同模块间的交互是否正常。对于复杂的子系统（如CPU、Ethernet），系统级验证通常将其视为黑盒或灰盒，只关心其接口行为和整体连通性，而非内部实现

验证点为何需分粗略和精细提取？

避免遗漏：如果只阅读一遍设计文档（DT）就立即提取验证点，往往提取不全，容易漏掉一些细节。
循序渐进：初次提取时通常是一个粗略的框架，后续通过进一步深入阅读和理解，再进行更细致的提取，以确保覆盖所有功能点和边界情况。

3.验证方法（面试常问）

动态仿真主要的仿真器有celium、VCS、Modelsim/Qusta。

我们了解过定向测试占百分之九十，随机测试占百分之十，主要用于测试工程师都未曾预料的缺陷。

静态验证

语义检查主要是检查rtl代码，对rtl代码进行语义检查，主要检查变量是否声明、类型是否一致等。
CDC跨时钟域检查，解决信号从一个时钟域跨越到另一个异步时钟域时，因频率不同或相位不一致导致的数据采集失败或采集错误问题（确保数据正确采集，所有信号都能正确得到同步），从而避免亚稳态等风险，保证系统稳定运行（保证同步可靠性）。
形式验证：穷尽所有数学方法来约束输入，验证rtl代码。基于事务的