SetAxi4Options simulator crash - Regression between 2026.01 and 2026.05

[dbee-lumacron]

Using Questa 2025.1, I use OSVVM_TOOL=siemens. (haven't tried with other tools)

With the exact same testbench that works perfectly fine in 2026.01, I am getting a simulator crash. It seems to be getting stuck on SetAxi4Options.

I tried adding a workaround like WaitForBarrier(OsvvmTestInit); before I set the options, and that seems to resolve itself. However, this was not previously needed.

My process is as follows:

  AXIL_checker_proc : process
    variable ProcID              : AlertLogIDType;
  begin
    ProcID := NewID("AXIL_checker_proc");

    Log(ProcID, "Starting process");
    -- this line (if uncommented - fixes it)
    -- WaitForBarrier(OsvvmTestInit);
    SetAxi4Options(register_axil_transrec, READ_DATA_VALID_TIME_OUT, 100);
    SetAxi4Options(register_axil_transrec, WRITE_RESPONSE_VALID_TIME_OUT, 100);
    SetAxi4Options(register_axil_transrec, WRITE_ADDRESS_READY_TIME_OUT, 100);
    SetAxi4Options(register_axil_transrec, WRITE_DATA_READY_TIME_OUT, 100);

    Log(ProcID, "Waiting for reset ");
    WaitForLevel(reset, '0'); -- Wait for Design Reset
    Log(ProcID, "Reset complete ");
    -- ...

error excerpt:

# %%      0 ns    Log    ALWAYS    in AXIL_checker_proc,   Starting process
# Attempting stack trace sig 11
# Signal caught: signo [11]
# vsim_stacktrace.vstf written
# Current time Tue Jun 16 18:12:37 2026
# Program = vsim
# Id = "2025.1"
# Version = "2025.01"
# Date = "Jan 17 2025"
# Platform = win64
# Signature = 6caf41abce44531be409b38b5e15fd71
# End of Stack Trace


# ** Fatal: (SIGSEGV) Bad handle or reference.
#    Time: 0 ps  Iteration: 0  Process: /tb_switch_map/ctrle/AXIL_checker_proc File: ../../../../../../OsvvmLibraries/Common/src/ModelParametersSingletonPkg.vhd
# Fatal error in Subprogram ModelParametersSingletonType.Set at ../../../../../../OsvvmLibraries/Common/src/ModelParametersSingletonPkg.vhd line 264
# 
# HDL call sequence:
# Stopped at ../../../../../../OsvvmLibraries/Common/src/ModelParametersSingletonPkg.vhd 264 Subprogram ModelParametersSingletonType.Set
# called from  ../../../../../../OsvvmLibraries/Common/src/ModelParametersSingletonPkg.vhd 488 Subprogram Set
# called from  tb.vhd 119 Process AXIL_checker_proc

Hopefully this is enough information to at least be somewhat helpful - apologies for not submitting a fully minimal repro testcase!

[JimLewis]

Hi Daniel,
That is very interesting and unfortunate. None of my test cases ran into, so I did not see it.

The easy update is to add the following (where your WaitForBarrier is):
WaitForClock(register_axil_transrec, 1) ;

The old SetAxi4Options did a transaction to hand off the information to the VC. The VC internally aligned to clock, so some time went by. Then it did the settings in the params data structure. By the time the transaction was decoded, the params data structure was updated and signal values had the ID (as this takes a couple of delta cycles at time 0).

The new SetAxi4Options realizes that some time ago access to the params data structure is inside the record, so it uses the id and sets the value directly - no transaction overhead. However at the start of time, you must wait several delta cycles before the params data structure is in the record. This is an experiment, but it greatly simplifies adding new parameters - so unfortunately edge cases like this will need to be updated.

Instead of the WaitForClock, you could also do:
wait for 1 ns ;

Enough wait for 0 ns would also get it done, but the number required may change over time.

Since the WaitForTransaction aligns to clock, this should just align to the first clock and return. With a 1 as the parameter, WaitForClock will find the 2nd rising edge of clock.
WaitForClock(register_axil_transrec, 0) ;

Best Regards,
Jim