( ESNUG 539 Item 5 ) -------------------------------------------- [05/08/14]
Subject: 15 gotchas found in Design and IP data management tools (part II)
From: [ Dean Drako of IC Manage ]
Hi, John,
The items 5 to 15 here below in this (part II) are the deep details of
a DM system.
5. Bug Dependency Management
6. IP Reuse Support
7. Project Management & Status Reporting
8. Check-List Driven Acceptance Flow
9. Linking/Importing IP & Design Data From Other Systems
10. Properties Encapsulated In IP
11. Global Data Consistency / Local Caching
12. Metadata Consistency / Reliability
13. Atomic Transactions
14. R&D Continuity Despite Remote Network Disruptions
15. Granular Security
I advise reading (part I) the "nuts and bolts" in ESNUG 539 #4 before
reading these details.
- Dean Drako
IC Manage Campbell, CA
---- ---- ---- ---- ---- ---- ----
5. BUG DEPENDENCY MANAGEMENT
Bug dependency management is the ability to identify the impact of a bug or
bugs across shared, reused, and derived design components.
DM integration with bug tracking systems
HW development teams track bugs and bug fixes using various 3rd party tools
such as Jira, Bugzilla, or internally developed systems.
Integration between a bug tracking system and a DM system ranges from no
integration, to unidirectional, or to full bidirectional linkage.
- Uni-directional DM/bug tracking integration, a binding is created
in the bug tracker to the set of files that were changed to fix a
particular bug, or ECO. This allows you to browse the bug data
within the bug tracking system and also see the file differences
for fixes that were applied to resolve them. However, the DM
system has no knowledge of the bug data.
- Bi-directional DM/bug tracking. The bugs and bug fixes associated
with each design element or IP block are automatically recorded in
both the bug tracking system and in the DM system. This means you
see the design information in the bug tracker along with the bug
and fix information in the DM system on a per file basis.
Further, the DM system records the bug information and binds it to
the file-tree state. This allows you to browse the bug data not
only within the bug tracking system, but also to perform workspace
synchronization for the different bug life cycle states directly
in your DM tool.
Bug tracing and Fix Propagation
I wrote about inter-file branching and bi-directional bug tracking in a
prior DeepChip letter in ESNUG 520 #3:
"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."
- from http://www.deepchip.com/items/0520-03.html
Controlled automation of these "bug interdependency management" steps can
also prevent inadvertently taping out with a known bug.
The alternative is to manually clone bugs for every derivative (or shared)
component.
---- ---- ---- ---- ---- ---- ----
6. IP REUSE SUPPORT
Our 2013 survey ESNUG 520 #1 showed that 44% of non-memory design involved
internal IP reuse. A company's ability to make its internal IP readily
available for reuse by all design teams is critical for competitiveness.
Splitting. A single IP repository (data storage location) allows your HW
design team to maintain the relationships between design files that would
otherwise be lost if split across multiple repositories. And although
splitting repositories is painful, unless your reuse database scales to
large file and directory accounts, 1000's of users, and 1,000,000's of
concurrent connections, splitting is inevitable to maintain functionality
and performance.
Tracing IP history. You maximize IP reuse if your DM system can trace where
your IP is being used across projects (designs-products), subsystems, and
by which users. Further, companies like to see how individual IP evolves
over time, in terms of design content and quality.
- A change-based DM system lets engineers see who made what changes
and to trace the history over time. For example, if someone
modified the IP, they may have changed it to a 32-bit bus, added
pipelining, and targeted a different process.
- A file-based systems makes duplicate physical copies of the IP.
The big drawback here you lose reliable, automated traceability.
The designer must first search the repository - or multiple
repositories - to find the IP copies, and then manually
determine the differences.
Searching for IP. Does your DM system publish your IP based on its
characteristics such as target process, power consumption, max frequency,
silicon validation, area? Can you also search using quality metrics like a
quality checklist status, passing functional verification, physical DRC/LVS
verification, number of open bugs, etc.?
---- ---- ---- ---- ---- ---- ----
7. PROJECT MANAGEMENT & STATUS REPORTING
In addition to managing your design data, engineering managers also want to
be able to track design activity. This requires first setting up your
project for efficient management (see "2. Configuration Management") and
then having visibility at the project/design-level to see what design
modules have been checked in and out, and how often.
Managers also want status reports and analysis, often daily. If the project
is not converging, they will then want more granular status reporting so
they can to drill down to determine which design/IP blocks are causing a
problem or project delay.
Does your DM system do this for you, and to what degree? Many DM systems
require groups to fill out spreadsheets manually to do status updates. This
in turn involves manual and error prone tasks of extracting up-to-date
information from already overburdened design team members.
One example of this that the U.S. Army, Navy, Air Force, and Marines each
have their own inventory systems for ammunition which can NOT share data
directly -- even though they have worked for decades to develop one single
database.
"A request for ammunition from the Marine Corps, for example, is
e-mailed to the Army. The e-mail is printed out and manually
retyped into the Army system because the services cannot share
data directly. Not only is this time consuming, but it can
introduce errors -- by an incorrect keystroke, for example."
- USA Today (04/28/14)
If the meta-data (e.g. revision data) in your DM system is captured in a
consistent, accurate way, your project leads will be happy. Why? Because
it means they can automatically generate reports and do trend analysis at
the top-level, plus readily see at a glance the project status of all IP
and subcomponents -- covering IP quality, open bugs and tapeout readiness.
They can even graph the trend of these metrics from version to version.
---- ---- ---- ---- ---- ---- ----
8. CHECK-LIST DRIVEN ACCEPTANCE FLOW
Last year's 2013 IP Reuse study ESNUG 520 #1 referenced a growing practice
for engineering groups to set up a formal process for IP development and
verification, with checklist items to track and monitor on each block; thus
tying the relevant status information of all the IP used to continuously
gauge the project's progress. A check list can apply to each stage of
design and verification to be passed.
These individual checklist guidelines can be enforced loosely or strictly,
depending on your company need. It can be for any design component.
This will encourage certain steps to be taken; for example, when a remote
design group checks in an IP, it's ready for a team at a different site and
time zone to use it the following day -- without schedule hits due to some
forgotten oversight. It also allows better quality control and visibility
into design progress, and correspondingly, the ability to assign resources.
Does your DM system directly integrate checklists? With automatic updates
tied to each design element? Or is it done outside the system by hand on
an Excel spreadsheet? And for for IP reuse: is the state of your design
checklist directly linked to the state of your IP, so that it's always
up-to-date?
---- ---- ---- ---- ---- ---- ----
9. LINKING/IMPORTING IP & DESIGN DATA FROM OTHER SYSTEMS
Our 2014 Design and IP Management survey (ESNUG 539 #1) showed that 55% of
companies have at least two different DM systems. Further, the majority
of those with multiple DM systems want better integration between them.
(One example is when a digital design team wants to use design elements
from the analog team.)
One approach to have different DM systems "talk" is to use a virtual tree
design. In such a system it is possible to perform multi-DM-system
configuration management by mapping individual DM system tree structures
into the virtual representation. Users can then register bindings into
the virtual object (protocol, authentication, tree structure, release info)
which allows users to pull content from multiple DM systems in a
transparent manner.
Another method is to manually copy your design data from your source DM
system and check it into your destination DM system. A drawback is that
designers then lose the link to the active design status, breaking the
audit trail.
---- ---- ---- ---- ---- ---- ----
10. PROPERTIES ENCAPSULATED IN IP
By encapsulating internal and 3rd party IP properties hierarchically and
organizing them in an easily searchable manner, everyone has immediate
access to all your IP's data, metadata, constraints and design history
all in one place. To encourage verification reuse, verification info
like testbenches, assertions and results, can also be encapsulated.
Because IP evolves dynamically over time -- often in parallel with chip
development -- it should be continuously updated.
Does your DM system allow you to encapsulate IP properties or design status
data? If yes, can it maintain the inherited hierarchy for the properties?
---- ---- ---- ---- ---- ---- ----
11. GLOBAL DATA CONSISTENCY / LOCAL CACHING
Global data consistency means everyone on the same project has access to all
versions of the same files plus its latest versions.
The way DM infrastructures try to get this desired result varies.
Mirrors. Some DM systems use mirrors -- or repository replicas -- for data
availability at remote sites. A drawback is that the mirrors can get out of
sync so that your master file content diverges from the remote site content;
that is, you get different results when trying to access the latest version
of a file.
With mirrors, there is an inherent synchronization overhead to ensure that
different teams get the same file version. The more mirror sites, the more
complicated this becomes and the greater the risk of error.
Caching. Some DM systems do global consistency by having a single server
maintain one global point of reference for versioned metadata and user
workspace contents. This type of DM system must use local caching to
deliver copies of design file data consistently and it must run quickly
across multiple sites.
The design file data is stored at remote sites in a local cache, while the
revision control metadata is stored at the master site. Remote queries to
the metadata should be fast since those involve a small number of network
packets. This approach also eliminates synchronization problems, even with
multiple servers.
---- ---- ---- ---- ---- ---- ----
12. METADATA CONSISTENCY / RELIABILITY
Does your DM system have a single distinct metadata repository that works
at both the IP and project level?
The goal of capturing metadata in a consistent way during design module
development is so your DM system can automatically generate reports and
trend analysis at the top level on down.
For DM systems without a centralized meta-data repository, the project
leader would need to query the status of individual files and workspaces,
which can be extremely time consuming.
---- ---- ---- ---- ---- ---- ----
13. ATOMIC TRANSACTIONS
Atomic transactions mean that all database updates associated with a given
design change are executed -- or none are. Atomic transactions prevent
inconsistent database states, for example, in case of a network disruption
where a subset of necessary updates are completed. Atomic transactions
prevent this from occurring.
Atomic transactions are necessary to prevent data corruption, which can be
painful to unravel and recover from.
Virtually all DM systems claim "transactions". However, for individual-file
based systems, which don't understand "transactions" for groups of files,
the concept of an atomic transaction, is confusing at best and difficult
to implement in a reliable and consistent manner.
---- ---- ---- ---- ---- ---- ----
14. R&D CONTINUITY DESPITE REMOTE NETWORK DISRUPTIONS
To maximize 24/7 productivity, it is ideal that designers at remote sites
are able to continue to operate productively within their project.
Distributed server architectures can tolerate transient network disconnects
to the corporate network because both metadata and data are available
locally at the remote site. It is possible to sync to the last replicated
file version, as well as perform checkouts of existing files if the
connection to the central server is lost. Once the network connection is
restored, version records are automatically re-synchronized to prevent
data corruption and version conflicts.
---- ---- ---- ---- ---- ---- ----
15. GRANULAR SECURITY
From our survey this year, security issues with file-based DM systems were
a factor for 69% of designers. Companies want to protect their key assets
such as trade secrets and IP -- plus conform to export restrictions.
On security issues, a fundamental difference between DM systems is whether
your data is controlled at one central-server level, or from a user-
accessible file-server. Controlling sensitive data at a central-server
prevents it from being delivered to an area where it can be compromised.
Beyond this, DM capabilities may include granularity in exactly what is
protected -- for example: by file name, file extension, file type,
component, project, workspace, or release.
There can be also granularity to control actions, such as: create, modify,
delete, view, and project managers -- plus granting role-based security to
various team members.
---- ---- ---- ---- ---- ---- ----
Again, I must advise reading (part I) the "nuts and bolts" in ESNUG 539 #4
before reading these details above.
For my comparative table of the current known DM systems, please go to the
final item here at ESNUG 539 #6.
- Dean Drako
IC Manage Campbell, CA
---- ---- ---- ---- ---- ---- ----
Related Articles
SCOOP! - Dean Drako's design and IP management survey Infographic
Nitty-gritty details to that design and IP survey Infographic
What design and verification engineers want on global projects
15 gotchas found in Design and IP data management tools (part I)
15 gotchas found in Design and IP data management tools (part II)
Dean Drako on IC Manage, Subversion, DesignSync, ClioSoft, CVS
Join
Index
Next->Item
|
|
