JP2002526908A - ブロックをベースとする設計方法 - Google Patents

Abstract

(57)【要約】 回路システムを設定するために使用されるべき、予め設計された複数の回路ブロックを選択する段階と、経験データ、推定データ、及び／又は実施データを含む、設計者のデータを、予め設計された回路ブロックに関して収集し、前記設計者のデータは、或る処理方法に適合可能である段階と、設計者のデータ及び受入れ可能なリスクの程度に基づいた仕方で、回路システムの設計を許可し又は拒絶する段階と、許可された場合に、回路ブロックの各々に対する判断規準及び修正された制約を含むブロック仕様を形成する段階と、許可された場合に、選択された回路ブロック及び処理方法を変更することなしに、判断規準及び修正された制約に従って、チップのフロアー計画上に回路ブロックを展開するためにブロック仕様を形成する段階を含む、回路システムを設計するための方法及び装置。

Description

【発明の詳細な説明】

【０００１】 （関連出願との相互参照） 本出願は、優先権に関して、1998年９月30日付米国特許出願第60/102,566号“
BLOCK-BASED DESIGN METHODOLOGY”に従属する。

【０００２】 （発明の分野） 本発明は、一般的には集積回路（“ＩＣ”）デバイス設計に関し、特定的には
予め設計済みの回路ブロックを再使用するシステムの設計に関する。

【０００３】 （発明の背景） 近年におけるシリコン処理技術の不断の革新は、集積回路デバイスの価格を激
烈に低下させ、性能及び機能を向上させ、それによってエレクトロニクス製造及
び情報処理産業の開発を刺激してきた。これらの急速に成長する産業自体が、集
積回路設計システム開発者により高速且つ安価なデバイスに関してさらなる要求
を賦課するようになっている。その結果、設計産業は、現在、以下のものを含む
急激な変化に曝されている。

【０００４】 （１）チップ設計は、より大きく且つより複雑になりつつある。例えば、1997
年の典型的な集積回路は100−500Ｋのゲートを含んでいた。1998年の典型的なデ
バイスは１乃至２百万のゲートを含んでいた。1999年における技術はこの傾向の
継続を示しており、４乃至６百万ゲートのデバイスを構築することを目指してい
る。

【０００５】 （２）チップ設計は、より特定用途向けになりつつある。ＩＣ設計の初期の頃
には、デバイス製造者は、エンドユーザが彼等の電子製品内に計画したいろいろ
な“オフザシェルフ”チップを製造していた。現在では、電子製品製造者が特定
機能を遂行させるための特注チップ設計を発注することがより多くなってきてい
る。

【０００６】 （３）現在の電子製品は、主として消費者の要求によって開発されている。こ
れが製品の寿命を短縮させ、従って許容される設計時間及び資源を短縮させてき
た。例えば1987年には、平均設計サイクルは12−18ヶ月であった。1998年にはこ
の平均時間は10−12ヶ月に短縮され、1999年においては当業界は８−10ヶ月の設
計サイクル時間まで短縮することを目指している。

【０００７】 （４）設計時間が制約されているために、並行設計努力を必要とする。以前は
、上流システム成分のための臨界的設計決定は、下流システム成分の設計が検査
されてしまうまで待機させられていた。設計管理者は、最早設計タスクを順次に
遂行するという贅沢さを有していない。幾つかのシステム成分を、同時に開発し
なければならない。従って設計管理者は、少なくとも若干のシステム成分設計が
完了する前に、重大な予測を行うことが要求されるようになってきた。

【０００８】 これらの要望に対処するために、電子システムの設計は、当分野において「ブ
ロックをベースとする設計」（“ＢＢＤ”）として知られている方法に移行しつ
つある。この方法においては、複数の既存成分設計ブロック（当分野では“知的
プロパティブロック”または“ＩＰブロック”と呼ばれている）を統合すること
によってシステムを設計する。これらの予め設計済みのブロックは、内部設計チ
ームから入手することも、または他の設計会社からライセンスを受けることも、
または根本的に異なる設計構造及び環境によって支援されることもできる。更に
、予め設計済みのブロックは、異なる設計要求及び制約に合致するように開発す
ることができる。

【０００９】 ＢＢＤを使用する設計者が当面する別の挑戦は、システム設計が実行可能であ
るか否かを決定する際の不確実性によってもたらされるフロントエンド（プロジ
ェクト受入れ）遅延、及びリスクである。現在のＡＳＩＣ（特定用途向け集積回
路）設計は、主としてＲＴＬ（レジスタトランスファレベル）ステージにおいて
、及びそれよりもやや早めの仕様レベルにおいて顧客から設計者に提示される。
次いで、これらの設計は、費用有効に実施するのに要求される面積、性能、及び
電力のトレードオフに従って、利用可能な合成技術の制約に基づく手法で分割さ
れる。このようにして、設計者は入力としてシステム仕様を受入れ、最終的に物
理的実施（設計場所、ルート、及び検査を含む）についてのネットリストレベル
設計を提供する。もし設計仕様が、クロッキング、電力、及びサイズ仕様を含む
意図された、または利用可能な処理技術の能力内にあれば利用可能な設計方法が
合理的に予測可能であり、この方法が利用可能な回路設計ツールを用いて良好に
作業する。

【００１０】 しかしながら、ＲＴＬレベル設計及びシステムレベル設計のアクティビティは
典型的には結合されていないか、またはゆるく結合されており、これはシステム
レベル機能の限界からＡＳＩＣ（ＲＴＬ）レベルまでコヒーレントなリンクが存
在しないことを意味している。ＲＴＬレベル設計は、ペーパーＡＳＩＣ仕様に基
づいて開発され、ＡＳＩＣインタフェースの周りに作成された新たに形成された
試験の組によって検査される。従って、ＡＳＩＣ設計のために利用可能な設計及
び実施方法は、効率的なブロック統合を阻害する多くの問題を呈する。

【００１１】 第１に、現在の方法は、異なる設計考察を有する複数のソースから供給される
複数の設計ブロックを統合しながら、厳格な時間対市場の制約の中で階層的検査
及び短いアセンブリ時間を提供するという両立性をを包括的に評価し、保証する
トップダウンアプローチを提供しない。

【００１２】 またＡＳＩＣ設計のための既存法は、スケーラビリティを提供しない。殆どの
既存方法は、フラット設計に集中している。このアプローチは、百万より多くの
ゲートを有するシステムのためのトップレベル設計をアセンブルするのに必要な
時間の長さに重大な問題を抱えている。

【００１３】 更に、既存のＡＳＩＣ設計方法は、予め設計済みの回路ブロックを再使用する
には適していない。従来のスキームは、特定のデバイスアーキテクチャ内に回路
設計ブロックを統合するのに伴うタイミング、クロック、バス、電力、ブロック
配列、検査、及び試験の諸問題を解決するためのガイドラインを提供しない。従
って、ブロック再使用のための包括的アプローチを用いない場合には、既存の方
法は、特別の且つ予測不能の設計アプローチをもたらし、設計実施の実現可能性
を低下させ、引渡し費用及び時間を増加させ、そしてそれらを設計済みのシステ
ム内に適合させるために、予め設計済みの回路ブロック自体の性能を低下させる
ような変更を強制することが多い。更に、既存方法は、性能トレードオフ解析、
クロック周波数のような臨界的設計パラメタのフィードバック、及び面積対成功
裏に且つ予測可能にチップ設計及び実施を完了させるリスクを提供しない。

【００１４】 従って、進展しつつある環境を満足させ、従来の（もしくは、利用可能な）技
術の欠点に対処することができる方法に対する要望が存在している。

【００１５】 また、回路設計における多数のソースからの予め設計済みの回路ブロックを使
用、及び再使用する適当な方法に対する要望も存在している。

【００１６】 ＩＰブロックを組合わせることは、ブロックを単一のデバイス上で一緒に動作
させることを可能にする論理である“グルー（ｇｌｕｅ：接続）”論理に対する
要望ももたらす。グルー論理は主として設計ブロックを相互接続することを責務
とする論理であり、通常は設計全体に分散するブロック間に存在している。グル
ー論理要素は、チップ計画の種々のステージの間に設計に追加することも、また
は設計内の各ブロックの最も外側の境界に存在してホストブロックのための相互
接続メカニズムとして動作することもできる。ブロック間にグルー論理を配置す
ることによって生ずるワイヤーの混雑及びタイミングの複雑さ（元のブロック設
計者によって企図されてはいなかった遅延を導入する）を最小にするためには、
そのソースには無関係に、グルー論理を設計内に最適に配置しなければならない
。

【００１７】 従って、本発明が関連する分野においては、ブロックをベースとする設計内に
グルー論理を配置し、分散させる改善された方法に対する要望が存在している。

【００１８】 また、いろいろなグルー論理要素の機能的有縁性を斟酌し、それらを新しい設
計ブロックにグループ化するグルー論理分配メカニズムに対する要望も存在して
いる。

【００１９】 関連する分野においては、最適化された量のグルー論理を既存設計に戻すグル
ー論理分配メカニズムに対する要望も存在している。

【００２０】 更に、既存ＡＳＩＣ設計方法は、予め設計済みの回路ブロックの再使用には適
していない。従来のスキームは、特定のデバイスアーキテクチャ内に回路設計ブ
ロックを統合するのに伴うタイミング、クロック、バス、電力、ブロック配列、
検査、及び試験の諸問題を解決するためのガイドラインを提供しない。回路ブロ
ックは複数の一貫性ソースからであるから、どのようにしてこれらの回路ブロッ
クを、ブロックをベースとする設計に適する態様で回路システム内に統合するか
が挑戦である。

【００２１】 従って、複数の一貫性ソースからの回路ブロックを、ブロックをベースとする
設計に適する態様で相互接続するのに適する方法及び装置に対する要望が存在し
ている。

【００２２】 異なるインタフェースを有する回路ブロックを、標準化されたインタフェース
を有する回路ブロックに変換するためのインタフェースを提供する方法及び装置
に対する別の要望も存在している。

【００２３】 勿論、全てのＩＣは、たとえ単一のチップ上に全システムが含まれているよう
なＩＣであっても、チップが性能要求を満足させていること、及び隠れた製造欠
陥が存在しないことを確認するために、一連の試験に合格しなければならない。
もし製造欠陥を見逃せば、アセンブリが処理された後まで、または更に悪い場合
には実装されるまで、障害チップが発見されないことになる。顧客を犠牲にする
ようなそれらの効果で表される“試験エスケープ”の費用が、生産ラインを荒廃
させる恐れがある。

【００２４】 一般的に、欠陥を検出するための試験には３つの型、即ち直流パラメトリック
試験、交流パラメトリック試験、及び機能（“ＰＬＬ”）試験が存在している。
直流パラメトリック試験では、チップの入力、出力、入力から出力への伝送、合
計電流、及び電力消費が測定される。交流パラメトリック試験では、チップの入
力及び出力信号の立上がり及び立下がり時間、入力端子と出力端子との間の伝播
の遅延時間、最小クロックパルス幅、及び動作周波数が測定される。機能試験で
は、チップは規定された動作条件の下で設計通りに機能するか否かを調べるため
に試験される。典型的には、入力端子へ試験パターン（“試験ベクトル”）を印
加し、出力端子において検出された出力パターンと予測されるパターンとを比較
することによって機能試験が遂行される。

【００２５】 試験用設計（“ＤＦＴ”）方法が出現する前は、設計者はチップを作ってアセ
ンブルし、次いで完了した設計を試験設計者に引渡していた。試験設計者はパッ
ケージレベル試験論理を追加し、チップを製造者（“fab”）に送る。Fab試験者
はチップを試験し、パッケージレベル論理上で上述した試験を含む広範な試験プ
ロトコルを走らせる。チップ全体に“単一”試験方法を適用し、予測可能な、そ
して一貫した試験結果を得る高度に効果的な、且つ広く使用されている方法の簡
単な例は、従来の「走査設計方法」である。走査不能な設計スタイルを処理する
ために、他の特別な方法も使用できる。

【００２６】 今日では、チップ全体内に既に含まれている論理を、単一の仮想成分（ＶＣ）
、またはより大きいチップ内に含まれる設計ブロックとして使用する。従って、
最早、回路設計が完了した後に試験を設計することはできない。設計者は、設計
プロセスを通して、各設計ブロックを、並びにパッケージ済みのチップ全体をど
のように試験するのかを計画しなければならない。従って、設計プロセスは、１
つまたはそれ以上の試験方法を適切に適用することによって、可試験性を保証し
なければならない。

【００２７】 ＤＦＴの利点は公知である。ＤＦＴ論理及び試験ベクトル検査機能は、生産サ
イクルの初期において短い、生産を実行することが可能か否かの試験を可能にす
る。またＤＦＴ走査経路は、それ以外では利用できないチップ及びシステム状態
へのアクセスを提供する。それにより、良好なＤＦＴ計画は、市場への時間を短
縮し、フロントエンド設計プロセス及び製造試験の開発を容易にすることによっ
て試験費用を低減させる。

【００２８】 従って、利用可能な技術に対して、４つの要望が存在している。第１に、ＢＢ
Ｄのための新しいＤＦＴは、他の異なる試験方法の中の予め設計済みの試験デー
タを効果的に使用できること、制限された試験アクセスを共用すること、及び総
合ＳＯＣレベル試験目的に合致させることができなければならない。

【００２９】 第２に、技術のスケーリングに起因して、新しい欠陥の型及び新しい欠陥のレ
ベル、混合された信号及び混合された技術設計の新しい複雑さ、及び増加するＩ
／Ｏカウント及び新しいパッケージング技術が出現する困難さに直面しなければ
ならない。

【００３０】 第３に、統一された構造的試験モデルを本質的に有していないＩＰブロックを
統合することの困難さに直面しなければならない。ＳＯＣレベル試験アクセス及
び障害分離が必要であり、現在利用可能なＤＦＴ方法によっては十分に支援され
ない低電力設計技術（即ち、ラッチをベースとする、ゲーテッドクロック、導出
されたクロック、パイプライン、及び低しきい値電圧）に対する要望に対処しな
ければならない。

【００３１】 そして新しいＤＦＴ方法は、たとえ制限された、または不十分な試験情報に当
面しても、コヒーレントで一貫した試験統合モデルを使用して市場までの時間の
圧力を打破しなければならない。

【００３２】 従来の技術は、試験データを部分的にまたは完全に生成し、１組の障害を検査
することができるように、構造的情報（即ち、障害モデル及び試験モデル）を必
要とする。例えば「走査設計方法」は同期設計だけに適用可能であり、単一の縮
退故障モデルだけを検出する。更に、他のＤＦＴ解決法は走査をベースにしてお
り、従って構造的情報を含まないハードＩＰ試験モデルを共用し、検査すること
をかなり困難にしている。

【００３３】 従来の技術は、たとえ共用及び検査が可能（即ち、ソフトＩＰモデル）である
としても、現在のゲートカウントの急増を支えることができない非線形計算モデ
ルを必要とする。しかしながら、ソフトＩＰは必ずしも走査可能または併合可能
でなく、場合によっては予測不能な、そして管理不能な試験開発をもたらす。

【００３４】 最後に設計検査に関して、ＳＯＣ設計内に複数の予め設計済みのブロックを使
用することによって提示される挑戦は、信頼できる且つ効率的な機能検査方法に
対する要望である。従来の技術では、試験の組が多重ブロック設計を検査するた
めに使用される。組内の各試験は、統合する前の各ブロックを試験するために使
用される。ブロックを統合した後に、システムレベルで機能検査可能にするよう
に試験の組を調整するには、かなりの努力を必要とする。最終的な全システム検
査を確信をもって提供できるようになるまでには、何回も試験してデバッグする
プロセスを繰り返す必要がある。

【００３５】 この問題に対する従来の１つのアプローチは、実施モジュールをそれらの対応
する挙動モデルに置換し、それによってチップレベルシミュレーション及び混合
モード状況での試験を可能にすることである。このアプローチは、もし効果的に
遂行されれば望ましい結果を提供することができ、また上述した繰り返し型のブ
ロックをベースとするシミュレーションよりも低費用とすることができるが、そ
れでもこのアプローチは、機能を信頼できるように検査するためには全チップを
シミュレートしなければならないので、極めて高価であり、低速である。

【００３６】 バス構造を機能的に検査する必要性があるために、多重ブロック設計において
は特に困難な挑戦が提示される。従来の技術では、バス検査は２つの方法の何れ
かで達成されている。バスは、総合チップの一体部分としてデバッグし、検査す
ることも、または新たに作成されたブロックによって提供される詳細な実施を斟
酌し、予め設計済みのブロックのためのバス機能モデルを使用して検査すること
もできる。しかしながら、統合バス検査は遅く、且つ高費用であり得る。バス設
計を検査するためにはチップ全体を使用しなければならず、また細部のレベル及
びバス関連バグが見出せない可能性があるためにデバッギングが困難であり且つ
時間を消費する場合には、統合バス検査は設計サイクルの後半にしか実行するこ
とができない。バス機能モデルアプローチはこれらの問題の若干を軽減するが、
新しく作成されたブロックの実施の詳細を必要とする。更に、バス機能モデルは
それら自体エラーを生じ易く、また“ブラックボックス”としてしか利用できな
いので信号追跡及びデバッグを困難にするか、または不可能にする。

【００３７】 （発明の概要） 従来技術の欠陥に対処するために、本発明は回路システムを設計するための方
法及び装置を提供する。本方法は、 （ａ）上記回路システムを設計するのに使用するために、複数の予め設計済み
の回路ブロックを選択するステップと、 （ｂ）上記予め設計済みの回路ブロックに関する設計者の経験を反映するデー
タを収集するステップと、 を含み、上記設計者の経験は処理方法に適用可能であり、 （ｃ）上記設計者の経験データ及び許可可能なリスクの程度に基づくような手
法で、上記回路システムの設計を許可するか、または拒絶するステップと、 （ｄ）許可された場合には、各回路ブロック毎の基準及び変更された制約（Ｆ
ＥＡ）を含むブロック仕様を形成するステップと、 （ｅ）許可された場合には、上記選択された回路ブロック及び上記処理方法を
変化させることなく、上記基準及び上記変更された制約に従って上記回路ブロッ
クをチップのフロアプラン上に展開させるためのブロック仕様を形成するステッ
プと、 を更に含んでいる。

【００３８】 （実施の形態） 従来技術の欠点を解消するために、本発明は、ブロックをベースとする設計（
“ＢＢＤ”）のための新しい方法及び実施を開示する。

【００３９】 図１のフローチャート１００は、本発明によるブロックをベースとする設計（
ＢＢＤ）に基づく設計プロセスを示している。図１に示すように、この設計プロ
セスは、フロントエンド受入れ設計ステージ１０２、チップ計画設計ステージ１
０４、ブロック設計ステージ１０６、チップアセンブリ設計ステージ１０８、及
び検査設計ステージ１１０を含んでいる。

【００４０】 フロントエンド受入れ設計ステージ１０２は、システム統合者（チップ設計者
）が、予測される設計プロジェクトの実現可能性を評価できるようにする。フロ
ントエンド受入れ設計ステージ１０２において、設計者は、ＡＳＩＣを設計する
ために、機能その他の要求（納期及び予算のような）を含む仕様を顧客から受け
る。顧客は、予め設計済みの回路ブロック、及びこれらの回路ブロックのための
試験ベンチを供給することもできる。フロントエンド受入れ設計ステージ１０２
を使用する設計者は、顧客が提供したブロックに加えて、入力として異なるソー
スからの回路ブロックを受入れる。これらの回路ブロックのあるものはサードパ
ーティから供給することができ、あるものは受け継がれた回路ブロックであるこ
とができ、あるものは新たに作成されたものであることができる。これらの選択
された回路ブロックは、ソフト、ファーム、またはハード設計状態にあることが
できる。（ソフト状態はＲＴＬレベルにあり、ハードはＧＤＳＩＩレベルにあり
、そしてファームはゲートレベルまたはネットリストレベルのようなソフトとハ
ードとの間にあることに注目されたい。）次いでフロントエンド受入れ設計ステ
ージ１０２は、設計者の利用可能な経験（データ使用分野、挙動シミュレーショ
ンを通しての推定データ、及び／または部分的実施データを含む）を収集する。
フロントエンド受入れ設計ステージ１０２のプロセスは、設計者が、顧客の要求
、設計者の利用可能な経験、及び設計者の受入れ可能なリスクの程度を含む設計
プロパティパラメタに基づいて、設計プロジェクトを許可するか否かを決定する
のを援助するアセスメントを提供する。更に、機能仕様に基づいて、フロントエ
ンド受入れ設計ステージ１０２は、予め設計済みの回路ブロックの最終セットを
回路設計内に使用するように指令する。

【００４１】 フロントエンド受入れ設計ステージ１０２は、３つの相のアセスメント、即ち
粗粒アセスメント、中粒アセスメント、及び細粒アセスメントを提供する。もし
１つの相におけるアセスメントで満足できなければ、フロントエンド受入れ設計
ステージ１０２は、設計プロパティパラメタを精細化することを可能にし、次の
相においてさらなるアセスメントを行わせる。

【００４２】 もし提唱された設計プロジェクトを受入れ可能であることを見出せば、フロン
トエンド受入れ設計ステージ１０２は包括的なステップを提供して、前の設計内
の諸問題を早めに検出するように、及びこれらの諸問題をプロジェクト要求、設
計者の利用可能な経験、及び選択された処理方法によって限定される境界内で包
括的に解消できるようにする。フロントエンド受入れ設計ステージ１０２は、選
択された予め設計済みの回路ブロック、設計基準、及び相互に依存し合う設計制
約を含む処理方法を限定する設計仕様を生成する。

【００４３】 チップ計画設計ステージ１０４は、フロントエンド受入れ設計ステージ１０２
の出力からの設計仕様を、各選択された回路ブロック毎のブロック仕様に翻訳す
る。チップ計画設計ステージ１０４内で実行されるタスクは、（１）チップ設計
、アセンブリ、及び遅延の予測可能性、ルータビリティ、面積、電力消費、及び
タイミングに集束される実施のための計画を開発すること、及び（２）制約を識
別し、調整することを含む。詳述すれば、フロントエンド受入れ設計ステージ１
０２の出力として供給される設計基準及び相互に依存し合う制約に基づいて、チ
ップ計画設計ステージ１０４は、フロントエンド受入れにおいて指令された境界
（要求及び制約のような）内でチップ計画を供給する。本発明のチップ計画設計
ステージ１０４は一時に１つの制約を考慮し、しかもフロントエンド受入れ設計
ステージ１０２によって指定された総合設計基準を満足させる。チップ計画設計
ステージ１０４は、フロントエンド受入れ設計ステージ１０２において選択され
た各回路ブロック毎に予算を計上し、回路ブロックの仕様を改訂し、そしてフロ
ントエンド受入れ設計ステージ１０２によって指定された処理方法の中で制約を
調整することによってこれを達成する。本発明のチップ計画設計ステージとは対
照的に、既存の方法は新しい機能ブロックを生成するか、または設計基準に合わ
せるように処理技術を変化させているが、これは設計時間を長引かせ、プロジェ
クトリスクを高める。チップ計画設計ステージ１０４は、詳細を後述するように
、グルー論理の仕様（即ち、選択された回路ブロックを相互接続するのに必要な
ハードウェア）をも生成する。チップ計画設計ステージ１０４は、出力として、
チップ内の１つまたはそれ以上の領域を占有する新しいグルー論理ブロック、選
択された回路ブロック内へ分散されている分散グルー論理、及びトップレベルブ
ロックグルー論理要素を含む３つの型のグルー論理を供給する。

【００４４】 選択された回路ブロックを継ぎ目無しで相互接続するために、もし必要ならば
、ブロック設計ステージ１０６は各回路ブロックの周りにインタフェース（カラ
ー（ｃｏｌｌａｒ）と呼ぶ）を埋め込み、標準インタフェースを形成させる。回
路ブロックはソフト、ファーム、またはハードであることができるから、各カラ
ーもソフト、ファーム、またはハードであることができる。ブロック設計ステー
ジ１０６の出力は、以下のものを提供する。即ち、（１）チップ内の全ての回路
ブロックは制約及び予算を満足させ、指令されたチップ設計計画及びアーキテク
チャに適合する；（２）チップアセンブリ設計ステージ１０８には、全ての要求
されたモデル及び全ての回路ブロックのビューが供給される；（３）チップ計画
設計ステージ１０４において生成された新しい回路ブロックを作成するための方
法及び流れを開発し、引き継がれた回路ブロックを適合させ、そしてサードパー
ティ回路ブロックを適合させるように設計が可能化される；（４）設計を所与の
チップアーキテクチャ及び予算に適合させる。

【００４５】 チップアセンブリ設計ステージ１０８は、回路ブロックを統合して設計ステー
ジ製造のためのトップレベル設計をテープアウトする。チップアセンブリ設計ス
テージ１０８は、ハードブロック及びチップバスルーティングの最終配置、並び
に何等かのグローバル設計詳細の完了を含む。チップアセンブリ設計ステージ１
０８は、全ての回路ブロックが設計され、変更され、そしてチップ計画内に統合
されるまでは開始されない。チップアセンブリ設計ステージ１０８への入力は、
フロントエンド受入れ設計ステージ１０２またはチップ計画設計ステップ１０４
から受けた電力、面積、及びタイミングマージン仕様を含む。

【００４６】 検査設計ステージ１１０は、各ステージにおける設計を、フロントエンド受入
れ設計ステージ１０２に供給される機能仕様に詳細が示されている顧客の機能要
求及びチップ試験ベンチに合致させることを保証する。検査設計ステージ１１０
は、機能検査１１２、タイミング検査１１４、及び物理的検査１１６を含む。

【００４７】 機能検査ステップ１１２は、設計の各ステージにおける選択された回路ブロッ
クのための論理機能及びチップ試験ベンチを、顧客仕様の機能要求に合致させる
ことを保証する。機能検査は、フロントエンド受入れ設計ステージ１０２、チッ
プ計画設計ステップ１０４、ブロック設計ステージ１０６、またはチップアセン
ブリ設計ステージ１０８中に遂行させることができる。タイミング検査は、設計
の各ステージにおける信号タイミングを、論理機能を生成させるのに適切である
ことを、また顧客の仕様に指定されている試験に合格させることを保証する。タ
イミング検査は、フロントエンド受入れ設計ステージ１０２、チップ計画設計ス
テップ１０４、ブロック設計ステージ１０６、またはチップアセンブリ設計ステ
ージ１０８中に遂行させることができる。物理的検査は、回路設計のための物理
的レイアウトを顧客の仕様に合致させることを保証する。

【００４８】 設計プロセス中に、フロントエンド受入れ設計ステージ１０２、チップ計画設
計ステップ１０４、ブロック設計ステージ１０６、及びチップアセンブリ設計ス
テージ１０８はそれらの機能を遂行するだけではなく、まとまって検査機能１１
０を構成している機能検査１１２、タイミング検査１１４、及び物理的検査１１
６に必要な情報をも生成する。もし設計プロセスの特定のステージにおける検査
中に何等かのエラーが発生すれば、次のステージへ進む前に訂正することが好ま
しい。

【００４９】 従って、チップアセンブリ設計ステージ１０８においては、設計プロセスはチ
ップを製造するためのトップレベル設計を生成するだけではなく、設計に使用さ
れる各回路ブロック毎のチップ試験ベンチの検査、及びチップのための総合チッ
プ試験ベンチをも完了させる。

【００５０】 図２−１５に関して概要説明する。これらの各図は、以下に詳細を説明する資
料の高レベル記述を与えている。

【００５１】 II．フロントエンド受入れ１０２ 図２のフローチャート２００は、本発明によるフロントエンド受入れ設計ステ
ージ１０２のステップ２１０−２１６を示している。

【００５２】 III．チップ計画１０４ チップ計画設計ステージ１０４は、以下のモジュールを含んでいる。

【００５３】 （１）クロック計画、 （２）バス識別及び計画、 （３）電力計画、 （４）Ｉ／Ｏ及びアナログ／混合信号要求、 （５）試験計画、 （６）タイミング及びフロア計画、及び （７）バス検査。

【００５４】 図３は、本発明によるクロック計画モジュールを示している。

【００５５】 図４は、本発明によるバス識別及び計画モジュールを示している。

【００５６】 図５は、本発明による電力計画モジュールを示している。

【００５７】 図６は、本発明によるＩ／Ｏ及びアナログ／混合信号要求を示している。

【００５８】 図７は、本発明による試験計画モジュールを示している。

【００５９】 図８は、本発明によるタイミング及びフロア計画モジュールを示している。

【００６０】 IV．ブロック計画１０６ 図９は、本発明によるブロック設計ステージの流れを示している。

【００６１】 V．チップアセンブリ１０８ 図１０は、本発明によるチップアセンブリ設計ステージのデータフローを示し
ている。

【００６２】 図１１は、本発明によるチップアセンブリ設計ステージのタスクフローを示し
ている。

【００６３】 VI．検査１１０ 図１２、１３、１４、及び１５は、本発明の検査設計ステージのための機能検
査の流れを示している。

【００６４】実現可能性アセスメントのためのスケーラブル方法 フロントエンドアセスメントに移って、先ず図１６は、複数の予め設計済みの
回路ブロックを使用して回路設計の実現可能性を評価する本発明による方法を示
している。

【００６５】 図１６において、この方法のための入力は、使用データのフィールドを入力と
して使用するために初めに設計される。しかしながら、新しい設計プロジェクト
を評価するには、新しい設計プロジェクトの実現可能性を評価するために、新し
い型の入力１、２、及び３を使用する必要がある。この方法を受入れるには、こ
の方法が新しい型の入力を使用して新しい設計プロジェクトについての実現可能
性アセスメントを遂行できるように、新しい型の入力が処理される。

【００６６】 図１７は、本発明により、図１６に示す方法を使用した実現可能性アセスメン
トの結果を示している。図１７は、垂直軸上にリスクを、また水平軸に沿って時
間／費用を示している。リスクインディケータによれば、これら３つの型の新し
いデータを使用する場合のリスクは、使用データのフィールドだけを使用する場
合のリスクに比して僅かに増加する。また図１７から、型３の入力がリスクに対
して最大のインパクトを有していることが解る。しかしながら、時間／費用イン
ディケータによれば、これら３つの型の新しいデータを使用することによって時
間／費用は、使用データのフィールドだけを使用することによって発生するリス
クに比して大きく増加する。図１７に示されている本発明のリスク対時間／費用
計算の結果を考えることによって、事前にステージ化されたブロックが予め設計
され、設計方法において適切に使用するために認定される。事前にステージ化さ
れた設計計画は、既存方法の１区分、例えばブロックオーサリング片であること
が好ましい。

