For verification, it was an eventful week. DVCON 2013
kept everyone busy with record attendance at the sessions and by following the
tweets & blogs that resulted from them. The major highlight of this year’s conference was release
of the latest update to System Verilog
standard, IEEE
1800-2012 and free PDF copies made available, courtesy - Accellera.
With verification constantly marching to increase its claim
on ASIC design schedule while retaining its position as a major factor for
silicon re-spins, verification planning was a hot topic of discussion at DVCON. Some of
the interesting points that came out of a panel discussion on verification
planning were –
- Verification plan is not just a wish list. You have to
define how you’re going to get there.
- Problem is not over-planning, but over-verifying designs
because there has not been enough planning.
- Biggest objection we hear is we don’t have time to
capture a verification plan. But you'll lose more time if you don't.
- What’s useful in verification planning is “ruthless
prioritization.” You can never get it all done.
- My biggest challenge is getting marketing input into my
verification plan.
- Failure to plan means planning to fail.
Last week, I guest blogged on a similar topic based on a
recent survey conducted by Catherine & Neil. Clearly, the issue of poor planning
gets highlighted in all areas of product development.
Traditionally, the verification plans were just a list of
features to be verified, addressing ‘what to verify’. With the emergence of
CRV, the plans started including the second aspect i.e. ‘how to verify’. Further,
to bring focus to this never ending verification problem, CDV was adopted. The verification plans now started including target numbers in terms of
coverage (code, functional and assertions) to define ‘when are we done’. With a
given set of resources, when the ASIC design schedule is imposed on the
verification plan, meeting the goals is a challenge. There arises a need to
prioritize verification in terms of the features. Remember, Any code that is not verified will not work!
To enable this “ruthless prioritization”, collaboration is
required among marketing, software and hardware groups to align to the design
objectives. Everyone needs to understand the potential end applications and preferential
ways in the design to achieve them. In case of IPs, this could mean that the
initial releases target a limited set of applications based on the customers on
board. Once that is achieved, ‘over-verifying’ can take over to further close
on the grey areas. In case of SoC, it is a tough call. While design cost continues
to increase with diminishing dimensions, the break even may not happen with
limited applications (as a result of limited verification) of the SoC. The
problem gets aggravated further with the specifications changing on the fly. A
platform based approach could be a potential solution where variants of SoC are
churned out frequently, but again defining the platform and prioritizing the features
boils down to the same problem. A tough nut to crack!
The whole point of over-verifying comes to the fore front
because verification is the long pole in the schedule. What if the designs
could be ‘over verified’ within the timelines? What does it take to achieve
that? Are tools like intelligent test benches, formal verification, hardware
acceleration or cloud computing a solution? If yes, what is the associated cost
and how does it affect?
There is no easy answer to any of these questions. In words of Albert Einstein, “The world we have created is a
product of our thinking. It cannot be changed without changing our thinking.”
Probably when an answer comes out, we will be on the road of commoditizing the hardware. Till then 'over-verification' is what we have to live with!
