Forum Discussion

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

SGDMA Write Master FIFO

Hi,

after discussing the implementation of a SGDMA in my system in this thread http://www.alteraforum.com/forum/showthread.php?t=27574 (http://www.alteraforum.com/forum/showthread.php?t=27574) , I now have one last problem that I would like to be solved or explained.

In SOPC builder, when I set up my SGDMA Write Master Component I can choose the internal FIFO to be 16, 32, 64, etc. stages deep. In my current case I have chosen 16 stages.

In the attachment one sees a signal tap recording that was taken right after the configuration of the FPGA. So this is the very first SGDMA transfer after startup.

The SGDMA should write streaming data from my ADC modul to SRAM. The data that comes from the ADC in this case is toggle testdata.

The blue mark in the attachment shows the testdata that goes into the FIFO of the write master module. The green mark shows the data that goes out of the write master FIFO into the SRAM.

What I don't understand is the fact that the first 16 transfers out of the FIFO are zero values. I understand that this is the data that is in the FIFO stages right after power up. But I didn't put this data in so I don't want this data to come out.

What I would like to see is that the data I first put in is also the data that first comes out and no additional data. This would lead to a SGDMA transfer delay of 1 in this case, which would be okay.

The way it is working now means that I have to skip the first 16 32 bit words in my SRAM which to me just makes no sense.

Additionally, if one looks at the usedw signal of the FIFO it says Fh right after the start of the SGDMA transfer. This explains why the FIFO "thinks" that the initial FIFO data belongs to this SGDMA transfer but I would like this not to happen. What can I do about it? Or is it just an effect I have to live and deal with?

Thank you,

Maik

5 Replies

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

    instead of signaltapping the fifo, could you see what the avalon master interface is doing? IE: the ready signal to the write master? data from the write master?

    Also, i think the modular SGDMA on altera.com is easier to work with.

    --dalon
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    The DMA might have been accepting data before you started it up. I forget what the initial state of the ready signal of the ST port but if it's asserted and your own core was feeding data into it before you told the DMA to start writing then I would expect the FIFO to fill up. It's hard to tell what will be happening at the memory from the FIFOs alone though.

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

    Hi,

    I'm using the modular SGDMA which I was pointed to by BadOmen in the thread that I linked to at the beginning of this thread.

    I'm signal tapping the FIFO of the write master because I think I tracked the problem down to this very spot. The results I get from my tests pointed me to this FIFO because if I set up this FIFO in the SOPC builder to a depth of 32 then the same "error" happens except that the first 32 SGDMA transfers contain "old" data (-> data that was already in the FIFO before the current transfer started). So in my opinion there is a straight relationship between this FIFO and my problem.

    I also don't think that my ADC module is delivering data to the SGDMA Write master before the transfer started because if I understand the Avalon streaming interface specification correctly, data is only "flowing" from the source (my ADC module) to the sink (SGDMA Write Master) if both streaming signals "ready" and "valid" are asserted. This is also to be seen in the signal tap screenshot.

    In fact, the "valid" signal in my ADC streaming interface is just mirroring the "ready" signal of the write master because my module is constantly ready to provide current data.

    The next thing that I wonder about is the fact that the "usedw" signals of the write master FIFO jump from 0x0 to 0xF and back to 0x0 without any intermediate states (see attachment).

    If it's necessary to provide additional signal tap recordings I would provide them. Please tell me what signals may be of interest.

    Finally, I could live with this effect. I just would like to know if I made an error during the system building process or if it's just the way it's intended to be.

    Regards,

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

    You are correct, streaming data should only enter the write master when ready and valid are both high. The used signal may roll over to 0x0 because anywhere in the logic that requires the "true" fill level the fifo_full bit is also used. So when you see used signal go from 0xF to 0x0 the fifo_full signal should be high (so the true used is 0x10). When you see the used signal go from 0x0 to 0xF you are seeing the "true" used go from 0x10 to 0x0F.

    I recommend setting up a trigger for the ST interface and making sure your logic isn't inserting zeros and then stopping due to the FIFO filling up. I just checked and the write master out of reset will assert the ready signal so if your component has valid asserted it'll start shoveling data into the FIFO.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi Maik,

    Did you resolve your issue? I am facing the same issue and was interested to know how you fixed it.

    Thanks!

    Eldos