aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Waterman <andrew@sifive.com>2019-03-13 13:58:04 -0700
committerAndrew Waterman <andrew@sifive.com>2019-03-13 13:58:04 -0700
commitd08060cef4facf327957a133c826c7cf749c6846 (patch)
treeaf4ade113b57541ab34a6a876ee576d05dde5d8b
parent0992858efdb226e14a9821cea862c65789f07c14 (diff)
downloadriscv-isa-manual-d08060cef4facf327957a133c826c7cf749c6846.zip
riscv-isa-manual-d08060cef4facf327957a133c826c7cf749c6846.tar.gz
riscv-isa-manual-d08060cef4facf327957a133c826c7cf749c6846.tar.bz2
Revise CSR-ordering section
-rw-r--r--src/csr.tex28
1 files changed, 22 insertions, 6 deletions
diff --git a/src/csr.tex b/src/csr.tex
index aa0f5f8..1118fb1 100644
--- a/src/csr.tex
+++ b/src/csr.tex
@@ -157,12 +157,28 @@ bits in the CSR when the old value is not required: CSRS/CSRC {\em
\subsection*{CSR Access Ordering}
-Each RISC-V hart observes its own CSR accesses as if they were performed
-sequentially in program order. RISC-V has a relaxed CSR ordering model
-between harts, requiring an explicit FENCE instruction to guarantee any
-specific ordering between CSR accesses and memory accesses. For the purposes
-of the FENCE instruction (see Section~\ref{sec:fence}), CSR reads are
-considered device input (I), and CSR writes are considered device output (O).
+Each RISC-V hart observes its own CSR accesses, including its implicit CSR
+accesses, as if they were performed in program order. Between harts, RISC-V
+has a relaxed CSR ordering model, in that other harts may perceive some CSR
+accesses in a different order. CSR accesses are ordered with each other and
+with memory accesses by the syntactic dependency rules of the memory model
+(see Section~\ref{sec:rvwmo}) and by FENCE instructions. For the purposes of
+the FENCE instruction (see Section~\ref{sec:fence}), CSR reads are considered
+device input (I), and CSR writes are considered device output (O).
+
+For CSR accesses that cause side effects, these ordering constraints dictate
+the ordering of side-effect initiation, not necessarily the ordering of
+side-effect completion.
+
+The hardware platform may define some CSRs as belonging to a strongly ordered
+I/O space, as defined in the Memory-Ordering PMAs section in Volume II of this
+manual, thereby implying stronger ordering constraints with other CSR
+accesses, memory-mapped I/O accesses, or both.
+
+\begin{commentary}
+A future revision of the memory model will formalize this CSR I/O ordering
+scheme.
+\end{commentary}
\begin{commentary}
Some CSRs, including those defined in Chapter~\ref{sec:single-float}, are not