JP4888272B2 - ソフトウェアのシミュレーション方法、ソフトウェアのシミュレーションのためのプログラム、及びソフトウェアのシミュレーション装置 - Google Patents

Description

本発明は、一般に計算機利用設計に関し、詳しくはシステムＬＳＩで実行するプログラムで発生するデッドロック等の問題抽出に関する。

シングルプロセッサ又はマルチプロセッサのシステムで動作する並列プログラムを開発する場合、データレース及びデッドロックの発生を的確に抽出する必要がある。抽出されたデータレース及びデッドロックに基づいて、ソフトウェア開発者が、発生原因をなくすようにプログラムを修正する。

データレースとは、排他制御が正しく行われないことに起因して１つの変数に対する多重アクセスの結果として生じるエラーである。プログラムの実行中に、あるスレッドがアドレス指定可能なメモリ位置をアクセスしているのと同時に、別のスレッドがそのメモリ位置の内容を変更する場合、プログラムにはデータレースが存在する。

デッドロックとは、例えば２つのスレッドが、互いに相手が必要としているリソースのロックを占有し、リソースの解放を待つ状態となり、何れのスレッドもリソースを解放しない結果、処理が進まなくなるというエラーである。より具体的には、複数のプロセスが起動している状態で、プロセスＡがレコードｃを排他的に使用しており、別なプロセスBが別のレコードｅを排他的に使用しているとする。この時プロセスＡが、プロセスＢの使用しているレコードｅを使用したいとすると、このレコードｅが解放されるまで待ち状態となる。この時プロセスＢが、同様にプロセスＡの使用しているレコードｃを使用したいとすると、このレコードｃが解放されるまで待ち状態となってしまう。即ち、プロセスＡとプロセスＢとが待ち状態になりプロセスの進行が停止してしまう。

上記説明では、単純化のために２つのプロセス間での競合としてデータレースとデッドロックについて説明したが、実際の処理では、複数のプロセス間でデータレースやデッドロックが発生する場合もある。プロセスの数に限らずデータレースやデッドロックの現象は、システム動作の障害となる場合が多く、システムのパフォーマンスの大幅な低下を引き起こしてしまう。

データレース及びデッドロックを抽出するために、システムＬＳＩの実機を使用してソフトウェアを実行し、そのソフトウェアのデバッグを行うことが考えられる。この場合、システムＬＳＩの実機にデバッグ機能を組み込むことにより、プログラム中に設定したブレークポイントでプログラムの実行を停止させ、その時点でのレジスタスタックの内容、グローバルデータの値、プログラムの呼び出しスタックの内容等をチェックできるように構成する。またデバッグ対象がマルチスレッドの場合、あるスレッドがブレークポイントに達して実行を停止した時点で、他のスレッドの実行を停止するように構成することが望ましい。このようなデバッグ機能をＬＳＩに組み込むことは、ＬＳＩが大規模で複雑なシステムの場合は比較的容易である。しかし民生機器等の電子機器の組み込みＬＳＩの場合、元々の構成が比較的単純であり、複雑なデバッグ機能を搭載することはコスト増に繋がるために望ましくない。

ＳｏＣ（System On a Chip）等のシステムＬＳＩを設計・製造する工程について考えると、まず最初に、ＬＳＩのアーキテクチャ設計及び仕様設計を行う。その後ＲＴＬ設計を行い、ＲＴＬ記述に基づいてレイアウト設計し、工場でＬＳＩを製造する。そして製造したＬＳＩにてソフトウェアを実行して、ソフトウェアの動作確認を行う。

このようなＬＳＩの設計・製造工程においては、最初にアーキテクチャ設計及び仕様設計を終了した時点で、システムＬＳＩの仮想的なソフトウェアのモデルを作成することができる。従って、ソフトウェアのモデルをソフトウェアデバッガに接続し、ソフトウェアのモデル上で開発対象のソフトウェアの実行をシミュレートすれば、ソフト開発者がソフトウェアの開発・検証を行うことができる。このようにアーキテクチャ設計及び仕様設計という最初の工程を終了した後に直ちにソフトウェアの設計・検証を開始すれば、ソフトウェア設計にかかる莫大な時間をＬＳＩ設計・製造工程の中に隠すことができる。

ソフトウェアデバッガを用いてソフトウェアの検証をする場合、通常、トレースポイントをプログラム中に埋め込まなければならない。またプログラム中にプリント文等を埋め込んでデバッグ目的のために使用したりする。しかしこのようにプログラムに細工をすると、デバッグ対象のプログラムと実際の実行用のプログラムとで環境や動作条件が異なってしまい、何をデバッグ対象としているのかが明確でなくなる。即ち、デバッグ用に生成された実行可能オブジェクトと製品レベルの最適化コンパイルで生成された実行可能オブジェクトとでは、実行条件が異なってしまうので、実際のプログラムの実際の動作のデバッグをしていることにならない。
特開平９−１０１９４５号公報 特開２００２−２９７４１４号公報

以上を鑑みて、本発明は、ＬＳＩのソフトウェアモデル上でプログラムの実行をシミュレートする際に、プログラムにデバッグ用の細工をすることなく、データレース及びデッドロック等を抽出可能なシミュレーション方法及びシミュレータを提供することを目的とする。

コンピュータによるソフトウェアのシミュレーション方法は、ソフトウェアによるシミュレータ上にソフトウェアとして実現したハードウェアのモデルにより複数のスレッドからなるプログラムを実行し、該シミュレータのモニタ機能により該ハードウェアのモデル内のリソースに対する該複数のスレッドによるアクセスをモニタしてアクセスに関する情報を収集し、該モニタ機能により、該収集された情報から複数のスレッドによる同一のリソース領域に対する重複するアクセスを抽出し、該モニタ機能により、該重複するアクセスを警告するメッセージを生成する各段階を含むことを特徴とする。

ソフトウェアのシミュレーションのためのプログラムは、ソフトウェアによるシミュレータ上にソフトウェアとして実現したハードウェアのモデルにより複数のスレッドからなるプログラムを実行し、該シミュレータのモニタ機能により該ハードウェアのモデル内のリソースに対する該複数のスレッドによるアクセスをモニタしてアクセスに関する情報を収集し、該モニタ機能により、該収集された情報から複数のスレッドによる同一のリソース領域に対する重複するアクセスを抽出し、該モニタ機能により、該重複するアクセスを警告するメッセージを生成する各段階をコンピュータに実行させる指令から構成される。

ソフトウェアのシミュレーション装置は、ソフトウェアとして実現したハードウェアのモデルを含むシミュレータプログラムと該ハードウェアのシステムでの実行を想定した複数のスレッドからなるプログラムとを格納するメモリと、該メモリに格納された該シミュレータプログラムを実行することにより該メモリに格納された該複数のスレッドからなるプログラムを該ハードウェアのモデル上で実行する演算処理ユニットを含み、該演算処理ユニットは、該シミュレータのモニタ機能により該ハードウェアのモデル内のリソースに対する該複数のスレッドによるアクセスをモニタしてアクセスに関する情報を収集し、該モニタ機能により、該収集された情報から複数のスレッドによる同一のリソース領域に対する重複するアクセスを抽出し、該モニタ機能により、該重複するアクセスを警告するメッセージを生成する各段階を実行することを特徴とする。

