feature article
Subscribe Now

Keeping Power Under Control

A Brief Look at PMbus

Nothing should be simpler than turning the power on and off. It’s just a switch. Switch it on; switch it off. Easy peasey. Right?

Well, not so fast. There ain’t just one power supply on a board anymore. These days you’ve gotta have in place a veritable cornucopia of power levels to satisfy all the finicky chips that are spreading like a bad mold across your boards. And the different power lines have different capacitances and different drivers, so that simply shutting the power down can conjure up images of leaves floating to the ground: a bunch of individual lines, all drifting down in their own sweet time, with little predictability as to which will reach the ground first. And turning the power on can be the equivalent of the dude with the blower; leaves fly up in the air willy nilly.

OK, perhaps that’s somewhat overstated, but only by a matter of degree. It’s gotten harder and harder to manage power. Which supplies have to go in which order? And how fast can they ramp? How do you handle variations in supply or adjustments needed on a given board? What if you go over voltage? What if the temperature gets too high? Should you lower the voltage? Turn on some fans? Send an alarm? What if a fan isn’t working or shuts down?

None of these questions gets a satisfying answer from a simple on/off switch. Power management attempts to wrangle these and other questions, although if each manufacturer comes up with a different answer, that still doesn’t feel particularly satisfying. Which is why the PMbus standard was created.

PMbus builds on the SMbus, which is itself something of a modification to the simpler I2C bus. SMbus was intended for PC and server management, and PMbus took it a step further in targeting power management specifically. PMbus first came out in 2005 and, like SMbus, has also largely been focused on servers, but it’s increasingly being explored in embedded systems as power requirements get nastier. Several presentations at this summer’s Embedded Power Conference were aimed at familiarizing embedded engineers with this way of getting control over power in a manner that can ultimately be handled by software.

PMbus isn’t meant to talk to the actual functional chips on a board: it’s for talking to the power converters and fans and such that power the chips and keep the temperature in line. It is also specifically set up for a host to have a conversation with converters, but not for converters to have conversations with each other – that’s still handled in a manufacturer-specific manner.

It looks like a fair bit of effort was made to keep requirements for PMbus from getting out of hand. There are lots of options and little that’s outright required. That puts a bit more work on the designer, since he or she has to get familiar with the specific features of each PMbus-compliant device, but this doesn’t sound like a particularly onerous task (especially as compared to the cost of either requiring more features or building in feature-support negotiation – ack!). Manufacturers also get a lot of flexibility on how they handle some of the features.

It’s easy to think of PMbus on three levels: the physical, the command format, and the command set. At the physical level, it can be implemented with as few as two wires (inherited from I2C): clock and data. There’s an additional optional alarm signal inherited from SMbus that you can use for interrupting a host; this can give faster response to critical events than you could get if polling were the only way of figuring out what was going on. There’s a new optional control signal that makes it possible to turn on or off converters using software, and there’s an optional write-protect pin in case you want to protect against changes. You also have to give an address for each device on the bus, and how you set that address is left to manufacturers. Some devices may have tri-state pins for a digital address; some may have a single pin for resistor programming. Some of the address bits may even be hard-coded by the manufacturer.

The command structure is pretty straightforward. Each command is a packet that’s got a command code followed by data. The amount of data depends on the command. The packet starts with a “start” signal and ends with a “stop” signal. An optional 8-bit CRC, which is called the packet error correction, or PEC, byte, can follow the data. There’s no explicit “execute” command; execution starts as soon as the “stop” signal is received.

With all this in place, PMbus then defines a bunch of commands very specifically aimed at different things you might want to do with power or fans. Some of them set up values – and these can be actual supply levels as well as margin values for testing, or things like trim (board-specific) or calibration (converter-specific) values. You can specify the timing of power-on and power-off sequences. Commands can also be used to get values back out of a device (the only thing that would be possible if the device was write-protected). There’s no requirement that any specific commands be supported; you’ve got to read the manual for each device to be sure. 45 commands are even reserved as manufacturer-specific: each maker of devices can come up with commands that are unique to their devices.

