[Digital Power Series Articles] Digital Power Sequencing

Building blocks of power conversion

Let's look at our power building blocks and tools and see what kind of trouble we can get ourselves into. For simplicity, we assume we have a Universal Power Building Block (UPB) and all the usual troublemakers (FPGAs and microcontrollers, logic, etc.). Our UPB has a simple interface:

Figure 1: Power supply building blocks.

Our simple power converter has a single VIN/VOUT, a PMBus interface, an input signal (CONTROL), and two output signals (POWER GOOD and FAULT/).

CONTROL

The CONTROL signal turns the output on and off. It is active high and has an internal pull-up resistor.

POWER GOOD

The POWER GOOD signal is high when the output is powered on and it is within the valid range.

FAULT/

The FAULT/ signal is active low, open drain, and is asserted when the power component has some fault. If there is some fault, ALERT/ is asserted, and the fault information can be read through the PMBus. Not all power converters will have a POWER GOOD and a FAULT/, we don't need both. In almost every case, FAULT/ can be used as a "stand-in" for POWER GOOD.

Design Scheme 1

Now let's design a solution so that we can break it down and design another solution, doing it better each time.

Assume we have a system with an intermediate bus controller (IBC) and the following power rails: 48V, 19V, 5.0V, 3.3V, 1.2V, 0.8V.

We decided to structure these power rails as a hierarchy. However, we needed a different control structure for powering up.

Figure 2: Simple power supply architecture.

For actual design, don't worry about whether the power hierarchy or logic is correct. What matters is the impact of this "type" of structure. Let's examine its advantages and disadvantages.

On the plus side, it is simple both in principle and in implementation. It would be easy to add an LED indicator or to use an FPGA or microprocessor's GPIO to read the power good information. If a fault condition occurs, POWER GOOD will let the system know that a power rail has failed.

On the bad side, if there is some fault, and if the system must shut down all the supplies, they must be shut down one by one in the same order in which they were powered up (no choice). This means that the rail furthest downstream will be powered down by loss of power, rather than by its control pin.

Since there is no timing control, additional circuitry will have to be added to place a delay between the rails. If a delay is added between the rails, the delay will only apply to power-up, because power on one feeding rail will be lost on power-down, thus shutting down the rail it depends on before the POWER GOOD signal can shut it down.

With this “type” of structure, if you make any mistakes, you will have to re-layout the PCB, and while you wait, you will be forced to modify the wires in the design (no choice), or “enjoy” a long break.

Design Plan 2

We can do better if we centralize the logic circuits. One programmable device (such as FPGA or microprocessor) can manage all the logic circuits.

By routing all the logic to the GPIOs, the controller has full control over the sequencing order (turning on and off) and timing. This can be changed at any time if you want to change the Verilog or C code. I have already labeled the PMBus on the controller (but not all the wiring), and using the PMBus, the controller can now also control the levels and fault behavior characteristics.

Figure 3: Power supply structure using controller.

On the plus side, the design is flexible and you won't get stuck in a rut. If you make a mistake in the control structure, you can fix it without having to re-layout it.

On the downside, you have to change Verilog or C, and the firmware may need to be retested and requalified. In addition, this design requires a lot of wiring. Each POL requires 5 control lines, and they are routed individually to the controller. Assuming we have a 20-rail system, we will need 42 GPIO pins due to PMBus.

Therefore, although this design is flexible, it requires a lot of GPIOs and occupies a lot of PCB area resources.

Design three

When combined with PMBus and intelligent digital power POLs, we can use the characteristics of open-drain control to simplify the controller.

All CONTROL pins are connected together, and all FAULT/ pins are connected together. This means that a 20-rail system only requires 5 wires, reducing the number of IO pins by 8 times.

Figure 4: Simplified controller.

Let's see how this works. The CONTROL pin is active high. It is controlled by GPIO0 (which is set to "open drain"). Since the CONTROL pin is open drain, this means that POL can also pull it low.

When a POL is reset, it will pull the CONTROL pin low until it is ready to respond to an external signal. This means that if the controller is too fast, none of the POLs will turn on (until they are all properly reset), and when the system powers up depends on the slowest POL to reset. If the controller is slow, it is responsible for controlling the power-up when it releases the CONTROL line.

