MAPCACHEDATASHEETDOC
MAPCACHEDATASHEETDOC
MAPCACHEDATASHEETDOC
1
1
1
Map Cache Data Sheet
Lissy Bland, Louis Monier and Pradeep Sindhu
Dragon-88-04 April 1988 
© Copyright 1988 Xerox Corporation. All rights reserved.
Keywords: Map Cache, Cache, Map Table, Memory, Address Translation, Virtual Address, Real Address, Dragon, Dynabus, VLSI;
Maintained by: Bland.pa
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304


For Internal Xerox Use Only
Map Cache Data Sheet
1.0 Brief Description
The Map Cache is a performance accelerator that sits between Map Table, stored in main memory, and the processor caches. It is a pure cache containing none of its own information; consequently, entries that are deleted from the Map Cache never have to be written back to the Map Table. The Map Cache is strictly a slave of other circuits, and all communications with it occur over the Dynabus.
As Figures 1a and 1b illustrate, the Map Cache enhances the Cache's ability to return data to the processor by translating virtual addresses to real addresses when the Cache has insufficient information to perform this translation.
[Artwork node; type 'ArtworkInterpress on' to command tool]
[Artwork node; type 'Artwork on' to command tool]
Figures 1a & 1b: The Map Cache and the Memory System: When a processor makes a request for data, there are three possible outcomes. (1) If the cache contains the data requested by the processor or is able to construct the real address for the requested data, it can return the data to the processor. (2) If the cache does not have the real address, it sends the virtual address of the requested data to the Map Cache. If the Map Cache has an entry for the virtual address requested, it returns the corresponding real address to the Cache. (3) If the virtual address requested is not in the Map Cache, the Map Cache reports an error condition to the processor via the cache(3A). This error condition initiates a software trap to load an entry for the requested virtual address in the Map Cache. The entry is taken from the complete Map Table which resides main memory (3B). After the entry is loaded, the Cache accesses the Map Cache again and obtains the real page.
2.0 Pin-Out
[Artwork node; type 'Artwork on' to command tool]
3.0 Block Diagram of the Chip
3.1 Simplified Block Diagram
[Artwork node; type 'Artwork on' to command tool]
3.2 Command filtering
A command received from the Dynabus is first checked by the command decoder. Only MapRqst, IORead, IOWrite, and BIOWrite commands are accepted. In addition, if bits 17 through 31 of the header are not all zero, the request is ignored. Commands that are accepted receive additional decoding and more checks are applied:
1. For MapRqst and IO operations accessing an entry in the Map Cache Table, the virtual page specified must be mapped by this particular Map Cache. In a system with multiple Map Caches, this check might be used to allocate virtual pages among the Map Caches. For example, one Map Cache might handle even pages and another odd ones. The subset of vp for a MapCache is specified by two 22-bit registers called SubSetMask and SubSetPattern.
2. For all IO operations, the device type specified in the header must indicate a Map Cache.
3. For all non-broadcast IO operations, the device number specified in the header must match the low-order bits of the DeviceID of this Map Cache.
A command satisfying all these conditions is accepted and queued in the 16-entry FIFO. The FIFO is necessary because requests can be received every two cycles, while processing takes three cycles. If an IOWrite is asserted in user mode, the command is accepted but will return a fault.
3.3 Command processing
Commands are then pulled out of the FIFO and processed. Unless the command is a BIOWrite, a request is posted immediately to the Arbiter. The processing of the command may involve reading or writing the Map Cache Table and the internal registers, and results in the formation of a reply packet.
3.4 Replies
All replies are two cycles long. The reply packet is written onto the Dynabus as soon as a grant is received from the Arbiter. The minimum latency, assuming a 3-cycle Arbiter delay between request and grant, is 9 cycles. In practice, the Arbiter latency is going to dominate.
4.0 The Addressing Architecture of the Cached Memory System
In order to understand the role of the Map Cache, it is necessary to understand the addressing architecture of the memory system, and how the Cache and Map Cache and Map Table work together to provide data to the processor.
The addressing architecture supports multiple address spaces, with fixed size pages being the unit of mapping and protection. The virtual addresses issued by each processor are in a single address space. For a given virtual address, the mapping to a real address can be thought of as a two step process: (1) determine the address space in which the virtual address must be interpreted, and (2) perform the translation in this space. Before this two-step process address translation is described in detail, some basic terms will be defined.
4.1 Definitions
4.1.1 Page, Virtual Address, Virtual Page, Real Address, Real Page, Offset
A page is a contiguous chunk of memory 2s 32-bit words long, aligned on a 2s word boundary; s is fixed at 10. Virtual addresses are denoted by va, real addresses by ra, virtual pages by vp, real pages by rp, and offsets into pages by offset. Both va and ra are 32-bit quantities, both vp and rp are (32—s)-bit quantities, and offset is an s-bit quantity. If vp and offset are the virtual page and offset corresponding to va, then the va=vp|offset; similarly, the ra=rp|offset for real addresses.
4.1.2 Flags, Faultcode and Aid
The Map Table keeps six flags bits for each page: in high to low order these are: Spare, Shared, Dirty, KWtEnable (kernel write permission), UWtEnable (user write permission), URdEnable (user read permission). The six flags are collectively referred to as the flags. The Map Cache only caches four of these six flags. The sizes of these quantities are constrained by the relation ||rp||+||flags||d32, where ||x|| is shorthand for log2xË, the number of bits needed to represent x. The Map Cache communicates faults with a 32-bit FaultCode. This FaultCode is divided into three-bit major faultcode and a 29-bit minor faultcode. Address spaces will be denoted by their address space id, aid, a quantity constrained by ||aid||d32. The current Map Cache stores only 16 bits for aid.
4.2 Address Translation
Figure 3 illustrates the process of mapping a virtual address for a given processor (the sizes and locations of the various regions shown are for illustration purposes only, and should not be interpreted as being fixed by the architecture). The first step begins with the aid of the processor's address space and the va to be mapped. If va lies in a special shared area of virtual addresses, then the address space used for mapping is space 0 otherwise va lies in the switched area, and the space used is aid. The second step translates va in the context of the aid given by the first step. This translation produces ra=rp|offset, where rp is obtained by looking up the entry corresponding to aid|vp in the Map Table.
Step one provides an economical, but restricted form of page sharing across address spaces called aliasing. Aliasing is economical in that there is only one mapping entry per real page whether or not the page is shared. Aliasing is restricted in two senses: (1) a page must appear at the same virtual address in all spaces, and (2) sharing is all-or-nothing; that is, a page is shared by all address spaces if it is shared by any. It is expected that all but a few cases of sharing will be covered by this restricted mechanism. However, the architecture also permits more general sharing in which the vp's sharing a particular rp are unrestricted and where each page may be shared by any subset of the spaces.
[Artwork node; type 'ArtworkInterpress on' to command tool]
Figure 3. Virtual to Real Address Translation.
4.3 Special regions
4.3.1 The Shared Area
The address space for all processors is divided into a shared and switched area. These areas are the same for all processors and are defined by a pair of 22-bit values, SharedMask and SharedPattern. A virtual address is in the shared area IF (vp AND SharedMask) = (SharedPattern AND SharedMask). If a virtual address is in the shared area, then its mapping is independent of the aid. All addresses that are not in the shared area are in the switched area. Typically, the shared area is used to store the kernel.
4.3.2 The Bypass Area
The Bypass area allows processors to access the Map Table and map-fault handling code without getting map faults. Bypassing is activated whenever a processor makes a reference to a portion of virtual address space called the map bypass area. The check for bypass gets applied before normal translation is attempted. This area appears at the same locations in all address spaces, and is defined by three 22-bit quantities BypassMask, BypassPattern, and BypassBase. The mask and pattern determine the bypass area's location and size in virtual memory as follows: a va is defined to be in the bypass area if the bits selected by BypassMask in vp match the corresponding bits in BypassPattern; a 1 in BypassMask selects the corresponding bit in vp while a 0 deselects it. BypassBase determines the starting location of the bypass area in real memory. The real address produced by bypass mapping is ra=rp|offset, where rp= (BypassBase'BypassMask) ( (vp'~BypassMask). The mask, pattern, and base can all be modified by software. If an address is in the Bypass area, the flags have the following default values: Dirty = TRUE, KWtEnable (kernel write permission) = TRUE, UWtEnable (user write permission) = FALSE, URdEnable (URdEnable) = FALSE.
4.3.3 The Identity Mapping
The identity mapping is useful in initializing the system at startup, and for doing IO. It is implemented by designating one of the address spaces (aid=-1) to correspond to the identity map (rp=vp). The check for identity mapping is applied before the check for bypass mapping, so it takes highest precedence. If an address is in the Identity Mapping area, the flags have the following default values: Dirty = TRUE, KWtEnable = TRUE, UWtEnable = FALSE, URdEnable = FALSE.
4.4 Mapping and DeMapping Pages
To create a new correspondence between a virtual and a real page, the system software simply enters a new entry in the Map Table which resides in memory.
When the correspondence between a virtual and real address is no longer valid, system software must delete the mapping entry using the following procedure:
1. Delete the entry from the Map Table.
2. Delete the entry from the Map Cache.
3. Execute DeMapRequest[realPage]. This Dynabus transaction causes the virtual address for the real page to be marked invalid in all caches.
When the Cache issues a MapRqst for a virtual page that is not in the Map Cache, system software should perform the following actions:
1. Verify that the virtual page exists in the Map Table. If it does not, this is a real error.
2. Determine whether the corresponding real page is in memory. If it is not, the page must be swapped into memory.
3. Load the new virtual to real correspondence into the Map Cache.  
5.0 Programmer's Model
The Map Cache implements five commands. Its main function is to provide mapping from virtual to real addresses, using the following transaction (MapRqst):
Map [aid, vp] Returns [rp, flags].
The entries of the Map Cache can also be accessed directly with the IORead and IOWrite commands. Because the format of the IORead and IOWrite commands is of limited size, it is not possible to pass both vp and aid as parameters to these transactions; consequently, the value of the aid is first stored in the AID internal register and is used implicitly:
WriteEntry [vp, rp flags].
ReadEntry [vp] Returns [rp, flags].
The Map Cache contains 8 internal registers, which can be accessed directly with IORead and IOWrite:
WriteRegister [registerNumber, value].
ReadRegister [registerNumber] Returns [value].
The Map Cache also implements the broadcast version of both IOWrite's.
5.1 DynaBus Transactions
Each DynaBus command is two cycles long. The first cycle presents header information and a 32-bit address. (See Figure 1). The use of the second cycle is command dependent.
[Artwork node; type 'Artwork on' to command tool]
Figure 1: Encoding of Header Cycle. During requests, bit 5 is indicates the mode (kernel=0, user=1); for replies, bit 5 indicates an error (error=1). The replyShared bit is always set to 0 by the Map Cache. The DeviceID is the requestor's for all headers.
The replies are also two cycles long. Note that for all of the transactions except MapRequest, the first cycle of the reply reflects most of the information contained in the header cycle of the command; bits 0-4 and 7-63 are identical. The second cycle is command dependent and may contain the requested data, error information or be unused.
Figure 4 illustrates the address pattern for all IO transactions addressed to the Map Cache.
[Artwork node; type 'Artwork on' to command tool]
Figure 4: Address pattern used for IO transactions addressed to the Map Cache.
The bits of the address have the following meanings:
1. bits 32-35: 0101, indicate the device type as specified in The DynaBus: A VLSI Bus for Use in Multi-Processor Systems1.
2. bits 36-39: nnnn, are the low-order bits of the DynaBus DeviceID of this Map Cache.
3. bits 40-41: a 2-bit opcode:
0X: read entry
00: flush entry
01: write entry
10: access register
4. bits 42-63: a 22-bit data field used for representing a virtual page or a register number.
—————————————————————————————————————
1Lissy Bland et. al. The DynaBus: A VLSI Bus for Use in Multi-Processor Systems. 1988 October. Dragon 88-08. [CSL].
Here are the specifications for the DynaBus commands to which the Map Cache responds:
5.1.1 Mapping: MapRqst and MapRply
This command takes a 16-bit address space identifier (aid) and a 22-bit virtual page number as inputs.
[Artwork node; type 'ArtworkInterpress on' to command tool]
If the Map Cache contains the requested entry, it returns the corresponding 22-bit real page number and 4 flags.
[Artwork node; type 'ArtworkInterpress on' to command tool]
If the Map Cache does not contain the requested entry, a 32-bit FaultCode is returned. The 10, high-order bits of the FaultCode are the Dynabus DeviceID of the reporting device. The 3, least significant bits of the FaultCode report the specific error, MapFault which is 010.
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.1.2 Read Map Cache Entry
The Map Cache extends the opcode of the IOReadRequest so that it can be used to read Map Cache entries. Bit 40 of the header cycle is the extention: if bit 40 = 0, a ReadMapCacheEntry is executed.
This command is logically equivalent to the Map Request, and should be used mostly for debugging purposes. The command takes a virtual page as input, and uses the AID register as aid corresponding to the virtual page.
[Artwork node; type 'ArtworkInterpress on' to command tool]
If the entry is present, the command returns the corresponding real page and flags:
[Artwork node; type 'ArtworkInterpress on' to command tool]
If the Map Cache does not contain the requested entry, a 32-bit FaultCode is returned. For ReadMapCacheEntryReply, the specific error is categorized as DynaBusOtherFault, 111.
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.1.3 Read Map Cache Register
The Map Cache extends the opcode of the IOReadRequest so that it can be used to read Map Cache registers. Bits 40 and 41 of the header cycle are the extention. If bits 40 and 41 are 10, the ReadMapCacheRegister is executed.
This command takes a 3-bit register number as input and returns the contents of the register. (For a description of the 8 Map Cache registers, see Section 5.2.)
[Artwork node; type 'ArtworkInterpress on' to command tool]
Since there are exactly 8 registers, and read access to these registers is not restricted, no error is possible for this command. The value of the register (16 or 22 bits) is left-filled with 0's.
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.1.4 Write Map Cache Entry
The opcode of the IOWriteRequest is extended so that it can be used to write Map Cache entries. Bit 40 header cycle is the extention. If bit 40 of the IOWriteRequest is a zero, a WriteMapCacheEntry is executed.
This command writes an entry containing a virtual page, a real page, 4 flags, and a valid bit in the Map Cache Entry Table. The valid bit is specified in position 41 of the header, and is really an extension of the opcode: if TRUE (1), the entry is written; if FALSE (0), the entry is flushed. Since the Map Cache uses a very simple (and somewhat heavy-handed) direct map scheme, flushing an entry which is not in the Map Cache causes any entry that uses the same location to be flushed instead.
The aid corresponding to the virtual page should be written into the AID register using WriteMapCacheRegister before this command is executed.
[Artwork node; type 'ArtworkInterpress on' to command tool]
If no error, the reply is:
[Artwork node; type 'ArtworkInterpress on' to command tool]
If the write is attempted in user mode, the IOAccessFault, 001, meaning insufficient privilege to access an IO location is returned.
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.1.5 Write Map Cache Register
This commands takes two arguments, a register number and the data to be written. (For a description of the 8 Map Cache registers, see Section 5.3.) The opcode is bit 40=1, bit 41=0.
[Artwork node; type 'ArtworkInterpress on' to command tool]
If no error occurs, the reply is:
If the write is attempted in user mode, the IOAccessFault, 001, meaning insufficient privilege to access an IO location is returned.
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.1.6 Broadcast Writes
The WriteMapCacheEntry and WriteMapCacheRegister commands have their broadcast counterpart which are almost identical. The Memory Controller provides the reply to all broadcast commands. These commands are only valid in kernel mode: if issued in user mode, they are simply ignored.
5.1.6.1 Broadcast Write Map Cache Entry
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.1.6.2 Broadcast Write Map Cache Register
This command writes the data provided to the specified register in all of the Map Caches in the system.
[Artwork node; type 'ArtworkInterpress on' to command tool]
5.2 The Registers
The following table describes the eight Map Cache registers. These registers can be read or written using the ReadMapCacheRegister and WriteMapCacheRegister commands.
Number Reg Name Description
0 AID 16 bits. Holds the address space identifier. For IOReads and IOWrites, the aid corresponding to a given virtual page is loaded into this register before the read or write is executed.
1 SharedPattern 22 bits. The SharedPattern and SharedMask are used to determine whether a specified virtual address is in the shared area: (vp ' SharedMask) = (SharedMask ' SharedPattern). (See Section 5.2.2.1 for details.) 
2 SharedMask 22 bits.
3 BypassPattern 22 bits. The BypassPattern and BypassMask are used to determine whether a specified virtual address is in the Bypass area. (vp ' BypassMask) = (BypassMask ' BypassPattern)(See Section 5.2.2.2 for details.)
4 BypassMask 22 bits.
5 BypassBase 22 bits. The BypassBase is used to map a virtual in the bypass area: rp=(BypassBase'BypassMask) ( (vp'~BypassMask). (See Section 5.2.2.2 for details.)
6 SubSetMask 22 bits. The SubSetMask and SubSetPattern registers are used to determine whether a specified virtual page is mapped by a particular Map Cache: (vp AND SubSetMask) ~= (SubSetPattern ' SubSetMask). (See Section 5.2.2 for more information.)
7 SubSetPattern 22 bits.
5.3 The Map Cache Table
5.3.1 The Map Cache Table: Hashing Function
The Map Cache Table is read during Map Request and Read Entry operations; it is written during Write Entry and Broadcast Write Entry operations if:
mode=0 (kernel)
aid is not -1
vp is not in the bypass area
The address of an entry in the Map Cache Table is determined by a hashing function of the virtual page and the aid. The virtual page is divided into three subfields, vp=vpH|vpM|vpL, with vpL the low-order byte, vpM the next one, and vpH the high-order 6 bits. Similarly, aid=aidH|aidL, where aidL is the low-order byte. Then h=vpL XOR vpM XOR aidL XOR aidH.
This is a good hasing function: it is insensitive to the fact that some bits of vp might be stuck if the map cache maps only a part of the address space.
5.3.1 Flushing the Map Cache Table
It is not possible in this implementation of the Map Cache to selectively flush all entries corresponding to a given aid. Instead, the whole Map Cache Table must be flushed. This is done with 256 transactions, each flushing a single entry of the table. To insure that the whole table is flushed, the hashing function was described above in order to infer a good set of vp's and aid's.
The most efficient flushing procedure is to pick a fixed aid, for example aid=1, avoid all special cases for vp (i.e. bypass and shared area), and perform the flush for 256 consecutive values of vp, as follows:
WriteRegister[aid𡤁]
FlushEntry[vp]
FlushEntry[vp+1] . . .
FlushEntry[vp+255]
5.4 The DBus Interface
The DBus is a serial data path into the Map Cache used for initialization and diagnostic purposes. For full details on using the DBus, see DBusDoc.tioga. The Map Cache has two registers that can be initialized and/or read over the DBus. Their addresses (path numbers) are as follows:
Addr 0: Chip Identification
 16 bits, Read Only. Indicates the type and version of the Map Cache. The 16 bits are broken down into 3 fields: a 4-bit fixed header (0101), a 6-bit chip type (Map Cache=9), and a 6-bit version number (version 0). The current Chip Identification Number for the Map Cache is: 0101 0010 0100 0000.
Addr 1: DynaBus DeviceID
 10 bits, Read/Write. Specifies the DynaBus Device ID for the Map Cache. This is a unique identifier loaded during system initialization.
6.0 Detailed Description of Each Pin 
6.1 DynaBus Pins
The following table describes the DynaBus pins of the Map Cache.
Pin Name I/O Pin Description
RequestOut O 2 bits, indicates arbiter request code as follows:
  00: no request (rescind bus hold)
  01: unused
  10: unused
  11: high priority, two-cycle request
SpareOut O 2 bits, driven to 0 when DataOut is driven, floated otherwise. Present only for compatibility
SStopOut O Always driven to 0. Present only for compatibility.
SharedOut O Always driven to 0. Present only for compatibility.
OwnerOut O Always driven to 0. Present only for compatibility.
HeaderCycleOut O Driven high when the header cycle of a packet is output on DataOut, driven low when data cycles are output on DataOut, floated when DataOut is floated.
ParityOut O Always driven to 0. Present only for compatibility.
DataOut O 64-bit wide DynaBus data output. Floated except when Grant is assserted (with 1 cycle of pipeline delay).
Grant I Packet grant from the arbiter. Data transmission on DataOut starts on the next clock edge.
HiPGrant I Ignored, present only for compatibility.
LongGrant I Ignored, present only for compatibility.
SpareIn I 2 bits, ignored, present only for compatibility.
SStopIn I Ignored, present only for compatibility.
SharedIn I Ignored, present only for compatibility
OwnerIn I Ignored, present only for compatibility
HeaderCycleIn I Indicates header cycles coming from the DynaBus.
ParityIn I Ignored, present only for compatibility.
DataIn I 64-bit wide DynaBus data input.
Clock I DynaBus clock input.
CkOut O Clock feedback output. Used to adjust the clock skew based on internal clock buffering delay.
TestEn I 1 bit. This signal is used to reduce the number of pins that need to be contacted for testing purposes. It relates only to the operation of the DynaBus data lines. When TestEn is de-asserted, the DataIn and DataOut pins are completely independent of each other. When TestEn is asserted, the DataOut signals are connected internally to the DataIn pins, so that when a DynaBus request is granted, the DataIn pins are driven with the DataOut signals.
 
6.2 DBus Pins
The following table describes the DBus pins of the Map Cache. The reader is referred to the DBus specification for details.
Pin Name I/O Pin Description
DSelect I DBus selection. This line is asserted (high) when the Map Cache should perform a non-address operation on the DBus.
DSerialOut O Data emitted serially on the DBus by the Map Cache. This line is floated except when DSelect is asserted.
DSerialIn I DBus serial input data and address.
nDReset I System reset (active low)
nDFreeze I Ignored by Map Cache.
DExecute I DExecute asks the Map Cache to perform an execute cycle instead of a data/address transfer on the next positive edge of DShiftCk.
DAddress I When high, address bits are presented serially on DSerialIn. The last three bits presented specify the DBus internal register selected.
DShiftCK I DBus shift clock.
7.0 DC Characteristics
This section lists the Direct Current characteristics of each signal. The signal types may be: input, output, tristate, open drain, etc. Group signals with the same characteristics together. A couple sample entries from the arbiter are given. Copy more table entries as needed.
Pin Name Signal Type Voltage  Current
Group D 5V output L 0.5 2 ma
  H 4.0 0
DSerialOut 5V Tri-state L 0.5 2 ma
  H 4.5 2 ma
Pin Type Pin Name
Group D nDHybridSel 
 DBdSel
CkOut
8.0. AC Characteristics
A. Definitions
The timing characteristic of each port are described in this section. It is generally assumed that the charcteristics of all the wires connecting a chip to a particular component are the same, so that Dynabus signals, DBug Bus signals, Backpanel signals, (etc.) may be characterized as a group.
[Artwork node; type 'Artwork on' to command tool]
Figure 4: Input Signal Characteristics
Ts (setup time) = the mimimum time a signal must be stable before the rising edge of the clock.
Th (hold time) = the mimimum time a signal must be stable after the rising edge of the clock.
[Artwork node; type 'Artwork on' to command tool]
Figure 5: Output Signal Characteristics
Tcycle = the time interval between successive rising edges of the clock
Tpd (propagation delay) = the waiting time after the clock is high until an output becomes valid.
Tm (maintenance of old data) = the time after rising edge of next clock cycle that old data remains valid.
B. Values
Qualififed Pin Name Tmin Ttypical Tmax
Tcycle 20ns 25ns 27ns
Ts.Dynabus In (setup.Dynabus In)  3ns 
Th.Dynabus In (hold.Dynabus In)  1ns
Tpd.Dynabus Out (propagation delay.Dynabus Out)  5ns
Tm.Dynabus Out (maintain.Dynabus Out)  2ns
   
   
9.0 Physical Pin-Out For Each Package
9.1 Physical die pin-out
This section indicates the pin-out of the Map Cache at the die level. In the following table, each colums describes a single side of the chip. Pads are numbered from left to right and top to bottom, from 1 to 67. The Map Cache uses the standard June87 padframe with signals pins on a single row inside and power supplies on the outside.
No Top No Bottom No Left No Right
1 DataIn[0] 1 DataIn[32] 1 N/A 1 HeaderCycleIn
2 DataOut[0] 2 DataOut[32] 2 N/A 2 HeaderCycleOut
3 DataIn[1] 3 DataIn[33] 3 N/A 3 OwnerIn
4 DataOut[1] 4 DataOut[33] 4 N/A 4 OwnerOut
5 DataIn[2] 5 DataIn[34] 5 N/A 5 SharedIn
6 DataOut[2] 6 DataOut[34] 6 N/A 6 SharedOut
7 DataIn[3] 7 DataIn[35] 7 N/A 7 SStopIn
8 DataOut[3] 8 DataOut[35] 8 N/A 8 SStopOut
9 DataIn[4] 9 DataIn[36] 9 N/A 9 Grant
10 DataOut[4] 10 DataOut[36] 10 N/A 10 LongGrant
11 DataIn[5] 11 DataIn[37] 11 N/A 11 HiPGrant
12 DataOut[5] 12 DataOut[37] 12 N/A 12 RequestOut[1]
13 DataIn[6] 13 DataIn[38] 13 N/A 13 RequestOut[0]
14 DataOut[6] 14 DataOut[38] 14 N/A 14 DShiftCK
15 DataIn[7] 15 DataIn[39] 15 N/A 15 DAddress
16 DataOut[7] 16 DataOut[39] 16 N/A 16 DExecute
17 DataIn[8] 17 DataIn[40] 17 N/A 17 nDFreeze
18 DataOut[8] 18 DataOut[40] 18 N/A 18 nDReset
19 DataIn[9] 19 DataIn[41] 19 N/A 19 DSerialIn
20 DataOut[9] 20 DataOut[41] 20 N/A 20 DBusOut
21 DataIn[10] 21 DataIn[42] 21 N/A 21 DSelect
22 DataOut[10] 22 DataOut[42] 22 N/A 22 Clock
23 DataIn[11] 23 DataIn[43] 23 N/A 23 CkOut
24 DataOut[11] 24 DataOut[43] 24 N/A 24 N/A
25 DataIn[12] 25 DataIn[44] 25 N/A 25 N/A
26 DataOut[12] 26 DataOut[44] 26 N/A 26 N/A
27 DataIn[13] 27 DataIn[45] 27 N/A 27 N/A
28 DataOut[13] 28 DataOut[45] 28 N/A 28 N/A
29 DataIn[14] 29 DataIn[46] 29 N/A 29 N/A
30 DataOut[14] 30 DataOut[46] 30 N/A 30 N/A
31 DataIn[15] 31 DataIn[47] 31 N/A 31 N/A
32 DataOut[15] 32 DataOut[47] 32 N/A 32 N/A
33 DataIn[16] 33 DataIn[48] 33 N/A 33 N/A
34 DataOut[16] 34 DataOut[48] 34 N/A 34 N/A
35 DataIn[17] 35 DataIn[49] 35 N/A 35 N/A
36 DataOut[17] 36 DataOut[49] 36 N/A 36 N/A
37 DataIn[18] 37 DataIn[50] 37 N/A 37 N/A
38 DataOut[18] 38 DataOut[50] 38 N/A 38 N/A
39 DataIn[19] 39 DataIn[51] 39 N/A 39 N/A
40 DataOut[19] 40 DataOut[51] 40 N/A 40 N/A
41 DataIn[20] 41 DataIn[52] 41 N/A 41 N/A
42 DataOut[20] 42 DataOut[52] 42 N/A 42 N/A
43 DataIn[21] 43 DataIn[53] 43 N/A 43 N/A
44 DataOut[21] 44 DataOut[53] 44 N/A 44 N/A
45 DataIn[22] 45 DataIn[54] 45 N/A 45 N/A
46 DataOut[22] 46 DataOut[54] 46 N/A 46 N/A
47 DataIn[23] 47 DataIn[55] 47 N/A 47 N/A
48 DataOut[23] 48 DataOut[55] 48 N/A 48 N/A
49 DataIn[24] 49 DataIn[56] 49 N/A 49 N/A
50 DataOut[24] 50 DataOut[56] 50 N/A 50 N/A
51 DataIn[25] 51 DataIn[57] 51 N/A 51 N/A
52 DataOut[25] 52 DataOut[57] 52 N/A 52 N/A
53 DataIn[26] 53 DataIn[58] 53 N/A 53 N/A
54 DataOut[26] 54 DataOut[58] 54 N/A 54 N/A
55 DataIn[27] 55 DataIn[59] 55 N/A 55 N/A
56 DataOut[27] 56 DataOut[59] 56 N/A 56 N/A
57 DataIn[28] 57 DataIn[60] 57 N/A 57 N/A
58 DataOut[28] 58 DataOut[60] 58 N/A 58 N/A
59 DataIn[29] 59 DataIn[61] 59 N/A 59 N/A
60 DataOut[29] 60 DataOut[61] 60 N/A 60 N/A
61 DataIn[30] 61 DataIn[62] 61 N/A 61 N/A
62 DataOut[30] 62 DataOut[62] 62 N/A 62 N/A
63 DataIn[31] 63 DataIn[63] 63 N/A 63 N/A
64 DataOut[31] 64 DataOut[63] 64 N/A 64 N/A
65 ParityIn 65 SpareIn[1] 65 N/A 65 N/A
66 ParityOut 66 SpareOut[0] 66 N/A 66 N/A
67 SpareIn[0] 67 SpareOut[1] 67 Test 67 N/A
Here is a diagram indicating the range of pins that are located on each side of the PGA:
[Artwork node; type 'Artwork on' to command tool]