From: lkcl <lkcl@web>
Date: Sun, 23 Jun 2019 18:35:02 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: convert-csv-opcode-to-binary~4518
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=2c59a34348447ed751e2be9fd7dbcf868a204dcc;p=libreriscv.git

---

diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn
index c24340946..6ad8f0a8f 100644
--- a/simple_v_extension/specification.mdwn
+++ b/simple_v_extension/specification.mdwn
@@ -2330,8 +2330,10 @@ Notes:
   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
-* Anything - any registers - within the VLIW-prefixed format *MUST* have the
-  RegCam and PredCam entries applied to it.
+* In any RVC or 32 Bit opcode, any registers within the VLIW-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 VLIW Block tables: they do however have VL or SUBVL applied (unless VLtyp or svlen are set).
 * At the end of the VLIW 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
@@ -2363,6 +2365,8 @@ 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 VLIW 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 VLIW 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.
+
 Open Questions:
 
 * Is it necessary to stick to the RISC-V 1.5 format?  Why not go with