|HOME |ABOUT |ARTICLES |ACK |FEEDBACK |TOC |LINKS |BLOG |JOBS |


Tutorials



SELF CHECKING TESTBENCH




Two important aspects of todays functional verification are quality and re usability. Design engineers have made design reuse to reduce development time and effort in designing an ASIC. Significant design blocks are reused from one project to the next. The lack of flexible verification environments that allow verification components reuse across ASIC design projects keep the verification cost very high. Considering the fact that verification consumes more resources than design does , it would be of great value to build verification components that are modular and reusable. When a design is passing all the tests in the verification environment, it has not been possible to know whether the design under verification is correct, and may be safely taped-out, or whether the verification environment is just incapable of finding any bugs that may still remain in DUT.

ADVANTAGES:
Speeds up verification and results in early tape out of the chip.
Less man power is required, by which the over all cost of the project will be low.
Environment can be reusable.
Easy tracking of verification progress(functional coverage).
Developing self checking testbench is very interesting.


Todays functional verification flow mainly contains following steps:

Generate the stimulus vectors.
Send the Stimulus to the DUT.
Monitor the response generated by the DUT.
Verify the response generated.
Generate report about the DUT performance.
Some kind of feedback to show the quality of testbench.

A test-bench is built to functionally verify the design by providing meaningful scenarios to check that given certain input, the design performs to specification. Test bench provides the stimulus to exercise DUT code. A self checking testbench is a intelligent testbench which does some form of output sampling of DUT and compares the sampled output with the expected outputs. A simulation environment is typically composed of several types of components:





Stimulus Generator:



In order to test the model of some design, a verification engineer must apply test patterns to the input ports and observe the output ports over time to decide whether the inputs were transformed to the expected outputs. The generator component generates input vectors. For simple memory stimulus generator generates read, write operations, address and data to be stored in the address if its write operation. Modern generators generate random, biased, and valid stimuli. In verilog $random does this job. The randomness is important to achieve a high distribution over the huge space of the available input stimuli. To this end, users of these generators intentionally under-specify the requirements for the generated tests. It is the role of the generator to randomly fill this gap. This mechanism allows the generator to create inputs that reveal bugs not being searched for directly by the user. Generators also bias the stimuli toward design corner cases to further stress the logic. Biasing and randomness serve different goals and there are tradeoffs between them, hence different generators have a different mix of these characteristics. Since the input for the design must be valid and many targets should be maintained, many generators use the Constraint Satisfaction Problem technique to solve the complex testing requirements. SystemVerilog, Vera, SystemC and Specman have " constraints " to specify The legality of the design inputs. In verilog ,to constrain the memory address to be between 0 to 63, {$random} % 64 is used. The model-based generators use this model to produce the correct stimuli for the target design. The stimulus generator should be intelligent and easily controllable.



Bus Functional Models



The Bus Functional Model (BFM) for a device interacts with the DUT by both driving and sampling the DUT signals. A bus functional model is a model that provides a task or procedural interface to specify certain bus operations for a defined bus protocol. For a memory DUT, transactions usually take the form of read and write operations. Bus functional models are easy to use and provide good performance. It has to follow the timing protocol of the DUT interface. BFM describes the functionality and provides a cycle accurate interface to DUT. It models external behavior of the device. For re usability, the implementation of the BFM functionality should be kept as independent of the communication to the BFM as it can be.


Driver



Driver is a types of BFM. The drivers translate the stimuli produced by the generator into the actual inputs for the design under verification. Generators create inputs at a high level of abstraction; namely, as transactions like read write operation. The drivers convert this input into actual design inputs which is at a low level like bits ,as defined in the specification of the designs interface. If the generator generates read operation, then read task is called, in that, the DUT input pin "read_write" is asserted.


Reciver



Receiver is also a type of BFM. The output of the DUT is collected. The output of the DUT is available in a low level format. Let~Rs take a packet protocol. The interface has "start of the packet" and "end of packet" signal to indicate the packet arrival. The receiver starts collecting the packet looking at the signal "start of packet" and does this job until "end of the packet".


Protocol Monitor:



Protocol monitor do not drive any signals, monitor the DUT outputs, identifies all the transactions and report any protocol violations. The monitor converts the state of the design and its outputs to a transaction abstraction level so it can be stored in a 'score-boards' database to be checked later on. Again let~Rs take a packet protocol. The monitor gets the information from the packet like, length of the packet, address of the packet etc.


Scoreboard:



Scoreboard is sometimes referred as storage structure. The stimulus generator generated the random vectors. These are derived to the dut. These stimulus are stored in scoreboard until the output comes out of the DUT. When a write operation is done on a memory with address 101 and data 202,asfter some cycles, if a read is done at address 101,what should be the data?.The score board recorded the address and data when write operation is done. Get the data stored at address of 101 in scoreboard and compare with the output of the DUT in checker. Scoreboard also has expected logic if needed. Take an 2 input and gate. The expect logic does the " and " operation on the two inputs and stores the output.


Checker:



Checker is part of score board. The checker validates that the contents of the 'score-boards' are legal. There are cases where the generator creates expected results, in addition to the inputs. In these cases, the checker must validate that the actual results match the expected ones.


Coverage:



Coverages are of two types, Functional coverage and code coverage. Code coverage is not part of Testbench. Functional Coverage is part of test bench. Functional coverage cannot be done in Verilog.


Code Coverage:



Code coverage, in short, is all about how thoroughly your tests exercise your code base. The intent of tests, of course, is to verify that your code does what it's expected to, but also to document what the code is expected to do. Taken further, code coverage can be considered as an indirect measure of quality -- indirect because we're talking about the degree to what our tests cover our code, or simply, the quality of tests. In other words, code coverage is not about verifying the end product's quality.

Statement coverage: measures the number of statements executed .
Branch coverage: measures the expressions and case statements that affect the control flow of the HDL execution
Condition coverage: breaks down the condition on the branch into elements that make the result true or false
Toggle coverage: counts low-to-high and high-to-low transitions
Finite State Machine: state and state transition coverage


Functional Coverage:



Functional is the metric which shows how much we have verified. It shows how many possible scenarios are possible and how many are covered. Take a memory. If the memory address is 64 byte depth, and if the address is generated randomly, we are not sure that every location is covered. Functional coverages gives report how many address are possible and how may we have covered.


Index
Introduction
Linear Tb
File Io Tb
State Machine Based Tb
Task Based Tb
Self Checking Testbench
Verification Flow
Clock Generator
Simulation
Incremental Compilation
Store And Restore
Event Cycle Simulation
Time Scale And Precision
Stimulus Generation
System Function Random A Myth
Race Condition
Checker
Task And Function
Process Control
Disableing The Block
Watchdog
Compilation N Simulation Switchs
Debugging
About Code Coverage
Testing Stratigies
File Handling
Verilog Semaphore
Finding Testsenarious
Handling Testcase Files
Terimination
Error Injuction
Register Verification
Parameterised Macros
White Gray Black Box
Regression
Tips

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





<< PREVIOUS PAGE

TOP

NEXT PAGE >>

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