( ESNUG 429 Item 8 ) --------------------------------------------- [06/03/04]
Subject: ( ESNUG 425 #5 ) The Details Of A Few Early OpenAccess Tape-outs
> OpenAccess is a database project being done by Cadence and some of its
> customers. Currently, it has virtually no tape-outs, no data,
> and almost no EDA tools running natively, including Cadence's tools.
>
> - Aart de Geus
> Synopsys, Inc. Mountain View, CA
From: Bart Bergman <bbergman=user domain=arrowsmith-research spot calm>
Hi John,
We did an OpenAccess tape-out.
I worked with LSI Logic to co-develop a design system associated with
LSI Logic's RapidChip structured ASIC program that is based on the
OpenAccess (OA) database. While building the system, I ran a design from
Plexus Corp. through the system and taped it out. The part took 3 months
to design and tapeout and the silicon worked correctly right out of the
chute. This Plexus chip will go in a airplane as part of a video control
system. The design is very small by RapidChip standards. It uses 88K
ASIC gate equivalents out of 1.5 M available, 350 I/O's and 288 Kbits of
diffused memory. The intent was to test out a minimal set of functionality
that included memory, I/O's and gates.
The Tape-Out:
The Plexus design served as a 'pipe cleaner' to test out LSI's OA-based
design flow -- we used it to work through the methodology, libraries, and
tools. It was also the first time that LSI Logic had put a real customer
design on a 130 nm RapidChip slice.
The Plexus design was initially mapped to a Xilinx VirtexII V250 part.
We received the design and did the work to map it into a RapidChip
slice. We started the design at the end of June 2003 and in less than
two months we were doing our initial physical synthesis runs on the
design. We were still developing the design flow while we did the
design, and the LSI Logic libraries and IP deliverables were still being
developed in parallel. Also, the customer added some additional
functionality along the way, including an SDRAM controller and a
multiplier. We were still able to tape out the design in late
September 2003.
In addition to the above design, I also moved a very large production
LSI design with 2 million gates through physical synthesis. Synplicity
also worked in close collaboration with LSI and Arrowsmith on this
OA-based flow. During this three month project, we had multiple
Synplicity releases, and LSI was modifing the libraries underneath the
design. However, because of the use of standard interfaces, when these
changes occurred, it didn't affect the flow.
The OA-Based Design Flow:
It took us three months from when we first received the design until we
taped out the Plexus chip. The pieces of the design that were influenced
by or represented in OA were the standard cell library, all IP blocks,
the diffused memories, the R-cell memories, and the slice definition.
All floorplanning operations, such as creating and editing placement
blockage and controlling diffused memory or R-cell memory locations were
also done natively in OA.
We were able to get significant sub-flows into OA. All libraries and all
of the data associated with doing RapidChip and the floorplanning was
represented in OA. RapidView (graphical viewing and editing application)
runs natively in OA. The other tools that we interfaced to OA were
RapidBuilder, for automated configuration of memories, I/O's, and clocks;
RapidPro for rule checking and linting; RapidCheck for electrical rule
checking; and Synplicity's Amplify-RC, for physical synthesis.
Synplicity's tool was accessed via a translator path, e.g. Standard file
formats (LEF, DEF and Verilog)
We interfaced LEF, DEF, and Verilog into and out of OA. We used these
interfaces frequently, such as when moving OA floorplan slice data into
DEF for input to Synplicity and moving DEF placement data into OA after
physical synthesis. We also moved data frequently between OA and
Milkyway to route the design in Avanti. The LEF and DEF translators
themselves are somewhat primitive -- just batch oriented commands with no
GUI -- yet they worked reliably. The translators are very particular about
command line options and file location. However, they did reliably
translate the data we required. The translator that goes from DEF back
to OA is extremely slow. We were able to solve that by translating just
the components section to minimize the amount of data that was
translated.
OpenAccess Plusses:
The single data model greatly simplifies design engineers' lives. For
example, while you use OA, selection and cross-probing between the
logical and physical views is a simple thing, versus error prone and
complicated socket connections that are used regularly today.
OA's single design repository combines the physical and logical database
in a high performance database. As a result, the entire design flow we
built can be run on Linux and Windows XP. My machine was a Dell laptop,
an Inspiron 8200 with a 2.0 Ghz Pentium 4 Processor and 1 G of memory. I
was able to run Physical Synthesis in 12 minutes under Windows XP.
OA allows high performance, user defined extensions to the database that
allowed us to develop a graphical application that can modify logical to
physical pin assignments to create a personalized I/O ring. This
openness and performance are critical to supporting additional
applications. We used these extensions to perform packaging operations.
We are also using OA to store RTL data in the database though it is not
part of the specification at this time. Handling RTL data is on the OA
roadmap, but we are implementing it ourselves in the interim.
OpenAccess Minuses:
There are not enough tools available to get from RTL to GDSII without
using translators. The translators work reliably, but are not nearly as
fast or powerful as a flow that uses a single data model. Most
importantly, synthesis is a critical tool in the center of today's
design flows and there are currently no synthesis tools that I know of
that are either built natively on OA or have an API interface to OA. As
a result, the IC design process remains much more complicated than it
needs to be. The most powerful system and the simplest system would have
been a system based entirely on OA. LSI Logic has provided a sample
datapoint that shows a 147 times performance increase (45 Seconds vs.
110 minutes) through the use of API's instead of translators. More
importantly, this will allow incremental changes.
More OA Highlights:
1. For memory site selection, we read in a logical design and then could
graphically place the memory in one of many diffusion memory sites or
place R-cell memories.
2. The Verilog to OA parser that we used could read in 762,000 standard
cells, and translate it into OA in less than 810 seconds on the
reference laptop platform.
3. Once parsed, the data is instantly available for incremental operations
within a native OA application.
4. This single data source is critical to automating applications. OA can
then provide access to objects like port names and port direction by
walking the database.
I'm happy to say I will demonstrate an incremental ECO flow and tool
interoperability in a RTL-to-GDSII flow using Artisan, Fujitsu, IBM,
LSI Logic, Mentor Graphics and Synplicity in the Si2 booth at DAC.
- Bart Bergman
Arrowsmith Research Lakeville, MN
---- ---- ---- ---- ---- ---- ----
From: Scott A. Peterson <sap=user domain=lsil spot calm>
Hi John,
We've taped out designs using our OA-based design flow. Shipped silicon on
a design that had 1.5 million equivalent user gates implemented in 130 nm
CMOS technology. The majority of the area was taken up by 4 2Kx36 2 port
memories. The rest of the design is comprised of an 18x18 multiplier, an
SDRAM controller, and a graphics controller.
Our OA-based design kit, RapidWorx, includes the following tools, which
combine both our internal and 3rd party EDA vendor tools:
- RapidBuilder - automated configuration of Memories, I/Os, and Clocks
- RapidPro - a rule-based methodology that combines best-practice design
rules with physical RTL analysis
- RapidView - a graphical viewing and editing application.
- Synplicity's Amplify RapidChip - for physical synthesis combines RTL
synthesis, placement and optimization
- RapidCheck - verifies a RapidChip gate-level netlist and generates
outputs for handoff to LSI Logic
- One of the internal applications, a Python scripting interface, we've
even donated source to OpenEDA.org. Why would we do that? Because
I'd love to see other groups build on our work and provide Perl, TCL,
etc. interfaces.
Within our internal flows we transfer data between Milkyway and OA through
a Python script layer between the two databases. Transfers are done in
memory avoiding additional files. In the future we plan to use the
translator technology being developed by the Golden Gate Working group.
Here are some examples of our Milkyway to OpenAccess transfers.
Number Number Number
of of of Xfer
gates Memories I/Os Time
Design 1 200 K 65 522 178 sec
Design 2 302 K 45 546 229
Before developing our RapidChip design kit on OpenAccess we ported an
internal GDSII application to get a measure of the performance, quality,
features, etc. of the standard and database. It took 3 man-weeks to port
the app to OpenAccess where we ran the following tests on a Pentium III
700 MHz processor with 256 MBytes of memory and Win2000 operation system.
We saw a consistent 3x reduction in data size, good runtime performance
and feature sets that met our needs.
Number Read Elapsed GDS OA
of Time Time Size Size
Records (ms) (ms) (KB) (KB) Ratio
Design 1 464078 11456 16944 3684 1434 2.6
Design 2 5177017 70101 76760 42690 14215 3.0
Design 3 5774428 77201 85933 49296 16087 3.1
Design 4 6758148 75459 82899 54408 18263 3.0
Design 5 7078607 87235 94806 57104 19222 3.0
Design 6 7186254 88538 96038 58050 19405 3.0
Design 7 8405195 105321 111430 67688 22593 3.0
Why did LSI Logic invest in OpenAccess? LSI Logic has developed and
maintained internal databases and used commercial ones. Both have
advantages and disadvantages. Internal database development allows complete
freedom and control but with a high resource burden. Commercial databases
are readily available but designers are forced to use what's there and have
marginal development control. For LSI Logic, OpenAccess fits nicely
between these two.
Three facets of this model are particularly important to LSI Logic.
First is the community control that influences the development direction of
the standard. The Coalition is governed so that no one company dictates
what the standard will be while also providing a balanced process to avoid
chaos or gridlock.
The second item is the availability of the reference database source code.
LSI Logic has been able to hot-fix bugs we've found because we had the
source code. We're in the business of shipping silicon solutions. Our
customers aren't interested in whether we have a tool bug and we need to
respond ASAP when these come up.
The third item is the extensibility of the standard. This is more than
developing new API features but rather an existing mechanism to natively
add new functions without altering the underlying API or database. For
example, LSI Logic has used extensibility to develop a bonding application
that bridges the die and package boundaries.
- Scott A. Peterson
LSI Logic Minneapolis, MN
|
|
