Used well, the Aspect Oriented (AO) features of the e verification language can save you scarce project time and give you a solution that can absorb change. The trick, of course, is using AO well.
I just saw the announcement for CDNLive! Silicon Valley, to be held September 10-12 in San Jose. I’d encourage you to attend. I had the opportunity to attend CDNLive! Europe in May and found it refreshing for a regional vendor-led conference to pack so much good material, interesting people and effective knowledge sharing into 3 days. There were over 550 attendees. The venue was great and the tone was appropriately ‘real’ for a developers’ conference.
[NOTE: This entry was written in response to some comments posted to my previous entry "Checks or Functional Coverage?". It was only meant to be a couple of line, but got a bit out of hand 
]
In my previous entry "Checks or Functional Coverage?", I made the point that checkers were more important than functional coverage, and that you had to get the checkers done first. Some of the replies said "I agree, but…" and then went on to say that we needed both. I completely agree; the ideal testbench will have checkers and functional coverage. My message here isn’t "do checks and forget about functional coverage". It’s "do the checks for the important requirements before the functional coverage for the important requirements, but do both of these before starting work on the less important requirements, because you might not end up with the time to do it all". That’s not very snappy though, so let’s go with "do the checks first".
31 July 2007 - Fixed a typo.
Why does no one mention checkers any more? All I ever seem to hear is “functional coverage”, “functional coverage”, and more “functional coverage”. It appears that the entire verification industry is in the midsts of a functional coverage love-in that, while might be good for tool sales, isn’t very good for some verification teams.
The historical reasons for this are clear - EDA vendors had to sell new tools, so they went on a functional coverage marketing campaign. They had nothing really new to add to checking, but they sure had those fancy constraint solvers with functional coverage engines to sell. And slowly but surely, functional coverage took centre stage in everyone’s minds.
But it has gone too far. Functional coverage has become such a central pillar of verification that we’ve encountered teams who can tell us in gory detail what they have covered, but can’t tell us what they have checked. In one case, they hadn’t actually checked anything, although they did have 100% functional coverage (which turned out to be wrong anyway).
A quick look at the SystemVerilog LRM suggests that the checking requirement seems to have escaped the language designers as well. Sure, SVA is wonderful, but assertions only go so far towards checking a design (and not really that far when you think about it). What about support for all those higher level checks? Where are the language constructs for checking behaviour and reporting errors in the testbench part of SV? “if()” and “$display()”? Is that really it? That’s not what I was expecting from a language that has been designed for verification.
The functional coverage mantra is so engrained in the verification industry’s psyche that even non-tool vendors are preaching it. Let me quote from Janick Bergeron’s [1] "Writing Testbenches using SystemVerilog":
"Start with functional coverage …Thus, it is important to implement functional coverage models and collect functional coverage measurements right from the start".
He is not alone - I just happened to have his book to hand. Surely it should be something like “Start with checks. Who cares what the functional coverage is if you don’t have any checks? Who cares what the functional coverage says when your implementation metric is only sitting at 10% (e.g. only 10% of testbench code written)?”.
Experienced guys like Janick know that the checks have to be in place, but even the mention of checkers has faded so far into the background that some verification engineers don’t seem to know about them at all.
So what should you really do when writing your testbench?
The point where you start concerning yourself with functional coverage is the point where you start going from the implementation phase (typing in the testbench code) to the closure phase (running tests and debugging). Now sure, I know they overlap quite a lot, but the point is that you get the checks in first because they are important. Functional coverage is a metric - passing checks are a necessity.
Look at it this way - if you had to run a testbench that had checks but no functional coverage, or a testbench that had functional coverage but no checks, which would be better?
Checks - no question about it.
So functional coverage might be the icing on the cake, but it will never be the cake. Checkers are the cake. You have to get the checks in first.
Cheers
David
[1] Ok, he works for Synopsys, but his testbench books are neutral and generic. Buy yourself a copy - you won’t regret it
Thursday morning at DAC I had the opportunity to speak with Larry Lapides, VP of Worldwide Sales for Averant about formal verification and Averant’s formal verification product Solidify. Averant’s formal tools compete with those from Jasper, OneSpin, Cadence, and Synopsys, among others.
This note began as a review of the tech report “The Landscape of Parallel Computing Research: A View from Berkeley“, with David Patterson among the many authors. It turned into a trip down memory lane. By the end, I agreed with them that Something Big is in play.
As ever, I urge you to read the paper. It has received quite a bit of attention, so there is also much surrounding material - the group’s blog is one good jumping-off point.
Music. Dancing. Free food and drink. Did I mention drink? All in a room full of engineers…? As it turns out, Denali Night Fever provided an excellent opportunity for a veritable who’s who of EDA luminaries and the rest of us just along for the ride to relax after a couple of long days at the DAC. The event was held at the On Broadway Event Center just a few blocks away from the
The party itself was a blast, but the more interesting question is whether the same held true for DAC this year. According to Richard Goering, there were 5,135 registered attendees, 3,796 exhibitor attendees, and 400 “other” attendees, for a total of 9,331 people. These numbers are down significantly from last year’s DAC in
Richard’s take was that there wasn’t much exciting going on this year at DAC, but I would tend to disagree. All four of us from Verilab who attended the conference were able to attend interesting product demos and sessions, and met up with people we otherwise would have had to travel far and wide to see. It also gave us a chance to catch up ourselves, as there were Verilab attendees from the
Some of the info at the conference could have been gleaned from attendance at DVCon or DATE. The technical sessions at DVCon were consistently the most relevant to my role as a verification consultant. Its smaller size (710 attendees) made it a good “starter conference” to help kick off the season. DATE was good because it gave me the opportunity to catch up with current/former clients and colleagues of mine in Europe, and to get a better understanding of what the design and verification community in
Is DAC still relevant? For me, the answer is yes. Your mileage may vary. If you’ve never been to any of the major conferences (a situation I found myself in before this year), you’re missing out. My horizons have broadened significantly over the last few months. I’ve got a much better appreciation for the state of the industry, what tools and methodologies are available, and who to call if I need a helping hand than I did back at the beginning of February.
After the keynote on Tuesday I had the opportunity to meet Soha Hassoun, an Associate Professor of Computer Science at Tufts University, while snapping a photo of Steven Levitan (DAC conference chair). Among other things, Soha is involved with a company called Carbon Design Systems. Now, as it turns out I’ve been bombarded with emails from Georgia Marszalek from ValleyPR about Carbon, but for some reason I never fully grasped the value of the company’s product after reading an email description. Based on the additional recommendation from Soha I decided to take a look.
Thursday morning I went by the Carbon booth and spoke with Elizabeth Abraham, VP, Consulting Services and Product Marketing. She gave me an overview of Carbon’s Virtual System Prototype (VSP) software. VSP converts “Verilog, VHDL, and mixed language RTL designs into an ultra-fast, cycle-accurate virtual prototype.” Basically, RTL is converted to high level C software model which can run 10-100x faster than the original design, according to Elizabeth. The other cool feature of Carbon’s product is the ability to debug hardware and software side by side, as bugs tracked down in the generated C code can be mapped back to the original hardware implementation.
I asked Elizabeth how VSP compared with solutions such as the Cadence ISX, which can provide coverage metrics and constrained random testing for embedded software. Based on my understanding of the tools, it appears VSP is focused on verifying the full system hardware/software solution, whereas ISX is focused on testing the interface layer between the system software and hardware (i.e. not the entire software solution). The other difference is that VSP should dramatically speed up simulations whereas ISX would not unless it was paired with a Palladium hardware accelleration box.
I had my first brush with formal methods about 11 years ago when I started my PhD. I was asked to look at the Z language, which would let you write a specification that could be formally proven to be correct. The downside was that, at any given time, there would only be three people on the planet with large enough brains to use it. Part of the complexity of Z was down to the fact that English characters were not allowed (that would have been too easy) - only Greek symbols by the looks of things. I’m not sure how you were meant to type it into a text editor, and I didn’t pursue it far enough to find out.
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.
