cdb vs OA

[tritue]

Hi all,

What will be the main different of CDB vs OA. What will be the future of
CDB. Will Cadence drop the CDB line in a near furture.
I saw a new release of OA but not for CDB. Should we prepare to convert to
OA.
TTT

 

[Bernd Fischer]

Hi,

With DFII version 6.0 or 6.0.1 or 6.1, or whatever the
next version after 5.1.41 and 5.2.51(OA) will be, Cadence will only
support OA 2.2 as database.
As far as I know 5.1.41 is the last release which runs on CDBA
database.
Nevertheless DFII 6.x first customer shipment will be sometime around
September 2006 and I would not use it before the first USR is out.
Because they changed not only the database model also 6.x is rewritten
with a different GUI library.

Although 5.2.52 is also based on OA 2.2 I think it's not intend to
use for production, just to do first database conversions test etc..
As from my experience I can also not recommend to use 5.1.41 OA 2.0 this is
a deed end street, because OA 2.0 support will also end with 6.x.

I don't know how long 5.1.41 on CDBA will be support by Cadence, but
I think it will be at least until end of 2007.
For new features you should surely look at 6.x.

This is what I've heard and must not be the 100% truth.
Maybe a Cadence internal can give you a more precise answer
on you question.

The main difference is of OA is not explained in a few sentences
I guess it's a complete new database.
But the good thing is that it is not Cadence proprietary, it's
owned by a kind of consortium and other EDA vendors can also apply it.
For more info have a look at http://www.si2.org and http://openeda.si2.org .

Bernd


tritue wrote:

Hi all,

What will be the main different of CDB vs OA. What will be the future of
CDB. Will Cadence drop the CDB line in a near furture.
I saw a new release of OA but not for CDB. Should we prepare to convert to
OA.
TTT

 

[Svenn Are Bjerkem]

Bernd Fischer wrote:

The main difference is of OA is not explained in a few sentences
I guess it's a complete new database.
But the good thing is that it is not Cadence proprietary, it's
owned by a kind of consortium and other EDA vendors can also apply it.
For more info have a look at http://www.si2.org and http://openeda.si2.org
.

But a lot of the contributed material is coming from Cadence (as they seems

to be a major driver) and it will be interesting to see if the license for
the OA things make it possible to link the C++ API stuff with any GNU tools
on distribution level.

I would start qualifying my designflow for OA as fast as I could. There is
no way around, and you have to be finished with your qualification so that
you can go productive as soon as possible after your CAD team has finished
the porting.

I am looking forward to integrate qucs as a lightweight schematic capture
and simulation front end and still have those dinosaur back-end tools do
their things.

It is fun, though, that Cadence standardize on Red Hat, who standardize on
GNOME and then they choose QT to have the right to do proprietary license
development. Sun also "wants" to standardize on GNOME, but that crappy CDE
is still around. Engineers were never known as drivers of technology, were
they?

Kind regards,
--
Svenn

 

[tritue]

Thank you for your prompted answer.

Our major problem is the design Kit coming from the foundry, they are not
very fast to support new tools or software upgrade.
Then I should expect a rough ride for the next 12-24 month.

Regards,

"Svenn Are Bjerkem" <svenn@bjerkem.de> wrote in message
news:dv9p5n$qeo$00$1@news.t-online.com...

Bernd Fischer wrote:

The main difference is of OA is not explained in a few sentences
I guess it's a complete new database.
But the good thing is that it is not Cadence proprietary, it's
owned by a kind of consortium and other EDA vendors can also apply it.
For more info have a look at http://www.si2.org and
http://openeda.si2.org
.

But a lot of the contributed material is coming from Cadence (as they
seems
to be a major driver) and it will be interesting to see if the license for
the OA things make it possible to link the C++ API stuff with any GNU
tools
on distribution level.

I would start qualifying my designflow for OA as fast as I could. There is
no way around, and you have to be finished with your qualification so that
you can go productive as soon as possible after your CAD team has finished
the porting.

I am looking forward to integrate qucs as a lightweight schematic capture
and simulation front end and still have those dinosaur back-end tools do
their things.

It is fun, though, that Cadence standardize on Red Hat, who standardize on
GNOME and then they choose QT to have the right to do proprietary license
development. Sun also "wants" to standardize on GNOME, but that crappy CDE
is still around. Engineers were never known as drivers of technology, were
they?

Kind regards,
--
Svenn

 

[fogh]

Svenn Are Bjerkem wrote:

Bernd Fischer wrote:


The main difference is of OA is not explained in a few sentences
I guess it's a complete new database.
But the good thing is that it is not Cadence proprietary, it's
owned by a kind of consortium and other EDA vendors can also apply it.
For more info have a look at http://www.si2.org and http://openeda.si2.org
.


But a lot of the contributed material is coming from Cadence (as they seems
to be a major driver) and it will be interesting to see if the license for
the OA things make it possible to link the C++ API stuff with any GNU tools
on distribution level.

I would start qualifying my designflow for OA as fast as I could. There is
no way around, and you have to be finished with your qualification so that
you can go productive as soon as possible after your CAD team has finished
the porting.

I am looking forward to integrate qucs as a lightweight schematic capture
and simulation front end and still have those dinosaur back-end tools do
their things.

Hum hum ...
There are various protections on the PDKs (legal and technical), and I
reckon that will be enough to prevent you from doing that.

For example a recent PDK EULA states that you can not use the PDK with
any other tool than cadence. Probably in reaction to paragon IC. In any
case, that legal restriction is new.

The OA semi-open/shared source status is not of much help if your
trying to see the callbacks is already illegal. Not to mention trying to
port/interpret them with scheme, python, C++ or whatever. Since the
callbacks are necessary for database consistency/integrity in most PDKs,
you won t be able technically

I am afraid that if you want to design using qucs libraries, you ll
have to build them from scratch. Probably on your own, and with the
foundry ignoring you (if not working against).

And then when you have a library ready, done with your design in a
rush to catch up for the library dev time, prepare to send a fat cheque
to VCAD so they port your design to the cadence PDK before the backend
design can start.

OK. This time, it is true: I am not funny and not cute. Bad hair day.