Cool Verification

Public Discourse and Open Standards

Back in May I announced that Verilab had joined Accellera and that specifically, I was a member of the Verification IP technical standards committee.  Later that month, I posted some comments about the discussions going on in the VIP TSC.  Then... nothing.  Of course, there have been several conference calls and a face to face at DAC since then.  Why the radio silence? 

Cadence Offers to Buy Mentor - A Verification Consultant's Perspective

Update: June 18, 2008: Added links to additional commentary about the merger at the bottom of this post.

Update 2, June 18, 2008: What is Certe?  Clarified language and made reference to comments of this post for more discussion.

Last Thursday, after DAC had pretty much come to a close, my colleagues and I headed over to the California Adventure theme park for a bit of fun.  One of the highlights was the Tower of Terror, based on the old TV series, The Twilight Zone. "The Twilight Zone" always opened with the following intro from Rod Serling:

"You unlock this door with the key of imagination. Beyond it is another dimension. A dimension of sound. A dimension of sight. A dimension of mind. You're moving into a land of both shadow and substance, of things and ideas. You've just crossed over into...The Twilight Zone."

I felt like I'd entered into "The Twilight Zone" this morning when I opened my email to see mail from current and former colleagues sharing the announcement that Cadence has offered to purchase Mentor Graphics for $16 per share.  The impact such a purchase could have on the EDA industry are enormous and span many technical and business areas.  As it turns out, I'm only really qualified to comment on one - verification, so the rest of this post will be focused on that topic.  How would a merger affect the lives of those of us who do hardware verification for a living? 

The AOP vs. OOP Saga Continues

A couple of weeks ago I posted a link to an article from Mentor describing how OOP techniques make it unnecessary to use AOP, and supposedly do an even better job than AOP in many cases.  The topic has picked up now over on the Verification Guild - where Adam Rose from Mentor, Janick Bergeron from Synopsys, and a cast of others have been responding to the age old question - "What's the difference between AOP and OOP?"  Check out responses from my co-consultant in crime David Robinson and myself.

Also, if you'd like, I'd recommend checking out a couple of interesting articles written by people using AOP as part of the AspectJ programming environment:

AOP@Work: AOP myths and realities

In the article, Ramnivas discusses in great detail several myths about development in AOP, some of which directly address points made in this discussion thread:

• Myth 1: AOP is good only for tracing and logging
• Myth 2: AOP doesn't solve any new problems
• Myth 3: Well-designed interfaces obviate AOP
• Myth 4: Design patterns obviate AOP
• Myth 5: Dynamic proxies obviate AOP
• Myth 6: Application frameworks obviate AOP
• Myth 7: Annotations obviate AOP
• Myth 8: Aspects obscure program flow
• Myth 9: Debugging with aspects is hard
• Myth 10: Aspects can break as classes evolve
• Myth 11: Aspects can't be unit tested
• Myth 12: AOP implementations don't require a new language
• Myth 13: AOP is just too complex
• Myth 14: AOP promotes sloppy design
• Myth 15: AOP adoption is all or nothing

I'd also like to point out another article by Nicholas Lesiecki, a software engineer at Google:

AOP@Work: Enhance design patterns with AspectJ, Part 1
AOP makes patterns lighter, more flexible, and easier to (re)use

It took years for the software development community to understand how to use OOP effectively.  It will probably take years more for AOP techniques to fully take hold.  That doesn't mean the feature doesn't add value - in my experience, it adds tremendous value.  It also doesn't mean that OOP techniques are obsolete.  If the tools, languages, and libraries most commonly used for hardware verification development weren't under the control of the Big Three EDA companies, we might actually be able to get past this perpetually silly AOP vs. OOP argument and focus on figuring out how to apply the right solutions where appropriate in order to be successful at our primary goal - taping out reliable products as quickly as possible.

They Just Don't Get It

I'm on the "Verification Horizons" mailing list from Mentor Graphics.  Today, one of the items caught my attention.  It was a link to an article entitled It's a Matter of Style: SystemVerilog for the e User.  The article describes how, given the lack of AOP in SystemVerilog, a user can implement some of the features available in Specman.  Technically speaking, they are exactly correct.  Anyone using SystemVerilog (especially if you're used to using e) should read the article and follow the recommendations.  However, the conclusions they draw - namely that there is either no difference between SystemVerilog and e or that SystemVerilog is inherently better - are completely false! 

I can't believe that anyone at Mentor has ever written a serious testbench in e.  The article deserves a point-by-point analysis which I don't have time to write up at the moment.  I'll give it a shot over the next week or two.  In the meantime, check out the article, and let me know what you think!

Creating Corporate Standards? Beware...

As chip design organizations grow and mature, they inevitably start to look at creating a global set of standard tools and methodologies.  There are several benefits to this approach, but there are some major drawbacks that need to be taken into account when developing a corporate strategy for design and verification.

The Wisdom of Crowds

I was fiddling around with my original Blogger-based blog this afternoon and noticed something new.  At the top of the page there was an icon called "Flag".  Apparently Google has instituted a mechanism through which they can unlist objectionable content (the blog is still available but won't be publicized through Blogspot).  They reference a book entitled The Wisdom of Crowds by James Surowiecki.  According to Surowiecki, "decentralized decisions can be vastly better than experts (or the public) expect them to be, or even than any one expert can make."  There are some caveats though -- if the decision structures in place are too centralized, too decentralized, or too imitative in nature they can distort the wisdom of the crowds. 

Interestingly enough, we seem to be going through an inflection point (to quote Andy Grove) in the verification industry related to what types of tools and methodologies we use.  Are we acting as a wise crowd would -- soon to come up with some outstanding solutions to the worlds verification issues -- or are our thought processes being distorted by the structure of the EDA industry and the marketing gurus at the Big Three?  Government agencies have talked about using futures markets to predict things like where terrorists are going to strike or where hurricanes will make landfall.  Maybe we need something similar to help us wade through the muddied-waters of the verification marketplace and focus on the most promising new technologies.