JP5004566B2 - 設計を検証するシステム - Google Patents

Description

本発明は、設計を検証する方法およびシステムに関し、より詳細には、シミュレーション・プロセスを用いてシステム・オン・チップ（ＳｏＣ）設計を検証する方法およびシステムに関する。

昨今の集積回路（ＩＣ）チップは、複雑さおよび精巧さの点でかなり高度化している。例えば、以前の世代のチップ設計では、チップは、論理ゲート間の相互接続部によってもたらされる比較的簡単な電子論理ブロックを具体化していたが、より新しい世代のチップの設計は、しばしば「コア」と呼ばれる複雑でモジュール化されたＩＣ設計の組み合わせを含み、これらのコアが合わさってＳｏＣ全体が構成される。これらのより新しい世代のＩＣ設計では、例えば、フィーチャ・サイズをより小型にすることができ、そのため、単一チップ上に構築し得る回路の量が増加することによって、チップ自体の全体的な機能および性能の特徴が大きく向上する。しかし、これには、コストがかかる。というのは、設計および検証の時間がより長くかかり、その結果、追加の開発および製作のコストを要するからである。

このような複雑なＩＣチップを設計するために、ＩＣチップ開発には、設計段階および検証段階が含まれる。後者は、実行可能性（workability）、したがってチップ自体の機能を決定するのに不可欠である。例えば、設計が予想どおりに機能するかどうかを決定するのは、この検証段階である。

検証段階は、まずハードウェアで設計を実装してこのような設計の実行可能性を検証するコストを避けるために、ソフトウェア・シミュレーションによる手法に向かいつつある。しかし、マルチプロセッサおよびマルチコアの設計では、シミュレーションごとに設計およびテスト・ベンチ全体を構築しなければならないために、シミュレーション・モデルが極めて大きくなることがある。最新のシミュレーション・ツールを利用しても、シミュレーションの負荷および実行時間ならびに構築時間は、コストおよび時間が非常に大きくなることがある。このことは、複雑な設計の場合に特に当てはまる。というのは、設計の完全なゲート・レベルの表現を構築し、それをシミュレーションにロードしなければならないからである。

例を挙げると、設計を検証する際に、シミュレータ（例えば、ＶｅｒｉｌｏｇまたはＶＨＤＬなどのハードウェア記述言語（ＨＤＬ）で書かれたソフトウェアを受け入れることを含む機能を有する特殊なソフトウェア）は、回路設計（例えば、コア）をモデル化して、この設計の応答をシミュレーションする。テスト・ケースは、この応答を適用して、この設計が予想どおりに機能するかどうかを決定する。しかし、許容し得る程度にバグのない設計を達成するには、この検証ソフトウェアは、完全な設計を既存のツールにロードして、この設計を成功裏に検証しなければならない。すなわち、シミュレーション中の設計を十分に働かせるように、多数のテスト・ケースを適用しなければならない。

チップ設計が、個々のコアおよびコア間の相互作用の点でより複雑になるにつれ、検証は、さらに膨大な量の時間と計算リソースを必要とする傾向がある。これは、主として、設計全体に関する諸機能の相互作用のモデル化および検証のためである。

すなわち、例えば、検証プロセスは、たった１つの機能をテストするか、または２つ以上の機能間の相互作用をテストする場合でさえ、テスト設計全体をロードして働かせる必要があり、そのため、指数関数的に長くなる。現在の検証方法におけるこれらの非効率さにより、時間に追われることが多くなり、ＩＣチップの開発業者および販売業者にとって事業で競争力を維持するための主要なファクタである、製品が市場に出るまでの時間がかなり長くなる。

本発明の第１の側面では、設計を検証する方法が提供される。この方法は、ある設計に対して離散的なテスト・ケースまたは１組の関連するテスト・ケースを実行するのに必要とされるリソースを抽出するステップを含む。この方法はさらに、抽出されたリソースに基づいてシミュレーション・モデルを構築するステップと、設計全体ではなく、抽出されたリソースだけを用いてこのシミュレーション・モデルを実行することにより、設計検証用の離散的なテスト・ケースまたは１組の関連するテスト・ケースが表す特定の機能または一群の相互に関係する機能をテストするステップとを含む。

