( ESNUG 520 Item 3 ) -------------------------------------------- [03/07/13]
From: [ Dean Drako of IC Manage ]
Subject: Dean Drako posits his design and verification IP Reuse 2.0 vision
Hi, John,
Below I describe 6 key aspects of an IP reuse dependency management vision
which allows all team members -- design and verification engineers, IP
owners, project leads, and management -- to have near real-time access to
the information they need to efficiently reuse IP in their job. This vision
applies to IP-based design and verification within and between digital and
custom/analog design teams.
Here's how all the parts of this vision works:
1. Central repository, with a single view of IP.
Having a central repository addresses the challenges of mixed data sources.
Mixed data sources are managed by a central repository with a single
consolidated view of IP, that allows a company's internal and 3rd party data
to be imported or linked from multiple repositories such as IC Manage,
ClearCase, DesignSync, Subversion, and Perforce.
Engineers can go to one place, search and select the specific IP they need,
then integrate it into their design, while that particular IP remains
dynamically coupled to its own underlying data management system.
2 & 3. Design Properties Encapsulated, Verification Info Encapsulated
Each IP block has assigned owners for development and verification and is
ready for reuse with all its critical info encapsulated with the IP.
- For maximum design reuse, the chip designers and project leads
that may use the IP have immediate access to all the IP's metadata
and properties, including constraints and design history. The IP
properties are encapsulated hierarchically and organized in an
easily searchable manner.
- For maximum verification reuse, all verification information,
including testbenches and assertions, are also encapsulated.
Making sure the testbench is encapsulated with the IP will
increase verification reuse -- equally important is that the
testbench version matches the updated IP version. Encapsulating
assertions with the IP, will allow it to more easily be verified
in the context of the system in which it is being used, saving
time with system level verification.
This is a continuous update process because the IP evolves dynamically over
time; often the IP is being developed, updated and verified in parallel with
the design of the chip.
4. Bug Dependency Tracing, Notification and Fixes
Verification and design engineers view an IP with its design history and bug
history. If an engineer finds a bug, they can track through the complete
design history and be able to return the IP to an earlier working state.
The verification engineer who finds a bug can immediately view all IP
instances and versions, what chips they are used in, and by which engineers.
They can then send out an immediate notification regarding the bug to all
affected parties. This avoids the need for another team to later repeat the
same debugging process to find the identical bug.
The IP owner and verification engineer can also selectively auto-propagate
any fixes. The bug notification and fix is automatically attached to the IP
itself so that any future IP user can use it. Controlled automation of
these "bug interdependency management" steps can also prevent inadvertently
taping out with a known bug.
5. Design & Verification Checklist - for Continuous Design
Designs today are heavily IP-based. Even new design modules/IP that are
not intended for reuse, are developed in parallel with the chip. Each IP
module faces a process of continuous development and evolution.
An engineering group should set up a formal, customized process to do IP
development and verification with checklist items to track and monitor on
each IP block -- then to tie the relevant status information with the IP
that to continuously gauged progress.
Individual checklist guidelines can be enforced loosely or strictly,
depending on the guideline and the organizational need. The idea is not to
restrict the use of the IP but rather to encourage certain steps being
taken when it's stored or used. Such measures ensure that when a remote
design group checks in an IP, it's ready for a team in a different place
and time zone to use the following day, without schedule hits due to some
forgotten oversight. Checklist items span both design progress -- such
as LVS/DRC clean or variation-clean -- and verification progress.
This example below shows some digital IP verification check list items:
Survey respondents were asked which of the verification checklist items
above their organizations would find valuable for engineering and management
to be able to readily access and view. The respondents each chose an
average of 6 items as important to monitor, with the items spanning the
entire list above.
As another example, a digital or analog physical designer might work with
some of the following checklist items:
- Variation-clean
- Hold time margins for specified corners
- DFM quality score
- LVS/DRC clean
- Power grid distribution
- Performance versus yield curves
An IP reuse system must be flexible enough to accommodate an individual in
an organization desire to select their own checklist items, and whether the
overall organization wishes to monitor the entire list or just to enforce
certain items.
6. Roll-up Reporting
This dependency management technology infrastructure can automatically
deliver IP usage and bug roll up reports for the assembled design without
having to copy the bug report into each chip project, or scripting and
maintaining a complex or reverse tracking methodology.
Additionally, other management metrics such as power consumption can be
added. The reports allow for quick "what if" analysis by management at
the project and IP levels.
- Dean Drako
IC Manage, Inc. Campbell, CA
---- ---- ---- ---- ---- ---- ----
Related Articles
New data from 372 engineers and managers surveyed on real IP reuse
And some more survey data on verification headaches and IP reuse
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
|
|