本発明の少なくとも１つの実施例によれば、ソフトウェアとして実現したハードウェアのモデルを含むシミュレータプログラムに、ハードウェアのモデルとは別のモニタ機能として、同一リソースに対する重複するアクセスを抽出する機能を設ける。これにより、ＬＳＩのソフトウェアモデル上でプログラムの実行をシミュレートする際に、プログラムにデバッグ用の細工をすることなく、データレース及びデッドロック等を抽出可能なシミュレーション方法及びシミュレータを提供することができる。

以下に、本発明の実施例を添付の図面を用いて詳細に説明する。

図1は、本発明によるＳｏＣシミュレータを使用する構成の一例を示す図である。図１の構成は、ソフトウェアデバッガ１０及びＳｏＣシミュレータ１１を含む。ＳｏＣシミュレータ１１は、ＡＰＩ（Application Program Interface）を介してソフトウェアデバッガ１０に結合され、ＳｏＣモデル１２、メモリモニタ１３、キャッシュモニタ１４、及びＳＷ／ＨＷ（ソフトウェア／ハードウェア）モニタ１５を含む。ＳｏＣモデル１２は、システムＬＳＩをソフトウェアでモデル化したものであり、ソフトウェアで実現された1つ又は複数のＣＰＵ２１、周辺ブロック２２、ＤＲＡＭ２３、メモリ２４、及びバス２５を含む。ソフトウェアデバッガ１０及びＳｏＣシミュレータ１１は、コンピュータ上で実行されている。

ＳｏＣモデル１２のシステムＬＳＩで実行するプログラムのソースコード１７を作成し、このソースコード１７をコンピュータでコンパイルすることにより、実行可能コード１８を生成する。ソフトウェアデバッガ１０は、ソースコード１７と実行可能コード１８とを参照しながら、ソースコード１７のプログラムをデバッグする。実行可能コード１８は、ＳｏＣモデル１２のメモリ２４に格納され、ＳｏＣモデル１２のＣＰＵ２１により実行される。即ち、システムＬＳＩの実際のＣＰＵによるプログラムの実行を、ソフトウェアとして実現されたＳｏＣモデル１２のＣＰＵ２１によりシミュレートする。

ＳｏＣモデル１２は、複数のスレッドを並行して実行するが、シングルプロセッサでマルチスレッド実行の構成、マルチプロセッサで各ＣＰＵ毎に１スレッド実行の構成、マルチプロセッサで各ＣＰＵ毎に複数スレッドの構成の何れの構成であってもよい。１つのシステムＬＳＩでは複数のプログラムが実行されるので、ソースコード１７及び実行可能コード１８はそれぞれ複数個あってよい。なお１つのプログラムが複数のスレッドを生成してよいし、１つのプログラム自身も１つのスレッドとして考えてよい。

図１に示すＳｏＣシミュレータ１１は、ＳｏＣモデル１２によりプログラムの実行をシミュレートすると共に、ＳｏＣモデル１２とは別に設けたモニタ機能を含んでおり、このモニタ機能によりデータレースやデッドロック等を検出する。具体的には、メモリモニタ１３、キャッシュモニタ１４、及びＳＷ／ＨＷモニタ１５がＳｏＣモデル１２からプログラム実行に関する種々の情報を収集し、更に収集された情報をＳＷ／ＨＷモニタ１５で纏めて整理することにより、データレースやデッドロック等を検出する。

まずソフトウェアデバッガ１０から、ＳｏＣモデル１２が実行する１つ又は複数のプログラム（実行可能コード１８）に関する情報を、ＳＷ／ＨＷモニタ１５に通知しておく。このプログラム情報は、複数のプログラムを区別するために一意に割り当てられたプログラムＩＤ、スレッド生成関数のアドレス（呼び出しアドレス）、スレッド同期のアドレス（呼び出しアドレス）、排他制御（ロック）関数のアドレス（呼び出しアドレス）、排他制御（アンロック）関数のアドレス（呼び出しアドレス）、及び各スレッドにセットされたプライオリティ（スレッド実行時の優先順位）を含む。

１つのスレッドから複数のスレッドを生成してよい。あるスレッドが、何れのスレッドから生成されたスレッドであるかを把握するために、上記のスレッド間の関係を階層化したデータ構造を用いてスレッド間の関係を管理する。階層化するために、プログラム情報にスレッドＩＤ（プログラムＩＤ）の継承の情報を含めてよい。

図２は、スレッド間の関係を示す階層化データ情報の一例を示す図である。プログラムの実行に伴い、図２に示すように、スレッドが順次生成されていく。図２の例ではプログラムＡ２８−１とプログラムＢ２８−２とが実行されている。プログラムＡ２８−１は第１のスレッド２９−１及び第２のスレッド２９−２を生成し、第１のスレッド２９−１から更に第３のスレッド２９−３及び第４のスレッド２９−４が生成されている。またプログラムＢ２８−２は第１のスレッド２９−５及び第２のスレッド２９−６を生成し、第１のスレッド２９−５から更に第３のスレッド２９−７及び第４のスレッド２９−８が生成されている。各スレッドは固有のスレッドＩＤで特定され、プライオリティ及びアクティブフラグが関連づけられている。アクティブフラグは、当該スレッドが排他状態であるか否かを示す。

ＳＷ／ＨＷモニタ１５は、ソフトウェアデバッガ１０から上記プログラム情報を受け取ると共に、ＳｏＣモデル１２のＣＰＵ２１から、ＣＰＵのＩＤ、プログラムカウンタ（ＰＣ）の値、及び命令サイクルのサイクル番号Ｃｙｃｌｅを受け取る。なおＰＣ値はソフトウェア上での位置を意味し、ＣｙｃｌｅはＳｏＣシミュレータ１１で実行した時間を意味する。

メモリモニタ１３は、ＳＷ／ＨＷモニタ１５にメモリアクセスに関する情報を提供するために、ＣＰＵ２１によるプログラム実行によりメモリ２４に対して発生した各メモリアクセスについての情報を収集する。収集する情報は、アクセス元のＣＰＵ２１のＩＤ、ＰＣの値、アクセスアドレス、アクセスサイズ、Ｒｅａｄ／Ｗｒｉｔｅの種別、及びアクセスの発生したＣｙｃｌｅ（アクセスの発生した時のＳｏＣシミュレータ１１の実行サイクルス数）である。また同様にキャッシュモニタ１４は、ＳＷ／ＨＷモニタ１５にキャッシュアクセスに関する情報を提供するために、ＣＰＵ２１によるプログラム実行によりキャッシュに対して発生した各アクセスについての情報を収集する。収集する情報は、アクセス元のＣＰＵ２１のＩＤ、ＰＣの値、アクセスアドレス、アクセスサイズ、Ｒｅａｄ／Ｗｒｉｔｅの種別、及びアクセスの発生したＣｙｃｌｅである。

