We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Adam Taylor’s MicroZed Chronicles, Part 162: Zynq SoC Power Management Part 1

by Xilinx Employee on ‎01-03-2017 12:16 PM (2,660 Views)


By Adam Taylor


I thought I would kick off the new year with a few blogs that look at the Zynq SoC’s power-management options. These options are important for many Zynq-based systems that are designed to run from battery power or other constrained power sources.


There are several elements of the design we can look at, from the system and board level down to the PS and PL levels inside of the Zynq SoC. At the system level, we can look at component selection. We can use low-voltage devices wherever possible because they will have a lower static power consumption. We can also use lower-power DRAM by selecting components like LPDDR in place of DDR2. One of the simpler choices would be selecting a single-core Zynq SoC as opposed to a dual-core device.


Within the Zynq SoC itself, there are several things we can do both within the PS and PL to reduce power. There are two categories we can consider when it comes to reducing power consumption in Zynq-based systems:


  1. Entering a low-power standby mode in which application execution is stopped. This is achieved by placing the Zynq PS in sleep mode and powering down the PL.
  2. Optimizing the PS and the PL to reduce power during operation.


The first option allows us to reduce the power consumption after we have detected that the system has been inactive for a period and should therefore enter a low-power mode to prolong operating life on a battery charge. The second option allows us to make the best use of the battery capacity while operating. I will demonstrate the savings to be had with the Zynq SoC’s sleep mode and how to enter it in a follow-up blog. For the moment, I want to look at what we can do within the Zynq SoC’s PS to reduce power consumption. Most of these techniques relate to how we configure the clocking architecture within the PS.


As you can see in the diagram below, the Zynq SoC’s clocking architecture is very flexible. We can use this flexibility to reduce the power consumption of the Zynq PS.






Zynq SoC Clocking Architecture



The first approach we can take is to trade off performance against power consumption. We can reduce the power consumption within the Zynq SoC’s PS simply by selecting a lower APU frequency. Of course, this also reduces APU performance. However, as engineers one of our roles is to understand the overall system requirements and balance them.  CMOS power dissipation is frequency dependent so we reduce power consumption by reducing the APU frequency, which has the potential to significantly reduce PS power dissipation. We can also use the same trade-off with the DDR SDRAM, trading memory bandwidth for reduced power.






Clock Configuration in the Zynq SoC – Reducing the APU frequency




Along with reducing the frequency of the APU, we can also implement a clocking scheme that reduces the number of PLLs used within the PS. The Zynq PS has three available PLLs named the ARM, IO, and DDR PLL. The clocking architecture allows downstream connections to use any one of the PLL sources, so a clocking scheme that uses fewer than all three PLLs results in lower power dissipation as unused PLLs can be disabled and their power consumption eliminated.


In addition, the application being developed may not require the use of all peripherals within the PS. We can therefore use the Zynq SoC’s clock-gating facilities to reduce power consumption by not clocking unused peripherals, further reducing the power consumption of the PS within the Zynq.


I performed a very simple experiment with a MicroZed board by inserting an ammeter into the USB power port supplying power to the MicroZed. This is a simple way to monitor the board’s overall power consumption. Running the Zynq PS alone with no design in the programmable logic, the MicroZed drew a current of 364mA @ 5V (1.825W) with the default MicroZed configuration.

I ran a few simple experiments to see the effect on the overall power consumption by reducing the clock frequency by half from 666MHz to 250MHz and then selecting the use of only one PLL—the DDR PLL—to clock the design. Running just from the DDR PLL reduced the current consumption to only 308mA, a 16% reduction. However, I did to have de-activate the unused PLL’s myself in my application. Reducing the frequency of the APU alone only reduced the overall current consumption to 345mA, a 6% reduction. So we see that turning off unused PLLs can have a big effect on power consumption.


If we want to gate the clocks to unused peripherals within the PS, we can use the Zynq SoC’s APER register to disable the clocks to that peripheral.






APER Control Register Bits



For a final experiment, I relocated the program to execute from the Zynq SoC’s on-chip RAM and disabled the DDR memory. For many applications, this may not be feasible but for some it may, so I thought it worthy of a test. Relocating the code further reduced the current consumption to 270mA (a 26% reduction) when combined with peripheral gating, APU frequency reduction, and running from one PLL alone.


Next time we will look at how we can place the processor into sleep mode.

About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.