本発明の実施形態では、抽出されたリソースは、この設計の特定の機能または一群の相互に関係する機能に関係するパーティションとして構築される。シミュレーション・モデルは、特定の機能または一群の相互に関係する機能をテストするのに必要とされる独立検証のための、個々の独立したテスト・ケースに分割することができる。本発明の実施形態では、抽出されたリソースは、少なくとも１組の共通必須要素およびテスト・ケース固有要素を含む。

本発明の別の実施形態では、この方法は、ＢＯＭ（build of materials：部品表）生成を構築することを含み、これは、少なくともチップ基本要素と、この設計を表すテスト・ケース固有要素とを組み合わせることを含む。チップ基本要素は、少なくとも１組の共通の非テスト・ケース固有要素である。この方法はさらに、テスト・ケースまたは１組のテスト・ケース内で、リソースを１組のＫＥＹＷＯＲＤとして提供することを含む。これらのＫＥＹＷＯＲＤは、これらのテスト・ケースまたは１組のテスト・ケースについてのリソースを指定するのに使用する。これらのリソースは、ハードウェアとすることができ、少なくとも１つの内部または外部リソースを含み得る。

本発明の別の実施形態では、この方法は、後続のシミュレーションの実行に関連するテスト・ケースまたは１組のテスト・ケース用のリソースをパースするステップを含む。この方法はさらに、パースされたリソースのキーワードと共通要素を組み合わせて、コンパイル用のＢＯＭモデル・ビルド・ファイルを生成することを含む。パースするステップは、特定のテスト・ケース用の異なるＢＯＭモデル・ビルド・ファイルを識別し、それにアクセスすることも含む。このＢＯＭモデル・ビルド・ファイルは、シミュレーション・モデルをコンパイルするための「スタブ」ファイルを生成する。これらのスタブ・ファイルは、シミュレーション・モデル内に完全に機能するモデル表現（すなわち、実モデル表現）および空モデル表現をインストールするようにモデル・ビルド・プロセスに命令する。この実モデル表現は、シミュレーション中に正確に振る舞い、検証すべき特定の機能または相互に関係する機能群にそれぞれ関連する、１つのパーティションまたは特定の一群のパーティションについて合成される。空モデル表現は、この設計の、シミュレーションも検証もされない残りの部分を表す。

本発明の別の実施形態では、この方法は、１組の共通必須要素および設計用のリソースを提供するステップを含む。これらのリソースは、テスト・ケース仕様についてパースされ、共通必須要素と組み合わされて、ＢＯＭのモデル・ビルド・ファイルを生成する。このＢＯＭモデル・ビルド・ファイルに基づいて、シミュレーション・モデルをコンパイルするためのスタブ・ファイルが生成される。この方法はさらに、設計全体ではなく、シミュレーション・モデルを用いて、検証すべき設計の離散的な機能をシミュレーションするステップを含む。この方法はさらに、離散的な機能のシミュレーション結果とテスト計画とを相関させることを含む。

本発明の別の実施形態では、１組の共通必須要素は、非テスト・ケース固有要素を含む。これらの非テスト・ケース固有要素は、シミュレーション・モデル用の設計の基本ビルディング・ブロックを記述する。

別の実施形態では、このシミュレーション・モデルは、設計全体ではなく、この設計の特定の機能を独立して検証するための個々の独立したサブシステムのパーティションを含む。この設計の特定の機能についてＢＯＭモデル・ビルド・ファイルを提供することができ、それを保存し再利用してシステム・リソースを活用し得る。この方法を用いて、流通用集積回路チップを製作することもできる。この方法はさらに、シミュレーション・モデルを用いて、ある設計に対して特定のテスト・ケースまたは１組のテスト・ケースを実行するのに必要とされるリソースのみを抽出することによって、シミュレーション・モデルのサイズおよび複雑さを体系的に低減する。

