| Copyright © 1999-2002, 2004-2009, 2011 ARM Limited. All rights reserved. | ARM IHI 0014Q |
| Non-Confidential | ID101211 |
 PDF version | |
| Home > ETMv3 Signal Protocol > Synchronization > I-sync instruction synchronization |
| |||
| Home > ETMv3 Signal Protocol > Synchronization > I-sync instruction synchronization | |||
When the decompressor finds an A-sync sequence, it must search for an I-sync packet. This provides synchronization of the following parts of the trace:
instruction address
instruction set state
address of previous data instruction, if it is still executing
Context ID.
The I-Sync packet includes a code that gives the reason for the output of the I-Sync. See Reason codes. The possible reasons are:
periodic synchronization
tracing enabled
tracing restarted after an overflow
the processor has exited debug state.
If the code indicates periodic synchronization, the I-sync packet is called a Periodic I-sync packet. Otherwise, it is called a Non-periodic I-sync packet.
The possible forms of an I-sync packet are:
Normal I-sync packet, see Normal I-sync packet
Normal with cycle count I-sync packet, see Normal I-sync with cycle count packet
Load/Store in Progress (LSiP) I-sync packet, see Load/Store in Progress (LSiP) I-sync packet
Load/Store in Progress (LSiP) with cycle count I-sync packet, see Load/Store in Progress (LSiP) I-sync with cycle count packet
Data-only I-sync packet, see Data-only I-sync packet.
When tracing in cycle-accurate mode, a cycle count is required for every Non-periodic I-sync packet to indicate the number of cycles (W atoms) since the last P-header packet prior to the I-sync packet. This is output in one of the following ways:
The I-sync packet, followed by a Cycle count packet before the next Non-periodic I-sync packet. The Cycle count packet might not be present if there is a subsequent ETM FIFO overflow, and in this case the cycle count is unknown.
The I-sync packet is a Normal I-sync with cycle count packet.
The I-sync packet is a Load/Store in Progress (LSiP) I-sync with cycle count packet.
For details of the possible use of I-sync packets for tracing long gaps in trace during cycle-accurate tracing, see Tracing long gaps in cycle-accurate trace.
Figure 7.42 shows the format of a Normal I-sync packet.
A normal I-sync packet comprises the following contiguous components:
Indicates that this is an I-sync packet.
The number of Context ID bytes traced (0-4) is statically determined by ETMCR bits [15:14]. For more information on Context ID, see Context ID packets.
In this byte:
Bit [7] distinguishes between Normal and LSiP I-sync packets, and is 0 for a Normal I-sync packet.
Bits [6:5] are a 2-bit reason code, see Reason codes.
Bit [4] is set to 1 if the processor is in Jazelle state.
Bit [3] is set to 1 if the processor is in a Non-secure state.
From ETMv3.3, bit [2] is the Alternative instruction set (AltISA) bit. For more information, see The Alternative instruction set bit, ETMv3.3 and later.
In ETMv3.5, for an implementation that includes the Virtualization Extensions, bit [1] is the Hyp bit and is set to 1 if the processor is in Hyp mode.
The instruction address is always four bytes and is not compressed.
Bit [0] is the Thumb bit and is set to 1 if the processor is in Thumb state. See The Alternative instruction set bit, ETMv3.3 and later for the interpretation of this bit in ETMv3.3 and later.
From ETMv3.3, bit [2] of the Information byte is the Alternative instruction set (AltISA) bit. From ETMv3.3, to find state of the processor you must consider the following:
the J bit, bit [4] of the Information byte
the T bit, bit [0] of the Address field
the AltISA bit, bit [2] of the Information byte.
Table 7.20 shows how the values of these bits correspond to the different processor states.
Table 7.20. Processor state information in I-sync packets, ETMv3.3 and later
| J bit | T bit | AltISA bit | Alignment | Processor State |
|---|---|---|---|---|
| 0 | 0 | 0 | Word | ARM. |
| 0 | 0 | 1 | Word | Not used. Reserved combination of J, T and AltISA. |
| 0 | 1 | 0 | Halfword | Thumb. |
| 0 | 1 | 1 | Halfword | ThumbEE. |
| 1 | X | 0 | Byte | Jazelle. The T bit indicates bit [0] of the address. |
| 1 | X | 1 | Byte | Not used. Reserved combination of J, T and AltISA. |
A Normal I-sync with cycle count packet is equivalent to a Normal I-sync packet followed by a Cycle count packet. The cycle count indicates the number of cycles (W atoms) that have occurred since the last P-header packet.
A Normal I-sync with cycle count packet is never output with a reason code of periodic synchronization, because the cycle count is used to indicate the gap between trace regions, and when periodic synchronization is performed there is no gap in the trace.
Figure 7.43 shows the format of a Normal I-sync with cycle count packet.
A normal I-sync packet with cycle count comprises the following contiguous components:
Indicates that this is an I-sync packet.
The number of cycles since the last P-header. See Cycle information, for cycle-accurate tracing for more information on P-headers.
In ETMv3.5, if the reason code in the information byte indicates overflow, the cycle count is unknown and cannot be relied on.
The number of Context ID bytes traced (0-4) is statically determined by ETMCR bits [15:14]. For more information on Context ID, see Context ID packets.
In this byte:
Bit [7] distinguishes between Normal and LSiP I-sync packets, and is 0 for a Normal I-sync packet.
Bits [6:5] are a 2-bit reason code, see Reason codes.
Bit [4] is set to 1 if the processor is in Jazelle state.
Bit [3] is set to 1 if the processor is in a Non-secure state.
From ETMv3.3, bit [2] is the Alternative instruction set (AltISA) bit. For more information, see The Alternative instruction set bit, ETMv3.3 and later.
In ETMv3.5, for an implementation that includes the Virtualization Extensions, bit [1] is the Hyp bit and is set to 1 if the processor is in Hyp mode.
The instruction address is always four bytes and is not compressed.
Bit [0] is the Thumb bit and is set to 1 if the processor is in Thumb state. See The Alternative instruction set bit, ETMv3.3 and later for the interpretation of this bit in ETMv3.3 and later.
LSiP I-sync packets occur only when the following conditions occur simultaneously:
Trace is enabled in the middle of a data instruction. Definitions lists the data instructions.
Another instruction is currently executing.
An LSiP I-sync packet is never output with a reason code of periodic synchronization because this I-sync packet is only used when tracing is started. Figure 7.44 shows the format of an LSiP I-sync packet.
An LSiP I-sync packet comprises the following contiguous components:
Indicates that this is an I-sync packet.
The number of Context ID bytes traced (0-4) is statically determined by ETMCR bits [15:14]. For more information on Context ID, see Context ID packets.
In this byte:
Bit [7] distinguishes between Normal and LSiP I-sync packets, and is 1 for a LSiP I-sync packet.
Bits [6:5] are a 2-bit reason code, see Reason codes.
Bit [4] is set to 1 if the processor is in Jazelle state.
Bit [3] is set to 1 if the processor is in a Non-secure state.
From ETMv3.3, bit [2] is the Alternative instruction set (AltISA) bit. For more information, see The Alternative instruction set bit, ETMv3.3 and later.
In ETMv3.5, for an implementation that includes the Virtualization Extensions, bit [1] is the Hyp bit and is set to 1 if the processor is in Hyp mode.
This is the address of the data instruction executing in parallel with the current instruction.
Bit [0] is the Thumb bit and is set to 1 if the processor is in Thumb state. See The Alternative instruction set bit, ETMv3.3 and later for the interpretation of this bit in ETMv3.3 and later.
Execution of the instruction at this address is implied, as if an E atom was traced after this address and before the current instruction addresses.
The address for the instruction currently executing (1-5 bytes) is compressed using the technique that is used for Branch addresses, see Branch Packets. The exception vector format is not used in this case. A 6-byte address might be used here to indicate a change in security level.
This instruction address is compressed relative to the full address from the data instruction address. The next instruction atom is for the instruction pointed to by the compressed current instruction address and tracing begins in the normal way from this point forwards.
The LSiP I-sync packet type enables correct tracing of all instructions that touch a particular data address or data value. Without it, the data instruction cannot be properly traced based on the data address.
If trace is enabled in the middle of a data instruction, another instruction has since executed and left the pipeline but no instruction is currently executing, a Normal I-sync packet is output, giving the address of the data instruction. A Branch address packet is output giving the address of the next instruction to execute before it is traced.
Instructions occurring underneath the data instruction are traced even if tracing is programmed to turn on only during the data instruction itself. Similarly, if tracing starts because of the instruction address of an instruction that executes underneath a data instruction, an LSiP I-sync packet is still output.
An LSiP I-sync with cycle count packet is equivalent to an LSiP I-sync packet followed by a Cycle count packet. The cycle count packet indicates the number of cycles (W atoms) that have occurred since the last P-header packet.
An LSiP I-sync with cycle count packet is never output with a reason code of periodic synchronization because this I-sync packet is only used when tracing is started.
Figure 7.45 shows the format of an LSiP I-sync with cycle count packet.
An LSiP I-sync with cycle count packet comprises the following contiguous components:
Indicates that this is an I-sync packet.
The number of cycles since the last P-header. See Cycle information, for cycle-accurate tracing for more information on P-headers.
In ETMv3.5, if the reason code in the information byte indicates overflow, the cycle count is unknown and cannot be relied on.
The number of Context ID bytes traced (0-4) is statically determined by ETMCR bits [15:14]. For more information on Context ID, see Context ID packets.
In this byte:
Bit [7] distinguishes between Normal and LSiP I-sync packets, and is 1 for an LSip I-sync packet.
Bits [6:5] are a 2-bit reason code, see Reason codes.
Bit [4] is set to 1 if the processor is in Jazelle state.
Bit [3] is set to 1 if the processor is in a Non-secure state.
From ETMv3.3, bit [2] is the Alternative instruction set (AltISA) bit. For more information see The Alternative instruction set bit, ETMv3.3 and later.
In ETMv3.5, for an implementation that includes the Virtualization Extensions, bit [1] is the Hyp bit and is set to 1 if the processor is in Hyp mode.
This is a fixed 4-byte address, the address of the data instruction executing in parallel with the current instruction.
Bit [0] is the Thumb bit and is set to 1 if the processor is in Thumb state. See The Alternative instruction set bit, ETMv3.3 and later for the interpretation of this bit in ETMv3.3 and later.
Execution of the instruction at this address is implied, as if an E atom was traced after this address and before the current instruction addresses.
The address for the instruction currently executing (1-5 bytes) is compressed using the technique that is used for Branch addresses, see Branch Packets. The exception vector format is not used in this case.
This instruction address is compressed relative to the full address from the data instruction address. The next instruction atom is for the instruction pointed to by the compressed current instruction address, and tracing begins in the normal way from this point. A 6-byte address might be used here to indicate a change in security level.
The LSiP I-sync packet type enables correct tracing of all instructions that touch a particular data address or data value. Without it, the data instruction cannot be properly traced based on the data address.
If trace is enabled in the middle of a data instruction, and another instruction has since executed and left the pipeline, but no instruction is currently executing, a Normal I-sync packet is output, giving the address of the data instruction. A Branch address packet is output giving the address of the next instruction to execute before it is traced.
Instructions occurring underneath the data instruction are traced even if tracing is programmed to turn on only during the data instruction itself. Similarly, if tracing starts because of the instruction address of an instruction that executes underneath a data instruction, an LSiP I-sync packet is still output.
In data-only mode, data-only I-sync packets are output instead of the other forms of I-sync packets. Figure 7.46 shows the format of a data-only I-sync packet.
A data-only I-sync packet comprises the following contiguous components:
Indicates that this is an I-sync packet.
The number of Context ID bytes traced (0-4) is statically determined by ETMCR bits [15:14]. For more information on Context ID, see Context ID packets.
This includes a 2-bit reason code. There is no bit to indicate whether the processor is in Jazelle state. Bit [3] is set to 1 if the processor is in Non-secure state.
In ETMv3.5, for an implementation that includes the Virtualization Extensions, bit [1] is the Hyp bit and is set to 1 if the processor is in Hyp mode.
Reason codes are encoded as the information byte in the I-sync packet header. The reason codes are listed in Table 7.21.
Table 7.21. ETMv3 reason codes
| Value | Description |
|---|---|
| b00 | Periodic I-sync. |
| b01 | Tracing enabled. |
| b10 | Tracing restarted after overflow. This takes precedence over b01. This is not output following exit from debug state. For more information, see ETM Status Register, ETMSR, ETMv1.1 and later. |
| b11 | ARM processor has exited from debug state. This code is only used if the first non-prohibited instruction following exit from debug state is traced. |
| Copyright © 1999-2002, 2004-2009, 2011 ARM Limited. All rights reserved. | ARM IHI 0014Q |
| Non-Confidential | ID101211 |
| PDF version | |
| Home > ETMv3 Signal Protocol > Synchronization > I-sync instruction synchronization |