メモリモニタ１３は、収集した情報に基づいて、多重アクセスを示す多重アクセス情報を生成する。この収集した情報には、メモリマップ３０における斜線として図３（Ａ）に示されるように、各ＣＰＵがアクセスした領域が記録されている。即ち、収集した情報中のアクセスアドレス及びアクセスサイズが、各ＣＰＵのアクセスした領域を示している。メモリモニタ１３は、各ＣＰＵによりアクセスされた領域を比較して重複領域を抽出することにより、図３（Ｂ）に示すように多重アクセスされた領域を特定する。また多重アクセスしたＣＰＵのＣＰＵ＿ＩＤを特定する。

図４は、メモリモニタ１３により生成された多重アクセス情報のデータ構造を示す図である。図４に示されるように、メモリモニタ１３が生成した多重アクセスデータは、１つのＣＰＵ＿ＩＤ３１に対して、このＣＰＵ＿ＩＤ３１を有するＣＰＵが実行した各アクセスの情報３２−１乃至３２−ｎが対応付けられている。アクセスの情報３２−１乃至３２−ｎの各々は、アクセスアドレス、アクセスサイズ、Ｒｅａｄ／Ｗｒｉｔｅの種別、ＰＣ、及びＣｙｃｌｅを含む。また各アクセスの情報３２−１乃至３２−ｎに対して、当該アクセスによりアクセスされた領域に重複してアクセスした他のＣＰＵのＣＰＵ＿ＩＤ３３−１乃至３３−ｎが対応付けられている。図４には１つのＣＰＵ＿ＩＤ３１に対するデータ構造のみが示されるが、図示するようなデータ構造が、複数のＣＰＵ＿ＩＤ３１に対して生成される。このようにして生成された多重アクセスデータは、メモリモニタ１３からＳＷ／ＨＷモニタ１５に供給される。

同様にキャッシュモニタ１４は、収集した情報に基づいて、キャッシュに対する多重アクセスをモニタ可能なアクセス情報を生成する。このアクセス情報の構造は、図４に示すデータ構造と同様である。キャッシュモニタ１４は、生成したアクセス情報をＳＷ／ＨＷモニタ１５に供給する。

図５は、図１の構成によりプログラムのデータレース及びデッドロック等を抽出する処理の全体の流れを示す図である。

まずステップＳ１においてソフトウェアデバッガ１０（図１参照）が動作を開始する。ステップＳ２において、ソフトウェアデバッガ１０がソースコード１７をコンパイルして実行可能コード（ロードモジュール）１８を生成する。

ステップＳ３においてソフトウェアデバッガ１０がＳｏＣシミュレータ１１（図１参照）を呼び出して起動する。ＳｏＣシミュレータ１１が起動されると（ステップＳ４）、ＳｏＣシミュレータ１１のＳＷ／ＨＷモニタ１５が、ソフトウェアデバッガ１０から送られるプログラム情報（ソースコード１７及び実行可能コード１８に関する情報）から必要な情報を抽出し（ステップＳ５）、プログラムの動作を監視するためのプログラム管理データ４０を生成する（ステップＳ６）。

ステップＳ７において、ＳｏＣシミュレータ１１のＳｏＣモデル１２のメモリ２４に実行可能コード（ロードモジュール）１８をロードする。ステップＳ８において、ソフトウェアデバッガ１０によりソフトウェア開発者がデバッグ作業を開始する。

ステップＳ９で、ＳｏＣシミュレータ１１がＳｏＣモデル１２によりシミュレーションを実行する。即ち、メモリ２４にロードされた実行可能コード１８をＣＰＵ２１により実行することにより、ソフトウェアとして実現されたＳｏＣモデル１２によるプログラム実行をシミュレートする。

ステップＳ１０において、各ＣＰＵ２１がプログラムを実行し、メモリ２４に対して適宜アクセスが実行される。メモリ２４に対してアクセスが実行されると、ステップＳ１１においてメモリモニタ１３がデータを収集する。ここで収集する情報は、前述のように、アクセス元のＣＰＵ２１のＩＤ、ＰＣの値、アクセスアドレス、アクセスサイズ、Ｒｅａｄ／Ｗｒｉｔｅの種別、及びＣｙｃｌｅである。またキャッシュアクセスに対しても同様の情報が収集される。

各ＣＰＵ２１がプログラムを実行していくにつれ、メモリアクセス、キャッシュアクセス、スレッド生成、スレッド消滅等のイベントが発生すると、それに応じてプログラム管理データ４０にデータを追加したり削除したりすることで、プログラム管理データ４０を適宜更新していく（ステップＳ１２）。これにより、図２に一例として示したようなデータがプログラム管理データ４０として生成・更新されていく。

ステップＳ１３で、シミュレーションによるプログラム実行の所定の期間（例えばＣｙｃｌｅが０から９９の期間）について、プログラム管理データ４０を参照することにより、多重アクセスによるデータレース及びデッドロック等を抽出する処理を実行する。ステップＳ１４で、抽出されたデータレース及びデッドロック等を警告するメッセージをソフトウェアデバッガ１０側（ソフトウェア開発者側）に送信する。この警告には、問題として検出されたのがデータレースであるのか又はデッドロックであるのか等の問題の種別を特定する情報、及び問題となっているアクセス先を特定する情報を含んでよい。ステップＳ１５で、ソフトウェアのデバッグを終了する。

以下に、図５の各ステップについて詳細に説明する。

図６は、図５のステップＳ５及びステップＳ６における処理を説明するための図である。前述のように、ＳＷ／ＨＷモニタ１５は、ソフトウェアデバッガ１０からＳｏＣモデル１２が実行する１つ又は複数のプログラムに関する情報を受け取る。この受け取る情報が図６においてプログラム情報４１として示されており、複数のプログラムを区別するために一意に割り当てられたプログラムＩＤ、スレッド生成関数のアドレス（呼び出しアドレス）、スレッド同期のアドレス（呼び出しアドレス）、排他制御（ロック）関数のアドレス（呼び出しアドレス）、排他制御（アンロック）関数のアドレス（呼び出しアドレス）、及び各スレッドにセットされたプライオリティ（スレッド実行時の優先順位）を含む。

ＳＷ／ＨＷモニタ１５は、プログラム情報４１に基づいて各プログラムの静的なスレッド情報を生成する。この処理が、図５のステップＳ５及びステップＳ６に相当する。この処理によりＳＷ／ＨＷモニタ１５が、プログラム管理データ４０を生成する。このプログラム管理データ４０は、図示されるように、プログラムＩＤ毎にロック開始アドレス、アンロックアドレス、スレッド生成アドレス、スレッド消滅アドレス、スレッド同期アドレス、及びプライオリティを設定したデータである。

図７は、図５のステップＳ９及びステップＳ１０における処理を説明するための図である。ステップＳ９で、ＳｏＣシミュレータ１１がＳｏＣモデル１２によりシミュレーションを実行すると、ステップＳ１０において、各ＣＰＵ２１（図７に示すＣＰＵ０乃至ＣＰＵＮ）がプログラムを実行する。ＣＰＵ０によるプログラム実行動作が、ステップＳ１０−１として例示されている。他のＣＰＵ２乃至ＣＰＵＮについても同様にプログラム実行動作が行われる。

