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
EU Data Sheet
The one for the SoftCard
Louis Monier
Dragon-87-2 March 20, 1987
© Copyright 1986, 1987 Xerox Corporation. All rights reserved.
Abstract: This data sheet corresponds to the version 4 of the EU, to be sent for fabrication in late April 197.
Keywords: EU, Execution Unit, Data Sheet
FileName: [Indigo]<Dragon>EU4>EUDataSheet.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 February 1987. It is almost an exact copy of the EU3 fabricated during the fall 1986, which in turn was 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 with Jean Vuillemin 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 were becoming rapidly obsolete.
Because of this long design process, the architecture of the EU is 99% history, and I don't feel that this chip reflects what a processor should be in 1987.
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.
[Artwork node; type 'ArtworkInterpress on' to command tool]
EU3 Pinout
3. Block Diagram
Ask how to include Interpress. What about the definition of states???
[Artwork node; type 'ArtworkInterpress on' to command tool]
EU3 block diagram
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
The clocks' complements are generated internally in the pads.
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 (unless reject was asserted in the previous PhB). On PhB, DPData carries a 32-bit data, either from the EU to the Cache (store) or from the Cache to the EU (fetch). In the case of a store, the EU asserts the data on the first PhiB, and on each subsequent PhiB if the transaction is delayed by reject.
DPRejectB: Issued by the Data Cache during 3B when 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 register 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
The datapath of the EU contains a shift register whic can be used for debugging. The DBus is composed of eight wires: DShA, DShB, DShRd, DShWt, DShIn, DShOut, DHold, DStAd[0..4). The semantic is different from what is currently defined in the DBus document because the IFU does not implements it, and both chips have to be compatible for the SoftCard. None of these signals are latched, and the clocks must be stoppped during debugging.
DHold: must be asserted during debug; freeze the EU.
DShA, DShB: the pair forms the clock used by the shift register.
DShRd: copies the value of a datapath pipeline register into the shift register.
DShWt: copies the content of the shift register into a particular datapath register.
DShIn, DShOut: the serial input and output of the shift register.
DStAd: encodes which datapath register is read/written.
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.
[Artwork node; type 'ArtworkInterpress on' to command tool]
Timing diagram
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
ChangeLog
Body