Wednesday, November 23, 2011

Constrained Random Verification : + and -

In the last decade, adherence to Moore’s law demanded ‘divide and conquer approach’ for developing SoC/ASIC. The design cycle now requires develop/procure IPs; build sub systems using them and integrate these sub systems further to realize the final product. Some IPs (Networking protocols, Graphics, Video, DSP… etc) are complex enough that further division into blocks during design and verification is unavoidable. Amidst all this, verification still is the biggest challenge in meeting schedules and taping out bug-free products. The ever increasing design complexity problem has enabled rapid development in ASIC verification. From traditional directed verification approach to Constrained Random Verification (CRV), it has been a long way. CRV brought a paradigm shift in the way we verify our designs and enabled development of Coverage Driven Verification (CDV) and Standard methodologies (eRM, RVM, AVM, VMM, OVM & UVM).

ADVANTAGES
+ Enables the test bench to hit corner cases & hidden (unplanned) bugs
+ When coupled with CDV leads to faster convergence of verification schedule  
+ Number of test cases to be developed / maintained is fewer as compared to directed test
+ Updating verification environment for changes in specifications during the design cycle is better organized
+ Methodical approach during development enables reusability from module to higher levels
+ Improves Portability across projects
+ Test bench reviews are more structured and probability of finding issues increases
+ Following a standard methodology helps in knowledge transfer across engineers & teams
+ Increases compute resource & license utilization

LIMITATIONS
- Requires a reference/Golden model to predict the output
- Requires lot of planning and structured code development (Methodology is key)
- In absence of CDV it would hard to define ‘are we done yet’
- During TB development, RTL bug rate is 0 and initially TB bug rate may be > RTL bug rate
- Converging on valid constraints when moving from IP to higher level involves iterations
- With increased design scope debugging random scenarios is challenging
- Limited randomness possible while verifying at SoC level with processor(s) in place.
- Gate level simulations require a set of directed test cases where CRV doesn’t contribute much
- In absence of adequate licenses and compute resources it stagnates to deliver desired results

Undoubtedly CRV has been instrumental in improving the quality of verification and getting organized verification closure. Most of the above limitations can be nullified with proper planning during the initial phase of any project. For IP level, CRV is a de-facto standard. However, as we move one level up, the limitations start influencing. Teams are forced to think if CRV will be utilized to its true potential? Should we follow CRV for sub-system and top level? What are the bottlenecks in extending CRV to increased scope of the design & is it worth the investment?

Coming next is a quick case study. Stay tuned…

6 comments:

  1. Commented by Peter Ateshian -

    Some architectures we design to emulate protein/water molecule interactions require integer bit precision ffts and ifft with double precision multiplying - CRV is really the only was to verify this exhaustive space

    ReplyDelete
  2. Linkedin Group: HVL (SystemC/C++/Verilog /Vera/Specman) Experts

    Good brief about Constrained Random Verification.

    Posted by Harinadh

    ReplyDelete
  3. Linkedin Group: OVM Professionals Network

    Ya....its right......but its the company which has a wide range of IP's which will succeed.....Bcoz you cannot always bu and trust third party IP's..And also some sort of verification is needed even for IP's bought from vendors...

    Posted by Parag

    ReplyDelete
  4. Linkedin Group: Indian Semiconductor Society

    Great Detailed Ariticle Gaurav. Keep Going. It would be a great Learning for the verification Folks who are on the learning curve.

    Posted by Jayant

    ReplyDelete
  5. Well rounded discussion Gaurav. If you are interested, I have a good counter-argument for each of you -ve points. (Yes, I am very pro-CRV/CDV.) In the interests of fair-play, I can offer on addition -ve point:

    The engineering skill level required for CRV is higher than traditional directed-test simulation methods.

    ReplyDelete
  6. Mike,

    Thank you for sharing this. I would be interested in keeping this discussion alive on the counter arguments for -ve points. Infact you can post it here or email it to me at siddhakarana@gmail.com

    We can have a separate blog post discussing our view points on the -ve aspects :)

    ReplyDelete