Skip to content

Commit

Permalink
N-Trace 1.0.0_rc27 - Second set of ARC notes DONE.
Browse files Browse the repository at this point in the history
  • Loading branch information
mipsrobert committed May 2, 2024
1 parent 8e9d090 commit 133df5f
Showing 1 changed file with 13 additions and 14 deletions.
27 changes: 13 additions & 14 deletions docs/RISC-V-N-Trace.adoc
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
[[header]]
:description: RISC-V N-Trace (Nexus-based Trace)
:company: RISC-V.org
:revdate: Apr 01, 2024
:revnumber: 1.0.0_rc26
:revremark: Stable state (before SYNC clarifications)
:revdate: May 02, 2024
:revnumber: 1.0.0_rc27
:revremark: Stable state (Second set of ARC notes DONE)
:url-riscv: http://riscv.org
:doctype: book
:preface-title: Preamble
Expand Down Expand Up @@ -50,10 +50,9 @@ Change is extremely unlikely.

PDF generated on: {localdatetime}

=== Version 1.0.0_rc26
* 2024-04-01
** 'itype' clarifications done.
** TODO: SYNC clarification (email exchange with Ved).
=== Version 1.0.0_rc27
* 2024-05-02
** Second set of ARC notes DONE

[Preface]
== Copyright and license information
Expand Down Expand Up @@ -1469,16 +1468,16 @@ Trace requires different types of synchronization on different abstraction level
|14..15| Reserved |-| For vendor defined codes.
|====

Decoders should report synchronization SYNC field values from messages (including reserved codes) as it provides a reason of the program flow change. Periodic Synchronization are generated to allow easier decoding (not necessarilly from the start of collected trace) and may only be reported when desired by the user (for debugging).
Decoders should report synchronization SYNC field values from messages (including reserved codes) as it provides a reason of the program flow change.

NOTE: Periodic Synchronization (SYNC=2) messages may be delayed if anyother SYNC message (for example Sequential Instruction Counter, SYNC=4) needs to be sent in the same moment. In such a case, Periodic Synchronization may be even skipped as decoding may start from any Synchronizing Message.
* All synchronizing messages fully reset the encoder state, so decoding can be started from this message.
** Before resetting the encoder state, the trace up to the current location must be emitted (it includes HIST, ICNT, HREPEAT and BCOUNT counters).
* All synchronizing messages emit an absolute <<field_TSTAMP,TSTAMP>> field (if enabled), so decoder may calculate full/absolute timestamps from this message forward.
* An <<msg_Ownership,Ownership>> messages (if enabled) must be emitted immediatelly after all synchronizing messages.

Periodic Synchronization are generated to allow easier decoding (not necessarilly from the start of collected trace) and may only be reported when desired by the user (for debugging).

[IMPORTANT]
====
* All synchronizing messages fully reset the encoder state, so decoding can be started from this message.
* All synchronizing messages emit an absolute <<field_TSTAMP,TSTAMP>> field (if enabled), so decoder may report full/absolute timestamp.
====
NOTE: Periodic Synchronization (SYNC=2) messages may not be precise and may be delayed if anyother SYNC message (for example Sequential Instruction Counter, SYNC=4) is sent. In such a case, Periodic Synchronization may be even skipped as decoding may start from any Synchronizing Message.

==== Examples of Synchronizing Messages

Expand Down

0 comments on commit 133df5f

Please sign in to comment.