(57)【要約】  開示された技術は、製造用のチップデザインを準備するために使用されるデザインデータの粒状分析、デザインデータファイルの各部間の類似性及び差異の認識に関する。特には、データの構文解析及び正則形式への変換を行い、前記正則形式をダイジェスト化し、デザインテンプレートのデザイン及びライブラリ等の様々なソースからのデザインデータのダイジェストを比較することに関する。デザインデータを正則形式に変換することによって、一般的に、デザインに機能的な影響を及ぼさないデータのばらつきに対するデータ分析の感受性を低下させる。粒状分析の詳細は、デザインのアスペクトを表すために使われる設計言語によって異なる。設計言語によって、粒状分析には、ヘッダ／セル部分によって、コメントの個別処理によって、機能的に重要な／非重要なデータによって、空白／非空白によって、デザインデータユニット内のレイヤーによって、デザインファイルを区分することが含まれる。対象となる類似性及び差異は、粒状分析の目的によって決まる。比較は様々な面で有用である。【選択図】  図３
2011525276.tif 000002
【特許請求の範囲】
【請求項１】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、
コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、
前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、
前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、
前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、
前記ダイジェストの前記比較の結果の少なくとも幾つかをサマライズする工程と、を備えることを特徴とする方法。
【請求項２】
前記計算及び記憶の前に、前記正則形式において機能的に重要なデザインデータと重要でないデータとを区分する工程を更に備え、
前記機能的に重要なデザインデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータであり、
前記ダイジェストの計算に用いられる前記正則形式の前記選択されたデザインデータは、少なくとも前記機能的に重要なデザインデータを含むことを特徴とする請求項１に記載の方法。
【請求項３】
デザインデータの構文が異なるファイルの比較において、一方のファイルがＯＡＳＩＳファイルであり、他方のファイルがＧＤＳＩＩファイルである場合に適用される方法であって、
前記第１ファイルが、ＯＡＳＩＳ設計言語で表現されたデザインデータを含み、前記第２ファイルが、ＧＤＳＩＩ設計言語で表現されたデザインデータを含み、
前記ＯＡＳＩＳ設計言語及び前記ＧＤＳＩＩ設計言語に関する前記正則形式によって、前記セルのボディのデザインデータが比較可能となることを特徴とする請求項１に記載の方法。
【請求項４】
セルデザインの古いライブラリに対する、セルデザインの新しいライブラリの評価に適用される方法であって、
前記第１ファイルが、セルデザインの新しいライブラリであり、前記第２ファイルが、セルデザインの古いライブラリであり、
前記サマライズする工程は更に、少なくとも、前記ダイジェストの比較によって検出された前記新しいライブラリにおける前記機能的に重要な変更のレポートを含むことを特徴とする請求項２に記載の方法。
【請求項５】
デザインファイルのセルが少なくとも１つの承認済みライブラリに属しており、かつ、旧式でないかどうかを判断するための、前記デザインファイルの評価に適用される方法であって、前記方法は、
前記認識し、構文を解析し、及び、計算する工程が適用される第３ファイルを更に含み、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つのセルデザインのカレントライブラリであり、前記第３ファイルは少なくとも１つのセルデザインの旧式ライブラリであり、
前記サマライズする工程は更に、前記カレントライブラリのセルデザインのダイジェストに一致せず、かつ、前記旧式ライブラリのセルデザインのダイジェストに一致するダイジェストを有する前記デザインファイルのセルのレポートを含むことを特徴とする請求項１に記載の方法。
【請求項６】
デザインファイルのセルが、既知の不良セルデザインを収集したものに属するかどうかを判断するための、前記デザインファイルの評価に適用される方法であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは既知の不良セルデザインを含み、
前記サマライズする工程は更に、前記既知の不良セルデザインのファイルのセルのダイジェストに一致するダイジェストを有する前記デザインファイルのセルのレポートを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記デザインファイルの前記セルが、少なくとも１つの承認済みライブラリに属するかどうかの評価に更に適用される方法であって、前記方法は、
前記認識し、構文を解析し、及び、計算する工程が適用される第３ファイルを更に含み、
前記第３ファイルは、少なくとも１つのセルの承認済みライブラリであり、
前記サマライズする工程は更に、前記セルの承認済みライブラリのセルのダイジェストに一致しないダイジェストを有する前記デザインファイルのセルのレポートを含むことを特徴とする請求項６に記載の方法。
【請求項８】
デザインファイルのセルが、少なくとも１つの承認済みライブラリに属するかどうかを判断するための、前記デザインファイルの評価に適用される方法であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記サマライズする工程は更に、前記承認済みライブラリのセルのダイジェストに一致しないダイジェストを有する前記デザインファイルのセルのレポートを含むことを特徴とする請求項１に記載の方法。
【請求項９】
セル名が異なる機能的に同じセルの検出に適用される方法であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記ダイジェストの計算及び記憶工程は、少なくとも、前記デザインファイルのセルの複数のレイヤーにおける機能的に重要なデータ及び前記承認済みライブラリに適用され、
前記サマライズする工程は更に、前記承認済みライブラリのセル（「機能的に一致するセル」と称する）のダイジェストに一致する、前記複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、前記機能的に一致するセルとセル名が一致しない前記デザインファイルの前記セルを、名称変更されたセルとしてレポートすることを含むことを特徴とする請求項２に記載の方法。
【請求項１０】
デザインファイルの保証されたセル又はその他のセルが変更されたかどうかを判断するための、前記デザインファイルの評価に適用される方法であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記ダイジェストの計算及び記憶工程は、少なくとも、前記デザインファイルのセルの複数のレイヤーにおける機能的に重要なデータ及び前記承認済みライブラリに適用され、
前記サマライズする工程は更に、前記承認済みライブラリのセルのダイジェストに一致する前記複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを有する前記デザインファイルのセルを、変更された可能性のあるセルとしてレポートすることを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
有償のセルデザインを見つけるための、製品設計の検査に適用される方法であって、
前記第１ファイルは、有償セルデザインの１又は複数の有償ライブラリを含み、第２ファイルは、セルデザインを含む１又は複数の製品設計を含み、
前記サマライズする工程は更に、前記有償ライブラリのセルのダイジェストに一致するダイジェストを有する製品設計におけるセルを、有償セルである可能性のあるセルとしてレポートすることを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記デザインデータの前記構文解析は更に、セル内の前記デザインデータを区分する１又は複数の構文木を生成する工程を含み、前記デザインデータは、少なくとも、
前記デザインデータが投入されるフォーマットに従って、ヘッダデータとボディデータ間、及び、
機能的に重要なデータと重要でないデータ間、
とで分割され、
前記機能的に重要なデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータの部分であり、
前記ダイジェストの計算及び記憶工程は、更に、１セル１区分当たり、少なくとも１つのダイジェストを生成する工程を含み、
前記サマライズする工程で、異なる区分タイプから生成された前記ダイジェストを区別することを特徴とする請求項１に記載の方法。
【請求項１３】
前記構文木が、更に、セル内の前記デザインデータを、デザインレイヤーに区分することを特徴とする請求項１２に記載の方法。
【請求項１４】
順序非依存が、ノードで表されるデザインデータから生成される回路を変更することなく、前記ノードが様々な順序で処理可能であることを意味する場合に、順序非依存の前記デザインデータを表す前記ノードを含む前記構文木の枝を認識する工程と、
前記認識された枝のノードをソートする工程と、を含む方法であって、
前記ダイジェストの計算及び記憶が、前記ソートされたノードに適用されることを特徴とする請求項１２に記載の方法。
【請求項１５】
回路のデザインデータ間の類似性及び差異、或いはその何れかに関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、
コンピュータを用いて、物理的回路のデザインに関するヘッダデータ及び／又はセルデータ（これらのデータをまとめて「デザインユニット」と称する）を含む、第１及び第２ファイルにあるデザインデータの構文解析を行う工程と、
前記デザインユニット内の前記デザインデータを、前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、標準化する工程と、
前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、デザインユニット毎に少なくとも１つのダイジェストを生成する工程と、
前記第１ファイルの前記デザインユニットの前記ダイジェストと、前記第２ファイルの前記デザインユニットの前記ダイジェストとを比較する工程と、
前記ダイジェストの前記比較の結果の少なくとも幾つかをサマライズする工程と、を備えることを特徴とする方法。
【請求項１６】
回路のデザインデータ間の類似性及び／又は差異を評価する装置であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記装置は、
少なくとも１つのプロセッサ及びメモリと、
前記プロセッサ上で実行され、物理的回路用のデザインのアスペクトを表すデザインデータを含むファイルを構文解析し、前記メモリに１又は複数の構文木を生成する構文解析ツールと、
前記プロセッサ上で実行され、前記構文木を構築する前記構文解析ツールと連携して、正則形式を生成する標準化ロジックと、を含み、前記標準化ロジックは、
前記ファイルを、少なくとも１つのヘッダと、前記ファイルを符号化するために使用される設計言語の規則に従って、デザインデータの複数のセルに区分し、前記ヘッダ及びセルの区分を表す前記構文木を構築する区分モジュールと、
前記構文木を解釈して、前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式を、前記デザインデータについて生成する正則形式生成モジュール、とを含み、
前記プロセッサ上で実行され、少なくとも選択された区分に関する前記正則形式を受け取り、選択された区分につき少なくとも１つのダイジェストを計算し、前記メモリに記憶するダイジェスタモジュールと、
前記プロセッサ上で実行され、デザインデータを含む少なくとも第１ファイル及び第２ファイルのダイジェストを受け取って比較する比較モジュールと、
前記プロセッサ上で実行され、前記ダイジェストの比較によって検出された前記一致及び／又は差異の少なくとも幾つかをサマライズする前記ダイジェスタに連結するレポータモジュールと、を備えることを特徴とする装置。
【請求項１７】
前記正則形式生成モジュールは、前記構文木の枝のソート可能性を解釈し、ソート可能性を反映する前記構文木を構築することを特徴とする請求項１６に記載の装置。
【請求項１８】
前記区分モジュールは、更に、前記ファイルを、セル内のレイヤーによって区分し、前記レイヤーを反映する前記構文木を構築することを特徴とする請求項１６に記載の装置。
【請求項１９】
前記区分モジュールは、更に、前記ファイルを、機能的に重要なデザインデータと重要でないデザインデータとに区分して、機能的重要性を反映する前記構文木を構築し、
前記機能的に重要なデザインデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータであることを特徴とする請求項１６に記載の装置。
【請求項２０】
セルデザインの古いライブラリに対して、セルデザインの新しいライブラリを評価するように構成された装置であって、
前記第１ファイルはセルデザインの新しいライブラリであり、前記第２ファイルはセルデザインの古いライブラリであり、
前記レポータモジュールは、前記ダイジェストを比較することによって検出された前記新しいライブラリにおける前記機能的に重要な変更をサマライズすることを特徴とする請求項１９に記載の装置。
【請求項２１】
デザインファイルのセルが既知の不良セルデザインを収集したものに属するかどうかを判断するために、前記デザインファイルを評価するように構成された装置であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは既知の不良セルデザインを含み、
前記レポータモジュールは、既知の不良セルデザインの前記ファイルのセルのダイジェストと一致するダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項１６に記載の装置。
【請求項２２】
前記デザインファイルの前記セルが少なくとも１つの承認済みライブラリに属するかどうかを評価するように構成された装置であって、
前記比較モジュールは、更に、第３ファイルのダイジェストを受け取って比較し、
前記第３ファイルは、少なくとも１つの、セルの承認済みライブラリであり、
前記レポータモジュールは、前記セルの承認済みライブラリのセルのダイジェストと一致しないダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項２１に記載の装置。
【請求項２３】
前記デザインファイルの前記セルが少なくとも１つの承認済みライブラリに属するかどうかを評価するように構成された装置であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの、セルの承認済みライブラリであり、
前記レポータモジュールは、前記セルの承認済みライブラリのセルのダイジェストと一致しないダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項１６に記載の装置。
【請求項２４】
デザインファイルのセルが、少なくとも１つの承認済みライブラリに属しており、かつ、旧式でないかどうかを判断するために前記デザインファイルを評価するように構成された装置であって、
前記比較モジュールは、更に、第３ファイルのダイジェストを受け取って比較し、
前記第１ファイルはデザインファイルであり、前記第２ファイルは、少なくとも１つの、セルデザインのカレントライブラリであり、前記第３ファイルは、少なくとも１つの、セルデザインの旧式のライブラリであり、
前記レポータモジュールは、前記カレントライブラリのセルデザインのダイジェストに一致せず、かつ、前記旧式のライブラリのセルデザインのダイジェストに一致するダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項１６に記載の装置。
【請求項２５】
名称は異なるが機能的に同じであるセルを検出するように構成された装置であって、
前記区分モジュールは、更に、セル内のレイヤーで前記ファイルを区分し、前記レイヤーを反映する前記構文木を構築し、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記ダイジェスタは、少なくとも、前記デザインファイルのセルの複数のレイヤーにおける機能的に重要なデータと前記承認済みライブラリのダイジェストを計算して前記メモリに記憶し、
前記レポータモジュールは、前記承認済みライブラリのセル（「機能的に一致するセル」と称する）のダイジェストに一致する、前記複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、前記機能的に一致するセルとセル名が一致しない前記デザインファイルの前記セルを、名称変更されたセルとしてサマライズすることを特徴とする請求項１９に記載の装置。
【請求項２６】
デザインファイルの保証されたセル又はその他のセルが変更されたかどうかを判断するために、前記デザインファイルを評価するように構成された装置であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記ダイジェスタは、少なくとも、前記デザインファイルのセルの複数のレイヤーにおける機能的に重要なデータと前記承認済みライブラリのダイジェストを計算して前記メモリに記憶し、
前記レポータモジュールは、前記承認済みライブラリのセルのダイジェストに一致する前記複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを有する前記デザインファイルのセルを、変更された可能性のあるセルとしてサマライズすることを特徴とする請求項１６に記載の装置。
【請求項２７】
有償のセルデザインを見つけるために、製品設計を検査するように構成された装置であって、
前記第１ファイルは、有償セルデザインの１又は複数の有償ライブラリを含み、第２ファイルは、セルデザインを含む１又は複数の製品設計を含み、
前記レポータモジュールは、前記有償ライブラリのセルのダイジェストに一致するダイジェストを有する製品設計におけるセルを、有償セルである可能性のあるセルとしてサマライズすることを特徴とする請求項１６に記載の装置。
【請求項２８】
一方のファイルがＯＡＳＩＳファイルであり、他方のファイルがＧＤＳＩＩファイルである場合に、デザインデータの構文が異なるファイルを比較するように構成された装置であって、
前記第１ファイルが、ＯＡＳＩＳ設計言語で表現されたデザインデータを含み、前記第２ファイルが、ＧＤＳＩＩ設計言語で表現されたデザインデータを含み、
前記正則形式生成モジュールが、前記構文木から、前記ＯＡＳＩＳ設計言語及び前記ＧＤＳＩＩ設計言語に関して、前記セルのボディ内に比較可能なデザインデータを提供する前記正則形式を生成することを特徴とする請求項１６に記載の装置。
【請求項２９】
コンピュータ上で実行され、コンピュータメモリに記憶された少なくとも２つのファイルに存在する回路用のデザインデータの類似性及び／又は差異を評価するように構成されたプログラムコードを記憶するコンピュータ可読記憶媒体を備える製造物品であって、
前記プログラムコードは、
物理的回路用のデザインのアスペクトを表すデザインデータを含むファイルの構文解析を行い、前記メモリに１又は複数の構文木を生成する構文解析ツールと、
前記構文木を構築する前記構文解析ツールと連携して、正則形式を生成する標準化ロジックと、を備え、前記標準化ロジックは、
前記ファイルを、少なくとも１つのヘッダと、前記ファイルを符号化するために使用される設計言語の規則に従って、デザインデータの複数のセルに区分し、前記ヘッダ及びセルの区分を表す前記構文木を構築する区分モジュールと、
前記構文木を解釈して、前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式を、前記デザインデータについて生成する正則形式生成モジュール、とを含み、
少なくとも選択された区分に関する前記正則形式を受け取り、選択された区分につき少なくとも１つのダイジェストを計算し、前記メモリに記憶するダイジェスタと、
デザインデータを含む少なくとも第１ファイル及び第２ファイルの前記ダイジェストを受け取って比較する比較モジュールと、
前記ダイジェストの比較によって検出された前記一致及び／又は差異の少なくとも幾つかをサマライズする前記ダイジェスタに連結するレポータモジュールと、を備えることを特徴とする製造物品。
【請求項３０】
前記正則形式生成モジュールは、前記構文木の枝のソート可能性を解釈し、ソート可能性を反映する前記構文木を構築することを特徴とする請求項２９に記載の製造物品。
【請求項３１】
前記区分モジュールは、更に、前記ファイルを、セル内のレイヤーによって区分し、前記レイヤーを反映する前記構文木を構築することを特徴とする請求項２９に記載の製造物品。
【請求項３２】
前記区分モジュールは、更に、前記ファイルを、機能的に重要なデザインデータと重要でないデザインデータとに区分して、機能的重要性を反映する前記構文木を構築し、
前記機能的に重要なデザインデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータであることを特徴とする請求項２９に記載の製造物品。
【請求項３３】
セルデザインの古いライブラリに対して、セルデザインの新しいライブラリを評価するように構成された製造物品であって、
前記第１ファイルはセルデザインの新しいライブラリであり、前記第２ファイルはセルデザインの古いライブラリであり、
前記レポータモジュールは、前記ダイジェストを比較することによって検出された前記新しいライブラリにおける前記機能的に重要な変更をサマライズすることを特徴とする請求項３２に記載の製造物品。
【請求項３４】
デザインファイルのセルが既知の不良セルデザインを収集したものに属するかどうかを判断するために、前記デザインファイルを評価するように構成された製造物品であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは既知の不良セルデザインを含み、
前記レポータモジュールは、既知の不良セルデザインの前記ファイルのセルのダイジェストと一致するダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項２９に記載の製造物品。
【請求項３５】
前記デザインファイルの前記セルが少なくとも１つの承認済みライブラリに属するかどうかを評価するように構成された製造物品であって、
前記比較モジュールは、更に、第３ファイルのダイジェストを受け取って比較し、
前記第３ファイルは、少なくとも１つの、セルの承認済みライブラリであり、
前記レポータモジュールは、更に、前記セルの承認済みライブラリのセルのダイジェストと一致しないダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項３４に記載の製造物品。
【請求項３６】
前記デザインファイルの前記セルが少なくとも１つの承認済みライブラリに属するかどうかを評価するように構成された製造物品であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの、セルの承認済みライブラリであり、
前記レポータモジュールは、前記セルの承認済みライブラリのセルのダイジェストと一致しないダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項２９に記載の製造物品。
【請求項３７】
デザインファイルのセルが、少なくとも１つの承認済みライブラリに属しており、かつ、旧式でないかどうかを判断するために前記デザインファイルを評価するように構成された製造物品であって、
前記比較モジュールは、更に、第３ファイルのダイジェストを受け取って比較し、
前記第１ファイルはデザインファイルであり、前記第２ファイルは、少なくとも１つの、セルデザインのカレントライブラリであり、前記第３ファイルは、少なくとも１つの、セルデザインの旧式のライブラリであり、
前記レポータモジュールは、前記カレントライブラリのセルデザインのダイジェストに一致せず、かつ、前記旧式のライブラリのセルデザインのダイジェストに一致するダイジェストを有する前記デザインファイルのセルをサマライズすることを特徴とする請求項２９に記載の製造物品。
【請求項３８】
名称は異なるが機能的に同じであるセルを検出するように構成された製造物品であって、
前記区分モジュールは、更に、セル内のレイヤーによって前記ファイルを区分し、前記レイヤーを反映する前記構文木を構築し、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記ダイジェスタは、少なくとも、前記デザインファイルのセルの複数のレイヤーにおける機能的に重要なデータと前記承認済みライブラリのダイジェストを計算して前記メモリに記憶し、
前記レポータモジュールは、前記承認済みライブラリのセル（「機能的に一致するセル」と称する）のダイジェストに一致する、前記複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、前記機能的に一致するセルとセル名が一致しない前記デザインファイルの前記セルを、名称変更されたセルとしてサマライズすることを特徴とする請求項３７に記載の製造物品。
【請求項３９】
デザインファイルの保証されたセル又はその他のセルが変更されたかどうかを判断するために、前記デザインファイルを評価するように構成された製造物品であって、
前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、
前記ダイジェスタは、少なくとも、前記デザインファイルのセルの複数のレイヤーにおける機能的に重要なデータ及び前記承認済みライブラリのダイジェストを計算して前記メモリに記憶し、
前記レポータモジュールは、前記承認済みライブラリのセルのダイジェストに一致する前記複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを有する前記デザインファイルのセルを、変更された可能性のあるセルとしてサマライズすることを特徴とする請求項２９に記載の製造物品。
【請求項４０】
有償のセルデザインを見つけるために、製品設計を検査するように構成された製造物品であって、
前記第１ファイルは、有償セルデザインの１又は複数の有償ライブラリを含み、第２ファイルは、セルデザインを含む１又は複数の製品設計を含み、
前記レポータモジュールは、前記有償ライブラリのセルのダイジェストに一致するダイジェストを有する製品設計におけるセルを、有償セルである可能性のあるセルとしてサマライズすることを特徴とする請求項２９に記載の製造物品。
【請求項４１】
一方のファイルがＯＡＳＩＳファイルであり、他方のファイルがＧＤＳＩＩファイルである場合に、デザインデータの構文が異なるファイルを比較するように構成された製造物品であって、
前記第１ファイルが、ＯＡＳＩＳ設計言語で表現されたデザインデータを含み、前記第２ファイルが、ＧＤＳＩＩ設計言語で表現されたデザインデータを含み、
前記正則形式生成モジュールが、前記構文木から、前記ＯＡＳＩＳ設計言語及び前記ＧＤＳＩＩ設計言語に関して、前記セルのボディ内に比較可能なデザインデータを提供する前記正則形式を生成することを特徴とする請求項２９に記載の製造物品。
【発明の詳細な説明】
【関連出願】
【０００１】
本出願は、提出された米国特許仮出願６１／１３１，６０１、及び、米国特許仮出願６１／１８０，７１５の利益を請求する。優先権主張の基礎となる出願は、参照することにより組み込まれる。
【背景技術】
【０００２】
本開示の技術は、製造に向けてチップデザインを準備するため、及び、デザインデータファイルの部分間の類似性と差異を認識するために用いられる、デザインデータの粒状分析（ｇｒａｎｕｌａｒ  ａｎａｌｙｓｉｓ）に関する。特に、データの構文を解析すること、解析後のデータを正則形式（ｃａｎｏｎｉｃａｌ  ｆｏｒｍｓ）にすること、正則形式をダイジェストすること、チップレベルのデザイン、デザインテンプレートライブラリ等の様々なソースからのデザインデータのダイジェストを比較することに関する。一般的に、デザインデータを正則形式にすることで、デザインに機能的影響を及ぼさないデータのばらつきに対する、データ分析の感受性が低下する。粒状分析の詳細は、デザインのアスペクト（ａｓｐｅｃｔｓ）を表すために用いられる設計言語やデータファイルフォーマットによって異なる。所望する分析及び設計言語に従って、粒状分析には、ヘッダ／セル部分、コメントの個別処理、機能的に意味のある／意味のないデータ、空白／非空白、デザインデータユニット内のレイヤーによって、デザインファイルを区分し、レポートすることが含まれる。対象となる類似性及び差異は、粒状分析の目的によって決まる。比較は多くの方法において有用である。
【０００３】
集積回路の設計は、何十万のセル及びブロックビュー、アーティファクト（ａｒｔｉｆａｃｔｓ）、それらが従属するものに関する繰り返し処理である。ビュー、アーティファクト、それらの従属物は、集積回路の開発中の機能的、電気的、物理的状態を表している。
【０００４】
セル及びブロックは、内部的なセルレベルの開発、及び、デザインテンプレートベンダーからのリリースに始まり、複数のリリース又は繰り返しが周期的に繰り返される設計工程を様々な速さでたどる。ブロック、ライブラリ、セル、アーティファクトの最新のバージョンの追跡し続けることは難しい。例えば、特別なデザインテンプレートを使う製品において歩留まりの問題が発見された場合、企業にとっては、他のどのプロジェクトでそのデザインテンプレートを使用するかを決定することが難しくなる。
【０００５】
古いセル又はライブラリが使われる可能性は何処にでもある。デザインツールには独自の構成ファイルがあり、マシンには独自の検索経路とディスクの実装点がある。設計或いはテープアウトのチームは、製造から問題のあるデザインが返ってくるまで、旧式（ｏｕｔ−ｏｆ−ｄａｔｅ）のファイル又はリンクを見つけられないことも考えられる。
【０００６】
複数のレベルからなる複雑なデザインは新たな問題を生む。設計チームがとりあえずは完成させた凍結ブロックは、旧バージョンのライブラリセルを使っている可能性がある。更に、設計者は、２つのセルが等しいかどうか確かめずに、セルの名称を変えるだけで、他の設計者のセルと名称がぶつからないようにするかも知れない。セルの名称を変えることは、将来のライブラリの更新やセルの追跡のメカニズムからその変更後の名称を分離させることになる。
【０００７】
設計者が、ベンダーによって提供されたデザインテンプレートに無認可の変更を行って、製造中に故障が生じた場合、デザインテンプレートのベンダーから受けられるはずだった保証を受けられなくなる。設計者は、変更によってテンプレートの性能や機能性を高められると考えるかも知れないが、結局は、生産段階における故障といった反対の結果を生むだけである。また、サードパーティのベンダーは、自社のデザインテンプレートに対する変更を保証しない。このように何かが起こった場合、原因の判定と誰に責任があるのかを認識することが難しくなる。
【０００８】
デザインがすぐに製造へリリースできる状態にある時点で、４０，０００ものユニークなセルが存在する。今日のように複雑なデザインとなると、デザインを準備するのに使用されるライブラリセルは最新ではないことがますます多くなってくる。テープアウトのチームは、今まさにフォトマスクの製造所に送られようとしているデザインのセルが、最新の利用可能なバージョンであるかどうか、確信を持って判断することができない。テープアウトの対象が確実にすべての最新データを使っていること、認証されたレイアウトに無認可の変更を加えていないことを確実にする方法は、今のところ存在しない。
【０００９】
集積回路の設計の間にセルデータを追跡する公知の方法は、セルの収集物を含むデータファイルを追跡することである。ファイル内でセルの変更を見つけるために、設計者は、通常は差分ツールを用いて、何百万もの行のデータを手動で分析する。差分チェックの実行は、複数の設計言語又はデータファイルフォーマットに対しては有効ではない。なぜなら、差分ツールは、通常、設計言語又はデザインを表すのに用いられるデータ型を考慮しない、テキストのマッチングを行うからである。差分プログラムは、通常、変更が製造中のチップに機能的影響を及ぼすかどうか、或いは、変更が重要であるかを分析することなく、ファイル同士の差分を求める。差分ツールは、特に、２つの対象ファイルがバイナリデータファイルである場合、処理が困難である。
【００１０】
差分ツールを含むと思われるデザインツールの例としては、ＣｌｅａｒＣａｓｅ、ＤｅｓｉｇｎＳｙｎｃ、ＩＣ  Ｍａｎａｇｅが挙げられる（ｈｔｔｐ：／／ｗｗｗ−０１．ｉｂｍ．ｃｏｍ／ｓｏｆｔｗａｒｅ／ｒａｔｉｏｎａｌ／、ｈｔｔｐ：／／ｗｗｗ．ｉｃｍａｎａｇｅ．ｃｏｍ、ｈｔｔｐ：／／ｗｗｗ．３ｄｓ．ｃｏｍに各販売者によって記載されている）。こうしたツールはセルレベルではなくファイルレベルで動作するため、差分ツールを用いる場合、設計者は、特に、比較対象の２セクションのコードを新しいファイルに抽出し、ファイル同士を直接比較する必要がある。或いは、設計者は、他の設計者が設計努力の方向について記録したファイルのメタデータに頼るかも知れない。しかし、これらの方法はいずれも堅牢ではなく、有効ではない。
【００１１】
デザインテンプレートの供給者の中には、テンプレートにタグを付ける者もある。タグによって、集積回路デザインの一部となる、自社製品ではない他のデザインテンプレートに対して、自社のテンプレートを認識することができる。タグは、デザインに使われるデザインテンプレートのインスタンスをカウントするのに使用され、テンプレートのユーザは、インスタンス数に基づいて使用料を支払う。このタグを付ける方法（ｔａｇｇｉｎｇ：タギング）の使用に関する産業標準規格は、ＶＳＩ  ＡｌｌｉａｎｃｅＴＭによって維持されている。ｈｔｔｐ：／／ｗｗｗ．ｖｓｉ．ｏｒｇ／ｄｏｃｓ／ＩＰＰ＿Ｔａｇｇｉｎｇ＿Ｓｔｄ％２０１＿３０．ｐｄｆで２００９年５月２１日にアクセスした「Ｖｉｒｔｕａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｐｈｙｓｉｃａｌ  Ｔａｇｇｉｎｇ  Ｓｔａｎｄａｒｄ」と題する標準規格のバーション２．０に、タギングの使用方法が書かれている。この標準規格は、ＧＤＳＩＩテキストやコメント行に埋め込まれるテキストタグについて定められている。ＶＳＩ  Ａｌｌｉａｎｃｅには、ＩＢＭ、Ｉｎｔｅｌ、ＡＲＭ、Ｆｒｅｅｓｃａｌｅ  Ｓｅｍｉｃｏｎｄｕｃｔｏｒ、ＴＳＭＣ等が参加している。サードパーティのＩＰ供給者は、タグがデザインテンプレートデータの一部である場合にデザインテンプレートを検出し、報告することが可能なスキャナーを開発した。ただし、タグが何らかの方法で除去されたり、読むのが困難となった場合、デザインテンプレートの所有者は、使用料の面で補償されることはない。
【００１２】
設計ワークフローにおいて、様々な接合点でのデザインデータの粒状分析を容易にするデザインデータ分析の為の新しいツールを開発する機会が与えられた。この新しいツールによって、より良い、よりエラーのない、回復力のある、透過的なワークフローと、製品デザインを得ることができる。
【発明の概要】
【００１３】
本開示の技術は、製造に向けてチップデザインを準備するため、及び、デザインデータファイルの部分間の類似性と差異を認識するために用いられるデザインデータの粒状分析に関する。特に、データの構文を解析すること、解析後のデータを正則形式にすること、正則形式をダイジェストすること、チップレベルのデザイン、デザインテンプレートライブラリ等の様々なソースからのデザインデータのダイジェストを比較することに関する。一般的に、デザインデータを正則形式にすることで、デザインに機能的影響を及ぼさないデータのばらつきに対する、データ分析の感受性が低下する。粒状分析の詳細は、デザインのアスペクトを表すのに用いられる設計言語によって異なる。所望する分析及び設計言語に従って、粒状分析には、ヘッダ／セル部分、コメントの個別処理、機能的に意味のある／意味のないデータ、空白／非空白、デザインデータユニット内のレイヤーによって、デザインファイルを区分することが含まれる。対象となる類似性及び差異は、粒状分析の目的によって決まる。比較は多くの方法において有用である。本発明の特定の態様は、特許請求の範囲、明細書、図面において記述される。
【図面の簡単な説明】
【００１４】
【図１】高レベルにおける、集積回路設計の環境を示す図である。
【図２】図１のブロックに関連するファイルフォーマットのバーションの増殖とファイルフォーマットの幾つかを示す図である。
【図３】本開示の技術が有効に適用可能な設計工程における接合点を示す図である。
【図４】複数のデータファイルの各部の正則表現をダイジェスト化する評価装置（ｅｖａｌｕａｔｏｒ）を示す図である。
【図５】正則セルダイジェスト又はデザインユニットダイジェストが、デザインデータを含むファイルを処理することによって生成されることを示す図である。
【図６−７】これらの方法の幾つかの態様の高レベルのフローチャートを示す図である。
【図８（ａ）−（ｂ）】Ｌｉｂｅｒｔｙファイル内の考えられるヘッダとセルステートメントのサンプリングを示している。
【図８（ｃ）】Ｌｉｂｅｒｔｙファイル内の考えられるヘッダとセルステートメントのサンプリングを示している。
【図８（ｄ）】Ｌｉｂｅｒｔｙファイル内の考えられるヘッダとセルステートメントのサンプリングを示している。
【図９】注釈付のＶｅｒｉｌｏｇファイルの一例を示す図である。
【図１０（ａ）】注釈付のサンプルＶＨＤＬファイルを示す図である。
【図１０（ｂ）】注釈付のサンプルＶＨＤＬファイルを示す図である。
【図１１】注釈付のサンプルＯＡＳＩＳファイルを示す図である。
【図１２】注釈付のサンプルＧＤＳＩＩファイルを示す図である。
【図１３】ＳＰＩＣＥファイルの注釈付のバージョンを示す図である。
【図１４】注釈付のサンプルＬＥＦを示す図である。
【図１５】ＤＥＦの注釈付のバージョンを示す図である。
【図１６】構造化テキストファイルの注釈付のバージョンを示す図である。
【図１７（ａ）】ユーザが構文解析したファイルの注釈付の例を示す図である。
【図１７（ｂ）】ユーザが構文解析したファイルの注釈付の例を示す図である。
【発明を実施するための形態】
【００１５】
図面を参照して以下に詳細な説明を行う。好ましい実施形態は、本発明を示すために記載されるものであって本発明の範囲を限定するものではなく、特許請求の範囲によって定義される。当業者は、以下に述べる説明について様々な同等の変形を認めると思われる。
【００１６】
＜＜概観＞＞
＜集積回路設計の環境＞
回路設計の環境は、上記の背景の項で述べた内容よりも、更に改善の余地がある分野である。集積回路（ＩＣ）のテープアウトを成功させるには、ＩＣデザインのセル及びブロックが正しくなければならない。誤ったバージョンの回路を用いると、数個のトランジスタを備えたリーフセルであろうと、大きな階層デザインのブロックであろうと、何百万ドルもの費用と、何ヶ月にも及ぶ遅延が発生する。
【００１７】
論理合成後のチップレベルのデザイン管理システムは、セル、セルのバージョン、ブロック、チップレベルのデザインブロックからなるデザインデータのファイルベースの収集物（ｃｏｌｌｅｃｔｉｏｎｓ）を追跡する。デザインデータ管理システムは、ファイル内に見られるセルデータ及びブロックデータの所定の収集物内で行われた変更を効果的に判定、或いは、サマライズ（ｓｕｍｍａｒｉｚｅ：要約）することはできないと思われる。また、チップレベルのデザインデータ管理システムは、このレベルの粒度で追跡することはできない。なぜなら、セル、ブロック、チップレベルのデザインブロックは、種類の異なる、様々なバーションのデザインツールによって生成され、様々な設計言語及びデータファイルフォーマットを用いて表される。複雑なＳＯＣデザインにおいては、デザインブロックは、様々な種類のバージョンの異なるツールを用いて、様々なデザイングループから生成される。現在のデザイン管理ツールに欠陥が見られると、セルレベルでのセルの同等性の評価、或いは、個々のセル内で何が変化したかをレポートすることができなくなる。
【００１８】
現在のデザインデータ管理ツールは、テキストデータとオブジェクトデータとを区別せず、データをソートすることもデザインデータの正則表現を生成することもないように思われる。また、現在のデザインデータ管理ツールには、ＩＣデザインのセルが最新の承認されたバージョンであることを検証すること、セルが不適切にコピー又はインポートされていないことを確実にすること、提案されたセルデザインの更新がテープアウトに近づいたデザインで利用可能であるかどうかを判断すること等に関心のあるプロジェクト管理者にとって有用と思われる監査機能がない。
【００１９】
また、デザインデータ管理システムは、マスクショップにリリースされる最終的なＧＤＳＩＩ又はＯＡＳＩＳファイルを認証する方法を提供しない。デザインデータ管理システムでは、徹底的な制御があれば、最終のデザインに「逸脱した」レイアウトが入り込むことはないと考えられている。
【００２０】
［デザインユニットとしてのセルとブロック］
チップデザインではセルが多用され、それらのセルは、ブロックにグループ分けされる。セルは、しばしばセル「ビュー」と呼ばれる一連のデータファイルに関連付けられる。セルビューには、セルの機能的表現、或いは、物理的表現が含まれる。通常、ＳＰＩＣＥ、Ｅｘｔｒａｃｔｅｄ  Ｎｅｔｌｉｓｔ、ＧＤＳＩＩ、Ｌｉｂｅｒｔｙ、Ｖｉｔａｌ、ＬＥＦといった、設計言語でデザインデータを表した２以上のセルのビューが存在する。ビューによって、セルについて規定される情報のタイプは様々である。また、ＥＤＡツールにも様々なものがあり、ＥＤＡツールが動作するビュー、及び、それに含まれるデータもＥＤＡツールによって異なる。詳細なポリゴン（ｐｏｌｙｇｏｎ：多角形）データを操作するツールがある一方で、簡略化されたポリゴン表現のみ扱うものもある。性能評価ツールはポリゴンを全く扱わず、タイミング情報を用いる。様々なツールに使用されるセルのビューのバージョンに一貫性がない場合、当該セルを用いるデザインが機能しないという実質的なリスクが存在する。
【００２１】
チップレベルのデザインブロックには、複数のセルからなるセルブロックが複数含まれる。セルブロックには、セル及び他のセルを含むサブブロック等に対する参照が含まれる。参照はネスト（ｎｅｓｔ：入れ子）させることが可能である。セルに対する参照は、チップが製造される時に最終的に展開される。設計工程の間、参照を利用することによって、デザインを表すために必要なメモリ量及びディスクスペース量を大きく減らすことができる。例えば、チップ上のメモリ領域には、１又は複数のコアビットセルと、ビットセルの読み出し及び書き込みを行う行セル及び列セルと、コアビットセル、行セル、列セルを参照する最上位のセルの定義が含まれる。６５５３６ビットメモリ（「６４Ｋビットメモリ」）は、通常、６５５３６回参照される１ビットセルの定義、２５６回参照される２つの列ドライバ又はセンスセルの定義（上下）、２５６回参照される２つの行ドライバ又はセンスセルの定義、及び、関連するデコード回路を有する。階層的デザインは更に参照の回数を減らすことができる。メモリの行は左右の行セルへの参照に加えて、コアビットセルへ２５６回の参照を含むように定義することが可能であり、当該行は２５６回参照が可能である。６５５３６回のセル参照の代わりに、１０００未満のネストされた参照を使うことが可能である。
【００２２】
マスク（チップ上にセルを製造するためのツール）が作られた時、又は、直接書き込みが使用された時、セルの参照が展開される。上記の多くの例において、如何にセルの階層が規定されても、ウェハにプリントされ、１つのオリジナルセルからコピーされたコアビットセルは６５５３６個存在する。展開前のデザインデータファイルのサイズは数十ギガバイトあり、展開後はその何倍にも大きくなる。マスクデータを準備するソフトウェアワークステーションと、場合によっては、チップデザインにおいてデザインのルールが破られているかをチェックするルールチェックシステムを含む、完全に展開されたデータを処理する必要があるのは、極僅かなツールのみである。
【００２３】
ビューの中には、単一のファイル内に複数の「セル」を備えるファイルフォーマットを使うものもある。これにより、別の側面で複雑さが増す。こうしたフォーマットにおけるファイルのバージョンは、ファイル内部のすべてのセルのバージョンに依存する。
【００２４】
プロセッサコア等の複雑なデザインテンプレートは大抵、多くの関連するアーティファクトを有する。通常、アーティファクトは別々のファイルに記憶されている。このファイルとは、論理合成のための性能制約ファイル、シミュレーションのための動作記述ファイル、或いは、複数のセルで構成されるツールからのログファイルである。これらのファイルはすべて、セルの広範なレイアウト、及び、タイミングビューと同期すると考えられている。
【００２５】
もっと微妙なところでは、セルのビューの中には、セルの表現、或いは、物理的なレイアウト（例えばレイアウト）が変更されなかった時でさえも、変更できるものがある。例えば、ファウンドリ（ＩＣ生産工場）での製造工程に変更が行われた場合、或いは、単に、ファウンドリからの製品の平均的な性能についてより多くの情報が利用可能になったという理由で、タイミングモデルが変わることがある。
【００２６】
＜正則セルダイジェスト（ＣＣＤ）及び正則デザインユニットダイジェスト（ＣＤＵＤ）がどのように機能するか＞
正則セルダイジェスト、及び、より一般的には、正則デザインユニットダイジェストは、ＩＣ設計工程において有用な新しいツールから出力される。本出願で開示されている正則ダイジェストツールは、共通ＥＤＡファイルフォーマットに関して、ファイル全体、セル毎、レイヤー毎の各ダイジェストを生成し、他のファイルフォーマットに拡張することができる。これらのツールは、空白やコメントの変更といった軽微な変更と、セルに対する新しいインターフェースといった大きな変更とを区別することができる。これにより、バージョン管理されたセルダイジェストのリポジトリ（ｒｅｐｏｓｉｔｏｒｙ）に対するセルのマッチングによって、テストされていないセル及び旧式のセルの非認証の使用、セルへの変更、或いは、セルの名称が異なるコピーを検出することができる。高レベルにおいて、図４は、複数のデータファイル４１１、４３１、４５１の各部の４１５、４３５、４５５の正則表現をダイジェストする評価装置４３３を示している。２つ以上のファイルを表すダイジェストが比較される。データの２つのファイルが１つのデータベースに記憶されるかも知れないため、この文脈では、特許手続上、用語「ファイル」を総称的に用いる。デザイン産業において、デザインファイルは、通常、Ｗｉｎｄｏｗｓ（登録商標）又はＬｉｎｕｘファイルシステム等のファイル階層に記憶される。評価装置４３３は、ダイジェストを比較し、特定の目的のために対象となるダイジェストにおける類似／非類似についてサマリー４７３又はレポート４７５を生成する。
【００２７】
正則セルダイジェスト又はデザインユニットダイジェストは、図５に示すように、デザインデータを含むファイル４１１を処理することによって生成される。このデザインデータは、最終的には、集積回路又はチップとも呼ばれる物理的な回路の製造に寄与する。一実施形態においては、プロセッサ５３０上で実行される構文解析ツール５３１、構文解析ツールと連携して実行される標準化ロジック５３３、プロセッサ上で実行されるダイジェスタ（ｄｉｇｅｓｔｅｒ）５３４が、メモリ４１５に記憶される構文木５３２及び正則セルダイジェストを生成する。セルダイジェストの正則構成は、構文解析される設計言語によって決まる。これらのプロセッサは、セル毎に、少なくとも１つのダイジェストを生成する。例えば、ダイジェストは、構文解析ツールや標準化ロジックの正則出力から生成される３２ビット、又は、６４ビットコードである。ダイジェストの生成には、ＣＲＣやＭＤ５等の様々なハッシュ関数が使用できる。ダイジェスタは、セルのヘッダ部とボディ部に関して別々のダイジェストを生成し、セル内のレイヤーによってダイジェストを生成することが可能である。コメント、空白、機能的に重要なデータは、別々にダイジェストすることができる。ダイジェストは、後の使用のために、絶えず記憶することが可能である。例えば、承認されたライブラリのダイジェストを、デザインプロジェクトのダイジェストと繰り返し比較するために生成し、記憶することができる。
【００２８】
正則ダイジェストの比較は、ユーザにとって、大きなファイルのデザイン要素間の小さな差異を理解することができる強力なツールである。上述のように、デザインファイル、特に、バイナリのポリゴンデータを含むファイルは巨大である可能性がある。何千、何十万もの（或いは、例えばメモリが大きい場合はもっと多くの）セルが、デザインファイルに含まれている。このように大量のデータがある場合に、誤った警報は深刻な問題である。正則セルダイジェストの使い方の１つとして、機能的重要性、時には、デザインプロセスのソースに基づいて検出された変更を認識し、それについてのフィルタリングを許可することが挙げられる。
【００２９】
プロセッサ５３５上で実行される比較処理（ｃｏｍｐａｒｅｒ）５３６、及び、前記プロセッサ上で実行されるレポータ５３７は、ダイジェスタ５３４によってメモリ４１５に記憶されたダイジェストについて動作する。通常、ファイル４１１の２又は３のグループが比較される。簡潔性のために、ファイルのグループを「ファイル」と称し、読者には比較される実際のファイル数が任意であると理解されるものとする。「２つのファイル」とは、２又はそれ以上のファイルを意味する。２つのファイルは、セルの古いライブラリと新しいライブラリを表している。３つのファイルは、デザインファイルと、承認済みのセルのライブラリと、製品で使用されると故障の原因となる拒絶されたセルデザインの収集物である。比較処理は、１又は複数の他のファイルのダイジェストに対して、１つのファイルに関するダイジェストをチェックする。レポータは、フィルタリングの基準に応じて、各ファイルのセル間の一致、ほぼ一致、或いは、あるファイル内にはあって他のファイルには見当たらないセルをレポートする。これらのレポートは、メモリ４７３に対するデータベース又は別のプログラムが処理可能な他の中間フォーマット等のサマリーであり、或いは、人間であるオペレータがディスプレイ上又は紙上で閲覧できるレポート４７５に対するサマリーである。有用なレポートを生み出すためのファイルの比較には、様々な使用事例がある。
【００３０】
この技術の使用事例の中には次のものがある。
・  更新されたセルデザインライブラリを理解する。
・  プロセス中のデザインに対する、更新されたセルデザインライブラリの影響を評価する。
・  配置配線（ｐｌａｃｅ  ａｎｄ  ｒｏｕｔｅ）の前、テープアウトの前、他のデザインマイルストーンにおける各デザインデータにおいて、未承認及び／又は不良セルを見つける。
・  デザインデータ内の名称変更されたセルを認識し、それらが承認されたセルテンプレートに一致することを検証する。
・  テンプレートを提供しているベンダーの保証を危うくするセルの変更を検出する。
・  製品設計において、使用料を支払うべきセル数をカウントする。
これらの使用事例から、開示された正則ダイジェストが回路設計者にとって如何に強力なツールであるかが分かる。
【００３１】
プロトタイプの正則ダイジェストツールは、以下の主要なＥＤＡデザインデータフォーマットを処理し、他のフォーマットに拡張することも容易に可能である。
・  Ｏｐｅｎ  Ａｒｔｗｏｒｋ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｈａｎｇｅ  Ｓｔａｎｄａｒｄ（ＯＡＳＩＳ）幾何学的レイアウトファイル
・  Ｃａｌｍａ  ＧＤＳＩＩ幾何学的レイアウトファイル
・  Ｓｙｎｏｐｓｙｓ  Ｌｉｂｅｒｔｙライブラリ回路タイミングモデルファイル
・  Ｖｅｒｉｌｏｇ  Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ記述ファイル
・  ＶＨＳＩＣ  Ｈａｒｄｗａｒｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＶＨＤＬ）Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ記述ファイル
・  Ｓｉｍｕｌａｔｉｏｎ  Ｐｒｏｇｒａｍ  ｗｉｔｈ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  Ｅｍｐｈａｓｉｓ（ＳＰＩＣＥ）サブ回路ネットリストファイル
・  Ｃａｄｅｎｃｅ  Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）レイアウト記述ファイル
・  Ｃａｄｅｎｃｅ  Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＤＥＦ）デザイン記述ファイル
・  「構造化テキスト」スクリプト・コントロールファイル
・  非構造化（任意の又は未知のフォーマット）テキストファイル
・  非構造化（未知のフォーマット）バイナリファイル
【００３２】
また、前記ツールは、独自仕様のデータフォーマット（「ユーザによる構文解析」ファイル）に関する正則セルダイジェストを計算するための、アプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。プロセッサ上で実行される構文解析ツールは、ファイル内の重要なデザインオブジェクトを認識し、セル、セルに対するインターフェース、セルボディ、何れかのセルの外側のファイルヘッダデータに関するダイジェストを生成する。
【００３３】
セル内もしくはファイルヘッダ内のコメントは、コメントのみの変更が認識されるように別々に示される。ファイルヘッダ、セルインターフェース、セルボディ内の各データは、更に、個々のレイヤーに対する変更が明らかであるように、適切な場合、レイヤーによって更に分けられる。ファイルフォーマット内のデータが順序非依存（ｏｒｄｅｒ−ｉｎｄｅｐｅｎｄｅｎｔ）であり、ソートが要求された時、正則セルダイジェストツールは、順序非依存のデータのみをソートし、順序依存（ｏｒｄｅｒ−ｄｅｐｅｎｄｅｎｔ）のデータは元の順序のままにしておく。
【００３４】
［ダイジェスト計算の基本］
正則セルダイジェストが適用可能なデザインデータファイル内のオブジェクトの３つの一般的なクラスは、ファイル、ファイルヘッダ、及び、セルである。ファイルレベルのダイジェストはファイル内のデータすべてから計算することができる。正則セルダイジェストは、ファイルのセル又はモジュールに関して正則形式に再構成されたデータのダイジェストである。正則ファイルヘッダダイジェストは、如何なるセル及びモジュールにも存在しない、正則形式に再構成されたデータのダイジェストである。設計言語又はデータファイルフォーマットによって、及び、ユーザ選択オプションによって程度に差はあるが、再構成は、ダイジェストが生成される前に適用される。本開示では、ファイルヘッダ及びセルデータに適用されるダイジェストをまとめて「正則デザインユニットダイジェスト」と称する。ここに挙げた多くの事例から分かるように、ファイル内のデザインデータは、データカテゴリのどちらか一方しかないフォーマットであっても、一般的に、ヘッダデータ又はセルデータとして扱うことができる。
【００３５】
正則セルダイジェストは、セルの複数部分（コメントデータ、レイヤーデータ、非レイヤーデータ）に関して計算された複数のダイジェストを意味する。コメントデータは、所定のファイルフォーマットの仕様によって定められた、非機能的データ（大抵はテキスト）である。ほとんどのフォーマットでは、コメントダイジェストの変更は無視できる。レイヤーデータには、第１レイヤー金属又はポリシリコンといった、ファイルを読むツールにとって意味のある区別可能なレイヤー名、或いはレイヤー番号が付与されている。非レイヤーデータとは、レイヤー番号を持たない、例えば、ＧＤＳＩＩもしくはＯＡＳＩＳにおけるセル配置（インスタンス化）等のオブジェクト、或いは、レイヤー番号によって分割されていないファイルのオブジェクトを指す。
【００３６】
レイヤーデータは、更に、幾何学的データと非幾何学的データに分けられる。ＧＤＳＩＩ及びＯＡＳＩＳファイルは、幾何学データではないがレイヤー番号を持つテキスト及びノード名レコードを有する。ノード及びテキスト情報への変更は、必ずしも、経路又はポリゴンといった幾何学的なデータへの変更ほど重要ではないため、ノード及びテキストダイジェストは、別々に記録される。ユーザは、ノード及びテキストデータを幾何学的データと同じ重要度で扱うかを選択できるが、選択しなくても構わない。
【００３７】
［ファイルとダイジェストの構成］
ダイジェストを計算するために、ファイルは大抵、一般的に、オプショナルヘッダと０以上のセルを含む。ファイルヘッダ（セルが明確な終端レコードを有する場合等、テキストが明らかにセルに属していない場合、セルとセルの間にテキストが含まれることもある）内にはヘッダデータに加えてコメントが存在し、それらのコメントは、特定のレイヤー上にあるか、若しくは、ファイルフォーマットがレイヤー名もレイヤー番号も持っておらず、明らかに「非レイヤーデータ」とレポートされる。
【００３８】
セルは、オプショナル・インターフェース、オプショナル・ボディ、オプショナル・コメントを有する。これら３つのクラスの内少なくとも１つがセル内に存在する。セルインターフェースデータは、名称又は番号が付与されたレイヤー上にあるか、或いは、明示的に「非レイヤーデータ」とレポートされる。
【００３９】
セルボディデータは、名称又は番号が付与されたレイヤー上にあるか、或いは、明示的に「非レイヤーデータ」とレポートされる。セルボディ（本実施例では、セルインターフェースやファイルヘッダを除く）は、幾何学的データフォーマットに対して、ポリゴン、矩形、配線等を規定しない情報である「非幾何学的データ」を有する。一般に、非幾何学的データは、（例えば、ＧＤＳＩＩファイルやＯＡＳＩＳファイルにおいて）プロパティやテキストレコードである。データフォーマットが幾何学的でない場合（例えば、Ｌｉｂｅｒｔｙタイミングモデル）、すべてのデータは、たとえそれが当該クラスに記録されていなくても、非幾何学的である（呼び出し側は知っていることになっている）。通常、すべてのデータは「非レイヤー」であるから、このことは自明である。これは、実行決定（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ｄｅｃｉｓｉｏｎ）であり、本発明にとって重要ではない。
【００４０】
例として、レポートは、一般カテゴリ又は詳細カテゴリを有する。一般カテゴリの例は以下の通りである。
ファイル：
ファイルヘッダコメント
ファイルヘッダ非レイヤー
ファイルヘッダレイヤー・・・
セル・・・
セル：
セルコメント
セルインターフェース非レイヤー
セルインターフェースレイヤー
セルボディ非レイヤー
セルボディレイヤー
セルボディ非幾何学的非レイヤー
セルボディ非幾何学的レイヤー・・
詳細カテゴリの例は以下の通りである。
ファイル：
ファイル
ファイル非空白
ファイル空白
ファイルヘッダ（ソートされていない：メモリが不十分）
ファイルヘッダ（ソート要求無し）
ファイルヘッダコメント
ファイルヘッダ非レイヤーデータ（−１）
レイヤー毎のファイルヘッダ
セル
セル（ソートされた）
セル（ソートされていない：メモリが不十分）
セル（ソート要求無し）
コメント無しのセル
セルコメント
セルインターフェース
ファイルヘッダを含むセルインターフェース
ファイルヘッダを除くセルインターフェース
セルインターフェース非レイヤーデータ（−１）
レイヤー毎のセルインターフェース
セルボディ非レイヤーデータ（−１）
レイヤー毎のセルボディの幾何学的形状（Ｇｅｏｍｅｔｒｙ）
レイヤー毎のセルボディの非幾何学的形状（ｎｏｎ−Ｇｅｏｍｅｔｒｙ）
【００４１】
［ＧＤＳＩＩの例］
例として、コマンドラインによって生成されたダイジェストレポートを、小さなＧＤＳＩＩファイルに関する正則ダイジェストツールと考える。
File "testfiles/sigtest.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -nosort
db7be73c  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (not sorted)
8f078078  File Header with Comments
3289c53f  File Header without Comments
bd8e4547  File Header Comments
3289c53f  File Header non-Layer
Cell "Structure_1" (not sorted)
a7100492  Cell with Comments
3d4d7fbf  Cell without Comments
9a5d7b2d  Cell Comments
7b78aab4  Cell Body non-Layer
15546763  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
Cell "Structure_2" (not sorted)
cd2b135d  Cell with Comments
d2c6c150  Cell without Comments
1fedd20d  Cell Comments
0f4c0817  Cell Body Layer 1
d4133b6c  Cell Body Layer 19
0999f22b  Cell Body non-Geometric Data Layer 5
Cell "Structure_3" (not sorted; hierarchical)
a7100492  Cell with Comments
3d4d7fbf  Cell without Comments
9a5d7b2d  Cell Comments
7b78aab4  Cell Body non-Layer
15546763  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
Cell "Structure_4" (not sorted; hierarchical)
70262033  Cell with Comments
5242eac1  Cell without Comments
2264caf2  Cell Comments
7b78aab4  Cell Body non-Layer
7a5bf21d  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
【００４２】
参照ファイルであるtestfiles/sigtest.gdsは、db7be73c（１６進数）の３２ビットファイルレベルダイジェストを生成する。ファイル全体のダイジェストがダイジェストリポジトリに記憶されている場合、このダイジェストを使えば、ダイジェストが最後に処理され、ダイジェストリポジトリに記憶されてからファイルに対して変更が行われたかどうかを迅速に判断することができる。
【００４３】
ＧＤＳＩＩはバイナリファイルフォーマットである。バイナリデータを含むファイルは、空白を含まないため、空白及び非空白のダイジェストはレポートされない。非空白のダイジェストは、データファイルへの変更が、空白の変更のみに由来している場合に、それを判断する手段としてレポートされる。ファイル内の記号（テキスト）データはしばしば、空白（スペース文字、タブ、改行）によって区切られ、通常、空白の量は重要ではない。記号データに対する変更が行われたかどうかを判断できるように、プロトタイプの正則ダイジェストツールは、ファイル内のすべての空白文字に関して、及び、ファイル内のすべての非空白文字に関して、ダイジェストを計算する。尚、空白のダイジェストは、場所（ｌｏｃａｔｉｏｎ）に関係なく、バイト毎に空白の量を記録する。例えば、２つの文字列“abc def”と“abcd ef”に関して、同じ空白（単一の空白文字を使用）ダイジェストと非空白ダイジェストがレポートされる。
【００４４】
ＧＤＳＩＩ内のほとんどのデータは、セル（ＧＤＳＩＩの命名基準では「ストラクチャ（ｓｔｒｕｃｔｕｒｅ）」）内にあるが、どのセルの外側にも幾つかのレコードがある。このデータは、ファイルヘッダダイジェストでダイジェストされる。このヘッダデータは、ファイルヘッダコメント或いはファイルヘッダ非レイヤーデータの何れかのタイプによって区分することが可能であり、ＧＤＳＩＩファイルヘッダ内のデータにはレイヤー番号が付与されない。ＧＤＳＩＩデータの解釈及び記録の詳細を以下で説明する。
【００４５】
一貫性を保つために、共通のレポートフォーマットを使うか、或いは、ダイジェストをデータベースに保存することができる。この例においては、そのダイジェストのタイプに関して記録されたデータがない場合に、「（無し（ｎｏｎｅ））」という語がダイジェストの代わりに印字される。これについて２つの例が、レポート内のファイルダイジェストブロックにおいて示されている。
【００４６】
合成ファイルヘッダダイジェストは、個々のファイルヘッダダイジェストと共に記録される。これは、ユーザにとって便利なようにコマンドラインユーティリティによって計算される。一実施形態において、合成ファイルヘッダダイジェストは、単なる、個々のファイルヘッダ正則セルダイジェストの排他的論理和（ＸＯＲ）である。また、セルダイジェストが計算されるのと同時に計算することも可能である。この合成ファイルヘッダダイジェストは、ファイルヘッダデータにおける変更の検出に利用できる。
【００４７】
個々のセルダイジェストブロックは、ファイルヘッダダイジェストブロックの下に現れる。示されているように、セルダイジェストには、コメントダイジェスト、レイヤーデータ及び非レイヤーデータに関する幾何学的ダイジェスト、レイヤーデータ及び非レイヤーデータに関する非幾何学的ダイジェストが含まれ、コメント有り及びコメント無しのセルに関するセルダイジェストを合成する。合成ファイルヘッダダイジェストと同様に、合成セルダイジェストは、一実施形態において、他のセルダイジェストの排他的論理和によって生成される。この合成セルダイジェストは、セルデータにおける変更の検出に利用できる。
【００４８】
上記ＧＤＳＩＩファイルに関するダイジェストは、データのソート無しで生成された。このことは、ファイル名の直下でダイジェストのブロックと共に印字されるプログラムのアーギュメントリストでレポートされている。
【００４９】
セルＳｔｒｕｃｔｕｒｅ＿３及びＳｔｒｕｃｔｕｒｅ＿４は階層的である。すなわち、それらのセルは、その他のセルに対するＳＲＥＦ又はＡＲＥＦ参照を有する。一般的に言えば、デザインデータベース階層において高レベルにある配置配線セル及びその他のセルに関するダイジェストは、それらが参照するリーフセルに関するダイジェストよりもずっと頻繁に変更される。変更されたセルがリーフセルであるかどうかが分かれば、ダイジェストの変更の重要性についての判断に役立てることができる。
【００５０】
セルＳｔｒｕｃｔｕｒｅ＿１及びＳｔｒｕｃｔｕｒｅ＿３に関する正則セルダイジェストを見れば、これらのセルに関するすべてのダイジェストが同じであることが分かる。これは、これら２つのセルのポリゴン及びストラクチャ（セル）参照データが一致していることを示している。セルＳｔｒｕｃｔｕｒｅ＿２及びＳｔｒｕｃｔｕｒｅ＿４に関するダイジェストは、他のどのセルに関するダイジェストととも一致していない。
【００５１】
ソートが要求された場合、セルの幾つかの部分に関して、異なるダイジェストが生成される。
File "testfiles/sigtest.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -sort
db7be73c  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
8f078078  File Header with Comments
3289c53f  File Header without Comments
bd8e4547  File Header Comments
3289c53f  File Header non-Layer
Cell "Structure_1" (sorted)
a7100492  Cell with Comments
3d4d7fbf  Cell without Comments
9a5d7b2d  Cell Comments
7b78aab4  Cell Body non-Layer
15546763  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
Cell "Structure_2" (sorted)
cd2b135d  Cell with Comments
d2c6c150  Cell without Comments
1fedd20d  Cell Comments
0f4c0817  Cell Body Layer 1
d4133b6c  Cell Body Layer 19
0999f22b  Cell Body non-Geometric Data Layer 5
Cell "Structure_3" (sorted; hierarchical)
a7100492  Cell with Comments
3d4d7fbf  Cell without Comments
9a5d7b2d  Cell Comments
7b78aab4  Cell Body non-Layer
15546763  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
Cell "Structure_4" (sorted; hierarchical)
1f29b54d  Cell with Comments
3d4d7fbf  Cell without Comments
2264caf2  Cell Comments
7b78aab4  Cell Body non-Layer
15546763  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
【００５２】
構文解析の前にファイルデータから生成されるファイルレベルのダイジェストは、ソートの影響を受けない。ファイルヘッダダイジェストブロックもまた変更されない。なぜなら、ＧＤＳＩＩファイルヘッダデータは順序依存であり、ソートされないためである。多くのセルエレメントダイジェストは、データがソートによって順番が変わるため、変更される。セルＳｔｒｕｃｔｕｒｅ＿４におけるセルボディレイヤー３及び４２に関する正則セルダイジェストは、Ｓｔｒｕｃｔｕｒｅ＿１及びＳｔｒｕｃｔｕｒｅ＿３のそれと今度は一致する。これにより、Ｓｔｒｕｃｔｕｒｅ＿４は、Ｓｔｒｕｃｔｕｒｅ＿１及びＳｔｒｕｃｔｕｒｅ＿３と等しいレイヤーであることが分かる。
【００５３】
フォーマットによっては（例えば、ＧＤＳＩＩ及びＯＡＳＩＳ）、ソートは、ダイジェストのマッチングにとって非常に有用であるため、デフォルトの動作とすべきである。ＩＣデザインファイル内のほとんどのセルは小さいため、実行時間の影響はごく限られている。
【００５４】
６４ビットのダイジェストが要求された場合、ソート無しのレポートの抜粋は、次のようになる。
File "testfiles/sigtest.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -nosort
3670d1e4a8c8c74b  File
(none)            File non-Whitespace
(none)            File Whitespace
File Header (not sorted)
026a2a5b01e0f6ec  File Header with Comments
fd352337a1644620  File Header without Comments
ff5f096ca084b0cc  File Header Comments
fd352337a1644620  File Header non-Layer
Cell "Structure_1" (not sorted)
41a9962cc923db00  Cell with Comments
a9a2d1241367de40  Cell without Comments
e80b4708da440540  Cell Comments
bb89d94bb8544e78  Cell Body non-Layer
b9ef42b48f65e40d  Cell Body Layer 3
e16d5f5cf714adc4  Cell Body Layer 42
4aa91587d342d9f1  Cell Body non-Geometric Data Layer 3
Cell "Structure_2" (not sorted)
30f8dca7d40bb330  Cell with Comments
1db29288b51ebd16  Cell without Comments
2d4a4e2f61150e26  Cell Comments
a80b7d0fa1a83fe1  Cell Body Layer 1
4bb6333790890817  Cell Body Layer 19
fe0fdcb0843f8ae0  Cell Body non-Geometric Data Layer 5
【００５５】
［正則ダイジェスト及びＤＩＦＦツールの連続使用］
差分ツール及び差分アルゴリズムについては上記で述べた。差分ツールでは、差分を計算するために比較される一対のファイルが必要であり、分析時にはその一対のファイルが必要とされる。一方、正則ダイジェストは、どちらかのファイルがなくても比較することが可能である。
【００５６】
差分ツールと組合せた正則ダイジェストの応用例の１つとして、更なる調査のために、正則ダイジェストを用いて異なるセルを認識することが挙げられる。差分ツールは、異なるセル内で何が変更されたかについての詳細を認識するために利用できる。この的を絞った差分ツールの使用方法は、差分アルゴリズムを用いてデザインファイル全体を比較する方法に比べるとずっと効率的である。
【００５７】
典型的な差分アルゴリズムは、効果的な並べ替えが差分アルゴリズムには分からないため、データが比較のためにだいたい同じ順番である必要がある。結局のところ、差分アルゴリズムは、共通のサブシークエンスを探すことになる。差分アルゴリズムの実行時間は、最悪の場合、指数関数的に増加する。実行時間を改善するために、大抵の差分アルゴリズムは最大ウインドウを有するが、それを越えて完全に異なるデータ（すなわち、そのウィンドウ内では一致がない場合）を想定する。Ｐａｕｌ  Ｈｅｃｋｅｌの差分アルゴリズムは、こうした限定の例外である。“Ａ  Ｔｅｃｈｎｉｑｕｅ  ｆｏｒ  Ｉｓｏｌａｔｉｎｇ  Ｄｉｆｆｅｒｅｎｃｅｓ  Ｂｅｔｗｅｅｎ  Ｆｉｌｅｓ”，Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＡＣＭ  ２１（Ａｐｒｉｌ  １９７８）：ｐｐ．２６４−２６８を参照。
【００５８】
差分アルゴリズムは、比較するデータファイルには構造がない（或いは、ほとんどなく、テキスト行のみである）と想定している。差分アルゴリズムは、セル、ヘッダ、レイヤー、非レイヤーデータ、コメント等を自身では理解しない。
【００５９】
ＤｅｓｉｇｎＳｙｎｃ及びＩＣ  Ｍａｎａｇｅは、スタンダードなファイル差分アルゴリズムに基づいていると思われるＩＣデザイン産業のためのツールである。これらのプログラムは、管理するデータの機能的な意味を深く理解しているようには見えない。ＩＣ  Ｍａｎａｇｅ（ｈｔｔｐ：／／ｗｗｗ．ｉｃｍａｎａｇｅ．ｃｏｍ）は、Ｐｅｒｆｏｒｃｅソースコード管理システムをベースに用いている。Ｐｅｒｆｏｒｃｅは、一般的な目的に用いられるデータ管理であり、ＥＤＡデータファイルフォーマットを理解することを意図していない差分ツールである。ＤｅｓｉｇｎＳｙｎｃ（ｈｔｔｐ：／／ｗｗｗ．３ｄｓ．ｃｏｍ）の文献には、複数の関連ファイルを一緒にリンクしてセル（すなわち、複数のビュー）を表すことが述べられている。ＤｅｓｉｇｎＳｙｎｃについての更なる情報は、以下で確認できる（２００９年５月現在）。
・  ｈｔｔｐ：／／ｗｗｗ．３ｄｓ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｅｎｏｖｉａ／ｉｎｄｕｓｔｒｉｅｓ／ｈｉｇｈ−ｔｅｃｈ／ｓｅｍｉｃｏｎｄｕｃｔｏｒ／
・  ｈｔｔｐ：／／ｗｗｗ．３ｄｓ．ｃｏｍ／ｆｉｌｅａｄｍｉｎ／ＰＲＯＤＵＣＴＳ／ＥＮＯＶＩＡ／ＰＤＦ／ＳｙｎｃｈＤｅｓｉｇｎＳｙｎｃ０８０５＿ＰＲＥＳＳ＿．ｐｄｆ
・  ｈｔｔｐ：／／ｗｗｗ．３ｄｓ．ｃｏｍ／ｆｉｌｅａｄｍｉｎ／ＰＲＯＤＵＣＴＳ／ＥＮＯＶＩＡ／ＰＤＦ／ＳｅｍｉＡｃｃＩＰｍｇｍｔ０８０５＿ＰＲＥＳＳ＿．ｐｄｆ
【００６０】
差分ツールは、正則セルダイジェストによってほぼ一致していると認識されたセルの詳細な比較に役立つ。しかし、差分ツールは、実行時間、ＥＤＡファイルの構文の理解不足、ノイズを含むレポート、及び、マッチングの限界のために、巨大なデザインファイルやセルライブラリの分析には使えない。差分ツールは、どのセルが変わったのかをレポートすることはできず、順序非依存のデータが並べ替えられた時に、誤った差分をレポートする可能性がある。
【００６１】
正則セルダイジェストの概観とその有用性に留意して、チップデザインデータの正則表現がどのようにして構築されるかについて、多くの事例と共に、これより詳細な開示を行う。
【００６２】
＜＜展開された背景及び語彙＞＞
一般的に、チップデザインは、次の３つの大きなフェーズを経る。１）スタンダードセル及び他のデザインテンプレートライブラリの開発又は習得（工場を持たないデザインハウスのすべてが彼ら自身のデザインテンプレートライブラリを開発しているわけではない）、２）フロントエンド設計、すなわち、ＲＴＬの生成、次に論理合成、３）バックエンド設計、すなわち、フロア計画、配置配線、配置の最適化（ＩＰＯ）。
【００６３】
フロントエンド設計において、高レベルのデザインテンプレートブロックは、論理合成ツールによって選択されるのではなく、設計者によって直接組み込まれる（「インスタント化される（ｉｎｓｔａｎｔｉａｔｅｄ）」）。論理合成は、設計者のＲＴＬをバックエンド設計用の構造ネットリストに変換する時に、一般的に、より単純な機能性を有するスタンダードセルのみを選択する。バックエンド設計においては、論理を、チップの製造に順番に使用されるマスクの製造に適合させる。
【００６４】
高度な集積回路（“ｓｙｓｔｅｍ  ｏｎ  ｃｈｉｐ”又は“ＳｏＣ”と呼ばれることもある）には、回路の高度な機能ブロックが含まれる。このブロックは、複雑なデザインテンプレート、又は、デザインの完成した配置配線部分である。後者は、一般的に、論理合成システムによって選択されたスタンダードセルを備える。
【００６５】
工場を持たないチップデザイン会社、及び、サードパーティのデザインテンプレート供給者は、１以上のスタンダードセルを含み、集積回路の設計で共通して使われる演算を実行することが可能な高機能セルブロックを生成する。例えば、ＡＲＭプロセッサは、チップ内に取り込むことができるデザインテンプレートとして利用可能である。
【００６６】
小さいセル又はセルブロックに対する１又は複数の参照を含む、大きなセルブロックを、階層的であると言うことができる。大きなブロック内に含まれるセルブロックは、それ自身が階層的であり、そのため、セルブロック内に幾つかのレベルの階層が存在し得る。小さなセル及びセルブロックが参照によって組み込まれるため、それらのビュー及び従属物は同じままである。
【００６７】
セル及びセルブロックはセットで、デザインテンプレートブロックライブラリを表す。ブロックライブラリはサードパーティの供給者によって提供されるか、或いは、内部のライブラリ開発チームによって生成される。こうしたライブラリ内のデザインテンプレートは、加算器や乗算器といった比較的単純なブロックから、ＵＳＢポート等の通信コンポーネント、更には、デジタル信号プロセッサ（ＤＳＰ）等の複雑なコンポーネント、或いは、ＡＲＭによって提供されるような一般的な目的のプロセッサにまで及ぶ。これらのすべては、集積回路設計における複数の配置において用いることができる。
【００６８】
チップの設計及び製造を行う設計チームによって用いられるビューとアーティファクトは、読み出し専用ブロックライブラリ内に存在する。多数のライブラリ内には数百から数千ものデザインテンプレートが存在し得る。これらは共に、集積デザイングループとなるより大きなライブラリを形成する。論理及び物理的設計チームは、当該ライブラリを使って、集積回路の機能性、物理的レイアウトの夫々を生成する。
【００６９】
ライブラリからのすべてのデザインテンプレートが、集積回路設計で使用されるわけではない。論理合成ツールが、最適化アルゴリズムと共に上手く動作するセルのみを選んで、スタンダードセルタイプのサブセットから選択することもよくある。デザインテンプレートライブラリには、メモリブロック等の関連機能ブロック又は予め設定されたバリアント（ｖａｒｉａｎｔｓ）のクラスが含まれ、設計チームは、こうしたバリアントのサブセットのみを使うことを選択してもよい。
【００７０】
本開示における事物の記載方法と、一般的に用いられる命名方法との差に気付いた読者のために、本開示での「デザインテンプレート」は、当該業界ではしばしば「ＩＰ」と呼ばれることを指摘しておく。デザインテンプレートは、デザインデータと集積回路の物理的関係を読者に連想させるものであると考える。
【００７１】
＜ビュー及びアーティファクト＞
セルは、ビューとアーティファクトを有する。ビューとは、セルの物理的、機能的、電気的表現である。また、ビューは、セルがデザイン内でどのように作用するかを規定し、それによって、設計者が集積回路の生成にそれをどのように使うことができるかが規定される。
【００７２】
アーティファクトは、通常、コンパイルされたＲＡＭブロック用のログファイルやデータシート等のセルビューが生成されることによって生じるファイル、或いは、デザインテンプレートが大きなブロックに取り込まれた場合に使用される制約ファイルである。アーティファクトは、ツールでは直接使用されないかも知れないが、意味を設計者に伝える、構造化されていないテキストファイルであることが多い。セルに関する他のビューとアーティファクトとの同期をとることは有用である。
【００７３】
ＧＤＳＩＩ及びＯＡＳＩＳ（ポリゴンレベル）ビューは、リーフセル、セルブロック、機能ブロック、及び、集積回路全体の物理的なレイアウトを表している。Ｌｉｂｅｒｔｙビューは、リーフセル或いは複雑なデザインテンプレートのタイミングモデルを表す。
【００７４】
設計者によって生成された、或いは、デザインテンプレートの物理的レイアウトの代わりに提供されたＲＴＬビューは、デザインの動作、及び、プロセッサコア等のデザインテンプレートに対する論理的接続を記述する。ＲＴＬビューは、通常、Ｖｅｒｉｌｏｇ又はＶＨＤＬフォーマットである。論理合成は、制約ファイル及びシミュレーション制御ファイルに加えてＲＴＬビューを用いて、構造ネットリスト（通常は、Ｖｅｒｉｌｏｇ又はＶＨＤＬ）を生成する。
【００７５】
設計者は、構造ネットリストを使って集積回路のフロアプランを生成する。Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＤＥＦ）におけるビューは、配置配線プログラムに対してフロアプランを示す。構造ネットリスト、Ｌｉｂｅｒｔｙ、ＬＥＦ、ＤＥＦの各ビューは、配置配線プログラムに対する入力として使われる。配置は、一般的に、１回に１つの機能ブロック内で実行され、配線は、機能ブロック（ブロック内）内と、機能ブロック−デザインテンプレート（ブロック間）間の両方で実行される。ビューには、他のビューの生成に使われるものもある。例えば、リーフセル又はスタンダードセル用のＧＤＳＩＩポリゴンデータは、回路エクストラクタに送られ、トランジスタの接続及び寄生要素を決定する。これらの生成されたビューは、従属ビューと呼ばれる。ソースビューが変更された時に、従属ビューの幾つか又はすべてを再生成することは有用である。
【００７６】
＜セル、セルインターフェース、セルボディ＞
ファイルに関する正則ダイジェストは、ファイルを分析し、タイプによってセクションを分類することによって計算される。多くのファイルがファイルについてのグローバルな情報を含むヘッダを備えている。また、セル又はモジュールといった個々のデザインユニットがあり、これらが組み合わされてデザインを形成する。セルは、更に、セル名、セルインターフェース、セルボディに分類される。ほぼすべてのファイルフォーマットは、コメント、すなわち、何らかの意味を読者や特定のツールに伝えることが可能な公式の非機能的テキストを規定する方法を有する。
【００７７】
セルのインターフェースは、外部の世界に対してのセルの仕様である。インターフェースへの変更は重要であると見なされるため、レビューと承認とで別々に警告される。デザインが完成へと進むにつれて、インターフェースの変更を承認する基準は増加する。なぜなら、新しいセルを使用するために重要な改訂が必要となるためである。例えば、レイアウトセルにおいてピン（Ｐｉｎ）の配置を変更した場合、新しいバージョンを、デザインの再配線をしないで当座の代替として使用することはできない。このことは論理設計中には問題にはならないが、物理的デザインの後のほうの段階になって、大きなスケジュールの遅延を起こす可能性がある。
【００７８】
セルインターフェースの一部ではないコンポーネントは、セルボディの一部である。これらのセルのアスペクトは、セルの既存のインスタンス（ｉｎｓｔａｎｔｉａｔｉｏｎ）を自動的に無効化にせずに、変更することが可能である。例えば、レイアウトセルの中央にある埋め込みレイヤーに対する変更は、再配線を必要としない。
【００７９】
ＧＤＳＩＩ及びＯＡＳＩＳファイルは、セルのボディ内に２つのクラスのデータを有する。第２クラスのデータは、テキストポイントやノードポイントといった非幾何学的データであり、これはセル非幾何学的ボディデータと呼ばれる。該区別は任意であり、このクラスのデータは、単純に別々に記録されている。ユーザによって構文解析されるテキストファイルにも利用可能である。
【００８０】
ファイルフォーマットには、他のセルへの参照を含むセルといった、階層データを規定できるものもある。この情報が利用可能である場合、セルにおけるフラグとしてのダイジェストデータを付けて返却される。
【００８１】
＜レイヤー＞
多くのデザインファイルは、複数のレイヤーに分割される。レイヤーによって様々な機能を有し、あるレイヤーへの変更は、その他のレイヤーよりも「安い（ｃｈｅａｐｅｒ）」。例えば、デザインが製造された後に論理エラーが見つかった場合、１又は複数の金属マスクにのみ変更が必要な修正は、トランジスタ層に対する変更が必要な修正よりも費用が安くつく。ファイルヘッダに関するダイジェスト、セルインターフェース、セルボディは、レイヤー単位で定義される。
【００８２】
内部的には、ダイジェストモジュールは、通常−１から小さい正数までの整数によってインデックスが付けられたレイヤーに関するダイジェストを記録する。−１のレイヤー番号は、通常、ＧＤＳＩＩやＯＡＳＩＳ等のレイアウトファイルにおけるセル参照のように、どのレイヤー上にも存在しないデータ、或いは、レイヤーを持たないフォーマットに関するすべてのデータを表している。
【００８３】
テキストベースのレイヤー名を用いた構文解析ツールは、レイヤー名に対するレイヤー番号のマッピングを返却するため、ダイジェストは名称によってレポートされる。構文解析ツールは、それ自体にレイヤー番号を割り当てるので、このリストを読み出し、ダイジェストと共に番号を記録又は印字することは有用である。
【００８４】
＜ソート＞
幾つかのフォーマットにおけるデータには、順序非依存、すなわち、ファイルの解釈が、ヘッダ又はセル内のオブジェクト（例えば、ポリゴン）の出現順序に依存しない部分がある。ファイルのこうした部分をソートするオプションが提供されている。例えば、ＶＨＤＬモジュールは、配線が名称毎にポートに関連付けられた関連リストを用いてインスタンス化されている。リストの順番は任意である。しかし、モジュール内の連続したステートメントは、並べ替えるべきではないので、ソートオプションが選択されてもソートは行われない。
【００８５】
ファイルデータが、すべてがソートされるまでメモリに保存されるとすると、相当な量のメモリが必要となる。プログラムに渡されたメモリ使用限度を超えると、記憶されたデータ（通常はセルデータ）が直ちに、ファイルから読み出された時と同じ順番で、ダイジェストモジュールに送信される。或いは、ファイルベースのソートが用いられる。ソートルーティンの詳細は、個別のファイルフォーマットの説明において開示される。
【００８６】
ファイルヘッダ及びセルダイジェストは、メモリ使用限度が変更された場合、或いは、プログラムのメモリの使用が改善された場合に、変更される。セルがソートされたかどうかを示すフラグは、アプリケーションプログラミングインターフェース（ＡＰＩ）を通じて利用可能であり、ファイルヘッダ又はセルに関するダイジェストと共にダイジェストデータベースに保存される。このフラグを用いることで、プログラムは、ダイジェストの変更がデータにおける実質的な変更によるものか、或いは、単にソートによるものかを判断することができる。
【００８７】
＜コメント＞
多くのフォーマットでは、コメントは、ソートや更なる解釈をされることなく、直ちにダイジェストモジュールに送信される。セル内のコメントは当該セルに関するコメントダイジェストに追加される。セルの外側のコメントは、ファイルヘッダコメントダイジェストに追加される。ＶＨＤＬでは、コメントは、合成命令を含むことができるため、特定のトークン（ｔｏｋｅｎ）シーケンスに関連付けされており、ソートを行うことができる。
【００８８】
コメントは、レイヤー名もレイヤー番号も持たない。
【００８９】
＜レビューされるデザインデータファイルフォーマット＞
チップデザインデータの多くのビューは、特化したファイルフォーマットを使用する。これらの中には、バイナリのものもあれば、テキスト（記号）のものもある。しかし、ファイルは大きく、人間が読めるものであっても見ることが難しい傾向にある。これらのファイルは、ライブラリベンダーやデザインテンプレートベンダーによって生成され、Ｅｌｅｃｔｒｏｎｉｃ  Ｄｅｓｉｇｎ  Ａｕｔｏｍａｔｉｏｎ（ＥＤＡ）ツールによって用いられるが、典型的なデザインハウスには、そうしたファイルを解釈し、これらのファイルについて自分自身で判断する能力がなかった。
【００９０】
ＧＤＳＩＩ及びＯＡＳＩＳのビューは、リーフセル及び階層セルの物理的レイアウトを含んでいる。リーフセルは、幾何形状（ｇｅｏｍｅｔｒｙ）（ポリゴン、配線、矩形、円等）しか含まない。階層セルは、他のセルに対する参照を含んでおり、幾何形状も含む。また、デザインテンプレートブロック、ベンダーからインポートされたプロセッサコアといった複雑な機能を持ち得るセルがある。設計者は、リーフセル及びデザインテンプレートブロックを変更無しで使用するものと考えられている。
【００９１】
ＧＤＳＩＩビュー又はＯＡＳＩＳビューは、単一のファイルに含まれ、複数のセルに対する幾何学的データを含んでいる。こうしたビューは、チップ内で参照される幾何学的データのライブラリを定義するか、或いは、チップに関する幾何学的データを定義する。
【００９２】
Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）ビューは、配置配線ツールへ提示するために、１又は複数のリーフセル又はデザインテンプレートブロックの物理的レイアウトの単純化されたバージョンを含む。
【００９３】
Ｌｉｂｅｒｔｙビューは、リーフセル、複雑なデザインテンプレート、或いは、夫々の混合である、１又は複数のセルのためのタイミング情報を含んでいる。
【００９４】
Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ（ＲＴＬ）ビューは、セルの動作記述を含む。典型的には、ＲＴＬビューは、Ｖｅｒｉｌｏｇ又はＶＨＤＬ言語フォーマットで規定される。論理合成は、ＲＴＬビューを構造ネットリストに変換する。構造ネットリストは、リーフセルや、デザインテンプレートブロックや、他の構造ネットリストへの参照を含むビューである。構造ネットリストは、非常に制限されたバージョンのＶｅｒｉｌｏｇ又はＶＨＤＬ言語フォーマット内でよく見られ、参照セルのリストのみを含んでおり、動作記述を含まない。構造ネットリストは、配置配線ツールへのエントリーに適している。構造ネットリストが配置配線されると、その性能を評価することが可能となり、妥当であれば、製造へのリリースが可能となる。
【００９５】
Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＤＥＦ）ビューは、フロアプランの記述、チップの粗い表現を含む。ＤＥＦビューは、大きなデザインテンプレートブロック及び空白エリアの配置を定義し、配置配線ツールがスタンダードセルをそこへ配置する。チップ内のブロックに関してＤＥＦファイルを生成し、当該ブロックに対して配置配線を実行し、そのブロックを高レベルのＤＥＦビュー内で使用することが可能である。配置配線されたブロックは、デザインテンプレートブロックと同様に扱われる。
【００９６】
スタンダードセルのライブラリを生成する場合、物理的なレイアウトに関して回路抽出が行われる。キャパシタンスや抵抗といった寄生性要素を含む、物理的なレイアウトにおける装置及び相互接続の電気的表現が生成され、ＳＰＩＣＥ等の回路シミュレータによって使用可能なフォーマットに変換される。ＳＰＩＣＥビューは、リーフセル或いは階層セルに関するデータを表す。
【００９７】
ＳＰＩＣＥビューは、回路特性評価プログラムへの入力として使用される。このプログラムは、典型的には、ＳＰＩＣＥや他の電気的シミュレータを用いて、特定の刺激（ｓｔｉｍｕｌｕｓ）又は一連の刺激の下で回路を評価し、回路内の遅延を評価する。こうした遅延はＬｉｂｅｒｔｙビューに記憶される。論理合成及び配置配線ツールは、Ｌｉｂｅｒｔｙビューを使って、デザインの性能又はデザインの部分を評価する。
【００９８】
上記から分かるように、特定のビューは、他のビューを生成するために使用されるデータを含む。例えば、ＧＤＳＩＩ又はＯＡＳＩＳのレイアウトビューは、ＬＥＦ及び抽出されたネットリストビューの生成に用いられ、抽出されたネットリストビューは、Ｌｉｂｅｒｔｙビューの生成に使用される。生成されたビューは従属ビューとなり、レイアウト等の独立ビューと従属ビューとの間には複雑な関係がある。
【００９９】
スタンダードセルは一般に、インバータ（２つのトランジスタ）からフリップフロップ（２０〜４０のトランジスタ）或いは加算器（１０〜１００のトランジスタ）までの比較的単純な機能を実施する。それらの機能は、論理合成ツールが直接操作できる程、単純である。１つのスタンダードセルライブラリに数千のスタンダードセルが存在し、１つのデザインに利用可能な３から恐らくは数十のスタンダードセルライブラリが存在する。
【０１００】
デザインテンプレートブロックは、一般的に、プロセッサコア、読み出し・書き込みメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、入力／出力サブシステムといったより複雑な機能を実行する。それらの機能は、論理合成ツールには複雑すぎて直接操作することができない。その代わりに、設計者は、デザインテンプレートブロックのインスタンスをデザインに挿入することを明確に要求し、次に、デザインテンプレートブロックへの接続を規定する。便宜上、インスタンスは通常ＲＴＬビューに配置される。１つのＳｏＣデザインには数百の個々のデザインテンプレートブロックが配置されている。
【０１０１】
メモリは、一般的には、デザインテンプレート供給者によって記述されたコンパイラを用いて生成される。これにより、設計者は、コンパイラが処理を終了した時点から変更されていない限り、デザインテンプレート供給者によって保証されたカスタムメモリ設定（例えば、ワード幅、ワード数等）を生成することができる。このために、設計者は、メモリコンパイラの出力をデザインテンプレートブロックとして扱うものと考えられている。
【０１０２】
メモリブロックは、階層構造のＧＤＳＩＩ又はＯＡＳＩＳビューに含まれる。このビューは、最終の組立（ａｓｓｅｍｂｌｙ）の間、デザインに組み込まれる。また、コンパイラは、自動化されたツールがメモリを使用するデザインを分析できるように、タイミングビュー（通常はＬｉｂｅｒｔｙ）及び物理的抽象化（ａｂｓｔｒａｃｔｉｏｎｓ）（通常はＬＥＦ）を生成する。
【０１０３】
設計チームにとって利用可能な、すべてのスタンダードセルライブラリ、及び、デザインテンプレートブロックを検討する場合、何万もの異なるセルが存在する。これらのセルのすべてが所定のデザインで用いられるわけではない。例えば、設計チームは、排他的論理和（ＸＯＲ）ゲートを用いた論理合成ツールでは上手くいかなかった場合、論理合成ツールにはＸＯＲゲートを使わないようにする。セル機能には、複数のドライブ強度（接続する回路及び寄生要素の量的変化に対応するための電流容量）に含まれるものもあるが、デザインツールは、所定のデザインにおけるドライブ強度のすべてを使うわけではない。
【０１０４】
＜＜セルビューに関する正則ダイジェストの実施例＞＞
このセクションにおいては、ＩＣデザインに用いられる多くの設計言語及びファイルフォーマットについて、説明及び分析を行う。ＩＣデザインフローで用いられる正則バージョンのデザインデータを準備する例を１０以上提供する。
【０１０５】
図１は、高レベルにおける、集積回路設計環境である。もちろん、この環境には多くの変形例があり、詳細の多くはここでは示さない。この変形例では、ブロックのほとんどが、セルデザインテンプレートの開発者が工場を持たない顧客１３７にテンプレートを提供するためのプロセスを示している。顧客１３７は、ファウンドリ１５１に頼ってチップを製造し、ファウンドリからのフィードバックに基づいて行動する。この概略図から、工場を持たない顧客による、ファウンドリでの製造向けのデザインのリリースには、マスク製造のための所謂「テープアウト」が含まれる。設計工程の初めに、設計者は、機能的仕様１１１を開発し、論理設計を行ってＲＴＬ１２１を生成する。ＲＴＬ１２１は、競合他社のデバイスには見られない、或いは、低価格の新しい機能を提供する。設計者は、ファウンドリの規則及び電気的情報１４１を含む、ファウンドリからの利用可能な情報を有する。ファウンドリ情報は、論理合成１２３の間にＲＴＬと組み合わされるセルデザインテンプレート１３１のライブラリに反映される。ＲＴＬは、フロントエンドビュー１２５として、工場を持たない顧客に提供されることもある。論理合成の出力は、フロアプランニング１３３で使用され、フロアプランニングの出力は、バックエンドビュー１４５を生成する配置配線作業１４３で使用される。図示していないが、配置配線作業は、物理的な制約を受けることが容易に理解される。バックエンドビューは、工場を持たない顧客１３７にリリースされる。バックエンドビュー及びフロンエンドビューは、工場を持たない顧客によって或いは当該顧客のためにライブラリにコンパイルされる。これらのバックエンドビューは、顧客が変更すべきでない固定化されたブロックの形をしている。
【０１０６】
図２は、バーションの増殖と図１のブロックに関連する幾つかのファイルフォーマットを示している。２つの図で並列的に付与されている番号は、２つの図におけるブロックを関連付けている。機能的仕様は、設計言語で表される。機能的仕様の制限にはバージョンがある。論理設計２２１で生成されるＲＴＬは、独自のバージョンを持つＶｅｒｉｌｏｇ又はＶＨＤＬで表現される。ファウンドリ規則２４１は、ＰＤＫ、Ｉｎｔｅｒｃｏｎｎｅｃｔ、Ｐａｒａｍｅｔｒｉｃｓ等の言語か、或いは、ファウンドリ独自の言語で表現される。参照セルライブラリには、デザインデータのための多数のビューが含まれる。これらのビューを表す言語には、ＳＰＩＣＥ、Ｌｉｂｅｒｔｙ、ＬＥＦ、ＧＤＳＩＩがある。論理設計２２１の期間、出力にはシミュレーション制御及びＲＴＬ（Ｖｅｒｉｌｏｇ又はＶＨＤＬ）が含まれる。論理設計の結果は、Ｌｉｂｅｒｔｙ、ＬＥＦ、ＲＴＬで表されるフロントエンドビュー２２５として直接発行される。或いは、論理合成２２３に送信される。論理合成２２３の結果は、物理的仕様２５３と組み合わされ、フロアプランニング２３３及び配置配線２４３への入力として使用される。これらの処理は、構造ネットリスト、ＤＥＦ、Ｌｉｂｅｒｔｙ、ＬＥＦ、ＧＤＳＩＩ等のビューを利用する。これらの処理の結果は、バックエンドビュー２４５として発行される。工場を持たない顧客１３７は、デザインデータのフロントエンドビュー及び／又はバックエンドビューを使用する。尚、図２に示されるバージョン番号は、単に説明のためのものであり、言語又はライブラリの過去、現在、未来のバージョンを参照するものとして解釈するべきではない。図２で参照されたファイルフォーマットについては、以下のセクションで説明を行う。
【０１０７】
＜ファイルタイプの分類＞
この議論では、ファイルは、非構造化テキスト、構造化テキスト、非構造化バイナリ、構造化バイナリの何れかに分類される。非構造化ファイルは、特定のフォーマットを持たず、文書等の補助的なファイルであるか、或いは、セルもレイヤーも持たないかのどちらかである。これらのファイルに関して計算されるダイジェストは、非常に限定されている。構造化ファイルは、コメント、レイヤー名又はレイヤー番号、セルを含む定義された構文を有する。これらを基に、構文解析ツールはファイルのセクションを区別し、タイプによってこれらをマークする。
【０１０８】
ＧＤＳＩＩ及びＯＡＳＩＳファイルを除いて、あるフォーマットのファイルに関して生成されたダイジェストは、一般的に、他のフォーマットのファイルに関して生成されたダイジェストとは互換性がない。すなわち、ファイルタイプを横断するダイジェストの比較は、通常は無意味である。オブジェクトのプロパティが存在しない場合、ＧＤＳＩＩデータとＯＡＳＩＳデータは、これらのファイルタイプを横断する比較をサポートする内部表現に初めに変換されるため、比較が可能である。一般的に言って、ＯＡＳＩＳのオブジェクトプロパティは、ＧＤＳＩＩのオブジェクトプロパティに対して、以下の例外を除き互換性がない。当該例外として、ＯＡＳＩＳファイルのＳ＿ＧＤＳ＿ＰＲＯＰＥＲＴＹプロパティは、等価なＧＤＳＩＩプロパティに変換される。
【０１０９】
ファイルタイプとそれらの解釈の詳細な説明を以下に行う。ファイル解釈、ダイジェスト計算、ソート動作の詳細を以下に記す。各セクションは、独立した参照となるように自己完結している。したがって、繰り返される情報もある。
【０１１０】
以下に示す説明において、言語のキーワードは、例えば、HEADERTEXT又はscaled_cellといったように、クーリエのフォントで表す。（翻訳者注：電子出願システムの制約から、フォントを変化させる文字修飾ができないため、原文のクーリエは半角文字で区別している。）
【０１１１】
［ファイルレベルダイジェスト］
構文解析ツールは、解釈及びソートを行わずに、ファイル内のすべてのバイトに関して順番に、少なくとも１つのファイルレベルダイジェストを計算する。テキストベースのフォーマットに関する構文解析ツールも、すべての空白文字（スペース及び水平タブ）に関するファイルレベルダイジェスト、及び、すべての非空白文字に関するファイルレベルダイジェストを計算する。これらのダイジェストは、正則セルダイジェストではない。これらは、フォーマット固有ではなく、ファイルが完全に変更されたかどうかをすばやく判断するためのみに使われる。
【０１１２】
［正則ダイジェスト］
正則ダイジェストを記録する場合、ファイルは、記録タイプに関連付けられたファイルユニットに分類される。ファイルユニットは、典型的には１又は複数のトークン（語又は句読点）といった言語仕様によって定義されるファイルの一部であり、記録タイプは、ファイルヘッダ、コメント、セル名、セルインターフェース、セルボディ、セル非幾何学的ボディの内の１つである。セル非幾何学的ボディデータは、単に、セルボディデータの別のクラスである。現在、このクラスは、NODEレコードやTEXTレコードといった、レイヤー番号を持つ非幾何学的データを示すために、ＧＤＳＩＩ及びＯＡＳＩＳの構文解析ツールでのみ使用されている。
【０１１３】
ファイルフォーマットに関するダイジェストの計算方法の定義は、図８〜１７に示されるように、複雑である。各フォーマットの説明には、外観、ファイルユニットの処理に関する詳細な仕様、及び、例が含まれる。
【０１１４】
＜例１：Ｌｉｂｅｒｔｙフォーマットされたファイル＞
Ｌｉｂｅｒｔｙライブラリファイルフォーマットは、回路の機能及びタイミングを記述する方法を論理合成ツールに提供する。前記フォーマットは、Ｓｙｎｏｐｓｙｓにより定義され、仕様が公開されたため、広く使われている。前記フォーマットは、容易に閲覧できるテストベースのフォーマットであるが、Ｌｉｂｅｒｔｙファイル内のデータのボリュームのために、通常、ソフトウェアによって生成される。
【０１１５】
この第１の例では、Ｌｉｂｅｒｔｙ設計言語ファイルのダイジェスト化について説明する。Ｌｉｂｅｒｔｙファイルの中には記録されない部分もある。「記録されない（Ｕｎｒｅｃｏｒｄｅｄ）」とは、正則ダイジェスト化を指している。一般的に言って、セル名は、異なる名称を持つ他の等しいセルのマッチングを妨げる虞があるため、ダイジェスト化されない。構文解析ツールの中には、要求されるトークンをスキップし、（ダイジェストは、いずれにしてもレイヤーによって分けられるため）場所が固定されたキーワードやレイヤー名等の付加的な情報を提供しないものもある。
【０１１６】
フォーマットによっては、記録される「テキスト」が、実際に印字できないバイナリデータであり、記述が言語仕様からのキーワードを用いているものもある。
【０１１７】
正則セルダイジェストは、通常、３２又は６４ビットからなる。どちらのタイプも、巡回冗長検査（ＣＲＣ）を用いて計算される。３２ビットダイジェストは、下記のＩＳＯ３３０９ＣＲＣ多項式、及び、ＳＥＭＩ規格Ｐ００３９−１１０５におけるＯＡＳＩＳファイルに関して規定された方法を用いて計算される。
ｘ３２＋ｘ２６＋ｘ２３＋ｘ２２＋ｘ１６＋ｘ１２＋ｘ１１＋ｘ１０＋ｘ８＋ｘ７＋ｘ５＋ｘ４＋ｘ２＋ｘ＋１
６４ビットダイジェストは、Ｅｃｍａ  Ｉｎｔｅｒｎａｔｉｏｎａｌの規格ＥＣＭＡ−１８２に関して規定された下記のＣＲＣ多項式を用いて計算される。
ｘ６４＋ｘ６２＋ｘ５７＋ｘ５５＋ｘ５４＋ｘ５３＋ｘ５２＋ｘ４７＋ｘ４６＋ｘ４５＋ｘ４０＋ｘ３９＋ｘ３８＋ｘ３７＋ｘ３５＋ｘ３３＋ｘ３２＋ｘ３２＋ｘ３１＋ｘ２９＋ｘ２７＋ｘ２４＋ｘ２３＋ｘ２２＋ｘ２１＋ｘ１９＋ｘ１７＋ｘ１３＋ｘ１２＋ｘ１０＋ｘ９＋ｘ７＋ｘ４＋ｘ＋１
【０１１８】
［Ｌｉｂｅｒｔｙ（．ｌｉｂ）ファイルのファイルコンテントダイジェスト］
Ｌｉｂｅｒｔｙ（．ｌｉｂ）ファイルに適用される、この例の詳細は、scaled_cellレコードがcellレコードと同じファイル内にあるか否かに依存する。以下に述べる議論の第１部分は、同一ファイルに２種類のレコードが存在することを想定している。後の部分では、その２種類のレコードを違うファイルで見つけることができる。
【０１１９】
Ｌｉｂｅｒｔｙファイルには、以下のファイル要素の幾つか或いはすべてに関するコンテント（ｃｏｎｔｅｎｔ）ダイジェストがある。
・  ファイル
・  ファイルヘッダ
・  ヘッダ内のコメントテキスト（任意）
・  セルのヘッダ
・  ファイルヘッダ情報を除くセルのボディ（任意）
・  セルに統合されたファイルヘッダ情報を備えるセルのボディ（任意）
・  セルの内部にあるコメントテキスト（任意）
【０１２０】
内部のセル名を見つけるために、ファイルの検査を行う。ファイル内のセルに関して、ツールは、セルのヘッダに関するダイジェスト（入力及び出力仕様）、及び、セルのボディに関するダイジェストを返却する。
【０１２１】
任意で、ヘッダ内及びセル内部のコメントテキストに関して、別々のダイジェストが計算され、空白の違い（スペースの数、タブ対スペース、空白行）は無視される。
【０１２２】
ダイジェストが、ファイルのヘッダ（セル定義前の情報）及びファイル全体に関して計算され、返却される。デフォルトでは、（例えば）ライブラリ内のすべてのセルに影響するようなユニット定義又は論理閾値の変更に起因する問題を回避するために、ファイルのヘッダに関するダイジェスト（コメントテキスト、ファイルの日付、版を除く）は、セルに関するダイジェストと統合される。ファイルヘッダが変更されたがセルの比較がやはり望まれる場合には、オプションとして、ファイルヘッダをセルボディのダイジェストの計算から除外することもできる。
【０１２３】
すべてのcell及びscaled_cellグループのステートメントは、ファイルのソートが要求されているか否かに関係なく、ダイジェストを記録する前に、順番に並べられる。セルに関するダイジェストには、すべてのscaled_cellタイミング定義も同様に含まれる。cellグループが最初で、scaled_cellグループが動作条件グループ名に基づく順番でその後に続く。
【０１２４】
scaled_cellレコードは、ｕｎｓｃａｌｅｄセルの前を含めてファイル内の何処にでも出現するため、「空白を含むすべてのテキスト」のダイジェストがセルに関して計算されることはない。このダイジェストは、ファイルレベルでのみ計算される。
【０１２５】
scaled_cellレコードをcellレコードでグループ化するようなソートが要求されるため、コマンドラインで規定されたメモリ限度に関係なく、ファイル全体がメモリにロードされる。ただし、cell及びscaled_cellグループのステートメントは、別々のファイルにある場合があり、その場合、これらのステートメントは、同一ファイルにある場合のように順番に並べられる代わりに、下記のように扱われる。
【０１２６】
セルヘッダダイジェストには、ピン名のみが記録される。これは、例えば、ピンの方向が変わってもヘッダダイジェストは変わらないことを意味している。
【０１２７】
必要とされる実行時間のために、一実施形態におけるグループステートメントのソートは、浅く（ｓｈａｌｌｏｗ）なっている。すなわち、グループステートメントのリストをソートする時に、グループステートメントの１つの子レベルのみが考慮される。或いは、複数の子レベルをソートすることも可能である。尚、１グループ内の複数のステートメントが（１つの子レベルを使って）ソートされる。すべてのソートは、安定しており、特定の相対的な順番で並んでいたステートメントは、比較の限界を超えても、その相対的な順番のままである。例えば、以下をソートすると、下記の表１に示す結果となる。
（表１）ファイルグループステートメントのソート
2011525276.tif 000003
【０１２８】
グループステートメントgbは、キーワードgbがgaの後に来るため、パラメータAがCの前にあっても、すべてのgaグループの後ろに移動する。また、パラメータCを持つ２つのga ステートメントは、同じ相対的な順番のままである。なぜなら、その下位レベルのpステートメントは、当該ソートの間には考慮されないためである。pレコード自体は、gaレコード内でソートされ、Gパラメータを持つ１つのgaレコードは、１連のgaレコードの最後に移動する。
【０１２９】
［Ｌｉｂｅｒｔｙライブラリ記述ファイル］
レイアウト設計者は、異なるライブラリのセルに同じセル名を使うことがよくあるため（例えば、高性能対高密度）、異なるライブラリのセルを区別するために、Ｌｉｂｅｒｔｙファイルのライブラリ名は、例えば以下のように、すべてのセル名の前に付与される。
library (demo) {
cell (INV_X1) {
area : 0.032;
...
}
}
【０１３０】
このセルに関連するセル名は、demo.INV_X1である。
【０１３１】
Ｌｉｂｅｒｔｙフォーマットは、すべての予想されるプロセスコーナーに対するタイミング及び電力係数が推定できるように設計された複数のスケーリングパラメータを規定している。中にはこれでは十分でないセルもあるため、通常のcellステートメントの代わりにscaled_cellステートメントを用いて、新たにｓｃａｌｅｄ  ｃｅｌｌレコードを、これらのセルに関して定義することができる。例えば下記のように、ｓｃａｌｅｄ  ｃｅｌｌレコードのセル名は、ｓｃａｌｅｄ  ｃｅｌｌ名で新たに記述される。これは特に、同一ファイル内に両方のタイプのセルがある場合に、セルタイプを区別するのに役立つ。
library (demo) {
scaled_cell (AND2_X2, slow_slow) {
area : 1.064000;
...
}
}
【０１３２】
このセルに関連するセル名は、demo.AND2_X2.slow_slowである。
【０１３３】
Ｌｉｂｅｒｔｙファイルには、セルに適用されるパラメータを規定する大規模（ｅｘｔｅｎｓｉｖｅ）ヘッダも含まれる。このヘッダに対する不注意による変更は重大な結果を招き得るため、デフォルトで、このヘッダ内のパラメータの少なくとも幾つかに関するダイジェストは、ファイル内のセルに関するダイジェストに統合されることになっている。すべてのセルに対応する変更がなく、ヘッダが（より小さい電圧又は時間単位に変換する等）誤って変更されることがない場合に、ヘッダの統合を-noheaderコマンドラインオプションで無効化することができる。
【０１３４】
Ｌｉｂｅｒｔｙファイル内のステートメントは、順序非依存であるため、ユーザが-nosortフラグを指定しない限り、これらのステートメントは、デフォルトで、ソートされる。
【０１３５】
Ｌｉｂｅｒｔｙファイル内にはレイヤーが無いため、以下のサンプルレポートのように、セルに関するすべてのダイジェストは、非レイヤーデータとしてレポートされる。
File "testfiles/tstlibpar2.lib": Liberty format
Arguments: -mem 64 -sort
728fb5e7  File
451c31ec  File non-Whitespace
00a03577  File Whitespace
File Header (sorted)
164c9eaf  File Header with Comments
1cc03fe0  File Header without Comments
0a8ca14f  File Header Comments
1cc03fe0  File Header non-Layer
Cell "demo.AND2_X1" (sorted)
be7930d6  Cell with Comments
be7930d6  Cell without Comments
(none)    Cell Comments
fe7aeb77  Cell Interface non-Layer
4003dba1  Cell Body non-Layer
【０１３６】
ここでは、ヘッダの統合が使用可能である。使用不可の場合は、ファイル名の下のアーギュメント行が、-noheaderとレポートする。
【０１３７】
［Ｌｉｂｅｒｔｙフォーマットファイルの処理詳細：定義］
プロトタイプのＬｉｂｅｒｔｙ構文解析ツールは、ＳｙｎｏｐｓｙｓのＬｉｂｅｒｔｙリファレンスマニュアル（バージョン２００７．０３）に記載されているＬｉｂｅｒｔｙフォーマットの定義に従っている。
【０１３８】
［構文解釈］
前記Ｌｉｂｅｒｔｙリファレンスには、３つのステートメントタイプが記載されており、次のように要約できる。
ｋｅｙｗｏｒｄ：ｖａｌｕｅ；
ｋｅｙｗｏｒｄ＝ｖａｌｕｅ；
ｋｅｙｗｏｒｄ（ｖａｌｕｅ．．．）；
ｋｅｙｗｏｒｄ（ｖａｌｕｅ．．．）｛ｓｔａｔｅｍｅｎｔ．．．｝
【０１３９】
最初の２つの形は、単純な属性（ｓｉｍｐｌｅ  ａｔｔｒｉｂｕｔｅｓ）として知られている。３番目の形は複雑な属性（ｃｏｍｐｌｅｘ  ａｔｔｒｉｂｕｔｅ）、４番目の形は、グループステートメントとして知られている。グループステートメントには、単純な属性、複雑な属性、グループステートメントの何れかの組合せが順に含まれている。尚、２番目の形の単純な属性の最後のセミコロン、及び、グループステートメントの括弧内のリストは、任意である。
【０１４０】
ステートメントの第１トークンは、キーワード（すなわち、予約語）とされるが、Ｌｉｂｅｒｔｙフォーマットでは、ライブラリベンダーが新しい単純な属性を定義することができ、キーワードについて限られたチェックのみが実行される。構文解析ツールによって、Ｌｉｂｅｒｔｙファイルが１又は複数のライブラリグループステートメントを含み、cell又はscaled_cellステートメントがライブラリ内にあることが確実となる。また、構文解析ツールは、セルインターフェースの一部と考えられるセルレベルステートメントを探す。その他、上記の一般的な構文に従ったステートメントは許可される。
【０１４１】
Ｌｉｂｅｒｔｙフォーマットファイルにはレイヤー名がないため、すべてのダイジェストは、非レイヤーデータであることを示すデフォルトのレイヤー番号である−１で記録される。
【０１４２】
前記リファレンスは、トークン／＊で始まり、トークン＊／で終わるＣスタイルのコメントを指定している。コメントは、ネストしないものとされている。セル内のコメントは、セルのダイジェストの一部として記録される。何れかのライブラリの外側にあるコメント、或いは、ライブラリステートメント内であるが、何れかのセルの外側にあるコメントは、ファイルヘッダコメントとして記録される。
【０１４３】
Ｌｉｂｅｒｔｙフォーマットは、異なる動作点で特徴付けられるセルのｓｃａｌｅｄバージョンを規定する手段を提供する。一実施形態では、これらのscaled_cellステートメントは、セルのｕｎｓｃａｌｅｄバージョンとは異なるＬｉｂｅｒｔｙファイルに現れるため、独立したセルとして扱われる。
【０１４４】
同じセル名が複数のライブラリに現れるため、構文解析ツールの一実施形態は、セル名をそのライブラリ名、及び、もしあればscaled_cell名で修飾する。例えば、cellに対しては、cmos_90nm.andx2、scaled_cellに対しては、cmos_90nm.andx2.slow_slowという具合である。名称の何れかの要素に「.」文字が含まれている場合、“cmos_90nm.v2”.andx2.“slow.slow”といったように、その要素を引用符で囲む。
【０１４５】
ライブラリにおいて最上位のステートメントには、ライブラリ内のすべてのセルの解釈に影響を与えるパラメータが多く含まれている。例えば、セル内の遅延又は電力値は、夫々、ナノ秒、ピコワットの単位で測定される。手で編集された、或いは、ファイルの断片からスクリプトで組み立てられたＬｉｂｅｒｔｙファイルには、セルと一致しないヘッダが含まれているかも知れない。この種のエラーを検出できるように、ライブラリレベルの属性のほとんどは、ダイジェスト記録のためのセルに統合が可能なヘッダブロックに集められる。バージョン毎に変更されやすいdateやversionといった属性は、このヘッダブロックからは除外される。
【０１４６】
cell又はscaled_cellステートメント内の属性及びグループステートメントの多くは、セルのインターフェースを規定している。すなわち、これらのステートメントに対して加えられた変更は、セルの機能に意味のある変更が行われたことを示唆する。完全なリストについては「注釈付のサンプルＬｉｂｅｒｔｙファイル」のセクションを参照。
【０１４７】
pin、bus、bundleグループステートメント内の属性にも、セルのインターフェースを規定しているものがある。しかし、これらのステートメント内のデータには、ライブラリのバージョンが上がる時に、変更が合理的に予想されるものがある。例えば、timingグループステートメントは、セルが機能的に同じであっても、プロセスパラメータが更新される時、或いは、レイアウトのある部分が変更される時はいつでも変更される。
【０１４８】
［Ｌｉｂｅｒｔｙファイルのソート］
Ｌｉｂｅｒｔｙファイルは順序依存ではない。セル内のステートメント又はセル内のグループステートメントは任意の順番で現れる。ステートメントが並べ替えられたライブラリ同士を比較するために、セル内のステートメントはソートされる。第１のソートキーは、ステートメントの冒頭のキーワードである。キーワードがどちらもユーザ定義の属性の場合（定義済みのＬｉｂｅｒｔｙキーワードではない場合）、文字の比較が行われ、アルファベット順で最初に来るキーワードを持つステートメントが、ステートメントリストの最初に来る。２つのステートメントのキーワードが一致すると、第２のソートキーがステートメントのパラメータリストとなる。パラメータは文字列として比較され、違いがあった場合、アルファベット順で最初に来るパラメータを持つステートメントがステートメントリストの最初に来る。一方のパラメータリストが短いことを除いて、すべてのパラメータが等しい場合、短い方のパラメータリストを持つステートメントが最初に来る。
【０１４９】
パラメータリストが一致すると、ステートメントは同一であると考えられる。ソートの間の実行時間を制限するため、実施形態によっては、グループステートメント内のステートメントを比較しない。安定したソートを用いるため、明らかな差異がある場合にのみステートメントの順番が変更される。
【０１５０】
［プロトタイプのＬｉｂｅｒｔｙ構文解析ツールの制限］
library、cell、scaled_cell名を含む、Ｌｉｂｅｒｔｙファイルのほとんどのトークンについては、大文字と小文字が区別される。例外はtrueとfalseであり、参考とするＳｙｎｏｐｓｙｓの構文解析ツールを実施したところ、trueとfalseについては大文字と小文字が区別されていない。
【０１５１】
構文解析ツールは、メモリの使用限度が、単一のcell又はscaled_cellのステートメントすべてに加えて、すべてのファイルヘッダステートメントを記憶するのに十分な程度であることを想定している。
【０１５２】
ステートメント構造の検証の他には、限られた構文チェックしか行われない。例えば、最上位のlibraryステートメントは複数あってもよい。ライブラリの構造がＬｉｂｅｒｔｙステートメントの構文に従っていない場合、或いは、最上位にlibraryステートメントが無い場合、エラーがレポートされ、ダイジェストは計算されない。
【０１５３】
セルの間に現れるヘッダステートメントは、ファイル内でそれらに続くダイジェストだけに統合される。完璧なダイジェスト記録のためには、すべてのライブラリヘッダステートメントが、cell又はscaled_cellステートメントよりも前に現れなけれなならない。
【０１５４】
インクルードファイルのサーチパスは利用できない（かつ、時間が経つと変化する）ため、インクルードファイルの命令は処理されない。
【０１５５】
文字列内の値は解釈されない。同一のツールがＬｉｂｅｒｔｙファイルを生成すること、及び、これらのツールは、例えば、番号が実際に変わらない限り、その番号を再フォーマットしないことが想定されている。
【０１５６】
キーワードリストが変わると、多くのダイジェストが再計算を必要とするため、ライブラリヘッダから除外されるか、或いは、セルインターフェースに含まれるキーワードリストは、一定であるべきであり、変更するにしても熟慮するべきである。
【０１５７】
ファイルヘッダのユニット番号は、例えば、1nsといった明確なトークン、或いは、“1mV”といった文字列の何れかでサポートされている。新しいバージョンのファイルでは、２つの表現を切り替えることはないと想定されている。
【０１５８】
［注釈付のサンプルＬｉｂｅｒｔｙファイル］
図８（ａ）〜８（ｄ）は、Ｌｉｂｅｒｔｙファイルの可能なヘッダ及びセルステートメントの一部抜粋を示している。ほとんどのヘッダ及びセルステートメントは図示されたように処理される。とりわけ、図８には、１つのグループステートメント全体が、同じダイジェストタイプとして記録される時は、キーワード、パラメータ（もしあれば）、波括弧のみが示されている。セルの外側にある属性及びステートメントはファイルヘッダダイジェストに追加される。セル内では、認識された属性とグループステートメントのみが、セルインターフェースの一部として記録されている。図で強調された幾つかの属性及びグループステートメントは、セルボディの一部として記録される。
【０１５９】
（ここでは示していないが、）デフォルトで、ほとんどのファイルヘッダステートメント（コメントトークンを除く）は、セルのインターフェースの一部として記録される。date、revision、commentといった属性は、Ｌｉｂｅｒｔｙファイルが変更される時に変わり易いため、セルのインターフェースの一部としては記録されない。
【０１６０】
多くの単純なcell及びpin属性は、セルインターフェースの一部であると考えられる。これらは上記の例に挙げられている。二重下線部、或いは、ここでは示していない箇所は、セルボディの一部と考えられる。
【０１６１】
尚、bus及びbundleグループステートメントには、ネストされたpinステートメントと共に、pinステートメントの単純な属性の何れかが含まれる。bus及びbundleステートメントの属性は、それらがあたかもpinステートメントにあるかのように記録される。ネストされたpinステートメントのコンテントは、それらが単独のピンであるかのように記録される。
【０１６２】
参考としているＳｙｎｏｐｓｙｓの構文解析ツールは、単純な属性では、「：」又は「＝」を使って、後に続く表現から変数名を分離する。以下は同じことを表している。
area = 5;
area : 5;
【０１６３】
文書では、「：」を使うため、すべての「＝」は、ダイジェストエンジンに送られる前に「：」に変換される。
【０１６４】
単純な属性及び複雑な属性のセミコロンは、記録されない。なぜなら、参考としているＳｙｎｏｐｓｙｓの構文解析ツールでは、それらのセミコロンを事実上任意としており、必ずしも必要としないからである。
【０１６５】
＜例２：Ｖｅｒｉｌｏｇファイルタイプ＞
Ｖｅｒｉｌｏｇは、集積回路設計で広く使われているシミュレーション及びレジスタ転送論理（ＲＴＬ）言語である。Ｖｅｒｉｌｏｇは、設計者によって共通に生成され、論理合成ツールによってコンパイルされるテキストベースのフォーマットである。Ｖｅｒｉｌｏｇによって設計者は、デザインを、相互接続したモジュールとして規定することができる。回路の機能性は、セルとして記録されたモジュールに規定される。セルインターフェースとして記録される入出力ポートを備える。論理合成ツールへのヒント（ｈｉｎｔ）は、モジュールヘッダ或いはステートメントに関連する属性に入れられる。
【０１６６】
この例では、Ｖｅｒｉｌｏｇファイルは、以下のファイル要素に関するコンテントダイジェストを有する。
・  ファイル
・  ファイルヘッダ
・  セルモジュールポート定義
・  セルモジュールのボディ
【０１６７】
内部のモジュール名を見つけるために、ファイルの検査を行う。ポート定義及びモジュールのボディに関して別々にダイジェストが計算される。これらは、空白を除く、個々のＶｅｒｉｌｏｇトークンに基づいている。
【０１６８】
ダイジェストは、ファイルのヘッダ（モジュール定義の外側の情報）、及び、ファイル全体に対して、計算、及び、返却される。このダイジェストには空白が含まれる。
【０１６９】
begin_keywordsがあっても、Ｖｅｒｉｌｏｇ２００５構文が推定される。ファイルのモジュール構造のみが解析されるため、このことは、ファイルのダイジェスト計算に影響を及ぼさない（例えば、キーワードは、記号とは異って解釈されることはない）。ファイルは、構文的には正しいと考えられる。
【０１７０】
マクロ置換を含む、コンパイラの命令は解釈されない。ファイルは、マクロ置換無しで有効なＶｅｒｉｌｏｇであると考えられる。一般的に言って、マクロは、定数の定義にしか用いられず、モジュールヘッダやＶｅｒｉｌｏｇステートメント等の合成構造を生成しないと想定されている。
【０１７１】
ダイジェスト計算時のインクルードパスが、コンパイル時のインクルードパスと異なることがあるため、インクルードファイルの命令は解釈されない。
【０１７２】
一実施形態において、合成命令は、コメントではなくＶｅｒｉｌｏｇ属性（“(*”及び“*)”）内にあると想定されている。モジュール又はマクロモジュールの宣言の直前に属性がある場合、そのダイジェストは当該モジュールのダイジェストに追加される。モジュールの宣言の外側のコメントは、モジュール自身の部分ではなく、ソースファイルの「ヘッダ」（非モジュールテキスト）の部分として考えられる。先行する属性の文字は、構文解析ツールがモジュールの宣言について知る前に検査されるため、それらの文字は、モジュール自身ではなく、ヘッダに関する「すべてがテキスト」のダイジェストに追加される。モジュールの外側のコメントは、ファイルヘッダダイジェストに追加される。モジュール、及び、マクロモジュールは同等のオブジェクトとして扱われる。一実施形態において、関数（ｆｕｎｃｔｉｏｎｓ）、ＵＤＰ、生成ブロックは、モジュール自身としてではなく、ソースファイルの「ヘッダ」の部分として考えられる。これらをモジュールの特別な形として扱い、プロシージャや関数の宣言等のＶＨＤＬの構成物（ｃｏｎｓｔｒｕｃｔｓ）の操作と同様に、セルとして記録することも可能である。ｌｉｓｔ＿ｏｆ＿ｐｏｒｔｓにおけるポート名は、ポートの何れかが“.”又は“{}”表記を使っている場合、適切にソートされない。
【０１７３】
ダイジェストは、セル内の空白に関しては計算されない。ファイルレベルの空白のダイジェストだけは計算される。セル内において、ダイジェストはファイルのトークン（適切な場合はコメントも含む）にのみ基づいている。
【０１７４】
［ＶｅｒｉｌｏｇＲＴＬファイル］
Ｖｅｒｉｌｏｇモジュールのボディの多くは順番に依存するため、モジュールパラメータのみがソートできる。その場合にも、モジュールは順序非依存のアーギュメントの仕様を用いて必ずしもインスタンス化されるとは限らないため、ソート後に見られるダイジェストの一致は、モジュール定義同士が完全に等しいことを表していないことも有り得る。したがって、Ｖｅｒｉｌｏｇファイルのソートは慎重に行わなければならない。デフォルトでは、Ｖｅｒｉｌｏｇファイルは、ユーザが-sortフラグを指定しない限り、ソートされない。
【０１７５】
Ｖｅｒｉｌｏｇファイルにはレイヤーはないため、セルに関するダイジェストはすべて、非レイヤーデータとしてレポートされる。
File "testfiles/verilog_test.v": Verilog format
Arguments: -mem 64 -nosort
5404c699  File
7c2a352d  File non-Whitespace
219b1881  File Whitespace
File Header (not sorted)
b290d605  File Header with Comments
(none)    File Header without Comments
b290d605  File Header Comments
Cell "DFF_X1" (not sorted)
ca436d2f  Cell with Comments
ca436d2f  Cell without Comments
(none)    Cell Comments
c102a525  Cell Interface non-Layer
0b41c80a  Cell Body non-Layer
【０１７６】
［Ｖｅｒｉｌｏｇフォーマットファイル：定義］
Ｖｅｒｉｌｏｇ言語仕様は、ＩＥＥＥ規格である。プロトタイプのＶｅｒｉｌｏｇの構文解析ツールは、ＩＥＥＥ規格１３６４−２００５における言語の定義に準拠している。これにはまだＶｅｒｉｌｏｇ−Ａ（アナログ）拡張は含まれていないが、Ｖｅｒｉｌｏｇ−Ａには容易に拡張が可能である。
【０１７７】
ＶｅｒｉｌｏｇＲＴＬの記述は、論理合成で使用されるが、言語そのものは、設計者の意図を判断するには十分ではない。論理合成ツールは、属性の使用を通じて最適化を導く手段を提供する。これらは、Ｖｅｒｉｌｏｇモジュール及びステートメントに先行する、或いは、その中に埋め込まれた、コメント状のトークンのシーケンスである。属性内のテキストは、合成指示を形成する。プロトタイプのＶｅｒｉｌｏｇ構文解析ツールは、Ｖｅｒｉｌｏｇ属性を解析し、当該属性を適切な言語構成物に割り当て、ダイジェストエンジンに送信するが、テキスト内部を解釈することはない。
【０１７８】
Ｖｅｒｉｌｏｇ言語に属性を追加する前に、合成命令がＶｅｒｉｌｏｇコメントを用いて規定される。構文解析ツールは、現在のところ、合成命令に関するコメントの使用をサポートしていないが、それも容易に拡張できる。
【０１７９】
［構文解釈］
Ｖｅｒｉｌｏｇファイルは、一続きの宣言とモジュールからなる。モジュールは、正則セルダイジェストツールにおけるセルであり、その他は、ファイルヘッダの一部として記録される。
【０１８０】
モジュールは、パラメータによって規定されたインターフェースを有する。パラメータ定義には、ポートリストとポート宣言リストという２つのスタイルがある。ポートリストに、モジュールステートメント内にポート名のみを有し、一方、ポート宣言リストは、ポートタイプも有する。
module a(b,c,d);  // list of ports
module a(input [7:0] b,output [8:0] c,reg d);  // port declarations
【０１８１】
モジュールへのインターフェースが、ポートリストを用いて既定される場合、宣言はモジュールボディに埋め込まれる。構文解析ツールは、宣言を探し、それらをセルインターフェースデータとしてダイジェストエンジンへ送信する。モジュールボディのその他のすべては、セルボディデータとしてダイジェストエンジンに送信される。
【０１８２】
モジュールへのインターフェースが、ポート宣言リストを用いて既定される場合、モジュールボディ内のすべてが、セルボディデータとしてダイジェストエンジンに送信される。
【０１８３】
構文解析ツールは、moduleとmacromoduleが等しいものであると想定している。macromoduleは、ダイジェストエンジンに送られる前に、moduleに変換される。
【０１８４】
マクロ定義は、解釈されない。マクロ定義は、構文解析ツールが利用できないインクルードファイル内に定義されているか、或いは、時間と共に変化するため、マクロの参照が展開されることはない。マクロは構文構成を含まないと想定されているため、マクロ参照が識別子又は番号と等しいと考えることによって、Ｖｅｒｉｌｏｇファイルを構文解析することは可能である。
【０１８５】
ライブラリ宣言及びインクルードステートメントは、ファイルヘッダデータとして記録される。インクルードファイルは読まれない。インクルードファイルサーチパスは、正則セルダイジェストプログラムでは利用できないためである。これもまた時間と共に変化し、既に計算されたファイルダイジェストを無効にする虞がある。
【０１８６】
関数、ユーザ定義プリミティブ（ＵＤＰ）定義、生成ブロック、設定の宣言は、更に解釈されることなくファイルヘッダダイジェストに追加されるか、或いは、ＶＨＤＬファイルと同様に扱われる。
【０１８７】
moduleキーワードの直前、或いは、モジュールボディ内の属性は、セルボディテキストとして記録される。他のすべての属性は、ファイルヘッダテキストとして記録される。
【０１８８】
［Ｖｅｒｉｌｏｇファイルのソート］
Ｖｅｒｉｌｏｇのステートメントの多くは、順序依存であるため、ソートできない。構文解析ツールは、モジュールボディのどの部分が順序非依存なのかを判断しようとはせず、モジュール定義のパラメータのみをソートする。モジュールのインスタンス化は、順序非依存のアーギュメントの仕様を使わないことも考えられるため、ソート後に見られるダイジェストの一致は、モジュール定義間の真に等しいことを表しているとは限らない。よって、Ｖｅｒｉｌｏｇファイルのソートは、慎重に行わなければならない。
【０１８９】
モジュールの入出力の宣言は、１つづつ、或いは、タイプが同じであればリストで規定される。例えば、以下の一連の宣言は等しい。
input signed [4:0] RN,CK,D,SE;
及び、
input signed [4:0] RN;
input signed [4:0] CK;
input signed [4:0] D;
input signed [4:0] SE;
【０１９０】
構文解析ツールは入出力パラメータの宣言を１番目の形から２番目の形に展開する。次に、それらの宣言は、パラメータの名称に従ってソートされる。
【０１９１】
構文解析ツールは、メモリ使用限度が、モジュールに関するポート定義のすべてを記憶するのに十分な程度であると想定している（ポート定義は多くても数百しかないため）。
【０１９２】
［プロトタイプＶｅｒｉｌｏｇ構文解析ツールの制限］
構文解析ツールは、ポートのすべてが名称で接続されていても（例えば、.Out(topB)）、モジュールのインスタンス化においてアーギュメントのリストのソートを行わない。
【０１９３】
モジュールボディ内の変数の宣言は、その変数がポートリスト内に規定される場合は、ポート宣言の意味を変更するために用いることができる。構文解析ツールは、これらの追加の宣言を探し出すことはしない。例えば、
module a(b);
input b;
wire signed [7:0] b;
endmodule
【０１９４】
ここで、入力ポートbのタイプは、wireの宣言によって変更されるが、wireの宣言はセルインターフェースダイジェストには追加されない。
【０１９５】
構文解析ツールは、ポートの宣言が「.」を含む外部名、又は、「{}」を含む連結を使っている場合、「ポート名」を割り当てない。通常、ポート名は、宣言内に配置され、ポートに関するダイジェストを記録する際は、インターフェースレコード名として使用される。外部名又は連結がある場合、宣言の第１トークンは、ポートのソートのための「名称」として使用される。
【０１９６】
モジュールポートリストにおけるパラメータ宣言（‘#’を使って規定された）は、セルボディダイジェストに追加される。
【０１９７】
マクロ定義は、ファイル内で見つけられると、ダイジェストエンジンに送られる。このマクロ定義は、ファイルヘッダ、或いは、セル内にあると考えられる。マクロ定義が、正則セルダイジェストツールが利用できない、或いは、時間と共に変化する別のファイルにあるかも知れないため、マクロ参照は展開されない。
【０１９８】
コンパイラの命令もまた解釈されない。
【０１９９】
数値リテラルは、解釈されることなく、ダイジェストエンジンに送られる。特に、そもそも正則形式に変換されることがない。例えば、指数内のプラス記号は任意であり、そのため、1e10は1e+10とは異なる。番号は再度印字されないため、1e10は1.0e10とも異なる。
【０２００】
構文解析ツールは、Ｖｅｒｉｌｏｇモジュールが階層的であると考えられる場合、判断を試みない。
【０２０１】
［注釈付のサンプルＶｅｒｉｌｏｇファイル］
図９は、上記の構文解析ルールの適用を示すＶｅｒｉｌｏｇファイルの注釈付の例である。
【０２０２】
＜例３：構造化バイナリファイルタイプ＞
この例では、カスタムの構文解析のない構造化バイナリファイルタイプを、非構造化バイナリファイルとして扱う。
【０２０３】
一般に、バイナリファイルの構造を知ることなく、ダイジェストは、すべてのバイトに関して割り当てられる。ダイジェストを構造化バイナリファイル内の特定のコンテントに割り当てるためには、データ構造が分かっている必要があり、かつ、構文解析ツールはそれに合わせて書かれている必要がある。
【０２０４】
＜例４：ＶＨＤＬファイルタイプ＞
ＶＨＤＬは、集積回路設計で広く使われているシミュレーション及びレジスタ転送論理（ＲＴＬ）言語である。設計者によって共通に生成され、論理合成ツールによってコンパイルされるテキストベースのフォーマットである。
【０２０５】
この例では、ＶＨＤＬファイルは、少なくとも以下のファイル要素に関するコンテントダイジェストを有する。
・  ファイル
・  ファイルヘッダ
・  エンティティブロック
・  アーキテクチャブロック
【０２０６】
このファイルは、モジュールに関するエンティティブロック及びアーキテクチャブロックを見つけるために検査される。モジュールに関して、エンティティとアーキテクチャに関して別々のダイジェストが計算される。或いは、以下のＶＨＤＬ「セル」の説明で述べるように、より詳細な（或いは、より大まかな）ダイジェストが計算可能である。これらのダイジェストは、空白を除く、個々のＶＨＤＬトークン（合成命令はコメントに含まれるため、コメントを含む）に基づいている。
【０２０７】
ダイジェストは、ファイルのヘッダ（モジュール定義の外側の情報）に関して、及び、ファイル全体に関して計算され、返却される。これらには、任意の空白が含まれる。ＵＳＥ命令からインクルードされたファイルは、検査されず、ダイジェストに追加されない。
【０２０８】
［ＶＨＤＬ  ＲＴＬファイル］
多くのＶＨＤＬ言語構成物は、エンティティ、設定、アーキテクチャ、プロシージャ、関数、コンポーネント、タイプ、サブタイプを含めて、「セル」の定義を満たすものと考えられる。これらの内何れか１つに対する変更は、デザインに対して広範囲に亘る影響を与え得る。構文解析の観点から、これら及び他のＶＨＤＬ宣言タイプもまた、ライブラリ内の第１クラスオブジェクトである。したがって、構文解析ツールは、（ＩＥＥＥ規格１０７６−２００２のＡｎｎｅｘ  Ａからの製造名を用いて）以下のＶＨＤＬ言語構成物に関するセルを生成する。
・  ｓｕｂｐｒｏｇｒａｍ＿ｄｅｃｌａｒａｔｉｏｎ（procedure又はfunction）
・  ｓｕｂｐｒｏｇｒａｍ＿ｂｏｄｙ（procedure又はfunction）
・  ｔｙｐｅ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｓｕｂｔｙｐｅ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｃｏｎｓｔａｎｔ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｓｉｇｎａｌ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｓｈａｒｅｄ＿ｖａｒｉａｂｌｅ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｆｉｌｅ＿ｄｅｃｌａｒａｔｉｏｎ
・  ａｌｉａｓ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｃｏｍｐｏｎｅｎｔ＿ｄｅｃｌａｒａｔｉｏｎ
・  ａｔｔｒｉｂｕｔｅ＿ｄｅｃｌａｒａｔｉｏｎ
・  ａｔｔｒｉｂｕｔｅ＿ｓｐｅｃｉｆｉｃａｔｉｏｎ
・  ｄｉｓｃｏｎｎｅｃｔｉｏｎ＿ｓｐｅｃｉｆｉｃａｔｉｏｎ
・  ｕｓｅ＿ｃｌａｕｓｅ
・  ｇｒｏｕｐ＿ｔｅｍｐｌａｔｅ＿ｄｅｃｌａｒａｔｉｏｎ
・  ｇｒｏｕｐ＿ｄｅｃｌａｒａｔｉｏｎ
【０２０９】
論理合成ツールへのヒントは、オブジェクトヘッダ或いはステートメントに関連するコメントに入れられる。したがって、組み合わされた「コメント付セル」ダイジェストは、恐らく、「コメント無しセル」ダイジェストよりも有用である思われる。
【０２１０】
ステートメントＶＨＤＬの多くは、順序依存であるため、宣言内のパラメータのみがソート可能である。その場合にも、アーキテクチャ、コンポーネントは、順序非依存のアーギュメントの仕様を用いて必ずしもインスタンス化されるとは限らず、そのため、ソート後に見られるダイジェストの一致は、完全に等しいことを表しているわけではない。ＶＨＤＬファイルのソートは慎重に行わなければならない。デフォルトでは、ＶＨＤＬファイルは、ユーザが-sortフラグを規定しない限り、ソートされない。
【０２１１】
ＶＨＤＬファイル内にはレイヤーが無いため、セルに関するすべてのダイジェストは、非レイヤーデータとしてレポートされる。
File "testfiles/timing_b.vhd": VHDL format
Arguments: -mem 64 -nosort
b116b16a  File
0cafc41a  File non-Whitespace
704d8ab4  File Whitespace
File Header (not sorted)
9f21a1ef  File Header with Comments
d279ff8a  File Header without Comments
4d585e65  File Header Comments
d279ff8a  File Header non-Layer
Cell "vital_timing.constant.edgesymbolmatch" (not sorted)
63c5ce8d  Cell with Comments
63c5ce8d  Cell without Comments
(none)    Cell Comments
63c5ce8d  Cell Interface non-Layer
Cell "vital_timing.function.vitalcalcdelay.1" (not sorted)
cd370359  Cell with Comments
cd370359  Cell without Comments
(none)    Cell Comments
be204681  Cell Interface non-Layer
731745d8  Cell Body non-Layer
【０２１２】
上記に見られるように、レポートされたセル名には、（もしあれば）オブジェクトが定義されたライブラリ、オブジェクト（定数、関数、エンティティ、アーキテクチャ等）のタイプ、オブジェクト名、オーバーロードを解決するために使用される曖昧性解消番号が含まれる。例えば、関数がオーバーロードされるとは、パラメータのタイプが異なる一連の関数に同じ名称を用いることを意味する。論理合成ツールは、すべての考えられる一致を調べることにより、適切な関数を選択する。
【０２１３】
正則セルダイジェストツールは、完全なＶＨＤＬ構文解析ツールを実行しない。特に、正則セルダイジェストツールは、記号テーブルを維持しないため、オブジェクト名のみに基づいた名称を持つセルにダイジェストを単純に記録するだけである。オーバーロードされたオブジェクトがファイルに追加される、或いは、ファイルから削除されると、曖昧性解消番号が変わる可能性があるため、ユーザのマッチングソフトウェアは、ダイジェストに基づいて適切なセルを選択する必要がある。
【０２１４】
［ＶＨＤＬフォーマットファイル：定義］
ＶＨＳＩＣ  Ｈａｒｄｗａｒｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＶＨＤＬ）は、１９８０年代に、ハードウェアシステム記述言語として米国国防省のために規定された。現在は、論理合成のためのＲｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌａｎｇｕａｇｅとしても使用されている。
【０２１５】
ＶＨＤＬは、テキストベースの言語であり、設計者はこれを用いて、アーキテクチャで実装される相互接続されたエンティティとして、デザインを規定することができる。ＶＨＤＬは、非常に複雑な言語で、デザインの仕様に影響を及ぼす多くの言語構成物からなる。この言語構成物はすべて、名称がタイプで修飾された（例えば、entity.full_adder）個別のセルとして記録される。
【０２１６】
ＶＨＤＬの言語仕様は、ＩＥＥＥ規格である。プロトタイプのＶＨＤＬ構文解析ツールは、ＩＥＥＥ規格１０７６−２００２における言語定義に準拠している。これには、ＶＨＤＬ−ＡＭＳ（アナログ）拡張は含まれていない。
【０２１７】
ＶＨＤＬ  ＲＴＬの記述は、論理合成で使用されるが、言語そのものは、設計者の意図を判断するには十分ではない。コメントに埋め込まれた合成命令は、最適化を導くＶＨＤＬテキストに追加されることがよくある。これらの命令は、それに従う言語構成物と共に記録される。Ｖｅｒｉｌｏｇ属性に相当するものは存在しない。
【０２１８】
パッケージの外側にあるコメントは、ファイルヘッダダイジェストに追加される。
【０２１９】
［構文解釈］
上述したように、多くのＶＨＤＬ言語構成物は、エンティティ、設定、アーキテクチャ、プロシージャ、関数、コンポーネント、タイプ、サブタイプを含む「セル」の定義を満たすと考えられる。
【０２２０】
ＶＨＤＬは、名称のオーバーロード（所定の名称を複数のオブジェクトにマップすること）をサポートしている。コンパイラは、コンテクスト及びタイプ情報を用いて適切なオブジェクトを選択する。
【０２２１】
言語定義は、これら２つの概念に大きく依存しているため、インクルードされたファイルを利用可能とせずにＶＨＤＬファイルを完全に構文解析するというエラーを起こしやすい。プロトタイプの正則セルダイジェスト構文解析ツールは、論理合成用に設計されていないため、また、自身が機能するコンテクスト（例えば、インクルードファイル）が時間とともに変化するため、コンテクストに依存しない構文解析が可能な、僅かに簡略化された言語仕様を使用している。
【０２２２】
ＶＨＤＬは、演算子オーバーロード（タイプとパラメータが異なる同じオブジェクトが複数バージョン存在すること）もサポートしている。例えば、複数の乗算演算子が存在することが可能である。
【０２２３】
最後に、所定のデザインエンティティに関して、複数のアーキテクチャを記述することができる。これらは交換可能に設計されており、設計者は、モジュールをインスタンス化する際にどのアーキテクチャを用るかを規定する。
【０２２４】
ＶＨＤＬデザインのすべてのアスペクトに関して正則セルダイジェストを生成するには、曖昧性を解消する必要がある。２つから４つの部分からなる符号化された名称が、セルとして記録されたオブジェクトに割り当てられる。
・各パッケージ内に記憶されたオブジェクトに対するパッケージ名
・オブジェクトのタイプ（例えば、architectureやfunction）
・設計者によって規定されたオブジェクト名
・名称でオーバーロードされたオブジェクトに関する末尾の番号
【０２２５】
例えば、vital_timing.constant.edgesymbolmatchは、vital_timingというパッケージ内のedgesymbolmatchという定数を表し、vital_timing.procedure.vitalerror.1は、このパッケージ内のvitalerrorという名称が付与された第２プロシージャを表している。正則セルダイジェストは、ファイル単位で計算されるため、ユーザのソフトウェアは、ダイジェストをデータベースに格納する際に更に名称の曖昧さを無くす必要がある。このことは、特に、個別の仕様とボディを有するプロシージャ及び関数について言える。構文解析ツールは、それが仕様を持つのかボディを持つのか、かなり後になるまで（パラメータリストの後まで）分からず、その時までには、セル名はダイジェストエンジンに渡されている。
【０２２６】
ＶＨＤＬの仕様では、オブジェクト定義をネストすることもできる（例えば、プロシージャ内の関数）。オブジェクト定義は無限にネストすることが可能であるため、また、その範囲は（オブジェクトを外側から見えなくする）包含オブジェクトに限られるため、こうしたオブジェクトに関しては個別のセルが生成されない。オブジェクトは、包含オブジェクトのセルボディの一部として記録される。
【０２２７】
ＶＨＤＬ仕様は、ＩＳＯ／ＩＥＣ８８５９−１規格で定義された８ビット文字のセットを用いる。構文解析ツールは、すべての有効な８ビット文字を完全にサポートしている。
【０２２８】
ＶＨＤＬは、拡張子を除いて大文字と小文字を区別しない。構文解析ツールは、拡張子を除くすべてのトークンを、ダイジェストエンジンに送る前に小文字に変換する。
【０２２９】
［ＶＨＤＬファイルのソート］
ＶＨＤＬのステートメントの多くは、順序依存であるため、ソートできない。構文解析ツールは、アーキテクチャ又はサブプログラムのボディのどの部分が順序非依存なのかを判断しようとはせず、パラメータのみをその宣言内でソートする。インスタンス化は、順序非依存のアーギュメントの仕様を使わないため、ソート後に見られるダイジェストの一致は、実際の一致を表していない。したがって、ＶＨＤＬファイルのソートは、慎重に行わなければならない。
【０２３０】
パラメータの宣言は、１つづつ、或いは、型が同じであればリストで規定される。例えば、以下の一連の宣言は等しい。
X,Y,Cin: in Bit;
Cout,Sum: out Bit;
及び、
X: in Bit;
Y: in Bit;
Cin: in Bit;
Cout: out Bit;
Sum: out Bit;
【０２３１】
構文解析ツールはパラメータの宣言を１番目の形から２番目の形に展開する。次に、それらの宣言はパラメータの名称に従ってソートされる。
【０２３２】
entityは１又は複数のarchitecturesに対するインターフェースの仕様であるため、entity内のすべては、isの後のエンティティステートメントであっても、インターフェースの一部であると考えられる。
【０２３３】
最上位のオブジェクト（セル）の名称は、名称は異なるが等しいセルのマッチングができるように、ダイジェストエンジンには送られない。最上位のオブジェクト内の変数の宣言（サブプログラムの宣言を含む）の名称は、セルインターフェーステキストとして記録されるが、これらの変数内の宣言の名称は記録されない。例えば、図１０（ａ）〜１０（ｂ）の注釈付のサンプルファイルを参照。
【０２３４】
［プロトタイプのＶＨＤＬ構文解析ツールの制限］
垂直タブ文字と改ページ文字は、ファイルレベルのダイジェストに追加される前であっても、改行文字に変換される。キャリッジリターンとラインフィードの組合せは、ファイルレベルのダイジェストに追加される前に、単一のラインフィード文字に変換される。
【０２３５】
構文解析ツールは、定数を組み合わせようとしない。例えば、文字列リテラルの連結は、行われない。“abcdef”は、“abc”&“def”と同じダイジェストを持たない。
【０２３６】
ダイジェスト計算時のインクルードパスはコンパイル時のインクルードパスと異なることが考えられるため、インクルードファイル命令（library節とuse節）は解釈されない。
【０２３７】
プロシージャセルと関数セルにおけるパラメータリストはソートされない。プロシージャ又は関数内のパラメータは別のファイルで宣言されているため、構文解析ツールにはそれらの名称が分からない。これは、パラメータが＝＞を使用した連想リスト（ａｓｓｏｃｉａｔｉｏｎ  ｌｉｓｔ）にある場合でも同様である。
【０２３８】
数値リテラルは、解釈無しでダイジェストエンジンに送られる。特に、最初に、正則形式に変換されることはない。例えば、指数におけるプラス記号は任意であり、そのため、1e10は、1e+10とは異なる。数字は再度印字されないため、1e10もまた1.0e10とは異なる。
【０２３９】
構文解析ツールは、ＶＨＤＬオブジェクトが階層的であると考えられる場合、判断を試みない。
【０２４０】
［注釈付サンプルＶＨＤＬファイル］
図１０（ａ）〜１０（ｂ）は、注釈付サンプルＶＨＤＬファイルを示している。
【０２４１】
尚、architecture MC68000において、第１レベルのネストされた関数（bclr_d）はインターフェーステキストとして記録され、一方、第２レベルのネストされた関数（nested）はインターフェーステキストとしては記録されない。これは、プロシージャVitalWireDelayにおける変数Delayのように、bclr_dがインターフェース変数であると考えられているためである。ネストされたプロシージャもまた、別個のセルとして記録されない。どちらもarchitecture MC68000の一部として考えられている。
【０２４２】
＜例５〜６：ＯＡＳＩＳ及びＧＤＳＩＩファイルタイプ＞
この例では、同じファイル要素を持つ、ＯＡＳＩＳ及びＧＤＳＩＩファイルタイプを一緒に記述している。これらのファイルタイプは、以下のファイル要素に関するコンテントダイジェストを有する。
・  ファイル
・  ファイルヘッダ
・  レイヤー単位の幾何学的オブジェクト
・  レイヤー単位の非幾何学的オブジェクト
・  下位のセルへの参照
・  他の下位のセルを指すブール型フラグ
【０２４３】
データベースは、内部のセル名を見つけるために検査される。存在するセルに関して、以下が計算される。
・すべての幾何学的オブジェクトのレイヤー単位のダイジェスト（ポリゴン、矩形等）
・すべての非幾何学的オブジェクトのレイヤー単位のダイジェスト（テキストポイント等）
・下位セルへの参照等のすべての他のオブジェクトに関するダイジェスト
・セルが下位セルへの参照を有するかを示すブール型フラグ
【０２４４】
オプションとして、サイズが小さいセル及び中間のセルにおけるデータは、データの順番が異なることによってダイジェストに差分が生じないように、ダイジェスト計算の前にソートされる。ユーザは、このオプションに関してメモリ利用限度を設定することができる。
【０２４５】
ＯＡＳＩＳの繰り返し、及び、ＧＤＳＩＩのアレイ参照は、繰り返し分析が異なることによってダイジェストに差分が生じないように、ダイジェスト計算の前に展開される。
【０２４６】
ダイジェストは、ファイルのヘッダ（セル定義の前の情報）と、ファイル全体に関して計算され、返却される。ＧＤＳＩＩファイルに関しては、ファイルは、構文的には正しいと想定されている。
【０２４７】
ストラクチャ（セル）の生成回数及び変更回数は、コメントとして記憶される。２つのセルにおいて、これらの回数が異なり、他の点で同一である場合、セルダイジェスト及びコメントダイジェストは異なるが、すべてのレイヤーダイジェストは同一である。
【０２４８】
尚、ＧＤＳＩＩ又はＯＡＳＩＳセルには「ヘッダ」（セルに対するインターフェース）の一部と考えられるデータがない。そうしたデータは、外部ツールによって生成され、他の場所（例えばＬＥＦ）に記憶されると想定されている。ＧＤＳＩＩ又はＯＡＳＩＳファイルに関しては「空白」ダイジェストが計算されない。ストラクチャ参照（ＳＲＥＦかつＡＲＥＦ）は、−１のインデックスを持つ非レイヤーデータに関するダイジェストの一部としてレポートされる。ＧＤＳＩＩ又はＯＡＳＩＳポリゴンのソート、及び、ＧＤＳＩＩ又はＯＡＳＩＳポリゴンの統合（重複除去）もまた、ダイジェスト計算の前に行うことが可能である。
【０２４９】
［ＯＡＳＩＳレイアウトファイル］
ＯＡＳＩＳファイルは、レイアウトを規定するための構造化バイナリファイルである。そのフォーマットには、繰り返し及び圧縮データブロック等、ファイルに必要なスペースを減少させる多くの様々な方法がある。これらの方法によって、セル内にデータが現れる順番を変更することや、或いは、データ（例えば、RECTANGLE対CTRAPEZOID）を表すために使われるデータ構成さえも変更が可能である。内部的に、表現に一貫性を持たせるため、すべての幾何学的構成はPOLYGONレコードに変換され、繰り返しは展開される。
【０２５０】
十分なメモリ又はディスクスペースが利用可能な場合、必要に応じて、ＯＡＳＩＳファイルデータはデフォルトでソートされる。データは、まずレイヤーでグループ化され、次に位置（ｐｏｓｉｔｉｏｎ）でグループ化されて、データが元々セル内でどのような順番であったかに拘わらず、同じダイジェストが生成される。データがソートされ、セル内にＯＡＳＩＳプロパティがない限り、ユーザのソフトウェアは、ＯＡＳＩＳセルとそれらと同等のＧＤＳＩＩ表現間でダイジェストのマッチングを行うことができる。
【０２５１】
浮動小数点の丸め誤差を回避するために、ダイジェストは、セル内のレイアウトデータの整数座標に基づいて計算される。ユーザの所望するデザイングリッドは時間と共に変化するため、正則セルダイジェストは、ユーザが-gridコマンドラインオプションを用いて規定する、より小さなグリッドに基づいて計算される。ユーザは、将来のデザイングリッドがすべて確実にこのグリッドの整数倍となるように、グリッドを慎重に選択しなければならない。デフォルトでは、このグリッドは、１ナノメータ（１．０ｅ−９メータ）となっている。０．５ナノメータ、或いは、０．２５ナノメータ等、もっと小さい値を設定するのが最良の選択であると考えられる。しかし、グリッドが小さすぎると、３２ビットマシン上で整数演算のオーバーフローが起きてしまう。
【０２５２】
すべての繰り返しは、表現の一貫性を保つために展開されるため、正則セルダイジェストの計算の実行時の性能は、同じサイズのファイルでもかなり変動する。
【０２５３】
ＯＡＳＩＳファイルに関するダイジェストレポートの一部をここに示す。
Cell "Structure_1" (not sorted)
f64ce851  Cell with Comments
f64ce851  Cell without Comments
(none)    Cell Comments
20b84e54  Cell Body non-Layer
e03bf9d2  Cell Body Layer 3
fda35715  Cell Body Layer 42
cb6c08c2  Cell Body non-Geometric Data Layer 3
【０２５４】
この例では、ソートは要求されておらず、このことはセル名の後ろでレポートされている。ＯＡＳＩＳセルでは、セルコメントデータとして記録されるものがないため、ダイジェストは、“(none)”とレポートされている。更に、非レイヤーデータとして記録されたストラクチャ参照と、レイヤー３及び４２に関して記録された幾何形状がある。最後に、レイヤー３に関する非幾何学的データ（１又は複数のTEXTレコード）がある。
【０２５５】
［ＯＡＳＩＳフォーマットファイル：定義］
オープン・アートワーク・システム・インターチェンジ・スタンダード（ＯＡＳＩＳ）フォーマットは、ＧＤＳＩＩに代わるフォーマットとして、Ｓｅｍｉｃｏｎｄｕｃｔｏｒ  Ｅｑｕｉｐｍｅｎｔ  ａｎｄ  Ｍａｔｅｒｉａｌｓ  Ｉｎｔｅｒｎａｔｉｏｎａｌ（ＳＥＭＩ）の委員会により開発された。ＯＡＳＩＳでは、数値に関する１６ビット及び３２ビットの制限が除去され、レイアウトファイルのサイズが１０倍にまで拡張された。プロトタイプのＯＡＳＩＳ構文解析ツールは、ＳＥＭＩ規格Ｐ３９−１１０５（２００５年１１月）に記載された仕様に準拠している。ここでは、名称テーブルがサポートされている。
【０２５６】
ＯＡＳＩＳはバイナリフォーマットであるため、明瞭性のために、本説明では、ＯＡＳＩＳの仕様に挙げられたレコード名を用いる。
【０２５７】
［ＯＡＳＩＳファイルの構文解釈］
ＯＡＳＩＳの仕様は、任意精度の整数と浮動小数点数を扱うことを想定している。しかし、任意精度の演算のための演算パッケージは遅く、設計自動化団体では広く使われていない。プロトタイプの構文解析ツールは、ネイティブ整数（３２ビットモードでコンパイル時の３２ビット、６４ビットモードでコンパイル時の６４ビット）と、ＩＥＥＥ倍精度浮動小数点数（６４ビット）を用いる。これらの限界を超える数がファイル内に存在する場合、エラーが記録される。
【０２５８】
また、ＯＡＳＩＳの仕様は、符号無し整数、符号有り整数、比、逆数、浮動小数点等の様々な数の表現を扱うことを想定している。すべての数は、比較のために正則形式（整数値に関してはネイティブ整数、及び、浮動小数点値に関しては倍精度浮動小数点数）に変換される。これにより、異なるツール（例えば、５／２や２．５）によって書き込まれた数のマッチングが可能となる。
【０２５９】
同様に、すべてのポイントリスト（例えば１デルタリスト）は、ダイジェストが計算される前に、Ｘ／Ｙ座標ペアリストに完全に展開される。
【０２６０】
デザインツールは、レイアウトセルの幾何形状を表すために使用されるＯＡＳＩＳ要素をかなり自由に選択することができる。レイアウトのエディタは、一般に、設計者の選択（例えば、PATH対POLYGON）を順守するが、最終的な出力は、屈曲部（ｂｅｎｄ）でのPATHの定義に固有な曖昧性を軽減するために、同じPOLYGONを有する可能性がある。また、こうしたツールは、反時計回りから時計回りにPOLYGONの「曲がりくねった方向」を変更することも考えられる。こうした問題を防ぐため、すべての幾何学的要素は、正則セルダイジェスト計算のための正則表現に変換される。
・  RECTANGLE、PATH、TRAPEZOID、CTRAPEZOID、CIRCLEの各要素は、同等のPOLYGONレコードに変換される。
・  POLYGONポイントリストは、結果的に得られたポリゴンが反時計回りの曲がりくねった方向を有する場合、反転される。
・  リストの第１ポイントには、最も左下のポイントが選ばれる。
【０２６１】
PLACEMENTレコードにフリップ（ｆｌｉｐ）がある場合、そのフリップはＧＤＳＩＩのSTRANSレコード（ビットアレイ）のように記録される。
【０２６２】
PLACEMENTオブジェクトが数値セル参照を使っている場合、その数値は、対応するセル名で置き換えられ、セル名のみがダイジェストに送られる。
【０２６３】
ＯＡＳＩＳ仕様は、すべての構成の繰り返しを扱うことを想定している。各種ツールは様々な繰り返しの最適化方法を選択する。データは、どのように並んでいようと等しいため、正則化のために、すべての繰り返しは、単一のオブジェクト参照に展開される（例えば、矩形やPLACEMENTレコード）。こうした理由により、ファイルサイズの関数である実行時間性能は保証できない。１０億のポリゴンに展開する繰り返しが行われる小さなファイルですら、かなりのＣＰＵ時間を要する。
【０２６４】
また、ＯＡＳＩＳファイルは、古いＧＤＳＩＩフォーマットファイルと共存する。ＯＡＳＩＳは、繰り返されるオブジェクト参照を様々な方法で記述するため、繰り返しが展開されないと、繰り替えされるPLACEMENTオブジェクトとＧＤＳＩＩAREFとのマッチングは不可能である。
【０２６５】
尚、幾つかの実施形態では、ダイジェストは、下層にある幾何形状ではなく、ＯＡＳＩＳファイル内のオブジェクトに基づいて計算される。ダイジェストの計算前には、重複の除去は行われない。
【０２６６】
ＯＡＳＩＳフォーマットは、仕様の「拡張」の必要性を取り除くように設計されている。ＯＡＳＩＳファイルが仕様書に従っていない場合は、構文解析ツールはエラーを返す。
【０２６７】
ＯＡＳＩＳレイヤーは、主に、番号でインデックスが付けられる（すべての幾何学的構成は、レイヤー番号を用い、レイヤー名は用いない）。レイヤー名（もしあれば）の番号へのマッピングは、現在のところ、構文解析ツールによって返却されない。
【０２６８】
ＯＡＳＩＳファイル内の座標は、例えば１ナノメータ（１．０ｅ−９メータ）のグリッドを用いて、ファイルの冒頭で規定される。セル内では、すべての座標がこのグリッドを単位として整数となるように定義されている。ファイルグリッドは変わる可能性があるが、最終のマスクデータには影響を及ぼさない。例えば、標準グリッドが１ナノメータであっても、インポートされたデザインテンプレートブロックは、５ナノメータのグリッドを用いて規定される可能性がある。ユーザのソフトウェアは、より小さいグリッドを使うために、セルの整数座標を５倍にスケーリングして、すべてのインポートされたデータを変換する。
【０２６９】
確実に正則化を行うため、ＯＡＳＩＳファイルにおけるすべての幾何形状は、内部の正則セルダイジェストグリッドが使えるようにスケーリングされる。ユーザは、すべての将来のデザインにおいて使用されるＯＡＳＩＳファイルグリッドが互換性を持つように、このグリッドを慎重に選択しなければならない。例えば、現在のデザイングリッドが５ナノメータとすると、１ナノメータか、或いは、０．５ナノメータのダイジェストグリッドを用いるのが最良の選択であると思われる。
【０２７０】
正則セルダイジェストグリッドの値は、ＯＡＳＩＳ構文解析ツールに渡され、ＯＡＳＩＳファイルグリッドが正則セルダイジェストグリッド値の整数倍でない場合、エラーが返却される。
【０２７１】
PLACEMENTレコードを持つストラクチャは、ダイジェストのレポートのために階層的に記述される。
【０２７２】
［ＯＡＳＩＳファイルのソート］
上述のように、ＯＡＳＩＳファイルにおける配列ストラクチャ参照（ａｒｒａｙｅｄ  ｓｔｒｕｃｔｕｒｅ  ｒｅｆｅｒｅｎｃｅｓ）を規定する方法は、ＧＤＳＩＩファイルとは異なる。また、ベンダーが異なれば、繰り返しの最適化方法も異なる。最後に、セル内の幾何学的オブジェクトは、ファイルの意味を変えることなく、いつでも順序の変更が可能である。したがって、ＯＡＳＩＳレイアウト同士、或いは、ＧＤＳＩＩレイアウトとＯＡＳＩＳレイアウトとを効果的に比較するには、ソートが必要である。このため、ＧＤＳＩＩレイアウト及びＯＡＳＩＳレイアウトのソートは、デフォルトで使用可能となっている。
【０２７３】
幾何学オブジェクトが正則形式に変換された後、ソートのために、以下のように別のオブジェクトとの比較が可能となる。
・  レイヤー名が第１キーとなる。レイヤー番号の若いものが最初に来る。
・  （ＧＤＳＩＩレコードタイプを用いた）要素タイプが第２キーとなる。下位の要素タイプが最初に来る。
・  要素のＸＹ座標（もしあれば）が第３キーとなる。座標は、１つづつ比較され、所定のエントリーに対して最も左下の点を持つ要素が最初に来る。
・  配置変換（すなわち、フリップ）が存在する場合は、整数に変換されたビットベクターが比較され、「最も小さい」のものが最初に来る。
・  次に、DATATYPE値が比較され、最も値の小さいものが最初に来る。
・  レコードが配置である場合、セル名がアルファベットで比較され、最も若いものが最初に来る。
・  次に、MAG値（もしあれば）が比較され、最も小さいものが最初に来る。
・  次に、ANGLE値（もしあれば）が比較され、最も小さいものが最初に来る。
・  最後に、PROPERTY値が１つづつ比較される。
【０２７４】
最初の３つの比較（レイヤー名、要素タイプ、ＸＹ位置）のみが使われると予想されるため、他の比較の順序は、ほぼ任意とすることができる。
【０２７５】
ソートの基準は、実質、ＧＤＳＩＩに用いるものと同じである。ＯＡＳＩＳに適用されないフィールドは上記から省かれている。ＧＤＳＩＩで、ＯＡＳＩＳにおけるアナログを持たないフィールド（例えばPLEX）、或いは、ＯＡＳＩＳでは異なるフィールド（例えばプロパティ）を使うと、異なるフォーマット間でのセルのマッチングの妨げとなる。
【０２７６】
ソートが要求されると、セル内のレコードは、セルの終端に達するまで、或いは、あまりに多くのセルデータがメモリに記憶されたためにメモリの使用限度を超えるまで、集められる。セルの終端に達すると、或いは、メモリの使用限度を超えると、記憶されたセルレコードは、実質的には性能に不利な条件で、元の順番でダイジェストモジュールに送られるか、或いは、ディスクソートを用いてソートされる。メモリテストはセル単位で行われるため、ソートされるセルもあれば、ソートされないセルもある。セルは、ソートされたかどうかについてマークされる。この情報は、ダイジェストレポートにおいて、ＡＰＩを通じて利用可能である。
【０２７７】
ファイルヘッダオブジェクトはソートされない。
【０２７８】
［プロトタイプのＯＡＳＩＳ構文解析ツールの制限］
ＯＡＳＩＳファイルはＳＥＭＩ  Ｐ３９の構文及び意味に準拠していると考えられる。エラーは許されない。エラーは１つのみレポートされる。構文解析ツールは、１番目のエラーを過ぎて処理を継続することはない。
【０２７９】
現在のところ、XELEMENT、XGEOMETRY、XNAMEの各レコードは、記録されずに破棄されている（ファイルレベルのダイジェストを除く）。
【０２８０】
PADレコードは記録されずに破棄される（ファイルレベルのダイジェストを除く）。
【０２８１】
ファイル内の名称テーブルに使用されているメモリは測定されない。これにより、実質的なメモリ使用量が、要求された限度を超える可能性がある。
【０２８２】
要素のプロパティは、要素自身と同じタイプ（幾何学的データ）で記録される。ＯＡＳＩＳのPROPERTYレコードの定義は、ＧＤＳＩＩのPROPATTRレコードと著しく異なっており、ＯＡＳＩＳとＧＤＳＩＩとで、プロパティ（互換性のあるS_GDS_PROPERTYを除く）を持つ要素を含むセルをマッチングすることは不可能である。
【０２８３】
LAYERNAMEテーブル（もしあれば）は、ＯＡＳＩＳ構文解析ツールによって返却されないため、レイヤー番号情報のみがダイジェストと共に使用できる。
【０２８４】
面積がゼロであるポリゴンは、そのポイントが「誤った」順番で描かれていた場合、反転されない。これにより、面積がゼロであるポリゴンを含むＧＤＳＩＩファイルとＯＡＳＩＳファイルの比較が難しくなることがある。
【０２８５】
［注釈付サンプルＯＡＳＩＳファイル］
図１１は、注釈付のサンプルＯＡＳＩＳファイルである。ＯＡＳＩＳはバイナリファイルフォーマットであるため、ＯＡＳＩＳレコード名が使用され、個々の要素の中には簡潔にするために省略されている部分もある。要素内のフィールドのすべては同じ記録タイプであるため、一般性の喪失はない。
【０２８６】
正則化のため、RECTANGLE、PATH、TRAPEZOID、CTRAPEZOID、CIRCLEの各要素は、時計回りの巻き付け（ｗｒａｐ）で同等のPOLYGON要素に変換される。したがって、これらの要素タイプは図示されていない。ポイントリストの第１ポイントは、最も左下の点が選択される。ＯＡＳＩＳセルがＧＤＳＩＩセルに対して一致させることができるように、ＧＤＳＩＩのBOUNDARYレコード番号が使われる。
【０２８７】
TEXT要素は、TEXTしか使用していないＯＡＳＩＳセルとＧＤＳＩＩセルのマッチングが可能となるように、ＧＤＳＩＩのTEXT要素番号を用いて記録される。尚、ＯＡＳＩＳには、ＧＤＳＩＩのNODE要素に対するアナログは存在しない。
【０２８８】
CBLOCKレコードはダイジェストを計算する前に展開されるため、正則セルダイジェストの一部とはならない。正則セルダイジェストは、CBLOCKレコードが存在するか否かに拘わらず、同じである。
【０２８９】
ファイルレベルのダイジェストは、CBLOCKレコードを展開させることなく、計算される。
【０２９０】
名称テーブルがファイル内に存在するか否かに拘わらず、名称及びその他の文字列は、それらが使われたレコードと共に存在するかのように記録される。名称及びその他の文字列テーブル自体は、どの正則セルダイジェストにも追加されない。名称レコードに関するプロパティ（例えば、CELLNAME）は、ファイルヘッダの非レイヤー幾何学ダイジェストに追加される。
【０２９１】
すべての幾何学的レコードは、ダイジェストエンジンに送られる前に、完全に展開される。モーダル変数が暗黙的に使用されることはない。これは、ＧＤＳＩＩファイルとのマッチングだけでなく、ソートにも有用である。このため、XYRELATIVEとXYABSOLUTEレコードは、どの正則セルダイジェストの一部でもなく、これらは単に、（前のオブジェクト又は絶対座標に関して）XY座標がどのように解釈されるかを決定するだけである。
【０２９２】
プロパティは、それらの直前のオブジェクトと共に記録される。そのオブジェクトがレイヤー番号を持っている場合、それらは、そのレイヤー番号に関して記録される。ファイルの冒頭の（つまり何れかのセルの外側の）プロパティは、ソートされない。それらは、出現した順に記録される。
【０２９３】
ダイジェストエンジンに送られる前に、タイプ１７（直交回転）のPLACEMENTオブジェクトは、ＧＤＳＩＩにおける定義に一致するように、タイプ１８（任意回転）のPLACEMENTオブジェクトに変換される。
【０２９４】
ストラクチャのインターフェース（例えば、ｂｏｕｎｄｉｎｇ  ｂｏｘ、ａｂｕｔｍｅｎｔ  ｂｏｘ、ｒｏｕｔｅｒ  ｐｉｃｋｕｐ  ｐｏｉｎｔ）に関しては産業規格がないため、セルヘッダデータとして記録されるものは何もない。
【０２９５】
＜例６（続き）：ＧＤＳＩＩレイアウトファイル＞
ＧＤＳＩＩファイルはレイアウトを規定するために使用される構造化バイナリファイルである。ＧＤＳＩＩファイルの記述に使用されるツールに応じて、セルにデータが現れる順番が変わり、幾つかの構成（特にPATH）は、より明確な表現（BOUNDARY）に変換される。内部的に、表現に一貫性を持たせるため、すべての幾何学的構成はBOUNDARY （ポリゴン）レコードに変換され、配列参照（AREF）はストラクチャ参照（SREF）の同等のシーケンスに展開される。
【０２９６】
十分なメモリ又はディスクスペースが利用可能な場合、必要に応じて、ＧＤＳＩＩファイルデータはデフォルトでソートされる。データは、レイヤー毎、位置毎にグループ分けされ、データが元々セル内でどのような順番であったかに拘わらず、同じダイジェストが生成される。データがソートされ、かつ、セル内にＧＤＳＩＩのNODEレコード或いはプロパティがない限り、ユーザのソフトウェアは、ＧＤＳＩＩセルとそれらと同等のＯＡＳＩＳ表現間でダイジェストのマッチングを行うことができる。
【０２９７】
浮動小数点の丸め誤差を回避するために、ダイジェストは、セル内のレイアウトデータの整数座標に基づいて計算される。ユーザの所望するデザイングリッドは時間と共に変化するため、正則セルダイジェストは、ユーザが-gridコマンドラインオプションを用いて規定する、より小さなグリッドに基づいて計算される。ユーザは、将来のデザイングリッドがすべて確実にこのグリッドの整数倍となるように、グリッドを慎重に選択しなければならない。デフォルトでは、このグリッドは、１ナノメータ（１．０ｅ−９メータ）となっている。０．５ナノメータ、或いは、０．２５ナノメータ等、もっと小さい値を設定するのが最良の選択であると考えられる。しかし、グリッドが小さすぎると、３２ビットマシン上で整数演算のオーバーフローが起きてしまう。
【０２９８】
すべてのAREF（配列ストラクチャ参照）は、表現の一貫性を保つために展開されるため、正則セルダイジェストの計算の実行時の性能は、同じサイズのファイルでもかなり変動する。
【０２９９】
ＯＡＳＩＳファイルに関するダイジェストレポートの一部をここに示す。
Cell "Structure_1" (sorted)
a7100492  Cell with Comments
3d4d7fbf  Cell without Comments
9a5d7b2d  Cell Comments
7b78aab4  Cell Body non-Layer
15546763  Cell Body Layer 3
fda35715  Cell Body Layer 42
aec2e57d  Cell Body non-Geometric Data Layer 3
【０３００】
この例では、セルはソートをするのに十分なほど小さく、このことはセル名の後ろでレポートされている。セルの変更及びアクセス回数はコメントとして記録され、非レイヤーデータとして記録されたストラクチャ参照と、レイヤー３及び４２に関して記録された幾何形状がある。最後に、レイヤー３に関して非幾何学的データ（１又は複数のNODE又はTEXTレコード）がある。
【０３０１】
［ＧＤＳＩＩストリームファイル：定義］
ＧＤＳＩＩは、早い時期からあるレイアウトデータベースフォーマットであり、元々はＣａｌｍａ  Ｃｏｒｐｏｒａｔｉｏｎによって１９８０年代によって定義され、現在は、Ｃａｄｅｎｃｅによって所有されている。プロトタイプのＧＤＳＩＩ構文解析ツールは、２０００年問題対応が追加されたＣａｄｅｎｃｅ  Ｖｉｒｔｕｏｓｏ  Ｄｅｓｉｇｎ  Ｄａｔａ  Ｔｒａｎｓｌａｔｏｒｓ  Ｒｅｆｅｒｅｎｃｅに記載された仕様に準拠している。
【０３０２】
ＧＤＳＩＩは、バイナリフォーマットであるため、明瞭性のために、本説明では、ＧＤＳＩＩの仕様に挙げられたレコード名を用いる。
【０３０３】
［ＧＤＳＩＩファイルの構文解釈］
産業標準仕様がないため、ツールベンダーは、長い年月の間に「拡張された」ＧＤＳＩＩフォーマットを持つようになった。例えば、ＧＤＳＩＩの付随資料には、ノードポイント、テキストポイント、幾何学的オブジェクトの最大レイヤー数は２５５であると記載されているが、ツールによっては、３２，７６７レイヤー（符号付１６ビット整数の最大値）まで許可しているものもある。同様に、ＧＤＳＩＩの付随資料では、バウンダリー（ポリゴン）及びパス（配線）を２００ポイントまでと制限しているが、ツールによっては、４，０９４ポイント（６５，５３５バイトレコードに適合するポイントの最大数）まで許可しているものもある。構文解析ツールは、これらの拡張をサポートするために、ある程度のチェックを提供する一方で、以下に関する制限を規定する「変動（ｖａｒｉａｎｃｅｓ）」レコードを認めている。
・  ストラクチャ名の長さ（デフォルトでは３２、最大３２，７５０）
・  （“Ａ−Ｚａ−ｚ０−９＿？＄”を超えて）ストラクチャ名に許される追加文字
・  最大レイヤー数、データタイプ、テキストタイプ（デフォルトでは６４、最大３２，７６７）
・  最大プロパティ属性数（デフォルトでは６４、最大３２，７６７）
・  最大BOUNDARY又はPATHポイントカウント（デフォルトでは２００、最大４，０９４）
・  最大ノードポイントカウント（デフォルトでは５０、最大４，０９４）
・  最大プロパティ値の長さ（デフォルトでは１２８、最大３２，７６７）
・  ＡＲＥＦにおける格子ベクトルが回転したか、或いは、それらが直交して第１象限にあるか
・  ＡＲＥＦでの回転が、格子が剛体回転することを意味するか、或いは、インスタンスが指定されたように格子内の所定の位置で回転することを意味するか
【０３０４】
これらのアスペクトへの変更の他、ＧＤＳＩＩファイルが上記仕様に準拠していない場合、構文解析ツールは、エラーを返す。
【０３０５】
デザインツールは、レイアウトセルの幾何形状を表すために使用されるＧＤＳＩＩ要素をかなり自由に選択することができる。レイアウトのエディタは、一般に、設計者の選択（例えば、PATH対BOUNDARY）を順守するが、最終的なストリーム出力は、屈曲部でのPATHの定義に固有な曖昧性を軽減するために、同じBOUNDARYを代わりに使用する可能性がある。また、こうしたツールは、反時計回りから時計回りにBOUNDARYの「曲がりくねった方向」を変更することも考えられる。こうした問題を防ぐため、すべての幾何学的要素は、正則セルダイジェスト計算のための正則表現に変換される。
・  PATH要素は同等のBOUNDARYレコードに変換される。
・  BOUNDARYポイントリストの最後のポイントは、第１ポイントと一致する場合、削除される。
・  BOUNDARYポイントリストは、結果的に得られたポリゴンが反時計回りの曲がりくねった方向を有する場合、反転される。
・  リストの第１ポイントには、最も左下のポイントが選ばれる。
【０３０６】
また、ＧＤＳＩＩファイルは、新しいＯＡＳＩＳフォーマットと共存する。ＯＡＳＩＳは、繰り返されるオブジェクト参照を記述するために様々な方法を用いる。正則化のため、AREF（配列ストラクチャ参照）オブジェクトは、個々のSREF（ストラクチャ参照）オブジェクトの同等のシーケンスに展開される。同様のことがＯＡＳＩＳ構文解析ツールにおいて行われる（繰り返しが展開される）ため、ＧＤＳＩＩファイル対ＯＡＳＩＳファイルでレイアウトに関するダイジェストの比較が可能となる。このため、ファイルサイズの関数である実行時間性能は保証できない。１０億のSREFに展開されるAREFを有する小さなファイルは、SREFが１つづつダイジェストに追加されるため、かなりのＣＰＵ時間を要する。
【０３０７】
ＧＤＳＩＩ仕様では、ＡＲＥＦ格子が直交しており、かつ、第１象限にあること（すなわち、正のＸ軸に沿った第１格子ベクトルと正のＹ軸に沿った第２格子ベクトル）が求められるため、左右反転の場合は左右反転が、回転の場合は剛体回転が、夫々指定される。実際、ＣＡＤツールでこの定義を使っているものはほとんどない。代わりに、格子ベクトルは回転、かつ／或いは、左右反転され、インスタンスは、変換された格子内に配置される。デフォルトでは、プロトタイプのＧＤＳＩＩ構文解析ツールはこの定義を用い、ＡＰＩには元の定義を使うオプションが存在する。
【０３０８】
尚、ダイジェストは、下層にある幾何形状ではなく、ＧＤＳＩＩファイル内のオブジェクトに基づいて計算される。ダイジェストの計算前には、重複の除去は行われない。
【０３０９】
ＧＤＳＩＩファイル内の座標は、例えば１ナノメータ（１．０ｅ−９メータ）のグリッドを用いて、ファイルの冒頭で規定される。セル内では、すべての座標がこのグリッドを単位として整数となるように定義されている。ファイルグリッドは変わる可能性があるが、最終のマスクデータには影響を及ぼさない。例えば、標準グリッドが１ナノメータであっても、インポートされたデザインテンプレートブロックは、５ナノメータのグリッドを用いて規定される可能性がある。ユーザのソフトウェアは、より小さいグリッドを使うために、セルの整数座標を５倍にスケーリングして、すべてのインポートされたデータを変換する。
【０３１０】
確実に正則化を行うため、ＧＤＳＩＩファイルにおけるすべての幾何形状は、内部の正則セルダイジェストグリッドが使えるようにスケーリングされる。ユーザは、すべての将来のデザインにおいて使われるＧＤＳＩＩファイルグリッドが互換性を持つように、このグリッドを慎重に選択しなければならない。例えば、現在のデザイングリッドが５ナノメータとすると、１ナノメータか、或いは、０．５ナノメータの正則セルダイジェストグリッドを用いるのが最良の選択であると思われる。
【０３１１】
正則セルダイジェストグリッドの値は、ＧＤＳＩＩ構文解析ツールに渡され、ＧＤＳＩＩファイルグリッドが正則セルダイジェストグリッド値の整数倍でない場合、エラーが返却される。
【０３１２】
SREF又はAREFレコードを持つストラクチャは、ダイジェストのレポートのために階層的に記述される。
【０３１３】
［ＧＤＳＩＩファイルのソート］
上述のように、ＧＤＳＩＩファイルは、ＯＡＳＩＳファイルとは異なる、配列ストラクチャ参照を指定する方法を用いる。ＯＡＳＩＳファイルライターは、繰り返しを用いて、幾何学的オブジェクト又はストラクチャ参照をかなり自由に集めることができる。繰り返し最適化方法の選択はベンダーによって異なる。最後に、セル内の幾何学的オブジェクトは、ファイルの意味を変えることなく、いつでも順序変更が可能である。したがって、ＧＤＳＩＩレイアウト同士、或いは、ＧＤＳＩＩレイアウトとＯＡＳＩＳレイアウトとを効果的に比較するには、ソートが必要である。このため、ＧＤＳＩＩレイアウト及びＯＡＳＩＳレイアウトのソートは、デフォルトで使用可能となっている。
【０３１４】
幾何学オブジェクトが正則形式に変換された後、ソートのために、以下のように別のオブジェクトとの比較が可能となる。
・  レイヤー名が第１キーとなる。レイヤー番号の若いものが最初に来る。
・  （ＧＤＳＩＩレコードタイプを用いた）要素タイプが第２キーとなる。下位の要素タイプが最初に来る。
・  要素のＸＹ座標（もしあれば）が第３キーとなる。座標は、１つづつ比較され、所定のエントリーに対して最も左下の点を持つ要素が最初に来る。
・  STRCLASSが存在する場合、整数に変換されたビットベクトルが比較され、「最も下位」のものが最初に来る。
・  ELFLAGSが存在する場合、整数に変換されたビットベクトルが比較され、「最も下位」のものが最初に来る。
・  PRESENTATIONが存在する場合、整数に変換されたビットベクトルが比較され、「最も下位」のものが最初に来る。
・  STRANSが存在する場合、整数に変換されたビットベクトルが比較され、「最も下位」のものが最初に来る。
・  次に、PLEX値（デフォルトは０）が比較され、最も値の小さいものが最初に来る。
・  次に、DATATYPE値が比較され、最も値の小さいものが最初に来る。
・  次に、PATHTYPE値（もしあれば）が比較され、最も値の小さいものが最初に来る。
・  レコードがSTRING値を有する場合、値がアルファベットで比較され、最も若いものが最初に来る。
・  レコードがSTRANS（ストラクチャ変換）である場合、SNAME値がアルファベットで比較され、最も若いものが最初に来る。
・  次に、MAG値（もしあれば）が比較され、最も小さいものが最初に来る。
・  次に、ANGLE値（もしあれば）が比較され、最も小さいものが最初に来る。
・  最後に、PROPATTR値が１つづつ比較される。
【０３１５】
最初の３つの比較（レイヤー名、要素タイプ、ＸＹ位置）のみが使われると予想されるため、他の比較の順序は、ほぼ任意とすることができる。
【０３１６】
こうしたソートの基準の中には、ＯＡＳＩＳファイルに使われているものもある。
【０３１７】
ＯＡＳＩＳにおけるアナログを持たないフィールド（例えばPLEX）、或いは、ＯＡＳＩＳでは異なるフィールド（例えばプロパティ）を使用すると、異なるフォーマット間でのセルのマッチングの妨げとなる。
【０３１８】
ソートが要求されると、セル（ＧＤＳＩＩストラクチャ）内のレコードは、セルの終端に達するまで、或いは、あまりに多くのセルデータがメモリに記憶されたためにメモリの使用限度を超えるまで、集められる。セルの終端に達すると、或いは、メモリの使用限度を超えると、記憶されたセルレコードは、元の順番でダイジェストモジュールに送られる。メモリテストがセルに関して行われるため、ソートされるセルもあれば、ソートされないセルもある。セルは、ソートされたかどうかについてマークされる。この情報は、ダイジェストレポートにおいて、ＡＰＩを通じて利用可能である。
【０３１９】
ファイルヘッダオブジェクトは指定された順番があるため、ソートされない。
【０３２０】
［プロトタイプのＧＤＳＩＩ構文解析ツールの制限］
ＧＤＳＩＩファイルは、上述のように、幾つかの数値の制限が緩和されていることを除いて、ＣａｄｅｎｃｅのＧＤＳＩＩの仕様に従うものとする。ＡＲＥＦ格子は、回転方向で規定することもできる。こうした変動の他は、例外及びエラーは許されない。エラーは１つのみレポートされる。構文解析ツールは、１番目のエラーを過ぎて処理を継続することはない。
【０３２１】
現在のところ、数値の制限及び動作フラグをコマンドラインから変更することはできない。ＡＰＩは、上記のすべての項目に関して変動を定義することができる。
【０３２２】
ＧＤＳＩＩにおけるPROPATTRレコードは、ＯＡＳＩＳにおけるPROPERTYレコードとは異なる構造を有する。ＯＡＳＩＳのPROPERTYレコードがS_GDS_PROPERTYフォーマットを使っていない限り、PROPATTRレコードを使うと、ＧＤＳＩＩセルとＯＡＳＩＳセルのマッチングの妨げとなる。
【０３２３】
面積がゼロであるBOUNDARY及びBOXは、それらのポイントが「誤った」順番で描かれていた場合、反転されない。これにより、面積がゼロであるポリゴンを含むＧＤＳＩＩファイルとＯＡＳＩＳファイルの比較が難しくなることがある。
【０３２４】
BOXレコードは、同じではないということを前提として、BOUNDARYレコードに変換されない。BOXレコードは、BOUNDARYレコードと比べて効率的でないため、意図的に異なるように描写される。
【０３２５】
［注釈付サンプルＧＤＳＩＩファイル］
図１２は、注釈付のサンプルＧＤＳＩＩファイルである。ＧＤＳＩＩはバイナリファイルフォーマットであるため、ＧＤＳＩＩレコード名が使用され、個々の要素の中には簡潔にするために省略されている部分もある。要素内のフィールドのすべては同じレコードタイプであるため、一般性の喪失はない。
【０３２６】
ストラクチャの変更及びアクセス回数はセルコメントとして記録される。ストラクチャクラスレコードもまた、セルコメントとして記録される。ストラクチャインターフェース（例えば、ｂｏｕｎｄｉｎｇ  ｂｏｘｅｓ、ａｂｕｔｍｅｎｔ  ｂｏｘｅｓ、ｒｏｕｔｅｒ  ｐｉｃｋｕｐ  ｐｏｉｎｔｓ）に関する産業規格がないため、セルヘッダデータとして記録されるものは何もない。
【０３２７】
ＧＤＳＩＩのレイヤーは数値である。レイヤー名のリストが返却されることはない。
【０３２８】
PATH要素は、ダイジェスト生成に送られる前に、パスタイプとBGNEXTN又はENDEXTNレコードを用いてBOUNDARY要素に変換される。パスタイプ１（丸い端部）は、パスタイプ２（終端から幅半分はみ出た四角い端部）に変換される。
【０３２９】
PATH要素が鋭角を持つ場合、当該屈曲部の外側のコーナーは配線幅の半分に等しい距離で切り取られる。PATHの外側は、時計回りの方向にトレースされ、最も左下のポイントが第１番目として選択される。リストの最後のポイントは第１番目とは一致しない。その代わり、暗黙の端部が存在する。
【０３３０】
ネガティブPATH幅は、警告もなく（ｓｉｌｅｎｔｌｙ）ポジティブパス幅に変換される。それによって、「絶対パス幅」のプロパティが削除される。この変換はダイジェストには記録されない。
【０３３１】
BOUNDARY要素のポイントリストは、反時計回りの巻き付けを持つ場合、反転される。その後、最も左下のポイントが第１番目として選ばれる。ＧＤＳＩＩの仕様に従って第１番目のポイントに重なる最終ポイントは、暗示的な端部が存在するように削除される。
【０３３２】
BOX要素のポイントリストは、反時計回りの巻き付けを持つ場合、反転される。その後、最も左下のポイントが第１番目として選ばれる。ＧＤＳＩＩの仕様に従って第１番目のポイントに重なる最終ポイントは、暗示的な端部が存在するように削除される。BOX要素は、夫々の目的が異なるということを前提として、BOUNDARY要素に変換されない。
【０３３３】
配列参照（AREF要素）は、ダイジェスト生成に送られる前に、SREF要素の同等のリストに展開される。
【０３３４】
要素の属性は、要素自身と同じタイプ（幾何学的データ）で記録される。ＯＡＳＩＳにおける属性の定義はかなり異なるため、非幾何学的データとしてそれらを記録することも可能である。そうしないと、要素を持つセルとＯＡＳＩＳにおける属性はマッチングできない。
【０３３５】
ＧＤＳＩＩレコードにおけるビットアレイ（例えばSTRANS）は、ダイジェスト計算に送られる前に整数に変換される。
【０３３６】
＜例７：非構造化テキストファイルタイプ＞
非構造化テキストファイルとは、正則セルダイジェストツールにとって理解できる仕様を持たないテキストファイルである。例えば、ログファイル、或いは、デザインテンプレートブロックの人間が読める記述が、非構造化テキストファイルである。しかし、テキストファイルは行指向（ｌｉｎｅ−ｏｒｉｅｎｔｅｄ）であるため、ソートがやはり可能である。ソートが要求されると、ファイルヘッダデータダイジェストはソートを反映するために変更される。ソートが要求されない場合は、ファイルダイジェストと一致する。
【０３３７】
この例では、非構造化テキストファイルは、ファイルに関するコンテントダイジェストをバイト単位で有する。バイト単位のダイジェストは、非構造化テキストファイルに関して計算される。ダイジェストは、改行の仕方に依存しない。オプションで、空白の差異を無視するかを指定できる。
【０３３８】
コマンドラインオプションである-mergewhite、-reportwhite、-discardwhiteは、テキストベースのファイルフォーマットに関するファイルレベルの空白ダイジェストのレポートを制御する。空白には、スペース、タブ、改行が含まれる。-mergewhiteオプションは規定値である。-mergewhiteオプションがアクティブの時、空白と非空白の両方を含んだ、単一のファイルレベルダイジェストがレポートされる。-reportwhiteオプションがアクティブの時、空白と非空白に対するダイジェストは別々にレポートされる。-discardwhiteオプションがアクティブの時、空白が無視され、空白を除く単一のファイルレベルダイジェストがレポートされる。
【０３３９】
例えば、サンプルファイルtextfiles/verilog_test.vが、非構造化テキストファイルとして扱われる時、以下の結果が得られる。
otismartsig -txt -mergewhite testfiles/verilog_test.v
File "testfiles/verilog_test.v": unstructured text format
File CRC 5404c699
otismartsig -txt -reportwhite testfiles/verilog_test.v
File "testfiles/verilog_test.v": unstructured text format
File CRC 5404c699
File non-whitespace CRC 7c2a352d
File whitespace CRC 219b1881
otismartsig -txt -discardwhite testfiles/verilog_test.v
File "testfiles/verilog_test.v": unstructured text format
File CRC 7c2a352d
【０３４０】
尚、１つ目の例における統合されたファイルダイジェストは、２つ目の例における完全なファイルダイジェストに一致し、２つ目の例の非空白ダイジェストは、３つ目の例のファイルダイジェストに一致する。
【０３４１】
空白ダイジェスト及び非空白ダイジェストは、ＬｉｂｅｒｔｙやＶｅｒｉｌｏｇ等のセルベースのフォーマットにおいては、個々のセルに関して計算されず、ファイルレベルでのみ計算される。
【０３４２】
３つの空白レポートオプションは、例えば以下のように、構造化テキストファイルフォーマットにも使用することができる。
otismartsig -discardwhite -ver testfiles/verilog_test2.v
File "testfiles/verilog_test2.v": Verilog format
File CRC 07f87fb9
File header CRC 6ef229e6
File comment CRC 6ef229e6
Cell "OAI21_X1"
Interface CRC dae46517
Contents CRC c73aceaf
Cell "OAI21_X2"
Interface CRC 01391569
Contents CRC c73aceaf
【０３４３】
［構文解析］
ファイルレベル（すべてのファイルデータ、非空白データ、空白データ）及びファイルヘッダダイジェストは、非構造化テキストファイルに関して計算される。ファイルヘッダダイジェストは、ファイル内のすべてのデータに関して計算され、必要に応じてアルファベット順に行をソートする。ファイルの行の終端がＤＯＳ形式（ＣＲ−ＬＦ）である場合、その行の終端は、ダイジェストが計算される前に、Ｕｎｉｘ（登録商標）形式（ＬＦのみ）に変換される。
【０３４４】
［非構造化テキストファイルのソート］
ソートが要求されて、メモリの使用限度が十分高い場合、ファイルヘッダダイジェストを計算する前に、ファイルの行はソートされる。すべてのデータは、非レイヤー、非コメントファイルヘッダデータとして記録される。
【０３４５】
［プロトタイプの非構造化テキストファイル構文解析ツールの制限］
現在のところ、空白を正則形式に変換する（例えば、タブをスペースに変換する、或いは、繰り返しのスペースを削除する）ためのオプションは存在しない。
【０３４６】
＜例８：非構造化及び構造化バイナリファイル＞
非構造化バイナリファイル（或いは、構文解析ツール無しの構造化バイナリファイル）に関するダイジェストとは、単純に、解釈の無い連続したＣＲＣのすべてのバイトである。ＧＤＳＩＩファイルの例であるtestfiles/sigtest.gdsに関するダイジェストは以下のように計算することができる。
otismartsig -bin testfiles/sigtest.gds
File testfiles/sigtest.gds: unstructured binary format
File CRC d0b40760
【０３４７】
これは、ＧＤＳＩＩ構文解析ツールによって計算されたファイルレベルのダイジェストと同じダイジェストである。
【０３４８】
［非構造化バイナリファイル］
非構造化バイナリファイルとは、正則セルダイジェストツールにとって理解できる仕様を持たない非テキストファイルである。例えば、オブジェクトコード、或いは、実行可能なプログラムが、非構造化テキストファイルである。これらのファイルは、既知の構造を持たないため、正則セルダイジェストは計算されない。計算されるのは、ファイルダイジェストのみである。構文解釈、及び、非構造化バイナリファイルのソートは行われない。
【０３４９】
＜例９：ＳＰＩＣＥフォーマットネットリストファイルタイプ＞
トランジスタレベルのデザインは、カリフォルニア大学バークレー校で１９７０年代に開発されたＳｉｍｕｌａｔｉｏｎ  Ｐｒｏｇｒａｍ  ｗｉｔｈ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  Ｅｍｐｈａｓｉｓ（ＳＰＩＣＥとして知られている）を用いて解析されることが多い。ＳＰＩＣＥとその派生物は、容量と実行時間の問題によってその使用はデザイン全体ではなくサブ回路（数十〜数百のトランジスタ、及び、関連する寄生回路要素）に限られているが、いまだに最も基準となる集積回路の数値解法ツール（ｓｏｌｖｅｒ）である。ＳＰＩＣＥの入力ファイルはテキストであり、設計者が作成することができるが、一般的には、ＧＤＳＩＩ又はＯＡＳＩＳからレイアウトを読み出す回路エクストラクタによって記述される。典型的には、これらのファイルを読むＳＰＩＣＥシミュレーションは、Ｌｉｂｅｒｔｙフォーマットファイルのためのタイミングモデルを生成するために使われる。
【０３５０】
この例では、ＳＰＩＣＥフォーマットネットリストファイルには、以下のファイル要素に関するコンテントダイジェストがある。
・  ファイル
・  ファイルヘッダ
・  サブ回路に関するポート定義
・  サブ回路のボディ
【０３５１】
ファイルは、内部のサブ回路名を見つけるために検査される。サブ回路に対して、ポート定義、及び、サブ回路のボディに関する個別のダイジェストが計算される。これらは、空白やコメントを除いた個々のＳＰＩＣＥネットリストトークンに基づいている。
【０３５２】
ダイジェストは、ファイルのヘッダ（サブ回路の定義の外側の情報）及びファイル全体に関して計算され、返却される。これらのダイジェストには、空白及びコメントが含まれる。
【０３５３】
インクルードファイルの命令は解釈されない。なぜなら、ダイジェスト計算時のインクルードファイル参照は、シミュレーション時と異なるためである（例えば、パス名が相対的である場合）。
【０３５４】
［ＳＰＩＣＥサブ回路ファイル］
抽出されたレイアウトは、一般に、ＳＰＩＣＥ入力ファイル内のサブ回路に書き込まれ、これらは、正則セルダイジェストソフトウェアによってセルとして記録される。サブ回路内のテキストは、順序非依存であり、ソートが可能であるが、順序非依存のアーギュメントの仕様でインスタンス化されない可能性もあるため、ソート後に見られるダイジェストの一致は、本当に等しいことを表しているとは限らない。したがって、ＳＰＩＣＥサブ回路ファイルのソートは、慎重に行わなければならない。デフォルトでは、ＳＰＩＣＥサブ回路ファイルは、ユーザが-sortフラグを指定しない限り、ソートされない。
【０３５５】
ＳＰＩＣＥサブ回路ファイルにはレイヤーがないため、セルに関するダイジェストはすべて、非レイヤーデータとしてレポートされる。
File "testfiles/test1.spi": Spice format
Arguments: -mem 64 -nosort
e4c0e613  File
7a041fe8  File non-Whitespace
07415f83  File Whitespace
File Header (not sorted)
c8954a7d  File Header with Comments
fa8f8413  File Header without Comments
321ace6e  File Header Comments
fa8f8413  File Header non-Layer
Cell "nand2" (not sorted)
59fa7f10  Cell with Comments
bdda89ec  Cell without Comments
e420f6fc  Cell Comments
5f4226ed  Cell Interface non-Layer
e298af01  Cell Body non-Layer
【０３５６】
［構文解釈］
ＳＰＩＣＥフォーマットに標準規格はなく、様々な変形版が独自の命令（特に装置モデルパラメータ）を持っている。しかし、すべてのプログラムは、サブ回路（セル）が.subcktで始まり.ends.で終わる、同じ行指向ネットリストを用いる。プロトタイプの正則セルダイジェストＳＰＩＣＥ構文解析ツールは、サブ回路に関してセルを生成し、他のすべてのテキストをファイルヘッダの一部として記録する。
【０３５７】
コメントは‘*’で始まり、現在行の終わりまで続く。‘*’の前に空白が入れられているかも知れないが、この空白は削除される。‘*’の後の空白は、処理されることなく記録される。サブ回路内部のコメント行は、セルボディダイジェストに追加される。
【０３５８】
次の行が第１カラム内の‘+’で始まる場合、どの行も次の行まで続く。複数の行が統合される前に、‘+’は削除されるため、以下の２行のシーケンスは、等しい。
.subckt a b c
及び、
.subckt
+ a
+ b
+ c
継続行が統合される時、スペースは追加されないため、以下の２行のシーケンスは、等しい。
.subckt a b c
及び、
.sub
+ckt a b c
【０３５９】
非コメント行における複数の空白文字のシーケンスは、当該非コメント行がダイジェストエンジンに送られる前に、単一のスペース文字に変換される。
【０３６０】
ドット付のコマンド名（例えば、.subckt）は、大文字と小文字が区別される。セル名は、記録される前に小文字に変換され、その他のテキストは、大文字／小文字の変換はされずに記録される。
【０３６１】
.global行に規定されたネットは、セルインターフェース内にピンとして記録される。
【０３６２】
.options行、及び、.param行は、それらがセルに影響を及ぼすことを前提に、セルのボディに追加される。
【０３６３】
.endステートメントの後の行は、解釈されることなく、ファイルヘッダデータとして記録される。.endコマンドは任意であり、もしそれがない場合、エラーは印字されない。
【０３６４】
.global、.options、.param、.subckt、.ends、.end以外のドット付のコマンドは、解釈されることなく、ファイルヘッダデータとして記録される。
【０３６５】
‘X’ （サブ回路のインスタンス化）コマンドを持つサブ回路は、階層的に記述される。
【０３６６】
［ＳＰＩＣＥネットリストファイルのソート］
ＳＰＩＣＥサブ回路ネットリストは接続性のみを規定するため、順番は任意とすることができる。ソートが要求された場合は、ファイルヘッダ内及びサブ回路内の各行がアルファベット順にソートされる。各行で繰り返されるスペースは、ソートが実行される前に削除される。
【０３６７】
サブ回路に関するピン名は、接続がポジショナル（順序依存）であっても、同様にソートされるため、ソートの結果は慎重に使用しなければならない。
【０３６８】
［プロトタイプのＳＰＩＣＥネットリスト構文解析ツールの制限］
構文解析ツールは、メモリ使用限度を超えるほど大きいＳＰＩＣＥサブ回路はないと想定している。また、サブ回路の外側のすべての行を、ソートし、ファイルの最後に記録した状態で格納するのに十分な空きがあると想定している。
【０３６９】
.includeステートメントは、ファイルサーチパスが構文解析ツールに理解されないため、また、時間と共に変化する可能性があるため、処理されない。
【０３７０】
.param行からのパラメータは代入できない。したがって、以下の２つのブロックのテキストは、等しくない。
.param lp=0.35
mpullup zn i vdd vdd pmos w=10.0 l=lp
及び、
mpullup zn i vdd vdd pmos w=10.0 l=0.35
.param行及び.options行は、更に解釈されることなく記録される。したがって、以下の２つのシーケンスは、等しくない。
.param lp=0.35 ln=0.3 wp=0.7 wn=0.7
及び、
.param lp=0.35 ln=0.3
.param wp=0.7 wn=0.7
【０３７１】
［注釈付サンプルＳＰＩＣＥネットリストファイル］
図１３は、上記の構文解析規則を示したＳＰＩＣＥファイルの注釈付バージョンである。
【０３７２】
＜例１０〜１１：ＬＥＦ／ＤＥＦファイルタイプ＞
Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）ファイルは、配置配線（Ｐ＆Ｒ）ツールで用いられる、ＧＤＳＩＩファイル又はＯＡＳＩＳファイルからのルーティングレイヤー設計規則、及び、物理的レイアウトを記述する方法を提供する。また、配置配線対象のセルの抽象化に加えて、ルーター指向（ｒｏｕｔｅｒ−ｏｒｉｅｎｔｅｄ）配線及びビア構築規則が提供される。Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＤＥＦ）ファイルと共に、ＬＥＦファイルは、完全な集積回路の配置配線に関する仕様を提供する。
【０３７３】
これらの例では、ＬＥＦ／ＤＥＦファイルには以下のファイル要素に関するコンテントダイジェストがある。
・  ファイル
・  ファイルヘッダ
・  ヘッダコメントテキスト
・  セルコメントテキスト
・  レイヤー毎の幾何学的オブジェクト
・  レイヤー毎の非幾何学的オブジェクト
・  他のすべてのオブジェクト：セルサイズ、サイトタイプ等
・  他の下位のセルを参照するブール型フラグ
【０３７４】
データベースは、内部のセル名を見つけるために検査される。存在するセルに関して、レイヤー毎のダイジェストがすべてに関して返却される。
１．ポリゴン、矩形等の幾何学的オブジェクト
２．テキストポイント等の非幾何学的オブジェクト
【０３７５】
ダイジェストは、セルサイズ、サイトタイプ、対称情報等の他のすべてのオブジェクトに対して割り当てられる。ダイジェストは、ファイルのヘッダ（セル定義の前の情報）に関して、及び、ファイル全体に関して計算され、返却される。
【０３７６】
オプションとして、ヘッダ内のコメントテキストとセル内部に関して個別のダイジェストが計算され、空白の差異（スペースの数、タブ対スペース、空白行）は無視される。
【０３７７】
［Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）ファイル］
ＬＥＦファイルは、テキスト指向であるが、一般に、設計者ではなく自動化ツールによって記述される。処理技術（すなわち設計規則）の記述は、典型的には、１つのＬＥＦファイルに記憶され、一方、セル情報は、別ファイル内に記憶されたマクロに記述される。技術情報は、ファイルヘッダデータとして記録され、マクロはセルとして記録される。マクロ内のほとんどすべての情報は、配置配線ツールに対するマクロのインターフェースを規定しているため、セルインターフェースデータとして記録される。マクロのプロパティ（もしあれば）だけが、セルボディデータとして記録される。
【０３７８】
ＧＤＳＩＩ及びＯＡＳＩＳのように、ＬＥＦファイルのデータの多くが順序非依存であるため、ユーザが-nosortフラグを指定しない限り、デフォルトでソートされる。マクロ内のデータはそのままで、ファイルヘッダにおける情報が必要に応じてソートされる。
【０３７９】
尚、ＬＥＦファイルは、ＧＤＳＩＩファイルやＯＡＳＩＳファイルのように番号でではなく、名称でレイヤーを規定する。
File "testfiles/parsetest.lef": LEF format
Arguments: -mem 64 -sort
c5eb5fff  File
1c18cc01  File non-Whitespace
eb7f52d1  File Whitespace
File Header (sorted)
30dbab35  File Header with Comments
25a292d4  File Header without Comments
157939e1  File Header Comments
b450539c  File Header non-Layer
316de219  File Header Layer M1
a8fd3343  File Header Layer V1
ff7eda09  File Header Layer M2
1b691e80  File Header Layer V2
ec75d49b  File Header Layer M3
Cell "AND2_X1" (sorted)
1ed769e0  Cell with Comments
1ed769e0  Cell without Comments
(none)    Cell Comments
818dbac9  Cell Interface non-Layer
cbeea19a  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
【０３８０】
［Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔファイル：定義］
プロトタイプのＬＥＦ構文解析ツールは、ＣａｄｅｎｃｅのＬＥＦ／ＤＥＦ  Ｌａｎｇｕａｇｅ  Ｒｅｆｅｒｅｎｃｅ  Ｍａｎｕａｌ、バージョン５．６（２００４年９月）におけるＬＥＦデータファイルフォーマットの定義を使用している。この文書は、曖昧な点があり、誤字があるが、これらの点については、前記マニュアルに同梱されている参考の構文解析ツールと同じ方法で解決された。
【０３８１】
［構文解釈］
ＬＥＦにおけるセルの記述は、マクロと呼ばれる。ブロッケージ（Ｂｌｏｃｋａｇｅ：封鎖）情報、及び、ピン情報といったマクロ内のすべての情報は、セルインターフェースの一部として記録される。ブロッケージは、セルに対して配線する際にルーターが避ける領域である。ピンは、ルーターがセルに接続する配線を引く場所を示す。
【０３８２】
技術ＬＥＦファイルにおける設計規則情報は、ファイルヘッダの一部として記録される。
【０３８３】
ＬＥＦファイル内のレイヤーは、名称によってインデックスが付けられるため、構文解析ツールは、文字列レイヤー名テーブルを生成し、当該テーブル内のインデックスをレイヤー番号として割り当てる。このテーブルは、ＡＰＩを通じて利用可能である。
【０３８４】
行は、ＬＥＦの仕様により、２０４８文字までで切り取られる。
【０３８５】
SITEステートメントは、ファイルヘッダに記録され、セル自体を形成しない。
【０３８６】
ＬＥＦファイルは配置配線ツールに対するセルのインターフェースを規定するためのものであるため、プロパティを除くMACROブロック内のすべては、セルインターフェーステキストとして記録される。
【０３８７】
ＬＥＦキーワードは、大文字／小文字に関係なくマッチングされる。ＬＥＦ５．６仕様では、明らかに大文字と小文字の区別がない&ALIASと&ENDALIASを除いて、この件に関して何も述べてられていない。現在のところ、正則セルダイジェストは、キーワードの元の文字を基本としている。これは、NAMESCASESENSITIVEがOFFに設定されていても、レイヤー、マクロ、ピン名に対して適用される。しかし、これは容易に変更される。
【０３８８】
［ＬＥＦファイルのソート］
一般に、ＬＥＦファイル内のオブジェクトは、以下の２点を除いて、順番は任意である。
・  オブジェクトの参照はそれらの定義の後に来る。
・  PATHの幅は、最も新しいWIDTHステートメントによって決定される。
【０３８９】
個々のオブジェクト内の情報には、順序非依存のものもあれば、順序依存のもの（例えば、PATHポイント又はITERATE値）もある。構文解析ツールは、ソートされたデータが依然として有効であることを確実にするために、順序依存のフィールドから順序非依存のフィールドを分離する。
【０３９０】
ファイルのソートが要求されると、ファイルヘッダ内とマクロ内のステートメントが、まずステートメント名に基づいて、次にステートメントパラメータに基づいて、アルファベット順に並べられる。ステートメント内の順序非依存のフィールドもまたソートされる。正則化を確実にするために、所定のPATHに適用されたWIDTHは、ソート前に当該PATHレコードに追加される。
【０３９１】
［プロトタイプのＬＥＦ構文解析ツールの制限］
１つのファイルの構文解析を行うことからＬＥＦ構文解析ツールには多くの制限があるが、ＬＥＦファイルを使うツールは複数のＬＥＦファイルを順にロードすることができる。順番が先のＬＥＦファイルからの値を、順番が後のＬＥＦファイルで使うことができる。ＬＥＦ構文解析ツールは、こうした他のファイルにアクセスできないため、渡された値に依存する。
【０３９２】
NAMESCASESENSITIVE、BUSBITCHARS、DIVIDERCHARの各ステートメントは、解釈されない。構文解析ツールは、最上位のドライバから仕切り文字を受け取る（まだコマンドラインから設定することができないので、デフォルト値が使用される）。仮に、構文解析ツールが現在のファイルから読み出した値に依存するならば、複数のＬＥＦファイルがロードされる時に、配置配線ツールとは異なる結果を得ると思われる。
【０３９３】
ファイルは、ALIAS名の参照が識別子として扱われても、構文的には正しいと考えられる。ALIASステートメント自体が、別のファイルにあり、任意の量の構文を含むことも考えられ、その場合、ファイルを単独で構文解析することは不可能である。
【０３９４】
ＬＥＦファイルのソートは、数字順ではなくアルファベット順に行われるため、正則セルダイジェストは現在のところ、以前と同じ番号フォーマットを使い続けるＬＥＦ生成ソフトウェアに依存している。
【０３９５】
構文解析ツールは、技術ＬＥＦファイル（設計規則を含む）が、セルライブラリＬＥＦファイル（マクロの記述を含む）と分けられているかをチェックしない。
【０３９６】
前に定義されたSITEブロックに対するSITEブロック参照は、前に定義されたSITEブロックの存在をチェックすることはない。古い方のSITEブロックは別のファイルにある可能性があり、しかも、一度に１つのファイルしか構文解析されないためである。SITEオブジェクトを変更しても、それらを参照するMACROオブジェクトは変更されることはないと考えられている。
【０３９７】
技術情報及び他のファイルヘッダデータは、メモリの使用限度を超えることはなく、１つのMACROがメモリの使用限度を超えることはないと考えられている。
【０３９８】
［注釈付サンプルＬＥＦファイル］
図１４は、上記の構文解析規則の適用を示す、注釈付のサンプルＬＥＦファイルである。
【０３９９】
＜例１１（続き）：Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＤＥＦ）ファイル＞
Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＤＥＦ）ファイルは、配置配線（Ｐ＆Ｒ）ツールで用いられるデザインフロアプラン及びネットリストを記述する方法を提供する。Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）ファイルと共に、ＤＥＦファイルは、完全な集積回路の配置配線の仕様を提供する。
【０４００】
ＤＥＦファイルは、テキスト指向であり、自動化ツール又は設計者によって記述される。ダイエリア及び領域の仕様等の高レベルの設計情報は手動で生成され、詳細なブロッケージ情報及び事前配線された（ｐｒｅ−ｒｏｕｔｅｄ）ネットは、一般にソフトウェアによって記述される。ＤＥＦファイルは、配置領域を含まない可能性があり、設計階層と相互に関連しないため、ＤＥＦファイルのすべてのデータは、ファイルヘッダダイジェストに記録される。
【０４０１】
ＧＤＳＩＩとＯＡＳＩＳと同様に、ＤＥＦファイルのデータの多くは順序非依存であるため、ユーザが-nosortフラグを指定しない限り、デフォルトでソートされる。
【０４０２】
尚、ＤＥＦファイルは、ＧＤＳＩＩファイルやＯＡＳＩＳファイルのように番号によってではなく、名称でレイヤーを規定する。
File "testfiles/simple.def": DEF format
Arguments: -mem 64 -sort
a832fb91  File
807bad9c  File non-Whitespace
280fe544  File Whitespace
File Header (sorted)
b8d02902  File Header with Comments
c6810a4d  File Header without Comments
7e51234f  File Header Comments
6d026f6f  File Header non-Layer
1d4870e4  File Header Layer m1
74aecb62  File Header Layer v1
feafad9c  File Header Layer m2
6a00eeb9  File Header Layer v2
eeb61028  File Header Layer m3
【０４０３】
［Ｄｅｓｉｇｎ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔファイル：定義］
プロトタイプのＤＥＦ構文解析ツールは、ＣａｄｅｎｃｅのＬＥＦ／ＤＥＦ  Ｌａｎｇｕａｇｅ  Ｒｅｆｅｒｅｎｃｅ  Ｍａｎｕａｌ、バージョン５．６（２００４年９月）におけるＤＥＦデータファイルフォーマットの定義を使用している。この文書は、曖昧な点があり、誤字があるが、これらの点については、前記マニュアルに同梱されている参考の構文解析ツールと同じ方法で解決された。
【０４０４】
［構文解釈］
ＤＥＦファイルは、階層を持たないフラットなエンティティとしてデザイン（或いはデザインのブロック）を記述する。領域の分類がたとえ使われたとしても、それはデザインの階層を反映しない。結果として、すべてのＤＥＦデータは、ファイルヘッダの一部として記録される。
【０４０５】
ＤＥＦファイル内のレイヤーは、名称によってインデックスが付けられるため、構文解析ツールは、文字列レイヤー名テーブルを生成し、当該テーブル内のインデックスをレイヤー番号として割り当てる。このテーブルは、ＡＰＩを通じて利用可能である。
【０４０６】
行は、ＤＥＦの仕様により、２０４８文字までで切り取られる。
【０４０７】
ＤＥＦキーワードは、大文字／小文字に関係なくマッチングされる。ＤＥＦ５．６仕様では、明らかに大文字と小文字の区別がない&ALIASと&ENDALIASを除いて、この件に関して何も述べてられていない。正則セルダイジェストは、キーワードの元の文字を基本としている。
【０４０８】
ＤＥＦファイルのサイズを小さくするため、（例えば、BLOCKAGEステートメント内のPOLYGONにおいて）再使用される係数は、アスタリスク（‘*’）として表現される。構文解析ツールは、現在のところ、アスタリスクを、それが表す番号に展開しない。なぜなら、そうした値は、理論上、&ALIASに置き換わるものであり、したがって、数値トークンではないからである。
【０４０９】
［ＤＥＦファイルのソート］
ＤＥＦファイルのほとんどのオブジェクトは、任意の順番で現れる。ただし、オブジェクトの参照は、それらの定義の後に来る。個々のオブジェクト内の情報には、順序非依存のものもあれば、順序依存のもの（例えば、POLYGONポイント）もある。構文解析ツールは、ソートされたデータが依然として有効であることを確実にするために、順序依存のフィールドから順序非依存のフィールドを分離する。例えば、BLOCKAGEステートメントでは、レイヤーに関するブロッケージはいずれも、ソート時にそのままの状態が維持されるが、レイヤー内のオブジェクトはソートが可能である。
【０４１０】
ファイルのソートが要求されると、ファイル内のステートメントが、まずステートメント名に基づいて、次にステートメントパラメータに基づいて、アルファベット順に並べられる。ステートメント内の順序非依存のフィールドもまたソートされる。
【０４１１】
［プロトタイプのＤＥＦ構文解析ツールの制限］
１つのファイルの構文解析を行うことからＤＥＦ構文解析ツールには多くの制限があるが、ＤＥＦファイルを使うツールは複数のＤＥＦファイルを順にロードすることができる。順番が先のＤＥＦファイルからの値を、順番が後のＤＥＦファイルで使うことができる。ＤＥＦ構文解析ツールは、こうした他のファイルにアクセスできないため、渡された値に依存する。
【０４１２】
ファイルは、&ALIAS名の参照が識別子として扱われても、構文的には正しいと考えられる。&ALIASステートメント自体が、別のファイルにあり、任意の量の構文を含むことも考えられ、その場合、ファイルを単独で構文解析することは不可能である。
【０４１３】
BLOCKAGES、COMPONENTS、FILLS、GROUPS、NETS、NONDEFAULTRULES、PINS、PINPROPERTIES、PROPERTYDEFINITIONS、REGIONS、SCANCHAINS、SLOTS、SPECIALNETS、STYLES、VIASの各セクションにおけるカウントは、これらのセクション内の項目の実際の数に対して検証されない。
【０４１４】
NAMESCASESENSITIVE、BUSBITCHARS、DIVIDERCHARの各ステートメントは、解釈されない。構文解析ツールは、最上位のドライバから仕切り文字を受け取る（まだコマンドラインから設定することができないので、デフォルト値が使用される）。仮に、構文解析ツールが現在のファイルから読み出した値に依存するならば、複数のＤＥＦファイルがロードされる時に、配置配線ツールとは異なる結果を得ると思われる。
【０４１５】
UNITSコマンドは、存在しないか、或いは、常に同じであり、ファイル内の係数は、現在のところ、デザインユニット値でスケーリングされないと考えられている。
【０４１６】
データポイント係数におけるアスタリスクは、現在のところ、数に展開されない。
【０４１７】
メモリ使用限度を超えたかどうかを判断する際、コメントによって使用されたメモリはカウントされるとは限らない。
【０４１８】
［注釈付サンプルＤＥＦファイル］
図１５は、上記規則の適用を示すＤＥＦファイルの注釈付バージョンである。
【０４１９】
コメント以外のすべてがファイルヘッダダイジェストへ送られるため、考えられるステートメントのすべてが示されている訳ではない。
【０４２０】
ＤＥＦオブジェクトの以下のタイプのソートが可能である。
・  PROPERTYDEFINITIONSセクション内のオブジェクト
・  ROW定義
・  TRACKS定義
・  VIAS定義、ビアのレイヤー内のRECT及びPOLYGONオブジェクト
・  STYLES定義（但し、スタイル内のポリゴンポイントを除く）
・  NONDEFAULTRULESセクション内のオブジェクト（但し、規則内のパラメータを除く）
・  REGIONSセクション内のオブジェクト（但し、領域内のパラメータを除く）
・  BLOCKAGE定義内のレイヤー、レイヤー内のRECT及びPOLYGONオブジェクト
・  BLOCKAGE定義内のPLACEMENTオブジェクト、PLACEMENTオブジェクト内のRECT及びPOLYGONオブジェクト
・  SLOTSセクション内のレイヤー、レイヤー内のRECT及びPOLYGONオブジェクト
・  FILLSセクション内のレイヤー、レイヤー内のRECT及びPOLYGONオブジェクト
・  COMPONENTSセクション内のオブジェクト（但し、コンポーネント内のパラメータを除く）
・  PINSセクション内のオブジェクト（但し、ピン内のパラメータを除く）
・  NETS或いはSPECIALNETSセクションにおけるネット（但し、ネット内のパラメータ及び接続を除く）
・  SCANCHAINSセクション内のネット（但し、ネット内のパラメータ及び接続を除く）
・  GROUPSセクション内のオブジェクト
【０４２１】
＜例１２：構造化テキストファイルタイプ＞
この例において、構造化テキストファイルは以下のファイル要素に関するコンテントダイジェストを有する。
・  ファイル
・  ファイルヘッダ
・  コメントテキスト
・  非コメントテキスト
【０４２２】
ダイジェストが、スクリプトファイル、及び、他の構造化テキストファイルに関してバイト単位で計算される。ダイジェストは、改行の書式には依存しない。オプションで、空白の差異を無視するかを指定できる。任意のコメントマーカーが渡されることがあるが、もしそれが存在する場合は、コメントと非コメントテキストの夫々に関してダイジェストが計算される。また、任意の行継続文字が渡されることもあり、もしそれが存在する場合は、この文字で終わっている行は、ダイジェスト計算の前に統合される。
【０４２３】
［構造化テキスト（スクリプト）ファイル］
構造化テキストファイルは、認識可能なコメントを含み、また恐らくは、後に続く行が論理的に現在行の一部であることを示す継続文字も含む、行指向の（ｌｉｎｅ−ｏｒｉｅｎｔｅｄ）人間が読めるファイルである。シェル、Ｐｅｒｌ、Ｐｙｔｈｏｎのスクリプトは、構造化テキストの典型的な例である。
【０４２４】
構造化テキストファイルのすべてのデータは、ファイルヘッダコメント又はファイルヘッダ非レイヤーデータの何れかであるファイルヘッダデータとして記録される。行頭の空白は削除され、空白文字の繰り返しは統合されて１つのスペースとなる。コメントは、ユーザ指定のコメント文字シーケンス（例えば‘#’）で始まり、行の末尾まで続く。行が、ユーザ指定の継続文字（例えば‘\’）で終わっている場合は、次の行と統合され、継続文字と行末文字は削除される。
【０４２５】
構造化テキストファイルは、シングルクォーテーション又はダブルクォーテーションで囲まれた文字列定数を含むことも考えられる。文字列定数内では、引用符は、‘\’でエスケープされる場合に現れる。引用文字内の空白は、統合されない。
【０４２６】
［構文解析］
構造化テキストファイルのすべてのデータは、ファイルヘッダコメント又はファイルヘッダ非レイヤーデータの何れかである、ファイルヘッダデータとして記録される。
【０４２７】
正則化のため、行内の空白文字の繰り返しは、統合されて１つのスペース文字となる。デフォルトでは、すべての行頭の空白（字下げ）は、行から削除される。字下げが重要である言語もあるため（例えば、Ｐｙｔｈｏｎ）、行頭の空白をそのままにするフラグが存在する。このフラグが設定されても、行内の、行頭以外の場所にある空白文字の繰り返しは、やはり統合されて１つのスペース文字となる。
【０４２８】
空行（行の末尾のみで、他の文字を伴っていない）は、ファイルレベルダイジェストにのみ記録され、ファイルヘッダダイジェストには記録されない。
【０４２９】
ファイルの行の末尾がＤＯＳ形式（ＣＲ−ＬＦ）である場合、その行の末尾は、ダイジェストが計算される前に、Ｕｎｉｘ（登録商標）形式（ＬＦのみ）に変換される。
【０４３０】
文字列定数は、シングルクォーテーションに囲まれているか、ダブルクォーテーションに囲まれているかに拘わらず、一語として扱われ、解釈及び空白の統合が行われない状態で記録される。バックスラッシュ文字（‘\’）は、文字列定数内の引用符のエスケープに用いることができる。
“This is a string constant with \” an embedded quote in it”
【０４３１】
バックスラッシュ文字、及び、引用符は文字列定数の一部として記録される。
【０４３２】
ユーザ指定の継続文字（例えば、‘\’）で終わる行は、文字列定数の認識を含む他の行の処理よりも前に、後続の行と統合される。継続文字は、空白が後に続かない行の末尾の直前の文字である。継続文字と行終端文字は、２行が統合される時に削除される。連続する任意の数の行は、このようにして統合される。
【０４３３】
コメントは、ユーザ指定の文字シーケンス（例えば、“#”又は“--”）で始まり、行の最後まで続く。コメント文字は行内の何処にでも存在する。文字列定数内のコメント文字からはコメントは始まらない。継続文字の処理は、コメントの処理の前に行われるため、継続文字がコメント行の最後にある場合、その後の行もまた、コメントの一部として記録される。したがって、以下の２ブロックのテキストは等しく、１つのコメント行として記録される。
# this is a multi-\
line comment
及び、
# this is a multi-line comment
【０４３４】
継続文字は、引用することができない。１行の最後の文字が継続文字の場合、その行は、例えば、‘\’が前にあるとしても、もしくは、文字列定数内にあるとしても、次の行と統合される。
【０４３５】
［構造化テキストファイルのソート］
構造化テキストファイルは、一般に順序依存であるため、ソートができない。
【０４３６】
［プロトタイプの構造化テキストファイル構文解析ツールの制限］
現在のところ、コマンドラインインターフェースを使って行頭の空白の削除を阻止することはできない。この機能を実現するにはＡＰＩが必要である。
【０４３７】
現在のところ、コマンドラインインターフェースを使ってコメント文字シーケンスを規定することはできない。この機能を実現するにはＡＰＩが必要である。
【０４３８】
現在のところ、コマンドラインインターフェースを使って継続文字を規定することはできない。この機能を実現するにはＡＰＩが必要である。
【０４３９】
文字列内の引用文字を規定することはできない。引用文字は、‘\’と定められている。
【０４４０】
［注釈付サンプル構造化テキストファイル］
図１６は、構造化テキストファイルの注釈付バージョンである。
【０４４１】
この例では、行頭の空白は保持されない。もし行頭の空白が保持されると、５番目の行の前のすべてのスペースがファイルヘッダテキストとして記録されることになる。
【０４４２】
＜例１３：外部のツールによって構文解析されるファイルタイプ＞
外部のツールによって構文解析されるファイルタイプに関して、少なくとも以下のファイル要素について、コンテントダイジェストが提供される。
・  ファイル
・  ファイルヘッダテキスト
・  セル名
・  インターフェースオブジェクト名、フラグ等
・  コメントテキスト
・  セルボディテキスト
【０４４３】
正則ダイジェスト生成工程と互換性があれば、外部の構文解析ツールを使用することができる。一実施形態において、外部の構文解析ツールは、以下のように、行指向の構文を用いてファイルをダイジェスト計算コードに返却する。
ＨＥＡＤＥＲＴＥＸＴ＜ｈｅａｄｅｒ  ｔｅｘｔ＞
ＣＥＬＬ＜ｃｅｌｌ  ｎａｍｅ＞
ＩＮＴＥＲＦＡＣＥ＜ｉｎｔｅｒｆａｃｅ  ｏｂｊｅｃｔ  ｎａｍｅ＞＜ｉｎｔｅｒｆａｃｅ  ｆｌａｇ＞．．．
ＣＯＭＭＥＮＴ＜ｃｏｍｍｅｎｔ  ｔｅｘｔ＞
ＣＥＬＬＴＥＸＴ＜ｃｅｌｌ  ｂｏｄｙ  ｔｅｘｔ＞
【０４４４】
ファイル毎に、１以上のＨＥＡＤＥＲＴＥＸＴレコードが存在する。また、ファイル毎に、１以上のＣＥＬＬが存在する。セル毎に１以上のＩＮＴＥＲＦＡＣＥレコードが存在する。
【０４４５】
行のテキストは、適切なファイル又はセルダイジェストに追加される。ＣＥＬＬレコードの後のコメント行は、当該セルに関するダイジェストに追加される。
【０４４６】
［ユーザ構文解析テキストファイル］
ユーザは、正則セルダイジェストを、独自のデータファイルフォーマットに関して記録したい場合があるかも知れない。そうした場合、ユーザはこうしたフォーマットに関して構文解析ツールを記述し、その内部でデータを、以下に示す、ユーザ構文解析テキストファイルフォーマットに変換することができる。
HEADERTEXT header_text
HEADERTEXT(layer) header_text
CELL cell_name
INTERFACE interface_object_name interface_object_text
INTERFACE(layer) interface_object_name interface_object_text
HIERCELL
CELLTEXT cell_body_text
CELLTEXT(layer) cell_body_text
CELLNONGEOM cell_body_text
CELLNONGEOM(layer) cell_body_text
COMMENT comment_text
【０４４７】
これは、すべての正則セルダイジェストタイプがアクセス可能な、単純な行指向の構文である。一般に、ファイルヘッダデータはHEADERTEXT行によって、セルの始まりはCELL行によって、セルのインターフェースレコードはINTERFACE行によって、セルボディレコードはCELLTEXT又はCELLNONGEOM行によって、コメントはCOMMENT行によって示される。HIERCELL行は階層セル（すなわち、下位の他のセルへの参照を含むセル）を示す。セル内のデータは、次のＣＥＬＬ又はＨＥＡＤＥＲＴＥＸＴ行、或いは、ファイルの最後に続く。すべてのファイルヘッダ、セルインターフェース、セルボディデータは、指定されたレイヤー名又はレイヤー番号を有する。データは、-sortオプションが指定されている場合、ソートが可能である（レイヤーでグループ化され、レイヤー内でアルファベット順にソートされる）。ダイジェストが計算されるテキストは、ユーザにとって意味のある何らかのフォーマットを有する。
【０４４８】
構文は、テキスト指向でかつ行指向であり、このフォーマットを持つファイルのダイジェストと、他のファイルフォーマットからのダイジェストとを比較することはできない。バイナリファイルダイジェストは、バイナリデータを用いて計算され、テキストファイルに関してダイジェストを計算する構文解析ツールは、まず初めに、行をトークンに分割する。
【０４４９】
［ユーザ構文解析テキストファイル：定義］
このフォーマットは、独自のフォーマットファイルを構文解析するために提供される。ユーザによって記述される構文解析ツールは、ファイルフォーマットを読み、この単純なフォーマットでファイルを生成し、生成されたファイルを正則セルダイジェストユーティリティに渡す。構文解析ツールは、あらゆるダイジェストを順に計算する。
【０４５０】
ユーザ構文解析ファイルフォーマットの記述は、下位のダイジェストエンジンに対して、Ａｐｐｌｉｃａｔｉｏｎｓ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）によって行われる。すべてのファイルフォーマットの解釈は、このＡＰＩへの一連の読み出しとして記述することができるため、読者は、このフォーマットを理解すれば、他のフォーマットがどのように解釈されるかも理解することができる。
【０４５１】
上記の実施形態より高度な第２実施形態においても、ユーザ構文解析ファイルフォーマットは行指向フォーマットである。レコードは、HEADERTEXT、COMMENT、CELL、INTERFACE、HIERCELL、CELLTEXT等のキーワードで始まる１行に現れる。HEADERTEXT、INTERFACE、CELLTEXTの各行は、任意で、キーワードの直後に続く括弧で囲まれたレイヤー名を持つ。行の残りの部分に関するレコードは、当該レイヤー名に関して記録される。レイヤー名がない場合、非レイヤーデータに関する−１の数値レイヤー番号が使われる。
【０４５２】
これらのファイルは、コンピュータソフトウェアによってしか生成されないと予想されるため、次のような厳密なフォーマットを使用することができる。
・  キーワードはすべて大文字とする。
・  行のキーワードは、当該行の如何なる文字によっても先行されることはない。
・  レイヤー名が規定されない場合、たとえ記録対象のテキストが空であっても、キーワードの後に１つのスペースが置かれる。
【０４５３】
レイヤー名が規定される場合、そのレイヤー名は、スペースを挟まずにキーワードの直後に括弧に囲まれて記述される。任意のスペースを含む括弧内のテキストは、解釈されずにレイヤー名として記録される。結果として、レイヤー名に閉じ括弧は含まれないことになる。閉じ括弧の後にはスペース文字が置かれる。
【０４５４】
第１のスペースの後のすべては、更なる解釈はされることなく、指定されたタイプのテキストとして記録される。
【０４５５】
改行シーケンス（Ｗｉｎｄｏｗｓ（登録商標）におけるＣＲ−ＬＦ、Ｕｎｉｘ（登録商標）／ＬｉｎｕｘにおけるＬＦ）は、生成されたダイジェストがシステムに依存することを避けるため、ダイジェストを記録する前に削除される。
【０４５６】
どの行にも長さの制限はない。各行は、キーワードで始まり、空行は許されない。
【０４５７】
［ユーザ構文解析テキストファイルの構文］
行のフォーマットは以下の通りである。
HEADERTEXT header_text
HEADERTEXT(layer) header_text
【０４５８】
HEADERTEXT行によって、セルの外側のデータが規定される。セルがオープンである場合（下記を参照）、当該セルは終了しており、新しいセルが開始されるまでセルテキストは提供されない。すべてのヘッダデータは、それがファイルの始まりにあるか、セルの間にあるか、最後のセルの後にあるかに関係なく、１つのブロックとして保存される。ヘッダテキストがソートされる場合、そのすべては（メモリの使用限度を前提として）ファイルの最後までメモリに保存され、１つの単位としてソートされる。
【０４５９】
HEADERTEXTキーワードの後に、１つのスペース文字が続く。当該スペースの後から行の最後までのすべては、ファイルヘッダテキストとして記録される。それ以降は、空白の削除は行われず、解釈、及び、大文字／小文字の変換も行われない。
CELL cell_name
【０４６０】
CELL行によって、新しいセルの開始が規定される。セルがすでにオープンの場合は、そのセルは終了しており、すべてのダイジェストは、そのセルに関して計算される。CELLキーワードの後には１つのスペース文字が続く。このスペース文字の後から行の最後までのすべては、任意の空白も含めて、セル名として使われる。セル名に関しては、解釈も、大文字／小文字の変換も行われない。セル名の重複は許されない。もし、独自のフォーマット内で名称が重複している場合、そのフォーマットに関する構文解析ツールでは、その重複した名称について曖昧になることはない。重複セル名が検出されると、致命的なエラーが発生する。
INTERFACE interface_object_name interface_object_text
INTERFACE(layer) interface_object_name interface_object_text
【０４６１】
INTERFACE行によって、セルに関するインターフェースレコードが規定される。各インターフェースレコードには別々の名称が存在するが、そうでない場合は、行のデータは解釈されない。同じインターフェース名を用いて複数のインターフェースレコードが存在することもある。インターフェース名（例えば、セルに関するピン名）は、INTERFACEキーワード又はレイヤー名の後の、最初の空白で区切られた語である。インターフェース名の後の空白は何れもスキップされ、行にテキストが残っているかどうかが（もし残っていれば）インターフェースオブジェクトテキストとして記録される。インターフェース名及びインターフェースオブジェクトテキストに対しては、大文字／小文字の変換は行われず、インターフェースオブジェクトテキストに対しては、空白の削除も行われない。インターフェース名及びインターフェースオブジェクトテキストはどちらも、セルインターフェースデータとして記録される。
【０４６２】
INTERFACE行が、セルの外側（第１CELLステートメントの前、或いは、HEADERTEXTステートメントと次のCELLステートメントの間）に検出されると、致命的エラーが発生する。
HIERCELL
【０４６３】
HIERCELL行は、セルが階層的である（すなわち、セルが他のセルに対する参照を含む）ことを示す。この情報は、ダイジェストをレポートする際に利用可能である。この行についてはパラメータはない。
CELLTEXT cell_body_text
CELLTEXT(layer) cell_body_text
【０４６４】
CELLTEXT行は、セルボディテキストを規定する。CELLTEXTキーワード又はレイヤー名の閉じ括弧の後に続くスペースの後ろのすべては、更なる解釈も、大文字小文字の変換も行われることなく、セルボディテキストとして記録される。また、空白の消去も行われない。
【０４６５】
CELLTEXT行が、セルの外側（第１CELLステートメントの前、或いは、HEADERTEXTステートメントと次のCELLステートメントの間）に検出されると、致命的エラーが発生する。
CELLNONGEOM cell_body_text
CELLNONGEOM(layer) cell_body_text
【０４６６】
CELLNONGEOM行によって、非幾何学的セルボディテキストが規定される。CELLNONGEOMキーワード又はレイヤー名の閉じ括弧の後に続くスペースの後ろのすべては、更なる解釈も、大文字小文字の変換も行われることなく、セル非幾何学的ボディテキストとして記録される。また、空白の消去も行われない。
【０４６７】
CELLNONGEOM行が、セルの外側（第１CELLステートメントの前、或いは、HEADERTEXTステートメントと次のCELLステートメントの間）に検出されると、致命的エラーが発生する。
COMMENT comment_text
【０４６８】
COMMENT行によって、コメントテキストが規定される。COMMENTキーワードに続くスペースの後ろのすべては、更なる解釈も、空白の消去も、大文字小文字の変換も行われることなく、（コンテクストによって）セル又はファイルヘッダコメントテキストとして記録される。
【０４６９】
［ユーザ構文解析テキストファイルのソート］
ソートが要求されると、ヘッダに関するテキストが、ファイルの最後に達するまで（ファイル内にセルが複数あっても）、或いは、あまりに多くのヘッダテキストがメモリに記憶されたためにメモリの使用限度を超えるまで、集められる。メモリの使用限度を超えると、記憶されたヘッダテキストは、元の順番でダイジェストモジュールに送られる。同様に、セルに関するテキストが、セルの最後に達するまで、或いは、多くのヘッダテキスト及びセルテキストがメモリに記憶されてメモリの使用限度を超えるまで、集められる。メモリの使用限度を超えることは、メモリが十分に提供されているか、或いは、メモリをディスクにバッファする準備がある場合は、めったに起こらないはずである。
【０４７０】
ヘッダテキストは、セルテキストに優先してメモリ内に保持される。複数のセルがファイル内にある場合、その複数のセルがメモリ限度をオーバーフローさせる可能性が最も高いユニットであるため、ヘッダテキストを解放してもほとんど意味がないと考えられている。
【０４７１】
ヘッダテキストに関して、第１のソートキーは、レイヤー番号である。レイヤー番号（レイヤー名テーブル内のインデックス）の若いものが最初に来る。所定のレイヤー内において、行は、キーワードとレイヤー名を除く、行に含まれるテキストを用いて、アルファベット順にソートされる。
【０４７２】
セル内において、第１のソートキーは、行タイプである。インターフェーステキストはセルボディテキストの前に来て、セル非幾何学的ボディテキストは最後に来る。所定のレイヤー内において、行は、キーワードとレイヤー名を除く、行に含まれるテキストを用いて、アルファベット順にソートされる。
【０４７３】
［ユーザ構文解析ファイルの注釈付サンプル］
図１７（ａ）〜１７（ｂ）は、ユーザ構文解析ファイルの注釈付の例である。図１７（ａ）のレイヤー名は、lay1、lay2、lay3、lay4である。これらは、レイヤー０からレイヤー３として夫々記録され、マッピングテーブルが利用可能である。レイヤーを持たないファイルヘッダ、セルインターフェース、セルボディ、セル非幾何学的ボディの各行は、レイヤー名が定義されていないレイヤー−１に記録される。このフォーマットに関して、レイヤー−１の定義は、ユーザの用途によって決定される。
【０４７４】
セルcell2は、階層的であり、h3、i1、i2、i3という名称のインターフェースオブジェクト（例えばピン）を有する。
【０４７５】
ファイルがソートされない時、ダイジェストは、上記の出現順で記録される。ファイルがソートされる時、正則セルダイジェストは、図１７（ｂ）に示されるように記録される。
【０４７６】
ここで注意したいのは、インターフェース行のソートは、それがインターフェース名とインターフェーステキストに分けられる前の、行の残りの部分に基づいて行われることである。したがって、セルcell2のインターフェースh3は、i1のインターフェーステキストがh3よりもアルファベット順で前であっても、インターフェースi1の前に記録される。
【０４７７】
また、セルcell2は、セルcell1が始まった時に終了し、セルcell1は、ヘッダテキストが始まった時に終了する。
【０４７８】
ファイルレベルのダイジェストは、ソートが可能なときは変化しない。HIERCELLレコードは、それを含むセルのソート又は正則セルダイジェストには影響せず、セルデータ構造にフラグを設定するだけである。
【０４７９】
［ユーザ構文解析テキストファイルフォーマットの制限］
ユーザ構文解析ファイルフォーマットはＡＳＣＩＩであるため、バイナリのＯＡＳＩＳフォーマットやＧＤＳＩＩフォーマットのファイルと同じダイジェストを持つように、ユーザ構文解析ファイルを記述することは不可能である。また、ユーザ構文解析ファイルと他の構造化テキストファイルフォーマットとでは、トークンの処理方法が異なる。独自の、内部データフォーマットを用いたファイルからのダイジェストと、別のフォーマットからのダイジェストとをマッチングさせるには、ユーザが、まず初めに、内部データフォーマットファイルを、サポートされたフォーマットに変換するか、或いは、内部フォーマット用のカスタム構文解析ツールを記述するかの何れかを行わなければならない。
【０４８０】
＜＜正則ダイジェストの比較の実施例＞＞
プロトタイプのコマンドラインツールを用いれば、３つのモードの比較が可能となる。ファイル比較モードは、ＯＡＳＩＳやＧＤＳＩＩといったデザインファイルの、異なる２つのバージョンに関するダイジェストファイルを比較し、重要な差異をレポートする。バージョンチェックモードは、デザインファイルのダイジェストと、一連のライブラリファイルに関して計算されたダイジェストとを比較し、最新の一致があればそれをレポートする。データベースチェックモードは、デザインファイルのセルと、新しい／未検査のセル、生産セル、廃止予定の／旧式のセル、既に分かっている不良セルのダイジェストを含むライブラリとをマッチングさせる。
【０４８１】
＜ファイル比較モード＞
ファイル比較モードでは、２つのデザインファイルのダイジェストが比較され、差異があればレポートされる。ファイル比較モードは、不一致のセルがあればそれに気付いて、異なるレイヤー（適用できる場合）とセル構造（例えばインターフェース、適用できる場合）と共に、ダイジェストが異なるセルに関してレポートを印字する。このモードは、既に製造段階に入っているデザインに対して承認済みの変更しか行われていないことを確実にしたい場合に有用である。例えば、設計者が１つのセル内のあるレイヤーを変更したかも知れない場合、新たな変更のレポートは何れも、エラーを示す。
【０４８２】
プロトタイプのコマンドラインツールを用いたファイル比較を実行する構文は次の通りである。
sigcompare -compare [-showall] file1 file2
【０４８３】
第１パラメータである-compareは、ファイル比較モードを規定している。デフォルトでは、異なるセルのみがレポートされる。オプションの-showallフラグは、一致するセルを含めて、すべてのセルがレポートされることを規定する。
【０４８４】
セルは名称によってマッチングされ、名称が異なるコピーを見つけることは意図されていない。
【０４８５】
［ファイル比較例］
以下に示す１対のＬｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）ダイジェストファイルについて検討する。
File "lib_45nm_v1_0.lef": LEF format
Arguments: -mem 64 -sort
c5eb5fff  File
1c18cc01  File non-Whitespace
eb7f52d1  File Whitespace
File Header (sorted)
6f3a526d  File Header with Comments
7a436b8c  File Header without Comments
157939e1  File Header Comments
b450539c  File Header non-Layer
316de219  File Header Layer M1
ff7eda09  File Header Layer M2
Cell "AND2_X1" (sorted)
9a4743f9  Cell with Comments
9a4743f9  Cell without Comments
(none)    Cell Comments
051d90d0  Cell Interface non-Layer
cbeea19a  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND2_X2" (sorted)
6922ffe9  Cell with Comments
6922ffe9  Cell without Comments
(none)    Cell Comments
04592cfd  Cell Interface non-Layer
39cfa1a7  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND2_X4" (sorted)
aa5c90cd  Cell with Comments
aa5c90cd  Cell without Comments
(none)    Cell Comments
d48106d4  Cell Interface non-Layer
2a69e4aa  Cell Interface Layer M1
39cfa1a7  Cell Interface Layer M2
54b472b3  Cell Body non-Layer
Cell "AND3_X1" (sorted)
ae1d08cc  Cell with Comments
ae1d08cc  Cell without Comments
(none)    Cell Comments
5b3057b1  Cell Interface non-Layer
a1992dce  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND3_X2" (sorted)
e9fc0084  Cell with Comments
e9fc0084  Cell without Comments
(none)    Cell Comments
6bca4478  Cell Interface non-Layer
d682364f  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND3_X4" (sorted)
6a5906e0  Cell with Comments
6a5906e0  Cell without Comments
(none)    Cell Comments
0a3e63ea  Cell Interface non-Layer
34d317b9  Cell Interface Layer M1
77375526  Cell Interface Layer M2
54b472b3  Cell Body non-Layer
及び、
File "lib_45nm_v2_0.lef": LEF format
Arguments: -mem 64 -sort
e03e9e03  File
80a5de77  File non-Whitespace
30dbab35  File Whitespace
File Header (sorted)
7c315cff  File Header with Comments
6948651e  File Header without Comments
157939e1  File Header Comments
b450539c  File Header non-Layer
316de219  File Header Layer M1
ec75d49b  File Header Layer M2
Cell "AND2_X1" (sorted)
1ed769e0  Cell with Comments
1ed769e0  Cell without Comments
(none)    Cell Comments
818dbac9  Cell Interface non-Layer
cbeea19a  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND2_X2" (sorted)
498852e8  Cell with Comments
498852e8  Cell without Comments
(none)    Cell Comments
04592cfd  Cell Interface non-Layer
19650ca6  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND2_X4" (sorted)
aa5c90cd  Cell with Comments
aa5c90cd  Cell without Comments
(none)    Cell Comments
d48106d4  Cell Interface non-Layer
2a69e4aa  Cell Interface Layer M1
39cfa1a7  Cell Interface Layer M2
54b472b3  Cell Body non-Layer
Cell "AND3_X1" (sorted)
ae1d08cc  Cell with Comments
ae1d08cc  Cell without Comments
(none)    Cell Comments
5b3057b1  Cell Interface non-Layer
a1992dce  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND3_X2" (sorted)
e9fc0084  Cell with Comments
e9fc0084  Cell without Comments
(none)    Cell Comments
6bca4478  Cell Interface non-Layer
d682364f  Cell Interface Layer M1
54b472b3  Cell Body non-Layer
Cell "AND3_X4" (sorted)
6a5906e0  Cell with Comments
6a5906e0  Cell without Comments
(none)    Cell Comments
0a3e63ea  Cell Interface non-Layer
34d317b9  Cell Interface Layer M1
77375526  Cell Interface Layer M2
54b472b3  Cell Body non-Layer
【０４８６】
これらのファイルは、（ＯＡＳＩＳ、ＧＤＳＩＩ、ＬＥＦ、ＤＥＦ、Ｌｉｂｅｒｔｙフォーマットファイルに推奨されている）幾何形状のソートを有効にした、ＬＥＦファイルの２つのバージョン、及び、３２ビットダイジェストを読み込むことによって生成された。ＬＥＦファイルは、配置配線ツールがどのようにスタンダードセルに接続すべきかを規定するため、セル内のほとんどすべてが、インターフェースにあると言える。つまり、変更が非常に重要となる。なぜなら、変更を行うと、新しいレイアウトのバージョンを落として、古いバージョンに置き換えることが簡単には行えなくなるためである。
【０４８７】
このコマンドを実行する。
sigcompare -compare sigcompare_file1.txt sigcompare_file2.txt
【０４８８】
以下のレポートを生成する。
Summary of file-level comparisons:
File "lib_45nm_v1_0.lef" File digest does not match
File "lib_45nm_v2_0.lef" File digest.
File "lib_45nm_v1_0.lef" non-Whitespace digest does not match
File "lib_45nm_v2_0.lef" non-Whitespace digest.
File "lib_45nm_v1_0.lef" Whitespace digest does not match
File "lib_45nm_v2_0.lef" Whitespace digest.
Summary of file header comparisons:
File "lib_45nm_v1_0.lef" header is a partial match with
File "lib_45nm_v2_0.lef" header:
non-Layer digests match
File Header Layers matched:
M1
File Header Layers mismatched:
M2
comments match
Summary of all cell comparisons:
2  cells are partial matches
4  cells are perfect matches
File "lib_45nm_v1_0.lef" cell "AND2_X2" is a partial match with
File "lib_45nm_v2_0.lef" cell "AND2_X2":
Cell Interface matches partially:
Cell Interface non-Layer digests match
Cell Interface Layers mismatched:
M1
no Cell Body data is present
no Cell Body non-Geometric Layer data is present
no comments present
File "lib_45nm_v1_0.lef" cell "AND2_X1" is a partial match with
File "lib_45nm_v2_0.lef" cell "AND2_X1":
Cell Interface matches partially:
Cell Interface non-Layer digests do not match
Cell Interface Layers matched:
M1
no Cell Body data is present
no Cell Body non-Geometric Layer data is present
no comments present
【０４８９】
ファイルには何処かに違いがあるため、ファイル内のすべてのバイトのファイルダイジェストは異なる。同様に、値の中にも異なるものがあるため、非空白ダイジェストは異なる。最終的に、空白ダイジェストも異なる。ファイルダイジェスト比較は、すべてのファイルタイプに関して印字され、残りの２つのダイジェストの比較は、テキストファイルタイプに関してのみ印字される。
【０４９０】
ＬＥＦファイルヘッダ（設計規則、及び、レイヤーをルーティングする際の寄生情報を含む）は、レイヤーＭ２について異なり、セルＡＮＤ２＿Ｘ２及びセルＡＮＤ２＿Ｘ１は完全には一致しない。これらの比較は、ヘッダ間及びセル間の差異の正確な性質を示すものではない。ここから分かるのは、単に、ユーザが何処を見ればよいかということだけである。
【０４９１】
必ずしもすべてのデザインファイルフォーマットが、ファイルヘッダに関連データを持つわけではない。ＧＤＳＩＩファイルは、ファイルヘッダに重要なデータを持たず、ＯＡＳＩＳファイルレベルプロパティは、幾何学的表現に影響を与えない。結果的に、ＧＤＳＩＩのファイル間、又は、ＯＡＳＩＳのファイル間の比較は、ファイルヘッダデータのマッチングに関するレポートを含まない。
【０４９２】
＜バージョンレポートモード＞
バージョンレポートモードの使用法の１つは、ユーザが複数のバージョンのライブラリファイルを有する時に、デザインファイル内のセルに関してソースライブラリを決定することである。デザインファイルのセルに関して、このプログラムは、すべてのライブラリファイルから、最新の一致（もしあれば）を発見する。
【０４９３】
バージョンレポートモードの構文は以下の通りである。
sigcompare -report [-showall] file -1 file... -2 file... [-3 file...] ...
【０４９４】
１つ目がデザインファイルであり、残りのファイルはライブラリである。ライブラリファイルは、−１は最も新しいバージョン、−２は次に新しいバージョンといった具合に、バージョン番号で規定される。バージョン番号、及び、バージョン番号毎のファイル数に制限はないが、ただし、バージョン番号は連続しており、バージョン番号１つにつき、少なくとも１つのファイルが存在する必要がある。
【０４９５】
-reportパラメータは、バージョンレポートモードを規定する。デフォルトでは、一致しないセル（例えば、配置配線セル）、不完全な一致、旧式のセルに対する一致しかレポートされない。オプションの-showallフラグは、最新のライブラリバージョンとの完全な一致を含めて、すべてのセルがレポートされることを規定する。
【０４９６】
ファイル名が“-”で始まる場合は、その名称は、前に-fileが付く。
【０４９７】
セルは名称によってマッチングされ、名称が異なるコピーを見つけることは意図されていない。
【０４９８】
［バージョンレポートの例］
この例では、小さなデザインＯＡＳＩＳファイルからのダイジェストと、それを構成するために使われるＧＤＳＩＩライブラリとを比較している。デザインダイジェストファイルは、design_from_versions.txtという名称である。
design_from_versions.txt:
File "design_from_versions.oas": OASIS format
Arguments: -grid 1e-9 -mem 64 -sort
f3b2848e  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
(none)    File Header with Comments
(none)    File Header without Comments
(none)    File Header Comments
Cell "top" (sorted; hierarchical)
4512f0e0  Cell with Comments
4512f0e0  Cell without Comments
(none)    Cell Comments
4512f0e0  Cell Body non-Layer
Cell "AND2_X1" (sorted)
63710c55  Cell with Comments
63710c55  Cell without Comments
(none)    Cell Comments
a57f61d1  Cell Body Layer 8
d5557088  Cell Body Layer 10
135b1d0c  Cell Body Layer 12
Cell "AND2_X2" (sorted)
4245e32b  Cell with Comments
4245e32b  Cell without Comments
(none)    Cell Comments
33bfda26  Cell Body Layer 8
47834653  Cell Body Layer 10
36797f5e  Cell Body Layer 12
Cell "AND2_X4" (sorted)
7dbb4961  Cell with Comments
7dbb4961  Cell without Comments
(none)    Cell Comments
b431c2dd  Cell Body Layer 8
addb2970  Cell Body Layer 10
6451a2cc  Cell Body Layer 12
【０４９９】
最新のライブラリからのダイジェストは、ファイルsigcompare_version1_3.txt内に含まれる。尚、上記のＯＡＳＩＳセルはコメントを持たないのに対して、ＧＤＳＩＩセルはコメントダイジェストを持つ。
File "lib_v1_3.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -sort
3b57a2c0  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
9547893d  File Header with Comments
01f60a9d File Header without Comments
94b183a0  File Header Comments
01f60a9d  File Header non-Layer
Cell "AND2_X1" (sorted)
e60bb9da  Cell with Comments
7ff21caa  Cell without Comments
99f9a570  Cell Comments
b9fc712e  Cell Body Layer 8
d5557088  Cell Body Layer 10
135b1d0c  Cell Body Layer 12
Cell "AND2_X2" (sorted)
ff7d7b80  Cell with Comments
6684def0  Cell without Comments
99f9a570  Cell Comments
cdf468c5  Cell Body Layer 8
9d09c96b  Cell Body Layer 10
36797f5e  Cell Body Layer 12
Cell "AND2_X4" (sorted)
11174169  Cell with Comments
88eee419  Cell without Comments
99f9a570  Cell Comments
7715e8f3  Cell Body Layer 8
8158c56e  Cell Body Layer 10
7ea3c984  Cell Body Layer 12
【０５００】
１つ前のバージョンからのダイジェストは、ファイルsigcompare_version1_2.txtに含まれる。
sigcompare_version1_2.txt:
File "lib_v1_2.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -sort
f7b57566  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
e4590214  File Header with Comments
d5839d36  File Header without Comments
31da9f22  File Header Comments
d5839d36  File Header non-Layer
Cell "AND2_X1" (sorted)
6f006266  Cell with Comments
26f9c716  Cell without Comments
99f9a570  Cell Comments
b9fc712e  Cell Body Layer 8
26cf422a  Cell Body Layer 10
b9caf41f  Cell Body Layer 12
Cell "AND2_X2" (sorted)
4b527d9d  Cell with Comments
4245e32b  Cell without Comments
09179eb6  Cell Comments
33bfda26  Cell Body Layer 8
47834653  Cell Body Layer 10
36797f5e  Cell Body Layer 12
Cell "AND2_X4" (sorted)
b35fe404  Cell with Comments
92f41f5b  Cell without Comments
21abfb5f  Cell Comments
418cffaf  Cell Body Layer 8
addb2970  Cell Body Layer 10
7ea3c984  Cell Body Layer 12
【０５０１】
最も古いアクティブなバージョンのライブラリからのダイジェストは、sigcompare_version1_1.txt内でソートされる。
sigcompare_version1_1.txt:
File "lib_v1_1.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -sort
ae014c24  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
82295a77  File Header with Comments
86b9ff40  File Header without Comments
0490a537  File Header Comments
86b9ff40  File Header non-Layer
Cell "AND2_X1" (sorted)
15918b78  Cell with Comments
8c682e08  Cell without Comments
99f9a570  Cell Comments
b9fc712e  Cell Body Layer 8
26cf422a  Cell Body Layer 10
135b1d0c  Cell Body Layer 12
Cell "AND2_X2" (sorted)
5a1e9163  Cell with Comments
169108cf  Cell without Comments
4c8f99ac  Cell Comments
33bfda26  Cell Body Layer 8
47834653  Cell Body Layer 10
6fad94ba  Cell Body Layer 12
Cell "AND2_X4" (sorted)
99bcef32  Cell with Comments
b817146d  Cell without Comments
21abfb5f  Cell Comments
b431c2dd  Cell Body Layer 8
addb2970  Cell Body Layer 10
a1fdffc0  Cell Body Layer 12
【０５０２】
このコマンドが実行されると以下の通りとなる。
sigcompare -report design_from_versions.txt \
-1 sigcompare_version1_3.txt \
-2 sigcompare_version1_2.txt \
-3 sigcompare_version1_1.txt
【０５０３】
次に、以下のレポートが生成される。
Summary of all comparisons:
1  cells do not appear in any library
1  of these cells are hierarchical
2  cells match only partially with library cells
2  cells match old library cells
File "design_from_versions.oas" cell "top" does not match any library cell.
cell is hierarchical.
File "design_from_versions.oas" cell "AND2_X4" is a partial match with
File "lib_v1_1.gds" cell "AND2_X4":
no Cell Interface data is present
Cell Body data matches partially:
Cell Body Layers matched:
10 8
Cell Body Layers mismatched:
12
no Cell Body non-Geometric Layer data is present
there are 2 newer versions of this cell
File "design_from_versions.oas" cell "AND2_X1" is a partial match with
File "lib_v1_3.gds" cell "AND2_X1":
no Cell Interface data is present
Cell Body data matches partially:
Cell Body Layers matched:
10 12
Cell Body Layers mismatched:
8
no Cell Body non-Geometric Layer data is present
File "design_from_versions.oas" cell "AND2_X2" is a perfect match with
File "lib_v1_2.gds" cell "AND2_X2":
no Cell Interface data is present
Cell Body data matches perfectly:
Cell Body Layers matched:
10 12 8
no Cell Body non-Geometric Layer data is present
there is 1 newer version of this cell
【０５０４】
最上位のデザインセルは、予想されるように、どのライブラリにもない。デザインファイルの他の３つのセルは、少なくとも１つのレポート可能な事柄を有する。
・  AND2_X4は、どのライブラリにも完全には一致しない。最も近い一致は、最も古いライブラリからのバージョンである。
・  AND2_X1は、どのライブラリにも完全には一致しない。最も近い一致は、最も新しいライブラリからのバージョンである。
・  AND2_X2は、２番目に古いライブラリのセルに完全に一致する。
【０５０５】
データタイプ及びレイヤーについての一致、不一致のリストは、セルが部分的に一致する場合にのみ、印字される。
【０５０６】
＜データベースチェックモード＞
データベースチェックモードの使用方法の１つは、新しい／証明されていない、生産段階にある、廃止予定／旧式である、既に分かっている不良があるといった、成熟度でタグ付けされた一連のライブラリに対して、対象となるデザインファイルを検証することである。これらの成熟度は、セルの特定のバージョンの生涯を表している。例えば、デザインが大量生産される場合に、ユーザは、証明されていないバージョンのセルを使いたいとは思わない。ユーザは、製造に値すると示されたセルのみを使いたいと思うはずである。しかし、一度、新しいバージョンが証明されると、古いバージョンは段階的に廃止される。廃止予定のバージョンは、新しいデザインではなく、既に大量生産されたデザインでしか使われない。最後に、機能的或いは歩留まりの問題があると分かっているセルのバージョンは、どのデザインにも使うべきではない。
【０５０７】
正則セルダイジェストマッチングによって、ユーザは、対象ファイル内のすべてのセルを、たとえ名称を変えてコピーされていても、分類することができる。この方法によれば、ユーザは、既知の不良セルの使用をすべて検出する、或いは、時間内に承認されていないセルを認識し、デザインが製造へリリースされることを防ぐことができる。
【０５０８】
プロトタイプのコマンドラインプロセッサを用いた、データベースチェックモードの構文は、以下の通りである。
sigcompare -database [-showall] [-new ...] [-prod ...] [-depr ...] [-bad ...] -test ...
【０５０９】
-databaseパラメータは、データベースチェックモードを規定する。デフォルトでは、生産セルとの完全な一致はレポートされない。こうしたセルもレポートするには、オプションの-showallフラグを用いる。
【０５１０】
コマンドラインの残りは、タイプが付けられたダイジェストファイルのリストである。ダイジェストファイルの順番は任意である。ただし、-test（対象）ファイルと、別のタイプのファイルが、夫々少なくとも１つは存在する必要がある。
【０５１１】
-newパラメータは、新しく、生産段階でまだ証明されていないセルを含むライブラリを規定する際に用いられる。
【０５１２】
-prodパラメータは、生産段階で証明されたセルを含むライブラリを規定する際に用いられる。
【０５１３】
-deprパラメータは、廃止予定である、又は、旧式であって、新しいデザインで使うべきではないセルを含むライブラリを規定する際に用いられる。-deprパラメータに続く、次のライブラリタイプまでのすべてのファイル名は、廃止予定として示される。
【０５１４】
-badパラメータは、不良であると既に分かっており、すべてのデザインから削除すべきであるセルを含むライブラリを規定する際に用いられる。-badパラメータに続く、次のライブラリタイプまでのすべてのファイル名は、既知の不良として示される。
【０５１５】
-testパラメータは、対象となるデザインファイルを規定するために用いられる。一般的に、ユーザが一度に比較する対象ファイルは１つだけである。
【０５１６】
ファイル名が“-”で始まる場合は、その名称は、前に-fileが付く。
【０５１７】
［データベースチェックの例］
この例では、小さなデザインＯＡＳＩＳファイルからのダイジェストと、それを構成するために使われるＧＤＳＩＩライブラリとを比較している。デザインダイジェストファイルは、design_from_database.txtという名称である。
design_from_database.txt:
File "design_from_database.oas": OASIS format
Arguments: -grid 1e-9 -mem 64 -sort
14430d19  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
(none)    File Header with Comments
(none)    File Header without Comments
(none)    File Header Comments
Cell "top" (sorted; hierarchical)
fccf8240  Cell with Comments
fccf8240  Cell without Comments
(none)    Cell Comments
fccf8240  Cell Body non-Layer
Cell "AND2_X1" (sorted)
7ff21caa  Cell with Comments
7ff21caa  Cell without Comments
(none)  Cell Comments
b9fc712e  Cell Body Layer 8
d5557088  Cell Body Layer 10
135b1d0c  Cell Body Layer 12
Cell "AND2_X2" (sorted)
aeece77d  Cell with Comments
aeece77d  Cell without Comments
(none)    Cell Comments
df16de70  Cell Body Layer 8
47834653  Cell Body Layer 10
36797f5e  Cell Body Layer 12
Cell "AND2_X4" (sorted)
b817146d  Cell with Comments
b817146d  Cell without Comments
(none)    Cell Comments
b431c2dd  Cell Body Layer 8
addb2970  Cell Body Layer 10
a1fdffc0  Cell Body Layer 12
Cell "AND2_X4A" (sorted)
b817146d  Cell with Comments
b817146d  Cell without Comments
(none)    Cell Comments
b431c2dd  Cell Body Layer 8
addb2970  Cell Body Layer 10
a1fdffc0  Cell Body Layer 12
Cell "AND2_X3" (sorted)
c6f8c857  Cell with Comments
c6f8c857  Cell without Comments
(none)  Cell Comments
b9fc712e  Cell Body Layer 8
075a8f95  Cell Body Layer 10
785e36ec  Cell Body Layer 12
Cell "AND2_X5" (sorted)
e60bb9da  Cell with Comments
7ff21caa  Cell without Comments
99f9a570  Cell Comments
b9fc712e  Cell Body Layer 8
d5557088  Cell Body Layer 10
135b1d0c  Cell Body Layer 12
バージョンレポート例からのファイルsigcompare_version1_1.txt、sigcompare_version1_2.txt、sigcompare_version1_3.txtが、新しいファイルsigcompare_version1_4.txtと共に、ここで再び使用される。
File "lib_v1_4.gds": GDS format
Arguments: -grid 1e-9 -mem 64 -sort
c589f1a1  File
(none)    File non-Whitespace
(none)    File Whitespace
File Header (sorted)
43922b24  File Header with Comments
c52bd464  File Header without Comments
86b9ff40  File Header Comments
c52bd464  File Header non-Layer
Cell "AND2_X1" (sorted)
512424b9  Cell with Comments
4a03a6f8  Cell without Comments
1b278241  Cell Comments
b9fc712e  Cell Body Layer 8
8ba1e13a  Cell Body Layer 10
785e36ec  Cell Body Layer 12
Cell "AND2_X2" (sorted)
a994ef98  Cell with Comments
58eb1029  Cell without Comments
f17fffb1  Cell Comments
cdf468c5  Cell Body Layer 8
47a75210  Cell Body Layer 10
d2b82afc  Cell Body Layer 12
Cell "AND2_X4" (sorted)
9842af7a  Cell with Comments
5c09dc54  Cell without Comments
c44b732e  Cell Comments
8d50e097  Cell Body Layer 8
affaf547  Cell Body Layer 10
7ea3c984  Cell Body Layer 12
【０５１８】
このコマンドが実行される時、
sigcompare -database -new sigcompare_version1_4.txt \
-prod sigcompare_version1_3.txt \
-depr sigcompare_version1_2.txt \
-bad sigcompare_version1_1.txt \
-test design_from_database.txt
【０５１９】
以下のレポートが生成される。
Summary of all comparisons:
1  cells have no good matches
1  of these cells are hierarchical
2  cells are perfect matches with known bad cells
1  of these matches are under different names
1  cells are partial matches with deprecated cells
1  cells are partial matches with new cells
1  of these matches are under different names
2  cells are perfect matches with production cells
1  of these matches are under different names
File "design_from_database.oas", cell "top": no good matches.
cell is hierarchical.
File "design_from_database.oas" cell "AND2_X4A" is a perfect match with
File "lib_v1_1.gds" bad cell "AND2_X4":
no Cell Interface data is present
Cell Body data matches perfectly:
Cell Body Layers matched:
10 12 8
no Cell Body non-Geometric Layer data is present
File "design_from_database.oas" cell "AND2_X4" is a perfect match with
File "lib_v1_1.gds" bad cell "AND2_X4":
no Cell Interface data is present
Cell Body data matches perfectly:
Cell Body Layers matched:
10 12 8
no Cell Body non-Geometric Layer data is present
File "design_from_database.oas" cell "AND2_X2" is a partial match with
File "lib_v1_2.gds" deprecated cell "AND2_X2":
no Cell Interface data is present
Cell Body data matches partially:
Cell Body Layers matched:
10 12
Cell Body Layers mismatched:
8
no Cell Body non-Geometric Layer data is present
File "design_from_database.oas" cell "AND2_X3" is a partial match with
File "lib_v1_4.gds" new cell "AND2_X1":
no Cell Interface data is present
Cell Body data matches partially:
Cell Body Layers matched:
12 8
Cell Body Layers mismatched:
10
no Cell Body non-Geometric Layer data is present
File "design_from_database.oas" cell "AND2_X5" is a perfect match with
File "lib_v1_3.gds" production cell "AND2_X1":
no Cell Interface data is present
Cell Body data matches perfectly:
Cell Body Layers matched:
10 12 8
no Cell Body non-Geometric Layer data is present
【０５２０】
先に述べたように、最上位のセルは、どのライブラリにも一致しない。物理的デザインプロセス（例えば配置配線）の一部として設計者が生成したセルは何れも、ライブラリには含まれない。通常、これらのセルは、リーフセルとはならないため、レポートは、階層的な、すなわち、他のセルを参照するセルに関して、印字される。
【０５２１】
既知の不良セルとの一致は、不一致のセルの後にリストとして挙げられる。このプログラムモードでは、セル名が異なっても一致が見つかり、レポートされる。例えば、セルAND2_X4Aは、最も古いライブラリ（バージョン１．１）からの既知の不良セルAND2_X4のコピーであり、このことは、設計者がデザインブロック内の当該セルを最新のバージョンで置き換えずに、その名称を変更したことを示唆している。既知の不良バージョンのAND2_X4もまた、元の名称で現れる。
【０５２２】
廃止予定のセルとの一致は、次にリストに挙げられる。ここで、デザインセルAND2_X2と最も一致するのは、廃止予定のライブラリバージョン１．２である。このことは、設計者が、旧式のライブラリで始まるセルを局部的に変更したことを示唆している。レイヤーの類似性及び差異が、セル名及びファイル名と共に示される。
【０５２３】
新しいセルとの一致は、廃止予定のセルとの一致の後にリストに挙げられる。デザインのセルAND2_X3は、新しいライブラリセルAND2_X1と完全に一致する。つまり、セルAND2_X3は、新しいライブラリから異なる名称でコピーされたものであることが分かる。
【０５２４】
最後に、名称の異なる生産セルとの一致がリストに挙げられる。ここで、デザインセルAND2_X5は、ライブラリバージョン１．３の生産セルAND2_X1のコピーである。これは、差し迫った問題ではないが、AND2_X1のバージョン１．３が後に変更された場合、そのコピーは新しいバージョンで置き換えられない。
【０５２５】
-showallオプションが選択された場合、同名の生産セルとの一致が、他のすべての一致の後にリストに挙げられる。この小さな例では、セルレポートが１つだけ追加で印字されているが、通常は、何千ものマッチングセルレポートが印字される。
File "design_from_database.oas" cell "AND2_X1" is a perfect match with
File "lib_v1_3.gds" production cell "AND2_X1":
no Cell Interface data is present
Cell Body data matches perfectly:
Cell Body Layers matched:
10 12 8
no Cell Body non-Geometric Layer data is present
【０５２６】
＜ライブラリ（．ｌｉｂ）ファイルのマッチングについてのレポート＞
Ｌｉｂｅｒｔｙフォーマットファイルtestfiles/tstlibpar2.libには、数個のセルに関するタイミングモデルが含まれている。セルAND2_X2は、cellとscaled_cellの両方の規定を持っている。一実施形態では、これらが組み合わされてセルに関するダイジェストを生成する。セルAND2_X1、AND2_X1_copy、AND2_X1_copy_bは同一である。AND2_X1_copyは正確なコピーであり、AND2_X1_copy_b内の幾つかのステートメントは並べ替えられている。ソートが無い時、ダイジェストは異なる。
otismartsig -sort -lib testfiles/tstlibpar2.lib
...
Cell "AND2_X1"
Interface CRC 0190af2f
Contents CRC 6a059541
Cell "AND2_X1_copy"
Interface CRC 0190af2f
Contents CRC 6a059541
Cell "AND2_X1_copy_b"
Interface CRC 1ee6bb80
Contents CRC e4fa24f0
【０５２７】
セルのpinグループステートメントは、セルインターフェースの一部と考えられる。２つのpinステートメントは、AND2_X1_copy_bで入れ替えられているため、インターフェースとコンテントダイジェストの両方が変更される。
【０５２８】
ソートがある時、すべてのダイジェストは一致する。
otismartsig -sort -lib testfiles/tstlibpar2.lib
...
Cell "AND2_X1"
Interface CRC 0190af2f
Contents CRC dc623050
Cell "AND2_X1_copy"
Interface CRC 0190af2f
Contents CRC dc623050
Cell "AND2_X1_copy_b"
Interface CRC 0190af2f
Contents CRC dc623050
【０５２９】
Ｌｉｂｅｒｔｙフォーマットファイル（例えば、ユニット、動作条件、テーブルインデックス）のヘッダを変更することは、ライブラリのセルに潜在的に影響を与えるため、デフォルトで、ヘッダの非コメントトークンが、ライブラリ内のセルのダイジェストに追加される。ヘッダにおける如何なる変更も、セルダイジェストの変更につながる。
【０５３０】
＜Ｖｅｒｉｌｏｇファイルのマッチングについてのレポート＞
ファイルtestfiles/verilog_test.vには、トランジスタレベルのセルの機能を記述する幾つかの小さいモジュールが含まれる。これらのモジュールの内幾つかはコピーである。例えば、モジュールDFF_X2はモジュールDFF_X1の直接のコピーである。したがって、２つのモジュールに関するダイジェストは、同一である。
otismartsig -ver testfiles/verilog_test.v
...
Cell "DFF_X1"
Interface CRC c102a525
Contents CRC dbac5dc2
Cell "DFF_X2"
Interface CRC c102a525
Contents CRC dbac5dc2
【０５３１】
空行は、セルの中から削除されるが、言語構成物は同じである。どのモジュールにもコメントは含まれないため、コメントダイジェストはレポートされない。
【０５３２】
ファイルtestfiles/verilog_test2.vには、モジュールOAI21_X1及びOAI21_X2が含まれる。後者は、ポートの順番が変わっていることを除いて、同じである。Ｖｅｒｉｌｏｇモジュールは、位置パラメータを用いてインスタンス化されることが多いため、モジュールとの接続は異なり、ダイジェストもまた異なる。
otismartsig -ver testfiles/verilog_test2.v
File "testfiles/verilog_test2.v": Verilog format
File CRC 25de7835
File header CRC 6ef229e6
File comment CRC 6ef229e6
File non-whitespace CRC 07f87fb9
File whitespace CRC ac6fc0b2
Cell "OAI21_X1"
Interface CRC dae46517
Contents CRC c73aceaf
Cell "OAI21_X2"
Interface CRC 01391569
Contents CRC c73aceaf
【０５３３】
しかし、-sortが規定されると、ダイジェストを計算するために、ポートがアルファベット順に並べられて、セルが一致する。
otismartsig -sort -ver testfiles/verilog_test2.v
File CRC 25de7835
File header CRC 6ef229e6
File comment CRC 6ef229e6
File non-whitespace CRC 07f87fb9
File whitespace CRC ac6fc0b2
Cell "OAI21_X1"
Interface CRC cf2d7023
Contents CRC c73aceaf
Cell "OAI21_X2"
Interface CRC cf2d7023
Contents CRC c73aceaf
【０５３４】
＜ＧＤＳＩＩファイルのマッチングについてのレポート＞
ファイルtestfiles/sigtest.gdsは、ＧＤＳＩＩ正則セルダイジェスト計算の特徴の幾つかを示すために構成された合成ＧＤＳＩＩフォーマットファイルである。当該ファイルには、Structure_1からStructure_4までの４つのセルが含まれており、Structure_2は、他の３つのセルによって参照されるリーフセルである。ストラクチャ及び配列参照は、レイヤー番号はなく、そのため、これらのダイジェストは、非レイヤーデータとしてレイヤー−１に記憶される。
otismartsig -gds testfiles/sigtest.gds
File "testfiles/sigtest.gds": GDS format
File CRC d0b40760
Cell "Structure_1"
Comment CRC b0f5064e
Layer -1 CRC 485b93e7
Layer 3 CRC 58ffb953
Layer 42 CRC e6098359
Cell CRC 4658afa3
Cell "Structure_2"
Comment CRC 6acc5ddd
Layer 1 CRC 0e517512
Layer 5 CRC 00065ea8
Layer 19 CRC 931b9a0f
Cell CRC f780ec68
Cell "Structure_3"
Comment CRC b0f5064e
Layer -1 CRC 485b93e7
Layer 3 CRC 58ffb953
Layer 42 CRC e6098359
Cell CRC 4658afa3
Cell "Structure_4"
Comment CRC 9d8b21ad
Layer -1 CRC 485b93e7
Layer 3 CRC 47a23fdd
Layer 42 CRC e6098359
Cell CRC 747b0ece
【０５３５】
Structure_3は、Structure_1の直接のコピーであるため、そのダイジェストはすべて、Structure_1のダイジェストと同じである。Structure_4のレイヤー３にあるポリゴンは順番が異なっており、そのため、レイヤー３に関するダイジェストはStructure_1及びStructure_3とは異なっている。任意で、otismartsigユーザは、ポリゴンのソート、及び、ダイジェストされるデザインデータを再構成するための他の工程を指定することが可能である。
【０５３６】
＜＜ＩＣデザインの問題を解決するための正則ダイジェストの適用＞＞
正則ダイジェストの計算及び比較は、集積回路の設計において、多くの点で実用的に役に立つ。クレームされた技術の様々な実施形態は、様々な問題に対処している。この技術の使用例の幾つかは、上記に挙げた通りである。図３は、開示された技術を有効に適用することができる設計工程における接合点を示している。図３のブロックのほとんどは、図１のブロックと一致する。図３で追加されているのは、監査３６２であり、これは、ファウンドリで製造された製品設計の独立した再検討を示しており、製品設計に有償のデザインテンプレートがあるかどうかを検証する。破線で示されたブロック３０１は、正則ダイジェストの計算と比較の適用が有効な接合点に設けられており、すべてを網羅する意図はない。論理合成１２３の前に、合成に用いられるセルデザインのライブラリの妥当性を検証することができる。セルデザインのライブラリ１３１への組み込みのために、新しいデータがファウンドリ１４１から受け取られる時、変更の重要性が検討及び評価される。フロアプランニング１３３の前後に、承認されたセルの使用、セルの改名及び変更のために、また、不良セルを使用しないために、デザインを精査することができる。監査工程３６２の一部として、製品設計におけるセルの正則ダイジェストが、有償のセルデザインのダイジェストと比較することができる。製品設計のセルのリスト及びカウントを、使用料を監査するために生成することができる。こうした有用な適用例について、以下のセクションにおいて更に説明する。
【０５３７】
＜共通の主題＞
上記の有用な適用は、コンピュータによって実行される、２以上のファイルに存在する回路のデザインデータ間の類似性及び／又は差異の評価方法に依存している。コンピュータは、デザインデータ内のセル又はデザインユニットを認識するために用いられる（セル及びデザインユニットは上述した通りである）。セルは、すでに説明したように、複数のブロックにグループ化されている。ファイルには、１つのヘッダ又はセルから構成されるものもある。セルにおいて、デザインデータの構文が解析され、正則形式に標準化される。正則形式にすることによって、デザインデータにおける非機能的変動に対するデータ分析の感受性を低下させることができる。ダイジェストは、正則形式のデザインデータの少なくとも一部に関して計算され、記憶される。セル又はデザインユニット毎に、少なくとも１つの（通常は１以上の）ダイジェストが生成される。ダイジェストは、特定のセルの一部とはみなされないファイルヘッダに関しても生成される。１つのファイルにおけるセルのダイジェストは、他のファイルにおけるセルのダイジェストと比較される。特定の分析に対して、類似性と差異の内どちらがより適切かに従って、適切なサマリーが生成される。サマリーは、人間が読めるレポートであるか、或いは、他のプログラムによって更に処理されるためにコンピュータファイルに記憶される。
【０５３８】
＜更新されたセルデザインライブラリの理解＞
設計者が直面する問題の１つは、デザインライブラリの新しいバージョンが、ファウンドリ、ライブラリベンダー、内部の開発グループから、バージョンが上がった際の変更について満足のいく説明がないまま渡されることである。新旧のライブラリを比較するためには、従来の差分ツールが使用できる。上述の通り、差分ツールは、変更の重要性を評価するというよりも、変更を警告するように設計されている。ライブラリの新旧バージョンのダイジェストの計算は、変更されたセルの認識に使うことができる。機能的データと非機能的データ間でセルを区分して、レイヤーに分割することによってダイジェストを生成することができる。そのダイジェストから、ライブラリの管理者は、新バージョンのライブラリに対する変更の重要性を推測し、更に詳細に調査することができる。ライブラリのバージョンを示すコメントへの変更、又は、Ｓｏｆｔ  ＩＰ  Ｔａｇｇｉｎｇを利用したＩＰタグへの変更といった、非機能的データにおける変更は、機能的に重要なデータにおける変更とは区別される。この区別は、フィルタ又はカラーコードサマリーに使用することができ、ライブラリ管理者が何処で詳細に調べるべきかを決定するのにも役立つ。
【０５３９】
＜更新されたセルデザインライブラリを開発中に採用するかどうか＞
集積回路設計は、何万ものセルと、何十或いは何百もの複雑なデザインテンプレートを用いる繰り返し処理である。論理設計チームは論理合成を用いて構造ネットリストを生成し、生成された構造ネットリストは配置配線工程のために集積チームに送られる。設計工程の最終段階においては、最上位のブロックが配置配線、及び、最適化されるため、デザインで確実にすべてのライブラリ要素について最新バージョンを使うことは有用である。
【０５４０】
しかし、配置配線の第１ラウンドまでに、設計プロジェクトにおいてあまりにも多くの投資を行うと、プロジェクト管理者は、ライブラリで何が変更されたのか、デザインの改訂に必要な新バージョンのライブラリを受け取る前になぜ変更されてしまったのかを知りたいと思うだろう。例えば、タイミングモデルが変わったとすると、新しいタイミングデータをマッチングする際に、配置の最適化（ｉｎ−ｐｌａｃｅ  ｏｐｔｉｍｉｚａｔｉｏｎ）の別のラウンドが必要となる。Ｌｉｂｒａｒｙ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（ＬＥＦ）ファイルにおけるセルのフットプリント（ｆｏｏｔｐｒｉｎｔｓ）が変わった時、新しい配置配線工程が必要となる。結果として、タイミングに大きな変更が生じ、更なる繰り返し処理が生じる。これらの工程の何れかをやり直すことは、性能目標を達成できない、或いは、期限に間に合わないといったリスクを伴う。こうしたリスクと、新バージョンのライブラリが対処する歩留まりや機能的問題のどちらを採るか、比較検討が必要である。
【０５４１】
開示された技術は、開発中のデザインにおいて実際に使われているセルについて、更新されたセルデザインライブラリの分析を適用するために使用できる。相当な投資がされた後で、プロジェクト管理者が、更新されたセルライブラリを採用するかどうかを決定する必要がある場合に、開発中のデザイン、古いライブラリセル、新しいライブラリセルの３通りのダイジェストの比較が役に立つ。プロジェクト管理者が決定を下す前に、複数のデザイン言語によるデザインデータの複数のビューを検討することができる。
【０５４２】
＜デザインデータにおける未承認及び／或いは不良セルの発見＞
セルには、会社内、及び、ベンダーに多くの潜在的なソースがある。セルが承認済みのソースから来たものか、或いは、未承認のソースから来たものかを判断することは有用である。更に、当初は承認されていたセルが不良であり、ソートのブラックリスト（すなわち、どのデザインにも使うべきでない不良セルのリスト）に載っていることが判明することもある。正則ダイジェストの有用な適用例の１つは、デザイン内のどのセルが承認済みのセルライブラリで見つからないかを判断することである。別の有用な適応例では、デザイン内のセルが、デザインで使ってはいけない不良セルのライブラリに一致するデータを有するかを判断することである。当然、これらの使用法は組み合わせることができる。
【０５４３】
＜デザインデータにおいて名称変更されたセルの認識＞
設計の間、設計者は、ツールによってはセル名が一意でなければならないものもあるため、重複を避けるためにセル名を変更する。名称の重複があった場合、当該セルの使用がどちらも同じセルバージョンに依存していたかを調査し、異なるバージョンから選択することが理想である。しかし、進行中の設計プロジェクトのプレッシャーにより、理想的な作業を行えない場合も多い。そのため、設計者は、単純に今使っているセルの名称を変更し、そのままにしておく。
【０５４４】
正則ダイジェストを使って、名称変更されたセルの起源を見つけることが可能である。名称変更されたセルのダイジェストと、セルライブラリを比較すれば、特に、作業グループの規則又は予測によってセルの名称変更が阻止されている場合に、セルの起源について、セル内のコメントよりも信頼性の高い情報が得られる。ダイジェストの比較によって、名称変更されたセルが承認済みのデザインに一致することを証明することができ、設計管理者又は設計者は、セル名を承認済みのデザインで使われている名称に自信を持って戻すことができる。デザインツールでセル名を参考として用いる際には、承認済みのライブラリ要素に一致する名称を使うことが望ましい。
【０５４５】
＜保証を危うくするセル変更の検出＞
ベンダーから提供されたテンプレートで始める設計チームは、テンプレートに関して改善を図ろうとする。例えば、コンパイルされたランダムアクセスメモリは、現在のデザインの認知されている必要性により適合するように変更される。しかし、設計者が、変更の結果を十分に理解していないことも考えられる。例えば、通常のプロセス条件でメモリのスピードを上げる変更を行うと、他のプロセス条件におけるメモリのスピードを落とす可能性もある。半導体産業において、これは、他のプロセスコーナーにおいて起きることとして知られている。また、デザインにおける変更は、ブリッジ故障（ｂｒｉｄｇｉｎｇ  ｆａｕｌｔｓ）又は接点切断（ｏｐｅｎ  ｃｏｎｔａｃｔｓ）が生じて回路の歩留まりが悪化する可能性もある。こうした変更は、ベンダーから受け取ったデザインテンプレートの明示的な或いは暗示的な保証を無効にするかも知れない。
【０５４６】
複数のダイジェストを有するセルは、それが別のセルの変更後のバージョンであるかどうかを判断するために、分析することができる。幾つかの例では、複数のライブラリセルは、複数のレイヤー間で一致する。例えば、すべてが同じ機能を持つセルからなるクラス内の金属レイアウトは一致する。すべてのレイヤーではないが、幾つかのレイヤー間で一致が検出された時、未承認の変更が行われたかを判断するために、更なる分析を行うことができる。任意で、セルの共通クラスのメンバー間の通常の変更以外の変更を示唆する、レイヤーの変更を重視するために、この分析に重点を置くことが可能である。
【０５４７】
＜使用料の監査＞
テープアウトのデータは、通常、製造工程の一部としてファウンドリで利用される。このテープアウトのデータは、ＯＡＳＩＳ、ＧＤＳＩＩ、或いは、別の言語で表現される。このデータには、製造ツールとして使用されるマスク、或いは、製造中の直接書き込みに用いられるマスクを定義するポリゴンが含まれる。
【０５４８】
テープアウトデータからのダイジェスト化されたセルは、セル内のポリゴンに基づいて、有償のライブラリからダイジェスト化されたセルと比較することができる。これらのポリゴンは、ソートによって標準化される。任意で、セル内のポリゴンを統合し、一貫性のある分割アルゴリズムを適用してそれらを再度バラバラにすることによって、更に標準化することができる。
【０５４９】
ファウンドリで使用されたデザインの監査、及び、支払うべき使用料の計算にセルダイジェストを用いると、監査担当者が、ダイジェスト化されたデザインデータに直接アクセスせずに、ダイジェストを分析できるという利点がある。ファウンドリがダイジェストツールを実行する時に、監査担当者は、結果的に得られるダイジェストを見るだけでよい。ダイジェストに限定せず、監査担当者に、更にデザインデータを見せることによって、細部に至る疑問点（ｃｌｏｓｅ  ｑｕｅｓｔｉｏｎｓ）が解決できる。
【０５５０】
使用料の監査は、ポリゴンデータの代わりに、記号、テキストベースのデザインデータに対して行うこともできる。
【０５５１】
＜故障分析に対する迅速な応答＞
故障分析によって、デザインテンプレートが不良で、製造に用いるべきでないことが証明されることが時々ある。これは、デザインテンプレートの名称変更及び変更のために、デザイン管理者にとって重大な問題を提示する。正則ダイジェストは、既存の製品設計と進行中のデザインをすばやく検査する方法を提供する。不良であると証明されたデザインテンプレートにおける１又は複数の変更のダイジェストは、既存の製品に関するダイジェストのライブラリ、及び、進行中のデザインに関するプロジェクトファイルと比較することができる。不良デザインテンプレートのダイジェストと一致する、或いは、部分的に一致するダイジェストを有するデザインは、更なる調査のために、警告される。これにより、設計管理者は、元のデザインライブラリとリンクされたままのセルだけでなく、それ以上を発見することができる。また、不良デザインテンプレートの故障を引き起こすレイヤーを共有する、改名されたセル及び変更されたセルを見つけることができる。
【０５５２】
＜＜コマンドラインプロセッサの実行時間オプション＞＞
プロトタイプの正則セルダイジェストのコマンドラインユーティリティ名は“ｏｔｉｓｍａｒｔｓｉｇ”であり、２．４．ｘ以降のカーネル（例えば、Ｒｅｄ  Ｈａｔ  Ｅｎｔｅｒｐｒｉｓｅ  Ｌｉｎｕｘ  ４．ｘ以降）上で動く３２又は６４ビットＬｉｎｕｘで実行可能である。これをアーギュメントなしで実行した場合、以下と同様のヘルプテキストが印字される。
Oasis Tooling Smart Digest utility 1.0 alpha (r867)
Copyright (c) 2007-2008 by Oasis Tooling Inc.  All Rights Reserved.
Usage: otismartsig [flags] -type file... [-type file...]
Available flags:
-file: treat the next argument as a file name, even if it begins with '-'
-mem number: maximum memory usage in megabytes (default 64)
-64: compute 64-bit digests
-sort: sort records before computing digests
-nosort: do not sort records before computing digests
-noheader: omit Liberty file header from cell digests
-verbose: print errors as they are found (useful in debugging)
-grid number: record layout file digests using the specified
grid (default 1.0e-9 meter)
Available file types:
-oas: OASIS geometry database (default: -sort)
-gds: GDS geometry database (default: -sort)
-lib: Liberty library format (default: -sort)
-ver: Verilog RTL and netlist format (default: -nosort)
-vhd: VHDL RTL and netlist format (default: -nosort)
-spi: SPICE subcircuit netlist format (default: -nosort)
-lef: Library Exchange Format (default: -sort)
-def: Design Exchange Format (default: -sort)
-txt: unstructured text files (default: -nosort)
-stxt: structured (e.g. script) text files (default: -nosort)
-user: user-parsed files (default: -nosort)
-bin: unstructured binary files (default: -nosort)
【０５５３】
＜ファイルタイプ＞
ファイルは、規定されたファイルタイプを有する。ファイルのフォーマットを推測するために、ファイルのヘッダを分析することは可能であるが、誤りを生じる可能性が高いと思われる。例えば、セルベースのテキストファイルは、非構造化ファイルとして誤解されるかも知れない。
【０５５４】
１以上のタイプのファイルが、必要に応じて、１回の実行で分析される。新しいファイルタイプのアーギュメントが規定されると、そのアーギュメントの後のファイルはそのフォーマットを使用する。以下の例では、最初の２つのファイルが非構造化テキストファイルとして解釈され、最後のファイルがＶｅｒｉｌｏｇファイルとして解釈される。
otismartsig -txt file1.txt file2.txt -ver file3.txt
【０５５５】
ファイル名が‘-’で始まる場合、その名称は、前に-fileが付く。各ファイルにつき、１つの-fileアーギュメントが使用できる。
【０５５６】
＜オプション：-sort＞
ほとんどのファイルフォーマットは、データのソートのオプションを提供している。幾つかのフォーマットに関しては、ソートがデフォルトとなっている。なぜなら、ソートされたデータを用いて生成されたダイジェストは、ソートされていないデータを用いたダイジェストよりもより有用なマッチングを生成するためである。デフォルトの動作は、ファイルフォーマットの簡単な説明の最後で、ヘルプテキストに以下の通りに規定されている。
・  ＯＡＳＩＳ：ＯＡＳＩＳライターは、特に書き込みの繰り返し時に、データの順番を変える可能性が高いため、デフォルトでソートされる。
・  ＧＤＳＩＩ：ＧＤＳＩＩライターは、データの順番を変える可能性があり、また、ＧＤＳＩＩセルデータは、ＯＡＳＩＳデータに対して一致させる必要があるため、デフォルトでソートされる。
・  Ｌｉｂｅｒｔｙ：データが順序非依存であるため、デフォルトでソートされる。
・  Ｖｅｒｉｌｏｇ：セルインターフェースレコードしかソートされないため、デフォルトではソートされない。
・  ＶＨＤＬ：セルインターフェースレコードしかソートされないため、デフォルトではソートされない。
・  ＳＰＩＣＥ：ソートルーチンもセルインターフェースレコードをソートするため、デフォルトではソートされない。
・  ＬＥＦ：データの多くが順序非依存であるため、デフォルトでソートされる。
・  ＤＥＦ：データの多くが順序非依存であるため、デフォルトでソートされる。
・  非構造化テキスト：ファイルの目的が不明であるため、デフォルトではソートされない。
・  構造化テキスト：スクリプトファイルが順序依存であるため、ソートは許可されない。
・  ユーザ構文解析ファイル：ファイルの目的がソフトウェアにとって不明であるため、デフォルトではソートされない。
・  非構造化バイナリ：レコード構造がないため、ソートは許可されない。
【０５５７】
Ｖｅｒｉｌｏｇ、ＶＨＤＬ、ＳＰＩＣＥファイルに関して、幾つかのインスタンス化で、連想ベースのポート参照（パラメータ名に基づく接続）ではなく、位置的なポート参照（パラメータの順番に基づく接続）を用いた場合、インターフェースレコード（ポート）のソートによって、セルの意味が変更される可能性がある。したがって、こうしたフォーマットのソートは、慎重に行わなければならない。
【０５５８】
ユーザが、デフォルトではソートされない所定のフォーマットのファイルをソートしたい場合は、-sortオプションを規定する。ユーザがファイルをソートしたくない場合は、-nosortオプションを規定する。これらのオプションは、コマンドラインに後でリストに挙がるすべてのファイルに影響するという意味合いで、「粘着的（ｓｔｉｃｋｙ）」である。
【０５５９】
＜オプション：-mem＞
-memオプションは、ソートに許されたメモリの最大量を、メガバイトで規定する。本実施では、ソートはメモリにおいて排他的に行われるため、セル又はファイルヘッダに関して見積もられたメモリ使用量がこの制限を越えると、影響を受けたデータがダイジェスト計算に元の順番で送られ、当該セル又はファイルヘッダに関して、ソートが無効化される。セルは、ソートが可能かを検査されて、最小限のメモリしか利用できなくても、マッチングを増加させ、差異の誤検出を減少させるために、すべての小さなデザインテンプレートブロックがソートされる。一般的に言って、メモリ使用限度を超えるのは、大きな配置配線ブロックのみである。
【０５６０】
デフォルトのメモリ使用限度は、６４メガバイトである。３２ビットＬｉｎｕｘプラットフォームでは、最大メモリ使用限度は３５００メガバイトである。-memが与えられた値が１６よりも小さい場合、警告無しにその値は１６まで増加し、３５００よりも大きい場合は、警告無しに３５００まで減少する。
【０５６１】
メモリ割り当て方法において不確定要素があるために、ツールのメモリ使用の推定は正確ではない。正則セルダイジェストを計算しているマシン上の物理メモリの量に近いメモリ限度は使わない方が賢明である。ファイルフォーマットに関するメモリの推定は楽観的である。
【０５６２】
同一ファイル内には、ソートされるセルもあれば、大きすぎてソートされないセルもあるため、正則セルダイジェストツールは、-sortが設定されていた（或いはデフォルトだった）ためにセルがソートされたのか、-nosortが設定されていた（或いはデフォルトだった）ためにセルがソートされなかったのか、-sortが設定されていたが大きすぎてソートされなかったのか、をレポートする。
Cell "Structure_1" (sorted)
Cell "Structure_1" (not sorted)
Cell "Structure_1" (unable to sort)
【０５６３】
ソフトウェアは、所定のセルに関するダイジェストが、ソートされたデータを示しているか否かについて、フラグ等が示す情報を、ダイジェストで監視し、記憶する。メモリの使用限度が増加した場合、或いは、ユーザが新しいより効果的なバージョンの正則セルダイジェストソフトウェアを使い始めた場合、以前はソートできなかったセルがソート可能となる（或いは、ユーザがメモリの使用限度を下げた場合はその逆）。ダイジェストがソートされたデータから計算されたかについての情報をデータベースが記憶していない限り、ユーザは、ダイジェストにおける変更が、データの本当の変更を示しているのか、或いは、単純に、一部のダイジェストはソートされたデータに関しており、残りのダイジェストはソートされていないデータに関しているためなのかを判断することができない。
【０５６４】
＜オプション：-64＞
デフォルトでは、３２ビットダイジェストが生成される。-64オプションが指定された場合は、６４ビットダイジェストが生成される。
【０５６５】
６４ビットダイジェストの生成は、３２ビットダイジェストの生成よりも実行時間が多少長くなる。６４ビットダイジェストは、６４ビット実行ファイルだけでなく、３２ビット実行ファイルにおいても利用可能である。
【０５６６】
＜オプション：-verbose＞
デフォルトでは、プログラムは、ダイジェストレポート又は一般的なエラーメッセージを生成する他は何も警告することなく、動作する。構文解析ツールは、人間の使用に対してではなく、自動化されたダイジェスト生成に対して最適化される。ファイルが構文解析に失敗し、実際のエラーを参照することが有用な場合、-verboseフラグを使用することにより、エラーが印字される。構文解析ツールの多くは、最初のエラーが見つかった後に停止するため、エラーレポートは特に長くなるわけではない。何らかのエラーが見つかると、ダイジェストは生成されない。
【０５６７】
＜オプション：-grid＞
ＯＡＳＩＳ及びＧＤＳＩＩファイルの幾何形状は、グリッド上に描かれる。すなわち、ファイル内のすべての座標が、幾何形状の絶対的なサイズをミクロン或いはナノメータで決定する数によってスケーリングされる。このグリッドは、意味が明確になるようにファイル内に記録されるが、何らかの理由で、グリッドの値が変わった場合、幾何形状は変わっていなくても、セル内のすべての座標が変わってしまう。グリッドによってすべての座標をスケーリングすることは、効果的な解決方法とは言えない。なぜなら、グリッドは、浮動小数点数であり、典型的には１０の累乗であるためである。不動小数点数に関するダイジェストは、マシン依存であるか、或いは、丸め誤差に対して脆弱である可能性がある。
【０５６８】
したがって、ＯＡＳＩＳ及びＧＤＳＩＩファイルには-gridオプションが存在する。すべての座標は、このグリッド（例えば１ナノメータ（デフォルトでは、１．０ｅ−９メータ））の倍数となるようにスケーリングされる。例えば、ファイルのグリッドが１０ナノメータで、正則セルダイジェストのグリッドが１ナノメータである場合、ファイルからのすべての座標は、ダイジェストの計算に送られる前に、１０倍される。ＯＡＳＩＳ或いはＧＤＳＩＩファイルグリッドが、-grid値の整数倍ではない場合、エラーが印字される。
【０５６９】
＜オプション：-noheader＞
Ｌｉｂｅｒｔｙフォーマットファイルは、ファイルヘッダに多数の定義とユニット定義を有する。これらのファイルヘッダ値の幾つかが変化した場合、すべてのセルにおけるすべての値（例えば、遅延）も同様に変化する。例えば、ファイルヘッダのtime_unit値又はvoltage_unit値が変化した場合、セル内のテキストが変わっていなくても、セルのタイミング遅延値のすべてが同様に変化する。Ｌｉｂｅｒｔｙファイルは、個々のセルに関するデータを持つ、固定されたファイルヘッダを連結するスクリプトによって構成されていることが多いが、誤ったヘッダを用い易い。したがって、デフォルトで、（日付等の非機能的値を除く）ファイルヘッダ値のすべてが、Ｌｉｂｅｒｔｙファイルにおけるセルに関するダイジェストに追加される。ユーザにこのエラーが起こらない自信がある場合は、-noheaderオプションを用いて、ヘッダ値の統合を無効にすることができる。
【０５７０】
＜＜特定の実施形態＞＞
開示された技術は、様々な方法及び装置で有効に適用することができる。また、当該技術は、前記方法を実行する、或いは、ハードウェアと組み合わせて前記装置の生産が可能なコンピュータプログラムを記憶する、コンピュータ可読記憶媒体等の製造物品（ａｒｔｉｃｌｅｓ  ｏｆ  ｍａｎｕｆａｃｕｒｅ）においても具体化される。
【０５７１】
第１の実施形態のグループでは、方法について説明する。これらは、コンピュータメモリに記憶された少なくとも２つのファイルに存在するデザインデータ間の類似性及び／又は差異を評価する、コンピュータによって実施される方法である。図６及び７は、これらの方法の幾つかの態様の高レベルのフローチャートを示している。デザインデータ環境において、データは記号、或いは、バイナリである。記号によって、人間が解読可能であることを意図したテキストを意味している。例えば、数値及び文字である。記号のファイルもまた、テキストを解読可能にする、或いは、内部ファイル管理に役立つコードを含む。例えば、タブ文字、フォント属性、ブックマーク（ｂｏｏｋ  ｍａｒｋｓ）である。デザインファイルは、上述の設計言語又はフォーマットの何れかで表現される。その中には、頂点や半平面によって定義されるポリゴンが含まれる。デザインファイルは、階層的（他のデザインデータへの参照を含む）であり、展開されるか、或いは、階層的フォーマットである。幅広い範囲のデザインデータが考えられる。上述の通り、２つのファイルへの参照は、包括的（ｇｅｎｅｒｉｃ）である。２つのファイルは、同じデータベースの一部である。２以上のファイルが関連している。
【０５７２】
前記方法は、第１及び第２ファイル４１１に存在するデータに関して機能する。この説明では、前記方法を、デザイン内のセルに対して機能し、正則セルダイジェストを生成するものとする。正則（ｃａｎｏｎｉｃａｌ）とは、規格化された（ｓｔａｎｄａｒｄｉｚｅｄ）フォーマットを意味する。幾つかのデザインデータファイルは、構文解析ツールに渡され、構文解析規則を適用されることによって正則フォーマットに標準化、或いは、変換される。他のファイルは、構文解析、或いは、ファイルを標準化するための他の操作によって生成される構文木の意味解析を必要とする。構文解析規則に従って、標準化は、空白を削除し、プログラムコードからコメントを区別し、構文木のトークン又は枝をソートし、機能的又は非機能的デザインデータとして構文木のトークン或いは枝を分類し、ヘッダとセルデータ間でデータを分割する、或いは、セル内のデータをセルヘッダとセルボディデータ間で分割し、ポリゴンの頂点を並べ替える、或いは、上述の、他の構文解析及び標準化方針（ｎｏｒｍａｌｉｚａｔｉｏｎ  ｓｔｒａｔｅｇｉｅｓ）を適用する。前記方法は、より一般的には、データのデザインユニットに適用され、「デザインユニット」という語は、後で述べる説明、及び、当初出願したクレームにおける「セル」と置き換えが可能である。本開示では、ファイル内のデザインデータが、ヘッダデータとセルデータにどのように区分できるかを示す。区分（ｐａｒｔｉｔｉｏｎ）又は区分された（ｐａｒｔｉｔｉｏｎｅｄ）とは、物理的に或いは論理的にグループに分割することを意味する。以下に説明するように、構文木を生成する構文解析規則によって、データの物理的区分が自ずと生成される。構文木が生成されると、タグ又はフラグは構文木のノード或いは枝に適用される。タグは、通常は、特別な意味を持つコードである。フラグもコードであるが、タグよりは単純であり、特別な意味を持つフィールドにおけるブール型の値である。以下に続く方法の説明は、デザインユニット及びセルに等しく当てはまる。前記方法は、ファイルに存在するデザインデータ内のセルを認識する工程６１１を含む。前記方法は、更に、構文の解析を行う工程６１２と、セル内のデザインデータを正則形式に標準化する工程６１３を含む。構文解析は、記号ファイル又はバイナリファイルの何れかに適用することができる。記号ファイルの構文解析では、トークンを認識し、言語を記述する一連の構文解析規則からファイルにおけるそれらの役割を判断する。バイナリデザインデータファイルの構文解析では、バイナリデータの要素及びグループを認識し、デザインファイルのバイナリフォーマットを記述する構文解析規則からデザインデータにおけるそれらの役割を判断する。構文解析には、しばしば、構文木の構築が含まれる。或いは、構文解析によって一連のイベントが生成することができる。標準化は上で述べた通りである。正則形式は、１又は複数の構文木５３２で維持される。正則形式によって、特定のセル内のデザインデータにおける非機能的なばらつきに対するデータ分析の感受性が低下する。デザインデータにおける非機能的変化とは、デザインデータを用いて生産された物理的回路を変化させない、デザ���ンデータに対する変更である。例えば、コメントは、通常、非機能的デザインデータであり、空白は、通常、記号ファイルにおいて非機能的である。ポリゴンの角の座標の順番リストにおいて、開始座標の選択、及び、角が時計回りに並ぶか、半時計回りに並ぶかは、通常、非機能的であると言える。製造工程で使われる特定のツールの演算には特定の分割アルゴリズムが必要であるが、高レベルにおいて、複雑なポリゴンを例えば台形や三角形に分割しても、生産された物理的回路の機能的な変更にはつながらない。前記方法は、更に、正則形式の少なくとも選択されたデザインデータのダイジェストを計算する工程６１４、及び、そのダイジェストを記憶する工程４１５を含み、セル毎に少なくとも１つのダイジェストを生成する。
【０５７３】
前記方法は、正則形式のダイジェストを比較し（６１５）、前記ダイジェストの比較の少なくとも幾つかの結果をサマライズする（６１６）。そして、別のプログラムに利用可能なデータテーブルといったサマリーをメモリに生成する（４７３）か、或いは、ユーザが閲覧可能なレポートを生成する（４７５）。
【０５７４】
この比較は、複数の方法で実行可能である。１以上のセットのダイジェストが、検索可能なデータ構造に記憶される。便利で検索可能なデータ構造は、ダイジェストのモジュールでインデックスが付けられたハッシュテーブルである。別にハッシュ関数を使用することもできる。ハッシュテーブルのサイズは、必要とされる記憶装置、及び、テーブルに対するハッシュの衝突の所望する頻度に基づいて選択される。衝突の場合、ハッシュテーブルにリンクしたリストが生成される。或いは、ダイジェストのソートを犠牲にして、ダイジェストの反転したインデックスが生成される。多くの実施形態において、セル毎に複数のダイジェストが存在する。複数のダイジェストを比較及び評価する１つの方法としては、対象となるセルに関するダイジェストに一致するダイジェストを有するすべてのセルのリストを生成することが挙げられる。幾つかの実施形態では、このリストは、例えば、最新のライブラリからのセルが古いライブラリからのセルよりも先行するように並んでいる。候補となるセルのリストを用いて、対象セルのすべてのダイジェストと、候補セルのダイジェストで比較を行う。特に、並べられたリストに関して、対象セルのすべてのダイジェストが、候補セルのダイジェストの内１つと一致した時、比較は終了する。対象セルが、候補セルの何れとも完全に一致しなかった場合は、一対のセルが類似していると見なされる複数のダイジェストの一致に対して、閾値又は比が適用される。或いは、完全な一致がない場合に、部分的な一致が順位付けされ、１つ又は複数の部分的な一致がサマライズ又はレポートされる。
【０５７５】
前記方法の１つの態様は、ダイジェストを計算及び記憶する前に、正則形式内で、機能的に重要なデザインデータ７２２を、重要でないデータから区分する工程が含まれる。デザインデータにおける変更が、デザインデータから生成された回路に変更をもたらす場合、デザインデータは機能的に重要であると言える。その時、ダイジェストの計算に使われる正則形式の選択されたデザインデータには、少なくとも機能的に重要なデザインデータが含まれている。
【０５７６】
ダイジェストの更に細かい比較は、セルヘッダ、インターフェース、ボディの何れか又はその組合せ（７２１）によって、レイヤー（７２３）によって、ソート可能な／順序依存のデータ（７２４）によって、セル内のデザインデータを区分することにより可能となる。区分方針（ｐａｒｔｉｔｉｏｎｉｎｇ  ｓｔｒａｔｅｇｉｅｓ）によって、物理的或いは論理的なデータの区分が生成される。物理的なデータの区分とは、第１及び第２リストといった物理的に分けられたグループに、データを分けることである。論理的なデータの区分とは、コンピュータがデータの項目を特定のグループに属するものと認識するように、データにタグを付ける、或いは、フラグを立てることである。これらの区分方針は、個別に、或いは、組み合わせて適用される。構文解析７１２は、デザインデータを所望するように区分することが可能な、１又は複数の構文木５３２を生成する。区分方針によっては、この構文解析７１２によって、構文木内のノード及び枝がどのように構築されるかが定義されるものもあれば、構文木のノード又は枝にフラグが設定されるものもある。フラグについては上述した通りである。ダイジェストの計算及び記憶は、１つの区分につき、少なくとも１つのダイジェストを生成することを更に含む。サマリーを作成することによって、異なる区分タイプから生成される複数のダイジェストを区別する。
【０５７７】
上述の方法は、異なる設計言語を用いて符号化されたファイルの比較に適用される。本開示では、ＯＡＳＩＳとＧＤＳＩＩの２つの設計言語について、如何に比較できるようにするかを説明している。これら２つの言語が比較される際、上述の第１及び第２ファイルは、ＯＡＳＩＳファイルとＧＤＳＩＩファイルとなる。これらの言語は、一致が成り立つのであれば、他の２言語でも構わない。設計言語が異なるファイルを比較する時、設計言語の正則形式によって、少なくともセルのボディのデザインデータが比較可能になる。或いは、セル間の機能的差異がセルヘッダにおいて表現され、セルのボディ自体には表現されない設計言語では、正則形式によって、少なくともセルヘッダ内のデザインデータが比較可能となる。
【０５７８】
前記方法は、セルデザインの古いライブラリに対する、セルデザインの新しいライブラリの評価に適用可能である。次に、第１ファイルは、セルデザインの新しいライブラリであり、第２ファイルは、セルデザインの古いライブラリである。サマライズには、更に、２つのライブラリのダイジェストを比較することによって検出される、新しいライブラリにおける機能的に重要な変更を少なくともレポートすることが含まれる。
【０５７９】
前記方法は、更に、新しいライブラリの採用による影響の評価に適用することができる。この前記方法の適用は、デザインファイルのセルが旧式のライブラリに属しているかの判断にも適用される。この適用には更に、認識、構文解析、計算の各処理が行われる第３のファイルが含まれる。この変形では、第１ファイルがデザインファイルであり、第２ファイルが少なくとも１つのセルデザインの現在のライブラリであり、第３ファイルが少なくとも１つのセルデザインの旧式のライブラリである。サマライズには、現在のライブラリにおけるセルデザインのダイジェストには一致しないが、旧式のライブラリのセルデザインのダイジェストには一致するダイジェストを持つデザインファイルのセルをレポートすることが含まれる。オプションで、現在のライブラリにも旧式のライブラリにも現れないセルデザインもレポートすることができる。このレポートの基準によれば、必然的に、現在のライブラリと旧式のライブラリの両方で同じであるセルデザインはレポートから排除される。本願の方法は、現在のライブラリと旧式のライブラリとを比較する方法であるが、これらの語は、ライブラリの２世代について言及するために用いられ、まだ採用されていない、候補であるバージョン（いわゆる「現在のバージョン」）と生産バージョン（いわゆる「旧式のバージョン」）にも容易に当てはめることができる。
【０５８０】
上記の方法は、不良セル或いは未承認セルを認識することにも適用できる。不良セル又は未承認セルの検出は、別々に、或いは、組み合わせて進めることができる。上記の方法は、デザインファイル内のセルが既知の不良セルの収集物に属するかどうかを判断するために、デザインファイルを評価する際に用いることができる。この用途では、第１ファイルはデザインファイルであり、既知の不良セルを含むファイルと比較される。サマライズには、更に、既知の不良セルのファイルのセルのダイジェストと一致するダイジェストを有するデザインファイルのセルをレポートすることが含まれる。同様に、上記方法は、デザインファイルのセルが少なくとも１つの承認済みライブラリに属するかどうかを判断するために、デザインファイルを評価する際に用いることができる。この場合もやはり、第１ファイルはデザインファイルであり、少なくとも１つの承認済みライブラリと比較される。レポートでは、典型的には、承認済みライブラリのセルのダイジェストと一致しないダイジェストを有するデザインファイルのセルを例外的にレポートする。オプションで、デザインファイルのセルと、承認済みのライブラリのセルの何れかとで完全な一致が見られない場合、部分的な一致がレポートされる。
【０５８１】
更に、上記方法は、名称は異なるが機能的には同じであるセルを検出する場合にも用いることができる。第１ファイルはデザインファイルであり、第２ファイルは少なくとも１つの承認済みのライブラリである。ダイジェストの計算及び記憶は、少なくとも、デザインファイルの複数のレイヤーの機能的に重要なデータと承認済みライブラリに適用される。サマライズには、承認済みのライブラリ（「機能的に一致するセル」と称する）のダイジェストと一致する、複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、機能的に一致するセルとセル名が一致しないデザインファイルのセルを、名称変更されたセルとしてレポートすることが含まれる。オプションで、前記方法は、「名称変更された」とレポートされたデザインファイルのセルを、承認済みのライブラリの機能的に一致するセルと一致し、リンクするセル名に戻すように、拡張することも可能である。
【０５８２】
上記方法の興味深い使い方としては、デザインファイルの保証されたセル或いはその他のセルが、保証されたデザインテンプレートから変更されたかどうかを判断するために、デザインファイルを評価することが挙げられる。第１ファイルはデザインファイルであり、第２ファイルは、少なくとも１つの承認済みライブラリである。ダイジェストの計算及び記憶は、デザインファイルのセルの複数のレイヤー内の少なくとも機能的に重要なデータと承認済みライブラリに対して行われる。サマライズには、更に、承認済みライブラリのセルのダイジェストに一致する、複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを持つデザインファイルのセルを、変更された可能性のあるセルとしてレポートすることが含まれる。
【０５８３】
上記方法の更なる適用として、製品設計を検査して、製品設計で使われている有償のセルデザインを見つけることが挙げられる。こうした用途では、第１ファイルには、有償のセルデザインの１又は複数の有償のライブラリが含まれ、第２ファイルには、セルデザインを含む１又は複数の製品設計が含まれる。サマライズには、更に、有償のライブラリのセルのダイジェストに一致するダイジェストを持つ製品設計の特定のセルを、有償である可能性のあるセルとしてレポートすることが含まれる。オプションで、ほぼ一致するものもレポートすることができる。ほぼ一致するとは、１つのセルの複数のレイヤーに関する複数のダイジェストといった、複数のダイジェストを持つセル又はデザインユニットに当てはまる単語である。
【０５８４】
実施形態の第２グループは、装置である。この装置は、コンピュータメモリに記憶された少なくとも２つのファイルに存在するデザインデータ間の類似及び／又は差異を評価するコンピュータ装置である。上述した図５は、こうした装置の幾つかの態様における高レベルのブロック図を表している。方法の実施形態と同様に、装置によって処理されるデザインデータは、記号又はバイナリである。そのデータは、上記の設計言語又はフォーマットで表される。それにはポリゴンが含まれる。当該データは、階層的（他のデザインデータへの参照を含む）であり、展開されるか、或いは、階層的フォーマットである。幅広い範囲のデザインデータが考えられる。上述の通り、２つのファイルへの参照は、包括的である。２つのファイルは、同じデータベースの一部である。２以上のファイルが関連している。
【０５８５】
前記装置は、少なくとも１つのプロセッサと、メモリ５３０及び５３５を備える。構文解析ツール５３１は、プロセッサ上で実行され、物理的回路のデザインのアスペクトを表すデザインデータを含むファイル４１１を構文解析し、メモリに１又は複数の構文木５３２を生成する。この説明では、前記装置を、デザイン内のセルに対して動作し、正則セルダイジェストを生成するものとする。より一般的には、前記装置は、データのデザインユニットに関して動作し、「デザインユニット」という語は、後で述べる説明、及び、当初出願したクレームにおける「セル」と置き換えが可能であると理解される。
【０５８６】
標準化ロジック５３３は、プロセッサ上で実行され、構文木５３２を構成して正則形式を生成する構文解析ツール４３２と連携する。「標準化ロジック」という語句における、ロジックとは、コンピュータ・コンポーネントの動作を制御する命令を意味する。プロセッサ上で実行されるため、ロジックは、典型的には、プログラムの命令からコンパイルされたオブジェクトコードであると考えられる。プロセッサ内では、ロジックは、マイクロ命令である。フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）のようなプログラマブル・ロジック・コンポーネントにおいては、ロジックは、ゲートと、ゲート間の接続で表される。この用途では、ロジックは、どのようにタスクを実行すべきかをコンピュータ・コンポーネントに教える役割を担う。標準化ロジックには、ファイルを少なくとも１つのヘッダとデザインデータの複数のセルに区分する区分モジュールが含まれる（デザインデータの複数のセルへの分割は、ファイルの符号化に使われる設計言語の規則に従う）。区分モジュールは、ヘッダ及びセルの区分を表す構文木を構築する。上述したように、様々な設計言語において、ファイルにはヘッダデータ又はセルデータ、或いはその両方が含まれる。分かり易くするために、前記装置は、ヘッダ及びセルデータの内１つのみを含むファイルに適用される。
【０５８７】
標準化ロジックは更に、デザインデータの正則形式を生成するための構文木を解釈する正則形式生成モジュールを含み、正則形式によってデザインデータにおける非機能的なばらつきに対するデータ分析の感受性を低下させる。
【０５８８】
前記装置は、更に、メモリ４１５のダイジェストを計算及び記憶するプロセッサ上で実行されるダイジェスタ５３４を備え、１つの区分につき少なくとも１つのダイジェストを生成する。
【０５８９】
比較モジュール５３６は、プロセッサ５３５上で実行され、正則形式のダイジェストを比較する。モジュールは、特定のタスクを実行するロジックのセグメントである。例えば、標準化ロジックには複数のモジュールが含まれる。レポータ５３７もまたプロセッサ５３５で実行され、ダイジェストの比較について少なくとも幾つかの結果をサマライズする。レポータは、メモリに、例えば別のプログラムで利用可能なデータのテーブルであるサマリー４７３、或いは、ユーザが閲覧可能なレポート４７５を生成する。
【０５９０】
比較モジュールを構成する方法は複数ある。１又は複数のセットのダイジェストが、検索可能なデータ構造に記憶される。比較モジュールの構造は、検索可能なデータ構造によって決まる。便利なデータ構造の１つは、ダイジェストの係数によってインデックスが設定されたハッシュテーブルである。別に、ハッシュ関数を使用することもできる。ハッシュテーブルのサイズは、必要とされる記憶装置と、テーブルに対するハッシュ衝突の所望する頻度に基づいて選択される。衝突の場合、ハッシュテーブルにリンクしたリストが生成される。或いは、ダイジェストのソートを犠牲にして、ダイジェストの反転したインデックスが生成される。多くの実施形態において、１つのセルにつき、複数のダイジェストが存在する。複数のダイジェストの比較及び評価方法の１つは、対象セルに関する何らかのダイジェストと一致するダイジェストを有するすべてのセルのリストを生成することである。幾つかの実施形態では、このリストは、例えば、最新のライブラリからのセルが古いライブラリからのセルよりも先行するように並んでいる。候補となるセルのリストを用いて、対象セルに関するすべてのダイジェストと、候補セルに関するダイジェストとを比較する。特に、並べられたリストに関して、対象セルのすべてのダイジェストが、候補セルのダイジェストの内１つと一致した時、比較は終了する。対象セルが、候補セルの何れとも完全に一致しなかった場合は、一対のセルが類似していると見なされる複数のダイジェストの一致に対して、閾値又は比が適用される。或いは、完全な一致がない場合に、部分的な一致が順位付けされ、１又は複数の部分的な一致がサマライズ又はレポートされる。
【０５９１】
区分モジュールは、更に、ダイジェスタがダイジェストを計算及び記憶する前に、正則形式内の機能的に重要なデザインデータと重要でないデータとを区分する。デザインデータの変更によってデザインデータから生成された回路が変更される場合は、デザインデータが機能的に重要である。次に、ダイジェスタ５３４によってダイジェストを計算するために処理される正則形式において選択されたデザインデータには、少なくとも機能的に重要なデザインデータが含まれる。
【０５９２】
ダイジェストの更に細かい比較は、セルヘッダ、インターフェース、ボディの何れか又はその組合せによって、レイヤーによって、ソート可能／順序依存データによって、セル内のデザインデータを区別する区分モジュールによって可能となる。これらの区分方針は、個別に或いは組み合わせて適用してもよい。区分のオプションとして、構文解析ツール５３１は、デザインデータを所望するとおりに区分する１又は複数の構文木５３２を生成する。区分方針によっては、構文解析ツール５３１によって、構文木内のノード及び枝が如何に構築されるかが定義されるものもあれば、構文木内のノード又は枝にフラグを設定されるものもある。ダイジェストを計算し、記憶するダイジェスタは、１つの区分につき、少なくとも１つのダイジェストを生成する。レポータ５３７は、異なる区分タイプから生成される複数のダイジェストを区別する。
【０５９３】
前記装置は、異なる設計言語を用いて符号化された複数のファイルを比較する。本開示では、ＯＡＳＩＳとＧＤＳＩＩの２つの設計言語について、如何に比較できるようにするかを説明している。これら２つの言語が比較される際、上述の第１及び第２ファイルは、ＯＡＳＩＳファイルとＧＤＳＩＩファイルとなる。これらの言語は、一致が成り立つのであれば、他の２言語でも構わない。設計言語が異なるファイルを比較する時、正則形式生成モジュールは、少なくともセルのボディ内のデザインデータを比較可能とする設計言語に関して正則形式を生成する。或いは、セル間の機能的差異がセルのボディではなくセルヘッダに表されている設計言語では、少なくともセルヘッダ内のデザインデータが正則形式で比較可能となる。
【０５９４】
上記装置は、セルデザインの古いライブラリに対して、セルデザインの新しいライブラリを評価する際に用いることができる。第１ファイルは、セルデザインの新しいライブラリであり、第２ファイルは、セルデザインの古いライブラリである。更に、レポータは、２つのライブラリのダイジェストを比較することによって検出される、新しいライブラリの機能的に重要な変更を少なくともレポートする。
【０５９５】
上記装置は、更に、新しいライブラリを採用した時の影響を評価する際に用いることができる。前記装置のこの使用方法は、デザインファイル内のセルが旧式のライブラリに属しているかを判断する際にも用いることができる。この場合、３つのファイルが関連する。第１のファイルはデザインファイルであり、第２のファイルは少なくとも１つのセルデザインの現在のライブラリであり、第３のファイルは少なくとも１つのセルデザインの旧式のライブラリである。レポータモジュールは、比較モジュールからの結果を用いて、現在のライブラリにおけるセルデザインのダイジェストには一致しないが、旧式のライブラリのセルデザインのダイジェストには一致するダイジェストを持つデザインファイルのセルをレポートする。オプションで、現在のライブラリにも旧式のライブラリにも現れないセルデザインもレポートすることが可能である。このレポートの基準によれば、必然的に、現在のライブラリと旧式のライブラリの両方で同じであるセルデザインはレポートから排除される。本願の方法は、現在のライブラリと旧式のライブラリとを比較する方法であるが、これらの語は、ライブラリの２世代について言及するために用いられ、まだ採用されていない、候補であるバージョン（いわゆる「現在のバージョン」）と生産バージョン（いわゆる「旧式のバージョン」）に等しく当てはめることができる。
【０５９６】
上記装置の別の用途としては、不良セル或いは未承認セルを認識することが挙げられる。不良セル或いは未承認セルの検出は、別々に、又は、組み合わせて進めることができる。前記装置は、デザインファイル内のセルが既知の不良セルの収集物に属するかどうかを判断するために、デザインファイルを評価する際に用いることができる。この用途では、第１ファイルはデザインファイルであり、既知の不良ファイルを含むファイルと比較される。レポータモジュールは、既知の不良セルのファイルのセルのダイジェストと一致するダイジェストを有するデザインファイルのセルをサマライズする。同様に、上記装置は、デザインファイルのセルが少なくとも１つの承認済みライブラリに属するかどうかを判断するために、デザインファイルを評価する際に用いられる。この場合もやはり、第１ファイルはデザインファイルであり、少なくとも１つの承認済みライブラリと比較される。レポータモジュールは、典型的には、承認済みライブラリのセルのダイジェストと一致しないダイジェストを有するデザインファイルのセルを例外的にレポートする。オプションで、デザインファイルのセルと、承認済みのライブラリのセルの何れかとで完全な一致が見られない場合、部分的な一致がレポートされる。
【０５９７】
上記装置の更なる使用方法は、名称は異なるが機能的には同じであるセルを検出する際に用いられる。この用途における区分モジュールは、更に、セル内のレイヤーによってファイルを区分し、そのレイヤーを反映した構文木を構築する。第１ファイルはデザインファイルであり、第２ファイルは少なくとも１つの承認済みライブラリである。ダイジェスタは、少なくとも、デザインファイルの複数のレイヤーの機能的に重要なデータと承認済みライブラリを反映するダイジェストを計算し、記憶する。レポータモジュールは、更に、承認済みのライブラリ（「機能的に一致するセル」と称する）のダイジェストと一致する、複数のレイヤーにおいて機能的に重要なデータのダイジェストを持つが、機能的に一致するセルとセル名が一致しないデザインファイルのセルを、名称変更されたセルとしてサマライズする。オプションで、前記方法は、「名称変更された」とレポートされたデザインファイルのセルを、承認済みライブラリの機能的に一致するセルと一致し、リンクするセル名に戻すように拡張することも可能である。
【０５９８】
前記装置の興味深い使用方法として、デザインファイルの保証されたセル或いはその他のセルが、それらの保証されたデザインテンプレートから変更されたかどうかを判断するために、デザインファイルを評価することが挙げられる。第１ファイルはデザインファイルであり、第２ファイルは、少なくとも１つの承認済みライブラリである。ダイジェスタは、少なくとも、デザインファイルのセルの複数のレイヤー内の機能的に重要なデータと承認済みライブラリのダイジェストを計算し、記憶する。レポータは、更に、承認済みライブラリのセルのダイジェストに一致する複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを持つデザインファイルのセルを、変更された可能性があるセルとしてサマライズする。
【０５９９】
上記装置の更なる用途として、製品設計を検査して、製品設計で使われている有償のセルデザインを見つけることが挙げられる。こうした用途では、第１ファイルには、有償のセルデザインの１又は複数の有償のライブラリが含まれ、第２ファイルには、セルデザインを含む１又は複数の製品設計が含まれる。レポータは、更に、有償のライブラリのセルのダイジェストに一致するダイジェストを持つ製品設計のセルを、有償である可能性のあるセルとしてサマライズする。オプションで、ほぼ一致するものもレポートすることができる。
【０６００】
実施形態の第３のグループは、ボーレガード事件（Ｉｎ  ｒｅ  Ｂｅａｕｒｅｇａｒｄ）に一致するが限定はされない製造物品である。一実施形態において、この製造物品には、上述の方法の実施形態の何れかを実行するためのプログラムコードを記憶するコンピュータ可読記憶媒体が含まれる。プログラムコードがプロセッサ上で実行される時、プログラムコードによってプロセッサは上述の動作の実行が可能となる。第２の実施形態において、こうした製造物品は、プロセッサ及びメモリと組み合わされて上述の装置の何れかを生成するプログラムコードを記憶するコンピュータ可読記憶媒体を含む。プログラムコードは、プロセッサ及びメモリと組み合わされた場合に、上記のモジュールを備える。
【図１】
2011525276.tif 000004
【図２】
2011525276.tif 000005
【図３】
2011525276.tif 000006
【図４】
2011525276.tif 000007
【図５】
2011525276.tif 000008
【図６−７】
2011525276.tif 000009
【図８（ａ）−（ｂ）】
2011525276.tif 000010
【図８（ｃ）】
2011525276.tif 000011
【図８（ｄ）】
2011525276.tif 000012
【図９】
2011525276.tif 000013
【図１０（ａ）】
2011525276.tif 000014
【図１０（ｂ）】
2011525276.tif 000015
【図１１】
2011525276.tif 000016
【図１２】
2011525276.tif 000017
【図１３】
2011525276.tif 000018
【図１４】
2011525276.tif 000019
【図１５】
2011525276.tif 000020
【図１６】
2011525276.tif 000021
【図１７（ａ）】
2011525276.tif 000022
【図１７（ｂ）】
2011525276.tif 000023
【手続補正書】
【提出日】平成23年2月17日(2011.2.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式において機能的に重要なデザインデータと重要でないデータとを区分する工程と、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記ダイジェストの前記比較の結果の少なくとも幾つかをサマライズする工程と、を備え、  前記機能的に重要なデザインデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータであり、  前記ダイジェストの計算に用いられる前記正則形式の前記選択されたデザインデータは、少なくとも前記機能的に重要なデザインデータを含むことを特徴とする方法。
【請求項２】
セルデザインの古いライブラリに対する、セルデザインの新しいライブラリの評価に適用される方法であって、  前記第１ファイルが、セルデザインの新しいライブラリであり、前記第２ファイルが、セルデザインの古いライブラリであり、  前記サマライズする工程は更に、少なくとも、前記ダイジェストの比較によって検出された前記新しいライブラリにおける前記機能的に重要な変更のレポートを含むことを特徴とする請求項１に記載の方法。
【請求項３】
セル名が異なる機能的に同じセルの検出に適用される方法であって、  前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、  前記ダイジェストの計算及び記憶工程は、少なくとも、前記デザインファイルと前記承認済みライブラリのセルの複数のレイヤーにおける機能的に重要なデータに適用され、  前記サマライズする工程は更に、前記承認済みライブラリのセル（「機能的に一致するセル」と称する）のダイジェストに一致する、前記複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、前記機能的に一致するセルとセル名が一致しない前記デザインファイルの前記セルを、名称変更されたセルとしてレポートすることを含むことを特徴とする請求項１に記載の方法。
【請求項４】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記ダイジェストの前記比較の結果の少なくとも幾つかをサマライズする工程と、を備え、  前記第１ファイルが、ＯＡＳＩＳ設計言語で表現されたデザインデータを含み、前記第２ファイルが、ＧＤＳＩＩ設計言語で表現されたデザインデータを含み、  前記ＯＡＳＩＳ設計言語及び前記ＧＤＳＩＩ設計言語に関する前記正則形式によって、前記セルのボディのデザインデータが比較可能となることを特徴とする方法。
【請求項５】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも３つのファイル内にあり、前記方法は、  コンピュータを用いて、第１、第２及び第３ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、    但し、前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つのセルデザインのカレントライブラリであり、前記第３ファイルは少なくとも１つのセルデザインの旧式ライブラリであり、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記カレントライブラリのセルデザインのダイジェストに一致せず、かつ、前記旧式ライブラリのセルデザインのダイジェストに一致するダイジェストを有する前記デザインファイルの少なくともセルをレポートする工程と、を備えることを特徴とする方法。
【請求項６】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、    但し、前記第１ファイルはデザインファイルであり、前記第２ファイルは既知の不良セルデザインを含み、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記ダイジェストの前記比較の結果の少なくとも幾つか、及び、前記既知の不良セルデザインのファイルのセルのダイジェストに一致するダイジェストを有する前記デザインファイルのセルをサマライズする工程と、を備えることを特徴とする方法。
【請求項７】
前記デザインファイルの前記セルが、少なくとも１つの承認済みライブラリに属するかどうかの評価に更に適用される方法であって、前記方法は、  前記認識し、構文を解析し、及び、計算する工程が適用される第３ファイルを更に含み、  前記第３ファイルは、少なくとも１つのセルの承認済みライブラリであり、  前記サマライズする工程は更に、前記セルの承認済みライブラリのセルのダイジェストに一致しないダイジェストを有する前記デザインファイルのセルのレポートを含むことを特徴とする請求項６に記載の方法。
【請求項８】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、    但し、前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記承認済みライブラリのセルのダイジェストに一致しないダイジェストを有する前記デザインファイルのセルをレポートする工程と、を備えることを特徴とする方法。
【請求項９】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、    但し、前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式の少なくとも、前記デザインファイルと前記承認済みライブラリのセルの複数のレイヤーにおける機能的に重要なデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記承認済みライブラリのセルのダイジェストに一致する前記複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを有する前記デザインファイルのセルを、変更された可能性のあるセルとしてレポートする工程と、を備えることを含むことを特徴とする方法。
【請求項１０】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、セル毎に少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記ダイジェストの前記比較の結果の少なくとも幾つかをサマライズする工程と、を備え、  前記第１ファイルは、有償セルデザインの１又は複数の有償ライブラリを含み、第２ファイルは、セルデザインを含む１又は複数の製品設計を含み、  前記サマライズする工程は更に、前記有償ライブラリのセルのダイジェストに一致するダイジェストを有する製品設計におけるセルを、有償セルである可能性のあるセルとしてレポートすることを含むことを特徴とする方法。
【請求項１１】
回路のデザインデータ間の類似性及び／又は差異に関して、コンピュータによって実行される評価方法であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記方法は、  コンピュータを用いて、第１及び第２ファイルにあるデザインデータ内の、物理的回路用のデザインの各部分に相当するセルを認識する工程と、  前記セル内の前記デザインデータの構文を解析し、特定のセル内の前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式へ、前記デザインデータを標準化する工程と、  セル内の前記デザインデータを区分する１又は複数の構文木を生成する工程と、    但し、前記デザインデータは、少なくとも、前記デザインデータが投入されるフォーマットに従って、ヘッダデータとボディデータ間、及び、機能的に重要なデータと重要でないデータ間、とで分割され、前記機能的に重要なデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータの部分であり、  前記正則形式の少なくとも選択されたデザインデータのダイジェストを計算及び記憶し、１セル１区分当たり少なくとも１つのダイジェストを生成する工程と、  前記第１ファイルの前記セルの前記ダイジェストと、前記第２ファイルの前記セルの前記ダイジェストとを比較する工程と、  前記ダイジェストの前記比較の結果の少なくとも幾つかをサマライズし、異なる区分タイプから生成された前記ダイジェストを区別する工程と、を備えることを特徴とする方法。
【請求項１２】
前記構文木が、更に、セル内の前記デザインデータを、デザインレイヤーに区分することを特徴とする請求項１１に記載の方法。
【請求項１３】
順序非依存が、ノードで表されるデザインデータから生成される回路を変更することなく、前記ノードが様々な順序で処理可能であることを意味する場合に、順序非依存の前記デザインデータを表す前記ノードを含む前記構文木の枝を認識する工程と、  前記認識された枝のノードをソートする工程と、を含む方法であって、  前記ダイジェストの計算及び記憶が、前記ソートされたノードに適用されることを特徴とする請求項１１に記載の方法。
【請求項１４】
回路のデザインデータ間の類似性及び／又は差異を評価する装置であって、前記デザインデータは、コンピュータメモリに記憶された少なくとも２つのファイル内にあり、前記装置は、  少なくとも１つのプロセッサ及びメモリと、  前記プロセッサ上で実行され、物理的回路用のデザインのアスペクトを表すデザインデータを含むファイルを構文解析し、前記メモリに１又は複数の構文木を生成する構文解析ツールと、  前記プロセッサ上で実行され、前記構文木を構築する前記構文解析ツールと連携して、正則形式を生成する標準化ロジックと、を含み、前記標準化ロジックは、    前記ファイルを、少なくとも１つのヘッダと、前記ファイルを符号化するために使用される設計言語の規則に従って、デザインデータの複数のセルに区分し、前記ヘッダ及びセルの区分を表す前記構文木を構築する区分モジュールと、    前記構文木を解釈して、前記デザインデータにおける非機能的なばらつきに対する、データ分析の感受性を低下させる正則形式を、前記デザインデータについて生成する正則形式生成モジュール、とを含み、  前記プロセッサ上で実行され、少なくとも選択された区分に関する前記正則形式を受け取り、選択された区分につき少なくとも１つのダイジェストを計算し、前記メモリに記憶するダイジェスタモジュールと、  前記プロセッサ上で実行され、デザインデータを含む少なくとも第１ファイル及び第２ファイルのダイジェストを受け取って比較する比較モジュールと、  前記プロセッサ上で実行され、前記ダイジェストの比較によって検出された前記一致及び／又は差異の少なくとも幾つかをサマライズする前記ダイジェスタに連結するレポータモジュールと、を備えることを特徴とする装置。
【請求項１５】
前記正則形式生成モジュールは、前記構文木の枝のソート可能性を解釈し、ソート可能性を反映する前記構文木を構築することを特徴とする請求項１４に記載の装置。
【請求項１６】
前記区分モジュールは、更に、前記ファイルを、セル内のレイヤーによって区分し、前記レイヤーを反映する前記構文木を構築することを特徴とする請求項１４に記載の装置。
【請求項１７】
前記区分モジュールは、更に、前記ファイルを、機能的に重要なデザインデータと重要でないデザインデータとに区分して、機能的重要性を反映する前記構文木を構築し、  前記機能的に重要なデザインデータとは、デザインデータの変更が、当該デザインデータから生成された回路の変更となるデザインデータであることを特徴とする請求項１４に記載の装置。
【請求項１８】
セルデザインの古いライブラリに対して、セルデザインの新しいライブラリを評価するように構成された装置であって、  前記第１ファイルはセルデザインの新しいライブラリであり、前記第２ファイルはセルデザインの古いライブラリであり、  前記レポータモジュールは、前記ダイジェストを比較することによって検出された前記新しいライブラリにおける前記機能的に重要な変更をサマライズすることを特徴とする請求項１７に記載の装置。
【請求項１９】
有償のセルデザインを見つけるために、製品設計を検査するように構成された装置であって、  前記第１ファイルは、有償セルデザインの１又は複数の有償ライブラリを含み、第２ファイルは、セルデザインを含む１又は複数の製品設計を含み、  前記レポータモジュールは、前記有償ライブラリのセルのダイジェストに一致するダイジェストを有する製品設計におけるセルを、有償セルである可能性のあるセルとしてサマライズすることを特徴とする請求項１４に記載の装置。
【請求項２０】
名称は異なるが機能的に同じであるセルを検出するように構成された装置であって、  前記区分モジュールは、更に、セル内のレイヤーで前記ファイルを区分し、前記レイヤーを反映する前記構文木を構築し、  前記第１ファイルはデザインファイルであり、前記第２ファイルは少なくとも１つの承認済みライブラリであり、  前記ダイジェスタは、少なくとも、前記デザインファイルと前記承認済みライブラリのセルの複数のレイヤーにおける機能的に重要なデータのダイジェストを計算して前記メモリに記憶し、  前記レポータモジュールは、前記承認済みライブラリのセル（「機能的に一致するセル」と称する）のダイジェストに一致する、前記複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、前記機能的に一致するセルとセル名が一致しない前記デザインファイルの前記セルを、名称変更されたセルとしてサマライズすることを特徴とする請求項１４に記載の装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０５８１
【補正方法】変更
【補正の内容】
【０５８１】  更に、上記方法は、名称は異なるが機能的には同じであるセルを検出する場合にも用いることができる。第１ファイルはデザインファイルであり、第２ファイルは少なくとも１つの承認済みのライブラリである。ダイジェストの計算及び記憶は、少なくとも、デザインファイルと承認済みライブラリの複数のレイヤーの機能的に重要なデータに適用される。サマライズには、承認済みのライブラリ（「機能的に一致するセル」と称する）のダイジェストと一致する、複数のレイヤーにおける機能的に重要なデータのダイジェストを持つが、機能的に一致するセルとセル名が一致しないデザインファイルのセルを、名称変更されたセルとしてレポートすることが含まれる。オプションで、前記方法は、「名称変更された」とレポートされたデザインファイルのセルを、承認済みのライブラリの機能的に一致するセルと一致し、リンクするセル名に戻すように、拡張することも可能である。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０５８２
【補正方法】変更
【補正の内容】
【０５８２】  上記方法の興味深い使い方としては、デザインファイルの保証されたセル或いはその他のセルが、保証されたデザインテンプレートから変更されたかどうかを判断するために、デザインファイルを評価することが挙げられる。第１ファイルはデザインファイルであり、第２ファイルは、少なくとも１つの承認済みライブラリである。ダイジェストの計算及び記憶は、デザインファイルと承認済みライブラリのセルの複数のレイヤー内の少なくとも機能的に重要なデータに対して行われる。サマライズには、更に、承認済みライブラリのセルのダイジェストに一致する、複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを持つデザインファイルのセルを、変更された可能性のあるセルとしてレポートすることが含まれる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０５９７
【補正方法】変更
【補正の内容】
【０５９７】  上記装置の更なる使用方法は、名称は異なるが機能的には同じであるセルを検出する際に用いられる。この用途における区分モジュールは、更に、セル内のレイヤーによってファイルを区分し、そのレイヤーを反映した構文木を構築する。第１ファイルはデザインファイルであり、第２ファイルは少なくとも１つの承認済みライブラリである。ダイジェスタは、少なくとも、デザインファイルと承認済みライブラリの複数のレイヤーの機能的に重要なデータを反映するダイジェストを計算し、記憶する。レポータモジュールは、更に、承認済みのライブラリ（「機能的に一致するセル」と称する）のダイジェストと一致する、複数のレイヤーにおいて機能的に重要なデータのダイジェストを持つが、機能的に一致するセルとセル名が一致しないデザインファイルのセルを、名称変更されたセルとしてサマライズする。オプションで、前記方法は、「名称変更された」とレポートされたデザインファイルのセルを、承認済みライブラリの機能的に一致するセルと一致し、リンクするセル名に戻すように拡張することも可能である。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０５９８
【補正方法】変更
【補正の内容】
【０５９８】  前記装置の興味深い使用方法として、デザインファイルの保証されたセル或いはその他のセルが、それらの保証されたデザインテンプレートから変更されたかどうかを判断するために、デザインファイルを評価することが挙げられる。第１ファイルはデザインファイルであり、第２ファイルは、少なくとも１つの承認済みライブラリである。ダイジェスタは、少なくとも、デザインファイルと承認済みライブラリのセルの複数のレイヤー内の機能的に重要なデータのダイジェストを計算し、記憶する。レポータは、更に、承認済みライブラリのセルのダイジェストに一致する複数のレイヤーの内、すべてではないが、幾つかの、機能的に重要なデータのダイジェストを持つデザインファイルのセルを、変更された可能性があるセルとしてサマライズする。
【国際調査報告】
2011525276.tif 000024
2011525276.tif 000025