[_CD4_]<dragon7.0>DBus>DBusDoc.tioga!6

THE DRAGON DBUS

The Dragon DBus

Description and Specifications

Jean-Marc Frailong

Dragon-88-xx Written August 19, 1986 Revised November 21, 1988

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 DBus specification and an application manual. This version of the document has been revised to incorporate modifications required for SunDragon.

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: [Dragon]<Dragon7.0>DBus>DBusDoc.tioga, .interpress

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

Dragon Project - Xerox Private Data

Contents

1. Introduction

2. DBus definition

3. DBus Usage in Components

4. DBus transmission and decoding

5. DBus Controller

6. Modifications to DBus for SunDragon

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 DynaBus 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:

DAddress DSelect DExecute Action 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

Time Min Max Comments

T1 1000 ns DShiftCK cycle time

T2 500 ns DShiftCK phase duration

T3 0 ns T2 DShiftCK down to DSerialIn update

T4 0 ns T2 DShiftCK 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

Time Min Max Comments

1 4*T1 nDFReeze change to next DBus event

2 5 ns 100 ns enable/disable time

3 T1 delay between DBus events

4 = T1 = DShiftCK cycle time

5 0 ns T1 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 component identification register is reloaded when an Address cycle occurs and when an Execute cycle is directed to path #0.

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.

3.2.4. DBus synchronizer

The DBusSync icon provides a synchronized DBus interface. This icon takes a raw DBus signal (Raw) and a reference clock (CK) to generate a synchronized version (Sync) of the raw signal. The icon has a parameter ld that indicates the logical drive of the output signal (expressed in number of SC inverters loaded by the output signal). The logical drive parameter is defaulted to 16.

3.2.5. DBus wire icons

Three icons describe the wire structure of the DBus in various locations of the machine:

- DBus.icon describes the DBus inside a chip (7 wires, excluding DSelect)

- DBusIn.icon describes the input part of the DBus, normally at board level (same as DBus, except for DSerialOut)

- DBusInOut.icon converts between the two representations

3.2.6. 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: The arbiter provides a mechanism to allow board identification. See the Arbiter datasheet for details.

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.

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 more complete implementation based on programmable gate arrays is feasible if performance is a problem.

6. Modifications to DBus for SunDragon

6.1. Overview

The major modifications of the DBus to SunDragon are:

- removal of the nDFreeze signal

- modification to hierarchical decoding

6.2. Removal of nDFreeze

nDFreeze is removed from the DBus specifications. The semantics of nDFreeze were not precise enough to be of any use in a system. In the modified scheme, the only way to stop the machine is by stopping the arbitration mechanism, which stops the machine on a packet transport limit.

6.3. Hierarchical decoding

The hierarchical decoding scheme outlined earlier in this document is based on the hybrid module structure in the Dragon machine. SunDragon packaging will differ noticeably from this scheme, requiring a different decoding implementation. Details will be decided based on the board organization. This modification has no impact on chip design.

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 type Chip

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 Dynabus clock generator

0B SimpleDBusExerciser (a test chip)

0C Unused

0D Unused

0E Unused

0F Unused

10-3F Unused