【００６７】 図１８は、本発明により、複数の予め設計済みの回路ブロックを使用する回路
設計の実現可能性を評価する方法を示している。図１８において、この方法への
入力は、使用データのフィールドを入力として使用するために初めに設計される
。しかしながら、新しい設計プロジェクトを評価するには、新しい設計プロジェ
クトの実現可能性を評価するために、新しい型の入力Ｘ、Ｙ、及びＺを使用する
必要がある。この方法を受入れるには、新しい入力型を適応させるために、新し
い設計プロジェクトについての実現可能性アセスメントを遂行するように、これ
らの新しい入力を使用できるように方法を変更する。

【００６８】 図１９は、本発明により、図１８に示す発明の方法を使用して得られる評価さ
れた実現可能性を示している。図１９は、垂直軸にリスクを、水平軸に時間／費
用を表している。リスクインディケータによれば、これら３つの新しい入力型を
使用する場合のリスクは、使用データのフィールドだけを使用する場合のリスク
に比して大きく増加する。また図１９から、型Ｚの入力がリスクに対して最大の
インパクトを有していることが解る。しかしながら、時間／費用インディケータ
によれば、これら３つの型の新しい入力を付加的に使用することによって与えら
れる時間／費用は、使用データのフィールドだけを使用することによる時間／費
用に比して中程度に増加している。

【００６９】 新しい型の入力は、予め設計済みの回路のための推定データまたは実施データ
であることができる。図１６−１９に示す結果に基づいて、システム統合者はト
レードオフ決定を行うことができる。

【００７０】フロントエンド受入れにおける実現可能性アセスメント 図１のフロントエンド受入れ（ＦＥＡ）設計ステージ１０２は、提唱された設
計の実現可能性及びリスクアセスメントを含んでいる。もし評価された基準が許
容されるリスク許容差内にあれば、設計は実行可能である。

【００７１】 ある意味ではＦＥＡは、システム統合者が、提唱された設計を受入れるリスク
を想定することができる点まで設計を精細化するプロセスである。従って、それ
は知識の欠如を減少させる、従って要求された設計の最終結果内のエラーを減少
させるプロセスである。開始点として、ＦＥＡプロセスは顧客が供給した１組の
設計要求、設計を受入れるための統合者のリスクプロファイル、１組の予め設計
済みのブロック、及び予め設計済みのブロックに関する統合者の先行知識及び経
験を受ける。予め設計済みのブロックは、いろいろな分解能（ハード、ソフト、
またはファーム）レベルにあることができる。分解能、先行経験、及びブロック
の理解は、ブロックの全域で面積、電力、性能等の予測に大きい範囲のエラー境
界をもたらす。

【００７２】 各ブロック毎に、設計の精細化は３つのレベルの分解能で提示される。

【００７３】 （１）統合者の経験のフィールド（ＦＯＥ）、 （２）実際のモデルを実行するために、これらのモデル及びツールを使用する
推定、及び （３）ブロックを、それが受けられた時よりも高レベルの設計分解能に取り入
れることによるディップ。 これら３つのレベルの設計分解能が、ソフト、ファーム、及びハードのような昇
順に配列されていることに注目されたい。効率は、全てのブロック及び相互接続
基準予測を不必要に精細化することなく、実現可能性アセスメントを遂行するメ
カニズムを提供することによって達成される。

【００７４】 図２０は、本発明によるＦＥＡプロセスのためのフローチャートである。

【００７５】 図２０において、ＦＥＡプロセスは、上述した３つのレベルの設計の精細化を
反映する３つの相の実現可能性アセスメントを含んでいる。これら３つの相は、
粗粒アセスメント、中粒アセスメント、及び細粒アセスメントである。

【００７６】 粗粒アセスメントは、設計統合者の類似設計による先行経験に基づく「経験に
支配された」アセスメントのフィールドである。粗粒アセスメントは、数十のブ
ロック及びシステム設計オプションに、及び設計推定エラー許容差が50％または
それ以上の程度であるような状況に特に適している。ブロック間の相互作用の推
定が臨界的ではない場合に、検討中のブロックを粗調査するために粗解析を使用
することができる。この相においては、検討中のブロックの全てが最終設計内に
使用されない可能性が最も大きい。

【００７７】 中粒アセスメントは、方程式またはシミュレーションによる挙動の解析的公式
化によって推定する「推定に支配された」アセスメントである。中粒アセスメン
トは、２から10までのシステム設計オプションにとって、及び受入れ可能な設計
推定エラー許容差が20％程度であり、統合者がブロックがどのように相互作用す
るかを理解しているような状況に特に適している。中粒アセスメントは、設計の
動作の充足度について臨界的であるブロック間の相互作用を調べるために使用す
ることができる。この相においては、検討中の全てのブロックが最終設計に使用
される高い確率を有している。

【００７８】 最も精細化された（細粒）アセスメントは、ブロック設計の精細化から測定が
なされる「設計・ディップに支配された」アセスメントである。ディッピングは
、新しいブロックをソフトブロックに、予め設計済みのソフトブロックをファー
ムブロックに、そして予め限定済みのファームブロックをハードブロックに変換
するプロセスである。結果は、シミュレーション、エミュレーション、またはプ
ロトタイピングから生成される。細粒アセスメントは、既存の設計精細化では不
十分である臨界的な結果の最終分解能のような、受入れ可能な設計推定エラー許
容差が５％またはそれ以上の程度であるような全ての、または一部の単一オプシ
ョンチップ設計に適している。細粒アセスメントは、充足度を保証するために、
またはそのブロックのための何等かの既存シミュレーションモデルが十分である
ことによって与えられる分解能を保証するために、詳細に検討する必要があるチ
ップ挙動またはブロック相互作用のサブセットを調べるのに使用することができ
る。また細粒アセスメントは、設計要求を満足させるために、ブロックの障害（
最終設計実現可能性に強いインパクトを与える）を調べるためにも使用すること
ができる。この相においては、検討中の全てのブロックがディップされるのでは
なく、代わりに、実質的にＦＥＡ決定に臨界的なインパクトを与えるブロックだ
けがディップされる。

【００７９】 図２０における各三角形の幅は、システムＦＥＡ基準の予測のエラーを表して
いる。アセスメントの各レベルにおけるキーは、ＦＥＡ決定を迅速に行うことが
できるように設計者のエラーを減少させながら、可能な限り小さくＦＥＡ基準を
精細化することである。ＦＥＡプロセスの各相における基本的な目的及び戦略は
、以下にリストするように同一である。

【００８０】 （１）検討中のブロックに関する利用可能な情報を集める、 （２）システム推定エラーに最もインパクトを与える可能性があるブロックを
局部的に識別し、精細化する、 （３）設計がＦＥＡ制約を満足するか否かを評価する。もし満足すれば、ＦＥ
Ａプロセスを停止する。もし満足しなければ、 （４）もしＦＥＡ制約を満足しなければ、システム内のブロック推定をグロー
バルに精細化する。

【００８１】 図２０に示すＦＥＡプロセスのキー部分は、システム基準の予測における受入
れ可能なグローバルエラー（または、総合エラー）をどのように計算するのか、
及びそのグローバルエラーを受入れ可能な境界内に導くためには、どの数ブロッ
クを推定精細化する必要があるかを識別することである。この計算プロセスは、
次の３つのパラメタを必要とする。

【００８２】 （１）決定を行うための受入れ可能なグローバルエラーの推定、 （２）現在のシステム解析から得られるグローバルエラーの推定、及び （３）設計内の特定ブロックを推定する際のエラーに対するグローバルエラー
の感受性（ブロックエラーインパクトとも呼ばれる）。

【００８３】 第１のパラメタは、システム統合者のリスクプロファイル、顧客によって供給
される制約、及びグローバルエラーの良好な予測（現在のデータの状態に基づく
システム予測から得られる）によって限定される。第２及び第３のパラメタは全
て、正確な「エラーインパクト曲線」を作成することから導出される。図２１は
、本発明により、エラーインパクト曲線が与えられた場合の精細化プロセスの駆
動を示している。

【００８４】 ＦＥＡプロセスを更に定義するために、本発明は以下の４つの基本的アセスメ
ント技術を使用する。

【００８５】 １．ＦＥＡ決定プロセス：データイン、データアウト、及びデータアウトに基 づく決定プロセス。（即ち、受入れ可能なリスクに関係するデータアウト はどのようであるか?）； ２．ＦＥＡデータ抽出プロセス：検討中の抽象レベルに関するデータインの完 全セットから、データアウトへ移動する； ３．ＦＥＡブロック精細化識別：あるシステム内の推定エラー及びブロックク リティカリティを与えて、システム推定インパクトを確立するための共通 メカニズムを限定する。（即ち、もし決定プロセスのための受入れ基準を 満足しなければ、最高の潜在的インパクトブロックが更に精細化される。 ）、 ４．ＦＥＡアセスメント−軸計量：ＦＥＡに関連付けられた各「受入れの軸」 毎に使用される実際の計量を定義する。（即ち、あるシステム内のあるブ ロックのクリティカリティをどのように限定するかを定義する。）

【００８６】 本発明の方法及びシステムにおいては、ＦＥＡプロセスを検査するために１組
の推定の正しさ曲線を使用する。各推定の正しさ曲線はＦＥＡ軸上に提示され、
これはＦＥＡプロセスを検査するための要素及び基準を視覚的に提供する。推定
の正しさ曲線の機能を解り易く説明するために、以下の要素及び基準を定義する
。これらの要素及び基準を、まとめて「ＦＥＡ受入れ軸」と呼ぶ。これらの定義
は、ブロック及び総合システムの両方に適用される。

【００８７】 電力 −動作モード毎（例えば、ｍＷ）、 性能 −サイクル内遅延（例えば、ｐｓ／ｎｓ／μｓ）、 −待ち時間（例えば、ｎｓ／μｓ／ｍｓ）、 −スループット（オブジェクト／秒−例えば、50ｋＢ／秒）、 面積 −ゲート、ルーティング、周囲、未使用白空間を含む面積（例 えば、ミル） 費用 −非回帰エンジニアリングコスト（例えば、米＄）、 −コスト／ユニット（例えば、米＄）、 スケジュール −資源割当て（例えば、人・年） −引渡し可能なタイムライン（時） リスク −エラーの確率（％）、 −エラーのインパクト（米＄、及び／または時間）。

【００８８】 ＦＥＡプロセスを遂行する前に、顧客は、システム統合者に可能な限り多くの
以下の情報を供給する。

【００８９】 （１）ソフト、ファーム、またはハードの何れかのフォーマットである１組の
回路ブロック、 （２）ブロックのための１組のシミュレータ（エスティメータ）または先行経
験推定を、推定のためのエラー許容差と共に、 （３）総合チップ機能及び性能要求を記述する１組の仕様、及び （４）プロジェクトのための受入れ可能なスケジュール、費用、及びリスクに
関する１組の規定。

【００９０】 顧客は、以下のものも供給する。

【００９１】 （５）チップ内に組み込まれる何等かの新しいブロックのための挙動の定義、
及び （６）既知の臨界的結果の識別。

【００９２】 ＦＥＡプロセスを遂行する前に、システム統合者は、 （１）ａ．保護帯−各ＦＥＡ軸毎の統合者の過大な設計マージン； ｂ．受入れリスク−顧客の要求（リクエスト）を受入れる前に、設計が
要求（リクワイヤメント）を満足することの確実さ。これは、単に標準偏差測度
、即ちＡσ設計受入れリスクとして表される； ｃ．拒絶リスク−指定された設計が、利用可能なブロックを用いてアセ
ンブルまたは製造することができないことの確実さ。拒絶は、実際にシステム統
合者にとって危険な挙動であることに注目されたい。採用されるリスクは、たと
え初期アセスメントが疑わしいことを明らかにしたとしても、拒絶された設計が
実際に実現不能であったことである。これも、標準偏差測度、即ちＲσ設計拒絶
リスクとして表される； を含む設計が適当であることを評価するリスクプロファイルを決定し、 （２）何等かの新しい、またはサードパーティブロックと組合わせた提示され
たブロックが、受入れ可能なリスクの限界内のプロジェクト制約を十分に満足す
ることを確認する べきである。

【００９３】 図２２は、本発明による正しさ曲線推定の例を示している。水平軸は、何等か
の顧客制約、またはシステムのための総合制約を表すことができるＦＥＡ軸であ
る。説明を容易にするために、ＦＥＡ軸が電力を表しているものとする。垂直軸
は、推定の正しさを表している。図２２によれば、電力制約の保護帯は、顧客に
よって初めに指定された制約と、ＦＥＡプロセスによって変更された制約との間
である。この例では、保護帯によって変更された電力制約が拒絶領域内にあるの
で、設計は拒絶される。これは、たとえ初期に指定された電力制約が拒絶領域内
になくても、真である。

【００９４】 もし変更された電力制約がＡσマーカーとＲσマーカーとの間にあったとすれ
ば、ＦＥＡ精細化プロセスが進められていたであろう。このプロセスは、精細化
された推定の正しさ曲線に基づいて受入れ、または拒絶を決定することができる
ようになるまで、予測されるエラー分散（即ち、この例では電力・エラー分散）
を減少させ続ける。

【００９５】 図２３は、本発明によりＦＥＡを検査するプロセスを示している。本発明のＦ
ＥＡ検査プロセスは、以下の４つの相を含んでいる。

【００９６】 ０．予備ＦＯＥ相（図示してない）： 各ＦＥＡ受入れ軸毎に顧客設計制約を入手する。要求された保護帯によっ て、これらの各制約を変更する。これらの変更された顧客制約は、ＦＥＡ プロセスの検査のためだけに使用され、単に設計制約と呼ばれる。

【００９７】 １．ＦＥＡ支配相： システム統合者は、ＦＯＥ推定と推定エラー許容差とを一緒に組合わせて 要求された制約を満足していることが保証されている（確信度は、合格の ためのＡσ、または不合格のためのＲσによって定義されるより高い） か否かを決定することによって、ＦＥＡを開始する。

【００９８】 （ａ）もし、サードパーティブロックを検討したにも拘わらず、それでも 制約が侵犯されれば、その設計は不可能である。システム統合者は 、これらの形態によって満たされる１組のオプション及び制約を顧 客に戻さなければならない。

【００９９】 （ｂ）もし制約が受入れ可能なリスク内で満たされれば、ＦＥＡプロセス は完了する。

【０１００】 （ｃ）もし設計の合格または不合格を予測する確信度が受入れられない程 低ければ、推定相を開始しなければならない。推定相に入るために は、“最も合格しそうな”設計形態（即ち、最良）のセットを選 択しなければならない。

【０１０１】 ２．推定支配相： ＦＯＥステージから導出された最良設計のセットに関して、クリティカリ ティの識別（即ち、設計が制約妥当性検査に合格したことを確認するため に統計的に最も有望な含まれている各ブロックにエラー許容差を与えて） を行わなければならない。これは、あるブロックのためのＦＯＥ仕様予測 の分散のサイズ、及びそのブロックが当該設計制約に与えたインパクトの 両者の積であろう。

【０１０２】 推定は、可能な限り多くの非臨界的設計を切取り、残されたもののための 設計特定推定を生成することによって進めるべきである。

【０１０３】 （ａ）侵犯：上述した手順１（ａ）に類似。

【０１０４】 （ｂ）満足度：もし推定の精度を向上させても、または既存ブロックモデ ルを与えてＳＯＣ設計の全推定を構築しても、不確定のレベルが更 に低下しなければ（推定内に既に含まれているブロックによってエ ラー許容差が支配されているために、切取りの量を減少させても推 定が統計的に大きく改善されない）、最良設計をディッピング相に 引渡さなければならない。

【０１０５】 ３．設計・ディップ支配相： グローバルエラーが最も感受的であるブロック推定を精細化し、次いで推 定相通りに進行する。ＦＥＡが確認されるか、または拒否されるまで、こ のプロセスを繰り返し続ける。統計的なクリティカリティの定義は類似し ている。

【０１０６】 図２４は、本発明のＦＥＡ設計プロパティ精細化プロセスを使用して精細化さ
れた推定の正しさ曲線を示している。上述したＦＥＡ相０から３まで移動する精
細化プロセスを通して、精細化された推定の正しさ曲線上の予測されるエラー分
散は、図２２に示す推定の正しさ曲線のそれに比して大きく減少している。従っ
て、受入れるか、拒絶するかの決定は、図２４に示す精細化された推定の正しさ
曲線に基づいて行うことができ、一方このような決定を図２２に示す推定の正し
さ曲線に基づいて行うことも、または行わないこともできる。

【０１０７】 もし１つの検査相における利用可能な情報及びデータに基づいてＦＥＡ決定を
行うことができなければ、本発明は予測されるエラー分散を減少させるために、
設計プロパティ精細化プロセスを遂行する。精細化されたデータ及び情報に基づ
いて、本発明は次の相におけるＦＥＡ検査を遂行する。設計プロパティ精細化プ
ロセスは、以下の３つの面からなっている。

【０１０８】 （１）ＦＥＡデータ抽出プロセス； （２）ＦＥＡブロック精細化識別；及び （３）ＦＥＡアセスメント軸計量。

【０１０９】 図２５は、本発明によるＦＥＡデータ抽出プロセスを示している。システム設
計内の各ブロックに関連付けられた予測エラーのための“システムインパクトの
推定”を確立するための標準化メカニズム、またはプロセスが存在する。「ブロ
ック精細化識別」と称するこのメカニズムは、ＦＥＡシステム設計アセスメント
の各精細化相毎に、どの特定ブロックのプロパティに対して要求されたエラー境
界（ＦＥＡ設計基準−例えば電力、面積、性能等）をも決定することを可能にす
る。

【０１１０】 Ｌ(β)を、ＦＥＡ基準βを満足させる設計のために、何等かの要求された設計
マージンによって変更された、顧客が指定した限界とする。ＦＥＡ基準βに対し
て測定された設計の予測値をＥ(β)とする。「設計決定制約」、即ちＦＥＡ基準
βに対する合格／不合格として定義される設計の“許容される最大エラー”は、
DDC(β)＝｜Ｌ(β)−Ｅ(β)｜である。Ｅ(β)自体は、予測される“合格” に関
してはＦＥＡ基準のための受入れ領域内になければならず、予測される“不合格
”に関しては拒絶領域内になければならない。実際的言えば、“合格”のための
第１の場合には我々はAσ_system＜DDCであることを要求し、“不合格”のための
第２の場合にはRσ_system＜DDCであることを要求する。もしこの不等性が満足さ
れなければ、システム解析は決定・同等性結果を発生しない。

【０１１１】 一般に、平均推定Ｅ(β)は、システムアセスメントの先行相が発生したシステ
ム基準βの最終推定であることに注目されたい。即ち、「中粒アセスメント」ス
テージは、平均として「粗粒アセスメント」ステージの最終推定を取り、「細粒
アセスメント」ステージは、平均として「中粒アセスメント」ステージの最終推
定を取る。プロセスを開始するために、粗粒アセスメントステージは、先ず各Ｆ
ＥＡ基準毎の粗レベル予測値推定を確立することから入らなければならない。

【０１１２】 特定のＦＥＡ基準βに関して設計決定制約（ＤＤＣ）が評価されるシステムの
場合、ブロック推定に伴うエラーと、システムのための合計推定エラーとの間の
関係を確立しなければならない。ブロック推定に伴うエラーは、そのブロックの
ためのβ基準を推定することの固有エラーだけではなく、そのブロックの特定の
影響力、及び統合費用を推定することの困難さに基づくブロックエラーでもある
ことに注目されたい。従って、ブロック推定のエラーは、ＦＥＡ基準βのための
そのプロパティ、または欠如または定義（エラー）に基づくブロックの統合の困
難さの測度であるシステムクリティカリティ測度Ｃによって基準化される。シス
テムの合格（不合格）に関する決定は、σ_systemに対する｛Ｃ_block．σ_block｜
ブロックε システム｝のセットの関係、及び各ＦＥＡ基準毎の要求される不等
性Aσ_system＜DDC（Rσ_system＜DDC）を通して確立される。

【０１１３】 上に表されているシステム不等性に対して中立のクリティカリティ測度Ｃ_{bloc k} を含み続ける（即ち、σ_systemはクリティカリティ基準化ブロックエラーを組
合わせて表される式Ｃ_block．σ_blockから公式化される）ためには、Σ_blocks(
Ｃ_block)²＝１のようにクリティカリティ測度が正規化されることにも注目され
たい。これを評価するためのプロセスは、処理中のシステムプロパティのクラス
に僅かに依存して変化する。ＦＥＡの透視から、以下にそれぞれ記述されている
３つのクラスのシステムプロパティが存在する。 ・ 絶対（ブロック）制約（例えば、サイクル内遅延、スループット）、 ・ 相対（ブロック）制約（例えば、電力、面積、待ち時間、費用、スケジュ
ール）、 ・ 混合（ブロック）制約（例えば、品質）。

【０１１４】 簡易化のために、ＦＥＡ基準βに関して、ブロック設計制約としてＢＤＣを定
義する。ここに、設計受入れのための試験の場合はBDC_block＝A．Ｃ_block．σ_{bl ock} であり、設計拒絶のための試験の場合はBDC_block＝R．Ｃ_block．σ_blockであ
る。従って、各ＦＥＡ基準毎の、 ａ．絶対制約：決定品質結果を達成するために、各ブロック、またはその直接 の環境（例えば、ルーティングロードを含む、等）内に浸された各ブロッ クは、絶対制約に関してＤＤＣに合格しなければならない。数学的には、 絶対制約上での決定品質結果の達成は、 システム内の全てのブロックε に対して、BDC_block＜DDC を暗示している。

【０１１５】 ｂ．相対制約：もしシステム全体のブロック設計制約の自乗の合計がＤＤＣの 自乗よりも小さければ、決定設計制約結果が達成される。この制約はシス テム全体を構成しているブロックの間に分割されるという柔軟性を有して いるので、用語「相対」はアセスメントの受入れ可能なエラーとして使用 される。相対型の若干のアセスメント基準が、複数の制約を有し得ること に注目されたい。これの例は、待ち時間である（完全システムの有効アセ スメントに貢献する幾つかのクリティカルパスが存在し得るからである） 。数学的には、相対制約上での決定品質結果の達成は、全てのブロックエ ラーがガウス分布した独立確率変数であるものとして、 Σ_blocks(BDC_block)²＜DDC² を暗示している。

【０１１６】 ｃ．混合制約：混合制約は、相対及び絶対型の両制約を含む型である。例えば 「品質」は混合制約である。設計内のブロックは、その品質の測度が指定 された境界を越えることはできないが、システム全体の全ての品質アセス メントの合計も指定された範囲内になければならない。この場合、ブロッ クのためのＤＤＣ_block、並びに総合システムのためのＤＤＣ_systemの両 方が存在する。数学的には、混合制約システムプロパティの場合には、２ つの基準を満足させる必要がある。即ち、 (i) 全ての場合：ブロックε システム、BDC_block＜DDC_block、 (ii) Σ_blocks(BDC_block)²＜(DDC_system)²。

【０１１７】 図２６は、本発明によるブロック推定精細化の必要性を識別するプロセスを示
している。図示のように、ＦＥＡブロック精細化識別には、以下のものを含む３
つのステップが存在する。 １：絶対或は混合の拘束タイプの各ＦＥＡ評価規準に対して、絶対誤り許容差（
ＣＩＣ）を達成するために必要とされる作動レベルは決定される。絶対拘束の必
要性を満たすべくモデルを純化する副産物又は副作用として、相対的拘束と関連
された幾つかの誤り−バウンドも低減され得る。 ２：モデルが絶対拘束及び混合拘束タイプの絶対部分を満たすべく純化された後
に予測される誤りに基づいて、システムに対する残りのシステム−誤り許容差（
ＣＩＣ）が決定され、個別ＩＰブロック間で区切られる。この区切りは見積を構
築するために必要とされる作動を最小限に為すように規定されることになる。こ
の区切りの柔軟性はアセンブルされたシステム内におけるブロック各々に対する
寄与の規定された重要性によって加減される。これは誤り衝撃の認識を規定する
。留意することは、この問題が各ＦＥＡ軸に沿って許容できる誤り許容差に対す
る必要な作動を同時に最適化しなければならないことである。 ３：もし任意の段階でシステム適合性が提案されたＣＩＣを用いて決定出来なけ
れば、これは更に締め付けられる必要性があり、プロセスは、 （ａ）ブロックに対して、もし特定の絶対拘束が不十分であれば反復されるか、
或は （ｂ）システムに対して、もしチップに対する相対的拘束が不十分であるか、 の何れかで反復される。

【０１１８】 図２７を参照すると、本発明に従った、評価軸重要性（ＡＡＣ）の概念を規定
する表（テーブル）を含むＦＥＡ評価軸測定が示されており、もし適合すれば、
模範的な重要性尺度を含んでいる。このＡＡＣは、関係：ＩＳＩ＝ＡＡＣ＊ＥＥ
Ｅに基づく予想見積誤り（ＥＥＥ）を介しての予想システム衝撃（ＥＳＩ）に関
係している。

【０１１９】 図２７に示されるように、テーブルは以下のように５つの列を含んでいる。 （１）評価軸 ＦＥＡはこれら規準に基づいて測定される。 （２）拘束タイプ 各ＦＥＡ評価軸はそれに関連された１つ或は多数の拘束タ イプを有し得る。 （３）拘束分類 以上に規定されている分類 （４）経路指定改善 経路指定改善のタイプは、チップ経路指定の衝撃が特定化 されたブロック及びシステムの拘束と同一の誤り度である ことを保証する必要がある。 （５）重要性尺度 ＦＥＡ評価軸と関連された特定の重要度を測定する規格化 された方法 テーブルの幾つかの要素は経路指定重要性を調べる。経路指定重要性はブロッ
ク或はチップ入力パッドの任意の出力ピンに対して、ピン経路指定重要性＝（予
想正味長さ）＊（キャパシタンス／単位長さ）として規定されている。ブロック
経路指定重要性はブロックの出力ピンにわたってのピン経路指定重要性の合計で
ある。

【０１２０】 シンボルαは効果的な経路指定領域スカラーを示し、よって、α＊（経路指定
重要性）は経路指定重要性の単位及びスケールを領域適用数へ変換する。

【０１２１】 経路指定の結果としてのパワー（電力）消費は、線上の活動の見積を必要とす
る。これはブロック或は解像度のピン・レベルで為され得る。ブロックに適用さ
れた際、活動見積はＥ_blockとして示されるブロックの出力線上の平均活動から
誘導される。

【０１２２】 点接続は、幾つかのファンアウト点が共有バスの使用によって接続されるまで
任意のファンアウト点としてカウントする。共有バスは単一の個別ブロックとし
てカウントする。経路指定重要性はピンへの経路指定接続に関する予想困難性の
尺度であり、それ故に、ＦＥＡ不確定性の尺度である。

【０１２３】 留意すべきことは、数多くの評価軸が解像度の何等かのレベルで混合拘束とし
て識別され得、例えば、ＳＯＣ設計チップ・レベル拘束をブロック・レベル拘束
に区切るべく、領域は初期フロア・プランが規定且つ使用された後の混合として
規定され得る。しかしながら、急速ＦＥＡ期間中に使用される優勢拘束タイプが
リストされる。

【０１２４】 テーブルで使用された用語誤りは問題となっている特性に関するように誤りに
対するバウンドを言及している。経験データの分野の組織化 設計者経験はＢＢＤ方法論のシステム決定プロセスにおける決定的な部分であ
る。ＢＢＤ方法論は単一キー設計者或は設計技師に関連された経験の概念を「会
社設計経験」の概念まで拡張する。経験のこの一般的な「プール」は本発明の経
験のＢＢＤ分野（ＦＯＥ）と呼称される。

【０１２５】 ＢＢＤ方法の目的は、ＦＯＥの構築及び使用に対する４つの概念及び機構を提
案することである。これら概念は： ａ）データ収集−ＦＯＥデータを獲得及び初期化するための厳格なプロセスの定
義。 ｂ）データ分類−関連分類を発展するための情報分類及び機構。収集されたデー
タが、充分に分析され、外挿され、そして、蓄積された設計知識増大量として、
全体的に改善され得ることのそうした分類保証。 ｃ）データ証明−さもなければ「経験法則」数として呼称され得る「信頼性」の
正しい保証を構築するプロセスの定義。ＦＯＥデータを証明することはＦＯＥデ
ータベースから構築された見積が充分満足にバウンドされていることを保証する
ことになる。 ｄ）データ適用−ＦＯＥの設計プロセスへの適用のための機構。これはＢＢＤに
対するフロントエンド受容である。経験定義の分野 ＢＢＤにおいて経験の分野は、設計形式、設計目的、並びに、設計特性の重要
な測定に従って分類された先行設計の測定からのコンパイルされたデータとして
定義され得る。重要な特性は、領域、スループット、パワー、並びに、冗長性を
含み得る。経験に基づく見積の定義は同様の設計或は設計行動に係わる経験に基
づく系統だった予測である。これは、ＦＯＥ見積の定義がＦＯＥデータ用いての
経験に基づく見積を模範としている。

【０１２６】 留意されるべきことはこれが、問題となっている設計の特定分析を暗示しない
、或は、ハードウェア設計がこれまでの直接体験から実際に知られている場合、
そのハードウェアに必要された新しい行動の特定分析を暗示しないことでＢＢＤ
とは区別されることである。例えば、ＤＳＰコアは会社内で開発され得て、ＦＩ
Ｒ−フィルタ埋め込みルーチンはコアの先行する例示におけるその上でランする
。次いで要求され得ることは、その同一コア上をランするＦＦＴアルゴリズムの
実現可能性は考慮されることである。もしその第１経験法則がその設計に対する
ＲＩＦ操作を実行する際に観察される先行するアルゴリズム効率だけに基づくが
、ＦＦＴアルゴリズムに相当特有の詳細に入ることがなければ、これはＦＯＥ見
積である。

【０１２７】 経験の分野（Ｆｉｅｌｄ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）は先行する設計プロ
ジェクトのセット中から誘導された情報を明白に活用しなければならない。ＦＯ
Ｅデータはカタログに作成され、保存され、そして、規格データベースにわたっ
てアクセスされ得るように為す必要がある。

