OpenAccess

[Suresh Jeevanandam]

Hi all,
I am seeking some info/comments on the migration to OpenAccess from
CDBA (DFII?).

Q's.
Q1. What does OpenAccess mean to the end user (Schematic/Layout designer)?

Q2. Can the layout/schematic designs in the current format be
viewed/edited after migration?

Q3. What are the advantages of the migration?

Q4. How is the scripting environment? I know there is a python binding
for OpenAccess. But is that as simple as Skill. (I personally like
programming in python. I can expect a huge time reduction in the
development time of scripts.)

Q5. Other interesting things that you may want to share...


regards,
Suresh

 

[Prashanth Konda]

Suresh,

I am not an OpenAccess expert but I'll try to address some of your
questions.

Q1. What does OpenAccess mean to the end user (Schematic/Layout designer)?
Open Access (OA) is a new database format for EDA tools that's different

from the Cadence proprietary database format, CDBA. Cadence DFII environment
is available on both CDBA and OpenAccess. For the end user the tools and the
GUI are the same. It's only the underlying database structure that's
different. For eg. on CDBA, your data is stored as layout.cdb whereas on
OpenAccess, the data is stored as layout.oa.

Q2. Can the layout/schematic designs in the current format be
viewed/edited after migration?
Once you convert your existing libraries to OA, you'll be able to view/edit

them using the DFII on OA software. On downloads.cadence.com, you'll find
separate IC releases for CDBA and OA.

Q3. What are the advantages of the migration?
Capacity:OA has much larger capacity than CDBA.

Speed: Much faster than CDBA. (opening a huge layout on CDBA could take a
long time, where it takes less time to open it on OA)
Interoperability: Since OA is governed by the Si2 Committee, and is open
source, design data can be exchanged easily between different EDA tools, if
they have hooks to OA.

Q4. How is the scripting environment? I know there is a python binding

for OpenAccess. But is that as simple as Skill. (I personally like
programming in python. I can expect a huge time reduction in the
development time of scripts.)
I am not familiar with python. If you are talking about migrating your

existing CDBA data to OA, there's a migration process you can follow which
is very well documented and also you can get help from Cadence AEs

Q5. Other interesting things that you may want to share...
If you have not see it already, there's an OA article at

http://www.cadence.com/partners/industry_initiatives/openaccess/index.aspx
which has links to the OpenAcess coalition website.

Regards,
Prashanth


"Suresh Jeevanandam" <sureshjeeva@DELETETHISindia.ti.com> wrote in message
news:cdg16q$bvq$1@home.itg.ti.com...

Hi all,
I am seeking some info/comments on the migration to OpenAccess from
CDBA (DFII?).

Q's.
Q1. What does OpenAccess mean to the end user (Schematic/Layout designer)?

Q2. Can the layout/schematic designs in the current format be
viewed/edited after migration?

Q3. What are the advantages of the migration?

Q4. How is the scripting environment? I know there is a python binding
for OpenAccess. But is that as simple as Skill. (I personally like
programming in python. I can expect a huge time reduction in the
development time of scripts.)

Q5. Other interesting things that you may want to share...


regards,
Suresh

 

[Jim Newton]

Q4. How is the scripting environment? I know there is a python binding
for OpenAccess. But is that as simple as Skill. (I personally like
programming in python. I can expect a huge time reduction in the
development time of scripts.)

The programming environment is still SKILL if you are working
inside the Cadence Design Framework.

But if you want to write a stand alone application separate from
the design framework, then you can use python or C++
or any other language for which the API is ported. But
those programs cannot be used inside of icfb or inside assura
or inside dracula or inside spectre or any other Cadence tool.

Furthermore if you want to write a Python program to modify
the OA data base, you'll have to negotiate locks with icfb,
in the same way that if two icfb sessions are running
trying to modify the same data base. One process will
be able to write and the other will see the files locked
and won't be able to open in write mode.

-jim

 

[John Gianni]

Suresh Jeevanandam <sureshjeeva@DELETETHISindia.ti.com> wrote in message news:<cdg16q$bvq$1@home.itg.ti.com>...

I am seeking some info/comments on the migration to OpenAccess from
CDBA (DFII?).
Q1. What does OpenAccess mean to the end user (Schematic/Layout designer)?

In summary:
Your DFII on OpenAccess tools will work the same as your DFII on CDB tools.
Your ability to read & write DFII data in a DIGITAL flow will be enhanced.
Your ability to use third-party tools with DFII will also be enhanced.
Also, some new tools such as the Virtuoso Chip Editor are available ONLY on OA.

Q2. Can the layout/schematic designs in the current format be
viewed/edited after migration?

