How to increase DMA fifo depth?

I'm not very knowledgable with DMA's but wouldn't that mean you should drop you interupt down to something that occurs sooner (maybe when the dma is half full).

To me it sounds like the interrupt happens too late and the fifo fills up before getting emptied out (although I would have figured the emptying process would be faster then the filling but again, I have never played with DMAs before).

Hopefully someone will be of more help

G-luck

Hey BadOmen,

No, I'm responding to the external fifo's IRQ in plenty of time. In fact the fifo's level never even makes it to 481, before my ISR starts the empyting process.

However, inside of the DMA object there is a tiny fifo to handle Avalon delays, etc. *This* fifo is the one over-flowing.

If I can get this internal fifo raised this will be pretty nice, as the DMA is emptying the fifo at a rate of 1 word per 2 cpu clocks (at 75MHz). I may be able to increase it to 1 word per 1 cpu clock, but not until I give the DMA some more room.

Ken

Oh ok (that's makes more sense to me now)

Ya I didn't realize that it doesn't have a "full" type status available. Maybe it's something that can be configured in the HAL stuff. So in a nutshell, you're other fifo reaches it's full count, triggers the IRQ, and the NIOS responds by doing a DMA transfer of it's FIFO contents to a RAM.

You DMA fifo length is longer then the other fifo length right?

Ok, I solved this.

I manually editted the .ptf file for my SOPC system and in the WIZARD_SCRIPT_ARGUMENTS section for the DMA module in question I added the following line

fifo_depth = "5";

This got rid of all errors! Awesome!

The default fifo_depth is 2, raising it to 5 gave the DMA engine enough timing leeway to work with the sdram.

This is pretty cool. It means on avg. I'm dma'ing one 32 word into sdram every 26ns.

I'm going to to some more testing on more loaded system and see if 5 is enough or if I need to increase it more.

Ken

Hi KenLand,

It's additional info. It seems that fifo_depth numbers will be replaced to power of 2.

We can see following code in em_dma.pm.

if (not is_power_of_two($Options->{fifo_depth}))

{

$Options->{fifo_depth} = next_higher_power_of_two($Options->{fifo_depth});

}

Thanks Koma,

I should update this thread with the latest. Raising the fifo depth helps a bit, but there is a problem in that the dma reads do not heed the FIFO_FULL flag and so anytime your Avalon bus gets busy during a dma it can corrupt the data.

I have submitted this as a bug to Altera and hope it will be fixed very soon.

I looked through the dma HDL to see if it would be simple to qualify the reads with !FIFO_FULL, but I'm afraid my HDL skills are nil.

I think Altera must have known something was up as the nr_dma_* functions all loop until the dma is complete - thus turning the dma into a synchronous memcpy. So if you're expecting true dma behavior you'll have to modify the dma calls. I looked through the NiosII/HAL dma code and it appears to function correctly.

Anyone useing dma's should run a lot of test data through the system under heavy load and check for errors. Setting a SignalTap trigger on the dma's FIFO_FULL is also a good idea.

Ken

Hi Ken,

Thanks a lot! That's good (bad?) news for me.

I will check that.

Thanks!

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

I have submitted this as a bug to Altera and hope it will be fixed very soon.[/b]

--- Quote End ---

I know this is a really old thread, but does anyone know if this has in fact been fixed? I&#39;m seeing very similar issues, and this could motivate a move to the latest and greatest Altera stuff.

Any insight would be greatly appreciated.

Thanks,

Ryan

Quantapoint

I worked with Ken Land on this issue quite some time ago (circa Nov 2004). After studying the problem for a while, I determined that the bug was not in the DMA, but rather in some user logic in Ken&#39;s system. At that time I felt that Ken accepted this result, and that the matter was closed.

Just for general info: the Avalon DMA has an internal FIFO to help improve throughput. It is true that the default size for this FIFO may not be large enough to provide optimal throughput, and the ptf assignment Ken mentioned can be used to bump up the size. It&#39;s also true that the size is rounded up to a power of two. You can read all about in the DMA generator program (em_dma.pm in the DMA component directory).

It is _not_ true that data is corrupted within the DMA when its FIFO becomes full.

Ken, if you&#39;re out there somewhere, would you care to step in and add your end-note?

Hi Kero,

Boy were you great to help out with that problem! Thanks again! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

If you search I did post the changes that made it work. I don&#39;t remember any more. It involved editting the .ptf. - maybe a latency setting.

Sorry I can&#39;t be of more help. Ultimately we had to abandon DMA for the streaming data, because although dma emptied the fifo into sdram lickety split, reaccessing the data to operate on it was dismally slow. (12-13 clocks per access!!!!)

We wound up having a Custom Instruction written that would pop a 32 bit fifo word into a register in 2 clocks. Then we could operate on it quickly.

I think with the new features in the latest Nios this would all be much easier. Namely the tightly-coupled memory interface. I&#39;m pretty sure our dilema was a motivation for its creation. (thanks James, Jesse, Kero !!!)

Ken