Issues with edge detection of bits belonging to a vector driven by cocotb

I commonly come across a new to have multiple coroutines each of which monitor’s a rising edge of a specific bit of a vector. Somewhat more rarely is that same vector is driven by cocotb. If the vector is driven one bit (bit slicing) at a time by cocotb, and two bits are driven high in the same time step, only one of the bits edges will detect. For example:

   dut.vector[0] <= 1
   dut.vector[1] <= 1
   dut.vector[2] <= 1
   dut.vector[3] <= 1

Assuming there is a coroutine per bit of vector, each awaiting on a rising edge trigger, only one of them will fire. However if instead you have:

   dut.vector <= 15

All 4 will triggers fire.

I’ve attached a MWE that fails a test in Riviera. I spoke to @ktbarrett about this and he tried this example on Questa and it passes. Since that simulator uses the FLI interface, it’s not clear if this is a Riviera pro issue or an issue with Cocotb’s VHPI interface logic. @cmarqu I’m told you might be able to run this test in cadence and rule out if this is a Riviera Pro issue. If it’s an issue with Aldec I can try to work with them to resolve it.

Context: Using cocotb 1.4 and Riviera Pro 64 bit on CentOs 7 & 8.

test.zip

[marlonjames]

From my reading of the LRM, updating a bit of a std_logic_vector is an error:

23.28 vhpi_put_value It is an error if the vhpi_put_value function is called with an update mode of vhpiForcePropagate or vhpiDepositPropagate to update a member of a resolved composite signal.

cocotb uses vhpiDepositPropagate, and std_logic_vector is a resolved composite type.

It might work with std_ulogic_vector.

[ktbarrett]

I guess that means we need better support at the Python object level.