The InnovationQ application will be updated on Sunday, May 31st from 10am-noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method to Provide Multi-master Support to the Primary Side of the IBM I2C MUX

IP.com Disclosure Number: IPCOM000015036D
Original Publication Date: 2002-May-08
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



The current implementation of the IBM I2C MUX lacks a mechanism to allow multiple I2C master to access the devices behind the MUX. One can not simply rely on I2C master arbitration to meter access to the MUX. Since an I2C master may be talking to a devices that requires multiple separate I2C transactions to complete a task, another master changing the MUX direction in the middle of these multiple transactions would be catastrophic. The MUX must employ a mechanism to "lock" the direction of the MUX until the current master is finished with the transaction "group." This invention will add features to the IBM I2C MUX that will allow masters to gain exclusive access to the MUX. The invention consists of a multiplexer, logic to implement the MUTEX locking, logic to implement the bus switching and logic to interface to the I2C bus. The invention is built such that an I2C master can read and write data to the device using the standard Philips I2C protocol. To the I2C masters the invention looks like a standard I2C based memory device. The invention can support as few as one master and is only limited in size by the number of secondary I2C busses and number of I2C masters that require access to the MUX. Each I2C master is assigned a semaphore bit in the invention with the highest priority master owning the MSB and other masters following from there. No two I2C masters can share a bit. Each I2C master is assigned a different bit since by the I2C arbitration rules two different I2C masters can successfully write the same data to a device during the exact same I2C bus transaction. If a single bit were to be used, two I2C master could presume that they each have exclusive access. In addition to the I2C semaphore bits, the MUX select bits are assigned beginning with the LSB. Allocation of the semaphore and MUX select bits must not overlap. The system designer can choose how allocate the number of masters vs. number of secondary busses as long as the assignment rules are followed. To obtain a bus switch, the I2C master performs an I2C write transaction to the invention setting its semaphore bit to a zero and all other semaphore bits to a 1 and the MUX bits to the desired secondary I2C bus. The write transaction is allowed to span multiple bytes so the I2C master and invention must follow the I2C spec accordingly. If no other I2C master has previously requested a lock, the semaphore bit corresponding to the I2C master will be set to zero and the new MUX direction will be set. The MUX bits will be latched through to the MUX once the I2C STOP condition is detected on the bus. If a different I2C master previously requested a lock, the write transaction will be halted by a NACK during the last data phase of the transaction and, the new MUX direction will not be set. This NACK behavior will indicate to the current I2C master that the invention is already processing a locked transaction. If the I2C master does not get a NACK during the last data phase, it owns the I2C MUX. The master may optionally read the I2C MUX to see if its bit has been set to determine if it owns the MUX. The master is then free to perform operations on the secondary side of the I2C MUX. After completing all locked transactions, the owning I2C master then writes all one's to the invention. This will clear the semaphore bit and reset the I2C MUX to a default bus. Again the MUX bits are latched through on a STOP. The invention is then clear to perform another locked bus switch.