Many Digital Power products use the industry standard PMBus to enable system architects to manage and control multi-rail power architectures. However, many people are uncertain how to apply PMBus to solve real world problems. Over the course of the coming months I am going to blog on different topics related to the practical aspects of architecting and integrating Digital Power Management products. I will address such topics as:

• PMBus
• Use models
• Power Sequencing
• Fault Handling Tools
• Embedded Software
• Architecture Device Types
• System Debug 

There are plenty of blogs and articles that will tout the virtues of Digital Power in the abstract. Those that have read my blog know that I like to get my hands dirty with stuff that really works. So you can expect more of the same here. If I talk software, expect code. If I talk hardware, expect schematics. If you want more of those than I post, ask.

I’ll kick off the series with a quick review of PMBus for those that are not initiated, and the main use models I see engineers using. Over time I’ll dig deeper and deeper until there are sufficient exemplars that will get anyone to get started on their own.

PMBus

Most people think of PMBus as I²C bus with some extra stuff, often not fully aware of what the extra stuff is. In fact, many designers treat PMBus like I²C and don’t realize all its benefits.

PMBus is an extension of SMBus, which is an extension of I²C. So let’s start with I²C.

I²C (Inter-IC)

I²C is nothing more than a serial bus with a couple of signals: CLOCK, DATA. It is bidirectional and multi-master. I²C dates all the way back to 1982 and has gone through 4 revisions. In 1992 the official 1.0 was releasde. In 1998 version 2.0 was released and the revision quite boldly proclaims:

The I²C-bus has become a de facto world standard that is now implemented in over 1000 different ICs and licensed to more than 50 companies. Many of today’s applications, however, require higher bus speeds and lower supply voltages. This updated version of the I²C-bus specification meets those requirements.

Then in 2007 version 3.0 defined 1Mbit/s clock rate. And in 2012 clocks were pushed to 5Mbit/s.

Note: If you are not familiar with the details of the higher bit rates, you have to be careful with assumptions. Higher bit rates do not necessarily imply low latency. To make the higher bit rates work on a bus with slower devices, the arbitration has to occur at the slower bit rate of 400Kbits/s before it can kick into high speed transfer mode.

SMBus (System Management Bus)

SMBus 1.1 was created in 1998. The relationship with I²C is described in Section 1.1:

The System Management Bus (SMBus) is a two-wire interface through which simple system and power management related chips can communicate with the rest of the system. It is based on the principals of operation of I²C.

SMBus provides a control bus for system and power management related tasks. A system using SMBus passes messages to and from devices instead of tripping individual control lines. Removing the individual control lines reduces pin count. Accepting messages ensures future expandability.

And a most important point is made in Section 1.3:

The SMBCLK and SMBDATA pins are similar to the clock and data pins found on an I²C bus. The SMBus electrical characteristics differ from those of I²C.

Similar, but different. Basically, don’t over assume. Read the SMBus spec. For example, electrical levels are different.

PMBus added some features to make it more robust, such as:

• Packet Error Checking (PEC)
• Alert
• Timeout

PEC guarantees data integrity, alert interrupts a host controller when a device requires service, and timeout prevents the bus from an hanging. All very important in multi-device systems.

SMBus 2.0 released in 2000 and added a few more things:

• Host notify protocol
• Address resolution protocol

PMBus (Power System Management Protocol)

PMBus revision 1.0 released in 2005, and 1.2 released in 2008, so this is a fairly new protocol. PMBus is similar to SMBus, in fact it uses part of the SMBus spec as its base. The Transport Layer of PMBus is SMBus 1.1 with extensions and exceptions.

Extensions:

• Block Write-Block Read Process Call

• Host Notify Protocol Group Command
• Protocol Extended Command
• Bus Speed 400Khz with timing modifications
• Electrical drive levels

Exceptions:

• Block write/read up to 255 data bytes

Now we add on to that a command language for setting voltages, currents, timing, and fault management. Finally, on top of the command language are application protocols.

And we wonder why engineers struggle with how to use PMBus!

Complexity

SMBus 1.1 is 39 pages. PMBus 1.2 is 125 pages. And on top of that, manufacturers add their own special registers and functionality with 100+ page specs.

