Design Intent Verication

Parin Chheda (07CS3023),c.parin@gmail.com March 21, 2012

Introduction

In this lecture, we show how the architectural design of an embedded system is veried against a given set of specications using the knowledge of temporal logic. Then, we would discuss about few core problems such as Satisability, Realizability, Formal Coverage and Model Checking. The design of embedded systems along with the hierarchy is shown in gure 1. The top-level design, architectural model is broken down into blocks and sub-blocks till we get sequential (series or parallel) aggregation of subblocks. All the components in the component model are further designed as nite state machines (FSMs). This is called the Macro-State model. In the leaf-level model, the states in each such FSMs are simple software modules. Hence, the design hierarchy of embedded system consists of four models.

Temporal Logic

Temporal logic is used to describe any system of rules and symbolism for representing and reasoning about, propositions qualied in terms of time. Temporal logic has found an important application in formal verication, where it is used to state requirements of hardware or software systems. There are four main teporal logic operators: Next operator (X) is shown in gure 2. X implies that has to hold in the next state. Globally operator (G) is shown in gure 3. G implies that has to hold on the entire subsequent path. 1

Figure 1: design of embedded systems

Figure 2: Next operator

Figure 3: Globally operator

Figure 4: Finally operator

Figure 5: Until operator

Finally operator (F) is shown in gure 4. F implies that eventually has to hold somewhere on the subsequent path. Until operator (U) is shown in gure 5. U implies that has to hold at least until , which holds at the current or a future position. Duality between temporal operators is shown as follows: G holds always does not hold eventually () eventually holds F () Nesting of temporal operators : F G implies that along the subsequent path, there exists a state from which will hold forever. GF implieas that along the subsequent path, for all states, there will be eventually some state where holds, i.e., along the subsequent path will hold innitely often.

Figure 6: Priority Arbiter

3
3.1

Examples
Priority Arbiter

Figure 6 shows a system which requires to arbitrate between requests r1 and r2 and provide grants g1 and g2 in such a way that r2 is default but r1 is given a higher priority over r2. Mutual exclusion must be guaranteed. We can dene the system behavior using temporal logic as follows: Either g1 or g2 is always false (mutual exclusion): G[g1 g2] Whenever r1 is asserted g1 is given in the next cycle: G[r1 Xg1] When r2 is the sole request, g2 comes in the next cycle: G[(r1bigwedger2) Xg2] When none are requesting, the arbiter parks the grant on g2: G[(r1bigwedger2) Xg2]

3.2

Automotive Properties in Temporal Logic

When brake is applied, the car immediately decelerates G[brake Xdecel] When brake is applied, the car begins to decelerate within 200ms G[brake F200 decel]

 When brake is applied, the car decelerates within 200ms by either throttle adjustment or brake adjustment G[brake Fx (throttle adj brake adj)] G[throttle adj Fy decel] G[brake adj Fz decel] (x + y 200) (x + z 200) If brake is pressed for more than 3 seconds the car stops G[brakeU3000 brake F3000 stops]

Architectural Verication of Design Intent

1. Satisability: check the consistency of the design by verifying whether the given specications are satised or not. 2. Realizability: tells whether the design can be implemented. 3. Coverage: check the completeness of the design by testing maximum test cases as possible. 4. Time budgeting: if the bigger problem has a time deadline then what will be the individual deadlines of its sub-problems?

There are mainly four properties which have to be veried:

For example, consider our example of priority arbiter which had a property stating that whenever the request r1 arrives, the grant g1 must be given exactly in the next cycle. Suppose the designer is tempted to write the property as G[r1 X(g1) XX(g1)]. The property is satisable (consider the input sequences where r1 is never asserted). But, the property is not realizable (implementable) for input sequences where r1 is asserted for two consecutive cycles (Since, next to next cycle for the rst r1 is same as the next cycle for second r1. So, g1 cannot be both true and false in the same cycle). The input and output of the system are passed through monitor which communicates with the environment. So, the monitor checks, at run time, whether the input and output lie in valid region. Appropriate action is taken by the monitor otherwise. Figure 7 shows an example of time budgeting.

Figure 7: Time Budgeting example

Model Checking

The modules in blocksub-block level are represented as nite state machines (FSMs). The functionality FSMs can be represented by temporal logic. So, in model checking the modules are veried with their correspoding temporal formula. Then, the model is checked globally with global properties of the system. Suppose there are n modules: M 1, M 2 . . . M n and they have k1, k2, . . . kn number of states respectively. Then, the global model has k1 k2 . . . kn number of states. This problem is called state explosion problem.

Modular Testing and Coverage Analysis

The leaf-level software modules are veried using software testing methods such as acceptability test. While testing, all the modules and each piece of code should be tested (covered). Also, each piece of code should be tested for various scenarios (completeness). Figure 8 shows the property renement and coverage ow.

Conclusion

The following are the emerging trends in design verication: 6

Figure 8: Coverage Flow

 Modeling open systems with environmental interactions Fault tolerant analysis of behavorial specications Specication and analysis of critical design parameters like power, reliability Design space exploration and metrics from integrated specications Fast implementation verication using results of design intent verication The problem of verication further complicates if we consider various possible combination of the following: System types: Discrete Systems Continuous Systems Hybrid Systems Formal specications can be represented in following ways: Boolean logic Temporal logic FSM Equations Hybrid Automata The following core problems have to be answered: Satisability Realizability Formal coverage Model checking