Skip to main content
zenodoopen

MSP430FR5969 Basic Block Worst Case Energy Consumption (WCEC) and Worst Case Execution Time (WCET) dataset

<p>This dataset contains around 30 000 basic blocks whose energy consumption and execution time have been measured in isolation on the MSP430FR5969 microcontroller, at 1MHz. Basic blocks were executed in a worst case scenario regarding the MSP430 FRAM cache and CPU pipeline. The dataset creation process is described thoroughly in [1].</p> <h2>Folder structure</h2> <p>This dataset is composed of the following files:</p> <ul> <li><code>basic_blocks.tar.xz</code> contains all basic blocks (BB) used in the dataset, in a custom JSON format,</li> <li><code>data.csv</code>/<code>data.xlsx</code> contains the measured energy consumption and execution time for each basic block</li> </ul> <p>We first details how the <code>basic_blocks.tar.gz</code> archive is organized, and then present the CSV/XSLX spreadsheet format.</p> <h2>Basic Blocks</h2> <p>We extracted the basic blocks from a subset of programs of the <em>AnghaBench</em> benchmark suite [2]. The <code>basic_blocks.tar.gz</code> archive consist of the extracted basic blocks organized as <code>json</code> files. Each <code>json</code> file correspond to a C source file from <em>AnghaBench</em>, and is given a unique identifier. An example json (<code>137.json</code>) is available here:</p> <div> <pre><code>{ "extr_pfctl_altq.c_pfctl_altq_init": [ # Basic block 1 [ # Instruction 1 of BB1 [ "MOV.W", "#queue_map", "R13" ], # Instruction 2 of BB1 [ "MOV.B", "#0", "R14" ], # Instruction 3 of BB1 [ "CALL", "#hcreate_r", null ] ], # Basic block 2 [ .... ] ] }</code></pre> </div> <p>The json contains a dict with only one key pointing to an array of basic blocks. This key is the name of the original C source file in <em>AnghaBench</em> from which the basic blocks were extracted (here <a href="https://github.com/brenocfg/AnghaBench/blob/master/freebsd/sbin/pfctl/extr_pfctl_altq.c_pfctl_altq_init.c">extr_pfctl_altq.c_pfctl_altq_init.c</a>). The array contains severals basic blocks, which are represented as an array of instructions, which are themselves represented as an array <code>[OPCODE, OPERAND1, OPERAND2]</code>.</p> <p>Then, each basic block can be identified uniquely using two ids : its <em>file id</em> and its <em>offset</em> in the file (<code>id=&lt;file id&gt;_&lt;offset&gt;</code>). In our example, the basic block 1 can be identified by the json file id (<code>137</code>) and its offset in the file (<code>0</code>). Its ID is <code>137_0</code>. This ID is used to make the mapping between a basic block and its energy consumption/execution time, with the <code>data.csv</code>/<code>data.xlsx</code> spreadsheet.</p> <h2>Energy Consumption and Execution Time</h2> <p>Energy consumption and execution time data are stored in the <code>data.csv</code> file. Here is the extract of the csv file corresponding to the basic block <code>137_0</code>. The spreadsheet format is described below.</p> <pre><code>bb_id;nb_inst;max_energy;max_time;avg_time;avg_energy;energy_per_inst;nb_samples;unroll_factor 137_0;3;8.77;7.08;7.04;8.21;2.92;40;50</code></pre> <p>Spreadsheet format :</p> <ul> <li><code>bb_id</code>: the unique identifier of a basic block (cf.&nbsp;<a>Basic Blocks</a>)</li> <li><code>nb_inst</code>: the number of instructions in the basic block</li> <li><code>max_energy</code>: the maximum energy comsumption (in nJ) measured during the experiment</li> <li><code>max_time</code>: the maximum execution time (in us) measured during the experiment</li> <li><code>avg_time</code>: the average execution time (in us) measured during the experiment</li> <li><code>avg_energy</code>: the average energy comsumption (in nJ) measured during the experiment</li> <li><code>energy_per_inst</code>: the average energy consumption per instruction (correspond to <code>avg_energy</code>/<code>nb_inst</code>)</li> <li><code>nb_samples</code>: how much time the basic block energy consumption/execution time has been measured</li> <li><code>unroll_factor</code>: how much time the basic block was unrolled (cf Basic Block Unrolling)</li> </ul> <h3>Basic Block Unrolling</h3> <p>To measure the energy consumption and execution time of the msp430, we need to be able to handle the scale difference between the measurement tool and the basic block execution time. This is achieved by duplicating the basic block multiple times while making sure to keep the worst-case memory layout as explained in the paper. The number of time the basic block has been duplicated is called the <code>unroll_factor</code>.</p> <p>Values of energy and time are always given per basic block, so they have already been divided by the unroll factor.</p> <p>&nbsp;</p> <h2>Dataset description</h2> <h3>Features</h3> <p>The selected features after PCA analysis for both energy and time model are listed here:&nbsp;<strong> MOV.W_Rn_Rn, MOV.W_X(Rn)_X(Rn), CALL, MOV.B_#N_Rn, ADD.W_Rn_Rn, MOV.W_@Rn_Rn, MOV.W_X(Rn)_Rn, ADD.W_#N_Rn, PUSHM.W_#N_Rn, MOV.W_X(Rn)_ADDR, CMP.W_#N_Rn, MOV.W_&amp;ADDR_X(Rn), MOV.W_Rn_X(Rn), BIS.W_Rn_Rn, RLAM.W_#N_Rn, SUB.W_#N_Rn, MOV.W_&amp;ADDR_Rn, MOV.W_#N_X(Rn), CMP.W_Rn_Rn, BIT.W_ADDR_Rn, MOV.W_@Rn_X(Rn), ADD.W_#N_X(Rn), MOV.W_#N_Rn, AND.W_Rn_Rn, MOV.W_Rn_ADDR, SUB.W_Rn_Rn, MOV.W_ADDR_Rn, MOV.W_X(Rn)_&amp;ADDR, MOV.W_ADDR_ADDR, JMP, ADD_#N_Rn, BIS.W_Rn_X(Rn), SUB_Rn_Rn, MOV.W_ADDR_X(Rn), ADDC_#N_X(Rn), MOV.B_Rn_Rn, CMP.W_X(Rn)_X(Rn), ADD_Rn_Rn, nb_inst, INV.W_Rn_, NOP__, ADD.W_X(Rn)_X(Rn), ADD.W_Rn_X(Rn), MOV.B_@Rn_Rn, BIS.W_X(Rn)_X(Rn), MOV.B_#N_X(Rn), MOV.W_#N_ADDR, AND.W_#N_ADDR, SUBC_X(Rn)_X(Rn), BIS.W_#N_X(Rn), SUB.W_X(Rn)_X(Rn), AND.B_#N_Rn, ADD_X(Rn)_X(Rn), MOV.W_@Rn_ADDR, MOV.W_&amp;ADDR_ADDR, ADDC_Rn_Rn, AND.W_#N_X(Rn), SUB_#N_Rn, RRUM.W_#N_Rn, AND_ADDR_Rn, CMP.W_X(Rn)_ADDR, MOV.B_#N_ADDR, ADD.W_#N_ADDR, CMP.B_#N_Rn, SXT_Rn_, XOR.W_Rn_Rn, CMP.W_@Rn_Rn, ADD.W_@Rn_Rn, ADD.W_X(Rn)_Rn, AND.W_Rn_X(Rn), CMP.B_Rn_Rn, AND.W_X(Rn)_X(Rn), BIC.W_#N_Rn, BIS.W_#N_Rn, AND.B_#N_X(Rn), MOV.B_X(Rn)_X(Rn), AND.W_@Rn_Rn, MOV.W_#N_&amp;ADDR, BIS.W_Rn_ADDR, SUB.W_X(Rn)_Rn, SUB.W_Rn_X(Rn), SUB_X(Rn)_X(Rn), MOV.B_@Rn_X(Rn), CMP.W_@Rn_X(Rn), ADD.W_X(Rn)_ADDR, CMP.W_Rn_X(Rn), BIS.W_@Rn_X(Rn), CMP.B_X(Rn)_X(Rn), RRC.W_Rn_, MOV.W_@Rn_&amp;ADDR, CMP.W_#N_X(Rn), ADDC_X(Rn)_Rn, CMP.W_X(Rn)_Rn, BIS.W_X(Rn)_Rn, SUB_X(Rn)_Rn, MOV.B_X(Rn)_Rn, MOV.W_ADDR_&amp;ADDR, AND.W_#N_Rn, RLA.W_Rn_, INV.W_X(Rn)_, XOR.W_#N_Rn, SUB.W_Rn_ADDR, BIC.W_#N_X(Rn), MOV.B_X(Rn)_ADDR, ADD_#N_X(Rn), SUB_Rn_X(Rn), MOV.B_&amp;ADDR_Rn, MOV.W_Rn_&amp;ADDR, ADD_X(Rn)_Rn, AND.W_X(Rn)_Rn, PUSHM.A_#N_Rn, RRAM.W_#N_Rn, AND.W_@Rn_X(Rn), BIS.B_Rn_X(Rn), SUB.W_@Rn_Rn, CLRC__, CMP.W_#N_ADDR, XOR.W_Rn_X(Rn), MOV.B_Rn_ADDR, CMP.B_X(Rn)_Rn, BIS.B_Rn_Rn, BIS.W_X(Rn)_ADDR, CMP.B_#N_X(Rn), CMP.W_Rn_ADDR, XOR.W_X(Rn)_Rn, MOV.B_Rn_X(Rn), ADD.B_#N_Rn</strong></p> <h3>Code</h3> <p>The trained machine learning model, tests, and local explanation code can be generated and&nbsp; found here: <a href="https://colab.research.google.com/drive/1zaCIkbKDRDtwzhY-r3Iff0OpOSkOUibW?usp=sharing" target="_blank" rel="noopener">WORTEX Machine learning code</a>&nbsp;</p> <h2>Acknowledgment</h2> <p>This work has received a French government support granted to the Labex CominLabs excellence laboratory and managed by the National Research Agency in the &ldquo;Investing for the Future&rdquo; program under reference ANR-10-LABX-07-01</p> <h2>Licensing</h2> <p>Copyright 2024 Hector Chabot Copyright 2024 Abderaouf Nassim Amalou Copyright 2024 Hugo Reymond Copyright 2024 Isabelle Puaut</p> <p>Licensed under the Creative Commons Attribution 4.0 International License</p> <h2>References</h2> <p>[1] Reymond, H., Amalou, A. N., Puaut, I. &ldquo;WORTEX: Worst-Case Execution Time and Energy Estimation in Low-Power Microprocessors using Explainable ML&rdquo; in 22nd International Workshop on Worst-Case Execution Time Analysis (WCET 2024)&nbsp;</p> <p>[2] Da Silva, Anderson Faustino, et al. &ldquo;Anghabench: A suite with one million compilable C benchmarks for code-size reduction.&rdquo; 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 2021.</p>

ShareScore

48/100

Overall dataset sharing score

Score breakdown

These five areas show where the dataset supports — or may limit — practical reuse.

Stewardship
8
Harmonization
4
Access
20
Reuse readiness
8
Engagement
8

Topics