用于针对生产工作流的芯片设计中的单元完整性、改变和起点的独立评估的方法和设备

相关申请

本申请要求所提交的美国专利临时申请号61/131,601以及美国专利临时申请号61/180,715的权益。通过引用并入在前申请。

背景技术

所公开的技术涉及用于准备芯片设计以用于制造的设计数据的粒度分析，并且涉及标识设计数据文件的各部分之间的相似性和差异性。具体地，所公开的技术涉及解析数据并且将其组织为规范化形式、概括规范化形式、以及把来自不同源(诸如芯片级设计和设计模板库)的设计数据的概要进行比较。将设计数据组织为规范化形式通常会降低数据分析对于对设计没有功能性影响的数据改变的敏感性。粒度分析的细节随表示设计方面的设计语言以及数据文件格式而有所不同。根据期望的分析和设计语言，粒度分析可以包括通过以下各项来划分和报告设计文件：头部/单元部分、对注释的独立处理、功能上重要的/不重要的数据、空白/非空白以及设计数据单元内的层。感兴趣的相似性和差异性取决于粒度分析的目的。比较按照多种方式都是有用的。

集成电路的设计是这样的迭代过程，其涉及成千上万的单元和块视图、伪像及其依赖关系。视图、伪像及其依赖关系表示集成电路的开发功能、电气和物理状态。

单元和块以不同的速率经历设计过程，该过程从设计模板供应商的发布和内部单元级开发开始，并且在多个发布或者迭代中循环。在最好的情况下，跟踪块、库、单元和伪像的最新版本也是困难的。例如，当某人在使用特定设计模板的产品中发现出产问题时，公司将难于确定哪些其他项目使用了该设计模板。

到处都存在使用陈旧的单元或者库的可能性。设计工具具有其自己的配置文件，并且机器具有其自己的搜索路径和盘安装点。设计或者流片(tapeout)团队可能无法找到过期的文件或者链接，直到从制造中返回有问题的设计。

复合的多级设计带来了新的问题。冻结块(其是由设计团队试验性完成的)可能正在使用库单元的过期版本。此外，设计者可能通过简单地对单元进行重命名而避免与另一设计者的单元的名称冲突，而没有验证这两个单元是否相同。对单元进行重命名将其与将来的库更新和单元跟踪机制分离。

设计者已经对供应商提供的设计模板做出了未授权修改，这导致了生产期间的失效，并且潜在地使否则从设计模板供应商可得的担保无效。例如，设计者可能认为修改将改善模板的性能或者功能，但是仅发现产生了相反结果，诸如生产中的失效。另外，第三方供应商不担保对其设计模板的修改。如果发生类似的事情，则将难以确定原因以及标识谁负有责任。

当设计准备发布到生产时，其可能多达40,000个独特的单元。由于目前的设计复杂度，很有可能用于准备设计的一些库单元不是最新的。流片团队无法肯定地确定其将要向掩膜车间发送的设计中的单元是否表示最新的可用版本。目前无法确保流片候选使用所有的最新数据，也无法确保没有人对已鉴定的布局做出未授权修改。

在集成电路的设计期间跟踪单元数据的已知方式跟踪包含单元集的数据文件。为了找到文件内的单元改变，设计者通常使用区分工具来进行上百万行数据的手动分析。运行差异性检查跨设计语言或者数据文件格式是无效的，因为区分工具通常执行文本匹配，而不考虑用于表示设计的设计语言或者数据类型。区分程序通常减去文件之间的差异，而不会分析改变对于正在生产的芯片是否具有功能性影响，或者其是否重要。区分工具对于两种二进制数据文件尤其困难。

明确包括区分工具的设计工具的示例包括ClearCase、DesignSync和IC Manage，其由其相应的销售商在http://www-01.ibm.com/software/rational/、http://www.icmanage.com和http://www.3ds.com处描述。因为此类工具在文件级而不是单元级操作，所以使用区分工具的设计者实际上需要将需要进行比较的两个代码段提取到新文件中，并且直接比较该文件。或者，设计者可以依赖于文件元数据，其中另一设计者保持了关于设计工作的过程的记录。这些方式都不够鲁棒或高效。

一些设计模板供应商为其模板添加标签。该标签将模板相对于可能不是其集成电路设计一部分的其他设计模板标识为“他们的”。标签可以用于对设计中使用的设计模板的实例进行计数，继而模板的用户基于实例的数目来支付使用费。对于该添加标签方法的使用的行业标准方式由VSI Alliance^TM维护。2009年5月21日在http://www.vsi.org/docs/IPP_Tagging_Std％201_30.pdf处访问的、标题为“Virtual Component Identification Physical Tagging Standard”的标准版本2.0描述了使用添加标签方法的方式。该标准描述了要嵌入在GDSII文本或者注释行中的文本标签。VSI联盟包括IBM、Intel、ARM、Freescale Semiconductor、TSMC等。第三方IP供应商已经开发了一种扫描仪，其可以在标签依然是设计模板数据的一部分的情况下检测并且报告设计模板。如果标签以某种方式被移除或者混淆，设计模板的所有者将不会在使用费方面得到补偿。

出现了开发用于设计数据分析的新工具的机会，该新工具促进设计工作流中的各交接点处的设计数据的粒度评估。比较好的是，可以产生较少的错误、更加弹性和透明的工作流以及产生的生产设计。

发明内容

所公开的技术涉及对用于准备芯片设计以用于制造的设计数据粒度分析，以及设计数据文件各部分之间的相似性和差异性标识。特别地，其涉及解析数据并且将其组织为规范化形式、概括规范化形式，以及将来自不同起点(诸如芯片级设计和设计模板库)的设计数据的概要进行比较。将设计数据组织为规范化形式通常会降低数据分析针对对设计没有功能性影响的数据改变的敏感性。粒度分析的细节在用于表示设计方面的各设计语言之间有所不同。根据期望分析和设计语言，粒度分析可以包括通过下述来划分文件：头部/单元部分，对注释的独立处理，功能上重要的/不重要的数据，空白/非空白以及设计数据单元内的层。感兴趣的相似性和差异性取决于粒度分析的目的。比较按照多种方式都是有用的。本发明的特定方面在权利要求、说明书和附图中进行描述。

附图说明

图1示出了高层集成电路设计环境。

图2示出了与图1中的框相关联的版本扩展和某些文件格式。

图3示出了设计过程中的交接点，所公开的技术可以有效地应用该交接点处。

图4绘出了概括多个数据文件的部分的规范化表示的评估器。

图5中示出了通过处理包含设计数据的文件来生成规范化单元概要或者设计单元概要。

图6和图7提供了这些方法的某些方面的高层流程图。

图8A-图8D示出了Liberty文件中的可能头部和单元语句的采样。

图9是Verilog的带注解示例。

图10A-图10B示出了带注解的样本VHDL文件。

图11是带注解的样本OASIS文件。

图12是带注解的样本GDSII文件。

图13是SPICE文件的带注解版本。

图14是带注解的样本LEF。

图15是DEF的带注解版本。

图16是结构化文本文件的带注解版本。

图17A-图17B是用户解析文件的带注解示例。

具体实施方式

参考附图进行下文的详细描述。描述了优选的实施方式以示出本发明，而不限制其范围，该范围由权利要求限定。本领域技术人员将认识到关于下文描述的多种等效变体。

概述

集成电路设计的环境

电路设计的环境比以上背景技术部分中的描述呈现了更多针对改进的挑战和机会。成功的集成电路(IC)流片需要IC设计的单元和块是正确的。使用电路的错误版本(不管是具有少量晶体管的叶单元还是较大层级设计块)可能花费上百万美元以及数月的延迟。

芯片级设计管理系统、后逻辑综合、基于跟踪文件的设计数据集：单元、单元的版本、块、和芯片级设计块。设计数据管理系统可能无法有效地确定或者总结文件内的给定单元和块数据集中的什么发生了改变。芯片级设计数据管理系统在该粒度层无法跟踪，因为单元和块以及芯片级设计块是由不同的设计工具和不同的设计工具版本创建的，并且使用不同的设计语言和数据文件格式来表示。在复杂的SOC设计中，设计块可以来自使用不同设计工具和工具版本的不同设计组。目前设计管理工具中察觉的缺陷使它们无法用于评估单元级的单元等效性或者报告单个单元内发生了什么改变。

现有的设计数据管理工具不在文本数据和对象数据之间进行区分，并且不对数据进行排序或者以其他方式产生设计数据的规范化表示。转而，其缺少审核能力，而这种审核能力对于对以下感兴趣的项目管理者是有用的：验证IC设计中的单元是否是最新的经批准版本，确保单元没有进行不适当的拷贝或者导入，或者确定所提出的单元设计更新在接近流片的设计中是否是不可用的。

另外，设计数据管理系统不提供验证发布到掩膜车间的最终GDSII或者OASIS文件的方式。其全部假设利用足够严格的控制，“偏离”的布局不会进入最终设计中。

单元和块作为设计单位

芯片设计大量使用单元，这些单元被分组到块中。单元与有时被称为单元“视图”的数据文件集合相关联。单元视图包含单元的功能或者物理表示。通常，存在表示诸如SPICE、Extracted Netlist、GDSII、Liberty、Vital和/或LEF的设计语言的设计数据的两个或者更多单元视图。不同的电子设计自动化(EDA)工具对其包含的不同视图和数据进行操作。一些工具操作详细的多边形数据，而其他工具仅利用简化的多边形表示来工作。性能估计工具完全不利用多边形工作，其使用定时信息。如果各种工具使用单元视图的版本不一致，则基本上存在使用该单元的设计将失效的风险。

芯片级设计块可以包括单元的若干单元块。单元块可以包含对单元以及包含其他单元的子块等的引用。引用可以是嵌套的。当芯片被制造时，对单元的引用最终被展开。在设计过程期间，使用引用极大地减小了表示设计所需要的存储器量和盘空间。芯片上的存储器区域例如将包含一个或多个核(core)比特单元、读取和写入比特单元的行和列单元以及引用核比特单元、行单元和列单元的顶层单元的定义。65,536比特存储器(“64K比特存储器”)将通常具有：被引用65,536次的1比特单元定义；被引用256次的两个列驱动器或者感测单元定义(顶层或底层)；被引用256次的两个行驱动器或者感测单元定义；以及分类(assorted)解码电路。层级设计可以进一步减少引用的数目；存储器的行可以被定义为包含对左和右行单元的引用加上对核比特单元的256次引用，继而该行可以被引用256次。可以使用少于1,000次嵌套引用来代替65,536次单元引用。

当制造掩膜(用于在芯片上制造单元的工具)或者使用直接写入时，单元引用被展开。在以上的存储器示例中，不管单元层级如何指定，都将存在从单个原始单元拷贝的、印刷在晶片上的65,536个核比特单元。在展开之前，设计数据文件可具有数十吉字节的大小；在展开之后，文件可能增大多倍。仅有少数工具需要利用完全展开的数据来工作，这种工具包括表示掩膜数据准备软件工作站并且可能包括检查芯片设计中的设计规则违背的规则检查系统。

一些视图使用在单个文件内提供多个“单元”的文件格式。这增加了另一维度的复杂度：这些格式之一中的文件版本取决于其内部所有单元的版本。

诸如处理器核的复合设计模板倾向于具有多种相关联的产品。通常，产品存储在单独的文件中。这些文件可以是针对逻辑综合的性能约束文件、针对仿真的行为描述文件或者来自由单元构造的工具的日志文件。假设将所有这些文件与单元的主布局和定时视图进行同步。

更详细地，一些单元视图可以改变，即使在那些单元的表示或者物理布局(例如，布局)尚未改变时。例如，如果对代工厂处的制造工艺进行改变，或者简单地因为关于来自代工厂的产品的平均性能的更多信息变得可用，定时模型可以改变。

规范化单元概要(“CCD”)和规范化设计单位概要(“CDUD”)如何工作

规范化单元概要(更一般地，规范化设计单位概要)是将在IC设计过程中有用的新工具的输出。本文档中公开的规范化概括工具针对公用EDA文件格式生成针对文件的、逐单元和逐层的概要，并且可以扩展至其他文件格式。这些工具可以区分诸如空白或者注释修改的不重要改变和诸如对单元的新接口的主要改变。其允许单元与版本化单元概要储存库的匹配，用以检测未测试单元、陈旧单元、单元的改变或者不同名称下的单元拷贝的未授权使用。在高层处，图4绘出了概括415、435、455多个数据文件411、431、451的部分的规范化表示的评估器433。将表示两个或更多文件的概要进行比较。在此上下文中，出于专利目的，一般性地使用术语“文件”，因为两个数据文件可能存储在单个数据库中。在设计行业内，设计文件通常存储在文件层级中，诸如Windows或者Linux文件系统。评估器433将概要进行比较，并且生成针对特定目的而感兴趣的概要相似性和/或差异性的总结473或者报告475。

通过处理包含设计数据的文件411来生成规范化单元概要或者设计单位概要，如图5所示。该设计数据最终有助于物理电路(也称为集成电路或者芯片)的生产。在一个实施方式中，在处理器530上运行的解析器531、与解析器协作运行的规范化器逻辑533以及在处理器上运行的概括器534生成存储在存储器415上的规范化单元概要和语法树532。单元概要的规范化组织取决于所解析的设计语言。这些处理器为每个单元生成至少一个概要。概要例如可以是从解析器和规范化器逻辑的规范化输出生成的32或者64比特代码。多种散列函数可以用于创建概要，诸如CRC、MD5等。概括器可以为单元的头部和主体部分生成独立的概要，并且由单元内的层生成概要。注释、空白和功能上重要的数据可以独立地进行概括。概要可以永久存储以便以后使用。例如，可以生成经批准的库的概要，并且将其存储以便与设计项目的概要进行重复比较。

规范化概要的比较是允许用户理解较大文件中设计元件之间的细小差异的有效工具。如上所述，设计文件(尤其是包含二进制多边形数据的文件)可能是庞大的。设计文件中包含数百乃至数千的单元(或者更多，例如利用大型存储器)。对于如此众多的数据，假警报是一个实际问题。规范化单元概要的一种使用是基于所检测的改变的功能重要性并且有时基于其在设计过程中的源来标识所检测的改变并且允许对其进行过滤。

运行在处理器535上的比较器536和运行在处理器上的报告器537对概括器534存储在存储器415中的概要进行操作。通常，比较两组或三组文件411。为简便起见，将文件组称为“文件”，并且期望读者理解所比较的文件的实际数目是任意的。“两个文件”意味着两个或更多文件。两个文件可以表示旧单元库和新单元库。三个文件可以是设计文件、已批准的单元库和被拒绝的单元设计集，其中如果被拒绝的单元设计被用于生产，则将导致失效。比较器针对一个或多个其他文件的概要来检查针对一个文件的概要。报告器响应于过滤标准来报告各文件中的单元之间的匹配、近似匹配或者一个文件中的单元没有出现在其他文件中。这些报告可以被总结至存储器473(诸如另一程序可以处理的其他中间格式或者数据库)，或者人类操作者在显示器或者纸张上可查看的报告475。比较文件以产生有用的报告存在多种使用情况。

此技术的一些用例是：

●理解更新单元设计库

●评估更新单元库对过程中设计的影响

●在布局和布线之前、在流片之前以及在其他设计里程碑处，找到设计数据中未被批准的单元和/或不良单元

●标识设计数据中重命名的单元，并且验证其与经批准的单元模板相匹配

●检测危害提供模板的供应商的担保的单元修改

●对生产设计中针对其应付使用费的单元数目进行计数

●根据这些用例，应当能够看出所公开的规范化概要作为用于电路设计者的工具如何有效。

原型规范化概括工具处理以下主要的已公布EDA设计数据格式，并且可以容易地扩展至其他格式：

●Open Artwork System Interchange Standard(OASIS)几何布局文件

●Calma GDSII几何布局文件

●Synopsys Liberty库电路定时模型文件

●Verilog Register Transfer Level描述文件

●VHSIC Hardware Description Language(VHDL)Register Transfer Level描述文件

●Simulation Program with Integrated Circuit Emphasis(SPICE)子电路网表文件

●Cadence Library Exchange Format(LEF)布局描述文件

●Cadence Design Exchange Format(DEF)设计描述文件

●“结构化文本”脚本编写和控制文件

●非结构化(任意或者未知格式)文本文件

●非结构化(未知格式)二进制文件

该工具还提供用于计算针对专有数据格式(“用户解析的”文件)的规范化单元概要的应用编程接口(API)。运行在处理器上的解析器标识文件内的重要设计对象，并且生成针对单元、与单元的接口、单元主体和任何单元外部的文件头部数据的概要。

对单元内或者文件头部中的注释独立地进行标记，使得可以仅标识注释中的改变。文件头部、单元接口以及单元主体内的数目在适当的时候由层进一步分离，使得对个体层的改变较明显。当文件格式内的数据与顺序无关时，则请求进行排序，规范化单元概括工具仅对顺序无关的数据进行排序，而使顺序相关数据保留其原始顺序。

概要计算基础

可以对其应用规范化单元概要的设计数据文件内的三个通常的对象类是文件、文件头部和单元。文件级概要可以根据文件中的所有数据来计算。规范化单元概要是针对单元或者文件模块的、规范化重组数据的概要。规范化文件头部概要是不在任何单元或者模块中的、规范化重组数据的概要。根据设计语言或数据文件格式或者根据用户选择的选项，在生成概要之前应用更多或者更少的重组。在本公开中，“规范化设计单位概要”统指应用于文件头部和单元数据的概要。在所提供的多个示例中，将会看到：即使在仅具有一个或其他数据种类的格式中，文件中的设计数据通常也可以作为头部或者单元数据来处理。

规范化单元概要可以涉及针对单元的部分计算的多个概要：注释数据、层数据和非层数据。注释数据是由规范针对给定文件格式确定的非功能性数据(通常是文本)。对于多数格式，注释概要中的改变可以忽略。层数据具有不同的层名称或者序号(诸如第一层金属或者多晶硅)，其对于读取文件的工具是有意义的。非层数据表示不具有层序号的对象(诸如GDSII或者OASIS中的单元布局(实例化))，或者没有由层序号划分的文件中的对象。

层数据进一步被分为几何数据和非几何数据。GDSII和OASIS文件具有不是几何数据的文本和节点名称记录，但是仍然具有层序号。对节点和文本信息的改变未必与对几何数据(诸如路径或者多边形)的改变一样重要，所以节点和文本概要单独记录。用户可以选择利用具有与几何数据相同的重要性来处理节点和文本数据，但是这样做不是必须的。

文件和概要的组织

为了概要计算这一目的，文件最通常包括可选头部以及零个或者多个单元。在文件头部(如果单元之间的文本不清楚地属于单元则其可以包括该文本，诸如当单元具有不同的端记录时)内，诸如当文件格式不具有层名称或者序号时，存在在指定的层上或者明确地报告为“非层数据”的注释加头部数据。

单元具有可选接口、可选主体和可选注释。这三类中的至少一个将出现在单元中。单元接口数据在命名的层上，或者是序号，或者可以将其明确地报告为“非层数据”。

单元主体数据在命名或者编序的层上，或者其被明确而地报告为“非层数据”。单元主体(但是在本实现中，不能是单元接口或者文件头部)可以具有“非几何数据”，对几何数据格式而言，它是不指定多边形、矩形、线形等的信息。通常，非几何数据将是特性和文本记录(例如，在GDSII或者OASIS文件中)。如果数据格式不是几何的(例如，Liberty定时模型)，则即使所有的数据没有记录在调用方期望知道的该类中，所有的数据也都是非几何的。通常这是显然的，因为所有的数据将是“非层”的。这是一种实现决策，而并不是本发明的关键。

作为示例，报告可以具有一般或者详细的类别。一般类型的一个示例如下：

文件：

文件头部注释

文件头部非层

文件头部层...

单元...

单元：

单元注释

单元接口非层

单元接口层...

单元主体非层

单元主体层...

单元主体非几何非层

单元主体非几何层...

较详细类别的一个示例如下：

文件：

文件

文件非空白

文件空白

文件头部(未排序：不充足存储器)

文件头部(没有请求排序)

文件头部注释

文件头部非层数据((-1)

文件头部逐层

单元

单元(排序)

单元(未排序：不充足存储器)

单元(没有请求排序)

不具有注释的单元

单元注释

单元接口

包括文件头部的单元接口

排除文件头部的单元接口

单元接口非层数据(-1)

单元接口逐层

单元主体非层数据(-1)

单元主体逐层几何

单元主体逐层非几何

GDSII示例

作为一个示例，考虑命令行规范化概括工具针对较小GDSII文件生成的概要报告：

File ″testfiles/sigtest.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -nosort

  db7be73c File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(not sorted)

  8f078078 File Header with Comments

  3289c53f File Header without Comments

  bd8e4547 File Header Comments

  3289c53f File Header non-Layer

Cell ″Structure_1″(not sorted)

  a7100492 Cell with Comments

  3d4d7fbf Cell without Comments

  9a5d7b2d Cell Comments

  7b78aab4 Cell Body non-Layer

  15546763 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

Cell ″Structure_2″(not sorted)

  cd2b135d Cell with Comments

  d2c6c150 Cell without Comments

  1fedd20d Cell Comments

  0f4c0817 Cell Body Layer 1

  d4133b6c Cell Body Layer 19

  0999f22b Cell Body non-Geometric Data Layer 5

Cell ″Structure_3″(not sorted；hierarchical)

  a7100492 Cell with Comments

  3d4d7fbf Cell without Comments

  9a5d7b2d Cell Comments

  7b78aab4 Cell Body non-Layer

  15546763 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

Cell ″Structure_4″(not sorted；hierarchical)

  70262033 Cell with Comments

  5242eac1 Cell without Comments

  2264caf2 Cell Comments

  7b78aab4 Cell Body non-Layer

  7a5bf21d Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

参考文件testfiles/sigtest.gds的处理生成32比特文件级概要db7be73c(十六进制)。当针对整个文件的概要存储在概要储存库中时，可以使用该概要来快速确定从最后处理概要并将其存储在储存库中之后，是否对文件进行了任何改变。

GDSII是二进制文件格式。包含二进制数据的文件不包含空白，因此不报告空白的概要和非空白概要。在适当时，非空白概要可被报告为确定对数据文件的改变是否仅源自空白中的改变的方式。文件内的符号(文本)通常由空白(空格字符、制表符或者换行符)分开，并且通常空白的量不大。为了帮助确定是否进行了对符号数据的改变，原型规范化概括工具计算针对文件中所有空白字符以及针对文件中所有非空白字符的概要。注意，空白概要逐字节地捕获空白的量，而与其位置无关。例如，将针对两个字符串“abc def”和“abcd ef”报告相同的空白(使用单个空格字符)和非空白概要。

GDSII文件中的多数数据在单元(GDSII命名法中的“结构”)内，但是任何单元的外部都存在一些记录。该数据在文件头部概要中进行概括。该头部数据可以由类型划分为文件头部注释或者文件头部非层数据；没有为GDSII文件头部内的数据指派层序号。下文描述GDSII数据的解释和记录的细节。

为了一致性，可以使用公用报告格式或者概要可以保存在数据库中。在该示例中，当针对某个概要类型没有记录数据时，则打印词语“(无)”来代替该概要。在报告内的文件概要块中示出了这样的两个示例。

合成文件头部概要与个体文件头部概要一起记录。为了用户方便，其由命令行工具来计算；在一个实施方式中，其仅是个体文件头部规范化单元概要的异或(XOR)。也可在计算单元概要的相同时间计算合成文件头部概要。合成文件头部概要可以用于帮助检测文件头部数据中的改变。

个体单元概要块出现在文件头部概要块之下。如图所示，单元概要包括注释概要、针对层和非层数据的几何概要、针对层和非层数据的非几何概要，以及针对具有和不具有注释的合成单元概要。由于具有合成文件头部概要，在一个实施方式中，合成单元概要通过与其他单元概要异或而生成。其可以用于帮助检测单元数据中的改变。

针对上述GDSII文件的概要在未对数据进行排序的情况下生成。这在文件名下方打印的程序参量列表中与概要的块一起进行报告。

单元Structure_3和Structure_4是层级的，这意味着它们具有对其中的其他单元的SREF或者AREF引用。一般而言，在设计数据库层级中较高的、针对布局和布线单元以及其他单元的概要将比针对其引用的叶单元的概要更频繁地改变。改变的单元是否是叶单元这一知识可以帮助确定概要改变的重要性。

考虑针对单元Structure_1和Structure_3的规范化单元概要，可以看到：针对这些单元的所有概要是相同的。这指示了针对这两个单元的多边形和结构(单元)引用数据相匹配。针对Structure_2和Structure_4的概要与针对任何其他单元的概要不匹配。

如果请求了排序，则针对单元的某些部分生成不同的概要：

File ″testfiles/sigtest.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -sort

  db7be73c File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  8f078078 File Header with Comments

  3289c53f File Header without Comments

  bd8e4547 File Header Comments

  3289c53f File Header non-Layer

Cell ″Structure_1″(sorted)

  a7100492 Cell with Comments

  3d4d7fbf Cell without Comments

  9a5d7b2d Cell Comments

  7b78aab4 Cell Body non-Layer

  15546763 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

Cell ″Structure_2″(sorted)

  cd2b135d Cell with Comments

  d2c6c150 Cell without Comments

  1fedd20d Cell Comments

  0f4c0817 Cell Body Layer 1

  d4133b6c Cell Body Layer 19

  0999f22b Cell Body non-Geometric Data Layer 5

Cell ″Structure_3″(sorted；hierarchical)

  a7100492 Cell with Comments

  3d4d7fbf Cell without Comments

  9a5d7b2d Cell Comments

  7b78aab4 Cell Body non-Layer

  15546763 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

Cell ″Structure_4″(sorted；hierarchical)

  1f29b54d Cell with Comments

  3d4d7fbf Cell without Comments

  2264caf2 Cell Comments

  7b78aab4 Cell Body non-Layer

  15546763 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

在解析之前从文件数据产生的文件级概要没有受到排序的影响。文件头部概要块也没有改变，因为GDSII文件头部数据是顺序相关的并因此是未排序的。多个单元元素概要被改变，因为该数据通过排序而被重新排列。针对单元Structure_4中的单元主体层3和42的规范化单元概要现在与Structure_1和Structure_3的规范化单元概要相匹配。这示出了Structure_4是与Structure_1和Structure_3相同的层。

针对某些格式(例如，GDSII和OASIS)，排序对于概要匹配是非常有用的，以至于应当将其作为默认行为。IC设计文件中的多数单元是较小的，所以仅存在受限的运行时影响。

如果请求64比特概要，在没有排序的情况下，报告的摘录将是：

File ″testfiles/sigtest.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -nosort

  3670d1e4a8c8c74b File

  (none)           File non-Whitespace

  (none)           File Whitespace

File Header(not sorted)

  026a2a5b01e0f6ec File Header with Comments

  fd352337a1644620 File Header without Comments

  ff5f096ca084b0cc File Header Comments

  fd352337a1644620 File Header non-Layer

Cell ″Structure_1″(not sorted)

  41a9962cc923db00 Cell with Comments

  a9a2d1241367de40 Cell without Comments

  e80b4708da440540 Cell Comments

  bb89d94bb8544e78 Cell Body non-Layer

  b9ef42b48f65e40d Cell Body Layer 3

  e16d5f5cf714adc4 Cell Body Layer 42

  4aa91587d342d9f1 Cell Body non-Geometric Data Layer 3

Cell ″Structure_2″(not sorted)

  30f8dca7d40bb330 Cell with Comments

  1db29288b51ebd16 Cell without Comments

  2d4a4e2f61150e26 Cell Comments

  a80b7d0fa1a83fe1 Cell Body Layer 1

  4bb6333790890817 Cell Body Layer 19

  fe0fdcb0843f8ae0 Cell Body non-Geometric Data Layer 5

顺序使用规范化概要和DIFF工具

以上提到了区分工具和算法。区分工具需要成对文件，该成对文件将被进行比较以计算差异，以便在分析时呈现。相反，规范化概要可以在没有任一文件呈现的情况下进行比较。

规范化概要与区分工具相结合的一个应用将是使用规范化概要来标识不同的单元以便进一步探究。区分工具可以用于标识不同的单元内发生了什么改变的细节。区分工具的良好集中使用比尝试使用区分算法来比较整个设计文件更为有效。

典型的区分算法需要数据或多或少按照相同的顺序以便进行比较，因为它并不知道有效的重新排列。毕竟它们在寻找公共子序列。区分算法的运行时间在最坏的情况下是指数级的。为了改善其运行时间，多数区分算法具有最大窗口，这些算法假设在该最大窗口之外的是完全不同的数据(即，如果窗内不存在匹配)。Paul Heckel的区分算法是这些限制的例外。参见“A Technique for Isolating Differences Between Files”，Communications of the ACM 21(1978年4月)：第264-268页。

区分算法假设它们正在比较的数据文件中没有结构(或者具有非常少的结构，仅有文本行)。其本身并不理解单元、头部、层、非层数据或者注释。

DesignSync和IC Manage是用于IC设计行业的工具，其看上去是基于标准文件区分算法的。这些程序看上去对其管理的数据的功能重要性并没有深刻理解。IC Manage(http://www.icmanage.com)在下层使用Perforce源代码管理系统。Perforce是通用数据管理和区分工具，其不尝试理解EDA数据文件格式。DesignSync(http://www.3ds.com)文献讨论了将多个相关文件链接到一起以表示单元(即，多个视图)。关于DesignSync的更多信息可以在以下地址处找到(2009年5月)：

●http://www.3ds.com/products/enovia/industries/high-tech/semicond uctor/

●http://www.3ds.com/fileadmin/PRODUCTS/ENOVIA/PDF/SynchDesignSync-0805_PRESS_.pdf

●http://www.3ds.com/fileadmin/PRODUCTS/ENOVIA/PDF/SemiAccIPmgmt-0805_PRESS_.pdf

区分工具对于被规范化单元概要标识为近似匹配的单元的详细比较是有用的。因为运行时间、缺乏对EDA文件语法的理解、噪声报告以及匹配的限制，它们无法被有效地用于分析庞大的设计文件或者单元库。当对顺序无关的数据进行重新排列时，其无法报告哪些单元发生了改变，但是可以报告错误差异。

在概述了规范化单元概要及其有用性之后，转而利用如何构造芯片设计数据的规范化表示的多个示例来进行深入公开。

扩展的背景和词汇

通常，芯片设计经历三个主要阶段：1)标准单元和其他设计模板库的开发或者获取(并非所有的无晶圆厂设计公司都将开发其自己的设计模板库)；2)前端设计-RTL的创建，继而逻辑综合；以及3)后端设计-布图规划、布局和布线，以及现场优化(IPO)。