ＣＰＵ０によるプログラム実行動作であるステップＳ１０−１においては、まずステップＳ５０で命令がフェッチされる。即ち実行対象のプログラムの命令がメモリ２４からＣＰＵ０にフェッチされる。次にステップＳ５１でフェッチされた命令がデコードされ、ステップＳ５２でデコード結果に基づいて命令が実行される。

ステップＳ５３で、実行した命令によりメモリアクセスが行われるか否かが判定される。メモリアクセス有りの場合には、ステップＳ５４でアクセス処理が実行される。このアクセス処理においては、ＣＰＵ０のプログラムカウンタＰＣの値を使用する。メモリアクセス無しの場合には、ステップＳ５５に進む。またステップＳ５４でのアクセス処理の終了後もステップＳ５５に進む。ステップＳ５５で割込み処理を実行する。その後、図７のステップＳ１０に示される処理ループに戻り、ＣＰＵ０によりプログラムの各命令が順次実行されていく。なお上記のステップＳ５４のアクセス処理が、図５のステップＳ１１におけるメモリモニタ１３によるデータ収集処理（及びキャッシュモニタ１４によるデータ収集処理）に対応する。

図８は、メモリモニタ１３によるデータ収集処理を説明するための図である。前述のように、メモリモニタ１３は、ＣＰＵ２１によるプログラム実行によりメモリ２４に対して発生した各メモリアクセスについての情報を収集する。収集する情報は、アクセス元のＣＰＵ２１のＩＤ、ＰＣの値、アクセスアドレス、アクセスサイズ、Ｒｅａｄ／Ｗｒｉｔｅの種別、及びＣｙｃｌｅである。図８において、１回のメモリアクセスについての情報がアクセスデータ４２として示される。この１回のメモリアクセスについてのアクセスデータ４２を、過去の複数回のメモリアクセスについてのアクセスデータを蓄積した蓄積データ４３に順次加えていく。この蓄積データ４３に対して、図３で説明したようなデータ比較処理をメモリモニタ１３が実行することにより、処理後のデータ４４が得られる。ここでいう処理後のデータ４４とは、図４に示される多重アクセスデータのことである。

図９は、データ比較処理を説明するための図である。図９に示されるように、蓄積データ４３に記録されたアクセスの開始アドレス及びサイズを各アクセス間で比較する（ステップＳ１）。これにより多重アクセスが有るか否かを判定する（ステップＳ２）。多重アクセス有りと判定されたアクセスに対して、多重アクセスしたプログラムＩＤを付加する（ステップＳ３）。これにより、図９に示されるように多重アクセスデータ４４が得られる。

なお上記のメモリモニタ１３による処理と同様の処理がキャッシュモニタ１４によりキャッシュアクセスに対しても実行される。即ち、図８に示すメモリモニタ１３によるデータ収集処理と同様のデータ収集処理がキャッシュモニタ１４により実行され、図９に示すメモリモニタ１３によるデータ比較処理と同様のデータ比較処理がキャッシュモニタ１４により実行される。

図９に示す多重アクセスデータ４４では、プログラムＩＤ４５に対して、このプログラムＩＤに対応するプログラムが実行したアクセスに関するアクセス情報４６が対応付けられ、更にこのアクセスのアクセス領域に重複アクセスした他のプログラムのプログラムＩＤ４７が、アクセス情報４６に対応付けられている。なお図４に示した多重アクセスデータでは、プログラムＩＤの代わりにＣＰＵ＿ＩＤを用いている。これはＯＳ（Operating System）が用いられない場合には、１つのＣＰＵに１つのプログラムが固定されるので、ＣＰＵ＿ＩＤを監視すれば何れのプログラムがアクセスしたのかを知ることができるからである。

図１０は、ＯＳ有の場合とＯＳ無しの場合との違いについて説明するための図である。ＯＳ無しの場合には、各ＣＰＵ毎に何れのプログラムを実行するかが決まっている。例えばＣＰＵ０がプログラムＡを実行するとすれば、プログラムＡの全てのスレッドＡはＣＰＵ０により実行される。従って、メモリ２４に対するアクセスを監視する際には、ＣＰＵ＿ＩＤのみをチェックしておけば、何れのプログラムがアクセスしたのかを知ることができる。

それに対してＯＳ有りの場合には、各スレッド実行時に、ＯＳによりスレッドを実行するＣＰＵが決定される。即ち、プログラムＡをＣＰＵ０で実行していたとしても、プログラムＡの全てのスレッドＡがＣＰＵ０により実行されるとは限らず、あるスレッドＡがＣＰＵ１により実行される場合もある。従ってメモリ２４に対するアクセスを監視する際には、ＣＰＵ＿ＩＤを監視するだけでは、何れのプログラム（スレッド）がアクセスしたのかを知ることができない。

図１１は、プログラムＩＤを特定する方法について説明するための図である。図１１に示されるように、各ＣＰＵがそれぞれプログラムを実行している。このときＣＰＵ０がメモリマップ５０上のプログラム１が格納されている領域をアクセスして命令フェッチした場合、即ち、ＣＰＵ０のプログラムカウンタＰＣの値がメモリマップ５０上のプログラム１が格納されている領域内のアドレスを示す場合、ＣＰＵ０が実行しているプログラムはプログラム１であることを知ることができる。このようにしてＰＣの値に基づいてプログラムＩＤを特定できる。

図１２は、ＳＷ／ＨＷモニタ１５への各種データの供給を示す図である。まずプログラム情報４１が、ソフトウェアデバッガ１０からＳＷ／ＨＷモニタ１５に供給される。またＳＷ／ＨＷモニタ１５は、ＣＰＵ情報５１として、ＣＰＵのＩＤ、プログラムカウンタ（ＰＣ）の値、及び命令サイクルのサイクル番号ＣｙｃｌｅをＳｏＣモデル１２のＣＰＵ２１から受け取る。また上に説明したように、アクセスデータ４２がメモリモニタ１３によるアクセス処理により処理され、多重アクセスデータ４４としてＳＷ／ＨＷモニタ１５に供給される。同様に、キャッシュアクセスに対するアクセスデータ５２がキャッシュモニタ１４によるアクセス処理により処理され、多重アクセスデータとしてＳＷ／ＨＷモニタ１５に供給される。これらのデータに基づいて、ＳＷ／ＨＷモニタ１５がプログラム管理データ４０の更新処理（データの追加・削除）を行う。

以下に、図５のステップＳ１２で実行されるデータの追加及び削除について説明する。図１３は、スレッド生成命令によりスレッドが追加されたプログラム管理データ４０を示す図である。

図５及び図７のステップＳ１０に示すＣＰＵによるプログラム実行において、ＣＰＵがある命令をフェッチして実行したときに、その命令がスレッド生成命令である場合、図１３に示すように、そのプログラムのプログラム管理データ４０にスレッドＩＤ６３が付加される。ここでプログラム管理データ４０において、プログラムＩＤ６１にそのプログラムが実行した１つ又は複数のアクセス情報６２が対応付けられており、そのプログラムＩＤ６１に更に、生成されたスレッドのスレッドＩＤ６３が対応付けられる。このスレッドＩＤ６３は、ＯＳ有りの場合にはＯＳにより付与されるＩＤであり、ＯＳ無しの場合には任意のＩＤでよい。

