Forum Discussion

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

making an IP for DMA transfers

Hello everybody.

I work with the Terasic DE2-115. I'm trying to plug the TRDB-D5M camera on a NIOS II with ethernet.

I can read data from the camera with the IP given by terasic, and I can use the NIOS II with ethernet without any problem.

But, I have some difficulties to plug the camera on the NIOS. As I can't read the camera on interrupts (there is a lot of pixels), I want to use a DMA. But I read somewhere that the PIO don't work with DMA.

So I'm trying to build my own PIO with a pixel clock input. I want this clock to trigger the DMA.

So my question : what signal do I have to drive on the avalon MM slave bus to trigger the DMA ?

8 Replies

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

    I would recommend something more along the lines of a FIFO. So you send the camera data into the FIFO and the DMA empties the FIFO. If the DMA is faster then the FIFO will hit empty and backpressure. Using a DMA supporting MM fixed address reads or streaming data should work. For example you can use the DMA (not the SGDMA) in SOPC Builder/Qsys to do this:

    Camera interface (ST) --> (ST) FIFO (MM) --> (MM) DMA (MM) --> (MM) SDRAM

    If your camera interface is really simple you might be able to get away with just exporting the ST interface of the FIFO directly out of your Qsys system and connecting it directly to the I/O with a little bit of glue logic.

    PIOs are typically not a good choice for this sort of thing because you are either pulling in samples and you can't easily sample a PIO in a deterministic way, or they are susceptible to missing samples (when you don't poll fast enough). With a FIFO get both assuming you can empty the FIFO faster than you fill it.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    In the process of doing something similar but need to cross from transceiver derived clock to system clock and 16bit data to 32bit storage.

    For now trying to avoid much user logic.

    Transceiver --> (16b)FIFO(32b)-->Qsys-->(ST) FIFO (MM) --> (MM) DMA (MM) --> (MM) DDR3 SDRAM

    The megawizard DCFIFO does the clock and bit cross, the Qsys on chip FIFO ST port provides the pin access, and the DMA (with its own FIFO) pumps data to DDR3.

    So that's 3 FIFOs.

    Possible alternative would be to create a Qsys new component FIFO to combine the function of the OnChip and the Wizard FIFOs. Probably easy but would like to know how.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Yep should be easy to do. I'm guessing the 16b to 32b FIFO uses flow control similar to Avalon ST. So it should be a matter of making the 32b side ST compliant and removing the secondary FIFO. If possible I would try to make the traceiver to FIFO interface ST compliant, if that's possible then I think there is a FIFO component in Qsys that supports different data widths on each side which you could use instead and not have to worry about custom FIFO logic.

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

    The Qsys OnChip FIFO interface is ready, valid, and data[31..0]

    Planning to connect Qsys:ready--> DCFIFO:rdreq

    and DCFIFO:empty --> NOT--> Qsys:valid

    That seems to work using a DCFIFO --> SCFIFO test design.

    Assumptions based on documentation that OnChip FIFO implements an SCFIFO for single clock option.

    I attended a Qsys workshop a couple of months ago and have a copy of mSGDMA (from PCIe example) in the files ... so installed a write master and dispatcher hooked up with ST export. Sure enough got the same 3 ... ready, valid, and data[31..0]
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    That's correct, the mSGDMA uses streaming as well so the ST port of the write master can be used for this sort of thing as well.

    I would make sure you have the latest version of the mSGDMA if you use it in your design, you can find it here: http://www.alterawiki.com/wiki/modular_sgdma I'll be updating it soon with a couple of small enhancements and a bug fix for packet ST-->MM transfers.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Managed to get both the legacy DMA and mSGDMA to function for prototyping. We need to fill ddr3 memory continuously while looking for an event and keep some large buffer before and after.

    Seems like the mSGDMA might work if no data is missed between descriptor blocks. Exposing the Done Strobe on the Write Response might make tracking the event location a bit easier.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    By missed data do you mean if the DMA is in the middle of switching between descriptors data could be missed? With the ST protocol that should never happen, the only way that would occur is if the DMA is being filled with data faster than it can write the data to memory, but the data would be dropped by whatever is providing the data and not the DMA itself (ST can't drop data if implemented properly).

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

    We have the mSGDMA operating in continuous DMA mode and start and stop under NIOS software control using a seperate VHDL module to detect the trigger events and count samples from there. In continuous mode the mSGDMA wraps around the assigned address space without problems.

    Should mention that proper capture of DMA data to the DDR3 controller requires using the faster of the two DDR3 controller output clocks to run the internal qsys DCFIFO.

    The assumption that a regular megawizard FIFO can function as a streaming interface model in simulations seems to work out. The FIFO has to be in look ahead mode for the simple hookup. I got the normal synchronous mode to work using some extra glue logic but a casual search did not locate documentation to confirm using that design as a streaming model.