Innovating the Intelligence of Formal Techniques for Automatic Design Verification
Blog Archive
September 2010
9/03/2010: A Look at Transaction-Based Modeling
August 2010
8/20/2010: The 10 Year Retooling Cycle
July 2010
7/30/2010: Hardware-Assisted Verification Usage Survey of DAC Attendees
7/23/2010: Leadership with Authenticity
7/16/2010: Clock Domain Verification Challenges: How Real Intent is Solving Them
7/09/2010: Building Strong Foundations
7/02/2010: Celebrating Freedom from Verification
June 2010
6/25/2010: My DAC Journey: Past, Present and Future
6/18/2010: Verifying Today’s Large Chips
6/11/2010: You Got Questions, We Got Answers
6/04/2010: Will 70 Remain the Verification Number?
May 2010
5/28/2010: A Model for Justifying More EDA Tools
5/21/2010: Mind the Verification Gap
5/14/2010: ChipEx 2010: a Hot Show under the Hot Sun
5/07/2010: We Sell Canaries
April 2010
4/30/2010: Celebrating 10 Years of Emulation Leadership
4/23/2010: Imagining Verification Success
4/16/2010: Do you have the next generation verification flow?
4/09/2010: A Bug’s Eye View under the Rug of SNUG
4/02/2010: Globetrotting 2010
March 2010
3/26/2010: Is Your CDC Tool of Sign-Off Quality?
3/19/2010: DATE 2010 – There Was a Chill in the Air
3/12/2010: Drowning in a Sea of Information
3/05/2010: DVCon 2010: Awesomely on Target for Verification
February 2010
2/26/2010: Verifying CDC Issues in the Presence of Clocks with Dynamically Changing Frequencies
2/19/2010: Fostering Innovation
2/12/2010: CDC (Clock Domain Crossing) Analysis – Is this a misnomer?
2/05/2010: EDSFair – A Successful Show to Start 2010
January 2010
1/29/2010: Ascent Is Much More Than a Bug Hunter
1/22/2010: Ascent Lint Steps up to Next Generation Challenges
1/15/2010: Google and Real Intent, 1st Degree LinkedIn
1/08/2010: Verification Challenges Require Surgical Precision
1/07/2010: Introducing Real Talk!

Imagining Verification Success

Rajiv Kumar   Rajiv Kumar
   VP of Engineering

EDA developers need to have a very active imagination. They need to imagine becoming their own end users. Sometimes they may become the designer, sometimes the verification engineer or perhaps even the design manager.  This role play is essential for creating tools that will be embraced by the designers or else they are going to be just one-tool-wonders. For an EDA tool to become a regular tool in a designer’s tool chest, it needs to have a very high usability quotient, and a role play is essential for creating that.

A tool’s usage in a design flow can nominally be broken into three distinct phases a) Setup (b) Analysis and (c) Debug. Setup is required just once per design and is should not be a very onerous step.  Analysis is done within the tool and should be highly, if not completely automated.  It should minimize the need for much user attention other than tracking things like performance, memory size, etc.  It is the debug phase where the user spends most of his/her bandwidth. They have to examine the output of the tool, combine their design knowledge with the tool’s analysis data, and quickly identify and repair the source of any detected issues.

To accurately capture and automate this flow,  developers need to imagine how the users are going interact with their tool. For example – does the tool present information in the proper terms and conventions of the language in use? Is the debugging output organized consistently with the design structure? Is the tool effective at propagating bugs to observable points in the design? Is the debug environment able to reconstruct the faulty effect easily under user control? Effective organization of the output is essential to enable a user to view the results in ways that can be internalized easily.

By a large margin, debug is the major factor in a verification tool’s usability. An accurate understanding of the designer’s desires and needs is the most effective way of organizing the output in a clear, logical fashion.  Developer imagination is a key part of this effort, as is real customer feedback to gauge how effectively the goal has been reached.  Despite the availability of dedicated tools and methodologies for verification, users are spending a lot of time tracking down bugs that should have been easily caught and debugged. Sometimes, the only difference between failure and success is just a little imagination.

Apr 23, 2010

blog comments powered by Disqus