Home > Community > Blogs > Functional Verification > is e old yes is it outdated definitely not
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

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


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Is e Old? Yes. Is it Outdated? Definitely Not!

Comments(2)Filed under: DAC, eRM, e, IEEE 1647, Aspect Oriented Programming, AOP, Object Oriented Programming, EDA, team specman, Corey Goss

I was at the Design Automation Conference (DAC) last week showcasing our latest, greatest Incisive Enterprise Simulator (IES) performance features in the demo suites.  In my "off" time, I was in our DAC booth meeting customers and discussing our advanced verification solutions.  I ran into a long-time SystemVerilog user who had been using that language since the AVM methodology days years ago.  He mentioned to me that he had attended the Accellera UVM Workshop and was surprised to learn that the Universal Verification Methodology (UVM) was derived from the e Reuse Methodology (eRM) and that the e language was, to this day, still the most productive verification language in the industry.  Before the workshop, his impression seemed to be that, since e has been around for so long, surely it must be an antiquated verification solution.

I thought about this a bit more and can see why he may have thought this.  e was invented in 1992.  Next year, it will be turning 20.  20 years is a long time.  A really long time in the EDA world where newer technology tends to render older technology obsolete (Think of what Verilog did to schematic capture, or what C/C++ will do to Verilog in the coming years) and change seems constant. 

What many people do not know is that, since the e language was developed specifically for hardware verification (a world of constant changing specs, features, tests, etc.)  it was built for change.  Yoav Hollander created a verification language in 1992 based on Aspect Oriented Programming (AOP) techniques that allowed engineers to model their verification environments with as many details as possible up front (typical OOP flow), while allowing for users to tweak and tune the environment over time through layering on additional functionality in a non intrusive way (AOP).  The result was an incredibly streamlined and powerful language that allows for code to be managed and maintained in ways unthinkable using any other verification solution, including the best of the best of today's solutions.

Is e old?  Yes.  Is it outdated?  Definitely Not.  Other languages are still trying to catch up.  Remember, SystemVerilog was based on donations from other languages in the early 2000's, all of which did not have the productivity advantage of e at that time.  UVM brings to SV some of the features of e -- however, until the overhead of the class libraries is pulled into the language itself and full AOP capabilities are added, it has a long way to go. 

Corey Goss


By X on June 20, 2011
From my point of view, when it comes to choosing a preferred programming language, regardless of the application, the most important thing for me, is to get from that language flexibility and an ease-to-understand language syntax.
If, and only if, I have that, then I'll will look next at the age of the language - OLDER IS BETTER! why? that is very simple: time is a proof that the language continuously was a reliable solution in passed projects and, because you can easily find online support in the form of tutorials, forums, blogs and so on.
'e' has it all: is the most ease to learn language that I personally ever used and the flexibility is out of the charts. For example, when I write:
this_method() is only {
I think that anybody, regardless of their programming skills will understand that I want to overwrite the body of this_method()
But I don't find the same ease in understanding this: "look, here I defined a class, which I will register to a factory and I'll use that factory to replace the usage of an other class with this class that I just created"
I don't want to pass the wrong message here, I thing its great that there are two reliable programming languages out there,  which I can choose from when it comes to hardware verification.
However, as an "end user" of the languages, what I want to get from SystemVerilog, as a younger language, is a better solution not a copied one.
So far, the feeling is this: if you want performance in verification then choose 'e', if you want lower project costs choose SystemVerilog, but pay the price in verification time and effort.

By tomacadence on June 21, 2011
X, thanks for your comments. You make several excellent points about the advantages of e. I do have to rebut your statement "if you want lower project costs choose SystemVerilog." Note that Cadence does not charge anything extra for e; our IES-XL flagship simulator supports all IEEE-standard languages (SystemVerilog, e, SystemC, PSL, Verilog, VHDL...) with a single license.
Tom A.

Leave a Comment

E-mail (will not be published)
 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.