High Res clock in C6747 Functional Simulator

Hi Peter --

I think the problem is that the simulator's timer input frequency does not match the hardware frequency.  The simulator's timer frequency can only be specified in terms of the CPU frequency and current value is50MHz (CPU / 6).  24/50 * 300,000,000 = 144,000,000 which is close to the number you are seeing.

You can update the simulator .xml file to change this frequency, but unfortunately, this frequency can only be specified in integer divisions of the CPU frequency.

From C:\Program Files\Texas Instruments\ccsv5.0.1.00036\ccsv5\ccs_base_5.0.1.00036\simulation\bin\configurations\tisim_c6747_ca.cfg

        // Clock divide ratio
        // The Clock freq is always fixed to be 50MHz.
        // Core is running at 300Mhz hence the divide ratio is 6
        CLOCK_DIVIDE 6;

        // Clock divide ratio
        // Uncomment this line to run the Timer at 25 MHz.
        // Core is running at 300Mhz hence the divide ratio is 12
        // CLOCK_DIVIDE 12

Looks like you can change this to 25MHz to be close to the h/w value which is 24MHz by updating the simulator .cfg file.

So, you can update this in the BIOS configuration with the following:

bios.CLK.INPUTCLK = 50.0000;

or, if you change the .cfg file to / 12 ...

bios.CLK.INPUTCLK = 25.0000;

I don't understand why these APIs return 0.  I'll try to look into this and respond later.

CLK_cpuCyclesPerHtime(); Yields 0 (!?)
CLK_cpuCyclesPerLtime(); Yields 0 (!?)

Regards,
-Karl-

Karl Wechsler said:

I don't understand why these APIs return 0.  I'll try to look into this and respond later.

CLK_cpuCyclesPerHtime(); Yields 0 (!?)
CLK_cpuCyclesPerLtime(); Yields 0 (!?)

 

Note that these functions have 'Float' return value.   So, maybe that's a clue to what is going on.

These functions are defined as follows.

/* ======= CLK_cpuCyclesPerHtime ========
 *  Returns ratio required to convert htime units to cpu cycles
 */
Float CLK_cpuCyclesPerHtime(Void)
{
    Float ratio;
    ratio = (Float)CLK_htimeMult / (Float)CLK_htimeDiv;
    return (ratio);
}

/* ======= CLK_cpuCyclesPerLtime ========
 *  Returns ratio required to convert ltime units to cpu cycles
 */
Float CLK_cpuCyclesPerLtime(Void)
{
    Float ratio;
    ratio = (Float)CLK_ltimeMult / (Float)CLK_ltimeDiv;
    return (ratio);
}

The Div and Mult variables are LgUns type. 

I put them in memory window and got the following values which make good sense.  I am using default clk example from BIOS and the evm6747 board.

Thanks for the hint about "float."  That was the problem with the CyclesPer<H|L>time().  Earlier I had been messing with the runtime printf support and disabled float.  Now I get the following values:

CLK_countspms();         Yields 300000 (seems okay based on 300MHz core clock)
CLK_getprd();            Yields 300000 (seems okay based on default setup of 1000 microsecond period)
CLK_cpuCyclesPerHtime(); Yields 1      (yay)
CLK_cpuCyclesPerLtime(); Yields 300000 (yay)

I was also able to adjust the "Input Clock" to 50MHz and get the expected results.  However, although I (sort of) understand what's going on, I'm worried about what will happen on real hardware.  To me it still seems odd that  CLK_cpuCyclesPerHtime() is not returning "6" (and other values adjusted by a factor of 6 accordingly) since I have configured the clock to be 50MHz.  When I get hardware will I need to change my tconf file back to the original values?

   Yes, I've verified that on actual hardware now I get something different (62360275):

    uint32_t tickStart = CLK_getltime();
    uint32_t clkStart = CLK_gethtime();
    TSK_sleep(100);
    uint32_t tickDelta = CLK_getltime() - tickStart;     // Yields 100 (seems okay)
    uint32_t clkDelta = CLK_gethtime() - clkStart;       // Yields 62360275(?!?!?)

However, the BIOS responses are all identical:

