# 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]]