OpenAccess based architecture for Neolinear s Rapid Analog Design Flow

Transcription

1 OpenAccess based architecture for Neolinear s Rapid Analog Design Flow Bogdan Arsintescu, David Cuthbert, Elias Fallon, Matt Phelps Abstract Developing tools for today s analog and mixed-signal design market requires swift response to ever-increasing design complexity and shrinking time-tomarket windows. In this environment, a proprietary database would not only act as a barrier against tool adoption, but its maintenance would divert resources from developing core functionality. This paper describes the new Neolinear software architecture targeting analog and RF design flows. This OpenAccess (OA) based architecture allows Neolinear to quickly deploy its leading edge tools in our dynamic market. I. INTRODUCTION Neolinear s Rapid Analog Design (RAD) flow [1] enables users to achieve design closure with minimal iteration and provides a unified environment encompassing optimization algorithms for sizing, placement and routing. These optimization algorithms optimize the design goals and minimize second order effects to increase yield and manufacturability using design constraints. Analog specific design constraints, both electrical and physical, are shared between the optimization algorithms. The RAD flow must allow new optimization features and constraints to be easily plugged-in. The infrastructure for such a flow must provide: A full-featured, extensible EDA database for stable algorithm development Netlisting and constraint editing features to cater for analog and mixed-signal specific design annotations A scripting interface for designer s extensions and swift product prototyping and development. The core of the architecture uses OA as the Manuscript received March 12, The authors are with the architecture group at Neolinear, Inc., 583 Epsilon Dr., Pittsburgh, PA USA ( bogdan@neolinear.com). in-memory database. Its rich application programming interface (API) and schema features allow fast algorithm development on a standardized API. Furthermore, the OA extensibility API allows custom analog extensions to be developed and possibly migrated to standard OA objects in future versions of the database. The RAD flow requires extensive netlisting abilities and analog-specific constraint and parasitic annotations. We have developed custom netlisting and constraint modules based on OA s Embedded Module Hierarchy (EMH), extensibility, and parasitic APIs respectively. These features and the OA API are accessible for scripting to our customers and tool developers through both a Python binding and a Scheme/SKILL interpreter. While on-disk OA representation is desirable, our architecture also integrates easily with any legacy database through a host EDA system communication protocol without persisting OA data on disk. This protocol allows tools to plug into any custom-design platform (e.g. Virtuoso) through a thin communication layer that converts and synchronizes necessary design data between legacy databases and the Neolinear OA representation. This approach captures the market realities while allowing future-proof development using the OA standard. This paper is organized as follows. Section II describes the software architecture we have implemented for the RAD flow. Subsequent sections describe the major building blocks of the software architecture: the integration layer with legacy EDA systems (Section III), the netlisting and constraints module (Section IV), and the scripting interface we provide (Section V). The paper concludes with an example RAD flow and with algorithm integration details (Section VI). II. RIPLEY: THE BIG PICTURE Neolinear has code named our next generation architecture Ripley. This architecture, and the software packages that implement it, provide the infrastructure that all future Neolinear tools will be built on. The fundamental needs of future Neolinear products addressed by Ripley are: Rich, standard in-memory data model to represent our design data. Unified data model for application and algorithm developers regardless of the underlying native CAD system. Promotion of easy prototyping and rapid application development. Promotion of reusable modular software development practices.

2 RHC Ripley-to-Host Communication NCM Netlisting and Constraints Module Application rpyoa Ripley/ OpenAccess/ Python Interface Scheme/ SKILL Interpreter OpenAccess In-Memory Data Representation Python Scripting Language Figure 1: Ripley Big Picture The basic Ripley architecture, shown in Figure 1, uses OpenAccess [2,3] for the majority of its in-memory representation and information model. The other modules listed (RHC, rpyoa, and NCM) implement the behavioral changes necessary for our RAD flow applications. These modules all work together to meet the design goals for our architecture. OpenAccess and NCM (our customizations on OA for analog netlisting and constraints) provide the rich, standard inmemory data model. RHC (our interface layer to CAD systems) insulates our application and algorithm developers from the details of each CAD system. The rpyoa module provides a rich Python scripting interface to all of Ripley, allowing rapid prototyping by facilitating development in a high level scripting language. The Scheme/ SKILL interpreter, built on top of Python, provides a scripting environment familiar to most current EDA customers. Finally, by providing a well defined API for all application and algorithm development, we encourage reusability in our software modules. III. RHC VS. OA ON DISK The RHC (Ripley-to-Host Communication) module provides the capability for bidirectional communication between a host system and Ripley. These host systems are any of the large design frameworks provided by the largest EDA vendors (i.e. Cadence DFII, Cadence OpenAccess, Synopsys Milkyway, etc.). This methodology allows all data available in-memory through Ripley to be persisted in the host system s native format. This presents a number of advantages: No separate disk files/directories for Neolinear data. Compatibility and interoperability with platforms that do not yet support OpenAccess (or only support older OpenAccess versions). Compatibility with design groups not yet ready to migrate to an OpenAccess-compatible platform (numerous in the analog/ custom design world). These advantages point out the necessity of having a bidirectional communication API between the host system and Ripley. Utilizing a translation step or a one-way bridge (such as the Golden Gate project) does not facilitate the kind of interoperability with legacy frameworks that are required for our applications. The RHC module itself is made up of three primary parts, shown in Figure 2. A standard API for passing data between Ripley and the host is defined, known as the RHC API. It uses the IPC mechanism for its syntax. Neolinear has developed an IPC mechanism, known as Wombeyan, to be slightly more host and platform portable. The RHC API is defined using OpenAccess semantics [2]. Therefore the meaning of terms such as lib/cell/view, net, or instance are all the meanings that OpenAccess uses. These semantics are then translated into the semantics of the host CAD system for read/write on the host side of the RHC. The RHC API provides a set of calls on both the host and Ripley sides. This allows the Ripley RHC - Host Side API: Embedded in Host CAD System (e.g. Cadence DFII) IPC Mechanism: Wombeyan RHC Ripley Side API Figure 2: The Ripley-to-Host Communication Architecture

