The descriptions will refer to components. These are not necessarily integrated circuits but are simply an addressable shift register that conforms to the DBus protocol.

All signals are assumed to follow positive logic unless they have an "n" at the beginning of the signal name.

The DBus comes in 2 flavors: the backpanel DBus and the IC DBus. The major difference between both flavors is that component addresses are transmitted serially on the backpanel DBus and decoded on the IC DBus. The backpanel DBus is transformed into the IC DBus by board-level logic, most of which is included for the June87 machine in the local DynaBus arbiter. All components behave as slaves of the DBus. The IC DBus is of interest to IC designers in general, whereas the backpanel DBus is of interest only for the designers of the DBus controller and the DBus board-level logic.

All signals in the DBus are synchronous with respect to the DynaBus master clock and follow all the DynaBus timing conventions (mainly, that signals are always sampled only at the leading edge of the DynaBus CLOCK signal). The DBus uses the same electrical conventions as the DynaBus. The notations used are (I) for input signals (as seen by the board or component), (O) for output signals, (OC) for open-collector signals. Open-collector outputs are implemented as a sampling stage followed by an inverter buffer and a pull-down transistor.

The IC DBus has 7 signal lines that are listed below, together with the meaning of each group of lines.

The back panel DBus has 7 signal lines. The lines are the same as the IC DBus with the exception that DAddress replaces nDSelect and modifies the meaning of DShift slightly. The redefinition of these lines follows:

The signals DShift, DSerialIn, DSerialOut, DExecute, nDFreeze and nDReset are connected between the back panel DBus and the IC DBus through one pipeline stage, like DynaBus signals. All DSerialOut lines coming from components in a board are wire-ORed, then sent onto the backpanel through a pipeline stage. Figure 1 gives a simplified description of the relationship between the back panel DBus and IC DBus. The nDSelect lines are computed by the board-level logic from the address bits passed from the backpanel DBus. The reader is referred to section 5 (DBus controller and board-level logic) for further details.

As mentioned earlier, the DBus is synchronous, with all timing constraints defined with respect to the DynaBus clock, CLOCK. Figure 2 describes the basic timing constraints regarding synchronism of DBus signals with DynaBus CLOCK. These constraints are exactly the same as those applied to all DynaBus signals. Inbound signals (as seen by a chip sitting on the DBus) are guaranteed to be stable at least TSetup before the leading edge of CLOCK. They must be sampled on the leading edge of a CLOCK period (TSetup is larger than the buffer input time and the setup time of the sampling flip-flop). In the same way, outbound signals must be sampled inside the chip on the leading edge of a CLOCK period and are then stable after the flip-flop settle time plus the buffer time, TSettle. The difference between the DynaBus clock period and TSetup+TSettle is the propagation delay between two chips.

Although the DBus uses CLOCK as its basic timing period, events on the DBus, with the excpetion of nDFreeze, are separated by a large enough number of CLOCK cycles (typically 4) so that even slow chips may follow up at top DynaBus clock speed (25ns/40MHz).

In the remainder of this description of DBus timings, all signals are assumed to respect the synchronization constraint with respect to DynaBus CLOCK. To simplify timing diagrams, signals will be represented as changing state on the leading edge of the DynaBus CLOCK. All times will be expressed in multiple of the DynaBus CLOCK period, also noted CLOCK.

The DynaBus clock is assumed to be free running. All derived clocks should start with a phase relationship which is fixed with respect to the trailing edge of nDReset. The EU and IFU clocks should start with the leading edge of PhA rising coincident with the immediately following rising edge of the DynaBus clock after a rising edge of the DynaBus clock during which nDReset is deasserted.

Power up reset and the reset button should both cause the IOP to be reset and a flipflop which asserts nDReset to be initialized. After booting the IOP then asserts nDFreeze and deasserts nDReset. For every DBus device the IOP must scan out the Component ID, determine if it is a DynaBus device, and, if so, allocate a DynaBus ID and insert it into the device. The IOP deasserts nDFreeze, initializes some portion of the main memory, copies the basic bootstrap from ROM into main memory and then tells one cache or all caches to deassert processor reset with an IO command.

