WCET Analysis Based on Micro-Architecture Modeling for Embedded System Security

Abstract

To ensure the timely execution of hard real-time applications, scheduling analysis techniques must consider safe upper bounds on the possible execution durations of tasks or runnables, which are referred to as Worst-Case Execution Times (WCET). Bounding WCET requires not only program path analysis but also modeling the impact of micro-architectural features present in modern processors. In this paper, we model the ARMv8 ISA and micro-architecture including instruction cache, branch predictor, instruction prefetching strategies, out-of-order pipeline. We also consider the complex interactions between these features (e.g., cache misses caused by branch predictions and branch misses caused by instruction pipelines) and estimate the WCET of the program using the Implicit Path Enumeration Technique (IPET) static WCET analysis method. We compare the estimated WCET of benchmarks with the observed WCET on two ARMv8 boards. The ratio of estimated to observed WCET values for all benchmarks is greater than 1, demonstrating the security of the analysis.

1. Introduction

Real-time systems are characterized by the existence of timing constraints, in which tasks must be completed within a limited time frame. In hard real-time systems, missing a deadline can directly impact the system’s security. For instance, if an airbag system in a car does not deploy within the required time frame, it could result in severe injury or death during an accident. Ensuring real-time performance is therefore essential for maintaining security in these systems. The Worst-Case Execution Time (WCET) of a computational task is the maximum length of time the task could take to execute on a specific hardware platform. Its offline estimation helps in choosing appropriate scheduling algorithms, ensuring the system’s performance, and guarantying the system’s energy efficiency [1]. Since the wide application of real-time systems makes real-time analysis of programs particularly important, WCET estimation has been studied extensively [2], and various approaches have been developed to derive such bounds [3]. In embedded systems, ARM processors are considered mainstream because of their high performance, low power consumption, reasonable price, and complete maintenance system. They are particularly prominent in the fields of real-time control, connected automated vehicles, and mobile phones. Thus, the analysis of WCET for ARM processors is crucial. Methods to estimate the WCET of programs on newer ARM platforms like ARMv8 should be provided.

Estimating the WCET of a program is difficult because the execution of a program depends on specific hardware [4]. In terms of micro-architecture, modern processors are often equipped with pipelines, caches, branch prediction, and other features. These units not only perform their own functions but also interact with each other. For example, modern processors often load multiple cache lines at once when transferring data from memory to cache. When dealing with branch instructions, this loading scheme can lead to additional cache invalidation [5]. When a processor’s branch instruction is mispredicted, instructions along the taken branch are fetched and executed, while instructions along the wrong path are undone, incurring a branch misprediction penalty. The branch misprediction penalty can be substantially larger than the pipeline length [6]. These interactions between functional units greatly complicate the analysis of program execution, and there is little research on them [7,8].

In this paper, we model the ARMv8 ISA and the features of the processor’s micro-architecture. These features include cache, dynamic branch predictor, prefetching strategy, and out-of-order pipeline. We also consider the interactions between these features. For example, the cache miss caused by branch prediction and the branch miss caused by the instruction pipeline. We estimate the WCET of a program using a static analysis method. The static estimation is performed by establishing and solving an Integer Linear Programming (ILP) problem using IPET, where the control flow information of the program and the processor’s micro-architecture are converted into a series of linear constraints and a target WCET equation. The estimated WCET of a program can be obtained by solving its corresponding ILP problem. Using this process, we present a WCET analysis tool based on the open-source project Chronos [9]. The tool is tested on WCET benchmarks. By comparing the estimated WCET of benchmarks with the observed results, it can be concluded that, in most cases, the analysis performs reliable WCET estimations.

Our contributions cam be summarized as follows:

• We use the IPET static WCET analysis method to estimate the WCET of programs on the ARMv8 platform.
• In the analysis, we model features of the micro-architecture of the platform, along with the interactions between them.
• We evaluate the performance of our WCET analysis tool by comparing the estimated WCET of benchmarks with the observed results. The results show that our tool can provide reliable WCET estimations.

The remainder of this paper is organized as follows. Section 2 explores common knowledge of WCET analysis, reviews prior research in the field, and elucidates its features. Section 3 introduces our WCET estimation method. Section 4 presents a detailed implementation of our analysis tool. Section 5 shows our evaluation method and experimental results. Lastly, Section 6 concludes the paper.

2. Related Work

