• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 4 answers
  • Subscribers 30 subscribers
  • Views 821 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.

TMS570LS1227: Effect of enabling MPU on processor loading

Steven Aris26
Prodigy 210 points
Part Number: TMS570LS1227

Please could someone let me know if enabling the MPU is expected to improve processor performance?

We have just found that disabling the MPU (with no other changes) on our TMS570LS1227 increases processor loading by about 7 to 10%.  As we're intending to use the MPU we're obviously quite happy that this appears to improve processor performance, but would like to understand why.

Any documentation we've found would seem to imply the MPU should have no impact on processor performance, but that is contrary to our experience.

Thanks,

Steve

  • 0
    TI__Guru**** 196276 points

    Hello Steve,

    Memory region change from MPU_STRONGLYORDERED_SHAREABLE to NORMAL or DEVICE will accelerate the write speed. But the DMA speed stays the same.   

    A write to Strongly-ordered memory is only considered complete when the transaction is acknowledged as complete by the memory or peripheral device. So it is slower to write to strongly-ordered memory.

    Do you write data to external memory attached to EMIF? The SDRAM and external async memory (SRAM) should be configured as device mode rather than NORMAL mode.

  • 0 in reply to QJ Wang
    Prodigy 210 points

    Thanks QJ,

    Apologies for my slow response.

    Our MPU configuration does set the peripherals frames (0xFC000000 -- 0xFFF80000) to DEVICE.  Are these regions STRONGLYORDERED by default?

    I can't seem to find any details on this, other than a sentence in the ARM Architecture Reference Manual that says 'memory-mapped registers must be mapped to STRONGLYORDERED or DEVICE memory'.

    Thanks again and best regards,

    Steve

  • 0 in reply to Steven Aris26
    TI__Guru**** 196276 points

    Hi Steve,

    Device and strongly-ordered type data accesses are normally used for peripherals. Instructions cannot be executed from regions with Device or Strongly-Ordered memory type attributes.

  • 0 in reply to QJ Wang
    Prodigy 210 points

    Thanks QJ,

    Understood, however, unless the peripheral regions are configured for strongly-ordered access by default, or there is a performance hit in having the MPU disabled, I'm not sure I can see where the performance difference is coming from.

    I forgot to mention last time that we are not using any external memory, so there are no accesses via the EMIF, which unfortunately rules that out as a possibility.

    Our MPU is configured as below - all RAM and flash regions (including the RAM ECC region) are configured for normal data accesses, the peripheral areas and CRC area are configured for device type accesses and the system modules regions is configured for strongly-ordered accesses...and for some reason this configuration gives us a performance improvement of between 7 and 10% over the default (MPU disabled) settings!

    The first column in the table is the MPU region and if I remember correctly our configuration is loosely based on application report SPNA177 (MPU Configuration), with a primary aim of catching stack overflows.

    0

    		 0x00000000 -- 0x0013FFFF Normal, Read\Write (Program Flash)
    1 0xF0000000 -- 0xF07FFFFF Normal, Read\Write, Execute never (Data Flash)
    2 0x08000000 -- 0x0802FFFF Normal, Read\Write (RAM)
    3 0x08400000 -- 0x0842FFFF Normal, Read\Write, Execute never (RAM ECC)
    4 0xFC000000 -- 0xFF7FFFFF Device, Read\Write, Execute never (Peripherals Frame 1 & 2 - also includes CRC and reserved area)
    5 0x08000020 -- 0x0800003F No access, Execute never (User stack guard region)
    6 0x08000820 -- 0x0800083F No access, Execute never (SVC stack guard region)
    7 0x08001020 -- 0x0800103F No access, Execute never (FIQ stack guard region)
    8 0x08001820 -- 0x0800183F No access, Execute never (IRQ stack guard region)
    9 0x08002820 -- 0x0800283F No access, Execute never (Abort stack guard region)
    10 0x08002C20 -- 0x08002C3F No access, Execute never (Undef stack guard region)
    11 0xFFF80000 -- 0xFFFFFFFF Strongly ordered, Privileged Read\Write, Execute never (System modules)

    Thanks and best regards,

    Steve

  • 0 in reply to Steven Aris26
    TI__Mastermind 49120 points

    Steve,

    The Cortex R4F TRM's Memory Protection Unit (MPU) chapter has a default memory map and attributes table. See attached.

    Note that you are configuring memories (module registers) in the range 0xFC000000 -- 0xFF7FFFFF as "device" type. These memories would have been strongly ordered with the MPU disabled. Configuring them as device type enables buffering within the CPU for write accesses, thereby yielding an improvement in the CPU bandwidth.

    Another observation: as per your MPU configuration information, there are several peripheral modules that are not mapped to any memory region. This would cause an error on a read or write access to these peripherals. For example, MibADC1 at 0xFFF7C000 are not mapped at all. It is okay if you are not using these modules. Please check if the end-address for region 4 should be 0xFFF7FFFF instead of 0xFF7FFFFF.

    Regards,

    Sunil

  • 0 in reply to Sunil Oak
    Prodigy 210 points

    Many thanks Sunil.

    That would explain the performance difference.

    I've now found the section in the Cortex-R4 TRM (I was looking in all the TRM's apart from this one!!) and I think it indicates that for our use, configuring the peripheral registers as 'device' type memory is okay, but could you just confirm, in case I've misunderstood, that a read from 'device' type memory will only occur after any pending writes in the write buffer have completed?  So any reads from device memory will always be coherent with preceding writes?

    And you were correct about our addresses for the peripheral register region - I didn't read our setup properly as we have that region divided into sub-regions so that it actually covers 0xFC000000 -- 0xFCFFFFFF and 0xFE000000 -- 0xFFFFFFFF.

    Best regards,

    Steve

  • 0 in reply to Steven Aris26
    TI__Mastermind 49120 points

    Hi Steve,

    Yes, a read from any device type region forces the write buffer to be flushed (pending writes to be completed). You could also force the CPU write buffer to be flushed by explicitly executing a data synchronization barrier (DSB) instruction in assembly.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Prodigy 210 points

    Hi Sunil,

    Thanks for your help.

    I think we now understand the reason for our performance improvement...and that, for our system at least, it is a safe change to the default settings.

    Best regards,

    Steve