• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 405 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

OMAPL138 - DDR2 FIFO Queue Questions

Michael Questo
Expert 6000 points

Hey L138 Champs,

We'd like to know how deep the FIFO queues are for the SCR on the side of the requested hardware, for example we are accessing DDR2 from both the DSP and the ARM9 core, continuously.

To give you some background we have a device continuously accessing this memory so it is arbitrating very quickly. We are experiencing performance problems with execution speeds.

 1. Is the queue depth infinite?

2. Are there any tools that allow monitoring the performance/usage/depth of these queues?

3. How much latency is involved in pulling memory?


 

Thanks,

 

  • 0
    TI__Expert 6000 points

    Found the answer to Question #1 in section 15.2.6 of the TRM (http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf)

  • 0
    TI__Mastermind 23525 points

     

    For #2, there are some counters which can be configured to count the number of clock cycles that the Command/Write/Read FIFO is full.  Take a look at the Performance Counter Config Register.


    Not sure what you are asking for #3.


    Regards,

    Travis

  • 0 in reply to tscheck
    TI__Guru* 78325 points

    For #3, we don't have any chip latency data. This is an old device, besides usually chip latency data is typically good to quantify best case scenarios (standalone traffic from one master to external memory), but it is difficult to communicate/quantify for complex system or multi-master use-cases, unless there is a very specific use-case you go after to do analysis. 

    I am sure you / customer have seen the OMAPL1x SoC Arch & Tput wiki 

    http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_SOC_Architecture_and_Throughput_Overview

    This has some good concepts on typical system tuning knobs and how arbitration works. 

    If they are seeing issues with DDR bandwidth for a particular master, usually the golden rules to always follow

    1) Ensure that the master that is the most important in the system or masters that have real time need (e.g, EDMA-TC servicing audio via McASP/McBSP tx/rx - where not keeping up real-time deadline will imply audible audio glitches or VPIF/LCD, where lack of proper servicing will cause visual artifacts etc), are at the highest priority.

    2) Make sure that the DDR2.BPRIO register is set to a value less than the default of 0xFF, usually 0x20 is a good value to start with 

    3) If the issue is due to multiple masters accessing external memory, try to break the access requests of the masters that are non real time (EDMA's doing paging, storage peripherals like SATA, MMC/SD etc) to smaller chunks, to allow better interleaving and arbitration to kick in.

    Hope this helps some.

    Regards

    Mukul