PCIe hprxm_master doesn't handle unaligned reads correctly

Hi Wincent,
thanks for your continuous interest in the matter.

I'm doing all tests on Arria 10 development board TR10a-HL. The observed effect with my latest demo code is basically the same as documented in SignalTap screenshots appended in initial post. The basic difference is that I stripped of a clock-crossing bridge used in the original design and any application code not related to the issue.

A new signal tap recording is contained in .qar if you want to check.

I'm performing an unaligned 64-bit read which crosses a 256-bit word border of the hprxm master, e.g. reading from address 0x1c. Respectively a burst read is with burst count=2 is generated, reading first 256 bit from 0x00 and second 256 bit from 0x20. hprxm master logic is expected to assemble read data to a single completion TLP with data.

I tested two cases:
- hprxm reads from a 32 bit MM slave, respectively a 256-bit read is performed in 8 consecutive read cycles, unaligned read takes 16 cycles + slave latency.
- hprxm reads from 256 bit MM slave, unaligned read takes only 2 cycles + latency.

I can see that hprxm assembles read data correctly, unfortunately it doesn't wait for burst read completion in case 1, sending arbitrary data from a previous read instead. Case 2 returns correct data, the completion TLP is send-off after burst read has finished.

Looking at internal hprxm read processing, I see the same state sequence triggered in both cases. I didn't yet a recognize a provision to wait for burst read finish before sending completion TLP. Either it's not there or it's not triggered due to wrong assumptions.

Why are we using bursting hprxm interface instead of default 32-bit BAR interface?
- It's necessary to support native memory access of a 64-bit processor.
- We want to implement effective access to 256-bit slaves in DMA and non-DMA mode.

As previously mentioned, we have adjusted application register map to avoid unaligned reads, so it's not an urgent problem any more. Nevertheless I'd appreciate a correction of the seeming hprxm bug.

Best regards

Frank