\item The Designers of RISC-V\vspace{15pt}
\item The RVV Working Group and contributors\vspace{15pt}
\item Allen Baum, Jacob Bachmeyer, Xan Phung, Chuanhua Chang,\\
- Guy Lemurieux, Jonathan Neuschafer, Roger Bruisse,
+ Guy Lemurieux, Jonathan Neuschafer, Roger Brussee,
and others\vspace{15pt}
\item ISA-Dev Group Members\vspace{10pt}
\end{itemize}
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.
+ existing (scalar) instructions with explicit parallelisation
+ (i.e. SV is actually about parallelism NOT vectors per se)
\end{itemize}
}
\frame{\frametitle{What's the value of SV? Why adopt it even in non-V?}
\begin{itemize}
- \item memcpy becomes much smaller (higher bang-per-buck)\vspace{10pt}
- \item context-switch (LOAD/STORE multiple): 1-2 instructions\vspace{10pt}
- \item Compressed instrs further reduces I-cache (etc.)\vspace{10pt}
- \item greatly-reduced I-cache load (and less reads)\vspace{10pt}
- \end{itemize}
- Note:\vspace{10pt}
+ \item memcpy becomes much smaller (higher bang-per-buck)
+ \item context-switch (LOAD/STORE multiple): 1-2 instructions
+ \item Compressed instrs further reduces I-cache (etc.)
+ \item Greatly-reduced I-cache load (and less reads)
+ \item Amazingly, SIMD becomes (more) tolerable\\
+ (corner-cases for setup and teardown are gone)
+ \end{itemize}
+ Note:
\begin{itemize}
\item It's not just about Vectors: it's about instruction effectiveness
+ \item Anything that makes SIMD tolerable has to be a good thing
\item Anything implementor is not interested in HW-optimising,\\
let it fall through to exceptions (implement as a trap).
\end{itemize}
}
-\frame{\frametitle{How does Simple-V relate to RVV?}
+\frame{\frametitle{How does Simple-V relate to RVV? What's different?}
\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}
+ \item Even Compressed become vectorised (RVV can't)\vspace{10pt}
\end{itemize}
What Simple-V is not:\vspace{10pt}
\begin{itemize}
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{6pt}
+ Note: EVERYTHING is parallelised:
\begin{itemize}
\item All LOAD/STORE (inc. Compressed, Int/FP versions)
\item All ALU ops (soft / hybrid / full HW, on per-op basis)
- \item All branches become predication targets (C.FNE added)
+ \item All branches become predication targets (C.FNE added?)
\item C.MV of particular interest (s/v, v/v, v/s)
+ \item FCVT, FMV, FSGNJ etc. very similar to C.MV
\end{itemize}
}
% but MODIFYING the remaining "vectorised" op, subtracting the now
% scalar ops from it.
+\frame{\frametitle{Predicated 8-parallel ADD: 1-wide ALU}
+ \begin{center}
+ \includegraphics[height=2.5in]{padd9_alu1.png}\\
+ {\bf \red Predicated adds are shuffled down: 6 cycles in total}
+ \end{center}
+}
+
+
+\frame{\frametitle{Predicated 8-parallel ADD: 4-wide ALU}
+ \begin{center}
+ \includegraphics[height=2.5in]{padd9_alu4.png}\\
+ {\bf \red Predicated adds are shuffled down: 4 in 1st cycle, 2 in 2nd}
+ \end{center}
+}
+
+
+\frame{\frametitle{Predicated 8-parallel ADD: 3 phase FIFO expansion}
+ \begin{center}
+ \includegraphics[height=2.5in]{padd9_fifo.png}\\
+ {\bf \red First cycle takes first four 1s; second takes the rest}
+ \end{center}
+}
+
+
\frame{\frametitle{How are SIMD Instructions Vectorised?}
\begin{itemize}
- \item SIMD ALU(s) primarily unchanged\vspace{10pt}
- \item Predication is added to each SIMD element (NO ZEROING!)\vspace{10pt}
- \item End of Vector enables predication (NO ZEROING!)\vspace{10pt}
+ \item SIMD ALU(s) primarily unchanged\vspace{6pt}
+ \item Predication is added to each SIMD element\vspace{6pt}
+ \item Predication bits sent in groups to the ALU\vspace{6pt}
+ \item End of Vector enables (additional) predication\vspace{10pt}
\end{itemize}
- Considerations:\vspace{10pt}
+ Considerations:\vspace{4pt}
\begin{itemize}
- \item Many SIMD ALUs possible (parallel execution)\vspace{10pt}
- \item Very long SIMD ALUs could waste die area (short vectors)\vspace{10pt}
- \item Implementor free to choose (API remains the same)\vspace{10pt}
+ \item Many SIMD ALUs possible (parallel execution)
+ \item Implementor free to choose (API remains the same)
+ \item Unused ALU units wasted, but s/w DRASTICALLY simpler
+ \item Very long SIMD ALUs could waste significant die area
\end{itemize}
}
% With multiple SIMD ALUs at for example 32-bit wide they can be used
% or they can be used to cover several operations on totally different
% vectors / registers.
+\frame{\frametitle{Predicated 9-parallel SIMD ADD}
+ \begin{center}
+ \includegraphics[height=2.5in]{padd9_simd.png}\\
+ {\bf \red 4-wide 8-bit SIMD, 4 bits of predicate passed to ALU}
+ \end{center}
+}
+
+
\frame{\frametitle{What's the deal / juice / score?}
\begin{itemize}
- \item Standard Register File(s) overloaded with CSR "vector span"\\
+ \item Standard Register File(s) overloaded with CSR "reg is vector"\\
(see pseudocode slides for examples)
- \item Element width and type concepts remain same as RVV\\
+ \item Element width (and type?) concepts remain same as RVV\\
(CSRs are used to "interpret" elements in registers)
\item CSRs are key-value tables (overlaps allowed)\vspace{10pt}
\end{itemize}
\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
+ \item Choice to Zero or skip non-predicated elements
\end{itemize}
}
\begin{semiverbatim}
function op_add(rd, rs1, rs2, predr) # add not VADD!
int i, id=0, irs1=0, irs2=0;
- for (i=0; i < MIN(VL, vectorlen[rd]); i++)
+ for (i = 0; i < VL; i++)
if (ireg[predr] & 1<<i) # predication uses intregs
ireg[rd+id] <= ireg[rs1+irs1] + ireg[rs2+irs2];
if (reg_is_vectorised[rd]) \{ id += 1; \}
s2 = reg_is_vectorised(src2);
if (!s2 && !s1) goto branch;
for (int i = 0; i < VL; ++i)
- preg[rs3] |= 1 << cmp(s1 ? reg[src1+i] : reg[src1],
- s2 ? reg[src2+i] : reg[src2]);
+ if cmp(s1 ? reg[src1+i] : reg[src1],
+ s2 ? reg[src2+i] : reg[src2])
+ preg[rs3] |= 1 << i;
\end{semiverbatim}
\begin{itemize}
for (int i = 0; i < VL; ++i)
if (preg_enabled[rd] && ([!]preg[rd] & 1<<i))
for (int j = 0; j < seglen+1; j++)
- if (vectorised[rs2]) offs = vreg[rs2][i]
+ if (reg_is_vectorised[rs2]) offs = vreg[rs2+i]
else offs = i*(seglen+1)*stride;
vreg[rd+j][i] = mem[sreg[base] + offs + j*stride]
\end{semiverbatim}
\begin{itemize}
- \item Again: SIMD slightly more complex
+ \item Again: elwidth != default slightly more complex
\item rs2 vectorised taken to implicitly indicate VLD.X
\end{itemize}
\end{frame}
\frame{\frametitle{Why are overlaps allowed in Regfiles?}
\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 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}
+ \item Same register(s) can have multiple "interpretations"
+ \item Set "real" register (scalar) without needing to set/unset CSRs.
+ \item xBitManip plus SIMD plus xBitManip = Hi/Lo bitops
+ \item (32-bit GREV plus 4x8-bit SIMD plus 32-bit GREV:\\
+ GREV @ VL=N,wid=32; SIMD @ VL=Nx4,wid=8)
+ \item RGB 565 (video): BEXTW plus 4x8-bit SIMD plus BDEPW\\
+ (BEXT/BDEP @ VL=N,wid=32; SIMD @ VL=Nx4,wid=8)
+ \item Same register(s) can be offset (no need for VSLIDE)\vspace{6pt}
+ \end{itemize}
+ Note:
\begin{itemize}
- \item xBitManip reduces O($N^{6}$) SIMD down to O($N^{3}$) \vspace{10pt}
- \item Hi-Performance: Macro-op fusion (more pipeline stages?)\vspace{10pt}
+ \item xBitManip reduces O($N^{6}$) SIMD down to O($N^{3}$)
+ \item Hi-Performance: Macro-op fusion (more pipeline stages?)
\end{itemize}
}
-\frame{\frametitle{Why no Zeroing (place zeros in non-predicated elements)?}
+\frame{\frametitle{To Zero or not to place zeros in non-predicated elements?}
\begin{itemize}
- \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 Zeroing is an implementation optimisation favouring OoO
+ \item Simple implementations may skip non-predicated operations
+ \item Simple implementations explicitly have to destroy data
\item Complex implementations may use reg-renames to save power\\
Zeroing on predication chains makes optimisation harder
+ \item Compromise: REQUIRE both (specified in predication CSRs).
\end{itemize}
- Considerations:\vspace{10pt}
+ Considerations:
\begin{itemize}
- \item Complex not really impacted, Simple impacted a LOT
- \item Overlapping "Vectors" may issue overlapping ops
+ \item Complex not really impacted, simple impacted a LOT\\
+ with Zeroing... however it's useful (memzero)
+ \item Non-zero'd overlapping "Vectors" may issue overlapping ops\\
+ (2nd op's predicated elements slot in 1st's non-predicated ops)
\item Please don't use Vectors for "security" (use Sec-Ext)
\end{itemize}
}
\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}
+ \item key is int regfile number or FP regfile number (1 bit)\vspace{6pt}
+ \item register to be predicated if referred to (5 bits, key)\vspace{6pt}
+ \item register to store actual predication in (5 bits, value)\vspace{6pt}
+ \item predication is inverted Y/N (1 bit)\vspace{6pt}
+ \item non-predicated elements are to be zero'd Y/N (1 bit)\vspace{6pt}
\end{itemize}
Notes:\vspace{10pt}
\begin{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}
+ \item key is int regfile number or FP regfile number (1 bit)\vspace{6pt}
+ \item treated as vector if referred to in op (5 bits, key)\vspace{6pt}
+ \item starting register to actually be used (5 bits, value)\vspace{6pt}
+ \item element bitwidth: default/8/16/32/64/rsvd (3 bits)\vspace{6pt}
+ \item element type: still under consideration\vspace{6pt}
\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
+ \item Same notes apply (previous slide) as for predication CSR table
+ \item Level of indirection has implications for pipeline latency
\end{itemize}
}
\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 Gather/Scatter
- \end{itemize}
- \vspace{8pt}
- Notes:\vspace{10pt}
+ \item scalar-to-vector (w/ no pred): VSPLAT
+ \item scalar-to-vector (w/ dest-pred): Sparse VSPLAT
+ \item scalar-to-vector (w/ 1-bit dest-pred): VINSERT
+ \item vector-to-scalar (w/ [1-bit?] src-pred): VEXTRACT
+ \item vector-to-vector (w/ no pred): Vector Copy
+ \item vector-to-vector (w/ src pred): Vector Gather
+ \item vector-to-vector (w/ dest pred): Vector Scatter
+ \item vector-to-vector (w/ src \& dest pred): Vector Gather/Scatter
+ \end{itemize}
+ \vspace{4pt}
+ Notes:
\begin{itemize}
- \item Really powerful!
- \item Any other options?
+ \item Surprisingly powerful!
+ \item Same arrangement for FVCT, FMV, FSGNJ etc.
\end{itemize}
}
\begin{itemize}
\item Is C.FNE actually needed? Should it be added if it is?
- \item FP Exceptions: should linear semantics be forced?\\
- (requires throwing away perfectly good data)
+ \item Element type implies polymorphism. Should it be in SV?
+ \item Should use of registers be allowed to "wrap" (x30 x31 x1 x2)?
\item Is detection of all-scalar ops ok (without slowing pipeline)?
\item Can VSELECT be removed? (it's really complex)
\item Can CLIP be done as a CSR (mode, like elwidth)
\item SIMD saturation (etc.) also set as a mode?
- \item C.MV src predication no different from dest predication\\
- What to do? Make one have different meaning?
\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?
}
+\frame{\frametitle{What's the downside(s) of SV?}
+ \begin{itemize}
+ \item EVERY register operation is inherently parallelised\\
+ (scalar ops are just vectors of length 1)\vspace{8pt}
+ \item An extra pipeline phase is pretty much essential\\
+ for fast low-latency implementations\vspace{8pt}
+ \item Assuming an instruction FIFO, N ops could be taken off\\
+ of a parallel op per cycle (avoids filling entire FIFO;\\
+ also is less work per cycle: lower complexity / latency)\vspace{8pt}
+ \item With zeroing off, skipping non-predicated elements is hard:\\
+ it is however an optimisation (and could be skipped).
+ \end{itemize}
+}
+
+
\frame{\frametitle{Is this OK (low latency)? Detect scalar-ops (only)}
\begin{center}
\includegraphics[height=2.5in]{scalardetect.png}\\
\frame{\frametitle{Summary}
\begin{itemize}
- \item Designed for flexibility (graded levels of complexity)\vspace{6pt}
- \item Huge range of implementor freedom\vspace{6pt}
- \item Fits RISC-V ethos: achieve more with less\vspace{6pt}
+ \item Actually about parallelism, not Vectors (or SIMD) per se
+ \item Designed for flexibility (graded levels of complexity)
+ \item Huge range of implementor freedom
+ \item Fits RISC-V ethos: achieve more with less
\item Reduces SIMD ISA proliferation by 3-4 orders of magnitude \\
- (without SIMD downsides or sacrificing speed trade-off)\vspace{6pt}
- \item Covers 98\% of RVV, allows RVV to fit "on top"\vspace{6pt}
+ (without SIMD downsides or sacrificing speed trade-off)
+ \item Covers 98\% of RVV, allows RVV to fit "on top"
\item Not designed for supercomputing (that's RVV), designed for
- in between: DSPs, RV32E, Embedded 3D GPUs etc.\vspace{6pt}
+ in between: DSPs, RV32E, Embedded 3D GPUs etc.
\item Not specifically designed for Vectorisation: designed to\\
reduce code size (increase efficiency, just
- like Compressed)\vspace{6pt}
+ like Compressed)
\end{itemize}
}