RSP OSS Schulung

OneSpin Solutions
Training Module Verification

Part I - Basics
July 2007
OneSpin Solutions GmbH
Theresienhoehe 12
80339 Munich Germany
support@onespin-solutions.com
Content
Module 1: Introduction to Formal Verification
Module 2: OneSpin Shell and Data base
Module 3: Models
Module 4: Set up a design
Module 5: Checking Properties
Module 6: How to check and debug properties
Module 7: Operation Properties
Module 8: More Advanced Properties
confidential
July 2007/Page 2
Module 1: Introduction to Formal Verification
What do you learn now ?
confidential
Where does assertion / property checking fit

into the verification flow?
What are the advantages of using

formal verification technology?
July 2007/Page 4
Formal Verification in Design Flow

Specification
e.g. RTL Entry
Verify Implementation:
Propery Checking
Implementation 1
Check RTL Integrity:

Consistency Checking
Implementation n
Verify Preservation:
Equivalence Checking
e.g. Synthesis
Goal: implementation meets specification.

Strategy: Verification is split into several steps.
OneSpin offers comprehensive formal verification
tool suite.
confidential
July 2007/Page 5
Verification is split
A
tpdLH
tpdHL
1.3 ns
1.1 ns
Strategy: Verification is split into function and timing.
confidential
July 2007/Page 6
Verification Methods
Function *)
Implementation
Simulation
Simulation
Formal Consistency &

Property Checking
Static Timing
Analysis
Simulation
Simulation
Formal
Equivalence Checking
Static Timing
Analysis
Preservation
Manufacturing
ATPG,...
*)
confidential
Timing
At-Speed Test,
High Temperature,
...
including cycle-based timing

July 2007/Page 7
Simulation
Specification
Testbench
Pattern
Generator
Design
Pattern
Analyzer
Simulator
hold/fail
Simulation is incomplete.
Testbench required.
confidential
July 2007/Page 8
Property Checking
Design
Specification
Properties
HDL-Front-End
Property Checker
hold/fail
confidential
Diagnostics
No pattern generator: formal approach is exhaustive.
100% functional coverage achievable.
Significantly reduced verification costs.

July 2007/Page 9
Consistency Checking
Specification
Properties
Consistency
Checks
Design
HDL-Front-End
Consistency
checker
Proof Engine
Statistics
confidential
Diagnostics
Extracts pre-defined and user-defined checks from RTL

without user effort.
Uses OneSpins HDL-front-ends and formal verification
technology: exhaustive checks of all possible scenarios.
July 2007/Page 10
Comparison
Simulation
011
010
001
000
Design
Examine a small
number of patterns
Runtime limitations
confidential
Property/Consistency Checking
111
110
101
100
011
010
001
000
Design
Same as automatic,
exhaustive simulation
each functionality
stimulated
Much faster than
exhaustive simulation
July 2007/Page 11
Operation Properties
request
rw
address
incominga
outgoing
write_data d
ready
pr nop
act nop wr nop
control
sdram_addr
a'
a''
sdram_wdat
d
idle
state idle
assume:
incoming_write(t, addr, data);
in_idle_state(t);
prove:
outgoing_write(t+1, addr, data);
ackn_incoming_write(t, t+1, t+7);
in_idle_state(t+7);
Main parts
Assume part: Situation analyzed by the property
Prove part: Expected behavior in this situation
Examples:
Transactions of a bus bridge
Instructions of a processor
confidential
If property is proven, slide it across any possible simulation

run
Unspecified signal values are dont care
July 2007/Page 12
360 MV Blocks All Error Escape Routes
Current Verification Practice
360 MV
confidential
July 2007/Page 14
Summary
Consistency Checking (Dynamic Linting, Intent

Checking)
generates and proves a vast number of simple assertions:

pre-defined ones extracted from the design.
ones extracted from user-defined incode-assertions.
confidential
July 2007/Page 15
Summary
Property Checking
verifies the implementation of a specification.
neither needs a testbench, nor an environment.
verifies function, no low-level timing.
generates a pattern if the property is violated.
verifies as many patterns as exhaustive simulation.
is much faster than exhaustive simulation.
Completeness Checking
confidential
attains 100% functional coverage!
July 2007/Page 16
Module 2: OneSpin Shell and Data base
confidential
shell and database
July 2007/Page 18
Tcl Shell
OneSpin shell is an extension of the Tcl shell
Tcl (tool command language) is standard in EDA
Tcl allows execution of
OneSpin-commands
Tcl-commands (e.g. set, lindex)
Tcl-scripts
Tcl allows definition of variables and procedures
confidential
July 2007/Page 19
Starting OneSpin shell

% onespin --help
% onespin &
% onespin -gui=no
setup> # some commands
setup> ...
setup> exit
%
% onespin my_run.tcl
% onespin -interactive_after_script my_run.tcl
confidential
July 2007/Page 20
Data in OneSpin Shell

All data needed for verification and all results
are persistent
I.e. the data is saved to and loaded from disk
Data collection is called database

User knows only a few files besides session
database
ITL
reference
VHDL
Verilog
reference
HDL-files (VHDL, Verilog)

ITL-files contain properties
OneSpin
commands
database
tcl
commands
tcl variables
persistence
database
OneSpin shell
confidential
July 2007/Page 21
Load and Save of Database

> onespin
setup> save_database my_database
setup> exit
> onespin --database my_database
setup> save_database my_database
setup> exit
> onespin
setup> load_database my_database
setup> exit ;# prompt for save: yes/no
confidential
July 2007/Page 22
Modes
The mode of the OneSpin Shell is a state
Mode can be either
setup (initial): read and configure designs and units
ec = equivalence checking
mv = module verification: checking properties,
assertions, completeness
cc = consistency checking
User guidance: commands for the respective task

Commands available for more than one mode
Mode change by set_mode
ec
Prompt shows current mode
setup
cc
setup> set_mode mv
mv>
mv
confidential
July 2007/Page 23
Help
Help for commands
setup> help <command-pattern>
Examples
setup> help *vhdl*
setup> help mode mv *propert*
Complete user documentation
(including Reference manual)
Help button/Help menu
Pdf-file in $ONESPINROOT/doc
confidential
July 2007/Page 24
Log Files
for commands
to create regression scripts
setup> start_command_log <log-file>
# all command lines are logged in <log-file>
setup> stop_command_log
for messages and commands

setup> start_message_log <log-file>
# all messages are logged in <log-file>
setup> stop_message_log
confidential
July 2007/Page 25
Module 3: Models
confidential
Modeling & abstraction for property checking.
July 2007/Page 27
Motivation
EDA tools usually compile the design into an
internal format which
enables the fastest algorithms for their purpose.
saves memory by keeping only data needed for their
specific functionality.
This internal format is also called a "model".

Model examples:
confidential
Layout editor: geometrical shapes on a grid

HDL simulation: "event-based" or "cycle-based"
Synthesis: data & control flow graphs
Formal Verification: finite state machine (FSM)
July 2007/Page 28
Abstraction (VHDL)
An abstraction of a model is a less detailed model
than the original one.
FSM for property checking is an abstraction of the
standard VHDL semantics IEEE 1076
restricted to zero delay descriptions.
Synthesis-like abstraction:
reduces real time to events (i.e. rising/falling edges).
ignores propagation delays (after)
samples outputs of settled combinational logic (i.e. no
spikes).
Additional abstraction (optional):

clock cycle accuracy
confidential
July 2007/Page 29
Model for Property Checking: FSM

A finite state machine (FSM) of OneSpin consists
of:
set of input variables

set of output variables
set of state variables
next-state functions for all state variables: calculate the
next state for a state variable from states and inputs
output functions for all output variables: calculate the
output for an output variable from states and inputs
set of internal variables: represent internal signals,
certain VHDL assertion statements, constants, etc.
Initial state is not part of the model.
confidential
July 2007/Page 31
FSM Model of a Design

Design
i1
ns6
s6
ns5
s5
ns4
s4
i4
ns3
s3
i5
ns2
s2
i2
i3
i6
i7
i8
A2
next
state
logic
A1
next
state
logic
ns9
s1
o1
s9
inputs
A4
next
state
&
output
logic
A3
ns1
FSM
next
state
logic
o2
ns8
s8
ns7
s7
outputs
combinational
logic
o3
A5
output
logic
o4
states
q d
next-states
q d
State of FSM consists of all registers of the design.
confidential
July 2007/Page 32
State Transition Diagram of a FSM

