Combining syntax checking, linting and simulation

A design can be syntactically correct and still describe the wrong hardware. It can satisfy every style rule and mishandle a rare reset case. It can pass a test that never generates the critical situation. Syntax checking, linting and simulation therefore answer different questions. A useful development workflow organises their results to provide fast feedback early and to let later checks build on an understandable project state.

Syntax and semantics: Is the description valid?

Syntax checking determines whether the source text follows the grammar of the selected language. Semantic analysis also considers names, types, declarations and other language rules. In practice, both often appear together as compiler diagnostics. A missing semicolon needs a different response from an unknown package: the latter may be caused by an incorrect library mapping even when the file itself is correct.

This distinction prevents unnecessary source changes. If many names are unresolved after a project import, first check dependencies, compilation order and the language setting. A local replacement declaration may remove the immediate message while creating a new inconsistency. The aim is a single traceable definition of every shared interface, rather than the fastest possible reduction in the number of messages.

Linting: Which construct is suspicious?

A linter checks rules that go beyond basic language validity. Some concern style and maintainability; others target common design risks. ALINT-PRO describes static RTL analysis and, depending on the rule package, checks including clock and reset domains. Their conclusions depend on the project model, constraints and selected configuration. Aldec ALINT-PRO.

A lint finding is a task that needs context. A justified exception may be appropriate for an intentionally unused interface. An unintended width reduction usually requires a design decision. Disabling the entire rule category removes future warnings as well. Establish how exceptions are justified, reviewed and reassessed when the design changes.

Simulation: What happens under these stimuli?

Simulation executes an elaborated model with specific stimuli. A self-checking testbench compares observed and expected behaviour. That provides stronger evidence than visual waveform inspection alone, but remains limited to the situations actually exercised. If a FIFO never becomes full, a passing run says little about its overflow behaviour. Test planning and observation points therefore matter as much as the simulator.

-- Eigenes Beispiel innerhalb einer Testbench:
assert received = expected
  report "Datenwert stimmt nicht mit dem Referenzmodell ueberein"
  severity error;
-- Der Runner muss severity error als fehlgeschlagenen Test behandeln.

The final comment is part of the test contract. A tool may print an error and still finish with a status that appears harmless to the surrounding script. Severity, stopping behaviour and result handling must therefore be checked together. A deliberately incorrect expected value provides a simple negative test: the complete automation chain must report that run as failed.

1. 01Syntax & semanticsIs the code valid in the language, and can names, types and libraries be resolved?Example: unknown package
2. 02Static rulesWhich constructs and structures are suspicious under the selected assumptions?Example: unintended width reduction
3. 03Simulation & checkerDoes the observed behaviour match the expectation for these stimuli?Example: counter holds when Enable = 0

Compilation is not a simulation test. A passing simulation covers only the cases actually exercised and checked.

One example across all stages

Suppose a counter must increment by one when enable is active and otherwise hold its value. A misspelled signal name is often caught by language analysis. A static rule may report an implicit width reduction. Whether the counter actually holds during a pause in enable requires a targeted functional observation. Reset during operation is another separate case. No single green indicator answers all four questions.

Choose the sequence deliberately as well. It is often efficient to run quick local checks before launching extensive regressions. Debugging an already known functional issue can be an exception: a small targeted test may help sooner than repeating every project check. The mandatory integration run is still required before accepting the change.

Maintain rules as a team decision

Classify findings by impact: code that cannot be analysed, a potential functional defect, unclear design intent or a formatting issue. These categories should not blindly copy a tool’s default colours. A missing reset, for example, can be correct or critical depending on the architecture. Assessment needs the requirement and must not rely solely on a generic rule name.

For existing projects, a documented baseline can help. New defects must not disappear into a large backlog, while every older formatting deviation need not immediately block development. Separate justified existing findings from newly introduced problems and plan remediation by risk. This approach requires clear ownership so that the baseline does not become a permanent exemption.

Create a traceable chain

Keep the source revision, configuration and result together for every run. A developer should be able to navigate from a diagnostic to the source and then to the relevant requirement. Sigasi’s documented external compiler integration can provide an additional early check; successful execution is not yet a simulation result. Sigasi: External compilers.

A useful starting point is a small module with three deliberately separate defects: an analysis problem, a questionable construct and a functional bug. This reveals whether each stage makes its expected contribution. The article on code coverage explains the additional questions that arise even after a simulation test passes.

Sources and date

Research checked on 19 October 2026. Aldec ALINT-PRO, Sigasi: External compilers.