Home > Community > Blogs > Industry Insights > seven requirements for an open pdk standard
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Seven Requirements For An Open PDK Standard

Comments(0)Filed under: Industry Insights, Si2, OpenAccess, PDK, SPICE, PCells, OpenPDK

My May 13 blog discussed the significance of the Silicon Integration Initiative (Si2) OpenPDK Coalition, which is seeking to define an open standard that will allow foundries to create a single process design kit (PDK) representation that can be translated into different input formats. What is necessary to make this happen? To get the ball rolling, Si2 has identified seven requirements, as described below. These will be points of discussion as the standards effort moves forward.

1. Interoperable OpenAccess (OA) Symbols

This goal has already been fulfilled! A common OA symbol set, originally donated by Cadence, has been available for download from the Si2 web site since 2007. Sumit DasGupta, senior vice president of engineering at Si2, noted that the symbols "have been proven by years of use at Cadence, so they are very robust." If needed, OpenPDK will add additional symbols and parameters for advanced features. (It should be noted that OpenPDK does not necessarily require OpenAccess).

2. Component Description Format (CDF) Specification

A CDF representation stores the parameter values that go along with a process. With a common CDF specification, the OpenPDK Coalition can set up a "design parameter database" that foundries can write to. They will only have to do so once for a given PDK, and then translators can bring the information into existing data formats. The diagram below tells the story.


3. Callback Specifications

Callbacks typically occur when changes in designs trigger re-evaluations. An infrastructure to support callbacks already exists on OA. OpenPDK will support all languages identified by coalition members, and recommend needed extensions.

4. Parameterized Cell (including SKILL PCell) Evaluation

OpenPDK strategy is not to define parameterized cells, but to specify standard ways in which the cells can be specified.  "We are trying to standardize on two ends of the PCell -- on what things drive the PCell evaluation and where it gets stored," DasGupta said.

5. SPICE Socket

Steve Schulz, Si2 president, noted that there's been a longstanding need to create an API interface for OA that makes it possible to invoke any SPICE simulator. The OpenPDK effort provides a new incentive to make that happen, he said. What's the connection? "It's related to callbacks and triggering re-evaluations," he said. "Once we have this standard interface, if a callback is triggered that requires a re-evaluation through SPICE, there will be a much greater efficiency."

6. OpenAccess Technology Enhancements

Si2 has proposed OA enhancements such as DFM-aware routing and updates to LEF/DEF and translators.

7. OpenDFM With Targeting

OpenPDK will align with the Si2 Design for Manufacturability Coalition and make use of the OpenDFM 1.0 specification that is currently out for review. One goal is to extend OpenDFM to cover recognition of device structures.

What's Next

The OpenPDK Coalition has announced its founding members, including Cadence, and has issued a Request for Technology (RFT) that covers many of the points above. The Coalition has started working as a single group, and will soon charter working groups. "The rest is work in progress," as DasGupta said. A June 14 Design Automation Conference workshop will provide more details.

Richard Goering

 

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.