Property-based Monitoring of Analog and Mixed-signal
Download
Report
Transcript Property-based Monitoring of Analog and Mixed-signal
PROPERTY-BASED MONITORING
OF ANALOG AND MIXEDSIGNAL SYSTEMS
J. HAVLICEK1, S. LITTLE1, O. MALER2 AND D. NICKOVIC3
1FREESCALE
2VERIMAG
3IST
AUSTRIA
Introduction
Growth of consumer embedded devices
Cell
Interaction between digital and analog components
phones, DVD players, GPS systems, …
Increasing importance of analog blocks
Need to extend verification techniques to analog
and mixed-signal systems
Analog Simulation in Practice
Analog and mixed-signal simulations long
Several ns of real-time transient behavior of a complex
AMS circuit often takes hours or days of simulation time
Circuit
Driver
2.3h
802.11 #1
2.3h
S/D ADC
3.3h
DDR2
Simulation time
24.0h
I/O
176.2h
CDR
336.0h
Improved AMS verification methodology would help to
decrease simulation times by stopping the simulations
that violate the specification
Objective
Other Applications
Monitoring of the physical systems
Our
focus is on simulated models
Post-production quality tests in chips, detecting
undesirable situations in nuclear and industrial plants,
detecting violations of procedures in an organization…
Real-time embedded systems
Monitoring the medical devices
Overview
Property-based verification in digital context
Verification and validation in AMS context
Property-based monitoring of AMS systems
STL specification language
Algorithms for checking properties
Tool for monitoring properties of AMS systems
Case studies
Industrial perspective and requirements
What is missing for industrial applications of the framework?
Development of ASVA specification language
Summary
Example Property
A mixed-signal stabilization property
Absolute value of signal x is always smaller or equal to 5
Whenever the trigger rises, |x| drops below 1 within 600
time units, and stay below that threshold for at least 300
time units
Systems and Properties
System: a dynamic mathematical model that
generates behaviors
Property: a set of expected (“good”) behaviors
that the system should exhibit
A system satisfies a property, if all the behaviors
that it generates are included in the set of
behaviors defined by the property
Properties in Verification: Digital
Setting
System: a mathematical model of the digital system
Finite
state machines and automata
Property: set of expected behaviors expressed in a
rigorous specification language
Formal verification and model-checking
Exhaustive
“simulation” of the digital system model
Monitoring of simulation-traces
Incomplete
but effective verification technique
Property Specification Languages
Temporal logics and regular expressions
Linear
temporal logic (LTL), Computation-tree logic
(CTL), Regular expressions…
Concise languages with precise semantics
Specification languages in industry
SystemVerilog
Assertions (SVA), Property Specification
Language (PSL)
Combine LTL and regular expressions
Industrial standards (IEEE)
Sugar: clocks, local variables…
Linear Temporal Logic
Propositional Boolean logic extended with
additional temporal operators
and 1 U 2
holds at cycle n iff holds at cycle n+1
1 U 2 holds at cycle n iff 2 holds at some cycle n’ st n’ n,
and for all n n’’ < n, 1 holds in n’’
Derived
operators: and
Every request is eventually served with a grant
(request grant)
SystemVerilog Assertions
Why not use LTL in industry?
Need for specific constructs that facilitate
specification of designs by verification engineers
and tight integration with the simulators
SVA – IEEE standard
Integral
part of SystemVerilog
Includes the specific requirements from industrial users
SystemVerilog Assertions
SVA consists of several layers
Boolean
HDL expressions, but reals are not allowed
All booleans are clocked
Sequence
Booleans are combined with regular expression operators to
define temporal patterns
Concatenations (##0, ##n), repetitions ([*n], [*1:$]),
connectives (and, or, intersect)
Property
Sequences are combined to define temporal logic properties
Implications (|->, |=>, if-else), logical connectives (and, or,
not), linear temporal logic operators (always, eventually,
until)
SystemVerilog Assertions
Example
After
request is asserted, acknowledge must come 1 to
3 cycles later
assert property( @(posedge clk) $rose(req) |->
##[1:3] $rose(ack));
Validation in the Analog and MixedSignal Setting - Academia
Exhaustive verification of
hybrid systems
Model
checking of analog and
mixed-signal systems
Subject to academic research in
past 15 years
Considerable progress
Scalability issues
No property-based verification
Validation in the Analog and MixedSignal Setting - Industry
Traditional analysis of
simulation traces
Frequency-domain analysis,
statistical measures, parameter
extraction, eye diagrams…
Problem-specific methods and
tools
Wave calculators, MatLab, SPICE
.measure, scripts…
Considerable user effort and
expertise
Validation in the Analog and MixedSignal Setting - Industry
State-of-the-art in industry is a bit ad hoc
AMS
designers are not well versed in digital
verification methodologies
AMS tools and methodologies are not mature
Working chips are being built
Test
chips help validate circuit correctness
Incremental design changes reduce risk
Ad hoc verification methods still find bugs
Bugs
are often found in the mixed-signal interface or digital
control of analog circuits
Industrial examples
Analog designers are responsible for verifying most
of the block-level details using traditional analog
verification methodologies
AMS verification at the block level focuses on the
interfaces and digital control
AMS verification at the SoC level is becoming
increasingly important
Interaction
between analog and digital blocks is
becoming more complex
PMU: Model creation
Power management unit (PMU)
AMS block with an asynchronous digital interface controlling
several voltage/current supplies that are switched on/off in
various power modes
Create an abstract PMU model (100% manual process)
Digital components are translated to RTL
Critical behavior of analog components is extracted and
modeled using Verilog-AMS
Relate abstract model to schematic to check accuracy
State of the art method is co-simulation of critical scenarios
Assertions check that deviations between the models are
within acceptable tolerances
PMU: Block-level verification
Functional verification of abstract model
Combination of Verilog-AMS/SystemVerilog creates the
stimulus and does the checking
For example: a Verilog-AMS monitor digitizes the result of
an AMS check for use in an assertion
Spot check schematic behaviors for sanity
A subset of critical scenarios are checked
Swapping models isn’t always trivial
Checkers will likely have to be updated (schematic outputs
are not as “clean” as model outputs, checkers may reference
internal model variables, etc.)
PMU: SoC-level verification
PMU is critical for SoC-level verification
Verifying
start-up and power mode transitions is a
critical SoC verification task
Abstract model used to meet performance requirements
Schematic may be used for a small number of high
priority scenarios
PLL
Most PLLs are largely digital logic
Use same verification methodology as the PMU
AMS verification focuses on digital interface and
system integration issues
AMS verification is not well equipped to verify
frequency domain properties (e.g., phase noise)
These
are still done by the analog designer
Bridging the gap between digital and
analog validation
Specification component of digital verification can
be successfully exported to analog and mixedsignal systems
Specification language adapted to continuous and
mixed-signal behaviors
Automatic monitoring of analog and mixed-signal
simulation traces wrt the specifications
PROPERTY-BASED
MONITORING OF AMSSYSTEMS: AN ACADEMIC
FRAMEWORK
Overview
Monitoring of timed and continuous signals
Signal
temporal logic STL for expressing properties of
continuous and hybrid behaviors
Dense-time
temporal logic MITL + numeric predicates
Two
procedures for monitoring simulation traces against
STL properties
Offline
+ Incremental
AMT
tool
Case studies
FLASH
memory and DDR2 memory interface
Signals
Multi-dimensional Boolean signal w
w
: R0 Bn
Alternating concatenation of points and open
segments
= w0 (w0)r0 w1 (w1)r1
wi and (wi)ri defined over [ti,ti] and (ti,ti+1), respectively
w
w0
w
(w0)r0
w1 (w1)r1 w2 (w2)r2 w3
Metric Interval Temporal Logic - MITL
Real-time extension of LTL
:== p | 1 2 | | 1 UI 2 | 1 SI 2
I non-punctual interval
Past and future operators
Derived operators obtained from the basic ones
I,
I and their past counterparts
p U[a,b] q
Satisfaction Signal
Each MITL sub-formula has an associated
satisfaction signal that corresponds to the truth
values of the sub-formula
Satisfaction signal u = Ip
p
u
Expressing Events in MITL
Two unary operators: rise and fall
Hold
at a rising and falling edge of a Boolean signal
Needs both past and future operators to be expressed
in MITL
= ( ( S true)) ( ( U true))
p1
p2
p1
p2
MITL Simplification Rules
Objective: Show that any MITL formula can be
written in terms of p U q and I p
Example
1
U(a,b) 2 = (0,a]1 (0,a](1 U 2) (a,b) 2
Example Property
A mixed-signal stabilization property
Absolute value of signal x is always smaller or equal to 5
Whenever the trigger rises, |x| drops below 1 within 600
time units, and stay below that threshold for at least 300
time units
Example Property
((|x| 5) (trigger [0,600][0,300](|x| 1))
Signal Temporal Logic - STL
Temporal logic that targets analog and mixedsignal systems
MITL extended with numerical predicates
Example:
x < 2 or |x2 – y2| < 3z
Booleanization of the original signal
Monitoring STL Properties
Marking: a procedure that computes the satisfaction
signal of each sub-formula of an STL specification
Doubly-recursive procedure, on time and the structure of the
formula
Procedure directly applied on signals, no automata
Two algorithms for checking STL properties
Offline marking: input is fully available
Incremental marking: input is dynamically observed
Offline Marking: Overview
5
x
x5
[1,3](x5)
[1,3](x5)
0
2
4
6
8
Offline Marking: pUq
wi
Until
• for all i 1, ui = ui
• for all i 1:
Case
1
2
3a
3b
3c
wi
!p
pq
p!q
p!q
p!q
wi+1
*
*
!p!q
p!q
q
p!q
pq
u
ui
0
1
0
1
ui+1
wi
Wi+1
Offline Marking: I p
u = I p
For every positive interval I in p
Compute its back-shifting by I
Merge the overlapping intervals to obtain u
Incremental Marking: Overview
5
x
x5
[1,3](x5)
[1,3](x5)
0
2
4
6
8
Analog Monitoring Tool: Architecture
FLASH Memory Case Study
Provided by STM Italy
Low-level behavior of a digital circuit
FLASH Memory Case Study - Setting
FLASH memory can be in different modes
FLASH memory contains a number of observable
characteristic signals
Programming, erasing, etc…
bl: bit line terminal
pw: p-well terminal
wl: word line
s: source terminal
vt: threshold voltage of cell
id: drain current of cell
Correct functioning in a given mode determined by the
behavior of the characteristic signals
FLASH Memory Case Study Properties
STM engineers provided 4 properties that specify
the expected behavior of characteristic signals of
the FLASH memory
3
properties about the FLASH memory in the
programming and 1 in the erasing mode
Several iterations needed to translate the intended
meaning of the English specifications into STL
properties
Programming Property
Whenever vt goes above 5V
vt and id have to remain
continuously above 4.5V and 5
μV
until id falls below 5 μV
vprop programming1 {
pgm1 assert:
always (rise(a:vt>5) ->
((abs(a:id)>5e-6) and
(a:vt>4.5))
until (fall(a:id>5e-6)));
}
Evaluation Results – Offline Mode
Input size
Name
wl
pw
s
bl
id
Offline evaluation time
pgm sim
input size
34829
25478
33433
32471
375
erase sim
input size
283624
283037
282507
139511
n/a
Property time(s) size
prog1
0.14
99715
prog2
0.42 405907
p-well
0.12
89071
erasing
2.35 2968578
Evaluation Results – Incremental vs.
Offline Mode
Offline vs. Incremental
Space Requirement
Input size
Name
wl
pw
s
bl
id
pgm sim
input size
34829
25478
33433
32471
375
erase sim
input size
283624
283037
282507
139511
n/a
Offline t =
Inc m = max
Property total size
m/t*100
act size
prog1
99715
65700
65.9
prog2
594709
242528
40.8
p-well
89071
8
0.01
DDR2 Case Study
DDR2-1066 memory interface, Rambus
Timing relations between events in analog signals defined in
the spec
Goal: to experiment whether some non-trivial properties from
the DDR2 specification can be effectively expressed in the
language
Alignment of Data and Data Strobe
Signals
Check if DQ and DQS respect the setup and hold times
Setup Property at the Falling Edge
Whenever DQS crosses VIH(DC)min from above, the previous
crossing from above of VIL(AC)max by DQ should precede it by at
least tDS (setup time)
define dqs_above_vihdcmin :=
DQS >= 1.025;
define dq_above_vilacmax :=
DQ >= 0.65;
always (fall(dqs_above_vihdcmin)
-> historically[0:tDS] not
fall(dq_above_vilacmax));
Variable Setup Time
Issue:
always (fall(dqs_above_vihdcmin)
-> historically[0:tDS] not
fall(dq_above_vilacmax));
tDS changes dynamically with different slew rates of DQ
and DQS
We can use only constant time bounds
Solution:
Divide slew rate correction values into ranges
Use conservative approximation (worst case tDS for a given
range)
Separate property for each range
Variable Setup Time
Jitter Cumulative Error
Property: check that the cumulative error of the
clock is correct wrt the specification
Clock period: tCK
Average Clock PeriodL tCK(avg)
Calculated
across any consecutive 200 cycle windows
Cumulative error across n cycles: tERR(nper)
Sum
of n actual periods – n*tCK(avg)
DDR2 Case Study – Jitter Spec
Parameters
Tolerated error
STL Extension
nth rise cannot be expressed in STL
Limitation
of temporal logic wrt “counting”
Auxiliary operator next_rise[n][a:b] p
Holds at time t iff the nth rise of p happens within
[t+a,t+b]
STL Limitation
Issue:
tCK(avg)
varies in time, hence time bounds are not
fixed
Solution:
Manual
extraction of the min/max tCK(avg) from the
simulation
Properties expressed wrt the values (conservative)
tCK(avg)min
= 1876ps
tCK(avg)max = 1877ps
Cumulative Error over 3 Clock Periods
Example: tERR(3per)
-175ps
<= tERR(3per) <= 175ps
For any given clock rise, the 3rd consecutive clock rise
has to happen within [tCK(avg)-175, tCK(avg)+175]
[tCK(avg)max-175:tCK(avg)min+175]
[5456:5803]
Use next_rise[n][a:b]
to express this property
Detection of Rising Edges of Clock
Periods
Clock period: detect differential crossings of
CK/CKB
define clk_period_start :=
rise (CK – CKB >= 0);
Cumulative Error Property
Example: tERR(3per) property
always (clk_period_start ->
next_rise[3][5456:5803] clk_period_start);
Similar tERR(nper) properties written and checked
for different n
Summary
The framework centered around STL presents a
good basis for property-based analog and mixedsignal monitoring
But…
There are limitations that need to be taken into
account!!!
Limitations: Linear Interpolation
Analog simulator provides a collection of
time/value samples
What
is the value of the signal in between the samples?
Linear interpolation
STL
property evaluated wrt the interpolated, not the
real signal
Limitations: Mixed-time Properties
STL is based entirely on continuous time
Mixed-signal systems combine analog (continuous
time) and digital (discrete time) components
Difficult to express purely discrete-time properties
for the digital part of the specification
Example:
((p
q) [0:200ns] (x 5))
Limitations: Regular Expressions
SVA and PSL heavily rely on regular expressions
(sequence operators)
DDR2 jitter property exposed further the need for
regular expression operators
Limitations: Future, Past and Events
STL combines future and past operators
Expressing events in real-time requires both future
and past operators
Past operators are difficult to use for online
monitoring
This
is especially true in the analog setting
The simulator cannot backtrack once it has computed a
new sample
Limitations: Expressiveness
DDR2 case study exposed limited expressiveness of
STL
Slew
rates, averages, variable times…
SVA-like local variables?
How to Overcome the Limitations?
Accellera ASVA committee
Analog
and mixed-signal extension of SVA that
addresses most of the above limitations
Provide an industrial-strength framework for property
based AMS monitoring
PROPERTY-BASED
MONITORING OF AMS
SYSTEMS: INDUSTRIAL
PERSPECTIVE
Expectations
Standardized AMS assertion language
Must be consistently supported across vendors
Must be well integrated with existing languages (VerilogAMS and SystemVerilog)
Build on idioms and styles of existing digital assertions
Efficient, accurate online and offline monitoring
SoC-level simulation performance is still important
Poorly performing assertions won’t get used
Offline mode is important for assertion development
Assertions can be edited and rechecked without waiting for long
AMS simulations to finish
Expected Use Models
System-level functional verification
User:
Verification engineer
Circuit type: SystemVerilog/Verilog AMS/SPICE
Level: System/Chip
Model functional verification
User:
AMS Verification engineer
Circuit type: Verilog AMS
Level: Block
Expected Use Models
Model vs. implementation checking
User:
Analog designer or AMS verification engineer
Circuit type: Verilog AMS/SPICE
Level: Block
AMS Assertions Today
AMS assertions are approximated using VerilogAMS monitors and digital SVAs:
Digital
signals created by Verilog-AMS monitors are
bound into SVA modules
SVAs are clocked by carefully timed signals
AMS Assertions Today (Example)
If ‘a’ < 10 mV has been true for at least 10 ns and
‘b’ is false, then the system should signal failure by
making ‘c’ false.
SVA
@(posedge clk_1n)
first_match(va_lt_10m[*10:$] ##0 !b)
|-> !c
Verilog-AMS monitors
@cross(V(a) - 10.0m, +1)
va_lt_10m <= 1’b0;
@cross(V(a) – 10.0m, -1)
va_lt_10m <= 1’b1;
Analog SVA (ASVA) Landscape
Extends SVA
Real
values in Boolean expressions
Realtime (i.e., continuous time) semantics
New realtime operators in sequences and properties
Draws on Verilog-AMS
Eventually,
ASVA will be part of a unified
SystemVerilog-AMS language
Standardization efforts underway within Accellera
and IEEE for ASVA and SystemVerilog-AMS
ASVA Extension Requirements
ASVA committee voted on extension requirements
ASVA
should include all existing SVA
The meaning of existing constructs should not change
New constructs should provide realtime capabilities
useful for AMS verification
Existing SVA has a discrete semantic framework
Problem: Extend SVA to realtime in a “good” way
Based
on linear temporal logic and regular expressions
Allow free intermingling of old and new operators, not
just a union of old and new forms
Non-trivial
ASVA Example
If ‘a’ < 10 mV has been true for at least 10 ns and
‘b’ is false, then the system should signal failure by
making ‘c’ false.
first_match((V(a) < 10.0m)[*10.0n:$] #0 !b)
|-> !c
Legend:
SVA
V-AMS
Extensions
Existing SVA Landscape
SVA consists of several layers
Boolean
HDL expressions, but reals are not allowed
All booleans are clocked
Sequence
Booleans are combined with regular expression operators to
define temporal patterns
Concatenations (##0, ##n), repetitions ([*n], [*1:$]),
connectives (and, or, intersect)
Property
Sequences are combined to define temporal logic properties
Implications (|->, |=>, if-else), logical connectives (and, or,
not), linear temporal logic operators (always, eventually,
until)
Extending SVA to Realtime
Some extensions are straightforward
Logical connectives (and, or, not) have the same meaning
Non-temporal implications (|->, if-else) have the same
meaning
Clocked Booleans (ignoring sampling questions)
Some extensions have been studied already
Realtime linear temporal logic operators
p until[0:1.5m] q requires q to occur within 1.5m of the
start of the property
Question: How to extend SVA sequences to realtime?
Realtime Sequences
Invented realtime semantic framework for sequences
based on continuous intervals
Covers all SVA sequence forms (local variables in progress)
Proved equivalence between the new realtime semantics
and the existing SVA semantics for these SVA sequence
forms
Introduced three new primitive realtime sequence forms:
b: realtime (i.e., unclocked) boolean
r without @(c): sequence without an event
b[*a1:a2]: boolean "smear", i.e., boolean holds
continuously for a specified time range
Realtime Sequences (2)
Introduced several new derived realtime sequence forms:
r #0 s: realtime fusion
r #[a:b] s: realtime concatenation
b[->1]: realtime goto
non-ranged forms of Boolean smear and realtime concatenation
Proof carried out for singly-clocked SVA sequences
Evidences coherency of our new realtime semantic framework and
operators
Good integration with the existing SVA semantics and operators
Associativity of realtime fusion and concatenation
Direct semantics of realtime concatenation and goto
Other ad hoc semantic checks
Proved that ##0 and ##1 can also be derived from
realtime operators
Performed semantic sanity checks:
Realtime Sequence Examples
a is true and b is false continuously for 10.5 s
(a
a is true and 9.7 s later b is true
&& !b)[*10.5]
a #9.7 b
From the beginning of the interval, advance to the
first time where a is high, then find b and c high
1.6 s later, and also ensure that b subsequently
stays high continuously for 5.1 s
a[->1] #1.6 (b && c) #0 b[*5.1]
Local Variables
We studied where to allow local variable assignments in
realtime sequences
Three policies were proposed (others are possible):
1.
2.
3.
Allow local variable assignments wherever they can be written
in digital SVA subsequences
Additionally, allow local variable assignments to be attached to
realtime (i.e., unclocked) Booleans
Additionally, allow local variable assignments to be attached to
realtime sequences all of whose matches are non-empty, right
closed intervals
The first policy will meet committee requirements
The third policy is essentially syntactic sugar over the
second
Fear of complexity issues for the second and third policies
led to the selection of the first policy
Future needs could dictate the adoption of the second or
third policy after a proper study of complexity issues
Local Variables (Example)
The falling crossing of V(b) < 2.5V must be (250.0
+ f(s)) ns after the most recent falling crossing of
V(a) < 2.5V, where s is the slew rate of V(a) from
5.0V to 2.5V
real s, t;
@(negedge V(a) < 5.0)
(1’b1, s = $abstime) |->
@(negedge V(a) < 2.5)
(1’b1, s = $abstime – s, t = $abstime) |->
@(negedge V(b) < 2.5) |->
$time – t > (250.0 + f(s))
Realtime Properties
Many property operators easily translate to
realtime (not, or, and, clocked nexttime,
clocked until)
|-> and |=> have been more challenging
Candidate
definitions for these property operators are
currently under development
Issues with the definitions of these operators in the
digital SVA have complicated the realtime definitions
Mixed-time Specification Language
Many truly mixed-signal properties are more easily
specified with a mixed-time language
Clocked
trigger implies start realtime measurement
(e.g., settling time, slew rate)
A free intermingling of clocked and realtime
sequences and properties is a key feature of ASVA
Accurate Simulations for Assertions
Accuracy of analog events is critical for correct
assertions.
Assertion writers require the ability to influence the
analog simulator time steps according to the needs
of the property
Implicit inference of critical solve points based on
assertion structure is preferred
Further
study is needed to understand the feasibility of
critical solve point inference and performance impact
Embedding ASVA within SV and VAMS
ASVA is ideally suited to a merged
SystemVerilog/Verilog-AMS language
Without a merged language it is difficult for:
ASVA
within SV to access continuous quantities & events
(e.g., V(a), @(cross()))
ASVA with VAMS to access complex testbench data
types (e.g. struct)
Compromises will be made
CONCLUSIONS AND
FURTHER PERSPECTIVES
Other Extensions
Robust satisfaction of STL
Today
17h presentation [DonzeMaler10]
Parametric MITL
Extract
timing bounds from a set of simulations
always
(p -> eventually[?] q)
[DiGiampaoloLaTorreNapoli10]
Conclusion
Exporting property-based monitoring to the AMS
context
Comprehensive
prototype tool applied to real
industrial case studies
Industrial interest in the methodology
Freescale,
Mentor Graphics, Rambus, STM…
Accellera ASVA committee
Towards a standard property specification language
for AMS applications
Work in progress