本発明の別の実施形態では、これらのリソースは、テスト・ケース必須リソースを指定するのに用いる１組のＫＥＹＷＯＲＤとして指定されるハードウェア・リソースである。これらのハードウェア・リソースは、検証すべき各機能ごとに特定のテスト・ケースを生成し、ＢＯＭモデル・ビルド・ファイルは、モデル・ビルド・プロセスに命令するためのスタブ・ファイルを生成する。

本発明の実施形態では、モデル・ビルド・プロセスは、実モデル表現および空モデル表現を含む。実モデル表現は、シミュレーション中に正確に振る舞い、設計全体ではなく、検証すべき機能を表すテスト・ケース仕様について合成することができる。空モデル表現は、この設計の１つ（または複数）の残りの部分を表す。別の実施形態では、空モデル表現のすべての出力を不活動状態にアサートするために「タイ・オフ」が提供され、それによって、それ以外では空モデル表現がシミュレーション・モデルで用いられないようにする。この方法はさらに、ＡＤＦ（アプリケーション定義ファイル）を用いてユーザ指定パラメータをコンパイルすることにより、シミュレーション・モデルにおいて検証すべき特定のテストを生成するステップを含む。

本発明の別の側面では、本発明のステップを実装するシステムが提供される。本発明の別の側面では、コンピュータ可読プログラムが提供される。このコンピュータ可読プログラムは、コンピュータ上で実行されると、このコンピュータに、ある設計に対して離散的なテスト・ケースまたは１組の関連するテスト・ケースを実行するのに必要とされるリソースを抽出させ、抽出されたリソースに基づいてシミュレーション・モデルを構築させ、設計全体ではなく、抽出されたリソースのみを用いてこのシミュレーション・モデルを実行させることにより、設計検証用の離散的なテスト・ケースまたは１組の関連するテスト・ケースによって表される特定の機能または一群の相互に関係する機能をテストさせ、さらに離散的な機能のシミュレーション結果とテスト計画を相関させることを含む。

本発明は、ＩＣ設計を検証する方法およびシステムに関し、より詳細には、改善されたシミュレーション・プロセスを用いたシステム・オン・チップ（ＳｏＣ）設計検証用の方法およびシステムに関する。本発明の実施形態では、このシステムおよび方法は、例えば、ある設計に対して特定のテスト・ケースまたは１組のテスト・ケースを実行するのに必要とされるリソースのみを抽出することによって、シミュレーション・モデルのサイズおよび複雑さを体系的に低減する。このようにして、これら１つ（または複数）のテスト・ケースを実行するのに必要とされる本質的なコンポーネントだけがシミュレーション・モデル内で実際に構築される。このように、これらの必要とされる部分のみを構築しシミュレーションすることによって、複雑なＳｏＣ設計が最小限の共通部分に低減される効果が得られる。そのため、このシステムおよび方法により、実装時に、検証の有効性を損なわずに、最小限のシミュレーション・モデルが構築される。

ＢＯＭ生成
１つの実装では、設計の検証を実施するために、ＢＯＭを構築する。一実施例として、ＢＯＭは、ＩＣの設計を検証するのに必要とされる項目のリストを含む。実装時に、このリストは、チップ・インテグレータによって提供される１組の共通必須要素と、特定のテスト・ケース用の特定のハードウェア・リソースのリストとを含み得る。そのため、一実施形態では、このシステムおよび方法は、チップの基本要素とテスト・ケース固有要素とを組み合わせることによってＢＯＭを構築し、それによって、シミュレーション・モデルについての必要な最小限のＢＯＭが生成される。

一実施形態では、独立した検証を行うために、シミュレーション・モデルを構築し、それを個々の独立したサブシステムまたはテスト・ケース（例えば、個々の設計機能）に分割することができる。このようにして、最終的なシミュレーション・モデルは、とりわけ、パーティションにまたがる機能を検証することを含み得る、設計の特定機能をテストするのに必要とされるパーティション（モデル）だけを含むことができる。こうすると、各機能をテストするごとに、チップ設計全体をモデル化し、ロードし、シミュレーションすることが不要になる。その代わりに、設計全体ではなく、パーティションまたは別々のチップ機能を検証することができる。