3 architecture to request information from the host CAD system, as well as allowing the host CAD system to trigger events in Ripley (or any Neolinear products using Ripley). Most communication between the host system and Ripley will happen automatically without the need for particular algorithms to request the information. This is accomplished through extensive use of OA callbacks on data to automatically request and update information from the host CAD system. Leaf OpenAccess cell views in the design hierarchy are implemented by OA pcells that automatically get updated information from the host CAD system whenever parameters are changed or the cell view is re-opened. All of this functionality allows the users of the Ripley architecture to use data in the native OpenAccess framework without any knowledge or responsibility towards the integration with various host CAD systems. It also allows deep integration of Neolinear s products into various host CAD systems without customization of the products themselves, as only the host side of the RHC API must be customized. IV. NETLISTING, PARASITICS AND CONSTRAINTS Custom analog flows need extensive netlisting abilities to size and optimize a circuit, define logical to physical mappings and create a flattened layout. Parasitic models are needed to model the second order effects in order to yield high-performance layout with the minimum number of iterations. Furthermore, design annotations are used in custom design to constrain optimization algorithms and editing features and to tailor the design space based on each designer need and expertise. This chapter describes the use of OA features and custom extensions developed for Ripley to provide the above functionality in our tools. The Embedded Module Hierarchy (EMH) in OA [2] provides an excellent open-ended way to traverse folded layout hierarchies. However, with the current limitations in the OA-2.1 release with respect to configuration traversal and with the variety of host-specific netlisting requirements that Ripley supports, we have developed, based on EMH functionality, a netlisting ability that provides all the required functionality for our flows. In order to support configuration and flattening of the layout at the same time, the Ripley netlister creates an embedded hierarchy where all the netlisted branches are module-only instances (oamodmoduleinst of oamodule [3]) and the leaf nodes are block level instances (oamod- CellViewInst of oacellview [3]). In this way, the connectivity source configuration hierarchy and the flattened layout are stored in the same oacellview in the module and block hierarchies respectively. Moreover, once the embedded hierarchy is created, Ripley is independent of the host CAD system and all the data required for our RAD flow is contained in the OA cell view. At the block level, the layout is flattened correct by construction and the minimum amount of design data needs to be eventually collected from the host CAD system through RHC. Incremental ECO is enabled by fast tree comparison between the folded EMH module tree and the host CAD netlister and propagates to the unfolded block hierarchy. This approach is fully OA compatible, no custom extensions are required. Future OA versions that provide netlisting features will provide an alternative way of building the embedded module hierarchy from native OA data. In such a scenario, ECO becomes a natural OA comparison between two module trees, one from the OA netlister and the other from the one embedded in the Ripley generate cell view. This netlister supports all host CAD system netlisting and configuration that Neolinear supports. The Neolinear RAD flow relies on parasitic models to converge the design through the iterative optimization of the connectivity source and the corresponding layout. To achieve this goal, Ripley architecture employs the oaparasiticnetwork objects to augment the original netlist with passive models of the second order effects. The parasitic networks are generated by our estimators or using host EDA layout extractors. Using the OA parasitic network preserves the LVS integrity with respect to the original host CAD netlist or design configuration. Analog design tools rely on design annotation to capture designer s intent and expertise. In the front end, parameter ranges, device matching and device parameter relationships drive the sizing optimization algorithms. In the back end, users control the placement and routing algorithms using logical-to-physical mappings (a.k.a. physical modules) and geometric constraints (e.g. layout partitioning, symmetry, alignment) to reduce the design space. Front end circuit optimization algorithms annotate the design in the module and eventually in the occurrence domain, because the block domain might not be fully realized at the time of the annotation. These annotations are stored on the OA EMH objects through standard OA extensions such as custom attributes, groups and properties. These extensions are encapsulated in NCM

