PMBus, or Power Management Bus, is two-wire interface that defines the management of power subsystems. This bus is an extension of the SMBus protocol, so PMBus and SMBus hold many similarities. In this article, we’ll provide a high-level overview of the background of PMBus, how PMBus operates, where it’s used, and ways to debug and develop PMBus systems.
The PMBus specification was released in 2005 as a way to help redefine power management within embedded systems. Before PMBus, many power supply and semiconductor companies felt there was a lack in ability to efficiently communicate with their power systems. As a result, various power supply and semiconductor companies collaborated to create the PMBus standard, which would allow system developers to configure the power supply for a specific task and to monitor the status/overall health of the power system. Currently, there are over 50 companies who oversee the development of PMBus specifications, and they are formed as PMBus-IF, or Power Management Bus Interface Forum. PMBus-IF is also a subgroup under the System Management Interface Forum (SMIF).
With the need for an industry standard protocol for power communication, PMBus developers determined that the SMBus protocol would be most efficient and cost effective to base the PMBus standard. SMBus it built on the I2C protocol and was created as a means to manage Smart Batteries and other system and power management devices. SMBus is low cost like I2C, but is more robust in its capabilities and features.
Because PMBus is an extension of the SMBus protocol, it shares much of its physical layer and how the bus operates. However, PMBus defines a specific set of commands and data structures required by power control and management components.
PMBus is a low cost, two-wire interface that is an extension of the SMBus standard, which is built from the I2C protocol. Similar to SMBus, PMBus requires a minimum of two wires for communication, including the clock signal, SMBCLK, and data signal, SMBDAT. Optional signals, which would be traded for two GPIO pins, include the CONTROL and SMBALERT# signals. The CONTROL signal acts as a hardwired on/off signal, and SMBALERT# is used to notify and get the attention of the master or system host; this alert signal is often used in the event of a fault condition. The Write Protect (WP) signal is an additional optional signal that is used to prevent unwanted data changes.
PMBus supports a more robust protocol compared to I2C since PMBus provides timeouts and optional packet error checking, or PEC, to enhance data integrity. Timeouts prevent slower slave devices from holding the clock line longer than the specified timeout interval, avoiding bus hang-ups. PEC bytes are generated using a CRC-8 algorithm used to validate the integrity of a transaction, which is often critical in power-management systems.
PMBus supports a maximum bus speed of 400 kHz, and because of the built-in timeouts, all PMBus devices support a minimum bus speed of 10 kHz.
Like SMBus, PMBus includes a system host/bus master and slave device (PMBus device) for communication. A master is any device that initiates transmission and drives the clock. There can be multiple masters on the bus, but only one device can master the bus at a given time. A master device can be a PC or microcontroller and a slave device can include an integrated circuit, power converter, or power supply. In certain instances, where a slave determines a fault, a PMBus device may temporarily become a master device and communicate with the host using the SMBus host notify protocol. A master directs communication to a single slave at a time by using a unique 7-bit address, similar to the slave addressing scheme in I2C and SMBus. This provides 100 possible device addresses after allowing for reserved addresses.
Similar to I2C, PMBus is a variable length packet of 8-bit data bytes. The basic data packet structure for PMBus includes an Address Byte which comprises of a 7-bit address, ending with a 1-bit Read or Write signal. Then follows an 8-bit Command Byte including the Command Code, following with one or more 8-bit Data bytes. Optionally, there may be an 8-bit PEC byte as well. Each byte includes their own receiver acknowledge, and each transaction is enclosed between a Start and Stop bit from the host.
The PMBus electrical interface follows similarly to the SMBus specification. For supply voltage requirements, the operating voltage range (VDD) may be 3 V to 5 V ±10% (2.7 V to 5.5 V).
The required pull down current is 4 mA for 400 kHz PMBus devices.
PMBus defines a set of commands that are specifically targeted for power control and management components to ensure the system is operating correctly. These commands allow the system to perform configuration, control, status monitoring, fault management, and information storage (inventory, user data).
PMBus devices must support the Group Command Protocol, which is designed to allow several PMBus-compliant devices to simultaneously execute commands. With this protocol, devices can receive the same or different command, but only one command can be sent to any a device in one Group Command packet.
PMBus commands are one-byte command codes, which allows for 256 commands that can be sent and read over the bus. Every command packet contains an address byte, followed by a command byte, and then either followed with zero or more bytes of data. Optionally, there also may be an additional PEC byte.
Additionally, to support certain commands of the PMBus command language, devices must support the Block Write-Block Read Process Call. PMBus supports block writes and reads up to 255 bytes in length compared to the 32-byte limit of SMBus.
PMBus has been increasingly used for digital power management within systems. PMBus works with a variety of power management products, such as AC-DC power supplies, isolated DC-DC break converters, non-isolated point-of-load (POL) converters, voltage regulators, supply sequencers and point-of-load voltage programmers, and monitors and fan controllers.
Total Phase offers a variety of debugging and development tools for I2C-based systems, including the Aardvark I2C/SPI Host Adapter, the Promira Serial Platform, and the Beagle I2C/SPI Protocol Analyzer. And because PMBus is based on I2C, some of our tools offer certain capabilities in helping developers test and debug their PMBus systems.
By using the Aardvark I2C/SPI Host Adapter or Promira Serial Platform, users can emulate a master or slave PMBus device. PMBus commands will need to be implemented by the user.
While PMBus decoding is not currently supported by the Beagle I2C/SPI Protocol Analyzer, users can monitor the I2C portion of PMBus by connecting the lines directly to the Beagle I2C/SPI analyzer and parse/decode them using the Beagle Software API. The other two lines CONTROL, SMBALERT# cannot be monitored.
Also wondering how we support SMBus? Learn how to get started debugging and developing SMBus systems using Total Phase tools here.
For more information on how Total Phase can help develop your I2C or PMBus applications, please email us at sales@totalphase.com.