RuleBase

1
RuleBase NuSMV
Model Checking in Practice

• ??? ?????? ???

2
Introduction

• In this lecture we will talk about 2 instruments
  that we have today for Model Checking
• RuleBase NuSMV
• The lecture will be mainly on RuleBase,but we
  will get the background on model checking
  instruments in general.

3
Overview

• RuleBase
• Introduction to RuleBase
• RuleBase Basic Features
• Sugar 2.0
• RuleBase DEMO
• The size problem
• Where RuleBase was used?
• Conclusion
• NuSMV
• An overview of NuSMV
• system architecture

4
Abstract

• Until now we talked about simulation as a method
  for hardware verification(creation of test
  vectors ).
• As the complexity of the design increases ,the
  coverage for this method becomes limited.
• For many years Formal Verification was the
  answer,but it was very limited because
• The size of the design was too small
• Limitations for writing the VHDL for some tools
• The language used to describe the model was too
  complex
• RuleBase is a formal verification tool that
  Confronts this limitations!!!

5
Introduction to RuleBase

• RuleBase is an industrial-strength Formal
  Verification (FV) tool, developed by the IBM
  Haifa Research Laboratory.
• RuleBase is especially applicable for verifying
  the control logic of hardware designs.
• RuleBase offers this advanced technology to
  designers and verification engineers and not only
  to FV experts.

6
Introduction - cont

• The basic idea behind RuleBase
• First, to translate the specifications into a set
  of rules, each of which represents a fragment of
  the specification.
• Then check whether the rules hold for a
  particular environment in which the chip might be
  used, that is, for particular combinations of
  legal inputs.
• Assigns a "pass" or "fail" to every rule,
  allowing the designer or verification team to
  find very subtle bugs that would be extremely
  unlikely to be caught by simulation.

7
Introduction - cont

• What is RuleBase ?
• RuleBase employs a powerful Formal Verification
  method called Symbolic CTL Model Checking
• In this method, the system's implementation is
  represented as a state machine and the desired
  behavior is given as a set of temporal-logic
  formulas.
• The model-checking algorithm scans all possible
  states and execution paths in an attempt to find
  a counter-example to the formulas. Unlike
  traditional verification methods, symbolic
  model-checking explores potentially large sets of
  states at each computation step. Unlike
  simulation-based verification, no test cases are
  required.
• Proving a property is equivalent to verifying
  that it holds on to all possible execution paths,
  with all combinations of inputs. No tests are
  required.

8
(No Transcript)
9
RuleBase Basic Features

• 1. High-level rule specification language (Sugar)
  
• Facilitates easy formulation of complex
  temporal properties.
• 2. Convenient Environment Description Language
  (EDL)
• Enables easy abstraction of the environment
  behavior.
• Eases management of multiple environment
  configurations.
• 3. Powerful Model Checking Algorithms
• BDD-based and SAT-based efficient exhaustive
  search, partial search and adaptive search.
• 4. Automatic state space reductions
• Cuts down model size while retaining
  functionality.
• Leaves only parts relevant to verified
  formulas.

10
RuleBase Basic Features-cont

• 5. Generation of counter-examples as timing
  diagrams or simulation testcases
• Counter-examples are provided as timing
  diagrams.
• Counter-examples can be translated to test
  programs.
• 6. Convenient control over the process
• Highly automated.
• Supports manual intervention.
• 7. Debugging aids
• Reduction Analyzer.
• (Simple) Schematics Browser.

11
RuleBase Basic Features-cont

• 8. Smooth integration with design flow
• Verilog is supported via a native compiler
  ("Koala").
• VHDL is supported via Synopsys Design
  Compiler (DC license required).
• RuleBase is fully compatible with TexVHDL
  (for IBM users only).
• 9. Platforms
• IBM RS/6000 running AIX Version 3.2.5 or
  higher.
• Solaris 2.5 or higher.
• Linux Kernel 2.4 or above, Red-hat 7.1 or
  above.
• 10.Friendly GUI

12
(No Transcript)
13
Sugar 2.0
Sugar comes in three flavors Verilog/VHDL/EDL

• Formal Specification Language
• formalism to reason about behavior over time
• Uses of Sugar
• For documentation easy to read, yet precise
  specification
• Input to formal verification tools (model
  checker, theorem prover)
• Input to simulation tools (source of
  automatically generated monitors )

14
History
Sugar 2.0

• 1994
• Syntactic sugaring of CTL for RuleBase model
  checker
• 1995
• Addition of regular expressions
• 1997
• Automatic generation of simulation monitors
• 2001
• Move to linear (LTL-based) semantics
• 2002
• Selected by Accellera for IEEE standardization

Sugar 1.0
Sugar 2.0
15
Overview
Sugar 2.0

