07:38 <tnt> _florent_: https://i.imgur.com/EBCBAYc.png

07:38 <tnt> This is with the other signals added (just got back to it today).

09:10 <tnt> What does CC/RQ/CQ/RC stand for ? I'm guessing Command/Request Queue/Completion ?

09:11 <tnt> So commands are received from the host to the device in the command queue and we send a command completion when done. And requests are initiated/sent from the device (fpga) to the host and we get a completion when it's executed ?

09:45 <tnt> So this is probably a more interesting capture : https://i.imgur.com/TafevxF.png

18:38 <tnt> _florent_: https://i.imgur.com/OL2Le7z.png

18:38 <tnt> I'm trying to understand what's going on into that RQ FIFO. AFAIU those should be TLPs right ?

19:15 <tnt> _florent_: This looks very wrong https://i.imgur.com/yJYUaiG.png

19:16 <tnt> (1) the byte enable 0xfffffffe is very suspicious

19:19 <tnt> (2) no first/last anywhere ?

20:11 <_florent_> tnt: The PCIe PHY on Ultrascale has 2 channels yes: Completer (cq/cc with Host initiating transfers) and Requester (rq/rc with FPGA initiating transfer), with the DMA, rq/rc are indeed the AXI streams to look at.

20:12 <_florent_> tnt: The AXI streams of the PHY are not standardized TLPs and some logic has been added in the pcie_support to expose standardized TLPs streams.

20:12 <tnt> The completion I get seems to be garbage afaict, I think something's wrong there, but I'm struggling to find the actual doc of the xilinx completion format ...

20:13 <_florent_> tnt: if RC seems suspicious, the issue is probably RC adaptation logic

20:13 <tnt> I though https://docs.xilinx.com/r/en-US/pg213-pcie4-ultrascale-plus/Completer-Request-Interface?tocId=ChYDdmUz7SwQBWVobe6XEA was it but ... doesn't seem to match.

20:13 <tpb> Title: Documentation Portal (at docs.xilinx.com)

20:13 <_florent_> tnt: if could be useful to do a capture with the output stream of the PHY and the adapted one

20:14 <tnt> Oh wait ... I was looking at CC doc instead of RC ...doh.

20:14 <tnt> How do you use litescope to capture signals inside a verilog block though ?

20:14 <_florent_> the adaptation is here:

20:14 <_florent_> https://github.com/enjoy-digital/litepcie/blob/master/litepcie/phy/xilinx_usp_gen3_x8/pcie_usp_support.v#L554-L631

20:14 <tnt> Yeah, I'm reading it now.

20:15 <tnt> "When the interface width is 256 bits and the straddle option is enabled, the core can straddle two Completion TLPs in the same beat."

20:15 <_florent_> To use LiteScope, you'll indeed have to expose this stream

20:15 <_florent_> https://github.com/enjoy-digital/litepcie/blob/master/litepcie/phy/xilinx_usp_gen3_x8/pcie_usp_support.v#L910-L915

20:18 <_florent_> tnt: this seems be a good suspect yes, is it enabled with your config?

20:18 <tnt> yup ... <spirit:configurableElementValue spirit:referenceId="MODELPARAM_VALUE.AXISTEN_IF_RC_STRADDLE">TRUE</spirit:configurableElementValue>

20:20 <tnt> Weird because I did start from the .xci in the repo, so somehow when loading it, it go changed back to true.

20:21 <_florent_> Vivado like to update things in it during the build...

20:24 <_florent_> this could also be related to an auto-update of the .xci with a newer version of Vivado.

20:26 <tnt> rebuilding now with that param changed.

20:27 <_florent_> tnt: OK, I hope it's the issue. (This would at least explain why you were seeing the issue while I haven't been able to reproduce it).

20:28 <tnt> yeah. I'm still a bit surprised though because even with straddle, but very first completion should be OK but it still looks messed up (like that weird byte enable ...)

20:49 <tnt> It'd be nice if litescope could use URAMs :)

20:50 <tnt> (not sure why it's not inferring any tbh, i didn't check)

20:53 <_florent_> it would be interesting to have a look yes.

20:54 <_florent_> Now that LiteDRAM also has a FIFO frontend, it would also be interesting to have the LiteScope buffer in DRAM :) (When capture bandwidth is limited and design already has a well validated DRAM support)

20:58 <_florent_> tnt: also if Vivado changed some of the settings in your .xci, can you also verify this one?:

20:58 <_florent_> spirit:referenceId="MODELPARAM_VALUE.AXISTEN_IF_ENABLE_CLIENT_TAG">TRUE

20:58 <_florent_> This has to be set to True to allow LitePCIe to handle the tags

21:01 <tnt> yup, that's enabled.

21:14 <tnt> _florent_: yup, that fixed it :)

21:20 <tnt> (or at least it doesn't hang. The litescope view is still ... weird)

21:28 <_florent_> tnt: good. Happy to have a closer look at the LiteScope captures tomorrow