one output
variable
called "q"
two input
variables
"d1 and "d2"
d1,d2/q
input 1 for d1
0 for d2
output 0
for q
1,0/0
(s1,s2)
(0,0)
two state variables: "s1" and "s2"
s1 is in state 0
s2 is in state 0
s1 is in state 0
s2 is in state 0
input 1 for d1
0 for d2
1,0/0=output function(0,0,1,0)
(0,1)=next-state
(0,0)
function(0,0,1,0)
confidential
July 2007/Page 33
Example
time point 0 1 2 3 4
state 0 0 1 1 0
in 0 1 1 0
synchronous DFF
1/0
1
out 0 0 1 1
0/0
0
1
0/1
1/1
1/1
state
in
out
One triple of (state, inputs, outputs) is associated

with one point in time, called "time point".
One step of a FSM is associated with one
"time unit".
A FSM models discrete time by "sampling once
per clock cycle.
confidential
July 2007/Page 34
Structural Abstraction: Black boxing

Black boxing means not representing certain cells,
modules, sub net lists, etc. in the model.
1. Cut out component B:
A
C
B
confidential
July 2007/Page 35
Black boxing, continued

2. Make driver to Bs inputs primary outputs:
A
3. Make signal driven by Bs outputs primary inputs:

A
confidential
July 2007/Page 36
Black boxing, continued

A
C
B
only values
generated
by B are
considered
all values are

considered
Black boxing B may allow input traces on C that

could not be generated by B.
(false-negative problem)
Properties which hold on models with black
boxing also hold for models without black boxing.
confidential
July 2007/Page 37
Module 4: Set up a design
Simplest Use Case of Setup and MV

Read
VHDL/Verilog
Elaboration
Compilation
Go to mv mode
> onespin
setup> read_vhdl c.vhd d.vhd
setup> elaborate
setup> compile
setup> set_mode mv
mv> read_itl a.vhi
mv> check_property read_req
mv> report_results
Read ITL
(properties)
Check a
property
Show results
confidential
July 2007/Page 39
HDL model and Design model

HDL
mod_5
mod_1
i1: mod_2
i2: mod_2
i1: mod_4
i1: mod_4
i2: mod_4
Design
i3: mod_3
i1: mod_4
i2: mod_4
i2: mod_2
i1: mod_4
i2: mod_4
Parsed and analyzed HDL

files
i1: mod_5
Design model
mod_1
i1: mod_2
confidential
HDL model
i2: mod_4
i3: mod_3
i1: black box
Elaborated from HDL

One top-level
Black boxes (optional)
typically for RAMs
Fixed values for generics/
parameters
July 2007/Page 40
Phases of Setup Mode
setup
read_hdl
elaborate
compile
pin declaration
set_read_hdl_option
get_read_hdl_option
read_vhdl/read_verilog
set_elaborate_option
get_elaborate_option
elaborate
set_compile_option
get_compile_option
compile
mv
confidential
July 2007/Page 41
Scheme for Option-Commands

Operation
set_
get_
add_
delete_
report_
confidential
Phase
read_hdl
elaborate
compile
debug
monitor
map
compare
_option
July 2007/Page 42
setup
read_hdl
elaborate
compile
pin declaration
mv
confidential
July 2007/Page 43
Read-HDL Phase: Read a VHDL Design
1. set options for read VHDL
> onespin
setup> set_read_hdl_option -vhdl_version 93
-pragma_ignore synthesis_
2. Read VHDL files
setup> read_vhdl -library juhu a.vhd b.vhd

setup> read_vhdl -pragma_ignore translate_
-version 87
c.vhd
read_vhdl creates hdl-model i.e. parse information

option library: vhdl-files compiled into a library
options of read_vhdl overrules read_hdl_options
except option pragma_ignore: cumulative
confidential
July 2007/Page 44
setting read_hdl options

set one or more options
setup> set_read_hdl_option -vhdl_version 93
-pragma_ignore synthesis_
set an option to a list: use tcl-lists
setup> set_read_hdl_option -pragma_ignore
{synthesis_ translate_}
check and use the values
setup> get_read_hdl_option -pragma_ignore
synthesis_ translate_
setup> report_read_hdl_option
vhdl_version: 93
pragma_ignore: synthesis_
translate_
setup> set my_vhdl_version \
[get_read_hdl_option vhdl_version]
93
confidential
July 2007/Page 45
Omitting VHDL text parts

Omit VHDL text parts between pragmas
e.g. omit the following text between the pragmas:
-- pragma translate_off;
signal testbench_error_code: integer;
-- pragma translate_on;
by specifying the pragma_ignore option:

setup> set_read_hdl_option pragma_ignore translate_
confidential
July 2007/Page 46
Read-HDL Phase: Parse Errors

if read_vhdl/read_verilog not successful
VHDL-/Verilog-files have to be read again
all files of the failed read_vhdl/read_verilog command
setup> read_vhdl -library my_lib a.vhd b.vhd
-E- ...
setup> # <fix syntax problem>
setup> read_vhdl -library my_lib a.vhd b.vhd
setup>
confidential
July 2007/Page 49
Read-HDL Phase: Restart

To remove previous parse results
setup> clear_design
read_hdl_options are not reset by clear_design
confidential
July 2007/Page 50
Read HDL Phase: Example (VHDL)

read_vhdl arbiter.vhd
confidential
July 2007/Page 51
setup
read_hdl
elaborate
compile
pin declaration
mv
confidential
July 2007/Page 53
Elaborate Phase
> onespin
setup> set_elaborate_option
-vhdl_generic
-verilog_parameter
-black_box
-top
abc=2
le=0
*ram*
arb
Elaboration
setup> elaborate
top level is automatically detected if unique and not
specified
confidential
July 2007/Page 54
Elaborate Phase: HDL change

Design model elaborated and HDL changed
afterwards
not necessary to call read-commands again
manually
setup> elaborate -reread_hdl
removes old parsed and design model

reads the same HDL files with the same
options again
confidential
July 2007/Page 55
Elaborate Phase: Example (VHDL)

set_elaborate_option -vhdl_generic nr_masters=5
elaborate
confidential
July 2007/Page 56
setup
read_hdl
elaborate
compile
pin declaration
mv
confidential
July 2007/Page 58
Compilation
> onespin
setup> set_compile_option
for advanced users only
Compilation
setup> compile
Needed to enable pin declaration
confidential
July 2007/Page 59
setup
read_hdl
elaborate
compile
pin declaration
mv
confidential
July 2007/Page 60
Pin Declaration
setup> set_clocking -rising clk
Alternative settings:
-default
-falling <pin>
and others
found during compilation

falling edge of <pin>
setup> set_reset_sequence -low res_n

Alternative settings:
-default
found during compilation
-high <pin>
high active reset <pin>
-scheme <sequence> arbitrary reset-sequence
confidential
July 2007/Page 61
Pin Declaration Phase: Example (VHDL)

Set_mode mv
confidential
July 2007/Page 62
Model building assertions

There are signal assignments that cause a
simulator to stop because the HDL semantics is
not defined.
architecture beh of ai is
begin
process(clk,reset)
begin
if reset = '1' then
v <= (others => '0');
elsif clk'event and
clk = '1' then
if i < 4 then
v(i) <= '1';
end if;
end if;
end process;
end beh;
confidential
entity ai is
port(
clk,reset: in bit;
i: in integer;
v: out bit_vector(3 downto 0)
);
end ai;
July 2007/Page 64
Model building assertions: OneSpin solution

OneSpin model produces an output for each
value of the inputs and states even if an
simulation run-time error would occur
Output of the onespin model is arbitrary in this
case!
A generated assertion fires then.
v(i) <= '1';
confidential
if (i >= 0) and (i <= 3) then

v(i) <= '1';
else
v(<arbitrary>) <= '1';
assert (false);
end if;
July 2007/Page 65
Check Model building assertions

It can be proven that a model building assertion
can never fire starting from a reset state
mv> check_consistency -category model_building
If it fails, one has to investigate the HDL code and

the generated trace for the cause of the problem.
confidential
July 2007/Page 66
Example (VHDL)
read_vhdl arbiter.vhd
set_elaborate_option -vhdl_generic nr_masters=5
elaborate
set_mode mv
check_consistency -category model_building
confidential
July 2007/Page 67
Module 5: Checking Properties

property syntax
the basics, just bits and bit-vectors
only the stuff needed for the 1st example
counter-example
confidential
July 2007/Page 70
Flow for Property Checking

Specification
RTL
Model
Property
OneSpin Property Checker
hold/fail
confidential
Waveform Viewer
Property Debugger
July 2007/Page 71
Basic Idea of the Language
Simple temporal operators + VHDL/Verilog like state

expressions
ITL properties specify cause-effect relations between
signals similar to waveforms.
+1
t_free
+0
+1
+2
0-11
state
idle
request
_ /= 0
_ /= idle
idle
free
_ /= 0
grant
If
confidential
Assumptions
hold, then Commitments
hold.
If property is proven, slide it across any possible simulation

