Merge pull request #61 from riscv-non-isa/beeman/smtdeleg-sstcfg

Avoid 2-level redirection description in Smtdeleg/Sstcfg spec

riscv-smtdeleg-sstcfg.adoc

@@ -14,44 +14,48 @@ The Smtdeleg extension provides a means for Sdtrig triggers to be accessed from
 
 === Supervisor Trigger Select (`stselect`)
 
-`stselect` provides access to `tselect` from S-mode and VS-mode.
+`stselect` provides read/write access to `tselect` from S-mode and VS-mode.
 
 == Supervisor and Virtual Supervisor Trigger Access
 
-While `siselect` holds XXX, the `sireg*` registers provide access to the `tdata*` and `tinfo` registers associated with the trigger selected in `tselect`.  The register mapping is shown below.
+While `siselect` holds XXX, the `sireg*` registers provide supervisor read/write access to register state associated with the trigger selected in `tselect`, the same state accessed by M-mode CSRs `tdata*` and `tinfo`. The register mapping is shown below.
 
-.Indirect Trigger Register Mappings
-[width="50%",options="header"]
+.Indirect Trigger Register Mappings When `siselect` = XXX
+[width="70%",options="header"]
 |===
-| Indirect CSR | Sdtrig CSR 
-| `sireg` | `tdata1` 
-| `sireg2` | `tdata2` 
-| `sireg3` | `tdata3` 
-| `sireg4` | `tinfo` 
+| Indirect CSR | State Accessed
+| `sireg` | Same as `tdata1` 
+| `sireg2` | Same as `tdata2` 
+| `sireg3` | Same as `tdata3` 
+| `sireg4` | Same as `tinfo` 
 |===
 
 [WARN]
 ====
-_There was much discussion of the best way to access counters in S-mode.  This method requires 1 new CSR (`stselect`), and creates a scenario where there are 2 levels of indirection (siselect routes sireg* to t*, and tselect routes t* to the state associated with the selected trigger)._
+_There was much discussion of the best way to access counters in S-mode.  This method requires 1 new CSR (`stselect`), along with 1 siselect index._
 
-_Also proposed was to simply allocate a range of `siselect` values that serve to select the trigger, bypassing `tselect` when accessing trigger state through `sireg*`.  This avoids the 2nd level of indirection, but artificially limits the number of triggers accessible in S-mode.  `tselect` supports up to 2^MXLEN^ triggers, while `siselect` would likely allocate only enough values to cover practical implementations (256?)._
+_Also proposed was to simply allocate a range of `siselect` values that serve to select the trigger, bypassing `tselect` when accessing trigger state through `sireg*`.  This adds no new CSRs, but artificially limits the number of triggers accessible in S-mode.  `tselect` supports up to 2^MXLEN^ triggers, while `siselect` would likely allocate only enough values to cover practical implementations (256?)._
+
+_Other approaches considered:_
 
-_Other approaches considered:
 * _Define new `stdata[123]` and `stinfo` registers, which provide S-mode access to `tdata[123]` and `tinfo`.  Avoids dependence on Sscsrind altogether, but costs 4 more CSR addresses._
+
 * _Access `tselect` via `sireg5` instead of through a new `stselect` CSR (access to `tdata*` and `tinfo` is the same as spec'd above).  While saving a CSR, this approach would require `sireg5` to continue to access `tselect` while the other `sireg*` registers shift the state they acccess based on the `tselect` value.  This approach seems more awkward for implementation._
 ====
 
-Similarly, when `vsiselect` holds XXX, the `vsireg*` registers provide access to `tdata*` and `tinfo` in the same manner as described above for `sireg*`.
+Similarly, when `vsiselect` holds XXX, the `vsireg*` registers provide access to trigger register state in the same manner as described above for `sireg*`.
 
 === Trigger State Access Modifications
 
-`sireg*` and `vsireg*` provide access to a subset of the fields in the native trigger CSRs, and in some cases fields are relocated.  The field modifications that apply when trigger registers are accessed via `sireg*` or `vsireg*` are documented below.
+`sireg*` and `vsireg*` provide access to a subset of the fields in the native trigger registers, and in some cases fields are relocated.  The field modifications that apply when trigger registers are accessed via `sireg*` or `vsireg*` are documented below.
 
 .Delegated Trigger CSR Field Modifications
-[options="header", cols="20%,30%,50%"]
+[options="header", cols="30%,30%,40%"]
 |===
 | Sdtrig Register | `sireg*` Field Modifications | `vsireg*` Field Modifications
-| `tdata1` | M is read-only 0 
+| `mcontrol`, `mcontrol6`, `icount`, `etrigger`, `itrigger` 
+
+(accessed by `tdata1`) | M is read-only 0 
 
 VS and VU are read-only 0
 
@@ -62,14 +66,14 @@ S accesses `tdata1`.VS
 U accesses `tdata1`.VU
 
 VS and VU are read-only 0
-| `tdata2` | none | none
-| `tdata3` | none | MHVALUE and MHSELECT are read-only 0
-| `tinfo` | none | none
+| `textra32`, `textra64` 
+
+(accessed by `tdata3`) | none | MHVALUE and MHSELECT are read-only 0
 |===
 
 [NOTE]
 ====
-_For a given `tselect` value, the bit positions for the `tdata1` fields listed above vary based on the value of `tdata1`.TYPE.  See details in the RISC-V Debug Specification, Chapter 5.7._
+_The bit positions for the M, S, U, VS, and VU fields referenced above vary based on the trigger type, specified by `tdata1`.TYPE.  See details in the RISC-V Debug Specification, Chapter 5.7._
 ====
 
 [NOTE]