Introduction to Verification
The ASIC Design Flow consists of several steps, including design specification, design entry, design synthesis, design verification, physical design, and design sign-off. Design verification (DV) typically refers to the pre-silicon effort of functional validation of the design using simulation tools.
What is digital design verification ?
Digital design verification is the process of testing and validating the correctness and functionality of a digital design or system before it is released or deployed. It is an essential step in the development process of digital systems and is crucial in ensuring that the system meets the required specifications and performance standards. The goal of digital design verification is to identify and eliminate any design errors or bugs, and to ensure that the system performs as expected under different conditions and use cases. The process involves creating a verification environment that can simulate various scenarios and test the system's behavior under different conditions.
What is the need of functional verification ?
Verilog RTL coding errors can take many forms, but here's an example: Let's say you are designing a simple counter module in Verilog that counts from 0 to a specified maximum value and then resets back to 0. Here's an example code snippet that implements this counter:
module counter ( input clk, input rst, output reg [7:0] count ); always @(posedge clk or negedge rst) begin if (rst) begin count
In this code, the counter module has an 8-bit output count that counts up from 0 to MAX_VALUE. However, there is an error in the code that could cause unexpected behavior. The error is in the reset logic of the module. The reset input rst is expected to be an active-low signal, but the code uses an active-high comparison to detect a reset condition. This means that the counter will reset when rst is high instead of low, which could lead to unexpected behavior and incorrect results. To fix this error, the code should use an active-low comparison (rst == 1'b0) instead:
always @(posedge clk or negedge rst) begin if (!rst) begin // active-low reset count
Importance of design verification
- Increasing design complexity: As the complexity of the design increases, the number of possible scenarios that need to be verified also increases. This means that the number of test cases and simulations required to verify the design also increases, making design verification a time-consuming task.
- Iterative process: Design verification is an iterative process that involves running simulations, analyzing results, and fixing design errors. This process may need to be repeated multiple times until the design meets all the required specifications and performs as expected. This iterative process can be time-consuming, especially for complex designs with many interactions between different modules.
- Development of verification environment: The development of a verification environment is a time-consuming task that involves creating testbenches, developing test cases, and running simulations. The verification environment must be comprehensive and cover all possible scenarios, which can be a time-consuming task.
- Time-sensitive nature of design verification: Design verification is a time-sensitive task because it must be completed before the design is fabricated. Any design errors or bugs that are not identified during the verification process can result in costly rework or delays in the project schedule.
To provide a rough estimate, the industry rule of thumb is that verification can take up to 70-80% of the total design time. However, this can vary widely depending on the design complexity, verification methodology used, and the expertise and experience of the verification team.
What happens if a bug is missed ?
Missing a hardware bug in verification can be costly in terms of time, money, and reputation. Here are a few potential costs of missing a hardware bug in verification:
- Rework and delay: If a hardware bug is not identified during verification, it may not be discovered until later in the design cycle, or even after the design has been fabricated. Fixing hardware bugs after the design has been fabricated can be costly and time-consuming, and can result in delays to the project schedule.
- Lost revenue: If a hardware bug is discovered after the design has been released to market, it can result in lost revenue and damage to the company's reputation. Customers may lose confidence in the product, leading to decreased sales and revenue.
- Product recalls: In some cases, hardware bugs can be severe enough to require a product recall. This can be a costly and time-consuming process, and can result in significant damage to the company's reputation.
- Legal liabilities: If a hardware bug results in harm or injury to users, the company may face legal liabilities and damages.
When can you stop verification ?
Verification is an iterative process that continues until the desired level of confidence is achieved. There is no fixed rule for when to stop verification as it depends on various factors such as project requirements, schedule, budget, and risk tolerance. However, some common criteria for stopping verification are:
- Achieving code coverage goals: The verification team can stop verification when all code coverage goals like branch, statement, expression, toggle and FSM have been met and the overall code coverage is at an acceptable level.
- Achieving functional coverage goals: The verification team can stop verification when all functional coverage goals have been met and the functional coverage is at an acceptable level.
- Meeting performance goals: Verification can be stopped when the design meets all performance goals, such as timing constraints and power consumption requirements.
- Finding and fixing all critical bugs: Verification can be stopped when all critical bugs have been found and fixed, and no new critical bugs have been introduced for a certain period.
- Available resources: Verification can be stopped if the available resources are not sufficient to continue, such as budget or time constraints.
