| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** somlo_ <[email protected]> has joined #litex | 00:07 | |
| *** somlo <[email protected]> has quit IRC (Read error: Connection reset by peer) | 00:08 | |
| *** rektide <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 00:14 | |
| *** rektide <[email protected]> has joined #litex | 00:15 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 01:03 | |
| *** Degi <[email protected]> has joined #litex | 01:04 | |
| *** indy <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 02:09 | |
| *** indy <[email protected]> has joined #litex | 02:11 | |
| *** sebo <[email protected]> has joined #litex | 04:01 | |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 04:06 | |
| *** SpaceCoaster_ <SpaceCoaster_!~derek@user/spacecoaster> has joined #litex | 04:08 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has quit IRC (Ping timeout: 256 seconds) | 04:10 | |
| *** Xesxen <Xesxen!~cyber@hackalot/deelnemer/xesxen> has quit IRC (Ping timeout: 256 seconds) | 04:10 | |
| *** SpaceCoaster_ is now known as SpaceCoaster | 04:10 | |
| *** Xesxen_ <Xesxen_!~cyber@hackalot/deelnemer/xesxen> has joined #litex | 04:10 | |
| *** FabM <[email protected]> has joined #litex | 06:59 | |
| tnt | _florent_: https://i.imgur.com/EBCBAYc.png | 07:38 |
|---|---|---|
| tnt | This is with the other signals added (just got back to it today). | 07:38 |
| *** Emantor <[email protected]> has quit IRC (Quit: ZNC - http://znc.in) | 08:22 | |
| *** Emantor_ <[email protected]> has joined #litex | 08:23 | |
| tnt | What does CC/RQ/CQ/RC stand for ? I'm guessing Command/Request Queue/Completion ? | 09:10 |
| 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:11 |
| tnt | So this is probably a more interesting capture : https://i.imgur.com/TafevxF.png | 09:45 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 260 seconds) | 15:00 | |
| *** zjason`` is now known as zjason | 15:40 | |
| *** sebo <[email protected]> has joined #litex | 16:15 | |
| *** sebo <[email protected]> has quit IRC (Remote host closed the connection) | 16:20 | |
| *** sebo <[email protected]> has joined #litex | 16:20 | |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 16:30 | |
| *** sebo <[email protected]> has joined #litex | 16:56 | |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 17:30 | |
| *** sebo <[email protected]> has joined #litex | 17:56 | |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 18:04 | |
| *** sebo <[email protected]> has joined #litex | 18:31 | |
| 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 ? | 18:38 |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 18:39 | |
| *** sebo <[email protected]> has joined #litex | 19:07 | |
| tnt | _florent_: This looks very wrong https://i.imgur.com/yJYUaiG.png | 19:15 |
| tnt | (1) the byte enable 0xfffffffe is very suspicious | 19:16 |
| tnt | (2) no first/last anywhere ? | 19:19 |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 19:40 | |
| *** sebo <[email protected]> has joined #litex | 20:08 | |
| _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:11 |
| _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:12 |
| _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:13 |
| 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:14 |
| 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:15 |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 20:15 | |
| _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:18 |
| tnt | Weird because I did start from the .xci in the repo, so somehow when loading it, it go changed back to true. | 20:20 |
| _florent_ | Vivado like to update things in it during the build... | 20:21 |
| _florent_ | this could also be related to an auto-update of the .xci with a newer version of Vivado. | 20:24 |
| tnt | rebuilding now with that param changed. | 20:26 |
| _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:27 |
| 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:28 |
| tnt | It'd be nice if litescope could use URAMs :) | 20:49 |
| tnt | (not sure why it's not inferring any tbh, i didn't check) | 20:50 |
| _florent_ | it would be interesting to have a look yes. | 20:53 |
| _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:54 |
| _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 | 20:58 |
| tnt | yup, that's enabled. | 21:01 |
| tnt | _florent_: yup, that fixed it :) | 21:14 |
| tnt | (or at least it doesn't hang. The litescope view is still ... weird) | 21:20 |
| _florent_ | tnt: good. Happy to have a closer look at the LiteScope captures tomorrow | 21:28 |
| *** nats` <nats`!~nats@2001:41d0:8:c634::1> has quit IRC (Quit: ZNC - http://znc.in) | 22:22 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
