From 149a6c6707782e8765ce661fc17bf39035b97b2f Mon Sep 17 00:00:00 2001 From: beeman Date: Mon, 9 Sep 2024 09:07:49 -0700 Subject: [PATCH 1/3] rephrase (v)sireg* to point to state accessed by tdata*, rather than to tdata* itself --- riscv-smtdeleg-sstcfg.adoc | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/riscv-smtdeleg-sstcfg.adoc b/riscv-smtdeleg-sstcfg.adoc index f94807c..a8e9ba5 100644 --- a/riscv-smtdeleg-sstcfg.adoc +++ b/riscv-smtdeleg-sstcfg.adoc @@ -14,44 +14,46 @@ 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 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 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: * _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 +64,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] From 34a49de83d2f78d0b2891c1fe112dbbc3a4a2983 Mon Sep 17 00:00:00 2001 From: beeman Date: Mon, 9 Sep 2024 09:11:28 -0700 Subject: [PATCH 2/3] fix table 1 header --- riscv-smtdeleg-sstcfg.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/riscv-smtdeleg-sstcfg.adoc b/riscv-smtdeleg-sstcfg.adoc index a8e9ba5..7fa17be 100644 --- a/riscv-smtdeleg-sstcfg.adoc +++ b/riscv-smtdeleg-sstcfg.adoc @@ -18,10 +18,10 @@ The Smtdeleg extension provides a means for Sdtrig triggers to be accessed from == Supervisor and Virtual Supervisor Trigger Access -While `siselect` holds XXX, the `sireg*` registers provide supervisor 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. +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 | State Accessed | `sireg` | Same as `tdata1` From 9806523876daf0b0152d9e2992edb8ed5fb03bfe Mon Sep 17 00:00:00 2001 From: beeman Date: Mon, 9 Sep 2024 09:13:21 -0700 Subject: [PATCH 3/3] fix warn block bullet list format --- riscv-smtdeleg-sstcfg.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/riscv-smtdeleg-sstcfg.adoc b/riscv-smtdeleg-sstcfg.adoc index 7fa17be..fd631d7 100644 --- a/riscv-smtdeleg-sstcfg.adoc +++ b/riscv-smtdeleg-sstcfg.adoc @@ -36,8 +36,10 @@ _There was much discussion of the best way to access counters in S-mode. This m _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._ ====