Professional VHDL development: What an IDE should provide

A VHDL editor needs to do more than colour keywords. What matters is whether it understands the relationship between files, libraries and instances. Otherwise, an incorrectly mapped package can look like a programming error. When choosing an IDE, start with a real section of a project: at least two libraries, a generic module, a testbench and a reused interface definition. This reveals whether the tool supports the way the team actually works.

Project understanding before convenience features

In a hardware description, the visible filename is only part of the meaning. An entity can have several architectures; a package declaration and its body must agree. The language version and library mapping also determine which names are valid. The IDE should obtain this information from a traceable project configuration. A new workstation must be able to establish the same context without someone selecting files from memory.

Test this deliberately with a small restructuring exercise: move a shared package into its own library and update the dependency. Does navigation remain correct? Does the tool actually report missing references? Does it distinguish between an existing file and an analysed design unit? These questions say more about everyday reliability than the number of available colour schemes.

Code navigation for design analysis

A text search also finds comments and identically named objects in other scopes. Semantic navigation should instead lead to the appropriate declaration. This reduces the effort involved in a change, particularly with overloaded functions, records and generic interfaces. The result remains verifiable: after jumping to a definition, developers check the type, width, direction and library. Navigation does not replace a design review; it makes the review inputs easier to access.

A concrete task works well for an evaluation: rename an output and change its width. First identify every direct instance and the corresponding testbench checks. Then examine which locations the IDE finds and which changes it proposes. Good refactoring preserves meaning; simple text replacement can alter coincidentally named signals or miss indirect dependencies.

Interpreting feedback correctly

A warning while typing can save a separate compiler run, but it does not prove that simulation will succeed. Keep three kinds of feedback separate: language and project analysis in the IDE, analysis by the compiler that will actually be used, and functional checking in the simulator. If the first two disagree, compare language settings, libraries and defines first. Avoid simply hiding all warnings from either side.

Sigasi calls its current product family Sigasi Visual HDL for VS Code. The official manual distinguishes Designer, Professional and Enterprise, together with a licence for the headless CLI. Older references to Sigasi Studio or Eclipse therefore need historical context when planning a new project. Available features depend on the specific edition and licence. Sigasi editions and languages.

A small example of explicit intent

-- Eigenes Beispiel: arithmetische Bedeutung sichtbar machen.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

-- Innerhalb einer Architecture:
-- signal count : unsigned(7 downto 0);
-- signal count_next : unsigned(7 downto 0);
-- count_next <= count + 1; -- modulo 256 durch feste Breite

Explicitly using unsigned makes the intended arithmetic clear. The comment identifies the overflow behaviour that a reviewer would otherwise have to infer. A complete module would also need to describe reset, enable and the transfer to the interface. The IDE can show types and references; the specification determines whether wrapping after 255 is correct. The team should maintain a clear understanding of this boundary.

Team configuration and handover

Shared settings belong in version control; personal window arrangements usually do not. Agree on a small set of mandatory rules: language standard, file encoding, library names, indentation and warning handling. Exceptions need a reason and an accountable owner. Assigning the same severity to every message can easily produce a long list without clear priorities.

A useful introductory project need not take a long time. Ask two people to investigate the same small defect independently, once using the existing workflow and once using the new IDE. Record the steps, misinterpretations and unresolved questions without inventing a general performance figure from them. Then repeat project setup on a fresh workstation. Only then can you assess whether the improvement also benefits the team.

The result should include a versioned project description, a short getting-started guide and a compile or test command that can run independently. The IDE then remains a productive entry point into development, while the verifiable project state exists beyond an individual user session. The next step is covered in the application note on external compilation with Riviera-PRO.

Sources and date

Research checked on 19 October 2026. Sigasi Visual HDL, Sigasi editions and languages.