Our Case Study of Verdi Integration from SNUG

As we discussed in last week’s post, the past two days we were busy with activities at SNUG Silicon Valley, the annual focus for all things Synopsys. On Monday we exhibited in the Designer Community Expo, which drew programmers, architects, and verification engineers in addition to hardware designers. We have always been impressed by the verification teams we meet at SNUG. They’re all working on hard projects and open to new ideas that will help them find more bugs more quickly.

We also had the pleasure of speaking for the first time in the SNUG technical program, with a talk on “Integration of Portable Test Cases and System-Level Coverage with Verdi HW SW Debug Using VC Apps” in the VC Apps Developer Forum session yesterday. We had a nice response from the 65 or so attendees and were delighted with their interest. Since the talks in this session do not have corresponding papers in the SNUG Proceedings, we’d like to use today’s post to fill in the technical details.

The goal of the project was to integrate the Breker product line, specifically the TrekBox run-time module, with Verdi and Verdi HW SW from Synopsys. Verdi is an industry-leading debug platform for RTL design and verification; Verdi HW SW is an extension that supports software running on embedded processors within the design. We were interested in this integration to provide our mutual customers a better debug experience when one of our automatically generated test cases triggers a bug in a customer design.

The primary feature that we wanted to enable was synchronized timelines between the two environments. Both TrekBox and Verdi have the notion of a cursor that indicates the current time when reviewing the results of a simulation for debug purposes. We observed users copying and pasting timeline values between the two tools to manually synchronize the two views. We asked Synopsys if there was a better way, and they provided our R&D team with an introduction to the VC Apps program. The rest, as they say, is history.

In the following description, when we say “Verdi” the same also applies to the Verdi HW SW product, which would be in use whenever the user is running embedded code.We used the Synopsys VC Apps application programming interface (API) to perform the integration. The first step was writing a TCL script that you include when starting Verdi. The following snippet from  “tbxverdi.tcl” shows how we add a Breker logo to the Verdi menu bar and program it to start TrekBox when you click on it.

Once the Breker icon is clicked, the two tools are running side by side. It is now necessary to connect them. The following snippet is from the C++ file “tbxverdi.cc” that is part of the code running on TrekBox. It shows how we query Verdi for a free communication port in order for the two tools to “talk” to each other.

The next step is to open the communication channel, possibly using the free port identified above. We originally did this, but in the current production version of the code we connect using a known available TCP port since this is more efficient than querying for a free port. The following snippet opens the channel and registers a callback with Verdi to inform TrekBox whenever you change the cursor in one of the Verdi windows.

This is followed by a section of code (not shown) that aligns the TrekBox cursor with the value received from Verdi during the callback.Finally, the following snippet shows TrekBox sending a command to Verdi whenever you change the cursor in one of the TrekBox windows. Verdi then adjusts its cursor so that the timelines are again aligned.

The result of this integration is a seamless debug experience for mutual customers of Synopsys and Breker. Whenever a Breker test case fails its self-check, you can take advantage of all the powerful debug features of both Trekbox and the Verdi platform in order to track down the design bug that is causing the failure. If the test case is purely transactional and generated by TrekUVM, then only Verdi is applicable. If the test case was generated by TrekSoC, containing C code compiled and run in your design’s embedded processors, then the additional features of Verdi HW SW are invaluable.

In yesterday’s talk, we also discussed how you can import our system-level coverage into Verdi and combine it with all the other forms of coverage metrics available. We covered that topic in a recent blog post, so there’s no need to repeat it here. The ability to share coverage and debug information among all the tools you’re using for verification is essential. We’d like to thank Synopsys for providing the open and flexible VC Apps interface for the benefit of you, all of our mutual customers, and the industry at large.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, Breker, DCE, debug, design IP, EDA, functional verification, graph, graph-based, HW SW, portable stimulus, Santa Clara, scenario model, simulation, SNUG, SoC verification, test generation, Universal Verification Methodology, uvm, VC Apps, VCS, Verdi, verification IP, VIP

This entry was posted on Thursday, March 26th, 2015 at 12:03 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.