Useful Feature(?): Separating Python side from simulation side about cocotb HOT 3 OPEN

The benchmark we have so far is https://github.com/search?q=repo%3Acocotb%2Fcocotb%20benchmark&type=code, with https://cocotb.github.io/cocotb-benchmark-results/dev/bench/ being the visualization for it.

For such a big change though, a more real-life testbench like the one for https://github.com/corundum/corundum/ might be better.

from cocotb.

It's definitely of interest. We (the maintainers, power users, previous personal employers, etc.) have been tossing the idea around for a couple years now, but no one has had time to work on it.

Primarily we are interested in it to be able to have VPI and DPI functionality usable from the same testing environment. We could also vastly simplify and improve the cocotb codebase by leveraging existing tools like pytest for regressions and asyncio or trio for concurrency.

The primary concern is performance. Doing an RPC 4 times for every clock cycle to implement a clock driver in Python would kill. But obviously, that could be alleviated by moving certain things to HDL.

Considering the massive changes this would involve, I don't see this is as a future for cocotb, but instead a successor/alternative that could leverage the existing cocotb codebase. It's been a dream of mine to make the GPI a first-class public API that other projects could leverage, but effort towards that goal is currently lower priority than the Python API.

from cocotb.

Nice to read that and thank you for the detailed answer :)

Regarding your performance concern:
Are there any examples/tests that could serve as a benchmark? We probably could hack something that could provide some insights into the overhead that we might have to expect — for possible clean implementation I would also see this kind of feature as an "option" to activate, i.e. not the default mode of operation.
I do agree that RPC via some network (esp. when thinking about REST APIs) could be really problematic when performed at each clock cycle (been there ;) ), but I guess a machine-local IPC mechanism would be still very much feasible (if it's about call latency we could resort to shmem and futexes, that should keep the call latency way below us range; i.e. I would expect that anything below 1MHz VPI/DPI call rate would be quite possible.

from cocotb.