• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 865 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.

TMS570LS3137: POM (Parameter Overlay Module) clock cylces for redirected read

Michael Riedel1
Prodigy 70 points

Part Number: TMS570LS3137

Hello everyone,

in my current project we are using the Parameter Overlay Module to switch between dedicated ROM and RAM sections for calibration purpose. At the moment we are facing some CPU load problem. So, we have to analyze optimization possibilities. For this, could you please provide me some information about the required clock cycles when using POM for the following usecases?:

Usecase 1: POM disabled; Direct read from ROM address

Usecase 2: POM enabled; ROM address redirect to RAM; Read from redirected ROM address (RAM)

Thank you very much for you support!

With best regards

Michael

  • 0
    TI__Mastermind 49120 points

    Hi Michael,

    Please note that the purpose of POM is not to speed up code execution by substituting Flash (ROM) accesses with RAM accesses. Rather it is to help with calibration of control algorithms where you can use POM to update "constants" that would normally be in Flash. This allows you to "tune" control algorithms without having to erase and reprogram Flash memory each time you need to change a constant value.

    See comments for your questions below.

    Use case 1: POM disabled; Direct read from ROM address

    >> This depends on whether the address being read from is already fetched into the flash module pipeline. If so, then it just takes a single CPU cycle to read this address. If not, then the number of wait states (additional CPU cycles) is specified in the datasheet and depends on the CPU operating frequency.

    Use case 2: POM enabled; ROM address redirect to RAM; Read from redirected ROM address (RAM)

    >> Once POM is enabled, any access to a Flash (ROM) address within the region defined in the POM causes the access to be diverted to the POM. POM is a bus master on the main interconnect and initiates a read from the overlay memory. This memory can either be an on-chip SRAM or an off-chip memory connected via EMIF. This is why the number of cycles it takes for a POM access are not fixed. There is a 32-cycle timeout on a POM access.

    Unfortunately we do not have the information about the number of cycles it takes for POM to read from internal RAM. The access path is shown in the figure above (pasted from the TRM). This shows only the command path. The response path travels the same hierarchy to complete the round-trip for a read from CPU RAM.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Prodigy 70 points

    Hi Sunil,

    thank you very much for your detailed response. In the project we are using the POM as follows...

    POMPROGSTART0: 0x002E0000;

    POMOVLSTAR0: 0x08020000;

    POMREGSIZE0: 12 (128KB)

    POM_GLBCTRL: 0x08000A05 (=disabled at startup), 0x08000A0A (=enabled during runtime)

    If POM is enabled, then the overall CPU load increases by 15% to 20% (depends on the software execution paths).

    Due to this, could you please provide me some more information about the required time for POM internal processing?

    My assumption is that after enabling POM module every RAM/ROM read access need to be checked by the POM module whether the address is in range or not.

    Is there kind of a formula or statement, like "...the POM enabling doubles the ROM read access time"?

    As you can see, I am very interested in this topic :)

    Thank you very much for your support!

    With best regards

    Michael

  • 0 in reply to Michael Riedel1
    TI__Mastermind 49120 points

    Michael,

    As mentioned, POM is not used to improve the CPU bandwidth. In fact it has the opposite effect on CPU performance, as you observed. We do not not have cycle time information for the POM use cases, as this is limited for use only during calibration.

    For improving CPU performance, you could consider running code directly from the tightly-coupled RAM.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Prodigy 70 points

    Sunil,

    thanks for your explenation. It's totally clear to me that using POM won't improve the performance :)

    We are using the POM module for calibration purpose. For this the calibration data will be switched during runtime between ROM (reference page) and RAM (working page). The RAM (working page) will be updated via XcpOnCan. After update completion the calibration page will switch from ROM (reference page) to RAM (working page) via XCP and POM module. This is a common usecase in the automotive industry for vehicle calibration and testing. The current size of calibration data is 128kB. So, half of the TCRAM (256kB) is used for calibration purpose.

    Regarding your suggestion. You are writing about linking code directly into RAM, right? Unfortunately, this is not our usecase. The application software is only reading constants from the calibration ROM. Those ROM area then is redirected to RAM by using POM module. So, we are able to test different calibration settings and switch back if something is not working well...

    Regarding the missing POM timing information, we would really need those information for further analysis.

    Do you see any chance to improve the performance for our usecase?

    Thanks again for your excellent support

    Best regards

    Michael

  • 0 in reply to Michael Riedel1
    TI__Mastermind 49120 points

    Michael,

    Unfortunately, it is not possible to get the requested POM access details within a reasonable amount of time.

    Regards, Sunil