slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 87

Introduction - PowerPoint PPT Presentation

  • Uploaded on

Property-based Monitoring of Analog and Mixed-signal Systems J. Havlicek 1 , S. Little 1 , O. Maler 2 and D. Nickovic 3 1 Freescale 2 VERIMAG 3 IST AUSTRIA. Introduction. Growth of consumer embedded devices Cell phones, DVD players, GPS systems, …

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Introduction' - xiu

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Property-based Monitoring of Analog and Mixed-signal SystemsJ. Havlicek1, S. Little1, O. Maler2 and D. Nickovic31Freescale2VERIMAG3IST AUSTRIA

  • Growth of consumer embedded devices
    • Cell phones, DVD players, GPS systems, …
  • Interaction between digital and analog components
    • Increasing importance of analog blocks
  • Need to extend verification techniques to analog and mixed-signal systems
analog simulation in practice
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
  • Improved AMS verification methodology would help to decrease simulation times by stopping the simulations that violate the specification
other applications
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
  • 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
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
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
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
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
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
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 assertions1
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 assertions2
SystemVerilog Assertions
  • Example
    • After request is asserted, acknowledge must come 1 to 3 cycles later
    • assert property( @(posedgeclk) $rose(req) |-> ##[1:3] $rose(ack));
validation in the analog and mixed signal setting academia
Validation in the Analog and Mixed-Signal 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 mixed signal setting industry
Validation in the Analog and Mixed-Signal 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 mixed signal setting industry1
Validation in the Analog and Mixed-Signal 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
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
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
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: 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
  • 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
Bridging the gap between digital and analog validation
  • Specification component of digital verification can be successfully exported to analog and mixed-signal systems
  • Specification language adapted to continuous and mixed-signal behaviors
  • Automatic monitoring of analog and mixed-signal simulation traces wrt the specifications
  • 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
  • Multi-dimensional Boolean signal w
    • w : R0  Bn
  • Alternating concatenation of points and open segments
    • w = w0  (w0)r0  w1  (w1)r1   
    • wiand (wi)ri defined over [ti,ti] and (ti,ti+1), respectively









metric interval temporal logic mitl
Metric Interval Temporal Logic - MITL
  • Real-time extension of LTL

f :== p | f1 f2 |  f | f1UI f2 | f1SI f2

  • I non-punctual interval
  • Past and future operators
  • Derived operators obtained from the basic ones
    • I, I and their past counterparts


satisfaction signal
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



expressing events in mitl
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
      • f = (f  (f S true))  (f  (f U true))





mitl simplification rules
MITL Simplification Rules
  • Objective: Show that any MITL formula can be written in terms of p U q and I p
  • Example
    • f1 U(a,b) f2 = (0,a]f1 (0,a](f1 U f2) (a,b) f2
example property1
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 property2
Example Property

((|x|  5)  (trigger  [0,600][0,300](|x|  1))

signal temporal logic stl
Signal Temporal Logic - STL
  • Temporal logic that targets analog and mixed-signal systems
  • MITL extended with numerical predicates
    • Example: x < 2 or |x2 – y2| < 3z
  • Booleanization of the original signal
monitoring stl properties
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
Offline Marking: Overview











offline marking puq
Offline Marking: pUq




  • Until
  • for all i1, ui = ui
  • for all i1:



offline marking i p
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
Incremental Marking: Overview











flash memory case study
FLASH Memory Case Study
  • Provided by STM Italy
  • Low-level behavior of a digital circuit
flash memory case study setting
FLASH Memory Case Study - Setting
  • FLASH memory can be in different modes
    • Programming, erasing, etc…
  • FLASH memory contains a number of observable characteristic signals
    • 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
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
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


until (fall(a:id>5e-6)));


evaluation results offline mode
Evaluation Results – Offline Mode

Input size

Offline evaluation time

evaluation results incremental vs offline mode
Evaluation Results – Incremental vs. Offline Mode

Offline vs. Incremental

Space Requirement

Input size

ddr2 case study
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
Alignment of Data and Data Strobe Signals
  • Check if DQ and DQS respect the setup and hold times
setup property at the falling edge
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)
  • definedqs_above_vihdcmin :=
  • DQS >= 1.025;
  • definedq_above_vilacmax :=
  • DQ >= 0.65;
  • always (fall(dqs_above_vihdcmin)
  • -> historically[0:tDS] not
  • fall(dq_above_vilacmax));
variable setup time
Variable Setup Time
  • Issue:

always (fall(dqs_above_vihdcmin)

-> historically[0:tDS] not


    • 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
jitter cumulative error
Jitter Cumulative Error
  • Property: check that the cumulative error of the clock is correct wrt the specification
  • Clock period: tCK
  • Average Clock PeriodLtCK(avg)
    • Calculated across any consecutive 200 cycle windows
  • Cumulative error across n cycles: tERR(nper)
    • Sum of n actual periods – n*tCK(avg)
stl extension
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
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
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
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
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
  • The framework centered around STL presents a good basis for property-based analog and mixed-signal monitoring
  • But…
  • There are limitations that need to be taken into account!!!
limitations linear interpolation
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
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
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
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
Limitations: Expressiveness
  • DDR2 case study exposed limited expressiveness of STL
    • Slew rates, averages, variable times…
  • SVA-like local variables?
how to overcome the limitations
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
  • Standardized AMS assertion language
    • Must be consistently supported across vendors
    • Must be well integrated with existing languages (Verilog-AMS 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
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 models1
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 Today
  • AMS assertions are approximated using Verilog-AMS 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
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.


@(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
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 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





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

existing sva landscape
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
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
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
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
  • Proved that ##0 and ##1 can also be derived from realtime operators
    • 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
  • Performed semantic sanity checks:
    • Associativity of realtime fusion and concatenation
    • Direct semantics of realtime concatenation and goto
    • Other ad hoc semantic checks
realtime sequence examples
Realtime Sequence Examples
  • a is true and b is false continuously for 10.5 s
    • (a && !b)[*10.5]
  • a is true and 9.7 s later b is true
    • 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) #0b[*5.1]
local variables
Local Variables
  • We studied where to allow local variable assignments in realtime sequences
  • Three policies were proposed (others are possible):
    • 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
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
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
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
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
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
other extensions
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]
  • 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