Support Riviera-PRO by ru551n · Pull Request #21 · VUnit/vunit-python-bridge

ru551n · 2026-10-13T16:00:38Z

Adds Riviera-PRO support through the VUnit Python bridge, with the same API as on NVC, GHDL and Questa. It replaces the separate, limited VHPI application used before.

What was added

native/vhpi.c, a VHPI front end. Riviera-PRO has no VHPIDIRECT, so this registers one foreign subprogram per bridge entry point, like native/fli.c does for Questa. Strings are passed as character vectors, because Riviera-PRO cuts a vhpiStrVal at a line feed.
A VHPI variant of the bridge library. It is built against the simulator's vhpi_user.h and cached in ~/.vunit-python-bridge. On Windows it is built with Riviera-PRO's bundled MinGW and linked against aldecpli.
Generated attributes that name the library by absolute path: "VHPI <dir>/libvunit_python_bridge_vhpi vpy_begin".
The configuration path is passed in VUNIT_PYTHON_BRIDGE_CONFIG, set in the VUnit process, because VUnit's Riviera-PRO interface has no run-environment hook.

Tested

	Linux	Windows
Riviera-PRO 2026.04	109/109 tests, 18/18 example	109/109 tests, 18/18 example

🤖 Generated with Claude Code

ru551n · 2026-10-14T21:36:53Z

 - Python 3.15 is supported, with a prebuilt bridge DLL for Windows.
 - The bridge library is no longer built in or copied to the VUnit output path, which may not allow executing files, but to `~/.vunit-python-bridge` in the home directory of the user, on every platform. This includes the prebuilt Windows DLLs. `VUNIT_PYTHON_BRIDGE_LIBRARY_DIR` selects another directory on every platform. When the directory cannot be written, the setup fails and asks for the variable to be set.
 - A library directory the simulator cannot load the bridge library from is reported as such when the package is set up: on Linux and macOS one on a file system mounted `noexec`, e.g. a tmpfs in a container, and on Windows one where an execution policy (AppLocker, Windows Defender Application Control) blocks the library. The simulator only reports that it failed to load it. Any other reason the library does not load is reported by the setup with the reason the system gives, rather than by NVC or GHDL as "cannot load VHPIDIRECT shared library" with no reason.
+- The Riviera-PRO/Active-HDL VHPI application builds on Linux. It was linked against the Windows import libraries (`-lpython311`, `-l_tkinter`) on every platform, so `ld` failed, and it is now `libraries/python.so` there. On Windows, `_tkinter` is only linked when the Python has it.


Shorten this to what feature was actually added.

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in ddafeb8: the release note is now "Riviera-PRO supports the whole API, through the VUnit Python bridge."

ru551n · 2026-10-14T21:38:42Z

+    # The embedded interpreter starts as this one, to use the same virtual environment. A header,
+    # since ccomp passes its arguments on through a shell, which would strip quotes from a -D.
+    (target.parent / "vunit_python_executable.h").write_text(
+        f"#define VUNIT_PYTHON_EXECUTABLE {json.dumps(sys.executable)}\n", encoding="utf-8"
+    )


Why is this needed for riviera pro?

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in ddafeb8 by removal. The fingerprint only decided when the old VHPI application had to be rebuilt in the output path. Riviera-PRO now uses the bridge library, cached like for the other simulators, so foreign_application.py is gone.

ru551n · 2026-10-14T21:42:07Z

    def post_run(results):
        verify(results, expected_failures)
-        run_file_base_tests(args)
+        if simulator_name in BRIDGE_SIMULATORS:


Why do we need this when we have all simulators working soon?

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in ddafeb8: with Riviera-PRO on the bridge, every simulator runs tb_python_pkg_bridge and the file_base tests, so the gate and the expected failures for VHPI are removed from tests/run.py.

Riviera-PRO has no direct binding (VHPIDIRECT), and was served by a separate VHPI application with a subset of the API. It now calls the bridge like the other simulators, through a VHPI front end, native/vhpi.c, that registers a foreign subprogram per entry point of bridge.h. The front end is compiled into a variant of the library, like the FLI one for Questa, against the vhpi_user.h of the simulator, and the generated attributes name the library by absolute path without its suffix. Strings cross as vectors of character positions, since Riviera-PRO ends a string value at a line feed. The VUnit interface of Riviera-PRO has no run environment hook, so the setup sets VUNIT_PYTHON_BRIDGE_CONFIG in the environment of the VUnit process, which vsim inherits. The VHPI application (python_pkg_vhpi.vhd, native/vhpi/, foreign_application.py) and the expected failures of the tests on VHPI are removed. Two test names lose their brackets, which VUnit's Tcl scripts for Riviera-PRO evaluate as commands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ru551n · 2026-10-14T22:00:22Z

@@ -1,5 +1,6 @@
 ## Changes

+- Riviera-PRO supports the whole API, through the VUnit Python bridge.


Just claim riviera pro as a supported simulator.

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in 32bcb3a: the release note is now "Riviera-PRO is a supported simulator."

