A technical knowledge portal by eVision Systems GmbH

EDA Praxis / Practice & guidance

HDL development and code quality

Keep HDL projects understandable, make changes confidently and use feedback early in the development workflow.

Abstract technical illustration of HDL development.

In an established HDL project, writing a line of code is rarely the hardest part. Finding which declaration is actually used, how libraries relate and what a change affects elsewhere takes more effort. Good development therefore starts with a consistent view of the project.

Project knowledge before convenience features

Define source files, logical libraries, language versions and external dependencies. If the editor and simulator analyse different sets of files, even good diagnostics create confusion. Keep the project description under version control and deliberately include or exclude generated files.

An IDE should then support work on the model: jump to declarations, find references, identify types and carry out traceable renames. Test these features on representative source code, including generic units and referenced libraries.

Which check belongs where?

CheckAnswersAlso requires
Syntax and semanticsIs the description consistent within the project context?Matching language settings and library assignments
LintingDoes the code violate selected structural or quality rules?Rule set, waivers and responsible owners
SimulationDoes the model behave as expected for these stimuli?Testbench and testable expectations

Use tools with a clear purpose

Sigasi Visual HDL supports work on HDL projects within VS Code. ALINT-PRO focuses on static design analysis. Useful checks depend on the risk of failure; an additional diagnostic does not improve quality until the team can assess it.

A useful first project trial

  1. Choose a module with real dependencies rather than an empty demonstration project.
  2. Align files, libraries and language versions between editor and compiler.
  3. Make a small, verifiable change and assess navigation and diagnostics.
  4. Agree on a few relevant rules and document justified waivers.
  5. Confirm the change through a self-checking simulation.

Articles in the code quality section explore IDE requirements and levels of checking. For the interaction between tools, read the shared workflow.

EDA PRAXIS / NEWSLETTER

Fresh perspectives.
Straight to your inbox.

Practical knowledge about HDL, simulation and verification. New articles, application notes and insights into useful tools.