+| 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.
+* 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, 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.
+* opptr points to where instructions begin in the VBLOCK. 0 indicates
+ 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
+ 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).
+
+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 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. 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
+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.
+
+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.