[enhancement] Add mechanism to detect blocked or slow paths in network of procs #3314
Description
What's hard to do? (limit 100 words)
It is hard to understand where and why stalls happen in a network of procd that together form a processing pipeline. At the DSLX level, tests do not have a notion of time, so it is not possible to see how data moves between procs or when one of them becomes a bottleneck. It would be helpful to have a way to detect blocked or slow paths in the design early.
Current best alternative workaround (limit 100 words)
Right now, one can dump the design to SystemVerilog and check how it behaves during simulation. Another option is to create C++ tests at the Block IR level, which does include the concept of time and can show how data moves between procs.
Your view of the "best case XLS enhancement" (limit 100 words)
It would be useful to have a tool that can detect stalls and blocked channels early in the development process. The test could reuse the same input data as normal DSLX tests but run the simulation at the Block IR level. By observing ready-valid handshakes, the tool could report which procs are waiting on data and which one are blocking others (for example, when the receiver is ready but the sender has no valid data). In a simple form, the test could try to push new data into inputs every cycle and record where gaps/bubbles appear in the pipeline