AxiMaster overloads cocotb scheduler when using large AXI-ID vectors about cocotbext-axi HOT 6 CLOSED

1. that's odd. I'm not sure why the scheduler would be doing anything for idle coroutines. I'll bring this up with the cocotb people. I can perhaps do some sort of lazy allocation of those resources - i.e. only spin up coroutines and allocate queues when IDs are active, and then perhaps delete them when the IDs become inactive. Lazy allocation could make sense, but if you do a sweep over the whole tag space, then you're right back where you started unless I also clean up inactive IDs, but then that's extra overhead if the problem is really in the cocotb scheduler.
2. how do you get that call graph? That would be super useful for tweaking the interface extensions.

from cocotbext-axi.

Oh, I know what I can do - make the mapping dynamic, with lazy allocation. That way, it will only spin up coroutines up to the number of unique active IDs at any one time, independent of the number of possible IDs. In that case, I won't clean up the queues and coroutines, just remove them from the mapping to be used for a different ID.

from cocotbext-axi.

Oh, is this only a problem during init? After init, the simulation is fast?

from cocotbext-axi.

Alright, try again with the git version and let me know if the performance is any different.

from cocotbext-axi.

The most visible speed impact is at initialization and again at teardown, but I would also expect that having a large amount of dormant coroutines doesn't make the scheduler any faster ;).

The fix you provided works out great, thank you for the fast action!

The call graph is created with https://github.com/jrfonseca/gprof2dot

from cocotbext-axi.

I just released v0.1.12 with this change

from cocotbext-axi.