Cool Verification

Those of you who have been reading Cool Verification since the early days will know that I'm a big proponent of the e language.  The IEEE 1647 working group is looking for volunteers to help develop the next version of the e-language standard.  What follows is a letter from Serrie Chapman, a member of the IEEE 1647 committee.  If you have any questions please let me know and I'll pass them along to the appropriate committee members.

This just in from Andy Piziali, Chairman of the IEEE 1647 e Language Working Group - IEEE 1647-2008 has just been released!  New features include (from the press release):

• Method ports for easy exchange complex data structures and control between verification components and designs under verification  
• Sequences that define, generate and apply complex stimuli that are specifically tailored for module-to-system reuse  
• A host of other features that enable scalability and module-to-system reuse by simplifying module naming hierarchies, structuring data and increasing performance  

Richard Goering had an interesting writeup over at SCDsource on the announcement but made the mistake of quoting Gary Smith:

Gary Smith, chief analyst at Gary Smith EDA, said that SystemVerilog and "e" are not natural competitors. The "e" language, he said, is typically used in large system designs, while SystemVerilog is an RTL language that replaces Verilog. What "e" language backers need to watch, he said, is SystemC – but SystemC's test class library is still "fairly immature."

Huh?  I'm sorry, but the SystemC SCV library, IMHO, competes (poorly) with SystemVerilog.  I don't know of many companies using SystemC for verification.  Of the two I'm thinking of, one of them didn't even know that there was such a thing as SCV until I mentioned it to them recently.  In fact, I'd be interested to hear if any readers of this blog actually use SCV or better yet, even use SystemC for real constrained random verification work (not modeling - I know it's popular in that area).  Gary has fallen victim to the fallacy that SystemVerilog is a single language when, in reality, it is three (design, testbench, and assertions).  The e language competes (rather well thank you very much) with the "Testbench" portion of SystemVerilog.  Based on the above comment I'd say Gary is not smarter than a 5th grader!

As always, questions and comments welcome.

Not surprisingly, I've yet to hear anything from Synopsys regarding the recent rumor about VCS supporting the e language.  While waiting to learn more, I thought I'd take a guess as to what sort of support might exist. 

Believing that Synopsys would actually openly support 'e' ranks up there with believing in the Tooth Fairy (more disturbingly) and Santa Claus.  A more realistic possibility could be for Synopsys to release a tool to convert 'e' to SystemVerilog.  That would let them sell into companies with a large base of existing 'e'  code, but still focus support on SystemVerilog.  If you look back in time a couple of years, you'll see that Synopsys has been offering an 'e' migration service to help clients port 'e' to SystemVerilog.  It's not such a stretch of the imagination to suppose that they've been able to neatly package up lessons learned over the years into an automated tool to assist with some of the heavy lifting.  Add in some native VCS support for constructs that are not easy to duplicate with straight SystemVerilog and you'd have a nice marketing bullet to help convince the heads of purchasing departments at large companies to completely make the switch. 

As always, comments welcome!

Those of you who follow the discussions over on the Verification Guild will have no doubt seen the thread about possible Synopsys support for the e language.  If not, head over there and take a look.  I've been getting bugged by someone from a certain large EDA company that has a vested interest in the language to mention the possibility of VCS supporting e for last few months.  The most interesting part of the entire discussion is that there hasn't been a single comment (unless I missed it) from any Synopsys employee.  In fact, the longer Synopsys doesn't comment on the issue, the more inclined I am to believe there could be some truth to the rumor. 

Janick or Tom - care to comment one way or the other if there is any merit to this?

I have not personally talked to anyone who has seen the e support or has directly heard from Synopsys that it will be supported.  I've only heard the info myself second hand.  Would anyone with direct exposure to the topic care to comment?  I'll be happy to keep your identity anonymous if needed.

Mike Santarini over at EDN recently posted a review of David Robinson's book, "Aspect Oriented Programming with the e Verification Language."  Thanks Mike! 

Recently, I took a look at Cooley's verification survey and came to the conclusion that his methods were flawed. I had the opportunity to speak with Cooley at the Denali Night Fever party this past Tuesday regarding the accuracy of his survey.  It was a challenging discussion, what with a band playing 20 feet away and Cooley sporting a pair of foam earplugs, but it was clear that Cooley still has faith in the results of his survey.  Why?  He's checked with some friends who work as actuaries and also has sanity checked his data against other surveys done by folks such as Gary Smith.  By the time we finished our chat, I wondered if maybe I'd been too harsh on Cooley. 

Update March 23, 2007 - Ok.  One more update.  It looks like if you're using the latest version of emacs/xemacs you should be just fine using the specman-mode.el patch without any additional patching required.  If anyone finds any strange bugs in the updated version let me know or simply send a support request to Cadence, or directly to mac at verilog dot com.

Update March 22, 2007 - I just got a note from Avidan with some new information.  Once you have the new version of Specman mode as described below, you'll need to install filladapt.  Don't ask me how it works - as I mentioned before I know very little about Emacs.  Regardless, once you have both files installed everything works correctly!

