Urgent Help Required: CLK_gethtime

Goku,

On 6/27/08, Goku wrote:
>
> Hello Mike/ Jeff ,
>
> I did manage to configure the timer, but the profiler clock cycles never
> matches with that of the TIMER_count from the csl api, there is a huge
> amount of difference:
>
> I have configured the timer as follows : but not sure whether it is
> configured properly, don't know whether it is overflowing, since the cycle
> count always less than the PRD set value i.e 0xFFFFFFFF, i am not able to
> tell , regarding the increment of timer : I have calculated it like this :
> DSK 6416 has 1Ghz Processor, hence the 1 CPU clock period= 10exp -9 > 1/1Ghz.
> Timer Input Clock = 8* ( 1/1Ghz) ;
> Timer Period= 0xFFFFFFFF
> Timer Period for Timer1 Interrupt is = 0xFFFFFFFF * (1/1Ghz) * 8= 34.5 Sec,
> Here i am not able to Configure HW_15 for ISR, which could call .
I suggest that you crawl, walk, and then run wrt to profiling. I do not
have time to analyze everything for you, but the following steps should
help.
1. Get a basic understanding using a simple program. From main call a
function with a processing loop and a large count [something like a 1,000
cycle loop with a count of 100,000. I suggest that you run the program once
before measurements and then take each measurement twice - if you get a
large difference, take it 3 times.
2. In main, time the loop from before the func call until after using the
timer. Don't worry about overflow yet, get the timer correct first. The
timer is not cycle accurate, but it will be very close [+/- a few cycles].
3. From main, time the loop using the profile counter. This should be the
actual number of cycles [it will include some overhead] +/- 1.
4. From main, set a GPIO pin before the func call and clear it after.
Measure this on a scope.
5. All three of the above methods should be very close. Once they are, you
should be ready to take some 'real' measurements [if you use the timer,
lengthen the loop to overflow and debug the overflow detection].
Actually the code runs for about 3-4 minutes before it could print the Timer
> Counts, the TImer is started when the decoding starts in the code, and stops
> at the end of decoding.
>
> And the difference is printed out, which states the no of clock cycles
> used.
>
> Other Aspects : Config File is as follows.
>
> L2 Cache : Not Configured, ISRAM is configured with the L2 enabling. It
> says in the caching document that it is not preferred to run the code
> without L2,i am not sure about the L1 on chip, by default it is enabled ,
> could anyone tell me how much difference a L1 miss and a hit can cause to
> the cpu cycles consumed.
This will vary with program. For a simple or sequential program:
1. Reset/flush cache
2. Load, run program [= L1 'is empty']
3. Restart, run program [= L1 'has repeatable cached entries']
4. Restart, run program [= L1 'has repeatable cached entries']. Should be
similar to previous.
5. Restart, run program [= L1 'has repeatable cached entries']. Should be
similar to previous.

If you want the details, goto spru190 and it will point you to the doc on
c64 cache/internal memory.

I am trying to find out the proper values for my application ( CPU cycles )
> , If i manage to get the cycle count not varying too much then i could do
> some more experiments.
FYI - Some applications 'vary all over the place' in cycle count. The 'GPIO
method' is the 100% accurate [with almost no overhead] realtime measurement.

THis is an additional .cdb file since the heap required to run the
> application is more than ISRAM (1MB)
> SECTIONS {
> .bss: fill=0 {
> *(.bss)
> . += 0x4;
> } > ISRAM
>
> .far: {} > SDRAM
>
> .cinit: {} > ISRAM
>
> .pinit: {} > ISRAM
>
> .data: {} > ISRAM
>
> .switch: {} > ISRAM
>
> .cio: {} > ISRAM
>
> .text: {} > SDRAM
> .const: {} > SDRAM
> }
> When i mapped Stack on the SDRAM i am getting around 1420057808 * 8 CPU
> cycles, but when i map it against ISRAM i am getting more cycle count from
> the timer 3853073033 *8 ,both of them can't be compared to the profiler
> clock, does the profiler clock give out exact number of cpu cycles elapsed
> for running the entire program.? could you let me know,
The profiler clock measures from 'run' to 'halt' by reading a hardware
counter [I don't remember if it is 32 or 64 bits - I typically only use it
for single function measurements].

mikedunn

Initilization of Timer is done in this way, could you please let me know
> whether it is correct:
> Timer_start(hTImer1)
> start_time= Timer_getcount(hTimer1)
>
> Mp3 Decoding code
>
> stop_time= TImer_getcount(hTimer1)
> and the difference is printed out.
>
> In the GUI .cdb file, mentioned that the Input to the Timer is CPU/8 rate,
> with reset before the start. and PRD set to max 0xFFFFFFFF.
>
> Do i have to tag HW_15 for any isr() ? i cant do it since in my code
> composer such option is disabled.
>
> Does the timer give out right values since the Interrupt is driven once in
> 34.5 Secs. Please explain since i am stuck at this point and i want to
> clarify why the variation in clock cycles is happening, and which procedure
> is correct to get the timer working and to get the same amount of clock
> cycles all the times.
>
> Regards,
> Goku
>
> On Thu, Jun 26, 2008 at 7:53 PM, Michael Dunn
> wrote:
>
>> Goku,
>>
>> On 6/26/08, Goku wrote:
>>>
>>> Hello,
>>>
>>> I had configured the Timer as per Dunn, with the following
>>> configurations, and i am experiencing huge amount of clock cycle differences
>>> for the execution of the same code.
>>>
>>> Please Could any one of you explain the same,
>>>
>>> Code : MP3 Player.
>>>
>>> Result :
>>> Iterations = 1
>>> -- Target Duration = 1417161654 X 8 Clock Cycles - > CPU/8 config for
>>> the timer
>>>
>>> Iterations = 2
>>> -- Target Duration = 815201933 X 8 Clock Cycles - > CPU/8 config for
>>> the timer
>>>
>>>
>>> The same code was rerun after a successful reboot of the DSK 6416 and
>>> then i got the result for Iteration 2 which is almost half of the cycles
>>> taken for Iteration 1.
>>> The very first pass will have nothing in L1 cache and you will get 100%
>> misses. Passes 2 and later should have similar times [assuming similat code
>> flow].
>>
>> When i was using the debugger CCS Singles step i could see that the
>>> timer was overflowing in the timer register, even though i had set values
>>> set for PRD : FFFFFFFF , CNT -> Start with a Reset, Clk-: Tick= 1000
>>> Microseconds/Int, HWi_14 configured for Timer 0 , i could understand this
>>> behaviour .
>>> The timer knows nothing about the CPU state and will not give reliable
>> numbers when you halt the DSP. If you want to manually profile a function,
>> use the 'profile clock' in CCS. It will update when you single step.
>>
>> mikedunn
>>
>> Can anyone pls let me know why there is a huge variation in the clock
>>> cycles, all of my code resides in the SD RAM, and HWINIT_VEC are residing in
>>> the Internal memory.
>>>
>>> Regards,
>>> Goku
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 26, 2008 at 12:19 PM, Jeff Brower
>>> wrote:
>>>
>>>> Goku-
>>>>
>>>>
>>>> I have included rts6400.lib, but it is not defined in it, am using CCS
>>>> 3.3 Version, still getting the same error ," not able to resolve the symbol
>>>> definition" .Could you let me know the details pls.
>>>>
>>>>
>>>> _CLK_gethtime is defined in bios.a64, or similar depending on the DSP
>>>> type. I think it gets resolved to CLK_F_gethtime (function defined in asm
>>>> code). bios.a64 file is not an rtdx lib file; ignore my previous comment,
>>>>
>>>> Mike and Richard's suggestions about simpler ways to benchmark and
>>>> profile code are accurate and useful. You should try those. If for some
>>>> reason you still want to use _CLK_gethtime, then you have to use it together
>>>> with _CLK_getltime and also have to deal with issues of timer wrap-around
>>>> and interrupt enable/disable for _getltime. This doc has a good
>>>> explanation:
>>>>
>>>> http://focus.ti.com/lit/an/spra829/spra829.pdf
>>>>
>>>> -Jeff
>>>>
>>>>
>>>> On Tue, Jun 24, 2008 at 5:21 PM, Jeff Brower
>>>> wrote:
>>>>>
>>>>> Goku-
>>>>>
>>>>> Since i am benchmarking different applications which are ported from
>>>>> linux, the linking is done with a makefile which has a huge code base, am
>>>>> using cygwin and CCS compiler, but not the IDE, target is connected to a
>>>>> different machine which has the CCS IDE, hence here i cant use the GUI
>>>>> interface, i dont know how could i use Clk_gethtime without the CCS IDE GUI
>>>>> Bios Start, could you pls let me know.
>>>>>
>>>>>
>>>>> CLK_gethtime should be in the basic run-time library, rts64xx.lib (not
>>>>> sure of that correct name, but look for rts64-something).
>>>>>
>>>>>
>>>>> Error: _CLK_gethtime undefined symbol.
>>>>>
>>>>> I could see that Clk_gethtime library is missing , if i add the
>>>>> libraries like bios.a64 and others , they tend to say that there are many
>>>>> other symbols which are not defined.
>>>>>
>>>>>
>>>>> bios.a64 sounds to me like an RTDX library... nothing to do with CLK_xx
>>>>> functions.
>>>>>
>>>>> TI's code-gen tools for Linux are new and not widely used. I would
>>>>> suggest that you build using standard CCS v3.3 on a Win machine, and test
>>>>> that output code first. Since you have a "huge" code base, it's a good idea
>>>>> to eliminate any possible build error, library version, link error, etc.
>>>>>
>>>>> Think about it this way -- TI didn't have Linux based code-gen tools
>>>>> until recently (last couple of years). So that means since 1996, when they
>>>>> acquired GoDSP (Code Composer), they've been pouring manpower and millions
>>>>> into Win code-gen tools, not Linux. Which one do you think is more reliable
>>>>> and widely used?
>>>>>
>>>>> -Jeff
>>>>>
>>>>>
>>>>> On Tue, Jun 24, 2008 at 2:21 AM, Richard Williams <
>>>>> r...@lewiscounty.com> wrote:
>>>>>>
>>>>>> ittiam,
>>>>>>
>>>>>> from your description, it is rather obvious that some libraries are
>>>>>> missing (assuming that the
>>>>>> compile operations worked with no errors.)
>>>>>>
>>>>>> If you would post the names of the functions that are not found by the
>>>>>> linker, we could possibly
>>>>>> assist you in determing which libraries are missing.
>>>>>>
>>>>>> BTW:
>>>>>> why are you using cgywin, etc rather than the CCS IDE for the
>>>>>> compile/link operations?
>>>>>>
>>>>>> R. Williams
>>>>>>
>>>>>> ---------- Original Message -----------
>>>>>> From: i...@gmail.com
>>>>>> To: c...
>>>>>> Sent: Mon, 23 Jun 2008 14:09:57 -0400
>>>>>> Subject: [c6x] Urgent Help Required: CLK_gethtime
>>>>>>
>>>>>> > Hi all,
>>>>>> >
>>>>>> > Platform : DSK6416.
>>>>>> > I have some problems regarding usage of BIOS with the header files
>>>>>> ,all my source code are
>>>>>> > compiled with Cygwin and TI C64x, this gives me the obj's which in
>>>>>> turn i am linking using
>>>>>> > the code composer, the problem is that i need to have this working
>>>>>> with the BIOS
>>>>>> > Clk_gethtime, if i use the function clk_gethtime with references of
>>>>>> the libraries it says
>>>>>> > that other references are missing, could anyone suggest me what are
>>>>>> the header files that
>>>>>> > need to be included to get the clk_gethtime working with proper
>>>>>> references. How can i
>>>>>> > start the bios if i cant use the GUI. Which are the header files
>>>>>> that need to be
>>>>>> > associated with it. The documentation regarding the Bios is very
>>>>>> poor, it is not quite
>>>>>> > clear about many aspects, if some one who had worked on BIOS could
>>>>>> throw a limelight it
>>>>>> > will be very helpfull for me .
>>>>>> >
>>>>>> > -BR
>>>>>> > -Goku------- End of Original Message -------
>>>>>>
>>>>>>
>>>
>>> --
>> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

HI All,
Sorry , in continuation with the previous mail, the mapping was changed wrt
.text area changed from SDRAM to ISRAM, the clock cycles increased when
mapped o ISRAM.

Regards,
Goku

On Fri, Jun 27, 2008 at 4:10 PM, Goku wrote:

> Hello Mike/ Jeff ,
>
> I did manage to configure the timer, but the profiler clock cycles never
> matches with that of the TIMER_count from the csl api, there is a huge
> amount of difference:
>
> I have configured the timer as follows : but not sure whether it is
> configured properly, don't know whether it is overflowing, since the cycle
> count always less than the PRD set value i.e 0xFFFFFFFF, i am not able to
> tell , regarding the increment of timer : I have calculated it like this :
> DSK 6416 has 1Ghz Processor, hence the 1 CPU clock period= 10exp -9 > 1/1Ghz.
> Timer Input Clock = 8* ( 1/1Ghz) ;
> Timer Period= 0xFFFFFFFF
> Timer Period for Timer1 Interrupt is = 0xFFFFFFFF * (1/1Ghz) * 8= 34.5 Sec,
> Here i am not able to Configure HW_15 for ISR, which could call .
>
> Actually the code runs for about 3-4 minutes before it could print the
> Timer Counts, the TImer is started when the decoding starts in the code, and
> stops at the end of decoding.
>
> And the difference is printed out, which states the no of clock cycles
> used.
>
> Other Aspects : Config File is as follows.
>
> L2 Cache : Not Configured, ISRAM is configured with the L2 enabling. It
> says in the caching document that it is not preferred to run the code
> without L2,i am not sure about the L1 on chip, by default it is enabled ,
> could anyone tell me how much difference a L1 miss and a hit can cause to
> the cpu cycles consumed.
>
> I am trying to find out the proper values for my application ( CPU cycles )
> , If i manage to get the cycle count not varying too much then i could do
> some more experiments.
>
> THis is an additional .cdb file since the heap required to run the
> application is more than ISRAM (1MB)
> SECTIONS {
> .bss: fill=0 {
> *(.bss)
> . += 0x4;
> } > ISRAM
>
> .far: {} > SDRAM
>
> .cinit: {} > ISRAM
>
> .pinit: {} > ISRAM
>
> .data: {} > ISRAM
>
> .switch: {} > ISRAM
>
> .cio: {} > ISRAM
>
> .text: {} > SDRAM
> .const: {} > SDRAM
> }
> When i mapped Stack on the SDRAM i am getting around 1420057808 * 8 CPU
> cycles, but when i map it against ISRAM i am getting more cycle count from
> the timer 3853073033 *8 ,both of them can't be compared to the profiler
> clock, does the profiler clock give out exact number of cpu cycles elapsed
> for running the entire program.? could you let me know,
>
> Initilization of Timer is done in this way, could you please let me know
> whether it is correct:
> Timer_start(hTImer1)
> start_time= Timer_getcount(hTimer1)
>
> Mp3 Decoding code
>
> stop_time= TImer_getcount(hTimer1)
> and the difference is printed out.
>
> In the GUI .cdb file, mentioned that the Input to the Timer is CPU/8 rate,
> with reset before the start. and PRD set to max 0xFFFFFFFF.
>
> Do i have to tag HW_15 for any isr() ? i cant do it since in my code
> composer such option is disabled.
>
> Does the timer give out right values since the Interrupt is driven once in
> 34.5 Secs. Please explain since i am stuck at this point and i want to
> clarify why the variation in clock cycles is happening, and which procedure
> is correct to get the timer working and to get the same amount of clock
> cycles all the times.
>
> Regards,
> Goku
> On Thu, Jun 26, 2008 at 7:53 PM, Michael Dunn
> wrote:
>
>> Goku,
>>
>> On 6/26/08, Goku wrote:
>>>
>>> Hello,
>>>
>>> I had configured the Timer as per Dunn, with the following
>>> configurations, and i am experiencing huge amount of clock cycle differences
>>> for the execution of the same code.
>>>
>>> Please Could any one of you explain the same,
>>>
>>> Code : MP3 Player.
>>>
>>> Result :
>>> Iterations = 1
>>> -- Target Duration = 1417161654 X 8 Clock Cycles - > CPU/8 config for
>>> the timer
>>>
>>> Iterations = 2
>>> -- Target Duration = 815201933 X 8 Clock Cycles - > CPU/8 config for
>>> the timer
>>>
>>>
>>> The same code was rerun after a successful reboot of the DSK 6416 and
>>> then i got the result for Iteration 2 which is almost half of the cycles
>>> taken for Iteration 1.
>>> The very first pass will have nothing in L1 cache and you will get 100%
>> misses. Passes 2 and later should have similar times [assuming similat code
>> flow].
>>
>> When i was using the debugger CCS Singles step i could see that the
>>> timer was overflowing in the timer register, even though i had set values
>>> set for PRD : FFFFFFFF , CNT -> Start with a Reset, Clk-: Tick= 1000
>>> Microseconds/Int, HWi_14 configured for Timer 0 , i could understand this
>>> behaviour .
>>> The timer knows nothing about the CPU state and will not give reliable
>> numbers when you halt the DSP. If you want to manually profile a function,
>> use the 'profile clock' in CCS. It will update when you single step.
>>
>> mikedunn
>>
>> Can anyone pls let me know why there is a huge variation in the clock
>>> cycles, all of my code resides in the SD RAM, and HWINIT_VEC are residing in
>>> the Internal memory.
>>>
>>> Regards,
>>> Goku
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 26, 2008 at 12:19 PM, Jeff Brower
>>> wrote:
>>>
>>>> Goku-
>>>>
>>>>
>>>> I have included rts6400.lib, but it is not defined in it, am using CCS
>>>> 3.3 Version, still getting the same error ," not able to resolve the symbol
>>>> definition" .Could you let me know the details pls.
>>>>
>>>>
>>>> _CLK_gethtime is defined in bios.a64, or similar depending on the DSP
>>>> type. I think it gets resolved to CLK_F_gethtime (function defined in asm
>>>> code). bios.a64 file is not an rtdx lib file; ignore my previous comment,
>>>>
>>>> Mike and Richard's suggestions about simpler ways to benchmark and
>>>> profile code are accurate and useful. You should try those. If for some
>>>> reason you still want to use _CLK_gethtime, then you have to use it together
>>>> with _CLK_getltime and also have to deal with issues of timer wrap-around
>>>> and interrupt enable/disable for _getltime. This doc has a good
>>>> explanation:
>>>>
>>>> http://focus.ti.com/lit/an/spra829/spra829.pdf
>>>>
>>>> -Jeff
>>>>
>>>>
>>>> On Tue, Jun 24, 2008 at 5:21 PM, Jeff Brower
>>>> wrote:
>>>>>
>>>>> Goku-
>>>>>
>>>>> Since i am benchmarking different applications which are ported from
>>>>> linux, the linking is done with a makefile which has a huge code base, am
>>>>> using cygwin and CCS compiler, but not the IDE, target is connected to a
>>>>> different machine which has the CCS IDE, hence here i cant use the GUI
>>>>> interface, i dont know how could i use Clk_gethtime without the CCS IDE GUI
>>>>> Bios Start, could you pls let me know.
>>>>>
>>>>>
>>>>> CLK_gethtime should be in the basic run-time library, rts64xx.lib (not
>>>>> sure of that correct name, but look for rts64-something).
>>>>>
>>>>>
>>>>> Error: _CLK_gethtime undefined symbol.
>>>>>
>>>>> I could see that Clk_gethtime library is missing , if i add the
>>>>> libraries like bios.a64 and others , they tend to say that there are many
>>>>> other symbols which are not defined.
>>>>>
>>>>>
>>>>> bios.a64 sounds to me like an RTDX library... nothing to do with CLK_xx
>>>>> functions.
>>>>>
>>>>> TI's code-gen tools for Linux are new and not widely used. I would
>>>>> suggest that you build using standard CCS v3.3 on a Win machine, and test
>>>>> that output code first. Since you have a "huge" code base, it's a good idea
>>>>> to eliminate any possible build error, library version, link error, etc.
>>>>>
>>>>> Think about it this way -- TI didn't have Linux based code-gen tools
>>>>> until recently (last couple of years). So that means since 1996, when they
>>>>> acquired GoDSP (Code Composer), they've been pouring manpower and millions
>>>>> into Win code-gen tools, not Linux. Which one do you think is more reliable
>>>>> and widely used?
>>>>>
>>>>> -Jeff
>>>>>
>>>>>
>>>>> On Tue, Jun 24, 2008 at 2:21 AM, Richard Williams <
>>>>> r...@lewiscounty.com> wrote:
>>>>>>
>>>>>> ittiam,
>>>>>>
>>>>>> from your description, it is rather obvious that some libraries are
>>>>>> missing (assuming that the
>>>>>> compile operations worked with no errors.)
>>>>>>
>>>>>> If you would post the names of the functions that are not found by the
>>>>>> linker, we could possibly
>>>>>> assist you in determing which libraries are missing.
>>>>>>
>>>>>> BTW:
>>>>>> why are you using cgywin, etc rather than the CCS IDE for the
>>>>>> compile/link operations?
>>>>>>
>>>>>> R. Williams
>>>>>>
>>>>>> ---------- Original Message -----------
>>>>>> From: i...@gmail.com
>>>>>> To: c...
>>>>>> Sent: Mon, 23 Jun 2008 14:09:57 -0400
>>>>>> Subject: [c6x] Urgent Help Required: CLK_gethtime
>>>>>>
>>>>>> > Hi all,
>>>>>> >
>>>>>> > Platform : DSK6416.
>>>>>> > I have some problems regarding usage of BIOS with the header files
>>>>>> ,all my source code are
>>>>>> > compiled with Cygwin and TI C64x, this gives me the obj's which in
>>>>>> turn i am linking using
>>>>>> > the code composer, the problem is that i need to have this working
>>>>>> with the BIOS
>>>>>> > Clk_gethtime, if i use the function clk_gethtime with references of
>>>>>> the libraries it says
>>>>>> > that other references are missing, could anyone suggest me what are
>>>>>> the header files that
>>>>>> > need to be included to get the clk_gethtime working with proper
>>>>>> references. How can i
>>>>>> > start the bios if i cant use the GUI. Which are the header files
>>>>>> that need to be
>>>>>> > associated with it. The documentation regarding the Bios is very
>>>>>> poor, it is not quite
>>>>>> > clear about many aspects, if some one who had worked on BIOS could
>>>>>> throw a limelight it
>>>>>> > will be very helpfull for me .
>>>>>> >
>>>>>> > -BR
>>>>>> > -Goku------- End of Original Message -------
>>>>>>
>>>>>>
>>>
>>> --
>> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>> Start a New Thread

Goku-
> I did manage to configure the timer, but the profiler clock cycles never matches
> with that of the TIMER_count from the csl api, there is a huge amount of
> difference:
>
> I have configured the timer as follows : but not sure whether it is configured
> properly, don't know whether it is overflowing, since the cycle count always less
> than the PRD set value i.e 0xFFFFFFFF, i am not able to tell , regarding the
> increment of timer : I have calculated it like this : DSK 6416 has 1Ghz Processor,
> hence the 1 CPU clock period= 10exp -9 = 1/1Ghz.
> Timer Input Clock = 8* ( 1/1Ghz) ;
> Timer Period= 0xFFFFFFFF
> Timer Period for Timer1 Interrupt is = 0xFFFFFFFF * (1/1Ghz) * 8= 34.5 Sec, Here i
> am not able to Configure HW_15 for ISR, which could call .
>
> Actually the code runs for about 3-4 minutes before it could print the Timer
> Counts, the TImer is started when the decoding starts in the code, and stops at the
> end of decoding.

If you need to measure periods longer than 34.36 sec, then you can:

a) use a timer interrupt to capture the wrap-
around; i.e. increment a software variable

