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…