Automatic Trace Analysis for Logic of Constraints

1
Automatic Trace Analysisfor Logic of Constraints

• Xi Chen, Harry HsiehUniversity of California,
  Riverside
• Felice Balarin, Yosinori WatanabeCadence
  Berkeley Laboratories

2
Outline

• Introduction
• System-level design
• Logic of Constraints
• Trace analysis methodology
• Methodology and algorithms
• Case studies
• Proving LOC formulas
• Summary

3
System-Level Design Methodology

• RTL level design is no longer efficient for
  systems containing millions of gates.
• System-level design becomes necessary
• Reuse of design components
• Reduce overall complexity
• Ease debugging
• Verification methods must accompany every
  step in the design flow
• Constraints need to be specified at the
  highest level and verified ASAP

(Keutzer, TCAD00)
4
Logic of Constraints (LOC)

• A transaction-level quantitative constraint
  language
• Works on a sequence of events from a particular
  execution trace
• The basic components of an LOC formula
• Boolean operators (not), (or), (and) and
  (imply)
• Event names, e.g. in, out, Stimuli or
  Display
• Instances of events, e.g. Stimuli0,
  Display10
• Annotations, e.g. t(Display5)
• Index variable i, the only variable in a formula,
  e.g. Displayi-5 and Stimulii

5
LOC Constraints
Throughput at least 3 Display events will be
produced in any period of 30 time units. t
(Displayi3) t (Displayi) lt 30 Other LOC
constraints Performance rate, latency, jitter,
burstiness Functional data consistency
6
Assertion Languages(Related Work)

• IBMs Sugar and Synopsis' OpenVera
• Good for both formal verification and simulation
  verification
• Implemented as libraries to supportdifferent
  HDLs
• Assertions are expressed with
• Boolean expressions, e.g. a03 b03
  0000
• Temporal logics, e.g. always !(a b)
• HDL code blocks, e.g. handshake protocol
• Mainly based on Linear Temporal Logic

7
Characteristics of LOC Formulism

• Constraints can be automatically synthesized into
  static checkers, runtime monitors and formal
  verification models.
• Performance constraints in addition to functional
  constraints
• A different domain of expressiveness than LTL.

8
Outline

• Introduction
• Trace analysis methodology
• Methodology and algorithms
• Case studies
• Proving LOC formulas
• Summary

9
Trace Analysis Methodology

• An efficient checking algorithm
• An automatic LOC checker generator

• Extended to runtime constraint monitoring

10
Algorithm of theLOC Checker
11
Algorithm of theLOC Checker
12
Input and Output
Input of the checker generator formula and
trace format
Output of the trace checking error report
13
Dealing with Memory Limitation

• scan trace and store the annotations only once.
• If the memory limit has been reached,
• stop storing more annotations
• search the rest of trace for current i
• resume storing annotations after freeing memory

memory
trace
14
Static Trace Checking v.s. Runtime Monitoring

• Runtime constraint monitoring
• Integrate the trace checker into a compiled-code
  simulator, e.g. SystemC modules
• At runtime, the events and annotations are passed
  to the monitor module directly
• Static trace checking v.s. runtime monitoring

15
Case Study FIR Filter
Rate t(Displayi1)-t(Displayi)
10 Latency t(Displayi) - t(Stimulii) lt
25 Jitter t(Displayi) - (i1) 10 lt
4 Throughput t (Displayi100)-t(Displayi)
lt 1001 Burstiness t (Displayi1000)-t(Disp
layi) gt 9999
16
Trace Checking Results (FIR)
Resource Usage for Checking Constraints (1) (5)
17
Runtime Monitoring (FIR)

• The checker implemented as a SystemC module and
  applied on the latency constraint, i.e.
• t(Displayi) - t(Stimulii) lt 25 (C2)
• Simulation trace is no longer written to a file
  but passed to the monitoring module directly.

Results of Runtime Monitoring on FIR for the
Latency Constraint (2)
18
Case Study Picture In Picture

• Picture-In-Picture (PIP)
• a system level design for set-top video
  processing
• 19, 000 lines of source code
• 120, 000 lines of simulation output (control
  trace)

PIP trace
19
Performance and Functional Constraints for
PIP(contd)

• 1. Data consistency The numbers of the fields
  read in and produced should be equal.