run.
Wherever the blue patterns match, the red ones will match.
July 2007/Page 72
Specification
d_i
res
dff
q_o
clk
If res is inactive (i.e. = 1) the input d_i will be

available at the output q_o one clock cycle later.
The circuit is fully synchronous with rising edge on
clock clk.
confidential
July 2007/Page 73
Design
library IEEE;
use IEEE.std_logic_1164.all;
entity dff is
port(
clk : in std_logic;
d_i : in std_logic;
q_o : out std_logic;
);
end dff;
architecture rtl of dff is
begin
process
begin
wait until clkevent and clk = '1';
q_o <= d_i;
end process;
end rtl;
Confidential
CVE Assertion Checking

Infineon Technologies AG 2004, All rights reserved
I-2/6
Property
Assuming res is inactive (i.e. = 1) an arbitrary
value of input d_i will be available at the
output q_o one clock cycle later:
Assumption
Commitment
property dff is
assume:
at t: res = 1;
prove:
at t+1: q_o = prev(d_i);
end property;
t is the referential time point

(any simulation cycle).
confidential
July 2007/Page 74
Commitments and Assumptions

property Example is
Assumptions
Environment
Commitments
end property;
Design
A property is split into two parts: a list of

commitments and a list of assumptions.
Commitments describe the design.
Assumptions describe the environment.
confidential
July 2007/Page 75
Semantics as Combinational Model

Exhaustive (2n) Pattern Generator
Unrolled design
inputs
nextstates
states
internal
nets outputs
inputs
nextstates
states
internal
nets outputs
inputs
nextstates
states
internal
nets outputs
Pattern Analyzer
time point t
time point t+1
time point t+2
Derived from property

confidential
hold/fail
July 2007/Page 76
Pattern Analyzer
Assumption 1
Assumption 2
Commitment 1
Commitment 2
Commitment 3
Assumption 3
&
&
confidential
1
0
hold/fail
Assumptions enable the commitments to be

checked.
If the assumptions disable, there is nothing to
check.
July 2007/Page 77
Semantics and Waveforms, Step 1

Exhaustive Pattern Generator
inputs
determines all states at first
states
3
cycle t and all inputs for int. signals
e
s
a
c
complete examination
outputs
t
t+1
t+2
window.
inputs
Next-state- and
states
2
e
output-functions of
s
int. signals
a
c
outputs
Finite State Machine
t
t+1
t+2
i.e. the design
inputs
determine all states from
states
1
cycle t+1 until the end and
e
int. signals
s
a
c
all internal signals and outputs for
outputs
t
t+1
t+2 the complete examination window.
confidential
July 2007/Page 78

Assumptions sort out those waveforms for which
the assumption is false.
inputs
states
int. signals
outputs
inputs
states
int. signals
outputs
inputs
states
int. signals
outputs
confidential
3
e
cas
t+1
2
e
cas
t+1
1
e
cas
t+1
True
t+2
True
t+2
t+2
inputs
states
int. signals
outputs
inputs
states
int. signals
outputs
inputs
states
False int. signals
outputs
3
e
cas
t
t+1
t+2
2
e
cas
t
t+1
t+2
1
e
cas
t
t+1
t+2
July 2007/Page 79

inputs
states
int. signals
outputs
inputs
states
int. signals
outputs
3
e
cas
t
t+1
True
&
t+2
2
e
s
ca
fail
False
t
t+1
t+2
counter-example found
Commitments decide whether a property holds

or fails.
If commitment fails for at least one waveform
the property fails.
confidential
July 2007/Page 80
Example: Parity Generator

S
I
S@t I@t
nextstate
output
state
Q@t
input
nextstate
output
state
Q@t+1
=
1
'0'
property parity is
assume:
at t: S = '0';
prove:
at t+1:
Q = I xor prev(I);
end property;
I@t+1 time point t+1
time point t
input
1
0
hold/
fail
=
commitment
assumption
confidential
July 2007/Page 81
Counter-Examples (1)
Diagnostic produces a sequence over the
examination window, which is called "counterexample".
A counter-example demonstrates why a property
fails: assumptions hold; at least one commitment
fails.
There may be many counter-examples.
A heuristic selects one specific counter-example.
The input d
will be
available at
the output q
two clock
cycles later.
confidential
q
t
t+1
t+2
t+1
t+2
July 2007/Page 82
Counter-Examples (2)
counter-example: like simulation trace
starts in an arbitrary state
applies values to the inputs
goes through a state-sequence that contradicts the
property
confidential
July 2007/Page 83
Prove and Assume Part
assume part
= assumption
property name
property <Identifier> is
assume:
<TemporalExpr>;
prove part
prove:
= commitment
<TemporalExpr>;
end property;
A property is identified by a property name.

assume part is a list of assumptions. (optional)
prove part is a list of commitments.
Assumptions and commitments have the same
syntax.
confidential
July 2007/Page 84
Temporal Expressions
For a commitment or an assumption, a
temporal expression defines:
the combinational logic block.
the points of time at which inputs, states, outputs,
and internal nets are read by that combinational logic
block.
hold/fail
confidential
July 2007/Page 85
at t
property Example is
prove:
at t: <StateExpr>;
end property;
VHDL or Verilog - like

expressions over input,
state, output variables,
and internal signals
read variables
at time point t
Examination window is [t,t].

Property holds if and only if the
state expression <StateExpr> is
true for all examined inputs, states,
outputs, and internal nets at time
point t.
confidential
July 2007/Page 86
at
General syntax: at t+<offset>: <StateExpr>;
at t-<offset>: <StateExpr>;
<offset> is a constant integer expression

containing
Arithmetic: +, -, *
Parentheses: ()
Examples:
at t:
a = b;
at t-2:
a = 1;
at t+(3-2)*2: a > b;
The combinational logic block is determined by

a state expression <StateExpr>.
Inputs, states, etc. are read by that combinational
logic block at some constant offset from t.
confidential
July 2007/Page 87
Examination Window
The right bound of the examination window is the
highest point of time being referred to in the
property.
The left bound of the examination window is either
t or the lowest negative point of time being
referred to in the property if there is any negative
one.
confidential
July 2007/Page 88
History in Examination Window

property Example is
property Example is
assume:
assume:
at t-1: <StateExpr>;
at t+1: <StateExpr>;
prove:
prove:
end property;
end property;
t-1
t+1
t+1
t+2
t+3
"history"
of one additional state transition
confidential
July 2007/Page 89
during
General syntax:
during [t[+-]<offset>,t[+-]<offset>] : <StateExpr>
Example:
during [t-1,t+2] : a = 1;
If the time interval is non-empty, this is equivalent

to an according number of timed state expressions
at.
property Example is
prove:
during [t+1,t+3]:
<StateExpr>;
end property;
property Example is
prove:
end property;
If the time interval is empty (e.g. [t+3,t+1]),

this is the same as if the during construct were
not there
confidential
July 2007/Page 90
What do you learn now?

Write properties
Check properties
Debug properties and design
Application Example
confidential
July 2007/Page 92
Design Under Verification: Arbiter

Resource
Master 0
Master 1
grant_o
free_i
Arbiter
Master
ster 2 2
3
confidential
request_i
July 2007/Page 93
A Typical Trace
request_i(0)
request_i(1)
request_i(2)
grant_o(0)
grant_o(1)
grant_o(2)
free_i
state_s
confidential
busy
idle st
busy
idle st
July 2007/Page 94
Implementation of the Arbiter

request_i
Master w. lowest index wins
prio_s=0: no request
prio_s
grant_o/=0
state_s = IDLE
Reset state
Wait for requests
START
IDLE
state_s = START
Grant the highest priority master
BUSY
state_s = BUSY
Wait for the resource to become free
free_i/=0
confidential
July 2007/Page 95
Reading the Design
setup> read_vhdl arbiter.vhd
setup> elaborate
setup> set_mode mv
default clock found
default reset found
confidential
July 2007/Page 96
A Simple ITL property

A request from the highest priority master (master 0)
is granted on the next cycle, if the arbiter is ready
to serve a request
t
state_s
IDLE
request_i
--1
grant_o
confidential
t+1
001
property grant_master_0 is
assume:
at t: state_s = IDLE;
at t: request_i(0) = '1';
prove:
at t+1: grant_o = "001";
end property;
July 2007/Page 97
Reading the Property
Property
not proven yet
mv> read_itl arbiter_master0.vli
confidential
July 2007/Page 98
Checking the Property
The property fails
mv> check_property grant_master_0
confidential
July 2007/Page 99
Debugging
Failing commitment
is colored red
Reset is active
mv> debug_property
confidential
July 2007/Page 100
Debugging (cont.)
When reset is active

