07:54 <tnt> _florent_: A couple of random question when digging in litedram and litepcie :

07:56 <tnt> - Is there any way to have dram port priority ? Like I have one port that needs to be "real-time" (i.e. as soon as there is a re-arbitration, it should win), and another that really doesn't matter, what's connected to it can go very fast if it needs to but there is no real time constraint so it should just use whatever bandwidth is left.

07:57 <tnt> - In litepcie DMA: When an endpoint accepts a request, does that mean the completion came back ? Or just that it was sent but we have no idea if it was executed yet. (Wondering if the polling of DMA status could "see" a descritor as done while in fact the request might have been sent but not yet executed).

08:56 <_florent_> tnt: Hi, we don't have priority on DRAM ports yet, but I also start having needs for this on some systems, so this would be useful to implement it. We could have low and high priority ports. This should consist of revisiting the arbitration in the crossbar and should not be complicated to add.

08:58 <_florent_> tnt: regarding LitePCIe, the DMA status and IRQ are updated/generated when the request has been accepted by the LitePCIe Endpoint

09:00 <_florent_> tnt: So a Write TLP still has to be transmitted to the Host and executed, a Read request TLP still has to be transmitted to the Host, executed and completion received by the FPGA.

09:02 <tnt> Mmm ok, so I have a race condition there :/

10:25 <_florent_> The current DMA is really targeting specific streaming applications and since still used on design I maintain I don't really want to modify the behavior. It would be good to provide a simpler alternative in the future on top of the AXI frontend to do Stream (FPGA) <-> MMAP (Host) and also MMAP (FPGA) <-> MMAP (Host)

10:40 <tnt> Is there a description somewhere of the endpoint port interface (or rather the cross bar ports). I see the request_layout / completion_layout but I'm a bit unclear how that works.

10:40 <tnt> (because typically I'd expect a header with address/ength/... and then a bunch of data, but here it's all in one layout)

10:47 <tnt> Also, the AXI front end also doesn't look like it's waiting for the write completion to send the axi completion. Only waits for all the data to be read in.

11:49 <_florent_> tnt: I just added some comments with https://github.com/enjoy-digital/litepcie/commit/2f8c1a29c5c8bdc352fb60e2b72981c91543ae06.

11:50 <_florent_> tnt: The parameters are constant during the packet duration (that needs to be delimited by setting first/last)

11:50 <_florent_> tnt: These parameters are used to create the header in the case of a request/or extracted from the completion

11:51 <_florent_> tnt: By the Packetizer/Depacketizer modules

11:54 <tnt> Ok, I see. Thanks for the info. I'm assuming completion don't come in order (since pcie itself can re-order), but I'm supposed to use user_id to keep track ?

11:58 <_florent_> The completion is already reordered in the lower layers

11:58 <tnt> Oh, that it really nice. Makes things way easier for me then :)

11:58 <_florent_> https://github.com/enjoy-digital/litepcie/blob/master/litepcie/tlp/controller.py#L88-L107

12:00 <_florent_> Regarding the user_id, it's here to be able to delimit the DMA Reader packet (and create one packet per DMA descriptor)

12:01 <_florent_> This is optional is you don't need this

12:02 <tnt> I don't think it would be all too hard to modify the existing DMA just a bit to have another operation mode that's what I want while still keeping the existing modes/behaviors.

12:03 <_florent_> I'm ok adding modes if by default we keep the current behavior

12:04 <tnt> yeah of course, I completely understand that changing the default behavior would be a maintenance nightmare.

12:09 <_florent_> If you think the changes would be limited, free free to explore this and we'll probably manage to integrate this mode.

12:10 <_florent_> Regarding writes, since they are posted you'll probably not be able to improve things a lot.

12:11 <_florent_> Regarding reads, you could use the user_id to only update the DMA status when the Read has effectively been done.

12:19 <tnt> Oh you don't get completion tlp on writes ?

12:19 <tnt> I need to read up on pcie ordering

13:17 <davebee> I'm trying to add my own SPI Flash boot to the BIOS. How can I add .c and .h files to the build, without having to modify the Litex source? I have working code, but I want to be able to load my own library into the bios code.

13:19 <_florent_> tnt: the writes are posted in PCIe yes.

13:21 <davebee> Being able to set an include path would be a good start.

13:22 <_florent_> davebee: This is not yet supported, but you could probably reused what is done for the BIOS libraries

13:22 <_florent_> https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/builder.py#L121-L127

13:23 <_florent_> sorry I have to go

13:24 <davebee> thanks. It would be seful to be able to add files and entry points to them n the bios.

15:06 <tnt> _florent_: So AFAIU the completion issued from reading the status register wouldn't be able to "pass over" the posted writes, so as long as the status regs are only updated once the write has actually been posted, there is no race.

15:30 <davebee> _florent_: the add_software_package() add_software_library() does build the library. That is very useful. I want to be able to share the library between my boot loader and app code. This is very helpful.