RSP OSS Schulung

OneSpin SolutionsOneSpin SolutionsTraining Module VerificationTraining Module Verification

Part I Part I -- BasicsBasics

July 2007

OneSpin Solutions GmbHTheresienhoehe 12

80339 Munich – Germany

[email protected]

July 2007/Page 2confidential

Content

Module 1: Introduction to Formal VerificationModule 2: OneSpin Shell and Data baseModule 3: Models Module 4: Set up a designModule 5: Checking PropertiesModule 6: How to check and debug propertiesModule 7: Operation PropertiesModule 8: More Advanced Properties

Module 1: Introduction to Formal VerificationModule 1: Introduction to Formal Verification


• Where does assertion / property checking fitinto the verification flow?

• What are the advantages of using formal verification technology?

What do you learn now ?


Formal Verification in Design Flow

Implementation nVerify Preservation:

Equivalence Checking

Verify Implementation:Propery Checking

Implementation 1

Specification

e.g. RTL Entry

e.g. Synthesis

Check RTL Integrity:Consistency Checking

Strategy: Verification is split into several steps.OneSpin offers comprehensive formal verification

tool suite.

Goal: implementation meets specification.


Verification is split

• Strategy: Verification is split into

ZA

B

tpdLH tpdHL

1.3 ns 1.1 ns

and timing.function

A B Z

0 0 0

10 0

0 01

1 1 1


Verification Methods

Implementation

Preservation

Manufacturing

Timing

At-Speed Test, High Temperature,

...

Function

ATPG,...

FormalEquivalence Checking

Formal Consistency &Property Checking

Simulation

Simulation

Simulation

Simulation

Static TimingAnalysis

Static TimingAnalysis

*) including cycle-based timing

*)


hold/fail

Simulator

TestbenchPattern

GeneratorPatternAnalyzer

Simulation

Design

– Simulation is incomplete.

Specification

– Testbench required.


Diagnostics

Property Checking

hold/fail

Property Checker

Properties

Specification

• No pattern generator: formal approach is exhaustive.• 100% functional coverage achievable. • Significantly reduced verification costs.

HDL-Front-End

Design


DiagnosticsStatistics

Consistencychecker

Consistency Checking

HDL-Front-End

Design

• Uses OneSpin´s HDL-front-ends and formal verification technology: exhaustive checks of all possible scenarios.

• Extracts pre-defined and user-defined checks from RTL without user effort.

Properties

Specification

Proof Engine

Consistency Checks

Proof Engine

Consistency Checks


Comparison

• Examine a small number of patterns

011010001000

Design

Simulation

111110101100011010001000

Design

Property/Consistency Checking

• Same as automatic, exhaustive simulation

• each functionality stimulated

• Much faster than exhaustive simulation

• Runtime limitations


incoming outgoing

• 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

• If property is proven, slide it across any possible simulationrun

• Unspecified signal values are don‘t care

Operation Properties

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);sdram_wdat

ad

da' a''act

idle

wr nop noppr

idle

nop

requestrw

addresswrite_data

readycontrol

sdram_addr

state


360 MV Blocks All Error Escape Routes

Current Verification Practice

360 MV


• generates and proves a vast number of simple assertions:

• Consistency Checking (Dynamic Linting, Intent Checking)

– pre-defined ones extracted from the design.

– ones extracted from user-defined incode-assertions.

Summary


• verifies the implementation of a specification.

• Property Checking

• 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!

Summary

• Completeness Checking

Module 2: OneSpin Shell and Data baseModule 2: OneSpin Shell and Data base


• shell and database



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


Starting OneSpin shell

% onespin --help

% onespin &

% onespin –-gui=nosetup> # some commandssetup> ...setup> exit%

% onespin my_run.tcl

% onespin –-interactive_after_script my_run.tcl


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– HDL-files (VHDL, Verilog)– ITL-files contain properties

database

tcl variables

databasepersistenceOneSpin

commands

tclcommands

OneSpin shellre

fere

nce

refe

renc

e

ITLVHDLVerilog


Load and Save of Database

> onespinsetup> # some commandssetup> save_database my_databasesetup> exit

> onespin --database my_databasesetup> # some commandssetup> save_database my_databasesetup> exit

> onespinsetup> load_database my_databasesetup> # some commandssetup> exit ;# prompt for save: yes/no


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• Prompt shows current modesetup> set_mode mvmv>

setup

mv

ec

cc


Help

• Help for commandssetup> help <command-pattern>

• Examplessetup> help *vhdl*setup> help –mode mv *propert*

• Complete user documentation(including Reference manual)– Help button/Help menu– Pdf-file in $ONESPINROOT/doc


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 commandssetup> start_message_log <log-file>

# all messages are logged in <log-file>setup> stop_message_log

Module 3: ModelsModule 3: Models


• Modeling & abstraction for property checking.



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:

– 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)


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


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.


FSM Model of a Design

outputs

next-statesstates

inputs

dq

dq

FSM

combinationallogic

A2nextstatelogic

A1nextstatelogic

A3nextstatelogic

A4nextstate

&outputlogic

A5outputlogic

o1

o2

o3

o4

i1

i2

i3

i5

i6

i4

i7

i8

s6ns6

s5ns5

s4ns4

s3ns3

s2ns2

s1ns1

s9ns9

s8ns8

s7ns7

Design

State of FSM consists of all registers of the design.


State Transition Diagram of a FSM

two inputvariables

"d1” and "d2"

(0,1)=next-statefunction(0,0,1,0)

input 1 for d10 for d2

one outputvariable

called "q"d1,d2/q

output 0for q

1,0/0

two state variables: "s1" and "s2"

(s1,s2)

s1 is in state 0s2 is in state 0

(0,0)

(0,0)

1,0/0=output function(0,0,1,0)

input 1 for d10 for d2

s1 is in state 0s2 is in state 0


0

Example

• 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” onceper clock cycle.

0

1

1

1

1

1

0

0

0 1

0

0

in

state

out

0

0

0/1

1/0

1/11

in

state

out

time point 0 1 2 3 4

0/0 00/0 0

1

0/0 0

00

1/0

1

1/0

10

10

1 1/1

0/1

0 1/11

1 110

0/1

0 1

synchronous DFF


Structural Abstraction: Black boxing