一実施形態では、このパーティション処理は、チップ・インテグレータによって提供されるテスト計画に基づいて行う。ここで、このテスト計画は、設計全体をロードし、シミュレーションし、検証することを必要とせずに、特定の設計機能をテストし検証するための個々のテスト・ケースに変換される。１つの実装では、特定のＩＣ用の共通設計機能についてシステム・リソースを活用するために、すなわち、メモリおよび記憶装置などのコンピュータ・リソースをより効率よく利用するために、これらのパーティションを保存し再利用することができる。こうすると、このような機能をモデル化し直す必要がなくなる。

図１を参照すると、以下のステップを用いてシミュレーション・モデルを構築するためのＢＯＭデータを生成することができる。これらのステップを実装すると、エンド・ユーザは、単にＳｏＣシミュレーション中にどの１つ（または複数）のテスト・ケースを実行するかを指定するだけで、最適なシミュレーション用の可能な最も小さいモデルを自動的に生成することができる。

ステップ１００では、チップ・インテグレータによって、１組の共通必須要素が提供される。これらの共通必須要素は、非テスト・ケース固有要素とすることができ、実行すべき基本的なものとしてすべてのモデルについて含めることができる。１つの実装では、これらの非テスト・ケース固有要素は、構築する必要はなく、検証のために用いられる必要もない。これらの共通必須要素は、典型的には環境的なものであり、チップを構築すべき基本ビルディング・ブロックを記述するのに使用される。非例示的な例として、非テスト・ケース固有要素は、いくつか例を挙げると、マイクロプロセッサ、バス、リセット、およびクロックの記述を含み得る。

ステップ１１０では、テスト・ケースの仕様内で、テスト・ケース必須リソースを指定するのに使用し得る１組のＫＥＹＷＯＲＤとして、１つ（または複数）の必要なハードウェア・リソースが指定される。一実施形態では、ハードウェア・リソースのリスト化は、検証すべき設計の各機能ごとに特定のテスト・ケースを生成するために必要とされる。これらのハードウェア・リソースは、例えば、割込みコントローラ、ＤＭＡコントローラ、メモリ・コントローラなどの内部デバイス、ならびにメモリ・モデル、外部バス・マスタなどの外部デバイスとし得る。

特定の例では、ＩＢＭ社のａｕｔｏＴＯＳ（商標）ＡＤＦ（アプリケーション定義ファイル：ソフトウェア・リソースを指定するところである）を用いてユーザ指定パラメータ（例えば、リソース）をコンパイルし、それによって、検証すべき特定のテストを生成することができる。当業者には周知のように、ａｕｔｏＴＯＳ（商標）は、テスト・プロセスおよび生成プロセスを自動化するのに使用するコンパイラ・ツールである。１つの実装では、当業者には理解されるように、ａｕｔｏＴＯＳ（商標）を用いて、テンプレートを実装するテスト・ケースを生成することができる。

ステップ１２０では、本発明のシステムおよび方法は、後続のシミュレーションの実行に関連するテスト・ケース（または１組のテスト・ケース）ごとにリソースのキーワードをパースする。ステップ１３０では、これらのパースされたリソースのキーワードと共通必須要素を組み合わせ、それを用いてＢＯＭモデル・ビルド・ファイルを生成する。パース処理には、１つ（または複数）の各テスト・ケースごとにリソースを識別することを含めることができ、それによって、このシステムおよび方法が、特定のテスト・ケースについて異なるＢＯＭまたはパーティションを識別し、アクセスすることができる。

ステップ１４０では、ＢＯＭモデル・ビルド・ファイルを用いて、サブセットまたはシミュレーションのモデルのコンパイルを指示するファイルである、Ｖｅｒｉｌｏｇ「スタブ」ファイルを生成する。当業者には周知のように、Ｖｅｒｉｌｏｇ ＨＤＬは、電子システムを設計し且つ文書化するのに用いるハードウェア記述言語である。

