draft-6

Makefile

@@ -1,47 +1,60 @@
-DOCKER_RUN := docker run --rm -v ${PWD}:/build -w /build \
-riscvintl/riscv-docs-base-container-image:latest
-
-HEADER_SOURCE := header.adoc
-PDF_RESULT := riscv_iopmp_specification.pdf
-
-ASCIIDOCTOR_PDF := asciidoctor-pdf
-OPTIONS := --trace \
-           -a compress \
-           -a mathematical-format=svg \
-           -a pdf-fontsdir=docs-resources/fonts \
-           -a pdf-theme=docs-resources/themes/riscv-pdf.yml \
-           --failure-level=ERROR
-REQUIRES := --require=asciidoctor-bibtex \
-            --require=asciidoctor-diagram \
-            --require=asciidoctor-mathematical \
-            --out-file=$(PDF_RESULT) \
-$(HEADER_SOURCE)
-
-.PHONY: all build clean build-container build-no-container
-
-all: build
-
-build: 
-	@echo "Checking if Docker is available..."
-	@if command -v docker >/dev/null 2>&1 ; then \
-		echo "Docker is available, building inside Docker container..."; \
-		$(MAKE) build-container; \
-	else \
-		echo "Docker is not available, building without Docker..."; \
-		$(MAKE) build-no-container; \
-	fi
-
-build-container:
-	@echo "Starting build inside Docker container..."
-	$(DOCKER_RUN) /bin/sh -c "$(ASCIIDOCTOR_PDF) $(OPTIONS) $(REQUIRES) --out-file=$(PDF_RESULT) $(HEADER_SOURCE)"
-	@echo "Build completed successfully inside Docker container."
-
-build-no-container:
-	@echo "Starting build..."
-	$(ASCIIDOCTOR_PDF) $(OPTIONS) $(REQUIRES) --out-file=$(PDF_RESULT) $(HEADER_SOURCE)
-	@echo "Build completed successfully."
+# Makefile for RISC-V ISA Manuals
+#
+# This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+# International License. To view a copy of this license, visit
+# http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to
+# Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
+#
+# SPDX-License-Identifier: CC-BY-SA-4.0
+#
+# Description:
+# 
+# This Makefile is designed to automate the process of building and packaging 
+# the documentation for RISC-V ISA Manuals. It supports multiple build targets 
+# for generating documentation in various formats (PDF, HTML).
+
+# Build Targets
+TARGETS := iopmp-spec
+
+# Declare phony targets
+.PHONY: all $(TARGETS) clean
+
+# Default target builds all
+all: $(TARGETS)
+
+# Build with preinstalled docker container; first install it with:
+#   docker pull riscvintl/riscv-docs-base-container-image:latest
+docker:
+	cd .. && docker run -it -v .:/build riscvintl/riscv-docs-base-container-image:latest /bin/sh -c 'cd ./build; make $(MAKEFLAGS)'
+
+# Asciidoctor options
+ASCIIDOCTOR_OPTS := -a compress \
+                    --attribute=mathematical-format=svg \
+                    --failure-level=ERROR \
+                    --require=asciidoctor-bibtex \
+                    --require=asciidoctor-diagram \
+                    --require=asciidoctor-mathematical \
+                    --trace
+
+# Source directory
+SRCDIR := ./
+
+PDF_RESULT := riscv-iopmp-specification.pdf
+
+# Temporary files to clean up for LaTeX build
+JUNK := *.pdf *.aux *.log *.bbl *.blg *.toc *.out *.fdb_latexmk *.fls *.synctex.gz
+
+# IOPMP Spec Build
+iopmp-spec: riscv-iopmp-specification.pdf
+
+riscv-iopmp-specification.pdf: $(SRCDIR)/header.adoc $(SRCDIR)/*.adoc
+	@echo "Building Privileged ISA"
+	rm -f $@.tmp
+	asciidoctor-pdf $(ASCIIDOCTOR_OPTS) --out-file=$@.tmp $<
+	mv $@.tmp $@
 
 clean:
 	@echo "Cleaning up generated files..."
 	rm -f $(PDF_RESULT)
-	@echo "Cleanup completed."
+	@echo "Cleanup completed."
+

appendix_a1.adoc

@@ -1,4 +1,4 @@
 [Appendix_A1]
-== A1: Multi-Faults Extension
-
-TBD
+== A1: Multi-Faults Record Extension
+A first violation is one that is detected and logged in the error report. However, since the error report can only accommodate one first violation, any additional violations that are detected but not logged in the error report are termed as subsequent violations. The issue at hand is that these subsequent violations become completely invisible. The Multi-Faults Record Extension is used to record which RRIDs make subsequent violations. The extension maintains a bit, referred to as SV[_s_], for each RRID _s_. When one or more subsequent violations are issued from an RRID, the corresponding bit is set.
+To retrieve these SVs, a 32-bit register *ERR_MFR* is used. Every 16 contiguous SVs are grouped together into a record window, which is indexed by a 12-bit field, *svi*. When *ERR_MFR* is read, the *svi* sequentially scans all windows from its original position until a violation is found. Once *svi* is overflowed, it rounds to zero. If found, the status bit *svs* is set, and *svi* stops in the window containing the first found set SV. The 16-bit field *svw* reflects the record window indexed by *svi*, where *svw[_j_]*=SV[*svi* * 32 + _j_]. After the register is read out, all bits in the record window are cleared. If not found, *svs* and *svw* return zeros and *svi* keeps the same. Moreover, the bit *svc* in the *ERR_REQINFO* indicates if any subsequent violation is in the log.

appendix_a2.adoc

@@ -4,7 +4,7 @@ In this specification, the support is capped at 63 memory domains. However, this
 
 
 === A2.1 Parallel IOPMP
-Multiple IOPMPs can be placed in parallel. A transaction should be directed to one of these IOPMPs for its check. The chosen IOPMP then determines its legality. There are two potential methods for routing the transaction: by address or by SID. Address-based routing divides the address space into multiple disjoint sets, and a transaction is directed to the IOPMP based on its starting address. Similarly, SID-based routing divides all possible SIDs, and a transaction is directed to the IOPMP based on its SID.
+Multiple IOPMPs can be placed in parallel. A transaction should be directed to one of these IOPMPs for its check. The chosen IOPMP then determines its legality. There are two potential methods for routing the transaction: by address or by RRID. Address-based routing divides the address space into multiple disjoint sets, and a transaction is directed to the IOPMP based on its starting address. Similarly, RRID-based routing divides all possible SIDs, and a transaction is directed to the IOPMP based on its RRID.
 
 [NOTE]
 ====
@@ -13,11 +13,11 @@ Placing IOPMPs in parallel can seamlessly enhance the support for an increased n
 ====
 
 === A2.2 Cascading IOPMP
-Cascading multiple IOPMPs allows a transaction to traverse through more than one IOPMP. Each time a transaction goes through an IOPMP, it is tagged a new SID until it reaches the final IOPMP. This new SID represents that the transaction has been checked by a specific IOPMP. Subsequent IOPMPs could deem the transaction trustworthy and forward it to their initiator port without further checks, or check it in a higher level view, e.g., a subsystem view. An IOPMP with the above feature of tagging a new SID is referred to as an IOPMP gateway. Its HWCFG0.sid_transl_en should be set to 1, and HWCFG2.sid_transl is used to store the SID.  HWCFG0.sid_transl_prog indicates whether HWCFG2.sid_transl is programmable or not. To lock sid_transl, write 1 to sid_transl_prog, which clears sid_transl_prog and is sticky to 0.
+Cascading multiple IOPMPs allows a transaction to traverse through more than one IOPMP. Each time a transaction goes through an IOPMP, it is tagged a new RRID until it reaches the final IOPMP. This new RRID represents that the transaction has been checked by a specific IOPMP. Subsequent IOPMPs could deem the transaction trustworthy and forward it to their initiator port without further checks, or check it in a higher level view, e.g., a subsystem view. An IOPMP with the above feature of tagging a new RRID is referred to as an IOPMP gateway. Its *HWCFG0.rrid_transl_en* should be set to 1, and *HWCFG2.rrid_transl* is used to store the RRID.  *HWCFG0.rrid_transl_prog* indicates whether *HWCFG2.rrid_transl* is programmable or not. To lock *rrid_transl*, write 1 to *rrid_transl_prog*, which clears *rrid_transl_prog* and is sticky to 0.
 
 [NOTE]
 ====
-The integration of several independently developed smaller Systems on a Chip (SoCs) to construct a larger SoC reduces the chip count in a device. This approach also decreases costs by enabling the use of larger and shared memory devices. In such a system, each subsystem upholds its governance through its own secure software, SID assignment, and security configuration. The cascading approach facilitates this: the secure software manages the IOPMP in the boundary of the subsystem. The boundary IOPMP assigns a new SID to each outgoing transaction, representing that it has been checked by the IOPMP. 
-The outer IOPMPs are tasked with controlling the transactions from a subsystem perspective by the new subsystem-level SID. That is, the IOPMP only considers the legality of the transactions initiated from a specific subsystem instead of individual transaction initiators. The boundary IOPMP hides some details of the subsystem good for protecting intellect properties. The development flow becomes more abstract, reusable, and modularized.
+The integration of several independently developed smaller Systems on a Chip (SoCs) to construct a larger SoC reduces the chip count in a device. This approach also decreases costs by enabling the use of larger and shared memory devices. In such a system, each subsystem upholds its governance through its own secure software, RRID assignment, and security configuration. The cascading approach facilitates this: the secure software manages the IOPMP in the boundary of the subsystem. The boundary IOPMP assigns a new RRID to each outgoing transaction, representing that it has been checked by the IOPMP. 
+The outer IOPMPs are tasked with controlling the transactions from a subsystem perspective by the new subsystem-level RRID. That is, the IOPMP only considers the legality of the transactions initiated from a specific subsystem instead of individual transaction initiators. The boundary IOPMP hides some details of the subsystem good for protecting intellect properties. The development flow becomes more abstract, reusable, and modularized.
 
 ====

appendix_a3.adoc

@@ -3,9 +3,9 @@
 
 IOPMP/SPS (Secondary Permission Setting) is an extension to support different sources to share memory domain while allowing each sources to have different R/W/X permission to a single memory domain.
 
-If the IOPMP/SPS extension is implemented, each SRCMD table entry shall additionally define read and write permission registers: SRCMD_R(_s_) and SRCMD_W(_s_), and SRCMD_RH(_s_) and SRCMD_WH(_s_) if applicable. Register SRCMD_R(_s_) and SRCMD_W(_s_) each  has a single fields, SRCMD_R(_s_).md and SRCMD_W(_s_).md respectively representing the read and write permission for each memory domain for source _s_. Setting lock to SRCMD_EN(_s_).l also locks SRCMD_R(_s_), SRCMD_RH(_s_), SRCMD_W(_s_), and SRCMD_WH(_s_).
+If IOPMP/SPS extension is implemented, each SRCMD table entry shall additionally define read and write permission registers: *SRCMD_R(_s_)* and *SRCMD_W(_s_)*, and *SRCMD_RH(_s_)* and *SRCMD_WH(_s_)* if applicable. Register *SRCMD_R(_s_)* and *SRCMD_W(_s_)* each has a single fields, *SRCMD_R(_s_).md* and *SRCMD_W(_s_).md* respectively representing the read and write permission for each memory domain for source _s_. Setting lock to *SRCMD_EN(_s_).l* also locks *SRCMD_R(_s_)*, *SRCMD_RH(_s_)*, *SRCMD_W(_s_)*, and *SRCMD_WH(_s_)*.
 
-IOPMP/SPS has two sets of permission settings: one from IOPMP entry and the other from SRCMD_R/SRCMD_W. IOPMP/SPS shall check read and write permission on both the SRCMD table and entries, a transaction fail the IOPMP/SPS check if it violates either of the permission settings.
+IOPMP/SPS has two sets of permission settings: one from IOPMP entry and the other from *SRCMD_R*/*SRCMD_W*. IOPMP/SPS shall check read and write permission on both the SRCMD table and entries, a transaction fail the IOPMP/SPS check if it violates either of the permission settings.
 
-The IOPMP/SPS register for setting executable permission on each memory domain is [TBD]. 
+The IOPMP/SPS register for setting instruction fetch permission on each memory domain is [TBD].