# Modeling the Power Consumption of Function-Level Code Relocation for Low-Power Embedded Systems
## 6 Experimental Results and Analysis  
In this section, we evaluate the proposed prior relocation-scoring model by using various benchmark programs. An instruction trace environment was set up to design the model. The instruction trace description that was derived was intended to describe several specifications of functions regarding instruction groups; for example, the number of instructions in each group, the power reduction efficiency of placing an example instruction in the other type of memory, and the absolute power values during execution. Then, the programs were ported to the power measurement environment for the model experiment. Based on the MiBench benchmark suite [22], which is known as an adequate tool for analyzing embedded processors, MiBench is composed of six categories including Automotive and Industrial Control, Network, Security, Consumer Devices, Office Automation, and Telecommunications. An experiment requires sequential work to be carried out. First, Instruction Trace must be run, after which it is necessary to measure the power factor when applying the proposed methodology. The results are collected by implementing the ETM Trace Method of Keil ULINKpro in the Instruction Trace environment and preprocessed by using Python. Subsequently, for the measurement of the power factor according to the application of the proposed methodology, the function is relocated to the SRAM area. At this time, the size of the SRAM memory on the experimental board is important and, as mentioned, it has a size of 64,000 bytes. In addition, because the SRAM is divided into several segments, Stack, Heap, Data, and Text amongst others, the size of the text area to be used by the function being relocated is limited. Therefore, we excluded some benchmarks that could not be executed because of the hardware limitation, e.g., requirements in terms of peripherals of experimental boards and memory capacity. These results enabled us to list our target applications. Because our model conducts function-level relocation, the functions comprising each program are also provided in Table 4. \begin{table}
\begin{tabular}{c c c} \hline \hline _Categories_ & _Application_ & _Function_ \\ \hline \multirow{4}{*}{Automotive and Industrial Control} & Basicmath & solvecubic \\  & & usqrt \\ \cline{2-3}  & Qsort & qsort \\  & & compare \\  & & swap \\ \hline \multirow{4}{*}{Network} & Dijkstra & dijkstra \\  & & enqueue \\ \cline{1-1}  & & dequeue \\ \cline{1-1}  & & qcount \\ \hline \multirow{4}{*}{Security} & Blowfish & init \\ \cline{1-1}  & & encrypt \\ \cline{1-1}  & & decrypt \\ \cline{1-1}  & & f \\ \cline{1-1} \cline{2-3}  & SHA & stream \\ \cline{1-1}  & & init \\ \cline{1-1}  & & update \\ \cline{1-1}  & & final \\ \cline{1-1}  & & transform \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Benchmarks of MiBench selected as experimental group. The occurrence of code relocation arranges the location of a function in a program. A function is fundamentally located in Flash memory without critical modification, whereas the insertion of unique codes can cause it to migrate to SRAM. In Figure 4, therefore, we separate the cases into two groups: The experimental group and the control group. Each group positions the target function differently. A target function in the experimental group is in SRAM, whereas a target function in the control group is in Flash memory. Because the control group is the standard for experimental comparisons, we specified the power consumption of the group as 100%. The value of the experimental group is subsequently analyzed as the relative power consumption. If the relative power consumption is smaller than 100%, it implies that execution in SRAM required less power than in Flash memory. This evaluation defines a target function as one of the functions in a benchmark program. Therefore, we migrated each function to SRAM one by one to obtain a measurement summary.