Forum Discussion

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

SGDMA write_waitrequest always 'high'

Hello everyone,

In order to achieve my project, I have to use my Nios II in order to send data from my FPGA to a server. My FPGA will have to read data from a Dual port Onchip memory which is connected to both Nios CPU and SGDMA (Stream to Memory).

The problem is that I'm having trouble everytime I try to write data from my Hardware component directly to my Qsys Onchip_memory.

I implemented an Avalon_Streaming interface (with valid, sop, eop, error, ready signals) between my Hardware component and my Qsys SGDMA linked to the Onchip_memory and when I check on SignalTap my ready signal is always set as '0'.

Moreover, my SGDMA write_request signal is always set as '1' so that my SGDMA is always waiting to write data that never comes to my memory.

I can't see why my SGDMA is never ready to receive and why it's always waiting.

Is there is something I missed on the configuration of my SGDMA with my Onchip memory?

Thank you in advance,

Michel

9 Replies

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

    Does anyone knows why ready signal of the SGDMA is always set to '0'?

    Thank you.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    waitrequest is an input to the master and since the master isn't writing data I wouldn't worry about it.

    That block providing the streaming data doesn't appear to be following the ST spec. I see it asserting valid and streaming a short 3 beat packet and yet the SGDMA is not asserting ready so it will not buffer the data coming at it. This explains why the write signal doesn't assert, because it's not accepting the data from the streaming port to begin with.

    Did you remember to start the SGDMA or feed it a valid descriptor? When it's idle I doubt it accepts streaming data.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    I think that I forgot to start the SGDMA in my software that's why it doesn't accepts any streaming data.

    I'm sorry for my mistake.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Best kinds of mistakes to make are the simple ones since they are the easiest to fix :)

    I would recommend modifying that streaming core providing data to the SGDMA since it's not adhering to the ST spec. The data, sop/eop, empty, etc... signals should be held constant when valid is high but ready is low.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thank you BadOmen, I followed your advices and I changed my streaming core ^^'

    I also started my SGDMA and fed it with a valid descriptor but I still get the "ready" to 0.

    Even when I don't connect anything in the input of the SGDMA, the waitrequest is high and its ready signal is low.

    I saw that you had a similar discussion with Socrate in the following thread:

    http://alteraforums.org/forum/showthread.php?t=30273&page=2

    My idea is to read the SGDMA ST data just like Socrate did but I don't get why my SGDMA is always waiting for an interruption that never happen because of the ready signal that is always low.

    Do you think that I should try to change my Onchip Memory with an DDR3 RAM ? (the same thing that is done with the TSE exemple)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Only worry about waitrequest getting stuck high if the master is issuing a read or write (otherwise the master ignores it). I also recommend getting the SGDMA working using polling code first and then when that's working then switch over to using interrupts.

    In order to get the SGDMA started you need the following (at a minimum):

    1) At least two descriptors allocated

    2) Make sure the descriptor at the end of the chain has the owned by hardware bit set low

    3) Write the pointer of the first descriptor to the SGDMA CSR slave port

    4) Write to the go bit of the SGDMA CSR slave port

    After# 4 you should see the SGDMA ready signal assert high, data becomes accepted, and eventually the write master will being writing out the data.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    I think that I found the reason why my ready signal was always low even when I attempted everything you said. I put descriptor_read/write signal of my Qsys file on the wrong memory.

    I linked the descriptor_read/write to my DDR3 where the .heap and .data is stored and now the ready signal is working fine.

    I still don't know whether my SGDMA is working or not but the ready signal is high ^^

    Thank you again BadOmen.

    Hopefully it was a stupid error again which can be easily fixed =)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    If you have to debug further I would recommend simulating the design since you'll get to see everything that is happening in the system. Normally when I do DMA debug I have to look at the CPU issuing descriptors, DMA, memory, and streaming cores if present. It is often too much stuff to sample with signaltap so simulation is normally the way to go. Just make sure your Nios II code is minimial so that you don't have to wait long for the simulation to reach the point where the DMA starts running.

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

    I've been doing a lot of testing but recently a new problem appeared.

    It seems that sometimes my full project is corrupted or something like that after a new compilation.

    I'm using the Simple Socket Server with my design which was working pretty well. But since I try to get data back into the Nios II, my design stay locked after the:

    Create "simple socket server" task (Prio: 4)

    Everything's working untill the select(max_socket, &readfs, NULL, NULL, NULL);

    I guess that I can't receive data anymore but all I did was linking different wire together (in order to send data to the SGDMA) without changing anything about the TSE or the Qsys.

    I'm trying to compile the project again but it's not the first time I have that problem and it's being quite annoying to compile everything twice or more...

    Does anyone ever had that problem before?

    Thanks