PMBus 2.0 expanding PMBus for future system needs: Virtual Interview, part 2 of 2

We are here today with Bob White, the PMBus power management protocol’s originator, long time chair of the PMBus specification working group, and current editor of the PMBus and SMBus specifications. Bob is the principal author of the PMBus specifications and continues to participate in the PMBus Specification Working Group. He is a well-known speaker and author who regularly presents papers and seminars at conferences such as the IEEE Applied Power Electronics Conference (IEEE APEC).  In part one of this virtual interview, Bob reviewed updates under development for the current PMBus 1.4 specification. In part 2, Bob looks into the future and the developments anticipated for PMBus 2.0. The following is from an interview with Bob by EEWorld’s Jeff Shepard.

JS: If revision 1.4 is the end of the road for the current generation of PMBus specifications, what comes next?

BW: Jeff, the working group has outlined a vision for PMBus 2.0, but at this time, it is still very much a work in progress.

One key change planned is that AVSBus 2.0 will be released as its own specification. While it will remain linked to the PMBus specifications, it will be free to evolve according to its own needs. For example, the existing AVSBus is a point-to-point protocol linking one controller with one target device. AVSBus 2.0 will have one controller with multiple target devices. The AVSBus user community has frequently requested this functionality.

As for PMBus 2.0, one of the visions of the original PMBus working group was that the PMBus command language would be adapted to run over other physical interfaces than SMBus. Some early work was done to run PMBus over the PS-485 interface, but that work stalled and was never completed.

The vision for PMBus 2.0 is to have a common command language that is run over different buses and interfaces. In addition to today’s PMBus over SMBus, the working group is actively looking at running PMBus over interfaces like standard serial buses (RS-232, RS-485), SPI, CAN bus, Ethernet, and even USB. We have talked about PMBus over wireless protocols such as Bluetooth, but for the moment, PMBus over wireless interfaces will be a future project.

JS: Are there any special challenges to running PMBus over so many different buses and interfaces?

BW: There are two challenges of note. The first is data formats. Although all digital data is communicated in bytes, there is a wide variation of native data width from 8 bit to 32 bits to 64 bits and in the future 128 bits or more. The question is, how do we write a command language that can readily adapt to communicating commands and data to the various native data bit widths.

The second challenge is the basic difference in communication between interfaces like SMBus and Ethernet. Interfaces like SMBus are what I call “transaction” based. A controller starts communication with a target device, sends commands and perhaps data, perhaps it receives data, and then it closes the communication.  Everything, commands, and the exchange of data happen in one transaction. When the transaction is complete, the controller knows that the target has received the command and the data transmission is complete. The bandwidth (bit rate) of such interfaces tend to be slow by today’s standards – megabits per second – but there is no delay (latency) in the communication.

Other interfaces, like CAN bus and Ethernet, are message based.  In this case, the controller assembles the command and any associated data, creates a message packet, and launches that message onto the bus. The controller does not know when, or even if, the intended target receives the message. If the message is received successfully, the target may send a return message acknowledging receipt of the original message, confirming the command was executed without error, and return any requested data. Again, the target does not know when or if the controller receives the message. Here the bandwidth can be very high – gigabits per second – but the latency is unknown.

Structuring PMBus 2.0 to work well with these variations in data width and message transport (transaction versus message) will require some care.

JS: Are there any other activities of the PMBus working group that EEWorld readers should know about?

BW: Another vision of the original PMBus working group was that major OEMs would create subsets of the PMBus specification particular to their needs. That never really happened, but there was a need for subsets of the PMBus specification adapted to specific applications.

These subsets are called application profiles. There is an effort underway now to develop an application profile that defines a standard subset of the PMBus specifications for non-server ac-dc front end power supplies, like those used in industrial or general-purpose computing applications. That work is proceeding a bit slowly as the committee members are quite busy with their day jobs. It is important to keep in mind that all PMBus working groups and specification activities are carried out by volunteers. The time they can commit to the PMBus varies depending on the need of their employers.

The PMBus working group has also long recognized the need for a standard file format that could be used to program PMBus devices in a production environment. The idea is to have a programmer, which could be anything from a PC running Windows to a Raspberry Pi running embedded Linux to a dedicated microcontroller that connects to PMBus devices that need programming. These PMBus devices could be point-of-load converters on a PCB or front end power supplies. The PMBus commands needed to configure these PMBus devices are then put into a standard format file that can be read by the programmer. The programmer interprets the file and then sends the commands to the devices to be programmed. The programming file could also include commands that would read back the programmed information to confirm the devices were properly programmed.

As for the programming file, the working group has discussed formats like JSON and a markup language like XML. The current thinking is that this file will be in the YAML (Yet Another Markup Language) file format.

As this work has progressed, the purpose has evolved a bit. Aside from just being used by a standalone programmer, there is interest in making this file usable by on board controllers (like baseboard management controllers (BMCs) in servers) to program or update PMBus devices in their systems. The working group is looking at the efforts of groups like Redfish and OpenBMC to make sure the PMBus file format will be usable in those environments. This work is ongoing.

JS: It sounds like the PMBus group has a lot going on.  If someone is interested in volunteering and contributing, how can they get involved?

BW: Jeff, you are right that a lot is going on. Aside from generally participating in the development of the PMBus specifications, specific areas where help is needed include defining the PMBus 2.0 protocols for various interfaces like CAN bus, USB, and Ethernet. Another area where help would be appreciated is the development of the standard PMBus programming file format, including those with production programming experience or those who are knowledgeable in OpenBMC and Redfish to make sure the standard PMBus programming file format can be used in those environments.

Those who are interested and have the time to volunteer should send their name, contact information, and areas of interest to questions@smiforum.org.

JS: Bob, thank you for taking time today to update the EEworld readers on the latest developments in PMBus.

BW: Jeff, thank you for the opportunity.

JS: Be sure to check out part one of this virtual interview, “PMBus® 1.4 update, what changes lie ahead?”

About Bob White

Bob has more than 30 years of experience designing power supplies, dc-dc converters, and power systems for electronic equipment.  Currently, Bob is President and Chief Engineer of Embedded Power Labs, a consulting and design services company.  He has held managerial and individual contributor positions in product development, technology development, systems and applications engineering, and technical marketing.  He has previously been employed by companies such as Emerson Electric, Artesyn Technologies, AT&T Power Systems/Bell Laboratories, and the Digital Equipment Corporation.

Bob has a BSEE from MIT (1980) and an MSEE from the Worcester Polytechnic Institute (1991).  He is currently pursuing a Ph.D. at the University of Colorado – Boulder under Professor Robert Erickson’s direction.  He is a Fellow of the IEEE.