With the overwhelming marketing buzz around the modern day verification languages such as SystemVerilog and methodologies such as VMM, OVM, UVM etc. I at times feel sorry for those real soldiers of the Verification army – who carry out most of the verification execution as they are left behind a lot untouched by these “happening stuff”. For them all it matters is “Now that I have a failure, how soon can I narrow down” the same?

In an earlier article inTeamCVC blog, we explored the amount of debug that goes on in the industry, see: http://www.cvcblr.com/blog/?p=93 

Yet, the amount of investment that goes into debug automation is not as much as it should really be – partly the users are to blame – they do NOT often speak out LOUD asking for those “right” features with their vendors.

For a change, this time at SNUG India 2011 some of the audience questions were specifically targeted at this exact Debug menace. Few samples for those who missed it out:

• During Gate Level simulations I see failures say timing violations. How do I correlate the log/console to VPD and the source code – it is pretty much manual and takes way too much time.
• The answer lies with some of the advanced capabilities being developed as you could see in: http://www.vmmcentral.org/vmartialarts/category/debug/ 
• Many modern day waveform viewers provide a nice automation to link these automatically, ask you vendor for more

Amit Sharma did a commendable job in running like the recently introduced Duronto Express of Indian Railways: http://en.wikipedia.org/wiki/Duronto_Express in covering a whole of VCS/DVE/VIP updates in his tutorial. Many wondered if the audience were able to cope up, but surprisingly there were so many involved audience queries that proved such speculations wrong by miles!

Another interesting Debug related query was to do with the Protocol Analyzer feature that Amit introduced and its applicability to custom interfaces. Interestingly the same has been discussed as recently as last week in Accellera’s UVM extensions to add more callbacks to the UVM 1.1 to allow extended transaction recording. If you want to contribute to the same, join us at: http://www.accellera.org/activities/vip 

It will be interesting to see what the debug focused EDA companies like SpringSoft, and the new EDA kid Vennsa have to offer in this space.