The primary function of the DBus is to transmit data on a serial line. Figure 3 depicts the basic shift cycle. DShift is guaranteed to be in the on and off state for at least 4 CLOCK (each), thus the frquency of DShift is at most CLOCK/8. DSerialIn is guaranteed to be stable on the leading edge of DShift. DSerialOut must be valid on the leading edge of DShift. The component is assumed to sample DSerialIn and produce DSerialOut on the leading edge of one of the CLOCK periods during the DShift cycle, so that DSerialOut is valid for the board-level logic or DBus controller at the next leading edge of DShift.

It is expected that components will sample DSerialIn and produce DSerialOut on the same CLOCK edge as DShift or on the following one if the component uses the DynaBus CLOCK as its basic clock, or after a synchronization delay if it uses a different clock.

Although the DBus has basically a radial structure, with the DBus controller at the center and DBus devices at the end of radial spokes (the nDSelect lines), it may sometimes be necessary to have muiltiple chips being a single DBus device. The EU and IFU couple are an example of such a situation, because it is very difficult to single-step them separately. In such a case, the above description is incorrect, since it may lead to timing inconsistencies. In such cases, the implementors of the chips should be careful to use exactly the same timing on chips that are chained on the DBus.

It is also worthwhile to notice that chips that do not have access to the DynaBus clock (such as the EU and IFU) may use DShift directly as a shift clock. The diagnostic software must then make sure that nDFreeze is always asserted before selecting such chips.

Figure 4 shows the timing for the IC DBus through a typical DBus transaction consisting of selection, writing some information, executing it, and reading back the results.

nDSelect is guaranteed to be stable at least 8 CLOCK cycle before DShift or DExecute are asserted and after they are rescinded. When nDSelect is not asserted for a component, this component should ignore DShift, DExecute and DSerialIn, and float off of DSerialOut.

DShift, DSerialIn and DSerialOut follow the timing requirements exposed in section 3.a .

DExecute and DShift are exclusive one of another. The delay between DShift rescinded and DExecute asserted is guaranteed to be greater than or equal to 4 CLOCK (that is DExecute cannot be asserted before the time when DShift might be reasserted). DExecute will always be asserted for at least 4 CLOCK. The delay from DExecute rescinded to DShift asserted is not specified. It will always be greater than or equal to 4 CLOCK, but it may take much longer for certain devices to execute the command. It is the responsibility of the DBus controller not to reassert DShift before the addressed component is ready again. This implies that the DBus controller needs to know what type of device it is addressing and its execution timing requirements. The action performed by a component when DExecute is asserted will depend on the component. Refer to the section on implementation hints for more details.

nDFreeze is guaranteed not to change at least 16 CLOCK before either DShift or DExecute is asserted, and the same time after they have been rescinded. All components should stop all internal operations (except for DBus and vital activities such as memory refresh) as soon as possible after nDFreeze has been asserted (low). This delay should be equal to 1 CLOCK for all components that use the DynaBus CLOCK as their basic internal clock. Other components (currently IFU/EU) should stop operations on the next transition of their internal clock after synchronization with the DynaBus CLOCK. Components may require that nDSelect is asserted only in conjonction with nDFreeze (such components support the DBus only when in the frozen state). It is expected that most components will have that restriction.

nDReset may be asserted (low) at any time (respecting the CLOCK synchronism). nDReset remains asserted for a minimum of 10 ms. As soon as nDReset is asserted, all components should perform an internal reset and remain in that state until nDReset is rescinded. None of the other wires of the DBus have meaning when nDReset is initially asserted. The reset logic guarantees that nDFreeze is asserted and that DShift, DAddress, and DExecute are deasserted at least 4 cycles prior to rescinding nDReset. nDSelect is undefined even after rescinding nDReset until the appropriate loading of the address via DAddress has occurred.

The description of the Backpanel DBus is of interest only to the implementors of the DBus controller (in the IOP board) and of the on-board DBus logic (integrated partly with the local DynaBus arbiter, partly in the DynaBus buffer chips).