grant_o is forced to zero
confidential
July 2007/Page 101
The definition can go into a

different file
Excluding reset
constr_no_reset.vhi
Define a constraint which

excludes the reset
constraint no_reset :=
reset = 0;
end constraint;
arbiter_master0.vhi
Use include to link

the 2 files
include constr_no_reset.vhi;
dependencies:
no_reset;
assume:
prove:
at t+1: grant_o = "001";
end property;
confidential
The property depends

on the constraint
July 2007/Page 102
Checking the Modified Property

The definition of
grant_master_0 has
changed;
the old proof status is
no longer valid
confidential
July 2007/Page 103
Validity Management: ITL-files

OneSpin keeps track on itl-file changes
modified properties are marked as invalid
check_property always reads the itl-file
explicit re-reading by
mv> read_itl ;# no options/parameters
to show all itl-files currently used
mv> get_itl_files
to exclude an itl-file
mv> release_itl <itl-file>
confidential
July 2007/Page 104
Checking the Modified Property (cont.)
The property still fails!
confidential
July 2007/Page 105
Debugging (again)
Two masters are granted

at the same time!
confidential
July 2007/Page 106
Debugging (cont.)
prio_s is assigned in
the process priority
When in IDLE,
grant_o takes the
value of prio_s
confidential
July 2007/Page 107
Formal Verification vs. Simulation
assume:
prove:
at t+1: grant_o = "001";
end property;
request_i = 001
request_i = 011
request_i = 101
request_i = 111
Simulation:
- every bit of request_i must be given a value
- not every one of the 4 request_i values hits the bug
assume:
at t: request_i = 101;
prove:
at t+1: grant_o = "001";
end property;
confidential
Holds!
July 2007/Page 108
Formal Verification vs. Simulation (cont.)

t
state_s
request_i
t+1
IDLE
One Pattern
--1
grant_o
001
Many Test Cases
reset
request_i
001
101
111
011
free_i
confidential
state_s
idle start
busy
idle start
busy
idle start
busy
grant_o
000 001
000
001
000
111
000
idle
July 2007/Page 109
Fixing the bug

priority: process(request_i)
variable index_v: natural range 0 to nr_masters-1;
begin
prio_s <= (others => '0');
for index_v in 0 to nr_masters-1 loop
if request_i(index_v) = '1' then
prio_s(index_v) <= '1';
else
else is wrong;
exit;
the loop must stop as
end if;
soon as a request is
end loop;
found
end process priority;
confidential
July 2007/Page 110
Checking the Fixed Design
property is
unproven
mv> set_mode setup

setup> elaborate reread_hdl
setup> set_mode mv
default clock found
default reset found
confidential
July 2007/Page 111
Validity Management: Model

OneSpin keeps track on HDL changes
change of HDL-file makes all properties
model_changed
verification can be continued but results are not valid for
current HDL
re-elaboration/re-compilation makes all properties

outdated
change of read_hdl, elaborate option
change of clocking
confidential
July 2007/Page 112
The Property Holds!
confidential
July 2007/Page 113
Summary
How to write a simple property in ITL

assume, prove, dependencies, at, constraint
How to check and debug properties

Formal Verification vs. Simulation
confidential
July 2007/Page 114
Used Syntax
Comments
/*
This is a block comment.
*/
assume:
-- This is a line comment
prove:
at t+1: grant_o = 001;
end property;
VHI files can be structured by comments.

A block comment starts with /* and ends with */ .
A line comment starts with -- just like in VHDL .
confidential
July 2007/Page 116
Signal Names in Properties
All top level signal names are usable:

inputs, outputs, and internal signals of the top level
module/architecture:
request_i grant_o state_s
Signals of lower level components are usable :

a_i1:a
ctrl_i:ctrl
a_i1/ctrl_i/state_s
state_s
Ports of instances are usable
confidential
July 2007/Page 117
Types of Signals
same as in VHDL
except:
confidential
std_[u]logic_vector unsigned
bit_vector
unsigned
array of bit
unsigned
integer, range
unsigned or signed
natural, positive
unsigned
July 2007/Page 118
Literals
Bit, std_logic and std_ulogic:
'0'
'1'
Bitvector, std_logic_vector and std_ulogic_vector:

"10101111"
O"257"
X"AF"
internally: unsigned
Number:
175
internally: signed (negative) or unsigned
Boolean literals:
false
true
Literal of user-defined enumeration type:

IDLE
confidential
colorRED
typemarking if
type is not unique
July 2007/Page 119
Structural Operations
Concatenation:
"1010" & "1111" = "10101111"
Indexing on arrays:
request_i(0)
memory_s(2,1)
Bit-Slicing: type is kept

"011"(1 downto 0) = 11
confidential
July 2007/Page 120
Shift arithmetically:
shift_left("10101111",3) = "01111000"
shift_right("10101111",3) = "00010101"
Rotating:
rotate_left("101",2) = "110"
rotate_right("10",1) = "01"
confidential
July 2007/Page 121
constraints
used to describe behavior of the environment
assumed to hold in each cycle starting after reset
implicitely assumed over the whole examination window
definition
constraint <name> :=
<boolean-expression>;
end constraint;
property that assumes a constraint
property Example is
dependencies:
<name-of-constraint>;
assume:
confidential
July 2007/Page 122

Developing an Operation Property
Constraining the Environment
Dealing with Variable Time Intervals
Contradictory Assumptions
Reachable and Unreachable States
confidential
July 2007/Page 124
An Operation Property
A request from the highest priority master (master 0)
is granted on the next cycle, if the arbiter is ready
to serve a request;
the arbiter then waits until the resource is free and
returns to a state where it is ready to serve a
request.
Full description of the operation:
serving a request from the master 0
waits until the resource is free

Environment:
after grant, the resource is busy for 2 cycles and freed on
the third cycle
confidential
July 2007/Page 125
Operation Property in ITL

A request from the highest priority master (master 0) is granted on the
next cycle, if the arbiter is ready to serve a request;
the arbiter then waits until the resource is free and returns to a state
where it is ready to serve a request.
t
request_i
--1
state_s
idle
grant_o
t+1
t+4
idle
001
free_i
after grant, the resource is busy for 2

cycles and freed on the third cycle
confidential
dependencies:
no_reset;
assume:
prove:
at t+1: grant_o = "001";
at t+4: state_s = IDLE;
end property;
July 2007/Page 126

t
request_i
--1
state_s
idle
grant_o
t_grant
t_grant+3
idle
001
free_i

confidential
dependencies:
no_reset;
assume:
prove:
at t+1: grant_o = "001";
end property;
July 2007/Page 127

t
request_i
--1
state_s
idle
grant_o
t_grant
idle
001
free_i

confidential
dependencies:
no_reset;
t_free_i
assume:
prove:
at t+1: grant_o = "001";
end property;
July 2007/Page 128
t
request_i
--1
state_s
idle
grant_o

Use time variables
to name meaningful
t_grant
t_free_i
dependencies:timepoints
idle
001
free_i

confidential
no_reset;
for timepoints:
t_grant = t+1,
t_free_i = t_grant+3;
assume:
prove:
at t_grant: grant_o = "001";
at t_free_i: state_s = IDLE;
end property;
July 2007/Page 129
Checking and Debugging

at free_i is set 2 cycles after
grant, instead of 3
at t_free_i state_s is not IDLE
confidential
July 2007/Page 130
Adding the Environment Constraint

constr_grant_free_after_3.vhi
constraint grant_free_after_3 :=
if grant_o /= 0 then
next(free_i) = '0' and
next(free_i,2) = '0' and
next(free_i,3) = '1'
end if;
end constraint;
confidential
arbiter_master0.vhi
include constr_grant_free_after_3.vhi
dependencies:
no_reset,
grant_free_after_3;
for timepoints:
t_grant = t+1,
t_free_i = t_grant + 3;
assume:
prove:
at t_free_i+1: state_s = IDLE;
end property;
July 2007/Page 131
The Property Holds!
confidential
July 2007/Page 132
A Different Environment
The resource is freed within 3 cycles from grant
arbiter_master0.vhi
constr_grant_free.vhi
constraint grant_free :=
if grant_o /= 0 then
next(free_i) = 1' or
next(free_i,2) = 1' or
next(free_i,3) = '1'
end if;
end constraint;
confidential
include constr_grant_free.vhi
dependencies:
no_reset,
grant_free;
for timepoints:
t_grant = t+1,
t_free_i = t_grant + 1..3;
assume:
prove:
end property;
July 2007/Page 133
Checking and Debugging
no connection!
confidential
July 2007/Page 134
Defining the t_free_i