【０１２８】 設計に使用される経験に基づくデータには３つの異なる分類があり、データの
各フォームは特定の誤りプロファイルと関連されている。 ａ）プロジェクト・データ（Ｐｒｏｊｅｃｔ Ｄａｔａ）−プロジェクト時の設
計者要求見積。設計者は、ＦＯＥデータベースにログされると他の者の経験を活
用しないが、彼自身の未カタログ化の設計経験をより多く活用する。設計見積に
おける誤りは設計者誤り変動（Ｄｅｓｉｇｎｅｒ−Ｅｒｒｏｒ Ｖａｒｉａｎｃ
ｅ）によって付与され、該設計者誤り変動は一般的設計に対して観察されたもの
である。設計者誤り変動は、正確に結果を予想すべく、設計者能力の一般的履歴
を測定することから構築される。 ｂ）予想データ（Ｐｒｅｄｉｃｔｅｄ Ｄａｔａ）−記憶された特定プロジェク
ト無しの設計分類内において、設計者には現行のＦＯＥデータを拡張すべく自身
の最良の推測をパラメータ関係に付与するように要求される。この場合、拡張さ
れるＦＯＥデータはせいぜい単一の設計点から構成され得る。これに対する誤り
は、部分的には、パラメータ化誤りでの設計者の最良の推測によって特定される
が、結果を正しく予想すべく設計者能力の履歴によっても変更される。統計的な
独自性を仮定すれば、これら誤り変動は合計されることになる。 ｃ）照合データ−設計経験セットからの照合され、分類され、そして、パラメー
タ化されたデータ。このデータに直に関連された測定誤りの可能性があるが、こ
れはおそらくは些細なことであろう。主要誤りは測定結果とデータ・パラメータ
の変動によって予想される対応するものとの間の差として規定される。

【０１２９】 留意すべきことは、プロジェクト・データは、それが現行見積を将来設計へ全
く拡張しないのでＦＯＥデータのフォームではない。更には、プロジェクト・デ
ータはプロジェクトの終了時ではなく開始時に収集されので、カタログ化設計経
験に対して立証できない。これはそれが証明されていないことを暗示している。
設計の最終測定から収集された任意のデータはＦＯＥデータベースへ入ることが
出来、プロジェクト・データの精度対最終測定は会社に対する設計者誤り変動を
改善する。

【０１３０】 予想データはＦＯＥ種データと呼称される。予想データは同様の設計における
ＦＯＥ見積に直ちに付与され得る。

【０１３１】 受け取られたデータタイプの共通分類はＦＯＥデータの先のソースの双方へ適
用されなければならない。そうした共通分類は、受け取りデータの迅速な識別及
びカタログ化を可能とする。初期分類−仕様書はＦＯＥに対するプランニング段
階として見做され、データの入力／収集は構築段階である。ＦＯＥデータベース
における情報量は成長するので、改善プロセスが適用されて、誤り許容差を統計
的に観察されるもの以内までに低減するように為す。これらの段階の３つ全てに
平行するものがＦＯＥ証明プロセスである。

【０１３２】 先にリストされたパラメータは、プロジェクト固有ＦＯＥ見積を誘導すべく、
現行の一般的なＦＯＥデータから外挿するために使用される。外挿見積及びＦＯ
Ｅデータの間のそうした関係は、好ましくは、各設計分類に対して規定される。
各パラメータＦＯＥ関係は設計者個人の経験によって規定され得る（先の予想デ
ータを参照のこと）か、或はもし充分な情報が利用可能であれば、ＦＯＥデータ
の曲線の当てはめを介して経験的に特定化され得る。パラメータは、パイプライ
ン深さ、類似度、ビット幅、並びに、クロック速度等のそうした技術的変数を含
むであろう。

【０１３３】 留意すべきことは、ＦＯＥが設計ブロックにだけ適用されるものではなく、ブ
ロック間の相互接続にも適用されることである。そうした場合、ＦＯＥは一方の
分類のブロックと他方の分類のブロックとの間の経路指定のコストとして特定化
され得る。ブロックへの適用と同様に、相互接続に対するＦＯＥ見積もパラメー
タ化され得る。

【０１３４】 最大限精度での見積 ＦＯＥのキーとなる局面は提供されたデータに付与される最大限精度の見積の
一般化である。これは２重プロセスである。 ａ）改善−先に述べたように、改善は、見積の誤りを統計的に観察されるもの以
内までに低減するように為すプロセスである。即ち、特定範疇におけるＦＯＥデ
ータ量が小さいとき、データに対する誤り許容差は大きい。これは固有誤りによ
るものではなく、むしろパラメータ化データの他の特定設計に対する未知（又は
未試験）の適用性によるものである。審査された設計の数が増大すると、データ
の統計的拡散は直にパラメータ化予想に対して測定可能である。多数の場合が設
計の特定分類に対してカタログ化されると、パラメータ化方法の精度が充分に設
定されることになる。大きな相関誤りの識別（データの無作為拡散に対する）は
パラメータ関係の再考の動機付けとなり得る。 ｂ）分類崩壊−設計の異なる分類は接近によって相互に関係させられ得る。例え
ば、バタフライＦＦＴ具現化は設計の１分類であり得るが、全てのＦＦＴブロッ
クはこの設計に密接に近接しているように見られることが可能である。もし対象
の特定分類に関連されたデータ数が統計的に意味を持つには余りにも小さければ
、密接な近接ＦＯＥデータは一体的に又は一緒に崩壊されて、全見積誤りを低減
する。分類の一体的な崩壊はそれ自体で設計タイプにおける僅かな装置によって
誤りを誘発することになるが、考慮された設計数という意味での統計的改善はこ
の相違誤りを負かし得る。図２８に示されるような曲線を計算することが好まし
く、そこから最良の誤りの形態を精選する。

【０１３５】 それ故にＦＯＥに対するプロセス／使用モデルは以下のようになる。 Ｉ． 評価されているブロックに適用可能なブロック分類の選択 ＩＩ． その分類に対して充分なデータがあるか？（即ち予想誤りは充分か？
） ＩＩＩ． 密接近接の範疇を見積誤りが改善すべく途絶えるまで崩壊する ＩＶ． ＦＯＥ見積に対して予想誤りは充分か？ イェス−最良ＦＯＥ見積を戻して終了 ノー−進める Ｖ． 設計者にその設計に対する彼の最良推測を生成するように求める。（
これはＢＢＤの見積位相内への沈下であり得る。

【０１３６】 ＦＯＥ証明 ＦＯＥの証明はプロセスであり、そのプロセスによって収集されたＦＯＥ情報
が信頼性があるように示される。この証明プロセスは構築及び改善の段階中に見
積の誤りを設定する。

【０１３７】 証明には２つの局面がある。 ａ）完全性の証明−全ＦＥＡ計量は提供されたパラメータ化方式を介して測定可
能でなければならない。 ｂ）精度の証明−設計者に対する経験尺度と、収集データの精度を保証するプロ
セスの定義とを含む。 膠論理 本発明は改善された膠論理分布及び低減方法論を更に開示する。３つの代替的
な膠論理分布機構の組み合わせは本発明の好適実施例を含む。第１として、予備
設計されたブロック内に組み込まれていない膠論理は現行ブロックへの分布用に
多数コピーに複製され得る。第２として、ブロックにトップ・レベルで親和性を
有さない論理は小数ブロックとして残留させられ得て、最適には、効果的なゲー
ト独占化、配線密集度、並びに、仕入れ資金融資方法衝撃を最小化すべく据えら
れる。第３として、ブロック数がブロック場所及び経路指定限定を超えた場合、
膠論理がブロック・カウントが許容出きるレベルまで低減されるまで膠クラスタ
・ブロック内にクラスタ化され得る。

【０１３８】 図２９を参照すると、膠論理２９１０が相互接続されたブロック間に不都合に
も常駐している回路設計図が図示されており、それによってシリコン面積の大き
な領域の使用が非効率化されて、著しい配線密集を作り出している。

【０１３９】 図３０を参照して、より大きなトップ・レベルのブロックへの分布のための膠
論理の多数コピーを作り出す本発明の方法の説明を始める。要素３０１０が多数
付加を駆動する出力正味を有すれば、この要素は、各々が出力に対する単一のみ
の負荷を有している多数の要素３０１２内へこぼされる。次いで、複製された要
素を駆動する各入力「コーン（ｃｏｎｅ）」（不図示）も、全てのブロック出力
が達成されるまでコピーされる。同様に大きな入力ゲートは、木の頂部にオリジ
ナル関数の２入力ゲートを伴う非反転２入力ゲートの木にまで低減される。この
ようにして、実質的により多くの論理が先行する相当により小さな膠論理関数に
専用化される。しかしながら、より大きなブロック間の領域から膠論理を除去す
ることによって、それらより大きなブロックはより効率的に配置されて、正味効
率増大となる。

【０１４０】 分布のために効率的に複製できない任意の膠論理要素は、次いで、配置された
要素に最も緊密な親和性を有するより大きなブロック内に好ましくは合併される
。膠論理合併は多数の規準に基づいた様式で実行され、その内の最も重要なもの
は合併がトップ・レベルのピン・アウト数を低減するかどうかである。よって、
多数コピーが作り出されると、結果として論理の殆どが２入力ゲートから構成さ
れるので、そうしたゲートを１つのピンがそのブロックに接続されているブロッ
ク内へ合併することはピン・カウントを２だけ低減する。２つ或はそれ以上のブ
ロックが合併のための同等候補である際、最低のピン密度を有するブロックが好
ましくは選択される。最後に最低の優先権は、好ましくは、タイミング考慮へ行
く。

【０１４１】 次に図３１で参照されるように、合併できないゲート及び小さなブロック３１
１０とはクラスタ３１１２内にクラスタ化される。合併できないゲートも殆ど同
様にそれらの入力及び出力の両正味に対する多数負荷を有する。ゲートを同様な
関数を有する入力と再組合せすることによってゲート・カウントは低減され得る
。

【０１４２】 本発明は予備設計された回路ブロックを規格化されたインターフェースを有す
る回路へ変換する方法を更に開示する。

【０１４３】 図１におけるブロック設計段階１０６で実行されるタスクは：（１）選択され
た回路ブロックに対する任意の喪失アブストラクトを作り出し、（２）回路ブロ
ックをそれらのカラー（ｃｏｌｌａｒ）として既知の各規格化インターフェース
内へ埋め込み、そして、（３）カラー付けされた回路ブロックに対するアブスト
ラクトから成る完全セットを作り出す。

【０１４４】 図３２を参照すると、回路ブロックをカラー内へ埋め込む、本発明に従ったカ
ラー付けプロセスが図示されている。ＢＢＤ方法論において、選択された回路ブ
ロックはチップ・レベルでの主要な入力構成要素である。カラー付けプロセスは
回路ブロック各々の回りにカラーを据え付けて、回路ブロック境界回りに規格イ
ンターフェースを作り出す。カラー付けされたブロックをチップ・レベルへ首尾
よく統合するために、アブストラクトから成る完全セットをそのカラー付けられ
たブロックに対して作り出さなければならない。そのアブストラクトから成る完
全セットを作り出す前に本発明のシステムは、アブストラクトがブロックのモデ
ル若しくは風景、チップ・レベルでの組立で要求されるカラー付けブロックの設
計、或は、プランニング・ツールである場合、選択されたブロックに対する任意
の喪失アブストラクトを先ず形成する。模範的なアブストラクトは： （１）固定状態のタイミング・アブストラクト−ＴＬＦ （２）レイアウト遮断ファイル−ＬＥＦ （３）立証用モデル−ボルト締めバス・ブロック・モデル （４）システムへのブロックレイアウト拘束 図３３を参照すると、本発明に従った回路ブロックのアブストラクトから成る
完全セットの作成が図示されている一方で、図３４は図３２及び図３３に図示さ
れた特徴の組合せを図示している。

【０１４５】 次にカラー付けプロセスの説明に移り、規格インターフェースが設計に使用さ
れるべきブロックタイプ毎に規定されていると仮定している。ブロックの内の任
意のものが完全ブロック・アブストラクトを具備しなければ、このプロセスはそ
のブロックに対する完全ブロック・アブストラクトを形成する。

【０１４６】 次にこのプロセスは、それらブロック各々のブロック・タイプを識別する。特
に、ブロックは：メモリ・タイプ、プロセッサ・タイプ、パワー・タイプ、或は
、アナログ／混合信号タイプであり得る。しかしながら異なるソースからの回路
ブロックのタイプは異なるインターフェースを有し、それらインターフェースは
他の回路ブロックに接続すべく異なる設計を必要とする。例えば、異なる売り主
によって設計されたプロセッサは異なるインターフェース及びバス構造を有し得
る。

【０１４７】 次にこのプロセスは、識別されたブロックをその対応するインターフェース規
格と関連させる。

【０１４８】 その後、このプロセスはその識別されたブロックの特定インターフェースに接
続可能な構成要素を含む第１カラー部を作り出す。

【０１４９】 次の段階で、このプロセスはその識別された回路ブロックに関連されたその規
格インターフェースに準じた第２カラー部を作り出す。

【０１５０】 次いでこのプロセスはその特定のインターフェースをその規格インターフェー
スと接続可能なフォーマットに変換する構成要素を含む第３カラー部を作り出し
て、第１カラー部を第２カラー部に接続する。

【０１５１】 ブロック・カラーは多数の層から構成され得る。現行、２つのカラー層（ブロ
ック規格カラー及びシステム特定カラー）がＢＢＤ及びＳＯＣ用にそれぞれ規定
されている。図３５を参照すると、２層を含むカラーが示され、その一方のカラ
ーが特定ブロックに対する規格であり、他方がブロックが展開されることになっ
ている特定システムに特有のものとなっている。ブロック規格カラーは、特定シ
ステム或は統合されることになる特定前後関係の知識無しで規定され得るような
インターフェース構成要素を含む。例えば、ＢＢＤの前後関係において、特定の
設計グループはＪＴＡＧ規格試験インターフェースが設計で必要とされていると
決定し得る。よって、設計されるシステムの内の任意のシステムにおいて使用さ
れるべきブロックの全てに対して、ＪＴＡＧ試験インターフェースが規格となり
、よってブロック規格カラーに属する。システム特定カラー（或は適合カラー）
はブロックに属するインターフェース構成要素を含むが、システム或は前後関係
特定ではない。例えばデータ線に対する規格セットはパリティ・ビットを必要と
し得ないが、設計される特定システムに対してパリティ・ビットが全データ線に
対して必要とされている。パリティ・ビットを生成する論理は、チップ・プラン
ニング中、ブロックと関連させられ、システム特定カラー内に常駐すべきである
。

【０１５２】 ＢＢＤにおける２つのカラー間の別の相違は、ブロック規格カラーがフロント
エンド受容及びチップ・プランニング（チップ・プランニングは初期カラーが必
要とされたチップ・プランニング関数をより良好に実行すべく沈下プロセスの一
部として設計されることを要求し得る）に先行してつけられるが、システム特定
カラーはチップ・プランニング後にだけ付加され得る。

【０１５３】 ２つのカラータイプ間のより微細な相違は、ブロック規格カラーに対する規格
セットがＳＯＣにおける規格セットよりも範囲において相当に狭くなり得ること
である。例えば、特定のパワー・インターフェースはＢＢＤに対して規格となり
得るが、特定の会社に対してだけであり、その他の会社はブロックに対するその
規格パワー・インターフェースに一致する必要性はない。結果として、会社の外
側からのブロックはシステム特定カラーを必要とし、それは規格パワー・インタ
ーフェースを会社のものに変換する。これはＳＯＣとは対照的であり、そこでは
産業の範囲にわたるインターフェース規格が存在し、ブロック規格カラー内に常
駐している。ＳＯＣにおける最終ゴールは産業の範囲にわたる規格である規格カ
ラーを作り出すことである。そうしたカラーを有するブロックはソケットに入れ
られたブロックと呼称される。将来、もしカラーの局面の全てが産業の範囲にわ
たるものであれば、システム特定カラーの追加的な層状化の必要性はなく、よっ
てブロックはプラグ・アンド・プレイの理想へより近づけられる。

【０１５４】 システム特定カラーへの別の次元は、それがチップ・プランニング後に設計さ
れることが意図されているが、チップ・プランニングにおいてシステム特定カラ
ーを作り出すことによってチップ統合化プロセスをスピードアップすることがで
き、システム特定カラーが標的とされるべき範囲を獲得するためのパラメータで
ある。これは統合化プロセスを加速し、その理由としては、チップ・プランニン
グ後、パラメータのみが変動される必要性がある一方で、システム特定カラーは
スクラッチから再設計される必要性がないからである。

【０１５５】 カラー及びブロックはソフト、ファーム、並び、ハードの様々な組み合わせで
あり得る。ブロックのハード性に関して長所及び短所があるのと同じように、カ
ラーのソフト性、ファーム性、並びに、ハード性の長所及び短所がある。例えば
、もしブロック自体がソフトであれば、そのブロック規格をソフトのままとして
、システム特定カラーが追加される際、ブロック全体が合成化、据え付けられ、
そして最終的なレイアウトへの変換用に平坦となるように経路指定され得るよう
に為すことが適切である。しかるにもしブロックがハードであれば、小量のみの
規格機能変換を伴う物理的インターフェース発行を際だって取り扱うべくハード
・ブロック規格カラーを使用することが適切であり得て、それはシステム特定発
行を取り扱うソフトのシステム特定カラーが殆ど機能変化を含むからである。

【０１５６】 カラーは、以下のような方法でブロック特異的インタフェースを標準的なイン
タフェースに変換する。すなわち、 （１）ブロックに特異的な物理的コンフィギュレーションを標準的な物理的コ
ンフィギュレーションに変換することで、ピン層、ピン配置、及びピン分離が含
まれ、 （２）ブロックに特異的な電源を標準的な電源に変換することで、電源ローデ
ィング及び物理的配置が含まれ、 （３）ブロックに特異的なテストプロセスを標準的なテストプロセスに変換す
ることで、テストアクセスポート（ＴＡＰ）コントローラ及びテストプロトコル
が含まれ、 （４）ブロックに特異的なタイミングを標準的なタイミングに変換することで
、セットアップ及び保持タイマーフリップフロップ、又はラッチが含まれ、 （５）ブロックに特異的なクロックポートを標準的なクロックポートに変換す
ることで、クロックポートの各々のローディングが含まれ、 （６）ブロックに特異的なデータ／制御信号を標準的なデータ／制御信号に変
換することで、信号ポジティブ／ネガティブ表明を標準化することが含まれ、さ
らに、 （７）効力のある入力を期待するブロックに対してレジスタを全てのサイクル
、大きいエンディアン（ｅｎｄｉａｎ）又は小さいエンディアン（大きいエンデ
ィアンはデータ単位の左端に０ビットを有し、小さいエンディアンのものは右側
にある）加えることで、ブロック特異的なバスインタフェースを標準的なバスイ
ンタフェースに変換する。

【０１５７】 また、カラーはカラー化ブロックのための余分な機能を実行するために、ブロ
ックコンポーネント（上記したように、グルー論理）を含むものであってもよい
。グルーは、３つのレベルで存在することができる。すなわち、（１）カラーの
中に配置されたグルー、（２）チップレベルで結合されたグルー、及び（３）チ
ップレベルで１つ以上の小さなブロックに配置されたグルーである。特に、グル
ー論理は単純機能的トランスレータ（例えば、ビットラインの各々に沿ったＮＡ
ＮＤゲート）からより複雑な機能（例えば、レジスタ、アキュムレータ等）まで
何でも含むことができる。グルー論理は任意の大きさであるが、もしグルーサイ
ズがブロックに対して著しく大きくなると、フロントエンドアセンブリの間で推
定が行われ、グルーサイズが考慮されていないことからチッププラニングが不正
確となる。ブロックに対するグルーの相対的サイズに対して制約条件が加えられ
る必要があるかもしれない。

【０１５８】 前提条件のセットが以下のようにカラーリングプロセスで使用される。すなわ
ち、 （１）グルー論理を加えるかどうかの判断はチッププラニングで行われる。

【０１５９】 （２）グルー論理の３つのタイプ（カラーに置かれたグルー、チップレベルで
の組み合わせグルー、チップレベルでミニブロックに置かれたグルー）について
、カラーリングプロセスは、好ましくはカラーに置かれたグルーのみにアドレス
する。

【０１６０】 （３）アスペクト比の問題が合成の間に処理される（ブロックカラーリングで
は処理されない）。

【０１６１】 （４）ＢＢＤに関して、カラー化ブロックの出力がレイアウトされる。

【０１６２】 図３６は、本発明にもとづいて上記したカラーのいくつかの代表的機能を説明
するためのもので、カラー６０２とブロック６０４との間の論理図が示されてい
る。

【０１６３】 図３６に示すように、カラー６０２は３つの異なる機能を実行する３つの部分
を含む。第１の部分はブロック６０４の境界部分周辺の特定インタフェースに対
して接続可能なコンポーネントを含む。第２の部分は標準に従って入出力コンポ
ーネントを含む。さらに、第３の部分はブロック６０４から標準へ出力を変換す
るためにコンポーネントを含む。

【０１６４】 特に、カラー６０２において、バスインタフェース６０６は双方向性のバス６
１２の中に２つの一方向性バス６０８及び６１０を結合する。テストアクセスポ
ート６１４は、ブロック６０４から情報を得て該ブロック６０４上でテストを実
行するために入力６１６に接続している。ゲート６１８は入力される信号をブロ
ック６０４に適したフォーマットに変転させ、ゲート６２０〜６２４はクロック
バッファリングを実行する。

【０１６５】 図３７は、本発明にもとづいて上記したカラーのいくつかの代表的機能を説明
するためのもので、カラー７０２とブロック７０４との間の物理図が示されてい
る。図３７中、カラー７０２及びブロック７０４は共に多数の金属層を含んであ
る。金属層３（Ｍ３）上にＶｄｄ電圧を配置し、金属層４（Ｍ４）にＧＮＤを配
置するために電源標準が存在する。もしブロック７０４が電源標準に従わない場
合は、カラー７０２は電源を従うように変換する。領域７０６はピン間隔／層標
準を設定する。もしブロック７０４がピン間隔／層標準に従わなければ、カラー
７０２はそれをピン間隔／層標準に従うように変換する。カラー７０２はまた、
硬い状態でグルー７０８を含む。

【０１６６】 図３９は、本発明のカラーリングプロセスを用いないシステム設計８００を示
している。図３８に示すように、システム設計８００は４つの回路ブロックＡ、
Ｂ、Ｃ、及びＤから構成される。ブロックに接続した各矢印線は、そのブロック
のインタフェースを設計するための制約条件を表す。したがって、もしシステム
がｎ個の回路ブロック（例えば、この実施例ではｎ＝４）から構成されるもので
あるならば、任意の特定のブロックに対するインタフェースはｎ−１セットの制
約条件まで満足させる必要があるかもしれない。したがって、全てのブロックに
対して満足させられる必要がある制約条件の全体の数は０（ｎ２）である。

【０１６７】 図４０は、本発明のカラーリングプロセスを用いるシステム設計９００を示し
ている。システム設計９００は４つの回路ブロックＡ、Ｂ、Ｃ、及びＤから構成
される。ブロックに接続した各矢印線は、そのブロックのインタフェースを設計
するための制約条件を表す。本発明のカラーリング／プロセスを用いることで、
各ブロックはカラーリングインタフェースによって定義された１セットの制約条
件を満足させることのみが必要である。したがって、もしシステムが回路ブロッ
ク（この実施例ではｎ＝４）から構成されるならば、全てのブロックを満足させ
るのに必要な制約条件の全体的な数は０（ｎ）である。

【０１６８】 図３８は、本発明にもとづいて、ここで議論されるカラーリング及び他の独創
的なＢＢＤプロセスのためのステップを実行するコンピュータシステム１０００
を示す。コンピュータシステム１０００は、システムバス１００１、処理ユニッ
ト１００２、メモリデバイス１００４、ディスクドライブインタフェース１００
６、ハードディスク１００８、ディスプレイインタフェース１０１０、ディスプ
レイモニタ１０１２、シリアルバスインタフェース１０１４、マウス１０１６、
及びキーボード１０１８を含む。

【０１６９】 ハードディスク１００８は、ディスクドライブインタフェース１００６に結合
し、モニタディスプレイ１０１２はディスプレイインタフェース１０１０に結合
し、さらにマウス１０１６及びキーボード１０１８はシリアルバスインタフェー
ス１０１４に結合している。システムバス１００１に結合しているものは、プロ
セッシングユニット１００２、メモリデバイス１００４、ディスクドライブイン
タフェース１００６、及びディスプレイインタフェース１０１０である。

【０１７０】 メモリデバイス１００４はデータ及びプログラムを格納する。ディスクドライ
ブインタフェース１００６とともに動作することで、ハードディスク１００８も
またデータ及びプログラムを格納する。しかし、メモリデバイス１００４はハー
ドディスク１００８よりも速い速度でアクセスされ、一方ハードディスク１００
８は、一般にメモリデバイス１００４よりも容量が大きい。

【０１７１】 ディスプレイインタフェース１０１０とともに動作することで、ディスプレイ
モニタ１０１２は実行されたプログラムとユーザとの間にビジュアルインタフェ
ースを提供し、該プログラムによって生成された出力を表示する。シリアルバス
インタフェース１０１４とともに動作することで、マウス１０１６及びキーボー
ド１０１８はコンピュータシステム１０００に対する入力を提供する。

【０１７２】 プロセッシングユニット１００２（複数のプロセッサを含むものであってもよ
い）は、メモリデバイス１００４及びハードディスク１００８に格納されたプロ
グラムを実行することでコンピュータシステム１０００の動作を制御する。プロ
セッシングユニットはまた、データ転送の制御とメモリデバイス１００４とハー
ドディスク１００８との間のプログラムの制御とを行う。

【０１７３】 本発明では、ここで議論するステップを実行するためのプログラムを、本発明
が関係する当該技術分野の当業者によって理解されるように、メモリデバイス１
００４又はハードディスク１００８に格納することができ、またプロセッシング
ユニット１００２によって実行することができる。

【０１７４】 バス識別及びプラニング 本発明の方法は、フロントエンドアクセプタンス（上述）の間で定義されるよ
うに、エンドユーザ又は設計チームによって望まれたシステムの全体的な設計の
パフォーマンス要求を満たす。パフォーマンスが本発明の設計方法に対する主な
検討を要求する一方で、第２の検討はバスタイプ選択の間にゲートカウントを減
少させることである。なぜなら、バスサイズは大きく、単純なバスは小さな、よ
り複雑なものよりも多くの論理を消費するように利用可能なバスタイプ間で変化
することができる。

【０１７５】 最初に図４１にもどると、本発明の方法を含む一連のステップが図示されてい
る。ステップ４１１０で、カスタマーの一次仕様のフロントエンドアクセプタン
スが完了する。このステップの詳細は上に述べられている。次に、ステップ４１
１２では、定義済み要求が以下に例示するように分析される。ステップ４１１４
では、バスクラスタリングがプラニングされ、一方で、レイテンシー、バンド幅
、方向、及びブロックの各々に対する存在するインタフェースを含む変数が十分
に分析され、バス分類法レファレンスライブラリに対してステップ４１１６で参
照が作られる。次に、ステップ４１１８で、新たなバス仕様が発生し、コンプラ
イアンスの組及びバスモデル検証サブステップの生成が含め、ステップ４１２０
で新たな仕様が検討される。ステップ４１１８及び４１２０は、アービタ及びブ
リッジをカバーする新たなブロック仕様が生成され、カラーを含むブロック仕様
が修正され、グルー仕様が定義され、テストベンチが生成されるブロックプレス
テージングステップ４１２２を参照して実行される。

【０１７６】 我々は、フロントエンド仕様をトップレベルのバス指定に翻訳することが含ま
れるバスプラニングについて説明する。利用可能な技術では、システム設計者は
高レベル機能モデル又は設計されているシステムの仕様でスタートする。類似の
システムのシステムノウハウ及び知識を用いて、設計者は該設計のためのバス構
造のハイレベルな図を組み立てる。設計者は一般に各々のバス上のトラフィック
についての大まかなアイデアを有し、いくつのバス、及び何の複雑さが必要とさ
れているかについて推定することができる。バスは、要求されたシステムパフォ
ーマンスを満たすように、また一方でインタフェースを最小限にするように設計
される。次に、設計者はこのアーキテクチャを用いてバス機能モデルを精製し、
該設計が仕様で定義されたように動作するかを確認する。この伝統的な方法は、
結果がノウハウや設計者の過去の経験によって変化することから数量化すること
が難しかった。ここに定義されたタスクは、チップ設計においてバス構造を定義
するプロセスに対して正式の構造を適用する。しかし、そのようなタスクは、最
良の結果を達成するために関連するバス及びシステム開発技術における平均的な
レベルの技量を必要とする。

【０１７７】 バスプロトコル バスは、設計内で回路ブロック間の好ましい通信媒体を提供する。最も簡単な
形態にあるバスは、僅かな論理を必要とするが多くのワイヤは必要としない点間
接続の集まりとすることができる。単純なバスは各クロックサイクルでブロック
間でのデータの移送を行う。いくつかのブロックがこのタイプの情報転送を必要
とする一方で、システムの殆どのブロックが時折他のブロックからの情報を必要
とする。チップピンは大きなシステム設計では非常に高価であることから、パフ
ォーマンスを殆ど失うことなくシステム内で必要とするチップピンの数を減少さ
せ、かつ多くの異なるブロック間での周期的な通信を可能とするためにバスが一
般的に使用される。このことを行うことで、データ転送スケジューリング問題、
例えばどのブロックがバス線を使用することができるか、データが送られるのは
どのブロックか、いつ送信者がデータを送ったか、さらに受信者がデータを得た
かどうか等を把握するために設計者はブロックの各々に論理を加えなければなら
ない。これらの問題はバス上の制御信号及びブロック（バスプロトコル）間の通
信を制御するためのプロシージャを確立することによって処理される。

【０１７８】 バスプロトコルの２つの例が周辺機器バスとパケットネットワークである。単
純な周辺機器バスプロトコルで、１つのデバイスが該バスを制御する。全ての情
報及びデータはこのデバイスを貫流し、ブロックがデータを送信又は受信する一
度に１つのケースを決定する。周辺機器バス処理が相対的に小さい論理を必要と
するが、バス線を効率よく使うことなく、また非常にフレキシブルではない。パ
ケットネットワークプロトコルは比較的複雑である。どのブロックがデータを送
り、またどのブロックがそれを受信しなければならないかについての情報全てが
データと共にパケットに格納される。パケットプロトコルは、任意のブロックを
任意の他のブロックへ任意の時間にデータを送るようにする。このプロトコルは
、非常にフレキシブルであり、バス線を効率的に使用するが、各ブロックはパケ
ットがいつ送られ、またそれが受け取るパケットを解読するかを知るために多く
の論理を必要とする。他のバスプロトコルは異なるレベルのフレキシビリティ、
利用度、及び遅延（バス上で１つのブロックから別のブロックへの情報の転送に
おける最初の遅れ）を有するフレキシビリティの異なるレベルを有する。異なる
バスのタイプ及びそのプロトコルは図５９に示されている。

