James Roberts
Motorola

With all the great strides in performance, memory compactness, open-source, etc. that OpenAccess is making, our engineers keep reminding us of one key shortcoming of the OA data model: ease of use. The binary data model requires the API for access. Yet, the end users of OpenAccess are not full-time software engineers or C programmers—they are circuit designers, layout designers—and they strongly desire direct visibility into the database, along with the ability to perform simple tasks (such as adding a shape) quickly and easily. Additionally, API-only access only provides visibility into the database inasmuch as you know what it is you are looking for—and know the API call to get it.

This can potentially slow OpenAccess adoption, since presently these same designers are reading and manipulating netlists, such as Spice, Verilog, LEF/DEF, etc., to meet their needs—one anomaly OpenAccess is trying to move away from. Engineers are reluctant to move away from familiar ASCII formats in favor of an undecipherable binary that requires Makefiles, C libraries, C++ API training, compilation time, etc. just to access their own data. Yet, these multiple ASCII formats retain one key shortcoming: no single ASCII format is capable of storing all the information, for all legal viewTypes. Information loss invariably occurs at netlisting time. This results in all the things OpenAccess intended to avoid: application-specific formats, translators, multiple tool flows, auxiliary files, etc.

Thus, even with an OA API, the need nevertheless remains for an "OpenAccess" human-readable ASCII format: similar in concept to EDIF, but applicable to all viewTypes, and freely interchangeable with OA's binary data model. This enables the use of all our familiar UNIX text-editing commands—cut-and-paste, drag-and-select, regular expressions, Perl, grep, shell scripts, diff, emacs, etc.—to perform basic database functions. The API reserves the right to perform the more complex, compute-intensive functions, such as simulation and place-and-route.