Update RISC-V-Trace-Control-Interface.adoc

Signed-off-by: Robert Chyla (MIPS) <[email protected]>

docs/RISC-V-Trace-Control-Interface.adoc

@@ -252,6 +252,7 @@ Different components must be connected via internal busses and/or FIFO buffers.
 NOTE: Sending RISC-V trace to Arm CoreSight infrastructure is allowed (via ATB Bridge), but this specification does not specify how to transport trace data from other Arm CoreSight components in the system using RISC-V Trace sub-system.
 One of possible ways of doing so would be to create a custom trace component, configure it to encapsulate it as custom N-Trace trace messages and connect it as input to one of trace funnels.
 
+<<<
 ==== Example Component Connection Diagrams 
 
 ////
@@ -275,7 +276,7 @@ Other potential unicode characters might be found in the following links:
 
 [[fig:trace-topo-single]]
 .Simplest trace: Single Hart, Trace Encoder and Trace Sink/Bridge
-["ditaa",shadows=false, separation=false, fontsize: 14]
+["ditaa",shadows=false, separation=false, fontsize: 12]
 ....
 +----------------+
 | Single Hart    |
@@ -290,7 +291,7 @@ Other potential unicode characters might be found in the following links:
 
 [[fig:trace-topo-multi]]
 .Multi-hart trace: Three harts, three Encoders, single Funnel and single Sink/Bridge
-["ditaa",shadows=false, separation=false, fontsize: 14]
+["ditaa",shadows=false, separation=false, fontsize: 12]
 ....
 +-----------+   +---------+
 | Hart with |   |  Trace  |
@@ -313,7 +314,7 @@ Other potential unicode characters might be found in the following links:
 
 [[fig:trace-topo-clusters]]
 .Multi-cluster trace: two three-hart clusters with top-level Funnel and Sink/Bridge  
-["ditaa",shadows=false, separation=false, fontsize: 14]
+["ditaa",shadows=false, separation=false, fontsize: 12]
 ....
 +-------------------------+
 | 3 Harts with 3 Encoders |
@@ -334,7 +335,7 @@ Other potential unicode characters might be found in the following links:
 
 [[fig:trace-topo-mixed]]
 .Local RAM Sink: Three-hart cluster plus extra hart with own RAM Sink (in SRAM mode)
-["ditaa",shadows=false, separation=false, fontsize: 14]
+["ditaa",shadows=false, separation=false, fontsize: 12]
 ....
 +-------------------------+
 | 3 Harts with 3 Encoders |
@@ -357,6 +358,7 @@ Other potential unicode characters might be found in the following links:
 
 NOTE: Trace data from *Trace Encoder #4* may be combined with trace from other 3 Trace Encoders. But it may be also sent to dedicated *Trace RAM Sink* - in such a case corresponding input to *Trace Funnel (top)* should be disabled.
 
+<<<
 === Accessing Trace Control Registers
 
 For the access method to the trace control registers, it makes a difference whether these registers shall be accessed by an external debug/trace tool, or by an internal debugger running on the chip.
@@ -681,6 +683,7 @@ Determine which filters defined in <<Trace Encoder Filter Registers, Trace Encod
 |31:16 |--|Reserved|--|0
 |===
 
+<<<
 === Timestamp Unit
 
 Timestamp Unit is an optional sub-component present in either Trace Encoder or Trace Funnel. An implementation may choose from several modes of timestamps: 
@@ -749,6 +752,7 @@ Prescale timestamp input clock by 2^(2*trTsPrescale). It will be divided by 1, 4
 |31:0 |trTsCounterHigh |Upper bits of timestamp counter, zero-extended. |RO|0
 |===
 
+<<<
 === Trace Encoder Triggers
 
 ==== Debug Trigger Module