上記のステップを用いることによって、ＳｏＣシミュレーションで実行すべき特定のテスト・ケースを指定することが可能である。こうすると、ユーザは、最適なシミュレーション用の可能な最も小さいモデルを自動的に生成することができる。

スタブ・ファイル
本発明の方法およびシステムでは、スタブ・ファイルを用いてモデル・ビルド・プロセスに命令することができる。すなわち、スタブ・ファイルを使用すると、ＢＯＭモデル・ビルド・ファイルを実装すべきファイルを、モデル・ビルド環境内に含めることができる。実施形態の一例として、以下でより詳細に論じるように、これらのスタブ・ファイルは、各ビルディング・ブロック（例えば、設計の機能ブロック）ごとに実モデル表現、または空モデル表現をインストールするようにモデル・ビルド・プロセスに命令することができる。

図２を参照すると、一実施例では、モデルの各ビルディング・ブロックは、２つのＨＤＬ（ハードウェア記述言語）表現を含む。ただし、ＨＤＬは単なる１つの実装であって、本発明とともに任意の既知の既存の検証システムを実装し得ることが当業者には理解されよう。

図２を再度参照すると、一方の表現は「実」モデルであり、他方の表現は「空」モデルまたはボックスである。この「実」モデル表現は、シミュレーション中に正確に振る舞い、かつ、１つのパーティションまたはある特定の一群のパーティションについて合成し得るモデルである。そのため、この「実」モデル表現は、検証すべき特定の機能または相互に関係する機能の振る舞いを記述するモデルに限定される（設計全体は含まない）。

「空」ボックス表現は、シミュレーションも検証も行わない設計の１つ（または複数）の残りの部分である。１つの実装では、「空」ボックスの中身は、すべての出力をそれらの不活動状態にアサートするのに用いる「タイ・オフ（tie-off）」である。このようにして、これらのボックスが、それ以外は、検証すべき特定のパーティションのシミュレーション・プロセスで使用されないようにする。当然のことながら、空ボックス表現では、はるかに高速にシミュレーションが行われ、この特定のビルディング・ブロックが、その特定のシミュレーションに関与しなければ、シミュレーションの精度が損なわれることはない。

本発明の１つの実装では、本発明のシステムおよび方法は、検証を実施するのに使用する現在のＴＯＳ ＡＤＦ（アプリケーション定義ファイル）言語を拡張したものである。そのため、一実施形態では、本発明のシステムおよび方法を実装することによって、ＴＯＳ ＡＤＦテスト・オペレーティング・システムを使用して、モデル全体の代わりに、テスト・ケースを表現する。すなわち、本発明のシステムおよび方法を実装することによって、ＴＯＳ ＡＤＦを用いて特定のパーティションについて特定のパラメータを実装することができる。別の実装では、本発明のシステムおよび方法は、所与のチップの基本操作について必要とされる共通必須要素を指定するＴＯＳ ＳＤＦ（システム定義ファイル）言語を拡張したものとして用いられる。

本明細書で説明する方法は、集積回路チップの製作に用いられる。得られた集積回路チップは、未加工ウエハの形態で（すなわち、複数のパッケージされていないチップを含む１枚のウエハとして）、またはベア・ダイとして、あるいはパッケージされた形態で製作することによって流通させることができる。後者の場合、チップは、単一チップ・パッケージ（マザー・ボードその他のより高水準キャリアに接続されるリード線を備えたプラスチック・キャリアなど）に、あるいは、マルチチップ・パッケージ（表面相互接続部または埋込相互接続部あるいはその両方を有するセラミック・キャリアなど）に実装される。いずれの場合でも、その後このチップを、他のチップ、離散的な回路要素、または、（ａ）マザー・ボードなどの中間製品または（ｂ）最終製品のいずれかの一部としての他の信号処理デバイスと集積するか、あるいはこれらを組み合わせて集積する。この最終製品は、玩具その他のローエンド応用例から、ディスプレイ、キーボードその他の入力デバイス、および中央プロセッサを有する最新のコンピュータ製品まで、集積回路チップを含む任意の製品とし得る。

