feedback from rogier bruisse
[libreriscv.git] / simple_v_extension / simple_v_chennai_2018.tex
index 037265a761dbf8281c883a11624d9774800110cf..b0561901007c781f29b81b0c6216ef09d8a82d6d 100644 (file)
   \end{center}
 }
 
-\frame{\frametitle{Why another Vector Extension?}
+
+\frame{\frametitle{Credits and Acknowledgements}
 
  \begin{itemize}
-   \item RVV very heavy-duty (excellent for supercomputing)\vspace{10pt}
-   \item Simple-V abstracts parallelism (based on best of RVV)\vspace{10pt}
-   \item Graded levels: hardware, hybrid or traps\vspace{10pt}
-   \item Even Compressed instructions become vectorised\vspace{10pt}
-  \end{itemize}
-  What Simple-V is not:\vspace{10pt}
-   \begin{itemize}
-   \item A full supercomputer-level Vector Proposal\vspace{10pt}
-   \item A replacement for RVV (designed to be augmented)\vspace{10pt}
+   \item The Designers of RISC-V\vspace{15pt}
+   \item The RVV Working Group and contributors\vspace{15pt}
+   \item Jacob Bachmeyer, Xan Phung, Chuanhua Chang,\\
+            Guy Lemurieux, Jonathan Neuschafer, Roger Bruisse,
+            and others\vspace{15pt}
+   \item ISA-Dev Group Members\vspace{10pt}
   \end{itemize}
 }
 
+
 \frame{\frametitle{Quick refresher on SIMD}
 
  \begin{itemize}
    \begin{itemize}
    \item See "SIMD instructions considered harmful"
    https://www.sigarch.org/simd-instructions-considered-harmful
-   \item (Corner-cases alone are extremely complex)\vspace{10pt}
-   \item O($N^{6}$) ISA opcode proliferation!\vspace{10pt}
+   \item Corner-cases alone are extremely complex.\\
+            Hardware is easy, but software is hell.
+   \item O($N^{6}$) ISA opcode proliferation!\\
+            opcode, elwidth, veclen, src1-src2-dest hi/lo
   \end{itemize}
 }
 
   \end{itemize}
   However...\vspace{10pt}
    \begin{itemize}
-   \item 98 percent opcode duplication with rest of RV (CLIP)\vspace{10pt}
-   \item Extending RVV requires customisation\vspace{10pt}
+   \item 98 percent opcode duplication with rest of RV (CLIP)
+   \item Extending RVV requires customisation not just of h/w:\\
+            gcc and s/w also need customisation (and maintenance)
+  \end{itemize}
+}
+
+
+\frame{\frametitle{The Simon Sinek lowdown (Why, How, What)}
+
+ \begin{itemize}
+   \item Why?
+         Implementors need flexibility in vectorisation to optimise for
+         area or performance depending on the scope:
+            embedded DSP, Mobile GPU's, Server CPU's and more.\vspace{4pt}\\
+                Compilers also need flexibility in vectorisation to optimise for cost 
+                of pipeline setup, amount of state to context switch
+                and software portability\vspace{4pt}
+   \item How?
+            By implicitly marking INT/FP regs as "Vectorised",\\
+            SV expresses how existing instructions should act 
+            on [contiguous] blocks of registers, in parallel.\vspace{4pt}
+   \item What?
+                Simple-V is an "API" that implicitly extends
+                existing (scalar) instructions with explicit parallelisation. 
+  \end{itemize}
+}
+
+
+\frame{\frametitle{How does Simple-V relate to RVV?}
+
+ \begin{itemize}
+   \item RVV very heavy-duty (excellent for supercomputing)\vspace{10pt}
+   \item Simple-V abstracts parallelism (based on best of RVV)\vspace{10pt}
+   \item Graded levels: hardware, hybrid or traps (fit impl. need)\vspace{10pt}
+   \item Even Compressed instructions become vectorised\vspace{10pt}
+  \end{itemize}
+  What Simple-V is not:\vspace{10pt}
+   \begin{itemize}
+   \item A full supercomputer-level Vector Proposal
+   \item A replacement for RVV (SV is designed to be over-ridden\\
+            by - or augmented to become, or just be replaced by  - RVV)
   \end{itemize}
 }
 
 
