Linear TestBench is the simplest, fastest and easiest way of writing testbenchs. This became novice verification engineer choice. It is also slowest way to execute stimulus. Typically, linear testbenchs are written in the VHDL or Verilog. In this TestBench, simple linear sequence of test vectors is mentioned. Stimulus code like this is easy to generate translating a vector file with a Perl script, for example. Small models like simple state machine or adder can be verified with this approach. The following code snippet shows linear TestBench. The code snippet shows some input combination only. This is also bad for simulator performance as the simulator must evaluate and schedule a very large number of events. This reduces simulation performance in proportion to the size of the stimulus process.

Typically, linear testbenchs perform the following tasks:

Instantiate the design under test (DUT)
Stimulate the DUT by applying test vectors.
Output results waveform window or to a terminal for visual inspection manually.

Example: Linear TestBench
module adder(a,b,c); //DUT code start
input [15:0] a;
input [15:0] b;
output [16:0] c;

assign c = a + b;

endmodule //DUT code end

module top(); //TestBench code start
reg [15:0] a;
reg [15:0] b;
wire [16:0] c;

adder DUT(a,b,c); //DUT Instantiation

a = 16'h45; //apply the stimulus
b = 16'h12;
#10 $display(" a=%0d,b=%0d,c=%0d",a,b,c);
//send the output to terminal for visual inspection
endmodule //TestBench code end

To test all possible scenarios which are known to us, it is not an easy task. Development time increases exponentially as the number of scenarios increases and maintain them is nightmare. Instead of listing out all the possible scenarios, pickup some randomly and check the DUT.


Generally tendency of any novice engineer is to see the outputs in the waveform viewer. Waveform viewers are for debugging designs, not for testbench. Most of the operation in TestBench executes in zero time, where waveform viewer will not be helpful. All the examples in the book outputs messages to terminal for analyzing its behavior.

Asic Design
Bottle Neck In Asic Flow
Functional Verification Need
Linear Testbench
Linear Random Testbench
How To Check The Results
Self Checking Testbenchs
How To Get Scenarios Which We Never Thought
How To Check Whether The Testbench Has Satisfactorily Exercised The Design
Types Of Code Coverage
Statement Coverage
Block Coverage
Conditional Coverage
Branch Coverage
Path Coverage
Toggle Coverage
Fsm Coverage
Make Your Goal 100 Percent Code Coverage Nothing Less
Functional Coverage
Coverage Driven Constraint Random Verification Architecture
Phases Of Verification
Ones Counter Example
Verification Plan

Report a Bug or Comment on This section - Your input is what keeps Testbench.in improving with time!




copyright 2007-2017 :: all rights reserved www.testbench.in::Disclaimer