SMBus Architecture and Implementation Overview

Robert A. Dunstan Mobile and Handheld Products Group - Mobile Technology Lab Intel Corporation [email protected]

Abstract The SMBus was originally designed to add functionality, with a minimum impact on cost (pin count). A single SMBus in a system was envisioned to have sufficient bandwidth and flexibility to communicate with a variety of devices including batteries, LCD contrast and backlight controllers, power plane switches etc. As the SMBus and systems have matured, a different architecture is emerging. On the hardware front, new devices and uses for the bus are appearing, while multiple SMBus segments within a system are becoming common. SMBus host controllers are being adapted to meet these needs. A single SMBus host controller in the chipset has given way to multiple hosts ranging from a dedicated SMBus connecting a pair of devices to embedded controllers that support one or more SMBuses. At the system level, the Advanced Configuration and Power Interface (ACPI) defines standard methods that can be used to identify the SMBus(s) and devices on a given platform extending the operating system’s the ability to access and control these devices. ACPI will enable the operating system to coordinate its efforts to control the all system components, including those on the SMBus, resulting in better power management, longer battery life and reduced heat generation.

with a Version 1.0 of each released early in History 1995. But was SMBus a done deal? SMBus (System Management Bus) was created As with many emerging technologies, the to extend chipset functionality without adding SMBus was incomplete. Not the specification more pins. Intel’s Mobile and Handheld itself, but rather the environment. How was Products Group (MHPG) found that while more data going to get from the SMBus to the system? functionality could be added to the chipset, the To meet the need, the SMBus BIOS spec was packaging only had a limited the number of pins published. Use of the BIOS allowed system available for these new functions. MHPG designers to hide the details of the actual SMBus engineers looking for a solution, identified low- implementation from the system software. At a speed serial buses as a way to extend the higher level, there was a need to access the functionality of their chipsets. At the same SMBus devices from the operating system. Intel time, another group within MHPG was created and made available a set of reference investigating intelligent batteries and needed a drivers that worked in both Windows 3.1 and simple, inexpensive means to attach the battery Windows 95. These drivers allowed to the system. These efforts were combined to applications to access SMBus devices, and in define SMBus, based on the existing I2C serial particular provided access to the Smart Battery. bus. I2C’s addressing, start/stop and collision detection/correction were adopted unchanged, but the electrical characteristics were tailored to Implementations meet the special needs of batteries and a well The first commercially available SMBus devices defined set of higher level protocols was added. were Smart Batteries targeted at the notebook The drafts of the SMBus and Smart Battery Data market. They appeared in commercial specifications were first published early in 1994, quantities early in 1995 with notebooks using them and SMBus BIOSes following later in 1995. However, there were challenges facing the bus to send messages to the charger or to the the early adopters of SMBus, notably the host. absence of an SMBus host controller chip or a Master only hosts today, take more care in their component with an SMBus UART. These first handling of the bus. They observe bus timing implementations used the keyboard controller to requirements so as not to cause SMBus devices emulate the SMBus host. on the bus to time out. They do not try to master The early systems using the keyboard controller the bus when a transaction is in progress. Many to emulate the SMBus host typically supported a periodically reset the bus and/or whenever they single SMBus device, the Smart Battery. The detect an unexpected bus state. These SMBus host often ignored the fact that the improvements have resulted in more reliable Smart Battery mastered the SMBus to issue SMBus hosts. alarms and simply depended on the battery’s Systems today usually support at least two ability to survive until the SMBus host batteries and a Smart Charger. This adds discovered that the battery was in an alarm additional requirements to the SMBus host. condition. Ignoring the state of the bus when Hosts that are master only must be able to deal the host initiated a bus transaction could cause with multiple masters on the bus. the battery to suffer a temporary communications failure. It also required the Along with the trend towards multiple batteries host to poll on the SMBus to determine if any is the addition of multiple SMBuses in a system. device was in an alarm condition. These Systems with multiple Smart Batteries require systems could not take advantage of the SMBus independent SMBus segments to allow Alert mechanism, which allows a device to independent access and charger coherency. To assert an alert line that notifies the host of an ensure safe operation, the SMBus between the alarm condition because the Smart Battery does Smart Battery Charger and the Smart Battery it not use this feature. is charging must be maintained at all times. Failure to do this can result in spectacular SMBus Host battery failures. But while maintaining a tight Master only connection between the battery and the charger, (part of KBC) the host needs to have the capability to read information from all Smart Batteries in the system. To do this, an additional battery system component, the Smart Battery Selector, has been SMBus developed.

