Semiconductor manufacturers such as Infineon need efficient design flows that can deliver accurate results in less time for larger designs. Traditional flows typically include a diverse mix of proprietary database, file formats and tool interfaces that lead to slower tool iterations, database integrity issues and longer development cycles as design sizes stretch the capabilities of previous generation environments.
By removing inefficiencies associated with these earlier flows, engineers not only eliminate error-prone steps but also recover valuable time needed to accommodate increased design and analysis associated with leading-edge ICs. In deploying OpenAccess in its mixed-signal production flow, Infineon encountered familiar issues associated with any effort involving migration to a new data model. Most important, however, the migration to OpenAccess has already delivered significant improvements in tool runtime and design cycle performance in a critical resimulation subflow.
The market demand for faster availability of more sophisticated analog/mixed-signal devices can only be met with highly efficient tool flows. Designers should be able to exploit improved process integration capabilities, increased transistor counts and higher clock rates to deliver next-generation ICs with dramatically greater functionality and performance.
At the same time, the continued acceleration of complexity in mixed-signal IC design presents an evolving challenge for designers charged with ensuring correct silicon while meeting tight product schedules. To effectively address emerging requirements, designers need ready access to commercial and proprietary tools that are interoperable with each other.
The task of adding a new tool to an existing flow has typically meant creating scripts, building tool wrappers or modifying the tools themselves to accommodate specialized formats and application programming interfaces (APIs). With growing tool diversity, however, companies face untenable resource, schedule and cost requirements associated with specialized tool interfaces. As a result, engineering departments require more effective solutions to streamline production flows comprising both commercial and proprietary tools that operate over a common open-source standard API and associated reference data model.
To meet business and technical needs in advanced mixed-signal designs, Infineon required an efficient common data model to enhance Infineon's mixed-signal Freeway design flow with greater interoperability among in-house and commercial tools, faster tool performance, reduced cycle time and greater design capacity. To support the enhanced flow, Infineon chose the OpenAccess data model, because it provided a production-ready combination of interoperability, capacity and performance as well as the open model needed to meet emerging mixed-signal design requirements.
OpenAccess is unique in providing the IC design industry with an open-source, standard, production-proven database. As an open-source standard, companies can deploy OpenAccess as needed and even adapt the available source code if required to meet their unique needs. OpenAccess itself is managed through the OpenAccess Coalition, a user-driven coalition of end-user and vendor companies.
Built in C++ with state-of-the-art, object-oriented software technology, OpenAccess was developed to minimize memory utilization, enabling it to support large designs. Most important, OpenAccess is a single, unified database system that provides a comprehensive data model which removes the barrier to deployment of more innovative design tools.
Diverse tools running on multiple platforms can interoperate through a consistent API and common data model, streamlining flows by eliminating delays inherent in data translations and format conversions that stretch cycle time in typical flows. Aside from OpenAccess's performance benefits, the open source model for using OpenAccess offers a distinct advantage for today's budget-conscious engineering departments.
On the back end, OpenAccess's data model is tuned to meet the specialized requirements of the IC design community, providing well-defined semantics for IC design from register-transfer level (RTL) to silicon. Within the OpenAccess data model definition, tools can access native objects for connectivity, hierarchy, geometry, place and route information, and more.
With OpenAccess, tools gain direct access to the data model, and OpenAccess's architecture enables fast read/write into the database. Furthermore, engineers can extend OpenAccess to address custom requirements or emerging applications such as design for manufacturing (DFM), while retaining the ability for diverse tools to share direct access to design data objects.
To deploy OpenAccess, Infineon defined a series of development phases designed to migrate Infineon's Freeway mixed-signal design environment with minimal impact on Infineon designers themselves. Comprising third party vendor tools and Infineon-proprietary tools, Freeway draws on both a third party vendor's proprietary design database and various proprietary file formats, using multiple Infineon conversion tools to handle translation among these data formats.
By standardizing Freeway on the OpenAccess database, Infineon expects to boost designer productivity by reducing tool run time and overall cycle time. In the process, designers should find a reduction in the number of error-prone steps associated with data translation and conversion, while gaining tool capacity and performance needed for more extensive design analysis. As its eventual goal, Infineon plans to completely replace the existing third party vendor's proprietary database with OpenAccess and port all in-house tools to use OpenAccess natively.
As the first step in this phased deployment, the Infineon deployment team focused on an existing analog resimulation subflow. This subflow serves as a critical step in Freeway, yet exhibits long cycle times due to multiple data conversion steps and the extraction step. By eliminating those conversion delays, an OpenAccess-based implementation of this flow would ideally offer increased performance required to meet the overall cycle time objective.
The resimulation flow uses a third party vendor tool for layout extraction and creation of an extracted design view. After extraction, an Infineon in-house tool reduces the number of RC parasitics in the extracted view without measurably modifying the design's physical behavior. In turn, the reduced data set serves as input to an Infineon Spice tool, which simulates the resulting Spice netlist and provides a result that could, in turn, require repeating the re-simulation flow until the desired results are achieved.
The previous resimulation flow was very time-consuming, largely due to the proprietary solution currently needed because of the inability to read/write directly from/to the third-party vendor's proprietary database. Here, a Skill-based program writes out all necessary data into a Spice-like netlist. The RC reducer parses this netlist and performs the reduction.
The result of that reduction is either a Spice netlist, which can then be simulated, or a file containing Skill code. This Skill file is loaded back into the third-party software, while the original extracted view is copied and reduced with the help of the Skill code.
In this flow, generation of the new extracted view using the view copy and the Skill file takes about 90% percent of the entire reduction time. The run time of the reduction tool itself is about 5% of the full RC reduction run time, so elimination of the Skill steps promised a substantially faster cycle time. This involved rewriting Infineon's in-house RC reducer tool in C++ and porting it natively on OpenAccess.
From a CAD point of view, the task of migrating and porting the existing resimulation subflow from a proprietary database to the OpenAccess API and data model was straightforward, although it involved mutiple steps. In particular, Infineon's RC reduction tool used a data model similar to the OpenAccess data model, simplifying the task of mapping this proprietary model to the OpenAccess model. The complete flow migration required the following steps (see Fig. 1).
- Porting Infineon's RC Reducer tool algorithm natively to the OpenAccess data model.
- Migrating Infineon's device libraries and standard-cell libraries to OpenAccess using a third-party OpenAccess translator utility, which performs the necessary conversions on a specified library.
- Creating Skill context files for all Infineon-specific Skill packages.
- Copying all scripts and context files that form the Freeway kernel to a specific directory.
- Creating a new project a UNIX home directory where the design will be developed and all design data will be located.
- Migrating design-specific libraries to OpenAccess using the third party OA translator.
Figure 1 Infineon mixed-signal simulation flow
Native porting involved mapping the existing RC reducer tool's data model to OA, which was a straightforward task because OpenAccess offers a very rich data model. The second step involved rewriting the port natively on OA. This step included rewriting the RC Reducer algorithm in C++ from Skill to provide a better performance boost.
Usually a native port involves just porting an existing algorithm to OA through the API. In this case, the deployment team also discovered some inherent technical issues with the legacy algorithm during rewrite and had to redevelop the algorithm. Overall this effort, including testing, took about four months with one full-time and one part-time engineer because of the need to rewrite the algorithm.
The following code example demonstrates the OpenAccess native port. This code traverses all of the nets in a cell view and runs an RC reducer on the parasitics associated with the nets. This algorithm should only be run on a given net if that net is not connected to a terminal (also known as ports or pins), and if it is connected to at least one instance terminal. Thus, the code performs this check before it runs the reduction algorithm.
Any migration effort involving commercial and proprietary tools is likely to encounter specific issues that lie outside the scope of the standard database definition. For example, in this case, the migration team needed to access specific elements of vendor-specific data stored in the OpenAccess database.
OpenAccess is very extensible, providing the capability for developers to create an extension API to handle design-environment-specific requirements not explicitly addressed in the standard OpenAccess data model or API. In this case, the migration team simply created an extension API to access the required data elements contained with the vendor-specific data.
Finally, the migration team validated the migration for the device libraries and the design libraries on the front end side by creating a Spice netlist and performing a schematic-versus-schematic check afterwards. Along with XOR checks of migrated layouts, the team performed layout-versus-schematic checks in the OpenAccess environment.
The primary test effort, however, revolved around the RC reduction tool. Ideally, this type of migration might be validated by directly comparing outputs generated by the old and new deployment. In this case, however, the old tool used a reduction algorithm whose results depended on which node in the av_extracted view serves as the start of the reduction procedure.
Thus, the team could not simply compare the reduced av_extracted views by creating a Spice netlist in the proprietary data model based flow and a Spice netlist in the OpenAccess-based flow, and perform a schematic-versus-schematic check using the third-party tool. Although the av_extracted views do not have the same topologies, they do have the same electrical behavior.
Consequently, the team was able to use a specially constructed simulation test bench to compare results from the two flows and confirm successful migration. The need for more involved validation efforts like this is not an OpenAccess issue, but one that faces any engineering team involved with migration to a different data model.
OpenAccess deployment results
From a user point of view, the OpenAccess-based flow looks the same as the proprietary data-model based flow; the differences are largely transparent to the user of the flow. The graphical interfaces provided by the design tools are identical in both types of flow. Even the control files for the third-party tool and the RC reduction tool are the same.
On the other hand, the performance differences between the earlier flow and the OpenAccess-based flow are substantial and significant. Because tools directly access the data in the OpenAccess-based subflow, the new subflow eliminates the need for the time-consuming Skill steps. Here, the RC reducer directly accesses the OpenAccess data to read in the extracted view, and the tool performs the reduction to generate a new extracted view within the OpenAccess database.
For a test case design, comprising 60K designed devices and 450K parasitics, this streamlined flow increased RC reduction tool performance alone by a factor of ten. For the same test case, this OpenAccess deployment has reduced overall cycle time of the OpenAccess-based resimulation subflow by a factor of three compared to the earlier version of this subflow.
The size of the layout and extracted views has dropped by only a few percentage points. This minimal change is not surprising, because a flow migration alone has little effect on the size of such views. To gain maximum size reduction, all tools in a flow need to use native OpenAccess objects a future effort in Infineon's full migration plan.
In this particular OpenAccess deployment, the primary performance gain is directly related to the ability of the RC reducer tool to access the database directly. Because the data model in the earlier reducer was designed specifically for the reduction task, the change to the OpenAccess data model did not significantly improve performance.
The straightforward migration of this critical subflow by a small number of engineers has demonstrated OpenAccess's ability to significantly improve complex mixed-signal design tool flows. Although the migration of purely Skill-based applications to C++-based OpenAccess code can be time-consuming, the full migration of this subflow was achieved more quickly than expected.
Familiarity with the OpenAccess C++ API is vital, and the participation by the Infineon team in a 3-day OpenAccess training workshop proved very useful during the migration effort. Flow developers responsible for configuring tools should be sure to know about the compiler used for OpenAccess as well as the version of OpenAccess used for any third-party software, particularly if proprietary tools are also used in the flow.
Because there are different versions of OpenAccess (2.0, 2.1, and 2.2), it is important to link to the correct version of the shared libraries as well. Designers will need to know which C++ compiler was used for compiling the shared object, because the same compiler must also be used for any in-house OpenAccess-based applications.
In this case, the design team used the Forte C++ compiler to implement the RC reducer on the Solaris platform. Because the Forte compiler is not available on Linux, the design team used gcc and performed the necessary adaptations needed to successfully compile the code on the Linux platform.
During this deployment effort, the migration team did face a data-semantic problem with proprietary data associated with a third-party tool. The team developed the necessary understanding of the data semantics to use the data and created an extension to access the data.
As noted previously, OpenAccess is extensible, so developers can create appropriate OpenAccess extensions as needed to deal with proprietary data. Although this method does provide a pragmatic solution to this common problem, such extensions can require additional maintenance work to ensure that any extensions continue to work properly with subsequent versions of OpenAccess.
With the migration of the resimulation subflow, the migration team met its key objectives and is currently extending the OpenAccess deployment to backend layout for porting Infineon's layout generation tool natively on OpenAccess using the C++ p-cells in OpenAccess. The main motivation for extending the OpenAccess deployment project to the layout generation flow is to realize the same performance, capacity and interoperability benefit in the backend mixed-signal production flow as achieved in the front end resimulation flow.
Currently, Infineon uses a C++ program to generate Skill-based parameterized cells in its mixed signal flow. This project aims to enhance this application with the ability to create an OpenAccess database directly through C++.
The primary tasks here include: interfacing the Infineon p-cell generator to OpenAccess, building an OpenAccess output model from the Infineon p-cell generator, constructing an interface from the OpenAccess p-cell evaluator into the generated p-cell, building a supermaster generator, and making required changes to the OpenAccess C++ p-cell evaluator algorithm. Infineon expects to achieve a performance gain greater than 2-fold and put in place OpenAccess p-cell generation enhancements.
By providing direct access to design data, an OpenAccess-enabled flow reduces the number of error-prone steps inherent in traditional flows. OpenAccess's ability to considerably improve tool runtime performance and cycle times along with interoperability advantage has allowed Infineon's engineers to maximize design analysis rather than face ongoing data-conversion delays.
For Infineon's resimulation subflow, OpenAccess successfully demonstrated its ability to enable improved performance, interoperability and cycle time a fundamental necessity for IC designers facing growing design challenges associated with advanced deep submicron technology. OpenAccess's robust architecture and its high quality implementation ensures its ability to support complex mixed-signal design production flows, and its flexibility is well-suited for supporting the evolving needs of advanced mixed-signal IC design.
Thomas Heiter is manager of design flow development at Infineon Technologies in the central CAD group located in Munich, Germany. As project leader, he is responsible for 'FreeWay', the mixed signal part of the Infineon Design Flow 'InWay'. Before joining Infineon, he was with ITT Semiconductors in Germany for 5 years, focusing on digital simulation, synthesis and technology migration.
Joachim Glas joined Infineon Technologies in 1997 and is working as an engineer at the Design Flow Development team in the central CAD group located in Munich, Germany. With more than 7 years of CAD experience, he is responsible for the migration of the mixed-signal design flow to OpenAccess.