1 # Simple-V (Parallelism Extension Proposal) Specification
3 * Copyright (C) 2017, 2018, 2019 Luke Kenneth Casson Leighton
5 * Last edited: 30 jun 2019
6 * Ancillary resource: [[opcodes]]
7 * Ancillary resource: [[sv_prefix_proposal]]
8 * Ancillary resource: [[abridged_spec]]
9 * Ancillary resource: [[vblock_format]]
10 * Ancillary resource: [[appendix]]
21 * The RISC-V Founders, without whom this all would not be possible.
25 # Summary and Background: Rationale
27 Simple-V is a uniform parallelism API for RISC-V hardware that has several
28 unplanned side-effects including code-size reduction, expansion of
29 HINT space and more. The reason for
30 creating it is to provide a manageable way to turn a pre-existing design
31 into a parallel one, in a step-by-step incremental fashion, without adding any new opcodes, thus allowing
32 the implementor to focus on adding hardware where it is needed and necessary.
33 The primary target is for mobile-class 3D GPUs and VPUs, with secondary
34 goals being to reduce executable size (by extending the effectiveness of RV opcodes, RVC in particular) and reduce context-switch latency.
36 Critically: **No new instructions are added**. The parallelism (if any
37 is implemented) is implicitly added by tagging *standard* scalar registers
38 for redirection. When such a tagged register is used in any instruction,
39 it indicates that the PC shall **not** be incremented; instead a loop
40 is activated where *multiple* instructions are issued to the pipeline
41 (as determined by a length CSR), with contiguously incrementing register
42 numbers starting from the tagged register. When the last "element"
43 has been reached, only then is the PC permitted to move on. Thus
44 Simple-V effectively sits (slots) *in between* the instruction decode phase
47 The barrier to entry with SV is therefore very low. The minimum
48 compliant implementation is software-emulation (traps), requiring
49 only the CSRs and CSR tables, and that an exception be thrown if an
50 instruction's registers are detected to have been tagged. The looping
51 that would otherwise be done in hardware is thus carried out in software,
52 instead. Whilst much slower, it is "compliant" with the SV specification,
53 and may be suited for implementation in RV32E and also in situations
54 where the implementor wishes to focus on certain aspects of SV, without
55 unnecessary time and resources into the silicon, whilst also conforming
56 strictly with the API. A good area to punt to software would be the
57 polymorphic element width capability for example.
59 Hardware Parallelism, if any, is therefore added at the implementor's
60 discretion to turn what would otherwise be a sequential loop into a
63 To emphasise that clearly: Simple-V (SV) is *not*:
67 * A Vectorisation Microarchitecture
68 * A microarchitecture of any specific kind
69 * A mandary parallel processor microarchitecture of any kind
70 * A supercomputer extension
72 SV does **not** tell implementors how or even if they should implement
73 parallelism: it is a hardware "API" (Application Programming Interface)
74 that, if implemented, presents a uniform and consistent way to *express*
75 parallelism, at the same time leaving the choice of if, how, how much,
76 when and whether to parallelise operations **entirely to the implementor**.
80 The principle of SV is as follows:
82 * Standard RV instructions are "prefixed" (extended) through a 48/64
83 bit format (single instruction option) or a variable
84 length VLIW-like prefix (multi or "grouped" option).
85 * The prefix(es) indicate which registers are "tagged" as
86 "vectorised". Predicates can also be added, and element widths
87 overridden on any src or dest register.
88 * A "Vector Length" CSR is set, indicating the span of any future
89 "parallel" operations.
90 * If any operation (a **scalar** standard RV opcode) uses a register
91 that has been so "marked" ("tagged"), a hardware "macro-unrolling loop"
92 is activated, of length VL, that effectively issues **multiple**
93 identical instructions using contiguous sequentially-incrementing
94 register numbers, based on the "tags".
95 * **Whether they be executed sequentially or in parallel or a
96 mixture of both or punted to software-emulation in a trap handler
97 is entirely up to the implementor**.
99 In this way an entire scalar algorithm may be vectorised with
100 the minimum of modification to the hardware and to compiler toolchains.
102 To reiterate: **There are *no* new opcodes**. The scheme works *entirely*
103 on hidden context that augments *scalar* RISCV instructions.
105 # CSRs <a name="csrs"></a>
107 * An optional "reshaping" CSR key-value table which remaps from a 1D
108 linear shape to 2D or 3D, including full transposition.
110 There are five additional CSRs, available in any privilege level:
112 * MVL (the Maximum Vector Length)
113 * VL (which has different characteristics from standard CSRs)
114 * SUBVL (effectively a kind of SIMD)
115 * STATE (containing copies of MVL, VL and SUBVL as well as context information)
116 * PCVBLK (the current operation being executed within a VBLOCK Group)
118 For User Mode there are the following CSRs:
120 * uePCVBLK (a copy of the sub-execution Program Counter, that is relative
121 to the start of the current VBLOCK Group, set on a trap).
122 * ueSTATE (useful for saving and restoring during context switch,
123 and for providing fast transitions)
125 There are also two additional CSRs for Supervisor-Mode:
130 And likewise for M-Mode:
135 The u/m/s CSRs are treated and handled exactly like their (x)epc
136 equivalents. On entry to or exit from a privilege level, the contents
137 of its (x)eSTATE are swapped with STATE.
139 Thus for example, a User Mode trap will end up swapping STATE and ueSTATE
140 (on both entry and exit), allowing User Mode traps to have their own
141 Vectorisation Context set up, separated from and unaffected by normal
142 user applications. If an M Mode trap occurs in the middle of the U Mode
143 trap, STATE is swapped with meSTATE, and restored on exit: the U Mode
144 trap continues unaware that the M Mode trap even occurred.
146 Likewise, Supervisor Mode may perform context-switches, safe in the
147 knowledge that its Vectorisation State is unaffected by User Mode.
149 The access pattern for these groups of CSRs in each mode follows the
150 same pattern for other CSRs that have M-Mode and S-Mode "mirrors":
152 * In M-Mode, the S-Mode and U-Mode CSRs are separate and distinct.
153 * In S-Mode, accessing and changing of the M-Mode CSRs is transparently
155 to changing the S-Mode CSRs. Accessing and changing the U-Mode
157 * In U-Mode, accessing and changing of the S-Mode and U-Mode CSRs
160 An interesting side effect of SV STATE being separate and distinct in S
161 Mode is that Vectorised saving of an entire register file to the stack
162 is a single instruction (through accidental provision of LOAD-MULTI
163 semantics). If the SVPrefix P64-LD-type format is used, LOAD-MULTI may
164 even be done with a single standalone 64 bit opcode (P64 may set up SUBVL,
165 VL and MVL from an immediate field, to cover the full regfile). It can
166 even be predicated, which opens up some very interesting possibilities.
168 (x)EPCVBLK CSRs must be treated exactly like their corresponding (x)epc
169 equivalents. See VBLOCK section for details.
171 ## MAXVECTORLENGTH (MVL) <a name="mvl" />
173 MAXVECTORLENGTH is the same concept as MVL in RVV, except that it
174 is variable length and may be dynamically set. MVL is
175 however limited to the regfile bitwidth XLEN (1-32 for RV32,
176 1-64 for RV64 and so on).
178 The reason for setting this limit is so that predication registers, when
179 marked as such, may fit into a single register as opposed to fanning
180 out over several registers. This keeps the hardware implementation a
183 The other important factor to note is that the actual MVL is internally
184 stored **offset by one**, so that it can fit into only 6 bits (for RV64)
185 and still cover a range up to XLEN bits. Attempts to set MVL to zero will
186 return an exception. This is expressed more clearly in the "pseudocode"
187 section, where there are subtle differences between CSRRW and CSRRWI.
189 ## Vector Length (VL) <a name="vl" />
191 VSETVL is slightly different from RVV. Similar to RVV, VL is set to be within
192 the range 1 <= VL <= MVL (where MVL in turn is limited to 1 <= MVL <= XLEN)
194 VL = rd = MIN(vlen, MVL)
196 where 1 <= MVL <= XLEN
198 However just like MVL it is important to note that the range for VL has
199 subtle design implications, covered in the "CSR pseudocode" section
201 The fixed (specific) setting of VL allows vector LOAD/STORE to be used
202 to switch the entire bank of registers using a single instruction (see
203 Appendix, "Context Switch Example"). The reason for limiting VL to XLEN
204 is down to the fact that predication bits fit into a single register of
207 The second and most important change is that, within the limits set by
208 MVL, the value passed in **must** be set in VL (and in the
209 destination register).
211 This has implication for the microarchitecture, as VL is required to be
212 set (limits from MVL notwithstanding) to the actual value
213 requested. RVV has the option to set VL to an arbitrary value that suits
214 the conditions and the micro-architecture: SV does *not* permit this.
216 The reason is so that if SV is to be used for a context-switch or as a
217 substitute for LOAD/STORE-Multiple, the operation can be done with only
218 2-3 instructions (setup of the CSRs, VSETVL x0, x0, #{regfilelen-1},
219 single LD/ST operation). If VL does *not* get set to the register file
220 length when VSETVL is called, then a software-loop would be needed.
221 To avoid this need, VL *must* be set to exactly what is requested
222 (limits notwithstanding).
224 Therefore, in turn, unlike RVV, implementors *must* provide
225 pseudo-parallelism (using sequential loops in hardware) if actual
226 hardware-parallelism in the ALUs is not deployed. A hybrid is also
227 permitted (as used in Broadcom's VideoCore-IV) however this must be
228 *entirely* transparent to the ISA.
230 The third change is that VSETVL is implemented as a CSR, where the
231 behaviour of CSRRW (and CSRRWI) must be changed to specifically store
232 the *new* value in the destination register, **not** the old value.
233 Where context-load/save is to be implemented in the usual fashion
234 by using a single CSRRW instruction to obtain the old value, the
235 *secondary* CSR must be used (STATE). This CSR by contrast behaves
236 exactly as standard CSRs, and contains more than just VL.
238 One interesting side-effect of using CSRRWI to set VL is that this
239 may be done with a single instruction, useful particularly for a
240 context-load/save. There are however limitations: CSRWI's immediate
241 is limited to 0-31 (representing VL=1-32).
243 Note that when VL is set to 1, vector operations cease (but not subvector
244 operations: that requires setting SUBVL=1) the hardware loop is reduced
245 to a single element: scalar operations. This is in effect the default,
246 normal operating mode. However it is important to appreciate that this
247 does **not** result in the Register table or SUBVL being disabled. Only
248 when the Register table is empty (P48/64 prefix fields notwithstanding)
249 would SV have no effect.
251 ## SUBVL - Sub Vector Length
253 This is a "group by quantity" that effectively asks each iteration
254 of the hardware loop to load SUBVL elements of width elwidth at a
255 time. Effectively, SUBVL is like a SIMD multiplier: instead of just 1
256 operation issued, SUBVL operations are issued.
258 Another way to view SUBVL is that each element in the VL length vector is
259 now SUBVL times elwidth bits in length and now comprises SUBVL discrete
260 sub operations. An inner SUBVL for-loop within a VL for-loop in effect,
261 with the sub-element increased every time in the innermost loop. This
262 is best illustrated in the (simplified) pseudocode example, in the
265 The primary use case for SUBVL is for 3D FP Vectors. A Vector of 3D
266 coordinates X,Y,Z for example may be loaded and multiplied then stored, per
267 VL element iteration, rather than having to set VL to three times larger.
269 Setting this CSR to 0 must raise an exception. Setting it to a value
270 greater than 4 likewise. To see the relationship with STATE, see below.
272 The main effect of SUBVL is that predication bits are applied per
273 **group**, rather than by individual element.
275 This saves a not insignificant number of instructions when handling 3D
276 vectors, as otherwise a much longer predicate mask would have to be set
277 up with regularly-repeated bit patterns.
279 See SUBVL Pseudocode illustration in the [[appendix]], for details.
283 out of date, see <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-June/001896.html>
285 This is a standard CSR that contains sufficient information for a
286 full context save/restore. It contains (and permits setting of):
290 * destoffs - the destination element offset of the current parallel
291 instruction being executed
292 * srcoffs - for twin-predication, the source element offset as well.
294 * svdestoffs - the subvector destination element offset of the current
295 parallel instruction being executed
297 Interestingly STATE may hypothetically also be modified to make the
298 immediately-following instruction to skip a certain number of elements,
299 by playing with destoffs and srcoffs (and the subvector offsets as well)
301 Setting destoffs and srcoffs is realistically intended for saving state
302 so that exceptions (page faults in particular) may be serviced and the
303 hardware-loop that was being executed at the time of the trap, from
304 user-mode (or Supervisor-mode), may be returned to and continued from
305 exactly where it left off. The reason why this works is because setting
306 User-Mode STATE will not change (not be used) in M-Mode or S-Mode (and
307 is entirely why M-Mode and S-Mode have their own STATE CSRs, meSTATE
310 The format of the STATE CSR is as follows:
312 | (31..28) | (27..26) | (25..24) | (23..18) | (17..12) | (11..6) | (5...0) |
313 | -------- | -------- | -------- | -------- | -------- | ------- | ------- |
314 | rsvd | dsvoffs | subvl | destoffs | srcoffs | vl | maxvl |
316 The relationship between SUBVL and the subvl field is:
325 When setting this CSR, the following characteristics will be enforced:
327 * **MAXVL** will be truncated (after offset) to be within the range 1 to XLEN
328 * **VL** will be truncated (after offset) to be within the range 1 to MAXVL
329 * **SUBVL** which sets a SIMD-like quantity, has only 4 values so there
330 are no changes needed
331 * **srcoffs** will be truncated to be within the range 0 to VL-1
332 * **destoffs** will be truncated to be within the range 0 to VL-1
333 * **dsvoffs** will be truncated to be within the range 0 to SUBVL-1
335 NOTE: if the following instruction is not a twin predicated instruction,
336 and destoffs or dsvoffs has been set to non-zero, subsequent execution
337 behaviour is undefined. **USE WITH CARE**.
339 NOTE: sub-vector looping does not require a twin-predicate corresponding
340 index, because sub-vectors use the *main* (VL) loop predicate bit.
342 ### Hardware rules for when to increment STATE offsets
344 The offsets inside STATE are like the indices in a loop, except
345 in hardware. They are also partially (conceptually) similar to a
346 "sub-execution Program Counter". As such, and to allow proper context
347 switching and to define correct exception behaviour, the following rules
350 * When the VL CSR is set, srcoffs and destoffs are reset to zero.
351 * Each instruction that contains a "tagged" register shall start
352 execution at the *current* value of srcoffs (and destoffs in the case
354 * Unpredicated bits (in nonzeroing mode) shall cause the element operation
355 to skip, incrementing the srcoffs (or destoffs)
356 * On execution of an element operation, Exceptions shall **NOT** cause
357 srcoffs or destoffs to increment.
358 * On completion of the full Vector Loop (srcoffs = VL-1 or destoffs =
359 VL-1 after the last element is executed), both srcoffs and destoffs
360 shall be reset to zero.
362 This latter is why srcoffs and destoffs may be stored as values from
363 0 to XLEN-1 in the STATE CSR, because as loop indices they refer to
364 elements. srcoffs and destoffs never need to be set to VL: their maximum
365 operating values are limited to 0 to VL-1.
367 The same corresponding rules apply to SUBVL, svsrcoffs and svdestoffs.
369 ## MVL and VL Pseudocode
371 The pseudo-code for get and set of VL and MVL use the following internal
372 functions as follows:
374 set_mvl_csr(value, rd):
376 STATE.MVL = MIN(value, STATE.MVL)
381 set_vl_csr(value, rd):
382 STATE.VL = MIN(value, STATE.MVL)
383 regs[rd] = STATE.VL # yes returning the new value NOT the old CSR
390 Note that where setting MVL behaves as a normal CSR (returns the old
391 value), unlike standard CSR behaviour, setting VL will return the **new**
392 value of VL **not** the old one.
394 For CSRRWI, the range of the immediate is restricted to 5 bits. In order to
395 maximise the effectiveness, an immediate of 0 is used to set VL=1,
396 an immediate of 1 is used to set VL=2 and so on:
398 CSRRWI_Set_MVL(value):
399 set_mvl_csr(value+1, x0)
401 CSRRWI_Set_VL(value):
402 set_vl_csr(value+1, x0)
404 However for CSRRW the following pseudocode is used for MVL and VL,
405 where setting the value to zero will cause an exception to be raised.
406 The reason is that if VL or MVL are set to zero, the STATE CSR is
407 not capable of storing that value.
409 CSRRW_Set_MVL(rs1, rd):
411 if value == 0 or value > XLEN:
413 set_mvl_csr(value, rd)
415 CSRRW_Set_VL(rs1, rd):
417 if value == 0 or value > XLEN:
419 set_vl_csr(value, rd)
421 In this way, when CSRRW is utilised with a loop variable, the value
422 that goes into VL (and into the destination register) may be used
423 in an instruction-minimal fashion:
425 CSRvect1 = {type: F, key: a3, val: a3, elwidth: dflt}
426 CSRvect2 = {type: F, key: a7, val: a7, elwidth: dflt}
427 CSRRWI MVL, 3 # sets MVL == **4** (not 3)
428 j zerotest # in case loop counter a0 already 0
430 CSRRW VL, t0, a0 # vl = t0 = min(mvl, a0)
431 ld a3, a1 # load 4 registers a3-6 from x
432 slli t1, t0, 3 # t1 = vl * 8 (in bytes)
433 ld a7, a2 # load 4 registers a7-10 from y
434 add a1, a1, t1 # increment pointer to x by vl*8
435 fmadd a7, a3, fa0, a7 # v1 += v0 * fa0 (y = a * x + y)
436 sub a0, a0, t0 # n -= vl (t0)
437 st a7, a2 # store 4 registers a7-10 to y
438 add a2, a2, t1 # increment pointer to y by vl*8
440 bnez a0, loop # repeat if n != 0
442 With the STATE CSR, just like with CSRRWI, in order to maximise the
443 utilisation of the limited bitspace, "000000" in binary represents
444 VL==1, "00001" represents VL==2 and so on (likewise for MVL):
446 CSRRW_Set_SV_STATE(rs1, rd):
449 STATE.MVL = set_mvl_csr(value[11:6]+1)
450 STATE.VL = set_vl_csr(value[5:0]+1)
451 STATE.destoffs = value[23:18]>>18
452 STATE.srcoffs = value[23:18]>>12
455 regs[rd] = (STATE.MVL-1) | (STATE.VL-1)<<6 | (STATE.srcoffs)<<12 |
459 In both cases, whilst CSR read of VL and MVL return the exact values
460 of VL and MVL respectively, reading and writing the STATE CSR returns
461 those values **minus one**. This is absolutely critical to implement
462 if the STATE CSR is to be used for fast context-switching.
464 ## VL, MVL and SUBVL instruction aliases
466 This table contains pseudo-assembly instruction aliases. Note the
467 subtraction of 1 from the CSRRWI pseudo variants, to compensate for the
468 reduced range of the 5 bit immediate.
472 | SETVL rd, rs | CSRRW VL, rd, rs |
473 | SETVLi rd, #n | CSRRWI VL, rd, #n-1 |
474 | GETVL rd | CSRRW VL, rd, x0 |
475 | SETMVL rd, rs | CSRRW MVL, rd, rs |
476 | SETMVLi rd, #n | CSRRWI MVL,rd, #n-1 |
477 | GETMVL rd | CSRRW MVL, rd, x0 |
479 Note: CSRRC and other bitsetting may still be used, they are however not particularly useful (very obscure).
481 ## Register key-value (CAM) table <a name="regcsrtable" />
483 *NOTE: in prior versions of SV, this table used to be writable and
484 accessible via CSRs. It is now stored in the VBLOCK instruction format. Note
485 that this table does *not* get applied to the SVPrefix P48/64 format,
486 only to scalar opcodes*
488 The purpose of the Register table is three-fold:
490 * To mark integer and floating-point registers as requiring "redirection"
491 if it is ever used as a source or destination in any given operation.
492 This involves a level of indirection through a 5-to-7-bit lookup table,
493 such that **unmodified** operands with 5 bits (3 for some RVC ops) may
494 access up to **128** registers.
495 * To indicate whether, after redirection through the lookup table, the
496 register is a vector (or remains a scalar).
497 * To over-ride the implicit or explicit bitwidth that the operation would
498 normally give the register.
500 Note: clearly, if an RVC operation uses a 3 bit spec'd register (x8-x15)
501 and the Register table contains entried that only refer to registerd
502 x1-x14 or x16-x31, such operations will *never* activate the VL hardware
505 If however the (16 bit) Register table does contain such an entry (x8-x15
506 or x2 in the case of LWSP), that src or dest reg may be redirected
507 anywhere to the *full* 128 register range. Thus, RVC becomes far more
508 powerful and has many more opportunities to reduce code size that in
509 Standard RV32/RV64 executables.
511 [[!inline raw="yes" pages="simple_v_extension/reg_table_format" ]]
513 i/f is set to "1" to indicate that the redirection/tag entry is to
514 be applied to integer registers; 0 indicates that it is relevant to
515 floating-point registers.
517 The 8 bit format is used for a much more compact expression. "isvec"
518 is implicit and, similar to [[sv_prefix_proposal]], the target vector
519 is "regnum<<2", implicitly. Contrast this with the 16-bit format where
520 the target vector is *explicitly* named in bits 8 to 14, and bit 15 may
521 optionally set "scalar" mode.
523 Note that whilst SVPrefix adds one extra bit to each of rd, rs1 etc.,
524 and thus the "vector" mode need only shift the (6 bit) regnum by 1 to
525 get the actual (7 bit) register number to use, there is not enough space
526 in the 8 bit format (only 5 bits for regnum) so "regnum<<2" is required.
528 vew has the following meanings, indicating that the instruction's
529 operand size is "over-ridden" in a polymorphic fashion:
532 | --- | ------------------- |
533 | 00 | default (XLEN/FLEN) |
538 As the above table is a CAM (key-value store) it may be appropriate
539 (faster, implementation-wise) to expand it as follows:
541 [[!inline raw="yes" pages="simple_v_extension/reg_table" ]]
543 ## Predication Table <a name="predication_csr_table"></a>
545 *NOTE: in prior versions of SV, this table used to be writable and
546 accessible via CSRs. It is now stored in the VBLOCK instruction format.
547 The table does **not** apply to SVPrefix opcodes*
549 The Predication Table is a key-value store indicating whether, if a
550 given destination register (integer or floating-point) is referred to
551 in an instruction, it is to be predicated. Like the Register table, it
552 is an indirect lookup that allows the RV opcodes to not need modification.
554 It is particularly important to note
555 that the *actual* register used can be *different* from the one that is
556 in the instruction, due to the redirection through the lookup table.
558 * regidx is the register that in combination with the
559 i/f flag, if that integer or floating-point register is referred to in a
560 (standard RV) instruction results in the lookup table being referenced
561 to find the predication mask to use for this operation.
562 * predidx is the *actual* (full, 7 bit) register to be used for the
564 * inv indicates that the predication mask bits are to be inverted
565 prior to use *without* actually modifying the contents of the
566 register from which those bits originated.
567 * zeroing is either 1 or 0, and if set to 1, the operation must
568 place zeros in any element position where the predication mask is
569 set to zero. If zeroing is set to 0, unpredicated elements *must*
570 be left alone. Some microarchitectures may choose to interpret
571 this as skipping the operation entirely. Others which wish to
572 stick more closely to a SIMD architecture may choose instead to
573 interpret unpredicated elements as an internal "copy element"
574 operation (which would be necessary in SIMD microarchitectures
575 that perform register-renaming)
576 * ffirst is a special mode that stops sequential element processing when
577 a data-dependent condition occurs, whether a trap or a conditional test.
578 The handling of each (trap or conditional test) is slightly different:
579 see Instruction sections for further details
581 [[!inline raw="yes" pages="simple_v_extension/pred_table_format" ]]
583 The 8 bit format is a compact and less expressive variant of the full
584 16 bit format. Using the 8 bit format is very different: the predicate
585 register to use is implicit, and numbering begins inplicitly from x9. The
586 regnum is still used to "activate" predication, in the same fashion as
589 The 16 bit Predication CSR Table is a key-value store, so
590 implementation-wise it will be faster to turn the table around (maintain
591 topologically equivalent state). Opportunities then exist to access
592 registers in unary form instead of binary, saving gates and power by
593 only activating "redirection" with a single AND gate, instead of
594 multiple multi-bit XORs (a CAM):
596 [[!inline raw="yes" pages="simple_v_extension/pred_table" ]]
598 So when an operation is to be predicated, it is the internal state that
599 is used. In Section 6.4.2 of Hwacha's Manual (EECS-2015-262) the following
600 pseudo-code for operations is given, where p is the explicit (direct)
601 reference to the predication register to be used:
603 for (int i=0; i<vl; ++i)
605 (d ? vreg[rd][i] : sreg[rd]) =
606 iop(s1 ? vreg[rs1][i] : sreg[rs1],
607 s2 ? vreg[rs2][i] : sreg[rs2]); // for insts with 2 inputs
609 This instead becomes an *indirect* reference using the *internal* state
610 table generated from the Predication CSR key-value store, which is used
614 preg = int_pred_reg[rd]
616 preg = fp_pred_reg[rd]
618 for (int i=0; i<vl; ++i)
619 predicate, zeroing = get_pred_val(type(iop) == INT, rd):
620 if (predicate && (1<<i))
621 result = iop(s1 ? regfile[rs1+i] : regfile[rs1],
622 s2 ? regfile[rs2+i] : regfile[rs2]);
623 (d ? regfile[rd+i] : regfile[rd]) = result
624 if preg.ffirst and result == 0:
625 VL = i # result was zero, end loop early, return VL
628 (d ? regfile[rd+i] : regfile[rd]) = 0
632 * d, s1 and s2 are booleans indicating whether destination,
633 source1 and source2 are vector or scalar
634 * key-value CSR-redirection of rd, rs1 and rs2 have NOT been included
635 above, for clarity. rd, rs1 and rs2 all also must ALSO go through
636 register-level redirection (from the Register table) if they are
638 * fail-on-first mode stops execution early whenever an operation
639 returns a zero value. floating-point results count both
640 positive-zero as well as negative-zero as "fail".
642 If written as a function, obtaining the predication mask (and whether
643 zeroing takes place) may be done as follows:
645 [[!inline raw="yes" pages="simple_v_extension/get_pred_value" ]]
647 Note here, critically, that **only** if the register is marked
648 in its **register** table entry as being "active" does the testing
649 proceed further to check if the **predicate** table entry is
652 Note also that this is in direct contrast to branch operations
653 for the storage of comparisions: in these specific circumstances
654 the requirement for there to be an active *register* entry
657 ## Fail-on-First Mode <a name="ffirst-mode"></a>
659 ffirst is a special data-dependent predicate mode. There are two
660 variants: one is for faults: typically for LOAD/STORE operations,
661 which may encounter end of page faults during a series of operations.
662 The other variant is comparisons such as FEQ (or the augmented behaviour
663 of Branch), and any operation that returns a result of zero (whether
664 integer or floating-point). In the FP case, this includes negative-zero.
666 ffirst interacts with zero- and non-zero predication. In non-zeroing
667 mode, masked-out operations are simply excluded from testing (can never
668 fail). However for fail-comparisons (not faults) in zeroing mode, the
669 result will be zero: this *always* "fails", thus on the very first
670 masked-out element ffirst will always terminate.
672 Note that ffirst mode works because the execution order must "appear" to be
673 (in "program order"). An in-order architecture must execute the element
674 operations in sequence, whilst an out-of-order architecture must *commit*
675 the element operations in sequence and cancel speculatively-executed
676 ones (giving the appearance of in-order execution).
678 Note also, that if ffirst mode is needed without predication, a special
679 "always-on" Predicate Table Entry may be constructed by setting
680 inverse-on and using x0 as the predicate register. This
681 will have the effect of creating a mask of all ones, allowing ffirst
684 See [[appendix]] for more details on fail-on-first modes, as well as
687 ## REMAP and SHAPE CSRs <a name="remap" />
689 See optional [[remap]] section.
691 # Instruction Execution Order
693 Simple-V behaves as if it is a hardware-level "macro expansion system",
694 substituting and expanding a single instruction into multiple sequential
695 instructions with contiguous and sequentially-incrementing registers.
696 As such, it does **not** modify - or specify - the behaviour and semantics of
697 the execution order: that may be deduced from the **existing** RV
698 specification in each and every case.
700 So for example if a particular micro-architecture permits out-of-order
701 execution, and it is augmented with Simple-V, then wherever instructions
702 may be out-of-order then so may the "post-expansion" SV ones.
704 If on the other hand there are memory guarantees which specifically
705 prevent and prohibit certain instructions from being re-ordered
706 (such as the Atomicity Axiom, or FENCE constraints), then clearly
707 those constraints **MUST** also be obeyed "post-expansion".
709 It should be absolutely clear that SV is **not** about providing new
710 functionality or changing the existing behaviour of a micro-architetural
711 design, or about changing the RISC-V Specification.
712 It is **purely** about compacting what would otherwise be contiguous
713 instructions that use sequentially-increasing register numbers down
714 to the **one** instruction.
716 # Instructions <a name="instructions" />
718 See [[appendix]] for specific cases where instruction behaviour is
719 augmented. A greatly simplified example is below. Note that this
720 is the ADD implementation, not a separate VADD instruction:
722 [[!inline raw="yes" pages="simple_v_extension/simple_add_example" ]]
724 Note that several things have been left out of this example.
725 See [[appendix]] for additional examples that show how to add
726 support for additional features (twin predication, elwidth,
731 Exceptions may occur at any time, in any given underlying scalar
732 operation. This implies that context-switching (traps) may occur, and
733 operation must be returned to where it left off. That in turn implies
734 that the full state - including the current parallel element being
735 processed - has to be saved and restored. This is what the **STATE**
736 and **PCVBLK** CSRs are for.
738 The implications are that all underlying individual scalar operations
739 "issued" by the parallelisation have to appear to be executed sequentially.
740 The further implications are that if two or more individual element
741 operations are underway, and one with an earlier index causes an exception,
742 it will be necessary for the microarchitecture to **discard** or terminate
743 operations with higher indices. Optimisated microarchitectures could
744 hypothetically store (cache) results, for subsequent replay if appropriate.
746 In short: exception handling **MUST** be precise, in-order, and exactly
747 like Standard RISC-V as far as the instruction execution order is
748 concerned, regardless of whether it is PC, PCVBLK, VL or SUBVL that
749 is currently being incremented.
753 A "HINT" is an operation that has no effect on architectural state,
754 where its use may, by agreed convention, give advance notification
755 to the microarchitecture: branch prediction notification would be
756 a good example. Usually HINTs are where rd=x0.
758 With Simple-V being capable of issuing *parallel* instructions where
759 rd=x0, the space for possible HINTs is expanded considerably. VL
760 could be used to indicate different hints. In addition, if predication
761 is set, the predication register itself could hypothetically be passed
762 in as a *parameter* to the HINT operation.
764 No specific hints are yet defined in Simple-V
766 # Vector Block Format <a name="vliw-format"></a>
768 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:
770 [[!inline raw="yes" pages="simple_v_extension/vblock_format_table" ]]
772 For more details, including the CSRs, see ancillary resource: [[vblock_format]]
774 # Under consideration <a name="issues"></a>