Marlon James

@ktbarrett Does that work with VHPI? It separates root instantiation and packages into `vhpi_handle(vhpiRootInst, NULL)` and `vhpi_iterator(vhpiPackInsts, NULL)`

Reopening until we have VHDL package support.

We always register callbacks as enabled, so we could assume the state is `vhpiEnable` without checking it.

You can try setting `COCOTB_LOG_LEVEL` environment variable to `DEBUG` or `TRACE` to get more info, but they will be increasingly verbose, so if a lot happens before that 50ns message...

This looks like a case of callback re-entrancy as detailed in #2178. The TRACE entry "Passing control to GPI user" happens when the simulator calls a registered GPI callback. That...

If you have `nox` installed, the `dev` session installs and editable build with debug info and coverage. Run `nox -s dev -- bash` from the cocotb repo. That will setup...

Ok, so both times it is a `vhpiCbValueChange` callback (`cb_data->reason = 1001`). Both times are also for the same `vhpiHandleT` (`cb_data->obj = 0x500080`). The part that is important is what...

Yeah, it's what I expected. These are the key parts: ``` #0 handle_vhpi_callback (cb_data=0x28d6ae0) at cocotb/share/lib/vhpi/VhpiImpl.cpp:988 [ ... simulator ... ] #6 0x00000000008992ca in vhpi_put_value () #7 0x00007f1e2d388710 in VhpiLogicSignalObjHdl::set_signal_value...

You are right, I just noticed **VPI** then **VHPI**. Mixed language simulation might be part of the problem here. Either way, we would expect the new callback to occur after...

If you step through the first breakpoint that "works", does it actually call up to Python, or is perhaps the trigger not primed?