update to rst table format

[libreriscv.git] / simple_v_extension / vblock_format.mdwn

# Simple-V (Parallelism Extension Proposal) Vector Block Format

* Copyright (C) 2017, 2018, 2019 Luke Kenneth Casson Leighton
* Status: DRAFTv0.6
* Last edited: 28 jun 2019

[[!toc ]]

# Vector Block Format <a name="vliw-format"></a>

This is a way to give Vector and Predication Context to a group of
standard scalar RISC-V instructions, in a highly compact form.

The format is:

* the standard RISC-V 80 to 192 bit encoding sequence, with bits
  defining the options to follow within the block
* An optional VL Block (16-bit)
* Optional predicate entries (8/16-bit blocks: see Predicate Table, above)
* Optional register entries (8/16-bit blocks: see Register Table, above)
* finally some 16/32/48 bit standard RV or SVPrefix opcodes follow.

Thus, the variable-length format from Section 1.5 of the RISC-V ISA is used
as follows:

[[!inline raw="yes" pages="simple_v_extension/vblock_format_table" ]]

Note: this format is very similar to that used in [[sv_prefix_proposal]]

If vlt is 0, VLEN is a 5 bit immediate value, offset by one (i.e
a bit sequence of 0b00000 represents VL=1 and so on). If vlt is 1,
it specifies the scalar register from which VL is set by this VBLOCK
instruction group. VL, whether set from the register or the immediate,
is then modified (truncated) to be MIN(VL, MAXVL), and the result stored
in the scalar register specified in VLdest. If VLdest is zero, no store
in the regfile occurs (however VL is still set).

This option will typically be used to start vectorised loops, where
the VBLOCK instruction effectively embeds an optional "SETSUBVL, SETVL"
sequence (in compact form).

When bit 15 is set to 1, MAXVL and VL are both set to the immediate,
VLEN (again, offset by one), which is 6 bits in length, and the same
value stored in scalar register VLdest (if that register is nonzero).
A value of 0b000000 will set MAXVL=VL=1, a value of 0b000001 will
set MAXVL=VL= 2 and so on.

This option will typically not be used so much for loops as it will be
for one-off instructions such as saving the entire register file to the
stack with a single one-off Vectorised and predicated LD/ST, or as a way
to save or restore registers in a function call with a single instruction.

Notes:

* Bit 7 specifies if the prefix block format is the full 16 bit format
  (1) or the compact less expressive format (0). In the 8 bit format,
  pplen is multiplied by 2.
* 8 bit format predicate numbering is implicit and begins from x9. Thus
  it is critical to put blocks in the correct order as required.
* Bit 7 also specifies if the register block format is 16 bit (1) or 8 bit
  (0). In the 8 bit format, rplen is multiplied by 2. If only an odd number
  of entries are needed the last may be set to 0x00, indicating "unused".
* Bit 15 specifies if the VL Block is present. If set to 1, the VL Block
  immediately follows the VBLOCK instruction Prefix
* Bits 8 and 9 define how many RegCam entries (0 to 3 if bit 15 is 1,
  otherwise 0 to 6) follow the (optional) VL Block.
* Bits 10 and 11 define how many PredCam entries (0 to 3 if bit 7 is 1,
  otherwise 0 to 6) follow the (optional) RegCam entries
* Bits 14 to 12 (IL) define the actual length of the instruction: total
  number of bits is 80 + 16 times IL.  Standard RV32, RVC and also
  SVPrefix (P48/64-\*-Type) instructions fit into this space, after the
  (optional) VL / RegCam / PredCam entries
* In any RVC or 32 Bit opcode, any registers within the VBLOCK-prefixed
  format *MUST* have the RegCam and PredCam entries applied to the
  operation (and the Vectorisation loop activated)
* P48 and P64 opcodes do **not** take their Register or predication
  context from the VBLOCK tables: they do however have VL or SUBVL
  applied (unless VLtyp or svlen are set).
* At the end of the VBLOCK Group, the RegCam and PredCam entries
  *no longer apply*.  VL, MAXVL and SUBVL on the other hand remain at
  the values set by the last instruction (whether a CSRRW or the VL
  Block header).