【０１７９】 本発明のＢＢＤバス設計方法は、好ましくは異なるバスタイプを使用する。設
計者はオーサーブロックの部分であるかどうかにかかわらずスクラッチからバス
が生ずるとは期待していない。また、設計者は、複雑なバスによりも既存の十分
に定義されたバス・タイプで論理的にブロックを接続する。したがって、本発明
のＢＢＤ方法はブロック間の単一の接続としてのバスを処理する。バスが外部と
通信すること許すためのグルー論理があるように、またグルー論理セクションで
既に説明したように、バスの論理は、好ましくは設計のブロックの間で好ましく
は分散される。

【０１８０】 全ての論理相互接続は単純又は複雑なバスのいずれかとして扱われる。相互接
続の単純な形態は、バス接続規則によって定義されるが、複雑なバスの特定のプ
ロトコルは好ましくは定義されない。本発明のＢＢＤ方法は、階層を有し、ブロ
ック内に完全に含まれ、ブロックの外にあるワイヤを有し、論理階層の１つのレ
ベルに完全に含まれ、物理的階層の１つのレベルに完全に含まれ、ＶＳＩのオン
チップバス（ＯＣＢ）属性仕様に従って、さらにコンプライアンストランザクシ
ョンベクターによって確認される。また、ＢＢＤの範囲外にある条件の多くは、
好ましくは本発明のＳＯＣ方法でサポートされる。

【０１８１】 バスは、好ましくはブロックの中に完全に含まれるか、又はトップ階層レベル
で相互接続として定義されるかのいずれか一方である。トップレベルで定義され
たバスは、そのレベルで生成され、ブロック間又はブロック内に分散されるバス
コンポーネントを可能とする。

【０１８２】 ＢＢＤチップのバスを定義するために、以下のステップが実行される。

【０１８３】 バス要求の抽出 クラスタリングに基づいたバスの定義 バスの選択 バス設計の特定 バス分類法の参照 バス選択の確認 ブロック設計想定 ＢＢＤの方法では、設計者がバス設計を特定した場合、該設計者はブロック構
造に接続しなければならない。このタスクは、もしハードブロックが特定のバス
インタフェースを含むならば、そのインタフェースはカラーを参照して既に仮定
されたように、柔らかいと仮定することができる。また、全てのタイプのブロッ
クがバスインタフェース論理とブロックの実際の機能との間で単純かされたイン
タフェースを含むと仮定する。このことは、周辺ブロックに対しては理由のない
仮定である。なぜなら、多くのサードパーティブロックプロバイダはユーザがバ
スインタフェース論理を加えることができるよう、単純化したインタフェースを
生成する。多数の設計に対して仕立てられるブロックは、最初の機能とバスイン
タフェース論理とを離れさせる。内部インタフェースは、異なるバスでそれらの
ブロックを再利用することを可能とする。内部機能から分けることのできない特
定のバスインタフェース論理をハードブロックが有する場合、より複雑なバスプ
ロトコルトランスレーションがブロックに再送点されてもよい。いずれの場合も
、結果として生ずるバスインタフェースがブロックを設計している間に生成され
た柔らかいカラーの部分になる。 バス必要条件の抽出 フロントエンドアクセプタンスタスクから受け取ったデータは、バスネット、
信号ネット、及びブロックの各々上にあるピンを含む。信号ネットには４通りの
カテゴリーがある。（１）事前に設定されたバス信号であり、プロセッサ等のあ
る種のブロックによって要求された、ＰＣＩ又はＡＭＢＡバス等のバスから構成
されるブロックピン又はネットである。（２）バス信号であり、該信号はピン及
びバスに違いないネットであり、例えば読み出し及び書き込み信号である。（３
）起こりうるバス信号であり、ワイヤ又はブースかもしれないブロックピン及び
ネットであり、（４）信号、ワイヤネット又であってバスによって処理されない
。

【０１８４】 設計者が単一タイプを決めた場合、フロント・エンド・アクセプタンスから受
信したデータは、信号ネットのそれら４通りのタイプに基づいて維持される。タ
イプ１及び２のネットは、バスを生成するために必要なデータは、カスタマーに
よって、又はさもなければ入手可能のいずれかいっぽうによって提供されなけれ
ばならない。必要なデータは、さらにＶＳＩのオンチップバス（ＯＣＢ）属性仕
様ＯＣＢ１ １．０（ＶＳＩ’ｓ Ｏｎ−Ｃｈｉｐ Ｂｕｓ （ＯＣＢ） Ａｔ
ｔｒｉｂｕｔｅｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＯＣＢ １ １．０）よって
さらに定義される。なお、この仕様をこの明細書で援用する。

【０１８５】 また、設計で特定又は使用されるかもしれない各バスは、バスを生成するのに
十分な完全なユーザガイド、明日の物理的要求を定義する実装ガイド、バスをテ
ストし、かつ検証するためのシミュレーションツールの完全セット、及び技術的
属性とどのようにしてバスをリストと比較するかについてのリストを持たなけれ
ばならない。また、ＶＳＩのオンチップバス（ＯＣＢ）属性仕様に従うバスを生
成するために、ベンダーは後述するドキュメンテーション及びモデルを提供しな
ければならない。

【０１８６】 ユーザガイド及びシミュレーションツール ユーザガイド及びシミュレーションツールはバス設計で使用され、それによっ
てバスコンポーネントの形成及び試験が行われる。シミュレーションツールのセ
ットは、以下の要素の行動的ベリログ（Ｖｅｒｉｌｏｇ）及び／又はＶＨＤＬで
記載されたモデルが含まれる。すなわち、該要素は、バスマスタ、バススレーブ
、バスサポート機能（アービタ、アドレス、デコーダ）、及び標準バスブリッジ
である。これらは、バス検証に関連したセクションで記載されている。

【０１８７】 実装ガイド 実装ガイドはバスの属性を記述するためにプラニングされたチップ設計におけ
るブロック設計、チップアセンブリ、及びその後のタスクで使用される。以下の
情報はブロック仕様の一部分としてブロック設計に渡される。すなわち、求めら
れた固有のセル、該セルの物理的特性、バス多重化又はステアリングオプション
、メモリマップ、電力配分、及びタイミングガイドラインである。タイミング及
び最大負荷ガイドラインもまたチップ設計プラニングの次のサブステップで使用
される。バスレイアウト又は配線に対するタイミングガイドライン、最大負荷、
及び制限はバス実装で使用するためにチップアセンブリタスクに渡される。

【０１８８】 技術的属性リスト 技術的属性はバス分類法参照ライブラリでバス属性として維持することができ
る形態に翻訳されなければならない。したがって、バス分類法参照及びバスタイ
プテーブルはバスタイプを選ぶために設計者に使用される。事前定義バス信号に
対して、設計者は要求された接続が最大負荷及びタイミングガイドラインに適合
することができるか、さらにバスレイアウト及び肺炎制限がチップアセンブリの
際に適合するかどうかを確かめる。もし適合しなければ、設計はフロントエンド
アクセプタンスタスクに送り戻されカストマーによって修正される。

【０１８９】 クラスタリングにもとづいたバスの定義 クラスタリングにもとづいたバスを定義するために、設計者はフロントエンド
アクセプタンスで受信した相互接続バンド幅及び遅延を使用する。このステップ
は、クラスタの各々及び該クラスタ内のブロックに対して、バンド幅、存在して
いるバスインタフェースのタイプ、及びデータフローの方向を決定する。続いて
、この情報は次のステップに送られて、バスの選択がなされる。

【０１９０】 バス階層は、最も高いバンド幅及び最も低い遅延バス相互接続をクラスタリン
グすることで定義される。ポイント間ネットである可能バス信号は、この及び次
のバス分析及び設計から除去することができる。なぜなら、そのような信号はル
ーティングのためのチップアセンブリタスクに対して直接与えられるからである
。

【０１９１】 通信マネージャ挙動モデルの生成 検証されたようなチップの挙動モデルは、ブロック間相互接続の挙動モデル及
びアブストラクトモデルを含む。一般に、この相互接続はテストベンチとブロッ
クとの間でデータを転送するソフトウェア機構である。理想的には、通信マネー
ジャの形態、おそらくスケジューラであり、これに全てのブロックが接続される
。一方で、相互接続は挙動モデルにおいて直接接続されたポイント間インタフェ
ースでもあってもよい。

【０１９２】 通信マネージャ又は、後述するように、スケジューラはトップレベルのシミュ
レーションモジュールである。そのようなスケジューラの仮コードは以下のよう
なものである。すなわち、 キューが空ではないときは； キューから次のトランザクションを得る； トランザクションからターゲット・ブロックを得る； ターゲット・ブロック（トランザクション）を呼び出す； 終了； この仮コード例では、各ブロックは以下のことを行う： ターゲット・ブロック（トランザクション） ブロック機能を行う； キューに対して新しいトランザクションを加える； 終了； このコードレベルでは、タイミング及びバスサイズともに定義されていない。
全ての通信がトランザクションで行われ、又は任意のサイズの情報パケットを転
送することによって行われる。トランザクションは、ブロック間の全ての通信が
スケジューラを通して行われるように可能なバス信号と非バス線とを含むもので
あってもよい。

【０１９３】 一方、設計者はブロック仮コードを修飾して非バス信号を非同期的に送信及び
読み取りを行うことができる。この場合、各ブロックは以下のことを行う。すな
わち、 目標ブロック（トランザクション）； トップレベルから非バス信号値を得る； ブロック機能を行う； キューに新たなトランザクションを加える； 新たな非バス信号値をトップレベルに与える； 終了 単純化のために、これらの例が非バス信号を含まないことを指摘しておくべき
である。しかし、設計者は上記例に対して同様の調整を施すことで非バス信号を
含めることができる。

【０１９４】 パターンセットは１つのブロックを他のブロックと通信させるテストベンチの
ベクタのコレクションである。テストベンチは、チップ全体の機能性を実行する
のに十分なパターンセットを含むものでなければならない。設計者は目標パフォ
ーマンスレベルを粗野なレベルでパターンセットの各々に割り当てなければなら
ない。例えば、もし１つのパターンセットにＭＰＥＧデコーダのフレームデータ
が存在するならば、設計者はどれぐらい長く目標ハードウェアがそのセットで該
フレームの処理にかかれるかを定義しなければならない。もし、設計者が出力速
度を１秒あたり約３０フレームとしなければならないことを知っているならば、
処理速度はその数を超えなければならない。これらのパフォーマンス目標は、必
要とされるバスバンド幅を定義するためにこのプロセスの次の段階で使われる。

【０１９５】 チップのために選択されたブロックは、若干のサイクル近似的パフォーマンス
仕様を有するものでなければならない。もし挙動モデルが既にそのような仕様を
持つならば、このステップでモデルに取り込まれるべきである。

【０１９６】 図４２は、挙動モデルの相互接続セクションの内部構造を説明するためのもの
である。第１に、テストベンチ及び要求条件が受信される。次に、予備のスケジ
ューラが生成される。相互接続マネージャ／スケジューラ４２１０は設計のブロ
ック間で情報を伝送し、該ブロックの実行の予定を立てる。相互接続４２１０は
、次に修正され、かつ修正された相互接続マネージャ４２１２は統計値ギャザリ
ングを含み、モデルとして加えられる遅延マトリックスがサイクル近似的オペレ
ーションに調整される。最後に、テストベンチはテスト及び設計繰り返しのため
に再び利用される。これらの変更の詳細は以下に続くセクションで説明される。

【０１９７】 遅延を説明するためのモデルの修正 いくつかの設計は特定の遅延要求を持たない。他の設計、例えばハブ及びスイ
ッチはデータ遅延（データの最初のユニットが送信元から受信元へ送られるに要
した時間の長さ）に敏感である。殆どのネットワークデバイス、特に非同期転送
モード（ＡＴＭ）デバイスは、ネットワーク内のコンポーネント及びバスのため
の緊密な遅延要求に翻訳される情報転送のための特定の遅延要求を持つ。ひとた
び設計者が設計のための遅延要求を知ると、該設計者は以下のように相互接続を
調整する。最初に、（１）ブロック間で転送されるデータの量と（２）実行され
たトランザクションの数とを特定する各パターンセットに対して２つのマトリッ
クスを生成する。第２に、サイクルカウント近似を特定する各パターンセットに
対してマトリックスを生成する。この第２のステップは遅延要求がない設計に対
しては必要ではない。

【０１９８】 データ転送マトリックス データ転送マトリクスを作成するために、設計者は先ず１つのブロックから別の
ブロックまで転送されているデータ量をコミュニケーションマネージャーモデル
に加える。次に、スプレッドシートツールを使用して、設計者は各パターンセッ
トのためテーブルにこのデータを蓄積する。 例えば、３つのブロック及びテストベンチを有するチップ用テーブルは、バイト
の状態でテーブルの各項目に転送されたすべてのデータの合計を有するテーブル
からテーブルまで４×４になるはずである。対角線方向はすべて０になるはずで
ある。より多くの実用的なモデルでは、チップの中へ及びチップの外へ進むバス
を考慮に入れると、テストベンチが各評価軸の項目より多くを有することになる
ことに留意されたい。 データ転送マトリクスの例を図４３のテーブルに示す。このマトリクスの背後に
ある設計には、テストベンチのための ３つのブロックと３つのポートがある：外部メモリへのインターフェース、ＰＣ
Ｉインターフェース及び並列Ｉ／Ｏインターフェースである。テーブルに示すよ
うに、ブロック１からブロック２へ転送されたデータは１０，０００バイトであ
り、かつブロック２からブロック１へ転送されたデータは８，０００バイトであ
る。 このように、データ転送マトリクスを作成する第１ステップは模範的パターンセ
ットＸのトランザクションを示す図４４に示すように、すべてのトランザクショ
ンの総計でテーブルを作成することである。 図４３及び図４４に示すテーブルを作成するには、設計者は次のようにスケジュ
ーラ擬似コードを修正してもよい： 列が空白ではない間に、 列から次のトランザクションを取得する； トランザクションから送信ブロックを取得する； トランザクションからターゲットブロックを取得する； トランザクションバイトカウントを取得する； トランザクションマトリクス（送信側、目標）＝トランザクションマトリクス（
送信側、目標）＋１； トランザクションマトリクス（送信側、目標）＝トランザクションマトリクス（
送信側、目標）＋トランザクションバイトカウント； 目標ブロック（トランザクション）呼出す；Ｅｎｄ； を行う。 非バスブロックからブロックへのワイヤにはある遅延（代表的には、１クロック
サイクル）があるので、バストランザクションの他にタイミング列における分離
したトランザクションとしてこれらを加えることが好ましい。 待ち時間マトリクス 各ブロックのクロックサイクルタイムがフロントエンドキャパシタンスですでに
定義されているため、設計者は原パフォーマンスを次のようにサイクルカウント
に翻訳することができる： １．それらの仕様で定義されたサイクルに近い動作を反映するため、設計者はそ
の既存挙動モデルに各ブロックの予測クロックサイクルを加える。このステップ
は送るブロックをブロックデザインタスクへ送信する前、しかし検査の後に実行
することが好ましい。 ２．設計者はブロックをチップモデルに一体化する。チップモデルは相互接続で
同時に定義されたサイクルに近いブロックを有することになる。 ３．設計者はスプレッドシートを使用して図４３及び４４に示すそれに類似のテ
ーブルをセットアップする。転送されたバイトの数の代わりに、設計者はデータ
が利用可能になる時間からデータが次のブロックまたはテストブロックに到着す
る時間（待ち時間）までのサイクル数を各転送受取り量に指定する。 ４．設計者は、新しいテーブルに示したパフォーマンス値を使用するため相互接
続モデルを修正する。 図４５に模範的待ち時間マトリクスを示す。これらの修正の疑似コード例を次に
示す： 列が空白ではない間に、 列から次のトランザクションを取得する； トランザクションから時間を取得する； トランザクションからターゲットブロックを取得する； ターゲットブロック（トランザクション、時間）を取得する； Ｅｎｄ；を行う。 ここで、各ブロックは次を実行する： ターゲットブロック（トランザクション、時間）； ブロックの機能を実行する； トランザクション時間を時間＋遅延＋待ち時間（このブロック目標）； 列に対する新しいトランザクションを並べ替える； Ｅｎｄ。 図４４の「０」を読取る項目が、データが転送されずかつ待ち時間マトリクスに
適用不可能であることを表示していることに留意されたい。 ５．設計者はテストベンチを修正して設計データフローの知識を使用して予測さ
れたれた相互接続サイクルカウント遅延を有するチップ待ち時間要件を含むよう
にする。 ６．設計者はそれがサイクル要件を満たしているかどうかを確かめるように設計
をシミュレートする。 ７．チップのサイクル要件が満たされるまで、設計者は待ち時間マトリクスを修
正して検証プロセスを繰り返す。 各タイプのバス転送に利用可能な最大サイクルカウントを有するテーブルを作成
するため、より厳格な待ち時間要件がよりゲート制御集約型バス相互接続方式に
翻訳するため要件が満たされるまで、設計者は大きいサイクルカウントを使用し
てそれらから始めかつそれらを低減なければならない。 クラスタ測定の判定 次に、データの自然なクラスタを反映するため、設計者は対角線方向の中心に最
も近接した最も大きいカウントを移動させることによってデータ転送マトリクス
を再組織する。このプロセスを行う多数の方法がある；好ましい方法は本明細書
においてピボット運動と呼ばれる。ピボット運動の目的は、必要なピン数を最小
にするための最高転送速度でブロックを集合させることである。設計者は自動的
に計算を行うためのスプレッドシートをセットアップしてもよい。 集合させることがどのくらい効果的であるか測定するため、データ転送マトリク
スの各サイトを正確に重みを加えなければならない。この例では、サイトに重み
を加えるため、図４６に示した距離マトリクスを使用する。図４６のテーブルで
、各セルにはセルが対角線方向による距離の二乗が含まれる。データ転送マトリ
クスサイトに重みを加えるための他の方法を使用してもよいが、より高度の測定
により制限される、システムの要素のある程度の移動し易さがある間急速に集中
することが配置アルゴリズムで示されているため、距離の二乗が好ましい。 次に、設計者は距離マトリクスのその対応するセルでデータ転送マトリクスの各
セルを乗算し、かつセルすべてのためすべての値をまとめて加える。結果がクラ
スタ測定値である。図４３のテーブルのマトリクスのクラスタ測定値は４２８，
２００である。クラスタ測定値が低いほど、バス集合はより効果的である。 ピボット運動ブロック より低いクラスタ測定値を取得するように試みるには、クラスタ測定値が向上し
ているかどうかを確かめるため設計者は、ひとつずつ列を交換しかつすべての交
換の後クラスタ測定値を再計算することによりデータ転送マトリクスをピボット
運動しなければならない。下記擬似コードに示したように、サイトが並べ替えら
れるべき一覧表の要素である場合の並べ替えを実行することにより、列の交換が
行われる。 マトリクスの電流クラスタ測定値を取得する（Ｇｅｔ Ｃｕｒｒｅｎｔ ｃｌｕ
ｓｔｅｒ ｍｅａｓｕｒｅ ｏｆ ｍａｔｒｉｘ）； 現行サイトに対して＝マトリクスのサイト１に、をｎ−１を実行する（Ｄｏ ｆ
ｏｒ Ｃｕｒｒｅｎｔ ｓｉｔｅ − ｓｉｔｅ １ ｔｏ ｎ−１ ｉｎ ｔ
ｈｅ ｍａｔｒｉｘ）； 次のサイトに対して＝現行サイト＋１をｎに、を実行する（Ｄｏ ｆｏｒ Ｎ
ｅｘｔ ｓｉｔｅ − Ｃｕｒｒｅｎｔ ｓｉｔｅ ＋ １ ｔｏ ｎ ｉｎ
ｔｈｅ ｍａｔｒｉｘ）； 現行サイトと次のサイトを交換する（Ｓｗａｐ Ｎｅｘｔ ｓｉｔｅ ｗｉ
ｔｈ Ｃｕｒｒｅｎｔ ｓｉｔｅ）； マトリクスの次のクラスタ測定値を取得する（Ｇｅｔ Ｎｅｘｔ ｃｌｕｓ
ｔｅｒ ｍｅａｓｕｒｅ ｏｆ ｍａｔｒｉｘ）； 次のクラスタ測定値＞現行クラスタ測定値なら、現行サイトと次のサイトを
交換し元の場所へ戻す（Ｉｆ Ｎｅｘｔ ｃｌｕｓｔｅｒ ｍｅａｓｕｒｅ ＞
Ｃｕｒｒｅｎｔ ｃｌｕｓｔｅｒ ｍｅａｓｕｒｅ Ｔｈｅｎ Ｓｗａｐ Ｎｅｘｔ ｓｉｔｅ ｗｉｔｈ Ｃｕｒｒｅｎｔ ｓｉｔ
ｅ ｂａｃｋ ｔｏ ｏｒｉｇｉｎａｌ ｌｏｃａｔｉｏｎ．）。 さもなければ（Ｅｌｓｅ）、 現行クラスタ測定値＝次のクラスタ測定値（Ｃｕｒｒｅｎｔ ｃｌｕｓｔｅ
ｒ ｍｅ８ｓｕｒｅ ＝ Ｎｅｘｔ ｃｌｕｓｔｅｒ）； Ｅｎｄ； Ｅｎｄ。 接続でなく相互接続は帯域幅であるけれども、この並べ替えは二次方程式配置ア
ルゴリズムに類似している。設計者はこのひとつの代わりに類似の結果をもたら
す他の方法を使用することができる。 上記に示すようにピボット運動させると、１１７，０００の改良クラスタ測定値
を有する図４７のマトリクスが生成される。この理想化された例では、構成要素
が情報を作成しないことに留意されたい。構成要素はそれらが読取ることを書込
むので、列及び行はブロック３及びＰＩＯを除いて、一致するものを合計する。
これは現場で使用するためのケースではないかもしれない。 設計者は図４７に示すようなテーブルを使用してバスクラスタを定義することが
できる。この例はブロック１、ブロック２、ＰＣＩ及びメモリ間の高速データ転
送を示す。従って、これらの構成要素は高速バスでなければならない。ブロック
３とＰＩＯ間には低データ転送速度があるため、これらの設計要素は低度バス上
にある。 ＰＩＯは出力のみであるが、他の構成要素はすべて双方向性である。クラスタ内
部及び外部の構成要素は連通していなければならないので、図４８に示すように
、設計者は２つのバス間のブリッジを作成しなければならない。 クラスタ化に基づくバスの定義 初期のクラスタ化には、好ましくは、すべての予め定義されたバス信号ネットが
含まれなければならない。設計者はクラスタ内でピボット運動させて本質の内部
サブクラスタを示すことができるが、ひとつの以上のバス形式がこれらのシグナ
ルのために定義されなければ、それらを次のタスクのひとつのクラスタとして取
扱う必要がある。 プロセッサのシステム及び周辺機器バスが定義されている場合、クラスタはシス
テムバスと周辺機器バスまたはクラスタ化情報に基づくバスに分けられる。例え
ば図４７のテーブルのバスマトリクスが前もって定義されたバスシグナルネット
から構成されている場合、初期クラスタ化にはマトリクス全体が含まれる。ひと
つの以上のバスが定義されている場合、高速バスにあるべきブロックがひとつの
バスを、かつ残りの部分が別のバスを形成する。この分割はその後、次のタスク
に渡される。予め定義されたバス接続がない場合、バスはクラスタ情報に基づい
た方法で定義される。ピボット運動されたマトリクスは通常、他の隣接したブロ
ックと比較されたそれらの間の比較的高いレベルの交信を有する隣接したブロッ
クのグループを有する。図４９のテーブルに以前のピボット運動されたマトリク
スに類似の、この種類のクラスタ化を示す。図４９は、クラスタ化プロセスをよ
り明らかにするため以前に示したそれらからの異なる例に基づいている。「＃＃
」が大きい数を表すことに留意されたい。 ここの例では、３つのブロック間に高速の交信があり、かつＨを介してこれらの
ブロックとブロックＤ間に交信がないため、ブロックＡ、Ｂと、及びＣが１つの
独立したバスクラスタを形成する。３つのブロックすべての間に高速の交信があ
るため、ブロックＤ，Ｅ、及びＦが別のバスクラスタを形成する。さらに、ブロ
ックＤ，Ｅ、及びＦが２つの別々のバス、即ち、Ｄ及びＥ間の二地点間バス及び
別のＥ及びＦ間の二地点間バスを形成する。ブロックＧ及びＨが第３クラスタを
形成する。ＥＦ対及びＧＨ対間により低い帯域幅接続が存在する。データ転送量
に依存して、Ｅ、Ｆ、Ｇ及びＨはより低いレベルの交信のためひとつのバス上ま
たはそれらの間に双方向性ブリッジを有する２つの別々のＥＦ及びＧＨバス上に
存在してもよい。 多数の異なるクラスタからオプションを選択するために、次の指針に従う： １．比較的低い交信領域から高い交信領域の、ブロック間のカットポイントを指
定して可能なクラスタを決定する。図４９のマトリクスのＣとＤ間のカットによ
り図５０に示したダイアグラムが生成される。ＡＢＣとＤＥＦＧＨグループ間交
信量を決定するため、下方左側及び上方右側のセルを合計する。この例の場合の
この合計がＯである場合、２つのグループにはそれらの間には交信がない。これ
らのグループは完全に分離したバスを形成する。カットを横切って生じる交信が
Ｏである場合のピボット運動したマトリクスを切断する。 指定グループの各々内に、効果のあるカットを見つける。生じるグループ間の交
信は各グループ内より非常に少なくなければならない。図５０にひとつのカット
がＤ−Ｈグループに現れ、かつ図５１に示すようにいかなるカットもＡ−Ｃグル
ープには現れない。ＧＨグループ間のデータ転送速度は２２であるが、他のグル
ープ内のデータ転送速度は非常に大きい数（＃＃）である。これらのクラスタは
それらの間にブリッジで２つのバスを形成することができる。 クラスタ間またはクラスタ内の交信にすべてのブロックが含まれまい場合、ユー
ザに最適化が必要な可能性がある。待ち時間マトリクスにある一定のブロック間
交信に対する非常に異なった要求がある場合、最適化することのみが重要である
。例えば、図５１はＧＨクラスタはＤＥと交信しないことを示している。ＤＥ及
びＥＦは交信しているが、ＤとＦは交信しない。ＤＥに対する待ち時間要求が非
常に厳密な場合、それ故、設計者はバスの残り部分からＤＥ 交信を分割する必
要がある。図５２から、生じるマトリクスが確かめられる。この例ではＥがＥ及
びＥ’に分割されて、分離したインターフェースが２つのバスのためＥに生成さ
れることになるため、それは２つの分離したブロックであるように見える。ブロ
ックに２つの以上のバスインターフェースがある場合、分離したインターフェー
スを効果的に使用するためこの技術を使用してもよい。 この技術が図４３の例で使用される場合、図５３に示したそれらの間のブリッジ
２つのバスを有するクラスタが生成される。ひとつのバスがデータ著しい量を転
送する一方、その他は非常に少ない量を転送する。ブロック３とＰＩＯ間の別の
カットがクラスタ間のより低い交信にさえも生ずることになる。しかし、それが
クラスタにただひとつのブロックを残すためこれは重要なカットではなく、従っ
てそれは作成されない。 ４．すべてのカットが作成されると、生じるクラスタ情報は次のタスクへ渡され
る。 このクラスタ化技術には、チップのためバス構造を生成するシステム知識が必要
とされる。設計者は現行ブロックバスインターフェース、追加プロセッサ要求、
及びバスに関するマスタ数などのデータタイミング及び実行詳細を考慮しなけれ
ばならない。これらの要因は、このクラスタ化方法を使用して得られた構造から
はずれることがよりよい性能または処理手順に単に追従することにより得られた
ものよりより低いゲートカウントを有するバス構造を生成することを示唆してい
る。そうであれば、設計者はこのタスクを繰り返えしてクラスタ化結果を修正す
ることを欲する可能性がある。 バスの選択 設計者がクラスタ化方法を使用してバスを定義したら、バス形式及び性能階層構
造を選択しなければならない。バス階層構造とは最高性能のバスからその最低性
能のバスまで低下するバスの水準である。例えば、設計に高速システムバス及び
２つのより低速の周辺機器バスが含まれている場合、階層構造はシステムバスか
ら２つの周辺機器バスまでである。 バス分類参照ライブラリによるバス属性及びサイズは、各バスのバス形式を定義
するため使用されることが好ましい。ライブラリにより利用可能なバス形式の各
々のため１組のバス属性が一覧表にされる。適切なバスを選択するため、設計者
は現行バスインターフェースのためのクラスタで各ブロックを分析する。何もな
いかまたはほとんどない場合、バスは最も類似する属性を有するバス分類参照ラ
イブラリのバス形式が選択される。この選択プロセスの結果がバス設計を指定す
る、次のタスクで使用される定義されたひと組のバス及び階層構造である。 バス分類参照ライブラリ及び設計におけるブロックのインターフェースをチェッ
クインして、バスを以下の通りに選択する必要がある： ラスタの帯域幅及び待ち時間を満足しないバスを除去する； ２．バスがすでに定義されている場合、そのバスを使用するが、さもなければ； ３．プロセッサが存在れば、それがすでに接続しているシステムバスを使用する
、さもなければ； ４．ほとんどのブロックがすでに接続しているバスを選択する； ５．それが接続されるものに、ほとんどのブロックのｅｎｄｉａｎ−ｎｅｓｓを
扱うことが可能なバスを使用する（大きいｅｎｄｉａｎにはデータユニットの左
端にＯビットがある；小さなｅｎｄｉａｎは右側にはない） ； ６．バスの負荷が過大な場合、多数のバスを使用する； ７．より低帯域幅のデバイスを周辺機器バスまたは（複数の）バスに分離する； ８．既存ブリッジを有する周辺機器バスを使用してシステムバスを選択する； ９．選択プロセスの終了後、ひとつの以上の選択がある場合、それが最良ツール
及びモデルサポートを有することになるため、ＯＣＢ属性一覧表を最もよく満足
するバス形式を選択する。 バスサイズの計算 バス待ち時間テーブルは、このステップの出発点として使用される。クラスタ化
を使用して指定バスコンフィギレーションが識別されると、情報をバスのサイズ
を決定するのに使用可能な形態に翻訳しれなければならない。以前のタスクの例
からのマトリクスでは、最初の４つのエントリはひとつのグループにクラスタ化
され、かつ後の２つは２つのグループにクラスタ化される。 バスサイズの計算には、目標帯域幅が可能な限り近くに接近するまで別のバス幅
値を代入して、転送されるデータ量のためかつ帯域幅を計算するため必要な帯域
幅の決定が必要とされる。 目標帯域幅の決定 パターンセットのバスに必要なターゲット帯域幅の決定には次のステップが必要
とされる； １．ピボット運動されたデータ転送マトリクスの各クラスタで生ずるトランザク
ションすべてを加える。同様の例について続行すると、大きいクラスタで６２，
６００、小さなクラスタで１００、及びクラスタ間で１，２００である。従って
、図５５のマトリクスは図５４の４つのグループの各々にエントリを加えること
によって生成される。 ２．このパターンセットが取り込むことが予期される時間を決定する。フロント
エンド受け入れタスクがこの情報を提供する。この例については、パターンセッ
トは１ミリ秒で転送されなければならない、即ち、高速クラスタは６３，８００
バイトのデータ−１，２００バイトをブリッジへかつ内部の６２，６００バイト
をバスへ−１１ミリ秒で転送しなければならない。帯域幅は１秒で転送可能な、
ビットでの、データ量として定義される。この例では、１ミリ秒に５１０ Ｋビ
ットが転送され、帯域幅はほぼ５１０ＭＨｚである。 バス幅の計算 帯域幅はデータが転送されているクロック周波数倍のバス（バス幅）のワイヤ数
により構成される。 帯域幅はデータが転送されているクロック周波数倍のバス（バス幅）のワイヤ数
により構成される。 計算は次のように実行される： （ｕｎｔｉｌ ／ ｃｌｏｃｋ＿ｃｙｃｌｅ） × ｂｕｓ＿ｗｉｄｔｈ ＝ｂ
ａｎｄｗｉｄｔｈ ここで、 ｕｎｔｉｌは、選択されたバス形式の最小バス利用百分率である（図５９を参照
）； ｃｌｏｃｋ＿ｃｙｃｌｅは、設計のためのクロックサイクルであり；かつ ｂｕｓ＿ｗｉｄｔｈは、バスのワイヤ数である。この値は２のべき数でなければ
ならない。 計算のため、ｂｕｓ＿ ｗｉｄｔｈに対して２１から始め、かつ生じる帯域幅値
が目標帯域幅より大きくなるまでより高い値（２２、２３、 ．．．）を代入し
続ける。例えば、クロックサイクルが２０ナノ秒であり、かつバス利用が２５％
である場合、２に最も近いべき数に端数をまるめられたワイヤの数は、６４ビッ
トである。ここで、 （２５％／２０ ｎｓ）＊２６ ＝８００ ＭＨｚ＞５１０ＭＨｚ。 この例では、図５９のテーブルから形式４または５が選択される場合、高速クラ
スタのためのバスでは少なくとも６４ビットが必要とされることになる。同様に
、２０ ナノ秒のサイクル時間は、より遅いクラスタのためただ８ビットが必要
とされることになる。 バスの増大された利用が待ち時間を増大させるため、待ち時間情報は部分的利用
機能である。例を簡単にしておくため、このような複雑さは含まれていない；そ
れは、利用数の部分的な説明になっている。しかし一般的に、ひとつの帯域幅計
算のために最小バス利用数を使用する場合、待ち時間も同様に最小に向う傾向が
ある。この効果を説明するために、設計者は、クラスタから最も悪いケース（最
も少ない）待ち時間要求を選択する必要がある。 従って、設計者はシミュレーションで使用した待ち時間マトリクスからトランザ
クション全体の待ち時間を導出すことができるが、図５９のテーブルは分離した
数としてバス待ち時間データ及び転送値を示す。図５９に形式４のバスの１０通
りの最大転送待ち時間を示す。最小データ待ち時間は単独データのため必要なサ
イクル数に近い。従って、設計者は、いずれが正味の転送待ち時間であるかを、
下記に示す待ち時間マトリクス数からデータ転送時間を減算することにより計算
する必要がある； ｄｅｔａ＿ｔｒａｎｓｆｅｒ＿ｔｉｍｅ ＊ ｍｉｎ＿ｃｙｃｌｅｓ ／ ｎｕ
ｍ＿ｗｏｒｄｓ ＊ ａｖｇ＿ｔｒａｎｓ ここで、 ｍｉｎ＿ｃｙｃｌｅｓは、このバス形式のデータ待ち時間サイクルの最小数であ
り； ｎｕｍ＿ｗｏｒｄｓは、バスにおけるワード数であり；かつ ａｖｇ＿ｔｒａｎｓは、平均トランザクションサイズ；トランザクションマトリ
クス（図４４）におけるトランザクション数で分割されたデータ転送マトリクス
（図４３）からのデータのバイト数である。 テーブルからの待ち時間を比較するために、設計者はトランザクションのデータ
待ち時間をマイナスシミュレーションマトリクスから引いた待ち時間値を使用す
る新しい待ち時間マトリクスを作成しなければならない。上記例では、このテー
ブルは図５３に示すようになるはずである。このマトリクスの各要素は次のよう
に計算される：［Ｒｅｓｕｌｔｉｎｇ Ｌａｔｅｎｃｙ（ｘ，ｙ） − Ｍｉｎ
Ｂｕｓ Ｌａｔｅｎｃｙ ｄａｔａ （ｔｙｐｅ）］ ＊（Ｄａｔａ Ｔｒａ
ｎｓｆｅｒ（ｘ，ｙ） ／ Ｔｒａｎｓａｃｔｉｏｎ（ｘ，ｙ） ｔ ｂｕｓ
ｓｉｚｅ））。 システムバスクラスタの最少数は２５である。この値は帯域幅のために必要なバ
スの形式の最大転送待ち時間より大きくなければならない。その数はバス形式４
の転送待ち時間の図５９のテーブルでは１０であり、従って、設計者は高速クラ
スタのためバス形式４または更に良好ないものを選択することができる。 バス階層の生成 設計者が一旦バスとそれらの負荷を確認すると、いずれが高速バスであるか、い
ずれが低速バスであるか、及びどのブリッジ及びアービタが必要とされているか
を判定するステップを含むバスパ性能階層が指定されなければならない。２つの
バスが低減バスマトリクス（セルから／セルへのそれらはゼロでない値を有する
）で接続される場合、それらの間でブリッジが生成される。図５４の例を使用し
て、ピボット運動したデータマトリクス及び低減バスマトリクスからの次のバス
モデルが生成される： 下記に接続された６４ビットのシステムバス（形式４または５）： Ｂｌｏｃｋ １（ＲＮＶ） Ｂｌｏｃｋ ２ （ＲＮＶ） Ｍｅｍｏｒｙ （ＲＮＶ） ＰＣＩ （ＲＮＶ）。

