3d_gpu/6600scoreboard.mdwn

   1 # 6600-style Scoreboards
   2
   3 Images reproduced with kind permission from Mitch Alsup
   4
   5 # Modifications needed to Computation Unit and Group Picker
   6
   7 The scoreboard uses two big NOR gates respectively to determine when there
   8 are no read/write hazards.  These two NOR gates are permanently active
   9 (per Function Unit) even if the Function Unit is idle.
  10
  11 In the case of the Write path, these "permanently-on" signals are gated
  12 by a Write-Release-Request signal that would otherwise leave the Priority
  13 Picker permanently selecting one of the Function Units (the highest priority).
  14 However the same thing has to be done for the read path, as well.
  15
  16 Below are the modifications required to add a read-release path that
  17 will prevent a Function Unit from requesting a GoRead signal when it
  18 has no need to read registers.  Note that once both the Busy and GoRead
  19 signals combined are dropped, the ReadRelease is dropped.
  20
  21 Note that this is a loop: GoRead (ANDed with Busy) goes through
  22 to the priority picker, which generates GoRead, so it is critical
  23 (in a modern design) to use a clock-sync'd latch in this path.
  24
  25 [[!img comp_unit_req_rel.jpg]]
  26 [[!img group_pick_rd_rel.jpg]]
  27
  28 # Modifications to Dependency Cell
  29
  30 Note: this version still requires CLK to operate on a HI-LO cycle.
  31 Further modifications are needed to create an ISSUE-GORD-PAUSE ISSUE-GORD-PAUSE
  32 sequence.  For now however it is easier to stick with the original
  33 diagrams produced by Mitch Alsup.
  34
  35 The dependency cell is responsible for recording that a Function Unit
  36 requires the use of a dest or src register, which is given in UNARY.
  37 It is also responsible for "defending" that unary register bit for
  38 read and write hazards, and for also, on request (GoRead/GoWrite)
  39 generating a "Register File Select" signal.
  40
  41 The sequence of operations for determining hazards is as follows:
  42
  43 * Issue goes HI when CLK is HI.  If any of Dest / Oper1 / Oper2 are also HI,
  44   the relevant SRLatch will go HI to indicate that this Function Unit requires
  45   the use of this dest/src register
  46 * Bear in mind that this cell works in conjunction with the FU-FU cells
  47 * Issue is LOW when CLK is HI.  This is where the "defending" comes into
  48   play.  There will be *another* Function Unit somewhere that has had
  49   its Issue line raised.  This cell needs to know if there is a conflict
  50   (Read Hazard or Write Hazard).
  51 * Therefore, *this* cell must, if either of the Oper1/Oper2 signals are
  52   HI, output a "Read after Write" (RaW) hazard if its Dest Latch (Dest-Q) is HI.
  53   This is the *Read_Pending* signal.
  54 * Likewise, if either of the two SRC Latches (Oper1-Q or Oper2-Q) are HI,
  55   this cell must output a "Write after Read" (WaR) hazard if the (other)
  56   instruction has raised the unary Dest line.
  57
  58 The sequence for determining register select is as follows:
  59
  60 * After the Issue+CLK-HI has resulted in the relevant (unary) latches for
  61   dest and src (unary) latches being set, at some point a GoRead (or GoWrite)
  62   signal needs to be asserted
  63 * The GoRead (or GoWrite) is asserted when *CLK is LOW*.  The AND gate
  64   on Reset ensures that the SRLatch *remains ENABLED*.
  65 * This gives an opportunity for the Latch Q to be ANDed with the GoRead
  66   (or GoWrite), raising an indicator flag that the register is being
  67   "selected" by this Function Unit.
  68 * The "select" outputs from the entire column (all Function Units for this
  69   unary Register) are ORed together.  Given that only one GoRead (or GoWrite)
  70   is guaranteed to be ASSERTed (because that is the Priority Picker's job),
  71   the ORing is acceptable.
  72 * Whilst the GoRead (or GoWrite) signal is still asserted HI, the *CLK*
  73   line goes *LOW*.  With the Reset-AND-gate now being HI, this *clears* the
  74   latch.  This is the desired outcome because in the previous cycle (which
  75   happened to be when CLK was LOW), the register file was read (or written)
  76
  77 The release of the latch happens to have a by-product of releasing the
  78 "reservation", such that future instructions, if they ever test for
  79 Read/Write hazards, will find that this Cell no longer responds: the
  80 hazard has already passed as this Cell already indicated that it was
  81 safe to read (or write) the register file, freeing up future instructions
  82 from hazards in the process.
  83
  84 [[!img dependence_cell_pending.jpg]]
  85
  86 # Shadowing
  87
  88 Shadowing is important as it is the fundamental basis of:
  89
  90 * Precise exceptions
  91 * Write-after-write hazard avoidance
  92 * Correct multi-issue instruction sequencing
  93 * Branch speculation
  94
  95 Modifications to the shadow circuit below allow the shadow flip-flops
  96 to be automatically reset after a Function Unit "dies".  Without these
  97 modifications, the shadow unit may spuriously fire on subsequent re-use
  98 due to some of the latches being left in a previous state.
  99
 100 Note that only "success" will cause the latch to reset.  Note also
 101 that the introduction of the NOT gate causes the latch to be more like
 102 a DFF (register).
 103
 104 [[!img shadow.jpg]]