The "Power Demo" was created with a vision to provide different power saving techniques available with Zynq AP SoC. It’s also intended to provide user with the flexibility to identify the system power, CPU utilization, CPU frequency scaling at run time and thus providing an opportunity to validate power budgets while designing the system. It demonstrates power consumption during execution of Ubuntu desktop and corresponding applications on Zynq. User can execute these applications and perform different I/O operation on Zynq PS peripherals supported by Ubuntu desktop to measure power consumption. Power Management of entire system can also be affected by I/O buffers at the PIN which drive the current and the traffic through logic gates. Controlling and power utilization of IOB’s and logic gates are explained as a part of Power Consuming And Speed Test Modules
This tech tip aims to help understand the basic Linux framework and various factors affecting power and how power consumption and the implementation support provided for the processing System (PS) to optimize the power consumption as a part of power Demo. In simple terms this tech tip helps user to map the theory of Linux Power management while running the power Demo providing a practical and proactive approach. It’s strongly advised that users goes through the “Zynq Power: Installing and running the Power Demo” tech tip before proceeding with the current tech tip.
Linux Kernel configuration for PM framework support in power demo
This section explains about the supported Linux OS power management framework features in the power demo. This section also explains how to enable corresponding frame work in the kernel configuration while building the kernel image for the Zynq System. Following is list of PM (power management) frameworks features supported in the power demo and the corresponding changes required in the config file of kernel configuration.
CPU Frequency: The cpufreq framework is used to scale the CPU frequency. The framework exposes a control interface through sysfs Is /sys/devices/system/cpu/cpu0/cpufreq/. This interface provides statistics (if enabled) and allows to choose a scaling governor and in case of the userspace governor is used to manually set a frequency.
To enable the cpufreq framework enable the following config options in your kernel configuration:
CPU Idle: The cpuidle framework manages CPU idle levels. The cpuidle driver puts idle CPUs in a low power state when a CPU becomes idle.To enable the cpuidle framework enable the following config options in your kernel configuration:
Suspend: The suspend framework provides the interface to enter sleep states, like the well-known 'suspend to disk/RAM' on laptops. The architecture specific callbacks and initialization is located in arch/arm/mach-zynq/pm.c. In order to shut down the DDR subsystem the final suspend call — mach-zynq/suspend.S:zynq_sys_suspend () — is moved into OCM and executed from there. Depending on the requirements of the wakeup device enabled, the IOPLL might not be bypassed. All Zynq peripheral drivers employ clock gating during suspend. The implementation details for suspend is described in detail at following link https://www.kernel.org/doc/Documentation/power/suspend-and-cpuhotplug.txt.To enable the suspend framework, enable the following config options in your kernel configuration.
XADC: The Xilinx analog mixed signal module, referred to as the XADC, allows temperature and voltage monitoring. In power demo for reading the die temperature through XADC module, enable the following kernel configuration option in the config file.
Host Machine Application view Host machine application is C# based GUI program executing on windows machine. The GUI sends commands and receives different kind responses from Linux application running on is the ZC702 board. Below figures shows Host machine GUI application:
Fig 1: GUI application
Linux Application description
The Linux application of the power demo runs on the ZC702 board. The main job of this application is to receive commands from the Host machine software and do necessary configurations related to Zynq device accordingly. It sends response of the received command to host machine application continuously in every 0.5 msec. Whenever the Linux application receives the valid command from the host machine software, it will do the following configuration to Zynq AP SoC according to that command.
CPU frequency scaling:The operating points which define the boundaries of the system supported in cpufreq framework for Zynq are as follows
User can switch between any of frequencies during execution and do measurements. When user selects any one of the frequencies from GUI, Linux application executes the following commands in user space to force the kernel/system to run at specified frequency using CPU frequency framework. “Echo <selected_CPU_speed> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed”
PLL Bypass mode: when user selects 33 MHz as CPU frequency from GUI, Linux application uses mmap system call to configure the ARM clock control register to bypass the Zynq ARM PLL frequency and gives 33 MHz output frequency of PLL directly to the processor. In this mode we can see lowest power consumption on Zynq AP SoC.
CPU load: Power demo supports following types of loads to apply on the CPU to see, different power consumption for different loads.
CPU Idle: Currently a pseudo CPU idle frame work is supported in Zynq. Ideally CPU idle frame work must make use of CPU governor and should execute an idle loop waiting for interrupt. However a pseudo idle loop is implemented by forcing the system to run at lowest possible operating frequency. When user selects CPU idle as a workload from the GUI, the background Linux application kills all the processes which are running currently, and forces the CPU utilization to become zero. By doing so it gives an impression of CPU Idling.
Spec 2000:1 load: When user selects this load option from the GUI, Linux application creates a child process and executes one Spec CPU2000 benchmark named 186.crafty on one CPU using below Linux system call. "execl(file_name ,process_name,NULL);"
After running the one Spec CPU2000 benchmark load, one of the two CPU utilization will become 100%.This utilization information would be captured form the /proc/stat directory of the kernel interface and calculated the percentage, sends captured value to the host application.
Spec 2000:2 loads: when user selects this load option from the GUI, Linux application creates two child processes and executes two Spec CPU2000 benchmark named 186.crafty on both CPU’s using below Linux system call. "execl (file_name ,process_name,NULL) ;"
After running the two Spec CPU2000 benchmark loads, both the CPU utilization will become 100%.The CPU utilization a result are captured from the /proc/stat directory of Linux kernel and calculate percentage, sends the calculated value to host machine application.
Suspend:It is low power state for Zynq, in which all peripherals goes to low power mode and DDR goes in to self-refresh mode. CPU waits for interrupt for resume.The implementation details for suspend is described in detail at https://www.kernel.org/doc/Documentation/power/suspend-and-cpuhotplug.txt . When user selects Standby as CPU load in the GUI, Linux application executes following command to enter the cpu in suspend mode
"echo mem > /sys/power/state"
The system can be brought back to life in three ways which are listed below
wake on UART
wake on GPIO
wake on debugger
To support above wake on methods, corresponding I/O has to configure as a wakeup device. Power demo supports wake on GPIO and below is explanation about how to configure the GPIOs as a wake on device.
Wake on GPIO: In order to wake up the system from suspend mode through GPIO ,need to follow the below procedure.Export the wanted GPIOs to kernel clock framework by entering following command "echo <n> > /sys/class/gpio/export"
Use <n> = 12 and 14 for the push buttons on a zc702.
Enable interrupts for the wanted GPIO pins with below command echo (rising|falling|both) > /sys/class/gpio/gpio<n>/edge
Make GPIO the wake-up device using following linux command "echo enabled > /sys/devices/amba.0/e000a000.gpio/power/wakeup"
DDR frequency configuration: In Zynq AP SoC we cannot change the DDR operating frequency “on the fly” because CPU and DDR both are driven by the same clock input. Power demo supports changing the different DDR frequency by rebooting the system with a new boot image. Different boot images are created with DDR frequencies using Xilinx Vivado hardware design tool and SDK tool. Power demo supports following two different DDR frequencies listed below.
When user selects the DDR frequency change option in the GUI, the back-end application will reboot the system a new boot image. Before the system starts rebooting, GUI backend application sends commands to Linux application to kill all the processes which are in active state. For this, Linux application uses kill command to kill the processes.
Additional Status Information Apart from the above Zynq configuration, Linux application gets the following status information from the Zynq processing system through Linux control interface as a part of power demo.
CPU frequency: CPU frequency at which it is running can be read through sys interface provided by the Linux frame work. Below is the path to read the CPU frequency.
Die temperature: XADC is a mixed signal module present on the Zynq AP SoC, which allows reading the temperature of the die in degree Celsius units. This is possible by enabling the hardware monitoring frame work in the Linux kernel. Linux application reads the die temperature from the following kernel path
DDR frequency: Power demo Linux application reads the DDR frequency from the DDR control register. These reads and writes to the hardware to registers in the memory is possible using the following Linux system call "void *mmap(void *addr, size_t length, int prot, int flags,int fd, off_t offset);”
Appendix A: Building power demo Linux application work-space Design files are provided along with this tech tip which contains SDK work-space for power demo Linux application. One can import the provided workspace to Xilinx SDK and can modify the Linux application according to ones requirements. For importing workspace to SDK tool, refer section “Building the first stage boot loader (FSBL)” in the following link http://www.wiki.xilinx.com/Zynq+Base+TRD+2013.4. Appendix B: File Descriptions in design directory Directory Structure is