-\frame{\frametitle{How is Parallelism abstracted?}
+\frame{\frametitle{How is Parallelism abstracted in Simple-V?}
 
  \begin{itemize}
-   \item Almost all opcodes removed in favour of implicit "typing"\vspace{10pt}
-   \item Primarily at the Instruction issue phase (except SIMD)\vspace{10pt}
+   \item Register "typing" turns any op into an implicit Vector op\vspace{10pt}
+   \item Primarily at the Instruction issue phase (except SIMD)\\
+         Note: it's ok to pass predication through to ALU (like SIMD)
    \item Standard (and future, and custom) opcodes now parallel\vspace{10pt}
   \end{itemize}
-  Notes:\vspace{10pt}
+  Notes:\vspace{6pt}
    \begin{itemize}
-   \item LOAD/STORE (inc. C.LD and C.ST, LDX: everything)\vspace{10pt}
-   \item All ALU ops (soft / hybrid / full HW, on per-op basis)\vspace{10pt}
-   \item All branches become predication targets (C.FNE added)\vspace{10pt}
+   \item LOAD/STORE (inc. C.LD and C.ST, LD.X: everything)
+   \item All ALU ops (soft / hybrid / full HW, on per-op basis)
+   \item All branches become predication targets (C.FNE added)
+   \item C.MV of particular interest (s/v, v/v, v/s)
   \end{itemize}
 }
 
 \frame{\frametitle{Implementation Options}
 
  \begin{itemize}
-   \item Absolute minimum: Exceptions (if CSRs indicate "V", trap)\vspace{10pt}
-   \item Hardware loop, single-instruction issue\vspace{10pt}
-   \item Hardware loop, parallel (multi-instruction) issue\vspace{10pt}
-   \item Hardware loop, full parallel ALU (not recommended)\vspace{10pt}
+   \item Absolute minimum: Exceptions (if CSRs indicate "V", trap)
+   \item Hardware loop, single-instruction issue\\
+                (Do / Don't send through predication to ALU)
+   \item Hardware loop, parallel (multi-instruction) issue\\
+                (Do / Don't send through predication to ALU)
+   \item Hardware loop, full parallel ALU (not recommended)
   \end{itemize}
-  Notes:\vspace{10pt}
+  Notes:\vspace{6pt}
   \begin{itemize}
    \item 4 (or more?) options above may be deployed on per-op basis
+   \item SIMD always sends predication bits through to ALU
    \item Minimum MVL MUST be sufficient to cover regfile LD/ST
-   \item OoO may split off 4+ single-instructions at a time
+   \item Instr. FIFO may repeatedly split off N scalar ops at a time
   \end{itemize}
 }
-
+% Instr. FIFO may need its own slide.  Basically, the vectorised op
+% gets pushed into the FIFO, where it is then "processed".  Processing
+% will remove the first set of ops from its vector numbering (taking
+% predication into account) and shoving them **BACK** into the FIFO,
+% but MODIFYING the remaining "vectorised" op, subtracting the now
+% scalar ops from it.
 
 \frame{\frametitle{How are SIMD Instructions Vectorised?}
 
   \end{itemize}
   Key differences from RVV:\vspace{10pt}
    \begin{itemize}
-   \item Predication in INT regs as a BIT field (max VL=XLEN)\vspace{10pt}
-   \item Minimum VL must be Num Regs - 1 (all regs single LD/ST)\vspace{10pt}
-   \item NO ZEROING: non-predicated elements are skipped\vspace{10pt}
+   \item Predication in INT regs as a BIT field (max VL=XLEN)
+   \item Minimum VL must be Num Regs - 1 (all regs single LD/ST)
+   \item SV may condense sparse Vecs: RVV lets ALU do predication
+   \item NO ZEROING: non-predicated elements are skipped
   \end{itemize}
 }
 
  \begin{itemize}
    \item Same register(s) can have multiple "interpretations"\vspace{10pt}
    \item xBitManip plus SIMD plus xBitManip = Hi/Lo bitops\vspace{10pt}
-   \item (32-bit GREV plus 4-wide 32-bit SIMD plus 32-bit GREVI)\vspace{10pt}
-   \item 32-bit op followed by 16-bit op w/ 2x VL, 1/2 predicated\vspace{10pt}
+   \item (32-bit GREV plus 4x8-bit SIMD plus 32-bit GREV)\vspace{10pt}
+   \item Same register(s) can be offset (no need for VSLIDE)\vspace{10pt}
   \end{itemize}
   Note:\vspace{10pt}
    \begin{itemize}
 \frame{\frametitle{Why no Zeroing (place zeros in non-predicated elements)?}
 
  \begin{itemize}
-   \item Zeroing is an implementation optimisation favouring OoO\vspace{10pt}
-   \item Simple implementations may skip non-predicated operations\vspace{10pt}
-   \item Simple implementations explicitly have to destroy data\vspace{10pt}
-   \item Complex implementations may use reg-renames to save power\vspace{10pt}
+   \item Zeroing is an implementation optimisation favouring OoO\vspace{8pt}
+   \item Simple implementations may skip non-predicated operations\vspace{8pt}
+   \item Simple implementations explicitly have to destroy data\vspace{8pt}
+   \item Complex implementations may use reg-renames to save power\\
+            Zeroing on predication chains makes optimisation harder
   \end{itemize}
   Considerations:\vspace{10pt}
   \begin{itemize}
 % predicated out, the second vector op may be issued *at the same time*
 % if there are available parallel ALUs to do so.
 
+
+\frame{\frametitle{Predication key-value CSR store}
+
+ \begin{itemize}
+   \item key is int regfile number or FP regfile number (1 bit)\vspace{10pt}
+   \item register to be predicated if referred to (5 bits, key)\vspace{10pt}
+   \item register to store actual predication in (5 bits, value)\vspace{10pt}
+   \item predication is inverted (1 bit)\vspace{10pt}
+  \end{itemize}
+  Notes:\vspace{10pt}
+   \begin{itemize}
+   \item Table should be expanded out for high-speed implementations
+   \item Multiple "keys" (and values) theoretically permitted
+   \item RVV rules about deleting higher-indexed CSRs followed
+  \end{itemize}
+}
+
+
+\frame{\frametitle{Register key-value CSR store}
+
+ \begin{itemize}
+   \item key is int regfile number or FP regfile number (1 bit)\vspace{10pt}
+   \item register to be predicated if referred to (5 bits, key)\vspace{10pt}
+   \item register to store actual predication in (5 bits, value)\vspace{10pt}
+   \item TODO\vspace{10pt}
+  \end{itemize}
+  Notes:\vspace{10pt}
+   \begin{itemize}
+   \item Table should be expanded out for high-speed implementations
+   \item Multiple "keys" (and values) theoretically permitted
+   \item RVV rules about deleting higher-indexed CSRs followed
+  \end{itemize}
+}
+
+
 \begin{frame}[fragile]
 \frametitle{ADD pseudocode (or trap, or actual hardware loop)}
 
@@ -236,16 +323,37 @@ for (int i = 0; i < VL; ++i)
 \end{frame}
 
 
+\frame{\frametitle{C.MV extremely flexible!}
+
+ \begin{itemize}
+   \item scalar-to-vector (w/no pred): VSPLAT
+   \item scalar-to-vector (w/dest-pred): Sparse VSPLAT
+   \item scalar-to-vector (w/single dest-pred): VINSERT
+   \item vector-to-scalar (w/src-pred): VEXTRACT
+   \item vector-to-vector (w/no pred): Vector Copy
+   \item vector-to-vector (w/src xor dest pred): Sparse Vector Copy
+   \item vector-to-vector (w/src and dest pred): Vector Shuffle
+  \end{itemize}
+  \vspace{8pt}
+  Notes:\vspace{10pt}
+   \begin{itemize}
+   \item Really powerful!
+   \item Any other options?
+  \end{itemize}
+}
+
+
 \frame{\frametitle{Opcodes, compared to RVV}
 
  \begin{itemize}
-   \item All integer and FP opcodes all removed (no CLIP!)\vspace{10pt}
-   \item VMPOP, VFIRST etc. all removed (use xBitManip)\vspace{10pt}
-   \item VSLIDE, VEXTRACT, VINSERT removed (using regfile)\vspace{10pt}
-   \item VSETVL, VGETVL, VSELECT stay\vspace{10pt}
-   \item Issue: VCLIP is not in RV* (add with custom ext?)\vspace{10pt}
-   \item Vector (or scalar-vector) use C.MV (MV is a pseudo-op)\vspace{10pt}
-   \item VMERGE: twin predicated C.MVs (one inverted. macro-op'd)\vspace{10pt}
+   \item All integer and FP opcodes all removed (no CLIP!)\vspace{8pt}
+   \item VMPOP, VFIRST etc. all removed (use xBitManip)\vspace{8pt}
+   \item VSLIDE removed (use regfile overlaps)\vspace{8pt}
+   \item C.MV covers VEXTRACT VINSERT and VSPLAT (and more)\vspace{8pt}
+   \item VSETVL, VGETVL, VSELECT stay\vspace{8pt}
+   \item Issue: VCLIP is not in RV* (add with custom ext?)\vspace{8pt}
+   \item Vector (or scalar-vector) use C.MV (MV is a pseudo-op)\vspace{8pt}
+   \item VMERGE: twin predicated C.MVs (one inverted. macro-op'd)\vspace{8pt}
   \end{itemize}
 }
 
@@ -253,21 +361,30 @@ for (int i = 0; i < VL; ++i)
 \frame{\frametitle{Under consideration}
 
  \begin{itemize}
-   \item Can VSELECT be removed (or overloaded onto xBitManip)?\vspace{10pt}
+   \item Is C.FNE actually needed?\vspace{10pt}
+   \item Can VSELECT be removed? (it's really complex)\vspace{10pt}
    \item Can CLIP be done as a CSR (mode, like elwidth)\vspace{10pt}
    \item SIMD saturation (etc.) also set as a mode?\vspace{10pt}
+   \item C.MV src predication no different from dest predication\\
+         What to do? Make one have different meaning?\vspace{10pt}
+   \item 8/16-bit ops is it worthwhile adding a "start offset"? \\
+         (a bit like misaligned addressing... for registers)\\
+         or just use predication to skip start?\vspace{10pt}
   \end{itemize}
 }
 
 
-\frame{\frametitle{slide}
+\frame{\frametitle{Summary}
 
  \begin{itemize}
-   \item \vspace{10pt}
-  \end{itemize}
-  Considerations:\vspace{10pt}
-  \begin{itemize}
-   \item \vspace{10pt}
+   \item Designed for simplicity (graded levels of complexity)\vspace{10pt}
+   \item Fits RISC-V ethos: do more with less\vspace{10pt}
+   \item Reduces SIMD ISA proliferation by 3-4 orders of magnitude \\
+            (without SIMD downsides or sacrificing speed trade-off)\vspace{10pt}
+   \item Covers 98\% of RVV, allows RVV to fit "on top"\vspace{10pt}
+   \item Huge range of implementor freedom and flexibility\vspace{10pt}
+   \item Not designed for supercomputing (that's RVV), designed for
+         in between: DSPs, RV32E, Embedded 3D GPUs etc.\vspace{10pt}
   \end{itemize}
 }