Volume 2, Number 2, Spring 2002

An Intelligent Serial Communication:
SMBus (System Management Bus)

Steve Hsiung
Associate Professor
Industrial Technology and Education
Utah State University


Serial communication between devices is an efficient and cost effective way that has been used in industries for years. System Management Bus (SMBus) is one of the newly developed means in the serial communication format. It uses two wires in bi-directional serial bus to provide intelligent protocols such as Master/Slave mode, time out, and error checking schemes. SMBus improves communications over other traditional serial forms: SCI, SPI, or any bit banging methods. It is the up-coming trend for mobile computer devices and desktop computer systems.


Communication between computer devices, especially in the chip level is vital and critical. There are two basic communication formats. A parallel form is straight and fast but costly. The other format is a serial form that is efficient and cost effective and has been used in industries for years. Those traditional serial formats are SPI (Serial Peripheral Interface), SCI (Serial Communication Interface), and other bit banging methods. SMBus (System Management Bus) is a newly developed form of a serial communication for use in between chips or systems. It has evolved from I2C (Inter IC) that was invented by Philips Semiconductors Inc. in the early 1980s [3]. In 1995, INTEL, Duracell Inc., Energizer Power Systems, Linear Technology, Mitsubishi Electronics, National Semiconductors, Benchmarq Microelectronics Inc., and Maxim Integrated Products used the principal operations of I2C to found todays SMBus standards [5]. It requires only two wires in bi-directional serial bus to provide a simple, efficient, and almost error free communication between devices for data exchange. It can play either master mode that controls the clock or slave mode sends/receives data serially. SMBus has error checking schemes that handle all the possible errors within the form of protocols and there is no tripping or stroking of any extra control lines [6]. It is mainly targeted for smart batteries that use Lithium Iron battery cells in notebook computers and their peripherals. It has the speed in range of 10Hz 100KHz [5].


The following are a brief discussion of the most common forms of the serial communication applications between devices.

Synchronous Serial Transmission/Receiving

SPI (Serial Peripheral Interface) is a synchronous communication in which both parties share the same clock. It uses three lines to communicate with other devices. There are SI (Serial In), SO (Serial Out), SCLK (Serial Clock) lines for the signals. SPI can be either master mode that controls the clock and sends/receives the data or slave mode that receives/sends the data. These modes are not interchangeable. Some devices such as EEPROM and display units are slave mode only. Some controller devices can play either master or slave mode depends on different configuration setup. They are committed to a specific mode after some particular setup steps. Any mode change requires a special configuration routine, and that mode stays on until another particular setup steps are implemented.

The operation of the SPI is that a master sends the clock on SCLK line along with serial data on SO line. The data is clocked out on SO line in a sequence of the MSB (Most Significant Bit) first and the LSB (Least Significant Bit) last during the master mode send stage. In the master mode receive stage; the data will be clocked in on SI line while the master sends a dummy byte (usually $FF or 0XFF) and the receiving bit is clocked in on a different edge of the same clock. The slave mode is either receiving data on SI line while a master is providing the clock or providing serial data on SO line to send bits out per masters request when a master is sending a dummy byte and providing the clock. There is limited error detection after the data byte has been sent or received but no intelligence during the bits transmission. It can be implemented in the interrupt driven algorithm to handle the data exchange in a more efficient manner.

Asynchronous Serial Transmission/Receiving

Asynchronous communication is usually referred to as UART (Universal Asynchronous Receiver/Transmitter). There are several formats of UART: (a) Simplex serial communication uses only one-way, one-line communication, (b) Half-duplex serial communication uses two-way on a single channel, (c) Full-duplex serial communication uses two channels, one for the transmit line and the other for the receive line [4].

For an equivalent comparison, the SCI (Serial Communication Interface) that is a Full-duplex and has two channels is introduced here. These two channels are called TxD (Transmission Data) and RxD (Receive Data) lines. SCI is an asynchronous communication that both parties do not use the same clock. Actually, there is no dedicated clock line for this type of communication. The data in or data out line is the clock itself. The transmission speed is determined in advance between two ends of the data rate been sent or received. Any error checking or handshaking scheme requires addition line(s) to trip or stroke to fulfill the requirements. It can also use the interrupt routine to handle the repeated communications.

The need of extra pin(s) for error detection makes SCI less attractive in transmitting data between chip level devices. Because of its simplicity and some special error handling detection with the help of additional signal lines, SCI is popular in computers, printers, and modems applications.

Bit Banging Method

The bit banning method is a way that does not require assistance from any external circuitry to send or receive data stream. At the sending or receiving device, normally there is a controller handles everything during the communication period. The task of sending/checking on the clock and sending data/waiting for response from the other end on a bit-by-bit basis requires constant attention during the communication period that leaves heavy burden on the controller on both parties. There is little room and time for the controller to perform tasks during the sending/receiving data period. It has little error detecting that the controller can perform since it is constantly busy in dealing with data transmission on every single bit.