a) use the CLK_gethtime + CLK_getltime method,
which requires DSP/BIOS to be running

b) use Richard's suggestion of toggling a GPIO
pin and use some external means (stand by
the dig scope holding a watch :-)

Otherwise, you don't know when the timer has wrapped, as you have found.

But I don't understand, why such a long time? You're doing an MP3 decode and it
takes 3-4 minutes? If that's really the case, then you're a long ways away from
real-time so what's the point of profiling? Any benchmarks you get at this point are
meaningless in a DSP environment. You should be working to get your code running in
real-time, then go and profile the code, in order to find the average frame overhead,
sections of code that should be optmized, etc. That's the normal approach.

-Jeff
> And the difference is printed out, which states the no of clock cycles used.
>
> Other Aspects : Config File is as follows.
>
> L2 Cache : Not Configured, ISRAM is configured with the L2 enabling. It says in the
> caching document that it is not preferred to run the code without L2,i am not sure
> about the L1 on chip, by default it is enabled , could anyone tell me how much
> difference a L1 miss and a hit can cause to the cpu cycles consumed.
>
> I am trying to find out the proper values for my application ( CPU cycles ) , If i
> manage to get the cycle count not varying too much then i could do some more
> experiments.
>
> THis is an additional .cdb file since the heap required to run the application is
> more than ISRAM (1MB)
> SECTIONS {
> .bss: fill=0 {
> *(.bss)
> . += 0x4;
> } > ISRAM
>
> .far: {} > SDRAM
>
> .cinit: {} > ISRAM
>
> .pinit: {} > ISRAM
>
> .data: {} > ISRAM
>
> .switch: {} > ISRAM
>
> .cio: {} > ISRAM
>
> .text: {} > SDRAM
> .const: {} > SDRAM
> }
> When i mapped Stack on the SDRAM i am getting around 1420057808 * 8 CPU cycles,
> but when i map it against ISRAM i am getting more cycle count from the timer
> 3853073033 *8 ,both of them can't be compared to the profiler clock, does the
> profiler clock give out exact number of cpu cycles elapsed for running the entire
> program.? could you let me know,
>
> Initilization of Timer is done in this way, could you please let me know whether it
> is correct:
> Timer_start(hTImer1)
> start_time= Timer_getcount(hTimer1)
>
> Mp3 Decoding code
>
> stop_time= TImer_getcount(hTimer1)
> and the difference is printed out.
>
> In the GUI .cdb file, mentioned that the Input to the Timer is CPU/8 rate, with
> reset before the start. and PRD set to max 0xFFFFFFFF.
>
> Do i have to tag HW_15 for any isr() ? i cant do it since in my code composer such
> option is disabled.
>
> Does the timer give out right values since the Interrupt is driven once in 34.5
> Secs. Please explain since i am stuck at this point and i want to clarify why the
> variation in clock cycles is happening, and which procedure is correct to get the
> timer working and to get the same amount of clock cycles all the times.
>
> Regards,
> Goku
>
> On Thu, Jun 26, 2008 at 7:53 PM, Michael Dunn wrote:
>
> Goku,
>
> On 6/26/08, Goku wrote:
>
> Hello, I had configured the Timer as per Dunn, with the
> following configurations, and i am experiencing huge amount of
> clock cycle differences for the execution of the same code.
>
> Please Could any one of you explain the same,
>
> Code : MP3 Player.
>
> Result :
> Iterations = 1
> -- Target Duration = 1417161654 X 8 Clock Cycles - > CPU/8
> config for the timer Iterations = 2
> -- Target Duration = 815201933 X 8 Clock Cycles - > CPU/8
> config for the timer
> The same code was rerun after a successful reboot of the DSK
> 6416 and then i got the result for Iteration 2 which is almost
> half of the cycles taken for Iteration 1.
> The very first pass will have nothing in L1 cache and you will get 100%
> misses. Passes 2 and later should have similar times [assuming similat
> code flow].
> When i was using the debugger CCS Singles step i could see that
> the timer was overflowing in the timer register, even though i
> had set values set for PRD : FFFFFFFF , CNT -> Start with a
> Reset, Clk-: Tick= 1000 Microseconds/Int, HWi_14 configured for
> Timer 0 , i could understand this behaviour .
> The timer knows nothing about the CPU state and will not give reliable
> numbers when you halt the DSP. If you want to manually profile a
> function, use the 'profile clock' in CCS. It will update when you single
> step.mikedunn
>
> Can anyone pls let me know why there is a huge variation in the
> clock cycles, all of my code resides in the SD RAM, and
> HWINIT_VEC are residing in the Internal memory.
>
> Regards,
> Goku
> On Thu, Jun 26, 2008 at 12:19 PM, Jeff Brower
> wrote:
>
> Goku-
>
> > I have included rts6400.lib, but it is not defined
> > in it, am using CCS 3.3 Version, still getting the
> > same error ," not able to resolve the symbol
> > definition" .Could you let me know the details pls.
> _CLK_gethtime is defined in bios.a64, or similar
> depending on the DSP type. I think it gets resolved
> to CLK_F_gethtime (function defined in asm code).
> bios.a64 file is not an rtdx lib file; ignore my
> previous comment,
>
> Mike and Richard's suggestions about simpler ways to
> benchmark and profile code are accurate and useful.
> You should try those. If for some reason you still
> want to use _CLK_gethtime, then you have to use it
> together with _CLK_getltime and also have to deal
> with issues of timer wrap-around and interrupt
> enable/disable for _getltime. This doc has a good
> explanation:
>
> http://focus.ti.com/lit/an/spra829/spra829.pdf-Jeff
>
> > On Tue, Jun 24, 2008 at 5:21 PM, Jeff Brower
> > wrote:
> >
> > Goku-
> >
> > > Since i am benchmarking different
> > > applications which are ported from
> > > linux, the linking is done with a
> > > makefile which has a huge code base, am
> > > using cygwin and CCS compiler, but not
> > > the IDE, target is connected to a
> > > different machine which has the CCS IDE,
> > > hence here i cant use the GUI interface,
> > > i dont know how could i use Clk_gethtime
> > > without the CCS IDE GUI Bios Start,
> > > could you pls let me know.
> >
> >
> > CLK_gethtime should be in the basic
> > run-time library, rts64xx.lib (not sure
> > of that correct name, but look for
> > rts64-something).
> >
> > > Error: _CLK_gethtime undefined symbol.
> > >
> > > I could see that Clk_gethtime library is
> > > missing , if i add the libraries like
> > > bios.a64 and others , they tend to say
> > > that there are many other symbols which
> > > are not defined.
> >
> >
> > bios.a64 sounds to me like an RTDX
> > library... nothing to do with CLK_xx
> > functions.
> >
> > TI's code-gen tools for Linux are new and
> > not widely used. I would suggest that
> > you build using standard CCS v3.3 on a
> > Win machine, and test that output code
> > first. Since you have a "huge" code
> > base, it's a good idea to eliminate any
> > possible build error, library version,
> > link error, etc.
> >
> > Think about it this way -- TI didn't have
> > Linux based code-gen tools until recently
> > (last couple of years). So that means
> > since 1996, when they acquired GoDSP
> > (Code Composer), they've been pouring
> > manpower and millions into Win code-gen
> > tools, not Linux. Which one do you think
> > is more reliable and widely used?
> >
> > -Jeff
> >
> > > On Tue, Jun 24, 2008 at 2:21 AM, Richard
> > > Williams wrote:
> > >
> > > ittiam,
> > >
> > > from your description, it is
> > > rather obvious that some
> > > libraries are missing
> > > (assuming that the
> > > compile operations worked with
> > > no errors.)
> > >
> > > If you would post the names of
> > > the functions that are not
> > > found by the linker, we could
> > > possibly
> > > assist you in determing which
> > > libraries are missing.
> > >
> > > BTW:
> > > why are you using cgywin, etc
> > > rather than the CCS IDE for
> > > the compile/link operations?
> > >
> > > R. Williams
> > >
> > > ---------- Original Message
> > > -----------
> > > From: i...@gmail.com
> > > To: c...
> > > Sent: Mon, 23 Jun 2008
> > > 14:09:57 -0400
> > > Subject: [c6x] Urgent Help
> > > Required: CLK_gethtime
> > >
> > > > Hi all,
> > > >
> > > > Platform : DSK6416.
> > > > I have some problems
> > > regarding usage of BIOS with
> > > the header files ,all my
> > > source code are
> > > > compiled with Cygwin and TI
> > > C64x, this gives me the obj's
> > > which in turn i am linking
> > > using
> > > > the code composer, the
> > > problem is that i need to have
> > > this working with the BIOS
> > > > Clk_gethtime, if i use the
> > > function clk_gethtime with
> > > references of the libraries it
> > > says
> > > > that other references are
> > > missing, could anyone suggest
> > > me what are the header files
> > > that
> > > > need to be included to get
> > > the clk_gethtime working with
> > > proper references. How can i
> > > > start the bios if i cant use
> > > the GUI. Which are the header
> > > files that need to be
> > > > associated with it. The
> > > documentation regarding the
> > > Bios is very poor, it is not
> > > quite
> > > > clear about many aspects, if
> > > some one who had worked on
> > > BIOS could throw a limelight
> > > it
> > > > will be very helpfull for me
> > > .
> > > >
> > > > -BR
> > > > -Goku------- End of Original
> > > Message -------
> > >
> > >
> > > Start a New Thread

