Trace encoder behavior when using etrigger/itrigger with start, stop and notify actions

[Muhammad-Saadi-Abbasi]

An etrigger/itrigger is a type of trigger fired when a trap occurs. I have a couple of questions related to the trace encoder's behavior when the action of these triggers is either trace on, trace off, or trace notify.

Consider the following sequence of instructions for each question:

• X (the instruction before trap)
• Y (traps, either due to exception or interrupt)
• Z (first instruction of trap handler)

1. For the above instruction sequence, if an etrigger/itrigger fires with the action "trace on" (obviously fired on the trap), what should be the first instruction reported, Y or Z? If Y is reported, how can it be represented using a trap packet? The trap packet's address field points to instruction Y, and then the address of instruction Z is reported via a sync packet because if trap packet's address field points to instruction Z then the decoder can't know that which instruction's trap information is this. OR The same question without triggers: what is the encoder's behavior if the first instruction traced traps?

2. For the above instruction sequence, if an etrigger/itrigger fires with the action "trace notify," what should be the behavior of the trace encoder?
   The trace encoder is already going to report instruction X (because it retired before the trap) and instruction Z via a trap packet containing the trap information for instruction Y, assuming Y is not the target of an uninferable PC discontinuity. Since the trap packet doesn’t include a notify bit, does this mean the trace encoder should behave as it normally does when a trap occurs, or is some special handling required?

3. For the above instruction sequence, if an etrigger/itrigger fires with the action "trace off," what should be the value of the QualStat field in the support packet, which indicates that the trace has been disabled? The last instruction is reported via a trap packet with the address pointing to the trap handler, not because it is the last traced instruction. In this case, the QualStat value should be ended_ntr? However, the specification states that the QualStat value should be ended_ntr when the last instruction is reported because it is the target of uninferable PC discontinuity. The spec states Interrupts and exceptions are another form of uninferable PC discontinuity so QualStat value should be ended_ntr, correct?

[IainCRobertson]

Muhammad, See inline... Iain From: Muhammad Saadi Abbasi ***@***.***> Sent: 25 January 2025 10:52 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] Trace encoder behavior when using etrigger/itrigger with start, stop and notify actions (Issue #192) An etrigger/itrigger is a type of trigger fired when a trap occurs. I have a couple of questions related to the trace encoder's behavior when the action of these triggers is either trace on, trace off, or trace notify. Consider the following sequence of instructions for each question: * X (the instruction before trap) * Y (traps, either due to exception or interrupt) * Z (first instruction of trap handler) 1. For the above instruction sequence, if an etrigger/itrigger fires with the action "trace on" (obviously fired on the trap), what should be the first instruction reported, Y or Z? If Y is reported, how can it be represented using a trap packet? The trap packet's address field points to instruction Y, and then the address of instruction Z is reported via a sync packet because if trap packet's address field points to instruction Z then the decoder can't know that which instruction's trap information is this. OR The same question without triggers: what is the encoder's behavior if the first instruction traced traps? [Iain] Trace will start with a sync-trap packet reporting the address of Z and the ecause/tval from Y. 1. For the above instruction sequence, if an etrigger/itrigger fires with the action "trace notify," what should be the behavior of the trace encoder? The trace encoder is already going to report instruction X (because it retired before the trap) and instruction Z via a trap packet containing the trap information for instruction Y, assuming Y is not the target of an uninferable PC discontinuity. Since the trap packet doesn't include a notify bit, does this mean the trace encoder should behave as it normally does when a trap occurs, or is some special handling required? [Iain] The encoder will behave normally, and generate a sync-trap reporting the address of Z with ecause/tval from Y. The objective of the trace-notify trigger is to ensure that the instruction is explicitly reported, which it is. 1. For the above instruction sequence, if an etrigger/itrigger fires with the action "trace off," what should be the value of the QualStat field in the support packet, which indicates that the trace has been disabled? The last instruction is reported via a trap packet with the address pointing to the trap handler, not because it is the last traced instruction. In this case, the QualStat value should be ended_ntr? However, the specification states that the QualStat value should be ended_ntr when the last instruction is reported because it is the target of uninferable PC discontinuity. The spec states Interrupts and exceptions are another form of uninferable PC discontinuity so QualStat value should be ended_ntr, correct? [Iain] Yes, it will be ended_ntr. The point here is that ended_ntr is used when the final traced instruction was already reported (i.e. would still have been reported even if trace didn't stop). - Reply to this email directly, view it on GitHub<#192>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSU2ARUMAOKMYSOVGED2MNUETAVCNFSM6AAAAABV3HOBZ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSHAYTAOJSGEYDEMQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[Muhammad-Saadi-Abbasi]

Thanks.