The SMBus is a two-wire mutli-master protocol that means more than one device can be connected and take control of the bus. A master is defined as a device that is the only one can initiate a bus transfer and provide the clock signals on the bus. A slave is defined as a device that is required to response to a master call by sending/receiving data to/from the master if its address has been placed on the bus. The bus has bi-directional SCL (Signal Clock) and SDA (Signal Data) lines connected to a positive supply voltage through pull-up resistors [6].

Both parties use the same clock format as a SPI. But there is no configuration required to change the mode. A device can be a slave and turn around become a master as long as it can take control of the bus. There are specific bus arbitration rules that are targeted on the bus ownership. A unique time out is activated if the bus gets stuck by any party or any faulty line. Anyone on the bus after the time-out period is required to back out and can try again to re-establish the communication. A special bus error checking can be implemented in the protocols to make it more immune to potential noises. A detail look at the SMBus specifications is the focus of this paper.

Now, it is the time to explore the basic SMBus regulations and its operations [5]:

1. A START or REPEATED START condition is defined as when there is a HIGH to LOW transition on SDA line while SCL is HIGH. Only a master can generate a START or REPEATED START on the bus.

2. A STOP is defined as when there is a LOW to HIGH transition of the SDA line while SCL is HIGH. This signal on the bus is also generated by a master only.

3. An ACK (acknowledge) is defined as the receiving device must pull the SDA line LOW during the HIGH period of the 9th clock pulse (SCL) at the end of each byte it has received. Both master and slave can generate this ACK signal.

4. A NACK (not acknowledge) is defined as the receive device must let the SDA line remain HIGH during the acknowledge clock pulse (9th SCL clock). This is a default signal if neither party responses at end of any bytes transmission.

5.      When a slave device is not available or none exist after the byte has been sent by a master, then there will be no ACK generated. The master device will receive a NACK by default and it is required to send a STOP to abort the communication.

6. An arbitration is defined as: Whoever takes control of the bus by pulling the SCL line low first becomes a master and wins the control of the bus and any other party looses. The master that lost the arbitration shall stay out of the bus for a time-out period and allowed to try to pull the SCL line low again to win back the bus if it intends to communicate after the time-out period.

7. Any party after a time-out period is required to back out from the bus; that means the slave shall not hold the SDA line low and the master shall send a STOP to abort any communication that it initiated.

8. The first byte after the START signal must be a 7 bit address plus the last read/write bit (the 8th bit) if it is a 1 indicates the following byte is a read, if it is a 0 indicates the following byte is a write.

9. Any complete communication must begin with a START and end with a STOP that shall be provided by a master.

10. The only time that data bit on SDA line is allowed to vary its status is when SCL line is low.

Here are the available protocols and their SCL and SDA line signals in SMBus standards [6]:

1. Quick <START><Address+R/W=0><ACK><STOP>

Figure 1. Clock and Data Bits Flow of SMBus Quick


2. Send Byte <START><Address+R/W=0><ACK><Command><ACK><STOP>

Figure 2. Clock and Data Bits Flow of SMBus Send Byte


3.      Receive Byte <START><Address+R/W=1><ACK><Data Byte><NACK>


Figure 3. Clock and Data Bits Flow of SMBus Receive Byte


4. Write Byte <START><Address+R/W=0><ACK><Command><ACK><Data


Figure 4. Clock and Data Bits Flow of SMBus Write Byte


5. Write Word <START>< Address+R/W=0><ACK><Command><ACK><Data

Byte Lo><ACK><Data Byte Hi><ACK><STOP>

Figure 5. Clock and Data Bits Flow of SMBus Write Word

6. Read Byte <START>< Address+R/W=0><ACK><Command><ACK>

<REPATED START>< Address+R/W=1><Data Byte><NACK>


Figure 6. Clock and Data Bits Flow of SMBus Read Byte


7. Read Word <START>< Address+R/W=0><ACK><Command><ACK>

<REPATED START>< Address+R/W=1><Data Byte

Lo><ACK><Data Byte Hi><NACK><STOP>

Figure 7. Clock and Data Bits Flow of SMBus Read Word


8. Block Write <START>< Address+R/W=0><ACK><Command><ACK><Byte

Count=N><ACK><Data Byte 1><ACK><Data Byte 2><ACK>.

<Data Byte N><ACK><STOP>

Figure 8. Clock and Data Bits Flow of SMBus Block Write


9. Block Read <START>< Address+R/W=0><ACK><Command><ACK>

<REPATED START>< Address+R/W=1><ACK> <Byte Count=N>

<ACK><Data Byte 1><ACK><Data Byte 2><ACK>.<Data Byte


Figure 9. Clock and Data Bits Flow of SMBus Block Read