スレッドＩＤ６３にはスレッド有効フラグ６４が対応付けられており、スレッド有効フラグ６４の値はＯＮになっている。このスレッド有効フラグ６４の値は、当該スレッドが削除されたときにＯＦＦとなる。なお図７において図示を省略するが、プログラム管理データ４０においては、図６に示されるように、各プログラムＩＤに対応づけて、ロック開始アドレス、アンロックアドレス、スレッド生成アドレス、スレッド消滅アドレス、スレッド同期アドレス、及びプライオリティを示すデータが設定されている。

図１４は、図１３のプログラム管理データ４０がデ―タ追加により更新された図である。図１４では、スレッドＩＤ６３のスレッドにより複数回のメモリアクセスが実行され、複数のアクセス情報６５−１乃至６５−ｎがスレッドＩＤ６３に対応付けられている。なお図１４においては、プログラムＩＤ６１に対応付けられているアクセス情報６２は省略して示してある。また図１４に示すように、スレッド有効フラグ６４がＯＮに設定されたときの時間がＣｙｃｌｅにより記録されている。このようにしてプログラム管理データ４０においては、スレッドＩＤ毎にアクセスに関する情報を纏めることにより、アクセスに関する情報をスレッド単位で整理する。

図１５は、他のプログラムのスレッドによるアクセスにより多重アクセスが発生した後のプログラム管理データ４０を示す図である。この例では、アクセス情報６５−ｎに対応するリソースに対してプログラムＩＤ６６のプログラムのスレッドＩＤ６７のスレッドがアクセスしている。この場合、スレッドＩＤ６３のスレッドが既にアクセス情報６５−ｎに対応するリソースをロックしている状態で、スレッドＩＤ６７のスレッドがこのリソースにアクセスしたことになる。

プログラム管理データ４０には更に、ロック時のサイクル（Ｃｙｃｌｅ）及びアンロック時のサイクルをロックデータ６８として記録する。これは、図５及び図７のステップＳ１０に示すＣＰＵによるプログラム実行において、ＣＰＵがある命令をフェッチして実行したときに、その命令がロック命令である場合にそのときのＣｙｃｌｅをロック時サイクルとして記録し、その命令がアンロック命令である場合にそのときのＣｙｃｌｅをアンロック時サイクルとして記録すればよい。

図１６は、スレッド削除命令によりスレッドが削除されたプログラム管理データ４０を示す図である。

図５及び図７のステップＳ１０に示すＣＰＵによるプログラム実行において、ＣＰＵがある命令をフェッチして実行したときに、その命令がスレッド削除命令である場合、図１３に示すように、当該スレッドＩＤ６３のスレッド有効フラグ６４の値をＯＦＦにする。また、スレッド有効フラグ６４がＯＦＦに設定されたときの時間を、Ｃｙｃｌｅ値として記録する。

図１７は、図１５の状態からスレッドが更なるスレッド生成命令によりスレッドを生成した場合のプログラム管理データ４０を示す図である。

図５及び図７のステップＳ１０に示すＣＰＵによるプログラム実行において、スレッドＩＤ６３のスレッドのある命令をＣＰＵがフェッチして実行したときに、その命令がスレッド生成命令であるとする。この場合、図１７に示すようにプログラム管理データ４０において、スレッドＩＤ６３により生成されたスレッドとして（スレッドＩＤ６３の下の階層のスレッドとして）、スレッドＩＤ６９がスレッドＩＤ６３に付加される。スレッドＩＤ６９にはスレッド有効フラグ７０が対応付けられており、スレッド有効フラグ７０の値はＯＮになっている。このスレッド有効フラグ７０の値は、当該スレッドが削除されたときにＯＦＦとなる。

以下に図５のステップＳ１３及びＳ１４における処理について説明する。この処理では、多重アクセスによるデータレース及びデッドロック等を抽出し、抽出結果を警告するメッセージを送出する。

図１８は、多重アクセスにより問題が発生する可能性のある箇所を抽出し警告する処理の詳細を示すフローチャートである。ステップＳ１で、着目期間内の新規アクセスを抽出する。ここで着目期間とは、ＳｏＣシミュレータ１１によるＳｏＣモデル１２のシミュレーションの期間を、サイクル数Ｃｙｃｌｅに応じて分割した複数の期間のうちの１つである。例えばシミュレーション期間を１００サイクル毎に分割すれば、第１の期間がサイクル数Ｃｙｃｌｅ０〜９９、第２の期間がサイクル数Ｃｙｃｌｅ１００〜１９９、第３の期間がサイクル数Ｃｙｃｌｅ２００〜２９９であり、以下同様である。

図１９は、着目期間に関するデータ処理とプログラム実行シミュレーションの進行との関係を示す図である。図１９に示されるように、例えばシミュレーション期間を１００サイクル毎に分割した各区間において、各ＣＰＵがそれぞれプログラムを実行する。図１９の例では、各区間の開始タイミングにおいて、各ＣＰＵによるプログラム実行の同期がとられている。図５のステップＳ１２の処理によりサイクルの進行と共にプログラム管理データ４０が蓄積されていくが、ある区間についてのプログラム管理データ４０は、次の区間において実行される多重アクセス検出処理によりチェックされる。即ち、図１９に示されるように、第１の区間が終了した後に、第２の区間において第１の区間のデータを処理する。同様に、第２の区間が終了した後に、第３の区間において第２の区間のデータを処理する。一般に、第Ｎの区間が終了した後に、第Ｎ＋１の区間において第Ｎの区間のデータを処理する。即ち、第Ｎ＋１の区間において、第Ｎの区間において蓄積されたプログラム管理データ４０をチェックして多重アクセス検出等の処理を実行する。この時、この第Ｎ＋１の区間においては、ＳｏＣシミュレータ１１によるＳｏＣモデル１２のプログラム実行シミュレーションが並行して実行されている。

図１８のステップＳ１で、ＳＷ／ＨＷモニタ１５が着目期間内の新規アクセスを抽出することにより、着目期間で発生したアクセスを全てリストアップする。ステップＳ２で、ＳＷ／ＨＷモニタ１５が、新規アクセスのリスト内を全てチェックしたか否かを判定する。ステップＳ３で、ＳＷ／ＨＷモニタ１５が新規アクセスのリストと過去のアクセスのリストとを纏めてチェックして、リソースとスレッドとの関係を示す表を生成する。

図２０は、新規アクセスのリスト及び過去のアクセスのリストを示す図である。図２０において、例えばリスト７１乃至７３としてアクセスのリストが蓄積されたとする。各リストは、図１３乃至図１７で示したプログラム管理データ４０と実質的に同様であり、各アクセス毎にアクセス情報７４乃至７６と、そのアクセス先にアクセスしたプログラムのスレッドとが特定されている。このリストは、プログラム管理データ４０から抽出すればよい。或いは単にプログラム管理データ４０のアクセス関連の部分に着目したものであると考えてもよい。

