Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12596 Discussions

A problem with on-chip FIFO memory and NIOS II

Altera_Forum
Honored Contributor II
1,472 Views

Hi there, 

 

I am pretty new to NIOS II, but used to work hard in the previous months :) I stumbled upon a strange behaviour with the On-chip FIFO memory. 

Namely, I have, as a tryout, a system containg a single clock on-chip FIFO (MM to ST) and an SGDMA (stream to memory). Although the both APIs seem to be quite clear and easy-to-use, I cannot seem to get it working. 

The first thing is that when I write to an empty FIFO, it seems as if the data is instantaneously lost for the first four writes. The Empty interrupt is generated as if something reads out the FIFO, althoug the SGDMA has not been set up yet. On the 5th successive write the FIFO level becomes 1 and so on until it overflows. Once the SGDMA is set up, it does not read out FIFO too... 

I am pretty sure the hw has been set up well. Just in case: 

 

FIFO: 

Backpressure on (for the sake of the SGDMA) 

Bits per symbol 8 

Symbols per beat 4 

Error width 0 

Channel width 0 

Packet data enabled (for the sake of the SGDMA) 

 

SGDMA: 

Enable bursting on descriptor read master OFF 

Allw unaligned transfers OFF 

Enable burst transfers OFF 

Data width 32 

Error widths (both) 0
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
355 Views

Probably something is bad with Your SGDMA setup on read side. I've used on-chip fifo and it worked fine.

0 Kudos
Altera_Forum
Honored Contributor II
355 Views

Thanks, I can see that the SGDMA did not read out the FIFO since the descriptors were not placed in a memory mastered by SGDMA MM interface... 

But... the other problem remains, if the FIFO is empty after software reset the first four writes are lost, i.e. immediately after a write to FIFO an empty interrupt is generated and FIFO gets a kind of flushed. It is not a case if the FIFO was not empty at the software reset. The SGDMA is idle at that time, the handle has not even been created before the FIFO is loaded.
0 Kudos
Altera_Forum
Honored Contributor II
355 Views

Let's start from some basics: 

I suppose You use Stream-to-Memory SGDMA? 

The sink interface is connected to the FIFO? 

How do You debug Your SGDMA? E.g. I've placed all of the SGDMA transfers to on-chip memory, which had memory monitoring option enabled. That helped a lot. 

Also, do You use SCFIFO or DCFIFO?
0 Kudos
Altera_Forum
Honored Contributor II
355 Views

OK, I am not sure what happens but I understand how it works... 

Once the SGDMA reads out the FIFO, it gets all the data initially loaded to the FIFO, even the ones reported to have been read before SGDMA had been set up. I mean, after loading 12 words in the FIFO, its level is eight only, but the SGDMA then reads out all the 48 bytes correctly. 

 

As if there is another data FIFO in the DMA write block, 4 words deep. According to the datasheet it should not be there, since bursting is disabled in the actual stream to memory configuration. 

 

Cheers and thanks
0 Kudos
Altera_Forum
Honored Contributor II
355 Views

 

--- Quote Start ---  

Let's start from some basics: 

I suppose You use Stream-to-Memory SGDMA? 

The sink interface is connected to the FIFO? 

How do You debug Your SGDMA? E.g. I've placed all of the SGDMA transfers to on-chip memory, which had memory monitoring option enabled. That helped a lot. 

Also, do You use SCFIFO or DCFIFO? 

--- Quote End ---  

 

 

Yes, I use stream to memory SGDMA, and the sink interace is connected to SCFIFO (MM to stream). 

I debug my SGDMA bia terminal window, it was sufficient here.
0 Kudos
Reply