Unleash PDK with Open StandardsUnleash PDK with Open Standards

Synopsys 18th EDA Interoperability Developers' Forum

Hau-Yung ChenNov. 9, 2006

Synopsys 18th EDA Interoperability Developers' Forum

Hau-Yung ChenNov. 9, 2006

Open PDKs: Primarily a Business IssueOpen PDKs: Primarily a Business Issue

Foundry A

Foundry B

Foundry/IDM C

Tool X

Tool Y

Tool Z

PDK A_X

PDK A_Z

PDK A_Y

PDK B_X

PDK B_Z

PDK B_Y

PDK C_X

PDK C_Z

PDK C_Y

- Process name

- SPICE Models - Schematic Symbol - Layout TF - Parameterized Devices - DRC rule file - LVS rule file - RC extraction rule file

PDKFoundry A Defined PDK

Foundry B Defined PDK

Foundry/IDM C Defined PDK

Open PDK

Open PlatformOpen Platform

Truly Open PDKs: Everybody Wins IF:Truly Open PDKs: Everybody Wins IF: Every involved party clearly sees the potential benefit and is willing to

participate, play by the rules, and support truly open standards Pure Play Foundry & IDM EDA Vendor & User Coordinated by independent bodies

Rename PDK to OPDK, UPDK, or TDK, or OK (OpenKit) The name PDK carries too much of a single-company image Signify a clean start and clear separation of Open Formats from old Proprietary

Formats Avoid the name confusion and conflict or even legal issues with the existing one.

Ban any proprietary languages Enough freely available scripting languages, Tcl, Python, Perl, etc. Why do we have to support a proprietary language in an Open system?

Ban any vendors who want to hijack the Open system with proprietary stuff. Start with a baseline OPDK set including Schematics Symbols, Layout TF,

and PCells

Allow us to compete on Technology and Implementation:

not on Scripting language, format, spec.