( ESNUG 520 Item 4 ) -------------------------------------------- [03/07/13]
From: [ Dean Drako of IC Manage ]
Subject: 10 design and verification "best practices" for IP Reuse 2.0 today
Hi, John,
Below are 10 best practices an engineering group can do today to get closer
to my IP Reuse 2.0 vision which I described earlier. It involves high reuse
of both your design and verification assets; plus interdependencies between
team members in local and remote sites across your enterprise.
This list is based on what IC Manage has seen from several semiconductor
companies most successfully maximizing IP reuse, including many of our
customers. Most of these practices apply to IP-based design in general,
while some are specific for IP with reuse potential.
Partitioning into functional modules, sets up for cleaner development and
easier functional verification.
The project manager or chip lead creates an initial partitioning structure,
and then assigns the design modules to individual designers or teams. This
practice establishes the various design modules as IP blocks, even when
their current reuse potential is not yet known.
In defining the design modules in anticipation of optimal reuse, the chip
lead must strike a balance between:
- creating small modules, which have high flexibility as they will
not be further split during reuse,
and
- ensuring that each IP block contains a critical mass of
functionality, so it can be reused on its own under certain
conditions rather than always needing to be combined with
other modules.
A well partitioned design is a dream to reuse; a poorly partitioned design
is a nightmare to reuse.
Set up the IP block organization by data type, such as including HDL, SPI,
LIB, LEF/DEF, SPF, and GDS, and not by file system naming or hierarchies.
This gives developers an infrastructure in which to place their data files
and sub-directories rather than using ad-hoc trees which may be difficult to
package or release. Data type partitioning also allows engineers to easily
extract specified data types, such as "Verilog and .LIB only".
Import or link internal IP data from other repositories into a single
repository, to provide a single view of all your IP assets. Use scripts or
other automated mechanisms to check-in, map, or import all IP -- both new
and legacy -- according to the partitioning and data type structures
discussed above.
Entering 3rd party IP into the same repository structure allows an easier
integration of it into your existing design flows. It'll be easier to track
and verify any changes to your project associated with updates that come
from the external vendors.
An IP block without a comprehensive and complete test is of limited use.
Some basics to consider in developing a reusable test bench are: Build an
open environment, using basic UNIX tools, keeping it simple with limited
scripting, and keep to industry-standard languages and tools.
By encapsulating all properties and data associated with the IP, so that
they always travel together, you eliminate manual tracking and the errors
associated with it -- including lost or out-of-date data.
Integrate your IP repository into one or more bug tracking systems from
the start, if a bug tracker is not already embedded in the IP logistics
management system. Doing this step from the beginning ensures that all
identified bugs and bug fixes associated with each individual IP block
are automatically recorded in both the bug tracking system and the IP
repository. This close linkage allows design and verification teams to
view and trace the bug history for every IP they work with across all
versions and designs.
Use traceable branching, so that each IP version can be separately and
independently tracked. This practice replaces creating physical copies of
different IP versions in multiple repositories, leading to unrecognized or
orphan copies whose usage is unknown.
Advanced branching with history tracking allows your top level chip assembly
teams to work with stable or released versions of each IP module; while your
design and verification teams continue to work on the IP and chip.
Encapsulate all relevant property data associated with each IP element into
the IP repository, such as the information I showed earlier.
As the IP development and verification process progresses, members of the
design team involved with the IP can mark or flag its status, based on rules
or metrics associated with the property list. Quality or verification
metrics can also be imported or linked from 3rd party tools.
In combination, these steps allow managers to measure progress against
specific milestones such that certain property groups go from "incomplete"
to "in progress" to "pass". Further, just having the checklist can improve
conformance to methodologies, such as preventing remote organizations from
submitting an IP element to another region, only to find out that a key
step was missed, and a workday lost.
It is a best practice to merge new or changed IP code into the IP repository
with sufficient frequency so that other designers and verification engineers
collaborating on the design or IP can notice errors and begin correcting
them immediately. It should be easy for all team members to view the latest
deliverables and changes. Management should be able to get instant
snapshots for decision-making purposes.
Continuous integration forces ongoing team member communication, reduces the
number of conflicts, and accelerates resolution. In contrast, delayed or
only periodically-scheduled check-ins can make it more difficult to resolve
development conflicts.
A close linkage between the bug tracking and design management systems
discussed earlier allows the IP changes associated with bug fixes to be
viewable in the bug tracking system; and the bug history viewed in the IP
repository. Further, chip and IP designers should automatically be notified
of any new bugs identified as well as the bug status.
Maintaining the relationships between the original IP and its derivative
versions allows for the automatic or selective propagation of IP bug fixes
in both directions -- parent-to-child or child-to-parent -- depending on the
policy. This practice also allows the chip integration lead to mark the IP
blocks as 'finished', then decide whether to let them stay finished after
reviewing the bugs for a particular release.
This methodology allows the mix-and-match of different revs of the same IP
in different blocks, without having to respin all blocks to the newest rev.
- 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
Dean Drako posits his design and verification IP Reuse 2.0 vision
The Show-Me-The-Money IP Reuse 2.0 ROI and what IC Manage does
Join
Index
Next->Item
|
|