例えばリスト７１の場合、アドレス１にスレッド０とスレッド１とがアクセスし、スレッド０がアドレス１をロックし、スレッド１はアドレス１のリリース待ちであることが示されている。また同様に、リスト７２の場合、アドレス０にスレッド１とスレッド２とがアクセスし、スレッド１がアドレス０をロックし、スレッド２はアドレス０のリリース待ちであることが示されている。図１８のステップＳ３において、これらのリストをチェックすることにより、デッドロック等を抽出するためのリソースとスレッドとの関係を示す表を生成することができる。

図２１は、図２０のデータから抽出されたリソースとスレッドとの関係を示す表を示す図である。図２１に示す表は、アドレス０に対してはスレッド１がロックしてスレッド２がリリース待ちであり、アドレス１に対してはスレッド０がロックしてスレッド１がリリース待ちであり、アドレス３に対してはスレッド２がロックしてスレッド０がリリース待ちであることが示されている。

図１８に戻り、ステップＳ４でリソースの取り合いがあるか否かをチェックする。これは、図２１に示すような表を縦方向にチェックして、各リソース（図２１の例ではアドレス０乃至アドレス２）毎にロックとリソース待ちとの両方が存在するか否かをチェックすることで行われる。図２１の例の場合、３つのスレッドが３つのリソースをロックして、互いにそれらのリソースのリリースを待っている状態となり、デッドロックの可能性があることが検出できる。このステップＳ４でのチェックによりリソースの取り合いが検出された場合には、ステップＳ５でデッドロックの可能性を指摘する警告を出力する。なお後述するように、ステップＳ４ではデッドロックだけでなくデータレース等についても同様に検出し、データレース等が検出された場合にはステップＳ５で警告を出力する。ステップＳ４でのチェックによりリソースの取り合いやデータレース等が検出されなければ、ステップＳ６に進み次の期間についての処理を実行する。

以下にデッドロックの抽出について更に詳細に説明する。図２２は、複数のスレッド間でのデッドロックの一例を示す図である。図２２では、実線の矢印がロック取得を示し、点線の矢印がリリース待ちを示す。スレッド０がリソース０をロックしリソース１のリリースを待ち、スレッド１がリソース１をロックしリソース２のリリースを待ち、スレッド２がリソース２をロックしリソース３のリリースを待ち、スレッド３がリソース３をロックしリソース０のリリースを待っている。この場合、何れのスレッドも、リリース待ちのリソースが開放されない限りロック中のリソースを開放しないとすると、処理が進まないデッドロック状態となる。

図２３は、スレッドによるリソースロックとアクセス不可とを示す図である。図２３において、スレッド０乃至スレッド４がそれぞれリソースＲＳ１乃至ＲＳ５をロックし、またそれぞれリソースＲＳ２、ＲＳ３、ＲＳ４、ＲＳ５、及びＲＳ１へのアクセスを試みてアクセス不可となった状況が示されている。

図２４は、図２３の場合のメモリマップの様子を示す図である。スレッド０乃至スレッド４がそれぞれリソースＲＳ１乃至ＲＳ５をロックし、またそれぞれリソースＲＳ２、ＲＳ３、ＲＳ４、ＲＳ５、及びＲＳ１へのアクセスを試みてアクセス不可となった状況が、メモリマップ上で示されている。

図２５は、リソースとスレッドとの関係表の一例を示す図である。図２５の例では、スレッド０がリソース０をロックしリソース４のリリースを待ち、スレッド１がリソース１をロックしリソース０のリリースを待ち、スレッド２がリソース２をロックしリソース３のリリースを待ち、スレッド３がリソース３をロックしリソース１のリリースを待ち、スレッド４がリソース４をロックしリソース２のリリースを待っている。この場合、表を縦方向にチェックして、各リソース毎にロックとリソース待ちとの両方が存在するか否かをチェックすると、全てのリソースについて取り合いが発生していることが分かる。従って、何れのスレッドも、リリース待ちのリソースが開放されない限りロック中のリソースを開放しないとすると、処理が進まないデッドロック状態となる。

図２６は、リソースとスレッドとの関係表の別の一例を示す図である。図２６の例では、スレッド０がリソース０をロックし、スレッド１がリソース４をロックし、スレッド２がリソース２をロックしリソース３のリリースを待ち、スレッド３がリソース３をロックしリソース１のリリースを待ち、スレッド４がリソース１をロックしリソース２のリリースを待っている。図２７は、図２６の表を縦方向にチェックした様子を示す図である。図２７に示すように表を縦方向にチェックして、各リソース毎にロックとリソース待ちとの両方が存在するか否かをチェックすると、リソース１、リソース２、及びリソース３について取り合いが発生していることが分かる。従って、スレッド２、スレッド３、及びスレッド４が、リリース待ちのリソースが開放されない限りロック中のリソースを開放しないとすると、処理が進まないデッドロック状態となる。

図２８は、データレースについて説明するための図である。図２８においてはスレッド０がメモリ（又はキャッシュ）の変数ｙに１を代入し、その後変数ｙを変数ｘに代入している。またスレッド０とは独立に、スレッド１が変数ｙに２を代入し、その後変数ｙを変数ｘに代入している。このときメモリ（又はキャッシュ）においては、まずスレッド０（ＩＤ＝０）により変数ｙが１に設定され、その後スレッド１（ＩＤ＝１）により変数ｙが２に書き替えられている。このプログラムにおいて、スレッド０は１が代入された変数ｙを変数ｘに代入することを意図しているとすると、図２８に示す例では変数ｙの多重アクセスにより意図した動作とは異なる動作となり、データレースが発生していることになる。

図２９は、データレースの検出を説明するための図である。図２９に示される例では、スレッド０がメモリ領域８１とメモリ領域８２とに対する読み出し動作（Ｒ）を実行し、スレッド１がメモリ領域８２に対する書き込み動作（Ｗ）を実行し、スレッドＮがメモリ領域８１に対する書き込み動作（Ｗ）を実行している。なおメモリマップはスレッド毎に管理する。メモリへのアクセスは書き込みＷと読み出しＲとの何れかであり、同一のメモリ領域への多重アクセスの組み合わせとしては、ＷＲ、ＲＷ、ＷＷ、及びＲＲの４つの組み合わせがあり得る。このうちＲＲはデータ競合とはならず、データレースとしては検出されない。ＷＲ、ＲＷ、ＷＷについてはデータ競合となるので、データレースとして検出されるべきである。具体的には、図１８で説明したようにＳＷ／ＨＷモニタ１５によりアクセスを抽出してアクセスリスト（図２０に示すのと同様のアクセスリスト）を生成し、このリストからＷＲ、ＲＷ、ＷＷの組み合わせの多重アクセスを検出し、データレースの可能性有りとして警告する。

図３０は、排他制御の検出について説明するための図である。図３０に示される例では、スレッド０がメモリ領域９２に対して読み出し動作（Ｒ）のためにロックしようとして待ち状態となってからその後ロック・アンロックし、更にメモリ領域９１に対して読み出し動作（Ｒ）のためにロック・アンロックし、更にメモリ領域９３に対して書き込み動作（Ｒ）のためにロック・アンロックしている。またスレッド１がメモリ領域９２に対する書き込み動作（Ｗ）のためにロック・アンロックしている。またスレッドＮがメモリ領域９１に対して書き込み動作（Ｗ）のためにロックしようとして待ち状態となってからその後ロック・アンロックし、更にメモリ領域９３に対して書き込み動作（Ｗ）のためにロックしようとして待ち状態となってからその後ロック・アンロックしている。なおメモリマップはスレッド毎に管理する。

