Feedback on chapter 10 - RISC-V N-Trace (Nexus-based Trace) Specification
Closed this issue · 1 comments
-
"Plain linear instructions" is not a recognized term. RISC-V does not have a
PC relative jump. Suggest using more formal language - e.g., "looking at
binary code"
The two bullet under main rules can be stated:
"Instructions and traps specified in Table 2. result in trace messages." -
Detailed rule 1. "If tracing was disabled and restarted" is misleading as
it implies that a state machine is maintained to determine if tracing was
previously disabled and is restarted. The description of ProgTraceSync
accurately states that the message is generated when trace is either started
or restarted. Since the distinction is not important, the first bullet
should be rewritten to be accurate:
"When tracing is started, a ProgTraceSync message is generated"
The sub-bullets do not add any value here as the detailed description of
the message provides the contents of the message. -
Detailed rule 2 - is a repeat of main rule.
-
Detailed rule 3 - "Plain linear" is first used in Chapter 10 and is
not a Priv/Unpriv term. -
Detailed rule 3 - does not state a rule for generating messages - it says
how decoder should disassemble the binary using the trace. This should be
removed. -
Detailed rule 6 - the rule is not clear about when "stopped or disabled"
occurs. -
Detailed rule 7 - does not allow for generating IndirectBranchHistSync?
which is the recommended method for ICNT overflow as specified in section
8.4.4 -
Section 10.1 - the informative note implies that N-trace existed when
V or Zb or Zcmp were ratfiied. Suggest removing the note. -
Section 10.1 - "Custom instruction which may change PC" implies that there
are instructions that can leave PC unchanged. Every instruction by definition
changes the PC.
10.Section 10.1 - the rule can be better stated as simply - map the custom
instruction to a itype category that best matches the custom instruction.
If we want to elaborate more then it could be stated that classify the custom
instruction as:
- If it is a jump then classify as the jump as specified in section 4.1.1 of
the ETrace specification. Drive itype corresponding to this classification
to the trace encoder. - With this the example is redundant as decoders just fully the itype
Could move to examples appendix or remove
Further add a statement, if the instruction could not be classified to a
standard itype using rules in section 4 of etrace then use a custom itype
-
After reading through Chapter 10 - most of the contents here are repeated
from Chapter 7. Avoid repeated and redundant specification. -
Section 10.2 - Suggest moving section 10.2 to a non-normative appendix
as it is a simplified version and not normative specification. Also include
a pointer to the github for the reference encoder.
I am closing all N-Trace PDF related issues with same comments as all issues were handled via comments/discussions in SINGLE Google Docs. Relevant links are as follows:
Notes to N-Trace PDF: https://docs.google.com/document/d/1h__c0Kc7TQAWMh5bw9cNC9bl_IGqyY_ylPV14uc2xj0