There are three types of WCET analysis methods: static analysis, dynamic analysis, and their hybrid [10]. Dynamic analysis obtains the estimated WCET by executing the given task on the given hardware or a simulator, for some set of inputs, and measuring the execution time of the task or its parts. Static analysis is the process of analyzing program code using offline methods without executing the code. Due to the introduction of mathematical theory, the estimated result of the static analysis is higher than the actual value and is considered the safest. This approach is usually used for hard real-time systems that have stringent execution time requirements [11]. Static analysis is comprised of three main sub-tasks: control flow analysis, processor behavior analysis, and WCET calculation. The tool in this paper is designed using static analysis.

The first task of IPET static analysis is to perform control flow analysis and construct the control flow diagram (CFG). CFG is a directed graph with one entry and one exit. Each node, or basic block, in a CFG represents the maximum sequence of consecutive instructions. Except for the last instruction, there is no more branch instructions in the block. Each edge between nodes represents a branch in the control flow. Basic blocks are divided by scanning the symbols using binary. Figure 1 shows an example program and its corresponding CFG.

Currently, there are three types of static WCET analysis methods: the Tree-based Technique, Implicit Path Enumeration Technique [12,13], and Path-Based Technique [14]. The Tree-based Technique translates the structure of a program into a syntax tree, where reduction is performed from the bottom of the tree upwards. When reduction reaches the root of the syntax tree, the WCET of the program is obtained. The Implicit Path Enumeration Technique converts the longest execution time path search problem into the problem of finding the maximum number of executions for each basic block. This can be modeled and solved using the ILP method. The Path-Based Technique is similar to the Tree-based Technique, but it uses a Scope Graph to represent the structure of the program hierarchically.

Table 1. Comparison of the three analysis methods.

Analysis Method	Tree-Based	Implicit Path Enumeration	Path-Based
Efficiency	Highest	High	Low
Accuracy	Average	Good	Best
Ability to Describe Flow Information	Poor	Good	Best
Affected by Compiler Optimization	Yes	No	No

provides a comparison of the characteristics of the methods. We adopt IPET in this paper because this method achieves good performance in various aspects when the input program is not too complex.

The purpose of control flow analysis is to find the program path with the longest execution time. Since IPET is based on the construction and solving of an ILP, the WCET target equation is given by Equation (1), ignoring hardware configuration. From basic block 0 to basic block n there is one possible control flow of the program, where the corresponding execution time and execution count of each block are $cos{t}_i$ and $cn{t}_i$, respectively.

$$WCET=max{\displaystyle \sum _{i=0}^N}(cos{t}_i\times cn{t}_i);$$

(1)

Then, the purpose of control flow analysis shifts to obtaining constraints from the program structure for the target equation. There are three kinds of constraints that should be established: basic block constraints, loop iteration upper limits, and infeasible path constraints [13]. Basic block constraints are relations regarding the execution count of basic blocks. Loop iteration upper limits include the maximum and minimum execution count of multi-exit loops, dependency count of inner loops in nested loops, and others constraints. Common methods for loop bound analysis are abstract interpretation [15] and symbolic execution [16]. Infeasible path constraints are used to exclude redundant control flow in the program that will never be reached, thereby improving the efficiency of the analysis. The detection of an Infeasible path is necessary to analyse reliable hard, critical real-time systems [17]. Ref. [18] proposed an abstract interpretation technique to analyze Infeasible paths in programs, and the technique requires manual intervention in test cases and cannot be fully automated yet.

After obtaining the preliminary WCET target equation and a series of constraints from the control flow of the program, the execution time of each basic block along the longest path is calculated by modelling the micro-architecture of the processor. This is a difficult task because most modern processors use multi-level cache, dynamic branch predictor, pipeline, etc., to improve CPU throughput and the complex behavior and interaction of these units make the execution time very unpredictable [5,19].

To analyse the influence of an instruction cache on program execution time, ref. [20] proposes a method based on IPET, and the basic idea is to estimate whether the cache access is hit or not by analyzing potential cache conflicts within the program and using Cache Conflict Graph (CCG) to model the cache line.

Dynamic branch prediction used by modern processors is based on the History State (HS) branch prediction algorithm. The idea is to predict a branch based on the execution history. The implementation uses the Branch History Register (BHR) to save the address of the Branch History Table (BHT). When a branch instruction is executed, the branch prediction for this instruction is looked up and updated in BHT. Ref. [21] considers the impact of branch prediction on WCET analysis by adding HS nodes in CFG.