@@ -830,6 +834,7 @@ It is implementation-dependent what happens when triggers (from debug module or
 
 It is recommended that tracing starts from the oldest instruction retired in the cycle that Trace-on is asserted, and stops following the newest instruction retired in the cycle that Trace-off is asserted.
 
+<<<
 === Trace Encoder Filter Registers
 
 All registers with offsets 0x400 .. 0x7FC are designated for additional trace encoder filter options (context, addresses, modes, etc.).
@@ -1118,6 +1123,7 @@ Details should be defined in definition of each trace protocol.
 |31:15 |--|Reserved|--|0
 |===
 
+<<<
 .*Register: trRamImpl: Trace RAM Sink Implementation Register (trBaseRamSink+0x004)*
 [cols="6%,24%,~,7%,7%",options="header"]
 |===
@@ -1327,6 +1333,7 @@ After the PIB reset value of this field should be set to safe (not too fast cloc
 |WARL|<<Undef,Undef>> 
 |===
 
+<<<
 .*Register: trPibImpl: Trace PIB Implementation Register (trBasePib+0x004)*
 [cols="6%,24%,~,7%,7%",options="header"]
 |===
@@ -1366,6 +1373,7 @@ Since the PIB supports many different modes, it is necessary to follow a particu
 * Activate the receiving device, such as a trace probe. Allow time for PLL to sync up, if using a PLL with a parallel PIB mode.
 * Set `trPibEnable`. This enables the PIB to generate output either immediately (calibration mode) or when the Trace Encoder or Trace Funnel begins sending trace messages/packets.
 
+<<<
 === Order of bits and bytes
 
 * Trace messages/packets are considered as sequences of bytes and are always transmitted with least significant bits/bytes first.
@@ -1382,6 +1390,7 @@ This protocol is oriented to send full, variable length trace messages/packets r
 
 When a message start is detected, this sample and possibly the next few (depending on the width of TRC_DATA) are collected until a complete byte has been received. Bytes are transmitted least significant bit first, with TRC_DATA[0] representing the least significant bit in each beat of data. The receiver continues collecting bytes until a complete message has been received. The criteria for this depends on the trace format. After the last byte of a message, the data signals may then go to their idle state or a new message may begin in the next trace clock edge.
 
+<<<
 ==== PIB Clock Center
 
 The trace clock, TRC_CLK, normally has edges coincident with the TRC_DATA edges. Typically, a trace probe will delay trace data or use a PLL to recover a sampling clock that is twice the frequency of TRC_CLK and shifted 90 degrees so that its rising edges occur near the center of each bit period. If the PIB implementation supports it, the debugger can set `trPibClkCenter` to change the timing of TRC_CLK so that there is a TRC_CLK edge at the center of each bit period on TRC_DATA. Note that this option cuts the data rate in half relative to normal parallel mode and still requires the probe to sample TRC_DATA on both edges of TRC_CLK.
@@ -1394,24 +1403,7 @@ And an example showing 8-bit parallel mode transmitting a 4-byte packet with `tr
 
 image:./RISC-V-Trace-Control-Interface-images/pib-ref1.png[image]
 
-=== Calibration Mode
-
-In optional calibration mode, the PIB transmits a repeating pattern. Probes can use this to automatically tune input delays due to skew on different PIB signal lines and to adjust to the transmitter's data rate (`trPibDivider` and `trPibClkCenter`). Calibration patterns for each mode are listed below. 
-
-.*PIB Calibration Patterns*
-[cols="25%,30%,~",options="header",align=center,width=80%]
-|===
-|*Mode* |*Calibration Bytes* |*Wire Sequence*
-|UART, Manchester |AA 55 00 FF |alternating 1/0, then all 0, then all 1
-| 1-bit parallel  |AA 55 00 FF |alternating 1/0, then all 0, then all 1
-| 2-bit parallel  |66 66 CC 33 |2, 1, 2, 1, 2, 1, 2, 1, 0, 3, 0, 3, 3, 0, 3, 0
-| 4-bit parallel  |5A 5A F0 0F |A, 5, A, 5, 0, F, F, 0
-| 8-bit parallel  |AA 55 00 FF |AA, 55, 00, FF
-| 16-bit parallel |AA AA 55 55 00 00 FF FF|AAAA, 5555, 0000, FFFF
-|===
-
-NOTE: Calibration mode may be used even by probes which do not support calibration of trace just to assure trace routing on PCB is correct and PIB is correctly enabled. It may be also possible to use calibration mode to check trace signal routing from SoC using scope or logic analyzer.
-
+<<<
 === SWT Manchester Protocol
 
 In this mode, the PIB outputs complete trace messages encapsulated between a start bit and a stop bit. Each bit period is divided into 2 phases and the sequential values of the TRC_DATA[0] pin during those 2 phases denote the bit value. Bits of the message are transmitted LSB first. The idle state of TRC_DATA[0] is low in this mode.
@@ -1434,6 +1426,24 @@ In UART protocol, the PIB outputs bytes of a trace message encapsulated in a 10-
 
 image:./RISC-V-Trace-Control-Interface-images/swt-uart.jpg[image]
 
+=== Calibration Mode
+
+In optional calibration mode, the PIB transmits a repeating pattern. Probes can use this to automatically tune input delays due to skew on different PIB signal lines and to adjust to the transmitter's data rate (`trPibDivider` and `trPibClkCenter`). Calibration patterns for each mode are listed below. 
+
+.*PIB Calibration Patterns*
+[cols="25%,30%,~",options="header",align=center,width=80%]
+|===
+|*Mode* |*Calibration Bytes* |*Wire Sequence*
+|UART, Manchester |AA 55 00 FF |alternating 1/0, then all 0, then all 1
+| 1-bit parallel  |AA 55 00 FF |alternating 1/0, then all 0, then all 1
+| 2-bit parallel  |66 66 CC 33 |2, 1, 2, 1, 2, 1, 2, 1, 0, 3, 0, 3, 3, 0, 3, 0
+| 4-bit parallel  |5A 5A F0 0F |A, 5, A, 5, 0, F, F, 0
+| 8-bit parallel  |AA 55 00 FF |AA, 55, 00, FF
+| 16-bit parallel |AA AA 55 55 00 00 FF FF|AAAA, 5555, 0000, FFFF
+|===
+
+NOTE: Calibration mode may be used even by probes which do not support calibration of trace just to assure trace routing on PCB is correct and PIB is correctly enabled. It may be also possible to use calibration mode to check trace signal routing from SoC using scope or logic analyzer.
+
 == Trace ATB Bridge
 
 Some SoCs may have an Advanced Trace Bus (ATB) infrastructure to manage trace produced by other components. In such systems, it may be desired to route entire RISC-V trace stream to the ATB through an ATB Bridge. This module manages the interface to ATB, generating ATB trace records that encapsulate RISC-V trace produced by the Trace Encoder[s] and/or Trace Funnel[s]. There is a control register that includes trace on/off control and a field allowing software to set the ID to be used on the ATB bus. This ID allows software to extract entire RISC-V trace from the combined trace. This interface is compatible with AMBA 4 ATB v1.1.
@@ -1574,7 +1584,7 @@ Reset and Discovery should be performed as follows:
 ** This should be done by writing a value 0x0 to `tr??Control` register.
 * Read-back and wait until `tr??Active` = 0 is read, which means that a component reached a reset state.
 * Release a component from reset by setting `tr??Active` = 1. 
-** This should be done by writing a value 0x1 to `tr??Control`` register. This write will reset most of other enable/mode bits in this register and all WARL and read-only fields will be set to defaults.
+** This should be done by writing a value 0x1 to `tr??Control` register. This write will reset most of other enable/mode bits in this register and all WARL and read-only fields will be set to defaults.
 * Read-back and wait until `tr??Active` = 1 is read, which means that a component was released from reset.
 ** In this moment `tr??Enable` is set to 0 and the component is not yet enabled.
 ** Component clock should be enabled to allow programming of other registers.