After examining the detail bits and bytes regulations, a flow chart presented in Figure 10 (below) gives another overall view of the SMBus protocols.


The chance of getting an error during any data transmission is unpredictable and unpreventable. The intelligence of a serial communication relies on how the error is detected, handed, and, recovered from those errors. There is no bullet-proof method of error free communication, but the best one depends on how intelligent a protocol is while dealing with and responding to these errors and still maintains a stable operating condition. The followings are the SMBus standards that handle spurious conditions and make it unique and better than the other serial communication formats [6].


Figure 10. SMBus Flow Chart


1. ACK/NACK: The receive side has to ACK at the end of each byte transmission. If there is no ACK (that means a NACK by default) from the receive side the transmit side (master) has to abort the communication by sending a STOP.

2. Time Out: Both parties are allowed to hold SDA low for a fix time-out period (25-35 ms) for whatever the reason. Any party holds SDA low for more than the allowed time-out period is required to abort the communication which means master has to send a STOP or slave has to release SDA line to terminate the communication.

3. Time Out: If there is a time out occurred the communication has to be aborted by both ends and a new or repeated communication is to begin after the time-out period.

4. PEC: Packet Error Code that uses 8-bit cyclic redundancy check (CRC-8) of each read or write bus transaction to calculate a FCS (Frame Check Sequence). This CRC-8 is calculated by the polynomial as C(X) = X8 + X2 + X1 + 1 [1]. The operation is that a master will send an addition byte of its PEC before the STOP in each protocol.

5. It is up to the individual party to decide how many times a failure communication is a proper conclusion of a faulty line on the bus. Normally, this is decided by the master when and how to give up the communication.


Figure 11. All the SMBus Protocols with PEC Implementation

The PEC is an additional byte to the SMBus protocols to check any transmission error condition. A PEC byte is to be sent from a master and the slave needs to come out with its own PEC byte. Both PEC bytes must be identical to complete a valid transmission. If it is not, the master can try to re-initiate this communication again.

The SMBus operation with PEC byte is very similar to those protocols that have been introduced. As shown in Figure 11, at the end of every protocol before a STOP there is an extra byte (PEC byte) sent by a master. A slave can hold SCL line for a maximum of 25-35 ms for its own calculation needs or go through a table lookup for a PEC byte [1]. If there is a match on the PEC byte, the transmission is considered a success and slave should release the SCL line and master will send a STOP. If there is no match on the PEC byte the transmission is consider as a failure and slave can hold SCL line low till the time-out period and master should still send a STOP but notice the transmission did not go through and can try it again or else.

Having these error-handling schemes, even a broken line during transmission the chance of communication mistake or any system runs away is very slim in SMBus standards.


The SMBus forum that defines the AC characteristic of the bus signals and protocol addresses & commands are mainly targeted for Lithium Iron battery cells that is now used in notebook computer systems [2]. With the aid of bi-direction, master/slave modes, and fairly high speed, the battery back will be able to calculate real time parametric data, maintain history, predict performance, alarm critical conditions, and extend battery cells life [2]. That is how the name smart battery became. SMBus has been widely accepted in the portable power management industries.

There are also traces of SMBus or I2C in computer monitor board controls, battery chargers, EEPROM in DIMM, desktop computer main boards, some LAN applications, and computer peripheral devices [3]. These protocol formats have various advantages over other means in serial communication, which make them attractive to any data exchange between devices or systems.


SMBus is a versatile, simple, and yet efficient communication form for new devices in the modern electronic industry. It has been implemented in the so called smart battery in modern notebook computers. It is at the beginning state in implementing on new computer main board, keyboard, mouse, monitor control circuit, EEPROM in DIMM, and wakeup on LAN connector. The unique format of the SMBus applications can be used everywhere in either wired system or wireless communications. It is not the only smart serial communication standard but a far better method than the traditional means, and it is the upcoming trend for current electronic industries.


[1] CRC-8 Implementation White Paper (1999), USAR System Inc., www.semtech.com

[2] MAX1780 Smart Battery Pack Controller (2001), www.maxim-ic.com/designapps/EndEquipment/BatteryPack/BatteryParts.htm

[3] Philips Semiconductors I2C Specification (1997), www-us2.semiconductors.Philips.com i2c/news/

[4] Serial and UART tutorial (1996), Frank Durda, www.freebsd.org/doc/en_US. iso88591-1/articles/serial_uart/, Email:uhelm@freebsd.org

[5] System Management Bus (SMBus) Specification (1998), Revision 1.1, Smart Battery System Specifications, www.sbs-forum.org, Email: battery@sbs-forum.org

[6] System Management Bus (SMBus) Specification (2000), Revision 2.0, Smart Battery

System Specifications, www.sbs-forum.org , Email: battery@sbs-forum.org or questions@sbs-forum.org