Nios II Burst Questions

[Altera_Forum]

Hi all, 

I need some help regarding bursts. First of all, I have designed a custom Avalon peripheral which acts like a bridge between Avalon and a custom DDR controller. The custom DDR controller always bursts back (both for reads and writes), so I have implemented a caching mechanism between. Everything is operational, but now I have to implement bursting, which is fairly simple. However, I do not understand Avalon bus property BurstOnBurstBoundariesOnly. I have made burstcount to the length of 6 (5..0), so maximum number of transfers is 32.  The BurstOnBurstBoundariesOnly property is set to true, and according to Avalon Bus specification, when this property is set, it should only burst with large bursts on burst boundaries (which means always bursting with 32 transfers on addresses that are multiple of 32). However, I can clearly see short transfers (lengths 3,5,8) on bus. I should probably mention that this is on Nios Instruction Master port only (I still haven't implemented write bursts, so I can't enable bursts on Data Master port yet). Now, everything works perfectly, but I am concerned that it might happen for Nios to ask for a burst of size, let's say 8, on address, let's say 27. This would mean that it would ask a burst which is between two burst blocks (0..31, 32..63), and that won't end well. Can anyone explain to me what's the practical use of this Avalon property, and whether it applies to both Instruction Master and Data Master ports? And whether my worries are justified? Thanks in advance!

[Altera_Forum]

I think you will only see bursts on cache line reads/writes (if they happen at all). 

Possibly the cache line reads are done requesting the wanted word first - which might be an explanation for what you are seeing.

[Altera_Forum]

Well, that's one more thing I don't understand. The property LineWrappedBursts is turned off, so technically, for Nios, it's what-you-ask-is-what-you-get principle. Hmm... maybe that really explains the situation. 

Ok, as long as it keep bursts inside one cache block, I have no problems with it. It gets ugly when it doesn't, and so far, I haven't seen that situation - I'm just trying to figure out why.

[Altera_Forum]

With old memory technologies (I can't remember whether it changed for SDRAM or DDR) processors used to read cache lines using an 8 word burst that started with the word they wanted - rather than the first word of the cache line (doing CAS only memory cycles while holding RAS asserted). 

This gives lower memory latency. Modern memories directly support sequential burst access - but these won't wrap - so the burst must finish at the end of the cache line. I suspect bursts can start mid burst/cache line, so the cpu could still read the requested word first by doing two memory bursts. OTOH I went out of my way to use only tightly coupled memory and disabled both the instruction and data caches!

[Altera_Forum]

The instruction master when bursting is set to 16 or 32 bytes per line will issue a burst starting at the offset on the cache line that cased the eviction. The data master always bursts on burst boundaries (start of the cache line). This property along with others like linewrapping bursts and always full bursting lets the tools know how to configure the burst adapter between CPU masters and the slave. For example if you created a sequential bursting master and hooked it up to a burst wrapping slave a burst adapter will be needed to handle chopping up the burst to avoid the wrapping conditions on the slave side (if bursts don't always start on burst boundaries). When the CPU instruction/data masters burst the linewrapping property is enabled for the instruction master and disabled for the data master. Likewise the instruction master always issues a max burst whereas the data master does not. 

 Back to your original post, if your caching component always issues bursts starting on a burst boundary then you can set the burstboundary condition to true. The only thing I have ever seen issue line wrapping bursts are processors so I guess use that to determine if your caching component needs to do the same. If your caching component will always do full bursts to the memory on the other side then you should probably enable the maxburst property. All these settings will impact the burst adapter between your caching component and the memories hooked up to it (if an adapter is necessary).