After reading Avidan Efody's description of bugs in Specman mode for Emacs and after being admonished by Verilab's resident lisp guru that the code on the site was at least four years old and that there might be a newer version, I decided to check with Cadence support to see if they had a more recent version of the file.  As luck would have it, they did have a newer version (1.22), which has now been posted to the Specman-Mode website.  Now, I'm not usually an Emacs user, but for the sake of all of you who are, I decided to give the new version a try.  Sadly, though I didn't experience the problem Avidan discussed related to '--' comment markes not being parsed correctly, I did still experience the second problem where commenting out lines with symbols such as '{}' made it impossible to enter a new line of text.  I've sent Cadence Support a follow up email and am waiting for a response.  If I learn anything new I'll post it here. (see above for an update!)

Also, I'm very excited to (belately) report that Avidan joined Verilab back in January!  Apparently he did a pretty good job answering all of those tough interview questions :-).  Welcome aboard Avidan!

On Friday afternoon I had an opportunity to speak with Mike Stellfox, Principal Field Verification Methodologist at Cadence.  We had an interesting discussion, which I'll write up in more detail soon, but towards the end of our discussion I asked him what new features we could expect in the near future for Specman.

Update - March 1, 2007: Tom Fitzpatrick from Mentor Graphics has responded to Mike's comments.  For his response, please read Fitzpatrick on SystemVerilog.

Update - February 23, 2007: Just to let everyone know, I contacted Mentor for a rebuttal comment before publishing this story and have shared this material with them since.  If they or Synopsys care to comment for this story I will be more than happy to provide the space for them to do so.  And, as I mentioned at the end of this article, I would be happy to take a look at any existing 3rd-party numbers that may exist regarding the realities about SystemVerilog vs. e adoption rates.

At yesterday's AVM tutorial, Tom Fitzpatrick from Mentor Graphics made a statement that caught my attention.  He declared that "SystemC and SystemVerilog are the only two growing verification standards", and that e and Vera were on the decline.  In the interest of fairness I decided to check with Mike Stellfox, Principal Field Verification Methodologist for Cadence Design Systems.  This was his response:

"It is interesting that Tom would say that SystemVerilog and SystemC are the only two growing verification standards, and that e and Vera are losing ground – I'm sure it has nothing to do with the fact that he works for Mentor and they don't offer an e or Vera solution. The fact is that Specman/e usage continues to grow -  Specman added over 20 new customers logos in 2006, on top of the over 10 logos in 2005 (now nearly 400 customers using e), and Cadence estimates there are over 75,000,000 lines (and growing) of e code in use today. 

"Another interesting stat is that Cadence has recently expanded its presence in over 40 accounts where we displaced other simulators that had previously been working with Specman with the Incisive Enterprise Simulator (where Specman is built in).  It's interesting to note that a significant share of those displacements were Modelsim from Mentor.  Therefore we clearly see Specman/e market growth.  Cadence also sees strong SystemC growth, where I should point out that Cadence has been one of the EDA companies pioneering it for many years in the industry (long before Mentor jumped on the bandwagon). 

"The primary application where we see customers using SystemC is for Transaction Level Modeling (TLM) for early architecture exploration or providing a virtual prototype for early software development, and to a lesser extent for testbench development where we clearly see that most customers prefer e or SystemVerilog – especially when you look at creating constrained random, coverage driven testbenches.  Finally, we also see significant growth in the SystemVerilog market, especially given the fact that it is the newest and therefore is starting from a much smaller base than SystemC or e which are both widely adopted and have been in use for many years.  SystemVerilog is appealing to a lot of people who haven't really adopted constrained random coverage driven verification methodology since everyone is talking about it now.  However, I have found that most customers using e don't see any technical benefits for moving to SystemVerilog, and actually see some limitations and immaturity compared to their current solution (I have heard similar things from Vera customers). 

"The bottom line is that verification is a huge problem today and there will likely continue to be multiple languages required to solve the complete problems at hand.  Cadence is investing in providing the best multi-language simulation platform and methodology with a focus on seamless interoperability between the languages, and IP designed in e, SystemVerilog, or SystemC, so that customers can choose what they feel is best for the task at hand, and still have the capability to leverage IP that may be available in a different language."

It was interesting to see some numbers from Cadence on the current status of Specman usage.  Comments from Mentor and Synopsys (and anyone else for that matter), are definitely welcome!  I find it fascinating from and user perspective that Cadence, Synopsys, and Mentor can look at the verification landscape and come up with such dramatically different opinions.  I haven't seen any numbers from Mentor or Synopsys – does anyone know where to find third party data describing the HVL market?  If so, let me know!  I imagine a similar discussion will play out later today at the low-power panel hosted by Synopsys.  I'll be there, if for no other reason than to see if the attendees are able to stay in their seats, or if tempers will flare (as a few different people have suggested to me could occur).

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.