Best text exporting for archiving purpose

If I want to export cdb library to text format for archiving, so it
would be possible/easy for me to look at a specific part or to search
something with text tools in the future when I don't need a full access
to Cadence environment. This may also serve the purposes of CVS
archiving. Which text format is the best to choose, DEF, EDIF or you
name it?

Ming

 

You may consider using the command "dbWriteSkill()" which translates
any database in text SKILL, so you may retreive 100% equivalent
database if your reload later this SKILL.

================
Kholdoun TORKI
http://cmp.imag.fr
================

 

This works for most things, but I recall a few gotcha's:

Pcells
connection or contact Pcells
complex arrays
CDF info.
Tech file info

This type of info requires a bit more than dbWriteSkill().
(actually slighlty different commands for some, special licenses for others)
I recall that my last company had automated all of this!

And then you use a simple ascii version
control system and a (not so simple) set
of makefiles and build scripts to rebuild
your library(s)!

YMMV

-- Gerry Vandevalk -- www.ictooling.com "Making Smarter Layouts "

 

Gerry,

I believe you need to add the "bags", property bags, as well.

About the version control system: did it provide a way to annotate
differences on schematics ?

 

Yup. bags are also problematic. (and groups, and many other rarely used
skill & artist things)

We made no effort to annotate differences. Essentially we built a simple
superset of basic/analogLib and a few others ... just to protect ourselves
when
cadence "improved" things in these cells. These were just for schematic
symbols.

Then for each physical library we would create a new set of cells that were
specific to
the given technology.

We then updated the masterSchematic library devices to reference the right
layout devices
with some careful netlisting and property updates.

In this environment we expected vedry little change in the symbols. (in fact
we enforced a policy
of never removing/renaming pins.) If pin changes were necessary, a new named
device was created.

This technique, along with the skill dump and tableRename() capability, let
us create technology
independant schematics. We also created a skill based moveLayers()
capability that let us morf
layouts from one technology to another.

(This, of course, overlooks the many gotcha's that such a system had. We
were able to get around and
avoid most, and learned how to hand-hold & code around the rest!)


;^( Too bad this COT tooling system was mothballed and is no longer in
use )^;

 

I would NOT recommend using dbWriteSkill for archiving purposes.

It is primarily for disaster recovery - and (originally) for getting data back
from 4.4 to 4.3.4.

Archive the original databases; we've provided tools in the past to upgrade
the databases to newer versions (from Edge to Opus, from 4.3.4 to 4.4, from
CDBA to OA) on the relatively rare occasions where the database changes (at
least not in a minor way, and then the database version can be up-revved).

More likely to cause you trouble is the design kit that you're using, and that
would be because of SKILL changes (much less common these days due to the
processes that we've put in place to ensure public functions are kept
compatible from release to release where possible), or more likely because:

a) the PDK checks what version it is running, and barfs if a later version is
used.
b) the PDK loads a context file containing the SKILL code, and that context
file is not valid in the specified version.

So normally what you'd do is either get hold of a new PDK version which
supports the version being restored from archive (best solution), or you
should archive the actual software version used on the design as well as all
the data.

Andrew.

 

ah! A robust set of wrappers for analog reuse and synthesis... with all
the right buzzwords it should have been a success. Victim of the bad times ?
At least you had the guts to try. I would not have dared.
The tool is maybe scrapped, but the experience stays. You can one day
become the yoda of PDK templates & layout migration