CLK_countspms();         Yields 300000 (seems okay based on 300MHz core clock)
CLK_getprd();            Yields 300000 (seems okay based on default setup of 1000 microsecond period)
CLK_cpuCyclesPerHtime(); Yields 1      (yay)
CLK_cpuCyclesPerLtime(); Yields 300000 (yay)

So my question remains that the BIOS API is giving me inconsistent results.

Again, here is my current tconf file:

utils.loadPlatform("ti.platforms.evm6747");

/* The following DSP/BIOS Features are enabled.  */
bios.enableRealTimeAnalysis(prog);
bios.enableRtdx(prog);
bios.enableTskManager(prog);

bios.RTDX.MODE = "Simulator";
bios.MEM.NOMEMORYHEAPS = 0;
bios.MEM.instance("IRAM").createHeap = 1;
bios.MEM.BIOSOBJSEG = prog.get("IRAM");
bios.MEM.MALLOCSEG = prog.get("IRAM");
bios.MEM.instance("IRAM").heapSize = 0x00010000;
bios.CLK.SPECIFYRATE = 0;
bios.CLK.SPECIFYRATE = 1;
bios.CLK.INPUTCLK = 50.0000;
// !GRAPHICAL_CONFIG_TOOL_SCRIPT_INSERT_POINT!

prog.gen();

Peter --

Unfortunately, you will need to change your .tcf for h/w vs simulator.  BIOS doesn't know the CPU or timer frequencies.  You configure this in the .tcf file as we've been discussing.

On the h/w, the CPU is 300MHz and the timer is 24MHz.

On the default simulator, the CPU is 300MHz and the timer is 50MHz.

You need to update your .tcf accordingly.

This number makes sense to me:  62360275

The CPU is running at 300MHz.  Your timer is running at 24MHz, but BIOS programmed the timer period register as if it were running at 50MHz.  So, BIOS put a 2x bigger number in the period register.  

24/50 * 300,000 ~= 625,000

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Thanks for your response and patience.  I think I haven’t been asking the right questions, but I’m still getting closer.  I of course understand that BIOS doesn’t know the clock frequencies, but I don’t know why it should need them.  The only reason it would need to know them is to time things against the “real world” and if there were more than one timer being used.

The BIOS documentation on this subject is a little light.  One problem here is that I was mostly reading SPRU423H 4.9 on this subject (particularly page 4-74) which led me to believe everything was done with one timer.  In this case, none of your comments make sense.  If the high resolution timer and low resolution timer are the same, then it should be impossible for CLK_getprd() to return anything but “the truth” and this value should matter.  Unfortunately SPRU423H only mentions “C6000” in general terms, and is misleading.  I believe SPRU403Q contains a little more detail. 

Is it correct that the C674x series follows the C64x+ model for the purposes of reading SPRU403Q?

Now I believe that on the C674x, two timers are used.  The core timer is used for the “high resolution” time and an external peripheral timer is used for the tick timer.  Is this correct?

Furthermore, I’m still confused by the usage of several fields.  In particular the following:

In SPRU403Q Pg 2-56 and 2-57:

Use high resolution time for internal timings. If this property is set to true, the high-resolution timer is used to monitor internal periods.  Otherwise the less intrusive, low-resolution timer is used.

This confused me because I have it selected, and it makes it sound like this will cause the high resolution (core counter) timer to count the ticks.  This is what led me to believe that a single timer was used for both the period and high resolution timing.  This is inconsistent with my findings.  What does this actually do?

Specify input clock rate. (C64x+ only) If this property is set to true, you can specify the Input frequency (INPUTCLK) property.  Otherwise, the default clock frequency is used. The default is dependant on the platform.

What does this do?  Based on your earlier comments, I now have no clue what this does.  In a detailed reading of the timer manual, it sounds like this sets the CLKSRC field in the TCR.  However, the two alternate clocks that can be selected aren’t specified here, the documentation refers me to the System manual.  In reading the system manual, (SPRUFK4D), I find Figure 6-1.  However, this diagram only shows a single clock source for the timers “AUXCLK.”  (Which is the 24 MHz clock as you mentioned).  However, what is the other alternate source?

All in all, I find that SPUR403Q says “dependent on the platform” a lot, and it has been very hard for me to figure out where this information resides.

Again, thanks for your help,

Peter

Perfect.  Okay, thanks much karl.

Peter