Home > Community > Blogs > Functional Verification > have you considered e lately
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Share
  • Email
  • Social Web
* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

Cadence Contacts

Global Office Locator
Find Offices worldwide »

Sales Inquiry
Request for Product information »
Cadence Channel Partners »

Corporate Headquarters
Cadence Design Systems, Inc.
2655 Seely Avenue
San Jose, CA 95134
Phone: 408.943.1234
* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Have You Considered e Lately?

By Tom Anderson on March 5, 2010Comments(5)Filed under: Testbench simulation, SystemVerilog, e, Specman, verification

Richard Goering's recent interview with Mitch Weaver on the future of Specman and e put me in a reflective mood about my own evolving opinions. My hands-on experience with Specman is minimal; back in my 0-In applications days I co-developed a joint demo with Verisity (prior to acquisition by Cadence) in which I had the chance to do a bit of e testbench coding. I was very familiar with formal at that point, but it was my first exposure to constrained-random simulation and I was impressed.

Six months later I was working at Synopsys, where I was deeply involved in their SystemVerilog rollout. My impression there, based largely on the fact that I talked almost exclusively to SystemVerilog and Vera users, was that e was dead or dying. Fast-forward a couple of years, and I joined Cadence. I can honestly say that nothing I have seen or learned in my time at Cadence has surprised me as much as finding out as soon as I joined just how powerful and popular e really is.

Mitch does not overstate reality at all - Specman and e continue in very broad usage with very few users switching to SystemVerilog and, in fact, new projects and new companies signing up every year. Of course, by now I've had the chance to talk to many e users and I understand how its technical advantages fuel their passion for the language. It's nothing against SystemVerilog to acknowledge that e has some unique features for advanced verification; it's a simple statement of fact.

However, I do talk to the occasional customer who is "e-lergic" (an old Verisity term) and who doesn't even want to hear e mentioned. Some are actually suspicious that our support for e somehow compromises our support for SystemVerilog! As Mitch explains in the interview, this is simply not the case. We support all IEEE-standard languages equally well, and enable just about any combination of e, SystemVerilog, and SystemC models in customer verification environments.

Since there are such strong opinions about e out there, I'm frankly surprised that there have been no comments on Richard's interview. I'll try for some response here since I'm quite curious to know what all you testbench developers really think. If you're unwilling to consider e, I'd like to know why. If you have an open mind on verification languages but didn't choose e, I'd like to know why. If you did choose e, I'd still like to know your reasons. So ... have you considered e lately?

Tom A.

The truth is out there...sometimes it's in a blog.   

 

Comments(5)

By Gaurav Jalan on March 5, 2010
Hi Tom,
Opinion from engineers definitely would be interesting to learn, however more important is the opinion of the decision maker on why he/she didn't realize the power of e over any other language.

By Bryan on March 5, 2010
I'll bite.  I'm pretty much in the camp of unwilling to consider e.  My biggest concern is that, despite being touted as an IEEE standard language, there is still only one vendor that supports it.  Nobody publishes prices, but I hear through the grapevine that it's a pretty pricey single-vendor solution as well.  I'd hate to get myself and my team locked in to that kind of a tool.  Knowing we can run our SystemVerilog design with any of the big simulators is very comforting.  Having the source code to the OVM is also a huge benefit for debugging, reuse, and portability of our design.  
All that being said, I did watch a brief video from DVCON about e[1] and thought about posting this comment there, but I didn't know if it would be an appropriate place to gripe.  I agree with the principles stated in that video, that excessive use of design patterns is generally a sign that your language isn't giving you all the power of what you need[2], and so my curiosity about e has been piqued, but not enough that I'd consider submitting to single-vendor lock-in.
1.  www.cadence.com/.../why-oop-falls-short-for-verification.aspx
2.  The "function" and "loop" design patterns of assembly programming became built-in features of the c language, the pattern of encapsulating data and function pointers inside structs in C programming became classes in C++, and so on

By tomacadence on March 5, 2010
Bryan, thank you for the thoughtful comments. The single-vendor argument may not apply; there has been much online discussion about one of our simulation competitors supporting e as well (for example, see http://tinyurl.com/yzyvdef or http://tinyurl.com/ydo2och).
As for pricing, it's certainly true that a customer buying Specman from Cadence and a simulator from another vendor is spending more than they would if they bought just that same simulator. However, note that Cadence Incisive Enterprise Simulator XL (IES-XL) runs SystemVerilog and e (and SystemC) all for the same price. We don't charge "extra" for one verification language over another.
Finally, I agree with you on the value of the OVM SystemVerilog source code; note that we also provide open-source libraries for OVM e and OVM SystemC in the Community Contributions area of OVM World.
Tom A.

By Bryan on March 6, 2010
Unfortunately, that online conversation was from nearly 2.5 years ago.  The only recent info about e support from a Cadence competitor that I could find was this:
www.synopsys.com/.../evcs_ntb.html
A service to migrate from e to SystemVerilog.  Not very promising.  Like I said, I want to be able to give e a chance... Maybe there is something Cadence could do to foster broader adoption and support among vendors of this standard. ;-)

By Patrick on March 8, 2010
Hi all.

I thought I d say a word regarding this "provider lock" Bryan mentions.

If you take a step back, you can easily  realize 3 things

- First, this objection to e has nothing to do with technical aspects. Those who, recently or years ago, made the choice to base their verification on e, all understood its technical superiority and benefit, and this took over the fact that they would have to pay for it every year.

In other terms, they all consider the gain on productivity is still superior.

- Second, being an active user of ovm SystemVerilog as well as e, I would say the superiority of e is less relying today on the language than on the features in the Specman tool enabled by the e language. It would take me around the same time to create a verification environment in e or SV, but to debug it and to be able to maintain it, there is no comparison on the time you gain by using Specman. Use the command line interactively in a simulation to query your verification environment, visualize objects, reload the testbench without recompiling the design and relaunch the test, have a unique generation debugger... all of those features are possible only in Specman and possible only with the e language. Also Cadence realized how much bad impact debug time has on projects, and is working on new technologies around this.

- The last point is harder to realize, but is true : Specman is the only real interroperable tool to any simulator. I ve heard many time people telling that their reason for choosing SystemVerilog was to have a language that would work with any simulator. For those who had to port SV environments from another vendor to IES or vice versa, they could easily tell you that this no effort portability is purely theorical. Even if you arrange your files to get syntaxes as basic as able to compile and elaborate correctly in all simulators, the tests themselves, based on randomness will anyway finish up being different as there is no algorithm set for random generation. In parallel, for those who switched simulator with a Specman environment, the effort was minimal as you have a dedicated tool for verification, completely agnostic to the simulator it interacts with. Still, you have to pay Cadence for it, but again, compare the money you spend against the time you pay your engineers to work without the best tools.

My 2 eurocent.

Patrick

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.