Trap Counter Implementation Details: Per-Filter vs Global, Vertical/Horizontal Traps, and Interaction with tval Latch Mode

[xingpenghu]

Questions
1. Trap Counter: Global vs Per-Filter Implementation
According to the Trace Control Interface specification, the filter_excint_p parameter indicates support for nested exception filtering. The trap counter itself should be implemented as a single global counter shared across all filters or separate counter instance per filter (trTeFilter0, trTeFilter1, etc.)
2. Vertical Traps vs Horizontal Traps
When the trap counter is active, which trap transitions (Vertical Traps or Horizontal Traps)should increment/decrement the counter?
3. Trigger and End Conditions Clarification
3.1 Trigger exclusivity: Are trTeFilterMatchEcause and trTeFilterMatchInterrupt the only conditions that can activate the trap counter qualify interval? Or can comparator matches (e.g., trTeFilterMatchCompX) also trigger trap counter qualification(such as tval)?
3.2 End condition exclusivity: Is trap counter == 0 ? When Mode 3 latch is used( tval with Mode 3 Latch) combined with trap counter, what is the actual end condition for the qualify interval?

[IainCRobertson]

See inline... Iain From: xingpenghu ***@***.***> Sent: 12 March 2026 12:29 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] Trap Counter Implementation Details: Per-Filter vs Global, Vertical/Horizontal Traps, and Interaction with tval Latch Mode (Issue #296) [https://avatars.githubusercontent.com/u/190453149?s=20&v=4]xingpenghu created an issue (riscv-non-isa/riscv-trace-spec#296)<#296> Questions 1. Trap Counter: Global vs Per-Filter Implementation According to the Trace Control Interface specification, the filter_excint_p parameter indicates support for nested exception filtering. The trap counter itself should be implemented as a single global counter shared across all filters or separate counter instance per filter (trTeFilter0, trTeFilter1, etc.) [Iain] Per filter 2. Vertical Traps vs Horizontal Traps When the trap counter is active, which trap transitions (Vertical Traps or Horizontal Traps)should increment/decrement the counter? [Iain] Sorry, I don't know what you mean by horizontal/vertical in this context. The whole point is to keep the filter active until the return from the trap which activated the filter. So every trap should increment the counter, and every return decrement it. 3. Trigger and End Conditions Clarification 3.1 Trigger exclusivity: Are trTeFilterMatchEcause and trTeFilterMatchInterrupt the only conditions that can activate the trap counter qualify interval? Or can comparator matches (e.g., trTeFilterMatchCompX) also trigger trap counter qualification(such as tval)? [Iain] Yes, only Ecause and Interrupt. Otherwise you could get unpredictable results if (for example) the address of the trap matched but the address of the return didn't. You wouldn't want the counter to increment on entry to the trap but not decrement on the return. 3.2 End condition exclusivity: Is trap counter == 0 ? When Mode 3 latch is used( tval with Mode 3 Latch) combined with trap counter, what is the actual end condition for the qualify interval? [Iain] The mode 3 latch is associated with the comparator. The comparator match result is ANDed with the rest of the filtering criteria. So if a return causes the nested trap counter to return to 0, matching ends at that point (after the return). - Reply to this email directly, view it on GitHub<#296>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSVYX34RSXQB2N6DGXD4QKUQ5AVCNFSM6AAAAACWPTYEE6VHI2DSMVQWIX3LMV43ASLTON2WKOZUGA3DIMZSG4ZDCNQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[xingpenghu]

Thank you lain. @IainCRobertson

1. Trap Counter Increment Logic
The privileged architecture specification distinguishes between "Vertical Traps" (which change the privilege level) and "Horizontal Traps" (which retain the privilege level).
Question: Does the trap counter increment based on every trap occurrence regardless of type, or only when a "Vertical Trap" (involving a privilege level change) occurs?
2. Comparator Qualification Timing for tval
If a comparator is set to match the tval field:
Does the expected qualify signal/assertion refer strictly to the single cycle where the match occurs?
Or does it trigger a range (a span of cycles) starting from the cycle where the match is detected?

[IainCRobertson]

Xing Peng, See in line, and also refer to my previous reply to Frank. Iain From: xingpenghu ***@***.***> Sent: 13 March 2026 07:05 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA IC DDCP TST RD SLE EAH) ***@***.***>; Mention ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Trap Counter Implementation Details: Per-Filter vs Global, Vertical/Horizontal Traps, and Interaction with tval Latch Mode (Issue #296) [https://avatars.githubusercontent.com/u/190453149?s=20&v=4]xingpenghu left a comment (riscv-non-isa/riscv-trace-spec#296)<#296 (comment)> Thank you lain. @IainCRobertson<https://github.com/IainCRobertson> 1. Trap Counter Increment Logic The privileged architecture specification distinguishes between "Vertical Traps" (which change the privilege level) and "Horizontal Traps" (which retain the privilege level). Question: Does the trap counter increment based on every trap occurrence regardless of type, or only when a "Vertical Trap" (involving a privilege level change) occurs? [Iain] Every trap. This is not about the privilege level, it's about being able to properly identify the *RET associated with trap from which we started tracing. 2. Comparator Qualification Timing for tval If a comparator is set to match the tval field: Does the expected qualify signal/assertion refer strictly to the single cycle where the match occurs? Or does it trigger a range (a span of cycles) starting from the cycle where the match is detected? [Iain] It's part of the conditions that cause the trap counter to increment from zero. Once the counter is non-zero it is not considered again. - Reply to this email directly, view it on GitHub<#296 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSQIMAB3E632SZFDMO34QOXJLAVCNFSM6AAAAACWPTYEE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJTGIYTEMZQGM>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[xingpenghu]

Hi, lain. @IainCRobertson
I would like to confirm my understanding of the Trap Counter logic.
The Trap Counter is triggered to increment under the following conditions:

1. The filter condition is met (indicated by either trTeFilterMatchEcause or trTeFilterMatchInterrupt being active).
2. The comparator is configured to monitor the tval field (via trTeCompPInput).
   When all these conditions are satisfied, the Trap Counter increments by 1. Furthermore, while the Trap Counter is non-zero, the qualify signal remains asserted (high).

If the comparator (trTeCompPInput) is set to monitor tval, and the match mode (trTeCompMatchMode) is set to 3 (which typically implies a Primary-Secondary combined condition):
Does the Trap Counter increment based solely on the Primary result being true, effectively ignoring the Secondary result?

Thanks for your help.

[IainCRobertson]

Xing Peng, See inline... Iain From: xingpenghu ***@***.***> Sent: 13 March 2026 10:33 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA IC DDCP TST RD SLE EAH) ***@***.***>; Mention ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Trap Counter Implementation Details: Per-Filter vs Global, Vertical/Horizontal Traps, and Interaction with tval Latch Mode (Issue #296) [https://avatars.githubusercontent.com/u/190453149?s=20&v=4]xingpenghu left a comment (riscv-non-isa/riscv-trace-spec#296)<#296 (comment)> Hi, lain. @IainCRobertson<https://github.com/IainCRobertson> I would like to confirm my understanding of the Trap Counter logic. The Trap Counter is triggered to increment under the following conditions: 1. The filter condition is met (indicated by either trTeFilterMatchEcause or trTeFilterMatchInterrupt being active). 2. The comparator is configured to monitor the tval field (via trTeCompPInput). When all these conditions are satisfied, the Trap Counter increments by 1. Furthermore, while the Trap Counter is non-zero, the qualify signal remains asserted (high). [Iain] Yes, although instructions may still not be traced if for example their address doesn't match. The overall qualify signal can be thought of as comprising multiple terms ANDed together: the trap counter envelope, and other filter conditions (iaddr, priv, etc) If the comparator (trTeCompPInput) is set to monitor tval, and the match mode (trTeCompMatchMode) is set to 3 (which typically implies a Primary-Secondary combined condition): Does the Trap Counter increment based solely on the Primary result being true, effectively ignoring the Secondary result? [Iain] It will behave the same for the 1st trap but differently for subsequent ones. I think this particular configuration may not be a useful one, but consider the following example: * Initial state: not qualified * Trap occurs that matches all filtering conditions * Comparator becomes set as it's in mode 3 * Trap ends and tracing stops * Note that at this point the comparator is still set * Later, another trap occurs. This matches ecause/int criteria. The trap counter will increment and tracing will start, regardless of the tval value, because the tval match comparator is still set to 'match' * Tval will therefore be ignored until whatever secondary match condition occurs to clear the comparator Thanks for your help. - Reply to this email directly, view it on GitHub<#296 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPST3VEV3XGOGXKQMQWL4QPPWRAVCNFSM6AAAAACWPTYEE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJUGE2TCNRTGU>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[xingpenghu]

Hi, lain. @IainCRobertson

1. Qualify Signal Behavior for Normal Instructions
When a filter is configured with:
trTeFilterMatchEcause set to match an illegal instruction exception (e.g., mcause=0x0B)
trTeFilterMatchInterrupt=0 (only match exceptions)
Comparator configured to match instruction address (iaddress)
Question:
Even if a normal instruction (outside the trap handler flow) matches the iaddress comparator, the qualify signal does not assert high.Is this expected behavior?

2. Filter Configuration for Normal Instruction Flow
To qualify only normal instruction flow (excluding exceptions/interrupts), I propose:
Set trTeFilterMatchEcause=0
Set trTeFilterMatchInterrupt=0
Configure Comparator to match all iaddress
Question:
Will this configuration effectively filter out only normal instruction flow? Specifically:

• Does an invalid trTeFilterEcause value ensure the Filter never matches any exception/interrupt?

• Will the comparator match all iaddress values, whether in the trap-related instruction flow (inside or outside), and trigger the qualify signal accordingly?

[IainCRobertson]

Xing Peng, See inline... Iain From: xingpenghu ***@***.***> Sent: 16 March 2026 04:22 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA IC DDCP TST RD SLE EAH) ***@***.***>; Mention ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Trap Counter Implementation Details: Per-Filter vs Global, Vertical/Horizontal Traps, and Interaction with tval Latch Mode (Issue #296) [https://avatars.githubusercontent.com/u/190453149?s=20&v=4]xingpenghu left a comment (riscv-non-isa/riscv-trace-spec#296)<#296 (comment)> Hi, lain. @IainCRobertson<https://github.com/IainCRobertson> 1. Qualify Signal Behavior for Normal Instructions When a filter is configured with: trTeFilterMatchEcause set to match an illegal instruction exception (e.g., mcause=0x0B) trTeFilterMatchInterrupt=0 (only match exceptions) Comparator configured to match instruction address (iaddress) Question: Even if a normal instruction (outside the trap handler flow) matches the iaddress comparator, the qualify signal does not assert high.Is this expected behavior? [Iain] Yes, that's correct. If ecause/int/tval filtering is enabled the objective here is to trace the trap handler that matches that condition. Anything outside the handler will be ignored. Only once you're inside the handler will any iaddress matching come into play. If you want to be able to trace A particular trap handler, but also a range of instruction addresses outside the handler then you need to use two filters . 2. Filter Configuration for Normal Instruction Flow To qualify only normal instruction flow (excluding exceptions/interrupts), I propose: Set trTeFilterEcause to an invalid value (e.g., 0xFFFFFFFF) to ensure no exception matches Set trTeFilterMatchInterrupt=0 to exclude interrupts Configure Comparator to match all iaddress Question: Will this configuration effectively filter out only normal instruction flow? Specifically: * Does an invalid trTeFilterEcause value ensure the Filter never matches any exception/interrupt? * Will the comparator match all iaddress values, whether in the trap-related instruction flow (inside or outside), and trigger the qualify signal accordingly? [Iain] That's an interesting use-case and one which the spec does not explicitly address. Your suggestion will not work: If trTeMatchEcause is 1, it will only trace trap handlers which match the specified choice of causes, and if you select an illegal cause, none will ever match. Nothing at all will be traced. What I would suggest here is that if trTeMatchEcause is 1 but trTeMatchChoiceEcause is all zero then this is treated as a special case meaning trace everything apart from traps. It would trace only when the trap counter is 0 instead of when it is 1. As currently defined this combination would result in nothing ever being traced, and therefore isn't currently a meaningful or sensible configuration choice. So if you implement this you won't be in violation of the spec. I propose we add this as an informative suggestion to the spec. - Reply to this email directly, view it on GitHub<#296 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPST6M5JIQYLCUP4CZGT4Q56PNAVCNFSM6AAAAACWPTYEE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRUHE2TOMBZGA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>