API vs. File Exchange

As the EDA industry has matured, multivendor interoperability has steadily improved. In the 1980’s, if you had design data in a Daisy Logician, there was practically no way to extract it. Then, with the rise of standard file formats such as EDIF and the currently popular quartet of LEF, DEF, Verilog and GDSII, multivendor interoperability became possible, albeit painful. In the late 1990’s, Avanti’s Milkyway and Magma’s Volcano databases provided excellent interoperability across tools, but the interoperability was limited to the respective company’s product line.

Procedural access to other EDA companies’ design databases was out of the question. As Avanti CEO Gerry Hsu once declared, “We let nobody suck our blood. We suck other people’s blood, but nobody sucks our blood!” Gerry considered interoperability between his tools to be the lifeblood of Avanti, a competitive advantage that was to be jealously guarded. While other CEOs were less graphic that Gerry, all EDA vendors who had any blood to suck shared his attitude. Meanwhile, EDA users got by using text files for multivendor interoperability.

Finally, powerful EDA customers like Agere, Hewlett-Packard, IBM, Intel, LSI Logic, Freescale and STMicroelectronics got fed up with the limitations of text file data exchange and demanded procedural access to a common database. While the intervening machinations are beyond the scope of this paper, the result is that everyone now has C/C++ procedural access to both Cadence/Si2 OpenAccess and Synopsys Milkyway.

API or File Exchange?

The question is now whether you as an EDA tool developer should take advantage of the Milkyway and OpenAccess APIs, or stick with the classic LEF, DEF, Verilog and GDSII.

File exchange is appealing because it seems so easy:

• Virtually every other tool reads and writes the popular text file formats
• Readers and writers with APIs are available
• They are familiar to most everyone
• They are human readable (except GDSII)
• They can be edited manually or with Perl, sed or awk (except GDSII)

Unfortunately, time consuming problems lurk beneath the apparent simplicity of file exchange:

• File writers know nothing about where their data will go; file readers know nothing about the data source
• LEF and DEF are flat formats. The user must specify each individual design to transfer.
• Tools read and write their own incompatible dialect of the text file format
• Each file format represents only a single view of the design, so multiple files are required
• Multiple files presents the opportunity for file skew, where all files are not from exactly the same version of the design
• Each file format has its own unique semantics, which are yet again different from the semantics of the databases on either side of the file transfer
• More often than not, you must edit the files to fix some problem. The required edit is often particular to the tool version used and the individual design.

Therefore, “our tool simply reads and writes LEF and DEF” becomes much more involved in actual practice. Your AE and customer must:

1. Start with a perfectly good, cohesive design database
2. Tear it apart into giant files with incompatible semantics
3. Edit the files to correct problems
4. Add a custom configuration file containing additional missing data that is missing in the standard file formats
5. Read all the data in all the files, using command line options determined through extensive experimentation
6. Reassemble the data
7. Troubleshoot the inconsistencies:
   • Between writers and readers
   • Between files exchanged (including the evil file skew)

The trouble can be reduced by spending the time to build a solid flow and supplying it to your AEs and customers. A Makefile-driven flow is especially effective in reducing the risk of file skew.

If you are doing an evaluation, many weeks will pass as you repeatedly pester your prospect with requests for the right data. The sales opportunity may pass before your tool ever sees complete, consistent input data. When you present your results, your sales prospect faces another ordeal reading your data back into their design environment. By the time they finish, your results may not look so exciting.

Control in File Exchange Flows

The worst problem with file exchange is all the nasty things that happen to the design data before your tool even sees it, and what happens after your tool writes it. For example, consider how little control you have over the DEF input flow:

Someone else (often your competitor) controls the foreign database, file format, and the translation between them. The best they can do is blindly write the file, not knowing what you expect. It is very difficult for them to test their results. By the time you get the file, the data you need may be missing, erroneously translated, or even obfuscated.

You are in the same situation when it is you writing the file. Even with the best of intentions, it is difficult to know how the data you write will be interpreted.

Further, the interface problems will be different for each design style, each tool and each version of tool with which you exchange files. This is responsible for the profusion of confusing command options on all file readers and writers.

Next, let’s have a look at specific examples of file exchange interfaces for which there is no satisfactory solution, only an unstable workaround.

Case 1: Milkyway to OpenAccess via LEF and DEF

While Milkyway LEF Out does an fine job of creating LEF MACROs (cell masters),