There are three phases in a backpanel DBus transaction: address setup, data transfer and execution. A single address setup may be used for more than one data transfer and/or execution. An address setup phase uses the DSerialIn line to transmit the component address to the board-level logic.

Figure 5 describes the address setup phase. DAddress is asserted at least 16 CLOCK cycles before DShift and deasserted at least 12 CLOCK cycles after the trailing edge of the last DShift period (i.e. 16 CLOCK cycles after the last address bit). As long as DAddress is asserted, the board-level logic will deassert all the nDSelect lines This deselection should occur within 8 CLOCK cycles to comply with the timing requirements on nDSelect outlined in 3.c. DSerialOut is undefined during this time. While DAddress is asserted, all DShift cycles are trapped by the board-level logic and will be used to build the component address. Bits are transmitted MSB first. Only the last 16 bits transmitted are used (5 bits for the board number, 11 bits for the component number - refer to section 5 for more details). When DAddress is rescinded, a single nDSelect line will be asserted by the onboard logic, for the addressed component. The delay from DAddress rescinded to nDSelect asserted will be at most equal to 8 CLOCK cycles (this is a constraint on the board-level logic). The next DShift leading edge should not occur before at least 8 CLOCK cycles (refer to section 3.a).

The data transfer phase follows exactly the specifications given in 3.a) for the basic DBus shift cycle. The number of shift periods (i.e. bits transferred in or out) is decided by the DBus controller according to the device being addressed. DAddress must remain unasserted during the data transfer phase.

The board-level logic uses only the address setup phase. In all other circumstances, it only acts as a delay line. The reader is referred to section 5 for a detailed discussion of a possible implementation of the DBus board-level logic.

There are two basic DBus functions that all components should implement: retrieve component identification, set DynaBus ID.

LSSD provides a very natural and easy way to implement the DBus in standard cell designs that use the DynaBus CLOCK as their basic clock. The basic idea is that all the "interesting" (specified by the designer) flip-flops in the chip are linked together in a very long shift register. Shifting this register is enabled by the DBus DShift signal. nDFreeze disables normal loading of all internal flip-flops. The reader should notice that LSSD applies only to "discrete" flip-flops. More complex state information (such as RAMs, FIFOs) may be recovered by setting first the flip-flops that control them (address register typically), then doing a DExecute cycle to read the RAM, then re-reading the LSSD to get the value (presumably stored in a RAM output buffer register). In terms of silicon real-estate, the cost should be fairly small (perhaps 10-15% more area on all flip-flops).

Fig. 6 to 8 give simple schematics that should be reasonable to implement the DBus function in a standard-cell design using LSSD. Obviously enough, the flip-flops that are used in this schematic should not be part of the LSSD scan path. Fig. 6 shows the DBus interface. It basically produces the same signals as the IC DBus, except that Shift and Execute are produced only if nDFreeze and nDSelect are asserted. Moreover, it produces a 2-bit control, LSSDCtl, that is used to select inputs to all flip-flops. The LSSDCtl values are:

The reader will note that this proposed interface meets the timing requirements by a wide margin. In particular, nDFreeze is taken into account exactly 1 CLOCK cycle after it is asserted. As mentioned in section 4a, the component ID register should be the first one on the DSerialOut path. The implementation of this register consists of a shift register with 32 bit constant as input which is loaded during DExecute.

Fig. 7 shows a typical flip-flop with reset on chip-reset using the basic flip-flop in the Logic library, together with an icon representing it (a real implementation will have to start from the elementary multiple-input FF suitably extended/modified). Fig. 8 shows how such flip-flops are linked to form the LSSD scan path for a 4-bit register. In a glorious future, the connection between the SI input flip-flop and the Q output of its neighbour will not be described by the user, but will be computed automatically by the standard-cell placer/router.

Obviously, this is only an example since no more control is available to produce more complex flip-flops, but it shows what the basic idea should be. As soon as the details get more precise, all the Logic library will be updated to support LSSD, and the standard cell programs will know how to handle them.

LSSD is extremely impractical for large full-custom designs, although it could be used when the designs are regular enough. The alternative solution is to view the DBus shift register as a command register. Assuming that the chip is structured around a major data path, this command register could be seen as containing some address bits to specify an internal register and some bits describing the action to be performed (read/write/single step/...). The execute command would then consist of interpreting this command register. In such an implementation, data shifted out of the chip would be meaningful only after an execution cycle.

