THE DRAGON DBUS - DESCRIPTION AND SPECIFICATIONS
THE DRAGON DBUS - DESCRIPTION AND SPECIFICATIONS
THE DRAGON DBUS - DESCRIPTION AND SPECIFICATIONS
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
DRAGON PROJECT — FOR INTERNAL XEROX USE ONLY
The Dragon DBus
Description and Specifications
Jean-Marc Frailong
Dragon-86-xx Written August 19, 1986 Revised March 31, 1987
© Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: The DBus is used both to initialize a Dragon machine and to debug it. This document is intended to be used both as a convenient source for information about the DBus and as a reference manual for bus specifications.
Acknowledgements to Rick Barth, Jim Gasbarro, Ed McCreight and others who designed the first DBus and discussed on the new version.
Keywords: DBus, LSSD, DynaBus, IOBridge, Bootstrap, Debug
FileName: [Indigo]<Dragon>DBus>DBusDoc.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. DBus definition
3. DBus Usage in Components
4. DBus transmission and decoding
5. DBus Controller
Appendix A. Well-known DBus addresses
Appendix B. Currently allocated chip types
ChangeLog
1. Introduction
1.1. Aims
The DBus is an asynchronous serial bus used for initialization and diagnostics within a Dragon system. These operations are accomplished by designing into each device connected to the DBus a set of shift registers (or scan paths) of arbitrary length. The DBus provides the timing and control necessary to serially load data into the scan paths and eventually transfer in parallel that data to the internal registers of the component. It also provides a mechanism to parallel load internal state of the component into the scan paths for serial transfer to the outside world. There is a centralized controller/generator for the DBus located on the I/O board. All Dragon-related ICs should support the DBus. All ICs connected to the DynaBus must support the DBus, since it is through the DBus that their DynaBus identifier will be set during the bootstrap process.
1.2. A little history
The first version of the DBus was designed for the DragonFly machine. When DragonFly was dropped and the June87 project was initiated, it was decided to make the DBus synchronous with the DynaBus, use the same propagation mechanism and use LSSD as the preferred DBus implementation in standard-cell chips.
It appeared that this solution did not meet our requirements:
- Stopping the machine synchronously is extremely hard due to the high degree of pipelining over the DynaBus. Moreover, it would require all registers to be DBus-controlled, resulting in a high overhead in standard-cell designs (which are already flip-flop dominated).
- Clock distribution needed the DBus to setup both the clock frequency and the skew tuning. This precluded the use of a DynaBus-synchronous DBus.
- An asynchronous DBus fits badly the LSSD methodology that was planned. First, it is almost unusable for chip debugging (and production testing) due to its very low speed (synchronization with DynaBus clock requires 3-10 clock periods). Since synchronous stopping was given up, it also meant that machine-level debugging using the DBus would be very restricted: the visible state would correspond to a much later date than the failing state. Thus, systematic access to detailed internal state would not provide an aid commensurate with its cost.
The solution retained was to lower our expectations of the DBus considerably. An asynchronous DBus would solve the clock tuning problem and provide downloadable constants needed for system initialization (DynaBus IDs, arbiter parameters, ...). Judicious use by designers of shadow registers should aid in debugging.
1.3. Notations and generalities
A component is the basic DBus client. It contains multiple scan paths. In the current implementation, all components are single ICs.
All signals are assumed to follow positive logic unless they have an "n" at the beginning of the signal name. The DBus is transmitted using TTL/CMOS levels: 0 is GND, 1 is +5V. Some of the DBus signals use tri-state ports.
DBus signals have no timing relationship to other clocks in the system. DBus clients must synchronize the DBus to their requirements, as explained in following sections.
2. DBus definition
2.1. Signals
The DBus has 7 signal lines that are listed below, together with the meaning of each group of lines. Signal directions are indicated from the point of view of a component.
DShiftCK: (I)
Shift clock for the currently selected scan path. Data must be transferred on the positive edge of this signal. If the DAddress line is active, the shift clock is used to transfer component address bits instead of data bits.
DAddress: (I)
Indicates that the current DShiftCK cycle is transferring address bits. Components are implicitly deselected when DAddress is asserted.
DSerialIn: (I)
Drives the data input lines of the scan path.
DSerialOut: (O, TS)
Driven by the selected component scan path data output line. An unselected component (DSelect not asserted) must float this line.
DExecute: (I)
Requests the component to perform an execute cycle on the next positive edge of DShiftCK, instead of a data/address transfer. Precise semantics are component dependent.
nDFreeze: (I)
Active low. Requires all components to stop operation as soon as possible. Due to the asynchronous structure of the DBus, all components will not exactly stop at the same time. Always active when DShiftCK is active. The DynaBus has a line with semantics similar to nDFreeze, named StopIn. The major difference between nDFreeze and StopIn is that StopIn is synchronous with the DynaBus clock and uses the DynaBus transport mechanism.
nDReset: (I)
Active low. Resets all components to their power-on state.
Moreover, components receive an additional signal DSelect that represents a decoding on the most significant bits of the DBus address performed by board-level logic. This signal is not a part of the DBus on the backpanel.
DSelect: (I)
Indicates that the component may be selected for this DBus operation. When DSelect is inactive, the component should ignore DShiftCK and float DSerialOut except if DAddress is asserted. In that case, it must shift the address bits in its internal address register for later processing.
2.2. Basic shift cycle
The basic shift cycle consists of shifting a complete scan path by one position, taking new data from the DSerialIn line into the LSB of the scan path. Data are always shifted MSB first. The DSerialOut line is connected (through a tri-state gate) to the MSB of the scan path. The DSerialIn line must be sampled on the raising edge of DShiftCK. The value of DSerialOut must change some time (transmission + setup) before the next raising edge of DShiftCK. nDFreeze will always be asserted (low) during a basic shift cycle. Refer to Fig. 1 for the basic shift cycle timing. It should be noticed that reasonable in-chip delays on DShiftCK are supported since the DBus controller guarantees that DSerialIn will be modified only on the negative edge of DShiftCK.
A shift cycle will be:
- ignored if neither DSelect nor DAddress are asserted
- a data transfer cycle if DSelect is asserted, but not DAddress nor DExecute
- an execute cycle if DSelect and DExecute are asserted, but not DAddress
- an address transfer cycle if DAddress is asserted, but not DSelect
DAddress and DSelect will never be asserted simultaneously during a shift cycle. Thus, basic shift cycles are interpreted according to the following table:
DAddressDSelectDExecuteAction to be performed
No No No No action
No No Yes No action
No Yes No Data transfer cycle
No Yes Yes Execute cycle
Yes No No Address transfer cycle
Yes No Yes -- Never occurs --
Yes Yes No -- Never occurs --
Yes Yes Yes -- Never occurs --
2.3. Address transfer and selection
When a shift cycle occurs while DAddress is asserted, the data must be shifted into a 3-bit address shift register. When DAddress is rescinded, the current contents of this register indicates which scan path is currently selected (1 of 8) in the component. The real DBus address is longer than 3 bits, but all more significant bits are decoded outside the component and result in the DSelect line. DSerialOut must be floated during an address transfer. Refer to Fig. 2 for the address transfer and selection timing. It should be noted that address transfer occurs in all components simultaneously.
DAddress will be asserted before the first positive edge of DShiftCK and will be removed after the last negative edge of DShiftCK.
Since external hardware guarantees that DSelect is rescinded immediately after DAddress is asserted (well before DShiftCK presents a positive edge) and is asserted again (if the component is selected) after DAddress is rescinded well before DShiftCK presents a positive edge), components do not need to do anything special to handle the overlap of DAddress and DSelect. Especially, this implies that DSerialOut will automatically be floated during address transfer since it is floated when DSelect is not asserted (c.f. 2.4.).
A component with a single scan path may ignore completely address transfers.
2.4. Data transfer
When a shift cycle occurs while DAddress is not asserted, the component must ignore it unless DSelect is asserted. In that case, and if DExecute is not asserted, the component must shift the data into the currently selected scan path (1 of 8) and drive the DSerialOut line. DSerialOut must be tri-stated when the component is not selected. When a scan path number not supported by the component is specified in the address, the component is free either to use any of its scan paths or ignore the data transfer. Refer to Fig. 2 for detailed timing information.
DSelect is guaranteed to be asserted before the first positive edge of DShiftCK and to be deasserted some time after the last positive edge of DShiftCK.
2.5. Execute request
When a shift cycle occurs while DAddress is not asserted, the component must ignore it unless DSelect is asserted. If DExecute is asserted, the component will perform an execute cycle for each positive edge of DShiftCK. The precise semantics of execute cycles are component dependent. Refer to Fig. 2 for detailed timing information. DSerialOut may be driven by the component, but will be ignored by the DBus master controller. A component may use its 3-bit DBus address as an additional qualifier of execute cycles.
The following actions are typical of what components might do for execute cycles:
- copy some internal state into DBus-scannable registers (shadow registers)
- reload some internal state from DBus-loadable registers
- interpret the contents of a scan path to access (read or write) otherwise inaccessible internal state (such as a RAM)
- initiate a test sequence
- single-step the component
2.6. Freeze and Reset timings
The nDFreeze signal (active low) must be interpreted by all components, whether they are selected or not. Components should stop internal processing (insofar as it is possible) while nDFreeze is asserted. Shift cycles and Execute requests occur only when nDFreeze is asserted. Fig. 2 gives a typical timing diagram for a complete DBus transaction, including Freeze, address setup, scan, execute, and Freeze removal.
In order to avoid shorts, a component selected during a Freeze should set all its bidirectional or tri-state pins to a non-driving state (either input or float), except for the DSerialOut pin. The reason for this treatment is that shifting a scan path may result in modifying the direction of data flow in a way not compatible with other chips connected to the selected chip. Moreover, components may need to float all bidirectional or tri-state pins to a non-driving state when nDFreeze is asserted, irrespective of DSelect, if they freeze into a possibly dangerous output configuration (for example, this is the case for components that stop immediately when nDFreeze is asserted).
nDReset (active low) requires all components (selected or not) to return to an idle state adequate to start operation. This state should be maintained as long as nDReset is kept active. The reader is referred to the bootstrap sequence description for further information on Reset processing. Timing of the nDReset is not specified, but may be assumed for all practical purposes to be infinite.
Chip implementors must be aware that nDReset is completely independent from all other DBus signals. It is expected that the bootstrap sequence will make full use of the DBus while nDReset is asserted.
2.7. Timing diagrams
The following diagram and table gives basic shift cycle timings.
[Artwork node; type 'ArtworkInterpress on' to command tool]
Figure 1 : Basic shift cycle timing diagram
TimeMinMaxComments
T1 1000 ns  DShiftCK cycle time
T2  500 ns  DShiftCK phase duration
T3  0 nsT2DShiftCK down to DSerialIn update
T4  0 nsT2DShiftCK up to DSerialOut update
The following timing diagram and table describes all the types of transactions supported by a component on the DBus.
NOTE: The delay between an execute cycle and the following cycle is defined as a minimum. Components may require longer delays to perform an execute cycle. It is the DBus control software's responsibility to ensure that an adequate delay is added at that point.
[Artwork node; type 'ArtworkInterpress on' to command tool]
Figure 2 : DBus component transactions timing diagram
TimeMinMaxComments
1 4*T1  nDFReeze change to next DBus event
2 5 ns100 ns enable/disable time
3 T1  delay between DBus events
4  = T1 =  DShiftCK cycle time
5 0 nsT1 DAddress to DSelect
3. DBus Usage in Components
3.1. General requirements
All components should have at least two scan path, one for identification and another for access to their internal structure. DynaBus clients should also have a scan path to setup their DynaBus ID.
3.1.1. Component identification
Each component must provide a 16-bit read-only scan path that contains a fixed value (initialized at reset time) identifying the chip. The chip ID must be of the form 0101ccccccrrrrrr, where 0101 is a fixed header used for checking purposes, cccccc (6 bits) is the type of component and rrrrrr (6 bits) is a revision number. The component ID scan path must be scan path #0 for the chip. Following the bit ordering convention outlined above, the component ID is shifted out MSB first (i.e. fixed header first).
To ensure that the component ID always supplies a consistent value, it is recommended to reload it as often as possible. A good way to achieve this is to reload it systematically on address transfer cycles.
3.1.1. DynaBus identification
Each component connected to the DynaBus must provide a 10-bit read-write scan path that will define its DynaBus ID. This identifier must, as all scan paths, be shifted out MSB first. The DynaBus ID scan path must be scan path #1 for the chip. This scan path should be handled inside the designed as a ROM providing the DynaBus ID.
3.2. DBus in standard-cell designs
Standard-cell designs should use the following building blocks for their DBus interface. All the cells and icons are provided in the DBus ChipNDale library.
3.2.1. Basic DBus interface
The DBusInterface icon implements the DBus buffering, address transfer and component identification. It receives the DBus and DSelect lines from the pads. It provides buffered signals for DShiftCK, DExecute, DFreeze (positive logic!), DReset (positive logic!) and DSerialIn. It also provides 7 pairs of path control lines (selection and serial output) for the user scan paths (scan path #0 is used internally for component identification).
The icon needs 3 parameters:
- Type: a 6-bit constant giving the component type for identification
- Version: a 6-bit constant giving the component version for identification
- CKBuff: the buffering strength required for DShiftCK. The value depends on the load on DShiftCK (count 1 for every 4 flip-flops connected to DShiftCK).
The DynaBus ID scan path is not provided in the basic DBus interface.
The DSerialOut output pad should be a tri-state pad enabled by DSelect.
3.2.2. DBus constants
The DBusConstant icon provides DBus-loadable "constants" of the chip. The icon uses a single parameter b denoting the number of bits. The value of the constant is available in direct and complemented forms.
The DShiftCK and DSerialIn inputs should be connected to the corresponding outputs of DBusInterface. SelPath and OutPath should be connected to corresponding (same number) SelPathi and OutPathi on DBusInterface. Multiple DBusConstants may be chained to form a single scan path. In that case, the OutPath must be chained to the DSerialIn of the following DBusConstant, the first DSerialIn fed from the DBusInterface and the last OutPath connected to OutPathi on the DBusInterface. It may be necessary, in case of very high loading, to add buffering to the SelPathi signal.
3.2.3. DBus shadow registers
The DBusShadowReg icon provides the ability to load data from the inside of the chip into a DBus-readable register. The data is loaded from the D input into the register by an execute cycle when the scan path is selected. The designer is responsible to ensure that the data is stable at that instant (the nDFreeze signal has been asserted for some time, so this condition is automatically met for data coming from registers enabled by nDFreeze). The icon uses a single parameter b denoting the number of bits.
The DShiftCK and DSerialIn inputs should be connected to the corresponding outputs of DBusInterface. SelPath and OutPath should be connected to corresponding (same number) SelPathi and OutPathi on DBusInterface. Multiple DBusConstants may be chained to form a single scan path. In that case, the OutPath must be chained to the DSerialIn of the following DBusConstant, the first DSerialIn fed from the DBusInterface and the last OutPath connected to OutPathi on the DBusInterface. It may be necessary, in case of very high loading, to add buffering to the SelPathi signal.
3.2.4. DBus synchronizer
The DBusSync icon provides a synchronized DBus interface. The only signals generated are synchronous Reset and Freeze. The icon has two parameters ResetBuff and FreezeBuff indicating the amount of buffering to be provided for both signals.
3.2.5. LSSD
LSSD is no longer supported. Chip designers may still build their own LSSD mechanism, but no support is planned for this (refer to discussion in introduction).
3.3. DBus in custom designs
3.3.1. Using the standard cell building blocks
In a custom design, it is possible to implement the DBus as a standard-cell part of the chip. In that case, all comments in the previous section apply.
3.3.1. Going custom all the way
It may be more convenient to integrate the DBus functionality in the custom part of the chip. Designers must then take care to the following points:
- Float the DSerialOut pin when DSelect is not asserted
- Provide chip identification register (and DynaBus ID if relevant)
The schematics in the DBus ChipNDale library should provide a reasonable logical basis for any full-custom implementation. It is strongly recommended to deviate as little as possible from their structure.
3.4. System initialization, hardware faults and DBus
3.4.1. What must be done at boot time
When the machine is started (e.g. at power on), a number of things need to be done before the first instruction is executed on a Dragon processor. The following steps should be performed in order by the bootstrap processor (the PC/AT):
1. assert nDReset through power on detection or by software
2. assert nDFreeze to enable DBus operations
3. read and verify the hardware configuration by reading all component IDs on the DBus
4. set the DynaBus clock frequency to a reasonable value
5. tune clock skews in each hybrid to the "best" value
6. load unique DynaBus IDs into each DynaBus partner
7. load chip-dependent initialization constants into chips (arbiters, ...)
8. assert DynaBus StopOut/StopIn signal to prevent arbiters from running
9. remove nDFreeze, DBus will not be used any more
10. remove nDReset, allowing chips to start running (except arbiters)
11. remove DynaBus StopOut/StopIn to start all arbiters synchronously
12. load Dragon boot code into DynaBus memory through the IOBridge
13. start processors (remove the processor reset bit in caches)
The scheme outlined above requires that system components must start in precise order. It should be noticed that the StopOut/StopIn DynaBus signal, in addition to its function of stopping the machine after a hardware crash, is used to ensure synchronous start of all the arbiters in the system (this is a requirement of the arbiter implementation).
3.4.2. What must be done when a hardware fault occurs
When a component detects an error that cannot be corrected or signalled by software (bus parity error for example), it should set a flip-flop readable by the DBus (through a shadow register) and drive the StopOut DynaBus line with the output of this flip-flop. As a result, arbiters will deny further requests on the bus and the system will end in a logically frozen state (processors may not be frozen at that point if they loop on instructions contained in their instruction cache and have not data cache faults). The IOBridge will detect StopIn and interrupt the debug processor for fault processing.
3.4.3. Implications for chip designers
This scheme assumes that all chips respect the following requirements:
- A chip must remain in a constant state while nDReset is asserted.
- Chip-dependent initialization constants must be loadable while nDReset is asserted.
- Chips may start operating when nDReset is removed. They should wait a negative edge of StopIn before starting if synchronous start is essential.
- Processors should use the processor reset bit provided by caches.
- Chips raising StopOut must provide information on the hardware failure through the DBus (including a bit stating that the chip detected a hardware failure)
- When nDFreeze is asserted, chips should cease operations as soon as possible so that DBus-visible registers do not change values.
The arbiter should allocate DynaBus transactions only when nDReset and StopIn are both deasserted. Caches may need to reject processor requests when StopIn is asserted to prevent processors from running.
NOTE: Cache rejection of processor requests is subject to discussion as it raises a problem for the IOBridge which may hang on a PC bus cycle during a hardware crash, preventing the debug processor from regaining control. Two solutions are possible: a DBus constant in the cache may enable/disable this mechanism, or the IOBridge may time out on cache requests independently of the DynaBus time out. The former solution is simpler to implement, but cache timeout in the IOBridge may be required for safety reasons anyhow (if the IOBridge cache fails).
NOTE: There should be a way to support board identification. The arbiter is the logical chip to support such a mechanism, but the details have not been worked out yet.
The IOBridge should be able to control the StopOut DynaBus line by software from the PC side to permit system initialization. It should recognize hardware crashes (StopIn asserted while StopOut is not forced by software) and interrupt the debug processor. If the DBus controller is implemented in the IOBridge, it should also assert nDFreeze.
4. DBus transmission and decoding
This section is of interest only to the system-level design of the machine. Chip designers should not depend on this part of the DBus description.
4.1. Overview of DBus transmission
The DBus is transmitted directly throughout the system without any pipeline stages, in order to be independent from the DynaBus clock. It is amplified in each board by the bus interface hybrid, then within each hybrid by the bus interface chips.
All the transmission uses TTL/CMOS levels in positive logic: 0 is GND, 1 is +5V.
4.2. Hierarchical decoding and merging of DSerialOut lines
The DBus carries actually 16-bit addresses that are decoded hierarchically. The 16 bit address is transmitted MSB first, as all DBus data. It is split into 5 fields:
<BoardNum:4><HybridNum:4><InterfaceNum:3><ChipNum:2><PathNum:3>
The 13 MSB of this address are decoded in two stages to provides the DSelect lines. First, on each board, the arbiter receives the address, compares the BoardNum field to a hardwired slot number and decodes HybridNum into 16 DHybridSelect lines, conditionned by the correct recognition of BoardNum. One of these lines is actually used by the arbiter itself. Each hybrid may contain up to 8 DynaBus interface chips. Each of the interface chips receives a DHybridSelect line. It compares InterfaceNum with a hardwired constant (number of the interface chip in the hybrid) and decodes ChipNum into 4 DSelect lines, conditionned by the correct recognition of InterfaceNum and assertion of DHybridSelect. One of the 4 lines is actually used by the interface chip itself. Since most hybrids contain 4 interface chips, this means that an hybrid may contain up to 12 chips other than interfaces.
In terms of implementation, this means that the arbiter should keep all 16 bits of DBus address in its address register and that the interface chips need keep only the least significant 8 bits. This method of implementation allows to modify to MSB addressing structure without modifying the interface chips.
The DSerialOut lines originating from components are merged in a process inverse of the address decoding. First, DSerialOut lines of components inside an hybrid are tied together (all are exclusive tri-state signals) and fed to one of the interface chips. The interface chip buffers it and emits it to the board level with a tri-state gate controlled by its DHybridSelect line. All lines at board level are tied together and they are fed into an open-collector gate in order to merge the DSerialOut lines for all boards.
NOTE: Using a tri-state gate instead of an open collector for this last stage is possible if the arbiter emits the DBoardSelect line which is currently only internal to the arbiter. Another possibility is to have the board-level DSerialOut line be fed into the arbiter to produce the backpanel DSerialOut line through a tri-state gate controlled by the arbiter.
5. DBus Controller
5.1. Functionality
The DBus controller is the only master on the DBus. It is operated by the debug processor (PC/AT). The interface to the PC/AT should provide the capability to use all the cycle types of the DBus (address, data and execute) and programmable control of the nDReset and nDFreeze signals.
5.2. Basic TTL implementation
A very simple implementation of the DBus controller as a TTL peripheral on the PC/AT bus is possible using two PALs (address decoding not included). The idea is just to provide a read/write register on the PC bus that controls all lines of the DBus. All timings are then under control of a program running on the PC/AT.
The drawback of this implementation is its low speed (current estimates are on the order of 10-20 kbits/sec).
A detailed implementation will be given when complete.
5.3. Integrated implementation
The final implementation of the DBus controller will be inside the IOBridge. External buffers will nevertheless be required to drive the DBus with sufficient power.
This implementation will provide a higher level protocol. It is expected to provide noticeably better performances (current estimates are on the order of 200 kbits/sec):
- Send component address
- Send & receive up to 32 bits of data
- Execute
- Explicit control of nDReset and nDFreeze.
The drawback of this implementation is that it may not work in case of hardware failure in the IOBridge itself, although all cares will be taken to make it as robust as possible.
A detailed implementation will be given when complete.
Appendix A. Well known DBus addresses
In order to recognize the hardware configuration, the bootstrap code will make a number of assumptions on the structure of DBus addresses:
- Arbiters (and arbiters only) respond to addresses of the form bbbb000000000ppp where bbbb is the board number and ppp the path number within the arbiter
- Interface chips (and interface chips only) respond to addresses of the form bbbbhhhhiii00ppp where bbbb is the board number, hhhh the hybrid number (different from 0), iii the interface chip number on the hybrid and ppp the path number within the interface chip.
- Path 0 is always the component identification.
The method to access a board type through the arbiter has not yet been specified, but should use DBus address of the form bbbb0000xxxxxppp with xxxxx#0.
Appendix B. Currently allocated chip types
The following table gives a complete list of currently allocated chip types (chip types are encoded on 6 bits).
Chip typeChip
 00 ** Reserved **
 01 Arbiter
 02 DynaBus Interface
 03 EU
 04 IFU
 05 Small Cache
 06 Memory controller
 07 IOBridge
 08 Display controller
 09 Map cache
 0A Unused
 0B Unused
 0C Unused
 0D Unused
 0E Unused
 0F Unused
 10-3F Unused
ChangeLog
Jean-Marc Frailong August 20, 1986 1:26:08 pm PDT
Clarifications, figure corrected
changes to: 2a: open-collector outputs, 3c: nDFreeze timing spec, 4a: component ID, 4b: Fig 9
Jean-Marc Frailong October 6, 1986 6:06:21 pm PDT
Clarification on shift timing, updated description of DBus board-level decoding with hierarchical addressing
changes to: 3.b (clarified chaining of components), 4.a (updated component ID definition), 5. (new version of the DBus board-level logic), 3, 4, 5, 6
Rick Barth November 12, 1986 4:45:47 pm PST
Added a section which describes the machine boot sequence and its interaction with the DBus. Refined the relationship between nDFreeze, the DynaBus clock and any derived clocks. Addresses are now transmitted MSB first to be compatible with the manner in which component ID's are shifted. Major sweep through the document cleaning up little errors.
Jean-Marc Frailong March 17, 1987 12:26:48 pm PST
Complete rewrite of document to take in account asynchronous DBus, removal of general LSSD strategy and synchronous stop, DBus ChipNDale library
changes to: all document rewritten, 3
Jean-Marc Frailong March 31, 1987 11:17:11 am PST
Added list of chip types in use
changes to: Contents new entry for Appendix B, AppendixB added