Formal Hardware/Software Co-Verification by ... - Semantic Scholar

Formal Hardware/Software Co-Verification by Interval Property Checking with Abstraction Minh D. Nguyen, Markus Wedler, Dominik Stoffel, Wolfgang Kunz Electronic Design Automation Group, University of Kaiserslautern

{thalmaier,nguyen,wedler,stoffel,kunz}@eit.uni-kl.de

ABSTRACT Ensuring functional correctness of hardware and software is a bottleneck in every design process of Embedded Systems. This paper proposes an approach to formally verify low-level software in conjunction with the hardware. The proposed approach is based on Interval Property Checking (IPC) that has proved successful on large industrial hardware designs. In this paper, IPC is extended by a specific abstraction technique that makes it tractable for hardware/software co-verification on realistic industrial designs. In the proposed methodology sets of finite state sequences of the system are abstracted by interval properties. This allows us to handle long sequences of state transitions in the hardware as they occur when running programs. We demonstrate the feasibility of our approach using the example of an industrial LIN software running on a public domain microprocessor platform.

Categories and Subject Descriptors B.8.2 [PERFORMANCE AND RELIABILITY]: Performance Analysis and Design Aids; B.6.3 [LOGIC DESIGN]: Design Aids— Verification

General Terms Verification, Design, Algorithms

Keywords Formal Verification, Embedded System, Hardware/Software, Abstraction

1. INTRODUCTION Verification of an embedded system design is a tremendous task and requires a large variety of verification techniques applied at all design levels ranging from the application and system software to the register transfer level (RTL) descriptions of the hardware. In today’s industrial practice, software verification is almost exclusively based on simulation techniques. At the hardware level, formal techniques have gained popularity and complement traditional simulation. In fact, even complex processor implementations can be completely verified formally against their instruction set architecture (ISA) models. It is therefore promising to explore how to extend formal approaches of hardware verification to low-level software

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DAC 2011, June 5-10, 2011, San Diego, California, USA. Copyright 2011 ACM ACM 978-1-4503-0636-2/11/06 ...$10.00.

such that a formal approach to hardware/software co-verification becomes possible. This opens new perspectives for the use of formal techniques in an industrial setting. Instead of guaranteeing correctness of a processor with respect to the specified ISA the formal guarantee could be given that the application programmer interface (API) behaves as described in a more abstract specification. This would provide a clean and formally verified interface as it is really needed by most users and would be especially useful when the definition of an ISA model is not feasible such as in some cases of highly optimized Application-Specific Instruction Set Processors (ASIPs) and Weakly Programmable IPs [13]. However, formally verifying low-level software, such as bring-up or initialization programs or drivers for bus protocols, in conjunction with the hardware on which they are running is a major challenge. Instead of formally verifying a single processor instruction we now have to verify programs that run over hundreds or thousands of instructions. This complexity can only be handled if we choose formal verification techniques that are best suited to handle models of large complexity. This is the reason why, in the context of this paper, we are particularly interested in formal verification methods by Bounded Model Checking (BMC) [3] or Interval Property Checking (IPC) [15, 14] which are based on satisfiability (SAT) solving and a bounded system model. In particular, the operationoriented methodology of IPC provides us with the basis for a fairly simple but effective abstraction mechanism. In IPC, operational behavior of the system is specified within finite time windows using interval properties. Differently from BMC the unrolled circuit is not constrained by the initial states of the circuit. Therefore, the interval properties are verified unboundedly against the system. In traditional RTL hardware verification behaviors are considered running, typically, over less than a hundred clock cycles. However, in HW/SW co-verification we formulate properties spanning thousands of clock cycles at the hardware level. As a consequence, the computational model becomes intractable even for the most powerful solvers. In this paper, we tackle this problem by an abstraction mechanism that is well adapted to typical situations in HW/SW coverification and leverages specific strengths of the IPC operationoriented verification paradigm.

1.1

Related Work

When the size of the system under verification increases its state space grows exponentially. A possible solution to this problem can be to consider more abstract models. The abstract model is conservatively created from the concrete system such that if the property holds on the abstract model, it also holds on the concrete system [5]. Two methods that are commonly used are localization reduction [12] and predicate abstraction such as in [10]. If the abstract model over-approximates the reachable state space a property may fail on the abstract model but still hold on the concrete system. In this case, we need to refine the abstract model. The refinement process is often guided by analyzing false counterexamples [6, 9].

In [4] the authors propose to use CTL properties as a replacement for concrete components in a large system. In [16], the authors extend predicate abstraction by introducing predicates of the transition relations. Similar to [4, 17] we use the properties to abstract the concrete system, however, we do not transfer the properties into automaton models. Most work on formal software verification such as [2] is based on hardware-independent models. Only a few works exist that consider hardware-dependent software or target formal HW/SW coverification, such as [7, 8]. However, in those works, the software part still needs to be transferred manually into a hardwaredependent model. Also the resulting models are fairly low-level, thus leading to computational complexity problems when considering larger programs.

