( ESNUG 429 Item 9 ) --------------------------------------------- [06/03/04]
Subject: ( ESNUG 427 #4 ) Developer Warns OpenAccess Has Scary Licensing!
> 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: James Cherry <cherry=user domain=parallaxsw spot calm>
Hi, John,
Some thoughts on OpenAccess. I have a few things I wanted to get off
my chest, so I took the bait and wrote the following. I just hope it
doesn't piss off the Cadence OA team too much.
Over the last few years I have developed a static timing engine that
is designed to be bolted on to external databases through an API. I
have licensed it to a few EDA startups that use it as part of more
comprehensive tool suites. One potential customer and another new
customer requested an OpenAccess port.
I have had to build a lot of infrastructure that is not related to
timing so I can develop and debug the timing engine. As I learned
about OpenAccess, I was hopeful that I could discard much of my own
infrastructure in favor of leveraging what is available in the
OpenAccess project. Someday this may be possible, but right now I
plan to keep my existing infrastructure and treat OpenAccess as just
another database that the timing engine can run on. Some of the
reasons why I am choosing this conservative approach are detailed
below.
The interesting parts of OpenAccess for timing are the netlist ("EMH",
or Extended Module Hierarchy) and parasitics support, which were added
in the OA 2.1 release. The flat netlists available in OA 2.0 do not
know anything about hierarchy. This means that timing constraints on
hierarchical pins and instances can not be supported on OA 2.0. For
this reason I targeted the OA 2.1 release.
I encountered some simple bugs in parasitics API functions that were
incorrectly rejecting the arguments passed to them. Because I had
sources, I was able to fix them and move on without waiting for fixes.
I was also able to fix the rather annoying 10,000 lines of compiler
warnings generated by the OpenAccess headers themselves reported by
g++ when warnings were enabled (-Wall). I was unable to fix one
problem related to hierarchical instance terminal lookup. I was able
to work around it by using a slower linear search. I happen to know
some of the OA team members and they were able to reproduce and
acknowledge the problems I encountered. I also was able to get most
of my questions answered promptly.
Although the bugs I encountered were reportedly fixed by the
OpenAccess team, they haven't appeared in a release yet. One of the
reasons is that the OA 2.1 release appears to be an orphaned preview
of OA 2.2. No more OA 2.1 releases are scheduled. OA 2.2 will not be
released until September 2004. This means that fixes for the bugs I
reported in October 2003 will not appear in a release for a year.
Because of changes to the license agreement, I won't have access to
that release until June 2004 unless I join Si2. Twenty months is a
long time to wait.
One of the most unfortunate aspects of OA 2.1 is that there is no way
to actually read a hierarchical netlist into the database. No Verilog
reader is available for OA 2.1. HP recently donated a Verilog reader,
but it works on OA 2.0, which is a flat netlist schema. Furthermore,
Si2 membership is required to download it. The good news is that the
OA DEF reader builds a "pretend" netlist hierarchy using generated
occurrence instance and terminal names. This allowed me to at least
test the hierarchical aspects of the OA EMH netlist API. However,
hierarchical timing constraints cannot be supported because the
generated names don't match the logical netlist that cannot be read
into OpenAccess.
I tried to use the spef2oa parasitics reader available on the
OpenAccess website. I was written for OA 2.0, so I had to do some
minor work to port it to OA 2.1 because the netlist and parasitics
APIs changed. Unfortunately, that was only the start of the problems
I had with it. It was unable to even parse Spef generated by the
Cadence/Simplex Fire&Ice extractor. After spending too much time
trying to fix it, gave up and I made some simple changes to my SPEF
reader so I could build an OA parasitics database using it instead.
When I attended the OpenAccess conference a few weeks ago, I finally
understood that it doesn't make sense to be on anything but OA 2.0 at
this point. Since Cadence is releasing their tools on that version,
it is the only version that has any real support. It doesn't make
much sense to move to OA 2.2 until late this year.
I always find it interesting to read other people's code. Most open
source code is not exactly pretty. There are plenty of examples of
rather bletcherous open source programs in the CAD domain from both
vendors and universities. On the other hand, the OpenAccess C++ API
is by far the most carefully crafted and well architected API I have
ever seen, open source or proprietary. The naming, coding and
formating standards are consistently followed in all of the headers,
making them easy to read and understand. The richnesss of the
OpenAccess schema makes it clear that the developers have extensive
real world EDA experience. OpenAccess makes reasonable use of the
power of C++ over vanilla C. Unfortunately, does not take advantage
of C++ STL libraries, namespaces, or the boolean primitive. Under the
hood (behind the header files), the OpenAccess implementation depends
on a rather opaque layer of code based on integer offsets into arrays
of objects that are memory mapped to disk. This is a strange world to
programmers accustom to dealing with pointers. This will prevent all
but the bravest of soles from attempting to fix bugs in the OpenAccess
core.
The complexity and changing nature of OpenAccess licensing is another
concern that I have. It is nothing like a simple open source license
agreement such as the familiar GNU GPL or the BSD license. The
license agreement that I signed to download OpenAccess in June 2003
does not apply to newer releases. It is disconcerting that the
licensing can and has changed over time.
With the new license agreement, the licensing rights expand after
joining Si2 and the OpenAccess coalition. Access to compiled OA
libraries, sources and utilities such as the HP Verilog reader is
delayed by nine months if you don't join. The access "matrix"
(http://www.si2.org/Membership/pdf/notification2.pdf) is rather
complicated. Distributing sources requires "project membership",
which isn't defined but presumably refers to OpenAccess coalition. It
will cost me $2000 to gain access to new releases ($1500 per year,
$500 first year). This isn't a huge amount of money, but what
assurances to I have that next year it won't be $10,000 or $100,000?
Cadence made an extremely bold move when they opened up OpenAccess.
It has the potential to change the landscape of the EDA industry in
significant ways. I hope that as it is adopted and matures access
will become simpler so that even small developers have a better chance
of building additional functionality on top of it.
- James Cherry
Parallax Software Los Altos, CA
|
|
