Computation Unit (aka "ALU Manager").

CompUnits serve the purpose of monitoring operations, and act as the arbiter between register file ports (both read and write) and ALUs. A critical aspect of its role is that at no time does result production go "unmonitored".

The Computation Unit module runs a "revolving door" set of three latches, based on

  • Issue
  • Go_Read
  • Go_Write

where one of them cannot be set on any given cycle. The Comp Unit monitors (and therefore blocks) until full completion of the operation. Stages are therefore as follows:

  • Issue to monitor receipt of the operation. "Block" begins here.
  • Operand Read waiting for opportunitie(s) for the regfile to become available and provide operands
  • Actual execution (which does not take place until all operands are provided)
  • Completion of result and capture of result(s)
  • Notification to regfile(s) of availability of results
  • Provision of result(s) on outgoing bus on request
  • Final release of "busy" when all result(s) have been sent out.

At no time is execution either allowed to proceed early, or is it "unmanaged". The Comp Unit absolutely must monitor start and end time without fail and communicate and coordinate with the Dependency Matrices in order to preserve the Directed Acyclic Graph of Register hazards.

Signals activate as follows:

  • When issue is first raised, a busy signal is sent out. The operand can be latched in at this point.

  • Issue will only be raised for one cycle. Read requests may go out immediately after issue goes low.

  • Read request is set, which is acknowledged through the Scoreboard to the priority picker, which generates (one and only one) Go_Read at a time. One of those will (eventually) be this Computation Unit.

  • Once Go_Read is set, the src1/src2/operand latch door shuts (locking src1/src2/operand in place), and the ALU is told to proceed.

  • when the ALU pipeline is ready, this activates "write request release", and the ALU's output is captured into a temporary register.

  • Write request release is HELD UP (prevented from proceeding) if shadowN is asserted LOW. This is how all speculation, precise exceptions, predication - everything - is achieved.

  • Write request release will go through a similar process as Read request, resulting (eventually) in Go_Write being asserted.

  • When Go_Write is asserted, two things happen: (1) the data in the temp register is placed combinatorially onto the output, and (2) the req_l latch is cleared, busy is dropped, and the Comp Unit is back through its revolving door to do another task.

Note that the read and write latches are held synchronously for one cycle, i.e. that when Go_Read comes in, one cycle is given in which the incoming register (broadcast over a Regfile Read Port) may have time to be latched.

It is REQUIRED that Issue be held valid only for one cycle.

It is REQUIRED that Go_Read be held valid only for one cycle, and it is REQUIRED that the corresponding Read_Req be dropped exactly one cycle after Go_Read is asserted HI.

Likewise for Go_Write: this is asserted for one cycle, and Req_Writes must likewise be dropped exactly one cycle after assertion of Go_Write.

When Go_Die is asserted then strictly speaking the entire FSM should be fully reset and that includes sending a cancellation request to the ALU. (XXX TODO: alu "go die" is not presently wired up)