Last traced instruction is the 31st branch instruction

[Muhammad-Saadi-Abbasi]

What is the correct encoder behavior when the last traced instruction is the 31st branch instruction?

The spec states:

If tracing stops for any reason, the address of the final traced instruction must be output.

The address needs to be emitted along with the direction of 31 branches, but Format 1 with an address packet can only have branches = 31 when:

The instruction immediately prior to the final branch causes an uninferable discontinuity, in which case branches is set to 31.

I believe that when the encoder emits a Format 1 packet without an address, it implicitly reports the address of the 31st branch. However, this contradicts the spec statement that the address of the final traced instruction must be explicitly output.

[IainCRobertson]

Muhammad, When the branch map fills, a format 1 message will be output. This will include an address (branches=31) if the instruction prior to the branch is an indirect jump. However, it will also include an address if that branch is the final traced instruction, regardless of the nature of the previous instruction. Is there some wording in the spec that makes you think that this is not the case? Iain From: Muhammad Saadi Abbasi ***@***.***> Sent: 22 April 2025 10:43 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] Last traced instruction is the 31st branch instruction (Issue #225) What is the correct encoder behavior when the last traced instruction is the 31st branch instruction? The spec states: If tracing stops for any reason, the address of the final traced instruction must be output. The address needs to be emitted along with the direction of 31 branches, but Format 1 with an address packet can only have branches = 31 when: The instruction immediately prior to the final branch causes an uninferable discontinuity, in which case branches is set to 31. I believe that when the encoder emits a Format 1 packet without an address, it implicitly reports the address of the 31st branch. However, this contradicts the spec statement that the address of the final traced instruction must be explicitly output. - Reply to this email directly, view it on GitHub<#225>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSR44NLIAQ3KMNVVSUD22YFJJAVCNFSM6AAAAAB3TGUQ2SVHI2DSMVQWIX3LMV43ASLTON2WKOZTGAYTANJTHA3TSNY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>> [https://avatars.githubusercontent.com/u/111724345?s=20&v=4]Muhammad-Saadi-Abbasi created an issue (riscv-non-isa/riscv-trace-spec#225)<#225> What is the correct encoder behavior when the last traced instruction is the 31st branch instruction? The spec states: If tracing stops for any reason, the address of the final traced instruction must be output. The address needs to be emitted along with the direction of 31 branches, but Format 1 with an address packet can only have branches = 31 when: The instruction immediately prior to the final branch causes an uninferable discontinuity, in which case branches is set to 31. I believe that when the encoder emits a Format 1 packet without an address, it implicitly reports the address of the 31st branch. However, this contradicts the spec statement that the address of the final traced instruction must be explicitly output. - Reply to this email directly, view it on GitHub<#225>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSR44NLIAQ3KMNVVSUD22YFJJAVCNFSM6AAAAAB3TGUQ2SVHI2DSMVQWIX3LMV43ASLTON2WKOZTGAYTANJTHA3TSNY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[Muhammad-Saadi-Abbasi]

Is there some wording in the spec that makes you think that this is not the case?

Yes, I believe the spec clearly states that the trace encoder can only use a format 1 packet with address and branches=31 when the 31st branch is the target of an uninferable PC discontinuity.

[IainCRobertson]

Muhammad, I see the text which you are referring to, at the top of section 7.7.2. I agree that is a little misleading - it is not meant to imply that this is the only reason. There are several reasons why an address may need reporting, and this is only one. It's meant to be explaining why we need a special case for 31 branches (with and without address), not mandating that it is for one use only. The 1st paragraph in section 7.7 (Format 1 packets) says: This packet includes branch information, and is used when either the branch information must be reported (for example because the branch map is full), or when the address of an instruction must be reported, and there has been at least one branch since the previous packet. And this is key requirement. I have reworded to make this clear. See #226 Iain From: Muhammad Saadi Abbasi ***@***.***> Sent: 22 April 2025 17:17 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Last traced instruction is the 31st branch instruction (Issue #225) Is there some wording in the spec that makes you think that this is not the case? Yes, I believe the spec clearly states that the trace encoder can only use a format 1 packet with address and branches=31 when the 31st branch is the target of an uninferable PC discontinuity. - Reply to this email directly, view it on GitHub<#225 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSTVU2BSZLBYGXJSVYT22ZTPTAVCNFSM6AAAAAB3TGUQ2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRRHAZTINJYGA>. You are receiving this because you commented.Message ID: ***@***.******@***.***>> [https://avatars.githubusercontent.com/u/111724345?s=20&v=4]Muhammad-Saadi-Abbasi left a comment (riscv-non-isa/riscv-trace-spec#225)<#225 (comment)> Is there some wording in the spec that makes you think that this is not the case? Yes, I believe the spec clearly states that the trace encoder can only use a format 1 packet with address and branches=31 when the 31st branch is the target of an uninferable PC discontinuity. - Reply to this email directly, view it on GitHub<#225 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSTVU2BSZLBYGXJSVYT22ZTPTAVCNFSM6AAAAAB3TGUQ2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRRHAZTINJYGA>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[Muhammad-Saadi-Abbasi]

Great, thanks, the updated wording makes it much clearer now. Appreciate the quick clarification.

[Muhammad-Saadi-Abbasi]

Hi Iain, (I accedential pressed cltr+enter in the above comment and GitHub is not letting me edit or delete the comment)

I have one more question related to format 1 packets where branches = 31. Consider the following scenario:

PC: X ---> 31st branch instruction (not all branches were predicted correctly)
<some sequential and non-branch instructions>
PC: Y ---> trap / uninferable PC discontinuity

In the above scenario, what should be the correct trace encoder behavior?

• Behavior 1:

  • Emit a format 1 packet with no address and branches = 0

  • Follow it with a format 2 packet to report the target of the uninferable PC discontinuity, or the last retired instruction before the trap

• Behavior 2:

  • Emit a format 1 packet with an address and branches = 31, where the address field points to either the target of the uninferable PC discontinuity, or the last retired instruction before the trap

If your answer is Behavior 1, then it implies that whenever the branch map becomes full, the encoder emits the packet immediately.

If your answer is Behavior 2, then it means the encoder waits for either a branch instruction or an uninferable PC discontinuity. If it encounters a branch, it emits a format 1 packet with no address and starts accumulating the branches again. If it encounters an uninferable PC discontinuity or trap, it emits a format 1 packet with an address and branches = 31.

[IainCRobertson]

Muhammad, Scenario 1 is the expected behaviour. Iain From: Muhammad Saadi Abbasi ***@***.***> Sent: 25 April 2025 13:09 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; State change ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Last traced instruction is the 31st branch instruction (Issue #225) [https://avatars.githubusercontent.com/u/111724345?s=20&v=4]Muhammad-Saadi-Abbasi left a comment (riscv-non-isa/riscv-trace-spec#225)<#225 (comment)> Hi Iain, (I accedential pressed cltr+enter in the above comment and GitHub is not letting me edit or delete the comment) I have one more question related to format 1 packets where branches = 31. Consider the following scenario: PC: X ---> 31st branch instruction (not all branches were predicted correctly) <some sequential and non-branch instructions> PC: Y ---> trap / uninferable PC discontinuity In the above scenario, what should be the correct trace encoder behavior? * Behavior 1: * Emit a format 1 packet with no address and branches = 0 * Follow it with a format 2 packet to report the target of the uninferable PC discontinuity, or the last retired instruction before the trap * Behavior 2: * Emit a format 1 packet with an address and branches = 31, where the address field points to either the target of the uninferable PC discontinuity, or the last retired instruction before the trap If your answer is Behavior 1, then it implies that whenever the branch map becomes full, the encoder emits the packet immediately. If your answer is Behavior 2, then it means the encoder waits for either a branch instruction or an uninferable PC discontinuity. If it encounters a branch, it emits a format 1 packet with no address and starts accumulating the branches again. If it encounters an uninferable PC discontinuity or trap, it emits a format 1 packet with an address and branches = 31. - Reply to this email directly, view it on GitHub<#225 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSTY2QJ6PLSR4GBFWTT23IQU3AVCNFSM6AAAAAB3TGUQ2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZQGI2DMNBXG4>. You are receiving this because you modified the open/close state.Message ID: ***@***.******@***.***>>

[Muhammad-Saadi-Abbasi]

You mean behavior 1. Thanks.

[IainCRobertson]

Yes, sorry for using different terminology.