Forum Discussion

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

Streaming DMA into NiosI

Hello,

Great Forum! Love the Nios!

(but that&#39;s not the subject of this post http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

We&#39;re having much trouble streaming data into a Nios UDL port.

The Nios is clocked at 75 MHz, is running in a Cyclone EP1C12, and we are trying to use Dataavailable_n to control the flow for 1-2MHz 32 bit values.

The idea is we setup a dma for a packet of anywhere from 1K to 11K 32 bit values from this single address port into 32 bit SDRAM. (same as on the Cyclone devkit)

So the dma is setup and then the transfer begins and when a value is ready the external (to the Nios, but inside the Cyc) logic pulls DAVn low and waits for RDn from the Nios. Once RDn is detected, DAVn goes high until the next value is ready. Once the proper number of values is transfered everyone is happy.

Two problems.

1. We&#39;re getting both double reads and skipped values (never more than one skip)

(We can detect this because the lower 2 bits of the 32 bit value are a counter)

2. The first RDn can take upto 30 xfer times (missing these values) before it comes. Once the first one asserts, its pretty timely after that.

First of all, after trying timing variations and this and that for several weeks we wonder if it is possbile or not? We&#39;ve tried deasserting on the falling edge of RDn but we miss many reads that way - meaning it appears that the read doesn&#39;t actually occur if DAVn deasserts too early. (even though RDn looks good on the LA)

We&#39;ve tried deasserting DAVn on the rising edge of RDn, but that leads to double reads. (looks like a glitch on the LA) Adding waits and holds doesn&#39;t help this.

Any suggestions? Our next try will be to deassert DAVn on the next rising edge of the clock after RDn goes low. To address 2. we&#39;re going to try raising the priority of the port.

Think this might work? Any chance the newer versions of periphs in Nios II kit would help?

The other idea is to abandon this approach and make the peripheral an Avalon Master, but I wonder if the problem in 2. will show up as an extended waitrequest.

Any comments or suggestions are greatly appreciated.

Ken

2 Replies

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

    Ken,

    I may be able to help with this problem, as I wrote the DMA controller generator program. Can you clarify this statement:

    "The Nios is clocked at 75 MHz, is running in a Cyclone EP1C12, and we are trying to use Dataavailable_n to control the flow for 1-2MHz 32 bit values."

    Does this mean that datavalid_n is not synchronized with the 75MHz system clock? If so, I think this is your problem: signals driving the avalon bus really need to be running on the same clock as the rest of the system.

    -Aaron
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Hi Aaron,

    The data coming in is (or was) synched to the cpu clock. The 1-2MHz meant that every say 30-80 clocks a value would be ready to be read into (streamed into) the Nios.

    We were looking at Example 17 on page 69 of the Avalon .pdf, so the peripheral was attempting to load this value on demand into the Nios using dataavailable just as shown. We got it to work somewhat, but never without errors as described earlier.

    Anyway, we finally had to give up and used an Avalon Master Port instead and had the peripheral write directly into the buffer. We followed example 13 on page 53 and had this working in no time.

    I&#39;m still integrating this module back into the overall system, but the test Nios with this port is working flawlessly.

    Thanks,

    Ken