Identifying transactions faster with Verdi

Further to our previous blog entry on Verdi’s advanced Transaction debug features (ref: http://www.cvcblr.com/blog/?p=130 ), here are some more tricks that can help debug automation even further.

 

Very often designers find that there are certain unique characteristics/attributes that differentiate transactions. For instance Transaction kind being ERROR/SPLIT/RETRY etc. Wouldn’t it be nice if on a 50,000 clock cycle simulation dump one can:

• Quickly identify the “information” from “raw data” of signal toggles? (see: http://www.cvcblr.com/blog/?p=130)
• On top of previous item, classify the transactions based on user specified “attributes/fields” such as ERROR/SPLIT/RETRY

This is very handy trick with Verdi. Select Message –> Filter/Colorify as in screenshot below:

 

 

Once you are there, define the attributes in the dialog/pane as shown below:

 

Voila! You get:

 

Add with the signals involved:

 

Now, that’s true “debug automation” and “raising debug abstraction level” in pragmatic sense!

Smart application of vmm_log::disable_types()

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Ever wonder why typical SystemVerilog base classes are bulky and seem to make life complicated against simple things like $display? The devil lies in detail – true simple $display is the easiest to use, but think about the code you are writing to have longer life and reuse – then you slowly start realizing the need. Sometimes you need to get bitten by the downside of not using amethodology to start appreciating the need for methodology.

See: http://www.vmmcentral.org/vmartialarts/?p=1098 for a smart usage of vmm_log::disable_types() method. Many folks have asked me why the VMM_LOG is so bloated (in their view), the above is just a sample, see more @ http://www.vmmcentral.org/vmartialarts/?p=259

Look ma “No RTL, TB, only PSL/SVA – yet I can validate my spec”

It is one of those most commonly asked questions in any assertions training/engagement – assertions describe design behavior, but how can I validate my assertions even before my RTL and/or TB is ready? This is useful for few reasons:

1. Users new to writing assertions using PSL/SVA are expected to make mistakes in assertions initially. So it will be good to get some quick waveforms and validate the assertions in stand alone fashion.

2. While the spec is vague, it creates a mechanism to develop/solidify the spec itself

Typically during the advanced sequences/SEREs section of our PSL (http://www.cvcblr.com/trng_profiles/CVC_LG_PSL_profile.pdf) trainings or SystemVerilog Assertions trainings (http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf) this question invariably comes up.

In principle this is a sweet spot for formal tools (Model checkers) – though not all of them openly promote this nice “hidden gem”. I had first hand experience of doing it via some scripts inside Synopsys not too long ago. But not every user is made aware of this “non-productized” feature.

 

Here is what Jasper had to say on this:

The idea you have mentioned about visualizing assertions in SVA/PSL without DUT/TB has been around within Jasper, for a long while. At that time, one of our customers is trying to train more people within their company to write PSL, and many of the engineers found it easy to write "incorrect PSL", and would like us to provide a tool to help them understand whether the PSL they have written captures the intended behaviors.

I also heard atleast one another EDA vendor confirming its tool being able to easily do this. I will add that name if I get clearance :-)

So as my co-author Ben Cohen (www.systemverilog.us) always insists – YES one can (and perhaps should, for a class of designs/specs) use assertions in SystemVerilog (SVA) and/or PSL during the micro-architecture specification stage itself.

Welcome to the new world of possibilities – true this capability has been around for few years, but I haven’t seen many fully exploiting it yet.

 

Transaction Level Debug with SystemVerilog/VMM and Verdi

In our regular SystemVerilog, VMM trainings (www.cvcblr.com/trainings) we demonstrate the power of callbacks to go beyond the obvious usage – specifically a case study to demonstrate transaction level debug. While this topic has been around for very long time (IIRC, Cadence/DAI first provided it via SignalScan), its real application in day-to-day debug has not been as popular as it should probably be.

Some reasons for the slow progress in debug are due to the tool limitations, some due to user unawareness etc. Today we had this session again at CVC and users really liked it a lot. We decided to open up this stuff as there is more interest and share it with larger community.

We also got Verdi (tm) working on this design with simple addition of $fsdbLog – one doesn’t require extra virtual-interface anymore! Hurray! The Debug champion has once again provided a very useful feature for SystemVerilog, class based environments to be debugged effectively. See some of the screenshots below. A much more lively demo can be seen at:

http://www.slideshare.net/svenka3/transaction-level-debug-with-systemverilog-vmm-verdi

Add simple code for  $fsdbLog – similar syntax as $display:

Start seeing transactions in Waveform (FSDB)

 

Verdi also presents a transaction browser in TEXTUAL form as shown below:

But to be honest – one needs to see the demo with action, try:

http://www.slideshare.net/svenka3/transaction-level-debug-with-systemverilog-vmm-verdi 

for a PPS style. I’m also uploading a Video capture soon. Hopefully it goes through, then it will be lot more fun. If you wish to see it live on your designs, call us via info@cvcblr.com or www.cvcblr.com

Potential research areas on ABV – for a Masters thesis

As part of our BUDS internship program (http://www.cvcblr.com/downloads/BUDs_CVC_Acad.pdf) we work with some of the leading edge educational institutions in India (and one in the USA, BTW). One of our current inters is working on Assertions Based Verification using OVL. In less than a month he has picked up so much so that he says he has learnt more than what he had done (practically) in last semester – it is about that self satisfaction that we consider as our success.

During a recent review at his college, his guide, a very respectable professor in this domain (He is the DEAN of M.Tech VLSI there) has given a very constructive criticism saying:

OVL is fine, but can you add some research work beyond what is obvious/common use to your thesis?

We at CVC felt very happy about that comment – as it reflects on the reviewer’s thirst for highest standards and research inclination and keep us more motivated to go beyond the obvious. So we than him greatly for his inputs via this blog.

Today during a review session we agreed on some of the research topics in this domain, feel free to add anymore if you come across. Even if the present intern can’t take all, a future one can build on this work!

1. Assertion Density –> How many assertions are enough for my design? Look for some research work @ IIT-KGP (http://www.smdp.iitkgp.ernet.in/publications.htm). Also tools like 0-in, VCS etc. present some code level metrics to assist in this space. But more needs to be done. Say assign a “weight” to each OVL element, classify them as per their complexity etc.
2. Clock Domain Crossing (CDC) Verification using Assertions
3. Low Power Verification using Assertions
4. Assertion candidate identification on a given RTL – such as the emerging Zazz bird dog (tm)  (http://zocalo-tech.com/products.php)
5. Assertion Visualization without any TB/RTL. A seemingly close to it technology is available from Jasper (www.jasper-da.com) via their recently announced ActiveDesign (tm) product.

I encourage others to add more topics as comments to this entry so that the academia can focus on next generation challenges!

Why CVC’s trainings are so special

As in any business, there are always lead players and those who try to “mimic” them. We see our trainings also the same way – let’s admit there are few players in this game in our region. However what sets us apart from the rest? Few:

1. First of all we serve the whole industry at large:

• Be it a fresh graduate (via our EIC: http://www.cvcblr.com/trng_profiles/CVC_EIC_profile.pdf, http://www.slideshare.net/svenka3/anubhuti-engineering-incubation-centre-eic)
• An experienced, mid-career engineer looking to re-skill, recently SystemVerilog being the runaway success (http://www.cvcblr.com/trng_profiles/CVC_VSV_WK_profile.pdf)
• Engineering managers, marketing execs who want 10,000 foot view of the VLSI ball game
• Sometimes, engineers from other domains (SW, Mechanical – yes we had one!!) willing to learn basics of Verilog.

Such a wide coverage of audience is very rare if any, even across globe. Again note that many may promise, it is important to deliver and that too with passion and from real experts, who can be named, identified than those typical “interact with industry experts” kind of statements!

As one of our testimonials (http://www.cvcblr.com/testimonials) go:

"...have been practicing for many years just what they teach now. A giant step in the right direction to introduce a quality VLSI design and verification in India!"

Sunil Kakkar, Chief Architect - SKAK INC.

2. We believe in what we do – yes we do NOT cover the whole VLSI flow – every wonder why? Espeically given that other training institutes here do claim that as a BIG deal? Recently an Aldec engineer (Purushottham) here said this:

I wonder why anyone would want to “specialize” on the whole VLSI flow, a typical ASIC/VLSI engineer works for several years on a specific role – either front-end or back-end, and not on both.

At CVC, our belief is that we should create employable talent pool than just some diploma, certificate holders. We infact receive several such resumes for our TDG division from other institutes, recently we had one – someone who is teaching Verilog at an institute, when asked to write some code and add “comments” used “ \\ Verilog comment “. Nothing against any specific individual or org, but just to reflect the state of what we saw.

Indeed I’m grateful to such experiences – that made us to realize the need for our EIC – an incubation center than just a training institute.

It is our genuine interest to place all our trainees – be it freshers or experienced ones – either through our industry contacts/existing customers or internally for our consulting projects. But we have very high levels of quality requirements to be placed – right from code indentation, linting, synthesis to verification. Unless the design, coding, tool usage everything measures upto our quality standards we just can’t hire folks into our TDG – we make that explicit every time we get a chance and NOT at the end alone!

So – to summarize, we BELIEVE in what we do, so if you are looking for a successful career and are willing to put in sincere efforts on your own, come and contact us training@cvcblr.com

 

Thanks for reading!

www.cvcblr.com/blog

Early validation of RTL – with no Testbench!

 

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Looks like Jasper DA (www.jasper-da.com) is on a mission to drive simulation a passé J On a more serious note, their recently announced ActiveDesign (TM) technology sounds pretty interesting for early RTL validation. Before I hear that “Aha..that’s my favourite LINTing”, hold on.. this is much more than that – one can see real waveforms– no testbench is ready yet, but the tool can create quality waveforms for you!

Sounds too good to be true, well their demo indeed shows a very representative real life design – AHB-lite to AXI bridge with 4 AHB-lite masters.

I had a chat with the ActiveDesign team recently to understand what goes “behind-the-scene” (Norris Ip, Holly Stump & Saptarshi all from Jasper). My main doubt on this “early RTL validation” was whether it can work for custom protocols and whether user needs to provide some assertions to get this working. These questions are relevant because we at CVC have prototyped similar stuff for standard protocols via our SVA/PSL based MIPs (Monitor IPs) and some commercially available tool features from other EDA vendors – it involves few hacks and scripting, but doable – if put in some hard work. It requires either an advanced SVA/PSL aware simulator or a model checker/formal tool.

Coming back to Jasper, the short & sweet answer is:

“No, user doesn’t have to create any assertions for getting this. The tool analyzes the RTL code and , based on a few user-interactions with the GUI, waveforms are created". And yes it does work for any design not just for standard protocols” As a side note the tool can create SVA code for the “behaviors/recipes” – more on it later.

The technology is built around Jasper’s popular and proven Visualize (TM) and recently announced “Behavioral Indexing (TM)”. More on the “behavioral indexing” in one of my next entries.

For now, if you are developing a fresh RTL and want to validate it without having to wait for RTL to finish, TB to be ready etc. look at ActiveDesign. Of-course I also highly recommend running LINT before you do that, though Jasper doesn’t have that in this platform. You may want to try some of the new linters such as Aldec’s ALINT, see: http://www.cvcblr.com/blog/?p=99 for a fresh look at Linters.