The PMBus standard for digital power management is the result of collaboration between power supply and semiconductor companies. There are more than 50 members in the PMBus organization. In terms of hardware, PMBus “devices” may be ICs, power converters, or power supplies. No device is required to support all of the available features, functions, and commands, but all must meet certain requirements. Part I of the standard addresses transport, the electrical interface, and timing for hardwired signals. Part II describes the command language.
Table Of Contents
What It’s Not
The PMBus standard does not address direct device-to-device communication such as analog current sharing, real-time analog or digital voltage tracking, or switching-frequency clock signals. It is not a standard for ac-dc power supplies, nor does it specify attributes such as form factor or pin-out, which are addressed by industry alliances such as the Point-Of-Load Alliance (POLA) and the Distributed-power Open Standards Alliance (DOSA). And, it doesn’t deal with communication between one power source and another. This is an important point. That kind of communication remains the domain of semiconductor and power supply manufacturers.
PMBus Roots
PMBus was released in 2003. By that time, the power supply community was adapting to new customer needs, particularly in the data center. While chipmakers continued to work on improving efficiency, they also had to respond to system designers who had embraced distributed power architectures (DPAs). DPAs are based on multi-level power distribution, where it isolated dc-dc converters, followed by loosely regulated intermediate bus converters (IBCs) and non-isolated point-of-load (POL) converters.
DPA components were developed because the latest complex microprocessors and ASICs had multiple power rails for core, memory, and I/O. Each of these rails had different voltage requirements (often down to 1 V) and, for cores in particular, extremely fast di/dt swings. There were many power management issues as well. As a minimum, on power-up and power-down, a systemic approach was needed to sequence those devices to avoid back-biasing transistors on the die.
In addition to application in the final product, this kind of control was deeded in design and manufacturing where the use of voltage margining to test design robustness had increased. Meanwhile, the monitoring of converter output currents and temperatures became common practice to improve system reliability.
As needs grew, different power-IC designers responded in unique ways. Sequencing might be accomplished with “output enable signals,” margining by switching trim-resistor values in and out. Elsewhere in the design cycle and in operation, currents and temperatures were sensed and digitized so FPGAs or microcontrollers could be programmed to manage all those processes.
The result was a kind of Tower of Babel. In 2004, Artesyn Technologies (now part of Emerson Electric) proposed the PMBus initiative. Early the following year, it was formalized as a special interest group (SIG) and opened to global membership. The protocol is now in the public domain, and the SIG, known as the System Management Interface Forum, is responsible for further developing and promoting the standard.
Artesyn framed the need for an industry standard at that time by noting that such an approach would fill a need for broad consensus on digital power management. At that point, several power supply manufacturers including Power-One, Zilker Labs (now part of Maxim Integrated), Primarion (now part of Infineon), and Silicon Labs had already announced digitally programmable point-of-load (POL) converters based on their own proprietary architectures and silicon—though just as PMBus was gaining traction, this situation would lead to a crisis that would bring PMBus implementations to a standstill for several years (see “Power-One’s Z-Bus And Patents.”)
PMBus Basics
The PMBus protocol defines an open-standard digital power management protocol that facilitates communication with a power converter or other device by fully defining the transport and physical interface, as well as the command language needed to accomplish these definitions.
Fundamentally, PMBus is about low-cost real-time control. Its transport layer is based on the SMBus (System Management Bus), a version of Philips’ I2C serial bus that adds packet-error checking and host notification. Importantly for PMBus, SMBus also provides a third signal line, SMBALERT, that allows slave devices such as POL converters to interrupt the system host/bus master. This is where PMBus has an advantage over polling systems.
Under PMBus, slave devices must store their default configuration data in nonvolatile memory or use pin programming. This means they power up without any bus communication, minimizing system startup times compared to schemes in which the bus master configures all slave devices on power-up. Slave physical addresses are defined by means of dedicated pins on the device package.
In addition to the SMBus clock, data, and interrupt lines, PMBus specifies two hardwired signals: a control signal used in conjunction with commands received over the bus to turn individual slave devices on and off, and an optional “write protect” signal that can be used to prevent changes to memory (Fig. 1).
1. Electrically, PMBus is I2C with an added “alert” signal back to the controller.
For bus-contention arbitration, SMBus employs wired-ANDs on all devices. For low cost and flexibility, all communications between host and power sources are conducted entirely via the bus. A “host” can take the form of the system’s existing processor, a low-cost general-purpose microcontroller, or an FPGA. During system design, it can be a PC, or during manufacturing, a piece of automated test equipment (ATE) gear.
Command packets comprise an address byte; a command byte; zero, one, or more data bytes; and an optional packet error code (PEC) byte (Fig. 2). In a typical host-to-slave information transfer, the master uses single “start” and “stop” conditions to indicate the beginning and end of the process, and the addressed slave device uses a single bit to acknowledge reception of each byte.
2. The standard master-to-slave communication sequence comprises multiple data packets.
The slave processes and executes a command immediately after it receives the “stop.” Some 256 commands are potentially available, but PMBus devices do not have to support all commands. Most use only a few. Extensions are built in to allow for command extensions that permit two-byte commands. One is reserved for device manufacturers’ own use, the other for revisions of the protocol.
Writing PMBus Code
Robert White, the evangelist and major architect of the protocol, describes how best to write power management programs in terms of sequencing, noting that only two PMBus commands are required to control a POL converter’s startup sequence (Fig. 3).1
3. Power-up/down sequencing typically involves just four PMBus commands
“TON_DELAY programs a time for the converter to wait until starting to produce an output, and TON_RISE programs the time for the output to increase from zero to the final programmed value. The user simply programs each converter with its own turn-on delay time and turn-on rise-time. Similarly, only two commands (TOFF_DELAY and TOFF_FALL) are required for turn-off sequencing,” White says.
Voltage margining demonstrates similar advantages. Previously, margin testing was highly iterative and time consuming, involving fitting different value resistors to dc-dc converters to vary their output voltage a few percent either side of nominal. PMBus-compliant POL converters simplify this process.
“Again, using just two commands (VOUT_MARGIN_HIGH and VOUT_MARGIN_LOW), each converter can be instructed to deliver tightly controlled test voltages, while the effect on board performance is monitored. This can significantly reduce production test times, help eliminate ambiguity, and produce clearly documented test results,” he says.
PMBus Functionality
Broadly, PMBus-compliant devices have some must-have and some may-have functionality (Tables 1 and 2). In terms of hardwired signals, devices may use pins for programming or for configuration such as a RESET pin or pins for setting the output voltage to high or low margin values. The hardwired CONTROL command, for turning the device on or off, can be configured as active high or active low. Either is optional, but at least one is recommended.
Output Voltage Commands
For flexibility, PMBus provides three formats for commanding or reading output voltage or related parameters: LINEAR, VID, and DIRECT. Using LINEAR, scaling is based on a 2-byte unsigned binary integer with a scaling factor, like a mantissa and exponent. If a linear scale factor is too simple, the DIRECT format allows the use of device-supplied coefficients that can be applied to a nonlinear scaling equation. The VID format supports Intel’s code format used by many microprocessor units.
For ground-reference consistency, PMBus treats all output voltages and output voltage-related as positive values. Table 3 summarizes more specific commands related to output voltage. Table 4 lists output-voltage sequencing commands.
Fault Management And Reporting Commands
PMBus includes the ability to program specific fault or warning levels. Fault conditions are more serious than warning conditions and may require the device to disable its output and stop the transfer of energy. Warnings support less urgent interventions.
For fault conditions, the options are to program the PMBus device to respond by shutting down immediately and latching off, shutting down and retrying, or continuing to operate for a specified delay time before shutting down. Table 5 provides a complete list of commands.
Reading Device Status and Operating Parameters
Read-only device-status and operating parameter commands are used during product design and in operation for fault diagnosis and for monitoring that goes beyond binary fault indicators (Tables 4 and 5). There are also commands to store and retrieve the device manufacturer’s inventory information. Typically, this is for the manufacturer of an assembled power supply or dc-dc converter rather than an IC. Several commands allow manufacturers to return device rating information, which serves as an electronic nameplate for the user’s convenience.
Handshakes
The PMBus command language provides many base command codes and codes reserved for specific manufacturer and user commands, and there is space for future expansion of the base commands. It is unlikely that most PMBus devices will implement all of the PMBus commands.
Conversely, because a device only needs to support one command to comply with the PMBus standard, there are provisions for notifying the PMBus master that a command is not supported. These include responding to a command code or a subsequent data byte with a negative acknowledgement (NAK), or responding with an ACK to the command and data, but then alerting the host that there was a problem.
The host, then, can read the package STATUS_BYTE to determine the support issue. This can be less ambiguous than a NAK, because NAK can mean “I did not hear you,” “I can not support you,” or “I did not understand you.”
Flexible Formats And The Limits Of VID
The PMBus specification allows engineering values to be encoded in at least two formats: literal and direct. The literal format exchanges data in engineering units of volts, amperes, milliseconds, or ºC. The direct method is based on the slave device’s internal units. It simplifies the slave computational requirements at the expense of complexity for the host, which must have information about the translation of host units into internal slave units. The literal format requires the least effort from the master, but the slave must convert internal numerical values to engineering units.
In addition to literal and direct, output voltage can be represented in Intel’s VID format. Although VID adjustments cannot meet the required timing for dynamic-processor power (because the bus bandwidth is too low), VID provides a simple way of managing voltage output and does not require a high level of complexity in either the host or slave devices.
The command language provides several ways to adjust power supply output and limits. First, the host calibrates the module and system to accurately set the output voltage. Next, it uses the VOUT_MODE command to configure the format of the output voltage format. Then the host can use the VOUT_COMMAND, VOUT_MARGIN_HIGH, or VOUT_MARGIN_LOW commands to set the output voltage. Which one it uses depends on the status of the CONTROL signal or on a prior OPERATION command.
Other Commands
PMBus provides explicit commands to set a device’s output voltage (Table 3) and voltage sequencing (Table 4), as well as commands for fault management (Table 5). Other commands simply check any fault-indication status that the device manufacturer has included in the design (Table 6) or certain parametric values, if knowledge of those must be provided for (Table 7).
1. “PMBus—Panacea or Hype?” Bob White, Artesyn Technologies, Electronic Products (August 8, 2005)