MENU

What about DC power integrity? – Part 2

What about DC power integrity? – Part 2

Technology News |
By eeNews Europe



PCB power budgeting
In my previous article on DC power integrity, I touched on some of the symptoms that can point toward power integrity problems in a PCB design. A great question to think about would be: "What is a good starting point for designing with power integrity in mind?"

There are well-established best-practices for designing with power in mind, but I still see quite a lot of designs where the PCB’s power distribution is basically copied from a chip manufacturer’s reference design. Often, this is done without a lot of concern for the customized nature of the product itself. Some of the difficulties and considerations with this approach are as follows.

  • When you’re under the gun to finish a design, it’s awfully tempting simply to copy the power supply from reference design material. This places a large — and sometimes unwarranted — amount of trust in the applications engineer who created the reference design. (In a sense, this is flattering, but it’s also a bit naive.)
  • Your use of the product is never going to be exactly the same as the reference design. Reference design boards tend to be large, simple designs intended to show how to use a device. Your design will most likely include 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 than the reference design was.

Reference designs from chip makers 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 create your design based on this information, the product almost certainly will be very robust from a DC power point of view. However, the extra copper and space required may make it too large and costly. Many would consider this the over-engineered approach.

Once the worst-case power needs have been established, you can consider the use case of the parts in the design to figure out a more optimized solution. Luckily, good component manufacturers with high-quality data sheets provide the extra information needed to estimate this, but a few tricks and even some tools allow you to get a clearer view of the nominal and peak current requirements. Also, tradeoffs can be made here. Running the CPU at half the clock speed, for example, can halve its power consumption.

Just for fun, let’s compare the power consumption requirements for two roughly equivalent ARM-Cortex M4 processors: the TM4C129XNCZAD from TI/Stellaris and the STM32F429xx from ST Micro. One thing they have in common 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
The TI/Stellaris CPU data sheet provides the information I need starting on page 2,173. (Caw! 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 with all the peripherals active, both at full clock speed (120 MHz) and at low speed (16 MHz), and with code executing from internal Flash and the high-speed SRAM.

Initially, I’m really just interested in the worst-case (or maximum) current consumption. In the TI data sheet, this specification is given as IDD_RUN in Flash loop execution. Table 32-74 shows it as 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, this is because only the core CPU and memory are actually running at the full speed.

(Source: https://www.ti.com/lit/ds/spms444/spms444.pdf, p 2173,viewed April 2014)

Now, 113 mA is not too bad for a fast microcontroller, but there’s a gotcha. This table really specifies only the consumption of the core and peripheral functions. If you are running lots of general-purpose input/outputs (GPIOs) at the Fast GPIO Pad recommended conditions (up to 12 mA drive per pad with a 40% switching rate), you need to consider the additional current needed to drive the I/Os.

This is specified on pages 2,104 and 2,105 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-116 mA per side of the die. So peak operating I/O current could be as high as ≈550 mA. In addition, I note that, on page 2,115, Table 32-15 shows an inrush current of the internal VDDCORE LDO regulator of 250 mA maximum. 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. Table 24 shows 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 this device really is pretty much equivalent to the TI/Stellaris chip. However, the notes associated with the table tell us that "additional power consumption should be considered" when analog 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," which does not necessarily imply all peripherals running.

Current consumption data graphed from STM32F429xx table data.

I just wanted to point out these subtleties, because they illustrate the fact that sometimes — to be really sure — you need to call the semiconductor FAE for additional clarification, or you need to measure things yourself.

Balancing the budget

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

One way to make 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. This makes it quick and easy to generate a BOM report for the power budget, export it 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 the two illustrations below, where negative numbers mean sourcing current.

STM3240G-EVAL power budget; current values are for illustrative purposes only.

STM3240G-EVAL regulation scheme.

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

Monitoring tools for embedded systems
One useful function of modern embedded tools is the ability to monitor power consumption in concert with debugging code.

Various means of measuring power may be provided. For example, the STM32429IG-EVAL board from ST Micro, which uses a variant of the ARM processor mentioned above, is designed with a jumper in place for the VDD rail to the CPU. The intent is that, while you are developing and debugging source code, you can also measure the current being supplied to the CPU.

  1. Set a breakpoint at the beginning and end of the code routine of interest.
  2. Enable the oscilloscope trigger on the current measurement probe on JP2.
  3. Step into the routine, capturing the current waveform on the scope.
  4. Repeat for all routines of interest, taking note of the current requirements.

This way, you can get a clear picture of how the source code is affecting power consumption. You can even decide how to modify the code to optimize or limit power use.

Similar tools are available for monitoring FPGA development flows. The image below shows the power monitoring capability of Altium’s NanoBoard FPGA development board. In this example, I am running the C-to-Hardware reference design that spins a graphical cube in 3D. I can switch between processing the matrices for transformation in software and FPGA hardware, and I can compare the power consumption based on how the job is done. Similar tools can be found with FPGA vendor development boards.


Monitoring power consumption during FPGA/Software debug of a System on Chip design.

What’s all this got to do with DC power integrity?
Modern designs have many dimensions of complexity, including limited space to design the power network on the PCB. Also, with ever-shrinking device packages, it’s getting harder and harder to use the old brute-force, plenty-of-copper approach to provide power to these devices. Knowing about the techniques discussed in this column will be key in using a multi-pronged approach to solving power integrity bottlenecks at the PCB design level. We will discuss these concepts further in future blogs.

Ben Jordan is senior manager of content marketing strategy at Altium.

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

Share:

Linked Articles
10s