(57)【要約】【課題】  論理回路のシステム検証の際、テスト実行において基本的なプロセス制御やシーケンス制御を自動的に管理・実行する。【解決手段】  論理回路のシステム検証において、テスト実行プロセスをランダム実行させる手段と、プロセスの実行、終了を管理する手段とを有し、それらの手段を自動的に行う仕組みを有するプログラム。【選択図】  図２
2006163981.tif 000002
【特許請求の範囲】
【請求項１】
複数ブロックの回路からなる論理回路のシステム検証において、ブロックの個別機能テストをランダムに起動させることにより検証を行う論理検証手法。
【請求項２】
上記個別機能テスト起動前にランダムサイクルの待ち時間を挿入するステップを有することを特徴とする請求項１記載の論理検証手法。
【請求項３】
個別機能テストの内容を実行する前に、ランダムサイクルの待ち時間を挿入するステップを有することを特徴とする請求項１記載の論理検証手法。
【請求項４】
個別機能テストを起動する際に、あらかじめ指定しておいた全個別機能テスト実行数と、そのときまでに終了した個別機能テスト数を比較するステップと、その比較結果から個別機能テストを実行するか実行しないかを判断することが可能であるステップを有することを特徴とする論理検証手法。
【請求項５】
個別機能テストを起動する際に、あらかじめ指定しておいた同時実行する個別機能テスト数と、そのとき実行している個別機能テスト数を比較するステップと、その比較結果から個別機能テストを実行するか実行しないかを判断するステップを有することを特徴とする論理検証手法。
【請求項６】
上記個別機能テストの実行後にあらかじめ指定しておいた全個別機能テスト実行数と、そのときまでに終了した個別機能テスト数を比較するステップと、その比較結果からシステムテストの終了条件を満たしたか満たしていないかを判断し、満たしていた場合にシステムテストを終了するステップを有することを特徴とする論理検証手法。
【請求項７】
個別機能テストにＩＤを設け、上記個別機能テスト実行後に実行済み個別機能テストのＩＤを記録しておくステップと、指定された全ての個別機能テストのＩＤが記録されていればシステムテストの終了条件を満たしたと判断し、システムテストを終了するステップを有することを特徴とする論理検証手法。
【請求項８】
請求項２、請求項３、請求項４、請求項５の処理手続きを請求項６または請求項７にけるステップをシステムテスト終了条件が満たされるまで自動的に繰り返すことを特徴とする論理検証手法。
【請求項９】
個別機能テストを複数持つテストベンチを使用したシステム検証において、それら個別機能テストを同時に複数起動および実行させることを特徴とする論理検証手法。
【請求項１０】
個別機能テストを複数持つテストベンチを使用したシステム検証において、機能ブロック単体に対し、複数の個別機能テストを同時に起動および実行させることを特徴とする論理検証手法。
【請求項１１】
個別機能テストを複数持つテストベンチを使用したシステム検証において、それら個別機能テストを同時に複数起動および実行させる場合に、個別機能テスト実行に必要なハードウェア資源を、テスト実行前に確保するステップを有することを特徴とするの論理検証手法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、集積回路のための論理検証手法に関するものである。
【背景技術】
【０００２】
一般に、システムＬＳＩ等の集積回路のための論理検証テストにおいて、複数の機能ブロックを同時に動作させて検証を行うテスト（以下、システム検証と呼ぶ）が行われている。システム検証は、検証時テストが使用するハードウェア資源が競合を起こさないようテスト命令を調停する仕組みを設け、個別機能テストを同時動作させて検証を行う方式や、あらかじめ決められた実行手順やタイミングをシナリオテストに記述し、そのシナリオにそって個別機能テストを実行して検証を行う方式がとられている（例えば、特許文献１参照）。
【特許文献１】特開２００２−５５８４３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記従来例では、回路全体が実際に使用されるような状況を発生させることはできるが、そのような状況を網羅する数のテストを用意しなければならず、テスト作成の負荷が大きくなり、また、シミュレーション効率が悪いという課題がある。特に機能ブロックの動作手順が外的要因に依存する等で不確定な回路の場合、全ての状況を十分に網羅することができないと、検証の信頼性が低下してしまうといった問題も発生する。
【０００４】
本発明は、上述の課題に鑑みてなされたもので、その目的とするところは、システム検証において個別機能テストの実行順序と個別機能テスト内容の実行タイミングにランダム性持たせることができるようにし、個別機能テストをシステムテストに流用することで検証の効率化を図ることにある。
【課題を解決するための手段】
【０００５】
上記の目的を達成するために本発明による論理回路システム検証手法は、集積回路に含まれる複数の機能ブロックを同時に動作させて論理検証するためのシステム検証テスト記述と、起動する個別機能テストをランダムに決定することと、個別機能テスト内容の実行タイミングをランダムに決定することと、個別機能テストの実行を、全個別機能テスト実行数と同時実行可能な個別機能テスト数から判断し制御することを特徴とする。
【発明の効果】
【０００６】
以上説明したように、本発明において、請求項２により、システム検証における個別機能テスト実行の順番と請求項３により個別機能テスト内容の実行のタイミングに冗長度を持たせることが可能となり、そのことによって個別機能テストをシステムテストに流用することができ、システムテスト作成の省力化が図れ、さらに検証の効率を向上することが可能となる。
【発明を実施するための最良の形態】
【０００７】
＜実施形態１＞
以下、添付の図面を参照して、本発明の好適な実施形態を説明する。図1は第１の実施形態による，集積回路の論理検証を行うシステム構成を示す。１０１はシステム検証用テスト、１０５、１０６、１０７は機能ブロックの個別機能テストである。１１５は検証対象となる集積回路であり、機能ブロック１０８、１０９、１１０と共有ハードウェア資源１１１、１１２とCPU１１４がシステムバス１１３に接続されている。１０２、１０３、１０４は機能ブロックの個別機能テストの起動および実行を制御するプログラム（以下機能テストと呼ぶ）である。１１６は機能テストが起動する個別機能テスト実行プロセスを管理するプログラムである。１１７は検証で利用されるユーティリティである。１１８はシステムテスト中にハードウェア資源の使用状況を管理するリソース管理プログラムである。なお、機能ブロック１０８、１０９、１１０の個別機能テストはそれぞれ機能ブロックの個別機能テスト１０５、１０６、１０７に対応している。また、１０２、１０５、１０８のように、ひとつの機能ブロックに複数の個別機能テストと機能テストを対応させて検証を行うことも可能である。
【０００８】
システムテスト１０１を起動すると、機能テスト１０２、１０３、１０４が開始される。この機能テストは、それぞれの個別機能テスト１０５、１０６、１０７を起動する前にランダムな待ち時間を発生させる。その後、待ち時間が終了した機能テストから順に個別機能テストの実行要求を行う。今、機能テスト１０２が個別機能テスト１０５の実行要求を行ったと仮定する。プロセス管理プログラム１１５はこの要求を受け、あらかじめ指定されている全個別機能テスト実行数と同時実行可能な個別機能テスト数から個別機能テスト１０５の実行が可能であるか判断し個別機能テスト実行権を機能テスト１０２に与える。個別機能テスト実行権を得た機能テスト１０２は、ユーティリティ１１７を介して個別機能テスト実行時に使用するハードウェア資源の確保要求をリソース管理プログラム１１８に通知する。リソース管理プログラムは、ハードウェア資源ごとに必要とされる資源を順に確保していく。個別機能テスト実行権と実行時必要となる全資源の確保がともに成功した場合、機能テスト１０２は、ランダムに待ち時間を発生させた後、個別機能テスト１０５を実行する。機能テスト１０２は，ユーティリティ１１７に記述されたＣＰＵコマンドを起動する。するとＣＰＵ１１４からシステムバス１１３を介して，対応する機能ブロック１０８および共有資源１１１または１１２へのアクセスが行われる。このようにして個別機能テスト１０５の実行が終了すると、機能テスト１０２は個別機能テスト１０５実行のために、リソース管理プログラムが確保していた資源と個別機能テスト実行権をユーティリティ１１７を介して解放する。そして、プロセス管理プログラム１１５は規定されている全個別機能テスト実行数を満たしているか判断し、満たしていたならばシステムテストを終了させる。
【０００９】
このように、機能テストにおいて、システムテスト開始から各機能テスト起動までにランダムな待ち時間を挿入し機能テストの起動順序をランダムにすることで起動する個別機能テストをランダムに決定できる。さらに、個別機能テストの内容を実行する前にランダムな待ち時間を挿入することで、個別機能テスト内容の実行タイミングをランダムにすることができる。
【００１０】
また、プロセス管理プログラムによって機能テストの同時実行数とシステムテスト終了の判断を行う。これらの仕組みについて例を用いて詳細に説明する。
【００１１】
図２は機能テストのフローチャート、図３はプロセス管理プログラムのフローチャートである。
【００１２】
個別機能テストは機能テストによって実行される。プロセス管理プログラムは、この機能テストによる個別機能テスト実行プロセスを制御する。プロセス管理プログラムは、システムテストにおいて実行する個別機能テストの総数と同時に実行できる個別機能テスト数のパラメータを持ち、検証者があらかじめこのパラメータ値を設定することが可能である。
【００１３】
まず、機能テストのフローについて図２を用いて説明する。システムテストが開始されると、テスト実行プログラムが開始される。機能テストはＳ１１においてプロセス管理プログラムからの機能テスト開始イベントの発生を待つ。
【００１４】
イベント発生が発生したら、全機能テストは一斉にＳ１３に移りランダムサイクル待機する。その後Ｓ１４に遷移し、待機時間の終了した機能テストから順にプロセス管理プログラムに個別機能テストプロセスの実行要求を行う。Ｓ１３における待機時間は機能テスト自身でランダムに決定するので、機能テストごとに待機時間は異なってくる。その後Ｓ１４で待機時間切れを迎えた機能テストから順に個別機能テスト起動を行うので、システムテストにおいて起動される個別機能テストとその順番をランダムに決定することができる。
【００１５】
Ｓ１４で、プロセス管理プログラムから個別機能テスト実行プロセス要求を許可されなかった場合はＳ１１０に遷移し、プロセス管理プログラムからシステムテストの終了イベントが発生しているか確認し、発生していなければＳ１３から上記フローを繰り返す。終了イベントが発生していれば自分の実行を終了する。
【００１６】
一方、Ｓ１４で個別機能テストプロセス実行を許可された場合は、Ｓ１５に遷移し、個別機能テスト実行時に必要なハードウェア資源を検証用ユーティリティを介して確保していく。
【００１７】
Ｓ１５で、必要な資源を確保できなかった場合は、Ｓ１１１、Ｓ１１２へと遷移し、それまでに確保したハードウェア資源を解放し、個別機能テストプロセス実行権を放棄する。その後、Ｓ１１０へ遷移し、プロセス管理プログラムからシステムテストの終了イベントが発生しているか確認し、発生していなければＳ１３から上記フローを繰り返す。終了イベントが発生していれば自分の実行を終了する。
【００１８】
Ｓ１５で、必要なハードウェア資源の確保に成功した場合、Ｓ１６に遷移しランダムサイクル待機し、Ｓ１７に遷移し、個別機能テストを呼び出し実行する。このときのランダムサイクル待ちによって、個別機能テスト実行のタイミングをランダムにすることが可能となる。ここで、Ｓ１３におけるランダムサイクル待機とＳ１６におけるランダムサイクル待機の違いは、ハードウェア資源を確保する前か、後かであって、確保した後の場合、その待機中に同じハードウェア資源を用いる他の機能テストを実行することはできないが、確保する前であれば、同じハードウェア資源を用いる他の機能テストが実行される可能性があることである。
【００１９】
個別機能テストが終了したらＳ１８、Ｓ１９に移り、ハードウェア資源を解放し、個別機能テストプロセス実行権を放棄する。
【００２０】
その後、機能テストはＳ１１０に遷移し、プロセス管理プログラムからシステムテストの終了イベントが発生しているか確認し、発生していなければＳ１３から上記フローを繰り返す。終了イベントが発生していれば自分の実行を終了する。
【００２１】
次に、プロセス管理プログラムのフローについて図３を用いて説明する。プロセス管理プログラムは、個別機能テスト実行プロセス判断部とシステムテスト終了判断部に分かれており、この２つが同時に動作する。最初に、個別機能テスト実行プロセス判断部のフローについて説明する。
【００２２】
プロセス管理プログラムは、システムテストが開始されると、Ｓ２１において機能テストの起動トリガとなるシステムテスト開始イベントを発行する。この後プロセス管理プログラムはＳ２２に移り、機能テストのテスト実行プロセス実行要求があるまで待機する。
【００２３】
機能テストからの個別機能テストプロセス実行要求を受けたらＳ２１４へ遷移し、この時にシステムテストの終了イベントが発行されていないかを確認する。このように、個別機能テストを起動する前にシステムテスト終了イベントを確認することによって不必要な個別テスト実行を防ぐことが可能となる。この後、Ｓ２３に遷移し、機能テストからの個別機能テストプロセス実行要求の調停を開始する。調停はプロセス管理プログラムが、あらかじめ検証者が指定できる全個別機能テスト実行数と同時実行できる個別機能テスト数のパラメータ値と、プロセス管理プログラムが持つ実行済み個別機能テスト数カウンタＳ２１２と同時実行中個別機能テスト数カウンタＳ２１３の値から判断する。
【００２４】
Ｓ２３でプロセス管理プログラムは、実行済み個別機能テスト数カウンタＳ２１２と同時実行個別機能テスト数カウンタＳ２１３の値を参照し、それらの和が規定された全個別機能テスト実行数に達していればＳ２６へ遷移し、プロセス実行要求を許可しない。その後、プロセス管理プログラムはＳ２２に遷移しシステムテスト終了イベントが発生するまで待機する。
【００２５】
プロセス管理プログラムがＳ２３からＳ２４に遷移した場合、プロセス管理プログラムは、同時実行中個別機能テスト数のカウンタＳ２１３の値を参照し、それが規定された同時個別機能テスト実行数以上であった場合要求を許可しない。この場合も、プロセス管理プログラムはＳ２２に遷移し次の個別機能テスト実行要求が発生するまで待機する。
【００２６】
Ｓ２３、Ｓ２４を通過した場合、つまりプロセス管理プログラムが、全個別機能テスト実行数と同時実行個別機能テスト数を満たしていないと判断した場合、Ｓ２５に遷移し、要求を行った機能テストに個別機能テストプロセスの実行の許可を通知し、個別機能テストプロセス実行権を与える。
【００２７】
その後、Ｓ２１６に遷移し、同時実行個別機能テスト数カウンタＳ２１３の値に１を加算し、同時実行個別機能テスト数カウンタＳ２１３を更新する。
【００２８】
その後、プロセス管理プログラムはＳ２２に遷移しプロセス実行要求があるまで待機する。
【００２９】
上記のように、本発明における機能テストはＳ２２からＳ２６またはＳ２２からＳ２１６までのフローを繰り返し実行することが可能である。
【００３０】
次に、システムテスト終了判断部について説明を行う。
【００３１】
プロセス管理プログラムのシステムテスト終了判断部は、システムテストが開始された後、Ｓ２１１に遷移し、機能テストからの個別機能テスト実行プロセス終了イベント通知があるまで待機する。
【００３２】
個別機能テスト実行プロセス終了イベント通知を受けたら、Ｓ２７に遷移し、実行済み個別機能テスト数カウンタＳ２１２の値に１を加算し、同時実行中個別機能テスト数カウンタＳ２１３の値から１を減算し、カウンタＳ２１２、Ｓ２１３を更新する。
【００３３】
その後、Ｓ２８に遷移し、更新後の実行済み個別機能テスト数カウンタＳ２１２の値を参照し全個別機能テスト実行数の規定値と等しいならば、システムテストの終了条件を満たしたと判断し、Ｓ２１０へ遷移し、システムテストの終了イベントを発行する。
【００３４】
さらに上記フローにおいて、検証者が実行しなければならないデバイステストのＩＤを登録したリストを作成し、Ｓ２７において実行済み個別機能テストＩＤをリストに記録しておき、Ｓ２８において実行済み個別機能テストリストと実行必須な個別機能テストを比較することで、システムテストの終了条件を満たしたか満たしていないかを判断させることも可能である。Ｓ２８の終了条件の組み合わせはプロセス管理プログラムがそれらの条件に対応したフラグ等を持つことによって選択することも可能である。
【００３５】
このように、個別機能テストのランダム実行をプロセス管理プログラムによって制約することで検証者が期待するハードウェアの実行状況の発生までの時間を短縮することが可能となる。また、設計者、検証者が思いもつかないハードウェアの動作状況を容易に作り出すことも可能である。
【図面の簡単な説明】
【００３６】
【図１】集積回路の論理検証を行うシステム構成を示す図である。
【図２】テスト実行プログラムにおける処理のフローチャートである。
【図３】プロセス管理プログラムにおける処理のフローチャートである。
【符号の説明】
【００３７】
１０１  システムテスト
１０２  機能テスト
１０３  機能テスト
１０４  機能テスト
１０５  機能ブロックの個別機能テスト
１０６  機能ブロックの個別機能テスト
１０７  機能ブロックの個別機能テスト
１０８  機能ブロック
１０９  機能ブロック
１１０  機能ブロック
１１１  ハードウェア資源
１１２  ハードウェア資源
１１３  システムバス
１１４  CPU
１１５  システムLSI
１１６  プロセス管理プログラム
１１７  検証用ユーティリティ
１１８  リソース管理プログラム
【図１】
2006163981.tif 000003
【図２】
2006163981.tif 000004
【図３】
2006163981.tif 000005