4 objects, which provide the applications with the required functionality through the object methods but hides the actual storage. Such approach allows easy migration when native OA objects will be available for storage. Logical-to-physical mapping is stored using OA cluster objects. The Ripley architecture relies on a restricted cluster tree structure to define and store both physical module and cell planning information. Physical modules are a collection of block level devices together with arrangement and routing information. The devices are grouped in an OA cluster and the arrangement and routing information are stored on OA extensions. Multiple cluster boundaries provide placement algorithm encapsulation, editing unity and variant computation and selection without geometry generation. The layout hierarchy supported by Ripley architecture can contain any disjoint combination of clusters and block instances. This layout hierarchy enables layout planning editing modes. Custom physical design and especially analog physical design relies on geometric relationship of the block instances. Matching attributes of block instances or clusters are stored using the same extensions used for front-end matching constraints. The most important physical design constraints, namely symmetry and alignment, require OA extensions as of the OA-2.1 release. Both symmetry and alignment rely on an abstract object in the block domain, namely an axis. Given the axis object, symmetry, alignment and ordering have straightforward close-ended mathematical definitions. Symmetry implies mirroring around the axis. Alignments and orderings refer to the axis for offsets and order references. We have defined the axis as an extension OA object oaappobject. The axis has as attributes the direction and an optional support, the latter either a fixed point or relative to a block domain object. The constraints using the new axis objects are collections using the appropriate attribute set, as required. Access to these constraints and the axis objects is encapsulated in a module that hides the implementation detail from the user. This, again, allows easy migration when OA will provide analog constraints support. In summary, the Ripley architecture provides a netlisting and constraints module (NCM) that encapsulates access to OA objects required for custom analog flows and provides consistent netlisting and constraint management features to our optimization algorithms and editing features. The OA cell view data created using Ripley architecture is compatible with any application with the exception of analog constraints, not yet supported by OA. V. SCRIPTING AND INTERFACE The Python scripting language was chosen for its rich library, support for object-oriented programming, and ease of extensibility in C and C++. In addition, using a widely adopted language eliminates the need to develop training materials and reference material on the basics of the language. Python, however, is a relatively young language, and has yet to see adoption by any of the major EDA vendors. However, a number of CAD systems use Lisp or Lisp-like languages as both their data representation and extension language. To provide a familiar interface for these users and to enable the direct-reading of their data files, a Scheme/SKILL interpreter was created. Written in Python, it uses the language s introspection features to provide a direct mapping between Scheme and Python objects. Although it strives to be compatible with the current Scheme specification [4] and the Mz- Scheme implementation [5], some of the functionality is missing (e.g., call-with-current-continuation and the full numeric tower) due to the limitations of Python. The rpyoa Python/OpenAccess binding, written in C++ using the Python-C API [6], exposes the full OA class hierarchy and API. In addition, objects of classes inherited from the oaobject [3] class have a one-to-one mapping between their C++ and Python counterparts; that is, conversion from a C++ object always results in the same Python object, as one would expect if OA were implemented in Python itself. Most of the remaining classes are implemented as immutable types and are converted between Python and C++ though copy-by-value semantics. The remaining classes are the OA callback classes. In order to allow Python extensions to implement callbacks, proxy C++ classes and stub Python classes are used. The proxy classes implement the callback on the C++ side and invoke a Python method (performing the necessary formatting). The stub class provides a base class for the Python callback implementation; the default implementation of each callback method is a no-op. Because Python offers run-time checks not available in C++, most of the extensions to Ripley are expected to be implemented in Python. Only the speed-critical algorithms are expected to be implemented in C++.

