The IOBridge works on the IOBus both as a master device, to allow DynaBus devices to access IOBus devices, and as a slave device to allow IOBus devices to access DynaBus memory, DynaBus IO devices and internal IOBridge registers.

The IOBus control signals allow the IOBus to be used as a memory bus and as an IO bus with two separate address spaces. Following Intel conventions, only the low 16 bits of the address bus are used in the IO space. IOBus cycles occur in two modes: "slow" cycles are initiated by the RD/WR lines (following the PC/AT signal conventions) whereas "fast" cycles are initiated by S0/S1. Fast cycles allow the IOB to emulate zero wait-state memory.

The IOBridge behaves on the IOBus as a slave device regarding arbitration, i.e. it requests the bus from an external arbiter.

IOBus requests may refer either to IOBridge internal registers or to DynaBus memory or I/O space. The first type of request uses IOBus IO space and is straightforward to implement. The second type of request is handled through a cache that follows the DynaBus consistency scheme. This cache is the Dragon processor small cache chip. DynaBus I/O requests are also handled through the cache, which then acts only as a DynaBus master controller. Since the IOBus does not provide enough address and data bits for DynaBus IO, the technique used consists in having an address and a data register describing the request. The DynaBus IO request is started through access to a special location. The same trick is used to access DynaBus memory locations beyond the 16 MB range supported by the processor sitting on the IOBus.

There are multiple reasons justifying a cache as the IOBus to DynaBus mechanism. First, IOBus access quantum is a byte, whereas DynaBus access quantum is a block (32 bytes). Hence, some buffering mechanism is necessary. Since DynaBus does not support byte atomic read-modify-write transactions, this buffer needs to support the DynaBus consistency scheme. As most of the IOBus accesses to DynaBus memory will be made through DMA-type devices, it could be expected that a simple silo mechanism would be sufficient. A major problem with that solution is that the I/O board is expected to use intelligent device controllers that behave as full bus masters and do not only work through standard sequential DMA channels (a good example of such a behaviour is the Intel 82586 Ethernet controller). Having a cache allows the IOBus to DynaBus interface to work without any knowledge of the behaviour of IOBus devices. Even for intelligent device controllers, most of the memory accesses will be made to sequential buffers. The benefits of using the cache will not be in reusing randomly blocks that are in the cache, but in the buffering provided by the cache. Reusing all of the work on the Dragon processor small cache chip is obviously a time and trouble saving solution, since the cache is a complex piece of hardware, due in part to the consistency protocol.

IOBus addresses are physical DynaBus memory addresses. Supporting a translation mechanism similar to the one performed in the Dragon small cache is not feasible because there is no page/mapping fault support on the IOBus. The mapping used in the cache chip is forced to be the idnetity map by using a dedicated address spece known to the map-cache as the identity map. Thus, mapping will never fail. I/O board implementors may want to provide an external full map mechanism, but it will be rather costly.

The IOBridge supports DynaBus requests for three purposes, managing the cache, accessing IOBridge registers and IOBus memory and devices, and debugging. The first type of accesses is completely handled by the cache. The second type of request is handled differently when the reference is to IOBridge internal registers and to IOBus. The third mechanism (Exerciser) is intended to be used only during the debugging of the machine, for testing purposes and possibly as part of the bootstrap code.

IOBus references are basically asynchronous since the latency of the IOBus is unknown. Requests are queued in a FIFO and processed one at a time, then the reply packet is sent back to the originating device. The specifications of the IOBridge indicate that DynaBus devices may access the IOBus memory space with only 24 bits of byte address. This restriction comes from the fact that although the DynaBus supports 48 bit addresses, Dragon processors only emit 32 bit addresses, thus restricting the whole IO address space to 232. As this DynaBus IO address space need to be shared among all the devices on the DynaBus, the largest reasonable subaddress field available for a given device is only 24 bits. This is not expected to be a serious problem, since most devices on the IOBus (including the IOBus debug processor) will only handle 24 address bits. Following Intel conventions, this address is restricted to 16 bits for the IOBus IO address space. Should this restriction prove to be a problem, extending to 24 bits would require only minor modifications.

