Verification -- Basic Concepts ~ 0. Introduction
Introduction
AISC设计流程由几个步骤组成，包括 design specification、design entry、design synthesis、design verification、physical design and design sign-off.
Design verification (DV) 通常是指使用仿真工具对设计进行功能验证的pre-silicon effort。
What is digital design verification ?
Digital Design Verification 是在发布或部署数字设计或系统之前测试和验证其正确性和功能的过程。这是数字系统开发过程中必不可少的一步，对于确保系统符合所需的规格和性能标准至关重要。
Digital Design Verification 的目标是识别和消除任何设计错误，并确保系统在不同条件和用例下按预期运行。该过程涉及创建一个验证环境，该环境可以模拟各种场景并测试系统在不同条件下的行为。
What is the need of functional verification ?
Verilog RTL 编码错误可以采取多种形式，但这里有一个示例：假设您正在 Verilog 中设计一个简单的计数器模块，该模块从 0 计数到指定的最大值，然后重置回 0。下面是实现此计数器的示例代码片段：
module counter (
input clk,
input rst,
output reg [7:0] count
);
always @(posedge clk or negedge rst) begin
if (rst) begin
count <= 8'd0;
end else begin
if (count == MAX_VALUE) begin
count <= 8'd0;
end else begin
count <= count + 1;
end
end
end
endmodule
在此代码中，计数器模块具有 8 位输出计数，从 0 计数到 MAX_VALUE。但是，代码中存在可能导致意外行为的错误。
错误出在模块的复位逻辑中。复位输入 rst 应为低电平有效信号，但该代码使用该电平有效比较来检测复位条件。这意味着当 rst 为高电平而不是低电平时，计数器将重置，这可能会导致意外行为和不正确的结果。
若要修复此错误，代码应改用低电平有效比较：（rst == 1'b0）
always @(posedge clk or negedge rst) begin
if (!rst) begin
count <= 8'd0;
end else begin
if (count == MAX_VALUE) begin
count <= 8'd0;
end else begin
count <= count + 1;
end
end
end
Importance of design verification
Design Verification 是项目生命周期中最耗时的任务之一，因为它涉及确保涉及满足所有必须的规范并按预期执行。
以下是 Design Verification 可能非常耗时的几个原因:
- 增加设计复杂性：随着设计复杂性的增加，需要验证的可能场景数量也会增加。这意味着验证设计所需的测试用例和仿真的数量也会增加，使设计验证成为一项耗时的任务。
- 迭代过程：设计验证是一个迭代过程，涉及运行仿真、分析结果和修复设计错误。此过程可能需要重复多次，直到设计满足所有必需的规格并按预期执行。这种迭代过程可能非常耗时，特别是对于不同模块之间有许多交互的复杂设计。
- 验证环境的开发：验证环境的开发是一项耗时的任务，涉及创建测试平台、开发测试用例和运行仿真。验证环境必需全面并涵盖所有可能的场景，这可能是一项耗时的任务。
- 设计验证的时间敏感性：设计验证是一项时间敏感的任务，因为它必须在设计制造之前完成。在验证过程中未发现的任何错误或错误都可能导致代价高昂的返工或项目进度延迟。
What happens if a bug is missed ?
在验证中遗漏硬件错误可能会在时间、金钱和声誉方面付出昂贵的代价。以下是在验证中遗漏硬件错误的一些潜在成本：
- 返工和延迟：如果在验证过程中未发现硬件错误，则可能要到设计周期的后期，甚至在设计完成之后才能发现该错误。在设计完成后修复硬件错误可能既昂贵又耗时，并可能导致项目进度延迟。
- 收入损失：如果在设计投放市场后发现硬件错误，可能会导致收入损失并损害公司声誉。客户可能会对产品失去信心，导致销售额和收入下降。
- 产品召回：在某些情况下，硬件错误可能严重到需要召回产品。这可能是一个昂贵且耗时的过程，并可能对公司的声誉造成重大损害。
- 法律责任：如果硬件错误导致用户受到伤害，公司可能面临法律责任和损害赔偿。
When can you stop verification?
验证是一个迭代过程，一直持续到达到所需的置信度。何时停止验证没有固定的规则，因为它取决于各种因素，例如项目要求、进度、预算和风险承受能力。但是，停止验证的一些常见标准是：
- 实现代码覆盖率目标：当满足所有代码覆盖率目标（如分支、语句、表达式、切换和FSM）且整体代码覆盖率处于可接受的水平时，验证团队可以停止验证。
- 实现功能覆盖率目标：当所有功能覆盖率目标都已实现且功能覆盖率处于可接受水平时，验证团队可以停止验证。
- 满足性能目标：当设计满足所有性能目标（如时序限制和功耗要求），可以停止验证。
- 查找并修复所有关键 Bug：当发现并修复所有关键 bug, 并且在一段时间内没有引进新的严重 bug 时，可以停止验证。
- 可用资源：如果可用资源不足以继续，例如预算或时间限制，则可以停止验证。
