DDR3 UniPHY 10.1 Core Burst of 8 vs. 4 Behavior?

You may be seeing the effects of burst wrapping. SDRAM have a concept of bursts that cross a burst boundary wrapping back to earlier addresses rather than progressing linearly. Lets say your memory local interface has a max burst count of 2 and is x32 wide. That means the burst boundary is multiples of 8 bytes. So if you start your burst at 0x0, 0x8, 0x10, etc... then you shouldn't see this chopping. If you start at address 0x4, 0xC, etc... then unless your master supports burst wrapping (I don't know of many that do) then the burst needs to get chopped up into bursts of 1 to avoid crossing the boundary.

So using the example above if my master wrote 0xAAAAAAAA followed by 0xBBBBBBBB to address 0x4 using a burst of 2 I would expect the following data cells to be stored:

wrapping master: address 0x4 contains 0xAAAAAAAA, address 0x0 contains 0xBBBBBBBB

nonwrapping master: address 0x4 contains 0xAAAAAAAA, address 0x8 contains 0xBBBBBBBB

So when you have a mismatch in wrapping capabilities the system needs to assume the burst behavior of the master. In the non-burst wrapping to burst wrapping case this means that any time a burst crosses a burst boundary then it needs to be divided into smaller bursts.

So to avoid it you may be able to make sure all accesses are aligned to a burst boundary or a multiple of it. In the modular SGDMA design example what I do is turn on an option that makes sure the master gets back into burst alignment and turn on a property that tells SOPC Builder/Qsys that all bursts that follow will be aligned on the burst boundary. The easiest way to do this is to do a bunch of bursts of 1 to get back into alignment and then burst the maximum amount multiple times back to back.

Let me know if that makes sense, this confused me a while back when the memory controller would do this but not tell the tools it was doing it which lead to a functional failure.