The basic interface depicted in Fig 6 remains valid for full-custom designs that use the DynaBus CLOCK as their basic clock. For other designs, it is necessary to replace the CLOCK edge detectors in the schematic by a CLOCK sampler/synchronizer followed by an edge detector synchronized to the internal chip clock. There should be no problem as long as the chip clock period remains below 8 CLOCK (i.e. 200ns in the fastest case). Similar precautions need to be taken to sample all incoming signals and to produce a SerialOut line consistent with DBus specs with respect to the timing constraints.

This piece of logic captures 16 bit DBus address transactions, stores the address, compares the most significant 5 bits with a hardwired board slot number, emits the 8 low-order bits and provides the 3 remaining bits in a decoded format (active LOW) which is disabled while the address transfer is proceeding. Fig. 9 is a logic diagram implementing this logic.

DShift-in is derived with respect to CLOCK, then the control bits for the shift register are built:

This guarantees the command required for the address shift register ((0,0) for right shift, (0,1) for idle, (1,1) for reset). The topmost 5 address bits are compared with the externally hardwired board slot number, the result is used to enable the decoding of the following 3 bits. The remaining low-order 8 bits are output for further decoding. Latching the nDSelect signals is necessary if we want to comply with the specifications given earlier.

The target timing specifications are easily met by this design (the maximum delay is 2 CLOCK cycles).

The DBus address capture logic will be incorporated in the same chip as the board-level DynaBus arbiter. Although it is not described here, the address capture logic should also contain hardware for a dummy component that will return the board type as its only DBus information.

Eight bits are left after the primary address decode. The first 4 of these bits are decoded at board level, providing 16 nDSelect lines addressed to hybrids. The remaining 4 bits are decoded inside each hybrid.

The basic decoding stage is described in Figure 10. It is simply a 2 bit decoder conditioned by a chip select and a 2 bit base value. Hence, four such blocks with the SubAddress and nCS inputs connected together form a 4 bit conditional decoder.

Since the DBus has the same electrical conventions as the DynaBus, it must contain the same set of buffers. The only major difference is that standard DynaBus buffers (which incorporate a stage of pipeline delay) may eventually be controlled by the DBus. The DBus buffers must be free from any DBus control interference. The mechanism currently proposed is that each DynaBus buffer (4 are required to buffer the full DynaBus) also contains some 2 extra pipelined buffers that are DBus independent. Those 8 buffers (4*2) are used to buffer the DBus.

Figure 11 gives an overview of the DBus structure in a typical June87 Dragon board. Each block labeled Buffer is a full DynaBus/DBus buffer, including 4 of the decoders described in section 5.2 (for Base from 0 to 3). The scheme used consists in buffering the backpanel DBus twice, once at board level, once inside each hybrid. The first level (hybrid DBus) is also buffered on the board to provide a component DBus with the same latency to the DBus address decoder and to components that are at board level, such as the arbiter.

The DBus address decoder emits only 7 decoded select lines, line 0 being used internally to allow the DBus to access the board type. One of these lines is an input to the board buffers, together with the 4 MSB of the undecoded DBus address to provide 15 hybrid select lines (line 0 is used to select the buffer itself). Each hybrid uses one of those lines, and its internal buffers further decode the 4 LSB of the undecoded DBus address, providing 15 select lines. The first level of buffers generate DynaBus-level signals, whereas the second level (whether on board or inside an hybrid) provides TTL levels.

The scheme thus provides directly for the selection of up to 15 hybrids, each having up to 15 components, per board. In fact, there are still plenty (5) of unused select lines provided by the DBus adddress decoder that may be used to provide additional selection if necessary.

It should be noticed that this design ensures that the DBus reaches all components with exactly the same latency (2 cycles).

The DBus controller will be split in 3 parts, all sitting in the I/O board:

The implementation currently envisioned consists of integrating the hardware DBus controller on the IOP chip and connecting all three pieces on the SloBus. Details still to be worked out.