Arria 10 DDR4 EMIF Burst Length Expansion

[Altera_Forum]

I'm working on an Arria 10 design where I would like to be able to support bursts of up to 512 words on the Avalon-MM interface into the SDRAM DDR4 EMIF. This parameter is not configurable in the IP parameter editor for the EMIF, so I would like to add an adapter to increase the maximum burst length. However, I've been having trouble choosing the correct one. I have looked at the following adapters, but none of them seem to quite serve my purpose: 

  

• Avalon MM Slave Translator 
• Avalon MM Master Translator 
• Avalon MM Unaligned Burst Expansion Bridge 
• Memory-Mapped Burst Adapter 

  Is one of these the right adapter that I am configuring incorrectly, or is there another that I'm missing? I've read through a lot of QSYS interconnect documentation and was not able to find an answer.  Thanks, Andrew

[Altera_Forum]

Even if you add an adaptor, if the IP doesn't support that large of a burst, you're not going to get that size burst. Can you do back to back bursts of 256?

[Altera_Forum]

Isn't one of the purposes of the QSYS interconnect logic to generate fifos and adapter logic to manage the different widths and burst capabilities of interfaces? 

 From the quartus handbook (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/qts/qts_qii5v1.pdf), p.8-16:  using bridges to minimize adapter logic Qsys generates adapter logic for clock crossing, width adaptation, and burst support when there is a mismatch between the clock domains, widths, or bursting capabilities of the master and slave interface pairs. Qsys creates burst adapters when the maximum burst length of the master is greater than the master burst length of the slave. The adapter logic creates extra logic resources, which can be substantial when your system contains master interfaces connected to many components that do not share the same characteris‐ tics. By placing bridges in your design, you can reduce the amount of adapter logic that Qsys generates.   This tells me that adding an Avalon-MM Pipeline Bridge with my desired max burst size will implicitly add all the required burst size adaptations. Should I be wary of this assumption?  Thanks, Andrew

[Altera_Forum]

That is for allowing different component interfaces to communicate with each other in the generated system interconnect. It does not change the capabilities of the actual IP that communicates with the RAM outside the system. So your master interface could issue a 512 burst to the memory controller (the slave). The adaptor translates this into a burst size that works for the IP and the IP issues commands to the external RAM. Responses back to the master would be translated as well. It depends on if this is the behavior you want. 

 Note also that the burst adaptor on its own adds a large amount of logic to the design and can often be the cause of timing issues in the system, which are ugly and difficult to debug since it's inside the generated interconnect. The handbook text you mention is indicating to add bridges, which would get placed on either side of the burst adaptor to help minimize the burst adaptor logic.