13:47 <tnt> Ok, so after nearly a full day of playing with constrainst and xdc and all that stuff, this is the culprit :

13:47 <tnt> https://github.com/enjoy-digital/litex/commit/3c34039b731b42e27e2ee6c8e399e5eb8f3a058f

13:48 <tnt> That causes the false path constraint in the XDC to be processed before the generated clock from the IP are created and so it doesn't find those clocks (not created yet).

13:49 <tnt> and AFAICT the purpose of that commit doesn't even work (at least not on current vivado). Trying to just use LOC constraints on the pins that don't match what was used in the .xci just results in DRC errors because some part of the IP end up locked to one place and some other to anothe rplace and it can't route things.

15:25 <tnt> Damnit ... I was preparing a PR to litex-board for the ADI board ... do one last test on master ... and now dma_test fails :/

15:25 <tnt> [ 319.751518] litepcie 0000:01:00.0: Reading too late, 92 buffers lost

15:25 <tnt> [ 319.751667] litepcie 0000:01:00.0: Writing too late, 57 buffers lost

15:25 <tnt> and litepci_util says 'Unable to find DMA RX_DELAY (min errors: 2048/2048), exiting'

15:39 <tnt> Mmmm that whole RX_DELAY thing is new, and if I try to use the "old" dma_test it works.

19:14 <tnt> I'm a bit at a loss how a DMA loopback test can "loose" packet ... this isn't a real-time process, if there is no buffer descriptors, just wait until there is one.

19:15 <tnt> I haven't dug into the code yet but that seems highly suspitious.

21:25 <tnt> So IIUC this is the so called "loop mode" where the descriptor are just looped indefinitely, completely free-running of any software control which is definitely not what I'd want.

21:25 <tnt> Unfortunately it looks like the kernel driver has no other mode, so I'll need to write my own from scratch unless someone has an example that doesn't use loop mode ?