1.2 Contribution We propose an abstraction methodology to improve the robustness of interval property checking when proving long, global interval properties of embedded systems. In contrast to other abstraction methods [6, 10, 9], we do not verify the property against the computational model generated from an abstract system model. Hence, we do not need to calculate the transition relation of some abstract finite state machine. Instead, our abstraction mechanism modifies the unrolled finite state machine of the concrete design by replacing some parts of it by interval properties. Differently from [17] we preserve the concrete transition relation in certain time intervals while abstracting it in others. This is highly useful in HW/SW coverification where different levels of abstraction are needed in different parts of the program. For example, cycling in a waiting loop may allow a stronger abstraction than executing complex hardware operations. Moreover, our method can abstract the state variables modeling the RAM, hence, a large memory size does not cause the state explosion problem as usually happens when embedded systems are verified. Our abstraction mechanism allows us to prove meaningful properties against an embedded system consisting of a processor, a RAM module, a ROM module and some peripherals. In such properties, we can specify not only the behavior of the software program as it is executed by the processor (e.g., by referring to program variables) but also the behavior of the system hardware running in parallel with the processor (e.g., by referring to input/output signals of peripherals).

2. EMBEDDED SYSTEM VERIFICATION ON THE HARDWARE LEVEL 2.1 Embedded System – Hardware Level In this paper, we want to verify an embedded system modeled at the hardware level. We consider the hardware and the software program (or program in short) in a joint computational model. This allows us to relate hardware events and corresponding software actions and to detect flaws in their interplay. Figure 1 shows how to construct the design under verification (DUV) for the embedded system at the hardware level. The program specified at the software level (e.g., in C language) is compiled into executable code and is loaded into the program memory that is connected with the processor on the hardware level (e.g., in an HDL). Therefore, the embedded system on the hardware level consists of a processor connected with a program memory (compiled program loaded in a ROM), a data memory (RAM) and peripherals, e.g., a UART (Universal Asynchronous Receiver/Transmitter). These modules are connected together and are compiled to build the DUV. The embedded system at the hardware level can be considered as a sequential circuit 𝐶(𝑉, 𝑉 ′ , 𝑋) with the set of state variables 𝑉 , the set of next state variables 𝑉 ′ , and the set of input signals 𝑋.

