(57)【要約】【課題】  論理回路の検証を行うモニタの検証精度を十分にチェックするための技術を提供すること。【解決手段】  論理回路を構成するバスのプロトコル仕様を示すデータを読み出し（Ｓ２０１）、このバスのトランザクションを監視するモニタの検証期間中の全てのサイクルにおいてプロトコル仕様を満たすトランザクションを示す正常プロトコルテストベクタを作成し（Ｓ２０２）、モニタの検証期間中の所望のサイクルでプロトコル仕様を満たさないトランザクションを示す違反プロトコルテストベクタを作成する（Ｓ２０４）。【選択図】  図２
2006268194.tif 000002
【特許請求の範囲】
【請求項１】
論理回路を構成するバスのトランザクションを監視するモニタの検証を行うために用いるデータを作成する情報処理装置であって、
前記バスのプロトコル仕様を示すデータを保持する保持手段と、
前記モニタの検証期間中の全てのサイクルにおいて前記プロトコル仕様を満たすトランザクションを示す第１のデータを作成する第１の作成手段と、
前記モニタの検証期間中の所望のサイクルで前記プロトコル仕様を満たさないトランザクションを示す第２のデータを作成する第２の作成手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記第１の作成手段は、
前記モニタの検証を行うサイクル数を指定する指定手段と、
１サイクル内で前記論理回路内で発生し得る制御信号の組み合わせで定義されるイベントをランダムに発生する発生手段と、
前記発生手段が発生したイベントが、前記プロトコル仕様のうち、ステート遷移条件を満たしているか否かを判断する第１の判断手段と、
前記発生手段が発生したイベントが、前記プロトコル仕様のうち、タイミング条件を満たしているか否かを判断する第２の判断手段とを備え、
前記ステート遷移条件及び前記タイミング条件を満たしているイベントを、前記指定手段が指定したサイクル数分発生させることで、前記第１のデータを作成することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第２の作成手段は、
前記第１のデータに含まれている各サイクルのイベントのうち、１つを前記プロトコル仕様を満たしていないイベントに置き換えることで前記第２のデータを作成することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第２の作成手段は、
前記第１のデータ中の所定のイベント間に、前記プロトコル仕様を満たしていないイベントを挿入することで前記第２のデータを作成することを特徴とする請求項２に記載の情報処理装置。
【請求項５】
前記第２の作成手段は、
前記第１のデータ中の所定のイベント間の遷移タイミングを、前記プロトコル仕様を満たしていないタイミングに置き換えることで前記第２のデータを作成することを特徴とする請求項２に記載の情報処理装置。
【請求項６】
前記第１のデータに従ったトランザクションを前記バス上に発生させた場合に、それぞれのイベント毎の前記バス上におけるプロトコル状態を示す期待値が前記第１のデータ内に含まれていることを特徴とする請求項２に記載の情報処理装置。
【請求項７】
前記第２のデータに従ったトランザクションを前記バス上に発生させた場合に、それぞれのイベント毎の前記バス上におけるプロトコル状態を示す期待値が前記第２のデータ内に含まれていることを特徴とする請求項２に記載の情報処理装置。
【請求項８】
更に、前記第１のデータ、前記第２のデータに従ったトランザクションを前記バス上に発生させた場合に、前記モニタによる監視結果と、発生させたトランザクションに対応する期待値とを比較するテストベンチを備えることを特徴とする請求項１に記載の情報処理装置。
【請求項９】
論理回路を構成するバスのトランザクションを監視するモニタの検証を行うために用いるデータを作成する情報処理方法であって、
前記バスのプロトコル仕様を示すデータを保持する保持工程と、
前記モニタの検証期間中の全てのサイクルにおいて前記プロトコル仕様を満たすトランザクションを示す第１のデータを作成する第１の作成工程と、
前記モニタの検証期間中の所望のサイクルで前記プロトコル仕様を満たさないトランザクションを示す第２のデータを作成する第２の作成工程と
を備えることを特徴とする情報処理方法。
【請求項１０】
コンピュータに請求項９に記載の情報処理方法を実行させることを特徴とするプログラム。
【請求項１１】
請求項１０に記載のプログラムを格納したことを特徴とする、コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、論理回路の検証技術に関するものである。
【背景技術】
【０００２】
ＬＳＩを含む論理システムの規模は年々増大しており、システムに搭載される機能も高度化・多様化している。このような状況の中、目的のシステムを効率よく実現する為の手段として、ＣＰＵと、このＣＰＵと電気的に接続されている周辺回路を１つのチップに搭載したシステムＬＳＩの開発が行われている。
【０００３】
さらにシステムＬＳＩでは、年々拡大する電子機器の性能への要求を満たす為に、データ処理能力を向上させる為の高速データ転送を行うバスと、汎用バスといったように複数のバスを利用する手法が一般的になってきている。このため、論理シミュレーションを用いた論理回路の検証において、バス上のプロトコルを監視するモニタの重要性が高まっている（例えば、特許文献１）。論理シミュレーションに先立ってモニタ自身の検証が当然行われているが、その検証方法はモニタの設計仕様書レベルでのレビューまたは、検証者が手作業でテストベクタを作成してモニタの検証を行ってきた。
【特許文献１】特開平６−２５０９４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、システムＬＳＩに組み込まれるバスの多様化、高機能化により、バス上に発生するトランザクションも複雑化しており、実機検証段階で論理回路の不具合が発生するケースが増えてきた。その原因としてはバスを監視するモニタ自身の検証性能が不十分である為に、論理シミュレーション時に発生したプロトコル違反を見逃してしまう状況が頻発していることが挙げられる。
【０００５】
従来のモニタの検証手法では、検証者が意図的に挿入したエラーに対する動作のみしか検証できないため、モニタ自体の精度が必ずしも保証されているとは言えなかった。モニタの検証精度を十分に保証する為には正常なバスプロトコルに対するモニタの検証だけでなく、違反プロトコルに大してもモニタを十分にチェックする必要がある。しかし、従来のように手作業で全てのモニタ検証用テストベクタを生成するのは現実的に不可能であり、実際には論理シミュレーションで論理回路の検証を行いながら、時間をかけてモニタの検証精度を高めていくしかなかった。
【０００６】
本発明は以上の問題に鑑みてなされたものであり、論理回路の検証を行うモニタの検証精度を十分にチェックするための技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の目的を達成するために、例えば、本発明の情報処理装置は以下の構成を備える。
【０００８】
即ち、論理回路を構成するバスのトランザクションを監視するモニタの検証を行うために用いるデータを作成する情報処理装置であって、
前記バスのプロトコル仕様を示すデータを保持する保持手段と、
前記モニタの検証期間中の全てのサイクルにおいて前記プロトコル仕様を満たすトランザクションを示す第１のデータを作成する第１の作成手段と、
前記モニタの検証期間中の所望のサイクルで前記プロトコル仕様を満たさないトランザクションを示す第２のデータを作成する第２の作成手段と
を備えることを特徴とする。
【０００９】
本発明の目的を達成するために、例えば、本発明の情報処理方法は以下の構成を備える。
【００１０】
即ち、論理回路を構成するバスのトランザクションを監視するモニタの検証を行うために用いるデータを作成する情報処理方法であって、
前記バスのプロトコル仕様を示すデータを保持する保持工程と、
前記モニタの検証期間中の全てのサイクルにおいて前記プロトコル仕様を満たすトランザクションを示す第１のデータを作成する第１の作成工程と、
前記モニタの検証期間中の所望のサイクルで前記プロトコル仕様を満たさないトランザクションを示す第２のデータを作成する第２の作成工程と
を備えることを特徴とする。
【発明の効果】
【００１１】
本発明の構成により、論理回路の検証を行うモニタの検証精度を十分にチェックすることができる。
【発明を実施するための最良の形態】
【００１２】
以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
【００１３】
図１は、本実施形態に係るシステムの機能構成とデータの流れを示す図である。
【００１４】
同図において１０１は、モニタ１０６が監視する対象のバス１０７（不図示の論理回路を構成するバスの１つ）の仕様に関する情報を保持しているバスプロトコル仕様データである。
【００１５】
このバスプロトコル仕様データ１０１はテストベクタ生成装置１０２に入力され、テストベクタ生成装置１０２は、入力されたバスプロトコル仕様データ１０１に基づいて正常プロトコルテストベクタ１０３、違反プロトコルテストベクタ１０４，１０５を生成する。正常プロトコルテストベクタ１０３とは、モニタ１０６の検証期間中の全てのサイクルにおいてプロトコル仕様を満たすトランザクションを示すものであり、違反プロトコルテストベクタ１０４，１０５とは、モニタ１０６の検証期間中の所望のサイクルでプロトコル仕様を満たさないトランザクションを示すものである。なお、それぞれのベクタについての詳細は後述する。
【００１６】
一方、バス１０７にはモニタ１０６が接続されており、モニタ１０６はバス１０７上のトランザクションを監視する。本実施形態では、このモニタ１０６の検証を行うために上記正常プロトコルテストベクタ１０３、違反プロトコルテストベクタ１０４，１０５に従ったトランザクションをバス１０７上に発生させる。
【００１７】
１０７は、モニタ１０６が接続されるバス、１０８は、バス１０７に対して各ベクタ１０３〜１０５に従ったトランザクションを入力として与えるとともに、各ベクタに対するモニタ１０６の反応をチェックするテストベンチである。
【００１８】
次に、テストベクタ生成装置１０２について説明する、テストベクタ生成装置１０２は、例えば一般のＰＣ（パーソナルコンピュータ）やＷＳ（ワークステーション）等のコンピュータでもって構成されているものであり、例えば図９に示すハードウェア構成を備える。図９は、テストベクタ生成装置１０２に適用可能なコンピュータのハードウェア構成を示すブロック図である。
【００１９】
９０１はＣＰＵで、ＲＡＭ９０２やＲＯＭ９０３に格納されているプログラムやデータを用いて、コンピュータ全体の制御を行うと共に、本コンピュータを適用したテストベクタ生成装置１０２が行う後述の各処理を実行する。
【００２０】
９０２はＲＡＭで、外部記憶装置９０６からロードされたプログラムやデータを一時的に記憶するためのエリア、Ｉ／Ｆ９０７を介して受信したプログラムやデータを一時的に記憶するためのエリア、ＣＰＵ９０１が各処理を実行する際に用いるワークエリア等、各種のエリアを適宜提供することができる。
【００２１】
９０３はＲＯＭで、本コンピュータを適用するテストベクタ生成装置１０２の設定データや、ブートプログラムなどを格納する。
【００２２】
９０４は操作部で、キーボードやマウスなどにより構成されており、操作者が操作することで、各種の指示をＣＰＵ９０１に対して入力することができる。
【００２３】
９０５は表示部で、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ９０１による処理結果を画像や文字などもでって表示することができる。
【００２４】
９０６は外部記憶装置で、ハードディスクドライブ装置に代表される大容量情報記憶装置であって、ここにＯＳ（オペレーティングシステム）や、本コンピュータを適用したテストベクタ生成装置１０２が行う後述の各処理をＣＰＵ９０１に実行させるためのプログラムやデータなどが保存されている。なお、このデータには、上記バスプロトコル仕様データ１０１も含まれている。よって、これらのプログラムやデータはＣＰＵ９０１による制御に従って適宜ＲＡＭ９０２にロードされ、ＣＰＵ９０１による処理対象となる。
【００２５】
９０７はＩ／Ｆで、上記テストベンチ１０８に接続されており、本コンピュータを適用したテストベクタ生成装置１０２が生成した正常プロトコルテストベクタ、違反プロトコルテストベクタのデータをテストベンチ１０８に送出する為のインターフェースとして機能する。
【００２６】
９０８は上述の各部を繋ぐバスである。
【００２７】
本実施形態では、このような構成を有するコンピュータをテストベクタ生成装置１０２に適用した場合について説明するが、テストベクタ生成装置１０２に適用可能なコンピュータの構成はこれに限定するものではない。
【００２８】
次に、テストベクタ生成装置１０２が、正常プロトコルテストベクタ、違反プロトコルテストベクタを生成するための処理について、同処理のフローチャートを示す図２を用いて以下説明する。なお、同図のフローチャートに従った処理をＣＰＵ９０１に実行させるためのプログラムやデータは外部記憶装置９０６に保存されており、これはＣＰＵ９０１による制御に従って適宜ＲＡＭ９０２にロードされ、ＣＰＵ９０１はこれを用いて処理を実行することで、テストベクタ生成装置１０２は以下説明する各処理を実行することになる。
【００２９】
先ず、外部記憶装置９０６に保存されているバスプロトコル仕様データ１０１をＲＡＭ９０２にロードする（ステップＳ２０１）。次に、このバスプロトコル仕様データ１０１を用いて、モニタ１０６の検証期間中の全てのサイクルにおいてプロトコル仕様を満たすトランザクションを示す正常プロトコルテストベクタ（同図では２０５）を生成する（ステップＳ２０２）。正常プロトコルテストベクタの生成処理の詳細については後述する。
【００３０】
次に、バスプロトコル仕様データ１０１を用いて、モニタ１０６の検証期間中の所望のサイクルでプロトコル仕様を満たさないような仕様（違反バスプロトコル仕様）を決定（作成）し（ステップＳ２０３）、決定した仕様に従ったトランザクションを示す違反プロトコルテストベクタ（同図では２０６〜２０８）を生成する（ステップＳ２０４）。
【００３１】
図３は、バスプロトコル仕様データ１０１の一例を示す図である。同図に示す如く、バスプロトコル仕様は、バス１０７上のアドレス、リード／ライトといった制御信号の定義（シグナル定義）と、その制御信号が１サイクル単位でとり得る状態の組み合わせ（１サイクル内で論理回路内で発生し得る制御信号の組み合わせ）で定義されるイベント定義、各イベントの発生順序を示したステート遷移定義、各ステート遷移間のタイミング定義により構成される。
【００３２】
ステート遷移定義については例えば、ＢＲＥＱ→［ＢＲＥＱ、ＢＧＮＴ、ＩＤＬＥ］は、ＢＲＥＱなるイベントの次にはＢＲＥＱ、ＢＧＮＴ、ＩＤＬＥなるイベントの何れかしか発生し得ないことを示す。よって、ＢＲＥＱなるイベントの次にＡＲＥＱなるイベントを発生させると、エラーとなる。
【００３３】
また、タイミング定義については例えば、ＢＲＥＱ→ＢＧＮＴ＜１００ｃｙｃｌｅは、イベントＢＧＮＴからイベントＢＧＮＴへの遷移は１００サイクル以内で遷移すべきものであることを示している。よって、イベントＢＧＮＴからイベントＢＧＮＴへの遷移を１００ｃｙｃｌｅ以上で行うと、エラーとなる。
【００３４】
このようにして、バスプロトコル仕様はこれらの形式で、バスの仕様として信号のとりえる全ての状態とその遷移条件、タイミング条件を保持する。
【００３５】
図４は、上記ステップＳ２０２における処理、即ち、正常プロトコルテストベクタの生成処理の詳細を示すフローチャートである。
【００３６】
先ず、バス１０７の初期状態を設定する為に、アイドルイベントをテストベクタに挿入する（ステップＳ４０１）。次に、操作者は操作部９０４を用いて「モニタ１０６の検証を行うサイクル数」を入力するので、ＣＰＵ９０１はこれを検知し、入力されたサイクル数をＲＡＭ９０２内に一時的に記憶する（ステップＳ４０２）。なお、サイクル数の指定方法については操作者が入力することに限定するものではなく、予め決めたものであっても良いし、ＣＰＵ９０１がランダムに設定するようにしても良い。
【００３７】
次に、ステップＳ４０２で入力されたサイクル数分だけイベントをテストベクタ（正常プロトコルテストベクタ）に挿入したのか否かを判断し（ステップＳ４０３）、未だステップＳ４０２で入力されたサイクル数分だけイベントをテストベクタに挿入していない場合には処理をステップＳ４０４に進め、イベント、ステート遷移定義、タイミング定義をランダムに発生させる（ステップＳ４０４）。
【００３８】
そしてステップＳ４０４で発生させたステート遷移定義が、バスプロトコル仕様データ１０１内に記述されたステート遷移定義に従ったものであるのかをチェックする（ステップＳ４０５）。
【００３９】
例えばステップＳ４０４で発生させたステート遷移定義がＢＲＥＱ→ＢＧＮＴであれば、バスプロトコル仕様データ１０１内に記述されたステート遷移定義に従ったものであると判断することができるが、ステップＳ４０４で発生させたステート遷移定義がＢＲＥＱ→ＡＲＥＱであれば、バスプロトコル仕様データ１０１内に記述されたステート遷移定義に従ったものではないと判断することができる。
【００４０】
よって、従ったものでない場合には処理をステップＳ４０４に戻し、再度、イベント、ステート遷移定義、タイミング定義を発生させる。なお、ステップＳ４０４で発生させたステート遷移定義が、バスプロトコル仕様データ１０１内に記述されたステート遷移定義に従ったものではない場合、イベント、ステート遷移定義、タイミング定義の全てを再度発生させずに、ステート遷移定義のみを再度発生させるようにしても良い。
【００４１】
一方、ステップＳ４０４で発生させたステート遷移定義が、バスプロトコル仕様データ１０１内に記述されたステート遷移定義に従ったものである場合には処理をステップＳ４０６に進め、ステップＳ４０４で発生させたタイミング定義が、バスプロトコル仕様データ１０１内に記述されたタイミング定義に従ったものであるのかをチェックする（ステップＳ４０６）。
【００４２】
例えばステップＳ４０４で発生させたタイミング定義がＢＲＥＱ→ＢＧＮＴ＜１００ｃｙｃｌｅであれば、バスプロトコル仕様データ１０１内に記述されたタイミング定義に従ったものであると判断することができるが、ステップＳ４０４で発生させたステート遷移定義がＢＲＥＱ→ＢＧＮＴ≧１００ｃｙｃｌｅであれば、バスプロトコル仕様データ１０１内に記述されたタイミング定義に従ったものではないと判断することができる。
【００４３】
よって、従ったものでない場合には処理をステップＳ４０４に戻し、再度、イベント、ステート遷移定義、タイミング定義を発生させる。なお、ステップＳ４０４で発生させたタイミング定義が、バスプロトコル仕様データ１０１内に記述されたタイミング定義に従ったものではない場合、イベント、ステート遷移定義、タイミング定義の全てを再度発生させずに、タイミング定義のみを再度発生させるようにしても良い。
【００４４】
一方、ステップＳ４０４で発生させたタイミング定義が、バスプロトコル仕様データ１０１内に記述されたタイミング定義に従ったものである場合には処理をステップＳ４０７に進め、ステップＳ４０４で発生させたイベントをテストベクタに挿入する（ステップＳ４０７）。そしてステップＳ４０３以降の処理を繰り返す。
【００４５】
このようにして、ステップＳ４０２で設定したサイクル数分だけイベントを含むテストベクタを生成することができる。そしてこのようにして生成されたテストベクタが正常プロトコルテストベクタとなる。
【００４６】
図５は、正常プロトコルテストベクタの一例を示す図である。同図に示す如く、正常プロトコルテストベクタ内には、イベントと共に、モニタ１０６の検証の際にバス１０７に対して与えられるバス１０７上の制御信号、書き込み／読み込みデータがサイクル毎に保持される。また、各サイクルにおけるバス上のプロトコル状態が期待値として挿入される。即ち、各サイクル毎に、対応するトランザクションを発生させた場合に処理結果がエラーであるのか否かを示すものを期待値として挿入している。
【００４７】
正常プロトコルテストベクタの場合、全てのサイクルでバスプロトコル仕様を満たしているため、全てのサイクルでNo violationが期待値として登録される。よって、モニタ１０６の検証の際にテストベンチ１０８により、正常プロトコルテストベクタに対するモニタ１０６の出力と、テストベクタの期待値とを比較することで、バスプロトコル仕様に対するモニタ１０６のチェックの妥当性が検証される。
【００４８】
図６は、違反バスプロトコル仕様の一例を示す図である。同図に示す如く、違反バスプロトコル仕様は、違反イベント定義、違反ステート遷移定義、違反タイミング定義により構成されている。違反イベント定義は、バスプロトコル仕様内のイベント定義で定義されている各イベントに含まれていない制御信号の組み合わせによるイベント（即ち、バスプロトコル仕様内のイベント定義には含まれ得ないイベント）を定義している。このようなイベントをバス１０７上に発生させ、モニタ１０６がこれを検知した場合には、不正信号入力として認識される。
【００４９】
また、違反ステート遷移定義は、バスプロトコル仕様内の各イベントが取りうるステート遷移定義以外のすべての組み合わせを示したもので、モニタ１０６がこのようなイベント遷移を検知した場合には、不正信号入力として認識される。
【００５０】
違反タイミング定義は、バスプロトコル仕様内のタイミング定義で示した条件を満たさないイベント遷移タイミング条件であり、モニタ１０６がこれらのタイミングでイベントの遷移が起こったことを検知した場合には、タイミング違反と認識される。
【００５１】
このような違反バスプロトコル仕様は、バスプロトコル仕様に記載された各定義から排他的に違反条件を抽出することで自動的に生成されるものである。
【００５２】
次に、違反プロトコルテストベクタの生成処理について説明する。図７は、違反プロトコルテストベクタの生成処理の模式図である。違反プロトコルテストベクタは、モニタ１０６の検証期間中の所望のサイクルでプロトコル仕様を満たさないトランザクションを発生させればよいので、任意のサイクルで違反プロトコルを配置すれば良い。ここで違反プロトコルとは、違反バスプロトコル仕様で定義された違反イベント、違反ステート遷移、違反タイミングの組み合わせである。
【００５３】
本実施形態では違反プロトコルテストベクタを生成する為には以下の３つの方法を用いる。
【００５４】
＜違反イベントへの置き換え＞
図７（ａ）の左側は正常プロトコルテストベクタで定義している各イベント、及びそれらの発生順を示している。ここで、ＡＲＥＱなるイベントの次にＡＡＣＫなるイベントを発生させることは正常なのであるが、同時右側に示す如く、ＡＡＣＫを、ＡＲＥＱなるイベントの次には発生し得ないイベント（図３の例ではＡＲＥＱ、ＡＡＣＫ以外のイベント）に置き換える（図７（ａ）の右側にＸＸＸＸで示すイベントに置き換える）ことにより、イベントの発生順が違反となる違反プロトコルテストベクタを生成することができる。
【００５５】
＜違反イベントの挿入＞
図７（ａ）に示す如く、ＡＲＥＱなるイベントの次にＡＡＣＫなるイベントを発生させることは正常なのであるが、図７（ｂ）に示す如く、ＡＲＥＱなるイベントの次には発生し得ないイベントＢＲＥＱ（即ち、図３の例ではＡＲＥＱ、ＡＡＣＫ以外のイベント）を、ＡＲＥＱの次に配置することにより、イベントの発生順が違反となる違反プロトコルテストベクタを生成することができる。
【００５６】
＜タイミング定義の置き換え＞
図７（ａ）に示す如く、ＡＲＥＱなるイベントからＡＡＣＫなるイベントへの遷移を２ｃｙｃｌｅで行うことは正常なのであるが、図７（ｃ）に示す如く、ＡＲＥＱなるイベントからＡＡＣＫなるイベントへの遷移のタイミングとしては許容し得ないタイミング（図３の例では２ｃｙｃｌｅよりも短いタイミング）を、ＡＲＥＱなるイベントからＡＡＣＫなるイベントへの遷移のタイミングとして設定することにより、イベントの遷移のタイミングが違反となる違反プロトコルテストベクタを生成することができる。
【００５７】
このようにして、様々な要素が違反となる違反プロトコルテストベクタを生成することができる。なお、以上の３つの方法で正常プロトコルテストベクタから変更する箇所、変更の内容については特に限定するものではなく、予め決まっていても良いし、ランダムに設定するようにしても良いし、操作者が操作部９０４を用いて設定するようにしても良い。また、上記３つの方法の何れを採用するのかについては予め決まっていても良いし、ランダムに決定しても良いし、操作者が操作部９０４を用いて設定するようにしても良い。
【００５８】
よって、上記ステップＳ２０４における違反プロトコルテストベクタの生成処理では、図６に例示するような違反バスプロトコル仕様を参照して、違反イベント、違反ステート遷移定義、違反タイミング定義の何れかを採用したものを用いて先に生成した正常プロトコルテストベクタに対して変更する。変更の内容は上記３つの方法の何れかを用いればよい。
【００５９】
ここで、バス上に違反プロトコルが発生した場合、それ以降のトランザクションは保証されなくなる為、１つの違反プロトコルテストベクタで検証できるモニタ１０６の検証項目は１つとなる。この為、違反プロトコル１つごとに違反プロトコルテストベクタを生成する。
【００６０】
図８は、違反プロトコルテストベクタの一例を示す図である。同図に示す如く、違反プロトコルテストベクタ内には、イベントと共に、モニタ１０６の検証の際にバス１０７に対して与えられるバス１０７上の制御信号、書き込み／読み込みデータがサイクル毎に保持される。また、各サイクルにおけるバス上のプロトコル状態が期待値として挿入される。即ち、各サイクル毎に、対応するトランザクションを発生させた場合に処理結果がエラーであるのか否かを示すものを期待値として挿入している。
【００６１】
同図の場合、１３３サイクル目において、ＡＲＥＱ→ＢＲＥＱの違反ステート遷移が挿入されているために、期待値にはState violationが登録される。よって、モニタ１０６の検証の際にテストベンチ１０８により、違反プロトコルテストベクタに対するモニタ１０６の出力と、テストベクタの期待値とを比較することで、違反バスプロトコル仕様に対するモニタ１０６のチェックの妥当性が検証される。
【００６２】
なお、以上説明したテストベンチ１０８の比較結果は、どのような報知方法でもって報知しても良いのであるが、例えば、表示部９０５に比較結果を表示するようにしても良い。
【００６３】
以上の説明により、本実施形態によって、バスを監視するモニタに対して、モニタ自身の検証をより短期間で、より厳しく検証することが可能となり、モニタの精度向上が図られる。
【００６４】
これにより、論理回路検証時のバスプロトコル違反のチェック漏れをなくし、実機検証段階での不具合発生を低減することが可能となる。これより設計品質の向上、しいては高品質な製品をより短期間で市場に投入することが可能となる。
【００６５】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【００６６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６７】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６８】
本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【図面の簡単な説明】
【００６９】
【図１】本発明の実施形態に係るシステムの機能構成とデータの流れを示す図である。
【図２】テストベクタ生成装置１０２が、正常プロトコルテストベクタ、違反プロトコルテストベクタを生成するための処理のフローチャートである。
【図３】バスプロトコル仕様データ１０１の一例を示す図である。
【図４】ステップＳ２０２における処理、即ち、正常プロトコルテストベクタの生成処理の詳細を示すフローチャートである。
【図５】正常プロトコルテストベクタの一例を示す図である。
【図６】違反バスプロトコル仕様の一例を示す図である。
【図７】違反プロトコルテストベクタの生成処理の模式図である。
【図８】違反プロトコルテストベクタの一例を示す図である。
【図９】テストベクタ生成装置１０２に適用可能なコンピュータのハードウェア構成を示すブロック図である。
【図１】
2006268194.tif 000003
【図２】
2006268194.tif 000004
【図３】
2006268194.tif 000005
【図４】
2006268194.tif 000006
【図５】
2006268194.tif 000007
【図６】
2006268194.tif 000008
【図７】
2006268194.tif 000009
【図８】
2006268194.tif 000010
【図９】
2006268194.tif 000011