From d08060cef4facf327957a133c826c7cf749c6846 Mon Sep 17 00:00:00 2001
From: Andrew Waterman <andrew@sifive.com>
Date: Wed, 13 Mar 2019 13:58:04 -0700
Subject: Revise CSR-ordering section

---
 src/csr.tex | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

(limited to 'src/csr.tex')

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
-- 
cgit v1.1