WP_Term Object
    [term_id] => 76
    [name] => Tanner EDA
    [slug] => tanner-eda
    [term_group] => 0
    [term_taxonomy_id] => 76
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 60
    [filter] => raw
    [cat_ID] => 76
    [category_count] => 60
    [category_description] => 
    [cat_name] => Tanner EDA
    [category_nicename] => tanner-eda
    [category_parent] => 14433

An Update on the OpenPDK for IC Design

An Update on the OpenPDK for IC Design
by Daniel Payne on 01-10-2014 at 11:00 am

IC designers use EDA tools to implement their logical and physical design, and these tools require foundry-specific information for:

  • Design Rule Checking (DRC)
  • Layout Versus Schematic (LVS)
  • Library Symbols
  • Parasitic EXtraction (PEX)

This foundry information is called a Process Design Kit or PDK for short. Now put yourself in the place of the foundry or IDM, and you want to support EDA tools from multiple vendors like: Cadence Design Systems, Mentor Graphics, Synopsys, Silvaco and Tanner EDA. That adds up to a lot of QA and PDK development effort to support so many EDA vendors and tools. There has to be an easier way to create PDKs instead of one vendor at a time.

Necessity is the mother of all invention, so the folks at Si2have gathered together the best minds in the semiconductor and EDA industry to address and standardize a way to create these PDKs, thus saving everyone more time and money. Si2 has created a coalition dubbed the OpenPDK with the following members:

AnaGlobe Technology, Inc.
Cadence Design Systems
IBM Corporation
Intel Corporation
Mentor Graphics Corporation
Samsung Electronics Co., Ltd.
Silvaco Inc.
Tanner Research, Inc.

Here’s the big picture on what the OpenPDK is automating:

The Supplier on the left column is either a Foundry or IDM and they have all the process-specific information to start with, and they gather that into a Design Rule Manual (DRM). The center column shows a standardized file exchange format called the Open Process Specification (OPS), and the OPS is an XSD file used as a syntax template for an XML file. Finally, in the right column are the automatically created PDK files.

Tanner EDA

This week there was an announcementby Tanner EDA where they’ve donated some code to the Open PDK Coalition. To learn more I contacted John Zuk at Tanner:

Q: Who will benefit from this contributed technology?

Initially, this contribution will directly impact other EDA companies – specifically the other members of Si2. It is the intention that this will ultimately benefit the broader ecosystem and EDA users as the OpenPDK standard matures.

Q: Is this new technology part of OPS v1.1?

This is not yet an adopted component of the standard. The contribution will be evaluated by the OpenPDK working group for inclusion in an upcoming release.

Q: When will the API be production ready?

Unknown – as this is dependent on adoption/inclusion by the working group.

Q: What release of Tanner EDA tools will support this technology?

This is currently in use within the Tanner EDA OpenAccess implementation.

Q: Who will the first customer of this technology be, and why?

Current users of Tanner Tools are already using this set of properties and this taxonomy for storing and maintaining information. It provides a robust and efficient system for maintaining design file information.

Mentor Graphics

Since the OpenPDK Coalition has many member companies, I asked Linda Fosler at Mentor what she thought about the recent contribution from Tanner EDA:

Mentor Graphics is pleased that Tanner has made this contribution. It helps to further the openness of PDKs. Some EDA vendors have stored their interpretation of display packets in ways that made it impossible for others to generate this data. What Tanner has contributed can become a truly open standard for the generation of this data.


Karen Bartleson over at Synopsys had a quick response to share with me:

Thanks for asking about this. We haven’t seen the contribution yet, but in principle, the Tanner contribution used with OPS should benefit end users who have to create PDKs in multiple formats/languages, which indirectly benefits Synopsys. This is not the end of the story, though. Stay tuned and consider attending the Si2 workshop at the end of January. There will be a lot of new and interesting material revealed that will support the IPL Alliance and development of iPDKs, which, of course helps Synopsys and our customers and partners.


It makes sense to have standards in EDA that save everyone time and development efforts: EDA vendors, foundries, IDMs, users. It looks like the OpenPDK Coalition is delivering on this promise and it’s a good sign when the big three in EDA adopt a standard: Synopsys, Cadence, Mentor.

lang: en_US

Share this post via:


0 Replies to “An Update on the OpenPDK for IC Design”

You must register or log in to view/post comments.