FPV For Design Exploration Erik Seligman CS 510, Lecture 11, February 2009

FPV For Design Exploration

Erik Seligman

CS 510, Lecture 11, February 2009

Agenda

Basic Concept RTL Exploration: Simple Example FPV as RTL Spec Analysis

(Thatcher/Chen) Behavioral Indexing

Agenda

Basic Concept RTL Exploration: Simple Example FPV as RTL Spec Analysis

(Thatcher/Chen) Behavioral Indexing

Design Exploration: When Needed?

Ownership handover / job transition Newly written block, lacking confidence Old design that needs updating Receive IP from external team

Simulation may be available • But may only show typical/expected traffic

• How do you understand atypical situations?

Fundamental Principle

With FPV, you can specify where you want to go, and the tool figures out how to get there!

Very different from simulation• For simulator, need to generate test vectors

• Lots of effort to test hard-to-reach situation

FPV for RTL Exploration?

FPV finds “interesting” corner cases• Comes up with ways to violate expectations

• Tends to drive atypical traffic

• Often not tests you would have written

Use it to help RTL understanding• View CEX for cover points

• Refine with additional assumptions– May constrain model to interesting part of space

• Challenging if very complex interface to block– Traffic less meaningful if fundamental assumes missing– But can mitigate with intentional over-constraint– Also: use assumes on internals, or asserts as assumes

How To Do it

Load design into FPV tool Add cover point to view some behavior

• Best tools let you do this on-the-fly

• Manually add SVA cover with other tools

Observe & refine for “interesting” trace• Create additional assumptions after viewing

– Restrict some inputs in certain cycles

– Require desired values on outputs

• Again, on-the-fly or SVA depending on tool

Agenda

Basic Concept RTL Exploration: Simple Example FPV as RTL Spec Analysis

(Thatcher/Chen) New Methods to Characterize RTL

Arbiter Example

Looking at example from JG doc dir Initially don’t know much about design Get started by looking at interface:

input clk, rstN; // Clock and reset (active low)input int_ready;input int_valid;input trans_started;input [3:0] ig_req;output [1:0] ig_sel;

To view arbiter activity, let’s start by covering case where agent 1 selected• ig_sel == 2’b01

Start Visualizer

Initial Plot

More Realistic Start?

Better Plot

Compete With Agents 2/3?

More Interesting Plot

Can Agent 1 Get Grant Without Request?

No! (Formal Proof)

Fix Too-Constant Inputs

Continue Fixing Inputs

Interesting Twist: Now Other Bus Wins First

‘Why’ Tracing If Desired

Is Non-Grant to Agent 1 a Necessary Effect? -- Try Freeze

Now Look For Grant After…

Grant 1 Not Possible Now!

Agenda

Basic Concept RTL Exploration: Simple Example FPV as RTL Spec Analysis

(Thatcher/Chen) Behavioral Indexing

The Concept

Why wait until RTL is written?• Specify basic behavior with assertions

Then prepare env to run FPV• Make assertions into assumptions

• Add cover points as FPV targets

Result: see behavior allowed by design• Coverage traces from FPV

• Discover gaps in assumptions

• Discover corner cases that need thought

Flowchart

Traffic Light Example

Traffic Light Example

Initial Specification1) Green or yellow light cross street gets red light.

2) Lights change in green, yellow, red sequence.

3) Traffic at red light gets green light if no traffic on cross street.

4) Traffic must not wait more than 5 ticks at a red light.

5) Traffic does not reset until green light appears. (No Right-On-Red!)

Q: Is this spec sufficient and/or complete?

• Convert to SVA assertions to find out…

FPV Runs

Coverage points created• Each light sees each color

• Cars waiting max time at each light FPV run, waveforms viewed

• Unexpected results– Green and red lights on Main at same time– Looong yellow light (length not bounded)– No lights / all-red situations allowed

• Nothing in original spec prevented these!

• Assertions (assumptions) added in response

OpenSparc T1 Cache

Multiple cores accessing memory Credit-based

• Agent can request memory based on credits

• Multi-cycle op may require >1 credit Similar early-FPV technique used Important properties

• Request only if proper # of credits

• One-hot grants bus

• No grants without requests

Things To Consider

Method not guaranteed to find bugs• Looking at specific coverage points

• May miss ‘dangerous’ situations

Complex cover pts are more interesting• Refine after initial FPV: add assumptions

Consider adding safety assertions• If you think safety should be fully ensured by

def of protocol

Agenda

Basic Concept RTL Exploration: Simple Example FPV as RTL Spec Analysis

(Thatcher/Chen) Behavioral Indexing

Growth of Design Reuse

RTL often reused by later teams Ownership often changes

• Knowledge lost

• Hard to find people to consult

How is IP documented?• Usually static plain-English word doc

• Some example waveforms

Dangerous to touch!• Expected behavior unknown in many cases

• How specific are waveforms in document?

Idea: Behavioral Indexing

Jasper DesignCon 2009 Paper IP designer specifies cover points

• Then get waveforms from FPV tool Store FPV data structures & waveforms

• Store prereqs to re-generate from RTL

• Annotation mechanism for IP owner– Mark important transitions– Designate ‘events’ (pre-defined sequences) that

are important

• Also connect transitions to source code

Behavioral Indexing Benefits

Basic understanding• Bring up waveforms, follow transitions

• Query about “why” to source code

“What-if” questions • Bring up FPV visualizer on modified RTL

• Attempt to generate same waveforms

• Look for annotated transactions!– If they are gone, figure out why

Launching Point for FPV

References / Further Reading

http://fvclasspsu2009q1.pbwiki.com/f/ChenThatcherProtocolVisualizationPaperFinal.pdf

http://www.scdsource.com/article.php?id=330

http://fvclasspsu2009q1.pbwiki.com/f/JasperDA-DesignCon%202009%20Paper-Final.pdf