Figure 1: Construction of embedded system in hardware level The circuit 𝐶 is modeled as a finite state machine 𝑀 (𝑆, 𝑆0 , Σ, 𝛿), where 𝑆 is the set of states encoded by state variables 𝑉 ; 𝑆0 is the set of initial states; Σ is the set of input symbols encoded by input signals 𝑋; 𝛿 : 𝑆 × Σ → 𝑆 is the transition function. For keeping our formalism simple we assume that outputs are part of the state vector. Among the state variables 𝑉 of the embedded system, the program counter register PC of the processor plays an important role. It determines the program position where instructions are executed, and it controls the overall behavior of the embedded system. The finite state machine (FSM) being encoded by the PC is the control flow graph of the program. D EFINITION 1. Given an embedded system 𝐶(𝑉, 𝑉 ′ , 𝑋) being modeled by the FSM 𝑀 (𝑆, 𝑆0 , Σ, 𝛿). Let PC ⊂ 𝑉 be a subset of state variables named the program counter of the system. The ˆ where ˆ 𝛿), ˆ (𝑆, ˆ 𝑠ˆ0 , Σ, control flow graph (CFG) of 𝐶 is a tuple 𝑀 ˆ 𝑆 is the set of program positions (or CFG states) encoded by the ˆ program counter PC; 𝑠ˆ0 ⊂ 𝑆 is the initial program position; Σ is the set of input symbols that are being encoded by the signals ˆ = (𝑉 ∖ PC) ∪ 𝑋; 𝛿ˆ : 𝑆ˆ × Σ ˆ → 𝑆ˆ is the program transition 𝑋 function. Here, our concept of a CFG is closely related to the hardware model of the embedded system. It is an abstraction of the embedded system on the hardware level. Our CFG differs from the conventional CFG in that it is not extracted only from the high-level program as in previous work [11]. Although the embedded system is a very large system and its model 𝑀 consists of many states, the CFG is considerably smaller and can be explicitly represented by a state transition graph (STG). Note that the states where the control flow differs from implicit PC incrementation (as in branches, calls or returns) are particularly important to our approach.

Figure 2: Example program and its control flow graph

Figure 2 shows a simple program computing the first 100 Fibonacci numbers and the STG of its simplified CFG. Each state in the STG of Fig. 2 is labeled with the line number in the program. In the actual CFG, these states correspond to starting addresses of linear instruction sequences (i.e., sequences of instructions with automatic PC incrementation). Note that the relationship between the PC values and the code lines is usually not a one-to-one mapping. Therefore, the CFG defined by the PC is different from the CFG extracted from the program code.

2.2 Modeling execution sequences In our methodology, we analyze the execution of individual segments of the program. Because hardware and software are considered together, executions of program segments correspond to finite runs of the FSM 𝑀 that is implemented by the circuit 𝐶 as defined above. In order to simplify notations, in the following, we consider the inputs of the circuit as part of a generalized state. A generalized state 𝑠 is a pair (𝑧, 𝑥) where 𝑧 represents a state vector encoded by the state variables 𝑉 and 𝑥 represents the input vector triggering the next transition. For a transition (𝑠𝑖−1 , 𝑠𝑖 ) of the FSM 𝑀 it holds that 𝑧𝑖 = 𝛿(𝑧𝑖−1 , 𝑥𝑖−1 ). Using this notation, we define the transition relation 𝑇 of the FSM 𝑀 : 𝑇 (𝑠𝑖−1 , 𝑠𝑖 ) = 𝑇 ((𝑧𝑖−1 , 𝑥𝑖−1 ) , (𝑧𝑖 , 𝑥𝑖 )) := (𝑧𝑖 ≡ 𝛿(𝑧𝑖−1 , 𝑥𝑖−1 )) In order to model execution, we define sequences and sequence predicates. An 𝑙-sequence 𝜋𝑙 is a sequence of 𝑙 + 1 (generalized) states (𝑠0 , . . . , 𝑠𝑙 ). An 𝑙-sequence predicate 𝜎(𝜋𝑙 ) is a Boolean function characterizing a set of 𝑙-sequences; 𝑙 is called the length of the predicate. For the special case 𝑙 = 0, a sequence predicate is also called state predicate. Note that we allow an 𝑙-sequence predicate to be applied also to a longer sequence, i.e., to an 𝑚-sequence (𝑠0 , . . . , 𝑠𝑙 , . . . , 𝑠𝑚 ) with 𝑚 > 𝑙. The predicate is then evaluated on the 𝑙-prefix (𝑠0 , . . . , 𝑠𝑙 ) of the sequence. In case we would like to evaluate the predicate on an 𝑙-subsequence other than the prefix we need to shift the predicate in time using the next operator defined as follows: next(𝜎𝑙 , 𝑛)((𝑠0 , . . . , 𝑠𝑛−1 , 𝑠𝑛 , 𝑠𝑛+1 , . . . , 𝑠𝑛+𝑙 )) := 𝜎𝑙 ((𝑠𝑛 , 𝑠𝑛+1 , . . . , 𝑠𝑛+𝑙 )). The next(𝜎𝑙 , 𝑛) operator shifts the starting point of the evaluation of a predicate 𝜎𝑙 to the 𝑛-th state in a sequence; next(𝜎𝑙 , 𝑛) is a sequence predicate of length (𝑛 + 𝑙). The usual Boolean operators ∨, ∧, ¬, ⇒ are also applicable to 𝑙-sequence predicates. If 𝑙max is the largest length of all sequence predicates in a Boolean expression built with these operators, then the value of the expression is defined only for 𝑚-sequences with length 𝑚 ≥ 𝑙max . We also define a concatenation operation ∘ for 𝑙-sequence predicates: 𝜎𝑙 ∘ 𝜎𝑘 = 𝜎𝑙 ∧ next(𝜎𝑘 , 𝑙) This predicate evaluates to true for all sequences that begin with a sequence of length 𝑙 characterized by 𝜎𝑙 and continue with a sequence of length 𝑘 characterized by 𝜎𝑘 , where the last state in the 𝑙-sequence is the first state in the 𝑘-sequence. If conjoined with 𝑙 times the transition relation, an 𝑙-sequence predicate becomes an 𝑙-path predicate: 𝑙 ⋀ 𝑇 (𝑠𝑖−1 , 𝑠𝑖 ) 𝑃𝑙 (𝜋𝑙 ) = 𝑃𝑙 ((𝑠0 , . . . , 𝑠𝑙 )) = 𝜎((𝑠0 , . . . , 𝑠𝑙 )) ∧ 𝑖=1

We define a path predicate 𝑀𝑙 (called ispath in [18]) that represents an unrolling of the transition relation of the FSM 𝑀 into 𝑙 time frames. The predicate evaluates to true if the 𝑙-sequence given as its argument is a valid path in the state transition graph of the

FSM 𝑀 . 𝑀𝑙 ((𝑠0 , . . . , 𝑠𝑙 )) =

𝑙 ⋀

𝑇 (𝑠𝑖−1 , 𝑠𝑖 )

𝑖=1

Using the ∘ operator defined above, we can also write 𝑀𝑙 = 𝑀1 ∘𝑀1 ∘ . . . ∘𝑀1 (𝑙 times) or 𝑀𝑙 = 𝑇 ∘𝑇 ∘ . . . ∘𝑇 (𝑙 times). A hardware state 𝑠 can be mapped to a state 𝑠ˆ in the control flow graph by an abstraction function 𝛼(𝑠). Correspondingly, a sequence of hardware states 𝜋𝑙 = (𝑠0 , . . . , 𝑠𝑙 ) is mapped to a sequence of states (program locations) 𝜋 ˆ𝑙 = (𝑠ˆ0 , 𝑠ˆ1 , . . . , 𝑠ˆ𝑙 ) with 𝑠ˆ𝑖 = 𝛼(𝑠𝑖 ) in the control flow graph, called execution sequence. The mapping is not one-to-one because the PC of the processor, encoding 𝑠ˆ, may keep its value over several cycles of different states 𝑠 of the hardware. We define a (backward) mapping function 𝛽(ˆ 𝑠) that maps a program location 𝑠ˆ to the set of hardware states 𝛽(ˆ 𝑠) that describe only the very instant where the instruction code at program location 𝑠ˆ is loaded into the decode stage of the processor pipeline. Other states with the same PC value are not included, i.e., 𝛽 is not the inverse of 𝛼.

2.3

Interval Property Checking

Interval Property Checking (IPC) is a SAT-based property checking technique. Similar to Bounded Model Checking, it uses a SAT solver to refute an interval property. An interval property 𝑃𝑙 is an implication 𝜑𝑙 = (𝐴𝑙 ⇒ 𝐶𝑙 ) where both 𝐴𝑙 (called assumption) and 𝐶𝑙 (called commitment) are sequence predicates of length 𝑙. An IPC checker proves that for all sequences 𝜋𝑙 = (𝑠0 , . . . , 𝑠𝑙 ) where the assumption holds on the design the commitment does too: 𝑀𝑙 (𝜋𝑙 ) ⇒ (𝐴𝑙 (𝜋𝑙 ) ⇒ 𝐶𝑙 (𝜋𝑙 )), i.e., 𝑀𝑙 (𝜋𝑙 ) ⇒ 𝜑𝑙 (𝜋𝑙 )

(1)

The property check can be formulated as a SAT problem. Refuting 𝑀𝑙 ⇒ 𝜑𝑙 means satisfying (𝑀𝑙 ∧ ¬𝜑𝑙 ). A satisfying set is a path 𝜋𝑙 representing a counterexample of the property. It is a false counterexample if the state 𝑠0 in the path is unreachable from the initial state. In order to rule out unreachable counterexamples in practice, it is common to add invariants to the proof problem [14]. The strengthened proof problem looks like this: (Φ0 (𝜋𝑙 ) ∧ 𝑀𝑙 (𝜋𝑙 )) ⇒ 𝜑𝑙 (𝜋𝑙 ) Here, the predicate Φ0 (𝜋𝑙 ) is a state predicate characterizing an over-approximation of the reachable state set at the head (i.e., the starting state) 𝑠0 of the 𝑙-sequence 𝜋𝑙 .

2.4

Specification of embedded systems

The behavior of the embedded system is specified on the hardware level using temporal logic. In industrial practice, several languages can be used such as SVA or ITL (InTerval Language), a proprietary language developed by OneSpin Solutions [15]. ITL can be mapped to a subset of LTL as described in the following. An interval LTL formula is an LTL formula that is built using only the Boolean operators ∧, ∨, ¬ and the “next-state” operator X . We define a generalized next-state operator X 𝑡 that denotes finite nestings of the next-state operator, i.e., if 𝑝 is an interval LTL formula, then X 𝑡 𝑝 = X X 𝑡−1 𝑝 for 𝑡 > 0 and X 0 𝑝 = 𝑝. An interval LTL formula is said to be in time-normal form if the generalized next-state operator X 𝑡 is applied only to atomic formulas. Since in LTL, X (𝑎 ∨ 𝑏) = X 𝑎 ∨ X 𝑏 and X (𝑎 ∧ 𝑏) = X 𝑎 ∧ X 𝑏 and ¬X 𝑎 = X ¬𝑎, any interval LTL formula can be translated to timenormal form. It is easy to see how an interval LTL formula can be used to specify an 𝑙-sequence predicate: The generalized next-state operator refers to the state variables of the system at the different “time” points in the sequence. The maximum power of the X operator occuring in the property determines the length of the property. Note that in IPC, a property 𝑝 is proven to hold globally (unboundedly) because the computational model for the proof assumes

an arbitrary starting state 𝑠0 (and not the initial state as in BMC). In other words, the property is implicitly preceded by a G operator: G 𝑝 = G (𝑎 ⇒ 𝑐) with 𝑎 and 𝑐 being the interval LTL formula for the assumptions 𝐴𝑙 and commitments 𝐶𝑙 , respectively. For the embedded system, we normally consider a portion of the system behavior when the processor executes a segment of the pro𝑠0 , 𝑠ˆ1 , . . . , 𝑠ˆ𝑙 ). We gram given by an execution sequence 𝜋 ˆ𝑙 = (ˆ write the interval property describing the system behavior in the following way: 𝜑𝑙

:=

(PC = 𝑠ˆ0 ∧ 𝑎) ⇒ (X 𝑙 PC = 𝑠ˆ𝑙 ∧ 𝑐)

(2)

The assumptions 𝑎 in this property include definitions to uniquely identify the clock cycle in which the first instruction in the sequence is loaded into the decode stage of the processor, i.e., (PC = 𝑠0 ), as well as constraints to uniquely determine the 𝑠ˆ0 ∧ 𝑎) ⇒ 𝛽(ˆ execution sequence 𝜋 ˆ𝑙 . For example, the interval property in Eq. 3 specifies the following behavior of the embedded system: “When the PC is addr1 and there is a start input, then, after 20 clock cycles, the PC will reach addr2 and the value of data (in memory) is increased by 5”. 𝜑𝑙 = (PC = addr1 ∧ x = start (3) 20 ⇒ (X PC) = addr2 ∧ (X 20 data) = data + 5)

3. PROPERTY-BASED ABSTRACTION A problem of SAT-based verification techniques such as BMC, or IPC is the complexity of the computational model in Eq. 1. The proof problem 𝑀𝐿 ⇒ 𝜑𝐿 becomes infeasible for the SAT solver for large property lengths 𝐿. Especially, interval properties for an embedded system are often very long because the operational behavior of the embedded system consists of many program instructions and takes many hardware clock cycles to execute. In this section, we propose a partial abstraction method to reduce the complexity using short properties.

3.1 Motivation and Basic Idea When the processor executes the program it performs many local execution steps and uses many temporary registers. This helps to increase the performance and the usage of hardware resources in the processor. For example, to calculate the statement 𝑐 = 𝑎 + 𝑏, the processor needs to perform a number of steps: load the values of memory cells 𝑎, 𝑏 into temporary registers R1 and R2; add R1 and R2 and put the result into R3; and finally store R3 into memory cell 𝑐. Moreover, each of the above steps can be divided further into shorter steps in the pipeline structure of the processor. The sequence of such steps corresponds to a long run of the system. Therefore, the iterative circuit model representing the run consists of many logic components and is complex. However, the results of local steps are usually not needed when the statement is considered in a global operation of the system. Only the final result of the statement needs to be specified. Hence, the behavior of a statement, or a portion of the program can be specified by an interval property that refers to the state variables at a few time points, only. For example, the property in Equation 3 refers to the PC register, the input 𝑥 and the data register at the time points 1 and 20. The translation of the property, thus, consists of less logic and is simpler than the iterative circuit model. Consequently, if we replace the iterative circuit model corresponding to a program portion by the translation of the property specifying that program portion we can obtain a much simpler computational model for proving a global software operation. The basic idea of our abstraction method is illustrated in Figures 3 and 4. The overall goal (Fig. 3) is to prove a “long” property 𝜑𝐿 spanning many clock cycles. The straightforward approach of constructing a long unrolling of the circuit into 𝐿 timeframes and attempting to prove the property directly fails because of complexity. However, a number of smaller properties 𝜑1 , 𝜑2 , 𝜑3 are feasible for the

"Long" unrolling of circuit

ML

M l2

⇓

⇓

ϕ 1l1

⇓ "Long" property

M l1

ϕL

Figure 3: Proof goal

ϕ 2l2

M l3 ⇓

ϕ 3l3

⇓

ϕL

Figure 4: Proof steps

SAT solver to prove. These properties are now used to partially or fully abstract the circuit unrolling. Wherever a short property 𝜑𝑘 describes a sub-sequence of the instructions verified by the long property 𝜑𝐿 it replaces the corresponding time frames of the transition function of the embedded system’s hardware. Note that this abstraction is not a trivial one as may seem at first glance. We are concatenating the short properties not in an implicative manner, i.e., we do not prove that the commitment 𝑐𝑖 of a property 𝜑𝑖 implies the assumption 𝑎𝑖+1 of the successor property 𝜑𝑖+1 nor would we make use of this implication should it exist. (This would correspond to some horizontal implication arrows in Fig. 4.) In fact, it may even be that properties are concatenated with original time frames of the hardware transition function if these time frames cannot be covered by a proven shorter property. We do, however, exploit transitivity of the vertical implication relationships indicated in Fig. 4: If time frames can be partially abstracted by proven short properties and the long property can be proven based on this abstraction then the long property also holds for the unabstracted circuit unrolling. Note that our abstraction mechanism allows modular and hierarchical abstraction. Modularly, we can replace the iterative circuit model of some components in the system by the properties that are proven for those components. Hierarchically, we can also replace partially abstracted circuit unrollings by global properties to prove even longer properties. In the next section, we will describe our abstraction method in more detail.

3.2

Property-Based Abstraction Method

We begin with a set of 𝑚 properties {𝜑𝑘𝑙𝑘 } with 1 ≤ 𝑘 ≤ 𝑚. In this notation, superscript 𝑘 is an index distinguishing properties in the set, subscript 𝑙𝑘 denotes the length of each property 𝑘. We assume that every property has been proven to hold on the design, i.e., 𝑀𝑙𝑘 ⇒ 𝜑𝑘𝑙𝑘 . The goal is to prove a “long” property 𝜑𝐿 with a large length 𝐿. Suppose the computational model for a straightforward IPC check, 𝑀𝐿 ⇒ 𝜑𝐿 , is too complex for the SAT solver to handle. However, a simplified model abstracted using shorter properties may be feasible. For example, assume property 𝜑2𝑙2 has been proven, already. If 𝐿 = 𝑙1 + 𝑙2 , i.e., 𝑀𝐿 = 𝑀𝑙1 ∘ 𝑀𝑙2 , the SAT solver may be able to prove 𝑀𝑙1 ∘ 𝜑2𝑙2 ⇒ 𝜑𝐿 , implying that 𝑀𝑙1 ∘ 𝑀𝑙2 ⇒ 𝜑𝐿 holds, also. In general, it is desirable to abstract as many time frames as possible by properties in order to reduce the proof complexity. The properties should be chosen such that they specify program execution sub-sequences of the longer property we want to prove. This is achieved by including 𝛽-mappings into the assumptions and commitments to describe the starting and ending program positions of the considered execution sub-sequences. We proceed in the following way. Step 1. If the proof problem 𝑀𝐿 ⇒ 𝜑𝐿 is feasible for the IPC checker, prove the property 𝜑𝐿 and add it to the set of proven properties. Step 2. If the proof does not succeed, simplify the computational model as follows. a. For a proven property 𝜑𝑘𝑙𝑘 , analyze whether the execution sequence 𝜋 ˆ𝑙𝑘 = (𝑠ˆ0 , 𝑠ˆ1 , . . . , 𝑠ˆ𝑙𝑘 ) described by the property is a

subsequence of the execution sequence 𝜋 ˆ𝐿 = (𝑡ˆ0 , 𝑡ˆ1 , . . . , 𝑡ˆ𝐿 ) of the long property 𝜑𝐿 , i.e., there exists a 𝑗 such that 𝑡ˆ𝑗 = 𝑠ˆ0 and 𝜋 ˆ𝐿 = (𝑡ˆ0 , 𝑡ˆ1 , . . . , 𝑡ˆ𝑗−1 , 𝑠ˆ0 , . . . , 𝑠ˆ𝑙𝑘 , 𝑡ˆ𝑗+𝑙𝑘 . . . , 𝑡ˆ𝐿 ). If so, replace the time frames of the unrolled design corresponding to the subsequence by the property. The proof problem based on this abstracted circuit model becomes 𝑀𝑗 ∘ 𝜑𝑘𝑙𝑘 ∘ 𝑀(𝐿−𝑗−𝑙𝑘 ) ⇒ 𝜑𝐿

(4)

b. Repeat this for all proven properties {𝜑𝑘𝑙𝑘 }. Step 3. If the IPC checker is able to prove Eq. 4, add the property 𝜑𝐿 to the set of proven properties. Step 4. If the IPC checker is not able to prove Eq. 4, we need to partition the execution sequence 𝜋 ˆ𝐿 = (𝑡ˆ0 , 𝑡ˆ1 , . . . , 𝑡ˆ𝐿 ) into shorter sub-sequences. For the sub-sequence starting from 𝑠ˆ0 , we verify the system behavior for this sub-sequence in a new property. Going back to step 2, this new property is then used to simplify the model. In our approach, steps 1, 2 and 3 can be done automatically. Only in step 4, the interaction of the verification engineer is needed to construct the new property. For this property, the starting and ending CFG states 𝑠ˆ0 and 𝑠ˆ𝑙 are chosen such that the length 𝑙 of the sequence 𝜋 ˆ𝑙 is as long as possible. However, the engineer needs to specify the assumption 𝑎 and the commitment 𝑐 in the property. The correctness of our abstraction method is guaranteed by the following theorem. T HEOREM 1. Given a “long” property 𝜑𝐿 and a “short” property 𝜑𝑙 . The short property is known to hold on the design, i.e., 𝑀𝑙 ⇒ 𝜑𝑙 is true. If 𝑀𝐿−𝑙 ∘ 𝜑𝑙 ⇒ 𝜑𝐿 holds then so does 𝑀𝐿 ⇒ 𝜑𝐿 , i.e., also the long property holds. P ROOF 1. Because 𝑀𝑙 ⇒ 𝜑𝑙 , also the implication shifted to the right by 𝐿 − 𝑙 clock cycles is true: next(𝑀𝑙 , 𝐿 − 𝑙) ⇒ next(𝜑𝑙 , 𝐿 − 𝑙). We conjoin the left-hand side with 𝑀𝐿−𝑙 , obtaining 𝑀𝐿−𝑙 ∧ next(𝑀𝑙 , 𝐿−𝑙) ⇒ next(𝜑𝑙 , 𝐿−𝑙) and, finally, 𝑀𝐿−𝑙 ∧next(𝑀𝑙 , 𝐿− 𝑙) ⇒ 𝑀𝐿−𝑙 ∧ next(𝜑𝑙 , 𝐿 − 𝑙). This is equivalent to 𝑀𝐿−𝑙 ∘ 𝑀𝑙 ⇒ 𝑀𝐿−𝑙 ∘ 𝜑𝑙 or 𝑀𝐿 ⇒ 𝑀𝐿−𝑙 ∘𝜑𝑙 . If, as required by the theorem, 𝑀𝐿−𝑙 ∘ 𝜑𝑙 ⇒ 𝜑𝐿 holds then, by transitivity of implication, also 𝑀𝐿 ⇒ 𝜑𝐿 holds.

second experiment considers the system with a LIN device driver developed by Infineon Technologies, Inc.. LIN (Local Interconnect Network) is a sequential network protocol commonly used in automotive systems.

4.2

Fibonacci Program

In this experiment, we compare the performance and the robustness of the proposed method against a brute-force approach without abstraction. We verified the Fibonacci program shown in Figure 2. We specified an interval property describing a piece of system behavior where 𝑖 Fibonacci numbers are calculated. We proved the property against the concrete system using the commercial IPC checker from OneSpin Solutions [15]. In Table 1, we report the CPU time and the memory consumption that the IPC checker needed to prove the properties in columns 3 and 5, respectively. Columns 1 and 2 show the number of Fibonacci numbers 𝑖 that are calculated and the length of the corresponding properties. As we can see in the table, without the proposed abstraction technique the IPC checker reports memory-out (marked “MO” in the table) when it was given the circuit unrolled over 718 clock cycles to prove the property specifying that 35 Fibonacci numbers had been calculated. Applying the proposed method, we consider the original properties as long properties and we formulate short properties specifying the behavior of the system when the loop body of the program is executed as described in Section 3.2. Then we use these properties to abstract the unrolled iterative circuit model when proving the long properties. The CPU time and memory consumption are shown in columns 4 and 6 of Table 1. Note that the proposed technique can prove even significantly longer properties depending on what aborting conditions we choose.

To the best of our knowledge, this is the first time that the abstract computational model for proving properties is constructed from a combination of both, instances of the abstract transition functions as given by the properties and instances of the concrete transition function.

4. EXPERIMENTAL CASE STUDIES

𝑖

length

5 6 7 8 9 15 20 25 30 35 40 45 50

118 138 158 178 198 318 418 518 618 718 818 918 1018

CPU time (s) Concrete Abstract 99 114 142 164 197 390 644 768 914 – – – –

Memory usage (MB) Concrete Abstract

32 36 41 49 54 89 165 186 218 279 445 517 658

6137 6502 6907 7772 8662 14038 18894 23447 26665 MO MO MO MO

1535 1705 1854 2047 2276 3808 5980 6688 7938 9170 11450 12522 13176

Table 1: Verifying the Fibonacci program

4.1 Experimental Setup

4.3

The proposed techniques were evaluated on an embedded system consisting of an open source 32-bit processor Aquarius [1] being connected with two memory modules, a RAM and a ROM, and a peripheral module, a UART. These hardware components are described in 6850 lines of Verilog code. The processor executes a program in C language which is compiled and loaded into the ROM module. As a result, the design under verification (DUV) at the hardware level consists of the processor, the peripheral and the memory component that contains the software program. These components are completely specified in a hardware-level language and can be verified against properties by the IPC checker. Although the properties are formulated in a hardware-level language it is possible to refer to program positions and variables in the software since the required information is also translated into the hardware level using a simple converter tool. In the next two sections, we describe two experiments to prove the behavior of the system where the processor executes two programs. The first experiment handles the system with the Fibonacci program and the

In this experiment, we applied the proposed method to an industrial software implementing a LIN master node. The software has

LIN driver

Property (name)

Length (cycles)

Proof size (AND gates)

CPU time (s)

Memory (MB)

first_new_frame wait_synchbreak

110 30

567,981 155,961

648 68

10,722 2,168

load_synchbreak start_bit_synchbreak bit1_synchbreak bit2_synchbreak bit3_synchbreak bit4_synchbreak bit5_synchbreak bit6_synchbreak bit7_synchbreak bit8_synchbreak stop_bit_synchbreak

920 810 810 810 810 810 810 810 810 810 810

199,697 181,604 181,604 181,604 181,603 181,604 181,605 181,605 181,604 181,602 181,597

625 474 474 517 472 473 480 476 490 475 481

15,949 13,967 13,635 13,969 14,008 14,010 13,967 14,003 13,969 13,964 14,014

Table 2: Verifying a LIN implementation

about 850 lines of C code. It was ported to the open-core-based platform described above. Our goal is to verify that the HW/SW system correctly implements all LIN transactions. As an example, we proved that the synchbreak symbol is first sent when the LIN node wants to start a LIN message transmission. Because symbols in the LIN frame are transmitted as serial bytes at a very slow rate with respect to the clock rate of the processor the length of the considered behavior in terms of the processor clock cycles is often very large. For example, at the Baud rate 38400 bps, one bit in the synchbreak symbol needs to be transmitted in 𝑇field = 1.5/38400 seconds. If the clock frequency of the processor is 20 MHz, the length of the property specifying the transmission of 1 bit is 𝑘 = 𝑇field ⋅ 20 ⋅ 106 Hz = 781 cycles. Consequently, the computational model to prove such properties becomes very complex and cannot be handled by IPC. We applied the proposed method to prove properties stating that each bit of the synchbreak symbol is transmitted correctly to the LIN bus. In the first step, we constructed two short properties specifying the behavior of the software executed in the processor. The first property, called first_new_frame, specifies that the synchbreak symbol is written to the UART correctly. The second short property, called wait_synchbreak, specifies that while the UART is sending synchbreak to the LIN bus a software loop is executed to wait for an interrupt from the UART signaling that it finishes the transmission. In the second step, we used these two properties to abstract the computational model to prove the long properties stating that individual bits are sent correctly to the LIN bus (UART output signal TxD). To do this, one instance of first_new_frame and about 20 instances of wait_synchbreak are used in the abstraction. The experimental results are shown in Table 2. In the table, columns 1 and 2 show the properties and the corresponding lengths. Column 3 shows the size of the proof problem in number of AND gates. Columns 4 and 5 show the CPU time and the memory usage that were needed to prove the properties. In the table, all properties besides the first two are long properties that were proven using the described abstraction. Note that without abstraction IPC runs out of memory in all cases when trying to prove a long property. (This is not explicitly stated in the table.) In this way, we proved that all LIN transactions work correctly in the implemented system. We are not aware of any property checking tools or techniques that could be successfully applied to this HW/SW co-verification problem. Existing model checkers would consider the software in a hardware-independent way and would possibly miss bugs that occur in the hardware or the interplay between hardware and software. The proposed approach, however, can complement HW/SW co-simulation techniques and has potential to provide complete correctness proofs for low-level drivers in embedded systems ensuring the correctness of hardware, software and their interaction.

5. CONCLUSION We propose a novel method to prove long interval properties in HW/SW systems. It is based on an operation-oriented verification paradigm that is employed successfully in industry for hardware. We propose a property-based abstraction scheme and show that this can increase the length of provable interval properties by an order of magnitude. In future work, we intend to combine this approach with path predicate abstraction as proposed in [18] to create provably correct system abstractions for large HW/SW-systems.

6. REFERENCES [1] T. Aitch. Aquarius: a pipelined RISC CPU. Technical report, 2003. [2] T. Ball and R. Majumdar. Automatic predicate abstraction of c programs. In Proc. Conference on Programming Language

Design and Implementation, 2001. [3] A. Biere, A. Cimatti, E. M. Clarke, M. Fujita, and Y. Zhu. Symbolic model checking using SAT procedures instead of BDDs. In Proc. International Design Automation Conference (DAC), pages 317–320, June 1999. [4] C. Braunstein and E. Encrenaz. Using CTL formulae as component abstraction in a design and verification flow. In International Conference on Application of Concurrency to System Design (ACSD), pages 80–89. IEEE Computer Society, 2007. [5] E. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Progress on the state explosion problem in model checking. Lecture Notes In Computer Science, pages 176 – 194, 2001. [6] E. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Counterexample-guided abstraction refinement for symbolic model checking. Journal of the ACM, 50(5):752–794, 2003. [7] L. Cordeiro, B. Fischer, H. Chen, and J. Marques-Silva. Semiformal verification of embedded software in medical devices considering stringent hardware constraints. In Proc. International Conference on Embedded Software and Systems (ICESS), 2009. [8] D. Große, U. Kühne, and R. Drechsler. HW/SW co-verification of embedded systems using bounded model checking. In GLSVLSI ’06: Proceedings of the 16th ACM Great Lakes symposium on VLSI, pages 43–48, 2006. [9] A. Gupta, M. Ganai, Z. Yang, and P. Ashar. Iterative abstraction using SAT-based BMC with proof analysis. In Proc. International Conference on Computer-Aided Design (ICCAD), page 416, Washington, DC, USA, 2003. IEEE Computer Society. [10] H. Jain, D. Kroening, N. Sharygina, and E. M. Clarke. Word-level predicate-abstraction and refinement techniques for verifying RTL Verilog. IEEE Transactions on Computer-Aided Design, 27(2):366–379, 2008. [11] D. Kaestner and S. Wilhelm. Generic control flow reconstruction from assembly code. In Proc. Joint Conference on Languages, compilers and tools for embedded systems: software and compilers for embedded systems, pages 46 – 55, 2002. [12] R. P. Kurshan. Computer-Aided Verification of Coordinating Processes – The Automata-Theoretic Approach. Princeton University Press, Princeton, New Jersey, 1994. [13] S. Loitz, M. Wedler, D. Stoffel, C. Brehm, W. Kunz, and N. Wehn. Complete verification of weakly programmable ips against their operational isa model. In Proc. Forum on Specification & Design Languages, 09 2010. [14] M. D. Nguyen, M. Thalmaier, M. Wedler, J. Bormann, D. Stoffel, and W. Kunz. Unbounded protocol compliance verification using interval property checking with invariants. IEEE Transactions on Computer-Aided Design, 27(11):2068–2082, November 2008. [15] Onespin Solutions GmbH, Germany. OneSpin 360MV. http://www.onespin-solutions.com. [16] A. Podelski and A. Rybalchenko. Transition predicate abstraction and fair termination. In Proc. of ACM Symposium on Principles of Programming Languages (POPL), pages 132–144. ACM, 2005. [17] M. Schickel, V. Nimbler, M. Braun, and H. Eveking. On consistency and completeness of property sets: Exploiting the property-based design process. In Proc. Forum on Design Languages, 2006. [18] J. Urdahl, D. Stoffel, J. Bormann, M. Wedler, and W. Kunz. Path predicate abstraction by complete interval property checking. In Formal Methods in Computer Aided Design, pages 207–215, 2010.