(57)【要約】【課題】設計検証に伴う負荷および時間の問題を解決する方法を提供する。【解決手段】方法は、既知のシーケンスに依存するテスト・ケースを作成するステップと、テスト・ケースを既知の点に到達するまで親プロセッサ上で実行するステップとを含む。本方法は、テスト・ケースを異なるプロセッサ上で実行してアクションを行い、アクションが行われたことを親プロセッサに対して通知するステップをさらに含む。アクションは、親プロセッサで検証されて、生じたものとされる。【選択図】図１
2007164781.tif 000002
【特許請求の範囲】
【請求項１】
既知のシーケンスに依存するテスト・ケースを作成するステップと、
前記テスト・ケースを既知の点に到達するまで親プロセッサ上で実行するステップと、
前記テスト・ケースを異なるプロセッサ上で実行してアクションを行うステップと、
前記アクションが行われたことを前記親プロセッサに対して通知するステップと、
前記アクションが生じたことを前記親プロセッサで検証するステップとを含む、方法。
【請求項２】
前記親プロセッサと前記異なるプロセッサとの間の前記テスト・ケースの前記実行中に取得された情報の交換のための共有メッセージ・メモリを提供するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記親プロセッサおよび前記異なるプロセッサ上で実行するＴＯＳ（テスト・オペレーティングシステム）間プロトコルをサポートするために、ＳＭＭ用の整合性のある構造を提供するステップをさらに含む、請求項２に記載の方法。
【請求項４】
前記親プロセッサと前記異なるプロセッサとの間で共有される前記テスト・ケースに対するアトミック動作中のＴＯＳ実行ファイルを通信するセマフォー機構を提供するステップをさらに含む、請求項１に記載の方法。
【請求項５】
低速および高速モード動作のうちの少なくとも１つの最中に、並列スケジュール中のコマンド・キューを前記親プロセッサおよび前記異なるプロセッサがポーリングするための機構を提供するステップをさらに含む、請求項１に記載の方法。
【請求項６】
障害回復機構を提供するステップをさらに備える、請求項１に記載の方法。
【請求項７】
前記障害回復機構は、シミュレーションが実行中に、前記親プロセッサおよび前記異なるプロセッサのうちの１つの上で実行されている前記テスト・ケースを取り消す、請求項６に記載の方法。
【請求項８】
前記障害回復機構は、
実行中のテスト・ケースの結果をチェックするように前記異なるプロセッサに対して信号で知らせるステップと、
実行中の前記テスト・ケースの結果を伴う戻り信号を待つステップと、
前記信号が所定の期間内に戻らない場合に、前記異なるプロセッサ上で実行中の前記テスト・ケースを取り消すステップと、
を含む、請求項７に記載の方法。
【請求項９】
少なくとも２つのプロセッサのうちの第１のプロセッサ上の分散されたテスト・ケースの実行から得られた共有情報をアクセスおよび取得するための信号を提供して、第１のプロセッサによって完了されたタスクが、分散されたテスト・ケースの同時実行中に、前記少なくとも２つのプロセッサのうちの第２のプロセッサに通信されるようにするステップと、
前記信号を受信すると、前記第２のプロセッサ上の前記分散されたテスト・ケースのうちのテスト・ケースを共有情報を使用して実行して、設計を検証するステップとを含み、
前記信号は、マルチプロセッサの応用における前記分散されたテスト・ケースの制御および同期を提供する、方法。
【請求項１０】
前記少なくとも２つのプロセッサは、前記分散されたテスト・ケースのうちのテスト・ケースを前記設計の検証のために同期して実行するプログラム・アプリケーションを含む、請求項９に記載の方法。
【請求項１１】
前記分散されたテスト・ケースは、前記少なくとも２つのプロセッサ上で同期して実行する、請求項９に記載の方法。
【請求項１２】
共有メモリ内のキューをポーリングするために前記少なくとも２つのプロセッサに対して信号で知らせて、前記共有情報を取得するハンドシェイク・プロトコルを提供するステップをさらに備える、請求項９に記載の方法。
【請求項１３】
キュー深度をポーリングして、前記共有情報を抽出して前記分散されたテスト・ケースを実行するためのロックを取得するステップをさらに含む、請求項９に記載の方法。
【請求項１４】
前記信号は、前記少なくとも２つのプロセッサ間のＴＯＳ間プロトコルをサポートするために、共有メモリ用の整合性のある構造を提供する、請求項９に記載の方法。
【請求項１５】
障害回復機構を提供するステップをさらに含み、前記障害回復機構は、
前記分散されたテスト・ケースの結果をチェックするように前記第２のプロセッサに対して信号で知らせるステップと、
前記信号通知に対する応答を待つステップと、
待ち時間が所定の時間より長い場合には、前記第２のプロセッサ上で実行している前記分散されたテスト・ケースを取り消すステップと、
を含む、請求項９に記載の方法。
【請求項１６】
互いに異なるプロセッサ上で実行される分散されたテスト・ケースの同時実行を可能にし、かつ前記分散されたテスト・ケースの各テストケースの状態を通信するように構成された機構と、
ハンドシェーキング・プロトコルを提供して、前記互いに異なるプロセッサの代替物上での前記テスト・ケースの結果のチェックと、前記チェックの前記結果を伴う応答とをいつ行うかについて信号で知らせるモジュールと
を含む、システム。
【請求項１７】
前記分散されたテスト・ケースのうちの前記テスト・ケースをキャンセル可能な障害回復機構をさらに備える、
請求項１６に記載のシステム。
【請求項１８】
前記テスト・ケースの結果を記憶および交換するための共有メッセージメモリをさらに備え、前記機構は、整合性を保つマルチプロセッサ検証ソフトウェアにおける複数の抽象層に渡る同期を提供する、請求項１６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、設計を試験する、または検証する、あるいはその両方を行う方法およびシステムに関し、より特定的には、シミュレーション処理を使用するクラスタ間の相互作用のシステム・オン・チップ（ＳｏＣ）の設計検証の方法およびシステムに関する。
【背景技術】
【０００２】
今日の集積回路（ＩＣ）チップは、複雑性および高性能の両面で著しく進歩してきた。例えば、初期の世代のチップ設計においては、チップは、論理ゲート間の相互接続によって有効になる比較的単純な電子論理ブロックを実施するようなものだったのに対して、より新しい世代のチップは、「コア」と呼ばれる、複雑でモジュール化されたＩＣ設計の組み合わせを有する設計を含み、共にＳｏＣ全体を構築する。これらのより新しい世代のＩＣ設計は、例えば、より小さい機能サイズを含むことができる能力を有し、それによって単一のチップ上に構築できる回路量を増加させることによって、チップ自体の全体的な機能性および性能を著しく向上させている。しかしながら、これには犠牲が伴う。つまり、設計および検証により時間がかかり、結果として、開発および生産コストがいっそうかかってしまう。
【０００３】
そのような複雑なＩＣチップを設計するためには、ＩＣチップ開発には、設計フェーズと、検証フェーズとが含まれ、後者は、実行可能性、従って、チップ自体の機能性の判断に重要である。例えば、設計が予想通り機能するかどうかの判断は、検証フェーズにおいてなされる。
【０００４】
検証フェーズは、ソフトウェアによるシミュレーション手法に移行してきており、設計を最初にハードウェアで実施するコストを回避して、そのような設計の実行可能性を検証する。しかしながら、マルチプロセッサおよびマルチコア設計は、設計全体および試験台をシミュレーション毎に構築しなければならないために、非常に大きなシミュレーション・モデルになりうる。現代のシミュレーション・ツールを使用した場合でも、シミュレーションの負荷および実行時間は、構築時間と共に、コストおよび時間が法外にかかりうる。これは、プロセッサ間クラスタの場合の複雑な設計の場合に特に当てはまる。なぜならば、設計の完全なゲート・レベルの表現を構築して、各プロセッサについてシミュレーションにロードしなくてはならないからである。
【０００５】
例証として、設計を検証する際に、シミュレータ（例えば、ＶｅｒｉｌｏｇまたはＶＨＤＬなどのハードウェア記述言語（ＨＤＬ）で記述されたソフトウェアを受け入れる機能を含む専用ソフトウェア）は、設計の応答をシミュレートするために回路設計（例えば、コア）をモデル化する。この応答は、テスト・ケースによって利用されて、設計が予想通り機能するかどうかが判断される。しかしながら、そこそこのバグのない設計を実現するには、設計を十分に検証するためには、すなわち、数多くのテスト・ケースを適用して、シミュレーションにおいて設計を完全に実施するためには、検証ソフトウェアは、設計全体を既存のツールにロードしなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
チップ設計が個別のコアおよびコア間の相互作用の両方において複雑になるにつれて、検証がさらにいっそう法外な時間および計算リソースを必要とする傾向にあるのは、設計全体に関連した機能の相互作用をモデル化および検証するからというのが主な理由である。すなわち、例えば、検証処理は、１つの機能のみ、または２つ以上の機能間の相互作用をテストするためのテスト設計全体をロードおよび実施する必要があるので、指数的に長くなる。この検証処理は、相互に作用し合うマルチプロセッサ・コアの検証についてますます複雑になる。なぜならば、互いに通信してマルチプロセッサ・コア間の相互作用を検証することができる既知の技術は存在しないからである。現在の検証手法のこのような非効率性によって、時間的な問題が悪化し、市場に出すまでの時間というビジネス競争の激しいＩＣチップの開発者および販売業者にとっては重要な要素が著しく増加する。
【課題を解決するための手段】
【０００７】
本発明の第１の局面において、方法は、既知のシーケンスに依存するテスト・ケースを作成するステップと、テスト・ケースを既知の点に到達するまで親プロセッサ上で実行するステップとを含む。本方法は、テスト・ケースを異なるプロセッサ上で実行してアクションを行い、アクションが行われたことを親プロセッサに対して通知するステップをさらに含む。アクションは、親プロセッサと共に生じている間に検証される。
【０００８】
本発明の他の局面において、本方法は、少なくとも２つのプロセッサのうちの第１のプロセッサ上に分散されたテスト・ケースの実行から得られた共有情報をアクセスおよび取得するための信号を提供して、第１のプロセッサによって完了されたタスクが、分散されたテスト・ケースの同時実行中に、当該少なくとも２つのプロセッサのうちの第２のプロセッサに通信されるようにするステップを含む。本方法は、当該信号を受信すると、第２のプロセッサ上に分散されたテスト・ケースのうちのテスト・ケースを共有情報を使用して実行して、設計を検証するステップをさらに含む。当該信号は、マルチプロセッサの応用における分散されたテスト・ケースの制御および同期を提供する。
【０００９】
本発明の他の局面において、システムは、互いに異なるプロセッサ上で実行される分散されたテスト・ケースの同時実行を可能にし、かつ分散されたテスト・ケースの各テストケースの状態を通信するように構成および適合された機構を含む。本システムは、ハンドシェーキング・プロトコルを提供して、互いに異なるプロセッサの代替物上でのテスト・ケースの結果のチェックと、チェックの結果を伴う応答とをいつ行うかについて信号で知らせるステップをさらに含む。
【００１０】
本発明のさらなる局面において、コンピュータ使用可能な媒体に含まれるコンピュータ読み出し可能なプログラムを提供する。コンピュータ読み出し可能なプログラムは、コンピュータ上で実行されると、本発明のステップを実施する。
【発明を実施するための最良の形態】
【００１１】
本発明は、改良されたシミュレーション処理を使用するマルチプロセッサ・プログラムのシステム・オン・チップ（ＳｏＣ）設計検証の方法およびシステムに関する。本発明の一実施形態において、本システムおよび方法は、マルチプロセッサ・プログラムに渡って機能の妥当性確認または検査のために、（例えば、分散されたテスト・ケースの）各テスト・ケースの各状態を通信することができる複数のプロセッサ上で同時に実行する分散されたテスト・ケースを実施する。より特定的には、本方法およびシステムは、マルチプロセッサＴＯＳ（テスト・オペレーティング・システム）アプリケーションにおける分散されたテスト・ケースの制御および同期を提供する。よって、実施形態において、本発明のシステムおよび方法は、複数のＴＯＳアプリケーション内のタスクが同期実行中に通信を行ってマルチプロセッサの設計を検証することができるようにする。
【００１２】
一実施において、テスト・アプリケーションは、以下の構成要素のうちの１つ以上を含む。
−（例えば、ＭＰ  ＴＯＳ  ＡＰＩ機能呼び出しを使用して）ＴＯＳ間プロトコルをサポートするための共有メッセージ・メモリ（ＳＭＭ）用の整合性のある構造、
−共有外部シミュレーション・モデル（例えば、ＥＭＵ，ＳＭＭおよびｔｉｍｅｂａｓｅＲ（登録商標）））に対するアトミック動作中に実行ファイル（例えば、ＴＯＳ実行ファイル）を通信するセマフォー機構、
−並列テスト・ケース・スケジュール中で低速および高速モード動作中にコマンド・キューをポーリングするための、各ＴＯＳアプリケーション用機構、または
−障害復旧機構、あるいはこれらすべてである。
これらの構造的な特徴を使用して、マルチプロセッサ・コア間の相互作用を検証することができ、これにより、実証済みの堅固な設計が得られ、市場に出すまでの時間が著しく速くなる。
【００１３】
図１は、本発明の特徴を実施するブロック図を示す。特に、図１は、参照番号１００として示された１つ以上のワークステーションを示す。１つ以上のワークステーション１００は、メモリと、１つ以上のプロセッサと、他の既知の構成要素とを含む。
【００１４】
本発明の一実施において、１つ以上のワークステーション１００は、ＴＯＳ間プロトコルをサポートするための共有メッセージ・メモリ（ＳＭＭ）２００を含む。１つ以上のワークステーション１００は、共有メモリ・ロック・テスト・アンド・セット・ハードウェア（ＳＭＭロックＴＮＳ  ＨＷ）３００と、例えば互いに異なるプロセッサ上で実行する１つ以上のプログラム・アプリケーション４００ａおよび４００ｂと、障害復旧機構５００とをさらに含む。プログラム・アプリケーション４００ａおよび４００ｂは、任意の従来のプログラム・アプリケーションであってよく、例えば、互いに異なるプロセッサ上での設計を検証するためのテスト・ケースを実行するａｕｔｏＴＯＳ（登録商標）などであってもよい。
【００１５】
一具体例において、検証すべき特定のテストを生成するために、ａｕｔｏＴＯＳ（登録商標）（またはＡＤＦ（アプリケーション定義ファイル）（ソフトウェア・リソースが指定される））を使用して、ユーザが指定したパラメータ（例えば、リソース）をコンパイルしてもよい。当業者にとっては自明のことであるが、ａｕｔｏＴＯＳ（登録商標）は、テストおよび生成処理を自動化するために使用されるコンパイラ・ツールである。一実施において、ａｕｔｏＴＯＳ（登録商標）を使用して、テンプレートを実施するテスト・ケースを生成することができることは、当業者によって理解されるとおりである。
【００１６】
さらに図１を参照して、図示の実施形態において、ＴＯＳアプリケーションは、「交互認識（ａｌｔｅｒｎａｔｅ  ａｗａｒｅ）」（または分散された）テスト・ケースを同時に別個のプロセッサ上で実行する。分散されたテスト・ケースを実施するのに、一実施において、ａｕｔｏＴＯＳによって生成されたＳＹＳＴＥＭ＿ＣＡＬＬＢＡＣＫ機能を介して、信号をＴＯＳアプリケーション間で送信することができる。ＳＹＳＴＥＭ＿ＣＡＬＬＢＡＣＫ機能を使用することによって、プログラム・アプリケーション４００ａ，４００ｂは、互いに情報をＳＭＭを介して伝送することができ、これは、ＳＭＭロックＴＮＳ  ＨＷ３００によるハンドシェイクによって開始される。このことは、後でさらに十分に説明するとおりである。
【００１７】
一例示として、ＳＭＭロックＴＮＳ  ＨＷ３００は、少なくとも２つのプロセッサ間のハンドシェイク（例えば、信号）を実施し、これは、当該少なくとも２つのプロセッサ間のＴＯＳ間プロトコルをサポートするために、ＳＭＭ用の整合性のある構造を提供する。一例において、ハンドシェイク（例えば、ハンドシェーキング・プロトコル）は、ＴＯＳアプリケーションに対して、代替ＴＯＳアプリケーションにおける結果をいつチェックし、チェック結果を伴って応答するかについて信号で知らせることができる。このように、ハンドシェイクは、読み出しおよび書き込み動作をロックまたはアンロックした状態で、ＴＯＳ間通信を開始するのに使用することができる。これにより、部分的には、テスト・ケースの同時実行および互いの相互作用が可能となる。このように、テスト・ケースの機能を、互いに異なるプロセッサ間で「分散」することができる。実施形態において、ＳＭＭロックＴＮＳ  ＨＷ３００は、あるプロセッサからロックが設定されると、システム内のすべての他のプロセッサは、当該ロックに気づいて適切に認識する。ハンドシェイクの実施は、例えば以下のものを含んでもよい。
【００１８】
【数１】
2007164781.tif 000003
（「ＲＥＡＤ＿ＭＩＯ８＿ＮＯＴＲＡＣＥ（ＫＥＲＮＥＬ＿ＴＥＳＴＮＳＥＴ＋（ＴＯＳＩＤ＊８）＋ＥＭＵＬＯＣＫ，＆ｔｅｍｐ８」は、再利用可能なＡＰＩであり、ライブラリから取得されてもよい）
【００１９】
さらに図１を参照すると、ＳＭＭ２００は、複数のプロセッサのＴＯＳアプリケーションの情報を共有するように実施されたビン・ファイルのＳＲＡＭであってもよい。実施において、ＳＭＭ２００は、共有外部シミュレーション・モデル（例えば、ＥＭＵ，ＳＭＭおよびｔｉｍｅｂａｓｅＲ（登録商標））に対するアトミック動作中のＴＯＳ実行ファイルをすべて通信するためのセマフォー機構を提供する。すなわち、実施において、ＳＭＭ２００は、読み出し／書き込み動作中に同一のデータを共有する２つのプログラム間の通信を提供する。周知のように、アトミック動作は、並列して実行するどの他のプログラムも読み出し／書き込み動作の間で実行できないように、１サイクル中の同時読み出し／書き込み動作を許可する。
【００２０】
上述のように、テスト・ケースは、既知のシーケンスに依存して作成できる。その後、互いに異なるプロセッサ上で、必要なシーケンスで、テスト・ケースを分散テスト・ケースとして実行できる。例えば、親プロセッサ上のテスト・ケースは、既知の点に到達するまで実行できる。その後、テスト・ケースは、異なるプロセッサにおいて実行されてアクションを行うことができ、親プロセッサから取得した情報を取る。親プロセッサは、アクションが取られ他を事に気づいて、そのようなアクションが取られたことを検証してもよい。
【００２１】
図２は、本発明の模式例を示し、本発明のステップを示すフロー図をも同様に表すことになろう。図２において、本発明に係るＳＭＭ２００およびＳＭＭロックＴＮＳ  ＨＷ３００を使用して互いに通信する２つのプログラム・アプリケーション、例えばＴＯＳ‐０  ４００ａおよびＴＯＳ‐１  ４００ｂが示されている。２つ以上のＴＯＳアプリケーション（または他の既知の認証アプリケーション）が本発明と共に本明細書に記載されたやり方で実施されてもよいことが、当業者によって理解されるべきである。
【００２２】
具体的な一実施形態において、ＳＭＭロックＴＮＳ  ＨＷ３００は、ＴＯＳ間プロトコルをサポートするためのＳＭＭ用の整合性のある構造を提供するハンドシェイクを実施する。例えば、ハンドシェイクは、読み出しおよび書き込み動作をロックおよびアンロックしながら、ＴＯＳ‐０  ４００ａがＴＯＳ‐１  ４００ｂと通信できることを知らせるプロトコルを提供する。
【００２３】
図２の実施において、ＳＭＭ２００は、ＴＯＳアプリケーション４００ａ，４００ｂ間で共有すべきＴＯＳ情報のためのキューを提供する。キューは、本発明に従って照会することができる。
【００２４】
図２の例において、ＴＯＳ‐０  ４００ａは、ＳＭＭ２００に対するロックを取得し、ＴＯＳ‐０テスト・ケースにおいて取得された情報またはその一部は、ＳＭＭ２００のキューに転送および記憶される。ＳＭＭロックは開放され、ＴＯＳ‐０  ４００ａは、ＳＭＭ２００のキュー深度をポーリングする。その後、ハンドシェイクは、ＴＯＳ‐１  ４００ｂに対して、今やＴＯＳ‐０アプリケーションから取得された情報を実行しながら実施可能なそのテスト・ケース・プログラム（異なるプロセッサ上で実行していてもよい）を実施するように信号で知らせる。ＴＯＳ‐１  ４００ｂは、キュー深度をポーリングして、ロックを取得する。ＴＯＳ‐１  ４００ｂは、メッセージを抽出し、ＳＭＭロックを開放して、メッセージを実行する。メッセージには、テスト・ケースをＴＯＳ‐１上で実行しながら使用される情報を含む。
【００２５】
さらなるステップとして、ＴＯＳ‐０  ４００ａは、ロックを取得して、キューから応答を抽出して、ロックを開放し、これでＴＯＳ‐１がロックを取得することができる（例えば、ハンドシェイクからの指示の下で）。ＴＯＳ‐１  ４００ｂは、そのプログラム・アプリケーションを実行する際に応答をキューに記憶して参照してもよい。ＳＭＭのロックは、その後開放されてもよい。このように、ＴＯＳ‐０およびＴＯＳ‐１のテスト・ケースは同時に実行でき（例えば、分散されて）、マルチプロセッサ（ＭＰ）プログラムの妥当性を確認または検証するために、各状態を通信することができる。
【００２６】
図２の例を使用して、各ＴＯＳアプリケーションが並列テスト・ケース・スケジュール中にコマンド・キューをポーリングする機構を、低速および高速モード動作中に実施することができる。例えば、一実施において、
高速モード：  テスト・ケースをデバッグ、および
低速モード：  複数のテスト・ケースを実行して、実行している１つのシミュレーションに対して検証を行うために、大量のテスト・ケースを検証する。
【００２７】
図３は、障害回復機構を表すブロック図であって、同じく、本発明のステップをも同様に示すフロー図を表すことになろう。障害回復機構は、１つ以上のワークステーション１００上に常駐してもよく、シミュレーションが実行中にＴＯＳアプリケーション上で実行されているテスト・ケースを取り消すように設計されている。例えば、図３の例において、ＴＯＳ‐０またはＴＯＳ‐１もしくはその両方の上の分散アプリケーションが、障害回復機構を使用して取り消されてもよい。
【００２８】
実施において、障害回復機構は、分散されたテスト・ケースの互いに異なるテスト・ケースを実行しているＴＯＳアプリケーション間で信号を提供する。一例として、ＴＯＳ‐０は、本発明に従ってＴＯＳ‐０およびＴＯＳ‐１上で同時に実行する、ハードウェア上のテストを開始してもよい。ＴＯＳ‐０は、自己宇宙のテストの結果をチェックするように、代替ＴＯＳであるＴＯＳ‐１に対して信号で知らせる。一方、ＴＯＳ‐１は、結果をチェックするための信号を待つ。ＴＯＳ‐１は、ハードウェア結果をチェックして、応答をＴＯＳ‐０に対して信号で知らせて戻す。ＴＯＳ‐０は結果を待って、結果が所定の期間内に提供されない場合には、ＴＯＳ‐１は、ＴＯＳ‐１上で実行している代替テスト・ケースを取り消すように信号を送る。この「取り消し（ｃａｎｃｅｌ）」または「停止（ｋｉｌｌ）」動作は、例えばＭＰＴＯＳ＿ＣＡＮ＿ＡＬＴＥＲＮＡＴＥ  ＡＰＩを使用して、ＭＰ  ＴＯＳによって実施されてもよい。
【００２９】
図４は、本発明のシステムおよび方法を実施する一実施形態を示す。図４において、例えば図２および図３の模式例に示すようなテスト・ケースおよび障害回復を実行する前に、以下のステップを実行してもよい。
‐ＴＯＳ  ＣＰＵ／カーネルを初期化
‐チップ初期化を開始
‐〜バスを初期化
‐ＴｅｓｔｎＳｅｔ論理を有効化
‐ＴＯＳ‐ｎを解除
‐ＭＰＴＯＳ＿ＩＮＩＴを子に発行（ＴＯＳ‐０の場合）
‐チップ初期化を完了
‐ＭＰＴＯＳ＿ＡＬＬＧＯを子に発行
当然ながら、これらのステップは、ハンドシェイク・プロトコルを使用して、ＴＯＳ‐１アプリケーションと同期してもよい。
【００３０】
図４において、ＴＯＳ‐１（子）は、例えば図２および図３の模式例に示すようなテスト・ケースおよび障害回復を実行する前に、以下のステップを行う。
‐ＣＰＵ／カーネルを初期化
‐親からのＭＰＴＯＳ＿ＩＮＩＴを待つ
‐チップ初期化を実行
‐ＭＰＴＯＳ＿ＩＮＩＴ＿ＣＯＭＰＬＥＴＥを親へ発行
‐親からのＭＰＴＯＳ＿ＡＬＬＧＯを待つ
‐テストケース・スケジュールを実行
当然ながら、これらのステップは、ハンドシェイク・プロトコルを使用して、ＴＯＳ‐０アプリケーションと同期してもよい。
【００３１】
さらに図４を参照すると、ＴＯＳ‐０およびＴＯＳ‐１を初期化すると、テスト・ケースを本発明の上述の記載に従って同時に実行することが可能である。また、上述のように、障害回復機構も実行されてもよい。一例において、障害回復は、テスト・ケースを実行している子（または複数の子）と通信を行うＴＯＳ‐０上に実施された以下の疑似コードを含んでもよい。
‐テスト完了、ＡＬＬＳＴＯＰ
‐ＭＰ＿ＡＬＬＳＴＯＰを子に発行
子  ‐からのＭＰＴＯＳ＿ＴＥＲＭＩＮＡＴＥＤを待つ
‐ＳＩＭ＿ＣＴＬを発行、シミュレータを停止
‐中断
本例において、障害回復は、ＴＯＳ‐０と通信を行うＴＯＳ‐１（任意の子）上に実施された以下の疑似コードを含んでもよい。
‐テスト完了、ＡＬＬＳＴＯＰ
‐親からのＭＰ＿ＡＬＬＳＴＯＰを待つ
‐ＭＰＴＯＳ＿ＴＥＲＭＩＮＡＴＥＤを親へ発行
‐中断
【００３２】
上述のように、本発明のシステムおよび方法は、プロセッサ間メッセージ・プロトコルとハンドシェイク・プロトコルと使用することによって、複数処理検証のためのマルチプロセッサＴＯＳアプリケーションにおいて、分散されたテスト・ケースを（たとえば、複数の抽象層に渡って）制御および同期する。よって、本発明のシステムおよび方法を実施することによって、１つのＴＯＳ（または他の）アプリケーション内のタスクは、（ＭＵＴＥＸ構造およびメモリ割り当てを使用して）同一のＨＷリソースを共有している場合に、（機能呼び出しおよび呼び戻し機能を使用して）符号化層に渡って同期的および非同期的に通信できる。これにより、整合性を確保しながら、検証すべきマルチプロセッサＳｏＣ設計において同時に実行している複数のＴＯＳ検証アプリケーション間のタスク間通信を提供することができる。
【００３３】
本明細書において説明したような方法を、集積回路チップの製造に使用する。結果生じた集積回路チップは、未処理のウエハ形状で（すなわち、複数のパッケージ化されていないチップを有する単一のウェハとして）、むき出しの型として、またはパッケージ化された形式で、製造者によって配布されることができる。後者の場合、チップは、単一のチップ・パッケージ内（導線がマザーボードに固定されたプラスチックの担体、または他の高レベル担体など）、またはマルチチップ・パッケージ内（片面または両面相互接続または埋め込み相互接続を有するセラミックの担体）に搭載されている。いずれの場合も、その後、チップは、（ａ）マザーボードのような中間製品または（ｂ）最終製品の何れかの一部として、他のチップ、ディスクリートな回路要素、または他の信号処理装置あるいはそのすべてと一体化される。最終製品は、玩具およびその他の低価格帯の応用品から、ディスプレイ、キーボード、または他の入力装置と、中央プロセッサとを有する高性能のコンピュータ製品まで、集積回路チップを含むどのような製品であってもよい。
【００３４】
本発明は、完全にハードウェアによる実施形態、完全にソフトウェアによる実施形態、またはハードウェアおよびソフトウェア要素を共に含む実施形態の形式を取ることができる。好ましい一実施形態において、本発明は、ソフトウェアで実施され、ソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されるものではない。さらに、本発明は、コンピュータまたは任意の命令実行システムによる、またはそれに関して使用されるプログラム・コードを提供するコンピュータが使用可能なまたはコンピュータが読み出し可能な媒体からアクセス可能なコンピュータ・プログラムの形式を取ってもよい。この説明の目的のために、コンピュータが使用可能なまたはコンピュータが読み出し可能な媒体は、任意の命令実行システム、装置、またはデバイスによる、またはそれに関して使用されるプログラムを包含、記憶、通信、伝搬、または搬送可能な任意の装置であってもよい。
【００３５】
当該媒体は、電子、磁気、光学、電磁気、赤外線、または半導体システム（または装置またはデバイス）または伝搬媒体であってもよい。コンピュータが読み出し可能な媒体の例には、半導体、ソリッド・ステート・メモリ、磁気テープ、着脱可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクが含まれる。光ディスクの現在の例には、コンパクト・ディスク‐読み出し専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク‐読み出し／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが含まれる。
【００３６】
プログラム・コードを記憶または実行およびその両方を行うのに適したデータ処理システムには、システム・バスを通じてメモリ要素と直接的または間接的に結合された少なくとも１つのプロセッサが含まれる。メモリ要素は、プログラム・コードを実際に実行中に使用されるローカル・メモリ、大容量ストレージ、および、実行中に大容量ストレージからコードを取り出す回数を減らすために少なくともいくつかのプログラムコードの一時的な記憶を提供するキャッシュ・メモリを含みうる。
【００３７】
入力／出力またはＩ／Ｏ装置（キーボード、ディスプレイ、ポインティング・デバイスなどを含むが、これらに限定されない）を、システムに直接または介在Ｉ／Ｏコントローラを通じて結合することができる。また、ネットワーク・アダプタをシステムに接続して、データ処理装置を他のデータ処理装置、遠隔プリンタ、または記憶装置に介在私設または公設ネットワークを通じて結合できるようにしてもよい。モデム、ケーブル・モデム、およびイーサネット(R)・カードは、現在利用可能なネットワーク・アダプタの種類のほんの一部である。
【００３８】
本発明を実施形態例の観点から説明してきたが、本発明は、変形を加えて、添付の請求項の精神および範囲内において実施されうることを当業者は認識するだろう。
【図面の簡単な説明】
【００３９】
【図１】本発明の一実施の形態を説明するブロック図である。
【図２】本発明の模式例を示し、本発明のステップを示すフロー図をも同様に表す図である。
【図３】障害回復機構を表すブロック図であって、同じく、本発明のステップをも同様に示すフロー図である。
【図４】本発明のシステムおよび方法を実施する模式例を表すブロック図である。
【符号の説明】
【００４０】
１００  ワークステーション
２００  ＳＭＭ
３００  ＳＭＭロックＴＮＳ  ＨＷ
４００ａ，４００ｂ  プログラム・アプリケーション
【図１】
2007164781.tif 000004
【図２】
2007164781.tif 000005
【図３】
2007164781.tif 000006
【図４】
2007164781.tif 000007