Closed smunaut closed 1 year ago
Thanks a lot @smunaut! You indeed probably found the root cause, I'll have a closer look at it and apply the changes.
The changes have been applied to LitePCIe:
And LiteX:
BTW, I've started cleaning up the Ultrascale(+) support in https://github.com/enjoy-digital/litepcie/commits/xilinx_us_cleanup but still have a bit of work to do. I was also planning to revisit this part of the code while doing so.
Thanks a lot @smunaut!
So I was getting in a situation where MSI would just stop being delivered to the host. Looking around I found a comment in litex soc integration code adding some
WaitTimer
thing with a comment :Well this didn't prevent them for me.
I dug into the problem and found the root cause.
The problem is in the interface to the
pcie_usp_support
and what it expects.So the problem is that the
pcie_usp_support
internally will detect RISING EDGES oni_cfg_interrupt_msi_int_valid
and submit interrupt request to the Xilinx core when they occur. Which is a big problem because if the cross clocking FIFO ever has more than 1 entry in it, after a transfer occurs,valid
will STAY high ... and the support code will never submit another request because it saw no rising edge which means ready will always be low ... and the CDC will fill up ... and IRQ are stalled.As a side note if
o_cfg_interrupt_msi_fail
ever occur, it will also probably stall too.So what I ended up doing is this :
This basically forces the re-detection of a rising edge if valid is still high after a 'sent' or 'fail' response.
That seems to have fixed the issue for me.