e language users deserve IDE support too

By Tom Anderson | No Comments | Posted: December 10, 2020
Topics/Categories: EDA - Verification | Tags: code optmization, code refactoring, e, hardware design language, HDLs, IDE, integrated design environment | Organizations: AMIQ EDA

Tom Anderson is a technical marketing consultant working with multiple EDA vendors, including Agnisys. His previous roles have included vice president of marketing at Breker Verification Systems, vice president of applications engineering at 0-In Design Automation, vice president of engineering at IP pioneer Virtual Chips, group director of product management at Cadence, and director of technical marketing at Synopsys.

Modern hardware design and verification is enormously challenging, with hundreds of millions or even billions of gates in a single chip. The abstraction level of the development process has been raised multiple times to make it possible to design and verify such chips in reasonable time with a reasonable number of engineers. A key part of this evolution has been the invention of design and verification languages that resemble software programming languages and borrow many important concepts. These languages, while extremely powerful, have complex constructs and require sophisticated methodologies to guide usage and enable reuse. It is highly inefficient, and often virtually impossible, to write the register transfer level (RTL) model for a large design or the hardware verification language (HVL) testbench for the design starting from an empty file in a traditional text editor.

Entry, editing, debugging, and maintenance of RTL and HVL code is much easier with an integrated development environment (IDE). This is one of the good ideas that hardware teams have borrowed from their software peers. Many programming languages are also complex, so programmers found that automated assistance was valuable. They wanted a tool that could check code syntax and semantics, enforce coding styles, and help the software engineers use and modify common language structures. This led to the development of IDEs, and to their eventual adoption for hardware design and verification as well. This article discusses the motivation and capabilities of the IDE, focusing on its value for testbench code. Previous articles in this series have covered SystemVerilog, VHDL, and other languages and formats. This article specifically addresses the use of the IDE for the e hardware verification language.

Advantages of the IDE

Both programmers and hardware developers started writing code using traditional text editors that were designed for natural language text and not formally defined languages. Text is broken into sections and chapters that are relatively independent, but code is highly interconnected. Signals flow between design and verification files, often traversing many levels up and down hierarchies. Methods, signals, classes, and other code structures are defined in one file but may be used in hundreds or thousands of other files. Library elements may be referenced in virtually every file. While many text editors can view a few files at a time, this is insufficient for tracing signals or following the logical flow of the code.

Renaming signals or structures is challenging, especially when similar names appear throughout the testbench and design. The changes may affect many files and it is incredibly tedious to have to bring up each of these files in the editor and manually review changes for correctness. Text editors can do only limited syntax checking because they have no knowledge of the overall design and testbench, and how they are interconnected. Some text editors provide simple templates for adding common code structures but these are also limited because they have no ‘understanding’ of the context. Only an IDE can solve these problems. It has deep language knowledge, sophisticated error-checking, and auto-correction suggestions. Tasks performed by the IDE include:

Running on-the-fly syntactic and semantic checks, and suggesting fixes;
Performing advanced static analysis;
Simplifying code navigation using hyperlinks, semantic searches, and signal tracing;
Providing visual representations like design schematics and state machine diagrams;
Speeding up code writing using auto-complete and code templates;
Highlighting and formatting the code; and
Linking to a simulator for runtime debugging.

They key to these capabilities is the IDE’s ability to compile together all relevant languages (including SystemVerilog, Verilog, e, VHDL, and C/C++) into a unified internal model of the complete design and verification environment. This provides the context needed to enable features impossible with a simple text editor. The IDE compiles code as the engineers type it in, making on-the-fly checks possible. The IDE also provides a powerful and intuitive graphical user interface (GUI) for easy navigation and interactive debug. The IDE provides ease of use and efficiency when entering and editing designs and testbenches, understanding inherited code, and debugging failing test cases during verification. This can save many engineer-years of effort and shorten a chip project schedule by months, reducing time to market (TTM) and making a successful end product much more likely.

Background on e

