Every day this week at DAC I’ve been involved in at least one discussion on VMM versus AVM. It’s getting really competitive now. There’s all this talk of standards, Open Source, maturity, and compliance. On top of that, things just don’t stay still long enough to form an opinion that lasts more than five minutes.
Tuesday I had the opportunity to attend the VMM Users’ Group luncheon. The highlight of the luncheon was a panel discussion moderated by Janick Bergeron, Chief Scientist at Synopsys. Before the panel got started, the folks from Synopsys had a few tidbits to share. According to Synopsys, the VMM is the most broadly adopted SystemVerilog library. They were also keen to point out that Synopsys had the highest percentage of reported users on Cooley’s DeepChip verification census.
At DAC this week Synopsys announced the new VMM Catalyst Program, with over 50 founding members (including Verilab). Members of the VMM Catalyst Program get access to the Synopsys VCS Verification Library as well as the SystemVerilog source code for the VMM Standard Library.
Most verification engineers burn themselves at some point by disabling a checker and then forgetting about it. There are sensible reasons for doing this; think about it. You find an RTL bug on Friday, but it doesn’t get fixed immediately. You decide to comment out the checker in order not to pollute the weekend’s regression run. The problem is that you come in on Monday morning and start debugging the new errors you have. The commented out check gets forgotten about.
Burned? I positively set myself on fire doing this on my first ever project. I spotted the commented out check 3 days before code freeze. And guess what it was masking a bug. Ouch.
I haven’t made the same mistake again. In fact, I go to excessive lengths to check that my testbench works correctly. I talk about one method in my book [1], where I create a special aspect that I load up at the start of regressions to verify that the testbench works before I run all of the other simulations. Another method I use is known as error injection (or fault injection, bug injection or mutation) where I’ll deliberately go and break the RTL and check that my testbench catches it.
The problem with this approach is that it can be manually intensive. Determining where the best place to inject a bug is, running an entire regression to see if it is caught, and repeating until you are happy you’ve done enough (and really, how do you know?) is tough.
Not any more though. I caught the Certess demo yesterday, and they seem to have solved the problem. I only saw a demo, but their solution looks pretty push button. You load the design into their tool, it runs a regression to profile your tests and work out which faults should get caught by which tests, and then it injects the faults one at a time and runs the appropriate tests. If they don’t complain about errors, then you have a problem with your testbench.
As far as I know, this is the first time that we’ve been able to measure the quality of a verification environment. So all you verification engineers, IP providers and outsourcing companies out there – be afraid. This thing will tell you what functionality your stimuli isn’t activating, what functionality it isn’t propagating, and what bugs you aren’t detecting. Your boss and customers can now find out how good a job you are really doing.
David
I was feeling a bit jet lagged today at DAC – nothing to do with the wine the evening before – so I decided to visit the Oxygen Party Bar installed at the Mentor Graphics booth. The friendly “bar staff” were only too happy to advise me that a 10 minute shot of the 90 percent concentration of aroma-scented oxygen, would give me “immediate relief”.
We made it through our first day at DAC 2007. It has been several years since I last visited DAC, but it did not seem to be as well attended this year. Aside from that, I saw a lot of new companies, many of which are start-ups trying to find their place in the EDA world. It is mind boggling to see how many companies are evolving to address the many complex design and verification tasks.
(more…)
Power-aware design and verification is a hot topic this year at DAC. I attended the “Design and Verification of Low Power ICs” workshop on Sunday, which mainly focused on Version 1.0 of Accellera’s Unified Power Format (UPF) Standard. The thing I was particularly interested in was how (if at all) UPF could help us functionally verify power-aware logic at the RTL level. If bugs can be found in power implementation at the RTL level, it is far more cost effective and practical than trying to find them at gate-level, or later. The workshop included of a number of presentations from different EDA vendors illustrating how UPF can be used to do just that.
(more…)
Today I had the opportunity to meet with Sean Smith, Chief Verification Architect, and Tim Cook, Staff Software Engineer at Denali. Sean and Tim were kind enough to spend an hour and a half discussing SystemRDL, Blueprint, and PureSpec SystemRDL with me. For those of you unfamiliar with these products, they cn be summarized as follows:
Here is a quick FYI for those of you who may have noticed a bit of a language difference between some of the posts on the blog so far. Verilab has offices in the UK, Germany, and US. As such, the articles on the blog and website may end up alternating between US and UK English. Of course, we all know which one makes the most sense, but to ward off an international incident I’ll concede that either one is grammatically correct, and leave it at that… for now.
By the way, along with the new website we’ve created a new Careers section with a handy form to allow you to submit your resume. We’re actively looking for highly talented individuals to join us. If you’re eligible to work in the US or European Union, please let us know if you’re interested!
JL
I had one of those “Doh! Why didn’t I think of that?” moments at the Mentor booth today. Mentor have a new tool [1] in the pipe called InFact which solves a problem in stimuli generation that you might not even have realised you had [2]. Once it’s pointed out to you, you might start wondering why you put up with it for so long.
Have you ever run a regression and found it took ages to hit those last few functional coverage points? For example, you fully define your AHB transaction, but you never seem to hit that weird WRAP8 BUSY 16bit OPCODE scenario. No matter how many tests you run, it just never seems to get hit, although you’ve hit some other scenarios a million times.
That seems like a bit of a waste of time.
(more…)
