1. Unleash PDK with Open Standards Synopsys 18th EDA Interoperability Developers' Forum Hau-Yung Chen Nov. 9, 2006 Synopsys 18th EDA Interoperability Developers' Forum Hau-Yung Chen Nov. 9, 2006

2. Open 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 PDK Foundry A Defined PDK Foundry B Defined PDK Foundry/IDM C Defined PDK Open PDK Open Platform

3. 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.