PCells运用于模拟与定制数字电路的设计中，是在规定的一套可变参数的基础上(图1)用来定义定制IC版图工具中物理版图的软件脚本。PCells是定制设计的建构基石，提供单一可程序化PCell以取代众多不同版本的手绘单元。PCells可使非常复杂的功能自动化，维护错综复杂的关系，甚至还能够与环境互动。

　　运用版图编辑器打开包含PCells的版图查看时，工具会运行个别的PCell脚本，产生对应的版图并保存在内存中。若有参数变更–无论是手工变更或是参数属性表中的参数变更–版图编辑器都必须重新为PCell赋值并适当地变更版图。在许多工具中，储存或关闭版图时，只有PCell处理程序与处理程序专属参数会被写入到磁盘，迫使工具在每次开启时重新为PCell赋值。

　　缓存技术可用来将赋值后的PCell版图写入到磁盘，以便能够读取源头工具所产生的版图内容。若无缓存技术，除非其他工具也能够执行PCell脚本，否则以其他工具开启时将无法显现PCell版图内容。

　　专利的脚本撰写语言，不断进化的标准

　　有史以来，PCells一直都以针对个别专属的版图工具而开发的专利脚本撰写语言(例如Cadence®SKILL®)而撰写的，这导致现有的大多数PCells都无法让其他供货商的工具「看见」，因为其他工具没有运行专利脚本赋值所需的软件。

　　由于可相互操作PDK库(InteroperablePDKLibrary，IPL)联盟的努力，现在这种窘境已经彻底改变了。这个联盟发起一项标准，让所有供货商能够执行可相互操作的PCells(参照www.IPLnow.com)。IPL联盟标准中使用的PCells是运用可相互操作Python脚本撰写语言而撰写的，被其开发者Ciranova称为PyCells™。

　　现在您终于能够建立可由几乎所有EDA工具开启和修改的PCells了。

　　可相互操作的数据库实现PCELL缓存的梦想

　　所有的EDA工具都建立在基本数据库上，这些数据库以汇聚方式执行储存和取回半导体设计数据的桥接功能。直到最近，EDA工具一直都建立在专属数据库上。如果某EDA工具使用专属数据库，那么其他工具能够「看见」版图的唯一方法就是，必须转换成GDSII等通用半导体设计格式。在转换过程中，原始工具会评估PCells及其参数，然后将物理版图改写成GDSII格式的几何图形，摒弃与PCell相关的许多内容与参数。

　　一旦转换成GDSII，大多数情况下原始工具都无法识别这个版图数据。因此对PCells来说，GDSII格式转换是不可逆的。如果以专属数据库为基础的工具，用户想要检视或修改自己的PCells，就必须在设计的生命周期中每年都支付授权费给工具供货商。这就是「工具税(tooltax)」，绝无任何使用者会愿意缴纳。

　　近年来，SiliconIntegraTIonInitiative(Si2)制定的可相互操作数据库标准OPENACCESS(OA)带动了在半导体的定制IC设计中使用多种工具的风潮。这种数据库允许所有工具能够读取和写入相同的数据库，而且还能够提供让不同的工具能实时地运作于同一份内存数据。

　　符合OA规范的其他任何工具都能够看见在OpenAccess数据库中缓存的PCells。几乎各大版图编辑器与EDA业界中大多数的定制设计工具都能够–或者即将能够–至少读取和写入到OA数据库。但是，倘若采用其他供货商工具修改缓存的专利PCell，那该怎么办呢?

　　OA数据库也是PyCells的基础，可以借由PyCellAPI而让任何以OA为基础的工具来利用，而不需要缓存即可让其他工具「看到」。在符合IPL规范的工具中使用IPL标准的可相互操作组件描述格式(InteroperableComponentDescriptionFormat，iCDF)与Tcl回呼函式(callbacks)时，PyCells具备完全的相互操作性。

　　PCELL缓存对象及其运作方式

　　编译过后的PCell代码，已经可供定制IC设计工具使用，称为PCell「supermaster」。Supermaster在评估时不含参数值;在赋值期间，仅仅通过当前工具采用组件描述格式(ComponentDescripTIonFormat，CDF)–或具相互操作性CDF(InteroperableCDF，iCDF)文件提供变量。

　　以手工方式放置或调用[instantiate]PCell到版图中时，工具会从CDF档案读取预设参数，然后在内存中建立这个cell单元的专属示例版本。此版本称为PCell「submaster」。所有的预设参数，或是被修改过的参数，都会储存为专属submaster的内容。给PCell赋值时，版图编辑器会运用这些专属参数来评估submasters，将版图写入内存，并在版图编辑器中呈现其版图以供查看或编辑。下次开启版图时，PCell将不得不重新赋值来建立新的版图。试想在拥有成千上万PCell的版图中，这一定会花费很多时间。

