Burst write transaction on PCIe TX Interface on SOPC application

[Altera_Forum]

Hi All, 

I've realized a Project with SOPC Builder including a PCIe IP, a DDR2 II controller and a custom SOPC components (with Master Avalon Interface inside) that manage a burst write from DDR2 II to TX Inteface of PCIe controller.  Project is implemented on ARRIA II GX Dev Kit.   All transaction has been completed but speed is very low. BURST transaction doesn't work correctly. Verifing TsxBurstCount_i signal with Signal_Tap is always at vale 0x01, while my custom components set it at 0x0100. It seem that SOPC Builder not connect corretly output of my custom master port with slave port of PCIe TX Interface.  I'm working with Quartus II v9.1 SP2, but I've verified also with Quartus II v10.0.  Has anyone never write a burst transaction on TX Interface of PCIe with succefull?  Thank you.-

[Altera_Forum]

Is your component declaring that the burst width is at least 9 bits (since you are sending a burst of 256). 

 I haven't hooked up my bursting stuff to PCIe personally but others have and had good luck with it so it is possible to get good throughput.  Also I'm not sure what the PCIe max burst count is but I thought it was 128. If that's the case you are probably better off matching your master max burst count to 128 so that you can avoid any burst adapter logic that SOPC Builder will insert between your master and slave port. You'll get one regardless on the SDRAM side unless you decouple the burst counts on the read and write but that requires the read and write control logic to manage the bursts separately.  I would also recommend simulation or signaltapping the master and slave interface to see exactly what the traffic looks like to make sure it is actually the writes causing the throughput problem.

[Altera_Forum]

It could be the first write caused the burst adapter/fabric to get stuck in an undefined state. Can you attached the .stp for the previous write operation to the PCIe tx slave port.

[Altera_Forum]

Dear BadOmen, 

in my previous test there isn't any write on Tx Interface before burst, but I've done another test, attached in .stp with a no burst write operation before start burst.  As you can see in the .stp also during no burst write burst count of Tx Interface is always at 0x01 while burst count of Avalon MM Master is at 0x00.  Let me know your opinion.  Thank you.

[Altera_Forum]

Actually I'm surprised the fabric didn't lock up when the master posted a burst write transaction of 0 beats (that is not allowed in Avalon-MM).