openpower/sv/rfc/ls001.mdwn

   1 [[!tag opf_rfc]]
   2
   3 # OpenPOWER Foundation External RFC LS001
   4
   5 Links
   6
   7 * <https://libre-soc.org/openpower/sv/>
   8 * <https://libre-soc.org/openpower/sv/compliancy_levels/>
   9 * <https://libre-soc.org/openpower/transcendentals/>
  10 * <https://libre-soc.org/openpower/sv/bitmanip>
  11 * <https://libre-soc.org/openpower/sv/int_fp_mv>
  12 * <https://libre-soc.org/openpower/sv/fclass/>
  13 * <https://libre-soc.org/openpower/sv/av_opcodes/>
  14 * <https://libre-soc.org/openpower/sv/fcvt/>
  15 * <https://libre-soc.org/openpower/sv/cr_int_predication/>
  16 * <https://libre-soc.org/openpower/sv/biginteger/>
  17
  18 # Introduction to Simple-V
  19
  20 This proposal is to extend the Power ISA with an Abstract RISC-Paradigm
  21 Vectorisation Concept that may be applied to **all and any** suitable
  22 Scalar instructions, present and future, in the Scalar Power ISA.
  23 **It is not a Vector ISA and does not add Vector opcodes of any kind**.
  24 A variant of Simple-V was originally invented in 1994 by Peter Hsu
  25 (Architect of the MIPS R8000) but was dropped as MIPS did not have an
  26 Out-of-Order Microarchitecture.
  27
  28 Simple-V is designed for Embedded Scenarios right the way through
  29 Audio/Visual DSPs to 3D GPUs and Supercomputing.  As it does **not**
  30 add actual Vector Instructions, relying solely and exclusively on the
  31 **Scalar** ISA, it is **Scalar** instructions that need to be added
  32 to the **Scalar** Power ISA before Simple-V may orthogonally Vectorise
  33 them.
  34
  35 Therefore because the goal of RED Semiconductor Ltd, an OpenPOWER Stakeholder,
  36 is to bring to market mass-volume general-purpose compute processors that
  37 are competitive in the 3D GPU Audio Visual DSP EDGE IoT markets, Simple-V
  38 has to be accompanied by corresponding **Scalar** instructions that bring
  39 the **Scalar** Power ISA up-to-date.  These include IEEE754 Transcendentals
  40 AV cryptographic Biginteger and bitmanipulation operations that ARM Intel
  41 AMD and many other ISAs have been adding over the past 12 years.
  42
  43 *Thus it becomes necesary to consider the Architectural Resource Allocation of not just
  44 Simple-V but the 80-100 Scalar instructions all at the same time*.
  45
  46 It is also critical to note that Simple-V **does not modify the Scalar Power ISA
  47 in any way**. There is one sole semi-exception to that (Vectorised Branch Conditional)
  48 in order to provide the usual capability present in every Commercial 3D GPU ISA.
  49
  50 # Compliancy Levels
  51
  52 Simple-V has been subdivided into levels akin to the Power ISA Compliancy Levels.
  53 For now Let us call them "SV Compliancy Levels" to distinguish the two.  The reason for
  54 the SV Compliancy Levels is the same as for the Power ISA Compliancy Levels (SFFS, SFS):
  55 to not overburden implementors with features that they do not need.
  56 *There is no dependence between the two types of Compliancy Levels*
  57
  58 The resources below therefore are not all required for all SV Compliancy Levels but
  59 they are all required to be reserved.
  60
  61 # Simple-V Architectural Resources
  62
  63 * No new Interrupt types are required.
  64 * GPR FPR and CR Field Register numbers are extended to 128.
  65   A future version may extend to 256 or beyond [^extend]
  66 * (A future version or other Stakeholder *may* wish to drop Simple-V
  67   onto VSX: extension of the number of VSX registers will be discussed at that
  68   time)
  69 * 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO)
  70 * Another 24-bit (a second 2-bit XO) is needed for a planned future encoding, currently
  71   named "SVP64-Single" [^likeext001]
  72 * A third 24-bits (third 2-bit XO) is strongly recommended to be **reserved**
  73   such that future unforeseen capability is needed.
  74 * To hold all Vector Context, five SPRs are needed for userspace (MSR.PR=1 Problem State).
  75   If Supervisor and Hypervisor mode are to also support Simple-V they will correspondingly
  76   need five SPRs each.
  77 * Five 6-bit XO (A-Form) "Management" instructions are needed.
  78
  79 **Summary of Opcode space**
  80
  81 * 75% of one Major Opcode (equivalent to the rest of EXT017)
  82 * Five 6-bit operations.
  83
  84 No further opcode space *for Simple-V* is envisaged to be required for at least
  85 the next decade.
  86
  87 **SPRs**
  88
  89 * **SVSTATE** - Vectorisation State
  90 * **SVSRR0** - identical in purpose to SRR0/1, storing SVSTATE on context-switch
  91 * **SVSHAPE0-3* - these are 32-bit and may be grouped in pairs, they REMAP (shape)
  92   the Vectors
  93 * **SVLR** - again similar to LR for exactly the same purpose, SVSTATE is swapped
  94   with SVLR by SV-Branch-Conditional for exactly the same reason that NIA is swapped
  95   with LR
  96
  97 * Vector Management Instructions
  98
  99 * **setvl** - Cray-style Scalar Vector Length instruction
 100 * **svstep** - used for Vertical-First Mode and for enquiring about internal state
 101 * **svremap** - "tags" registers for activating REMAP
 102 * **svshape** - convenience instruction for quickly setting up Matrix, DCT, FFT and
 103   Parallel Reduction REMAP
 104 * **svshape2** - additional convenience instruction to set up "Offset" REMAP
 105   (fits within svshape's XO encoding)
 106 * **svindex** - convenience instruction for setting up "Indexed" REMAP.
 107
 108 # SVP64 24-bit Prefix
 109
 110 The SVP64 24-bit Prefix provides several options, too numerous to describe in this
 111 document. The primary options are:
 112
 113 * element-width overrides, which dynamically redefine each SFFS or SFS Scalar prefixed
 114   instruction to be 8-bit, 16-bit, 32-bit or 64-bit operands **without requiring new
 115   8/16/32 instructions** [^pseudorewrite]
 116
 117 * Due to a concept called "Element-width Overrides
 118
 119
 120 [^extend]: Prefix opcode space **must** be reserved in advance to do so, in order to avoid the catastrophic binary-incompatibility mistake made by RISC-V RVV and ARM SVE/2
 121 [^likeext001]: SVP64-Single is remarkably similar to the "bit 1" of EXT001 being set to indicate that the 64-bits is to be allocated in full to a new encoding, but in fact it still embeds v3.0 Scalar operations.
 122 [^pseudorewrite] elwidth overrides does however mean that all SFS / SFFS pseudocode will need rewriting to be in terms of XLEN. This has the indirect side-effect of automatically making a 32-bit Scalar Power ISA Specification possible, as well as a future 128-bit one (Cross-reference: RISC-V RV32 and RV128)