What about DC Power Integrity? – Part 1

What about DC Power Integrity? – Part 1

Feature articles |
By eeNews Europe

When I first learned to design digital electronics and layout a PCB, I was taught to put all the 74-series chips and the microprocessor in neat rows, and the rule of thumb was to add a single 0.1 µF ceramic capacitor for decoupling to each device, and sometimes adding an additional 1 µF tantalum or electrolytic for the micros in parallel. I never worried too much about getting power to each device – using a 20 or 30 mil trace was enough for a chip that never drew more than 100 mA, along with the classic interdigitated +5V/GND “grid”. Of course, power electronic designs are a whole different ball game. And I always took a lot more time, care and planning with power supply and amplifier designs – making sure to use proper (star) grounding and keeping high-current loops as tight as possible.

Some of this was more than 20 years ago now, and of course there has been a lot of development in the decoupling and power network topic since then. More elaborate and carefully placed decoupling schemes have to be designed for each new silicon process node, each new chip package generation and for each new PCB design as they become more densely packed with parts than ever. It’s getting difficult to find room for all the “rule of thumb” decoupling caps! And with BGA packaged devices down to 0.4 mm pitch, that meanwhile draw several amps of current during use, it’s getting really difficult to plan and design a good power network on the PCB. Whether we like it or not, Power Integrity is a challenge that all PCB designers and engineers have to address.

Power Integrity is talked about a lot these days. But a lot of the talk is really on the signal integrity side – I call it AC power integrity, which is really about the impedances of the power network at high frequencies. This deals with how the decoupling is designed as well as return paths for high-speed signals. While it is non-trivial, I don’t want to simply regurgitate this already very commonly discussed topic. I want to get down to DC… why? Well, it just seems to me that learning to walk before trying to run is a good idea. So let’s talk DC Power Integrity.

At face value, it seems to be a simple enough topic – you just need to make sure there’s enough copper to get the necessary current to each device on the board. But that’s just at face value. When you start to work with fine-pitch device packages, manufacturing constraints and power requirements of said devices are almost completely at odds. Not only is it difficult to get the current needed to all the power pins, but you are also working with multiple supply voltages. This means that unless you want a high-layer-count PCB, you are going to have to get power to your devices through various split planes, and that’s just where the trouble begins.

But before I go too far down into the rabbit hole of designing the power distribution networks, how can you tell if you even have a power integrity problem? Power Integrity issues are sneaky little creatures. Like cockroaches that rapidly scamper into the crevices when the light turns on – the moment you try looking for these issues is the moment they can’t easily be reproduced. But you may have a power integrity issue if any of the following symptoms occur to your assemblies:

1. The CPU is resetting unexpectedly, or when a high-utilisation thread enters execution.

2. Memory devices keep failing content retention / corruption tests.

3. Analogue front-end circuits are randomly inaccurate or out of design specs.

4. CPU or FPGA devices fail catastrophically.

5. FPGA configurations are corrupted during power up.

6. PCB vias go open-circuit after a period of use cycles or maybe even at first power on.

7. Production PCBs suffer blistering in the common locations.

8. PCBs suffer delamination in common locations.

9. Trace or polygon neckdowns are fusing.

10. Discolouration of laminate or solder mask material in some regions of the PCB.

These symptoms fall into two broad categories of DC Power Integrity problems. For example, items 1 through 5 are the more sinister misbehaviours caused by transient voltage drops across the board. Sometimes they can be fixed with better decoupling but when talking DC, really, more copper will improve the design. Items 6 through 10 are more serious power integrity issues where current density regularly exceeds the safe limits for temperature rise and the board is suffering from localised heating, or copper is outright fusing.

There are some useful tools for avoiding these sorts of problems before prototype; for example the IPC-2152 conductor sizing charts. I would say it’s a must that every design begins with these charts as the basis for power network design rules for the PCB layout. However, there are designs that now approach a part density that make it necessary to design “on the edge” and work with means (that is, average values) and duty cycles to make sure the board doesn’t fail.

So, DC Power Integrity is the concern over making sure that each device in the design gets the power it needs, without suffering the problems mentioned, all while ensuring a reliable power network on the PCB.

Design with PI in mind

A great question to answer though, is what is a good starting point for designing with PI in mind?

While there are well established “best practices” in designing with power in mind, I still see quite a large number of designs where the power distribution on the PCB is basically copied from a chip manufacturer’s reference design. Often, this is done without a lot of concern for the customised nature of the product itself. The difficulties with this approach are that:

– It’s awfully tempting when you’re “under the gun” to finish a design, to simply copy the power supply from reference design material.

– It places a large and sometimes unwarranted trust in the applications engineer who did the reference design (in a sense it is flattering, but also a bit naive).

– Your use of their product is never going to be exactly the same as their reference design.

– Reference design boards tend to be large, simple designs which are simply intended to show how to use a specific device.

