< for more information.
## Supported Devices
- AM65x
- J721E
## Example Data Sets
Below are some example data sets that showcase the three operation modes of the CP Tracer 2 IPs on Keystone 3 devices.
The examples below are capturing during the profiling of a DDR intensive application on the J721E EVM.
### Throughput Statistics
Throughput statistics are collected over a user defined sampling window and offer three data points per window: byte transactions (throughput), the number of transactions, and the average length / burst size.
The sampling window is clocked according to the probe clock where the probe resides.
For example on AM65x and J721E, the EMIF0_INITIATOR probe clock is the same as the MSMC clock (typically 1GHz).
The three data points can be viewed in graph form the "Graph View" tab of the Traffic Profiling app as shown in Figure 0.
Figure 2 shows the "Raw Data" view. Note that the data can be saved off in TDF (can be opened from SoC Analysis menu) or CSV formats by selecting the save icon in the top right corner.
**Byte Transactions** - The total number of byte transactions observed at probe interface.
**Matched Transactions** - The total number of transactions observed at probe interface that have matched the filtering criteria.
**Average Length of Transactions** - The average transaction length calculated by Total Bytes / Total Matched.
[[b Tip:
The Byte Transactions value can be converted to MB/s as described in the [FAQ](#faq) section.
]]
Figure 0: Graph view of throughput statistics in Traffic Profiling via CCS. Note that the graph can be zoomed in by clicking and dragging as shown in Figure 1.
Figure 1. Zoomed in graph of data set from Figure 0. To reset the graph to default zoom, double-click on the graph.
Figure 2. Raw data view of throughput statistics.
### Latency Statistics
Latency statistics are captured and counted with the same user defined sampling window as described in the [Throughput Statistics](#throughput-statistics) section.
**Tracked** - The total number of transactions observed at probe interface.
**Matched** - The total number of transactions observed at probe interface that have matched the filtering criteria.
**Max Wait** - The maximum wait time observed at probe interface.
**Total Wait** - The total wait time observed at probe interface.
**Credit Wait** - The credit wait time observed at probe interface for credit-based buses.
Figure 3: Graph view of latency statistics.
### Transaction Logging
Transaction logging is a trace of system transactions occurring across a given probe interface.
The output trace data is only available in the Raw Data view format as the graph view doesn't universally apply to the whole data set.
All of the column data is available in the Probe Configuration menu within the Traffic Profiling application.
Some of the notable fields of the transaction logging data include the following.
[[b Note:
Reads and writes can be traced simultaneously in transaction logging mode, unlike throughput and latency statistics which can only trace reads or writes separately. The sampling window in transaction logging is a don't care.
]]
**Address** - The address of the observed transaction.
**Route ID** - The route ID of the transaction. The route ID is a unique ID assigned to each master interface of the system.
**Direction (DIR)** - The direction of the transaction.
See the [Advanced Probe Filters](#advanced-probe-filters) section for additional transaction logging data columns.
[[b Note:
The direction column applies only to VBUSM and VBUSP probes. Use OP code to determine access type for VBUSM.C probes.
]]
**Byte Count** - Burst size of the transaction.
Figure 4: An example set of transaction logging.
## Getting Started in CCS
To use the Traffic Profiling application, you must have an active debug session opened with a Keystone 3 device.
The Traffic Profiling window can then be opened by right-clicking any of the cores and selecting SoC Analysis→Traffic Profiling.
More information about each use-case, probe definitions, and filtering can be found within the Traffic Profiling window itself.
Figure 5: Open Traffic Profiling by right-clicking a connected core and selecting SoC Analysis→Traffic Profiling.
Figure 6. Expand the Probe Configuration and Receiver Settings for more options.
Figure 7. Traffic Profiling menu bar icons.
## Probe Configuration Settings
Figure 8. Select the desired use-case. Use-case information can be displayed by selecting the down arrow of each use-case.
Once you have selected a use-case, you can decide which probes you would like to trace.
Because bandwidth to the aggregator is limited, it is optimal to only enable the probes that you are interested in.
The most up-to-date descriptions of each probe will be displayed underneath the use-case selection group. The probes are split up by the trace aggregator that they are connected to.
Currently, only one trace aggegator may be traced at a time for ETB and pin trace.
The aggregator is specified by a user via the "Probe Domain" drop down list.
[[b Note:
ETB sizes may be different for each domain so you might see that there is more data collected using one domain versus another.
]]
Figure 9. Select the group of probes to enable/disable via the Probe Domain drop-down list.
Figure 10. Default probe settings for Throughput Statistics.
Figure 11. Latency Statistics set to capture "Write" transactions.
Figure 12. Transaction Logging set to capture "All" transactions. Note that the "All" setting is only available for Transaction Logging.
## Basic Probe Filters
Basic probe filter descriptions are available in the form of a tooltip when hovering over the input of each field.
- **Sampling Window**: Measurement interval in clock cycles for detecting a statistics event
The sampling window frequency matches the probe clock for a given domain (i.e. MSMC probes are clocked with the MSMC clock).
Sampling window selection is dependent on how long in time you wish to view statistics or transactions.
- **Address Range Low**: Low end of the address window.
Transactions occurring occurring at addresses above this value will be included in statistics/logging if Exclude address range is not checked.
- **Address Range High**: High end of the address window.
Transactions occurring occurring at addresses below this value will be included in statistics/logging if Exclude address range is not checked.
- **Exclude address range**: If false, only addresses included in range specified by Address Range Low and Address Range High will be traced.
If true, all addresses inside of the address range window will be excluded.
- **Access Type**: Specifies whether reads, writes, or both read and writes will be traced.
[[b Note:
Reads and writes can't be traced simultaneously when using Throughput or Latency statistics.
]]
## Advanced Probe Filters
Advanced probe filters can be added/removed as shown in Figure 8.
Note that the following filter descriptions are available in the Add Filter dialog as shown in Figure 9.
- **Channel ID**
Indicates the channel ID of a transaction.
This value is used by downstream hardware for identifying ownership/permissions/address translations.
Valid range: 0 - 0xFFF
- **Order ID**
The Order ID signal indicates how transactions need to be ordered at the endpoint slave.
By default, all transactions within the same order ID will be treated as strongly ordered by the endpoint slaves.
Valid range: 0 - 0xF
- **Address Mode** (Mode column in transaction logging)
The value of the transaction address mode.
0 = linear incrementing
1..3 = reserved
- **Route ID**
The route ID of the transaction.
The route ID is a unique ID assigned to each master interface of the system.
Valid range: 0 - 0xFFF
- **Region ID**
The region of the transaction.
Valid range: 0 - 0xF
- **Virtual ID**
The virtualization ID of the transaction.
Valid range: 0 - 0xFFF
- **Exclusive** (EXCL column in transaction logging)
The exclusivity of the transaction.
0 = normal
1 = exclusive
- **Direction** (DIR column in transaction logging)
The direction of the transaction for VBUSM/VBUSP probes.
For VBUSM.C probes, use OP Code for filtering reads/writes.
0 = write
1 = read
- **Data Type**
The data type of the transaction.
0 = CPU Data Access
1 = CPU Instruction Access
2 = DMA Access
3 = Reserved
- **Line Size** (LSIZE column in transaction logging)
Cache line size for constant or cache line wrap addressing modes.
0 = 16 bytes
1 = 32 bytes
2 = 64 bytes
4 = 128 bytes
5-7 = reserved
- **Byte Count**
Burst size of the transaction
Valid range: 0 - 0x3FF
- **OP Code**
The opcode of the transaction for VBUSM.C probes.
Valid range: 0 - 0x3F
|Op Code | Description |Category | Blocking / Non-blocking |
|------------------|-------------------------|-------------|-------------------------|
|000_000 | ReadNoSnoop | Read | Blocking |
|000_001 | ReadOnce | Read | Blocking |
|000_010 | ReadClean | Read | Blocking |
|000_011 | ReadUnique | Read | Blocking |
|000_100 | ReadNotSharedDirty | Read | Blocking |
|000_101 | ReadShared | Read | Blocking |
|000_110 | CleanUnique | Read | Blocking |
|000_111 | MakeUnique | Read | Blocking |
|001_000 | WriteNoSnoop | Write | Blocking |
|001_001 | WriteUnique | Write | Blocking |
|001_010 | WriteLineUnique | Write | Blocking |
|001_011 | WriteClean | Write | Non-blocking |
|001_100 | WriteBack | Write | Non-blocking |
|001_101 | WriteEvict | Write | Non-blocking |
|001_110 | WriteNoSnoopNonBlocking | Write | Non-blocking |
|001_111 | RESERVED | N/A | N/A |
|010_000 | SnoopReadOnce | Snoop | Non-blocking |
|010_001 | SnoopReadShared | Snoop | Non-blocking |
|010_010 | SnoopCleanShared | Snoop | Non-blocking |
|010_011 | SnoopCleanInvalid | Snoop | Non-blocking |
|010_100 | SnoopMakeInvalid | Snoop | Non-blocking |
|010_101 | SnoopReadClean | Snoop | Non-blocking |
|010_110 | SnoopReadNotSharedDirty | Snoop | Non-blocking |
|010_111 | SnoopReadUnique | Snoop | Non-blocking |
|011_000 - 011_111 | RESERVED | N/A | N/A |
|100_000 | DVMOperation | DVM | Blocking |
|100_001 | DVMOperationMulti | DVM | Blocking |
|100_010 | DVMSync | DVM | Blocking |
|100_011 | DVMComplete | DVM | Blocking |
|100_100 | DVMSnoopOperation | DVM | Non-blocking |
|100_101 | DVMSnoopOperationMulti | DVM | Non-blocking |
|100_110 | DVMSnoopSync | DVM | Non-blocking |
|100_111 | DVMSnoopComplete | DVM | Non-blocking |
|101_000 | CacheWarmShared | Message | Blocking |
|101_001 | CacheWarmUnique | Message | Blocking |
|101_010 | MMUWarm | Message | Blocking |
|101_011 | Evict | Message | Non-blocking |
|101_100 - 101_111 | RESERVED | N/A | N/A |
|110_000 | CleanSharedPOU | Maintenance | Blocking |
|110_001 | CleanInvalidPOU | Maintenance | Blocking |
|110_010 | MakeInvalidPOU | Maintenance | Blocking |
|110_011 | RESERVED | N/A | N/A |
|110_100 | CleanSharedPOC | Maintenance | Blocking |
|110_101 | CleanInvalidPOC | Maintenance | Blocking |
|110_110 | MakeInvalidPOC | Maintenance | Blocking |
|110_111 | RESERVED | N/A | N/A |
|111_000 | Read Response | Response | Non-blocking |
|111_001 | Snoop Response | Response | Non-blocking |
|111_010 - 111_111 | RESERVED | N/A | N/A |
- **Memory Type**
The memory type of the transaction.
0 = Device memory
1 = Normal writeback cacheable memory
2 = Normal write-through cacheable memory
3 = Normal non-cacheable memory
- **Address Type** (ATYPE column in transaction logging)
Indicates the address type of the transaction
0 = Physical address
1 = Intermediate address
2 = Virtual address
3 = Translated address (physical address with all memory attributes)
- **Escalated Priority** (EPRIORITY column in transaction logging)
The escalated priority of the transaction.
0 = highest
7 = lowest
- **Priority**
The priority of the transaction
0 = highest
7 = lowest
- **QoS**
Indicates the quality of service of the transaction.
Valid range: 0-7
- **Privilege** (PRIV column in transaction logging)
The privilege level of the transaction.
0 = user
1 = supervisor
2 = hypervisor
3 = hypervisor supervisor
- **Secure**
Indicates whether the transaction is secure.
0 = not secure
1 = secure
- **Privilege ID** (PRIVID column in transaction logging)
The privilege ID of the transaction.
The ID of the logical entity that is responsible for the current transaction.
Valid range: 0 - 0x0FF
- **Pre-fetchable** (PABLE column in transaction logging)
Indicates pre-fetchbility of the transactions.
0 = device memory
1 = normal writeback cacheable memory
- **Shareability** (SDOMAIN column in transaction logging)
Indicates the shareability domain of the transaction.
0 = Non-shareable
1 = Inner shareable
2 = Outer shareable
3 = System shareable
- **Outer Cache** (OUTER column in transaction logging)
Transaction for outer cache domain.
0 = Non-allocateable. Caches in the domain must not allocate.
1 = Writes should allocate. Reads must not allocate.
2 = Reads should allocate. Writes must not allocate.
3 = Reads and writes should allocate.
- **Inner Cache** (INNER column in transaction logging)
Transaction for inner cache domain.
0 = Non-allocateable. Caches in the domain must not allocate.
1 = Writes should allocate. Reads must not allocate.
2 = Reads should allocate. Writes must not allocate.
3 = Reads and writes should allocate.
- **Mirrored Sideband** (CMSIDEBAND column in transaction logging)
The CMSIDEBAND bus.
Valid range: 0 - 0xFF
- **Sideband** (CSIDEBAND column in transaction logging)
The CSIDEBAND bus.
Valid range: 0 - 0xFF
- **Flush**
Signal that indicates transaction has been invalidated.
0 = normal
1 = blocked
- **Firewall Status** (FWPASS column in transaction logging)
Signal that indicates the previously passing firewall status of a transaction.
0 = Security and isolation firewalls not checked.
1 = Security firewall checked and isolation firewall not checked.
2 = Security firewall not checked and isolation firewall checked.
3 = Security and isolation firewalls checked.
- **Slave Select** (ASEL column in transaction logging)
Indicates the predetermined slave select of the transaction.
0 = No default slave select (decode based on address).
1 = Forward the transaction to the slave based on the SoC map.
Figure 13: Advanced filters may be added and removed as shown above.
Figure 14: Advanced filter settings dialog.
Advanced filters have two fields: value and mask.
The mask can be used to mark values of the "Value" field as a don't care allowing a filter to match a range of multiple criteria for a given filter.
For example, in Figure. 9, the Route ID Value is set to 0xFF (11111111b) and the Route ID Mask is set to 0xF8 (11111000).
Any of the bits set in the Route ID Mask will be marked as a care and the zeros in the mask are don't cares.
The result is that any Route ID from 0xF8-0xFF will be considered a match in the filter criteria and transactions statistics/logging will be traced for those Route IDs.
### Throughput and Latency Restrictions
For Keystone 3 devices, CP tracer probes will be attributed with one of the following bus types: VBUSM, VBUSP, and VBUSM.C.
The bus type for each probe is appended to the probe description in the information table on the main "Probe Configuration" view.
Figure 15: Bus type is appended to the probe description.
Depending on which probe you are using, there will be default filter values that are preset when enabling a probe.
These default values are intentionally set to comply with hardware restrictions.
The restrictions imply the following for Throughput and Latency Statistics:
1. Direction mask must always be set to 1 for VBUSM and VBUSP probes.
2. Bits 5:3 of the OP Code mask must always be set to 111b for VBUSM.C
3. Transaction Logging does not have this restriction.
### Transaction Logging Restrictions
Because the bandwidth is limited from the probe to the aggegator, the aggregator may overflow and be unable to send out the trace data fast enough.
In the data, this scenario will be reported as a FIFO overflow.
Currently there are only two ways to reduce the amount of FIFO overflows.
1. Increase the amount of filter criteria to limit transactions to the aggregator.
2. Slow down the clock of the bus being probed.
## Receiver Settings
There are two options for exporting traffic profiling data: ETB or TPIU (pin trace).
Currently for TPIU trace only the Pro Trace receiver is supported.
### Buffer Type
All receivers support circular and stop-on-full buffer types.
In circular buffer mode, the ETB or Pro Trace will overwrite data once the buffer is full continually until trace is stopped.
In stop-on-full mode, the trace capture will automatically halt when the buffer is full.
### Halt trace capture when specified core halts
All receivers support the halt trace capture when specified core halts field. When this field is set to an existing core name, the traffic profiling data will halt automatically when the specified core halts.
This feature is useful, along with breakpoint, in tracing the exact code that you want to profile.
### ETB Receiver
Figure 16: ETB receiver set in circular buffer mode. Trace will halt when MCU_PULSAR_Cortex_R5_0 halts. Manual halt will still work.
### Pro Trace Receiver
Figure 17: Pro Trace receiver set in circular buffer mode. Trace will halt when CortexA53_0_1 halts. Manual halt will still work.
The Pro Trace has two additional options that the ETB receiver does not have: Pins and Buffer Size.
- **Pins**
Select the number of pins you will use to export data off-chip.
More pins will allow more bandwidth.
However, keep in mind that there still is a bandwidth limit at the aggregator.
- **Buffer Size**
Select the size of buffer for binary trace data.
Note that the trace data is highly compressed in binary form and will result in files much larger than the specified buffer size.
## FAQ
### What does the data mean?
All of the column information for each use-case can be found in the configuration screen by expanding each use-case within the app as shown in Figure 8.
### How do you interpret throughput/latency data?
For Throughput and Latency statistics, the values contained in each column represent the number of instances that occurred within a sampling window.
Once you know what the probe clock you can make the calculation.
**Example**
One partial line of throughput data looks like the following:
| Master | Master Name | Data Message | Global Timestamp |Total Bytes
|--------|-----------------|-----------------------------------------------|--------------------|
| 0x20 | EMIF0_INITIATOR | Throughput statistics per 0xffff clock cycles | 0x000000018AC13A40 | 0x00009900
So for this sample, the throughput at GTC timestamp 0x18AC13A40 is 0x9900 bytes / 0xffff MSMC clock cycles.
If MSMC is clocked at 1GHz, the sampling window is (65536 cycles / 1 window) * (1 s / 1 G cycles) = 0.000065535 seconds.
Which would be (0x9900 bytes / 1 sample window) = 39168 bytes / 0.000065535 seconds = ~600MB/s
### What does the global timestamp mean?
The global timestamp is the time when a transaction or sample window's closing occurred.
The timestamp comes from the Global Timestamp Counter (GTC).
The GTC clock frequency is user-configurable. Refer to chip documentation for specifics on the frequency for a given device.
A ballpark estimate of the GTC frequency can also be captured with the get_gtc_clock_frequency() function via the gel here.
```
#define GTC_REG_BASE 0x00a90000 // Device specific (valid for AM65x and J721E)
#define GTC_REG_CNTCR (GTC_REG_BASE+0x000)
#define GTC_REG_CNTSR (GTC_REG_BASE+0x004)
#define GTC_REG_CNTCV_LO (GTC_REG_BASE+0x008)
#define GTC_REG_CNTCV_HI (GTC_REG_BASE+0x00C)
#define GTC_SYSTEM_COUNTER_ENABLE (1 << 0)
#define GTC_WAIT_TIME_SECONDS 10
unsigned int gtc_cntcv_lo = 0;
unsigned int gtc_cntcv_hi = 0;
unsigned int gtc_cntcv_lo_post = 0;
unsigned int gtc_cntcv_hi_post = 0;
enable_gtc()
{
unsigned int val = 0;
unsigned int addr = 0;
addr = GTC_REG_CNTCR;
val = *(unsigned int*)addr@System_View;
if (!(val & GTC_SYSTEM_COUNTER_ENABLE)) {
val |= GTC_SYSTEM_COUNTER_ENABLE;
*(unsigned int*)addr@System_View = val;
val = *(unsigned int*)addr@System_View;
if (!(val & GTC_SYSTEM_COUNTER_ENABLE)) {
GEL_TextOut("Unable to enable GTC counter!\n",,,,,);
return;
}
}
GEL_TextOut("GTC Counter Enabled\n",,,,,);
}
hotmenu get_gtc_count()
{
unsigned int addr = 0;
addr = GTC_REG_CNTCV_HI;
gtc_cntcv_hi = *(unsigned int*)addr@System_View;
addr = GTC_REG_CNTCV_LO;
gtc_cntcv_lo = *(unsigned int*)addr@System_View;
GEL_TextOut( "GTC_REG_CNTCV_HI_PRE = %x\n",,,,, gtc_cntcv_hi );
GEL_TextOut( "GTC_REG_CNTCV_LO_PRE = %x\n",,,,, gtc_cntcv_lo );
}
get_gtc_count_post()
{
unsigned int addr = 0;
unsigned int freq = 0;
addr = GTC_REG_CNTCV_HI;
gtc_cntcv_hi_post = *(unsigned int*)addr@System_View;
addr = GTC_REG_CNTCV_LO;
gtc_cntcv_lo_post = *(unsigned int*)addr@System_View;
GEL_TextOut( "GTC_REG_CNTCV_HI_POST = %x\n",,,,, gtc_cntcv_hi_post );
GEL_TextOut( "GTC_REG_CNTCV_LO_POST = %x\n",,,,, gtc_cntcv_lo_post );
GEL_CancelTimer(1);
GEL_TextOut( "GTC_REG_CNTCV_HI delta = %x\n",,,,, (gtc_cntcv_hi_post - gtc_cntcv_hi) );
GEL_TextOut( "GTC_REG_CNTCV_LO delta = %x\n",,,,, (gtc_cntcv_lo_post - gtc_cntcv_lo) );
freq = (((gtc_cntcv_hi_post - gtc_cntcv_hi) << 32) | (gtc_cntcv_lo_post - gtc_cntcv_lo)) / GTC_WAIT_TIME_SECONDS;
// Divide by 1000000 to convert Hz->MHz.
GEL_TextOut( "Approximate GTC frequency = %d MHz\n",,,,, (freq / 1000000));
}
hotmenu get_gtc_clock_frequency()
{
enable_gtc();
get_gtc_count();
GEL_TextOut( "Waiting %d seconds to calculate GTC delta.\n",,,,,(GTC_WAIT_TIME_SECONDS));
// GEL_SetTimer takes milliseconds as first argument.
GEL_SetTimer(GTC_WAIT_TIME_SECONDS*1000, 1, "get_gtc_count_post()");
}
```
The gel is intended to be executed from the CS_DAP_0 node (right-click any core in active debug session and select "Show all cores" then expand Non Debuggable Devices).
### Why am I not seeing the expected throughput data?
Trace is not being captured at the time of the transaction or the valid trace data is being overwritten in a circular buffer.
First if you are trying to capture throughput or latency statistics with an ETB receiver, understand that the trace buffer will fill very fast as the probe is continuously sampling even if no traffic is occurring on the probes interconnect.
It is important that trace be halted immediately after the desired point of tracing is complete which can be accomplished with the "Halt trace capture when specified core halts" option in Receiver Settings.
Please note that the "Halt trace capture..." option will be triggered by printf statements on the core the option is tied to.
[[y Warning:
It is not recommended to tie the stop capture option to a core that is running code with printf's in it.
]]
If you are sure you are capturing throughput or latency statistics at the correct time, try capturing with transaction logging using the same sequence.
Set "Access Type" to all and confirm that the transactions are actually happening.
Confirm that the correct probe is being used for the interconnect you are trying to profile.
### Why am I seeing FIFO overflow in transaction logging mode?
Hardware limitations will sometimes prevent transactions from being recorded due to a overflow in trace hardware.
The exact bandwidth limitation across a probe interface is device dependent.
When a FIFO message is encountered, there is no way to definitively determine how many transactions were lost. However, careful notice of the global timestamp can give you an idea of the timeframe in which transactions were not being traced.
The only way to prevent FIFO overflows the use filters to limit what transactions get traced or to slow the bandwidth of said transactions at a given interface.
<!-- End of markdown source -->
<div id="footer"></div>
]]>