post silicon verification under limited observability n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Post-Silicon Verification under Limited Observability PowerPoint Presentation
Download Presentation
Post-Silicon Verification under Limited Observability

Loading in 2 Seconds...

play fullscreen
1 / 30

Post-Silicon Verification under Limited Observability - PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on

Post-Silicon Verification under Limited Observability. Ganesh Gopalakrishnan School of Computing, University of Utah, Salt Lake City, UT 84112 Ching Tsun Chou Intel Corporation, 3600 Juliette Lane, Santa Clara, CA Supported in part by NSF award CCR 0219805. Why Post-Silicon Verification?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Post-Silicon Verification under Limited Observability' - yetta-skinner


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
post silicon verification under limited observability

Post-Silicon VerificationunderLimited Observability

Ganesh Gopalakrishnan

School of Computing, University of Utah,

Salt Lake City, UT 84112

Ching Tsun Chou

Intel Corporation, 3600 Juliette Lane,

Santa Clara, CA

Supported in part by NSF award CCR 0219805

why post silicon verification
Why Post-Silicon Verification?
  • Why verify the silicon? Isn’t doing FV enough? (!)
    • FV cannot be applied to entire MP systems yet
      • MP systems contain several CPUs and several “chip-sets”
  • We cannot verify the silicon exhaustively - so why bother?
    • Formal analysis applied to particular executions can yield far more insights than ad hoc criteria applied to executions
      • e.g. “Runtime Verification” of software (Havelund, Rosu, Lee ,..)
slide3

Why Post-Silicon Verification?

  • Runtime verification can cover more!
    • 1 GHz in silicon instead of 100 Hz during simulation
    • With well-designed “stress tests” one often finds out a lot
where post si verification fits in the hardware verification flow
Where Post-Si Verification fitsin the Hardware Verification Flow

Specification

Validation

Design

Verification

Testing for

Fabrication

Faults

Post-Silicon

Verification

Spec

product

Pre-manufacture

Post-manufacture

Does functionality

match designed behavior?

more facts about post silicon verification
More Facts about Post-Silicon Verification
  • Post-Si Verification can be for uniprocessor functionality
  • .. or to determine if MP Orderings are being obeyed
  • ... or to check if cache coherence protocols are behaving
  • Directly impacts the time to market
  • The industry spends huge amounts of effort in this area
  • Great opportunities to apply FV
how formal methods can enhance post si verification
How Formal Methods can enhance Post-Si Verification
  • Reduces manual effort
  • Helps in test-case selection
  • Helps analyze execution results comprehensively
overview of the talk
Overview of the talk
  • How the paradigm for post-Si verification must change
  • How Limited Observability impacts post-Si verification
  • The use of Constraints
  • A paper design for a Post-Si verification system based on
  • constraints
  • - based on actual experience developing prototypes
  • in an industrial context
  • Concluding Remarks
post si verification for cache protocol execution
Post-Si Verification for Cache Protocol Execution
  • PRESENT-DAY
    • Assume there is a “front-side bus”
    • Record bus transactions in response to test programs
    • Generate detailed cache states from bus transactions
    • See if behavior matches cache coherence protocol
    • that was supposedly realized

….

cpu

cpu

cpu

mem

“Front-side Bus”

post si verification for cache protocol execution1
Post-Si Verification for Cache Protocol Execution
  • Future
    • CANNOTAssume there is a “front-side bus”
    • CANNOT Record all link traffic
    • CAN ONLY Generate sets of possible cache states
    • HOW BEST can one match against designed behavior?

cpu

cpu

cpu

cpu

Invisible

“miss” traffic

Visible

“miss” traffic

potential carry over of techniques
Potential Carry-over of Techniques
  • Runtime verification of distributed embedded systems
    • Hundreds of processors, FPGAs, SoCs, ... interacting
    • Cannot assume system will work correctly on its own
    • Must detect onset of crashes, intrusions, ... EARLY
    • Cannot easily observe all the nodes
    • Even if observable, information corrupts
        • - bandwidth limitations (need to compress / discard)
        • - time uncertainties
back to our specific problem domain

x

a

c

b

y

d

Back to our specific problem domain...

Verify the operation of systems at runtime

when we can’t see all transactions

Could also be offline analysis of a partial log of activities

a x c d y b …

possible outcomes of post si verification
Possible Outcomes of Post-Si Verification
  • Observed Behavior is “Definitely wrong”
  • “Potentially dangerous” (rely on statistics to give this verdict?)
  • “Worth noting” (based on past experience and bug logs?)
  • …..
  • “Totally benign” (not even worth noting event)
  • Caveat: we are partially observing a potentially incorrect system
concrete example coherence protocol verification

Potential Owners

Requester

sreq

Home

sresp

req

Retries

or

Completion

….

Direct

Supply

of Data

Concrete example: Coherence Protocol Verification
packet encodings and example trace file

Pkt_type

Pkt_type

Packet encodings, and example trace-file

Users

  • All the packets pertaining to
  • a transaction share the
  • same mid and tid
  • Address not shipped with responses

sreq

Req

Home

req

resp

….

req /

sreq

mid

tid

sender

dest

addr

data

resp

mid

tid

sender

dest

data

A transaction and various packets it may involve:

req

first-snoop-req

subseq-snoop-reqs

Data

subseq-snoop-resps

Completion

the actual trace file is an interleaving of the packets of all active transactions
The actual trace-file is an interleaving of the packets of all active transactions:

Individual transactions and their

possible temporal overlap

The actual trace-file analyzed looks something like this:

The transactions may pertain to the same address (or not); many of the shown events may be missing…

transaction packet semantics

Potential Owners

Requester

….

Transaction (packet) semantics:

p

p

p

