1.1. RISC-V Hart to Trace Encoder interface

This section describes in general terms the information which must be passed from the RISC-V hart to the trace encoder for the purposes of Instruction Trace, and distinguishes between what is mandatory, and what is optional.

The following information is mandatory:

The following information is optional:

The mandatory information is the bare-minimum required to implement a basic branch trace encoding algorithm. The optional information facilitates alternative or improved trace algorithms:

This section describes the interface between a RISC-V hart and the trace encoder that conveys the information described in 1.1.1. Instruction Trace Interface requirements. Signals are assigned to one of the following groups:

"Special" instructions are those that require itype to be non-zero.

Table 1 and Table 2 list the signals in the interface designed to efficiently support retirement of multiple instructions per cycle. The following discussion describes the multiple-retirement behavior. However, for harts that can only retire one instruction at a time, the signalling can be simplified, and this is discussed subsequently in 1.1.2.1. Simplifications for single-retirement.

The information presented in a block represents a contiguous sequence of instructions starting at iaddr, all of which retired in the same cycle. Note if itype is 1 or 2 (indicating an exception or an interrupt), the number of instructions retired may be zero. cause is only defined if itype is 1 or 2, and tval if itype is 1. If iretire=0 and itype=0, the values of all other signals are undefined.

iretire contains the number of (16-bit) half-words represented by instructions retired in this block, and ilastsize the size of the last instruction. Half-words rather than instruction count enables the encoder to easily compute the address of the last instruction in the block without having access to the size of every instruction in the block.

itype can be 3 or 4 bits wide. If itype_width_p is 3, a single code (6) is used to indicate all uninferable jumps. This is simpler to implement, but precludes use of the implicit return mode (see Implicit Return), which requires jump types to be fully classified. Note that when itype_width_p is 3, itype = 0 is used for inferable calls. However, inferable calls must still be the last instruction retired in a block, otherwise the block would not be comprised of contiguous instructions.

Whilst iaddr is typically a virtual address, it does not affect the encoder’s behavior if it is a physical address.

For harts that can retire a maximum of N non-zero itype values per clock cycle, the signal groups MR, OR and either BR or SR must be replicated N times. Typically N is determined by the maximum number of branches that can be retired per clock cycle. Signal group 0 represents information about the oldest instruction block, and group N-1 represents the newest instruction block. The interface supports no more than one privilege change, context change, exception or interrupt per cycle and so signals in groups M and O are not replicated. Furthermore, itype can only take the value 1 or 2 in one of the signal groups, and this must be the newest valid group (i.e. iretire and itype must be zero for higher numbered groups). If fewer than N groups are required in a cycle, then lower numbered groups must be used first. For example, if there is one branch, use only group 0, if there are two branches, instructions up to the 1st branch must be reported in group 0 and instructions up to the 2nd branch must be reported in group 1 and so on.

sijump is optional and may be omitted if the hart does not implement the logic to detect sequentially inferable jumps. If the encoder offers an sijump input it must also provide a parameter to indicate whether the input is connected to a hart that implements this capability, or tied off. This is to ensure the trace decoder can be made aware of the hart’s capability. Enabling sequentially inferable jump mode in the encoder and trace decoder when the hart does not support it will prevent correct reconstruction by the trace decoder.

The context and/or the time field can be used to convey any additional information to the trace decoder. For example:

Table 7 specifies the actions for the various ctype values. A typical behavior would be for this signal to remain zero except on the 1st retirement after a context change or when a time value should be reported. Note also that context and time are automatically included in trace packets reporting the 1st instruction of a trap handler, or after a privilege change, and so this signal can remain zero in these cases as well (though it is not required). ctype_width_p may be 1 or 2. The reduced width option only provides support for reporting context changes imprecisely.

This section describes in general terms the information which must be passed from the RISC-V hart to the trace encoder for the purposes of Data Trace, and distinguishes between what is mandatory, and what is optional.

If Data Trace is not needed in a system then there is no requirement for the RISC-V hart to supply any of the signals in 1.1.4. Data Trace Interface.

Data trace supports up to four data access types: load, store, atomic and CSR. Support for both atomic and CSR accesses are independently optional.

The signalling protocol can take one of two forms, depending on the needs of the RISC-V hart: unified or split. A hart is expected to provide one of these forms, not both simultaneously.

