2026.05 and SetAxi4Options/GetAxi4Options

Problem and Solution
In 2026.05, if a test case calls SetAxi4Options/GetAxi4Options at time 0 with a parameter other than an AXI4 bus value (such as BRESP) the test case will crash.

Problematic use case:

  ManagerProc : process
    variable IntOption  : integer ;
  begin
    -- this process starts at time 0, delta cycle 0 (aka Initialization phase)
    -- SetAxi4Options or GetAxi4Options access a parameter that is not a AXI4 bus value (such as BRESP)
    SetAxi4Options(ManagerRec, WRITE_RESPONSE_READY_DELAY_CYCLES, 2) ; 
    GetAxi4Options(ManagerRec, WRITE_RESPONSE_READY_DELAY_CYCLES, IntOption) ;
    AffirmIfEqual(TbManagerID, IntOption, 2, "WRITE_RESPONSE_READY_DELAY_CYCLES") ;

With 2026.05, the code now requires a wait (such as the WaitForClock below).

  ManagerProc : process
    variable IntOption  : integer ;
  begin
    -- Using the below WaitForClock causes the SetAxi4Options/GetAxi4Options to run at the same time previous versions ran the SetAxi4Options/GetAxi4Options.
    WaitForClock(ManagerRec, 0) ;
    SetAxi4Options(ManagerRec, WRITE_RESPONSE_READY_DELAY_CYCLES, 2) ; 
    GetAxi4Options(ManagerRec, WRITE_RESPONSE_READY_DELAY_CYCLES, IntOption) ;
    AffirmIfEqual(TbManagerID, IntOption, 2, "WRITE_RESPONSE_READY_DELAY_CYCLES") ;

What happened behind the scenes
The old SetAxi4Options/GetAxi4Options did a transaction to hand off the information to the VC. When transactions start, the WaitForTransaction aligns to clock (if not already aligned). This causes time to pass at the beginning of the test case and the data structures in the VC are now initialized.

The updated SetAxi4Options/GetAxi4Options directly references the params data structure via the record if the value is not an AXI bus value. Hence, if called at time 0, the data structure is referenced at time 0 before it is constructed.

Adding the WaitForClock(ManagerRec, 0) is the ideal solution. It initiates a transaction, WaitForTransaction aligns to clock (exactly as the old SetAxi4Options/GetAxi4Options did), and then calls WaitForClock(Clk, 0) – which does not wait since the value is 0. Not that ManagerRec in the WaitForClock call is the transaction record and not a clock signal.

Will the timing of SetAxi4Options/GetAxi4Options be reverted in the future
The current implementation simplifies adding parameters to a VC. The VC only needs to initialize the parameter at the start, otherwise, it is strictly the responsibility of SetAxi4Options/GetAxi4Options to write or read the value.

This is an experiment that I expect to be propagated to other VC in the future.

If your test case needs to set options before running a test, be sure to add the WaitForClock(TransactionRec, 0) to the start of the process.

Thanks to Daniel
Thanks to Daniel for reporting this on GitHub at: https://github.com/OSVVM/AXI4/issues/30.