So how does one deal with all this complexity? Well, basically with tools and reuse. And of course the specs, which you can find at: System Management Interface Forum

Use Models

I’ll propose two major use models, there are probably others, but these are the main two I see used a lot:

• Configure and Deploy
• Monitor and Act

One of the most important PMBus command sets are for storing and restoring settings between operational memory and non-volatile memory. When combined with commands for changing operational memory (behavior), they support the Configure and Deploy use model.

Configure and Deploy

Most manufacturers of PMBus products have a GUI tool that can communicate with their products via the PMBus and a dongle. In most cases, the dongle connects to a host PC via USB. The fundamental use pattern is to configure all the registers of the PMBus devices on a bus and store their values in non-volatile memory. Then when the system is powered or reset, all devices load operational memory from non-volatile memory during startup.

The fundamental strength of this model is its simplicity. Tools can absorb much of the PMBus complexity by organization of data, templates, and project reuse. A secondary advantage is lower cost because no “extra” devices are required to manage the bus.

The fundamental weakness of this model is the forfeiture of all the capability of the PMBus during normal operation. During abnormal conditions, such as faulting, all the devices must react autonomously, but the flexibility is limited, and not coordinated. The same is true at reset. All devices must startup autonomously.

Let’s consider some of the limitations this imposes. Suppose a power architecture has 12 rails of POL (Point of Load) converters operating off of an IBC (Intermediate Bus Controller). POL 1 has an OC (Over Current) fault, and the fault response is to shut down the rail. Without any host controller on the bus to react to the fault, the other rails will continue to operate unless the OC of POL 1 causes a fault on another rail through the load.

To overcome these limitations, many devices have additional IO pins that allow devices to communicate between them without PMBus. A classic approach is to use open-drain signals between devices. Typically, there are three pins:

• SYNC
• RUN
• GPIO

The sync pin is used to establish a common time-base at reset. This allows accurate time corrleation for sequencing on/off events. The run pin allows all devices to reset at the same time, either from an external gate, or from the devices themselves. GPIO is typically a fault output and fault input. This allows a fault from one device to propagate to other devices. These pins are not part of the PMBus specification, but are very necessary for the Configure and Deploy use model to work as a system.

Monitor and Act

The most flexible use model requires a PMBus host that is active during the operation of the system. With full access to the complete command set, the system is only limited by the speed of the PMBus and your imagination.

There are several sub-models for building a PMBus host. A micro-processor or micro-controller, FPGA logic, or a controller embedded in a FPGA. Typically, it is a controller of some sort, even if in an FPGA. It is just easier to implement, and more flexible.

The Alert Pin is normally connected to an interrupt pin on the controller. When there is a fault, the uP reacts to the interrupt by getting the address of the faulted device, querying conditions via PMBus, and taking action to correct the problem or to power down rails.

The controller is also used for telemetry. The data may be used to predict failure, measure power consumption, or for debugging rare faults. The controller will also setup all the rails at reset.

The ultimate value of this use model is flexibility. However, there is a price to be paid: development time/cost and more hardware. The development cost can be somewhat mitigated via reusable frameworks, but there is no way around the extra hardware cost.

Hybrid Models

From my experience, there are a lot of engineers using the Configure and Deploy Model, and a smaller number using the Monitor and Act. When the latter is used, it is rarely used in its pure form. It is far more typical to handle the bulk of the configuring with tools by ensuring that a dongle and host are compatible, and only using the PMBus host for telemetry, high level fault handling, and end user notification.

This division of labor also allows some control over policy and safety decisions. The power engineer can control the rail voltages, startup timing, and primary fault responses via a tool. And via rules on allowed commands issued by the PMBus host, the embedded software designer is constrained to a safe set of telemetry functions and logging of unusual conditions that aid debug.

Ultimate Decisions

Making decisions about use-models is not simple. Often, it is not until after you have designed your first Digital Power Architecture that you really know what you should have done. Hopefully, with this blog series these decisions will become easier, and you can even prototype your architecture before the final design, given resources I make available.

If you have topics you would like to see covered, just send me an e-mail and I’ll do my best to cover them.