Home > Community > Blogs > Functional Verification > a look back on 2008 before hazarding predictions for 2009
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

A Look Back On 2008 (Before Hazarding Predictions for 2009)

Comments(0)Filed under: Functional Verification, Enterprise Manager, OVM, CDV, Coverage-Driven Verification, metric driven verification (MDV), coverage driven verification (CDV), Open Verification Methodology, verification strategy, Multi-domain verification: HW/SW co-verification, HW/SW, e, Enterprise Planner

Before I dare take a stab at adding to the many predictions already made for 2009 (like those in EE Times and SCD Source), allow me to share with you some of the main verification technology-specific observations that the "Trailblazer" team saw in 2008:

1 billion logic gate chip roadmaps
As noted in a previous post, SoCs with over 1 billion logic gates are now on the drawing boards of customers around the word.  (That's billion with a "B", which per the 6x rule of thumb implies they will have 6 billion transistors.)  Of course, no customer in their right mind would ever create such a monster gate-by-gate from scratch.  Instead, such designs will be comprised of many, many blocks of proven IP. 

However, as many customers have learned the hard way when re-using "proven" IP in new chips, it's inevitable that once unreachable / masked corner-case bugs suddenly appear in this proven IP for a whole host of reasons.  Long story short: the requirements for verification tool and methodology scalability to simply re-validate these new IP collections, let alone root out the new corner-cases, are daunting to say the least.  (And FWIW, I remain surprised this whole "billion gate verification scalability" issue isn't getting more attention in the mainstream trade press, and/or when it is mentioned at all it's only raised in terms of the physical design challenges of the 22nm node).


True "Metric Driven Verification" (MDV) starts to evolve from CDV
In 2008 many customers have started to add new metrics above and beyond the recording of code and functional coverage.  Assertion coverage, sequence coverage, firmware code coverage, and the man-hours of D&V personnel are all examples of data points that engineers and managers at our most advanced customers are collecting together with [brace yourself for a shameless product plug] Incisive Enterprise Manager to get a complete picture of a given project's progress. 

In all honesty, this is not just a 2008 trend -- it's been ongoing for few years now, and it's been so prevalent that it inspired the creation of the new "Enterprise Planner" capability in Enterprise Manager.  (And in the "imitation is the sincerest form of flattery” department, 2008 saw Mentor soft launch their pale Enterprise Manager clone.  For completeness sake: last I heard, Synopsys' clone is still on ice due their obsession with propping up VMM.  But I digress.)


The "language war" is over -- all languages won!
Given the growing popularity of the SystemVerilog language, in 2008 I saw many customers trying to "standardize" on using SystemVerilog as their only verification, ESL, RTL, and assertions language (as per the language's original promise).  While this plan still has an obvious conceptual appeal, with very few exceptions customers have found this to be practically impossible to implement in practice. 

In short, if they haven't already realized it, customers are discovering that it's a multi-language world whether they like it or not.  Note: I'm not suggesting that SystemVerilog has not been widely adopted, and that some customers will use it for most of their work.  Instead, people are coming to terms with the fact that a) SystemVerilog is not a verification paneca, and b) there is a ton of non-SystemVerilog IP - both legacy code and new VIP -- that will need to be leveraged now and forever.  In summary, SystemVerilog  is simply a great complement to all the other EDA tools and methodologies people already have, and/or need to adopt in addition to SystemVerilog itself.


Pre-silicon HW/SW co-verification became too important to ignore
My colleague Jason Andrews expertly covers this topic in his blog, so I will simply refer you to his latest post on this issue.


Analog+Digital verification frustration grows
I cover this observation in my November post on the DV Club lunch presentation from Dr. Henry Chang of Designers' Guide Consulting.  To briefly recap: I was "relieved" (in an ironic, negative sense) to hear that an expert like Dr. Chang is seeing that the analog verification is still 15-20 years behind digital verification methodology and levels of automation, and for various reasons the situation is improving slower than anyone likes.


And last but not least:

Low Power pain continues
I'm sure it's no surprise that low power D&V was an ongoing concern in 2008.  Let me share a relevant anecdote: at every "ClubT", techtorial, or on-site customer meeting, I always ask the audience 2-3 questions about what pain points they may be facing to get a sense of how to further tailor my remarks to their information needs.  When ever I ask, "is power consumption and/or low power D&V an issue with you?", 95% of the hands in the room go up every time.


I'm eager to hear your reaction to these observations, so feel free to post some comments below or contact me offline.

Finally: Happy New Year!

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.