Unified is the simplest form, suitable for simpler, in-order harts. In this form, all information about a data access is signalled by the RISC-V hart in the same cycle. This is also the cycle that the associated data access instruction is reported as retired on the instruction trace interface, except for multi-memory access instructions - see 1.1.4.1. Multi-memory-access Instructions.

For harts with out of order or speculative execution capabilities, many loads may be in progress simultaneously, and this approach is not practical as it would require the hart to maintain a large amount of state relating to all the in-progress loads. For this reason, the interface also supports splitting loads, atomic and CSR accesses into two parts:

The two parts of a split load are associated by use of a transaction ID.

For CSR accesses, the request and response phases should occur simultaneously.

This section describes the interface between a RISC-V hart and the trace encoder that conveys the information described in the 1.1.3. Data Trace Interface requirements. Signals are assigned to one of the following groups:

All signals in M, U and O groups are only valid when dretire is high. Signals in the S group are valid as indicated in table Table 12.

For harts that can retire a maximum of M data accesses per cycle, the implemented signal groups must be replicated M times. If fewer than M groups are required in a cycle, then lower numbered groups must be used first. For example, if there is one data access, use only group 0.

The maximum value of dtype_width_p is 4. However, if only loads and stores are supported, dtype_width_p can be 1. If Multi-memory access instructions are also required, dtype_width_p can be 2. If CSRs are supported but atomics are not, dtype_width_p can be 3.

Atomic and CSR accesses have load data and an operand (the actual stored data is obtained by applying the operator indicated by dtype to these values). When using unified signalling, both values are reported via data, with the operand data in the LSBs (occupying bits 0 through data_width_p/2 - 1) and the load data in the MSBs (occupying bits data_width_p/2 through data_width_p - 1). When using split signalling, the operand is reported via sdata and the load data via ldata.

Store conditional (SC) and Compare-and-swap (CAS) instructions both perform stores only if some condition is met. When a store is not performed, the trace decoder needs to be made aware in order to be able to correctly associate store packets in the data trace stream with the correct instruction.

lrid_width_p is determined by the maximum number of loads that can be in progress simultaneously, such that at any one time there can be no more than one load in progress with a given ID.

iaddr_lsbs and dblock are provided to support filtering of which data accesses to trace based on their instruction address. This is best illustrated by considering the following instruction sequence:

Suppose the hart is capable of retiring up to 4 instructions in a cycle, via a single block. Instruction trace is enabled throughout, but the requirement is to collect data trace for the 1st load (instruction 1), and filtering is configured to match the address of this instruction only. However, information about instruction addresses is passed to the encoder at the block level, and the block boundaries are invisible to the trace decoder. For instruction trace, all instructions in a block are traced if any of the instructions in that block match the filtering criteria. That is fine for instruction trace - the address of the 1st and final traced instruction are output explicitly. There will be some fuzziness about precisely what those addresses will be depending on where the block boundaries fall, but this is not a concern as everything is always self-consistent.

However, that is not the case for data trace. Consider two scenarios:

The signals from the 1.1.2. Instruction Trace Interface that provide details about the instruction block containing a data access instruction must be valid when dretire is active. Given this, the encoder knows the address of the 1st and last instructions in a block, but does not know precisely where in the block the data access is. In both cases, the first block matches the filtering criteria (it contains the address of instruction 1), and the second block does not. But if the encoder traced all the data accesses in the matching block, then in case 1 it would trace both instructions 1 and 3, whereas in the second case it would trace only instruction 1. The trace decoder has no visibility of the block boundaries so cannot account for this. It is expecting only instruction 1 to be traced, and so may misinterpret instruction 3. If this code is in a loop for example, it will assume that the 2nd traced load is in fact instruction 1 from the next loop iteration, rather than instruction 3 from this iteration.

Providing the LSBs of the data access instruction address allows the trace decoder to determine precisely whether the data access should be traced or not, and removes the dependency on the block sizes and boundaries. The number of bits required is one more bit than the number required to index within the block because blocks can start on any half-word boundary.

For harts that replicate the block signals to allow multiple blocks to retire per cycle it is also necessary to indicate which block each data access is associated with, so the encoder knows which block address to combine with the LSBs in order to construct the actual data access instruction address. 1 bit for 2 blocks per cycle, 2 bits for 4, and so on.