• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 350 subscribers
  • Views 2943 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex M3, PrimeCell uDMAC bus arbitration

acoad

Hi,

This is in the context of the Cortex-M3 and PrimeCell uDMAC as implemented in the Texas Instruments CC2640R2F Bluetooth controller (I have gone through the TI support forums for this question but it seems that this is fully within the ARM IP domain). 

From reading the ARM documents, I see that the MCU core access to memory and uDMAC access to memory and peripherals all occur on the same (system) bus and that the MCU core has priority over the uDMAC...

Is there any provision in this architecture for the MCU core to yield to the uDMAC every, say, 16 bus cycles? I cannot see any mention of such in the documentation so I am assuming that there is not. Can anyone kindly confirm?

Regards,

ac

Parents
  • +1

    Although the Cortex-M3 and the Primecell uDMAC modules are ARM IP, it would be the unknown TI logic is connecting these 2 AHB-lite masters through to your memory that would determine which master has access to memory at any time.

    It is likely to be some sort of AHB-lite BusMatrix, possibly also ARM IP, possibly TI's own design, and this will implement arbitration logic to work out which master access is stalled, and which access gets through to memory, and by the sounds of your description this is a simple fixed priority decision with priority given to the Cortex-M3.

    If the connection is that simple, the Cortex-M3 system access will always block a coincident uDMA accesses, so the question still needs to be answered by TI, do they have something in the connecting logic to somehow actively change priorities to avoid always starving the uDMA.

    However the Cortex-M3 is hopefully using its ICODE and DCODE interfaces for the majority of accesses, and only using the SYSTEM interface for accesses outside the CODE space, so that should reduce contention on the SYSTEM address space with the uDMA master. I don't know how much control you have over the address space the Cortex-M3 is operating in.

    There isn't anything implemented in the Cortex-M3 itself to get it to NOT use the system bus every X cycles if that is the address space the software is operating from, as that would be making the M3 less efficient, so this would need to be something implemented by the system architecture. The Cortex-M3 and the uDMA will both request to use the system bus when they need to.

    Sorry, you do need to ask TI about the system connecting these 2 ARM IP masters, or to determine why the Cortex-M3's SYSTEM interface is being used so heavily in the CC2640R2F Bluetooth controller  This isn't something I know about.

    Colin..

Reply
  • +1

    Although the Cortex-M3 and the Primecell uDMAC modules are ARM IP, it would be the unknown TI logic is connecting these 2 AHB-lite masters through to your memory that would determine which master has access to memory at any time.

    It is likely to be some sort of AHB-lite BusMatrix, possibly also ARM IP, possibly TI's own design, and this will implement arbitration logic to work out which master access is stalled, and which access gets through to memory, and by the sounds of your description this is a simple fixed priority decision with priority given to the Cortex-M3.

    If the connection is that simple, the Cortex-M3 system access will always block a coincident uDMA accesses, so the question still needs to be answered by TI, do they have something in the connecting logic to somehow actively change priorities to avoid always starving the uDMA.

    However the Cortex-M3 is hopefully using its ICODE and DCODE interfaces for the majority of accesses, and only using the SYSTEM interface for accesses outside the CODE space, so that should reduce contention on the SYSTEM address space with the uDMA master. I don't know how much control you have over the address space the Cortex-M3 is operating in.

    There isn't anything implemented in the Cortex-M3 itself to get it to NOT use the system bus every X cycles if that is the address space the software is operating from, as that would be making the M3 less efficient, so this would need to be something implemented by the system architecture. The Cortex-M3 and the uDMA will both request to use the system bus when they need to.

    Sorry, you do need to ask TI about the system connecting these 2 ARM IP masters, or to determine why the Cortex-M3's SYSTEM interface is being used so heavily in the CC2640R2F Bluetooth controller  This isn't something I know about.

    Colin..

Children