Forums

profile / view clock working with c33 and Code composer ?

Started by frederic_terrettaz August 13, 2003
Hi,

Have somebody use the profile/view clock of code composer 4.10.37
with c33 (and the black hawk usb2.0 emulator) ?

When I display the variable CLK in the watch window, I see it
changing but its value is increasing at a too slow rate.

It is unusable for one who want to do accurate benchmark.

Which 'trick' use code composer to update the CLK value ? Do it use
the internal DSP timer divide by a magic constant ?

Thanks to answer.

Fred



Hi Fred

I am not sure *exactly* how the JTAG emulator 'clock' works so your best bet
would be to contact Black-Hawk. I can however possibly provide an alternative.

Any one of the four internal timers (TCLK0, TCLK1, CLKX, CLKR -serial port)
can be used to get cycle accurate results, even though these timers are
clock on 2-cycle boundaries. The basic idea is to read and then add the
timer count on two consecutive cycles, essentialy doubling the timer count
(desired) and simultaneously catching any possible transitions.

The DSK tools use this concept to create a delta time parameter in the CPU
context area called '_dT'. Converting this to C, we would get something
like the following (that is, I did not test this!).

Hope this helps
Keith Larson

;---------------------
; Function: long GetTimer0(void);
;
; Returns : Cycle accurate timer count
; Comments: Timer comparisons (benchmarking) requires the
; timer period to be greater than the event being timed.
; Also, the timer count should not roll over during this
; time. Setting count to zero is a possible solution
;---------------------
_GetTimer0 pop R0 ; Fast return using BUD
bud R0 ;
LDI @TCLK0_count,R0 ; get timer count
ADDI @TCLK0_count,R0 ; add timer count, and possible transition
nop ;

void main(void)
{
long Offset, BM;
//
InitTimer0(LongPeriod);
//
Offset =GetTimer0(); // Determine timer function offset
Offset-=GetTimer0(); // constant for this system
//
for(;;)
{
BM = GetTimer0(); // get base time
//
BenchmarkCode(); // run benchmark code
//
BM = GetTimer0()- BM - Offset; // Benchmark time in cycles
}
} --
At 09:59 PM 8/13/03 -0000, you wrote:
Hi,

Have somebody use the profile/view clock of code composer 4.10.37 with c33
(and the black hawk usb2.0 emulator) ?

When I display the variable CLK in the watch window, I see it changing but
its value is increasing at a too slow rate.

It is unusable for one who want to do accurate benchmark.

Which 'trick' use code composer to update the CLK value ? Do it use the
internal DSP timer divide by a magic constant ?

Thanks to answer.

Fred
+-----------+
|Keith Larson |
|Member Group Technical Staff |
|Texas Instruments Incorporated |
| |
| 281-274-3288 |
| |
| www.micro.ti.com/~klarson |
|-----------+
| TMS320C3x/C4x/VC33 Applications |
| |
| TMS320VC33 |
| The lowest cost and lowest power 500 w/Mflop |
| floating point DSP on the planet! |
+-----------+


Keith,

That 's a good idea. It make you independant of the erratic behaviour of CC.

Now I start the timer with a function and then I use a watch windwow with
*(0x808024) wich is the timer 0 counter value of the C3x

Thanks for your help

Fred
----- Original Message -----
From: Keith E. Larson
To: frederic_terrettaz ;
Sent: Tuesday, August 19, 2003 12:28 PM
Subject: Re: [c3x] profile / view clock working with c33 and Code composer ? Hi Fred

I am not sure *exactly* how the JTAG emulator 'clock' works so your best bet
would be to contact Black-Hawk. I can however possibly provide an
alternative.

Any one of the four internal timers (TCLK0, TCLK1, CLKX, CLKR -serial port)
can be used to get cycle accurate results, even though these timers are
clock on 2-cycle boundaries. The basic idea is to read and then add the
timer count on two consecutive cycles, essentialy doubling the timer count
(desired) and simultaneously catching any possible transitions.

The DSK tools use this concept to create a delta time parameter in the CPU
context area called '_dT'. Converting this to C, we would get something
like the following (that is, I did not test this!).

Hope this helps
Keith Larson

;---------------------
; Function: long GetTimer0(void);
;
; Returns : Cycle accurate timer count
; Comments: Timer comparisons (benchmarking) requires the
; timer period to be greater than the event being timed.
; Also, the timer count should not roll over during this
; time. Setting count to zero is a possible solution
;---------------------
_GetTimer0 pop R0 ; Fast return using BUD
bud R0 ;
LDI @TCLK0_count,R0 ; get timer count
ADDI @TCLK0_count,R0 ; add timer count, and possible transition
nop ;

void main(void)
{
long Offset, BM;
//
InitTimer0(LongPeriod);
//
Offset =GetTimer0(); // Determine timer function offset
Offset-=GetTimer0(); // constant for this system
//
for(;;)
{
BM = GetTimer0(); // get base time
//
BenchmarkCode(); // run benchmark code
//
BM = GetTimer0()- BM - Offset; // Benchmark time in cycles
}
} --
At 09:59 PM 8/13/03 -0000, you wrote:
Hi,

Have somebody use the profile/view clock of code composer 4.10.37 with c33
(and the black hawk usb2.0 emulator) ?

When I display the variable CLK in the watch window, I see it changing but
its value is increasing at a too slow rate.

It is unusable for one who want to do accurate benchmark.

Which 'trick' use code composer to update the CLK value ? Do it use the
internal DSP timer divide by a magic constant ?

Thanks to answer.