arbiter_master0.vhi
dependencies:
no_reset,
grant_free;
for timepoints:
t_grant = t+1,
assume:
during [t_grant+1, t_free_i - 1]: free_i = '0';
at t_free_i: free_i = '1';
prove:
end property;
confidential
July 2007/Page 135
The Property Holds!

Warning if a time variable with
interval value is not restricted
confidential
July 2007/Page 136
Contradictory Assumptions
arbiter_master0.vhi
dependencies:
no_reset,
typo:
grant_free;
for timepoints:
t_free_i
t_grant = t+1,
Instead of
t_free_i 1
assume:
during [t_grant+1, t_free_i]: free_i = '0';
at t_free_i:
prove:
free_i = 0 and free_i = 1
Contradiction!!!
end property;
confidential
July 2007/Page 137
Contradictory Assumptions (cont.)
Do not accept hold empty!
confidential
July 2007/Page 138
Contradictory Assumptions:
why does the property holds
Commitment 1
Assumption 1
Assumption 2
Commitment 2
Commitment 3
Assumption 3
not relevant!
&
&
1
0
constant 1
hold
constant 0
Assumptions enable the commitments to be checked.

If the assumptions disable, there is nothing to check.
confidential
July 2007/Page 139
Debugging of Contradictory Assumptions

Tool support is currently under development
In the meanwhile:
Comment one assumption at the time until the
contradiction disappears
Analyse the offending assumption
Contradicts another assumption
Contradicts the design
confidential
July 2007/Page 140
The Arbiters State Space

Reachable and Unreachable states
state_s
idle
000
001
010
grant_o
011
100
101
110
111
confidential
start
busy
State Space:
state_s x grant_o
Reachable states:
Reset state
States reached from the
reset state
Etc.
Unreachable states:
All the other states
July 2007/Page 141
Start State of grant_master_0

arbiter_master0.vhi
state_s
dependencies:
no_reset,
No assumptions
grant_free;
on grant_o
for timepoints:
t_grant = t+1,
assume:
during [t_grant+1, t_free_i-1]: free_i = '0';
prove:
end property;
confidential
grant_o
idle
start
busy
000
001
010
011
100
101
110
111
Holds from unreachable

states!
July 2007/Page 142
Properties Starting from Any State

Pros & Cons
Pros:
If the property holds on any state, it also holds on the
reachable states
No need to find all the reachable state set
Can only be done on small designs
No need to limit the verification to a certain number of

cycles from reset
Bounded model checking - not a true proof
Cons:
False negatives: the property fails from an unreachable
state
Not a true failure
Soon learn how to deal with false negatives
confidential
July 2007/Page 143
Summary
An operation property describes a full operation
From accepting a request to being ready for the next
Use time variables over an interval to describe

variable time intervals
Define the time variable in the assume part
Do not accept contradictory assumptions

Properties are proven from any state
Not just reachable states
confidential
July 2007/Page 144
Used Syntax
Logical Operations
Bit-wise operations:
not
and
or
xor
nand
nor
xnor
Reduction operations on vectors:

and_reduce
nand_reduce
or_reduce
nor_reduce
xor_reduce
xnor_reduce
e.g.
and_reduce("1111111")
confidential
= '1'
July 2007/Page 146
Conditional Expressions
Complete if expression
a ?
b = 3 :
b = 5
if a then
b = 3
else
b = 5
end if
b = if a then
3
else
5
end if
Incomplete boolean if expression

if a then
b = 3
end if
if a then
b = 3
else
true
end if
Note difference to VHDL: no assignment in VHI !!!
confidential
July 2007/Page 147
Conditional Expressions
Cascaded if statements:
if a1 then
b = 3
elsif a2 then
b = 5
else
b = 0
end if
if a1 then
b = 3
else if a2 then
b = 5
else
b = 0
end if
end if
case statement:
case c is
when 2
=> d = 6;
when 3
=> d = 9;
when others => d = 0
end case;
confidential
if
(c = 2) then d = 6
elsif (c = 3) then d = 9
else
d = 0
end if;
July 2007/Page 148
prev and next Operators

For each signal or expression, the previous and next
values can be referenced.
confidential
property Example is
prove:
at t+1: cnt = prev(cnt) + 1;
end property;
stands for:
previous value of cnt
i.e. at t
property Example is
prove:
at t: next(cnt) = cnt + 1;
end property;
stands for:
next value of cnt
i.e. at t+1
property Example is
prove:
at t: next(cnt, 2) = cnt + 2;
end property;
stands for:
next but one value
of cnt i.e. at t+2
July 2007/Page 149
within
<TimedStateExpr> ::= within <TimeRange>:<StateExpr>
<TimeRange> ::= [<TimeExpr>,<TimeExpr>]
If the time interval <TimeRange> is non-empty,

the combinational logic block is the disjunction of sub blocks
one for each time point of the time interval .
determined by a state expression <StateExpr>.
inputs, states, etc. to a sub block are read at the according

time point of the time interval.
If the time interval is empty, this is equivalent to false .

<StateExpr> should be
property Example is
true at t+3 or at t+4
prove:
within [t+3,t+4]: <StateExpr>;
end property;
Confidential
CVE Property Checking

I-5/24
either .. or
At least one, possibly several alternatives hold:
<TimedStateExpr> ::= either <TimedStateExpr>
{or <TimedStateExpr>}+
end either;
Operator within is restricted:

property Example is
prove:
within [t+3,t+5]: <StateExpr>;
end property;
<StateExpr> should
hold at t+3,
or at t+4,
or at t+5
Construct either .. or is more general:

property Example is
prove:
either
at t+3: <StateExpr1>;
or
at t+5: <StateExpr2>;
end either;
end property;
Confidential
<StateExpr1> should
hold at t+3 or
<StateExpr2> at t+5

I-9/13
rose, fell, changed

Derived operators:
rose(expr)
::= not(prev(expr)) and expr
fell(expr)
::= prev(expr) and not(expr)
changed(expr) ::= expr /= prev(expr)
Confidential

I-8/13
Abbreviating Time Points

Defines a time
variable
property Example is
for timepoints:
Denotes a
t_grant = t+1;
time point
prove:
at t_grant: ack_o = '1';
end property;
Uses the time variable
Defines a time variable, which is equivalent to the

denoted time point wherever it occurs in the
property.
A time variable may serve as a symbolic name
to enhance the readability of a property.
confidential
July 2007/Page 150
Cascaded Time Variables

for timepoints:
t_grant = t+1,
t_free_i = t_grant +3;
assume:
...
prove:
at t_grant: grant_o = 001;
end property;
There may be a list of time variable definitions.

A definition of a time variable uses exactly one
other time variable.
confidential
July 2007/Page 151
Time Variable over Intervals

property Example is
Stands for:
for timepoints:
in [t+3,t+4]
t_free_i = t+3..4;
prove:
at t_free_i: state_s = IDLE;
end property;
A time variable may range over an interval.

A time variable keeps its value.
The property is checked for all possible values of
the time variable.
property Example is
property Example is
prove:
prove:
end property;
end property;
confidential
July 2007/Page 152
Several Time Variables over Intervals

Conceptually, every different
combination of all possible
time points of all time
variables leads to a different
property to be checked.
t1=t+1
property Example is
for timepoints:
t1 = t+1..2,
t2 = t1+2..3;
prove:
<TimedStateExprList>
end property;
t1=t+2
t1=t+1
t2=t1+2
t2=t+3
t1=t+2
t2=t1+3
t2=t+4
t2=t1+2
t2=t+4
t2=t1+3
t2=t+5
(t1,t2)={(t+1,t+3),(t+1,t+4),(t+2,t+4),(t+2,t+5)}
confidential
July 2007/Page 153
for
property Example is
for:
<Identifier> = M..N;
prove:
end property;
Introduces a new constant named <Identifier> .

Implicitly expands a property to a set of properties, with
one property for each constant integer value from M to N.
Range must be given in terms of constants.
All properties of this set must hold!
Confidential

I-9/3
Application of for
State variables generated by for serve to
parameterize properties with a generic array index
and check the property for all possible values of that
array index independently.
property Example is
for:
Index = 3..4;
prove:
at t: DO_o(Index) = 0;
end property;
Confidential
property Example_3 is
prove:
at t: DO_o(3) = 0;
end property;
property Example_4 is
prove:
at t: DO_o(4) = 0;
end property;
I-9/4
More on for
property Example is
for:
<Identifier> = M..N,
<Identifier> = O..P,
<Identifier> = Q..R;
freeze:
<Identifier> = <Expr> @ <TimeExpr>;
prove:
end property;
You can have a list of for variables, separated by commas.

The for part is positioned directly before freeze part.
Confidential

