riscv-non-isa/tg-nexus-trace

Feedback on RISC-V Trace Control Interface Specification - Chapter 1, 2, and 3

ved-rivos opened this issue · 1 comments

  1. Document state should be Stable. The copyright should match the RVI template.
  2. Chapter 1 - "Both Trace Working Groups..." this sentence be removed.

Chapter 2:

  1. Reword first and second paragraph.
  2. First bullet - "It describes RISC-V Trace Ingress..." can be removed
  3. Page 6 - replace "master" with a better and inclusive term.

Chapter 3:

  1. It is customary to have the glossary in the Introduction chapter.
  2. Section 3.1 - For terms defined in E-trace glossary would want to
    use identically to avoid subtly different terminology.
    • Trace Encoder
    • Trace Message/Packet
    • Trace Decoder
  3. Section 3.1 - Trace funnel - the definition should be expanded to
    include inputs from other trace funnels - as allowed by section 3.8
  4. Section 3.1 - R - usually R denotes readable and not read-only. The
    conventional notation for read-only is RO.
  5. Bit/field can be replaced with field everywhere as fields can be
    single bit wide.
  6. Section 3.1 - RW - we should avoid bits that have side effects.
    If there really are no bits that are volative and RW then please
    update the description. If there are please justify the definition.
  7. Section 3.1 - WARL - please adopt the Priv spec definition for WARL
  8. Section 3.1 - ATB - parenthesis can be removed. Please add a bibliography
    and full reference to the ARM specification.
  9. Section 3.2 - the heading of the section does not match the contents.
  10. Section 3.6 - informational note - The note about Nexus Format
    should be stated as an example.
  11. Section 3.6.2 - Any reason for omitting (usually bytes) for System
    Memory Sink as compared to SRAM sink? "DMA-type bus master" -> "DMA
    controller".
  12. Section 3.7 - "ATB bus master" -> "ATB initiator"
  13. Section 3.7 - Reword second sentence.
  14. Section 3.7 - ATB Bridge - Could the trace funnel or trace encoder
    not directly emit on a ATB. Please explain why a bridge is required
    and what is bridge to ATB.
  15. Section 3.8 - is it assumed or it is required to have unique source ID?
    Should the note should be rewritten to state that trace messages that are
    input to the funnel are required to include a unique message source ID?
    The teSrcID is not a funnel control register so the parenthetical use
    somehow implies these signals are input to the funnel.

All notes to Control PDF as 1.0.0_rc20.