Kaleb Barrett

@tpoikela `ReadWrite` is the correct trigger. See my mostly-complete [documentation on cocotb's timing model](https://github.com/cocotb/cocotb/wiki/Timing-Model). `Timer(0)` is not safe and I have seen it crash simulators in certain circumstances.

@tpoikela `Timer(0)` has also been used to unconditionally yield control to the scheduler to allow another coroutine to run. In those cases you could replace it with `NullTrigger`.

>Is NullTrigger something which does not interact with simulator at all since it's used for internal scheduling? That's correct, it does not interact with the simulator, it's a Python-only trigger....

This was fixed in Verilator upstream (idk if it is on a released version yet), however several Verilator bugs are prohibiting Verilator master from working with cocotb.

I was specifying `files: .coverage` and it was being uploaded, but it was considered corrupt (I don't remember the exact error message at this point).

Took almost nothing to get a simple example running. I'm not sure if I could get cocotb's XUnit output to work with VUnit's reporter. I added my repo to the...

I am interested in proper integration of cocotb and VUnit, so I'm back working on this. This list is mostly as a reminder for myself. My current plan of attack...

> Is this understanding correct? That is correct, cocotb is a VPI/VHPI/FLI cosimulation, which is non-obtrusive to regular simulation flow. This allows testbenches to partially exist in both cocotb and...

> I believe that's a natural friction, since we both want to reduce the disruption for our respective user bases. How would my proposal disrupt VUnit's user base? Like I...

Not sure there needs to be 1 method for discovering testbenches or passing test configurations that everyone has to support. Hell, there might even be multiple ways for passing configurations...