DYNABUS CHANGE SUMMARY
DYNABUS CHANGE SUMMARY
DYNABUS CHANGE SUMMARY
1
1
1
Dynabus Change Summary
Written November 16, 1988   Revised November 16, 1988
© Copyright 1986, 1987, 1988 Xerox Corporation. All rights reserved.
Abstract: This document describes the changes made to the Dynabus logical specifications as a result of interactions with Sun Microsystems. The current version of the Dynabus logical specifications does not incorporate these changes, so that this change list should be considered an addendum to the logical specifications.
Keywords: Dynabus Logical Specifications, Changes
FileName: DynabusConsistency.tioga, .interpress
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304



Dragon Project - Xerox Private Data
Contents
1. Consistency
2. IO
3. Aribitration
4. Reliability
5. DBus
1. Consistency
The changes described in this section are in one way or other related to the Dynabus consistency algorithm.
1.1 Choice of Consistency Units
The original specification supported the 32 bit word as the unit of consistency.
The change is to maintain consistency over 8 bit, 16 bit, 32 bit, and 64 bit quantities with the restriction that quantities are size aligned (8 bit quantities are byte aligned, 16 bit quantities are 16 bit aligned, etc.). The transactions WriteSingle and ConditionalWriteSingle carry 64 bits of data, the address of this data, and four bits indicating the size and alignment of the quantity to be written. The four bits encode the following 15 cases: 1 byte (8 cases), 2 bytes (4 cases), 4 bytes (2 cases), and 8 bytes (1 case).
1.2 Transactions
The original specification supported the following consistency related transactions: ReadBlock, WriteBlock, FlushBlock, WriteSingle, ConditionalWriteSingle, Map, and DeMap.
The change is to:
(1) add KillBlock (eliminates block from all caches but requester)
(2) extend DeMap semantics to also implement ProbePage (returns sharing information on page basis), and KillPage (eliminates page from all caches)
1.3 Size of Transport Unit (Block)
The original specification supported a block size of 32 bytes.
We may change the block size to 64 bytes. In any event only one block size will be supported.
1.4 Real Address size
The original specification supported 32 bit real addresses.
The change is to increase this to 36 bits.
2. IO
The changes described in this section are related to the IO portion of the Dynabus protocol.
2.1 Control Space
The original specification had the notion of IO address space.
The change is to rename IO address space to Control space.
2.2 Byte Support
The original specification did not support Byte operations for IORead and IOWrite.
The change is to support reads and writes to 8 bit, 16 bit, 32 bit and 64 bit quantities via ControlRead and ControlWrite (the renamed versions of IORead and IOWrite). ControlRead and ControlWrite carry 64 bits of data, the address of this data, and a four bits indicating the size and alignment of the quantity to be read or written. The four bits encode the following 15 cases: 1 byte (8 cases), 2 bytes (4 cases), 4 bytes (2 cases), and 8 bytes (1 case).
2.3 Transactions
The original specification supported the following IO related transactions: IORead, IOWrite, and BIOWrite.
The change is to:
(1) replace BIOWrite by Interrupt (the interrupt scheme is unchanged)
(2) rename IORead and IOWrite to ControlRead and ControlWrite, and
(3) add ControlReadBlock, and ControlWriteBlock (a block is 32 bytes cf. section 1.3).
2.4 IO Address size
The original specification supported 32 IO addresses.
The change is to increase this to 36 bits.
3. Arbitration
The changes described in this section are related to the interface between a Dynabus device and the arbiter.
3.1 Request Port
In the original specification, the request port consisted of Request[0..1], SStopOut, SharedOut, and OwnerOut.
The new interface consists of Request[0..2], SharedOut, OwnerOut, and RParity. The request wires carry information about the priority and length of a request, with the priority indicated by one cycle and the length indicated by the very next cycle:
1st Cycle  P0 P1 P2
2nd Cycle x x L
In this encoding, P0P1P2 is a priority that has the following values:
 7 stop
 6 reply high
 5 reply low
 4 hold
 3 request high
 2 request medium
 1 request low
 0 idle
L is a length that has the following values:
 0 2 cycle packet
 1 5 cycle packet
and x represents don't care.
SharedOut and OwnerOut have the same semantics as before. RParity is a new wire that carries parity computed over the other signals in the group.
3.1 Grant Port
In the original specification, the grant port consisted of Grant, GrantLength, GrantPriority, SharedIn, and OwnerIn.
The new interface consists of Grant, GrantLength, SharedIn, OwnerIn, and GParity. The Grant wire indicates when a device has grant, while the GrantLength wire indicates the length of the packet for which the grant has been given. GrantLength is bussed, and is valid only in the cycle just before Grant. GParity carries parity computed over the other signals in the group.
4. Reliability
The changes described in this section are related to reliability. It helps to have the following model of what happens following an error: When an error occurs, detection mechanisms help to discover it as quickly as possible. A stopping mechanism brings Dynabus activity to a halt and simultaneously relays boolean error information to a service processor. The service processor then diagnoses the error, disables failed components, and restarts the system with as little loss of state as possible.
The first two items relate to detection, the third to stopping, and the remainder to diagnosibility.
4.1 Parity Checks
The original specification carried a single parity bit for the 64 data wires of the Dynabus. However, the timing and semantics of this parity bit were not defined.
The change is to add parity to all Dynabus signals. These signals are divided into three groups (on the basis of timing and logical grouping), and each group has a single parity bit that is delayed one pipeline stage relative to data. The three groups are:
a. Data group: Data[0..63], HeaderCycle, DParity
b. Arbitration request group: Request[0..2], Shared, Owner, RParity
c. Arbitration grant group: Grant, GrantLength, Shared, Owner, GParity
All Dynabus chips must generate and check parity. When a device receives a packet with a parity error in the header cycle, it must ensure that the packet has no effect on its internal state. When a device receives a packet with a parity error in a data cycle, it may process this packet to completion. In any event, the device should issue Stop to the arbiter.
4.2 Arbitration Consistency Checks
In the original specification, a device could check for unsolicited grants.
The change is to have client devices perform two checks on arbitration grants they receive: (1) they must check for unsolicited grants, and (2) they must check for grants they never receive. The first check should be imlemented by verifying the length of a grant with what (if anything) was requested. The second check should be implemented via timeout.
4.3 Stopping Mechanism
All Dynabus errors must be reported by asserting Stop on the arbiter request wires. Assertion of Stop does two things: it quickly halts all Dynabus traffic because Stop has the highest priority; and it signals the service processor that a Dynabus error has occurred. The service processor will then try to diagnose the error.
Packets received after asserting Stop but before Stop has taken effect must be processed normally by each device.
4.4 Data Snapshot
When a chip first detects a parity error, it should remember the offending data, so that the service processor can examine it.
4.5 Data History
The bus interface chip (BIC) should keep a log of the last several cycles of data on its unidirectional input bus. When it receives a Stop command, it should freeze the log, so that the service processor can examine it.
4.6 Grant History
Each arbiter chip should keep a log of the last several cycles of its grant group output signals. When it receives a Stop command, it should freeze the log, so that the service processor can examine it.
4. DBus
The signal nDFreeze is removed from the DBus.