1 # Variable-width Variable-packed SIMD / Simple-V / Parallelism Extension Proposal
3 Key insight: Simple-V is intended as an abstraction layer to provide
4 a consistent "API" to parallelisation of existing *and future* operations.
5 *Actual* internal hardware-level parallelism is *not* required, such
6 that Simple-V may be viewed as providing a "compact" or "consolidated"
7 means of issuing multiple near-identical arithmetic instructions to an
8 instruction queue (FILO), pending execution.
10 *Actual* parallelism, if added independently of Simple-V in the form
11 of Out-of-order restructuring (including parallel ALU lanes) or VLIW
12 implementations, or SIMD, or anything else, would then benefit *if*
13 Simple-V was added on top.
19 This proposal exists so as to be able to satisfy several disparate
20 requirements: power-conscious, area-conscious, and performance-conscious
21 designs all pull an ISA and its implementation in different conflicting
22 directions, as do the specific intended uses for any given implementation.
24 Additionally, the existing P (SIMD) proposal and the V (Vector) proposals,
25 whilst each extremely powerful in their own right and clearly desirable,
28 * Clearly independent in their origins (Cray and AndesStar v3 respectively)
29 so need work to adapt to the RISC-V ethos and paradigm
30 * Are sufficiently large so as to make adoption (and exploration for
31 analysis and review purposes) prohibitively expensive
32 * Both contain partial duplication of pre-existing RISC-V instructions
33 (an undesirable characteristic)
34 * Both have independent and disparate methods for introducing parallelism
35 at the instruction level.
36 * Both require that their respective parallelism paradigm be implemented
37 along-side and integral to their respective functionality *or not at all*.
38 * Both independently have methods for introducing parallelism that
39 could, if separated, benefit
40 *other areas of RISC-V not just DSP or Floating-point respectively*.
42 Therefore it makes a huge amount of sense to have a means and method
43 of introducing instruction parallelism in a flexible way that provides
44 implementors with the option to choose exactly where they wish to offer
45 performance improvements and where they wish to optimise for power
46 and/or area (and if that can be offered even on a per-operation basis that
47 would provide even more flexibility).
49 Additionally it makes sense to *split out* the parallelism inherent within
50 each of P and V, and to see if each of P and V then, in *combination* with
51 a "best-of-both" parallelism extension, could be added on *on top* of
52 this proposal, to topologically provide the exact same functionality of
53 each of P and V. Each of P and V then can focus on providing the best
54 operations possible for their respective target areas, without being
55 hugely concerned about the actual parallelism.
57 Furthermore, an additional goal of this proposal is to reduce the number
58 of opcodes utilised by each of P and V as they currently stand, leveraging
59 existing RISC-V opcodes where possible, and also potentially allowing
60 P and V to make use of Compressed Instructions as a result.
62 **TODO**: propose overflow registers be actually one of the integer regs
63 (flowing to multiple regs).
65 **TODO**: propose "mask" (predication) registers likewise. combination with
66 standard RV instructions and overflow registers extremely powerful, see
69 # Analysis and discussion of Vector vs SIMD
71 There are five combined areas between the two proposals that help with
72 parallelism without over-burdening the ISA with a huge proliferation of
75 * Fixed vs variable parallelism (fixed or variable "M" in SIMD)
76 * Implicit vs fixed instruction bit-width (integral to instruction or not)
77 * Implicit vs explicit type-conversion (compounded on bit-width)
78 * Implicit vs explicit inner loops.
79 * Masks / tagging (selecting/preventing certain indexed elements from execution)
81 The pros and cons of each are discussed and analysed below.
83 ## Fixed vs variable parallelism length
85 In David Patterson and Andrew Waterman's analysis of SIMD and Vector
86 ISAs, the analysis comes out clearly in favour of (effectively) variable
87 length SIMD. As SIMD is a fixed width, typically 4, 8 or in extreme cases
88 16 or 32 simultaneous operations, the setup, teardown and corner-cases of SIMD
89 are extremely burdensome except for applications whose requirements
90 *specifically* match the *precise and exact* depth of the SIMD engine.
92 Thus, SIMD, no matter what width is chosen, is never going to be acceptable
93 for general-purpose computation, and in the context of developing a
94 general-purpose ISA, is never going to satisfy 100 percent of implementors.
96 To explain this further: for increased workloads over time, as the
97 performance requirements increase for new target markets, implementors
98 choose to extend the SIMD width (so as to again avoid mixing parallelism
99 into the instruction issue phases: the primary "simplicity" benefit of
100 SIMD in the first place), with the result that the entire opcode space
101 effectively doubles with each new SIMD width that's added to the ISA.
103 That basically leaves "variable-length vector" as the clear *general-purpose*
104 winner, at least in terms of greatly simplifying the instruction set,
105 reducing the number of instructions required for any given task, and thus
106 reducing power consumption for the same.
108 ## Implicit vs fixed instruction bit-width
110 SIMD again has a severe disadvantage here, over Vector: huge proliferation
111 of specialist instructions that target 8-bit, 16-bit, 32-bit, 64-bit, and
112 have to then have operations *for each and between each*. It gets very
115 The V-Extension on the other hand proposes to set the bit-width of
116 future instructions on a per-register basis, such that subsequent instructions
117 involving that register are *implicitly* of that particular bit-width until
118 otherwise changed or reset.
120 This has some extremely useful properties, without being particularly
121 burdensome to implementations, given that instruction decode already has
122 to direct the operation to a correctly-sized width ALU engine, anyway.
124 Not least: in places where an ISA was previously constrained (due for
125 whatever reason, including limitations of the available operand spcace),
126 implicit bit-width allows the meaning of certain operations to be
127 type-overloaded *without* pollution or alteration of frozen and immutable
128 instructions, in a fully backwards-compatible fashion.
130 ## Implicit and explicit type-conversion
132 The Draft 2.3 V-extension proposal has (deprecated) polymorphism to help
133 deal with over-population of instructions, such that type-casting from
134 integer (and floating point) of various sizes is automatically inferred
135 due to "type tagging" that is set with a special instruction. A register
136 will be *specifically* marked as "16-bit Floating-Point" and, if added
137 to an operand that is specifically tagged as "32-bit Integer" an implicit
138 type-conversion will take place *without* requiring that type-conversion
139 to be explicitly done with its own separate instruction.
141 However, implicit type-conversion is not only quite burdensome to
142 implement (explosion of inferred type-to-type conversion) but also is
143 never really going to be complete. It gets even worse when bit-widths
144 also have to be taken into consideration. Each new type results in
145 an increased O(N^2) conversion space that, as anyone who has examined
146 python's source code (which has built-in polymorphic type-conversion),
147 knows that the task is more complex than it first seems.
149 Overall, type-conversion is generally best to leave to explicit
150 type-conversion instructions, or in definite specific use-cases left to
151 be part of an actual instruction (DSP or FP)
153 ## Zero-overhead loops vs explicit loops
155 The initial Draft P-SIMD Proposal by Chuanhua Chang of Andes Technology
156 contains an extremely interesting feature: zero-overhead loops. This
157 proposal would basically allow an inner loop of instructions to be
158 repeated indefinitely, a fixed number of times.
160 Its specific advantage over explicit loops is that the pipeline in a DSP
161 can potentially be kept completely full *even in an in-order single-issue
162 implementation*. Normally, it requires a superscalar architecture and
163 out-of-order execution capabilities to "pre-process" instructions in
164 order to keep ALU pipelines 100% occupied.
166 By bringing that capability in, this proposal could offer a way to increase
167 pipeline activity even in simpler implementations in the one key area
168 which really matters: the inner loop.
170 However when looking at much more comprehensive schemes
171 "A portable specification of zero-overhead loop control hardware
172 applied to embedded processors" (ZOLC), optimising only the single
173 inner loop seems inadequate, tending to suggest that ZOLC may be
174 better off being proposed as an entirely separate Extension.
176 ## Mask and Tagging (Predication)
178 Tagging (aka Masks aka Predication) is a pseudo-method of implementing
179 simplistic branching in a parallel fashion, by allowing execution on
180 elements of a vector to be switched on or off depending on the results
181 of prior operations in the same array position.
183 The reason for considering this is simple: by *definition* it
184 is not possible to perform individual parallel branches in a SIMD
185 (Single-Instruction, **Multiple**-Data) context. Branches (modifying
186 of the Program Counter) will result in *all* parallel data having
187 a different instruction executed on it: that's just the definition of
188 SIMD, and it is simply unavoidable.
190 So these are the ways in which conditional execution may be implemented:
192 * explicit compare and branch: BNE x, y -> offs would jump offs
193 instructions if x was not equal to y
194 * explicit store of tag condition: CMP x, y -> tagbit
195 * implicit (condition-code) ADD results in a carry, carry bit implicitly
196 (or sometimes explicitly) goes into a "tag" (mask) register
198 The first of these is a "normal" branch method, which is flat-out impossible
199 to parallelise without look-ahead and effectively rewriting instructions.
200 This would defeat the purpose of RISC.
202 The latter two are where parallelism becomes easy to do without complexity:
203 every operation is modified to be "conditionally executed" (in an explicit
204 way directly in the instruction format *or* implicitly).
206 RVV (Vector-Extension) proposes to have *explicit* storing of the compare
207 in a tag/mask register, and to *explicitly* have every vector operation
208 *require* that its operation be "predicated" on the bits within an
209 explicitly-named tag/mask register.
211 SIMD (P-Extension) has not yet published precise documentation on what its
212 schema is to be: there is however verbal indication at the time of writing
215 > The "compare" instructions in the DSP/SIMD ISA proposed by Andes will
216 > be executed using the same compare ALU logic for the base ISA with some
217 > minor modifications to handle smaller data types. The function will not
220 This is an *implicit* form of predication as the base RV ISA does not have
221 condition-codes or predication. By adding a CSR it becomes possible
222 to also tag certain registers as "predicated if referenced as a destination".
225 // in future operations from now on, if r0 is the destination use r5 as
226 // the PREDICATION register
227 SET_IMPLICIT_CSRPREDICATE r0, r5
228 // store the compares in r5 as the PREDICATION register
230 // r0 is used here. ah ha! that means it's predicated using r5!
233 With enough registers (and in RISC-V there are enough registers) some fairly
234 complex predication can be set up and yet still execute without significant
235 stalling, even in a simple non-superscalar architecture.
237 (For details on how Branch Instructions would be retro-fitted to indirectly
238 predicated equivalents, see Appendix)
242 In the above sections the five different ways where parallel instruction
243 execution has closely and loosely inter-related implications for the ISA and
244 for implementors, were outlined. The pluses and minuses came out as
247 * Fixed vs variable parallelism: <b>variable</b>
248 * Implicit (indirect) vs fixed (integral) instruction bit-width: <b>indirect</b>
249 * Implicit vs explicit type-conversion: <b>explicit</b>
250 * Implicit vs explicit inner loops: <b>implicit but best done separately</b>
251 * Tag or no-tag: <b>Complex but highly beneficial</b>
255 * variable-length vectors came out on top because of the high setup, teardown
256 and corner-cases associated with the fixed width of SIMD.
257 * Implicit bit-width helps to extend the ISA to escape from
258 former limitations and restrictions (in a backwards-compatible fashion),
259 whilst also leaving implementors free to simmplify implementations
260 by using actual explicit internal parallelism.
261 * Implicit (zero-overhead) loops provide a means to keep pipelines
262 potentially 100% occupied in a single-issue in-order implementation
263 i.e. *without* requiring a super-scalar or out-of-order architecture,
264 but doing a proper, full job (ZOLC) is an entirely different matter.
266 Constructing a SIMD/Simple-Vector proposal based around four of these five
267 requirements would therefore seem to be a logical thing to do.
271 The instruction format for Simple-V does not actually have *any* compare
272 operations, *any* arithmetic, floating point or memory instructions.
273 Instead it *overloads* pre-existing branch operations into predicated
274 variants, and implicitly overloads arithmetic operations and LOAD/STORE
275 depending on implicit CSR configurations for both vector length and
276 bitwidth. This includes Compressed instructions.
278 * For analysis of RVV see [[v_comparative_analysis]] which begins to
279 outline topologically-equivalent mappings of instructions
280 * Also see Appendix "Retro-fitting Predication into branch-explicit ISA"
281 for format of Branch opcodes.
283 **TODO**: *analyse and decide whether the implicit nature of predication
284 as proposed is or is not a lot of hassle, and if explicit prefixes are
285 a better idea instead. Parallelism therefore effectively may end up
286 as always being 64-bit opcodes (32 for the prefix, 32 for the instruction)
287 with some opportunities for to use Compressed bringing it down to 48.
288 Also to consider is whether one or both of the last two remaining Compressed
289 instruction codes in Quadrant 1 could be used as a parallelism prefix,
290 bringing parallelised opcodes down to 32-bit and having the benefit of
293 ## Branch Instruction:
296 31 | 30 .. 25 |24 ... 20 | 19 15 | 14 12 | 11 .. 8 | 7 | 6 ... 0 |
297 imm[12] | imm[10:5]| rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
298 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
299 I/F | reserved | src2 | src1 | BPR | predicate rs3 || BRANCH |
300 0 | reserved | src2 | src1 | 000 | predicate rs3 || BEQ |
301 0 | reserved | src2 | src1 | 001 | predicate rs3 || BNE |
302 0 | reserved | src2 | src1 | 010 | predicate rs3 || rsvd |
303 0 | reserved | src2 | src1 | 011 | predicate rs3 || rsvd |
304 0 | reserved | src2 | src1 | 100 | predicate rs3 || BLE |
305 0 | reserved | src2 | src1 | 101 | predicate rs3 || BGE |
306 0 | reserved | src2 | src1 | 110 | predicate rs3 || BLTU |
307 0 | reserved | src2 | src1 | 111 | predicate rs3 || BGEU |
308 1 | reserved | src2 | src1 | 000 | predicate rs3 || FEQ |
309 1 | reserved | src2 | src1 | 001 | predicate rs3 || FNE |
310 1 | reserved | src2 | src1 | 010 | predicate rs3 || rsvd |
311 1 | reserved | src2 | src1 | 011 | predicate rs3 || rsvd |
312 1 | reserved | src2 | src1 | 100 | predicate rs3 || FLT |
313 1 | reserved | src2 | src1 | 101 | predicate rs3 || FLE |
314 1 | reserved | src2 | src1 | 110 | predicate rs3 || rsvd |
315 1 | reserved | src2 | src1 | 111 | predicate rs3 || rsvd |
318 In Hwacha EECS-2015-262 Section 6.7.2 the following pseudocode is given
319 for predicated compare operations of function "cmp":
321 for (int i=0; i<vl; ++i)
323 preg[pd][i] = cmp(s1 ? vreg[rs1][i] : sreg[rs1],
324 s2 ? vreg[rs2][i] : sreg[rs2]);
326 With associated predication, vector-length adjustments and so on,
327 and temporarily ignoring bitwidth (which makes the comparisons more
328 complex), this becomes:
330 if I/F == INT: # integer type cmp
331 pred_enabled = int_pred_enabled # TODO: exception if not set!
332 preg = int_pred_reg[rd]
334 pred_enabled = fp_pred_enabled # TODO: exception if not set!
335 preg = fp_pred_reg[rd]
337 s1 = CSRvectorlen[src1] > 1;
338 s2 = CSRvectorlen[src2] > 1;
339 for (int i=0; i<vl; ++i)
340 preg[rs3][i] = cmp(s1 ? reg[src1+i] : reg[src1],
341 s2 ? reg[src2+i] : reg[src2]);
345 * Predicated SIMD comparisons would break src1 and src2 further down
346 into bitwidth-sized chunks (see Appendix "Bitwidth Virtual Register
347 Reordering") setting Vector-Length * (number of SIMD elements) bits
348 in Predicate Register rs3 as opposed to just Vector-Length bits.
349 * Predicated Branches do not actually have an adjustment to the Program
350 Counter, so all of bits 25 through 30 in every case are not needed.
351 * There are plenty of reserved opcodes for which bits 25 through 30 could
352 be put to good use if there is a suitable use-case.
353 * FEQ and FNE (and BEQ and BNE) are included in order to save one
354 instruction having to invert the resultant predicate bitfield.
355 FLT and FLE may be inverted to FGT and FGE if needed by swapping
356 src1 and src2 (likewise the integer counterparts).
358 ## Compressed Branch Instruction:
361 15..13 | 12...10 | 9..7 | 6..5 | 4..2 | 1..0 | name |
362 funct3 | imm | rs10 | imm | | op | |
363 3 | 3 | 3 | 2 | 3 | 2 | |
364 C.BPR | pred rs3 | src1 | I/F B | src2 | C1 | |
365 110 | pred rs3 | src1 | I/F 0 | src2 | C1 | P.EQ |
366 111 | pred rs3 | src1 | I/F 0 | src2 | C1 | P.NE |
367 110 | pred rs3 | src1 | I/F 1 | src2 | C1 | P.LT |
368 111 | pred rs3 | src1 | I/F 1 | src2 | C1 | P.LE |
373 * Bits 5 13 14 and 15 make up the comparator type
374 * In both floating-point and integer cases there are four predication
375 comparators: EQ/NEQ/LT/LE (with GT and GE being synthesised by inverting
378 ## LOAD / STORE Instructions
380 For full analysis of topological adaptation of RVV LOAD/STORE
381 see [[v_comparative_analysis]]. All three types (LD, LD.S and LD.X)
382 may be implicitly overloaded into the one base RV LOAD instruction.
387 31 | 30 | 29 25 | 24 20 | 19 15 | 14 12 | 11 7 | 6 0 |
388 imm[11:0] |||| rs1 | funct3 | rd | opcode |
389 1 | 1 | 5 | 5 | 5 | 3 | 5 | 7 |
390 ? | s | rs2 | imm[4:0] | base | width | dest | LOAD |
393 The exact same corresponding adaptation is also carried out on the single,
394 double and quad precision floating-point LOAD-FP and STORE-FP operations,
395 which fit the exact same instruction format. Thus all three types
396 (unit, stride and indexed) may be fitted into FLW, FLD and FLQ,
397 as well as FSW, FSD and FSQ.
401 * LOAD remains functionally (topologically) identical to RVV LOAD
402 (for both integer and floating-point variants).
403 * Predication CSR-marking register is not explicitly shown in instruction, it's
404 implicit based on the CSR predicate state for the rd (destination) register
405 * rs2, the source, may *also be marked as a vector*, which implicitly
406 is taken to indicate "Indexed Load" (LD.X)
407 * Bit 30 indicates "element stride" or "constant-stride" (LD or LD.S)
408 * Bit 31 is reserved (ideas under consideration: auto-increment)
409 * **TODO**: include CSR SIMD bitwidth in the pseudo-code below.
410 * **TODO**: clarify where width maps to elsize
412 Pseudo-code (excludes CSR SIMD bitwidth):
414 if (unit-strided) stride = elsize;
415 else stride = areg[as2]; // constant-strided
417 pred_enabled = int_pred_enabled
418 preg = int_pred_reg[rd]
420 for (int i=0; i<vl; ++i)
421 if (preg_enabled[rd] && [!]preg[i])
422 for (int j=0; j<seglen+1; j++)
424 if CSRvectorised[rs2])
427 offs = i*(seglen+1)*stride;
428 vreg[rd+j][i] = mem[sreg[base] + offs + j*stride];
431 Taking CSR (SIMD) bitwidth into account involves using the vector
432 length and register encoding according to the "Bitwidth Virtual Register
433 Reordering" scheme shown in the Appendix (see function "regoffs").
435 A similar instruction exists for STORE, with identical topological
436 translation of all features. **TODO**
438 ## Compressed LOAD / STORE Instructions
440 Compressed LOAD and STORE are of the same format, where bits 2-4 are
441 a src register instead of dest:
444 15 13 | 12 10 | 9 7 | 6 5 | 4 2 | 1 0 |
445 funct3 | imm | rs10 | imm | rd0 | op |
446 3 | 3 | 3 | 2 | 3 | 2 |
447 C.LW | offset[5:3] | base | offset[2|6] | dest | C0 |
450 Unfortunately it is not possible to fit the full functionality
451 of vectorised LOAD / STORE into C.LD / C.ST: the "X" variants (Indexed)
452 require another operand (rs2) in addition to the operand width
453 (which is also missing), offset, base, and src/dest.
455 However a close approximation may be achieved by taking the top bit
456 of the offset in each of the five types of LD (and ST), reducing the
457 offset to 4 bits and utilising the 5th bit to indicate whether "stride"
458 is to be enabled. In this way it is at least possible to introduce
461 (**TODO**: *assess whether the loss of one bit from offset is worth having
462 "stride" capability.*)
464 We also assume (including for the "stride" variant) that the "width"
465 parameter, which is missing, is derived and implicit, just as it is
466 with the standard Compressed LOAD/STORE instructions. For C.LW, C.LD
467 and C.LQ, the width is implicitly 4, 8 and 16 respectively, whilst for
468 C.FLW and C.FLD the width is implicitly 4 and 8 respectively.
470 Interestingly we note that the Vectorised Simple-V variant of
471 LOAD/STORE (Compressed and otherwise), due to it effectively using the
472 standard register file(s), is the direct functional equivalent of
473 standard load-multiple and store-multiple instructions found in other
476 In Section 12.3 riscv-isa manual V2.3-draft it is noted the comments on
477 page 76, "For virtual memory systems some data accesses could be resident
478 in physical memory and some not". The interesting question then arises:
479 how does RVV deal with the exact same scenario?
481 # Note on implementation of parallelism
483 One extremely important aspect of this proposal is to respect and support
484 implementors desire to focus on power, area or performance. In that regard,
485 it is proposed that implementors be free to choose whether to implement
486 the Vector (or variable-width SIMD) parallelism as sequential operations
487 with a single ALU, fully parallel (if practical) with multiple ALUs, or
488 a hybrid combination of both.
490 In Broadcom's Videocore-IV, they chose hybrid, and called it "Virtual
491 Parallelism". They achieve a 16-way SIMD at an **instruction** level
492 by providing a combination of a 4-way parallel ALU *and* an externally
493 transparent loop that feeds 4 sequential sets of data into each of the
496 Also in the same core, it is worth noting that particularly uncommon
497 but essential operations (Reciprocal-Square-Root for example) are
498 *not* part of the 4-way parallel ALU but instead have a *single* ALU.
499 Under the proposed Vector (varible-width SIMD) implementors would
500 be free to do precisely that: i.e. free to choose *on a per operation
501 basis* whether and how much "Virtual Parallelism" to deploy.
503 It is absolutely critical to note that it is proposed that such choices MUST
504 be **entirely transparent** to the end-user and the compiler. Whilst
505 a Vector (varible-width SIM) may not precisely match the width of the
506 parallelism within the implementation, the end-user **should not care**
507 and in this way the performance benefits are gained but the ISA remains
508 straightforward. All that happens at the end of an instruction run is: some
509 parallel units (if there are any) would remain offline, completely
510 transparently to the ISA, the program, and the compiler.
512 The "SIMD considered harmful" trap of having huge complexity and extra
513 instructions to deal with corner-cases is thus avoided, and implementors
514 get to choose precisely where to focus and target the benefits of their
515 implementation efforts, without "extra baggage".
517 # CSRs <a name="csrs"></a>
519 There are a number of CSRs needed, which are used at the instruction
520 decode phase to re-interpret standard RV opcodes (a practice that has
521 precedent in the setting of MISA to enable / disable extensions).
523 * Integer Register N is Vector of length M: r(N) -> r(N..N+M-1)
524 * Integer Register N is of implicit bitwidth M (M=default,8,16,32,64)
525 * Floating-point Register N is Vector of length M: r(N) -> r(N..N+M-1)
526 * Floating-point Register N is of implicit bitwidth M (M=default,8,16,32,64)
527 * Integer Register N is a Predication Register (note: a key-value store)
528 * Vector Length CSR (VSETVL, VGETVL)
532 * for the purposes of LOAD / STORE, Integer Registers which are
533 marked as a Vector will result in a Vector LOAD / STORE.
534 * Vector Lengths are *not* the same as vsetl but are an integral part
536 * Actual vector length is *multipled* by how many blocks of length
537 "bitwidth" may fit into an XLEN-sized register file.
538 * Predication is a key-value store due to the implicit referencing,
539 as opposed to having the predicate register explicitly in the instruction.
543 The Predication CSR is a key-value store indicating whether, if a given
544 destination register (integer or floating-point) is referred to in an
545 instruction, it is to be predicated. The first entry is whether predication
546 is enabled. The second entry is whether the register index refers to a
547 floating-point or an integer register. The third entry is the index
548 of that register which is to be predicated (if referred to). The fourth entry
549 is the integer register that is treated as a bitfield, indexable by the
550 vector element index.
552 | RegNo | 6 | 5 | (4..0) | (4..0) |
553 | ----- | - | - | ------- | ------- |
554 | r0 | pren0 | i/f | regidx | predidx |
555 | r1 | pren1 | i/f | regidx | predidx |
556 | .. | pren.. | i/f | regidx | predidx |
557 | r15 | pren15 | i/f | regidx | predidx |
559 The Predication CSR Table is a key-value store, so implementation-wise
560 it will be faster to turn the table around (maintain topologically
564 int_pred_enabled[32];
565 for (i = 0; i < 16; i++)
567 idx = CSRpred[i].regidx
568 predidx = CSRpred[i].predidx
569 if CSRpred[i].type == 0: # integer
570 int_pred_enabled[idx] = 1
571 int_pred_reg[idx] = predidx
573 fp_pred_enabled[idx] = 1
574 fp_pred_reg[idx] = predidx
576 So when an operation is to be predicated, it is the internal state that
577 is used. In Section 6.4.2 of Hwacha's Manual (EECS-2015-262) the following
578 pseudo-code for operations is given, where p is the explicit (direct)
579 reference to the predication register to be used:
581 for (int i=0; i<vl; ++i)
583 (d ? vreg[rd][i] : sreg[rd]) =
584 iop(s1 ? vreg[rs1][i] : sreg[rs1],
585 s2 ? vreg[rs2][i] : sreg[rs2]); // for insts with 2 inputs
587 This instead becomes an *indirect* reference using the *internal* state
588 table generated from the Predication CSR key-value store:
591 pred_enabled = int_pred_enabled
592 preg = int_pred_reg[rd]
594 pred_enabled = fp_pred_enabled
595 preg = fp_pred_reg[rd]
597 for (int i=0; i<vl; ++i)
598 if (preg_enabled[rd] && [!]preg[i])
599 (d ? vreg[rd][i] : sreg[rd]) =
600 iop(s1 ? vreg[rs1][i] : sreg[rs1],
601 s2 ? vreg[rs2][i] : sreg[rs2]); // for insts with 2 inputs
605 MAXVECTORDEPTH is the same concept as MVL in RVV. However in Simple-V,
606 given that its primary (base, unextended) purpose is for 3D, Video and
607 other purposes (not requiring supercomputing capability), it makes sense
608 to limit MAXVECTORDEPTH to the regfile bitwidth (32 for RV32, 64 for RV64
611 The reason for setting this limit is so that predication registers, when
612 marked as such, may fit into a single register as opposed to fanning out
613 over several registers. This keeps the implementation a little simpler.
614 Note that RVV on top of Simple-V may choose to over-ride this decision.
616 ## Vector-length CSRs
618 Vector lengths are interpreted as meaning "any instruction referring to
619 r(N) generates implicit identical instructions referring to registers
620 r(N+M-1) where M is the Vector Length". Vector Lengths may be set to
621 use up to 16 registers in the register file.
623 One separate CSR table is needed for each of the integer and floating-point
633 An array of 32 4-bit CSRs is needed (4 bits per register) to indicate
634 whether a register was, if referred to in any standard instructions,
635 implicitly to be treated as a vector. A vector length of 1 indicates
636 that it is to be treated as a scalar. Vector lengths of 0 are reserved.
638 Internally, implementations may choose to use the non-zero vector length
639 to set a bit-field per register, to be used in the instruction decode phase.
640 In this way any standard (current or future) operation involving
641 register operands may detect if the operation is to be vector-vector,
642 vector-scalar or scalar-scalar (standard) simply through a single
645 Note that when using the "vsetl rs1, rs2" instruction (caveat: when the
646 bitwidth is specifically not set) it becomes:
648 CSRvlength = MIN(MIN(CSRvectorlen[rs1], MAXVECTORDEPTH), rs2)
650 This is in contrast to RVV:
652 CSRvlength = MIN(MIN(rs1, MAXVECTORDEPTH), rs2)
654 ## Element (SIMD) bitwidth CSRs
656 Element bitwidths may be specified with a per-register CSR, and indicate
657 how a register (integer or floating-point) is to be subdivided.
666 vew may be one of the following (giving a table "bytestable", used below):
679 Extending this table (with extra bits) is covered in the section
680 "Implementing RVV on top of Simple-V".
682 Note that when using the "vsetl rs1, rs2" instruction, taking bitwidth
683 into account, it becomes:
685 vew = CSRbitwidth[rs1]
687 bytesperreg = (XLEN/8) # or FLEN as appropriate
689 bytesperreg = bytestable[vew] # 1 2 4 8 16
690 simdmult = (XLEN/8) / bytesperreg # or FLEN as appropriate
691 vlen = CSRvectorlen[rs1] * simdmult
692 CSRvlength = MIN(MIN(vlen, MAXVECTORDEPTH), rs2)
694 The reason for multiplying the vector length by the number of SIMD elements
695 (in each individual register) is so that each SIMD element may optionally be
698 An example of how to subdivide the register file when bitwidth != default
699 is given in the section "Bitwidth Virtual Register Reordering".
703 > What does an ADD of two different-sized vectors do in simple-V?
705 * if the two source operands are not the same, throw an exception.
706 * if the destination operand is also a vector, and the source is longer
707 than the destination, throw an exception.
709 > And what about instructions like JALR?
710 > What does jumping to a vector do?
712 * Throw an exception. Whether that actually results in spawning threads
713 as part of the trap-handling remains to be seen.
715 # Comparison of "Traditional" SIMD, Alt-RVP, Simple-V and RVV Proposals <a name="parallelism_comparisons"></a>
717 This section compares the various parallelism proposals as they stand,
718 including traditional SIMD, in terms of features, ease of implementation,
719 complexity, flexibility, and die area.
723 Primary benefit of Alt-RVP is the simplicity with which parallelism
724 may be introduced (effective multiplication of regfiles and associated ALUs).
726 * plus: the simplicity of the lanes (combined with the regularity of
727 allocating identical opcodes multiple independent registers) meaning
728 that SRAM or 2R1W can be used for entire regfile (potentially).
729 * minus: a more complex instruction set where the parallelism is much
730 more explicitly directly specified in the instruction and
731 * minus: if you *don't* have an explicit instruction (opcode) and you
732 need one, the only place it can be added is... in the vector unit and
733 * minus: opcode functions (and associated ALUs) duplicated in Alt-RVP are
734 not useable or accessible in other Extensions.
735 * plus-and-minus: Lanes may be utilised for high-speed context-switching
736 but with the down-side that they're an all-or-nothing part of the Extension.
737 No Alt-RVP: no fast register-bank switching.
738 * plus: Lane-switching would mean that complex operations not suited to
739 parallelisation can be carried out, followed by further parallel Lane-based
740 work, without moving register contents down to memory (and back)
741 * minus: Access to registers across multiple lanes is challenging. "Solution"
742 is to drop data into memory and immediately back in again (like MMX).
746 Primary benefit of Simple-V is the OO abstraction of parallel principles
747 from actual (internal) parallel hardware. It's an API in effect that's
748 designed to be slotted in to an existing implementation (just after
749 instruction decode) with minimum disruption and effort.
751 * minus: the complexity of having to use register renames, OoO, VLIW,
752 register file cacheing, all of which has been done before but is a
754 * plus: transparent re-use of existing opcodes as-is just indirectly
755 saying "this register's now a vector" which
756 * plus: means that future instructions also get to be inherently
757 parallelised because there's no "separate vector opcodes"
758 * plus: Compressed instructions may also be (indirectly) parallelised
759 * minus: the indirect nature of Simple-V means that setup (setting
760 a CSR register to indicate vector length, a separate one to indicate
761 that it is a predicate register and so on) means a little more setup
762 time than Alt-RVP or RVV's "direct and within the (longer) instruction"
764 * plus: shared register file meaning that, like Alt-RVP, complex
765 operations not suited to parallelisation may be carried out interleaved
766 between parallelised instructions *without* requiring data to be dropped
767 down to memory and back (into a separate vectorised register engine).
768 * plus-and-maybe-minus: re-use of integer and floating-point 32-wide register
769 files means that huge parallel workloads would use up considerable
770 chunks of the register file. However in the case of RV64 and 32-bit
771 operations, that effectively means 64 slots are available for parallel
773 * plus: inherent parallelism (actual parallel ALUs) doesn't actually need to
774 be added, yet the instruction opcodes remain unchanged (and still appear
775 to be parallel). consistent "API" regardless of actual internal parallelism:
776 even an in-order single-issue implementation with a single ALU would still
777 appear to have parallel vectoristion.
778 * hard-to-judge: if actual inherent underlying ALU parallelism is added it's
779 hard to say if there would be pluses or minuses (on die area). At worse it
780 would be "no worse" than existing register renaming, OoO, VLIW and register
781 file cacheing schemes.
783 ## RVV (as it stands, Draft 0.4 Section 17, RISC-V ISA V2.3-Draft)
785 RVV is extremely well-designed and has some amazing features, including
786 2D reorganisation of memory through LOAD/STORE "strides".
788 * plus: regular predictable workload means that implementations may
789 streamline effects on L1/L2 Cache.
790 * plus: regular and clear parallel workload also means that lanes
791 (similar to Alt-RVP) may be used as an implementation detail,
792 using either SRAM or 2R1W registers.
793 * plus: separate engine with no impact on the rest of an implementation
794 * minus: separate *complex* engine with no RTL (ALUs, Pipeline stages) reuse
796 * minus: no ISA abstraction or re-use either: additions to other Extensions
797 do not gain parallelism, resulting in prolific duplication of functionality
798 inside RVV *and out*.
799 * minus: when operations require a different approach (scalar operations
800 using the standard integer or FP regfile) an entire vector must be
801 transferred out to memory, into standard regfiles, then back to memory,
802 then back to the vector unit, this to occur potentially multiple times.
803 * minus: will never fit into Compressed instruction space (as-is. May
804 be able to do so if "indirect" features of Simple-V are partially adopted).
805 * plus-and-slight-minus: extended variants may address up to 256
806 vectorised registers (requires 48/64-bit opcodes to do it).
807 * minus-and-partial-plus: separate engine plus complexity increases
808 implementation time and die area, meaning that adoption is likely only
809 to be in high-performance specialist supercomputing (where it will
810 be absolutely superb).
814 The only really good things about SIMD are how easy it is to implement and
815 get good performance. Unfortunately that makes it quite seductive...
817 * plus: really straightforward, ALU basically does several packed operations
818 at once. Parallelism is inherent at the ALU, making the addition of
819 SIMD-style parallelism an easy decision that has zero significant impact
820 on the rest of any given architectural design and layout.
821 * plus (continuation): SIMD in simple in-order single-issue designs can
822 therefore result in superb throughput, easily achieved even with a very
823 simple execution model.
824 * minus: ridiculously complex setup and corner-cases that disproportionately
825 increase instruction count on what would otherwise be a "simple loop",
826 should the number of elements in an array not happen to exactly match
827 the SIMD group width.
828 * minus: getting data usefully out of registers (if separate regfiles
829 are used) means outputting to memory and back.
830 * minus: quite a lot of supplementary instructions for bit-level manipulation
831 are needed in order to efficiently extract (or prepare) SIMD operands.
832 * minus: MASSIVE proliferation of ISA both in terms of opcodes in one
833 dimension and parallelism (width): an at least O(N^2) and quite probably
834 O(N^3) ISA proliferation that often results in several thousand
835 separate instructions. all requiring separate and distinct corner-case
837 * minus: EVEN BIGGER proliferation of SIMD ISA if the functionality of
838 8, 16, 32 or 64-bit reordering is built-in to the SIMD instruction.
839 For example: add (high|low) 16-bits of r1 to (low|high) of r2 requires
840 four separate and distinct instructions: one for (r1:low r2:high),
841 one for (r1:high r2:low), one for (r1:high r2:high) and one for
842 (r1:low r2:low) *per function*.
843 * minus: EVEN BIGGER proliferation of SIMD ISA if there is a mismatch
844 between operand and result bit-widths. In combination with high/low
845 proliferation the situation is made even worse.
846 * minor-saving-grace: some implementations *may* have predication masks
847 that allow control over individual elements within the SIMD block.
849 # Comparison *to* Traditional SIMD: Alt-RVP, Simple-V and RVV Proposals <a name="simd_comparison"></a>
851 This section compares the various parallelism proposals as they stand,
852 *against* traditional SIMD as opposed to *alongside* SIMD. In other words,
853 the question is asked "How can each of the proposals effectively implement
854 (or replace) SIMD, and how effective would they be"?
858 * Alt-RVP would not actually replace SIMD but would augment it: just as with
859 a SIMD architecture where the ALU becomes responsible for the parallelism,
860 Alt-RVP ALUs would likewise be so responsible... with *additional*
861 (lane-based) parallelism on top.
862 * Thus at least some of the downsides of SIMD ISA O(N^3) proliferation by
863 at least one dimension are avoided (architectural upgrades introducing
864 128-bit then 256-bit then 512-bit variants of the exact same 64-bit
866 * Thus, unfortunately, Alt-RVP would suffer the same inherent proliferation
867 of instructions as SIMD, albeit not quite as badly (due to Lanes).
868 * In the same discussion for Alt-RVP, an additional proposal was made to
869 be able to subdivide the bits of each register lane (columns) down into
870 arbitrary bit-lengths (RGB 565 for example).
871 * A recommendation was given instead to make the subdivisions down to 32-bit,
872 16-bit or even 8-bit, effectively dividing the registerfile into
873 Lane0(H), Lane0(L), Lane1(H) ... LaneN(L) or further. If inter-lane
874 "swapping" instructions were then introduced, some of the disadvantages
875 of SIMD could be mitigated.
879 * RVV is designed to replace SIMD with a better paradigm: arbitrary-length
881 * However whilst SIMD is usually designed for single-issue in-order simple
882 DSPs with a focus on Multimedia (Audio, Video and Image processing),
883 RVV's primary focus appears to be on Supercomputing: optimisation of
884 mathematical operations that fit into the OpenCL space.
885 * Adding functions (operations) that would normally fit (in parallel)
886 into a SIMD instruction requires an equivalent to be added to the
887 RVV Extension, if one does not exist. Given the specialist nature of
888 some SIMD instructions (8-bit or 16-bit saturated or halving add),
889 this possibility seems extremely unlikely to occur, even if the
890 implementation overhead of RVV were acceptable (compared to
891 normal SIMD/DSP-style single-issue in-order simplicity).
895 * Simple-V borrows hugely from RVV as it is intended to be easy to
896 topologically transplant every single instruction from RVV (as
897 designed) into Simple-V equivalents, with *zero loss of functionality
899 * With the "parallelism" abstracted out, a hypothetical SIMD-less "DSP"
900 Extension which contained the basic primitives (non-parallelised
901 8, 16 or 32-bit SIMD operations) inherently *become* parallel,
903 * Additionally, standard operations (ADD, MUL) that would normally have
904 to have special SIMD-parallel opcodes added need no longer have *any*
905 of the length-dependent variants (2of 32-bit ADDs in a 64-bit register,
906 4of 32-bit ADDs in a 128-bit register) because Simple-V takes the
907 *standard* RV opcodes (present and future) and automatically parallelises
909 * By inheriting the RVV feature of arbitrary vector-length, then just as
910 with RVV the corner-cases and ISA proliferation of SIMD is avoided.
911 * Whilst not entirely finalised, registers are expected to be
912 capable of being subdivided down to an implementor-chosen bitwidth
913 in the underlying hardware (r1 becomes r1[31..24] r1[23..16] r1[15..8]
914 and r1[7..0], or just r1[31..16] r1[15..0]) where implementors can
915 choose to have separate independent 8-bit ALUs or dual-SIMD 16-bit
916 ALUs that perform twin 8-bit operations as they see fit, or anything
917 else including no subdivisions at all.
918 * Even though implementors have that choice even to have full 64-bit
919 (with RV64) SIMD, they *must* provide predication that transparently
920 switches off appropriate units on the last loop, thus neatly fitting
921 underlying SIMD ALU implementations *into* the arbitrary vector-length
922 RVV paradigm, keeping the uniform consistent API that is a key strategic
924 * With Simple-V fitting into the standard register files, certain classes
925 of SIMD operations such as High/Low arithmetic (r1[31..16] + r2[15..0])
926 can be done by applying *Parallelised* Bit-manipulation operations
927 followed by parallelised *straight* versions of element-to-element
928 arithmetic operations, even if the bit-manipulation operations require
929 changing the bitwidth of the "vectors" to do so. Predication can
930 be utilised to skip high words (or low words) in source or destination.
931 * In essence, the key downside of SIMD - massive duplication of
932 identical functions over time as an architecture evolves from 32-bit
933 wide SIMD all the way up to 512-bit, is avoided with Simple-V, through
934 vector-style parallelism being dropped on top of 8-bit or 16-bit
935 operations, all the while keeping a consistent ISA-level "API" irrespective
936 of implementor design choices (or indeed actual implementations).
938 # Impementing V on top of Simple-V
940 * Number of Offset CSRs extends from 2
941 * Extra register file: vector-file
942 * Setup of Vector length and bitwidth CSRs now can specify vector-file
943 as well as integer or float file.
944 * Extend CSR tables (bitwidth) with extra bits
947 # Implementing P (renamed to DSP) on top of Simple-V
949 * Implementors indicate chosen bitwidth support in Vector-bitwidth CSR
950 (caveat: anything not specified drops through to software-emulation / traps)
955 ## V-Extension to Simple-V Comparative Analysis
957 This section has been moved to its own page [[v_comparative_analysis]]
961 This section has been moved to its own page [[p_comparative_analysis]]
963 ## Example of vector / vector, vector / scalar, scalar / scalar => vector add
965 register CSRvectorlen[XLEN][4]; # not quite decided yet about this one...
966 register CSRpredicate[XLEN][4]; # 2^4 is max vector length
967 register CSRreg_is_vectorised[XLEN]; # just for fun support scalars as well
968 register x[32][XLEN];
970 function op_add(rd, rs1, rs2, predr)
972 /* note that this is ADD, not PADD */
973 int i, id, irs1, irs2;
974 # checks CSRvectorlen[rd] == CSRvectorlen[rs] etc. ignored
975 # also destination makes no sense as a scalar but what the hell...
976 for (i = 0, id=0, irs1=0, irs2=0; i<CSRvectorlen[rd]; i++)
977 if (CSRpredicate[predr][i]) # i *think* this is right...
978 x[rd+id] <= x[rs1+irs1] + x[rs2+irs2];
979 # now increment the idxs
980 if (CSRreg_is_vectorised[rd]) # bitfield check rd, scalar/vector?
982 if (CSRreg_is_vectorised[rs1]) # bitfield check rs1, scalar/vector?
984 if (CSRreg_is_vectorised[rs2]) # bitfield check rs2, scalar/vector?
988 ## Retro-fitting Predication into branch-explicit ISA <a name="predication_retrofit"></a>
990 One of the goals of this parallelism proposal is to avoid instruction
991 duplication. However, with the base ISA having been designed explictly
992 to *avoid* condition-codes entirely, shoe-horning predication into it
993 bcomes quite challenging.
995 However what if all branch instructions, if referencing a vectorised
996 register, were instead given *completely new analogous meanings* that
997 resulted in a parallel bit-wise predication register being set? This
998 would have to be done for both C.BEQZ and C.BNEZ, as well as BEQ, BNE,
1001 We might imagine that FEQ, FLT and FLT would also need to be converted,
1002 however these are effectively *already* in the precise form needed and
1003 do not need to be converted *at all*! The difference is that FEQ, FLT
1004 and FLE *specifically* write a 1 to an integer register if the condition
1005 holds, and 0 if not. All that needs to be done here is to say, "if
1006 the integer register is tagged with a bit that says it is a predication
1007 register, the **bit** in the integer register is set based on the
1008 current vector index" instead.
1010 There is, in the standard Conditional Branch instruction, more than
1011 adequate space to interpret it in a similar fashion:
1014 31 |30 ..... 25 |24 ... 20 | 19 ... 15 | 14 ...... 12 | 11 ....... 8 | 7 | 6 ....... 0 |
1015 imm[12] | imm[10:5] | rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
1016 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
1017 offset[12,10:5] || src2 | src1 | BEQ | offset[11,4:1] || BRANCH |
1023 31 | 30 .. 25 |24 ... 20 | 19 15 | 14 12 | 11 .. 8 | 7 | 6 ... 0 |
1024 imm[12] | imm[10:5]| rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
1025 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
1026 reserved || src2 | src1 | BEQ | predicate rs3 || BRANCH |
1029 Similarly the C.BEQZ and C.BNEZ instruction format may be retro-fitted,
1030 with the interesting side-effect that there is space within what is presently
1031 the "immediate offset" field to reinterpret that to add in not only a bit
1032 field to distinguish between floating-point compare and integer compare,
1033 not only to add in a second source register, but also use some of the bits as
1034 a predication target as well.
1037 15 ...... 13 | 12 ........... 10 | 9..... 7 | 6 ................. 2 | 1 .. 0 |
1038 funct3 | imm | rs10 | imm | op |
1040 C.BEQZ | offset[8,4:3] | src | offset[7:6,2:1,5] | C1 |
1043 Now uses the CS format:
1046 15 ...... 13 | 12 ........... 10 | 9..... 7 | 6 .. 5 | 4......... 2 | 1 .. 0 |
1047 funct3 | imm | rs10 | imm | | op |
1048 3 | 3 | 3 | 2 | 3 | 2 |
1049 C.BEQZ | predicate rs3 | src1 | I/F B | src2 | C1 |
1052 Bit 6 would be decoded as "operation refers to Integer or Float" including
1053 interpreting src1 and src2 accordingly as outlined in Table 12.2 of the
1054 "C" Standard, version 2.0,
1055 whilst Bit 5 would allow the operation to be extended, in combination with
1056 funct3 = 110 or 111: a combination of four distinct (predicated) comparison
1057 operators. In both floating-point and integer cases those could be
1058 EQ/NEQ/LT/LE (with GT and GE being synthesised by inverting src1 and src2).
1060 ## Register reordering <a name="register_reordering"></a>
1079 May not be an actual CSR: may be generated from Vector Length CSR:
1080 single-bit is less burdensome on instruction decode phase.
1082 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
1083 | - | - | - | - | - | - | - | - |
1084 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
1086 ### Vector Length CSR
1088 | Reg Num | (3..0) |
1099 ### Virtual Register Reordering
1101 This example assumes the above Vector Length CSR table
1103 | Reg Num | Bits (0) | Bits (1) | Bits (2) |
1104 | ------- | -------- | -------- | -------- |
1105 | r0 | (32..0) | (32..0) |
1108 | r4 | (32..0) | (32..0) | (32..0) |
1111 ### Bitwidth Virtual Register Reordering
1113 This example goes a little further and illustrates the effect that a
1114 bitwidth CSR has been set on a register. Preconditions:
1117 * CSRintbitwidth[2] = 010 # integer r2 is 16-bit
1118 * CSRintvlength[2] = 3 # integer r2 is a vector of length 3
1119 * vsetl rs1, 5 # set the vector length to 5
1121 This is interpreted as follows:
1123 * Given that the context is RV32, ELEN=32.
1124 * With ELEN=32 and bitwidth=16, the number of SIMD elements is 2
1125 * Therefore the actual vector length is up to *six* elements
1126 * However vsetl sets a length 5 therefore the last "element" is skipped
1128 So when using an operation that uses r2 as a source (or destination)
1129 the operation is carried out as follows:
1131 * 16-bit operation on r2(15..0) - vector element index 0
1132 * 16-bit operation on r2(31..16) - vector element index 1
1133 * 16-bit operation on r3(15..0) - vector element index 2
1134 * 16-bit operation on r3(31..16) - vector element index 3
1135 * 16-bit operation on r4(15..0) - vector element index 4
1136 * 16-bit operation on r4(31..16) **NOT** carried out due to length being 5
1138 Predication has been left out of the above example for simplicity, however
1139 predication is ANDed with the latter stages (vsetl not equal to maximum
1142 Note also that it is entirely an implementor's choice as to whether to have
1143 actual separate ALUs down to the minimum bitwidth, or whether to have something
1144 more akin to traditional SIMD (at any level of subdivision: 8-bit SIMD
1145 operations carried out 32-bits at a time is perfectly acceptable, as is
1146 8-bit SIMD operations carried out 16-bits at a time requiring two ALUs).
1147 Regardless of the internal parallelism choice, *predication must
1148 still be respected*, making Simple-V in effect the "consistent public API".
1150 vew may be one of the following (giving a table "bytestable", used below):
1163 Pseudocode for vector length taking CSR SIMD-bitwidth into account:
1165 vew = CSRbitwidth[rs1]
1167 bytesperreg = (XLEN/8) # or FLEN as appropriate
1169 bytesperreg = bytestable[vew] # 1 2 4 8 16
1170 simdmult = (XLEN/8) / bytesperreg # or FLEN as appropriate
1171 vlen = CSRvectorlen[rs1] * simdmult
1173 To index an element in a register rnum where the vector element index is i:
1175 function regoffs(rnum, i):
1176 regidx = floor(i / simdmult) # integer-div rounded down
1177 byteidx = i % simdmult # integer-remainder
1178 return rnum + regidx, # actual real register
1180 byteidx * 8 + (vew-1), # high
1182 ### Example Instruction translation: <a name="example_translation"></a>
1184 Instructions "ADD r2 r4 r4" would result in three instructions being
1185 generated and placed into the FILO:
1193 SIMD register file splitting still to consider. For RV64, benefits of doubling
1194 (quadrupling in the case of Half-Precision IEEE754 FP) the apparent
1195 size of the floating point register file to 64 (128 in the case of HP)
1196 seem pretty clear and worth the complexity.
1198 64 virtual 32-bit F.P. registers and given that 32-bit FP operations are
1199 done on 64-bit registers it's not so conceptually difficult. May even
1200 be achieved by *actually* splitting the regfile into 64 virtual 32-bit
1201 registers such that a 64-bit FP scalar operation is dropped into (r0.H
1202 r0.L) tuples. Implementation therefore hidden through register renaming.
1204 Implementations intending to introduce VLIW, OoO and parallelism
1205 (even without Simple-V) would then find that the instructions are
1206 generated quicker (or in a more compact fashion that is less heavy
1207 on caches). Interestingly we observe then that Simple-V is about
1208 "consolidation of instruction generation", where actual parallelism
1209 of underlying hardware is an implementor-choice that could just as
1210 equally be applied *without* Simple-V even being implemented.
1212 ## Analysis of CSR decoding on latency <a name="csr_decoding_analysis"></a>
1214 It could indeed have been logically deduced (or expected), that there
1215 would be additional decode latency in this proposal, because if
1216 overloading the opcodes to have different meanings, there is guaranteed
1217 to be some state, some-where, directly related to registers.
1219 There are several cases:
1221 * All operands vector-length=1 (scalars), all operands
1222 packed-bitwidth="default": instructions are passed through direct as if
1223 Simple-V did not exist. Simple-V is, in effect, completely disabled.
1224 * At least one operand vector-length > 1, all operands
1225 packed-bitwidth="default": any parallel vector ALUs placed on "alert",
1226 virtual parallelism looping may be activated.
1227 * All operands vector-length=1 (scalars), at least one
1228 operand packed-bitwidth != default: degenerate case of SIMD,
1229 implementation-specific complexity here (packed decode before ALUs or
1231 * At least one operand vector-length > 1, at least one operand
1232 packed-bitwidth != default: parallel vector ALUs (if any)
1233 placed on "alert", virtual parallelsim looping may be activated,
1234 implementation-specific SIMD complexity kicks in (packed decode before
1237 Bear in mind that the proposal includes that the decision whether
1238 to parallelise in hardware or whether to virtual-parallelise (to
1239 dramatically simplify compilers and also not to run into the SIMD
1240 instruction proliferation nightmare) *or* a transprent combination
1241 of both, be done on a *per-operand basis*, so that implementors can
1242 specifically choose to create an application-optimised implementation
1243 that they believe (or know) will sell extremely well, without having
1244 "Extra Standards-Mandated Baggage" that would otherwise blow their area
1245 or power budget completely out the window.
1247 Additionally, two possible CSR schemes have been proposed, in order to
1248 greatly reduce CSR space:
1250 * per-register CSRs (vector-length and packed-bitwidth)
1251 * a smaller number of CSRs with the same information but with an *INDEX*
1252 specifying WHICH register in one of three regfiles (vector, fp, int)
1253 the length and bitwidth applies to.
1255 (See "CSR vector-length and CSR SIMD packed-bitwidth" section for details)
1257 In addition, LOAD/STORE has its own associated proposed CSRs that
1258 mirror the STRIDE (but not yet STRIDE-SEGMENT?) functionality of
1261 Also bear in mind that, for reasons of simplicity for implementors,
1262 I was coming round to the idea of permitting implementors to choose
1263 exactly which bitwidths they would like to support in hardware and which
1264 to allow to fall through to software-trap emulation.
1266 So the question boils down to:
1268 * whether either (or both) of those two CSR schemes have significant
1269 latency that could even potentially require an extra pipeline decode stage
1270 * whether there are implementations that can be thought of which do *not*
1271 introduce significant latency
1272 * whether it is possible to explicitly (through quite simply
1273 disabling Simple-V-Ext) or implicitly (detect the case all-vlens=1,
1274 all-simd-bitwidths=default) switch OFF any decoding, perhaps even to
1275 the extreme of skipping an entire pipeline stage (if one is needed)
1276 * whether packed bitwidth and associated regfile splitting is so complex
1277 that it should definitely, definitely be made mandatory that implementors
1278 move regfile splitting into the ALU, and what are the implications of that
1279 * whether even if that *is* made mandatory, is software-trapped
1280 "unsupported bitwidths" still desirable, on the basis that SIMD is such
1281 a complete nightmare that *even* having a software implementation is
1282 better, making Simple-V have more in common with a software API than
1285 Whilst the above may seem to be severe minuses, there are some strong
1288 * Significant reduction of V's opcode space: over 85%.
1289 * Smaller reduction of P's opcode space: around 10%.
1290 * The potential to use Compressed instructions in both Vector and SIMD
1291 due to the overloading of register meaning (implicit vectorisation,
1293 * Not only present but also future extensions automatically gain parallelism.
1294 * Already mentioned but worth emphasising: the simplification to compiler
1295 writers and assembly-level writers of having the same consistent ISA
1296 regardless of whether the internal level of parallelism (number of
1297 parallel ALUs) is only equal to one ("virtual" parallelism), or is
1298 greater than one, should not be underestimated.
1300 ## Reducing Register Bank porting
1302 This looks quite reasonable.
1303 <https://www.princeton.edu/~rblee/ELE572Papers/MultiBankRegFile_ISCA2000.pdf>
1305 The main details are outlined on page 4. They propose a 2-level register
1306 cache hierarchy, note that registers are typically only read once, that
1307 you never write back from upper to lower cache level but always go in a
1308 cycle lower -> upper -> ALU -> lower, and at the top of page 5 propose
1309 a scheme where you look ahead by only 2 instructions to determine which
1310 registers to bring into the cache.
1312 The nice thing about a vector architecture is that you *know* that
1313 *even more* registers are going to be pulled in: Hwacha uses this fact
1314 to optimise L1/L2 cache-line usage (avoid thrashing), strangely enough
1315 by *introducing* deliberate latency into the execution phase.
1319 * SIMD considered harmful <https://www.sigarch.org/simd-instructions-considered-harmful/>
1320 * Link to first proposal <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/GuukrSjgBH8>
1321 * Recommendation by Jacob Bachmeyer to make zero-overhead loop an
1322 "implicit program-counter" <https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/vYVi95gF2Mo/SHz6a4_lAgAJ>
1323 * Re-continuing P-Extension proposal <https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa-dev/IkLkQn3HvXQ/SEMyC9IlAgAJ>
1324 * First Draft P-SIMD (DSP) proposal <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/vYVi95gF2Mo>
1325 * B-Extension discussion <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/zi_7B15kj6s>
1326 * Broadcom VideoCore-IV <https://docs.broadcom.com/docs/12358545>
1327 Figure 2 P17 and Section 3 on P16.
1328 * Hwacha <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.html>
1329 * Hwacha <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-263.html>
1330 * Vector Workshop <http://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf>
1331 * Predication <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/XoP4BfYSLXA>
1332 * Branch Divergence <https://jbush001.github.io/2014/12/07/branch-divergence-in-parallel-kernels.html>
1333 * Life of Triangles (3D) <https://jbush001.github.io/2016/02/27/life-of-triangle.html>
1334 * Videocore-IV <https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-3d-Graphics-Pipeline>
1335 * Discussion proposing CSRs that change ISA definition
1336 <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/InzQ1wr_3Ak>
1337 * Zero-overhead loops <https://pdfs.semanticscholar.org/dbaa/66985cc730d4b44d79f519e96ec9c43ab5b7.pdf>
1338 * Multi-ported VLIW Register File Implementation <https://ce-publications.et.tudelft.nl/publications/1517_multiple_contexts_in_a_multiported_vliw_register_file_impl.pdf>
1339 * Fast context save/restore proposal <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/57F823FA.6030701%40gmail.com>
1340 * Register File Bank Cacheing <https://www.princeton.edu/~rblee/ELE572Papers/MultiBankRegFile_ISCA2000.pdf>