Add more example diagrams for different models

Author: gagachang

chapter2.adoc

@@ -75,7 +75,8 @@ Let's consider a non-priority entry matching all bytes of a transaction. It is l
 Finally, if no such above entry exists, the transaction is illegal with error code = "not hit any rule" (0x05).
 
 
-.IOPMP Block Diagram.
+[caption="Figure {counter:image}: ", reftext="Figure {image}"]
+[title="an example block diagram of an IOPMP. It illustrates the checking flow of an IOPMP. This IOPMP takes three inputs: RRID, the transaction type (read/write), and the request address. It first looks up the SRCMD table according to the RRID carried by the incoming transaction to retrieve associated MD indexes and the corresponding permissions related to these MDs. By the MD indexes, the IOPMP looks up the MDCFG table to get the belonging entry indexes. The final step checks the access right according to the above entry indexes and corresponding permissions. An interrupt, an error response, and/or a record is generated once the transaction fails the permission check in the step.", id=iopmp-block-diagram]
 image::iopmp_unit_block_diagram.png[]
 
 [#SECTION_2_7]

chapter3.adoc

@@ -59,6 +59,18 @@ This format is based on Format 1, except *HWCFG0.md_entry_num* is programmable.
 === IOPMP Models
 For the sake of convenience of discussion, some highly used combinations of *HWCFG0* have an alias name, which are *srcmd_fmt*=0 and *mdcfg_fmt*=0 as the full model, *srcmd_fmt*=0 and *mdcfg_fmt*=1 as the rapid-_k_ model, where _k_ = (*md_entry_num* + 1), *srcmd_fmt*=0 and *mdcfg_fmt*=2 as the dynamic-_k_ model, where _k_ = (*md_entry_num* + 1), *srcmd_fmt*=1 and *mdcfg_fmt*=0 as the isolation model, and *srcmd_fmt*=1 and *mdcfg_fmt*=1 as the compact-_k_ model, where _k_ = (*md_entry_num* + 1).
 
+[caption="Figure {counter:image}: ", reftext="Figure {image}"]
+[title="an example block diagram of the rapid-4 model. The flow is the same as in <<iopmp-block-diagram>>, except the MDCFG table is simplified to a constant mapping illustrated in the dashed box. In this example, every MD has exactly four entries."]
+image::iopmp_unit_block_diagram_rapid_4.png[]
+
+[caption="Figure {counter:image}: ", reftext="Figure {image}"]
+[title="an example block diagram of the compact-4 model."]
+image::iopmp_unit_block_diagram_compact_4.png[]
+
+[caption="Figure {counter:image}: ", reftext="Figure {image}"]
+[title="an example block diagram of the model implements SRCMD table format 2 and MDCFG table format 1 with HWCFG0.md_entry_num is 0. In this example, every MD has exactly single entry, i.e., the entry index is equal to the MD index."]
+image::iopmp_unit_block_diagram_srcmd_fmt2.png[]
+
 [#SECTION_3_5]
 === Configuration Protection
 The term 'lock' refers to a hardware feature that renders one or more fields or registers nonprogrammable until the IOPMP is reset. This feature serves to maintain the integrity of essential configurations in the event of a compromise of secure software. In cases where a lock bit is programmable, it is expected to be reset to '0' and sticky to '1' upon receiving a write of '1'.

images/iopmp_unit_block_diagram.png

@@ -10,5 +10,3 @@ Another hardware component in a bus matrix, the Input-Output Memory Management U
 
 .Examplary Integration of IOPMP(s) in System.
 image::iopmp_system_position.png[]
-
-