( ESNUG 429 Item 10 ) -------------------------------------------- [06/03/04]
Subject: ( ESNUG 427 #4 ) George Janac's OpenAccess vs. Milkway Comparison
> It took us 2 months evaluate OA, and about 6 months ago we decided to
> use it as our in-memory database, in the hope that it would save us of
> time in developing and building a correct database.
>
> - Bogdan Arsintescu
> Neolinear/Cadence San Jose, CA
From: George Janac <george=user domain=sinavigator spot calm>
Hi John,
Silicon Navigator is an EDA startup that had to make the decision of
whether to build a framework or use an existing one. We have been
developing new applications and component software in areas of size,
timing, power, and leakage on OA for 6-7 months. We had looked at both
OpenAccess and Milkyway. Our decision to go with OpenAccess was driven
by the following observations:
1) Milkyway
- Older software C architecture
- Very good for extending the Synopsys/Avanti tools
- C-level API and Scheme extension language
- Lot of point tools on the framework
- Framework not just a database
- Difficult model for an EDA startup to use and build new applications on.
2) OpenAccess
- Very modern software architecture
- Full C++ API, no scripting language yet
- Very high performance database with rich data model
- Very few native applications so far
- Framework layer missing (Windows, Menus, Database Imaging)
- Ideal for building new applications
Our OpenAccess Development Work:
The first thing we built was the framework for graphics. A TCL interface
to OpenAccess is also under way in order to provide memory safe user
extensibility.
We have been working on OpenAccess 2.1 for about 6-7 months with a team
of currently 9. We have created a Framework, selection, and are working
on extension language. The major problem has largely been inefficiencies
in region query (a well known OA problem due to be fixed in 2.2). We
have implemented RTL/Gate level import into OpenAccess and processed
designs upwards of 1 million objects. Major issues there have been the
newness of the OA2.1 EMH (Embedded Module Hierarchy) Occurrence Model.
We have had to make several fixes but have been able to keep developing.
Many of the experiences with this in 2.1 will serve to make sure the
OA2.2 version more robust and higher performance. We have implemented
OA-based components for placement, floorplanning, and static timing.
Major issues there are that data models for timing are not fully
represented in OA (also not in Milkyway). We have had to work around
this by reading files like SDF, SDC, and Liberty directly into the
engines, not from OpenAccess. While this is not the best solution, the
system works, and it is likely to persist for some time.
Design flows have gone way beyond scripting. All high end design teams
do some amount of run time scripting or software development. Scripting
languages like Scheme and Skill have sufficed on smaller designs. Today
most flows use Perl, TcL, and C to process large files to extract
information. The ability for a team to use C++ directly on a database
and implement analysis, control, and implementation is going to be more
and more of a requirement as we move towards 10 million cell designs.
OpenAccess has this ability and no EDA vendor can prevent anyone from
using it.
Missing from OpenAccess:
For most developers four things are not yet available in either free form
or licensable form:
1) Framework: Graphics environment that can be used to image the
database, interact with the database, and build applications on.
2) Scripting Language: Memory safe scripting language that can be used
to simply interrogate and extend OpenAccess capabilities.
3) Applications - OpenAccess needs to close the gap on the number of
native applications compared to Milkyway
4) Component Algorithms - Custom flow development requires a new model
for both business and software. Algorithms like static timing,
congestion analysis, power analysis, placement, floorplanning,
extraction, etc have to be available as components ready for integration
with other (maybe in-house) tools.
By year's end the framework and scripting language issues will be solved
by combinations of Silicon Navigator, other commercial vendors, Si2, and
Cadence. Silicon Navigator is partially concentrating on bringing
component algorithms to OpenAccess. This will hopefully be the start of
a brand new branch in EDA.
OpenAccess Issues:
1) Main issue is that it is new. Having both a 2.0 and 2.1 stream has
been a major source of confusion. Cadence is deploying on 2.0 and it is
the well supported software release stream. Everyone doing timing and
optimization, including us, has jumped on the 2.1 stream because of its
Occurrence model. However it is not that well supported. This has
caused some angst in the community.
The solution to the 2.0 and 2.1 stream is 2.2 which is starting to roll
out this summer. The community is pretty much banking on 2.2 to be the
main stream for release later in the year. This will solve many issues
that the current users have been faced with.
2) Resources for implementation. Cadence is the main resource for the
reference implementation. This is both good and bad. It is good
because they are then motivated to be in sync and release their tools
on OpenAccess. It is bad because what everyone wants will take more
resources than they can muster. OpenAccess will not be truly a
community until other teams (individuals or companies) start to provide
reference implementation in some key areas.
3) Lack of user base. This is the classic Chicken and Egg problem.
Synopsys and Magma all point to there being few OpenAccess users. Well
I would point out that when these company brought out their first
products, they had no users. OpenAccess is in better shape because the
Independent Device Manufactures (IDMs) are invested-many have adopted
OpenAccess and are real drivers, such as IBM, HP, LSI, and others. They
need custom flows and they have the last vestige of internal CAD groups.
It is the first time they can blend internal knowledge and still be able
to leverage commercial EDA.
Additionally, EDA startups are using it for economic reasons.
What most people don't realize is that OpenAccess has the possibility of
creating some killer applications not possible on other systems. The
ability to handle very large layout, large number of RC parasitics will
create new applications that can efficiently analyze 2 centimeter layouts
for 90 nm and below. Undo and incremental support is going to be another
key distinguishing feature. When you have 10 million of anything
changing 100 should take a very small fraction of the time. Capacity and
incrementality will lead to a new set of killer applications. OpenAccess
in the end will be defined by the applications that it enables.
You have to scratch your head pretty hard and just ignore OpenAccess and
build your own database and framework from scratch as a start-up. It is
the embodiment of 20 years of framework knowledge (mostly layout) from
Cadence. Implementation is first rate. Even if you could do it better,
it is 2 year project that will burn up one round of very expensive VC
financing. We have expertise to build what OA is. However, by choosing
not to build our own framework, we expect to save several millions of
dollars of development expense and more then a year in time-to-market
savings.
- George Janac
Silicon Navigator Corp. Cupertino, CA
|
|
