Updates from AR review

qos.bib

@@ -7,6 +7,10 @@ @electronic{IOMMU
   title = {RISC-V IOMMU Architecture Specification},
   url = {https://github.com/riscv-non-isa/riscv-iommu}
 }
+@electronic{SSQOSID,
+  title = {RISC-V Quality-of-Service (QoS) Identifiers},
+  url = {https://github.com/riscv/riscv-ssqosid}
+}
 @INPROCEEDINGS{SSAMPLE,
   author={Thornock, N.C. and Flanagan, J.K.},
   booktitle={2000 Winter Simulation Conference Proceedings (Cat. No.00CH37165)},

qos_bandwidth.adoc

@@ -21,12 +21,12 @@ register interface.
                                     allocation>>                | Yes
 |===
 
-The reset value is 0 for the following registers fields.
+The reset value is 0 for the following register fields.
 
 * `bc_mon_ctl.BUSY` field
 * `bc_alloc_ctl.BUSY` field
 
-The reset value is `UNSPECIFIED` for all other registers and/or fields.
+The reset value is `UNSPECIFIED` for all other register fields.
 
 The bandwidth controllers at reset must allocate all available bandwidth to
 `RCID` value of 0. When the bandwidth controller supports bandwidth allocation
@@ -88,7 +88,7 @@ bandwidth controller can handle such transient inaccuracies.
 
 The `bc_mon_ctl` register is used to control monitoring of bandwidth usage by a
 `MCID`. When the controller does not support bandwidth usage monitoring, the
-`bc_mon_ctl` register is read-only and hardwired to zero.
+`bc_mon_ctl` register is read-only zero.
 
 .Bandwidth usage monitoring control (`bc_mon_ctl`)
 [wavedrom, , ]
@@ -117,24 +117,7 @@ matching the monitoring event as the requests go past the monitoring point.
 The `OP`, `AT`, `MCID`, and `EVT_ID` fields of the register are WARL fields.
 
 The `OP` field is used to instruct the controller to perform an operation
-listed in <<BC_MON_OP>>. The supported operations of the `OP` field include
-configuring an event to count in the monitoring counter and obtaining a
-snapshot of the counter value.
-
-The `EVT_ID` field is used to program the identifier of the event to count in 
-the monitoring counter selected by `MCID`. The `AT` field is used to program the
-access-type to count, and its validity is indicated by the `ATV` field. When 
-`ATV` is 0, the counter counts requests with all access-types, and the `AT` 
-value is ignored.
-
-When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value,
-the counter is reset to 0 and starts counting matching events for requests with
-the matching `MCID` and `AT` (if `ATV` is 1). However, if the `EVT_ID` is
-configured as 0, the counter retains its current value but stops counting.
-
-A controller that does not support monitoring by access-type can hardwire the
-`ATV` and the `AT` fields to 0, indicating that the counter counts requests with
-all access-types.
+listed in <<BC_MON_OP>>.
 
 [[BC_MON_OP]]
 .Usage monitoring operations (`OP`)
@@ -154,6 +137,11 @@ all access-types.
 | --           | 24-31     | Designated for custom use.
 |===
 
+The `EVT_ID` field is used to program, using the `CONFIG_EVENT` operation, the
+identifier of the event to count in the monitoring counter selected by `MCID`.
+The `AT` field is used to program the access-type to count, and its validity is
+indicated by the `ATV` field. When `ATV` is 0, the counter counts requests with
+all access-types, and the `AT` value is ignored.
 
 [[BC_EVT_ID]]
 .Bandwidth monitoring event ID (`EVT_ID`)
@@ -179,6 +167,15 @@ all access-types.
 | --           | 128-256   | Designated for custom use.
 |===
 
+When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value,
+the counter is reset to 0 and starts counting matching events for requests with
+the matching `MCID` and `AT` (if `ATV` is 1). However, if the `EVT_ID` is
+configured as 0, the counter retains its current value but stops counting.
+
+A controller that does not support monitoring by access-type can hardwire the
+`ATV` and the `AT` fields to 0, indicating that the counter counts requests with
+all access-types.
+
 When the `bc_mon_ctl` register is written, the controller may need to perform
 several actions that may not complete synchronously with the write. A write to
 the `bc_mon_ctl` sets the read-only `BUSY` bit to 1 indicating the controller
@@ -232,7 +229,7 @@ as zero.
 ....
 
 The counter is valid if the `INV` field is 0. The counter may be marked
-`INV` if, for `UNSPECIFIED` reasons, the controllerdetermine the count to be
+`INV` if, for `UNSPECIFIED` reasons, the controller determines the count to be
 not valid. Such counters may become valid in the future. Additionally, if an
 unsigned integer overflow of the counter occurs, then the `OVF` bit is set to 1.
 
@@ -256,7 +253,8 @@ Bandwidth = T_{freq} \times \frac{ B2 - B1 }{T2 - T1}
 \end{equation}
 ++++
 
-The width of the counter is `UNSPECIFIED`.
+The width of the counter is `UNSPECIFIED` but the unimplemented bits must be
+read-only zero. 
 
 [NOTE]
 ====
@@ -275,7 +273,7 @@ operation.
 The `bc_alloc_ctl` register is used to control the allocation of bandwidth to an
 `RCID` per `AT`. If a controller does not support bandwidth allocation, then the
 register is read-only zero. If the controller does not support bandwidth
-allocation per access-type, then the `AT` field is also read-only zero.
+allocation per access-type, then the `AT` field is read-only zero.
 
 .Bandwidth allocation control (`bc_alloc_ctl`)
 [wavedrom, , ]
@@ -446,8 +444,8 @@ access-type specified by `sharedAT` does not have unique bandwidth allocation,
 meaning that it has not been configured with `useShared=0`, then the behavior
 is `UNSPECIFIED`.
 
-The `useShared` and `sharedAT` fields are reserved if the bandwidth controller
-does not support bandwidth allocation per access-type.
+The `useShared` and `sharedAT` fields are read-only zero if the bandwidth
+controller does not support bandwidth allocation per access-type.
 
 [NOTE]
 ====
@@ -459,7 +457,7 @@ and the access-type 2 is configured to share bandwidth allocation with
 access-type 1. The example configuration is illustrated as follows:
 
 [width=100%]
-[%header, cols="4,^1,^1,^1,^1"]
+[%header, cols="4,^2,^2,^2,^2"]
 |===
 |                  |  `Rbwb`  |  `Mweight`  |  `useShared`  |  `sharedAT`
 | `RCID=3`, `AT=0` | `100`    |    `16`     |      `0`      |     `N/A`

qos_capacity.adoc

@@ -48,12 +48,12 @@ The size and offset in <<CC_REG>> are specified in bytes.
 The size of the `cc_block_mask` register is determined by the `NCBLKS` field
 of the `cc_capabilities` register but is always a multiple of 8 bytes.
 
-The reset value is 0 for the following registers fields.
+The reset value is 0 for the following register fields.
 
 * `cc_mon_ctl.BUSY` field
 * `cc_alloc_ctl.BUSY` field
 
-The reset value is `UNSPECIFIED` for all other registers and/or fields.
+The reset value is `UNSPECIFIED` for all other registers fields.
 
 The capacity controllers at reset must allocate all available capacity to `RCID`
 value of 0. When the capacity controller supports capacity allocation per
@@ -138,24 +138,7 @@ The `OP`, `AT`, `ATV`, `MCID`, and `EVT_ID` fields of the register are WARL
 fields.
 
 The `OP` field is used to instruct the controller to perform an operation listed
-in <<CC_MON_OP>>. The supported operations of the `OP` field include configuring
-an event to count in the monitoring counter and obtaining a snapshot of the
-counter value.
-
-The `EVT_ID` field is used to program the identifier of the event to count in
-the monitoring counter selected by `MCID`. The `AT` field is used to program the
-access-type to count, and its validity is indicated by the `ATV` field. When
-`ATV` is 0, the counter counts requests with all access-types, and the `AT`
-value is ignored.
-
-When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value, 
-the counter is reset to 0 and starts counting matching events for requests with 
-the matching `MCID` and `AT` (if `ATV` is 1). However, if the `EVT_ID` is 
-configured as 0, the counter retains its current value but stops counting.
-
-A controller that does not support monitoring by access-type can hardwire the
-`ATV` and the `AT` fields to 0, indicating that the counter counts requests with 
-all access-types.
+in <<CC_MON_OP>>.
 
 [[CC_MON_OP]]
 .Capacity usage monitoring operations (`OP`)
@@ -175,6 +158,11 @@ all access-types.
 | --           | 24-31     | Designated for custom use.
 |===
 
+The `EVT_ID` field is used to program the identifier of the event to count in
+the monitoring counter selected by `MCID`. The `AT` field (See <<AT_ENC>>) is
+used to program the access-type to count, and its validity is indicated by the
+`ATV` field. When `ATV` is 0, the counter counts requests with all access-types,
+and the `AT` value is ignored.
 
 [[CC_EVT_ID]]
 .Capacity usage monitoring event ID (`EVT_ID`)
@@ -191,6 +179,16 @@ all access-types.
 | --           | 128-256   | Designated for custom use.
 |===
 
+When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value
+using the `CONFIG_EVENT` operation, the counter is reset to 0 and starts counting
+matching events for requests with the matching `MCID` and `AT` (if `ATV` is 1).
+However, if the `EVT_ID` is programmed to 0, the counter retains its current value
+but stops counting.
+
+A controller that does not support monitoring by access-type can hardwire the
+`ATV` and the `AT` fields to 0, indicating that the counter counts requests with
+all access-types.
+
 When the `cc_mon_ctl` register is written, the controller may need to perform
 several actions that may not complete synchronously with the write. A write to
 the `cc_mon_ctl` sets the read-only `BUSY` bit to 1 indicating the controller
@@ -242,22 +240,27 @@ zero.
 ], config:{lanes: 2, hspace:1024}}
 ....
 
-The counter is valid if the `INV` field is 0. The counter may be marked
-`INV` if it underflows or the controller, for `UNSPECIFIED` reasons determine
-the count to be not valid. The counters marked `INV` may become valid in future.
+The counter is valid if the `INV` field is 0. The counter may be marked `INV` if
+the controller, for `UNSPECIFIED` reasons determine the count to be not valid.
+The counters marked `INV` may become valid in future.
+
+The counter shall not decrement below zero. If an event should occur that would
+otherwise result in a negative value, the counter will continue to hold a value
+of 0.
 
 [NOTE]
 ====
-A counter may underflow when capacity is de-allocated following a reset
-of the counter to 0. This may be due to the `MCID` being reallocated to a new
-workload while the capacity controller still holds capacity allocated by
-the workload to which the `MCID` was previously allocated. The counter value
-should typically stabilize to reflect the capacity usage of the new workload
-after the workload has executed for a short duration following the counter
-reset.
+Following a reset of the counter to zero, a capacity de-allocation may attempt
+to drive its value below zero. This scenario may occur when the `MCID` is
+reassigned to a new workload, yet the capacity controller continues to hold
+capacity initially allocated by the previous workload. In such cases, the
+counter shall not decrement below zero and shall remain at zero. After a brief
+period of execution for the new workload post-counter reset, the counter value is
+expected to stabilize to reflect the capacity usage of this new workload.
 ====
 
 [NOTE]
+[%unbreakable]
 ====
 Some implementations may not store the `MCID` of the request that caused the
 capacity to be allocated with every unit of capacity in the controller to
@@ -288,10 +291,10 @@ processes.
 === Capacity allocation control (`cc_alloc_ctl`)
 
 The `cc_alloc_ctl` register is used to configure allocation of capacity to an
-`RCID` per access-type (`AT`). The `RCID` and `AT` fields in this register are
-WARL. If a controller does not support capacity allocation then this register is
-read-only zero. If the controller does not support capacity allocation per
-access-type then the `AT` field is read-only zero.
+`RCID` per access-type (`AT`). The `OP`, `RCID` and `AT` fields in this register
+are WARL. If a controller does not support capacity allocation then this
+register is read-only zero. If the controller does not support capacity
+allocation per access-type then the `AT` field is read-only zero.
 
 .Capacity allocation control (`cc_alloc_ctl`)
 [wavedrom, , ]
@@ -307,8 +310,6 @@ access-type then the `AT` field is read-only zero.
 ], config:{lanes: 2, hspace:1024}}
 ....
 
