Inside SI2’s OpenPCell Workshop

In the last Standards and Beyond blog, we provided background on the Open Process Specification, including where pcells fit into the overall picture, and gave an invitation to the OpenPCell workshop being hosted by the Silicon Integration Initiative (Si2). The ensuing workshop, held on Jan. 29, was well attended with more than 35 companies represented across the globe. It was a gathering of many longtime pcell developers, representing foundries, design houses and EDA vendors in person and over the Web. As is usual when pcell developers gather, there was lively discussion about the OpenPCell strategies being developed by the Si2 working groups.

The workshop was kicked off with a presentation on the results of an Si2 survey on pcells. This survey, done one-on-one with industry experts, pointed out that the requirements for Pcells were dependent on the client; fabs wanted a multivendor solution, design houses were more single vendor focused, EDA vendors wanted their tools to be supported, and everybody needs better testing.

The OpenPCell workshop accomplished even more than had been planned. First of all, it validated the multipronged approach and the importance of the XML standard. Likewise, there was interest in the language solution and more interest will be generated as the API’s are solidified. Testing is just getting started, and a plea went out for more inputs and more members for the working group. As a follow-up to the workshop, Si2 has recently sent out an OpenPCells needs and requirements survey, so stay tuned at DAC for reports on the progress Si2 is making in OpenPCells. It is always good to get together with other pcell developers, the discussions were lively and, even after 30 years, I always learn something new.

Process design kits (PDKs) are targeted to design flows, which are becoming more heterogeneous, despite the best efforts of the big EDA vendors. A major source of contention is the pcell implementation language. Multiple languages can be used to implement a pcell. SKILL and the Python PyCell APIs are the most common languages, but pcells are coded in other languages, as well. AnaGlobe’s GOLF and Cadence’s Virtuoso Graphical Pcell Designer both support languages based on creation and editing of objects through a graphical interface, and Phoenix developed its own pcell language to ameliorate problems caused by changes to Open Source libraries.

In order to provide value to pcell developers targeting either single or multi-vendor design flows, Si2’s OpenPCell effort splits the definition of the pcell from the implementation grammar and the pcell testing. The definition is in the Open Process Specification (OPS) XML repository and is language agnostic. The testing definition is a developing subset of the OpenPCell XML repository, which is the initial testing implementation for the OpenPDK efforts. For those supporting multiple vendor implementations, the OpenPCell Common Description Language Grammar, independent from the other two sections, specifies a high level language that can be translated into the implementation languages of the design tools. The working groups share a common motto: “Write once, use many, (test forever)!”

Discussion on pcells can be contentious, especially when it comes to their implementation languages, but there are several areas of agreement. The pcell definition, including the operational parameters and the PDK integration values, can be shared across the various implementations. No matter what implementation language is used, the pcells must be tested in the design flows to ensure high quality. The OpenPCell strategy, to address each of these issues separately, allows users to participate in the working groups where they have interest.

OpenPCell XML repository
The pcell is defined by a set of parameters and an evaluator, which operates on the values of those parameters. The pcell superMaster is a cellView in an OA library that has a set of operational parameters (OpParams) whose values are set when the device is instantiated. If the instance has a unique set of parameters, the evaluator associated with the pcell is executed—calculating and creating the objects in the master of that instance. In addition to the OpParam values assigned by the user, the PDK supplies process data, which ties the pcell into the PDK. These PDK parameters (PdkParams) set the layers, rule values, terminal names and any other data that are unique to the process. The same evaluator code may be reused with different sets of device specific PdkParams to create different devices in the same device family. The OpenPCell XML Repository contains the pcell specific OpParams and PdkParams, these are shared across the multiple language implementations. Every evaluator gets the same data, regardless of the pcell implementation language. The OpenPCell XML standard is language neutral, supporting legacy languages as well as any new languages.

At the workshop and in the interviews, it appeared that the OpenPCell XML standard had the greatest interest. Fortunately, it is nearly complete. A status was given at the workshop as it moves towards adoption in April. If you have interest, please seek out the SI2 booth at DAC where Si2 will present an update and working group members will be providing demonstrations.

The OpenPCell XML standard is a subset of the OpenPDK Process Standard (OPS). It shares many elements with other OPS data standards, Design Data Format (DDF – CDF/ICDF) and Tool Interface (TI) standards, allowing the PDK generation tool to use the same data to create the design flow specific PDKs.

Language grammar
The common language grammar is useful for those who need to output PDK’s that can target different vendor design flows. The pcell code is written in a description language that also supports callbacks such as CDF/DDF callbacks, abutment functions and stretch handle user functions. The description language is based on a restricted version of Python, the abstract syntax tree can be parsed and translated into other languages but the target implementation languages impose some restrictions on some of Python’s polymorphic operators and other language constructs. Intel has contributed a prototype translator, PyXlate, which tests the translation of the basic language constructs into common languages. At the OpenPCell workshop, James Masters of Intel gave a presentation and demonstration of PyXlate in action.

The description language will include a set of behavioral APIs that define the actions to be taken in callbacks and pcells. An analysis of the most common languages, SKILL by licensed users and the PyCell APIs from the contribution by Synopsys, shows much common ground…but there are differences. To create a named rectangle as a pin in SKILL takes a single function call while it takes three function calls using the PyCell APIs. Conversely, to assign abutment properties with the PyCell APIs uses one function call, while in SKILL it takes multiple. Other languages may not even have the concept of named objects, and would require support of a user provided infrastructure. The description language will describe the expected behavior and results, while the translator will map the API’s to those in the target language. Regardless, the results of the pcell execution should be the same. The contribution by Synopsys defines a set of target behaviors and this is critical in areas such as contact fill. At the workshop, Olaf Schnieder of Synopsys gave a presentation on the PyCell APIs, which was followed by a group discussion of the potential common language’s requirements and direction.

Test
No matter what implementation language is ultimately used, the pcells must be tested in the design flows. The OpenPCell XML repository will contain the test definitions for the pcells, which are run on the generated PDKs. While the testing standard is not targeting any test tool, it will define an architecture that can be implemented by vendors or CAD groups, supporting reuse regardless of the design flow. The testing standard is in early development and is driven by the contributions of members of the OpenPCell XML working group.