During power-up, there’s a way of setting up values with defaults to make sure that nothing is left undefined. The device itself may have some defaults, which are loaded up first, but which may then be overwritten by any pin-programmed values. You can also have a default non-volatile store, which would be loaded next, again overwriting anything already in place, as well as a user non-volatile store within which you can store the last state of the system for restoration after power sequencing. Finally, the host can issue new commands to replace any of the values loaded in any of the previous loads.

There’s also a built-in system of alerts that provides a number of things you can do when an alert occurs, including doing nothing, restarting the device, and inhibiting the device. You can check out the status of any device, including warnings that might not actually trigger an interrupt, through the status byte (critical alarm stuff) or status word (other stuff), as well as through a series of more specific status registers. There are also a number of registers that can provide information about the device and the manufacturer and a space for application-specific stuff that you can create.

Support for PMbus on devices continues to grow, though the pace seems a bit modest. A number of application notes and reference boards are available; these kits often contain code for implementing PMbus drivers. It’s typical that the manufacturers provide their own driver code since there are so many things that end up being manufacturer-specific.

There is a whiff of a suggestion that a cloud might lie over all this, however. Artesyn (now owned by Emerson) was one of the initial drivers of PMbus and released some early devices supporting aspects of it. They were challenged by Power-One, who alleged that Artesyn had infringed some patents. Late last year, a jury apparently agreed on one of them, and it’s not clear whether it really impacts PMbus. There’s no mention of this on the System Management Interface Forum’s website (SM-IF “owns” the PMbus standard), and a request for the official position on the impact, if any, of this lawsuit on PMbus got no response, so the only information easily available is the little tiny bit of buzz around this on the internet; we all know how reliable that might be.

Devices do still appear to be available, business does seem to be moving forward, and the PMbus presentations at the Embedded Power Conference did come after the verdict. So, judging by behavior, one would guess that, for whatever reason, the verdict has no impact. Power-One doesn’t appear to have raised any kind of a post-victory issue, so this may be much ado about nothing.

Assuming it’s all in the clear, PMbus does look like the basis for a much greater level of power sophistication, control, and monitoring than ad hoc methods have allowed. There is obviously some cost involved in implementing the standard, but it’s clear that minimizing that cost has been a goal in setting out the required elements. And it pushes more of the functionality up into the realm of software by putting in place a hardware infrastructure that can then be programmed, giving you a much higher level of flexibility, both in re-using designs and in making improvements through firmware changes instead of hardware changes.

Links: PMbus

Leave a Reply

featured blogs
Jan 27, 2023
Wow, it's already the last Friday in January, so time for one of my monthly update posts where I cover anything that doesn't justify its own full post or which is an update to something I wrote about earlier. Automotive Security I have written about automotive secur...
Jan 26, 2023
By Slava Zhuchenya Software migration can be a dreaded endeavor, especially for electronic design automation (EDA) tools that design companies… ...
Jan 24, 2023
We explain embedded magnetoresistive random access memory (eMRAM) and its low-power SoC design applications as a non-volatile memory alternative to SRAM & Flash. The post Why Embedded MRAMs Are the Future for Advanced-Node SoCs appeared first on From Silicon To Software...
Jan 19, 2023
Are you having problems adjusting your watch strap or swapping out your watch battery? If so, I am the bearer of glad tidings....

featured video

Synopsys 224G & 112G Ethernet PHY IP OIF Interop at ECOC 2022

Sponsored by Synopsys

This Featured Video shows four demonstrations of the Synopsys 224G and 112G Ethernet PHY IP long and medium reach performance, interoperating with third-party channels and SerDes.

Learn More

featured chalk talk

HARTING's HAN® 1A Connector Series

Sponsored by Mouser Electronics and HARTING

There is a big push in the electronics industry today to make our designs smaller and more modular. One way we can help solve these design challenges is with the choice of connector we select for our designs. In this episode of Chalk Talk, Goda Inokaityte from HARTING and Amelia Dalton examine the role that miniaturized connectivity plays in the future of electronic design. They also how HARTING's Han 1A connectors can help reduce errors in installation, improve serviceability and increase modularity in your next design.

Click here for more information about HARTING Han® 1A Heavy Duty Power Connectors