-The `OP`, `AT`, and `RCID` are WARL fields.
-
 The `OP` field is used to instruct the capacity controller to perform an
 operation listed in <<CC_ALLOC_OP>>. Some operations necessitate the
 specification of the _capacity blocks_ to act upon. For such operations, the
@@ -338,14 +339,14 @@ initiating the operation via the `cc_alloc_ctl` register.
                              `cc_block_mask` register, and the configured limit
                              on _capacity units_ is available in the `cc_cunits`
                              register on successful completion of the operation.
-|`FLUSH_RCID`  | 3         | Deallocate the capacity used by the specified
+|`FLUSH_RCID`  | 3         | Flushes the _capacity units_ used by the specified
                              `RCID` and access-type `AT`. This operation is
                              supported if the `capabilities.FRCID` bit is 1.   +
                                                                                +
                              The `cc_block_mask` and `cc_cunits` registers
                              are not used for this operation.                  +
                                                                                +
-                             The configured _capacity_ block allocation or the
+                             The configured _capacity block_ allocation or the
                              _capacity unit_ limit is not changed by this
                              operation.
 | --           | 4-23      | Reserved for future standard use.
@@ -467,12 +468,13 @@ software must verify that `BUSY` bit  is 0 before writing any of these registers
 === Capacity block mask (`cc_block_mask`)
 
 The `cc_block_mask` is a WARL register. If the controller does not support