• Black boxing means not representing certain cells, modules, sub net lists, etc. in the model.

1. Cut out component B:

B

CA


Black boxing, continued

2. Make driver to B’s inputs primary outputs:

3. Make signal driven by B’s outputs primary inputs:

CA

CA


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

Black boxing, continued

CAall values are

considered

B

CA only values generatedby B are

considered

Module 4: Set up a designModule 4: Set up a design


Simplest Use Case of Setup and MV

> onespinsetup> read_vhdl c.vhd d.vhdsetup> elaboratesetup> compilesetup> set_mode mvmv> read_itl a.vhimv> check_property read_reqmv> report_results

Read VHDL/Verilog

Elaboration

Go to mv mode

Read ITL(properties)

Check aproperty

Show results

Compilation


HDL model and Design model

• HDL model– Parsed and analyzed HDL

files

HDLmod_1

i1: mod_2 i2: mod_2 i3: mod_3

i1: mod_4

i2: mod_4

i1: mod_4

i2: mod_4

i1: mod_5

mod_5

Design mod_1

i1: mod_2 i2: mod_2 i3: mod_3

i1: mod_4

i2: mod_4

i1: mod_4

i2: mod_4

i1: black box

• Design model– Elaborated from HDL– One top-level– Black boxes (optional)

typically for RAMs– Fixed values for generics/

parameters


Phases of Setup Mode

read_hdl

elaborate

compile

mv

setup

set_read_hdl_optionget_read_hdl_optionread_vhdl/read_verilog

set_elaborate_optionget_elaborate_optionelaborate

pin declaration

set_compile_optionget_compile_optioncompile


Scheme for Option-Commands

set_get_add_

delete_report_

read_hdlelaboratecompiledebug

monitormap

compare

_option

PhaseOperation



read_hdl

elaborate

compile

mv

setup

pin declaration


Read-HDL Phase: Read a VHDL Design

• 1. set options for read VHDL> onespinsetup> set_read_hdl_option -vhdl_version 93

-pragma_ignore synthesis_

• 2. Read VHDL filessetup> read_vhdl -library juhu a.vhd b.vhdsetup> 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


setting read_hdl options

• set one or more optionssetup> set_read_hdl_option -vhdl_version 93

-pragma_ignore synthesis_

• set an option to a list: use tcl-listssetup> set_read_hdl_option -pragma_ignore

{synthesis_ translate_}

• check and use the valuessetup> get_read_hdl_option -pragma_ignoresynthesis_ translate_setup> report_read_hdl_optionvhdl_version: 93pragma_ignore: synthesis_

translate_setup> set my_vhdl_version \

[get_read_hdl_option –vhdl_version]93


Omitting VHDL text parts

• Omit VHDL text parts between pragmas

-- pragma translate_off;signal testbench_error_code: integer;-- pragma translate_on;

e.g. omit the following text between the pragmas:

by specifying the pragma_ignore option:

setup> set_read_hdl_option –pragma_ignore translate_


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


Read-HDL Phase: Restart

• To remove previous parse results

setup> clear_design

• read_hdl_options are not reset by clear_design


Read HDL Phase: Example (VHDL)

read_vhdl arbiter.vhd



read_hdl

elaborate

compile

mv

setup

pin declaration


Elaborate Phase

> onespinsetup> set_elaborate_option

-vhdl_generic abc=2-verilog_parameter le=0-black_box *ram*-top arb

• Elaborationsetup> elaborate

– top level is automatically detected if unique and not specified


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


Elaborate Phase: Example (VHDL)

set_elaborate_option -vhdl_generic nr_masters=5elaborate



read_hdl

elaborate

compile

mv

setup

pin declaration


Compilation

> onespinsetup> set_compile_option

– for advanced users only

• Compilationsetup> compile

– Needed to enable pin declaration



read_hdl

elaborate

compile

mv

setup

pin declaration


Pin Declaration

setup> set_clocking -rising clk

Alternative settings:-default found during compilation-falling <pin> falling edge of <pin>

and others

setup> set_reset_sequence -low res_nAlternative settings:

-default found during compilation-high <pin> high active reset <pin>-scheme <sequence> arbitrary reset-sequence


Pin Declaration Phase: Example (VHDL)

Set_mode mv


Model building assertions

• There are signal assignments that cause a simulator to stop because the HDL semantics isnot defined.

entity ai isport(clk,reset: in bit; i: in integer;v: out bit_vector(3 downto 0));end ai;

architecture beh of ai isbeginprocess(clk,reset)beginif reset = '1' thenv <= (others => '0');elsif clk'event and

clk = '1' thenif i < 4 thenv(i) <= '1';

end if;end if;end process;end beh;


Model building assertions: OneSpin solution

• OneSpin model produces an output for eachvalue of the inputs and states even if an simulation run-time error would occur

• Output of the onespin model is arbitrary in thiscase!

• A generated assertion fires then.

v(i) <= '1';

if (i >= 0) and (i <= 3) thenv(i) <= '1';

elsev(<arbitrary>) <= '1';assert (false);

end if;


Check Model building assertions

• It can be proven that a model building assertioncan 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.


Example (VHDL)

read_vhdl arbiter.vhdset_elaborate_option -vhdl_generic nr_masters=5elaborateset_mode mv

check_consistency -category model_building

Module 5: Checking PropertiesModule 5: Checking Properties


• property syntax– the basics, just bits and bit-vectors– only the stuff needed for the 1st example

• counter-example



Waveform Viewerhold/fail

Flow for Property Checking

Property Debugger

OneSpin Property Checker

Model Property

RTL

Specification


Basic Idea of the Language

• If property is proven, slide it across any possible simulation run.

staterequestfreegrant

t+ 1 + 2

t_free+ 0 + 1

0-11

idle_ /= 0

_ /= idle idle

_ /= 0

CommitmentsAssumptionsIf hold, then hold.

• Simple temporal operators + VHDL/Verilog like state expressions

• ITL properties specify cause-effect relations between signals similar to waveforms.

• Wherever the blue patterns match, the red ones will match.


Specification

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

q_odffd_i

clk

res

CVE Assertion CheckingI-2/6©Infineon Technologies AG 2004, All rights reserved

Confidential

