Frequently Asked Questions
The following questions and answers have been provided for your information and may be subject to change without notice. Hover over the + at the right of each closed box to expand it to view the answer.
General PMBus Support
I have a question about the PMBus or SMBus. Where can I get help?
Send your question to email@example.com. Questions about the specifications can be answered and some assistance can be provided with debugging problems with a PMBus or SMBus system. We do not recommend specific products or suppliers.
What is PMBus?
PMBus is a non-proprietary standard for communication with power converters of all types. The PMBus specification is in three parts.
- Part I describes how data is moved from one device to another. It is based on the SMBus specification with a few additional requirements specific to the PMBus.
- Part II of the PMBus specification describes the command language, data formats including numerical formats, how communication faults are handled, and other requirements.
- Part III of the PMBus specification was introduced with Revision 1.3. Part III describes the AVSBus which provides a fast and simple interface for logic devices (such as microprocessors, ASICs, and FPGAs and other programmable logic devices) to quickly control their supply voltage. AVSBus also provides for some monitoring of the power converter attached to the devices. The physical layer of the AVSBus is very much like the common SPI.
What is AVSBus™?
AVSBus (Adaptive Voltage Scaling Bus) is a part of the PMBus specifications. The AVSBus specification describes a power management bus design to allowed complex logic devices, like processors and large FPGAs, to control their supply voltages as fast as possible.
When a logic device wants to enter an energy saving mode, like a hibernation or sleep state, it generally lowers its supply voltage to a minimum value. The faster the voltage can be changed from the normal or high performance operating value to the energy saving value, the more energy can be saved. An important part of how long it takes to reduce the voltage is the communication delay from the logic device to the power converter. AVSBus, which can operate at speeds up to 50 MHz, is designed to minimize the communication delay and maximize energy savings.
In the other direction, when a logic device wants to return to normal or high performance operation, it is important that the voltage be increased to the new operating voltage as quickly as possible in order to maximize performance. Again, AVSBus is designed to minimize the communication delay so that the power converter can respond to the voltage change request in the least time possible.
How can I participate in the PMBus standard development process?
Companies that are current PMBus Adopters are eligible, but not required, to participate in the PMBus Standards Working Group. Companies interested in participating in the PMBus Standards Working Group should send an email message firstname.lastname@example.org with the name and contact of the person that they would like to represent them in the Working Group.
In general, each PMBus Adopter may have one representative on the group although this is at the discretion of the Chair of the Working Group. When voting on any matter, each PMBus Adopter company gets one vote.
Is there any training available for the PMBus?
The PMBus web site, http://pmbus.org/, provides supporting materials. On the home page, in addition to the specification, Application Profiles & Notes are available under the Specifications tab and several presentations on PMBus are available under the Resources tab.
How do I get the PMBus specification?
The current PMBus specifications are available at no cost, although registration with your name, email, and company is required, from the PMBus web site, http://pmbus.org/.
What is the difference between PMBus and I2C?
The I2C specification only describes the physical layer, timing, and flow control of a two-wire bus. The I2C specification does not describe the format of messages (like the SMBus protocols) and does not describe the content of the messages.
The PMBus specification is a complete power management protocol. It includes how to get the bit and bytes from one device to another (transport) as well as describing a command language that gives meaning to those bits and bytes.
Can I use the PMBus with other buses such as serial buses (RS-232 or RS-485), USB, or TCP/IP over Ethernet?
In principle, yes, although there is no specification to do so. The original PMBus specification was in two parts, transport and command language, to allow for the possibility of using another bus, such as RS-485, to send and receive PMBus commands.
How do I get my product certified as compliant to the PMBus specification?
At this time, device manufacturers must self-certify that their devices are compliant to the PMBus specification.
Who controls the assignment of devices addresses for PMBus devices?
There is no central authority that controls the addresses of PMBus devices. Manufacturers are free to use any of the non-reserved addresses for their devices. This places the responsibility for assuring that there are no address conflicts on the system engineer designing with PMBus devices.
What PMBus products are available?
On the PMBus web site, http://pmbus.org/, the Products tab leads to a list of PMBus adopter companies. Click on Product By Category to see a list of particular products, or conversely, click on Products By Company to see a list of PMBus products from a specific company.
Where can I get tools to support the design and testing of my PMBus system?
There is a growing number of technical notes, design tools, adapters and demonstration kits available to support PMBus system development. Many of our adopter companies provide tools that are specifically tailored to support their PMBus-compliant product offerings, which can be found under the Products tab of the PMBus web site. Other universal development tools are also available from third-party suppliers.
Disclaimer: This partial listing of suppliers and products is provided as a convenience and is not an endorsement of any of these suppliers or products by the System Management Interface Forum. Please contact your supplier directly for a complete review of PMBus support information.
PMBus Technical Operations
What is required in order for a product to be in compliance with the PMBus specification?
Part I of the PMBus specification defines four distinct requirements for a device to be considered compliant to the PMBus specification.
- The device must meet all of the requirements of Part I of the PMBus specification. The purpose of this requirement is to assure that PMBus devices are interoperable at the interface level.
- The device must support at least one of the non-manufacturer specific commands given in Part II of the PMBus specification, The PMBus specification is intended to cover a wide range of power converter types and applications. Except for this requirement, it would be possible for a manufacturer to develop a device that has only commands custom to that manufacturer. This requirement is intended to encourage manufacturers to use more of the standard commands.
- If a device accepts a PMBus command code, it must execute that function as described in Part II of the PMBus specification. This requirement is to assure interoperability of PMBus devices that use standard commands. For example, the basic command to set the output voltage is VOUT_COMMAND. Part II of the specification describes this command including the acceptable formats for the data containing the value of the voltage. If a manufacturer developed a device that accepted the VOUT_COMMAND, but specified their own formatting for the data, it would not be interoperable with any other manufacturer’s PMBus device. So this requirement assures the system engineer that the possible formats for the data are limited to the ones given in the PMBus specification.
- If a device does not accept a given PMBus command code, it must respond as described in the “Fault Management and Reporting” section of Part II of the PMBus specification. This assures that a controller or host device that is attempting to communicate with a target PMBus device will be informed if a command was accepted.
What signals are required for a PMBus system?
The minimum required signals are the clock, SMBCLK, and data, SMBDAT.
What are the optional signals for a PMBus system?
Optional PMBus signals include the CONTROL signal, which acts as a hardwired on/off signal, and SMBALERT#, which is a signal for a PMBus device to notify the controller or system host that it has information or needs attention, such as in the cause of a fault condition. Another optional signal is WP (write protect), an input to a PMBus device that can control write access to a PMBus device.
What is the PMBus CONTROL signal, and how do I use it?
The CONTROL signal is a hardwired on/off signal. The signal name “control” was chosen because many power supply manufacturers were already using signal names like ENABLE or REMOTE ON/OFF.
The CONTROL signal can be configured to be active high (CONTROL pulled high to start the converter) or active low (CONTROL pulled low to start the converter) by using the ON_OFF_CONFIG command.
One use of the CONTROL signal is as an emergency off signal. Under normal conditions, the converter would be turned on and off over the bus using the OPERATION command. In the case of a system fault requiring the system to be powered down immediately, the CONTROL signal could be set to the “Not Run” or “Off” value to cause all converters to turn off or start their power down sequence immediately.
Another use of the CONTROL signal is to synchronize power up (or power down) sequencing. First, startup delay time and output voltage rise time of all the converters in the system are configured using the TON_DELAY and TON_RISE commands. Then the converters are configured to start when the CONTROL signal is asserted (active high or low as configured with the ON_OFF_CONFIG command). Asserting the CONTROL signal provides a simultaneous “Start” signal to the converters.
What are manufacturer-specific PMBus commands?
When developing the PMBus specification the PMBus Specification Working Group recognized the need for device manufacturers to add their own unique value, albeit at the cost of interoperability with devices from other manufacturers. To accomplish this goal, the PMBus specification designates several command codes as manufacturer-specific. Possible uses of the manufacturer-specific commands are:
- A command to download firmware updates,
- A command that reads back of all of the device status in one command,
- Commands for calibrating additional parameters, or
- A command to download coefficients for a digital compensator.
If a manufacturer does use one or more manufacturer-specific commands, they must provide a full description of the command, including transaction type and data formats, in their product literature.
How can a system controller determine the capabilities and supported PMBus commands for a target device?
Two commands are provided that allow a controller or system host to determine the capabilities of PMBus devices on the bus: CAPABILITY and QUERY.
The CAPABILITY command provides basic information about the PMBus. The CAPABILITY command returns information such as:
- Does the device support Packet Error Checking (PEC)?
- Maximum bus speed supported by the device?
- Does the device have an SMBALERT# signal output?
- Which numeric format is used for general purpose data?
- Does the device support the AVSBus?
The QUERY command allows a controller or system host to ask a PMBus device about support for a specific command.
The QUERY command returns information such as:
- Is the command supported or not?
- If the command is supported, does the device allow writes to this command?
- Does the device allow reads of the data associated with the command?
- What is the data format the device uses with this command?
The combination of these two commands, CAPABILTY and QUERY, allows a controller or system host to determine how to configure itself to work with a PMBus device on the bus.
How can a controller device quickly determine how many target devices are on the bus and their addresses?
The standard way is for a controller to poll each address in the system and terminate the transaction with a STOP condition after the ACK/NACK response. If an ACK follows the R/W# bit then the controller knows that there is a device at that address. If there is no acknowledge (a NACK) after the R/W# bit then the master knows there is no device at the address.
A faster way is for the system to use ZONE capable devices. The controller can then use a ZONE READ operation to get a response from all the attached devices. This results in a transaction that is only as long as the number of devices on the bus rather than the 127 transactions needed to poll every address. The procedure for discovering all of the devices in a system using the ZONE READ operation is described in detail in PMBus Power System Management Protocol Application Note AN001: Using The ZONE_READ and ZONE_WRITE Protocols, which can be found in the Application Profiles & Notes section under the Specifications tab on the PMBus web site http://pmbus.org/.
What are the Zone Protocols?
The new Zone Protocol is comprised of three features which enable faster bus transactions:
- Zone Configuration
- Zone Write
- Zone Read
A zone is a set of target devices on a shared PMBus that can react to Zone Write and Zone Read operations. Any target device can be assigned to a zone with a configuration command, and a controller can set the Active Write Zone and Active Read Zone to communicate with a specific zone, in much the same way a controller can set the PAGE of a target device to communicate with a subset of its functionality. The Active Write Zone and Active Read Zone do not have to be the same value. The Active Write Zone is often not the same as the Active Read Zone because it is common to “control” one subset of target devices and “monitor” telemetry from a different subset.
What addresses are available for use by SMBus and PMBus devices?
“Appendix C. SMBus Device Address Assignments” of the SMBus 3.0 specification gives a detailed list of the available and reserved addresses for both PMBus and SMBus devices.
SMBus Related Questions
What is SMBus? How is it different from I2C?
The SMBus is a 2-wire bus that is similar to the I2C bus that was developed by Philips in the 1980s. The two main signals are the clock, SMBCLK, and data, SMBDAT. While similar to the I2C bus, there are some notable differences:
- The SMBus logic level thresholds are fixed and not proportional to a device’s supply voltage. This allows devices with different supply voltages to operate on the same bus. For example, one SMBus might have devices powered from 1.8V, 3.3V and 5V.
- The SMBus provides for a minimum clock speed and limits the amount the clock may be stretched in one transaction. A violation of the timeout limits causes all SMBus devices to reset their I/O logic to allow the bus to restart. This enhances the robustness of the bus.
- It is an explicit requirement that a SMBus device must acknowledge (ACK) its own address every time it is received, regardless of what else the device may be doing. This assures that a controller device can accurately determine what devices are active on the bus.
- All SMBus transactions are carried out through one of the specified SMBus protocols.
- The SMBus includes an optional signal, SMBALERT#, that target devices can use to quickly notify the controller or system host that it has information for the controller, such as reporting a fault condition.
A detailed discussion of the differences between the SMBus and the I2C bus is given in “Appendix B. Differences between SMBus and I2C” of the SMBus 3.0 specification.
How do I get the SMBus specification?
The SMBus specifications are available from the System Management Bus (SMBus) web site, http://smbus.org/.
What is required to be compliant to the SMBus specification?
The SMBus specification does not give specific criteria for compliance. However, to be compliant a device must meet the requirements given in the specification, including but not limited to:
- Electrical interface,
- Timing, and
- Proper operation with all supported SMBus protocols.
How do I get my product certified as compliant to the SMBus specification?
At this time, device manufacturers must self-certify that their devices are compliant to the SMBus specification.
General / Other
Who or what is the System Management Interface Forum (SMIF)?
The System Management Interface Forum (SMIF), Inc., is a non-profit corporation that supports the rapid advancement of an efficient and compatible technology base that promotes power management and systems technology implementations. The group’s activities include: promoting global development of communications protocols; identification of appropriate applications; providing global educational services; promoting worldwide compatibility and interoperability; and identifying, selecting, augmenting as appropriate, and publishing specifications. SMIF provides a membership path for any company or individual to be active participants in any or all of the various working groups established by the implementers forums. SMIF is currently responsible for the Smart Battery System (SBS), System Management Bus (SMBus), and Power Management Bus (PMBus) protocols.
Are there any royalties, license fees, or other costs for using the PMBus?
Commercial users of the PMBus trademarks must be PMBus adopters; that is, they must be members of the System Management Interface Forum (SMIF) in good standing and must have signed the PMBus adopters agreement. Commercial use includes, but is not limited to, using the term PMBus, AVSBus, or any PMBus or AVSBus logo on a company’s web site, or using the term PMBus, AVSBus, or any PMBus or AVSBus logo on commercial literature such as product briefs, data sheets, application notes, or sales quotations.
The fee for membership in the SMIF is 3900 US Dollars. (Membership fees are subject to change.)
There are no other fees for using PMBus or PMBus trademarks in a commercial application.
PMBus trademarks may be freely used in non-commercial applications.
We are developing PMBus-based products. Are there patents to be aware of?
The SMIF organization takes no position on the existence or applicability of any patent or its licenses. Patents may exist and users should do due diligence. Multiple PMBus adopters provide solutions. Please refer to your vendor of choice for their statement regarding these matters.
Is there a list of royalty-free patents of PMBus?
Per the PMBus adopters agreement, “necessary claims” (claims essential to implement the specification) in patents owned by PMBus adopters are automatically licensed to all PMBus adopters royalty-free. There is no list of such patents or claims, nor have we determined what claims of what patents are necessary.