Fred
+-----------+
|Keith Larson |
|Member Group Technical Staff |
|Texas Instruments Incorporated |
| |
| 281-274-3288 |
| |
| www.micro.ti.com/~klarson |
|-----------+
| TMS320C3x/C4x/VC33 Applications |
| |
| TMS320VC33 |
| The lowest cost and lowest power 500 w/Mflop |
| floating point DSP on the planet! |
+-----------+

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you want
your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join: Send an email to

To Post: Send an email to

To Leave: Send an email to

Archives: http://groups.yahoo.com/group/c3x

More Groups: http://www.dsprelated.com


Hi Fred

You need a watch on the *difference* of the two returned timer values, not
the timer itself since the timer itself is free running.

I suppose you could reset/start then stop the timer and then watch the timer
directly, but the timer value itself only ticks once every two cycles so you
cant (at least directly) get a single cycle accurate timing. Basically you
would need to double the timer count, resulting in times that are modulo two.

The trick that I was presenting is that by adding two consecutive timer tick
counts, you

a) Effectively double the timer count
b) Optionally capture the timer transition

The very interesting part of this is that the resulting 2x+transition time
becomes single cycle accurate. All you need to do is account for (EG
subtract) any constant offsets that are introduced by the calling of the
timer sampling routine.

BTW, I found this rather accidentally when trying to do benchmarking in the
early DSK debugger. After getting past the initial surprise, I eventually
figured it out.

As a side note on this new DSK debugger, I changed how watch expressions and
watch windows work. I basically noted that watches come in two types.
Global variables that eventually evaluate to locations in .bss constant
storage memory, and local variables that also evaluate to locations in
memory, but this time in the C call stack.

1) A watch expression for a specific memory location or value
can be entered in the command window. Then, on each emulation
halt (screen repaint) the command window is re-evaluated and
the text following the watch expression modified
->> USING THE COMMAND WINDOW MEANS NO WATCH WINDOW WAS NEEDED <<-

2) Global variables (and there symbols) are rather easily viewed
using a memory window opened up with its initial address set
to the beginning of .bss

3) Local variables, and the C call stack, are displayed using a
specialized memory window that calculates its start address
from the stack/frame pointer. I then display symbol names
relative to the frame, regressing the frame down to main.
By colorizing the call stack for each function level, you can
now see how variables are passed on the stack!

4) I also track the variable type as fixed or float and modify
the memory window display accordingly (as long as the type
is auto and not something else like hex, binary or Q format).

5) The CPU registers are also saved in memory on each EMU halt.
As you can guess, the CPU register window is yet again another
specialized memory window.

I have shown this to a few people in the TI Code Composer tools development
group and they seem to like the idea. Maybe they will adopt this idea.
After all, the DSK tools were also the first tools to offer ASM source
tracking, among a few other neat things.

Best regards,
Keith Larson
---------
At 11:55 AM 8/20/03 -0400, you wrote:
Keith,

That 's a good idea. It make you independant of the erratic behaviour of CC.

Now I start the timer with a function and then I use a watch windwow with
*(0x808024) which is the timer 0 counter value of the C3x

Thanks for your help

Fred
----- Original Message -----
From: Keith E. Larson
To: frederic_terrettaz ;
Sent: Tuesday, August 19, 2003 12:28 PM
Subject: Re: [c3x] profile / view clock working with c33 and Code composer ?

Hi Fred

I am not sure *exactly* how the JTAG emulator 'clock' works so your best bet
would be to contact Black-Hawk. I can however possibly provide an alternative.

Any one of the four internal timers (TCLK0, TCLK1, CLKX, CLKR -serial port)
can be used to get cycle accurate results, even though these timers are
clock on 2-cycle boundaries. The basic idea is to read and then add the
timer count on two consecutive cycles, essentialy doubling the timer count
(desired) and simultaneously catching any possible transitions.

The DSK tools use this concept to create a delta time parameter in the CPU
context area called '_dT'. Converting this to C, we would get something
like the following (that is, I did not test this!).

Hope this helps
Keith Larson
;---------------------
; Function: long GetTimer0(void);
;
; Returns : Cycle accurate timer count
; Comments: Timer comparisons (benchmarking) requires the
; timer period to be greater than the event being timed.
; Also, the timer count should not roll over during this
; time. Setting count to zero is a possible solution
;---------------------
_GetTimer0 pop R0 ; Fast return using BUD
bud R0 ;
LDI @TCLK0_count,R0 ; get timer count
ADDI @TCLK0_count,R0 ; add timer count, and possible transition
nop ;

void main(void)
{
long Offset, BM;
//
InitTimer0(LongPeriod);
//
Offset =GetTimer0(); // Determine timer function offset
Offset-=GetTimer0(); // constant for this system
//
for(;;)
{
BM = GetTimer0(); // get base time
//
BenchmarkCode(); // run benchmark code
//
BM = GetTimer0()- BM - Offset; // Benchmark time in cycles
}
}
--
At 09:59 PM 8/13/03 -0000, you wrote:
Hi,
Have somebody use the profile/view clock of code composer 4.10.37 with c33
(and the black hawk usb2.0 emulator) ?

When I display the variable CLK in the watch window, I see it changing but
its value is increasing at a too slow rate.

It is unusable for one who want to do accurate benchmark.

Which 'trick' use code composer to update the CLK value ? Do it use the
internal DSP timer divide by a magic constant ?

Thanks to answer.
Fred
+-----------+
|Keith Larson |
|Member Group Technical Staff |
|Texas Instruments Incorporated |
| |
| 281-274-3288 |
| |
| www.micro.ti.com/~klarson |
|-----------+
| TMS320C3x/C4x/VC33 Applications |
| |
| TMS320VC33 |
| The lowest cost and lowest power 500 w/Mflop |
| floating point DSP on the planet! |
+-----------+