Suggestion of small corrections for v0.0.4

[Lauterbach-MIS]

Hi Iain,

as we've been discussing the changes to the RHTI in this week's DTPM meeting, I reviewed the document again in more detail.
From a technical perspective, I could not spot any functional changes, either.

But there are two tiny issues, that caught my attention. Maybe these should be corrected to make this specification even more readable.

1. In chapter 1.1 the term 'discontinuity' refers to the term 'delta' which is not explained. I'd suggest rewriting the description as 'delta' is otherwise not in the document. Perhaps we could use the 'delta' definition from the original E-Trace specification: "a change in the program counter that is other than the difference between two instructions placed consecutively in memory"
2. In chapter 2.1 the terms 'instruction_type' and 'instruction_address' are written in italics. As these terms are quite special and are highlighted I wondered if they refer to something. Unfortuantely, these terms do not appear in other places in this document, so some readers might wonder what these terms are referring to.

Best regards,
Michael

[IainCRobertson]

Michael I have made both the updates you suggested - see #27 and let me know if you're happy with this.

[Lauterbach-MIS]

Hello Iain.
Yes, the second point would be fixed by your commit. Thank you.
However, I was not able to see a change in the way the term 'discontinuity' is explained in chapter 1.1. The reference to 'delta' still points to nowhere. So, I suggest explaining 'discontinuity' as "a change in the program counter that is other than the difference between two instructions placed consecutively in memory".
What do you think about this?

[IainCRobertson]

