1 \documentclass[slidestop
]{beamer
}
2 \usepackage{beamerthemesplit
}
6 \title{Simple-V RISC-V Extension for Vectorisation and SIMD
}
7 \author{Luke Kenneth Casson Leighton
}
14 \huge{Simple-V RISC-V Extension for Vectors and SIMD
}\\
16 \Large{Flexible Vectorisation
}\\
17 \Large{(aka not so Simple-V?)
}\\
19 \Large{[proposed for
] Chennai
9th RISC-V Workshop
}\\
26 \frame{\frametitle{Credits and Acknowledgements
}
29 \item The Designers of RISC-V
\vspace{15pt
}
30 \item The RVV Working Group and contributors
\vspace{15pt
}
31 \item Jacob Bachmeyer, Xan Phung, Chuanhua Chang,\\
32 Guy Lemurieux, Jonathan Neuschäfer, Roger Bruisse,
33 and others
\vspace{15pt
}
34 \item ISA-Dev Group Members
\vspace{10pt
}
39 \frame{\frametitle{Quick refresher on SIMD
}
42 \item SIMD very easy to implement (and very seductive)
\vspace{10pt
}
43 \item Parallelism is in the ALU
\vspace{10pt
}
44 \item Zero-to-Negligeable impact for rest of core
\vspace{10pt
}
46 Where SIMD Goes Wrong:
\vspace{10pt
}
48 \item See "SIMD instructions considered harmful"
49 https://www.sigarch.org/simd-instructions-considered-harmful
50 \item Corner-cases alone are extremely complex.\\
51 Hardware is easy, but software is hell.
52 \item O($N^
{6}$) ISA opcode proliferation!\\
53 opcode, elwidth, veclen, src1-src2-dest hi/lo
57 \frame{\frametitle{Quick refresher on RVV
}
60 \item Extremely powerful (extensible to
256 registers)
\vspace{10pt
}
61 \item Supports polymorphism, several datatypes (inc. FP16)
\vspace{10pt
}
62 \item Requires a separate Register File
\vspace{10pt
}
63 \item Can be implemented as a separate pipeline
\vspace{10pt
}
65 However...
\vspace{10pt
}
67 \item 98 percent opcode duplication with rest of RV (CLIP)
68 \item Extending RVV requires customisation not just of h/w:\\
69 gcc and s/w also need customisation (and maintenance)
74 \frame{\frametitle{The Simon Sinek lowdown (Why, How, What)
}
78 Implementors need flexibility in vectorisation to optimise for
79 area or performance depending on the scope:
80 embedded DSP, Mobile GPU's, Server CPU's and more.
\vspace{4pt
}\\
81 Compilers also need flexibility in vectorisation to optimise for cost
82 of pipeline setup, amount of state to context switch
83 and software portability
\vspace{4pt
}
85 By implicitly marking INT/FP regs as "Vectorised":\\
86 it expresses how existing instructions should act
87 on (contiguous) blocks of registers, in parallel.
\vspace{4pt
}
89 Simple-V is a vectorisation "API" that extends existing
90 (scalar) instructions with explicit parallelisation.
95 \frame{\frametitle{How does Simple-V relate to RVV?
}
98 \item RVV very heavy-duty (excellent for supercomputing)
\vspace{10pt
}
99 \item Simple-V abstracts parallelism (based on best of RVV)
\vspace{10pt
}
100 \item Graded levels: hardware, hybrid or traps (fit impl. need)
\vspace{10pt
}
101 \item Even Compressed instructions become vectorised
\vspace{10pt
}
103 What Simple-V is not:
\vspace{10pt
}
105 \item A full supercomputer-level Vector Proposal
106 \item A replacement for RVV (SV is designed to be over-ridden\\
107 by - or augmented to become - RVV)
112 \frame{\frametitle{How is Parallelism abstracted in Simple-V?
}
115 \item Register "typing" turns any op into an implicit Vector op
\vspace{10pt
}
116 \item Primarily at the Instruction issue phase (except SIMD)\\
117 Note: it's ok to pass predication through to ALU (like SIMD)
118 \item Standard (and future, and custom) opcodes now parallel
\vspace{10pt
}
122 \item LOAD/STORE (inc. C.LD and C.ST, LD.X: everything)
123 \item All ALU ops (soft / hybrid / full HW, on per-op basis)
124 \item All branches become predication targets (C.FNE added)
125 \item C.MV of particular interest (s/v, v/v, v/s)
130 \frame{\frametitle{Implementation Options
}
133 \item Absolute minimum: Exceptions (if CSRs indicate "V", trap)
134 \item Hardware loop, single-instruction issue\\
135 (Do / Don't send through predication to ALU)
136 \item Hardware loop, parallel (multi-instruction) issue\\
137 (Do / Don't send through predication to ALU)
138 \item Hardware loop, full parallel ALU (not recommended)
142 \item 4 (or more?) options above may be deployed on per-op basis
143 \item SIMD always sends predication bits through to ALU
144 \item Minimum MVL MUST be sufficient to cover regfile LD/ST
145 \item Instr. FIFO may repeatedly split off N scalar ops at a time
148 % Instr. FIFO may need its own slide. Basically, the vectorised op
149 % gets pushed into the FIFO, where it is then "processed". Processing
150 % will remove the first set of ops from its vector numbering (taking
151 % predication into account) and shoving them **BACK** into the FIFO,
152 % but MODIFYING the remaining "vectorised" op, subtracting the now
153 % scalar ops from it.
155 \frame{\frametitle{How are SIMD Instructions Vectorised?
}
158 \item SIMD ALU(s) primarily unchanged
\vspace{10pt
}
159 \item Predication is added to each SIMD element (NO ZEROING!)
\vspace{10pt
}
160 \item End of Vector enables predication (NO ZEROING!)
\vspace{10pt
}
162 Considerations:
\vspace{10pt
}
164 \item Many SIMD ALUs possible (parallel execution)
\vspace{10pt
}
165 \item Very long SIMD ALUs could waste die area (short vectors)
\vspace{10pt
}
166 \item Implementor free to choose (API remains the same)
\vspace{10pt
}
169 % With multiple SIMD ALUs at for example 32-bit wide they can be used
170 % to either issue 64-bit or 128-bit or 256-bit wide SIMD operations
171 % or they can be used to cover several operations on totally different
172 % vectors / registers.
174 \frame{\frametitle{What's the deal / juice / score?
}
177 \item Standard Register File(s) overloaded with "vector span"
\vspace{10pt
}
178 \item Element width and type concepts remain same as RVV
\vspace{10pt
}
179 \item CSRs are key-value tables (overlaps allowed)
\vspace{10pt
}
181 Key differences from RVV:
\vspace{10pt
}
183 \item Predication in INT regs as a BIT field (max VL=XLEN)
184 \item Minimum VL must be Num Regs -
1 (all regs single LD/ST)
185 \item SV may condense sparse Vecs: RVV lets ALU do predication
186 \item NO ZEROING: non-predicated elements are skipped
191 \frame{\frametitle{Why are overlaps allowed in Regfiles?
}
194 \item Same register(s) can have multiple "interpretations"
\vspace{10pt
}
195 \item xBitManip plus SIMD plus xBitManip = Hi/Lo bitops
\vspace{10pt
}
196 \item (
32-bit GREV plus
4x8-bit SIMD plus
32-bit GREV)
\vspace{10pt
}
197 \item Same register(s) can be offset (no need for VSLIDE)
\vspace{10pt
}
201 \item xBitManip reduces O($N^
{6}$) SIMD down to O($N^
{3}$)
\vspace{10pt
}
202 \item Hi-Performance: Macro-op fusion (more pipeline stages?)
\vspace{10pt
}
207 \frame{\frametitle{Why no Zeroing (place zeros in non-predicated elements)?
}
210 \item Zeroing is an implementation optimisation favouring OoO
\vspace{8pt
}
211 \item Simple implementations may skip non-predicated operations
\vspace{8pt
}
212 \item Simple implementations explicitly have to destroy data
\vspace{8pt
}
213 \item Complex implementations may use reg-renames to save power\\
214 Zeroing on predication chains makes optimisation harder
216 Considerations:
\vspace{10pt
}
218 \item Complex not really impacted, Simple impacted a LOT
219 \item Overlapping "Vectors" may issue overlapping ops
220 \item Please don't use Vectors for "security" (use Sec-Ext)
223 % with overlapping "vectors" - bearing in mind that "vectors" are
224 % just a remap onto the standard register file, if the top bits of
225 % predication are zero, and there happens to be a second vector
226 % that uses some of the same register file that happens to be
227 % predicated out, the second vector op may be issued *at the same time*
228 % if there are available parallel ALUs to do so.
231 \frame{\frametitle{Predication key-value CSR store
}
234 \item key is int regfile number or FP regfile number (
1 bit)
\vspace{10pt
}
235 \item register to be predicated if referred to (
5 bits, key)
\vspace{10pt
}
236 \item register to store actual predication in (
5 bits, value)
\vspace{10pt
}
237 \item predication is inverted (
1 bit)
\vspace{10pt
}
241 \item Table should be expanded out for high-speed implementations
242 \item Multiple "keys" (and values) theoretically permitted
243 \item RVV rules about deleting higher-indexed CSRs followed
248 \frame{\frametitle{Register key-value CSR store
}
251 \item key is int regfile number or FP regfile number (
1 bit)
\vspace{10pt
}
252 \item register to be predicated if referred to (
5 bits, key)
\vspace{10pt
}
253 \item register to store actual predication in (
5 bits, value)
\vspace{10pt
}
254 \item TODO
\vspace{10pt
}
258 \item Table should be expanded out for high-speed implementations
259 \item Multiple "keys" (and values) theoretically permitted
260 \item RVV rules about deleting higher-indexed CSRs followed
265 \begin{frame
}[fragile
]
266 \frametitle{ADD pseudocode (or trap, or actual hardware loop)
}
269 function op_add(rd, rs1, rs2, predr) # add not VADD!
270 int i, id=
0, irs1=
0, irs2=
0;
271 for (i=
0; i < MIN(VL, vectorlen
[rd
]); i++)
272 if (ireg
[predr
] &
1<<i) # predication uses intregs
273 ireg
[rd+id
] <= ireg
[rs1+irs1
] + ireg
[rs2+irs2
];
274 if (reg_is_vectorised
[rd
]) \
{ id +=
1; \
}
275 if (reg_is_vectorised
[rs1
]) \
{ irs1 +=
1; \
}
276 if (reg_is_vectorised
[rs2
]) \
{ irs2 +=
1; \
}
280 \item SIMD slightly more complex (case above is elwidth = default)
281 \item Scalar-scalar and scalar-vector and vector-vector now all in one
282 \item OoO may choose to push ADDs into instr. queue (v. busy!)
286 \begin{frame
}[fragile
]
287 \frametitle{Predication-Branch (or trap, or actual hardware loop)
}
290 s1 = vectorlen
[src1
] >
1;
291 s2 = vectorlen
[src2
] >
1;
292 for (int i =
0; i < VL; ++i)
293 preg
[rs3
] |=
1 << cmp(s1 ? reg
[src1+i
] : reg
[src1
],
294 s2 ? reg
[src2+i
] : reg
[src2
]);
298 \item SIMD slightly more complex (case above is elwidth = default)
299 \item If s1 and s2 both scalars, Standard branch occurs
300 \item Predication stored in integer regfile as a bitfield
301 \item Scalar-vector and vector-vector supported
305 \begin{frame
}[fragile
]
306 \frametitle{LD/LD.S/LD.X (or trap, or actual hardware loop)
}
309 if (unit-strided) stride = elsize;
310 else stride = areg
[as2
]; // constant-strided
311 for (int i =
0; i < VL; ++i)
312 if (preg_enabled
[rd
] && (
[!
]preg
[rd
] &
1<<i))
313 for (int j =
0; j < seglen+
1; j++)
314 if (vectorised
[rs2
]) offs = vreg
[rs2
][i
]
315 else offs = i*(seglen+
1)*stride;
316 vreg
[rd+j
][i
] = mem
[sreg
[base
] + offs + j*stride
]
320 \item Again: SIMD slightly more complex
321 \item rs2 vectorised taken to implicitly indicate LD.X
326 \frame{\frametitle{C.MV extremely flexible!
}
329 \item scalar-to-vector (w/no pred): VSPLAT
330 \item scalar-to-vector (w/dest-pred): Sparse VSPLAT
331 \item scalar-to-vector (w/single dest-pred): VINSERT
332 \item vector-to-scalar (w/src-pred): VEXTRACT
333 \item vector-to-vector (w/no pred): Vector Copy
334 \item vector-to-vector (w/src xor dest pred): Sparse Vector Copy
335 \item vector-to-vector (w/src and dest pred): Vector Shuffle
340 \item Really powerful!
341 \item Any other options?
346 \frame{\frametitle{Opcodes, compared to RVV
}
349 \item All integer and FP opcodes all removed (no CLIP!)
\vspace{8pt
}
350 \item VMPOP, VFIRST etc. all removed (use xBitManip)
\vspace{8pt
}
351 \item VSLIDE removed (use regfile overlaps)
\vspace{8pt
}
352 \item C.MV covers VEXTRACT VINSERT and VSPLAT (and more)
\vspace{8pt
}
353 \item VSETVL, VGETVL, VSELECT stay
\vspace{8pt
}
354 \item Issue: VCLIP is not in RV* (add with custom ext?)
\vspace{8pt
}
355 \item Vector (or scalar-vector) use C.MV (MV is a pseudo-op)
\vspace{8pt
}
356 \item VMERGE: twin predicated C.MVs (one inverted. macro-op'd)
\vspace{8pt
}
361 \frame{\frametitle{Under consideration
}
364 \item Can VSELECT be removed? (it's really complex)
\vspace{10pt
}
365 \item Can CLIP be done as a CSR (mode, like elwidth)
\vspace{10pt
}
366 \item SIMD saturation (etc.) also set as a mode?
\vspace{10pt
}
367 \item C.MV src predication no different from dest predication\\
368 What to do? Make one have different meaning?
\vspace{10pt
}
369 \item 8/
16-bit ops is it worthwhile adding a "start offset"? \\
370 (a bit like misaligned addressing... for registers)\\
371 or just use predication to skip start?
\vspace{10pt
}
376 \frame{\frametitle{Summary
}
379 \item Designed for simplicity (graded levels of complexity)
\vspace{10pt
}
380 \item Fits RISC-V ethos: do more with less
\vspace{10pt
}
381 \item Reduces SIMD ISA proliferation by
3-
4 orders of magnitude \\
382 (without SIMD downsides or sacrificing speed trade-off)
\vspace{10pt
}
383 \item Covers
98\% of RVV, allows RVV to fit "on top"
\vspace{10pt
}
384 \item Huge range of implementor freedom and flexibility
\vspace{10pt
}
385 \item Not designed for supercomputing (that's RVV), designed for
386 in between: DSPs, RV32E, Embedded
3D GPUs etc.
\vspace{10pt
}
391 \frame{\frametitle{slide
}
396 Considerations:
\vspace{10pt
}
403 \frame{\frametitle{Including a plot
}
405 % \includegraphics[height=2in]{dental.ps}\\
406 {\bf \red Dental trajectories for
27 children:
}
410 \frame{\frametitle{Creating .pdf slides in WinEdt
}
413 \item LaTeX
[Shift-Control-L
]\vspace{10pt
}
414 \item dvi2pdf
[click the button
]\vspace{24pt
}
416 To print
4 slides per page in acrobat click
\vspace{10pt
}
418 \item File/print/properties
\vspace{10pt
}
419 \item Change ``pages per sheet'' to
4\vspace{10pt
}