專利名稱：用于針對生產(chǎn)工作流的芯片設計中的單元完整性、改變和起點的獨立評估的方法和設備的制作方法
用于針對生產(chǎn)工作流的芯片設計中的單元完整性、改變和 起點的獨立評估的方法和設備相關申請本申請要求所提交的美國專利臨時申請?zhí)?1/131，601以及美國專利臨時申請?zhí)?61/180,715的權益。通過引用并入在前申請。
背景技術：
所公開的技術涉及用于準備芯片設計以用于制造的設計數(shù)據(jù)的粒度分析，并且涉 及標識設計數(shù)據(jù)文件的各部分之間的相似性和差異性。具體地，所公開的技術涉及解析數(shù) 據(jù)并且將其組織為規(guī)范化形式、概括規(guī)范化形式、以及把來自不同源(諸如芯片級設計和 設計模板庫)的設計數(shù)據(jù)的概要進行比較。將設計數(shù)據(jù)組織為規(guī)范化形式通常會降低數(shù)據(jù) 分析對于對設計沒有功能性影響的數(shù)據(jù)改變的敏感性。粒度分析的細節(jié)隨表示設計方面的 設計語言以及數(shù)據(jù)文件格式而有所不同。根據(jù)期望的分析和設計語言，粒度分析可以包括 通過以下各項來劃分和報告設計文件頭部/單元部分、對注釋的獨立處理、功能上重要的 /不重要的數(shù)據(jù)、空白/非空白以及設計數(shù)據(jù)單元內(nèi)的層。感興趣的相似性和差異性取決于 粒度分析的目的。比較按照多種方式都是有用的。集成電路的設計是這樣的迭代過程，其涉及成千上萬的單元和塊視圖、偽像及其 依賴關系。視圖、偽像及其依賴關系表示集成電路的開發(fā)功能、電氣和物理狀態(tài)。單元和塊以不同的速率經(jīng)歷設計過程，該過程從設計模板供應商的發(fā)布和內(nèi)部單 元級開發(fā)開始，并且在多個發(fā)布或者迭代中循環(huán)。在最好的情況下，跟蹤塊、庫、單元和偽像 的最新版本也是困難的。例如，當某人在使用特定設計模板的產(chǎn)品中發(fā)現(xiàn)出產(chǎn)問題時，公司 將難于確定哪些其他項目使用了該設計模板。到處都存在使用陳舊的單元或者庫的可能性。設計工具具有其自己的配置文件， 并且機器具有其自己的搜索路徑和盤安裝點。設計或者流片(tapeout)團隊可能無法找到 過期的文件或者鏈接，直到從制造中返回有問題的設計。復合的多級設計帶來了新的問題。凍結塊(其是由設計團隊試驗性完成的)可能 正在使用庫單元的過期版本。此外，設計者可能通過簡單地對單元進行重命名而避免與另 一設計者的單元的名稱沖突，而沒有驗證這兩個單元是否相同。對單元進行重命名將其與 將來的庫更新和單元跟蹤機制分離。設計者已經(jīng)對供應商提供的設計模板做出了未授權修改，這導致了生產(chǎn)期間的失 效，并且潛在地使否則從設計模板供應商可得的擔保無效。例如，設計者可能認為修改將改 善模板的性能或者功能，但是僅發(fā)現(xiàn)產(chǎn)生了相反結果，諸如生產(chǎn)中的失效。另外，第三方供 應商不擔保對其設計模板的修改。如果發(fā)生類似的事情，則將難以確定原因以及標識誰負
有責任。當設計準備發(fā)布到生產(chǎn)時，其可能多達40，000個獨特的單元。由于目前的設計復 雜度，很有可能用于準備設計的一些庫單元不是最新的。流片團隊無法肯定地確定其將要 向掩膜車間發(fā)送的設計中的單元是否表示最新的可用版本。目前無法確保流片候選使用所
9有的最新數(shù)據(jù)，也無法確保沒有人對已鑒定的布局做出未授權修改。在集成電路的設計期間跟蹤單元數(shù)據(jù)的已知方式跟蹤包含單元集的數(shù)據(jù)文件。為 了找到文件內(nèi)的單元改變，設計者通常使用區(qū)分工具來進行上百萬行數(shù)據(jù)的手動分析。運 行差異性檢查跨設計語言或者數(shù)據(jù)文件格式是無效的，因為區(qū)分工具通常執(zhí)行文本匹配， 而不考慮用于表示設計的設計語言或者數(shù)據(jù)類型。區(qū)分程序通常減去文件之間的差異，而 不會分析改變對于正在生產(chǎn)的芯片是否具有功能性影響，或者其是否重要。區(qū)分工具對于 兩種二進制數(shù)據(jù)文件尤其困難。明確包括區(qū)分工具的設計工具的示例包括ClearCase、DesignSync和IC Manage, 其由其相應的銷售商在 http://www-01. ibm. com/software/rational/、http://www. icmanage. com和http://WWW. 3ds. com處描述。因為此類工具在文件級而不是單元級操作， 所以使用區(qū)分工具的設計者實際上需要將需要進行比較的兩個代碼段提取到新文件中，并 且直接比較該文件?；蛘?，設計者可以依賴于文件元數(shù)據(jù)，其中另一設計者保持了關于設計 工作的過程的記錄。這些方式都不夠魯棒或高效。一些設計模板供應商為其模板添加標簽。該標簽將模板相對于可能不是其集成電 路設計一部分的其他設計模板標識為“他們的”。標簽可以用于對設計中使用的設計模板的 實例進行計數(shù)，繼而模板的用戶基于實例的數(shù)目來支付使用費。對于該添加標簽方法的使 用的行業(yè)標準方式由VSI Alliance 維護。2009年5月21日在http://www. vsi. org/docs/ IPP_Tagging_Std% 201_30· pdf 處訪問的、標題為 “Virtual Component Identification Physical Tagging Mandard”的標準版本2. 0描述了使用添加標簽方法的方式。該標準 描述了要嵌入在⑶SII文本或者注釋行中的文本標簽。VSI聯(lián)盟包括IBM、Intel, ARM, Freescale Semiconductor、TSMC等。第三方IP供應商已經(jīng)開發(fā)了一種掃描儀，其可以在 標簽依然是設計模板數(shù)據(jù)的一部分的情況下檢測并且報告設計模板。如果標簽以某種方式 被移除或者混淆，設計模板的所有者將不會在使用費方面得到補償。出現(xiàn)了開發(fā)用于設計數(shù)據(jù)分析的新工具的機會，該新工具促進設計工作流中的各 交接點處的設計數(shù)據(jù)的粒度評估。比較好的是，可以產(chǎn)生較少的錯誤、更加彈性和透明的工 作流以及產(chǎn)生的生產(chǎn)設計。

發(fā)明內(nèi)容
所公開的技術涉及對用于準備芯片設計以用于制造的設計數(shù)據(jù)粒度分析，以及設 計數(shù)據(jù)文件各部分之間的相似性和差異性標識。特別地，其涉及解析數(shù)據(jù)并且將其組織為 規(guī)范化形式、概括規(guī)范化形式，以及將來自不同起點(諸如芯片級設計和設計模板庫)的設 計數(shù)據(jù)的概要進行比較。將設計數(shù)據(jù)組織為規(guī)范化形式通常會降低數(shù)據(jù)分析針對對設計沒 有功能性影響的數(shù)據(jù)改變的敏感性。粒度分析的細節(jié)在用于表示設計方面的各設計語言之 間有所不同。根據(jù)期望分析和設計語言，粒度分析可以包括通過下述來劃分文件頭部/單 元部分，對注釋的獨立處理，功能上重要的/不重要的數(shù)據(jù)，空白/非空白以及設計數(shù)據(jù)單 元內(nèi)的層。感興趣的相似性和差異性取決于粒度分析的目的。比較按照多種方式都是有用 的。本發(fā)明的特定方面在權利要求、說明書和附圖中進行描述。


