( ESNUG 488 Item 9 ) -------------------------------------------- [03/25/11]
From: Henrik Ahrendt <hahrendt=user domain=gnresound.dk>
Subject: User writes on D/a, A/d, 3rd party IP, Virtuoso, and IC Manage GDP
Hi, John,
In the last 5 years, we've done over a dozen tapeouts using the IC Manage
Global Design platform (GDP) as our design management system.
We use GDP for our full chip designs, both analog on top (A/d) and digital
on top (D/a) chips. Our chips contain a combination of internal & external
IP, and they are all customized to be ultra, ultra low power chips for
hearing instruments.
I use IC Manage GDP from both a designer and a project manager standpoint,
so I can comment on it from both aspects. I want to share how we use GDP
for configuration management. A main advantage is it gives us one data
repository across all our designs, both digital and analog.
DIGITAL AND ANALOG DESIGN FLOWS:
Analog flow: Virtuoso, ADE, MMSim (AMS, UltraSim, Spectre).
Digital flow: Cadence Incisive and SimVision for simulation,
and Magma Talus.
When our digital chip is finished, with final GDS and gate netlist, we do a
sign-off using Cadence Assura. This has a double function. It does DRC
and design rules (e.g. polygon distance), and LVS (extracts devices and
connectivity in layout and compares it to source).
FILE TYPES:
D/a. Our digital assembly engineer needs:
- GDSII for final chip (hard macro)
- LEF for simple view for Magma Talus P&R
- .lib file for I/O timing of analog blocks
(we use black box models for analog IP)
A/d. Our analog assembly engineer needs:
- Virtuoso schematic and layout data. (CDB)
- Hard macros from our digital designers and
external IP providers
LIBRARIES:
We use GDP as our data container. We check everything into our own libs,
with scripts as needed. We organize everything into several lib types:
- Analog Design
- Analog Release
- Analog Testbenches
- PDK
- Digital Backend
- Flow
- Digital Design
- Tapeout
- External Packages
The "External Packages" are where we place 3rd party IP vendor source data
that we import. No one touches this library. Instead we manage scripts;
which take us from this source data to the target library. Details below.
USING IC MANAGE GDP TO MANAGE INTERNAL AND EXTERNAL IP:
We go through the same steps to import data into IC Manage from 3rd party
IP providers as we do to manage our internal design content and IP. We
just bring it into our library.
D/a flows:
We use external IP from Virage and ARM mostly for our D/a flow. Our IP
vendor deliverables consist of all the data we need for back end synthesis,
including .gds2, .lef and .lib, plus VITAL files, which combine
functionality at a behavioral level timing delay information estimating how
fast the IP will toggle, because we don't have full layout information.
A/d flows:
We don't use as much external IP for our analog flow, due to our low power
needs. As for file format compatibility, normally we get an analog netlist
and GDS2 file from our IP providers.
- We need to ensure we have the right pins and no global nets
- Certain syntax and statements the IP vendor provides in the netlist
can be confusing in Virtuoso.
- We get the 'whole' view from vendor, but not a schematic; so using
300 small cells would mean recreating 300 schematics by hand.
- We manage all this by doing scripting on the IP files to map the
original netlist into IC Manage library types; this ensures
compatibility as we incorporate the IP into our design.
As for updates, our internal IP is already under configuration management so
we don't need to do any further processing for revisions. If our external
IP vendor gives us an IP update, we do what IC Manage terms an 'offline
library update'. This overlays the IP vendor's update on the IC Manage
workspace, where we can use the ICM diff commands to see what was added,
edited or deleted. The original data will still reside inside the central
repository, and won't be overwritten with the updates. But if the vendor
finds out 10 files are not necessary, we don't want to see them anymore.
We use IC Manage's 'Import by Reference' feature, to map our libraries to
multiple projects. So when we 'reference' one or more libs, we point to a
single place in the repository. We only need to modify the component/IP
in one central place, as this 'import by reference' provides the module
or IP to all the specified locations. IC Manage then maps that library or
library set to multiple projects. We can see where the library is used
by the different projects so we have visibility into any changes made
through CLI commands.
IC MANAGE CHECK-IN/ CHECK-OUT PROCESS
Cadence Analog Interface
Without any doubt, GDP's integration with the Cadence analog tools is a
major strength for IC Manage. IC Manage's library manager looks just like
the Cadence library manager, except that it also has visual extensions for
revision control. GDP has the best analog integration on the market. It
just doesn't make sense to go to the shell or a separate menu every time
to manage revisions.
With GDP you can go back if you messed things up. It's easy to revert to
an old schematic. Instead of rolling back the schematic to a prior version,
you can open both versions at once and look at them. The integration is so
tight that our analog designers actually use the revision control. If
there are lots of changes to several libs, it's easy to get an overview of
what changed. You can set up submit triggers to control to enforce
check-in policies.
With GDP it's trivial for our designers to submit their work frequently.
It's push button, so there is no excuse not to. Instead of waiting 3 days
or a week, you can press "+" to selects every file you've been working
that day - then submit the changes into the repository all at once (atomic
transaction), or individually.
Prior to tapeout, the engineer-in-charge can see who has open files and who
needs to submit them, to ensure the right information prior to tapeout. IC
Manage's analog interface drove our initial use of GDP. Then it was so
beneficial to have one data container that we expanded our IC Manage use
to our digital flow.
Digital Interface
ICM GUI (ICMG) is IC Manage's digital interface. Digital is text files,
Verilog source, scripts, make files, and simulation results. Our designers
either use ICMG or the command-line interface, or the emac P4 integration.
ICMG is an easy way for people to get a hierarchical view, like a file
browser, of what's in the workspace. You can right click and get series of
commands: like edit, add, revert or submit. You can also use ICM diff to
view the deltas between 2 versions. ICMG is convenient if people don't
have good memory of the dozens of CLI commands. Easy to understand and
sufficient for daily use.
A big advantage is having same system for analog and digital, so we can
create a consistent configuration across our entire project. In addition to
consistency, this gives us better tracking and access control.
Performance
Our check-in and check-out performance is somewhat variable based on our
network load. As a rough estimate, a 1.5 Gigabyte project with 20,000 files
takes about 20 minutes to check out over our Ethernet with GDP. Since IC
Manage uses streaming TCP for data transfers, they don't incur an additional
individual file transfer overhead, but I do not have hard data to quantify
the actual impact on performance.
IC MANAGE GDP vs CVS:
As for the impact on project time, it's hard to quantify but I can comment
on a couple of aspects. Several years ago, before we had IC Manage, we
used CVS open source for basic revision control, which had some limitations
compared to GDP:
- It was much harder and more cumbersome to do check-ins with Virtuoso
using CVS. When you make that process difficult, often people let
things be and just don't check in.
- CVS had weird way of distributing .cvs catalogs all over, which
would pop up and interfere with our Cadence environment. We had
problem doing merges before tapeout. Several people worked on a
library, and we had lots of communication issues, such as determining
which files to archive. We wanted to make the archive of all 200 lib
files into 1 file and submit it to CVS. At one point our design was
working, then after a 1-2 day period where something went wrong, it
took us a full month to get back to a working config of our design.
We never face this problem with GDP since all the data is in one bucket.
Additionally, GDP allows us to work on different aspects of the design
concurrently and save time on merging data later.
- Henrik Ahrendt
GN ReSound A/S Ballerup, Denmark
Join
Index
Next->Item
|
|