• Contains both branching and linear constructs.
• CTL
• SERE Sugar Extended Regular Expression
• Extensive syntactic sugaring

16
Expressiveness
Sugar 2.0

• Theory
• At least as expressive as
• LTL
• CTL
• regular expressions
• Practice
• All properties suggested by FVTC of Accellera
  are concisely and intuitively expressible in
  Sugar

17
Implementation
Sugar 2.0

• Sugar has a core of operators which determine its
  expressive power
• Other operators are syntactic sugaring
  (abbreviations) of the core operators

18
Implementation (of the core)

• Any Sugar property can be reduced to an LTL or
  CTL property using auxiliary state machines.
• CTL and LTL have known model checking
  algorithms..
• For simulation we consider the subset that can be
  verified on-the-fly.

19
(No Transcript)
20
RuleBase DEMO
21
Intruduction

• In this demo I will present a small design of a
  buffer , and explain how to verify it under
  RuleBase .
• RuleBase supports both VHDL and VERILOG.

22
Specification

• BUF is a design block that buffers a word of data
  (32 bits) sent by a sender to a reciever.
• It has 2 control inputs , 2 control outputs and
  a data bus on each side, as shown by the block
  diagramgt

23
Specification-cont

• Communication (on both sides)
• 1.Sender has data to send to the receiver,it
  initiates a transfer by putting the data on the
  data bus and asserting StoB_REQ(sender to buffer
  request).
• 2.If BUF is free ,it reads the data and asserts
  BtoS_ACK (buffer to sender acknowledge).Otherwise
  ,the sender waits.
• After seeing BtoS_ACK ,the sender may release the
  data bus and deassert StoB_REQ .To conclude the
  transaction ,BUF deasserts BtoS_ACK.

24
Specification-cont

• 3.When BUF has data, it initiates a transfer to
  the receiver by putting the data on the data bus
  and asserting BtoR_REQ(buffer to receiver
  request).
• 4.If the receiver is ready ,it reads the data and
  asserts RtoB_ACK (receiver to buffer
  acknowledge).Otherwise BUF waits.
• After seeing RtoB_ACK ,BUF may release the data
  bus and deassert BtoR_REQ.
• To conclude the transaction the receiver
  deasserts RtoB_ACK.

25
BUF implementation

• We have 4 parts
• 1.SENDER_INTERFACE controls the interface
  with the sender.
• 2.RECEIVER_INTERFACE controls the interface
  with the receiver.
• 3.OCCUPIED_FLAG a flag that indicates whether
  BUF has data.
• 4.DATA_BUFFER a register that holds the 32 bit
  data.

26
Modeling the Enviroment

• Enviroment models are described in EDL
• (Enviroment Description Language)
• First a module that describes the behavior is
  defined,and then the module is instantiated.
• If inputs are left unspecified ,unexpected input
  sequences may induce incorrect behaviors of the
  implementation .
• These are called false negatives ,bugs
  which result from a behavior that is impossible
  in the real environment.

27
module sender

• module sender(reset,ack)(req)
• "The sender initiates data transfers 'at random'
  and stay active for an arbitrary long time."
• var state idle ,busy
• assign
• init(state) idle
• next(state)
• case
• reset idle
• state idle !ack idle,busy
• state busy ack idle,busy
• else state
• esac
• define req statebusy
• instance sender sender (RST,BtoS_ACK)(StoB_REQ)
  

28
module receiver

• module receiver(reset,req)(ack)
• var state idle ,busy
• assign
• init(state) idle
• next(state)
• case
• reset idle
• state idle req idle,busy
• state busy !req idle,busy
• else state
• esac
• define ack statebusy
• instance receiver receiver(RST,BtoR_REQ)(RtoB_ACK
  )

29
module reset

• module reset1 ()(RST)
• "A one cycle reset at the begining"
• var RST boolean
• assign
• init(RST) 1
• next(RST) 0
• instance reset reset1 ()(RST)

30
Specifying Properties for verification

• Now we want to verify certain properties (rules)
  of BUF.
• simple example
• rule tauto "This rule just checks that 1 is
  always true" formula AG(1)

31

32
Specifying Properties for verification-cont

• Rule ack_inetrleaving input
  acknowledge and output acknowledge are
  interleaved
• Formula no overflowRtoB_ACK is asserted
  between any two BtoS_ACK assertions
• AG( !RST rose(BtoS_ACK) gt
  AX(rose(RtoB_ACK) before rose(BtoS_ACK)))
• Formula no underflowBtoS_ACK is asserted
  between any two RtoB_ACK assertions AG(
  !RST rose(RtoB_ACK) gt AX(rose(BtoS_ACK)
  before rose(RtoB_ACK)))