SMBus Host

Other SMBus Smart Battery Device(s)

Smart Battery Other SMBus Smart Battery #1 Smart Battery #2 Selector Device(s) Figure 1. Many of the early SMBus host emulations failed Smart Battery to observe good SMBus etiquette and simply Charger started writing on the SMBus without checking to see if it was busy. This could cause other Figure 2 SMBus devices to become confused. As these Multiple SMBus segments have appeared in were incomplete implementations of the SMBus another context. Private SMBus segments specification, they often exhibited other between pairs of tightly coupled components are unpredictable behaviors. For example, many being used. One example is a CardBus had difficulty when the Smart Battery was controller and a switch that controls the voltage inserted or removed, particularly during a supplied to the CardBus slot. The system transaction or when the Smart Battery mastered communicates to the CardBus controller in the can be included with the operating system as typical fashion using IO ports. The CardBus well. controller accepts commands to control the This example embedded controller also replaces voltage at its slot and then translates them into the functionality of two Smart Battery system SMBus commands that go to the voltage components, the charger and the selector. At selection switch via a private SMBus segment. the interface, it looks like all the components are If the system was required to communicate on the SMBus, but the actual implementation is directly with the voltage selection switch, it quite different, taking advantage of embedded would require at least a read/write line, eight controller to replace functional blocks reducing data lines and a chip select instead of the component count and real estate. The example SMBus’s clock and data line. Using a private embedded controller emulates two SMBus SMBus segment saves a relatively large number segments to individually communicate with two of pins that can result in a considerable cost Smart Batteries. It either operates in a saving. master/slave mode or master only where it must Systems in the future will probably have poll the batteries for alarm conditions. When an multiple SMBuses, multiple SMBus hosts and alarm is detected or there is a status change in private SMBus segments. Figure 3 below is a the Smart Battery system, the embedded block diagram of such a system. controller issues an SCI (ACPI style event notification) which causes the operating system Embedded Controller to identify issuer and service the interrupt. Interface (ACPI) In this example, the embedded controller may Smart Battery #1 Embedded Smart Battery #2 serve another purpose as well. There are some Controller (Smart Battery devices that should not be fully exposed. For Selector, Smart Battery Charger) example, a rogue piece of code could continually force the Smart Charger on the SMBus to charge the battery, potentially causing a battery Card Bus SMBus Host failure or could command the SMBus power Controller plane controller to turn off the main power plane. These SMBus devices can be “hidden” behind the embedded controller interface, available to the system, but totally inaccessible Card Bus Power Switch at the SMBus interface. The embedded controller can reject or ignore requests in order SMBus Device #1 SMBus Device #2 to maintain system safety and integrity. It should be noted that the embedded controller Figure 3 may perform many other system activities as well. This system shows three different collections of SMBus components. The upper is of particular The lower left of Figure 3 represents a chipset interest as an example of an embedded with a SMBus UART. In this case the SMBus controller whose interface is reported to the host is a simple UART and is limited to operating system via ACPI. The key features communicating with devices on the SMBus. are: The lower right of Figure 3 represents a pair of · ACPI reports the location of the embedded devices that use an SMBus segment to pass controller register set. proprietary control, command and data between · ACPI defines a set of commands to the devices. SMBus is attractive in this communicate with devices on the SMBus. application because the implementation can be This set of commands allows a standard device as simple as a pair of shift registers and a clock. driver for the embedded controller to included Most if not all implementations of this type are with the operating system. Since ACPI also expected to have a master only in one device and supports the Smart Battery systems a slave only in the other. The system has no specifications, a standard battery device driver direct access to the SMBus. SMBus Host Emulation time-out and assert a start followed by a stop. This action will resynchronize the SMBus and A major problem seen in many systems in use cause all components on the SMBus to be in a today is the quality of their SMBus host ready state. emulation. The problems range from the failure to check for bus activity before attempting to master the bus to timing violations. There are Areas for Improvement generally simple solutions to these problems. In The SMBus specification has proven to be the following paragraphs, several of these workable and many reliable components use it problems will be examined and solutions posed. now to communicate. However, as more devices Failure to detect bus activity before mastering are designed and new uses are found for the the bus can cause problems for the devices on SMBus, there are areas in the specification that the bus that are already communicating. It is could be improved. Time-outs, while sensible rarely a problem for the emulated host. Since for batteries, are still relatively long. These long indiscriminate mastering of the bus can occur at time-outs, in the order of 30ms for SMBus random times and intervals, clock and data devices, may render the bus unusable for more transitions outside of the normal timing specs time critical devices and/or may limit the are likely to occur. The SMBus specification number of devices that can share the same host. recognized that micro-controllers would be used SMBus uses fixed addressing. This leads to two to emulate the SMBus host function and as a problems: someone needs to coordinate and result specified a relatively short clock high time assign addresses and what happens when the during any bus transaction. This allows the 100 or so available addresses are all used. The SMBus emulation to ensure that the bus is first problem is now being addressed by the inactive by observing the that clock has System Management Bus/Smart Battery remained high for greater than 100ms before Implementers Forum (SBS-IF). The SMBus attempting to master the bus. specification reserved the addresses used for Micro-controllers operating as bus slaves are I2C’s 10-bit addressing which should allow for required to respond to their slave address at a expansion to 10-bit addressing sometime in the 100KHz rate or else follow the clock stretching future. rules. If the micro simply depends on an One other troublesome area is semantic. It interrupt to respond to the start condition (clock comes from differing meanings of the word high, data transitions from high to low), the address. An SMBus address is defined as 7-bits. interrupt latency needs to be less than 4.7ms so However, a 0 (write bit) is usually appended to the micro can meet the timing requirements to that address and the resulting in an 8-bit value is read the data. This requirement can be difficult often used as a device’s address. The SMBus to meet with many micro-controllers taking specification uses the 7-bit convention, while the 20ms or more to respond to the interrupt. The Smart Battery Specifications use the 8-bit solution here can be helper hardware, that is notation. A cautionary note here is that ACPI hardware that holds the clock low when a start consistently uses only the 7-bit address. condition is detected and is reset by the micro- controller when it is ready to respond. The micro-controller is then free to stretch the Where do we go from here? remaining clocks in order to control the effective The SBS Implementers Forum was announced clock rate to one it can easily sustain. This late in 1996. It consists of a core group of helper hardware is present on some chipsets in silicon vendors and battery vendors. In use today. addition, there are other members from various Another area where some SMBus host industries. This group owns the SMBus emulation as well as some SMBus components Specification as well as the Smart Battery Data have difficulty is dealing with transients Specification, the Smart Charger Specification associated with hot insertion/removal of Smart and the Smart Battery Selector specification. Batteries. The exact failure mechanism is less This SBS-IF was an outgrowth of the Smart clear in this case, but a host should detect a bus Battery Plugfests. The Plugfests allowed the participating companies to get together and verify the interoperability of their components., Changes and improvements to the specifications are discussed at the Plugfests. They are open to all SMBus component manufacturers who are invited and encouraged to test their component’s interoperability with those from other manufacturers. The inclusion of SMBus in the Advanced Configuration and Power Interface (ACPI) is very important to the continuing success of SMBus. The ACPI specification was authored by Microsoft, Intel and Toshiba and endorsed by many other OEMs. It is a publicly available specification that defines interfaces and methods that the operating system can use to access, configure and control devices on the system board. ACPI is based on open, publicly available specifications and its inclusion of the SMBus, means that SMBus devices are part of the mainstream. An SMBus device driver will be part of the operating system. Well defined interfaces will allow standard device drivers for common SMBus devices, such as Smart Batteries to be included with the operating system. ACPI is the latest in a series of initiatives from Intel, Microsoft and computer OEMs to simplify system configuration and reduce device/system power consumption.

Call to action · Get a copy of the specification (www.sbs-forum.org). · Use the SMBus where appropriate. · Participate in the SBS-IF.