Forum Discussion

corestar's avatar
corestar
Icon for Contributor rankContributor
2 years ago
Solved

Bug in Avalon-MM PCIe core for Non-Qword aligned writes

The "Avalon-MM Cyclone V Hard IP for PCI Express" does not appear to handle Non-Qword aligned writes correctly. I can't find anything in the datasheet that says only Qword aligned writes are allowed....
Pcie
  • FvM's avatar
    FvM
    2 years ago
    Hi,
    I see the misunderstanding. BAR 32/64-bit setting refers to address width. Data width is the native master width, can be 64 to 256 bit, in your design 64 bit. To see address and data presented to a 32-bit slave, tap the slave interface directly.

    Regards,
    Frank
FvM's avatar
FvM
Icon for Super Contributor rankSuper Contributor
2 years ago

Hi,
the Signaltap recordings don't look incorrect at first sight.
You are performing 32 bit writes, they are translated to partial enabled 64 bit writes. Data position, 64-bit address (a[2:0] masked out) and byte enables are matching for all four writes. The only confusing point is address copied to inactive data part, but it shouldn't cause trouble. Interesting question would be if unaligned 64 bit writes and reads are translated correctly.

Does Cyclone V Bar2 support bursting operation? Then we would expect unaligned 64 bit write split into two aligned writes, otherwise failure.


Regards
Frank

corestar's avatar
corestar
Icon for Contributor rankContributor
2 years ago

Hello @FvM

Thanks for looking at this. I completely agree that data is fine as I noted.

But I have to disagree that the address is not a problem since I have no way of knowing when it is putting it in the bar2_write_data and when it is putting it in the bar2_address. Note: it is not just copied; the bar2_address is wrong. For example, on the third write (after the third bus_enable), it says the address is 0x08 (which apparently is just a hold over from the previous TLP, but has the correct address, 0x0C, in the low dword of write_data. If it had just copied it, I agree it would not be a big deal. But the bar2_address for the first write is 0 (should be 4) and for the third is 0x8 and should be 0xC. I see no way to disentangle this.

I did not include it, but I captured the 64-bit TLP and they in fact look as expected.

I agree it would be interesting to see what 64-bit writes do. Unfortunately, as near as I can tell drivers on the root complex have no way of doing that other than DMA. And the writes I included are the 32-bit writes to setup the DMA. Clearly I could get around it, but the whole point of the Avalon-MM vs the Avalon-ST PCI was to simplify things. The Avalon-ST interface is quite clumsy, but I at least have it working and so have gone back to it.

Thanks again