33
RuleBase Interface

• The main 4 parts
• A status window with red lines in the upper part.
• A list of rules to be verified (on the left)
  status is Done,Running or Killed.
• A colum of yellow push buttons to control
  verification and its options
• A big text window ,used to display important
  information.

34
DEMO 1

35
DEMO 2

36
DEMO 3

37
DEMO 4

38
DEMO 5

39
DEMO 6

40
DEMO 7

41
DEMO 8

42
END OF DEMO
43
The size problem

• symbolic model-checking requires an abstract
  model of the chip
• The transition relation must be calculated and
  stored.
• A chip with n latches has 2n states.
• One of the solutions
• Reduce the number of latches in a design that
  need to be considered during the verification
  process. By going through a reduction step before
  verification, (designs with as many as a 1,000
  latches can now be verified three to four times
  more than could be handled by the original
  model-checking techniques).

44
Coverage Problem

• RuleBase addresses the coverage problem of
  verification by simulation but it does not solve
  it completely!!
• The questions Have I coded all necessary rules?
  and Have I coded enough environments?
• Verification with RuleBase provide much greater
  coverage then Verification by simulation.(as we
  will see in the next slide)

45
Coverage Problem cont
simulation gt
RuleBase gt
46
Where RuleBase was used

• Industrial Alliances Licensees
• Galileo Technology
• STMicroelectronics
• Zoran Microelectronics
• Mellanox Technologies
• Analog Devices
• Nobug Consulting
• For example
• Zoran's engineers have successfully used RuleBase
  to verify an MPEG video decoder, a video
  processing unit (responsible for MPEG video
  buffers control), a processor decoding function
  responsible for stall generation, an interrupt
  arbiter, an ATAPI interface, and a few smaller
  design blocks.

47
Conclusion

• For many years, the use of formal verification
  was very limited. ( size of design was too small
  in an industrial setting,limitations for writing
  the VHDL for some tools, language used to
  describe the model to check was too complex).
• RuleBase makes formal verification easy with the
  very simple, but powerful language SUGAR.
• Even with a limitation on the size of the design,
  RuleBase can check the industrial design with its
  multiple optimization and reduction algorithms.
• Even though RuleBase was introduced very late in
  the validation stage of the framer, it found some
  bugs that would have been impossible to find
  using simulation.

48
NuSMV
49
Overview - NuSMV

• NuSMV is a software tool for the formal
  verification of finite state systems. It has been
  developed jointly by ITC-IRST and by Carneqie
  Mellon University(CMU).
• NuSMV allows to check finite state systems
  against specifications in the temporal logic CTL.
  
• NuSMV is a re-implementation and a reengineering
  of the SMV model checker developed by McMillan at
  CMU during his PhD.

Istituto per la Ricerca Scientifica e
Tecnologica (IRST)
50
Overview cont

• The basic purpose of the NuSMV language is to
  describe (using expressions in propositional
  calculus) the transition relation of a finite
  Kripke structure.
• Since NuSMV is intended to describe finite
  state machines, the only data types in the
  language are finite ones, i.e. boolean, scalar
  and fixed arrays of basic data types.

51
System Functionalities

• NUSMV can process files written in SMV
• NUSMV supports LTL model checking.
• NUSMV can work in batch mode, just like SMV,
  processing an input file according to the
  specified command line options.
• NUSMV has an interactive mode it enters a shell
  performing a read-eval-print loop, and the user
  can activate the various computation steps (e.g.
  parsing, model construction, reachability
  analysis, model checking)
• The internal parameters of the system can be
  inspected and modified to tune the verification
  process. For instance, the NUSMV interactive
  shell provides full access to the configuration
  options of the underlying BDD package.
• (e.g. partition of the model, BDD variable
  orderings )

52
The NuSMV system architecture
53
system architecture cont

• kernel. The kernel provides the low level
  functionalities (dynamic memory allocation, basic
  data structures,basic BDD primitives, directly
  taken from the CUDD BDD package).
• Parser. This module implements the routines to
  process a file written in NUSMV language, check
  its syntactic correctness, and build a parse
  tree.

54
system architecture cont

• COMPILER This module is responsible for the
  compilation of the parsed model into BDDs.
• The Instantiation. sub module processes the parse
  tree, and performs the instantiation of the
  declared modules, building a description of the
  finite state machine (FSM) representing the
  model.
• The Encoding. sub module performs the encoding
  of data types and finite ranges into boolean
  domains. Having separated this module makes it
  possible to have different encoding policies
  which can be more appropriate for different kind
  of variables (e.g. data path, control path).