在前端设计中，较高层设计模板块由设计者直接并入(“实例化”)，而不是由逻辑综合工具来选择。逻辑综合通常仅选择标准单元，规范化单元具有较简单的功能，因为其将设计者的RTL转化为用于后端设计的结构化网表。在后端设计中，逻辑适应所使用的掩膜的生产，转而用于制造芯片。

高级集成电路(有时称为“片上系统”或者“SoC”)包含电路的高层功能块，其可以是复合的设计模板或者设计的已完成布局和布线部分。后一种通常包括由逻辑综合系统选择的标准单元。

无晶圆厂芯片设计公司和第三方设计模板供应商创建了复杂的单元块，其包含不止一个标准单元，并且可以执行集成电路设计中通常使用的一些操作。例如，ARM处理器可用作可以并入到芯片中的设计模板。

包含对较小单元或者单元块的一个或多个引用的较大单元块被称为层级式的。较大块内包含的单元块本身可以是层级式的，使得单元块内可以存在若干层的层级。因为较小单元和单元块通过引用而并入，所以其视图和依赖关系保持相同。

单元和单元块的集合一起表示设计模板块库。块库可以由第三方供应商提供或者由内部库开发团队创建。此类库内的设计模板的范围从相对简单的块(诸如加法器和乘法器)到通信组件(诸如USB端口)，以及复合组件，诸如数字信号处理器(DSP)或者通用处理器(诸如由ARM提供的)。所有这些可以用在集成电路设计内的多个位置。

设计团队用于设计和制造芯片所使用的视图和伪像驻留在只读块库内。几十个库内可能存在数百到数千个设计模板，这些库一起形成服务集成设计组的较大库。逻辑和物理设计团队使用该库来分别创建集成电路的功能和物理布局。

并非来自库的每个设计模板都在集成电路设计中使用。逻辑综合工具通常从标准单元类型的子集中选择，仅选择与其优化算法相协调的单元。设计模板库可以包括相关功能块或者预先配置变量的类，诸如存储器块，并且设计团队可以选择仅使用这些变量的子集。

对于注意本公开中描述的事物与较通常使用的命名法之间的差别的读者，指出这里的“设计模板”在行业内通常称为“IP”。设计模板被认为能够较好地使读者注意到设计数据与集成电路之间的物理关系。

视图和伪像

单元具有视图和伪像。视图是单元的物理、功能或者电气表示之一。视图一起指定了单元在设计内如何工作，并且由此指定了设计者可以如何对其进行使用以创建集成电路。

伪像通常是由单元视图的创建产生的文件，诸如针对编译的RAM块的日志文件或者数据表单，或者在将设计模板并入到大块中时使用的约束文件。伪像通常是未被结构化的文本文件，其可能不在工具中在直接使用，而是向设计者传达意义。使其与针对单元的其他视图保持同步是有用的。

GDSII和OASIS(多边形级)示图表示叶(leaf)单元、单元块、功能块和整个集成电路的物理布局。Liberty视图表示针对叶单元或者复合设计模板的定时模型。

由设计者创建或者代替设计模板的物理布局而提供的RTL视图描述了设计行为以及与诸如处理器核的任何设计模板的逻辑连接。RTL视图通常是Verilog或者VHDL格式。逻辑综合使用RTL视图加约束和仿真控制文件来生成结构化网表(通常是Verilog或者VHDL)。

设计者使用结构化网表来创建用于集成电路的布图规划。设计交换格式(DEF)的视图表示用于布局和布线程序的布图规划。结构化网表、Liberty、LEF和DEF视图用作布局和布线程序的输入。布局通常一次在一个功能块内执行；布线在功能块中(块内)以及在功能块与设计模板之间(块间)都执行。一些视图被用于创建其他视图。例如，将针对叶单元或者标准单元的GDSII多边形数据发送至电路提取器以用于确定晶体管连接和寄生元件。这些导出的视图称为相关视图。当源视图改变时，重新生成某些或者全部相关视图是有用的。

单元、单元接口和单元主体

通过分析文件并且通过类型对各部分进行归类来计算文件的规范化概要。很多文件具有头部，其可以包括关于该文件的全局信息。还可能存在单元或模块，它们是被结合以形成设计的独立设计单位。单元可以被进一步分解为单元名称、单元接口和单元主体。几乎所有文件格式还具有用于指定注释的方法，其中注释是仍然可以向读者或者特定工具传达某些意义的正式的非功能性文本。

单元的接口是单元去往外部世界的说明。假定对接口的改变是重要的，所以将其独立地添加标志以便审阅和批准。随着设计接近完成，针对接口改变的批准的标准将增加，因为将需要大量的重新工作以使用新的单元。例如，如果布局单元中管脚的放置改变，则新的版本在不对设计进行重新布线的情况下无法用作插入式(drop-in)替换。这在逻辑设计期间不是问题，但是在物理设计的后期阶段，这将造成主要的计划延迟。

不构成单元接口某一部分的组件是单元主体的部分。单元的这些方面可以改变，而不会自动地使现有的单元实例化无效。例如，在布局单元的中间植入层的改变不需要进行重新布线。

GDSII和OASIS文件在单元主体内具有两类数据。第二类数据是非几何数据，诸如文本点和节点，所以称为单元非几何主体数据。区别是任意的；此类数据被简单地独立记录。其还可用于用户解析的文本文件。

一些文件格式可以指定层级数据：包含对其他单元的引用的单元。在该信息可用时，将其与概要一起返回作为单元中的标志。

层

多个设计文件被划分到层中。不同的层具有不同的功能，并且对某些层的改变比其他层“廉价”。例如，如果在制造出设计之后发现了逻辑错误，则仅需要对一个或多个金属掩膜进行修改的安装比需要改变晶体管层的安装廉价。针对文件头部、单元接口和单元主体的概要可以在逐层的基础上定义。

在内部，概要模块记录关于层的概要，其中层由整数(通常从-1到较小正数)索引。编号为-1的层通常表示不在任何层上的数据，诸如布局文件(GDSII或者OASIS)中的单元引用，或者针对不具有层的格式的所有数据。

具有基于文本的层名称的解析器返回层编号向层名称的映射，使得可以通过名称来报告概要。解析器本身可以指派层编号，所以其对于利用概要来获取该列表以及记录或者打印编号是有用的。

排序

按照某些格式的某些数据部分是顺序无关的，这意味着文件的解释不取决于头部或者单元内的对象(例如，多边形)出现的顺序。提供有对这些文件部分进行排序的选项。例如，VHDL模块可以使用关联列表进行实例化，在该关联列表中，通过名称将接线与端口相关联。这些可以按照任意顺序列出。然而，模块内的连续语句不应当进行重新排列，所以即使在选择了排序选项时，也不对其进行排序。

如果在可以对所有文件数据进行排序之前在存储器中保持文件数据，则可能需要大量的存储器。如果超过了传递给程序的存储器使用限制，则可以按照所存储的数据(通常是单元数据)从文件中读取的相同顺序立即向概要模块发送所存储的数据，或者可以使用基于文件的排序。排序例程的细节在单独文件格式的描述中公开。

当改变了存储器使用限制时或者在程序存储器使用改善的情况下，文件头部和单元概要可以改变。表明单元是否被排序的标志通过应用编程接口(API)可得，并且可以与针对文件头部或者单元的概要一起保存在概要数据库中。使用该标志，程序可以确定概要是否由于数据中的实际改变而改变，或者仅由排序中的改变而引起改变。

注释

对于多数格式，在没有排序或者进一步解释的情况下，立即向概要模块发送注释。将单元内的注释添加到针对该单元的注释概要中；将任何单元外部的注释添加到文件头部注释概要中。在VHDL中，注释可以包含综合指令，所以其与特定记号序列相关联，并且由此可以进行排序。

注释没有层名称或者编号。

所审阅的设计数据文件格式

多种芯片设计数据视图使用专用的文件格式。这些格式中的某些是二进制的，并且某些是文本(符号)的。然而，这些文件常常较大，并且即使在人类可读时也难于查看。其由库和设计模板供应商创建，并且由电子设计自动化(EDA)工具使用，但是典型的设计公司还没有能力解释这些文件以及自己做出关于这些文件的判断。

GDSII和OASIS视图包含叶单元和层级式单元的物理布局。叶单元仅包含几何形状(多边形、线形、矩形、圆形等)。层级式单元包含对其他单元的引用，并且还可以包含几何形状。还可以具有从供应商导入的诸如处理器核的可能的复合功能的设计模板块、单元。假设设计者使用没有修改的叶单元和设计模板块。

GDSII或者OASIS视图包含在单个文件中，并且包含针对多个单元的几何数据。此类视图可以定义将要在芯片内引用的几何数据库，或者其可以定义芯片的几何数据。

库交换格式(LEF)视图包含一个或多个叶单元或者设计模板块的物理布局的简化版本，以便向布局和布线工具呈现。

Liberty视图包含用于一个或多个单元的定时信息，该一个或多个单元可以是叶单元、复合设计模板或者各项的组合。

寄存器传输级(RTL)视图包含单元的行为描述。通常，RTL视图按照Verilog或者VHDL语言格式来指定。逻辑综合将RTL视图转换为结构化网表，该结构化网表是包含对叶单元、设计模板块或者其他结构化网表的引用的视图。结构化网表通常在Verilog或者VHDL语言格式的非常有限的版本中，其仅包含所引用的单元的列表，而不包含任何行为描述。结构化网表适于向布局和布线工具输入。一旦布局和布线了结构化网表，即可以对其性能进行评估，并且在适合的情况下还可以发布以进行制造。

设计交换格式(DEF)视图包含布图规划的描述，布图规划是对芯片的粗糙表示。其定义了较大设计模板块和空区域的布局，布局和布线工具将标准单元放置到其中。可以在芯片内创建针对块的DEF文件，针对该块运行布局和布线，并且继而在较高层DEF视图内使用该块。继而对经布局和布线的块进行与设计模板块相同的处理。

在创建标准单元库时，在物理布局上执行电路提取。创建器件的电气表示和物理布局中的互连(包括诸如电容和电阻器的任何寄生组件)，并且将其放入到电路仿真器(诸如SPICE)可用的格式中。SPICE视图可以表示针对叶单元或者层级式单元的数据。

SPICE视图用作对电路表征程序的输入，该电路表征程序通常使用SPICE或者其他电气仿真器在特定激励或者激励集合下评估电路，继而估计电路内的延迟。这些延迟继而存储在Liberty视图内。逻辑综合以及布局和布线工具使用Liberty视图来估计设计或者部分设计的性能。

如以上说明书所述，某些视图包含用于生成其他视图的数据。例如，GDSII或者OASIS布局视图用于创建LEF以及提取的网表视图，并且提取的网表视图用于生成Liberty视图。所创建的视图称为相关视图，并且在独立视图(诸如布局)与相关视图之间可具有复杂的关系。

标准单元通常实现相对简单的功能，从反相器(两个晶体管)到触发器(20-40个晶体管)或者加法器(10-100个晶体管)。其功能简单到足以使逻辑综合工具直接操纵。单个标准单元库中可能具有数千个标准单元，并且三个到大概数十个标准单元库可用于单个设计。

设计模板块通常实现更复杂功能，诸如处理器内核、读写存储器(RAM)、只读存储器(ROM)或者输入/输出子系统。其功能过于复杂以至于逻辑综合工具无法直接操纵。相反，设计者明确地要求将设计模板块的实例插入到其设计中，继而指定去往设计模板块的连接。为方便起见，通常将实例放置到RTL视图中。单个SoC设计中可以放置数百个个体设计模板块。

通常使用由设计模板提供商编写的编译器来创建存储器。这允许设计者生成由设计模板提供商担保的定制存储器配置(例如，字宽、字数目)，只要它们在编译器完成之后未被修改即可。为此，假定设计者将存储器编译器的输出作为设计模板块来处理。

存储器块可以包含在层级式GDSII或者OASIS视图中。在最终装配期间将该视图被并入到设计中。编译器还生成定时视图(通常是Liberty)和物理抽象(通常是LEF)，使得自动化工具可以分析使用存储器的设计。

在认为所有的标准单元库和设计模板块对于设计团队可用时，可能存在数万个不同的单元。并非所有这些单元都可以在给定设计中使用。例如，设计团队可能对使用异或(XOR)门的逻辑综合工具具有不良经验，所以他们可以告知逻辑综合工具不使用任何XOR门。一些单元功能可以存在于多驱动强度中(用于处理附加电路和寄生组件的改变的量的电流容量)，并且设计工具可能不使用给定设计中的全部驱动强度。

针对单元视图的规范化概要的工作示例

在本部分中，描述和分析用于IC设计的多种设计语言和文件格式。提供准备在IC设计流中使用的设计数据的规范化版本的十几个示例。

图1示出了高层集成电路设计环境。当然，关于该环境存在很多变体，并且很多细节没有示出。在该变体中，多数块示出了单元设计模板的开发者向无晶圆厂客户137提供模板可能遵循的过程，该无晶圆厂(fabless)客户依靠代工厂(foundry)151来生产芯片，并且根据来自代工厂的反馈来工作。根据该图示应当理解，无晶圆厂客户发布的用于由代工厂制造的设计包括用于掩膜生产的所谓“流片”。在设计过程的开始，设计者开发功能规范111并且执行逻辑设计以产生RTL 121，其可以提供竞争者的器件中没有的新功能或者以较低的价格提供。设计者具有来自代工厂的可用信息，该可用信息包括代工厂规则和电气信息141。代工厂信息反映在逻辑综合123期间与RTL相结合的单元设计模板131的库中。有时向无晶圆厂客户提供RTL作为前端视图125。逻辑综合的输出在布图规划133中使用；布图规划的输出在产生后端视图145的布局和布线操作143中使用。没有示出但易于理解的是，布局和布线操作受制于物理约束。后端视图被发布至无晶圆厂客户137。可以由或者针对无晶圆厂客户将后端和前端视图编辑到库中。这些后端视图按照客户不应当修改的固定块的形式。

图2示出了与图1的框相关联的版本和某些文件格式的扩展。附图之间的并行编号将两个附图中的框相关联。功能规范可以以设计语言来表示。功能规范约束将具有版本。逻辑设计221中创建的RTL可以以Verilog或者VHDL来表示，其将具有其自己的版本。代工厂规则241可以以诸如PDK、Interconnect(互连)、Parametrics(参数化)或者代工厂专有语言的语言来表示。引用单元库可以包括多个针对设计数据的视图。用于表示这些视图的语言包括SPICE、Liberty、LEF和GDSII。在逻辑设计221期间，输出可以包括仿真控制和RTL(Verilog或者VHDL)。逻辑设计的结果可以直接公布为使用Liberty、LEF和RTL表示的前端视图225；或者可以将其发送至逻辑综合223。逻辑综合223的结果与物理规范253相结合，并且用作对布图规划233以及对布局和布线243的输入。这些过程使用诸如结构化网表、DEF、Liberty、LEF和GDSII的视图。这些过程的结果可以发布作为后端视图245。无晶圆厂客户137可以使用设计数据的前端和/或后端视图。注意，包括在图2中的版本号仅是示例性的，并且不应当视为对过去、现在或者将来的语言或者库版本的引用。图2中引用的文件格式在以下部分中解释。

文件类型的分类

为了该讨论，文件被分类为非结构化文本、结构化文本、非结构化二进制或者结构化二进制。非结构化文件没有特定格式；其是诸如文档的辅助文件，或者其不具有单元和层。为这些文件所计算的概要是非常受限的。结构化文件具有定义的语法，其可以包括注释、层名称或者编号以及单元。这些需要解析器区分文件的各部分并且通过类型对其进行标记。

除了GDSII和OASIS文件以外，针对一种格式的文件生成的概要通常与针对另一格式的文件生成的概要不兼容。也就是，跨文件类型比较概要通常是无意义的。如果不存在对象属性，则可能将GDSII与OASIS数据进行比较，因为其首先被转换为支持跨这些文件类型进行比较的内部表示。一般而言，OASIS中的对象属性与GDSII中的对象属性不兼容，除非OASIS文件中的S_GDS_PROPERTY属性被转换为等效的GDSII属性。

文件类型及其解释的详细描述见下文。下文描述了文件解释、概要计算和排序行为的细节。各部分是独立的，使得其可以充当独立的参考。由此，一些信息可能是重复的。

在以下的描述中，语言关键词以Courier字体出现，例如HEADERTEXT或者scaled_cell。

文件级概要

解析器针对文件中按照没有解释或者排序的顺序的所有字节计算至少一个文件级概要。用于基于文本格式的解析器还针对所有空白字符(空格和水平制表符)以及针对所有的非空白字符计算文件级概要。这些不是规范化单元概要；其不是格式特定的，并且仅可以用于快速确定文件是否完全改变。

规范化概要

当记录规范化概要时，文件被分解为文件单位(file unit)，其与记录类型相耦合。文件单位是由语言规范定义的文件的一部分，通常是一个或多个记号(token)(单词或者标点)，并且记录类型是文件头部、注释、单元名称、单元接口、单元主体或者单元非几何主体之一。单元非几何主体数据仅是单元主体数据的独立类。目前，此类仅在GDSII和OASIS解析器中用于表明具有层编号的非几何数据，诸如NODE和TEXT记录。

如何针对文件格式计算概要的定义可能是复杂的，如图8-图17所示。各种格式的描述包括概观、用于处理文件单位的详细规范以及示例。

示例1：Liberty格式化文件

Liberty库文件格式提供了一种向逻辑综合工具描述电路的功能和定时的方式。它由Synopsys定义，并且得到广泛地使用，因为Synopsis已经发布了规范。它是可以易于查看的基于文本的格式，但是归因于Liberty文件中的数据量，其通常由软件创建。

在此第一示例中，将讨论Liberty设计语言文件的概括。Liberty文件的某些部分是未记录的。“未记录”是指规范化概括。一般而言，单元名称没有进行概括，因为这样做将阻碍否则具有不同名称的等效单元的匹配。一些解析器还跳过所需要的记号，并且不提供附加信息，诸如固定位置关键词或者层名称(因为概要无论如何都由层分离)。

在一些格式中，被记录的“文本”实际上是不可打印的二进制数据，并且描述使用来自语言规范的关键词。

规范化单元概要通常具有32或者64比特。两种类型都使用循环冗余校验(CRC)来计算。32比特概要使用SEMI标准P0039-1105中针对OASIS文件所规定的ISO 3309 CRC多项式和方法来计算：

x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1

64比特概要使用针对欧洲计算机制造商协会(Ecma)国际标准ECMA-182规定的CRC多项式来计算：

x⁶⁴+x⁶²+x⁵⁷+x⁵⁵+x⁵⁴+x⁵³+x⁵²+x⁴⁷+x⁴⁶+x⁴⁵+x⁴⁰+x³⁹+x³⁸+x³⁷+x³⁵+x³³+x³²+x³¹+x²⁹+x²⁷+x²⁴+x²³+x²²+x²¹+x¹⁹+x¹⁷+x¹³+x¹²+x¹⁰+x⁹+x⁷+x⁴+x+l

针对Liberty(.lib)文件的文件内容概要

应用于Liberty(.lib)文件的此示例的细节取决于scaled_cell记录是否在与cell记录相同的文件中。以下讨论的第一部分假设两种记录在相同的文件中。后一部分允许两种记录在不同的文件中。

Liberty文件具有针对以下文件元素中的某些或全部的内容概要：

●文件

●文件头部

●头部内的注释文本(可选)

●单元头部

●除文件头部信息以外的单元主体(可选)

●文件头部信息合并到单元中的单元主体(可选)

●单元内的注释文本(可选)

对文件进行扫描以发现内部的单元名称。针对文件中的单元，该工具返回针对单元头部的概要(输入和输出规范)以及针对单元主体的概要。

作为一个选项，针对头部中的注释文本和单元内的注释文本计算独立的概要，并且忽略空白(空格、制表符的数目相对于空格、空行)的差异。

针对文件头部(任何单元定义之前的信息)以及针对整个文件而计算并且返回概要。默认地，将针对文件头部(排除注释文本、文件日期以及修订)的概要与针对单元的概要合并，以避免(例如)由将影响库中的所有单元的逻辑阈值或者单位定义的改变而导致的问题。作为一个选项，当已知文件头部已经改变但是仍然期望进行单元比较时，可以将文件头部从单元主体概要计算中排除。

在记录任何概要之前，将所有的cell和scaled_cell组语句进行排列，而不管是否请求了文件的排序。针对单元的概要还包括所有的scaled_cell定时定义。在基于操作条件组名称的已排序顺序中，cell组是第一个，scaled_cell组在其之后。

因为scaled_cell记录可以出现在文件中的任何地方，甚至可以出现在未缩放的单元之前，所以不计算针对单元的“包括空白的所有文本”概要。该概要仅在文件级计算。

因为需要对具有cell记录的组scaled_cell记录进行排序，所以将整个文件载入到存储器中，而不管命令行中规定的存储器限制。然而，注意，cell和scaled_cell组语言可以出现在独立的文件中，在这种情况下，如果其出现在相同文件中，则最大限度地如下文所述进行处理，而不是对其进行排列。

单元头部概要中仅记录管脚名称。这例如意味着，如果管脚的方向改变，则头部概要将不会改变。

