(57)【要約】回路ブロックを設計するための方法は、回路システムを設計するために利用されるべき複数の事前に設計された回路ブロックを選択するステップであって、少なくとも１つの該回路ブロックは、プログラム可能であるステップと、事前に設計される回路ブロックに関して、設計者の経験を反映するデータを収集するステップであって、設計者の経験は、処理方法に適応可能であるステップと、設計者の経験、データおよび許容可能な程度のリスクに基づく方法で回路システムの設計を許容する、または、拒否するステップと許容性に基づき、判断基準を含むブロックの仕様および各回路ブロックに対する修正された制限を形成するステップと、許容性に基づき、選択された回路ブロックおよび処理方法を変更することなく判断基準および修正された制限と整合して、チップのフロアプラン上に回路ブロックを配備するためのブロック仕様を形成するステップとを含む。【選択図】図８６
2004531056.tif 000002
【特許請求の範囲】
【請求項１】
回路ブロックを設計するための方法であって、
（ａ）該回路システムを設計するために利用されるべく事前に設計された複数の回路ブロックを選択するステップであって、少なくとも１つの該回路ブロックはプログラム可能である、ステップと、
（ｂ）該事前に設計された回路ブロックに関する設計者の経験を反映するデータを収集するステップであって、該設計者の経験は、処理方法に適合可能である、ステップと、
（ｃ）該設計者の経験データおよび許容される程度の危険性に基づく態様で、該回路システムの設計を許容する、または、拒絶するステップと、
（ｄ）許容性に基づき、判断基準および各該回路ブロック（ＦＥＡ）のための修正された制限を含むブロック仕様書を形成するステップと、
（ｅ）許容性に基づき、該選択された回路ブロックおよび該処理方法を改変することなく、該判断基準および修正された制限に整合して、チップのフロアプラン（ｆｌｏｏｒ  ｐｌａｎ）上に回路ブロックを配置するためのブロック仕様書を形成するステップと
を包含する、方法。
【請求項２】
派生的な回路ブロックを設計するための方法であって、
（ａ）オリジナルの回路設計を選択するステップであって、該オリジナルの回路設計は、１つ以上のプログラム可能なファブリックを含む、ステップと、
（ｂ）該回路設計上でフロントエンド許容性テストを実行するステップと、
（ｃ）チップレイアウトをプラニングするステップと、
（ｄ）少なくとも１つ以上のプログラム可能ファブリックをプログラムするステップと、
（ｅ）該派生的な回路ブロックの検証を実行するステップと
を包含する、方法。
【請求項３】
前記チップレイアウトをプラニングする前記ステップは、結果として、該チップレイアウトの変更を生じさせない、請求項２に記載の方法。
【請求項４】
前記派生的な回路ブロックの検証を実行する前記ステップの前に、クロッキングおよびタイミング分析を実行するステップをさらに包含する、請求項２に記載の方法。
【請求項５】
前記派生的な回路ブロックの検証を実行する前記ステップの前に、電力分析を実行するステップをさらに包含する、請求項２に記載の方法。
【請求項６】
前記オリジナル回路設計を付加された新規機能性のセット、および、新規機能性の前記セットとインターフェイスする任意の機能性のみが、テストされる、または、検証される、請求項２に記載の方法。
【請求項７】
ステップＡからステップＥまでは、該第２の派生的な設計のオリジナルの回路設計が、派生的な設計であるように、該第２の派生的な設計を設計するように繰り返される、請求項２に記載の方法。
【請求項８】
前記チップレイアウトをプラニングする前記ステップは、前記派生的な回路ブロックが、全ての適用可能なタイミング要件と整合することを保証するために、タイミング要件を分析するステップを包含する、請求項２に記載の方法。
【請求項９】
前記派生的な回路ブロックの検証を実行する前記ステップの前に、前記チップを組み立てるステップをさらに包含する、請求項２に記載の方法。
【請求項１０】
前記オリジナルの回路設計は、１つ以上のプログラム可能でないファブリックをさらに含む、請求項２に記載の方法。
【請求項１１】
前記１つ以上のプログラム可能なファブリックの各々は、ポートアクセスおよび階層的なルーティングを有する、請求項１０に記載の方法。
【請求項１２】
シミュレーションを介して、各プログラム可能ファブリックおよび各プログラム可能でないファブリックのための電力レベルを決定するステップをさらに包含する、請求項１０に記載の方法。
【請求項１３】
派生的な回路ブロックを設計するための１つ以上の指示の１つ以上のシーケンスを保有するコンピュータ読み込み可能媒体であって、該１つ以上の指示の該１つ以上のシーケンスの実行は、１つ以上のプロセッサに、
（ａ）オリジナルの回路設計を選択するステップであって、該オリジナルの回路設計は、１つ以上のプログラム可能ファブリックを含む、ステップと
（ｂ）該回路設計上でフロントエンド許容性テストを実行するステップと、
（ｃ）チップレイアウトをプラニングするステップと、
（ｄ）少なくとも１つの該１つ以上のプログラム可能ファブリックをプログラムするステップと、
（ｅ）該派生的な回路ブロックの検証を実行するステップと
を実行させる、コンピュータ読み込み可能媒体。
【請求項１４】
前記チップレイアウトをプラニングする前記ステップは、結果として該チップレイアウトを変更を生じさせない、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項１５】
前記派生的な回路ブロックの検証を実行する前記ステップの前に、クロッキングおよびタイミング分析を実行するステップをさらに包含する、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項１６】
前記派生的な回路ブロックの検証を実行するステプの前に、電力分析を実行するステップをさらに包含する、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項１７】
前記オリジナルの回路設計を付加された新規の機能性のセット、および、新規機能性の該セットとインターフェイスする任意の機能性は、テストされ、または、検証される、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項１８】
ステップＡからステップＥまでは、第２の派生的な設計のオリジナルの回路設計が、派生的な設計であるように、該第２の派生的な設計を設計するように繰り返される、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項１９】
前記チップレイアウトをプラニングする前記ステップは、
前記派生的な回路ブロックは、全ての適用可能なタイミング要件に整合することを保証するタイミング要件を分析するステップ
を包含する、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項２０】
前記派生的な回路ブロックの検証を実行する前記ステップの前に、前記チップを組み立てるステップをさらに包含する、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項２１】
前記オリジナル回路設計は、１つ以上のプログラム可能でないファブリックをさらに包含する、請求項１３に記載のコンピュータ読み込み可能媒体。
【請求項２２】
前記１つ以上のプログラム可能ファブリックの各々は、ポートアクセスおよび階層的ルーティングを有する、請求項２１に記載のコンピュータ読み込み可能媒体。
【請求項２３】
シミュレーションを介して、各プログラム可能ファブリックおよび各プログラム可能でないファブリックのための電力レベルを決定するステップをさらに包含する、請求項２１に記載のコンピュータ読み込み可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
本発明は概して、集積回路（「ＩＣ」）デバイス設計に関し、より詳細には、予め設計された回路ブロックを再使用するシステムの設計に関する。
【背景技術】
【０００２】
（発明の背景）
近年では、シリコン処理技術の絶え間ない革新が、劇的に価格を減少させ、集積回路デバイスの性能および機能性を増加させ、これにより、電子機器製造および情報処理産業の開発を刺激してきた。次いで、これらの高速成長産業は、集積回路設計システム開発者にさらに高速かつより安価なデバイスに対する増大している要求を課す。その結果、現在では、設計産業は以下のような劇的な変化を受けている。
（１）チップ設計がより大きくそしてより複雑になっている。例えば、１９９７年では、典型的な集積回路は、１０〜５０万のゲートを含んでいた。１９９８年では、典型的なデバイスは、１００〜２００万ゲートを含んでいた。１９９９年およびそれ以後の技術は、４００〜６００万ゲートまたはそれ以上構成されたデバイスと共にこのトレンドの継続を示してきた。
（２）チップ設計は、より多くの特定用途となってきている。ＩＣ設計の初期では、デバイス製造業者は、典型的には、種々の「既製品（ｏｆｆ−ｔｈｅ−ｓｈｅｌｆ）」のチップを製造し、そのエンドユーザは、そのチップをユーザの電子製品に設計する。現在では、電子製品製造業者は、しばしば特定の機能を実行するためにカスタムチップ設計を注文する。
（３）現在では、電子製品開発は、主にカスタマの要求によって動かされ、それにより製品の寿命を短くし、従って可能な設計時間および資源を短縮する。例えば、１９９７年では、平均設計サイクルは、１２〜１８ヶ月であった。１９９８年では、その平均時間は、１０〜１２ヶ月に減少され、現在では、典型的な設計サイクル時間はもっと短い。
（４）設計時間の制約は、逆行して設計労力を必要とする。以前は、上流システムコンポーネントについての重要な設計決定は、下流のシステム設計コンポーネントが検証されるまで待つことができた。設計管理者は、もはや設計タスクを逐次的に実行する贅沢さを有さない。いくつかのシステムコンポーネントは、同時に開発される必要があり得る。従って、設計管理者は、少なくともいくつかのシステムコンポーネント設計が完成する前に、重要な予測を行うことが要求される。
【０００３】
これらの要求に近づくために、電子システム設計は、ブロックベースの設計（Ｂｌｏｃｋ  Ｂａｓｅｄ  Ｄｅｓｉｇｎ）（「ＢＢＤ」）として当該分野で公知の方法論に移行しており、システムは、複数の既存のコンポーネント設計ブロック（当該分野では、「知的所有権ブロック」すなわち「ＩＰブロック」とも呼ばれる）を統合することによって設計される。これらの予め設計されたブロックは、内部設計チームから得られるか、または他の設計会社から実施許諾を獲得し得、そして基本的に異なる設計構造および環境によって支援され得る。さらに、予め設計されたブロックは、異なる設計要求および制約を満たすように開発され得る。
【０００４】
ＢＢＤを用いる設計者が直面する別の課題は、フロントエンド（プロジェクト承認）遅延およびシステム設計の実現可能性を決定する際の不確実性によってもたらされたリスクである。現在のＡＳＩＣ（特定用途集積回路）設計は、主にＲＴＬ（レジスタ転送レベル）段階で提示され、いくつかは、カスタマによってより早く設計者に仕様レベルで提示される。次いで、これらの設計は、コスト効率の良いインプリメンテーションを提供するために領域、性能、および電力トレードオフに従って、利用可能な合成技術の制限に基づいてある態様で分割される。このように、設計者は、入力としてシステム仕様を承認し、物理的なインプリメンテーション（設計場所、ルート、および検証）のためのネットリストレベルの設計を究極的には提供する。設計仕様は、クロック、電力、および大きさの仕様を含む意図されたまたは利用可能な処理技術の能力の範囲内にある場合、利用可能な設計方法論は、合理的に予測可能であり、利用可能な回路設計ツールを用いて十分に働く。
【０００５】
しかし、ＲＴＬレベルの設計およびシステムレベル設計活動は、典型的には、結合されていないかまたは弱く結合され、システムレベル機能定義からＡＳＩＣ（ＲＴＬ）レベルへの密着したリンクがないことを意味する。ＲＴＬレベルの設計は、文書のＡＳＩＣ仕様に基づいて開発され、ＡＳＩＣインターフェースの周辺に作成された新しく形成されたテストの組（ｓｕｉｔ）によって検証される。従って、ＡＳＩＣ設計のための利用可能な設計およびインプリメンテーションの方法論は、複数の問題を提示し、効率的なブロック統合を妨害する。
【０００６】
第１に、現在の方法論は、トップダウンアプローチを提供せず、互換性を包括的に評価かつ保証して、異なる設計を考慮する複数の資源によって提供された複数の設計ブロックを統合する一方で、市場に出るまでの厳しい時間制約の範囲内で階層的検証および短い組み立て時間を提供する。
【０００７】
あるいは、ＡＳＩＣ設計のための既存の方法論は、拡張性を提供しない。多数の既存の方法論は、フラット（ｆｌａｔ）設計周辺に集中される。このアプローチは、１００万より多くのゲートを有するシステムに対する上位レベルの設計を組み立てるために必要とされた時間の長さについての重要な問題の原因となってきた。
【０００８】
さらに既存のＡＳＩＣ設計の方法論は、予め設計された回路ブロックの再使用に適さない。利用可能な方式は、タイミング、クロック、バス、電力、ブロック構成、検証、特定のデバイスアーキテクチャの範囲内にある集積回路設計ブロックに関連付けられたテスト問題を解決するための指針を提供しない。従って、ブロック再使用への包括的なアプローチなしで、特別かつ予想できない設計アプローチをもたらす既存の方法論は、設計実現可能性を低減し、送達コストおよび時間を増加し、そしてしばしば、回路ブロックを設計されたシステムに適応させるために、予め設計された回路ブロックへの性能を低減する改変を引き起こす。さらに、既存の方法論は、性能トレードオフ解析および重要な設計パラメータ（クロック周波数、ならびにチップ設計およびインプリメンテーションを首尾よくかつ予測的に完成させる領域対リスク等）のフィードバックを提供しない。
【０００９】
従って、進歩している環境を満足させ、利用可能な技術の欠点に取り組み得る方法論に対する必要性が存在する。
【００１０】
回路設計において複数の資源からの予め設計された回路ブロックを使用および再使用するための適切な方法論に対する必要性もまた存在する。
【００１１】
ＩＰブロックを結合することもまた、「グルー（ｇｌｕｅ）」論理に対する必要性もまたもたらし、その論理はブロックが単一のデバイス上で共に作用することを可能にする。グルー論理は、設計ブロックを相互接続することに対して主に責任を負い、通常、ブロック間に常駐し、設計全体にわたって分散している。グルー論理エレメントは、チップ計画の種々の段階の間の設計に追加されてもよいし、ホストブロックのための相互接続機構として機能する設計内部に各ブロックの最も外部の境界において常駐してもよい。その資源にもかかわらず、グルー論理は、ブロック間のグルー論理の配置から生じるワイヤ輻輳およびタイミングの複雑さを最小化するための設計内に最適に配置されなければならず、元のブロック設計者によって企図され得ない遅延を導入する。
【００１２】
従って、本発明がブロックベースの設計においてグルー論理を配置かつ分散する改良された方法に関する従来技術の必要性が存在する。
【００１３】
種々のグルー論理エレメントの機能的な結合性を考慮し、それらのエレメントを新しい設計ブロックにグループ化するグルー論理分散機構のための必要性もまた存在する。
【００１４】
グルー論理の最適な量を既存の設計に戻すグルー論理分散システム機構に対する関連技術における必要性もまた存在する。
【００１５】
さらに、既存のＡＳＩＣ設計の方法論は、予め設計された回路ブロックの再使用に適さない。利用可能な方式は、タイミング、クロック、バス、電力、ブロック構成、検証、および特定のデバイスアーキテクチャ内部の回路設計ブロックを統合することに関連付けられたテスト問題を解決する指針を提供しない。回路ブロックが複数の非一貫性の資源から得られるため、課題は、どのようにしてこれらの回路ブロックをブロックベースの設計に適した態様でこれらの回路ブロックに統合するかである。
【００１６】
従って、ブロックベースの設計に適した態様で複数の非一貫性の資源から回路ブロックを相互接続するのに適した方法および装置に対する必要性が存在する。
【００１７】
異なるインターフェースを有する回路ブロックを標準化されたインターフェースを有するブロックに変換するためのインターフェースを提供するための方法および装置を提供するための別の必要性が存在する。
【００１８】
もちろん、全てのＩＣ（単一のチップ上の全システムを含むＩＣであっても）は、チップが性能要求を満たし、隠れた製造欠陥がないことを検証するための一連のテストに合格しなければならない。製造欠陥が見逃される場合、組み立てプロセスの後まで、またはさらに悪い場合は客先（ｆｉｅｌｄ）で、欠陥のあるチップが発見され得ない。このようなカスタマの満足についての影響に関する「テスト漏れ（ｔｅｓｔ  ｅｓｃａｐｅ）」のコストは、製造ラインに大打撃を与え得る。
【００１９】
一般的には、欠陥を検出するための３つのタイプが存在する。すなわち、ＤＣパラメトリックテスト、ＡＣパラメトリックテスト、および機能性（「ＰＬＬ」）テストである。ＤＣパラメトリックテストでは、入力、出力、入力−出力変換、全電流、チップの電力消費が計測される。ＡＣパラメトリックテストでは、入力および出力信号の立ち上がりおよび立ち下がり時間、入力端子と出力端子との間の伝搬の遅延時間、最小クロックパルス幅、およびチップの動作周波数が計測される。機能性テストでは、チップが予め規定された動作条件下で設計されたように機能するかどうかを見るためにテストされる。典型的には、テストパターンを入力端子に適用し（「テストベクトル（ｔｅｓｔ  ｖｅｃｔｏｒ）」）、予測されたパターンと出力端子において検出された出力パターンを比較することによって、機能性テストを実行する。
【００２０】
テスト用の設計（Ｄｅｓｉｇｎ  ｆｏｒ  Ｔｅｓｔ）（「ＤＦＴ」）方法論の出現の前には、設計者はチップを作製かつ組み立て、次いで、テスト設計者による完成された設計に渡した。次いでテスト設計者は、追加されたパッケージレベルテスト論理に追加され、チップを製造業者（「ｆａｂ」）に送った。次いでｆａｂテスターは、チップを検査し、パッケージレベルの論理に関する上述のテストを含む基板テストプロトコルを実行した。利用可能なスキャン設計方法論は、予測可能かつ一貫性のあるテスト結果を用いて全体のチップに「単一の」テスト方法を適用するためのかなり効率的で広く使用された方法の簡単な例である。他の特殊な方法は、スキャン可能ではない設計スタイルを処理するために使用され得る。
【００２１】
今日では、全体のチップ内に以前から含まれた論理は、現在では単一の仮想コンポーネント（ＶＣ）またはより大きいチップに含まれる設計ブロックとして使用されている。従って、回路設計が完成した後に、テストはもはや設計され得ない。設計者は、設計プロセスにわたって各設計ブロック、ならびに全体のパッケージングチップをどのようにしてテストするかを計画しなければならない。従って設計プロセスは、適切なものとして１つ以上のテスト方法を適用することによってテスト可能性を確実にする。
【００２２】
ＤＦＴの利点は周知である。ＤＦＴ論理およびテストベクトル検証機能は、生成サイクルの初期においてより短い、生成準備テストを可能にする。あるいは、ＤＦＴスキャンパスは、他の場合では利用不可能であるチップおよびシステム状態へのアクセスを提供する。それにより、良好なＤＦＴ計画は、市場に出るまでの時間を短縮し、フロントエンド設計プロセスおよび製造テストの開発を簡略化することによってテストのコストを低減する。
【００２３】
従って、利用可能な技術によって提示された４つの必要性が存在する。第１に、ＢＢＤに対する新しいＤＦＴは、制限されたテストアクセスを共有し、全体のＳＯＣレベルテスト目的を満たすように、他の異なるテスト方法間で予め設計されたテストデータの効率的な使用を行うことが可能でなければならない。
【００２４】
第２に、技術拡張、混合信号および混合技術設計の新しい複雑さ、ならびに増加しているＩ／Ｏカウントおよび新しいパッケージング技術に起因する、新しい欠陥のタイプおよび新しい欠陥レベルの問題の出現に直面しなければならない。
【００２５】
第３に、ＩＰブロックの統合の問題に直面しなければならない。これは、統合されていない構造テストモデルが本来欠如している。ＳＯＣレベルのテストアクセスおよび不良の分離が必要とされ、現在利用可能なＤＦＴ方法論によってほとんどサポートされていない低電力設計技術（すなわち、ラッチベース、ゲートクロック、導かれたクロック、パイプライン、および低閾値電圧）に対する要求に取り組まなければならない。
【００２６】
新しいＤＦＴ方法論は、制限または不適切なテスト情報と直面した場合であっても、コヒーレントかつ一貫したテスト統合モデルを用いて市場圧力（ｍａｒｋｅｔ  ｐｒｅｓｓｕｒｅ）までの時間を克服しなければならない。
【００２７】
利用可能な技術は、構造的情報（すなわち、不良モードおよびテストモード）を必要とすることにより、テストデータが部分的または完全に発生され、不良のセットが検証され得る。例えば、スキャン設計方法論は、同期設計に対して利用可能であるのみであり、単一のスタックアットフォルト（ｓｔｕｃｋ−ａｔ−ｆａｕｌｔ）モデルのみを検出する。さらに、他のＤＦＴ解決策は、スキャンベースであることにより、構造的情報を含まないハードＩＰテストモデルを共有かつ検証することに対してその解決策をむしろ困難にする。
【００２８】
利用可能な技術はまた、共有かつ検証が可能である（すなわち、ソフトＩＰモデル）としても、現在のゲートカウントの急増を持続できない非線形計算モデルを必要とする。しかし、ソフトＩＰは、必ずしもスキャン可能または併合可能であるとは限らず、時には、予想できないかつ管理できないテスト開発を生じる。
【００２９】
最後に設計検証を考慮すると、ＳＯＣ設計における複数の予め設計されたブロックの使用によって提示された課題は、信頼性がありかつ効率的な機能検証方法に対する必要性が存在する。関連技術では、テストの組は、マルチブロック設計を検証するために使用される。この組における各テストは、ブロックが統合される前に各ブロックをテストするために使用される。次いで、ブロックの統合後、著しい労力がシステムレベルにおける機能的検証を可能にするようにテストの組を調整するために必要とされる。テストおよびデバッグプロセスは、最終的な完全なシステム検証が確信的に提供され得る前に複数の反復に対して繰り返され得る必要があり得る。
【００３０】
この問題に対する１つの利用可能なアプローチは、対応する挙動モデルのためのインプリメンテーションモデルの置換であり、それにより、チップレベルシミュレーションを可能にし、かつ混合されたモード状況でテストする。このアプローチは、効率的に実行された場合、望ましい結果を提示し、上述の反復ブロックベースのシミュレーションよりもあまり高価ではないが、このアプローチは、さらに一層高価で遅くなり得る。なぜなら、全体のチップは、信頼性のある機能検証を獲得するためにシミュレートされなければならないためである。
【００３１】
特に重要な課題が、バス構造を機能的に識別する必要性によってマルチブロック設計において提示される。利用可能な技術では、バス検証は、２つの方法の内のいずれかで達成される。バスがデバックされ、全体のチップの統合部分としてデバッグかつ検証されてもよいし、新しい権限が与えられたブロックによって提供された詳細なインプリメンテーションを考慮して、予め定義されたブロックのためのバス機能モデルを用いて検証されてもよい。しかし、統合バス検証は遅くかつ高価であり得る。全体のチップは、バス設計を検証するために使用されなければならず、詳細なレベルおよびバス関連バグを見つけない可能性のために、デバッグが困難で時間がかかる場合、統合バス検証は、設計サイクルにおいて遅れて実行されるのみであり得る。バス機能モデルアプローチは、いくつかのこれらの問題を簡略化するが、新しく権限が与えられたブロックに対するインプリメンテーションの詳細を必要とする。さらに、バス機能モデルは、機能モデル自体によるエラーを受けやすく、信号追跡およびデバッグを困難または不可能にする「ブラックボックス」としてのみ利用可能であり得る。
【００３２】
しばしば、回路設計者が、回路またはシステム設計の一部としてプログラム可能な回路構成要素を含ませることが有益である。しかし、さらなる課題が、再利用可能な回路設計の一部としてプログラム可能な回路設計を含ませることを試みることによって提示される。プログラム可能な回路構成が、種々の異なる形態において存在し得、そして、このような回路構成が再使用可能な回路ブロック上に組み込まれることであり、次いで、この設計およびテストプロセスフローは、プログラム可能な回路構成の特定のタイプの特定の要求を考慮し、これらの要求が、回路ブロックにおいて利用されたプログラム可能でない回路構成と互換性があることを確実にする必要がある。従って、最使用可能な回路ブロックを構成するための方法論を提供することが有利であり、この方法論は、プログラム可能なコンポーネントの特定の要求を説明し、プログラム可能でないコンポーネントを用いてこのようなプログラム可能なコンポーネントの統合を容易にする。
【発明の開示】
【課題を解決するための手段】
【００３３】
（発明の要旨）
利用可能な技術の欠点に取り組むためには、本発明は、回路システムを設計するための方法および装置を提供する。一実施形態では、この方法は、
（ａ）回路システムを設計するために使用された複数の予め設計された回路ブロックを選択するステップであって、該回路ブロックの内の少なくとも１つはプログラム可能である、ステップと、
（ｂ）予め設計された回路ブロックについて設計者の経験を反映するデータを収集するステップであって、設計者の経験は処理法方に適応可能である、ステップと、
（ｃ）設計者の経験データおよび承認可能なリスクの程度に基づいてある態様で回路システムの設計を承認または拒絶するステップと、
（ｄ）承認すると、回路ブロック（ＦＥＡ）の各々に対して基準および改変された制約を含むブロック仕様を形成するステップと、
（ｅ）承認すると、選択された回路ブロックおよび処理方法を変更することなく、基準および改変された制約に従ってチップのフロア計画に回路ブロックを展開するためのブロック仕様を形成するステップと
を含む。
【００３４】
（好適な詳細な説明および代替の実施形態）
利用可能な技術の欠点を克服するために、ブロックベースの設計（「ＢＢＤ」）のための新規な方法論およびインプリメンテーションが本明細書中で開示される。本明細書中で説明されたような１つ以上の好適な実施形態では、プログラム可能およびプログラム可能ではない回路コンポーネントの両方が回路ブロック内で利用され得る。より詳細に説明されるように、図１は、ブロックベースの設計プロセスの上位レベルの概観を示す。他の図は、図１に示された一般的なフレームワークに従って、種々のブロックベースの設計処理の実施形態またはインプリメンテーションに関連するさらなる詳細を提供する。特に、図７４〜図７８は、ブロックベースの設計プロセスにおけるプログラム可能な回路構成の使用に関して特に集中して説明される。
【００３５】
本明細書中で説明されたようなブロックベースの設計の主要な局面は、回路ブロック設計において使用される「ファブリック」の概念に関連する。本明細書中で使用される場合、用語「ファブリック」は、一般的には、構造よりも下位レベルの複雑さを隠すことによって設計プロセスを簡略化する、電子技術における繰り返し構造を指す。ファブリックは、ソフトウエアまたはハードウエアのいずれかに関連し得る。ファブリックの例は、例えば、デジタルハードウエアにおけるゲート、およびソフトウエアにおけるプログラミングコードのラインを含む。
【００３６】
ハードウエア関連ファブリックは、いくつかの異なるカテゴリに分類され得る。すなわち、標準的なセル、ゲートアレイ、金属プログラム可能なゲートアレイ（ｍｅｔａｌ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）（ＭＰＧＡ）、フィールドプログラム可能なゲートアレイ（ＦＰＧＡ）、および計算（ｃｏｍｐｕｔａｔｉｏｎａｌ）を含む。標準的なセル設計は、シリコンの全ての層の設計を含むが、トランジスタレベルの細部を隠す。ゲートアレイ設計は、相互接続の全ての層の設計を含むが、物理的なサイズ特徴および完全な配置およびルーティングの細部を隠す。ＭＰＧＡ設計は、上部相互接続層の設計を含むが、ローカル相互接続の細部を隠す。ＦＰＧＡ設計は、既存のシリコンの使用を含むが、半導体処理の全てを隠す。計算的設計はまた、既存のシリコンを使用するが、ほとんどの物理インプリメンテーションを隠す。
【００３７】
種々のタイプのファブリック間の設計トレードオフは、少なくともブロックベースの設計の意味以外のデジタル回路設計の分野の当業者に周知である。標準的なセル技術は、一般的には、非常に高い密度および高性能（例えば高速）によって特徴付けられるが、典型的はハードワイヤードであり、従って、比較的フレキシブルではない。ＭＰＧＡ技術もまた、一般的には高密度であり、合理的に良好な性能を有し、そしてこの技術が配線構成である点においてあるフレキシビリティを有する。ＦＰＧＡ技術は典型的には中間の密度であり、中程度の性能を有するが、再構成可能な利点を有する。計算回路技術は、一般的には低密度であり、従って、ほとんどのチップ領域を利用するが、この技術は、フレキシブルな性能の利点およびソフト（ｓｏｆｔ）プログラム可能性の利点を有する。種々のハードウエアファブリックの性能（サイクル時間）、ならびにその各々の密度（ゲート当たりの面積）および粒度（ｇｒａｎｕｌａｒｉｔｙ）を比較するグラフは、図７４に示される。比較目的のために、カスタム回路設計はまた、図７４のグラフに示され、この図は、カスタム回路設計が最大密度レベルおよび最大性能を有するが、カスタム回路設計はまた、最小のフレキシビリティであり、任意のトランジスタレベルの設計細部から設計者を隔離しない。一般的には、回路構成（プログラム可能性または構成可能性）がフレキシブルになるほど、性能が遅くなり、そしてオーバーヘッドが大きくなる。しかし、プログラム可能な機能の数が増大する場合、機能当たりのオーバーヘッドは、最大のフレキシビリティ（例えば、計算回路システム）を有するこれらのシステムにおいて最も急速に低下する。さらに、さらなる機能を追加するコストは、システムのプログラム可能性が大きくなればなるほどそれに比例して小さくなる。
【００３８】
さらに、ハードウエアファブリックを分類することに加えて、ブロックベースの設計方法論の説明を容易にする目的のための異なる分類にプログラミングファブリックを分割するのに役立ち得る。プログラミングファブリックは、格納されたプログラムへの分割、瞬間的に再構成可能、高速に再構成可能、低速に再構成可能、１回プログラム可能（ＯＴＰ）、配線で構成可能、ハードワイヤードであり得る。格納されたプログラム技術は、継続的なロードおよび命令の解釈により命令または命令のブロックに対する実行によって特徴付けられ、一般的には、実行の命令当たり数ナノ秒またはそれ以上を必要とする。瞬間的な再構成可能な回路は、一般的には、モジュールに対してプログラム可能であり、ロードするために内部メモリ交換を使用し、典型的には、約１０ナノ秒のロード時間がかかる。瞬間的に再構成可能な回路構成を用いると、簡単なアドレススイッチは、一般的には、回路構成が進行中に選択され得る機能性の層をパラレルで有するという点で、回路構成要素の機能を切り替える必要があるだけである。高速再構成可能な回路構成は、一般的には機能に対してプログラム可能であり、プログラミングのために外部メモリロード動作を使用し、典型的には約１０マイクロ秒のロード時間がかかる。低速な再構成可能な回路構成は、一般的に全体のシステム（断片的なプログラミングブロックではなく）に対してプログラム可能であり、プログラミングのための外部構成獲得（一般的には低周波数、他のコンポーネントへのシリアルＩ／Ｏ接続）を利用し、約１０ミリ秒のロード時間がかかる。ＯＴＰは、一般的には、ハードウエアレベルで１回プログラムする能力を指す。配線構成可能な回路構成は、一般的には、初期化に応じてプログラムまたは構成され、そのロード時間は、回路構成のタイプに依存する。ハードワイヤード回路構成はプログラム可能ではない。
【００３９】
ＭＰＧＡ、ＦＰＧＡの使用および／または計算回路は、ブロックベースの設計の観点において特別な課題を提示する。特に、考慮は、ＢＢＤ設計プロセスフローの各ステージにおいてこれらのタイプのファブリックのプログラム可能なおよび／または構成可能な性質が与えられることを必要とする。アーキテクチャ設計トレードオフは、種々の異なるタイプのファブリックのプログラム可能性のレベルだけではなく、速度、密度、および全体の設計の大きさ等の他の特性に基づき得る。カスタム回路技術は、一般的には、単一のチップ上に２０００万までまたはそれ以上の現在の技術用いた最大密度論理を可能にする。標準的なセル技術は、単一のチップ上に約２００万〜２０００万ゲートの密度を現在の技術を用いて提供する。ＭＰＧＡ技術は、単一のチップ上に約２０万〜２００万ゲートの密度を提供するが、ＦＰＧＡ技術は、単一のチップ上に約２万〜２０万ゲートの密度を提供する。図８３は、設計者が選択し得るいくつかの種々の異なるファブリックの特性を比較する図である。これらの特性（フレキシビリティ、大きさ、電力等）に加えて、設計者はまた、「誘導的な」回路設計が期待されるかどうかを考慮し得る。すなわち、元の設計に基づくが、いくつかの新しいかまたは異なる機能性を生成するために変更されるさらなる回路設計である。誘導的な設計発生に関するさらなる細部が本明細書中で以後説明される。
【００４０】
プログラム可能ではないファブリックとは異なり、プログラム可能なファブリックは、しばしば２つの列のルーティング（階層的）およびマルチタイルタイプに基づく配置（すなわち、プログラム可能な回路構成は、タイルに編成された回路構成の異なるタイプのクラスタを含むことにより、回路構成の配置を制限する）を有する。例えば、ＦＰＧＡは、一般的に２０，０００〜５０，０００ゲートを有し（ルーティング／配置の第１のレベル）、さらに、全体の機能性をＦＰＧＡに集合的に提供するサブ機能にライブラリエレメントを相互接続する内部ルーティングワイヤを有する（ルーティング／配置の第２のレベル）。さらに、プログラム可能ではないファブリックとは異なり、プログラム可能なファブリックは、一般的には、回路構成をプログラミングするための機構を必要とする。例えば、プログラミングポートは、プログラム可能性を提供するために必要とされ得、例えば、Ｉ／Ｏポートまたはシステムバスに取り付け得る。最も一般的なＦＰＧＡは、例えば、ソフトプログラム可能である。すなわち、ＦＰＧＡ機能性のプログラミングは、ＦＰＧＡを回路ブロック内の他のコンポーネントに接続した後で、その後追加され得る。回路ブロック内のプロセッサは、例えば、回路ブロックの動作間のＦＰＧＡ機能性をロードし得る。いくつかのＦＰＧＡは、不揮発性プログラム可能（例えば、ＥＥＰＲＯＭを介してプログラムされた）であり、この場合、ＦＰＧＡは、パワーアップ手順の一部としてロードされる。他のＦＰＧＡは、スタティックＲＡＭ（ＳＲＡＭ）を用いてプログラム可能であり、この場合、別個のＩ／ＯポートがＦＰＧＡをロードするために必要とされ得る。プログラム可能なファブリックの特別の配置およびルーティング要求、ならびにプログラミングアクセスポイントに対する必要性は、プログラム可能なファブリックが利用されるブロックベースの設計プロセスの一部として考慮される必要がある。
【００４１】
ここで、図１を参照すると、ブロックベースの設計（ＢＢＤ）方法論に基づく好適な設計プロセスを示すフローチャート１００が示される。図１に示されるように、設計プロセスは、好適には、フロントエンド承認設計ステージ１０２、チップ計画設計段階１０４、ブロック設計ステージ１０６、チップアセンブリ設計ステージ１０８、および検証設計ステージ１１０を含む。
【００４２】
フロントエンド承認設計ステージ１０２は、システムインテグレータ（チップ設計者）が予測される設計プロジェクトの実現可能性を評価することを可能にする。フロントエンド承認設計ステージ１０２において、設計者は、ＡＳＩＣを設計するための機能的および他の要求（送達時間および予算等）を含む仕様をカスタマから受け取る。カスタマはまた、これらの回路ブロックにいくつかの予め設計された回路およびテストベンチを提供し得る。カスタマに提供されたブロックと共に、設計者が利用するフロントエンド承認設計ステージ１０２は、異なる資源からの回路ブロックを入力として受け入れ、いくつかの回路ブロックは第三者によって供給され得、いくつかの回路ブロックは、レガシー回路ブロックであり得、そしていくつかの回路ブロックは、新しく権限が与えられ得る。これらの選択された回路ブロックは、ソフト、ファーム、またはハード設計状態であり得る（ソフト状態はＲＴＬレベルで存在し、ハードはＧＤＳＩＩレベルで存在し、そしてファームは、例えばゲートレベルまたはネットリストレベルにおいてソフトとハードとの間に存在する）。次いでフロントエンド承認設計ステージ１０２は、使用データのフィールド、挙動シミュレーションによるデータの推定、および／または部分的なインプリメンテーションデータを含む設計者の利用可能な経験を収集する。次いで、フロントエンド承認設計ステージ１０２の処理は、カスタマの要求、設計者の利用可能な経験、および設計者のリスクの承認可能な程度を含む設計プロパティパラメータに基づいて設計プロジェクトを承認するかどうかを設計者が決定するのに役立つ評価を提供する。さらに、機能的な仕様に基づいて、フロントエンド承認設計ステージ１０２は、回路設計内で使用された予め設計された回路ブロックの最後のセットを指示する。
【００４３】
プログラム可能なファブリックを用いて、フロントエンド承認設計ステージ１０２は、プログラム可能な回路のプログラミング電力を推定するステップ、および回路設計の要求を満たすことができることを確実にするステップを含む。例えば、ＦＰＧＡは、一般的には、所与の大きさに対して制限された機能的な能力を有する。ＦＰＧＡ（または他のプログラム可能なファブリック）の計画された機能性の全てが選択された大きさで実行できない場合、より大きな大きさのＦＰＧＡが利用されることを必要とする。しかし、より大きな大きさのＦＰＧＡは、全体の回路設計内の他のコンポーネントの大きさに影響を与える。さらに、各プログラム可能なファブリックのプログラミング電力および大きさを評価することに加えて、フロントエンド承認設計状態１０２は、プログラム可能な回路構成の電力消費を推定し、全体の回路設計に対してプログラム可能な回路構成のタイミング要求を最初に評価することに関し得る。
【００４４】
フロントエンド承認設計ステージ１０２は、好ましくは、評価の３つの段階を提供する。すなわち、粗い評価、中間の評価、および精細な評価である。１つの段階における評価が満足できない場合、フロントエンド承認設計ステージ１０２は、設計プロパティパラメータの改良を可能にし、次の段階でさらなる評価を行う。
【００４５】
提案された設計プロジェクトが承認可能である場合、フロントエンド承認設計ステージ１０２は、設計における問題が前もって早くから検出され、そしてこれらの問題が、プロジェクト要求、設計者の利用可能な経験、および選択された処理方法によって定義された境界の範囲内で包括的な態様で解決され得ることを確実にするために包括的なステップを提供する。フロントエンド承認設計ステージ１０２は、選択された予め設計された回路ブロック、設計基準、および相互依存的な設計制約を含む処理方法論を定義する設計仕様を発生する。
【００４６】
チップ計画設計ステージ１０４は、フロントエンド承認設計ステージ１０２の出力から選択された回路ブロックの各々に対するブロック仕様に設計仕様を変換する。チップ計画設計ステージ１０４において実行されたタスクは、（１）チップ設計と、アセンブリと、遅延、ルーティング可能性、領域、電力消失、およびタイミングの予測可能性に集中したインプリメンテーションとに対する計画を開発すること、および（２）制約を調整して識別することを含む。特に、フロントエンド承認設計ステージ１０２の出力として提供された設計基準および独立した制約に基づいて、チップ計画設計ステージ１０４は、フロントエンド承認において命令された境界（要求および制約等）内部にチップ計画を提供する。チップ計画設計ステージ１０４は、好適には、一度に１つの制約を考慮し、フロントエンド承認設計ステージ１０２によって特定された場合、全体の設計基準をさらに満たす。チップ計画設計ステージ１０４は、フロントエンド承認設計ステージ１０２において選択された回路ブロックの各々に対する予算を形成してこれを達成することによって、回路ブロックに対する仕様を修正し、そしてフロントエンド承認設計ステージ１０２によって特定された処理方法内部の制約を調整する。本発明のチップ計画設計ステージとは対照的に、既存の方法論は、新しい機能ブロックを発生させるかまたは設計基準（増加している設計時間および上昇しているプロジェクトのリスク）を満たすための処理技術を変化させる。チップ計画設計ステージ１０４はまた、以下にさらに詳細に説明されるように、グルー論理（すなわち、選択された回路ブロックを相互接続するために必要とされたハードウエア）に対する仕様を発生させる。チップ計画設計ステージ１０４は、３つのタイプのグルー論理（すなわち、チップ内の１つ以上の領域を占有する新しいグルー論理ブロック、選択された回路ブロックに分散された分散グルー論理、および上位レベルのブロックのグルー論理エレメントを含む）を出力として提供する。
【００４７】
プログラム可能なファブリックに関して、チップ計画設計ステージ１０４は、好ましくは、プログラム可能な回路構成の特別な要求を説明する。例えば、チップ計画設計ステージ１０４は、どのようなタイプのプログラミングであってもバス計画ステップの間に発生する必要があることを考慮し得る。シリアルプログラミングが発生する場合、専用またはマルチ化されたＩ／Ｏピンがプログラム可能性機能を支援するために必要とされ得る。チップ計画設計ステージ１０４は、電力消費を評価する場合、通常の動作およびプログラミング動作の間の電力引き込みを考慮し得る（例えば、プログラム可能な回路構成がロードされる場合）。各プログラム可能なファブリックに対するソフトウエアアルゴリズムがチップ計画設計ステージ１０４の間に含まれる場合、タイミング予算作成のために、各プログラム可能なファブリックに対するソフトウエアアルゴリズムが十分に定義される必要があり得ることにより、論理合成またはいくつかの他のタイプの推定技術を介して、タイミング推定（例えば、高境界および低境界）に到達され得る。上位レベルのフロアプランニングに対して、プログラム可能なファブリックがチップ計画設計ステージ１０４の間に含まる場合、プログラム可能なファブリックは、一般的には、予め固定されているかまたは大きさが調整可能であるかのいずれかであるプログラム可能でないファブリック状であり得るが、ほとんどのプログラム可能ではないファブリックとは異なり、プログラム可能なファブリックは、任意のアスペクト比に調整可能である必要はなく、その代わり、所定の離散的なアスペクト比を利用可能にする（段階的な関係に従って）だけであり得る。テスト設計に対して、テストブロックがチップ計画設計ステージ１０４の間に含まる場合、プログラム可能な機能性に対するテストブロックが好適には導入され、テスト計画またはアーキテクチャは、好適には、特定のファブリックに関連するテスト設計によって含まれない全体の回路設計のこれらの局面を含むように定義される。
【００４８】
選択された回路ブロックをシームレスに相互接続するためには、必要ならば、ブロック設計ステージ１０６は、標準的なインターフェースを形成するために各回路ブロック周辺にインターフェース（カラーと呼ばれる）を埋め込む。回路ブロックは、ソフト、ファーム、またはハードであり得、各カラーは、同様にソフト、ファーム、またはハードであり得る。ブロック設計ステージ１０６の出力は、（１）チップ内の全ての回路ブロックが制約および予算を満たし、専用のチップ設計計画およびアーキテクチャに適応し、（２）チップアセンブリ設計ステージ１０８は、全ての必要とされたモデルおよび全ての回路ブロックの図に提供され、（３）設計が方法論およびフローを開発するためおよびチップ計画設計ステージ１０４において発生された新しい回路ブロックに権限を与えることを可能にすることにより、レガシー回路ブロックに適応させ、そして第三者の回路ブロックに適応させ、および（４）設計が所与のチップアーキテクチャおよび予算に適応することを提供する。
【００４９】
プログラム可能なファブリックに対して、ブロック設計ステージ１０６におけるカラーリングプロセスは、プログラミングポートラッパーをプログラム可能なファブリックに追加する必要があり得る。あるいは、カラーリング処理は、さらなる入力／出力バッファの追加に関し、このような機能を必要な場合（例えば、ＦＰＧＡは、チップの残りとは異なる電圧レベルで動作し得る）、電圧レベルシフトまたはトライステートとして実行する。好適には、このような入力／出力バッファリングは、プログラム可能なファブリック回路構成とカラーの一部として提供される任意の境界スキャン回路構成との間に存在する。
【００５０】
チップアセンブリ設計ステージ１０８は、設計ステージ製造のための上位レベル設計を取り出す（ｔａｐｅ−ｏｕｔ）ために回路ブロックを統合する。チップアセンブリ設計ステージ１０８は、ハードブロックの最終的な配置およびチップバスルーティング、ならびに、任意のグローバル設計の細部の完成を含む。チップアセンブリ設計ステージ１０８は、全ての回路ブロックが設計され、改変され、そしてチップ設計に統合されるまで、開始しない。チップアセンブリ設計ステージ１０８のための入力は、電力、領域、ならびにフロントエンド承認設計ステージ１０２またはチップ計画設計ステージ１０４から受け取られたタイミングマージン仕様を含む。
【００５１】
検証設計ステージ１１０は、各ステージにおける設計がフロントエンド承認設計ステージ１０２において供給された機能的な仕様およびチップテストベンチにおいて詳述されたようにカスタマの機能的要求を満たすことを確実にする。検証設計ステージ１１０は、機能検証１１２、タイミング検証１１４、および物理検証１１６を含む。
【００５２】
機能検証ステップ１１２は、設計の各ステージにおいて選択された回路ブロックに対する論理機能およびチップテストベンチがカスタマの仕様の機能的要求を満たすことを確実にする。機能的検証は、フロントエンド承認設計ステージ１０２、チップ計画設計ステージ１０４、ブロック設計ステージ１０６、またはチップアセンブリ設計ステージ１０８の間に実行され得る。タイミング検証は、設計の各ステージにおける信号タイミングが、論理機能を生成し、カスタマの仕様に特化されたテストに合格するのに適切である。タイミング検証は、フロントエンド承認設計ステージ１０２、チップ計画設計ステージ１０４、ブロック設計ステージ１０６、またはチップアセンブリ設計ステージ１０８の間に実行され得る。物理検証は、回路設計に対する物理的レイアウトがカスタマ仕様を満たすことを確実にする。プログラム可能なファブリックについて、検証ラッパーは、回路設計のプログラム可能な部分を支援するために提供されるプログラミングポートに対して必要とされ得る。
【００５３】
設計プロセスの間、フロントエンド承認設計ステージ１０２、チップ計画設計ステージ１０４、ブロック設計ステージ１０６、およびチップアセンブリ設計ステージ１０８が意図された機能を実行するだけではなく、検証機能１１０を含む、機能的検証１１２、タイミング検証１１４、および物理的検証１１６に対して必要とされた情報を生成する。設計処理の特定のステージにおいて検証の間に任意のエラーが発生する場合、これらのエラーは、好ましくは、次のステージに進む前に補正される。
【００５４】
従って、チップアセンブリ設計ステージ１０８では、設計プロセスは、チップの製造に対して、上位レベルの設計を生成するばかりではなく、設計内で使用された回路ブロックの各々に対するチップテストベンチおよびチップに対する全体のチップテストベンチの検証を完成する。
【００５５】
ここで、図２〜図１５が概要形式で説明される。これらの図の各々は、以下により詳細に説明された材料のハイレベルな説明を提供する。
【００５６】
（フロントエンド承認１０２）
図２を参照すると、フローチャート２００は、フロントエンド承認設計ステージ１０２において使用され得るような種々のステップ２１０〜２１６を示す。
【００５７】
（チップ計画１０４）
チップ計画設計ステージ１０４は、好ましくは以下のモジュールを含む。
（１）クロック設計
（２）バス識別および設計
（３）電力設計
（４）Ｉ／Ｏおよびアナログ混合信号要求
（５）テスト計画
（６）タイミングおよびフロア計画
（７）バス検証
（８）プログラミング計画
図３を参照すると、示されたクロック計画モジュールが存在する。
【００５８】
図４を参照すると、示されたバス検証および計画モジュールが存在する。
【００５９】
図５を参照すると、示された電力計画モジュールが存在する。
【００６０】
図６を参照すると、Ｉ／Ｏおよびアナログ／混合信号要求を導くための示されたステップが存在する。
【００６１】
図７を参照すると、示されたテスト計画モジュールが存在する。
【００６２】
図８を参照すると、示されたタイミングおよびフロア計画モジュールが存在する。
【００６３】
（ブロック計画１０６）
図９を参照すると、ブロック設計ステージの示されたフローが存在する。
【００６４】
（チップアセンブリ１０８）
図１０を参照すると、チップアセンブリ設計ステージの示されたデータフローが存在する。
【００６５】
図１１を参照すると、チップアセンブリ設計ステージの示されたタスクフローが存在する。
【００６６】
（検証１１０）
図１２、１３、１４および１５を参照すると、検証設計ステージに対する機能的検証フローが示されている。
【００６７】
（実現可能な評価のための拡張可能な方法論）
最初にフロントエンド評価に取りかかると、図１６は、本明細書において議論される一実施形態にしたがう複数の事前設計された回路ブロックを用いる回路設計の実現性を評価するための好適な方法論を示す。
【００６８】
図１６では、方法論のための入力は、入力としてデータの使用領域を使用するように当初から設計されている。しかしながら、新しい設計計画を評価する際、新しいタイプの入力１、２および３が新しい設計計画の実現性を評価するために使用される必要がある。方法論を適応させるために、方法論が新しいタイプの入力を使用して新しい設計計画のための実現性の評価を実行し得るように新しいタイプの入力が処理される。
【００６９】
図１７は、図１６に示される方法論を用いる実現性評価結果を示す。図１７は、垂直軸上にリスクを表わし、時間／コストが水平軸に沿っている。リスク表示によると、これら３つのタイプの新データを使用することのリスクは、使用データの領域のみを使用する場合に提示されるリスクと比較してわずかに増加する。また、図１７から、タイプ３入力がリスク上に最も大きい影響があることが見られ得る。しかしながら、時間／コスト表示によると、これら３つのタイプの新データを使用することによって、時間／コストは、使用データの領域のみを使用することによって形成されるリスクに比較して大きく増加する。図１７に示される本発明のリスク対時間／コスト計算の派生を考慮することによって、段形成前のブロックが設計方法論における正しい使用のために事前設計および修飾される。段階形成前の設計計画は、好適には、既存方法の部分、例えば、ブロックオーサリングピース（ｂｌｏｃｋ−ａｕｔｈｏｒｉｎｇ  ｐｉｅｃｅ）にある。
【００７０】
図１８は、複数の設計前回路ブロック用いる回路設計を評価する方法論を示す。図１８では、方法論のための入力は、入力として使用データの領域を使用するように当初から設計されている。しかしながら、新しい設計計画を評価する際、新しいタイプの入力Ｘ、Ｙ、Ｚが新しい設計計画の実現性を評価するために使用される必要がある。新しい入力タイプを適応させるために、方法論は、新しい入力が新しい設計計画に対する実現性評価を実行するために使用され得るように改変される。
【００７１】
図１９は、図１８に示される本発明の方法論を用いて取得された評価された実行可能性を示す。図１９は、垂直軸に沿ってリスクを、水平軸に沿って時間／費用を示す。このリスクインジケータによると、３つの新しいタイプを用いる場合に提供されるリスクは、データの使用領域のみを用いる場合に提供されるリスクと比較してはるかに増加する。また、図１９から、タイプＺ入力がリスク上に最も大きいインパクトを有することを見得る。しかしながら、時間／費用インジケータによると、新しい入力の３つのタイプを追加で用いることによって提供された時間／費用は、データの使用領域のみを用いることによる時間／費用と比較して適度に増加する。
【００７２】
入力の新しいタイプは、事前設計された回路についての見積もりデータまたはインプリメンテーションデータであり得る。図１６〜１９に示される結果に基づき、システム集積者は、トレードオフを決定を行い得る。
【００７３】
（フロントエンドアクセプタンスにおける実行可能性評価）
図１におけるフロントエンドアクセプタンス（ＦＥＡ）設計ステージ１０２は、提示された設計の実行可能性およびリスク評価を含む。設計は、評価された基準が許容できるリスク許容度の範囲内であれば実行可能である。
【００７４】
ある意味で、ＦＥＡは、システム集積者が提示された設計を受け入れるリスクを仮定し得るポイントへの設計洗練のプロセスである。それ自体では、要求された設計の最終結果におけるエラーの知識欠如、したがって、その低減のプロセスである。開始点では、ＦＥＡプロセスは、カスタマーによって配信された設計要求のセット、設計を受け入れることに対する集成者のリスクプロファイル、事前設計されたブロックのセット、および集成者の事前設計されたブロックの以前の知識および事前設計されたブロックについての経験を受け取る。事前設計されたブロックは、レゾリュ−ション（ハード、ソフト、またはファーム）の種々のレベルにあり得る。ブロックのレソリューション、以前の経験および理解は、ブロックにわたって、エリア予測、パワー、性能等において広範囲のエラー限界を引き起こす。
【００７５】
ブロックのそれぞれに対して、設計洗練は、３レベルのレゾリューションにおいて提示され得る。
【００７６】
（１）インテグレータの経験領域（ＦＯＥ）
（２）実際のモデルおよびこれらのモデルを実行するためのツールを用いる見積もり
（３）ブロックを受信されたものより高いレベルの設計レソリューションに取り入れることによるディップ
３レベルの設計レソリューションは、ソフト、ファーム、そしてハードと上がる順に配列される留意されるべきである。全てのブロックおよび相互接続基準予測を不必要に洗練することなく実行可能性評価を行う機構を提供することによって効率性が達成される。
【００７７】
図２０は、フロントエンドアクセプタンス（ＦＥＡ）プロセスに対するフロー図を示す。
【００７８】
図２０では、ＦＥＡプロセスは、上記の３レベルの設計洗練を反映する３つの段階の実行可能性評価を含む。これらの３つの段階は、粗グレイン評価、中間グレイン評価、精密グレイン評価である。
【００７９】
粗い評価は、設計インテグレータの類似の設計に関する以前の経験に基づく評価に支配される経験領域である。粗い評価は、何十ものブロックおよびシステム設計オプション、および設計見積もりエラー許容度が５０パーセント以上のオーダである状況に特に適している。粗い解析が考慮されているブロックの通り一遍の検査を行うために用いられ得、ここでは、ブロック間の相互作用の見積もりは、重大ではない。この段階では、最も可能性が高いのは、考慮される全てのブロックが採集の設計において用いられるわけではないことである。
【００８０】
中間評価は、見積もり−ドメイン評価であり、方程式による挙動の解析公式またはシミュレーションによって見積もりする。これは、２〜１０のシステム設計オプション、および受入可能な設計見積もりエラー許容度が２０％のオーダーである状況に適しており、集成者は、ブロックが相互作用する方法を理解している。設計の操作充足性に対して重大になっているブロック間の相互作用を検査するために用いられ得る。この段階では、考慮中の全てのブロックは、最終設計において用いられる可能性が高い。
【００８１】
最も洗練された（精密な）評価は、ブロック設計の洗練から測定を行う設計ディップ支配の評価である。ディッピングは、新しいブロックがソフトブロックに、事前設計されたソフトブロックがファームブロックに、そして、事前設計されたファームブロックがハードブロックに変換されるプロセスである。結果は、シミュレーション、エミュレーションまたはプロトタイプのいずれかから発生される。精密な評価は、既存の設計洗練が不十分である重大な問題の最終リゾリューション中等の受入可能な設計見積もりエラー許容度が５％未満である単一オプションチップ設計の全てまたは一部に適している。これは、十分な状態であることを保証するためまたはブロックのために任意の既存のシミュレーションモデルによって提供されたレゾリューションが十分であることを保証するために詳細に研究される必要があるチップ挙動またはブロック相互作用のサブセットを検査するために用いられ得る。ブロックが設計要件を満たすことに失敗することを検査するためにも用いられ得、これは、強いインパクトを最終設計実現可能性に与える。この段階では、考慮中の全部のブロックがディップされるわけではなく、その代わりに、実質的にＦＥＡ決定プロセス上に重大なインパクトを有するブロックのみがディップされる。
【００８２】
図２０では、各三角形の幅が、システムＦＥＡ基準の予測におけるエラーを表わす。評価の各レベルにおいて、キーは、ＦＥＡ決定が迅速になされ得るように設計者のエラーを低減しながらＦＥＡ基準をできる限り少なく洗練することである。ＦＥＡプロセスの各段階において、基本的な意図および戦略は、以下に列挙されるように同一である。
【００８３】
（１）考慮したブロックについて利用可能な情報を集める；
（２）システム見積もりエラーにインパクトを与える最も可能性があるブロックをローカルに識別および洗練する；
（３）設計がＦＥＡ制限に合うかどうかを評価する。合えば、ＦＥＡプロセスを停止する。そうでなければ、
（４）ＦＥＡ制限が合わない場合には、システムにおいてブロック見積もりをグローバルに洗練する。
【００８４】
図２０に示されたＦＥＡプロセスのキー部分は、システム基準の予測において受入可能なグローバルエラー（または、すべてのエラーを計算し、および、グローバルエラーを受入可能な境界の範囲内にするためにどの少数のブロックが見積もり洗練を必要とするかを識別する方法である。この計算プロセスは、３つのパラメータを必要とする。
【００８５】
（１）決定を行うための受入可能なグローバルエラーの見積もり
（２）現行システム解析から生じるグローバルエラーの見積もり
（３）設計における特定のブロックを見積もりする場合のエラーに対するグローバルエラーの感度（ブロックエラーインパクトともいう）
第一のパラメータは、システム集成者のリスクプロファイル、顧客によって供給される制約、およびグローバルエラーの良好な予測によって規定され、現行のデータの状態についてのシステム予測に基礎をおくことから生じる。第二および第三のパラメータは、すべて、正確なエラーインパクト曲線を構築することから導き出される。図２１を参照すると、本発明による、洗練プロセスの駆動が示され、エラーインパクト曲線が与えられている。
【００８６】
ＦＥＡプロセスをさらに規定するために、本発明は、４つの基本評価技術を用いる。
【００８７】
１．ＦＥＡ決定プロセス：データアウトに基づいてデータイン（Ｄａｔａ−ｉｎ）、データアウト（Ｄａｔａ−ｏｕｔ）および決定プロセスを規定する（すなわち、データアウトは、どのように受入可能なリスクの評価に関連するか？）
２．ＦＥＡデータ抽出プロセス：データアウトの発生に対して考慮される抽出レベルのためのデータインの完全なセットを移動させる。
【００８８】
３．ＦＥＡブロック洗練識別：システム見積もりインパクトを確立するための共通機構を規定し、システム設計内の見積もりエラーおよびブロックの臨界が与えられる（すなわち、決定プロセスに対する受入基準が合わない場合に最高の潜在的なインパクトブロックがさらに洗練される）。
【００８９】
４．ＦＥＡ評価軸測定基準：ＦＥＡに関連付けられる受入軸のそれぞれに対して用いられる実際の測定基準を規定する（すなわち、システム内のブロックの臨界が規定される方法を規定する）。
【００９０】
本明細書に開示される特定の方法およびシステムでは、見積もり修正曲線のセットがＦＥＡプロセスを検証するために使用される。見積もり修正曲線のそれぞれは、ＦＥＡ軸上に提示され、ＦＥＡプロセスを検証するための要素および基準を視覚的に提供する。見積もり修正曲線の機能をより良好に説明するために、以下の要素および基準が規定される。集約すると、これらの要素および基準は、アクセプタンスのＦＥＡ軸と呼ばれる。これらの規定は、ブロックおよびシステム全体の両方に適用される。
【００９１】
2004531056.tif 000003
ＦＥＡプロセスを行う前に、カスタマーは、できる限りの以下の情報を有するシステムインテグレータを提供する。
【００９２】
（１）ソフト、ファーム、またはハードフォーマットのいずれかである回路ブロックのセット
（２）見積もりに対するエラー許容度と共に、ブロックのためのシミュレータ（エスティメータ）または以前の経験の見積もりのセット
（３）全体のチップ機能性および性能要求を記載する仕様のセット
（４）プロジェクトに対する受入可能なスケジュール、費用、およびリスクに関する条項のセット
カスタマーは、さらに、以下を提供し得る。
【００９３】
（５）チップに組み込まれた任意の新しいブロックに対する作用規定
（６）既知の臨界事項の識別
ＦＥＡプロセスを行う前に、システムインテグレータは、以下を行うできである。
【００９４】
（１）設計の適切さが評価されるリスクプロファイルを決定すること。これは、以下を含む。
【００９５】
ａ．ガードバンド−各ＦＥＡ軸ごとのインテグレータの過設計マージン。
【００９６】
ｂ．アクセプタンスリスク−カスタマー要求を受け入れる前に設計が要件を満たす確実性。これは、標準偏差測定−Ａσ設計アクセプタンスリスクとして簡単に表現される。
【００９７】
ｃ．拒絶リスク−特定化された設計が利用可能なブロックを用いて組み立てられかつ製造されることができない確実性。拒絶は、実際に、システム集成者にとってリスクのある挙動であることに留意のこと。利用されるリスク設計は、初期評価が疑わしいとされたとしても拒絶された設計が実際に実行可能であるリスク設計である。これはまた、標準偏差測定−Ｒσ設計拒絶リスクとして表現される。
【００９８】
（２）任意の新しいまたは第三者ブロックと組み合わされた提示されたブロックが受入可能なリスク制限内のプロジェクト制約に合わせるのに十分であることを検証すること。
【００９９】
図２２を参照すると、例示の修正曲線見積もりが示される。水平軸はＦＥＡ軸であり、任意のカスタマー制約またはシステムに対する全体の制約を表わし得る。説明を容易にするため、ＦＥＡ軸はパワーを表すと仮定する。垂直軸は、見積もり修正を表わす。図２２によると、パワー制約のガードバンドが、カスタマーによって初期に特定された制約とＦＥＡプロセスによって改変された制約との間にある。与えられた例では、ガードバンドによって改変されたパワー制約が拒絶領域内にあるので、設計は拒絶されることに留意のこと。これは、初期に特定されたパワー制約が拒絶領域にない場合であっても真である。
【０１００】
改変されたパワー制約がＡσとＲσマーカーとの間にある場合、ＦＥＡ洗練プロセスは処理される。このプロセスは、受入または拒絶決定が洗練された修正曲線に基づいてなされ得るまで期待されたエラー変動（すなわち、この例ではパワーエラー変動）を低減し継続する。
【０１０１】
図２３を参照すると、ＦＥＡを検証するためのプロセスが示される。本発明のＦＥＡ変動プロセスは、４段階を含む。
【０１０２】
０．前ＦＯＥ相（図示せず）
アクセプタンスの各ＦＥＡ軸毎にカスタマー設計制約を取得する。要求されたガードバンドによってこれらの制約のそれぞれを改変する。これらの改変されたカスタマー制約は、ＦＥＡプロセスの検証のためのみに用いられ、単に設計制約と呼ばれる。
【０１０３】
１．ＦＯＥ支配段階
システム集成者は、要求された制約が一致されるように保証される（合格に対するＡσまたは失敗に対するＲσによって規定される信任より高い）かどうかを決定するためにＦＯＥ見積もりおよび見積もりエラー許容度を結び付けることによってＦＥＡを開始する。
【０１０４】
（ａ）第三者ブロックの考慮にかかわらず、制約がそれでも破られる場合、設計は可能ではない。システム集成者は、オプションのセットを有するカスタマーおよびこれらの構成に合わされる制約に戻らなければならない。
【０１０５】
（ｂ）制約が受入可能なリスクの範囲内に合わされる場合、ＦＥＡプロセスは、完成する。
【０１０６】
（ｃ）受入可能に至らない、設計の合格または失敗を予測する信任が存在する場合、見積もり段階が開始されなければならない。見積もり段階に入るために、「最も合格の可能性がある」設計構成（すなわち、最良）のセットが、選択されなければならない。
【０１０７】
２．見積もり支配段階
ＦＯＥステージから導き出された最良設計のセットのために、臨界性の識別がなされなければならない。すなわち、含まれるブロックのそれぞれの上にエラー許容度が与えられ、設計が制約検証を合格することを検証する可能性が統計学的に最も高い。これは、ブロックに対するＦＯＥ仕様予測の変動の大きさおよびブロックが問題になる設計制約上に有するインパクトの両方の積である。見積もりは、できるだけ非臨界設計を引き抜き、そして、そのまま残るものについての見積もりに特有の設計を生成することよって進むべきである。
【０１０８】
（ａ）違反：上記手順１（ａ）に類似。
【０１０９】
（ｂ）満足：見積もりの正確さを増加させることによって不確定のレベルがさらに低減される見込みがない場合（引き抜く量を低減することは、エラー許容度が見積もりにすでに含まれるブロックによって支配されるという事実に起因して任意の統計学的に重要な態様における見積もりを改善しない）、または、ＳＯＣ設計の全見積もりが、所与の既存のブロックモジュールを構築する場合、最良の設計がディッピング段階上で合格しなければならない。
【０１１０】
３．設計ディップ支配段階
グローバルなエラーが最も敏感であるブロック見積もりの洗練は、次いで、見積もり段階により進む。ＦＥＡが確認されるかまたは否定されるまでこのプロセスを繰り返して継続する。統計学的な臨界の規定は、類似している。
【０１１１】
図２４を参照すると、本明細書中に記載されたような一実施形態によるＦＥＡ設計特性洗練プロセスを用いる洗練見積り修正曲線が示される。上記のようにＦＥＡ段階０から３に移動する洗練プロセスを通じて、洗練された見積り修正曲線上の予想されるエラー変動は、図２２に示される見積もり修正曲線のものと比較して著しく低減される。このため、受入または拒絶の決定は、図２４に示されるような洗練された見積り修正曲線に基づいてなされ得る。ここで、このような決定は、図２２に示される見積り修正曲線に基づいてなされてもなされなくてもよい。
【０１１２】
ＦＥＡ決定が、検証の一つの相において利用可能な情報およびデータに基づいてなされ得ない場合、設計特性洗練プロセスは、予想されたエラー変動を低減するように行われ得る。洗練されたデータおよび情報に基づいて、ＦＥＡ変動プロセスは、次の段階において行われ得る。設計特性洗練プロセスは、好適には、以下の３つの局面を含む。
【０１１３】
（１）ＦＥＡデータ抽出プロセス
（２）ＦＥＡブロック洗練識別
（３）ＦＥＡ評価軸測定基準
図２５を参照すると、好適はＦＥＡデータ抽出プロセスが示される。好適には、標準化された機構またはプロセスが、システム設計における各ブロックに関連付けられる予測エラーのための「システムインパクトの見積もり」を確立するために提供される。この機構は、ブロック洗練識別と呼ばれ、任意の特定のブロックの特性（ＦＥＡ設計基準、例えば、パワー、エリア、性能等）に関して要求されたエラー境界がＦＥＡシステム設計評価の各洗練相について決定されることを可能にする。
【０１１４】
Ｌ（β）がカスタマーによって特定された制限にあるとすると、設計がＦＥＡ基準βを満足するために、任意の要求された設計マージンによって改変される。ＦＥＡ基準βに抗して測定された設計の期待値がＥ（β）であるとする。設計がＦＥＡ基準βと比較して合格／失敗として規定されるための、設計決定制約、すなわち、「最大エラー許容度」は、ＤＤＣ（β）＝｜Ｌ（β）−Ｅ（β）｜によって与えられる。予想された「合格」に対して、Ｅ（β）自体は、ＦＥＡ基準に対する受入領域の範囲内になけらばならず、予想された「失敗」に対しては、Ｅ（β）は、拒絶領域の範囲内になけらばならない。効率的には、「合格」に対する第一の場合において、Ａσｓｙｓｔｅｍ＜ＤＤＣが要求され、「失敗」に対する第二の場合において、Ｒσｓｙｓｔｅｍ＜ＤＤＣが要求される。この不等式が満足されない場合、システム解析は、決定品質結果を保護しない。
【０１１５】
一般に、システム評価の以前の段階によって生成されるとき、平均見積りＥ（β）がシステム基準βの最終的な見積りであることが留意されるべきである。すなわち、中間評価ステージは、粗い評価ステージの最終の見積りの平均をとり、精密評価ステージは、中間評価ステージの最終見積りの平均をとる。プロセスを開始するために、粗い評価ステージは、最初にＦＥＡ基準のそれぞれに対して粗レベル期待値見積りを確立することによって入らされなければならない。
【０１１６】
システムが設計決定制約と比較して評価される（ＤＤＱ）のために、関係は、ブロック見積もりに関連付けられるエラーと、システムについての全体の見積りエラーとの間に確立されなければならない。ブロック見積りに関連付けられるエラーは、ブロックのβ基準を見積るときの固有のエラーだけでなく、そのブロックの特殊な影響および統合費用を見積りすることの困難性についてのブロックエラーも含み得る。ブロックを見積もる場合のエラーは、結果として、システム臨界測定Ｃによって倍率をかけられる。このシステム臨界測定Ｃは、その特性またはＦＥＡ基準βに対する欠落または欠陥（エラー）に基づいてブロックを統合する際の困難性の測定である。システムの合格（失敗）に関する決定は、σｓｙｓｔｅｍへの｛Ｃｂｌｏｃｋ，σｂｌｏｃｋ・｜ｂｌｏｃｋ  σ  ｓｙｓｔｅｍ）のセットの関連およびＦＥＡ基準のそれぞれに対して要求される不等式：ＦＥＡ基準のそれぞれに対して、Ａσｓｙｓｔｅｍ＜ＤＤＣ（Ｒσｓｙｓｔｅｍ＜ＤＤＣを通じて確立される。
【０１１７】
上記に表わされるシステム不等式に対する臨界測定Ｃｂｌｏｃｋニュートラルの算入を維持するために（すなわち、σｓｙｓｔｅｍは、臨界倍率されたブロックエラー：Ｃｂｌｏｃｋ，σｂｌｏｃｋを結び付ける式から定式化される）、臨界測定は、好適には、Σｂｌｏｃｋｓ（Ｃｂｌｏｃｋ）２＝１であるように規格化される。これを評価するためのプロセスは、評価されるシステム特性のクラスに応じてわずかに変動する。ＦＥＡの立場から、好適には、の３クラスのシステム特性があり、それぞれは、以下に記載される。
【０１１８】
・完全（ブロック）制約（例えば、イントラサイクルディレイ（Ｉｎｔｒａ−Ｃｙｃｌｅ  Ｄｅｌａｙ）、スループット）
・相対（ブロック）制約（例えば、パワー、エリア、待ち時間、費用、スケジュール）
・混合（ブロック）制約（例えば、質）
簡略のため、ＦＥＡのために基準βは、ＢＤＣをブロック設計制約として規定する。ここで、設計アクセプタンスのためのテストである場合、ＢＤＣｂｌｏｃｋ＝Ａ．Ｃｂｌｏｃｋ，σｂｌｏｃｋであり、設計拒絶のテストである場合、ＢＤＣｂｌｏｃｋ＝Ｒ．Ｃｂｌｏｃｋ，σｂｌｏｃｋである。次いで、各ＦＥＡ基準に対して、
ａ．完全制約：決定品質結果を達成するために、各ブロック、または中間環境（例えば、ルーティングロード等を含む）に巻き込まれた各ブロックは、完全制約のためにＤＤＣを合格しなければならない。数学的に、完全制約についての決定品質結果の達成は、全てのブロックに対して、ＢＤＣｂｌｏｃｋ＜ＤＤＣであることを意味する。
【０１１９】
ｂ．相対制約：決定品質結果は、システムにわたるブロック設計制約の平方合計がＤＤＣの平方未満であれば達成される。用語「相対」は、この制約に対する評価の受入可能なエラーとして用いられ、システム全体を構成するブロック間で区分化されるという柔軟性を有する。相対タイプのなんらかの評価基準は、複数の制約を有することに留意のこと。この例としては、待ち時間があり、完全なシステムの有効な評価に寄与するいくつかの臨界パスが存在し得る。数学的には、相対制約についての決定品質結果の達成は、ランダム変数とは無関係に全ブロックエラーがガウス分布であることを仮定して、Σｂｌｏｃｋｓ（ＢＤＣｂｌｏｃｋ）２＜ＤＤＣ２を意味する。
【０１２０】
ｃ．混合制約：混合制約は、相対および完全タイプの制約の両方を含むタイプである。例えば、
品質は、混合された制約である。設計範囲内のブロックは、品質の測定上の特定の境界を越え得ないが、システムにわたる全品質評価の加算も、特定の範囲内に下がらなければならない。この場合には、ブロックに対するＤＤＣｂｌｏｃｋおよびシステム全体に対するＤＤＣｓｙｓｔｅｍの両方がある。数学的に、混合制約のシステム特性に対して、２つの基準が満足される必要がある。
【０１２１】
（ｉ）全てに対して：ブロックεシステム、ＢＤＣｂｌｏｃｋ＜ＤＤＣｂｌｏｃｋ
（ｉｉ）Σｂｌｏｃｋ（ＢＤＣｂｌｏｃｋ）２＜（ＤＤＣｓｙｓｔｅｍ）２
図２６を参照すると、ブロック見積り洗練の必要性のレベルを識別するためのプロセスが示されている。
【０１２２】
示されるように、ＦＥＡブロック洗練識別は、好適には、以下を含む３ステップを含む。
【０１２３】
１：  完全または混合制約タイプの各ＦＥＡ評価基準に対して、完全エラー許容度（ＣＩＣ）を達成するために要求される作業レベルが決定される。完全制約の必要性を満足させるモデルを洗練する副生物として、相対制約に関連付けられるいくつかのエラー境界も低減され得る。
【０１２４】
２：完全制約および混合制約タイプの完全部分を満足させるためにモデルが洗練された後の予測されるエラーに基づいて、システムに対する残りのシステムエラー許容度（ＣＩＣ）が決定され、分離ＩＰブロック間に区分化される。この区分化は、見積もりを構築するために要求される作業を最小にするように規定される。この区分化の柔軟性は、組みたれられたシステム内のブロックのそれぞれに対する寄与の規定された臨界性によって緩和される。これは、エラーインパクトの概念を規定する。この問題は、各ＦＥＡ軸に沿う受入可能なエラー許容度に対する必要な作業を同時に最適化しなければならないことに留意のこと。
【０１２５】
３．任意のステージにおいて、システムの適合性が提示されたＣＩＣを用いて決定され得ない場合、これらは、さらに密接にされる必要があり、以下のいずれかであれば、プロセスが再度繰り返される必要がある。
【０１２６】
（ａ）ブロックに対して、特定の完全制約が不十分である場合、または、
（ｂ）システムに対して、チップに対する相対制約が不十分である場合、
図２７を参照すると、ＦＥＡ評価軸測定基準が示されており、これは、本発明による評価軸臨界（ＡＡＣ）の概念を規定し、適切な例示的臨界測定を含む表を含む。ＡＡＣは、以下の関連：ＥＳＩ＝ＡＡＣ＊ＥＥＥに基づく予想される見積りエラー（ＥＥＥ）を通じて予想されるシステムインパクト（ＥＳＩ）に関連する。
【０１２７】
図２７に示されるように、表は、好適には、以下の５列を含む。
【０１２８】
（１）評価軸：ＦＥＡは、これらの基準に基づいて測定される。
【０１２９】
（２）制約タイプ：各ＦＥＡ評価軸は、関連付けられる１以上の制約ライプを有し得る。
【０１３０】
（３）制約クラス：上記に規定されるようなクラス
（４）ルーティング洗練：チップルーティングのインパクトが、特定されたブロックおよびシステム制約と同一程度のエラーであることを保証するのに必要なルーティング洗練のタイプ
（５）臨界測定：ＦＥＡ評価軸に関連付けられる特性の臨界を測定する標準的な方法
表のいくつかの要素は、ルーティング臨界に対する基準を形成する。ルーティング臨界は、チップの任意の出力ピンまたはチップ入力パッドに対して、ピンルーティング臨界＝（予想された正味長さ）＊（キャパシタンス／単位長さ）として規定される。ブロックルーティング臨界は、ブロックの出力ピンにわたるピンルーティング臨界の合計である。
【０１３１】
シンボル：αは、効率的なルーティングエリアスカラーを示す。：α＊（ルーティング臨界性）は、単位およびルーティング臨界性のスケールをエリア適用性数に変える。
【０１３２】
ルーティングの結果として消費されるパワーは、ライン上の活性度の見積りを必要とする。これは、レゾリュ−ションのブロックまたはピンレベルにおいてなされ得る。ブロックに適用された場合、活性度見積りは、ブロックの出力ライン上の平均の活性度から導き出され、Ｅｂｌｏｃｋで示される。
【０１３３】
点接続は、数個のファンアウト点が共有バスの使用によって接続されなければ、任意のファンアウト点としてカウントされる。共有バスは、単一の明確なブロックとしてカウントする。ルーティング臨界は、ピンへのルーティング接続において予想される困難性の測定であり、したがって、それは、ＦＥＡ不確定性の測定である。評価軸の多くは、なんらかのレゾリューションレベルでの混合制約として識別され得ることに留意のこと。：例えば、エリアは、最初の平面図が規定され、かつ、ＳＯＣ設計チップレベルの制約をブロックレベルの制約に区分するために使用された後に混合されたものとして規定され得る。しかしながら、迅速なＦＥＡ期の間に用いられる支配的制約タイプが列挙される。表において用いられる用語エラーは、問題となっている特性に関連するようなエラーについての束縛を指す。
【０１３４】
（経験データ領域の組織化）
設計経験は、ＢＢＤ方法論のシステム決定プロセスにおける関連部分であり得る。ＢＢＤ方法論は、単一キー設計者または概念「会社設計経験」に対するアーキテクチャに関連付けられる経験の概念を拡張する。経験のこの一般的な「プール」は、本明細書中では、ＢＢＤ経験領域（ＦＯＥ）と呼ばれる。
【０１３５】
ＦＯＥの構築および使用に対する４つの概念および／または機構は、好適に採用される。これら４つの概念および／または機構は、
ａ）データ収集−ＦＯＥデータを取得および開始するための厳密なプロセスの規定
ｂ）データ分類−関連分類を展開するための情報分類および機構。このような分類は、集められたデータが蓄積された設計知識の量が増加するにしたがって統計学的に解析され、外挿され、そして、グローバルに洗練され得ることを保証する。
【０１３６】
ｃ）データ証明−「経験則」ナンバーとして他の方法で参照され得るものにおいて「信頼」の修正の確実さを構築するプロセスの規定。ＦＯＥデータを証明することは、ＦＯＥデータベースから構築された見積もりが統計学的によく境界をつけられることを保証する。
【０１３７】
ｄ）データ適用−設計プロセスにＦＯＥを適用するための機構。これは、ＢＢＤのためのフロントエンドアクセプタンスの一部である。
【０１３８】
（経験規定の領域）
ＢＢＤでは、経験領域は、設計スタイル、設計目的、および設計特徴の臨界測定にしたがって分類された以前の設計の測定からコンパイルされたデータとして規定され得る。臨界特徴は、エリア、スループット、パワーおよび待ち時間を含み得る。経験に基づく見積もりの規定は、類似の設計または設計挙動を伴う経験に基づく系統的な予測である。これに続くのは、ＦＯＥ見積もりの規定がＦＯＥデータを用いる経験に基づく見積もりであることである。
【０１３９】
これは、問題となっている設計の特定の解析、あるいは、ハードウェア設計が以前の露出から実際に知られる場合には、そのハードウェアを要求する新しい挙動の特定の解析を意味しない点で、ＢＢＤ見積もりとは性質が異なることが留意されるべきである。例えば、ＤＳＰコアは、会社内で展開され得、ルーチンを埋め込むＦＩＲフィルタは、以前のコアの実例でＤＳＰコア上で実行され得る。次いで、要求され得るのは、考慮されるその同一コア上で走行するＦＦＴアルゴリズムの実現可能性である。最初の経験則が、設計に関するＦＩＲオペレーションを実行する場合に観察される以前のアルゴリズム効率にのみ基づく場合、これは、ＦＯＥ見積もりである。
【０１４０】
経験領域は、以前の設計プロジェクトのセットの間に導き出された情報を明示的に利用しなければならない。ＦＯＥデータは、標準データベースを通じて目録に載せられ、格納され、そして、アクセスされることができなければならない。
【０１４１】
設計に用いられる経験に基づくデータの３つの異なる分類があり、データの各形態は、特定のエラープロファイルに関連付けられる。
【０１４２】
ａ）プロジェクトデータ−プロジェクト時に設計者が要求する見積もり。設計者は、ＦＯＥデータベースに記録されるような他の経験を利用しないが、彼自身の目録に載せられていない設計経験をより利用する。設計見積もりにおけるエラーは、設計者エラー変動によって与えられ、これは、一般的な設計に観察される。設計者エラー変動は、正確に結果を予測する設計者の能力の一般的な履歴を測定することから構築される。
【０１４３】
ｂ）予測されたデータ−設計分類内であるが、心にとどめる特定のプロジェクト外で、設計者は、既存のＦＯＥデータを拡張するために彼の最良の推測パラメータ関係を与えることを要求される。この場合には、拡張されるＦＯＥデータは、単一の設計ポイントと同じほど少なく形成され得る。これに対するエラーは、パラメータ化エラーにおいて設計者の最良の推測によって部分的に特定されるが、さらに、正確に結果を予測する設計者の能力の履歴によって改変される。統計学的な独立性を仮定すると、これらのエラー変動は、合計される。
【０１４４】
ｃ）対照データ−設計経験のセットからの、対照され、分類され、そして、パラメータ化されたデータ。このデータに直接関連付けられる測定エラーの可能性があるが、これは、小さい可能性が高い。主要なエラーは、測定された結果とデータパラメータの変動によって予測された結果との間の相違として規定される。
【０１４５】
プロジェクトデータは、現行の見積もりを拡張する機構をさらなる設計に提供しないのでＦＯＥデータの形態ではないことに留意のこと。さらに、終了時ではなくプロジェクトの開始時にプロジェクトデータが集められるため、目録に載せられた設計経験に対して検証可能ではない。これは、証明されないことを暗に意味する。設計の最終測定から集められた任意のデータは、ＦＯＥデータベースに入力され得、プロジェクトデータ対最終測定の正確性は、会社に対する設計者エラー変動を洗練するために用いられ得る。
【０１４６】
予測されたデータは、ＦＯＥシードデータとして参照される。予測されたデータは、同様の設計上のＦＯＥ見積もりにすぐに適用され得る。
【０１４７】
受信されるデータのタイプの共通の分類は、ＦＯＥデータの上記ソースの両方に適用されなければならない。このような共通の分類は、受信されたデータの迅速な識別および目録化を可能にする。当初の分類仕様は、ＦＯＥに対する計画ステージとして関連され、データの入力／収集は、構築ステージである。ＦＯＥデータベースにおける情報量が大きくなるにしたがって、洗練プロセスは、統計的に観察される範囲内にエラー許容度を低減するように適用される。これらステージの全３つに並行して、ＦＯＥ証明プロセスが行われる。
【０１４８】
上記に列挙されるパラメータは、既存の一般的なＦＯＥデータからデバイスプロジェクト特定のＦＯＥ見積もりに外挿するために用いられる。外挿された見積もりとＦＯＥデータとの間のこのような関係は、好適には、各設計分類に対して規定される。各パラメータＦＯＥ関係は、設計者の個人経験（上記の予測されたデータ参照）によって規定され得るか、または、十分な情報が利用可能であればＦＯＥデータの曲線適合を通じて経験的に特定され得る。パラメータは、パイプライン深さ、平行の程度、ビット幅、およびクロッキング速度のような技術的な変数を含み得る。
【０１４９】
ＦＯＥは、設計ブロックだけではなく、ブロック間の相互接続に適用されることに留意されるべきである。このような場合、ＦＯＥは、ある分類のブロックと別のブロックとの間のルーティングの費用として特定され得る。ブロックへの適用のように、相互接続に対するＦＯＥ見積もりはまた、パラメータ化され得る
（最大の正確さを有する見積もり）
ＦＯＥのキーとなる局面は、提供されたデータに与えられる最大正確さの見積もりの生成である。これは、２倍のプロセスである。
【０１５０】
ａ）洗練−上記に言及されたように、洗練は、統計学的に観察される範囲内に見積もりエラーを低減するプロセスである。すなわち、特定のカテゴリーにおけるＦＯＥデータの量が小さい場合、データに対するエラー許容度は大きい。これは、固有のエラーのためではなく、むしろ、他の特定の設計へのパラメータ化されたデータの未知の（またはテストされていない）適用性のためである。検査される設計の数が増えると、統計学的なデータの広がりは、パラメータ化された予測に対して直接測定され得る。大多数の場合が設計の特定の分類のための目録に載せられる場合、パラメータ化方法の正確性は、より良好に確立される。大きく修正されたエラーの識別（ランダムなデータの広がりに対立するものとして）は、パラメータ関係の再考をうながし得る。
【０１５１】
ｂ）分類破綻−設計の異なる分類は、互いに密接に関連され得る。例えば、Ｂｕｔｔｒｅｆｌｙ  ＦＦＴインプリメンテーションは、設計の一つの分類であり得るが、全てのＦＦＴブロックは、この設計に近接するとみなされ得る。特定の興味の分類に関連付けられるデータ数があまりに小さすぎて、統計学的に重要でない場合、近接ＦＯＥデータは、見積もりエラー全体を低減するように一緒に破綻され得る。分類を一緒に破綻させることは、設計タイプにおけるわずかな相違に起因して、それ自体で、エラーを誘導するが、考えられる設計数の点での統計学的な改善は、この相違のエラーをのみこみ得る。好適であるのは、図２８に示されるように曲線を演算し、そのピックから最良のエラーを構成することである。
【０１５２】
したがって、ＦＯＥのためのプロセス／使用モデルは、以下の通りである。
【０１５３】
Ｉ．評価されるブロックに適用可能なブロック分類を選択する
ＩＩ．その分類のために十分なデータが存在するか？（すなわち、予想されるエラーは、十分？）
はい−最良ＦＯＥ見積もりに戻り終了する  いいえ−進む
ＩＩＩ．見積もりエラー改良を終わるまで近接のカテゴリーを破綻させる
ＩＶ．予想されたエラーは、ＦＯＥ見積もりのために十分か？
はい−最良ＦＯＥ見積もりに戻り終了する  いいえ−進む。
【０１５４】
Ｖ．設計者に設計に対する彼の最良の推測を生成することを頼む。（これは、ＢＢＤの見積もり段階へのディップであり得る。）
（ＦＯＥ証明）
ＦＯＥを証明することは、集められたＦＯＥ情報が信頼できることが示されるプロセスである。この証明プロセスは、構築および洗練ステージ中の見積もりのエラーを確立する。
【０１５５】
証明の２つの局面がある。
【０１５６】
ａ）完全性の証明−全てのＦＥＡ測定基準は、提供されるパラメータ化スキームを通じて測定可能でなければならない。
【０１５７】
ｂ）正確性の証明−設計者のための経験測定を含み、収集されたデータの正確性を保証するプロセスの規定。
【０１５８】
（タイミングおよびフロアプラニング）
図８は、チッププラニングステージの一部としてのタイミングおよびフロアプラニングに対する例示のプロセスフロー３００を示す。図８に示されるように、タイミング環境をつくる第一ステージ３０１が実行される。このステップ３０１は、例えば、回路ブロック設計全体の種々の個別の回路部分のためのタイミング供給を生成することを必要とし得る。事前の堅い回路部分に対して、タイミングは、概して、シミュレーションまたは他の技術を通じて決定され得る。しかしながら、プログラム可能なファブリックに対しては、タイミングは、大きく、ファブリックのプログラムされた機能性に依存し得る。この理由のため、論理システムまたはいくつかの他のタイプの見積もり技術を通じて、タイミング供給での使用のためにタイミングモデルおよびタイミング見積もり（例えば、高および低境界）が到達し得るように十分に規定された各プログラム可能なファブリックのためのソフトウェアアルゴリズムが好適である。したがって、プログラム可能でないファブリックとは異なり、プログラム可能なファブリックは、概して、単一の固定されたタイミング見積もりとは反対に高および低タイミング境界を有する。
【０１５９】
タイミング供給は、好適には、プログラム可能なファブリックをハードブロックとして扱うが、タイミング検証がタイミングが最適でないまたは作動可能でないことを示す場合には、実質的に変更され得るものとして扱う。このため、タイミング環境が生成され（ステップ３０１）、トップレベルのネットリストが生成された（ステップ３０５）後、ステップ３０８によって示されるように、タイミング検証（典型的には、静的）が実行される。タイミング検証が受入可能な結果を生じない場合、タイミングを変更するために利用され得る種々のステップがある。これらが含むのは、グルーロジックを分配するステップ（ステップ３１０）、クロック計画を改変するステップ（ステップ３１１）、仕様またはネットリスト（特に、ソフトまたはファーム回路に対して）を改変するステップ（ステップ３１２）、およびプログラム可能なファブリックのタイミングを改変するステップ（ステップ３１３）である。プログラム可能なファブリックのタイミングは、例えば、プログラミング機能性を低減すること、または、プログラムコードを最適化することによって変更され得る。一旦、プログラム可能なファブリックが受け取られると、新しい合成がタイミング検証に有用なタイミングモデルを取得するように行われ、新しい高および低タイミング境界が確立される。次いで、タイミング検証ステップ３０８は、改訂されたプログラム可能なファブリックに対して改変されたタイミングで繰り返される。
【０１６０】
一旦、タイミング検証が回路ブロック設計に対して課されたタイミング要求に首尾よく合うと、ステップ３２０によって示されるように、タイミングスラックがブロック制約に変換され、その結果、新しいブロック制約を生じる。静的なタイミング検証は、含まれる新しいブロック制約を有する回路モデルを用いて再実行され得る。また、トップレベルのフロアプラニングが、ステップ３２２に示されるように、実行され得る。フロアプラニングステップ３２２は、フロアプランにおけるトップレベル配置の前に種々の回路部分のフットプリントの調節を必要とし得る。事前に堅くされた回路部分は、概して、形状または大きさにおいて調整不可であるが、ソフトまたはファーム回路部分は、形状の点で調整可能であり得る。プログラム可能なファブリックはまた、形状において調整可能であり得るが、プログラム可能なファブリックの典型であるタイルベースのレイアウト（ＲＯＭ等）に起因して、所定の別個のアスペクト比以外の任意のアスペクト比を引き受けることが必ずしも可能でなくてもよい。図８４は、形状において調整可能なプログラム可能な回路ブロックの可能なフットプリントの簡単な例示を示す図であり、種々の法定のアスペクト比を示している。
【０１６１】
一旦、フロアプラニングステップ３２２が完了すると、分配されたバック注釈付けステップ３２３が実行され得、これに続いて、望みの場合には、さらなるタイミング検証（ステップ３０８）および追加の洗練が行われる。
【０１６２】
（グルーロジック）
本明細書に開示された種々の実施形態においてグルーロジックの分配および低減方法論が提供される。３つの交互のグルーロジック分配機構の組み合わせが行われる。第一に、事前設計されたブロックに組み込まれないグルーロジックは、既存のブロックへの分配のために複数のコピーに複製され得る。第二に、トップレベルにあるブロックに類似点がないロジックが小ブロックとして残され得、事実上のゲート独占化、書き込み密集、およびフロアプラニングインパクトを最小にするように最適に配置される。第三に、ブロックの数がブロック箇所およびルート制限を超える場合に、グルーロジックは、ブロックカウントが受入可能なレベルに低減されるまでグルークラスターブロックに密集され得る。
【０１６３】
図２９を参照すると、回路設計図が示されており、ここでは、グルーロジック２９１０が相互接続ブロック間に不利益に常駐し、これにより、重大なシリコン領域（ｒｅａｌ  ｅｓｔａｔｅ）の使用を非効率的にし、重大な書き込み密集を生成する。
【０１６４】
図３０は、トップレベルブロックへの分配のためのグルーロジックの複数のコピーの生成を概念的に示す。素子３０１０が複数のロードを駆動する出力ネットを有する場合、素子は、複数の素子３０１２に分離され、それぞれは、出力上に単一のロードのみを有する。次に、全てのブロック出力が到達するまで、複製された素子を駆動する各入力「コーン」（図示せず）が同様にコピーされる。同様に、大きな入力ゲートは、ツリーのトップで元の機能の２入力ゲートを有するノンインバーティング２入力ゲートのツリーに低減される。このようにして、実質的により多くのロジックが以前にはるかに小さいグルーロジック機能に供される。しかしながら、より大きいブロック間のエリアからグルーロジックを取り除くことによって、より大きいブロックは、より効率的に配置され得、その結果、正味の効率が増加する。
【０１６５】
次いで、分配のために効率的に供することができない任意のグルーロジック素子は、最も近い親和性を有する大きいブロックに好適にマージされる。グルーロジックマージャーは、基準上の数に基づく態様で実行され、大抵の重大な基準は、マージャがトップレベルのピン出力の数を低減するかどうかである。このため、得られたロジックの大部分がから構成されて以来、複数のコピーが生成された場合、一つのピンがブロックに接続されるピンにこのようなゲートをマージすることは、ピンカウントを２倍低減することである。２以上のブロックがマージャに対して同等の候補である場合、最低ピン密度を有するブロックが好適に選択される。最後に、最低の優先度は、好適には、タイミング考慮に進む。
【０１６６】
次に、図３１を参照すると、マージされ得ないゲートおよび小ブロック３１１０は、クラスタ３１１２に密集される。マージされ得ないゲートは、それらの入力および出力ネットの両方上に複数のロードを有する可能性が最も高い。同様の機能を有する入力にゲートを再結合することによって、ゲートカウントは、低減され得る。
【０１６７】
さらに、予め設計された回路ブロックを、規格化されたインターフェースを有する回路に変換する方法が開示される。
【０１６８】
図１のブロック設計段にて実行されるタスクは、（１）選択された回路ブロックのために、任意のミシングアブストラクト（ｍｉｓｓｉｎｇ  ａｂｓｔｒａｃｔ）を作成し、（２）回路ブロックを、公知の、それら回路ブロックのそれぞれの規格化されたインターフェースに組み込み、（３）カラー付けされた（ｃｏｌｌａｒｅｄ）回路ブロックのアブストラクトの完全なセット（ｃｏｍｐｌｅｔｅ  ｓｅｔ）を作成することを含む。
【０１６９】
図３２を参照すると、回路ブロックをカラーに組み込むカラー付けプロセスが示される。
【０１７０】
好適なＢＢＤ方法論において、選択された回路ブロックは、チップレベルでの第１入力コンポーネントである。カラー付けプロセスは、カラーを、回路ブロックのそれぞれの周りに配置し、これにより、回路ブロックの境界の周りに規格インターフェースを作成する。カラー付けされたブロックをチップレベルに首尾よく一体化するように、アブストラクトの完全なセットは、カラー付けされたブロックのために作成されなければならない。アブストラクトの完全なセットをカラー付けされたブロックのために作成する前に、選択されたブロックの任意のミシングアブストラクトが形成される（アブストラクトは、ブロックのモデルまたはビュー（ｖｉｅｗ）、または、チップレベルアセンブリあるいはプランニングツールによって必要とされたカラー付けされたブロック設計である）。アブストラクトの例は、以下の、
（１）スタティックタイミング抽象化（Ｓｔａｔｉｃ  Ｔｉｍｉｎｇ  Ａｂｓｔｒａｃｔｉｏｎ）−ＴＬＦ
（２）レイアウトブロッケージファイル（Ｌａｙｏｕｔ  Ｂｌｏｃｋａｇｅ  Ｆｉｌｅ）−ＬＥＦ
（３）検証用モデル−ボルティッド−バス−ブロックｋモデル（Ｂｏｌｔｅｄ  Ｂｕｓ  Ｂｌｏｃｋ  ｍｏｄｅｌ）
（４）システムに対するブロックレイアウト制限
を含む。
【０１７１】
図３３を参照すると、回路ブロックのアブストラクトの完全なセットの作成が例示され、図３４は、図３２および３３に例示される特徴の組み合わせを例示する。
【０１７２】
カラー付けプロセスが、ここで、説明される。規格インターフェースが、設計中に用いられるように、ブロックのそれぞれのタイプに対して定義されていることが仮定される。
【０１７３】
第１ステップでは、カラー付けプロセスは、ブロックそれぞれが完成されたブロック抽象化を有するかどうかを調べる。ブロックのいずれかが完成されたブロック抽象化を有しない場合、プロセスは、そのブロックのために、完全なブロック抽象化を形成する。
【０１７４】
次に、プロセスは、ブロックそれぞれに対するブロックタイプを識別する。詳細には、ブロックは、メモリタイプ、プロセッサタイプ、パワータイプまたはアナログ／ミックスド信号タイプであり得る。しかし、異なるソースからの回路ブロックタイプは、異なるインターフェースを有し得る。この異なるインターフェースは、他の回路ブロックと接続するための、異なる設計を必要とする。例えば、異なるベンダーによって設計されたプロセッサは、異なるインターフェースおよびバス構造を有し得る。
【０１７５】
次に、プロセスは、識別されたブロックを、その各々のインターフェース規格に関連付ける。
【０１７６】
その後、プロセスは、第１カラー部分を作成する。第１カラー部分は、識別されたブロックの特定インターフェースに接続可能なコンポーネントを含む。
【０１７７】
次のステップでは、プロセスは、識別された回路ブロックと関連付けられた規格インターフェースに応じて、第２カラー部分を作成する。
【０１７８】
次いで、プロセスは、第３カラー部分を作成する。第３カラー部分は、特定インターフェースを、規格インターフェースに接続可能なフォーマットに変換し、第１カラー部分を第２カラー部分に接続するためのコンポーネントを含む。
【０１７９】
ブロックカラーは、多層から構成され得る。今日、二つのカラー層（ブロック規格カラーおよびシステム特定カラー）がＢＢＤおよびＳＯＣにそれぞれ定義されてきた。図３５を参照すると、二つの層を含むカラーが示されており、一方のカラーは特別なブロックに対する規格であり、他方のカラーは、ブロックが配備されるべき特別なシステムに特有である。ブロック規格カラーは、上記のインターフェースコンポーネントを含む。このインターフェースコンポーネントは、特定のシステムまたは統合されている特定のコンテキストの知識なしで定義され得る。例えば、ＢＢＤのコンテキストにおいて、特別な設計グループは、ＪＴＡＧ規格テストインターフェースが設計上必要とされることを決定し得る。したがって、設計されているシステムのいずれかにて用いられるべき全てのブロックについて、ＪＴＡＧテストインターフェースが、規格であり、したがって、ブロック規格カラーに属する。システム特定カラー（または適応カラー）は、インターフェースコンポーネントを含む。インターフェースコンポーネントは、ブロックに属するが、システムまたはコンテキスト特有である。例えば、データ線毎の規格セットは、パリティビットを必要とし得ないが、設計されている特別のシステムについて、パリティビットは、全てのデータ線上で必要とされる。パリティビットを生成するためのロジックは、チッププランニング中にブロックに関連付けられ、システム特定カラー内に常駐する。
【０１８０】
ＢＢＤの二つのカラー層間の別の差異は、ブロック規格カラーがフロントエンド引受（ａｃｃｅｐｔａｎｃｅ）およびチッププランニング前に装着される（チッププランニングは、最初のカラーが、必要とされるチッププランニング機能をより良く実行するための浸漬プロセス（ｄｉｐｐｉｎｇ  ｐｒｏｃｅｓｓ）の一部として、設計されることを必要とし得る）が、しかし、システム特定カラーがチッププランニング後に追加され得ることである。
【０１８１】
二つのカラータイプ間のより僅かな差異は、ブロック規格カラーの規格セットが、ＳＯＣの規格セットより、範囲において、かなり狭くなり得ることである。例えば、あるパワーインターフェースは、特別の会社に対してのみ、ＢＢＤの規格になり得、他の会社は、ブロックについて、その規格パワーインターフェースに適合する必要がない。結果として、会社の外部からのブロックはシステム特定カラーを必要とする。システム特定カラーは、規格パワーインターフェースを会社のインターフェースに変換する。これはＳＯＣとは対照的であり、産業ワイドパワーインターフェース（ｉｎｄｕｓｔｒｙ−ｗｉｄｅ  ｐｏｗｅｒ  ｉｎｔｅｒｆａｃｅ）規格は、ブロック規格カラーに存在し、常駐する。ＳＯＣの最終的な目的は、産業ワイド規格である規格カラーを作成することである。このようなカラーを有するブロックはソケット化されたブロック（ｓｏｃｋｅｔｉｚｅｄ  ｂｌｏｃｋ）と呼ばれ得る。将来、カラーの局面が産業ワイドである場合、システム特定カラーの追加した層の必要性がなく、したがって、ブロックを、プラグおよびプレイの理想により近付ける。
【０１８２】
システム特定カラーの別の重要さは、それがチッププランニング後に設計されるように意図されるが、チッププランニングにてシステム特定カラーを作製することにより、チップ統合プロセスを高速化できることであり、システム特定カラーが目的とされなければならない範囲を取り込むパラメータである。これは、統合プロセスを高速化する。チッププランニング後、このパラメータのみが変動される必要があり、システム特定カラーがスクラッチから再設計される必要がないからである。
【０１８３】
カラーおよびブロックは、柔軟（ｓｏｆｔ）、安定（ｆｉｒｍ）および頑丈（ｈａｒｄ）の様々な組み合わせであり得る。ブロックの頑丈さに関しては利益および不利益があるように、カラーの柔軟さ、安定さおよび頑丈さの組み合わせに関する利益および不利益がある。例えば、ブロック自体が柔軟である場合、それは、ブロック規格カラーを柔軟な状態にするためには適切であり得る。この結果、システム特定カラーが追加される場合、全ブロックが、レイアウトの最終変換のために、合成され、配置され、丁度、経路設定され得る。ブロックが頑丈である場合、それは、非常に小さい規格機能上の変化のみについての物理的なインターフェース問題を優位に処理するために頑丈なブロック規格カラーを用いることに適し得る。システム特有の問題を処理する柔軟なシステム特定カラーは、たいてい、機能上の変化を含むからである。
【０１８４】
カラーは、ブロック特定インターフェースを、以下の方法で、規格インターフェースに換える。
（１）ブロック特有の物理的構成を、ピン層、ピン位置およびピン分離を含む規格物理的構成に換える。
（２）ブロック特有の電源を、パワーローディング（ｐｏｗｅｒ  ｌｏａｄｉｎｇ）およびパワー物理的位置を含む規格電源に換える。
（３）ブロック特有のテストプロセスを、テストアクセスポート（ＴＡＰ）コントローラおよびテストプロトコルを含む規格テストプロセスに換える。
（４）ブロック特有のタイミングを、起動、待ち時間、フリップ−フロップまたはラッチを含む規格タイミングに換える。
（５）ブロック特有のクロックポートを、クロックポートそれぞれのローディングを含む規格クロックポートに換える。
（６）ブロック特有のデータ／コントロール信号を、規格化するための信号の正／負のアサート（ａｓｓｅｒｔｉｏｎ）を含む規格データ／コントロール信号に換える。
（７）ブロック特有のバスインターフェースを、全ての周期、大きなエンディアン（ｅｎｄｉａｎ）または小さいエンディアン上にて有効な入力を期待するブロック用のレジスタを追加し、ビット幅を変換することにより、規格バスインターフェースに換える。
【０１８５】
さらに、カラーは、カラー付けされたブロックに余分の機能を実行させるコンポーネント（上記で説明されたグルーロジック（ｇｌｕｅ  ｌｏｇｉｃ））を含み得る。グルーは、三つのレベルにて存在する。（１）カラーに配置されたグルー、（２）チップレベルで組み合わされたグルーおよび（３）チップレベルで１以上の小型ブロックに配置されたグルー。詳細には、グルーロジックは、単純な機能トランスレータ（例えば、ビット線のそれぞれに沿ったＮＡＮＤゲート）からより複雑な機能（例えば、レジスタ、アキュムレータ等）までのいずれをも含み得る。グルーロジックは任意のサイズであり得るが、グルーサイズがブロックに対して大きくなる場合、フロントエンドアセンブリおよびチップのプランニング中に為された評価は、グルーサイズが考慮されないために不正確になり得る。制限は、ブロックに対するグルーの相対サイズについて付けられる必要がある。
【０１８６】
仮定のセットは、カラー付けプロセスに、以下のように用いられる。
（１）グルーロジックを追加するかどうかの決定がチッププランニング中に行われる。
（２）グルーロジックの三つのタイプ（カラーに付けられたグルー、チップレベルの組み合わせグルー、チップレベルの小型ブロックに置かれたグルー）の中で、カラー付けプロセスは、好適には、カラーに置かれたグルーをアドレス指定する。
（３）アスペクト比問題は、（ブロックカラー付けの際にではなく）合成中に処理される。
（４）ＢＢＤについて、カラー付けされたブロックの出力がレイアウトされる。
【０１８７】
プログラム可能なファブリックについて、上述されたように、カラー付けプロセスは、チッププランニングプロセス中に、プログラミングポートモジュールの命令に基づいて、プログラミングポートラッパ（ｐｒｏｇｒａｍｍｉｎｇ  ｐｏｒｔ  ｗｒａｐｐｅｒ）を、プログラム可能なファブリックに追加する必要があり得る。また、カラー付けプロセスは、必要な場合（例えば、ＦＰＧＡがチップの残りと異なる電位にて作用しえる場合）には電位を変位するか、または三つの状態にする機能を実行するためには、入力／出力バッファの追加を必要とし得る。好適には、このような入力／出力バッファリングは、プログラム可能なファブリック回路と任意の境界走査回路との間に配置され、たとえあったにしても、カラーの一部として一般に提供される。
【０１８８】
図３６を参照すると、カラー６０２とブロック６０４との間のロジックビューが示されており、上述されたカラーのいくつかの例示的な機能を示す。
【０１８９】
図３６に示されるように、カラー６０２は、三つの異なる機能を実行する三つの部分を含む。第１部分は、ブロック６０４の境界周囲の特定インターフェースに接続可能であるコンポーネントを含む。第２部分は、規格に応じて入出力コンポーネントを含み、第３部分は、ブロック６０４からの出力を規格に変換するコンポーネントを含む。
【０１９０】
詳細には、カラー６０２において、バスインターフェース６０６は、二つの一方向バス６０８および６１０を双方向バス６１２に組み合わせる。テストアクセスポート６１４は、ブロック６０４から情報を収集し、ブロック６０４についてのテストを実行するように、入力６１６に接続される。ゲート６１８は、ゲート６１９によって受け取られると、ブロック６０４に適切なフォーマットに、入来信号を反転し、ゲート６２０〜６２４は、クロックバッファリングを実行する。
【０１９１】
図３７を参照すると、カラー７０２とブロック７０４との間の物理的ビューが示されており、上述されたカラーのいくつかの例示的な機能を示す。図３７において、カラー７０２およびブロック７０４両方が複数の金属層を含む。パワー規格は、金属層３（Ｍ３）上にＶｄｄ電圧を配備し、金属層４（Ｍ４）上にＧＮＤを配備するために存在する。ブロック７０４がパワー規格について適格でない場合、カラー７０２は、適格となるようにパワーを変換する。領域７０６は、ピン間隔／層規格を設定する。ブロック７０４がピン間隔／層規格を適格としない場合、カラー７０２は、それを、ピン間隔／層規格に適格とするように、変換する。カラー７０２は、頑丈な状態でグルー７０８を含む。
【０１９２】
図３９を参照すると、システム設計８００は、上述されたカラー付けプロセスを用いることなく、示される。図３８に示されるように、システム設計８００は、四つの回路ブロックＡ、Ｂ、ＣおよびＤから構成される。ブロックに接続されたそれぞれの矢印線は、そのブロックのインターフェースを設計するための制限を表示する。したがって、システムがｎ個の回路ブロック（この例ではｎ＝４）から構成される場合、任意の特別のブロックのためのインターフェースは、制限のｎ−１個のセットまで満足させる必要がある。それゆえ、全てのブロックについて満足である必要がある制限の総数は、Ｏ（ｎ２）である。
【０１９３】
図４０を参照すると、システム設計９００が、上述されたカラー付けプロセスを用いて示される。システム設計９００は、四つの回路ブロックＡ、Ｂ、ＣおよびＤから構成される。ブロックに接続されるそれぞれの矢印線は、そのブロックのインターフェースを設計するための制限を表示する。前述のカラー付けプロセスを用いて、それぞれのブロックは、カラー付けインターフェースによって定義される制限の一組を満たすことのみを必要とする。したがって、システムがｎ個の回路ブロック（この例ではｎ＝４）から構成される場合、全てのブロックについて満足である必要とする制限の総数はＯ（ｎ）である。
【０１９４】
図３８を参照すると、カラー付けおよび本明細書中で説明された他の創作的なＢＢＤプロセスのステップを実行するコンピュータシステム１０００が示される。コンピュータシステム１０００は、システムバス１００１、処理装置１００２、メモリデバイス１００４、ディスクドライブインターフェース１００６、ハードディスク１００８、ディスプレイインターフェース１０１０、ディスプレイモニタ１０１２、シリアルバスインターフェース１０１４、マウス１０１６およびキーボード１０１８を含む。
【０１９５】
ハードディスク１００８は、ディスクドライブインターフェース１００６に接続される。モニタディスプレイ１０１２は、ディスプレイインターフェース１０１０に結合され、マウス１０１６およびキーボード１０１８は、シリアルバスインターフェース１０１４に結合される。処理装置１００２、メモリデバイス１００４、ディスクドライブインターフェース１００６およびディスプレイインターフェース１０１０は、システムバス１００１に結合される。
【０１９６】
メモリデバイス１００４は、データおよびプログラムを保存する。ハードディスク１００８はまた、ディスクドライブインターフェース１００６と共に動作して、データおよびプログラムを保存する。しかし、メモリデバイス１００４は、ハードディスク１００８より高速なアクセス速度を有し、ハードディスク１００８は、通常、メモリデバイス１００４より高いキャパシティを有する。
【０１９７】
ディスプレイモニタ１０１２は、ディスプレイインターフェース１０１０と共に動作して、実行されるプログラムとユーザとの間に視覚インターフェースを提供し、プログラムによって生成された出力を表示する。マウス１０１６およびキーボード１０１８は、シリアルバスインターフェース１０１４と共に動作して、入力を、コンピュータシステム１０００に提供する。
【０１９８】
処理装置１００２は、一つより多いプロセッサを含み得、メモリデバイス１００４およびハードディスク１００８に保存されたプログラムを実行することにより、コンピュータシステム１０００の動作を制御する。処理装置はまた、メモリデバイス１００４とハードディスク１００８との間のデータおよびプログラムの伝送を制御する。
【０１９９】
本明細書中に説明された様々な実施形態において、本発明が属する当業者によって理解されるように、本明細書中で説明されたステップを実行するプログラムは、メモリデバイス１００４またはハードディスク１００８に保存され得、処理装置１００２によって実行され得る。
【０２００】
（バス識別およびプランニング）
方法論は、フロントエンド受諾中に定義されるように、エンドユーザまたは設計チームによって望まれるシステムの全設計の性能要件を満たすための方法論が、提供される。性能が第１条件であり、第２条件は、バスタイプ選択中のゲートカウントを低減させることである。バスサイズは、利用可能なバスタイプ間で変動し得る。大きく、単純なバスが、より小さく、より複雑なバスよりも、よりロジックを消費するからである。
【０２０１】
まず、図４１を参照すると、一連のステップが例示されている。この一連のステップはバス識別およびプランニングに一般に関連する。ステップ４１１０では、顧客の最初の仕様のフロントエンド受諾が完了される。このステップは、これまでに詳細に、説明されてきた。ステップ４１１２にて、予め定義されたバス要件が、以下に説明されるように、解析される。ステップ４１１４にて、バスクラスター化（ｂｕｓ  ｃｌｕｓｔｅｒｉｎｇ）が計画され、その上、バス分類基準ライブラリ（ｂｕｓ  ｔａｘｏｎｏｍｙ  ｒｅｆｅｒｅｎｃｅ  ｌｉｂｒａｒｙ）にステップ４１１６での基準を作って、変数が解析される。上記変数は、ブロックそれぞれの、待ち時間、帯域幅、方向および既存のインターフェースを含む。次に、ステップ４１１８にて、新しいバス仕様が開発され、ステップ４１２０にて、新しい仕様が検証される。新しい仕様は、適格系統（ｃｏｍｐｌｉａｎｃｅ  ｓｕｉｔｅ）およびバスモデル検証サブステップの生成を含む。ステップ４１１８および４１２０は、ブロックプレステージング（ｂｌｏｃｋ  ｐｒｅｓｔａｇｉｎｇ）ステップ４１２２に関して実行され、アービタ−（ａｒｂｉｔｅｒ）およびブリッジをカバーする新しいブロック仕様が作成され、カラーを含むブロック仕様が改変され、グルー仕様が定義され、テストベンチが作製される。
【０２０２】
バスプランニングは、フロントエンド仕様を上位レベルのバス仕様に翻訳することを含み、ここで、より詳細に説明される。利用可能な技術分野にて、システム設計者は、高レベル機能モデル、または、設計されるシステムの使用で開始する。設計者は、システム専門の意見および類似するシステムの知識を用いて、設計のために、バス構造の高レベル模式図を構築する。設計者は、通常、バスそれぞれ上のトラフィックを大雑把に知っており、何個のバスが必要とされ、どんな複雑さのバスが必要とされるかを推定し得る。バスは、インターフェースロジックおよび設計労力を最小にしながら、必要とされるシステム性能を満たすように設計される。次いで、設計者は、このアーキテクチャを用い、これにより、設計物が仕様上で定義されたように動作するかを検証するためのバス機能モデルを作成する。この伝統的なプロセスは、数量化することが困難であった。結果が、専門の意見および設計者の過去の経験により、変動するからである。本明細書中に定義されたタスクは、形式的な構造を、チップ設計のバス構造を定義するプロセスに適用する。しかし、上記のタスクは、最上の結果を達成するために、関連するバスおよびシステム開発技術分野の当該技術の平均レベルを少なくとも必要とする。
【０２０３】
（バスプロトコル）
バスは、設計上の回路ブロック間の好適な通信媒体を提供する。バスは、最も単純な形式において、ポイントツゥポイント接続の集団であり得る。ポイントツゥポイント接続は、ロジックをほとんど必要としないが、多くのワイヤを必要とする。単純なバスは、クロック周期毎に、ブロック間でデータを転送する。いくつかのブロックが情報転送のこのタイプを必要とするが、ほんの時折、システムのたいていのブロックが、他のブロックからの情報を必要とする。チップピンが大きなシステム設計において非常に高価となるので、バスは、通常、必要とされるチップピンの数を低減し、性能上、ほとんど損失無く、システムの多くの異なるブロック間の周期的な通信を可能にするために、用いられる。これをするためには、設計者は、ロジックを、ブロックのそれぞれに追加して、例えばどのブロックがバスワイヤを使用できるか、どのブロックに、データが送信されるか、いつ送信側がデータを送信するか、受信側がデータを受信するかどうかといったデータ転送スケジューリング問題を把握しなければならない。上記問題が、バス上の制御信号、および、ブロック間の通信を制御するプロシージャ（バスプロトコル）の確立により、処理される。
【０２０４】
バスプロトコルの二つの例は、周辺装置のバスおよびパケットネットワークである。単純な周辺装置のバスプロトコルでは、一つのデバイスがバスを制御する。全ての情報およびデータがこのデバイスを介して流れ、このデバイスは、一回に一つのケース、どのブロックがデータを送信するか、または受信するかを決定する。周辺装置のバス処理は、比較的僅かなロジックを要するが、この処理は、バスワイヤを効率良く用いず、大して柔軟ではない。パケットネットワークプロトコルは、比較的複雑である。どのブロックがデータを送信し、どのブロックがデータを受信するかについての全ての情報が、パケット内のデータにより、保存される。パケットプロトコルにより、任意のブロックが、任意の時間に、任意の他のブロックにデータを送信する。このプロトコルは、非常に柔軟で、バスワイヤを効率良く用いるが、それぞれのブロックは、いつパケットを送信するかを知り、それが受信するパケットを解読するための、多くのロジックを必要とする。他のバスプロトコルは、柔軟性、利用度および待ち時間（バス上で、一方のブロックから他方のブロックに情報を転送する場合の初期遅延）の異なるレベルを有する。異なるバスタイプおよびこれらの方法論の分類は図５９に提供される。
【０２０５】
好適なＢＢＤバス設計方法論は、定義されたバスタイプを用いる。設計者は、それらが認証ブロック（ａｕｔｈｏｒｅｄ  ｂｌｏｃｋ）の一部でない場合、スクラッチからバスが展開されることを期待されていない。また、設計者は、好適的には、既存の、十分に定義されたバスタイプにブロックを論理的に接続し、複雑なバスを作成しない。したがって、好適なＢＢＤ方法論は、ブロック間の信号接続として、バスを取り扱う。グルーロジック選択において本明細書中で説明されたように、グルーロジックは、バスが、バスの外側で通信することを可能にするので、バスのロジックは、好適には、設計上のブロック間で分散される（ｄｉｓｔｒｉｂｕｔｅｄ）。
【０２０６】
全ての論理的相互接続は、好適には、単純または複雑なバスのいずれかとして、取り扱われる。相互接続の単純な形式は、バス接続ルールによって定義されているが、複雑なバスについての特定のプロトコルは、好適には、定義されていない。好適なＢＢＤ方法論は、階層を有し、完全にブロック内に含まれ、ブロック外部でワイヤを有し、論理的階層の一つのレベル内に、完全に含まれ、ＶＳＩのオンチップバス（ＯＣＢ）属性仕様に適格であり、適格トランザクションベクトル（ｃｏｍｐｌｉａｎｃｅ  ｔｒａｎｓａｃｔｉｏｎ  ｖｅｃｔｏｒ）で検証されるバスを支援する。また、ＢＢＤの範囲外条件（ｔｈｅ  ｏｕｔ−ｏｆ−ｓｃｏｐｅ  ｃｏｎｄｉｔｉｏｎｓ）の多くは、好適には、ＳＯＣ方法論にて支援される。
【０２０７】
バスは、好適には、ブロック内に含まれるか、または、上位階層レベルの相互接続として定義される。上位レベルにて定義されるバスがそのレベルで作成されており、バスコンポーネントがブロック間およびブロック内で分散されることを可能にする。
【０２０８】
プログラム可能ファブリックに関して、バス要件の解析は、回路設計のプログラム可能な部分の動作中に生じる必要があるプログラミングのいずれのタイプの評価も伴い得る。シリアルプログラミング（ｓｅｒｉａｌ  ｐｒｏｇｒａｍｍｉｎｇ）が生じることになる場合、例えば、専用の、または、多重化されたＩ／Ｏピンは、機能をプログラム可能に支援するように割り当てられる必要があり得る。命令（またはブロック）のローディングがバスを越えて生じる場合、様々なバス要件が、回路ブロックの動作中に、上記のプログラミングを支援するために十分であることが必要である。
【０２０９】
ＢＢＤチップのバスを定義するためには、以下のステップが実行される。これらステップそれぞれは、以下で詳細に説明される。
【０２１０】
バス要件の抽象
クラスター化に基づくバスの定義
バス選択
バス設計の特定
バス分類の基準
バス選択の検証
（ブロック設計仮定）
ＢＢＤ方法論において、設計者がバス設計を特定すると、設計者は、ブロック構造に接続しなければならない。このタスクは、安定または頑丈なブロックが特定のバスインターフェースを含む場合、カラーについて上述されたように、このインターフェースが柔軟であることを仮定する。また、全てのタイプのブロックが、バスインターフェースロジックとブロックの現実の機能との間に単純化されたインターフェースを含むことが仮定される。これは、周辺装置のブロックには不合理な仮定である。多くの第３者的なブロック提供者は、ユーザがインターフェースロジックを追加できるように、彼ら自身の単純なインターフェースを有するからである。複数の設計に合わせられるブロックは、個別の内部機能およびバスインターフェースロジックを有する。内部インターフェースは、異なるバスを備えた上記のブロックを再使用することを可能にする。頑丈なブロックが、その内部機能から分離され得ない特定のバスインターフェースロジックを有する場合、より複雑なバスプロトコル翻訳がブロックに追加されなければならない。いずれの場合にも、結果的に生じるバスインターフェースロジックは、ブロック設計中に作成される柔軟なカラーの一部となる。
【０２１１】
（バス要件の抽象化）
フロントエンド受諾タスクから受け取られたデータは、バスネット、信号ネットおよびピンを、ブロックそれぞれの上に、含む。信号ネットの四つのカテゴリがある。１）ブロックピンであり、プロセッサ等の所定のブロックによって必要とされるＰＣＩまたはＡＭＢＡバス等のバスを含むネットである、予め定義されたバス信号。２）ブロックピンであり、バスでなければならないネットである、読み出しおよび書き込み信号等の、バス信号。３）ブロックピンであり、ワイヤまたはバスであり得るネットである、可能なバス信号。４）ワイヤネットであり、バスによって処理されない信号。
【０２１２】
設計者が信号タイプを決定する場合、フロントエンド受諾タスクから受け取られたデータは、信号ネットの上記四つのタイプに応じて、編集される。タイプ１および２のネットについて、バスを作成するために必要なデータは、顧客によって提供されなければならないか、または他の場合に利用可能でなければならない。必要とされたデータは、ＶＳＴのオンチップバス（ＯＣＢ）属性仕様ＯＣＢ１１．０にさらに定義され、参考として本明細書中で援用される。
【０２１３】
さらに、特定されるか、設計上で用いられ得るそれぞれのバスは、バスを作成するために十分な完全なユーザガイドと、バスに物理的要件を定義する実施ガイドと、バスをテストし、検証するシミュレーションツールの完全なセットと、技術的な属性のリストと、バスをテストし、検証するためのシミュレーションツールの完全なセットと、技術的属性のリストおよびバスがこのリストと比較する方法とを有しなければならない。また、ＶＳＴのオンチップバス属性仕様と適格であるバスを作成するために、ベンダーは、以下に説明された説明書およびモデルを提供しなければならない。
【０２１４】
（ユーザガイドおよびシミュレーションツール）
ユーザガイドおよびシミュレーションツールは、バスコンポーネントを構築し、テストするために、バス設計上で用いられる。シミュレーションツールのセットは、以下の要素バスマスター、バススレーブ、バス支援機能（アービタ、アドレスデコーダ）、規格バスブリッジについての、挙動上のＶｅｒｉｌｏｇおよび／またはＶＨＤＬに書き込まれたモデルを含む。これらは、バス検証に関連するセクションで本明細書中に説明されたように、バスを検証するために用いられる。
【０２１５】
（実施ガイド）
実施ガイドは、ブロック設計、チップアセンブリ、および、バスの属性を説明するチップ設計プランニング上のタスクにて、用いられる。以下の情報は、ブロック仕様（必要とされる特別のセル、セルの物理的な性質、バス多重化または操作オプション、メモリマップ、パワー分散およびタイミングガイドライン）の一部としてブロック設計に通過される。タイミングおよび最大のローディングガイドラインはまた、チップ設計プランニング中の、以下のステップに用いられる。タイミングガイドライン、最大ローディング、バスレイアウトまたはワイヤリング上の限定は、バス実施の使用のためにチップアセンブリタスクに通過される。
【０２１６】
（技術的属性リスト）
技術的属性は、バス分類基準ライブラリ内のバス属性として維持され得る形式に、翻訳されなければならない。したがって、バス分類基準およびバスタイプテーブルは、バスタイプを選ぶ設計者によって用いられる。予め定義されたバス信号について、設計者は、必要とされた接続が最大ローディングおよびタイミングガイドラインを満たすことができ、バスレイアウトおよびワイヤリング限定がチップアセンブリ中に満たされ得ることを確実にするように調べる。そうでなければ、設計が、顧客によって改変されるように、フロントエンド受諾タスクに送り返される。
【０２１７】
（クラスター化に基づくバス定義）
クラスター化に基づいてバスを定義するためには、設計者は、フロントエンド受諾にて受け取られた相互接続の帯域幅および待ち時間を用いる。このステップは、クラスタおよびクラスタ内のブロックそれぞれについて、待ち時間、帯域幅、既存のバスインターフェースタイプおよびデータフローの方向を決定する。次いで、この情報は、バスを選択する次のステップに通過される。
【０２１８】
バス階層は、最高の帯域幅および最低の待ち時間バス相互接続をクラスター化することによって定義される。ポイントツゥポイントネットである可能なバス信号は、今回および次のバス解析および設計から除去され得る。上記の信号が経路設定のチップアセンブリタスクに直接に提供されるからである。
【０２１９】
（通信マネージャ挙動モデルの作成）
検証されるチップの挙動モデルは、挙動モデルおよびブロック間の相互接続の抽象モデルを含む。通常、この相互接続は、テストベンチおよびブロック間でデータを転送するソフトウェア機構である。理想的には、それは、全てのブロックが接続される、通信マネージャ（可能ならばスケジューラ）の形式である。それとは反対に、相互接続はまた、挙動モデルで、直接接続されたポイントツゥポイントインターフェースであり得る。
【０２２０】
通信マネージャまたは、以降で参照されるように、スケジューラは、通常、シミュレーションモジュールの上位レベルにある。このようなスケジューラに対する擬似コード（ｐｓｅｕｄｏｃｏｄｅ）は以下のようになる：
キューが空でない間、以下のことをする；
次のトランザクションをキューから得る；
ターゲットブロックをトランザクションから得る；
ターゲットブロック（トランザクション）を呼び出す；
終了；
この擬似コードの例では、それぞれのブロックは、以下のことをする：
ターゲットブロック（トランザクション）；
ブロックの機能をする；
新しいトランザクションをキューに付与する；
終了；
このコードレベルでは、タイミングまたはバスサイズのどちらも定義されていない。全ての通信は、トランザクション中に為されるか、または、任意のサイズの情報パケットを転送することにより、為される。トランザクションは、ブロック間の全ての通信がスケジューラを通過するように、可能なバス信号および非バスワイヤ（ｎｏｎ−ｂｕｓ  ｗｉｒｅ）を含む。
【０２２１】
あるいは、設計者は、非バス信号を送信し、読み出すように、非同期に、ブロック擬似コードを変更し得る。この場合、それぞれのブロックは以下のことをする：
ターゲットブロック（トランザクション）；
上位レベルから非バス信号値を得る；
ブロックの機能を為す；
新しいトランザクションをキューに追加する；
新しい非バス信号値を上位レベルに適用する；
終了；
平易さのために、これらの例が非バス信号を含まないことに留意すべきである。しかし、設計者は、非バス信号を含むことに至る、実施例への類似の調整を行い得る。
【０２２２】
パターンセットは、一つのブロックを別のブロックと通信させる、テストベンチのベクトルの集団である。テストベンチは、全チップの機能性を実行するために十分なパターンセットを含まなければならない。設計者は、ターゲット性能レベルを、概略レベルで、パターンセットのそれぞれに割り当てなければならない。例えば、一つのパターンセットのＭＰＥＧデコーダにはフレームデータがある場合、設計者は、ターゲットハードウェアが、上記セットのフレームを処理するには、どのくらいの時間が必要かを定義し得なければならない。設計者が出力レートが秒単位で約３０フレームでなければならないことを知る場合、処理レートはその数を越えなければならない。上記の性能ターゲットは、必要とされるバス帯域幅を定義するために、このプロセスの次のステージで用いられる。
【０２２３】
チップのために選択されるブロックは、いくつかの周期近似性能仕様（ｃｙｃｌｅ−ａｐｐｒｏｘｉｍａｔｅ  ｐｅｒｆｏｒｍａｎｃｅ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）を有しなければならない。挙動モデルがこれらの仕様をすでに有する場合、それらはこのステップでモデルに組み込まれる。
【０２２４】
図４２は、挙動モデルの相互接続セクションの内部構造を示す。第１に、テストベンチおよび要件が受け取られる。次に、予備スケジューラが作成される。相互接続マネージャ／スケジューラ４２１０は、設計上のブロック間で情報を転送し、それらの実行を予定に入れる。次いで、相互接続４２１０が変更され、変更された相互接続マネージャ４２１２は、統計ギャザリング（ｓｔａｔｉｓｔｉｃｓ  ｇａｔｈｅｒｉｎｇ）を含み、モデルとして追加される遅延マトリックスは、周期近似動作に調節される。最後に、テストベンチは、テストおよび設計の繰り返しのために、再び、利用される。これらの変更の詳細は、以下のセクションにて説明される。
【０２２５】
（待ち時間を説明するためのモデルの変更）
いくつかの設計は、特定の待ち時間必要条件を有していない。ハブおよびスイッチ等の他の設計は、データ待ち時間（それが送信者から受信者に行くデータの第１ユニット取り出す時間の長さ）に敏感である。たいていのネットワークデバイス、特に、非対称転送モード（ＡＴＭ）は、情報転送のための特定の待ち時間必要条件を有する。この待ち時間必要条件は、ネットワーク内のコンポーネントおよびバスに対する厳密な待ち時間必要条件に変えられる。一旦設計者が設計の待ち時間必要条件を知ると、設計者は、以下のように、相互接続モデルを調整する。第１に、マトリクスは、１）ブロック間で転送されるデータ量および２）実行されるトランザクション数を特定するそれぞれのセットのために作成される。第２に、マトリクスは、周期カウント近似を特定するそれぞれのパターンセットのために作成される。この第２のステップは、待ち時間必要条件なしの設計には、必要がない。
【０２２６】
（データ転送マトリクス）
データ転送マトリクスを作成するために、設計者は、あるブロックから別のブロックに転送されているデータ量を、通信マネージャモデルに追加する。次に、スプレッドシートツールを用いて、設計者は、このデータを、それぞれのパターンセットに対するテーブルに蓄積する。
【０２２７】
例えば、三つのブロック付きのチップおよびテストベンチのためのテーブルは、４×４フロム／トゥ（ｆｒｏｍ／ｔｏ）テーブルであって、バイト単位で、テーブル内のそれぞれのエントリについて、転送された全てのデータの合計を有する４×４フロム／トゥテーブルである。対角成分は全てゼロである。なお、より現実的なモデルは、チップに出入するバスを考慮しており、テストベンチは、おそらく、それぞれの軸上の一つより多いエントリを有する。
【０２２８】
データ転送マトリクスの例は、図４３のテーブルに例示される。このマトリクスの裏側の設計（ｄｅｓｉｇｎ  ｂｅｈｉｎｄ  ｔｈｉｓ  ｍａｔｒｉｘ）は、テストベンチ用の三つのブロックおよび三つのポート、外部メモリへのインターフェース、ＰＣＩインターフェースおよび並列Ｉ／Ｏインターフェースである。テーブル内に示されるように、ブロック１からブロック２に転送されるデータは、１０，０００バイトであり、ブロック２からブロック１に転送されるデータは、８，０００バイトである。
【０２２９】
したがって、データ転送マトリクスを作成する際の第１ステップは、テーブルを作成することである。このテーブルは、図４４に示されるように、全てのトランザクションカウントを伴い、例示的なＰａｔｔｅｒｎ  Ｓｅｔ  Ｘのためのトランザクションを示す。
【０２３０】
図４３および図４４に例示されたテーブルを作成するために、設計者は、以下のように、スケジューラ擬似コードを変更する。
【０２３１】
キューが空でない間、以下のことをする；
次のトランザクションをキューから得る；
送信者ブロックをトランザクションから得る；
ターゲットブロックをトランザクションから得る；
トランザクションバイトカウントを得る；
トランザクションマトリクス（送信者、ターゲット）
＝トランザクションマトリクス（送信者、ターゲット）＋１；
トランザクションマトリクス（送信者、ターゲット）
＝トランザクションマトリクス（送信者、ターゲット）
＋トランザクションバイトカウント；
ターゲットブロック（トランザクション）を呼び出す
終了；
非バスブロックトゥブロックワイヤがいくつかの遅延（通常、少なくとも１クロック周期）を有するので、これらは、好適には、バストランザクションに加えて、タイミングキューの個別のトランザクションとして追加される。
【０２３２】
（待ち時間マトリクス）
それぞれのブロックのクロック周期時間が、既に、フロントエンド受諾で定義されたので、次いで、設計者は、以下のように、行性能（ｒｏｗ  ｐｅｒｆｏｒｍａｎｃｅ）を周期カウントとして変え得る。
【０２３３】
１．それぞれの仕様にて定義される周期近似動作を反映するために、設計者は、それぞれのブロックの評価されたクロック周期を、その既存の挙動モデルに加える。このステップは、好適には、ブロックをブロック設計タスクに送信する前だが、検証後に、実行される。
【０２３４】
２．設計者は、ブロックバック（ｂｌｏｃｋ  ｂａｃｋ）をチップモデルに統合する。チップモデルは、次いで、相互接続にて定義されていない時間を伴う周期近似ブロックを有する。
【０２３５】
３．設計者は、図４３および４４に例示されたものに類似するテーブルを設定するために、スプレッドシートを用いる。設計者は、転送されるバイト数ではなく、転送タスク毎に、データが利用可能である時間からデータが次のブロックまたはテストベンチに到達する時間までに（待ち時間）に、必要な周期数を特定する。
【０２３６】
４．設計者は、新しいテーブルに例示された性能値を用いるために、相互接続モデルを変更する。
【０２３７】
図４５は、例示的な待ち時間マトリクスを示す。これらの変更の擬似コードは以下に示される。
【０２３８】
キューが空である間、以下のことをする；
次のトランザクションをキューから得る；
時間をキューから得る；
ターゲットブロックをトランザクションから得る；
ターゲットブロック（トランザクション、時間）を呼び出す；
終了；
それぞれのブロックが以下のことをする：
ターゲットブロック（トランザクション、時間）；
ブロックの関数を実行する；
トランザクション時間を、時間＋遅延＋待ち時間（このブロック、ターゲット）；
新しいトランザクションをキューに分類する；
終了
なお、図４４の「０」を読み出すエントリは、データが転送されず、待ち時間マトリクスに適用可能なものではないことを示す。
【０２３９】
５．設計者は、設計データフローの知識を用いる、評価された相互接続周期を伴うチップ待ち時間必要条件を含むために、テストベンチを変更する。
【０２４０】
６．設計者は、設計が周期必要条件を満たすか否かを理解するために、設計のシミュレーションを行う。
【０２４１】
７．設計者は、待ち時間マトリクスを変更し、チップの周期必要条件が満たされるまで、検証プロセスを繰り返す。
【０２４２】
バス転送のそれぞれのタイプに利用可能な最大周期カウントを伴うテーブルを作成するために、設計者は、仕様が満たされるまで、大周期カウントを開始し、減少するために大周期カウントを用いる。厳密な待ち時間必要条件がより多くのゲート集約バス相互接続スキームに変えられるからである。
【０２４３】
（クラスタ測度の決定）
次に、データの本来のクラスタリングを反映するために、設計者は、中心の対角成分に最も近い最大カウントを移動することにより、データ転送マトリクスを認識する。このプロセスを実行する多くの方法がある。好適な方法は、枢軸演算（ｐｉｖｏｔｉｎｇ）として、本明細書中にて参照される。枢軸演算の目的は、必要とされるピン数を最小とするために、最高の転送速度で、ブロックをクラスタリングすることである。設計者は、自動的に計算を行うスプレッドシートを設定し得る。
【０２４４】
クラスタリングがどれほど効率がよいかを測定するために、データ転送マトリクスのそれぞれのサイトは、精密に重み付けされ得る。この例は、図４６に示される、距離マトリクスを用いて、サイトを重み付けする。図４６のテーブルでは、全てのセルは、セルがある対角成分からの距離の二乗を含む。データ転送マトリクスを重み付けする他の測定が用いられるが、距離の二乗が好適である。距離の二乗は、高次の測度が限定する配置アルゴリズムにおいて、システム内の要素のいくつかの移動度を許容しながら、素早く収束するように、示されてきたからである。
【０２４５】
次に、設計者は、データ転送マトリクス内のそれぞれのセルを、距離マトリクス内のそれの対応するセルによって倍加にし、全てのセルに全ての値を一緒に加える。この結果がクラスタ測度である。図４３のテーブルのマトリクスのクラスタ測度は４２８，２００である。
【０２４６】
（ピボットブロック）
より低いクラスタ測度を得るように試みるために、設計者は、行を一つずつスワップし、全てのスワップの後にクラスタ測度を再計算することによってデータ転送マトリクスを旋回し、クラスタ測度が向上するか否かを見る。分類を実行することによって行をスワップできる。サイトは、以下の擬似コードに例示されるように、分類されるための、リスト内の要素である：
現在のマトリクスのクラスタ測度を得る；
現在のサイト＝マトリクスのサイト１〜ｎ−Ｉに対して、以下のことを行う；
次のサイト＝マトリクスの現在のサイト＋１〜ｎに対して、以下のことを行う；
次のサイトを現在のサイトにスワップする；
マトリクスの次のクラスタ測度を得る；
次のクラスタ測度＞現在のクラスタ速度である場合、
次のサイトを現在のサイトにスワップして元の位置に戻す。
【０２４７】
あるいは
現在のクラスタ測度＝次のクラスタ測度にする；
終了
終了；
この分類は、相互接続が接続ではなく帯域幅であるが、二次の配置アルゴリズムに類似する。設計者は、今回のものではなく、類似の結果を提供する他の方法を用い得る。
【０２４８】
上述された枢軸演算が、好適に、例えば、１１７，０００の向上したクラスタ測度を有する、図４７のマトリクスを生成する。この理想化された例では、コンポーネントが情報を作成しないことに留意すべきである。コンポーネントは、列および行の全部がブロック３およびＰＩＯを除いて適合するように、コンポーネントが読み出すものを書き込む。これは、当該分野で使用のケースではない。
【０２４９】
次いで、設計者は、バスクラスタを定義するために、図４７に示されるようなテーブルを用い得る。この例は、ブロック１、ブロック２、ＰＣＩおよびメモリ間の高いデータ転送レートを示す。したがって、上記のコンポーネントは、高速バス上になければならない。ブロック３とＰＩＯとの間では低いデータ転送レートであるから、上記の設計要素は、低速バス上であり得る。
【０２５０】
ＰＩＯは、出力のみであるが、全ての他のコンポーネントが双方向である。クラスタ内外のコンポーネントが通信しなければならないので、設計者は、図４８に示されるように、二つのバス間のブリッジを作成しなければならない。
【０２５１】
（クラスタリングに基づくバスの定義）
初期クラスタリングは、好ましくは、予め定義されたバス信号ネットの全てを含む必要がある。設計者は、固有の内部サブクラスタを示すためにクラスタ内部で回転し得るが、１つよりも多くのバスのタイプがこれらの信号に対して定義されない場合、次のタスクで１つのクラスタとして処理されるべきである。
【０２５２】
プロセッサのシステムおよび周辺バスが定義されると、クラスタは、クラスタリング情報に基づいて、システムバスおよび１つ以上の周辺バスに分解される。例えば、図４７のテーブルにおけるバスマトリクスが予め定義されたバス信号ネットからなる場合、初期クラスタリングは全体のマトリクスを含む。１つ以上のバスが定義される場合、高速バス上に存在することが必要であるブロックが１つのバスを形成し、残りのブロックが別のバスを形成する。次いで、このパーティションは次のタスクに渡される。
【０２５３】
予め定義されたバス接続が存在しない場合、バスはクラスタ情報に基づく態様で定義される。通常、回転されたマトリクスは、他の隣接するブロックと比較される隣接するブロック間において比較的高いレベルの通信を有する隣接するブロックのグループを有する。図４９におけるテーブルは、以前に回転されたマトリクスと同様のこの種のクラスタリングを示す。図４９は、クラスタリングプロセスをより明瞭にするために以前に示された例とは異なる例に基づく。「＃＃」は、大きい数を表すことに留意すべきである。
【０２５４】
この例では、ブロックＡ、Ｂ、およびＣは、１つの独立したバスクラスタを形成する。なぜなら、３つのブロック間に高い通信レートが存在し、３つのブロックとブロックＤ〜Ｈとの間の通信が存在しないためである。ブロックＤ、Ｅ、およびＦは、別のクラスタを形成する。なぜなら、３つの全ての間の高い通信レートが存在するためである。あるいは、ブロックＤ、Ｅ、およびＦは、２つの別個のバスを形成し得る。すなわち、ＤとＥとの間のポイントツーポイントバス、ＥとＦとの間の別のポイントツーポイントバスである。ブロックＧおよびＨは第３のクラスタを形成する。ＥＦ対とＧＨ対との間の低帯域幅接続が存在する。データ転送の量に応じて、Ｅ、Ｆ、Ｇ、およびＨは、１つのバスまたはより低いレベルの通信のためにそれらの間に双方向ブリッジを有する２つの別々のＥＦおよびＧＨバスであり得る。
【０２５５】
多くの異なるクラスタリング選択肢から選択するためには、以下の指針に従う：
１．ブロック間の切断点を識別して可能なクラスタを決定する。切断点は、比較的低い通信領域から高い通信領域を指す。図４９におけるマトリクス内のＣとＤとの間の切断は、図５０に示された図を生成する。ＡＢＣグループとＤＥＦＧＨグループとの間の通信量を決定するためには、左下および右上のグループにおけるセルが加算される。この合計が０である場合（本例の場合）、２つのグループは、それらの間の通信を有さない。これらのグループは完全に別々のバスを形成する。その切断によってその結果生じた通信が０である回転されたマトリクスを切断する。
【０２５６】
２．識別されたグループの各々の内部では、有意な切断を見出す。生じたグループ間の通信は、各グループ内の通信よりもはるかに少なくなるべきである。図５０では、１つの切断はＤ−Ｈグループにおいて現われ、図５１に示されたように、Ａ−Ｃグループでは現われない。ＧＨグループ間のデータ転送速度は２２であるが、他のグループ内でのデータ転送速度は、非常に大きい数（＃＃）である。これらのクラスタは、２つのバス間にブリッジを有する２つのバスを形成し得る。
【０２５７】
３．クラスタ間またはクラスタ内部の通信が全てのブロックを含まない場合、クラスタを最適化する必要があり得る。遅延マトリクスが所定のブロック間の通信に対する非常に異なる要求を有する場合、最適化することが単に重要である。例えば、図５１は、ＧＨクラスタがＤＥと通信しないことを示す。ＤＥおよびＤＦは通信するが、ＤおよびＦは通信しない。ＤＥに対する遅延要求が非常に厳しい場合、従って設計者は、残りのバスからＤＥ通信を外部に分割すべきである。図５２から生じたマトリクスを見ることができる。この例は、ＥをＥおよびＥ’に分割し、それにより、２つの別々のブロックであるように見える。なぜなら、別々のインターフェースは、２つのバスに対してＥについて作成されるからである。ブロックが２つ以上のバスインターフェースを有する場合、この技術は、別々のインターフェースの効率的な使用を行うために使用され得る。
【０２５８】
この技術が図４３の元の例について使用される場合、図５３に示された、２つのバス間にブリッジを有する２つのバスを含むクラスタが作成される。１つのバスは著しい量のデータを転送する一方で、他のバスは非常に少ないデータを転送する。ブロック３とＰＩＯとの間の別の切断は、クラスタ間のさらに低い通信を生じる。しかし、これは、有意な切断ではない。なぜなら、この切断はクラスタ内に１つのみのブロックを残すためであり、それによりこの切断は行われない。
【０２５９】
４．全ての切断が行われる場合、生じたクラスタ情報は、次のタスクに渡される。
【０２６０】
このクラスタリング技術は、チップのためのバス構造を生成するためのシステム知識を必要とする。この設計者は、既存のブロックバスインターフェース、さらなるプロセッサ要求、およびバス上のマスターの数などのデータタイミングおよびインプリメンテーションの細部を考慮しなければならない。このクラスタリング方法を用いて獲得された構造から逸脱することは、手順に純粋に従うことによって獲得された構造よりも良好な性能または低いゲートカウント有するバス構造を作成することをこれらのファクタが提示し得る。これらのファクタがこのクラスタリング方法を用いて獲得された構造から逸脱する場合、設計者は、このタスクを繰り返して、クラスタリング結果を修正することを望む。
【０２６１】
（バスの選択）
一旦、設計者がクラスタリング方法を用いてバスを定義した場合、バスタイプおよび性能は、階層的に選択されなければならない。バス階層は、最高の性能のバスから最低の性能のバスまで相互接続されるバスの序列である。例えば、ある設計が１つの高速システムバスおよび２つの低速周辺バスを含む場合、階層は、システムバスから２つの周辺バスまで存在する。
【０２６２】
バス分類参照ライブラリからのバス属性およびサイズは、好適には、各バスに対するバスタイプを定義するために使用される。このライブラリリストは、利用可能なバスタイプの各々に対するバス属性のセットを列挙する。適切なバスを選択するためには、設計者は既存のバスインターフェースに対するクラスタにおける各ブロックを解析する。バスが全くないかまたはほとんどない場合、最も類似する属性を有する、バス分類参照におけるバスタイプが選択される。この選択プロセスの結果は、次のタスクにおいて使用されるバスおよび階層の定義されたバスのセットであり、これによりバス設計を特定する。
【０２６３】
バス分類参照ライブラリにおけるパラメータおよび設計におけるブロックのインターフェースをチェックすることによって、バスは以下のように選択されるべきである。
１．クラスタの帯域幅および遅延要求を満たさないバスを除去する
２．バスが既に定義されている場合、バスを使用するが、バスが既に定義されていない場合、バスを使用しない。
３．プロセッサが存在する場合、それが既に接続されているシステムバスを使用し、プロセッサが存在しない場合、それが既に接続されているシステムバスを使用しない
４．ほとんどのブロックが既に接続されているバスを選択する
５．接続されているほとんどのブロックのエンディアンネス（ｅｎｄｉａｎ−ｎｅｓｓ）（大きいエンディアンは、データユニットの左端に０ビットを有し、小さいエンディアンの０ビットは右にある）を処理し得るバスを使用する
６．バスのロードが過剰である場合、マルチバスを使用する
７．周辺バスまたはバス上に別々のより低い帯域幅のデバイスを分離する
８．選択されたシステムバスへの既存のブリッジを有する周辺バスを使用する
９．選択プロセスが完了した後に１つ以上の選択が存在する場合、ＯＣＢ属性リストを最も満たすバスタイプを選択する。なぜなら、その選択は最良のツールおよびモデルサポートを有するためである。
【０２６４】
（バスサイズの計算）
バス遅延テーブルは、このステップのための開始点として使用される。一旦特定のバス構成がクラスタリングを用いて識別される場合、情報は、バスのサイズを決定するために使用可能な形態に変換されなければならない。以前のタスクの例からのマトリクスでは、第１の４つのエントリが１つのグループにおいてクラスタ化され、最後の２つは、第２のグループにクラスタ化される。
【０２６５】
バスサイズを計算することは、転送されたデータ量に対して必要とされた帯域幅を決定し、そして帯域幅を計算し、ターゲット帯域幅ができるだけ近くに接近するまで異なるバス幅値を置換することを必要とする。
【０２６６】
（ターゲット帯域幅の決定）
パターンセットにおけるバスに対して必要とされたターゲット帯域幅を決定することは、以下のステップを必要とする：
１．回転されたデータ転送マトリクスにおける各クラスタで発生する全てのトランザクションを加える。同じ例を続けると、より大きいクラスタにおいて６２，６００存在し、より小さいクラスタにおいて１００存在し、そしてクタスタ間で１，２００存在する。従って図５５におけるマトリクスは、図５４の４つのグループの各々にエントリを加えることによって生成される。
【０２６７】
２．このパターンのセットが取ることを期待される時間を決定する。フロントエンド受理タスクは、この情報を提供する。この例に対して、パターンセットは、１ミリ秒で転送されなければならない。すなわち、高速クラスタは、６３，８００バイトのデータ（ブリッジに１，２００バイトおよびバス内部に６２，６００バイト）を１ｍｓで転送しなければならない。帯域幅は、１秒で転送され得るデータの量（ビット）として定義される。この例では、１ｍｓで５１０Ｋビットを転送し得、帯域幅は約５１０ＭＨｚである。
【０２６８】
（バス幅の計算）
帯域幅は、バス内のワイヤの数（バス幅）とデータが転送されるクロック周波数との乗算によって構成される。
計算は以下のようである。
（ｕｔｉｌ／ｃｌｏｃｋ＿ｃｙｃｌｅ）×ｂｕｓ＿ｗｉｄｔｈ＝帯域幅
ここで、ｕｔｉｌは、選択されたバスタイプに対する最小バス利用パーセントである（図５９参照）。ｃｌｏｃｋ＿ｃｙｃｌｅは、設計のためのクロックサイクルであり、ｂｕｓ＿ｗｉｄｔｈは、バス内のワイヤ数である。この値は２のべき乗でなければならない。
【０２６９】
計算するためには、ｂｕｓ＿ｗｉｄｔｈに対して２１で開始し、生じた帯域幅の値がターゲット帯域幅よりも大きくなるまで、より大きい値（２２、２３、．．．）を置換し続ける。例えば、クロックサイクルが２０ｎｓであり、バス利用率が２５％である場合、最も近い２のべき乗に丸められたワイヤ数は、６４ビットであり、ここで
（２５％／２０ｎｓ）＊２６＝８００ＭＨｚ＞５１０ＭＨｚ
である。
【０２７０】
この例では、図５９のテーブルからタイプ４またはタイプ５を選択した場合、高速クラスタに対するバスにおいて少なくとも６４ビットを必要とする。同様に、２０ｎｓサイクル時間は、より遅いクラスタに対して８ビットのみを必要とする。
【０２７１】
遅延情報は、部分的に利用率の関数である。なぜなら増加されたバスの利用率は遅延を増加させるためである。例を簡単にするためには、このような複雑さは含まない。すなわち、利用率数において部分的に説明される。しかし、概して、帯域幅計算のために最小バス利用率数を使用する場合、遅延は、同様に最小に向かう傾向がある。この効果を説明するためには、設計者は、クラスタからの最悪の場合（最小）の遅延要求を選択すべきである。
【０２７２】
従って、設計者は、シミュレーションにおいて使用された遅延マトリクスから全体のトランザクションの遅延を導き得るが、図５９のテーブルは、別々の数としてバス遅延データおよび転送値を示す。図５９は、タイプ４バスに対する最大転送遅延１０を示す。最小データ遅延は、データ単独に対して必要とされたサイクル数により近い。従って、設計者は、遅延マトリクスにおけるメンバからデータ転送時間を減算することによって、正味の転送遅延がどれくらいかを計算する必要がある。これを以下に示す：
ｄａｔａ＿ｔｒａｎｓｆｅｒ＿ｔｉｍｅ＝ｍｉｎ＿ｃｙｃｌｅｓ／ｎｕｍ＿ｗｏｒｄｓ＊ａｖｇ＿ｔｒａｎｓ、ここで、
ｍｉｎ＿ｃｙｃｌｅｓは、このバスタイプに対するデータ遅延サイクルの最小数であり、
ｎｕｍ＿ｗｏｒｄｓは、バス内のワード数であり、
ａｖｇ＿ｔｒａｎｓは、平均トランザクションサイズである。すなわち、トランザクションマトリクス（図４４）におけるトランザクション数によって除算されたデータ転送マトリクス（図４３）からのデータのバイト数である。
【０２７３】
テーブルから遅延を比較するためには、設計者は、シミュレーションマトリクスからトランザクションのデータ遅延を減算した遅延値を使用する新しい遅延マトリクスを作成しなければならない。上記例では、このテーブルは、図５６に示される。このマトリクスの各要素は、以下のように計算される：［生じた遅延（ｘ，ｙ）−最小バス遅延データ（タイプ）］＊（データ転送（ｘ，ｙ）／［トランザクション（ｘ，ｙ）＊バスサイズ］）。
【０２７４】
システムバスクラスタにおける最小数は、２５である。この値は、帯域幅のために必要とされたバスタイプに対する最大転送遅延よりも大きくなければならない。バスタイプ４の転送遅延に対するこの数は、図５９のテーブルにおける１０であり、それにより設計者は、高速クラスタに対してバスタイプ４またはそれより良いものを選択し得る。
【０２７５】
（バス階層の作成）
一旦設計者がバスおよびロードを識別した場合、どれが高速バスであるか、どれが低速バスか、ならびにどのブリッジおよびアービタが必要とされるかを含むバス性能階層が識別されなければならない。２つのバスが低減されたバスマトリクス（セルからの／セルへのバスマトリクスは、０でない値を有する）に接続される場合、それらのバス間にブリッジを作成する。図５４の例を用いると、回転されたデータマトリクスおよび低減されたバスマトリクスから以下のバスモデルを作成する。
６４ビットのシステムバス（タイプ４または５）は、以下に接続される：
ブロック１（ＲＮＶ）
ブロック２（ＲＮＶ）
メモリ（ＲＮＶ）
ＰＣＩ（ＲＮＶ）
８ビットの周辺バス（タイプ３またはそれより良いもの）へのブリッジ（ＲＮＶ）は、以下に接続される
ブロック３（Ｒ／Ｗ）
ＰＩＯ（書き込み専用）
注記：ＰＩＯは書き込み専用である。なぜなら、そこから入来するデータがないためである。ブリッジは読み出し／書き込みである。なぜなら、バス１と２との間の両方の対角線が０ではないためである。次いで、このマップは次のタスクに渡されることにより、バス設計を特定する。
【０２７６】
（バス設計の特定）
バス設計を特定するためには、設計者は、元のブロック、新しいブロックのセット（ブリッジおよびアービタ等）、およびグルー（ｇｌｕｅ）ロジックのセットに対するインターフェース仕様のセットに作成されたバスを拡張する。元のおよび新しいブロックの仕様は、ブロック設計タスクに渡される。最小ブロック等のグルーロジックは、ブロック設計を介してチップアセンブリタスクに転送される。バスがＯＣＢ属性仕様を満たす場合、マスターおよびスレーブデバイスのためのモデル、ならびにアービタおよびブリッジなどの他のバスオブジェクトを有する。マップで定義された選択バスを用いて、次いで設計者は詳細なバス構造を作成する。
【０２７７】
（詳細なバス構造）
詳細なバス構造を作成するためには、次いで設計者は、以下のようにすべきである：
１．単一のロードおよびブリッジを有する全てのバスを除去することによってバスを最適化する。ロードは、ブリッジの一方の側に配置されるべきである。なぜなら、ロードは、システムバスのプロトコルと１つのみのロードに対する周辺バスのプロトコルとの間で移動するゲートに対してより遅くかつより高価であるためである。設計者は、ブリッジ論理を全体的に除することができないかもしれないが、トライステートインターフェースが除去され得る。なぜならバスは、ポイントツーポイント通信を低減するからである。さらに、８ビットが多くのペナルティなしで１６ビットに変えられ得る。なぜなら２つの末端が互いに配置され得るためである。
２．バスマスターおよびスレーブを種々のロードに割り当てる。設計者は、ブリッジで開始すべきである。ブリッジは、より遅い側上のマスターであり、より速い側のスレーブである。周辺バス上の全てのデバイスは、スレーブデバイスである。システムバス上では、マスターおよびスレーブは、どのデバイスがバスを制御することを必要とするかによって定義される。この設計の知識はこの決定に役立ち得る。プロセッサがバスに接続される場合、そのインターフェースはマスターである。他の場合では、明確なマスターが存在しない場合、ＰＣＩ等の外部インターフェースはマスターである。通常、メモリインターフェースは、ほとんどスレーブインターフェースである。どのブロックがマスターインターフェースを必要とするかを決定するためには、設計者は、バスに対する相互接続要求を参照すべきである。
３．メモリインターフェースをさらに有するプロセッサまたは他のブロックがバスに接続され、ブロックは、メモリインターフェースを特に必要とする場合、設計者は、バス上に１つ以上の直接メモリアクセス（ＤＭＡ）デバイスをバス上に含むべきである。これらのデバイスはバスマスターとして作用する。
４．最終的に、バス上の２つ以上のデバイスがバスマスターである場合、アービタを追加する。
【０２７８】
（詳細なバス設計）
バス構造が定義される場合、ブロックバスインターフェースがチェックされる。ブロックは、バスインターフェースを既に有する場合、インターフェースは、バスに調整するためのソフト、ファーム、またはパラメータ化された形態でなければならない。この場合、既存のバスインターフェースロジックが使用されるべきであり、他の場合は、バスに提供されたモデルが受理可能である。ブロック上に異なるバスインターフェースが存在する場合、可能であれば削除されるべきである。
【０２７９】
このバスロジックは、以下のようにバスとインターフェースを取るように改変されるべきである：
１．インターフェースの各々に対してアドレス空間を割り当てる。通常、アドレス空間は、このブロックがアドレスされるかどうかを決定するように、トランザクションアドレスの上位ビットに整合するように設計される。あるいは、各ブロックが内部ストレージのための十分なアドレス空間またはブロックにおいて使用された動作コードを有することを保証すべきである。
【０２８０】
２．１つのみの機能が使用される場合、書き込みまたは読み出しバッファを除去する。ほとんどの既存のバスインターフェースは、読み出しおよび書き込みの両方を行うように設計される。設計者は、これらの機能の内の１つのみが必要とされる場合、ロジックを著しく低減し得る。例えば、バスが１より大きいクロックサイクルを取る場合、通常、読み出しおよび書き込みデータは別々にバッファされる。１つの機能だけが必要とされる場合、設計者は、レジスタビットの半分を除去し得る。
【０２８１】
３．規定されるバスサイズを満たすように拡張または収縮する。ほとんどのバスインターフェースは、標準的な３２または６４ビットバスに対して設計されるが、他の代替も利用可能である。設計者は、標準的ではないバスインターフェースを必要とする場合、設計者はレジスタおよび信号線を除去または追加するためのロジックを修正しなければならない。同様に、通常、アドレスは、データと同じサイズであるが、これは、この場合ではないかもしれない。同じバス信号にアドレスおよびデータをインターリーブするバスに対して、データおよびアドレスサイズにおける不整合は、信号ではなく、上位アドレスデコードまたはデータレジスタロジックを除去するのみである。
【０２８２】
４．必要ならば、バッファをブリッジに追加する。このような改変がステップ３のようにブリッジの両方の面に対してなされるべきである。
【０２８３】
５．バス間をマッピングするブリッジサイズを修正する。読み出し／書き込みインターフェースに対して、ブリッジは、両方の面上のバスのより大きい部分に等しい、各機能に対して少なくとも１つのレジスタを必要とする。各機能に対するデータバッファに加えて、例えば、図５７に示されたブリッジを用いて、次のバスに転送される前に、データがブリッジによって受け取られる場合、データのバーストがより効率的に転送され得る。これは、図５８のブリッジにおいて示されたように、バーストを格納し、それを次のバスに送るために、各機能に対してＦＩＦＯを必要とし得る。
【０２８４】
６．バスマスターの優先度および調停のタイプを定義する。バス上に１より多くのマスターが存在する場合、マスター間である種の調停が存在しなければならない。厳密に順序決定された優先度からラウンドロビン（ｒｏｕｎｄ−ｒｏｂｉｎ）調停にわたる多くのタイプの調停が存在する。両方のマスターが同様の数のトランザクションおよび必要とされた遅延を有する同じ量のデータを処理する場合、マスターは等しい優先度を有するべきである。一方で、データ、トランザクション、および遅延の量の等価な順序と共に、マスターの重要性における明確な順位が存在する場合、調停が順番に並べられるべきであり、最も重要なマスターが最初に置かれる。
【０２８５】
７．ステップ５における定義に基づいてアービタを作成かつ接続する。バスによって調停方式が分散または集中される。調停ロジックがグルーロジックを用いてブロックに分散されることを可能にするために、調停ロジックはできる限り分散されるべきである。
【０２８６】
８．デバイスのエンディアンネスによって必要とされた場合、バスをインターフェースロジックにマッピングする。ほとんどのバスは、小さいエンディアンであるが、いくつかのデバイスは大きいエンディアンである。末端のタイプ間に不整合が存在する場合、設計者は、バスからのデータのバイトをどのようにして交換するかを決定しなければならない。この決定は、一般的にコンテクストに依存する。バスへのおよびバスからの全てのトランザクションがデータの同じタイプである場合、設計者は、固定されたバイト交換を使用し得、バスへのおよびバスからの全てのトランザクションがデータの同じタイプでない場合、バスマスターは、交換を行わなければならない。
【０２８７】
９．ＤＭＡデバイスをバスに調整する。直接メモリアクセスデバイスは、１つのブロックから別のブロックにデータを転送するコントローラである。直接メモリアクセスデバイスは、任意の他のデバイスのようにアドレスバスのサイズに改変されるべきである。
【０２８８】
１０．必要な場合、任意のテスト可能なポートおよびインターフェースを追加する。最小レベルのテストは、バス自体をテストする能力である。標準的なチップテストロジックもまたバスを使用する。これらのテスト特徴は、通常の動作モードとテストを区別するようにさらなる信号に要求し得る。
【０２８９】
１１．必要な場合、初期化パラメータを追加する。ＰＣＩ等のいくつかのバスは、構成レジスタを有する。これらのレジスタは、変更されない構成に対してハードコード化され得る。
【０２９０】
１２．デバイスによってバス上必要とされる場合、任意のバス能力を追加する。いくつかのバスは、スレッド、分割トランザクション、およびエラー再試行等の高度な能力を有し、バスに接続されたデバイスがこの能力を必要としない場合、インプリメントされる必要がないかもしれない。ＤＭＡデバイス、不連続なバースト転送、およびエラー復元制御等のいくつかのさらなる能力は、標準バスにおいて定義されたよりも多くの信号を必要とし得る。これらの信号は、必要な場合、バスに追加されるべきである。
【０２９１】
これらの改変が終了する場合、バスインターフェース論理は、生じたブロックのインターフェースに接続される。
【０２９２】
（バス分類参照）
バス分類参照は、バス属性およびセルライブラリにおいて利用可能なバスに対する帯域幅、遅延、およびデータ方向に対する関係を列挙するライブラリである。分類ライブラリは、比較的固定された情報の集合である。このライブラリの管理者は、新しいバスが利用可能になる場合、バス属性を更新する必要があり得る。
【０２９３】
（バスタイプ参照）
バスタイプは、遅延および帯域幅利用率によって分類され得る。純粋な帯域幅は、バス内のワイヤの数とデータが転送されるクロック周波数との積の関数であるが、帯域幅利用率は、アーキテクチャの関数である。
【０２９４】
図５９は、最小帯域幅利用率および最長遅延から最大帯域幅利用率および最短遅延までの特定のバス属性のリストを示す。典型的には、論理およびワイヤのコストは、最初では最小であり、そして最後では最大である。ライブラリの各バスは、このテーブルから割り当てられたバスタイプを有さなければならない。各バスタイプは、ある範囲の遅延（サイクル）およびバス帯域幅（利用百分率）を有し得る。各バスは、異なるクロックサイクルの時間および大きさを有し、それにより利用百分率は、サイクル時間とバスのサイズとの積を超える効率的なスループットである。１００％のバス利用率の値は、各サイクルが完全に利用されていることを意味する。データ遅延カラムは、バスがデータのワードに転送するために要するサイクル数を与える。転送遅延カラムは、バストランザクションを開始するために要するサイクルの平均数である。図５９におけるテーブルは、バス利用率および遅延値の粗い推定を与える。設計者のグループは、経験およびその設計のタイプに基づいて値を特定し得る。
【０２９５】
（バス分類参照）
複数のプロジェクトにわたって、設計グループはバスのライブラリを蓄積する。各バスは、図４１に示された参照ライブラリからのバスのタイプを含む情報のセット、ならびに、「Ｂｌｏｃｋ−Ｂａｓｅｄ  Ｄｅｓｉｇｎ  Ｍｅｔｈｏｄｏｌｏｇｙ  Ｄｏｃｕｍｅｎｔａｔｉｏｎ」Ｖｅｒｓｉｏｎ１．２（１９９９年５月２１日）のＢ−５〜Ｂ−１０ページのセクションＢ．２（この全体を本明細書中で参考として援用する）において見出されたＶＳＩ  ＯＣＢ属性仕様およびバス分類参照からのバス属性のリストを含む。この情報は、どのバスを使用するかを決定することについて説明された場合、この情報が使用されるべきである。
【０２９６】
（テストのための設計）
発明の背景において説明されたように、テストを簡単にすることは、ＳＯＣ設計の最も重要な属性の内の１つである。従って、テストに対する設計（「ＤＦＴ」）は、標準となっている。所与のカスタマ仕様に対して、本明細書で説明された方法論を用いて導かれたＤＦＴ知識ベースが、質問および回答（Ｑ＆Ａ）形式でカスタマに提示するために検索されかつ抽出され得る。このデバイスを介して、テストの対象が交渉され得、テスト問題が、フロントエンド受理の間に交渉された作業明細書（Ｓｔａｔｅｍｅｎｔ  Ｏｆ  Ｗｏｒｋ（ＳＯＷ））において解決される。
【０２９７】
テスト計画段階は、テスト収支、テストスケジューリング、およびテスト管理に従うことにより、仕様およびテスト計画のセットを生じ、公知の資源および手順のセットを用いて明確に定義された目的のためにテスト開発を別個の独立したサブタスクにさらに分解する。
【０２９８】
各テストブロックは、予め規定されたレシピに従って同時に開発され、最も利用可能な技術を用いて処理され得る。
【０２９９】
一旦、テストブロックがテスト統合のために準備されると、テストブロックは、制限されていないＳＯＣ境界にマッピングされ得ることにより（Ｉ／Ｏ制限が適用されない）、各層が設計ブロックに変換される制限されていないＳＯＣのための「テスト準備態勢にある」テンプレートとなる。次いで制限されていないＳＯＣは、さらなるＩ／Ｏレベルテストによって特定のＩ／Ｏパッケージングに制限される。これにより、テストスケジューリングプロセスは、ＳＯＣレベルのテスト対象を発生させ、これを満たすことをイネーブルする。
【０３００】
（ＤＦＴテスト計画の作成）
ＦＥＡ間のカスタマの計画の獲得の後に、好適なテスト計画開発方式は、これがテスト併合可能であるかどうか（テストは、複数のブロック上の同時に実行され得るかどうか）を見るために各ブロックの評価を開始する。次に、設計者は、併合可能なブロックの各々がどれくらい「テスト可能」であるかを決定する。第３に、ＪＴＡＧ境界スキャン等のテストタイプを含むチップレベルテスト仕様、ＤＣテスト、およびＰＬＬテストが開発される。最終的に、テスト失敗適用範囲は、全体のチップレベルにおいてテスト併合可能なブロックに対して、ブロックレベルにいて併合可能ではないブロックに対して、そして相互接続に対して特定される。この４つに分かれた（ｆｏｕｒ−ｐｒｏｎｇｅｄ）初期解析の結果は、全体のシステム設計に対してＤＦＴ対象を提供する。
【０３０１】
プログラム可能なファブリックに関して、テスト計画は、プログラム機能性のテストを最小に含むべきである。しかし、設計者はまた、タイミング（特にタイミングに敏感な回路設計）に対するテストを望み得る。さらに、検証ラッパーは、プログラム可能な回路部のプログラミング特性を支援するように提供されるプログラミングポートのために開発される必要があり得る。元のプラットフォーム設計に基づいているが、単にプログラムされた機能性の変化によって変更される「誘導的な」設計に対して、テストを新しいプログラム可能な機能性にテストすることを制限し、必要ならば、プログラムされた機能性の変化によって影響され得るタイミングを制限することが望ましくあり得る。しかし、所定のタイミング収支内に適応するように誘導された設計において新しいプログラムされた機能性が提供される場合、タイミングは再テストされる必要はない。
【０３０２】
（ＤＦＴ規則の使用）
特定の、テストに関連した制限があるＤＦＴアーキテクチャ規則は、一貫性のあるテスト開発フローおよび密接したテストデータ管理を維持するために使用される。これらの規則は、テスト属性のアプリケーションをトップレベルで仮想ソケットにおける配置のために併合可能ではないブロックの各々に導き、最も簡単で最も適用できるテスト戦略を得るためにトレードオフの実行を導き、設計のためのトップレベルのテスト仕様の作成を形成し、そしてテスト計画の誘導がテストインプリメンテーションプロセスを詳述することを可能にする。
【０３０３】
（ＤＦＴ用語集）
列挙されたＤＦＴ用語は、本明細書中で使用される場合、以下の定義を有する。
認証：予め指定されたブロックの統合を可能にする変換プロセス
ＢＩＳＴ：組み込まれた自己テスト
ＢＳＲ：１つ以上の境界スキャンレジスタ
ＣＡＰ：チップアクセスポート
ＣＴＡＰ：コアテストアクセスポート
ＤＡＰ：設計アクセスポート
ＤＦＴ：テストのための設計
失敗適用範囲：テストのスタックアット失敗（Ｓｔｕｃｋ−ａｔ−ｆａｕｌｔ）適用範囲
ＩＣＴＡＰ：集積回路テストアクセスポート
ＩＰ：知的所有権
ＪＴＡＧ：ジョイントテストアクショングループ（Ｊｏｉｎｔ  Ｔｅｓｔ  Ａｃｔｉｏｎ  Ｇｒｏｕｐ）（ｉＥＥＥ−ｉ  １４９．１）
レガシーブロック：未知の結果の危険なしで再利用可能性のために改変またはリバースエンジニアリングできない予め指定されたゲートレベルブロック
併合可能：併合可能なコンポーネントに対するテスト要求が１つ以上の他のコンポーネントのテスト要求と結合され、それによりテスト要求は、ユニットとしてテストされ、テスト時間およびコストを節減し得る
ＭＩＳＩＲ：マルチ入力署名発生器
Ｍｕｘ：マルチプレクサ
併合不可能：パラレルテストに対する他のブロックと併合できない
ＰＲＰＧ：擬似ランダムパターン発生器
ＳＡＰ：ソケットアクセスポート
ソケット化：テストカラーを特定し、それを設計の範囲のテストを可能にする予め指定されたブロックに追加する適応プロセス
ＴＡＰ：テストアクセスポート
ＴＢＡ：テストバスアーキテクチャ
テストカラー：テストアクセスおよび制御を提供する予め指定されたブロックを囲むテストポートおよび論理の集合
テスト併合可能：少なくとも１つの他のブロックと併合できるブロックであって、二つ以上のブロックは単一のテストプロトコルによってテストされるブロック
時間設定：サイクル化されたテスター時間フォーマット。すなわち、ＲＺ（０復帰）、ＮＲＺ（非０復帰）、ＲＴＯ（１復帰）、ＤＮＲＺ（遅延された０復帰）である
ＵＤＬ：ユーザ定義ロジック
ＶＣ：仮想コンポーネント
仮想ソケット：そのテストインターフェースを含む予め指定されたブロックのためのプレースホルダ
ＶＳＩＡ：仮想ソケットインターフェース協定
（テスト計画の作成）
全体のＤＦＴテスト計画を生成するプロセスは、ＦＥＡ発生入力、各ブロックに対するテスト技術、予測されたテストベクトル仕様、製造のためのテスト時間要求、予測されたテストベクトル使用、ならびにＩ／Ｏおよびアナログ混合信号（「ＡＭＳ」）要求モジュール（ｘｒｅｆ）によって供給された特殊なパラメトリックまたはアナログテストを受け取るテスト設計者によって開始する。従って完全なＤＦＴ計画は、効率的な編成およびこのデータの使用を含む。
【０３０４】
（併合可能ではないブロックのテスト要求）
チップレベルテスト要求は、併合可能ではないブロックテスト要求を含み、次いで、４つのコンポーネント（テストモデルと、専用テストポートおよびテストモード等のテスト制御ロジックと、セーフアウト等のテスト分離ロジックと、テストベンチおよびテストベクトル等のテスト妥当性コンポーネント）を含む。併合可能ではないブロックがカスタマに送達される場合、それらのブロックは、テストアクセスおよび制御データ（テストモード、起動、および終了等）、テストプロトコル、テストデータ、テスタフォーマット、およびテストアプリケーション／設定時間を特定する。
【０３０５】
（併合可能なブロックのためのテスト要求）
チップレベルテスト要求はまた、全てのテスト併合可能なブロックのためのテスト情報を含む。次いで、テスト方法、テスト制御論理、相互接続インプリメンテーション機構、およびテスト妥当性コンポーネントを含む。
【０３０６】
（チップレベルテスト要求）
チップレベルテスト要求はまた、電力分配およびアナログテスト要求等のＤＣテスト要求、ＡＣテスト要求、Ｉｄｄｑテスト要求もまた含み得る。
【０３０７】
（チップレベルテストコントローラ）
チップレベルにおけるテスト制御は、ＪＴＡＧ、ＰＲＰＧ、およびＭＩＳＲであり得る。
【０３０８】
（コンポーネント属性マトリクス）
設計者は、ＢＢＤ設計におけるコンポーネントのためのテスト開発環境を説明するためにマトリクスを使用し得る。このマトリクスドキュメントは、可能な解決策を発行し、推薦し、または評価し、さらなる情報が必要とされる場所を示す。マトリクスはまた、テスト設計における困難および不適合性が存在する競合領域を識別する。
【０３０９】
（ＤＦＴ規則の使用）
一旦設計者は、マトリクスを用いることによってチップレベルテスト要求をフィルタリングかつ分類した場合、ＤＦＴアーキテクチャ規則のセットを用いてこれらの要求を処理し得る。アーキテクチャ規則を用いることは、共通のアクセス、テスト制御、テストクロック、および非同期属性を可能にし、そして利用可能なＤＦＴアーキテクチャに基づいてトレードオフして、設計されたチップのための固有のハイブリッドＤＦＴアーキテクチャの作成を可能にする。
【０３１０】
適応可能性は、ＢＢＤ  ＤＦＴ戦略の１つの特徴である。適切なテスト統合を確実にするためには、設計者は、制約およびフロントエンドアクセプタンス（ｆｒｏｎｔ  ｅｎｄ  ａｃｃｅｐｔａｎｃｅ）の末端で受け取られたテスト情報に基づいて各併合可能でないブロックに仮想ソケットを割り当てる。ＤＦＴアーキテクチャは、これらの仮想ソケットをチップレベルテスト要求の残りに統合することによって仕様を完成する。各仮想ソケットは、このようなテストデータの変換に影響を与えるように、チップアクセスポート（ＣＡＰ）にマッピングされたソケットアクセスポート（ＳＡＰ）を有する。
【０３１１】
設計者がテスト計画を作成し、テストのための設計の準備を開始し得る前に、一貫性および結合（ｃｏｈｅｓｉｏｎ）のためのグループのＤＦＣアーキテクチャ規則をチェックしなければならない。
【０３１２】
（一貫性）
一貫性は、各コンポーネントのためのテスト開発適用範囲が、４つのモード（通常、テスト、分離、および境界（ｃｏ−ｔｅｓｔ））で完成する度数である。設計者は、そのモデル、コントローラ、設計、分離、およびテスト妥当性の値、が各ブロックとチップレベルの記述との間で一貫性がることを確実にするために、各コンポーネントに対してチェックリストを使用し得る。
【０３１３】
例えば、３つの併合可能ではないブロックＡ、Ｂ、およびＣを有する設計では、テストコントローラ設計は、ブロックＢおよびＣが分離される場合にのみ、ブロックＡをテストし得る。テストコントローラ仕様は、ＢおよびＣが分離された場合のみブロックＡのテストアクセスを特に可能にしなければならない。ブロックＢおよびブロックＣが同時にテストされるべきである場合、テストコントローラ仕様は、単一のシミュレーション環境におけるテストデータを同期化するテスト妥当性方式を用いて両方のブロックへのテストアクセスを可能にしなければならない。
【０３１４】
この例に対して、図６０のテーブルは、例示的なブロックＡの一貫性のチェックを示す。
【０３１５】
（結合）
結合は、フローにおけるテスト方法が互いに関連する度数である。５つの密接に関連したテスト方法のパラメータが存在する。各々は他を修正し得る。例えば、テストアクセス方法は、テストプロトコルの始動条件を規定し、テストプロトコルは、どれくらいの数のテストデータが連続しているかを規定し、そしてテストデータは、特定のテスターの時間設定を有するパターンのセットに分解される。そして、埋め込まれたブロックへのテストアクセスがチップＩ／Ｏ制限およびコントローラ設計に対して敏感であるために、これらのパラメータの結合は、テストデータ統合性を維持するために独特の検証スタイルを必要とする。従って、５つのテスト方法パラメータは、テストアクセス、テストプロトコル、テストデータ、テスター時間設定、およびテスト時間である。
【０３１６】
（アーキテクチャ規則）
図６１は、ＤＦＴ各々からのチップの上位レベル階層を示す。設計者がＤＦＴプロセスを開始する前に、設計者は、機能ブロックの集合としてではなく、図６１に示されたようにチップを視覚化すべきである。図６２は、併合可能ではないブロックがソケットかされるＳＡＰおよびＤＡＰを有する機能ブロックから作成された設計を示す。
【０３１７】
実際には、この設計における機能ブロックは、挙動ＲＴＬ、ゲート、または混合されたレベルのＨＤＬにおいて説明され得る。ＨＤＬファイルは、ディレクトリ構造内で編成される。テストファイルを編成する好適な方法は、以下のアーキテクチャ規則において説明されたようにディレクトリ階層を作成することであり、次いで、設計階層内のデータファイル内のデータファイルへのリンクをテストディレクトリに置く。このように、チップは、ＨＤＬ命令を用いて異なる構成で構築され得る。
【０３１８】
チップレベルのＤＦＴアーキテクチャが単一のレベルのみを有するために、すべての属性は上位レベルにある。従って、設計者が、上位レベルの設計ファイルに抽出可能なコメント形式で属性を置く以下のアーキテクチャ規則を使用すべきであることが意図される。
ＤＦＴアーキテクチャを階層的に記述する
最高レベルの階層において単一のチップアクセスポート（ＣＡＰ）を作成する。
好ましくはＣＡＰ仕様は、以下のようにすべきである。
【０３１９】
ａ．設計およびテストデータを一貫的に維持するために、テスト制御およびテストデータピンに全てのパッケージレベルピンをマッピングする
ｂ．テストデータピンからテスト制御ピンを分離する
ｃ．テスト制御ピン属性を専用または選択可能な以下のいずれかのように設定する
ｉ．専用：好ましくは属性が通常モードで排他的に停止されるべきである場合、専用ピンは機能的なピンと共有され得ない。
【０３２０】
ｉｉ．選択可能：属性が、テストにわたってテスト定数（論理値）に設定される場合、選択可能なピンが機能的なピンと共有され得る。
【０３２１】
ｄ．テストデータピン属性を以下のように設定する。
【０３２２】
ｔｅｓｔ＿ｃｌｏｃｋ：ｔｅｓｔ＿ｃｌｏｃｋがテストの間にクロックとして使用される場合、ｔｅｓｔ＿ｃｌｏｃｋピンが外部機能クロックピンと共有されるのみであり得る。
【０３２３】
ｔｅｓｔ＿ａｓｙｎｃ：ｔｅｓｔ＿ａｓｙｎｃがリセットのためのテストの間に非同期的に使用される場合、ｔｅｓｔ＿ａｓｙｎｃピンが他のテスト、テストモード、または分離モードと任意の競合をさせない場合、ｔｅｓｔ＿ａｓｙｎｃピンが専用化または共有され得る。
【０３２４】
ｔｅｓｔ＿ｇｒｏｕｐ（ｉ）：（ｉ）は、ｔｅｓｔ＿ｇｒｏｕｐピンがテストの間に同期化されるｔｅｓｔ＿ｃｌｏｃｋである。
【０３２５】
ｅ．各テストモードについて以下に説明する。
【０３２６】
ｉ．テストセットアップがアクセス順序を必要とする場合、テスト下においてデバイスへのアクセスを獲得する必要がある。ＪＴＡＧ命令等、テストクロック、テストリセット等のプロトコルを説明する。
【０３２７】
ｉｉ．テスト実行が実際のテストを実行するために必要とした。タスクレベル、反復数、サイクル時間、およびテスト結果までの段階でテスト順序を説明する。
【０３２８】
ｉｉｉ．テスト後処理は、テストを終了し、チップをデフォルト条件（通常モード）に再度置く必要がある。
３．各テストモードに対してテストセットアップおよびテスト処理順序を説明するＣＡＰコントローラを作成する。仕様は、好適にはインプリメント可能（合成可能）かつ検証可能（テストベンチおよびテスト順序）であるべきである。
４．設計者は、内部テストデータバスを利用可能なテストデータピンに折りたたむようにステージングラッチのセットを任意に特定し得る。このステージング動作は、好適には連続的なテスト結果を変更してはいけない。ステージングは、好ましくは、以下のようであるべきである。
【０３２９】
ａ．状態変更がない場合、時間に敏感な信号である。その信号を分解するために、ｔｅｓｔ＿ａｓｙｎｃ信号を用いるかまたはｔｅｓｔ＿ｃｌｏｃｋに対して持続的な発生の順序に従う。
【０３３０】
ｂ．状態変更がない場合、時間に敏感な信号であり、追加のテストピンを有するべきである。この規則は、好ましくはテストパッケージング問題を回避するように慎重に使用されるべきである。
５．設計者は、テストデータを圧縮するテストデータ署名解析能力（ＭＩＳＲ等）を随意に特定し得ることにより、物理Ｉ／Ｏ制限を最小化する。署名解析は、好ましくは、動作の各サイクルに対して決定論的であるべきであり、好ましくは以下のようにすべきである。
【０３３１】
ａ．ＭＩＳＲ入力においてそれを回避することによってＸ−値伝搬がない
ｂ．ステップａが失敗すると、影響されたＭＩＳＲサイクルを抑圧する。この規則は、失敗の適用範囲の損失を慎重に避けることに従うべきである。
６．設計者は、以下の特定のテストを実行するためにチップ周辺において他のテスト機構のセットを選択的に作成し得る。すなわち、境界スキャンテスト等のＤＣおよびＡＣパラメトリックテスト、ＰＬＬテスト等の周波数テスト、ＡＤＯおよびＤＡＣテスト等の混合信号テストである。これらのテストに対する制御ピンは、好ましくは、全てのｔｅｓｔ＿ｃｏｎｔｒｏｌピンのテーブルに含まれるべきである。設計者はまた、相互作用の競合を避けるためのＣＡＰコントローラ仕様においてその制御ピンを含むことを望み得る。
７．次のレベルの階層における単一のデバイスアクセスポート（ＤＡＰ）を特定する。そのレベルはＩ／ＯまたはＩ／Ｏに関連したセルはなく、物理Ｉ／Ｏに対して制限されない。
８．ＤＡＰは、ＴＡＰベースのポート等の一般的なポートを連結し、併合し、大きさ変更し、マルチ化することによって形成され得るハイブリッドテストポートであるべきである。
９．設計者は、好ましくは、ＣＡＰコントローラから直接ＤＡＰを構成することができるべきである。テスト制御、テストデータ、またはテスト分離ポートに各構成を区切る。各構成では、
ａ．好ましくはターゲットの構成ｋを設定するために使用されるべきである場合、ｔｅｓｔ＿ｃｏｎｆ（ｋ）
テスト定数に設定され得る場合、ｔｅｓｔ＿ｓｅｌｅｃｔ
ｂ．テストポートデータ属性を以下のように設定する
テスト中にクロックとして使用される場合、ｔｅｓｔ＿ｃｌｏｃｋ
テスト中に同期的に使用される場合、ｔｅｓｔ＿ａｓｙｎｃ
（１）が、ポートが同期化されるテストクロックを示すｔｅｓｔ＿ｇｒｏｕｐ（ｉ）
テストデータ命令を示すために使用された場合、ｔｅｓｔ＿ｄｉｒｅｃｔｉｏｎ。テスト命令は、１または０の値であるのみであり得る。
【０３３２】
ｃ．好ましくはテスト分離ポート属性が０、１１、またはＺの安全状態論理値を有するテスト間に分離される場合、ｓａｆｅ＿ｓｔａｔｅ、およびその属性が０または１を有する非浮動論理値に設定される場合ｄｏｎｔ＿ｃａｒｅにテスト分離ポート属性を設定する。
１０．ＣＡＰ、ＣＡＰコントローラ、ステージングラッチ、ＭＩＳＲ、ＤＡＰ、および他のテスト機構の相互作用を特定する。
１１．ＣＡＰコントローラ、ステージングラッチ、ＭＩＳＲ、設計ボディ、および他のテスト機構を専用のセクションに特定する。
１２．設計ボディアーキテクチャのみのために、ソケット、ＵＤＬ、テスト相互接続をＤＡＰ上で詳細に特定する。
１３．設計ボディアーキテクチャは、好ましくは階層的に説明されるべきである。
１４．好ましくは、階層の次のレベル（ソケットレベル）においてマルチＳＡＰがあるべきである。
１５．各ＳＡＰは、好ましくは、ＤＡＰに対して利用可能な複数の利用可能な構成を有するＤＡＰの再帰的イメージであるべきである。ＳＡＰの全ての構成は、好ましくは、ＤＡＲによってサポートされるべきである。
【０３３３】
（ソケット化（ｓｏｃｋｅｔｉｚａｔｉｏｎ）ルール）
一旦、マージ可能でないブロックまたはＶＣが設計に配置されると、そのＩ／Ｏポートは、もはやチップＩ／Ｏからアクセスすることができない。Ｉ／Ｏポートで生成されるテストデータもまた、もはや利用することができない。
【０３３４】
一般的に、チップレベルでのテストデータの再生成は、困難であり、かつ、予期することができない。なぜならば、設計ブロックテスト値は、他の論理ブロックを通って伝播される。従って、好ましいアプローチは、設計ブロックに対する仮想ソケットを生成することによって設計ブロック自体をアクセス可能にすることである。仮想ソケットは、テストアクセス、アイソレーション、および、チップＩ／Ｏからアクセス可能な境界テスト機能性を含む。
【０３３５】
設計者は、設計の設計ブロックに対するプレースホルダとして仮想ソケットを利用し得る、もしくは、また設計ブロック自体にテスト制約を置くためにそのソケットを利用し得る。設計ブロックは、Ｉ／Ｏマッピングおよび制限を利用して、設計内の設計ブロックに制約がマッピングされる時、ソケット化される。制約は、設計に敏感であり、かつ、条件的であるが、設計者に各設計ブロックソケット化タスクを結合性のあるように分割させる一方で、設計の統合の間に設計ブロックのトラックを保つ。
【０３３６】
ソケット化設計ブロックは、機能インターフェイスを維持しながらチップレベルのテスト制約に整合するように、余分なＩ／Ｏポート、および、論理もしくはテストカラー（ｃｏｌｌａｒ）を必要とし得る。インターフェイスタイミングは僅かに変更させられ得るので、ＲＴＩＬコードにテストカラーを書き込み、各ソケット化ブロックに統合して特徴付けられる、または、再度予定が立て直されることが一番である。設計全体を統合させた後、ゲートレベルでテストカラーを付加することは、タイミングの問題を発生させる。
【０３３７】
設計ブロックソケット化ルールは、以下の通りである。
【０３３８】
１．ソケットは階層的に説明され得るが、最上位レベルは、好ましくは、全てのテスト属性を含むべきである。
【０３３９】
２．ソケット当たりに１つだけＳＡＰが存在し得る。
【０３４０】
３．ＳＡＰは、ソケットの全ての要素を分離し、テストし、診断し、かつデバックする方法についてのテスト情報に対する参照のみである。
【０３４１】
４．各ＳＡＰは、好ましくは、上位レベルの仕様に応じて構築される、または、統合されるべきである。
【０３４２】
５．設計者は、好ましくは、上位レベルの構成およびコンテクストでは、各ＳＡＰが通常のテスト、アイソレーション、境界モードを起動し、かつ、終了し得ることを検証することができるべきである。このことは、設計者が、ソケットの外部のテスト情報構造を検証すべきであることを意味する。
【０３４３】
ａ．外部のテスト情報構造は、好ましくは、ＶＳＩＡ順守ルールに明記される標準化記述言語に準拠すべきである。
【０３４４】
ｂ．標準化記述言語が利用可能でない場合、テスト情報構造は、仮想ソケットにおけるチップレベルの設計テスト属性に準拠すべきである。
【０３４５】
６．各ＳＡＰは、好ましくは、テスト設定、テスト実行、および、テスト後処理シーケンスを適切に実行することを保証するために、再フォーマットされたテストデータによってソケットレベルで有効にされるべきである。このことは、設計者がソケットの内部のテスト情報構造を検証すべきであることを意味する。
【０３４６】
ａ．内部のテスト情報構造は、好ましくは、全ての設計ブロックテストモジュール、全ての機能性ブロック、および、ソケットによって結合される全ての他の論理を含むべきである。
【０３４７】
ｂ．内部のテスト情報構造は、好ましくは、チップレベルのシミュレーション環境と共同シミュレートされ、かつ、共同操作されるべきである。
【０３４８】
７．ノーマルモードでは、ＳＡＰに関連する全てのテスト論理は、好ましくは、ＳＡＰインターフェイスから、同時かつ直接的であり、順番どおりではなく終了されるべきである。ノーマルモードは、単一のテスト制御ポートによって起動されるべきである。
【０３４９】
８．アイソレーションモード（ｒｅｓｔ）では、ＳＡＰに関連する全てのテスト論理は、中間の衝突なしに、終了され、かつ、セーフ状態値に割り当てられるべきである。
【０３５０】
９．テストモードでは、ＳＡＰに関連する全てのテスト論理は、好ましくは、単一の起動シーケンス、その後の選択的な設定シーケンスによって、テストシーケンスを開始する前に有効にされるべきである。テスト時間を最小化するために、同一の構成の逐次テストシーケンスは、バンドルされるべきである。
【０３５１】
１０．全てのソケットの周辺論理は、境界（共同テスト）モードでテスト可能であるべきであり、ＳＡＰに関連するテスト論理を含む。
【０３５２】
（最上位レベルのテスト論理仕様の設計）
対象範囲および時間要件に適合するように、設計者が最上位レベルのテスト論理使用を設計する時、設計者は、テスト論理のパラレルな性質を増強するトレードオフを生成する必要がある。主要な決定は、各ブロックテストを生成するためにシリアルまたはパラレルをどうするべきかである。
【０３５３】
テスト制約は、テストカラーを構築するためのテスト要件を確立するように、ソケット化ルールを有する各仮想ソケットのために利用される。テストアクセスの観点からは、ＳＡＰは、テスト統合目的に対して完全であり、かつ、適切である。設計およびテスト衝突を発生させ得る設計変更を避けるために、ＳＡＰは、ブロックの機能的要素を共用する、または、利用すべきでない。この分離は、異なるブロックタイプ（ソフト、ファーム、または、ハードブロック）が利用される際により意味をなし、テスト統合の間の不確定性を避けることができる。
【０３５４】
一般的に、各アーキテクチャは、ソリューションの一意のセットもしくは特定のツールのセットを目的とし、テストアプリケーションの特定の範囲を対象とする。多くのアーキテクチャは、設計のほぼ全ての役割にまたがる特定の設計環境に由来する。従って、開発フローは、以下のことがなされる必要がある。
【０３５５】
１．設計コンテクストにおけるテスト問題を特徴付け、かつ、カテゴリー化する。
【０３５６】
２．各アーキテクチャのためのトレードオフに対処する。
【０３５７】
３．各対象とされる設計に対してさらなる変更を提供する。
【０３５８】
本発明の出現までは、ＢＢＤテスト問題は、以下の領域にいて明らかであった。
【０３５９】
テストデータ再利用性
テストソケット設計およびソケット情報
ＵＤＬおよびチップレベルの相互接続テスト
テストパッケージ化
テスト検証
テストプロトコル
診断およびデバック
これらの問題は、ＢＤＤ設計プラニングの間になされる前提に関連する。しかし、設計プランは、多くの特定のプロセス（例えば、テスト用のＢＤＤ設計を生成する、設計ブロックテストインターフェイスをカスタマイズする、テストアクセスおよび制御メカニズムを設計および検証する、および、チップＩ／Ｏによりかつテスト量（ｂｕｄｇｅｔ）内でテストをパッケージ化する等）に、再利用可能なテストデータを有するデザインブロックをパッケージ化することをリクエストする。
【０３６０】
（ＤＦＴ分類（Ｔａｘｏｎｏｍｙ））
ＤＦＴアーキテクチャは、テスト方法、テストインターフェイス、および、利用され得るブロックのタイプによってクラス分けされる。４つの異なる一般的なＤＦＴアーキテクチャが存在するが、同様のテストインターフェイスを有することはほとんどない。例えば、ほとんどのチップが、メモリＢＩＳＴインターフェイスを利用する組み込みＲＡＭを有する一方で、残りのチップは、スキャン方法を利用し得る。図６３の表は、設計シナリオにおける典型的な選択をリストにする。
【０３６１】
（最上位レベルのＤＦＴアーキテクチャを生成するプロシージャ）
図６４のフローチャートは、最上位レベルのアーキテクチャ仕様を生成し、かつ、チップレベルのテスト構造を特定するために利用されるプロシージャである。ＤＦＴプランは、好ましくは、チップ上の全てのブロックに対してブロックレベルのテスト論理を特定すべきである。テスト論理を有するブロックは、最上位レベルに対するインターフェイスを受けとるべきである。テスト論理なしのブロックは、テスト論理要件を受けとるべきである。これらの設計要件の両方をブロック設計に送信し、好ましくは、最上位レベルのテストおよびアクセスメカニズムの両方を生成する。
【０３６２】
図６５のフローチャートは、ブロックテスト論理仕様を生成するために利用されるソケット生成プロシージャを示す。この設計における各ソケットに対して、示されるＤＦＴアーキテクチャと適合させるために、各設計ブロックのためのテストカラーを特定する。
【０３６３】
（テスト生成メカニズムの生成）
テスト生成のためのＢＢＤストラテジーは、マニュアルベクトル、ＡＴＰＧを含み得、あるいは、混合される。翻訳および連結メカニズムは、最上レベルのテスト論理および各ブロックのテストメカニズムと整合するように規定されるべきである。ＢＢＤにおいて、テスト開発は、２つの独立プロセスを含む。
【０３６４】
１．各仮想ソケットに対するブロックレベルのテスト開発。ほとんどの場合、このプロセスは、以下のタスクからなる。
【０３６５】
ａ．ＳＡＰ宣言：ＳＡＰを挙動モデルインターフェイスに加えて、かつ、仮想ソケットを有するブロックを再インスタンス化する。
【０３６６】
ｉ．テスト論理挿入：テストアクセス、アイソレーション、相互接続テスト、およびテスト制御論理を加えて、対象とされるブロックの周りのテストカラーを形成する。最良の結果のために、統合可能ＲＴＬ形式でテストカラーを記述する。
【０３６７】
ｉｉ．テストデータ転換：テストデータをＳＡＰポートへ展開し、かつ、マッピングする。新しいテストデータフォーマットを許容するようにブロックレベルのテストベンチを修正すべきである。テストフローを簡素化するために、あるブロックのテスタータイミングを変更して、ソケット当たりの設定時間を最小化し、同時に複数のブロックテストを実行し得る。
【０３６８】
ｉｉｉ．テスト検証：ブロックレベルのテストベンチを修正して、テスト論理を検証する。ターゲットブロックを完全なブロックレベルのテストベクトルセットのサブセットで検証して、前のステップの前後のテストデータ整合性を保証する。
【０３６９】
２．ＤＣテストおよびアナログテスト等の全てのテストマージ可能ブロックおよびチップレベルのテストに対するチップレベルのテスト開発。このプロセスは、以下のタスクを含む。
【０３７０】
ａ．テスト論理挿入：テストコントローラ、専用テストピン、ＤＣテスト論理、アナログテスト論理、および、必要であれば、全てのテスト用のクロックマルチプレクサおよびテストクロックを加える。このタスクはまた、テストマージ可能ブロック、および、必要であれば、ＵＤＬに対するスキャン挿入を含む。
【０３７１】
ｂ．テスト生成：ＡＴＰＧツールを用いて、テストマージ可能ブロックおよびＵＤＬに対するテストデータを生成する、または、サイクル機能テストデータをキャプチャする。対象とされるテストデータの製造とフォルト対象範囲の目的を適合させることが重要である。
【０３７２】
ｃ．テスト検証：チップレベルのテストベンチを修正し、テストコントローラを検証し、かつ、ＤＣテスト、アナログテスト、設計の全ての仮想ソケットに対するテスト、および、ＵＤＬテストを実行する。これらのテストは、ＪＴＡＧが要求するような前および後テストシーケンスを必要とし得る。
【０３７３】
ｄ．テストデータフォーマッティング：シミュレーション結果を出し、その結果をＷＧＬ等のテストデータ記述言語で表現する。
【０３７４】
次に、ＢＢＤ  ＤＦＴメソドロジーコンテクストでブロックレベルのＤＦＴのアプリケーションに進む。知的財産コアまたは設計ブロックの最終製品は、標準化された、または、一般的なテストインターフェイスおよびチップレベルで再利用され得るテストデータセットを有する「テスト読み込み」ブロックである。設計ブロックソケット化スキーマは、設計ブロックをチップレベルのテストの完全な部分に変換するために利用される一方、各ブロックの設計の間に生成されるほとんどのテストプロシージャおよび装置を再利用する。本発明の１３１３１）ＤＥＴうまく組み合わせた（ｍｉｘ−ａｎｄ−ｍａｔｃｈ）ストラテジーは、最好評なスキャンに基づくテストメソドロジーと対比して、マージ可能でないブロックを分類することによって、異なるテスト方法およびテストインターフェイスを有する事前に設計された多様なブロックを組み込むための柔軟なアプローチを提供する。スキャン設計メソドロジーをテストマージ可能選択のための根拠にする理由は、単に自動化による簡素化の目的である。
【０３７５】
ブロックＩ／Ｏのアクセスビリティについての特定の前提を配慮して、再利用可能なテストデータを有する設計ブロックをパッケージ化するために、多くの特定のプロセスに含まれるブロック設計プランは、標準化されるか、または、カスタマイズされた設計ブロックテストインターフェイスに基づく。しかし、一旦組み込まれると、ブロックＩ／Ｏは、異なるコンテクストで配置され得、かつ、潜在的にアクセス不可能になる。組み込みの簡潔さを保証するために、テストインターフェイスは、チップ設計の観点からいくらかの直交性を提供するために、機能性インターフェイスから分離されるべきである。Ｂ８Ｄにおいて、設計ブロックインターフェイスとうまく組み合わせて、それらをチップレベルで統一することを試みる（図６８に示されるように）。従って、テストインターフェイスの柔軟性および修正可能性が、テストアクセスおよび制御メカニズムを設計および検証し、かつ、チップ１／０により、ブロックレベルのテスト量（ｂｕｄｇｅｔ）内でテストをパッケージ化するために提供されるべきである。本発明に関連する当業者に理解されるように、テストバスの一部分としてのオンチップバス（ＯＣＢ）の利用は、本記載の範囲を超えるが、本発明によって考慮される。
【０３７６】
（マージ可能でないブロック）
ＤＦＴ論理およびテストベクトル検証機能は、設計者をより短く実行させ、すなわち、生産サイクルにおいて生産準備テストをより早くする。ＤＦＴスキャンパスは、他の点では利用可能でないチップおよびシステム状態へのアクセスを提供する。メモリＢＩＳＴはアルゴリズムテストベクトルを利用して、異なる組み込みメモリフォルトクラスをカバーする。論理ＢＩＳＴは、スキャンベースの設計のランダムなテスト可能構造の利点を利用して、テストアクセスおよびテストデータ障害を低減する。しかし、各事前に設計されたブロックは、多くの理由のためにマージ可能でなくなり得る。一般的に、マージ可能でないブロックは、
内部テストのアクセシビリティ（例えば、ゲートクロック、ラッチベースのデータパス）の欠如、または、フォルト対象範囲（ｃｏｖｅｒａｇｅ）（例えば、非同期式）の欠如のために、共通のテスト方法と互換性がなくてもよい合成可能ＲＴＬソフトブロック。
【０３７７】
スキャンメソドロジー（すなわち、同期式）、スキャンスタイル（例えば、ｍｕｘスキャン、クロックスキャン、ＬＳＳＤ）等の共通のテスト方法と互換性があり得えないゲートレベルのソフトブロック。
【０３７８】
一般的に配列ベースのコンパイルされたブロック。例えば、組み込みＲＡＭ、ＲＯＭ、ＤＲＡＭ、ＦＬＡＳＨ等は、組み合わせ論理と同一のフォルトモデルを有さない。これらのブロックは、大きなアルゴリズムのテストパターンを要求する。
【０３７９】
特定のテスト方法により生成されるが、テスト統合のために利用可能なインフラストラクチャを有しないハードブロック。一般的に、これらのブロックは、好ましくは、特定のテストインターフェイスを有するか、または、有することなく特定のブロックレベルのテストデータにより送達されるべきである。
【０３８０】
特定のテスト方法によってか、または、よらずに生成されるが、統合のためのインフラストラクチャを有するレガシーブロック。一般的に、これらのブロックは、未知の結果を避けるために修正され得ない。
（テストカラー）
ソケット化（ｓｏｃｋｅｔｉｚｅｄ）設計ブロックは、図６６のフローチャートに示されるように、ＳＡＰ仕様によってソケットを記述する新しいモジュールを生成し、オリジナルの設計ブロックをインスタンス化し、それらの間にテスト論理を挿入することによってモデル化され得る。ソケット化設計ブロックは、機能インターフェイスをまず復元し、すなわち、テストアクセス、テストアイソレーション、境界テキスト構造を加え、次いで、それらはチッププラニングの間に定義されるようなベーシックテストインターフェイス（例えば、ＴＡＲスキャン、ＢＳＲ、または、ダイレクトｍｕｘ）を提供する。その結果は、各々に関連するテスト１／０ポートのためのコメントのような付加されたテスト属性を有するＳＡＰである。各マージ可能でないブロックは、テストカラーによって覆われて、ブロック方法（ｂｌｏｃｋ  ｂａｓｉｓ）によってブロック上のテスト設定、テスト実行、および、テスト後処理を実行するためのテストアクセス、アイソレーション、および、相互接続テスト能力（ｆａｃｉｌｉｔｙ）を付加する。出力は、以下を含むソケット設計ブロックである。
【０３８１】
１．テストアクセスおよび制御（例えば、テストモード、起動、および、終了）
２．テストプロトコル（例えば、機能性、ｍｕｘスキャン、ＢＩＳＴ、診断）
３．テストデータ（例えば、テスト言語、ベクトルサイズ、フォルト対象（ｃｏｖｅｒａｇｅ））
４．テスターフォーマット（例えば、テスター仕様、タイムセット、テストスピード）
５．テスト付加時間（例えば、テストのない設定時間）
（テスタビリティの付加）
再利用可能テストデータを備えていない各マージ可能でないブロックに対しては、設計プラニングフェーズは、テスト構造を挿入することによって、テストインターフェイス、テスト方法、テストデータフォーマット、予期されるフォルト対象、および、テスト量を特定し、全領域およびタイミングコストを評価し得る。この評価は、各ブロックにテスタビリティを付加するための制限となる。
（統合可能ＲＴＬソフトブロック）
予め設計されたブロックが、スキャンベースのテストアプリケーションと互換性のない統合可能ソフトブロックである場合、フォルト対象が問題となり得る。例えば、スキャン設計ルールチェックは、ＲＴＬまたはゲートレベルでなされ得、スキャン妨害を排除（ｓｃｒｅｅｎ  ｏｕｔ）する。スキャンチェーンまたはテストポイントが容易にモデルに挿入され得ないので、連続的なＡＴＰＧは、図６７のフローチャートに示されるように、機能テストベクトルと結合して利用され得る。このタイプの設計のためのフォルト対象は、予測するのが難しく、フォルトシミュレーションは、好ましくは、プラニングフェーズの間のそのようなブロックの再利用可能性判断基準を確立するために、利用されるべきである。ＴＢＡベースのテストカラーは、最良のテストインターフェイスであるが、ＢＳＲベースのテストカラーは、ブロックのためのテスト量が許容されるかどうかが考慮され得る。
（検証）
ここでＤＦＴから設計検証に移動すると、ＢＢＤ設計検証の目的は、完全な設計（最終的なテープアウトで）が、フロントエンド許容性の一部分として供給される機能仕様（Ｆｕｎｃｔｉｏｎａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）およびチップテストベンチで明記されるようなカスタマーの機能要件と適合することを保証することである。第２の目的は、可能な最小の時間第１の目的を達成することである。
【０３８２】
任意の設計テストスキーマと同様に、重要なのは、カスタマー提供のチップテストベンチが、カスタマーに要求される機能性の完全なテストを形成することである。この前提は、好ましくは、フロントエンド許容性の一部分としての間で強調され得る。ＢＢＤ設計フローは、それにより、機能仕様モデル上で実行される間にチップテストベンチのグレーディングを組み込み、それにより、チップテストベンチの計測を提供する。
【０３８３】
１つのアプローチでは、統合された態様で機能仕様およびチップテストベンチの両方を利用することにより両者が一貫性を持つことを保証することである。その後、詳細はチッププラニング、チップアセンブリおよびブロック設計によって加えられ、かつ、精錬されるように、設計は、チップテストベンチを介して再検証されて、機能性がオリジナルの機能仕様と一貫性を持ったままであることを保証する。革新的により詳細なビューの検証が、以下に示されるように、完全なチップレベル、または、チップテストベンチから抽出される別個のブロックテストベンチによって各ブロックレベルで実行され得る。
【０３８４】
経験により明らかなのは、バス論理および同一のバスに沿って接続される様々なブロックの相互作用は、解決するための有意な時間を取り得、設計プロセスにおいて、初期および連続的にアドレスされない場合、反復性の再設計を引き起こす。このため、設計サイクルにおいて初期に、バス機能性の検証に対して、特定の注意が与えられる。従って、以下に示されるように、バスコンプライアンステストベンチを用いて、残りの設計に独立して、バスおよび関連するロジックが、初期段階において識別され、かつ検証される。しかし、好ましい検証フローは、高速のターンアラウンドを有する広範囲の設計を操作するために十分な柔軟性がある。例えば、設計が単純なバスを利用する場合、または、設計者がバスに取り付けられるブロックに関して有意義な経験を有する場合、バスコンプライアンステストのいくらかまたは全ては、延期され得る。同様に、ブロックのいくらかまたは全てが、単純または従来設計から再利用される場合、各ブロック検証の一部分は、スキップされ得、かつ、チップレベルの検証段階まで延期された検証に到達する。
【０３８５】
特定の設計に従う詳細なフローは、ＦＥＡプロセスの一部分として確立されるべきである。図１２〜１５は、機能性検証の間に実行され得る好ましいタスクの生成されたフローを提供する。これらの図は、チップテストベンチ図６９〜７３を相互参照して、詳細に記述される。尚、図１２〜１５は、大きな矢印がタスクフローを表わし、より小さい矢印がタスク入力を表わし、破線矢印が選択的なバイパスパスを表わす。
【０３８６】
図１２を参照して、ＦＥＡの終了後に、上述されるように、設計プロセスは、好ましくは、チップテストベンチ検証ステップ８２１０に続き、ここで、チップレベルの機能性モデルは、図６９においてチップテストベンチ８３１０によって機能試験をされる。モデルおよびテストベンチの両方がカスタマー提供され、検証の目的が、テストベンチおよび機能性モデルが一貫することを保証する。モデルは、他のフォーマットも適切であり得るが、好ましくは、Ｖｅｒｉｌｏｇ、ＶＨＤＬ、または、実行可能なＣコードコンピュータファイルの形式である。チップテストベンチ８３１０は、モデルとファイル互換性がある。モデルとテストベンチとの間の任意の不整合は、カスタマーにフィードバックされ、モデルまたはテストベンチのどちらかは、内部整合性を達成するように修正される。
【０３８７】
次に、チップテストベンチは、機能性モデル上で実行する間にグレード付けされる。このようなグレーディングは、以下の属性の１つ以上を計測することによって、テストベンチの「良好な状態」計測、または対象メトリック（ｃｏｖｅｒａｇｅ  ｍｅｔｒｉｃ）を提供する。すなわち、ステートメント対象、切り替え対象、ＦＳＭアーク対象、訪問された状態対象、ペアアーク対象、パス／ブランチ対象、および／または、表現対象。この対象メトリックは、その後、カスタマーにフィードバックされる。対象メトリックは、設計が不十分にテストされた、または、設計が冗長な機能を含むような、テストが乏しいと思われる設計の領域をハイライトし得る。いずれの場合においても、カスタマーは、対象メトリックを改良するために、テストベンチまたはモデルを修正するように選択し得、それにより、本明細書中に記載されるＢＢＤ設計メソドロジーのためのプロジェクト開始時間をリセットする。
【０３８８】
一旦、チップテストベンチが機能性モデルと一貫性を持つことが認定されると、チップの新しいビュー８３１２（図６９）が、これらのブロックの間の定義されたグル（ｇｌｕｅ）論理を有する各ブロックのためのブロック機能性モデルを結合することによって、（図１２の）ステップ８２１２において生成される。ブロック機能性モデル８３１２は、上述されたように、カスタマー提供されるか、または、ＦＥＡの間に「浸す（ｄｉｐｐｉｎｇ）」プロセスを介して生成されるかのどちらかである。グル論理モデルはまた、上述されたようにチッププラニングの間に特定される。
【０３８９】
図１２を再び参照して、チップレベルの構造上の検証ステップ８２１４は、チップテストベンチによるチップのブロック機能性モデルをシミュレートするステップを包含する。任意の矛盾は、ブロック機能性モデル８３１２またはグル論理モデルを１つ以上を修正し、かつ、シミュレーションに戻ることによって解消される。このステップは、ブロック機能性モデルがチップ機能性モデルと一貫性を持つことを保証する。
【０３９０】
次に、図１３および１４に戻って、バス検証フローの目的は、チップ内のバス論理が、正確に動作し、かつ、異なるバス要素の間の相互作用が、バスプロトコルエラーを引き起こさないことを保証することである。従って、整合性ベクトルは、バス設計のために生成される。これらのベクトルは、カスタマーまたはブロック設計提供者によって提供される整合性テスト一式に基づき得る。ベクトルは、設計の特定のバストポロジーに対応するように操作されなくてはならない。整合性ベクトルが提供され得ない場所では、それらは、設計チームによって書かれ、好ましくは、バスに取り付けられた様々なブロックの相互作用を機能試験するような態様で、全ての境界条件を機能試験し、かつ、バスエラーが正確に操作されていることを保証しなくてはならない。
【０３９１】
図１３におけるステップ８２１８は、バス機能性の検証を提供する。バス整合性ベクトルは、上述されるようなチッププラニング段階から提供されるバスのサイクルの正確な（ｃｙｃｌｅ−ａｃｃｕｒａｔｅ）モデルに逆らってシミュレートされる。任意のエラーは、整合性ベクトルセット（示されない）を修正するか、または、図７０に示される１つ以上のバス論理エレメント８５１２を修正するかのどちらかによって、解消されなくてはならない。このステップは、整合性テスト一式がバス論理モデル上で首尾よく実行するまで繰り返される。
【０３９２】
次に図１４を参照して、バスブロックモデルおよびテストベンチ生成ステップ８６１０から８６１４が、図示される。バスブロックモデル生成ステップ８６１０およびテストベンチ生成実行ステップ８６１２、ならびに、バスブロックモデル検証ステップ８６１４の両方の目的は、ハイレベルの挙動モデルおよび設計内の各ブロックに対する関連するテストベンチを生成することである。これらは、ブロック設計者までパスし、かつ、各ブロックのためのターゲット機能性を規定する。
【０３９３】
各ブロックのための図７０におけるバスブロックモデル８５１０を生成するステップは、機能的に正確であり、サイクルの近似したブロック機能性モデル８３１２を、そのブロックに対するサイクルの正確なバス論理モデルと結合するステップを包含する。バス論理は、チッププラニングから提供されるバスグル論理モデルから抽出され、上記のように検証される。バス機能性モデルのいくらかの改変は、「位置合わせ」するためのインターフェイスを得るために要求され得る。
【０３９４】
バスブロックモデルは、その後、バスブロックモデルの全てを結合するチップのモデルを組み立てることによって、検証され得る。チップモデルは、その後、チップテストベンチによってそれをシミュレートすることによって検証される。チップテストベンチが、前述のようにサイクル近似モデル上で検証される一方で、チップのこの挙動ブロックモデルは、いくらかのサイクルの正確な操作を有し、チップテストベンチのいくらかの精錬が、ブロックモデルをパスさせるために必要とされる。いくつかの場合では、ブロック機能性モデルおよびバス論理における不整合のためにエラーが生じ得、このとき、このモデルは、そのエラーを訂正するために修正され得る。一旦、チップテストベンチが、このチップモデル上で首尾よく実行されると、各バスブロックモデルは、詳細な実装のためにブロック設計者に送られ得る。
【０３９５】
図１４のステップ８６１２において、ブロックテストベンチが抽出される。一旦、図７１に示されるように、チップテストベンチは、チップレベルのバスブロックモデル８７１０上で首尾よく実行されると、プローブが、各ブロックのインターフェイス上にセットされ得、ブロックテストベンチは、モデル上で実行されるようにチップテストベンチ８７１２から抽出され得る。これらのブロックテストベンチは、実装を介して進行するようなブロックの検証のために、ブロック設計者に送られる。
【０３９６】
次に図１５において示される論理的検証フローに進んで、論理的検証タスクの目的は、（ＲＴＬからプレレイアウトネットリスト、ポストレイアウトネットリストまで）設計の実装フェーズを介して進行するように、各ブロックが機能的に正確であることを保証することである。また、組み込みチップが必要とされる機能性を提供し続けるかどうかがテストされる。
【０３９７】
検証は、機能性シミュレーションによって動的に行われ得るか、または、同等のチェックを実行する正式な検証ツールを利用して静的に行われ得る。動的な検証は、一般的に、本明細書中の他で述べられるシミュレーションツールを要求する。動的な検証はまた、他で利用されるベクトルセットを利用し、そして、事実上の近時サイクルから正確なサイクルまでのテスト一式の移動に役立つ。静的な検証は、新しいツールの包含を要求する。しかし、静的な検証は、シミュレーションと対比して、典型的には、シミュレーションよりも高速に実行され、「完全に」同等のチェックを提供し、そのことは、テストベンチが設計機能性を機能試験する範囲と同等な範囲のみを検証する。
【０３９８】
次に、各ＲＴＬブロックモデルは、ステップ８７１０において検証され、ここで、ブロック設計者によって生成されるＲＴＬシミュレーションモデルは、チップテストベンチに反して検証される。これは、ブロックＲＴＬモデルをチップレベルの挙動モデルにおける対応する挙動モデルとスワップし、かつ、完全なチップテストベンチを用いてチップの混合モードシミュレーションを実行することによって実施され得る。もしくは、各ブロックＲＴＬモデルは、抽出されるブロックテストベンチによってシミュレートされ得る。いずれの場合でも、サイクル近似モデルからサイクルの正確なモデルまでの遷移のために、不整合が予測され得る。これらの不整合は、テストベンチを修正することによって、解消され得る。不足または不正確な機能性によって不整合が引き起こされる場合、ＲＴＬモデルは、エラーを訂正するように修正されなくてはならない。
【０３９９】
ステップ８７１２において、ＲＴＬブロックモデルは、チップレベルで検証される。各ブロックのためのＲＴＬシミュレーションモデルは、チップレベルのＲＴＬモデルを生成するように結合される。このモデルは、チップテストベンチによってシミュレートすることによって検証される。再び、いくらかのエラーが、サイクル近似モデルからサイクルの正確なモデルまでの遷移のために存在し得る。これらのエラーは、チップテストベンチを修正することによって解消される。任意の機能性エラーは、１つ以上のブロックレベルのＲＴＬモデルを修正することによって、解消されなくてはならない。
【０４００】
ステップ８７１４において、各プレレイアウトブロックネットリストが検証される。各ブロックのためのポスト統合ネットリストシミュレーションモデルは、このブロックのためのＲＴＬモデルに逆らう。
【０４０１】
ステップ８７１６において、動的および静的チップレベルのプレレイアウトブロックネットリストは、検証される。動的な検証は、ブロックレベルのポスト統合ネットリストをチップレベルの挙動モデルにおける対応する挙動モデルとスワップし、かつ、完全なチップテストベンチを利用してチップの混合モードシミュレーションを実行することによって、実行され得る。もしくは、各ブロックレベルのポスト統合ネットリストは、ブロックテストベンチによってシミュレートされ得る。いずれの場合においても、サイクルの正確なモデルからサイクル内（ｉｎｔｒａ−ｃｙｃｌｅ）タイミングを有するモデルまでの遷移のために、再び、不整合が予期され得る。これらの不整合は、テストベンチ内のタイミングストロボを修正することによって解消される。静的な検証は、ポスト統合ネットリストおよび各ブロックのためのＲＴＬモデル上で同等のチェックツールを実行することによって、実行される。不整合は、ＲＴＬモデルと整合させるためにポスト統合ネットリストを修正することによって、解消する。
【０４０２】
各ブロックのためのポスト統合ネットリストは、その後、チップポスト統合ネットリストを生成するように結合される。このチップレベルのネットリストは、シミュレーションを介してか、または、正式な同等のチェックツールを介して静的かのどちらかで検証される。動的な検証は、チップテストベンチによってチップポスト同等のネットリストをシミュレートすることによって、達成される。静的なチップレベルのプレ例アプと検証は、チップポスト同等のネットリストおよび各ブロックのためのチップＲＴＬモデル上の同等なチェクツールを実行することによって、実行される。
【０４０３】
ステップ８７１８において、各ポストレイアウトブロックネットリストは、検証される。このステップは、ステップ８７１４の繰り返しであるが、ポストレイアウトネットリストは、プレレイアウトネットリストに対して置換された状態である。ネットリストレベルでのこれらの２つのモデルの差異は、バッファの修正のみであるであるべきであり、設計のレイドアウト（ｌａｉｄ−ｏｕｔ）のタイミングゴールを達成するために強度をドライブするべきである。発生する任意のエラーは、バッファの不正確な追加または削除に限定されるべきである。ブロックテストベンチのタイミングは、ポストレイアウトタイミング変更が、タイミングストロボに関連して信号を移動させた場合に、修正されなければならなくなり得る。
【０４０４】
この検証は、静的または動的のどちらかで実行され得る。動的な検証は、ブロックレベルのポストレイアウトネットリストをチップレベルのＲＴＬモデルの対応するブロックＲＴＬモデルとスワップし、完全なチップテストベンチを利用してチップの混合モードシミュレーションを実行することによって、実行され得る。あるいは、各ブロックレベルのポストレイアウトネットリストは、ブロックテストベンチによってシミュレートされ得る。静的な検証は、ポストレイアウトネットリストおよび各ブロックのためのＲＴＬモデル情の同等なチェックツールを実行することによって、実行される。不整合は、ＲＴＬモデルと整合するためにポスト統合ネットリストを修正することによって、解消される。
【０４０５】
チップレベルのポストレイアウトネットリストの検証は、ステップ８７２０、すなわちステップ８７１６の繰り返しにおいて達成されるが、ポストレイアウトチップレベルのネットリストは、プレレイアウトネットリストに対して置換された状態である。ネットリストレベルでのこれらの２つのモデルの差異は、バッファの修正のみであるべきであり、設計のレイドアウトのタイミングゴールを達成するために強度をドライブする。発生する任意のエラーは、バッファの不正確な追加または削除に限定されるべきではない。動的な検証は、チップテストベンチによって、チップポストレイアウトネットリストをシミュレートすることによって達成される。静的な検証は、チップポストレイアウトネットリストおよびチップＲＴＬモデル上で同等のチェックツールを実行することによって、実行される。不整合は、ＲＴＬモデルと整合するために、ポストレイアウトネットリストを修正することによって解消する。
【０４０６】
最終的に、物理的検証が、図７２および７３に図示されるように達成され、ここで、ブロックおよびチップテープアウトの両方は、本発明に関連する分野の当業者によって理解される態様で、検証される。物理的検証タスクの目的は、ブロック設計によって生成されたＧＤＳＩＩファイル、および、設計のチップアセンブリフェーズが、機能的に正確であり、かつ、対象技術のための設計ルールの任意の妨害から自由であることを検証することである。
【０４０７】
ブロック設計プロセスによって生成される各ブロックのためのＧＤＳＩＩは、ターゲット技術に対してＤＲＣを実行することによって、検証される。任意のエラーおよび警告は、決断のためにブロック設計者にフィードバックされる。ＬＶＳはまた、ブロックＧＤＳＩＩフィアルとブロックのためのポストレイアウトネットリストとの間で実行される。任意のエラーまたは警告は、決断のためにブロック設計者にフィードバックされる。
【０４０８】
チップアセンブリプロセスによって生成される完全なチップためのＧＤＳＩＩは、ターゲット技術に対してＤＲＣを実行することによって、検証される。任意のエラーおよび警告は、決断のためにチップアセンブリ設計者に送り返される。ＬＶＳはまた、チップＧＤＳＩＩフィアルとチップのためのポストレイアウトネットリストとの間で実行される。任意のエラーまたは警告は、決断のためにチップアセンブリ設計者にフィードバックされる。
（プログラム可能ファブリックおよびデリバティブ設計）
プログラム可能ファブリックは、ブロックベース設計における特別な制限を要求し得、それらの多くは、既に本明細書中に詳細が記述された。プログラム可能ファブリックはまた、デリバティブ設計のコンテクストにおいてある利点を提供し得、ブロックベースのメソドロジーは、これらの利点の特定の利点を得るように適用され得る。
【０４０９】
ファブリック（プログラム可能およびプログラム不可能）の利用の概念的な観点は、図７５〜８０に提供される。図７５は、ファブリックへ組織化される回路設計３５０のレイアウトの例を表わす。図７５に示される例では、プラットフォームカーネル３５１は、一般的に、標準的なセル技術を利用して構築され（および、従ってまたファブリックを考慮され得る）、事前に硬化された、または、硬いブロックであり得る。図７５に示される回路設計３５０は、さらに、スクラッチメモリブロック３５３および標準的なセルブロック３５２（それらの両方はまた、ファブリックとして考慮され得る）、ならびに、任意のタイプの回路（例えば、標準的なセル、カスタム、ＭＰＧＡ、ＦＰＧＡ等）であり得る様々なファブリック３５４、３５５、３５６を含む。
【０４１０】
本明細書中に既に記述された様々な技術によると、回路設計３５０は、フロントエンド許容性プロセス、チップ設計プラニングプロセス、ブロック設計プロセス、チップアセンブリプロセス、および、検証プロセスを前提とし得る。これらのプロセスの一部分として、プラットフォームカーネルを含む様々なファブリックは、フロアプラン（ｆｌｏｏｒｐｌａｎ）に適切に捕まえられ（ｃｏｌｌａｒｅｄ）、配置される。ファブリックは、その後、例えば図７６に概念的に示されるように、相互接続される。その後、好ましくはプログラム可能性の順で、ファブリック相互接続論理は生成され得、ファブリックは実装され得る。カラーリング（ｃｏｌｌａｒｉｎｇ）プロセスの一部分として、好ましくは、完成された設計および実際の製造されたチップのテストを促進するように、境界スキャンテスト論理が含まれる。図７８は、概念的に、回路設計において利用され得る階層的テスト論理構成を示し、ここで、単一のテストアクセスポート（ＪＴＡＧ準拠コントローラ等によって）である。また、カラーリングプロセスの間に、本明細書中で既に述べられたように、プログラミングポートアクセスはまた、好ましくは、事実上プログラム可能であるファブリックに対して提供される。
【０４１１】
ここで、図７８をより詳細に見ると、標準のテストアクセスポートおよびコントローラ（ＪＴＡＧコントローラ等）を用いて、図７５に示される回路設計３５０のための階層的テスト回路レイアウトが図示される。図７８に示されるように、最上位レベルＪＴＡＧコントローラ３６０は、外部アクセスが提供された状態で、回路設計３５０に提供される。ファブリック３５４、３５５および３５６の各々は、それら専用のテストコントローラ３７７、３７６および３７８がそれぞれ提供され得、プラットフォームカーネル３５１はまた、それ専用のテストコントローラを提供され得る。サブレベル回路ブロック（例えば、プラットフォームカーネル３５１は、３つの小さなブロック３６１、３６２、３６３を含むように示され、あるファブリック３５５は、３つの小さなブロック３６７、３６８、３６９を含むように示される）回路ブロックに対して、さらなるテストコントローラが、各レベルに配置され、かつ、階層に組織化され得る。階層的なテスト回路レイアウトの構築に関するさらなる詳細は、例えば、本明細書中に完全に示されるように参照として援用される、２００１年１月１８日に出願された「Ｈｉｅｒａｒｃｈｉｃａｌ  Ｔｅｓｔ  Ｃｉｒｃｕｉｔ  Ｓｔｒｕｃｔｕｒｅ  ｆｏｒ  Ｃｈｉｐｓ  ｗｉｔｈ  Ｍｕｌｔｉｐｌｅ  Ｃｉｒｃｕｉｔ  Ｂｌｏｃｋｓ」と称する同時係属中の米国特許出願第０９／７６５，９５８号において述べられる。
【０４１２】
フロアプラニングに関連して、前述されたように、プログラム可能ファブリックは、プログラム可能ファブリックを形成し、かつ、サイズ処理をするためのオプションを制限し得るフロアプラニングがタイル配置に基づくことを要求し得る。プログラム可能ファブリックはまた、階層的ルーティングを要求し得る。いくらかの点では、回路設計３５０のクロッキングおよびタイミング分析が、望ましくなる。図７７に示されるように、機能性テスト（ＰＬＬ）モジュールは、クロッキングおよびタイミング分析を促進するために有利に利用され得る。タイミング分析のために、様々な各ブロック（ファブリック）は、「ブラックボックス」として本質的に扱われ得、従って、タイミングの立場からもう一方と分離され得る。クロックは、好ましくは、最上位レベルで分配され、クロックの遅延は、好ましくは、様々な異なるファブリックにおいて整合するように調節される。ファブリック内（ｉｎｔｅｒ−ｆａｂｒｉｃ）ゆがみは、タイミング分析の一部として計算され得る。
【０４１３】
電力分析はまた、ブロックベースの設計プロセスの一部として処理され得る。図７９は、様々な内部ファブリックを含む回路ブロックの電源設計を概念的に表わす図である。特定のファブリックの電力を決定するために、シミュレーションは、ある電力消費量評価に達するように実行され得る。プログラム可能ファブリックに対して、電力消費量は、第１の場合では、必要なプログラミング電力の評価に基づき得る。プログラミング可能ファブリックのための電力消費量は、好ましくは、通常の操作、および、回路が動作している際にファブリックがアクティブにプログラムされる間の時間の両方に対して決定される。図７９に概念的に示されるように、各ファブリックは、好ましくは、チップ電力および接地ラインに相互接続される電力および接地ワイヤによって取り囲まれる。別々の電力は、特に残りのチップ（例えば、ＦＰＧＡを有する）と異なる電圧レベルで実行される場合、プログラム可能ファブリックに対して供給され得る。
【０４１４】
プログラミングアクセスはまた、ブロックベースの設計プロセスの一部として処理される。図８０は、１つ以上のプログラミング可能ファブリックを含む回路ブロックのためのプログラミングアクセスの包含の例を示す概念図である。プログラミングアクセスは、一般的には、外部（Ｉ／Ｏ）ピンまたは内部バスを介して提供され得る。どちらかの場合には、プログラミングアーキテクチャは、好ましくは、図８０に概念的に示されるように、分析のために開発される。
【０４１５】
プログラミング可能ファブリックは、オリジナルの回路設計に基づく派生した（ｄｅｒｉｖａｔｉｖｅ）設計の生成において、特定の利点を提供し得る。１つのこのような利点は、例えば、多くのオリジナルの回路構成が再利用されるので、市場に対する高速な時間である。図８５および８６は、プログラム可能ファブリックを利用した派生的な設計プロセスを集団的に図示する。派生的な設計と関連する図８６は、完全なオリジナルの回路設計にとってより対象となる図１と対比され得る。図８６のプロセスフローに示され得るように、派生的な設計プロセス５５０は、オリジナルの下回路設計プロセスにおいて利用される多くのステップを省略する。フロントエンド許容性ステップ５５１は、好ましくはさらに実行されて、以前の様に、オリジナルの回路設計の派生は、必要な設計ゴールに適合することを保証する。チッププラニングステップ５５２が、好ましくは実行されるが、チップレイアウトが必然的に最利用される必要がないので、著しく促進され得る（派生物がオリジナルの回路設計に対するプログラミング改変だけに基づくかどうかに依存する）。しかし、タイミング管理（ｔｉｍｉｎｇ  ｂｕｄｇｅｔｉｎｇ）および分析ステップ５５４は、好ましくは、派生的な設計が、確実に適用可能なタイミング要件と適合するように実行される。プログラミングステップ５５７が加えられ、ここで、プログラム可能ファブリックのためのプログラミングが開発される。このようなプログラミングステップはまた、同様にオリジナル回路設計を含み得るが、それに付随する図において明確に示されていない。検証ステップ５５９がまた、前述のように含まれる。
【０４１６】
図８５は、派生的な設計がブロックに基づく設計方法論を利用して開発され得る方法の例を示す。プラットフォームカーネル５０１は、ＦＰＧＡコア５０６等のプログラム可能ファブリックを提供され得る。ＦＰＧＡコア５０６の一部分は、いくらかの点においてメタライズされ得、その結果、図８５に示されるように、第１の派生的な回路設計５２０が生じる。メタライゼーションは、一般的に、ハードウェアに関連するプロセスである。すなわち、メタライゼーションの例は、図８７に示され、ここで、ハードウェアパターンを繰り返しは、ＭＰＧＡコアの一部分全体にわたって重複する。その後、さらに図８５に示されるように、ＦＰＧＡコア５０６’のメタライズされた一部分５０９の機能性プログラミングが実行され、その結果、完全にプログラムされたＭＰＧＡコア５０６’’を有する第２の派生的な回路設計５３０を発生させる。各新規の派生的な設計に進む場合、新規の機能性だけが（およびそれによって影響を受けるもの）は、設計され、テストされる必要がある。すなわち、オリジナルの回路設計の残りは、原型のままであり、従って、より高速な設計ターンアラウンド時間が許される。多くの厳密なテストは、オリジナルの回路設計に対して保存され得る。
【０４１７】
図８１は、前述の原理が適用され得るＭＰＧＡコアを含む様々なファブリックを含む、回路ブロックの例を示すより詳細な図である。図８２は、メタライゼーションおよび／またはＭＰＧＡコアのプログラミングによって、図８に示される回路ブロックから導き出される派生的な回路ブロックの例を示す図である。
【０４１８】
より概念的な観点から、ハードウェアプログラミングに基づくプログラム可能なファブリックにおける特定の機能を開発することによって、第１の派生的な設計が到達され得る。第１の派生的な設計においてプログラミングされたハードウェアの処理を介して、付加的なよりハイレベルの機能をプログラミングすることによって、第２の派生的な設計が到達され得る。このようなプロセスの例として、第１の派生的な設計は、例えば、「一般的な」携帯電話のための回路設計であり得る。第２の派生的な設計のセットは、例えば、特定の領域（北アメリカ、ヨーロッパ、ラテンアメリカ等）に特定、または、特定の言語に特定であり得る携帯電話のための回路設計であり得る。派生的な設計プロセスは、開始プラットフォームなどの派生的な設計を共通に有する機能を実行するために、完成した回路設計を高速に生成するための方法を提供する。
【０４１９】
本発明は、図および前述の説明において詳細に図示され、かつ、記述されたが、理解されるべきは、本発明は、本発明の意図内で代替の実施形態によって実装され得ることである。従って、本発明の範囲は、本明細書中の図および説明に制限されることは意図されないが、付属の特許請求の範囲によって規定されるべきである。
【図面の簡単な説明】
【０４２０】
【図１】図１は、本明細書で開示されたような好適な実施形態による、ブロックベースの設計方法論に基づいて設計プロセスを示すフローチャートである。
【図２】図２は、図１に示された設計プロセスにおいて使用され得るように、フロントエンド承認の好適なステップを示すフローチャートである。
【図３】図３は、クロック計画モジュールを示す。
【図４】図４は、バス識別および計画モジュールを示す。
【図５】図５は、電力計画モジュールを示す。
【図６】図６は、Ｉ／Ｏおよびアナログ混合信号要求を導くための技術を示す。
【図７】図７は、テスト計画モジュールを示す。
【図８】図８は、タイミングおよびフロア計画モジュールを示す。
【図９】図９は、ブロック設計のメタフローを示す。
【図１０】図１０は、チップアセンブリのデータフローを示す。
【図１１】図１１は、チップアセンブリのタスクフローを示す。
【図１２】図１２は、機能的検証フローを示す。
【図１３】図１３は、機能的検証フローを示す。
【図１４】図１４は、機能的検証フローを示す。
【図１５】図１５は、機能的検証フローを示す。
【図１６】図１６は、複数の予め設計された回路ブロックを用いて回路設計の実現可能性を評価する方法論を示す。
【図１７】図１７は、図２に示された方法論を用いて実現可能な評価の結果を示す。
【図１８】図１８は、複数の予め設計された回路ブロックを用いて回路設計の実現可能性を評価する方法論を示す。
【図１９】図１９は、図１８に示された方法論を用いて実現可能な評価の結果を示す。
【図２０】図２０は、フロントエンド承認（「ＦＥＡ」）処理の例を示す。
【図２１】図２１は、改良処理を示す。
【図２２】図２２は、例示的な評価補正曲線を示す。
【図２３】図２３は、ＦＥＡを妥当化する処理を示す。
【図２４】図２４は、ＦＥＡ設計特性改良処理を用いて改良された推定補正曲線を示す。
【図２５】図２５は、ＦＥＡデータ抽出プロセスを示す。
【図２６】図２６は、ブロック推定改良に対する必要性を識別する処理を示す。
【図２７】図２７は、ＦＥＡ評価軸基準を示す。
【図２８】図２８は、分類崩壊曲線を示す。
【図２９】図２９は、回路設計における複数の設計ブロックを示し、グルー論理は、最適な設計ブロック配置とインターフェースを取る。
【図３０】図３０は、第１のタイプのグルー論理分散を示す。
【図３１】図３１は、第２および第３のタイプのグルー論理分散を示す。
【図３２】図３２は、回路ブロックをカラーに埋め込むためのカラーリングプロセスを示す。
【図３３】図３３は、ブロックの抽象物の完全なセットを作成する場合のステップを示す。
【図３４】図３４は、カラーリングプロセスを示すフローチャートである。
【図３５】図３５は、２つの層を有するカラーを示す。
【図３６】図３６は、カラーと回路ブロックとの間の論理の図を示す。
【図３７】図３７は、カラーと回路ブロックとの間の物理的な図を示す。
【図３８】図３８は、図３４に示されたようなカラーリングプロセスを用いることなくシステム設計を示す。
【図３９】図３９は、カラーリングプロセスを用いるシステム設計を示す。
【図４０】図４０は、図３４のカラーリングプロセスにおけるステップを実行するためのコンピュータシステムを示す。
【図４１】図４１は、バス識別および計画の概要のための一連の好適なステップを示す。
【図４２】図４２は、本明細書中で開示されているような一実施形態に従って構成された挙動モデルの相互接続部の内部構造を示す。
【図４３】図４３は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図４４】図４４は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図４５】図４５は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図４６】図４６は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図４７】図４７は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図４８】図４８は、本明細書中で開示されているような種々の実施形態と共に使用され得るバスブリッジを示す。
【図４９】図４９は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５０】図５０は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５１】図５１は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５２】図５２は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５３】図５３は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５４】図５４は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５５】図５５は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５６】図５６は、本明細書中で開示されているような種々の技術を用いてインプリメントされたバス改変によって改善された遅延時間を示す表である。
【図５７】図５７は、別のバスブリッジを示す。
【図５８】図５８は、ＦＩＦＯを含むバスブリッジを示す。
【図５９】図５９は、種々のバスタイプのためのバス利用率および遅延特性を示す表である。
【図６０】図６０は、例示的な一貫性チェックの真理値表を示す。
【図６１】図６１は、本発明の方法を用いてＤＦＴの観点からチップの上位レベル階層を示す。
【図６２】図６２は、機能的ブロックおよびソケットアクセスポート（「ＳＡＰ」）から構成された設計を示す。
【図６３】図６３は、種々の設計アーキテクチャのための適切なテスト方法を示す表である。
【図６４】図６４は、本明細書中で開示されたような一実施形態による上位レベルのアーキテクチャ仕様手順を示すフローチャートである。
【図６５】図６５は、ソケット化の手順を示す。
【図６６】図６６は、ブロックレベルテスト開発手順を示す。
【図６７】図６７は、チップレベルテスト開発手順を示す。
【図６８】図６８は、計画からチップアセンブリへのテストフローを示す。
【図６９】図６９は、フロントエンド承認検証ツールの設計者の図を示す。
【図７０】図７０は、チップ計画からブロック設計に移行する設計者の図を示す。
【図７１】図７１は、バスブロックモデルおよびテストベンチ発生を導く設計者の図を示す。
【図７２】図７２は、ブロックテストベンチおよびチップテストベンチの設計者の図を示す。
【図７３】図７３は、ブロックおよびチップ論理検証モデルの設計者の図を示す。
【図７４】図７４は、プログラム可能ではない回路構成およびプログラム可能な回路構成の種々の異なるタイプのゲート当たりの（サイクル時間の）速度および領域を比較するグラフである。
【図７５】図７５は、回路ブロックの例を示し、回路設計の観点からファブリックの概念を示す図である。
【図７６】図７６は、図７５において示された回路ブロックのコンポーネントの相互接続を概念的に示す図である。
【図７７】図７７は、回路ブロックの機能的テストを概念的に示す図である。
【図７８】図７８は、図７５に示された回路ブロックのためのテスト回路レイアウトを示す概念図である。
【図７９】図７９は、種々の内部コンポーネントを含む回路ブロックの電源設計を概念的に示す図である。
【図８０】図８０は、１つ以上のプログラム可能なコンポーネントを含む回路ブロックに対するプログラミングアクセスを含む例を示す概念図である。
【図８１】図８１は、種々のファブリックを含む回路ブロックの例を示すより詳細な図である。
【図８２】図８２は、図８１に示された回路ブロックから導かれた誘導回路ブロックの例を示す図である。
【図８３】図８３は、設計者が選択し得るいくつかの種々の異なるファブリック特性を比較する図である。
【図８４】図８４は、種々の有効なアスペクト比を示す、形状が調整可能であるプログラム可能な回路ブロックの可能なフットプリントの簡単な例を示す図である。
【図８５】図８５は、プログラム可能なファブリックを用いて誘導設計プロセスを示す概念図である。
【図８６】図８６は、誘導設計プロセスのための処理フローチャートである。
【図８７】図８７は、金属プログラム可能なゲートアレイ（ＭＰＧＡ）の例を示す図である。
【図１】
2004531056.tif 000004
【図２】
2004531056.tif 000005
【図３】
2004531056.tif 000006
【図４】
2004531056.tif 000007
【図５】
2004531056.tif 000008
【図６】
2004531056.tif 000009
【図７】
2004531056.tif 000010
【図８】
2004531056.tif 000011
【図９】
2004531056.tif 000012
【図１０】
2004531056.tif 000013
【図１１】
2004531056.tif 000014
【図１２】
2004531056.tif 000015
【図１３】
2004531056.tif 000016
【図１４】
2004531056.tif 000017
【図１５】
2004531056.tif 000018
【図１６】
2004531056.tif 000019
【図１７】
2004531056.tif 000020
【図１８】
2004531056.tif 000021
【図１９】
2004531056.tif 000022
【図２０】
2004531056.tif 000023
【図２１】
2004531056.tif 000024
【図２２】
2004531056.tif 000025
【図２３】
2004531056.tif 000026
【図２４】
2004531056.tif 000027
【図２５】
2004531056.tif 000028
【図２６】
2004531056.tif 000029
【図２７】
2004531056.tif 000030
【図２８】
2004531056.tif 000031
【図３０】
2004531056.tif 000032
【図３２】
2004531056.tif 000033
【図３３】
2004531056.tif 000034
【図３５】
2004531056.tif 000035
【図３６】
2004531056.tif 000036
【図３７】
2004531056.tif 000037
【図３８】
2004531056.tif 000038
【図４０】
2004531056.tif 000039
【図４１】
2004531056.tif 000040
【図４２】
2004531056.tif 000041
【図４３】
2004531056.tif 000042
【図４４】
2004531056.tif 000043
【図４５】
2004531056.tif 000044
【図４６】
2004531056.tif 000045
【図４７】
2004531056.tif 000046
【図４８】
2004531056.tif 000047
【図４９】
2004531056.tif 000048
【図５０】
2004531056.tif 000049
【図５１】
2004531056.tif 000050
【図５２】
2004531056.tif 000051
【図５３】
2004531056.tif 000052
【図５４】
2004531056.tif 000053
【図５５】
2004531056.tif 000054
【図５６】
2004531056.tif 000055
【図５７】
2004531056.tif 000056
【図５８】
2004531056.tif 000057
【図５９】
2004531056.tif 000058
【図６０】
2004531056.tif 000059
【図６１】
2004531056.tif 000060
【図６２】
2004531056.tif 000061
【図６３】
2004531056.tif 000062
【図６４】
2004531056.tif 000063
【図６５】
2004531056.tif 000064
【図６６】
2004531056.tif 000065
【図６７】
2004531056.tif 000066
【図６８】
2004531056.tif 000067
【図６９】
2004531056.tif 000068
【図７０】
2004531056.tif 000069
【図７１】
2004531056.tif 000070
【図７２】
2004531056.tif 000071
【図７３】
2004531056.tif 000072
【図７４】
2004531056.tif 000073
【図７５】
2004531056.tif 000074
【図７６】
2004531056.tif 000075
【図７７】
2004531056.tif 000076
【図７８】
2004531056.tif 000077
【図８０】
2004531056.tif 000078
【図８１】
2004531056.tif 000079
【図８２】
2004531056.tif 000080
【図８３】
2004531056.tif 000081
【図８５】
2004531056.tif 000082
【図８６】
2004531056.tif 000083
【図８７】
2004531056.tif 000084
【国際公開パンフレット】
2004531056.tif 000085
2004531056.tif 000086
2004531056.tif 000087
2004531056.tif 000088
2004531056.tif 000089
2004531056.tif 000090
2004531056.tif 000091
2004531056.tif 000092
2004531056.tif 000093
2004531056.tif 000094
2004531056.tif 000095
2004531056.tif 000096
2004531056.tif 000097
2004531056.tif 000098
2004531056.tif 000099
2004531056.tif 000100
2004531056.tif 000101
2004531056.tif 000102
2004531056.tif 000103
2004531056.tif 000104
2004531056.tif 000105
2004531056.tif 000106
2004531056.tif 000107
2004531056.tif 000108
2004531056.tif 000109
2004531056.tif 000110
2004531056.tif 000111
2004531056.tif 000112
2004531056.tif 000113
2004531056.tif 000114
2004531056.tif 000115
2004531056.tif 000116
2004531056.tif 000117
2004531056.tif 000118
2004531056.tif 000119
2004531056.tif 000120
2004531056.tif 000121
2004531056.tif 000122
2004531056.tif 000123
2004531056.tif 000124
2004531056.tif 000125
2004531056.tif 000126
2004531056.tif 000127
2004531056.tif 000128
2004531056.tif 000129
2004531056.tif 000130
2004531056.tif 000131
2004531056.tif 000132
2004531056.tif 000133
2004531056.tif 000134
2004531056.tif 000135
2004531056.tif 000136
2004531056.tif 000137
2004531056.tif 000138
2004531056.tif 000139
2004531056.tif 000140
2004531056.tif 000141
2004531056.tif 000142
2004531056.tif 000143
2004531056.tif 000144
2004531056.tif 000145
2004531056.tif 000146
2004531056.tif 000147
2004531056.tif 000148
2004531056.tif 000149
2004531056.tif 000150
2004531056.tif 000151
2004531056.tif 000152
2004531056.tif 000153
2004531056.tif 000154
2004531056.tif 000155
2004531056.tif 000156
2004531056.tif 000157
2004531056.tif 000158
2004531056.tif 000159
2004531056.tif 000160
2004531056.tif 000161
2004531056.tif 000162
2004531056.tif 000163
2004531056.tif 000164
2004531056.tif 000165
2004531056.tif 000166
2004531056.tif 000167
2004531056.tif 000168
2004531056.tif 000169
2004531056.tif 000170
2004531056.tif 000171
2004531056.tif 000172
2004531056.tif 000173
2004531056.tif 000174
2004531056.tif 000175
2004531056.tif 000176
2004531056.tif 000177
2004531056.tif 000178
2004531056.tif 000179
2004531056.tif 000180
2004531056.tif 000181
2004531056.tif 000182
2004531056.tif 000183
2004531056.tif 000184
2004531056.tif 000185
2004531056.tif 000186
2004531056.tif 000187
2004531056.tif 000188
2004531056.tif 000189
2004531056.tif 000190
2004531056.tif 000191
2004531056.tif 000192
2004531056.tif 000193
2004531056.tif 000194
2004531056.tif 000195
2004531056.tif 000196
2004531056.tif 000197
2004531056.tif 000198
2004531056.tif 000199
2004531056.tif 000200
2004531056.tif 000201
2004531056.tif 000202
2004531056.tif 000203
2004531056.tif 000204
2004531056.tif 000205
2004531056.tif 000206
2004531056.tif 000207
2004531056.tif 000208
2004531056.tif 000209
2004531056.tif 000210
2004531056.tif 000211
2004531056.tif 000212
2004531056.tif 000213
2004531056.tif 000214
2004531056.tif 000215
2004531056.tif 000216
2004531056.tif 000217
2004531056.tif 000218
2004531056.tif 000219
2004531056.tif 000220
2004531056.tif 000221
2004531056.tif 000222
2004531056.tif 000223
2004531056.tif 000224
2004531056.tif 000225
2004531056.tif 000226
2004531056.tif 000227
2004531056.tif 000228
2004531056.tif 000229
2004531056.tif 000230
2004531056.tif 000231
2004531056.tif 000232
2004531056.tif 000233
2004531056.tif 000234
2004531056.tif 000235
2004531056.tif 000236
2004531056.tif 000237
2004531056.tif 000238
2004531056.tif 000239
2004531056.tif 000240
2004531056.tif 000241
【国際公開パンフレット（コレクトバージョン）】
2004531056.tif 000242
2004531056.tif 000243
【国際調査報告】
2004531056.tif 000244