Sorry Michael, that's my mistake - I forgot to commit the file (D'oh). Take another look - this should be fixed now. Iain From: Michael Schleinkofer ***@***.***> Sent: 23 September 2025 06:29 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] Suggestion of small corrections for v0.0.4 (Issue #11) [https://avatars.githubusercontent.com/u/149766666?s=20&v=4]Lauterbach-MIS left a comment (riscv-non-isa/hart-trace-interface#11)<#11 (comment)> Hello Iain. Yes, the second point would be fixed by your commit. Thank you. However, I was not able to see a change in the way the term 'discontinuity' is explained in chapter 1.1. The reference to 'delta' still points to nowhere. So, I suggest explaining 'discontinuity' as "a change in the program counter that is other than the difference between two instructions placed consecutively in memory". What do you think about this? - Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSXXWYIUYOFLRJ6SYWL3UDLAPAVCNFSM6AAAAACCH6LC5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRSGQ3TIMRYHE>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[Lauterbach-MIS]

No problem.
The changes look good to me. Thanks.

[IainCRobertson]

Thanks Michael. Re-opening as change not merged to main yet. Will close when this is done.

[pdonahue-ventana]

So, I suggest explaining 'discontinuity' as "a change in the program counter that is other than the difference between two instructions placed consecutively in memory".

What about a branch or jump to the next instruction? Are the following things discontinuities? I would say yes because trace needs to know about them.

  beq x0,x0,1f
1:

  la x1,1f
  jr x1
1:

  j 1f
1:

I think that a discontinuity happens whenever the PC mux isn't selecting the increment input. That's not really the right way to specify it but I think that's the idea.

[IainCRobertson]

Paul, You're making the further distinction between inferrable and uninferrable discontinuities. These are not mentioned explicitly in this list, although inferrable and uninferrable jumps are, as is updiscon. This can definitely be improved - I'll update. Iain From: Paul Donahue ***@***.***> Sent: 24 September 2025 00:28 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; State change ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] Suggestion of small corrections for v0.0.4 (Issue #11) [https://avatars.githubusercontent.com/u/48959409?s=20&v=4]pdonahue-ventana left a comment (riscv-non-isa/hart-trace-interface#11)<#11 (comment)> So, I suggest explaining 'discontinuity' as "a change in the program counter that is other than the difference between two instructions placed consecutively in memory". What about a branch or jump to the next instruction? Are the following things discontinuities? I would say yes because trace needs to know about them. beq x0,x0,1f 1: la x1,1f jr x1 1: j 1f 1: I think that a discontinuity happens whenever the PC mux isn't selecting the increment input. That's not really the right way to specify it but I think that's the idea. - Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSVJGIM2GUJ4CRA7SOD3UHJRNAVCNFSM6AAAAACCH6LC5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRVHA4DAMBRGU>. You are receiving this because you modified the open/close state.Message ID: ***@***.******@***.***>>

[IainCRobertson]

@pdonahue-ventana happy with this (#27)?

[pdonahue-ventana]

I still think that my concern hasn't been addressed. My understanding is that a branch to the next instruction is a discontinuity and an inferrable discontinuity. That PR says (1) that it's not a discontinuity because the PC change is to an instruction that's consecutive in memory and (2) that it's not an inferrable discontinuity because it's not a discontinuity.

[IainCRobertson]

Paul, I disagree. In my opinion a non-taken branch is not a discontinuity, as execution continues sequentially. The inferrable discontinuity definition does not imply that every branch or direct jump results in a discontinuity, just that if a discontinuity arises, it is inferrable. Iain From: Paul Donahue ***@***.***> Sent: 26 September 2025 18:10 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; State change ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] Suggestion of small corrections for v0.0.4 (Issue #11) [https://avatars.githubusercontent.com/u/48959409?s=20&v=4]pdonahue-ventana left a comment (riscv-non-isa/hart-trace-interface#11)<#11 (comment)> I still think that my concern hasn't been addressed. My understanding is that a branch to the next instruction is a discontinuity and an inferrable discontinuity. That PR says (1) that it's not a discontinuity because the PC change is to an instruction that's consecutive in memory and (2) that it's not an inferrable discontinuity because it's not a discontinuity. - Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSQLRYT2EULKRZVDJE33UVXPPAVCNFSM6AAAAACCH6LC5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZZGY4DENJXGI>. You are receiving this because you modified the open/close state.Message ID: ***@***.******@***.***>>

[pdonahue-ventana]

All of the branches/jumps that I listed are taken.

Let me restate the scenario with a different example. We have:

pc0:
  beq x1,x2,pc4
pc4:

Whether x1==x2 or not, the PC will go from pc0 to pc4 which are instructions which are "consecutive in memory." We agree that if x1!=x2 then the branch is not taken and this is not a discontinuity. The spec says that if x1==x2 then this is also not a discontinuity because pc4 is consecutive in memory. I believe that, because the branch is taken, it is a discontinuity. I think that the definition of discontinuity is flawed with respect to this example.

[IainCRobertson]

Paul, Okay, I understand where you are coming from now. However, I am still not convinced there is an issue with the definition. I guess it depends whether you think that a taken branch is always a discontinuity, or whether a discontinuity is first and foremost a non-sequential change of PC. You have illustrated a special case where a taken branch happens to move the PC to the next sequential value (i.e. the same as if it were non-taken). I agree that by the current definition that is not a discontinuity. The question is: does it matter? I don't think it does, but I also don't mind changing the definition if other disagree. The challenge is: how to change the definition in a way which is equally straightforward to understand. I don't want to end up with a much more complex definition that is not very easy to follow. Do you have any suggestions for how to reword? Iain From: Paul Donahue ***@***.***> Sent: 29 September 2025 17:00 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; State change ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] Suggestion of small corrections for v0.0.4 (Issue #11) [https://avatars.githubusercontent.com/u/48959409?s=20&v=4]pdonahue-ventana left a comment (riscv-non-isa/hart-trace-interface#11)<#11 (comment)> All of the branches/jumps that I listed are taken. Let me restate the scenario with a different example. We have: pc0: beq x1,x2,pc4 pc4: Whether x1==x2 or not, the PC will go from pc0 to pc4 which are instructions which are "consecutive in memory." We agree that if x1!=x2 then the branch is not taken and this is not a discontinuity. The spec says that if x1==x2 then this is also not a discontinuity because pc4 is consecutive in memory. I believe that, because the branch is taken, it is a discontinuity. I think that the definition of discontinuity is flawed with respect to this example. - Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSQ6BRQKTGC2RIIX7WT3VFJQDAVCNFSM6AAAAACCH6LC5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBXHAYTSMBUGE>. You are receiving this because you modified the open/close state.Message ID: ***@***.******@***.***>>

[pdonahue-ventana]

I think that it does matter, at least in some cases. In particular, an uninferrable jr to the following instruction would affect trace.

I don't have suggested language right now, but it would probably involve something about the next instruction being the target of a jump/branch rather than an incremented PC. In the cases I mentioned, the PC comes from the target address, not from the incrementor (even though both mux inputs have the same value).