Interoperable Physical Design Database between

OpenAccess and Milkyway

#i *2 #3 *4
Yong Hong Poh , Chin Yin Chew , Kok Leong Hoi , Wei Pin SOO
Altera Corporation (M) Sdn. Bhd.,
Plot 6 Bayan Lepas Technoplex, Medan Bayan Lepas,
11900 Penang. Malaysia
[email protected]
[email protected]
[email protected]
[email protected]

Abstract- In the world of mixed signal design, physical

design database transfers between custom (Cadence
ASIC World
OpenAccess (OA» and ASIC (Synopsys Milkyway (MW»
(Synopsys MW)
are frequently needed for the completion of a design. The
traditional method of using only GDSII as the transfer
medium has many disadvantages, such as lost connectivity
information and net-texting inconsistency. This paper
describes a methodology for transferring the database in the
most efficient way, retaining the information in the
database, ensuring the correctness of the database.

Keywords-Bridging, LEF, DEF, Milkyway (MW),

OpenAccess (OA), SKILL, Scheme

1. Introduction Altera Internal

In the c urrent w orld of c hip design, t he ra tio b etween Developed Protocol

custom bl ocks and ASIC b locks in a c hip is getting elose

to each other. This poses a challenge to the design team as Figure I: Four different possible ways of ASIC custom bridging.
frequent and rapid database de livery b etween cus tom
Out of t he four different w ays, w e c hose a m ixture
design and ASIC design a re n eeded. T he t raditional w ay
between L EF/DEF a nd SKILL/Scheme. L EF/DEF was
of database transfer, which depends solely on GDSH, is no
chosen as it is th e in dustrial s tandard database t ransfer
longer sufficient to serve the purpose owing to the
format ado pted by mo st ED A to ols. SKILL/Scheme i s
complex verification, texting, and preparation required.
used to execute m inor m assages on t he da tabase pr e- and
Based on our prior project for Stratix IV GX FPGAs to post-database transfer.
deliver a MRAM FRAM view for the lllP block, there is a
I. Methodology
need to cr eate cus tomized program in SKILL, Perl, and
The OA platform stores the custom designs, which uses
Scheme w ith a utilization 0 fH ercules an d Calibre to
the in -house t echnology I ibrary a nd PCELLs. The MW
achieve t he t arget. T he da tabase co nversion a nd delivery
platform s tores th e A SIC de signs, w ith the technology
process (bridging) i s I engthy a nd involves layout, CA D,
and ICD to c omplete. Th e tur naround time pe r F RAM library and s tandard c ells pr ovided b y f oundry. Figure 2
gives a n ove rview of t he m ethodology 0 f A SIC custom
view delivery is a minimum of 2 days.
bridging a nd between t he two different da tabase
Therefore, a n official aut omated database tr ansfer
platforms.
method should be cr eated to e nsure a smoother and
simpler f low f or da tabase de livery. In a ddition, a ny da ta
and attribute with common behaviors in both custom and
ASIC design must be r etained to r educe r ework once t he
database is transferred.

As illus trated in F igure 1, t here a re f our di fferent

possible ways bridging can b e c ompleted: LEF/DEF,
SKILL/Scheme, OA C-API/MW Tel-API, and internally
developed protocols.

978-1-4244-7456-1/10/$26.00 ©2010 IEEE 1003

 For the b ridging, w e e xcluded t he technology
information, because both the OA and MW environments
contain their own te chnology in formation. The
FRAMIabstract view generated from the LEF file consists
Cadence 0.\
of:
In-house fech
• Pin: Power, ground, signal
• Cell boundary: prBoundary layer
Layout View
• Blockages: 00, PO, metals, vias

C. Verilog to Schematic and Symbol View Bridging

Custom a nd A SIC de signs have different s tarting
points. The V erilog netlist is th e s tarting point f or A SIC
Symbol View
Verilog Nellist
Verilog :-Ietlist
designs, while a schematic is used in custom designs. This
bridging e nables the v iewing capability f or a custom
Schematic Vie"
Milkyway to OA layout designer, with access to th e 10 gical de tails of the
mw20a ASIC design to ease the de bugging w ork dur ing t he
integration of the ASIC into the custom design.

Figure 2. The methodology of ASIC bridging. D. Infrastructure

Bridging works in two directions, from OA to MW and A new directory named "bridge" has been introduced to
vice v ersa. We w ill di scuss in de tail h ow th e database i s serve as a common pI ace to s tore all th e f iles us ed for
transferred via the f ollowing elements: Library Exchange bridging. For e ach da tabase transfer executed, all
Format (LEF), Oesign E xchange F ormat (OEF), GOSH necessary files are version-controlled in the directory.
stream file, and Verilog netlist.
H. Implementation
To impl ement th e ide a 0 f ASIC custom bridging,
A. CEULayout Views Bridging bridging f rom OA to MW use program "oa2mw" while
The p hysical layout in 0 A ( layout v iew) is translated bridging f rom MW to OA use program "mw20a". The
into MW (CEL view) via the OEF and GOSH file formats
following sections discuss how the programs being
and vice versa. The GOSH stream file is the standard way implemented.
of t ransferring the tw o-dimensional physical mas k layout
design data such as instances, polygon of layers, texts, and A. OA to MW Bridging (oa2mw)
vias. However, the stream file is unable to transfer design The oa2mw program consists 0 f tw 0 h alf-bridging
connectivity information. To overcome this limitation, the processes, "oa2bridge" and "bridge2mw". F igure 3
OEF methods can be used. A OEF f ile contains the illustrates the oa2mw program.
following information:

• Logical design data: Netlist connectivity

• Physical data: Locations of cells and macros Bridge
• Locations of routing wires (designSync)
Taggillg all(/
To resolve the limitation of the OEF file format, which
is unable to transfer unique technology library data objects
such as PC ELLs and vias accurately, a GOSH stream file
is used to transfer these objects.
Figure 3. The concept of OA to MW bridging.
B. FRAMIAbstract View Bridging The b ridge directory stores all of the b ridging-related
LEF is t he file f ormat that enables the c reation 0 f t he files, including LEF, OEF, GOSH stream file, ISS netlist,
identical a bstract view of a physical mas k layout c ell in EQV cell equivalent f ile, and Verilog netlist. Th ese files
both 0 A ( "abstract" view) a nd MW (FRAM view) are version c ontrolled and t agged to in dicate the
environments. LE F gives a physical description for layout bridging's source and destination.
libraries ( for macrocells), w hich i s us ed for place a nd
At the start, the oa2bridge process uses the in-house
route t ools. A L EF f ile in A SCII f ormat c ontains the
customized SKILL program to generate the abstract view.
following sections:
Next, the abstract view is translated into an LEF f ile
• Technology: Layer, design rules, v ia de finitions, through the "lefout" command. In th e me antime, the
metal capacitance GOSH f ile for the top cell's lay out v iew is generated by
• Site: Site extension using the customized SKILL command. Then, the OEF
• Macros: Cell de scriptions, c ell di mensions, file is ge nerated with th e command" defout". A l ayout
layout of pins and blockages, capacitances. engineer w ill need to pr epare t he b locks' co rrespondence
ISS netlist an d EQV e quivalent f ile f or L VS v erification

1004
purpose after th e in tegration of c ustom design in to A SIC Next, t he bridge20a process builds the database in OA.
design. The GOSII file is used to rebuild layout view without any
pins and connectivity information. Then, L EF a nd OEF
Next, the bridge2mw process builds the da tabase in
file is translated and overlaid into the lay out v iew to
MW. Th e L EF f ile is tr anslated into FRAMvi ew vi a the
recreate t he co nnectivity of the physical mas k layout.
"read_Ief' command. The GOSII file is translated into the
Next, t he o riginal L EF f ile, is used to cr eate t he abstract
CEL v iew. The OEF file can b e us ed to r ecreate t he
view. Lastly, verilog file is c ompiled to r ecreate t he
connectivity i n t he C EL v iew w hen needed. Once the
symbol and schematic views of the ASIC de sign i n OA .
database is b uilt, a verification mo dule e nsures that the
Once th e da tabase is b uilt, a v erification module e nsures
database created in MW is identical to the bridge directory
that th e da tabase c reated in OA is identical to th e bridge
data. Figure 4 demonstrates the process of oa2mw.
directory da tao Figure 6 demonstrates t he pr ocess 0 f
Custom Block Custom Block mw2oa.
(Cadence OA Platform) (Synopsys MW Platform)
ASIC Block ASIC Block
(Cadence OA Platform) (Synopsys Milkyway Platform)

Figure 6. Program flow chart for mw20a.

Figure 4. Program flow chart for oa2mw.
III. Results and Achievement

B. MW to OA Bridging (mw20a) This me thodology is widely us ed in Altera 28-nm

The mw20a program consists 0 f tw 0 h alf-bridging process pr ojects and has b een de monstrated as a r eliable

processes, "mw2bridge" and "bridge2oa". Figure 5 and efficient method to b ridge da tabases for bl ock

illustrates the mw20a program. integration.

�
Figure 5. The concept of MW to OA bridging. � �

J I ...=;:.
At the start, the mw2bridge process first verifY the MW --- I
-
J • _J
design cel l if it c ontains b oth a C EL an d FRAM view.
----_ ..
Then, the LEF file is generated from the top cell's FRAM ---- -

view by using the command "write lef', and the OEF file
is ge nerated using the c ommand '';''ite def'. The stream Figure 7. Abstract view in OA (top) and FRAM view in MW (bottom).
file is ge nerated using the" write_gds-;; c ommand. The
place-and-route engineer i s a Iso r equired t 0 provide the Figure 7 s hows t he abstract view in O A e nvironment
Verilog file. translated into FRAM view in MW and vice versa. (Color
differences are due to the different color settings.)

1005
 [4] Cadence, LEFIDEF Language Reference (Product version 6.1.4)

Figure 8. Layout view in OA (top) and CEL view in MW (bottom). [5] Synopsys, Milkyway Environment Data Preparation (Product
version 20/O.03-SP5)

Figure 8 shows t he layout view in 0 A e nvironment

translated into CEL view in MW and vice ve rsa. (Color
differences are due to the different color settings.)

Table 1 summarizes th e b enefits of the ASIC custom

bridging program.

Table I. Benefits of ASIC Custom Bridging

Before ASIC With ASIC Custom

Bridging Bridging

Stream file has no Additional manual LEF in/DEF in

connectivity work to create port ensure that
from txt for connectivity is taken
connectivity care of
Mode of process Manually performed Standardized and
automated
Cross-probing between Unable to perform Possible
schematic and layout
Verification of database Exhaustive verification Simple and
bridge straightforward
Version control of Not available Yes
database bridge
Efficiency (turnaround Low High
time due to the frequent
design updates)

Generation of Required additional Possible in the near

integration netlist for merging scripts future
ASIC in custom design

IV. Conclusion
The ASIC custom bridging pr ogram pa ckages the
numerous steps required in database translation to reduce
the n umber 0 f man ual iterations that engineers a re
required to perform. Compared to previous manual efforts,
this pr ogram sa ves time an d effort by simplifYing the
methodology. Files are version controlled and placed in a
centralized location to avoid messy files when designs get
bigger. The results a re verified to en sure no da ta l oss
occurs during the tr ansition of the da tabase b ridge
between the two platforms.

Acknowledgements
Our t hanks t o t he Altera layout a nd place-and-route
engineers f or t heir exhaustive te sting of t he program a nd
providing critical feedback for improvement.

References
[I] David C hinnery, Kurt Keutzer, Closing The Gap Between ASIC &
Custom: Tools and Techniques for High-Performance ASIC Design,
Publisher: Springer; I edition (June 30,2002)

[2] 1. B hasker, The Exchange Format Handbook, Publisher: Star

Galaxy Publishing (September 1,2005)

[3] Cadence, Design Data Translator's Reference (Product version

6.1.4)

1006