The specifications also allow for byte and halfword access to the IOBus. Word access is not supported. Halfword access offers a choice regarding byte swapping.

The DynaBus reception interface on one side with the standard DynaBus interface, using the input and control ports, and on the other side with the DynaBus I/O manager. It also has a few general control wires.

The interface with the request FIFO is:

The DynaBus interface used is:

The following signals are also public:

The data path contains only a pipelined header register. The header register stores all incoming headers. Its input is decoded to check for header validity and prepare the generation of the request.

The control consists of the header decoder and two control pipelines for regular request reception and exerciser reception.

The DynaBus IO manager interfaces with the IOBus master interface as consumer, and with the DynaBus reception as producer.

The interface with the DynaBus I/O manager is:

The interface with the IOBus master and the internal peripherals is:

The interface with the IOBus master interface is:

The interface with the internal peripherals is:

The interface with the DynaBus output is:

A single data bus links to DynaBus I/O manager to the IOBus master interface and the internal peripherals. This bus is output for a write, input for a read. During a read, either IOBus master or peripherals will drive according to the state of IOBusDone/PeripheralsDone. The value shouldd be used only while one of the Done signals is asserted.

The data path consists of a request buffer (if the FIFO does not have stable outputs) and a reply data buffer. The latter is not strictly necessary, but it slightly improves the availability of the internal peripherals since they do not need to maintain their data output while the DynaBus is still processing the previous reply (this is quite negligible, and the design might be better off without this extra pipeline).

The control is a finite state machine. The FSA is started from the idle state when the request FIFO contains valid data. The data is read into the request buffer, and a IOBus or internal peripheral cycle is initiated depending on the state of the Internal request bit. Either way, the automaton first waits for availability of the interface, initiates the cycle and waits for the reply handshake. When the latter occurs, the reply data, ignored bit and protected bit are stored in the reply data buffer and the cycle is terminated. If the request was ignored or was a broadcast write, the FSA returns to the idle state. If the request was accepted, the FSA polls the DynaBus output for availability and initiates the reply, then returns to the idle state. If reply data is not stored, the FSA must be modified to end the cycle only when the DynaBus output has been initiated, since data are guaranteed during acknowledge time. This alternate solution may result in longer wait time when IOBus accesses internal peripherals. This might be helped by making IOBus cycles higher priority when accessing the internal peripherals. There is no risk of DynaBus thrashing with this solution, since IOBus requests will always find their way between IOBus requests.

The IOBus master interface contains the following wires connected to the requestor:

All those signals are synchronous with CLOCK.

The following signals are shared with the IOBus:

Control of the IOBus master interface is achieved through a handshake protocol using StartIOBusCycle and IOBusCycleDone. The requestor must assert StartIOBusCycle and wait for IOBusCycleDone to be asserted to indicate cycle completion. At that point, the requestor must rescind StartIOBusCycle and wait for IOBusCycleDone to be rescinded in reply before starting a new cycle. This last part of the handshake may be pipelined on following requests by waiting for IOBusCycleDone to be rescinded before asserting StartIOBusCycle.

Input data signals (AddrIn, nBHEIn, WRData, WnR, IO, Lock) must be stable during all the time StartIOBusCycle is asserted. Data read from the IOBus (for read cycles) is stable from assertion of IOBusCycleDone to assertion of StartIOBusCycle for the next cycle (it is actually still valid for some time after that, but the delay is not known outside the IOBus master interface).

All input signals are assumed to be latched on the requestor's side. They are not latched inside the IOBus master interface.

Control signals (WnR, IO) are decoded into the demultiplexed IOBus controls with an enable provided by the internal automaton (CEN) to ensure timing of read/write signals. All signals are connected to the output ports through tristate buffers controlled by HLDA.

This automaton controls the generation of the IOBus master cycles. It has the following state diagram.

The DynaBus output and control section receives packets to be sent on the DynaBus and manages output queueing, DynaBus allocation and output. There are two types of packets sent: IOReadReply packets are created by the DynaBus IO manager as a result of an IOReadRequest transaction, Exerciser packets are produced explicitely by the debug microprocessor on the IOBus.

