1 # Computation Unit (aka "ALU Manager").
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
8 The Computation Unit module runs a "revolving door" set of three latches, based on
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:
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
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.
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.
34 Signals activate as follows:
36 * When issue is first raised, a busy signal is sent out.
37 The operand can be latched in at this point.
39 * Issue will only be raised for one cycle. Read requests may
40 go out immediately after issue goes low.
42 * Read request is set, which is acknowledged through the Scoreboard
43 to the priority picker, which generates (one and only one) Go_Read
44 at a time. One of those will (eventually) be this Computation Unit.
46 * Once Go_Read is set, the src1/src2/operand latch door shuts (locking
47 src1/src2/operand in place), and the ALU is told to proceed.
49 * when the ALU pipeline is ready, this activates "write request release",
50 and the ALU's output is captured into a temporary register.
52 * Write request release is *HELD UP* (prevented from proceeding) if shadowN
53 is asserted LOW. This is how all speculation, precise exceptions,
54 predication - everything - is achieved.
56 * Write request release will go through a similar process as Read request,
57 resulting (eventually) in Go_Write being asserted.
59 * When Go_Write is asserted, two things happen: (1) the data in the temp
60 register is placed combinatorially onto the output, and (2) the
61 req_l latch is cleared, busy is dropped, and the Comp Unit is back
62 through its revolving door to do another task.
64 Note that the read and write latches are held synchronously for one cycle,
65 i.e. that when Go_Read comes in, one cycle is given in which the incoming
66 register (broadcast over a Regfile Read Port) may have time to be latched.
68 It is REQUIRED that Issue be held valid only for one cycle.
70 It is REQUIRED that Go_Read be held valid only for one cycle, and it is
71 REQUIRED that the corresponding Read_Req be dropped exactly one cycle after
72 Go_Read is asserted HI.
74 Likewise for Go_Write: this is asserted for one cycle, and Req_Writes must
75 likewise be dropped exactly one cycle after assertion of Go_Write.
77 When Go_Die is asserted then strictly speaking the entire FSM should be
78 fully reset and that includes sending a cancellation request to the ALU.
79 (XXX TODO: alu "go die" is not presently wired up)