search

riscv-non-isa / tg-nexus-trace

RISC-V Nexus Trace TG documentation and reference code
https://jira.riscv.org/browse/RVG-96
Creative Commons Attribution 4.0 International
44 stars 32 forks source link

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

Closed ved-rivos closed 7 months ago

ved-rivos commented 7 months ago

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 commented 7 months ago

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