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.

EDMA poor performance L3/DDR OMAP-L138

Other Parts Discussed in Thread: OMAPL138

Hi All,

Note: We are using BIOS 5.33.05 / DSPLink 1.65.00.03 on the OMAP-L138 with Linux on the ARM Core.

Memory layout: Data/Program in DDR/L3 with L2/L1D/L1P caching enabled.

Clock Rate: DSP/ARM 456Mhz, eDMA 228Mhz

We are currently using the eDMA to ping-pong buffer and transport sets of data from the McASP FIFO into the internal L2 RAM. Furthermore, the eDMA is using Queue 0 along with TC0 which is set to a high priority in the SYSCFG module.

Now, we would like to further harness the eDMA power in order to reduce I/O constraints on our DSP. Therefore, we attempted to use another channel along with Queue 1 and TC1 for bulk data transfers from L2 into L3/DDR. However, it seems like the eDMA cannot guarantee our deadlines for transferring the bulk data into L3/DDR. Our deadline for the bulk transfer is 10msec for 12 kilobytes from L2 to either DDR or L3. Meaning we require ~9mbps throughput for the transfer which should be achievable given our clock rates.

If anyone could aid us in diagnosing this problem we would appreciate it

Thanks,

Arya B.

  • Hi,

    Please refer the OMAPL138 TRM section 18.2.14 & 18.2.11 for EDMA slow transfer issues,

    Also refer the OMAPL138 TRM section 18.4.3.5 for RDRATE register to increase the transfer speed,

    Are you using chaining configuration for your EDMA transfers?

    Try to configuring "early completion" & optimize your DBS size and DSTREGDEPTH (TR pipelining) and it is also configurable through CFGCHIP1 register.

    Did you configure the EDMA interrupts?

    Refer the old e2e post regarding EDMA slow transfers,

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/274777.aspx

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/47544.aspx

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/t/91086.aspx

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/249828.aspx

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/219010.aspx

  • Hi Arya,

    Thanks for your post.

    As per system priority considerations, it is highly recommended that a TC servicing audio data requests from serial ports should be configured at a higher priority as compared to TC service memory to memory (paging/bulk) transfer requests. Please refer section 18.2.14.1 in the omapl138 TRM as below:

    http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

    With the above strategy, it is obvious that, TC0 would set to high priority as you configure would meet real-time deadlines whereas, TC1 with lower system priority may not gurarantee in meeting your deadlines which is expected. Please look at the important note for omapl138 device as below:

    Note: On previous architectures, the EDMA3TC priority was controlled by the QUEPRI register in the EDMA3CC memory-map. However for this device, the priority control for the transfer controllers is controlled by the chip-level registers in the System Configuration Module.

    Also, there are other constraints will have the possibility of being locked out from accessing the EMIFA by a stream of higher priority requests. Therefore, care should be taken when issuing persistent requests to theEMIFA from a source such which is a high priority requester. Please check whether this case applicable to your design and for more details, please refer section 20.2.13.2 in the above omapl138 TRM.

    Thanks & regards,
    Sivaraj K

    -------------------------------------------------------------------------------------------------------
    Please click the Verify Answer button on this post if it answers your question.
    -------------------------------------------------------------------------------------------------------
  • Arya,

    Is this problem resolved? You were discussing similar issues on the TI-RTOS Forum after this thread, so if this is done, please post a simple summary of your solution or at least let us know to close this thread.

    Regards,
    RandyP