原文链接，在这。
PDK（process design kit）是沟通IC设计公司、代工厂与EDA厂商的桥梁。
当我们需要开始采用一个新的半导体工艺时，第一件事就是需要开发一套PDK，PDK用代工厂的语言定义了一套反映foundary工艺的文档资料，是设计公司用来做物理验证的基石，也是流片成败关键的因素。PDK包含了反映制造工艺基本的“积木块”：晶体管、接触孔，互连线等，除PDK的参考手册(Documentation)外,PDK的内容还包括：
器件模型(Device Model)：由Foundry提供的仿真模型文件
Symbols & View：用于原理图设计的符号,参数化的设计单元都通过了SPICE 仿真的验证
CDF(Component Description Format,组件描述格式) & Callback：器件的属性描述文件,定义了器件类型、器件名称、器件参数及参数调用关系函数集Callback、器件模型、器件的各种视图格式等
Pcell(Parameterized Cell,参数化单元)：它由Cadence的SKILL语言编写,其对应的版图通过了DRC和LVS验证,方便设计人员进行Schematic Driven Layout(原理图驱动的版图)设计流程
技术文件(Technology File)：用于版图设计和验证的工艺文件,包含GDSII的设计数据层和工艺层的映射关系定义、设计数据层的属性定义、在线设计规则、电气规则、显示色彩定义和图形格式定义等;
PV Rule(物理验证规则)文件：包含版图验证文件DRC/LVS/RC提取,支持Cadence的Diva、Dracula、Assura等。
在开发PDK的演进中，有些事情在慢慢变化着：一是Virtuoso 不再是这个领域唯一的玩家，所有主要的EDA厂商都纷纷给出了自己的解决方案，但没有一家EDA工具能读写Virtuoso的PDK。Virtuoso的PDK是采用Cadence的SKILL语言开发的，目前没有将其公开化。二是设计规则变得如此复杂，以至于开发一套特定工艺的PDK花费巨大。相应的开发针对不同版图编辑器的PDK更是需要很多的经验，但此项工作又不能给代工厂或用户带来实际的利益。
由于Cadence不愿意公开他的PDK（也称PCell），iPDK作为一个PDK标准渐渐走入人们的视线。这是由IPL（Interoperable PDK Libraries Alliance）组织发起，联合TSMC，采用Ciranova's PyCell（基于Python而非SKILL语言）开发出的一套新PDK标准。目前被各大EDA厂商的版图编辑器所支持，尽管Virtuoso没在官方表态，实际上也在偷偷的支持这一标准。也行这就是商业利益使然吧。
也许一个标准是好的，两个就更好了？实际上并非如此。还有另一个便携式的PDK——OpenPDK。在Si2大伞的庇护下，在极力推广，但这一项目自去年展开以来，至今还未有实际的PDK采用此标准。OpenPDK采用OpenAccess数据库，设计成支持各种格式的工艺数据库，而不需要各EDA工具在内部实现Openacess。
精彩的故事于是上演了，那谁能主PDK沉浮呢？iPDK被视为TSMC的标准，GlobalFoundries以及他们那帮“common platform”哥们当然不会买它的帐，他们只支持Virtuoso PDK。不过这以壁垒也增加了他们的客户试图从TSMC以及其客户那里窃取技术机密的难度。
在其他EDA公司看来Si2与Cadence走得太近了，如OpenAccess and CPF本就是Cadence的产品，只不是经由Si2摇身一变成了开放标准了。所以不得不怀疑Cadence是否有兴趣公开PDK这一标准，因为除了Virtuoso PDK还没有第二个标准能与之相争，真是：倚天不出，谁与争锋，倚天在何方？