5 Circuit Space Prototype Space Annotated Design Automated Design Interactive Automation My Space Sizing/Resizing Design Structure Hierarchy Design Annotation Automation Assisted edits Figure 3: RAD Top-Down Design Flow VI. ARCHITECTURE IMPLEMENTATION AND ALGORITHM INTEGRATION EXAMPLES The Neolinear RAD flow enables users to achieve design closure with minimal iteration and provides a unified environment encompassing optimization algorithms for sizing, placement and routing. Figure 3 illustrates how designers achieve their goal starting from a generic circuit space (an un-sized schematic or netlist) and successively confine this design space into the final design point. The left part of Figure 3 illustrates the design space throughout the design phases: initial circuit sizing provides a design space that the user can prototype by assigning design hierarchy and design specific annotations. Though successive iterations, using constraintdriven placement and routing, constraint and parasitic aware resizing, and incremental changes to design annotation, the designer optimizes the design to a final design point. This point must meet the design specifications and must also encapsulate each user s custom design art. The tools and optimization employed, shown in the right side of Figure 3, communicate and iteratively refine constraints as shown by the arrows to the right of the rectangles. The tools and algorithms in our flow modify the OA database to reduce the design space using netlisting, design annotations and constraints as described in the Ripley software architecture. In order to achieve design space closure, the iterative flow in Figure 4 is proposed. The RAD flow [1] in Figure 4 is a top-down design flow with bottom-up assembly and re-estimation. In this flow, each top-down design step employs Neolinear tools and optimization algorithms to reduce the design space based on the design goals, the parasitic information, and the current set of constraints. The bottom-up verification stage validates the goals and eventually updates the second-order effects and the constraints with more accurate values measured or estimated from the current design point. The user may also customize the design annotation for the subsequent iteration. In what follows we describe how our algorithms are integrated with the Ripley software architecture by means of a simple flow example. In this example, we start from a host CAD schematic representation that we size, layout and route, then we save the resulting layout back in the same host CAD system. The design cellview is created through a RHC call to the host CAD system netlisting. The result of the netlisting creates a module hierarchy in the OA cellview. The leaf nodes of the hierarchy are the devices that need to be sized and laid out by RAD optimization algorithms. In Ripley these leaf device masters are OA pcell cellviews, which allows us, via RHC, to have a bidirectional synchronization and ECO mechanism with the host CAD system. Together with the netlist, we collect all supported annotations that RAD supports, such as host CAD constraints or RAD constraints already stored in the host CAD system in a previous session. The user annotates this embedded module hierarchy with constraints that are stored in OA objects as described in Section IV. Parasitic annotation creates net models using oaparasiticnetwork objects for each flattened net in the design. The RAD sizing algorithm integrated with Ripley collects the netlist information, parasitic and annotation data and employs a third party simulator to yield a sized circuit. Since all devices are OA pcells, the information is automatically annotated into the host system through RHC. Once the circuit is sized, the geometry is generated for each pcell instance using either Neolinear custom devices or the host CAD pcells or cellviews. The user may annotate this design further with physical level constraints and employ automated placement and routing algorithms. These algorithms are constraint and parasitic aware. The resulting placement can be saved into the host CAD system database, together with the annotations, at any time. Further resizing iteration loops are possible upon user decisions, given more accurate parasitic estimation and new design annotations. Integrating a different CAD system with the Ripley architecture requires the ability establish a communication channel through which the netlist, the layout and our annotations can be synchronized between the host CAD system and Ripley. Such a link is not required when the host CAD system also uses OA; Ripley can operate

6 Sizing/Behavioral description Partitioning/Planning: Functional/logical Structural/physical Inter-block and Interconnect constraints Estimators Size Parasitics Congestion Update estimates & contexts, parasitic annotation Functional verification Context validation Block Context Encapsulation Placement & Routing/Polishing Hierarchical Blocks + Context constraints Block Assembly Block Authoring Figure 4: Detailed RAD Design Flow natively on OA libraries (assuming the versions are compatible). Integrating and developing new algorithms for RAD requires the algorithm developers to decide which OA features to support and eventually which extensions are necessary, for the few cases where OA does not provide the required functionality. In our experience, the main problem is not the lack of features in OA but rather keeping up with the meaning of all object attributes such that the resulting database is handled correctly by all tools and eventually third party tools. VII. CONCLUSIONS The Ripley software architecture enables a next-generation Rapid Analog Design flow by leveraging the OpenAccess reference implementation as an in-memory database. Custom modules have been built (1) to support legacy host CAD systems or native on-disk OA libraries, (2) for flow-specific task and consistent algorithm integrations, e.g. netlisting, constraint and parasitic annotation, and (3) to provide a scripting interface for users and tool prototyping. The use of a remote host communication protocol enables synchronization with any host CAD system and allows algorithm developers to focus on using the rich OA API. Finally, the flow example in Figure 4 illustrates how this architecture meets the data communication and integration requirements of our tools. REFERENCES [1] Neolinear, Inc., Rapid Analog Design for A/MS, /solutions/nav/analog, January [2] Silicon Integration Initiative, OpenAccess 2.1: The Standard API for Rapid EDA Tool Integration, SI2, First Edition, October [3] Silicon Integration Initiative, OpenAccess C++ API Documentation, Version 2.1.1, August [4] R. Kelsey, W. Clinger, J. Rees (eds.), Revised(5) Report on the Algorithmic Language Scheme, Higher-Order and Symbolic Computation, Vol. 11, No. 1, August 1998; ACM SIGPLAN Notices, Vol. 33, No. 9, September [5] M. Flatt, PLT MzScheme: Language Manual, doc, March [6] G. van Rossum, F. L. Drake, Jr., Python/C API Reference Manual, Release 2.2, Python Labs, 2001.