+[[!tag standards]]
+
# Simple-V (Parallelism Extension Proposal) Vector Block Format
* Copyright (C) 2017, 2018, 2019 Luke Kenneth Casson Leighton
-* Status: DRAFTv0.6
-* Last edited: 13 aug 2019
+* Status: DRAFTv0.7.1
+* Last edited: 2 sep 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.
+standard scalar RISC-V instructions, in a highly compact form. Program Execution Order is still preserved (unlike VLIW), just with "context" that would otherwise require much longer instructions.
The format is:
# VBLOCK Prefix
-The purpose of the VBLOCK Prefix is to specify the context in which a block of RV Scalar instructions are "vectorised" and/or predicated.
+The purpose of the VBLOCK Prefix is to specify the context in which a
+block of RV Scalar instructions are "vectorised" and/or predicated.
-As there are not very many bits available without going into a prefix format longer than 16 bits, some abbreviations are used. Two bits are dedicated to specifying whether the Register and Predicate formats are 16 or 8 bit.
+As there are not very many bits available without going into a prefix
+format longer than 16 bits, some abbreviations are used. Two bits are
+dedicated to specifying whether the Register and Predicate formats are
+16 or 8 bit.
-Also, the number of entries in each table is specified with an unusual encoding, on the basis that if registers are to be Vectorised, it is highly likely that they will be predicated as well.
+Also, the number of entries in each table is specified with an unusual
+encoding, on the basis that if registers are to be Vectorised, it is
+highly likely that they will be predicated as well.
-The VL Block is optional and also only 16 bits: this because an RVC opcode is limited by comparison.
+The VL Block is optional and also only 16 bits: this because an RVC
+opcode is limited by comparison.
The format is explained as follows:
[[!inline raw="yes" pages="simple_v_extension/swizzle_table_format" ]]
-It is still under development and will need integration into the
-main VBLOCK format
+Swizzle blocks are only accessible using the "VBLOCK2" format.
+
+# REMAP Area Format<a name="remap_format"></a>
+
+REMAP is an algorithmic version of in-place vector "vgather" or "swizzle".
+
+The REMAP area is divided into two areas:
+
+* Register-to-SHAPE. This defines which registers have which shapes.
+ Each entry is 8-bits in length.
+* SHAPE Table entries. These are 32-bits in length and are aligned
+ to (start on) a 16 bit boundary.
+
+REMAP Table Entries:
+
+| 7:5 | 4:0 |
+| -------- | ------ |
+| shapeidx | regnum |
+
+When both shapeidx and regnum are zero, this indicates the end of the
+REMAP Register-to-SHAPE section. The REMAP Table section size is then
+aligned to a 16-bit boundary. 32-bit SHAPE Table Entries then fill the
+remainder of the REMAP area, and are indexed in order by shapeidx.
+
+In this way, multiple registers may share the same "shape" characteristics.
+
+# SHAPE Table Format<a name="shape_format"></a>
+
+The shape table format is included here for convenience. See [[simple_v_extension/remap]] for full details on how SHAPE applies,
+including pseudo-code.
+
+[[!inline raw="yes" pages="simple_v_extension/shape_table_format" ]]
+
+REMAP Shape blocks are only accessible using the "VBLOCK2" format.
# CSRs:
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 |
+| 31:30 | 29 | 28:26 | 25:24 | 23:22 | 21 | 20:5 | 4:0 |
+|--------|-------|-------|-------|-------|------|---------|-------|
+| status | vlset | 16xil | pplen | rplen | mode | vblock2 | opptr |
+| 2 | 1 | 3 | 2 | 2 | 1 | 16 | 5 |
* status is the key field that effectively exposes the inner FSM (Finite
State Machine) directly.
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
+* 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).
+ read again from the instruction stream, and that VBLOCK2 has also been
+ read and stored, if 16xil was equal to 0b111.
+* status=0b10 indicates that the VL Block has been read from the instruction
+ stream and actioned. (This means that a SETVL instruction has been
+ created and executed). It also indicates that reading of the
+ Predicate, Register and Swizzle Blocks are now being read.
* 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.
+ 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).
+ the start of the opcodes
+ (not the start of the VBLOCK),
+ 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
and Register Context destroyed (Note: the STATE CSR is **not** altered
purely by exit from a VBLOCK Context).
+During the transition from status=0b00 to status=0b01, it is assumed
+that the instruction stream is being read at a mininum of 32 bits at
+a time. Therefore it is reasonable to expect that VBLOCK2 would be
+successfully read simultaneously with the initial VBLOCK header.
+For this reason there is no separate state in the FSM for updating
+of the vblock2 field in PCVBLK.
+
+When the transition from status=0b01 to status=0b10 occurs, actioning the
+VL Block state *actually* and literally **must** be as if a SETVL instruction
+had occurred. This can result in updating of the VL and MVL CSRs (and
+the VL destination register target). Note, below, that this means that
+a context-switch may save/restore VL and MVL (and the integer register file),
+where the remaining tables have no such opportunity.
+
+When status=0b10, and before status=0b11, there is no external indicator
+as to how far the hardware has got in the process of reading the
+Predicate, Register, and Swizzle Blocks. Implementations are free to use
+any internal means to track progress, however given that if a trap occurs
+the read process will need to be restarted (in simpler implementations),
+there is no point having external indicators of progress. By complete
+contrast, given that a SETVL actually writes to VL (and MVL), the VL
+Block state *has* been actioned and thus would be successfully restored
+by a context-switch.
+
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
+in normal RISC-V execution. 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.
+instruction exception. To be clear: CSRRWI PCVBLK does **not** have the same
+behaviour as CSRRW PCVBLK.
-In privileged modes, obviously the above rules do not apply to the
-completely seoarate (x)ePCVBLK CSRs because these are copies of state,
+In privileged modes, obviously the above rules do not apply to the completely
+separate (x)ePCVBLK CSRs because these are (inactive) *copies* of state,
not the actual active PCVBLK. Writing to PCVBLK during a trap however,
clearly the rules must apply.
returning to "normal" standard RV mode, and then using standard RVC,
32 bit or P48/64-\*-type opcodes.
+The exception to this rule is if the branch or jump within the VBLOCK is back to the start of the same VBLOCK. If this is used, the VBLOCK is, clearly, to be re-executed, including any optional VL blocks and any predication, register table context etc.
+
+Given however that the tables are already established, it is only the VL block that needs to be re-run. The other tables may be left as-is.
+
# Links
* <https://groups.google.com/d/msg/comp.arch/yIFmee-Cx-c/jRcf0evSAAAJ>
projects / libreriscv.git / blobdiff