By the late 1980s, chip verification was facing a crisis. Leading development teams realized that ad hoc design simulation was not good enough, and they also saw the risks in having the same person design and verify. They established verification as a separate discipline, with dedicated engineers developing testbenches to stress-test the designs based on the functional specification. These engineers developed a verification plan listing all the features to be verified, and then checked them off as they wrote and debugged simulation tests. They generally set up tests that would run in batch simulations, with self-checking capabilities to determine success or failure. There was typically some randomization on data values, but randomizing sequences such as bus transactions were difficult to do in Verilog or VHDL. Some verification teams developed ways to measure how well the tests exercised the design, but again this was not easy with the available languages.

The solution to these limitations arrived in the early 90s, when an engineer named Yoav Hollander invented the e language. In 1996 he formed the company InSpec and introduced Specman as a product to compile and run e language testbenches. He wisely designed Specman to run alongside all the major RTL simulators so it could be adopted by any verification team. The language enabled a higher level of verification abstraction with much more automation. Instead of manually specifying inputs, engineers defined the constraints for values and sequences and then Specman randomized inputs obeying those constraints. Structures such as scoreboards and assertions made self-checking tests easier. Object-oriented programming (OOP) provided data encapsulation and aspect-oriented programming (AOP) made it possible for users to overlay new functionality. Dedicated functional coverage constructs made it possible to determine exactly which parts of the design had been verified and which had not.

With all these new capabilities, it is not surprising that e was adopted by many teams developing advanced chips. InSpec was renamed Verisity and was acquired by Cadence in 2005, making e available to an even broader array of users. The language was standardized as IEEE 1647 and was a major influence on the development of the SystemVerilog standard (IEEE 1800). The e Reuse Methodology (eRM) developed by Verisity in 2001 was a key inspiration for the Universal Verification Methodology (UVM) standard (IEEE 1800.2). Despite these new standards, e has several valuable features, most notably AOP, that remain unique. Verification teams benefiting from the language often resist moving to SystemVerilog and giving up their productivity and quality advantages. Since e remains in active use on both existing and new projects, and is an IEEE standard as well, users have every right to expect the same level of IDE support as other verification languages receive.

Searching and navigating e code

As mentioned earlier, the seemingly simple act of navigating through e testbench code is difficult in a text editor, and the IDE provides many more capabilities. Perhaps the most fundamental task is searching for specific types, methods, fields, and so on across what may be a huge set of files. Figure 1 shows an example of how easy this is within the IDE. The user opens the search dialog, types in the string of interest, and chooses whether to restrict the search to specific entities or constructs. In this case, the user is looking for a method, and the matches are displayed. Clicking on a selection takes the user to the precise location of the match in the relevant file. It is easy to refresh search results or recall previous search results. These screenshots and the others that appear in the following examples are from the Design and Verification Tools (DVT) Eclipse IDE from AMIQ EDA.

Figure 1. The IDE can easily search for a method (AMIQ EDA – click to enlarge)

A method, field, struct, unit, or any other entity may be defined in one file and used in many others. The IDE’s complete model of the testbench gives it a comprehensive view of the relationships between the code in different files. In Figure 2, the user has hovered over the name of an entity and clicked on the pop-up menu to show all usages. The results are presented in the same manner as the semantic search shown in Figure 1. Alternatively, the user can hover over a usage and navigate to the definition.

Figure 2. The IDE can find all usages of an entity (AMIQ EDA – click to enlarge)

Similarly, Figure 3 shows the user hovering over the name of a unit and selecting the menu option to show all its instances. The results are presented in the search window and the user can choose to navigate directly to any file of interest.

Figure 3. The IDE can find all instances of an entity (AMIQ EDA – click to enlarge)

One of the more challenging aspects of modern testbenches is choosing the proper constraints for design inputs. Constraint conflicts can be detected by Specman and some simulators, but it is more efficient to find issues much earlier in the design flow. The IDE can help by displaying all constraints in which a variable is involved. In Figure 4, the user has selected a data bus and chosen the menu option to display constraints. Seeing constraints together and reviewing them may reveal errors that can be fixed immediately. As in any search results window, the user can easily jump to any relevant file and the precise location in the code.