由于所需要的运行时间，组语句的排序在一个实施方式中是浅层的(shallow)：在对组语句的列表进行排序时，仅考虑组语句的一个子层。备选地，可以对多个子层进行排序。注意，对组内的语句进行排序(再次，使用一个子层)。所有排序都是稳定的，所以当比较的限制被超过时，先前按照特定相对顺序的语句将维持该相对顺序。例如，对以下进行排序产生以下表1中示出的结果：

表1：文件组语句的排序

排序前             排序后

g1 (B) {           G1 (B) {

  gb (A) {           ga (C) {

    p：Z ；            p：E；

    p：X；             p：F；

  }                  }

  ga (C) {           ga (C) {

    p：E；             p：D；

    p：F；             p：E；

  }                  }

  ga (G) {           ga (G) {

    p：D；             p：D；

    p：E；             p：E；

  }                  }

  ga (C) {           gb (A) {

    p：E；             p：X；

    p：D；             p：Z；

  }                  }

}                  }

组语句gb被移动到所有的ga组之后，因为关键词gb在ga之后，即使参数A在C之前。还要注意，具有参数C的两个ga语句维持相同的相对顺序，因为其低级p语句在排序期间未被考虑。p记录自身在ga记录内进行排序，并且针对ga记录之一的G参数使得其移动至ga记录集合的一端。

Liberty库描述文件

布局设计者通常将相同的单元名称用于不同库(例如高性能和高密度)中的单元，以便帮助区分不同库中的单元，对所有的单元名称预先考虑Liberty文件中的库名称。例如：

library (demo) {

  cell (INV_X1) {

    area：0.032；

    ...

  }

}

与该单元相关联的单元名称将是demo.INV_X1。

Liberty格式为所有期望的工艺拐点(process corner)规定多个缩放参数，其被设计用于帮助外推定时和功率系数。这对于某些单元可能并不充分，所以可以使用scaled_cell语句而不是常规的cell语句来定义针对这些单元的附加缩放单元记录。针对经缩放单元记录的单元名称利用经缩放单元名称来另外标记，这对于在两种类型都出现在相同文件中时区分单元类型特别有用。例如：

library (demo) {

  scaled_cell (AND2_X2，slow_slow) {

    area：1.064000；

    ...

  }

}

与此单元相关联的单元名称将是

demo.AND2_X2.slow_slow

Liberty文件还包含规定应用于单元的参数的广泛(extensive)头部。对此头部的不经意改变由此将具有显著的结果，所以默认将针对头部中至少一些参数的概要合并到针对文件中的单元的概要中。当在没有相应地改变所有单元的情况下不会意外地改变头部(诸如转换为较小的电压或者时间单元)时，可以使用-noheader命令行选项来禁用头部合并。

Liberty文件中的语句是顺序无关的，所以默认对语句进行排序，除非用户指定-nonsort标志。

Liberty文件中不存在层，所以所有针对单元的概要都被报告为非层数据，如以下样本报告：

File ″testfiles/tstlibpar2.lib″：Liberty format

Arguments：-mem 64 -sort

  728fb5e7 File

  451c31ec File non-Whitespace

  00a03577 File Whitespace

File Header(sorted)

  164c9eaf File Header with Comments

  1cc03fe0 File Header without Comments

  0a8ca14f File Header Comments

  1cc03fe0 File Header non-Layer

Cell ″demo.AND2_X1″(sorted)

  be7930d6 Cell with Comments

  be7930d6 Cell without Comments

  (none)   Cell Comments

  fe7aeb77 Cell Interface non-Layer

  4003dba1 Cell Body non-Layer

此处启用了头部合并；否则文件名称下的参量行将具有报告的-noheader。

处理Liberty格式文件的细节：定义

原型Liberty解析器遵循Synopsys的Liberty参考手册(版本2007.03)中的Liberty格式定义。

语法解释

Liberty参考描述了三种语句类型，其可以总结如下：

keyword：value；

keyword＝value；

keyword(value...)；

keyword(value...){statement...}

前两种形式称为简单属性。第三种形式称为复杂属性，而第四种称为组语句。组语句转而可以包含简单属性、复杂属性或者组语句的任意组合。注意，第二形式的简单属性的结尾的分号以及组语句的括号内列表是可选的。

虽然假定语句的第一记号是关键词(即，保留字)，但是Liberty格式允许库供应商定义新的简单属性，并且因此仅执行有限的关键词检查。解析器确保Liberty文件包含一个或多个库组语句，并且确保任何cell或者scaled_cell语句在该库内。解析器还寻找单元级语句，其可以是单元接口的考虑部分。否则，允许遵循以上一般语法的任何语句。

Liberty格式文件中不存在层名称，所以记录针对非层数据具有默认为-1的层编号的所有概要。

该参考规定了C样式的注释，其开始于记号/*，结束于记号*/。假设注释不是嵌套的。将单元内的注释记录为针对单元的概要的一部分。将出现在任何库外部的注释或者出现在库语句内部但是任何单元外部的注释记录为文件头部注释。

Liberty格式提供了用于指定在不同的操作点处表征的单元的缩放版本的方式。在一个实施方式中，这些scaled_cell语句被视为独立单元，因为其出现在与单元的非缩放版本不同的Liberty文件中。

因为在多个库中可能出现相同的单元名称，所以一个解析器实施方式利用其库名称以及scaled_cell名称(如果有的话)来限定单元名称，例如，用于cell的cmos_90nm或者用于scaled_cell的cmos_90nm.andx2.slow_slow。如果任何名称的组成包括′.′字符，则该组成被引证为：″cmos_90nm.v2″.andx2.″slow.slow″。

库中的顶层语句包括影响库内所有单元的解释的多个参数。例如，单元内的延迟或者功率值可以以纳秒或者皮瓦为单位来测量。手工编辑的或者利用脚本从文件碎片汇编的Liberty文件可能具有不与单元相对应的头部。为了帮助检测此类错误，将多数库级属性收集到头部块中，继而可以将该头部块合并到单元中以用于概要记录。很有可能随版本而改变的属性(例如，date或者version)从该头部块中排除。

cell或者scaled_cell语句内的多个属性和组语句指定单元的接口，意味着对这些语句的任何改变将意味着该单元的功能已经以有意义的方式改变。参见“带注解样本Liberty文件”部分以查看完整列表。

pin、bus和bundle组语句内的某些属性还指定了单元的接口。然而，可以合理地期望这些语句内的某些数据随着库的版本而改变。例如，无论何时更新了过程参数或者改变了布局的某些部分，即使单元的功能仍然相同，timing组语句都将改变。

Liberty文件的排序

Liberty文件不是顺序相关的；单元内的语句或者单元内的组语句可以按任何顺序出现。为了允许可能具有重新排列的语句的库之间的比较，可以对单元内的语句进行排序。主排序关键字是开始语句的关键词。如果两个关键词都是用户定义的属性(与预先定义的Liberty关键词相比)，则执行字符串比较，并且按字母顺序排第一的关键词是语句列表中的第一个。如果两个语句的关键词是相同的，则辅排序关键字是语句中的参数列表。将参数作为字符串比较，并且如果存在差异，则具有按字母顺序排第一的参数的语句是语句列表中的第一个。如果所有的参数都是相等的，只是一个参数列表较短，则具有较短参数列表的语句被排在前面。

如果参数列表是相同的，则将语句视为相同的。为了限制排序期间的运行时，一些实施方式不比较组语句内的语句。使用稳定排序，以使得语句排列仅在存在明显差异时才改变。

原型Liberty解析器的限制

Liberty文件中的多数记号(包括library、cell和scaled_cell名称)假设是区分大小写的。true和false是例外，其在参考Synopsys解析器实现中是不区分大小写的。

解析器假设存储器使用限制将高到足以用来存储所有的单个cell或者scaled_cell的语句加上所有的文件头部语句。

除语句结构的验证之外，仅进行有限的语法检查。例如，允许多个顶层library语句。如果库的结构不遵循Liberty语句语法，或者如果顶层不存在library语句，则报告错误，并且不计算概要。

出现在单元之间的头部语句仅被合并到文件中在其之后的概要中。对于多数完整的概要记录，所有的库头部语句应当在任何cell或者scaled_cell语句之前出现。

因为针对包含文件的搜索路径不可用(并且可能随时间改变)，所以不处理包含文件指令。

字符串内的值未被解释。假设相同工具将创建Liberty文件，并且这些工具例如将不会对编号进行重新格式化，除非编号实际上已经改变。

将要从库头部中排除或者包括在单元接口中的关键词列表应当是固定的，并且在仔细考虑之后改变，因为当关键词列表改变时，很多概要需要重新计算。

将文件头部中的单位编号作为显式记号(例如，1ns)或者作为字符串(例如，″1mV″)来支持。假设，文件的新版本将不会在两个表示之间切换。

带注解的样本Liberty文件

图8A-图8D示出了Liberty文件中的可能头部和单元语句的采样。多数头部和单元语句以所示出的方式进行处理。特别地，当把整个组语句记录为相同的概要类型时，图8中仅示出了关键词、参数(如果有的话)以及花括号。单元外部的属性和语句被添加到文件头部概要中。在单元内，仅将所标识的属性和组语句记录为单元接口的一部分。如所指示的，将强调的某些属性和组语句记录为单元主体的一部分。

默认地，多数文件头部语句(排除注释记号)被记录为单元接口的一部分；此处没有示出。没有将date、revision和comment属性记录为单元接口的一部分，因为其可能在修改Liberty文件时改变。

很多简单cell和pin属性被视为单元接口的一部分；它们被列在以上示例中。加双下划线或者这里没有示出的部分都被视为单元主体的一部分。

注意，bus和bundle组语句可以包括pin语句以及嵌套的pin语句的任何简单属性。将bus和bundle语句的属性记录为如同其在pin语句中一样；将嵌套的pin语句的内容记录为如同其是独立的管脚一样。

在Synopsys参考解析器中，简单的属性可以使用‘：’或者‘＝’来将变量名称与之后的表达分离，因此以下是等效的：

area＝5；

area：5；

文档使用‘：’，所以所有的‘＝’在发送至概要引擎之前都被转换为‘：’。

没有记录用于简单和复杂属性的分号，因为Synopsys参考解析器并非总是需要它们，有效地使其可选。

示例2：Verilog文件类型

Verilog是集成电路设计中广泛使用的仿真和寄存器传输逻辑(RTL)语言。它是通常由设计者创建并且由逻辑综合工具编译的基于文本的格式。其允许设计者将设计指定为互连模块。电路功能在记录为单元的模块中指定，输入和输出端口记录为单元接口。将对逻辑综合工具的暗示放到与模块头部或者语句相关联的属性中。

在此示例中，Verilog文件具有针对以下文件元素的内容概要：

●文件

●文件头部

●单元模块端口定义

●单元模块的主体

对文件进行扫描以找到内部的模块名称。针对端口定义和模块的主体计算独立的概要。这些基于排除任何空白的个体Verilog记号。

针对文件的头部(任何模块定义之外的信息)以及针对整个文件而计算和返回概要。

假设Verilog 2005语法，即使出现了′begin_keywords。因为仅解析文件的模块结构，所以这不应当影响针对文件的概要计算(例如，关键词不与符号不同地解释)。假设文件在语法上是正确的。

不解释编译器指令(包括宏替代)。假设文件是不具有宏替代的有效Verilog。一般而言，假设仅针对常量定义使用宏，并且其不创建诸如模块头部或者Verilog语句的语法结构。

不解释包含文件指令，因为概要计算时的包含路径可能与编译时的包含路径不同。

在一个实施方式中，假设综合指令在Verilog属性(“(*”和“*)”)内，而不在注释内。如果存在紧邻模块或者宏模块声明之前的属性，则其概要被添加到模块的概要中。模块声明之外的注释被视为源文件的“头部”(非模块文本)的一部分，而不是模块自身的一部分。因为在解析器了解模块声明之前扫描前述属性的字符，所以其被添加到针对头部的“全文本”概要中，而不是模块自身中。模块之外的注释被添加到文件头部概要中。模块和宏模块被视为等效的对象。在一个实施方式中，功能、UDP和生成块被视为源文件的“头部”的部分，而不是模块自身。有可能将这些视作模块的特殊形式，以与处理VHDL构造(诸如过程和功能声明)类似的方式将其记录为单元。如果list_of_ports中的任何端口使用“.”或者“{}”记法，则将不对list_of_ports中的端口名称进行正确的排序。

不计算针对单元内的空白的概要。仅计算文件级空白概要。在单元内，概要仅基于文件的记号(在适当时包括注释)。

Verilog RTL文件

Verilog模块的很多主体是顺序相关的，所以只能对模块参数进行排序。即使如此，模块也并非总是使用顺序无关的参数规范来实例化，所以在排序之后发现的概要匹配可能不表示模块定义之间的真正等效。由此，Verilog文件的排序应当慎重进行。默认地，不对Verilog文件进行排序，除非用户指定-sort标志。

Verilog文件中不存在层，所以所有针对单元的概要都被报告为非层数据：

File ″testfiles/verilog_test.v″：Verilog tormat

Arguments：-mem 64 -nosort

  5404c699 File

  7c2a352d File non-Whitespace

  219b1881 File Whitespace

File Header(not sorted)

  b290d605 File Header with Comments

  (none)   File Header without Comments

  b290d605 File Header Comments

Cell ″DFF_X1″(not sorted)

  ca436d2f Cell with Comments

  ca436d2f Cell without Comments

  (none)   Cell Comments

  c102a525 Cell Interface non-Layer

  0b41c80a Cell Body non-Layer

Verilog格式文件：定义

Verilog语言规范是IEEE标准；原型Verilog解析器遵循IEEE标准1364-2005中的语言定义。这尚不包括Verilog-A(模拟)扩展，但是可以易于进行扩展以将其包括。

虽然Verilog RTL描述在逻辑综合中使用，但是语言本身不足以确定设计者的意图。逻辑综合工具提供用于通过使用属性来引导优化的手段。这些是类似于注释的记号序列，其在Verilog模块和语句之前或者嵌入在其中。属性内的文本形成综合指令。原型Verilog解析器解析Verilog属性，将其指派至适当的语言结构，并且将其发送至概要引擎，但是其不解释内部的文本。

在将属性附加到Verilog语言之前，使用Verilog注释来指定综合指令。解析器目前不支持使用针对综合指令的注释，但是它可被容易地扩展以支持上述使用。

语法解释

Verilog文件是声明和模块的序列。模块是规范化单元概要工具中的单元；其他所有的都记录为文件头部的一部分。

模块可以具有由参数指定的接口。存在两种样式的参数定义：端口列表和端口声明列表。端口列表仅具有模块语句中存在的端口名称，而端口声明列表还具有端口类型。

module a(b，c，d)；//list of ports

module a(input [7:0] b，output [8:0] c，reg d)；//port declarations

当使用端口列表指定对模块的接口时，声明嵌入在模块主体中。解析器寻找声明，并将其作为单元接口数据发送至概要引擎。模块主体中其他所有内容都作为单元主体数据发送至概要引擎。

当使用端口声明列表指定对模块的接口时，模块主体中的所有内容作为单元主体数据发送至概要引擎。

解析器假设模块和宏模块是等效的。宏模块在被发送至概要引擎之前被转换为模块。

不对宏定义进行解释。因为宏定义可能在解析器不可用的已包含文件中，或者可能随时间改变，因此不会尝试展开宏引用。假设宏不包含语法结构，使其可以通过假设宏引用与标识符或者数字等效而解析Verilog文件。

库声明和include语句被记录为文件头部数据。不读取include文件；include文件搜索路径对规范化单元概要程序不可用。其也可能随时间改变，从而使已经计算的任何文件概要无效。

可以将功能、用户定义的原语(UDP)定义、生成块和配置声明添加到文件头部概要中，而不进行进一步解释，或者可以视为在VHDL文件中。

紧邻模块关键词之前的或者模块主体内的属性可以记录为单元主体文本。所有其他属性记录为文件头部文本。

Verilog文件的排序

Verilog中的很多语句是顺序相关的，因此无法进行排序。解析器不尝试确定模块主体的哪些部分是顺序无关的，其仅排序模块定义的参数。因为模块实例化可能不使用顺序无关的参量规范，所以排序之后发现的概要匹配可能不表示模块定义之间的真正等效。由此，Verilog文件的排序应当谨慎进行。

可以逐个指定模块输入和输出声明，或者如果类型相同，则在列表中指定。例如，以下声明集合是等效的：

input signed [4:0] RN，CK，D，SE；以及

input signed [4:0] RN；

input signed [4:0] CK；

input signed [4:0] D；

input signed [4:0] SE；

解析器将输入和输出参数声明从第一形式扩展到第二形式。继而可以根据参数的名称对其进行排序。

解析器假设存储器使用限制高到足以存储针对模块的所有端口定义，因为最多将只有几百个。

原型Verilog解析器的限制

解析器不尝试对模块实例化中的参量列表进行排序，即使在所有的端口通过名称连接(例如，.Out(topB))时也是如此。

当模块主体内的变量声明在端口列表中被指定时，可以用于修改端口声明的含义。解析器不尝试定位这些附加声明。例如：

module a(b)；

  input b；

  wire signed [7:0] b；

endmodule

这里，输入端口b的类型由wire声明修改，但是wire声明没有被添加到单元接口概要中。

当端口声明使用具有‘.’的外部名称或者具有“{}”的并置(concatenation)时，解析器不尝试指派“端口名称”。通常将端口名称定位在声明内，并且在记录针对端口的概要时被用作接口记录名称。当存在外部名称或者并置时，将声明的第一记号用作用于对端口进行排序的“名称”。

