US20040255193A1 - Inter integrated circuit router error management system and method - Google Patents
Inter integrated circuit router error management system and method Download PDFInfo
- Publication number
- US20040255193A1 US20040255193A1 US10/461,209 US46120903A US2004255193A1 US 20040255193 A1 US20040255193 A1 US 20040255193A1 US 46120903 A US46120903 A US 46120903A US 2004255193 A1 US2004255193 A1 US 2004255193A1
- Authority
- US
- United States
- Prior art keywords
- port
- bus
- router
- inter
- integrated circuit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/349—Performance evaluation by tracing or monitoring for interfaces, buses
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
- G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
- G06F13/4291—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus using a clocked protocol
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/348—Circuit details, i.e. tracer hardware
Abstract
The present invention provides a convenient and efficient integrated circuit router error management system and method. In one embodiment an inter-integrated circuit router error management system comprises a high-speed internal bus, an inter-integrated circuit port, a high-speed external port and an error register. The high-speed internal bus communicates information. The inter-integrated circuit port is coupled to the high-speed internal bus and the inter-integrated circuit port provides an interface for communicating information with an inter-integrated circuit bus segment. The high-speed external port is coupled to the high-speed internal bus and the high-speed external port provides an interface to an external high-speed bus. The error register is coupled to the inter-integrated circuit port and the error register captures errors in communication operations.
Description
- The invention relates to the field of bus communications.
- Numerous electronic circuits and systems are utilized to perform useful tasks. In the performance of these tasks, the electronic circuits and systems often communicate with one another via a communication bus. One type of communication bus is the inter-integrated circuit bus (I2C bus). The I2C bus provides a communication link between integrated circuits (ICs) and electronic systems. Traditionally, an I2C bus consists of two active wires referred to as the serial data line (SDA) and serial clock line (SCL).
- Prior Art FIG. 1 is an illustration of
I2C bus system 100 configured in an exemplary conventional arrangement wherein amanagement processor 110 manages communication access onI2C bus 115. TheI2C bus 115 comprises an SCL line 112 and anSDA line 114 that provide bi-directional communication paths which are coupled to modular field replaceable units (FRUs) 120, 121, and 122. Pull-upresistors SDA line 114 respectively to establish a default state on each line. The FRUs can be a variety of components including a server blade, a server card, a driver, a memory, or complex function IC. The I2C bus can be used with an intelligent platform management interface (IPMI) or other I2C protocols. - Conventional I2C buses utilize a master-slave or master-master communication protocol for transmitting packets (e.g., well defined blocks of data comprising a header, data and a trailer) between devices coupled to the bus. Components (e.g., FRUs) coupled to the I2C bus have a unique address and can behave as a sender or receiver of data (e.g., depending on specific functionality of the device). With IPMI, each “intelligent” device on the bus acts as a master and utilizes a master-master communication protocol. A component (e.g., FRU120), attempting to transmit information on the I2C bus while another master (e.g., the management processor) controls the bus, must adhere to the arbitration rules of I2C. Essentially, all devices that are attempting to gain control of the bus must also monitor the bus and back off as soon as the signals do not match what the individual device is attempting to write. Because the bus is pulled high by pull-up resistors, and only driven low by active devices, the device driving low wins control of the bus.
- One major concern for communication systems is security maintenance. Preventing unintended and/or unauthorized entities from accessing information communicated on a bus is usually desirable. However, traditionally it is usually possible for unintended components to spoof communications on I2C busses. For example, communications on an I2C bus in a common chassis (e.g., a host-client situation wherein slots are rented in a common chassis) intended for components utilized by a first entity (e.g., a first company) can be received by another component utilized by a second entity (e.g., a competing company). More specifically, it is possible for a device to “spoof” the I2C bus to deliberately receive data (e.g., a competitor's confidential information) that was not destined for the particular “spoofing” device.
- There are a number of issues that arise in maintenance of traditional I2C bus systems. For example, if there is a bus failure on a segment of an I2C bus, communications are typically lost to the components coupled to the bus even if the components are not on the segment that is lost. To provide proper maintenance it is usually beneficial to have a good understanding of the type and number of devices coupled to an I2C bus and traditionally this is manually performed which is labor intensive and often inconvenient, especially if the components are remotely located. It is also usually difficult to discover errors in a system and provide corrective directions. For example, it is traditionally difficult to detect and remedy a situation in which one device effectively “captures” the bus by becoming a master and continuously transmitting information to prevent others from using the bus. Capacitance characteristics of devices coupled to an I2C bus also often can make maintenance and reconfiguration difficult.
- Components coupled to an I2C bus usually create a capacitive load on the I2C bus, which together with the pull-up resistors produce RC constant characteristics that impact attributes of signals communicated via the I2C bus. For example, signal waveforms can be altered and the ability of components to distinguish between logical ones and zeroes impacted. As a result, it is desirable maintain an appropriate balance between the capacitive and resistive characteristics of the I2C bus lines. However, maintaining a capacitive and resistive balance can be difficult when adding or deleting components dynamically since the number and type of components on a bus impact the capacitive characteristics. Traditional attempts at achieving a balance usually limited the number of components coupled to an I2C and often involve costly bus redesign, which if done incorrectly can cause bus interrupts, or possibly catastrophic bus failure.
- In current I2C bus systems, each component is assigned an I2C address. For example, with reference to FIG. 1,
FRU 120, FRU 121 and FRU 122 each have an assigned I2C address. As described above, consider a situation where FRU 120 is operated by the first entity and FRU 121 is operated by the second entity. If the second entity desires to access data being transmitted toFRU 120, FRU 121 may spoof current I2C bus systems into believing it isFRU 120 by using the I2C address ofFRU 120. - The I2C bus according to the conventional art also suffers from the inability to detect the presence of a device (e.g., field replaceable unit) coupled thereto, the inability to determine if the device coupled thereto is functional and/or the inability to reset the device when an error occurs. Furthermore, the I2C bus according to the conventional art also suffers from the inability to provide for readily analyzing and debugging data traffic on the I2C bus. The serial two-line I2C bus is difficult to trap events on, because a serial data pattern must be trapped. In addition, it is also difficult to detect what device is the source device; only the destination device address can readily be trapped.
- The present invention provides a convenient and efficient integrated circuit router error management system and method. In one embodiment an inter-integrated circuit router error management system comprises a high-speed internal bus, an inter-integrated circuit port, a high-speed external port and an error register. The high-speed internal bus communicates information. The inter-integrated circuit port is coupled to the high-speed internal bus and the inter-integrated circuit port provides an interface for communicating information with an inter-integrated circuit bus segment. The high-speed external port is coupled to the high-speed internal bus and the high-speed external port provides an interface to an external high-speed bus. The error register is coupled to the inter-integrated circuit port and the error register captures errors in communication operations.
- The present invention is illustrated by way of example and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
- Prior art FIG. 1 shows a block diagram of a conventional inter-integrated circuit bus system according to the conventional art.
- FIG. 2 shows a block diagram of an inter-integrated circuit bus system comprising an inter-integrated circuit router in accordance with an embodiment of the invention.
- FIG. 3 shows a block diagram of an inter-integrated circuit router in accordance with an embodiment of the invention.
- FIG. 4 shows a flow diagram of a process for controlling communication on an I2C router in accordance with an embodiment of the invention.
- FIG. 5 shows a block diagram of an inter-integrated circuit router in accordance with an embodiment of the invention.
- FIG. 6A shows a flow diagram illustrating a process for securely controlling data communication at an inter-integrated circuit router in accordance with an embodiment of the invention.
- FIG. 6B shows a flow diagram illustrating a process for comparing a destination address to control information in accordance with an embodiment of the invention.
- FIG. 7A shows an exemplary mask register settings in accordance with an embodiment of the invention.
- FIG. 7B shows an exemplary comparison of control information and destination addresses in accordance with an embodiment of the invention.
- FIGS. 8A and 8B show a flow diagram of a method of transmitting data through an I2C router in accordance with an embodiment of the invention.
- FIG. 9 shows a flow diagram of an alternative method of transmitting data though an I2C router in accordance with an embodiment of the invention.
- FIGS. 10A and 10B show a flow diagram of a method of transmitting data through an I2C router in accordance with an embodiment of the invention.
- FIG. 11 shows is a flow diagram of an alternative method of transmitting data through an I2C router in accordance with an embodiment of the invention.
- FIG. 12 is block diagram of an inter-integrated circuit (I2C) router error management system in accordance with one embodiment of the present invention.
- FIG. 13 is a flow chart of an inter-connected router error management method in accordance with one embodiment of the present invention.
- FIG. 14 shows a data flow diagram of an exemplary inter-integrated circuit router for supporting independent transmission rates in accordance with an embodiment of the invention.
- FIGS.15A-C show flow diagrams illustrating processes for communicating data between ports of an inter-integrated circuit router in accordance with embodiments of the invention.
- FIG. 16 shows a block diagram of an I2C router, in accordance with an embodiment of the invention.
- FIG. 17A shows a flow diagram of a method of detecting the presence of a device coupled to an I2C router, in accordance with an embodiment of the invention.
- FIG. 17B shows a flow diagram of a method of resetting a device coupled to an I2C router, in accordance with an embodiment of the invention.
- FIG. 18 shows a block diagram of an I2C router, in accordance with an embodiment of the invention.
- FIG. 19 shows a flow diagram of a method of analyzing traffic in an I2C router, in accordance with an embodiment of the invention.
- Reference will now be made in detail to the embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it is understood that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
- Referring now to FIG. 2, a block diagram of an inter-integrated circuit (I2C)
router system 200, in accordance with an embodiment of the invention, is shown. The exemplaryI2C router system 200 comprises amanagement processor 201, anI2C router 250 and a plurality of field removable units (FRUs) 220, 221 and 222.Management processor 201 is coupled toI2C router 250 by high-speedexternal bus 240. TheFRUs I2C router 250 by electrically isolatedI2C bus sections I2C bus section SDA line 261 andSCL line 271 ofI2C bus section 241communicatively couple FRU 220 toI2C router 250,SDA 262 andSCL line 272 ofI2C bus section 242communicatively couple FRU 221 toI2C router 250, andSDA line 263 andSCL line 273 ofI2C bus section 243communicatively couple FRU 222 toI2C router 250. Pull-up resistors (e.g., pull-up resistor 290) are coupled to the SDA lines and the SCL lines (e.g., SCL line 273). -
Exemplary I2C router 250 comprises high-speedexternal port 210, high-speedinternal bus 281,I2C ports I2C router 250 may comprise any number of ports, and is not limited to this embodiment. High-speedinternal bus 281 is coupled to high-speedexternal port 210, andI2C ports I2C port controller electrical connector - In one embodiment, the components of
exemplary I2C router 250 cooperatively operate to provide security for communications between I2C bus sections (e.g.,I2C bus sections I2C router 250 by controlling communications through the ports included inI2C router 250. Theelectrical connectors I2C bus sections I2C router 250. In one exemplary implementation, each electrical connector includes a serial data pin and a serial clock pin.Controllers electrical connectors - Preventing the electrical connectors from gaining unauthorized access to data provides additional security for external components or devices (e.g.,
FRUs I2C router 250 to communicate with each other. For example,controller 257 a prevents spoofing of data off internal high-speed bus 281 for communication throughelectrical connectors 259 a and ontoI2C bus 241. The inter-integrated circuit ports can stop information from being communicated to an I2C bus section if a FRU coupled downstream of the inter-integrated circuit port is not authorized to receive said information. Thus, an entity (e.g., a company) or entities (e.g., a supplier and a purchaser) with control of devices (e.g.,FRUs 220 and 222) coupled to respective bus sections (e.g., 241 and 243) can communicate information to each other without illicit spoofing of the information by unauthorized or unapproved entities (e.g., a competitor) with control of a device (e.g., FRU 221) coupled to a separate bus section (e.g., 242). The unauthorized or unapproved entity can not receive the information illicitly because a present invention controller (e.g., 257 b) prevents the information from being communicated via a corresponding electrical connector (e.g., 259 b). - High-speed
internal bus 281 provides an internal communication path for components ofI2C router 250. It is appreciated that high-speedinternal bus 281 can be a parallel bus or any other high-speed bus compatible with various configurations of the invention. High-speedinternal bus 281 communicates information between each of theI2C ports external port 210. The communication speed of high-speedinternal bus 281 can be different than the external communication speed of the respective ports. Optionally,ports I2C router 250 simultaneously. - The size of a cache can be configured in accordance with a
variety I2C router 250 implementations. For example, ifI2C router 250 is used in a configuration utilizing an intelligent platform management interface (IPMI) protocol in which the IPMI limits packets to 32 bytes, the cache can be sized as a multiple of the packet size (e.g., 64 bytes, 96 bytes, etc.). Additional flexibility can be achieved in embodiments of the invention that utilize retry schemes and flow control schemes to help handle overflow conditions. For example, when a cache associated with a particular port reaches a predetermined capacity, a programmed overflow control routine can interrupt the bus and allow the port to dump its memory to prevent errors. - In one embodiment of the invention, the inter-integrated circuit ports of
I2C router 250 provide segmentation or separation of theI2C bus sections ports I2C bus sections FRU 220, 2221, and 223) coupled to the I2C bus sections. In one exemplary implementation, the electrical isolation of the I2C bus sections permit swapping of the FRUs without requiring changes to pull-up resistors (e.g., pull-up resistor 290) to accommodate a change in capacitance on the impacted I2C bus section. - Furthermore, by electrically isolating devices on an I2C bus, the invention beneficially provides each bus section coupled to
I2C router 250 greater flexibility with regard to the type and or number of devices coupled to a bus section before reaching a capacitance limit (e.g., 400 pF, I2C specification limits, etc.). Thus, overall capacitance limitations are more flexible than if a conventional I2C bus were used. Segmenting and electrically isolating the I2C bus sections also facilitates preservation of I2C functionality even when a device (e.g. a FRU) coupled to one of the I2C bus sections fails. If a device (e.g., FRU 221) coupled to one I2C bus section (e.g., I2C bus section 242) fails it does not preclude other devices (e.g.,FRU 220 and 222) coupled to other I2C bus sections (e.g., 241 and 243) from communicating with one another. - In one embodiment of the invention,
I2C router 250 is a packet-based router wherein several bytes are read on a port at the same time (e.g., waiting for an I2C STOP condition) and then transferred to another port inI2C router 250. Each port inI2C router 250 can recognize valid I2C communication protocol behavior on coupled I2C buses (e.g., 241, 242 and 243) andI2C router 250 can handle I2C hand shaking as appropriate. In one exemplary implementation,I2C router 250 can permit devices coupled to different I2C ports to communicate withI2C router 250 simultaneously, eliminating the traditional requirement that a device necessarily wait until the sections of an I2C bus are free. In one embodiment, the FRUs or devices coupled to the ports ofI2C router 250 operate normally as they would on a conventional I2C bus and the presence of theI2C router 250 is transparent to the FRUs or devices. - With reference still to FIG. 2, high-
speed port 210 inI2C router 250 can be coupled to external devices via high-speedexternal bus 240. It is appreciated that the high-speedexternal bus 240 can be a parallel port bus, a high speed I2C bus, or any other high-speed bus. Again,I2C router 250 optionally comprises a buffer for caching data received from another port (e.g.,I2C port external bus 240, thus allowing multiple devices coupled toI2C router 250 to communicate simultaneously. - In one embodiment of the invention, the
electrical connectors I2C buses controller 351 is a port management component coupled to the I2C bus couplers via high-speed internal bus 375 (not 243). The port management component manages data communication flow through the I2C bus couplers, including preventing said I2C connector from illicitly accessing said data. - It will be appreciated that the invention is readily adaptable to a variety of implementations. In one embodiment, a controller (e.g.,257 a) associated with a first port (e.g., 253 a) prevents information from a second port (e.g., 253 b) from being communicated via the first port to an electrical connector (e.g., 259 a) unless the information from the second port is addressed to the first port or an external device (e.g., FRU 220) coupled to the first port. In yet another embodiment, a controller (e.g., 257 a. 257 b, 257 n) also prevents an I2C port from sending data to another I2C port.
- Referring now to FIG. 3, a block diagram300 of an inter-integrated circuit (I2C)
router 350, in accordance with an embodiment of the invention, is shown. TheI2C router 350 is similar toI2C router 250 exceptI2C router 350 has asingle controller 351 instead of a controller in each of theports I2C router 350 comprises high-speed internal bus 375,controller 351, external high-speed port 310, andI2C ports controller 351, high-speedexternal port 310, andI2C ports I2C router 350 can include any number of ports (e.g., sixteen individual I2C ports).Controller 351 controls data communication flow through correspondingports - Factors such as cost may influence the configuration of a router, such that a port may have its own controller therein or each port may share a central controller, depending on cost objectives. In accordance with embodiments of the invention, a single unit, such as a field programmable gate array (FPGA), may be used control all of the ports in a router, wherein its general purpose input/output pins are used as I2C busses, thus creating I2C ports therein.
- The invention is readily adaptable for use in a variety of I2C bus configurations (e.g., a system compatible with the I2C specification provision for 127 addresses that can be written on a single I2C bus). In one embodiment of the invention I2C router can block communications to port addresses in both directions (e.g., receiving data and transmitting data) for any port on an I2C router. For example, suppose
port 253 a is only allowed to communicate withport 253 b andport 253 b is only allowed to communicate withport 253 a. Any packet fromport 253 a to any other address (e.g.,port 253 n) is not routed throughI2C router 250. Consequently, the number of I2C devices supported by theI2C router 250 is increased to 127 times the number of ports on the router. For example, ifI2C router 250 has 16 ports, the number of available addresses would be 2032, thus allowing up to 2032 devices to be coupled to a 16 port I2C router. - Referring now to FIG. 4, a flow diagram400 of a process for controlling communication on an inter-integrated circuit (I2C) router, in accordance with an embodiment of the invention, is shown. In accordance with an embodiment of the invention, the router controls communication between ports by limiting the ability of ports to spoof information.
- In
step 410 data for communication on an I2C bus connection interface is received. In embodiment of the invention, an I2C bus connection interface is associated with an I2C connector address. A determination is made if a destination address included in the data corresponds to the I2C connector address. For example, a received data packet is examined and an origin address and a destination address are identified in the header portion of the data packet. If the data corresponds to the I2C connector address an analysis is performed to analyze if the I2C connection interface is approved to communicate the data. In one exemplary implementation the data is received from a server blade via and I2C bus section. It is appreciated that data can be received on a first bus connection interface of an I2C router (e.g., from a high-speed external bus, an external I2C bus, etc.), wherein the data is destined for a second bus connection interface included in the I2C router. - In
step 420, the data is forwarded on the I2C bus connection interface if the I2C bus connection interface is approved for communicating the data. In one embodiment of the invention, the data is forwarded via an I2C bus section to a device (e.g., a FRU). - In step430, communication of the data on the I2C connection interface is prohibited if the I2C bus connector is not approved. Prohibiting communication on the I2C interface provides additional security for external components or devices (e.g.,
FRUs - In one embodiment of inter-integrated circuit (I2C)
communication control method 400 the I2C bus connection interface is utilized to divide an I2C bus into different sections. For example, the I2C bus connection interface is utilized to electrically isolate a section of an I2C bus. In one exemplary implementation in which the I2C bus connection interface is utilized to divide an I2C bus into different section, hot swapping of a component coupled to the I2C bus connection interface is permitted without changing pull-up resistance(e.g., pull-upresistor 290 from FIG. 2). - Referring now to FIG. 5, a block diagram of an inter-integrated circuit (I2C) router, in accordance with embodiments of the invention, is shown.
Router 570 comprises a high-speed port 510. High-speed port 510 interfaces the router with high-speedexternal bus 540. It is appreciated that high-speed bus 540 can be a high-speed I2C bus, a parallel bus, or any other high speed bus known in the art. In one embodiment in accordance with the invention, high-speed bus 540 is an 8 wire parallel bus. - High-
speed port 510 comprisescontrol logic 515 for controlling communications on high-speedinternal bus 575. Control logic is coupled to mask 530 whereinmask 530 provides control information to controllogic 515. High-speed port 510 also includes anoptional buffer 520 for buffering communications on high-speedinternal bus 575. As stated above, overflow routines and buffering schemes can be implemented bycontrol logic 515 to protect against errors resulting from data overflow. Optionally, high-speed port 510 comprises an error register and a corresponding system event log. The error register tracks errors on the router and the system event log organizes the errors and can provide reports. - Coupled to the high-speed
internal bus 575 is a plurality of I2C ports. For clarity, FIG. 5 illustrates twoI2C ports Port 550 comprisescontrol logic 516 and amask 531.Control logic 516 controls communication onport 550.Mask 531 provides control information to controllogic 516. It is appreciated thatmask 531 can be programmed using software or can be programmed manually with an I2C dual inline plug (DIP) switch.Mask 531 provides port addresses for whichport 550 can send data. If the port tries to send data to an address not allowed inmask 531, the data will not enterrouter 570. It is appreciated that each I2C port also includes an I2C controller for controlling I2C protocol. It is appreciated thatPort 560 is configured similarly toPort 550 whereinport 560 comprisescontrol logic 517,mask 532 and anoptional buffer 522. In accordance with embodiments of the invention, multiple ports onrouter 570 share central control logic and a central mask. In a centralized configuration, a single processor and a single mask can control communication on high-speed internal bus 574 - Coupled to
I2C port 550 andport 560 areSDA line 561,SCL line 571,SDA line 562 andSCL line 572, respectively, for providing a conventional I2C bus connection for a device to couple thereto.Port 550 is coupled toI2C bus 541 andport 560 is coupled toI2C bus 542. In accordance with an embodiment of the invention,I2C port 550 also includes an optional detection line for detecting the presence of a device coupled thereto. Furthermore, an optional reset line is coupled toport 550 for resetting a non-responsive device coupled to the port. A reset line can provide means to reset a device that is causing errors onrouter 570. In one embodiment of the invention, high-speed port 510 comprises debug logic wherein debug logic can toggle a reset line coupled to a device producing errors on the router to reset the non-responsive device. - In accordance with embodiments of the invention, ports coupled to
router 570, forexample ports router 570 at different speeds. For example, a device coupled toport 550 may only be capable of communicating at 100 kb/s whereinport 560 may have a device coupled thereto that is capable of communicating at 1.4 mb/s. Internal high-speed bus 575 provides bandwidth such that devices coupled to I2C ports onrouter 570 to communicate at high-speeds. - As stated above, the invention uses control logic and an address mask to provide security on an I2C bus by controlling communication on ports that segment an I2C bus. Beneficially, devices coupled to the ports on the
router 570 operate normally as they would on a conventional I2C bus and they are unaware of therouter 570. Advantageously, therouter 570 electrically segments an I2C bus from one device to another and beneficially, only packets aimed for a particular source on a particular port get forwarded to that port. - In addition to providing security on an I2C bus, the invention electrically isolates devices on an I2C bus to allow for hot swapping. As opposed to conventional I2C bus implementation wherein all devices share a single bus and are attached thereto, the invention advantageously electrically isolates devices coupled to the router. Thus, any failing device on the bus will not affect other devices on other ports. In addition, segmenting an I2C bus and electrically isolating devices on the I2C bus allows for hot swapping of devices on the I2C bus without requiring changes to pull-up resistors to accommodate for a change in capacitance on the bus. Furthermore, by electrically isolating devices on an I2C bus, the invention provides each port on the router to approach the 400 pF capacitance limit of I2C specification. Thus, each segment or port can require less stringent capacitance requirements than if a conventional I2C bus were used.
- With reference to FIG. 5, in overview, embodiments of the invention provide a process for securely controlling data communication through
I2C router 570. In one embodiment,I2C router 570 comprisesI2C port 550,I2C port 560 and high-speed port 510. It should be appreciated thatI2C router 570 may comprise any number of I2C ports, and is not limited by the embodiment illustrated in FIG. 5. For example,I2C router 570 may comprise sixteen I2C ports. Each I2C port is coupled to high-speedinternal bus 575. - In one embodiment, each I2C port comprises a controller (e.g.,
control logic 516 ofI2C port 550 andcontrol logic 517 of I2C port 560) and a mask register (e.g.,mask 531 ofI2C port 550 andmask 532 of I2C port 560). The controller is operable to control data communication through the I2C port based on control information provided by the mask register. In one embodiment, the mask register is stored within random access memory (e.g., RAM) of the controller (e.g., control logic 516). The control information designates data communication that is permitted to be transmitted through the I2C port. In one embodiment, the control information designates an I2C address to which data can be transmitted through the I2C port. - In one embodiment,
I2C router 570 comprises logical circuitry to compare an address to the control information. In one embodiment, the logical circuitry comprises an exclusive-OR (XOR) and AND logic circuit for comparing an address to the control information. The XOR and AND logic circuit may be comprised within control logic (e.g.,control logic - In one embodiment,
I2C router 570 comprises a port identification tag (PIT) register. Once an I2C port, or a set of I2C ports, is identified as being a recipient of a particular data communication, an access validation is indicated in the PIT register. In one embodiment, the PIT register is stored within RAM of the controller (e.g., control logic 516). It should be appreciated that the PIT register comprises at least as many bits as there are ports inI2C router 570. An access validation is indicated as a ‘1’ in the PIT register. - Referring now to FIG. 6A, a flow diagram of a computer implemented
process 600 for securely controlling data communication at an inter-integrated circuit (I2C) port in accordance with an embodiment of the invention, is shown. In one embodiment in accordance with the invention,process 600 is performed at an inter-integrated circuit port (e.g.,I2C port 550 of FIG. 5). Although specific blocks are disclosed inprocess 600, such blocks are exemplary. That is, the embodiments in accordance with the invention are well suited to performing various other blocks or variations of the blocks recited in FIG. 6A. - At
step 610 ofprocess 600, data is received at an I2C port of an I2C router (e.g.,I2C router 570 of FIG. 5), wherein the data comprises a destination address. In one embodiment, the data is a data packet comprising a header and a payload. The destination address is comprised within the header. To securely control data communication through the I2C port, and to prevent address spoofing, destination address must be validated at the I2C port. In one embodiment, the destination address is one byte. - At
step 620, control information of the I2C port is accessed. As described above, the control information designates whether data intended for a particular destination address is permitted to be transmitted through a particular I2C port. In one embodiment, the control information comprises an I2C address. In another embodiment, the control information comprises a range of I2C addresses. - In one embodiment, the control information is stored within a mask register (e.g.,
mask 531 of FIG. 5). In one embodiment, the mask register is stored within random access memory (e.g., RAM) of the controller (e.g., control logic 516). The mask register is set to allow communications through an I2C port or through a range of I2C ports. In one embodiment, the mask register of an I2C port is set to a single I2C address. In another embodiment, the mask register of an I2C port is set to a range of I2C address. - It should be appreciated that a mask register can comprise any number of bytes for storing any number of I2C addresses. In one embodiment,
mask 530 ofhigh speed port 510 is set to allow communications to address 20 h (hexadecimal notation). The mask registers of other I2C ports ofI2C router 570 may initially be set to a single I2C address. The mask registers can be managed to account for personalized settings for storing multiple I2C addresses. - In one embodiment, the mask register is one byte for storing a single I2C address. In another embodiment, the mask register is two bytes for storing a range of I2C addresses. FIG. 7A illustrates exemplary
mask register settings - The mask registers as depicted in FIG. 7A comprise two registers, a Do Not Care register and an Address register. The Address register is for indicating an I2C address. The Do Not Care register is for indicating the bits of the Address register are used for indicating an allowable destination address. Each ‘1’ in the Do Not Care register indicates a bit that is used and each ‘0’ in the Do Not Care register indicates a bit that is not used. The Do Not Care register and the Address register are operable to provide a single I2C address or a range of I2C addresses.
- Mask register setting700 illustrates an exemplary mask setting for allowing a destination address of 20h. As shown, the Do Not Care register is set to 1111 1110 (binary notation) and the Address register is set to 0010 0000b. Since every bit of the Do Not Care register except the last is set to 1, every bit of the Address register is used to determine the allowed destination address. Therefore, the only allowed addresses are 0010 000xb (20h and 21h). It should be appreciated that only the first seven bits of address space are used. The last bit of the byte determines whether the access is read/write.
- Mask register setting710 illustrates an exemplary mask setting for allowing destination addresses 20h-27h. As shown, the Do Not Care register is set to 1111 1000b (F8h) and the Address register is set to 0010 0000b. Since the last three bits if the Do Not Care register are set to 0, an allowed destination address may be 0010 0xxxb, where x may be a 1 or a 0. Therefore, the allowed addresses are in the range of 20h-27h. As with mask register setting 700, only the first seven bits of address space are used. The last bit of the byte determines whether the access is read/write.
- With reference to FIG. 6A, at
step 630, the destination address is compared to the control information. The control information indicates whether the destination address is allowed for transmission through the I2C port. - Referring now to FIG. 6B, a flow diagram of a
process 630 for comparing a destination address to control information, in accordance with an embodiment of the invention, is shown. In one embodiment in accordance with the invention,process 630 is performed at an inter-integrated circuit port (e.g.,I2C port 550 of FIG. 5). Although specific blocks are disclosed inprocess 630, such blocks are exemplary. That is, the embodiments in accordance with the invention are well suited to performing various other blocks or variations of the blocks recited in FIG. 6B. - At
step 632 ofprocess 630, a logical exclusive-OR (XOR) operation of the destination address and the Address register is performed. Each bit of the destination address and the Address register are compared. If the bits do not match, a ‘1’ is returned. Alternatively, if the bits do match, a ‘0’ is returned. - At
step 634, a logical AND operation of the result of the XOR operation and the Do Not Care register is performed. Each bit of the result of the XOR operation and the Do Not Care register are compared. If either of the bits is ‘0’, a ‘0’ is returned. Alternatively, if neither of the bits is ‘0’, a ‘1’ is returned. - At
step 636, it is determined whether the logical AND operation returns a value of zero (e.g., 00h or 0000 0000b). A value of zero indicates that the destination address matches the control information stored in the mask register. A match indicates that the destination address is acceptable for transmitting data through the I2C port. - FIG. 7B illustrates
exemplary comparisons comparisons -
Comparison 720 illustrates an exemplary comparison where the destination address is 24h. As described atstep 632 of FIG. 6B, a logical XOR operation is performed on the destination address (24h) and the Address register (20h), returning a result of 04h. A logical AND operation is then performed on the result of the XOR operation (04h) and the Do Not Care register (F8h), as described atstep 634 of FIG. 6B. The logical AND operation results in 00h, indicating a destination address that permits transmission through the I2C port. -
Comparison 730 illustrates an exemplary comparison where the destination address is 28h. A logical XOR operation performed on the destination address (28h) and the Address register (20h) returns a result of 08h. A logical AND operation performed on the result of the XOR operation (08h) and the Do Not Care register (F8h) returns a result of 08h. Because the result of the logical AND operation results in a value that is not 00h, the destination address is not permitted for transmission through the I2C port. - With reference to FIG. 6B, provided the logical AND operation returns a value of zero, as shown at
step 638, transmission through the I2C port is permitted.Process 630 then proceeds to step 640 ofprocess 600 of FIG. 6A. Alternatively, provided the logical AND operation returns a value other than zero, as shown atstep 639, transmission through the I2C port is not permitted.Process 630 then proceeds to step 640 ofprocess 600 of FIG. 6A. - At
step 640 of FIG. 6A, it is determined whether transmission through the I2C port is permitted. In one embodiment, the determination is based on the results of comparing the destination address to the control information as described atprocess 630 of FIG. 6B. It should be appreciated that any comparison may be used to compare the destination address to the control information, and the invention is not limited to the embodiment described atprocess 630 of FIG. 6B. For example, if the mask register is one byte for storing one address, an XOR operation can be performed on the mask register and the destination address, where a result of 00 h indicates an allowable destination address. - Provided transmission through the I2C port is permitted, as shown at
step 650, the data is transmitted through the I2C port.Process 600 then proceeds to step 670. Alternatively, provided transmission through the I2C port is not permitted, as shown atstep 660, the data is ignored by the I2C port. - At
step 670, it is indicated in a PIT register of the I2C router that the destination address corresponds to the I2C port. In one embodiment, a ‘1’ is indicated in the bit corresponding to the I2C port in the PIT register. - Accordingly, embodiments of the invention provide a process for securely controlling data communication at an I2C router. By using a mask register of an I2C port, it is possible to prevent unintended and/or unauthorized entities for accessing information communicated across a bus. Each port is assigned an address, and only information intended for a particular address can be transmitted through the port. Furthermore, it is not possible for a device to spoof the bus to deliberately receive unauthorized data due to the mask register.
- Method of Transmitting Data Through an I2C Router
- Referring again to FIG. 5, in overview, embodiments of the invention provides for a novel method of transmitting data through an
I2C router 570 that avoids buffer-overflow. In one embodiment of theinvention I2C router 570 comprises a first I2Csource port buffer 522, anI2C destination port 550 coupled to the firstI2C source buffer 522 via high speedinternal bus 575, and a second I2C source port buffer (not shown but similar tobuffers 521 and 522) also coupled toI2C destination port 550 via high speedinternal bus 575. Each buffer inrouter 570 is associated with a port in the router 570 (e.g., firstI2C source buffer 522 is associated with I2C port 560) and ports in the router are in communication with each other through an internal bus (e.g. high speed bus 575). - In one embodiment, data to be transmitted from the
first I2C port 560 to theI2C destination 550 port is received at the firstI2C port buffer 522. On receiving data in the first I2Csource port buffer 522, therouter 570 is operable to capture theI2C destination port 550 before the first I2Csource port buffer 522 has overflowed. On capturingdestination port 550, the router is operable to transmit data from the first I2Csource port buffer 522 to theI2C destination port 550, while restricting transmission from other source port buffers (not shown) todestination port 550. Thus with the invention,router 570 is operable as a router/hub for transmitting data between ports; similarly,router 570 is operable as a multi bus hub for secure transmission between ports. - For more detail description of this embodiment of the invention, FIG. 5 is now referenced in conjunction with
flowchart 800 of FIGS. 8A and 8B andflowchart 900 of FIG. 9. Although specific steps of this embodiment of the invention are disclosed inflowcharts flowcharts flowcharts flowcharts flowcharts flowcharts exemplary router 570 of FIG. 5. - Referring now to FIGS. 8A and 8B, a flow diagram800 of a method of transmitting data through an inter-integrated circuit (I2C) router (e.g.,
router 570 of FIG. 5), in accordance with one embodiment of the invention, is shown. The method starts atstep 801 whenrouter 570 becomes aware that a source port (e.g. source port 560) has received new data representing the beginning of a I2C data packet from a transmitting device (not shown) connected to sourceport 560 throughSDA 562 andSLC 572, for transmission to a destination port (e.g. destination port 550 on the router 570). - In
step 802, the data packet is received and read atsource port 560. Instep 803, the data is checked to determine whether, or if, the packet should be routed to a port another thanport 560. In an IC2 transmission, the first byte of a data packet contains the destination address of the packet. In checking whether the data packet should be routed to another port,router 570 looks at this byte to determine which, if any, destination ports is to receive the packet. - In
step 804, if the packet is not to be routed to another port, the packet is ignored and the method ends atstep 805. If instep 804router 570 has determined that the packet should be routed to another port (e.g. to port 550), then instep 806 the data is validated byrouter 570 for routing todestination port 550 by comparingrouter mask 532 data withdestination port 550 address. - In
step 807 if the data is not validated bymask 532, the data is ignored instep 808. If, however, instep 807, the data is validated for routing todestination port 550, therouter 570, instep 809, queues the data intobuffer 522 ofsource port 560 untilrouter 570 has received confirmation thatdestination port 550 is ready to receive incoming data fromsource port 560. - While the incoming data is being queued in
buffer 522, instep 810,router 570controls destination port 550 by using control lines (not shown) attached toport 550 and monitoring the necessary registers designated (not shown) fordestination port 550. - In
step 811, if it has been determined thatdestination port 550 I2C is currently available, thenrouter 570 sends the data fromsource port buffer 522 todestination port 550 via high speedinternal bus 575, where, atsteps buffer 522 to thedestination port 550 viahigh speed bus 575. - If, however, in
step 811 it is determined that thedestination port 550 is currently busy, the data continues to be stored insource port buffer 522 as it is being received at thesource port 560. Instep 812 of FIG. 8B,router 570 checks sourceport buffer 522 by polling to determine whether a predetermined point (e.g., the halfway point) has been reached insource port buffer 522. Alternatively, the source port buffer initiates an interrupt to the router when the buffer has reached its predetermined point. Instep 813,router 570 polls thedestination port 550 register for availability, and also negotiates control ofdestination port 550. As long assource port buffer 522 capacity is still below the predetermined point,router 570 continues to queue data intosource buffer 522 and continue to negotiate for control ofdestination port 550. - In
step 814, ifdestination port 550 remains busy for a long time after data has been received atsource port buffer 522, and thesource port buffer 522 capacity has reached the predetermined point (e.g. the halfway point),router 570 takes one of the following two actions to capturedestination port 550 beforebuffer 522 has overflowed: - a) In step816, the
router 570 holds other ports currently attempting to communicate withdestination port 550 busy, and transmit data fromfirst port buffer 522 until the data insource port buffer 522 has been transmitted todestination port 550. This is accomplished by therouter 570 asserting logic low on all SDA and SCL lines other thandestination port 550 SDA and SCL lines. - b) Alternatively, in
step 817,router 570 breaks intodestination port 550 by sending bytes of 0's to ports transmitting on high speedinternal bus 575. Under the I2C protocol, when a transmitting port recognizes that it is receiving bytes of 0's data on its own port, it halts its initial transmission and attempt to resend the transmission. In accordance with the invention, it is in between the time of the halt and the resending of the initial data at ports other thansource port 560 thatrouter 570 breaks into and win negotiation ofdestination port 550. It should be noted that whenrouter 570 initiates action to capturedestination port 550, if thedestination port 550 is not busy, therouter 570 obtains control ofdestination port 550 and starts sending out data to destination port 550 (e.g., at a rate as fast assource port buffer 522 is being filled). -
Router 570 continues with either of these two actions until it capturesdestination port 550 atsteps 816, 817 or untilsource port buffer 522 has overflowed its capacity. Upon capturingdestination port 550, therouter 570, insteps source port 560 todestination port 550 until the data atsource port 560 intended fordestination port 550 is transmitted. Ifrouter 570 fails to capturedestination port 550 andsource port buffer 522 overflows, the method terminates atstep 815 with the consequent loss of data atsource port 560. - In this embodiment of the invention, the likelihood that source
port buffer 522 overflows is reduced by designingsource buffer 522 to have a capacity of twice the size of a packet length, and by initiating capturing of thedestination port 550 before thesource port buffer 522 has overflowed, atstep 814, whensource port buffer 522 has reached a predetermined point (e.g., the half way point) of its capacity. Thus, for example if the packet length is 32 bytes and the capacity ofsource port buffer 522 is 64 bytes, the action to capturedestination port 550 commences whensource port buffer 522 is at 32 bytes. Under these conditions,source port buffer 522 should not overflow. It should be noted that other design ratios for packet length to buffer capacity can be used in this embodiment of the invention. - Referring now to FIG. 9, a flow diagram of an alternative method of transmitting data through an inter-integrated circuit (I2C) router, in accordance with an embodiment of the invention, is shown. The method of transmitting data through the
I2C router 900 comprises, instep 901, receiving data in the firstsource port buffer 522 ofrouter 570. Instep 902, therouter 570 is operable to capturedestination port 550 before the firstsource port buffer 522 has overflowed. Instep 903, therouter 570 is operable to transmit data from firstsource port buffer 522 to thedestination port 550 while restricting transmission from other source port buffers (not shown) to thedestination port 550. - For ease of explanation, the above embodiments describe the invention in terms of communication between a first and second I2C port. However, it is appreciated that the method of buffering data can comprise communications between an I2C port and an external high speed port and between an I2C port and a plurality of I2C ports.
- Method of Overflow Recovery of I2C Packets on an I2C Router
- Referring again to FIG. 5, in overview, embodiments of the invention also provide for a novel method of transmitting data through an
I2C router 570 wherein a source port buffer, e.g.,buffer 522 has overflowed. In this embodiment of theinvention router 570 comprises a firstI2C source buffer 522, anI2C destination port 550 coupled to the firstI2C source buffer 522 via high speedinternal bus 575, and a second I2C source port buffer (not shown but similar tobuffers 521 and 522) also coupled toI2C destination port 550 via high speedinternal bus 575. Each buffer e.g. 521, 522 inrouter 570 is associated with a port e.g. 550, 560 in therouter 570, e.g., firstI2C source buffer 522 is associated withI2C port 560; and, ports in the router are in communication with each other through an internal bus, e.g.high speed bus 575. - In an embodiment wherein data at a source port has overflowed the buffer, e.g. the first I2C
source port buffer 522 has overflowed,router 570 is operable to request resend of the overflowed data to first I2Csource port buffer 522. On requesting the resending of the data to sourcebuffer 522,router 570 is operable to hold other ports currently attempting to transmit to thedestination port 550, or presently transmitting to the destination port 50, busy. Alternatively, therouter 570 is operable to break into theI2C destination port 550. In either event, on succeeding in accessing the I2C destination port, the router is operable to resend the recovered data from thesource port buffer 522 to thedestination port 550 while restricting transmission from other source port buffers (not shown) todestination port 550. Thus with the invention,router 570 is operable as a router/hub for transmitting data between ports; similarly,router 570 is operable as a multi bus hub for secure transmission between ports. - FIG. 5 is now referenced in conjunction with
flowchart 1000 of FIGS. 10A and 10B andflowchart 1100 of FIG. 11 to describe in more detail this embodiment of the invention. Although specific steps of this embodiment of the invention are disclosed in theflowcharts flowchart flowchart flowchart flowchart flowcharts exemplary router 570 of FIGS. 3 and 5. - Referring now to FIGS. 10A and 10B, a flow diagram1000 of a method of transmitting data through an inter-integrated circuit (I2C)
router 570, in accordance with an embodiment of the invention, is shown. The method starts atstep 1001 when therouter 570 receives information that a source port (e.g. source port 560) has received new data representing the beginning of a packet from a transmitting device on thesource port 560, for transmission to a destination port, (e.g., destination port 550). - In
step 1002, the data is read and instep 1003, the data is checked to determine whether, or if, the packet should be routed to another port. In an IC2 transmission, the first byte of a packet contains the destination address of the packet. In checking whether the data should be routed, therouter 570 looks at this byte to determine which, if any, destination ports,e.g. port 550 is to receive the packet. - In
step 1004, if the packet is not to be routed, the packet is ignored and the method ends atstep 1005. If instep 1004 therouter 570 has determined that the packet should be routed, then instep 1006 the data is validated for transmission to thedestination port 550 by comparing therouter masking data 532 with the destination port address. - In
step 1007 if the data is not validated by themask 532, the data is ignored instep 1008. If, however, instep 1007, the data is validated for routing to adestination port 550, therouter 570, instep 1009, queues the data into thebuffer 522 atsource port 560 until therouter 570 has received confirmation that thedestination port 550 is ready to receive incoming data from thesource port 560. - While the data is being queued in the
buffer 522, instep 1010, therouter 570 controls thedestination port 550 by using control lines attached to the port (not shown) and monitoring the necessary registers designated for thedestination port 550. - In
step 1011, if it has been determined that thedestination port 550 is currently available and thatbuffer 522 has not overflowed, therouter 570 sends the data from thesource port buffer 522 to thedestination port 550, where, atsteps buffer 522 to thedestination port 550. - If, in
step 1011 and then instep 1012 of FIG. 10B it is determined that thedestination port 550 is currently busy but thebuffer 522 has not overflowed, the data continues to be stored in thebuffer 522 as it is being received, and therouter 570 continues to negotiate control of thedestination port 550. - If in
step 1012 it is determined that thebuffer 522 has overflowed, therouter 570, instep 1013 requests a resend of data from the source port I2C bus andre-start step 1002 for this data. Instep 1013, therouter 570 takes one of the following two actions to capture the destination port 550: - a) In step1014, the
router 570 holds ports currently attempting to communicate with thedestination port 550 busy until the initial data in thebuffer 522 has been transmitted to thedestination port 550. This is accomplished by therouter 570 asserting logic low on all SDA and SCL lines other than thedestination port 550. - b) Alternatively, in
step 1015, therouter 570 breaks into thedestination port 550 by sending bytes of 0's to the transmitting ports. Under the I2C protocol, when a transmitting port recognizes that it is receiving bytes of 0's data on its own port, it halts its initial transmission and attempt to resend the transmission. It is in between the time of the halt and the resending of the initial data that therouter 570 breaks into and win negotiation of thedestination port 550. It should be noted that when therouter 570 initiates action to capture thedestination port 550, if thedestination port 550 is not busy, therouter 570 controls thedestination port 550 and start sending out data at a rate as fast as thebuffer 522 is being filled. - The
router 570 continues with either of these two actions until it captures thedestination port 550 at which point instep 1016, therouter 570 feeds data from thesource port 560 to thedestination port 550 until the data is transmitted atstep 1017. As data is being fed to thedestination port 550, therouter 570 keeps other ports busy with stretched low on the SCL and SDA lines until transmission of the packets completes successfully. Thereafter, therouter 570 returns to normal operation. - Referring now to FIG. 11, a flow diagram1100 an alternative method of transmitting data through an inter-integrated circuit (I2C) router, in accordance with an embodiment of the invention, is shown. At
step 1101, overflowed data is resent to a first I2C source port buffer, the I2C router further comprising and a I2C destination port and a second I2C source port buffer. Atstep 1102, the overflowed data is received at the first I2C source port buffer. Atstep 1103, the I2C destination port is captured. Atstep 1104, data from the first I2C source port buffer is transmitted to the I2C destination port. - With the invention, a router is capable of functioning at speeds in the MHz range and the transmission from the source port to the destination port can be transparent under open, non-busy conditions. Further, with the invention, if a buffer overflows the data can be recovered for re-transmission to the destination port. Also, with the invention, since the router can track transmitted data and negotiate for a bus, the router can be operated as a multi-bus data hub with secure transmission to each port by limiting access to designated ports.
- For ease of explanation, the above embodiments describe the invention in terms of communication between a first and second I2C port. However, it is appreciated that the method of overflow recovery of I2C packets can comprise communications between an I2C port and an external high speed port and between an I2C port and a plurality of I2C ports.
- An Inter-Integrated Circuit Router Error Management System and Method
- FIG. 12 is block diagram of inter-integrated circuit (I2C) router
error management system 1200 in accordance with one embodiment of the present invention. I2C routererror management system 1200 comprisesinternal bus 1215,high speed port 1220,debug connector 1230 andI2 Cports Internal bus 1215 communicatively coupleshigh speed port 1220,debug connector 1230 andI2C ports 1250 and 1270 (e.g., similar to other internal buses of thepresent invention external port 1220 provides a high speed interface frominternal bus 1215 and high speed external bus 1221 (e.g., similar to high speedexternal ports Debug connector 1230 provides an interface from the components ofI2C router system 1200 to an external debugging mechanism.I2C ports external I2C buses -
I2C ports I2C port 1250 comprisescontrol logic 1251,mask 1252,buffer 1255, parallel toserial bus interface 1290,error register 1253 andsystem event log 1257.Control logic 1251 controls information flow through I2C port 1250 (e.g., similar tocontrol logic Mask 1252 provides control information to control logic 1251 (e.g., in accordance withmethod 600 and/or settings shown in FIGS. 7A and 7B, etc.).Buffer 1255 buffers information communicated viaI2C port 1250. In one exemplary implementation,buffer 1255 can buffer information in accordance withmethod serial bus interface 1290 provides an interface between internal parallel communications ofI2C port 1250 and external serial I2C bus communications.Error register 1253 tracks (e.g., stores) indications of errors (e.g., associated with a data flow of information throughI2C port 1250 and controlled control logic 1251). Event system log 1257 logs error information and statistics in a coordinated and correlated manner. -
I2C ports bus internal bus 1215 and vise versa. Presentinvention I2C bus 1213 includesSDA line 1201,SCL line 1202, presence detectline 1203 and resetline 1204. Presentinvention I2C bus 1217 includesSDA line 1207,SCL line 1208, presence detectline 1209 and resetline 1210. Presence detectlines bus lines 1660 and 1665).Reset lines busses - With continued reference to FIG. 12,
error register 1253 can capture error information in communication operations in a variety of different ways.Error register 1253 can utilizeflags error register 1253 are set to a predetermined logical value to indicate the existence of a type of error).Error register 1253 can include a failed port register or flag that is set if an I2C port fails. The register can also start a secondary state machine that executes a process to regain control of a failed port and monitor the port for recovery. The secondary state machine can be included in I2C router system 1200 (e.g., included in parallel to serial bus interface 1290) or can be independent of theI2C router system 1200. Remaining non-err ports ofI2C router system 1200 continue to pass data properly with no effect from the failed port or the secondary state machine. If a non-errI2C router system 1200 port attempts to communicate with an “isolated” failed port, a transmitting port is signaled that at least a portion of the communication is not completed. In one exemplary implementation,error register 1253 maintains an error count. For example,error register 1253 can track error counts by incrementing a value included in an error register flag each time an error event associated with the flag is detected. -
Error register 1253 is flexibly adaptable for implementation with a variety of error management policies directed to capturing indications of and recovering from numerous different errors. In one embodiment,error register 1253 can capture an indication of a failed port condition and participate in recovery from the error. For example, a failed port condition can be recognized by an indication of the number of times that parallel toserial bus interface 1290 attempts to reset its own ports in order to gain control ofSCL line 1202 andSDA line 1201. Alternatively, a failed port condition can be recognized by an indication of the number of times thatI2C router system 1200 attempts and fails to take control of an I2C port suspected of failing. Anerror register 1253 can also be utilized to capture and recover from a buffer problem (e.g., a buffer overflow). For example, an error register can be utilized to detect long transmission packets that exceed the buffering capabilities ofbuffer 1255. Present invention error management policies can also be directed to minimizing the likelihood of detrimental bus monopolization by a particular I2C port. -
I2C router system 1200 also includes error recovery mechanisms and features to facilitate recovery from an error condition. In one embodiment, when an I2C port is considered “lost” (e.g., a fatal error or errors have occurred on the I2C port), I2C router system can prevent data from passing to or from the lost I2C port. A failed I2C port is isolated from the data transfer portion of I2C router system 1200 (e.g., internal bus 1215). In one exemplary implementation,I2C router system 1200 includes a fault light which is activated to indicate an I2C router is not functioning properly (e.g., is “lost”). - With reference still to FIG. 12, parallel to
serial bus interface 1290 can be utilized to provide an indication of errors to errorregister 1253. In one exemplary implementation, time outregister 1291 can be utilized to provide indications of errors. A maximum time out value is set in time outregister 1291. The maximum time out value is the maximum time that an SCL line (e.g., SCL 1202) is held low before a reset is initiated (e.g., via reset line 1204). The SCL can be held low for a variety of reasons, including long negotiations, missing stop bit, and/or hung bus. The time out feature starts when the SCL goes low and is reset when the SCL line goes high. If the SCL line stays low for a time period equal to or longer that the time out valueI2C router system 1200 concludes a bus error has occurred. Parallel toserial bus interface 1290 loads an indication or status code instatus register 1293 that the SCL line is stuck low and generates an interrupt signal that attempts to releaseSCL line 1202 andSDA line 1201.Control logic 1251 can poll thestatus register 1293 and monitor the interrupt signal line to determine the error event occurred.Control logic 1252 can respond by incrementing an I2C bus error counter value by 1 and setting a port error LED to distinguish the failed port from a non-failed port. - Other I2C “health” indicators or error counters can be implemented utilizing other functions in parallel
serial bus interface 1290. In one exemplary implementation, when a missing stop bit occurs parallel toserial bus interface 1290 can load a status code that indicates a bus error occurrence during serial transfer. A bus error can be caused by the occurrence of start or stop condition at an incorrect (“illegal”) position in a format frame or an external interface interferes with parallel to serial bus interface. For example, a data bit or acknowledge bit is transmitted in an address byte. When an error occurs an interrupt is set (e.g., including setting a serial interrupt flag).Control logic 1251 can again poll thestatus register 1293 and increment a missing stop bit error count by 1 if a missing stop bit error occurred. - FIG. 13 is a flow chart of inter-integrated connected (I2C) router
error management method 1300, an inter-connected router error management method in accordance with one embodiment of the present invention. I2C routererror management method 1300 tracks, tabulates and recovers from error issues. Inter-integrated connected (I2C) router error management method increases the robustness and dependability of an I2C router system. - In
step 1310, communication activities on an I2C router are monitored. For example, the communications traffic flow characteristics of a port are examined. The amount of time an I2C port captures an internal bus can be examined or the amount of information communicated by an I2C port in one packet can be examined. In one exemplary implementation, buffer (e.g., buffer 1255) overflows are monitored. - Errors associated with the communications activities are captured in
step 1320. In one embodiment, errors identified instep 1310 are tracked. For example, a count of the particular types of error occurrences is maintained. In one exemplary implementation, error indications are logged in coordinated and correlated manner. Indications of errors can be communicated to a debugging system for extended debugging analysis. - In
step 1330 actions are executed to recover from the errors. In one embodiment of the present invention, the recovery action includes pausing the I2C communication activity associated with an error. For example, pausing communication of a long transmission packet via an affected port until the large packet can be sent directly to its destination port with the use of a buffer. In one exemplary implementation, the communication is paused until an internal I2C router bus can be captured by the source port of the long packet. Alternatively large packets are not allowed to be communicated via a source port and a source port attempting to communicate a large packet is disabled. Disabling a source port can also be utilized to prevent a run away process and/or denial of service attacks from preventing other ports from accessing an internal bus (e.g., 1215) and effectively bringing down the ports. In one embodiment of the present invention, an error recovery action includes initiating a reset (e.g., resetting a device coupled to an I2C port). The present invention is also flexibly adaptable to reset multiple I2C ports and facilitate implementation an overall I2C communication network error monitoring and recovery system. - An Inter-Integrated Circuit Router for Supporting Independent Transmission Rates
- Referring now to FIG. 14, a data flow diagram of an inter-integrated circuit (I2C) router for supporting independent transmission rates, in accordance with an embodiment of the invention, is shown. For purposes of clarity in describing the present embodiment,
I2C router 1400 is used to illustrate an I2C router capable of supporting coupled devices having independent transmission rates. However, it should be appreciated that other embodiments of invention, such as those described inI2C router 570 of FIG. 5, also are be operable to provide independent transmission rates for coupled devices, and that support of independent transmission rates is not exclusive to the embodiment described in FIG. 14. -
I2C router 1400 comprises internal bus 1402 operable to transmit data at afirst transmission rate 1410. In one embodiment, internal bus 1402 is a high-speed bus. In one embodiment,first transmission rate 1410 is substantially 1.4 megahertz (MHz). Internal bus 1402 comprises ports configured for coupling to electrically isolated external buses. An electrically isolated bus (e.g.,external I2C bus 1424 and external bus 1434) can run independently of other buses the electrically isolated port is coupled to through the port. -
I2C router 1400 comprisesI2C port 1420 coupled to internal bus 1402.I2C port 1420 comprises abuffer 1422 and is coupled toexternal I2C bus 1424.External I2C bus 1424 is electrically isolated from internal bus 1402.External I2C bus 1424 is operable to transmit data atsecond transmission rate 1426. In one embodiment,second transmission rate 1426 is substantially 100 kilohertz (kHz). In another embodiment,second transmission rate 1426 is substantially 400 kHz.External I2C bus 1424 is configured for coupling to external devices or components (e.g.,FRUs -
Buffer 1422 is operable to buffer data transmitted betweeninternal bus 1410 andexternal I2C bus 1424 whenfirst transmission rate 1410 is different thansecond transmission rate 1426.Buffer 1422 comprises a data cache for temporarily storing data as it is transmitted betweeninternal bus 1410 andexternal I2C bus 1424. In one embodiment, providedfirst transmission rate 1410 is greater thansecond transmission rate 1424,buffer 1422 is operable to receive data from internal bus 1402 atfirst transmission rate 1410, buffer the data by storing the data it is unable to transmit due to the disparity in transmission rates, and transmit data acrossexternal I2C bus 1424 atsecond transmission rate 1426. In effect,buffer 1422 is operable to slow down data transmission such that a slower link can receive data from a faster link. As described above, thesize buffer 1422 can be configured in accordance with avariety I2C router 1400 implementations. For example, ifI2C router 1400 is used in a configuration utilizing IPMI protocol, the cache can be sized as multiples of a packet size of 32 bytes (e.g., 64 bytes, 96 bytes, etc.). - In one embodiment, provided
first transmission rate 1410 is greater thansecond transmission rate 1424,buffer 1422 is operable to cache data fromexternal I2C bus 1424 atsecond transmission rate 1426 and transmit data in bursts across internal bus 1402 atfirst transmission rate 1410. For example, data is received atI2C port 1420 fromexternal bus 1424.Buffer 1422 caches the data. Once enough data has been cached, the cached data is transmitted in bursts across internal bus 1402. Effectively,buffer 1422 operates to achieve higher throughput by receiving data from a slower link, caching the data, and pumping the data out the faster link at a faster rate. By bursting the data,faster bus 1410 can be freed to burst other data independent ofbus 1424. - In one embodiment,
I2C router 1400 comprisesport 1430 coupled to internal bus 1402.Port 1430 comprisesbuffer 1432 and is coupled to external bus 1434. External bus 1434 is electrically isolated from internal bus 1402. External bus 1434 is operable to transmit data atthird transmission rate 1436. It should be appreciated thatbuffer 1432 operates in a manner similar tobuffer 1422, and is operable to buffer data whenfirst transmission rate 1410 is different thanthird transmission rate 1436. - In one embodiment,
port 1430 is a second I2C port (e.g.,port 560 of FIG. 5) and external bus 1434 is an I2C bus (e.g.,I2C bus 542 of FIG. 5). In another embodiment,port 1430 is a high-speed port (e.g., high-speed port 510 of FIG. 5) and external bus 1434 is an external high-speed bus (e.g., high-speedexternal bus 540 of FIG. 5). - In one embodiment,
first transmission rate 1410 is at least as fast as the faster ofsecond transmission rate 1426 andthird transmission rate 1436. In one embodiment, internal bus 1402 is operable to transmit data at transmission rates less than first transmission rate. In the present embodiment, it is not necessary to cache data received atport 1420 fromexternal I2C bus 1424 and transmit the data in bursts atfirst transmission rate 1410.Port 1420 can be operable to transmit data acrossinternal bus 1410 at second transmission rate.Buffer 1432 is operable to receive data from internal bus 1402 atsecond transmission rate 1426 and transmit data fromport 1430 to external bus 1434 atthird transmission rate 1436. - In another embodiment,
buffer 1422 is operable cache data received fromexternal I2C port 1424 atsecond transmission rate 1426 and transmit the data in bursts across internal bus 1402 atfirst transmission rate 1410.Buffer 1432 is operable to receive the data from internal bus 1402 at first-transmission rate 1410 and transmit the data to external bus 1434 atthird transmission rate 1436.Buffer 1432 is operable to cache data received from external bus 1434 atthird transmission rate 1436 and transmit the data in bursts across internal bus 1402 atfirst transmission rate 1410. - Referring now to FIGS.15A-C, flow
diagrams illustrating processes I2C router 1400 of FIG. 4). Although specific blocks are disclosed inprocess 1500, such blocks are exemplary. That is, the embodiments in accordance with the invention are well suited to performing various other blocks or variations of the blocks recited in FIG. 15A. For purposes of clarity, processes 1500, 1520 and 1530 will be described in conjunction withI2C router 1400 of FIG. 14. However, it should be appreciated that the described embodiments of the present invention may be implemented on other I2C routers (e.g.,I2C router 570 of FIG. 5). - At
step 1502 ofprocess 1500, data is received atI2C port 1420 over a bus (e.g., internal bus 1402) atfirst transmission rate 1410. Atstep 1504, providedfirst transmission rate 1410 is faster thansecond transmission rate 1426 ofexternal I2C bus 1424 coupled toI2C port 1420, the data is buffered atbuffer 1422. Atstep 1506, the data is transmitted acrossexternal I2C bus 1424 atsecond transmission rate 1426. - At
step 1508, second data is received atI2C port 1420 overexternal I2C bus 1424 atsecond transmission rate 1426. Atstep 1510, providedfirst transmission rate 1410 is faster thansecond transmission rate 1426, the data is cached atbuffer 1422. Atstep 1512, the data is transmitted in bursts across internal bus 1402 atfirst transmission rate 1410. - With reference to FIG. 15B,
process 1520 for buffering second data at a second I2C port is described in accordance with an embodiment of the invention. In the present embodiment,port 1430 is a second I2C port and external bus 1434 is a second external I2C bus. - At
step 1522 ofprocess 1520, the second data is received at the second I2C port over internal bus 1402 atfirst transmission rate 1410. Atstep 1524, providedfirst transmission rate 1410 is faster thanthird transmission rate 1436 of the second external I2C bus, the second data is buffered atbuffer 1432. Atstep 1526, the second data is transmitted across the second external I2C bus atthird transmission rate 1436. - With reference to FIG. 15C,
process 1530 for buffering second data at a high-speed port is described in accordance with an embodiment of the invention. In the present embodiment,port 1430 is a high-speed port and external bus 1434 is an external high-speed bus. - At
step 1532 ofprocess 1530, the second data is received at the high-speed port over internal bus 1402 atfirst transmission rate 1410. Atstep 1534, providedfirst transmission rate 1410 is faster thanthird transmission rate 1436 of the external high-speed bus, the second data is buffered atbuffer 1432. Atstep 1536, the second data is transmitted across the external high-speed bus atthird transmission rate 1436. - Accordingly, various embodiments of the present invention provide an I2C router for supporting independent transmission rates. The I2C router can comprise a high-speed internal bus coupled to a plurality of I2C ports and a high-speed port. Each bus coupled the I2C ports and the high-speed port is electrically isolated, and can operate at different speeds. By buffering data at each of the I2C ports, as well as caching the data and pumping it out at fast speeds, a single high-speed bus can be used in the I2C router to provide greater throughput. Furthermore, by having one high-speed port and a plurality of I2C ports, cost can be optimized for use without compromising performance.
- System and Method for Presence Detect and Reset of Devices
- Embodiments of the invention provide for detecting a device (e.g., field replaceable unit) coupled to an inter-integrated circuit (I2C) router and/or resetting the device. Referring now to FIG. 16, a block diagram of an
I2C router 1605, in accordance with an embodiment of the invention, is shown. As depicted in FIG. 16, theI2C router 1605 comprises aninternal bus 1610, a plurality of bus ports 1615-1630, and acontrol logic 1640. Theinternal bus 1610 communicatively couples the plurality of bus ports 1615-1630 and thecontrol logic 1640. The plurality of bus ports 1615-1630 comprise a high-speedexternal bus port 1615 and a plurality of I2C bus ports 1620-1630 (e.g., sixteen I2C bus port interfaces). - The
internal bus 1610 comprises a bi-directional high-speed communication path. In one embodiment, the high-speed communication path comprises a bi-directional parallel bus (e.g., speedway), or the like. In one implementation, the bi-directional parallel bus comprises eight data lines, two address lines, and five control lines (e.g., read, write, enable, interrupt, and reset). The bandwidth of theinternal bus 1610 is sufficient to enable high-speed communication between devices coupled to theI2C router 1605. - The
control logic 1640 implements the logic for controlling communication on the plurality of bus ports 1615-1630, detecting a device coupled to one or more of the I2C bus ports 1620-1630, and/or resetting a device on one or more of the I2C bus ports 1620-1630. Thecontrol logic 1640 may be centralized within theI2C router 1605 or distributed among each of the plurality of bus ports 1615-1630. - The high-speed
external bus port 1615 comprises an interface for controlling communication between theI2C router 1605 and a high-speed external bus. The high-speed external bus comprises a communication path between a coupled external device and theI2C router 1605. The high-speed external bus may be a parallel bus, a high-speed I2C bus (e.g., 1.4 MHz), or the like. Each I2C bus port 1620-1630 comprises an interface for controlling communication between the I2C router and a corresponding sectioned (e.g., segregated) I2C bus. The I2C buses each comprise a communication path between one or more coupled device and theI2C router 1605. TheI2C router 1605 receives one or more data packets on any one of the plurality of bus ports 1620-1630 and forwards the packets to the correct destination bus port 1615-1630. Accordingly, theI2C router 1605 provides for communication between a device coupled to the high-speed external bus and devices coupled to any one of the I2C buses, and/or a device coupled to a first one of the I2C buses and another device coupled to any other of the I2C buses. - Each I2C bus port1620-1630 comprises a serial data line (SDA) 1650 and a serial clock line (SCL) 1655 that provide for bi-directional communication. Each
I2C bus port 1620 further comprises apresence line 1660 and areset line 1665. In one embodiment, thepresence line 1665 is active low into thebus port 1620 and thereset line 1665 is active high out of thebus port 1620. More specifically, thepresence line 1660 is biased at a high level (e.g., a pull-up resistor to an appropriate supply voltage) by theI2C bus port 1620 or thecontrol logic 1640. If a device is coupled to theI2C bus port 1620 and the device is functioning, the device drives thepresence line 1660 low. If a device is not coupled to theI2C bus port 1620 or is not functioning, thepresence line 1660 remains biased high. Thus, theI2C router 1605 is readily able to determine the presence of an operational device coupled to a givenI2C bus port 1620 as a function of the state of thecorresponding presence line 1660. - Similarly, the
reset line 1665 is biased at a low level (e.g., a pull-down resistor to ground) by theI2C bus port 1620. If a reset condition is determined by the I2C router, theI2C bus port 1620 or thecontrol logic 1640 drives thereset line 1665 high for a desired (e.g., pre-defined) period of time. Upon sensing the high state of thereset line 1665, a device coupled to theI2C bus port 1620 will perform a reset process. - Referring now to FIG. 17A, a flow diagram of a method of detecting the presence of a device (e.g., field replaceable unit) coupled to an inter-integrated circuit (I2C) router, in accordance with an embodiment of the invention, is shown. As depicted in FIG. 17A, the method comprises biasing the presence line at a first state, at1710. In one implementation, the presence line is biased by pulling the presence line high (e.g., a pull-up resistor coupled to an appropriate power supply).
- At1715, the presence line is driven to a second state by a functioning device coupled to the presence line. In one implementation, the functional device drives the presence line low. Alternatively at 1720, if a device is not connected to the presence line or the device is not functioning, the presence line remains at the first state.
- At1725, the I2C router senses the presence line. If the presence line is at the second state, the I2C router determines that a device is present and/or functional, at 1730. If the presence line is at the first state, the I2C router determines that a device is not connected or that the device is not functional, at 1735. Upon determining if a device is or is not present and/or function, the method returns to 1725.
- Referring now to FIG. 17B, a flow diagram of a method of resetting a device (e.g., field replaceable unit) coupled to an inter-integrated circuit (I2C) router, in accordance with an embodiment of the invention, is shown. As depicted in FIG. 17B, the method comprises biasing the reset line at a first state, at1750. In one implementation, the reset line is biased by pulling the reset line low (e.g., a pull-down resistor coupled to a ground).
- At1755, the I2C router determines if a reset condition exists. In one implementation, a reset condition comprises a reported error as described above with respect to FIGS. 13 and 14.
- At1760, the reset line is driven to a second state for a desired period (e.g., pre-defined) of time if a reset condition exists. In one implementation, the I2C router drives the reset line high if a reset condition exists.
- At1765, a device coupled to the reset line executes a reset process when the reset line is driven low. If no reset condition is determined or after the reset line is driven low in response to a reset condition the method returns to step 1755.
- In another embodiment the function of the presence and reset are implemented utilizing a single line. Furthermore, embodiments of the invention may implement the method of detecting the presence of a device only, the method of resetting a device upon determination of a reset condition only, or both the method of detecting the presence of a device and resetting the same device or another device.
- Accordingly, embodiments of the invention are advantageous in that a device that is not functioning can be reset. Embodiments of the invention are also advantageous in that a device which has taken over control of the I2C bus can be reset. Upon resetting the device, the I2C bus is released. Embodiments of the invention are also advantageous in that a non-responsive device can be detected. The ability to detect and/or reset a device coupled to the I2C router readily improves the robustness of the system.
- System and Method for Analysis of I2C Router
- Embodiments of the invention provide for readily analyzing and debugging an inter-integrated circuit (I2C) router. Referring to FIG. 18, a block diagram of an
I2C router 1805, in accordance with an embodiment of the invention, is shown. As depicted in FIG. 18, theI2C router 1805 comprises aninternal bus 1810, a plurality of bus ports 1815-1830, acontrol logic 1840, and adebug connector 1865. Theinternal bus 1810 communicatively couples the plurality of bus ports 1815-1830 and thecontrol logic 1840. The plurality of bus ports 1815-1830 comprise a high-speedexternal bus port 1815 and a plurality of I2C bus ports 1820-1830 (e.g., sixteen I2C bus ports). - The
internal bus 1810 comprises a bi-direction high-speed communication path and a plurality of debug lines. In one embodiment, the high-speed communication path comprises a bi-direction parallel bus (e.g., speedway), or the like. In one implementation, the bi-direction parallel bus comprises eight data lines, two address lines, five control lines (e.g., read, write, enable, interrupt and reset) and four general purpose input/output lines. In one embodiment, the general purpose input/output lines are designated as debug lines 1880 (e.g., debug (0:3)). The bandwidth of theinternal bus 1810 is sufficient to enable high-speed communication between devices (e.g., field replaceable units) coupled to theI2C router 1805. - The
control logic 1840 implements the logic for controlling communication on the plurality of port interfaces 1815-1830. Thecontrol logic 1840 may be centralized within theI2C router 1805 or distributed among each of the plurality of bus ports 1815-1830. - The high-speed external
bus port interface 1815 comprises an interface for controlling communication between theI2C router 1805 and a high-speedexternal bus 1845. The high-speedexternal bus 1845 comprises a communication path between an coupled external device and theI2C router 1805. The high-speedexternal bus 1845 may be a parallel bus, a high-speed I2C bus (e.g., 1.4 MHz), or the like. EachI2C bus port 1820 comprises an interface for controlling communication between theI2C router 1805 and a corresponding sectioned (e.g., segmented) I2C bus 1855-1860. Each I2C bus port 1820-1830 comprises a serial data line (SDA) 1860 and a serial clock lines (S DL) 1865 that provide for bi-directional communication. The I2C buses each comprise a communication path between one or more coupled devices and theI2C router 1805. TheI2C router 1805 receives one or more packets on any one of the plurality of bus ports 1815-1830 and forwards the packets to the correct destination bus port 1815-1830. Accordingly, theI2C router 1805 provides for communication between a device coupled to the high-speedexternal bus 1815 and devices coupled to any one of the I2C buses 1820-1830, and/or a device coupled to a first one of the I2C buses 1820-1830 and another device coupled to any other of the I2C buses 1820-1830. - The
debug connector 1865 provides for coupling alogic analyzer 1885 or the like, to one or more of a plurality of analysis lines 1870-1880. Thedebug connector 1865 may also provide for coupling thelogic analyzer 1885 to theinternal bus 1810. The plurality of analysis lines 1870-1880 comprise the plurality of debug lines (e.g., debug (0:3)) 1880, one or more controllogic analysis lines 1870, and/or one or more high-speed external bus port analysis lines 1875. Thus, thedebug connector 1865 allows for the trapping and analysis, in a standard manner, of traffic passing through theI2C router 1805 to any bus port 1815-1830. In addition, signals on the analysis lines 1870-1880 may be generated by debug firmware for setting breakpoints and traps. TheI2C router 1805, comprising the internal bus (e.g., parallel bus) 1810 anddebug connector 1865, readily allow isolation of traffic to and/or from an individual bus port 1815-1830 and ready analysis of data on a byte by byte bases. Therefore, generation and control of complex state conditions necessary for analysis of serial signals are not necessary. - Referring now to FIG. 19, a flow diagram of a method of analyzing traffic in an inter-integrated (I2C) router, in accordance with an embodiment of the invention, is shown. As depicted in FIG. 19, the method comprises transmitting a first set of signals on a plurality of debug lines coupled to one or more bus ports, at1910. Transmitting comprises sending and/or receiving signals. In an exemplary implementation, one or more signals are transmitted on the debug lines to set the state of one or more elements of one or more bus ports and/or to determine the state of one or more elements of one or more of the bus ports.
- The method may further comprise transmitting a second set of signals on one or more control logic analysis lines, at1915. In an exemplary implementation, one or more signals are transmitted on the one or more control logic analysis lines to set the state of one or more elements of the control logic and/or to determine the state of one or more elements of the control logic. The method may further comprise transmitting a third set of signals on one or more bus port analysis lines, at 1920. In an exemplary implementation, one or more signals are transmitted on the one or more bus port analysis lines to set the state of one or more elements of the bus ports and/or to determine the state of one or more elements of the bus ports.
- The method may further comprise transmitting data packets on one or more bus ports, at1925. The bus ports may comprise a high-speed bus port and/or a plurality of I2C bus ports. Furthermore, one or more of elements 1910-1925 of the method may be performed individually, in combination with each other, sequentially, in parallel with each other, and/or any combination thereof.
- Accordingly, embodiments of the invention advantageously provide for readily analyzing and debugging communications passing through I2C routers. Embodiments of the invention advantageously allow for setting breakpoints and traps. Embodiments of the invention also advantageously allow readily detecting destination and source addresses of data packet traffic.
- The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.
Claims (20)
1. An inter-integrated circuit router error management system comprising:
a) a high-speed internal bus for communicating information;
b) an inter-integrated circuit port coupled to said high-speed internal bus, said inter-integrated circuit port provides an interface for communicating information with an inter-integrated circuit bus segment;
c) a high-speed external port coupled to said high-speed internal bus, said high-speed external port provides an interface to an external high-speed bus; and
d) an error register coupled to said inter-integrated circuit port, said error register captures errors in communication operations.
2. The inter-integrated circuit router error management system as described in claim 1 wherein said error register includes a failed port register that is set if said inter-integrated circuit port fails.
3. The inter-integrated circuit router error management system as described in claim 2 wherein a failed port condition is recognized by an indication of a number of times that a parallel to serial bus interface attempts to reset ports of said parallel to serial bus interface in order to gain control of a serial data line.
4. The inter-integrated circuit router error management system as described in claim 1 wherein said error register maintains an error count.
5. The inter-integrated circuit router error management system as described in claim 1 wherein said error register is utilized to capture and recover from a buffer problem.
6. The inter-integrated circuit router error management system as described in claim 1 wherein said inter-integrated circuit port is isolated from the said high speed internal bus.
7. The inter-integrated circuit router error management system as described in claim 1 further comprising a fault light which is activated to indicate an inter-integrated circuit router is not functioning properly.
8. An inter-integrated circuit router error management method comprising:
monitoring communication activities on an inter-integrated circuit router;
capturing errors associated with said communications activities; and
executing actions to recover from said errors.
9. An inter-integrated circuit router error management method of claim 8 further comprising examining communications traffic flow characteristics of a port.
10. An inter-integrated circuit router error management method of claim 8 wherein the time an inter-integrated circuit port captures an internal bus is examined.
11. An inter-integrated circuit router error management method of claim 8 wherein buffer overflows are monitored.
12. An inter-integrated circuit router error management method of claim 8 further comprising maintaining a count of a particular type of error occurrence.
13. An inter-integrated circuit router error management method of claim 8 further comprising logging error indications in a coordinated and correlated manner.
14. An inter-integrated circuit router error management method of claim 8 further comprising communicating indications of errors to a debugging system for extended debugging analysis.
15. An inter-integrated circuit router error management method of claim 8 further comprising pausing an inter-integrated circuit communication activity associated with an error.
16. An inter-integrated circuit router error management method of claim 8 further comprising disabling a source port to prevent a run away process and denial of service attacks from preventing other ports from accessing an internal bus.
17. An inter-integrated circuit router error management port comprising:
an electrical connector for communicatively coupling to an inter-integrated circuit bus;
a controller coupled to said electrical connector, said controller controls data communication flow through said electrical connector, including preventing said electrical connector from unauthorized access to said data; and
an error register coupled to said controller, said error register tracks indications of errors associated with said data communication flow.
18. The inter-integrated circuit router error management port as described in claim 17 wherein said error register utilizes a flag to capture indications of an error and particular bits included in said error register are set to a predetermined logical value to indicate existence of a type of error.
19. The inter-integrated circuit router management error port as described in claim 17 wherein a maximum time out value is set in a time out register.
20. The inter-integrated circuit port as described in claim 1 wherein an inter-integrated circuit bus is electrically isolated.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/461,209 US20040255193A1 (en) | 2003-06-12 | 2003-06-12 | Inter integrated circuit router error management system and method |
JP2004165341A JP2005006306A (en) | 2003-06-12 | 2004-06-03 | Inter-integrated circuit router error management system and method |
GB0412762A GB2403039B (en) | 2003-06-12 | 2004-06-08 | An inter integrated circuit router error management system and method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/461,209 US20040255193A1 (en) | 2003-06-12 | 2003-06-12 | Inter integrated circuit router error management system and method |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040255193A1 true US20040255193A1 (en) | 2004-12-16 |
Family
ID=32713626
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/461,209 Abandoned US20040255193A1 (en) | 2003-06-12 | 2003-06-12 | Inter integrated circuit router error management system and method |
Country Status (3)
Country | Link |
---|---|
US (1) | US20040255193A1 (en) |
JP (1) | JP2005006306A (en) |
GB (1) | GB2403039B (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060053331A1 (en) * | 2004-09-03 | 2006-03-09 | Chou Norman C | Slave device having independent error recovery |
US8902554B1 (en) | 2013-06-12 | 2014-12-02 | Cypress Semiconductor Corporation | Over-voltage tolerant circuit and method |
US20150212965A1 (en) * | 2014-01-28 | 2015-07-30 | Siemens Schweiz Ag | Combination of buses for a hazard management system, hazard management system, and method of operating the hazard management system |
CN105068965A (en) * | 2015-08-13 | 2015-11-18 | 上海斐讯数据通信技术有限公司 | Inter-integrated circuit (I2C) bus based NAND Flash storage method and system |
US20230168980A1 (en) * | 2021-12-01 | 2023-06-01 | Hitachi, Ltd. | Storage system |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101103559B (en) | 2005-01-13 | 2011-09-07 | 日本电气株式会社 | Mobile communication terminal and method of accomplishing tpc in mobile communication terminal |
KR100908766B1 (en) * | 2008-12-03 | 2009-07-22 | 김태수 | A cosmetics case of rotate pressing out type with simple structure |
WO2010097831A1 (en) * | 2009-02-24 | 2010-09-02 | 富士通テレコムネットワークス株式会社 | I2c monitor sequential read data storage device |
US11422876B2 (en) * | 2019-08-02 | 2022-08-23 | Microsoft Technology Licensing, Llc | Systems and methods for monitoring and responding to bus bit error ratio events |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4825438A (en) * | 1982-03-08 | 1989-04-25 | Unisys Corporation | Bus error detection employing parity verification |
US5243699A (en) * | 1991-12-06 | 1993-09-07 | Maspar Computer Corporation | Input/output system for parallel processing arrays |
US6105146A (en) * | 1996-12-31 | 2000-08-15 | Compaq Computer Corp. | PCI hot spare capability for failed components |
US6233635B1 (en) * | 1997-07-10 | 2001-05-15 | Samsung Electronics Co., Ltd. | Diagnostic/control system using a multi-level I2C bus |
US20020042896A1 (en) * | 1997-05-13 | 2002-04-11 | Johnson Karl S. | Diagnostic and managing distributed processor system |
US20020108076A1 (en) * | 2001-02-08 | 2002-08-08 | International Business Machines Corporation | Method for isolating an I2C bus fault using self bus switching device |
US6510522B1 (en) * | 1998-11-20 | 2003-01-21 | Compaq Information Technologies Group, L.P. | Apparatus and method for providing access security to a device coupled upon a two-wire bidirectional bus |
US6526525B1 (en) * | 1999-08-27 | 2003-02-25 | Via Technologies, Inc. | PCI debugging device, method and system |
US6629172B1 (en) * | 1998-12-14 | 2003-09-30 | Micron Technology, Inc. | Multi-chip addressing for the I2C bus |
US20040036808A1 (en) * | 2000-12-20 | 2004-02-26 | Lendaro Jeffrey Basil | I2c bus control for isolating selected ic's for fast I2c bus communication |
US6728908B1 (en) * | 1999-11-18 | 2004-04-27 | California Institute Of Technology | I2C bus protocol controller with fault tolerance |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6145036A (en) * | 1998-09-30 | 2000-11-07 | International Business Machines Corp. | Polling of failed devices on an I2 C bus |
-
2003
- 2003-06-12 US US10/461,209 patent/US20040255193A1/en not_active Abandoned
-
2004
- 2004-06-03 JP JP2004165341A patent/JP2005006306A/en active Pending
- 2004-06-08 GB GB0412762A patent/GB2403039B/en not_active Expired - Fee Related
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4825438A (en) * | 1982-03-08 | 1989-04-25 | Unisys Corporation | Bus error detection employing parity verification |
US5243699A (en) * | 1991-12-06 | 1993-09-07 | Maspar Computer Corporation | Input/output system for parallel processing arrays |
US6105146A (en) * | 1996-12-31 | 2000-08-15 | Compaq Computer Corp. | PCI hot spare capability for failed components |
US20020042896A1 (en) * | 1997-05-13 | 2002-04-11 | Johnson Karl S. | Diagnostic and managing distributed processor system |
US6233635B1 (en) * | 1997-07-10 | 2001-05-15 | Samsung Electronics Co., Ltd. | Diagnostic/control system using a multi-level I2C bus |
US6510522B1 (en) * | 1998-11-20 | 2003-01-21 | Compaq Information Technologies Group, L.P. | Apparatus and method for providing access security to a device coupled upon a two-wire bidirectional bus |
US6629172B1 (en) * | 1998-12-14 | 2003-09-30 | Micron Technology, Inc. | Multi-chip addressing for the I2C bus |
US6526525B1 (en) * | 1999-08-27 | 2003-02-25 | Via Technologies, Inc. | PCI debugging device, method and system |
US6728908B1 (en) * | 1999-11-18 | 2004-04-27 | California Institute Of Technology | I2C bus protocol controller with fault tolerance |
US20040036808A1 (en) * | 2000-12-20 | 2004-02-26 | Lendaro Jeffrey Basil | I2c bus control for isolating selected ic's for fast I2c bus communication |
US20020108076A1 (en) * | 2001-02-08 | 2002-08-08 | International Business Machines Corporation | Method for isolating an I2C bus fault using self bus switching device |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060053331A1 (en) * | 2004-09-03 | 2006-03-09 | Chou Norman C | Slave device having independent error recovery |
US7526676B2 (en) * | 2004-09-03 | 2009-04-28 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Slave device having independent error recovery |
US8902554B1 (en) | 2013-06-12 | 2014-12-02 | Cypress Semiconductor Corporation | Over-voltage tolerant circuit and method |
US20150212965A1 (en) * | 2014-01-28 | 2015-07-30 | Siemens Schweiz Ag | Combination of buses for a hazard management system, hazard management system, and method of operating the hazard management system |
US10282336B2 (en) * | 2014-01-28 | 2019-05-07 | Siemens Schweiz Ag | Combination of buses for a hazard management system, hazard management system, and method of operating the hazard management system |
CN105068965A (en) * | 2015-08-13 | 2015-11-18 | 上海斐讯数据通信技术有限公司 | Inter-integrated circuit (I2C) bus based NAND Flash storage method and system |
US20230168980A1 (en) * | 2021-12-01 | 2023-06-01 | Hitachi, Ltd. | Storage system |
US11954001B2 (en) * | 2021-12-01 | 2024-04-09 | Hitachi, Ltd. | Storage system |
Also Published As
Publication number | Publication date |
---|---|
GB0412762D0 (en) | 2004-07-07 |
JP2005006306A (en) | 2005-01-06 |
GB2403039A (en) | 2004-12-22 |
GB2403039B (en) | 2006-10-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7010639B2 (en) | Inter integrated circuit bus router for preventing communication to an unauthorized port | |
US7240130B2 (en) | Method of transmitting data through an 12C router | |
US7082488B2 (en) | System and method for presence detect and reset of a device coupled to an inter-integrated circuit router | |
US7630304B2 (en) | Method of overflow recovery of I2C packets on an I2C router | |
US7398345B2 (en) | Inter-integrated circuit bus router for providing increased security | |
US20040255070A1 (en) | Inter-integrated circuit router for supporting independent transmission rates | |
US7003698B2 (en) | Method and apparatus for transport of debug events between computer system components | |
US8127015B2 (en) | Alerting system, architecture and circuitry | |
EP2002602B1 (en) | Method and system for error assessment over a communication link | |
EP0925666B1 (en) | Method and system for identifying an error condition due to a faulty cable connection in an ethernet network | |
US20080163005A1 (en) | Error injection in pci-express devices | |
US20090279423A1 (en) | Recovering from Failures Without Impact on Data Traffic in a Shared Bus Architecture | |
CN100365994C (en) | Method and system for regulating ethernet | |
CN101317165A (en) | A simplified universal serial bus (USB) hub architecture | |
US20150058912A1 (en) | Method and apparatus for securing computer interfaces | |
US20040255193A1 (en) | Inter integrated circuit router error management system and method | |
US20040255195A1 (en) | System and method for analysis of inter-integrated circuit router | |
US7712004B1 (en) | Method of and system for error checking in a data storage system | |
EP1221099A1 (en) | Remote event handling in a packet network | |
CN115065572A (en) | CAN FD controller for vehicle-mounted electronic system | |
US7596724B2 (en) | Quiescence for retry messages on bidirectional communications interface |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GUIDANT INVESTMENT CORPORATION, CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNOR:CARDICA, INC.;REEL/FRAME:013900/0946 Effective date: 20030819 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LARSON, THANE M.;YATES, KIRK;REEL/FRAME:014476/0757 Effective date: 20030612 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |