Abstract
Power consumption is critical constrain for embedded system. In order to provide a criterion for designers to optimize system power as well as performance, various power evaluation methods have been proposed. Power evaluation methods can be classified into two groups: simulation-based and measurement-based. Simulation-based modeling is a good tool for evaluating power due to the controllability of simulator. However, the simulation accuracy might be questioned since model might not reflect all the details of actual hardware. Besides, the long simulation time could be a burden while the extreme accuracy is required. By contrast, the measurement-based method is closer to reality, but also introduces other issues. In this thesis, we use a real-time embedded power measurement board, which is developed by previous work in [1], to measure the power of ARM core and DRAM module on an embedded system development board. A power collection hardware is designed on FPGA to interface with the power measurement board. Combining the driver which we develop, the software on ARM core can access the measured power data real-timely. To further utilize the real-time power information, in this thesis, we try to map the measured power data to the corresponding software context on system. One of the challenges we face is the latency of passing a command to enable power monitor from software. If the command is issued by a user-level application, it must pass through driver and then to FPGA hardware. From experiment results, the delay between driver and hardware is almost constant, so we can easily compensate it by buffering the power data in this constant period. Conversely, the response time from driver to application is determined by scheduling and varies depending on current system context. To deal with this difficulty, we propose a sampling-based power monitoring method, based on a system profile tool, OProfile. Oprofile can record program counter (PC) value periodically by an interrupt handler which is triggered by performance counter or timer. Finally, due to the limited OProfile sample rate in our system, an OProfile sample is mapped to multiple samples of measured power. Trying to rebuild the lost software context, we proposed a linear programming method to analyze and estimate the power consumption of each profiled function calls.