DRAGON DOCUMENT TITLE for Cedar.Style (Mark property value: centerHeader)
DRAGON DOCUMENT TITLE for Cedar.Style (Mark property value: centerRectoHeader)
DRAGON DOCUMENT TITLE for Cedar.Style (Mark property value: centerVersoHeader)
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
EU3 Data Sheet
The last version, hopefully
Louis Monier
Dragon-86-xx August 1986
© Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: This data sheet corresponds to the version 3 of the EU, to be sent for fabrication in late fall 1986.
Keywords: EU, Execution Unit, Data Sheet
FileName: EU3DataSheet.tioga, .interpress
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
Dragon Project - For Internal Xerox Use Only
Contents
1. Introduction
2. Pinout
3. Block Diagram
4. Signals definition
5. Timing
6. Application schematics
Appendix A. Appendix A Title
Appendix B. Appendix B Title
ChangeLog
1. Introduction and history
The Execution Unit (EU) is the datapath of the Dragon processor. Coupled with an IFU and two Caches, it forms a single Dragon processor.
I am referring in this document to the version designed during the fall 1986; it is mostly a fixed-up version of the EU2 which was designed between January and June 1986 and tested in October 1986. The EU1 was designed in the Spring 1985 but all the chips processed by ICL failed because of a metalization failure shorting power buses. There was an EU0, designed in late 1984 with the first version of Patchwork, but never sent to fab. There was even a 4-m NMOS EU(-1), hand-crafted during the summer of 1983 when dinosaurs were still roaming the Bay Area; this version was fabricated by ICL, zapped to death during packaging, and abandonned because its architecture and technology became rapidly obsolete. Because of this long design process, the architecture of this chip is 99% history, and I don't feel that this chip reflects what a processor should be in 1986.
The EU is mostly a slave processor of the IFU. It interfaces to the KBus (with the IFU), to the PBus (with the Data Cache) and to the DBus for debugging. It receives commands from the IFU, and returns a condition code.
Warning: the Mesa convention applies here, i.e. the high order bit is numbered 0.
2. Pinout
Vdd, Gnd, PadVdd, PadGnd.
Every corner is occupied by a special pad.
One out of every three pads is a power pad.
3. Block Diagram
Ask how to include Interpress. What about the definition of states???
4. Signals definition
4.1 Clocks and power supplies
The EU uses two sets of power supplies: PadVdd (+5V) and PadGnd (0V) for the pad drivers, and Vdd (+5V) and Gnd (0V) for the rest of the chip. These two sets are connected on the chip carrier.
PhA and PhB are two non-overlapping clocks with the following ideal characteristics:
period=100ns, width=40ns, Trise=Tfall<5ns
4.2 Communication with the IFU
KBus: The KBus is a 32-bit bidirectionnal bus interfacing the EU to the IFU. During PhB the IFU always sends to the EU a 32-bit quantity interpreted as follows:
KBus [0..7] is aAdr
KBus [8..15] is bAdr
KBus [16..23] is cAdr
KBus [24] is EUSt3AisCBus2BA
KBus [25..26] is EUAluLeftSrc1BA
KBus [27..29] is EUAluRightSrc1BA
KBus [30..31] is EUStore2ASrc1BA
During PhA the direction of the KBus is decided by the value of cAdr on the previous cycle: if it was equal to euToKBus (129) then the EU sends to the IFU the value of the cBus, otherwise the EU receives from the IFU an immediate constant on 32 bits.
EUAluOp2AB: A 4-bit opcode specifies one among 16 possible operations. The opcode assignment:
Or(0) And(1) VAdd2(2) BndChk(3)
SAdd(4) SSub(5) LAdd(6) LSub(7)
Xor(8) res9(9) FOP(10) res11(11)
VAdd(12) VSub(13) UAdd(14) USub(15)
EUCondSel2AB: A 4-bit opcode specifies which one of the 16 computed conditions is returned to the IFU.
False(0) EZ(1) LZ(2) LE(3)
res4(4) NE(5) GE(6) GZ(7)
OvFl(8) BC(9) IL(10) res11(11)
res12(12) NotBC(13) NotIL(14) ModeFault(15)
EUCondition2B: The condition returned to the IFU during 2B. If true, causes the IFU to trap; in prevision of the trap, the EU preserves the carry when issuing a true condition.
EURes3BisPBus3AB: Specifies that the EU must read the PBus on 3B.
EUWriteToPBus3AB: Specifies that the EU must write on the PBus on 3B. EURes3BisPBus3AB and EUWriteToPBus3AB are mutually exclusive.
4.3 Communication with the Cache
DPData: is a 32-bit bidirectionnal bus interfacing the EU to the Data Cache. On PhA the EU always sends to the EU a 32-bit address. On PhB, DPData carries a 32-bit data, either from the EU to the Cache (store) or from the Cache to the EU (fetch).
DPRejectB: Issued by the Data Cache during 3B if it cannot satisfy the EU request, and latched by the EU at the end of PhB. When issued, it freezes the EU, i.e. during the following PhA:
the cBus selects as source the address responsible for the reject (in r3B);
this address is saved in ram[130];
no pipeline register is updated;
carryAB is preserved;
no address is put on the PBus;
4.4 Debug bus
DShift, DSerialIn, DSerialOut, nDSelect, DExecute, nDFreeze, nDReset. The semantic is defined in the DBus document. Most of these signals are latched on PhA.
The EU contains a 2(opcode)+4(dStateAd)+32(data) = 38-bit shift register. The following opcodes are defined:
reset: the id and version number of the chip are copied into the data part of the shift register.
read: the value of the register "dStateAd" is copied into the data part of the shift register.
write: the value of the data part of the shift register is copied into the register "dStateAd".
The registers are numbered as follows: left(0) right(1) st2A(2) st2B(3) st3A(4) kReg(5) field(6) r2B(7) r3A(8) r3B(9) dataIn(10).
4.5 The RAM
The
EU contains a 160x32-bit words three-ported register file (usually called
ram) organized as follows:
euStack (000), -- beginning of EU Stack; ram[0..128) is the stack
euJunk (128), -- the non-matching EU register, used to specify "no write"
euToKBus (129), -- send result on Kbus to IFU!
euMAR (130), -- MemoryAddressRegister, save the address sent to the cache
euField (131), -- Field register, duplicates the content of the register "field"
euConstant (132), -- Base of EU constant registers (12 regs)
euAux (144), -- Base of EU auxilliary registers (16 regs)
euBogus (160), -- [euBogus..euLast] not legal (NA) (80 regs)
euLast (239), -- last possible EU reg (NA)
Note: ram[132]=0, ram[133]=1, ram[134]=2 and ram[135]=3 are hardwired constants (implemented as ROM) and cannot be written; the registers ram[136..144) are also designated as constants but can be modified.
4.6 Other states
The EU pipeline contains a dozen 32-bit registers; names bear the scars of a long history and don't make always sense:
kReg receives on 1B the ram addresses and other control bits
left, right, st2A operands for ALU and field unit; (2A)
field field descriptor for FU operation; loaded when cAdr=131; (2A)
r2B result of ALU or FU operation; (2B)
st2B data for the cache; (2B)
r3A copy of address sent to cache or result on its way to the ram; (3A)
st3A data for the cache; (3A)
r3B copy of r3A (3B); tristate driver on cBus during 4A
dataIn copy of DPData (3B); tristate driver on cBus during 4A
Other bits of state are found; they are all 1-bit quantities and reside in the control section.
rejectBA a copy of DPRejectB latched on PhB
carryBA output of the adder modified by the opcode of the previous operation
carryAB incoming carry for the ALU; copy of carryBA if no reject or trap
5. Timing
All control signals sent by the IFU are valid at the end of PhA and latched by the IFU during PhB. Both KBus and PBus are bidirectionnal and phase-multiplexed. DPRejectB is valid at the end of PhB and invalid during PhA, so it is internally latched by the EU.
3.1 SubSection Title
3.2 SubSection Title
Body
6. Application schematics
All paragraphs in a Dragon document have the format body, except for paragraphs that continue after an equation or an in-line figure. These have the format block. All headings have the format head. Chapters should begin on an odd-numbered page, so a pageBreak node should be placed just prior to the chapter.
A node which defines the running head can be inserted nested under the chapter heading. It has the node property Mark with value centerRectoHeader. The TSetter understands this to be a header definition and diverts the text for later assembly during page layout. All paragraphs in a blue-and-white have the format body.
3.1 SubSection Title
Body
3.2 SubSection Title
Body
Appendix A.
Appendix A Title
Body
Appendix B.
Appendix B Title
Body