+
# Simple-V (Parallelism Extension Proposal) Specification
* Copyright (C) 2017, 2018, 2019 Luke Kenneth Casson Leighton
-* Status: DRAFTv0.6
-* Last edited: 21 jun 2019
+* Status: DRAFTv0.6.1
+* Last edited: 10 sep 2019
* Ancillary resource: [[opcodes]]
* Ancillary resource: [[sv_prefix_proposal]]
* Ancillary resource: [[abridged_spec]]
* Ancillary resource: [[vblock_format]]
* Ancillary resource: [[appendix]]
-With thanks to:
+Authors/Contributors:
+* Luke Kenneth Casson Leighton
* Allen Baum
* Bruce Hoult
* comp.arch
* A SIMT system
* A Vectorisation Microarchitecture
* A microarchitecture of any specific kind
-* A mandary parallel processor microarchitecture of any kind
+* A mandatory parallel processor microarchitecture of any kind
* A supercomputer extension
SV does **not** tell implementors how or even if they should implement
There are five additional CSRs, available in any privilege level:
* MVL (the Maximum Vector Length)
-* VL (which has different characteristics from standard CSRs)
+* VL (sets which scalar register is to be the Vector Length)
* SUBVL (effectively a kind of SIMD)
* STATE (containing copies of MVL, VL and SUBVL as well as context information)
+* SVPSTATE (state information for SVPrefix)
* PCVBLK (the current operation being executed within a VBLOCK Group)
For User Mode there are the following CSRs:
to the start of the current VBLOCK Group, set on a trap).
* ueSTATE (useful for saving and restoring during context switch,
and for providing fast transitions)
+* ueSVPSTATE when SVPrefix is implemented
+ Note: ueSVPSTATE is mirrored in the top 32 bits of ueSTATE.
-There are also two additional CSRs for Supervisor-Mode:
+There are also three additional CSRs for Supervisor-Mode:
* sePCVBLK
-* seSTATE
+* seSTATE (which contains seSVPSTATE)
+* seSVPSTATE
And likewise for M-Mode:
* mePCVBLK
-* meSTATE
+* meSTATE (which contains meSVPSTATE)
+* meSVPSTATE
The u/m/s CSRs are treated and handled exactly like their (x)epc
-equivalents. On entry to or exit from a privilege level, the contents of its (x)eSTATE are swapped with STATE.
+equivalents. On entry to or exit from a privilege level, the contents
+of its (x)eSTATE are swapped with STATE.
Thus for example, a User Mode trap will end up swapping STATE and ueSTATE
(on both entry and exit), allowing User Mode traps to have their own
Vectorisation Context set up, separated from and unaffected by normal
-user applications. If an M Mode trap occurs in the middle of the U Mode trap, STATE is swapped with meSTATE, and restored on exit: the U Mode trap continues unaware that the M Mode trap even occurred.
+user applications. If an M Mode trap occurs in the middle of the U Mode
+trap, STATE is swapped with meSTATE, and restored on exit: the U Mode
+trap continues unaware that the M Mode trap even occurred.
Likewise, Supervisor Mode may perform context-switches, safe in the
knowledge that its Vectorisation State is unaffected by User Mode.
* In U-Mode, accessing and changing of the S-Mode and U-Mode CSRs
is prohibited.
-An interesting side effect of SV STATE being
-separate and distinct in S Mode
-is that
-Vectorised saving of an entire register file to the stack is a single
-instruction (through accidental provision of LOAD-MULTI semantics). If the
-SVPrefix P64-LD-type format is used, LOAD-MULTI may even be done with a
-single standalone 64 bit opcode (P64 may set up SUBVL, VL and MVL from an
-immediate field, to cover the full regfile). It can even be predicated, which opens up some very
-interesting possibilities.
+An interesting side effect of SV STATE being separate and distinct in S
+Mode is that Vectorised saving of an entire register file to the stack
+is a single instruction (through accidental provision of LOAD-MULTI
+semantics). If the SVPrefix P64-LD-type format is used, LOAD-MULTI may
+even be done with a single standalone 64 bit opcode (P64 may set up SVPSTATE.SUBVL,
+SVPSTATE.VL and SVPSTATE.MVL from an immediate field, to cover the full regfile). It can
+even be predicated, which opens up some very interesting possibilities.
(x)EPCVBLK CSRs must be treated exactly like their corresponding (x)epc
equivalents. See VBLOCK section for details.
## Vector Length (VL) <a name="vl" />
-VSETVL is slightly different from RVV. Similar to RVV, VL is set to be within
-the range 1 <= VL <= MVL (where MVL in turn is limited to 1 <= MVL <= XLEN)
-
- VL = rd = MIN(vlen, MVL)
-
-where 1 <= MVL <= XLEN
-
-However just like MVL it is important to note that the range for VL has
-subtle design implications, covered in the "CSR pseudocode" section
-
-The fixed (specific) setting of VL allows vector LOAD/STORE to be used
-to switch the entire bank of registers using a single instruction (see
-Appendix, "Context Switch Example"). The reason for limiting VL to XLEN
-is down to the fact that predication bits fit into a single register of
-length XLEN bits.
-
-The second and most important change is that, within the limits set by
-MVL, the value passed in **must** be set in VL (and in the
-destination register).
-
-This has implication for the microarchitecture, as VL is required to be
-set (limits from MVL notwithstanding) to the actual value
-requested. RVV has the option to set VL to an arbitrary value that suits
-the conditions and the micro-architecture: SV does *not* permit this.
-
-The reason is so that if SV is to be used for a context-switch or as a
-substitute for LOAD/STORE-Multiple, the operation can be done with only
-2-3 instructions (setup of the CSRs, VSETVL x0, x0, #{regfilelen-1},
-single LD/ST operation). If VL does *not* get set to the register file
-length when VSETVL is called, then a software-loop would be needed.
-To avoid this need, VL *must* be set to exactly what is requested
-(limits notwithstanding).
-
-Therefore, in turn, unlike RVV, implementors *must* provide
-pseudo-parallelism (using sequential loops in hardware) if actual
-hardware-parallelism in the ALUs is not deployed. A hybrid is also
-permitted (as used in Broadcom's VideoCore-IV) however this must be
-*entirely* transparent to the ISA.
-
-The third change is that VSETVL is implemented as a CSR, where the
-behaviour of CSRRW (and CSRRWI) must be changed to specifically store
-the *new* value in the destination register, **not** the old value.
-Where context-load/save is to be implemented in the usual fashion
-by using a single CSRRW instruction to obtain the old value, the
-*secondary* CSR must be used (STATE). This CSR by contrast behaves
-exactly as standard CSRs, and contains more than just VL.
-
-One interesting side-effect of using CSRRWI to set VL is that this
-may be done with a single instruction, useful particularly for a
-context-load/save. There are however limitations: CSRWI's immediate
-is limited to 0-31 (representing VL=1-32).
-
-Note that when VL is set to 1, vector operations cease (but not subvector
-operations: that requires setting SUBVL=1) the hardware loop is reduced
-to a single element: scalar operations. This is in effect the default,
-normal operating mode. However it is important to appreciate that this
-does **not** result in the Register table or SUBVL being disabled. Only
-when the Register table is empty (P48/64 prefix fields notwithstanding)
-would SV have no effect.
+VL is very different from RVV's VL. It contains the scalar register *number* that is to be treated as the Vector Length. It is a sub-field of STATE. When set to zero (x0) VL (vectorisation) is disabled.
+
+Implementations realistically should keep a cached copy of the register pointed to by VL in the instruction issue and decode phases. Out of Order Engines must then, if it is not x0, add this register to Vectorised instruction Dependency Checking as an additional read/write hazard as appropriate.
+
+Setting VL via this CSR is very unusual. It should not normally be needed except when [[specification/sv.setvl]] is not implemented. Note that unlike in sv.setvl, setting VL does not change the contents of the scalar register that it points to, although if the scalar register's contents are not within the range of MVL at the time that VL is set, an illegal instruction exception must be raised.
## SUBVL - Sub Vector Length
Another way to view SUBVL is that each element in the VL length vector is
now SUBVL times elwidth bits in length and now comprises SUBVL discrete
-sub operations. An inner SUBVL for-loop within a VL for-loop in effect,
+sub operations. This can be viewed as an inner SUBVL hardware for-loop within a VL hardware for-loop in effect,
with the sub-element increased every time in the innermost loop. This
is best illustrated in the (simplified) pseudocode example, in the
[[appendix]].
## STATE
+out of date, see <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-June/001896.html>
+
This is a standard CSR that contains sufficient information for a
full context save/restore. It contains (and permits setting of):
* SUBVL
* svdestoffs - the subvector destination element offset of the current
parallel instruction being executed
-* svsrcoffs - for twin-predication, the subvector source element offset
- as well.
Interestingly STATE may hypothetically also be modified to make the
immediately-following instruction to skip a certain number of elements,
The format of the STATE CSR is as follows:
-| (29..28 | (27..26) | (25..24) | (23..18) | (17..12) | (11..6) | (5...0) |
-| ------- | -------- | -------- | -------- | -------- | ------- | ------- |
-| dsvoffs | ssvoffs | subvl | destoffs | srcoffs | vl | maxvl |
+| (31..28) | (27..26) | (25..24) | (23..18) | (17..12) | (11..6) | (5...0) |
+| -------- | -------- | -------- | -------- | -------- | ------- | ------- |
+| rsvd | dsvoffs | subvl | destoffs | srcoffs | vl | maxvl |
+
+Legal values of vl are between 0 and 31.
The relationship between SUBVL and the subvl field is:
When setting this CSR, the following characteristics will be enforced:
* **MAXVL** will be truncated (after offset) to be within the range 1 to XLEN
-* **VL** will be truncated (after offset) to be within the range 1 to MAXVL
+* **VL** must be set to a scalar register between 0 and 31.
* **SUBVL** which sets a SIMD-like quantity, has only 4 values so there
are no changes needed
* **srcoffs** will be truncated to be within the range 0 to VL-1
* **destoffs** will be truncated to be within the range 0 to VL-1
-* **ssvoffs** will be truncated to be within the range 0 to SUBVL-1
* **dsvoffs** will be truncated to be within the range 0 to SUBVL-1
NOTE: if the following instruction is not a twin predicated instruction,
and destoffs or dsvoffs has been set to non-zero, subsequent execution
behaviour is undefined. **USE WITH CARE**.
+NOTE: sub-vector looping does not require a twin-predicate corresponding
+index, because sub-vectors use the *main* (VL) loop predicate bit.
+
+When SVPrefix is implemented, it can have its own VL, MVL and SUBVL, as well as element offsets. SVSTATE.VL acts slightly differently in that it is no longer a pointer to a scalar register but is an actual value just like RVV's VL.
+
+The format of SVSTATE, which fits into *both* the top bits of STATE and also into a separate CSR, is as follows:
+
+| (31..28) | (27..26) | (25..24) | (23..18) | (17..12) | (11..6) | (5...0) |
+| -------- | -------- | -------- | -------- | -------- | ------- | ------- |
+| rsvd | dsvoffs | subvl | destoffs | srcoffs | vl | maxvl |
+
### Hardware rules for when to increment STATE offsets
The offsets inside STATE are like the indices in a loop, except
functions as follows:
set_mvl_csr(value, rd):
- regs[rd] = STATE.MVL
STATE.MVL = MIN(value, STATE.MVL)
get_mvl_csr(rd):
regs[rd] = STATE.VL
set_vl_csr(value, rd):
- STATE.VL = MIN(value, STATE.MVL)
- regs[rd] = STATE.VL # yes returning the new value NOT the old CSR
+ STATE.VL = rd
return STATE.VL
get_vl_csr(rd):
- regs[rd] = STATE.VL
return STATE.VL
Note that where setting MVL behaves as a normal CSR (returns the old
[[!inline raw="yes" pages="simple_v_extension/pred_table_format" ]]
The 8 bit format is a compact and less expressive variant of the full
-16 bit format. Using the 8 bit formatis very different: the predicate
+16 bit format. Using the 8 bit format is very different: the predicate
register to use is implicit, and numbering begins inplicitly from x9. The
regnum is still used to "activate" predication, in the same fashion as
described above.
The 16 bit Predication CSR Table is a key-value store, so
implementation-wise it will be faster to turn the table around (maintain
-topologically equivalent state):
+topologically equivalent state). Opportunities then exist to access
+registers in unary form instead of binary, saving gates and power by
+only activating "redirection" with a single AND gate, instead of
+multiple multi-bit XORs (a CAM):
[[!inline raw="yes" pages="simple_v_extension/pred_table" ]]
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
+ffirst interacts with zero- and non-zero predication. In non-zeroing
+mode, masked-out operations are simply excluded from testing (can never
+fail). However for fail-comparisons (not faults) in zeroing mode, the
+result will be zero: this *always* "fails", thus on the very first
+masked-out element ffirst will always terminate.
+
+Note that ffirst mode works because the execution order must "appear" to be
+(in "program order"). 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).
+the element operations in sequence and cancel speculatively-executed
+ones (giving the appearance of in-order execution).
Note also, that if ffirst mode is needed without predication, a special
"always-on" Predicate Table Entry may be constructed by setting
# Instructions <a name="instructions" />
-See [[appendix]]
+See [[appendix]] for specific cases where instruction behaviour is
+augmented. A greatly simplified example is below. Note that this
+is the ADD implementation, not a separate VADD instruction:
+
+[[!inline raw="yes" pages="simple_v_extension/simple_add_example" ]]
+
+Note that several things have been left out of this example.
+See [[appendix]] for additional examples that show how to add
+support for additional features (twin predication, elwidth,
+zeroing, SUBVL etc.)
+
+Branches in particular have been transparently augmented to include
+"collation" of comparison results into a tagged register.
# Exceptions
-TODO: expand. Exceptions may occur at any time, in any given underlying
-scalar operation. This implies that context-switching (traps) may
-occur, and operation must be returned to where it left off. That in
-turn implies that the full state - including the current parallel
-element being processed - has to be saved and restored. This is
-what the **STATE** CSR is for.
+Exceptions may occur at any time, in any given underlying scalar
+operation. This implies that context-switching (traps) may occur, and
+operation must be returned to where it left off. That in turn implies
+that the full state - including the current parallel element being
+processed - has to be saved and restored. This is what the **STATE**
+and **PCVBLK** CSRs are for.
The implications are that all underlying individual scalar operations
"issued" by the parallelisation have to appear to be executed sequentially.
The further implications are that if two or more individual element
operations are underway, and one with an earlier index causes an exception,
-it may be necessary for the microarchitecture to **discard** or terminate
-operations with higher indices.
+it will be necessary for the microarchitecture to **discard** or terminate
+operations with higher indices. Optimisated microarchitectures could
+hypothetically store (cache) results, for subsequent replay if appropriate.
-This being somewhat dissatisfactory, an "opaque predication" variant
-of the STATE CSR is being considered.
+In short: exception handling **MUST** be precise, in-order, and exactly
+like Standard RISC-V as far as the instruction execution order is
+concerned, regardless of whether it is PC, PCVBLK, VL or SUBVL that
+is currently being incremented.
# Hints
# Vector Block Format <a name="vliw-format"></a>
-See ancillary resource: [[vblock_format]]
+The VBLOCK Format allows Register, Predication and Vector Length to be contextually associated with a group of RISC-V scalar opcodes. The format is as follows:
+
+[[!inline raw="yes" pages="simple_v_extension/vblock_format_table" ]]
+
+For more details, including the CSRs, see ancillary resource: [[vblock_format]]
# Under consideration <a name="issues"></a>
projects / libreriscv.git / blobdiff