* Although an inefficient use of resources, it is fine to set the MAXVL,
  VL and SUBVL CSRs with standard CSRRW instructions, within a VBLOCK.

All this would greatly reduce the amount of space utilised by Vectorised
instructions, given that 64-bit CSRRW requires 3, even 4 32-bit opcodes:
the CSR itself, a LI, and the setting up of the value into the RS
register of the CSR, which, again, requires a LI / LUI to get the 32
bit data into the CSR.  To get 64-bit data into the register in order
to put it into the CSR(s), LOAD operations from memory are needed!

Given that each 64-bit CSR can hold only 4x PredCAM entries (or 4 RegCAM
entries), that's potentially 6 to eight 32-bit instructions, just to
establish the Vector State!

Not only that: even CSRRW on VL and MAXVL requires 64-bits (even more
bits if VL needs to be set to greater than 32).  Bear in mind that in SV,
both MAXVL and VL need to be set.

By contrast, the VBLOCK prefix is only 16 bits, the VL/MAX/SubVL block is
only 16 bits, and as long as not too many predicates and register vector
qualifiers are specified, several 32-bit and 16-bit opcodes can fit into
the format. If the full flexibility of the 16 bit block formats are not
needed, more space is saved by using the 8 bit formats.

In this light, embedding the VL/MAXVL, PredCam and RegCam CSR entries
into a VBLOCK format makes a lot of sense.

Bear in mind the warning in an earlier section that use of VLtyp or svlen
in a P48 or P64 opcode within a VBLOCK Group will result in corruption
(use) of the STATE CSR, as the STATE CSR is shared with SVPrefix. To
avoid this situation, the STATE CSR may be copied into a temp register
and restored afterwards.

# Register Table Format

The register table format is covered in the main [[specification]],
included here for convenience:

[[!inline raw="yes" pages="simple_v_extension/reg_table_format" ]]

# Predicate Table Format

The predicate table format is covered in the main [[specification]],
included here for convenience:

[[!inline raw="yes" pages="simple_v_extension/pred_table_format" ]]

# CSRs:

The CSRs needed, in addition to those from the main [[specification]] are:

* pcvblk
* mepcvblk
* sepcvblk
* uepcvblk
* hepcvblk

To greatly simplify implementations, which would otherwise require a
way to track (cache) VBLOCK instructions, it is required to treat the
VBLOCK group as a separate sub-program with its own separate PC. The
sub-pc advances separately whilst the main PC remains "frozen", pointing
at the beginning of the VBLOCK instruction (not to be confused with how
VL works, which is exactly the same principle, except it is VStart in
the STATE CSR that increments).

This has implications, namely that a new set of CSRs identical to (x)epc
(mepc, srpc, hepc and uepc) must be created and managed and respected
as being a sub extension of the (x)epc set of CSRs.  Thus, (x)epcvblk CSRs
must be context switched and saved / restored in traps.

The srcoffs and destoffs indices in the STATE CSR may be similarly
regarded as another sub-execution context, giving in effect two sets of
nested sub-levels of the RISCV Program Counter (actually, three including
SUBVL and ssvoffs).

# PCVBLK CSR Format

Using PCVBLK to store the progression of decoding and subsequent execution of opcodes in a VBLOCK allows a simple single issue design to only need to fetch 32 or 64 bits from the instruction cache on any given clock cycle.

*(This approach also alleviates one of the main concerns with the VBLOCK Format: unlike a VLIW engine, a FSM no longer requires full buffering of the entire VBLOCK opcode in order to begin execution. Future versions may therefore potentially lift the 192 bit limit).*

To support this option (where more complex implementations may skip some of these phases), VBLOCK contains partial decode state, that allows a trap to occur even part-way through decode, in order to reduce latency.

The format is as follows:

| 31:30  | 29    | 28:26 | 25:24 | 23:22 | 21   | 20:5  | 4:0   |
|--------|-------|-------|-------|-------|------|-------|-------|
| status | vlset | 16xil | pplen | rplen | mode | vlblk | opptr |
| 2      | 1     | 3     | 2     | 2     | 1    | 16    | 5     |

