Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Industry Insights > webinar seeks to end the debate e or systemverilog
 
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 Industry Insights blog (individual posts).
 

Email

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

Webinar Seeks to “End the Debate” – e or SystemVerilog?

Comments(2)Filed under: Industry Insights, ESL, specman, OVM, verification, Functional Verification, e, UVM, SystemVerilog, webinar, assertions, SVA, aspect-oriented programming, eRM, object-oriented, Goss

Which language is best for functional IC verification - e or SystemVerilog? A newly archived Cadence webinar attempts to answer this question by analyzing the key capabilities in both languages, and presenting code comparisons that show how the same functionality would be expressed in either language. The webinar then makes a recommendation, but let's first review how it gets there.

The webinar is titled "Ending the Debate: e or SystemVerilog." The presenter is Corey Goss, staff solutions engineer at Cadence. At one point he used a "Mac versus PC" analogy to note how Apple has extended its computing capabilities across many platforms, including TVs, iPads, and iPhones, in addition to laptops. This is similar, he suggested, to the way e can be adapted to just about any task the user might want to accomplish.

The Story of Two Languages

Goss started the webinar by providing a brief history of SystemVerilog and e. There are several important points in this discussion. SystemVerilog has its roots in Verilog, an RTL design language that originally had little support for verification. While SystemVerilog added verification support, vendors still needed to create class libraries to add automation and a consistent methodology. This need culminated in the Accellera Universal Verification Methodology (UVM) standard.

The e language, in contrast, was created about 20 years ago from the ground up for verification. While SystemVerilog uses object-oriented programming, e allows a finer degree of programmer control with aspect-oriented programming. The e language gave rise to the first reuse methodology through eRM, which defined how to architect verification components and build verification environments in a reusable way. It was the basis for the Cadence URM methodology, which joined with the Mentor Graphics AVM to form OVM, which was the basis for today's UVM.

Many people don't know - I did not - that "e" stands for "English." That's because the syntax of e is very English like. Here is an actual line of e code:

if my_list is not empty then (for each in my_list do (print it; ) ; ) ; 0;

As Goss noted, SystemVerilog is seeing a lot of momentum as the newest verification language, but e is a mature, stable language still used by a large number of customers. "Most of Cadence's top customers are using e as their primary language," he said. "We are also now seeing that users are migrating back to the e language after they went off and tried SystemVerilog, because they realized there were some productivity issues there."

Technical Comparison

Goss noted that the methodologies for SystemVerilog and e are essentially identical, largely because UVM has its roots in eRM. But the way that methodology is implemented is different. With SystemVerilog, many automation features are contained in UVM class libraries, not in the language. With e most of these features are in the language itself. Therefore, UVMe is a "very thin class library" that implements some new features like test flows and scoreboards.

When one looks at e and SystemVerilog/UVM code examples side-by-side, what is striking is the much smaller amount of e code needed to implement many functions. In general, according to Goss, SystemVerilog requires about 3X more lines of code than e. The example below shows how a designer might layer a constraint on top of the test environment to guide stimulus. In the SystemVerilog example (gray box on top), to control the length of a packet, you would first create a new derived class called a short_packet_c. You then use the UVM Factory type-override feature to replace every packet_c with the new short_packet_c.

The e language (yellow box), in contrast, is aspect-oriented, and that makes it possible to extend the base packet definition instead of having to create a derived type. Goss showed a number of similar examples in the webinar.

In the webinar, Goss had quite a bit to say about the advantages of aspect-oriented programming. While object-oriented programming lets users encapsulate behavior within objects such as ports and packets, "there are times when we need to add little tweaks of code across all these various objects." Examples of "aspects" that cut across different objects include operating modes, checking, coverage, error injection, and specific tests or corner cases. For example, suppose you want to create a double-speed test for 2-4 slaves using legal delays. This can be set up with a few simple extensions in e. Goss likened this capability to having a set of "control knobs" in the verification environment.

Goss noted that e is the best language for electronic system-level (ESL) verification, given its support for testbenches that extend from high-level SystemC to RTL. Since not all vendors support every SystemVerilog construct or UVM, he also noted that SystemVerilog doesn't yet provide its promised simulation independence and portability. But he identified one area where SystemVerilog outshines e - assertions. SystemVerilog assertions, unlike e temporal constructs, can be used in Cadence formal verification and acceleration tools and provide automated coverage collection.

The Recommendation

The conclusion? "e is the most productive verification language in the industry today," Goss said. He cited its code compactness, aspect-oriented programming, scope from high-level models to RTL, compiled and interpreted modes, and quick ramp-up. On the other hand, SystemVerilog with UVM has some strong points. These include object-oriented programming, SystemVerilog Assertions, syntax familiarity for Verilog users, and the eventual promise of vendor neutrality.

"If you are looking for the most advanced and productive language in the industry today, then e is your choice," Goss concluded. "If for some reason e is not feasible to use, then when paired with UVM, SystemVerilog can be a solid choice for RTL verification. Regardless of which language you choose, Cadence fully supports all IEEE standard languages moving forward."

Richard Goering

Related Blog Posts

User View: Where e Outshines SystemVerilog For Functional Verification

User View: Is e or SystemVerilog Best for Constrained-Random Verification?

Q&A: Why The e Verification Language Is Alive And Well

Comments(2)

By Cedric Fau on September 29, 2011
I definitely agree with these conclusions. Note that you can use SV assertions in addition to your e verification environment to benefit the advantages of the 2 worlds.

I would add that SV has another :

1/ drawback : assertion can not be used in class, limiting their usage

2/ advantage : license cost


By Daniel Bayer on February 7, 2012
Hi Cedric,
I think you raise a good point with the SV drawback, its class based domain can not use SVA. One of the biggest misconceptions of SV is that people think that it is "just an extension of Verilog, which we already know". SystemVerilog's class based language domain is not like the module language domain and for any RTL designer to learn that part of the language is really quite difficult for various reasons.
But one point I don't understand is the SV license cost advantage you mention, SV and e costs are exactly the same and there is no difference if you use SV or e.
Another cost factor should be more important, the costs to develop, debug and maintain code. I think everyone who had the chance to work with both languages will tell you that e is more cost efficient in terms of its development, debugability and code maintenance.

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.