　　但是，如果工具将submasters储存到磁盘(缓存)，那么就不需要每次都重新赋值了，可以大幅加速版图绘制时间。此外，每次建立submaster，在赋值PCell之前，工具都会先查看缓存是否含有同样的submaster，然后才建立新的版图。即使具有同样参数的同一PCell已经使用数千次(例如Contact)，仍然只需缓存保存一个版图版本到缓存中，从而节省更多时间与磁盘空间。

　　基于PCELLS的缓存技术实现相互操作性

　　当没有相互操作性PCells可供选用，或者有庞大、既有的PCells库可供选用时，缓存功能对多重工具设计环境，或在转换到更新工具的过程中，是非常实用的。在这个领域内有两大选择：

　　ExpressPCells：当今的许多PCells都是以Cadence的专利SKILL脚本撰写语言来撰写的。即使是为了在更新的CadenceOA版本中使用，SKILLPCells也不是一定可以在其他工具看到的，因为并没有自动缓存。为了在其他工具中能够「看见」，CadenceExpressPCells可用来缓存OA数据库中的单元。这使得单元以–只读–的方式让其他非Cadence工具可以看见。

　　在某些工具，可以看见程序专属参数的属性表，但不可以在其他工具中修改PCells，除非先经过处理成为简单的版图。此外，stretchhandles、auto-abutment回呼(callbacks)在其他工具中是不可见的。(有关PCell功能的详情，请参照SpringSoft网站技术单元中的ASilicon-provenInteroperablePDK一文。)

　　例如，对于使用非CadenceDRC工具的使用者而言，需要ExpressPCells才能够直接从OA执行DRC。在多工具设计流程中，不同的版图模块有不同的版图编辑器完成，对于组合这些不同的模块，ExpressPCells是一个可行的方案。当然，进一步修改基于Cadence的模块，这些模块需要全部替换，或至少修改PCell实例。这就和典型的SOC流程没有什么不同了(SOC流程中，不同的模块有不同的团队甚至不同的公司设计完成)。

　　PCellXtreme：Ciranova的PCellXtreme™也能够搭配Cadence环境，就如同ExpressPCells缓存SKILLPCells一样，可以加速开启版图的时间。然而，与ExpressPCells不同的是，PCellXtreme服务除了可以看到缓存的PCell之外，还能够读取和修改PCell参数。PCellXtreme不转换PCell代码或赋值;如果没有第二个工具要读取PCell的参数，PCellXtreme会根据Cadence的SKILLPCell生成版图放进缓存中。所以新版图是可见的并且实时刷新。因此，被其他工具修改的参数可以被所有的工具承认。这种方法需要使用者至少拥有一套授权的Cadence工具，以便赋值SKILLPCells。

　　但是，需要注意的是PCellXtreme并不能实现回呼(callbacks)。回呼是许多PCell参数的关键元素，因为他们被用来通过输入的参数来计算相对值、逾限值(outofboundsvalues)等等。所以，单纯只有参数传递是不够的。若要实现在非Cadence工具中的回呼功能，对其他工具来说，必须要有与IPLAllianceReferenceflow1.0中定义的TCL回呼完全一样的可相互操作回呼功能，以供其他工具使用。对于Cadence环境，包括IPL库中运行的客户操作PCell，双重回呼是必须的，因此TCL回呼存在更多的互操作环境是值得期待的。这两个回呼只要适当的设置，所有参数的互操作都可以实现。

　　因为stretchhandles与auto-abutment是随着版图而缓存的OA内容，使用者可以TCL或其他可相互操作的脚本撰写语言来写入对等的stretchhandle与auto-abutment程序，以吻合SKILL功能。移动stretchhandle会导致版图编辑器更新相关的参数、触发相关的回呼。参数变更会导致PCellXtreme产生和缓存修改后的版图，如同前述手工输入的参数变更一般。Auto-abutment也会以同样的方式而实现。

　　总结

　　PCell缓存技术是在以OPENACCESS为基础的工具中重复利用原有版图数据的实用做法，为使用者提供更高的相互操作性，远胜过参数化单元的GDSII转换作法。

　　虽然具备最高相互操作性的解决方案就是使用IPLAlliance的可相互操作PyCells、回呼、CDF与stretchhandle/auto-abutment技术，PCell缓存技术在一个新的OA工具、混合设计环境中对于使用遗留的PCell是一个切实可行的方法;或者单纯以加速既有工具为目的，也是很好的解决方案。