The present invention relates to a network interface system having a bus architecture: and more particularly to a system that facilitates the transfer of data among a collection of devices via a common bus without the need for connecting each device separately to a central unit.
In a bus architecture, all of the devices on the network communicate via a common set of data lines. This is in contrast to some other network architectures wherein each device is connected to a hub or switch via an individual connection.
The MII (Media-Independent Interface) is a standard interface specified in IEEE Standard 802.3, The Institute of Electrical and Electronics Engineers, New York, N.Y., 2000, which is incorporated by reference for all purposes as if fully set forth herein. The MII provides specifications for the connection of the Ethernet MAC (Media Access Control) layer to the Ethernet Physical (PHY) layer. The MII is incorporated in many devices, such as CPU's and network processors. The MII is intended to connect a single MAC to a network cable leading to a port on a device such as a hub or switch. Although the Ethernet transmits data serially, the MII transmits data in parallel. In an Ethernet network, the MII is connected to a PHY interface, which handles, among other things, the interconversion of serial and parallel data. Over short distances, parallel data transmission is advantageous because it allows the use of slower, cheaper electronic components, although it does require more data paths, and is subject to data timing problems, both of which problems are of only minor significance for short-distance data transmission.
It is often desirable to connect several devices in a private network in a limited space where cost and reliability are primary considerations, while the ability to support connections of more than approximately one meter is unimportant. This is particularly the case when it is desired to interconnect several printed-circuit cards within a single chassis, by means of a printed-circuit backplane, in which case all of the communicating devices are in very close proximity to each other typically less than one meter. In such a situation, especially where the communicating devices incorporate MII interfaces, it is often desirable to use parallel data transmission rather than incur the expense of a full serial Ethernet system, with a full PHY interface for each device on the network.
Connecting multiple devices via a bus presents a problem because more than one device may try to drive the bus at the same time. This is especially troublesome if the driving devices include active pullup. FIG. 1 and FIG. 2 illustrate prior-art output drivers having active pullup. Drivers such as these are often referred to as “totem-pole” outputs. FIG. 1 illustrates a bipolar-transistor active-pullup output driver. FIG. 2 illustrates a field-effect-transistor (FET) active-pullup output driver.
Active pullup devices effectively connect the driven line to either a high or low logic level. In the bipolar active-pullup output driver of FIG. 1, output 24 is driven to a low logic level when driving circuitry (omitted here for simplicity) connected to base 10 of transistor 18 and base 12 of transistor 20, cuts off current to the base 10 of transistor 18, making transistor 18 non-conductive, and drives current into the base 12 of transistor 20, making transistor 20 conductive. In contrast, output 24 is driven to a high logic level when current is driven into the base 10 of transistor 18, making transistor 18 conductive, and current to the base 12 of transistor 20 is cut off, making transistor 20 non-conductive.
Similarly, in the FET active-pullup output driver of FIG. 2, output 44 is driven to a low logic level when driving circuitry (omitted here for simplicity) connected to gate 30 of FET 38 and gate 32 of FET 40, places a high voltage oil gate 30 of p-channel FET 38, making FET 38 non-conductive, and places a high voltage on gate 32 of n-channel FET 40, making FET 40 conductive. In contrast, output 44 is driven to a high logic level when a low voltage is placed on gate 30 of p-channel FET 38, making FET 38 conductive, and a low voltage is placed on gate 32 of n-channel FET 40, making FET 40 non-conductive.
Direct connection of the outputs of two or more active-pullup devices is considered poor practice in the art, because, in a situation where one device attempts to drive a high logic level and another device attempts to drive a low logic level, the resulting logic level is indeterminate, and large Currents flowing through the switching devices may damage the switching devices or other components of the system.
As used herein, unless otherwise specified, the term “open-driver” refers to a device, without active pullup, for driving a logic signal. The tern “open-driver” derives from the term “open-collector”, which, in turn, derives from bipolar transistor technology. Open-driver, as used herein, is a more general term than open-collector, referring not only to open-collector topologies, but also to similar topologies, such as open-drain, implemented in other technologies, such as FET technology.
In a typical application, an open-driver device drives a low logic level on its output by connecting the output, via a switching device such as a bipolar transistor or FET, to a low logic level, such as ground. When an open-driver device is not driving a low logic level on its output the output of the open-driver device is in a high-impedance state, i.e., the switching, device is made to stop conducting, allowing the output to reach a logic level determined by whatever other devices are connected to the output. Typically, at least one resistor, known as a pullup resistor, is connected from the output to a high logic level, such as the power supply, so that the output line is at a high logic level whenever all open-driver devices connected to the line are in a non-conducting state.
FIG. 3 illustrates schematically a bipolar-transistor open-collector driver. In this version of an open-driver driver, a low logic level is driven on output 104 by allowing current to flow into base 100 of transistor 102; causing transistor 102 to become conductive and effectively connect output 104 to ground. If current flowing through base 100 is insufficient to make transistor 102 conductive, the driver is said to be in a high-impedance state, and the potential of output 104 is determined by whatever other circuitry, not shown, is connected to output 104. Typically, such circuitry includes at least one pullup resistor.
FIG. 4 illustrates schematically an FFT open-drain driver. In this version of an open-driver driver, a low logic level is driven on output 114 by impressing a high logic level on gate 110 of n-channel FET 112, causing FET 112 to become conductive and effectively connect output 114 to ground. When the potential applied to gate 110 is insufficient to make FET 112 conductive, the driver is said to be in a high-impedance state, and the potential of output 114 is determined by whatever other circuitry, not shown, is connected to output 114. Typically, such circuitry includes at least one pullup resistor.
An alternative configuration for an open-driver driver utilizes a device having a three-state output. A three-state device is able to, alternatively, drive its output to a low logic level, drive its output to a high logic level, or place its output in a high-impedance state. In the high-impedance state, the three-state driver is effectively disconnected from its output line, allowing the output line to be driven by other, similar devices connected to the output line. When in the high-impedance state, a three-state driver is said to be “disabled”, and when not in the high-impedance state, a three-state driver is said to be “enabled”. An example, illustrated schematically in FIG. 5, of a three-state driver configured as an open-driver driver uses a three-state buffer 120 with an inverting three-state control input 122. If three-state-control input 122 is at a low logic level, output 124 of buffer 120 follows input 126 of buffer 120. If three-state-control input 122 is at a high logic level, output 124 of buffer 120 is in a high-impedance state. Because input 126 of buffer 120 is set to a low logic level by being connected to ground, a low logic level applied to three-state-control input 122 causes a low logic level to be driven on output 124 of buffer 120. A high logic level applied to the three-state-control input 122 causes output 124 of buffer 120 to be in a high-impedance state. With appropriate pullup, not shown, output 124 will be at a high logic level if output 124 of buffer 120 is in a high-impedance state. Thus, the configuration of FIG. 5 effectively performs as an open-driver driver. This configuration is particularly useful where ordinary open-driver outputs are not available, but three-state outputs are available, or where parts of a system have spare three-state drivers.
As used herein, the term “wired-and” refers to the connection in common of open-driver outputs such that the logic level of the common connection is low if any one or more of the open-driver outputs is driving a low logic level. Note that, in the degenerate case of a single open-driver output, the configuration can still be referred to as a wired-and, because the single output is low if the single open-driver output is driving a low logic level.
FIG. 6 illustrates schematically, by way of example only, an FET wired-and configuration, although it will be appreciated that the concepts discussed apply to wired-and configurations incorporating other types of open-driver drivers.
According to accepted practice in the art, the common connection 130 of wired-and connected open-driver outputs 132 is further connected, by means of a resistor 134, known as a pullup resistor 134, to a conductor 136 at a high logic level. A wire-and connection without a pullup resistor 134 may operate, but is likely to be slow and unreliable, and thus neglecting to include a pullup resistor 134 is considered poor practice in the art.
If several open-driver outputs 132 are wired together and a pullup resistor 134 is included, and none of the FETs 138 is in a conductive state pullup resistor 134 effectively connects common connection 130 to conductor 136, causing common connection 130 to be at a potential near the potential of conductor 136, and this potential is referred to herein as the default logic state of the common connection 130, or, more simply, the default. If one or more of the FETs 138 is in a conductive state, the potential of the common connection 130 follows that of the open-driver outputs 132 of the conductive FETs 138, and this potential is referred to herein as the driven potential.
Common Ethernet local area networks (LAN's), such as 100BaseT, are usually configured in a “star” architecture, with each device on the network connected via its own four-wire cable to a central unit, such as a hub or switch. Because each device must have its own four-wire connection to the central unit, implementing such an interface on a printed-circuit backplane requires 4N traces, where N is the number of devices. Thus, a system with twenty printed circuit cards communicating via a network implemented on a single, common backplane would require 80 circuit traces. A bus architecture where all of the devices communicate via a small number of shared circuit traces driven by open-driver drivers makes the design of the backplane much simpler, because each device need only connect to a small number of shared circuit traces. Many devices are equipped with a parallel-format MII interface, and it is desirable to eliminate the cost of also including an Ethernet PHY interface. In a star architecture, the reliability of the central unit is critical. If the central unit fails or is absent, the entire network is not usable. In a bus architecture, there is no central unit to fail.
There is thus a widely recognized need for, and it would be highly advantageous to have, a system for allowing a group of devices located in close proximity to each other to communicate with each other via a bus architecture. Optionally, the communication bus would provide parallel data paths. Preferably, the communication bus would allow the devices to communicate with each other through an interface that appears to each device as would an MII interface, but without the expense and complication of a full Ethernet implementation.