• The FSM Compiler. sub module provides the
  routines for constructing and manipulating FSM's
  at the BDD level. It is responsible of all the
  necessary semantic checks on the read model, such
  as the absence of circular definitions.

55
system architecture cont

• Model Checking. This module provides the
  functionalities.
• This module provides the routines for
  counterexample generation and inspection.
• LTL. Translates the LTL formula into a tableau
  suitable to be loaded into NUSMV. This program
  also generates a new CTL formula to be verified
  on the synchronous product of the original system
  and the generated tableau.
• Interactive Shell. From the interaction shell the
  user has full access to all the functionalities
  provided by the system.
• GUI-Graphical User Interface.

56
(No Transcript)
57
END OF NuSMV
58
CONCLUSIONS

• This was a small presentation on Model Checking
  in Practice and a little bit on the theory behind
  it.
• What have we seen?
• RuleBase
• Sugar (and CTL)
• NuSMV
• Symbolic Model Checking

59
THE END
60
IBM Research Labs in Haifa Announce the Release
of RuleBase Version 1.4

• The RuleBase formal verification tool, with
  enhanced performance, is now available on more
  platforms Haifa, Israel, June 20, 2002 The
  Formal Methods department at the IBM Research
  Labs in Haifa today released a new version of
  RuleBase, the industry-leading model checker.
  RuleBase is a functional verification tool that
  determines whether a design functions according
  to a specified set of properties. The tool
  ensures a very high degree of verification
  coverage and design quality, as well as faster
  time-to-market for the final design. As opposed
  to simulation, RuleBase leverages static checking
  algorithms and requires no test cases. To date,
  RuleBase supports assertion-based verification
  (ABV) methodologies across IBM and for several
  strategic business partners. Many design teams
  have reported that RuleBase detected design flaws
  that would have escaped traditional simulation
  methods. RuleBase 1.4 comes in two versions
  RuleBase Classic and RuleBase Premium. The heart
  of the Classic offering is a BDD-based search
  engine called Discovery, which has been in use
  since 1994 and is continuously being improved.
  The Premium version of RuleBase 1.4 is now
  officially available to the verification
  community. On top of the Classic version,
  RuleBase Premium contains a set of additional
  verification engines, which excel in finding bugs
  in very large, high-complexity logic models.
  Similar to previous versions, RuleBase 1.4 runs
  on both AIX and Solaris, and now runs on Linux.
  RuleBase 1.4 highlights
• Runs on Linux, Sun/Solaris, and AIX.
• Classic version with field-proven BDD-based
  Discovery search engine.
• Premium version with new state-space compression
  search algorithms.
• Platform-independent and user friendly GUI.
• About 10 years of proven state-of-the-art of
  Formal Verification experience.
• Support for user-defined search directives
  (Hints).
• Includes a 64-bit version of the Discovery search
  engine.
• RuleBase 1.4 is available for a 90-day trial
  period. For more details see http//www.haifa.il.
  ibm.com/projects/verification/RB_Homepage/evaluate
  .html

61
SEREs
Sugar 2.0

• Sugar Extended Regular Expressions
• Why extended?
• more operators than regular expressions
• built from boolean expressions over the atomic
  propositions
• p q, r s, t u v
• Engineers find SEREs to be a natural way of
  expressing specifications shown as timing diagrams

62
Catching bugs on the fly

• On-the-fly verification interleaves the
  verification steps with the process of building
  the state space, allowing one, in the initial
  stages, to check the rules on a much smaller
  number of states and thereby vastly reduce the
  resources needed for verification. As soon as one
  finds a bug, one stops, so the rest of the state
  space and transition relations need never be
  built.
• However, the technique requires a different kind
  of algorithm for checking the rules, and that
  algorithm applied to only a small percentage of
  the rules one needed to check. (can be done with
  Sugar!!!).

63
NuSMV SMV

• NuSMV provides the following additional features
  
• Interaction. In addition to the usual SMV batch
  mode, NuSMV provides a textual interaction
  shell.Through the shell the user can activate
  various NuSMV computation steps as system
  commands with different options. These
  computation steps can therefore be invoked
  separately and possibly undone.
• Analysis of invariants. Specialized routines
  allow for checking invariants, i.e. formulae
  which must hold uniformly on the model, on the
  fly during reachability analysis.

64
NuSMV SMV cont

• Partitioning methods. The model can be
  partitioned conjunctively and disjunctively. The
  partitions can be inspected, and (for the
  conjunctive case) ordered according to the
  heuristics defined in.
• LTL Model Checking. LTL model checking is
  performed via reduction to CTL model checking,
  according to the algorithm proposed in. An LTL
  specification is automatically converted into a
  tableau, which is then used to extend the model
  in synchronous product. The result is provided by
  checking the truth of a CTL formula in the
  extended model.