Last week at SNUG India, LSI presented a good paper on the topic of Functional Coverage reuse (See: http://www.synopsys.com/Community/SNUG/India/Pages/Abstracts.aspx?loc=India&locy=2011#TA1)

Challenges and Approaches for Functional Coverage in SOC Verification Environments
Manikandan Subramanian, Ron Jacob, Sasidhar Dudyala, Srishan Thirumalai [LSI]

This paper describes the complexity in using block level functional coverage at top level and pitfalls and approaches to aid reuse. This also describes controllability on coverage infrastructure from block level to SOC level and how UVM-EA helped in building the layered testbench infrastructure that can be reused.

What I really liked about this is the level of maturity that the SystemVerilog adoption that this paper indicates in India – while functional coverage is one of the top few powerful features in System Verilog, its adoption has been traditionally slower than what we wished. Especially with the boatload of features, knobs/options to control/fine tune, it is clearly one of those features that is waiting to be explored in greater detail. In this paper Ron laid out a nice architecture for “coverage reuse” across levels of verification. The architecture he & his team proposed can be captured into 3 classes:

• Config class – to configure “How much do you want”
• Coverage class – to capture “what and all you want”
• Coverage collector class – to sample the coverage points

In a way the last 2 points have been stressed by VMM for years, and we at TeamCVC have been recommending it to our customers for years.

Specifically during our popular System Verilog training sessions such as VSV (http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf) we compare this to an athletic race and describe how the “field meters” placed/planted in the filed actually measures the speed while the runners/athletes simply RUN RUn & RUN! 

Now compare this to a classical VMM environment:

The environment with all the components form the “field” while the “transactions” that flow through match the real “athletes”. It makes a lot of sense to plant the “measuring meters” (in this case the “coverage collectors and the coverage models” away from the actual transactions.

This is what Ron’s team experienced too. Though there are some ACC technologies such as ECHO in VCS that traditionally worked better (see: http://www.cvcblr.com/blog/?p=9) with transactions “embedded with covergroups”, VCS’s ECHO has come a long way and has supported VMM style covergroups as well.

The next big challenge that Ron addressed was the “reusability” and need to “control” the amount of coverage at System Level from block level. He had several good guidelines for the users, recommend highly to take down his paper and keep it handy at work! While some of the “sample_cov” overriding can be better done using SystemVerilog 2009 updates to built-in sample() function, a lot needs to be still done. For instance how do we override a full coverage model/covergroup/coverpoint/bins/cross etc. at System Level?

Ron’s approach was to add disable bits – yes, better than not having it, but it doesn’t scale up. Several years back Vera added such AOP/OOP style extensions to covergroups, but due to slow user adoption, this was never ported to SystemVerilog. Talk to Arturo Salz – friendly known as the “Father of Vera HVL” by many if you are interested.Basically the extensions are to allow things like:

• Add extra coverpoint/bin/cross
• Delete/drop a block level coverpoint/bin/cross
• Re-define the entire covergroup etc.

Now – where do we go from here – IEEE-SA invites sincere participation from end-users to set directions, drive language features/enhancements via active participation. See: https://mentor.ieee.org/stds-india/bp/StartPage to know more.

If you’ve missed being at SNUG India DCE 2011 – you’ve truly missed out the high spirits of a great ambience, great food and even greater freebies flowing in from all the participating companies – ranging from bags, pens, mugs, Android Phones, quick reference guides (SVA, UVM), Apple iPods, iTouch, and believe-it-or-not – the all new iPhone4 and of-course the best of all, the popular and most useful SystemVerilog books in the earth: SystemVerilog Assertions, 2nd edition (with IEEE 1800-2009 updates), Pragmatic Approach to VMM adoption and the PSL, IEEE 1850, now part of VHDL- 1076-2009.

TeamCVC’s booth was naturally focused on our core strength, some of the most popular Advanced Verification trainings in India and soon more globally too:

Given the vibrant ecosystem with 22+ participating companies setting up their booths, the ambience was amazing, electrifying and something that Leela Palace “GRAND Ballroom” was literally struggling to cope-up with. There were more than dozen folks mentioning it during the day:

Man, this is crazy, next year perhaps they should find a bigger place

And some suggestions were out for free from some audience too (if Synopsys wants to take tips ):

• ITPL convention centre
• Palace Grounds: http://en.wikipedia.org/wiki/Bangalore_Palace

Coming back to the 2011 event, the attendance at CVC booth was way above average, given the ideal location that one could have asked for – just right at the entrance and opposite to the “most happening” place in the DCE – i.e. the SNUG Prize booth – after all the iPhone/iPad’s were being handed out there, where else would you be?

Here are users eagerly waiting to hear “Who won the iPod” man..

At CVC we strongly believe that it is our “employees” that make the brand TeamCVC so unique and exclusive. With innovative business model that beats the attrition – we have a well established flow (See for our EIC at www.cvcblr.com/trainings) through which we are able to churn out VLSI professionals from fresh B.E. & M.Tech graduates – many fresh from their college. Here is our young army of VLSI folks all raring to go at problems that are just aptly being demonstrated at places such as SNUG!

And what is a better way to reward our TeamCVC booth attendees than providing them free books, calendar, SVA Quick reference guide and an invitation to join the IEEE-SA India initiative https://mentor.ieee.org/stds-india/bp/StartPage

Congratulations to all the winners and thanks for your continued patronage. Together WE can make the Indian VLSI ecosystem the BEST in the world!

Earlier this week at SNUG India 2011, Intel had a very interesting and pragmatic paper on just “how rudimentary” the code coverage analysis tools are as of today. The presenter Ishwar did a great job in all aspects – right from having chosen the right number of slides, clarity and keen focus on the problem he chose to talk about.

Let’s start with the basics – below is a trivial Toggle cov report from VCS’s URG (just as a sample, every major simulator has similar viewer)

While the color coding, hierarchical reporting etc. are useful – the “uncovered” hole analysis is where the users spend lot of time analyzing just “what is not covered and why”? Ishwar’s team has done some out-of-the-box thinking and shown how a simple, logical way to approach the analysis can bring quick results than the “raw” approach that many might follow – blame it on the tools not giving better assistance, if you will. He used 3 criteria to prioritize which holes to look at:

1. How “close” is the net/node/coverage object is to the primary input?
2. How recently did the design/block change?
3. The fan-in/fan-out count

There was a great question from the audience on the #1 above – why not focus on “output” than the “input”. After all we are verifying the design behavior, isn’t it? A great question indeed and a matching answer from Ishwar:

Since we as “stimulus writers” have better control on the inputs, it makes it easier to “fix” the hole thereby improving the coverage number faster. After all if we didn’t even toggle the input pins fully, how do you expect the internal nodes, all the way upto output nodes would toggle?

Now add our TeamCVC’s own twist to it:

• Identifying prioritized set of goals/candidates to look at is a critical next step to get more value out of code coverage. Clearly the industry would benefit from such simple steps especially for those teams to whom the code coverage is a MUST have sign-off criteria (most of the ASICs do demand that)
• While in general coverage analysis is a key process in DV closure, it is important to ensure we “check” what we got “covered” too. Otherwise we get into this infamous phenomenon of “We got it covered, but didn’t get it checked”. Not always easy, especially at code coverage level, but atleast important to keep this in mind while doing the hole analysis. B’cos that’s when you realize “OK, since you told me a scenario that you didn’t cover, let me explain what would make this cover, and also what is expected behavior of the DUT in such cases, and why it is important”.
• A novel, emerging approach to the above problem is to “Begin-with-end-in-mind”. Look at Breker’s Trek – www.brekersystems.com – the whole paradigm of “Scenario models” and “Model based test synthesis” is to start at the “expected DUT” output and expand that to “what stimulus” is needed to get there, and what shall be the expected behavior.
• Zocalo’s Zazz Bird-dog is a tool much like what Ishwar presented that does some deep analysis/heuristics to promote assertions to be written on those candidates. Now one could use the same info with code coverage analysis as well – technically speaking. This has NOT been done/endorsed yet by the developers of the tool themselves, so it is an idea from TeamCVC end based on pure technical perspective.
• NextOp (www.nextopsoftware.com<http://www.nextopsoftware.com>) promotes a technology called "Assertion Synthesis" that infers "properties" from simulation and presents them to users/RTL designers to see if they care about these behaviors (could be classified as assertions or cover hole by the designer). Arguably, there is more work involved here by the designer but you end up high quality RTL.

Looking forward – one would hopefully expect more such papers from the real “Trenches” to highlight/guide the EDA developers to solve the key challenges from “real end-users” such as Ishwar. One topic that keeps bogging us (TeamCVC) together with our customers is the ability to do incremental “exclusion” on coverage holes – say when there are some more comments added to the source code, the old, technically/logically valid exclusion file becomes unusable/non-reusable. Any simulator expert care to comment?

On June 17th 2011 IEEE RevCom has approved the latest updated version of IEEE-1647 e-standard. Some of the exciting new additions include:

• Named constraints – a la SystemVerilog constraint blocks, helps in debug, review etc.
• Much awaited “real” data type – we asked for it back in 2004! Wish granted some 7 years later, better late than never! It also indicates that the language is very much alive and kicking!
• Type constraints
• Constraint extensions – with is only
• e templates – much like C++ – better than user written complex macros
• Named checks – more useful for tools to do “failure triage” for instance
• A full fledged “Reflective API” a la Verilog’s VPI

As noted in recent Cadence blog entry: http://www.cadence.com/Community/blogs/fv/archive/2011/06/16/is-e-old-yes-is-it-outdated-definitely-not.aspx?CMP=home e is old but NOT dead! It is alive and kicking!

Now it is almost time to start contributing to next-gen E language, if you want to contribute, contact us!

If you live in India, specifically Bangalore and work in the field of VLSI, it is hard to miss the well attended SNUG event every year. Just like last year, this year’s SNUG hosts the popular DCE – Designer Community Expo  

http://www.synopsys.com/Community/SNUG/India/Pages/DCE.aspx 

TeamCVC (www.cvcblr.com) will be at Verification track booth and you are welcome to stop by for a range of surprises, quiz & gifts including our various books (www.systemverilog.us). TeamCVC also has a paper co-authored by our CTO Srini (www.linkedin.com/in/svenka3) along with Kishor @Intel and Amit @SNPS, see abstract at: http://www.synopsys.com/Community/SNUG/India/Pages/Abstracts.aspx?loc=India&locy=2011#TA1

What: OVM/UVM paper with Intel-CVC-SNPS: http://www.synopsys.com/Community/SNUG/India/Pages/Abstracts.aspx?loc=India&locy=2011#TA1

When: Thursday June 23, 2011, 10.30 AM

Where: Leela Palace Hotel

What: Meet TeamCVC @ our booth, DCE: Win books, gifts, take quiz etc.

When: Thursday, June 23
Time: 5:15pm – 7:15pm
Location: Grand Ballroom, Leela Palace

At DAC 2011, Cadence introduced yet-another 3-letter buzzword to the wonderful world of Verification – ADS: Assertion-Driven Simulation. Traditionally assertions have been monitors/passive elements, but some high-end formal verification groups have been using it to drive model checkers, random stimulus generators etc. CVC (www.cvcblr.com) has a long history with assertions and we saw this ADS model first with a start-up named Safelogic in Sweden, that got acquired by Jasper a while ago. Under the hood most of the formal tools could do this – be it CDN’s IFV, SNPS’s Magellan etc.

Jasper rolled out ActiveDesign in 2010 and TeamCVC spoke to the developers and blogged it at http://www.cvcblr.com/blog/?p=132

Recently Zocalo (www.zocalo-tech.com) announced VisualSVA product that enables capturing of SVA via a GUI and also provide debug traces

And now Cadence brings it even more closer – down to your Simvision window – with a push of an additional button in your favorite Waveform window you get stimulus, see: http://bit.ly/mo9kjl 

This is certainly encouraging and will propel the industry to increase the much needed assertion density among legacy & new RTL designs to improve the quality of designs.

From a language perspective SystemVerilog 2009 added checker..endchecker and rand variables inside. While the 2009 LRM limits the checker to be “monitors” alone, the recent discussions in the SV-AC IEEE extension groups proposals are emerging to make them “generate random stimulus” from checker blocks too. So stay tuned for more on ADS