Understanding the RISC-V Trigger Module

The Trigger module in the RISC-V architecture is one of the core components of its Debug System. It allows developers to set various debugging conditions, and when the processor runs and meets these conditions, it triggers specific debugging actions, such as interrupting processor execution or recording trace information.

Core Functions	Hardware Breakpoint	Pauses program execution at specified addresses, data, or conditions
Watchpoint	Monitors read/write operations to specific addresses or data
Program Tracing and Filtering	Conditionally records program flow, reducing redundant data output
Trigger Types	Address Trigger	Triggers when the address matches, with options for execution, read, write, etc.
Data Trigger (optional)	Triggers when the data value matches
Context/Mode Trigger (optional)	Triggers based on processor modes (e.g., user mode, machine mode) or context ID
Components and Registers	<span>tselect</span>	Selects the current trigger to configure or access
<span>tdata1</span>~<span>tdata7</span>	Configuration and data registers for triggers, for example, <span>tdata1</span> typically contains control information
<span>tinfo</span> (optional)	Provides information about trigger functionality
<span>tcontrol</span> (optional)	Global trigger control
<span>mcontext</span>/<span>scontext</span>/<span>hcontext</span> (optional)	Registers for context matching
Trigger Modes	Before Trigger	Checks conditions before instruction execution
After Trigger	Checks conditions after instruction execution
Action Types	Enter Debug Mode	The most common action, pauses the processor core and enters debug state, waiting for the debugger to connect
Trigger Trace Output	Generates trace packets
Raise Exception	Generates a specific exception
Implementation Options	Address/Data Trigger Options	Address trigger can be implemented without data trigger
Context Register Options	<span>mcontext</span>, <span>scontext</span>, <span>hcontext</span> etc. are optional
Number of Triggers Optional	The processor can implement a specific number of triggers (e.g., 1, 4, 8)

In the RISC-V specification, many trigger configuration fields are defined as WARL (Write-Any-Read-Legal). This means that software can write any value, but hardware may only support a subset. When reading this register, the actual valid values supported by the hardware will be returned (usually, unsupported function bits are read as 0).

Configuring and using a Trigger typically involves the following steps:

1. Select Trigger: Write the index value to the <span>tselect</span> register to select the trigger to configure.

2. Configure Trigger: Based on the selected trigger type, write the corresponding configuration information to the <span>tdata1</span>, <span>tdata2</span>, etc. registers. This includes setting trigger conditions (address, data, operation type, etc.) and trigger actions.

3. Enable Debugging: Ensure that the global debugging facility is enabled.

4. Run Program: The processor begins executing the program and monitors the Trigger conditions.

5. Trigger Handling: Once the conditions are met, the processor executes the preset trigger actions (e.g., entering debug mode)

These include three core concepts:

1. trigger_hit: Whether the current instruction or data access meets the conditions set by the trigger
2. trigger_chain: Whether multiple triggers match successfully in the preset order, used to implement complex condition judgments
3. trigger_action: The operation that the hardware automatically executes when the trigger matches successfully

trigger_hit

Indicates that the matching condition of a specific trigger has been met

Source: It is generated by an independent trigger module (e.g., mcontrol6). This module continuously monitors the execution flow, memory access, or data values of the processor based on its configuration registers (such as tdata1, tdata2) settings.

Matching Conditions: Common matching conditions include:

• Instruction Address (PC): Triggered when executing instructions at a specific address

• Data Address (Load/Store): Triggered when reading/writing to a specific memory address

• Data Value: Triggered when the data read or written equals a specific value (this function is usually an optional implementation)

• Opcode: Triggered when encountering a specific instruction

trigger_chain

Indicates that all connected triggers in a trigger chain (Trigger Chain) have matched successfully

Purpose: To implement complex breakpoint conditions that a single trigger cannot independently describe. For example:“Interrupt when function A is called, and function B accesses the global variable global_var inside it”

Working Principle:

1. Chain Configuration: By setting the configuration registers of each trigger in the chain (such as chain bit fields), they are logically linked together.

2. Logical AND: The essence of trigger_chain_hit is to perform a logical AND operation on the trig_hit signals of all triggers in the chain. Only when all triggers report a hit does the entire chain report a hit

3. Length Limitation: Due to hardware implementation complexity, the RISC-V debugging specification allows setting an upper limit on the length of trigger chains (e.g., m). The chain configuration enable signal (such as chain_enable) is only valid when the effective length of the chain does not exceed this limit, allowing triggers to join the chain.

trigger_action

Defines the operation that the hardware should automatically execute when a trigger matches successfully (or when the entire trigger chain matches successfully). This behavior is pre-set in the configuration registers of the trigger (such as tdata1 action field).

Common Actions:

• Breakpoint (断点): Pauses the processor (Halt) execution. This is the most commonly used action, allowing the debugger to check the processor state at this moment

• Trigger into Debug Mode (进入调试模式): Generates a debug mode trap

• Exception (异常): Generates a specific exception

• Trace (跟踪): Issues a trace packet to record execution flow or data access, but usually does not stop program execution

Cooperation with Chains:

• The trig_action of the last trigger in the chain can be configured to the desired action (e.g., breakpoint)

• All triggers in the chain can also have their actions set to 0 (chained), meaning they do not produce independent actions but only participate in chain matching, with the final action defined by the last trigger in the chain

Operational Process and Example

Suppose you want to implement a complex breakpoint:“Interrupt when the program counter (PC) is at address 0x80001000 and the value of register x5 equals 0x12345678 .”

1.Configure Trigger#1:

Type: Set to match instruction address (execute)

Address (tdata2):0x80001000.

Action (action): May be set to 0 (chained), as it is only part of the condition

Chain (chain): Set to allow chaining to the next trigger

2.Configure Trigger#2:

Type: Set to match data value (for example, check the value of x5 when the instruction is executed at the specified address)

Value (tdata2):0x12345678

Action (action): Set to 1 (Breakpoint, pause the processor)

Chain (chain): Set to the end of the chain or appropriate value

3.Operational Process:

• The processor executes

• When the PC reaches 0x80001000, Trigger #1 generates a trig_hit signal

• At the same time, the hardware detects that the value of x5 equals 0x12345678, and Trigger #2 also generates a trig_hit signal

• The debug module detects that these two triggers form a chain, and their trig_hit signals are true simultaneously, thus generating a trig_chain_hit signal

• The trig_chain_hit signal is valid, causing the trig_action configured for Trigger #2 (breakpoint) to be triggered

• The processor pauses execution, enters debug state, and waits for further operations from the debugger