Hello Mike/ Jeff ,

I did manage to configure the timer, but the profiler clock cycles never
matches with that of the TIMER_count from the csl api, there is a huge
amount of difference:

I have configured the timer as follows : but not sure whether it is
configured properly, don't know whether it is overflowing, since the cycle
count always less than the PRD set value i.e 0xFFFFFFFF, i am not able to
tell , regarding the increment of timer : I have calculated it like this :
DSK 6416 has 1Ghz Processor, hence the 1 CPU clock period= 10exp -9 1/1Ghz.
Timer Input Clock = 8* ( 1/1Ghz) ;
Timer Period= 0xFFFFFFFF
Timer Period for Timer1 Interrupt is = 0xFFFFFFFF * (1/1Ghz) * 8= 34.5 Sec,
Here i am not able to Configure HW_15 for ISR, which could call .

Actually the code runs for about 3-4 minutes before it could print the Timer
Counts, the TImer is started when the decoding starts in the code, and stops
at the end of decoding.

And the difference is printed out, which states the no of clock cycles used.
Other Aspects : Config File is as follows.

L2 Cache : Not Configured, ISRAM is configured with the L2 enabling. It says
in the caching document that it is not preferred to run the code without
L2,i am not sure about the L1 on chip, by default it is enabled , could
anyone tell me how much difference a L1 miss and a hit can cause to the cpu
cycles consumed.

