From: Luke Kenneth Casson Leighton Date: Tue, 17 Mar 2020 21:43:50 +0000 (+0000) Subject: move 6600scoreboard page to correct location X-Git-Tag: convert-csv-opcode-to-binary~3105 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=7164a89a5e07169acc9cdef17eefb3a192f92889;p=libreriscv.git move 6600scoreboard page to correct location --- diff --git a/3d_gpu/6600scoreboard.mdwn b/3d_gpu/6600scoreboard.mdwn deleted file mode 100644 index 9a900561c..000000000 --- a/3d_gpu/6600scoreboard.mdwn +++ /dev/null @@ -1,118 +0,0 @@ -# 6600-style Scoreboards - -Images reproduced with kind permission from Mitch Alsup - -# Modifications needed to Computation Unit and Group Picker - -The scoreboard uses two big NOR gates respectively to determine when there -are no read/write hazards. These two NOR gates are permanently active -(per Function Unit) even if the Function Unit is idle. - -In the case of the Write path, these "permanently-on" signals are gated -by a Write-Release-Request signal that would otherwise leave the Priority -Picker permanently selecting one of the Function Units (the highest priority). -However the same thing has to be done for the read path, as well. - -Below are the modifications required to add a read-release path that -will prevent a Function Unit from requesting a GoRead signal when it -has no need to read registers. Note that once both the Busy and GoRead -signals combined are dropped, the ReadRelease is dropped. - -Note that this is a loop: GoRead (ANDed with Busy) goes through -to the priority picker, which generates GoRead, so it is critical -(in a modern design) to use a clock-sync'd latch in this path. - -[[!img comp_unit_req_rel.jpg]] -[[!img group_pick_rd_rel.jpg]] - -# Modifications to Dependency Cell - -Note: this version still requires CLK to operate on a HI-LO cycle. -Further modifications are needed to create an ISSUE-GORD-PAUSE ISSUE-GORD-PAUSE -sequence. For now however it is easier to stick with the original -diagrams produced by Mitch Alsup. - -The dependency cell is responsible for recording that a Function Unit -requires the use of a dest or src register, which is given in UNARY. -It is also responsible for "defending" that unary register bit for -read and write hazards, and for also, on request (GoRead/GoWrite) -generating a "Register File Select" signal. - -The sequence of operations for determining hazards is as follows: - -* Issue goes HI when CLK is HI. If any of Dest / Oper1 / Oper2 are also HI, - the relevant SRLatch will go HI to indicate that this Function Unit requires - the use of this dest/src register -* Bear in mind that this cell works in conjunction with the FU-FU cells -* Issue is LOW when CLK is HI. This is where the "defending" comes into - play. There will be *another* Function Unit somewhere that has had - its Issue line raised. This cell needs to know if there is a conflict - (Read Hazard or Write Hazard). -* Therefore, *this* cell must, if either of the Oper1/Oper2 signals are - HI, output a "Read after Write" (RaW) hazard if its Dest Latch (Dest-Q) is HI. - This is the *Read_Pending* signal. -* Likewise, if either of the two SRC Latches (Oper1-Q or Oper2-Q) are HI, - this cell must output a "Write after Read" (WaR) hazard if the (other) - instruction has raised the unary Dest line. - -The sequence for determining register select is as follows: - -* After the Issue+CLK-HI has resulted in the relevant (unary) latches for - dest and src (unary) latches being set, at some point a GoRead (or GoWrite) - signal needs to be asserted -* The GoRead (or GoWrite) is asserted when *CLK is LOW*. The AND gate - on Reset ensures that the SRLatch *remains ENABLED*. -* This gives an opportunity for the Latch Q to be ANDed with the GoRead - (or GoWrite), raising an indicator flag that the register is being - "selected" by this Function Unit. -* The "select" outputs from the entire column (all Function Units for this - unary Register) are ORed together. Given that only one GoRead (or GoWrite) - is guaranteed to be ASSERTed (because that is the Priority Picker's job), - the ORing is acceptable. -* Whilst the GoRead (or GoWrite) signal is still asserted HI, the *CLK* - line goes *LOW*. With the Reset-AND-gate now being HI, this *clears* the - latch. This is the desired outcome because in the previous cycle (which - happened to be when CLK was LOW), the register file was read (or written) - -The release of the latch happens to have a by-product of releasing the -"reservation", such that future instructions, if they ever test for -Read/Write hazards, will find that this Cell no longer responds: the -hazard has already passed as this Cell already indicated that it was -safe to read (or write) the register file, freeing up future instructions -from hazards in the process. - -[[!img dependence_cell_pending.jpg]] - -# Shadowing - -Shadowing is important as it is the fundamental basis of: - -* Precise exceptions -* Write-after-write hazard avoidance -* Correct multi-issue instruction sequencing -* Branch speculation - -Modifications to the shadow circuit below allow the shadow flip-flops -to be automatically reset after a Function Unit "dies". Without these -modifications, the shadow unit may spuriously fire on subsequent re-use -due to some of the latches being left in a previous state. - -Note that only "success" will cause the latch to reset. Note also -that the introduction of the NOT gate causes the latch to be more like -a DFF (register). - -[[!img shadow.jpg]] - -# Store Computation Unit - -* Issue will close the opcode latch and OPEN the operand latch AND -trigger "Request-Read" (and set "Busy") -* Go-Read will close the operand latch and OPEN the address latch AND -trigger "Request Address". -* Go-Address will close the address latch and OPEN the result latch -AND trigger "Request Write" -* Go-Write will close the result latch and OPEN the opcode latch, and -reset BUSY back to OFF, ready for a new cycle. - -[[!img st_comp_unit.jpg]] - diff --git a/3d_gpu/architecture/6600scoreboard.mdwn b/3d_gpu/architecture/6600scoreboard.mdwn new file mode 100644 index 000000000..9a900561c --- /dev/null +++ b/3d_gpu/architecture/6600scoreboard.mdwn @@ -0,0 +1,118 @@ +# 6600-style Scoreboards + +Images reproduced with kind permission from Mitch Alsup + +# Modifications needed to Computation Unit and Group Picker + +The scoreboard uses two big NOR gates respectively to determine when there +are no read/write hazards. These two NOR gates are permanently active +(per Function Unit) even if the Function Unit is idle. + +In the case of the Write path, these "permanently-on" signals are gated +by a Write-Release-Request signal that would otherwise leave the Priority +Picker permanently selecting one of the Function Units (the highest priority). +However the same thing has to be done for the read path, as well. + +Below are the modifications required to add a read-release path that +will prevent a Function Unit from requesting a GoRead signal when it +has no need to read registers. Note that once both the Busy and GoRead +signals combined are dropped, the ReadRelease is dropped. + +Note that this is a loop: GoRead (ANDed with Busy) goes through +to the priority picker, which generates GoRead, so it is critical +(in a modern design) to use a clock-sync'd latch in this path. + +[[!img comp_unit_req_rel.jpg]] +[[!img group_pick_rd_rel.jpg]] + +# Modifications to Dependency Cell + +Note: this version still requires CLK to operate on a HI-LO cycle. +Further modifications are needed to create an ISSUE-GORD-PAUSE ISSUE-GORD-PAUSE +sequence. For now however it is easier to stick with the original +diagrams produced by Mitch Alsup. + +The dependency cell is responsible for recording that a Function Unit +requires the use of a dest or src register, which is given in UNARY. +It is also responsible for "defending" that unary register bit for +read and write hazards, and for also, on request (GoRead/GoWrite) +generating a "Register File Select" signal. + +The sequence of operations for determining hazards is as follows: + +* Issue goes HI when CLK is HI. If any of Dest / Oper1 / Oper2 are also HI, + the relevant SRLatch will go HI to indicate that this Function Unit requires + the use of this dest/src register +* Bear in mind that this cell works in conjunction with the FU-FU cells +* Issue is LOW when CLK is HI. This is where the "defending" comes into + play. There will be *another* Function Unit somewhere that has had + its Issue line raised. This cell needs to know if there is a conflict + (Read Hazard or Write Hazard). +* Therefore, *this* cell must, if either of the Oper1/Oper2 signals are + HI, output a "Read after Write" (RaW) hazard if its Dest Latch (Dest-Q) is HI. + This is the *Read_Pending* signal. +* Likewise, if either of the two SRC Latches (Oper1-Q or Oper2-Q) are HI, + this cell must output a "Write after Read" (WaR) hazard if the (other) + instruction has raised the unary Dest line. + +The sequence for determining register select is as follows: + +* After the Issue+CLK-HI has resulted in the relevant (unary) latches for + dest and src (unary) latches being set, at some point a GoRead (or GoWrite) + signal needs to be asserted +* The GoRead (or GoWrite) is asserted when *CLK is LOW*. The AND gate + on Reset ensures that the SRLatch *remains ENABLED*. +* This gives an opportunity for the Latch Q to be ANDed with the GoRead + (or GoWrite), raising an indicator flag that the register is being + "selected" by this Function Unit. +* The "select" outputs from the entire column (all Function Units for this + unary Register) are ORed together. Given that only one GoRead (or GoWrite) + is guaranteed to be ASSERTed (because that is the Priority Picker's job), + the ORing is acceptable. +* Whilst the GoRead (or GoWrite) signal is still asserted HI, the *CLK* + line goes *LOW*. With the Reset-AND-gate now being HI, this *clears* the + latch. This is the desired outcome because in the previous cycle (which + happened to be when CLK was LOW), the register file was read (or written) + +The release of the latch happens to have a by-product of releasing the +"reservation", such that future instructions, if they ever test for +Read/Write hazards, will find that this Cell no longer responds: the +hazard has already passed as this Cell already indicated that it was +safe to read (or write) the register file, freeing up future instructions +from hazards in the process. + +[[!img dependence_cell_pending.jpg]] + +# Shadowing + +Shadowing is important as it is the fundamental basis of: + +* Precise exceptions +* Write-after-write hazard avoidance +* Correct multi-issue instruction sequencing +* Branch speculation + +Modifications to the shadow circuit below allow the shadow flip-flops +to be automatically reset after a Function Unit "dies". Without these +modifications, the shadow unit may spuriously fire on subsequent re-use +due to some of the latches being left in a previous state. + +Note that only "success" will cause the latch to reset. Note also +that the introduction of the NOT gate causes the latch to be more like +a DFF (register). + +[[!img shadow.jpg]] + +# Store Computation Unit + +* Issue will close the opcode latch and OPEN the operand latch AND +trigger "Request-Read" (and set "Busy") +* Go-Read will close the operand latch and OPEN the address latch AND +trigger "Request Address". +* Go-Address will close the address latch and OPEN the result latch +AND trigger "Request Write" +* Go-Write will close the result latch and OPEN the opcode latch, and +reset BUSY back to OFF, ready for a new cycle. + +[[!img st_comp_unit.jpg]] +