模块端口列表中的参数声明(使用‘#’指定)被添加到单元主体概要中。

当在文件中发现宏定义时，将其发送至概要引擎。其可能在文件头部内或者在单元内。没有对宏引用进行展开，因为宏定义可能在另一文件中，而该文件对于规范化单元概要工具而言可能不可用，或者可能随时间而改变。

也不解释编译器指令。

将数值文字在不解释的情况下向概要引擎发送。特别地，不将其首先转换为规范化形式。例如，指数中的加号是可选的，所以1e10将不同于1e+10。数字不是重印的，所以1e10也将不同于1.0e10。

解析器不尝试确定何时可以将Verilog模块视为层级式的。

带注解样本Verilog文件

图9是示出解析上述规则的应用的Verilog文件的带注解样本。

示例3：结构化二进制文件类型

在此示例中，将不具有定制解析器的结构化二进制文件类型视为非结构化二进制文件。

通常，在不知道二进制文件的结构的情况下，为所有字节指派概要。为了向结构化二进制文件内的特定内容指派概要，数据结构需要是已知的，并且需要为其编写的解析器。

示例4：VHDL文件类型

VHDL是集成电路设计中广泛使用的仿真和寄存器传输逻辑(RTL)语言。它是通常由设计者创建并且由逻辑综合工具编译的基于文本的格式。

在此示例中，VHDL文件具有针对至少以下文件元素的内容概要：

●文件

●文件头部

●实体块

●架构块

扫描该文件以找到用于模块的实体和架构块。针对模块，为实体和架构计算独立的概要。备选地，可以计算较大(或者较小)粒度的概要，如以下VHDL“单元”的解释中所描述的。这些概要可以基于排除任何空白的个体VHDL记号(包括注释，因为综合指令可以包括在注释在)。

将针对文件的头部(任何模块定义之外的信息)和针对整个文件而计算和返回概要。这些包括所有空白。不检查来自USE指令的包含文件也不将其添加到概要中。

VHDL RTL文件

很多VHDL语言结构可以视为满足“单元”的定义，包括实体、配置、架构、过程、功能、组件、类型和子类型。对这些中任何一个的改变都可能对设计具有深远的影响。从解析的角度看，这些以及其他VHDL声明类型也是库内的第一类对象。由此，解析器创建针对以下VHDL语言结构的单元(使用来自IEEE标准1076-2002的附录A的产品名称)：

●subprogram_declaration(a procedure or a function)

●subprogram_body(a procedure or a function)

●type_declaration

●subtype_declaration

●constant_declaration

●signal_declaration

●shared_variable_declaration

●file_declaration

●alias_declaration

●component_declaration

●attribute_declaration

●attribute_specification

●disconnection_specification

●use_clause

●group_template_declaration

●group_declaration

逻辑综合工具的提示被放入与对象头部或者语句相关联的注释中。由此，组合的“具有注释的单元”概要比“没有注释的单元”概要可能更加有用。

很多语句VHDL是顺序相关的，所以仅可以排序声明中的参数。即使如此，架构和组件也并非总是使用顺序无关的参量规范来实例化的，所以在排序之后找到的概要匹配可能不表示真正的等效。由此，VHDL文件的排序应当谨慎进行。默认地，不对VHDL文件进行排序，除非用户指定了-sort标志。

VHDL文件中不存在层，所以所有针对单元的概要都被报告为非层数据：

File ″testfiles/timing_b.vhd″：VHDL format Arguments：-mem 64 -nosort

b116b16a File

0cafc41a File non-Whitespace

704d8ab4 File Whitespace

File Header(not sorted)

9f21a1ef File Header with Comments

d279ff8a File Header without Comments

4d585e65 File Header Comments

d279ff8a File Header non-Layer

Cell ″vital_timing.constant.edgesymbolmatch″(not sorted)

63c5ce8d Cell with Comments

63c5ce8d Cell without Comments

(none)   Cell Comments

63c5ce8d Cell Interface non-Layer

Cell ″vital_timing.function.vitalcalcdelay.1″(not sorted)

cd370359 Cell with Comments

cd370359 Cell without Comments

(none)   Cell Comments

be204681 Cell Interface non-Layer

731745d8 Cell Body non-Layer

如上所述，所报告的单元名称包括在其中定义对象的库(如果有的话)；对象的类型(常量、函数、实体、架构等)，对象名称以及用于重载解析的歧义编号。例如，函数可以被重载，意味着相同的名称用于具有不同参数类型的一组函数。逻辑综合工具通过检查所有可能的匹配来选择适合的函数。

规范化单元概要工具不实现完全的VHDL解析器。特别地，它不维护符号表，所以它仅基于对象名称而简单地记录具有名称的单元中的概要。因为如果重载的对象被添加到文件中或者从文件中移除，则歧义编号可能改变，所以用户的匹配软件将必须基于概要来选择适合的单元。

VHDL格式文件：定义

在20世纪80年代，为国防部定义了VHSIC硬件描述语言(VHDL)作为硬件系统定义语言。其现在仍然用作针对逻辑综合的寄存器传输语言。

VHDL是基于文本的语言，其允许设计者将涉及指定为利用架构实现的互连实体。这是具有影响设计规范的多个语言结构的非常复杂的语言。所有这些被记录为利用其类型来限定名称的不同单元，例如entity.full_adder。

VHDL语言规范是IEEE标准；原型VHDL解析器遵循IEEE标准1076-2002中的语言定义。这不包括VHDL-AMS(模拟)扩展。

虽然VHDL RTL描述在逻辑综合中使用，但是语言本身并不足以确定设计者的意图。通常将嵌入在注释中的综合指令添加到VHDL文本中以便引导优化。这些利用遵循其的语言结构来记录。对于Verilog属性不存在等效。

将包之外的注释添加至文件头部概要。

语法解释

如上所述，很多VHDL语言结构都可以视为满足“单元”的定义，包括实体、配置、架构、过程、函数、组件、类型和子类型。

VHDL支持名称重载，这意味着给定的名称可以映射至多个对象。编译器使用上下文和类型信息来选择适合的对象。

语言定义非常依赖于这两个概念，因为在其包含的文件完全不可用的情况下，解析VHDL文件易于出错。因为原型规范化单元概要解析器不是针对逻辑综合而设计的，并且因为其工作的上下文(例如include文件)可能随时间改变，所以其使用允许无上下文解析的稍微简化的语言规范。

VHDL还支持运算符重载，意味着可能存在具有不同类型和参数的相同对象的多个版本。例如，可以存在若干乘法运算符。

最终，针对给定设计实体，可能存在多个架构。这些应该是可互换的；设计者在实例化模块时指定要使用哪个架构。

由此，为VHDL设计的所有方面生成规范化单元概要需要歧义消除。两个到四个部分的已编码名称被指派给被记录为单元的对象：

●包名称，用于存储在包中的对象

●对象类型，例如架构或者函数

●由设计者指定的对象名称

●编号后缀，用于通过名称重载的对象

例如，Vital_timing.constant.edgesymbolmatch表示包vital_timing中的常量edgesymbolmatch，而vital_timing.procedure.vitalerror.1表示该包中名称为vitalerror的第二过程。因为规范单元概要是在逐个文件的基础上计算的，所以用户的软件在将概要排序到数据库中时可能必须进一步对名称消除歧义。对于具有独立规范和主体的过程和函数尤其如此——解析器直到很晚(在参数列表之后)才知道其是否具有规范或者主体，而在那时，单元名称已经被传送至概要引擎。

VHDL规范还提供嵌套的对象定义，例如过程内的函数。因为这些可以被无限地嵌套，并且因为其范围限于包含对象(使得其对于外部不可见)，所以不针对这些对象创建独立单元。其被记录为包含对象的单元主体的一部分。

VHDL规范使用ISO/IEC 8859-1标准中定义的8比特字符集。解析器具有针对所有有效8比特字符的完全支持。

除了扩展标识符以外，VHDL是不区分大小写的；在向概要引擎发送之前，解析器将扩展标识符以外的所有记号都转换为小写。

VHDL文件的排序

VHDL中的很多语句是顺序相关的，由此无法进行排序。解析器不尝试确定架构或者子程序主体的哪些部分是顺序无关的——其仅排序其声明中的参数。因为实例化可能不使用顺序无关的参量规范，所以在排序之后找到的概要匹配可能不表示实际匹配。由此，VHDL文件的排序应当谨慎进行。

可以逐个指定参数声明，或者如果类型相同，则在列表中指定。例如，以下声明集合是等效的：

X，Y，Cin：in Bit；

Cout，Sum：out Bit；

以及

X：in Bit；

Y：in Bit；

Cin：in Bit；

Cout：out Bit；

Sum：out Bit；

解析器将参数声明从第一形式扩展至第二形式。继而可以根据参数的名称对其进行排序。

因为entity是与一个或多个architecture的接口的规范，所以entity中的所有内容都被视为接口的部分，即使单词is之后的实体语句也是。

顶层对象(单元)的名称将被发送至概要引擎，以使得有可能发生具有不同名称的等效单元的匹配。顶层对象内的变量声明(包括子程序声明)的名称被记录为单元接口文本，但是这些变量内的任何声明的名称没有记录。例如，参见带注解样本文件、图10A-图10B。

原型VHDL解析器的限制

垂直制表符和换页符被转换为换行符，即使在将其添加至文件级概要之前也是如此。回车/换行对在被添加至文件级概要之前被转换为单个换行符。

解析器不尝试组合常量。例如，不执行字符串文字并置。“abcdef”将不具有与“abc”和“def”相同的概要。

不解释包含文件指令(library和use子句)，因为概要计算时的包含路径可能不同于编译时的包含路径。

不对过程单元和函数单元中的参数列表进行排序；解析器可能不知道过程或者函数中的参数的名称，因为其声明可能在另一文件中。即使参数处于使用＝＞的关联列表中，这也是成立的。

在无解释的情况下将数值文字发送至概要引擎。特别地，不将其首先转换为规范化形式。例如，指数中的加号是可选的，所以1e10将不同于1e+10。数字不是不重印的，所以1e10也将不同于1.0e10。

解析器不尝试确定何时可以将VHDL对象视为层级式的。

带注解样本VHDL文件

图10A-图10B示出了带注解样本VHDL文件。

注意，在architecture MC68000中，第一级嵌套函数(bclr_d)的名称被记录为接口文本，但是第二级嵌套函数(nested)的名称没有记录。这是因为bclr_d被视为接口变量，类似于过程VitalWireDelay中的变量Delay。没有任何嵌套过程被记录为独立单元；二者都被视为architecture MC68000的部分。

在此示例中，将一起描述具有相同文件元素的OASIS和GDSII文件类型。这些文件类型具有针对以下文件元素的内容概要：

●文件

●文件头部

●逐层几何对象

●逐层非几何对象

●对低级单元的引用

●涉及其他低级单元的布尔标志

扫描数据库以找到内部的单元名称。针对存在的单元，计算以下各项：

●所有几何对象(多边形、矩形等)的逐层概要；

●所有非几何对象(文本点等)的逐层概要；

●针对所有其他对象(诸如对低级单元的引用)的概要；以及

●指示单元是否具有对低级单元的引用的布尔标志。

作为一个选项，在概要计算之前对小规模和中等规模单元中的数据进行排序，使得数据排列差异不会引起概要差异。用户可以设置用于该选项的存储器使用限制。

在概要计算之前对OASIS重复和GDSII数组引用进行展开，以使得重复分析的差异不会引起概要差异。

针对文件的头部(任何单元定义之前的信息)以及针对整个文件而计算和返回概要。对于GDSII文件，假设该文件是语法正确的。

结构(单元)创建和修改时间被存储为注释；如果其在两个其他方面相同的单元中不同，则单元概要和注释概要将不同，但是所有的层概要将是相同的。

不认为GDSII或者OASIS单元中的任何数据是“头部”(对单元的接口)的一部分。假设其由外部工具生成并且存储在其他任何地方(例如LEF)。对于GDSII或者OASIS文件，不计算“空白”概要。结构引用(SREF和AREF)被报告为针对具有索引-1的非层数据的概要的一部分。在概要计算之前还可以执行GDSII或者OASIS多边形排序以及GDSII或者OASIS多边形合并(重叠移除)。

OASIS布局文件

OASIS文件是用于指定布局的结构化二进制文件。该格式可以具有多种不同方法以用于减少文件所需空间，诸如重复和压缩数据块。这些可能改变数据在单元中出现的顺序，或者甚至可能改变用于表现数据的数据构造(例如，RECTANGLE与CTRAPEZOID)。在内部，为了确保一致表示，所有几何构造都被转换为POLYGON记录并且重复被展开。

在适当的情况下，如果具有充足的存储器或者盘空间可用，则默认对OASIS文件数据进行排序。数据按层分组，并且继而按位置分组，从而生成相同的概要而不考虑数据原来在单元内如何排列。只要数据进行了排序，并且单元中不存在OASIS特性，用户的软件就应当能够在OASIS单元及其等效GDSII表示之间匹配概要。

为了避免浮点舍入误差，基于单元内的布局数据的整数坐标来计算概要。因为用户的优选设计栅格可能随时间改变，所以基于用户使用-grid命令行选项指定的较小栅格来计算规范化单元概要。用户应当细心选择该栅格，以担保所有的将来设计栅格是其整数倍。默认该栅格是1纳米(1.0e-9米)；其可以最佳地设置为较小的值，诸如0.5纳米或者0.25纳米。然而，如果栅格过小，用户在32比特机器上可能得到整数算术溢出。

因为所有的重复都被扩展以确保一致的表示，所以针对规范化单元概要计算的运行时性能即使对于相同大小的文件也可能显著改变。

这里是针对OASIS文件的概要报告的一部分：

Cell ″Structure_1″(not sorted)

  f64ce851 Cell with Comments

  f64ce851 Cell without Comments

  (none)   Cell Comments

  20b84e54 Cell Body non-Layer

  e03bf9d2 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  cb6c08c2 Cell Body non-Geometric Data Layer 3

在此示例中，没有请求排序，并且这在单元名称之后b被报告。OASIS单元中没有任何数据被记录为单元注释数据，所以概要被报告为“(none)”。存在记录为非层数据的一些结构引用，以及层3和42上的一些几何形状。最后，层3上存在一些非几何数据(一个或多个TEXT记录)。

OASIS格式文件：定义

开放原图系统交换标准(OASIS)格式由半导体设备和材料国际协会(SEMI)开发，以作为对GDSII的代替。其移除了数值的16比特和32比特限制，并且对布局文件大小的改善高达因数10。原型OASIS解析器遵循SEMI标准P39-1105(2005年11月)中描述的规范。支持名称表。

OASIS是二进制格式，所以为了清楚起见，本说明书使用OASIS规范中列出的记录名称。

OASIS文件的语法解释

OASIS规范提供了任意精度的整数和浮点数。然而，针对任意精度算术的算术封包较慢，并且没有在设计自动化业界被广泛使用。原型解析器使用自然数(当以32比特模式编译时是32比特，当以64比特编译时是64比特)以及IEEE双精度浮点数(64比特)。如果文件中出现超过这些限制的数字，则将记录(log)错误。

该规范还提供若干不同的数字表示，诸如无符号整数、带符号整数、比率、倒数和浮点。所有数字都被转换为用于比较的规范化形式—用于整数值的自然数以及用于浮点值的双精度浮点数。这允许由不同工具编写的数字的匹配，例如，5/2和2.5。

以类似的方式，在计算概要之前，将所有点列表(例如，1-delta列表)完全展开为X/Y坐标对列表。

设计工具具有相当大的自由度来选择用于表示布局单元的几何形状的OASIS元素。虽然布局编辑器通常将保存设计者的选择，例如PATH与POLYGON，但是最终输出可能具有等效POLYGON，以便减少PATH定义在弯曲处固有的歧义。此类工具还可能将POLYGON的“绕线方向”从逆时针改变为顺时针。为了避免这些问题，将所有的几何元素转换为用于规范化单元概要计算的规范化表示：

●将RECTANGLE、PATH、TRAPEZOID、CTRAPEZOID和CIRCLE元素转换为等效的POLYGON记录

●如果所产生的多边形具有逆时针绕线方向，则将POLYGON点列表反转

●选择列表中的第一个点作为最左下方的点

如果PLACEMENT记录中存在翻转(flip)，则将其进行排序如同其是GDSII STRANS记录一样(比特数组)。

如果PLACEMENT对象使用数字单元引用，则利用其对应的单元名称来替换数字，并且仅将单元名称发送至概要。

OASIS规范提供了所有构造的重复。不同的工具可以选择优化重复的不同方法。数据不管如何成组都是等效的，所以为了正规起见，将所有的重复展开为单对象引用(例如，矩形或者PLACEMENT记录)。为此，无法担保取决于文件大小的运行时性能—重复展开至上亿多边形的较小文件将需要大量的CPU时间。

OASIS文件还与较老的GDSII格式文件共存。OASIS使用描述重复的对象引用的不同方法，所以除非重复被展开，否则其将不能将重复的PLACEMENT对象与GDSII AREF进行匹配。

注意，在一些实施方式中，基于OASIS文件中的对象而不是下层的几何形状来计算概要。在计算概要之前，不执行重叠移除。

OASIS格式被设计为移除了对规范的“扩展”的需要。如果OASIS文件没有遵循规范，则解析器将返回错误。

OASIS层主要由编号进行索引(所有的几何构造都使用层编号，而不是层名称)；解析器目前不返回层名称(如果有的话)到编号的映射。

在文件的前端，使用栅格来指定OASIS文件中的坐标，例如1纳米(1.0e-9米)。在单元内，所有的坐标按照该栅格来定义，使其可以是整数。然而，文件栅格可能改变，而不会影响最终掩膜数据。例如，即使标准栅格是1纳米，所导入的设计模板块也可以使用5纳米的栅格进行指定。用户的软件继而将转换所有导入的数据，以使用较小栅格，利用因数5来缩放单元中的整数坐标。

为了确保正规，对OASIS文件中的所有几何形状进行缩放以使用内部的规范化单元概要栅格。用户应当细心选择该栅格，以使得将可兼容所有将来设计中使用的OASIS文件栅格。例如，如果目前设计栅格是5纳米，则最佳地使用1纳米或者甚至0.5纳米的概要栅格。

将规范化单元概要栅格值传送至OASIS解析器，并且如果OASIS文件栅格不是规范化单元概要栅格值的整数倍，则返回错误。

将具有PLACEMENT记录的结构标记为层级式的以用于概要报告。

OASIS文件的排序

如所提到的，OASIS文件使用与GDSII文件不同的方法来指定成组的结构引用。不同的供应商也可选择不同的重复优化方法。最终，可能在任何时刻对单元内的几何对象重新排序，而不改变文件的含义。由此OASIS布局的比较或者GDSII布局与OASIS布局的比较需要排序。为此，默认支持GDSII和OASIS布局的排序。

在将几何对象转换为规范化形式之后，可以按照如下将其与另一对象进行比较以用于排序目的：

●层名称是主关键字；首先是较低层编号

●元素类型(使用GDSII记录类型)是次关键字；较低元素类型排在前面

●元素的XY坐标(如果有的话)是第三关键字；对坐标逐个进行比较，并且针对给定条目具有最低、最左边的点的元素排在前面

●如果存在位置变换(即翻转)，则比较被转换为整数的比特向量，并且“最低”的一个排在前面

●接下来，比较DATATYPE值，并且最低的一个排在前面

●如果记录是位置，则按照字母顺序比较单元名称值，并且最低的一个排在前面

●接下来，比较MAG值(如果有的话)，并且最低的一个排在前面

●接下来，比较ANGLE值(如果有的话)，并且最低的一个排在前面

●最后，逐个比较PROPERTY值

期望将仅使用前三种比较(层名称、元素类型和XY位置)，以使其他比较的顺序在某种程度上可以是任意的。

排序标准实际上与用于GDSII的排序标准相同；已经从以上描述中忽略了不适用OASIS的字段。使用在OASIS中不具有有模拟的GDSII字段(例如，PLEX)或者在OASIS中不同的GDSII字段(例如，特性)将会阻止跨格式的单元匹配。

如果请求了排序，则收集单元中的记录直到到达单元的结尾或者直到存储器中存储了超过使用限制的单元数据。如果发生上述情况，则将所存储的单元记录按照其原始顺序发送至概要模块，或者可以使用盘排序来对其排序，这是以基本性能为代价。在逐个单元的基础上执行存储器测试，所以某些单元可以被排序，而某些可以不被排序。根据单元是否已经被排序而对单元进行标记；该信息在概要报告中并且通过API可得。

不对文件头部对象进行排序。

原型OASIS解析器的限制

假设OASIS文件符合SEMI P39语法和语义。没有错误是被容忍的。仅报告一个错误；解析器不尝试继续通过第一错误。

目前，XELEMEMT、XGEOMETRY和XNAME记录被丢弃，而不被记录(在文件级概要中除外)。

丢弃PAD记录而不进行记录(在文件级概要中除外)。

不测量文件中的名称表所使用的存储器；这可能使得实际存储器使用超过所请求的限制。

元素的特性被记录为与元素本身相同的类型(几何数据)。OASIS中PROPERTY记录的定义显著区别于GDSII中的PROPATTR记录，并且其将没有可能与其中具有带特性(除了可兼容的S_GDS_PROPERTY以外)元素的单元相匹配。

LAYERNAME表(如果有的话)不由OASIS解析器返回，所以仅层编号信息可用于与概要一起使用。

如果零面积多边形的点以“错误”顺序绘制，则不对其进行反转。这可能使得比较包含零面积多边形的GDSII和OASIS文件较困难。

带注解样本OASIS文件

图11是带注解样本OASIS文件。因为OASIS是二进制文件格式，所以使用OASIS记录名称，并且为了简便，对个体元素的某些部分进行缩写。元素内的所有字段具有相同的记录类型，所以未失一般性。

为了规范化，将RECTANGLE、PATH、TRAPEZOID、CTRAPEZOID和CIRCLE元素转换为具有顺时针环绕的等效POLYGON元素。由此，附图中没有示出这些元素类型。选择点列表中的第一点作为最低最左边的点。使用GDSII BOUNDARY记录号，以使得OASIS单元可以与GDSII单元相匹配。

使用GDSII TEXT元素号来记录TEXT元素，以使得仅使用TEXT的OASIS单元可以与GDSII单元相匹配。注意，不存在OASIS到GDSII NODE元素的模拟。

在计算概要之前扩展CBLOCK记录，所以其不会成为规范化单元概要的一部分。规范化单元概要将是相同的，而不管是否存在CBLOCK记录。

在不扩展CBLOCK记录的情况下计算文件级概要。

记录名称和其他字符串，如同它与其所用于的记录一起存在一样，无论名称表是否存在于文件中。名称和其他字符串表本身不被添加至任何规范化单元概要中。与名称记录相关联的特性(例如，CELLNAME)被添加至文件头部非层几何概要中。

所有的几何记录在被发送至概要引擎之前被完全展开；不进行模态变量的隐含使用。这对于排序以及与GDSII文件的匹配是有用的。为此，XYRELATIVE和XYABSOLUTE记录不是任何规范化单元概要的一部分；其仅确定如何(相对于先前对象或者绝对坐标)解释XY坐标。

特性与紧跟在其后的对象被一起记录。如果该对象具有层编号，则其根据该层编号来记录。不对文件前端(并且由此在任何单元以外)的特性进行排序；在其发生时对其进行记录。

在发送至概要引擎之前，将类型17(正交旋转)的PLACEMENT对象转换为类型18(任意旋转)的PLACEMENT对象，以便与GDSII中的定义相匹配。

对于结构接口(例如，边界框、邻接框和布线器接入点)不存在行业标准，所以没有任何结构接口被记录为单元头部数据。

示例6(继续)：GDSII布局文件

GDSII文件是用于指定布局的结构化二进制文件。根据用于编写GDSII文件的工具，数据在单元中出现的顺序可能改变，并且某些构造(尤其是PATH)可以被转换为较无歧义的表示(BOUNDARY)。在内部，为了担保一致的表示，将所有的几何构造都转换为BOUNDARY(多边形)记录，并且将数组引用(AREF)扩展为等效的构造引用(SREF)序列。

在适当时，如果具有足够的存储器或者盘空间可用，则默认对GDSII文件数据进行排序。通过层并且继而通过位置对数据进行分组，以使得无论数据起初在单元内如何排序都生成相同的概要。只要对数据排序，并且单元中不存在GDSII NODE记录或者特性，用户的软件就应当能够在GDSII单元与其等效OASIS表示之间进行匹配。

为了避免浮点舍入错误，基于单元内的布局数据的整数坐标来计算概要。因为用户的优选设计栅格可能随时间改变，所以基于用户使用-grid命令行选项指定的较小栅格来计算规范化单元概要。用户应当细心选择该栅格，以确保所有将来设计栅格是它的整数倍。默认该栅格是1纳米(1.0e-9米)；可以最佳地设置为诸如0.5纳米或者0.25纳米的较小值。然而，如果栅格过小，则用户可能在32比特机器上得到整数算术溢出。

因为展开了所有的AREF(成组结构引用)以确保一致表示，所以针对规范化单元概要计算的运行时性能可能显著改变，即使对于相同大小的文件也是如此。

这里是针对GDSII文件的概要报告的一部分：

Cell ″Structure_1″(sorted)

  a7100492 Cell with Comments

  3d4d7fbf Cell without Comments

  9a5d7b2d Cell Comments

  7b78aab4 Cell Body non-Layer

  15546763 Cell Body Layer 3

  fda35715 Cell Body Layer 42

  aec2e57d Cell Body non-Geometric Data Layer 3

在此示例中，单元小到足以进行排序，并且这在单元名称之后报告。单元修改和访问时间被记录为注释，层3和42上存在记录为非层数据的某些结构引用以及某些几何形状。最后，层3上存在某些非几何数据(一个或多个NODE或者TEXT记录)。

GDSII流式文件：定义

GDSII是早期的布局数据库格式，最初由Calma公司在20世纪80年代制定，并且现在归Cadence所有。原型GDSII解析器遵循具有Y2K附加的Cadence Virtuoso设计数据翻译器参考中描述的规范。

GDSII是二进制格式，所以为了清楚起见，本说明书使用GDSII规范中列出的记录名称。

GDSII文件的语法解释

在缺少行业标准规范的情况下，工具供应商多年来“扩展”了GDSII格式。例如，GDSII文档注意到节点、文本点或者几何对象的最大层编号是255，但是某些工具允许多达32,767个层(最大可能的带符号16比特整数)。类似地，GDSII文档将边界(多边形)和路径(线路)被限制到200个点，但是某些工具允许多达4,094个点(可以适合65,535字节记录的最大点数)。为了支持这些扩展同时仍然提供相同的检查水平，解析器接受“变动”记录，其指定了针对以下的限制：

●结构名称长度(默认32，最大32,750)

●结构名称中允许的附加字符(在“A-Za-z0-9_？$”以外)

●最大层编号、数据类型或者文本类型(默认64，最大32,767)

●最大特性属性数目(默认64，最大32,767)

●最大BOUNDARY或者PATH点计数(默认200，最大4,094)

●最大节点计数(默认50，最大4,094)

●最大特性值长度(默认128，最大32,767)

●AREF中的晶格向量是否可以旋转或者其是否正交并且在第一象限

●AREF中的旋转是否意味着晶格被刚性旋转或者实例按照其指定在晶格内的位置中旋转

除了对这些方面的修改以外，如果GDSII文件不符合规范，则解析器将返回错误。

设计工具具有相当大的自由度来选择用于表示布局单元的几何形状的GDSII元素。虽然布局编辑器通常将保存设计者的选择，例如，PATH与BOUNDARY，但是最终的流式输出可以代替地使用等效的BOUNDARY，以便减少PATH的定义在弯曲处固有的歧义。此类工具也可以将BOUNDARY的“绕线方向(winding direction)”从逆时针改变为顺时针。为了避免这些问题，将所有的几何元素转换为用于规范化单元概要计算的规范化表示：

●将PATH元素转换为等效的BOUNDARY记录

●如果BOUNDARY点列表中的最后一个点与第一个点一致，则将其移除

●如果所产生的多边形具有逆时针绕线方向，则反转BOUNDARY点列表

●选择列表中的第一个点作为最低最左边的点

GDSII文件还与较新的OASIS格式文件共存。OASIS使用描述重复的对象引用的不同方法。为了正规，将AREF(成组结构引用)对象扩展为等效的个体SREF(结构引用)对象序列。在OASIS解析器(重复被展开)中同样如此，从而可以将针对GDSII文件与OASIS文件中布局的概要进行比较。为此，无法担保取决于文件大小的运行时性能—具有扩展为上亿个SREF的AREF的较小文件将需要大量的CPU时间，因为SREF被一次一个地添加到概要中。

GDSII规范要求AREF晶格是正交的并且在第一象限(即，第一晶格向量沿正X轴，而第二晶格向量沿正Y轴)中，继而如果指定了镜像或者旋转，则相应地进行刚性的镜像或者旋转。很少有CAD工具实际使用该定义；相反，晶格向量被旋转和/或镜像，并且实例被放置到转换的晶格中。原型GDSII解析器默认使用该定义；API中存在使用原始定义的选项。

注意，基于GDSII文件中的对象而不是下层的几何形状来计算概要。在计算概要之前不执行重叠移除。

在文件前端，使用例如1纳米(1.0e-9米)的栅格来指定GDSII文件中的坐标。在单元内，所有的坐标按照该栅格来定义，使得其可以是整数。然而，文件栅格可以改变，而不影响最终掩膜数据。例如，虽然标准栅格是1纳米，但是也可以使用5纳米的栅格来指定导入的设计模板块。用户的软件继而将转换所有导入的数据以便使用较小栅格，通过因数5来缩放单元中的整数坐标。

为了确保正规，缩放GDSII文件中的所有几何形状，以使用内部规范化单元概要栅格。用户应当细心选择该栅格，以使得所有将来设计中使用的GDSII文件栅格将是可兼容的。例如，如果目前设计栅格是5纳米，则最佳地使用1纳米或者甚至0.5纳米的规范化单元概要栅格。

将规范化单元概要栅格值传送至GDSII解析器，并且如果GDSII文件栅格不是规范化单元概要栅格值的整数倍，则返回错误。

将具有SREF或者AREF记录的结构标记为层级式的以用于概要报告。

GDSII文件的排序

如所提到的，GDSII文件使用与OASIS文件不同的方法来指定成组结构引用。OASIS文件编写者具有很大的自由度来通过使用重复而对几何对象或者结构引用进行聚类。不同的供应商可能选择不同的重复优化方法。最终，可以在任何时刻重新排列单元内的几何对象，而不改变文件的含义。GDSII布局或者GDSII布局与OASIS布局的有效比较由此需要排序。为此，默认支持GDSII和OASIS布局的排序。

在将几何对象转换为规范化形式之后，可以按照如下将其与另一对象比较以用于排序目的：

●层名称主关键字；较低层编号排在前面

●元素类型(使用GDSII记录类型)是次关键字；较低元素类型排在前面

●元素的XY坐标(如果有的话)是第三关键字；逐个比较坐标，并且针对给定条目，具有最低最左边的点的元素排在前面

●如果存在STRCLASS，则比较转换为整数的比特向量，并且“最低”的一个排在前面

●如果存在ELFLAGS，则比较转换为整数的比特向量，并且“最低”的一个排在前面

●如果存在PRESENTATION，则比较转换为整数的比特向量，并且“最低”的一个排在前面

●如果存在STRANS，则比较转换为整数的比特向量，并且“最低”的一个排在前面

●接下来，比较PLEX值(默认为0)，并且最低的一个排在前面

●接下来，比较DATATYPE值，并且最低的一个排在前面

●接下来，比较PATHTYPE值(如果有的话)，并且最低的一个排在前面

●如果记录具有STRING值，则按字母顺序比较这些值，并且最低的一个排在前面

●如果记录是STRANS(结构变换)，则按字母顺序比较SNAME值，并且最低的一个排在前面

●接下来，比较MAG值(如果有的话)，并且最低的一个排在前面

●接下来，比较ANGLE值(如果有的话)，并且最低的一个排在前面

●最后，逐个比较PROPATTR值

期望将仅使用前三种比较(层名称、元素类型和XY位置)，以使得其他比较的顺序可以或多或少是任意的。

这些排序标准中的一些也用于OASIS文件

使用在OASIS中不具有模拟的GDSII字段(例如，PLEX)或者在OASIS中不同的GDSII字段(例如，特性)将阻止跨格式的单元匹配。

如果请求了排序，则收集单元(GDSII结构)中的记录直到到达单元的结尾或者直到存储器中存储了超过使用限制的单元数据。如果发生上述情况，则将所存储的单元记录按照其原始顺序发送至概要模块。针对单元执行存储器测试，所以某些单元可以被排序，而某些可以不被排序。根据单元是否已经被排序而对单元进行标记；该信息在概要报告中并且通过API可得。

文件头部对象具有指定的顺序，所以其不被排序。

原型GDSII解析器的限制

假设GDSII文件遵循针对GDSII的Cadence规范，除了可以放松某些数字限制以外，如上所述。AREF晶格还可以在旋转方向中指定。除了这些变动之外，不容忍任何例外或者错误。仅报告一个错误；解析器不尝试继续越过第一错误。

目前没有改变来自命令行的行为标志和数字限制的方式。API能够定义针对上述所有项目的变动。

PROPATTR记录在GDSII中具有与OASIS中的PROPERTY记录不同的结构。PROPATTR记录的使用将阻止GDSII单元与OASIS单元的匹配，除非OASISPROPERTY记录使用S_GDS_PROPERTY格式。

如果零面积BOUNDARY和BOX的点以“错误”顺序绘制，则不对其进行反转。这可能使得比较包含零面积多边形的GDSII和OASIS文件较困难。

在BOX记录和BOUNDARY记录不等效的假设下，不将BOX记录转换为BOUNDARY记录；BOX记录不比BOUNDARY记录有效，所以假定其是有意不同地绘制的。

带注解样本GDSII文件

图12是带注解样本GDSII文件。因为GDSII是二进制文件格式，所以使用GDSII记录名称，并且为了简便，对个体元素的某些部分进行缩写。元素内的所有字段具有相同的记录类型，所以未失一般性。

结构的修改和访问时间被记录为单元注释。结构类记录也被记录为单元注释。对于结构接口(例如，边界框、邻接框和布线器接入点)不存在行业标准，所以没有结构接口被记录为单元头部数据。

GDSII中的层是数值的；不返回层名称的列表。

在将PATH元素发送至概要生成之前，使用路径类型以及任何BGNEXTN或者ENDEXTN记录将其转换为BOUNDARY元素。将路径类型1(圆端)转换为路径类型2(超过端点半个宽度的方端)。

如果PATH元素具有锐角，则在等于接线宽度一半处截去任何此类弯曲的转角。PATH的外部以顺时针方向跟踪(trace)；将最低、最左边的点选为第一个。列表中的最后一个点与第一个不一致；相反，存在隐式的边缘。

将负PATH宽度默默地转换为正路径宽度，从而移除其“绝对路径宽度”特性。该转换不记录在概要中。

如果BOUNDARY元素的点列表具有逆时针环绕，则将其反转；之后，将最低、最左边的点选为第一个。根据GDSII规范与第一个点重叠的最后的点被移除，以使得存在隐式边缘。

如果BOX元素的点列表具有逆时针环绕，则将其反转；之后，将最低、最左边的点选为第一个。根据GDSII规范与第一个点重叠的最后的点被移除，以使得存在隐式边缘。在假设BOX元素旨在用于不同目的时，不将BOX元素转换为BOUNDARY元素。

在将数组引用(AREF元素)发送至概要生成之前，将其扩展为等效的SREF元素列表。

将元素的属性记录为与元素本身相同的类型(几何数据)。还有可能将其记录为非几何数据，因为OASIS中的属性定义显著不同，并且其否则将无法匹配其中具有带属性元素的单元。

在将GDSII记录中的比特数组(例如，STRANS)发送至概要计算之前，将其转换为整数。

示例7：非结构化文本文件类型

非结构化文本文件是不具有规范化单元概要工具已知的规范的文本文件。例如，设计模板块的人类可读描述或者日志文件将是非结构化文本文件。然而，文本文件是面向行的，所以其仍然可以进行排序。如果请求了排序，则文件头部数据概要将改变以反映排序。否则其将匹配文件概要。

在此示例中，非结构化文本文件具有针对文件逐个字节的内容概要。针对非结构化文本文件计算逐个字节概要。该概要独立于换行样式。作为一个选项，忽略空白的差异。

命令行选项-mergewhite、-reportwhite和-discardwhite控制针对基于文本文件格式的文件级空白概要的报告。空白包括空格、制表符和换行符。-mergewhite选项是默认的；当其活跃时，报告单个文件级概要，包括空白和非空白二者。当-reportwhite选项活跃时，单独报告针对空白和非空白的概要。当-discardwhite选项活跃时，忽略空白，并且报告排除空白的单个文件级概要。

例如，如果将样本文件testfiles/verilog_test.v视为非结构化文本文件，则将获得以下结果：

otismartsig -txt -mergewhite testfiles/verilog_test.v

File ″testfiles/verilog_test.v″：unstructured text format

  File CRC 5404c699

otismartsig -txt -reportwhite testfiles/verilog_test.v

File ″testfiles/verilog_test.v″：unstructured text format

  File CRC 5404c699

  File non-whitespace CRC 7c2a352d

  File whitespace CRC 219b1881

otismartsig -txt -discardwhite testfiles/verilog_test.v

File ″testfiles/verilog_test.v″：unstructured text format

  File CRC 7c2a352d

注意，第一示例中合并的文件概要与第二示例中的完全文件概要相匹配，并且第二示例中的非空白概要与第三示例中的文件概要相匹配。

不针对基于单元的格式(诸如Liberty或者Verilog)中的个体单元计算空白和非空白概要；其仅在文件级计算。

三种空白报告选项也可以用于结构化文本文件格式。例如：

otismartsig -discardwhite -ver testfiles/verilog_test2.v

File ″testfiles/verilog_test2.v″：Verilog format

  File CRC 07f87fb9

  File header CRC 6ef229e6

  File comment CRC 6ef229e6

Cell ″OAI21_X1″

  Interface CRC dae46517

  Contents CRC c73aceaf

Cell ″OAI21_X2″

  Interface CRC 01391569

  Contents CRC c73aceaf

语法解释

针对非结构化文本文件计算文件级(所有文件数据、非空白数据和空白数据)以及文件头部概要。针对文件中的所有数据计算文件头部概要，如果请求则按字母对行进行排序。如果文件具有DOS样式(CR-LF)行结尾，则在计算任何概要之前将其转换为UNIX样式(仅LF)行结尾。

非结构化文本文件的排序

如果请求了排序，并且存储器使用限制足够高，则在计算文件头部概要之前对文件的行进行排序。将所有数据记录为非层、非注释文件头部数据。

原型非结构化文本文件解析器的限制

目前，不存在将空白转换为规范化形式(例如，将制表符转换为空格或者移除重复的空格)的选项。

示例8：非结构化和结构化二进制文件

针对非结构化二进制文件(或者没有解析器的结构化二进制文件)的概要仅仅是没有解释的序列中的所有字节的CRC。针对示例GDSII文件testfiles/sigtest.gds的概要可以计算如下：

otismartsig -bin testfiles/sigtest.gds

File testfiles/sigtest.gds：unstructured binary format

  File CRC d0b40760

这是与由GDSII解析器计算的文件级概要相同的概要。

非结构化二进制文件

非结构化二进制文件是不具有规范化单元概要工具已知的规范的非文本文件。例如，对象代码或者可执行程序将是非结构化文件。因为这些文件没有已知的结构，所以无法针对其计算规范化单元概要。仅计算文件概要。不存在语法解释或者非结构化二进制文件的排序。

示例9：SPICE格式网表文件类型

通常使用20世纪70年代在加利福尼亚大学伯克利校区开发的以集成电路为重心的仿真程序(通常称为SPICE)来分析晶体管级设计。SPICE及其衍生品仍然是用于集成电路的优质标准数值解法，但是容量和运行时问题将其使用限于子电路(几十个到上百个晶体管，加上关联的寄生电路元件)而非整个设计。SPICE输入文件是文本，并且可以由设计者创建，但是通常由从GDSII或者OASIS读取布局的电路提取者来编写。通常，将读取这些文件的SPICE仿真继而用于生成针对Liberty格式文件的定时模型。

在此示例中，SPICE格式网表文件具有针对以下文件元素的内容概要：

●文件

●文件头部

●针对子电路的端口定义

●子电路的主体

扫描该文件以找到内部的子电路名称。对于子电路，针对子电路的端口定义和主体而计算独立的概要。这些以排除任何空白或者注释的个体SPICE网表记号为基础。

将针对文件的头部以及针对文件的概要作为一个整体来计算和返回。这些包括任何空白和注释。

不解释包含文件指令，因为概要计算时的包含文件引用可能与仿真时不同(例如，如果路径名称是相对的)。

SPICE子电路文件

通常将所提取的布局写入到SPICE输入文件内的子电路中，并且由规范化单元概要软件将这些记录为单元。子电路内的文本是顺序无关的，并且可以进行排序，但是其可能不使用顺序无关参量规范来实例化，所以在排序之后找到的概要匹配可能不表示真正等效。由此，应当谨慎进行SPICE子电路文件的排序。默认不对SPICE子电路文件排序，除非用户指定了-sort标志。

SPICE子电路文件中不存在层，所以将所有针对单元的概要报告为非层数据：

File ″testfiles/test1.spi″：Spice format

Arguments：-mem 64 -nosort

  e4c0e613 File

  7a041fe8 File non-Whitespace

  07415f83 File Whitespace

File Header(not sorted)

  c8954a7d File Header with Comments

  fa8f8413 File Header without Comments

  321ace6e File Header Comments

  fa8f8413 File Header non-Layer

Cell ″nand2″(not sorted)

  59fa7f10 Cell with Comments

  bdda89ec Cell without Comments

  e420f6fc Cell Comments

  5f4226ed Cell Interface non-Layer

  e298af01 Cell Body non-Layer

语法解释

不存在标准的SPICE格式，因为变量具有其自己的指令(尤其是器件模型参数)，但是所有程序使用相同的面向行的网表结构，在该网表结构中，子电路(单元)开始于.subckt，结束于.ends。原型规范化单元概要SPICE解析器针对子电路创建单元，并且将所有其他文本记录为文件头部的一部分。

注释以‘*’开始，并且继续到目前行的结尾。‘*’前面可以具有空白；这被移除。记录‘*’之后的任何空白而不进行进一步处理。子电路内的注释行被添加到单元主体概要中。

如果任一行的下一行在第一栏中开始于‘+’，则可以将该行继续到下一行。在将行合并到一起之前移除‘+’，以使得以下两个行序列是等效的：

.subckt a b c

以及

 .subckt

+a

+b

+c

当合并连续行时不添加空格，所以下面两个行序列是等效的：

.subckt a b c

以及

.sub

+ckt a b c

在将非注释行发送至概要引擎之前，将该行中多个空白字符的序列转换为单个空格字符。

假设点命令名称(例如，.subckt)是不区分大小写的。在记录单元名称之前将其转换为小写，但是否则将在没有大小写转换的情况下记录文本。

将.global行上指定的网记录为单元接口中的管脚。

在.options和.param行将影响单元的假设下，将其添加到单元的主体中。

将.end语句之后的行记录为文件头部数据，而不进行任何解释。.end命令认为是可选的；如果漏掉了它，将不会打印错误。

将.global、.param、.subckt、.ends和.end之外的点命令记录为文件头部数据而不进行解释。

将具有‘X’(子电路实例化)的任何子电路标记为层级式的。

SPICE网表文件的排序

因为SPICE子电路网表仅指定了连通性，所以其可以按照任意顺序。如果请求了排序，则按照字母顺序排序文件头部以及子电路中的行。在执行排序之前移除行中重复的空格。

还将对用于子电路的管脚名称进行排序，即使连接是位置的(顺序相关)，所以应当谨慎使用排序的结果。

原型SPICE网表解析器的限制

解析器假设：SPICE子电路都不会大到超出存储器的使用限制。还假设：具有足够的空间来存储任何子电路以外的所有行，以使得其可以存储和记录在文件的尾部。

不处理.include语句，因为文件搜索路径对于解析器不是已知的，并且无论如何可能随时间改变。

来自.param行的参数不被代替。由此以下两个文本块是不等效的：

.param lp＝0.35

mpullup zn i vdd vdd pmos w＝10.0 l＝lp

以及

mpullup zn i vdd vdd pmos w＝10.0 l＝0.35

记录.param和.options行而不进行进一步解释。由此以下两个序列是不等效的：

.param lp＝0.35 ln＝0.3 wp＝0.7 wn＝0.7

以及

.param lp＝0.35 ln＝0.3

.param wp＝0.7 wn＝0.7

带注解样本SPICE网表文件

图13是示出以上解析规则的SPICE文件的带注解版本。

示例10-11：LEF/DEF文件类型

库交换格式(LEF)文件提供了用于描述来自GDSII或者OASIS文件的布线层设计规则以及物理布局以便在布局和布线(P&R)工具中使用的方式。它提供了要进行布局和布线的单元的面向布线器的接线以及通孔构造规则加抽象。在与设计交换格式(DEF)文件相耦合的情况下，库交换格式(LEF)文件提供了用于完整集成电路的布局和布线的规范。

在这些示例中，LEF/DEF文件具有针对以下文件元素的内容概要：

●文件

●文件头部

●头部注释文本

●单元注释文本

●逐层几何对象

●逐层非几何对象

●所有其他对象：单元大小、站点(site)类型等

●涉及其他较低层单元的布尔标志

扫描数据库以找到内部的单元名称。对于存在的单元，返回针对以下全部的逐层概要：

1.几何对象，诸如多边形、矩形等；以及

2.非几何对象，诸如文本点等。

为所有其他对象(诸如单元大小、站点类型和对称性信息)指派概要。将针对文件的头部(任何单元定义之外的信息)以及针对文件的概要作为一个整体来计算和返回。

作为一个选项，针对头部中的注释文本和单元内部的注释文本计算独立的概要，并且忽略空白(空格、制表符与空格以及空行的数目)的差异。

库交换格式(LEF)文件

LEF文件是面向文本的，但是其通常由自动化工具而不是设计者编写。处理技术的描述(即，设计规则)通常存储在LEF文件中，而单元信息在存储于另一文件内的宏中指定。技术信息被存储为文件头部数据，而宏被记录为单元。宏中几乎所有的信息都指定该宏与布局和布线工具的接口，所以其被记录为单元接口数据。仅是宏的特性(如果有的话)被记录为单元主体数据。

类似于GDSII和OASIS，LEF文件中的很多数据是顺序无关的，所以默认地对其进行排序，除非用户指定了-nosort标志。在适合时排序文件头部中的信息，如同宏内的数据一样。

注意，LEF文件通过名称指定层，而不是像GDSII和OASIS文件一样通过编号指定：

File ″testfiles/parsetest.lef″：LEF format

Arguments：-mem 64 -sort

  c5eb5fff File

  1c18cc01 File non-Whitespace

  eb7f52d1 File Whitespace

File Header(sorted)

  30dbab35 File Header with Comments

  25a292d4 File Header without Comments

  157939e1 File Header Comments

  b450539c File Header non-Layer

  316de219 File Header Layer M1

  a8fd3343 File Header Layer V1

  ff7eda09 File Header Layer M2

  1b691e80 File Header Layer V2

  ec75d49b File Header Layer M3

Cell ″AND2_X1″(sorted)

  1ed769e0 Cell with Comments

  1ed769e0 Cell without Comments

  (none)   Cell Comments

  818dbac9 Cell Interface non-Layer

  cbeea19a Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

库交换格式文件：定义

原型LEF解析器使用Cadence LEF/DEF语言参考手册版本5.6(2004年9月)中的LEF数据文件格式的定义。该文档具有一些歧义和打字错误；这些以与同该手册一起提供的参考解析器相同的方式解决。

语法解释

LEF中的单元描述称为宏；宏内的所有信息(诸如阻塞(blockage)和管脚信息)被记录为单元接口的部分。阻塞(blockage)是布线器在单元上布线时避免的区域。管脚标记布线器绘制接线以连接到单元的位置。

将技术LEF文件中的设计规则信息记录为文件头部的一部分。

通过名称来索引LEF文件中的层，所以解析器创建字符串层名称表，并且将该表内的索引指派为层名称。该表通过API可得。

将行截断为每个LEF规范2,048个字符。

在文件头部中记录SITE语句；其本身不形成单元。

将MACRO块中除特性以外的所有东西记录为单元接口文本，因为LEF文件打算指定与布局和布线工具的单元接口。

以不区分大小写的方式对LEF关键词进行匹配。LEF 5.6规范关于这个问题无记载，但是&ALIAS和&ENDALIAS是例外，其是明确不区分大小写的。目前，规范化单元概要基于关键词的原始大小写。即使NAMESCASESENSITIVE被设置为OFF，其也将应用于层、宏和管脚名称。然而，这很容易改变。

LEF文件的排序

通常，LEF文件中的对象可以按照任何顺序出现，两个例外如下：

●对象引用出现在其定义之后

●PATH的宽度由最近的WIDTH语句确定

在个体对象内，某些信息是顺序无关的，而某些(例如，PATH点或者ITERATE值)是顺序相关的。解析器将顺序无关字段与顺序相关字段分离，以担保经排序的数据仍然有效。

当请求了文件排序时，首先基于语句名称并且其次基于语句参数，按照字母顺序排列文件头部中以及宏内的语句。也排序语句内的顺序无关字段。为了确保正规，在排序之前，将应用于给定PATH的WIDTH添加到该PATH记录中。

原型LEF解析器的限制

LEF解析器的很多限制都起因于它正在解析单个文件这一事实，而使用LEF文件的工具可以依次加载多个LEF文件。来自较早LEF文件的值可以在较晚的LEF文件中使用。在缺少对那些其他文件的访问的情况下，LEF解析器依赖于向其传递的值。

不解释NAMESCASESENSITIVE、BUSBITCHARS和DIVIDERCHAR语句。解析器从顶层驱动器(尚未具有从命令行对其进行设置的能力，所以使用默认值)得到间隔字符。如果解析器将要依赖于从目前文件获取的值，则当加载多个LEF文件时，其可能得到与布局和布线工具不同的结果。

假设，即使对ALIAS名称的引用被视为标识符，也对文件进行语法纠正。ALIAS语句本身可能在另一文件中，并且可能包括任意数量的语法，使得文件无法独立解析。

LEF文件的排序是按照字母顺序的，而不是数字顺序，所以规范化单元概要目前依赖于LEF生成软件继续使用与之前相同的数字格式。

解析器不进行确保技术LEF文件(包含设计规则)与单元库LEF文件(包含宏描述)分离的检查。

对先前定义的SITE块的SITE块引用不进行确保其存在的检查；较老的SITE块可能在另一文件中，并且一次仅解析一个文件。假设对SITE对象的改变将不改变引用它们的MACRO对象。

假设技术信息和其他文件头部数据将不会超过存储器使用限制，并且单个MACRO都将超过存储器使用限制。

带注解样本LEF文件

图14是示出以上解析规则的应用的带注解样本LEF文件。

示例11(继续)：设计交换格式(DEF)文件

设计交换格式(DEF)文件提供了用于描述设计布图规划和网表以便在布局和布线(P&R)工具中使用的方式。在与库交换格式(LEF)文件相耦合的情况下，DEF文件提供用于完整集成电路的布局和布线的规范。

DEF文件是面向文本的，并且可以由自动化工具或者设计者来编写。高层设计信息(诸如管芯面积和区域规范)可以手动创建，并且详细的阻塞信息和预先布线网通常由软件编写。因为DEF文件可能不包括布局区域，并且其可能不与设计层级相关，所以将DEF文件中的所有数据记录在文件头部概要中。

类似于GDSII和OASIS，DEF文件中的很多数据是顺序无关的，所以默认地对其进行排序，除非用户指定了-nosort标志。

注意，DEF文件通过名称来指定层，而不是类似于GDSII和OASIS文件通过编号来指定：

File ″testfiles/simple.def″：DEF format

Arguments：-mem 64 -sort

  a832fb91 File

  807bad9c File non-Whitespace

  280fe544 File Whitespace

File Header(sorted)

  b8d02902 File Header with Comments

  c6810a4d File Header without Comments

  7e51234f File Header Comments

  6d026f6f File Header non-Layer

  1d4870e4 File Header Layer m1

  74aecb62 File Header Layer v1

  feafad9c File Header Layer m2

  6a00eeb9 File Header Layer v2

  eeb61028 File Header Layer m3

设计交换格式文件：定义

原型DEF解析器使用Cadence LEF/DEF语言参考手册版本5.6(2004年9月)中的DEF数据文件格式。该文档具有一些歧义和打字错误；这些以与同该手册一起提供的参考解析器相同的方式来解决。

语法解释

DEF文件将设计(或者设计的块)描述为没有真实层级的平面实体。区域分组即使使用也不反应设计层级。因此，将所有的DEF数据记录为文件头部的一部分。

DEF文件中的层通过名称来索引，所以解析器创建字符串层名称表，并且将该表内的索引指派为层编号。该表通过API可得。

将行截断为每个DEF规范2,048个字符。

以不区分大小写的方式匹配DEF关键词。LEF 5.6规范关于这个问题无记载，但是&ALIAS和&ENDALIAS是例外，其是明确不区分大小写的。规范化单元概要基于关键词的原始大小写。

为了减小DEF文件大小，可以将(例如，BLOCKAGE语句内的POLYGON中的)复用系数表示为星号(’*’)。解析器目前不将星号扩展为其表示的数字，因为任何此类值在理论上可以是&ALIAS替换，并且由此不管怎样都不是数值记号。

DEF文件的排序

DEF文件中的多数对象可以按照任何顺序出现，除了对象引用在其定义之后。在个体对象内，某些信息是顺序无关的，而某些(例如，POLYGON点)是顺序相关的。解析器将顺序无关字段与顺序相关字段分离，以确保经排序的数据仍然有效。例如，在BLOCKAGE语句中，在排序时，使针对层的阻塞保持在一起。然而，可以对层内的对象进行排序。

当请求了文件排序时，首先基于语句名称其次基于语句参数，按照字母顺序来排列文件中的语句。也对语句内的顺序无关字段进行排序。

原型DEF解析器的限制

DEF解析器的很多限制都起因于它正在解析单个文件这一事实，而使用DEF文件的工具可以依次加载多个DEF文件。来自较早DEF文件的值可以在较晚的DEF文件中使用。在缺少对那些其他文件的访问的情况下，DEF解析器依赖于向其传递的值。

假设即使将对&ALIAS名称的引用视为标识符，也对文件进行语法纠正。&ALIAS语句本身可能在另一文件中，并且可能包括任意数量的语法，使得文件无法独立解析。

不将BLOCKAGES、COMPONENTS、FILLS、GROUPS、NETS、NONDEEAULTRULES、PINS、PINPROPERTIES、PROPERTYDEEINITIONS、REGIONS、SCANCHAINS、SLOTS、SPECIALNETS、STYLES和VIAS部分中的计数与这些部分内的项目的实际数目进行验证。

不解释NAMESCASESENSITIVE、BUSBITCHARS和DIVIDERCHAR语句。解析器从顶层驱动器(尚未具有从命令行对其进行设置的能力，所以使用默认值)得到间隔字符。如果解析器将要依赖于从目前文件获取的值，则当加载多个DEF文件时，其可能得到与布局和布线工具不同的结果。

假设UNITS命令或者不存在或者并非总是相同；目前不通过设计单位值来缩放文件中的系数。

目前不将数据点系数中的星号扩展为数字。

当确定是否超过存储器使用限制时，并不总是对注释所使用的存储器进行计数。

带注解样本DEF文件

图15是示出这些规则的应用的DEF文件的带注解版本。

没有示出所有可能的语句，因为无论如何都将除注释以外的所有语句都发送至文件头部概要。

以下DEF对象类型是可排序的：

●PROPERTYDEFINITIONS部分内的对象

●ROW定义

●TRACKS定义

●VIAS定义；通孔的层内的RECT和POLYGON对象

●STYLES定义(但不是类型内的多边形点)

●NONDEFAULTRULES部分内的对象(但不是规则内的参数)

●REGIONS部分内的对象(单不是区域内的参数)

●BLOCKAGE定义内的层；层内的RECT和POLYGON对象

●BLOCKAGE定义内的PLACEMENT对象；PLACEMENT对象内的RECT和POLYGON对象

●SLOTS部分内的层；层内的RECT和POLYGON对象

●FILLS部分内的层；层内的RECT和POLYGON对象

●COMPONENTS部分内的对象(但不是组件内的参数)

●PINS部分内的对象(但不是管脚内的参数)

●NETS或者SPECIALNETS部分中的网(但不是网内的参数或者连接)

●SCANCHAINS部分中的网(但不是网内的参数或者连接)

●GROUPS部分内的对象

示例12：结构化文本文件类型

在此示例中，结构化文本文件具有针对以下文件元素的内容概要：

●文件

●文件头部

●注释文本

●非注释文本

针对脚本文件和其他结构化文本文件计算逐个字节概要。概要与换行样式无关。作为一个选项，忽略空白的差异。可以传送可选的注释标记符；如果其存在，则针对注释和非注释文本计算独立的概要。可以传送可选的行继续字符；如果其存在，则在概要计算之前合并具有该字符的行结尾。

结构化文本(脚本)文件

结构化文本文件是面向行的人类可读文件，具有可标识注释以及可能的继续字符，该继续字符表示随后的行在逻辑上是目前行的一部分。Shell、Perl和Python脚本是结构化文本文件的规范化实例。

将结构化文本文件中的所有数据记录为文件头部数据，其是文件头部注释或者文件头部非层数据。移除开头的空白，并且将重复的空白字符合并为单个空格。注释开始于用户指定的注释字符序列(例如，‘#’)，并且继续到行的结尾。如果某行结束于用户指定的继续字符(例如，‘\’)，则将其与下一行合并；移除继续字符和行字符的结尾。

结构化文本文件可能具有括在单引号或者双引号内的字符串常量。在字符串常量内，引号字符如果避开了‘\’则可以出现。不合并引证字符串内的空白。

语法解释

将结构化文本文件中的所有数据记录为文件头部数据，其是文件头部注释或者文件头部非层数据。

为了正规，将行中重复的空白字符合并为单个空格字符。默认地，从行中移除所有开头的空白(缩进)。因为在某些语言(例如Python)中，缩进是重要的；所以存在标志来将开头的空白维持原样。即使设置了该标志，也仍然将行中其他地方的重复空白字符合并为单个空格字符。

仅在文件级概要中记录空行(仅是没有其他字符的行结尾)；不将其记录在文件头部概要中。

如果文件具有DOS样式的行结尾(CR-LF)，则在计算任何概要之前将其转换为UNIX样式的行结尾(仅LF)。

字符串常量不管是否用单引号或者双引号引用，都视为单个字；将其按照原样记录，而不进行解释或者空白合并。反斜线字符(‘\’)可以用于避免字符串常量内的引号：

″This is a string constant with \″an embedded quote in it″

将反斜线字符和封闭引号记录为字符串常量的一部分。

在进行任何其他行处理(包括字符串常量的标识)之前，将以用户指定的继续字符(‘\’)结束的行与下一行合并。继续字符是之后不跟空白的行的结尾之前的最后一个字符。在合并两行时，将其与行结尾字符移除。可以按照这种方式合并一排(row)中任意数目的行。

注释开始于用户指定的字符序列(例如，‘#’或者“--”)，并且继续到行的结尾。注释字符可以在行内的任何地方。字符串常量内的注释字符不开始注释。在注释处理之前执行继续字符处理，所以如果继续字符出现在注释行的结尾，则将之后的行也记录为注释的一部分。由此，以下两个文本块是等效的，并且被记录为单个注释行：

# this is a multi-\

line comment

以及

# this is a multi-line comment

无法将继续字符放到引号中；如果行中的最后一个字符是继续字符，则将该行与下一行合并，即使其之前例如是‘\’，或者内部是字符串常量。

结构化文本文件的排序

结构化文本文件通常是顺序相关的，所以无法对其进行排序。

原型结构化文本文件解析器的限制

目前，没有方式使用命令行接口来阻止对开头空白的移除。API具有这种能力。

目前，没有方式使用命令行接口来指定注释字符序列。API具有这种能力。

目前，没有方式使用命令行接口来指定继续字符。API具有这种能力。

没有方式在字符串内指定引号字符；其被固定为‘\’。

带注解样本结构化文本文件

图16是结构化文本文件的带注解版本。

在此示例中，不保留开头的空白。如果保留了开头的空白，则第五行前端的所有空格都已经被记录为文件头部文本。

示例13：由外部工具解析的文件类型

对于由外部工具解析的文件类型，至少提供针对以下文件元素的内容概要：

●文件

●文件头部文本

●单元名称

●接口对象名称、标志等

●注释文本

●单元主体文本。

可以使用与规范化概要生成过程兼容的任何外部解析器工具。在一个实施方式中，外部文件解析器向概要计算代码返回使用如下面向行的语法的文件：

HEADERTEXT<header text>

CELL<cell name>

INTERFACE<interface object name><interface flag>...

COMMENT<comment text>

CELLTEXT<cell body text>

每个文件可以存在不止一个HEADERTEXT记录。每个文件可以存在不止一个CELL。每个单元可以存在不止一个INTERFACE记录。

将行的文本添加到适合的文件或者单元概要。将CELL记录之后的注释行添加到针对该单元的概要。

用户解析的文本文件

可能存在这样的专有数据文件格式，用户想要记录针对该专有数据文件格式的规范化单元概要。如果这样，则用户可以编写针对这些格式的解析器，并且将内部的数据翻译为用户解析的文本文件格式，如下所示：

HEADERTEXT header_text

HEADERTEXT(layer)header_text

CELL cell_name

INTERFACE interface_object_name interface_object_text

INTERFACE(layer)interface_object_name interface_object_text

HIERCELL

CELLTEXT cell_body_text

CELLTEXT(layer)cell_body_text

CELLNONGEOM cell_body_text

CELLNONGEOM(layer)cell_body_text

COMMENT comment_text

这是一个简单的面向行的语法，其提供了对所有规范化单元概要类型的完全访问。通常，文件头部数据由HEADERTEXT行来指示，单元的开始由CELL行来指示，单元接口记录由INTERFACE行来指示，单元主体记录由CELLTEXT或者CELLNONGEOM行来指示，而注释由COMMENT行来指示。HIERCELL行指示层级式单元，即可以包含对其他较低层单元的引用的单元。单元内的数据继续到下一CELL或者HEADERTEXT行或者文件的结尾。所有的文件头部、单元接口和单元主体数据可以具有指定的层名称或者编号。如果指定了-sort选项，则可以对数据进行排序(通过层分组，继而在层内按照字母顺序)。针对其计算概要的文本可以具有对用户有意义的任何格式。

因为语法是面向文本和面向行的，所以无法将具有该格式的文件的概要与来自任何其他文件格式的概要进行比较。使用二进制数据来计算二进制文件概要，并且计算针对文本文件的解析器首先将行分为记号。

用户解析的文本文件：定义

该格式被提供以用于解析专有格式文件。用户将编写读取文件格式并且生成这种简单格式的文件、继而将生成的文件传送至规范化单元概要工具的解析器。解析器转而将计算全部范围的概要。

用户解析的文件格式的描述由到低层概要引擎的应用程序接口(API)实现。可以将所有文件格式的解释描述为对该API的一系列调用，所以该格式的理解将帮助读者理解如何解释其他格式。

在比以上实施方式更加复杂的第二实施方式中，用户解析的文件格式也是面向行的格式。记录出现在开始于诸如HEADERTEXT、COMMENT、CELL、INTERFACE、HIERCELL和CELLTEXT的关键词的单个行中。HEADERTEXT、INTERFACE和CELLTEXT行可以可选地在紧跟关键词的圆括号内具有层名称。继而在改层名称上记录关于行的其余部分的记录。如果没有提供层名称，则使用针对非层数据的数值层编号-1。

期望这些文件将仅通过计算机软件生成，所以可以使用严格的格式：

●所有关键词大写

●关于行的关键词之前没有任何关于行的字符

●如果没有指定层名称，则在关键词之后跟随单个空格，即使要进行记录的文本是空的

如果指定了层名称，则将其放在紧跟关键词的圆括号中，之间没有空格。将括号之间的文本(包括任何空白)存储为层名称而不进行解释。因此，层名称可能不包括闭括号。在闭括号之后存在空格字符。

将第一空格之后的所有东西记录为指定类型的文本，而不进行进一步的解释。

在记录任何概要之前移除换行序列(Windows上的CR-LF、Unix/Linux上的LF)，以避免所生成的概要中的系统依赖性。

关于任何行的长度不存在限制。行开始于关键词；空行是非法的。

用户解析的文本文件的语法

行的格式如下：

HEADERTEXT header_text

HEADERTEXT(layer)header_text

HEADERTEXT行指定任何单元之外的数据。如果单元是开放的(见下文)，则终止该单元，并且不能提供其他单元文本，直到开始新的单元。将所有的头部数据保存为单个块，无论其是否处于文件的开始、单元之间或者在最后一个单元之后。如果将要对头部文本进行排序，则将其全部保持在存储器中直到文件的结尾(受制于存储器使用限制)，继而将其作为单位排序。

空格字符跟随HEADERTEXT关键词；将该空格之后到行结尾的所有都记录为文件头部文本。不执行进一步的空白移除，并且不执行进一步的解释或者大写/小写转换。

CELL cell_name

CELL行指定了新单元的开始。如果单元已经是开放的，则将其终止，并且计算针对其的所有概要。空格字符跟随CELL关键词；该空格之后到行结尾的所有都被用作单元名称，包括任何空白。不对单元名称执行解释或者大写/小写转换。不允许重复的单元名称；如果可能存在专有格式的重复名称，则在解析器中针对该格式对其消除歧义。如果发现了重复的单元名称，则将发生致命错误。

INTERFACE interface_object_name interface_object_text

INTERFACE(layer)interface_object_name interface_object_text

INTERFACE行指定了针对单元的接口记录。存在针对接口记录的单独名称，否则不解释该行上的数据。可以存在多个接口记录使用相同的接口名称。接口名称(例如，针对单元的管脚名称)是INTERFACE关键词或者层名称之后的第一个空白定界的字。继而跳过接口名称之后的任何空白，并且将该行上保留的任何文本(如果有的话)记录为接口对象文本。不对接口名称或者接口对象文本执行大写/小写转换，并且不对接口对象文本执行空白移除。将接口名称和接口对象文本都记录为单元接口数据。

如果在单元之外(在第一CELL语句之前或者在HEADERTEXT语句与下一CELL语句之间)发现INTERFACE行，则将发生致命错误。

HIERCELL

HIERCELL标记单元是层级式的，意味着其包含对其他单元的引用。该信息可用于概要报告。该行不存在参数。

CELLTEXT cell_body_text

CELLTEXT(layer)cell_body_text

CELLTEXT行指定单元主体文本。将跟随CELLTEXT关键词的空格或者层名称的闭括号之后的所有都记录为单元主体文本，而不进行进一步的解释或者大写/小写转换。也不执行空白移除。

如果在单元之外(在第一CELL语句之前或者在HEADERTEXT语句与下一CELL语句之间)发现CELLTEXT行，则将发生致命错误。

CELLNONGEOM cell_body_text

CELLNONGEOM(layer)cell_body_text

CELLNONGEOM行指定非几何单元主体文本。将跟随CELLNONGEOM关键词的空格或者层名称的闭括号之后的所有记录为单元非几何主体文本，而不进行进一步解释或者大写/小写转换。也不执行空白移除。

如果在单元之外(在第一CELL语句之前或者在HEADERTEXT语句与下一CELL语句之间)发现CELLNONGEOM行，则将发生致命错误。

COMMENT comment_text

COMMENT行指定注释文本。将跟随COMMENT关键词的空格之后的所有都记录为单元或者文件头部注释文本(取决于上下文)，而不进行进一步解释、空白移除或者大写/小写转换。

用户解析的文本文件的排序

如果请求了排序，则收集针对头部的文本，直到到达文件的结尾(即使文件中存在单元)或者直到在存储器中存储了超过使用限制的头部文本。如果超过了使用限制，则将所存储的头部文本按照其原始顺序发送至概要模块。类似地，收集针对单元的文本，直到到达单元的结尾或者直到在存储器中存储了超过使用限制的头部和单元文本。如果提供了足够的存储器或者向盘提供缓冲存储器，这应当很少发生。

头部文本优先于单元文本保持在存储器中。前提是如果文件中存在单元，则单元是最可能溢出存储器限制的单位，所以释放头部文本的帮助不大。

对于头部文本，主排序关键字是层编号：较低的层编号(层名称表中的索引)排在前面。在给定层内，使用行的文本(排除关键词和层名称)按字母顺序对行进行排序。

在单元内，主排序关键字是行类型：接口文本排在单元主体文本之前，并且单元非几何主体文本排在最后。层编号是次关键字：较低的层编号排在前面。在给定层内，使用行的文本(排除关键词和层名称)按照字母顺序对行进行排序。

带注解的样本用户解析的文件

图17A-图17B是用户解析的文件的带注解示例。图17A中的层名称是lay1、lay2、lay3和lay4。分别将这些记录为层0到层3，并且将使映射表可用。将没有层的文件头部、单元接口、单元主体和单元非几何主体行记录在层-1上，针对层-1不定义层名称。对于该格式，层-1的定义由用户的应用确定。

单元cell2是层级式的，并且具有称为h3、i1、i2和i3的接口对象(例如，管脚)。单元cell1具有称为j1和j2的接口对象。

如果没有排序文件，则按照以上所示的出现的顺序记录概要。如果排序了文件，则将如图17B所示记录规范化单元概要。

注意，接口行的排序基于行在分为接口名称和接口文本之前的剩余部分。由此单元cell2的接口h3在接口i1之前记录，即使按照字母顺序i1的接口文本在h3之前。类似地，头部文本的第一行将最后记录，因为其具有层索引0，而其他头部行具有层索引-1。

还要注意，当单元cell1开始时，单元cell2结束，并且当头部文本开始时，单元cell1结束。

当排序被启用时，文件级概要将不会改变。HIERCELL记录不会影响排序或者包含其的单元的规范化单元概要；其简单地在单元数据结构中设置标志。

用户解析的文本文件格式的限制

用户解析的文件格式是ASCII，所以其无法编写将具有与二进制OASIS和GDSII格式文件相同的概要的用户解析的文件。在用户解析的文件中处理记号的方式也不同于在其他结构化文本文件格式中处理记号。为了将来自使用专有、内部数据格式的文件的概要与来自另一格式的概要相匹配，用户可以首先将内部数据格式文件翻译为所支持的格式，或者编写针对该内部格式的定制解析器。

比较规范化概要的工作示例

使用原型命令行工具，三种比较模式是可用的。文件比较模式比较针对两个不同版本的设计文件(诸如OASIS或者GDSII)的概要文件，并且报告有意义的差异。版本检查模式将针对设计文件的概要与针对库文件集合计算的概要进行比较，并且报告最近的匹配(如果有的话)。数据库检查模式将设计文件中的单元与包含新的/未测试的单元、生产单元、被否决/陈旧的单元以及已知不良单元的概要的库进行匹配。

文件比较模式

在文件比较模式中，将针对两个设计文件的概要进行比较，并且报告任何差异。其标记任何不匹配的单元，并且打印针对具有不同概要的单元连同有区别的层(在可应用时)和单元结构(例如，接口，当可应用时)的报告。当想要确保仅对已经在产的设计进行经授权的改变时，该模式是有用的。例如，设计者可能改变了单个单元中的一个层；附加改变的任何报告将代表错误。

用于使用原型命令行工具来运行文件比较的语法是：

sigcompare -compare[-showall]file1 file2

第一参数-compare指定文件比较模式。默认地，仅报告有区别的单元；可选的-showall标志指定报告了所有单元，包括相同单元。

通过名称对单元进行匹配，不尝试在不同的名称下查找拷贝。

文件比较示例

考虑一下库交换格式(LEF)概要文件对：

File ″lib_45nm_v1_0.lef″：LEF format

Arguments：-mem 64 -sort

c5eb5fff File

1c18cc01 File non-Whitespace

eb7f52d1 File Whitespace

File Header(sorted)

6f3a526d File Header with Comments

7a436b8c File Header without Comments

157939e1 File Header Comments

b450539c File Header non-Layer

316de219 File Header Layer M1

ff7eda09 File Header Layer M2

Cell ″AND2_X1″(sorted)

9a4743f9 Cell with Comments

9a4743f9 Cell without Comments

(none)   Cell Comments

051d90d0 Cell Interface non-Layer

cbeea19a Cell Interface Layer M1

54b472b3 Cell Body non-Layer

Cell ″AND2_X2″(sorted)

  6922ffe9 Cell with Comments

  6922ffe9 Cell without Comments

  (none)   Cell Comments

  04592cfd Cell Interface non-Layer

  39cfa1a7 Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

Cell ″AND2_X4″(sorted)

  aa5c90cd Cell with Comments

  aa5c90cd Cell without Comments

  (none)   Cell Comments

  d48106d4 Cell Interface non-Layer

  2a69e4aa Cell Interface Layer M1

  39cfa1a7 Cell Interface Layer M2

  54b472b3 Cell Body non-Layer

Cell ″AND3_X1″(sorted)

  ae1d08cc Cell with Comments

  ae1d08cc Cell without Comments

  (none)   Cell Comments

  5b3057b1 Cell Interface non-Layer

  a1992dce Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

Cell ″AND3_X2″(sorted)

  e9fc0084 Cell with Comments

  e9fc0084 Cell without Comments

  (none)   Cell Comments

  6bca4478 Cell Interface non-Layer

d682364f Cell Interface Layer M1

    54b472b3 Cell Body non-Layer

Cell ″AND3_X4″(sorted)

  6a5906e0 Cell with Comments

  6a5906e0 Cell without Comments

  (none)   Cell Comments

  0a3e63ea Cell Interface non-Layer

  34d317b9 Cell Interface Layer M1

  77375526 Cell Interface Layer M2

  54b472b3 Cell Body non-Layer

以及

File ″lib_45nm_v2_0.lef″：LEF format

Arguments：-mem 64 -sort

  e03e9e03 File

  80a5de77 File non-Whitespace

  30dbab35 File Whitespace

File Header(sorted)

  7c315cff File Header with Comments

  6948651e File Header without Comments

  157939e1 File Header Comments

  b450539c File Header non-Layer

  316de219 File Header Layer M1

  ec75d49b File Header Layer M2

Cell ″AND2_X1″(sorted)

  1ed769e0 Cell with Comments

  1ed769e0 Cell without Comments

  (none)   Cell Comments

  818dbac9 Cell Interface non-Layer

  cbeea19a Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

Cell ″AND2_X2″(sorted)

  498852e8 Cell with Comments

  498852e8 Cell without Comments

  (none)   Cell Comments

  04592cfd Cell Interface non-Layer

  19650ca6 Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

Cell ″AND2_X4″(sorted)

  aa5c90cd Cell with Comments

  aa5c90cd Cell without Comments

  (none)   Cell Comments

  d48106d4 Cell Interface non-Layer

  2a69e4aa Cell Interface Layer M1

  39cfa1a7 Cell Interface Layer M2

  54b472b3 Cell Body non-Layer

Cell ″AND3_X1″(sorted)

  ae1d08cc Cell with Comments

  ae1d08cc Cell without Comments

  (none)   Cell Comments

  5b3057b1 Cell Interface non-Layer

  a1992dce Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

Cell ″AND3_X2″(sorted)

  e9fc0084 Cell with Comments

  e9fc0084 Cell without Comments

  (none)   Cell Comments

  6bca4478 Cell Interface non-Layer

  d682364f Cell Interface Layer M1

  54b472b3 Cell Body non-Layer

Cell ″AND3_X4″(sorted)

  6a5906e0 Cell with Comments

  6a5906e0 Cell without Comments

  (none)   Cell Comments

  0a3e63ea Cell Interface non-Layer

  34d317b9 Cell Interface Layer M1

  77375526 Cell Interface Layer M2

  54b472b3 Cell Body non-Layer

这些文件通过读取支持几何排序(针对OASIS、GDSII、LEF、DEF和Liberty格式文件的推荐)并且具有32比特概要的两个版本的LEF文件来生成。因为LEF文件指定布局和布线工具应当如何连接至标准单元，所以单元中几乎全部内容都在接口中—改变是足够显著的，因为这意味着无法简单地嵌入新的布局版本来代替较老版本。

运行该命令：

sigcompare -compare sigcompare_file1.txt sigcompare_file2.txt

产生以下报告：

Summary of file-level comparisons：

File ″lib_45nm_v1_0.lef″File digest does not match

File ″lib_45nm_v2_0.lef″File digest.

File ″lib_45nm_v1_0.lef″non-Whitespace digest does not match

File ″lib_45nm_v2_0.lef″non-Whitespace digest.

File ″lib_45nm_v1_0.lef″Whitespace digest does not match

File ″lib_45nm_v2_0.lef″Whitespace digest.

Summary of file header comparisons：

File ″lib_45nm_v1_0.lef″header is a partial match with

File ″lib_45nm_v2_0.lef″header：

  non-Layer digests match

  File Header Layers matched：

    M1

  File Header Layers mismatched：

    M2

  comments match

Summary of all cell comparisons：

        2 cells are partial matches

        4 cells are perfect matches

File ″lib_45nm_v1_0.lef″cell ″AND2_X2″is a partial match with

File ″lib_45nm_v2_0.lef″cell ″AND2_X2″：

  Cell Interface matches partially：

    Cell Interface non-Layer digests match

    Cell Interface Layers mismatched：

      M1

  no Cell Body data is present

  no Cell Body non-Geometric Layer data is present

  no comments present

File ″lib_45nm_v1_0.lef″cell ″AND2_X1″is a partial match with

File ″lib_45nm_v2_0.lef″cell ″AND2_X1″：

  Cell Interface matches partially：

    Cell Interface non-Layer digests do not match

    Cell Interface Layers matched：

      M1

  no Cell Body data is present

  no Cell Body non-Geometric Layer data is present

  no comments present

文件中某些地方存在差异，所以针对文件中所有字节的文件概要不同。某些值也是不同的，所以非空白概要不同。最后，空白概要不同。针对所有文件类型打印文件概要比较；仅针对文本文件类型打印其他两个。

LEF文件头部(其包括用于布线层的设计规则和寄生信息)在层M2上不同，单元AND2_X2与AND2_X1不完全匹配。这些比较没有示出头部与单元之间的差异的准确性质；其仅告知用户查看哪里。

并非所有的设计文件格式都在文件头部中具有相关数据。GDSII文件在文件头部中具有无意义的数据，而OASIS文件级特性不会影响几何表示。因此，GDSII或者OASIS文件之间的比较将不包括关于文件头部数据的匹配的报告。

版本报告模式

版本报告模式的一种用途是用于：当用户具有多个版本的库文件时，确定针对设计文件中的单元的源库。针对设计文件中的单元，程序定位来自所有库文件的最近匹配(如果有的话)。

用于版本报告模式的语法是：

sigcompare -report[-showall]file -1 file...-2 file...[-3 file...]...

首先是设计文件，其他文件是库。库文件利用其版本号来指定，-1表示最近版本，-2表示下一最近版本，以此类推。除了版本号是连续的，并且每个版本号存在至少一个文件以外，版本号或者每个版本号的文件数目没有限制。

-report参数指定版本报告模式。默认地，仅报告不匹配单元(例如，布局和布线单元)、非完全匹配或者与过期单元的匹配；可选的-showall标志指定报告了所有单元，包括与最近库版本的完全匹配。

如果文件名称以“-”开始，则其名称之前具有-file。

通过名称来对单元进行匹配，不尝试在不同的名称下查找拷贝。

版本报告示例

此示例将来自小的设计OASIS文件的概要与用于构建其的GDSII库进行比较。设计概要文件称为

design_from_versions.txt：

File ″design_from_versions.oas″：OASIS format

Arguments：-grid 1e-9 -mem 64 -sort

  f3b2848e File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  (none)   File Header with Comments

  (none)   File Header without Comments

  (none)   File Header Comments

Cell ″top″(sorted；hierarchical)

  4512f0e0 Cell with Comments

  4512f0e0 Cell without Comments

  (none)   Cell Comments

  4512f0e0 Cell Body non-Layer

Cell ″AND2_X1″(sorted)

  63710c55 Cell with Comments

  63710c55 Cell without Comments

  (none)   Cell Comments

  a57f61d1 Cell Body Layer 8

  d5557088 Cell Body Layer 10

  135b1d0c Cell Body Layer 12

Cell ″AND2_X2″(sorted)

  4245e32b Cell with Comments

  4245e32b Cell without Comments

  (none)   Cell Comments

  33bfda26 Cell Body Layer 8

  47834653 Cell Body Layer 10

  36797f5e Cell Body Layer 12

Cell ″AND2_X4″(sorted)

  7dbb4961 Cell with Comments

  7dbb4961 Cell without Comments

  (none)   Cell Comments

  b431c2dd Cell Body Layer 8

  addb2970 Cell Body Layer 10

  6451a2cc Cell Body Layer 12

来自最近库的概要包括在文件

sigcompare_version1_3.txt中：注意，GDSII单元具有注释概要，而以上OASIS单元不具有任何注释。

File ″lib_v1_3.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -sort

  3b57a2c0 File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  9547893d File Header with Comments

  01f60a9d File Header without Comments

  94b183a0 File Header Comments

  01f60a9d File Header non-Layer

Cell ″AND2_X1″(sorted)

  e60bb9da Cell with Comments

  7ff21caa Cell without Comments

  99f9a570 Cell Comments

  b9fc712e Cell Body Layer 8

  d5557088 Cell Body Layer 10

  135b1d0c Cell Body Layer 12

Cell ″AND2_X2″(sorted)

  ff7d7b80 Cell with Comments

  6684def0 Cell without Comments

  99f9a570 Cell Comments

  cdf468c5 Cell Body Layer 8

  9d09c96b Cell Body Layer 10

  36797f5e Cell Body Layer 12

Cell ″AND2_X4″(sorted)

  11174169 Cell with Comments

  88eee419 Cell without Comments

  99f9a570 Cell Comments

  7715e8f3 Cell Body Layer 8

  8158c56e Cell Body Layer 10

  7ea3c984 Cell Body Layer 12

来自先前版本的概要包括在文件

sigcompare_version1_2.txt中：

File ″lib_v1_2.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -sort

  f7b57566 File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  e4590214 File Header with Comments

  d5839d36 File Header without Comments

  31da9f22 File Header Comments

  d5839d36 File Header non-Layer

Cell ″AND2_X1″(sorted)

  6f006266 Cell with Comments

  26f9c716 Cell without Comments

  99f9a570 Cell Comments

  b9fc712e Cell Body Layer 8

  26cf422a Cell Body Layer 10

  b9caf41f Cell Body Layer 12

Cell ″AND2_X2″(sorted)

  4b527d9d Cell with Comments

  4245e32b Cell without Comments

  09179eb6 Cell Comments

  33bfda26 Cell Body Layer 8

  47834653 Cell Body Layer 10

  36797f5e Cell Body Layer 12

Cell ″AND2_X4″(sorted)

  b35fe404 Cell with Comments

  92f41f5b Cell without Comments

  21abfb5f Cell Comments

  418cffaf Cell Body Layer 8

  addb2970 Cell Body Layer 10

  7ea3c984 Cell Body Layer 12

来自库的最老的活跃版本的概要包括在sigcompare_version1_1.txt中：

File ″lib_v1_1.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -sort

  ae014c24 File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  82295a77 File Header with Comments

  86b9ff40 File Header without Comments

  0490a537 File Header Comments

  86b9ff40 File Header non-Layer

Cell ″AND2_X1″(sorted)

  15918b78 Cell with Comments

  8c682e08 Cell without Comments

  99f9a570 Cell Comments

  b9fc712e Cell Body Layer 8

  26cf422a Cell Body Layer 10

  135b1d0c Cell Body Layer 12

Cell ″AND2_X2″(sorted)

  5a1e9163 Cell with Comments

  169108cf Cell without Comments

  4c8f99ac Cell Comments

  33bfda26 Cell Body Layer 8

  47834653 Cell Body Layer 10

  6fad94ba Cell Body Layer 12

Cell ″AND2_X4″(sorted)

  99bcef32 Cell with Comments

  b817146d Cell without Comments

  21abfb5f Cell Comments

  b431c2dd Cell Body Layer 8

  addb2970 Cell Body Layer 10

  a1fdffc0 Cell Body Layer 12

如果运行此命令：

sigcompare -report design_from_versions.txt \

  -1 sigcompare_version1_3.txt \

  -2 sigcompare_version1_2.txt \

  -3 sigcompare_version1_1.txt

则生成以下报告：

Summary of all comparisons：

      1 cells do not appear in any library

        1 of these cells are hierarchical

      2 cells match only partially with library cells

       2 cells match old library cells

File ″design_from_versions.oas″cell ″top″does not match any

library cell.

  cell is hierarchical.

File ″design_from_versions.oas″cell ″AND2_X4″is a partial

match with

File ″lib_v1_1.gds″cell ″AND2_X4″：

  no Cell Interface data is present

  Cell Body data matches partially：

    Cell Body Layers matched：

      10 8

    Cell  Body Layers mismatched：

      12

  no Cell Body non-Geometric Layer data is present

  there are 2 newer versions of this cell

File ″design_from_versions.oas″cell ″AND2_X1″is a partial

match with

File ″lib_v1_3.gds″cell ″AND2_X1″：

  no Cell Interface data is present

  Cell Body data matches partially：

    Cell Body Layers matched：

      10 12

    Cell Body Layers mismatched：

      8

  no Cell Body non-Geometric Layer data is present

File ″design_from_versions.oas″cell ″AND2_X2″is a perfect

match with

File ″lib_v1_2.gds″cell ″AND2_X2″：

  no Cell Interface data is present

  Cell Body data matches perfectly：

    Cell Body Layers matched：

      10 12 8

  no Cell Body non-Geometric Layer data is present

  there is 1 newer version of this cell

顶层设计单元不在任何库中，如所期望的。设计文件中的其他三个单元具有至少一个可报告问题：

●AND2_X4不与任何库单元完全匹配；最接近的匹配是来自最老库的版本

●AND2_X1不与任何库单元完全匹配；最接近的匹配是来自最新库的版本

●AND2_X2与第二老的库中的单元完全匹配

当单元仅进行部分匹配时，打印匹配和失配的数据类型和层的列表。

数据库检查模式

数据库检查模式的一种用途是：将候选设计文件与利用以下完善水平加标签的库集合进行验证：新的/未检验的、生产、被否决/陈旧或者已知是不良的。这些表示单元的特定版本的生命期。例如，如果设计处于批量生产中，则用户可能不想使用单元的未检验版本；用户可能仅想使用已被标记为值得生产的单元。然而，一旦检验了新的版本，则将逐步淘汰较老的版本。被否决的版本可能仅在已经批量生产的设计中使用，而不在新设计中使用。最后，如果已知单元版本具有功能或者生产问题，则不应当将其用于任何设计。

规范化单元概要匹配允许用户在候选文件中分类所有单元，即使其已经在不同的名称下被拷贝。以此方式，用户可以检测对所有已知不良单元的使用，或者及时标识未授权单元以防止发布设计去制造。

使用原型命令行处理器时，用于数据库检查模式的语法是：sigcompare -database [-showall] [-new...] [-prod...] [-depr...] [-bad...] -test...

-database参数指定数据库检查模式。默认地，不报告对生产单元的完全匹配。同样使用可选的-showall标志来报告这些单元。

命令行的其余部分是具有类型的概要文件的列表。除了存在至少一个-test(候选)文件以及至少一个另一类型的文件以外，它们可以按照任何顺序。

-new参数用于指定包含新的并且尚未在生产中检验的单元的库。此后直到下一库类型之前的所有文件名称被标记为新的。

-prod参数用于指定包含已经在生产中检验的单元的库。此后直到下一库类型之前的所有文件名称被标记为生产。

-depr参数用于指定包含如下单元的库，这些单元被否决或者是陈旧的，并且不应当在新设计中使用。此后直到下一库类型之前的所有文件名称被标记为被否决。

-bad参数用于指定包含已知是不良的并且应当从所有设计中移除的单元的库。此后直到下一库类型之前的所有文件名称被标记为已知是不良的。

-test参数用于指定候选设计文件。通常，用户一次将仅比较一个候选文件。

如果文件名称以“-”开始，则其名称之前具有-file。

数据库检查示例

此示例将来自小的设计OASIS文件的概要与用于构建其的GDSII库进行比较。设计概要文件名为

design_from_database.txt：

File ″design_from_database.oas″：OASIS format

Arguments：-grid 1e-9 -mem 64 -sort

  14430d19 File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  (none)   File Header with Comments

  (none)   File Header without Comments

  (none)   File Header Comments

Cell ″top″(sorted；hierarchical)

  fccf8240 Cell with Comments

  fccf8240 Cell without Comments

  (none)   Cell Comments

  fccf8240 Cell Body non-Layer

Cell ″AND2_X1″(sorted)

  7ff21caa Cell with Comments

  7ff21caa Cell without Comments

  (none)   Cell Comments

  b9fc712e Cell Body Layer 8

  d5557088 Cell Body Layer 10

  135b1d0c Cell Body Layer 12

Cell ″AND2_X2″(sorted)

  aeece77d Cell with Comments

  aeece77d Cell without Comments

  (none)   Cell Comments

  df16de70 Cell Body Layer 8

  47834653 Cell Body Layer 10

  36797f5e Cell Body Layer 12

Cell ″AND2_X4″(sorted)

  b817146d Cell with Comments

  b817146d Cell without Comments

  (none)   Cell Comments

  b431c2dd Cell Body Layer 8

  addb2970 Cell Body Layer 10

  a1fdffc0 Cell Body Layer 12

Cell ″AND2_X4A″(sorted)

  b817146d Cell with Comments

  b817146d Cell without Comments

  (none)   Cell Comments

  b431c2dd Cell Body Layer 8

  addb2970 Cell Body Layer 10

  a1fdffc0 Cell Body Layer 12

Cell ″AND2_X3″(sorted)

  c6f8c857 Cell with Comments

  c6f8c857 Cell without Comments

  (none)   Cell Comments

    b9fc712e Cell Body Layer 8

  075a8f95 Cell Body Layer 10

  785e36ec Cell Body Layer 12

Cell ″AND2_X5″(sorted)

  e60bb9da Cell with Comments

  7ff21caa Cell without Comments

  99f9a570 Cell Comments

  b9fc712e Cell Body Layer 8

  d5557088 Cell Body Layer 10

  135b1d0c Cell Body Layer 12

再次使用来自版本报告示例的文件

sigcompare_version1_1.txt、

sigcompare_version1_2.txt和

sigcompare_version1_3.txt，连同新文件

sigcompare_version1_4.txt：

File ″lib_v1_4.gds″：GDS format

Arguments：-grid 1e-9 -mem 64 -sort

  c589f1al File

  (none)   File non-Whitespace

  (none)   File Whitespace

File Header(sorted)

  43922b24 File Header with Comments

  c52bd464 File Header without Comments

  86b9ff40 File Header Comments

  c52bd464 File Header non-Layer

Cell ″AND2_X1″(sorted)

  512424b9 Cell with Comments

  4a03a6f8 Cell without Comments

  1b278241 Cell Comments

  b9fc712e Cell Body Layer 8

  8ba1e13a Cell Body Layer 10

  785e36ec Cell Body Layer 12

Cell ″AND2_X2″(sorted)

  a994ef98 Cell with Comments

  58eb1029 Cell without Comments

  f17fffb1 Cell Comments

  cdf468c5 Cell Body Layer 8

  47a75210 Cell Body Layer 10

  d2b82afc Cell Body Layer 12

Cell ″AND2_X4″(sorted)

  9842af7a Cell with Comments

  5c09dc54 Cell without Comments

  c44b732e Cell Comments

  8d50e097 Cell Body Layer 8

  affaf547 Cell Body Layer 10

  7ea3c984 Cell Body Layer 12

当运行此命令时：

sigcompare -database -new sigcompare_version1_4.txt \

  -prod sigcompare_version1_3.txt \

  -depr sigcompare_version1_2.txt \

  -bad sigcompare_version1_1.txt \

  -test design_from_database.txt

生成以下报告：

Summary of all comparisons：

       1 cells have no good matches

         1 of these cells are hierarchical

       2 cells are perfect matches with known bad cells

         1 of these matches are under different names

       1 cells are partial matches with deprecated cells

       1 cells are partial matches  with new cells

         1 of these matches are under different names

       2 cells are perfect matches with production cells

         1 of these matches are under different names

File ″design_from_database.oas″，cell ″top″：no good matches.

  cell is hierarchical.

File ″design_from_database.oas″cell ″AND2_X4A″is a perfect

match with

File ″lib_v1_1.gds″bad cell ″AND2_X4″：

  no Cell Interface data is present

  Cell Body data matches perfectly：

    Cell Body Layers matched：

      10 12 8

  no Cell Body non-Geometric Layer data is present

File ″design_from_database.oas″cell ″AND2_X4″is a perfect

match with

File ″lib_v1_1.gds″bad cell ″AND2_X4″：

  no Cell Interface data is present

  Cell Body data matches perfectly：

    Cell Body Layers matched：

      10 12 8

  no Cell Body non-Geometric Layer data is present

File ″design_from_database.oas″cell ″AND2_X2″is a partial

match with

File ″lib_v1_2.gds″depreeated cell ″AND2_X2″：

  no Cell Interface data is present

  Cell Body data matches partially：

    Cell Body Layers matched：

      10 12

    Cell Body Layers mismatched：

      8

  no Cell Body non-Geometric Layer data is present

File ″design_from_database.oas″cell ″AND2_X3″is a partial

match with

File ″lib_v1_4.gds″new cell ″AND2_X1″：

  no Cell Interface data is present

  Cell Body data matches partially：

    Cell Body Layers matched：

      12 8

    Cell Body Layers mismatched：

      10

  no Cell Body non-Geometric Layer data is present

File ″design_from_database.oas″cell ″AND2_X5″is a perfect

match with

File ″lib_v1_3.gds″production cell ″AND2_X1″：

  no Cell Interface data is present

  Cell Body data matches perfectly：

    Cell Body Layers matched：

      10 12 8

  no Cell Body non-Geometric Layer data is present

如之前一样，顶层单元不与任何库相匹配。设计者例如通过布局和布线而创建作为物理设计过程一部分的任何单元将不在库中。通常，这些单元将不是叶单元，所以打印针对层级式单元的报告，意味着其具有对其中其他单元的引用。

将与已知不良单元的匹配列在非匹配单元之后。在该程序模式中，即使单元名称不同，也将发现和报告匹配。例如，单元AND2_X4A是来自最老的库(版本1.1)的已知不良单元AND2_X4的拷贝，这表明设计者在设计块中对该单元进行了重命名，而不是利用最新的版本来对其进行替换。AND2_X4的已知不良版本也出现在其原始名称下。

接下来列出与被否决单元的匹配。这里，与设计单元AND2_X2的最佳匹配来自被否决库版本1.2。这表明设计者从过期库开始本地修改了单元。利用单元和文件名称来标记层相似性和差异性。

将与新单元的匹配列在与被否决单元的匹配之后。来自设计的单元AND2_X3是与新库单元AND2_X1的优选匹配，这意味着其是从不同的名称下的新库拷贝的。

最后，列出与不同名称下的生产单元的匹配。这里，设计单元AND2_X5是来自库版本1.3的生产单元AND2_X1的拷贝。这不是即时问题，但是如果以后修改了AND2_X1的版本1.3，则拷贝将不利用改进的版本来替换。

如果选择了-showall选项，则将与相同名称的生产单元的匹配列在所有其他匹配之后。在此小示例中，将仅打印一个附加单元报告；通常，将打印上千个匹配单元报告。

File ″design_from_database.oas″cell ″AND2_X1″is a perfect

match with

File ″lib_v1_3.gds″production cell ″AND2_X1″：

  no Cell Interface data is present

  Cell Body data matches perfeetly：

    Cell Body Layers matched：

      10 12 8

  no Cell Body non-Geometric Layer data is present

匹配Liberty(.lib)文件的报告

Liberty格式文件testfiles/tstlibpar2.lib包含针对几个单元的定时模型。单元AND2_X2具有cell和scaled_cell规范二者。在一个实施方式中，将这些进行组合以生成针对单元的概要。单元AND2_X1、AND2_X1_copy和AND2_X1_copy_b是相同的；AND2_X1_copy是准确拷贝，而AND2_X1_copy_b内的某些语句已经进行了重新排列。在不排序的情况下，概要不同：

otismartsig -sort -lib testfiles/tstlibpar2.lib

...

Cell ″AND2_X1″

  Interface CRC 0190af2f

  Contents CRC 6a059541

Cell ″AND2_X1_copy″

  Interface CRC 0190af2f

  Contents CRC 6a059541

Cell ″AND2_X1_copy_b″

  Interface CRC 1ee6bb80

  Contents CRC e4fa24f0

将单元的pin组语句视为单元接口的一部分。因为两个pin语句在AND2_X1_copy_b中交换，所以接口和内容概要都改变了。

在排序的情况下，所有的概要相匹配：

otismartsig -sort -lib testfiles/tstlibpar2.lib

...

Cell ″AND2_X1″

  Interface CRC 0190af2f

  Contents CRC dc623050

Cell ″AND2_X1_copy″

  Interface CRC 0190af2f

  Contents CRC dc623050

Cell ″AND2_X1_copy_b″

  Interface CRC 0190af2f

  Contents CRC dc623050

修改Liberty格式文件的头部(例如，单位、操作条件或者表索引)潜在地影响库中的单元，所以默认将头部的非注释记号添加到库中的单元概要中。由此，头部中的任何改变将改变单元概要。

匹配Verilog文件的报告

文件testfiles/verilog_test.v包含描述某些晶体管级单元的若干较小模块。这些模块中的某些是拷贝。例如，模块DEF_X2是模块DEF_X1的直接拷贝。因此，针对两个模块的概要是相同的：

otismartsig -ver testfiles/verilog_test.v

...

Cell ″DFF_X1″

  Interface CRC c102a525

  Contents CRC dbac5dc2

Cell ″DFF_X2″

  Interface CRC c102a525

  Contents CRC dbac5dc2

单元内的空行被移除，但是语言构造是相同的。任一模块内都不存在注释，所以不报告注释概要。

文件testfiles/verilog_test2包含模块OAI21_X1和OAI21_X2。后者是相同的，除了改变了端口排列。通常，使用位置参数来对Verilog模块进行实例化，所以，与模块的连接将是不同的，并且概要也将不同：

otismartsig -ver testfiles/verilog_test2.v

File ″testfiles/verilog_test2.v″：Verilog format

  File CRC 25de7835

  File header CRC 6ef229e6

  File comment CRC 6ef229e6

  File non-whitespace CRC 07f87fb9

  File whitespace CRC ac6fc0b2

Cell ″OAI21_X1″

  Interface CRC dae46517

  Contents CRC c73aceaf

Cell ″OAI21_X2″

  Interface CRC 01391569

  Contents CRC c73aceaf

然而，如果指定了-sort，则将端口按字母顺序放置以用于计算概要之目的，并且单元将匹配：

otismartsig -sort -ver testfiles/verilog_test2.v

  File CRC 25de7835

  File header CRC 6ef229e6

  File comment CRC 6ef229e6

  File non-whitespace CRC 07f87fb9

  File whitespace CRC ac6fc0b2

Cell ″OAI21_X1″

  Interface CRC cf2d7023

  Contents CRC c73aceaf

Cell ″OAI21_X2″

  Interface CRC cf2d7023

  Contents CRC c73aceaf

匹配GDSII文件的报告

文件testfiles/sigtest.gds是综合GDSII格式文件，其被构造为显示GDSII规范化单元概要计算的某些特征。其包含四个单元，Structure_1到Structure_4。Structure_2是叶单元，其被其他三个单元引用。结构和数组引用不具有层编号，所以其概要作为非层数据存储在层-1上：

otismartsig -gds testfiles/sigtest.gds

File ″testfiles/sigtest.gds″：GDS format

  File CRC d0b40760

Cell ″Structure_1″

  Comment CRC b0f5064e

  Layer -1 CRC 485b93e7

  Layer 3 CRC 58ffb953

  Layer 42 CRC e6098359

  Cell CRC 4658afa3

Cell ″Structure_2″

  Comment CRC 6acc5ddd

  Layer 1 CRC 0e517512

  Layer 5 CRC 00065ea8

  Layer 19 CRC 931b9a0f

  Cell CRC f780ec68

Cell ″Structure_3″

  Comment CRC b0f5064e

  Layer -1 CRC 485b93e7

  Layer 3 CRC 58ffb953

  Layer 42 CRC e6098359

  Cell CRC 4658afa3

Cell ″Structure_4″

  Comment CRC 9d8b21ad

  Layer -1 CRC 485b93e7

  Layer 3 CRC 47a23fdd

  Layer 42 CRC e6098359

  Cell CRC 747b0ece

Structure_3是Structure_1的直接拷贝，所以其所有概要与Structure_1的相同。Structure_4的层3上的多边形按照不同的顺序，所以针对层3的概要不同于Structure_1和Structure_3。可选地，otismartsig用户可以指定多边形的排序和其他步骤，以进一步重新组织所概括的设计数据。

应用规范化概要来解决IC设计问题

计算和比较规范化概要可以在集成电路的设计中具有很多实践使用。要求保护的技术的不同实施方式解决了不同的问题。以上列出了针对该技术的某些使用情况。图3示出了可以有益地应用所公开的技术的设计过程中的交接点。图3中的多数框与图1中的框相匹配。图3中添加了审核362，其指示在代工厂制造的生产设计的独立查看，用以验证生产设计中存在承担使用费的设计模板。虚线框301放置在可以有益地应用计算和比较规范化概要的交接点处，但并不旨在穷举性的。在逻辑综合123之前，可以测试用于综合的单元设计库的有效性。随着从代工厂141接收新数据以并入单元设计库131中，可以查看和评估改变的重要性。在布图规划133之前和之后，可以针对经批准单元的使用、单元的重命名和修改来仔细查看设计，以避免使用不良单元。作为审核过程362的一部分，可以将生产设计中的规范化单元概要与承担使用费的设计单元概要进行比较。可以生成生产设计中的单元的列表和计数，以用于使用费审核目的。这些有益应用在以下部分中将进一步易见。

共同主题

所描述的有益应用依赖于计算机实现的方法，该方法用于评估驻留在两个或更多文件中的针对电路的设计数据之间的相似性和/或差异性。计算机被用于标识设计数据内的单元或者设计单位，以上描述了单元和设计单位。如所解释的，单元可以分组为块。一些文件可以包括单个头部或者单元。在单元内，设计数据的语法被解析，并被标准化为规范化形式。规范化形式降低了数据分析对设计数据中的非功能性改变的敏感性。计算并且存储针对规范化形式的设计数据的至少一部分的概要。每个单元或者设计单位产生至少一个概要，并且通常不止一个概要。还产生针对不被视为任何特定单元的部分的文件头部的概要。将一个文件中的单元的概要与其他文件中的单元的概要进行比较。根据相似性或者差异性是否更加适合任何特定分析，生成适合的总结。总结可以是人类可读的报告，或者存储在计算机文件中以用于由其他程序进一步处理。

更新的单元设计库的理解

设计者面临的问题之一是：虽然可以从代工厂、库供应商或者内部开发组接收设计库的新版本，但没有从一个版本到下一版本的改变的满意描述。常规的区分工具可以用于将新库与老库进行比较。如上所述，区分工具设计用于为改变添加标志，而不是评估改变的重要性。计算库的老版本和新版本的概要可以用于标识改变的单元。单元在功能性和非功能性数据之间的划分以及将单元划分到层中可以产生概要，根据该概要，库管理者可以评估到库的新版本的改变的重要性，并且进一步详细调查。可以将非功能性数据的改变(诸如对标识库版本的注释的改变或者对应用软IP标签添加的IP标签的改变)与功能上重要的数据的改变分离开。这种分离可以用于过滤总结或者为其添加色码(color code)，并且帮助库管理者决策进行到何处。

在开发期间是否采取更新的单元设计库

集成电路设计是使用数以万计的单元以及几十或者几百个复杂设计模板的迭代过程。逻辑设计团队使用逻辑综合来生成结构化网表，其被发送至集成团队以用于布局和布线过程。在设计过程的最后阶段，在对顶层块进行布局、布线和优化时，其用于确保设计使用所有库元件的最新版本。

然而，通过第一轮布局和布线，在设计项目中投入了太多，使得项目管理者将想要知道库中发生了什么改变，以及为何在其接受需要设计的重新工作的库的新版本之前发生改变。例如，如果改变了定时模块，则需要进行另一轮现场优化，以匹配新的定时数据。如果改变了库交换格式(LEF)文件中的单元占用面积，则可能需要新的布局和布线步骤，这可能造成定时以及进一步迭代的巨大改变。这些步骤中任何一个的重新工作都牵涉将无法满足性能目标或者将延误截止期限的风险。将这些风险与库的新版本解决的生产或者功能性问题进行权衡。

所公开的技术可以用来聚焦到对正在开发的设计中实际使用的单元上的已更新单元设计库的分析。针对开发中的设计、老库单元和新库单元的概要的三种方式的比较对于项目管理者而言是有用的，这些项目管理者需要决策在已经做出了相当的投资之后是否要采取更新的单元库。在管理者做出决策之前，可以考虑多种设计语言的设计数据的多个视图。

找到设计数据中未被批准和/或不良单元

单元具有很多潜在源，这些源在公司内或者来自供应商。确定单元来自经批准的源还是未被批准的源是有用的。另外，最初被批准的单元可能被证明是不良的，并且被放置在排序的黑名单中，该黑名单是不应当在任何设计中使用的不良单元的列表。规范化概要的一种有益应用是确定设计中的哪些单元不存在于任何经批准的单元库中。另一有益应用是确定设计中的任何单元是否具有与不应当在任何设计中使用的不良单元的库相匹配的数据。当然，这些可以组合使用。

标识设计数据中的重命名单元

在设计期间，已知设计者对单元进行了重命名，以便避免单元名称冲突，因为在某些工具中，要求单元名称是唯一的。理想上，名称冲突可以作为调查单元的两个使用是否依赖于相同的单元版本以及在不同的版本之间选择的原因。正在进行的设计项目的压力有时导致不理想的实现。因此，设计者简单地对其使用的单元进行重命名并且保留。

规范化概要可以用于找到重命名的单元的源。对重命名的单元的概要与单元库进行比较提供了比单元内的注释更加可靠的单元源的指示，当工作组规则或者期待阻止单元的重命名时尤其如此。对概要进行比较可以证明重命名的单元与经批准的设计相匹配，这给予设计管理者或者设计者将单元名称反转为经批准的设计中所使用的名称的信心。当设计工具使用单元名称作为参考时，期望使用与经批准的库元件相匹配的名称。

检测危害担保的单元修改

利用供应商提供的模板开始工作的设计团队可能尝试对模板进行改进。例如，可以改变编译的随机访问存储器以更好地适合所感知到的当前设计需要。然而，设计者可能无法完全理解改变的后果。例如，在标称过程条件下加速存储器的改变实际上在其他过程条件下可能减慢存储器。在半导体行业中，这是指在其他工艺拐点发生什么。设计的改变还可能由于导致桥接故障或者开放触点而破不良电路的生产。这些改变可能使从供应商接收的设计模板的显式或者隐式的担保无效。

可以分析具有多个概要的单元，以确定其是否是另一单元的修改版本。在某些情况下，多个库单元将跨某些层匹配。例如，都具有相同功能的单元类内的金属布局可能匹配。当检测到跨某些层但不是全部层的匹配时，可以执行进一步的分析，以确定是否发生了未授权修改。可选地，可以对该分析加权，以强调隐式修改的层改变而不是单元的共同类的成员之间的正常改变。

使用费审核

流片数据通常对于代工厂是可用的，作为制造过程的一部分。该流片数据可以按照OASIS、GDSII或者其他语言来表达。其包括定义掩膜的多边形，该掩膜用作制造工具或者用于制造期间的直接写入。

基于单元中的多边形，可以将来自流片数据的经概括的单元与来自使用费承担库的经概括单元进行比较。可以通过排序来标准化这些多边形。可以可选地通过将单元中的多边形合并并且应用一致的分割算法使其重新分割来对其进行进一步标准化。

使用单元概要来审核代工厂处使用的设计并且计算所拥有的使用费具有以下优点，即审核者可以在不直接访问所概括的设计数据的情况下分析概要。如果代工厂运行概括工具，则审核者仅需要查看所产生的概要。通过审核者进一步查看设计数据而不限于概要，可以解决封闭式问题。

使用费审核还可以通过基于符号、文本的设计数据而不是多边形数据来导出。

故障分析的立即响应

有时，故障分析将证实：设计模板是不良的并且不应当在任何产品中使用。由于设计模板的重命名和修改，这为设计管理者提出了严重的问题。规范化概要提供了快速扫描现有生产设计以及过程中设计的方式。可以将证明是不良的设计模板上的一个或多个变体的概要与针对现有产品的概要库以及过程中的设计的项目文件进行比较。可以为概要匹配或者部分匹配不良设计模板的概要的设计添加标志以用于进一步调查。这给予设计管理者一种方式，使其不止能够发现保留与原始设计库的链接的单元。这允许设计管理者发现可能共享导致不良设计模板的故障的层的重命名的单元和修改的单元。

命令行处理器的运行时间选项

原型规范化单元概要命令行工具的名称是“otismartsig”；其是将运行在1.4.x和之后的核上的32位或者64位Linux(例如，Red Hat公司Linux4.x或之后的)可执行的。如果其在没有参量的情况下运行，则其打印类似于以下的帮助文本：

Oasis Tooling Smart Digest utility 1.0 alpha(r867)

Copyright(c)2007-2008 by Oasis Tooling Inc.All Rights

Reserved.

Usage：otismartsig [flags] -type file... [-type file...]

Available flags：

-file：treat the next argument as a file name，even if it begins

with ′-′

-mem number：maximum memory usage in megabytes(default 64)

-64：compute 64-bit digests

-sort：sort records before computing digests

-nosort：do not sort records before computing digests

-noheader：omit Liberty file header from cell digests

-verbose：print errors as they are found(useful in debugging)

-grid number：record layout file digests using the specified

              grid(default 1.0e-9 meter)

Available file types：

-oas：OASIS geometry database(default：-sort)

-gds：GDS geometry database(default：-sort)

-lib：Liberty library format(default：-sort)

-ver：Verilog RTL and netlist format(default：-nosort)

-vhd：VHDL RTL and netlist format(default：-nosort)

-spi：SPICE subcircuit netlist format(default：-nosort)

-lef：Library Exchange Format(default：-sort)

-def：Design Exchange Format(default：-sort)

-txt：unstructured text files(default：-nosort)

-stxt：structured(e.g.script)text files(default：-nosort)

-user：user-parsed files(default：-nosort)

-bin：unstructured binary files(default：-nosort)

文件类型

文件应当具有所指定的文件类型。虽然有可能分析文件的头部来猜测其格式，但是错误的成本是很高的，例如，可能将基于单元的文本文件错误理解为非结构化文件。

如果期望，可以在单次运行中分析不止一种类型的文件。如果指定了新文件类型参量，则该参量之后的文件使用该格式。在以下示例中，前两个文件被解释为非结构化文本文件，而最后一个文件被解释为Verilog文件：

otismartsig -txt file1.txt file2.txt -ver file3.txt

如果文件名称以‘-’开始，则其之前应当具有-file。一个-file参量可以用于每个文件。

选项：-sort

多数文件格式提供排序数据的选项。针对若干格式，这是默认的，因为使用经排序的数据生成概要将比使用未排序的数据的概要生成更加有用的匹配。默认行为在文件格式的简要描述的结尾处的帮助文本中指定。其是：

●OASIS：默认排序，因为OASIS编写者很可能对数据重新排列，尤其是编写重复时

●GDSII：默认排序，因为GDSII编写者可能对数据重新排列，并且因为GDSII单元数据可能需要与OASIS数据进行匹配

●Liberty：默认排序，因为数据是顺序无关的

●Verilog：默认不排序，因为仅排序单元接口记录

●VHDL：默认不排序，因为仅排序单元接口记录

●SPICE：默认不排序，因为排序例程也排序单元接口记录

●LEF：默认排序，因为很多数据是顺序无关的

●DEF：默认排序，以为很多数据是顺序无关的

●非结构化文本：默认不排序，因为文件的目的未知

●结构化文本：不允许排序，因为脚本文件是顺序相关的

●用户解析的文件：默认不排序，因为文件的目的对于软件未知

●非结构化二进制：不允许排序，因为不存在记录结构

对于Verilog、VHDL和SPICE文件，如果某些实例使用位置端口引用(基于参数顺序的连接)而不是基于关联的端口引用(基于参数名称的连接)，则接口记录(端口)的排序可能修改单元的含义。由此，这对这些格式的排序应当谨慎进行。

如果用户想要对默认不排序的给定格式文件进行排序，则应当指定-sort选项。如果用户想要阻止文件的排序，则应当指定-nosort选项。这些选项是“粘性的”，意味着其影响命令行之后所列的所有文件。

选项：-mem

-mem指定允许用于排序的最大存储器量，以兆字节为单位。在本实现中，排序在存储器中排他地执行，所以如果针对单元或者文件头部的估计存储器使用超过该限制，则将所影响的数据按照其原始顺序发送至概要计算，并且针对该单元或者文件头部禁用排序。测试单元的可排序性，以使得即使在最小存储器可用的情况下也可以排序所有较小的设计模板块，以增加匹配并且降低差异性的错误检测。一般而言，仅较大的布局和布线块会超过存储器使用限制。

默认存储器使用限制是64兆字节；在32位Linux平台上，最大存储器使用限制是3500兆字节。如果-mem提供的值小于16，则默认将其增加至16；如果该值大于3500，则将默认将其减小至3500。

由于存储器分配方法的不确定性，工具的存储器使用估计是不精确的。最好不使用接近计算规范化单元概要的机器上的物理存储器量的存储器限制。针对某些文件格式的存储器估计可以是乐观的。

文件中的某些单元可以排序，而相同文件中的其他单元太大以至于不能排序，所以规范化单元概要工具报告是否因为设置-sort(或者默认)而对单元排序，是否因为指定-nosort(或者默认地)而不排序，或者虽然设置了-sort但是因为太大而不能排序：

Cell ″Structure_1″(sorted)

Cell ″Structure_1″(not sorted)

Cell ″Structure_1″(unable to sort)

软件利用概要来跟踪和存储针对给定单元的概要是否表示经排序的数据的指示或者标志。如果存储器使用限制增加，或者用户开始使用规范化单元概要软件的新的、更加有效的版本，则先前不可排序的某些单元现在可能将进行排序(如果用户减少限制，则反之亦然)。除非数据库存储是否根据经排序的数据计算概要的指示，用户将不能够确定概要的改变是否表示数据的真实改变，或者是否简单地因为一组概要是针对经排序的数据而另一组针对未经排序的数据。

选项：-64

默认地，生成32比特概要；如果指定了-64选项，则生成64比特概要。

64比特概要的生成或多或少需要比32比特概要的生成更多的运行时间。64比特概要在32比特可执行以及64比特可执行中是可用的。

选项：-verbose

默认地，程序静默地工作，仅生成概要报告或者一般的错误消息。针对自动化概要生成而不是针对人类使用来优化解析器。如果文件无法解析，并且其对于查看实际错误有用，则使用-verbose标志将使错误打印出来。在发现第一个错误之后，很多解析器会退出，所以错误报告将不会特别长。如果发现任何错误，则将不生成概要。

选项：-grid

OASIS和GDSII文件中的几何形状是在栅格中绘制的，这意味着文件中的所有坐标被缩放某个数目，以确定几何形状的绝对大小，以微米或者纳米为单位。栅格存储在文件中，使得含义是没有歧义的，但是如果栅格值由于某些原因改变，则单元中所有的坐标都将改变，即使几何形状没有改变。通过栅格缩放所有的坐标不是有效的方案，因为栅格是浮点数，通常幂为10。针对浮点数的概要可能是机器相关的或者容易受到舍入误差的影响。

由此，存在针对OASIS和GDSII文件的-grid选项。所有坐标被缩放至该栅格的倍数，该栅格例如1纳米(默认1.0e-9米)。例如，如果文件栅格是10纳米，并且规范化单元概要栅格是1纳米，则将来自文件的所有坐标发送至概要计算之前乘以10。如果OASIS或者GDSII文件栅格不是-grid值的整数倍，则打印错误。

选项：-noheader

Liberty格式文件在文件头部中具有多个定义和单位定义。如果这些文件头部值中任何部分改变，所有单元中的所有值(例如延迟)也可能改变。例如，如果文件头部中的time_unit或者voltage_unit值改变，则单元中的所有定时延迟值也将改变，即使单元中的文本没有改变。Liberty文件通常由脚本构建，该脚本将固定文件头部与针对个体单元的数据并置，并且容易使用错误的头部。由此，默认地，将所有的文件头部值(除了诸如日期的非功能性值以外)添加到Liberty文件中的针对单元的概要中。如果用户确信不会发生这种错误，则可以使用-noheader选项来禁用头部值合并。

某些具体实施方式

所公开的技术可以有益地应用于各种方式和设备。该技术还可以具体化在诸如计算机可读存储介质的制品中，该计算机可读存储介质存储有实现该方法或者可以与硬件相结合以产生所描述的设备的计算机程序。

在第一实施方式组中描述了方法。这些是评估驻留在存储于计算机存储器中的至少两个文件中的设计数据之间的相似性和/或差异性的计算机实现的方法。图6和图7提供了这些方法的某些方面的高层流程图。在设计数据环境中，数据可以是符号的或者二进制的。符号意味着文本旨在成为人类可读的。例如，数字和字母。符号文件也可以包含有助于文本可读性或者帮助内部文件管理的代码。例如制表符、字体属性和书签。设计文件可以按照以上所述的任何设计语言或者格式来表达。其可以包括多边形，该多边形可以由顶点和半平面来定义。其可以是层级式的，包括对其他设计数据的引用，按照展开格式或者层级式格式。可以预期广泛的设计数据。如上所述，对两个文件的引用是一般性的。这两个文件可以是相同数据库的部分。可以涉及不止两个文件。

方法对驻留在第一和第二文件411中的数据进行操作。在此描述中，方法涉及对设计内的单元进行操作并且生成规范化单元概要。规范化意味着标准化格式。通过将某些设计数据文件传送通过解析器并且应用解析规则，这些设计数据文件被正则化或被转换为规范化格式。其他文件可能需要通过解析生成的语法树的语义分析或者对文件进行正则化的其他操作。取决于解析规则，正则化可能消除空白，将来自程序代码的注释并置，对记号或者语法数的分支进行排序，将记号或者语法树的分支归类为功能性或者非功能性设计数据，在头部数据和单元数据之间划分数据，或者在单元内在单元头部和单元主体数据之间划分数据，重新排列多边形的角点，或者应用以上描述的任何其他解析或者标准化策略。应当理解，更一般地，在所附并且原始提交的权利要求中，该方法适用于数据的设计单位，并且词语“设计单位”在描述中可以替换为“单元”。在此公开中，示出了如何将文件中的设计数据划分为头部数据和单元数据。划分或者区分的意思是物理上或者逻辑上分组。如以下所解释的，产生语法树的解析规则可以自然地产生数据的物理划分。一旦产生了语法树，即可以将标签或者标志应用于语法树的节点或者分支。标签通常是具有特定意义的代码。标志也可以是代码，但是其比标签简单，诸如具有特定意义的字段中的布尔值。以下方法描述同等地适用于设计单位和单元。该方法包括标识驻留在文件中的设计数据内的单元(611)。其继续解析语法(612)，并且对单元内的设计数据正则化(613)为规范化形式。解析语法可以适用于符号或者二进制文件中的任一种。解析符号文件包括标识记号，并且根据描述语言的一系列解析规则来识别其在文件中的角色。解析二进制设计数据文件包括标识二进制数据的元素和组，并且根据描述设计文件的二进制格式的解析规则来识别其在设计数据中的角色。解析有时包括构建语法树。备选地，解析可以生成事件的流。正则化已在上文描述。规范化形式可以维护在一个或多个语法树532中。规范化形式降低了数据分析对特定单元内的设计数据中的非功能性改变的敏感性。设计数据的非功能性改变是对设计数据的这样的改变，这些改变不改变使用该设计数据产生的物理电路。例如，注释通常是非功能性设计数据；空白在符号文件中通常是非功能性的；在多边形角坐标的排列的列表中，起始坐标的选择以及该角是以顺时针还是逆时针方向列出通常是非功能性的。在较高层处，例如，将复杂多边形分割为梯形或者三角形不应当功能性地改变所产生的物理电路，但是特定的分割算法对于生产过程中使用的特定工具的操作是有必要的。该方法还包括计算(614)以及存储至少所选择的规范化形式的设计数据的概要415，针对每个单元产生至少一个概要。

该方法比较(615)规范化形式的概要，并且总结(616)比较概要的至少一些结果。其可以在存储器中产生总结473，诸如对另一程序可用的数据表，或者用户可查看的报告475。

执行这种比较可以存在多种方式。一个或多个概要集合存储在可搜索的数据结构中。一种方便的可搜索数据结构是散列表，其通过概要的模数来索引。可以使用另一散列函数。散列表的大小可以基于所需要的存储以及表中的散列之间的冲突的期望频率来选择。在冲突的情况下，创建链接至散列表的列表。备选地，以排序概要为代价，可以创建概要的反向索引。在多种实施方式中，针对每个单元将具有多个概要。对多个概要进行比较和评分的一种方法是创建具有与针对感兴趣的单元的任何概要相匹配的概要的所有单元的列表。在一些实施方式中，可以对该列表进行排列，例如将来自最新库的单元排在来自较老库的单元之前。使用候选单元的列表，在针对感兴趣的单元的所有概要与针对候选单元的概要之间进行比较。特别地，对于经排列的列表，当在针对感兴趣的单元的所有概要以及候选单元之一之间发现匹配时，比较可以终止。当不存在感兴趣的单元与任何候选单元之间的完全匹配时，可以对多个概要匹配应用某个阈值或者比率，它使得成对的单元被认为是类似的。备选地，在不存在完全匹配的情况下，可以对部分匹配进行等级排列，并且总结或者报告一个或多个部分匹配。

该方法的一个方面还包括在计算和存储概要之前，划分规范化形式的功能上重要的设计数据722与不重要的数据。当设计数据的改变将导致根据该设计数据生成的电路的改变时，该设计数据是功能上重要的。继而，所选择的用于计算概要的规范化形式的设计数据至少包括功能上重要的设计数据。

概要比较中的附加粒度可以通过如下方式来支持：按单元头部、接口和/或主体721、按层723以及按可排序/顺序相关数据724来划分单元内的设计数据。划分策略可以产生数据的物理或者逻辑划分。数据的物理划分包括将数据分为物理分离的组，诸如第一列表和第二列表。逻辑划分数据可以包括为数据添加标签或者标志，以使计算机将数据项识别为属于特定组。这些划分策略可以单独应用或者以任何组合来应用。解析712创建了一个或多个语法树532，其可以按照期望划分设计数据。针对某些划分策略，这包括定义如何组织语法树中的节点和分支。针对其他划分策略，这可以包括为语法树中的节点或者分支设置标志。标志如上文所述。计算和存储概要还包括针对每个划分产生至少一个概要。总结在根据不同划分类型产生的概要之间进行区分。

上述方法可以应用于比较使用不同的设计语言编码的文件。本公开描述的如何呈现可比较的两种语言是OASIS设计语言和GDSII设计语言。当比较这两种语言时，以上引用的第一文件和第二文件是OASIS和GDSII文件。当针对其他配对而开发等效方法时，其可以是两种其他语言。当比较不同设计语言的文件时，针对设计语言的规范化形式呈现了至少单元的主体中的可比较设计数据。备选地，针对在单元头部而不是在单元主体本身中表达的单元之间的功能性差异，规范化形式可以呈现至少单元头部中的可比较设计数据。

上述方法可以应用于相对于老单元设计库来评估新单元设计库。继而，第一文件是新单元设计库，而第二文件是老库。总结还包括报告通过比较两个库的概要而检测到的新库中的至少功能上重要的改变。

上述方法还可以应用于评估采用新库的影响。该方法的这种应用还应用于确定设计文件中的单元是否属于过期库。此应用还包括第三文件，向该第三文件应用标识、解析和计算动作。在该变体中，第一文件是设计文件，第二文件是至少一个单元设计的当前库，而第三文件是至少一个单元设计的过期库。总结包括报告设计文件中具有与当前库中的单元设计的概要不匹配、但是与过期库中的单元设计的概要相匹配的概要的单元。可选地，还可以报告不出现在当前库或者过期库的任何一个中的单元设计。此报告标准自然地消除了报告在当前库和过期库二者中相同的单元设计。虽然将本发明描述为比较当前和过期库，但是这些表述用于指示库的两种生成，并且可以仅简单地应用于尚未采用的候选版本(所谓的“当前版本”)以及生产版本(所谓的“过期版本”)。

上述方法的另一应用是标识不良的或者未被批准的单元。检测不良的或者未被批准的单元可以独立进行或者组合进行。上述方法可以应用于评估设计文件以确定设计文件中的单元是否属于已知不良单元的集。在此应用中，第一文件是设计文件，其与包含已知不良单元的文件进行比较。总结还包括报告设计文件中具有与已知不良单元的文件中的单元的概要相匹配的概要的单元。类似地，上述方法可以应用于评估设计文件以确定设计文件中的单元是否属于至少一个经批准的库。报告通常将在排除的基础上报告设计文件中具有与经批准的库中的单元的概要不匹配的概要的单元。可选地，当不存在设计文件中的单元与经批准的库中的任何单元的完全匹配时，可以报告部分匹配。

上述方法的进一步使用是检测具有不同单元名称的功能上相同的单元。第一文件是设计文件，而第二文件是至少一个经批准的库。计算和存储概要应用于设计文件和经批准的库的多个层中的至少功能上重要的数据。总结还包括将设计文件中具有与经批准的库中的概要相匹配的多个层中的功能上重要的数据的概要的单元(称为“功能上匹配的单元”)报告为重命名的单元，但是该重命名的单元具有与功能上匹配单元的单元名称不匹配的单元名称。可选地，该方法可以进行扩展，以反转设计文件中报告为“重命名”的单元，以具有匹配并且链接至经批准的库中的功能上匹配的单元的单元名称。

上述方法的一种感兴趣的使用是评估设计文件以确定是否从其担保的设计模板中修改了设计文件中的担保的单元或者其他单元。第一文件是设计文件，而第二文件是至少一个经批准的库。计算和存储概要应用于设计文件和经批准的库中的单元的多个层中的至少功能上重要的数据。总结还包括将设计文件中具有与经批准的库中的单元的概要相匹配的多个层中的一些但非全部层中的功能上重要的数据的概要的单元报告为潜在修改的单元。

上述方法的另一应用是扫描生产设计以找到生产设计中使用的使用费承担单元设计。在此应用中，第一文件包括使用费承担单元设计的一个或多个使用费承担库，而第二文件包括一个或多个包括单元设计的生产设计。总结还包括将生产设计中具有与使用费承担库中的单元的概要相匹配的概要的单元报告为潜在使用费承担特定单元。可选地，还可以报告近似匹配。近似匹配是应用于具有多个概要(诸如针对单元的多个层的概要)的单元或者设计单位的项。如果单元中的多数层具有匹配的概要，则这两个单元可以是近似匹配。

第二组实施方式是设备。这些是评估驻留在存储于计算机存储器中的至少两个文件中的设计数据之间的相似性和/或差异性的计算机设备。先前描述的图5提供了这些设备的某些方面的高层框图。与方法实施方式相同，该设备处理的设计数据可以是符号的或者二进制的。其可以在以上描述的任何设计语言或者格式中表达。其可以包括多边形。其可以是层级式的，包括对其他设计数据的引用，按照展开或者层级格式。预期广泛的设计数据。如上所述，对两个文件的引用是一般性的。两个文件可以是相同数据库的部分。可以涉及不止两个文件。

该设备包括至少一个处理器和存储器530、535。解析器531运行在处理器上，并且解析包含表示用于物理电路的设计的方面的设计数据的文件411，以及在存储器中创建一个或多个语法树532。在本说明书中，设备对设计内的单元进行操作，并且生成规范化单元概要。应当理解，更一般地，设备可以对数据的设计单位进行操作，并且在所附以及原始提交的权利要求的描述中，表述“设计单位”可以替换“单元”。

正则化器逻辑533运行在处理器上并且与解析器432协作，其组织语法树532以产生规范化形式。在短语“正则化器逻辑”中，逻辑的意思是控制计算机组件的操作的指令。在处理器上运行时，逻辑通常将是根据程序指令编译的对象代码。在处理器内，逻辑可以是微指令。在可编程逻辑组件(诸如，现场可编程门阵列(FPGA))中，逻辑可以由门以及门之间的连接来表示。在此应用中，逻辑告知计算机组件如何执行任务。正则化器逻辑包括划分模块，其将文件划分为至少一个头部，并且根据用于编码文件的设计语言的规则，将文件划分为设计数据的多个单元。划分模块组织语法树，以表示头部和单元划分。如以上所解释的，在各种设计语言中，文件可以包含头部数据、单元数据或者二者。为了清楚起见，设备应用于仅包含头部和单元数据其中一个的文件。

正则化器逻辑还包括规范化形成模块，其解释语法树以产生设计数据的规范化形式，其中规范化形式降低了数据分析对设计数据中的非功能性改变的敏感性。

该设备还包括运行在处理器上的概括器534，其计算概要并且将其存储在存储器415中，针对每个划分至少产生一个概要。

比较器模块536运行在处理器535上，并且比较规范化形式的概要。模块是实现特定任务的逻辑分段。例如，正则化器逻辑包括多个模块。也运行在处理器535上的报告器537总结比较概要的至少一些结果。报告器可以在存储器中产生总结473，诸如可用于其它程序的数据表，或者用户可查看的报告475。

存在可以构造解析器的多种方式。一个或多个概要集合存储在可搜索数据结构中。解析器的结构取决于可搜索数据结构。一种方便的数据结构是散列表，其通过概要的模数来索引。可以使用另一散列函数。散列表的大小可以基于所需要的存储以及表中的散列之间的冲突的期望频率来选择。在冲突的情况下，创建链接至散列表的列表。备选地，以排序概要为代价，可以创建概要的反向索引。在多个实施方式中，每个单元将有多个概要。对多个概要进行比较和评分的一种方法是创建具有与针对感兴趣的单元的任何概要相匹配的概要的所有单元的列表。在一些实施方式中，可以对该列表进行排列，例如将来自最新库的单元排在来自较老库的单元之前。使用候选单元的列表，在针对感兴趣的单元的所有概要与针对候选单元的概要之间进行比较。特别地，对于经排列的列表，当在针对感兴趣的单元的所有概要以及候选单元之一之间发现匹配时，比较可以终止。当不存在感兴趣的单元与任何候选单元之间的完全匹配时，可以针对多个概要匹配应用某个阈值或者比率，其使得成对的单元被认为是类似的。备选地，在不存在完全匹配的情况下，可以对部分匹配进行等级排列，并且总结或者报告一个或多个部分匹配。

在概括器计算和存储概要之前，划分模块还可以划分规范化形式的功能上重要的设计数据与不重要的数据。当设计数据的改变将导致根据该设计数据生成的电路的改变时，该设计数据是功能上重要的。继而，所选择的由概括器534处理以计算概要的规范化形式的设计数据至少包括功能上重要的设计数据。

概要比较中的附加粒度可以这样来支持：按单元头部、接口和/或主体、按层以及按可排序/顺序相关数据来划分单元内的设计数据而得到支持。划分策略可以单独应用或者以任何组合来应用。针对划分选项，解析器531创建一个或多个语法树532，其按照期望划分设计数据。针对某些划分策略，这包括如何组织语法树中的节点和分支。针对其他划分策略，这可以包括为语法树中的节点或者分支设置标志。计算和存储概要的概括器针对每个划分产生至少一个概要。报告器537在根据不同划分类型产生的概要之间进行区分。

该设备可以比较使用不同的设计语言编码的文件。本公开描述的如何呈现可比较的两种语言是OASIS设计语言和GDSII设计语言。当比较这两种语言时，以上引用的第一文件和第二文件是OASIS和GDSII文件。当针对其他配对而开发等效物时，其可以是两种其他语言。当比较不同设计语言的文件时，规范化形成模块产生针对呈现至少单元的主体中的可比较设计数据的设计语言的规范化形式。备选地，针对在单元头部而不是在单元主体本身中表达单元之间的功能性差异的设计语言，规范化形式可以呈现至少单元头部中的可比较设计数据。

上述设备可以应用于相对于老单元设计库来评估新单元设计库。继而，第一文件是新单元设计库，而第二文件是老库。报告器还报告通过比较两个库的概要而检测到的新库中的至少功能上重要的改变。

上述设备还可以应用于评估采用新库的影响。该设备的这种应用还应用于确定设计文件中的单元是否属于过期库。涉及三个文件。第一文件是设计文件，第二文件是至少一个单元设计的当前库，而第三文件是至少一个单元设计的过期库。报告器模块使用来自解析器的结果，并且报告设计文件中具有与当前库中的单元设计的概要不匹配、但是与过期库中的单元设计的概要相匹配的概要的单元。可选地，还可以报告不出现在当前库或者过期库的任何一个中的单元设计。此报告标准自然地消除了报告在当前库和过期库二者中相同的单元设计。虽然将本方法描述为比较当前和过期库，但是这些表述用于指示库的两种生成，并且可以相同地应用于尚未采用的候选版本(所谓的“当前版本”)以及生产版本(所谓的“过期版本”)。

上述设备的另一应用是标识不良的或者未被批准的单元。检测不良的或者未被批准的单元可以独立进行或者组合进行。该设备可以应用于评估设计文件以确定设计文件中的单元是否属于已知不良单元的集。在此应用中，第一文件是设计文件，其与包含已知不良单元的文件进行比较。报告器模块总结设计文件中具有与已知不良单元的文件中的单元的概要相匹配的概要的单元。类似地，上述设备可以应用于评估设计文件以确定设计文件中的单元是否属于至少一个经批准的库。同样，第一文件是设计文件，其与至少一个经批准的库进行比较。报告器模块通常将在排除的基础上报告设计文件中具有与经批准的库中的单元的概要不匹配的概要的单元。可选地，当不存在设计文件中的单元与经批准的库中的任何单元的完全匹配时，可以报告部分匹配。

上述设备的进一步使用是检测具有不同单元名称的功能上相同的单元。针对该使用的划分模块进一步通过单元内的层来划分文件，并且组织语法树以反映该层。第一文件是设计文件，而第二文件是至少一个经批准的库。概括器计算和存储概要，其反应设计文件和经批准的库的多个层中的至少功能上重要的数据。报告器模块还将设计文件中具有与经批准的库中的概要相匹配的多个层中的功能上重要的数据的概要的单元(称为“功能上匹配的单元”)总结为“重命名”的单元，但是该重命名的单元具有与功能上匹配的单元的单元名称不匹配的单元名称。可选地，该方法可以进行扩展，以翻转设计文件中报告为“重命名”的单元，以具有匹配并且链接至经批准的库中的功能上匹配的单元的单元名称。

上述设备的一种感兴趣的使用是评估设计文件以确定是否从其担保的设计模板中修改了设计文件中的担保的单元或者其他单元。第一文件是设计文件，而第二文件是至少一个经批准的库。概括器计算和存储设计文件和经批准的库中的单元的多个层中的至少功能上重要的数据的概要。报告器还将设计文件中具有与经批准的库中的单元的概要相匹配的多个层中的一些但非全部层中的功能上重要的数据的概要的单元总结为潜在修改的单元。

上述设备的另一应用是扫描生产设计以找到生产设计中使用的使用费承担单元设计。在此应用中，第一文件包括使用费承担单元设计的一个或多个使用费承担库，而第二文件包括一个或多个包括单元设计的生产设计。报告器还将生产设计中具有与使用费承担库中的单元的概要相匹配的概要的单元总结为潜在使用费承担特定单元。可选地，还可以报告近似匹配。

第三组实施方式是制品，与案例In re Beauregard一致但不限于此。在一个实施方式中，这些制品包括存储有程序代码的计算机可读存储介质，该程序代码用于实现以上描述的任何方法实施方式。程序代码当在处理器上运行时，使得处理器执行以上所述的动作。在第二实施方式中，这些制品包括存储有程序代码的计算机可读存储介质，该程序代码当与处理器和存储器相结合时，创建以上描述的任何设备。当与处理器和存储器相结合时，程序代码包括以上所述的模块。