Superscalar out-of-order CPUs can achieve higher performance than in-order CPUs, but it is difficult to guarantee the WCET of the software. Ref. [22] modeled basic blocks and performed an analysis of the five-stage pipeline, considering cache effects by using an execution graph, and avoided enumeration of all possible instruction execution times in the analysis by using intervals to represent the execution time of the instructions. Their analysis of pipelines can also be expressed in the form of linear constraints, meaning it can be easily integrated into IPET. Their methods have been adopted by the static WCET analysis tool Chronos.

3. Design

The analysis method in this paper is divided into three steps: compile, analyze, and solve and the process of these works is shown in Figure 2. In the compile step, C source files are compiled and disassembled. We focus on analyzing programs on the ARM architecture, so the output of this step is an object file in ELF format and its disassembled code on the ARM platform. In the analysis step, we perform control flow analysis and micro-architecture modeling to collect the target WCET equation and linear constraints, then combine them into the target ILP problem. In the solve step, the ILP problem obtained in the previous steps is solved to get the estimated WCET value.

3.1. Control Flow Analysis

Each node, or basic block, in the CFG is the maximum sequence of consecutive instructions. Let the directed edge $E_{B\to B^{\prime }}$ represent the count of executions from a basic block B to $B^{\prime }$, and let $v_B$ denote the execution count of a basic block. For any node in the CFG, the count of control flows into the node is equal to the count of flows out of the node, which is equal to the node’s execution count. Thus, the basic block constraint Equation (2) is obtained.

The other two kinds of constraints mentioned in Section 2, namely the loop iteration upper limit and infeasible path constraints, are provided by the user in our analysis. Figure 3 shows a simple C program and its corresponding CFG, along with the structural constraints and loop iteration bounds. These form an ILP problem together with (1). By solving this preliminary problem, we can estimate the execution count of each basic block without considering micro-architecture details.

$$\sum _i{d}_{i,j}=cn{t}_j=\sum _k{d}_{j,k};$$

(2)

Within these constraints, variable $d_n$ denotes the execution count of the path, $cn{t}_n$ denotes the execution count of each basic block, and $L_n$ denotes the execution count of a loop in the CFG. The identification of loops in the CFG will be described in Section 4.

3.2. Instruction Cache Analysis

In this paper, we use a Cache Conflict Graph (CCG) to model direct-mapping cache schemes and FIFO replacement policies. In the direct-mapping scheme, each block of the main memory is mapped to only one specific cache location. We divide instructions in a basic block into several cache basic blocks based on the size of the physical cache line configured by the user, represented by a node in the CCG. Each split block is then mapped to a cache line based on its starting address. If multiple cache basic blocks are mapped to the same cache line, conflicts may occur during execution, represented by edges between nodes in the CCG. Assuming there are four cache sets, each with one cache line, a program, its cache mapping table, and the CCG of the cache is set to zero, as shown in Figure 4. S and E represent the start and end nodes. $B_{i,j}$ denotes the j th cache basic block i and edge $ce{c}_{m,n,k,l}$ denotes the count cache basic block $B_{kl}$, which is evicted by $B_{mn}$.

The target equation, considering the instruction cache model, is revised to (3). $n_i$ is the number of cache blocks in basic block i, $cos{t}_{i,j}^{hit}$ ($cos{t}_{i,j}^{miss}$) denotes the execution time of $B_{i,j}$ when the cache hits (misses), and $cn{t}_{i,j}^{hit}$ ($cn{t}_{i,j}^{miss}$) denotes the execution count of $B_{i,j}$ when the cache hits (misses). Estimated WCET is the maximum sum of the execution time of the cache basic blocks in all possible control flows in the CFG.

$$WCET=max\sum _{i=1}^N\sum _{j=i}^{n_i}(cos{t}_{i,j}^{hit}\times cn{t}_{i,j}^{hit}+cos{t}_{i,j}^{miss}\times cn{t}_{i,j}^{miss});$$

(3)

In the CFG and CCG of a program, the execution count of a basic block is equal to the execution counts of all the cache basic blocks within it. The sum of the control flow into a basic block $B_i$, $i{f}_i$ is equal to the control flow out of the basic block $o{f}_i$ and the branch connected to the starting and ending nodes will only be executed once. Based on these observations, the following constraints can be established for the target equation:

$$cn{t}_{i,j}^{hit}+cn{t}_{i,j}^{miss}=cn{t}_{i,k}^{hit}+cn{t}_{i,k}^{miss},j\ne k;$$

(4)

$$cn{t}_i=i{f}_i=o{f}_i;$$

(5)