圖1示出了高層集成電路設計環(huán)境。圖2示出了與圖1中的框相關聯(lián)的版本擴展和某些文件格式。圖3示出了設計過程中的交接點，所公開的技術可以有效地應用該交接點處。圖4繪出了概括多個數(shù)據(jù)文件的部分的規(guī)范化表示的評估器。圖5中示出了通過處理包含設計數(shù)據(jù)的文件來生成規(guī)范化單元概要或者設計單 元概要。圖6和圖7提供了這些方法的某些方面的高層流程圖。圖8A-圖8D示出了 Liberty文件中的可能頭部和單元語句的采樣。圖9是Verilog的帶注解示例。圖IOA-圖IOB示出了帶注解的樣本VHDL文件。圖11是帶注解的樣本OASIS 文件。圖12是帶注解的樣本⑶SII文件。圖13是SPICE文件的帶注解版本。圖14是帶注解的樣本LEF。圖15是DEF的帶注解版本。圖16是結構化文本文件的帶注解版本。圖17A-圖17B是用戶解析文件的帶注解示例。
具體實施例方式參考附圖進行下文的詳細描述。描述了優(yōu)選的實施方式以示出本發(fā)明，而不限制 其范圍，該范圍由權利要求限定。本領域技術人員將認識到關于下文描述的多種等效變體。鍵集成電路設計的環(huán)境電路設計的環(huán)境比以上背景技術部分中的描述呈現(xiàn)了更多針對改進的挑戰(zhàn)和機 會。成功的集成電路(IC)流片需要IC設計的單元和塊是正確的。使用電路的錯誤版本 (不管是具有少量晶體管的葉單元還是較大層級設計塊)可能花費上百萬美元以及數(shù)月的 延遲。芯片級設計管理系統(tǒng)、后邏輯綜合、基于跟蹤文件的設計數(shù)據(jù)集單元、單元的版 本、塊、和芯片級設計塊。設計數(shù)據(jù)管理系統(tǒng)可能無法有效地確定或者總結文件內(nèi)的給定單 元和塊數(shù)據(jù)集中的什么發(fā)生了改變。芯片級設計數(shù)據(jù)管理系統(tǒng)在該粒度層無法跟蹤，因為 單元和塊以及芯片級設計塊是由不同的設計工具和不同的設計工具版本創(chuàng)建的，并且使用 不同的設計語言和數(shù)據(jù)文件格式來表示。在復雜的SOC設計中，設計塊可以來自使用不同 設計工具和工具版本的不同設計組。目前設計管理工具中察覺的缺陷使它們無法用于評估 單元級的單元等效性或者報告單個單元內(nèi)發(fā)生了什么改變?，F(xiàn)有的設計數(shù)據(jù)管理工具不在文本數(shù)據(jù)和對象數(shù)據(jù)之間進行區(qū)分，并且不對數(shù)據(jù) 進行排序或者以其他方式產(chǎn)生設計數(shù)據(jù)的規(guī)范化表示。轉(zhuǎn)而，其缺少審核能力，而這種審核 能力對于對以下感興趣的項目管理者是有用的驗證IC設計中的單元是否是最新的經(jīng)批 準版本，確保單元沒有進行不適當?shù)目截惢蛘邔?，或者確定所提出的單元設計更新在接近流片的設計中是否是不可用的。另外，設計數(shù)據(jù)管理系統(tǒng)不提供驗證發(fā)布到掩膜車間的最終⑶SII或者OASIS 文 件的方式。其全部假設利用足夠嚴格的控制，“偏離”的布局不會進入最終設計中。單元和塊作為設計單位芯片設計大量使用單元，這些單元被分組到塊中。單元與有時被稱為單元“視圖” 的數(shù)據(jù)文件集合相關聯(lián)。單元視圖包含單元的功能或者物理表示。通常，存在表示諸如 SPICE,Extracted Netlist.GDSII,Liberty,Vital 和 / 或 LEF 的設計語言的設計數(shù)據(jù)的兩 個或者更多單元視圖。不同的電子設計自動化(EDA)工具對其包含的不同視圖和數(shù)據(jù)進行 操作。一些工具操作詳細的多邊形數(shù)據(jù)，而其他工具僅利用簡化的多邊形表示來工作。性 能估計工具完全不利用多邊形工作，其使用定時信息。如果各種工具使用單元視圖的版本 不一致，則基本上存在使用該單元的設計將失效的風險。芯片級設計塊可以包括單元的若干單元塊。單元塊可以包含對單元以及包含其他 單元的子塊等的引用。引用可以是嵌套的。當芯片被制造時，對單元的引用最終被展開。在 設計過程期間，使用引用極大地減小了表示設計所需要的存儲器量和盤空間。芯片上的存 儲器區(qū)域例如將包含一個或多個核(core)比特單元、讀取和寫入比特單元的行和列單元 以及引用核比特單元、行單元和列單元的頂層單元的定義。65，536比特存儲器(“64K比 特存儲器”)將通常具有被引用65，536次的1比特單元定義；被引用256次的兩個列驅(qū) 動器或者感測單元定義(頂層或底層)；被引用256次的兩個行驅(qū)動器或者感測單元定義； 以及分類(assorted)解碼電路。層級設計可以進一步減少引用的數(shù)目；存儲器的行可以被 定義為包含對左和右行單元的引用加上對核比特單元的256次引用，繼而該行可以被引用 256次。可以使用少于1，000次嵌套引用來代替65，536次單元引用。當制造掩膜(用于在芯片上制造單元的工具)或者使用直接寫入時，單元引用被 展開。在以上的存儲器示例中，不管單元層級如何指定，都將存在從單個原始單元拷貝的、 印刷在晶片上的65，536個核比特單元。在展開之前，設計數(shù)據(jù)文件可具有數(shù)十吉字節(jié)的大 ?。辉谡归_之后，文件可能增大多倍。僅有少數(shù)工具需要利用完全展開的數(shù)據(jù)來工作，這種 工具包括表示掩膜數(shù)據(jù)準備軟件工作站并且可能包括檢查芯片設計中的設計規(guī)則違背的 規(guī)則檢查系統(tǒng)。一些視圖使用在單個文件內(nèi)提供多個“單元”的文件格式。這增加了另一維度的 復雜度這些格式之一中的文件版本取決于其內(nèi)部所有單元的版本。諸如處理器核的復合設計模板傾向于具有多種相關聯(lián)的產(chǎn)品。通常，產(chǎn)品存儲在 單獨的文件中。這些文件可以是針對邏輯綜合的性能約束文件、針對仿真的行為描述文件 或者來自由單元構造的工具的日志文件。假設將所有這些文件與單元的主布局和定時視圖 進行同步。更詳細地，一些單元視圖可以改變，即使在那些單元的表示或者物理布局(例如， 布局)尚未改變時。例如，如果對代工廠處的制造工藝進行改變，或者簡單地因為關于來自 代工廠的產(chǎn)品的平均性能的更多信息變得可用，定時模型可以改變。規(guī)范化單元概要(“(XD”)和規(guī)范化設計單位概要(“⑶UD”)如何工作規(guī)范化單元概要(更一般地，規(guī)范化設計單位概要)是將在IC設計過程中有用的 新工具的輸出。本文檔中公開的規(guī)范化概括工具針對公用EDA文件格式生成針對文件的、逐單元和逐層的概要，并且可以擴展至其他文件格式。這些工具可以區(qū)分諸如空白或者注 釋修改的不重要改變和諸如對單元的新接口的主要改變。其允許單元與版本化單元概要儲 存庫的匹配，用以檢測未測試單元、陳舊單元、單元的改變或者不同名稱下的單元拷貝的未 授權使用。在高層處，圖4繪出了概括415、435、455多個數(shù)據(jù)文件411、431、451的部分的 規(guī)范化表示的評估器433。將表示兩個或更多文件的概要進行比較。在此上下文中，出于專 利目的，一般性地使用術語“文件”，因為兩個數(shù)據(jù)文件可能存儲在單個數(shù)據(jù)庫中。在設計行 業(yè)內(nèi)，設計文件通常存儲在文件層級中，諸如Windows或者Linux文件系統(tǒng)。評估器433將 概要進行比較，并且生成針對特定目的而感興趣的概要相似性和/或差異性的總結473或 者報告475。通過處理包含設計數(shù)據(jù)的文件411來生成規(guī)范化單元概要或者設計單位概要，如 圖5所示。該設計數(shù)據(jù)最終有助于物理電路(也稱為集成電路或者芯片)的生產(chǎn)。在一個 實施方式中，在處理器530上運行的解析器531、與解析器協(xié)作運行的規(guī)范化器邏輯533以 及在處理器上運行的概括器534生成存儲在存儲器415上的規(guī)范化單元概要和語法樹532。 單元概要的規(guī)范化組織取決于所解析的設計語言。這些處理器為每個單元生成至少一個概 要。概要例如可以是從解析器和規(guī)范化器邏輯的規(guī)范化輸出生成的32或者64比特代碼。 多種散列函數(shù)可以用于創(chuàng)建概要，諸如CRC、MD5等。概括器可以為單元的頭部和主體部分 生成獨立的概要，并且由單元內(nèi)的層生成概要。注釋、空白和功能上重要的數(shù)據(jù)可以獨立地 進行概括。概要可以永久存儲以便以后使用。例如，可以生成經(jīng)批準的庫的概要，并且將其 存儲以便與設計項目的概要進行重復比較。規(guī)范化概要的比較是允許用戶理解較大文件中設計元件之間的細小差異的有效 工具。如上所述，設計文件(尤其是包含二進制多邊形數(shù)據(jù)的文件)可能是龐大的。設計 文件中包含數(shù)百乃至數(shù)千的單元(或者更多，例如利用大型存儲器)。對于如此眾多的數(shù) 據(jù)，假警報是一個實際問題。規(guī)范化單元概要的一種使用是基于所檢測的改變的功能重要 性并且有時基于其在設計過程中的源來標識所檢測的改變并且允許對其進行過濾。運行在處理器535上的比較器536和運行在處理器上的報告器537對概括器5；34 存儲在存儲器415中的概要進行操作。通常，比較兩組或三組文件411。為簡便起見，將文 件組稱為“文件”，并且期望讀者理解所比較的文件的實際數(shù)目是任意的。“兩個文件”意味 著兩個或更多文件。兩個文件可以表示舊單元庫和新單元庫。三個文件可以是設計文件、 已批準的單元庫和被拒絕的單元設計集，其中如果被拒絕的單元設計被用于生產(chǎn)，則將導 致失效。比較器針對一個或多個其他文件的概要來檢查針對一個文件的概要。報告器響應 于過濾標準來報告各文件中的單元之間的匹配、近似匹配或者一個文件中的單元沒有出現(xiàn) 在其他文件中。這些報告可以被總結至存儲器473(諸如另一程序可以處理的其他中間格 式或者數(shù)據(jù)庫)，或者人類操作者在顯示器或者紙張上可查看的報告475。比較文件以產(chǎn)生 有用的報告存在多種使用情況。此技術的一些用例是 理解更新單元設計庫·評估更新單元庫對過程中設計的影響 在布局和布線之前、在流片之前以及在其他設計里程碑處，找到設計數(shù)據(jù)中未 被批準的單元和/或不良單元
13
標識設計數(shù)據(jù)中重命名的單元，并且驗證其與經(jīng)批準的單元模板相匹配 檢測危害提供模板的供應商的擔保的單元修改 對生產(chǎn)設計中針對其應付使用費的單元數(shù)目進行計數(shù) 根據(jù)這些用例，應當能夠看出所公開的規(guī)范化概要作為用于電路設計者的工具 如何有效。原型規(guī)范化概括工具處理以下主要的已公布EDA設計數(shù)據(jù)格式，并且可以容易地 擴展至其他格式· 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)子電路網(wǎng) 表文件# Cadence Library Exchange Format (LEF)布局描述文件# Cadence Design Exchange Format (DEF)設計描述文件· “結構化文本”腳本編寫和控制文件 非結構化(任意或者未知格式)文本文件 非結構化(未知格式)二進制文件該工具還提供用于計算針對專有數(shù)據(jù)格式(“用戶解析的”文件)的規(guī)范化單元 概要的應用編程接口(API)。運行在處理器上的解析器標識文件內(nèi)的重要設計對象，并且生 成針對單元、與單元的接口、單元主體和任何單元外部的文件頭部數(shù)據(jù)的概要。對單元內(nèi)或者文件頭部中的注釋獨立地進行標記，使得可以僅標識注釋中的改 變。文件頭部、單元接口以及單元主體內(nèi)的數(shù)目在適當?shù)臅r候由層進一步分離，使得對個體 層的改變較明顯。當文件格式內(nèi)的數(shù)據(jù)與順序無關時，則請求進行排序，規(guī)范化單元概括工 具僅對順序無關的數(shù)據(jù)進行排序，而使順序相關數(shù)據(jù)保留其原始順序。概要計算基礎可以對其應用規(guī)范化單元概要的設計數(shù)據(jù)文件內(nèi)的三個通常的對象類是文件、文 件頭部和單元。文件級概要可以根據(jù)文件中的所有數(shù)據(jù)來計算。規(guī)范化單元概要是針對單 元或者文件模塊的、規(guī)范化重組數(shù)據(jù)的概要。規(guī)范化文件頭部概要是不在任何單元或者模 塊中的、規(guī)范化重組數(shù)據(jù)的概要。根據(jù)設計語言或數(shù)據(jù)文件格式或者根據(jù)用戶選擇的選項， 在生成概要之前應用更多或者更少的重組。在本公開中，“規(guī)范化設計單位概要”統(tǒng)指應用 于文件頭部和單元數(shù)據(jù)的概要。在所提供的多個示例中，將會看到即使在僅具有一個或其 他數(shù)據(jù)種類的格式中，文件中的設計數(shù)據(jù)通常也可以作為頭部或者單元數(shù)據(jù)來處理。規(guī)范化單元概要可以涉及針對單元的部分計算的多個概要注釋數(shù)據(jù)、層數(shù)據(jù)和 非層數(shù)據(jù)。注釋數(shù)據(jù)是由規(guī)范針對給定文件格式確定的非功能性數(shù)據(jù)(通常是文本)。對 于多數(shù)格式，注釋概要中的改變可以忽略。層數(shù)據(jù)具有不同的層名稱或者序號(諸如第一 層金屬或者多晶硅)，其對于讀取文件的工具是有意義的。非層數(shù)據(jù)表示不具有層序號的對象(諸如GDSII或者OASIS 中的單元布局(實例化))，或者沒有由層序號劃分的文件中 的對象。層數(shù)據(jù)進一步被分為幾何數(shù)據(jù)和非幾何數(shù)據(jù)。GDSII和OASIS 文件具有不是幾何 數(shù)據(jù)的文本和節(jié)點名稱記錄，但是仍然具有層序號。對節(jié)點和文本信息的改變未必與對幾何 數(shù)據(jù)(諸如路徑或者多邊形)的改變一樣重要，所以節(jié)點和文本概要單獨記錄。用戶可以選 擇利用具有與幾何數(shù)據(jù)相同的重要性來處理節(jié)點和文本數(shù)據(jù)，但是這樣做不是必須的。文件和概要的組織為了概要計算這一目的，文件最通常包括可選頭部以及零個或者多個單元。在文 件頭部(如果單元之間的文本不清楚地屬于單元則其可以包括該文本，諸如當單元具有不 同的端記錄時)內(nèi)，諸如當文件格式不具有層名稱或者序號時，存在在指定的層上或者明 確地報告為“非層數(shù)據(jù)”的注釋加頭部數(shù)據(jù)。單元具有可選接口、可選主體和可選注釋。這三類中的至少一個將出現(xiàn)在單元中。 單元接口數(shù)據(jù)在命名的層上，或者是序號，或者可以將其明確地報告為“非層數(shù)據(jù)”。單元主體數(shù)據(jù)在命名或者編序的層上，或者其被明確而地報告為“非層數(shù)據(jù)”。單 元主體(但是在本實現(xiàn)中，不能是單元接口或者文件頭部)可以具有“非幾何數(shù)據(jù)”，對幾何 數(shù)據(jù)格式而言，它是不指定多邊形、矩形、線形等的信息。通常，非幾何數(shù)據(jù)將是特性和文本 記錄(例如，在⑶SII或者OASIS 文件中)。如果數(shù)據(jù)格式不是幾何的(例如，Liberty定 時模型)，則即使所有的數(shù)據(jù)沒有記錄在調(diào)用方期望知道的該類中，所有的數(shù)據(jù)也都是非幾 何的。通常這是顯然的，因為所有的數(shù)據(jù)將是“非層”的。這是一種實現(xiàn)決策，而并不是本 發(fā)明的關鍵。作為示例，報告可以具有一般或者詳細的類別。一般類型的一個示例如下文件文件頭部注釋文件頭部非層文件頭部層...單元...單元單元注釋單元接口非層單元接口層...單元主體非層單元主體層...單元主體非幾何非層單元主體非幾何層...較詳細類別的一個示例如下文件文件文件非空白文件空白
文件頭部(未排序不充足存儲器)文件頭部(沒有請求排序)文件頭部注釋文件頭部非層數(shù)據(jù)((-1)文件頭部逐層單元單元(排序)單元(未排序不充足存儲器)單元(沒有請求排序)不具有注釋的單元單元注釋單元接口包括文件頭部的單元接口排除文件頭部的單元接口單元接口非層數(shù)據(jù)(-1)單元接口逐層單元主體非層數(shù)據(jù)(-1)單元主體逐層幾何單元主體逐層非幾何GDSII 示例作為一個示例，考慮命令行規(guī)范化概括工具針對較小GDSII文件生成的概要報
生 I=I File “ testfiles/sigtest. gds〃 :GDS formatArguments -grid le_9 -mem 64 -nosortdb7be73c File(none) File non-Whitespace(none) File WhitespaceFile Header (not sorted)8f078078 File Header with Comments3289c53f File Header without Commentsbd8e4547 File Header Comments3289c53f File Header non-LayerCell " Structure_l" (not sorted)a7100492Cellwith Comments3d4d7fbfCellwithout Comments9a5d7b2dCellComments7b78aab4CellBody non-Layer15546763CellBody Layer 3fda35715CellBody Layer 42
aec2e57d Cell Body non-Geometric Data Layer 3
Cell " Structure_2" (not sorted)
cd2bl35dCellwith Comments
d2c6cl50Cellwithout Comments
lfedd20dCellComments
0f4c0817 Cell Body Layer 1
d4133b6c Cell Body Layer 19
0999f22b Cell Body non-Geometric Data Layer 5
Cell " Structure_3" (not sorted ；hierarchical)
a7100492Cellwith Comments
3d4d7fbfCellwithout Comments
9a5d7b2dCellComments
7b78aab4CellBody non-Layer
15546763CellBody Layer 3
fda35715CellBody Layer 42
aec2e57dCellBody non-Geometric Data Layer 3
Cell " Structure_4" (not sorted ；hierarchical)
70262033Cellwith Comments
5242eaclCellwithout Comments
2264caf2CellComments
7b78aab4CellBody non-Layer
7a5bf21dCellBody Layer 3
fda35715CellBody Layer 42
aec2e57dCellBody non-Geometric Data Layer 3
參考文件testfiles/sigtest. gds的處理生成32比特文件級概要db7be73c (十六進制)。當針對整個文件的概要存儲在概要儲存庫中時，可以使用該概要來快速確定從最后
處理概要并將其存儲在儲存庫中之后，是否對文件進行了任何改變。⑶SII是二進制文件格式。包含二進制數(shù)據(jù)的文件不包含空白，因此不報告空白 的概要和非空白概要。在適當時，非空白概要可被報告為確定對數(shù)據(jù)文件的改變是否僅源 自空白中的改變的方式。文件內(nèi)的符號(文本)通常由空白(空格字符、制表符或者換行 符)分開，并且通?？瞻椎牧坎淮蟆榱藥椭_定是否進行了對符號數(shù)據(jù)的改變，原型規(guī)范 化概括工具計算針對文件中所有空白字符以及針對文件中所有非空白字符的概要。注意， 空白概要逐字節(jié)地捕獲空白的量，而與其位置無關。例如，將針對兩個字符串“abc def”和 "abed ef”報告相同的空白(使用單個空格字符)和非空白概要。⑶SII文件中的多數(shù)數(shù)據(jù)在單元(⑶SII命名法中的“結構”)內(nèi)，但是任何單元的 外部都存在一些記錄。該數(shù)據(jù)在文件頭部概要中進行概括。該頭部數(shù)據(jù)可以由類型劃分為 文件頭部注釋或者文件頭部非層數(shù)據(jù)；沒有為GDSII文件頭部內(nèi)的數(shù)據(jù)指派層序號。下文 描述GDSII數(shù)據(jù)的解釋和記錄的細節(jié)。為了 一致性，可以使用公用報告格式或者概要可以保存在數(shù)據(jù)庫中。在該示例中，當針對某個概要類型沒有記錄數(shù)據(jù)時，則打印詞語“(無)”來代替該概要。在報告內(nèi)的文 件概要塊中示出了這樣的兩個示例。合成文件頭部概要與個體文件頭部概要一起記錄。為了用戶方便，其由命令行工 具來計算；在一個實施方式中，其僅是個體文件頭部規(guī)范化單元概要的異或(XOR)。也可在 計算單元概要的相同時間計算合成文件頭部概要。合成文件頭部概要可以用于幫助檢測文 件頭部數(shù)據(jù)中的改變。個體單元概要塊出現(xiàn)在文件頭部概要塊之下。如圖所示，單元概要包括注釋概要、 針對層和非層數(shù)據(jù)的幾何概要、針對層和非層數(shù)據(jù)的非幾何概要，以及針對具有和不具有 注釋的合成單元概要。由于具有合成文件頭部概要，在一個實施方式中，合成單元概要通過 與其他單元概要異或而生成。其可以用于幫助檢測單元數(shù)據(jù)中的改變。針對上述GDSII文件的概要在未對數(shù)據(jù)進行排序的情況下生成。這在文件名下方 打印的程序參量列表中與概要的塊一起進行報告。單元Structure_3和Structure_4是層級的，這意味著它們具有對其中的其他單 元的SREF或者AREF引用。一般而言，在設計數(shù)據(jù)庫層級中較高的、針對布局和布線單元以 及其他單元的概要將比針對其引用的葉單元的概要更頻繁地改變。改變的單元是否是葉單 元這一知識可以幫助確定概要改變的重要性?？紤]針對單元Structure」和Structure_3的規(guī)范化單元概要，可以看到針對這 些單元的所有概要是相同的。這指示了針對這兩個單元的多邊形和結構(單元)引用數(shù)據(jù) 相匹配。針對Structure_2和Structure_4的概要與針對任何其他單元的概要不匹配。如果請求了排序，則針對單元的某些部分生成不同的概要File ‘‘ testfiles/sigtest. gds" :GDS formatArguments -grid le_9 -mem 64 -sortdb7be73c File(none) File non-ffhitespace(none) File WhitespaceFile Header (sorted)8f078078 File Header with Comments3289c53f File Header without Commentsbd8e4547 File Header Comments3289c53f File Header non-LayerCell " Structure」" (sorted)a7100492 Cell with Comments3d4d7fbf Cell without Comments9a5d7b2d Cell Comments7b78aab4 Cell Body non-Layer15546763 Cell Body Layer 3fda35715 Cell Body Layer 42aec2e57d Cell Body non-Geometric Data Layer 3Cell “ Structure_2〃 (sorted)
cd2b135d Cell with Comments
d2c6c150 Cell without Comments
lfedd20d Cel l Comments
0f4c0817 Cell Body Layer l
d4133b6c Cel l Body Layer 19
0999f22b Cel l Body non—GeometriC Data Layer 5
Cell”Structure 3” (sortedhierarchical)
a7100492 Cell with Comments
3d4d7fbf Cel l without Comments
9a5d7b2d Cel l Comments
7b78aab4 Ce l l Body non—Layer
15546763 Cell Body Layer 3
fda35715 Cell Body Layer 42
aec2e57d Cel l Body non—GeometriC Data Layer 3
Cell”Structure 4” (sortedhierarchical)
lf29b54d Cel l with Comments
3d4d7fbf Cel l without Comments
2264caf2 Cel l Comments
7b78aab4 Ce l l Body non—Layer
l 5546763 Ce l l Body Layer 3
fda35715 Cell Body Layer 42
]aec2e57d Cell Body non—GeometriC Data Layer 3
在解析之前從文件數(shù)據(jù)產(chǎn)生的文件級概要沒有受到排序的影響。文件頭部概要塊也沒有改變，因為GDSI工文件頭部數(shù)據(jù)是順序相關的并因此是未排序的。多個單元元素概要被改變，因為該數(shù)據(jù)通過排序而被重新排列。針對單元Structure一4中的單元主體層3和42的規(guī)范化單元概要現(xiàn)在與Structure一1和Structure一3的規(guī)范化單元概要相匹配。這示出了Structure 4是與Structure l和Structure 3相同的層。
針對某些格式(例如，GDSI工和OASIS⑧)，排序?qū)τ诟乓ヅ涫欠浅Ｓ杏玫?，以至于應當將其作為默認行為。工C設計文件中的多數(shù)單元是較小的，所以僅存在受限的運行時影響。
如果請求64比特概要，在沒有排序的情況下，報告的摘錄將是
Fi le”testfi les／sigtest．gds”GDS format
Arguments一grid le一9一mem 64一nosort
3670dle4a8c8c74b Fi le
(none)Fi le non—Whitespace
(none)Fi le Whitespace
Fi l e Header(not sorted)
026a2a5boleOf6ec File Header with Comments
fd352337a1644620 Fi le Header without Comments
ff5f096ca084b0ccFileHeader Comments
fd352337al644620FileHeader non-Layer
Cell " Structure_l“(not sorted)
41a9962cc923db00Cellwith Comments
a9a2dl241367de40Cellwithout Comments
e80b4708da440540CellComments
bb89d94bb8544e78CellBody non-Layer
b9ef42b48f65e40dCellBody Layer 3
el6d5f5cf714adc4CellBody Layer 42
4aa91587d342d9flCellBody non-GeometricData Layer 3
Cell “ Structure_2"(not sorted)
30f8dca7d40bb330Cellwith Comments
Idb29288b51ebdl6Cellwithout Comments
2d4a4e2f61150e26CellComments
a80b7d0fala83felCellBody Layer 1
4bb6333790890817CellBody Layer 19
fe0fdcb0843f8ae0CellBody non-GeometricData Layer 5
順序使用規(guī)范化概要和DIFF工具
以上提到了區(qū)分工具和算法。區(qū)分工具需要成對文件，該成對文件將被進行比較
以計算差異，以便在分析時呈現(xiàn)。相反，規(guī)范化概要可以在沒有任一文件呈現(xiàn)的情況下進行 比較。規(guī)范化概要與區(qū)分工具相結合的一個應用將是使用規(guī)范化概要來標識不同的單 元以便進一步探究。區(qū)分工具可以用于標識不同的單元內(nèi)發(fā)生了什么改變的細節(jié)。區(qū)分工 具的良好集中使用比嘗試使用區(qū)分算法來比較整個設計文件更為有效。典型的區(qū)分算法需要數(shù)據(jù)或多或少按照相同的順序以便進行比較，因為它并不 知道有效的重新排列。畢竟它們在尋找公共子序列。區(qū)分算法的運行時間在最壞的情況 下是指數(shù)級的。為了改善其運行時間，多數(shù)區(qū)分算法具有最大窗口，這些算法假設在該最 大窗口之外的是完全不同的數(shù)據(jù)(即，如果窗內(nèi)不存在匹配)。Paul Heckel的區(qū)分算法 是這些限制的例外。參見"A Technique for Isolating Differences Between Files”， Communications of the ACM 21(1978 年 4 月)第 264-268 頁。區(qū)分算法假設它們正在比較的數(shù)據(jù)文件中沒有結構(或者具有非常少的結構，僅 有文本行)。其本身并不理解單元、頭部、層、非層數(shù)據(jù)或者注釋。DesignSync和IC Manage是用于IC設計行業(yè)的工具，其看上去是基于標準 文件區(qū)分算法的。這些程序看上去對其管理的數(shù)據(jù)的功能重要性并沒有深刻理解。IC Manage (http://www. icmanage. com)在下層使用 Perforce 源代碼管理系統(tǒng)。Perforce 是通 用數(shù)據(jù)管理和區(qū)分工具，其不嘗試理解EDA數(shù)據(jù)文件格式。DesignSync (http://www. 3ds. com)文獻討論了將多個相關文件鏈接到一起以表示單元(即，多個視圖)。關于DesignSync 的更多信息可以在以下地址處找到(2009年5月)· http//www. 3ds. com/products/enovia/industries/high-tech/semiconductor/· http://www.3ds.com/fileadmin/PR0DUCTS/EN0VIA/PDF/ SynchDesignSync-0805_PRESS_. pdf· http://www.3ds.com/fileiidmin/PR0DUCTS/EN0VIA/PDF/ SemiAccIPmgmt-0805_PRESS_. pdf區(qū)分工具對于被規(guī)范化單元概要標識為近似匹配的單元的詳細比較是有用的。因 為運行時間、缺乏對EDA文件語法的理解、噪聲報告以及匹配的限制，它們無法被有效地用 于分析龐大的設計文件或者單元庫。當對順序無關的數(shù)據(jù)進行重新排列時，其無法報告哪 些單元發(fā)生了改變，但是可以報告錯誤差異。在概述了規(guī)范化單元概要及其有用性之后，轉(zhuǎn)而利用如何構造芯片設計數(shù)據(jù)的規(guī) 范化表示的多個示例來進行深入公開。擴展的背景和詞匯通常，芯片設計經(jīng)歷三個主要階段1)標準單元和其他設計模板庫的開發(fā)或者獲 取(并非所有的無晶圓廠設計公司都將開發(fā)其自己的設計模板庫)；2)前端設計-RTL的創(chuàng) 建，繼而邏輯綜合；以及3)后端設計-布圖規(guī)劃、布局和布線，以及現(xiàn)場優(yōu)化(IPO)。在前端設計中，較高層設計模板塊由設計者直接并入(“實例化”)，而不是由邏輯 綜合工具來選擇。邏輯綜合通常僅選擇標準單元，規(guī)范化單元具有較簡單的功能，因為其將 設計者的RTL轉(zhuǎn)化為用于后端設計的結構化網(wǎng)表。在后端設計中，邏輯適應所使用的掩膜 的生產(chǎn)，轉(zhuǎn)而用于制造芯片。高級集成電路(有時稱為“片上系統(tǒng)”或者“SoC”)包含電路的高層功能塊，其可 以是復合的設計模板或者設計的已完成布局和布線部分。后一種通常包括由邏輯綜合系統(tǒng) 選擇的標準單元。無晶圓廠芯片設計公司和第三方設計模板供應商創(chuàng)建了復雜的單元塊，其包含不 止一個標準單元，并且可以執(zhí)行集成電路設計中通常使用的一些操作。例如，ARM處理器可 用作可以并入到芯片中的設計模板。包含對較小單元或者單元塊的一個或多個引用的較大單元塊被稱為層級式的。較 大塊內(nèi)包含的單元塊本身可以是層級式的，使得單元塊內(nèi)可以存在若干層的層級。因為較 小單元和單元塊通過引用而并入，所以其視圖和依賴關系保持相同。單元和單元塊的集合一起表示設計模板塊庫。塊庫可以由第三方供應商提供或者 由內(nèi)部庫開發(fā)團隊創(chuàng)建。此類庫內(nèi)的設計模板的范圍從相對簡單的塊(諸如加法器和乘法 器)到通信組件(諸如USB端口)，以及復合組件，諸如數(shù)字信號處理器(DSP)或者通用處 理器(諸如由ARM提供的)。所有這些可以用在集成電路設計內(nèi)的多個位置。設計團隊用于設計和制造芯片所使用的視圖和偽像駐留在只讀塊庫內(nèi)。幾十個庫 內(nèi)可能存在數(shù)百到數(shù)千個設計模板，這些庫一起形成服務集成設計組的較大庫。邏輯和物 理設計團隊使用該庫來分別創(chuàng)建集成電路的功能和物理布局。并非來自庫的每個設計模板都在集成電路設計中使用。邏輯綜合工具通常從標準 單元類型的子集中選擇，僅選擇與其優(yōu)化算法相協(xié)調(diào)的單元。設計模板庫可以包括相關功 能塊或者預先配置變量的類，諸如存儲器塊，并且設計團隊可以選擇僅使用這些變量的子集。
21
對于注意本公開中描述的事物與較通常使用的命名法之間的差別的讀者，指出這 里的“設計模板”在行業(yè)內(nèi)通常稱為“IP”。設計模板被認為能夠較好地使讀者注意到設計 數(shù)據(jù)與集成電路之間的物理關系。視圖和偽像單元具有視圖和偽像。視圖是單元的物理、功能或者電氣表示之一。視圖一起指 定了單元在設計內(nèi)如何工作，并且由此指定了設計者可以如何對其進行使用以創(chuàng)建集成電路。偽像通常是由單元視圖的創(chuàng)建產(chǎn)生的文件，諸如針對編譯的RAM塊的日志文件或 者數(shù)據(jù)表單，或者在將設計模板并入到大塊中時使用的約束文件。偽像通常是未被結構化 的文本文件，其可能不在工具中在直接使用，而是向設計者傳達意義。使其與針對單元的其 他視圖保持同步是有用的。⑶SII和OASIS (多邊形級)示圖表示葉(leaf)單元、單元塊、功能塊和整個集 成電路的物理布局。Liberty視圖表示針對葉單元或者復合設計模板的定時模型。由設計者創(chuàng)建或者代替設計模板的物理布局而提供的RTL視圖描述了設計行為 以及與諸如處理器核的任何設計模板的邏輯連接。RTL視圖通常是Verilog或者VHDL格 式。邏輯綜合使用RTL視圖加約束和仿真控制文件來生成結構化網(wǎng)表(通常是Verilog或 者 VHDL)。設計者使用結構化網(wǎng)表來創(chuàng)建用于集成電路的布圖規(guī)劃。設計交換格式(DEF)的 視圖表示用于布局和布線程序的布圖規(guī)劃。結構化網(wǎng)表、Liberty、LEF和DEF視圖用作布 局和布線程序的輸入。布局通常一次在一個功能塊內(nèi)執(zhí)行；布線在功能塊中(塊內(nèi))以及 在功能塊與設計模板之間(塊間)都執(zhí)行。一些視圖被用于創(chuàng)建其他視圖。例如，將針對 葉單元或者標準單元的GDSII多邊形數(shù)據(jù)發(fā)送至電路提取器以用于確定晶體管連接和寄 生元件。這些導出的視圖稱為相關視圖。當源視圖改變時，重新生成某些或者全部相關視 圖是有用的。單元、單元接口和單元主體通過分析文件并且通過類型對各部分進行歸類來計算文件的規(guī)范化概要。很多文 件具有頭部，其可以包括關于該文件的全局信息。還可能存在單元或模塊，它們是被結合以 形成設計的獨立設計單位。單元可以被進一步分解為單元名稱、單元接口和單元主體。幾 乎所有文件格式還具有用于指定注釋的方法，其中注釋是仍然可以向讀者或者特定工具傳 達某些意義的正式的非功能性文本。單元的接口是單元去往外部世界的說明。假定對接口的改變是重要的，所以將其 獨立地添加標志以便審閱和批準。隨著設計接近完成，針對接口改變的批準的標準將增加， 因為將需要大量的重新工作以使用新的單元。例如，如果布局單元中管腳的放置改變，則新 的版本在不對設計進行重新布線的情況下無法用作插入式(drop-in)替換。這在邏輯設計 期間不是問題，但是在物理設計的后期階段，這將造成主要的計劃延遲。不構成單元接口某一部分的組件是單元主體的部分。單元的這些方面可以改變， 而不會自動地使現(xiàn)有的單元實例化無效。例如，在布局單元的中間植入層的改變不需要進 行重新布線。⑶SII和OASIS 文件在單元主體內(nèi)具有兩類數(shù)據(jù)。第二類數(shù)據(jù)是非幾何數(shù)據(jù)，諸如文本點和節(jié)點，所以稱為單元非幾何主體數(shù)據(jù)。區(qū)別是任意的；此類數(shù)據(jù)被簡單地獨立記 錄。其還可用于用戶解析的文本文件?！┪募袷娇梢灾付▽蛹墧?shù)據(jù)包含對其他單元的引用的單元。在該信息可用 時，將其與概要一起返回作為單元中的標志。星多個設計文件被劃分到層中。不同的層具有不同的功能，并且對某些層的改變比 其他層“廉價”。例如，如果在制造出設計之后發(fā)現(xiàn)了邏輯錯誤，則僅需要對一個或多個金屬 掩膜進行修改的安裝比需要改變晶體管層的安裝廉價。針對文件頭部、單元接口和單元主 體的概要可以在逐層的基礎上定義。在內(nèi)部，概要模塊記錄關于層的概要，其中層由整數(shù)(通常從-1到較小正數(shù))索 引。編號為-1的層通常表示不在任何層上的數(shù)據(jù)，諸如布局文件(GDSII或者OASIS )中 的單元引用，或者針對不具有層的格式的所有數(shù)據(jù)。具有基于文本的層名稱的解析器返回層編號向?qū)用Q的映射，使得可以通過名稱 來報告概要。解析器本身可以指派層編號，所以其對于利用概要來獲取該列表以及記錄或 者打印編號是有用的。腿按照某些格式的某些數(shù)據(jù)部分是順序無關的，這意味著文件的解釋不取決于頭部 或者單元內(nèi)的對象(例如，多邊形)出現(xiàn)的順序。提供有對這些文件部分進行排序的選項。 例如，VHDL模塊可以使用關聯(lián)列表進行實例化，在該關聯(lián)列表中，通過名稱將接線與端口相 關聯(lián)。這些可以按照任意順序列出。然而，模塊內(nèi)的連續(xù)語句不應當進行重新排列，所以即 使在選擇了排序選項時，也不對其進行排序。如果在可以對所有文件數(shù)據(jù)進行排序之前在存儲器中保持文件數(shù)據(jù)，則可能需要 大量的存儲器。如果超過了傳遞給程序的存儲器使用限制，則可以按照所存儲的數(shù)據(jù)(通 常是單元數(shù)據(jù))從文件中讀取的相同順序立即向概要模塊發(fā)送所存儲的數(shù)據(jù)，或者可以使 用基于文件的排序。排序例程的細節(jié)在單獨文件格式的描述中公開。當改變了存儲器使用限制時或者在程序存儲器使用改善的情況下，文件頭部和單 元概要可以改變。表明單元是否被排序的標志通過應用編程接口(API)可得，并且可以與 針對文件頭部或者單元的概要一起保存在概要數(shù)據(jù)庫中。使用該標志，程序可以確定概要 是否由于數(shù)據(jù)中的實際改變而改變，或者僅由排序中的改變而引起改變。_對于多數(shù)格式，在沒有排序或者進一步解釋的情況下，立即向概要模塊發(fā)送注釋。 將單元內(nèi)的注釋添加到針對該單元的注釋概要中；將任何單元外部的注釋添加到文件頭部 注釋概要中。在VHDL中，注釋可以包含綜合指令，所以其與特定記號序列相關聯(lián)，并且由此 可以進行排序。注釋沒有層名稱或者編號。所審閱的設計數(shù)據(jù)文件格式多種芯片設計數(shù)據(jù)視圖使用專用的文件格式。這些格式中的某些是二進制的，并 且某些是文本(符號)的。然而，這些文件常常較大，并且即使在人類可讀時也難于查看。 其由庫和設計模板供應商創(chuàng)建，并且由電子設計自動化(EDA)工具使用，但是典型的設計公司還沒有能力解釋這些文件以及自己做出關于這些文件的判斷。⑶SII和OASIS 視圖包含葉單元和層級式單元的物理布局。葉單元僅包含幾何
形狀(多邊形、線形、矩形、圓形等)。層級式單元包含對其他單元的引用，并且還可以包含 幾何形狀。還可以具有從供應商導入的諸如處理器核的可能的復合功能的設計模板塊、單 元。假設設計者使用沒有修改的葉單元和設計模板塊。⑶SII或者OASIS 視圖包含在單個文件中，并且包含針對多個單元的幾何數(shù)據(jù)。 此類視圖可以定義將要在芯片內(nèi)引用的幾何數(shù)據(jù)庫，或者其可以定義芯片的幾何數(shù)據(jù)。庫交換格式(LEF)視圖包含一個或多個葉單元或者設計模板塊的物理布局的簡 化版本，以便向布局和布線工具呈現(xiàn)。Liberty視圖包含用于一個或多個單元的定時信息，該一個或多個單元可以是葉 單元、復合設計模板或者各項的組合。寄存器傳輸級(RTL)視圖包含單元的行為描述。通常，RTL視圖按照Verilog或 者VHDL語言格式來指定。邏輯綜合將RTL視圖轉(zhuǎn)換為結構化網(wǎng)表，該結構化網(wǎng)表是包含對 葉單元、設計模板塊或者其他結構化網(wǎng)表的引用的視圖。結構化網(wǎng)表通常在Verilog或者 VHDL語言格式的非常有限的版本中，其僅包含所引用的單元的列表，而不包含任何行為描 述。結構化網(wǎng)表適于向布局和布線工具輸入。一旦布局和布線了結構化網(wǎng)表，即可以對其 性能進行評估，并且在適合的情況下還可以發(fā)布以進行制造。設計交換格式(DEF)視圖包含布圖規(guī)劃的描述，布圖規(guī)劃是對芯片的粗糙表示。 其定義了較大設計模板塊和空區(qū)域的布局，布局和布線工具將標準單元放置到其中?？梢?在芯片內(nèi)創(chuàng)建針對塊的DEF文件，針對該塊運行布局和布線，并且繼而在較高層DEF視圖內(nèi) 使用該塊。繼而對經(jīng)布局和布線的塊進行與設計模板塊相同的處理。在創(chuàng)建標準單元庫時，在物理布局上執(zhí)行電路提取。創(chuàng)建器件的電氣表示和物理 布局中的互連(包括諸如電容和電阻器的任何寄生組件)，并且將其放入到電路仿真器(諸 如SPICE)可用的格式中。SPICE視圖可以表示針對葉單元或者層級式單元的數(shù)據(jù)。SPICE視圖用作對電路表征程序的輸入，該電路表征程序通常使用SPICE或者其 他電氣仿真器在特定激勵或者激勵集合下評估電路，繼而估計電路內(nèi)的延遲。這些延遲繼 而存儲在Liberty視圖內(nèi)。邏輯綜合以及布局和布線工具使用Liberty視圖來估計設計或 者部分設計的性能。如以上說明書所述，某些視圖包含用于生成其他視圖的數(shù)據(jù)。例如，⑶SII或 者OASIS 布局視圖用于創(chuàng)建LEF以及提取的網(wǎng)表視圖，并且提取的網(wǎng)表視圖用于生成 Liberty視圖。所創(chuàng)建的視圖稱為相關視圖，并且在獨立視圖(諸如布局)與相關視圖之間 可具有復雜的關系。標準單元通常實現(xiàn)相對簡單的功能，從反相器(兩個晶體管)到觸發(fā)器(20-40個 晶體管)或者加法器(10-100個晶體管)。其功能簡單到足以使邏輯綜合工具直接操縱。 單個標準單元庫中可能具有數(shù)千個標準單元，并且三個到大概數(shù)十個標準單元庫可用于單 個設計。設計模板塊通常實現(xiàn)更復雜功能，諸如處理器內(nèi)核、讀寫存儲器(RAM)、只讀存儲 器(ROM)或者輸入/輸出子系統(tǒng)。其功能過于復雜以至于邏輯綜合工具無法直接操縱。相 反，設計者明確地要求將設計模板塊的實例插入到其設計中，繼而指定去往設計模板塊的連接。為方便起見，通常將實例放置到RTL視圖中。單個SoC設計中可以放置數(shù)百個個體 設計模板塊。通常使用由設計模板提供商編寫的編譯器來創(chuàng)建存儲器。這允許設計者生成由設 計模板提供商擔保的定制存儲器配置(例如，字寬、字數(shù)目)，只要它們在編譯器完成之后 未被修改即可。為此，假定設計者將存儲器編譯器的輸出作為設計模板塊來處理。存儲器塊可以包含在層級式⑶SII或者OASIS 視圖中。在最終裝配期間將該視 圖被并入到設計中。編譯器還生成定時視圖(通常是Liberty)和物理抽象(通常是LEF)， 使得自動化工具可以分析使用存儲器的設計。在認為所有的標準單元庫和設計模板塊對于設計團隊可用時，可能存在數(shù)萬個不 同的單元。并非所有這些單元都可以在給定設計中使用。例如，設計團隊可能對使用異或 (XOR)門的邏輯綜合工具具有不良經(jīng)驗，所以他們可以告知邏輯綜合工具不使用任何XOR 門。一些單元功能可以存在于多驅(qū)動強度中(用于處理附加電路和寄生組件的改變的量的 電流容量)，并且設計工具可能不使用給定設計中的全部驅(qū)動強度。針對單元視圖的規(guī)范化概要的工作示例在本部分中，描述和分析用于IC設計的多種設計語言和文件格式。提供準備在IC 設計流中使用的設計數(shù)據(jù)的規(guī)范化版本的十幾個示例。圖1示出了高層集成電路設計環(huán)境。當然，關于該環(huán)境存在很多變體，并且很多細 節(jié)沒有示出。在該變體中，多數(shù)塊示出了單元設計模板的開發(fā)者向無晶圓廠客戶137提供 模板可能遵循的過程，該無晶圓廠(fabless)客戶依靠代工廠(foundry) 151來生產(chǎn)芯片， 并且根據(jù)來自代工廠的反饋來工作。根據(jù)該圖示應當理解，無晶圓廠客戶發(fā)布的用于由代 工廠制造的設計包括用于掩膜生產(chǎn)的所謂“流片”。在設計過程的開始，設計者開發(fā)功能規(guī) 范111并且執(zhí)行邏輯設計以產(chǎn)生RTL 121，其可以提供競爭者的器件中沒有的新功能或者 以較低的價格提供。設計者具有來自代工廠的可用信息，該可用信息包括代工廠規(guī)則和電 氣信息141。代工廠信息反映在邏輯綜合123期間與RTL相結合的單元設計模板131的庫 中。有時向無晶圓廠客戶提供RTL作為前端視圖125。邏輯綜合的輸出在布圖規(guī)劃133中 使用；布圖規(guī)劃的輸出在產(chǎn)生后端視圖145的布局和布線操作143中使用。沒有示出但易 于理解的是，布局和布線操作受制于物理約束。后端視圖被發(fā)布至無晶圓廠客戶137。可以 由或者針對無晶圓廠客戶將后端和前端視圖編輯到庫中。這些后端視圖按照客戶不應當修 改的固定塊的形式。圖2示出了與圖1的框相關聯(lián)的版本和某些文件格式的擴展。附圖之間的并行編 號將兩個附圖中的框相關聯(lián)。功能規(guī)范可以以設計語言來表示。功能規(guī)范約束將具有版本。 邏輯設計221中創(chuàng)建的RTL可以以Verilog或者VHDL來表示，其將具有其自己的版本。代 工廠規(guī)則241可以以諸如PDK、Interconnect (互連)、Parametrics (參數(shù)化)或者代工廠 專有語言的語言來表示。引用單元庫可以包括多個針對設計數(shù)據(jù)的視圖。用于表示這些視 圖的語言包括SPICE、Liberty、LEF和⑶SII。在邏輯設計221期間，輸出可以包括仿真控 制和RTL(Verilog或者VHDL)。邏輯設計的結果可以直接公布為使用Liberty、LEF和RTL 表示的前端視圖225 ；或者可以將其發(fā)送至邏輯綜合223。邏輯綜合223的結果與物理規(guī)范 253相結合，并且用作對布圖規(guī)劃233以及對布局和布線243的輸入。這些過程使用諸如 結構化網(wǎng)表、DEF、Liberty、LEF和⑶SII的視圖。這些過程的結果可以發(fā)布作為后端視圖245。無晶圓廠客戶137可以使用設計數(shù)據(jù)的前端和/或后端視圖。注意，包括在圖2中的 版本號僅是示例性的，并且不應當視為對過去、現(xiàn)在或者將來的語言或者庫版本的引用。圖 2中引用的文件格式在以下部分中解釋。文件類型的分類為了該討論，文件被分類為非結構化文本、結構化文本、非結構化二進制或者結構 化二進制。非結構化文件沒有特定格式；其是諸如文檔的輔助文件，或者其不具有單元和 層。為這些文件所計算的概要是非常受限的。結構化文件具有定義的語法，其可以包括注 釋、層名稱或者編號以及單元。這些需要解析器區(qū)分文件的各部分并且通過類型對其進行 標記。除了⑶SII和OASIS 文件以外，針對一種格式的文件生成的概要通常與針對另一 格式的文件生成的概要不兼容。也就是，跨文件類型比較概要通常是無意義的。如果不存 在對象屬性，則可能將⑶SII與OASIS 數(shù)據(jù)進行比較，因為其首先被轉(zhuǎn)換為支持跨這些文 件類型進行比較的內(nèi)部表示。一般而言，OASIS 中的對象屬性與GDSII中的對象屬性不兼 容，除非OASIS 文件中的S_GDS_PR0PERTY屬性被轉(zhuǎn)換為等效的⑶SII屬性。文件類型及其解釋的詳細描述見下文。下文描述了文件解釋、概要計算和排序行 為的細節(jié)。各部分是獨立的，使得其可以充當獨立的參考。由此，一些信息可能是重復的。在以下的描述中，語言關鍵詞以Courier字體出現(xiàn)，例如HEADERTEXT或者scaled_ cell ο文件級概要解析器針對文件中按照沒有解釋或者排序的順序的所有字節(jié)計算至少一個文件 級概要。用于基于文本格式的解析器還針對所有空白字符(空格和水平制表符)以及針對 所有的非空白字符計算文件級概要。這些不是規(guī)范化單元概要；其不是格式特定的，并且僅 可以用于快速確定文件是否完全改變。規(guī)范化概要當記錄規(guī)范化概要時，文件被分解為文件單位(file unit)，其與記錄類型相耦 合。文件單位是由語言規(guī)范定義的文件的一部分，通常是一個或多個記號(token)(單詞 或者標點)，并且記錄類型是文件頭部、注釋、單元名稱、單元接口、單元主體或者單元非幾 何主體之一。單元非幾何主體數(shù)據(jù)僅是單元主體數(shù)據(jù)的獨立類。目前，此類僅在⑶SII和 OASIS 解析器中用于表明具有層編號的非幾何數(shù)據(jù)，諸如NODE和TEXT記錄。如何針對文件格式計算概要的定義可能是復雜的，如圖8-圖17所示。各種格式 的描述包括概觀、用于處理文件單位的詳細規(guī)范以及示例。示例1 =Liberty格式化文件Liberty庫文件格式提供了一種向邏輯綜合工具描述電路的功能和定時的方式。 它由Synopsys定義，并且得到廣泛地使用，因為Synopsis已經(jīng)發(fā)布了規(guī)范。它是可以易于 查看的基于文本的格式，但是歸因于Liberty文件中的數(shù)據(jù)量，其通常由軟件創(chuàng)建。在此第一示例中，將討論Liberty設計語言文件的概括。Liberty文件的某些部分 是未記錄的?！拔从涗洝笔侵敢?guī)范化概括。一般而言，單元名稱沒有進行概括，因為這樣做將 阻礙否則具有不同名稱的等效單元的匹配。一些解析器還跳過所需要的記號，并且不提供 附加信息，諸如固定位置關鍵詞或者層名稱(因為概要無論如何都由層分離)。
26
在一些格式中，被記錄的“文本，，實際上是不可打印的二進制數(shù)據(jù)，并且描述使用 來自語言規(guī)范的關鍵詞。規(guī)范化單元概要通常具有32或者64比特。兩種類型都使用循環(huán)冗余校驗(CRC) 來計算。32比特概要使用SEMI標準P0039-1105中針對OASIS 文件所規(guī)定的ISO 3309 CRC多項式和方法來計算χ32+χ26+χ23+χ22+χ16+χ12+χ11+χ10+χ8+χ7+χ5+χ4+χ2+χ+164比特概要使用針對歐洲計算機制造商協(xié)會(Ecma)國際標準ECMA-182規(guī)定的 CRC多項式來計算Χ +χ62+χ57+χ55+χ54+χ53+χ52+χ47+χ46+χ45+χ40+χ39+χ38+χ37+χ35+χ33+χ32+χ31+χ29+χ27+χ24+χ23 ,22 , 21 , 19 , 17 , 13 , 12 , 10 , 9 , 7 , 4 , , -ι
+X +X +X +X +X +X +X +X +X +X +X+丄針對LibertyC lib)文件的文件內(nèi)容概要應用于LibertyC lib)文件的此示例的細節(jié)取決于scalecLcell記錄是否在與 cell記錄相同的文件中。以下討論的第一部分假設兩種記錄在相同的文件中。后一部分允 許兩種記錄在不同的文件中。Liberty文件具有針對以下文件元素中的某些或全部的內(nèi)容概要 文件 文件頭部眷頭部內(nèi)的注釋文本(可選) 單元頭部 除文件頭部信息以外的單元主體(可選) 文件頭部信息合并到單元中的單元主體(可選) 單元內(nèi)的注釋文本(可選)對文件進行掃描以發(fā)現(xiàn)內(nèi)部的單元名稱。針對文件中的單元，該工具返回針對單 元頭部的概要(輸入和輸出規(guī)范)以及針對單元主體的概要。作為一個選項，針對頭部中的注釋文本和單元內(nèi)的注釋文本計算獨立的概要，并 且忽略空白(空格、制表符的數(shù)目相對于空格、空行)的差異。針對文件頭部(任何單元定義之前的信息)以及針對整個文件而計算并且返回概 要。默認地，將針對文件頭部(排除注釋文本、文件日期以及修訂)的概要與針對單元的概 要合并，以避免(例如)由將影響庫中的所有單元的邏輯閾值或者單位定義的改變而導致 的問題。作為一個選項，當已知文件頭部已經(jīng)改變但是仍然期望進行單元比較時，可以將文 件頭部從單元主體概要計算中排除。在記錄任何概要之前，將所有的cell和scalecLcell組語句進行排列，而不管是 否請求了文件的排序。針對單元的概要還包括所有的scalecLcell定時定義。在基于操作 條件組名稱的已排序順序中，cell組是第一個，scalecLcell組在其之后。因為scalecLcell記錄可以出現(xiàn)在文件中的任何地方，甚至可以出現(xiàn)在未縮放的 單元之前，所以不計算針對單元的“包括空白的所有文本”概要。該概要僅在文件級計算。因為需要對具有cell記錄的組scalecLcell記錄進行排序，所以將整個文件載入 到存儲器中，而不管命令行中規(guī)定的存儲器限制。然而，注意，cell和scalecLcell組語言 可以出現(xiàn)在獨立的文件中，在這種情況下，如果其出現(xiàn)在相同文件中，則最大限度地如下文所述進行處理，而不是對其進行排列。單元頭部概要中僅記錄管腳名稱。這例如意味著，如果管腳的方向改變，則頭部概 要將不會改變。由于所需要的運行時間，組語句的排序在一個實施方式中是淺層的(shallow) 在對組語句的列表進行排序時，僅考慮組語句的一個子層。備選地，可以對多個子層進行排 序。注意，對組內(nèi)的語句進行排序(再次，使用一個子層)。所有排序都是穩(wěn)定的，所以當比 較的限制被超過時，先前按照特定相對順序的語句將維持該相對順序。例如，對以下進行排 序產(chǎn)生以下表1中示出的結果表1 文件組語句的排序
排序前排序后
gl (B) {Gl (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組之后
之前。還要注意，具有參數(shù)C的兩個ga語句維持相同的相對順序，因為其低級P語句在排 序期間未被考慮。P記錄自身在ga記錄內(nèi)進行排序，并且針對ga記錄之一的G參數(shù)使得其 移動至ga記錄集合的一端。Liberty庫描述文件布局設計者通常將相同的單元名稱用于不同庫(例如高性能和高密度)中的單 元，以便幫助區(qū)分不同庫中的單元，對所有的單元名稱預先考慮Liberty文件中的庫名稱。 例如library (demo) {cell (INV_X1) {area :0. 032 ；
...}}與該單元相關聯(lián)的單元名稱將是demo. INV_X1。Liberty格式為所有期望的工藝拐點(process corner)規(guī)定多個縮放參數(shù)，其被 設計用于幫助外推定時和功率系數(shù)。這對于某些單元可能并不充分，所以可以使用scalecL cell語句而不是常規(guī)的cell語句來定義針對這些單元的附加縮放單元記錄。針對經(jīng)縮放 單元記錄的單元名稱利用經(jīng)縮放單元名稱來另外標記，這對于在兩種類型都出現(xiàn)在相同文 件中時區(qū)分單元類型特別有用。例如library (demo) {scaled_cell (AND2_X2, slow_slow) {area :1. 064000 ；...}}與此單元相關聯(lián)的單元名稱將是demo. AND2_X2. slow_slowLiberty文件還包含規(guī)定應用于單元的參數(shù)的廣泛(extensive)頭部。對此頭部 的不經(jīng)意改變由此將具有顯著的結果，所以默認將針對頭部中至少一些參數(shù)的概要合并到 針對文件中的單元的概要中。當在沒有相應地改變所有單元的情況下不會意外地改變頭部 (諸如轉(zhuǎn)換為較小的電壓或者時間單元)時，可以使用-noheader命令行選項來禁用頭部合并。Liberty文件中的語句是順序無關的，所以默認對語句進行排序，除非用戶指 ^ -nonsort t示;^。Liberty文件中不存在層，所以所有針對單元的概要都被報告為非層數(shù)據(jù)，如以下 樣本報告File ‘‘ testfiles/tstlibpar2. lib" :Liberty formatArguments -mem 64 -sort728fb5e7 File451c31ec File non-ffhitespace00a03577 File WhitespaceFile Header(sorted)164c9eaf File Header with CommentsIcc03fe0 File Header without Comments0a8cal4f File Header CommentsIcc03fe0 File Header non-LayerCell “ demo. AND2_X1 〃 (sorted)be7930d6 Cell with Commentsbe7930d6 Cell without Comments
(none) Cell Commentsfe7aeb77 Cell Interface non-Layer4003dbal Cell Body non-Layer此處啟用了頭部合并；否則文件名稱下的參量行將具有報告的-noheader。處理Liberty格式文件的細節(jié)定義原型Liberty解析器遵循Synopsys的Liberty參考手冊(版本2007. 03)中的 Liberty格式定義。
語法解釋
Liberty參考描述了三種語句類型，其可以總結如下keyword value ；keyword = value ； keyword (value...)； keyword(value. . .){statement...}
前兩種形式稱為簡單屬性。第三種形式稱為復雜屬性，而第四種稱為組語句。組 語句轉(zhuǎn)而可以包含簡單屬性、復雜屬性或者組語句的任意組合。注意，第二形式的簡單屬性 的結尾的分號以及組語句的括號內(nèi)列表是可選的。雖然假定語句的第一記號是關鍵詞(即，保留字)，但是Liberty格式允許庫供應 商定義新的簡單屬性，并且因此僅執(zhí)行有限的關鍵詞檢查。解析器確保Liberty文件包含 一個或多個庫組語句，并且確保任何cell或者scalecLcell語句在該庫內(nèi)。解析器還尋找 單元級語句，其可以是單元接口的考慮部分。否則，允許遵循以上一般語法的任何語句。Liberty格式文件中不存在層名稱，所以記錄針對非層數(shù)據(jù)具有默認為_1的層編 號的所有概要。該參考規(guī)定了 C樣式的注釋，其開始于記號/*，結束于記號*八假設注釋不是嵌 套的。將單元內(nèi)的注釋記錄為針對單元的概要的一部分。將出現(xiàn)在任何庫外部的注釋或者 出現(xiàn)在庫語句內(nèi)部但是任何單元外部的注釋記錄為文件頭部注釋。Liberty格式提供了用于指定在不同的操作點處表征的單元的縮放版本的方式。 在一個實施方式中，這些scalecLcell語句被視為獨立單元，因為其出現(xiàn)在與單元的非縮 放版本不同的Liberty文件中。因為在多個庫中可能出現(xiàn)相同的單元名稱，所以一個解析器實施方式利用其庫名 稱以及scalecLcell名稱(如果有的話)來限定單元名稱，例如，用于cell的cmOS_90nm 或者用于scalecLcell的cmos_90nm. andx2. slow_slow。如果任何名稱的組成包括'.‘ 字符，則該組成被引證為“cmos_90nm. v2" · andx2. “ slow, slow"。庫中的頂層語句包括影響庫內(nèi)所有單元的解釋的多個參數(shù)。例如，單元內(nèi)的延遲 或者功率值可以以納秒或者皮瓦為單位來測量。手工編輯的或者利用腳本從文件碎片匯編 的Liberty文件可能具有不與單元相對應的頭部。為了幫助檢測此類錯誤，將多數(shù)庫級屬 性收集到頭部塊中，繼而可以將該頭部塊合并到單元中以用于概要記錄。很有可能隨版本 而改變的屬性(例如，date或者version)從該頭部塊中排除。cell或者scalecLcell語句內(nèi)的多個屬性和組語句指定單元的接口，意味著對 這些語句的任何改變將意味著該單元的功能已經(jīng)以有意義的方式改變。參見“帶注解樣本Liberty文件”部分以查看完整列表。pin、bus和bundle組語句內(nèi)的某些屬性還指定了單元的接口。然而，可以合理地 期望這些語句內(nèi)的某些數(shù)據(jù)隨著庫的版本而改變。例如，無論何時更新了過程參數(shù)或者改 變了布局的某些部分，即使單元的功能仍然相同，timing組語句都將改變。Liberty文件的排序Liberty文件不是順序相關的；單元內(nèi)的語句或者單元內(nèi)的組語句可以按任何順 序出現(xiàn)。為了允許可能具有重新排列的語句的庫之間的比較，可以對單元內(nèi)的語句進行排 序。主排序關鍵字是開始語句的關鍵詞。如果兩個關鍵詞都是用戶定義的屬性(與預先定 義的Liberty關鍵詞相比)，則執(zhí)行字符串比較，并且按字母順序排第一的關鍵詞是語句列 表中的第一個。如果兩個語句的關鍵詞是相同的，則輔排序關鍵字是語句中的參數(shù)列表。將 參數(shù)作為字符串比較，并且如果存在差異，則具有按字母順序排第一的參數(shù)的語句是語句 列表中的第一個。如果所有的參數(shù)都是相等的，只是一個參數(shù)列表較短，則具有較短參數(shù)列 表的語句被排在前面。如果參數(shù)列表是相同的，則將語句視為相同的。為了限制排序期間的運行時，一些 實施方式不比較組語句內(nèi)的語句。使用穩(wěn)定排序，以使得語句排列僅在存在明顯差異時才 改變。原型Liberty解析器的限制Liberty文件中的多數(shù)記號(包括library、cell和scaled_cell名稱)假設是區(qū) 分大小寫的。true和false是例外，其在參考Synopsys解析器實現(xiàn)中是不區(qū)分大小寫的。解析器假設存儲器使用限制將高到足以用來存儲所有的單個cell或者scalecL cell的語句加上所有的文件頭部語句。除語句結構的驗證之外，僅進行有限的語法檢查。例如，允許多個頂層library語 句。如果庫的結構不遵循Liberty語句語法，或者如果頂層不存在library語句，則報告錯 誤，并且不計算概要。出現(xiàn)在單元之間的頭部語句僅被合并到文件中在其之后的概要中。對于多數(shù)完整 的概要記錄，所有的庫頭部語句應當在任何cell或者scalecLcell語句之前出現(xiàn)。因為針對包含文件的搜索路徑不可用(并且可能隨時間改變)，所以不處理包含 文件指令。字符串內(nèi)的值未被解釋。假設相同工具將創(chuàng)建Liberty文件，并且這些工具例如 將不會對編號進行重新格式化，除非編號實際上已經(jīng)改變。將要從庫頭部中排除或者包括在單元接口中的關鍵詞列表應當是固定的，并且在 仔細考慮之后改變，因為當關鍵詞列表改變時，很多概要需要重新計算。將文件頭部中的單位編號作為顯式記號(例如，Ins)或者作為字符串(例 如，“ImV")來支持。假設，文件的新版本將不會在兩個表示之間切換。帶注解的樣本Liberty文件圖8A-圖8D示出了 Liberty文件中的可能頭部和單元語句的采樣。多數(shù)頭部和 單元語句以所示出的方式進行處理。特別地，當把整個組語句記錄為相同的概要類型時，圖 8中僅示出了關鍵詞、參數(shù)(如果有的話)以及花括號。單元外部的屬性和語句被添加到文 件頭部概要中。在單元內(nèi)，僅將所標識的屬性和組語句記錄為單元接口的一部分。如所指
31示的，將強調(diào)的某些屬性和組語句記錄為單元主體的一部分。默認地，多數(shù)文件頭部語句(排除注釋記號)被記錄為單元接口的一部分；此處沒 有示出。沒有將date、revision和comment屬性記錄為單元接口的一部分，因為其可能在 修改Liberty文件時改變。很多簡單cell和pin屬性被視為單元接口的一部分；它們被列在以上示例中。加 雙下劃線或者這里沒有示出的部分都被視為單元主體的一部分。注意，bus和bundle組語句可以包括pin語句以及嵌套的pin語句的任何簡單屬 性。將bus和bundle語句的屬性記錄為如同其在pin語句中一樣；將嵌套的pin語句的內(nèi) 容記錄為如同其是獨立的管腳一樣。在Synopsys參考解析器中，簡單的屬性可以使用‘’或者‘=’來將變量名稱與 之后的表達分離，因此以下是等效的area = 5 ；area 5 ；文檔使用‘’，所以所有的‘=’在發(fā)送至概要引擎之前都被轉(zhuǎn)換為‘’。沒有記錄用于簡單和復雜屬性的分號，因為Synopsys參考解析器并非總是需要 它們，有效地使其可選。示例2 Verilog文件類型Verilog是集成電路設計中廣泛使用的仿真和寄存器傳輸邏輯(RTL)語言。它是 通常由設計者創(chuàng)建并且由邏輯綜合工具編譯的基于文本的格式。其允許設計者將設計指定 為互連模塊。電路功能在記錄為單元的模塊中指定，輸入和輸出端口記錄為單元接口。將 對邏輯綜合工具的暗示放到與模塊頭部或者語句相關聯(lián)的屬性中。在此示例中，Verilog文件具有針對以下文件元素的內(nèi)容概要 文件 文件頭部 單元模塊端口定義 單元模塊的主體對文件進行掃描以找到內(nèi)部的模塊名稱。針對端口定義和模塊的主體計算獨立的 概要。這些基于排除任何空白的個體Verilog記號。針對文件的頭部(任何模塊定義之外的信息)以及針對整個文件而計算和返回概要。假設Verilog 2005語法，即使出現(xiàn)了' begir^keywords。因為僅解析文件的模塊 結構，所以這不應當影響針對文件的概要計算(例如，關鍵詞不與符號不同地解釋)。假設 文件在語法上是正確的。不解釋編譯器指令(包括宏替代)。假設文件是不具有宏替代的有效Verilog。一 般而言，假設僅針對常量定義使用宏，并且其不創(chuàng)建諸如模塊頭部或者Verilog語句的語 法結構。不解釋包含文件指令，因為概要計算時的包含路徑可能與編譯時的包含路徑不 同。在一個實施方式中，假設綜合指令在Verilog屬性(“(*”和“*)”)內(nèi)，而不在注釋內(nèi)。如果存在緊鄰模塊或者宏模塊聲明之前的屬性，則其概要被添加到模塊的概要中。 模塊聲明之外的注釋被視為源文件的“頭部”(非模塊文本)的一部分，而不是模塊自身的 一部分。因為在解析器了解模塊聲明之前掃描前述屬性的字符，所以其被添加到針對頭部 的“全文本”概要中，而不是模塊自身中。模塊之外的注釋被添加到文件頭部概要中。模塊 和宏模塊被視為等效的對象。在一個實施方式中，功能、UDP和生成塊被視為源文件的“頭 部”的部分，而不是模塊自身。有可能將這些視作模塊的特殊形式，以與處理VHDL構造(諸 如過程和功能聲明)類似的方式將其記錄為單元。如果list_0f_p0rts中的任何端口使用 “.”或者“ H ”記法，則將不對list_0f_p0rts中的端口名稱進行正確的排序。不計算針對單元內(nèi)的空白的概要。僅計算文件級空白概要。在單元內(nèi)，概要僅基 于文件的記號(在適當時包括注釋)。Verilog RTL 文件Verilog模塊的很多主體是順序相關的，所以只能對模塊參數(shù)進行排序。即使如 此，模塊也并非總是使用順序無關的參數(shù)規(guī)范來實例化，所以在排序之后發(fā)現(xiàn)的概要匹配 可能不表示模塊定義之間的真正等效。由此，Verilog文件的排序應當慎重進行。默認地， 不對Verilog文件進行排序，除非用戶指定-sort標志。Verilog文件中不存在層，所以所有針對單元的概要都被報告為非層數(shù)據(jù)File “ testfiles/verilog_test. ν" Verilog tormatArguments -mem 64 —nosort5404c699 File7c2a352d File non-ffhitespace219bl881 File WhitespaceFile Header(not sorted)b290d605 File Header with Comments(none) File Header without Commentsb290d605 File Header CommentsCell “ DFF_X1〃 (not sorted)ca436d2f Cell with Commentsca436d2f Cell without Comments(none) Cell Commentscl02a525 Cell Interface non-Layer0b41c80a Cell Body non-LayerVerilog格式文件定義Verilog語言規(guī)范是IEEE標準；原型Verilog解析器遵循IEEE標準1364-2005中 的語言定義。這尚不包括Verilog-Α(模擬)擴展，但是可以易于進行擴展以將其包括。雖然Verilog RTL描述在邏輯綜合中使用，但是語言本身不足以確定設計者的意 圖。邏輯綜合工具提供用于通過使用屬性來引導優(yōu)化的手段。這些是類似于注釋的記號 序列，其在Verilog模塊和語句之前或者嵌入在其中。屬性內(nèi)的文本形成綜合指令。原型 Verilog解析器解析Verilog屬性，將其指派至適當?shù)恼Z言結構，并且將其發(fā)送至概要引 擎，但是其不解釋內(nèi)部的文本。
在將屬性附加到Verilog語言之前，使用Verilog注釋來指定綜合指令。解析器 目前不支持使用針對綜合指令的注釋，但是它可被容易地擴展以支持上述使用。語法解釋Verilog文件是聲明和模塊的序列。模塊是規(guī)范化單元概要工具中的單元；其他 所有的都記錄為文件頭部的一部分。模塊可以具有由參數(shù)指定的接口。存在兩種樣式的參數(shù)定義端口列表和端口聲 明列表。端口列表僅具有模塊語句中存在的端口名稱，而端口聲明列表還具有端口類型。module a(b，c，d) ；//list of portsmodule a (input [7:0] b，output [8:0] c，reg d) ；//port declarations當使用端口列表指定對模塊的接口時，聲明嵌入在模塊主體中。解析器尋找聲明， 并將其作為單元接口數(shù)據(jù)發(fā)送至概要引擎。模塊主體中其他所有內(nèi)容都作為單元主體數(shù)據(jù) 發(fā)送至概要引擎。當使用端口聲明列表指定對模塊的接口時，模塊主體中的所有內(nèi)容作為單元主體 數(shù)據(jù)發(fā)送至概要引擎。解析器假設模塊和宏模塊是等效的。宏模塊在被發(fā)送至概要引擎之前被轉(zhuǎn)換為模 塊。不對宏定義進行解釋。因為宏定義可能在解析器不可用的已包含文件中，或者可 能隨時間改變，因此不會嘗試展開宏引用。假設宏不包含語法結構，使其可以通過假設宏引 用與標識符或者數(shù)字等效而解析Verilog文件。庫聲明和include語句被記錄為文件頭部數(shù)據(jù)。不讀取include文件；include文 件搜索路徑對規(guī)范化單元概要程序不可用。其也可能隨時間改變，從而使已經(jīng)計算的任何 文件概要無效?？梢詫⒐δ?、用戶定義的原語(UDP)定義、生成塊和配置聲明添加到文件頭部概 要中，而不進行進一步解釋，或者可以視為在VHDL文件中。緊鄰模塊關鍵詞之前的或者模塊主體內(nèi)的屬性可以記錄為單元主體文本。所有其 他屬性記錄為文件頭部文本。Verilog文件的排序Verilog中的很多語句是順序相關的，因此無法進行排序。解析器不嘗試確定模塊 主體的哪些部分是順序無關的，其僅排序模塊定義的參數(shù)。因為模塊實例化可能不使用順 序無關的參量規(guī)范，所以排序之后發(fā)現(xiàn)的概要匹配可能不表示模塊定義之間的真正等效。 由此，Verilog文件的排序應當謹慎進行?？梢灾饌€指定模塊輸入和輸出聲明，或者如果類型相同，則在列表中指定。例如， 以下聲明集合是等效的input signed[4input signed[4input signed[4input signed[4input signed[4
0]RN, CK, D，SE ；以及
0]RN;
0]CK ；
0]D ；
0]SE ； 解析器將輸入和輸出參數(shù)聲明從第一形式擴展到第二形式。繼而可以根據(jù)參數(shù)的
34名稱對其進行排序。解析器假設存儲器使用限制高到足以存儲針對模塊的所有端口定義，因為最多將 只有幾百個。原型Verilog解析器的限制解析器不嘗試對模塊實例化中的參量列表進行排序，即使在所有的端口通過名稱 連接(例如，.Out(topB))時也是如此。當模塊主體內(nèi)的變量聲明在端口列表中被指定時，可以用于修改端口聲明的含 義。解析器不嘗試定位這些附加聲明。例如module a(b)；input b ；wire signed [7:0] b ；endmodule這里，輸入端口 b的類型由wire聲明修改，但是wire聲明沒有被添加到單元接口 概要中。當端口聲明使用具有‘.，的外部名稱或者具有“ {}，，的并置(concatenation)時， 解析器不嘗試指派“端口名稱”。通常將端口名稱定位在聲明內(nèi)，并且在記錄針對端口的概 要時被用作接口記錄名稱。當存在外部名稱或者并置時，將聲明的第一記號用作用于對端 口進行排序的“名稱”。模塊端口列表中的參數(shù)聲明(使用‘#’指定)被添加到單元主體概要中。當在文件中發(fā)現(xiàn)宏定義時，將其發(fā)送至概要引擎。其可能在文件頭部內(nèi)或者在單 元內(nèi)。沒有對宏引用進行展開，因為宏定義可能在另一文件中，而該文件對于規(guī)范化單元概 要工具而言可能不可用，或者可能隨時間而改變。也不解釋編譯器指令。將數(shù)值文字在不解釋的情況下向概要引擎發(fā)送。特別地，不將其首先轉(zhuǎn)換為規(guī)范 化形式。例如，指數(shù)中的加號是可選的，所以IelO將不同于le+10。數(shù)字不是重印的，所以 IelO也將不同于1. OelO0解析器不嘗試確定何時可以將Verilog模塊視為層級式的。帶注解樣本Verilog文件圖9是示出解析上述規(guī)則的應用的Verilog文件的帶注解樣本。示例3 結構化二進制文件類型在此示例中，將不具有定制解析器的結構化二進制文件類型視為非結構化二進制 文件。通常，在不知道二進制文件的結構的情況下，為所有字節(jié)指派概要。為了向結構化 二進制文件內(nèi)的特定內(nèi)容指派概要，數(shù)據(jù)結構需要是已知的，并且需要為其編寫的解析器。示例4 =VHDL文件類型VHDL是集成電路設計中廣泛使用的仿真和寄存器傳輸邏輯(RTL)語言。它是通常 由設計者創(chuàng)建并且由邏輯綜合工具編譯的基于文本的格式。在此示例中，VHDL文件具有針對至少以下文件元素的內(nèi)容概要 文件
35
文件頭部眷實體塊 架構塊掃描該文件以找到用于模塊的實體和架構塊。針對模塊，為實體和架構計算獨立 的概要。備選地，可以計算較大(或者較小)粒度的概要，如以下VHDL “單元”的解釋中所 描述的。這些概要可以基于排除任何空白的個體VHDL記號(包括注釋，因為綜合指令可以 包括在注釋在)。將針對文件的頭部(任何模塊定義之外的信息)和針對整個文件而計算和返回概 要。這些包括所有空白。不檢查來自USE指令的包含文件也不將其添加到概要中。VHDL RTL 文件很多VHDL語言結構可以視為滿足“單元”的定義，包括實體、配置、架構、過程、功 能、組件、類型和子類型。對這些中任何一個的改變都可能對設計具有深遠的影響。從解析 的角度看，這些以及其他VHDL聲明類型也是庫內(nèi)的第一類對象。由此，解析器創(chuàng)建針對以 下VHDL語言結構的單元(使用來自IEEE標準1076-2002的附錄A的產(chǎn)品名稱)參 subprogram—declaration(a procedure or a function)# subprogram—body(a procedure or a function)· type—declaration# subtype—declaration· constant—declaration· signal_declaration· shared—νariable_declaration參 file_declaration· alias_dec larat ion· component—declaration· attribute—declaration· attribute—specification· disconnection—specification· use—clause· group_template_dec larat ion# group—declaration邏輯綜合工具的提示被放入與對象頭部或者語句相關聯(lián)的注釋中。由此，組合的 “具有注釋的單元”概要比“沒有注釋的單元”概要可能更加有用。很多語句VHDL是順序相關的，所以僅可以排序聲明中的參數(shù)。即使如此，架構和 組件也并非總是使用順序無關的參量規(guī)范來實例化的，所以在排序之后找到的概要匹配可 能不表示真正的等效。由此，VHDL文件的排序應當謹慎進行。默認地，不對VHDL文件進行 排序，除非用戶指定了 -sort標志。VHDL文件中不存在層，所以所有針對單元的概要都被報告為非層數(shù)據(jù)File “ testfiles/timing_b· vhd" :VHDL format Arguments :-mem 64 -nosortbll6bl6a File
Ocafc41a File non-ffhitespace704d8ab4 File WhitespaceFile Header(not sorted)9f21alef File Header with Commentsd279ff8a File Header without Comments4d585e65 File Header Commentsd279ff8a File Header non-LayerCell " vital_timing. constant, edgesymbolmatch" (not sorted)63c5ce8d Cell with Comments63c5ce8d Cell without Comments(none) Cell Comments63c5ce8d Cell Interface non-LayerCell " vital_timing. function, vitalcalcdelay. I" (not sorted)cd370359 Cell with Commentscd370359 Cell without Comments(none) Cell Commentsbe204681 Cell Interface non-Layer731745d8 Cell Body non-Layer如上所述，所報告的單元名稱包括在其中定義對象的庫(如果有的話)；對象的類 型(常量、函數(shù)、實體、架構等)，對象名稱以及用于重載解析的歧義編號。例如，函數(shù)可以被 重載，意味著相同的名稱用于具有不同參數(shù)類型的一組函數(shù)。邏輯綜合工具通過檢查所有 可能的匹配來選擇適合的函數(shù)。規(guī)范化單元概要工具不實現(xiàn)完全的VHDL解析器。特別地，它不維護符號表，所以 它僅基于對象名稱而簡單地記錄具有名稱的單元中的概要。因為如果重載的對象被添加到 文件中或者從文件中移除，則歧義編號可能改變，所以用戶的匹配軟件將必須基于概要來 選擇適合的單元。VHDL格式文件定義在20世紀80年代，為國防部定義了 VHSIC硬件描述語言(VHDL)作為硬件系統(tǒng)定 義語言。其現(xiàn)在仍然用作針對邏輯綜合的寄存器傳輸語言。VHDL是基于文本的語言，其允許設計者將涉及指定為利用架構實現(xiàn)的互連實體。 這是具有影響設計規(guī)范的多個語言結構的非常復雜的語言。所有這些被記錄為利用其類型 來限定名稱的不同單元，例如entity. full_adder。VHDL語言規(guī)范是IEEE標準；原型VHDL解析器遵循IEEE標準1076-2002中的語 言定義。這不包括VHDL-AMS (模擬)擴展。雖然VHDL RTL描述在邏輯綜合中使用，但是語言本身并不足以確定設計者的意 圖。通常將嵌入在注釋中的綜合指令添加到VHDL文本中以便引導優(yōu)化。這些利用遵循其 的語言結構來記錄。對于Verilog屬性不存在等效。將包之外的注釋添加至文件頭部概要。語法解釋
如上所述，很多VHDL語言結構都可以視為滿足“單元”的定義，包括實體、配置、架 構、過程、函數(shù)、組件、類型和子類型。VHDL支持名稱重載，這意味著給定的名稱可以映射至多個對象。編譯器使用上下 文和類型信息來選擇適合的對象。語言定義非常依賴于這兩個概念，因為在其包含的文件完全不可用的情況下，解 析VHDL文件易于出錯。因為原型規(guī)范化單元概要解析器不是針對邏輯綜合而設計的，并且 因為其工作的上下文(例如include文件)可能隨時間改變，所以其使用允許無上下文解 析的稍微簡化的語言規(guī)范。VHDL還支持運算符重載，意味著可能存在具有不同類型和參數(shù)的相同對象的多個 版本。例如，可以存在若干乘法運算符。最終，針對給定設計實體，可能存在多個架構。這些應該是可互換的；設計者在實 例化模塊時指定要使用哪個架構。由此，為VHDL設計的所有方面生成規(guī)范化單元概要需要歧義消除。兩個到四個部 分的已編碼名稱被指派給被記錄為單元的對象 包名稱，用于存儲在包中的對象 對象類型，例如架構或者函數(shù)·由設計者指定的對象名稱 編號后綴，用于通過名稱重載的對象例如，Vital_timing. constant, edgesymboImatch 表不包 vital_timing 中的 常量 edgesymbo lmatch,而 vital_timing. procedure, vitalerror. 1 表不該包中名禾爾為 vitalerror的第二過程。因為規(guī)范單元概要是在逐個文件的基礎上計算的，所以用戶的軟 件在將概要排序到數(shù)據(jù)庫中時可能必須進一步對名稱消除歧義。對于具有獨立規(guī)范和主體 的過程和函數(shù)尤其如此——解析器直到很晚(在參數(shù)列表之后)才知道其是否具有規(guī)范或 者主體，而在那時，單元名稱已經(jīng)被傳送至概要引擎。VHDL規(guī)范還提供嵌套的對象定義，例如過程內(nèi)的函數(shù)。因為這些可以被無限地嵌 套，并且因為其范圍限于包含對象(使得其對于外部不可見)，所以不針對這些對象創(chuàng)建獨 立單元。其被記錄為包含對象的單元主體的一部分。VHDL規(guī)范使用IS0/IEC 8859-1標準中定義的8比特字符集。解析器具有針對所 有有效8比特字符的完全支持。除了擴展標識符以外，VHDL是不區(qū)分大小寫的；在向概要引擎發(fā)送之前，解析器 將擴展標識符以外的所有記號都轉(zhuǎn)換為小寫。VHDL文件的排序VHDL中的很多語句是順序相關的，由此無法進行排序。解析器不嘗試確定架構或 者子程序主體的哪些部分是順序無關的——其僅排序其聲明中的參數(shù)。因為實例化可能不 使用順序無關的參量規(guī)范，所以在排序之后找到的概要匹配可能不表示實際匹配。由此， VHDL文件的排序應當謹慎進行?？梢灾饌€指定參數(shù)聲明，或者如果類型相同，則在列表中指定。例如，以下聲明集 合是等效的X，Y，Cin :in Bit ；
38
Cout, Sum :out Bit ；以及X in Bit;Y:in Bit;Cin : in Bit;Cout :out Bit ；Sum :out Bit ；解析器將參數(shù)聲明從第一形式擴展至第二形式。繼而可以根據(jù)參數(shù)的名稱對其進 行排序。因為entity是與一個或多個architecture的接口的規(guī)范，所以entity中的所有 內(nèi)容都被視為接口的部分，即使單詞is之后的實體語句也是。頂層對象(單元)的名稱將被發(fā)送至概要引擎，以使得有可能發(fā)生具有不同名稱 的等效單元的匹配。頂層對象內(nèi)的變量聲明(包括子程序聲明)的名稱被記錄為單元接口 文本，但是這些變量內(nèi)的任何聲明的名稱沒有記錄。例如，參見帶注解樣本文件、圖IOA-圖 10B。原型VHDL解析器的限制垂直制表符和換頁符被轉(zhuǎn)換為換行符，即使在將其添加至文件級概要之前也是如 此。回車/換行對在被添加至文件級概要之前被轉(zhuǎn)換為單個換行符。解析器不嘗試組合常量。例如，不執(zhí)行字符串文字并置?！癮bcdef”將不具有與 “abc”和“def”相同的概要。不解釋包含文件指令(library和use子句)，因為概要計算時的包含路徑可能不 同于編譯時的包含路徑。不對過程單元和函數(shù)單元中的參數(shù)列表進行排序；解析器可能不知道過程或者函 數(shù)中的參數(shù)的名稱，因為其聲明可能在另一文件中。即使參數(shù)處于使用= >的關聯(lián)列表中， 這也是成立的。在無解釋的情況下將數(shù)值文字發(fā)送至概要引擎。特別地，不將其首先轉(zhuǎn)換為規(guī)范 化形式。例如，指數(shù)中的加號是可選的，所以IelO將不同于le+10。數(shù)字不是不重印的，所 以IelO也將不同于1. OelO0解析器不嘗試確定何時可以將VHDL對象視為層級式的。帶注解樣本VHDL文件圖IOA-圖IOB示出了帶注解樣本VHDL文件。注意，在architecture MC68000中，第一級嵌套函數(shù)(bclr_d)的名稱被記錄為接 口文本，但是第二級嵌套函數(shù)(nested)的名稱沒有記錄。這是因為bclr_d被視為接口變 量，類似于過程VitalWireDelay中的變量Delay。沒有任何嵌套過程被記錄為獨立單元； 二者都被視為architecture MC68000的部分。
示例5-6: OASIS 和GDSII文件類型 在此示例中，將一起描述具有相同文件元素的OASIS 和⑶SII文件類型。這些文 件類型具有針對以下文件元素的內(nèi)容概要
文件 文件頭部 逐層幾何對象 逐層非幾何對象 對低級單元的引用 涉及其他低級單元的布爾標志掃描數(shù)據(jù)庫以找到內(nèi)部的單元名稱。針對存在的單元，計算以下各項 所有幾何對象(多邊形、矩形等)的逐層概要； 所有非幾何對象(文本點等)的逐層概要； 針對所有其他對象(諸如對低級單元的引用)的概要；以及 指示單元是否具有對低級單元的引用的布爾標志。作為一個選項，在概要計算之前對小規(guī)模和中等規(guī)模單元中的數(shù)據(jù)進行排序，使 得數(shù)據(jù)排列差異不會引起概要差異。用戶可以設置用于該選項的存儲器使用限制。在概要計算之前對OASIS 重復和⑶SII數(shù)組引用進行展開，以使得重復分析的差 異不會引起概要差異。針對文件的頭部(任何單元定義之前的信息)以及針對整個文件而計算和返回概 要。對于⑶SII文件，假設該文件是語法正確的。結構(單元)創(chuàng)建和修改時間被存儲為注釋；如果其在兩個其他方面相同的單元 中不同，則單元概要和注釋概要將不同，但是所有的層概要將是相同的。不認為⑶SII或者OASIS 單元中的任何數(shù)據(jù)是“頭部”(對單元的接口 )的一部 分。假設其由外部工具生成并且存儲在其他任何地方(例如LEF)。對于⑶SII或者OASIS 文件，不計算“空白”概要。結構引用(SREF和AREF)被報告為針對具有索引-1的非層數(shù) 據(jù)的概要的一部分。在概要計算之前還可以執(zhí)行⑶SII或者OASIS 多邊形排序以及⑶SII 或者OASIS 多邊形合并(重疊移除)。OASIS 布局文件OASIS 文件是用于指定布局的結構化二進制文件。該格式可以具有多種不同方 法以用于減少文件所需空間，諸如重復和壓縮數(shù)據(jù)塊。這些可能改變數(shù)據(jù)在單元中出現(xiàn)的 順序，或者甚至可能改變用于表現(xiàn)數(shù)據(jù)的數(shù)據(jù)構造(例如，RECTANGLE與CTRAPEZ0ID)。在 內(nèi)部，為了確保一致表示，所有幾何構造都被轉(zhuǎn)換為POLYGON記錄并且重復被展開。在適當?shù)那闆r下，如果具有充足的存儲器或者盤空間可用，則默認對OASIS 文件 數(shù)據(jù)進行排序。數(shù)據(jù)按層分組，并且繼而按位置分組，從而生成相同的概要而不考慮數(shù)據(jù)原 來在單元內(nèi)如何排列。只要數(shù)據(jù)進行了排序，并且單元中不存在OASIS 特性，用戶的軟件 就應當能夠在OASIS 單元及其等效⑶SII表示之間匹配概要。為了避免浮點舍入誤差，基于單元內(nèi)的布局數(shù)據(jù)的整數(shù)坐標來計算概要。因為用 戶的優(yōu)選設計柵格可能隨時間改變，所以基于用戶使用-grid命令行選項指定的較小柵格 來計算規(guī)范化單元概要。用戶應當細心選擇該柵格，以擔保所有的將來設計柵格是其整數(shù) 倍。默認該柵格是1納米(1. Oe-9米)；其可以最佳地設置為較小的值，諸如0. 5納米或者 0.25納米。然而，如果柵格過小，用戶在32比特機器上可能得到整數(shù)算術溢出。
因為所有的重復都被擴展以確保一致的表示，所以針對規(guī)范化單元概要計算的運 行時性能即使對于相同大小的文件也可能顯著改變。這里是針對OASIS 文件的概要報告的一部分Cell ‘‘ Structure」" (not sorted)f64ce851 Cell with Commentsf64ce851 Cell without Comments(none) Cell Comments20b84e54 Cell Body non-Layere03bf9d2 Cell Body Layer 3fda35715 Cell Body Layer 42cb6c08c2 Cell Body non-Geometric Data Layer 3在此示例中，沒有請求排序，并且這在單元名稱之后b被報告。OASIS 單元中沒 有任何數(shù)據(jù)被記錄為單元注釋數(shù)據(jù)，所以概要被報告為“ (none) ”。存在記錄為非層數(shù)據(jù)的 一些結構引用，以及層3和42上的一些幾何形狀。最后，層3上存在一些非幾何數(shù)據(jù)(一 個或多個TEXT記錄)。OASIS 格式文件定義開放原圖系統(tǒng)交換標準(OASIS )格式由半導體設備和材料國際協(xié)會(SEMI)開 發(fā)，以作為對GDSII的代替。其移除了數(shù)值的16比特和32比特限制，并且對布局文件大小 的改善高達因數(shù)10。原型OASIS 解析器遵循SEMI標準P39-1105 (2005年11月)中描述 的規(guī)范。支持名稱表。OASIS 是二進制格式，所以為了清楚起見，本說明書使用OASIS 規(guī)范中列出的記 錄名稱。OASIS 文件的語法解釋OASIS .規(guī)范提供了任意精度的整數(shù)和浮點數(shù)。然而，針對任意精度算術的算術封
包較慢，并且沒有在設計自動化業(yè)界被廣泛使用。原型解析器使用自然數(shù)(當以32比特模 式編譯時是32比特，當以64比特編譯時是64比特)以及IEEE雙精度浮點數(shù)(64比特)。 如果文件中出現(xiàn)超過這些限制的數(shù)字，則將記錄(log)錯誤。該規(guī)范還提供若干不同的數(shù)字表示，諸如無符號整數(shù)、帶符號整數(shù)、比率、倒數(shù)和 浮點。所有數(shù)字都被轉(zhuǎn)換為用于比較的規(guī)范化形式一用于整數(shù)值的自然數(shù)以及用于浮點值 的雙精度浮點數(shù)。這允許由不同工具編寫的數(shù)字的匹配，例如，5/2和2. 5。以類似的方式，在計算概要之前，將所有點列表(例如，Ι-delta列表)完全展開為 X/Y坐標對列表。設計工具具有相當大的自由度來選擇用于表示布局單元的幾何形狀的OASIS 元 素。雖然布局編輯器通常將保存設計者的選擇，例如PATH與POLYGON，但是最終輸出可能具 有等效POLYGON，以便減少PATH定義在彎曲處固有的歧義。此類工具還可能將POLYGON的 “繞線方向”從逆時針改變?yōu)轫槙r針。為了避免這些問題，將所有的幾何元素轉(zhuǎn)換為用于規(guī) 范化單元概要計算的規(guī)范化表示·將 RECTANGLE、PATH、TRAPEZOID、CTRAPEZ0ID 和 CIRCLE 元素轉(zhuǎn)換為等效的
41POLYGON 記錄 如果所產(chǎn)生的多邊形具有逆時針繞線方向，則將POLYGON點列表反轉(zhuǎn) 選擇列表中的第一個點作為最左下方的點如果PLACEMENT記錄中存在翻轉(zhuǎn)(flip)，則將其進行排序如同其是⑶SII STRANS 記錄一樣(比特數(shù)組)。如果PLACEMENT對象使用數(shù)字單元引用，則利用其對應的單元名稱來替換數(shù)字， 并且僅將單元名稱發(fā)送至概要。OASIS 規(guī)范提供了所有構造的重復。不同的工具可以選擇優(yōu)化重復的不同方法。 數(shù)據(jù)不管如何成組都是等效的，所以為了正規(guī)起見，將所有的重復展開為單對象引用(例 如，矩形或者PLACEMENT記錄)。為此，無法擔保取決于文件大小的運行時性能一重復展開 至上億多邊形的較小文件將需要大量的CPU時間。OASIS 文件還與較老的⑶SII格式文件共存。OASIS 使用描述重復的對象引用 的不同方法，所以除非重復被展開，否則其將不能將重復的PLACEMENT對象與⑶SII AREF 進行匹配。注意，在一些實施方式中，基于OASIS 文件中的對象而不是下層的幾何形狀來計 算概要。在計算概要之前，不執(zhí)行重疊移除。OASIS 格式被設計為移除了對規(guī)范的“擴展”的需要。如果OASIS 文件沒有遵 循規(guī)范，則解析器將返回錯誤。OASIS 層主要由編號進行索引(所有的幾何構造都使用層編號，而不是層名稱)； 解析器目前不返回層名稱(如果有的話)到編號的映射。在文件的前端，使用柵格來指定OASIS 文件中的坐標，例如1納米(1. 0e_9米)。 在單元內(nèi)，所有的坐標按照該柵格來定義，使其可以是整數(shù)。然而，文件柵格可能改變，而不 會影響最終掩膜數(shù)據(jù)。例如，即使標準柵格是1納米，所導入的設計模板塊也可以使用5納 米的柵格進行指定。用戶的軟件繼而將轉(zhuǎn)換所有導入的數(shù)據(jù)，以使用較小柵格，利用因數(shù)5 來縮放單元中的整數(shù)坐標。為了確保正規(guī)，對OASIS 文件中的所有幾何形狀進行縮放以使用內(nèi)部的規(guī)范化 單元概要柵格。用戶應當細心選擇該柵格，以使得將可兼容所有將來設計中使用的OASIS 文件柵格。例如，如果目前設計柵格是5納米，則最佳地使用1納米或者甚至0.5納米的概 要柵格。將規(guī)范化單元概要柵格值傳送至OASIS 解析器，并且如果OASIS 文件柵格不是 規(guī)范化單元概要柵格值的整數(shù)倍，則返回錯誤。將具有PLACEMENT記錄的結構標記為層級式的以用于概要報告。OASIS 文件的排序如所提到的，OASIS 文件使用與GDSII文件不同的方法來指定成組的結構引用。 不同的供應商也可選擇不同的重復優(yōu)化方法。最終，可能在任何時刻對單元內(nèi)的幾何對象 重新排序，而不改變文件的含義。由此OASIS 布局的比較或者⑶SII布局與OASIS 布局 的比較需要排序。為此，默認支持⑶SII和OASIS 布局的排序。在將幾何對象轉(zhuǎn)換為規(guī)范化形式之后，可以按照如下將其與另一對象進行比較以用于排序目的 層名稱是主關鍵字；首先是較低層編號 元素類型(使用GDSII記錄類型)是次關鍵字；較低元素類型排在前面 元素的XY坐標(如果有的話)是第三關鍵字；對坐標逐個進行比較，并且針對 給定條目具有最低、最左邊的點的元素排在前面 如果存在位置變換(即翻轉(zhuǎn))，則比較被轉(zhuǎn)換為整數(shù)的比特向量，并且“最低”的 一個排在前面 接下來，比較DATATYPE值，并且最低的一個排在前面 如果記錄是位置，則按照字母順序比較單元名稱值，并且最低的一個排在前面 接下來，比較MAG值(如果有的話)，并且最低的一個排在前面 接下來，比較ANGLE值(如果有的話)，并且最低的一個排在前面 最后，逐個比較PROPERTY值期望將僅使用前三種比較(層名稱、元素類型和XY位置)，以使其他比較的順序在 某種程度上可以是任意的。排序標準實際上與用于⑶SII的排序標準相同；已經(jīng)從以上描述中忽略了不適用 OASIS 的字段。使用在OASIS 中不具有有模擬的⑶SII字段(例如，PLEX)或者在OASIS 中不同的GDSII字段(例如，特性)將會阻止跨格式的單元匹配。如果請求了排序，則收集單元中的記錄直到到達單元的結尾或者直到存儲器中存 儲了超過使用限制的單元數(shù)據(jù)。如果發(fā)生上述情況，則將所存儲的單元記錄按照其原始順 序發(fā)送至概要模塊，或者可以使用盤排序來對其排序，這是以基本性能為代價。在逐個單元 的基礎上執(zhí)行存儲器測試，所以某些單元可以被排序，而某些可以不被排序。根據(jù)單元是否 已經(jīng)被排序而對單元進行標記；該信息在概要報告中并且通過API可得。不對文件頭部對象進行排序。原型OASIS 解析器的限制假設OASIS 文件符合SEMI P39語法和語義。沒有錯誤是被容忍的。僅報告一個 錯誤；解析器不嘗試繼續(xù)通過第一錯誤。目前，XELEMEMT、XGE0METRY和XNAME記錄被丟棄，而不被記錄(在文件級概要中 除外)。丟棄PAD記錄而不進行記錄(在文件級概要中除外)。不測量文件中的名稱表所使用的存儲器；這可能使得實際存儲器使用超過所請求 的限制。元素的特性被記錄為與元素本身相同的類型(幾何數(shù)據(jù))。OASIS 中PROPERTY記 錄的定義顯著區(qū)別于⑶SII中的PR0PATTR記錄，并且其將沒有可能與其中具有帶特性(除 了可兼容的S_GDS_PR0PERTY以外)元素的單元相匹配。LAYERNAME表(如果有的話)不由OASIS 解析器返回，所以僅層編號信息可用于
與概要一起使用。如果零面積多邊形的點以“錯誤”順序繪制，則不對其進行反轉(zhuǎn)。這可能使得比較 包含零面積多邊形的⑶SII和OASIS 文件較困難。帶注解樣本OASIS 文件
圖11是帶注解樣本OASIS 文件。因為OASIS 是二進制文件格式，所以使用 OASIS 記錄名稱，并且為了簡便，對個體元素的某些部分進行縮寫。元素內(nèi)的所有字段具 有相同的記錄類型，所以未失一般性。為了規(guī)范化，將RECTANGLE、PATH、TRAPEZOID、CTRAPEZ0ID 和 CIRCLE 元素轉(zhuǎn)換為 具有順時針環(huán)繞的等效POLYGON元素。由此，附圖中沒有示出這些元素類型。選擇點列表 中的第一點作為最低最左邊的點。使用⑶SII BOUNDARY記錄號，以使得OASIS 單元可以 與⑶SII單元相匹配。使用⑶SII TEXT元素號來記錄TEXT元素，以使得僅使用TEXT的OASIS 單元可 以與⑶SII單元相匹配。注意，不存在OASIS 到⑶SII NODE元素的模擬。在計算概要之前擴展CBLOCK記錄，所以其不會成為規(guī)范化單元概要的一部分。規(guī) 范化單元概要將是相同的，而不管是否存在CBLOCK記錄。在不擴展CBLOCK記錄的情況下計算文件級概要。記錄名稱和其他字符串，如同它與其所用于的記錄一起存在一樣，無論名稱表是 否存在于文件中。名稱和其他字符串表本身不被添加至任何規(guī)范化單元概要中。與名稱記 錄相關聯(lián)的特性(例如，CELLNAME)被添加至文件頭部非層幾何概要中。所有的幾何記錄在被發(fā)送至概要引擎之前被完全展開；不進行模態(tài)變量的隱含使 用。這對于排序以及與⑶SII文件的匹配是有用的。為此，XYRELATIVE和XYABS0LUTE記 錄不是任何規(guī)范化單元概要的一部分；其僅確定如何(相對于先前對象或者絕對坐標)解 釋XY坐標。特性與緊跟在其后的對象被一起記錄。如果該對象具有層編號，則其根據(jù)該層編 號來記錄。不對文件前端(并且由此在任何單元以外)的特性進行排序；在其發(fā)生時對其 進行記錄。在發(fā)送至概要引擎之前，將類型17(正交旋轉(zhuǎn))的PLACEMENT對象轉(zhuǎn)換為類型 18 (任意旋轉(zhuǎn))的PLACEMENT對象，以便與⑶SII中的定義相匹配。對于結構接口(例如，邊界框、鄰接框和布線器接入點)不存在行業(yè)標準，所以沒 有任何結構接口被記錄為單元頭部數(shù)據(jù)。示例6 (繼續(xù))⑶SII布局文件⑶SII文件是用于指定布局的結構化二進制文件。根據(jù)用于編寫⑶SII文件的 工具，數(shù)據(jù)在單元中出現(xiàn)的順序可能改變，并且某些構造(尤其是PATH)可以被轉(zhuǎn)換為較 無歧義的表示(BOUNDARY)。在內(nèi)部，為了擔保一致的表示，將所有的幾何構造都轉(zhuǎn)換為 BOUNDARY(多邊形)記錄，并且將數(shù)組引用(AREF)擴展為等效的構造引用(SREF)序列。在適當時，如果具有足夠的存儲器或者盤空間可用，則默認對GDSII文件數(shù)據(jù)進 行排序。通過層并且繼而通過位置對數(shù)據(jù)進行分組，以使得無論數(shù)據(jù)起初在單元內(nèi)如何排 序都生成相同的概要。只要對數(shù)據(jù)排序，并且單元中不存在GDSII NODE記錄或者特性，用 戶的軟件就應當能夠在⑶SII單元與其等效OASIS 表示之間進行匹配。為了避免浮點舍入錯誤，基于單元內(nèi)的布局數(shù)據(jù)的整數(shù)坐標來計算概要。因為用 戶的優(yōu)選設計柵格可能隨時間改變，所以基于用戶使用-grid命令行選項指定的較小柵格 來計算規(guī)范化單元概要。用戶應當細心選擇該柵格，以確保所有將來設計柵格是它的整數(shù)倍。默認該柵格是1納米(1. Oe-9米)；可以最佳地設置為諸如0. 5納米或者0. 25納米的 較小值。然而，如果柵格過小，則用戶可能在32比特機器上得到整數(shù)算術溢出。因為展開了所有的AREF(成組結構引用)以確保一致表示，所以針對規(guī)范化單元 概要計算的運行時性能可能顯著改變，即使對于相同大小的文件也是如此。這里是針對⑶SII文件的概要報告的一部分Cell ‘‘ Structure」" (sorted)a7100492 Cell with Comments3d4d7fbf Cell without Comments9a5d7b2d Cell Comments7b78aab4 Cell Body non-Layer15546763 Cell Body Layer 3fda35715 Cell Body Layer 42aec2e57d Cell Body non-Geometric Data Layer 3在此示例中，單元小到足以進行排序，并且這在單元名稱之后報告。單元修改和訪 問時間被記錄為注釋，層3和42上存在記錄為非層數(shù)據(jù)的某些結構引用以及某些幾何形 狀。最后，層3上存在某些非幾何數(shù)據(jù)(一個或多個NODE或者TEXT記錄)。⑶SII流式文件定義⑶SII是早期的布局數(shù)據(jù)庫格式，最初由Calma公司在20世紀80年代制定，并且 現(xiàn)在歸Cadence所有。原型⑶SII解析器遵循具有Y2K附加的Cadence Virtuoso設計數(shù) 據(jù)翻譯器參考中描述的規(guī)范。GDSII是二進制格式，所以為了清楚起見，本說明書使用GDSII規(guī)范中列出的記錄 名稱。⑶SII文件的語法解釋在缺少行業(yè)標準規(guī)范的情況下，工具供應商多年來“擴展” 了 GDSII格式。例如， GDSII文檔注意到節(jié)點、文本點或者幾何對象的最大層編號是255，但是某些工具允許多達 32，767個層(最大可能的帶符號16比特整數(shù))。類似地，⑶SII文檔將邊界(多邊形)和 路徑(線路)被限制到200個點，但是某些工具允許多達4，094個點(可以適合65，535字 節(jié)記錄的最大點數(shù))。為了支持這些擴展同時仍然提供相同的檢查水平，解析器接受“變動” 記錄，其指定了針對以下的限制 結構名稱長度(默認32，最大32，750) 結構名稱中允許的附加字符(在“A-h-z0-9_ ？ $”以外) 最大層編號、數(shù)據(jù)類型或者文本類型(默認64，最大32，767) 最大特性屬性數(shù)目(默認64，最大32，767) 最大BOUNDARY或者PATH點計數(shù)(默認200，最大4，094) 最大節(jié)點計數(shù)(默認50，最大4，094) 最大特性值長度(默認128，最大32，767)· AREF中的晶格向量是否可以旋轉(zhuǎn)或者其是否正交并且在第一象限· AREF中的旋轉(zhuǎn)是否意味著晶格被剛性旋轉(zhuǎn)或者實例按照其指定在晶格內(nèi)的位 置中旋轉(zhuǎn)
除了對這些方面的修改以外，如果⑶SII文件不符合規(guī)范，則解析器將返回錯誤。設計工具具有相當大的自由度來選擇用于表示布局單元的幾何形狀的GDSII元 素。雖然布局編輯器通常將保存設計者的選擇，例如，PATH與BOUNDARY，但是最終的流式輸 出可以代替地使用等效的BOUNDARY，以便減少PATH的定義在彎曲處固有的歧義。此類工具 也可以將BOUNDARY的“繞線方向(winding direction) ”從逆時針改變?yōu)轫槙r針。為了避 免這些問題，將所有的幾何元素轉(zhuǎn)換為用于規(guī)范化單元概要計算的規(guī)范化表示 將PATH元素轉(zhuǎn)換為等效的BOUNDARY記錄 如果BOUNDARY點列表中的最后一個點與第一個點一致，則將其移除 如果所產(chǎn)生的多邊形具有逆時針繞線方向，則反轉(zhuǎn)BOUNDARY點列表 選擇列表中的第一個點作為最低最左邊的點⑶SII文件還與較新的OASIS 格式文件共存。OASIS 使用描述重復的對象引用 的不同方法。為了正規(guī)，將AREF(成組結構引用)對象擴展為等效的個體SREF(結構引用) 對象序列。在OASIS 解析器(重復被展開)中同樣如此，從而可以將針對⑶SII文件與 OASIS 文件中布局的概要進行比較。為此，無法擔保取決于文件大小的運行時性能一具有 擴展為上億個SREF的AREF的較小文件將需要大量的CPU時間，因為SREF被一次一個地添 加到概要中。⑶SII規(guī)范要求AREF晶格是正交的并且在第一象限(S卩，第一晶格向量沿正X軸， 而第二晶格向量沿正Y軸)中，繼而如果指定了鏡像或者旋轉(zhuǎn)，則相應地進行剛性的鏡像或 者旋轉(zhuǎn)。很少有CAD工具實際使用該定義；相反，晶格向量被旋轉(zhuǎn)和/或鏡像，并且實例被 放置到轉(zhuǎn)換的晶格中。原型GDSII解析器默認使用該定義；API中存在使用原始定義的選 項。注意，基于GDSII文件中的對象而不是下層的幾何形狀來計算概要。在計算概要 之前不執(zhí)行重疊移除。在文件前端，使用例如1納米(l.Oe-9米)的柵格來指定⑶SII文件中的坐標。 在單元內(nèi)，所有的坐標按照該柵格來定義，使得其可以是整數(shù)。然而，文件柵格可以改變，而 不影響最終掩膜數(shù)據(jù)。例如，雖然標準柵格是1納米，但是也可以使用5納米的柵格來指定 導入的設計模板塊。用戶的軟件繼而將轉(zhuǎn)換所有導入的數(shù)據(jù)以便使用較小柵格，通過因數(shù) 5來縮放單元中的整數(shù)坐標。為了確保正規(guī)，縮放GDSII文件中的所有幾何形狀，以使用內(nèi)部規(guī)范化單元概要 柵格。用戶應當細心選擇該柵格，以使得所有將來設計中使用的GDSII文件柵格將是可兼 容的。例如，如果目前設計柵格是5納米，則最佳地使用1納米或者甚至0.5納米的規(guī)范化 單元概要柵格。將規(guī)范化單元概要柵格值傳送至⑶SII解析器，并且如果⑶SII文件柵格不是規(guī) 范化單元概要柵格值的整數(shù)倍，則返回錯誤。將具有SREF或者AREF記錄的結構標記為層級式的以用于概要報告。⑶SII文件的排序如所提到的，GDSII文件使用與OASIS 文件不同的方法來指定成組結構引用。
OASIS 文件編寫者具有很大的自由度來通過使用重復而對幾何對象或者結構引用進行聚
類。不同的供應商可能選擇不同的重復優(yōu)化方法。最終，可以在任何時刻重新排列單元內(nèi)
46的幾何對象，而不改變文件的含義。⑶SII布局或者⑶SII布局與OASIS 布局的有效比較 由此需要排序。為此，默認支持⑶SII和OASIS 布局的排序。在將幾何對象轉(zhuǎn)換為規(guī)范化形式之后，可以按照如下將其與另一對象比較以用于 排序目的 層名稱主關鍵字；較低層編號排在前面 元素類型(使用GDSII記錄類型)是次關鍵字；較低元素類型排在前面 元素的XY坐標(如果有的話)是第三關鍵字；逐個比較坐標，并且針對給定條 目，具有最低最左邊的點的元素排在前面 如果存在STRCLASS，則比較轉(zhuǎn)換為整數(shù)的比特向量，并且“最低”的一個排在前 面 如果存在ELFLAGS，則比較轉(zhuǎn)換為整數(shù)的比特向量，并且“最低”的一個排在前面 如果存在PRESENTATION，則比較轉(zhuǎn)換為整數(shù)的比特向量，并且“最低”的一個排 在前面 如果存在STRANS，則比較轉(zhuǎn)換為整數(shù)的比特向量，并且“最低”的一個排在前面 接下來，比較PLEX值(默認為0)，并且最低的一個排在前面 接下來，比較DATATYPE值，并且最低的一個排在前面 接下來，比較PATHTYPE值(如果有的話)，并且最低的一個排在前面 如果記錄具有STRING值，則按字母順序比較這些值，并且最低的一個排在前面 如果記錄是STRANS (結構變換)，則按字母順序比較SNAME值，并且最低的一個 排在前面 接下來，比較MAG值(如果有的話)，并且最低的一個排在前面 接下來，比較ANGLE值(如果有的話)，并且最低的一個排在前面 最后，逐個比較PR0PATTR值期望將僅使用前三種比較(層名稱、元素類型和XY位置)，以使得其他比較的順序 可以或多或少是任意的。這些排序標準中的一些也用于OASIS 文件使用在OASIS 中不具有模擬的⑶SII字段(例如，PLEX)或者在OASIS 中不同 的⑶SII字段(例如，特性)將阻止跨格式的單元匹配。如果請求了排序，則收集單元(GDSII結構)中的記錄直到到達單元的結尾或者直 到存儲器中存儲了超過使用限制的單元數(shù)據(jù)。如果發(fā)生上述情況，則將所存儲的單元記錄 按照其原始順序發(fā)送至概要模塊。針對單元執(zhí)行存儲器測試，所以某些單元可以被排序，而 某些可以不被排序。根據(jù)單元是否已經(jīng)被排序而對單元進行標記；該信息在概要報告中并 且通過API可得。文件頭部對象具有指定的順序，所以其不被排序。原型⑶SII解析器的限制假設⑶SII文件遵循針對⑶SII的Cadence規(guī)范，除了可以放松某些數(shù)字限制以 外，如上所述。AREF晶格還可以在旋轉(zhuǎn)方向中指定。除了這些變動之外，不容忍任何例外或 者錯誤。僅報告一個錯誤；解析器不嘗試繼續(xù)越過第一錯誤。目前沒有改變來自命令行的行為標志和數(shù)字限制的方式。API能夠定義針對上述所有項目的變動。PR0PATTR記錄在⑶SII中具有與OASIS 中的PROPERTY記錄不同的結構。 PR0PATTR記錄的使用將阻止⑶SII單元與OASIS 單元的匹配，除非OASIS PROPERTY記 錄使用S_GDS_PR0PERTY格式。如果零面積BOUNDARY和BOX的點以“錯誤”順序繪制，則不對其進行反轉(zhuǎn)。這可 能使得比較包含零面積多邊形的⑶SII和OASIS 文件較困難。在BOX記錄和BOUNDARY記錄不等效的假設下，不將BOX記錄轉(zhuǎn)換為BOUNDARY記 錄；BOX記錄不比BOUNDARY記錄有效，所以假定其是有意不同地繪制的。帶注解樣本⑶SII文件圖12是帶注解樣本⑶SII文件。因為⑶SII是二進制文件格式，所以使用⑶SII 記錄名稱，并且為了簡便，對個體元素的某些部分進行縮寫。元素內(nèi)的所有字段具有相同的 記錄類型，所以未失一般性。結構的修改和訪問時間被記錄為單元注釋。結構類記錄也被記錄為單元注釋。對 于結構接口(例如，邊界框、鄰接框和布線器接入點)不存在行業(yè)標準，所以沒有結構接口 被記錄為單元頭部數(shù)據(jù)。⑶SII中的層是數(shù)值的；不返回層名稱的列表。在將PATH元素發(fā)送至概要生成之前，使用路徑類型以及任何BGNEXTN或者 ENDEXTN記錄將其轉(zhuǎn)換為BOUNDARY元素。將路徑類型1 (圓端)轉(zhuǎn)換為路徑類型2 (超過端 點半個寬度的方端)。如果PATH元素具有銳角，則在等于接線寬度一半處截去任何此類彎曲的轉(zhuǎn)角。 PATH的外部以順時針方向跟蹤(trace)；將最低、最左邊的點選為第一個。列表中的最后一 個點與第一個不一致；相反，存在隱式的邊緣。將負PATH寬度默默地轉(zhuǎn)換為正路徑寬度，從而移除其“絕對路徑寬度”特性。該 轉(zhuǎn)換不記錄在概要中。如果BOUNDARY元素的點列表具有逆時針環(huán)繞，則將其反轉(zhuǎn)；之后，將最低、最左邊 的點選為第一個。根據(jù)GDSII規(guī)范與第一個點重疊的最后的點被移除，以使得存在隱式邊緣。如果BOX元素的點列表具有逆時針環(huán)繞，則將其反轉(zhuǎn)；之后，將最低、最左邊的點 選為第一個。根據(jù)GDSII規(guī)范與第一個點重疊的最后的點被移除，以使得存在隱式邊緣。在 假設BOX元素旨在用于不同目的時，不將BOX元素轉(zhuǎn)換為BOUNDARY元素。在將數(shù)組引用(AREF元素)發(fā)送至概要生成之前，將其擴展為等效的SREF元素列表。將元素的屬性記錄為與元素本身相同的類型(幾何數(shù)據(jù))。還有可能將其記錄為 非幾何數(shù)據(jù)，因為OASIS 中的屬性定義顯著不同，并且其否則將無法匹配其中具有帶屬性 元素的單元。在將⑶SII記錄中的比特數(shù)組(例如，STRANS)發(fā)送至概要計算之前，將其轉(zhuǎn)換為整數(shù)。示例7 非結構化文本文件類型非結構化文本文件是不具有規(guī)范化單元概要工具已知的規(guī)范的文本文件。例如，設計模板塊的人類可讀描述或者日志文件將是非結構化文本文件。然而，文本文件是面向 行的，所以其仍然可以進行排序。如果請求了排序，則文件頭部數(shù)據(jù)概要將改變以反映排 序。否則其將匹配文件概要。在此示例中，非結構化文本文件具有針對文件逐個字節(jié)的內(nèi)容概要。針對非結構 化文本文件計算逐個字節(jié)概要。該概要獨立于換行樣式。作為一個選項，忽略空白的差異。命令行選項-mergewhite、-reportwhite禾口 -discardwhite控制針對基于文本文 件格式的文件級空白概要的報告?？瞻装崭瘛⒅票矸蛽Q行符。-mergewhite選項是默 認的；當其活躍時，報告單個文件級概要，包括空白和非空白二者。當_r印ortwhite選項活 躍時，單獨報告針對空白和非空白的概要。當-discardwhite選項活躍時，忽略空白，并且 報告排除空白的單個文件級概要。例如，如果將樣本文件testfiles/verilog_test. ν視為非結構化文本文件，則將 獲得以下結果otismartsig -txt -mergewhite testfiles/verilog_test. νFile " testfiles/verilog_test. ν" unstructured text formatFile CRC 5404c699otismartsig -txt -reportwhite testfiles/verilog_test. νFile " testfiles/verilog_test. v" unstructured text formatFile CRC 5404c699File non-whitespace CRC 7c2a352dFile whitespace CRC 219bl881otismartsig -txt -discardwhite testfiles/verilog_test. νFile " testfiles/verilog_test. v" unstructured text formatFile CRC 7c2a352d注意，第一示例中合并的文件概要與第二示例中的完全文件概要相匹配，并且第 二示例中的非空白概要與第三示例中的文件概要相匹配。不針對基于單元的格式(諸如Liberty或者Verilog)中的個體單元計算空白和 非空白概要；其僅在文件級計算。三種空白報告選項也可以用于結構化文本文件格式。例如otismartsig -discardwhite -ver testfiles/verilog_test2. νFile " testfiles/verilog_test2. ν" Verilog formatFile CRC 07f87fb9File header CRC 6ef229e6File comment CRC 6ef229e6Cell “ 0AI21_X1〃Interface CRC dae46517Contents CRC c73aceafCell “ 0AI21_X2〃Interface CRC 01391569Contents CRC c73aceaf
語法解釋針對非結構化文本文件計算文件級(所有文件數(shù)據(jù)、非空白數(shù)據(jù)和空白數(shù)據(jù))以 及文件頭部概要。針對文件中的所有數(shù)據(jù)計算文件頭部概要，如果請求則按字母對行進行 排序。如果文件具有DOS樣式(CR-LF)行結尾，則在計算任何概要之前將其轉(zhuǎn)換為UNIX樣 式(僅LF)行結尾。非結構化文本文件的排序如果請求了排序，并且存儲器使用限制足夠高，則在計算文件頭部概要之前對文 件的行進行排序。將所有數(shù)據(jù)記錄為非層、非注釋文件頭部數(shù)據(jù)。原型非結構化文本文件解析器的限制目前，不存在將空白轉(zhuǎn)換為規(guī)范化形式(例如，將制表符轉(zhuǎn)換為空格或者移除重 復的空格)的選項。示例8 非結構化和結構化二講制文件針對非結構化二進制文件(或者沒有解析器的結構化二進制文件)的概要僅僅是 沒有解釋的序列中的所有字節(jié)的CRC。針對示例⑶SII文件testfiles/sigtest. gds的概 要可以計算如下otismartsig -bin testfiles/sigtest. gdsFile testfiles/sigtest. gds !unstructured binary formatFile CRC d0b40760這是與由⑶SII解析器計算的文件級概要相同的概要。非結構化二進制文件非結構化二進制文件是不具有規(guī)范化單元概要工具已知的規(guī)范的非文本文件。例 如，對象代碼或者可執(zhí)行程序?qū)⑹欠墙Y構化文件。因為這些文件沒有已知的結構，所以無法 針對其計算規(guī)范化單元概要。僅計算文件概要。不存在語法解釋或者非結構化二進制文件 的排序。示例9 =SPICE格式網(wǎng)表文件類型通常使用20世紀70年代在加利福尼亞大學伯克利校區(qū)開發(fā)的以集成電路為重心 的仿真程序(通常稱為SPICE)來分析晶體管級設計。SPICE及其衍生品仍然是用于集成電 路的優(yōu)質(zhì)標準數(shù)值解法，但是容量和運行時問題將其使用限于子電路(幾十個到上百個晶 體管，加上關聯(lián)的寄生電路元件)而非整個設計。SPICE輸入文件是文本，并且可以由設計 者創(chuàng)建，但是通常由從⑶SII或者OASIS 讀取布局的電路提取者來編寫。通常，將讀取這 些文件的SPICE仿真繼而用于生成針對Liberty格式文件的定時模型。在此示例中，SPICE格式網(wǎng)表文件具有針對以下文件元素的內(nèi)容概要 文件 文件頭部 針對子電路的端口定義 子電路的主體掃描該文件以找到內(nèi)部的子電路名稱。對于子電路，針對子電路的端口定義和主 體而計算獨立的概要。這些以排除任何空白或者注釋的個體SPICE網(wǎng)表記號為基礎。將針對文件的頭部以及針對文件的概要作為一個整體來計算和返回。這些包括任何空白和注釋。不解釋包含文件指令，因為概要計算時的包含文件引用可能與仿真時不同(例 如，如果路徑名稱是相對的)。SPICE子電路文件通常將所提取的布局寫入到SPICE輸入文件內(nèi)的子電路中，并且由規(guī)范化單元概 要軟件將這些記錄為單元。子電路內(nèi)的文本是順序無關的，并且可以進行排序，但是其可 能不使用順序無關參量規(guī)范來實例化，所以在排序之后找到的概要匹配可能不表示真正等 效。由此，應當謹慎進行SPICE子電路文件的排序。默認不對SPICE子電路文件排序，除非 用戶指定了 -sort標志。SPICE子電路文件中不存在層，所以將所有針對單元的概要報告為非層數(shù)據(jù)File ‘‘ testfiles/testl. spi" Spice formatArguments -mem 64 —nosorte4c0e613 File7a041fe8 File non-ffhitespace07415f83 File WhitespaceFile Header (not sorted)c8954a7d File Header with Commentsfa8f8413 File Header without Comments321ace6e File Header Commentsfa8f8413 File Header non-LayerCell 〃 nand2〃 (not sorted)59fa7fl0 Cell with Commentsbdda89ec Cell without Commentse420f6fc Cell Comments5f4226ed Cell Interface non-Layere298af01 Cell Body non-Layer語法解釋不存在標準的SPICE格式，因為變量具有其自己的指令(尤其是器件模型參 數(shù))，但是所有程序使用相同的面向行的網(wǎng)表結構，在該網(wǎng)表結構中，子電路(單元)開始 于.subckt，結束于.ends。原型規(guī)范化單元概要SPICE解析器針對子電路創(chuàng)建單元，并且 將所有其他文本記錄為文件頭部的一部分。注釋以‘*’開始，并且繼續(xù)到目前行的結尾?！?’前面可以具有空白；這被移除。 記錄‘*’之后的任何空白而不進行進一步處理。子電路內(nèi)的注釋行被添加到單元主體概要 中。如果任一行的下一行在第一欄中開始于‘ + ’，則可以將該行繼續(xù)到下一行。在將行 合并到一起之前移除‘ + ’，以使得以下兩個行序列是等效的. subckt a b c以及. subckt
+a+b+c當合并連續(xù)行時不添加空格，所以下面兩個行序列是等效的. subckt a b c以及. sub+ckt a b c在將非注釋行發(fā)送至概要引擎之前，將該行中多個空白字符的序列轉(zhuǎn)換為單個空 格字符。假設點命令名稱(例如，.subckt)是不區(qū)分大小寫的。在記錄單元名稱之前將其 轉(zhuǎn)換為小寫，但是否則將在沒有大小寫轉(zhuǎn)換的情況下記錄文本。將.global行上指定的網(wǎng)記錄為單元接口中的管腳。在.options和.param行將影響單元的假設下，將其添加到單元的主體中。將.end語句之后的行記錄為文件頭部數(shù)據(jù)，而不進行任何解釋。.end命令認為是 可選的；如果漏掉了它，將不會打印錯誤。將.global、. param、. subckt、. ends和.end之外的點命令記錄為文件頭部數(shù)據(jù) 而不進行解釋。將具有‘X’ (子電路實例化)的任何子電路標記為層級式的。SPICE網(wǎng)表文件的排序因為SPICE子電路網(wǎng)表僅指定了連通性，所以其可以按照任意順序。如果請求了 排序，則按照字母順序排序文件頭部以及子電路中的行。在執(zhí)行排序之前移除行中重復的空格。還將對用于子電路的管腳名稱進行排序，即使連接是位置的(順序相關)，所以應 當謹慎使用排序的結果。原型SPICE網(wǎng)表解析器的限制解析器假設=SPICE子電路都不會大到超出存儲器的使用限制。還假設具有足夠 的空間來存儲任何子電路以外的所有行，以使得其可以存儲和記錄在文件的尾部。不處理.include語句，因為文件搜索路徑對于解析器不是已知的，并且無論如何 可能隨時間改變。來自.param行的參數(shù)不被代替。由此以下兩個文本塊是不等效的. param Ip = 0. 35mpullup zn i vdd vdd pmos w = 10. 0 1 = Ip以及mpullup zn i vdd vdd pmos w = 10. 0 1 = 0. 35記錄.param和.options行而不進行進一步解釋。由此以下兩個序列是不等效 的. param Ip = 0. 35 In = 0. 3 wp = 0. 7 wn = 0. 7以及
. param Ip = 0. 35 In = 0. 3. param wp = 0. 7 wn = 0. 7帶注解樣本SPICE網(wǎng)表文件圖13是示出以上解析規(guī)則的SPICE文件的帶注解版本。示例10-11 :LEF/DEF 文件類型庫交換格式(LEF)文件提供了用于描述來自⑶SII或者OASIS 文件的布線層設 計規(guī)則以及物理布局以便在布局和布線(P&R)工具中使用的方式。它提供了要進行布局和 布線的單元的面向布線器的接線以及通孔構造規(guī)則加抽象。在與設計交換格式(DEF)文件 相耦合的情況下，庫交換格式(LEF)文件提供了用于完整集成電路的布局和布線的規(guī)范。在這些示例中，LEF/DEF文件具有針對以下文件元素的內(nèi)容概要 文件 文件頭部 頭部注釋文本 單元注釋文本 逐層幾何對象 逐層非幾何對象 所有其他對象單元大小、站點(site)類型等 涉及其他較低層單元的布爾標志掃描數(shù)據(jù)庫以找到內(nèi)部的單元名稱。對于存在的單元，返回針對以下全部的逐層 概要1.幾何對象，諸如多邊形、矩形等；以及2.非幾何對象，諸如文本點等。為所有其他對象(諸如單元大小、站點類型和對稱性信息)指派概要。將針對文 件的頭部(任何單元定義之外的信息)以及針對文件的概要作為一個整體來計算和返回。作為一個選項，針對頭部中的注釋文本和單元內(nèi)部的注釋文本計算獨立的概要， 并且忽略空白(空格、制表符與空格以及空行的數(shù)目)的差異。庫交換格式(LEF)文件LEF文件是面向文本的，但是其通常由自動化工具而不是設計者編寫。處理技術 的描述(即，設計規(guī)則)通常存儲在LEF文件中，而單元信息在存儲于另一文件內(nèi)的宏中指 定。技術信息被存儲為文件頭部數(shù)據(jù)，而宏被記錄為單元。宏中幾乎所有的信息都指定該 宏與布局和布線工具的接口，所以其被記錄為單元接口數(shù)據(jù)。僅是宏的特性(如果有的話) 被記錄為單元主體數(shù)據(jù)。類似于⑶SII和OASIS ，LEF文件中的很多數(shù)據(jù)是順序無關的，所以默認地對其 進行排序，除非用戶指定了 -nosort標志。在適合時排序文件頭部中的信息，如同宏內(nèi)的數(shù)
據(jù)一樣。注意，LEF文件通過名稱指定層，而不是像⑶SII和OASIS 文件一樣通過編號指 定File ‘‘ testfiles/parsetest. lef" :LEF formatArguments -mem 64 -sort
c5eb5fff FileIcl8cc01 File non-ffhitespaceeb7f52dl File WhitespaceFile Header(sorted)30dbab35 File Header with Comments25a292d4 File Header without Comments157939el File Header Commentsb450539c File Header non-Layer316de219 File Header Layer Mla8fd3343 File Header Layer Vlff7eda09 File Header Layer M2Ib691e80 File Header Layer V2ec75d49b File Header Layer M3Cell “ AND2_X1〃 (sorted)Ied769e0 Cell with CommentsIed769e0 Cell without Comments(none) Cell Comments818dbac9 Cell Interface non-Layercbeeal9a Cell Interface Layer Ml54b472b3 Cell Body non-Layer庫交換格式文件定義 原型LEF解析器使用Cadence LEF/DEF語言參考手冊版本5. 6 (2004年9月)中 的LEF數(shù)據(jù)文件格式的定義。該文檔具有一些歧義和打字錯誤；這些以與同該手冊一起提 供的參考解析器相同的方式解決。語法解釋LEF中的單元描述稱為宏；宏內(nèi)的所有信息(諸如阻塞(blockage)和管腳信息) 被記錄為單元接口的部分。阻塞(blockage)是布線器在單元上布線時避免的區(qū)域。管腳 標記布線器繪制接線以連接到單元的位置。將技術LEF文件中的設計規(guī)則信息記錄為文件頭部的一部分。通過名稱來索引LEF文件中的層，所以解析器創(chuàng)建字符串層名稱表，并且將該表 內(nèi)的索引指派為層名稱。該表通過API可得。將行截斷為每個LEF規(guī)范2，048個字符。在文件頭部中記錄SITE語句；其本身不形成單元。將MACRO塊中除特性以外的所有東西記錄為單元接口文本，因為LEF文件打算指 定與布局和布線工具的單元接口。以不區(qū)分大小寫的方式對LEF關鍵詞進行匹配。LEF 5. 6規(guī)范關于這個問題無記 載，但是&ALIAS和&ENDALIAS是例外，其是明確不區(qū)分大小寫的。目前，規(guī)范化單元概要基 于關鍵詞的原始大小寫。即使NAMESCASESENSITIVE被設置為0FF，其也將應用于層、宏和管 腳名稱。然而，這很容易改變。
54
LEF文件的排序通常，LEF文件中的對象可以按照任何順序出現(xiàn)，兩個例外如下 對象引用出現(xiàn)在其定義之后· PATH的寬度由最近的WIDTH語句確定在個體對象內(nèi)，某些信息是順序無關的，而某些(例如，PATH點或者ITERATE值) 是順序相關的。解析器將順序無關字段與順序相關字段分離，以擔保經(jīng)排序的數(shù)據(jù)仍然有 效。當請求了文件排序時，首先基于語句名稱并且其次基于語句參數(shù)，按照字母順序 排列文件頭部中以及宏內(nèi)的語句。也排序語句內(nèi)的順序無關字段。為了確保正規(guī)，在排序 之前，將應用于給定PATH的WIDTH添加到該PATH記錄中。原型LEF解析器的限制LEF解析器的很多限制都起因于它正在解析單個文件這一事實，而使用LEF文件 的工具可以依次加載多個LEF文件。來自較早LEF文件的值可以在較晚的LEF文件中使用。 在缺少對那些其他文件的訪問的情況下，LEF解析器依賴于向其傳遞的值。不解釋NAMESCASESENSITIVE、BUSBITCHARS 和 DIVIDERCHAR 語句。解析器從頂層 驅(qū)動器(尚未具有從命令行對其進行設置的能力，所以使用默認值)得到間隔字符。如果 解析器將要依賴于從目前文件獲取的值，則當加載多個LEF文件時，其可能得到與布局和 布線工具不同的結果。假設，即使對ALIAS名稱的引用被視為標識符，也對文件進行語法糾正。ALIAS語 句本身可能在另一文件中，并且可能包括任意數(shù)量的語法，使得文件無法獨立解析。LEF文件的排序是按照字母順序的，而不是數(shù)字順序，所以規(guī)范化單元概要目前依 賴于LEF生成軟件繼續(xù)使用與之前相同的數(shù)字格式。 解析器不進行確保技術LEF文件(包含設計規(guī)則)與單元庫LEF文件(包含宏描 述)分離的檢查。對先前定義的SITE塊的SITE塊引用不進行確保其存在的檢查；較老的SITE塊可 能在另一文件中，并且一次僅解析一個文件。假設對SITE對象的改變將不改變引用它們的 MACRO對象。假設技術信息和其他文件頭部數(shù)據(jù)將不會超過存儲器使用限制，并且單個MACRO 都將超過存儲器使用限制。帶注解樣本LEF文件圖14是示出以上解析規(guī)則的應用的帶注解樣本LEF文件。示例11 (繼續(xù))設計交換格式(DEF)文件設計交換格式(DEF)文件提供了用于描述設計布圖規(guī)劃和網(wǎng)表以便在布局和布 線(P&R)工具中使用的方式。在與庫交換格式(LEF)文件相耦合的情況下，DEF文件提供 用于完整集成電路的布局和布線的規(guī)范。DEF文件是面向文本的，并且可以由自動化工具或者設計者來編寫。高層設計信 息(諸如管芯面積和區(qū)域規(guī)范)可以手動創(chuàng)建，并且詳細的阻塞信息和預先布線網(wǎng)通常由 軟件編寫。因為DEF文件可能不包括布局區(qū)域，并且其可能不與設計層級相關，所以將DEF 文件中的所有數(shù)據(jù)記錄在文件頭部概要中。
類似于GDSII和OASIS ，DEF文件中的很多數(shù)據(jù)是順序無關的，所以默認地對其進行排序，除非用戶指定了-nosort 標志。
注意，DEF文件通過名稱來指定層，而不是類似于⑶SII和OASIS 文件通過編號來指定
File “ testfiles/simple.def〃 :DEF format
Arguments ■-mem 丨64 -sort
a832fb91File
807bad9cFilenon-Whitespace
280fe544 File Whitespace
File Header(sorted)
b8d02902FileHeaderwith Comments
c6810a4dFileHeaderwithout Comments
7e51234fFileHeaderComments
6d026f6fFileHeadernon-Layer
Id4870e4FileHeaderLayer ml
74aecb62FileHeaderLayer vl
feafad9cFileHeaderLayer m2
6a00eeb9FileHeaderLayer v2
eeb61028FileHeaderLayer m3
設計交換格式文件定義
原型DEF解析器使用Cadence LEF/DEF語言參考手冊版本5. 6 (2004年9月)中的 DEF I女據(jù)文件格式<,該文檔具有-一些歧義和打字錯誤；這些以與同該手冊一起提供的參考解析器相同的方式來解決。語法解釋DEF文件將設計(或者設計的塊)描述為沒有真實層級的平面實體。區(qū)域分組即 使使用也不反應設計層級。因此，將所有的DEF數(shù)據(jù)記錄為文件頭部的一部分。DEF文件中的層通過名稱來索引，所以解析器創(chuàng)建字符串層名稱表，并且將該表內(nèi) 的索引指派為層編號。該表通過API可得。將行截斷為每個DEF規(guī)范2，048個字符。以不區(qū)分大小寫的方式匹配DEF關鍵詞。LEF 5. 6規(guī)范關于這個問題無記載，但是 &ALIAS和&ENDALIAS是例外，其是明確不區(qū)分大小寫的。規(guī)范化單元概要基于關鍵詞的原 始大小寫。為了減小DEF文件大小，可以將(例如，BLOCKAGE語句內(nèi)的POLYGON中的)復用 系數(shù)表示為星號(’*’)。解析器目前不將星號擴展為其表示的數(shù)字，因為任何此類值在理 論上可以是&ALIAS替換，并且由此不管怎樣都不是數(shù)值記號。DEF文件的排序DEF文件中的多數(shù)對象可以按照任何順序出現(xiàn)，除了對象引用在其定義之后。在個 體對象內(nèi)，某些信息是順序無關的，而某些(例如，POLYGON點)是順序相關的。解析器將 順序無關字段與順序相關字段分離，以確保經(jīng)排序的數(shù)據(jù)仍然有效。例如，在BLOCKAGE語句中，在排序時，使針對層的阻塞保持在一起。然而，可以對層內(nèi)的對象進行排序。當請求了文件排序時，首先基于語句名稱其次基于語句參數(shù)，按照字母順序來排 列文件中的語句。也對語句內(nèi)的順序無關字段進行排序。原型DEF解析器的限制DEF解析器的很多限制都起因于它正在解析單個文件這一事實，而使用DEF文件 的工具可以依次加載多個DEF文件。來自較早DEF文件的值可以在較晚的DEF文件中使用。 在缺少對那些其他文件的訪問的情況下，DEF解析器依賴于向其傳遞的值。假設即使將對&ALIAS名稱的引用視為標識符，也對文件進行語法糾正。&ALIAS語 句本身可能在另一文件中，并且可能包括任意數(shù)量的語法，使得文件無法獨立解析。不將BLOCKAGES、COMPONENTS、FILLS、GROUPS、NETS、NONDEEAULTRULES、PINS、 PINPR0PERTIES、PR0PERTYDEEINITI0NS、REGIONS、SCANCHAINS、SLOTS、SPECIALNETS、STYLES 和VIAS部分中的計數(shù)與這些部分內(nèi)的項目的實際數(shù)目進行驗證。不解釋NAMESCASESENSITIVE、BUSBITCHARS 和 DIVIDERCHAR 語句。解析器從頂層 驅(qū)動器(尚未具有從命令行對其進行設置的能力，所以使用默認值)得到間隔字符。如果 解析器將要依賴于從目前文件獲取的值，則當加載多個DEF文件時，其可能得到與布局和 布線工具不同的結果。假設UNITS命令或者不存在或者并非總是相同；目前不通過設計單位值來縮放文 件中的系數(shù)。目前不將數(shù)據(jù)點系數(shù)中的星號擴展為數(shù)字。當確定是否超過存儲器使用限制時，并不總是對注釋所使用的存儲器進行計數(shù)。帶注解樣本DEF文件圖15是示出這些規(guī)則的應用的DEF文件的帶注解版本。沒有示出所有可能的語句，因為無論如何都將除注釋以外的所有語句都發(fā)送至文 件頭部概要。以下DEF對象類型是可排序的· PR0PERTYDEFINITI0NS 部分內(nèi)的對象^ROW 定義· TRACKS 定義· VIAS定義；通孔的層內(nèi)的RECT和POLYGON對象· STYLES定義(但不是類型內(nèi)的多邊形點)· N0NDEFAULTRULES部分內(nèi)的對象(但不是規(guī)則內(nèi)的參數(shù))· REGIONS部分內(nèi)的對象(單不是區(qū)域內(nèi)的參數(shù))· BLOCKAGE定義內(nèi)的層；層內(nèi)的RECT和POLYGON對象· BLOCKAGE 定義內(nèi)的 PLACEMENT 對象；PLACEMENT 對象內(nèi)的 RECT 和 POLYGON 對
象· SLOTS部分內(nèi)的層；層內(nèi)的RECT和POLYGON對象· FILLS部分內(nèi)的層；層內(nèi)的RECT和POLYGON對象· COMPONENTS部分內(nèi)的對象(但不是組件內(nèi)的參數(shù))^PINS部分內(nèi)的對象(但不是管腳內(nèi)的參數(shù))[1022]· NETS或者SPECIALNETS部分中的網(wǎng)(但不是網(wǎng)內(nèi)的參數(shù)或者連接)· SCANCHAINS部分中的網(wǎng)(但不是網(wǎng)內(nèi)的參數(shù)或者連接)· GROUPS部分內(nèi)的對象示例12 結構化文本文件類型在此示例中，結構化文本文件具有針對以下文件元素的內(nèi)容概要 文件 文件頭部 注釋文本眷非注釋文本針對腳本文件和其他結構化文本文件計算逐個字節(jié)概要。概要與換行樣式無關。 作為一個選項，忽略空白的差異?？梢詡魉涂蛇x的注釋標記符；如果其存在，則針對注釋和 非注釋文本計算獨立的概要。可以傳送可選的行繼續(xù)字符；如果其存在，則在概要計算之前 合并具有該字符的行結尾。結構化文本(腳本)文件結構化文本文件是面向行的人類可讀文件，具有可標識注釋以及可能的繼續(xù)字 符，該繼續(xù)字符表示隨后的行在邏輯上是目前行的一部分。aiell、Perl和Python腳本是 結構化文本文件的規(guī)范化實例。將結構化文本文件中的所有數(shù)據(jù)記錄為文件頭部數(shù)據(jù)，其是文件頭部注釋或者文 件頭部非層數(shù)據(jù)。移除開頭的空白，并且將重復的空白字符合并為單個空格。注釋開始于 用戶指定的注釋字符序列(例如，‘#’)，并且繼續(xù)到行的結尾。如果某行結束于用戶指定 的繼續(xù)字符(例如，‘\’)，則將其與下一行合并；移除繼續(xù)字符和行字符的結尾。結構化文本文件可能具有括在單引號或者雙引號內(nèi)的字符串常量。在字符串常量 內(nèi)，引號字符如果避開了 則可以出現(xiàn)。不合并引證字符串內(nèi)的空白。語法解釋將結構化文本文件中的所有數(shù)據(jù)記錄為文件頭部數(shù)據(jù)，其是文件頭部注釋或者文 件頭部非層數(shù)據(jù)。為了正規(guī)，將行中重復的空白字符合并為單個空格字符。默認地，從行中移除所有 開頭的空白(縮進)。因為在某些語言(例如Python)中，縮進是重要的；所以存在標志來 將開頭的空白維持原樣。即使設置了該標志，也仍然將行中其他地方的重復空白字符合并 為單個空格字符。僅在文件級概要中記錄空行(僅是沒有其他字符的行結尾)；不將其記錄在文件 頭部概要中。如果文件具有DOS樣式的行結尾(CR-LF)，則在計算任何概要之前將其轉(zhuǎn)換為 UNIX樣式的行結尾(僅LF)。字符串常量不管是否用單引號或者雙引號引用，都視為單個字；將其按照原樣記 錄，而不進行解釋或者空白合并。反斜線字符(‘\’ )可以用于避免字符串常量內(nèi)的引號〃 This is a string constant with \〃 an embedded quote in it"將反斜線字符和封閉引號記錄為字符串常量的一部分。在進行任何其他行處理(包括字符串常量的標識)之前，將以用戶指定的繼續(xù)字符(‘\’)結束的行與下一行合并。繼續(xù)字符是之后不跟空白的行的結尾之前的最后一個 字符。在合并兩行時，將其與行結尾字符移除。可以按照這種方式合并一排(row)中任意 數(shù)目的行。注釋開始于用戶指定的字符序列(例如，‘#’或者“一”)，并且繼續(xù)到行的結尾。 注釋字符可以在行內(nèi)的任何地方。字符串常量內(nèi)的注釋字符不開始注釋。在注釋處理之前 執(zhí)行繼續(xù)字符處理，所以如果繼續(xù)字符出現(xiàn)在注釋行的結尾，則將之后的行也記錄為注釋 的一部分。由此，以下兩個文本塊是等效的，并且被記錄為單個注釋行# this is a multi_\
1047]line comment
1048]以及
1049]# this is a multi-line comment 無法將繼續(xù)字符放到引號中；如果行中的最后一個字符是繼續(xù)字符，則將該行與 下一行合并，即使其之前例如是‘ \ ’，或者內(nèi)部是字符串常量。 結構化文本文件的排序
結構化文本文件通常是順序相關的，所以無法對其進行排序。 原型結構化文本文件解析器的限制
目前，沒有方式使用命令行接口來阻止對開頭空白的移除。API具有這種能力。 目前，沒有方式使用命令行接口來指定注釋字符序列。API具有這種能力。 目前，沒有方式使用命令行接口來指定繼續(xù)字符。API具有這種能力。 沒有方式在字符串內(nèi)指定引號字符；其被固定為‘\’。 帶注解樣本結構化文本文件 圖16是結構化文本文件的帶注解版本。
在此示例中，不保留開頭的空白。如果保留了開頭的空白，則第五行前端的所有空
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061 1062
1063
1064
1065
1066
1067
1068 1069
1070
1071
1072
1073
1074
格都已經(jīng)被記錄為文件頭部文本t
示例13 由外部工具解析的文件類型
對于由外部工具解析的文件類型，至少提供針對以下文件元素的內(nèi)容概要 文件
眷文件頭部文本 單元名稱
接口對象名稱、標志等 注釋文本 單元主體文本。
可以使用與規(guī)范化概要生成過程兼容的任何外部解析器工具。在一個實施方式
中，外部文件解析器向概要計算代碼返回使用如下面向行的語法的文件
HEADERTEXIXheader text〉 CELL<cell name>
INTERFACE<interface object ηame><interface flag>. COMMENIXcomment text〉 CELLTEXIXcell body text〉[1075]每個文件可以存在不止一個HEADERTEXT記錄。每個文件可以存在不止一個CELL。 每個單元可以存在不止一個INTERFACE記錄。將行的文本添加到適合的文件或者單元概要。將CELL記錄之后的注釋行添加到 針對該單元的概要。用戶解析的文本文件可能存在這樣的專有數(shù)據(jù)文件格式，用戶想要記錄針對該專有數(shù)據(jù)文件格式的規(guī) 范化單元概要。如果這樣，則用戶可以編寫針對這些格式的解析器，并且將內(nèi)部的數(shù)據(jù)翻譯 為用戶解析的文本文件格式，如下所示HEADERTEXT header_textHEADERTEXT(layer)header_textCELL cell_nameINTERFACE interface_object_name interface_object_textINTERFACE(layer)interface_object_name interface_object_textHIERCELLCELLTEXT cell_body_textCELLTEXT(layer)eell_body_textCELLN0NGE0M cell_body_textCELLNONGEOM(Iayer)cell_body_textCOMMENT comment_text這是一個簡單的面向行的語法，其提供了對所有規(guī)范化單元概要類型的完全訪 問。通常，文件頭部數(shù)據(jù)由HEADERTEXT行來指示，單元的開始由CELL行來指示，單元接口 記錄由INTERFACE行來指示，單元主體記錄由CELLTEXT或者CELLN0NGE0M行來指示，而注 釋由COMMENT行來指示。HIERCELL行指示層級式單元，即可以包含對其他較低層單元的引 用的單元。單元內(nèi)的數(shù)據(jù)繼續(xù)到下一 CELL或者HEADERTEXT行或者文件的結尾。所有的文 件頭部、單元接口和單元主體數(shù)據(jù)可以具有指定的層名稱或者編號。如果指定了 -sort選 項，則可以對數(shù)據(jù)進行排序(通過層分組，繼而在層內(nèi)按照字母順序)。針對其計算概要的 文本可以具有對用戶有意義的任何格式。因為語法是面向文本和面向行的，所以無法將具有該格式的文件的概要與來自任 何其他文件格式的概要進行比較。使用二進制數(shù)據(jù)來計算二進制文件概要，并且計算針對 文本文件的解析器首先將行分為記號。用戶解析的文本文件定義該格式被提供以用于解析專有格式文件。用戶將編寫讀取文件格式并且生成這種 簡單格式的文件、繼而將生成的文件傳送至規(guī)范化單元概要工具的解析器。解析器轉(zhuǎn)而將 計算全部范圍的概要。用戶解析的文件格式的描述由到低層概要引擎的應用程序接口(API)實現(xiàn)?？梢?將所有文件格式的解釋描述為對該API的一系列調(diào)用，所以該格式的理解將幫助讀者理解 如何解釋其他格式。在比以上實施方式更加復雜的第二實施方式中，用戶解析的文件格式也是面向 行的格式。記錄出現(xiàn)在開始于諸如HEADERTEXT、COMMENT、CELL、INTERFACE、HIERCELL和
60CELLTEXT的關鍵詞的單個行中。HEADERTEXT、INTERFACE和CELLTEXT行可以可選地在緊跟 關鍵詞的圓括號內(nèi)具有層名稱。繼而在改層名稱上記錄關于行的其余部分的記錄。如果沒 有提供層名稱，則使用針對非層數(shù)據(jù)的數(shù)值層編號-1。期望這些文件將僅通過計算機軟件生成，所以可以使用嚴格的格式 所有關鍵詞大寫 關于行的關鍵詞之前沒有任何關于行的字符 如果沒有指定層名稱，則在關鍵詞之后跟隨單個空格，即使要進行記錄的文本 是空的如果指定了層名稱，則將其放在緊跟關鍵詞的圓括號中，之間沒有空格。將括號之 間的文本(包括任何空白)存儲為層名稱而不進行解釋。因此，層名稱可能不包括閉括號。 在閉括號之后存在空格字符。將第一空格之后的所有東西記錄為指定類型的文本，而不進行進一步的解釋。在記錄任何概要之前移除換行序列(Windows上的CR-LF、Unix/Linux上的LF)， 以避免所生成的概要中的系統(tǒng)依賴性。關于任何行的長度不存在限制。行開始于關鍵詞；空行是非法的。用戶解析的文本文件的語法行的格式如下HEADERTEXT header_textHEADERTEXT(layer)header_textHEADERTEXT行指定任何單元之外的數(shù)據(jù)。如果單元是開放的(見下文)，則終止該 單元，并且不能提供其他單元文本，直到開始新的單元。將所有的頭部數(shù)據(jù)保存為單個塊， 無論其是否處于文件的開始、單元之間或者在最后一個單元之后。如果將要對頭部文本進 行排序，則將其全部保持在存儲器中直到文件的結尾(受制于存儲器使用限制)，繼而將其 作為單位排序?？崭褡址SHEADERTEXT關鍵詞；將該空格之后到行結尾的所有都記錄為文件 頭部文本。不執(zhí)行進一步的空白移除，并且不執(zhí)行進一步的解釋或者大寫/小寫轉(zhuǎn)換。CELL cell_nameCELL行指定了新單元的開始。如果單元已經(jīng)是開放的，則將其終止，并且計算針 對其的所有概要。空格字符跟隨CELL關鍵詞；該空格之后到行結尾的所有都被用作單元名 稱，包括任何空白。不對單元名稱執(zhí)行解釋或者大寫/小寫轉(zhuǎn)換。不允許重復的單元名稱； 如果可能存在專有格式的重復名稱，則在解析器中針對該格式對其消除歧義。如果發(fā)現(xiàn)了 重復的單元名稱，則將發(fā)生致命錯誤。INTERFACE interface_object_name interface_object_textINTERFACE(layer)interface_object_name interface_object_textINTERFACE行指定了針對單元的接口記錄。存在針對接口記錄的單獨名稱，否則不 解釋該行上的數(shù)據(jù)?？梢源嬖诙鄠€接口記錄使用相同的接口名稱。接口名稱(例如，針對 單元的管腳名稱)是INTERFACE關鍵詞或者層名稱之后的第一個空白定界的字。繼而跳過 接口名稱之后的任何空白，并且將該行上保留的任何文本(如果有的話)記錄為接口對象 文本。不對接口名稱或者接口對象文本執(zhí)行大寫/小寫轉(zhuǎn)換，并且不對接口對象文本執(zhí)行空白移除。將接口名稱和接口對象文本都記錄為單元接口數(shù)據(jù)。如果在單元之外(在第一 CELL語句之前或者在HEADERTEXT語句與下一 CELL語 句之間)發(fā)現(xiàn)INTERFACE行，則將發(fā)生致命錯誤。HIERCELLHIERCELL標記單元是層級式的，意味著其包含對其他單元的引用。該信息可用于 概要報告。該行不存在參數(shù)。CELLTEXT cell_body_textCELLTEXT(layer)cell_body_textCELLTEXT行指定單元主體文本。將跟隨CELLTEXT關鍵詞的空格或者層名稱的閉 括號之后的所有都記錄為單元主體文本，而不進行進一步的解釋或者大寫/小寫轉(zhuǎn)換。也 不執(zhí)行空白移除。如果在單元之外(在第一 CELL語句之前或者在HEADERTEXT語句與下一 CELL語 句之間)發(fā)現(xiàn)CELLTEXT行，則將發(fā)生致命錯誤。CELLN0NGE0M cell_body_textCELLN0NGE0M(layer)eell_body_textCELLN0NGE0M行指定非幾何單元主體文本。將跟隨CELLN0NGE0M關鍵詞的空格或 者層名稱的閉括號之后的所有記錄為單元非幾何主體文本，而不進行進一步解釋或者大寫 /小寫轉(zhuǎn)換。也不執(zhí)行空白移除。如果在單元之外(在第一 CELL語句之前或者在HEADERTEXT語句與下一 CELL語 句之間)發(fā)現(xiàn)CELLN0NGE0M行，則將發(fā)生致命錯誤。COMMENT comment_textCOMMENT行指定注釋文本。將跟隨COMMENT關鍵詞的空格之后的所有都記錄為單 元或者文件頭部注釋文本(取決于上下文)，而不進行進一步解釋、空白移除或者大寫/小 寫轉(zhuǎn)換。用戶解析的文本文件的排序如果請求了排序，則收集針對頭部的文本，直到到達文件的結尾(即使文件中存 在單元)或者直到在存儲器中存儲了超過使用限制的頭部文本。如果超過了使用限制，則 將所存儲的頭部文本按照其原始順序發(fā)送至概要模塊。類似地，收集針對單元的文本，直到 到達單元的結尾或者直到在存儲器中存儲了超過使用限制的頭部和單元文本。如果提供了 足夠的存儲器或者向盤提供緩沖存儲器，這應當很少發(fā)生。頭部文本優(yōu)先于單元文本保持在存儲器中。前提是如果文件中存在單元，則單元 是最可能溢出存儲器限制的單位，所以釋放頭部文本的幫助不大。對于頭部文本，主排序關鍵字是層編號較低的層編號(層名稱表中的索引)排在 前面。在給定層內(nèi)，使用行的文本(排除關鍵詞和層名稱)按字母順序?qū)π羞M行排序。在單元內(nèi)，主排序關鍵字是行類型接口文本排在單元主體文本之前，并且單元非 幾何主體文本排在最后。層編號是次關鍵字較低的層編號排在前面。在給定層內(nèi)，使用行 的文本(排除關鍵詞和層名稱)按照字母順序?qū)π羞M行排序。帶注解的樣本用戶解析的文件圖17A-圖17B是用戶解析的文件的帶注解示例。圖17A中的層名稱是layl、lay2、lay3和lay4。分別將這些記錄為層0到層3，并且將使映射表可用。將沒有層的文件頭部、 單元接口、單元主體和單元非幾何主體行記錄在層-1上，針對層-ι不定義層名稱。對于該 格式，層-1的定義由用戶的應用確定。單元cell2是層級式的，并且具有稱為h3、il、i2和i3的接口對象(例如，管腳)。 單元eel 11具有稱為jl和j2的接口對象。如果沒有排序文件，則按照以上所示的出現(xiàn)的順序記錄概要。如果排序了文件，則 將如圖17B所示記錄規(guī)范化單元概要。注意，接口行的排序基于行在分為接口名稱和接口文本之前的剩余部分。由此單 元cell2的接口 h3在接口 il之前記錄，即使按照字母順序il的接口文本在h3之前。類 似地，頭部文本的第一行將最后記錄，因為其具有層索引0，而其他頭部行具有層索引-1。還要注意，當單元celll開始時，單元cell2結束，并且當頭部文本開始時，單元 celll結束。當排序被啟用時，文件級概要將不會改變。HIERCELL記錄不會影響排序或者包含 其的單元的規(guī)范化單元概要；其簡單地在單元數(shù)據(jù)結構中設置標志。用戶解析的文本文件格式的限制用戶解析的文件格式是ASCII，所以其無法編寫將具有與二進制OASIS 和⑶SII
格式文件相同的概要的用戶解析的文件。在用戶解析的文件中處理記號的方式也不同于在 其他結構化文本文件格式中處理記號。為了將來自使用專有、內(nèi)部數(shù)據(jù)格式的文件的概要 與來自另一格式的概要相匹配，用戶可以首先將內(nèi)部數(shù)據(jù)格式文件翻譯為所支持的格式， 或者編寫針對該內(nèi)部格式的定制解析器。比較規(guī)范化概要的工作示例使用原型命令行工具，三種比較模式是可用的。文件比較模式比較針對兩個不同 版本的設計文件(諸如OASIS 或者GDSII)的概要文件，并且報告有意義的差異。版本檢 查模式將針對設計文件的概要與針對庫文件集合計算的概要進行比較，并且報告最近的匹 配(如果有的話)。數(shù)據(jù)庫檢查模式將設計文件中的單元與包含新的/未測試的單元、生產(chǎn) 單元、被否決/陳舊的單元以及已知不良單元的概要的庫進行匹配。文件比較樽式在文件比較模式中，將針對兩個設計文件的概要進行比較，并且報告任何差異。其 標記任何不匹配的單元，并且打印針對具有不同概要的單元連同有區(qū)別的層(在可應用 時)和單元結構(例如，接口，當可應用時)的報告。當想要確保僅對已經(jīng)在產(chǎn)的設計進行 經(jīng)授權的改變時，該模式是有用的。例如，設計者可能改變了單個單元中的一個層；附加改 變的任何報告將代表錯誤。用于使用原型命令行工具來運行文件比較的語法是sigcompare -compare[-showall]filel file2第一參數(shù)-compare指定文件比較模式。默認地，僅報告有區(qū)別的單元；可選 的-showall標志指定報告了所有單元，包括相同單元。通過名稱對單元進行匹配，不嘗試在不同的名稱下查找拷貝。文件比較示例考慮一下庫交換格式(LEF)概要文件對[1152]File ‘‘ lib_45nm_vl_0. Ief “ :LEF formatArguments -mem 64 -sortc5eb5fff FileIcl8cc01 File non-ffhitespaceeb7f52dl File WhitespaceFile Header (sorted)6f3a526d File Header with Comments7a436b8c File Header without Comments157939el File Header Commentsb450539c File Header non-Layer316de219 File Header Layer Mlff7eda09 File Header Layer M2Cell " AND2_X1〃 (sorted)9a4743f9 Cell with Comments9a4743f9 Cell without Comments(none) Cell Comments051d90d0 Cell Interface non-Layercbeeal9a Cell Interface Layer Ml54b472b3 Cell Body non-LayerCell " AND2_X2〃 (sorted)6922ffe9 Cell with Comments6922ffe9 Cell without Comments(none) Cell Comments04592cfd Cell Interface non-Layer39cfala7 Cell Interface Layer Ml54b472b3 Cell Body non-LayerCell " AND2_X4〃 (sorted)aa5c90cd Cell with Commentsaa5c90cd Cell without Comments(none) Cell Commentsd48106d4 Cell Interface non-Layer2a69e4aa Cell Interface Layer Ml39cfala7 Cell Interface Layer M254b472b3 Cell Body non-LayerCell " AND3_X1〃 (sorted)aeld08cc Cell with Commentsaeld08cc Cell without Comments(none) Cell Comments5b3057bl Cell Interface non-Layer
64[1191]al992dceCellInterface Layer Ml[1192]54b472b3 Cell Body non-Layer[1193]Cell “ AND3_X2"(sorted)[1194]e9fc0084Cellwith Comments[1195]e9fc0084Cellwithout Comments[1196](none)CellComments[1197]6bca4478CellInterface non-Layer[1198]d682364f Cell Interface Layer Ml[1199]54b472b3 Cell Body non-Layer[1200]Cell “ AND3_X4"(sorted)[1201]6a5906e0Cellwith Comments[1202]6a5906e0Cellwithout Comments[1203](none)CellComments[1204]0a3e63eaCellInterface non-Layer[1205]34d317b9CellInterface Layer Ml[1206]77375526CellInterface Layer M2[1207]54b472b3CellBody non-Layer[1208]以及[1209]File “ lib_45nm_v2_0. Ief" :LEF format[1210]Arguments -mem34 -sort[1211]e03e9e03File[1212]80a5de77Filenon-ffhitespace[1213]30dbab35 File Whitespace[1214]File Header(sorted)[1215]7c315cffFileHeader with Comments[1216]6948651eFileHeader without Comments[1217]157939elFileHeader Comments[1218]b450539cFileHeader non-Layer[1219]316de219FileHeader Layer Ml[1220]ec75d49bFileHeader Layer M2[1221]Cell “ AND2—Xl'(sorted)[1222]Ied769e0Cellwith Comments[1223]Ied769e0Cellwithout Comments[1224](none)CellComments[1225]818dbac9CellInterface non-Layer[1226]cbeeal9aCellInterface Layer Ml[1227]54b472b3CellBody non-Layer[1228]Cell “ AND2_X2'(sorted)[1229]498852e8Cellwith Comments[1230]498852e8Cellwithout Comments[1231](none)CellComments[1232]04592cfdCellInterface non-Layer[1233]19650ca6CellInterface Layer Ml[1234]54b472b3CellBody non-Layer[1235]Cell “ AND2_X4'(sorted)[1236]aa5c90cdCellwith Comments[1237]aa5c90cdCellwithout Comments[1238](none)CellComments[1239]d48106d4CellInterface non-Layer[1240]2a69e4aaCellInterface Layer Ml[1241]39cfala7CellInterface Layer M2[1242]54b472b3CellBody non-Layer[1243]Cell ” AND3_X1'(sorted)[1244]aeld08ccCellwith Comments[1245]aeld08ccCellwithout Comments[1246](none)CellComments[1247]5b3057blCellInterface non-Layer[1248]al992dceCellInterface Layer Ml[1249]54b472b3CellBody non-Layer[1250]Cell “ AND3_X2(sorted)[1251]e9fc0084Cellwith Comments[1252]e9fc0084Cellwithout Comments[1253](none)CellComments[1254]6bca4478CellInterface non-Layer[1255]d682364fCellInterface Layer Ml[1256]54b472b3CellBody non-Layer[1257]Cell “ AND3_X4'(sorted)[1258]6a5906e0Cellwith Comments[1259]6a5906e0Cellwithout Comments[1260](none)CellComments[1261]0a3e63eaCellInterface non-Layer[1262]34d317b9CellInterface Layer Ml[1263]77375526CellInterface Layer M2[1264]54b472b3CellBody non-Layer[1265]這些文件通過讀取支持幾何排序(針對OASIS 、⑶SII、LEF、DEF和Liberty格式
文件的推薦)并且具有32比特概要的兩個版本的LEF文件來生成。因為LEF文件指定布 局和布線工具應當如何連接至標準單元，所以單元中幾乎全部內(nèi)容都在接口中一改變是足 夠顯著的，因為這意味著無法簡單地嵌入新的布局版本來代替較老版本。1266]運行該命令
1267]sigcompare -compare sigcompare_fi1e1. txt sigcompare_file2. txt
1268]產(chǎn)生以下報告
1269]Summary of file-level comparisons
1270]File ” lib—45nm_vl—0. Ief" File digest does not match
1271]File “ lib—45nm—v2—0. Ief〃 File digest.
1272]File “ lib_45nm_vl_0. Ief" non-Whitespace digest does not match
1273]File ” lib_45nm_v2_0. Ief/r non-Whitespace digest.
1274]File “ lib_45nm_vl_0. Ief" Whitespace digest does not match
1275]File “ lib_45nm_v2_0. Ief/r Whitespace digest.
1276]Summary of file header comparisons
1277]File “ lib_45nm_vl_0. Ief" header is a partial match with
1278]File “ lib_45nm—ν2_0· Ief" header
1279]non-Layer digests match
1280]File Header Layers matched
1281]Ml
1282]File Header Layers mismatched
1283]M2
1284]comments match
1285]Summary of all cell comparisons
1286]2 cells are partial matches
1287]4 cells are perfect matches
1288]File “ lib_45nm_vl_0. Iefcell “ AND2_X2is a partial match with
1289]File “ lib—45nm—v2—0. Ief" cell “ AND2—X2"
1290]Cell Interface matches partially
1291]Cell Interface non-Layer digests match
1292]Cell Interface Layers mismatched
1293]Ml
1294]no Cell Body data is present
1295]no Cell Body non-Geometric Layer data is present
1296]no comments present
1297]File “ lib_45nm—vl_0. Ief 〃 cell “ AND2—XI" is a partial match with
1298]File “ lib—45nm—v2—0. Ief" cell “ AND2—XI"
1299]Cell Interface matches partially
1300]Cell Interface non-Layer digests do not match
1301]Cell Interface Layers matched
1302]Ml
1303]no Cell Body data is present
1304]no Cell Body non-Geometric Layer data is present[1305]no comments present文件中某些地方存在差異，所以針對文件中所有字節(jié)的文件概要不同。某些值也 是不同的，所以非空白概要不同。最后，空白概要不同。針對所有文件類型打印文件概要比 較；僅針對文本文件類型打印其他兩個。LEF文件頭部(其包括用于布線層的設計規(guī)則和寄生信息)在層M2上不同，單元 AND2_X2與AND2_X1不完全匹配。這些比較沒有示出頭部與單元之間的差異的準確性質(zhì)； 其僅告知用戶查看哪里。并非所有的設計文件格式都在文件頭部中具有相關數(shù)據(jù)。GDSII文件在文件頭部 中具有無意義的數(shù)據(jù)，而OASIS 文件級特性不會影響幾何表示。因此，⑶SII或者OASIS
文件之間的比較將不包括關于文件頭部數(shù)據(jù)的匹配的報告。版本報告樽式版本報告模式的一種用途是用于當用戶具有多個版本的庫文件時，確定針對設 計文件中的單元的源庫。針對設計文件中的單元，程序定位來自所有庫文件的最近匹配 (如果有的話)。用于版本報告模式的語法是sigcompare -report[-showall]file _1 file. . . -2 file…[_3 file…]…首先是設計文件，其他文件是庫。庫文件利用其版本號來指定，"I表示最近版 本，-2表示下一最近版本，以此類推。除了版本號是連續(xù)的，并且每個版本號存在至少一個 文件以外，版本號或者每個版本號的文件數(shù)目沒有限制。-report參數(shù)指定版本報告模式。默認地，僅報告不匹配單元(例如，布局和布線 單元)、非完全匹配或者與過期單元的匹配；可選的-showall標志指定報告了所有單元，包 括與最近庫版本的完全匹配。如果文件名稱以“_”開始，則其名稱之前具有-file。通過名稱來對單元進行匹配，不嘗試在不同的名稱下查找拷貝。版本報告示例此示例將來自小的設計OASIS 文件的概要與用于構建其的⑶SII庫進行比較。 設計概要文件稱為design—from—versions· txt File ” design_from—versions, oas“ :0ASIS formatArguments -grid le_9 -mem 64 -sortf3b2848e File(none) File non-Whitespace(none) File WhitespaceFile Header (sorted)(none) File Header with Comments(none) File Header without Comments(none) File Header CommentsCell ” top" (sorted ；hierarchical)4512f0e0 Cell with Comments[1331]4512f0e0 Cell without Comments(none) Cell Comments4512f0e0 Cell Body non-LayerCell " AND2_X1〃 (sorted)63710c55 Cell with Comments63710c55 Cell without Comments(none) Cell Commentsa57f61dl Cell Body Layer 8d5557088 Cell Body Layer 10135bld0c Cell Body Layer 12Cell " AND2_X2〃 (sorted)4245e32b Cell with Comments4245e32b Cell without Comments(none) Cell Comments33bfda26 Cell Body Layer 847834653 Cell Body Layer 1036797f5e Cell Body Layer 12Cell " AND2_X4〃 (sorted)7dbb4961 Cell with Comments7dbb4961 Cell without Comments(none) Cell Commentsb431c2dd Cell Body Layer 8addb2970 Cell Body Layer 106451a2cc Cell Body Layer 12來自最近庫的概要包括在文件sigcompare_versionlJ3. txt中注意，⑶SII單元具有注釋概要，而以上OASIS單 元不具有任何注釋。File ‘‘ lib_vl_3. gds"⑶S formatArguments -grid le_9 -mem 64 -sort3b57a2c0 File(none) File non-Whitespace(none) File WhitespaceFile Header (sorted)9547893d File Header with Comments01f60a9d File Header without Comments94bl83a0 File Header Comments01f60a9d File Header non-LayerCell " AND2_X1〃 (sorted)e60bb9da Cell with Comments[1369]7ff21caaCellwithout Comments[1370]99f9a570CellComments[1371]b9fc712eCellBody Layer 8[1372]d5557088CellBody Layer 10[1373]135bld0cCellBody Layer 12[1374]Cell “ AND2_X2"(sorted)[1375]ff7d7b80Cellwith Comments[1376]6684def0Cellwithout Comments[1377]99f9a570CellComments[1378]cdf468c5CellBody Layer 8[1379]9d09c96bCellBody Layer 10[1380]36797f5eCellBody Layer 12[1381]Cell “ AND2_X4"(sorted)[1382]11174169Cellwith Comments[1383]88eee419Cellwithout Comments[1384]99f9a570CellComments[1385]7715e8f3CellBody Layer 8[1386]8158c56eCellBody Layer 10[1387]7ea3c984CellBody Layer 12[1388]來自先前版本的概要包括在文件[1389]sigcompare__versionl_2. txt 中[1390]File “ lib_vl_2.gds“ :GDS format[1391]Arguments -gridle-9 -mem 64 -sort[1392]f7b57566File[1393](none)Filenon-Whitespace[1394](none)File Whitespace[1395]File Header(sorted)[1396]e4590214FileHeader with Comments[1397]d5839d36FileHeader without Comments[1398]31da9f22FileHeader Comments[1399]d5839d36FileHeader non-Layer[1400]Cell “ AND2_X1'(sorted)[1401]6f006266Cellwith Comments[1402]26f9c716Cellwithout Comments[1403]99f9a570CellComments[1404]b9fc712eCellBody Layer 8[1405]26cf422aCellBody Layer 10[1406]b9caf41fCellBody Layer 12[1407]Cell “ AND2_X2'(sorted)
70[1408]4b527d9d Cell with Comments4245e32b Cell without Comments09179eb6 Cell Comments33bfda26 Cell Body Layer 847834653 Cell Body Layer 1036797f5e Cell Body Layer 12Cell " AND2_X4〃 (sorted)b35fe404 Cell with Comments92f41f5b Cell without Comments21abfb5f Cell Comments418cffaf Cell Body Layer 8addb2970 Cell Body Layer 107ea3c984 Cell Body Layer 12來自庫的最老的活躍版本的概要包括在sigcompare_versionl_l· txt中File ‘‘ lib_vl_l. gds" GDS formatArguments -grid le_9 -mem 64 -sortae014c24 File(none) File non-Whitespace(none) File WhitespaceFile Header (sorted)82295a77 File Header with Comments86b9ff40 File Header without Comments0490a537 File Header Comments86b9ff40 File Header non-LayerCell " AND2_X1〃 (sorted)15918b78 Cell with Comments8c682e08 Cell without Comments99f9a570 Cell Commentsb9fc712e Cell Body Layer 826cf422a Cell Body Layer 10135bld0c Cell Body Layer 12Cell " AND2_X2〃 (sorted)5ale9163 Cell with Comments169108cf Cell without Comments4c8f99ac Cell Comments33bfda26 Cell Body Layer 847834653 Cell Body Layer 106fad94ba Cell Body Layer 12Cell “ AND2_X4〃 (sorted)[1447]99bcef32 Cell with Commentsb817146d Cell without Comments21abfb5f Cell Commentsb431c2dd Cell Body Layer 8addb2970 Cell Body Layer 10alfdffcO Cell Body Layer 12如果運行此命令sigcompare -report design_from一versions, txt \-1 sigcompare_versionl_3. txt \-2 sigcompare_versionl_2. txt \-3 sigcompare_versionl_l. txt則生成以下報告Summary of all comparisons 1 cells do not appear in any library1 of these cells are hierarchical2 cells match only partially with library cells2 cells match old library cellsFile “ design_from—versions, oas" cell “ top" does not match anylibrary cell.cell is hierarchical.File “ design—from一versions, oas" cell “ AND2_X4/r is a partialmatch withFile “ lib—vl—1. gds" cell “ AND2—X4"no Cell Interface data is presentCell Body data matches partially Cell Body Layers matched 10 8Cell Body Layers mismatched 12no Cell Body non-Geometric Layer data is presentthere are 2 newer versions of this cellFile “ design_from—versions, oas" cell “ AND2—XI" is a partialmatch withFile “ lib—vl—3. gds" cell “ AND2—XI"no Cell Interface data is presentCell Body data matches partially Cell Body Layers matched 10 12Cell Body Layers mismatched 1486]8
1487]no Cell Body non-Geometric Layer data is present
1488]File “ design_from—versions, oas" cell “ AND2—X2" is a perfect
1489]match with
1490]File “ lib—vl—2. gds" cell “ AND2—X2"
1491]no Cell Interface data is present
1492]Cell Body data matches perfectly
1493]Cell Body Layers matched
1494]10 12 8
1495]no Cell Body non-Geometric Layer data is present
1496]there is 1 newer version of this cell
1497]頂層設計單元不在任何庫中，如所期望的。設計文件中的其他三個單元具有至少 -個可報告問題
1498]· AND2_X4不與任何庫單元完全匹配；最接近的匹配是來自最老庫的版本
1499]· AND2_X1不與任何庫單元完全匹配；最接近的匹配是來自最新庫的版本
1500]· AND2_X2與第二老的庫中的單元完全匹配
1501]當單元僅進行部分匹配時，打印匹配和失配的數(shù)據(jù)類型和層的列表。
1502]數(shù)據(jù)庫檢杳樽式
1503]數(shù)據(jù)庫檢查模式的一種用途是將候選設計文件與利用以下完善水平加標簽的庫 集合進行驗證新的/未檢驗的、生產(chǎn)、被否決/陳舊或者已知是不良的。這些表示單元的 特定版本的生命期。例如，如果設計處于批量生產(chǎn)中，則用戶可能不想使用單元的未檢驗版 本；用戶可能僅想使用已被標記為值得生產(chǎn)的單元。然而，一旦檢驗了新的版本，則將逐步 淘汰較老的版本。被否決的版本可能僅在已經(jīng)批量生產(chǎn)的設計中使用，而不在新設計中使 用。最后，如果已知單元版本具有功能或者生產(chǎn)問題，則不應當將其用于任何設計。規(guī)范化單元概要匹配允許用戶在候選文件中分類所有單元，即使其已經(jīng)在不同的 名稱下被拷貝。以此方式，用戶可以檢測對所有已知不良單元的使用，或者及時標識未授權 單元以防止發(fā)布設計去制造。使用原型命令行處理器時，用于數(shù)據(jù)庫檢查模式的語法是sigcompare -database [-showall] [-new. . . ] [-prod. . . ] [-depr. . . ] [-bad. . . ] -test...-database參數(shù)指定數(shù)據(jù)庫檢查模式。默認地，不報告對生產(chǎn)單元的完全匹配。同 樣使用可選的-showall標志來報告這些單元。命令行的其余部分是具有類型的概要文件的列表。除了存在至少一個-test (候 選)文件以及至少一個另一類型的文件以外，它們可以按照任何順序。-new參數(shù)用于指定包含新的并且尚未在生產(chǎn)中檢驗的單元的庫。此后直到下一庫 類型之前的所有文件名稱被標記為新的。-prod參數(shù)用于指定包含已經(jīng)在生產(chǎn)中檢驗的單元的庫。此后直到下一庫類型之 前的所有文件名稱被標記為生產(chǎn)。-d印r參數(shù)用于指定包含如下單元的庫，這些單元被否決或者是陳舊的，并且不應 當在新設計中使用。此后直到下一庫類型之前的所有文件名稱被標記為被否決。[1511]-bad參數(shù)用于指定包含已知是不良的并且應當從所有設計中移除的單元的庫。此后直到下一庫類型之前的所有文件名稱被標記為已知是不良的。[1512]-test參數(shù)用于指定候選設計文件。通常，用戶一次將僅比較一個候選文件。[1513]如果文件名稱以“_”開始，則其名稱之前具有-file。[1514]數(shù)據(jù)庫檢查示例[1515]此示例將來自小的設計OASIS 文件的概要與用于構建其的GDSII庫進行比較。設計概要文件名為[1516]design_from_database.txt [1517]File “ design_from_database. oas" :0ASIS format[1518]Arguments -gridle~9 -mem 64 -sort[1519]14430dl9File[1520](none)Filenon-Whitespace[1521](none)FileWhitespace[1522]File Header(sorted)[1523](none)FileHeader with Comments[1524](none)FileHeader without Comments[1525](none)FileHeader Comments[1526]Cell “ top"(sorted ；hierarchical)[1527]fccf8240Cellwith Comments[1528]fccf8240Cellwithout Comments[1529](none)CellComments[1530]fccf8240CellBody non-Layer[1531]Cell “ AND2_X1"(sorted)[1532]7ff21caaCellwith Comments[1533]7ff21caaCellwithout Comments[1534](none)CellComments[1535]b9fc712eCellBody Layer 8[1536]d5557088CellBody Layer 10[1537]135bld0cCellBody Layer 12[1538]Cell “ AND2_X2"(sorted)[1539]aeece77dCellwith Comments[1540]aeece77dCellwithout Comments[1541](none)CellComments[1542]dfl6de70CellBody Layer 8[1543]47834653CellBody Layer 10[1544]36797f5eCellBody Layer 12[1545]Cell “ AND2_X4"(sorted)[1546]b817146dCellwith Comments[1547]b817146dCellwithout Comments1548](none) Cell Comments
1549]b431c2dd Cell Body Layer 8
1550]addb2970 Cell Body Layer 10
1551]alfdffcO Cell Body Layer 12
1552]Cell “ AND2_X4A〃 (sorted)
1553]b817146d Cell with Comments
1554]b817146d Cell without Comments
1555](none) Cell Comments
1556]b431c2dd Cell Body Layer 8
1557]addb2970 Cell Body Layer 10
1558]alfdffcO Cell Body Layer 12
1559]Cell “ AND2_X3〃 (sorted)
1560]c6f8c857 Cell with Comments
1561]c6f8c857 Cell without Comments
1562](none) Cell Comments
1563]b9fc712e Cell Body Layer 8
1564]075a8f95 Cell Body Layer 10
1565]785e36ec Cell Body Layer 12
1566]Cell “ AND2_X5〃 (sorted)
1567]e60bb9da Cell with Comments
1568]7ff21caa Cell without Comments
1569]99f9a570 Cell Comments
1570]b9fc712e Cell Body Layer 8
1571]d5557088 Cell Body Layer 10
1572]135bld0c Cell Body Layer 12
1573]再次使用來自版本報告示例的文件
1574]sigcompare_versionl_l. txt、
1575]sigcompare_versionl_2. txt 禾口
1576]sigcompare_versionl_3. txt，連同新文件
1577]sigcompare_versionl_4. txt
1578]File “ lib—vl—4. gds" :( S format
1579]Arguments -grid le_9 -mem 64 -sort
1580]c589flal File
1581 ](none) File non-Whitespace
1582](none) File Whitespace
1583]File Header(sorted)
1584]43922b24 File Header with Comments
1585]c52bd464 File Header without Comments
1586]86b9ff40 File Header Comments
751587]c52bd464FileHeader non-Layer1588]Cell “ AND2_X1〃 (sorted)1589]512424b9Celwith Comments1590]4a03a6f8Celwithout Comments1591]lb278241CelComments1592]b9fc712eCelBody Layer 81593]8balel3aCelBody Layer 101594]785e36ecCelBody Layer 121595]Cell “ AND2_X2〃 (sorted)1596]a994ef98Celwith Comments1597]58ebl029Celwithout Comments1598]fl7fffblCelComments1599]cdf468c5CelBody Layer 81600]47a75210CelBody Layer 101601]d2b82afcCelBody Layer 121602]Cell “ AND2_X4〃 (sorted)1603]9842af7aCelwith Comments1604]5c09dc54Celwithout Comments1605]c44b732eCelComments1606]8d50e097CelBody Layer 81607]affaf547CelBody Layer 101608]7ea3c984CelBody Layer 121609]當運行此命令時1610]sigcompare-database -new sigcompare_versionl_4. txt \1611]-prod sigcompare_versionl_3. txt \1612]-depr sigcompare_versionl_2. txt \1613]-bad sigcompare_versionl_l. txt \1614]-test design—from—database, txt1615]生成以下報告1616]Summary ofallcomparisons 1617]1 cellshave no good matches1618]1of these cells are hierarchical1619]2 cellsare perfect matches with known bad cells1620]1of these matches are under different names1621]1 cellsare partial matches with deprecated cells1622]1 cellsare partial matches with new cells1623]1of these matches are under different names1624]2 cellsare perfect matches with production cells1625]1of these matches are under different names[1626]File “ design_from—database, oas〃，cell “ top“ :no good matches.cell is hierarchical.File “ design_from_database. oas/r cell “ AND2_X4A/r is a perfectmatch withFile “ lib—vl—1. gds" bad cell “ AND2—X4"no Cell Interface data is presentCell Body data matches perfectly Cell Body Layers matched 10 12 8no Cell Body non-Geometric Layer data is presentFile “ design_from_database. oas/r cell “ AND2_X4/r is a perfectmatch withFile “ lib—vl—1. gds" bad cell “ AND2—X4"no Cell Interface data is presentCell Body data matches perfectly Cell Body Layers matched 10 12 8no Cell Body non-Geometric Layer data is presentFile “ design—from一database, oas" cell “ AND2_X2/r is a partialmatch withFile “ lib—vl—2. gds" depreeated cell “ AND2—X2"no Cell Interface data is presentCell Body data matches partially Cell Body Layers matched 10 12Cell Body Layers mismatched 8no Cell Body non-Geometric Layer data is presentFile “ design—from一database, oas" cell “ AND2_X3/r is a partialmatch withFile “ lib—vl—4. gds" new cell “ AND2—XI"no Cell Interface data is presentCell Body data matches partially Cell Body Layers matched 12 8Cell Body Layers mismatched 10no Cell Body non-Geometric Layer data is presentFile “ design—from—database, oas" cell “ AND2—X5" is a perfect
77[1665]match withFile “ lib—vl—3. gds“ production cell “ AND2—XI"no Cell Interface data is presentCell Body data matches perfectly Cell Body Layers matched 10 12 8no Cell Body non-Geometric Layer data is present如之前一樣，頂層單元不與任何庫相匹配。設計者例如通過布局和布線而創(chuàng)建作 為物理設計過程一部分的任何單元將不在庫中。通常，這些單元將不是葉單元，所以打印針 對層級式單元的報告，意味著其具有對其中其他單元的引用。將與已知不良單元的匹配列在非匹配單元之后。在該程序模式中，即使單元名稱 不同，也將發(fā)現(xiàn)和報告匹配。例如，單元AND2_X4A是來自最老的庫(版本1.1)的已知不良 單元AND2_X4的拷貝，這表明設計者在設計塊中對該單元進行了重命名，而不是利用最新 的版本來對其進行替換。AND2_X4的已知不良版本也出現(xiàn)在其原始名稱下。接下來列出與被否決單元的匹配。這里，與設計單元AND2_X2的最佳匹配來自被 否決庫版本1.2。這表明設計者從過期庫開始本地修改了單元。利用單元和文件名稱來標 記層相似性和差異性。將與新單元的匹配列在與被否決單元的匹配之后。來自設計的單元AND2_X3是與 新庫單元AND2_X1的優(yōu)選匹配，這意味著其是從不同的名稱下的新庫拷貝的。最后，列出與不同名稱下的生產(chǎn)單元的匹配。這里，設計單元AND2JC5是來自庫版 本1. 3的生產(chǎn)單元AND2_X1的拷貝。這不是即時問題，但是如果以后修改了 AND2_X1的版 本1. 3，則拷貝將不利用改進的版本來替換。如果選擇了 -showall選項，則將與相同名稱的生產(chǎn)單元的匹配列在所有其他匹 配之后。在此小示例中，將僅打印一個附加單元報告；通常，將打印上千個匹配單元報告。File ‘‘ design_from_database. oas" cell ‘‘ AND2_X1 “ is a perfectmatch withFile “ lib_vl_3. gds" production cell “ AND2_X1〃 no Cell Interface data is presentCell Body data matches perfeetly Cell Body Layers matched 10 12 8no Cell Body non-Geometric Layer data is present匹配LibertyC lib)文件的報告Liberty格式文件testfiles/tstlibpar2. lib包含針對幾個單元的定時模型。單 元AND2_X2具有cell和scalecLcell規(guī)范二者。在一個實施方式中，將這些進行組合以生 成針對單元的概要。單元AND2_X1、AND2_Xl_copy和AND2_Xl_copy_b是相同的；AND2_X1_ copy是準確拷貝，而AND2_Xl_copy_b內(nèi)的某些語句已經(jīng)進行了重新排列。在不排序的情況 下，概要不同otismartsig -sort -lib testfiles/tstlibpar2. lib[1689]Cell “ AND2_X1〃Interface CRC 0190af2fContents CRC 6a059541Cell “ AND2_Xl_copy〃Interface CRC 0190af2fContents CRC 6a059541Cell “ AND2_Xl_copy_b〃Interface CRC Iee6bb80Contents CRC e4fa24f0將單元的pin組語句視為單元接口的一部分。因為兩個pin語句在AND2_Xl_copy_ b中交換，所以接口和內(nèi)容概要都改變了。在排序的情況下，所有的概要相匹配otismartsig -sort —lib testfiles/tstlibpar2. libCell “ AND2_X1〃Interface CRC 0190af2fContents CRC dc623050Cell “ AND2_Xl_copy〃Interface CRC 0190af2fContents CRC dc623050Cell “ AND2_Xl_copy_b〃Interface CRC 0190af2fContents CRC dc623050修改Liberty格式文件的頭部(例如，單位、操作條件或者表索引)潛在地影響庫 中的單元，所以默認將頭部的非注釋記號添加到庫中的單元概要中。由此，頭部中的任何改 變將改變單元概要。匹配Verilog文件的報告文件testfiles/verilogjest. ν包含描述某些晶體管級單元的若干較小模塊。 這些模塊中的某些是拷貝。例如，模塊DEF_X2是模塊DEF_X1的直接拷貝。因此，針對兩個 模塊的概要是相同的otismartsig -ver testfiles/verilog_test. νCell “ DFF—Xl"Interface CRC cl02a525Contents CRC dbac5dc2Cell “ DFF_X2〃Interface CRC cl02a525Contents CRC dbac5dc2[1723]單元內(nèi)的空行被移除，但是語言構造是相同的。任一模塊內(nèi)都不存在注釋，所以不 報告注釋概要。文件testf i les/verilog_test2 包含模塊 0AI21_X1 和 0AI21_X2。后者是相同的， 除了改變了端口排列。通常，使用位置參數(shù)來對Verilog模塊進行實例化，所以，與模塊的 連接將是不同的，并且概要也將不同otismartsig -ver testfiles/verilog_test2. νFile " testfiles/verilog_test2. v" Verilog formatFile CRC 25de7835File header CRC 6ef229e6File comment CRC 6ef229e6File non-whitespace CRC 07f87fb9File whitespace CRC ac6fc0b2Cell “ 0AI21_X1〃Interface CRC dae46517Contents CRC c73aceafCell “ 0AI21_X2〃Interface CRC 01391569Contents CRC c73aceaf然而，如果指定了 -sort，則將端口按字母順序放置以用于計算概要之目的，并且 單元將匹配otismartsig -sort -ver testfiles/verilog_test2. νFile CRC 25de7835File header CRC 6ef229e6File comment CRC 6ef229e6File non-whitespace CRC 07f87fb9File whitespace CRC ac6fc0b2Cell “ 0AI21_X1〃Interface CRC cf2d7023Contents CRC c73aceafCell “ 0AI21_X2〃Interface CRC cf2d7023Contents CRC c73aceaf匹配⑶SII文件的報告文件testfiles/sigtest. gds是綜合⑶SII格式文件，其被構造為顯示⑶SII 規(guī)范化單元概要計算的某些特征。其包含四個單元，Structure」到Structure_4。 Structure_2是葉單元，其被其他三個單元引用。結構和數(shù)組引用不具有層編號，所以其概 要作為非層數(shù)據(jù)存儲在層-1上otismartsig -gds testfiles/sigtest. gdsFile “ testfiles/sigtest. gds" :GDS format[1755]File CRC d0b40760Cell ‘‘ Structure」"Comment CRC b0f5064eLayer _1 CRC 485b93e7Layer 3 CRC 58ffb953Layer 42 CRC e6098359Cell CRC 4658afa3Cell “ Structure_2"Comment CRC 6acc5dddLayer 1 CRC 0e517512Layer 5 CRC 00065ea8Layer 19 CRC 931b9a0fCell CRC f780ec68Cell “ Structure_3"Comment CRC b0f5064eLayer _1 CRC 485b93e7Layer 3 CRC 58ffb953Layer 42 CRC e6098359Cell CRC 4658afa3Cell " Structure_4〃Comment CRC 9d8b21adLayer _1 CRC 485b93e7Layer 3 CRC 47a23fddLayer 42 CRC e6098359Cell CRC 747b0eceStructure_3是Structure_l的直接拷貝，所以其所有概要與Structure_l的 相同。StrUCtUre_4的層3上的多邊形按照不同的順序，所以針對層3的概要不同于 Structure_l和Mructure_3?？蛇x地，otismartsig用戶可以指定多邊形的排序和其他步 驟，以進一步重新組織所概括的設計數(shù)據(jù)。應用規(guī)范化概要來解決IC設計問題計算和比較規(guī)范化概要可以在集成電路的設計中具有很多實踐使用。要求保護的 技術的不同實施方式解決了不同的問題。以上列出了針對該技術的某些使用情況。圖3示 出了可以有益地應用所公開的技術的設計過程中的交接點。圖3中的多數(shù)框與圖1中的框 相匹配。圖3中添加了審核362，其指示在代工廠制造的生產(chǎn)設計的獨立查看，用以驗證生 產(chǎn)設計中存在承擔使用費的設計模板。虛線框301放置在可以有益地應用計算和比較規(guī)范 化概要的交接點處，但并不旨在窮舉性的。在邏輯綜合123之前，可以測試用于綜合的單元 設計庫的有效性。隨著從代工廠141接收新數(shù)據(jù)以并入單元設計庫131中，可以查看和評 估改變的重要性。在布圖規(guī)劃133之前和之后，可以針對經(jīng)批準單元的使用、單元的重命名 和修改來仔細查看設計，以避免使用不良單元。作為審核過程362的一部分，可以將生產(chǎn)設計中的規(guī)范化單元概要與承擔使用費的設計單元概要進行比較。可以生成生產(chǎn)設計中的單 元的列表和計數(shù)，以用于使用費審核目的。這些有益應用在以下部分中將進一步易見。共同主題所描述的有益應用依賴于計算機實現(xiàn)的方法，該方法用于評估駐留在兩個或更多 文件中的針對電路的設計數(shù)據(jù)之間的相似性和/或差異性。計算機被用于標識設計數(shù)據(jù)內(nèi) 的單元或者設計單位，以上描述了單元和設計單位。如所解釋的，單元可以分組為塊。一些 文件可以包括單個頭部或者單元。在單元內(nèi)，設計數(shù)據(jù)的語法被解析，并被標準化為規(guī)范化 形式。規(guī)范化形式降低了數(shù)據(jù)分析對設計數(shù)據(jù)中的非功能性改變的敏感性。計算并且存儲 針對規(guī)范化形式的設計數(shù)據(jù)的至少一部分的概要。每個單元或者設計單位產(chǎn)生至少一個概 要，并且通常不止一個概要。還產(chǎn)生針對不被視為任何特定單元的部分的文件頭部的概要。 將一個文件中的單元的概要與其他文件中的單元的概要進行比較。根據(jù)相似性或者差異性 是否更加適合任何特定分析，生成適合的總結?？偨Y可以是人類可讀的報告，或者存儲在計 算機文件中以用于由其他程序進一步處理。更新的單元設計庫的理解設計者面臨的問題之一是雖然可以從代工廠、庫供應商或者內(nèi)部開發(fā)組接收設 計庫的新版本，但沒有從一個版本到下一版本的改變的滿意描述。常規(guī)的區(qū)分工具可以用 于將新庫與老庫進行比較。如上所述，區(qū)分工具設計用于為改變添加標志，而不是評估改變 的重要性。計算庫的老版本和新版本的概要可以用于標識改變的單元。單元在功能性和 非功能性數(shù)據(jù)之間的劃分以及將單元劃分到層中可以產(chǎn)生概要，根據(jù)該概要，庫管理者可 以評估到庫的新版本的改變的重要性，并且進一步詳細調(diào)查。可以將非功能性數(shù)據(jù)的改變 (諸如對標識庫版本的注釋的改變或者對應用軟IP標簽添加的IP標簽的改變)與功能上 重要的數(shù)據(jù)的改變分離開。這種分離可以用于過濾總結或者為其添加色碼(color code), 并且?guī)椭鷰旃芾碚邲Q策進行到何處。在開發(fā)其月丨旬是否采耳又更新的單元設i十庫集成電路設計是使用數(shù)以萬計的單元以及幾十或者幾百個復雜設計模板的迭代 過程。邏輯設計團隊使用邏輯綜合來生成結構化網(wǎng)表，其被發(fā)送至集成團隊以用于布局和 布線過程。在設計過程的最后階段，在對頂層塊進行布局、布線和優(yōu)化時，其用于確保設計 使用所有庫元件的最新版本。然而，通過第一輪布局和布線，在設計項目中投入了太多，使得項目管理者將想要 知道庫中發(fā)生了什么改變，以及為何在其接受需要設計的重新工作的庫的新版本之前發(fā)生 改變。例如，如果改變了定時模塊，則需要進行另一輪現(xiàn)場優(yōu)化，以匹配新的定時數(shù)據(jù)。如 果改變了庫交換格式(LEF)文件中的單元占用面積，則可能需要新的布局和布線步驟，這 可能造成定時以及進一步迭代的巨大改變。這些步驟中任何一個的重新工作都牽涉將無法 滿足性能目標或者將延誤截止期限的風險。將這些風險與庫的新版本解決的生產(chǎn)或者功能 性問題進行權衡。所公開的技術可以用來聚焦到對正在開發(fā)的設計中實際使用的單元上的已更新 單元設計庫的分析。針對開發(fā)中的設計、老庫單元和新庫單元的概要的三種方式的比較對 于項目管理者而言是有用的，這些項目管理者需要決策在已經(jīng)做出了相當?shù)耐顿Y之后是否 要采取更新的單元庫。在管理者做出決策之前，可以考慮多種設計語言的設計數(shù)據(jù)的多個視圖。mwmmm^Mmmm /單元具有很多潛在源，這些源在公司內(nèi)或者來自供應商。確定單元來自經(jīng)批準的 源還是未被批準的源是有用的。另外，最初被批準的單元可能被證明是不良的，并且被放置 在排序的黑名單中，該黑名單是不應當在任何設計中使用的不良單元的列表。規(guī)范化概要 的一種有益應用是確定設計中的哪些單元不存在于任何經(jīng)批準的單元庫中。另一有益應用 是確定設計中的任何單元是否具有與不應當在任何設計中使用的不良單元的庫相匹配的 數(shù)據(jù)。當然，這些可以組合使用。標識設計數(shù)據(jù)中的重侖名單元在設計期間，已知設計者對單元進行了重命名，以便避免單元名稱沖突，因為在某 些工具中，要求單元名稱是唯一的。理想上，名稱沖突可以作為調(diào)查單元的兩個使用是否依 賴于相同的單元版本以及在不同的版本之間選擇的原因。正在進行的設計項目的壓力有時 導致不理想的實現(xiàn)。因此，設計者簡單地對其使用的單元進行重命名并且保留。規(guī)范化概要可以用于找到重命名的單元的源。對重命名的單元的概要與單元庫進 行比較提供了比單元內(nèi)的注釋更加可靠的單元源的指示，當工作組規(guī)則或者期待阻止單元 的重命名時尤其如此。對概要進行比較可以證明重命名的單元與經(jīng)批準的設計相匹配，這 給予設計管理者或者設計者將單元名稱反轉(zhuǎn)為經(jīng)批準的設計中所使用的名稱的信心。當設 計工具使用單元名稱作為參考時，期望使用與經(jīng)批準的庫元件相匹配的名稱。檢測危害擔保的單元修改利用供應商提供的模板開始工作的設計團隊可能嘗試對模板進行改進。例如，可 以改變編譯的隨機訪問存儲器以更好地適合所感知到的當前設計需要。然而，設計者可能 無法完全理解改變的后果。例如，在標稱過程條件下加速存儲器的改變實際上在其他過程 條件下可能減慢存儲器。在半導體行業(yè)中，這是指在其他工藝拐點發(fā)生什么。設計的改變 還可能由于導致橋接故障或者開放觸點而破不良電路的生產(chǎn)。這些改變可能使從供應商接 收的設計模板的顯式或者隱式的擔保無效。可以分析具有多個概要的單元，以確定其是否是另一單元的修改版本。在某些情 況下，多個庫單元將跨某些層匹配。例如，都具有相同功能的單元類內(nèi)的金屬布局可能匹 配。當檢測到跨某些層但不是全部層的匹配時，可以執(zhí)行進一步的分析，以確定是否發(fā)生了 未授權修改。可選地，可以對該分析加權，以強調(diào)隱式修改的層改變而不是單元的共同類的 成員之間的正常改變。使用費審核流片數(shù)據(jù)通常對于代工廠是可用的，作為制造過程的一部分。該流片數(shù)據(jù)可以按 照OASIS 、⑶SII或者其他語言來表達。其包括定義掩膜的多邊形，該掩膜用作制造工具 或者用于制造期間的直接寫入?；趩卧械亩噙呅?，可以將來自流片數(shù)據(jù)的經(jīng)概括的單元與來自使用費承擔庫 的經(jīng)概括單元進行比較。可以通過排序來標準化這些多邊形?？梢钥蛇x地通過將單元中的 多邊形合并并且應用一致的分割算法使其重新分割來對其進行進一步標準化。使用單元概要來審核代工廠處使用的設計并且計算所擁有的使用費具有以下優(yōu) 點，即審核者可以在不直接訪問所概括的設計數(shù)據(jù)的情況下分析概要。如果代工廠運行概括工具，則審核者僅需要查看所產(chǎn)生的概要。通過審核者進一步查看設計數(shù)據(jù)而不限于概 要，可以解決封閉式問題。使用費審核還可以通過基于符號、文本的設計數(shù)據(jù)而不是多邊形數(shù)據(jù)來導出。故障分析的立即響應有時，故障分析將證實設計模板是不良的并且不應當在任何產(chǎn)品中使用。由于設 計模板的重命名和修改，這為設計管理者提出了嚴重的問題。規(guī)范化概要提供了快速掃描 現(xiàn)有生產(chǎn)設計以及過程中設計的方式。可以將證明是不良的設計模板上的一個或多個變體 的概要與針對現(xiàn)有產(chǎn)品的概要庫以及過程中的設計的項目文件進行比較。可以為概要匹配 或者部分匹配不良設計模板的概要的設計添加標志以用于進一步調(diào)查。這給予設計管理者 一種方式，使其不止能夠發(fā)現(xiàn)保留與原始設計庫的鏈接的單元。這允許設計管理者發(fā)現(xiàn)可 能共享導致不良設計模板的故障的層的重命名的單元和修改的單元。侖令行處理器的運行時間詵項原型規(guī)范化單元概要命令行工具的名稱是“otismartsig” ；其是將運行在1. 4. χ 和之后的核上的32位或者64位Linux (例如，Red Hat公司LinuX4. χ或之后的)可執(zhí)行 的。如果其在沒有參量的情況下運行，則其打印類似于以下的幫助文本
1808
1809
1810 1811 1812
1813
1814
1815
1816
1817
1818
1819
1820 1821 1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
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 :0ASIS 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) -Ief :Library Exchange Format(default -sort) -def :Design Exchange Format(default -sort)
84[1832]-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 filel. txt file2. txt -ver file3. txt如果文件名稱以‘_’開始，則其之前應當具有-file。一個-file參量可以用于每 個文件。詵項-sort多數(shù)文件格式提供排序數(shù)據(jù)的選項。針對若干格式，這是默認的，因為使用經(jīng)排序 的數(shù)據(jù)生成概要將比使用未排序的數(shù)據(jù)的概要生成更加有用的匹配。默認行為在文件格式 的簡要描述的結尾處的幫助文本中指定。其是· OASIS 默認排序，因為OASIS 編寫者很可能對數(shù)據(jù)重新排列，尤其是編寫重 復時·⑶SII 默認排序，因為⑶SII編寫者可能對數(shù)據(jù)重新排列，并且因為⑶SII單 元數(shù)據(jù)可能需要與OASIS 數(shù)據(jù)進行匹配· Liberty 默認排序，因為數(shù)據(jù)是順序無關的· Verilog 默認不排序，因為僅排序單元接口記錄· VHDL 默認不排序，因為僅排序單元接口記錄· SPICE 默認不排序，因為排序例程也排序單元接口記錄· LEF 默認排序，因為很多數(shù)據(jù)是順序無關的· DEF 默認排序，以為很多數(shù)據(jù)是順序無關的 非結構化文本默認不排序，因為文件的目的未知 結構化文本不允許排序，因為腳本文件是順序相關的 用戶解析的文件默認不排序，因為文件的目的對于軟件未知 非結構化二進制不允許排序，因為不存在記錄結構對于Verilog、VHDL和SPICE文件，如果某些實例使用位置端口引用(基于參數(shù)順 序的連接)而不是基于關聯(lián)的端口引用(基于參數(shù)名稱的連接)，則接口記錄(端口)的排 序可能修改單元的含義。由此，這對這些格式的排序應當謹慎進行。如果用戶想要對默認不排序的給定格式文件進行排序，則應當指定-sort選項。 如果用戶想要阻止文件的排序，則應當指定-nosort選項。這些選項是“粘性的”，意味著其 影響命令行之后所列的所有文件。詵項-mem-mem指定允許用于排序的最大存儲器量，以兆字節(jié)為單位。在本實現(xiàn)中，排序在存儲器中排他地執(zhí)行，所以如果針對單元或者文件頭部的估計存儲器使用超過該限制，則將 所影響的數(shù)據(jù)按照其原始順序發(fā)送至概要計算，并且針對該單元或者文件頭部禁用排序。 測試單元的可排序性，以使得即使在最小存儲器可用的情況下也可以排序所有較小的設計 模板塊，以增加匹配并且降低差異性的錯誤檢測。一般而言，僅較大的布局和布線塊會超過 存儲器使用限制。默認存儲器使用限制是64兆字節(jié)；在32位Linux平臺上，最大存儲器使用限制是 3500兆字節(jié)。如果-mem提供的值小于16，則默認將其增加至16 ；如果該值大于3500，則將 默認將其減小至3500。由于存儲器分配方法的不確定性，工具的存儲器使用估計是不精確的。最好不使 用接近計算規(guī)范化單元概要的機器上的物理存儲器量的存儲器限制。針對某些文件格式的 存儲器估計可以是樂觀的。文件中的某些單元可以排序，而相同文件中的其他單元太大以至于不能排序，所 以規(guī)范化單元概要工具報告是否因為設置-sort (或者默認)而對單元排序，是否因為指 定-nosort (或者默認地)而不排序，或者雖然設置了 -sort但是因為太大而不能排序Cell ‘‘ Structure」" (sorted)Cell ‘‘ Structure」" (not sorted)Cell " Structure」" (unable to sort)軟件利用概要來跟蹤和存儲針對給定單元的概要是否表示經(jīng)排序的數(shù)據(jù)的指示 或者標志。如果存儲器使用限制增加，或者用戶開始使用規(guī)范化單元概要軟件的新的、更加 有效的版本，則先前不可排序的某些單元現(xiàn)在可能將進行排序(如果用戶減少限制，則反 之亦然)。除非數(shù)據(jù)庫存儲是否根據(jù)經(jīng)排序的數(shù)據(jù)計算概要的指示，用戶將不能夠確定概要 的改變是否表示數(shù)據(jù)的真實改變，或者是否簡單地因為一組概要是針對經(jīng)排序的數(shù)據(jù)而另 一組針對未經(jīng)排序的數(shù)據(jù)。選項-64默認地，生成32比特概要；如果指定了 -64選項，則生成64比特概要。64比特概要的生成或多或少需要比32比特概要的生成更多的運行時間。64比特 概要在32比特可執(zhí)行以及64比特可執(zhí)行中是可用的。選項-verbose默認地，程序靜默地工作，僅生成概要報告或者一般的錯誤消息。針對自動化概要 生成而不是針對人類使用來優(yōu)化解析器。如果文件無法解析，并且其對于查看實際錯誤有 用，則使用-verbose標志將使錯誤打印出來。在發(fā)現(xiàn)第一個錯誤之后，很多解析器會退出， 所以錯誤報告將不會特別長。如果發(fā)現(xiàn)任何錯誤，則將不生成概要。選項-gridOASIS 和⑶SII文件中的幾何形狀是在柵格中繪制的，這意味著文件中的所有坐 標被縮放某個數(shù)目，以確定幾何形狀的絕對大小，以微米或者納米為單位。柵格存儲在文件 中，使得含義是沒有歧義的，但是如果柵格值由于某些原因改變，則單元中所有的坐標都將 改變，即使幾何形狀沒有改變。通過柵格縮放所有的坐標不是有效的方案，因為柵格是浮點 數(shù)，通常冪為10。針對浮點數(shù)的概要可能是機器相關的或者容易受到舍入誤差的影響。由此，存在針對OASIS 和⑶SII文件的-grid選項。所有坐標被縮放至該柵格的倍數(shù)，該柵格例如1納米(默認1. Oe-9米)。例如，如果文件柵格是10納米，并且規(guī)范化單 元概要柵格是1納米，則將來自文件的所有坐標發(fā)送至概要計算之前乘以10。如果OASIS 或者⑶SII文件柵格不是-grid值的整數(shù)倍，則打印錯誤。詵項-noheaderLiberty格式文件在文件頭部中具有多個定義和單位定義。如果這些文件頭部值 中任何部分改變，所有單元中的所有值(例如延遲)也可能改變。例如，如果文件頭部中的 time_unit或者voltagejnit值改變，則單元中的所有定時延遲值也將改變，即使單元中 的文本沒有改變。Liberty文件通常由腳本構建，該腳本將固定文件頭部與針對個體單元的 數(shù)據(jù)并置，并且容易使用錯誤的頭部。由此，默認地，將所有的文件頭部值(除了諸如日期 的非功能性值以外)添加到Liberty文件中的針對單元的概要中。如果用戶確信不會發(fā)生 這種錯誤，則可以使用-noheader選項來禁用頭部值合并。某㈣
具體實施例方式所公開的技術可以有益地應用于各種方式和設備。該技術還可以具體化在諸如計 算機可讀存儲介質(zhì)的制品中，該計算機可讀存儲介質(zhì)存儲有實現(xiàn)該方法或者可以與硬件相 結合以產(chǎn)生所描述的設備的計算機程序。在第一實施方式組中描述了方法。這些是評估駐留在存儲于計算機存儲器中的至 少兩個文件中的設計數(shù)據(jù)之間的相似性和/或差異性的計算機實現(xiàn)的方法。圖6和圖7提 供了這些方法的某些方面的高層流程圖。在設計數(shù)據(jù)環(huán)境中，數(shù)據(jù)可以是符號的或者二進 制的。符號意味著文本旨在成為人類可讀的。例如，數(shù)字和字母。符號文件也可以包含有 助于文本可讀性或者幫助內(nèi)部文件管理的代碼。例如制表符、字體屬性和書簽。設計文件 可以按照以上所述的任何設計語言或者格式來表達。其可以包括多邊形，該多邊形可以由 頂點和半平面來定義。其可以是層級式的，包括對其他設計數(shù)據(jù)的引用，按照展開格式或者 層級式格式?？梢灶A期廣泛的設計數(shù)據(jù)。如上所述，對兩個文件的引用是一般性的。這兩 個文件可以是相同數(shù)據(jù)庫的部分?？梢陨婕安恢箖蓚€文件。方法對駐留在第一和第二文件411中的數(shù)據(jù)進行操作。在此描述中，方法涉及對 設計內(nèi)的單元進行操作并且生成規(guī)范化單元概要。規(guī)范化意味著標準化格式。通過將某些 設計數(shù)據(jù)文件傳送通過解析器并且應用解析規(guī)則，這些設計數(shù)據(jù)文件被正則化或被轉(zhuǎn)換為 規(guī)范化格式。其他文件可能需要通過解析生成的語法樹的語義分析或者對文件進行正則化 的其他操作。取決于解析規(guī)則，正則化可能消除空白，將來自程序代碼的注釋并置，對記號 或者語法數(shù)的分支進行排序，將記號或者語法樹的分支歸類為功能性或者非功能性設計數(shù) 據(jù)，在頭部數(shù)據(jù)和單元數(shù)據(jù)之間劃分數(shù)據(jù)，或者在單元內(nèi)在單元頭部和單元主體數(shù)據(jù)之間 劃分數(shù)據(jù)，重新排列多邊形的角點，或者應用以上描述的任何其他解析或者標準化策略。應 當理解，更一般地，在所附并且原始提交的權利要求中，該方法適用于數(shù)據(jù)的設計單位，并 且詞語“設計單位”在描述中可以替換為“單元”。在此公開中，示出了如何將文件中的設 計數(shù)據(jù)劃分為頭部數(shù)據(jù)和單元數(shù)據(jù)。劃分或者區(qū)分的意思是物理上或者邏輯上分組。如 以下所解釋的，產(chǎn)生語法樹的解析規(guī)則可以自然地產(chǎn)生數(shù)據(jù)的物理劃分。一旦產(chǎn)生了語法 樹，即可以將標簽或者標志應用于語法樹的節(jié)點或者分支。標簽通常是具有特定意義的代 碼。標志也可以是代碼，但是其比標簽簡單，諸如具有特定意義的字段中的布爾值。以下方 法描述同等地適用于設計單位和單元。該方法包括標識駐留在文件中的設計數(shù)據(jù)內(nèi)的單元
87(611)。其繼續(xù)解析語法(612)，并且對單元內(nèi)的設計數(shù)據(jù)正則化(613)為規(guī)范化形式。解 析語法可以適用于符號或者二進制文件中的任一種。解析符號文件包括標識記號，并且根 據(jù)描述語言的一系列解析規(guī)則來識別其在文件中的角色。解析二進制設計數(shù)據(jù)文件包括標 識二進制數(shù)據(jù)的元素和組，并且根據(jù)描述設計文件的二進制格式的解析規(guī)則來識別其在設 計數(shù)據(jù)中的角色。解析有時包括構建語法樹。備選地，解析可以生成事件的流。正則化已 在上文描述。規(guī)范化形式可以維護在一個或多個語法樹532中。規(guī)范化形式降低了數(shù)據(jù)分 析對特定單元內(nèi)的設計數(shù)據(jù)中的非功能性改變的敏感性。設計數(shù)據(jù)的非功能性改變是對設 計數(shù)據(jù)的這樣的改變，這些改變不改變使用該設計數(shù)據(jù)產(chǎn)生的物理電路。例如，注釋通常是 非功能性設計數(shù)據(jù)；空白在符號文件中通常是非功能性的；在多邊形角坐標的排列的列表 中，起始坐標的選擇以及該角是以順時針還是逆時針方向列出通常是非功能性的。在較高 層處，例如，將復雜多邊形分割為梯形或者三角形不應當功能性地改變所產(chǎn)生的物理電路， 但是特定的分割算法對于生產(chǎn)過程中使用的特定工具的操作是有必要的。該方法還包括計 算(614)以及存儲至少所選擇的規(guī)范化形式的設計數(shù)據(jù)的概要415，針對每個單元產(chǎn)生至 少一個概要。該方法比較(615)規(guī)范化形式的概要，并且總結(616)比較概要的至少一些結果。 其可以在存儲器中產(chǎn)生總結473，諸如對另一程序可用的數(shù)據(jù)表，或者用戶可查看的報告 475。執(zhí)行這種比較可以存在多種方式。一個或多個概要集合存儲在可搜索的數(shù)據(jù)結構 中。一種方便的可搜索數(shù)據(jù)結構是散列表，其通過概要的模數(shù)來索引?？梢允褂昧硪簧⒘泻?數(shù)。散列表的大小可以基于所需要的存儲以及表中的散列之間的沖突的期望頻率來選擇。 在沖突的情況下，創(chuàng)建鏈接至散列表的列表。備選地，以排序概要為代價，可以創(chuàng)建概要的 反向索引。在多種實施方式中，針對每個單元將具有多個概要。對多個概要進行比較和評 分的一種方法是創(chuàng)建具有與針對感興趣的單元的任何概要相匹配的概要的所有單元的列 表。在一些實施方式中，可以對該列表進行排列，例如將來自最新庫的單元排在來自較老庫 的單元之前。使用候選單元的列表，在針對感興趣的單元的所有概要與針對候選單元的概 要之間進行比較。特別地，對于經(jīng)排列的列表，當在針對感興趣的單元的所有概要以及候選 單元之一之間發(fā)現(xiàn)匹配時，比較可以終止。當不存在感興趣的單元與任何候選單元之間的 完全匹配時，可以對多個概要匹配應用某個閾值或者比率，它使得成對的單元被認為是類 似的。備選地，在不存在完全匹配的情況下，可以對部分匹配進行等級排列，并且總結或者 報告一個或多個部分匹配。該方法的一個方面還包括在計算和存儲概要之前，劃分規(guī)范化形式的功能上重要 的設計數(shù)據(jù)722與不重要的數(shù)據(jù)。當設計數(shù)據(jù)的改變將導致根據(jù)該設計數(shù)據(jù)生成的電路的 改變時，該設計數(shù)據(jù)是功能上重要的。繼而，所選擇的用于計算概要的規(guī)范化形式的設計數(shù) 據(jù)至少包括功能上重要的設計數(shù)據(jù)。概要比較中的附加粒度可以通過如下方式來支持按單元頭部、接口和/或主體 721、按層723以及按可排序/順序相關數(shù)據(jù)7M來劃分單元內(nèi)的設計數(shù)據(jù)。劃分策略可以 產(chǎn)生數(shù)據(jù)的物理或者邏輯劃分。數(shù)據(jù)的物理劃分包括將數(shù)據(jù)分為物理分離的組，諸如第一 列表和第二列表。邏輯劃分數(shù)據(jù)可以包括為數(shù)據(jù)添加標簽或者標志，以使計算機將數(shù)據(jù)項 識別為屬于特定組。這些劃分策略可以單獨應用或者以任何組合來應用。解析712創(chuàng)建了一個或多個語法樹532，其可以按照期望劃分設計數(shù)據(jù)。針對某些劃分策略，這包括定義如 何組織語法樹中的節(jié)點和分支。針對其他劃分策略，這可以包括為語法樹中的節(jié)點或者分 支設置標志。標志如上文所述。計算和存儲概要還包括針對每個劃分產(chǎn)生至少一個概要。 總結在根據(jù)不同劃分類型產(chǎn)生的概要之間進行區(qū)分。上述方法可以應用于比較使用不同的設計語言編碼的文件。本公開描述的如何呈 現(xiàn)可比較的兩種語言是OASIS 設計語言和⑶SII設計語言。當比較這兩種語言時，以上引 用的第一文件和第二文件是OASIS 和GDSII文件。當針對其他配對而開發(fā)等效方法時，其 可以是兩種其他語言。當比較不同設計語言的文件時，針對設計語言的規(guī)范化形式呈現(xiàn)了 至少單元的主體中的可比較設計數(shù)據(jù)。備選地，針對在單元頭部而不是在單元主體本身中 表達的單元之間的功能性差異，規(guī)范化形式可以呈現(xiàn)至少單元頭部中的可比較設計數(shù)據(jù)。上述方法可以應用于相對于老單元設計庫來評估新單元設計庫。繼而，第一文件 是新單元設計庫，而第二文件是老庫?？偨Y還包括報告通過比較兩個庫的概要而檢測到的 新庫中的至少功能上重要的改變。上述方法還可以應用于評估采用新庫的影響。該方法的這種應用還應用于確定設 計文件中的單元是否屬于過期庫。此應用還包括第三文件，向該第三文件應用標識、解析和 計算動作。在該變體中，第一文件是設計文件，第二文件是至少一個單元設計的當前庫，而 第三文件是至少一個單元設計的過期庫?？偨Y包括報告設計文件中具有與當前庫中的單元 設計的概要不匹配、但是與過期庫中的單元設計的概要相匹配的概要的單元?？蛇x地，還可 以報告不出現(xiàn)在當前庫或者過期庫的任何一個中的單元設計。此報告標準自然地消除了報 告在當前庫和過期庫二者中相同的單元設計。雖然將本發(fā)明描述為比較當前和過期庫，但 是這些表述用于指示庫的兩種生成，并且可以僅簡單地應用于尚未采用的候選版本(所謂 的“當前版本”)以及生產(chǎn)版本(所謂的“過期版本”)。上述方法的另一應用是標識不良的或者未被批準的單元。檢測不良的或者未被批 準的單元可以獨立進行或者組合進行。上述方法可以應用于評估設計文件以確定設計文件 中的單元是否屬于已知不良單元的集。在此應用中，第一文件是設計文件，其與包含已知不 良單元的文件進行比較?？偨Y還包括報告設計文件中具有與已知不良單元的文件中的單元 的概要相匹配的概要的單元。類似地，上述方法可以應用于評估設計文件以確定設計文件 中的單元是否屬于至少一個經(jīng)批準的庫。報告通常將在排除的基礎上報告設計文件中具有 與經(jīng)批準的庫中的單元的概要不匹配的概要的單元?？蛇x地，當不存在設計文件中的單元 與經(jīng)批準的庫中的任何單元的完全匹配時，可以報告部分匹配。上述方法的進一步使用是檢測具有不同單元名稱的功能上相同的單元。第一文件 是設計文件，而第二文件是至少一個經(jīng)批準的庫。計算和存儲概要應用于設計文件和經(jīng)批 準的庫的多個層中的至少功能上重要的數(shù)據(jù)?？偨Y還包括將設計文件中具有與經(jīng)批準的 庫中的概要相匹配的多個層中的功能上重要的數(shù)據(jù)的概要的單元(稱為“功能上匹配的單 元”)報告為重命名的單元，但是該重命名的單元具有與功能上匹配單元的單元名稱不匹配 的單元名稱?？蛇x地，該方法可以進行擴展，以反轉(zhuǎn)設計文件中報告為“重命名”的單元，以 具有匹配并且鏈接至經(jīng)批準的庫中的功能上匹配的單元的單元名稱。上述方法的一種感興趣的使用是評估設計文件以確定是否從其擔保的設計模板 中修改了設計文件中的擔保的單元或者其他單元。第一文件是設計文件，而第二文件是至少一個經(jīng)批準的庫。計算和存儲概要應用于設計文件和經(jīng)批準的庫中的單元的多個層中的 至少功能上重要的數(shù)據(jù)?？偨Y還包括將設計文件中具有與經(jīng)批準的庫中的單元的概要相匹 配的多個層中的一些但非全部層中的功能上重要的數(shù)據(jù)的概要的單元報告為潛在修改的 單元。上述方法的另一應用是掃描生產(chǎn)設計以找到生產(chǎn)設計中使用的使用費承擔單元 設計。在此應用中，第一文件包括使用費承擔單元設計的一個或多個使用費承擔庫，而第二 文件包括一個或多個包括單元設計的生產(chǎn)設計?？偨Y還包括將生產(chǎn)設計中具有與使用費承 擔庫中的單元的概要相匹配的概要的單元報告為潛在使用費承擔特定單元。可選地，還可 以報告近似匹配。近似匹配是應用于具有多個概要(諸如針對單元的多個層的概要)的單 元或者設計單位的項。如果單元中的多數(shù)層具有匹配的概要，則這兩個單元可以是近似匹 配。第二組實施方式是設備。這些是評估駐留在存儲于計算機存儲器中的至少兩個文 件中的設計數(shù)據(jù)之間的相似性和/或差異性的計算機設備。先前描述的圖5提供了這些設 備的某些方面的高層框圖。與方法實施方式相同，該設備處理的設計數(shù)據(jù)可以是符號的或 者二進制的。其可以在以上描述的任何設計語言或者格式中表達。其可以包括多邊形。其 可以是層級式的，包括對其他設計數(shù)據(jù)的引用，按照展開或者層級格式。預期廣泛的設計數(shù) 據(jù)。如上所述，對兩個文件的引用是一般性的。兩個文件可以是相同數(shù)據(jù)庫的部分。可以 涉及不止兩個文件。該設備包括至少一個處理器和存儲器530、535。解析器531運行在處理器上，并且 解析包含表示用于物理電路的設計的方面的設計數(shù)據(jù)的文件411，以及在存儲器中創(chuàng)建一 個或多個語法樹532。在本說明書中，設備對設計內(nèi)的單元進行操作，并且生成規(guī)范化單元 概要。應當理解，更一般地，設備可以對數(shù)據(jù)的設計單位進行操作，并且在所附以及原始提 交的權利要求的描述中，表述“設計單位”可以替換“單元”。正則化器邏輯533運行在處理器上并且與解析器432協(xié)作，其組織語法樹532以 產(chǎn)生規(guī)范化形式。在短語“正則化器邏輯”中，邏輯的意思是控制計算機組件的操作的指令。 在處理器上運行時，邏輯通常將是根據(jù)程序指令編譯的對象代碼。在處理器內(nèi)，邏輯可以是 微指令。在可編程邏輯組件(諸如，現(xiàn)場可編程門陣列(FPGA))中，邏輯可以由門以及門之 間的連接來表示。在此應用中，邏輯告知計算機組件如何執(zhí)行任務。正則化器邏輯包括劃 分模塊，其將文件劃分為至少一個頭部，并且根據(jù)用于編碼文件的設計語言的規(guī)則，將文件 劃分為設計數(shù)據(jù)的多個單元。劃分模塊組織語法樹，以表示頭部和單元劃分。如以上所解 釋的，在各種設計語言中，文件可以包含頭部數(shù)據(jù)、單元數(shù)據(jù)或者二者。為了清楚起見，設備 應用于僅包含頭部和單元數(shù)據(jù)其中一個的文件。正則化器邏輯還包括規(guī)范化形成模塊，其解釋語法樹以產(chǎn)生設計數(shù)據(jù)的規(guī)范化形 式，其中規(guī)范化形式降低了數(shù)據(jù)分析對設計數(shù)據(jù)中的非功能性改變的敏感性。該設備還包括運行在處理器上的概括器534，其計算概要并且將其存儲在存儲器 415中，針對每個劃分至少產(chǎn)生一個概要。比較器模塊536運行在處理器535上，并且比較規(guī)范化形式的概要。模塊是實現(xiàn) 特定任務的邏輯分段。例如，正則化器邏輯包括多個模塊。也運行在處理器535上的報告 器537總結比較概要的至少一些結果。報告器可以在存儲器中產(chǎn)生總結473，諸如可用于其它程序的數(shù)據(jù)表，或者用戶可查看的報告475。存在可以構造解析器的多種方式。一個或多個概要集合存儲在可搜索數(shù)據(jù)結構 中。解析器的結構取決于可搜索數(shù)據(jù)結構。一種方便的數(shù)據(jù)結構是散列表，其通過概要的 模數(shù)來索引?？梢允褂昧硪簧⒘泻瘮?shù)。散列表的大小可以基于所需要的存儲以及表中的散 列之間的沖突的期望頻率來選擇。在沖突的情況下，創(chuàng)建鏈接至散列表的列表。備選地，以 排序概要為代價，可以創(chuàng)建概要的反向索引。在多個實施方式中，每個單元將有多個概要。 對多個概要進行比較和評分的一種方法是創(chuàng)建具有與針對感興趣的單元的任何概要相匹 配的概要的所有單元的列表。在一些實施方式中，可以對該列表進行排列，例如將來自最新 庫的單元排在來自較老庫的單元之前。使用候選單元的列表，在針對感興趣的單元的所有 概要與針對候選單元的概要之間進行比較。特別地，對于經(jīng)排列的列表，當在針對感興趣的 單元的所有概要以及候選單元之一之間發(fā)現(xiàn)匹配時，比較可以終止。當不存在感興趣的單 元與任何候選單元之間的完全匹配時，可以針對多個概要匹配應用某個閾值或者比率，其 使得成對的單元被認為是類似的。備選地，在不存在完全匹配的情況下，可以對部分匹配進 行等級排列，并且總結或者報告一個或多個部分匹配。在概括器計算和存儲概要之前，劃分模塊還可以劃分規(guī)范化形式的功能上重要的 設計數(shù)據(jù)與不重要的數(shù)據(jù)。當設計數(shù)據(jù)的改變將導致根據(jù)該設計數(shù)據(jù)生成的電路的改變 時，該設計數(shù)據(jù)是功能上重要的。繼而，所選擇的由概括器534處理以計算概要的規(guī)范化形 式的設計數(shù)據(jù)至少包括功能上重要的設計數(shù)據(jù)。概要比較中的附加粒度可以這樣來支持按單元頭部、接口和/或主體、按層以及 按可排序/順序相關數(shù)據(jù)來劃分單元內(nèi)的設計數(shù)據(jù)而得到支持。劃分策略可以單獨應用或 者以任何組合來應用。針對劃分選項，解析器531創(chuàng)建一個或多個語法樹532，其按照期望 劃分設計數(shù)據(jù)。針對某些劃分策略，這包括如何組織語法樹中的節(jié)點和分支。針對其他劃 分策略，這可以包括為語法樹中的節(jié)點或者分支設置標志。計算和存儲概要的概括器針對 每個劃分產(chǎn)生至少一個概要。報告器537在根據(jù)不同劃分類型產(chǎn)生的概要之間進行區(qū)分。該設備可以比較使用不同的設計語言編碼的文件。本公開描述的如何呈現(xiàn)可比較 的兩種語言是OASIS 設計語言和GDSII設計語言。當比較這兩種語言時，以上引用的第一 文件和第二文件是OASIS 和GDSII文件。當針對其他配對而開發(fā)等效物時，其可以是兩種 其他語言。當比較不同設計語言的文件時，規(guī)范化形成模塊產(chǎn)生針對呈現(xiàn)至少單元的主體 中的可比較設計數(shù)據(jù)的設計語言的規(guī)范化形式。備選地，針對在單元頭部而不是在單元主 體本身中表達單元之間的功能性差異的設計語言，規(guī)范化形式可以呈現(xiàn)至少單元頭部中的 可比較設計數(shù)據(jù)。上述設備可以應用于相對于老單元設計庫來評估新單元設計庫。繼而，第一文件 是新單元設計庫，而第二文件是老庫。報告器還報告通過比較兩個庫的概要而檢測到的新 庫中的至少功能上重要的改變。上述設備還可以應用于評估采用新庫的影響。該設備的這種應用還應用于確定設 計文件中的單元是否屬于過期庫。涉及三個文件。第一文件是設計文件，第二文件是至少 一個單元設計的當前庫，而第三文件是至少一個單元設計的過期庫。報告器模塊使用來自 解析器的結果，并且報告設計文件中具有與當前庫中的單元設計的概要不匹配、但是與過 期庫中的單元設計的概要相匹配的概要的單元?？蛇x地，還可以報告不出現(xiàn)在當前庫或者過期庫的任何一個中的單元設計。此報告標準自然地消除了報告在當前庫和過期庫二者中 相同的單元設計。雖然將本方法描述為比較當前和過期庫，但是這些表述用于指示庫的兩 種生成，并且可以相同地應用于尚未采用的候選版本(所謂的“當前版本”)以及生產(chǎn)版本 (所謂的“過期版本”)。上述設備的另一應用是標識不良的或者未被批準的單元。檢測不良的或者未被批 準的單元可以獨立進行或者組合進行。該設備可以應用于評估設計文件以確定設計文件中 的單元是否屬于已知不良單元的集。在此應用中，第一文件是設計文件，其與包含已知不良 單元的文件進行比較。報告器模塊總結設計文件中具有與已知不良單元的文件中的單元的 概要相匹配的概要的單元。類似地，上述設備可以應用于評估設計文件以確定設計文件中 的單元是否屬于至少一個經(jīng)批準的庫。同樣，第一文件是設計文件，其與至少一個經(jīng)批準的 庫進行比較。報告器模塊通常將在排除的基礎上報告設計文件中具有與經(jīng)批準的庫中的單 元的概要不匹配的概要的單元?？蛇x地，當不存在設計文件中的單元與經(jīng)批準的庫中的任 何單元的完全匹配時，可以報告部分匹配。上述設備的進一步使用是檢測具有不同單元名稱的功能上相同的單元。針對該使 用的劃分模塊進一步通過單元內(nèi)的層來劃分文件，并且組織語法樹以反映該層。第一文件 是設計文件，而第二文件是至少一個經(jīng)批準的庫。概括器計算和存儲概要，其反應設計文件 和經(jīng)批準的庫的多個層中的至少功能上重要的數(shù)據(jù)。報告器模塊還將設計文件中具有與經(jīng) 批準的庫中的概要相匹配的多個層中的功能上重要的數(shù)據(jù)的概要的單元(稱為“功能上匹 配的單元”)總結為“重命名，，的單元，但是該重命名的單元具有與功能上匹配的單元的單 元名稱不匹配的單元名稱?？蛇x地，該方法可以進行擴展，以翻轉(zhuǎn)設計文件中報告為“重命 名”的單元，以具有匹配并且鏈接至經(jīng)批準的庫中的功能上匹配的單元的單元名稱。上述設備的一種感興趣的使用是評估設計文件以確定是否從其擔保的設計模板 中修改了設計文件中的擔保的單元或者其他單元。第一文件是設計文件，而第二文件是至 少一個經(jīng)批準的庫。概括器計算和存儲設計文件和經(jīng)批準的庫中的單元的多個層中的至少 功能上重要的數(shù)據(jù)的概要。報告器還將設計文件中具有與經(jīng)批準的庫中的單元的概要相匹 配的多個層中的一些但非全部層中的功能上重要的數(shù)據(jù)的概要的單元總結為潛在修改的 單元。上述設備的另一應用是掃描生產(chǎn)設計以找到生產(chǎn)設計中使用的使用費承擔單元 設計。在此應用中，第一文件包括使用費承擔單元設計的一個或多個使用費承擔庫，而第二 文件包括一個或多個包括單元設計的生產(chǎn)設計。報告器還將生產(chǎn)設計中具有與使用費承擔 庫中的單元的概要相匹配的概要的單元總結為潛在使用費承擔特定單元?？蛇x地，還可以 報告近似匹配。第三組實施方式是制品，與案例h re Beauregard—致但不限于此。在一個實施 方式中，這些制品包括存儲有程序代碼的計算機可讀存儲介質(zhì)，該程序代碼用于實現(xiàn)以上 描述的任何方法實施方式。程序代碼當在處理器上運行時，使得處理器執(zhí)行以上所述的動 作。在第二實施方式中，這些制品包括存儲有程序代碼的計算機可讀存儲介質(zhì)，該程序代碼 當與處理器和存儲器相結合時，創(chuàng)建以上描述的任何設備。當與處理器和存儲器相結合時， 程序代碼包括以上所述的模塊。
9權利要求
1.一種評估電路設計數(shù)據(jù)之間的相似性和/或差異性的計算機實現(xiàn)的方法，所述設計 數(shù)據(jù)駐留在存儲于計算機存儲器中的至少兩個文件中，所述方法包括使用計算機，標識駐留在第一文件和第二文件中的設計數(shù)據(jù)內(nèi)的單元，其中所述單元 對應于物理電路的設計的部分；解析所述單元內(nèi)的所述設計數(shù)據(jù)的語法，并且將所述單元內(nèi)的所述設計數(shù)據(jù)正則化為 規(guī)范化形式，其中所述規(guī)范化形式降低了數(shù)據(jù)分析對特定單元內(nèi)的設計數(shù)據(jù)的非功能性改 變的敏感性；計算和存儲所述規(guī)范化形式的至少所選擇的設計數(shù)據(jù)的概要，針對每個單元產(chǎn)生至少 一個概要；將所述第一文件中的所述單元的概要與所述第二文件中的所述單元的概要進行比較；以及總結對所述概要的所述比較的至少一些結果。
2.根據(jù)權利要求1所述的方法，還包括在所述計算和存儲之前，劃分所述規(guī)范化形式的功能上重要的設計數(shù)據(jù)和不重要的數(shù) 據(jù)，其中當設計數(shù)據(jù)的改變將導致根據(jù)所述設計數(shù)據(jù)生成的電路有所改變時，所述設計數(shù) 據(jù)是功能上重要的；以及其中所選擇的用于計算所述概要的規(guī)范化形式的設計數(shù)據(jù)至少包括所述功能上重要 的設計數(shù)據(jù)。
3.根據(jù)權利要求1所述的方法，被應用于比較不同設計數(shù)據(jù)語法的文件，所述不同設 計數(shù)據(jù)語法中的一個是0ASIS，另一個是⑶SII，其中所述第一文件包含以OASIS 設計語言表達的設計數(shù)據(jù)，并且所述第二文件包含以 ⑶SII設計語言表達的設計數(shù)據(jù)；以及針對所述OASIS 設計語言和所述GDSII設計語言的規(guī)范化形式呈現(xiàn)所述單元的主體 中的可比較設計數(shù)據(jù)。
4.根據(jù)權利要求2所述的方法，被應用于相對于老單元設計庫來評估新單元設計庫， 其中所述第一文件是新單元設計庫，并且所述第二文件是老單元設計庫；以及 所述總結還包括至少報告通過比較所述概要而檢測到的所述新庫中功能上重要的改變。
5.根據(jù)權利要求1所述的方法，被應用于評估設計文件以確定所述設計文件中的單元 是否屬于至少一個經(jīng)批準的庫并且沒有過期，所述方法還包括向第三文件應用所述標識、解析和計算的步驟；其中所述第一文件是設計文件，所述第二文件是至少一個單元設計的當前庫，并且所 述第三文件是至少一個單元設計的過期庫；以及其中所述總結還包括報告所述設計文件中具有如下概要的單元，所述概要與所述當 前庫中的單元設計的概要不匹配、并且與所述過期庫中的單元設計的概要相匹配。
6.根據(jù)權利要求1所述的方法，被應用于評估設計文件以確定所述設計文件中的單元 是否屬于已知不良單元設計的集合，其中所述第一文件是設計文件，并且所述第二文件包含已知不良單元設計；以及所述總結還包括報告設計文件中具有如下概要的單元，所述概要與已知不良單元設 計的文件中的單元的概要相匹配。
7.根據(jù)權利要求6所述的方法，還被應用于評估所述設計文件中的單元是否屬于至少 一個經(jīng)批準的庫，包括向第三文件應用所述標識、解析和計算的步驟； 其中所述第三文件是至少一個經(jīng)批準的單元庫；以及其中所述總結還包括報告所述設計文件中具有如下概要的單元，所述概要與所述經(jīng) 批準的單元庫中的單元的概要不匹配。
8.根據(jù)權利要求1所述的方法，被應用于評估設計文件以確定所述設計文件中的單元 是否屬于至少一個經(jīng)批準的庫，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫；以及 所述總結還包括報告所述設計文件中具有如下概要的單元，所述概要與所述經(jīng)批準 的庫中的單元的概要不匹配。
9.根據(jù)權利要求2所述的方法，被應用于檢測具有不同單元名稱的功能上相同的單 元，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫； 所述計算和存儲概要至少被應用于所述設計文件和所述經(jīng)批準的庫中的單元的多個 層中功能上重要的數(shù)據(jù)；以及所述總結還包括將所述設計文件中的如下單元報告為重命名的單元，所述單元具 有的所述多個層中的功能上重要的數(shù)據(jù)的概要與所述所批準的庫中的單元的概要相匹配 (稱為“功能上匹配的單元”)，但是該重命名的單元具有的單元名稱與所述功能上匹配的單 元的單元名稱不匹配。
10.根據(jù)權利要求1所述的方法，被應用于評估設計文件以確定所述設計文件中已擔 保的單元或者其他單元是否被修改，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫； 所述計算和存儲概要至少被應用于所述設計文件和所述經(jīng)批準的庫中的單元的多個 層中功能上重要的數(shù)據(jù)；以及所述總結還包括將所述設計文件中的如下單元報告為潛在被修改的單元，所述單元 具有的所述多個層中的一些但非全部層中的功能上重要的數(shù)據(jù)的概要與所述經(jīng)批準的庫 中的單元的概要相匹配。
11.根據(jù)權利要求1所述的方法，被應用于掃描生產(chǎn)設計以找到使用費承擔單元設計， 其中所述第一文件包括使用費承擔單元設計的一個或多個使用費承擔庫，并且所述第二文 件包括包含設計單元的一個或多個生產(chǎn)設計；以及所述總結還包括將所述生產(chǎn)設計中具有如下概要的單元報告為潛在的使用費承擔單 元，所述概要與所述使用費承擔庫中的單元的概要相匹配。
12.根據(jù)權利要求1所述的方法，其中解析所述設計數(shù)據(jù)的語法還包括 創(chuàng)建一個或多個語法樹，所述語法樹將單元內(nèi)的所述設計數(shù)據(jù)至少劃分為 頭部數(shù)據(jù)和主體數(shù)據(jù)，這是根據(jù)放置設計數(shù)據(jù)的格式劃分的；以及功能上重要的數(shù)據(jù)和功能上不重要的數(shù)據(jù)，其中，當所述設計數(shù)據(jù)的改變將導致根據(jù) 所述設計數(shù)據(jù)生成的電路有所改變時，所述設計數(shù)據(jù)的部分是功能上重要的；以及 其中計算和存儲概要還包括針對每個單元的每次劃分產(chǎn)生至少一個概要；以及 所述總結區(qū)分根據(jù)不同的劃分類型而產(chǎn)生的概要。
13.根據(jù)權利要求12所述的方法，其中所述語法樹還將單元內(nèi)的所述設計數(shù)據(jù)劃分為 設計層。
14.根據(jù)權利要求12所述的方法，還包括識別所述語法樹中包括如下節(jié)點的分支，所述節(jié)點表示順序無關的設計數(shù)據(jù)，其中順 序無關表示所述節(jié)點可以按照變化的順序被處理而不會改變根據(jù)所述節(jié)點所表示的設計 數(shù)據(jù)生成的電路；以及排序所識別的分支中的節(jié)點； 其中所述計算和存儲概要被應用于經(jīng)排序的節(jié)點。
15.一種評估電路設計數(shù)據(jù)之間的相似性和/或差異性的計算機實現(xiàn)的方法，所述設 計數(shù)據(jù)駐留在存儲于計算機存儲器中的至少兩個文件中，所述方法包括使用計算機，解析駐留在第一文件和第二文件中的設計數(shù)據(jù)的語法，包括物理電路設 計的頭部數(shù)據(jù)和/或單元數(shù)據(jù)(統(tǒng)稱為“設計單位”)；將所述設計單位內(nèi)的設計數(shù)據(jù)正則化為規(guī)范化形式，其中所述規(guī)范化形式降低了數(shù)據(jù) 分析對所述設計數(shù)據(jù)中的非功能性改變的敏感性；計算和存儲所述規(guī)范化形式的至少所選擇的設計數(shù)據(jù)的概要，針對每個設計單位產(chǎn)生 至少一個概要；將所述第一文件中的所述設計單位的概要與所述第二文件中的所述設計單位的概要 進行比較；以及總結對所述概要的所述比較的至少一些結果。
16.一種評估電路設計數(shù)據(jù)之間的相似性和/或差異性的設備，所述設計數(shù)據(jù)駐留在 存儲于計算機存儲器中的至少兩個文件中，所述設備包括至少一個處理器和存儲器；運行在所述處理器上的解析器，其解析包含表示物理電路設計的方面的設計數(shù)據(jù)的文 件，并且在所述存儲器中創(chuàng)建一個或多個語法樹；運行在所述處理器上并且與所述解析器協(xié)作的正則化器邏輯，其組織所述語法樹以產(chǎn) 生規(guī)范化形式，其中所述正則化器邏輯包括劃分模塊，其將所述文件劃分為至少一個頭部，并且根據(jù)用于編碼所述文件的設計語 言的規(guī)則將所述文件劃分為設計數(shù)據(jù)的多個單元，以及組織所述語法樹以表示所述頭部和 單元劃分；以及規(guī)范化形成模塊，其解釋所述語法樹以產(chǎn)生所述設計數(shù)據(jù)的規(guī)范化形式，其中所述規(guī) 范化形式降低了數(shù)據(jù)分析對所述設計數(shù)據(jù)中的非功能性改變的敏感性；運行在所述處理器上的概括器模塊，其接收針對至少所選擇的劃分的規(guī)范化形式，并 且針對每個所選擇的劃分計算至少一個概要并將其存儲在所述存儲器中；運行在所述處理器上的比較器模塊，其接收并且比較包含設計數(shù)據(jù)的至少第一文件和 第二文件的概要；以及運行在所述處理器上并且與所述概括器耦合的報告器模塊，其總結通過比較所述概要 而檢測到的至少一些匹配和/或差異性。
17.根據(jù)權利要求16所述的設備，其中所述規(guī)范化形成模塊解釋所述語法樹的分支的 可排序性，并且組織所述語法樹以反映可排序性。
18.根據(jù)權利要求16所述的設備，其中所述劃分模塊還按單元內(nèi)的層來劃分所述文 件，并且組織所述語法樹以反映所述層。
19.根據(jù)權利要求16所述的設備，其中所述劃分模塊還在功能上重要的設計數(shù)據(jù)與功 能上不重要的設計數(shù)據(jù)之間劃分所述文件，其中，當設計數(shù)據(jù)的改變將導致根據(jù)所述設計 數(shù)據(jù)生成的電路有所改變時，所述設計數(shù)據(jù)是功能上重要的；并且所述劃分模塊組織所述 語法樹以反映功能重要性。
20.根據(jù)權利要求19所述的設備，適于相對于老單元設計庫來評估新單元設計庫，其中所述第一文件是新單元設計庫，并且所述第二文件是老單元設計庫；以及所述報告器模塊總結通過比較概要而檢測到的新庫中的功能上重要的改變。
21.根據(jù)權利要求16所述的設備，適于評估設計文件以確定所述設計文件中的單元是 否屬于已知不良單元設計的集，其中所述第一文件是設計文件，并且所述第二文件包含已知不良單元設計；以及所述報告器模塊總結所述設計文件中具有如下概要的單元，所述概要與已知不良單元 設計的文件中的單元的概要相匹配。
22.根據(jù)權利要求21所述的設備，還適于評估所述設計文件中的單元是否屬于至少一 個經(jīng)批準的庫，其中所述比較器模塊還接收和比較第三文件的概要；所述第三文件是至少一個經(jīng)批準的單元庫；以及所述報告器模塊還總結所述設計文件中具有如下概要的單元，所述概要與所述經(jīng)批準 的單元庫中的單元的概要不匹配。
23.根據(jù)權利要求16所述的設備，適于評估所述設計文件中的單元是否屬于至少一個 經(jīng)批準的庫，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的單元庫；以及所述報告器模塊總結所述設計文件中具有如下概要的單元，所述概要與所述經(jīng)批準的 單元庫中的單元的概要不匹配。
24.根據(jù)權利要求16所述的設備，適于評估設計文件以確定所述設計文件中的單元是 否屬于至少一個經(jīng)批準的庫并且沒有過期，其中所述比較器模塊還接收和比較第三文件的概要；所述第一文件是設計文件，所述第二文件是至少一個單元設計的當前庫，并且所述第 三文件是至少一個單元設計的過期庫；以及所述報告器模塊總結所述設計文件中具有如下概要的單元，所述概要與所述當前庫中 的單元設計的概要不匹配、并且與所述過期庫中的單元設計的概要相匹配。
25.根據(jù)權利要求19所述的設備，還適于檢測具有不同單元名稱的功能上相同的單 元，其中所述劃分模塊還按單元內(nèi)的層來劃分所述文件，并且組織所述語法樹以反映所述層； 所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫； 所述概括器計算設計文件和所述經(jīng)批準的庫中的單元的多個層中的至少功能上重要 的數(shù)據(jù)的概要，并且將其存儲在所述存儲器中；以及所述報告器模塊將所述設計文件中的如下單元報告為重命名單元，所述單元具有的所 述多個層中的功能上重要的數(shù)據(jù)的概要與所述經(jīng)批準的庫中的單元的概要相匹配(稱為 “功能上匹配的單元”)，但是重命名的單元具有的單元名稱與所述功能上匹配的單元的單 元名稱不匹配。
26.根據(jù)權利要求16所述的設備，適于評估設計文件以確定所述設計文件中擔保的單 元或者其他單元是否已被修改，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫； 所述概括器計算所述設計文件和所述經(jīng)批準的庫中的單元的多個層中的至少功能上 重要的數(shù)據(jù)的概要，并且將其存儲在所述存儲器中；以及所述報告器模塊將所述設計文件中具有如下概要的單元報告為潛在被修改的單元，所 述單元具有的所述多個層中的一些但非全部層中的功能上重要的數(shù)據(jù)的概要與所述經(jīng)批 準的庫中的單元的概要相匹配。
27.根據(jù)權利要求16所述的設備，適于掃描生產(chǎn)設計以找到使用費承擔單元設計，其中所述第一文件包括使用費承擔單元設計的一個或多個使用費承擔庫，并且所述第二文 件包括包含單元設計的一個或多個生產(chǎn)設計；以及所述報告器模塊將所述生產(chǎn)設計中具有如下概要的單元報告為潛在使用費承擔單元， 所述概要與所述使用費承擔庫中的單元的概要相匹配。
28.根據(jù)權利要求16所述的設備，適于比較不同設計數(shù)據(jù)語法的文件，所述不同設計 數(shù)據(jù)語法中的一個是0ASIS ，另一個是⑶SII，其中所述第一文件包含以OASIS ，設計語言表達的設計數(shù)據(jù)，并且所述第二文件包含以 ⑶SII設計語言表達的設計數(shù)據(jù)；以及所述規(guī)范化形成模塊根據(jù)呈現(xiàn)單元的主體中的可比較設計數(shù)據(jù)的所述語法樹來產(chǎn)生 針對所述OASIS 設計語言和所述⑶SII設計語言的規(guī)范化形式。
29.一種制品，包括存儲程序代碼的計算機可讀存儲介質(zhì)，所述程序代碼適于運行在計算機上，并且用于 評估電路設計數(shù)據(jù)之間的相似性和/或差異性，所述設計數(shù)據(jù)駐留在存儲于計算機存儲器 中的至少兩個文件中，所述程序代碼包括解析器，其解析包含表示物理電路設計的方面的設計數(shù)據(jù)的文件，并且在所述存儲器 中創(chuàng)建一個或多個語法樹；與所述解析器協(xié)作的正則化器邏輯，其組織所述語法樹以產(chǎn)生規(guī)范化形式，其中所述 正則化器邏輯包括劃分模塊，其將所述文件劃分為至少一個頭部，并且根據(jù)用于編碼所述文件的設計語 言的規(guī)則將所述文件劃分為設計數(shù)據(jù)的多個單元，以及組織所述語法樹以表示所述頭部和 單元劃分；以及規(guī)范化形成模塊，其解釋所述語法樹以產(chǎn)生所述設計數(shù)據(jù)的規(guī)范化形式，其中所述規(guī) 范化形式降低了數(shù)據(jù)分析對所述設計數(shù)據(jù)中的非功能性改變的敏感性；概括器，其接收針對至少所選擇的劃分的規(guī)范化形式，并且針對每個所選擇的劃分計 算至少一個概要并將其存儲在所述存儲器中；比較器模塊，其接收并且比較包含設計數(shù)據(jù)的至少第一文件和第二文件的概要；以及 與所述概括器耦合的報告器模塊，其總結通過比較所述概要而檢測到的至少一些匹配 和/或差異性。
30.根據(jù)權利要求四所述的制品，其中所述規(guī)范化形成模塊解釋所述語法樹的分支的 可排序性，并且組織所述語法樹以反映可排序性。
31.根據(jù)權利要求四所述的制品，其中所述劃分模塊還按單元內(nèi)的層來劃分所述文 件，并且組織所述語法樹以反映所述層。
32.根據(jù)權利要求四所述的制品，其中所述劃分模塊還在功能上重要的設計數(shù)據(jù)與功 能上不重要的設計數(shù)據(jù)之間劃分所述文件，其中，當設計數(shù)據(jù)的改變將導致根據(jù)所述設計 數(shù)據(jù)生成的電路有所改變時，所述設計數(shù)據(jù)是功能上重要的；并且所述劃分模塊組織所述 語法樹以反映功能重要性。
33.根據(jù)權利要求32所述的制品，適于相對于老單元設計庫來評估新單元設計庫，其中所述第一文件是新單元設計庫，并且所述第二文件是老單元設計庫；以及 所述報告器模塊總結通過比較概要而檢測到的新庫中的功能上重要的改變。
34.根據(jù)權利要求四所述的制品，適于評估設計文件以確定所述設計文件中的單元是 否屬于已知不良單元設計的集，其中所述第一文件是設計文件，并且所述第二文件包含已知不良單元設計；以及 所述報告器模塊總結所述設計文件中具有如下概要的單元，所述概要與已知不良單元 設計的文件中的單元的概要相匹配。
35.根據(jù)權利要求34所述的制品，還適于評估所述設計文件中的單元是否屬于至少一 個經(jīng)批準的庫，其中所述比較器模塊還接收和比較第三文件的概要； 所述第三文件是至少一個經(jīng)批準的單元庫；以及所述報告器模塊還總結所述設計文件中具有如下概要的單元，所述概要與所述經(jīng)批準 的單元庫中的單元的概要不匹配。
36.根據(jù)權利要求四所述的制品，適于評估所述設計文件中的單元是否屬于至少一個 經(jīng)批準的庫，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的單元庫；以及 所述報告器模塊總結所述設計文件中具有如下概要的單元，所述概要與所述經(jīng)批準的 單元庫中的單元的概要不匹配。
37.根據(jù)權利要求四所述的制品，適于評估設計文件以確定所述設計文件中的單元是 否屬于至少一個經(jīng)批準的庫并且沒有過期，其中所述比較器模塊還接收和比較第三文件的概要；所述第一文件是設計文件，所述第二文件是至少一個單元設計的當前庫，并且所述第三文件是至少一個單元設計的過期庫；以及所述報告器模塊總結所述設計文件中具有如下概要的單元，所述概要與所述當前庫中 的單元設計的概要不匹配、并且與所述過期庫中的單元設計的概要相匹配。
38.根據(jù)權利要求37所述的制品，還適于檢測具有不同單元名稱的功能上相同的單 元，其中所述劃分模塊還按單元內(nèi)的層來劃分所述文件，并且組織所述語法樹以反映所述層； 所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫； 所述概括器計算設計文件和所述經(jīng)批準的庫中的單元的多個層中的至少功能上重要 的數(shù)據(jù)的概要，并且將其存儲在所述存儲器中；以及所述報告器模塊將所述設計文件中的如下單元報告為重命名單元，所述單元具有的所 述多個層中的功能上重要的數(shù)據(jù)的概要與所述經(jīng)批準的庫中的單元的概要相匹配(稱為 “功能上匹配的單元”)，但是重命名的單元具有的單元名稱與所述功能上匹配的單元的單 元名稱不匹配。
39.根據(jù)權利要求四所述的制品，適于評估設計文件以確定所述設計文件中擔保的單 元或者其他單元是否已被修改，其中所述第一文件是設計文件，并且所述第二文件是至少一個經(jīng)批準的庫； 所述概括器計算所述設計文件和所述經(jīng)批準的庫中的單元的多個層中的至少功能上 重要的數(shù)據(jù)的概要，并且將其存儲在所述存儲器中；以及所述報告器模塊將所述設計文件中具有如下概要的單元報告為潛在被修改的單元，所 述單元具有的所述多個層中的一些但非全部層中的功能上重要的數(shù)據(jù)的概要與所述經(jīng)批 準的庫中的單元的概要相匹配。
40.根據(jù)權利要求四所述的制品，適于掃描生產(chǎn)設計以找到使用費承擔單元設計，其中所述第一文件包括使用費承擔單元設計的一個或多個使用費承擔庫，并且所述第二文 件包括包含單元設計的一個或多個生產(chǎn)設計；以及所述報告器模塊將所述生產(chǎn)設計中具有如下概要的單元報告為潛在使用費承擔單元， 所述概要與所述使用費承擔庫中的單元的概要相匹配。
41.根據(jù)權利要求四所述的制品，適于比較不同設計數(shù)據(jù)語法的文件，所述不同設計 數(shù)據(jù)語法中的一個是OASIS 而另一個是⑶SII，其中所述第一文件包含以OASIS 設計語言表達的設計數(shù)據(jù)，并且所述第二文件包含以 ⑶SII設計語言表達的設計數(shù)據(jù)；以及所述規(guī)范化形成模塊根據(jù)呈現(xiàn)單元的主體中的可比較設計數(shù)據(jù)的所述語法樹來產(chǎn)生 針對所述OASIS 設計語言和所述⑶SII設計語言的規(guī)范化形式。
全文摘要
所公開的技術涉及用于為制造而準備芯片設計的設計數(shù)據(jù)的粒度分析，以及涉及標識設計數(shù)據(jù)文件的各部分之間的相似性和差異性。具體地，所公開的技術涉及解析數(shù)據(jù)并且將其組織到規(guī)范化形式中，概括規(guī)范化形式并且將來自不同源(諸如設計和設計模板庫)的設計數(shù)據(jù)的概要進行比較。將設計數(shù)據(jù)組織到規(guī)范化形式中通常會降低數(shù)據(jù)分析對于數(shù)據(jù)中對設計沒有功能性影響的改變的敏感性。粒度分析的細節(jié)在用于表示設計方面的設計語言以及數(shù)據(jù)文件格式之間有所不同。針對各種設計語言，粒度分析可以包括通過以下各項來劃分設計文件頭部/單元部分、注釋的單獨處理、功能上重要的/不重要的數(shù)據(jù)、空白/非空白以及設計數(shù)據(jù)單位內(nèi)的層。感興趣的相似性和差異性取決于粒度分析的目標。比較按照多種方式都是有用的。
文檔編號G06F19/00GK102112988SQ200980129771
公開日2011年6月29日 申請日期2009年6月10日 優(yōu)先權日2008年6月10日
發(fā)明者D·查普曼, T·格里賓斯基 申請人:綠洲模具公司