Designlibrary IEEE;use IEEE.std_logic_1164.all;entity dff isport(clk : in std_logic;d_i : in std_logic;q_o : out std_logic;);end dff;architecture rtl of dff isbeginprocessbeginwait until clk’event and clk = '1';q_o <= d_i;end process;end rtl;


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:

t is the referential time point (any simulation cycle).

property dff isassume:at t: res = ‘1’;

prove:at t+1: q_o = prev(d_i);

end property;

Assumption

Commitment


Commitments and Assumptions

• A property is split into two parts: a list of commitments and a list of assumptions.

Design

• Assumptions describe the environment.

• Commitments describe the design.

property Example is

end property;Commitments

AssumptionsEnvironment


time point t time point t+1 time point t+2

Exhaustive (2n) Pattern Generator

inputs

outputs

statesinternal

nets

next-states

inputs

outputs

statesinternal

nets

next-states

inputs

outputs

statesinternal

nets

next-states

Pattern Analyzer

Derived from property

Unrolled design

hold/fail

Semantics as Combinational Model


Pattern Analyzer

hold/fail1

10

Commitment 1

Commitment 2

Commitment 3

Assumption 1

Assumption 2

Assumption 3

&&

• Assumptions enable the commitments to be checked.

• If the assumptions disable, there is nothing to check.


Semantics and Waveforms, Step 1

t t+2t+1outputs

int. signals

inputsstates

t t+2t+1outputs

int. signals

inputsstates

t t+2t+1outputs

int. signals

inputsstates

Exhaustive Pattern Generator determines all states at first cycle t and all inputs forcomplete examinationwindow.

case 1

case 2

case 3

Next-state- and output-functions of

Finite State Machine i.e. the design

determine all states from cycle t+1 until the end and

all internal signals and outputs for the complete examination window.


t t+2t+1outputs

int. signals

inputsstates

case 1False


• Assumptions sort out those waveforms for which the assumption is false.

t t+2t+1outputs

int. signals

inputsstates

t t+2t+1outputs

int. signals

inputsstates

t t+2t+1outputs

int. signals

inputsstates

True

True

case 1

case 2

case 3

t t+2t+1outputs

int. signals

inputsstates

t t+2t+1outputs

int. signals

inputsstates

case 2

case 3


False


t t+2t+1outputs

int. signals

inputsstates

t t+2t+1outputs

int. signals

inputsstates

True

fail

• Commitments decide whether a property holds or fails.

• If commitment fails for at least one waveform the property fails.

case 2

case 3

counter-example found

&


I@t+1S@t I@t

Example: Parity Generator

property parity isassume:at t: S = '0';prove:at t+1:

Q = I xor prev(I);end property;

assumption

time point t time point t+1

input

state

next-state

output

input

state

next-state

output

commitment

110

hold/fail

SI Q

=

'0'=

Q@tQ@t+1


Counter-Examples (1)

• Diagnostic produces a sequence over the examination window, which is called "counter-example".

• 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 dwill be available at the output qtwo clock cycles later.

t t+2t+1

d

q

t t+2t+1

d

q


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


Prove and Assume Part

prove part= commitment

assume part= assumption

property name

end property;

property <Identifier> isassume:

<TemporalExpr>;…

prove:<TemporalExpr>;…

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


Temporal Expressions

hold/fail

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


property Example isprove:at t: <StateExpr>;

end property;

at t

• Examination window is [t,t].

read variablesat time point t

VHDL or Verilog - like expressions over input, state, output variables,

and internal signals

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

t


at

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

• <offset> is a constant integer expression containing– Arithmetic: +, -, *– Parentheses: ()

at t+<offset>: <StateExpr>;

at t-<offset>: <StateExpr>;• General syntax:

• Inputs, states, etc. are read by that combinational logic block at some constant offset from t.


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.


History in Examination Window

property Example isassume:at t-1: <StateExpr>;

prove:at t+1: <StateExpr>;

end property;

property Example isassume:at t+1: <StateExpr>;

prove:at t+3: <StateExpr>;

end property;

t t+1 t+2 t+3t-1 t t+1

"history"of one additional state transition


• If the time interval is non-empty, this is equivalent to an according number of timed state expressions at.

during

• If the time interval is empty (e.g. [t+3,t+1]), this is the same as if the “during” construct were not there

property Example isprove:during [t+1,t+3]:<StateExpr>;

end property;

property Example isprove:at t+1: <StateExpr>;at t+2: <StateExpr>;at t+3: <StateExpr>;

end property;

during [t[+-]<offset>,t[+-]<offset>] : <StateExpr>• General syntax:

during [t-1,t+2] : a = 1;• Example:

Module 6: How to check and debug propertiesModule 6: How to check and debug properties


What do you learn now?

• Write properties

• Check properties

• Debug properties and design

• Application Example


Design Under Verification: Arbiter

Master 0

Master 1

ster 2

Arbiter

request_i3

free_igrant_o

Resource

Master 2

3


A Typical Trace

request_i(0)

request_i(1)

grant_o(0)

grant_o(1)

free_i

request_i(2)

grant_o(2)

state_s busy idle st busy idle st


Implementation of the Arbiter

Master w. lowest index winsprio_s=0: no request

prio_s

request_i

START

BUSY

state_s = IDLEReset stateWait for requests

state_s = STARTGrant the highest priority master

state_s = BUSYWait for the resource to become free

grant_o/=0

free_i/=0

IDLE


Reading the Design

setup> read_vhdl arbiter.vhd

setup> elaborate

setup> set_mode mv

default clock found

default reset found


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”

grant_o

request_i

state_s IDLE

--1

001

t t+1property grant_master_0 isassume:

at t: state_s = IDLE;at t: request_i(0) = '1';

prove:at t+1: grant_o = "001";

end property;


Reading the Property

mv> read_itl arbiter_master0.vli

Property not proven yet


Checking the Property

mv> check_property grant_master_0

The property fails


Debugging

mv> debug_property

Failing commitment is colored red

Reset is active


Debugging (cont.)

When reset is activegrant_o is forced to zero


Excluding reset

constraint no_reset :=reset = 0;

end constraint;

include “constr_no_reset.vhi”;

property grant_master_0 isdependencies:

no_reset;assume:



end property;

constr_no_reset.vhi

arbiter_master0.vhi

Define a constraint which excludes the reset

The definition can go into a different file

