Hello, I have a hard time understanding how the Nios II handles memory accesses. In our Nios II design we want to use burst transfers to transfer data from SRAM into the caches of the processor or to on-chip memory. Does the Nios II processor use burst transfers by default or do we have to explicitly enable burst transfers? Is it recommended to use a DMA controller to transfer data from the SRAM to the on-chip memory? Regards Martin

You have to set 'enable burst' on the cache memory to get cache-line sized memory bursts for cache line fill/writeback. Memory cycles to tightly coupled memory and cache hits complete in 1 cycle, but the data value (for reads) can't be used in the next two instructions (cpu stalls if you try to do this). Memory cycles over the Avalon bus are synchronous on the processor (ie it stalls until the slave cycle finishes), the two cycle delay then applies to reads. I'm sure it wouldn't have been that difficult to give the option of 'posting' a single write. Aynchronous reads would be slightly more difficult (due to scheduling the write into the register file).

When bursting is enabled in the cache settings, the following burst lengths are used: Instruction master burst length = 8 (32-bit wide beats) Data master burst length = 4/8 (32-bit wide beats base on cache line size of 16/32 bytes) For SRAM accesses enabling bursting on the CPU side doesn't buy you anything since the memory doesn't support bursting. Whether using a DMA makes sense depends on the algorithm you are implementing. If your code works on small buffers of data that fit in an onchip RAM then it might make sense to DMA the data from ofchip SRAM (I'm assuming you are using SRAM and not SSRAM) and access it as tightly coupled memory. If you are doing short quick accesses then the overhead of moving the data with a DMA is probably not worth the effort.

Hello, the topic of using bursts transfers to the processor popped up again. This time I have written a component which exposes a bursts capable Avalon MM Slave interface. Is there a cost associated with enabling the "Bursts transfers" option for the Nios II processor in Qsys? Regards Martin

When the master and slave are perfectly matched in terms of width, max burst count, and burst wrapping capabilities then there is no overhead in SOPCB or Qsys. When burst adapters must be inserted in the logic due to a mismatch there is no overhead with the adapters in Qsys (there is overhead in the ones for SOPCB though). So the only cost is the additional logic in any burst adaptation logic that Qsys might need to insert along with the extra logic in the masters to perform the burst. If you require burst adaptation logic it's possible that the master provides a suboptimal burst for the slave interface you have built. I don't know what your slave is so I can't say for certain.

My slave exposes a memory interface to the Nios II processor. The width of the data bus is 32 bits and the number of pending read transactions can be set by generics. There are also other devices attached to the data bus like SRAM and DDR2 memory (I'm developing on a Altera Embedded Systems Development Kit, Cyclone III Edition). The SRAM is not used currently but for the target platform we have designated SRAM as main memory. Does the DDR2 SDRAM Controller with ALTMEMPHY support burst transfers? There doesn't seem to be any documentation for Qsys. I've only seen a datasheet for the MegaWizard.

Burst transfer from memory to Nios II | Altera Community

13 Replies

Altera_Forum
Honored Contributor
14 years ago
Thank you! I think I know what it is now - we wanted one onchip memory for code and data and want to send data stored in this onchip memory. I see we would have to create a second onchip region to do this, which is OK but not as convenient.

Bill
Altera_Forum
Honored Contributor
14 years ago
Assuming you have enough room in your code on-chip memory then it should be possible to use it for the data storage as well for the SGDMA. You might want to keep those as separate onchip memories for performance reasons though (so that Nios can access one and the SGDMA access the other concurrently).
Altera_Forum
Honored Contributor
14 years ago
Or give the nios 'tightly coupled' access and let the SGMA access the other as an Avalon slave.

If you are using on-chip memory for code/data the performance is better if you use tightly coupled memories. It may well mean that you don't need the instruction or data caches (except you'll need the i-cache to use the JTAG debug and most of the boot options).

You do want to make sure that the code put into tightly coupled instruction memory is pure (contains no data) - to avoid slow Avalon cycles to it. This probably required you use a non-standard linker script and may be impossible if you are trying to use the default EPCS loader. Also the gcc4 built by Altera puts jump tables (for switch statemants) into the code segment - you'd need to use the gcc3 build (or rebuild the compiler).
I also got worse code from gcc4!

Forum Discussion

Burst transfer from memory to Nios II

13 Replies

Recent Discussions

JTAG_UART stuck in printf

NIOS SDK SBOM/FOSS info

NiosV µC/OS-II

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

AshlingRISCFree IDE Build system: 'source directory does not appear to contain CMakeLists.txt"