From dfb0f5aa6695afe2bb12f517e656c2a939a4a5ec Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 3 May 2020 22:31:03 +0100 Subject: [PATCH] whitespace --- 3d_gpu/architecture/6600scoreboard.mdwn | 57 +++++++++++++++---------- 1 file changed, 35 insertions(+), 22 deletions(-) diff --git a/3d_gpu/architecture/6600scoreboard.mdwn b/3d_gpu/architecture/6600scoreboard.mdwn index 2c5846a78..f0076fa67 100644 --- a/3d_gpu/architecture/6600scoreboard.mdwn +++ b/3d_gpu/architecture/6600scoreboard.mdwn @@ -29,32 +29,32 @@ the reason i feel that the weirdness exists is for a few reasons: hazards that allow reads to proceed. * fifth: the ComputationUnits still need to "manage" the input and output of those resources to actual pipelines (or FSMs). - - (a) the CUs are *not* permitted to blithely say, if there is an - expected output that also needs managing "ok i got the inputs, now throw - them at the pipeline, i'm done".  they *must* wait for that result.  of - course if there is no result to wait for, they're permitted to indicate + - (a) the CUs are *not* permitted to blithely say, if there is an + expected output that also needs managing "ok i got the inputs, now throw + them at the pipeline, i'm done".  they *must* wait for that result.  of + course if there is no result to wait for, they're permitted to indicate "done" without waiting (this actually happens in the case of STORE). - - (b) there's an apparent disconnect between "fetching of registers" - and "Computational Unit progress".  surely, one feels, there should - be something that, again, "orders the CU to proceed in a set, orderly - progressive fashion?".  instead, because the progress is from the -*absence* of hazards, the CU's FSMs likewise make forward progress from -the "acknowledgement" of each blockage being dropped. + - (b) there's an apparent disconnect between "fetching of registers" + and "Computational Unit progress".  surely, one feels, there should + be something that, again, "orders the CU to proceed in a set, orderly + progressive fashion?".  instead, because the progress is from the + *absence* of hazards, the CU's FSMs likewise make forward progress from + the "acknowledgement" of each blockage being dropped. * sixth: one of the incredible but puzzling things is that register renaming is *automatically* built-in to the design.  the Function Unit's input and output latches are effectively "nameless" registers. - (a) the more Function Units you have, the more nameless registers - exist.  the more nameless registers exist, the further ahead that + exist.  the more nameless registers exist, the further ahead that in-flight execution can progress, speculatively. - (b) whilst the Function Units are devoid of register "name" - information, the FU-Regs Dependency Matrix is *not* devoid of that - information, having latched the read/write register numbers in an unary - form, as a "row", one bit in each row representing which register(s) - the instruction originally contained. + information, the FU-Regs Dependency Matrix is *not* devoid of that + information, having latched the read/write register numbers in an unary + form, as a "row", one bit in each row representing which register(s) + the instruction originally contained. - (c) by virtue of the direct Operand Port connectivity between the FU - and its corresponding FU-Regs DM "row", the Function Unit requesting for - example Operand1 results in the FU-Regs DM *row* triggering a register - file read-enable line, *NOT* the Function Unit itself. + and its corresponding FU-Regs DM "row", the Function Unit requesting for + example Operand1 results in the FU-Regs DM *row* triggering a register + file read-enable line, *NOT* the Function Unit itself. * seventh: the PriorityPickers manage resource contention between the FUs and the row-information from the FU-Regs Matrix.  the port bandwidth by nature has to be limited (we cannot have 200 read/write ports on @@ -64,10 +64,23 @@ the "acknowledgement" of each blockage being dropped. ultimately then, there is: -* an FU-Regs Matrix that, on a per-row basis, captures the instruction's register numbering (in unary, one SR-Latch raised per register per row) on a per-operand basis -* an FU-FU Matrix that preserves, as a Directed Acyclic Graph (DAG), the instruction order.  again, this is a bit-based system (SR Latches) that record which *read port* of the Function Unit needs a write result (when available). -* a suite of Function Units with input *and* output latches where the register information is *removed* (that being back in the FU-Regs row associated with a given FU) -* a PriorityPicker system that acknowledges the desire for access to the register file, and, due to the regfile ports being a contended resource, *only* permits one and only one FunctionUnit at a time to gain access to that regfile port.  where the FunctionUnit knows the Operand number it requires the input (or output) to come from (or to), it is the FU-Regs *row* that knows, on a per-operand-number basis, what the actual register file number is. +* an FU-Regs Matrix that, on a per-row basis, captures the instruction's + register numbering (in unary, one SR-Latch raised per register per row) + on a per-operand basis +* an FU-FU Matrix that preserves, as a Directed Acyclic Graph (DAG), + the instruction order.  again, this is a bit-based system (SR Latches) + that record which *read port* of the Function Unit needs a write result + (when available). +* a suite of Function Units with input *and* output latches where the + register information is *removed* (that being back in the FU-Regs row + associated with a given FU) +* a PriorityPicker system that acknowledges the desire for access to the + register file, and, due to the regfile ports being a contended resource, + *only* permits one and only one FunctionUnit at a time to gain access to + that regfile port.  where the FunctionUnit knows the Operand number it + requires the input (or output) to come from (or to), it is the FU-Regs + *row* that knows, on a per-operand-number basis, what the actual register + file number is. # Modifications needed to Computation Unit and Group Picker -- 2.30.2