Use “include” to link the 2 files

The property depends on the constraint


Checking the Modified PropertyThe definition of “grant_master_0” has changed;the old proof status is no longer valid


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 bymv> read_itl ;# no options/parameters

• to show all itl-files currently usedmv> get_itl_files

• to exclude an itl-filemv> release_itl <itl-file>


Checking the Modified Property (cont.)

The property still fails!


Debugging (again)

Two masters are granted at the same time!


Debugging (cont.)

When in IDLE, grant_o takes the

value of prio_s

prio_s is assigned in the process “priority”


…assume:



end property;

Formal Verification vs. Simulation

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: state_s = IDLE;at t: request_i = “101”;


end property;

Holds!


Many Test Cases

Formal Verification vs. Simulation (cont.)

grant_o

request_i

state_s IDLE

--1

001

t t+1

resetrequest_i

free_i001

state_sgrant_o

idle start busy

001000

idle start busy idle start busy

101 111

001 111000 000

011

000

idle

One Pattern


Fixing the bug

priority: process(request_i)variable index_v: natural range 0 to nr_masters-1;beginprio_s <= (others => '0');for index_v in 0 to nr_masters-1 loopif request_i(index_v) = '1' thenprio_s(index_v) <= '1';

elseexit;

end if;end loop;

end process priority;

“else” is wrong; the loop must stop as soon as a request is found


Checking the Fixed Design

setup> elaborate –reread_hdl

mv> set_mode setup

setup> set_mode mv

default clock found

default reset found

property is unproven


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


The Property Holds!


Summary

• How to write a simple property in ITL– assume, prove, dependencies, at, constraint

• How to check and debug properties

• Formal Verification vs. Simulation

Module 6: How to check and debug propertiesModule 6: How to check and debug properties

Used Syntax


property grant_master_0 isassume:


prove:at t+1: grant_o = ”001”;

end property;

-- This is a line comment

Comments

• VHI files can be structured by comments.

• A line comment starts with -- just like in VHDL .

• A block comment starts with /* and ends with */ .

/*This is a block comment.

*/


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

Ports of instances are usable

• Signals of lower level components are usable :

a_i1:a

ctrl_i:ctrl

state_s

a_i1 /state_s/ctrl_i


Types of Signals

• same as in VHDL• except:

– std_[u]logic_vector unsigned– bit_vector unsigned– array of bit unsigned– integer, range unsigned or signed– natural, positive unsigned


Literals

• Bit, std_logic and std_ulogic:

• Bitvector, std_logic_vector and std_ulogic_vector:

'1''0'

"10101111" O"257" X"AF"

• Number:175

• Literal of user-defined enumeration type:IDLE

• Boolean literals:false true

internally: unsigned

internally: signed (negative) or unsigned

color’RED typemarking if type is not unique


Structural Operations

• Concatenation:"1010" & "1111" = "10101111"

• Bit-Slicing: type is kept"011"(1 downto 0) = “11”

• Indexing on arrays:request_i(0) memory_s(2,1)



• Shift arithmetically:

• Rotating:

shift_left("10101111",3) = "01111000"

shift_right("10101111",3) = "00010101"

rotate_left("101",2) = "110"

rotate_right("10",1) = "01"


constraints

• used to describe behavior of the environment• assumed to hold in each cycle starting after reset

– implicitely assumed over the whole examination window

• definitionconstraint <name> :=

<boolean-expression>;end constraint;

• property that assumes a constraint property Example isdependencies:<name-of-constraint>;

assume: …

Module 7: Operation PropertiesModule 7: Operation Properties



• Developing an Operation Property

• Constraining the Environment

• Dealing with Variable Time Intervals

• Contradictory Assumptions

• Reachable and Unreachable States


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


Operation Property in ITL



request_istate_sgrant_ofree_i

t

idle idleidle001

--1


no_reset;

assume:at t: state_s = IDLE;at t: request_i(0) = '1';

prove:at t+1: grant_o = "001";at t+4: state_s = IDLE;

end property;

t+1 t+4







t t_grant

idle idleidle001

--1


no_reset;



end property;

t_grant+3







t t_grant t_free_i

idle idleidle001

--1


no_reset;



end property;




no_reset;for timepoints:

t_grant = t+1,t_free_i = t_grant+3;


prove:at t_grant: grant_o = "001";at t_free_i: state_s = IDLE;

end property;





t t_grant t_free_i

idle idleidle001

--1


Use time variables to name meaningful

timepoints


Checking and Debugging

at “t_free_i” state_s is not IDLE

at “free_i” is set 2 cycles after grant, instead of 3


Adding the Environment Constraint

constr_grant_free_after_3.vhiconstraint grant_free_after_3 :=

if grant_o /= 0 thennext(free_i) = '0' andnext(free_i,2) = '0' andnext(free_i,3) = '1'

end if;end constraint;

arbiter_master0.vhiinclude “constr_no_reset.vhi”;include “constr_grant_free_after_3.vhi”


no_reset,grant_free_after_3;

for timepoints:t_grant = t+1,t_free_i = t_grant + 3;


prove:at t_grant: grant_o = "001";at t_free_i+1: state_s = IDLE;

end property;


The Property Holds!


A Different Environment

constr_grant_free.vhiconstraint grant_free :=

if grant_o /= 0 thennext(free_i) = ‘1' ornext(free_i,2) = ‘1' ornext(free_i,3) = '1'

end if;end constraint;

arbiter_master0.vhiinclude “constr_no_reset.vhi”;include “constr_grant_free.vhi”


no_reset,grant_free;

for timepoints:t_grant = t+1,t_free_i = t_grant + 1..3;



end property;

“The resource is freed within 3 cycles from grant”


Checking and Debugging

no connection!


Defining the “t_free_i”





assume:at t: state_s = IDLE;at t: request_i(0) = '1';during [t_grant+1, t_free_i - 1]: free_i = '0';at t_free_i: free_i = '1';


end property;


The Property Holds!

Warning if a time variable with interval value is not restricted


Contradictory Assumptions





assume:at t: state_s = IDLE;at t: request_i(0) = '1';during [t_grant+1, t_free_i]: free_i = '0';at t_free_i: free_i = '1';


end property;

typo:“t_free_i”Instead of “t_free_i – 1”

