3d_gpu/architecture/compunit.mdwn

   1 # Computation Unit (aka "ALU Manager").
   2
   3 CompUnits serve the purpose of monitoring operations, and act as the
   4 arbiter between register file ports (both read and write) and ALUs.
   5 A critical aspect of its role is that *at no time* does result production
   6 go "unmonitored".
   7
   8 The Computation Unit module runs a "revolving door" set of three latches, based on
   9
  10 * Issue
  11 * Go_Read
  12 * Go_Write
  13
  14 where one of them cannot be set on any given cycle.  The Comp Unit
  15 monitors (and therefore blocks) until full completion of the
  16 operation.  Stages are therefore as follows:
  17
  18 * Issue to monitor receipt of the operation. "Block" begins here.
  19 * Operand Read waiting for opportunitie(s) for the regfile
  20   to become available and provide operands
  21 * Actual execution (which does not take place until all operands
  22   are provided)
  23 * Completion of result and capture of result(s)
  24 * Notification to regfile(s) of availability of results
  25 * Provision of result(s) on outgoing bus on request
  26 * Final release of "busy" when all result(s) have been sent out.
  27
  28 At no time is execution either allowed to proceed early, or is it
  29 "unmanaged".  The Comp Unit absolutely must monitor start and
  30 end time without fail and communicate and coordinate with the
  31 Dependency Matrices in order to preserve the Directed Acyclic
  32 Graph of Register hazards.
  33
  34 Signals activate as follows:
  35
  36 * When issue is first raised, a busy signal is sent out.
  37   The src1 and src2 registers and the operand can be latched in
  38   at this point
  39
  40 * Read request is set, which is acknowledged through the Scoreboard
  41   to the priority picker, which generates (one and only one) Go_Read
  42   at a time.  One of those will (eventually) be this Computation Unit.
  43
  44 * Once Go_Read is set, the src1/src2/operand latch door shuts (locking
  45   src1/src2/operand in place), and the ALU is told to proceed.
  46
  47 * when the ALU pipeline is ready, this activates "write request release",
  48   and the ALU's output is captured into a temporary register.
  49
  50 * Write request release is *HELD UP* (prevented from proceeding) if shadowN
  51   is asserted LOW.  This is how all speculation, precise exceptions,
  52   predication - everything - is achieved.
  53
  54 * Write request release will go through a similar process as Read request,
  55   resulting (eventually) in Go_Write being asserted.
  56
  57 * When Go_Write is asserted, two things happen: (1) the data in the temp
  58   register is placed combinatorially onto the output, and (2) the
  59   req_l latch is cleared, busy is dropped, and the Comp Unit is back
  60   through its revolving door to do another task.
  61
  62 Note that the read and write latches are held synchronously for one cycle,
  63 i.e. that when Go_Read comes in, one cycle is given in which the incoming
  64 register (broadcast over a Regfile Read Port) may have time to be latched.
  65
  66 It is REQUIRED that Go_Read be held valid only for one cycle, and it is
  67 REQUIRED that the corresponding Read_Req be dropped exactly one cycle after
  68 Go_Read is asserted HI.
  69
  70 Likewise for Go_Write: this is asserted for one cycle, and Req_Writes must
  71 likewise be dropped exactly one cycle after assertion of Go_Write.
  72
  73 When Go_Die is asserted then strictly speaking the entire FSM should be
  74 fully reset and that includes sending a cancellation request to the ALU.
  75 (XXX TODO: alu "go die" is not presently wired up)