Forum Discussion

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

DMA & FIR Filter, some questions.

Hello everyone,

I'd like to implement a FIR filter (because it's easy to start with) in DSPBuilder. It should make use of DMA. I finally want to integrate it into an NIOS II based system using SOPC-Builder. I'm struggling at how to integrate such signal processing into an SOPC component.

I had a look at several tutorials regarding Avalon interfaces, but I still don't know what approach would be the best.

I see mainly the following solutions:

- Building the complete SOPC-component in DSPBuilder by using one Avalon MM Slave block (for control) and two Avalon MM Master blocks(read/write for doing DMA). Seems a lot of work for such a simple task, especially if you want pipelined/burst masters.

- Making use of some master templates like this one altera.com.cn/support/examples/nios2/exm-avalon-mm.html. Using HDL Import I can bring them into DSPBuilder and connect some logic around it, but what would be the correct way to bring the whole system into SOPCBuilder? Compile and add per generated *.tcl script, or maybe export HDL and use the SOPCBuilder's 'new component' dialog?

- Could I use the DMA-Controllers which are integrated in SOPCBuilder (DMA, SGDMA) to connect to some DSP-logic, what kind of interface would this logic need. I can imagine how to use these controllers to copy e.g. from the SRAM to the SDRAM, but again how do I get some signal processing in between.

Any hints and tips appreciated.

Best Regards,

Sebastian

15 Replies

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

    Looks like a cache coherency problem to me. If you have a data cache enabled for the CPU then when you write to the "From value" it might be in the data cache. Nios II implements a write back cache which means the data will only arrive at the memory when the line is evicted as a result of a miss or it is flushed. Either remap those pointers to be uncacheable or flush the data cache before triggering the DMA so that the contents will be written out to memory before the DMA attempts to move the data.

    http://www.altera.com/literature/hb/nios2/n2sw_nii52007.pdf
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Didn't solve the probem, I checked flushing the cache, making pointers volatile and finally disabled the data cache in the hardware design. Any other ideas?

    I originally thought it might be a SDRAM timing issue, but manually copying the array value for value works every time.

    Regards,

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

    Copying data one at a time won't stress the memory out as much as a DMA. I recommend running this through a simulation to see if you can spot the same failure and if so look at the data moving by to see where the problem may be occurring.

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

    Okay, now it works. I had marked the "extended feature" checkbox in the SOPC configuration of the dispatcher core. But on the software side I used the standard descriptor. It shows that you MUST use the extended descriptor as soon as you enable the extended feature checkbox. The documentation was not 100% clear about this, only: "In order to use the extended format you must select 'enhanced features' in the dispatcher...". I probably assumed that the standard descriptor is simply defaulting to certain values, when used in "extended" mode.

    Second thing I noticed is that when you open the included quartus example project, the DMA is wired incorrectly. E.g. the Dispatcher-READ-Response-Sink is connected to the WRITE-master-response-port. Can you confirm this? I attached a picture... there I just opened the freshly unzipped example project.

    Regards,

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

    I'm going to generate a new pdf for the user guide so I can probably improve it to make it more clear that extended descriptors must only be used when the extended features are enabled.

    I just found out yesterday the response ports are wired up backwards. Nobody noticed since the software still works because by the time the CPU goes to validate the data the DMA is already complete. There will be an update to the files soon (probably next week) which will correct this issue as well as add these features:

    - Stop on descriptor (instead of just stopping in the middle of a transfer)

    - Early done enable for reads (so that the read master doesn't have to wait for all the data to return before moving on to the next descriptor)

    Both of these new features will have added code in the drivers but you shouldn't have to update the application code unless you want to make use of them.