Writing code is hard, especially on projects involving many thousands or even millions of lines. Managing the sheer complexity of such a codebase is challenging—just pulling together all the pieces into a coherent whole is a huge effort.
The code must be verified and debugged, and the fixes must be re-verified to ensure that no new bugs are introduced. The code also changes frequently over the course of a project as new requirements are defined and downstream issues are discovered. On top of all that, the codebase must be maintained as features are added and lingering bugs are fixed in future releases.
For all of these reasons, software programmers found many years ago that traditional text editors were insufficient for projects of any significant size. These editors were designed to work on only one file at a time, or perhaps a few files, with no understanding of code hierarchy or a complete picture of the project.
Integrated development environments (IDEs) were introduced to improve the efficiency and accuracy of writing and maintaining code. IDEs provide easy navigation within and across files, hierarchical views of the complete project codebase, and interactive editing assistance far beyond what a text editor can do.
IDEs were originally developed for such classic programming languages as C and Lisp, but now there’s support for many newer languages. A common belief is that IDEs are relevant only for software languages, leading to a series of myths regarding their suitability for chip hardware design and verification languages. This really makes no sense.
To a casual observer walking through a typical high-tech cubicle farm, it’s hard to tell which engineers are designing hardware and which are coding software. They all write code using complex and sophisticated languages. Thus, it’s important to dispel some misconceptions about IDEs and their value for designers and verification engineers.
1. Hardware languages are too simple to require IDEs.
Nothing could be further from the truth. SystemVerilog, the most widely used design and verification language, is incredibly complex. Its reference manual is more than 1,300 pages and documents nearly 250 reserved keywords.
SystemVerilog supports object-oriented programming (OOP), constrained-random stimulus generation, multiple forms of coverage, register-transfer-level (RTL) design, assertions, and more. Other languages and libraries used in hardware development include C/C++/SystemC, Java, Python, Perl, VHDL, e, Property Specification Language (PSL), Unified Power Format (UPF), Portable Stimulus Standard (PSS), and the Universal Verification Methodology (UVM). All of these formats present their own challenges when learning syntax, semantics, and best practices in coding.
2. IDEs are just fancy text editors.
While “fancy” implies extra features, the term vastly undersells the capabilities of IDEs over text editors. In terms of interactive editing, the most advanced text editors have enough language knowledge to autocomplete some common constructs, flag simple syntax errors, color code according to keywords and user identifiers, and align code via consistent indentation. IDEs provide all this and more, adding checks for semantic errors, suggested fixes for errors, context-sensitive autocompletion, and templates for adding new constructs to the code. These features help new users learn a language much more quickly while saving time and effort even for seasoned veterans.
These advanced capabilities require both intimate knowledge of languages such as SystemVerilog and associated libraries like the UVM. Text editors don’t even parse code, and much more is required. IDEs must compile and elaborate the entire design and testbench “on the fly” every time that a change is made to the code. This generates an internal model with the full hierarchy and interconnectivity readily accessible.
A text editor without such a model cannot, for example, display all possible autocompletions for user identifiers. Even a deceptively simple action like renaming a signal or module is incredibly tedious without a complete internal model. A signal may pass through hundreds of files; a defined module may be instantiated in thousands of places.
With a text editor, the user must manually search through all of those files and make the changes. IDEs automatically trace through the entire design and testbench, presenting the entire slate of code changes for user approval at the click of a button.
3. IDEs are for verification engineers but not designers.
It’s certainly true that the verification team uses more advanced language constructs than designers. For example, OOP is used almost entirely for the testbench and not within the RTL design. Thus, certain IDE capabilities are of most interest to verification users, including class hierarchy and inheritance views.
However, many views are used primarily by designers, including schematics, finite-state-machine (FSM) diagrams, WaveDrom waveforms, and power-domain diagrams based on UPF files (Fig. 1). IDEs generate all of these automatically from the RTL code and supporting files. Designers also really like the ability to trace a signal through the design with a single click, showing all places where the signal is read or written.
Other IDE features of high value to designers include:
- Renaming a port across the entire design hierarchy
- Adding a new port to an existing module and updating all instances
- Connecting an output of one module instance to the input of another module instance
4. IDEs are focused only on editing text.
Although text remains the primary input format for both design and verification code, IDEs provide a wide range of graphical views that help in creation, debug, and maintenance. As mentioned above, there are several views of high value to designers, and others geared toward verification engineers (Fig. 2).
Some views are used extensively by both teams as well as programmers, especially hierarchy diagrams that make it easy to navigate through a large codebase. Control and status registers (CSRs) are the key interface between hardware and software, so both teams benefit from views showing registers and bitfields within them. IDEs connect all text and graphical views together synchronously and interactively, with hyperlinks, cross-probing, highlighting, and consistent coloring.
5. IDEs don’t provide debugging.
Regarding IDEs as tools to be used only in preparing code prior to simulation is too limited a perspective. IDEs may either provide a universal debug module that links to popular simulators or integrate with proprietary debug tools provided by simulator vendors. This adds post-simulation results and waveforms to the many synchronized views available. For example, IDEs allow a user to click on a signal and send it to the simulator waveform viewer.
IDEs also support popular debugging features such as launching simulations, setting breakpoints in the code, examining and changing variable values while simulation is paused, simulating code line by line, resuming simulation, and sending other commands to the simulator. A special debug view allows users to move up and down the call stack, with all other views automatically updated.
6. IDEs can’t generate code.
IDEs modify code and assist in writing code, so in fact they do generate new code. Autocompletion and templates were mentioned earlier; in both cases the resulting output is a combination of user input and generated code. This also is true for refactoring operations that modify code without changing its underlying functionality. Refactored code is easier to understand and maintain. It may also produce better results in simulation or logic synthesis.
For example, a reused section of code can be extracted into a new module or function so that future updates need be made in only one place. Similarly, a reused expression can be replaced by a new local variable. Specific to SystemVerilog, IDEs can swap code back and forth between specification by position or specification by name for module instance port connections and function call arguments. IDEs also offer far more formatting options than text editors for code indentation and alignment to satisfy project and company coding guidelines.
Other electronic-design-automation (EDA) tools generate code from more abstract formats such as Perl-based templates, and IDEs play a critical role in checking this code for correctness and integrating it with handwritten code. They show the abstract code side by side with the generated code and support modifying and saving the template code, automatic re-generation, compiling the generated code, and updating the internal model.
7. IDEs are hard to learn.
It’s hard to see why this myth exists. Graphical environments inherently support learning by doing. Every desired action is only a click or two away. IDEs start up with carefully defined default settings, including keyboard shortcuts, that can be modified easily to suit user preferences. In addition, some IDEs come pre-packaged with options for Emacs and vi keyboard shortcuts, allowing users to flex the muscle memory they acquired from years of using text editors.
8. IDEs are hard to set up.
As above, the default settings for IDEs are selected carefully so that most users will make little or no customization. The goal is “out of the box” use with no setup required. Some IDEs support the command-line arguments of popular simulators, making it trivial to invoke them. Even fully automatic project configuration is available, making the bring-up process as easy as opening a file in a plain text editor.
Some configuration options require more effort and knowledge, such as customizing rule checks and guiding template creation. However, these options are set up on a project-wide or company-wide basis by IDE experts, so most users never have to learn about them at all.
9. IDEs are slower than text editors.
Users should choose the tool best for the task at hand. If all that’s desired is a simple code change, then a simple text editor might be a reasonable choice. It will load a single file faster than an IDE since it has much less analysis capability. However, users tend to keep IDEs open all day, so startup time isn’t an issue. For any more complex tasks, even making simple updates to multiple files, IDEs can do in seconds what would take hours or even days in traditional editors.
10. IDEs cost too much.
Since IDEs provide far more functionality than shareware text editors, it’s entirely appropriate that they cost more. IDEs are productivity tools that accelerate code development, saving precious engineering resources. Many types of bugs are found immediately, with no need to run simulation. Design and verification files are explored quickly, thus avoiding the search/debug loops required with text editors. Common tasks such as adding new constructs and refactoring are accomplished in a fraction of the time consumed by manual editing.
Furthermore, users know that IDEs also save money on projects since they allow for much more efficient use of other EDA tools. Every design and testbench issue detected by IDEs is found and fixed much earlier in the project, and at much less cost than by more expensive simulation, debug, and logic synthesis tools. Finally, as noted above, some IDE refactoring operations yield code that runs more efficiently in these other tools.
11. IDE users lose their language skills.
This simply isn’t the case. Since IDEs provide coding assistance in many forms, they shorten the language and methodology learning curve for new users. These same capabilities also benefit experienced users, who effectively get an ongoing tutorial on syntax, semantics, and best practices every time they create or edit code with IDEs.
Programmers who use software languages have relied for years on IDEs and could not imagine coding without one. Today, the same level of support is available to hardware designers and verification engineers for the languages and formats they use.
A leading solution is the Design and Verification Tools (DVT) Eclipse IDE from AMIQ EDA, bolstered by the DVT Debugger plug-in and the Verissimo SystemVerilog Testbench Linter. Engineers already using this IDE enjoy the same benefits as their software colleagues, as they report in the own words: https://dvteclipse.com/testimonials.