_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
somlo_ has joined #litex
somlo has quit [Read error: Connection reset by peer]
rektide has quit [Ping timeout: 256 seconds]
rektide has joined #litex
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #litex
indy has quit [Ping timeout: 256 seconds]
indy has joined #litex
sebo has joined #litex
sebo has quit [Ping timeout: 248 seconds]
SpaceCoaster_ has joined #litex
SpaceCoaster has quit [Ping timeout: 256 seconds]
Xesxen has quit [Ping timeout: 256 seconds]
SpaceCoaster_ is now known as SpaceCoaster
Xesxen_ has joined #litex
FabM has joined #litex
FabM has joined #litex
<tnt> This is with the other signals added (just got back to it today).
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor_ has joined #litex
<tnt> What does CC/RQ/CQ/RC stand for ? I'm guessing Command/Request Queue/Completion ?
<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 ?
<tnt> So this is probably a more interesting capture : https://i.imgur.com/TafevxF.png
FabM has quit [Ping timeout: 260 seconds]
zjason`` is now known as zjason
sebo has joined #litex
sebo has quit [Remote host closed the connection]
sebo has joined #litex
sebo has quit [Ping timeout: 260 seconds]
sebo has joined #litex
sebo has quit [Ping timeout: 260 seconds]
sebo has joined #litex
sebo has quit [Ping timeout: 248 seconds]
sebo has joined #litex
<tnt> I'm trying to understand what's going on into that RQ FIFO. AFAIU those should be TLPs right ?
sebo has quit [Ping timeout: 246 seconds]
sebo has joined #litex
<tnt> _florent_: This looks very wrong https://i.imgur.com/yJYUaiG.png
<tnt> (1) the byte enable 0xfffffffe is very suspicious
<tnt> (2) no first/last anywhere ?
sebo has quit [Ping timeout: 268 seconds]
sebo has joined #litex
<_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.
<_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.
<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 ...
<_florent_> tnt: if RC seems suspicious, the issue is probably RC adaptation logic
<tpb> Title: Documentation Portal (at docs.xilinx.com)
<_florent_> tnt: if could be useful to do a capture with the output stream of the PHY and the adapted one
<tnt> Oh wait ... I was looking at CC doc instead of RC ...doh.
<tnt> How do you use litescope to capture signals inside a verilog block though ?
<_florent_> the adaptation is here:
<tnt> Yeah, I'm reading it now.
<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."
<_florent_> To use LiteScope, you'll indeed have to expose this stream
sebo has quit [Ping timeout: 268 seconds]
<_florent_> tnt: this seems be a good suspect yes, is it enabled with your config?
<tnt> yup ... <spirit:configurableElementValue spirit:referenceId="MODELPARAM_VALUE.AXISTEN_IF_RC_STRADDLE">TRUE</spirit:configurableElementValue>
<tnt> Weird because I did start from the .xci in the repo, so somehow when loading it, it go changed back to true.
<_florent_> Vivado like to update things in it during the build...
<_florent_> this could also be related to an auto-update of the .xci with a newer version of Vivado.
<tnt> rebuilding now with that param changed.
<_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).
<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 ...)
<tnt> It'd be nice if litescope could use URAMs :)
<tnt> (not sure why it's not inferring any tbh, i didn't check)
<_florent_> it would be interesting to have a look yes.
<_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)
<_florent_> tnt: also if Vivado changed some of the settings in your .xci, can you also verify this one?:
<_florent_> This has to be set to True to allow LitePCIe to handle the tags
<tnt> yup, that's enabled.
<tnt> _florent_: yup, that fixed it :)
<tnt> (or at least it doesn't hang. The litescope view is still ... weird)
<_florent_> tnt: good. Happy to have a closer look at the LiteScope captures tomorrow
nats` has quit [Quit: ZNC - http://znc.in]