Accidentally removed chapter 3.3 other models in v0.9.0, add back.

Author: channingt

chapter3.adoc

@@ -50,3 +50,32 @@ If a MD is locked, while its preceding MD is not locked, it could lead to the po
 
 ==== Entry Protection
 IOPMP entry protection is also related to the other IOPMP entries belonging to the same memory domain. For a MD, locked entries should be placed in the higher priority. Otherwise, when the secure monitor is compromised, one unlocked entry in higher priority can overwrite all the other locked or non-locked entries in lower priority.  A register *ENTRYLCK* is define to indicate the number of nonprogrammable entries. *ENTRYLCK* register has two fields: *ENTRYLCK.l* and *ENTRYLCK.f*. Any IOPMP entry with index _i_ ≤ *ENTRYLCK.f* is not programmable. *ENTRYLCK.f* is initialized to 0 and can be increased only when written. Besides, *ENTRYLCK.l* is the lock to *ENTRYLCK.f* and itself. If *ENTRYLCK* is hardwired, *ENTRYLCK.l* should be wired to 1.
+
+=== Other IOPMP Models
+==== Tables Reduction
+Full model comprises two tables and an array, offering substantial flexibility for configuring an IOPMP. However, this comes at the cost of increased latency and area usage. The chapter presents the other models designed to simplify these tables, thereby catering to diverse design requirements. 
+
+The IOPMP array functions as the primary repository for IOPMP entries with it's size adjustable. Sharing memory domains among RRIDs can result in shared entries between them. This sharing approach has the potential to decrease the overall footprint of the IOPMP array. Nevertheless, if a design doesn't encompass many shared regions, simplifying the SRCMD table, as demonstrated in the isolation and compact-_k_ models, could be a viable consideration.
+
+As to MDCFG table, its primary function is to partition the entries within the IOPMP. Besides programming each *MDCFG(_m_).t* for every MD _m_, an alternative approach involves evenly distributing entries across each MD. This distribution method is implemented in the Rapid-_k_, dynamic-_k_, and compact-_k_ models.
+
+==== Rapid-k Model
+The Rapid-_k_ model is based on Full model and aims to reduce latency by eliminating the need to lookup the MDCFG table. In this model, each memory domain has exactly _k_ entries where _k_ is implementation-dependent and non-programmable. Only MDCFG(0) is utilized, rendering the implementation of MDCFG(j) unnecessary for j greater than 0.  *MDCFG(0).t* store the value _k_, while *MDCFGLCK.f* is ignored and *MDCFGLCK.l* should be 1.
+
+==== Dynamic-k Model
+Dynamic-_k_ model is based on rapid-_k_ model, except the _k_ value is programmable. That is, *MDCFG(0).t* is WARL and accepts a limited set of values. *MDCFGLCK.f* is ignored, and *MDCFGLCK.l* indicates if *MDCFG(0).t* is still programmable or locked.
+
+===== Isolation Model
+The bitmap implementation of SRCMD table facilitates the sharing of regions between RRIDs. The Isolation model is specifically tailored for scenarios where there are minimal to no shared regions. In this model, each RRID is exactly associated with a single MD, eliminating the necessity for SRCMD table lookups. Each RRID _i_ is directly associated with MD _i_, resulting in advantages in terms of area, latency, and system complexity. However, duplication of entries occurs when shared regions are required, representing a potential drawback. In this model, SRCMD table and *MDLCK(H)* registers are omitted.
+
+The number of RRIDs to support is bounded by the maximal number of MDs, 63.
+
+There is no constraint imposed on MDCFG table and *MDCFGLCK* register.
+
+==== Compact-k Model
+The Compact-_k_ model, being the most compact variant, is based on the Isolation model. It mandates that each MD has exactly _k_ entries with _k_ being non-programmable. Only *MDCFG(0)* is implemented. *MDCFG(0).t* holds the value _k_, *MDCFGLCK.f* is ignored and *MDCFGLCK.l* is 1.
+
+==== Model Detections
+
+To distinguish the above models, the user can read register *HWCFG0.model* to determine the current implemented IOPMP model.
+

chapter5.adoc

@@ -255,7 +255,6 @@ Implemented only for *HWCFG0.chk_x*=1.
 |===
 
 An implementation can optionally support the full and partial functions defined in the fields *ree*, *rwe*, and *rxe*.
-//Paul 4/4:  As discussed on 4/3, we should pick a new name to replace 'ip'.
 *ERR_REQINFO* captures more detailed error infomation.
 [cols="<2,<1,<1,<1,<6",stripes=even]
 |===
@@ -308,7 +307,6 @@ h|Field                         |Bits       |R/W    |Default    |Description
 h|Field                         |Bits       |R/W    |Default    |Description
 |{set:cellbgcolor:#FFFFFF}addrh |31:0       |R      |DC         |Indicate the errored address[65:34]
 |===
-// Paul 4/4: I am thinking of whether 'eid' should be a mandatory field. Could we make it optional?
 *ERR_REQID* indicates the errored RRID and entry index.
 [cols="<2,<1,<1,<1,<6",stripes=even]
 |===