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.

Signs of maturity in EDA tool built-in examples

During a recent look at ActiveDesign product from Jasper (http://www.jasper-da.com/products/ActiveDesign.htm), I was pleasantly surprised to see a high quality design being used as the case study. Usually such early product demos contain tightly canned examples, showing only the relevant tool features and much less on the actual design. Here is a refresher – we get a very representative real life design – AHB-lite to AXI bridge with 4 AHB-lite masters, a refreshing change in EDA space.

See below for a screenshot of the demo design:

Tool demos are not on dummy designs, becoming more and more realistic indeed!

On a similar note, Breker’s Trek (www.brekersystems.com) has $TREK_HOME/examples that are complete SoC level test synthesis – not just “Hello World”, “foo-bar” anymore! Other interesting designs include a Cache controller model, CPU etc.

Similar is the SoC kit initiative from Cadence (www.cadence.com/products/fv/iv_kit) – this one tops the list of all EDA demos I’ve seen in years on Verification – they started back in late 2007 and have been growing in strength over years. During CDNLive 09 @ Bangalore, CDN showed their roadmap for these kits and clear indications are that these will be extended to ESL platforms too.

Sure all vendors ship more and more examples with their tools nowadays, this also means they employ/engage with real verification engineers besides R&D, support engineers, good for the job market, hopefully :-)

Debug SystemVerilog macros with VCS-DVE

Srinivasan Venkataramanan, CVC Pvt. Ltd.

Rashmi Talanki, Sasken

John Paul Hirudayasamy, Synopsys

An extract from a little lengthier post @ http://www.vmmcentral.org/vmartialarts/?p=922 – focus here only on Debug side on this post:

One of the powerful features of SystemVerilog is the ability to create TEXT macros (those `define s) with arguments – they can create fairly complex code in jiffy. Take a look at VMM source code if you need examples.

In a recent customer engagement, we had to dig deep into VMM atomic Generator code that gets created by the one liner macros!

During the coding work, the customer opened up vmm.sv and got trapped in the multitude of `define vmm_atomic_gen_* macros with all those nice looking “ \ “ at the end – thanks to SV’s style of creating macros with arguments. Though powerful, it is not the easiest one to read and decipher – again for a first time SV/VMM user.

Now comes the rescue in terms of well proven DVE – the VCS’s robust GUI front end. Its macro expansion feature that works as cleanly as it can get is at times hard to locate. But with our toolsmiths ready for assistance at CVC, it took hardly a few clicks to reveal the magic behind the `vmm_atomic_gen(icu_xfer). Here is a first look at the atomic gen code inside DVE.

Once the desired text macro is selected, DVE has a “CSM – Context Sensitive Menu” to expand the macro with arguments. It is “Show à Macro”, as seen below in the screenshot.

With a quick bang go on DVE – the Macros expander popped up revealing the nicely expanded, with all class name argument substituted source code for the actual atomic_generator that gets created by the one liner macro. Along with clearly visible were the facade class name and the actual callback task with clear argument list (something that’s not obvious by looking at standard vmm.sv).

Now, what’s more – in DVE, you can bind such “nice feature” to a convenient hot-key if you like (say if you intend to use this feature often). Here is the trick:

Add the following to your $HOME/.synopsys_dve_usersetup.tcl

gui_set_hotkey -menu "Scope->Show->Macro" -hot_key "F6"

Now when you select a macro and type “F6” – the macro expands, no rocket science, but a cool convenient feature indeed!

The DVE’s macro expansion feature that makes debugging a real fun!