( ESNUG 520 Item 2 ) -------------------------------------------- [03/07/13]
From: [ Dean Drako of IC Manage ]
Subject: And some more survey data on verification headaches and IP reuse
Hi, John,
I was recently invited to speak at DVClub in Silicon Valley. My topic was
the impact of IP reuse on verification.
Design reuse is absolutely part of the race to market, but on its own, it
doesn't cut it. The nature of continuous design requires verifying and
fixing the IP as both the modules and the chips evolve, so it is vital to
also focus on the verification aspects of IP reuse.
SPEED UP VERIFICATION WITH IP REUSE
To better assess opportunities where effective IP reuse and dependency
management could reduce verification time, IC Manage's 2013 independent
survey investigated 372 engineers on where their verification teams
currently spend their time.
The three primary verification tasks where time is being spent are:
1) developing testbenches,
2) writing and running the tests, and
3) debugging.
Each of these key verification tasks has overhead associated with IP reuse
and dependency management.
1. IP testbench development. Testbenches are frequently either not
tied to the IP, or the proper IP testbench version is not tied to
the proper IP version, creating testbench development
redundancies.
2. Writing and Running tests. With today's complexities, the
context of where the IP is used in a design is nearly as
important as the IP itself. It is risky to expect that an IP
placed somewhere in a design will behave identically to the same
IP placed elsewhere. Any verification information associated
with an IP that is lost, including whether or not it works under
certain conditions, risks duplication of effort.
3. Debugging. Debugging time is comprised of identifying bugs (25%)
and managing bug dependencies, such as tracing instances/history,
bug notification and propagating fixes (17%). This means
verification engineers spend an average of 40% of their debugging
time on managing bug dependencies! Even worse, a lack of
notification can result in redundancies, such as multiple teams
debugging the same problem in multiple instances of an IP.
The example below illustrates the problem of IP bug interdependencies.
A common IP is shared across 3 projects. Each node represents a release of
that IP, and the edges show the direction of sharing. An identical bug
is found in both releases I and M. Because B is common ancestor of releases
I and M, a minimum of 12 releases -- B plus all of its 11 descendants -- are
at risk. The maximum number of releases at risk is all of them, should the
defect trace back further to ancestor A.
IP REUSE DEPENDENCY MANAGEMENT
In any engineeering group, to properly do their jobs different constituents
depend on ready access to information regarding the IP to be reused. These
people include:
- Chip designers
- Verification engineers
- Project leads
- IP owners
- Design and verification management
In this 2013 independent survey, the 372 team members each ranked their
top 3 challenges with IP reuse dependency management, as they affected BOTH
design AND verification. Below is what they stated were the top priority
issues they needed to address.
The respondent's top problem cited was managing the mix of data sources and
inadequate sharing and reuse of testbenches. Organizations are faced with
managing IP data, not only from 3rd parties, but internally, where they
often have a combination of design management systems across various design
groups, including commercial systems, open source revision control,
internally developed systems, and open source. For example, the digital
group often has a different DM system than the custom/analog group, which
can make it difficult to reuse the IP between the groups.
As a virtual tie for their number one problem, organizations recognized
redundancies in testbench development as a missed chance for "verification
reuse". As mentioned earlier, 26% of verification time is spent developing
testbenches, so the time impact of duplicate effort is considerable.
Another extremely technically complex issue for dependency management is
finding a bug in an IP and being able to trace it both backwards and
forwards in the branch history to identify all the IP instances across
projects, designs and derivatives. Limitations here prevent timely
notification of the bug and fixes to other IP users. The worst case
scenario is taping out a chip with a known bug in an IP used elsewhere
in the design.
Additionally, processes and systems are suffering from the lack of adequate
checklists for IP development and verification -- as a way to infuse a
consistent process and communicate ongoing status. The absense of such a
checklist can limit design team confidence in reusing IP that they did not
personally develop and verify.
Teams often count on robust 3rd party IP, yet it also can have multiple
versions over time, with dependencies to manage. Additionally, the lack
of an organizational infrastructure and design and verification team
participation was a obstacle to reusing IP.
IP reuse is problematic if key IP property and status items are missing.
Further, status and decision making is inhibited if engineering and
verification management, chip project leads, and IP owners do not have an
efficient way to compile and view all the data associated with a particular
IP or a particular design into meaningful formats. This includes, but is
not limited to, bug roll-up reporting.
- Dean Drako
IC Manage, Inc. Campbell, CA
---- ---- ---- ---- ---- ---- ----
Related Articles
New data from 372 engineers and managers surveyed on real IP reuse
Dean Drako posits his design and verification IP Reuse 2.0 vision
10 design and verification "best practices" for IP Reuse 2.0 today
The Show-Me-The-Money IP Reuse 2.0 ROI and what IC Manage does
Join
Index
Next->Item
|
|
