(no commit message)

diff --git a/3d_gpu/architecture/decoder.mdwn b/3d_gpu/architecture/decoder.mdwn
index daff5b6a621e3d9349dc4310f2d827ad4cb39d8b..e340bd143d6ea4682463028a33ae80f81fac32ba 100644 (file)
--- a/3d_gpu/architecture/decoder.mdwn
+++ b/3d_gpu/architecture/decoder.mdwn
@@ -2,7 +2,7 @@
 
 <http://bugs.libre-riscv.org/show_bug.cgi?id=186>
 
-The decoder is in charge of translating the RISCV or POWER instruction stream into operations that can be handled by our backend. It will have an extra input bit, set via a MSR that will switch which architecture it treats an instruction as.
+The decoder is in charge of translating the POWER instruction stream into operations that can be handled by our backend. It will have an extra input bit, set via a MSR, that will switch on GPU instructions.
 
 Source code: <https://git.libre-riscv.org/?p=soc.git;a=tree;f=src/soc/decoder;hb=HEAD>
 
@@ -12,6 +12,34 @@ The decoder has been written in python, to parse straight CSV files and other in
 
 The top level decoder object recursively drops through progressive levels of case statement groups, covering additional portions of the incoming instruction bits.  More on this technique - for which python and nmigen were *specifically* and strategically chosen - is outlined here <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/004882.html>
 
+## Link to Function Units
+
+The Decoder (PowerDecode2) knows which registers are needed, however what
+it does not know is:
+
+* which Register file ports to connect to (this is defined by regspecs)
+* the order of those regfile ports (again: defined by regspecs)
+
+Neither do the Phase-aware Function Units (derived from MultiCompUnit)
+themselves know anything about the PowerDecoder, and they certainly
+do not know when a given instruction will need to tell *them* to read
+RA, or RB.  For example: negation of RA only requires one operand,
+where add RA, RB requires two.  Who tells whom that information, when
+the ALU's job is simply to add, and the Decoder's job is simply to decode?
+
+This is where a special function called "rdflags()" comes into play.
+rdflags works closely in conjunction with regspecs and the PowerDecoder2,
+in each Function Unit's "pipe\_data.py" file.  It defines the flags that
+determine, from current instruction, whether the Function Unit actually
+*wants* any given Register Read Ports activated or not.
+
+That dynamically-determined information will then actively disable
+(or allow) Register file Read requests (rd.req) on a per-port basis.
+
+* [[architecture/regfiles]]
+* [CompUnits](https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/compunits/compunits.py;hb=HEAD)
+* [ALU pipe_data.py specification](https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/alu/pipe_data.py;hb=HEAD)
+
 ## Fixed point instructions
 
  - `addi`, `addis`, `mulli` - fairly straightforward - extract registers and immediate and translate to the appropriate op
@@ -23,7 +51,3 @@ The top level decoder object recursively drops through progressive levels of cas
  - `and*`, `or*`, `xor*`, `nand*`, `eqv*`, `andc*`, `orc*` - similar to the register-register arithmetic instructions above
 
 
-# RISCV
-
-To save time, using minerva will help enormously
-<https://github.com/lambdaconcept/minerva>