Can a tool find bugs without running the design?
Your simulation passes, yet one line adds an 8-bit constant into a 4-bit counter. Every test fed values that fit, so no check ever noticed the extra bits. A second tool reads the same line and objects without running anything: that is the gap this lesson closes.
Lint is static analysis of your source: it reads the text and reports patterns that often mean bugs, with no testbench and no simulated time. A width mismatch widens a value or trims it silently. An unused or undriven signal suggests a forgotten connection. A latch is storage the tools infer where you meant plain combinational logic, usually from an incomplete branch. None of these needs a run to spot, and all of them are cheaper to fix before simulation.
The linter in this course is Verilator, run with --lint-only so it analyzes instead of simulating, -Wall so it reports every warning class, and --top-module naming the design. The Verilator documentation lists every warning code the tool can emit; this lesson needs exactly two of them.
The figure below shows the line this lesson breaks and the two warnings it produces. Each warning names a column: match the column to the token it complains about before reading on.
Lint the course counter as written. The command and its answer:
# captured terminal output
$ verilator --lint-only -Wall --top-module mini_controller rtl/mini_controller.sv && echo lint clean
- V e r i l a t i o n R e p o r t: Verilator 5.048 2026-04-26 rev vUNKNOWN-built20260426
- Verilator: Built from 0.033 MB sources in 2 modules, into 0.008 MB in 3 C++ files needing 0.000 MB
- Verilator: Walltime 0.003 s (elab=0.000, cvt=0.001, bld=0.000); cpu 0.003 s on 1 threads; allocated 9.359 MB
lint cleanThis output came from Verilator 5.048 on macOS. The command asks for analysis only, with all warnings on and the counter as the top. The middle lines are the tool's own report header; the last line is the shell confirming success, because Verilator exits quietly when there is nothing to flag.
No. Lint checks the text for suspicious patterns, never the intent behind it. A counter that adds two instead of one uses perfectly ordinary widths and lints clean, yet fails simulation on every counting edge. Lint asks whether the code looks wrong; only a testbench asks whether it behaves wrong.
Change the increment from a 4-bit constant to an 8-bit one. In a small module holding this counter line, the increment reads count <= count + 8'd1;. Lint it:
# captured terminal output
$ verilator --lint-only -Wall --top-module w widthdemo/w.sv
%Warning-WIDTHEXPAND: widthdemo/w.sv:2:45: Operator ADD expects 8 bits on the LHS, but LHS's VARREF 'count' generates 4 bits.
: ... note: In instance 'w'
2 | always_ff @(posedge clk) count <= count + 8'd1;
| ^
... For warning description see https://verilator.org/warn/WIDTHEXPAND?v=5.048
... Use "/* verilator lint_off WIDTHEXPAND */" and lint_on around source to disable this message.
%Warning-WIDTHTRUNC: widthdemo/w.sv:2:36: Operator ASSIGNDLY expects 4 bits on the Assign RHS, but Assign RHS's ADD generates 8 bits.
: ... note: In instance 'w'
2 | always_ff @(posedge clk) count <= count + 8'd1;
| ^~
... For warning description see https://verilator.org/warn/WIDTHTRUNC?v=5.048
... Use "/* verilator lint_off WIDTHTRUNC */" and lint_on around source to disable this message.
%Error: Exiting due to 2 warning(s)
[exit status 1]Same tool and platform. Two warnings point at the same line from opposite ends. The WIDTHEXPAND warning at column 45 says the addition widens to 8 bits: the constant is 8 bits wide, so the sum follows it. The WIDTHTRUNC warning at column 36 says the 8-bit sum is assigned back into the 4-bit count, so the top four bits are cut away. The last two lines are the verdict: with -Wall warnings are fatal, so Verilator exits with an error status instead of passing.
Both warnings describe one mismatch, so one change clears both. Match the constant to the count:
// snippet
count <= count + 4'd1;This listing is the corrected line: the constant is 4 bits wide like the count, so the sum never widens and there is nothing left to cut. The course counter carries exactly this line, and its lint run above is clean, which is the proof that the pattern behind both warnings is gone.
Skipping lint because simulation passes. Simulation checks only the cases it drives; lint checks the text. The 8-bit constant passes every test whose values fit in four bits and still describes a wider adder than you meant.
Silencing a warning instead of fixing it. Verilator lets you wrap lines in lint-off comments, but a waiver is a documented exception for a deliberate construct, and the waiver policy lives in RTL: Coding Lint. Fix the code first; only a construct you mean gets a waiver.
Starting a comment with the word verilator. The tool reads a comment whose first word is verilator as a control pragma and stops with an error instead of linting. Reword the comment so another word comes first.
Rule: fix the warning instead of silencing it.
One: change 8'd1 to 4'd1 so the constant matches the 4-bit count. The sum stays 4 bits wide, so the expand warning has nothing to widen and the trunc warning has nothing to cut.
No. Lint judges the text; the testbench judges the behavior. A clean lint with a failing test means the bug is in the logic or the intent, like an increment of two, not in a suspicious pattern.
Document it and waive it narrowly around those lines, following the waiver policy in RTL: Coding Lint. Keep -Wall on for everything else: a blanket disable trades one justified exception for silence about the next real bug.
Lint reads the source without a testbench and flags patterns that often mean bugs.
With -Wall, warnings are fatal: one width fix can clear several warnings at once.
Fix each warning where you wrote it; waive only deliberate exceptions with a written reason.