$$cn{t}_i=\sum _{u,v\in i{f}_i}ce{c}_{(u,v,i,j)}=\sum _{u,v\in o{f}_i}ce{c}_{(i,j,u,v)};$$

(6)

$$\sum _{i\in i{f}_i}ce{c}_{(i,E)}=\sum _{i\in o{f}_i}ce{c}_{(S,i)};$$

(7)

3.3. Branch Prediction Analysis

This paper adopts the GAg prediction model for micro-architecture analysis. In this model, the branch predictor first looks up the Global History Register (GHR) to obtain the current global history of the branches when predicting a branch instruction. This history is then used as an index to access entry into the Pattern History Table (PHT), which contains the results of the branch direction. Prediction errors can lead to pipeline flushes and delays in instruction prefetching. To analyze the impact of branch prediction on program execution time, let $bc{m}_i$ denote the count of prediction errors and $penalty$ represent the delay penalty. The target equation is then revised to:

$$WCET=\sum _{i=0}^N(cos{t}_i\times cn{t}_i+penalty\times bm{c}_i);$$

(8)

To obtain the constraints bounding the count of mispredictions under the GAg model, information about the execution history of each branch instruction must be recorded. Therefore, we introduce the Historical State (HS) into the CFG. Since there is only one branch instruction per basic block, each basic block will have an HS attribute that records the possible branch history when the control flow reaches that block. Assuming that the BHR is a two-bit register, the CFG, after adding the HS attribute to each basic block, is shown in Figure 5. Let 0 represent the branch that is not taken and 1 represent the branch that is taken. Basic block $B_0$ is the starting block, so its HS is always 00. Basic block $B_1$ has two incoming edges and the two possible paths to this block are $B_0\to B_1$ and $B_2\to B_3\to B_1$. The branch history of these two paths are not taken ($B_0$), not taken ($B_0\to B_1$), and taken ($B_2\to B_3$), not taken ($B_3\to B_1$); therefore, the HS is $\{00,11\}$. In an execution, the current HS of each basic block is used as its global history to access and modify the branch prediction result in the BHT, as proposed by the GAg prediction model.

After adding HS information, the condition still holds that for each basic block in the CFG, the sum of the control flows into the block equals the sum of the control flows out of the block. Let $d_{i,j}$ denote the execution count from $B_i$ to $B_j$, $hs\in B_i$ represents all HS of basic block $B_i$, $bm{c}_i^{hs}$, and $cn{t}_i^{hs}$ represents the corresponding variable when the control flow comes with the $hs$ historical state. Then, the constraints for the target equation can be obtained:

$$d_{i,j}=\sum _{hs\in B_i}{d}_{i,j}^{hs};$$

(9)

$$bm{c}_i=\sum _{hs\in B_i}bm{c}_i^{hs};$$

(10)

$$cn{t}_i=\sum _{hs\in B_i}cn{t}_i^{hs}\ge bm{c}_i^{hs};$$

(11)

If there is an edge from basic block $B_j$ to basic block $B_i$, and the HS of this control flow at $B_j$ is $h^{pre}$, the HS at $B_i$ in this control flow can occur after recording the branch of the edge $B_j\to B_i$. The sum of the incoming control flow from all possible basic blocks under all possible HSs is the execution count of a basic block. Constrains can be obtained in Equation (12).

$$cn{t}_i^h=\sum _j{d}_{j,i}^{h^{pre}}=\sum _j\sum _{h^{\prime }\in \left\{h\right|h^{pre}\to h\}}{d}_{j,i}^{h^{\prime }};$$

(12)

Let $spe{c}_{(i,j)}^{(h,n)}$ denote the count of the executions when the HS h remains unchanged on the longest path from $B_i$ to $B_j$. This means that along the path, branches are either always taken or always not taken, and n represents the branch result of $B_i$. If a basic block takes (1) the branch to the next block and the branch prediction under HS h is incorrect, the count of the incorrect prediction must be smaller than the total execution count when the basic block takes the branch. So, the following constraints can be obtained:

$$bm{c}_i^{(h,1)}\le \sum _{j}sp{c}_{(i,j)}^{(h,1)};$$

(13)

$$bm{c}_i^{(h,0)}\le \sum _{j}sp{c}_{(i,j)}^{(h,0)};$$

(14)

3.4. Prefetching Strategy

