Visualizing UVM Environments: Debug Features Deliver a Clearer View

Guest Blog from Srinivasan Venkataramanan of CVC

Srinivasan Venkataramanan, Chief Technology Officer, CVC Pvt Ltd
Like(3)  Comments  (0)

It is an often-quoted statistic that Functional Verification consumes the lion’s share (40-70%) of ASIC and complex FPGA design projects. A less often stated fact, yet no less true, is the majority of verification cycle time is spent within the debug phase. Hence, any automation implemented during the debug process stands to deliver a considerable boost to productivity.

 

The Universal Verification Methodology (UVM) has standardized how interoperable Verification IP (VIP) can be created, reused, plugged into larger sub-systems. UVM has also laid out building blocks for new verification projects in the form of several base classes or templates. By taking advantage of the established UVM structure, a mature Electronic Design Automation (EDA) tool can take and abstract the debug level quite significantly. Early stage UVM SystemVerilog debuggers (that are now by default available with most EDA tools) do show the class relationships, graphs, and UMLs. While this is a decent starting point, most of that information could also be easily obtained using free tools such as Doxygen™ or NaturalDocs™ with appropriate UVM SystemVerilog filters.

 

Viewing Testbench Architecture

In my experience helping semiconductor design companies with their verification challenges, I have found that what is really needed is the ability to visualize verification environments in a top-down fashion. This information has been hard to obtain from most debuggers, so I was pleasantly surprised to see that the latest 2014.02 release of Aldec Riviera-Pro, offers some unique, out-of-the-box views of UVM verification environments.

 

Riviera-PRO 2014.02 offers an illustrated view of the testbench structure as shown below in Figure-1.

blog_img_030514_a_574

For testbench architects, this type of visualization is particularly helpful, enabling them to view the “micro-architecture” (of testbench) in a GUI. Note that the above process is completely automated and essentially a code-to-graphics approach.

blog_img_030514_b_408Those little icons used to indicate the individual components also make it interesting and fun at times. For instance, Anirudh, my son in primary school, is able to quickly identify the “Agent-P” in there!

Being Verification engineer is more fun nowadays!

 

Visualizing Data-Flow

Getting back to serious debug sessions, to better understand the data-flow within the UVM framework, one option is to go through lengthy UVM base class code, identify the TLM ports, exports, tlm_fifo (and its derivatives), and finally reach the user code.

A better option is available with the new visualization features in Riviera-PRO. With a simple mouse-click, an expanded view of sequencer & driver reveals the same details in a much more compact and digestible form as shown in Figure-2 below.

blog_img_030514_c_580

Painless Debugging

By now verification engineers (who have completed any serious UVM debugging with currently available solutions) are probably growing envious – and we have only just begun!

What if you are chasing an error from a WIP (Work In Progress) verification environment as shown below?

blog_img_030514_d_586

Sure thing, you might say, a nice debug challenge ahead. Pick up a mug of coffee or chai, lock your team’s UVM base class champion and the code developer inside a room and promise to release them once the issue is resolved.

Unfortunately, the UVM base class is complex and is not so “debug friendly” for the end-user, especially when debugging user-level coding errors. Using the new Riviera-Pro debugger, however, it’s a simple matter of bringing up the same code, clicking the right button and, as shown below, the picture suddenly becomes clearer.

blog_img_030514_e_578

Study the above image and you will likely soon realize the sequencer and driver are left unconnected. While the UVM base class has done an excellent  job not wasting simulation time by issuing a fatal error in this scenario (thus saving time for the verification process), it falls short in identifying the exact issue.

The relevant source code causing the above scenario is shown in Figure-4 below. It is one of those cases of “Aha, I knew that before,” but was able to recall only “after”.

blog_img_030514_f_573

I hope that you appreciate the value of these new debug features and enhanced visualization now available with Riviera-Pro as much as I do.

There are many more similar debug anecdotes emerging from the verification Spartans working in trenches at CVC - so stay tuned.

 

Srini provides support to leading edge semiconductor design companies on their verification methodologies and challenges. Throughout his career he has been actively involved in the verification of leading edge high-speed, multi-million gates ASIC designs. He is an active member in various upcoming standards, is currently the co-chair of IEEE 1647, e –Functional Verification Language, and has co-authored several books. Srini holds a Masters Degree from the prestigious Indian Institute of Technology (IIT), Delhi in VLSI Design, and a Bachelors degree in Electrical Engineering from TCE, Madurai.

Comments

Ask Us a Question
x
Ask Us a Question
x
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.