Integrated Dual Bus Controller

This invention is in the area of computers and more specifically relates to bus controller architecture.

The design of bus controllers has evolved over the years as performance requirements and customer needs have driven computer architectures to become more sophisticated and efficient. Specifically, the desire for higher performance has necessitated that a bus controller be able to operate with both a local bus and a system bus simultaneously and autonomously. Additionally, a bus controller that is not limited with regard to speed is needed; in this way both the local bus or the system bus may interact with the bus controller as fast as circuitry on the boards permit without suffering from speed limitations incurred by the bus controller. Lastly, a need has been felt for a bus controller that may operate as a master during a transaction or as a slave during a transaction simultaneously with both the local bus and the system bus, thus providing for more system flexibility.

The design of bus architectures typically include a number of compromises to optimize performance parameters that may be inversely related to one another. Certain bus architecture standards are designed as open standards to provide a general framework, yet provide flexibility so that performance criteria may be enhanced for specific system applications. Futurebus+ is one such open standard. The Futurebus+ standard is an IEEE specification #896.1-1991 and is described in an article entitled "Futurebus+ Coming of Age" (Theus, John, "Futurebus+ Coming of Age", Microprocessor Report, May 27, 1992, pp. 17-22).

It is an object of this invention to provide a dual bus controller architecture that enables simultaneous, autonomous interaction with both the local bus and the system bus and is compatible with the Futurebus+ bus architecture standard (IEEE spec #896.1-1991). It is another object of this invention to provide a dual bus controller architecture that allows both the local bus and the system bus to interact with the bus controller operating as a master or a slave without any imposed speed limitations. Other objects and advantages of the invention will become apparent to those of ordinary skill in the art having reference to the following specification together with the drawings herein.

A dual bus controller includes a system bus control module connected to a local bus control module. An optional filter is also connected to the system bus control module. A plurality of programmable status registers for the local bus is connected to the local bus control module and a time dependent reset circuit is connected to both the system bus control module and the local bus control module. The dual bus controller allows simultaneous, autonomous activity with both the local bus and the system bus via the local bus and system bus control modules. The unique interaction between the local bus and system bus control modules also allow both the local bus and system bus to interact with the dual bus controller operating as a slave without any imposed speed limitations by actively resolving bus collisions and "live-lock" conditions.

FIG. 1 is a block level diagram illustrating a backplane based computer system 10.

FIG. 2 is a block level diagram illustrating the preferred embodiment of the invention, a dual bus controller 22a.

FIG. 3 is a block diagram illustrating in greater detail a local bus control module 12 and a system bus control module 14 within dual bus controller 22a of FIG. 2.

FIG. 1 is a block level diagram illustrating a backplane based computer system 10. Computer system 10 includes a system bus 11 connected to a plurality of computer boards 13a-n. Each computer board 13a-n includes a local bus 24a-n, a bus controller 22a-n, and possibly a memory 26, a microprocessor 28, an input/output (I/O) device 30 or other type devices depending upon each board's 13a-n application requirements. Each board 13a-n communicates with one another via system bus 11.

FIG. 2 is a block level diagram illustrating the preferred embodiment of the invention, a dual bus controller 22a. Within bus controller 22a a system bus control module 14 is connected to a filter 18, a reset circuit 20, a system bus 11, a local bus control module 12, and a plurality of control status registers 16. Local bus control module 12 is also connected to control status registers 16, reset circuit 20, and a local bus 24a. Filter 18 is also connected to reset circuit 20 and to system bus 11.

System bus control module 14 monitors signals on system bus 11 (which in this particular embodiment is a Futurebus+ system bus) and maintains the appropriate handshake protocols necessary for proper operation with Futurebus+ 11. System bus control module 14 will be described in greater detail later. Local bus control module 12 monitors signals on local bus 24a and maintains the appropriate handshake protocols necessary for proper operation with local bus 24a. Additionally, local bus control module 12 also decodes and encodes commands from local bus 24a to Futurebus+ 11 and from Futurebus+ 11 to local bus 24a. This allows Futurebus+ 11 and local bus 24a to be completely independent of one another with respect to speed and handshake protocols. Therefore, local bus control module 12 acts as a command translator between Futurebus+ 11 and local bus 24a. Local bus control module 12 also provides synchronization circuitry which allows signals to cross the timing boundaries between different time domains. This allows either or both Futurebus+ 11 and local bus 24a to be asynchronous. (Futurebus+ 11 is an asynchronous bus).

Filter 18 is an optional filter that allows incoming signals from Futurebus+ 11 to be glitch filtered. This is sometimes desired when each computer card 13a-n in a backplane based computer environment is configured in a "wired-OR" configuration which is well known by those skilled in the art of system design. It is often desired to glitch filter incoming signals since they may suffer from the "wired-OR" glitch phenomena which is also well known by those skilled in the art. Other times, due to speed requirements or specific transaction types, filtering of incoming signals is not desirable; therefore the filter is optional and use will depend upon the specific operation being performed.

Reset block 20 is a time dependent reset circuit that conforms to the Futurebus+ spec noted earlier. Therefore, depending upon the duration of a reset signal being asserted, different types of reset operations take place. Different types of reset include: start, power-up, system initialization, and local bus initialization.

Control status registers 16 include a plurality of programmable status and configuration registers. Therefore, via software, control status registers 16 may be programmed to indicate the capability of the components within system 10. These capabilities may include: address size, data size, memory capacity, interrupt registers, timers, data speed capabilities, glitch filter settings, bus status, and enables.

FIG. 3 is a block level diagram illustrating in greater detail local bus control module 12 and system bus control module 14 of FIG. 2. It was stated earlier that local bus control module 12 monitors signals on local bus 24a and decoded command signals between local bus 24a and Futurebus+ 11. FIG. 3 illustrates the two separate functions of local bus control module 12, a local bus control 34, and a local bus decoder/encoder 36. Local bus control 34 may include a state machine and synchronizer. Local bus decoder/encoder 36 is composed of standard decoding circuitry well known by those skilled in the art. System bus control module 14 is composed of system bus control 38 which may include a state machine.

Dual bus controller 22a resides on computer board 13a and communicates with devices on board 13a via local bus 24a and with components on other boards via system bus 11. Bus controller 22a may advantageously become a bus slave of both local bus 24a and Futurebus+ 11 simultaneously with the ability to resolve both bus collisions and "live-lock" problems which are well known be those skilled in the art. Additionally, bus controller 22a may operate with both local bus 24a and Futurebus+ 11 simultaneously and autonomously, thereby improving system 10 performance. Thus, for example, bus controller 22a may simultaneously be sending data to a component on local board 13a via local bus 24a and performing an appropriate handshake with Futurebus+ 11. This improves system performance.

The following is an example illustrating the ability of bus controller 22a to operated as a slave simultaneously with both local bus 24a and Futurebus+ 11. Board A 13a wants to transfer data to board B 13b. Simultaneously, board B 13b wants to transfer data to board A 13a. Both boards make requests for Futurebus+ 11, yet only one board will receive a grant which will depend upon the priorities of each request. In this instance, board A 13a has a higher priority and receives a grant for Futurebus+ 11. Microprocessor 28a on board A 13a presently is the master of local bus 24a and controller 22a is the slave of local bus 24a. This same series of events occurs on board B with a microprocessor 28b (not shown) being the master on local bus 24b and the controller 22b the slave. The data then transfers from memory 26a to FIFO 40a via local bus 24a; FIFO 40a acts as a temporary data storage on board A 13a. Typically, on board A 13a processor 28a or memory 26a is master moving data into FIFO 40a via local bus 24a. Then controller 22a becomes the master on Futurebus+. While controller 22a is a master on Futurebus+, controller B 22b is a slave on Futurebus+. This typically would be a problem since bus controller 22b on board B 13b is now a slave of both local bus 24b and Futurebus+ 11 simultaneously, however bus controller 22b has the ability to recognize this potential problem through the monitoring of signals on local bus 24b and Futurebus+ 11. When this case occurs, bus controller 22b sends a signal to the microprocessor on board B 13b telling it to "back-off" on its attempt to send data to board A 13a. This frees local bus 24b to complete the transaction of sending data from board A 13a to board B 13b. Data is transferred to a memory 32b or an I/O device 30b on board B 13b via Futurebus+ 11, bus controller 22b, and local bus 24b. After completion of this transaction, board B may then complete its desired transaction of sending data from board B 13b to board A 13a. Similarly, when both local bus 24b and Futurebus+ 11 are bus masters bus controller 22b utilizes the "back-off" feature to avoid the bus collision that may occur.

It should also be noted that the "back-off" feature may work with either Futurebus+ 11 or a local bus 24a-n. However, bus controllers 22a-n are configured specifically to operate the "back-off" signal in the majority of cases with local buses 24a-n. This is to avoid the "live-lock" phenomena which is well known by those skilled in the art. If the "back-off" signal were used with Futurebus+ 11 it is possible that two boards, for example board 13a and board 13b, may alternately back each other off Futurebus+ 11 when attempting a transaction. Therefore, although Futurebus+ 11 is active (back-off signals are traveling along Futurebus+ 11) neither transaction is being executed and system 10 becomes "locked up". Bus controllers 22a-n traverse this problem by implementing the "back-off" signal on local buses 24a-n, therefore transactions always travel along Futurebus+ 11 without any impediments and the risk of system 10 lock-up is eliminated.

Dual bus controller 22a also may operate with both local bus 24a and Futurebus+ 11 simultaneously and autonomously. This feature is due primarily to the independent operation of local bus control module 12 and system bus control module 14. Below is an example illustrating how these modules interact to provide the decoupling feature and thereby the improved performance.

Bus controller 22a on board 13a monitors signals on both Futurebus+ 11 via system bus control module 14 and local bus 24a via local bus control module 12. Microprocessor 28a on board A 13a wants to transfer data to memory 32b on board B 13b. Local bus decoder 36 within local bus system module 12 in bus controller 22a decodes the address and determines that the address resides in memory 32b on board B 13b and translates a request to system bus control 38 within system bus control module 14. System bus control module 14, in response, makes a request for mastership of Futurebus+ 11. As system bus control module 14 is making a request for Futurebus+ 11 it also sends a signal to local bus control module 12 indicating that bus controller 22a is in the "request phase" of the transaction. After that event, this triggers the transfer of data from memory 26a to FIFO 40a on board A. After data has been sent to FIFO 40 a local bus control module 12 sends a signal to system bus control module 14 via local bus control 34 indicating that data is in FIFO 40a and ready for transfer to memory 32b on board B 13b which begins the "data phase" of the transfer. System bus control module 14 relays a signal back to local bus control module 12 indicating the that Futurebus+ 11 is in the "data phase" of the transaction. Local bus control module 12, in response to the "data phase" signal, effectively disconnects from system bus control module 14 and is therefore independent of the remainder of the data transfer to memory 32b on board B 13b. The data in FIFO 40a is transferred along Futurebus+ 11 to its destination in memory 32b on board B 13b during the Futurebus+ "data phase". While the transfer of data from FIFO 40a to memory 32b is occurring, new activity may occur on board A 13a along local bus 24a via local bus control module 12. In one instance, data from memory 26a could again be retrieved and stored in FIFO 40a for future transfer independent of the speed of the Futurebus+ transaction. The ability to operate along local bus 24a and Futurebus+ 11 simultaneously and autonomously greatly improves system performance in that certain operations may occur in a pipeline or parallel fashion as opposed to a serial fashion.

Table 1, listed below, is a Verilog program listing. Verilog is a behavioral program which translates macro-level system inputs into a gate level schematic and is well known by those skilled in the art of digital circuit design. The following Verilog program listing is a detailed representation of dual bus controller 24a-n and describes the gate-level construction of dual bus controller 24a-n. ##SPC1##