【０１９９】 下記に接続された８ビットの周辺機器バス（形式３または更に良好なもの）への
ブリッジ（ＲＮＶ）： Ｂｌｏｃｋ ３ （読込み／書込み） ， ＰＩＯ （書込みのみ）。 注記：それからの到来データがないため、ＰＩＯは書込みのみである。バス１と
２間の両対角線方向がゼロではないため、ブリッジは読込み／書込みである。 このマップは次のタスクに渡されバス設計が指定される。 バス設計の指定 バス設計を指定するため、設計者は作成されたバスを元のブロック、ブリッジ及
びアービタなどのひと組の新しいブロック、及びひと組のグリュウ論理回路のた
めのひと組のインターフェース仕様に拡張する。新旧のロック仕様はブロック設
計タスクへ渡される。グリュウ論理回路はミニブロックとしてブロック設計を通
ってチップ組立体タスクへ転送される。バスがＯＣＢ属性仕様を満足する場合、
それにはアービタ及びブリッジなどの他のバス対象と同様に、マスタスレーブデ
バイスのためのモデルを有している。バスを選択する定義されたマップを使用し
て、設計者は詳細バス構造を作成する。 詳細バス構造 詳細バス構造を作成するため、設計者は下記を実行しなければならない： １． 単一負荷及びブリッジですべてのバスを除去することによってバスを最適
化する。システムバスのプロトコルとただひとつの周辺機器のバスとの間の翻訳
がゲートの観点から緩慢でかつ高価であるため、負荷をブリッジの反対側に置く
必要がある。設計者はブリッジ論理回路を完全に除去できない可能性があるが、
バスが二地点間交信に縮小するのでトリステートインターフェースは除去される
。さらに、２つの端部を一緒に置くことができるため、８ビットを多くの不利点
なしに１６ビットに変えることができる。 ２．バス・マスタ（bus master）及びスレーブを様々なロードに割り当てる。設
計者は、ブリッジでまる。それは、より遅いサイド（side）でのマスタ及びより
速いサイドでのスレーブである。周辺バス上のすべての装置は、スレーブ装置で
ある。システム・バス上では、マスタ及びスレーブは、どの装置が、前記バスを
制御する必要があるかによって定義される。設計の知識は、この決定を手助けす
ることができる。プロセッサが、前記バスに接続されている場合、そのインター
フェースはマスタである。そうでなければ、明白なマスタがない場合、ＰＣＩ等
の外部インターフェースがマスタである。メモリ・インターフェースは、ほぼ常
に、スレーブ・インターフェースである。どのブロックがマスタ・インターフェ
ースを要求するかを決定するために、設計者は、前記バスへの相互接続条件を参
照しなければならない。 ３．プロセッサ又は他のブロックが、メモリ・インターフェースも有するバスに
接続されている場合、及び前記ブロックが特定的にそれを必要とする場合、設計
者は、前記バス上に、一つ以上の直接メモリ・アクセス（direct memory access
）（ＤＭＡ）装置を含むべきである。これらの装置は、バス・マスタとして動作
する。 ４．最後に、一つのバス上の二つ以上の装置がバス・マスタである場合、アービ
タ（arbiter）を追加する。 詳細なバス設計 バス構造が定義されると、ブロック・バス・インターフェースが検査される。
ブロックがすでにバス・インターフェースを有する場合、前記インターフェース
は、前記バスに合わせるために、ソフト（soft）、ファーム（firm）、又はパラ
メータ表示された形式でなければならない。この場合には、存在するバス・イン
ターフェース・ロジックが使用されるべきであり、そうでなければ、前記バスを
備えたモデルが容認される。異なるバス・インターフェースが前記ブロック上に
ある場合、それは可能であれば排除されるべきである。

【０２００】 前記バス・ロジックは、以下のように、バスと連動するために変更されなけれ
ばならない： 前記インターフェースの各々に、アドレス空間を割り当てる。前記アドレス空間
は、通常はこのブロックがアドレス指定されているか決定するために、トランザ
クション・アドレスの上位ビットに適合するように設計される。また、各ブロッ
クが、内部記憶装置に関して十分なアドレス空間を、又は前記ブロックにおいて
使用される操作コードを有することを確実にしなければならない。 一つの機能のみが使用される場合、書き込み又は読み取りバッファを排除する。
ほとんどの現存するバス・インターフェースは、読み取り及び書き込みの両方の
ために設計されている。設計者は、これらの機能のたった一つが必要とされる場
合に、ロジックを顕著に低減させることができる。例えば、前記バスが１以上の
クロック・サイクルを必要とする場合、読み取り及び書き込みデータは、通常個
別にバッファされる。一つの機能のみが必要とされる場合、設計者は、レジスタ
・ビットの半分を排除することができる。 定義されたバス・サイズに適合するように、設計を拡張し又は短絡させる。ほと
んどのバス・インターフェースは、標準３２又は６４ビット・バスに設計されて
いるが、他の選択肢も可能である。設計者が、非標準バス・インターフェースを
必要とする場合、前記設計者は、レジスタ又は信号線を排除し又は追加するため
に、前記ロジックを変更しなければならない。同様に、前記アドレスは通常、デ
ータと同じサイズであるが、そうでなくてもよい。アドレス及びデータを、同じ
バス信号に交互に配置するバスに関して、データ及びアドレス・サイズにおける
不適合は、信号ではなく、上位オーダのアドレス・デコード又はデータ・レジス
タ・ロジックを排除するのみである。 必要な場合は、前記ブリッジにバッファを追加する。そのような変更は、ステッ
プ３におけるように、前記ブリッジの両方のサイドに対してなされなければなら
ない。

【０２０１】 前記バス間のブリッジ・サイズ・マッピングを変更する。読み取り／書き込みイ
ンターフェースに関して、ブリッジは、各機能に関して少なくとも一つのレジス
タを必要とし、両サイド上のバスの大きい方に等しい。各機能に関するデータ・
バッファに加えて、データのバーストは、データが、例えば図５７に記載された
ブリッジを使用して、次のバスに転送される前に、ブリッジによって受容される
場合に、より効率的に転送されることができる。図５８のブリッジにおいて記載
のとおり、これは、各機能に関するＦＩＦＯに、バーストを記憶し、及びそれを
次のバスに転送するよう要求する。 バス・マスタ及びアービトレーション（arbitration）の種類の優先順位を定義
する。バス上に一つ以上のマスタがある場合、マスタ間には、ある種のアービト
レーションがなければならない。厳格な順番の優先順位から、ラウンドロビン・
アービトレーション（round-robin arbitration）まで、多くの種類のアービト
レーションがある。前記マスタの両方が、類似の数のトランザクション及び必要
とされる待ち時間で、同じ量のデータを扱う場合、それらは、等しい優先順位を
有するであろう。その一方で、前記マスタの重要における明白な順位がある場合
、データ、トランザクション、及び待ち時間の量における同等の順番で、アービ
トレーションは並列化され、最も重要なマスタを第一位に置く。 ステップ５における定義に基づいて、アービタを作成し及び接続する。アービト
レーション体系は、バスに依存して、分散され又は中央化されうる。アービトレ
ーション・ロジックは、それが、グルー・ロジック（glue logic）でブロックへ
と分散されるように、可能な限り分散されるであろう。 装置のエンディアンネス（endian-ness）によって要求されるとおり、前記バス
を前記インターフェース・ロジックにマッピングする。ほとんどのバスは、リト
ル・エンディアン（little-endian）であるが、いくつかの装置は、ビッグ・エ
ンディアン（big-endian）である。エンド・タイプ間に不適合がある場合、設計
者は、前記バスからデータのバイトをどのようにスワップするかを決定しなけれ
ばならない。この決定は通常、コンテクスト（context）に依存する。前記バス
へ、及び前記バスからのすべてのトランザクションが、同じ種類のデータである
場合、設計者は、固定バイト・スワッピング（fixed byte-swapping）を使用し
てもよく、そうでなければ前記バス・マスタは、スワッピングをしなければなら
ない。 ＤＭＡ装置を、前記バスに合わせる。直接メモリ・アクセス装置は、データを一
つのブロックから他のブロックへと転送するコントローラである。それらは、他
の装置と同じように、アドレス・バスのサイズへと変更されるべきである。 １０．必要な場合、テスト容易性ポート及びインターフェースを追加する。最低
レベルのテストは、バスそのものをテストする性能である。標準チップ・テスト
・ロジックは、バスを使用することもできる。これらのテスト特性は、テストを
、通常のオペレーション・モードから区別するために、さらなる信号を必要とし
てもよい。 １１．必要な場合、初期化パラメータを追加する。ＰＣＩ等のいくつかのバスは
、コンフィギュレーション・レジスタを有する。これらのレジスタは、変化しな
いコンフィギュレーションに関してハードコード化されてもよい。 １２．前記バス上の装置によって要求される場合、任意のバス性能を追加する。
いくつかのバスは、スレッド、分割トランザクション、及びエラー・リトライ（
error retry）等の進化した性能を有し、それは前記バスに接続された前記装置
が、それらを必要としない場合は、実行される必要がないかもしれない。ＤＭＡ
装置、非連続バースト転送、及びエラー回復制御等、追加の性能のいくつかは、
標準バスにおいて定義されるよりも多くの信号を必要とするかもしれない。これ
らの信号は、必要な場合は、前記バスに追加されるべきである。 これらの変更が完了すると、バス・インターフェース・ロジックは、前記ブロッ
クの結果としてのインタフェースに接続される。

【０２０２】 バス分類参照 バス分類参照は、バス属性及び、それらと、セル・ライブラリ（cell library
）において使用可能なバスに関する帯域幅、待ち時間、及びデータ方向との関係
を列挙するライブラリである。分類ライブラリは、比較的固定された情報の集ま
りである。このライブラリの責任者は、新しいバスが利用可能になる時、前記バ
ス属性を更新する必要があるかもしれない。 バス・タイプ参照 バス・タイプは、待ち時間及び帯域幅ユーティライゼーションによって分類さ
れることができる。純粋な帯域幅は、バスにおけるワイヤの数に、前記データが
転送されるクロック周波数をかけたものの関数であるが、帯域幅ユーティライゼ
ーションは、アーキテクチャの関数である。

【０２０３】 図５９は、最低帯域幅ユーティライゼーション及び最長待ち時間から、最高帯
域幅ユーティライゼーション及び最短待ち時間までの特定のバス属性のリストを
示す。通常は、ロジック及びワイヤにおけるコストは、最初は最小で最後は最大
である。ライブラリにおける各バスは、このテーブルから割り当てられたバス・
タイプを有しなければならない。各バス・タイプは、ある範囲のサイクルにおけ
る待ち時間及びユーティライゼーション率におけるバス帯域幅を有しうる。各バ
スは、異なるクロック・サイクル時間及びサイズを有してもよいので、ユーティ
ライゼーション率は、サイクル時間にバスのサイズをかけた積に対する有効処理
量である。１００％のバス・ユーティライゼーション値は、すべてのサイクルが
完全に利用されていることを意味する。データ待ち時間列は、バスが１ワードの
データを転送するためにかかるサイクルの数を示す。転送待ち時間列は、バス・
トランザクションを開始するためにかかるサイクルの平均数である。図５９にお
けるテーブルは、バス・ユーティライゼーション及び待ち時間値の概算を示す。
設計者のグループは、経験及びその設計の種類に基づいて、値を特定することが
できる。 バス分類参照 多くのプロジェクトに対して、設計グループは、バスのライブラリを蓄積する
。各バスは、図４１に記載の参照ライブラリからのバスの種類を含む一組の情報
を含み、及び「ブロック・ベースの設計方法の文書化（Block-Based Design Met
hodology Documentation）」バージョン１．２、１９９９年５月２１日（そのす
べては、参照のため、ここに採用されている）Ｂ．２節、ページＢ−５乃至Ｂ−
１０に記載のＶＳＩ ＯＣＢ属性仕様及びバス分類参照からの、バス属性のリス
トを含む。この情報は、記載のとおり、どのバスを使用するか決定するために使
用されるであろう。テストのための設計 背景で記載されたとおり、テストの容易性は、ＳＯＣ設計の最も重要な特性で
ある。このようにテストのための設計（design for test）（“ＤＦＴ”）は、
標準になった。一定の顧客仕様に関して、本発明の方法及びシステムを使用して
引き出されたＤＦＴ知識ベースは、顧客に質疑応答（Ｑ＆Ａ）形式を提示するた
めに、探索され及び抽出されうる。この装置を通して、テスト目標が検討され、
及びテスト問題が、フロントエンド受容の間に検討されたステートメント・オブ
・ワーク（Statement Of Work）（ＳＯＷ）で解決される。

【０２０４】 テスト・プラン段階の後に、テスト配分、テスト・スケジュール、及びテスト
管理が続き、その結果、一組の公知のリソース及びプロシージャを伴う、明確に
定義された目標のために、さらにテスト開発を、個別の、独立したサブタスクに
分解するために、一組の仕様及びテスト・プランを生む。

【０２０５】 各テスト・ブロックは、規定された方法に従って同時に開発され、それは最善
の利用可能な技術でテストされうる。

【０２０６】 一度、前記テスト・ブロックがテスト統合のため準備されると、それらは、Ｉ
／Ｏ制限が適用されない、制約を受けないＳＯＣ境界にマッピングされ、それに
よって各層は、設計ブロックへと変換されるべき、制約を受けないＳＯＣのため
の「テスト準備」テンプレートになる。制約を受けないＳＯＣは、追加のＩ／Ｏ
レベル・テストを伴う特定のＩ／Ｏパッケージングに制約される。これによって
、テスト・スケジュール処理が発生し、及びＳＯＣレベル・テスト目的が満たさ
れる。 ＤＦＴテスト・プランを作成する ＦＥＡ中の顧客のプランの入手後、本発明のテスト・プラン開発体系は、好ま
しくは、それがテスト・マージ可能（test-mergeable）であるか（前記テストが
、複数のブロック上で自発的に実行されるか）を見るために、各ブロックの査定
で開始する。次に、設計者は、マージ非可能ブロックの各々がどれほど「テスト
可能である」かを決定する。第三に、ＪＴＡＧ境界走査、ＤＣテスト、及びＰＬ
Ｌテスト等のテスト・タイプを含むチップ・レベル・テスト仕様が開発される。
最後に、テスト故障補償が、チップ・レベル全体におけるテスト・マージ可能ブ
ロックのために、ブロック・レベルにおけるマージ非可能ブロックのために、及
び相互接続のために特定される。この四叉の初期分析の結果は、本発明のシステ
ム設計全体に関して、ＤＦＴ目標を与える。 ＤＦＴ規則を使用する ＤＦＴアーキテクチャ規則は、特定的な、テスト関連の制約であり、一貫した
テスト開発フロー及び結合テスト・データ管理を維持するために使用される。こ
れらの規則は、最高レベルにおける仮想ソケットにおける配置のための各マージ
非可能ブロックへのテスト属性の適用を導き、最も単純で最も適応性のあるテス
ト戦略を得るために、トレード・オフの実行を導き、設計のために、最高レベル
のテスト仕様の作成をし、及びテスト・プランの抽出が、テスト実行処理を詳述
できるようにする。 ＤＦＴグロッサリ（DFT Glossary） 列挙されたＤＦＴ用語は、ここに使用され主張されているとおり、以下の定義
を有する： オーソライゼーション 予め設計されたブロックを統合することを可能にする変
換処理。

【０２０７】 ＢＩＳＴ ビルトイン自己テスト（Built-in self test） ＢＳＲ 境界走査レジスタ（Boundary scan register(s)） ＣＡＰ チップ・アクセス・ポート（Chip access port） ＣＴＡＰ コア・テスト・アクセス・ポート（Core test access p
ort） ＤＡＰ 設計アクセス・ポート（Design access port） ＤＦＴ テストのための設計（Design for test） 故障補償 テストの縮退故障補償 ＩＣＴＡＰ 集積回路テスト・アクセス・ポート (Integrated circuit test access port) ＩＰ 知的財産（Intellectual property） ＪＴＡＧ 結合テストアクション・グループ（Joint Test Action
Group）（ｉＥＥＥ−ｉ１４９．１） レガシー・ブロック 未知の結果を危険にさらすことなく、再使用性のために
、変更又は分解模倣されることができない、予め設計されたゲート・レベル・ブ
ロック マージ可能 マージ可能コンポーネントに関するテスト条件は、一つ
以上の他のコンポーネントのそれと結合されうるので、それらは、一単位として
テストされることができ、テスト時間及びコストを節約する。

【０２０８】 ＭＩＳＩＲ 多重入力シグネチャ・ジェネレータ（Multiple input s
ignature generator） Ｍｕｘ マルチプレクサ（Multiplexer） マージ非可能 並行テストのために、他のブロックとマージされること
ができない ＰＲＰＧ 偽ランダム・パターン・ジェネレータ（Pseudo-random
pattern generator） ＳＡＰ ソケット・アクセス・ポート（Socket access port） ソケット化 テスト・カラー（test collar）を特定し、及び設計内
のテストを許可する、予め設計されたブロックに追加するための適応処理 ＴＡＰ テスト・アクセス・ポート（Test access port） ＴＢＡ テスト・バス・アーキテクチャ（Test bus architectur
e） テスト・カラー テスト・アクセス及び制御を供給する、予め設計された
ブロックを取り囲むテスト・ポート及びロジックの集まり テスト・マージ可能 少なくとも一つの他のブロックと併合可能なブロックで
あり、二つ以上のブロックが、単一のテスト・プロトコルでテストされる Ｔｉｍｅｓｅｔ サイクル化されたテスタ時間フォーマット：ＲＺ（ゼロ
復帰）、ＮＲＺ（非ゼロ復帰）、ＲＴＯ（１復帰）、ＤＮＲＺ（遅延非ゼロ復帰
） ＵＤＬ ユーザ定義のロジック（User-defined logic） ＶＣ 仮想コンポーネント（Virtual component） 仮想ソケット そのテスト・インターフェースを含む、予め設計された
ブロックに関するプレースホルダ（placeholder） ＶＳＩＡ 仮想ソケット・インターフェース連合（Virtual Socket Interface Alliance） テスト・プランを作成する ＤＦＴテスト・プランの全体を作成する処理は、ＦＥＡが生成した入力から、
各ブロックに関するテスト技術と、予想されるテスト・ベクトル仕様と、製造に
関するテスト時間条件と、及びＩ／Ｏ及びアナログ／混合信号（“ＡＭＳ”）条
件モジュール（ｘｒｅｆ）によって供給される特別なパラメトリックな、又はア
ナログのテストを受け取るテスト設計者で始まる。それゆえに、完全なＤＦＴプ
ランを作成することは、このデータの有効な編成及び使用を具備する。 マージ非可能ブロックに関するテスト条件 チップ・レベル・テスト条件は、マージ非可能ブロック・テスト条件を含み、
それは、順に、四つのコンポーネント：テスト・モデル、専用テスト・ポート及
びテスト・モード等のテスト制御ロジック、セーフ・アウト（safe-outs）等の
テスト分離ロジック、及びテスト・ベンチ及びテスト・ベクトル等のテスト妥当
性検査コンポーネント、を具備する。マージ非可能ブロックは、顧客に届けられ
る時、それらは：テスト・アクセス及び制御データ（テスト・モード、活動化、
及び非活動化等）、テスト・プロトコル、テスト・データ、テスタ・フォーマッ
ト、及びテスト・アプリケーション／セットアップ時間を特定する。 マージ可能ブロックに関するテスト条件 チップ・レベル・テスト条件はまた、すべてのテスト・マージ可能ブロックに
関するテスト情報を含み、それは、順に、テスト方法、テスト制御ロジック、相
互接続実行メカニズム、及びテスト妥当性検査コンポーネントを具備する。 チップ・レベル・テスト条件 チップ・レベル・テスト条件はまた、ＤＣテスト条件、ＡＣテスト条件、配電
等のｌｄｄｑテスト条件、及びアナログ・テスト条件も含む。 チップ・レベル・テスト・コントローラ チップ・レベルにおけるテスト制御は、テスト・インターフェース、ＪＴＡＧ
、ＰＲＰＧ及びＭＩＳＲでもよい。 コンポーネント属性マトリックス 設計者は、ＢＢＤ設計におけるコンポーネントに関するテスト開発環境を計画
するために、マトリックスを使用してもよい。このマトリックス文書は、可能な
解決法、及び追加の情報が必要とされる注記を発行し、推奨し、又は評価する。
前記マトリックスはまた、テスト設計における難点及び互換性があるコンフリク
ト領域を識別する。 ＤＦＴ規則を使用する 一度、設計者がマトリックスを使用することによって、チップ・レベル・テス
ト条件をフィルタに掛け、及び階級化すると、前記設計者はこれらの条件を、一
組のＤＦＴアーキテクチャ規則で処理することができる。アーキテクチャ規則を
使用することによって、共通アクセス、テスト制御、テスト・クロック及び非同
期属性の確立、及び利用可能なＤＦＴアーキテクチャに基づいたトレード・オフ
が、設計されているチップに関する独自の混成したＤＦＴアーキテクチャの作成
を可能にすることができる。

【０２０９】 適応性は、本発明のＢＢＤ ＤＦＴ戦略の重要な特性である。適切なテスト統
合を確実にするために、設計者は、仮想ソケットを、フロントエンド受容の端部
において受信された制約及びテスト情報に基づいて、各マージ非可能ブロックに
割り当てる。ＤＦＴアーキテクチャは、これらの仮想ソケットを、チップ・レベ
ル・テスト条件の残りに統合することによって、仕様を完成させる。各仮想ソケ
ットは、そのようなテスト・データの変換を達成するために、チップ・アクセス
・ポート（ＣＡＰ）へとマッピングされたソケット・アクセス・ポート（ＳＡＰ
）を有する。

【０２１０】 設計者が、テスト・プランを作り、テストのための設計を準備し始める前に、
前記設計者は、一貫性及び結合性のために、前記グループのＤＦＴアーキテクチ
ャ規則を検査しなければならない。 一貫性 一貫性は、各コンポーネントに関するテスト開発補償が、４つのオペレーティ
ング・モードにおいて、完了する程度であり、４つのモードとは：通常、テスト
、分離、及び境界（コテスト（co-test））である。設計者は、そのモデル、コ
ントローラ設計、分離、及びテスト妥当性検査値が、各ブロックとチップ・レベ
ル記述の間で一貫することを確実にするために、各コンポーネントに関するチェ
ックリストを使用してもよい。

【０２１１】 例えば、三つのマージ非可能ブロック、Ａ、Ｂ、及びＣを有する設計において
、テスト・コントローラ設計は、ブロックＢ及びＣが分離される場合のみ、ブロ
ックＡをテストすることができる。テスト・コントローラ仕様は、特定的に、Ｂ
及びＣの両方が分離される時のみ、ブロックＡテスト・アクセスを可能にしなけ
ればならない。ブロックＢ及びブロックＣが、同時にテストされることになって
いる場合、テスト・コントローラ仕様は、単一のシミュレーション環境において
、それらのテスト・データを同期させるテスト妥当性検査体系で、両方のブロッ
クへのテスト・アクセスを可能にしなければならない。

【０２１２】 この例に関して、図６０のテーブルは、例示的なブロックＡ一貫性検査を示す
。 結合性 結合性は、ある流れにおけるテスト方法が、互いに関与する程度である。５つ
の密接な関係を有するテスト方法パラメータがある；各々は、他を変更すること
ができる。例えば、前記テスト・アクセス方法は、テスト・プロトコルの活動化
条件を定義し、前記テスト・プロトコルは、テスト・データがどのように順番を
つけられるかを定義し、及びテスト・データは、特定の手スタ・タイムセットを
有する、一組のパターンに分解される。そして、埋め込みブロックへのテスト・
アクセスは、チップＩ／Ｏ制限及びコントローラ設計の影響を受けやすいので、
これらのパラメータの結合性は、テスト・データの保全性を維持するために、独
自の検査スタイルを必要とする。それゆえに、前記５つのテスト方法パラメータ
は、テスト・アクセス、テスト・プロトコル、テスト・データ、テスタ・タイム
セット、及びテスト時間である。 アーキテクチャ規則 図６１は、ＤＦＴ透視図からの、チップの最高レベルの階層を示す。設計者が
ＤＦＴ処理を始める前に、前記設計者は、機能的ブロックの集まりとしてよりも
、図６１に記載のとおり、前記チップを視覚化するであろう。図６２は、マージ
非可能ブロックがソケット化されるＳＡＰ及びＤＡＰを伴う、機能的ブロックで
作られた設計を示す。