ru551n · 2026-10-14T22:02:55Z

    if simulator_name is not None and simulator_name not in BRIDGE_SIMULATORS:
        raise PythonBridgeError(
-            f"The vunit-python-bridge package requires NVC, GHDL or Questa/ModelSim, "
+            f"The vunit-python-bridge package requires NVC, GHDL, Questa/ModelSim, Riviera-PRO or Active-HDL, "


Remove Active HDL as it is untested.

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in 32bcb3a: Active-HDL is removed from the code (the simulator table, the VHPI simulators, the hooks), the tests and the docs, so selecting it now fails at setup like any other unsupported simulator.

ru551n · 2026-10-14T22:04:22Z



-def prepare_library(root: Path, simulator_prefix: Optional[Path] = None) -> Path:
+def prepare_library(root: Path, simulator_prefix: Optional[Path] = None, front_end: str = "fli") -> Path:


Why do we have a default here, it should be explicit.

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in 32bcb3a: prepare_library takes simulator_prefix and front_end without defaults, and every caller passes them, None, None for the VHPIDIRECT variant. Same for _prepare_posix_library and bridge_sources.

ru551n · 2026-10-14T22:06:16Z



-def _build_windows_library(root: Path, simulator_prefix: Optional[Path] = None) -> Path:
+def _build_windows_library(root: Path, simulator_prefix: Optional[Path] = None, front_end: str = "fli") -> Path:


again, why do we need a default here

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in 32bcb3a: _build_windows_library takes simulator_prefix and front_end without defaults too, and uses front_end directly instead of deriving a variant from the prefix.

ru551n · 2026-10-14T22:06:52Z

+    built only when there is no prebuilt DLL.

-    Untested: this environment has no Windows installation.
+    The Questa variant is untested.


Remove this from the code

Claude (AI assistant) here, on behalf of @ru551n:

Fixed in 32bcb3a: removed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ru551n force-pushed the fix/riviera-linux branch from ae85275 to f6c7ad4 Compare October 13, 2026 16:04

ru551n changed the title ~~Build the Riviera-PRO/Active-HDL VHPI application on Linux~~ Support Riviera-PRO/Active-HDL on Linux Oct 13, 2026

ru551n changed the title ~~Support Riviera-PRO/Active-HDL on Linux~~ Support Riviera-PRO/Active-HDL on Linux and Windows Oct 13, 2026

ru551n force-pushed the fix/riviera-linux branch from f6c7ad4 to 6ac9cc2 Compare October 13, 2026 16:23

ru551n changed the title ~~Support Riviera-PRO/Active-HDL on Linux and Windows~~ Support Riviera-PRO/Active-HDL Oct 13, 2026

ru551n force-pushed the fix/riviera-linux branch 3 times, most recently from 78760a7 to 673c58a Compare October 13, 2026 16:28

ru551n mentioned this pull request Oct 13, 2026

Load the bridge library from outside the VUnit output path #13

Merged

ru551n force-pushed the fix/riviera-linux branch from 673c58a to f2f6bbf Compare October 13, 2026 18:00

This was referenced Oct 14, 2026

Build the documentation on Read the Docs #25

Merged

Restyle the documentation with a VHDL API reference and release docs #27

Merged

Name the release notes of the next release unreleased.md #28

Merged

ru551n force-pushed the fix/riviera-linux branch 2 times, most recently from 7ec9d3d to ad2504a Compare October 14, 2026 21:10

ru551n commented Oct 14, 2026

View reviewed changes

ru551n changed the title ~~Support Riviera-PRO/Active-HDL~~ Support Riviera-PRO/Active-HDL with the whole API Oct 14, 2026

ru551n changed the title ~~Support Riviera-PRO/Active-HDL with the whole API~~ Support Riviera-PRO Oct 14, 2026

ru551n force-pushed the fix/riviera-linux branch 3 times, most recently from fa05b6f to 139a950 Compare October 14, 2026 21:54

ru551n force-pushed the fix/riviera-linux branch from 139a950 to ddafeb8 Compare October 14, 2026 21:55

ru551n commented Oct 14, 2026

View reviewed changes

Address review: Riviera-PRO only, explicit front ends

32bcb3a

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

		@@ -1,5 +1,6 @@
		## Changes

		- Riviera-PRO supports the whole API, through the VUnit Python bridge.



		def prepare_library(root: Path, simulator_prefix: Optional[Path] = None) -> Path:
		def prepare_library(root: Path, simulator_prefix: Optional[Path] = None, front_end: str = "fli") -> Path:



		def _build_windows_library(root: Path, simulator_prefix: Optional[Path] = None) -> Path:
		def _build_windows_library(root: Path, simulator_prefix: Optional[Path] = None, front_end: str = "fli") -> Path:

Conversation

ru551n commented Oct 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What was added

Tested

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ru551n Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ru551n Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ru551n Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

ru551n commented Oct 13, 2026 •

edited

Loading

ru551n Oct 14, 2026 •

edited

Loading

ru551n Oct 14, 2026 •

edited

Loading

ru551n Oct 14, 2026 •

edited

Loading