In the previous two subsections, the analyses of the instruction cache and the dynamic branch predictor were performed independently. When analyzing the cache using the CCG, the impact of branch prediction on program execution time was ignored. Similarly, when analyzing the impact of branch prediction using HS, the influence of cache hits or misses due to the branch predictor was not considered. In reality, instruction cache prefetching occurs based on the predicted branch direction, which affects whether instructions hit the cache and, consequently, influences the program’s execution time. In this paper, we assume that the processor can only allow one branch instruction to be in the prediction stage at any given time. This ensures that all previous instructions have finished executing before the branch instruction is processed.

When branch prediction is incorrect, an invalid cache may cause a cache miss, resulting in delays. For this scenario, we introduce virtual nodes for the CCG. If the cache line blocks on the predicted path conflict with the other cache line blocks, virtual node $B_{i,j}^x$ is introduced for cache basic block $B_{(i,j)}$, to describe the mutual influence between branch prediction and instruction cache. x denotes the actual execution outcome of the branch instruction. If a cache line basic block along the predicted path does not conflict with other blocks, there is no need to add a virtual node. After adding virtual nodes, the CCG in Figure 4 is modified to the CCG shown in Figure 6. For branch instruction 2, when the actual execution is 0 but the prediction is 1, we do not need to add additional nodes because, in this scenario, instruction prefetching will proceed along the erroneous path and no instructions within basic block $B_2$ conflict with other instructions. Similarly, for branch instruction 3, when the execution is 1 but the prediction is 0, we also do not need to add nodes. $B_{3.1}^{(2,1)}$ denotes the impact on cache line 3.1 when the actual execution branch instruction 2 is 1, but the prediction is 0. The edge $B_{1.2}\to B_{3.1}^{(2,1)}$ indicates that, due to the branch instruction 2 is predicted as 0, 3.1 is already in the cache. However, when instruction 1.2 is executed, the cache miss for 1.2 occurs because of 3.1. For edge $B_{3.1}^{(2,1)}\to B_{3.1}$, when the prediction for branch instruction 2 is 0 but the execution is 1, the incorrect prediction results in instruction 3.1 being cached. This scenario actually improves the cache hit rate.

After adding virtual nodes, the target equation is modified to Equation (15). $delay\text{\_}b$ represents the total time consumed by the branch prediction. $delay\text{\_}c$ denotes the total time consumed by the cache misses. The Equation illustrates that when a branch prediction error occurs, instruction prefetching will proceed along the erroneous path. Consequently, when the program executes along the correct path, at least one cache miss will occur. Here, l denotes the number of instructions fetched in a single prefetch operation.

$$WCET=\sum _{i=1}^N[cos{t}_i\times cn{t}_i+delay\text{\_}b+delay\text{\_}c]+\sum _{b\in Branch\left(P\right)}[cmp\times l];$$

(15)

$$delay\text{\_}b=bmp\times b{m}_i;$$

(16)

$$delay\text{\_}c=\sum _{j=1}^{n_i}(cmp\times c{m}_{(i,j)});$$

(17)

3.5. Pipeline Analysis

The purpose of pipeline analysis is to comprehensively consider the effects of both the cache model and branch prediction, and to calculate the execution time for a basic block. Ref. [23] analyzes the impact of out-of-order execution pipelines on program execution time, noting that the execution time cannot be simply represented by the longest path of instruction execution; dependencies between instructions must also be considered. This paper achieves this by analyzing the commonly used five-stage pipeline architecture in ARMv8 processors: Instruction Fetch (IF), Decode (ID), Instruction Execute (EX), Memory Access (MEM), and Write Back (WB). We use execution graphs to model and analyze the pipelines of out-of-order executions. Execution graphs illustrate the dependencies between instructions using directed edges as follows:

• The dependency between different stages of the same instruction. The completion of the previous stage is required before proceeding to the next stage.
• The dependency between different instructions in the same pipeline stages. Earlier instructions in the program have a higher priority.
• The data dependency between instructions.
• Queuing for idle Instruction Fetch Buffers (I-buffers) and Reorder Buffers (ROB).

Assuming the size of the Instruction I-buffer is 2 and the size of the Reorder ROB is 4, a program and its corresponding execution graph is shown in Figure 7. The edge $WB\to EX$ represents the data dependency between instructions, $ID\to IF$ and $MEM\to ID$ represent the dependencies between instructions due to the sizes of the I-buffer and ROB, respectively, and the dashed line $EX\to EX$ indicates instructions competing for the same functional unit.