【０２１３】 実際には、前記設計における機能的ブロックは、行動的、ＲＴＬ、ゲート、又
は混合レベルのＨＤＬで記述されうる。ＨＤＬファイルは、ディレクトリ構造で
編成される。テスト・ファイルを編成するための好ましい方法は、以下のアーキ
テクチャ規則で説明されるとおり、ディレクトリ階層を作成し、それからテスト
・ディレクトリにおけるリンクを、設計階層におけるデータ・ファイルへと入れ
ることである。この方法で、チップはＨＤＬディレクティブを使用して、異なる
コンフィギュレーションで作られうる。

【０２１４】 チップ・レベルＤＦＴアーキテクチャは、単一のレベルのみを有するので、す
べての属性は、最高レベルにある。それゆえに設計者は、最高レベル設計ファイ
ルに、抽出可能コメント形式で、属性を入れるために、本発明の方法に従って、
以下のアーキテクチャ規則を使用するであろう： ＤＦＴアーキテクチャを階層的に記述する。 階層の最高レベルにおいて、単一のチップ・アクセス・ポート（ＣＡＰ）を作成
する。前記ＣＡＰ仕様は好ましくは： ａ．設計及びテスト・データを一貫して維持するために、すべてのテスト制御及
びテスト・データ・ピンを、パッケージ・レベル・ピンにマッピングする ｂ．テスト制御ピンを、テスト・データ・ピンから分離する。 ｃ．テスト制御ピン属性を、専用又は選択可能のいずれかに設定する： それが、好ましくは、通常モードで専ら非活動化される場合、「専用」である；
専用ピンは、機能ピンと共有されえない。 それが、テスト全体を通して、テスト定数−論理値−に設定されうる場合に、「
選択可能」である；選択可能ピンは、機能ピンと共有されうる。

【０２１５】 ｄ．テスト・データ・ピン属性を： テスト中に、クロックとして使用される場合は、 ｔｅｓｔ＿ｃｌｏｃｋに設定する；ｔｅｓｔ＿ｃｌｏｃｋピンは、外部機能クロ
ック・ピンとのみ共有されうる。 リセットのために、テスト中に非同期的に使用される場合は、 ｔｅｓｔ＿ａｓｙｎｃに設定される；ｔｅｓｔ＿ａｓｙｎｃピンは、他のテスト
、テスト・モード、又は分離モードとの矛盾を生じない場合、専用にされ又は共
有されうる。 （ｉ）が、ｔｅｓｔ＿ｇｒｏｕｐピンと、テスト中に同期される ｔｅｓｔ＿ｃｌｏｃｋである、ｔｅｓｔ＿ｇｒｏｕｐ（ｉ）に設定される。

【０２１６】 ｅ．各テスト・モードに関して、以下の内容を記述する： アクセス順序を要求する場合、テスト中の装置へのアクセスを得るために必要な
テスト・セットアップ。ＪＴＡＧ命令、テスト・クロック、又はテスト・リセッ
ト等、プロトコルを記述する。 実際のテストを実行するために必要なテスト実行。タスク・レベル、繰り返し数
、サイクル時間、テスト長、及びテスト結果への段階における、テストの順序を
記述する。 前記テストを閉鎖し、及び前記チップを、デフォルト状態（通常モード）に戻す
ために必要なテストの後処理。 各テスト・モードに関して、テスト・セットアップ及びテスト処理順序を記述す
るＣＡＰコントローラ仕様を作成する。前記仕様は、好ましくは、実行可能（合
成可能）で、（テスト・ベンチ及びテスト順序を介して）検査可能である。 設計者は任意で、内部テスト・データ・バスを、利用可能なテスト・データ・ピ
ンへと包み込むために、一組のステージング・ラッチ（staging latches）を特
定してもよい。ステージング・アクションは、好ましくは、それに続くテスト結
果を変えない。前記ステージングは、好ましくは ａ．状態変更、時間依存（time-sensitive）信号を免れる。 ｔｅｓｔ＿ａｓｙｎｃ信号を使用するか、又は分解するために、 ｔｅｓｔ＿ｃｌｏｃｋと関連する、一貫した発生順序に従う。

【０２１７】 ｂ．状態変更、時間依存信号から免れない場合、余分なテスト・ピンを有
するであろう。この規則は好ましくは、テスト・パッケージ問題を回避するため
に、賢明に使用される。 設計者は任意で、テスト・データを圧縮するために、ＭＩＳＲ等のテスト・デー
タ・シグネチャ分析機能を特定してもよく、それは物理的Ｉ／Ｏ制約を最小化す
る。前記シグネチャ分析は好ましくは、各オペレーションのサイクルに関して決
定的であり、好ましくは： ａ．ＭＩＳＲ入力でそれを避けることによって、Ｘ値伝播（X-value propagatio
n）を免れる。 ｂ．ステップａが失敗した場合、影響を受けたＭＩＳＲサイクルを抑制する。こ
の規則は、故障補償の損失を避けるために、賢明に従われる。 設計者は任意で、以下の特殊テストを実行するために、チップ周辺における一組
の他のテスト・メカニズムを作成してもよい：境界走査テスト等のＤＣ及びＡＣ
パラメトリック・テスト；ＰＬＬテスト等の周波数テスト（frequency tests）
；及びＡＤＯ及びＤＡＣテスト等の混合信号テストである。これらのテストに関
する制御ピンは好ましくは、すべてのｔｅｓｔ＿ｃｏｎｔｒｏｌピンのテーブル
に含まれる。設計者はまた、矛盾するインタラクションを避けるために、ＣＡＰ
コントローラ仕様においてそれらを含みたいと思うかもしれない。 次のレベルの階層において、単一の装置アクセス・ポート（ＤＡＰ）を特定し、
前記レベルはＩ／Ｏ又はＩ／Ｏ関連セルがなく、物理的Ｉ／Ｏに制限されない。
前記ＤＡＰは好ましくは、ＴＡＰベースのポート等、汎用ポートを連結し、マー
ジし、リサイズし（resizing）、及び多重化することによって、形成されうる、
混成テスト・ポートである。 設計者は好ましくは、前記ＣＡＰコントローラから直接、前記ＤＡＰを構成する
ことができる。各コンフィギュレーションを、テスト制御、テスト・データ、又
はテスト分離ポートに分割する。各コンフィギュレーションにおいて： ａ．テスト制御ポート属性を 好ましくは、対象となるコンフィギュレーションｋを設定するために、使
用される場合、ｔｅｓｔ＿ｃｏｎ ｆ（ｋ）に設定する。 テスト定数に設定されうる場合、ｔｅｓｔ＿ｓｅｌｅｃｔに設定する。

【０２１８】 ｂ．テスト・データ・ポート属性を テスト中に、クロックとして使用される場合、 ｔｅｓｔ＿ｃｌｏｃｋに設定する。 テスト中、非同期に使用される場合、ｔｅｓｔ＿ａｓｙｎｃに設定する。 （ｉ）は、前記ポートが同期されるテスト・クロックを示す、 ｔｅｓｔ＿ｇｒｏｕｐ（ｉ）に設定する。 テスト・データ方向を示すために使用される場合、 ｔｅｓｔ＿ｄｉｒｅｃｔｉｏｎに設定する。テスト方向は、１又は０の値だけで
ある。

【０２１９】 ｃ．テスト分離ポート属性を、それがテスト中に、好ましくは０、１、又
はＺである安全状態論理値で分離される場合、 ｓａｆｅ＿ｓｔａｔｅに設定し、それが０又は１である非浮動論理値に設定され
うる場合には、ｄｏｎｔ＿ｃａｒｅに設定する。 １０．最高レベルのＤＦＴアーキテクチャにおいて、ＣＡＰ、ＣＡＰコントロー
ラ、ステージング・ラッチ、ＭＩＳＲ、ＤＡＰ、及び他のテスト・メカニズムの
相互接続を特定する。 １１．専用のセクションにおいて、ＣＡＰコントローラ、ステージング・ラッチ
、ＭＩＳＲ、設計本体、及び他のテスト・メカニズムを特定する。 １２．設計本体のアーキテクチャのみに関するＤＡＰ、ソケット、ＵＤＬ及びテ
ストの相互接続の詳細を特定する。 １３．設計本体のアーキテクチャは好ましくは、階層的に記述される。 １４．好ましくは、階層の次のレベル、ソケット・レベルに、多重ＳＡＰがある
。 １５．各ＳＡＰは好ましくは、ＤＡＰが利用できる一つ又は多数の適用可能なコ
ンフィギュレーションを有する、ＤＡＰの再帰的画像である。前記ＳＡＰのすべ
てのコンフィギュレーションは、好ましくは、ＤＡＲによってサポートされる。 ソケット化規則 一度、マージ非可能ブロック又はＶＣが設計内に配置されると、そのＩ／Ｏポ
ートはもはやチップＩ／Ｏからアクセスできない。そのテスト・データは、Ｉ／
Ｏポートで作成され、もはや使用できない。

【０２２０】 通常、設計ブロック・テスト値は、他のロジック・ブロックを通して伝播しな
ければならないので、チップ・レベルでのテスト・データの再作成は難しく、予
測できない。それゆえに、好ましいアプローチは、設計ブロックに関する仮想ソ
ケットを作成することによって、設計ブロック自身にアクセス性を追加すること
である。仮想ソケットは、テスト・アクセス、分離、及び前記チップＩ／Ｏから
アクセス可能な境界テスト機能を含む。

【０２２１】 設計者は、前記設計における設計ブロックに関するプレースホルダとして、仮
想ソケットを使用することができ、又は設計ブロック自身に、テスト制約を課す
ために、前記ソケットを使用することもできる。設計ブロックは、Ｉ／Ｏマッピ
ング及び制限を使用して、ある設計において、制約をそれにマッピングする時に
ソケット化される。前記制約は、設計依存で条件的であるが、それらは、設計者
に、結合的に各設計ブロック・ソケット化タスクを分割させる一方で、設計統合
中に、設計ブロックの追跡をする。

【０２２２】 ソケット化された設計ブロックは、チップ・レベル・テスト制約に適合するた
めに、余分なＩ／Ｏポート及びロジック又はテスト・カラーを必要とする一方で
、機能的インターフェースを維持するかもしれない。前記インターフェース・タ
イミングは、やや変更するかもしれないので、各ソケット化された設計ブロック
に関して、総合して特徴付けられ又は再配分されるために、ＲＴＬコードでテス
ト・カラーを書くのが最善である。設計全体を総合した後に、ゲート・レベルで
テスト・カラーを追加することは、タイミング問題を招くかもしれない。 設計ブロック・ソケット化規則は、以下のとおりである： １．ソケットは、階層的に記述されうるが、最高レベルは、好ましくはすべての
テスト属性を含む。

【０２２３】 ２．一つのソケットにつき一つのＳＡＰのみが存在しうる。

【０２２４】 ３．前記ＳＡＰは、前記ソケットにおけるすべてのエレメントをどのように分
離し、テストし、診断し、及びデバッグするかに関するテスト情報に関する唯一
の参照である。

【０２２５】 ４．各ＳＡＰは、好ましくは、より高いレベルの仕様に従って構築され又は合
成される。

【０２２６】 ５．設計者は、構成及びコンテクストのより高いレベルにおいて、各ＳＡＰが
、通常、テスト、分離、及び境界モードを活動化させ及び非活動化させることが
できることを検査することができる。これは、設計者が、前記ソケットの外部テ
スト情報構造を検査するということを意味する。

【０２２７】 ａ．前記外部テスト情報構造は、好ましくはＶＳＩＡコンプライアンス規
則において特定された標準化された記述言語に適合する。

【０２２８】 ｂ．標準化された記述言語を使用することができない場合、前記テスト情
報構造は、仮想ソケットにおけるチップ・レベル設計テスト属性に適合するであ
ろう。

【０２２９】 ６．各ＳＡＰは好ましくは、テスト・セットアップ、テスト実行、及びテスト
後処理順序を適切に実行することを確実にするために、再フォーマットされたテ
スト・データで、ソケット・レベルにおいて検査される。これは、設計者が、前
記ソケットの内部テスト情報構造を検査することを意味する。

【０２３０】 ａ．前記内部テスト情報構造は、好ましくは、すべての設計ブロック・テ
スト・モデル、すべての機能的ブロック、及び前記ソケットによって境界を定め
られたすべての他のロジックを含む。

【０２３１】 ｂ．前記内部テスト情報構造は、好ましくはコ・シミュレートされ（co-s
imulated）、チップ・レベル・シミュレーション環境と相互運用できる。

【０２３２】 ７．通常モードにおいて、ＳＡＰと関連するすべてのテスト・ロジックは、好
ましくは、ＳＡＰインターフェースから、順番ではなく、自発的及び直接的に非
活動化される。通常モードは、単一のテスト制御ポートによって活動化される。

【０２３３】 ８．分離（レスト（rest））モードにおいて、ＳＡＰと関連するすべてのテス
ト・ロジックは、非活動化され、及び中間競合なく、安全状態値に割り当てられ
る。機能的状態は、分離順序に含まれない。 ９．テスト・モードにおいて、ＳＡＰと関連するすべてのテスト・ロジックは、
好ましくは、単一の活動化順序によって可能にされ、それから任意で、テスト順
序を開始する前に、構成順序によって可能にされる。テスト時間を最短化するた
めに、同じコンフィギュレーションの連続したテスト順序がまとめられる。 １０．ソケットの周辺ロジックのすべては、ＳＡＰと関連するテスト・ロジック
を含み、境界（コ・テスト）モードにおいてテスト可能である。 最高レベル・テスト・ロジック仕様を設計する 設計者は、補償及び時間の条件に適合するように、最高レベル・テスト・ロジ
ック仕様を設計する時、前記設計者は、テスト・ロジックの並行性質を向上させ
るトレードオフをする必要がある。重要な決定は、個別のブロック・テストをど
のくらい直列に又は並列にするかである。

【０２３４】 テスト制約は、テスト・カラーを構築するための、テスト条件を確立するため
に、ソケット化された規則を伴って、各仮想ソケットに関して使用される。テス
ト・アクセス透視図から、ＳＡＰはテスト統合目的において、完全であり十分で
ある。設計及びテスト競合を生じうる設計変更を避けるために、ＳＡＰは、ブロ
ックの機能的エレメントを共有し又は使用するべきではない。この分離は、異な
るブロック・タイプ−ソフト、ファーム、又はハード・ブロック−が利用される
時に、より意味があり、テスト統合中の予測不可能性を回避することを可能にす
る。

【０２３５】 通常、各アーキテクチャは、独自の組のソリューション又は特定の組のツール
を目的とし、及び特定の範囲のテスト応用を対象とする。多くのアーキテクチャ
は、設計のほぼすべての役割に及び特定の設計環境に由来する。それゆえに、以
下の内容を実行する開発の流れが、必要とされる： １．設計コンテクストにおけるテスト問題を特徴付け、及び分類する； ２．各アーキテクチャに関してトレードオフをアドレスする； ３．各対象となる設計に追加の変更を与える； ４．本発明の出現まで、ＢＢＤテスト問題が、以下の領域において明白であった
： テスト・データ再使用性 テスト・ソケット設計及びソケット情報 ＵＤＬ及びチップ・レベル相互接続テスト テスト・パッケージング テスト妥当性検査 テスト・プロトコル 診断及びデバッグ これらの問題は、ＢＢＤ設計プラン中になされる前提と関連する。しかしなが
ら、設計プランは、再使用可能なテスト・データと設計ブロックをパッケージ化
するための、多くの特定の処理を必要とする。例えば：テストためのＢＢＤ設計
の作成、設計ブロック・テスト・インターフェースのカスタマイズ、テスト・ア
クセス及び制御メカニズムの設計及び妥当性検査、及び前記テストとチップＩ／
Ｏとの、及びテスト・バジェット（test budget）内でのパッケージングである
。 ＤＦＴ分類 ＤＦＴアーキテクチャは、それらのテスト方法、それらのテスト・インターフ
ェース、及びそれらが使用されうるブロックの種類によって分類される。四つの
ことなる汎用ＤＦＴアーキテクチャがあるが、それらは類似のテスト・インター
フェースを有することはほとんどない。例えば、ほとんどのチップは、メモリＢ
ＩＳＴインターフェースを使用するＲＡＭを埋め込んでいる一方で、前記チップ
の残りは、走査方法を使用しているかもしれない。図６３に記載のテーブルは、
設計シナリオにおける典型的な選択を列挙している。 最高レベルＤＦＴアーキテクチャを作成するためのプロシージャ 図６４に記載のフローチャートは、最高レベルのアーキテクチャ仕様を作成し
、及びチップ・レベル・テスト構造を特定するために使用されるプロシージャを
示す。ＤＦＴプランは、好ましくはチップ上のすべてのブロックに関して、ブロ
ック・レベル・テスト・ロジックを特定する。テスト・ロジックを伴うブロック
は、最高レベルへのインターフェースを受け取る。テスト・ロジックを伴わない
ブロックは、テスト・ロジック条件を受け取る。これらの設計条件の両方を、ブ
ロック設計タスクに転送し、好ましくは、最高レベル・テスト・ロジック及びア
クセス・メカニズムの両方を作成する。

【０２３６】 図６５に記載のフローチャートは、ブロック・テスト・ロジック仕様を作成す
るために使用される、ソケット化プロシージャを示す。前記設計における各ソケ
ットに関して、図示されたとおり、ＤＦＴアーキテクチャに適合するために、各
設計ブロックに関して、テスト・カラーを特定する。

【０２３７】 テスト生成メカニズムを作成する テスト生成に関するＢＢＤ戦略は、マニュアル・ベクトル（manual vector）
、ＡＴＰＧ、又は混合（mixed）を具備しうる。トランスレーション及び連結メ
カニズムは、最高レベル・テスト・ロジック及び個別のブロックのテスト・メカ
ニズムに適合するように定義される。ＢＢＤにおいて、テスト開発は、二つの独
立した処理を具備する。 １．各仮想ソケットに関するブロック・レベル・テスト開発である。ほとんど の場合、この処理は以下のタスクを含む： ａ．ＳＡＰ宣言：ＳＡＰを、行動モデル・インターフェースに追加し、及び
前記ブロックを、その仮想ソケットで再インスタンス生成をする。 テスト・ロジック挿入：対象となるブロック周辺のテスト・カラーを形成するた
めに、テスト・アクセス、分離、相互接続テスト及びテスト制御ロジックを追加
する。最善の結果を得るために、前記テスト・カラーを、合成可能ＲＴＬフォー
マットで記述する。 テスト・データ変換：テスト・データをＳＡＰポートに拡張し、及びマッピング
する。新しいテスト・データ・フォーマットを受容するために、ブロック・レベ
ル・テスト・ベンチを変更しなければならない。テスト・フローを能率化するた
めには、１つのソケットにつきテスト・セットアップ時間を最短化し、及び同時
に複数のブロック・テストをランさせるために、いくつかのブロック上で手スタ
・タイミングを変更してもよい。 テスト検査：テスト・ロジックを検査するために、ブロック・レベル・テスト・
ベンチを変更する。対象となるブロックを、前のステップの前後に、テスト・デ
ータ保全性を確実にするために、完全なブロック・レベル・テスト・ベクトル・
セットのサブセットで検査する。

【０２３８】 ２．ＤＣテスト及びアナログ・テスト等、すべてのテスト・マージ可能ブロッ
ク及びチップ・レベル・テストに関する、チップ・レベル・テスト開発。この処
理は、以下のタスクを具備する： ａ．テスト・ロジック挿入：テスト・コントローラ、専用テスト・ピン、
ＤＣテスト・ロジック、アナログ・テスト・ロジック、及び必要であれば、すべ
てのテストに関するクロック・マックス（clock muxes）及びテスト・クロック
を追加する。このタスクはまた、必要であれば、テスト・マージ可能ブロック及
びＵＤＬのための走査挿入も伴う。

【０２３９】 ｂ．テスト生成：テスト・マージ可能ブロック及びＵＤＬに関するテスト
・データを生成するために、又は循環機能的テスト・データを収集するために、
ＡＴＰＧツールを使用する。対象となる製造テスト・データで、故障補償目標を
満たすことが重要である。

【０２４０】 ｃ．テスト検査：テスト・コントローラを検査し、及びＤＣテスト、アナ
ログ・テスト、設計におけるすべての仮想ソケットに関するテスト、及びＵＤＬ
テストを実行するために、チップ・レベル・テスト・ベンチを変更する。これら
のテストは、ＪＴＡＧが求めるようなテスト前及び後順序を必要としてもよい。

【０２４１】 ｄ．テスト・データ・フォーマッティング：シミュレーション結果を得て
、それらをＷＧＬ等のテスト・データ記述言語に入れる。

【０２４２】 次に、ＢＢＤ ＤＦＴ方法コンテクストにおいて、ブロック・レベルでのＤＦ
Ｔの応用を検討する。知的財産のコア（core）又は設計ブロックの最終プロダク
トは、標準化された又は汎用のテスト・インターフェースを伴う「テスト準備さ
れた」ブロック、及びチップ・レベルで再使用されうるテスト・データ・セット
である。設計ブロック・ソケット化体系は、設計ブロックを、チップ・レベル・
テストの一部へと変換する一方で、各ブロックの設計中に生成されるテスト・プ
ロシージャ及び装置のほとんどを再使用するために採用される。本発明のＢＢＤ
ＤＦＴ混合及び適合戦略は、多くの一般的な、走査に基づくテスト方法とは対
照的に、マージ非可能ブロックをソートすることによって、様々な、予め設計さ
れたブロックを、異なるテスト方法及びテスト・インターフェースと統合するた
めの、柔軟なアプローチを与える。テスト・マージ可能選択に基づいて、走査設
計方法を作成する理由は、単純に、自動化目的の簡易性である。

【０２４３】 設計ブロックを、再使用可能なテスト・データとパッケージするための、多く
の特定の処理に関与するブロック設計プランは、標準化され又はカスタマイズさ
れた設計ブロック・テスト・インターフェースに基づいており、ブロックＩ／Ｏ
のアクセス可能性に関する一定の前提を考慮に入れる。しかしながら、一度埋め
込まれると、ブロックＩ／Ｏは、異なるコンテクストに配置され、及び潜在的に
アクセス不可能になりうる。統合の容易性を確実にするために、前記テスト・イ
ンターフェースは、チップ設計透視図からオーソゴナリティ（orthogonalities
）を供給するために、機能的インターフェースから分離される。ＢＢＤにおいて
、設計ブロック・インターフェースを混合し並びに適合し、及びそれらをチップ
・レベルで統一するよう試みる（図６８に記載のとおり）。それゆえに、テスト
・インターフェースの柔軟性及び変更性は、テスト・アクセス及び制御メカニズ
ムを設計し及び妥当性検査するために、及び前記テストを、チップＩ／Ｏと、及
びブロック・レベル・テスト・バジェット内でパッケージするために、供給され
る。本発明が関連する分野の当業者によって理解されるとおり、可能ではあるが
、テスト・バスの一部としての、オン・チップ・バス（On Chip Bus）（ＯＣＢ
）の使用は、本発明によって検討されるが、本説明の範囲外である。 マージ非可能ブロック ＤＦＴロジック及びテスト・ベクトル検査機能は、設計者に、より短く、生産
サイクルにおけるより早い段階で、生産準備テストをランさせる。ＤＦＴ走査パ
ス（DFT scan paths）は、そうでなければ利用不可能であるチップ及びシステム
状態へのアクセスを供給する。メモリＢＩＳＴは、様々な埋め込まれたメモリ故
障階級をカバーするために、アルゴリズミック・テスト・ベクトルを使用する。
ロジックＢＩＳＴは、テスト・アクセス及びテスト・データ・ボトルネックを減
らすために、走査に基づいた設計のランダム・テスト可能構造を利用する。しか
しながら、各予め設計されたブロックは、多くの理由から、マージ非可能になる
かもしれない。通常は、マージ非可能ブロックは： 内部テスト・アクセス可能性（例えば、ゲート・クロック、ラッチ・ベース、
データ・パス）の欠如又は故障補償（例えば非同期）の欠如による、共通テスト
方法と互換性がなくてもよい合成可能ＲＴＬソフト・ブロックである。

【０２４４】 走査方法（すなわち、同期）、走査スタイル（例えば、マックス走査、クロッ
ク走査、ＬＳＳＤ）等、共通テスト方法と互換性がなくてもよいゲート・レベル
・ソフト・ブロックである。

【０２４５】 通常は、アレイ・ベースである、コンパイルされたブロックである。例えば、
埋め込みＲＡＭ、ＲＯＭ、ＤＲＡＭ、ＦＬＡＳＨ等は、結合ロジックと同じ故障
モデルを有しない。これらのブロックは、大きなアルゴリズミック・テスト・パ
ターンを必要とする。

【０２４６】 特定のテスト方法で作成されるが、テスト統合のために利用可能なインフラス
トラクチャを有しないハード・ブロックである。通常は、これらのブロックは好
ましくは、特定のテスト・インターフェースを有する、又は有しない特定のブロ
ック・レベル・テスト・データ・セットとともに転送される。

【０２４７】 特定のテスト方法を伴って又は伴わずに作成されるが、統合のためのインフラ
ストラクチャを有しないレガシー・ブロックである。通常は、これらのブロック
は、未知の結果を避けるために変更されなくてもよい。 テスト・カラー ソケット化された設計ブロックは、図６６のフローチャートに記載されたとお
り、ＳＡＰ仕様を伴うソケットを記述する新しいモジュールを作成し、本来の設
計ブロックをインスタンス作成し、及びそれらの間にテスト・ロジックを挿入す
ることによって、モデル化されうる。前記ソケット化設計ブロックは、第一に、
設計ブロック機能的インターフェースを回復させ、テスト・アクセス、テスト分
離、境界テスト構造を追加し、それからチップ・プラニング中に定義されたとお
り、基本的なテスト・インターフェース（例えば、ＴＡＲ走査、ＢＳＲ、又は直
接マックス）を供給する。その結果は、各関連したテストＩ／Ｏポートに関する
コメントとして追加されたテスト属性を伴うＳＡＰである。各マージ非可能ブロ
ックは、ブロックごとのベースで、テスト・セットアップ、テスト実行及びテス
ト後処理を実行するためのテスト・アクセス、分離、及び相互接続テスト機能を
追加するために、テスト・カラーによって、ラップされるであろう。前記出力は
： １．テスト・アクセス及び制御（例えば、テスト・モード、活動化、及び非活動
化） ２．テスト・プロトコル（例えば、機能的、マックス走査、ＢＩＳＴ、診断） ３．テスト・データ（例えば、テスト言語、ベクトル・サイズ、故障補償） ４．テスタ・フォーマット（例えば、テスタ仕様、タイムセット、テスト速度
） ５．テスト・アプリケーション時間（例えば、テスト・セットアップ時間がな
い） を含む、ソケット化された設計ブロックである。 テスト可能性を追加すること 再使用可能テスト・データとともに現れない各マージ非可能ブロックに関して
、設計プラン段階は、テスト構造を挿入することでテスト・インターフェース、
テスト方法、テスト・データ・フォーマット、期待される故障補償、及びテスト
・バジェットを、特定することができ、及び全体の領域及びタイミング・コスト
を評価することができる。この評価は、各ブロックにテスト可能性を追加するこ
とへの制約になる。 合成可能ＲＴＬソフト・ブロック 予め設計されたブロックが、走査に基づいたテスト・アプリケーションと互換
性がない合成ソフト・ブロックである場合、故障補償は問題となりうる。例えば
、走査設計規則検査は、走査侵害を遮断するために、ＲＴＬ又はゲート・レベル
で実行されうる。走査チェーン（scan chain）又はテスト・ポイント（test poi
nts）は、容易にモデルに挿入されることができないので、逐次ＡＴＰＧは、図
６７に記載のフローチャートに記載のとおり、機能的テスト・ベクトルとともに
使用されうる。このタイプの設計のための故障補償は、予測することが難しく、
故障シミュレーションは好ましくは、プラン段階中に、前記ブロックの再使用性
基準を確立するために使用される。ＴＢＡに基づいたテスト・カラーは、最善の
テスト・インターフェースであるが、前記ブロックに関するテスト・バジェット
が許可される場合は、ＢＳＲに基づいたテスト・カラーが考慮される。 検査 ここでＤＦＴから設計検査に移ってみると、本発明の検査方法及びシステムの
第一の目的は、（最終テープ・アウト（final tape out）での）完全な設計が、
フロントエンド受容の一部として供給された、機能的仕様及びチップ・テスト・
ベンチにおいて特定されたように、顧客の機能的条件に適合することを確実にす
ることである。第二の目的は、可能な限り最短の時間で、前記第一の目的を達成
することである。

【０２４８】 本発明の適切な機能に特に不可欠なことは、あらゆる設計テスト体系に不可欠
であるように、顧客が供給するチップ・テスト・ベンチが、顧客の要求された機
能の完全なテストを形成することである。この前提は、好ましくは、フロントエ
ンド受容中に強調される。ＢＢＤ設計フローは、それによって、チップ・テスト
・ベンチのグレーディング（grading）を組み込む一方で、機能的仕様モデル上
でランし、それによってチップ・テスト・ベンチの測定を供給する。

【０２４９】 本発明のアプローチは、統合された方法で、機能的仕様及びチップ・テスト・
ベンチの二つが一貫するように、それらの両方を利用することである。それに続
いて、詳細が、チップ・プラン、チップ・アセンブリ及びブロック設計を通して
追加され及び改良されると、前記設計は、機能が、本来の機能的仕様と一貫した
ままでいることを確実にするために、チップ・テスト・ベンチを介して、再検査
される。革新的に、より詳細にされたビュー（view）の検査は、完全なチップ・
レベルにおいて、又は後述のとおり、チップ・テスト・ベンチから引き出された
別個のブロック・テスト・ベンチを伴う個別のブロック・レベルにおいて、実行
されてもよい。

