Directed verification is a type of functional verification in which the test cases are created to exercise specific features or functions of a digital design. The test cases are designed based on the knowledge of the design specification and the intended behavior of the design. Directed verification is often used in the early stages of the verification process, before random or stress testing is performed, as it can help to quickly identify bugs and ensure that the basic functionality of the design is correct.
Directed verification can be performed using different types of testbenches, such as a file-based testbench, a linear testbench, or a state machine-based testbench. In a directed testbench, the test cases are carefully designed to cover specific scenarios, and the input stimuli are typically pre-defined. The testbench monitors the output of the design and checks whether it matches the expected output for each test case.
Here's an example of a directed testbench that tests the basic functionality of a 2-to-1 multiplexer:
module tb();
// Declare inputs and outputs
logic a;
logic b;
logic sel;
logic out;
// Instantiate DUT
mux2to1 u_mux(a, b, sel, out);
// Test cases
initial begin
// Test case 1: sel=0, a=1, b=0
sel = 0;
a = 1;
b = 0;
#1 $display("Test case 1: a=%b, b=%b, sel=%b => out=%b", a, b, sel, out);
if (out !== a) $error("Test case 1 failed");
// Test case 2: sel=1, a=1, b=0
sel = 1;
a = 1;
b = 0;
#1 $display("Test case 2: a=%b, b=%b, sel=%b => out=%b", a, b, sel, out);
if (out !== b) $error("Test case 2 failed");
// Test case 3: sel=0, a=0, b=1
sel = 0;
a = 0;
b = 1;
#1 $display("Test case 3: a=%b, b=%b, sel=%b => out=%b", a, b, sel, out);
if (out !== a) $error("Test case 3 failed");
// Test case 4: sel=1, a=0, b=1
sel = 1;
a = 0;
b = 1;
#1 $display("Test case 4: a=%b, b=%b, sel=%b => out=%b", a, b, sel, out);
if (out !== b) $error("Test case 4 failed");
// Finish test
$display("All test cases passed");
$finish;
end
endmodule
In this example, the testbench includes four pre-defined test cases that exercise the basic functionality of the multiplexer. The testbench sets the input signals for each test case and then checks the output of the design to ensure that it matches the expected output. If the output does not match the expected value, the testbench generates an error using the built-in $error function. Once all test cases have been run, the testbench prints a message indicating whether all test cases passed or if there were any failures.
Limitations
Directed verification has some limitations that can affect its effectiveness in identifying all potential design bugs. Here are some of the limitations:
- Limited test coverage: Directed verification is based on pre-defined test cases that are designed to test specific functionalities or scenarios. This means that it may not cover all possible scenarios, which can lead to undetected bugs.
- Bias towards the designer's assumptions: Directed verification is based on the designer's knowledge of the design specification and intended behavior. This can lead to test cases that are biased towards the designer's assumptions, which may not always be accurate.
- Difficulty in detecting complex bugs: Directed verification may not be effective in detecting complex bugs that require multiple functionalities to interact in specific ways.
- Limited scalability: Directed verification may not scale well for larger and more complex designs, as it can become increasingly difficult to create enough test cases to cover all possible scenarios.
- Time-consuming test case creation: Creating directed test cases can be time-consuming, as each test case must be carefully designed to exercise a specific functionality or scenario.
