From: lkcl <lkcl@web>
Date: Sat, 24 Sep 2022 23:11:45 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~309
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d9dee5eb04dc5b3053507e50daee06021aaff418;p=libreriscv.git

---

diff --git a/openpower/sv/overview/discussion.mdwn b/openpower/sv/overview/discussion.mdwn
index d9d001235..2c488eabb 100644
--- a/openpower/sv/overview/discussion.mdwn
+++ b/openpower/sv/overview/discussion.mdwn
@@ -177,3 +177,36 @@ has to be solved in the ISACaller Simulator when elwidth overrides are
 completed (recall that the ISACaller Simulator uses a python class where
 numbers are indeed strict MSB0 defined, arithmetically).
 
+# Architecturally LE Regfile
+
+The meaning of "Architecturally" is that the programmer sees one definition,
+where that definition has absolutely no connection or imposition on precisely
+how the implementation is implemented (internally), **except** to comply with
+the definition as far as **external** usage is concerned (programs).
+
+This is the *canonical* Architectural definition of the regfile
+asuming a Little-Endian system, in the c programming language:
+
+    #pragma pack
+    typedef union {
+        uint8_t  b[];
+        uint16_t s[];
+        uint32_t i[];
+        uint64_t l[];
+        uint8_t actual_bytes[8];
+    } el_reg_t;
+
+    elreg_t int_regfile[128];
+
+Where things become complicated is how to transliterate the above into
+MSB0 numbering.  We start with some definitions:
+
+* bit-ordering below is in MSB0 order, prefix "b"
+* byte-ordering is in MSB0 order, prefix "B"
+* register-numbering is in **LSB0** order, prefix "r"
+* element-numbering is in **LSB0** order, prefix "e"
+
+First we define the contents of 64-bit registers:
+
+    r0 : | b0 b1 b2 b3 b4 b5 b6 b7 | ... | b56 b57 b58 b59 b60 b61 b62 b63 |
+         |        B0               | ... |  B7                             |