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.

Clock Profiler Question

Other Parts Discussed in Thread: OMAP-L137

Hi,


I am working with the AudioSample project  on the OMAP-L137/C6747 EVM and I am having trouble understanding some observations I have made using the clock profiler on this program. I am using the profiler by placing a breakpoint in the infinite loop within this code in order to judge the number of cycles taken by one execution of this loop.

The first thing I noticed is that using the default number of buffers (four), the number of cycles varies greatly between each execution. While most executions will take maybe 200,000 clock cycles, some will take several million. This is fixed by reducing the number of buffers to 2, but I still do not understand what is causing this change.


The second thing I noticed is that the number of clock cycles this loop takes is unaffected by the sampling frequency I choose. My current understanding is that the clock profiler will tell me the number of clock cycles between two breakpoints, however if this is the case, I would expect each execution of this loop to require the number of clock cycles it takes to sample the data which by my calculations would be ~108.8k clock cycles =(16 * 3*10^8)/44,100. Instead each execution takes ~40k clock cycles, and this value is unchanged when I reduce the sampling frequency to 8k.

I am new to CCS and believe both problem could stem from a simple misunderstanding I have regarding the operation of the clock profiler, but I have been able to find answers to these questions in my research so far. Any information that could improve my understanding would be greatly appreciated.

Thanks,

Alan
 

  • Alan,

    Sorry, it seems your thread slipped from the radar screen. Are you still having the reported issue?

    Regards,

    Rafael

  • I have not yet been able to figure out what is causing the behavior described in my initial post. However since I posted  this question I have made several changes to my code, so neither of the issues I posted above are currently presenting any problems to me at this moment. Any insight you could provide me on these issues may prove helpful to me in my future work on this project, however it is not fundamental to my current work.

    Regards,

    Alan

  • Alan,

    Since I don't have the same setup/code as you, I can only make some assumptions.

    I imagine the different cycle count when using a large number of buffers may be due to cache hits/misses, as the cache is limited in size and a flush will sevrely impact the performance. Also, the larger buffer will naturally take longer to process, therefore increasing the chances of an interrupt (or interrupts) happen during the execution of the routine under scrutiny. 

    Regarding the second scenario, unfortunately I can't necessary pinpoint a plausible explanation, as it is dependent on the processing routine or on how the data is being fed to the buffers (via DMA, for example). For example, if the time spent for the incoming data is very small when compared to the actual processing, the cycle counts would be very similar. Again, this is a guess as I am not looking at your system.

    In any case, please feel free to write back if you see any strange behaviour.

    Regards,

    Rafael