Formal Analysis of Hardware Requirements

1
Formal Analysis of Hardware Requirements

• Marco Roveri
• ITC-irst
• roveri_at_itc.it
• July 27, 2006

Joint work with R. Bloem, I. Pill Graz
University of Technology R. Cavada, A. Cimatti,
S. Semprini ITC-irstWork founded by EC 507219
PROSYD
2
Outline

• Motivation
• Requirements
• Requirements Analysis
• Requirements Analysis Techniques
• An Example
• Methodological Guidelines
• Underlying Technologies
• The RAT Tool
• Conclusions Future Work

3
Motivations

• Assertion Based Verification is becoming
  increasingly important
• Formally stated requirements (specification) used
  to check correctness of a design
• Dynamic and static verification
• Trend supported by expressive specification
  languages (PSL, SVA, ForSpec)
• Seldom requirements are object of quality control
• Industry about 50 of defects and 80 of rework
  effort originate in flawed requirements K.E.
  Wiegers. Inspecting Requirements.
  Sticky Minds Weekly Column, July 2001

4
Requirements

• Requirements are the description of the
  functional behavior of a system and of the
  assumptions on its environment
• Requirements are not the description of a design

5
Requirements

• Used for
• Communication
• Development
• Formal Verification
• Key issues
• Difficult to understand
• Complexities
• Subtleties
• Quality assurance?

6
Requirements Analysis

• Explore and assure the quality of requirements
• Formal Language
• Techniques
• Methodological Guidelines
• Tools
• Not design validation
• No design yet
• Performed before their usage

7
Requirements Analysis

• Issues
• Formalism understand the semantics?
• Correctness capture my intent?
• Consistency sensible?
• Under-constraining unwanted behaviors?
• Over-constraining desirable behaviors?
• Vacuity trivial scenarios?
• Realizability implementable?

8
Requirements Analysis

• Our approach focuses on
• Understanding the formalism
• Compliance w.r.t. engineers intent
• Consistency
• Under/over-constraining
• Thus ensures
• Proper formalization
• Proof of consistency
• Compliance with what is unwanted/desirable

9
Requirements Analysis our proposal

• Two techniques
• Property Simulation
• Property Assurance
• Methodological guidelines how to apply and
  integrate the two techniques
• A tool Requirement Analysis Tool (RAT)

10
Property Simulation

• Understanding the formalism
• Compliance w.r.t. engineers intent
• Achieved by
• Interactive exploration of the behaviors
• Asking for compliant/contradicting behaviors
• Modifying behaviors to check whether they remain
  compliant/contradicting
• Inspecting behaviors

11
Property Assurance

• Consistency of requirements
• Analysis of under-/over-constraining
• Achieved by
• Checking for existence of compliant behaviors
• Checking against golden properties
• Possibilities are they feasible?
• Assertions are they violated?
• Showing debugging information

12
An example Initial Specification

• An arbiter receiving requests and issuing grants
  
• Boolean signals
• The requirements (PSL like formalization)
• Any request is eventually grantedR1
• No simultaneous grants for the two linesR2

13
An example Property Assurance (I)

• Rule out unwanted behavior
• right after a grant, no request means no
  grant
• Assertion A1

14
An example Property Assurance (II)

• Checking the requirements we get
• 
  Compliant with R1 but not with A1
  R1 does
  not rule out initial spurious grants
• We add a requirement initially no grants
  before requests
• R3
• 
  Compliant with R1, R2 and R3
  but not with A
  R1, R2
  and R3 do not rule out unneeded grants
• We add a requirement after a grant, no other
  grants until a request is issued
• R4

Green part repeats infinitely
15
An example Property Simulation (I)

• We want to be sure about what we have done
• Explore behaviors to gain understanding and
  confidence
• In particular, the semantics of
• R4
• is not trivial

16
An example Property Simulation (II)

• Exploring semantics of requirement R4
• B1
  Compliant with R4
  trivial no requests are
  issued
• Imposing a request at first tick
• 
  not compliant with R4
• B2
  is false at the first tick because is
• 
  never true while this is requested by
• 
  the semantics of
• Hence we weaken R4 (and R3) by using
  R3 R4
• We generalize this behavior by adding a
  possibility P1

17
An Example The Results of Analysis

• Refined requirements Added R3 and R4
• Semantic inspection requirements correction
  until vs. until!
• Assertionsright after a grant, no request
  means no grant
• Possibilitiesrequests may be not issued

18
Methodological Guidelines

• Trying to systematize what we have seen in the
  example
• set of requirements
• set of assertions
• set of possibilities

Property Assurance
Property Simulation
Inspect and explorerepresentative traces
Add possibilities,assertions
Integration
19
Underlying Technologies (I)

• Automata-based Model Checking
• BDD-based
• Language emptiness check
• Accepting runs are example behaviors
• Bounded Model Checking
• SAT-based
• Propositional encoding of lasso shaped paths
  checked for satisfiability
• Bounded witnesses/counterexamples of a property

20
Underlying Technologies (II)

• Property Simulation
• Automata-based
• Automata for requirement(s) and for user-defined
  constraints
• Language emptiness on product automaton
• Analysis of traces provides a measure of coverage
• Property Assurance
• Automata-based/Bounded Model Checking
• Consistency check
• Assertion check for
• Possibility check for

21
The RAT Tool

• Supports the methodological guidelines
• User-friendly access to the techniques
• Specification management
• Results management
• Builds over state-of-the-art verification
  technologies
• NuSMV model checker
• http//nusmv.irst.itc.it
• VIS model checker
• http//vlsi.colorado.edu/vis
• Full support for PSL CIAA06, FMCAD06
• Available at http//rat.itc.it
• LGPLs license

22
The RAT Tool GUI
Project management
Signals and requirements
Assertions and Possibilities
Interface to Property Assurance technology
Waveform-like visualization of behaviors
23
The RAT Tool GUI (II)
Access to specification while simulating
Properties to be simulated
Simulation traces/Stimuli Editing
Syntax tree sub-formula satisfaction
24
The RAT Tool Some Features
Coverage statistics
Enforce features
25
The RAT tool Some Features (II)
26
Industrial Validation First Results

• Input Block (ST Microelectronic)
• 54 Boolean signals
• 159 Requirements in PSL
• Assertion A well formed input packet does
  get right through the Input Block
• Successfully verified by RAT
• Successfully used RAT to prove that replacing a
  small number of properties in a specification by
  a different set, preserves an assertion
• Thus proving the two complete sets are equivalent
  w.r.t. the assertion
• Property simulation used to understand and
  correct some of the PSL requirements
• Several other industrial case studies are being
  considered within the PROSYD project (jointly
  with IBM, ST, OneSpin)
• The WISHBONE System-on-Chip (SoC) Interconnect
  Architecture for Portable IP Coreshttp//www.open
  cores.org/projects.cgi/web/wishbone/wishbone

27
Conclusions Future Work

• We have
• Techniques and methodological guidelines for
  requirements analysis
• A tool supporting the adoption of our techniques
  in practice
• We are working/will work on
• Diagnostics
• Requirements level
• Subset of requirements responsible for an
  inconsistency
• Subset of requirements needed to satisfy an
  assertion/possibility
• Subset of requirements responsible for violating
  an assertion/possibility
• Interpretation of unsatisfiable core
• Trace level
• Signal
• Ticks
• Values
• Vacuity
• Identify vacuity conditions
• Realizability
• Beyond satisfiability is it possible to
  implement the specification?
• Automatic Synthesis

28
Thank you!