From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Mon, 24 Jun 2019 13:57:59 +0000 (+0100)
Subject: fail-first mode
X-Git-Tag: convert-csv-opcode-to-binary~4481
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=8bb469701d7a03ea5f4a4a718e323b7aa6e39aa0;p=libreriscv.git

fail-first mode
---

diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn
index 638ce711a..7a4704dcb 100644
--- a/simple_v_extension/specification.mdwn
+++ b/simple_v_extension/specification.mdwn
@@ -712,14 +712,45 @@ is removed.
 
 ## Fail-on-First Mode
 
-* ffirst is a special mode that, except for the first element,
-  stops sequential element processing when a trap or fail-condition
-  occurs.
-  The first element is treated normally (as if ffirst is clear).
-  Should any subsequent element instruction require a trap, instead
-  it and subsequent indexed elements are ignored (or cancelled in
-  out-of-order designs), and VL is set to the *last* instruction
-  that did not take the trap.
+ffirst is a special data-dependent mode.  There are two variants: one
+is for faults: typically for LOAD/STORE operations, which may encounter
+end of page faults during a series of operations.  The other variant is
+comparisons such as FEQ (or the augmented behaviour of Branch), and
+any operation that returns a result of zero (whether integer or floating-point).
+In the FP case, this includes negative-zero.
+
+Note that the execution order must "appear" to be sequential for ffirst
+mode to work correctly.  An in-order architecture must execute the element
+operations in sequence, whilst an out-of-order architecture must *commit*
+the element operations in sequence (giving the appearance of in-order
+execution).
+
+For traps:
+
+Except for the first element, ffault stops sequential element processing
+when a trap occurs.  The first element is treated normally (as if ffirst
+is clear).  Should any subsequent element instruction require a trap,
+instead it and subsequent indexed elements are ignored (or cancelled in
+out-of-order designs), and VL is set to the *last* instruction that did
+not take the trap.
+
+If SUBVL is being used (SUBVL!=1), the first *sub-group* of elements
+will cause a trap as normal (as if ffirst is not set); subsequently,
+the trap must not occur in the *sub-group* of elements.  SUBVL will **NOT**
+be modified.
+
+For conditional tests:
+
+ffault stops sequential element conditional testing on the first element result
+being zero.  VL is set to the number of elements that were processed before
+the fail-condition was encountered.
+
+Note that just as with traps, if SUBVL!=1, the first of any of the *sub-group*
+will cause the processing to end, and, even if there were elements within
+the *sub-group* that passed the test, that sub-group is still (entirely)
+excluded from the count (from setting VL).  i.e. VL is set to the total
+number of *sub-groups* that had no fail-condition up until execution was
+stopped.
 
 ## REMAP CSR <a name="remap" />
 
@@ -1029,6 +1060,12 @@ comprehensive in its effect on instructions.
 
 ## Branch Instructions
 
+Branch operations are augmented slightly to be a little more like FP
+Compares (FEQ, FNE etc.), by permitting the cumulation (and storage)
+of multiple comparisons into a register (taken indirectly from the predicate
+table).  As such, "ffirst" - fail-on-first - condition mode can be enabled.
+See ffirst mode in the Predication Table section.
+
 ### Standard Branch <a name="standard_branch"></a>
 
 Branch operations use standard RV opcodes that are reinterpreted to
@@ -1181,6 +1218,8 @@ integer register (rd) to determine the predicate.  FP Compare is **not**
 a twin-predication operation, as, again, just as with SV Branches,
 there are three registers involved: FP src1, FP src2 and INT rd.
 
+Also: note that ffirst (fail first mode) applies directly to this operation.
+
 ### Compressed Branch Instruction
 
 Compressed Branch instructions are, just like standard Branch instructions,