Get the message: Power-management protocol rides on industry bus

As system power requirements have increased in complexity for telecom and datacom applications, so have the communication requirements between the system host and its power subsystems. Power-supply and power-management-IC vendors initially responded by developing proprietary communication and control schemes. However, an SIG (Special Interest Group) comprising power-management-IC and power-supply vendors, after about 18 months of planning, this year released the first version of the PMBus, an open standard for communication between host systems and the power subsystems. The PMBus Implementers Forum, which the System Management Interface Forum has now absorbed, originally developed the standard.

Communication between the system host and power subsystems has been relatively simple, often comprising one line indicating that power is either on or off. In complex telecom and datacom applications, such an indicator is woefully inadequate. The PMBus SIG members believed the time was right for an industry-backed open standard.

Why does a system need to communicate with its power subsystem beyond a simple on/off response? The host must be able to tell the power subsystem what the system's power needs are or will be and to get status information from the subsystem. Don Alfano, director of power products for Silicon Labs, gives an example: "Let's say that you have a large system with a lot of high-current ASICs. And let's say that system doesn't necessarily have all of these high-current ICs on at any one time, because it's switching them in and out to conserve power whenever possible. When these ASICs turn on, there is an enormous inrush of current. It would be nice to give the power subsystem some warning that the massive current needs of an ASIC will shortly need to be met. The power subsystem can begin to position itself for a large current load or to limit the inrush current. Either way, the subsystem can react as an integral part of the system, rather than something that just sits there and tries to hold the voltage constant."

The PMBus' physical interface is based on the simple and popular I²C (Inter-IC Bus), a serial bus that Philips developed for communication between large ICs, typically within a single backplane. As Alfano puts it, "It's a little LAN for chips. With only two wires, an almost unlimited number of talkers and listeners can be on the network. And many microcontrollers already have an I²C port."

The PMBus is not the only intersystem-communication bus based on I²C: SMBus, which Intel developed for system management, is also I²C-based. However, PMBus is more robust than its precursors in that if a chip stops talking on an I²C bus or the SMBus, the bus hangs up, whereas the PMBus times out and boots the chip off the network.

Building on the I²C hardware interface, the PMBus SIG next developed a protocol for handling power-management information. The protocol covers manufacturing information, power-supervision and -monitoring commands, and power-supply-control commands. Manufacturing information can include information such as serial numbers, lot numbers, codes, and manufacturer-specific information. Power-supervision and -monitoring commands provide a framework for the system to communicate with the power subsystem's controller, an important feature because each power-microcontroller vendor has developed its own protocol. Dave Freeman, system-power-products engineering manager at Texas Instruments and TI's representative on the PMBus SIG, says, "A lot of power-management ICs are out there, and they all manage and sequence supplies with their proprietary interfaces. One of the goals of the SIG was to develop a protocol that would make it simpler for the host software to deal with these various microcontrollers."

Power-supply-control commands allow the system to set power-supply parameters, such as frequency, duty-cycle limits, compensation, and values for closing the power-control loop. Freeman explains how TI plans to implement the PMBus control protocol in its power-controller ICs: "The PMBus will configure and set limits and set operational policies for the digital controller. The digital controller will be responsible for closing the loop and operating within the bounds set by the PMBus. The PMBus is too slow for real-time control as far as closing a control loop, but it can set power policy," he says. For example, it can define compensation values for loop closure in sleep mode versus the values that the supply would use when it is awake. Says Freeman, "The PMBus overhead is small compared to the bandwidth necessary for the digital controller."

Alfano of Silicon Labs agrees and points out that, because of the low overhead the bus protocol incurs, designers can implement the PMBus almost free in parts costs and count for subsystems that have digital controllers. And he believes that most subsystems within the next few years will have a digital controller. "Since you've already got the microcontroller to close your digital-control loop, running a PMBus protocol is easy and cheap."

He underscores the importance of using a microcontroller with onboard ADCs: You can use the ADC to replace analog circuits that provide circuit protection such as overvoltage protection, current shutdown, and overtemperature protection. If you use the additional bandwidth in your mixed-signal microcontroller to monitor these conditions, you can replace several analog components (Figure 1). Other advantages include increased reliability from the reduced parts count and the added flexibility of programmable parameters.

The specification comprises 115 commands, such as power-supply temperature status and history, output voltage, current, and switching offline and online. However, a device neither needs nor is likely to implement all 115 commands. To comply, all a power subsystem must do is obey the physical specification, including the electrical and timing specification, and implement one standard command. Additionally, if you implement commands that have the same effect, you must implement the command according to the specification, and, if the system doesn't implement a command, it must send a nonacknowledgment and not execute it. Keith Curtis, principal applications engineer for the security, microcontroller, and technology-development division for Microchip, says the SIG insisted that any device claiming PMBus compatibility must be able to operate stand-alone with no bus connection.

Having access to a GUI (graphical user interface) to develop your application is just as important as having the right digital controller to interface to the PMBus. Curtis, who is chairman of the PMBus Reference GUI subcommittee, explains the importance of a powerful GUI: "The intent of the whole GUI effort is to make it easy for people to get started with an upfront configuration. I would expect people to take this as a starting point and then build their own in-house systems." Curtis expects developers to also control the PMBus from environments such as LabView, Virtual Basic, or C, depending on their expertise.

In addition to running on a variety of platforms, the GUI must support a variety of microcontrollers. "The GUI has to be able to run on something as simple as a PIC16F785 with an I²C interface, up through the dsPIC," says Curtis. "The GUI must have the kind of range that allows it to support a small low-dropout point-of-load regulator on a board up through the ac/dc converter that's supplying a rack." Microchip has released the PIC16F685/687/689/690, the company's first offering that supports the PMBus.

The SIG will by year-end release a GUI that will support debugging, multiple command strings, demonstration functions, and manufacturer-specific commands. The debugging function allows designers to manually enter commands and debug initial communications routines. The multiple command strings include a macro function, and the demonstration function takes advantage of all the capabilities of the PMBus, displaying voltages as real numbers rather than as hexadecimal values. With the manufacturer-specific commands, you can change the GUI's front end and have it run with your company's name and format. You also can use the built-in PMBus functions for communication.

Not all vendors have immediately and wholeheartedly embraced the PMBus (see sidebar "Competition for a power-management protocol"). Semtech recently announced its SC900 I²C power-management IC, which offers the I²C interface but no PMBus support. Tom Karpus, handheld-systems manager for portable power products at Semtech, says the company is looking at the PMBus, but stayed with the I²C interface for the SC900. "The I²C interface offers substantial benefits to a small, multiregulator device like the SC900. I²C also involves having an address assigned to the device, so there is no need to have external pins to set the device address, an important consideration for a miniature device without the room for these address-assignment pins," says Karpus. He adds that Semtech is monitoring the evolution of PMBus for future designs.

Even the staunchest supporters of the bus don't claim it excels in all applications. Because the designers of the original I²C bus developed it for inter-IC communication, the bus is best for short-haul applications, such as within a single board or server blade. For intercabinet runs, you're better off with a more robust bus. The European CANBus, whose developers targeted automotive applications that are similarly noisy environments, is the most likely choice.

*Member of the initial coalition of power-industry companies.