Bad TLP packet issue with PCI express gen3 x8 Avalon-MM 256 bit DMA core

[Altera_Forum]

I am working on spinning up a PCIe gen3 x8 based project on a Stratix V on a DE5-Net board. However, I am running in to a few issues. Right now I am working on getting the example design up and running so I can get a very basic driver implemented. The card will eventually be used in a gen 3 x8 slot, but right now I am testing it in a motherboard that only supports gen1 x4. This also means that I can use my PCIe protocol analyzer, as the one I have will only run up to gen 2 speeds.  

 The example design runs correctly in the simulator. When the design is instantiated on the DE5-Net board, the host computer can detect it correctly and it shows up in lspci. However, I cannot read or write anything to the BARs. This is not a driver issue; the PCIe protocol analyzer shows the proper outgoing read and write request TLPs, however, the received completion TLPs for read requests sent to the DMA module are incorrect.    Example transmit packet:   FB05B400000002000001FFFBFF8000ABB400C9FD    (memory read request, fmt = 0, type = 0)   Invalid completion response: FB02AB0A00000001008008000001000000000000000000902D21B2FD    (completion w/o data, fmt = 0, type = A, incorrect LCRC of all zeros)    It looks like the wrong header is being sent for read request completions. Right now all I am trying to do is read out the first few bytes of the on-chip memory in the example design. I'm not sure if the testbench actually tries read requests, only DMA reads.

[Altera_Forum]

On further investigation, it seems that the core only allows reads and writes of 4 bytes or less. Changing memcpy_fromio to a loop over ioread32 now actually reads successfully. However, there is still an issue of the core producing invalid TLP packets.  

 Looks like what is happening is that some extra data is being sent with the abort status, which is not allowed. The header is generated on like 606 of altpcieav_dma_rxm.sv:  assign tx_tlp_empty[1:0] = addr_bit2_reg? 2'b10 : 2'b01;  Changing this to:  assign tx_tlp_empty[1:0] = is_valid_read_reg ? (addr_bit2_reg? 2'b10 : 2'b01) : 2'b10;  seems to solve the problem, as the protocol analyzer now lists the packet has having a valid LCRC.