– Your design will most likely include use the “device of interest” along with myriad other systems vying for power.

– Your board, more likely than not, will be much more constrained for size and layer count.

Reference designs from chip makers do serve as a decent starting point. However the wise thing to do is establish your own power budget based on how you intend your product to be used.

Finding the current draw

First, you can find the worst case (or maximum) current draw required. If you design based on this information, almost certainly the product will be very robust from a DC power point of view, but may be too large and costly – due to the extra copper and space required. Many would consider this the “over-engineered” approach.

With the worst-case power needs established, you can take into consideration the use-case of the parts in the design to figure out a more optimised solution. Luckily good component manufacturers with high-quality data sheets provide the extra information needed to estimate this, but there are a few tricks and even some tools that allow you to get a clearer view of the nominal and peak current requirements. There are trade-offs that can be made here, for example running the CPU at half the clock speed can halve the power requirements for the CPU.

Just for fun, I want to compare the consumption requirements of a couple of roughly equivalent ARM-Cortex M4 processors. One is the TM4C129XNCZAD from TI/Stellaris and the other is the STM32F429xx from ST Micro.

One thing that is common to these two ARM Cortex M4 devices is that the LDO regulator for the 1.2V core logic supply is included on the chip – the only thing needed is external bypassing capacitors.

TM4C129XNCZAD Current Consumption

For the TI/Stellaris CPU, the data sheet provides the information I need starting on page 2173 (wow! They don’t make ’em small these days…) What’s nice here is that you can see the nominal and maximum current draw of the CPU and all peripherals active, both at full clock speed (120 MHz) and low speed (16 MHz), and with code executing from internal FLASH and also the high-speed SRAM. At first, I’m really just interested in the worst case (or maximum current) consumption. In the TI data sheet this spec is given as IDD_RUN, in Flash loop execution, and Table 32-74 shows it at 113 mA max. Perhaps a little surprisingly, the relationship between system clock and current consumption appears to be nonlinear, with only a 2.6x increase in current corresponding to a 7.5x increase in clock frequency – most likely because only the core CPU and memory are actually running at the full speed.

Figure 1. (Source: p2173 viewed April 2014)

113 mA is not too bad for a fast microcontroller. But there’s a “gotcha” with this – What this table really only specifies is the consumption of the core and peripheral functions. If you are running lots of GPIO at the FAST GPIO Pad recommended conditions (up to 12 mA drive per pad, with a 40% switching rate) then you need to consider the additional current needed for IO drive. This is specified on pages 2104/5 of the data sheet where the recommended operating conditions for GPIOs are called out. Here you can see a cumulative maximum current recommendation for 88 to 116 mA per side of the die. So peak operating IO current could be as high as ≈ 550 mA! In addition, I note on page 2115, Table 32-15, shows an inrush current of the internal VDDCORE LDO regulator of 250 mA maximum. So this could mean a peak power-up current draw of 250 mA followed by increased draw once the code begins execution and starts banging away at the GPIOs.

STM32F429xx Current Consumption

Let’s quickly examine the same parameters for the STM32F429xx. The data we’re after here begins in the data sheet on page 98, with Table 24 showing the current consumption during execution of code from program memory (Flash), for a range of clock speeds. Since this processor is normally used at 168 MHz I’ll check the value for that clock frequency – the maximum from the table is 116 mA with all peripherals enabled at 85°C, so it really is pretty much equivalent to the TI/Stellaris chip. The notes on the table however call out that “additional power consumption should be considered” when analogue peripheral blocks are on. This is where more caveats are needed – the subtleties of data sheets can be confusing. The table 24 wording is “All Peripherals Enabled” – not necessarily all peripherals running.

Figure 2. Current consumption data graphed from STM32F429xx table data.

I just wanted to point these subtleties out because sometimes to be really sure you just need to call the semiconductor FAE for additional clarification, or simply measure it yourself.

Balancing the budget?!

We’ve just looked at the current consumption needs of two similar micros that would typically form the heart of a single-board embedded system. But of course the same needs to be considered for all the components.

One way of making this task quick and easy for new designs is to make sure average and peak current requirements for each voltage rail are included as a parameter in the CAD library, for all active components. Then it’s quick and easy to generate a BoM report for power budget, export to Excel and do the math for each supply rail. As a starting point this at least helps plan the supply and regulation network. An example of how this might look (based on the STM3240G-EVAL board) is shown in Figure 3a. (Negative numbers mean sourcing current).

Figure 3 (a) and (b). STM3240G-EVAL power budget and regulation scheme. The current values are shown for illustrative purposes only.

In this design the 1V8 regulator takes its input from the 3V3 rail (so as to limit regulator power dissipation, while maintaining a voltage drop larger than the dropout voltage). This means the 1V8 rail’s current consumption must be added with the rest of the 3V3 devices. The regulator circuit is shown in figure 3b.

Part 2 of this article will take the discussion on with a look at monitoring tools for embedded systems.

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles