Abhishek-
> Thanks a lot for your timely support.
>
> By using the Run Free option from Debug and toggling GPIO pin I was able
> to get the exact decoding timings which were matching the expectations.
Ok great. Good luck on the project.
-Jeff
>>>-----Original Message-----
>>>From: c... [mailto:c...] On Behalf Of
> Jeff
>>>Brower
>>>Sent: Thursday, November 02, 2006 12:19 AM
>>>To: Abhishek Dixit
>>>Cc: c...
>>>Subject: Re: [c6x] Cycle count measurement not matching with real time
>>>behaviour
>>>
>>>Abhishek Dixit-
>>>
>>>> I am working on a video decoding algorithm on TMS320C6416 DSK at 600
>>>> MHz.
>>>>
>>>> On enabling and viewing the clock while profiling it is found that
> it
>>>> takes nearly 20 Mega Cycles for single frame decoding.
>>>> But real time taken for single frame decoding when profiling enabled
>>>> comes in few seconds.
>>>>
>>>> When I disable the clock it is found that it decodes 3 frames per
> second
>>>> even though CPU clock is supposed to be at 600 MHz.
>>>> I have checked CLKMODE0 and CLKMODE1 pins which are at 0 and 1
>>>> respectively.
>>>>
>>>> Can somebody help me why real time for decoding is coming much
> higher
>>>> than expected?
>>>> We should be able to decode 30 frames per second. But we are getting
>>>> only 3 frames and on enabling clock it becomes less than a frame per
>>>> second.
>>>> What could be the possible reasons for such mismatch between cycle
> taken
>>>> for decoding and elapsed time?
>>>> Or is there anything wrong with the cycle measurement itself?
>>>
>>>Profiling consumes 64x CPU resources, as does any RTDX communication
> with
>>>the host.
>>>The point of profiling is to learn which code takes what amount of
> time
>>>relative to
>>>other code. I think of it as "percentage execution time". If you
> want
>>>fastest
>>>real-time performance, all host I/O (printf, logprintf, getch, etc)
> has to
>>>be turned
>>>off, all RTDX has to be off, and "Run Free" should be selected in the
> CCS
>>>Debug
>>>menu. In that case, if you need to measure specific processing
> intervals
>>>(like why
>>>certain decode functions are still running too slow), then you can use
> an
>>>onchip
>>>timer (TIMER1, manually) or add DSP code to toggle GPIO lines at
> start/end
>>>of "code
>>>of interest" and measure those lines on a dig scope.
>>>
>>>-Jeff
RE: Cycle count measurement not matching with real time behaviour
Started by ●November 3, 2006