I am trying to find out the proper values for my application ( CPU cycles )
, If i manage to get the cycle count not varying too much then i could do
some more experiments.

THis is an additional .cdb file since the heap required to run the
application is more than ISRAM (1MB)
SECTIONS {
.bss: fill=0 {
*(.bss)
. += 0x4;
} > ISRAM

.far: {} > SDRAM

.cinit: {} > ISRAM

.pinit: {} > ISRAM

.data: {} > ISRAM

.switch: {} > ISRAM

.cio: {} > ISRAM

.text: {} > SDRAM
.const: {} > SDRAM
}
When i mapped Stack on the SDRAM i am getting around 1420057808 * 8 CPU
cycles, but when i map it against ISRAM i am getting more cycle count from
the timer 3853073033 *8 ,both of them can't be compared to the profiler
clock, does the profiler clock give out exact number of cpu cycles elapsed
for running the entire program.? could you let me know,

Initilization of Timer is done in this way, could you please let me know
whether it is correct:
Timer_start(hTImer1)
start_time= Timer_getcount(hTimer1)

Mp3 Decoding code

stop_time= TImer_getcount(hTimer1)
and the difference is printed out.

In the GUI .cdb file, mentioned that the Input to the Timer is CPU/8 rate,
with reset before the start. and PRD set to max 0xFFFFFFFF.

