Sledgehammer to crack a nut? – Use right tools for right class of design errors/bugs

I am sure you have heard this phrase before – “A sledgehammer to crack a nut”; the below picture describes it all!

Would you use a HUGE hammer to crack a small, tiny nut?

(If you are further interested in this phrase read: http://www.phrases.org.uk/meanings/sledgehammer-to-crack-a-nut.html).

I recently had a small design error introduced in a piece of  RTL as below: It is an interrupt masking logic, code snippet as below:

Note the use of “ANDing” logic – simply, AND- mask with data to produce result.The subtlety in Verilog/System Verilog is that you have 2 seemingly similar operators for doing AND operation;

1. The logical AND: &&
2. The bitwise AND: &

Given the “loose” data type checking, assignment rules etc. one can get away by using either one of the above many-a-times. In the above case the user used:

  result = data && mask;

With result being a vector the above is a “logical/design error” but usually a Verilog compiler would let this go through (as it is not an error as per LRM).

Now one can “verify” this by writing a testbench, simulate, look at waveform and debug. Depending on luck and the expertise of the engineer, it could take some 30-minutes to few hours. But as a Verification power-house CVC suggests to rethink – use the right tool/technology for the right class of design errors. These are things that are very easy for a static verification technology such as HDL-Linting to flag in less than a minute.

For instance, let’s try the above code with a popular Linter – ALINT from Aldec (http://www.aldec.com/products/alint/).

 

ALINT has nice rule sets pre-packaged for various policies such as STARC (http://www.starc.jp/index-e.html). It produces the following:

 

This will trigger 2 rules:
  -  rule about logic operation having a vector operand
  -  rule about bit width mismatch in the assignment - LHS vs RHS.

ALINT: Warning: test.v : (4, 1): Module "top". "STARC_VLOG.2.1.4.5" Logical operator has vector argument(s). Use bit-wise operators for multi-bit arguments and logical operators only for 1-bit arguments. Level: Recommendation 1.
ALINT: Warning: test.v : (4, 1): Module "top". "STARC_VLOG.2.10.3.4" Assignment source bit width "1" is less than destination bit width "8". Upper bits of the right-hand side will be filled with zeroes. Match bit widths exactly to improve the readability of the description. Level: Recommendation 2.

 

Now from a business perspective too – this is a far better option for your management – usually LINT tools are far cost efficient than full blown SystemVerilog simulator(s) such as Aldec’s Riviera-Pro http://www.aldec.com/Riviera

So next time when you receive a RTL code to verify, do yourself a favor by running a quick Lint run before looking for “hard bugs” that demand popular, powerful techniques such as Constrained-random, coverage-driven, UVM based etc.

BTW – CVC offers training sessions (http://www.cvcblr.com/trainings) on Aldec’s ALINT and HDL-Lint in general. Contact us (http://www.cvcblr.com/about_us) to see how we can help your teams!

Happy Verification ahead!

UVM with VMM – first trial of true inter-operability

 

As noted in our recent blog article http://www.cvcblr.com/blog/?p=362 UVM is the first genuine step in the industry towards verification inter-operability. But it has a long way to go before all the VIPs get migrated to UVM – if they do. So there is a strong need to leverage on existing code base such as VMM, OVM & UVM.

Below is a code snippet that shows how we can use both VMM & UVM messaging schemes in same env/code base. As such the code is not magic, is it? But do watch below for the real MAGIC..

 

If not for the inter-op kit, the above code would spit the messages from 2 different schemes and make it very hard for end user to keep track, customize etc.

With UVM & VMM loggers being separate and not “inter-operating” the following user issues may arise:

1. Different formatted messages coming at different lines, making it hard, ugly to read, analyze

2. Complicating data-mining of log files as there are 2 different formats now in same log file

3. Error, Warning counts distributed leading to unreliable FAIL/PASS detection

4. Any customization done by user on formatting needs to be done multiple times

5. Sending to different log files not as easy as it involves 2 different base classes now!

 

Again there are more, let’s get solutions on the table. Here comes the MAGIC: With VCS, try:

The log file now combines the `vmm_note into `uvm_info “magically” and unifies it for the users!

 

 

There is much more to this inter-op kit, see: http://www.vmmcentral.com/uvm_vmm_ik/ 

 

Enjoy UVM and more..

Verification inter-operability beyond UVM

As industry gets ready for adopting UVM with SystemVerilog, there are several practical combinations that come to the fore. One of the important concerns is about the existing code base/VIPs that can be “reused as-is”, yet benefit from various UVM features. For instance consider a VMM based VIP being plugged into a new UVM based env. Several user requirements/expectations arise:

1. Can the UVM & VMM co-exist in same simulation?

2. Can we leverage on single messaging scheme – instead of both `uvm_error & `vmm_error counting on their own, how do we unify them?

3. Can UVM phasing control/synchronize the vmm_xacotr::start/stop_xactor?

4. How does the UVM-Objection work with VMM-Consensus?

5. How do we talk from VMM-channel to UVM components and vice-versa?

6.How does the UVM ACTIVE/PASSIVE mechanism control VMM xactors underneath?

7. Does UVM config mechanism affect the VMM, if yes, how, if not then what do we do?

I am sure there are more. But just enough to get you worried! Thankfully the problem seems to have been acknowledged by the EDA vendors and potential solutions have started emerging. For instance the recently released VMM/UVM inter-op kit from Synopsys is at: http://www.vmmcentral.com/uvm_vmm_ik/

 

Another common requirement from many customers is the ability to mix multiple modeling & verification languages with UVM. Cadence recently donated its version of UVM ML (Multi-Language) to Accellera for potential extension. This contains UVM-SystemC via TLM 2,0 and UVM-e for integrating IEEE 1647-E based eVCs to UVM. Though the industry has publically seen only Cadence’s Specman supporting IEEE 1647-E language, if John’s ESNUG were to be trusted (why not BTW?, see: http://www.deepchip.com/items/0495-02.html), it may be soon that all major vendors release E-support.

As noted in our recent blog, http://www.cvcblr.com/blog/?p=361 the upcoming 2012 year seems to be quite interesting for Verification technologies.

Reusing functional coverage from block to system level – LSI @ SNUG India

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.

Meet TeamCVC at next week SNUG India DCE booth

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

Verification gets another buzzword - “ADS” thanks to Cadence

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 :-)

An evening full of Do’s & Don’ts in OVM/UVM with Cliff Cummings

Clifford Cummings (http://www.linkedin.com/in/cliffcummings) is a crowd puller – no doubt. Consider:

• Hot summer mid-day (2 PM start time)
• Bangalore traffic/center of city (potential peak traffic towards end time of 5.30 PM)
• A venue known/infamous for a “HUGE” area but no so frequented by hi-tech community of Silicon Valley of India, past events over there had history of terrible attendance

Yet there were close to 70+ Verification engineers at Cliff’s UVM/OVM seminar aptly titled as:

“Advanced SystemVerilog Tips Including OVM & UVM Tips”

 

It was indeed for Advanced System Verilog users as he had most of the slides on OVM/UVM. TeamCVC (http://in.linkedin.com/in/cvcblr) specifically its trainees, some 11 of them were there cherishing their stint at CVC (www.cvcblr.com) as they hear a world-class seminar and being a fresh graduate, making sense out of that was  a pride on its own. That’s the power of CVC’s time proven EIC training (http://www.cvcblr.com/trng_profiles/CVC_EIC_profile.pdf) that takes in a fresh B.E/M.Tech graduate and turns them to be most sought out Verification engineer in local market.

Madhavi Rao of Cadence (http://in.linkedin.com/in/madhavirao) has done an excellent job in making the event popular and driving it to customers. TeamCVC did their bit, by blogging about it via: http://www.cvcblr.com/blog/?p=325 and also tweeted via: http://twitter.com/cvcblr – for those who believe (still) that Social Media is not engineers/hi-tech, there were more than 5 folks who told me at the event that they heard it via Tweets and they signed-in for the event!

Coming to the event technical content – A good detailed, 60-page write-up by Cliff is at: http://j.mp/gJegMP And for those who cherish/enjoy live-tweets, let’s not repeat all the hardwork TeamCVC had put in live-tweets during the event itself, see: http://twitter.com/cvcblr

The true success of the technical value was evident towards the end – during the High-Tea, almost every attendee had atleast one TIP to go home with (many with more than 1 obviously), I heard things like:

I would not use global_stop_request after run_test

I would not look at enable_stop_interrupt

etc.

Cliff cited JL Gray (http://www.linkedin.com/in/jlgray) for his interesting analogy of OVM’s TLM port-export to the famous Hollywood Blockbuster Avatar Movie. I am still looking for more details on that comparison as it wasn’t easy to catch that link during Cliff’s brief notes.

Cliff’s own explanation of port-export to a driving-a-car using steering-wheel was interesting as well.

Cliff’s session on handling end-of-test was the best pick in this event. Start with the following:

  initial begin : end_of_test_try

    run_test();

    global_stop_request;

  end : end_of_test_try

If you need more details, read: http://j.mp/gJegMP

It was indeed a nice evening with Cliff and other Verification geeks of Bangalore. Now, let’s look forward to how the Pune event goes, maybe http://twitter.com/punechips will provide us the live-tweets :-)