Yes.
Your DFII designs & design kits will look & behave the same in DFII
on OpenAccess as they did in DFII on CDB. In the same project directory,
we keep a directory called "design/custom_oa" and "design/custom_cdb"
where we start DFII on OpenAccess or DFII on CDB respectively. (We also
keep a directory called "design/digital" where we start SOC Encounter.)

The DFII on OpenAccess & DFII on CDB data looks so similar that we've
found we constantly accidentally use the wrong executable; hence we've
requested & received an excellent error message which says, in effect:
"You just tried to open CDBA data with an OpenAccess executable."
"Choose a CDBA executable to open CDBA data (& vice versa)."

Q3. What are the advantages of the migration?

See A1 to Q1 above.

Q4. How is the scripting environment? I know there is a python binding
for OpenAccess. But is that as simple as Skill. (I personally like
programming in python. I can expect a huge time reduction in the
development time of scripts.)

The SKILL scripting environment to DFII is the same with DFII on OpenAccess
as it is with DFII on CDB. Where there are differences, they are noted in
the latest printing of the DFII SKILL Quick Reference (available from your
sales team). This SQR (11th printing, Cadence-orange cover) also contains the
SKILL access to CDB and SKILL access to OpenAccess datamap foldouts.

Q5. Other interesting things that you may want to share...

Interesting ... to whom? Here is what is interesting to me:

The custom ic flow engineering team has been building designs on DFII in
OpenAccess for more than a year now. We create designs just like you do.

Our team members are scattered around the world and our parts are varied
(RF, analog, mixed-signal, digital, memory, I/O, etc.) Many flow issues
come up (rest assured) - but relatively few OpenAccess-specific issues arise.

