VHPI: Re-evaluate callbacks for ReadWrite/ReadOnly triggers

Currently, the callbacks being used for ReadWrite and ReadOnly triggers through VHPI (VHDL) are as follows:

ReadWrite : vhpiCbRepEndOfProcesses ReadOnly : vhpiCbRepLastKnownDeltaCycle

I think that there are better callbacks that match the behavior of the VPI interface.

The vhpiCbRepLastKnownDeltaCycle callback more closely matches the VPI ReadWrite behavior, as it occurs after execution of all simulator events for the simulation time. The vhpiCbRepEndOfProcesses is called at the end of every delta cycle during the current time. It also still allows for setting signal/driver values and scheduling Timer events. If any signals are updated, an additional delta cycle will occur.

The vhpiCbRepEndOfTimeStep callback more closely matches the VPI ReadOnly callback in that it occurs at the end of the last delta cycle of the current time but does not allow changing signals/drivers or scheduling Timer events.

The current callback for ReadWrite can cause subtle problems in cocotb tests. If the scheduler yields on a ReadWrite trigger before all delta cycles have finished, it’s possible to set a signal value “early” before events have propagated through the simulation model.

References: IEEE Std 1076-2008 VHDL Language Ref Manual Section 14.7.5 and 21.3.6.1 IEEE Std 1364-2001 Verilog Hardware Description Language Section 27.33.2

[marlonjames]

Callback support:

Simulator	vhpiCbRepLastKnownDeltaCycle support	vhpiCbRepEndOfTimeStep support
Aldec Active-HDL 10.1+	✔️	✔️
Aldec Riviera 2016.06+	✔️	✔️
GHDL	Uses VPI	Uses VPI
Cadence Incisive	✔️	✔️
Modelsim/Questa	Uses FLI	Uses FLI
NVC	No longer supported	No longer supported
Cadence Xcelium	✔️	✔️

Edit: For what it’s worth, I discovered that internally GHDL bridges from the VPI interface back to the VHPI model and uses my suggested callbacks already.

[ktbarrett]

Testing with IUS and Xcelium was done by @themperek and there is no regression. That should complete your table, meaning #1498 can come in.