This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Video data transfer by GPMC bus of OMAP3530

Other Parts Discussed in Thread: OMAP3530

Hi:

I have a new project that need LCD controller(FPGA) and OMAP3530 with GPMC bus.
In this project, we need two LCD displays, one is show control information on 21" LCD monitor(DVI I/F, named LCD-A) by LCD controller of OMAP3530.
Other one is 10" ~ 28" options LCD module(different resolution, VGA ~ 1080p60 maximum, named LCD-B) and driving by FPGA.

My question is, when the OMAP3530 decode video stream(e.q MPEG4/H.264 file from MMC) and output video data to FPGA to display on LCD-B via GPMC bus,
can it reach real time transfer(e.q 720p 30fps)? How maximum transfer speed can be reach?

Thank you.

Sincerely,

Marcs

  • Hello Marcs,

    You should be good to go with 720p @30fps.  The measured throughput to a PSRAM was a little over 103MB/sec.

  • Dear Jeff:

    Thank you for your help.

     

    Marcs

  • Hi Jeff and Marcs,

    I'm not completely sure, but I seem to remember that I have had the GPMC giving an effective throughput of ~150MB using DMA and 16 bit synchronous burst mode some time back? @Jeff: How did you measure the 103MB/s?

    In synchronous burst mode theroretical maximum is: 100MHz@16bit= 200MB/s minus address setup and interburst cycles. Assuming address/data muxed mode I would assume a maximum of 4 "missed" clocks (to make calculations easy) pr 16 burst clocks clocking actual data => An actual throughput of 160MB/s. In non address/data muxed mode the number could be even higher?

    All this being said. I'm not so sure it will be 100% trivial to get sustained real time data to the FPGA for a 720p video stream over the GPMC. The 720p stream at 24 bit would require (1280*720*30*3=) 83MB/s continuously at the same time as OMAP is decoding and up scaling the video. All in all a pretty touch process which might be just at/above the limitation of the chips capabilities. You as well would need to have at least some memory within the FPGA in order to keep a few/several lines of video data, since there is no way of forcing the GPMC to stream data in the same was as i.e. the LCD controller can do. The best way would be to use a highly-prioritized DMA channel moving the data from DDR to GPMC...

    One complete angle not covered by this is the overall throughput of the SDRC and the decoding of the video simultaneously by driving two high-res displays and running code on the ARM/DSP - all from SDRC. This is pretty fast getting a bottleneck for a task like this as well...

    All in All: I think the task is *very* tough, but most likely not impossible in case everything is fine tuned/considered in detail, but it definitely not 100% trivial :-)

    Best regards - Good luck
      Søren