Originally the term lint comes from a piece of Unix software that was used to warn about suspicious code and non-portable constructs in C programs. The term linter was then adopted to refer to any such program which performs linting tasks.

Generally speaking, a linter does perform a static analysis on a piece of code according to a set of specified rules. It does not care about the functionality or correctness of the code you feed it. Today linting is also used to enforce coding guidelines, flag bad coding practices or warn about code that is known to cause bugs in certain compilers.

The practice of linting was adopted for HDLs for the same reasons as given above and to speed up design analysis in general. In the world of HDL design linting is a great help, since each synthesis tool has its own quirks, bugs and known issues that a linter can warn about and help in circumventing.

The goal of linting is to help cleaning up the HDL code and warn about problems before they occur. Linting is usually carried out before simulation to catch as many issues as possible before entering the simulation phase, but there are some lint tools on the market which operate on netlists as well.

Examples of issues that a linter addresses are:

  • Enforcement of coding guidelines or coding styles.
  • Unsynthesizable constructs.
  • (Unintentional) latches.
  • Undriven or unused signals.
  • Unreachable or unleavable FSM states.
  • Race conditions.
  • Set/Reset conflicts.
  • Out-of-range indices.
  • Incorrect sensitivity lists.

A major drawback of linting that is often criticized is that it carries out a immense number of checks, of which a considerable number are probably duplicates or have become obsolete. The resulting report file therefore can become huge and often contains a large number of false positives. The task of searching the result file for those lint flags which really correspond to a portion of code that needs the attention of a HDL designer can thus become burdensome. Some say most of the time that is saved by using a linter is spent on reading the lint reports.

To reduce the number of false positives and to restrict the linter to those types of checks the user is really interested in, most linters offer a vast number of options and parameters that can be configured. However, even then it often is a challenge to set up a linter to perform only the desired checks. Many EDA vendors are trying to increase the usability of their linter or try to prioritize the flags raised by the linter.

Despite its problems, linting has become an integral part of HDL design flows, especially in the area of design verification.

If you will use a linter or not, it is worth knowing that these helpful tools exist and what they can do for you.