メモリへのアクセスは書き込みＷと読み出しＲとの何れかであり、同一のメモリ領域への多重アクセスの組み合わせとしては、ＷＲ、ＲＷ、ＷＷ、及びＲＲの４つの組み合わせがあり得る。このうちＲＲはデータ競合とはならず、排他制御としては検出されない。ＷＲ、ＲＷ、ＷＷについてはデータ競合となるので、排他制御として検出されるべきである。具体的には、図１８で説明したようにＳＷ／ＨＷモニタ１５によりアクセスを抽出してアクセスリスト（図２０に示すのと同様のアクセスリスト）を生成し、このリストからＷＲ、ＲＷ、ＷＷの組み合わせの多重アクセスを検出し、排他制御の可能性有りとして警告する。この際、ＳＷ／ＨＷモニタ１５により、ロック関数呼び出しに応答してアクティブフラグをＯＮに設定し、アンロック関数呼び出しに応答してアクティブフラグをＯＦＦに設定する。これにより、アクティブフラグがＯＮの間にスレッドがアクセスした領域は排他状態と認識される。

図３１は、多重アクセスが発生した場合のメモリとキャッシュとの関係について説明するための図である。２つのアクティブなスレッドＡ及びスレッドＢが同一のアドレス１にアクセスした状況において、メモリとキャッシュとの何れがアクセスされたかに応じて、４つの異なるパターンに場合分けできる。

図３１（ａ）は、スレッドＡがメモリにアクセスし、スレッドＢもメモリにアクセスした場合である。この場合、メモリ間でリソース競合アクセスが発生しているのを検知できる。（ｂ）は、スレッドＡがＣＰＵ０のキャッシュ９５にアクセスし、スレッドＢがメモリにアクセスした場合である。この場合、ＣＰＵ０のキャッシュ９５内のデータとメモリのデータとに違いが発生していることを検知できる。（ｃ）は、スレッドＡがＣＰＵ０のキャッシュ９５にアクセスし、スレッドＢがＣＰＵ１のキャッシュ９６にアクセスした場合である。この場合、ＣＰＵ０／ＣＰＵ１のキャッシュ内でアクセスがあり、実際のメモリにはアクセスが発生していないことを検知できる。（ｄ）は、スレッドＡがＣＰＵ０のキャッシュ９５とメモリとにアクセスし、スレッドＢがＣＰＵ１のキャッシュ９６にアクセスした場合である。この場合、ＣＰＵ０のキャッシュ９５のデータとメモリのデータとは同一となる場合と異なる場合とがある。同一となるのは、ＣＰＵ０がメモリとキャッシュとを正常に更新した場合である。異なるのは、ＣＰＵ０がメモリにアクセスする前後でＣＰＵ１のアクセスがあった場合である。但し、ＣＰＵ０のアクセスとＣＰＵ１のアクセスとが両方とも読み出しアクセスの場合は、上記パターンに関係なく多重アクセスによる問題は発生しない。

図３２は、本発明によるＳｏＣシミュレータ１１を実行する装置の構成を示す図である。

図３２に示されるように、本発明によるＳｏＣシミュレータ１１を実行する装置は、例えばパーソナルコンピュータやエンジニアリングワークステーション等のコンピュータにより実現される。図３２の装置は、コンピュータ５１０と、コンピュータ５１０に接続されるディスプレイ装置５２０、通信装置５２３、及び入力装置よりなる。入力装置は、例えばキーボード５２１及びマウス５２２を含む。コンピュータ５１０は、ＣＰＵ５１１、ＲＡＭ５１２、ＲＯＭ５１３、ハードディスク等の二次記憶装置５１４、可換媒体記憶装置５１５、及びインターフェース５１６を含む。

キーボード５２１及びマウス５２２は、ユーザとのインターフェースを提供するものであり、コンピュータ５１０を操作するための各種コマンドや要求されたデータに対するユーザ応答等が入力される。ディスプレイ装置５２０は、コンピュータ５１０で処理された結果等を表示すると共に、コンピュータ５１０を操作する際にユーザとの対話を可能にするために様々なデータ表示を行う。通信装置５２３は、遠隔地との通信を行なうためのものであり、例えばモデムやネットワークインターフェース等よりなる。

本発明によるＳｏＣシミュレータ１１及びソフトウェアデバッガ１０は、コンピュータ５１０が実行可能なコンピュータプログラムとして提供される。このコンピュータプログラムは、可換媒体記憶装置５１５に装着可能な記憶媒体Ｍに記憶されており、記憶媒体Ｍから可換媒体記憶装置５１５を介して、ＲＡＭ５１２或いは二次記憶装置５１４にロードされる。或いは、このコンピュータプログラムは、遠隔地にある記憶媒体（図示せず）に記憶されており、この記憶媒体から通信装置５２３及びインターフェース５１６を介して、ＲＡＭ５１２或いは二次記憶装置５１４にロードされる。

キーボード５２１及び／又はマウス５２２を介してユーザからプログラム実行指示があると、ＣＰＵ５１１は、記憶媒体Ｍ、遠隔地記憶媒体、或いは二次記憶装置５１４からプログラムをＲＡＭ５１２にロードする。ＣＰＵ５１１は、ＲＡＭ５１２の空き記憶空間をワークエリアとして使用して、ＲＡＭ５１２にロードされたプログラムを実行し、適宜ユーザと対話しながら処理を進める。なおＲＯＭ５１３は、コンピュータ５１０の基本動作を制御するための制御プログラムが格納されている。

上記コンピュータプログラムを実行することにより、コンピュータ５１０が、上記各実施例で説明されたようにソフトウェアデバッガ１０及びＳｏＣシミュレータ１１を実行する。

以上、本発明を実施例に基づいて説明したが、本発明は上記実施例に限定されるものではなく、特許請求の範囲に記載の範囲内で様々な変形が可能である。例えば同一の領域へのアクセスとしてはメモリ又はキャッシュへのアクセスを主な例として説明したが、デッドロック等検出の対象となるのはメモリ又はキャッシュに限られず、ＣＰＵがアクセス可能なものであればよい。例えば図１に示す周辺ブロック２２のＩ／Ｏリソース等へのアクセスも、検出対象のアクセスとしてよい。

