Home > Community > Blogs > Functional Verification > e users have spoken and voiced their opinions on the benefits of using e over sv
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).


* 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: *

Specman/e Users Voice Their Opinions on Benefits of e over SystemVerilog

Comments(2)Filed under: Testbench simulation, eRM, SystemVerilog, e, Specman, OVM e, Aspect Oriented Programming, AOP, EDA, IES-XL, team specman, Functional Verificatioa, OVM ML, simulation, e language

A recent customer blog interview with Geoffrey Faurie from ST Microelectronics and Richard Goering from Cadence was posted on Cadence.com with the title: "Is e or SystemVerilog Best for Constrained-Random Verification?" This blog post has received much positive feedback from other Specman/e and SystemVerilog users. Whether you are a Specman/e and/or SystemVerilog user, this blog provides a good balance of the differentiators of each language. Geoffrey used an analogy of comparing e to a screwdriver and SystemVerilog to a knife, stating that one can definitely drive a screw with a knife but it will take him/her much longer than with a screwdriver. Geoffrey also stated that he noticed a 30% productivity drop when his team switched from e to SystemVerilog. Wow!!!.....Many other Specman/e users have chimed in and supported Geoffrey's opinion. 

Full Blog interview : Is e or SystemVerilog Best for Constrained-Random Verification?

Check out some of comments from other Specman/e and SystemVerilog users who read Geoffrey's blog:

  • "Excellent summary of differences between the languages. I'd pick e over SV any day" - Dag S Skjelbried

  • "The best product doesn't always win, so we're left with using a knife for putting in eyeglass screws.. ;-)" - Dag S Skjelbried

  • "Having worked on 'e' for many years and moving to other HVLs I strongly support 'e' as a better option for verification engineer, be it productivity, managing code, maintaining code, debugging it & reusing it." - Gaurav Jalan

  • "I've been working with SV for several years and keep reminiscing about my days using 'e'. Everything *seemed* so much easier, but I could never quantify it like M. Faurie has at STM." - Bryan Morris

  • "When I had to learn SV, I at first thought that it is not so bad but not as powerful as e. Now that I have been using SV I am really disappointed with that language. First of all, it does not naturally embrace verification methodology. What I mean with that is, comparing e and SV OVM and UVM, I see the eRM everywhere in UVM, however the UVM seems to not have added much to the eRM methodology but rather "patch" the shortcomings of SystemVerilog to make this language usable. So, I have to say that I completely agree with the rest of the article and also I favor e over SV any time." - Daniel Bayer

  • "The reason there's so much extra code required for OVM/UVM compared to e is because the language does not provide the introspection that e does. It's a ridiculous oversight as the tools already have the capability (they have to have otherwise they couldn't operate at all) - yet verifiers have to jump through hoops defining the obvious simply because there's no introspection." - Paul Marriott

In the past couple of months, Cadence has posted two other customer interview blogs (links below) highlighting the effectiveness of Specman constrained-random verification for complex SoCs. These blog posts showed how Raimund Soenning from Fujitsu Semiconductor and Sarmad Dahir from Ericsson have also transitioned from traditional verification methods to a Specman-based, constrained-random, verification approach to improve their overall verification productivity.

In the interview with Richard Goering, Soenning was asked "Since constrained-random test generation is now available with SystemVerilog, why use the Specman e language?" Soenning responded "Because e has been around for 10 years and is a much more mature language, and in an earlier comparison it appeared to use fewer lines of code than SystemVerilog...Why go for, in our view, the second best solution, when we can go for the best solution?"

"Constrained-random testing is much more efficient than the old directed test approach," Dahir said. "Random testing makes things easier, because you won't have to target every possible scenario." This translates into a time savings -- perhaps 30 percent for the overall verification process. In the old directed test environment, Dahir said, it took 1-2 weeks to rewrite testbenches and resume verification after new RTL came in. With Specman, this only takes a couple of days.

In case you missed these past interviews, you can still read them:

We would like to hear your feedback too on the differences and the benefits of using e and/or SystemVerilog. Feel free to comment.

Kishore Karnane (Team Specman)


By mahesh on March 8, 2012
e is one of the best language to generate random values, this the best verification language.

By mahesh on March 19, 2012
When i try to compare bothe the hvls like specman and system verilog, its easier to learn e language when compare to sv. So in specman automatically every field is randomize so no need to write like $random explicitly. In specman e every constraint is easy to understand and its simply like english language.  
                                                                         - Mahesh.s@sicon tech

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.