at t_free_i:free_i = ‘0’ and free_i = ‘1’

Contradiction!!!


Contradictory Assumptions (cont.)

Do not accept “hold empty”!


Contradictory Assumptions:why does the property holds

hold1

10

Commitment 1

Commitment 2

Commitment 3

Assumption 1

Assumption 2

Assumption 3

&&

• Assumptions enable the commitments to be checked.

• If the assumptions disable, there is nothing to check.

constant 0

constant 1

not relevant!


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


The Arbiter’s State SpaceReachable and Unreachable states

idle start busy

state_s

grant_o

000

001

010

011

100101

110

111

• State Space:– state_s x grant_o

• Reachable states:– Reset state– States reached from the

reset state– Etc.

• Unreachable states:– All the other states






assume:at t: state_s = IDLE;at t: request_i(0) = '1';during [t_grant+1, t_free_i-1]: free_i = '0';at t_free_i: free_i = '1';


end property;

Start State of “grant_master_0”

No assumptions on grant_o

idle start busy

state_s

grant_o

000

001

010

011

100101

110

111

Holds from unreachable states!


Properties Starting from Any StatePros & 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

stateNot a true failureSoon learn how to deal with false negatives


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

Module 7: Operation PropertiesModule 7: Operation Properties

Used Syntax


Logical Operations

• Bit-wise operations:not and or xor nand nor xnor

• Reduction operations on vectors:and_reduce or_reduce xor_reducenand_reduce nor_reduce xnor_reduce

and_reduce("1111111") = '1'

– e.g.


Conditional Expressions

• Complete if expressionif a then

b = 3else

b = 5end if

≡

• Incomplete boolean if expression

if a thenb = 3

end if≡

if a thenb = 3

elsetrue

end if• Note difference to VHDL: no assignment in VHI !!!

a ?b = 3 :b = 5

b = if a then3

else5

end if

≡


Conditional Expressions• Cascaded if statements:

if a1 thenb = 3

elsif a2 thenb = 5

elseb = 0

end if

if a1 thenb = 3

else if a2 thenb = 5

elseb = 0

end ifend if

≡

• case statement:case c iswhen 2 => d = 6;when 3 => d = 9;when others => d = 0

end case;

if (c = 2) then d = 6elsif (c = 3) then d = 9else d = 0end if;

≡


prev and next Operators

stands for:previous value of cnti.e. at t

• For each signal or expression, the previous and next values can be referenced.

property Example isprove:

at t+1: cnt = prev(cnt) + 1;end property;

stands for:next value of cnti.e. at t+1


at t: next(cnt) = cnt + 1;end property;

stands for:next but one valueof cnt i.e. at t+2


at t: next(cnt, 2) = cnt + 2;end property;

CVE Property CheckingI-5/24©Infineon Technologies AG 2004, All rights reserved

Confidential

• If the time interval <TimeRange> is non-empty,

within

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

<TimedStateExpr> ::= within <TimeRange>:<StateExpr><TimeRange> ::= [<TimeExpr>,<TimeExpr>]

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

property Example isprove:within [t+3,t+4]: <StateExpr>;

end property;

<StateExpr> should betrue at t+3 or at t+4


Confidential

either .. or

• Operator within is restricted:

<TimedStateExpr> ::= either <TimedStateExpr>{or <TimedStateExpr>}+end either;

property Example isprove:within [t+3,t+5]: <StateExpr>;end property;

<StateExpr> shouldhold at t+3,or at t+4,or at t+5

property Example isprove:either at t+3: <StateExpr1>;orat t+5: <StateExpr2>;end either;end property;

<StateExpr1> should hold at t+3 or <StateExpr2> at t+5

• Construct either .. or is more general:

At least one, possibly several alternatives hold:


Confidential

rose, fell, changed

• Derived operators:

rose(expr) ::= not(prev(expr)) and exprfell(expr) ::= prev(expr) and not(expr)changed(expr) ::= expr /= prev(expr)


Abbreviating Time Points

Uses the time variable

Defines a time variable

Denotes atime point

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

property Example isfor timepoints:t_grant = t+1;

prove:at t_grant: ack_o = '1';

end property;


Cascaded Time Variables

• There may be a list of time variable definitions.

• A definition of a time variable uses exactly one other time variable.

property grant_master_0 isfor timepoints:t_grant = t+1,t_free_i = t_grant +3;

assume:...

prove:at t_grant: grant_o = ”001”;at t_free_i+1: state_s = IDLE;

end property;


Time Variable over Intervals

Stands for:in [t+3,t+4]

• 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 isprove:

at t+4: state_s = IDLE;end property;

property Example isprove:at t+3: state_s = IDLE;

end property;

property Example isfor timepoints:t_free_i = t+3..4;

prove:at t_free_i: state_s = IDLE;

end property;


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.

property Example isfor timepoints:t1 = t+1..2,t2 = t1+2..3;

prove:<TimedStateExprList>

end property;

,(t+1,t+4),(t+2,t+4),(t+2,t+5)}(t+1,t+3)

t1=t+1 t1=t+2

t2=t1+2 t2=t1+3 t2=t1+2 t2=t1+3

(t1,t2)={

t

t1=t+1 t1=t+2

t2=t+4t2=t+3 t2=t+5t2=t+4


Confidential

property Example isfor:prove:<TimedStateExprList>

end property;

M..N;=

for

<Identifier>

• Introduces a new constant named <Identifier> .

• Implicitly expands a property to a set of properties, withone 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

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 isfor:Index = 3 ;prove:at t: DO_o(Index) = 0;

end property;

property Example_4 isprove:at t: DO_o(4) = 0;

end property;

property Example_3 isprove:at t: DO_o(3) = 0;

end property;..4 ≡


Confidential

property Example isfor:


end property;

<Identifier> = M..N,

More on for

• You can have a list of for variables, separated by commas.

• The for part is positioned directly before freeze part.

<Identifier> = Q..R;freeze:<Identifier> = <Expr> @ <TimeExpr>;

<Identifier> = O..P,


Confidential

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 jprove:at t: mem(i,j) =

if i < j then djielse iend if;

end property;

• The for variables may be used in freeze expressions.

More on for

• Restrict for variable with assumption, not in definition.

⌦ For inspecting intermediate results use freeze variables.

Module 8: More Advanced PropertiesModule 8: More Advanced Properties



• Writing more general properties

• Freeze variables

• Macros

• Generating a witness


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


arbiter_all_masters.vhiinclude “constr_no_reset.vhi”;include “constr_grant_free.vhi”

property grant_master isdependencies:

no_reset, grant_free;for timepoints:

t_grant = t+1,t_free_i = t_grant + 1..3;

assume:at t: state_s = IDLE;at t: request_i /= 0; -- some requestduring [t_grant+1, t_free_i]: free_i = '0';at t_free_i: free_i = '1';

prove:at t_grant: grant_o = grant_to_highest_prio(req);at t_free_i+1: state_s = IDLE;

end property;

A Property for All the Masters (cont.)arbiter_master0.vhiinclude “constr_no_reset.vhi”;include “constr_grant_free.vhi”






end property;





assume:at t: state_s = IDLE;at t: request_i /= 0; -- some requestduring [t_grant+1, t_free_i]: free_i = '0';at t_free_i: free_i = '1';

prove:at t_grant: grant_o = <highest priority request>at t_free_i+1: state_s = IDLE;

end property;





freeze:req = request_i @ t;

assume:at t: state_s = IDLE;at t: request_i /= 0; -- some requestduring [t_grant+1, t_free_i-1]: free_i = '0';at t_free_i: free_i = '1';

prove:at t_grant: grant_o = grant_to_highest_prio(req);at t_free_i+1: state_s = IDLE;

end property;

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;


The Property Holds!


Generating a Witnessarbiter_all_masters.vhiinclude “constr_no_reset.vhi”;include “constr_grant_free.vhi”




freeze:req = request_i @ t;

assume:at t: state_s = IDLE;at t: request_i /= 0; -- some requestduring [t_grant+1, t_free_i-1]: free_i = '0';at t_free_i: free_i = '1';

prove:false;at t_grant: grant_o = grant_to_highest_prio(req);at t_free_i+1: state_s = IDLE;

end property;

• No counter-examples for holding properties

• Witness– a trace on which the

property holds• Force the property to fail


Generating a Witness (cont.)

“prove: false;”To generate an example

on which the property holds – a witness


Expanding Macros


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

Module 8: More Advanced PropertiesModule 8: More Advanced Properties

Used Syntax


freeze

property Example isfreeze:


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

<Identifier> <Expr> @ <TimeExpr>;=

• Signals generated by freeze serve to compare values of variables and expressions at different time points.


Application: freeze vs. prev/next

property Relative isprove:

during [t+1, t+3]:out = prev(sig);

end property;

property Absolute isfreeze: sig_0 = sig @ t;prove:

during [t+1, t+3]:out = sig_0;

end property;

sig

out

t t+1 t+2 t+3

sig

out

t t+1 t+2 t+3

• relative reference: prev/next

• absolute reference: freeze


Macro Syntax (VHI)

macro return type

macro callproperty Example isassume:at t: Request;

prove:at t+2: grant_o = ”001”;

end property;

macro Request : boolean isrequest_i = '1';

end macro;

• Prepare re-use of assumptions by way of macros.

macro name


Macro Parameter of HDL Types (VHI)

formal parameterof a HDL type

• Generalize macros by parameter of HDL types.

property Example isassume:

at t+1: Request('1');prove:

at t+2: grant_o = ”001”;end property;

macro Request (ActiveLevel: std_ulogic) : boolean isrequest_i = ActiveLevel;

end macro;

Note: signals are usable within a macro without need of parameter usage.

actual parameterof a HDL type


Different Macro Types

property Example isdependencies:

no_reset, gnt_req;assume:

at t+1: if (a < b) thenb-a

elsea-b

end if;prove:

at t+2: rdy_o = '1';end property;

Expressions

temporals

dependencies

time points

properties


Confidential

State Expression Macros: Constant

state expression macro call

state expression macro call

HDL type of the state expression

• Improve readability and modifiability by macros.

macroActiveLevel: std_ulogic is'1';end macro;

property Example isassume:at t+1: Request(ActiveLevel );prove: at t+2: rdy_o = ActiveLevel;

end property;


Confidential

Constant Return Type

• For bit-slicing, specify const return type.

macro accepted as constant

prefix key word const

macroc2: const range is 2;

end macro;

property Example is...prove:at t+2:reg(c2 downto c2 - 1) = 0;

end property;


Confidential

State Expression Macros: Function

• Functional macros return HDL-typed value

macromax_prio(i,j: range): unsigned isif prio(i) > prio(j) then prio(i)else prio(j)end if;

end macro;

property example isassume:at t: prio(0) = max_prio(0,1);

prove:at t+1: arb_win = 0;end property;


Confidential

State Expression Macros: Relation

• Relational macros return true or falsemacrogt_prio(i,j: range): boolean isprio(i) > prio(j) or(prio(i) = prio(j) and i <= j);

end macro;

property example isassume:at t: gt_prio(1,0);

prove:at t+1: arb_win = 1 and

prio(1) > prio(0);end property;


Confidential

macroone_hot(vec:unsigned;l,i:range): boolean isif vec(i) = '1' then

vec((l-1)downto(i+1)&

vec((i-1)downto(0)= 0

end if;end macro;

--shift_right(vec,i+1)--shift_left(vec,unsigned’(l-i))

Example: 1-Hot Macro

property at_most_one_grant_p isfor: 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

macro stable(X:std_ulogic): boolean isX = prev(X);

end macro;

Example: Temporal Operators• Using prev/next, macros can implicitly refer to

different time-points:

property Example isassume: during [t, t+7]:stable(input1) and stable(input2);

at t+3: rose(clk);prove: ...end property;

macro rose(X:std_ulogic): boolean isprev(X) = '0' and X = '1';

end macro;


Confidential

macro type for list oftimed state expressions

macro call

Timed State Expression Macro

• Special type assertion:

property Example isassume:Request;prove:at t+2: rdy_o = '1';

end property;

macroRequest: temporal isat t : req_i = '0';at t+1: req_i = '1';end macro;


Confidential

Inclusion of Macros

a VHI file

macro<Macro>end macro;...

• Several macros sections in a file allowed.

include ...;

Defining re-usablemacros

VHI macro file named"Basics.vhi"macro

m1: ... end macro; property p1 is... m1 ... end property;macrom2: ... end macro;property p2 is... m2 ... end property;

definemacrosbeforeusage

includeVHI

macro files

include "Basics.vhi";include "Params.vhi";


Arithmetic and Comparison

• Sign:+A_s -A_s

• Binary operations:

• Comparison:

A_s + B_s A_s * B_sA_s - B_s

A_s = B_s A_s /= B_s

A_s > B_s A_s >= B_s A_s < B_s A_s <= B_s

A_s div B_s A_s mod B_sA_s rem B_s


Confidential


• Bit-Slicing: type is kept, sign is new MSB if signed

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

• Resizing, removing or filling with '0'/sign at left end:

RESIZE(signed’"101",2) = signed’"11"RESIZE(signed’"010",2) = signed’"00"RESIZE(signed’"10",3) = signed’"110"

RESIZE("011",2) = "11"RESIZE("11",3) = "011"


Confidential

Example: Signs & Lengths

• Result of subtraction is signed.

property Example is prove:

end property;

at t: "111" = "000" - 1;

at t: signed’"111" = "000" - 1;

at t: "111" = resize("000" - 1,3);at t: "111" = unsigned’("000" - 1);

at t: "110" = ("111" - 1)(2 downto 0);at t: "110" = unsigned’(("111" - 1)(2 downto 0));

///

/

• Result of addition/subtraction has carry bit.

• Equality uses numerical interpretation.

-- "1111"-- "111"-- "1111"-- "1111"-- "0110"

at t: resize("111" - 1,3) = ("111" - 1)(2 downto 0);

• Resized or bit-sliced (un-)signed is (un-)signed.

/

• Resize preserves sign, bit slicing doesn’t.

/


Specifics of Operations

• The result’s internal representation of any operation will be large enough to avoid anyover- or underflow.

• The result is to be understood arithmetically, wherever possible.

• Mixed argument types are allowed, wherever possible.

- Arguments’ internal representation may be resized.

- Resizing is done arithmetically: Sign is preserved.


Confidential

Exercise: Alu

flags_o.carryflags_o.ovflflags_o.negflags_o.zero4 4

in0_iin1_i

out1_o out0_o

flags_o

44

cmd_i

ASLASRLSRADDSUBMULSMULUIDLE

• As preparation

– analyze alu_pack.vhd, alu.vhd into library work .

– note that entity alu describes a combinational circuit .(set_clocking…)


Confidential

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 .

• Hint: function shift_left of VHI does an arithmetic shift-left .

• Put everything into one property .

Verify other commands in the same style !

CVE Property CheckingI-6/21©Infineon Technologies AG 2004, All rights reservedConfidential

Solutions


Confidential

Idle Operation and Shift Left

property asl isassume:at t: cmd_i = ASL;prove:at t: out0_o = shift_left(in0_i,1);at t: out1_o = 0;at t: flags_o.carry = in0_i(3);at t: flags_o.ovfl = (in0_i(3) xor out0_o(3));

end property;

property idle isassume: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;


Confidential

Error Handling in ATM Cells

• CRC enables correction of one-bit errors

Header CRC Data

an ATM cell

# of bit errors

prob

abili

ty

1 packet size

trunk errors

routing errors

• CRC enables detection of multi-bit errors

• Error correction code CRC for Header


Confidential

10/01

ATM Error Controller

1 A cell is never corrected and dismissed at the same time.

10/1011/010-/00 0

0-/001

11/01 correct_o

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.

error_i

multiple_i dismiss_o

state

error_i multiple_i correct_o dismiss_o/

*)

*)

CVE Property CheckingI-5/31©Infineon Technologies AG 2004, All rights reservedConfidential

Solutions


Confidential

Solution for Exercise 1

property t1 isprove:at t: correct_o = '0' or

dismiss_o = '0';end property;

10/ 0110/10

11/ 010-/00 00-/ 00

1

11/01


Confidential

Solution for Exercise 1 - variantsproperty t1 isprove:at t: correct_o = '0' or dismiss_o = '0';

end property;

property t1b isprove:at t: (correct_o = '1' and dismiss_o = '1') = false;

end property;

property t1a isprove:at t: (correct_o and dismiss_o) = '0';

end property;

property t1c isprove:at t: not(correct_o = '1' and dismiss_o = '1');

end property;


Confidential


property t2 isassume:at t: error_i = '0';prove:at t: correct_o = '0';at t: dismiss_o = '0';

end property;

10/0110/10

11/0111/01

0-/00 00-/00

1


Confidential

10/10


property t3 isassume: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;

10/0111/010-/00 0

0-/001

11/01


Confidential

Solution for Exercise 4property t4 isassume:during [t,t+1]:error_i = '1';at t+1:multiple_i = '0';

prove:at t+1: dismiss_o = '1';

end property;

10/1011/010-/00 0

11/01

10/010-/00

1


Confidential


property t5 isassume:at t: error_i = '1';at t: multiple_i = '1';prove:at t: dismiss_o = '1';

end property;

10/0110/10

11/010-/00 00-/00

1

11/01

OneSpin SolutionsOneSpin SolutionsTraining Module VerificationTraining Module Verification

Part III Part III –– Assertions and ConstraintsAssertions and Constraints

July 2007

OneSpin Solutions GmbHTheresienhoehe 12

80339 Munich – Germany

[email protected]

OneSpin Solutions/Page 387confidential

Content

Module 1: Unreachable states and AssertionsModule 2: Proving AssertionsModule 3: False assertions and constraints

Module 1: Unreachable states and AssertionsModule 1: Unreachable states and Assertions



• Dealing with failures due to unreachable states

• Assertions


The Arbiter’s State SpaceReachable and Unreachable states

idle start busy

state_s

grant_o

000

001

010

011

100101

110

111

State Space:– state_s x grant_o

IDLE START

BUSY

grant_o <= 0

grant_o <= prio_s

grant_o <= 0grant_o <= 0

grant_o <= 0

reachableunreachable








end property;

Start State of “grant_master_0”

No assumptions on grant_o

idle start busy

state_s

grant_o

000

001

010

011

100101

110

111

Holds from unreachable states!


Properties Starting from Any StatePros & 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

stateNot a true failure

• Learn how to deal with false negatives


Example – False Negative

IDLE START

BUSY

grant_o <= 0

grant_o <= prio_s

grant_o <= 0grant_o <= 0

grant_o <= 0

property idle isassume:

at t: state_s = idle;at t: request_i = 0;

prove:at t+1: grant_o = 0;

end property;

“If the arbiter is ready to serve a request and there is no request, then on the next cycle,grant_o is zero.”


Example – False Negative (cont.)

Unreachable start state


Filtering the Unreachable States

• Temporarily exclude the unreachable states that make the property fails.

• Check if the property holds


A More Generic Assumptionarbiter_idle.vhi


-- tmpduring [t_first, t_last]:

if (state_s = idle) then grant_o = 0

end if;at t: state_s = idle;at t: request_i = 0;


end property;

“if (state_s = idle) then grant_o = 0”is true for all reachable states, therefore is always true

Such conditions are called“invariants”


Assertionsarbiter_idle.vhi

assertion idle_grant :=if (state_s = idle) then

grant_o = 0 end if;

end assertion;

property idle isdependencies:

idle_grant;assume:

at t: state_s = idle;at t: request_i = 0;


end property;

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


Dependencies Management

mv> report_resultOne unresolved

dependency


Syntax - Assertions

• assumed to hold in each cycle starting after reset– implicitely assumed over the whole examination window

• definitionassertion <name> :=

<boolean-expression>;end assertion;

• property that assumes an assertion property Example isdependencies:<name-of-assertion>, <name-of-constraint>,…;

assume: …


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 projectMonitored during simulation


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

Module 2: Proving AssertionsModule 2: Proving Assertions



• How to prove assertions

• Proof by induction

• check_assertion


Proving Assertions

• 360 MV command to check assertions:– “check_assertion”

• “check_assertion” automates a proof technique called proof by induction


Mathematical Induction

• A technique to prove statements about the natural numbers

• Example

∑i=0

n2i = 2n+1 - 1

base case

prove for n = 0

20 = 1

2(0+1) - 1 = 2 - 1 = 1

induction step

assume the statement true for n-1 and prove it for n

∑i=0

n2i = ∑

i=0

n-12i + 2n =

= 2n – 1 + 2n = 2n+1 - 1


Induction in Formal Verification

State at t=0, just after reset

States at t= 1,states that

can be reached from the reset

state

States at t= n,states that

can be reached from the states

at t = n-1

…

t = 0 t = 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)

Sequence of Sets of States


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

assertion idle_grant :=if (state_s = idle) then grant_o = 0 end if;

end assertion;

property idle_grant_base isassume:reset_sequence;prove:at t: idle_grant;end property;

Automatically found when changing to mv mode

or defined by the user using set_reset_sequence

The cycle on which the reset is active is “t-1”


Checking the Base Property

mv> get_reset_sequence


Checking the Induction Step Property

The property fails!

The state at tis not reachable:false negative


Why Does the Induction Step fails?

idle start busy

state_s

grant_o

000

001

010

011

100101

110

111

Set of states described by the assertion, some reachable, some unreachable

assertion idle_grant :=if (state_s = idle) then

grant_o = 0 end if;

end assertion;

The start state in the counter-example is

unreachable


Why Does the Induction Step fails?

Set of states described by the assertion, some reachable, some unreachable

idle start busy

state_s

grant_o

000

001

010

011

100101

110

111

It is possible to leave the set of states described by the

assertion

Start state in the counter-example

This assertion cannot be proven by induction

The assertion must be refined by excluding the states that cause the failure


A Stronger Assertion

assertion idle_grant :=if (state_s = idle) then grant_o = 0 end ifandif (state_s = busy) then grant_o = 0 end if;

end assertion;

grant_o idle start busy

state_s

000

001

010

011

100101

110

111The remaining unreachable

states have a “next state” which is within the set of states

described by the assertion


Re-checking Base and Step Properties


Assertions vs. Reachable State Space

reachable states

idle_grant states

all states

Calculating the exact set of reachable states is typically not possible on non-trivial designs

InsteadFind and prove the invariants needed to prove the properties

All the states that satisfy an invariant that can be proven by induction have a next

state that satisfy the invariant


check_assertionautomatic proof by induction

First version of the assertion

mv> check_assertion idle_grant


debug_assertion

mv> debug_assertion

step property

The state at tis not reachable:false negative


Refining the Assertion

The assertion has changed

All the previous results are invalid, including the status of property “idle”

Making the assertion stronger


Re-checking the Assertion and the Property

Both assertion and property hold!


No Unresolved Dependencies

mv> report_result 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


Summary

• Proof by induction

• Check_assertion automates the induction technique

• How to debug assertions

• How to strengthen assertions in order to prove them

Module 3: False assertions and constraintsModule 3: False assertions and constraints



• Dealing with false assertions

• Assertion which depends on the environment

• Short-term redundancies


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;


check_assertion no_grant_idle

Before investigating the failure of the step case …


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>


Checking a Longer Base Case

mv> check_assertion –force –base –length 4 no_grant_idle


Debugging the Assertion

mv> debug_assertion –base

The reset sequenceends at t-1

Extended base property

Found a reachable state in which grant_o is zero and state_s is not idle;the assertion is not true for the design


Debugging the Assertion (cont.)

Expand “during”

Expand the assertion

In this example the assertion is wrong.

In a different situation this could have been a bug in the design!


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


Debugging the Assertion

“free_i” is always zero,environment violation


…an environment constraint might be needed

mv> check_assertion –force –base –length 100 max_3_busy_cycles

Add the environment

constraint

The extended base case holds

The step case still unproven


Completing the proof

The step case fails


Debugging the Step Case

State at t:“state_s = start and

grant_o = 0”Unreachable!


Strengthening the Assertion

Make the assertion stronger

The assertion holds!


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

• False negatives that can be filtered in this way are called “Short-Term Redundancies”


at t+1: state_s = idle;at t+1: request_i = 0;


end property;


Short-Term Redundancy

a

b

+2tt

a

b

• Prove: at t: a = b

t+1

• Cure:– 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

• Irrelevant counter-example!

• n D-FFs as output registers:

• Dependencies needed!


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!


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

Date post:	15-Dec-2015
Category:	Documents
Upload:	salloum18
View:	257 times
Download:	8 times

RSP OSS Schulung

Documents