I-9/5
More on for
property Example is
-- for: i = 0..5, j = i..5; -- forbidden!
for: i = 0..5, j = 0..5;
freeze:
dji = j - i@t;
assume: at t: j >= i; -- relation between i and j
prove:
at t: mem(i,j) =
if
i < j then dji
else
i
end if;
end property;
Restrict for variable with assumption, not in definition.

The for variables may be used in freeze expressions.
For inspecting intermediate results use freeze variables.
Confidential

I-9/6

Writing more general properties
Freeze variables
Macros
Generating a witness
confidential
July 2007/Page 155
An Operation Property for All Masters

If the arbiter is ready to serve a request and there is a request,
the request with the highest priority is served on the next cycle;
the arbiter then waits until the resource is free and returns to a
state where it is ready to serve a request.
Full description of the operation:

serving a request from any master
waits until the resource is free

Environment:
The resource is freed within 3 cycles from grant
confidential
July 2007/Page 156
A Property for All the Masters (cont.)

arbiter_master0.vhi
arbiter_all_masters.vhi
macro
grant_to_highest_prio (request:bit_vector):
bit_vector :=
if
request(0) = 1
then "001"
elsif request(1) = 1 then "010"
elsif request(2) = 1 then "100"
else
"000"
end if;
end macro;
property grant_master
grant_master_0
is is
dependencies:
no_reset, grant_free;
for timepoints:
t_grant = t+1,
freeze:
req = request_i @ t;
assume:
request_i(0)
= '1';
at t: request_i
/= 0;
-- some request
during [t_grant+1, t_free_i-1]:
t_free_i]: free_i
==
'0';'0';
free_i
prove:
"001"; priority request>
at t_grant: grant_o = grant_to_highest_prio(req);
<highest
end property;
confidential
July 2007/Page 157
The Property Holds!
confidential
July 2007/Page 158
Generating a Witness
arbiter_all_masters.vhi
No counter-examples for
holding properties
Witness
property grant_master is
dependencies:
no_reset, grant_free;
a trace on which the
for timepoints:
t_grant = t+1,
property holds
Force the property to fail
freeze:
req = request_i @ t;
assume:
at t: request_i /= 0; -- some request
during [t_grant+1, t_free_i-1]: free_i = '0';
prove:
false;
at t_grant: grant_o = grant_to_highest_prio(req);
end property;
confidential
July 2007/Page 159
Generating a Witness (cont.)
prove: false;
To generate an example
on which the property
holds a witness
confidential
July 2007/Page 160
Expanding Macros
confidential
July 2007/Page 161
Summary
How to write a property for all master
From a specific property (request from master 0) to a
generic property (requests from any master)
freeze, macros
How to generate a witness

A trace for a holding property
How to examine macros in the debugging

environment
confidential
July 2007/Page 162
Used Syntax
freeze
property Example is
freeze:
<Identifier> = <Expr> @ <TimeExpr>;
prove:
end property;
Introduces a new signal named <Identifier>.

The value of the signal is the same for all time
points.
The value of the signal is defined by the value of
expression <Expr> at time point <TimeExpr>.
Signals generated by freeze serve to compare
values of variables and expressions at different
time points.
confidential
July 2007/Page 164
Application: freeze vs. prev/next

relative reference: prev/next
property Relative is
prove:
during [t+1, t+3]:
out = prev(sig);
end property;
sig
out
t
t+1 t+2 t+3
t+1 t+2 t+3
absolute reference: freeze

property Absolute is
freeze: sig_0 = sig @ t;
prove:
during [t+1, t+3]:
out = sig_0;
end property;
confidential
sig
out
July 2007/Page 165
Macro Syntax (VHI)

Prepare re-use of assumptions by way of macros.
macro name
macro return type
macro Request : boolean is

request_i = '1';
end macro;
property Example is
macro call
assume:
at t: Request;
prove:
end property;
confidential
July 2007/Page 166
Macro Parameter of HDL Types (VHI)

Generalize macros by parameter of HDL types.
formal parameter
of a HDL type
macro Request (ActiveLevel: std_ulogic) : boolean is
request_i = ActiveLevel;
end macro;
actual parameter
property Example is
of a HDL type
assume:
at t+1: Request('1');
prove:
end property;
Note: signals are usable
within a macro without need
of parameter usage.
confidential
July 2007/Page 167
Different Macro Types
property Example is
dependencies:
no_reset, gnt_req;
assume:
at t+1: if (a < b) then
b-a
else
time points
a-b
end if;
prove:
at t+2: rdy_o = '1';
end property;
confidential
properties
dependencies
Expressions
temporals
July 2007/Page 168
State Expression Macros: Constant

Improve readability and modifiability by macros.
HDL type of the state expression
macro
ActiveLevel: std_ulogic is
'1';
end macro;
property Example is
state expression macro call
assume:
at t+1: Request(ActiveLevel );
prove:
at t+2: rdy_o = ActiveLevel;
end property;
state expression macro call
Confidential

I-10/5
Constant Return Type

For bit-slicing, specify const return type.
macro
c2: const range is 2;
end macro;
prefix key word const
property Example is
...
prove:
at t+2:
reg(c2 downto c2 - 1) = 0;
end property;
macro accepted as constant
Confidential

I-10/6
State Expression Macros: Function

Functional macros return HDL-typed value
macro
max_prio(i,j: range): unsigned is
if prio(i) > prio(j) then prio(i)
else prio(j)
end if;
end macro;
property example is
assume:
at t: prio(0) = max_prio(0,1);
prove:
at t+1: arb_win = 0;
end property;
Confidential

I-10/7
State Expression Macros: Relation

Relational macros return true or false
macro
gt_prio(i,j: range): boolean is
prio(i) > prio(j) or
(prio(i) = prio(j) and i <= j);
end macro;
property example is
assume:
at t: gt_prio(1,0);
prove:
at t+1: arb_win = 1 and
prio(1) > prio(0);
end property;
Confidential

I-10/8
Example: 1-Hot Macro

