( ESNUG 429 Item 7 ) --------------------------------------------- [06/03/04]
Subject: ( ESNUG 427 #4 ) Hewlett-Packard Strongly Supports OpenAccess
> Where are the actual end users clamoring for OpenAccess use? Where are
> the EDA companies not trying to be acquired by Cadence who are crafting
> OA interfaces? Once we hear from them, we'll know where OpenAccess
> adoption currently stands. (And those under a court order to support
> OpenAccess, like Mentor, don't count.)
From: Jim Wilmore <jim.wilmore=user domain=hp spot calm>
Hi, John,
HP is deploying an OpenAccess-based system for the actual production
design of a 90 nanometer chip. Let me fill you in on our experience so
far.
HP had originally integrated commercial tools from a number of vendors
along with many internally developed design tools into design flows
using our proprietary CAD database. Our internal tools run on our own
database, and we integrated commercial tools by readers and writers of
file formats, primarily standard industry formats. This type of
integration is creating significant inefficiency with each successive
generation of IC process, as the electrical effects all interact more
closely, requiring analyses on many parameters virtually in parallel,
rather than in the longer sequential design loops of the past.
These were HP's requirements for a database:
1. We must have control of our CAD system's database to
- fine tune tool integrations
- accommodate the special features and data needs of various tools
- debug complex tool flows directly in the database -- instead of
guessing at problems in a tool based on the file format
that it kicks out. We need to fix bugs in the database
as they are encountered, not on a vendor's release schedule.
In the past year we have found a number of bugs in OA.
We have submitted bug reports to OpenEDA.si2.org,
but in one case the short-term workaround was undesirable,
and so we modified our copy of the OpenAccess code
(which we manufacture in our internal build system).
When the fix is available in the next OA release,
we will replace our fix after verifying that the released
version meets our needs.
2. The CAD database that we build our system on must be efficient
in both performance and capacity. Our comparisons of our mature,
highly tuned internal database against the OpenAccess technology
gets mixed reviews. OA is considerably more efficient
in its use of memory, however its performance for creation of data
objects is somewhat slower than our database. Here are a few
representative data points for netlist data:
Netlist A: 70 K Instances, 95 K Nets, 230 K InstTerms
Netlist B: 350 K Instances, 290 K Nets, 960 K InstTerms
Netlist C: 2820 K Instances, 2570 K Nets, 8065 K InstTerms
Database Creation Memory Usage Data Traversal
OA HP OA HP OA HP
Netlist A 25 sec 19 sec 40 MB 70 MB 1 sec 1 sec
Netlist B 105 sec 75 sec 150 MB 260 MB 1 sec 1 sec
Netlist C 1170 sec 630 sec 1100 MB 2200 MB 2 sec 2 sec
The capacity benefits were enough to offset performance degradation
because:
- OpenAccess is not nearly as mature as our internal database,
and we anticipate performance improvements over its first
few years with the same sort of tuning we invested
in our database.
- The raw performance of the database is less of a consideration
than the performance of the design flow that is built on it,
and more EDA vendor software will obviously be written
on OpenAccess than to HP's proprietary database,
thus allowing for tighter tool integrations in the future,
especially as we port our internal tools (and write new ones)
to OA.
3. Just as we do with our own database, HP needs a way to add in
its own extensions to the CAD database without retooling them
to each OA release. OpenAccess technology has a very sophisticated
technique for extensions, and we have already used this feature.
One example is a mechanism to support HP's style of "searchpath"
environment for finding and selecting cells for use in the design.
The extra objects that we make are a persistent part of the extended
OA database and continue to work as designed across OA releases
with no code change on our part.
Changing the database in a design system as complex as HP's is a daunting
challenge. We are successful if the design communities that we support
continue to design their chips to specs and on schedule. Since we are
using it in a production design flow, we had to chart an evolutionary plan
to introduce OpenAccess into our system. We are going through this effort
now because we believe very strongly that OpenAccess is an essential
ingredient in our future CAD system.
- Jim Wilmore
Hewlett-Packard Cupertino, CA
---- ---- ---- ---- ---- ---- ----
From: Alva Barney <alva.barney=user domain=hp spot calm>
Hi, John,
Right now we are using Open Access (OA) in a production 90 nm SP&R flow.
Our flow covers block level floorplanning, physical synthesis, clock and
test distribution, and routing for timing closure. It is designed to
work smoothly with our hierarchical design styles. This flow is used on
an extremely aggressive ASIC for high end HP servers.
You ask why we clamor for OA ...
1) We do not have a single vendor flow. We use OA to ease the integration
of different vender tools and our internal design environment (which is
heavily influenced by well entrenched custom designers.) Obviously the
number of tools which run native on OA is not as high as we would like.
However, we look forward to see more companies develop on OA because it
lowers the cost of integration into our flow.
2) We still code various portions of the flow in-house. Our methodologies
around clock distribution and test insertion do not allow us to use
vender tools wholesale. We have written these pieces natively on OA.
It has been a big win in both performance and cost. A couple examples:
a) For test device insertion, we use our own OA application
for the insertion (netlist editing) and placement legalization.
This sure beats calling an expensive tool just to modify the
netlist and do the simple placement legalizations.
b) Use of geometrical operations to check various floorplanning
rules (i.e. ports on grid, sufficient clearance, etc.)
before feeding the floorplan into physical synthesis.
This allows us to catch many data problems right away and not
after a full night of computing.
The bottom line is that OA is at the heart of our flow. The performance
critical portions of the flow are C++ and the basic flow control is Perl.
We are using SWIG (Simplified Wrapper and Interface Generator) to create a
Perl interface into the native OA API and HP OA engines. The performance
is comparable to our battle hardened internal database, but the available
information is richer for SP&R related applications. Because of the
richer API, we are reaping benefits today.
- Alva Barney
Hewlett-Packard Fort Collins, CO
|
|
