Importance of Constrained Random Verification Approach

[Asic With Ankit]

Importance of Constrained Random Verification Approach : ASIC With Ankit

As a verification Engineers we must know what technique should be used in Test Bench development to verify IP, FPGA or any ASIC/SoC Verification.

I have been hearing many ideas, techniques and approaches on Directed Testing as well as Constrained Random Verification. Here I would like to share some advantages of CRV (Constrained Random Verification) over Directed Testing/Verification. Let us try to understand in brief on both approaches

First, let me give you an idea on 'What is Directed Testing?'

Directed Verification Environment with a sets of directed tests is extremely time-consuming and difficult to maintain. Directed tests only cover conditions that have been anticipated by the verification team, This can lead to costly re-spins and still there are changes of missing market windows which is extremely painful for any semiconductor company.

In directed Verification testing, Engineers spends good amount of time to understand the functionality of Design and identify different verification scenarios to cover functionality. Once they are done with identifying scenarios, they start defining directed test bench architecture. Traditionally verification IP (VIP) works in a directed test environment by acting on specific testbench commands such as read, write or some other commands to generate transactions for specific protocol testing. This type of directed testing is used to verify that an interface behaves as expected in response to valid/invalid transaction. Bigger risk with this type of testing is that directed tests only test for predicted behavior. So some time it leads to extremely costly bugs found in silicon which they missed during the scenario identification phase !!

Constrained Random Verification Methodology gives effective method to achieve coverage goals faster and most importantly it helps in finding corner case problem. Advantage is, Engineers does not have to write many test cases, smaller set of constrained-random scenario with few full random test scenario are good enough to fulfill coverage goals (functional as well as code coverage).
Based on my experience and understanding, usually people follows layered architecture in constrained random verification. (For better understanding of layered architecture, click on Gopi's Blog or Read VMM User manual by Synopsys) where you will see Test layer controls over whole verification environment and component. Mostly this control will be given to user. So user can run same test suites with different configuration if require to achieve coverage goal. In constrained random approach, scoreboards are used to verify that data has successfully reached to its destination while monitors snoops the interfaces to provide coverage information. New or revised constraints focus verification on the uncovered scenarios to meet coverage goal. As verification progresses the simulation tool identifies the best seeds which are then retained as regression tests to create a set of scenarios, constraints and seeds. In this approach of verification, you will be having less number of test cases which is enough to achieve coverage goals. I have observed one best usage of Directed tests in random verification, Here I am describing the best usage place of directed tests.

Always use directed tests after regression cycles of random verification, Random verification regression cycles gives some corner scenarios which are always left in coverage and you can always identify from functional and code coverage analysis. So identify those kind of scenario and write directed tests with specific constraint to cover specific scenario. This way coverage will be achieved !

Constrained Random Verification is very popular now a days because of so many reason, I have tried to capture couple of differences and advantages over both techniques.

Hope this post adds better understanding over constrained random verification technique.

Note : Special Thanks to Mr Gopi Krishna allowing me to use his webpages as references and posting my couple of interesting posts on his website http://www.testbench.in/links.html. My Coverage Post, My Pass/Fail Message Post

Comments, suggestion and questions are always welcome !

Enjoy!
ASIC With Ankit @ ASIC with Ankit
Ankit Gopani | LinkedIn
​

 

[simguru]

Basically CRV drops out of the fact you can't test everything - because you haven't enough time. You do directed tests to make sure you have not screwed up on the obvious stuff then you do random tests to try and make sure you have exercised everything, and if you're lucky some tools well help you get there.

If you have formal tools you would be better off using them most of the time, simulation based testing is only as good as the ability of the simulator (or HDL) to model your design, and that's pretty poor at RTL and way too slow in SPICE.

My personal preference is to model complete systems so that you can see all the pieces fit, and it actually performs the tasks required. Large amounts of CRV on a subsystem doesn't really tell you it's going to do the right thing. You can plug the subsystems in with increasing detail as the design process moves along with a "checker board" approach.

 

[Asic With Ankit]

Correct !! CRV drop outs the fact you can't test everything !! So to start with basic testing Engineers generally uses semi directed or directed tests where we make sure on basic functionality testing. This way we get confident that we have not screwed up anything and checked basic functionality. Then we start random testing to exercise maximum functionality and to fulfill coverage goals !

After this phase of testing/verification if we observe couple of corner cases from coverage (code/functional) then we again write those type of directed testcases to generate identified corner cases.

Regards,
Asic With Ankit