2008-04-02 10:42:29     DAB congestion due to urgent DMA?

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

2008-04-02 10:42:29     DAB congestion due to urgent DMA?

Hans Eklund (SWEDEN)

Message: 53545    We have a scenario where we have short bursts of (25 Mhz PPI clock or more) PPI data commming in, its a high resolution frame commming from a image sensor. We get PPI overflows and Im qute sure it has everything to do with the BFIN MAC and PPI competing for the DAB(DMA Access Bus, it goes between DMA to peripherals). Thing is, this should not need to happen, the PPI transactions only occupies 26% of each timeslot(or 0,9ms per transfer in a 30fps=3,33ms slot example). We have investigated other options, such as SDRAM bank switch latency. It is really a clear case of bus congestion, flood pinging the blackfin generates loads of PPI overflows and would destroy the frame.

 

I would like to keep the bus for PPI transfers only during that time(0,9ms). During the other 3.33-0.9=2,43 ms there is time to do any sort of work on the bus. Would there be a way to ensure we have exclusive access to the bus during the entire PPI transfer? The DAB bus arbitration says PPI has highest priority. However, HRM says the BFIN MAC has the ability to utilize the DMA Control command and issue and urgent transfer. Could that be the cause? we lose to the MAC due to this. I also read that peripheral could be flagged as urgent if a transmit fifo is empty/receive fifo full AND its DMA request line is asserted, so potentially any peripheral could screw with our PPI DMA transfer here.

 

In our case, an IP packetloss(wich may be recovered) would be prefered over loosing a frame from our sensor. Could this be handled somehow? During our PPI transfer i would like the core to do image processing(last image) for example, but not allow peripheral DMA transfers.

 

/Hans

QuoteReplyEditDelete

 

 

2008-04-02 16:22:25     Re: DAB congestion due to urgent DMA?

Robin Getz (UNITED STATES)

Message: 53567    Hans:

 

What chip are you working with? Some of the low level details (which you are asking about) are different on the different parts.

 

I assume 537?

 

-robin

QuoteReplyEditDelete

 

 

2008-04-03 03:19:36     Re: DAB congestion due to urgent DMA?

Hans Eklund (SWEDEN)

Message: 53584    Yes BF537 based custom platform based upon the stamp board design.

 

We are lucky though, our final design will use the Netchip NET2272 (as on usb-lan extender card). While doing the same test via that network, no PPI overflows occur at all, so i think the problem is isolated to the DAB. But i think it is an interesting problem that the MAC could be the source of some PPI overflow cases people are experiencing, since many rely on it for devloping, mounting resources or having background networked applications or servers.

 

/Hans

QuoteReplyEditDelete

 

 

2008-04-03 03:44:09     Re: DAB congestion due to urgent DMA?

Michael Hennerich (GERMANY)

Message: 53587    Hi Hans,

 

the scenario you describe sounds new to me.

We use CMOS camera sensors in IP streaming applications (EMAC), where PPI CLK is 24MHz and 48MHz (8-bit bus).

There can be concurrency issues between Core and DMA, (solved by setting CDPRIO), but so far I haven't  noticed issues  between PPI and EMAC DMA.

 

What is your PPI width?

 

-Michael

QuoteReplyEditDelete

 

 

2008-04-03 04:48:44     Re: DAB congestion due to urgent DMA?

Hans Eklund (SWEDEN)

Message: 53596    Hi Michael.

 

16-bit width, we started out at 6Mhz PPI and experienced no trouble, raising it ot 24 Mhz produced some unexplaned PPI FIFO overflow errors. Moving to USB LAN adapter and 24 Mhz clock - no errors once again. Since PPI is externally clocked wouldnt we like to have close to exclusive access to it while sampling incomming data?

 

Video servers is a case i was thinking about how they may suffer. Could it be that in your implementation no heavy ethernet traffic is active during the frame beeing transfered from CMOS to SDRAM? If you ever get the chance to do an experiment, enable PPI error irq in the driver to print on ppi status FIFO overflow and flood ping(sudo ping -f IP) your blackfin board. What happens? For us it was vivid.. from a few, but disturbing errors every 5-10 frame to errors all the time while flooding.

 

Just a thought here, we sometimes connect our cards to our big office network and there are probably loads of broadcast traffic triggering this. On a quiet and nice lab network via a dedicated switch, this problem would not happen. A flood ping should trigger it in any case. Outgoing UDP traffic(as on a video server) may not be as disturbing after all, since data will be sent whenever the bus is free and should not trigger urgent transfers.

 

thanks

 

/Hans

 

edit: clarify

QuoteReplyEditDelete

 

 

2008-04-07 21:28:23     Re: DAB congestion due to urgent DMA?

Frank Van Hooft (CANADA)

Message: 53778    I'm seeing a very similar problem, and I'm not convinced it's due to network traffic. I'm also reading data from the PPI port (16 bits at 12.5 MHz), and I have the CDPRIO bit set. If I have PPI data coming in, and I simply start up FFMPEG, that will often cause a PPI FIFO overflow. My application doesn't use the network and I can have the ethernet cable physically unplugged - the FIFO overflow still occurs.

 

I haven't isolated the cause yet, but I thought you may find this interesting.

QuoteReplyEditDelete

 

 

2008-04-08 04:10:03     Re: DAB congestion due to urgent DMA?

Hans Eklund (SWEDEN)

Message: 53815    Frank, PPI overflows/underruns can appear for several reasons as you know. I think our problem is quite and specific since the ppi overflows skyrockets with incomming ethernet data and disappears when moving to another chip that sits on another bus. What happens with your ppi if you do the test i proposed for michael to do? ping -f that is. Any more ppi overflows? would be great if someone else could verify this theory.

 

thanks

 

/Hans

Attachments

    Outcomes