NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
Trace Functionality And Capabilities
Contents
Trace Functionality And Capabilities[edit]
Overview[edit]
This page will give an overview of the functionality and capabilities provided with XDS560 Trace. It is meant to describe the low level trace functionality in order to give the user an idea of the raw capabilities. There are two different types of trace, Standard Trace and Event Trace. Standard Trace gives the user the capability to decide what types of data should be captured, and to configure Advanced Event Triggering to specify where in the application execution trace data should be captured. Event trace is slightly different. Event trace essentially allows the user to capture a snapshot of the CPU execution, injected with marks indicating a number of various events.
Trace Capture Modes[edit]
Stop on buffer full[edit]
When trace is configured for stop on buffer full, trace data is captured as it is provided until the trace capture buffer is full. Once it is full, the trace receiver will automatically stop trace capture. When the buffer is decoded, it will contain the first N instructions that were executed by the application.
Circular buffer[edit]
When trace is configured for a circular buffer, once the trace buffer is filled it will wrap with the latest data overwriting the oldest data remaining in the buffer. When trace capture is stopped, and the buffer is decoded, it will contain the last N instructions that were executed by the application.
Standard Trace[edit]
Standard Trace provides export of PC, Timing and processor Data accesses. Complex triggers (AET) provide control over trace combinations that limit the trace data exported to just the data (PC, Timing or Data) needed to provide visibility to the problem. Examples are:
- PC plus Timing from start of execution
- - This can be accomplished with a single Trace On job with PC and Timing data selected to trace.
- PC plus Timing in a range (specific function or loop)
- - This can be accomplished with a single Trace in Range job with the function or loop addresses used to define the range, with PC and Timing data selected to trace.
- PC plus Timing from a Start Trigger PC address to an End Trigger PC address (same as a Trace In Range).
- - This can be accomplished with two trace jobs, one for the Start Trace trigger with PC and Timing selected to trace, and then one for the End Trace trigger with just the PC selected. We don't enable timing in the End Trace job so we can trace the number of cycles that executed between the End Trace trigger address and the next Start Trace trigger address. If we were to select the timing stream in the End Trace job, the next time the Start Trace trigger job enables trace the timing data will start from where it left off (the timing stream is made up of delta timing only) making it appear the PCs where executed in consecutive cycles.
- PC plus all data reads or writes of a specific location or memory range
- - Note that this can be accomplished with two trace jobs, one using Trace On to trace PC and Timing, and a Store Sample Job at the specific memory point eanbled for reads or writes with read/write addresses and/or memory read/write data enabled along with PC with Data selected for tracing. To see both reads and writes at the same location or different locations you need to setup two Store Sample Jobs, one for reads and one for writes.
- All PCs that write a specific memory location or memory range
- - You just need a single Store Trace job set for a single write address or range of writes with PC and Timing selected for trace. If you want to also see the data associated with the write simply select data address and data writes for tracing.
Trace Streams[edit]
- PC Trace (Program Trace)
- PC Trace allows the user to capture the execution flow of their application. When enabled every program counter change is captured.
- Timing Trace
- By itself, timing trace is not useful. But in conjunction with PC or Data trace, it allows the user to capture a time stamp with every piece of trace data that was captured. This will give a point of reference to the time between executed instructions, memory accesses and visibility into where stalls may be occurring.
- Data Trace
- Data Trace monitors activity on the processor's memory address and data buses, providing visibility to where memory read/writes are occurring and what the values being read/written are. Note: Data Trace only provides visibility into memory accesses that originate with the processor. Data Trace cannot provide direct visibility to processor Register Reads/Writes, or memory accesses that originate with other modules such as DMA Reads/Writes, HPI reads/writes, etc.
- Read Address
- Read Address Trace captures activity on the data address bus for read operations.
- Read Data
- Read Data Trace captures activity on the data bus for read operations
- Write Address
- Write Address Trace captures activity on the data address bus for write operations.
- Write Data
- Write Data Trace captures activity on the data bus for read operations
- Read Address
- Data Trace monitors activity on the processor's memory address and data buses, providing visibility to where memory read/writes are occurring and what the values being read/written are. Note: Data Trace only provides visibility into memory accesses that originate with the processor. Data Trace cannot provide direct visibility to processor Register Reads/Writes, or memory accesses that originate with other modules such as DMA Reads/Writes, HPI reads/writes, etc.
Useful Tip There is also a PC with Data option that is a data stream configuration option. It allows the program address to also be captured when any data trace samples are captured. So, rather than simply recording the address or data that was read/written, the output also contains the program address of the instruction that performed the read/write. PC with Data is only useful with Data Trace. This option is also referred to as PCTag. |
Warning:
Trace Triggers[edit]
Trace Data is captured based on triggers generated by the Advanced Event Triggering (AET) unit (see AET Logic Unit for details). There are a number of different types of triggers that can be used to capture trace data. The triggers are chosen based on how the data should be captured. The triggers are generated based on combinations of events that are specified in the AET unit. Each of the triggers can be generated
Start Trace Trigger[edit]
- The Start Trace trigger works like turning on a switch. When the Start Trace trigger is generated, the trace stream will continue to be active until another trigger is generated to turn the stream off. If the event that generated the Start trigger ceases to be active, trace data will continue to be captured. If the streams are already enabled, additional Start Trace triggers for those streams will have no effect.
Start Trace Trigger Example
Start PC, Timing trace when PC = "main"
When the application is run, PC and timing trace will be turned on whenever the program address is equal to the address of "main". From then on, PC and Timing data will be captured for every executed instruction until either a) The trace buffer is full (Halt on Buffer Full mode), b) the application is halted or c) End PC/Timing trace triggers are generated.
End Trace Trigger[edit]
- The End Trace Trigger works in the opposite manner of the Start Trace Trigger. When the End Trace trigger is generated, it will turn off the specified trace stream. An End Trace trigger genenerated without a corresponding trace stream already running has no effect.
End Trace Trigger Example
Start PC, Timing trace when PC = "func1" End PC trace when PC = "func2"
In this example, when the address of symbol func1 is encountered for the first time in the execution, Trace will begin capturing PC and timing data. If "func2" is encountered before "func1", it has no effect because the PC trace stream has not yet been turned on. Generating an End PC trace trigger when PC trace is not currently on has no effect. Once "func1" has been encountered, and trace has started, it will capture PC and Timing data until we encounter the address of "func2". Once we have encountered "func2", the PC trace stream will be turned off. Note however, that we didn't specify ending the timing trace stream. So this stream will continue to run. In effect, it will keep counting CPU cycles even while we are not capturing PC trace information.
If, during the course of application execution, "func1" is called again, the PC trace stream will again be turned on. The Start Timing trace trigger will have no effect because the timing trace stream is still on from the initial call of "func1". The effect of keeping the timing stream enabled while PC trace was not being captured will be obvious in the results data. When func2 is encountered for the first time, trace will capture that instruction, and then subsequently stop capturing PC trace data. The last instruction captured will be assigned a cycle count. For the purpose of this example, let's say the value is 10,000. If the timing stream were turned off with the PC stream, then the cycle count attached to the 2nd execution of "func1" would be 10,001, as if there were no time delay between the two. But if we allow the timing data to continue execution, the 2nd execution of "func1" will show a cycle count that reflects the time delay between executing "func2" the 1st time and executing "func1" the 2nd time. For example, the value might be 18000, meaning that 8000 cycles elapsed between the first call of "func2" and the 2nd call of "func1".
Store Trace Sample Trigger[edit]
- Where the behavior of the Start Trace Trigger and Stop Trace Trigger could be considered analogous to turning a normal light switch on and off, the behavior of the Store Trace Sample trigger can be considered analogous to a normally open push-button switch. In the case of the push button switch, when the button is pushed, the light comes on. And when the button is released, the light goes off. So it is for the Store Trace Sample Trigger. When the events that are configured to trigger the event is high (active), trace samples are captured. When the same events go low (inactive) trace will no longer capture data
Store Trace Sample Example
Store Read Data Trace Sample when 0x800000 <= Read Address <= 0x800010.
When the application goes to read any piece of data to memory, trace will be turned on when the address of that reads in the specified range. When a read instruction occurs, and the address is outside of the specified range, trace will not capture that read data because the trigger event logic is no longer active.
Consider an instance where two data reads occur in parallel. If one of those reads is inside the specified range, and the other is outside of the specified range, Trace will actually capture both data values. The triggering logic only specifies when to turn the trace stream on and off. Trace will then (attempt to) capture all of the data in that stream. There is no way to filter the additional values out of the trace stream. |
Suspend Trace Trigger[edit]
- The Suspend Trace Trigger will temporarily turn off a combination of the three trace streams (PC/Timing/Data). When the logic of the trigger builder is true, the designated trace stream is turned off for as long as the logic remains in the true state. When the logic goes false again, the trace stream is re-enabled.
Suspend Trace Example
Do NOT trace when 0x08000000 <= Program Address <= 0x08010000
This use case actually requires a pair of triggers. Some trigger needs to initially turn the AET capture of trace on. Assume that we have created one Trace job that starts capturing PC and Timing trace whenever the program address of MAIN is encountered. The second trigger could be used to suspend Program Trace whenever the Program Address value is in the designated range. In this manner, any PC execution between 0x8000000 and 0x8010000 would be neglected, but the timing stream would continue to run. When the execution of the application resumed outside of the specified range, trace capture would then resume. Because the timing stream was not suspended, the trace output would indicate a difference in cycle count based on the length of execution of the code between 0x08000000 and 0x08001000.
Trace Marker Trigger[edit]
- Insert a marker into the trace stream. The resulting data display will show where the marker was generated. The trace marker works in somewhat of a one-shot fashion. Once the trigger has been generated, it will not trigger again until the trace marker has been cleared. When using trace through the CCS plugin, this will be done when trace is restarted.
Trace Marker Example
Insert Trace marker at the point where Interrupt 9 occurs for the first time
This use case would work in conjunction with a PC trace capture. The PC trace data would show where the first instance of interrupt 9 occurred. This could potentially be used to check for interrupt latency.
End Trace Trigger[edit]
- The End Trace Trigger is the highest priority trigger. It will stop all trace streams.
Trace Jobs[edit]
A Trace Job is essentially a configuration logically connecting a combination of inputs to the AET Block to a specified output trigger, or set of output triggers. In the AET Logic High Level View Diagram, a Trace Job designates the connections made from the event Generation signals to the Event Combination logic known as a Trigger Builder. The trace job also defines the logic in the Event Combiner that determines the combination of the four inputs that causes an output to be generated.
In the Code Composer Studio UBM, there are a number of semi-configured jobs provided. A job can be selected based on the scenario that is desired, and then the specific details can be configured. Each provided job is detailed below. In each scenario, the type of data to be captured can also be selected.
- Trace On
- A Trace On Job essentially generates a Start Trace trigger for the specified trace streams immediately. If the CPU is halted at main, and a Trace On job is configured, Trace will capture execution beginning at the main statement. It will continually capture the enabled streams until the streams are turned off by a End All Trace job, or the buffer fills. A Trace On job can not be terminated with a End Trace job because Trace On is persistent. Trace On jobs are typically used with PC/Timing Trace Streams. They are not typically useful for Data Streams due to bandwidth limitations.
- Start Trace
- A Start Trace Job is similar to the Trace On Job, but is slightly different. Where the Trace On job started trace immediately, regardless of what was going on in the application, the Start Trace job allows the user to specify a PC that triggers tracing. A Start Trace job essentially turns on one or more of the trace streams, and they remain on. If a Trace Stream is already on, the Start Trace trigger has no effect. Start Trace jobs are typically used with PC/Timing Trace Streams. They are not typically useful for Data Streams due to bandwidth limitations. A Start Trace job is not persistent, meaning the trace streams started with a Start Trace job can be turned off with a End Trace job. After a End Trace job is triggered, a Start Trace job can trigger trace to start again.
- End Trace
- An End Trace Job is analogous to a Start Trace job, except with the opposite behavior. It will turn off the specified trace streams. Creating an End Trace job without a corresponding Start Trace will have no effect, as none of the trace streams will ever get turned on.
- Trace In Range
- A Trace In Range job allows the user to specify a range of PC addresses in which to capture Trace Data. One use case might be to capture Trace Data only in a specified function. The selected Trace Streams are turned on when the program address is within the specified range, and are turned off when the program address is outside that range. Trace in Range jobs can be useful with PC and Data Trace Streams.
- Don't Trace In Range
- A Don't Trace In Range job is the opposite of a Trace in range job. A range is specified in the same way, except the logic is inverted. When the program address is within the range, the trace streams are turned off. When the program address is outside the range, the streams are turned on. Don't Trace in Range jobs can be useful with PC and Data Trace Streams.
- Trace Variable
- A Trace Variable job is quintessential data trace. It allows the user to specify a variable, and allows trace to capture all reads and/or writes to that specific variable. Trace Variable jobs are typically useful with Data Trace streams.
- Store Sample
- A Store Sample job is basically a less restrictive version of the Trace Variableor Trace in Range jobs. Where the Trace Variable job limits it's active scope to occasions where a specific memory location is read or written, a Store Sample job allows the user to set the parameters for when the trace streams are active or inactive. Some possibilities are when a range of addresses is read or written to or when an event or set of events occur. These jobs can be useful with both PC and Data Trace
- Don't Store Sample
- A Don't Store Sample job typically works in conjunction with a Start Trace or Trace On job. One of these jobs is used to start capturing trace data. A Don't Store Sample job is used to suppress the trace capture during a specific set of conditions.
- Insert Trace Marker
- An Insert Trace Marker job is typically used with PC trace and a Trace On or Start Trace job. One of these two jobs will typically start trace, and the Insert Trace Marker job can be used to add a notation to the Trace output when a certain event occurs. One example case might be noting within a set of PC trace data where a specific variable was written to.
- End All Trace
- End All Trace can be used to stop tracing of all streams (PC/Timing/Data). Generating this trigger will immediately end all trace capture. This is slightly more restrictive than the End Trace job. The End Trace job allows the user to select the trace streams to be turned off. The End All Trace trigger does not. It will automatically end ALL trace streams. When using CCS an End All Trace trigger will also stop trace recording.
- User Script
- A User Script job allows implementation of some jobs that are too complex to be able to create with the typical trace interface. They typically generate trace data that can be post processed from some scripts in order to gather application data. The scripts can be found here.
Event Trace[edit]
Event Trace is slightly different from Standard Trace in that it enables capturing of the CPU execution and timing with markers injected that indicate where selected events are occurring. Event Trace provides correlation of up to 4 sets of events with PC and Timing data. Essentially, output will look similar to standard PC+Timing trace output, except various samples will be tagged with the different event numbers. With Event Trace you don't have the capability to select specific data to trace when the trigger occurs, like you would in a standard trace. Tracing is essentially always on.
Event Families[edit]
There are 3 different types of events that can be captured with Event Trace. They are Memory Events, Stall Events, and Miscellaneous Events. The list of events for a generic 64x+ device are below. Each device also implements a custom set of events that are routed through the interrupt controller into the Miscellaneous Event group. See the datasheet for the specific device for a comprehensive list of events.
The standard list of events is as follows
Important Note:
The software found on this site is available for download, but is no longer being actively developed. This wiki is in maintenance mode and the software is supported on C64x Multi-core E2E forum
Memory Events | ||||
---|---|---|---|---|
Signal # | Event Number | Aligned | Source | Masked by Emulatable |
0 | L1D Read Hit SRAM A | Yes | Memory Subsystem | Yes |
1 | L1D Read Hit SRAM B | Yes | Memory Subsystem | Yes |
2 | L1D Read Hit Cache A | Yes | Memory Subsystem | Yes |
3 | L1D Read Hit Cache B | Yes | Memory Subsystem | Yes |
4 | L1D Write Hit, Tag Buffer Not Full A | Yes | Memory Subsystem | Yes |
5 | L1D Write Hit, Tag Buffer Not Full B | Yes | Memory Subsystem | Yes |
6 | L1D Write Hit, Tag Buffer Full A | Yes | Memory Subsystem | Yes |
7 | L1D Write Hit, Tag Buffer Full B | Yes | Memory Subsystem | Yes |
8 | L1D Read Miss, Hits L2 SRAM A | Yes | Memory Subsystem | Yes |
9 | L1D Read Miss, Hits L2 SRAM B | Yes | Memory Subsystem | Yes |
10 | L1D Read Miss, Hits L2 Cache A | Yes | Memory Subsystem | Yes |
11 | L1D Read Miss, Hits L2 Cache B | Yes | Memory Subsystem | Yes |
12 | L1D Read Miss, Hits External, Cacheable A | Yes | Memory Subsystem | Yes |
13 | L1D Read Miss, Hits External, Cacheable B | Yes | Memory Subsystem | Yes |
14 | L1D Read Miss, Hits External, non-Cacheable A | Yes | Memory Subsystem | Yes |
15 | L1D Read Miss, Hits External, non-Cacheable B | Yes | Memory Subsystem | Yes |
16 | L1D Write Miss, Write Buffer Not Full A | Yes | Memory Subsystem | Yes |
17 | L1D Write Miss, Write Buffer Not Full B | Yes | Memory Subsystem | Yes |
18 | L1D Write Miss, Write Buffer Full A | Yes | Memory Subsystem | Yes |
19 | L1D Write Miss, Write Buffer Full B | Yes | Memory Subsystem | Yes |
20 | L1D Read Miss, Tag/Victim/Write Buffer Flush A | Yes | Memory Subsystem | Yes |
21 | L1D Read Miss, Tag/Victim/Write Buffer Flush B | Yes | Memory Subsystem | Yes |
22 | CPU-CPU Bank Conflict | Yes | Memory Subsystem | Yes |
23 | CPU-Snoop Conflict (A or B) | Yes | Memory Subsystem | Yes |
24 | CPU-iDMA/EDMA Bank Conflict (A or B) | Yes | Memory Subsystem | Yes |
25 | L1P Read Hit SRAM | Yes | Memory Subsystem | Yes |
26 | L1P Read Hit Cache | Yes | Memory Subsystem | Yes |
27 | L1P Read Miss, Hits L2 SRAM | Yes | Memory Subsystem | Yes |
28 | L1P Read Miss, Hits L2 Cache | Yes | Memory Subsystem | Yes |
29 | L1P Read Miss, Hits External, Cacheable | Yes | Memory Subsystem | Yes |
30 | RESERVED | |||
31 | RESERVED |
System Stall Events | ||||
---|---|---|---|---|
Signal # | Event Number | Aligned | Source | Masked by Emulatable |
0 | CPU Pipeline Stall | No | CPU | YES |
1 | Cross Path Stall | No | CPU | YES |
2 | Branch to Spanning Execute Packet Stall | No | CPU | YES |
3 | External Functional Interface Stall | No | CPU | YES |
4 | MVC Stall | No | CPU | YES |
5 | L1P Other Stall | No | Prioritized (Memory Subsystem L1P) | YES |
6 | L1P Wait State Stall | No | Prioritized (Memory Subsystem L1P) | YES |
7 | RESERVED | |||
8 | L1P Miss Stall | No | Prioritized (Memory Subsystem L1P) | YES |
9 | RESERVED | |||
10 | L1D Other Stall | No | Prioritized (Memory Subsystem L1D) | YES |
11 | L1D Bank Conflict Stall | No | Prioritized (Memory Subsystem L1D) | YES |
12 | L1D DMA Conflict Stall | No | Prioritized (Memory Subsystem L1D) | YES |
13 | L1D Write Buffer Full Stall | No | Prioritized (Memory Subsystem L1D) | YES |
14 | L1D Tag Update Buffer Full Stall | No | Prioritized (Memory Subsystem L1D) | YES |
15 | L1D Line Fill Stall B | No | Prioritized (Memory Subsystem L1D) | YES |
16 | L1D Line Fill Stall A | No | Prioritized (Memory Subsystem L1D) | YES |
17 | L1D Write Buffer Flush Stall | No | Prioritized (Memory Subsystem L1D) | YES |
18 | L1D Victim Buffer Flush Stall | No | Prioritized (Memory Subsystem L1D) | YES |
19 | L1D Tag Update Buffer Flush Stall on Write Buffer Full | No | Prioritized (Memory Subsystem L1D) | YES |
20 | L1D Tag Update Buffer Flush Stall on Read Miss | No | Prioritized (Memory Subsystem L1D) | YES |
21 | L1D Snoop Conflict Stall | No | Prioritized (Memory Subsystem L1D) | YES |
22 | L1D Coherence Operation Conflict Stall | No | Prioritized (Memory Subsystem L1D) | YES |
23 | RESERVED | |||
24 | RESERVED | |||
25 | RESERVED | |||
26 | RESERVED | |||
27 | RESERVED | |||
28 | RESERVED | |||
29 | RESERVED | |||
30 | RESERVED | |||
31 | RESERVED |
Miscellaneous Events | ||||
---|---|---|---|---|
Signal # | Event Number | Aligned | Source | Masked by Emulatable |
0 | Execute Cycles | No | CPU | Yes |
1 | Pipeline Stalls | No | CPU | Yes |
2 | Mark 0 Instruction | Yes | CPU | Yes |
3 | Mark 1 Instruction | Yes | CPU | Yes |
4 | Mark 2 Instruction | Yes | CPU | Yes |
5 | Mark 3 Instruction | Yes | CPU | Yes |
6 | ET0 | No | ECM | No |
7 | ET1 | No | ECM | No |
8 | IACK | No | CPU | No |
9 | AEGEVT 0 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
10 | AEGEVT 1 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
11 | AEGEVT 2 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
12 | AEGEVT 3 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
13 | AEGEVT 4 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
14 | AEGEVT 5 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
15 | AEGEVT 6 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
16 | AEGEVT 7 (Configured through the Interrupt Controller) | No | Interrupt Controller | Depends on Int Cntl Configuration |
17 | EXCEP | No | Interrupt Controller | No |
18 | EXC | No | CPU | No |
19 | NMI | No | Interrupt Controller | No |
20 | RTDX_RX_END | No | RTDX | No |
21 | RTDX_TX_END | No | RTDX | No |
22 | DTDMA END | No | DTDMA | No |
23 | L1D Write Miss, hits L2 SRAM | No | Memory Subsystem | Yes |
24 | L1D Write Miss, hits L2 Cache | No | Memory Subsystem | Yes |
25 | L1D Write Miss, hits external, cacheable | No | Memory Subsystem | Yes |
26 | L1D Write miss, hits external, non-cacheable | No | Memory Subsystem | Yes |
27 | Dirty Victim Writeback from L2 | No | Memory Subsystem | Yes |
28 | DMA Snoop read | No | Memory Subsystem | Yes |
29 | DMA Snoop Write | No | Memory Subsystem | Yes |
30 | Tag Update Queued Tag Update Buffer | No | Memory Subsystem | Yes |
31 | Dirty Victim Writeback from L1D | No | Memory Subsystem | Yes |