Todd Strader

> #75 (once merged) makes CI work again, but it doesn't pass because of the issues fixed by this PR. > > @toddstrader Would you mind updating this PR (resolve...

So this breaks `test_timing_triggers.test_writes_have_taken_effect_after_readwrite`. I believe the timeline is: - `write_manually` is started soon - `in_data` is assigned via `.value` (this is deferred for `_do_writes` to handle later) - `write_manually`...

Thanks @marlonjames . Also, it's not just an icarus problem. Xcelium also gives me `FATAL: We are calling up again`.

I believe the latest commit addresses the reentrancy problem (at least it fixes my test for icarus and xcelium). I can split that off into another PR if desired or...

Scratch that ^ it's `issue_768_*` I need to dig into more (for icarus). `test_writes_have_taken_effect_after_readwrite` is still failing, but is understood and explained above. Still curious if people think that the...

> It probably makes sense to move the re-entrancy handling to a different PR. Sounds good. I'd like to keep them combined for now because I need the `setimmediatevalue` change...

I lied. I can make the `768` issue happen with either `cbStartOfSimulation` or `cbAfterDelay` with a delay of zero (I believe this is what cocotb is doing for Icarus). I'll...

Alright. So there's a bunch of things going on here. ### Issue 768 I would posit that https://github.com/steveicarus/iverilog/issues/1111 was the real problem with #768 all along. Let's see what the...

> how quickly they can get a fix out Answer: zero time. It was already fixed. If I re-run the `768` tests against `HEAD` of Icarus with this change, they...

> we shouldn't be using vpiInertialDelay at all I ran `nox` on this branch with both Icarus (`HEAD`) and Xcelium without `vpiInertialDelay` and everything passed. So I'm increasingly pro this...