#Counting Cycles#
##Overview##
There are a number of different ways to measure performance. Some devices offer advanced trace capabilities which often requires the of an advanced debug probe or trace receiver. The vast majority of TI devices provide a quick and easy way to count cycles.
One devices you can use the Profile Clock for this and on other devices you can make use of a "Count Event". This article will cover both methods.
##Count Event##
On devices such as those that contain an ARM Cortex core there are counters on the device that can be used to count cycles.
###Setting up a Count Event###
To create a Count Event open the **Breakpoints View**. This can be done by going to the menu and selecting ***View -> Breakpoints***.
Click on down arrow beside the new breakpoint button and select ***Count Event*** as the breakpoint type.
![](./images/new_count_event.png)
Then select **Clock Cycles** as the event.
![](./images/count_event_clock_cycles.png)
The **Breakpoints View** will now show the event and its value.
![](./images/breakpoints_view_count_event.png)
###Reset the Count###
You can reset the count by right clicking on the event and selecting **Reset Counter**. The value shown in the **Breakpoints View** may not immediately change but it the value stored in the hardware counter is cleared.
###Measure cycles###
Follow this procedure to measure cycles between two lines of code:
-create a **Count Event** as shown above
-set breakpoints at the lines between which you want to measure the cycle count
-run to the first breakpoint
-reset the counter
-run to the second breakpoint
-the count event will display the cycle count between those two points in the code
##Profile Clock##
###Enable the Profile Clock###
In the Debug perspective go to the menu and select ***Run -> Clock -> Enable***. This will add a clock icon and count to the status bar at the bottom of Code Composer Studio. You may have to do this each time you restart the debugger.
![](./images/profile_clock.png)
###Configuring the Profile Clock###
Depending on the device the Profile Clock can be configured to count a number of events. In the debug perspective go to the menu and select ***Run -> Clock -> Setup***. This will open up the Clock Setup dialog.
![](./images/profile_clock_setup.png)
The **Count** field allows you to specify the event you want to count. Typically you will select "Cycles".
The **Reset Option** determines how the clock value is accumulated. If you select the "Manual" the clock variable accumulates counts without resetting the clock. If you select the "Auto" the clock variable is automatically reset to 0 before running or stepping the target processor. Therefore the clock only displays the count since the last run or step.
###Reset the Clock###
Double-click on the clock value in the status bar to reset the count to 0
###Measure cycles###
Follow this procedure to measure cycles between two lines of code using Profile Clock:
-enable the Profile Clock and configure it to count cycles
-Set breakpoints at the lines between which you want to measure the cycle count
-run to the first breakpoint
-double-click on the Clock in the status bar to reset its value or, if you use the Auto Reset Option, this step can be skipped.
-run to the second breakpoint
-the clock will display the cycle count between those two points in the code
##Considerations##
###Convert Cycles to actual time###
The profile clock displays the direct CPU cycle count, therefore its value must be multiplied by 1/CLK to convert it to seconds.
For example, if the target is running at 300MHz and the Profile clock cycle count for a routine is 1000, then the time consumed by the routine would be:
1000 * (1/300,000,000) = 3.3 μs
###Interrupts###
If the software under evaluation contains interrupt requests, keep in mind that the cycle count may increase significantly if an interrupt is serviced in the middle of the region under evaluation.
###External Memory###
Some cores have a 1:1 relationship between the clock and the CPU cycles, therefore a simple instruction like NOP located in internal memory should just jump one unit in the counter. However, if the code is located in external memory the CPU will have to wait several cycles until the instruction is fetched to its internal pipeline (caused by waitstates and stalls), this translates to additional clock cycles measured by the Profile clock.
###Other###
Certain instructions require additional CPU cycles to complete their execution if they access memory (MOV, PUSH/POP, etc.), jump to other parts of the code (B, JNE, etc.) or do not execute at all (conditional instructions in the C6000 ISA, for example).
For the instructions that access memory, keep in mind that other peripherals (DMA, HPI) or cores (in case of SoC devices) may be accessing the same region at the same time, which will cause a bus contention and make the CPU wait until it is allowed to fetch the data/instruction.