Since the analysis of the cache is performed using the CCG, the cache is ignored when establishing execution graphs; we assume that all instructions hit the cache. However, errors in branch prediction can cause the instruction pipeline to prefetch instructions along an incorrect path. To address this, we add instructions with the same size as the Reorder Buffer (ROB) along the erroneous path after the mispredicted branch instruction in the execution graph.

For a node in execution phase, its earliest finish time and latest finish time can be obtained using Algorithm 1. $earliest\left[t_i^{start}\right]$ denotes the earliest start time of node i, $earliest\left[t_i^{finish}\right]$ denotes the earliest finish time, $latest\left[t_i^{start}\right]$ denotes the latest start time, and $latest\left[t_i^{finish}\right]$ denotes the latest finish time. The latest finishing time of the last node is the estimated WCET. The functions in the algorithm are:

• $LatestTimes\left(G\right)$ calculates the latest ready, start, and finish times for the nodes. The latest start time depends on its latest ready time, which depends on the latest finish time of its predecessor or competitors. If a competitor has a lower priority than the instruction in question, the competitor will be excluded, and those whose execution times do not overlap will also be excluded. If a competitor has a higher priority than the instruction, it is assumed that all nodes preceding this competitor will delay the node. Once a node’s latest start time is obtained, the latest ready times of its successor nodes are updated.
• $EarliestTimes\left(G\right)$ calculates the earliest ready, start, and finish times of nodes. Unlike $LatestTimes\left(G\right)$, the calculation of these times only considers competitors that conflict with the node’s preparation time and hardware resources.

Algorithm 1: Basic Block WCET Analysis Algorithm

4. Implementation

This section provides a description of the implementation process of the tool, including the establishment of the CFG and CCG, the extension of the CFG, and WCET calculation.

Each basic block in the CFG must indicate whether it contains a branch instruction. For blocks with branch instructions, there are two outgoing edges representing the two possible execution directions of the branch instruction. In addition to edges, other information, such as the basic block index, must also be stored. The data type of a basic block is shown in

Table 2. Data type of basic block.

Data Type	Name	Description
$int$	$id$	Index of the basic block.
$proc\text{\_}{t}^{*}$	$proc$	Function the node belongs to.
$addr\text{\_}t$	$sa$	Starting address of the node.
$int$	$size$	Size of the basic block.
$int$	$num\text{\_}inst$	Number of instructions in the basic block.
$de\text{\_}inst\text{\_}{t}^{*}$	$code$	Pointer to the first instruction in the basic block.
$bb\text{\_}type\text{\_}t$	$type$	Whether include branch instruction.
$cfg\text{\_}edge\text{\_}{t}^{*}$	$out\text{\_}n$, $out\text{\_}t$	Outing edges of the basic block.
$int$	$num\text{\_}in$	Number of the edges out.
$cfg\text{\_}edge\text{\_}{t}^{**}$	$int$	Set of the edges in.

.

To analyze the impact of the cache on program execution time, basic blocks are divided into multiple cache basic blocks. If a basic block is smaller than the size of a cache line configured by the user, it is treated as a single node. Otherwise, the basic block is divided into multiple cache basic blocks. The data type for a cache basic block is shown in

Table 3. Data type of cache basic block.

Data Type	Name	Description
$inst\text{\_}t$	$start\text{\_}inst$	Starting instruction of the basic block.
$size\text{\_}t$	$lb\text{\_}size$	Size of the cache basic block.
$unsigned$	$lb\text{\_}set$	Cache line the basic block mapped to.
$cfg\text{\_}node\text{\_}t$	$cfg\text{\_}bb$	Basic block the cache basic block belongs to.
$unsigned$	$id$	Index of the cache basic block in CFG.
$ccg\text{\_}edge{\text{\_}}^{*}$	$edges\text{\_}in$	Set of edges in.
$ccg\text{\_}edge{\text{\_}}^{*}$	$edges\text{\_}out$	Set of edges out.

. Each cache basic block must record information such as the starting instruction address, the index of the cache set it is mapped to, and the index of the basic block it belongs to. This data type can also be used to describe nodes in the CCG. Consequently, the edges in the CCG only need to record the indices of the start and end nodes, and the count of conflicts.

For branch prediction analysis, the introduction of HS requires the extension of CFG. A new node is used to store the branch history information for nodes in the CFG. The data type is shown in

Table 4. Data type of HS node in CFG.