macro
one_hot(vec:unsigned;l,i:range): boolean is
if vec(i) = '1' then
-- vec((l-1)downto(i+1)
shift_right(vec,i+1)
&
-- vec((i-1)downto(0)
shift_left(vec,unsigned(l-i))
= 0
end if;
end macro;
property at_most_one_grant_p is
for: i = 0..nr_masters-1;
prove:
at t+1: one_hot(grant_o,nr_masters,i);
end property;
Much easier with advanced features (cf. II.1: recursive macros)
Confidential

I-10/9
Example: Temporal Operators

Using prev/next, macros can implicitly refer to
different time-points:
macro stable(X:std_ulogic): boolean is
X = prev(X);
end macro;
macro rose(X:std_ulogic): boolean is
prev(X) = '0' and X = '1';
end macro;
property Example is
assume:
during [t, t+7]:
stable(input1) and stable(input2);
at t+3: rose(clk);
prove: ...
end property;
Confidential
I-10/10
Timed State Expression Macro

Special type assertion:
macro
Request: temporal is
at t : req_i = '0';
at t+1: req_i = '1';
end macro;
macro type for list of

timed state expressions
property Example is
assume:
macro call
Request;
prove:
at t+2: rdy_o = '1';
end property;
Confidential

I-10/11
Inclusion of Macros
Several macros sections in a file allowed.
include
VHI
macro
files
define
macros
before
usage
a VHI file
Confidential
include "Basics.vhi";
include "Params.vhi";
macro
m1: ...
end macro;
property p1 is
... m1 ...
end property;
macro
m2: ...
end macro;
property p2 is
... m2 ...
end property;
VHI macro file named

"Basics.vhi"
include ...;
macro
<Macro>
end macro;
...
Defining re-usable
macros
I-10/12
Arithmetic and Comparison

Sign:
+A_s
-A_s
Binary operations:
A_s + B_s
A_s - B_s
A_s * B_s
A_s div B_s
A_s rem B_s
A_s mod B_s
Comparison:
confidential
A_s = B_s
A_s /= B_s
A_s > B_s
A_s >= B_s
A_s < B_s
A_s <= B_s
July 2007/Page 169
Resizing, removing or filling with '0'/sign at left end:
RESIZE("011",2) = "11"
RESIZE("11",3) = "011"
RESIZE(signed"101",2) = signed"11"
RESIZE(signed"010",2) = signed"00"
RESIZE(signed"10",3)
= signed"110"
Bit-Slicing: type is kept, sign is new MSB if signed

"011"(1 downto 0) = 3
signed"101"(1 downto 0) = 1
signed"011"(1 downto 0) = -1
signed"011"(2 downto 1) = 1
Confidential

I-6/12
Example: Signs & Lengths

property Example is
prove:
at
at
at
at
at
at
t:
t:
t:
t:
t:
t:
"111" / = "000" - 1;
-- "1111"
"111" / = resize("000" - 1,3);
-- "111"
"111" / = unsigned("000" - 1);
-- "1111"
signed"111" = "000" - 1;
-- "1111"
"110" / = ("111" - 1)(2 downto 0);
/
-- "0110
"
"110" = unsigned(("111" - 1)(2 downto 0));
at t: resize("111" - 1,3) / = ("111" - 1)(2 downto 0);

end property;
Result of addition/subtraction has carry bit.

Result of subtraction is signed.
Equality uses numerical interpretation.
Resized or bit-sliced (un-)signed is (un-)signed.
Resize preserves sign, bit slicing doesnt.
Confidential
I-6/13
Specifics of Operations
The results internal representation of any
operation will be large enough to avoid any
over- or underflow.
- Arguments internal representation may be
resized.
The result is to be understood arithmetically,
wherever possible.
- Resizing is done arithmetically: Sign is
preserved.
Mixed argument types are allowed, wherever
possible.
confidential
July 2007/Page 170
Exercise: Alu
ASL
ASR
LSR
ADD
SUB
MULS
MULU
IDLE
in1_i
in0_i
cmd_i
flags_o
4
flags_o.carry
flags_o.ovfl
flags_o.neg
flags_o.zero
out1_o out0_o
As preparation
analyze alu_pack.vhd, alu.vhd into library work .
note that entity alu describes a combinational circuit .
(set_clocking)
Confidential

I-6/19
Arithmetic Shift Left

Assume that the command is ASL.
Prove that out0_o is the result of shifting in0_i left
by one bit and replacing its LSB by '0' .
Prove that flags_o.carry is the MSB of in0_i .
Prove that flags_o.ovfl is '1' if and only if MSB
of in0_i differs from the MSB of out0_o .
Put everything into one property .
Hint: function shift_left of VHI does an
arithmetic shift-left .
Verify other commands in the same style !
Confidential

I-6/20
Solutions
Confidential
I-6/21
Idle Operation and Shift Left

property idle is
assume:
at t: cmd_i = IDLE;
prove:
at t: out1_o & out0_o = in1_i & in0_i;
at t: flags_o.carry = '0';
at t: flags_o.ovfl = '0';
end property;
property asl is
assume:
at t: cmd_i = ASL;
prove:
at t: out0_o
at t: out1_o
at t: flags_o.carry
at t: flags_o.ovfl
end property;
Confidential
=
=
=
=
shift_left(in0_i,1);
0;
in0_i(3);
(in0_i(3) xor out0_o(3));
I-6/22
Error Handling in ATM Cells

probability
trunk errors
an ATM cell
routing errors
packet size
# of bit errors
Header CRC Data
Error correction code CRC for Header

CRC enables correction of one-bit errors
CRC enables detection of multi-bit errors
Confidential

I-5/29
ATM Error Controller

error_i
11/01
10/10
*)
0-/00
state
correct_o
1
11/01
10/01
0-/00
multiple_i
*)
error_i multiple_i/ correct_o dismiss_o
dismiss_o
1 A cell is never corrected and dismissed at the same time.

2 An error free cell is neither corrected nor dismissed.
3 The first cell with single bit error is corrected.
4 A cell with single bit error following a flawed cell is dismissed.
5 All cells with multiple bit errors are dismissed.
Confidential

I-5/30
Solutions
Confidential
I-5/31
Solution for Exercise 1

property t1 is
prove:
at t: correct_o = '0' or
dismiss_o = '0';
end property;
11/01
10/10
0-/00
11/ 01
10/ 01
0-/ 00
Confidential

I-5/32
Solution for Exercise 1 - variants

property t1 is
prove:
at t: correct_o = '0' or dismiss_o = '0';
end property;
property t1a is
prove:
at t: (correct_o and dismiss_o) = '0';
end property;
property t1b is
prove:
at t: (correct_o = '1' and dismiss_o = '1') = false;
end property;
property t1c is
prove:
at t: not(correct_o = '1' and dismiss_o = '1');
end property;
Confidential

I-5/33

property t2 is
assume:
at t: error_i = '0';
prove:
at t: correct_o = '0';
at t: dismiss_o = '0';
end property;
11/01
10/10
0-/00
11/01
10/01
0-/00
Confidential

I-5/34

property t3 is
assume:
at t : error_i = '0';
at t+1: error_i = '1';
at t+1: multiple_i = '0';
prove:
at t+1: correct_o = '1';
end property;
11/01
10/10
0-/00
11/01
10/01
0-/00
Confidential

I-5/35

property t4 is
assume:
during [t,t+1]:
error_i = '1';
at t+1:
multiple_i = '0';
prove:
at t+1: dismiss_o = '1';
end property;
11/01
10/10
0-/00
11/01
10/01
0-/00
Confidential

I-5/36

property t5 is
assume:
at t: error_i = '1';
at t: multiple_i = '1';
prove:
at t: dismiss_o = '1';
end property;
11/01
10/10
0-/00
11/01
10/01
0-/00
Confidential

I-5/37
OneSpin Solutions
Training Module Verification
Part III Assertions and Constraints
July 2007
OneSpin Solutions GmbH
Theresienhoehe 12
80339 Munich Germany
support@onespin-solutions.com
Content
Module 1: Unreachable states and Assertions

Module 2: Proving Assertions
Module 3: False assertions and constraints
confidential
OneSpin Solutions/Page 387
Module 1: Unreachable states and Assertions
Dealing with failures due to unreachable states

Assertions
confidential
The Arbiters State Space

Reachable and Unreachable states
grant_o <= 0
state_s
idle
start
busy
IDLE
grant_o <= prio_s
START
000
001
010
grant_o
011
100
101
110
grant_o <= 0
grant_o <= 0
BUSY
grant_o <= 0
111
reachable
unreachable
confidential
State Space:
state_s x grant_o
Start State of grant_master_0

arbiter_master0.vhi
state_s
dependencies:
no_reset,
No assumptions
grant_free;
on grant_o
for timepoints:
t_grant = t+1,
assume:
during [t_grant+1, t_free_i]: free_i = '0';
prove:
end property;
confidential
grant_o
idle
start
busy
000
001
010
011
100
101
110
111
Holds from unreachable

states!
Properties Starting from Any State

Pros & Cons
Pros:
If the property holds on any state, it also holds on the
reachable states
No need to find all the reachable state set
Can only be done on small designs
No need to limit the verification to a certain number of

cycles from reset
Bounded model checking - not a true proof
Cons:
False negatives: the property fails from an unreachable
state
Not a true failure
Learn how to deal with false negatives

confidential
Example False Negative

grant_o <= 0
IDLE
grant_o <= prio_s
grant_o <= 0
grant_o <= 0
BUSY
grant_o <= 0
confidential
START
If the arbiter is ready

to serve a request
and there is no request,
then on the next cycle,
grant_o is zero.
property idle is
assume:
at t: state_s = idle;
prove:
end property;
Example False Negative (cont.)
Unreachable
start state
confidential
Filtering the Unreachable States
Temporarily exclude the

unreachable states that
make the property fails.
Check if the property holds
confidential
A More Generic Assumption

arbiter_idle.vhi
property idle is
assume:
-- tmp
during [t_first, t_last]:
if (state_s = idle) then
grant_o = 0
end if;
prove:
end property;
confidential
if (state_s = idle) then grant_o = 0

is true for all reachable states,
therefore is always true
Such conditions are called

invariants
Assertions
arbiter_idle.vhi
assertion idle_grant :=
grant_o = 0
end if;
end assertion;
property idle is
dependencies:
idle_grant;
assume:
prove:
end property;
confidential
An invariant can be expressed as

an ITL assertion
The property idle depends

on the assertion idle_grant
Dependencies
idle depends on an
unproven assertion
confidential
Dependencies Management
mv> report_result
confidential
One unresolved
dependency
Syntax - Assertions
assumed to hold in each cycle starting after reset
implicitely assumed over the whole examination window
definition
assertion <name> :=
<boolean-expression>;
end assertion;
property that assumes an assertion
property Example is
dependencies:
<name-of-assertion>,
<name-of-constraint>,
;
assume:
confidential
Constraints vs. Assertions

Both assumed as dependencies
Assertions express provable facts on the design
Must be proven to resolve the dependency
Constraints express environment conditions

Not to be proven on the design under verification
Assertions on the rest of the design
Proven in a different verification project
Monitored during simulation
confidential
Summary
Dealing with false negatives due to unreachable
start state
Describe the set of legal start states with an assertion
Set a dependency between the property and the
assertion
360 MV manages the dependencies between the