Do i have to tag HW_15 for any isr() ? i cant do it since in my code
composer such option is disabled.

Does the timer give out right values since the Interrupt is driven once in
34.5 Secs. Please explain since i am stuck at this point and i want to
clarify why the variation in clock cycles is happening, and which procedure
is correct to get the timer working and to get the same amount of clock
cycles all the times.

Regards,
Goku

On Thu, Jun 26, 2008 at 7:53 PM, Michael Dunn
wrote:

> Goku,
>
> On 6/26/08, Goku wrote:
>>
>> Hello,
>>
>> I had configured the Timer as per Dunn, with the following configurations,
>> and i am experiencing huge amount of clock cycle differences for the
>> execution of the same code.
>>
>> Please Could any one of you explain the same,
>>
>> Code : MP3 Player.
>>
>> Result :
>> Iterations = 1
>> -- Target Duration = 1417161654 X 8 Clock Cycles - > CPU/8 config for
>> the timer
>>
>> Iterations = 2
>> -- Target Duration = 815201933 X 8 Clock Cycles - > CPU/8 config for
>> the timer
>> The same code was rerun after a successful reboot of the DSK 6416 and then
>> i got the result for Iteration 2 which is almost half of the cycles taken
>> for Iteration 1.
>> The very first pass will have nothing in L1 cache and you will get 100%
> misses. Passes 2 and later should have similar times [assuming similat code
> flow].
>
> When i was using the debugger CCS Singles step i could see that the
>> timer was overflowing in the timer register, even though i had set values
>> set for PRD : FFFFFFFF , CNT -> Start with a Reset, Clk-: Tick= 1000
>> Microseconds/Int, HWi_14 configured for Timer 0 , i could understand this
>> behaviour .
>> The timer knows nothing about the CPU state and will not give reliable
> numbers when you halt the DSP. If you want to manually profile a function,
> use the 'profile clock' in CCS. It will update when you single step.
>
> mikedunn
>
> Can anyone pls let me know why there is a huge variation in the clock
>> cycles, all of my code resides in the SD RAM, and HWINIT_VEC are residing in
>> the Internal memory.
>>
>> Regards,
>> Goku
>> On Thu, Jun 26, 2008 at 12:19 PM, Jeff Brower
>> wrote:
>>
>>> Goku-
>>>
>>>
>>> I have included rts6400.lib, but it is not defined in it, am using CCS
>>> 3.3 Version, still getting the same error ," not able to resolve the symbol
>>> definition" .Could you let me know the details pls.
>>>
>>>
>>> _CLK_gethtime is defined in bios.a64, or similar depending on the DSP
>>> type. I think it gets resolved to CLK_F_gethtime (function defined in asm
>>> code). bios.a64 file is not an rtdx lib file; ignore my previous comment,
>>>
>>> Mike and Richard's suggestions about simpler ways to benchmark and
>>> profile code are accurate and useful. You should try those. If for some
>>> reason you still want to use _CLK_gethtime, then you have to use it together
>>> with _CLK_getltime and also have to deal with issues of timer wrap-around
>>> and interrupt enable/disable for _getltime. This doc has a good
>>> explanation:
>>>
>>> http://focus.ti.com/lit/an/spra829/spra829.pdf
>>>
>>> -Jeff
>>>
>>>
>>> On Tue, Jun 24, 2008 at 5:21 PM, Jeff Brower
>>> wrote:
>>>>
>>>> Goku-
>>>>
>>>> Since i am benchmarking different applications which are ported from
>>>> linux, the linking is done with a makefile which has a huge code base, am
>>>> using cygwin and CCS compiler, but not the IDE, target is connected to a
>>>> different machine which has the CCS IDE, hence here i cant use the GUI
>>>> interface, i dont know how could i use Clk_gethtime without the CCS IDE GUI
>>>> Bios Start, could you pls let me know.
>>>>
>>>>
>>>> CLK_gethtime should be in the basic run-time library, rts64xx.lib (not
>>>> sure of that correct name, but look for rts64-something).
>>>>
>>>>
>>>> Error: _CLK_gethtime undefined symbol.
>>>>
>>>> I could see that Clk_gethtime library is missing , if i add the
>>>> libraries like bios.a64 and others , they tend to say that there are many
>>>> other symbols which are not defined.
>>>>
>>>>
>>>> bios.a64 sounds to me like an RTDX library... nothing to do with CLK_xx
>>>> functions.
>>>>
>>>> TI's code-gen tools for Linux are new and not widely used. I would
>>>> suggest that you build using standard CCS v3.3 on a Win machine, and test
>>>> that output code first. Since you have a "huge" code base, it's a good idea
>>>> to eliminate any possible build error, library version, link error, etc.
>>>>
>>>> Think about it this way -- TI didn't have Linux based code-gen tools
>>>> until recently (last couple of years). So that means since 1996, when they
>>>> acquired GoDSP (Code Composer), they've been pouring manpower and millions
>>>> into Win code-gen tools, not Linux. Which one do you think is more reliable
>>>> and widely used?
>>>>
>>>> -Jeff
>>>>
>>>>
>>>> On Tue, Jun 24, 2008 at 2:21 AM, Richard Williams <
>>>> r...@lewiscounty.com> wrote:
>>>>>
>>>>> ittiam,
>>>>>
>>>>> from your description, it is rather obvious that some libraries are
>>>>> missing (assuming that the
>>>>> compile operations worked with no errors.)
>>>>>
>>>>> If you would post the names of the functions that are not found by the
>>>>> linker, we could possibly
>>>>> assist you in determing which libraries are missing.
>>>>>
>>>>> BTW:
>>>>> why are you using cgywin, etc rather than the CCS IDE for the
>>>>> compile/link operations?
>>>>>
>>>>> R. Williams
>>>>>
>>>>> ---------- Original Message -----------
>>>>> From: i...@gmail.com
>>>>> To: c...
>>>>> Sent: Mon, 23 Jun 2008 14:09:57 -0400
>>>>> Subject: [c6x] Urgent Help Required: CLK_gethtime
>>>>>
>>>>> > Hi all,
>>>>> >
>>>>> > Platform : DSK6416.
>>>>> > I have some problems regarding usage of BIOS with the header files
>>>>> ,all my source code are
>>>>> > compiled with Cygwin and TI C64x, this gives me the obj's which in
>>>>> turn i am linking using
>>>>> > the code composer, the problem is that i need to have this working
>>>>> with the BIOS
>>>>> > Clk_gethtime, if i use the function clk_gethtime with references of
>>>>> the libraries it says
>>>>> > that other references are missing, could anyone suggest me what are
>>>>> the header files that
>>>>> > need to be included to get the clk_gethtime working with proper
>>>>> references. How can i
>>>>> > start the bios if i cant use the GUI. Which are the header files that
>>>>> need to be
>>>>> > associated with it. The documentation regarding the Bios is very
>>>>> poor, it is not quite
>>>>> > clear about many aspects, if some one who had worked on BIOS could
>>>>> throw a limelight it
>>>>> > will be very helpfull for me .
>>>>> >
>>>>> > -BR
>>>>> > -Goku------- End of Original Message -------
>>>>>
>>>>> --
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
> Start a New Thread

Hello ,

HWI_15 is not tagged to the ISR routine, where in i am incrementing a static
variable to get the ticks, as per my calculation an Interrupt should be
triggered every 34.5 Sec and the variable should be updated at that
instance, but it is not all going to the ISR function, could you please let
me know how can i enable the ISR. I have this piece of code:

TimerEventId1=TIMER_getEventId(hTimer1);
IRQ_enable(TimerEventId1);
TIMER_start(hTimer1);

I can't tag HwI_15 to a ISR as given in the manual , reason being that it is
not enabled, so i have marked HWI_4 for Timer1, but still it doesnt enter
into the ISR routine, am i doing something wrong here, can u pls let me
know.

Regards,
Goku

On Fri, Jun 27, 2008 at 5:09 PM, Michael Dunn
wrote:

