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.

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:

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.

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.

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.

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.

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:

DAddress and DSelect will never be asserted simultaneously during a shift cycle. Thus, basic shift cycles are interpreted according to the following table:

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.

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.

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:

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.

The following diagram and table gives basic shift cycle timings.

The following timing diagram and table describes all the types of transactions supported by a component on the DBus.

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.

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.

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.

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:

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.

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.

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.

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

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.