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

Initial Specification 1) 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  enThatcherProtocolVisualizationPaperFi nal.pdf enThatcherProtocolVisualizationPaperFi nal.pdf  =330 =330  perDA-DesignCon%202009%20Paper- Final.pdf perDA-DesignCon%202009%20Paper- Final.pdf