> Goku,
>
> On 6/27/08, Goku wrote:
>>
>> Hello Mike/ Jeff ,
>>
>> I did manage to configure the timer, but the profiler clock cycles never
>> matches with that of the TIMER_count from the csl api, there is a huge
>> amount of difference:
>>
>> I have configured the timer as follows : but not sure whether it is
>> configured properly, don't know whether it is overflowing, since the cycle
>> count always less than the PRD set value i.e 0xFFFFFFFF, i am not able to
>> tell , regarding the increment of timer : I have calculated it like this :
>> DSK 6416 has 1Ghz Processor, hence the 1 CPU clock period= 10exp -9 >> 1/1Ghz.
>> Timer Input Clock = 8* ( 1/1Ghz) ;
>> Timer Period= 0xFFFFFFFF
>> Timer Period for Timer1 Interrupt is = 0xFFFFFFFF * (1/1Ghz) * 8= 34.5
>> Sec, Here i am not able to Configure HW_15 for ISR, which could call .
> I suggest that you crawl, walk, and then run wrt to profiling. I do not
> have time to analyze everything for you, but the following steps should
> help.
> 1. Get a basic understanding using a simple program. From main call a
> function with a processing loop and a large count [something like a 1,000
> cycle loop with a count of 100,000. I suggest that you run the program once
> before measurements and then take each measurement twice - if you get a
> large difference, take it 3 times.
> 2. In main, time the loop from before the func call until after using the
> timer. Don't worry about overflow yet, get the timer correct first. The
> timer is not cycle accurate, but it will be very close [+/- a few cycles].
> 3. From main, time the loop using the profile counter. This should be the
> actual number of cycles [it will include some overhead] +/- 1.
> 4. From main, set a GPIO pin before the func call and clear it after.
> Measure this on a scope.
> 5. All three of the above methods should be very close. Once they are, you
> should be ready to take some 'real' measurements [if you use the timer,
> lengthen the loop to overflow and debug the overflow detection].
> Actually the code runs for about 3-4 minutes before it could print the
>> Timer Counts, the TImer is started when the decoding starts in the code, and
>> stops at the end of decoding.
>>
>> And the difference is printed out, which states the no of clock cycles
>> used.
>>
>> Other Aspects : Config File is as follows.
>>
>> L2 Cache : Not Configured, ISRAM is configured with the L2 enabling. It
>> says in the caching document that it is not preferred to run the code
>> without L2,i am not sure about the L1 on chip, by default it is enabled ,
>> could anyone tell me how much difference a L1 miss and a hit can cause to
>> the cpu cycles consumed.
> This will vary with program. For a simple or sequential program:
> 1. Reset/flush cache
> 2. Load, run program [= L1 'is empty']
> 3. Restart, run program [= L1 'has repeatable cached entries']
> 4. Restart, run program [= L1 'has repeatable cached entries']. Should be
> similar to previous.
> 5. Restart, run program [= L1 'has repeatable cached entries']. Should be
> similar to previous.
>
> If you want the details, goto spru190 and it will point you to the doc on
> c64 cache/internal memory.
>
> I am trying to find out the proper values for my application ( CPU cycles )
>> , If i manage to get the cycle count not varying too much then i could do
>> some more experiments.
> FYI - Some applications 'vary all over the place' in cycle count. The
> 'GPIO method' is the 100% accurate [with almost no overhead] realtime
> measurement.
>
> THis is an additional .cdb file since the heap required to run the
>> application is more than ISRAM (1MB)
>> SECTIONS {
>> .bss: fill=0 {
>> *(.bss)
>> . += 0x4;
>> } > ISRAM
>>
>> .far: {} > SDRAM
>>
>> .cinit: {} > ISRAM
>>
>> .pinit: {} > ISRAM
>>
>> .data: {} > ISRAM
>>
>> .switch: {} > ISRAM
>>
>> .cio: {} > ISRAM
>>
>> .text: {} > SDRAM
>> .const: {} > SDRAM
>> }
>> When i mapped Stack on the SDRAM i am getting around 1420057808 * 8 CPU
>> cycles, but when i map it against ISRAM i am getting more cycle count from
>> the timer 3853073033 *8 ,both of them can't be compared to the profiler
>> clock, does the profiler clock give out exact number of cpu cycles elapsed
>> for running the entire program.? could you let me know,
> The profiler clock measures from 'run' to 'halt' by reading a hardware
> counter [I don't remember if it is 32 or 64 bits - I typically only use it
> for single function measurements].
>
> mikedunn
>
> Initilization of Timer is done in this way, could you please let me know
>> whether it is correct:
>> Timer_start(hTImer1)
>> start_time= Timer_getcount(hTimer1)
>>
>> Mp3 Decoding code
>>
>> stop_time= TImer_getcount(hTimer1)
>> and the difference is printed out.
>>
>> In the GUI .cdb file, mentioned that the Input to the Timer is CPU/8 rate,
>> with reset before the start. and PRD set to max 0xFFFFFFFF.
>>
>> Do i have to tag HW_15 for any isr() ? i cant do it since in my code
>> composer such option is disabled.
>>
>> Does the timer give out right values since the Interrupt is driven once in
>> 34.5 Secs. Please explain since i am stuck at this point and i want to
>> clarify why the variation in clock cycles is happening, and which procedure
>> is correct to get the timer working and to get the same amount of clock
>> cycles all the times.
>>
>> Regards,
>> Goku
>>
>> On Thu, Jun 26, 2008 at 7:53 PM, Michael Dunn
>> wrote:
>>
>>> Goku,
>>>
>>> On 6/26/08, Goku wrote:
>>>>
>>>> Hello,
>>>>
>>>> I had configured the Timer as per Dunn, with the following
>>>> configurations, and i am experiencing huge amount of clock cycle differences
>>>> for the execution of the same code.
>>>>
>>>> Please Could any one of you explain the same,
>>>>
>>>> Code : MP3 Player.
>>>>
>>>> Result :
>>>> Iterations = 1
>>>> -- Target Duration = 1417161654 X 8 Clock Cycles - > CPU/8 config for
>>>> the timer
>>>>
>>>> Iterations = 2
>>>> -- Target Duration = 815201933 X 8 Clock Cycles - > CPU/8 config for
>>>> the timer
>>>>
>>>>
>>>> The same code was rerun after a successful reboot of the DSK 6416 and
>>>> then i got the result for Iteration 2 which is almost half of the cycles
>>>> taken for Iteration 1.
>>>>
>>>
>>> The very first pass will have nothing in L1 cache and you will get 100%
>>> misses. Passes 2 and later should have similar times [assuming similat code
>>> flow].
>>>
>>>
>>>
>>> When i was using the debugger CCS Singles step i could see that the
>>>> timer was overflowing in the timer register, even though i had set values
>>>> set for PRD : FFFFFFFF , CNT -> Start with a Reset, Clk-: Tick= 1000
>>>> Microseconds/Int, HWi_14 configured for Timer 0 , i could understand this
>>>> behaviour .
>>>>
>>>
>>> The timer knows nothing about the CPU state and will not give reliable
>>> numbers when you halt the DSP. If you want to manually profile a function,
>>> use the 'profile clock' in CCS. It will update when you single step.
>>>
>>> mikedunn
>>>
>>> Can anyone pls let me know why there is a huge variation in the
>>>> clock cycles, all of my code resides in the SD RAM, and HWINIT_VEC are
>>>> residing in the Internal memory.
>>>>
>>>> Regards,
>>>> Goku
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jun 26, 2008 at 12:19 PM, Jeff Brower
>>>> wrote:
>>>>
>>>>> Goku-
>>>>>
>>>>>
>>>>> I have included rts6400.lib, but it is not defined in it, am using CCS
>>>>> 3.3 Version, still getting the same error ," not able to resolve the symbol
>>>>> definition" .Could you let me know the details pls.
>>>>>
>>>>>
>>>>> _CLK_gethtime is defined in bios.a64, or similar depending on the DSP
>>>>> type. I think it gets resolved to CLK_F_gethtime (function defined in asm
>>>>> code). bios.a64 file is not an rtdx lib file; ignore my previous comment,
>>>>>
>>>>> Mike and Richard's suggestions about simpler ways to benchmark and
>>>>> profile code are accurate and useful. You should try those. If for some
>>>>> reason you still want to use _CLK_gethtime, then you have to use it together
>>>>> with _CLK_getltime and also have to deal with issues of timer wrap-around
>>>>> and interrupt enable/disable for _getltime. This doc has a good
>>>>> explanation:
>>>>>
>>>>> http://focus.ti.com/lit/an/spra829/spra829.pdf
>>>>>
>>>>> -Jeff
>>>>>
>>>>>
>>>>> On Tue, Jun 24, 2008 at 5:21 PM, Jeff Brower
>>>>> wrote:
>>>>>>
>>>>>> Goku-
>>>>>>
>>>>>> Since i am benchmarking different applications which are ported from
>>>>>> linux, the linking is done with a makefile which has a huge code base, am
>>>>>> using cygwin and CCS compiler, but not the IDE, target is connected to a
>>>>>> different machine which has the CCS IDE, hence here i cant use the GUI
>>>>>> interface, i dont know how could i use Clk_gethtime without the CCS IDE GUI
>>>>>> Bios Start, could you pls let me know.
>>>>>>
>>>>>>
>>>>>> CLK_gethtime should be in the basic run-time library, rts64xx.lib (not
>>>>>> sure of that correct name, but look for rts64-something).
>>>>>>
>>>>>>
>>>>>> Error: _CLK_gethtime undefined symbol.
>>>>>>
>>>>>> I could see that Clk_gethtime library is missing , if i add the
>>>>>> libraries like bios.a64 and others , they tend to say that there are many
>>>>>> other symbols which are not defined.
>>>>>>
>>>>>>
>>>>>> bios.a64 sounds to me like an RTDX library... nothing to do with
>>>>>> CLK_xx functions.
>>>>>>
>>>>>> TI's code-gen tools for Linux are new and not widely used. I would
>>>>>> suggest that you build using standard CCS v3.3 on a Win machine, and test
>>>>>> that output code first. Since you have a "huge" code base, it's a good idea
>>>>>> to eliminate any possible build error, library version, link error, etc.
>>>>>>
>>>>>> Think about it this way -- TI didn't have Linux based code-gen tools
>>>>>> until recently (last couple of years). So that means since 1996, when they
>>>>>> acquired GoDSP (Code Composer), they've been pouring manpower and millions
>>>>>> into Win code-gen tools, not Linux. Which one do you think is more reliable
>>>>>> and widely used?
>>>>>>
>>>>>> -Jeff
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 24, 2008 at 2:21 AM, Richard Williams <
>>>>>> r...@lewiscounty.com> wrote:
>>>>>>>
>>>>>>> ittiam,
>>>>>>>
>>>>>>> from your description, it is rather obvious that some libraries are
>>>>>>> missing (assuming that the
>>>>>>> compile operations worked with no errors.)
>>>>>>>
>>>>>>> If you would post the names of the functions that are not found by
>>>>>>> the linker, we could possibly
>>>>>>> assist you in determing which libraries are missing.
>>>>>>>
>>>>>>> BTW:
>>>>>>> why are you using cgywin, etc rather than the CCS IDE for the
>>>>>>> compile/link operations?
>>>>>>>
>>>>>>> R. Williams
>>>>>>>
>>>>>>> ---------- Original Message -----------
>>>>>>> From: i...@gmail.com
>>>>>>> To: c...
>>>>>>> Sent: Mon, 23 Jun 2008 14:09:57 -0400
>>>>>>> Subject: [c6x] Urgent Help Required: CLK_gethtime
>>>>>>>
>>>>>>> > Hi all,
>>>>>>> >
>>>>>>> > Platform : DSK6416.
>>>>>>> > I have some problems regarding usage of BIOS with the header files
>>>>>>> ,all my source code are
>>>>>>> > compiled with Cygwin and TI C64x, this gives me the obj's which in
>>>>>>> turn i am linking using
>>>>>>> > the code composer, the problem is that i need to have this working
>>>>>>> with the BIOS
>>>>>>> > Clk_gethtime, if i use the function clk_gethtime with references of
>>>>>>> the libraries it says
>>>>>>> > that other references are missing, could anyone suggest me what are
>>>>>>> the header files that
>>>>>>> > need to be included to get the clk_gethtime working with proper
>>>>>>> references. How can i
>>>>>>> > start the bios if i cant use the GUI. Which are the header files
>>>>>>> that need to be
>>>>>>> > associated with it. The documentation regarding the Bios is very
>>>>>>> poor, it is not quite
>>>>>>> > clear about many aspects, if some one who had worked on BIOS could
>>>>>>> throw a limelight it
>>>>>>> > will be very helpfull for me .
>>>>>>> >
>>>>>>> > -BR
>>>>>>> > -Goku------- End of Original Message -------
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>>>
> --
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
> Start a New Thread

Goku,

On Tue, Jul 1, 2008 at 4:47 AM, Goku wrote:
> Hello ,
>
> HWI_15 is not tagged to the ISR routine, where in i am incrementing a static
> variable to get the ticks, as per my calculation an Interrupt should be
> triggered every 34.5 Sec and the variable should be updated at that
> instance, but it is not all going to the ISR function, could you please let
> me know how can i enable the ISR. I have this piece of code:
>
> TimerEventId1=TIMER_getEventId(hTimer1);
> IRQ_enable(TimerEventId1);
> TIMER_start(hTimer1);
>
> I can't tag HwI_15 to a ISR as given in the manual , reason being that it is
> not enabled, so i have marked HWI_4 for Timer1, but still it doesnt enter
> into the ISR routine, am i doing something wrong here, can u pls let me
> know.

Set a BP and check:
1. GIE set in CSR.
2. The interrupt is enabled in the IER
3. The interrupt service table [vector table] location needs to point
to the ISR. Check ISTP address [0 by default] and the table values in
memory.
4. You should be able to create a test interrupt by setting the bit in
the ISR [interrupt set register].

As I remember it, you are not using DSP/BIOS. Is this correct??
mikedunn

>
> Regards,
> Goku
>
> On Fri, Jun 27, 2008 at 5:09 PM, Michael Dunn
> wrote:
>>
>> Goku,
>>
>> On 6/27/08, Goku wrote:
>>>
>>> Hello Mike/ Jeff ,
>>>
>>> I did manage to configure the timer, but the profiler clock cycles never
>>> matches with that of the TIMER_count from the csl api, there is a huge
>>> amount of difference:
>>>
>>> I have configured the timer as follows : but not sure whether it is
>>> configured properly, don't know whether it is overflowing, since the cycle
>>> count always less than the PRD set value i.e 0xFFFFFFFF, i am not able to
>>> tell , regarding the increment of timer : I have calculated it like this :
>>> DSK 6416 has 1Ghz Processor, hence the 1 CPU clock period= 10exp -9 >>> 1/1Ghz.
>>> Timer Input Clock = 8* ( 1/1Ghz) ;
>>> Timer Period= 0xFFFFFFFF
>>> Timer Period for Timer1 Interrupt is = 0xFFFFFFFF * (1/1Ghz) * 8= 34.5
>>> Sec, Here i am not able to Configure HW_15 for ISR, which could call .
>> I suggest that you crawl, walk, and then run wrt to profiling. I do not
>> have time to analyze everything for you, but the following steps should
>> help.
>> 1. Get a basic understanding using a simple program. From main call a
>> function with a processing loop and a large count [something like a 1,000
>> cycle loop with a count of 100,000. I suggest that you run the program once
>> before measurements and then take each measurement twice - if you get a
>> large difference, take it 3 times.
>> 2. In main, time the loop from before the func call until after using the
>> timer. Don't worry about overflow yet, get the timer correct first. The
>> timer is not cycle accurate, but it will be very close [+/- a few cycles].
>> 3. From main, time the loop using the profile counter. This should be the
>> actual number of cycles [it will include some overhead] +/- 1.
>> 4. From main, set a GPIO pin before the func call and clear it after.
>> Measure this on a scope.
>> 5. All three of the above methods should be very close. Once they are,
>> you should be ready to take some 'real' measurements [if you use the timer,
>> lengthen the loop to overflow and debug the overflow detection].
>>
>>>
>>> Actually the code runs for about 3-4 minutes before it could print the
>>> Timer Counts, the TImer is started when the decoding starts in the code, and
>>> stops at the end of decoding.
>>>
>>> And the difference is printed out, which states the no of clock cycles
>>> used.
>>>
>>> Other Aspects : Config File is as follows.
>>>
>>> L2 Cache : Not Configured, ISRAM is configured with the L2 enabling. It
>>> says in the caching document that it is not preferred to run the code
>>> without L2,i am not sure about the L1 on chip, by default it is enabled ,
>>> could anyone tell me how much difference a L1 miss and a hit can cause to
>>> the cpu cycles consumed.
>> This will vary with program. For a simple or sequential program:
>> 1. Reset/flush cache
>> 2. Load, run program [= L1 'is empty']
>> 3. Restart, run program [= L1 'has repeatable cached entries']
>> 4. Restart, run program [= L1 'has repeatable cached entries']. Should be
>> similar to previous.
>> 5. Restart, run program [= L1 'has repeatable cached entries']. Should be
>> similar to previous.
>>
>> If you want the details, goto spru190 and it will point you to the doc on
>> c64 cache/internal memory.
>>>
>>> I am trying to find out the proper values for my application ( CPU cycles
>>> ) , If i manage to get the cycle count not varying too much then i could do
>>> some more experiments.
>> FYI - Some applications 'vary all over the place' in cycle count. The
>> 'GPIO method' is the 100% accurate [with almost no overhead] realtime
>> measurement.
>>>
>>> THis is an additional .cdb file since the heap required to run the
>>> application is more than ISRAM (1MB)
>>> SECTIONS {
>>> .bss: fill=0 {
>>> *(.bss)
>>> . += 0x4;
>>> } > ISRAM
>>>
>>> .far: {} > SDRAM
>>>
>>> .cinit: {} > ISRAM
>>>
>>> .pinit: {} > ISRAM
>>>
>>> .data: {} > ISRAM
>>>
>>> .switch: {} > ISRAM
>>>
>>> .cio: {} > ISRAM
>>>
>>> .text: {} > SDRAM
>>> .const: {} > SDRAM
>>>
>>>
>>> }
>>>
>>>
>>> When i mapped Stack on the SDRAM i am getting around 1420057808 * 8 CPU
>>> cycles, but when i map it against ISRAM i am getting more cycle count from
>>> the timer 3853073033 *8 ,both of them can't be compared to the profiler
>>> clock, does the profiler clock give out exact number of cpu cycles elapsed
>>> for running the entire program.? could you let me know,
>> The profiler clock measures from 'run' to 'halt' by reading a hardware
>> counter [I don't remember if it is 32 or 64 bits - I typically only use it
>> for single function measurements].
>>
>> mikedunn
>>>
>>> Initilization of Timer is done in this way, could you please let me know
>>> whether it is correct:
>>> Timer_start(hTImer1)
>>> start_time= Timer_getcount(hTimer1)
>>>
>>> Mp3 Decoding code
>>>
>>> stop_time= TImer_getcount(hTimer1)
>>>
>>>
>>> and the difference is printed out.
>>>
>>> In the GUI .cdb file, mentioned that the Input to the Timer is CPU/8
>>> rate, with reset before the start. and PRD set to max 0xFFFFFFFF.
>>>
>>> Do i have to tag HW_15 for any isr() ? i cant do it since in my code
>>> composer such option is disabled.
>>>
>>> Does the timer give out right values since the Interrupt is driven once
>>> in 34.5 Secs. Please explain since i am stuck at this point and i want to
>>> clarify why the variation in clock cycles is happening, and which procedure
>>> is correct to get the timer working and to get the same amount of clock
>>> cycles all the times.
>>>
>>> Regards,
>>> Goku
>>>
>>>
>>>
>>> On Thu, Jun 26, 2008 at 7:53 PM, Michael Dunn
>>> wrote:
>>>>
>>>> Goku,
>>>>
>>>> On 6/26/08, Goku wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I had configured the Timer as per Dunn, with the following
>>>>> configurations, and i am experiencing huge amount of clock cycle differences
>>>>> for the execution of the same code.
>>>>>
>>>>> Please Could any one of you explain the same,
>>>>>
>>>>> Code : MP3 Player.
>>>>>
>>>>> Result :
>>>>> Iterations = 1
>>>>> -- Target Duration = 1417161654 X 8 Clock Cycles - > CPU/8 config
>>>>> for the timer
>>>>>
>>>>> Iterations = 2
>>>>> -- Target Duration = 815201933 X 8 Clock Cycles - > CPU/8 config for
>>>>> the timer
>>>>>
>>>>>
>>>>> The same code was rerun after a successful reboot of the DSK 6416 and
>>>>> then i got the result for Iteration 2 which is almost half of the cycles
>>>>> taken for Iteration 1.
>>>>
>>>>
>>>> The very first pass will have nothing in L1 cache and you will get 100%
>>>> misses. Passes 2 and later should have similar times [assuming similat code
>>>> flow].
>>>>
>>>>>
>>>>> When i was using the debugger CCS Singles step i could see that the
>>>>> timer was overflowing in the timer register, even though i had set values
>>>>> set for PRD : FFFFFFFF , CNT -> Start with a Reset, Clk-: Tick= 1000
>>>>> Microseconds/Int, HWi_14 configured for Timer 0 , i could understand this
>>>>> behaviour .
>>>>
>>>>
>>>> The timer knows nothing about the CPU state and will not give reliable
>>>> numbers when you halt the DSP. If you want to manually profile a function,
>>>> use the 'profile clock' in CCS. It will update when you single step.
>>>> mikedunn
>>>>>
>>>>> Can anyone pls let me know why there is a huge variation in the clock
>>>>> cycles, all of my code resides in the SD RAM, and HWINIT_VEC are residing in
>>>>> the Internal memory.
>>>>>
>>>>> Regards,
>>>>> Goku
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 26, 2008 at 12:19 PM, Jeff Brower
>>>>> wrote:
>>>>>>
>>>>>> Goku-
>>>>>>
>>>>>>
>>>>>> I have included rts6400.lib, but it is not defined in it, am using CCS
>>>>>> 3.3 Version, still getting the same error ," not able to resolve the symbol
>>>>>> definition" .Could you let me know the details pls.
>>>>>>
>>>>>> _CLK_gethtime is defined in bios.a64, or similar depending on the DSP
>>>>>> type. I think it gets resolved to CLK_F_gethtime (function defined in asm
>>>>>> code). bios.a64 file is not an rtdx lib file; ignore my previous comment,
>>>>>>
>>>>>> Mike and Richard's suggestions about simpler ways to benchmark and
>>>>>> profile code are accurate and useful. You should try those. If for some
>>>>>> reason you still want to use _CLK_gethtime, then you have to use it together
>>>>>> with _CLK_getltime and also have to deal with issues of timer wrap-around
>>>>>> and interrupt enable/disable for _getltime. This doc has a good
>>>>>> explanation:
>>>>>>
>>>>>> http://focus.ti.com/lit/an/spra829/spra829.pdf
>>>>>>
>>>>>> -Jeff
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 24, 2008 at 5:21 PM, Jeff Brower
>>>>>> wrote:
>>>>>>>
>>>>>>> Goku-
>>>>>>>
>>>>>>>
>>>>>>> Since i am benchmarking different applications which are ported from
>>>>>>> linux, the linking is done with a makefile which has a huge code base, am
>>>>>>> using cygwin and CCS compiler, but not the IDE, target is connected to a
>>>>>>> different machine which has the CCS IDE, hence here i cant use the GUI
>>>>>>> interface, i dont know how could i use Clk_gethtime without the CCS IDE GUI
>>>>>>> Bios Start, could you pls let me know.
>>>>>>>
>>>>>>> CLK_gethtime should be in the basic run-time library, rts64xx.lib
>>>>>>> (not sure of that correct name, but look for rts64-something).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Error: _CLK_gethtime undefined symbol.
>>>>>>>
>>>>>>> I could see that Clk_gethtime library is missing , if i add the
>>>>>>> libraries like bios.a64 and others , they tend to say that there are many
>>>>>>> other symbols which are not defined.
>>>>>>>
>>>>>>> bios.a64 sounds to me like an RTDX library... nothing to do with
>>>>>>> CLK_xx functions.
>>>>>>>
>>>>>>> TI's code-gen tools for Linux are new and not widely used. I would
>>>>>>> suggest that you build using standard CCS v3.3 on a Win machine, and test
>>>>>>> that output code first. Since you have a "huge" code base, it's a good idea
>>>>>>> to eliminate any possible build error, library version, link error, etc.
>>>>>>>
>>>>>>> Think about it this way -- TI didn't have Linux based code-gen tools
>>>>>>> until recently (last couple of years). So that means since 1996, when they
>>>>>>> acquired GoDSP (Code Composer), they've been pouring manpower and millions
>>>>>>> into Win code-gen tools, not Linux. Which one do you think is more reliable
>>>>>>> and widely used?
>>>>>>>
>>>>>>> -Jeff
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 24, 2008 at 2:21 AM, Richard Williams
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> ittiam,
>>>>>>>>
>>>>>>>> from your description, it is rather obvious that some libraries are
>>>>>>>> missing (assuming that the
>>>>>>>> compile operations worked with no errors.)
>>>>>>>>
>>>>>>>> If you would post the names of the functions that are not found by
>>>>>>>> the linker, we could possibly
>>>>>>>> assist you in determing which libraries are missing.
>>>>>>>>
>>>>>>>> BTW:
>>>>>>>> why are you using cgywin, etc rather than the CCS IDE for the
>>>>>>>> compile/link operations?
>>>>>>>>
>>>>>>>> R. Williams
>>>>>>>>
>>>>>>>> ---------- Original Message -----------
>>>>>>>> From: i...@gmail.com
>>>>>>>> To: c...
>>>>>>>> Sent: Mon, 23 Jun 2008 14:09:57 -0400
>>>>>>>> Subject: [c6x] Urgent Help Required: CLK_gethtime
>>>>>>>>
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > Platform : DSK6416.
>>>>>>>> > I have some problems regarding usage of BIOS with the header files
>>>>>>>> > ,all my source code are
>>>>>>>> > compiled with Cygwin and TI C64x, this gives me the obj's which in
>>>>>>>> > turn i am linking using
>>>>>>>> > the code composer, the problem is that i need to have this working
>>>>>>>> > with the BIOS
>>>>>>>> > Clk_gethtime, if i use the function clk_gethtime with references
>>>>>>>> > of the libraries it says
>>>>>>>> > that other references are missing, could anyone suggest me what
>>>>>>>> > are the header files that
>>>>>>>> > need to be included to get the clk_gethtime working with proper
>>>>>>>> > references. How can i
>>>>>>>> > start the bios if i cant use the GUI. Which are the header files
>>>>>>>> > that need to be
>>>>>>>> > associated with it. The documentation regarding the Bios is very
>>>>>>>> > poor, it is not quite
>>>>>>>> > clear about many aspects, if some one who had worked on BIOS could
>>>>>>>> > throw a limelight it
>>>>>>>> > will be very helpfull for me .
>>>>>>>> >
>>>>>>>> > -BR
>>>>>>>> > -Goku------- End of Original Message -------
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>>
>> --
>> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread