Copyright © 2004 by Doulos Ltd. All Rights Reserved Experiences of a PSL Educator John Aynsley,...

Copyright © 2004 by Doulos Ltd. All Rights Reserved

Experiences ofa PSL Educator

John Aynsley, Technical Director


• Why our customers use PSL

• What our customers need to learn

(The marketing stuff)

• Teaching temporal reasoning

(The technical stuff)

Experiences of a PSL Educator


Why PSL?

• Verification is the problem

• The PSL solution is

• Incremental - not disruptive

• Easy to learn

• Non-proprietary

(in Europe, we like to keep EDA vendors hungry)

• Supported by tools today

• Opens the door to formal verification


What is there to learn?

• Learning the syntax is easy

• Learning why is more challenging!

• The selling job


Bogus debates

• Properties are a simulation overhead

• so can I turn them off?

• Properties only replace one problem with another

• how do I debug the properties?


Real debate - who writes properties?

• The system architect (or whoever) writes the spec

• The design and verification engineers interpret the spec and write properties

• The RTL design engineer

• White-box verification, driven by the implementation

• Block-level test benches

• Properties embedded in RTL code

• The verification engineer

• Black-box verification, driven by the specification

• Chip-level test benches

• Properties in separate files


Who writes properties?

• Writing properties forces you to be more formal

• Finds ambiguities in the spec

• Helps the design engineer understand the design

• Assertion-Based Design

• “Your lab questions aren’t accurate”

• Properties can be used to augment the spec


Observability

BUG

Bug invisible here!Bug invisible here!

Test vectors

Test vectors

Bug caught by assertionBug caught by assertion

• Increased observability gives better bug coverage from a given set of tests

Watchdog

Sentinel


Localising Bugs

Block A

Block A

Block B

Block B

Assertion failure => bug detected in block AAssertion failure => bug detected in block A

Assertion failure => end-to-end bug somewhere in the designAssertion failure => end-to-end bug somewhere in the design


Properties are Reusable

Block ABlock A

PropertiesProperties

Interface PropertiesInterface Properties

Block-level StimulusBlock-level Stimulus

Block ABlock A Block BBlock B Block CBlock C

Chip-level StimulusChip-level Stimulus

Interface PropertiesInterface Properties

• Embedded assertions go on checking, even when you've forgotten about them!


Temporal reasoning

property p1 is always req -> next grant;property p1 is always req -> next grant;

clk

grant

req


Temporal reasoning


req holds

clk

grant

req


Temporal reasoning


req holds

grant holds

clk

grant

req


Temporal reasoning


req holds

grant holds

clk

grant

req

next grant holds


Temporal reasoning


req holds

grant holds

clk

grant

req

req -> next grant holds

next grant holds


Temporal reasoning


req holds

grant holds

clk

grant

req

assert p1;

next grant holds

pass fail

req -> next grant holds


next [N] versus sequence

assert always req -> next next (grant);assert always req -> next next (grant);

req

grant

pass failpass

clk

assert always {req} |-> {true[*2]; grant};assert always {req} |-> {true[*2]; grant};

assert always req -> next[2] (grant);assert always req -> next[2] (grant);


next_e versus sequence

req

grant

pass failpass

assert always req -> next_e[1:2] (grant);assert always req -> next_e[1:2] (grant);

clk

assert always {req} |-> {[*1:2]; grant};assert always {req} |-> {[*1:2]; grant};

assert always req -> next(grant) || next[2](grant);assert always req -> next(grant) || next[2](grant);


rose() versus sequence

assert always rose(req) -> next rose(grant);assert always rose(req) -> next rose(grant);

req

grant

pass fail

clk

assert always {!req; req} |-> {!grant; grant};assert always {!req; req} |-> {!grant; grant};


until versus sequence

assert always req -> next (ack until grant);assert always req -> next (ack until grant);

req

grant

fail

clk

pass pass

assert always {req} |=> {ack[*]; grant};assert always {req} |=> {ack[*]; grant};

ack


before versus sequence

assert always req -> (ack before grant);assert always req -> (ack before grant);

req

ack

fail

clk

pass

grant

pass

assert always {req} |-> {{[*];ack} && {!grant[+]}};assert always {req} |-> {{[*];ack} && {!grant[+]}};

Length-matching andLength-matching and


What we’ve learnt

EndEnd

nextnext

->->

alwaysalways

next[N]next[N]

{ ; ; }{ ; ; }

next_e[m:n]next_e[m:n]

|->|->

[*m:n][*m:n]

true[*n]true[*n]

rose()rose()

untiluntil

|=>|=>

&&&&

[+][+]

beforebefore

[*][*]

Temporal operators Sequences Function

Date post:	25-Dec-2015
Category:	Documents
Upload:	melvin-wells
View:	214 times
Download:	1 times

Copyright © 2004 by Doulos Ltd. All Rights Reserved Experiences of a PSL Educator John Aynsley,...

Documents