Change VPI callback for ReadWrite

Discussion of proposed solution following #1611. #1060 likely related.

Background

After waiting on an edge trigger on a signal, we exist in a state where computations based on the change in value on the signal have not been resolved. Reading values at this point yields previous values for the related signals. If want to read the resolved values and respond in the same time cycle (modelling combinational logic), we need to move to a state where the HDL assignments are resolved, but we can still write values. This is the point of ReadWrite.

We currently use the cbReadWriteSynch trigger to move us into that context; however, as https://github.com/cocotb/cocotb/issues/1611#issuecomment-613076767 points out, there is some contention on what that trigger actually means. @themperek has done investigative testing showing that Questa and VCS’s implementation of cbReadWriteSynch do not put us after the values resolve. So the ReadWrite trigger behaves differently under different simulators. There is no proper way to model combinational logic in cocotb in those simulators (you could still use NextTimeStep or Timer(1), but the timing will be off).

Solution

If we move the implementation of ReadWrite to use the cbAtEndOfSimTime trigger, VCS will function as intended. However, Questa’s VPI implementation does not implement this trigger. So with Questa we can choose between an implementation of cbReadWriteSynch that doesn’t work how we want it to, or something that doesn’t work at all. We should leave Questa alone for right now, the regressions pass and existing code (likely) works and will continue to work.

Kudos to @themperek for doing all the investigative legwork on this.

[themperek]

Maybe on simple D flip-flop ?

import random
import cocotb
from cocotb.triggers import RisingEdge, ReadWrite, Timer

async def custom_clock(dut):
    while True:
        dut.clk <= 0
        await Timer(5, units="us")
        dut.clk <= 1
        await Timer(5, units="us")

@cocotb.test()
async def test_dff_simple(dut):

    cocotb.fork(custom_clock(dut))

    for i in range(10):
        val = random.randint(0, 1)
        dut.d <= val
        await RisingEdge(dut.clk)
        await ReadWrite() # fails to sample correct dut.q
        #await Timer(1) # works
        assert dut.q == val, "output q was incorrect on the {}th cycle".format(i)

[mballance]

@imphil, good question. I’ll be happy to take a look at it myself initially, though it won’t be until the weekend. Is there a testcase that I can use to observe the current behavior?