Re: address alignment during master write bursts?

Altera_Forum · ‎08-30-2007

Moin,

Have some strange behaviour right here:

I'm using QII6.1 and the CyclonII-NIOS-Evalboard; have built a sopc containing (besides other things) a PLL generating the clock of 85MHz, NIOS-CPU, a DDR-SDRAM and a self built component having an avalon master port, doing some DMA to the SDRAM.

This unit uses burstaccess for the SDRAM with different lengths (between 10-16 transfers).

After that, i use the NIOS with some q&d software to read and display the contents of the SDRAM area.

For tests i do a burst-transfer with length 11 of this data:

0x00000000,0x11111111,0x22222222,....0xaaaaaaaa

Everything looks ok, left column is the memory address(=target of the DMA Transfer), right column looks like the transferred data.:

82053a20 : 0
82053a24 : 11111111
82053a28 : 22222222
82053a2c : 33333333
82053a30 : 44444444
82053a34 : 55555555
82053a38 : 66666666
82053a3c : 77777777
82053a40 : 88888888
82053a44 : 99999999
82053a48 : aaaaaaaa

But when i use another target address, which doesn't end on zero, but e.g. on 4, i get results like here:

82053a24 : 0
82053a28 : 11111111
82053a2c : 22222222
82053a30 : 77777777
82053a34 : 44444444
82053a38 : 55555555
82053a3c : 66666666
82053a40 : 55555555
82053a44 : 88888888
82053a48 : 99999999
82053a4c : aaaaaaaa

Totally mixed up - but i couldn't find anything in the avalon-spec regarding the alignment of addresses at the beginning of burst transfers. With addresses ending on 0x8 or 0xc even worse, some of the transfers go also at lower addresses as the starting address...

Does anybody have more information about this?

Looks like i have to split my bursts into at least 2 parts to avoid alignment problems - but where can i find some information about the alignment sizes, burst sizes, etc.?

Cheers,

WK

PS: Phase of SDRAM Clk should not be the issue, the NIOS alone is running properly and i have no changes in behaviour, when i change the phase (at the PLL) in a range of +/-45°

Altera_Forum · ‎09-11-2007

Moin,

Hmmm, not much response yet: Nobody else having such kind of problems? Or is the solution much too obvious to post here? :)

I've solved it so far by using an initial burst with length 1-3 (or no initial burst, if the address ist already aligned) and then proceeding with 16xfer bursts, but i would feel much better if i'd had some specification somewhere, describing the burst abilities of avalon components.

Cheers

WK

Altera_Forum · ‎09-11-2007

I had a similar issue about a year ago, this may not be 100% correct, but when you burst into DDR2 it will do a essentially a cache wrap, take a look in the DDR data sheet it should talk about it. THe DDR core and SOPC do not honor this, i.e. it assumes linear addressing.

Altera_Forum · ‎09-11-2007

Hi Sledghedge post is exactly correct:

When you do burst transfers to the the DDR2 controller, the burst fabric doens't break up the burst based on the DDR2 burst limitation, so unaligned bursts will give you this problem.

This problem changes based on what type of RAM you are talking too. DDR and DDR2 have different native burst lengths, but I believe the problem exists for all of them.

(I know for sure it exists for DDR2)

We had to correct this problem in each of our master devices. However, if you are willing to attempt it, there is a generated file usually called burst0.v, that can be modified to fix the alignment issue.

The problem with fixing it this way, is it is generated every time you modify your SOPC system, so you either have to update the script (At your own risk) that generates the burst0.v or remember to copy the fix after every SOPC generation.

I really wish Altera would fix this issue, because it is a performance killer when doing video warping.

But they claim it's a limitation of the DDR2 not the burst system, but they also don't document this issue anywhere.

Regards.

Pete

Altera_Forum · ‎09-13-2007

Moin,

Thanks for the hints, i'll have a look into the SRDAM datasheet.

So i might assume that i'll have less difficulties with bursting when i switch from DDR-SDRAM (i currently have to use on the NIOSII-Eval-Board) to SDR-SDRAM (i plan to use on my own HW-Design).

Cheers,

WK

Altera_Forum · ‎09-13-2007

I would expect the problem still exists with the SDR as well.

The boundaries vary however. For DDR2 the native burst length is 2, for DDR it's 4 and I believe for SDR it's 4. So where the problem shows up, is depended on the native burst length, but I believe it exists for all of them.

Pete