【０２５０】 バス・ロジック及び同じバスに沿って接続された様々なブロックのインタラク
ションは、分解するのに相当の時間を要し、設計処理の早い段階で及び継続的に
アドレスされないと、反復再設計を生じさせうることが、経験から明らかである
。この理由から、特定の注意が、設計サイクルの早い段階で、バス機能の妥当性
検査に払われる。前記バス及び関連するロジックはそれゆえに、後述のとおり、
早い段階で識別され、及び残りの設計からは独立して、バス・コンプライアンス
・テスト・ベンチを使用して、検査される。しかしながら、本発明の好ましい検
査フローは、迅速なターンアラウンドで、幅広い設計を扱うのに十分に柔軟であ
ることが注目される。例えば、ある設計が単純なバスを使用し、又は設計者が、
前記バスに接続されたブロックに関して十分な経験を有する場合、前記バス・コ
ンプライアンス・テストのいくつか又はすべては、延期されてもよい。同様に、
前記ブロックのいくつか又はすべては、単純であるか又は従来の設計から再使用
される場合、前記個別のブロック検査の一部は省略され、及びチップ・レベル検
査ステージに到達するまで検査は延期される。

【０２５１】 特定の設計に関して従われるべき詳細なフローは、ＦＥＡ処理の一部として確
立される。図１２乃至１５は、本発明に従って、機能的検査中に実行されるべき
タスクの、一般化したフローを供給する。これらの図は、チップ・テスト・ベン
チの図６９乃至７３への相互参照をしながら、詳細に説明される。図１２乃至１
５において、大きな矢印は、タスクの流れを示し、小さい矢印はタスク入力を示
し、及び点線矢印は任意の迂回パスを示すことが特記される。

【０２５２】 図１２を参照すると、上述のとおり、ＦＥＡの完了後、本発明の方法は、チッ
プ・テスト・ベンチ検査ステップ８２１０で続き、チップ・レベル機能的モデル
は、図６９に記載のチップ・テスト・ベンチ８３１０で実行される。モデル及び
テスト・ベンチの両方は、カスタマが供給し、検査の目的は、テスト・ベンチ及
び機能的モデルが一貫性を有することを確実にすることである。あらゆる互換性
言語でも十分であるが、前記モデルは好ましくは、Ｖｅｒｉｌｏｇ、ＶＨＤＬ又
は実行可能Ｃコードである。チップ・テスト・ベンチ８３１０は、前記モデルと
互換性があるファイルにある。前記モデルと前記テスト・ベンチとの不適合は、
顧客に戻され、前記モデル又は前記テスト・ベンチのいずれかは、内部一貫性を
達成するために変更される。

【０２５３】 次に、チップ・テスト・ベンチは、機能的モデル上でランする間に階級付けさ
れる。そのようなグレーディングは、以下の属性：宣言補償、二重補償、ＦＳＭ
アーク補償、訪問状態補償、対アーク補償、パス／ブランチ補償及び／又は表現
式補償、の一つ以上を測定することによって、テスト・ベンチの「グッドネス（
goodness）」計測、又は補償メトリックを供給する。この補償メトリックは、そ
れから顧客に戻される。補償メトリックは、ある設計が不十分にテストされ、又
は前記設計が十分な機能を含む場合、不十分にテストされたように見える設計の
領域を、強調してもよい。いずれの場合も、顧客は、前記補償メトリックを向上
させるために、テスト・ベンチ又はモデルを変更することを選択してもよく、そ
れによって、ここに記述されているＢＢＤ設計方法に関するプロジェクト開始時
間をリセットする。

【０２５４】 一度、チップ・テスト・ベンチが、機能的モデルと一貫していることが証明さ
れると、前記ブロックの各々に関するブロック機能的モデルを、これらのブロッ
ク間の定義されたグルー・ロジックと結合させることによって、前記チップの新
しいビュー８３１２（図６９）が、（図１２の）ステップ８２１２において作成
される。前記ブロック機能的モデル８３１２は、上述のとおり、顧客によって供
給されるか、又はＦＥＡ中に「ディッピング（dipping）」処理を介して作成さ
れる。グルー・ロジック・モデルはまた、上述のとおり、チップ・プラン中に特
定される。

【０２５５】 再度図１２を参照すると、チップ・レベル構造検査ステップ８２１４は、チッ
プ・テスト・ベンチで、前記チップのブロック機能的モデルをシミュレートする
ことを含む。ブロック機能的モデル８３１２又はグルー・ロジック・モデルの一
つ以上を変更し、及び前記シミュレーションを再度ランすることによって、あら
ゆる矛盾が解決される。このステップは、ブロック機能的モデルが、チップ機能
的モデルと一貫することを確実にする。

【０２５６】 次に図１３及び１４を参照すると、バス検査フローの目的は、前記チップ内の
バス・ロジックが正しく動作し、及び異なるバス・エレメント間のインタラクシ
ョンが、バス・プロトコル・エラーを生じさせないことを確実にすることである
。このように、コンプライアンス・ベクトルは、バス設計のために作成される。
これらのベクトルは、顧客又はブロック設計供給者によって供給されるコンプラ
イアンス・テスト・スーツに基づいてもよい。前記ベクトルは、前記設計の特定
のバス・トポロジーに対応するように操作されなければならない。コンプライア
ンス・ベクトルが供給されていなかった場合、それらは設計チーム（design tea
m）によって、好ましくはそれらが前記バスに接続された様々なブロックのイン
タラクションを実行し、すべての境界条件を実行し、及びバス・エラーが正しく
扱われているか検査する方法で、書き込まれなければならない。

【０２５７】 図１３に記載のステップ８２１８は、バス機能の検査に供給される。バス・コ
ンプライアンス・ベクトルは、上述のチップ・プラン段階から供給されたバスの
、サイクルの正確なモデルに対してシミュレートされる。あらゆるエラーは、コ
ンプライアンス・ベクトル・セット（図示されていない）を変更するか、又は図
７０に記載のバス・ロジック・エレメント８５１２の一つ以上を変更することに
よって、解決されなければならない。このステップは、前記コンプライアンス・
テスト・スーツが、うまくバス・ロジック・モデル上で実行するまで、繰り返さ
れる。

【０２５８】 次に図１４を参照すると、バス・ブロック・モデル及びテスト・ベンチ作成ス
テップ８６１０乃至８６１４が記載される。バス・ブロック・モデル作成ステッ
プ８６１０とテスト・ベンチ生成抽出ステップ８６１２の両方の目的は、バス・
ブロック・モデル検査ステップ８６１４と同様に、前記設計内のブロックの各々
に関する高いレベルの行動モデル及び関連テスト・ベンチを作成することである
。これらは、ブロック・設計者に渡され、及び前記ブロックの各々に関して、対
象となる機能を定義する。

【０２５９】 各ブロックに関する、図７０に記載のバス・ブロック・モデル８５１０を作成
することは、機能的に正しく、サイクルが近似したブロック機能的モデル８３１
２を、前記ブロックに関する、サイクルが正確なバス・ロジック・モデルと結合
することを含む。前記バス・ロジックは、チップ・プランから供給され、及び上
述のとおり検査されたバス・グルー・ロジック・モデルから引き出される。バス
機能的モデルのいくつかの変更は、インターフェースに「位置合わせ（align）
」させることを要求されてもよい。

【０２６０】 バス・ブロック・モデルはそれから、すべてのバス・ブロック・モデルを結合
させるチップのモデルをアセンブルすることによって、検査される。チップ・モ
デルはそれから、それをチップ・テスト・ベンチでシミュレートすることによっ
て、検査する。チップ・テスト・ベンチが、以前にサイクル近似モデル上で検査
された一方で、チップのこの行動ブロック・モデルは、いくつかのサイクルの正
確なオペレーションを有し、ゆえにブロック・モデルを通過させるためには、前
記チップ・テスト・ベンチの精緻さが要求されるであろう。ある場合において、
ブロック機能的モデル及びバス・ロジックにおける不適合によって、エラーが生
じるかもしれず、その時は、前記モデルは、エラーを修正するために変更されて
もよい。一度チップ・テスト・ベンチが、うまくこのチップ・モデル上で動作す
ると、個別のバス・ブロック・モデルは、詳細な実行のために、ブロック・設計
者に送られてもよい。

【０２６１】 図１４に記載のステップ８６１２において、ブロック・テスト・ベンチが引き
出される。一度、チップ・テスト・ベンチが、うまくチップ・レベル・バス・ブ
ロック・モデル８７１０上で動作すると、図７１に記載のとおり、プローブは、
個別のブロックのインターフェースに設定されることができ、及びブロック・テ
スト・ベンチは、それが前記モデル上で動作すると、チップ・テスト・ベンチ８
７１２から引き出されることができる。これらのブロック・テスト・ベンチは、
それらが実行を通して進行すると、前記ブロックの妥当性検査のために、ブロッ
ク設計者へと送られる。

【０２６２】 次に、図１５に記載のロジカル検査フローに進むと、ロジカル検査タスクの目
的は、前記ブロックの各々が、それが設計の実行段階（ＲＴＬから、後レイアウ
ト・ネットリストへの前レイアウト・ネットリストへ）を通して進行するにつれ
て、機能的に正しいことを確実にすることである。アセンブルされたチップが、
要求される機能を供給し続けるかについてもテストされる。

【０２６３】 検査は、機能的シミュレーションを通して動的に、又は同等性チェックを実行
する形式的検査ツールを使用して静的に実行されてもよい。動的検査は、本発明
のＢＢＤ方法の流れにおける他の部分で必要とされ、及び記述されているシミュ
レーション・ツールを必要とする。動的検査はまた、他の部分で使用されたベク
トル・セットを利用し、ゆえに、近似したサイクルから事実上正確なサイクルへ
のテスト・スーツの移動を支援する。静的検査は、新しいツールの包含を必要と
する。しかしながら、静的検査は通常は、シミュレーションよりも迅速にランし
、及びシミュレーションとは対照的に、「完全な」同等性チェックを供給し、そ
れはテスト・ベンチが、設計機能を実行するという範囲での同等性を証明するに
すぎない。

【０２６４】 次に、個別のＲＴＬブロック・モデルは、ステップ８７１０において検査され
、そこで、ブロック設計者によって作成されるＲＴＬシミュレーション・モデル
は、チップ・テスト・ベンチに対して検査される。これは、ブロックＲＴＬモデ
ルを、チップ・レベル行動モデルにおける対応する行動モデルと交換すること、
及び完全なチップ・テスト・ベンチを使用して、前記チップの混合モード・シミ
ュレーションを実行することによって、実行されうる。代替的には、個別のブロ
ックＲＴＬモデルは、引き出されたブロック・テスト・ベンチでシミュレートさ
れうる。いずれの場合も、近似サイクル・モデルから、正確なサイクルのモデル
への移行による不適合が考えられうる。これらの不適合は、テスト・ベンチを変
更することによって解決されるであろう。不適合が、損なわれた機能又は正しく
ない機能によって引き起こされる場合、ＲＴＬモデルは、前記エラーを修正する
ために変更されなければならない。

【０２６５】 ステップ８７１２において、ＲＴＬブロック・モデルは、チップ・レベルで検
査される。ブロックの各々に関するＲＴＬシミュレーション・モデルは、チップ
・レベル・ＲＴＬモデルを作成するために結合される。このモデルは、チップ・
テスト・ベンチでシミュレートすることによって、検査される。再度、サイクル
近似モデルから、正確なサイクルのモデルへの移行によるいくつかのエラーが存
在するかもしれない。これらのエラーは、チップ・テスト・ベンチを変更するこ
とによって、解決される。あらゆる機能的エラーは、ブロック・レベルＲＴＬモ
デルの一つ以上を変更することによって、解決されなければならない。

【０２６６】 ステップ８７４１において、個別の前レイアウト・ブロック・ネットリストが
検査される。各ブロックに関する後合成ネットリスト・シミュレーション・モデ
ルは、前記ブロックに関するＲＴＬモデルに対するものである。

【０２６７】 ステップ８７１６において、動的及び静的チップ・レベル前レイアウト・ブロ
ック・ネットリストが検査される。動的検査は、ブロック・レベル後合成ネット
リストを、チップ・レベル行動モデルにおける対応する行動モデルと交換するこ
と、又は完全なチップ・テスト・ベンチを使用して、前記チップの混合モード・
シミュレーションを実行することのいずれかによって、実行されうる。代替的に
は、個別のブロック・レベル後合成ネットリストは、ブロック・テスト・ベンチ
でシミュレートされうる。いずれの場合にも、正確なサイクルのモデルから、イ
ントラ・サイクル・タイミング（intra-cycle timing）を有するモデルへの移行
による不適合が、再度考えられる。これらの不適合は、テスト・ベンチ内のタイ
ミング・ストローブ（timing strobe）を変更することによって、解決される。
静的検査は、後合成ネットリスト及び各ブロックに関するＲＴＬモデル上で、同
等性チェック・ツールをランさせることによって実行される。不適合は、ＲＴＬ
モデルに適合するように、後合成ネットリストを変更することによって解決され
る。

【０２６８】 前記ブロックの各々に関する後合成ネットリストはそれから、チップ後合成ネ
ットリストを作成するために、結合される。このチップ・レベル・ネットリスト
は、シミュレーションを通して、又は形式的同等性チェック・ツールを通して静
的に、検査される。動的検査は、チップ後合成ネットリストを、チップ・テスト
・ベンチでシミュレートすることによって、達成される。静的チップ・レベル前
レイアウト検査は、チップ後合成ネットリスト及び各ブロックに関するチップＲ
ＴＬモデル上で、同等性チェック・ツールをランさせることによって、実行され
る。不適合は、ＲＴＬモデルに適合するように、後合成ネットリストを変更する
ことによって、解決される。

【０２６９】 ステップ８７１８において、個別の後レイアウト・ブロック・ネットリストが
検査される。このステップは、ステップ８７１４の繰り返しであるが、前レイア
ウト・ネットリストの代わりの後レイアウト・ネットリストを伴う。ネットリス
ト・レベルにおいて、これら二つのモデル間の唯一の相違は、レイアウトされた
設計のタイミング・ゴールを達成するためのバッファ及びドライブ強度（drive
strengths）の変更である。遭遇するあらゆるエラーは、バッファの不正な追加
又は削除に限定される。ブロック・テスト・ベンチのタイミングは、後レイアウ
ト・タイミング変更が、タイミング・ストローブについて、信号を動かした場合
には、変更されなければならないかもしれない。

【０２７０】 この検査は、静的又は動的に実行されてもよい。動的検査は、ブロック・レベ
ル後レイアウト・ネットリストを、チップ・レベルＲＴＬモデルにおける対応す
るブロックＲＴＬモデルと交換すること、及び完全なチップ・テスト・ベンチを
使用して、チップの混合モード・シミュレーションを実行することによって、実
行されうる。代替的に、個別のブロック・レベル後レイアウト・ネットリストは
、ブロック・テスト・ベンチでシミュレートされうる。静的検査は、後レイアウ
ト・ネットリスト及び各ブロックに関するＲＴＬモデル上で、同等性チェック・
ツールをランさせることによって、実行される。不適合は、ＲＴＬモデルに適合
するように、後合成ネットリストを変更することによって、解決される。

【０２７１】 チップ・レベル後レイアウト・ネットリストの検査は、ステップ８７１６の繰
り返しであるステップ８７２０において達成されるが、前レイアウト・ネットリ
ストの代わりの後レイアウト・チップ・レベル・ネットリストを伴う。ネットリ
スト・レベルにおいて、これら二つのモデル間での唯一の相違は、レイアウトさ
れた設計のタイミング・ゴールを達成するためのバッファ及びドライブ強度の変
更である。遭遇するあらゆるエラーは、バッファの不正な追加又は削除に限定さ
れる。動的検査は、チップ後レイアウト・ネットリストを、チップ・テスト・ベ
ンチでシミュレートすることによって、達成される。静的検査は、チップ後レイ
アウト・ネットリスト及びチップＲＴＬモデル上で、同等性チェック・ツールを
ランさせることによって、実行される。不適合は、ＲＴＬモデルに適合するよう
に、後レイアウト・ネットリストを変更することによって、解決される。

【０２７２】 最後に、物理的検査は、図７２及び７３に記載のとおりに達成され、そこでは
、ブロック及びチップ・テープ・アウトの両方が、本発明が関連する業界の当業
者に理解される方法で検査される。物理的検査タスクの目的は、ブロック設計及
び前記設計のアセンブリ段階を通して作成されたＧＤＳＩＩファイルが、機能的
に正しく、対象となる技術に関する設計規則の侵害がないことを検査することで
ある。

【０２７３】 各ブロックに関するＧＤＳＩＩは、ブロック設計処理によって作成され、対象
技術に関するＤＲＣをランさせることで検査される。あらゆるエラー及び警告は
、解決のために、ブロック設計者に戻される。ＬＶＳもまた、ブロックＧＤＳＩ
Ｉファイルと、前記ブロックに関する後レイアウト・ネットリストの間でランす
る。あらゆるエラー又は警告は、解決のために、ブロック設計者に戻される。

【０２７４】 完全なチップのためのＧＤＳＩＩは、チップ・アセンブリ処理によって作成さ
れ、対象技術に関するＤＲＣをランさせることによって検査される。あらゆるエ
ラー及び警告は、解決のためにチップ・アセンブリ設計者に戻される。ＬＶＳも
また、チップＧＤＳＩＩと前記チップに関する後レイアウト・ネットリストとの
間でランする。あらゆるエラー又は警告は、解決のために、チップ・アセンブリ
設計者に戻される。

【０２７５】 本発明は、図面及び上述の説明で、詳細に図示され及び説明されてきた一方で
、本発明は、本発明の精神の範囲内で、他の実施形態を通して実施されてもよい
と理解される。このように、本発明の範囲は、本明細書における図示及び説明に
限定されるものではないが、添付の特許請求の範囲によって定義されるべきであ
る。

【図面の簡単な説明】

【図１】 本発明によるブロックをベースとする設計方法に基づく設計プロセスを示すフ
ローチャートである。

【図２】 本発明によるフロントエンドアクセスの諸ステップを示すフローチャートであ
る。

【図３】 本発明によるクロック計画モジュールを示す図である。

【図４】 本発明によるバス識別及び計画モジュールを示す図である。

【図５】 本発明による電力計画モジュールを示す図である。

【図６】 本発明によるＩ／Ｏ及びアナログ／混合信号要求を示す図である。

【図７】 本発明による試験計画モジュールを示す図である。

【図８】 本発明によるタイミング及びフロア計画モジュールを示す図である。

【図９】 本発明によるブロック設計のメタフローを示す図である。

【図１０】 本発明によるチップアセンブリのデータフローを示す図である。

【図１１】 本発明によるチップアセンブリのタスクフローを示す図である。

【図１２】 本発明による機能検査を示す図である。

【図１３】 本発明による機能検査を示す図である。

【図１４】 本発明による機能検査を示す図である。

【図１５】 本発明による機能検査を示す図である。

【図１６】 複数の予め設計された回路ブロックを使用する回路設計の実現可能性にアクセ
スするための本発明による方法を示す図である。

【図１７】 本発明により、図２に示す方法を使用した実現可能性アセスメント結果を示す
図である。

【図１８】 複数の予め設計された回路ブロックを使用する回路設計の実現可能性にアクセ
スするための本発明による方法を示す図である。

【図１９】 本発明により、図１８に示す方法を使用した実現可能性アセスメント結果を示
す図である。

【図２０】 本発明によるフロントエンド受入れ（“ＦＥＡ”）プロセスを示す図である。

【図２１】 本発明による精細化プロセスを示す図である。

【図２２】 本発明による推定の正しさ曲線の例を示す図である。

【図２３】 本発明によるＦＥＡを検査するプロセスを示す図である。

【図２４】 本発明によるＦＥＡ設計プロパティ精細化プロセスを使用して精細化された推
定の正しさ曲線を示す図である。

【図２５】 本発明によるＦＥＡデータ抽出プロセスを示す図である。

【図２６】 本発明によるブロック推定精細化の必要性を識別するプロセスを示す図である
。

【図２７】 本発明によるＦＥＡアセスメント軸計量を示す図である。

【図２８】 本発明による分類崩壊曲線を示す図である。

【図２９】 グルー論理が最適設計ブロック配置を妨害するような回路設計における複数の
設計ブロックを示す図である。

【図３０】 本発明による第１の型のグルー論理分布を示す図である。

【図３１】 本発明による第２及び第３の型のグルー論理分布を示す図である。

【図３２】 回路ブロックをカラーに埋め込む本発明によるカラーリングプロセスを示す図
である。

【図３３】 本発明による設計に使用されるブロックのための要約の完全セットの作成を示
す図である。

【図３４】 本発明によるカラーリングプロセスを示すフローチャートである。

【図３５】 本発明による２つの層を有するカラーを示す図である。

【図３６】 本発明によるカラーと回路ブロックとの間の論理ビューを示す図である。

【図３７】 本発明によるカラーと回路ブロックとの間の物理ビューを示す図である。

【図３８】 本発明のカラーリングプロセスを使用しないシステム設計を示す図である。

【図３９】 本発明のカラーリングプロセスを使用するシステム設計を示す図である。

【図４０】 図３４のカラーリングプロセスのステップを遂行するための本発明によるコン
ピュータシステムを示す図である。

【図４１】 本発明のバス識別及び計画スキームを含む一連のステップを示す図である。

【図４２】 本発明の方法により製造された挙動モデルの相互接続区分の内部構造を示す図
である。

【図４３】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図４４】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図４５】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図４６】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図４７】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図４８】 本発明の方法及びシステム内に使用されるバスブリッジを示す図である。

【図４９】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５０】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５１】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５２】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５３】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５４】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５５】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５６】 本発明によるシステム及び方法を使用して実施したバス変更による改善された
遅延時間を示す表である。

【図５７】 本発明の方法及びシステム内に使用されるバスブリッジを示す図である。

【図５８】 本発明の方法及びシステム内に使用されるＦＩＦＯを含むバスブリッジを示す
図である。

【図５９】 いろいろなバス型のためのバス利用及び待ち時間特性を示す表である。

【図６０】 例示一貫性検査真理値表である。

【図６１】 本発明の方法を使用するＤＦＴ透視からチップのトップレベル階層を示す図で
ある。

【図６２】 機能ブロック及びソケットアクセスポート（“ＳＡＰ”）を作る設計を示す図
である。

【図６３】 いろいろな設計アーキテクチャのための適切な試験方法を示す表である。

【図６４】 本発明の方法及びシステムのためのトップレベルアーキテクチャ仕様手順を示
すフローチャートである。

【図６５】 本発明の方法及びシステムのソケット化手順を示す図である。

【図６６】 本発明の方法及びシステムのブロックレベル試験開発手順を示す図である。

【図６７】 本発明の方法及びシステムのチップレベル試験開発手順を示す図である。

【図６８】 本発明の方法及びシステムによる計画からチップアセンブリまでの試験の流れ
を示す図である。

【図６９】 本発明のフロントエンド受入れ検査の設計者のビューを示す図である。

【図７０】 チップ計画からブロック設計への移動の設計者のビューを示す図である。

【図７１】 本発明の方法及びシステムの進展するバスブロックモデル及び試験ベンチ生成
の設計者のビューを示す図である。

【図７２】 ブロック試験ベンチ及びチップ試験ベンチの設計者のビューを示す図である。

