Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

A problem with on-chip FIFO memory and NIOS II

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

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

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

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- 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.