Renaming and Refactoring in HDL Code

I’ve enjoyed my past discussions with Cristian Amitroaie, the CEO of AMIQ EDA, in which we covered their Design and Verification Tools (DVT) Eclipse Integrated Development Environment (IDE) and their Verissimo SystemVerilog Testbench Linter. Cristian’s descriptions of AMIQ’s products and customers have intrigued me. They seem to be doing very well selling “utility” tools that are largely ignored by the big EDA vendors. The more I learn about AMIQ, the more I see that their tools are successful because they solve real-world user problems when writing, debugging, and maintaining hardware description language (HDL) design and verification code. I have also come to appreciate that there is a lot of technology “under the hood” to enable the tasks they automate.

CEO Interview: Cristian Amitroaie of AMIQ EDA

I Thought that Lint Was a Solved Problem

Easing Your Way into Portable Stimulus

Cristian likes to use the term “refactoring” when describing some of these tasks. I have not heard this word very often in the context of hardware design, and so I did a little research. I found an interesting site called “Refactoring.Guru” that offers this crisp definition:

“Refactoring is a controllable process of improving code without creating new functionality. Refactoring transforms a mess into clean code and simple design.”

Thus, refactoring means making changes in code to improve readability and comprehensibility. My search for this term turned up many references for software programs, but very few for hardware. Modern HDLs, especially SystemVerilog, are very complex and encompass many ideas borrowed from software, including coverage, assertions, and object-oriented programming (OOP). So, it seems natural that refactoring could apply to hardware design code as well.

I learned from Cristian that there are many types of refactoring possible, ranging from consistent formatting of white space and code alignment to significant transformations of the code. Rich languages such as SystemVerilog offer multiple ways to achieve the same functionality. Choosing one way and refactoring the code to follow the chosen style clearly makes it easier to maintain, especially when it is re-used or passed on to someone who was not the original coder. Some types of refactoring may also make HDL code more suitable for the EDA tools that consume it. For example, one style may simulate more efficiently than another, even when the functionality is identical.

I asked Cristian for an example of refactoring that is very common, and he replied with the task of renaming an element (variable, port, function, class, etc.) in the HDL code. This surprised me; renaming at first seems just a simple matter of find-and-replace in a text editor. But it’s not that simple. For one thing, searches often find a lot of similar names. Engineers tend to use common terms such as “counter” or “size” that may apply to many places in the code plus short names often appear as part of longer names. Not all text editors have find-and-replace functions with enough wildcard or regular-expression features to define unambiguously the name to be changed.

Renaming is much harder if there are ripple effects beyond the file being edited. Renaming an input or output, or an element used outside of the file, means that other files must be edited. Historically, engineers have used the Unix family of “grep” utilities to search through the design and verification files to identify where the name occurs, and then edit each such file to make the changes. This is obviously an inefficient process. Depending upon the language and the text editor, it may be possible to use a “Ctags” index to identify more easily which names appear in which file. However, generating and maintaining such an index takes additional effort, especially when the list of HDL design and verification source files, header files, and libraries changes constantly through a project.

As Cristian points out, an integrated development environment such as AMIQ’s DVT Eclipse IDE makes renaming a much simpler task. There’s no need for an index file; the tool takes the same file list used by the simulator, reads in every file, and compiles them together into a single model of the complete design and verification environment. In the IDE’s graphical user interface (GUI), the user selects the element to be renamed and types in the new name. The GUI shows all relevant files, and the user can preview the proposed changes in each file. Renaming happens instantly and accurately, updating both the internal model and the HDL files themselves. This level of speed and accuracy is possible only because the IDE has a complete compiled model and “knows” how every signal is connected and how every code element is used.

I think that renaming is a great example of a seemingly simple HDL coding task that benefits from an IDE and requires strong technology underneath the spiffy GUI. I look forward to learning more about the more advanced forms of refactoring and how DVT Eclipse IDE automates them. Thanks to AMIQ for the education and for providing the screen shot.
To learn more, visit https://dvteclipse.com/products/dvt-eclipse-ide.

Also Read

I Thought that Lint Was a Solved Problem

Easing Your Way into Portable Stimulus

CEO Interview: Cristian Amitroaie of AMIQ EDA

Share this post via:

• 
• 
• 
•