( ESNUG 429 Item 11 ) -------------------------------------------- [06/03/04]
Subject: ( ESNUG 427 #4 ) John McGehee'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: John McGehee <johnm=user domain=voom.net>
Hi, John,
I have been developing software for EDA companies using the Synopsys
Milkyway API and Si2/Cadence OpenAccess. My experience of both:
First, OpenAccess (OA) and Milkyway are not competitors. OA competes with
internally developed physical design databases. Milkyway competes with file
interchange. Your application decides which to choose. You might need
both.
The Milkyway API is an interface to the popular Synopsys Milkyway database.
With the ability to open and save Milkyway cells, your tool becomes a part
of the Synopsys Galaxy physical design flow. Skip that nasty LEF and DEF.
Open Access is an open source data model for EDA. If you need a new
physical design database, you have two choices: you can spend lots of time
and money to develop your own incompatible database, or you can adopt OA
virtually for free, without waiting. Other developers of new EDA tools are
going to make the same obvious choice, so it won't be long until the newest
tools run native on OpenAccess, sharing the same compatible database.
My relative strengths of Milkyway and OpenAccess:
Popularity -
For six years now, Astro, Star-RCXT, Jupiter and Hercules have created
thousands of chip databases that can be accessed with the Milkyway C API.
The sheer volume of data makes Milkyway the king of interface APIs. While
Synopsys has a lot of tools on Milkyway, it is not practical for any other
company's tool to adopt Milkyway as its native database.
There are few OA chip databases in existence.
There are lots of Cadence Encounter and Magma Volcano chip design data out
there, but they have no API. Well, there is a Volcano API, but it's a
secret.
Documentation -
The OpenAccess 2.1 documentation is some of the best EDA documentation I
have ever read. The 2.1 documentation is much better than 2.0, so use the
2.1 documentation even if you are developing on OA 2.0.
The 2003.06 Milkyway documentation is poorly written and contains many
errors and omissions. Developers without previous Milkyway experience will
find it difficult to understand.
Modernity -
Object-oriented Open access is written in C++, while Milkyway uses C. I had
more trouble with memory allocation, segmentation violations and pointers in
Milkyway C than I did in OA C++. OA's route object represents a contiguous
point-to-point connectivity through vias and bending wires, while Milkyway
uses only individual wires and vias.
Most tantalizing is the prospect of EDA software components from multiple
vendors sharing the same design data in memory. For example, this would
allow your place and route tool to switch between its own internal static
timing analysis tool, PrimeTime, and EinsTimer. I haven't tried it myself,
but OpenAccess appears to handle this. If Milkyway can do it, it is not
evident from the API or the usage models of Synopsys' Milkyway-based tools.
Track Record -
Have I taped out a chip with Milkyway? Yes, plenty with RC extraction and
timing analysis. Have I taped out with a tool based on OpenAccess? Uh, no.
After programming on OA, I am confident that it is excellent for topological
data, but I haven't seen much of the analysis features like parasitics and
timing.
Completeness -
Both OpenAccess and Milkyway have complete netlist and physical design data.
They both support cell views and reference libraries. OA gives complete
access to physical technology data and rules, Milkyway does not.
OA's parasitic and timing data is underdeveloped while Milkyway's is very
highly developed. However, very little of Milkyway's parasitic and timing
data is available to Milkyway API programmers. API programmers really need
access to the Milkyway parasitic view, but I appreciate how it is not so
easy to publish a satisfactory interface to such complicated data.
Licensing -
OpenAccess is open source, so you can freely examine and modify the source
code. Milkyway source code is unavailable.
No license manager regulates the execution of your compiled OA program.
Every Milkyway API program requires a valid Milkyway license in order to
initialize. Your users will never have a problem, because every Astro comes
with five Milkyway licenses. Milkyway API developers must live more
dangerously. Every year you need a new license file from Synopsys. If
Synopsys were to judge you unworthy, your investment in Milkyway development
would evaporate.
Utilities -
The Milkyway API comes with MDE, a little Astro that can't floorplan or
place or route, but does have the same GUI, layout editor, Scheme and TCL
interpreter and file translators. It's great for testing API programs. MDE
is so useful for viewing and translating Milkyway databases, every AE in the
EDA industry should have access to it.
OpenAccess does not come with a GUI. LSI Logic has donated a Python binding
for use as a scripting language, but I have not tried it.
OA does have LEF, DEF, GDSII and Verilog translators that allow you to test
your programs using text files. Note that if you use Open Access as your
native database, these same file translators will also work for your tool,
so you don't have to develop your own translators.
Golden Gate -
The goal of the Golden Gate project is a Milkyway-OpenAccess translator.
Currently, Cadence is leading the effort to develop a translator from
Milkyway to OA. Cadence thought it would be great if Synopsys would do the
complimentary translator from Milkyway to OA, but Synopsys is not quite so
enthusiastic. Anyway, when it does get done, the Golden Gate translator
will join the other interfaces, allowing all OA-native applications to read
and write Milkyway just like they can now read and write LEF, DEF, Verilog
and GDSII.
OpenAccess & Milkyway are by far the best EDA multi-vendor interoperability
tools I have ever used. No more data transfer using sets of huge,
inconsistent files. I can now open the cohesive native database, examine
the entire design hierarchy, plan what I will do, and transfer only the data
I need. That's the way it should be.
- John McGehee
Voom, Inc. Los Altos, CA
|
|
