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