Bus arbiter system and method for managing communication buses

A communication interface device with a card chassis capable of holding a number of electronic equipment or circuit cards. The card chassis provides a communication backplane that provides a plurality of communication buses accessing each of the equipment cards in the card chassis. To select between communication buses with mutually exclusive access to the electronic circuit card, an arbiter monitors the communication buses and determines which of the plurality of communication bus will be provided access to the electronic circuit card.

FIELD OF INVENTION
 This invention relates in general to communications equipment. More
 particularly, it is directed to providing a communication device with the
 ability to switch or arbitrate between a plurality of communication buses.
 BACKGROUND OF THE INVENTION
 An electronic card chassis typically provides a number of card slots for
 inserting electronic equipment or application cards. These application
 cards are designed to perform functions such as providing modem card
 functions or other communication interface card functions. A communication
 backplane in the electronic card chassis provides the application cards a
 source of power and communication access through the card chassis. The
 communication backplane may include a plurality of different backplane
 communication buses to allow electronic circuit cards in the card chassis
 to communicate to external devices or to other cards in the card chassis.
 In addition to the plurality of application cards capable of performing a
 variety of functions, the electronic card chassis may also contain a
 management card to perform system overhead management functions for the
 application cards in the chassis. A backplane communication bus allows the
 management card to communicate to the plurality of application cards. The
 communication bus provides management cards a communication path through
 the communication backplane to access each of the application cards in the
 card chassis.
 To provide for fault tolerant operation, the card chassis may include a
 number of management cards for backup and redundancy in case of a failure
 of a primary management card. If a management card were to experience a
 failure, a second or backup management card could take over the management
 function of the application cards in the electronic card chassis.
 In this redundant configuration including a plurality of management cards,
 each of the plurality management cards will typically have a backplane
 communication bus connection to each of the application cards. As a result
 of the plurality of management cards, each application card will have a
 plurality of backplane communication buses from which it may receive
 communications from the management cards at any time. As a consequence,
 the application card must be capable of receiving messages from any of the
 management cards over any one of the backplane communication buses
 accessing the card. Thus, to properly receive incoming management messages
 from any of the management cards, the application card must be able to
 dynamically switch between different backplane communication buses.
 SUMMARY OF THE INVENTION
 In accordance with an illustrative embodiment of the present invention,
 problems associated with managing communications from a plurality of
 different communication buses are addressed. The present embodiment allows
 application cards to arbitrate between messages on a plurality of
 different communication buses from devices communicating to the
 application card.
 In the illustrative embodiment, the application card includes an arbiter
 that monitors the plurality of communication buses to determine which
 communication bus is allowed access to the application card. To this end,
 the arbiter monitors when a communication bus becomes active. When it
 detects a communication bus is active and no other mutually exclusive bus
 is active, the arbiter will allow that communication bus to access the
 application card. The communication bus can be switched to access the
 local bus of the application card. Once a communication bus is allowed
 access to the communication card, a hold off signal may be given to other
 communication buses accessing the application card. In addition, a timer
 may be utilized with the present embodiment to prevent a device from
 holding the communication bus to the application card for too long a
 period of time. It should be understood that the application card may be
 simultaneously accessed by a number of communication buses while other
 communication buses utilize mutually exclusive (one-at-a-time) access to
 the application card.
 According to another aspect of the present invention, the arbiter allows
 the application card to dynamically select or arbitrate between different
 communication buses. The arbiter may include state machine logic to
 implement appropriate protocol of the communication bus. The arbiter can
 employ a variety of different algorithms to allow and control access to
 the application card. The arbiter may allow access to the application card
 according to the priority of different communication buses. The arbiter
 can allow simultaneous access to the application card according to the
 types and classes of different communication buses. Using the present
 invention, any arbitrary scheme for selecting among a plurality of
 communication buses may be implemented and dynamically tailored and
 changed according to the needs of the particular device.
 The foregoing and other features and advantages of an illustrative
 embodiment of the present invention will be more readily apparent from the
 following detailed description, which proceeds with references to the
 accompanying drawings.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT
 FIG. 1 diagrammatically illustrates a simplified example of an electronic
 equipment card chassis 12 utilizing an illustrative embodiment of the
 invention. The exemplary system, includes a card chassis 12 utilized in a
 communication interface device such as a network access server ("NAS"),
 remote access server ("RAS"), router, bridge, gateway or other type of
 suitable communication device.
 In the illustrative embodiment, the card chassis 12 provides a plurality of
 available card slots (not shown) capable of holding a plurality of
 electronic circuit or application cards 20 that may perform a variety of
 different functions. The card chassis 12 provides the facility to provide
 a backplane having a plurality of communication buses for the application
 equipment cards 20 contained in the card chassis 12 to communicate with
 other application equipment cards 20 in the card chassis 12. To facilitate
 communications between the different application cards 20 in the card
 chassis, a plurality of different types of communication buses provide
 communication access and coordination between the different application
 cards 1-12 in the card chassis. This illustrative embodiment will be
 described with respect to an implementation using an I.sup.2 C-bus to
 provide communication for a management card implementing a variety of
 management functions for the different cards in the chassis 12.
 Although the exemplary embodiment described herein is in relation to
 management cards communicating to application cards over a particular type
 of bus using a particular communication protocol. It should be understood
 that the present embodiment can be applied to any type of communication
 buses which require arbitration between a plurality of buses. For example,
 a card chassis 12 may also include an Asynchronous Transfer Mode ("ATM")
 bus or Star bus to handle data call type traffic between modems and the
 Switch Fabric/Management Card 26, as well as voice-data call setup over a
 TDM bus. The card chassis may also include two separate ATM buses to
 provide back up for fault tolerant operation that can be arbitrated
 between the two buses as taught herein. It should be understood that
 additional buses or fewer buses than described herein may be provided.
 In this preferred embodiment, the Switch Fabric/Management Card 26 oversees
 the operation of all the components in the card chassis. The Switch
 Fabric/Management card 26 may provide a variety of system management
 functions of the card chassis 12 such as software download to the various
 application cards upon power up, the operational configuration of the
 application cards, and providing card status and statistics. An I.sup.2
 C-bus 18a may also be provided for Switch Fabric/Management Card 26 to
 communicate control and management functions of the application cards 20.
 To provide for fault tolerant operation, a plurality of redundant Switch
 Fabric/Management Cards 26 and associated I.sup.2 C-bus may be provided.
 The Inter-IC bus or I.sup.2 C-bus in this exemplary embodiment is generally
 designed to connect a number of integrated circuit ("ICs") devices. The
 I.sup.2 C-bus is a multi-master bus, meaning that a plurality of devices,
 such as ICs, can be connected to the bus, and each of the devices may act
 as the master of the bus by taking control of the bus to initiate a data
 transfer. According to the I.sup.2 C-bus standard, a device that transmits
 signals onto the I.sup.2 C-bus is the "transmitter." A device that
 controls signal transfers on the bus in addition to controlling the clock
 frequency of the bus is the "master." A device that receives signals from
 the bus is the receiver and a device that is controlled by the master is a
 "slave." The master device can transmit or receive signals to or from a
 slave device, respectively, or control signal transfers between two slave
 devices, where one slave device is the transmitter and the other slave
 device is the receiver. It is also possible to combine multiple master
 devices and multiple slave devices, onto an I.sup.2 C-bus to form a
 multi-master system. In this multi-master system, if more than one master
 device simultaneously attempts to control the line a conflict arises and
 an arbitration procedure must decide which master device gets priority.
 In addition to communication conflicts over a single bus, multiple I.sup.2
 C-buses accessing the same application card may also potentially conflict.
 In some systems, several I.sup.2 C-buses may exist for redundancy and
 fault tolerant operation. As previously described, a card chassis holding
 a number of application cards may include a management card such as Switch
 Fabric/Management Card 26 to control the operation of the card chassis and
 application cards within the chassis. To provide for fault tolerant
 operation, a plurality of management cards may be provided for backup and
 redundancy. Each of the management cards will have its own communication
 bus access to each application card. These redundant management
 communication buses, however, should have mutually exclusive data
 communication access to the application card to avoid conflicts and
 contention between multiple devices.
 Referring again to FIG. 1, in this exemplary implementation a primary or
 first management card 26 and a second management card 27 may be provided
 for redundancy in the case of a failure of the first management card 26.
 Each of these management cards 26, 27 preferably has their own
 communication bus shown as separate I.sup.2 C-buses 18a, 18b to
 communicate to each application card in card slots 1-12 of the card
 chassis 12. The card chassis 12 backplane will provide I.sup.2 C-bus
 connections 18a, 18b from each of the management card slots to each of the
 application card slots. FIG. 1 diagrammatically shows the I.sup.2 C-buses
 18a, 18b as a series of connections between each of the management cards
 26, 27 and the card slots 1-12. As seen in FIG. 2, an application card in
 each of the card slots 1-12 will therefore have two management
 communication buses 18a, 18b, one from each of the management cards 26,
 27, accessing each card slot.
 At any time, either of the management cards 26, 27 may initiate a
 communication or data transfer over its I.sup.2 C-bus to an application
 card using an I.sup.2 C-bus Start Sequence as described in more detail
 below. As a result, the application card receiving commands from the
 management cards via the I.sup.2 C-buses 18a, 18b must be able to
 dynamically switch between the two I.sup.2 C-bus interfaces to receive the
 data transfer. To select between the I.sup.2 C-buses, the application
 cards preferably include an arbiter that provides an interface to the
 I.sup.2 C-buses accessing the card and appropriately allows the active
 communication bus to access the application card.
 Referring now to FIG. 2, shown is a diagrammatic illustration of an
 application card 20 with an arbiter 50 that may be utilized to interface a
 plurality of incoming communication buses to the application card 20. The
 arbiter 50 also preferably implements and provides the selection between
 the plurality of mutually exclusive communication buses 18a, 18b having
 communication access to the application card 20. The active communication
 bus carrying communications for the application card will access the
 devices on the application card through a local bus (Local Data and Local
 Clock), which may also include an I.sup.2 C-bus. As shown in the example
 of FIG. 2, a plurality of communication buses, Bus A and Bus B 18a, 18b in
 this example, access the application card 20. Thus, the application card
 20 may receive messages from either of the communication buses, Bus A or
 B. The arbiter 50 determines which of the communication buses 18a, 18b the
 application card 20 (at Local Card Data and Local Card Clock) will receive
 messages from using methods described in more detail below. Once the
 selection of the active incoming communication bus is made, the selected
 communication bus and data is allowed to access the application card on
 the Local Card Data and Local Card Clock. The Local Data and Local Card
 may access a variety of devices on the application card 20, such as the
 Slave devices 1-4 shown in FIG. 2.
 It should also be noted that the power source, Vcc for the application card
 can be supplied from a 3.3V supply line from the management card 26 to
 ensure the HNM is active even if the main power of the application card
 itself is turned off. Preferably, the arbiter 50 draws power from two
 supply pins on the backplane driven by management cards 26, 27. The supply
 pins are OR'ed on the application card and then fused (not shown). In a
 preferred embodiment, the application card is limited to drawing 200 mA.
 The combination of the ower supplies from different sources, the two
 management cards in this exanple, provides edundancy in the case of
 failure of a power supply.
 The arbiter 50 provides an interface to the communication buses 18a, 18b,
 and acts as a bi-directional multiplexer selecting which of the plurality
 of communication buses will be allowed access to the Local Card Data and
 Clock bus of the application card. A bus interface typically includes an
 interface to the communication bus according to the standards and
 requirements of the particular type of communication bus being interfaced.
 In this example, the interface requirements of the I.sup.2 C-bus are
 published by Philips Semiconductors and widely known and available. Of
 course, the arbiter 50 can be interfaced to a variety of other bus
 interfaces as well. Preferably, the arbiter 50 incorporates most of the
 basic I.sup.2 C-bus protocols which allows it to monitor transactions on
 the bus and switch direction of the bus when appropriate. More details
 regarding particular I.sup.2 C-bus protocols will be provided below.
 Preferably, the operation of the arbiter 50 is transparent to the
 transactions on the buses. In the preferred embodiment, the arbiter does
 not have an I.sup.2 C-bus address and is not directly accessible from the
 switch management card.
 Referring now to FIG. 3, shown is a hardware embodiment of the Bus Arbiter
 50 interfacing a plurality of communication buses, Bus A and Bus B in this
 example. The exemplary embodiment of the Bus Arbiter 50 employs state
 machines that are clocked by the external 10 MHz oscillator including
 Start/Stop Detection 52, Read/Write Detection 54 and Direction Control 56
 controlling access from the communication buses to a local bus. Associated
 controllers and timers 58 are also shown. The Start/Stop Detection state
 machine 52 monitors for a start condition on either communication bus. An
 I.sup.2 C-bus implements a particular Start Sequence that indicate the
 communication bus is active and ready to initiate a transaction. A
 particular Start Sequence of the I.sup.2 C-bus protocol as well as a Stop
 Sequence of the I.sup.2 C-bus is described below in more detail with
 reference to FIGS. 7A and 7B. Once an active communication bus determined
 by matching the Start Sequence, an internal multiplexer connects the
 active communication bus to the local application card bus. The other,
 non-active communication buses are held off. Any signaling on the other
 communication buses (except for a Stop Sequence) is ignored until the
 transaction on the current communication bus is completed. Preferably, a
 Stop Sequence on any communication bus, however, will be received and
 reset the arbiter 50, terminating the ongoing transactions on either
 communication bus. The ability of a Stop Sequence from any of the
 plurality of communication buses to terminate read and write transactions
 on any active bus provides a mechanism to recover from a failed
 communication and reset the system as described in more detail below.
 A Control State machine 56 implements the basic I.sup.2 C protocol decoding
 the address phase of the protocol to determine if the transaction will be
 a read or write transaction. The bus arbiter 50 switches direction of the
 communication bus appropriately for the acknowledge handshaking between
 the master and slave I.sup.2 C-bus devices on the bus according to the
 appropriate protocol. The flowchart of FIG. 4 further explains the logic
 of an exemplary Control State machine 56 used to determine a read
 transaction or a write transaction on the bus. The flowchart of FIG. 4 can
 be implemented by those skilled in the art as a hardware state machine to
 determine between a read or write transaction.
 The I.sup.2 C-bus read and write protocols of the preferred embodiment are
 shown in FIG. 5A and 5B. As seen in FIG. 5A and 5B the read and write
 transactions are both initiated with a Start Sequence or Start Condition
 which is described in more detail below (An exemplary Start Sequence is
 shown in FIG. 6A and described below in more detail). The three most
 significant bits of a write transaction begin with 3-bit device address
 and the 8.sup.th bit a read/write bit indicating the type of transaction.
 An ACK follows the read/write bit followed by a word address. Following
 the word address is another ACK and then the data bits are transmitted,
 most significant bits first. Read transactions progress similarly as shown
 in FIG. 6B. Both transactions are terminated by a Stop Sequence or Stop
 Condition on any of the communication buses, as shown in FIG. 6B.
 The Start/Stop Detection state machine 52 implements logic and circuitry to
 detect the Start/Stop sequence protocol as shown in FIGS. 6A and 6B. As
 shown in FIGS. 6A and 6B, in the illustrative embodiment using the I.sup.2
 C-bus, the I.sup.2 C protocol specifies a transaction sequence for the
 start/stop detection of I.sup.2 C-bus transactions. The protocol examines
 the Data and Clock lines to determine the status of the bus transaction.
 On and the inactive bus, the Data and Clock lines with both be in the high
 logic states as shown at interval A. To indicate the start sequence of the
 bus, the Data line transitions to the low logic state such that the Data
 line is low and Clock line is still high, as shown as interval B. The
 Clock line then transitions to the low logic level as data transmission
 occurs at interval C. The stop sequence occurs when the Clock line starts
 high and the Data line is low and begins to transition high at interval D.
 After the Clock line is high, the Data line starts high at interval E. The
 Data and Clock lines are then interval F, signifying the Stop sequence.
 Using the Start and Stop sequence of the I.sup.2 C-bus protocol, the
 arbiter can be programmed to identify active communication buses,
 determine a failed communication bus and allow access to a backup
 communication bus. For example, in one embodiment a timeout is initiated
 upon the detection of a Start sequence as described in FIG. 4 above and
 terminated upon the detection of a Stop sequence. If a Stop sequence is
 not detected within a prescribed timeout period, the present communication
 bus may be assumed to be locked up, failed or otherwise gone
 out-of-service. The prescribed timeout should be chosen according to the
 requirements of the particular communication bus protocol, in this case
 the I.sup.2 C-bus protocol.
 FIGS. 7A and 7B show an illustrative embodiment of Start/Stop Detection
 state machine logic 52 that can be used to detect the Start and Stop
 Sequences of the read and write transactions of FIGS. 6A and 6B. The
 Start/Stop detections can implemented with flip-flops that can be
 including ordinary combinational logic well-known by those skilled in the
 art. The Read/Write Detection 54 implements processes to handle read and
 write transactions from the communication bus. As discussed in herein,
 FIGS. 8 and 9 show exemplary process for read and write transactions that
 can be implemented by the Read/Write Detection 54.
 An exemplary Read/Write State Machine 54 processes the reads and writes to
 and from the appropriate communication bus as determined from the
 Start/Stop Detection 52. FIGS. 9 and 10 show the illustrative flow charts
 of the Read/Write State Machine 54. It will be appreciated by those
 skilled in the art that the can implement the flow charts with a logic
 state machine using combinational logic. A stop condition on either
 communication bus resets the control state machine 56.
 It should be understood that the arbiter 50 can use a variety of procedures
 to select between the plurality of communication buses. FIG. 10 shows a
 general method that can be utilized by the arbiter 50 to select the
 appropriate communication bus to interface to the application card 20. At
 Step 100, the arbiter 50 monitors the plurality of communication buses to
 determine if a communication buses has become active with data from a
 management card. At Step 102, an active communication bus can be
 determined in any variety of ways well known to those skilled in the art
 including monitoring protocols sent on the communication buses.
 At Step 104, the active communication bus is allowed access to the
 application card by connecting or switching the active communication bus
 to the local bus of the application card. The access to the local card can
 be provided by a switching function device implemented through an
 integrated switching matrix, a simple decoder or other solid state
 integrated circuit. At Step 106, the arbiter prevents the other
 communication buses from accessing the application card to prevent
 possible conflicts and contention between the buses.
 Because the I.sup.2 C-bus is bidirectional, the arbiter also preferably
 includes knowledge of the I.sup.2 C protocol to appropriately switch the
 bus direction as described above.
 Alternatively, the arbiter may select among a plurality of communication
 buses according to a programmed algorithm or other criteria. A priority
 can be assigned to communication buses and the priority of the
 communication bus used to selected the appropriate communication bus to
 allow access to the application card. A priority can also be utilized to
 allow a communication bus to preempt communication buses of lower
 priority. Communication buses may be assigned to classes in which certain
 classes are allowed simultaneous access to the application card and other
 classes of communication buses access the card mutually exclusively. The
 management card may download updated priority scheme to the arbiter over
 to the I.sup.2 C-bus. Using the arbiter, any arbitrary scheme for
 selecting among a plurality of communication buses may be implemented and
 tailored and modified according to the needs of the particular device.
 Those skilled in the art will recognize that the bus arbiter and methods
 disclosed herein provides have many different uses and provides many
 advantages for allowing multiple access to electronic circuit cards. By
 resolving potential contention between multiple communication buses
 accessing a device the present embodiment has many applications beyond
 implementing redundancy within a communication card chassis as disclosed
 for illustrative purposes herein. For example, the present invention can
 be utilized whenever multiple access to an electronic circuit card or
 device is regulated.
 The present embodiment preferably includes logic to implement the described
 methods in software modules as a set of computer executable software
 instructions. The Computer Processing Unit ("CPU") or microprocessor
 implements the logic that controls the operation of the channel card. The
 microprocessor executes software that can be programmed by those of skill
 in the art to provide the described functionality. The software can be
 represent as a sequence of binary bits maintained on a computer readable
 medium including magnetic disks, optical disks, organic disks, and any
 other volatile or (e.g., Random Access memory ("RAM")) non-volatile
 firmware (e.g., Read Only Memory ("ROM")) storage system readable by the
 CPU. The memory locations where data bits are maintained also include
 physical locations that have particular electrical, magnetic, optical, or
 organic properties corresponding to the stored data bits. The software
 instructions are executed as data bits by the CPU with a memory system
 causing a transformation of the electrical signal representation, and the
 maintenance of data bits at memory locations in the memory system to
 thereby reconfigure or otherwise alter the unit's operation. The
 executable software code may implement, for example, the methods described
 in further detail below.
 It should be understood that the programs, processes, methods and apparatus
 described herein are not related or limited to any particular type of
 computer or network apparatus (hardware or software), unless indicated
 otherwise. Various types of general purpose or specialized computer
 apparatus may be used with or perform operations in accordance with the
 teachings described herein.
 In view of the wide variety of embodiments to which the principles of the
 present invention can be applied, it should be understood that the
 illustrated embodiments are exemplary only, and should not be taken as
 limiting the scope of the present invention. For example, the steps of the
 flow diagrams may be taken in sequences other than those described, and
 more or fewer elements may be used in the block diagrams.
 It should be understood that a hardware embodiment may take a variety of
 different forms. The hardware may be implemented as an integrated circuit
 with custom gate arrays or an application specific integrated circuit
 ("ASIC"). Of the course, the embodiment may also be implemented with
 discrete hardware components and circuitry. Preferably, the present
 embodiment is embodied as a Programmable Logic Device.
 The claims should not be read as limited to the described order or elements
 unless stated to that effect. In addition, use of the term "means" in any
 claim is intended to invoke 35 U.S.C. .sctn.112, paragraph 6, and any
 claim without the word "means" is not so intended. Therefore, all
 embodiments that come within the scope and spirit of the following claims
 and equivalents thereto are claimed as the invention.