本発明によるＳｏＣシミュレータを使用する構成の一例を示す図である。 スレッド間の関係を示す階層化データ情報の一例を示す図である。 多重アクセスを示す多重アクセス情報を生成する処理を説明する図である。 メモリモニタにより生成された多重アクセス情報のデータ構造を示す図である。 図１の構成によりプログラムのデータレース及びデッドロック等を抽出する処理の全体の流れを示す図である。 図５のステップＳ５及びステップＳ６における処理を説明するための図である。 図５のステップＳ９及びステップＳ１０における処理を説明するための図である。 メモリモニタによるデータ収集処理を説明するための図である。 データ比較処理を説明するための図である。 ＯＳ有の場合とＯＳ無しの場合との違いについて説明するための図である。 プログラムＩＤを特定する方法について説明するための図である。 ＳＷ／ＨＷモニタへの各種データの供給を示す図である。 スレッド生成命令によりスレッドが追加されたプログラム管理データを示す図である。 図１３のプログラム管理データがデ―タ追加により更新された図である。 他のプログラムのスレッドによるアクセスにより多重アクセスが発生した後のプログラム管理データを示す図である。 スレッド削除命令によりスレッドが削除されたプログラム管理データを示す図である。 図１５の状態からスレッドが更なるスレッド生成命令によりスレッドを生成した場合のプログラム管理データを示す図である。 多重アクセスにより問題が発生する可能性のある箇所を抽出し警告する処理の詳細を示すフローチャートである。 着目期間に関するデータ処理とプログラム実行シミュレーションの進行との関係を示す図である。 新規アクセスのリスト及び過去のアクセスのリストを示す図である。 図２０のデータから抽出されたリソースとスレッドとの関係を示す表を示す図である。 複数のスレッド間でのデッドロックの一例を示す図である。 スレッドによるリソースロックとアクセス不可とを示す図である。 図２３の場合のメモリマップの様子を示す図である。 リソースとスレッドとの関係表の一例を示す図である。 リソースとスレッドとの関係表の別の一例を示す図である。 図２６の表を縦方向にチェックした様子を示す図である。 データレースについて説明するための図である。 データレースの検出を説明するための図である。 排他制御の検出について説明するための図である。 多重アクセスが発生した場合のメモリとキャッシュとの関係について説明するための図である。 本発明によるＳｏＣシミュレータを実行する装置の構成を示す図である。

符号の説明

１０ ソフトウェアデバッガ
１１ ＳｏＣシミュレータ
１２ ＳｏＣモデル
１３ メモリモニタ
１４ キャッシュモニタ
１５ ＳＷ／ＨＷモニタ
２１ ＣＰＵ
２２ 周辺ブロック
２３ ＤＲＡＭ
２４ メモリ
２５ バス
５１０ コンピュータ
５１１ ＣＰＵ
５１２ ＲＡＭ
５１３ ＲＯＭ
５１４ 二次記憶装置
５１５ 可換媒体記憶装置
５１６ インターフェース
５２０ ディスプレイ装置
５２１ キーボード
５２２ マウス
５２３ 通信装置

Claims (9)

1. ソフトウェアによるシミュレータ上にソフトウェアとして実現したハードウェアのモデルにより複数のスレッドからなるプログラムを実行し、
   該シミュレータのモニタ機能により該ハードウェアのモデル内のリソースに対する該複数のスレッドによるアクセスをモニタしてアクセスに関する情報を収集し、
   該モニタ機能により、該収集された情報から複数のスレッドによる同一のリソース領域に対する重複するアクセスを抽出し、
   該モニタ機能により、該重複するアクセスを警告するメッセージを生成する
   各段階を含むことを特徴とするコンピュータによるソフトウェアのシミュレーション方法。
2. 該収集する情報は、アクセス元のＣＰＵのＩＤ、該ＣＰＵのプログラムカウンタの値、アクセスアドレス、アクセスサイズ、Ｒｅａｄ／Ｗｒｉｔｅの種別、及びアクセス発生時の該シミュレータの実行サイクル数であることを特徴とする請求項１記載のシミュレーション方法。
3. 該重複するアクセスを抽出する段階は、該複数のスレッドによるアクセス間で、該アクセスアドレス及び該アクセスサイズを比較することにより、該重複するアクセスを抽出することを特徴とする請求項２記載のシミュレーション方法。
4. 抽出された該重複するアクセスに関する情報を、スレッドＩＤ毎に纏めることにより、スレッド単位で整理し、
   該スレッド単位で整理された該重複するアクセスに関する情報に基づいてスレッド毎に各リソースのロック及びリリース待ちを示したスレッドとリソースとの関係を示す表を作成し、
   各リソース毎にロックとリソース待ちとの両方が存在するか否かをチェックすることにより、該表に基づいてデッドロックの可能性を検出する
   各段階を更に含み、該メッセージを生成する段階は該検出されたデッドロックの可能性について警告するメッセージを生成することを特徴とする請求項１記載のシミュレーション方法。
5. 抽出された該重複するアクセスに関する情報を、スレッドＩＤ毎に纏めることにより、スレッド単位で整理し、
   該スレッド単位で整理された該重複するアクセスに関する情報に基づいて、該重複するアクセスが読み出しアクセスであるか又は書き込みアクセスであるかに応じて書き込み＆読み出し、読み出し＆書き込み、書き込み＆書き込みの組み合わせの多重アクセスを検出することにより、データレースの可能性を検出する
   各段階を更に含み、該メッセージを生成する段階は該検出されたデータレースの可能性について警告するメッセージを生成することを特徴とする請求項１記載のシミュレーション方法。
6. 該メッセージを生成する段階は、該重複するアクセスに起因する問題の種別を特定する情報及び該重複するアクセスのアクセス先を特定する情報を含めて該メッセージを生成することを特徴とする請求項１記載のシミュレーション方法。
7. 該ハードウェアのモデルの動作期間を複数の期間に分割し、該複数の期間のうちの所定の期間において生成された該アクセスに関する情報を該所定の期間において収集し、該収集された情報に基づいて該所定の期間の次の期間において該メッセージを生成することを特徴とする請求項１記載のシミュレーション方法。
8. ソフトウェアによるシミュレータ上にソフトウェアとして実現したハードウェアのモデルにより複数のスレッドからなるプログラムを実行し、
   該シミュレータのモニタ機能により該ハードウェアのモデル内のリソースに対する該複数のスレッドによるアクセスをモニタしてアクセスに関する情報を収集し、
   該モニタ機能により、該収集された情報から複数のスレッドによる同一のリソース領域に対する重複するアクセスを抽出し、
   該モニタ機能により、該重複するアクセスを警告するメッセージを生成する
   各段階をコンピュータに実行させる指令から構成されるソフトウェアのシミュレーションのためのプログラム。
9. ソフトウェアとして実現したハードウェアのモデルを含むシミュレータプログラムと該ハードウェアのシステムでの実行を想定した複数のスレッドからなるプログラムとを格納するメモリと、
   該メモリに格納された該シミュレータプログラムを実行することにより該メモリに格納された該複数のスレッドからなるプログラムを該ハードウェアのモデル上で実行する演算処理ユニットを含み、該演算処理ユニットは、
   該シミュレータのモニタ機能により該ハードウェアのモデル内のリソースに対する該複数のスレッドによるアクセスをモニタしてアクセスに関する情報を収集し、
   該モニタ機能により、該収集された情報から複数のスレッドによる同一のリソース領域に対する重複するアクセスを抽出し、
   該モニタ機能により、該重複するアクセスを警告するメッセージを生成する
   各段階を実行することを特徴とするソフトウェアのシミュレーション装置。

Images