OpenPDK accelerates design kit production at ST
The FD-SOI processes developed by STMicroelectronics have provided the testbeds for a standard for automating the production and updating of process design kits (PDKs) that the chipmaker now hopes will become widely adopted by design tool vendors as well as by foundries.
IBM and ST are among the first to use the OpenPDK standard from the Silicon Integration Initiative (Si2) to help automate the production of process design kits (PDKs) for IC layout and verification tools. According to Jim Culp, OpenPDK chair and senior technical staff member at IBM, OpenPDK has been used to create a design rule manual (DRM) for a 45nm process. ST has taken the OpenPDK technology, using it to develop the PDK for its upcoming 14nm FD-SOI process and a silicon photonics process as well as to update the existing 28nm FD-SOI kit.
Culp explained during an Si2 press conference at the recent Design Automation Conference in San Francisco: “From a foundry perspective, the PDK is composed of manual transformations from a DRM, describing the behaviors of a fab for design tools. But for each tool, you might need to customize the information in a different way. We sought to standardize this effort for productivity and efficiency improvements by replacing the bottom part of the PDK. Using OpenPDK, I can [in principle] describe the capabilities of my foundry and render them into any of the available toolsets. It gives me not only productivity improvements but quality, because the data is renderable.”
OpenPDK structure
OpenPDK is based on XML with the key component of each kit being a file – the Open Process Specification (OPS) – that describes the process attributes and rules, many of them in the form of layer equations expressed in the Universal Layer Model (ULM) format developed by Si2 to support a number of its standard. The OPS file then needs to be transformed by parsers into files that can be used by individual design software such as design rule checkers or parasitic extraction tools. The foundry would typically generate the OPS data using its own parsers and scripts from the in-house DRM database in parallel to the written design-rule document rather than being derived by hand from the PDF. This should reduce the number of errors that are introduced, particularly during the frequent updates that occur during the development and yield-ramp stages of an advanced process node.
“On advanced technology nodes, we are often adjusting the edges of the litho process window. If we have to do that for each tool individually, it is very onerous,” said Culp.
Philippe Magarschack, executive vice president of design enablement at ST, said: “OPS reaps all the process information that’s normally expressed in human-readable language in the DRM document. But this is a self-consistent electronic format, essentially a foolproof reference. Otherwise you have to go through a very lengthy, error-prone and effort-intensive activity for different vendors. The goal is to have a single source, which is this OPS format. The value to our customers is time to market and also, to EDA vendors, the increase in quality.”
Seeking support
Although the OpenPDK effort has had the stated backing of a number of EDA vendors since Si2 began the project several years ago, Magarshack said: “We hope EDA vendors will endorse the standard. We are seeing interest from EDA vendors but it is a classic chicken-and-egg situation. They want more support from foundries. But the foundries want to see more investment from the tools vendors.”
Magarshack said the infrastructure developed for OpenPDK so far provides ST with benefits over conventional techniques even without wider industry support. “We get benefits from the automation. The big, big benefit is when you get incremental updates that happen every other work. For each of these, you have to go through a series of QA checks. That’s where we gain tremendously from the automation and a correct-by-construction approach that’s inherent to this standard.”
Work began on OpenPDK at ST in 2011 when the company worked with IBM on what was then known as the 20nm FD-SOI process. “Out of that platform, we derived what we now call 14nm FD-SOI,” said Magarshack. “The work was too late to intercept the first phase of 28nm. We are currently back-annotating into 28nm FD-SOI, and this will be coming out in the next few months. We are also retroactively applying the format to 130nm CMOS platform derivatives for applications such as image sensing. The plan is for that to be deployed by the end of this year.”
The current work by ST does not support the full range of tool outputs as yet. The work currently concentrates on device libraries and mask preparation. “The next step will be physical verification,” said Magarshack.