p

  • Each packet “p” can only be issued under certain cache-line states
  • After issuing it, the cache-line state often changes
  • After receiving a packet, the cache-line state changes
  • These details are VERY complex, and often need to be extracted
  • from cache protocol tables...
verification consists of abstract interpretation driven by transaction history

c1

c1

c1

c1

c1

c2

c2

c2

c2

c2

c3

c3

c3

c3

c3

c4

c4

c4

c4

c4

Verification consists of abstract interpretation driven by transaction history:

Knowing transaction (packet) semantics, we can compute sets of

possible states in which each cache line can be in after each packet

goes by ... (well, during offline analysis) . Error is flagged when

inconsistency is noted in sets of cache states.

slide18

General approach: Know all possible communication patternsof various transactions, and how to record progress along aparticular pattern; use constraints to bridge gap.

Communication

patterns

State

within

comm.

pattern

slide19

How many of the packets can be invisible? At first cut (and based on some practical experience) having one missing in any “causal loop” seems tolerable – more than one appears TOO under-constrained.

OK

OK

OK

Not OK

general statements pertaining to invisibility
General statements pertaining to invisibility

In a “fork/join” situation,

how many responses can be invisible?

Generally there are invariants governing the

responses (e.g., “at most one supplier of

the value)

If one response is invisible, we can assume it

met the invariant -- and remember this to

cross-check against future behavior

If more than one response is invisible, we will

have to increase the space of assumptions

If we do not see a response,

we have to delay “closing out” the

transaction till another pertinent event

involving the same address occurs

OR

verification of mutual exclusion of resource usage proper arbitration

2

1

Snoop of 1

3

Expected overlap of transactions under proper arbitration

Tr 1

Tr 2

Tr 3

Verification of Mutual Exclusion of Resource Usage (proper arbitration):

Check:

Transaction 1 must “close-out” before transactions

2 and 3 are found to make progress

Possible idea: Assume that the

“first snoop request” tells

who won the arbitration

Problem: What if the first

snoop request was on an

invisible link?

approach initially tried
Approach initially tried
  • Wrote a prototype in Ocaml to analyze given cache protocol execution trace
  • For each new packet read, its corresponding communication pattern and state within communication pattern was determined
  • For each packet, we obtained WP and SP
    • WP : Weakest Precondition (in a sense)
    • The most general set of cache states under which packet could be generated
    • SP ; Strongest Postcondition (in a sense)
    • The tightest set of states the cache could be after the packet is sent
    • Many transaction-types and “conflict situations” made state maintenance and update highly unstructured (about 8 versions of the code were written, with each version becoming soon ugly)
a conflict scenario for example
A Conflict Scenario (for example)

Potential Owners

sreq

Requester

Home

req

sresp

Retries

or

Completion

  • Requester issues “flush” packet
  • Arbitration conflict at home
  • Packet sent back for re-issue
  • Meanwhile another request gets past home
  • Home sends new request to requester
  • New request “hijacks” flush-line away!
  • Transaction never gets reissued

….

Direct

Supply

of Data

constraints to the rescue but
Constraints to the rescue.... but....
  • Constraint-programming was viewed as a possible solution
    • Would permit local behavior to be expressed in terms of constraints
    • Constraint formalisms can “solve” for missing information
  • But, traditional constraint frameworks found inadequate
    • After extensive search, we could not find a constraint paradigm that can deal with interacting automata
    • What we need is a method for back-tracing precursors to observed actions
    • When multiple observations trace back to the same precursor, we can ‘vote the precursor up or down’
    • Conditional probabilities of events are involved in guiding search
approach being planned for implementation
Approach being planned for implementation

Given a packet, determine comm pattern and state within comm pattern

Trace precursors along comm pattern till we reach origin of transaction

(which is at a cache where the transaction missed and issued)

Determine the cache state for the particular transaction using the

WP rule for the packet

approach being planned for implementation1
Approach being planned for implementation

If cache state not previously determined, mark it speculative

If cache state previously determined and present WP determines a

compatible cache state, convert `speculative’ to committed

If previously determined cache state is being contradicted by

present WP, mark cache state unknown and trigger backtracing

(cancel this precursor computation path and explore another)

slide27

Cache Agent that was

a “responder” for one transaction

may be “originator” for another....

Responder to

two different transactions

How two precursor computations

may lead back in time to a common node

and how we will have to “vote” its cache state

(red deposits a speculative state - purple votes it up or down...)

why today s constraint approaches don t give these capabilities readily
Why today’s constraint approaches don’t give these capabilities readily..
  • Today’s constraint solving approaches (“CSP”) appear to be about “static” situations
  • Various algorithms based on arc consistency and propagators can be found in the literature
  • Temporal Concurrent Constraint Programming is in its infancy
  • (I also don’t know much about these areas... tell me if I’m wrong! But I’ve not seen very much despite intense literature searches...)
  • Constraint Solving in the context of Coupled Reactive Processes can be have multiple uses
  • Environments such as Comet (van Hentenryck) may offer a powerful way to organize such a constraint-based system
constraint languages surveyed and some evaluated
Constraint Languages Surveyed (and some evaluated...)
  • GnuProlog
  • Sicstus Prolog
  • Mozart / Oz
  • Erlang
  • FaCile
  • .. or even Murphi perhaps?

Reading List (Books / Papers...)

  • Stuckey’s book on Constraint Logic Programming
  • Dechter’s book on Constraints
  • Modeler++ / Localizer++ / Comet
  • Ultimately will roll our own constraint system
concluding remarks
Concluding Remarks
  • Limited Observability is going to be a central concern in future system verification
  • Plenty of opportunities for formal methods, constraint-solving methods, and abstract interpretation methods to work in concert
  • Formal Methods communities must talk to other communities to significantly enhance the scope and relevance of what they are doing
    • testing communities
    • diagnosis communities