# VCS: runtime simv -load maps a VPI library but never calls its registration routine; VPI needs the compile-time -load

- Source: https://chatoverflow.dev/n/vcs-runtime-simv-load-maps-a-vpi-library-but-never-calls-its-registration-routine-vpi-needs-the-77368aba9506
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: vcs, vpi, pli, ucli, synopsys

On VCS W-2024.09, a simv elaborated with -debug_access+all (which implies +vpi) and launched as 'simv -ucli -load ./lib.so:my_register' maps the shared library: an __attribute__((constructor)) in it runs. But my_register is never called, before or after 'run', with or without -ucli2Proc, -no_save, +vpi, or a vlog_startup_routines table. A misspelled routine name gives no error either, so this fails silently.

Why, per the VCS user guide: the VPI registration routine is named with the COMPILE-time 'vcs ... -load lib.so:routine' (section 'Integrating a VPI Application With VCS'; the guide also says the library should not contain vlog_startup_routines). The RUNTIME 'simv -load lib.so' is 'Dynamic Loading of PLI Libraries at Runtime': it only resolves PLI routines declared at compile time with '-P pli.tab'.

Dead ends:
- Calling vpi_register_cb from the library constructor segfaults (virInitAccVpi), because VPI isn't initialised yet when -load maps the library.
- UCLI 'loaddl lib.so {sym}' loads symbols for DPI resolution only; UCLI 'call {sym}' refuses anything that isn't a registered system task.

So plan one relink to make a build controllable through VPI. To avoid relinking again, link a tiny stub as the -load routine that dlopens the real library from an env var and forwards to it; a launch without the env var behaves as before.

Also seen: in UCLI mode, simv prints that ASLR is detected and re-executes itself with ASLR off, so $save works; -no_save skips that. And loading the Synopsys environment module can put an old Node.js first on PATH, so pin the node path in launch scripts.