-capacity allocation i.e. `NCBLKS` is 0, then this register is read-only 0.
+capacity allocation, i.e., `NCBLKS` is 0, then this register is read-only 0.
 
 The register has `NCBLKS` bits each corresponding to one allocatable
 _capacity block_ in the controller. The width of this register is variable but
 always a multiple of 64 bits. The bitmap width in bits (`BMW`) is determined by
-<<eq-1>>. The division operation in this equation is an integer division.
+the equation below. The division operation in this equation is an integer
+division.
 
 [latexmath#eq-1,reftext="equation ({counter:eqs})"]
 ++++
@@ -481,21 +483,20 @@ BMW = \lfloor{\frac{NCBLKS + 63}{64}}\rfloor \times 64
 \end{equation}
 ++++
 
-Bits `NCBLKS-1:0` are read-write, and the bits `BMW-1:NCBLKS` are read-only and
-have a value of 0.
+Bits `NCBLKS-1:0` are read-write, and the bits `BMW-1:NCBLKS` are read-only zero.
 
 The process of configuring capacity allocation for an `RCID` and `AT` begins by
 programming the `cc_block_mask` register with a bit-mask that identifies the
-_capacity blocks_ to be allocated and, if supported, the `cc_cunits` register with
-a limit on the capacity units that may be occupied in those capacity blocks.
-Next, the `cc_alloc_ctl register` is written to request a `CONFIG_LIMIT`
-operation for the `RCID` and `AT`. Once a capacity allocation limit has been
-established, a request may be allocated capacity in the capacity blocks
-allocated to the `RCID` and `AT` associated with the request. It is important to
-note that at least one capacity block must be allocated using `cc_block_mask`
-when allocating capacity, or else the operation will fail with `STATUS=5`.
-Overlapping _capacity block_ masks among `RCID` and/or `AT` are allowed to be
-configured.
+_capacity blocks_ to be allocated and, if supported, by programming the
+`cc_cunits` register with a limit on the capacity units that may be occupied in
+those capacity blocks. Next, the `cc_alloc_ctl register` is written to request a
+`CONFIG_LIMIT` operation for the `RCID` and `AT`. Once a capacity allocation
+limit has been established, a request may be allocated capacity in the _capacity
+blocks_ allocated to the `RCID` and `AT` associated with the request. It is
+important to note that at least one _capacity block_ must be allocated using
+`cc_block_mask` when allocating capacity, or else the operation will fail with
+`STATUS=5`.  Overlapping _capacity block_ masks among `RCID` and/or `AT` are
+allowed to be configured.
 
 [NOTE]
 ====
@@ -516,13 +517,13 @@ provides the `READ_LIMIT` operation which can be requested by writing to the
 
 The `cc_cunits` register is a read-write WARL register. If the controller does
 not support capacity allocation (i.e., `NCBLKS` is set to 0), this register
-shall be read-only and return a value of 0. 
+shall be read-only zero.
 
 If the controller does not support configuring limits on _capacity units_ that
 may be occupied in the allocated _capacity blocks_ (i.e.,
-`cc_capabilities.CUNITS=0`) then this register shall be read-only and return a
-value of 0. In such cases the controller will allow utilization of all available
-_capacity units_ by an `RCID` within the _capacity blocks_ allocated to it.
+`cc_capabilities.CUNITS=0`) then this register shall be read-only zero. In such
+cases the controller will allow utilization of all available _capacity units_ by
+an `RCID` within the _capacity blocks_ allocated to it.
 
 If the controller supports configuring limits on _capacity units_ that may be
 occupied in the allocated _capacity blocks_ (i.e., `cc_capabilities.CUNITS=1`)

