Step-by-Step Guide to Running Lint Checks, Catching Errors, and Fixing Them: Industrial Best Practices with Examples

In VLSI design, maintaining clean, error-free HDL code is essential for successful chip development. One of the most effective ways to ensure code quality is by running lint checks—a static analysis technique that detects potential coding issues before simulation or synthesis.

This article provides a practical, step-by-step guide on how to run lint tools, interpret lint reports, catch common errors, and fix them using an industrial approach. We’ll walk through a simple example containing typical linting errors and demonstrate how to resolve them efficiently.

Whether you are a beginner or a working professional, this guide will help you master linting and improve your design workflow.

What is Linting and Why Is It Important?

Linting is a static code analysis process that scans your HDL source code (Verilog, VHDL, SystemVerilog) to identify syntax errors, coding style violations, and risky constructs that may cause bugs or synthesis issues.

Benefits of linting:

• Detects errors early in the design cycle.
• Enforces coding standards and best practices.
• Reduces debugging time and improves reliability.
• Ensures consistency across teams and projects.

Step 1: Prepare Your HDL Code with Intentional Linting Errors

Let’s start with a simple Verilog module that contains a few common linting errors.

Check out Common Linting Errors and How to Fix Them

module example_lint_errors (
    input wire a,
    input wire b,
    input wire clk,
    output wire y
);
    wire unused_signal;          // Unused signal (lint warning)
    reg flag;                   // reg driven in multiple always blocks (lint error)
    wire w;

    assign w = a & b;
    assign w = a | b;           // Multiple drivers on wire 'w' (lint error)

    always @(posedge clk) begin
        flag <= a;
    end

    always @(negedge clk) begin
        flag <= b;              // Multiple drivers for 'flag' (lint error)
    end

    assign y = w;

endmodule

Common Lint Errors in This Code:

• Unused signal: unused_signal declared but never used.
• Multiple drivers on a wire: w is driven by two continuous assignments.
• Multiple procedural drivers: flag assigned in two separate always blocks.

Step 2: Run the Lint Tool

Assuming you are using Verilator (open-source and widely used), run lint as follows:

verilator --lint-only --Wall --Werror example_lint_errors.v

• --lint-only: Run lint checks without simulation.
• --Wall: Enable all warnings.
• --Werror: Treat warnings as errors to enforce strictness.

Step 3: Analyze the Lint Report

Typical lint output might look like this:

%Error: example_lint_errors.v:10: multiple drivers for wire 'w'
%Warning: example_lint_errors.v:6: unused signal 'unused_signal'
%Error: example_lint_errors.v:14: variable 'flag' driven in multiple always blocks

• Errors must be fixed before proceeding.
• Warnings should be reviewed and fixed if possible.

Step 4: Fix the Lint Errors — Industrial Approach

Fix 1: Remove or Use Unused Signals

If unused_signal is unnecessary, remove it:

// wire unused_signal;  // Removed since unused

If needed, ensure it is connected and used properly.

Fix 2: Avoid Multiple Drivers on a Wire

You cannot drive a wire with multiple continuous assignments. Instead, use a reg and assign inside a procedural block or use a multiplexer.

Solution: Use a procedural block to assign w or combine logic.

reg w_reg;

always @(*) begin
    w_reg = a & b | a | b;  // Combined logic or use mux
end

assign w = w_reg;

Or if logic is mutually exclusive, use a mux:

assign w = select ? (a & b) : (a | b);

Fix 3: Avoid Multiple Drivers on a Reg

flag is driven in two always blocks, which is illegal.

Solution: Combine logic into a single always block or use separate signals and combine later.

always @(posedge clk or negedge clk) begin
    if (clk) 
        flag <= a;
    else 
        flag <= b;
end

Or use separate signals:

reg flag_pos, flag_neg;

always @(posedge clk) flag_pos <= a;
always @(negedge clk) flag_neg <= b;

assign flag = clk ? flag_pos : flag_neg;

Step 5: Re-run Lint and Verify Fixes

After applying fixes, re-run the lint tool:

verilator --lint-only --Wall --Werror example_lint_errors.v

You should see no errors or warnings if all issues are resolved.

Integrate Lint Checks into Your Workflow

• Automate linting: Add lint runs to your CI/CD pipelines or pre-commit hooks.
• Use strict linting rules: Enforce consistent coding standards.
• Review lint reports: Regularly analyze and fix issues.
• Document exceptions: Justify and document any suppressed warnings.

Lint checking is a vital step in professional VLSI design, helping catch subtle errors early and improving code quality. By following this step-by-step guide and adopting industrial best practices, you can efficiently identify, analyze, and fix lint errors, ensuring robust and maintainable RTL code.