properties and the assertions
confidential
Module 2: Proving Assertions

How to prove assertions
Proof by induction
check_assertion
confidential
Proving Assertions
360 MV command to check assertions:
check_assertion
check_assertion automates a proof technique

called proof by induction
confidential
Mathematical Induction
A technique to prove statements about the natural
numbers
Example
n
2i = 2n+1 - 1
i=0
base case
induction step
prove for n = 0
assume the statement true for n-1 and

prove it for n
20 = 1
2(0+1) - 1 = 2 - 1 = 1
n-1
2 = 2i + 2n =
i=0
i=0
= 2n 1 + 2n = 2n+1 - 1
confidential
Induction in Formal Verification

Sequence of Sets of States
State at t=0,
just after reset
t=0
States at t= 1,
states that
can be reached
from the reset
state
t=1
States at t= n,
states that
can be reached
from the states
at t = n-1
t=n
To prove that a condition is true for all the states in the sequence
(all the reachable states)
- prove at t=0 (base case)
- assume at t, prove at t+1 (induction step)
confidential
Understanding How check_assertion Works

Manual proof by induction of idle_grant
done automatically by check_assertion
Base case: prove at t=0, just after reset

if (state_s = idle) then grant_o = 0 end if;
end assertion;
Automatically found when
changing to mv mode
property idle_grant_base is
or
assume:
defined by the user using
reset_sequence;
set_reset_sequence
prove:
at t: idle_grant;
end property;
The cycle on which the
reset is active is t-1
confidential
Checking the Base Property
mv> get_reset_sequence
confidential
Checking the Induction Step Property
The state at t
is not reachable:
false negative
The property fails!
confidential
Why Does the Induction Step fails?

state_s
grant_o
000
idle
start
busy
grant_o = 0
end if;
end assertion;
001
010
011
100
101
Set of states described by

the assertion,
some reachable,
some unreachable
110
111
The start state in the

counter-example is
unreachable
confidential
Why Does the Induction Step fails?

state_s
grant_o
idle
start
busy
000
001
010
011
Set of states described by

the assertion,
some reachable,
some unreachable
100
101
110
Start state in the

counter-example
111
It is possible to leave
the set of states
described by the
assertion
confidential
This assertion cannot be proven by induction

The assertion must be refined
by excluding the states that cause the failure
A Stronger Assertion
state_s
grant_o
if (state_s = idle) then grant_o = 0 end if
and
if (state_s = busy) then grant_o = 0 end if;
end assertion;
idle
start
busy
000
001
010
011
100
101
110
111
The remaining unreachable

states have a next state which
is within the set of states
described by the assertion
confidential
Re-checking Base and Step Properties
confidential
Assertions vs. Reachable State Space
idle_grant states
all states
reachable states
All the states that satisfy an invariant that

can be proven by induction have a next
state that satisfy the invariant
Calculating the exact set of reachable states is typically
not possible on non-trivial designs
Instead
Find and prove the invariants needed to prove the properties
confidential
check_assertion
automatic proof by induction
First version of
the assertion
mv> check_assertion idle_grant
confidential
debug_assertion
step
property
mv> debug_assertion
confidential
The state at t
is not reachable:
false negative
Refining the Assertion
The assertion has changed

All the previous results are invalid,
including the status of property idle
confidential
Making the assertion

stronger
Re-checking the Assertion and the Property
Both assertion and property hold!
confidential
No Unresolved Dependencies
mv> report_result
confidential
No unresolved
dependency
Proof by induction - summary

If both base and step hold, the assertion holds
If the base case fails, the assertion fails
The assertion fails on a reachable state
If the induction step fails, the assertion can still

hold
Make the assertion stronger
confidential
Summary
Proof by induction
Check_assertion automates the induction
technique
How to debug assertions
How to strengthen assertions in order to prove
them
confidential
Module 3: False assertions and constraints

Dealing with false assertions
Assertion which depends on the environment
Short-term redundancies
confidential
Dealing with False Assertions
An assertion can be false (does not hold on the design)

Because there is a bug in the design
Because the assertion is wrong
Example wrong assertion

assertion no_grant_idle :=
if grant_o = 0 then state_s = idle end if;
end assertion;
confidential
check_assertion no_grant_idle
Before investigating the failure

of the step case
confidential
Does the Assertion Fail from Reset?

If the assertion fails from reset,
we have a true failure
Check a longer base case
check_assertion force base length <n> <assertion_name>
confidential
Checking a Longer Base Case
mv> check_assertion force base length 4 no_grant_idle
confidential
Debugging the Assertion

Found a reachable state in which
grant_o is zero and state_s is not idle;
the assertion is not true for the design
The reset sequence
ends at t-1
Extended
base property
mv> debug_assertion base
confidential
Debugging the Assertion (cont.)
Expand during
In this example the assertion is wrong.
In a different situation this could have been
a bug in the design!
Expand the assertion
confidential
But not all failures from reset are errors

Assertion: maximum 3 consecutive cycles
in the state BUSY
The step case

fails
mv> check_assertion force base length 3 max_3_busy_cycles
The extended base

case fails too
confidential
Debugging the Assertion
free_i is always zero,

environment violation
confidential
an environment constraint might be needed
The step case

still unproven
Add the
environment
constraint
mv> check_assertion force base length 100 max_3_busy_cycles

The extended
base case holds
confidential
Completing the proof
The step case

fails
confidential
Debugging the Step Case

State at t:
state_s = start and
grant_o = 0
Unreachable!
confidential
Strengthening the Assertion
Make the
assertion
stronger
The assertion
holds!
confidential
Another Way of Dealing with False Negatives

The original problem was a false negative in the
idle property
In certain design, false negatives can be
elimitated by shifting the starting point of the
property
Example
property idle is
assume:
at t+1: state_s = idle;
at t+1: request_i = 0;
prove:
end property;
False negatives that can be filtered in this way are

called Short-Term Redundancies
confidential
Short-Term Redundancy
n D-FFs as output registers:
t+1
t +2
a
b
Prove:
Irrelevant counter-example!
Dependencies needed!
Cure:
at t: a = b
a
b
no assumption nor commitment for time points before t+N, or

add "at t-N: true; " to the assumption in order to shift left
boundary of examination window
confidential
Unreachable states and Completeness

Complete sets of operation properties
Eliminate the unreachable states by strengthening the
definition of the important states
A complete set of properties is needed!
confidential
Summary
How to check assertions from reset on longer
intervals
Assertions can depend on environment constraint
Short-term redundancies
Completeness helps in dealing with unreachable
states
confidential

RSP OSS Schulung

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RSP OSS Schulung

Загружено:

Авторское право:

Доступные форматы

OneSpin Solutions

Training Module Verification

Module 1: Introduction to Formal Verification

What do you learn now ?

Where does assertion / property checking fit

What are the advantages of using

Formal Verification in Design Flow

Check RTL Integrity:

Goal: implementation meets specification.

Strategy: Verification is split into function and timing.

Formal Consistency &

including cycle-based timing

No pattern generator: formal approach is exhaustive.

100% functional coverage achievable.

Significantly reduced verification costs.

Extracts pre-defined and user-defined checks from RTL

If property is proven, slide it across any possible simulation

360 MV Blocks All Error Escape Routes

Current Verification Practice

Consistency Checking (Dynamic Linting, Intent

generates and proves a vast number of simple assertions:

verifies the implementation of a specification.

neither needs a testbench, nor an environment.

verifies function, no low-level timing.

generates a pattern if the property is violated.

verifies as many patterns as exhaustive simulation.

is much faster than exhaustive simulation.

attains 100% functional coverage!

Module 2: OneSpin Shell and Data base

What do you learn now ?

shell and database

Tcl allows definition of variables and procedures

Starting OneSpin shell

Data in OneSpin Shell

Data collection is called database

HDL-files (VHDL, Verilog)

Load and Save of Database

User guidance: commands for the respective task

for messages and commands

What do you learn now ?

Modeling & abstraction for property checking.

This internal format is also called a "model".

Layout editor: geometrical shapes on a grid

Additional abstraction (optional):

Model for Property Checking: FSM

set of input variables

Initial state is not part of the model.

FSM Model of a Design

State of FSM consists of all registers of the design.

State Transition Diagram of a FSM

two state variables: "s1" and "s2"

One triple of (state, inputs, outputs) is associated

Structural Abstraction: Black boxing

Black boxing, continued

3. Make signal driven by Bs outputs primary inputs:

Black boxing, continued

all values are

Black boxing B may allow input traces on C that

Module 4: Set up a design

Simplest Use Case of Setup and MV

HDL model and Design model

Parsed and analyzed HDL

Elaborated from HDL

Phases of Setup Mode