You may be confused about the sequencing. Have we lost control of it? No, we have not, because PMBus has a TON_DELAY command and its value is usually stored in the non-volatile memory (NVM) of the POL. It can be set by the controller or stored in the NVM using an external tool.

The FAULT/ pins are also open drain and controlled by GPIO1, and they are both inputs and outputs. This means that when any power rail fails, all power rails will be notified when the FAULT pin is pulled low. Also, when FAULT/ is pulled low, ALERT/ is asserted. So the controller knows that there is some kind of fault. As you all know, this is the key to this design.

Now, you have a few options for fault handling. PMBus can respond to ALERT/ with an Alert Response Address (ARA), which gets the address of all POLs with a certain fault, and then polls each POL for fault information. It can then use a decision tree and shut down the rails in any order as needed. Or, it can shut down all rails at once and let the PMBus TOFF_DELAY manage the timing.

Many POLs have enhanced fault management features and can respond directly to faults (remember that FAULT/ is also an input). Typical responses are:

• Retry

• Immediate shutdown

• Ramp off

When the POL has these advanced features, the workload of Verilog or C code is greatly reduced because the POL can be programmed using an external tool (through PMBus and external interface and software). In addition, when the FAULT/ pin is used, the response speed to the fault is much faster than the response speed of handling ALERT/.

Design Option 3 Trade-offs

With enhanced POLs, you can make tradeoffs. If the fault logic is too complex for the shared FAULT/ line, just add a controller. If the fault logic is simple, you can use a tool to configure the fault behavior and not use a controller. Alternatively, you can use a controller for remote sensing and other functions, but use the FAULT/ pin to perform fault handling. And if you find that it can't handle all fault conditions, you can always add code for fault handling and change it. A similar tradeoff is made for the CONTROL pin. You can also use PMBus instead. In this case, the CONTROL pin will still delay turning on until all POLs have reset.

The greatest flexibility is achieved when the CONTROL and FAULT pins are shared and there is a controller for the PMBus. With this design, full flexibility is possible after the PCB is fabricated.

Power Good

In case you didn't notice, I didn't use POWER GOOD. You don't need to know when a rail is good before turning on another rail. If all rails are controlled by TON_DELAY and one doesn't get ready in time, a fault will occur. PMBus specifies TON_MAX_FAULT_LIMIT, which limits how long a rail must take to ramp up and get into tolerance. If a rail is not in specification by this time, a fault will occur, preventing the other rails from turning on.

The design principle is: no news is good news. If the system needs to know when all power rails are powered up, a simple timer can be set to the maximum time specified by all TON_DELAYs. Alternatively, the controller can perform a PMBus query of the status of the last POL.

In some devices, the FAULT/ pin can be reconfigured as a POWER GOOD pin. This allows you to have POWER GOOD when you really need it, but you lose the fault sharing pin. Then you might want to have a controller that responds to ALERT/. Or, in simpler systems, ALERT/ might take over the functionality of the CONTROL pin and shut down all power rails when some fault occurs.

In practice, POWER GOOD is usually not essential. However, if you really need it, you can usually resort to reconfiguring FAULT/. After all, there are always special cases. Perhaps there is always room for that "Universal Adapter Kit".

Let’s review

Here is a brief overview to help readers who jump directly to the end quickly understand the main points of this article:

The first design uses a principle I call "sequencing of events." The POWER GOOD pin is connected to the CONTROL pin of the next POL. But there is no configurability and control over the fault behavior characteristics. The second design uses a controller and puts all the sequencing at its command, but it uses a lot of GPIOs, so you are forced to let the controller do all the work. The third design uses open-drain pins to share CONTROL and FAULT/ and provides an optional controller. This design has a lot of flexibility, a low GPIO pin count, and simple wiring. This is the most popular design approach when the main tradeoff is the decision about the controller. More on this tradeoff in a future article. There is nothing wrong with design one and design two as long as you understand and adapt to their limitations. But we all know that when unexpected problems arise during system qualification, the rules of the game suddenly change. Even if you don't think you need design three, it is still a very good insurance policy. All I can say is: if I were a power engineer and I had a large team of engineers relying on my design, I would definitely not want to be in trouble if something went wrong. I thought if I delayed the launch of a product, they wouldn't be too happy.