Introduction

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

2. Introduction • 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

3. 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

4. Objective

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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…

11. 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)

12. 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

13. 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)

14. SystemVerilog Assertions • Example • After request is asserted, acknowledge must come 1 to 3 cycles later • assert property( @(posedgeclk) $rose(req) |-> ##[1:3] $rose(ack));

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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.)

21. 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

22. 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

23. 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

24. Property-based monitoring of ams-systems: an academic framework

25. 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

26. Signals • 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 w2 w3 w0 (w0)r0 w1 (w1)r1 (w2)r2 w

27. 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 pU[a,b]q

28. 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

29. 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)) p1 p2 p1 p2

30. 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

31. 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

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

33. 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

34. 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

35. Offline Marking: Overview 5 x x5 [1,3](x5) [1,3](x5) 0 2 4 8 6

36. Offline Marking: pUq wi wi Wi+1 • Until • for all i1, ui = ui • for all i1: pq u

37. 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

38. Incremental Marking: Overview 5 x x5 [1,3](x5) [1,3](x5) 0 2 4 8 6

39. Analog Monitoring Tool: Architecture

40. FLASH Memory Case Study • Provided by STM Italy • Low-level behavior of a digital circuit

41. 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

42. 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

43. 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))); }

44. Evaluation Results – Offline Mode Input size Offline evaluation time

45. Evaluation Results – Incremental vs. Offline Mode Offline vs. Incremental Space Requirement Input size

46. 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

47. Alignment of Data and Data Strobe Signals • Check if DQ and DQS respect the setup and hold times

48. 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));

49. 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

50. Variable Setup Time