qos_header.adoc

@@ -41,7 +41,7 @@ RISC-V CMQRI Task Group
 
 // Preamble
 [WARNING]
-.This document is in the link:http://riscv.org/spec-state[Development state]
+.This document is in the link:http://riscv.org/spec-state[Stable state]
 ====
 Assume everything can change. This draft specification will change before
 being accepted as standard, so implementations made to this draft

qos_hw_guidelines.adoc

@@ -1,6 +1,7 @@
 [[QOS_HW_GUIDE]]
 == Hardware Guidelines
 
+[[QOS_SIZING]]
 === Sizing QoS Identifiers
 
 In a typical implementation the number of `RCID` bits implemented (e.g., to
@@ -20,9 +21,12 @@ large pool of `MCID` speeds up this analysis.
 
 [NOTE]
 ====
-To support maximal flexibility in allocation of QoS IDs to workloads it is
-recommended for all resource controllers in the system to support an identical
-number of `RCID` and `MCID`.
+To achieve maximum flexibility in the allocation of QoS IDs to workloads, it is
+recommended that all resource controllers in the system support an identical
+number of `RCID` and `MCID`. Requests typically need to be processed by multiple
+controllers, such as caches, fabrics, and memory controllers. In such cases, if
+not all controllers accessed by a request support an identical number of IDs,
+software will be constrained, using only the IDs supported by all controllers.
 ====