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
