The D bus (Figure 1) is a serial synchronous bus that is used for initialization and diagnostics within a Dragon system. These operations are accomplished by designing into each device connected to the D bus a shift register of arbitrary length. The D bus provides the timing and control necessary to serially load data into this shift register and subsequently 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 shift register for serial transfer to the outside world. There is a centralized controller for the D bus located on the baseboard. The Dragon processors and I/O controllers are all slaves on the D bus. All of the components connected to the M bus must be connected to the D bus.

The remainder of this document goes into greater detail about the structure, timing, and usage of the D bus. The next section lists the bus signals in detail and gives the meaning of each signal. Section 3 provides detailed timing diagrams for the bus. Section 4 discusses how the bus might be used in the implementation of a custom integrated circuit.

The D bus has 13 signal lines that are listed below, together with the meaning of each group of lines. The description uses the following naming conventions: S[a..b) denotes a group of b-a lines that encode the bits representing the signal S; most significant bits of the signal are written leftmost. A signal represented by a single wire is written unencumbered with the [) notation. All signals are assumed to follow positive logic unless they have an "n" at the beginning of the signal name. Finally, the letters "AB" are appended to signal S if it is computed during phase A and becomes valid during phase B. The actual setup time at which the bus becomes valid prior to the falling edge of phase B has not yet been determined but is approximately 20ns.

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

By convention the signals which the 4-to-16 decoder drive are labeled nDSelect[0..16) and the components have nDSelect as their port label.

This section gives the detailed timing of the D bus. In the timing diagrams used below, each row corresponds to one cycle of the clock. Values are driven onto the bus at the rising edge of phase A and are sampled on the falling edge of phase B. Actions during each cycle are indicated using Mesa like statements.

Figure 2a shows the minimal hold timing. During the first cycle the baseboard processor raises DHoldAB and all of the components sense it but continue with normal execution. During the second cycle all components continue with normal execution. During the third cycle all components do not update their state. Even though the system clocks are still running the components state should be the same as if the clocks for this cycle were deleted. During the fourth cycle the components resume normal execution, assuming that DHold was deasserted during the second cycle. An arbitrary number of cycles may be deleted by leaving DHold asserted, the first cycle deleted is always the second cycle following the cycle during which DHold is asserted and the last cycle deleted is always the cycle immediately following the cycle in which DHold is deasserted.

Figure 2b shows the execute timing. Execute can only take place when DHoldAB is asserted for multiple cycles. Execution causes the selected component to execute [shift, state] ← f[shift, state] where f is a function that can vary for different components, shift is the contents of the component's D bus shift register, and state is whatever other state information the component contains.

Figure 2c shows the shift timing. Components shift only if they are selected. A component continuously samples both DShiftAB and DDataIn but only inserts the data acquired into its shift register when the sampled value of DShiftAB is true. If DShiftAB remains high from cycle to cycle then the component continuously produces and consumes streams of bits.

This section describes how one might use the D bus within a custom component design.

Have pin for parallel drive of internal shift register to reduce test time.

Generic test programs for common structures like RAM, ROM, PLA, CAM, etc.

Only the requirements are shown in the diagrams. The value of a wire or bus is undefined during phases that the value is not explicitly given with the exception of nPError which is assumed to always be high.

Perhaps the logic to drive the bus should be on the card which has the cache that is the interface between the VME bus and the M bus since the D bus is synchronous to the main Dragon clocks. The logic could consist of a shift register that is 32 bits long, and some synchronization logic that allows the VME bus to read and write the shift register, cause DHoldAB to be set for some number of cycles like up to 16 or forever, causes DShiftAB to shift a (fixed or countable)? number of times, followed by DExecute at the appropriate time, and write the DAddress register. There may have to be a done bit that indicates when a command is finished.

The components will be required to have some mechanism with which the baseboard can determine the component type and version stamp. Perhaps this should be extended to the boards as well. This implies some standardization of the bits that are shipped, what DExecute means, and which select line means select the board level shift register.

It doesn't make sense for the hardware shift register to be anything but a multiple of 32 bits since that is the size that the VME bus can transport. More than 32 bits requires multiple VME I/O addresses to load and unload the shift register.

It has been suggested that DShiftAB and DExecuteAB be encoded so that rising edges indicate that the action should take place. This is so that subsystems running asynchronously at higher frequencies can share these wires. It is not clear to me that the additional complexity is worth saving the two wires.

If changing any of the timings would remove some complexity from the design of any of the components then people should complain as there is no reason not to relax the timings as much as necessary to eliminate complexity. Restrictions about the phase relationships between hold, shift, and execute will be fine as well.