Data Type	Name	Description
$tcfg\text{\_}node\text{\_}{t}^{*}$	$bbi$	Basic node pointed to.
$short$	$bhr$	Value of BHR.
$short$	$pi$	Index of prediction table, calculated by BHR.
$tcfg\text{\_}node\text{\_}{t}^{*}$	$out$	Set of edges out.
$tcfg\text{\_}node\text{\_}{t}^{*}$	$in$	Set of edges in.
$int$	$flags$	Flags indicating whether the path is feasible.

. The main steps in analyzing branch prediction are collecting the set of instructions on the erroneous path, constructing the HS of nodes, and analyzing the HSs of edges to feasible nodes. Function $collect\text{\_}mp\text{\_}insts$ is used to collect instructions along the predicted path, function $build\text{\_}bfg$ collects control flow information between adjacent branch instructions under a specific HS, and function $build\text{\_}btg$ uses BFS to collect the information of all nodes reachable from a specific CFG node.

The pipeline model analysis is implemented using execution graphs, with the goal of determining the execution time of a basic block. When computing the execution time of a basic block, it is insufficient to consider the block in isolation; the block’s context within the CFG must also be considered. For example, if the instruction fetch buffer size is 2 and the instruction reorder buffer size is 4, then before the execution of a basic block, there will be 5 instructions waiting in the pipeline and one instruction being executed. Instructions in the cache may have dependencies on nearby instructions. Instructions that have dependencies on the previous basic block are referred to as the prologue, while those with dependencies on the subsequent basic block are called the epilogue. By using the functions $collect\text{\_}prologs$ and $collect\text{\_}epilogs$ to traverse paths in the CFG, we can establish the context between cache basic blocks. This allows us to account for dependencies within the contextual environment when analyzing the execution graph.

In the implementation of the pipeline analysis, the function $est\text{\_}units$ calculates the execution time of each basic block in the CFG. The function $ctx\text{\_}unit\text{\_}time$ analyzes paths within the CFG, focusing on branch prediction and the contextual environment of the basic blocks. The function $create\text{\_}egraph$ establishes the execution graph for each basic block, while the function $est\text{\_}egraph$ applies Algorithm 1 to derive the final WCET target equation.

IPET solves problems using ILP. The overall construction process for the ILP problem is shown in Figure 8. There are two branches related to branch prediction: the function after the first branch prediction extracts constraints related to branch prediction, while the function after the second branch extracts constraints related to the erroneous path prefetching strategy. The roles of the other functions are as follows:

• $cost\text{\_}func$ generates linear target equations based on the micro-architecture configured by the user. For scenarios involving branch prediction execution, $cost\text{\_}term\left(BP\text{\_}CPRED\right)$ or $cost\text{\_}term\left(BP\text{\_}MPRED\right)$ is invoked to construct target equations for correct branch prediction or branch prediction errors, respectively. $mpcost\text{\_}func$ is invoked to establish the target Equation (15) to consider branch prediction and the instruction cache, along with their interactions.
• $tcfg\text{\_}cons$ generates constraints derived from the control flow information.
• $bfg\text{\_}cons$ generates constraints derived from the branch prediction.
• $cache\text{\_}cons$ and $mp\text{\_}cache\text{\_}cons$ generates constraints for cache hits or misses, as well as for constraints, when executing along erroneous paths.
• $user\text{\_}cons$ reads user-input constraint files and parses the linear constraint for the ILP problem.

Figure 8. Process of implementing the ILP problem.

Figure 8. Process of implementing the ILP problem.

The ILP designed in this paper is based on the ILOG/CPLEX format [24]. There are two ILP solvers capable of solving problems in this format: CPLEX, a commercial software, and $lp\text{\_}solver$, a free and open-source alternative. This paper uses $lp\text{\_}solver$ 5.5.0.4 as the third-party ILP solver for calculating the WCET.

5. Results and Discussion

Figure 9 gives the analysis WCET in cycles for the set of Mälardalen benchmarks [25] supported by our WCET analysis tool. The processor configuration of the tool we use in experiments is listed in

Table 5. Processor configuration.

Module	Parameter	Description
Cache	-cache:il1 il1:768:64:3:l	L1 instruction cache that is a 48 KB 3-way set-associative cache with a 64-byte cache line; LRU replacement policie.
	-cache:il2 il2:16384:64:16:l	L1 instruction cache that is a 1 MB 16-way set-associative cache with a 64-byte cache line; LRU replacement policie.
	-cache:dl1 none	Data caching is not considered
Branch Prediction	-bpred:2lev 1 1024 4 1	Size of first level entry is 1; size of second level entry is 1024; Width of BHR is 4; Support branch history.
	-fetch:mplat 15	Branch mis-prediction latency is 15 cycles
