Problem and objective
An HDL project can appear plausible in its development environment yet produce a diagnostic when analysed by the compiler used later in the workflow. Tool-specific rules, different language settings or inconsistent libraries may be responsible. This note explains how to check a Sigasi project additionally with Riviera-PRO’s external compiler. The objective is a reproducible compilation step in the editor and an understandable interpretation of its results. A successful compiler run is explicitly not presented as a successful simulation.
The workflow uses the current Sigasi Visual HDL documentation for VS Code. Its documented task is called sigasiRivieraCompile. Historical instructions for Sigasi Studio in Eclipse may show different menus and configuration files. New projects should therefore use documentation for the product generation actually installed. This note does not claim that an equivalent current built-in Active-HDL task exists. Sigasi: External compilers.
Prerequisites and version scope
- A legitimately usable Sigasi Visual HDL installation in VS Code and a working project target.
- A legitimately usable Riviera-PRO installation with accessible compiler executables.
- A small VHDL project without FPGA vendor IP for the first integration attempt.
- Documented language settings, library names and actual local installation paths.
- A separate working directory for generated compiler artefacts.
The source review date is 19 October 2026. At the time of research, the current Sigasi download archive listed 2026.4.1. This records the state of the source, rather than claiming that this version is installed on the present machine or already approved for every team. After installation, check the displayed version and compare the available task properties with the corresponding manual. Sigasi Visual HDL Download Archive.
Editions and licence rights must match the intended use. The Sigasi manual distinguishes use inside the IDE from a headless CLI in automation. An editor licence available for this exercise must therefore not be interpreted, without checking, as permission to operate arbitrary CI runners. Likewise, a simulator installation alone does not confirm available licence access. Binding terms come from the applicable licence agreement. Sigasi editions and languages.
Workflow architecture
Versionierte Quellen + Sigasi-Projekt-Target
|
v
Sigasi-Projektanalyse und Task-Konfiguration
|
v
Externer Riviera-Compiler -> Compilerdiagnosen
|
v
Separater Simulationslauf -> Testbench-ErgebnisThe two result types remain separate. The compiler examines the selected source set. Simulation additionally needs a top level, elaboration, stimuli, run control and a defined check. This separation also aids diagnosis: an analysis error is investigated first in the project configuration or source, whereas an assertion failure later belongs to functional checking. A single green status without that distinction would be misleading.
Step 1: Prepare a small target
In a new working directory, create rtl/counter.vhd and tb/tb_counter.vhd using the files from the testbench note. Use the installed Sigasi project interface to create a target named counter_demo. Assign both files to the same logical library and select VHDL-2008. The precise project description should be generated by the interface or the documented import mechanism for the version in use.
Check the project model before enabling the external compiler. The testbench must resolve its DUT instance and the IEEE packages must be available. Deliberately leave out vendor IP at this stage. A minimal project reduces the number of simultaneous possible causes and makes later comparison with an automated test easier. Save the generated project configuration alongside the sources.
Step 2: Make the compiler independently discoverable
In the intended terminal, check which Riviera installation is actually being invoked. Mixed development environments can have several programs named vcom on the search path. A successful invocation therefore does not yet establish that the correct product has started. If uncertain, use the actual full path and record the version-query output according to the locally installed vendor manual.
Pay attention to the editor’s environment. A search-path change may not be inherited by an application that is already running. Restart the editor with the intended environment or specify the appropriate installation path in the task configuration. Licence variables and confidential licence files do not belong in a public project. The startup guide can explain their purpose without storing private values.
Step 3: Generate the task through Sigasi
Open the Projects View, select the target and choose Automate Designflow from its context menu. Select the external compiler Riviera Compile. Leave watch mode and automatic startup disabled for the first attempt so that every run is initiated deliberately. The manual describes this process and the generated .vscode/tasks.json file. Sigasi: Integrating with external tools.
{
"version": "2.0.0",
"tasks": [
{
"label": "EDA: Riviera Compile counter_demo",
"type": "sigasiRivieraCompile",
"target": "counter_demo",
"watch": false
}
]
}The file shown is our own minimal configuration example. The target value must exactly match an existing target. Here, the compiler is located through the search path. For a different installation, add installationPath with the actual absolute directory containing the executables. Do not copy illustrative paths without checking, and do not accidentally treat a personal machine configuration as a universally valid project setting.
Step 4: Run a controlled compilation
Start the task through the VS Code command palette using Tasks: Run Task. Read the terminal log from the beginning. Check the selected target, the files analysed and the first diagnostic. Subsequent errors are often consequences of a package that failed analysis earlier. Correct the first cause and repeat the same run before suppressing further warnings.
As a negative check, briefly introduce an unambiguous syntax error in a local working copy. The external run must fail or display the corresponding diagnostic. Remove the error and check again. This exercise demonstrates the route to the source and back. It demonstrates neither complete language support nor the counter’s functional correctness. Record the exercise with actual output in the team’s test record.
Step 5: Add extensions one at a time
Only after a stable minimal run should additional libraries and third-party IP be added. The documented libraryCfg and precompiledLibraries fields and additional compiler arguments must fit the real environment. Excluding a library as precompiled does not create it or automatically verify version compatibility. Document its origin, simulator version and actual prepared library revision.
Watch mode can then be added as a convenience. First examine what happens when several files are saved rapidly, when the target changes and when the compiler is unavailable. Retain a manually initiated compilation task as a clear diagnostic route. Automatic repetition should not cause important diagnostics to disappear among many successive outputs.
Simulation and troubleshooting
For subsequent simulation, use a separate documented entry point. The VUnit note demonstrates such a test runner. The simulator selected there must again match the available installation. Compilation and simulation should use the same sources, libraries and language settings; otherwise, the second stage may check a different project state.
- Executable not found: check the search path of the actual editor session and installationPath.
- Missing library: check the logical mapping, library configuration and prepared dependencies.
- IDE and compiler disagree: compare language version, target, defines and source set.
- Compilation succeeds but there is no test result: only compilation has run; start the separate simulation step.
- Licence error: establish the existing entitlement and local installation; do not silently activate an evaluation.
Actual test status and limitations
Checked against documentation; not executed in Sigasi or Riviera-PRO. No demonstrably authorised working vendor environment was available for this note. The JSON example was validated syntactically. The referenced original VHDL testbench was tested separately with GHDL 6.0.0 on Windows; that does not demonstrate the Sigasi–Riviera integration. Before use in your own project, record the described successful and failing runs in the actual intended environment.
The next useful step is to apply the workflow to a small section of your real project. Bring its source structure, library list and required tool versions to a development-workflow consultation. A concrete configuration can be assessed more directly than a general question about whether two product names work together.
Sources and date
Research checked on 19 October 2026. Sigasi: External compilers, Sigasi: Integrating with external tools, Sigasi editions and languages, Sigasi Visual HDL Download Archive.