Each type of packet has its own buffer. IOReadReply packets are always 2 64-bit words long, whereas Exerciser packets are always 5 64-bit words long. The IOB uses the high-priority arbiter port for IOReadReply packets (length = 2 cycles) and the low-priority arbiter port for Exerciser packets (length = 5 cycles).

Due to the pipelining stage in the on-chip DynaBus interface, the 1st and 2nd word of each buffer must be accessible in parallel (refer to timing diagrams for more details).

The control section is a finite state automaton implemented using discrete logic and decoded state. The structure of the FSA is obscured by the pipelining of the Grant signal and the DataOut bus (refer to the timing diagram for more details). The automaton has the following states (FFs) and outputs:

The inputs to the FSA are:

The equations governing the FSA are (= denotes a boolean function, ← a flip-flop):

All internal peripherals are organized around an internal bidirectionnal 32-bit data bus and a small control bus containing an 8-bit peripheral address and read, write and acknowledge signals. The bus is described exactly by the following signals (as seen by a peripheral):

PerAccess is asserted for exactly 1 CLOCK cycle. PerAck will be asserted for exactly 1 CLOCK cycle when the action has been completed. PerAccess should not be asserted again before PerAck has been asserted. Thus, it is a simple handshake protocol. The delay between PerAccess and PerAck depends on the peripheral addressed. PerData, PerAddr and PerWR are assumed to be correct from the time PerAccess is asserted to the time PerAck is asserted. Output data should be sampled by PerAck.

The asynchronous peripherals support the time control operations. As the frequency of the DynaBus and the IOBus may vary, they use a separate 8 MHz reference clock to mesure elapsed time. Asynchronous peripherals are located at addresses in the range [0..15]. They share a common section that synchronizes PerAccess with the 8 MHz clock (CK8MHz) and generates PerAck and all the control signals needed by the asynchronous peripherals.

The overall schematic for asynchronous peripherals consists in the subschematics described in the next sections, plus elementary decoding logic on the peripheral address.

The prescaler block synchronizes a reference 8 MHz signal with the DynaBus CLOCK and produces a 1-CLOCK pulse on its leading edge. This results in a synchronous 8 MHz signal, which is divided by 8, producing SCk1MHz, then by 1000 producing SCk1kHz, finally by 100 producing SCk10Hz. A pipeline stage is inserted between each of the dividers to ensure that propagation time does not exceed CLOCK frequency.

The permanent clock (FastClock.sch) is simply a 32-bit up-counter with an overflow detection mechanism that raises an interrupt. The counter runs with 1 MHz ticks, synchronous with the DynaBus clock, provided by the prescaler logic. The overflow detection mechanism detects when the counter goes beyond 232-1 and sets an interrupt flip-flop. Writing any value in the permanent clock will erase the interrupt flip-flop. The value of the counter itself cannot be modified by software.

The Busy output allows to quiesce the peripherals automaton when an update is in progress.

The state of the interrupt flip-flop is 0 when no overflow is present. It is set to the Idle state by the Reset signal. Its equations are:

The time-of-day clock is simply a 32-bit counter (divided in 8-bit slices to allow IOBus access) that may be read from and written into from both IOBus and DynaBus. The counter counts up every 1/10 second. There is no overflow provision, since the overflow time is large (232/10 seconds is over 13 years). The time of day clock is not reset by the system Reset signal. It must be initialized by software.

Byte enables and TODC select provide S0/S1 for the counters by:

The interrupt manager receives 8 interrupt lines from the IOBus side (INTR0-INTR7). The interface to the IOBus to cache interface consists of a handshake SendInterrupt, InterruptSent pair following the standard protocol.

The external interrupts are sampled twice to synchronize them with the internal clock. The internal interrupts join them at this stage. All interrupt sources form a pseudo-register readable through DynaBus and IOBus. The interrupts are then masked, and a off-to-on edge detector is applied to each of them, producing interrupt pending transmission signals. As long as any of these is on, an interrupt sending cycle is required, and the highest priority interrupt is sent, then the interrupt pending transmission flip-flop is cleared.