Those that do, we resolve in the software (so you don't have to). Items
like asymetrical 90nm & 65nm vias arose (& were resolved in IC5033USR2).

DBUperUU issues arose in the beginning, solved with the new XScale utility.

Issues about migration with digital vias arose recently and are being
worked on as we speak (use LEF/DEF for migration of active digital instead
of the cdb2oa executable). etc. All of these were found & resolved using
existing design practices (just like you use) by the flow engineering team.

That's my philosophy. Do things like you do. Define the flow that works.
Fix the flow that doesn't. To do this, all we need are designs & kits.

We have simple designs (two inverters) & complex designs (40-million xtors)
which go from the Virtuoso Editor (aka Composer) to Virtuoso Preview to
Virtuoso Chip Assembly Router (aka CCAR) to SOC Encounter, to Virtuoso Chip
Editor, to Assura (and back for parasitic re-simulation) all on OpenAccess.

We used to use industry standard kits, but, now we build our own (they
need to contain pcells, CDFs, symbols, schematics, abstracts, techfiles,
LEF technology & macro files, memory complers, tool-specific technology
files such as QTrek, NeoCell, VoltageStorm, etc., standard cells, verilog,
rule decks, OA layout, CDB layout, model files, etc.). Just like you do.

In short, we try to work the flow before you even receive the latest tools.
We try to do what you do (build kits & chips). In doing so, we've designed,
tested, and laid out complete PLLs, ADC's, LNAs, Mixers, OpAmps, DACs,
Ethernet Phys, Leon CPUs, MACs, DMAs, VGA controllers, EIDE controllers,
TDES encryption, USB 2.0 devices, etc. (many of which were shown at DAC
2004 in the platform suites). All that will fewer than 5 full-time equivalents!

In summary, for the most part, you won't notice any negative effects while
working with DFII on OpenAccess data vs working with DFII on CDB data. If
you do ... let us know

John Gianni
--
Every statement including this one on this newsgroup is a PERSONAL opinion!
No post is a company statement from my employer.

 

[fogh]

Prashanth,

Prashanth Konda wrote:

Interoperability: Since OA is governed by the Si2 Committee, and is open
source, design data can be exchanged easily between different EDA tools, if
they have hooks to OA.
OA is not open source. The consensual definition of the term is from OSI http://www.opensource.org/docs/definition.php

I hope it becomes open source someday, but that is unlike the evolution it had seen since it s announcement.

 

[fogh]

John,

this is music !
There maybe only 5 FTE's at cadence, but feedback on usability is certainly easy to get from cadence customers.
If cds would broadcast a questionary on usability that is flexible and open enough, and does not use rude and off-putting words like "leverage", you could get material that will keep 5 FTE skill gurus busy few a few months.

John Gianni wrote:

Suresh Jeevanandam <sureshjeeva@DELETETHISindia.ti.com> wrote in message news:<cdg16q$bvq$1@home.itg.ti.com>...

I am seeking some info/comments on the migration to OpenAccess from
CDBA (DFII?).
Q1. What does OpenAccess mean to the end user (Schematic/Layout designer)?


In summary:
Your DFII on OpenAccess tools will work the same as your DFII on CDB tools.
Your ability to read & write DFII data in a DIGITAL flow will be enhanced.
Your ability to use third-party tools with DFII will also be enhanced.
Also, some new tools such as the Virtuoso Chip Editor are available ONLY on OA.


Q2. Can the layout/schematic designs in the current format be
viewed/edited after migration?


Yes.
Your DFII designs & design kits will look & behave the same in DFII
on OpenAccess as they did in DFII on CDB. In the same project directory,
we keep a directory called "design/custom_oa" and "design/custom_cdb"
where we start DFII on OpenAccess or DFII on CDB respectively. (We also
keep a directory called "design/digital" where we start SOC Encounter.)

The DFII on OpenAccess & DFII on CDB data looks so similar that we've
found we constantly accidentally use the wrong executable; hence we've
requested & received an excellent error message which says, in effect:
"You just tried to open CDBA data with an OpenAccess executable."
"Choose a CDBA executable to open CDBA data (& vice versa)."


Q3. What are the advantages of the migration?


See A1 to Q1 above.


Q4. How is the scripting environment? I know there is a python binding
for OpenAccess. But is that as simple as Skill. (I personally like
programming in python. I can expect a huge time reduction in the
development time of scripts.)


The SKILL scripting environment to DFII is the same with DFII on OpenAccess
as it is with DFII on CDB. Where there are differences, they are noted in
the latest printing of the DFII SKILL Quick Reference (available from your
sales team). This SQR (11th printing, Cadence-orange cover) also contains the
SKILL access to CDB and SKILL access to OpenAccess datamap foldouts.


Q5. Other interesting things that you may want to share...


Interesting ... to whom? Here is what is interesting to me:

The custom ic flow engineering team has been building designs on DFII in
OpenAccess for more than a year now. We create designs just like you do.

Our team members are scattered around the world and our parts are varied
(RF, analog, mixed-signal, digital, memory, I/O, etc.) Many flow issues
come up (rest assured) - but relatively few OpenAccess-specific issues arise.

Those that do, we resolve in the software (so you don't have to). Items
like asymetrical 90nm & 65nm vias arose (& were resolved in IC5033USR2).

DBUperUU issues arose in the beginning, solved with the new XScale utility.

Issues about migration with digital vias arose recently and are being
worked on as we speak (use LEF/DEF for migration of active digital instead
of the cdb2oa executable). etc. All of these were found & resolved using
existing design practices (just like you use) by the flow engineering team.

That's my philosophy. Do things like you do. Define the flow that works.
Fix the flow that doesn't. To do this, all we need are designs & kits.

We have simple designs (two inverters) & complex designs (40-million xtors)
which go from the Virtuoso Editor (aka Composer) to Virtuoso Preview to
Virtuoso Chip Assembly Router (aka CCAR) to SOC Encounter, to Virtuoso Chip
Editor, to Assura (and back for parasitic re-simulation) all on OpenAccess.

We used to use industry standard kits, but, now we build our own (they
need to contain pcells, CDFs, symbols, schematics, abstracts, techfiles,
LEF technology & macro files, memory complers, tool-specific technology
files such as QTrek, NeoCell, VoltageStorm, etc., standard cells, verilog,
rule decks, OA layout, CDB layout, model files, etc.). Just like you do.

In short, we try to work the flow before you even receive the latest tools.
We try to do what you do (build kits & chips). In doing so, we've designed,
tested, and laid out complete PLLs, ADC's, LNAs, Mixers, OpAmps, DACs,
Ethernet Phys, Leon CPUs, MACs, DMAs, VGA controllers, EIDE controllers,
TDES encryption, USB 2.0 devices, etc. (many of which were shown at DAC
2004 in the platform suites). All that will fewer than 5 full-time equivalents!

In summary, for the most part, you won't notice any negative effects while
working with DFII on OpenAccess data vs working with DFII on CDB data. If
you do ... let us know

John Gianni
--
Every statement including this one on this newsgroup is a PERSONAL opinion!
No post is a company statement from my employer.

 

[John Gianni]

Suresh Jeevanandam <sureshjeeva@DELETETHISindia.ti.com> wrote in message news:<cdg16q$bvq$1@home.itg.ti.com>...

I am seeking some info/comments on the migration to OpenAccess from
CDBA (DFII?).

In addition, I suggest a simplified database structure similar to:
~/PROJECT/<NAME-of-CHIP>/{design,share,doc}

In the "design" directory tree, I suggest a simplified hierarchy of:
design/{custom_cdba,custom_oa,digital,data}

I suggest starting all the OpenAccess-based custom tools in "custom_oa";
run all the CDBA-based custom tools in "custom_cdba"; and execute all
the digital tools in "digital" (whether they are OA-based or not).

For example:
% cd ~/PROJECT/EAGLET/design/custom_oa
% cdsLibDebug -cla (i.e., check your libraries & lib paths)
% clsAdminTool -ale .(i.e., check for extraneous lock files)
% cds_root icfb (i.e., check for a good installation hierarchy)
% translate -c myLib (i.e., defragment to gain 20% VM & disk perhaps)
...
% icfb &

Note: While CDBA data usually gets defragmented 20% weekly (or so);
I'm told there is never a need to defragment OpenAccess data:
CIW: File->Defragment library->myLib

Once inside the tool-starting directories, I suggest a WORK directory
containing run files for Assura, Spectre, VCAR, Diva, Dracula, etc., e.g,:
~/PROJECT/EAGLET/design/custom_oa/WORK/{AMS,AV,CDL,DIVA,EDFM,NEO,PIPO,SNA}

Note: Some folks like to store the artist_states as a cellview inside the
design data directory (either OpenAccess or CDBA design data).

I suggest storing actual design data OUTSIDE the tool-starting directory,
but inside the design directory, e.g.:
~PROJECT/EAGLET/design/data/{oa,cdb,cdl,def,lef,rtl,gds2,cdump}

Likewise, in the share tree I suggest storage of foundry-supplied files:
~PROJECT/EAGLET/share/{il,gpdk045,gsclib045,giolib045,gmemlib045}

A CAD or DESIGN group may not control the underlying structure of the share
hierarchy; but I suggest keeping the OA data separate from CDBA as in:
~PROJECT/EAGLET/share/gpdk045/{libs.oa,libs.cdba,models,lef,tf,sna,pv,il}
~PROJECT/EAGLET/share/gsclib045/{oa,cdba,gds,gds,lef,net,lib,vlog,doc,bin}
~PROJECT/EAGLET/share/giolib045/{oa,cdba,gds,gds,lef,net,lib,vlog,doc,bin}
~PROJECT/EAGLET/share/gmemlib045/{oa,cdba,compiler,characterizer}

Note: g === generic (i.e., not targeted to any specific foundry)

In short, by necessity, in a complete design kit - the process design kit,
standard-cell libraries, I/O libraries, memory libraries, & even the designs
(at times) may have mixed OpenAccess & CDBA hierarchies (+ LEF/DEF/RTL,etc.).

I suggest users plan for mixed oa & cdb hierarchies with a well-thought-out
directory tree (a place for everything & ...) & which specifically keeps
OpenAccess & CDBA data separate, but close by (logically).

John Gianni
--
Absolutely nothing I say on the USENET has prior sanction by my employer!

 

[John Gianni]

Suresh Jeevanandam <sureshjeeva@DELETETHISindia.ti.com> wrote in message news:<cdg16q$bvq$1@home.itg.ti.com>...
I am seeking some info/comments on the migration to OpenAccess from
CDBA (DFII?).

Another cdba-to-openaccess migration suggestion is, for now, to
migrate the custom CDBA data to OpenAccess using the cdba2oa
translator, from the bottom (reference libs) up.

Then, migrate all pure digital blocks using LEF/DEF import, either
into the digital tools (e.g., SOC Encounter) which can save OpenAccess
directly, or into the custom-IC tools (e.g., DFII, aka "Virtuoso")
which will easily create OpenAccess files & OpenAccess technology
files upon import of LEF/DEF.

Depending on the low-level data format supplied for the standard-cell
library (i.e., GDSII or CDBA or OA layout), you may also cdb2oa these
standard cell layouts from CDB to OA (or use the really fast XStream
OpenAccess PIPO replacement if warranted).

We've done these steps many times and it works quite well for the RF,
analog, mixed-signal, digital, memory, & I/O components we've thrown
at it over the past year or so.

John Gianni
--
The email address above is a spam trap; nothing sent to it will be
read by me.

 

[Keith S.]

John Gianni wrote:

We have simple designs (two inverters) & complex designs (40-million xtors)
which go from the Virtuoso Editor (aka Composer) to Virtuoso Preview to
Virtuoso Chip Assembly Router (aka CCAR) to SOC Encounter, to Virtuoso Chip
Editor, to Assura (and back for parasitic re-simulation) all on OpenAccess.

Interesting. We put a demo together for DAC last year, writing
an OpenAccess database using SoC Encounter, reading it with
our tools, doing stuff on it, then writing out a new OA database.
We found Encounter couldn't read the resulting database.

Turns out Encounter requires 'other' stuff in the OA cellview
directory, and refused to read the database if this stuff
wasn't there. I don't know if this has been fixed, but it
kind of makes a mockery of the supposed interoperability
benefits of OA.

The other question I'd be interested in an answer is how DF2
based pcells can be handled (if at all) by non-DF2 OA applications.
The OA documentation on pcells says very little about this.

- Keith