Intent Verification

7/31/2019 Intent Verification

1/8


2/8

Figure 1: design of embedded systems

Figure 2: Next operator

Figure 3: Globally operator

2


3/8

Figure 4: Finally operator

Figure 5: Until operator

Finally operator (F) is shown in figure 4.F

implies that

eventuallyhas to hold somewhere on the subsequent path.

Until operator (U) is shown in figure 5. U implies that has to holdat 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 subsequentpath, there exists a state from which will hold forever. GF implieas thatalong the subsequent path, for all states, there will be eventually some state

where holds, i.e., along the subsequent path will hold infinitely often.

3


4/8


5/8

When brake is applied, the car decelerates within 200ms by either throt-

tle adjustment or brake adjustmentG[brake Fx(throttle adj

brake adj)]

G[throttle adj Fydecel]

G[brake adj Fzdecel]

(x + y 200)

(x + z 200)

If brake is pressed for more than 3 seconds the car stopsG[brakeU3000brake F3000stops]

4 Architectural Verification of Design Intent

There are mainly four properties which have to be verified:

1. Satisfiability: check the consistency of the design by verifying whetherthe given specifications are satisfied or not.

2. Realizability: tells whether the design can be implemented.

3. Coverage: check the completeness of the design by testing maximumtest cases as possible.

4. Time budgeting: if the bigger problem has a time deadline then whatwill be the individual deadlines of its sub-problems?

For example, consider our example of priority arbiter which had a prop-

erty stating that whenever the request r1 arrives, the grant g1 must be givenexactly in the next cycle. Suppose the designer is tempted to write the prop-erty as G[r1 X(g1) XX(g1)]. The property is satisfiable (considerthe input sequences where r1 is never asserted). But, the property is notrealizable (implementable) for input sequences where r1 is asserted for twoconsecutive cycles (Since, next to next cycle for the first r1 is same as thenext cycle for second r1. So, g1 cannot be both true and false in the samecycle).

The input and output of the system are passed through monitor whichcommunicates with the environment. So, the monitor checks, at run time,

whether the input and output lie in valid region. Appropriate action istaken by the monitor otherwise.Figure 7 shows an example of time budgeting.

5


6/8

Figure 7: Time Budgeting example

5 Model Checking

The modules in blocksub-block level are represented as finite state ma-chines (FSMs). The functionality FSMs can be represented by temporallogic. So, in model checking the modules are verified with their correspodingtemporal formula. Then, the model is checked globally with global proper-ties of the system. Suppose there are n modules: M1, M2 . . . M n and theyhave k1, k2, . . . k n number of states respectively. Then, the global model has

k1k2 . . .kn number of states. This problem is called state explosionproblem.

6 Modular Testing and Coverage Analysis

The leaf-level software modules are verified using software testing methodssuch as acceptability test. While testing, all the modules and each piece ofcode should be tested (covered). Also, each piece of code should be testedfor various scenarios (completeness). Figure 8 shows the property refinementand coverage flow.

7 Conclusion

The following are the emerging trends in design verification:

6


7/8

Figure 8: Coverage Flow

7


8/8

Modeling open systems with environmental interactions

Fault tolerant analysis of behavorial specifications

Specification and analysis of critical design parameters like power, re-liability

Design space exploration and metrics from integrated specifications

Fast implementation verification using results of design intent verifica-tion

The problem of verification further complicates if we consider various

possible combination of the following: System types: Discrete Systems

Continuous Systems

Hybrid Systems

Formal specifications can be represented in following ways:

Boolean logic

Temporal logic

FSM

Equations

Hybrid Automata

The following core problems have to be answered:

Satisfiability

Realizability

Formal coverage

Model checking

8

Intent Verification

Documents

Transcript of Intent Verification