Instruction Pipeline	-fetch:ifqsize 4	Instruction prefetch queue size is 4.
	-decode:width 4	Instruction decode width is 4 insts/cycle.
	-issue:width 4	Instruction transmission width is 4 insts/cycle.
	-commit:width 4	Instruction commisstion width is 4 insts/cycle.
	-issue:inorder true	Run pipeline with in-order issue.
	-issue:wrongpath true	Issue instructions down wrong execution paths
Others	-ruu:size 128	Size of register update unit is 128.
	-lsq:size 64	Size of load/store queue is 64.
	-mem:width 8	Size of memory block is 32 bytes.

. Some user-provided constraints we used for the benchmarks are shown in

Table 6. User constraints for benchmarks.

Insertsort	cnt	Matmult	bs
c0.1 − 1024 c0.0 ≤ 0 c0.3 − 1024 c0.2 ≤ 0 c0.5 − 512 c0.4 ≤ 0	c0.2 − 128 c0.1 ≤ 0 c0.1 − 128 c0.0 ≤ 0 c0.6 − 128 c0.5 ≤ 0 c0.6 − 128 c0.5 ≤ 0 c0.5 − 128 c0.4 ≤ 0	c0.1 − 24 c0.0 ≤ 0 c0.2 − 24 c0.1 ≤ 0 c0.6 − 24 c0.5 ≤ 0 c0.5 − 24 c0.4 ≤ 0 c0.11 − 24 c0.10 ≤ 0 c0.10 − 24 c0.9 ≤ 0 c0.9 − 24 c0.8 ≤ 0	c0.1 − 1024 c0.0 ≤ 0 c0.3 − 1024 c0.2 v 0 c0.4 − 512 c0.3 ≤ 0

.

Among Mälardalen WCET benchmarks, the insertsort program has the largest estimated WCET, in contrast to the binary search program $bs$ and the finite impulse response filter program $fir$. This is because we changed the length of the target reversed array in $insertsort$ to 1024 but $bs$ only sorts 15 elements.

Two boards equipped with ARMv8-A CPUs, the Raspberry Pi 4 Model B from Sony, Pencoed, Wales, and the Firefly ROC-RK3568-PC-SE from T-CHIP, Zhongshan, Guangdong Province, China, are also used to obtain the observed WCETs of the benchmarks in a physical environment. Execution time in processor cycles is obtained by reading the generic timer register of the ARMv8-A CPU. The difference between the values before and after execution is the measured execution time of the program. Five measured execution times are averaged to obtain the final observed WCET. We configure the analysis tool to make the micro-architecture similar to the target processor. The two sets of measured and observed WCETs of the benchmarks are shown in Figure 10 and Figure 11.

Given a C program and a processor configuration, the static analysis method guarantees that the estimated WCET is not less than the program’s actual execution time for any input. As shown in the figure, the ratio of the estimated to observed WCET values for all benchmarks is greater than 1, which ensures the reliability of the analysis tool. The analysis result is considered precise if the estimated value is close to the observed value.

However, some estimated WCET values for benchmarks are up to 2–3 times larger than the observed WCET. There may be two reasons for these differences. First, our micro-architecture modeling may not be detailed enough. For instance, features like data caches and Translation Lookaside Buffers (TLBs) supported by modern processors are not included in our model, leading to a lack of constraints. Second, the differences may be attributed to the pessimistic nature of the static analysis method.

6. Conclusions

This paper designs a WCET analysis tool that includes using a CCG to address cache conflicts, employing a control flow analysis method based on historical states to analyze branch predictors, and examining instruction cache prefetching strategies based on erroneous branch prediction paths by adding virtual nodes to the CCG. When calculating the execution time of a basic block, this paper integrates instruction pipelines into the analysis and uses execution graphs to determine the execution time of individual basic blocks.

After implementation, we evaluate the performance of the analysis tool by comparing the estimated WCET of benchmarks with the observed values for two boards. The ratio of estimated to observed WCET values for all benchmarks is greater than 1, demonstrating the tool’s reliability. Some estimated values differ greatly from the observed values. This discrepancy is due to our incomplete modeling of modern processor features.

Future works will mainly include the following:

• Model and analyze shared caches among multi-core to improve analysis accuracy.
• Optimize the micro-architecture model to make it more suitable for modern processors.
• Adopt algorithms with lower time complexity so that the tool can analyze more complex programs.
• Use estimated WCET bounds to perform schedulability analyses for programs [26].