Matthias Köfferlein 2025-02-21
The following is a opinionated view. I do not intend to give a complete specification here, just food for a discussion.
The text is a description of my personal preferences, as a user in an Analog-Mixed Signal context and as an Author of Open Source EDA Tools.
First, I would like to introduce the requirements from the AMS point of view. With this in mind, I would like to introduce a proposal that starts from OpenAccess, without fully adopting this API.
Instead, I want to provide ideas how to modify that system in a way more suitable for multi-paradigm flows and with priority on implementation opportunities with limited development power.
This section tries to summarize requirements for applications in the mentioned areas where
Analog/Mixed-Signal is the application of a design system for the design of circuits in the analog domain, with interfaces to digital circuits or integration of small-scale digital functionality (glue logic).
Such designs use a schematic hierarchy and connected layout views, with a strong focus on layout integrity, such as symmetry, parasitics or impedance-driven layout. Simulations are typically transistor-level using parasitics-annotated Spice-type netlists. In the advanced RF regime, field solvers are employed additionally to verify the design parameters.
Layout-Only: such applications usually do not integrate schematic views, but consist only of layout. Typical fields of application are MEMS or sensors, single devices, test rigs, holographic masks, micro-fluid systems, Quantum appliances etc. Such applications are strong candidates for Open Source Tooling as their niche character is not providing enough market potential to be attractive to EDA vendors. Typically such applications integrate strongly with specialized simulation tools such as multi-physics engines. Providing an infrastructure for such tools is an important corner stone for the design of a layout database.
Analog-alike applications include Photonics circuits with their waveguide-style layout method. Waveguides usually have a strong requirement to represent bended, wire-like features with a variable width and ideally based on Splines.
Some common characteristics of these applications are:
Low complexity: targeting transistor-level simulations, the maximum complexity of a circuit is maybe in the order of 1M devices. Layout complexity is in the same order in terms of flat polygons.
Smooth and curved polygon features: some of the mentioned applications require smooth and piecewise curved polygons. Also, curvilinear areas are often built from repeated parts and feature holes, which are hard to represent in conventional databases.
Macro capable: in AMS applications, the Analog design environment is typically not used for top level assembly. Instead macros are provided for integration into the chip, which is done in the digital flow (“digital on top”).
As a requirement, the design database needs to support export into a digital flow, hence providing typical features such as definition of routing aids (blockages, pins) and ability to generate digital flow information (such as timing views or LEF files).
Utility features for layout generation: as there is a strong focus on layout generation in these applications, a wide range of utilities have been developed, for which a proper database should offer support: PCells, layout generators, Multi-part paths, Via generators, stretchable cells etc. A database is not expected to offer these features as integral components, but to provide a framework for integrating a wide range of services.
Low level of abstraction: while in digital designs elements are typically idealized and modelled with simple approximations, Analog designs typically have to consider secondary effects such as the impact of process variations, asymmetry, substrate (current injection, noise, latch-up), cross-coupling etc. Hence, the main task of the AMS designer is tuning the circuit to control these effects. The tools used in that domain are typically highly interactive.
Design management: a strict requirement is to support design management - i.e. versioning of the design database in a configuration management system such as git. The file-based paradigm of OpenAccess integrates well with such systems and allows merging of different branches to some extent, providing the branches do not touch the same cell and view. Typically, some locking mechanism is in place to prevent parallel modification of the same file. git by itself does not provide such a lock mechanism, but it might be possible to add such a feature in a new database design.
Complex layout hierarchy: while in a digital flow, the layout hierarchy is typically rather flat (routing level, gate cells, macros), AMS designs feature various levels of hierarchy, made for accommodating layout elements for easy replication (symmetry, multiplier) and reuse. Several layers of hierarchy are not uncommon. The primary layout hierarchy matches the schematic hierarchy to support hierarchical extraction and verification.
I am using the term “AMS” (Analog Mixed Signal) for all mentioned fields of application, meaning low-complexity, tuned, “artwork-style” layouts and designs, in contrast to “compiled”, high-complexity designs emerging from an automated flow at a high level of abstraction.
A strong user requirement is easy installation and robustness. Also, the database should be available on a large range of operating systems. This specifically includes Windows, which still is accounting for more than 50% of the user base.
Some organisations restrict access to the network, so offline installation and operation is a must. This favors a file/directory-based storage paradigm like that of OpenAccess, combined with (primarily) local design management such as git. Using network shares for data exchange may be discouraged, if design synchronization through design management is implemented properly.
Memory requirements can be as high as several GB. As a rough guideline, consumer-grade hardware should be capable of handling designs up a 100k elements, with a memory footprint of less than 2 GB for the database.
The database API can be modern C++, but shared object exports should be C-level if possible to avoid ABI compatibility issues (to be discussed).
Binding of the API to script engines should not be restricted, yet lifetime management needs to be considered. For efficiency and for compatibility with future systems, the database should not implement support for specific scripting systems. A simple script system-agnostic paradigm is to consider script objects proxies or weak pointers into C++ objects inside the database.
(more to be discussed)
In comparison to a digital database, an AMS design database is designed for richness and data storage of artwork - not algorithms - while a digital database is optimized for efficiency and compactness and support for specific algorithms (like synthesis or place and route). To achieve this goal, a digital database operates on a high level of abstraction, not suitable for layout artwork or analog schematics.
In an EDA ecosystem, a database plays two roles:
Foundation Database or Live Database: a database build to serve the application and their algorithms.
In that role, the database is optimized for a specific representation and typical access pattern, as required by the algorithms running in the application. It does so by providing specialized data structures, caches, support algorithms and by employing specific storage models. Depending on the algorithm such databases may be optimized for CRUD (create, read, update, delete) cycles or CQRS (command query responsibility segregation) access pattern.
The design of the database as well as the coding details depend on the application. An editor application database for example will be CRUD style and support transactions for undo/redo implementation. A database for a verification tool will be CQRS, optimized for frequent and efficient queries, but without transaction support and poor performance on updates - if write ability is needed at all.
Data Pool: a database as a flow backbone or persistence layer.
In that role, the database will act as a data container for the inputs or outputs of a particular tool. The database needs to implement a universal data model - preferably extensible. No support for specific algorithms is provided, nor is the database optimized for specific access pattern. Instead, the EDA tools attached to it, utilize their own database, optimized for their particular operation and pull the needed data on initialization or push the results of the operation when finished. Optimization focus for such a database is on robustness and speedy bulk read or write operations. The data model should be simple and inherently consistent, so damage of data by faulty clients should be minimized.
A data pool-type database needs to implement access control, configuration management and client management. Ideally, such a database implements a notification hub to keep clients synchronized and informed about database updates.
For AMS applications, we are mostly looking for a database of the data pool kind. There is no common persistence layer available in the Open Source domain for AMS currently. The existing solutions are point solutions, like the XScheme schematics format, GDS for KLayout or Spice for transistor-level netlists and SPEF for parasitic annotations. These are all formats, i.e. persistence methods. To fuel a FOSS EDA ecosystem we first need to establish a common persistence layer replacing these formats by a common data pool.
At the far end of that vision there is a work bench, integrating various tools and based on that pool database.
OpenAccess appears to be a great candidate for such a database. It integrates analog and digital aspects and was build with universality in mind. However, there is some criticism on that database from my side (see below).
But we do not need to seek for a universal solution. As long as a database is good enough to support a particular sub-flow, we can separate these flows as a first step. A good database design should allow transfer of the design into another database - for example from an Analog into a Digital flow. For applications other than digital-on-top, we can stay in the AMS flow up to the final product.
By focussing on Analog, I am expecting a leaner design of such a database, with reduced design and implementation effort. The digital infrastructure can use a separate incarnation of a data pool. I am advocating this separation as I do not believe in a universal “one fits all” solution and in favor of simplicity and feasibility.
Eventually and as a second step, I want to propose creating some “master flow architecture layer” that wraps different sub-flows with individual data pools into a common design management and flow control environment. Such a layer can manage the aggregation of macros into a top level design.
OpenAccess is chosen as a basis for the discussion as it the specification is publicly available (https://oa22doc.github.io/help.html). Furthermore, OpenAccess is a well-established standard.
On the positive side, OpenAccess defines an API that (in parts) is well adapted in the AMS universe as it stems from the Cadence Virtuoso tool. This still is the de-facto standard in the AMS design.
Other positive aspects include:
Compatibility with Windows, which is a strong user requirement
The file-based view model integrates well with standard design management systems and is a useful storage model for AMS applications.
The documentation of OpenAccess is well written and comprehensible. OpenAccess without doubt is a great piece of work, bringing many good concepts into the public domain. It includes an number of great design decisions and was made with a professional application in mind. OpenAccess is not vaporware, but a solid basis.
However, despite the name, the reference implementation is not compatible with Open Source tools as (to my understanding) only Si2 members are permitted to develop software on the basis of the OpenAccess code.
For an FOSS EDA ecosystem, an alternative is required. At first glance, reimplementing the OpenAccess API in FOSS appears to be an option.
However, there are considerations that discourage this approach:
The OpenAccess software technology was defined in 2001 and it is time for a refresh. For example, multi-core compatibility (multi-thread safety) should be an integral part of a modern API.
The OpenAccess API appears to be overly complex in certain areas and tailored to flows that are no longer needed in the way they were anticipated. See later for the discussion of the overall structure of OpenAccess.
There may be legal implications when exactly reproducing the API. Parts may be patented for example and trademarks may be involved.
OpenAccess is likely to stem from a marketing campaign with the goal to strengthen the position of certain flows. So it is fair to suspect it was not made with universal compatibility in mind. Following a new design path might open options to rectify marketing-driven decisions.
OpenAccess is too feature rich, if not over-engineered for the purpose of AMS and alike applications. So some re-scoping is needed.
The OpenAccess documentation describes OpenAccess as the result of an attempt to join the former Cadence Design Database (CDB) with a digital database.
The nature of the digital DB is unknown to me, but I find some concepts that stem from LEF/DEF (for example the term “design” for the top level entity). In general, OpenAccess has a strong tendency towards LEF/DEF compatibility - see the LEF/DEF mapping guide (https://oa22doc.github.io/oa2lefdefmap/index.html). As LEF/DEF is inherently different from a typical mask layout database, this is not a promising basis.
Also, they tried to include somewhat foreign objects into the database (e.g. wafer, stepper map). The data model there is quite basic with only a few classes and attributes, so I doubt there is much practical use for them.
The result of that merge is not quite convincing in my point of view. The class hierarchy is pretty complex, specifically in the domain of geometrical objects and seems somewhat contrived.
So in the end, for example, the “oaArc” class, usually used in schematic symbols (and only there), has attributes describing shielded nets, because it inherits them from “oaShape”. This is the effect of folding routing information into a plain geometry database.
This is not just an efficiency issue, but it also makes it hard to validate objects or give guidelines for application development. If certain attributes are only useful in certain contexts and for some classes, they should not be part of a generic API IMHO.
In addition, connectivity attributes - specifically on a higher level, like shielded nets - are difficult to maintain during manual layout generation, if it makes sense at all to keep them there. Many layout editors have trouble, keeping even simple net connectivity assignments intact. So eventually, connectivity attributes seem to serve more an output purpose, when some physical implementation tool wants to store the results into some database.
So eventually, one has to carefully differentiate between generated objects and attributes and the artwork objects - and a database should clearly separate between these two. We call that a flow, with inputs and outputs in each step. OpenAccess, being a single database, tries to combine these separate aspects into a single data model.
I other areas, the concepts provided are biased towards digital flows. For example, concept of hierarchy domains (https://oa22doc.github.io/guide/emh.html) is very much aligned with the requirements of a digital flow. While the module hierarchy is deeply nested, the block hierarchy is viewed as a more or less flat sea of gates and macros.
In the AMS world, the situation is typically reversed and a layout hierarchy is richer than the schematic hierarchy. For example, a simple resistor divider (two lumped elements in the schematics) is represented by a number of cell instances (typically PCells) in the layout. This includes dummy elements not corresponding to a specific schematic element.
In general, OpenAccess tries to unify too many aspects in my opinion. Given the terminology introduced above, OpenAccess in large parts is a data pool (a container), while a number of aspects (like undo/redo support, boolean operations or region queries) qualify it as tool foundation or live database.
In my opinion, it is not wise to try integrating these two aspects into one database, as this leads to design compromises and increased implementation complexity.
Following the previous arguments, it appears natural to propose a downsizing, redesign and reimplementation of the OpenAccess API with the mentioned requirements and scope in mind.
Defining the new API is a task for a specific work package. I can only contribute ideas here. Details will follow if there is time. Eventually, this should give us the “data pool” database we are looking for.
We may additionally plan to provide a reference implementation for a foundation database, providing utility functions such as region queries or Boolean operations.
As the geometry API of OpenAccess is rather weak in comparison to rich libraries such as KLayout or other GDS handlers, this is an opportunity to provide more value to applications. However, I consider this step second priority as most tools already come with their own foundation database.
Also, a new brand needs to be created to avoid confusion with the existing OpenAccess project (“FreeAccess”?).
Tying these threads together, here is a proposal for an overall view of a flow and database architecture:
In the center of this design, the Design Management component is located. This component is responsible for creating file objects and putting them under configuration management. It also interfaces with network entities - the versioning system (Configuration Management, CI/CD systems or an Access Control database - the latter for example to manage locks).
Below Design Management begins the regime of some top level integration flow. This flow needs to manage the aggregation of macros into a chip in case of a “digital on top” design. Technically this is probably a synchronization task to export AMS components and fit these deliveries into a digital flow.
The proposal includes Sub-Flows, specifically for Analog and Digital components. This may also include other kind of flows, i.e. a Photonics flow.
The Sub-Flow architecture consists of a Data Pool DB, providing the persistence layer for the designs. The tools working on this layer, include their own Foundation Databases, which are loaded from the Data Pool DB and store results into the latter. The implementation of such a Foundation Database is tool specific and usually available already. As a prio 2 target, we may decide to provide a reference implementation for such a Foundation Database.
In summary, the proposal consists of the following work packages: