add slide
[libreriscv.git] / simple_v_extension / simple_v_chennai_2018.tex
1 \documentclass[slidestop]{beamer}
2 \usepackage{beamerthemesplit}
3 \usepackage{graphics}
4 \usepackage{pstricks}
5
6 \title{Simple-V RISC-V Extension for Vectorisation and SIMD}
7 \author{Luke Kenneth Casson Leighton}
8
9
10 \begin{document}
11
12 \frame{
13 \begin{center}
14 \huge{Simple-V RISC-V Extension for Vectors and SIMD}\\
15 \vspace{32pt}
16 \Large{Flexible Vectorisation}\\
17 \Large{(aka not so Simple-V?)}\\
18 \vspace{24pt}
19 \Large{[proposed for] Chennai 9th RISC-V Workshop}\\
20 \vspace{24pt}
21 \large{\today}
22 \end{center}
23 }
24
25
26 \frame{\frametitle{The Simon Sinek lowdown (Why, How, What)}
27
28 \begin{itemize}
29 \item Vectorisation needs to fit an implementor's needs:\\
30 RV32E, Embedded/Mobile, DSP, Servers and more.\vspace{15pt}
31 \item By implicitly marking INT/FP regs as "Vectorised",\\
32 everything else follows from there.\vspace{15pt}
33 \item A Standard Vector "API" with flexibility for implementors:\\
34 choice to optimise for area or performance as desired\vspace{10pt}
35 \end{itemize}
36 }
37
38
39 \frame{\frametitle{Why another Vector Extension?}
40
41 \begin{itemize}
42 \item RVV very heavy-duty (excellent for supercomputing)\vspace{10pt}
43 \item Simple-V abstracts parallelism (based on best of RVV)\vspace{10pt}
44 \item Graded levels: hardware, hybrid or traps\vspace{10pt}
45 \item Even Compressed instructions become vectorised\vspace{10pt}
46 \end{itemize}
47 What Simple-V is not:\vspace{10pt}
48 \begin{itemize}
49 \item A full supercomputer-level Vector Proposal\vspace{10pt}
50 \item A replacement for RVV (designed to be augmented)\vspace{10pt}
51 \end{itemize}
52 }
53
54
55 \frame{\frametitle{Quick refresher on SIMD}
56
57 \begin{itemize}
58 \item SIMD very easy to implement (and very seductive)\vspace{10pt}
59 \item Parallelism is in the ALU\vspace{10pt}
60 \item Zero-to-Negligeable impact for rest of core\vspace{10pt}
61 \end{itemize}
62 Where SIMD Goes Wrong:\vspace{10pt}
63 \begin{itemize}
64 \item See "SIMD instructions considered harmful"
65 https://www.sigarch.org/simd-instructions-considered-harmful
66 \item (Corner-cases alone are extremely complex)\vspace{10pt}
67 \item O($N^{6}$) ISA opcode proliferation!\vspace{10pt}
68 \end{itemize}
69 }
70
71 \frame{\frametitle{Quick refresher on RVV}
72
73 \begin{itemize}
74 \item Extremely powerful (extensible to 256 registers)\vspace{10pt}
75 \item Supports polymorphism, several datatypes (inc. FP16)\vspace{10pt}
76 \item Requires a separate Register File\vspace{10pt}
77 \item Can be implemented as a separate pipeline\vspace{10pt}
78 \end{itemize}
79 However...\vspace{10pt}
80 \begin{itemize}
81 \item 98 percent opcode duplication with rest of RV (CLIP)\vspace{10pt}
82 \item Extending RVV requires customisation\vspace{10pt}
83 \end{itemize}
84 }
85
86
87 \frame{\frametitle{How is Parallelism abstracted?}
88
89 \begin{itemize}
90 \item Almost all opcodes removed in favour of implicit "typing"\vspace{10pt}
91 \item Primarily at the Instruction issue phase (except SIMD)\vspace{10pt}
92 \item Standard (and future, and custom) opcodes now parallel\vspace{10pt}
93 \end{itemize}
94 Notes:\vspace{10pt}
95 \begin{itemize}
96 \item LOAD/STORE (inc. C.LD and C.ST, LDX: everything)\vspace{10pt}
97 \item All ALU ops (soft / hybrid / full HW, on per-op basis)\vspace{10pt}
98 \item All branches become predication targets (C.FNE added)\vspace{10pt}
99 \end{itemize}
100 }
101
102
103 \frame{\frametitle{Implementation Options}
104
105 \begin{itemize}
106 \item Absolute minimum: Exceptions (if CSRs indicate "V", trap)\vspace{10pt}
107 \item Hardware loop, single-instruction issue\vspace{10pt}
108 \item Hardware loop, parallel (multi-instruction) issue\vspace{10pt}
109 \item Hardware loop, full parallel ALU (not recommended)\vspace{10pt}
110 \end{itemize}
111 Notes:\vspace{10pt}
112 \begin{itemize}
113 \item 4 (or more?) options above may be deployed on per-op basis
114 \item Minimum MVL MUST be sufficient to cover regfile LD/ST
115 \item OoO may split off 4+ single-instructions at a time
116 \end{itemize}
117 }
118
119
120 \frame{\frametitle{How are SIMD Instructions Vectorised?}
121
122 \begin{itemize}
123 \item SIMD ALU(s) primarily unchanged\vspace{10pt}
124 \item Predication is added to each SIMD element (NO ZEROING!)\vspace{10pt}
125 \item End of Vector enables predication (NO ZEROING!)\vspace{10pt}
126 \end{itemize}
127 Considerations:\vspace{10pt}
128 \begin{itemize}
129 \item Many SIMD ALUs possible (parallel execution)\vspace{10pt}
130 \item Very long SIMD ALUs could waste die area (short vectors)\vspace{10pt}
131 \item Implementor free to choose (API remains the same)\vspace{10pt}
132 \end{itemize}
133 }
134 % With multiple SIMD ALUs at for example 32-bit wide they can be used
135 % to either issue 64-bit or 128-bit or 256-bit wide SIMD operations
136 % or they can be used to cover several operations on totally different
137 % vectors / registers.
138
139 \frame{\frametitle{What's the deal / juice / score?}
140
141 \begin{itemize}
142 \item Standard Register File(s) overloaded with "vector span"\vspace{10pt}
143 \item Element width and type concepts remain same as RVV\vspace{10pt}
144 \item CSRs are key-value tables (overlaps allowed)\vspace{10pt}
145 \end{itemize}
146 Key differences from RVV:\vspace{10pt}
147 \begin{itemize}
148 \item Predication in INT regs as a BIT field (max VL=XLEN)\vspace{10pt}
149 \item Minimum VL must be Num Regs - 1 (all regs single LD/ST)\vspace{10pt}
150 \item NO ZEROING: non-predicated elements are skipped\vspace{10pt}
151 \end{itemize}
152 }
153
154
155 \frame{\frametitle{Why are overlaps allowed in Regfiles?}
156
157 \begin{itemize}
158 \item Same register(s) can have multiple "interpretations"\vspace{10pt}
159 \item xBitManip plus SIMD plus xBitManip = Hi/Lo bitops\vspace{10pt}
160 \item (32-bit GREV plus 4-wide 32-bit SIMD plus 32-bit GREV)\vspace{10pt}
161 \item Same register(s) can be offset (no need for VSLIDE)\vspace{10pt}
162 \end{itemize}
163 Note:\vspace{10pt}
164 \begin{itemize}
165 \item xBitManip reduces O($N^{6}$) SIMD down to O($N^{3}$) \vspace{10pt}
166 \item Hi-Performance: Macro-op fusion (more pipeline stages?)\vspace{10pt}
167 \end{itemize}
168 }
169
170
171 \frame{\frametitle{Why no Zeroing (place zeros in non-predicated elements)?}
172
173 \begin{itemize}
174 \item Zeroing is an implementation optimisation favouring OoO\vspace{10pt}
175 \item Simple implementations may skip non-predicated operations\vspace{10pt}
176 \item Simple implementations explicitly have to destroy data\vspace{10pt}
177 \item Complex implementations may use reg-renames to save power\vspace{10pt}
178 \end{itemize}
179 Considerations:\vspace{10pt}
180 \begin{itemize}
181 \item Complex not really impacted, Simple impacted a LOT
182 \item Overlapping "Vectors" may issue overlapping ops
183 \item Please don't use Vectors for "security" (use Sec-Ext)
184 \end{itemize}
185 }
186 % with overlapping "vectors" - bearing in mind that "vectors" are
187 % just a remap onto the standard register file, if the top bits of
188 % predication are zero, and there happens to be a second vector
189 % that uses some of the same register file that happens to be
190 % predicated out, the second vector op may be issued *at the same time*
191 % if there are available parallel ALUs to do so.
192
193
194 \frame{\frametitle{Predication key-value CSR store}
195
196 \begin{itemize}
197 \item key is int regfile number or FP regfile number (1 bit)\vspace{10pt}
198 \item register to be predicated if referred to (5 bits, key)\vspace{10pt}
199 \item register to store actual predication in (5 bits, value)\vspace{10pt}
200 \item predication is inverted (1 bit)\vspace{10pt}
201 \end{itemize}
202 Notes:\vspace{10pt}
203 \begin{itemize}
204 \item Table should be expanded out for high-speed implementations
205 \item Multiple "keys" (and values) theoretically permitted
206 \item RVV rules about deleting higher-indexed CSRs followed
207 \end{itemize}
208 }
209
210
211 \begin{frame}[fragile]
212 \frametitle{ADD pseudocode (or trap, or actual hardware loop)}
213
214 \begin{semiverbatim}
215 function op_add(rd, rs1, rs2, predr) # add not VADD!
216  int i, id=0, irs1=0, irs2=0;
217  for (i=0; i < MIN(VL, vectorlen[rd]); i++)
218   if (ireg[predr] & 1<<i) # predication uses intregs
219    ireg[rd+id] <= ireg[rs1+irs1] + ireg[rs2+irs2];
220 if (reg_is_vectorised[rd]) \{ id += 1; \}
221 if (reg_is_vectorised[rs1]) \{ irs1 += 1; \}
222 if (reg_is_vectorised[rs2]) \{ irs2 += 1; \}
223 \end{semiverbatim}
224
225 \begin{itemize}
226 \item SIMD slightly more complex (case above is elwidth = default)
227 \item Scalar-scalar and scalar-vector and vector-vector now all in one
228 \item OoO may choose to push ADDs into instr. queue (v. busy!)
229 \end{itemize}
230 \end{frame}
231
232 \begin{frame}[fragile]
233 \frametitle{Predication-Branch (or trap, or actual hardware loop)}
234
235 \begin{semiverbatim}
236 s1 = vectorlen[src1] > 1;
237 s2 = vectorlen[src2] > 1;
238 for (int i = 0; i < VL; ++i)
239 preg[rs3] |= 1 << cmp(s1 ? reg[src1+i] : reg[src1],
240 s2 ? reg[src2+i] : reg[src2]);
241 \end{semiverbatim}
242
243 \begin{itemize}
244 \item SIMD slightly more complex (case above is elwidth = default)
245 \item If s1 and s2 both scalars, Standard branch occurs
246 \item Predication stored in integer regfile as a bitfield
247 \item Scalar-vector and vector-vector supported
248 \end{itemize}
249 \end{frame}
250
251 \begin{frame}[fragile]
252 \frametitle{LD/LD.S/LD.X (or trap, or actual hardware loop)}
253
254 \begin{semiverbatim}
255 if (unit-strided) stride = elsize;
256 else stride = areg[as2]; // constant-strided
257 for (int i = 0; i < VL; ++i)
258 if (preg_enabled[rd] && ([!]preg[rd] & 1<<i))
259 for (int j = 0; j < seglen+1; j++)
260 if (vectorised[rs2]) offs = vreg[rs2][i]
261 else offs = i*(seglen+1)*stride;
262 vreg[rd+j][i] = mem[sreg[base] + offs + j*stride]
263 \end{semiverbatim}
264
265 \begin{itemize}
266 \item Again: SIMD slightly more complex
267 \item rs2 vectorised taken to implicitly indicate LD.X
268 \end{itemize}
269 \end{frame}
270
271
272 \frame{\frametitle{Opcodes, compared to RVV}
273
274 \begin{itemize}
275 \item All integer and FP opcodes all removed (no CLIP!)\vspace{10pt}
276 \item VMPOP, VFIRST etc. all removed (use xBitManip)\vspace{10pt}
277 \item VSLIDE, VEXTRACT, VINSERT removed (using regfile)\vspace{10pt}
278 \item VSETVL, VGETVL, VSELECT stay\vspace{10pt}
279 \item Issue: VCLIP is not in RV* (add with custom ext?)\vspace{10pt}
280 \item Vector (or scalar-vector) use C.MV (MV is a pseudo-op)\vspace{10pt}
281 \item VMERGE: twin predicated C.MVs (one inverted. macro-op'd)\vspace{10pt}
282 \end{itemize}
283 }
284
285
286 \frame{\frametitle{Under consideration}
287
288 \begin{itemize}
289 \item Can VSELECT be removed? (it's really complex)\vspace{10pt}
290 \item Can CLIP be done as a CSR (mode, like elwidth)\vspace{10pt}
291 \item SIMD saturation (etc.) also set as a mode?\vspace{10pt}
292 \item 8/16-bit ops is it worthwhile adding a "start offset"? \\
293 (a bit like misaligned addressing... for registers)\vspace{10pt}
294 \end{itemize}
295 }
296
297
298 \frame{\frametitle{Summary}
299
300 \begin{itemize}
301 \item Designed for simplicity (graded levels of complexity)\vspace{10pt}
302 \item Fits RISC-V ethos: do more with less\vspace{10pt}
303 \item Reduces SIMD ISA proliferation by 3-4 orders of magnitude \\
304 (without SIMD downsides or sacrificing speed trade-off)\vspace{10pt}
305 \item Covers 98\% of RVV, allows RVV to fit "on top"\vspace{10pt}
306 \item Huge range of implementor freedom and flexibility\vspace{10pt}
307 \item Not designed for supercomputing (that's RVV), designed for
308 in between: DSPs, RV32E, Embedded 3D GPUs etc.\vspace{10pt}
309 \end{itemize}
310 }
311
312
313 \frame{\frametitle{slide}
314
315 \begin{itemize}
316 \item \vspace{10pt}
317 \end{itemize}
318 Considerations:\vspace{10pt}
319 \begin{itemize}
320 \item \vspace{10pt}
321 \end{itemize}
322 }
323
324
325 \frame{\frametitle{Including a plot}
326 \begin{center}
327 % \includegraphics[height=2in]{dental.ps}\\
328 {\bf \red Dental trajectories for 27 children:}
329 \end{center}
330 }
331
332 \frame{\frametitle{Creating .pdf slides in WinEdt}
333
334 \begin{itemize}
335 \item LaTeX [Shift-Control-L]\vspace{10pt}
336 \item dvi2pdf [click the button]\vspace{24pt}
337 \end{itemize}
338 To print 4 slides per page in acrobat click\vspace{10pt}
339 \begin{itemize}
340 \item File/print/properties\vspace{10pt}
341 \item Change ``pages per sheet'' to 4\vspace{10pt}
342 \end{itemize}
343 }
344
345 \frame{
346 \begin{center}
347 {\Huge \red The end}
348 \end{center}
349 }
350
351
352 \end{document}