Feedback on RISC-V N-Trace Specification 1.0.0 rc2.0 - chapter 9 and 10.

[ved-rivos]

Chapter 9:
Editorial suggestions:

1. Section 9.1 "Jump targets that supplied via" -> "Some jump targets may be supplied via:"
2. Section 9.2 - "and is reset to 0 whenever a synchronization packet" was that meant to say Synchronizing ?
3. Suggest using messages or packets consistently. Message seems to be used more often than packet in this specification.
4. Section 9.2 "Such deep calls will be most likely 'broken' by other events/messages" - replace broken by interrupted.

Chapter 10:

1. Calling interrupts and exceptions as non-inferable instructions is not right. Restate main rules as
   "Main Rules
   • Inferable Instructions: This category includes instructions that neither perform control transfers nor
     are direct jumps. The subsequent program counter (PC) for these instructions can be accurately
     predicted through static analysis of the binary code. Because these instructions exhibit a predictable
     execution flow, they are termed "inferable," and no trace is generated for them. In BTM, a not-taken
     conditional branch is also classified as inferable.

• Non-Inferable Instructions: This category comprises conditional and indirect branches, distinguished
  by their ability to generate a trace. Due to the unpredictability of the next PC as determined through
  static analysis alone, non-inferable instructions require trace generation for precise control flow tracking.
• Interrupts and Exceptions: Control flow changes caused by interrupts and exceptions necessitate
  trace generation. These events alter the flow in an unpredictable manner, similar to non-inferable
  instructions, thereby requiring their occurrences to be traced for accurate analysis."

2. First detailed rule implies that ProgTraceSync is generated only when tracing is started after it was
   disabled. Is that intended that the very first enabling of trace does not generate ProgTraceSync. If
   not then suggest updating as:
   "If tracing is started (or restarted after being disabled), a ProgTraceSync message is generated. This
   message specifies the reason for the start in the SYNC field and includes the full address in the F-ADDR field."

3. "Any retired instruction increments I-CNT field (+1 or +2)." -> the increment should be on the counter and not
   a message field.
   "A retired 16-bit instruction increments the I-CNT counter by 1, while a retired 32-bit instruction increments it by 2."

4. The third bullet of the detailed rules repeats the main rule for inferable instructions. Can replace the
   third point and its sub-bullets with a single statement "Inferable instructions do not generate any trace"

5. First extended rule states that call and return maintain call stack. However, implicit return optimization does
   not require maintaining a call stack as there is an option to implement a counter.

Editorial:

1. "This chapter..."->
   "This chapter explicitly addresses 16-bit and 32-bit instructions as defined in the currently
   ratified instruction set. Nonetheless, the guidelines provided herein are applicable to any
   instruction size that is a multiple of 16-bit, should such instructions be defined in the future. "

2. Detailed rules 4th point
   "Indirect branch instructions are handled as follows:

   • In BTM mode, an IndirectBranch message is generated.
   • In HTM mode, an IndirectBranchHist message is produced. Should the HIST field be
     empty, an IndirectBranch message may optionally be generated instead."

3. Detailed rules 5th point
   "Conditional Branch Instructions are handled as follows:

   • In BTM mode, a DirectBranch message is generated, but only if the branch is taken.
   • In HTM mode, the outcome of the branch (1 for taken, 0 for not taken) is appended
     as a single bit to the branch history buffer (HIST register).

4. Detailed rules 6th point
   "When tracing is stopped or disabled, a ProgTraceCorrelation message is generated.
   This message includes the reason for stopping or disabling (specified in the EVCODE
   field), the I-CNT, and an optional HIST field. These details allow for the calculation of the last PC."

5. Detailed rules 7th point
   "When a generated message includes I-CNT counter value or HIST register value, the
   corresponding counter and/or register are reset.

   • If the I-CNT counter reaches its capacity, a ResourceFull message, indicating that the
     I-CNT counter is full, is generated. Subsequently, the I-CNT counter is reset.
   • Similarly, if the HIST register reaches its capacity, a ResourceFull message, specifying
     that the HIST register is full, is generated. The HIST register is then reset."

[mipsrobert]

Addressed in 1.0.0_rc25 (or even earlier ...) version.