本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェアおよびソフトウェアの要素をともに含む実施形態をとり得る。好ましい実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロ・コードなどを含むソフトウェアで実装されるが、ソフトウェアに含まれる例はこれらに限定されるものではない。さらに、本発明は、コンピュータまたは任意の命令実行システムが使用する、あるいは、それに関係するプログラム・コードを提供する、コンピュータが使用可能な、またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラムの形態をとり得る。この説明では、コンピュータが使用可能な、またはコンピュータ可読媒体は、命令実行用のシステム、装置、またはデバイスが使用する、あるいは、それに関係するプログラムを含み、記憶し、通信し、伝播させ、転送することができる任意の装置とし得る。

この媒体は、電子媒体、磁気媒体、光学媒体、電磁気媒体、赤外媒体、または半導体システム（あるいは装置またはデバイス）媒体、あるいは伝播媒体とし得る。コンピュータ可読媒体の例には、半導体メモリまたは固体メモリ、磁気テープ、取り外し可能なコンピュータ用ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、剛体磁気ディスク、および光ディスクが含まれる。光ディスクの現在の例には、読出し専用メモリ型コンパクト・ディスク（ＣＤ−ＲＯＭ）、読書き型コンパクト・ディスク（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが含まれる。

プログラム・コードの記憶または実行あるいはその両方を行うのに適したデータ処理システムには、システム・バスを介してメモリ要素に直接または間接的に結合した少なくとも１つのプロセッサが含まれる。これらのメモリ要素は、プログラム・コードの実際の実行時に使用されるローカル・メモリ、バルク記憶装置、および実行時にバルク記憶装置からコードを取り出さなければならない回数を少なくするために少なくとも何らかのプログラム・コードの一時記憶装置を提供するキャッシュ・メモリを含み得る。

入力／出力デバイスすなわちＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイスなどが含まれるが、これらに限定されるものではない）は、直接、あるいは仲介するＩ／Ｏコントローラを介して、システムに結合することができる。データ処理システムを、仲介する専用または公共のネットワークを介して他のデータ処理システム、あるいは離れたプリンタまたは記憶装置に結合することができるように、ネットワーク・アダプタをシステムに結合することもできる。モデム、ケーブル・モデム、およびイーサネット（Ｒ）・カードは、いくつかの現在利用可能なタイプのネットワーク・アダプタの例にすぎない。

実施形態の例に関して本発明を説明してきたが、添付の特許請求の範囲の趣旨および範囲内で改変した本発明を実施し得ることが当業者には理解されよう。

本発明によるステップを示す流れ図である。 本発明によるモデル表現を示す図である。

Claims (1)

1. 設計を検証するシステムであって、
   （ａ）１組の共通必須要素を提供する手段と、
   （ｂ）１組のキーワードとして、テスト・ケース必須リソースを指定するのに用いるハードウェア・リソースを指定する手段と、
   （ｃ）後続のシミュレーションの実行に関連するテスト・ケースまたは１組のテスト・ケースごとに前記１組のキーワードをパースする手段と、
   （ｄ）前記パースされた１組のキーワードと前記共通必須要素を組み合わせて、ＢＯＭモデル・ビルド・ファイルを生成する手段と、
   （ｅ）前記ＢＯＭビルド・ファイルを使用してスタブ・ファイルを生成する手段とを備え、
   前記スタブ・ファイルは、設計の離散的な機能を検証するためのシミュレーション・モデルのコンパイルを指示するものであって、前記シミュレーション・モデル内に実モデル表現および空モデル表現をインストールするようにモデル・ビルド・プロセスに命令し、
   前記実モデル表現は、シミュレーション中に正確に振る舞い、設計全体ではなく、検証すべき機能を表す前記テスト・ケースの仕様について合成することができ、
   前記空モデル表現は、前記設計のシミュレーションも検証もされない残りの部分を表し、かつ前記空モデル表現のすべての出力を不活動状態にアサートすることにより、前記空モデル表現が前記シミュレーション・モデル内で用いられないことを保証するためのタイ・オフを含む、システム。

Images