• field_count(ini) field_count(outi)
• field_count is an annotation number of fields
  processed
• in, out are events reading a field and
  producing a field

20
Performance and Functional Constraints for
PIP(contd)
2. The field sizes of paired even and odd fields
should be the same. size(field_start2i2)-size(
field_start2i1) size(field_start2i1)-size(
field_start2i) 3. Latency between user control
and actual size change lt 5. field_count(change_
sizei) - field_count(read_sizei) lt 5
Trace Checking Results With the trace of about
120,000 lines, all these three constraints are
checked within 1 minute.
21
Outline

• Introduction
• Trace analysis methodology
• Proving LOC formulas
• Summary

22
Formal Verification Tools and Methods

• Model checkers, e.g. SPIN, SMV
• Check if a finite state system(model) satisfy
  some property
• Properties are expressed with temporal logics,
  e.g. LTL
• Limitation
• state explosion
• finite state

23
Formal Verification for LOC

• We define a subset of LOC that has finite-state
  equivalents
• represent the LOC formula with LTL
• use LTL model checking directly
• Example

t(Displayi1) t(Displayi) 10
Display_occur ? Display_t Display_t_last 10
24
Formal Verification for LOC(contd)

• Other LOC formulas are beyond the finite-state
  domain, e.g. the latency constraint
• make assumption to limit the system to
  finite-state domain
• verify assumption and assumption ? constraint
  separately

25
Case Study A FIFO Channel
FIFO Buffer
DataGen
Sum
Control Unit

• Data consistency constraint on the channel
• Assumption Sum_read always follows
  DataGen_write, between a write and its
  corresponding read, only 30 more writes can be
  produced

data(DataGen_writei) data(Sum_readi)
26
Case Study A FIFO Channel (contd)
FIFO Buffer
DataGen
Sum
Control Unit

• Using the model checker SPIN, the assumption is
  verified in 1.5 hours and assumption ? constraint
  is verified in 3 hours
• The FIFO channel is a library module
• Repeated use
• Small 600 lines of source code v.s. PIP (19,000
  lines)

27
Summary

• LOC is useful and is different from LTL
• Automatic trace analysis
• Case studies with large designs and traces
• Formal verification approach

28
Thank You!
29
Design Complexity Increases Dramatically

• RTL is no longer efficient for systems
  containing millions of gates.
• - long design period- huge man-power-
  difficult to optimize- long simulation runs

30
Other Real Time LOC Constraints

• Rate Displays are produced every 10 time
  units,
• t(Displayi1) - t(Displayi) 10
• Latency Display is generated no more than 25
  time units after Stimuli ,
• t(Displayi) - t(Stimulii) lt 25
• Jitter every Display is no more than 4 time
  units way from the corresponding tick of the
  real- time clock with period 10,
• t(Displayi) - (i1) 10 lt 4
• Burstiness no more than 1000 Display events
  will arrive in any period of 9999 time units,
• t(Displayi1000) - t(Displayi) gt 9999

31
Partial Evaluation

• Combination of multiple LOC formulas with logical
  operationse.g. t(Displayi10) gt 100
  t(Stimulii-5) lt 300
• Partial evaluation based on 3-value logic
  true,false and unknowni.e.
• An formula instance is evaluated to unknown if
• an annotation with a index value is not yet
  available in trace
• when the index has an invalid value (e.g.
  Stimuli-2)

or
32
Case Study FIR Filter(contd)

• An alternative latency constraint
• t(Displayi)-t(Stimulicause(Displayi)) lt 25
  (C6)
• Use the annotation cause as indexes.
• Memory for annotation t of Stimuli can never be
  recycled.
• When memory limit is reached, much more time is
  needed.

Verification Resource Usage for Constraint C6
33
Case Study TTL Channel(contd)

• Using LTL model checker
• Assumption Sum always follows DataGen, and the
  distance between them is less than 31
• Constraint Data consistency in LTL
• (Sum_occur -gt DataGen_dataSum_i
  Sum_dataSum_i)
• Verify Assumption and Assumption ? Constraint
  separately

34
Algorithm of theLOC Checker
Throughput at least 3 Display events will be
produced in any period of 30 time units t
(Displayi3) t (Displayi) lt 30
FIR Trace
Queue data structure
35
Algorithm of theLOC Checker