Cocotb: VHPI: Re-evaluate callbacks for ReadWrite/ReadOnly triggers

[marlonjames]

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

[eric-wieser]

Looking at the VPI callbacks, the ones added in the verilog 2005 standard might make sense to use in place of the ones we currently use too...

[stuarthodgson]

The potential issue here is then ensuring all the simulators support the changes. The ones used now were chosen because of this.

[yaff]

Just for reference: I believe this is causing an issue with Aldec 2016.06-x64 where signals assigned in Python via the <= operator after yielding to a RisingEdge are not appropriately delayed until the next ReadWrite cycle. They appear to change 1 delta cycle after the clock edge, and thus assert too early to the HDL under test. Temporarily adjusting the vhpi calls in the manner that @garmin-mjames suggested did resolve the issue.

I tested the same scenario under Modelsim 10.6 i386 and it does not appear to have the same problem. But I'm not sure if cocotb uses vhpi calls with Modelsim.

[marlonjames]

Callback support:

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

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]

@garmin-mjames Do you have a branch with the changes that we could test with?

[marlonjames]

@ktbarrett see #1498

[marlonjames]

Do we have contributors who can test this callback change using #1498?

[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.