WP_Term Object
(
    [term_id] => 42
    [name] => Amiq EDA
    [slug] => amiq-eda
    [term_group] => 0
    [term_taxonomy_id] => 42
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 7
    [filter] => raw
    [cat_ID] => 42
    [category_count] => 7
    [category_description] => 
    [cat_name] => Amiq EDA
    [category_nicename] => amiq-eda
    [category_parent] => 157
    [is_post] => 1
)

I Thought that Lint Was a Solved Problem

I Thought that Lint Was a Solved Problem
by Daniel Nenni on 11-16-2018 at 12:00 pm

A few months back, we interviewed Cristian Amitroaie, the CEO of AMIQ EDA. We talked mostly about their Design and Verification Tools (DVT) Eclipse Integrated Development Environment (IDE) and how it helps design and verification engineers develop code in SystemVerilog and several other languages. Cristian also mentioned their Verissimo SystemVerilog Testbench Linter, which enforces group or corporate coding guidelines for verification environments written in SystemVerilog. This stuck in my mind because it’s hard to imagine making money selling a stand-alone linter when so much related functionality is already built into the front ends of simulators and logic synthesis tools. So, I started asking more questions.

A little history lesson may be useful. The idea of a dedicated utility to examine code for programming errors and dubious constructs arose in the Unix team at Bell Labs in the late 70s, where Steve Johnson wrote the original version. The name “lint” cleverly captured the idea of getting rid of something unwanted. We have lint brushes for our clothes, lint traps in our dryers, and lint tools for our code. Many typos and simple syntax errors could be detected very early in the coding process, and over time linters added deeper analysis and the ability to find some semantic errors as well.

C programmers who used lint couldn’t imagine life without it. Its fast runtime and precise messages made it an ideal tool for use whenever code was changed. In fact, lint was sometimes added as a “screen” for checking in code to revision control systems. Linters were developed for other programming languages and became essential tools for software engineers. Then, in the late 80s and early 90s, hardware engineers started coding as well. Schematics were replaced by hardware description languages (HDLs) such as Verilog and VHDL. Hardware designers soon faced many of the same debug challenges as their programming colleagues.

In the mid-90s, InterHDL introduced Verilint, which checked for typos, races, dead code, undeclared variables, and more. As with original lint, Verilint ran quickly and produced clear, accurate results. Other companies developed competing products but, over time, most of them were absorbed into the “Big 3” EDA vendors. Many of the linting capabilities were rolled into the front ends of other tools. This leads me back to my opening question of whether there is a place in the market today for stand-alone linters and how AMIQ is being successful.

For a start, Verissimo has the advantage of being faster and better suited to the linting task than simulation or synthesis. But as I dug into Verissimo further, I began to appreciate why it is so popular. One immediate asset is the number of rules: more than 450 according to Cristian, about 75% of them based on the coding guidelines of actual users. This ensures that the problems reported are real issues for real testbenches. Although Verissimo also finds problems in designs, its focus is on testbenches, which are far more complex. This code is not well checked by simulators or traditional linters, while logic synthesis tools never read in testbenches at all.

Further, testbenches use the most advanced object-oriented constructs of the SystemVerilog and Universal Verification Methodology (UVM) standards. That’s why so many rules are needed. In fact, the latest version of the IEEE SystemVerilog standard is more than 1300 pages, and the latest UVM release adds nearly 500 more. With this complexity come overlapping constructs, multiple ways of doing the same thing, and opportunities for language misuse, performance issues, and code maintenance issues. Verissimo enforces best practices for dealing with all these challenges, with rules based on problems found by real users in the past.

22635-verissimo1.jpg
Figure 1: Verissimo displays the results from checking more than 450 SystemVerilog rules

Now that verification consumes much more of a project schedule than design, managers are looking closely at how to improve efficiency. With two or three verification engineers per designer, it is important for all members of the team to be aligned on coding style and interoperability. Cristian points out that testbench linting is a great way to ensure that everyone is following the rules for coding conventions, naming conventions, constructs/patterns/recipes to be used or avoided, and even the organization of testbench files. It brings new team members up to speed quickly, reducing their learning curve and aligning them to the prescribed way of coding. Verissimo also automates most of the traditional manual code review tasks, saving even more project time.

The resource demands of verification also mean that testbench code is more likely to be reused than in the past. Verification harnesses, interface checkers, and other testbench elements are often applicable to multiple generations of designs. In fact, Cristian argues that the lifespan of verification code may exceed the lifespan of actual designs. Sometimes this code lives so long that nobody remembers exactly what it does, but everybody is afraid to throw it away or rewrite it. Testbench linting plays an important role in ensuring that new and legacy code is consistent. Just as with original C lint, Verissimo is frequently used as a screen before check-in.

22635-verissimo1.jpg
Figure 2: Debugging Verissimo rule violations is easy within DVT Eclipse IDE

Verissimo supports the definition of new rules, customization of rules by changing/tuning parameters, enabling, disabling, or setting severity levels, and waiving of specific rule instances. Verissimo can be run from a command line, started from a regression manager, included in a continuous integration process, or invoked from within DVT Eclipse IDE. Cristian notes that it is easier to see and fix errors when running in the IDE GUI, a big improvement over early linters. All its current users also have access to lots of other tools, so clearly Verissimo adds unique value to the design and verification flow. I’m now sold on the idea that a stand-alone linting tool with the right set of features can succeed today. By the way, I also learned that “Verissimo” means “very true” in Italian.

To learn more, visit https://www.dvteclipse.com/products/verissimo-linter.