simple_v_extension/vblock_format.mdwn

   1 # Simple-V (Parallelism Extension Proposal) Vector Block Format
   2
   3 * Copyright (C) 2017, 2018, 2019 Luke Kenneth Casson Leighton
   4 * Status: DRAFTv0.6
   5 * Last edited: 21 jun 2019
   6
   7 [[!toc ]]
   8
   9 # Vector Block Format <a name="vliw-format"></a>
  10
  11 This is a way to give Vector and Predication Context to a group of
  12 standard scalar RISC-V instructions, in a highly compact form.
  13
  14 The format is:
  15
  16 * the standard RISC-V 80 to 192 bit encoding sequence, with bits
  17   defining the options to follow within the block
  18 * An optional VL Block (16-bit)
  19 * Optional predicate entries (8/16-bit blocks: see Predicate Table, above)
  20 * Optional register entries (8/16-bit blocks: see Register Table, above)
  21 * finally some 16/32/48 bit standard RV or SVPrefix opcodes follow.
  22
  23 Thus, the variable-length format from Section 1.5 of the RISC-V ISA is used
  24 as follows:
  25
  26 [[!inline raw="yes" pages="simple_v_extension/vblock_table_format" ]]
  27
  28 Note: this format is very similar to that used in [[sv_prefix_proposal]]
  29
  30 If vlt is 0, VLEN is a 5 bit immediate value, offset by one (i.e
  31 a bit sequence of 0b00000 represents VL=1 and so on). If vlt is 1,
  32 it specifies the scalar register from which VL is set by this VBLOCK
  33 instruction group. VL, whether set from the register or the immediate,
  34 is then modified (truncated) to be MIN(VL, MAXVL), and the result stored
  35 in the scalar register specified in VLdest. If VLdest is zero, no store
  36 in the regfile occurs (however VL is still set).
  37
  38 This option will typically be used to start vectorised loops, where
  39 the VBLOCK instruction effectively embeds an optional "SETSUBVL, SETVL"
  40 sequence (in compact form).
  41
  42 When bit 15 is set to 1, MAXVL and VL are both set to the immediate,
  43 VLEN (again, offset by one), which is 6 bits in length, and the same
  44 value stored in scalar register VLdest (if that register is nonzero).
  45 A value of 0b000000 will set MAXVL=VL=1, a value of 0b000001 will
  46 set MAXVL=VL= 2 and so on.
  47
  48 This option will typically not be used so much for loops as it will be
  49 for one-off instructions such as saving the entire register file to the
  50 stack with a single one-off Vectorised and predicated LD/ST, or as a way
  51 to save or restore registers in a function call with a single instruction.
  52
  53 CSRs needed:
  54
  55 * mepcvblk
  56 * sepcvblk
  57 * uepcvblk
  58 * hepcvblk
  59
  60 Notes:
  61
  62 * Bit 7 specifies if the prefix block format is the full 16 bit format
  63   (1) or the compact less expressive format (0). In the 8 bit format,
  64   pplen is multiplied by 2.
  65 * 8 bit format predicate numbering is implicit and begins from x9. Thus
  66   it is critical to put blocks in the correct order as required.
  67 * Bit 7 also specifies if the register block format is 16 bit (1) or 8 bit
  68   (0). In the 8 bit format, rplen is multiplied by 2. If only an odd number
  69   of entries are needed the last may be set to 0x00, indicating "unused".
  70 * Bit 15 specifies if the VL Block is present. If set to 1, the VL Block
  71   immediately follows the VBLOCK instruction Prefix
  72 * Bits 8 and 9 define how many RegCam entries (0 to 3 if bit 15 is 1,
  73   otherwise 0 to 6) follow the (optional) VL Block.
  74 * Bits 10 and 11 define how many PredCam entries (0 to 3 if bit 7 is 1,
  75   otherwise 0 to 6) follow the (optional) RegCam entries
  76 * Bits 14 to 12 (IL) define the actual length of the instruction: total
  77   number of bits is 80 + 16 times IL.  Standard RV32, RVC and also
  78   SVPrefix (P48/64-\*-Type) instructions fit into this space, after the
  79   (optional) VL / RegCam / PredCam entries
  80 * In any RVC or 32 Bit opcode, any registers within the VBLOCK-prefixed
  81   format *MUST* have the RegCam and PredCam entries applied to the
  82   operation (and the Vectorisation loop activated)
  83 * P48 and P64 opcodes do **not** take their Register or predication
  84   context from the VBLOCK tables: they do however have VL or SUBVL
  85   applied (unless VLtyp or svlen are set).
  86 * At the end of the VBLOCK Group, the RegCam and PredCam entries
  87   *no longer apply*.  VL, MAXVL and SUBVL on the other hand remain at
  88   the values set by the last instruction (whether a CSRRW or the VL
  89   Block header).
  90 * Although an inefficient use of resources, it is fine to set the MAXVL,
  91   VL and SUBVL CSRs with standard CSRRW instructions, within a VBLOCK.
  92
  93 All this would greatly reduce the amount of space utilised by Vectorised
  94 instructions, given that 64-bit CSRRW requires 3, even 4 32-bit opcodes:
  95 the CSR itself, a LI, and the setting up of the value into the RS
  96 register of the CSR, which, again, requires a LI / LUI to get the 32
  97 bit data into the CSR.  To get 64-bit data into the register in order
  98 to put it into the CSR(s), LOAD operations from memory are needed!
  99
 100 Given that each 64-bit CSR can hold only 4x PredCAM entries (or 4 RegCAM
 101 entries), that's potentially 6 to eight 32-bit instructions, just to
 102 establish the Vector State!
 103
 104 Not only that: even CSRRW on VL and MAXVL requires 64-bits (even more
 105 bits if VL needs to be set to greater than 32).  Bear in mind that in SV,
 106 both MAXVL and VL need to be set.
 107
 108 By contrast, the VBLOCK prefix is only 16 bits, the VL/MAX/SubVL block is
 109 only 16 bits, and as long as not too many predicates and register vector
 110 qualifiers are specified, several 32-bit and 16-bit opcodes can fit into
 111 the format. If the full flexibility of the 16 bit block formats are not
 112 needed, more space is saved by using the 8 bit formats.
 113
 114 In this light, embedding the VL/MAXVL, PredCam and RegCam CSR entries
 115 into a VBLOCK format makes a lot of sense.
 116
 117 Bear in mind the warning in an earlier section that use of VLtyp or svlen
 118 in a P48 or P64 opcode within a VBLOCK Group will result in corruption
 119 (use) of the STATE CSR, as the STATE CSR is shared with SVPrefix. To
 120 avoid this situation, the STATE CSR may be copied into a temp register
 121 and restored afterwards.
 122
 123 Open Questions:
 124
 125 * Is it necessary to stick to the RISC-V 1.5 format?  Why not go with
 126   using the 15th bit to allow 80 + 16\*0bnnnn bits?  Perhaps to be sane,
 127   limit to 256 bits (16 times 0-11).
 128 * Could a "hint" be used to set which operations are parallel and which
 129   are sequential?
 130 * Could a new sub-instruction opcode format be used, one that does not
 131   conform precisely to RISC-V rules, but *unpacks* to RISC-V opcodes?
 132   no need for byte or bit-alignment
 133 * Could a hardware compression algorithm be deployed?  Quite likely,
 134   because of the sub-execution context (sub-VBLOCK PC)
 135
 136 ## Limitations on instructions.
 137
 138 To greatly simplify implementations, it is required to treat the VBLOCK
 139 group as a separate sub-program with its own separate PC. The sub-pc
 140 advances separately whilst the main PC remains pointing at the beginning
 141 of the VBLOCK instruction (not to be confused with how VL works, which
 142 is exactly the same principle, except it is VStart in the STATE CSR
 143 that increments).
 144
 145 This has implications, namely that a new set of CSRs identical to xepc
 146 (mepc, srpc, hepc and uepc) must be created and managed and respected
 147 as being a sub extension of the xepc set of CSRs.  Thus, xepcvblk CSRs
 148 must be context switched and saved / restored in traps.
 149
 150 The srcoffs and destoffs indices in the STATE CSR may be similarly
 151 regarded as another sub-execution context, giving in effect two sets of
 152 nested sub-levels of the RISCV Program Counter (actually, three including
 153 SUBVL and ssvoffs).
 154
 155 In addition, as xepcvblk CSRs are relative to the beginning of the VBLOCK,
 156 branches MUST be restricted to within (relative to) the block,
 157 i.e. addressing is now restricted to the start (and very short) length
 158 of the block.
 159
 160 Also: calling subroutines is inadviseable, unless they can be entirely
 161 accomplished within a block.
 162
 163 A normal jump, normal branch and a normal function call may only be taken
 164 by letting the VBLOCK group end, returning to "normal" standard RV mode,
 165 and then using standard RVC, 32 bit or P48/64-\*-type opcodes.
 166
 167 ## Links
 168
 169 * <https://groups.google.com/d/msg/comp.arch/yIFmee-Cx-c/jRcf0evSAAAJ>
 170