DDR3 burst lenght

Larger burst lengths can be an advantage - as long as the data you're transferring resides in contiguous address spaces. Only you can determine the suitability of your data space in this respect. Jump around the memory and you'll quickly lose out. Retrieve a large portion of data, only to use a small portion of it, and you'll suffer too. Providing you can repetitively transfer larger data chunks and process it you should benefit.

So, yes - it may help. Have you tried it? I suspect you're limited to a burst length of 8 with that memory device. Whilst you may be able to configure your Avalon memory controller for burst lengths larger than that, it will limit it's transactions with the memory device to bursts of 8. So, you won't get the efficiency gain you're after, although it may simplify the your code with fewer accesses to the memory controller.

Other ways - can you run your memory faster?

Cheers,

Alex

Thanks, for the input Alex. We are running the controller at max freguency (400 MHz). The transfers are large (2 MB at a time). From "External Memory Interface Handbook Volume 2: Design Guidelines"

The following methods of data transfer reduce the efficiency of your controller:

• Performing individual read or write accesses is less efficient.

• Switching between read and write operation has a negative impact on the efficiency of the controller.

• Performing read or write operations from different rows within a bank or in a different bank—if the bank and a row you are accessing is not already open—also affects the efficiency of your controller.

Since we have two concurrent jobs at the same time (writing video data from the camera and reading video data to the VGA display port). I wonder if increased Avalon burst will increase performance since there will be less witching between reading and writing. I also wonder if burst length equal to RAM page size is the most optimal (besides starvation)

I agree that there will be a benefit in such a streaming application, where you're transferring large, consecutive chunks of data around.

Yes, the handbook statements are correct. However, the memory device only supports burst length of 8. If you're already at 4 I shouldn't expect any huge increase in performance. I expect it'll be relatively modest. As mentioned before, setting the Avalon controller with a burst length any longer is unlikely to yield any performance advantage.

Cheers,

Alex

Hello, I currently have an issue with writing data to SDRAM memory

Due to the requirement of writing video a single video pixel data in a different memory location so I use the writing with a burst length of 1 and data width of 32bits. In reading mode, I used burst length of 32 with the same data width of 32 bits. The color of the video after readout from SDRAM memory is changed. If I use writing burst length of 1 but provide the continuous address then the color of video is correct.

My guess is that when the writing address is changed in every clock cycle the HMC takes a longer time to change the row and bank therefore when it starts writing the data to sdram the data is starting to change to the next writing data.

Is it possible to use the HMC with burst length of 1?

My used device is Cycle 5CEFA9F31I7 and MT41J128M16 SDRAM. HMC is configured at full-rate 400MHz, the max burst length is 32 and data width is 32bits.

https://www.alteraforum.com/forum/attachment.php?attachmentid=14716

Rotation of 90 degrees, the pixel data is stored on the X,Y rotation coordinate, therefore the writing address in the memory is not continuous.

https://www.alteraforum.com/forum/attachment.php?attachmentid=14717

Without rotation, the writing address in the memory is continuous