RTL Bench PRO
Open RTL Bench →

Understanding Lint Warnings

Static code analysis detects structural RTL defects—such as inferred latches, multi-driver conflicts, and undriven wires—before simulation or synthesis. Catching these early saves hours of hardware debugging.

Why RTL Linting Matters

Unlike software compilers that produce executables, hardware synthesis converts behavioral descriptions into physical logic gates. A linter checks your Abstract Syntax Tree (AST) against design rules to ensure your code cleanly maps to synthesizable silicon without unexpected memory elements or conflicting voltage drivers.

The Top Three Lint Violations

  • Inferred Latches: Combinational blocks (always @* or always_comb) missing an assignment in any branch will retain their previous value, forcing the synthesizer to create asynchronous level-sensitive latches.
  • Multi-Driver Nets: More than one procedural block or continuous assign statement driving the same wire, creating electrical short-circuit hazards.
  • Undriven Signals: Nets that are read in logic expressions or module outputs that are never assigned a value.

Fixing Inferred Latches

Always provide default signal assignments at the very beginning of combinational processes, or ensure every if statement has a matching else branch: 

// Bad: Incomplete if statement infers a latch
always_comb begin
    if (enable)
        data_out = data_in;
    // Missing else retains old value -> latch inferred!
end

// Good: Default assignment guarantees pure combinational logic
always_comb begin
    data_out = 8'h00; // Safe default
    if (enable)
        data_out = data_in;
end
💡 Pro Tip: Prefer SystemVerilog always_comb and always_ff over legacy Verilog always @*. Synthesis tools will enforce combinational semantics and immediately flag procedural latch generation.

Frequently asked questions

Why is linting essential before running simulation or synthesis?

Linters catch subtle HDL bugs early — such as undeclared signals, inferred latches, bit-width truncations, and unused variables — that may compile without errors but produce simulation mismatches or erratic hardware behavior.

What causes unintentional latch inference in combinational logic?

Incomplete conditional statements (e.g., an if without an else, or a case statement lacking default cases) force synthesis tools to preserve the old signal value, inferring a transparent latch instead of combinational gates.

How do I interpret width mismatch warnings in Verilog?

A width mismatch occurs when an expression or assignment has mismatched bit-lengths (e.g., assigning an 8-bit sum to a 4-bit wire). The linter flags these to alert you of potential accidental bit truncation or unexpected sign extension.

Next

Try it in the workbench →