• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 3076 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.

Confirming ARM/DSP clock values on AM572x

Caleb Pentecost
Prodigy 150 points
Other Parts Discussed in Thread: SYSBIOS

Howdy,

I am currently working with a Sitara AM572x series processor, and am having some confusion regarding the operating clock frequencies of the A15_0, A15_1, DSP1, and DSP2 cores. This leads me to a series of questions:

My system is using an input clock frequency of 20MHz, and I am building/configuring XDC sysbios onto this system. In the Platform.xdc file, I have the following (among other things) defined:

/* ARM */
readonly config xdc.platform.IExeContext.Cpu ARM = {
    id:             "3",
    clockRate:      650.0,  /* Typically set by the HLOS */
    catalogName:    "ti.catalog.arm.cortexa15",
    deviceName:     "Vayu",
    revision:       "1.0"
};
readonly config xdc.platform.IExeContext.Cpu DSP = {
    id:             "0",
    clockRate:      600,
    catalogName:    "ti.catalog.c6000",
    deviceName:     "DRA7XX",
    revision:       "1.0",
};

When executing my program, calling BIOS_getCpuFreq() on ARM0 yields the correct value of 650MHz. However, when looking at the DPLL registers for DPLL_MPU (which sources the clock frequencies for both of the ARM cores) the multiply value is 150 and the divide value is 4. This would result in a DPLL output of 750 MHz. Which value is correct? How can I verify the operating frequency of the ARM cores?

My question is repeated for the DSP cores, as well. I was able to test the operating frequency of the DSP cores, and it appeared that the operating frequency of those cores would NOT change when the platform.xdc definitions changed. Manually changing the multiply and divide values, however, allowed me to change the DSP operating frequency. Why did the platform.xdc file not correctly change the clock frequency?

Thank you, in advance, for your assistance.

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the RTOS team to comment.
  • 0
    TI__Guru** 116170 points

    Hi Caleb,

    TI RTOS does not configure the device clocks and has no mchanism to determine the device clocks rates. BIOS relies on the user to provide the correct clock settings. When you create a BIOS project with a configuration file with AM57xx platform specification, it will pick up the default platform definition from sysbios package and will use the clock settings from the platform definition.

    You can update these settings using the following code in the configuration file.

    var BIOS = xdc.useModule('ti.sysbios.BIOS');

    BIOS.cpuFreq.lo = 1500000000; // Set CPU clock to 1.5 GHz  (just an example)

    For CCS use case:

    The device clock or DPLL configuration is done by the GEL files that you use in CCS or the board library that you may be using from the Processor SDK RTOS package.  You can see the ARM clock configuration in the GEL file

    There are 3 Operating points (OPP) defined in the GEL files as described below:

    By default the GEL uses OPP_NOM which sets the ARM at 1000Mhz and DSP at 600 Mhz (May vary based on which version of the GEL you are using.)

    For Processor SDK RTOS usage:

    If you are using the Board library software for initializing the clocks, then you can see the PLL configuration setting in the function Board_PLLInit that can be located in the board library under

    pdk_am57xx_1_0_1\packages\ti\board\src\evmAM572x

    Just make sure that your BIOS.cpufreq matches with which ever software you use for configuring the DPLL.

     To physically verify the clock configuration, you will need to track down test points on your board where either the CPU clock or one of the derived system clocks are brought out to a test point. If you specify which board you are using we can provide information if there are any test points for you to measure these clocks.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 150 points

    Howdy,

    Thanks for the response! You've helped me gain a little more insight, but I have a few more comments/questions for you...

    The system is currently performing standalone boot, so I do not think that there are any GEL files involved with setting up the clock frequencies. Because of this, I am presuming that the boot code will set the DPLL_MPU M and N values to some defaults, and it is up to the program itself to change these to the appropriate values? I suppose that my understanding is this:

    1. The device boots, using the input clock (20MHz) and some default DPLL_MPU multiply/divide values (150/4) to generate the ARM clock frequency (750MHz)
    2. XDC configuration begins, using the provided clock value (650MHz) to configure internal clocks, networking, etc. under the assumption that the system is running at that provided clock frequency.

    Is my understanding here correct?

    If that is the case, I either need to reconfigure my XDC configuration to have a clock value of 750MHz (to match the real clock frequency), or in my main() function I need to manually reconfigure the DPLL_MPU register to force the device cores to run at the slower speed (to match the XDC configuration). Is this correct? Is there a more elegant way of achieving this, other than what I have described?

    I do not believe that I am using the Board Library software. And while I am using CCS for debugging (I have disabled the GEL file's clock configuration code, for when OnConnect() is called) I am otherwise not using its configuration features.  Sorry for the confusion!

    Additionally, this chip is on a custom CPU board and I do not believe that there are any ARM clock frequency probe points (or deriviative points) available to me. I imagine that I need to set up some sort of NOP counter to determine just how many instructions can be accomplished in a given amount of time, and use that to determine the real clock speed.

    Thank you for your help!

  • 0 in reply to Caleb Pentecost
    TI__Guru** 116170 points
    Caleb,

    Yes, your understanding is correct. For standalone boot, the bootloader will perform the necessary device initialization of PLL, PSC etc based on the boot mode you are using. You can then pass on the device configuration information to the BIOS so that it will use those settings when it computes time stamps or when timers are run in BIOS.

    Yes, your second statement is also correct. You need to either reconfigure your XDC configuration to have clockrate value at 750Mhz or choose to lower the CPU clock by modifying the DPLL to match the XDC setting.

    Bootloader, GEL and board library all perform similar functions to perform device initialization so you can use either one of them to determine your system clocks and then pass the information to BIOS to consume.

    Regards,
    Rahul