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


Tutorials



HOW TO GET SCENARIOS WHICH WE NEVER THOUGHT




In Directed verification, the Verification Environment has mechanism to send the Stimulus to DUT and collect the responses and check the responses. The Stimulus is generated in Tests case. Directed testbenchs may also use a limited amount of randomization, often by creating random data values rather than simply filling in each data element with a predetermined value. Each test case verifies specific feature of the design. This becomes tedious when the design complexity increases. As circuit

complexity increases, it becomes more difficult to create patterns that fully exercise the design. Test case maintenance become harder and time consuming.



In Directed Verification, test writer has to list out each feature. Test writer can't think of all possible potential bug scenarios and there are chances that Bugs will escape. With these approaches, the bugs lurking in these corners hide until late in the development cycle, or aren't found at all until product is taped out.

Solution to the above problems is Constraint random verification. Using constraint random verification, the stimulus required to verify test features are generated automatically. Test writer specifies set of specification, and the TestBench automatically creates solution space and picks up scenarios from the solution space.

Constraint random verification also reduces manual effort and code for individual tests. As the scenarios are generated automatically by the TestBench, the number of test case files gets reduced. In Directed verification, some of the tests share similar logic, if the engineer has to change the logic which is common to certain group of tests, then he has to edit all the test case files and it is time consuming. But in Constraint random verification, the number of tests case files will be very less, so changes will be mostly in environment and minimal.

Directed verification with a fairly simple TestBench, verification engineers can start finding bugs in simulation almost immediately even before the TestBench is fully completed. With a constrained-random verification environment, there is an up-front cost that must be invested before the first test can be run. Constraint-based generators can be easily converted into checkers if required.


Generating fully randomly is meaningless as it may generate invalid scenarios and it may also regenerate the same scenario again and again wasting potential simulation time. A User must define data structures, which represent stimulus applied to the DUT input. Next, constraints must be defined to guide the random generator. Using constraint, the solution space is defined, and randomization picks up scenarios randomly from the solution space. Constraints act as knobs in the TestBench which control the generator's randomness.

The main disadvantage of constraint random verification is we never know how well the DUT is verified. If verification engineer can get the information about the logic in DUT which is not verified, he can further constraint the randomization or write directed testcases to exercise the unverified logic.


Index
Asic Design
Bottle Neck In Asic Flow
Functional Verification Need
Testbench
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!





<< PREVIOUS PAGE

TOP

NEXT PAGE >>

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