Behavior of 10 GX Avalon-MM Interface for PCI Express* IP Core when byteenable=16'h0000

Hi,

we are using an Arria® 10 and Cyclone® 10 GX Avalon® Memory-Mapped (Avalon-MM) Interface for PCI Express* IP Core.

During our tests we noticed some illegal PCIe packages generated presumable due to a wrong data length. We could tackle down the problem to the following basic setup:

avalon_mm_master => 128 bit bus => PCIe-Core

When we send the following sequence (two words), we get an illegal/unexpected PCIe transfers/behavior:

1. burstcount = 2, address = address_a, data = some_data, byteenable=16'h0000
2. burstcount = 1, address = address_a+16, data=some_data, byteenable=16'hFFFF

When we only send the second word everything works fine. This sequence originally comes from a qsys autogenerated 256=>128 width change in the interconnect somewhere upstream in our project.

My question is: Do we miss something here? Does the IP-Core not allow for a first word to be completely disabled? If so, is there any (automatic) way to tell qsys / the interconnect to discard a leading all_bytes_disabled word? 5.3. 64- or 128-Bit Bursting TX Avalon-MM Slave Signals

Best regards,

Michael