6.3. Verification Techniques in RTL Simulation

A testbench is a specialized simulation environment used to apply inputs to the design and verify its outputs. The testbench includes: ● Stimulus generation: Applying test inputs to the design. ● Monitor: Observing and reporting output values from the DUT (Design Under Test). ● Checker: Comparing the actual output with the expected output. There are two main types of testbenches in RTL verification: Directed Testbenches: These use a predefined set of test vectors to verify specific scenarios. Directed tests are easy to write but may not catch all corner cases.

initial begin
// Test specific conditions
reset = 1;
#10 reset = 0;
#20 reset = 1;
// Apply more stimuli
end

Random Testbenches: These generate random input sequences to stress the design and test it under various conditions. Random testbenches are more exhaustive but harder to control.

initial begin
// Random stimuli generation using $random
input_a = $random;
input_b = $random;
end

A testbench is like a testing environment for a digital circuit. It simulates how the circuit would behave under certain conditions.

1. Stimulus Generation: Just like a coach prepares different drills for athletes, the testbench sets up inputs or signals that the design will face during operation.
2. Monitor: This part watches what happens when those inputs are applied—just like a referees watch a game to ensure everything runs smoothly.
3. Checker: It compares what should happen (expected output) with what actually happens (actual output). This helps determine whether the design works correctly.

There are two types of testbenches:

• Directed Testbenches are specific and straightforward—like practicing a particular play in football. You tell exactly what to test, but it might miss other situations.
• Random Testbenches generate unpredictable inputs, providing a broader coverage of possible scenarios—like a scrimmage where players face various unexpected plays. However, controlling outcomes is harder with randomness.

Think of a testbench as a cooking environment. When you want to make a dish (verify the design), you prepare ingredients (stimuli), check the recipe (monitor), and taste the dish (checker) to see if it turned out the way you intended. If you follow a strict recipe, it’s like a directed testbench; if you try random combinations of spices, it’s like a random testbench.

Assertions are used to specify properties that should hold true during simulation. Assertions help to automatically check the correctness of the design and are often used in combination with formal verification to prove that the design satisfies the specification. ● Property Specification: Assertions allow the specification of properties like "if A happens, B must happen next" or "the output should never be high unless the input is high." Example: Assertion in Verilog

assert property (@(posedge clk) reset == 0);
``` This assertion ensures that reset is not high on the rising edge of clk.

Assertions are like rules or conditions you set while designing a product to ensure quality control labels.

1. Purpose: Assertions check that specific conditions—it’s like saying, 'If I press this button, the light must turn on.'
2. How it Works: During the simulation, assertions continuously monitor the design. If any assertion fails (like the light not turning on), it indicates a problem.
3. Specifications: You can define properties to check. The example shows a condition that ensures a reset signal (which often clears settings) must be low when the clock ticks.

Using assertions consistently helps catch errors early, much like following safety checks in a manufacturing process.

Imagine a smart oven that checks whether the temperature is correct before starting to bake. If the temperature isn’t right, the oven doesn't start, just like how assertions prevent a design from running when it doesn't meet requirements.

Code Coverage is used to measure how much of the RTL code has been exercised during simulation. It helps identify untested areas of the design. ● Types of Coverage: ○ Statement Coverage: Ensures that each line of code is executed at least once. ○ Branch Coverage: Ensures that each possible branch in the code (e.g., if-else statements) is exercised. ○ Toggle Coverage: Measures how often signals change from 0 to 1 and vice versa. Functional Coverage is used to track whether all functional scenarios (e.g., all possible input combinations) have been tested. Functional coverage can be manually defined in the testbench or automatically tracked by the simulator. Example: Functional Coverage in Verilog

covergroup cg;
coverpoint signal_a;
coverpoint signal_b;
endgroup
``` This coverage block tracks the coverage of signal_a and signal_b.

Code coverage is like measuring how much of a book you've read—tracking which parts of the design have been tested during simulation.

1. Types of Coverage:
   • Statement Coverage: Similar to checking if every page of a book has been opened while reading.
   • Branch Coverage: Ensures that every storyline in a book is followed at least once, just like checking each possible path in decision-making.
   • Toggle Coverage: Monitors if the lights switch from on to off often enough, indicating sufficient dynamic behavior in signals.
2. Functional Coverage: Tracks if all scenarios, like every character’s actions, have been explored. This kind of coverage helps ensure no major plot points are ignored.

Think of code coverage as checking off ingredients in a recipe. If you haven't used every ingredient (i.e., code line), the dish (which represents the design) may not turn out right. You want to ensure you didn't miss any crucial steps.

--