* status is the key field that effectively exposes the inner FSM (Finite State Machine) directly.
* status = 0b00 indicates that the processor is not in "VBLOCK Mode". It is instead in standard RV Scalar opcode execution mode. The processor will leave this mode only after it encounters the beginning of a valid VBLOCK opcode.
* status = 0b01 indicates that vlset, 16xil, pplen, rplen and mode have all been copied directly from the VBLOCK so that they do not need to be read again from the instruction stream.
* status=0b10 indicates that the VL Block has been read from the instruction stream and decoded (and copied into vlblk).
* status=0b11 indicates that the Predicate and Register Blocks have been read from the instruction stream (and put into internal Vector Context)  Simpler implementations are permitted to reset status back to 0b10 and re-read the data after return from a trap that happened to occur in the middle of a VBLOCK. They are not however permitted to destroy opptr in the process, and after re-reading the Predicate and Register Blocks must resume execution pointed to by  opptr.
* opptr points to where instructions begin in the VBLOCK. 0 indicates the start of the opcodes, and is in multiples of 16 bits (2 bytes).  This is the equivalent of a Program Counter, for VBLOCKs.
* at the end of a VBLOCK, when the last instruction executes (assuming it does not change opptr to earlier in the block), status is reset to 0b00 to indicate exit from the VBLOCK FSM, and the current Vector Predicate and Register Context destroyed (Note: the STATE CSR is **not** altered purely by exit from a VBLOCK Context).

When status=0b11, opptr may be written to using CSRRWI. Doing so will cause execution to jump within the block, exactly as if PC had been set in normal RISC-V eexecution. Writing a value outside of the range of the instruction block will cause an illegal instruction exception. Writing a value (any value) when status is not 0b11 likewise causes an illegal instruction exception.

In privileged modes, obviously the above rules do not apply to the completely seoarate (x)ePCVBLK CSRs because these are copies of state, not the actual active PCVBLK. Writing to PCVBLK during a trap however, clearly the rules must apply.

If PCVBLK is written to with CSRRW, the same rules apply, however the entire register in rs1 is treated as the new opptr.

Note that the value returned in the register rd is the *full* PCVBLK, not just the opptr part.

# Limitations on instructions

As the pcvblk CSR is relative to the beginning of the VBLOCK,
branch and jump opcodes MUST NOT be used to point to a location inside a block: only at the beginning of an opcode (including another VBLOCK, including the current one). However, setting the PCVBLK CSR is permitted, to unconditionally jump to any opcode within a block.

Also: calling subroutines is likewise not permitted, because PCVBLK context cannot be atomically reestablished on return from the function.

ECALL, on the other hand, which will cause a trap that saves and restores the full state, is permitted.

Prohibited instructions will cause an illegal instruction trap. If at that point, software is capable of then working out how to emulate a branch or function call successfully, by manipulating (x)ePCVBLK and other state, it is not prohibited from doing so.

To reiterate: a normal jump, normal conditional branch and a normal function call may only be taken
by letting the VBLOCK group finish, returning to "normal" standard RV mode,
and then using standard RVC, 32 bit or P48/64-\*-type opcodes.

# Links

* <https://groups.google.com/d/msg/comp.arch/yIFmee-Cx-c/jRcf0evSAAAJ>

# Open Questions:

* Is it necessary to stick to the RISC-V 1.5 format?  Why not go with
  using the 15th bit to allow 80 + 16\*0bnnnn bits?  Perhaps to be sane,
  limit to 256 bits (16 times 0-11).
* Could a "hint" be used to set which operations are parallel and which
  are sequential?
* Could a new sub-instruction opcode format be used, one that does not
  conform precisely to RISC-V rules, but *unpacks* to RISC-V opcodes?
  no need for byte or bit-alignment
* Could a hardware compression algorithm be deployed?  Quite likely,
  because of the sub-execution context (sub-VBLOCK PC)