• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 445 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

L3 Interconnect Prioritization / Arbitration

Brad Griffis
Guru*** 125430 points

Can someone please provide some details as to how prioritization / arbitration works on the L3 interconnect?  I went and looked at the SonicsMX data sheet and it gives some high level bullets talking about various prioritization capabilities, but I cannot find any data from Sonics or TI detailing how to configure those priorities.  Or even if the priorities are fixed we need to know which initiators have what priorities.

Thanks,
Brad

 

  • 0
    TI__Mastermind 30150 points

    Hi Brad,

    I am as well interested on the L3 interconnect priorities/arbitration for OMAP35x/DM37x. Did you manage to find some documentation on this?

    Here is what I found in the TRM SPRUGN4N  so far:
    - Section 9.3.2.3 on the region and firewall priority but the priority for the different master and slave on the interconnect is not described.
    - For SMS/SDCR as destination it seems that priority can be given depending on the requestor (CAM, MPU, sDMA..etc). See section 10.2.4.1.1.

    Where you able to find more info or other docs?

    Thanks and best regards,

    Anthony

  • 0 in reply to AnBer
    TI__Guru*** 125430 points

    Ah hah!!! Yes, I think Section 10.2.4.1.1 (Memory Access Scheduling) is part of the info I've been looking for!!!  You just broke this thing wide open!!!

    Clearly the prioritization of the SDRC is the most important aspect.  I think this documentation is pretty clear.  Section 10.2.4.1.3.1 "Interclass Arbitration" clearly states that Class 0 (Camera/Display) always gets highest priority.  That part of it is non-programmable.  However, there are then some knobs to twiddle to weight priorities between Class 1 and Class 2.  Finally Section 10.2.4.1.3 "Internal Class Arbitration" discusses how to prioritize within a given class.

    It looks to me like the only other place where multiple outstanding requests/threads can be support is by the L4 Interconnect.  In Section 9.3 "L4 Interconnects" makes the following note:

    "L4_CORE has four threads (maximum), L4_PER has four threads (maximum), and L4_EMU and L4_WKUP have one thread."

    There's also the following bullet:

    "Nonblocking with fair arbitration between threads"

    So it would seem to me that the L4_CORE and L4_PER support 4 threads, and that there is a round-robin treatment to give each initiator a turn.

    Based on the internal spec I sent you it appears that all other peripherals support only a single thread, so for everything else it will simply be "first come, first serve".