Figure 4. The IDE can list the constraints on a signal (AMIQ EDA – click to enlarge)

Assistance when entering or editing code

As the user enters e code, the IDE checks for correctness on the fly and offers ‘quick fix’ proposals that the user can approve or reject. This provides a very efficient way to detect and resolve many types of problems long before simulation is run. Figure 5 shows an example of a typical error that can occur as a user is entering or editing code. The user has referenced an event that does not exist because it has not been declared. The IDE detects the error and suggests adding the declaration in an appropriate location. If the user approves this change, the error is resolved, and the message then disappears.

Figure 5. The IDE can suggest a fix for a missing event (AMIQ EDA – click to enlarge)

In some cases, the user may wish to waive a problem detected by the on-the-fly analysis. A waiver may be used suppress an error that the user intends to address at a later date. As shown in Figure 6, the user can select a waiver rather than accepting one of the quick fix proposals. The IDE provides options to change the default waiver severity, description, path, and message in the pop-up dialog. Once the user confirms the waiver, it is added to a project-wide XML file and respected in future analysis of the code.

Figure 6. The IDE supports waivers for detected issues (AMIQ EDA – click to enlarge)

The IDE’s deep knowledge of the e language enables it not only to detect errors, but also to provide guidance to users when entering new code. For example, the IDE can offer auto-complete options when the user starts typing any type of identifier. Figure 7 shows a list of possible completions in response to a partially entered name. If the user continues typing an undeclared name instead of selecting one of the auto-complete options, the IDE will report an error and offer quick-fix suggestions to declare the new identifier.

Figure 7. The IDE can auto-complete partially entered identifiers (AMIQ EDA – click to enlarge)

When the user starts entering a new e construct, the IDE provides a template showing the code details that need to be completed. In Figure 8, the user has started entering a ‘sequence’ statement and the IDE shows the complete information needed. Template can be customized on a company-wide (global) or per-project basis to enforce specific coding styles and conventions.

Figure 8. The IDE can provide templates for partially entered constructs (AMIQ EDA – click to enlarge)

Refactoring e code

Refactoring operations change code without altering its black-box functionality. A common example is renaming elements in the code, which does not change the structure of the internal model built by the IDE. Renaming is a classic example of a task that is tedious and error prone with a text editor. Changing a name may involve edits to many files, and text editor searches may be difficult to refine. The IDE bypasses these issues by precisely identifying the code that needs to be changed. In Figure 9, the user has selected a new name for an entity and the IDE shows all the changes to the source code so that the user can preview and approve them. All refactoring operations are under the control of the user, who can accept or reject the changes. Upon approval, all relevant files are modified automatically.

Figure 9. The IDE can accurately rename an entity (AMIQ EDA – click to enlarge)

Automatic aligning, indenting, and formatting of e code is also a type of refactoring. Consistent coding guidelines across a project team improve readability and maintainability, especially when engineers inherit code or revisit their own code after a prolonged period. Formatting rules may be enforced on a project-wide or company-wide basis using a configuration file. The IDE supports many formatting options, including:

Trimming end-of-line whitespace;
Compacting consecutive whitespace characters;
Indenting lines using tabs or spaces as specified;
Placing the ‘{‘ character on a new line or the same line;
Vertically aligning language tokens on consecutive lines or on all lines;
Vertically aligning single line comments;
Wrapping a line that exceeds a specified number of characters; and
Ignoring formatting for specified lines.

Conclusion

The e language has unique capabilities that keep it in active use on many leading-edge chip development projects. All the IDE features available for other design and verification languages are available to e users. The IDE detects errors on the fly and suggests fixes, offers auto-complete options and templates for new code, and refactors for better quality. These features fix many types of problems early in the development process, saving critical project resources while reducing time to market.