• The LEF TECHNOLOGY section must be created either manually, or with a custom program
• The boundary of rectilinear macro blocks is converted to a rectangle

Milkyway 2004.06 has a much-improved DEF writer, write_def. Even so,

• def2oa cannot read the blockages output by write_def
• Identical cell instances appear multiple times
• Double cut vias and notch/gap geometries appear in the DEF SPECIALNETS section

If you are using an earlier version of Milkyway DEF Out, the problems are almost intolerable:

• The TAPER statement is incorrect
• DEFAULT vias are used in NONDEFAULT routes
• Vias are not properly rotated

These problems necessitate changes to the tech file, which causes delays because the library group must approve them. Worse, before writing DEF, all blocks must be re-routed with Astro using the new tech file. This kind of nonsense is often fatal to a benchmark or tool evaluation.

Case 2: OpenAccess to Milkyway via DEF

After successfully transferring the data to OpenAccess from Milkyway, you will see more problems on the way back to Milkyway:

• Inconsistent handling of bus delimiters will cause the Astro router to re-route parts of the design
• The above problem changes subtly depending on whether the bus in the original Verilog netlist was bit-blasted

This file transfer requires a custom Perl script for each DEF, because some busses may be bit-blasted and others may not. Any netlist changes may require a modification to the Perl script.

Case 3: LEF and DEF from Milkyway back into Milkyway

This should be a very straightforward flow. Not so.

• Since many individual files are involved, merely assembling a complete, synchronized set of LEF and DEF files is quite difficult.
• Only the most basic technology rules are translated from the LEF TECHNOLOGY section. Hopefully you have the original Astro tech file.
• Milkyway read_lef and read_def each output a Scheme side file that define and assign variable route rules. If your net names look like regular expressions (like bus[3]), the rule may be assigned to the wrong net, or to no net at all. Regardless, you must manually edit the file.
• read_def creates multiple ports on nets, which is illegal in Milkyway. Mower’s detailed diagnostics caught this error.

The above case studies cannot describe the full extent of the file exchange problems that anyone might encounter. Maintaining the translators and flow is a nightmare because the problems never end, changing from tool to tool, version to version, and design to design.

The API Flow

I have had as much success as anybody building and running multivendor design flows using file exchange. Still, their robustness and utility pales in comparison to the interfaces that can be built using a C/C++ API to databases like Milkyway and OpenAccess.

The API flow has several key advantages:

• Control over the entire translation
• Stability across tools, versions and design styles
• No translation to or from file format semantics
• Fast, in-memory data transfer
• Access to the entire hierarchy of a single cohesive database with all views
• Bidirectional data exchange, and even sharing the same design in memory

The API interface extends inside both databases in a multivendor flow, giving you extraordinary control:

Because the interface has access to the entire hierarchy of the input and output designs, the interface can automatically decide what to do, and translate with minimal user guidance. For example, when asked to translate a cell from Milkyway to OpenAccess, Voom Mower™ checks to make sure that OpenAccess contains all necessary child cells, and recursively translates the missing cells from Milkyway. In contrast, DEF interfaces depend on the user to specify which hierarchical cells to output.

Without the intermediate file format, only one translation, directly from database to database is required. Development is easier, because binary databases are similar to each other, but quite different from text files. Further, since all your design data is unlikely to fit in a single text file format, this single API interface replaces not just two file translators, but four, six, or even eight translators, each invoked on multiple files. It is then up to your support staff to help the users figure out how to correctly apply all these translators.

The data stored in design databases is remarkably accurate and stable across versions. This is enforced by the fact that inside the database, the tools all must eat their own cooking–even leftovers from last night’s version. The API gives your tool a seat at the same table with Astro and Virtuoso.

Conclusion

Design data interchange using text files is simple enough in theory, but in actual practice text files provide an unstable and incomplete interface. With text file exchange, if some tool forgets to write the data you need, they don’t care. That’s your problem.

For a reasonable up-front investment, your tool can have a robust, easily maintained, easy-to-use link to Milkyway or OpenAccess through a published API.

Get Voom

If your tools are based on OpenAccess, eliminate sales objections, save development time and instantly make your tools a part of the Synopsys Galaxy Design Platform. Get Mower, the industry’s only bidirectional Milkyway-to-OpenAccess translator.

If you use your own proprietary design database, we will apply our unique combination of Milkyway and OpenAccess application programming, tapeout and multi-vendor flow expertise to quickly make your software a natural, integrated extension of Synopsys and OpenAccess physical design flows.