【図７３】 ブロック及びチップ論理検査モデルの設計者のビューである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｕ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ ，ＧＨ，ＧＭ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ， ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，Ｌ Ｓ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ， ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，Ｔ Ｔ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 クック ラリー アメリカ合衆国 カリフォルニア州 95033 ロス ガトス スパニッシュ ラ ンチ ロード 25399 (72)発明者 ハント メリル アメリカ合衆国 カリフォルニア州 92025 エスコンディード ライルヴィュ ー ドライヴ 2460 (72)発明者 ケ ウーディアン アメリカ合衆国 カリフォルニア州 95014 クーパーティノ ハンターストン プレイス 1086 (72)発明者 レナード クリストファー ケイ アメリカ合衆国 カリフォルニア州 94087 サニーヴェイル サウス バーナ ード アベニュー 745 アパートメント ＃319−エイ (72)発明者 マーティン グラント アメリカ合衆国 カリフォルニア州 94566 プレザントン レイヴァン ロー ド 2424 (72)発明者 パターソン ピーター アメリカ合衆国 カリフォルニア州 92692 ミッション ヴィージョ パシフ ィック ヒルズ ドライヴ 25585 (72)発明者 トゥロン コーアン アメリカ合衆国 カリフォルニア州 95035 ミルピタス グレンヴィュー ド ライヴ 2206 (72)発明者 ヴェンカトラマーニ クマー アメリカ合衆国 カリフォルニア州 95070 サラトーガ ヴィア リアル ド ライヴ 19495 Ｆターム(参考） 5B046 AA08 BA03 KA06 5F064 AA06 DD04 HH06 HH08 HH12

Claims (122)

【特許請求の範囲】
1. 【請求項１】設計者によって実施される、回路システムを設計するための方法で
   あり、この方法が、 （ａ）回路システムを設計するために使用される、予め設計された複数の回路
   ブロックを選択する段階と、 （ｂ）経験データ、推定データ、及び／又は実施データを含む、設計者のデー
   タを、予め設計された回路ブロックに関して収集し、前記設計者のデータは、或
   る処理方法に適合可能である段階と、 （ｃ）設計者のデータ及び受入れ可能なリスクの程度に基づいた仕方で、回路
   システムの設計を許可し又は拒絶する段階と、 （ｄ）許可された場合に、回路ブロックの各々に対する判断規準及び修正され
   た制約を含むブロック仕様を形成する（ＦＥＡ）段階と、 （ｅ）許可された場合に、選択された回路ブロック及び処理方法を変更するこ
   となしに、判断規準及び修正された制約に従って、チップのフロアープラン上に
   回路ブロックを展開するためにブロック仕様を形成する段階を含む方法。
2. 【請求項２】前記仕様がバス識別情報を含む請求項１記載の方法。
3. 【請求項３】前記仕様が試験法を含む請求項１記載の方法。
4. 【請求項４】（ｆ）許可された際に、回路ブロックに標準及びシステム特定イン
   タフェースを加えることにより、チップフロア計画上に回路ブロックを展開する
   段階を更に含む請求項１記載の方法。
5. 【請求項５】前記回路ブロックを相互接続するための接続回路を形成する段階を
   更に含む請求項４記載の方法。
6. 【請求項６】回路仕様に基づいて選択された回路ブロックをチップ内に製造する
   ためにトップレベル計画を形成する段階を更に含む請求項１記載の方法。
7. 【請求項７】処理を完了する以前に、段階（ｃ）、（ｄ）、（ｅ）、（ｆ）及び
   （ｇ）の各々の適正な実施を確認する段階を更に含む請求項５記載の方法。
8. 【請求項８】一人以上の設計者によって実施される、回路システムの設計方法で
   あり、この方法が、 （ａ）回路システムを設計するのに使用される予め設計された回路ブロックを
   選択する段階と、 （ｂ）予め設計されおり且つ依然として設計されるべき回路ブロックに関して
   、設計者の経験を反映するデータを集め、設計者の経験が処理方法に適合してい
   る段階と、 （ｃ）設計者の経験データ及び受入れ可能なリスクの程度に基づいた方法で、
   回路システムの設計を許可又は拒絶する段階と、 （ｄ）許可された場合、回路ブロックの各々に対する判断規準及び修正された
   制約を含むブロック仕様を形成する段階と、 （ｅ）許可された場合に、選択された回路ブロック及び処理方法を変更するこ
   となしに、設計対象に合う判断規準及び修正された制約に従って、チップのフロ
   ア計画上に回路ブロックを展開するために、クロック、電力及びバス通信に対す
   るブロック仕様及びグルー論理を形成する段階とを含む方法。
9. 【請求項９】（ｆ）許可された場合に、選択された回路ブロック及び処理方法を
   変更することなしに、判断規準及び修正された制約に従って、チップのフロア計
   画上に回路ブロックを展開するためにブロック仕様を形成する段階を含む請求項
   ４記載の方法。
10. 【請求項１０】前記段階（ｆ）が、チップのフロア計画上に回路ブロックを展開
    するために、回路ブロックの各々に対する仮想回路仕様を形成することを更に含
    む請求項９記載の方法。
11. 【請求項１１】前記設計者の経験データが、予め設計されたブロックの少なくと
    も一つの使用のフィールド、シミュレーション及び部分的又は完全な実施から成
    るグループの少なくとも一つを含む請求項８記載の方法。
12. 【請求項１２】（ｇ）回路ブロックを相互接続するためのグルー論理を形成する
    ための段階を更に含む請求項９記載の方法。
13. 【請求項１３】（ｇ）回路ブロックを相互接続するためのカラーインタフェース
    を形成する段階を含む請求項９記載の方法。
14. 【請求項１４】段階（ｆ）が、許可された場合に、仮想的回路仕様に基づいて選
    択された回路ブロックをチップ内に製造するためのトップレベル計画を形成する
    ことを更に含む請求項９記載の方法。
15. 【請求項１５】処理を改良する以前に、段階（ｃ）、（ｄ）、（ｅ）及び（ｆ）
    の各々の適正な実施を確認する段階を更に含むことを特徴とする請求項９記載の
    方法。
16. 【請求項１６】前記チップを製造するために必要な物理的レイアウト、マスク及
    び試験データを作成し且つその結果を検査する段階を更に含む請求項１４記載の
    方法。
17. 【請求項１７】所定の形態のパラメータに基づいた回路設計の実現可能性に到達
    するために現存する手順を拡張するための方法であって、この方法が、 （ａ）回路設計で使用されるべき複数の回路ブロックを選択する段階と、 （ｂ）回路ブロックに対する所定の形態のパラメータを受信する段階と、 （ｃ）所定の形態のパラメータに依存した現存する手順を使用して第１の実現可
    能性にアクセスし、この第１の実現可能性が第１のリスク指示子及び第１の時間
    ／コスト指示子を含む段階と、 （ｄ）現存する手順で使用されていない少なくとも一つの第２の形態のパラメー
    タを受信する段階と、 （ｅ）現存する手順に適応するために、第２の形態のパラメータを処理し、 （ｆ）所定の形態のパラメータ及び第２の形態のパラメータに基づいて、現存す
    る手順を使用して、第２の実現可能性にアクセスする段階を含み、この第２の実
    現可能性が第２のリスク指示子及び第２の時間／コスト指示子を含み、第２のリ
    スク指示子が、現存する手順の使用による第１のリスク因子と比較して、実質的
    に増加されなく、第２の時間／コスト因子が、第２の形態のパラメータのインパ
    クトによって、第１の時間／コスト因子と比較して増加される、前記の方法。
18. 【請求項１８】所定の形態パラメータが使用データのフィルードであり、第２の
    形態のパラメータが推定データ又は実現データの何れかである請求項１７記載の
    方法。
19. 【請求項１９】所定の形態のパラメータに基づいた回路設計の実現可能性にアク
    セスするために現存する手順を拡張するための方法であり、この方法が、 （ａ）回路設計で使用されるべき複数の回路ブロックを選択する段階と、 （ｂ）回路ブロックに対する所定の形態のパラメータを受信する段階と、 （ｃ）所定のパラメータに基づいた現存する手順を使用して第１の実現可能性に
    アクセスし、第１の実現可能性が第１のリスト指示子及び第１の時間／コスト指
    示子を含の段階と、 （ｄ）現存する手順で使用されていない少なくとも一つの第２の形態のパラメー
    タを受信する段階と、 （ｅ）第２の形態のパラメータと適合するために現存する手順を変化する段階と
    、 （ｆ）所定の形態のパラメータ及び第２の形態パラメータに基づいて、前記変化
    された手順を使用して第２の実現可能性にアクセスする段階とを含み、この第２
    の実現可能性が第２のリスト指示子及び第２の時間／コスト指示子を含み、前記
    第２のリスク指示子が、現存する手順の変化によって、第１のリスク因子と比較
    して、増大し、第２の時間／コストが、現存する手順の変化によって、第１の時
    間／コスト因子と比較して、実質的に増大されない、前記の方法。
20. 【請求項２０】所定の形態のパラメータが使用データのフィールドであり、第２
    の形態のパラメータが、推定データ又は実施データの何れかである請求項１９記
    載の方法。
21. 【請求項２１】所定の組の設計特徴に基づいて、回路設計の実現可能性にアクセ
    スするために現存する手順を拡張する方法であり、この方法が、 （ａ）設計リスクが知られており且つそれが受け入れることができる程小さい設
    計特徴の組を使用のフィールドとして定める段階と、 （ｂ）回路設計で使用されるべき複数の回路ブロックを選択する段階と、 （ｃ）回路ブロックに対する所定の設計特徴を受信する段階と、 （ｄ）使用特徴のフィールドに基づいて、現存する手順を使用して、第１の実現
    可能性にアクセスし、第１の実現可能性が第１のリスク指示子及び第１の時間／
    コスト指示子を含む段階と、 （ｅ）現存する手順で使用されていない少なくとも一つの第２の設計特徴を受信
    する段階と、 （ｆ）現存する手順と適合するために第２の設計特徴を処理する段階と、 （ｇ）使用特徴のフィールド及び第２の設計特徴に基づいて現存する方法を使用
    して第２の実現可能性にアクセスする段階とを含み、第２の実現可能性が第２リ
    スク指示子及び第２の時間／コスト指示子を含み、第２のリスク指示子が、現存
    する手順の使用のために第１のリスク因子と比較して、実質的に増大されなく、
    第２の時間／コスト因子が、第２の設計特徴のインパクトのために第１の時間／
    コスト因子と比較して、増大される、前記の方法。
22. 【請求項２２】所定の設計特徴が使用データのフィールドの定義内にあり、第２
    の形態の設計特徴の正しい予測と関連するエラーリスクが、推定データ又は実施
    データから知られることを特徴とする請求項２１記載の方法。
23. 【請求項２３】設計特徴の所定の組に基づいて、回路設計の実現可能性にアクセ
    スするために現存する手順を拡張する方法であって、この方法が、 （ａ）設計リスクが既知であり且つそれが小さい一組の設計特徴を使用のフィー
    ルドとして定める段階と、 （ｂ）回路設計で使用されるべき複数の回路ブロックを選択する段階と、 （ｃ）回路ブロックに対する所定の設計特徴を受信する段階と、 （ｄ）使用のフィールドの特徴に基づいて、現存する手順を使用して、第１の実
    現可能性にアクセスし、この第１の実現可能性が第１のリスク指示子及び第１の
    時間／コスト指示子を含む段階と、 （ｅ）現存する手順で使用されていない少なくとも一つの第２の設計特徴を受信
    する段階と、 （ｆ）第２の形態の設計特徴と適合するために現存する手順を変化する段階と、 （ｇ）使用設計特徴のフィールド及び第２の形態の設計特徴に基づいて、変化さ
    れた手順を使用して第２の実現可能性にアクセスする段階を含み、第２の実現可
    能性が第２のリスク指示子及び第２の時間／コスト指示子を含み、第２のリスク
    指示子が現存する手順の変化のために、第１のリスク因子と比較して、第２のリ
    スク指示子が増大され、第２の時間／コスト因子が、現存する手順の変化のため
    に、第１の時間／コスト因子と比較して、実質的に増大されない、前記の方法。
24. 【請求項２４】所定の設計特徴が使用データのフィルードの定義内にあり、第２
    の形態の設計特徴の正しい予測と関連するエラーリスクが推定データ又は実施デ
    ータから知られることを特徴とする請求項２３記載の方法。
25. 【請求項２５】回路設計に対する実現可能性評価を達成するための方法であり、
    この方法が、 （ａ）回路設計のための要求及び制約を受信する段階と、 （ｂ）回路設計で使用されるべき複数の予め設計された回路ブロックを選択する
    段階と、 （ｃ）回路ブロックに対する経験データのフィールドを収集する段階と、 （ｄ）回路ブロックに対する経験データのフィールドを使用して、第１のレベル
    決定ルールを生成し、第１のレベル決定ルールは、許可領域、拒絶領域、及び不
    確定領域を含む段階と、 （ｅ）第１のレベル決定ルールに基づいた要求及び制約を使用して、第１のレベ
    ル予測を行う段階と、 （ｆ）第１のレベル予測が第１のレベル決定ルールの許可領域内にある場合に回
    路の設計を許可し、第１のレベル予測が第１のレベル決定ルールの拒絶領域内に
    ある場合に回路設計を拒絶する段階と、 （ｇ）第１のレベル予測が第１のレベル決定ルールの不確定領域内にある場合、
    回路設計に対する第２のレベル予測を行うために第２のレベル決定ルールを形成
    する段階から成る、前記の方法。
26. 【請求項２６】（ｈ）回路ブロックに対する推定データを修正し、（ｇ）におけ
    る第２のレベル決定ルールが推定データを使用して形成され、第２のレベル決定
    ルールが許可領域、拒絶領域、及び不確定領域を含む段階と、 （ｉ）第２のレベル決定ルールに基づいた要求と制約を使用して、第２のレベ
    ル予測を行う段階と、 （ｊ）第２のレベル予測が第２のレベル予測ルールの許可領域内にある場合に
    その回路設計を許可し、第２のレベル予測が第２のレベル決定ルールの拒絶領域
    内にある場合に、その回路設計を拒絶する段階と、 （ｋ）第２のレベル予測が第２のレベル決定ルールの不確定領域内にある場合
    に、その回路設計に対する第３のレベル予測を行うための第３のレベル決定ルー
    ルを形成する段階とを更に含む請求項２５記載の方法。
27. 【請求項２７】（ｌ）回路ブロックに対する実施データを収集し、（ｋ）におけ
    る第３のレベル決定ルールが実施データを使用して形成され、第３のレベル決定
    ルールが許可領域、拒絶領域、及び不確定領域を含む段階と、 （ｍ）第３のレベル決定ルールに基づいた要求及び制約を使用して第３のレベ
    ル予測を行い、 （ｎ）第３のレベル予測が第３のレベル決定ルールの許可領域内にある場合に
    、その回路設計許可し、第３のレベル予測が第３のレベル決定ルールの拒絶領域
    内にある場合に、その回路設計を拒絶する段階と、を更に含む請求項２６記載の
    方法。
28. 【請求項２８】推定データが、経験データのフィールドよりも、より高い収集の
    コスト及びより高い精度を有しており、 実施データが、より高い収集コスト及びより高い精度を有する請求項２７記載
    の方法。
29. 【請求項２９】回路設計に対する第１の決定ルールを洗練する方法であり、この
    方法が、（ａ）回路設計の要求及び制約を受信する段階と、 （ｂ）設計に使用される複数の予め設計されたブロックを選択する段階と、 （ｃ）回路ブロックの少なくとも一つを臨界的回路ブロックとして識別し、残り
    の回路ブロックを非臨界的回路ブロックとして識別する段階と、 （ｄ）非臨界的回路ブロックに対する経験データのフィールドを収集し、臨界回
    路ブロックに対する推定データ及び／又は実施データを収集する段階と、 （ｅ）経験データのフィルードを推定データ又は実施データと組合せることによ
    り、洗練された決定ルールを形成する段階とを含む、前記の方法。
30. 【請求項３０】決定ルールが、許可領域、拒絶領域、及び不確定領域を含み、 （ｆ）（ｅ）の洗練された決定ルールに基づいた要求及び制約を使用して予測
    を行う段階と、 （ｇ）予測が許可領域内にある場合に、その回路設計を許可し、予測が拒絶領
    域内にある場合に、回路設計を拒絶する段階とを更に含む請求項２９記載の方法
    。
31. 【請求項３１】推定データが経験データのフィールドよりもより高い収集コスト
    及びより高い精度を有しており、 実施データが推定データよりもより高い収集コスト及びより高い精度を有して
    いる請求項３０記載の方法。
32. 【請求項３２】回路設計に対する第２の決定ルールを形成する方法であり、この
    方法が、 （ａ）回路設計の要求及び制約を受信する段階と、 （ｂ）複数の予め設計された回路ブロックを選択する段階と、 （ｃ）少なくとも一つの回路ブロックを臨界的ブロックとして識別し、残りの
    ブロックを非臨界的ブロックとして識別する段階と、 （ｄ）非臨界的回路ブロックに対する推定データを収集し、臨界回路ブロック
    に対する実施データを収集する段階と、 （ｅ）推定データ及び実施データを使用して洗練された第２の決定ルールを形
    成する方法。
33. 【請求項３３】決定ルールが、許可領域、拒絶領域、及び不確定領域を含み、 （ｆ）（ｅ）の洗練された決定ルールに基づいて要求及び制約を使用して予測
    を行う段階と、 （ｇ）予測が許可領域内にある場合には、その回路設計を許可し、予測が拒絶
    領域内にある場合には、その回路設計を拒絶する段階とを更に含む請求項３２記
    載の方法。
34. 【請求項３４】実施データが、推定データよりもより高い収集コスト及びより高
    い精度を有する請求項３３記載の方法。
35. 【請求項３５】回路システムを設計するのに使用されるべき複数の予め設計され
    た回路ブロックに関する設計者の経験データを編成する方法であり、前記方法が
    、設計者によって実施され、経験データは回路システム設計に対する実施可能性
    の評価を達成するのに使用される方法において、 （ａ）実施データを測定することのできる一組のパラメータを定義する段階と
    、 （ｂ）回路ブロックに関しての設計者の経験データを識別する段階と、 （ｃ）識別された設計者の経験データを複数のクラスに分類し、経験データク
    ラスが回路ブロックに対応する段階と、 （ｄ）設計者の経験データを決定ルールを形成するために使用し、決定ルール
    が許可領域、拒絶領域、及び不確定領域を含む段階と、 （ｅ）決定ルールに基づいて要求及び制約を使用して推定を行う段階とを含む
    、前記の方法。
36. 【請求項３６】推定が決定ルールの許可領域内にある場合には、回路システム設
    計を許可し、推定が決定ルールの拒絶領域内にある場合には、その回路システム
    設計を拒絶する段階を更に含む請求項３５記載の方法。
37. 【請求項３７】（ｆ）実施可能性評価エラーを最小化するために、経験データの
    クラスを洗練することを特徴とする請求項３５記載の方法。
38. 【請求項３８】 （ｆ）経験データを認証する段階を更に含む請求項３５記載の
    方法。
39. 【請求項３９】識別された経験データが、予測された経験データ又は収集された
    経験データの少なくとも一方を含む請求項３５記載の方法。
40. 【請求項４０】（ｆ）類似の設計の類似のパラメータを予測するために、識別さ
    れた設計者経験データに基づいてモデル組み立てる段階を更に含む請求項３５記
    載の方法。
41. 【請求項４１】デバイス設計が複数の予め存在する設計ブロックを含む集積回路
    デバイス設計法の実施おいて、グルー論理の分配効率を高める方法であり、この
    方法が、 選択されたグルー論理要素をコピーし、これによって、前記選択された要素と
    そのコピーを含む複製要素の組を生成する段階と、 前記複製要素の組を複数の設計ブロックに分配する段階とを含む、前記の方法
    。
42. 【請求項４２】デバイス設計が複数の予め存在する設計ブロックを含む集積回路
    デバイス設計法の実施おいて、設計ブロック間に複数のグルー論理要素を分配す
    る方法であり、この方法が、 第１のグルー論理要素が複数の負荷を駆動する出力ネットを含む場合、第１の
    要素を複数の誘導グルー論理要素に分割する段階と、 前記誘導要素を複数の設計ブロックに分配する段階とを含む、前記の方法。
43. 【請求項４３】各誘導要素が単一の出力負荷を有する請求項４２記載の方法。
44. 【請求項４４】第１のグルー論理要素が複数の入力を含み、分割要素が第１の要
    素である請求項４２記載の方法。
45. 【請求項４５】誘導要素が２つのみの入力を有する請求項４２記載の方法。
46. 【請求項４６】デバイス設計が複数の予め存在する設計ブロックから成る、集積
    回路デバイス設計法の実施おいて、設計ブロック間に複数のグルー論理要素を配
    分する方法であり、この方法が、 選択された品質に対する複数の要素を解析する段階と、 選択されたグルー論理要素を、解析に基づいた方法で選択されたブロックに併
    合する段階とを含む、前記の方法。
47. 【請求項４７】選択された要素に対する機能上の相性に基づいた方法で、選択さ
    れたブロックが選択される請求項４６記載の方法。
48. 【請求項４８】前記機能上の相性、前記併合が前記回路装置設計の固有の機能に
    対して要求される物理Ｉ／Ｏ要素の数を減少するか否かからなる請求項４７記載
    の方法。
49. 【請求項４９】２つ以上のブロックが併合に対する等しい候補である場合、最低
    ピン密度を有するブロックが選ばれる請求項４６記載の方法。
50. 【請求項５０】前記機能上の相性が、選択された要素及び選択されたブロックが
    両者で、チップレベルタイミング特徴を改良するか否かからなる請求項４７記載
    の方法。
51. 【請求項５１】デバイス設計が複数の予め存在する設計ブロックを含む集積回路
    デバイス設計法の実施おける、グルー論理を分配する方法であり、この方法が、 コピーされず且つ設計ブロック間で分配されないか、又は、設計ブロックと併
    合されない複数の要素を識別する段階と、 識別された複数の要素をクラスター化する段階とを含む、前記の方法。
52. 【請求項５２】クラスター化された要素が、入力ネット上に複数の負荷を有し、
    且つ出力ネット上に複数の負荷を含む請求項５１記載の方法。
53. 【請求項５３】複数の要素が類似の機能を有する入力を含む請求項５１記載の方
    法。
54. 【請求項５４】デバイス設計が複数の予め存在する設計ブロックを含む集積回路
    デバイス設計法の実施おける、設計ブロック間でグルー論理を分配する方法であ
    り、この方法が、 第１のグルー論理要素の第１の特徴を識別する段階と、 第１のグルー論理要素と互換性のある第２のグルー論理要素を作り出す第２の
    特徴を有する第２のグルー論理を識別する段階と、 前記第１のグルー論理要素を識別された第２のグルー論理要素と併合する段階
    とを含む、前記の方法。
55. 【請求項５５】前記第１の特徴が、前記第１のグルー論理要素によって要求され
    るピンの数から成る請求項５４記載の方法。
56. 【請求項５６】前記第１の特徴が、前記第１のグルー論理要素の入力構造からな
    る請求項５４記載の方法。
57. 【請求項５７】前記第１の特徴が、前記グルー論理要素の出力構造からなる請求
    項５４記載の方法。
58. 【請求項５８】第２のグルー論理要素が設計ブロックである請求項５４記載の方
    法。
59. 【請求項５９】．回路ブロックの特定のインタフェースを変換するための方法で
    あり、この方法が， （ａ）標準インタフェースを定義する段階と、 （ｂ）カラーインタフェースを回路ブロックに接続する段階を含み、このイン
    タフェースが回路ブロックに接続可能な第１の部分、標準インタフェースに従っ
    た第２の部分、及び特定のインタフェースを標準インタフェースに変換する第３
    の部分を有する、前記の方法。
60. 【請求項６０】前記カラーインタフェースは、ハード、ソフト又はファームフォ
    ーマットとすることができる請求項５９記載の方法。
61. 【請求項６１】前記回路ブロックは、メモリー、プロセッサ、ランダムロジック
    、又はアナログ／混合信号である請求項５９記載の方法。
62. 【請求項６２】前記カラーインタフェースは、ブロック特定標準層及びシステム
    特定層を含む複数の層を含む請求項５９記載の方法。
63. 【請求項６３】第１の回路ブロックと第２の回路ブロックとを接続する方法であ
    り、第１の回路ブロックが第１の特定のインタフェースを有し、第２の回路ブロ
    ックが第２の特定のインタフェースを有し、この方法が、 （ａ）第１及び第２の回路ブロックを接続するための標準インタフェースを定
    義する段階と、 （ｂ）第１の接続インタフェースを第１の回路ブロックに接続し、第１のイン
    タフェースは第１の回路ブロックに接続可能な第１の部分、標準インタフェース
    に従った第２の部分、及び第１の特定のインタフェースを標準インタフェースに
    変換するための第３の部分を含む段階と、 （ｃ）第２のカラーインタフェースを第２の回路ブロックに接続し、この第２
    のカラーインタフェースは第２の回路ブロックに接続される第１の部分、標準イ
    ンタフェースに従った第２の部分、及び特定のインタフェースを標準インタフェ
    ースに変換する第３の部分を有する段階と、 （ｄ）第１及び第２の回路ブロックを標準インタフェースを使用して接続する
    段階を含む方法。
64. 【請求項６４】第１及び第２インタフェースがハード、ソフト、又はファームフ
    ォーマットとすることができる請求項６３記載の方法。
65. 【請求項６５】第１及び第２回路ブロックがメモリ、プロセッサ、ランダムロジ
    ック、又はアナログ／混合信号である請求項６３記載の方法。
66. 【請求項６６】第１及び第２のカラーインタフェースが、ブロック特定標準層及
    びシステム特定層を含む多層を含む請求項６３記載の方法。
67. 【請求項６７】回路ブロックの特定のインタフェースを標準インタフェースに変
    換するカラーインタフェースであり、 （ａ）回路ブロックの特定のインタフェースに接続可能な成分を含む第１の部
    分、 （ｂ）標準インタフェースに従う第２の部分、および （ｃ）特定のインタフェースを標準インタフェースに変換する第３の部分から
    成るカラーインタフェース。
68. 【請求項６８】装置がハード、ソフト又はファームフォーマットとすることがで
    きる請求項６７記載のカラーインタフェース。
69. 【請求項６９】回路ブロックがメモリ、プロセッサ、ランダムロジック、又はア
    ナログ／混合信号である請求項６７記載のカラーインタフェース。
70. 【請求項７０】カラーインタフェースが、ブロック特定標準層及びシステム特定
    層を含む多層を含む請求項６７記載のカラーインタフェース。
71. 【請求項７１】第１の回路ブロックと第２の回路ブロックを標準インタフェース
    を介して接続し、第１の回路ブロックが第１の特定インタフェースを有し、第２
    の回路ブックが第２の特定のインタフェースを有する、インタフェースシステム
    であり、 （ａ）第１の回路ブロックに接続された第１のカラーインタフェースであり、
    （１）第１の回路ブロックの特定のインタフェースに接続可能な構成要素を含む
    第１の部分、（２）標準インタフェースに従う第２の部分、及び第１の特定のイ
    ンタフェースを標準インタフェースに変換するための構成要素を含む第３の部分
    を含む第１のカラーインタフェースと、 （ｂ）第２の回路ブロックに接続される第２のカラーインタフェースであり、
    （１）第２の回路の特定インタフェースに接続可能な構成要素を含む第１の部分
    、（２）標準インタフェースに従う第２の部分、及び第２の特定のインタフェー
    スを標準インタフェースに変換するための構成要素を含む第３の部分を含む第２
    のカラーインタフェースとを含むインタフェースシステム。
72. 【請求項７２】第１及び第２のカラーインタフェースがハード、ソフト、又はフ
    ァームフォーマットとすることができる請求項７１記載のインテフェースシステ
    ム。
73. 【請求項７３】第１及び第２の回路ブロックがメモリ、プロセッサ、ランダムロ
    ジック、又はアナログ／混合信号である請求項７１記載のインタフェースシステ
    ム。
74. 【請求項７４】第１及び第２のカラーインタフェースが、ブロック特定標準層及
    びシステム特定層を含む多層を含む請求項７１記載のインタフェースシステム。
75. 【請求項７５】設計中の回路が複数の予め存在する設計ブロックから成る回路設
    計方法における、回路バスを選択する方法が、 複数の設計ブロック間のデータトランザクションの作動状態を観測する段階と
    、 観測されたトランザクションの作動状態から、複数のバスの判断規準を導く段
    階と、 前記複数のバス判断規準に基づいた方法で利用可能なバス設計ブロックからバ
    ス構造を選択する段階と、 前記選択されたバス構造を前記回路中に集積する段階とを含む、前記の方法。
76. 【請求項７６】前記複数のバス判断規準が、バスサイズ、バスバンド幅、バス性
    能レベル、及び信号待ち時間から成るグループの内の少なくとも一つから成る請
    求項７５記載の方法。
77. 【請求項７７】バスを選択する以前に、ブロック間の複数の通信要求にに従って
    複数の設計ブロックをクラスター化し、複数のブロッククラスターを形成する段
    階を更に含む請求項７５記載の方法。
78. 【請求項７８】バスサイズ、バスバンド幅、バス性能レベル、及び信号待ち時間
    から成るグループの内の少なくとも一つから成るバス選択規準が、各々形成され
    たクラスターに割り当てられている請求項７７記載の方法。
79. 【請求項７９】 前記導く段階が、回路内の少なくとも一つのブロックとＩ／Ｏ
    構造との間での通信に対する要求を導くことから成る請求項７５記載の方法。
80. 【請求項８０】バスインタフェースロジック回路を改良することにより、選択さ
    れたバス構造を回路内にマッピングすることを更に含む請求項７５記載の方法。
81. 【請求項８１】前記導く段階が、 複数のデータ転送カウントエントリを含む、データ転送マトリックスを生成す
    る段階と、 マトリックスの中心軸に向かってカウントの最大値を移動することによって、
    データ転送マトリックスを編成する段階からなる請求項７５記載の方法。
82. 【請求項８２】前記導く段階が、更に、選択された重み付け判断規準に従って、
    カウントエントリを重み付けする請求項８１記載の方法。
83. 【請求項８３】前記導く段階が、選択されるべきバス内のデータ流の分布を表わ
    す複数のデータを含むクラスター値マトリックスを生成する段階と、 前記分布データを選択的に再有機化することにより選択されるべきバス内のデ
    ータ流を最適化する段階とから成る請求項７７記載の方法。
84. 【請求項８４】データトランザクョシンの作用状態を観測する段階が、作動状態
    モデルで達成される請求項７５記載の方法。
85. 【請求項８５】作動状態モデルが複数の設計ブロックとＩ／Ｏ構造を含む請求項
    ８４記載の方法。
86. 【請求項８６】作動状態モデルがトランザクションデータを収集するように修正
    される請求項８４記載の方法。
87. 【請求項８７】複数の予め存在する設計ブロックから成る回路設計を実現するた
    めのブロックベース設計法における、前記設計を具体化する装置を設計し製造後
    に装置を試験することを可能にする方法において、この方法が、 試験開発フレームワークを設立する段階と、 このフレームワークに従って、設計ブロックを試験するための複数の試験ブロ
    ックを開発する段階と、 前記フレームワークに従って複数の試験ブロックを、回路設計のための試験を
    展開するためにマッピングする段階を含む、前記の方法。
88. 【請求項８８】前記設立する段階が、一組のクオリファイヤーに従って複数の予
    め存在する設計ブロックを識別し、前記クオリファイヤーが、試験モデル、試験
    方法、試験データ、及び試験インタフェースから成るグループの内の少なくとも
    一つのエントリから成る請求項８７記載の方法。
89. 【請求項８９】一組のクオリファイヤーが、トップダウン試験プランを可能とす
    る設計ブロックの抽象化から成る請求項８８記載の方法。
90. 【請求項９０】前記プランが、ブロックの各々に対するシケン予算から成る請求
    項８７記載の方法。
91. 【請求項９１】２つ以上のブロックの同時試験を可能とすることを更に含む請求
    項８７記載の方法。
92. 【請求項９２】前記可能とする段階が、デバイスレベル試験インタフェースから
    成る請求項９１記載の方法。
93. 【請求項９３】前記可能とする段階が、試験ブロック間のテスターセットアップ
    時間を最小化するためにテスター時間設定を操作する請求項９１記載の方法。
94. 【請求項９４】前記フレームワーク及びブロック試験を、試験再利用性に対する
    試験準備設計ブロックとしてパッケージングすることから更になる請求項８７記
    載の方法。
95. 【請求項９５】複数の予め存在する設計ブロックから成る集積回路デバイスを製
    造後試験が可能である様に設計する方法が、 回路試験開発フレームワークを設立するために予め存在するブロックを抽象化
    する段階と、 デバイスに対する、複数の試験を含む設計法を形式化するが、回路設計を全体
    的に試験することが可能であることを予測に推定することを維持する段階とから
    成る、前記の方法。
96. 【請求項９６】回路試験フレームワークが複数のテトス目的のために最適化され
    る請求項９５記載の方法。
97. 【請求項９７】回路試験フレームワークが、予め定められたブロックの試験可能
    性のリスクレベルが許可可能なレベルよりも大きい場合には、拒絶される請求項
    ９５記載の方法。
98. 【請求項９８】フレームワークは試験コスト予算判断規準からなる請求項９５記
    載の方法。
99. 【請求項９９】ある試験を設計法に加えることにより、試験効力の交換を実施す
    ることを更に含む請求項９８記載の方法。
100. 【請求項１００】設計法からある試験を除去することにより、試験効力の交換を
     実施することからなる請求項９８記載の方法。
101. 【請求項１０１】指定された許容度内で設計法を洗練することを更に含む請求項
     ９５記載の方法。
102. 【請求項１０２】選択された好適な試験方法で各ブロックが試験されるべきこと
     を可能にすることにより、設計法の一部として同時的試験開発を可能にすること
     を更に含む請求項９５記載の方法。
103. 【請求項１０３】設計法が試験インタフェースを含みこのインタフェースが複数
     の異なる試験プロトコルと互換性のある請求項９５記載の方法。
104. 【請求項１０４】２つ以上のブロック試験を同時に実施することにより、設計法
     の試験スケジュール部分を簡単化することを更に含む請求項９５記載の方法。
105. 【請求項１０５】設計ブロック間の試験ベクトルを複製し、設計法での試験ブロ
     ック間の経過時間を減少することを含む請求項９５記載の方法。
106. 【請求項１０６】複数の類似のブロックが同時に実施され、結果試験時間が減少
     される請求項９５記載の方法。
107. 【請求項１０７】複数の回路設計に適合するために、設計者フィードバックを使
     用して設計法を更新する請求項９５記載の方法。
108. 【請求項１０８】複数の予め存在する設計ブロックから成る回路設計の固有の機
     能を検査する方法であり、 回路設計モデル及び回路試験ベンチを得る段階と、 回路設計モデルを複数のブロックモデルに分ける段階と、 複数のブロックモデルを相互接続するバスモデルを生成する段階と、 複数のブロックモデル及びバスモデルを検査するための複数の試験ベンチを生
     成する段階と、 複数のブロックモテル及びバスモデルの機能を検査するための試験ベンチを使
     用する段階とを含む、前記の方法。
109. 【請求項１０９】回路設計モデルがトップレベル計画を含む請求項１０８記載の
     方法。
110. 【請求項１１０】バスモデルがブロックモデルからグルー論理を含む請求項１０
     ８記載の方法。
111. 【請求項１１１】ブロックモデルの機能がレジスタ転送言語検査を含む請求項１
     ０８記載の方法。
112. 【請求項１１２】ブロックモデルの機能が予めレイアウトされたネットリスト検
     査を含む請求項１０８記載の方法。
113. 【請求項１１３】ブロックモデルの機能がレイアウト後ネットリスト検査を含む
     請求項１０８記載の方法。
114. 【請求項１１４】複数ののブロックモデルを検査する試みの後に、複数のブロッ
     クモデルが、サイクル精度のために修正される請求項１０８記載の方法。
115. 【請求項１１５】回路設計用の試験ベンチを開発し、 回路設計の機能を検査することを試みることを更に含む請求項１０８記載の方
     法。
116. 【請求項１１６】回路設計の機能がレジスタ転送言語検査を含む請求項１１５記
     載の方法。
117. 【請求項１１７】回路設計の機能がレイアウト前のネットリスト検査を含む請求
     項１１５記載の方法。
118. 【請求項１１８】回路設計の機能を検査することが、レイアウト後のネットリス
     ト検査を含む請求項１１５記載の方法。
119. 【請求項１１９】回路設計を検査することを試みる後に、回路試験ベンチがサイ
     クル精度に関して修正される請求項１０８記載の方法。
120. 【請求項１２０】初期の作動形態レベル試験ベンチを、タイミングの競合無しに
     、設計の全てタイミングが正確な観点での機能検査に対して好適なサイクル正確
     試験ベンチに含む方法でおいて、 試験ベンチ上での設計を実行した際の不変出力を決定する段階と、 試験ベンチをクロックを含む様に修正する段階と、 タイミングが正確なモデル上で修正された試験ベンチを実施する段階と、 試験ベンチの不変出力を比較する段階とから成る、前記の方法。
121. 【請求項１２１】 複数の予め存在する設計ブロックを含む回路設計の固有の機
     能を検査する方法であり、 トップレベル計画及び複数のブロックモデルを含む回路設計モデルを得る段階
     と、 回路試験ベンチを得る段階と、 複数のブロックモデルを相互接続するバスモデルを生成する段階と、 複数のブロックモデル及びバスモデルを検査するための複数の試験ベンチを生
     成する段階と、 複数のブロックモデル及びバスモデルの機能を検査するために試験ベンチを使
     用する段階とを含む、方法。
122. 【請求項１２２】初期の作用形態レベル試験ベンチを、タイミングの競合無しに
     、設計の実質的にタイミングが正確な観点での機能検査に対して好適なサイクル
     が正確な試験ベンチに含む方法でおいて、 試験ベンチ上での設計の実施による不変出力を決定する段階と、 試験ベンチをクロックを含む様に修正する段階と、 実質的にタイミングが正確なモデル上で修正された試験ベンチを実行する段階
     と、 試験ベンチの不変出力を比較する段階とを含む方法。