I imagine that the title of this post will remind many of 80s synth-pop, or perhaps the movie The Breakfast Club. But my topic is the venerable hardware verification language (HVL) known simply as e. It has quite an interesting history and it played a key role in the development of the modern testbench methodology that most chip verification engineers use today. I was wondering about the language and where it stands now, and I thought that it would be an interesting topic for a blog post. Let me start with the history. By the late 1980s, functional verification was hitting a wall. In the days of small chips, at best the designers might have hand-written some interesting input values or sequences, run them in simulation, and looked at waveforms to check the results. As chips grew bigger, this was no longer enough.
Project managers saw value in separating design and verification, and during the second half of the 80s dedicated verification engineers became more common. They generally started with a verification plan in a spreadsheet or document, iterating all the features to be verified. The engineers hand-wrote tests for these features, checking them off as they ran and passed in simulation. Verification teams gradually developed more automated methods, including randomized input data and self-checking tests. They started using hardware description language (HDL) line coverage to see how well the tests exercised the design, and some of the more advanced teams added ad hoc functional coverage metrics such as reporting which states in a finite state machine (FSM) had been visited.
In the early 90s, a really smart guy named Yoav Hollander invented the e language to further automate chip verification. He developed the Specman tool to execute the language when linked with an HDL simulator, and formed InSpec (later named Verisity) to market the solution. Specman was introduced as a product in 1996 and it quickly gained favor with teams developing some of the biggest and baddest chips in the world. Specman and e represented a major shift in verification. Object-oriented programming (OOP) provided data encapsulation, inputs were randomized within the bounds of constraints, functional coverage constructs generated precise verification metrics, assertions monitored for unexpected conditions, and aspect-oriented programming (AOP) made it easier for users to add new functionality to existing testbenches.
Cadence acquired Verisity, standardized e as IEEE 1647, and added native support to its line of simulators. The language was a significant influence on SystemVerilog (IEEE 1800), but it seemed that many Specman users had no interest in changing. It wasn’t just because of different syntax; e has several key features, especially around AOP, that were not—and are still not—available in SystemVerilog. There are countless millions of lines of e code in use, and new code is being developed all the time for new projects and even new companies, as experienced verification engineers change jobs and are reluctant to lose the productivity gains they have seen. I checked with friends at Cadence and they confirmed this active usage, noting that they have recently added some new valuable e-related features to Specman Elite and their flagship Xcelium simulator.
The most common rap against e has been that it is a “single-vendor language” but that’s not really the case. Specman Elite enables e support for other simulators and there have been multiple companies over the years offering related tools, Verification IP, and services. One of these is AMIQ EDA, whose Design and Verification Tools (DVT) Eclipse Integrated Development Environment (IDE) includes e support. I touch base with their CEO Cristian Amitroaie every few months, so I asked him about the status of the language. Frankly, he surprised me a bit when he said that they have more than 1000 active users writing testbenches in e. They do have quite a few more SystemVerilog users, but the e-xperts remain e-nthusiastic and have no plans to give up the advantages they enjoy.
From Cristian’s viewpoint, e is just another in a long list of standard languages and formats they support, including Verilog and Verilog-AMS, SystemVerilog, VHDL, Portable Stimulus Standard (PSS), SystemC, Property Specification Language (PSL), the Universal Verification Methodology (UVM), and the Unified Power Format (UPF). He believes strongly that verification engineers using e have every right to expect the same sort of EDA tool features and support as their SystemVerilog and C/C++/SystemC colleagues. Accordingly, DVT Eclipse IDE provides a full range of capabilities. Users can search and use hyperlinks to navigate around the testbench code as well as the design being verified. They can take advantage of specialized OOP and AOP views showing hierarchies, inheritance, and extensions.
DVT Eclipse IDE compiles e code “on the fly” as it is typed in, reporting a wide range of syntactic and semantic errors. Cristian said that he is especially proud of the built-in language intelligence that allows the tool to suggest fixes for many classes of problems, from typographical errors and undeclared variables to errors in complex verification structures. For new constructs being added to the testbench, DVT Eclipse IDE provides easy-to-complete templates that enable correct-by-construction programming. Renaming verification elements is performed with no need for manual searching, and code can be automatically reformatted to satisfy project or corporate coding guidelines.
I found it fascinating to learn how popular e is and to see the high level of assistance available to the many verification engineers devoted to this well-proven solution. As we discussed recently, engineers today live in a polyglot world and it’s great to see AMIQ EDA stepping up to support such a wide range of language and formats as uniformly as possible.
To learn more, visit https://www.dvteclipse.com.
Also Read
The Polyglot World of Hardware Design and Verification
An Important Step in Tackling the Debug Monster
Debugging Hardware Designs Using Software Capabilities
Share this post via:
What is Wrong with Intel?