検証方法及び検証プログラム
【課題】回路検証に用いるシナリオ等のプログラムを効率的に開発する。
【解決手段】コンピュータが、検証対象に対する命令を記述したシナリオ（Ｓ６５）の所定記述部分の命令実行を制限する制限情報を含んだ設定制限リスト（Ｓ６７）を用い、その内容を示すシナリオチェッカ（Ｓ６９）を生成する。コンピュータは、検証対象のシミュレーション（Ｓ７４）において、シナリオ（Ｓ６５）の上記所定記述部分の命令実行時に、シナリオチェッカ（Ｓ６９）を用いて当該命令が制限情報を含むか否かチェックし、その結果（Ｓ７５）を出力する。
【解決手段】コンピュータが、検証対象に対する命令を記述したシナリオ（Ｓ６５）の所定記述部分の命令実行を制限する制限情報を含んだ設定制限リスト（Ｓ６７）を用い、その内容を示すシナリオチェッカ（Ｓ６９）を生成する。コンピュータは、検証対象のシミュレーション（Ｓ７４）において、シナリオ（Ｓ６５）の上記所定記述部分の命令実行時に、シナリオチェッカ（Ｓ６９）を用いて当該命令が制限情報を含むか否かチェックし、その結果（Ｓ７５）を出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、回路検証に用いる検証方法及び検証プログラムに関する。
【背景技術】
【０００２】
ＬＳＩ（Large Scale Integration）等の集積回路の開発では、設計仕様を基にレジスタ・トランスファ・レベル（ＲＴＬ）と呼ばれる論理式を用いて回路の論理を表現する。このＲＴＬで設計された回路の機能、動作を検証するために、コンピュータを用いたシミュレーションが行われる。
【０００３】
検証時には、検証対象の回路に対する命令の手順を記述したシナリオをテストベンチに組み込み、そのテストベンチを用いて検証対象のシミュレーションを行う。そして、その検証対象の回路からの出力について、仕様違反や規格違反等のエラーを起こしていないかチェックする。このような回路の検証に用いられるシナリオやテストベンチは、回路の検証に先立ち、或いは回路の検証と並行して、開発される。
【０００４】
また、回路を制御するためのファームウェアを設計し、ファームウェアを用いて回路を動作させ、ファームウェアがその回路を正しく制御しているかを確認する技術等も知られている。
【０００５】
このほか、ランダムに並べたテストシーケンスを含むシナリオを用いたランダムテストで回路を検証する際に、シミュレーションによって実際にテストされた検証項目を確認するための手法等も知られている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−８６８３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、シナリオを組み込んだテストベンチを用いて検証対象の検証を行う場合、検出されるエラーは、検証対象が原因である場合のほか、テストベンチの開発段階ではそのテストベンチ、例えば組み込まれているシナリオが原因である場合もある。シナリオが原因である場合には、例えば、シミュレーション時の波形データを用いて、エラーを引き起こしたシナリオの命令箇所を特定する。しかし、エラーの発生タイミングとそのエラーを引き起こしたシナリオの命令タイミングには時間差があるため、エラーを引き起こしたシナリオの原因箇所を特定する作業が複雑になり、エラー原因の解析に長時間を要してしまうことがある。
【０００８】
一方、上記のような検証に用いるシナリオの開発段階では、検証対象の設計仕様書に基づき、一定条件の場合の命令実行を制限する制限事項を考慮してシナリオを作成し、それを組み込んだテストベンチを用いてシミュレーションが行われる。このシミュレーション時の波形データを目視確認することで、シナリオの動作が検証される。しかし、このような波形データの目視確認には長時間を要してしまうことがある。更に、シナリオに基づく検証対象への入力命令の数が膨大になると、それら全てについて波形データの目視確認で検証を行うことは難しくなる。このようにして検証されなかった命令や、制限事項が適正に考慮されていない命令が、上記のようなシナリオが原因のエラーを発生させる一因にもなっている。
【０００９】
ここではシナリオを例にしたが、回路を制御するファームウェアでも同様に、その開発段階では、作成したファームウェアを用いて回路（検証対象）を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラーの原因が検証対象の回路側にあるのか、それを制御するファームウェア側にあるのかの判定に時間がかかってしまう。エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。
【課題を解決するための手段】
【００１０】
本発明の一観点によれば、コンピュータが実行する検証方法であって、検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、前記チェックの結果を示す結果情報を生成する検証方法が提供される。
【００１１】
また、本発明の一観点によれば、このような検証方法を実現するための処理をコンピュータに実行させる検証プログラムが提供される。
【発明の効果】
【００１２】
開示の技術によれば、シナリオやファームウェア等のプログラムを、当該プログラムの実行時にチェッカを用いてチェックし、そのチェックの結果から検証することが可能になる。それにより、当該プログラムの検証時や、当該プログラムを用いた検証時に、波形データの取得、取得した波形データの目視確認作業を不要にすることが可能になる。適正なシナリオやファームウェア等のプログラムを、効率的に開発することが可能になり、当該プログラムを用いた検証作業を効率的に行うことが可能になる。
【図面の簡単な説明】
【００１３】
【図１】論理シミュレーション環境の一例を示す図である。
【図２】検証作業フローの一例を示す図である。
【図３】テストベンチ開発作業フローの一例を示す図（その１）である。
【図４】テストベンチ開発段階でのテストベンチの構成例を示す図（その１）である。
【図５】シナリオ要因のエラー発生例を示す図である。
【図６】シナリオ開発作業フローの一例を示す図（その１）である。
【図７】シナリオ開発段階でのテストベンチの構成例を示す図（その１）である。
【図８】シナリオ開発作業フローの一例を示す図（その２）である。
【図９】シナリオ開発段階でのテストベンチの構成例を示す図（その２）である。
【図１０】テストベンチ開発作業フローの一例を示す図（その２）である。
【図１１】テストベンチ開発段階でのテストベンチの構成例を示す図（その２）である。
【図１２】設定制限リストのフォーマットの一例を示す図である。
【図１３】第１実施例に係る検証対象とシナリオの関係を示す図である。
【図１４】第１実施例に係る設定制限事項の一例を示す図である。
【図１５】第１実施例に係るシナリオの記述部分の一例を示す図である。
【図１６】設定制限リストの作成方法を示す図（その１）である。
【図１７】設定制限リストの作成方法を示す図（その２）である。
【図１８】設定制限リストの作成方法を示す図（その３）である。
【図１９】設定制限リストの作成方法を示す図（その４）である。
【図２０】シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す図である。
【図２１】第１実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。
【図２２】第１実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。
【図２３】第１実施例に係るログファイルの出力例である。
【図２４】第２実施例に係る設定制限事項の一例を示す図である。
【図２５】第２実施例に係るシナリオの記述部分の一例を示す図である。
【図２６】第２実施例に係る設定制限リストの一例を示す図である。
【図２７】第２実施例に係るシナリオチェッカの一例を示す図である。
【発明を実施するための形態】
【００１４】
ＬＳＩ開発では、設計仕様を基にＲＴＬで設計された論理回路の機能、動作を、コンピュータを用いた論理シミュレーションを行って検証する。
図１に論理シミュレーション環境の一例を示す。
【００１５】
論理シミュレーション環境は、コンピュータ１００を用いて構築される。コンピュータ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御される。ＣＰＵ１０１には、バス１１０を介して、ＲＯＭ（Read Only Memory）１０２及びＲＡＭ（Random Access Memory）１０３が接続される。ＲＯＭ１０２には、シミュレーションを行う論理回路を制御するファームウェア等のプログラムが格納される。ＲＡＭ１０３には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０３には、ＣＰＵ１０１による処理に必要な各種データが格納される。
【００１６】
バス１１０には、複数の周辺機器が接続される。バス１１０に接続される周辺機器としては、ハードディスクドライブ（Hard Disk Drive；ＨＤＤ）１０４、通信インタフェース１０５、キーボード１０６、マウス１０７等がある。
【００１７】
ＨＤＤ１０４は、ハードディスク（Hard Disk；ＨＤ）１０４ａに対して磁気的にデータの書き込み及び読み出しを行う。ＨＤＤ１０４には、ＯＳのプログラム、アプリケーションプログラム、及び各種データが格納される。通信インタフェース１０５は、ネットワークに接続され、ネットワークを介して、他のコンピュータ又は通信機器との間でデータの送受信を行う。また、キーボード１０６やマウス１０７から送られてくる信号は、バス１１０を介してＣＰＵ１０１に送信される。尚、マウス１０７は、ポインティングデバイスの一例であり、タッチパネル、タブレット、タッチパッド、トラックボール等、他のポインティングデバイスを用いることも可能である。
【００１８】
バス１１０には、更に、その他の周辺機器１０８が接続されていてもよい。その他の周辺機器１０８としては、例えば、グラフィック処理装置や光学ドライブ装置等が挙げられる。この場合、グラフィック処理装置には、モニタ（ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置等）が接続され、グラフィック処理装置は、ＣＰＵ１０１からの命令に従って、画像をモニタの画面に表示させる。また、光学ドライブ装置は、レーザ光等を利用して、光ディスク（ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等）に記録されたデータの読み取りを行う。
【００１９】
このような構成を有するコンピュータ１００の、例えばＨＤ１０４ａに、ＲＴＬの論理回路（検証対象）の設計データ１２０、論理シミュレータ１３０、ＲＴＬの論理回路に対する命令を記述したシナリオを組み込んだテストベンチ１４０等が格納される。コンピュータ１００は、ＨＤＤ１０４を駆動し、ＨＤ１０４ａに格納されたこれらの情報を用いて、検証対象である論理回路の論理シミュレーションを実行する。この論理シミュレーションの結果に基づき、論理回路の機能、動作が適正か否かが検証される。
【００２０】
次に、論理シミュレーションを用いた検証作業の一例について説明する。
図２は検証作業フローの一例を示す図である。
論理シミュレーションを行う検証作業では、まず、検証対象である論理回路の仕様書（設計仕様書）（Ｓ１０）を基に、検証仕様書が作成される（Ｓ１１，Ｓ１２）。そして、作成された検証仕様書からテストベンチの構成が検討され、テストベンチ仕様書が作成される（Ｓ１３，Ｓ１４）。このテストベンチ仕様書を基に、テストベンチの開発が行われる（Ｓ１５，Ｓ１６）。開発されたテストベンチを用いて論理シミュレーション（検証作業）が行われ、その結果（検証結果）が取得される（Ｓ１７，Ｓ１８）。論理シミュレーションで得られる検証結果から、検証対象の論理回路が適正に動作するか否かが、開発者或いはコンピュータ１００によって、判定される。
【００２１】
更にテストベンチ開発（Ｓ１５，Ｓ１６）に着目して説明する。
図３はテストベンチ開発作業フローの一例を示す図である。
図３のテストベンチ開発作業フローでは、開発者が、テストベンチ仕様書（Ｓ２０）から更にテストベンチの構成要素となる部品（モデル）毎の仕様を設定し、部品毎に開発を行う（Ｓ２１〜Ｓ２３）。図３の例では、チェッカの開発（Ｓ２１）、トランザクタの開発（Ｓ２２）、シナリオの開発（Ｓ２３）を行っている。そして、各部品について単体テストを実施し、問題がないことを確認して、各部品を取得する（Ｓ２４）。このようにして取得された各部品を、検証対象の論理回路と共に組み上げることで（Ｓ２５）、テストベンチ（論理回路を含むシミュレーションの全体環境）を取得する（Ｓ２６）。
【００２２】
テストベンチ開発段階でのテストベンチの構成例を図４に示す。
図４のテストベンチ２００は、部品として、シナリオ２１１及びトランザクタ２１２を含むモデル２１０、プロトコルチェッカ２２０、及び期待値比較チェッカ２３０を備えている（テストベンチ開発環境）。
【００２３】
シナリオ２１１には、ＲＴＬで設計された検証対象３００の論理回路に対する命令の手順が記述されている。シナリオ２１１は、トランザクタ２１２の仕様に合わせ、トランザクタ２１２に対し、検証対象３００を制御する（動作させる）命令を与える。
【００２４】
トランザクタ２１２は、シナリオ２１１からの命令に従い、検証対象３００との間のインタフェース仕様に合わせて信号を制御し、シナリオ２１１からの命令の情報を検証対象３００に伝える。検証対象３００は、このトランザクタ２１２からの情報を受けて、その情報が示す命令の動作を実行する。また、トランザクタ２１２は、検証対象３００から送られてくる情報を受信し、受信した情報をシナリオ２１１へ通知する。
【００２５】
プロトコルチェッカ２２０は、プロトコルが存在するインタフェースに対し、関連する入出力端子を参照し、プロトコルに特化したチェックを行う。プロトコルチェッカ２２０は、プロトコル違反を検出した場合、エラーを報告する。
【００２６】
期待値比較チェッカ２３０は、検証対象３００の入出力端子を参照し、検証対象３００の出力端子（データ値、信号制御等）が設計仕様通り動作しているかのチェックを行う。期待値比較チェッカ２３０は、設計仕様違反を検出した場合、エラーを報告する。
【００２７】
図３のテストベンチ開発作業フローにおいて、このような構成を有するテストベンチを取得（Ｓ２６）した後は、コンピュータを用い、テストベンチで検証対象の論理回路を動作させ、最終的な動作確認テスト（全体シミュレーション）を行う（Ｓ２７）。この全体シミュレーションの結果（テストベンチに組み込まれたチェッカによるチェック結果）は、ログファイルとして出力される（Ｓ２８）。このログファイルの情報から開発者がエラーの発生有無を判断する（Ｓ２９）。エラーが発生している場合、そのエラー要因を特定するために波形データが必要になる。この波形データを取得する目的で、コンピュータを用いた再シミュレーションを行う（Ｓ３０，Ｓ３１）。取得した波形データを開発者が目視で確認し、エラー要因を特定する（Ｓ３２）。エラー要因は、まず、検証対象の論理回路側にある場合と、テストベンチ側にある場合の２つに分けられる（Ｓ３３）。
【００２８】
エラー要因が検証対象の論理回路側にある場合には（Ｓ３３）、開発者が、ＲＴＬで設計されたその論理回路の修正を行い（Ｓ３４）、修正後の論理回路を作成し（Ｓ３５）、修正後の論理回路と共に、再度テストベンチを取得する（Ｓ２５，Ｓ２６）。そして、その再取得したテストベンチを用いて全体シミュレーション（Ｓ２７）以降の作業を実施する。
【００２９】
一方、エラー要因がテストベンチ側にある場合（Ｓ３３）、エラー要因は、テストベンチ内のシナリオ、トランザクタ、チェッカ等の部品の、少なくともいずれかに存在している（Ｓ３６）。例えば、図４のテストベンチ２００の場合、シナリオ２１１、トランザクタ２１２、プロトコルチェッカ２２０、期待値比較チェッカ２３０のいずれかにエラー要因が存在する。
【００３０】
シナリオにエラー要因（シナリオミス）がある場合には（Ｓ３６）、シナリオ開発（Ｓ２３）に戻り、シナリオのエラー要因を修正する。トランザクタにエラー要因（トランザクタミス）がある場合には（Ｓ３６）、トランザクタ開発（Ｓ２２）に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因（チェッカミス）がある場合には（Ｓ３６）、チェッカ開発（Ｓ２１）に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し（Ｓ２４）、テストベンチを取得（Ｓ２５，Ｓ２６）して、全体シミュレーション（Ｓ２７）以降の作業を実施する。
【００３１】
全体シミュレーションでエラーが検出されず（Ｓ２９）、更に異なる条件で全体シミュレーション（テスト）を行う場合には（Ｓ３７）、シミュレーション条件を変更してテストを行う（Ｓ２７）。エラーなく全てのテストが終了すれば（Ｓ３７）、テストベンチ開発作業は終了となる。開発したテストベンチを用いて、上記図２の論理シミュレーション（検証作業）が行われる（Ｓ１７，Ｓ１８）。
【００３２】
テストベンチは、例えば上記図３のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図３の作業フローでは、全体シミュレーションの結果（Ｓ２７，Ｓ２８）、チェッカによりエラーが検出された場合（Ｓ２９）、再シミュレーションで波形データが取得され（Ｓ３０，Ｓ３１）、その目視確認が行われる（Ｓ３２）。
【００３３】
開発済みの適正なテストベンチが用いられている場合、チェッカがエラーを検出すれば、検証対象の論理回路側に問題があると判断できる。しかし、テストベンチの開発段階では、チェッカ自体が適正であるか否かが確定しておらず、その品質に問題が残っているため、検出されたエラーがチェッカ自体のミスによるものである可能性がある。更に、テストベンチの開発段階では、シナリオに問題がある場合も、チェッカによりエラーとして検出されてくる。このようにエラーの要因がシナリオにある場合、その要因の特定には時間がかかる。その理由を、次の図５を参照して説明する。
【００３４】
図５はシナリオ要因のエラー発生例を示す図である。図５において、（Ａ）はテストベンチの一例、（Ｂ），（Ｃ）は波形データの一例である。
まず、チェッカがエラーを検出するのは、検証対象の出力端子が仕様違反、規格違反した動作に対してであり、検証対象の出力動作は入力パターンで決まる。つまり、検証対象への入力パターン（シナリオの命令）にミスがあると、チェッカによってエラーが検出される。
【００３５】
今、図５（Ａ）のテストベンチ２００における一方のモデル２１０ａのシナリオ２１１ａに従い、図５（Ｂ）のような入力パターン（出力信号１，２）がトランザクタ２１２ａを介して検証対象３００に出力されたものとする。そして、その入力パターンに基づき、検証対象３００からは、図５（Ｃ）のような出力（出力信号１，２）が得られ、その出力がもう一方のモデル２１０ｂ（シナリオ２１１ｂ、トランザクタ２１２ｂ）に送られるものとする。この検証対象３００からの出力に対し、Ｂプロトコルチェッカ２２０ｂがＸ部にエラーを検出したものとする。即ち、この例では、Ｂプロトコルチェッカ２２０ｂが、出力のＸ部における、クロックの立ち上がりで出力信号１，２が共にハイ（Ｈ）レベルとなるエラーを検出する。このＢプロトコルチェッカ２２０ｂで検出されたエラーは、シナリオ２１１ａからの入力パターンにおける、Ｙ部の入力パターンミスが根本原因になっている。
【００３６】
このように、検証対象３００の出力についてＢプロトコルチェッカ２２０ｂで検出されるエラー要因が、検証対象３００に対する入力パターンにあると、エラーの検出ポイント（Ｘ部）と、その要因となる入力パターン（Ｙ部）の間には、時間差Ｔが生じる。エラー要因がシナリオ２１１ａにあり、その要因を波形データから特定しようとすると、この時間差Ｔのために、解析が複雑になる場合があり、解析に長時間を要してしまう場合もある。
【００３７】
尚、このような課題に対し、検証対象３００への入力パターンの制約違反のチェックを行うチェッカを開発することも考えられる。例えば、Ａプロトコルチェッカ２２０ａに検証対象３００への入力パターンをチェックするアサーションを実装することで、課題の改善には繋がる。しかし、チェッカ開発工数が増える、チェッカ開発が完了しないとチェックが行えない等、根本的な解決には至らない。
【００３８】
シナリオは、例えば次のような作業フローで開発されている。
図６はシナリオ開発作業フローの一例を示す図である。
図６のシナリオ開発作業フローでは、開発者が、検証対象の設計に用いる仕様書（Ｓ４０）を基に、シナリオの仕様の検討を行い（Ｓ４１）、シナリオに設定する設定手順（Ｓ４２）、シナリオを設定するうえでの制限事項（設定制限事項）（Ｓ４３）を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成し（Ｓ４４，Ｓ４５）、それを組み込んだテストベンチを取得する（Ｓ４６，Ｓ４７）。そして、取得したテストベンチの動作確認のため、コンピュータを用いてシミュレーションを行い（Ｓ４８）、その結果（波形データ）を取得する（Ｓ４９）。
【００３９】
シナリオ開発段階でのテストベンチの構成例を図７に示す。
シナリオ開発段階のシミュレーション（Ｓ４８）に用いるテストベンチ２００Ａは、検証対象３００、その検証対象３００を動作させる、シナリオ２１１及びトランザクタ２１２を含むモデル２１０を備えている（シナリオ開発環境）。
【００４０】
シナリオ開発環境には、検証対象の入出力をチェックする機能が設けられていない。そのため、シミュレーション時（Ｓ４８）には、波形データを取得し（Ｓ４９）、その波形データを目視確認することで（Ｓ５０）、シナリオの動作を確認する。動作確認の結果、シナリオに問題が見つかった場合には、修正したシナリオを作成し（Ｓ４４，Ｓ４５）、それを組み込んだテストベンチを取得して（Ｓ４６，Ｓ４７）、再度シミュレーションを行い（Ｓ４８，Ｓ４９）、その波形データを確認する（Ｓ５０）。動作確認でシナリオに問題がなく（Ｓ５０）、更に異なる条件でシミュレーション（テスト）を行う場合には（Ｓ５１）、シミュレーション条件を変更してテストを行う（Ｓ４８）。エラーなく全てのテストが終了すれば（Ｓ５１）、シナリオ開発作業は終了となる。
【００４１】
シナリオは、例えば上記図６のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図６の作業フローでは、シナリオの動作確認を、シミュレーション時（Ｓ４８）に取得した波形データ（Ｓ４９）の目視確認によって行っている（Ｓ５０）。
【００４２】
シナリオは、検証対象の状態やその受信状態よって、生成する入力パターンが変わるため、組み合わせを考慮すると、膨大な入力パターンが存在し得る。それら全ての組み合わせについて、波形データを目視で確認し、シナリオの動作確認を行うことは、困難である。そのため、組み合わせを考慮しない、機能毎の動作確認までしか行わない場合もある。
【００４３】
このようにしてシナリオの動作確認を行い、その開発作業を完了させたとしても、全入力パターンの動作確認が済んでいるわけではないため、シナリオが設定制限事項に違反した入力パターンを生成してしまう等、その後の工程に影響を及ぼしてしまう場合がある。例えば、上記図３のテストベンチ開発作業フローで述べた全体シミュレーション（Ｓ２７，Ｓ２８）、更にその結果に基づく再シミュレーション（Ｓ２９〜Ｓ３１）において、上記のようなシナリオ要因の問題が発生してしまう場合がある。
【００４４】
以上説明したように、検証対象の論理回路検証に用いるシナリオの開発（及びシナリオを組み込んだテストベンチの開発）においては、検証の早い段階で、適正な、安定した品質のシナリオを取得することが難しい。適正なシナリオを取得するために、開発中のシナリオ、テストベンチを実際に動作させたときの波形データを取得し、それを開発者が目視で確認する作業が必要になるため、開発に時間を要してしまう。
【００４５】
また、以上の説明では、シナリオ（及びシナリオを組み込んだテストベンチ）の開発を例にしたが、論理回路を制御するファームウェアの開発においても同様のことが起こり得る。
【００４６】
即ち、ファームウェアの開発段階では、作成したファームウェアを用いて論理回路を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラー要因が論理回路側にあるのか、ファームウェア側にあるのかの判定に時間がかかってしまう。これは、上記図５において述べたのと同様に、エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。このように論理回路を制御するためのファームウェアでも、その動作確認に時間を要してしまい、論理回路検証の早い段階で、適正な、安定した品質のファームウェアを取得することが難しい。
【００４７】
シナリオ、ファームウェアのいずれの場合においても、それらを実際に動作させたときに取得される波形データの目視確認を行うことが、それらの開発効率を低下させ、更に、検証対象である論理回路の検証作業効率を低下させる一因になっている。
【００４８】
そこで以下では、このような波形データの目視確認によらずに、適正なシナリオ、ファームウェアを効率的に取得する手法について、詳細に説明していく。ここでは主にシナリオを例に説明する。
【００４９】
図８はシナリオ開発作業フローの一例を示す図である。
図８のシナリオ開発作業フローでは、上記図６で述べた作業フロー同様、まず開発者が、検証対象の設計に用いる仕様書（Ｓ６０）を基に、シナリオの仕様の検討を行い（Ｓ６１）、シナリオの設定手順（Ｓ６２）、シナリオの設定制限事項（Ｓ６３）を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成する（Ｓ６４，Ｓ６５）。
【００５０】
シナリオの作成後、この図８のシナリオ開発作業フローでは、開発者が、シナリオの仕様検討時に抽出した設定制限事項（Ｓ６３）、及び作成したシナリオ（Ｓ６５）を基に、設定制限リストを作成する（Ｓ６６，Ｓ６７）。設定制限リストには、例えば、作成したシナリオの所定記述部分の命令実行を制限する、上記設定制限事項の内容に対応した情報（制限情報）や、その記述部分に対応する所定行番号等の情報が含まれる。尚、設定制限リストの詳細については後述する。
【００５１】
そして、コンピュータを用い、このような設定制限リスト（Ｓ６７）を入力とし、シナリオの動作をチェックするためのシナリオチェッカを自動生成する（Ｓ６８，Ｓ６９）。コンピュータは、例えば、設定制限リスト（Ｓ６７）の内容を、シナリオと同じ言語を用いて、所定記述のシナリオチェッカに書き換える。シナリオチェッカは、例えば、上記したシナリオの所定記述部分の命令が実行されるときに、その命令が上記制限情報を含むか否か、即ち、命令（入力パターン）が設定制限事項に違反していないかをチェックする。尚、この点の詳細については後述する。
【００５２】
設定制限リスト（Ｓ６７）は、このシナリオチェッカの生成のほか（Ｓ６８，Ｓ６９）、シナリオへのシナリオチェッカ組み込み処理に用いられる（Ｓ７０，Ｓ７１）。コンピュータは、例えば、設定制限リスト（Ｓ６７)に示された、上記したシナリオの所定記述部分に対応した行番号を基に、シナリオのその行番号の箇所に、生成したシナリオチェッカ（Ｓ６９）を呼び出すための命令文を挿入する（Ｓ７０）。これにより、当該所定記述部分の命令実行時に、生成されたシナリオチェッカ（Ｓ６９）を呼び出し可能にしたシナリオが取得される（Ｓ７１）。尚、この点の詳細については後述する。
【００５３】
開発者は、このようにして取得されたシナリオチェッカ（Ｓ６９）と、そのシナリオチェッカ（Ｓ６９）を所定記述部分で呼び出し可能なシナリオ（Ｓ７１）とを組み込んだテストベンチを取得する（Ｓ７２，Ｓ７３）。
【００５４】
シナリオ開発段階でのテストベンチの構成例を図９に示す。
シナリオ開発段階のテストベンチ２００Ａは、検証対象３００、その検証対象３００を駆動するモデル２１０であるシナリオ２１１及びトランザクタ２１２を備えている（シナリオ開発環境）。このシナリオ２１１に、シナリオチェッカ２１３が、所定記述部分で呼び出されるように組み込まれている。
【００５５】
シナリオ２１１に従って検証対象３００を動作させると、シナリオ２１１の当該所定記述部分でシナリオチェッカ２１３が呼び出される。呼び出されたシナリオチェッカ２１３は、シナリオ２１１からの命令（入力パターン）に上記制限情報が含まれていないか、即ち、設定制限事項に違反した入力パターンが生成されていないか、チェックする。このようなチェックが、続く、コンピュータを用いたシミュレーション（Ｓ７４）によって行われる。
【００５６】
即ち、取得したテストベンチの動作確認のため、コンピュータを用いたシミュレーションが行われ（Ｓ７４）、コンピュータが、そのシミュレーション結果の情報（ログファイル）を生成する（Ｓ７５）。ここで生成されるシミュレーション結果の情報は、テストベンチにシナリオチェッカが組み込まれているため、シナリオチェッカでエラーを検出したか否かを示すログファイルとなる。上記図６で述べた作業フローにおけるように、シミュレーション結果として、必ずしも波形データを取得することを要しない。
【００５７】
開発者は、シミュレーション結果のログファイルの情報を基に、シナリオから検証対象に対し、設定制限事項に違反しない、適正な命令（入力パターン）が入力されたか否かを判断することができ、そのシナリオの動作確認を行うことができる（Ｓ７６）。従って、シナリオの動作確認のために、上記のような波形データの目視確認を行うことが不要になり、シナリオの動作確認を効率的に行うことができる。
【００５８】
作成したシナリオの動作確認の結果、エラーが検出された場合には、修正したシナリオを作成する（Ｓ６４，Ｓ６５）。そして、上記同様、設定制限リストの作成（Ｓ６６，Ｓ６７）、シナリオチェッカの生成（Ｓ６８，Ｓ６９）及び組み込み（Ｓ７０，Ｓ７１）を行い、テストベンチを取得して（Ｓ７２，Ｓ７３）、再度シミュレーションを行う（Ｓ７４，Ｓ７５）。そのログファイルの情報から、修正したシナリオの動作確認を行う（Ｓ７６）。
【００５９】
動作確認でエラーが検出されず（Ｓ７６）、更に異なる条件でシミュレーション（テスト）を行う場合には（Ｓ７７）、シミュレーション条件を変更してテストを行う（Ｓ７４）。エラーなく全てのテストが終了すれば（Ｓ７７）、シナリオ開発作業は終了となる。
【００６０】
更に、シナリオ開発後の工程について説明する。
図１０はテストベンチ開発作業フローの一例を示す図である。
図１０のテストベンチ開発作業フローでは、上記図３で述べた作業フロー同様、開発者が、テストベンチ仕様書（Ｓ８０）を基に、テストベンチの構成要素の部品毎に、チェッカの開発（Ｓ８１）、トランザクタの開発（Ｓ８２）、シナリオの開発（Ｓ８３，Ｓ６０〜Ｓ７７）を行う。そして、テスト済みの各部品を取得し（Ｓ８４）、それらを組み込んだテストベンチを取得する（Ｓ８５，Ｓ８６）。
【００６１】
テストベンチ開発段階でのテストベンチの構成例を図１１に示す。
図１１のテストベンチ２００は、シナリオ２１１及びトランザクタ２１２を含むモデル２１０、プロトコルチェッカ２２０、及び期待値比較チェッカ２３０を備えている（テストベンチ開発環境）。このシナリオ２１１に、シナリオチェッカ２１３が組み込まれている。
【００６２】
シナリオ開発（図９）で用いられたシナリオチェッカは、シナリオに組み込まれた構成（呼び出し可能な構成）になっており、テストベンチ開発のテストベンチにおいてもそのまま用いることができる。このようなテストベンチ（Ｓ８６）を用いて、上記図３で述べた作業フロー同様、検証対象の論理回路を動作させる全体シミュレーションを行う（Ｓ８７）。この全体シミュレーションの結果は、テストベンチに組み込まれたチェッカ（プロトコルチェッカ、期待値比較チェッカ、シナリオチェッカ）によるチェック結果のログファイルとして出力される（Ｓ８８）。このログファイルの情報から開発者がエラーの発生有無を判断する（Ｓ８９）。
【００６３】
ここで、シナリオチェッカによりエラーが検出されている場合には（Ｓ８９）、シナリオ開発（Ｓ８３）に戻り、シナリオのエラー要因を修正する。ここではシナリオチェッカを設けているため、このように全体シミュレーション（Ｓ８７）のログファイルの結果確認段階で、シナリオのエラー（シナリオミス）を検出することが可能になっている。そのため、検証の比較的早い段階でシナリオの修正を行い、適正なシナリオを作成することができる。また、この時点でシナリオチェッカのエラーがなく、その他のチェッカエラーが検出されていれば、そのエラー要因が、検証対象か、テストベンチのシナリオ以外の部品にあると判断することができる。
【００６４】
シナリオ以外についてのエラーが検出されている場合には（Ｓ８９）、コンピュータを用いた再シミュレーションを行って波形データを取得する（Ｓ９０，Ｓ９１）。取得した波形データを開発者が目視で確認し、エラー要因を特定する（Ｓ９２）。
【００６５】
エラー要因が検証対象の論理回路側にある場合には（Ｓ９３）、開発者が、その論理回路の修正を行い（Ｓ９４）、修正後の論理回路を作成し（Ｓ９５）、修正後の論理回路と共に、再度テストベンチを取得する（Ｓ８５，Ｓ８６）。そして、その再取得したテストベンチを用いて全体シミュレーション（Ｓ８７）以降の作業を実施する。
【００６６】
エラー要因がテストベンチ側にある場合、エラー要因は、テストベンチ内のトランザクタ又はチェッカに分けられる（Ｓ９６）。トランザクタにエラー要因（トランザクタミス）がある場合には（Ｓ９６）、トランザクタ開発（Ｓ８２）に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因（チェッカミス）がある場合には（Ｓ９６）、チェッカ開発（Ｓ８１）に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し（Ｓ８４）、テストベンチを取得（Ｓ８５，Ｓ８６）して、全体シミュレーション（Ｓ８７）以降の作業を実施する。
【００６７】
全体シミュレーションでエラーが検出されず（Ｓ８９）、更に異なる条件で全体シミュレーション（テスト）を行う場合には（Ｓ９７）、シミュレーション条件を変更してテストを行う（Ｓ８７）。エラーなく全てのテストが終了すれば（Ｓ９７）、テストベンチ開発作業は終了となる。
【００６８】
このように、シナリオにシナリオチェッカを組み込むことで、シナリオ開発及びテストベンチ開発において、シナリオミスについては、シミュレーションによる波形データの取得、取得した波形データの目視確認を不要にすることができる。それにより、適正なシナリオを比較的早期に作成することができ、シナリオ開発を効率化し、更に、テストベンチ開発、論理回路検証の効率化を図ることができる。
【００６９】
上記図８のシナリオ開発作業フローには、上記図６の作業フローと異なり、設定制限リストの作成（Ｓ６６，Ｓ６７）、シナリオチェッカの生成（Ｓ６８，Ｓ６９）、シナリオチェッカの組み込み（Ｓ７０，Ｓ７１）、ログファイルの確認（Ｓ７５，Ｓ７６）を含む。これらのステップを含むことにより、上記のようなシナリオ開発の効率化が図られている。これらの各ステップは、以下のように行われる。
【００７０】
まず、設定制限リスト作成ステップ（Ｓ６６，Ｓ６７）について説明する。
設定制限リスト（Ｓ６７）の作成は、開発者が行う。設定制限リストの作成は、設定制限事項（Ｓ６３）及びシナリオ（Ｓ６５）を入力として行われる。
【００７１】
設定制限事項には、検証対象に対する入力動作（命令）を制限する制限事項の内容が、自然言語で記載されているものとする。また、入力動作を制限する各事項について、対応する番号（Ｎｏ．）が付与されているものとする。シナリオは、トランザクタへの命令を記述したソースコードである。このような設定制限事項及びシナリオを用いて、開発者が設定制限リストを作成する。
【００７２】
図１２に設定制限リストのフォーマットの一例を示す。
図１２の設定制限リストのフォーマット４００ａには、各種情報を記入（入力）する欄４０１ａ〜４０６ａが設けられている。
【００７３】
欄４０１ａには、設定制限リストからシナリオチェッカ生成ステップ（Ｓ６８、Ｓ６９）で生成するシナリオチェッカの名称（チェッカ名）が記入される。チェッカ名の欄４０１ａには、生成するシナリオチェッカの機能を表すような任意の文字列が記入される。この欄４０１ａに記入されたチェッカ名は、シナリオチェッカ生成ステップで生成されるファイル名の一部として使用される。また、このチェッカ名は、チェッカエラー時のメッセージに出力される文字列にも使用される。
【００７４】
欄４０２ａには、シナリオ（Ｓ６５）の、設定制限事項（Ｓ６３）に関する入力動作を行う記述がある部分のファイルの名称（参照ファイル名）が記入される。欄４０３ａには、シナリオチェッカ生成ステップで生成されるシナリオチェッカを、上記参照ファイル名のファイル中に挿入する行番号（挿入行番号）が記入される。
【００７５】
欄４０４ａのＮｏ．（番号１〜ｎ）は、シナリオの入力動作についての各設定制限事項に対応して付与されている。入力１〜ｍの欄４０５ａには、各設定制限事項の入力動作の内容を決定する変数名が記入される。条件１＿１〜ｎ＿ｍの欄４０６ａには、各設定制限事項の入力動作の内容を決定する変数名（入力１〜ｍ）に対応した具体的な変数が記入される。欄４０６ａのその他条件１〜ｍには、入力１〜ｍの変数名に対応した変数以外の条件が記入される。欄４０５ａ、欄４０６ａは、該当する条件がない場合には空欄とされる。
【００７６】
開発者は、設定制限事項（Ｓ６３）及びシナリオ（Ｓ６５）を用いて、フォーマット４００ａの各欄４０１ａ〜４０６ａの内容を記入し、設定制限リスト（Ｓ６７）を作成する。尚、設定制限リストを作成するうえで、行数及び列数は、設定制限事項の数（番号の数）及び変数名の数等に応じて適宜調節される。
【００７７】
続いて、シナリオチェッカ生成ステップ（Ｓ６８，Ｓ６９）について説明する。
シナリオチェッカ（Ｓ６９）の生成は、開発者がシナリオチェッカ生成スクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの生成は、設定制限リスト（Ｓ６７）を入力として行われる。
【００７８】
シナリオチェッカは１つ又は２つ以上のチェッカを含むファイルである。設定制限リストを入力としてシナリオチェッカ生成スクリプトを実行することにより、設定制限リストの内容を記述したシナリオチェッカが生成され、ファイルに出力される。このときのファイル名は“［チェッカ名］．［拡張子］”となる。拡張子は、テストベンチ（Ｓ７３）で使用する言語に依存する。
【００７９】
生成されるシナリオチェッカの記述内容は、テストベンチで使用する言語によって異なる。但し、いずれの言語においても、シミュレーションを実行してシナリオチェッカがエラーとなったときに、どの設定制限事項に対してのエラーであるかが判別できるようにする。そのため、ログファイルにエラーの内容と共に、“［チェッカ名］＿［番号ｉ］”（ｉ＝１〜ｎ）という文字列（ラベル名）を出力するようなシナリオチェッカを生成する。
【００８０】
続いて、シナリオチェッカ組み込みステップ（Ｓ７０，Ｓ７１）について説明する。
シナリオチェッカ（Ｓ６９）の組み込みは、開発者がシナリオチェッカ組み込みスクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの組み込みは、設定制限リスト（Ｓ６７）、シナリオチェッカ（Ｓ６９）、シナリオ（６５）を入力として行われる。シナリオチェッカ組み込みスクリプトを実行することで、設定制限リストに記載された参照ファイル名（欄４０２ａ）に該当するファイルの、挿入行番号（欄４０３ａ）に該当する行番号に、シナリオチェッカ（Ｓ６９）のファイルのインクルード文が追加される。
【００８１】
続いて、ログファイル確認ステップ（Ｓ７５，Ｓ７６）について説明する。
ログファイルの確認は、開発者が行う。ログファイルの確認では、シミュレーションを行った結果が出力されるログファイル（Ｓ７５）の内容から、シナリオチェッカのエラー出力メッセージの有無を確認し、シナリオ修正の要否が判断される。シミュレーションにおいてシナリオチェッカのエラーが発生した場合、ログファイルには、エラーを検出したチェッカ名と、そのエラーの内容を示す情報（設定制限事項の番号）を含んだラベル名の文字列が出力される。このようなログファイルに含まれる情報を基に、シナリオ修正の要否が判断される。
【００８２】
以下、上記手法を、実施例によって、より具体的に説明する。
まず、第１実施例について説明する。
図１３は第１実施例に係る検証対象とシナリオの関係を示す図である。
【００８３】
第１実施例のテストベンチで使用する言語は、ＳｙｓｔｅｍＶｅｒｉｌｏｇとする。
図１３の検証対象３００はメモリモデルとなっており、内部にレジスタ領域３０１を有している。検証対象３００への入力動作として、レジスタ領域３０１への書き込み動作がある。検証対象３００には、アドレスＡＤＤＲ（３２’ｈ００００００００〜３２’ｈＦＦＦＦＦＦＦＣ）とデータＤＡＴＡを指定した、シナリオ２１１からの書き込み動作の命令が、トランザクタ２１２を介して送られる。検証対象３００では、指定されたアドレスＡＤＤＲの示すレジスタ領域３０１に、指定されたデータＤＡＴＡが格納される。
【００８４】
即ち、まずシナリオ２１１において、レジスタ領域３０１への書き込み動作のアドレスＡＤＤＲとデータＤＡＴＡの内容を決定する。次いで、シナリオ２１１がトランザクタ２１２に、レジスタ領域３０１への書き込み動作を行うように、アドレスＡＤＤＲとデータＤＡＴＡの情報を与えて命令する。トランザクタ２１２が検証対象３００に対してレジスタ領域３０１への書き込み動作の入力動作を行い、検証対象３００にアドレスＡＤＤＲとデータＤＡＴＡの情報を伝える。検証対象３００は、トランザクタ２１２からのレジスタ領域３０１への書き込み動作の情報を受けて、指定されたアドレスＡＤＤＲのレジスタ領域３０１に、指定されたデータＤＡＴＡを格納する。
【００８５】
第１実施例では、このようなレジスタ領域３０１への書き込み動作に関し、シナリオ２１１を設定するうえでの設定制限事項があるものとする。図１４は第１実施例に係る設定制限事項の一例を示す図である。図１４に例示する設定制限事項５００では、まず第１（Ｎｏ．０００１）の設定制限事項の内容として、アドレス３２’ｈ００００００００に対して３２’ｈ０００００００１の書き込み禁止が設定されている。更に、第２（Ｎｏ．０００２）の設定制限事項の内容として、ｔｏｐ．ＲＥＡＤＹｏ＝＝０のときアドレス３２’ｈ０００００００４に対して書き込み禁止が設定されている。
【００８６】
図１５は第１実施例に係るシナリオの記述部分の一例を示す図である。図１５には、第１実施例のシナリオ２１１に含まれるレジスタ領域３０１への書き込み動作を行う記述部分（一部）を例示している。第１実施例のシナリオ２１１には、“ｓｃｅｎａｒｉｏ．ｓｖ”という名称のファイル２１１ｆａが含まれており、このファイル２１１ｆａに、レジスタ領域３０１への書き込み動作を行う記述（ｗｒｉｔｅ＿ａｃｃｅｓｓタスク）が含まれている。
【００８７】
上記のような設定制限事項５００及びシナリオ２１１を用いた設定制限リストの作成を、例えば、図１６〜図１９のような流れで行っていく。
設定制限リスト４００の作成では、まず図１６のように、生成しようとするシナリオチェッカの機能を表すような任意の文字列、ここでは“ＷＲＩＴＥ”という文字列を、チェッカ名の欄４０１（図１２のフォーマット４００ａの欄４０１ａ）に記入する。
【００８８】
次いで、図１７のように、設定制限事項５００に関する入力動作を行う記述のあるファイル２１１ｆａの名称“ｓｃｅｎａｒｉｏ．ｓｖ”を、参照ファイル名の欄４０２（図１２のフォーマット４００ａの欄４０２ａ）に記入する。更に、後のシナリオチェッカ生成ステップで生成されるファイルを“ｓｃｅｎａｒｉｏ．ｓｖ”内でインクルードする行番号を、挿入行番号の欄４０３（図１２のフォーマット４００ａの欄４０３ａ）に記入する。この第１実施例では、生成されるファイルを、レジスタ領域３０１に対する書き込み動作の内容（アドレスＡＤＤＲ、データＤＡＴＡ）を参照できる箇所である１０１行目に挿入することになるため、欄４０３には“１０１”を記入する。
【００８９】
次いで、図１８のように、入力（変数名）の欄４０５（図１２のフォーマット４００ａの欄４０５ａ（入力１及び入力２））に、変数名を記入する。この第１実施例では、レジスタ領域３０１に対する書き込み動作の内容を決定する変数がアドレスＡＤＤＲとデータＤＡＴＡであるため、欄４０５に“ＡＤＤＲ”及び“ＤＡＴＡ”を記入する。
【００９０】
次いで、設定制限事項５００に記載されている内容を解釈して、図１９のように、各条件の欄４０６（図１２のフォーマット４００ａの欄４０６ａ）に、具体的な条件を記入する。第１実施例では、Ｎｏ．０００１の設定制限事項について、“ＡＤＤＲ”に対して“３２’ｈ００００００００”を記入し、“ＤＡＴＡ”に対して“３２’ｈ０００００００１”を記入し、その他条件は空欄とする。また、Ｎｏ．０００２の設定事項については、“ＡＤＤＲ”に対して“３２’ｈ０００００００４”を記入し、“ＤＡＴＡ”は空欄とし、その他条件に対して“ｔｏｐ．ＲＥＡＤＹｏ＝＝０”を記入する。
【００９１】
このようにして設定制限リスト４００の作成が行われる。
続いて、作成された設定制限リスト４００を用いたシナリオチェッカ２１３の生成について、図２０及び図２１を参照して説明する。
【００９２】
ここでは、ＳｙｓｔｅｍＶｅｒｉｌｏｇを用いている場合を例に説明する。ＳｙｓｔｅｍＶｅｒｉｌｏｇのチェッカのアサーションは、“［ラベル名］：ａｓｓｅｒｔ（［エラー条件］）”というフォーマットになる。［ラベル名］は任意の文字列となり、［エラー条件］はＳｙｓｔｅｍＶｅｒｉｌｏｇの文法における論理式となる。このチェッカがシミュレーション中に実行されたときに、［エラー条件］の論理式が真を示すと、結果(ログファイル)に、［ラベル名］と共に、エラーであることが記録される。
【００９３】
ＳｙｓｔｅｍＶｅｒｉｌｏｇの場合のシナリオチェッカ生成では、シナリオチェッカ生成スクリプトを実行することにより、作成された設定制限リスト４００を基に、［ラベル名］と［エラー条件］の部分の文字列を生成し、シナリオチェッカ２１３を生成する。シナリオチェッカ２１３は、“［チェッカ名］．ｓｖｈ”というファイル名で生成する。
【００９４】
図２０に、シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す。図２０には、設定制限リストのフォーマット４００ａの記載と、それから生成されるシナリオチェッカ２１３の記述との対応を示している。
【００９５】
各Ｎｏ．（番号１〜ｎ）について、それぞれ１つのチェッカが生成される。各チェッカの［ラベル名］は、“チェッカ名＿番号ｉ”（ｉ＝１〜ｎ）という文字列で生成される。［エラー条件］は、例えばＮｏ．０００１では、“（入力１＝＝条件１＿１）＆＆（入力２＝＝条件１＿２）・・・（入力ｍ＝＝条件１＿ｍ）＆＆（その他条件１）”という文字列で生成される。但し、条件が空欄の場合は、その部分の論理式は生成されない。
【００９６】
第１実施例では次の図２１に示すようになる。
図２１は第１実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。
【００９７】
図２１のように、設定制限リスト４００より、Ｎｏ．０００１については［ラベル名］が“ＷＲＩＴＥ＿０００１”、［エラー条件］が“ＡＤＤＲ＝＝３２’ｈ００００００００）＆＆（ＤＡＴＡ＝＝３２’ｈ０００００００１）”のチェッカ２１３ａが生成される。また、設定制限リスト４００より、Ｎｏ．０００２については［ラベル名］が“ＷＲＩＴＥ＿０００２”、［エラー条件］が“ＡＤＤＲ＝＝３２’ｈ０００００００４）＆＆（ｔｏｐ．ＲＥＡＤＹｏ＝＝０）”のチェッカ２１３ｂが生成される。
【００９８】
このようなチェッカ２１３ａ，２１３ｂを含むシナリオチェッカ２１３のファイル名は、“ＷＲＩＴＥ．ｓｖｈ”となる。
続いて、生成されたシナリオチェッカの組み込みについて、図２２を参照して説明する。
【００９９】
図２２は第１実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。
図２２のように、シナリオチェッカ組み込みスクリプトを実行することで、設定制限リスト４００の情報を基に、シナリオ２１１の“ｓｃｅｎａｒｉｏ．ｓｖ”のファイル２１１ｆａの１０１行目に、“ＷＲＩＴＥ．ｓｖｈ”のインクルード文２１１ｃが挿入される。これにより、図２１のようなシナリオチェッカ２１３がシナリオ２１１に組み込まれた記述（シナリオチェッカ２１３を呼び出し可能な記述）が得られる。
【０１００】
このようなシナリオ２１１を用いたシナリオ開発やテストベンチ開発の段階で行われるシミュレーションの際には、シナリオの“ｓｃｅｎａｒｉｏ．ｓｖ”の記述部分の命令実行時に、“ＷＲＩＴＥ．ｓｖｈ”のシナリオチェッカ２１３が呼び出される。そして、呼び出されたシナリオチェッカ２１３により、シナリオ２１１が実行する命令に、その実行を制限する制限情報（アドレスＡＤＤＲ、データＤＡＴＡ、その他条件）が含まれるか否か（エラー条件の論理式が真を示すか否か）がチェックされる。シナリオ２１１の命令実行を制限する制限情報が含まれていればエラーとなる。エラーか否かのチェック結果は、ログファイルとして出力される。
【０１０１】
続いて、シナリオチェッカを用いたシミュレーションの結果得られるログファイルについて、図２３を参照して説明する。
図２３は第１実施例に係るログファイルの出力例である。
【０１０２】
第１実施例のシナリオチェッカ２１３がシミュレーションでエラーを検出した場合、シミュレーションの結果得られるログファイル６００には、チェッカ２１３ａ，２１３ｂの［ラベル名］の文字列が出力される。即ち、この例では、“ＷＲＩＴＥ＿０００１”や“ＷＲＩＴＥ＿０００２”というラベル名６０１がログファイル６００に出力される。
【０１０３】
開発者は、シミュレーションの結果得られるログファイル６００を確認し、このようにチェッカ２１３ａ，２１３ｂの［ラベル名］が出力されている場合は、シナリオ２１１にエラーがあるとみなし、シナリオ２１１を修正する工程へ進むことになる。
【０１０４】
次に、第２実施例について説明する。
上記第１実施例では、レジスタ領域３０１への書き込み動作における設定制限事項の場合について例示したが、このような単一の動作に対するもののほか、ある機能の一連の処理全体に対する設定制限事項の場合も同様に、上記手法を適用することができる。このような例を、第２実施例として説明する。
【０１０５】
第２実施例の検証対象は、次のような構成を有しているものとする。この検証対象は、ＤＭＡ（Direct Memory Access）機能を有している。検証対象は、複数のＤＭＡ機能設定レジスタを備え、ＤＭＡ機能設定レジスタに行いたい動作の設定を書き込んでＤＭＡ機能が起動されると、ＤＭＡ機能設定レジスタに書き込まれた設定値に従ってＤＭＡ機能の動作を行う。
【０１０６】
ＤＭＡ機能設定レジスタには、転送方向（ＯＵＴ／ＩＮ）、ＤＭＡモード（ブロック／デマンド）、バーストモード（ＳＩＮＧＬＥ／ＩＮＣＲ）の各設定項目があるものとする。尚、ＤＭＡモードのブロックは、１回の転送要求にてブロック単位で１回の転送を行うモードを示し、デマンドは、転送要求がアクティブの期間、転送を行うモードを示す。バーストモードのＳＩＮＧＬＥは、１回の転送要求で単独転送を行うモードを示し、ＩＮＣＲは、インクリメント式のバースト転送を行うモードを示す。このほか、ＤＭＡ機能設定レジスタには更に、総転送数（ＬＥＮＧＴＨ）（１６ｂｉｔ）、転送元（ＳＲＣ）アドレス（３２ｂｉｔ）、転送先（ＤＳＴ）アドレス（３２ｂｉｔ）の各設定項目があるものとする。
【０１０７】
このような検証対象のＤＭＡ機能の動作に関し、シナリオ２１１を設定するうえでの設定制限事項があるものとする。図２４は第２実施例に係る設定制限事項の一例を示す図である。図２４に例示する設定制限事項５１０では、まずＮｏ．０００１の設定制限事項の内容として、総転送数０でのＤＭＡ起動禁止が設定されている。Ｎｏ．０００２の設定制限事項の内容として、転送方向がＩＮ且つＤＭＡモードがデマンドでのＤＭＡ起動禁止が設定されている。Ｎｏ．０００３の設定制限事項の内容として、ＤＭＡモードがブロック且つバーストモードがＩＮＣＲでのＤＭＡ起動禁止が設定されている。
【０１０８】
図２５は第２実施例に係るシナリオの記述部分の一例を示す図である。図２５には、第２実施例のシナリオ２１１に含まれるＤＭＡ機能の起動処理を行う記述部分（一部）を例示している。第２実施例のシナリオ２１１には、“ｓｃｅｎａｒｉｏ．ｓｖ”という名称のファイル２１１ｆｂが含まれており、このファイル２１１ｆｂに、ＤＭＡ機能の起動処理を行う記述（ｄｍａ＿ｐｒｏｃｅｓｓタスク）が含まれている。ｄｍａ＿ｐｒｏｃｅｓｓタスクは、入力されたＤＭＡ機能設定レジスタの設定項目の情報に従ってレジスタの書き込みを行い、一連のＤＭＡ機能の起動処理を行うタスクである。
【０１０９】
上記のような設定制限事項５１０及びシナリオ２１１を用いて作成される、第２実施例に係る設定制限リストの一例を図２６に示す。
図２６の設定制限リスト４１０は、上記第１実施例と同様の手順で作成することができる。この第２実施例の設定制限リスト４１０では、チェッカ名の欄４１１（図１２のフォーマット４００ａの欄４０１ａ）に“ＤＭＡ”という文字列が記入される。
【０１１０】
参照ファイル名の欄４１２（図１２のフォーマット４００ａの欄４０２ａ）には、ＤＭＡ機能の起動処理を行う記述のあるファイル２１１ｆｂの名称“ｓｃｅｎａｒｉｏ．ｓｖ”が記入される。
【０１１１】
挿入行番号の欄４１３（図１２のフォーマット４００ａの欄４０３ａ）には、シナリオチェッカ生成ステップで生成されるファイルをインクルードする行番号が記入される。この第２実施例では、生成されるファイルを、ＤＭＡ機能の起動処理の内容（ディレクトリＤＩＲ、ＤＭＡモードＤＭＡ＿ＭＯＤＥ、バーストモードＢＵＲＳＴ＿ＭＯＤＥ、ＬＥＮＧＴＨ）を参照できる行である“２０７”が欄４１３に記入される。
【０１１２】
入力（変数名）の欄４１５（図１２のフォーマット４００ａの欄４０５ａ）には、ＤＭＡ機能の起動処理の内容を決定するディレクトリＤＩＲ、ＤＭＡモードＤＭＡ＿ＭＯＤＥ、バーストモードＢＵＲＳＴ＿ＭＯＤＥ、ＬＥＮＧＴＨの各変数名が記入される。
【０１１３】
各条件の欄４１６（図１２のフォーマット４００ａの欄４０６ａ）には、設定制限事項５１０の内容が解釈されて具体的な制限情報が記入される。第２実施例では、Ｎｏ．０００１の設定制限事項について、“ＬＥＮＧＴＨ”に対して“１６’ｈ００００”が記入され、それ以外は空欄とされる。Ｎｏ．０００２の設定事項については、“ＤＩＲ”及び“ＤＭＡ＿ＭＯＤＥ”に対して“１’ｂ１”が記入され、それ以外は空欄とされる。Ｎｏ．０００３の設定事項については、“ＤＭＡ＿ＭＯＤＥ”に対して“１’ｂ０”が記入され、“ＢＵＲＳＴ＿ＭＯＤＥ”に対して“１’ｂ１”が記入され、それ以外は空欄とされる。
【０１１４】
図２７は第２実施例に係るシナリオチェッカの一例を示す図である。
上記のような設定制限リスト４１０を基に、シナリオチェッカ生成スクリプトを実行することで、Ｎｏ．０００１，０００２，０００３の各チェッカ２１３ｃ，２１３ｄ，２１３ｅを含むシナリオチェッカ２１３が生成される。各チェッカ２１３ｃ，２１３ｄ，２１３ｅは、第１実施例同様、“［ラベル名］：ａｓｓｅｒｔ（［エラー条件］）”というフォーマットに従って生成される。この第２実施例の場合、生成されるシナリオチェッカ２１３は、“ＤＭＡ．ｓｖｈ”というファイル名になる。
【０１１５】
そして、上記第１実施例同様、シナリオチェッカ組み込みスクリプトを実行し、設定制限リスト４１０を基に、これらのチェッカ２１３ｃ，２１３ｄ，２１３ｅを含むシナリオチェッカ２１３をファイル２１１ｆｂの２０７行目に呼び出すインクルード文を挿入する。それにより、それにより、当該シナリオチェッカ２１３が、ファイル２１１ｆｂの２０７行目で呼び出されるように組み込まれたシナリオ２１１が得られるようになる。
【０１１６】
このようなシナリオ２１１が用いられてシナリオ開発やテストベンチ開発で行われるシミュレーションでは、エラー検出の際のログファイルに“ＤＭＡ＿０００１”、“ＤＭＡ＿０００２”、“ＤＭＡ＿０００３”の［ラベル名］が出力される。開発者は、シミュレーションの結果得られるログファイルを確認し、このようにチェッカ２１３ｃ，２１３ｄ，２１３ｅの［ラベル名］が出力されている場合は、シナリオ２１１にエラーがあるとみなし、シナリオ２１１を修正する工程へ進む。
【０１１７】
以上説明した手法によれば、シナリオ開発段階、テストベンチ開発段階で行われるシミュレーションにおいて、シナリオのエラーの有無及びエラーの内容を示す情報を、ログファイルの確認で行うことができる。そのため、シナリオのエラーが検出されたときに、敢えて波形データを取得することが不要になり、更に、取得した波形データを開発者が目視で確認し解析することによってそのエラー要因を特定するといった作業が不要になる。従って、シナリオ要因のエラーの解析時間を短縮することが可能になる。例えば、テストベンチ開発段階で、シナリオ要因のエラーとそれ以外のエラーがそれぞれ５割の割合で発生していた場合、全体としてのエラーの解析時間がおよそ２分の１になることになる。
【０１１８】
更に、以上説明した手法では、シナリオ開発段階でのシナリオの動作確認（検証）をログファイルの確認で行うことができる。一方、シナリオの動作確認を波形データの目視確認によって行うと、時間がかかり、あまり多くの動作について確認が行えない場合があった。上記手法によれば、シナリオの動作確認をログファイルの確認で行え、波形データの目視確認を不要とすることができるため、動作確認に要する時間を短縮できる。その結果、より多くの動作について確認を行うことも可能になり、シナリオの動作確認を十分に行うことが可能になる。
【０１１９】
尚、以上の説明では、シナリオ（及びシナリオを組み込んだテストベンチ）の開発を例にしたが、論理回路を制御するファームウェアの開発においても、上記同様の手法を用いることができる。
【０１２０】
即ち、検証対象の仕様、ファームウェアの仕様等を基に、ファームウェアの制御動作を設定するうえでの設定制限事項を得る。その設定制限事項を基に、上記シナリオの例に従い、ファームウェアの所定記述部分の命令実行を制限する制限情報を含んだ設定制限リストを作成する。そして、作成した設定制限リストの内容を記述したファームウェアのチェッカを生成し、生成したチェッカを、ファームウェアに対し、その所定記述部分の命令実行時に呼び出せるように組み込む。このファームウェアを用いて論理回路を動作させ、所定記述部分でチェッカを呼び出し、その所定記述部分の命令にその実行を制限する制限情報が含まれるか否かを、呼び出したチェッカによってチェックする。ファームウェアの命令実行を制限する制限情報が含まれていればエラーとなる。エラーの有無及びエラーの内容を示す情報を、ログファイルとして出力する。
【０１２１】
このような手法によれば、検出されるエラーがファームウェアによるものであることをログファイルから判定でき、更に、ファームウェア要因のエラーについて、波形データの解析が不要になる。そのため、ファームウェア要因のエラーを波形データの目視確認で行う場合に比べ、エラーの解析時間を短縮することが可能になる。
【０１２２】
尚、上記のシナリオ、テストベンチ、及びファームウェア、並びにそれらを用いた対象回路の検証は、コンピュータを用いて実現することができ、その場合、コンピュータが実行する処理機能の内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、ＨＤ、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷ等がある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）等がある。
【０１２３】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１２４】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム若しくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。尚、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１２５】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現することもできる。
【符号の説明】
【０１２６】
１００ コンピュータ
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＨＤＤ
１０４ａ ＨＤ
１０５ 通信インタフェース
１０６ キーボード
１０７ マウス
１０８ 周辺機器
１１０ バス
１２０ 設計データ
１３０ 論理シミュレータ
１４０，２００，２００Ａ テストベンチ
２１０，２１０ａ，２１０ｂ モデル
２１１，２１１ａ，２１１ｂ シナリオ
２１１ｃ インクルード文
２１１ｆａ，２１１ｆｂ ファイル
２１２，２１２ａ，２１２ｂ トランザクタ
２１３ シナリオチェッカ
２１３ａ，２１３ｂ，２１３ｃ，２１３ｄ，２１３ｅ チェッカ
２２０ プロトコルチェッカ
２２０ａ Ａプロトコルチェッカ
２２０ｂ Ｂプロトコルチェッカ
２３０ 期待値比較チェッカ
３００ 検証対象
３０１ レジスタ領域
４００，４１０ 設定制限リスト
４００ａ フォーマット
４０１ａ，４０２ａ，４０３ａ，４０４ａ，４０５ａ，４０６ａ，４０１，４０２，４０３，４０５，４０６，４１１，４１２，４１３，４１５，４１６ 欄
５００，５１０ 設定制限事項
６００ ログファイル
６０１ ラベル名
【技術分野】
【０００１】
本発明は、回路検証に用いる検証方法及び検証プログラムに関する。
【背景技術】
【０００２】
ＬＳＩ（Large Scale Integration）等の集積回路の開発では、設計仕様を基にレジスタ・トランスファ・レベル（ＲＴＬ）と呼ばれる論理式を用いて回路の論理を表現する。このＲＴＬで設計された回路の機能、動作を検証するために、コンピュータを用いたシミュレーションが行われる。
【０００３】
検証時には、検証対象の回路に対する命令の手順を記述したシナリオをテストベンチに組み込み、そのテストベンチを用いて検証対象のシミュレーションを行う。そして、その検証対象の回路からの出力について、仕様違反や規格違反等のエラーを起こしていないかチェックする。このような回路の検証に用いられるシナリオやテストベンチは、回路の検証に先立ち、或いは回路の検証と並行して、開発される。
【０００４】
また、回路を制御するためのファームウェアを設計し、ファームウェアを用いて回路を動作させ、ファームウェアがその回路を正しく制御しているかを確認する技術等も知られている。
【０００５】
このほか、ランダムに並べたテストシーケンスを含むシナリオを用いたランダムテストで回路を検証する際に、シミュレーションによって実際にテストされた検証項目を確認するための手法等も知られている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−８６８３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、シナリオを組み込んだテストベンチを用いて検証対象の検証を行う場合、検出されるエラーは、検証対象が原因である場合のほか、テストベンチの開発段階ではそのテストベンチ、例えば組み込まれているシナリオが原因である場合もある。シナリオが原因である場合には、例えば、シミュレーション時の波形データを用いて、エラーを引き起こしたシナリオの命令箇所を特定する。しかし、エラーの発生タイミングとそのエラーを引き起こしたシナリオの命令タイミングには時間差があるため、エラーを引き起こしたシナリオの原因箇所を特定する作業が複雑になり、エラー原因の解析に長時間を要してしまうことがある。
【０００８】
一方、上記のような検証に用いるシナリオの開発段階では、検証対象の設計仕様書に基づき、一定条件の場合の命令実行を制限する制限事項を考慮してシナリオを作成し、それを組み込んだテストベンチを用いてシミュレーションが行われる。このシミュレーション時の波形データを目視確認することで、シナリオの動作が検証される。しかし、このような波形データの目視確認には長時間を要してしまうことがある。更に、シナリオに基づく検証対象への入力命令の数が膨大になると、それら全てについて波形データの目視確認で検証を行うことは難しくなる。このようにして検証されなかった命令や、制限事項が適正に考慮されていない命令が、上記のようなシナリオが原因のエラーを発生させる一因にもなっている。
【０００９】
ここではシナリオを例にしたが、回路を制御するファームウェアでも同様に、その開発段階では、作成したファームウェアを用いて回路（検証対象）を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラーの原因が検証対象の回路側にあるのか、それを制御するファームウェア側にあるのかの判定に時間がかかってしまう。エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。
【課題を解決するための手段】
【００１０】
本発明の一観点によれば、コンピュータが実行する検証方法であって、検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、前記チェックの結果を示す結果情報を生成する検証方法が提供される。
【００１１】
また、本発明の一観点によれば、このような検証方法を実現するための処理をコンピュータに実行させる検証プログラムが提供される。
【発明の効果】
【００１２】
開示の技術によれば、シナリオやファームウェア等のプログラムを、当該プログラムの実行時にチェッカを用いてチェックし、そのチェックの結果から検証することが可能になる。それにより、当該プログラムの検証時や、当該プログラムを用いた検証時に、波形データの取得、取得した波形データの目視確認作業を不要にすることが可能になる。適正なシナリオやファームウェア等のプログラムを、効率的に開発することが可能になり、当該プログラムを用いた検証作業を効率的に行うことが可能になる。
【図面の簡単な説明】
【００１３】
【図１】論理シミュレーション環境の一例を示す図である。
【図２】検証作業フローの一例を示す図である。
【図３】テストベンチ開発作業フローの一例を示す図（その１）である。
【図４】テストベンチ開発段階でのテストベンチの構成例を示す図（その１）である。
【図５】シナリオ要因のエラー発生例を示す図である。
【図６】シナリオ開発作業フローの一例を示す図（その１）である。
【図７】シナリオ開発段階でのテストベンチの構成例を示す図（その１）である。
【図８】シナリオ開発作業フローの一例を示す図（その２）である。
【図９】シナリオ開発段階でのテストベンチの構成例を示す図（その２）である。
【図１０】テストベンチ開発作業フローの一例を示す図（その２）である。
【図１１】テストベンチ開発段階でのテストベンチの構成例を示す図（その２）である。
【図１２】設定制限リストのフォーマットの一例を示す図である。
【図１３】第１実施例に係る検証対象とシナリオの関係を示す図である。
【図１４】第１実施例に係る設定制限事項の一例を示す図である。
【図１５】第１実施例に係るシナリオの記述部分の一例を示す図である。
【図１６】設定制限リストの作成方法を示す図（その１）である。
【図１７】設定制限リストの作成方法を示す図（その２）である。
【図１８】設定制限リストの作成方法を示す図（その３）である。
【図１９】設定制限リストの作成方法を示す図（その４）である。
【図２０】シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す図である。
【図２１】第１実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。
【図２２】第１実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。
【図２３】第１実施例に係るログファイルの出力例である。
【図２４】第２実施例に係る設定制限事項の一例を示す図である。
【図２５】第２実施例に係るシナリオの記述部分の一例を示す図である。
【図２６】第２実施例に係る設定制限リストの一例を示す図である。
【図２７】第２実施例に係るシナリオチェッカの一例を示す図である。
【発明を実施するための形態】
【００１４】
ＬＳＩ開発では、設計仕様を基にＲＴＬで設計された論理回路の機能、動作を、コンピュータを用いた論理シミュレーションを行って検証する。
図１に論理シミュレーション環境の一例を示す。
【００１５】
論理シミュレーション環境は、コンピュータ１００を用いて構築される。コンピュータ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御される。ＣＰＵ１０１には、バス１１０を介して、ＲＯＭ（Read Only Memory）１０２及びＲＡＭ（Random Access Memory）１０３が接続される。ＲＯＭ１０２には、シミュレーションを行う論理回路を制御するファームウェア等のプログラムが格納される。ＲＡＭ１０３には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０３には、ＣＰＵ１０１による処理に必要な各種データが格納される。
【００１６】
バス１１０には、複数の周辺機器が接続される。バス１１０に接続される周辺機器としては、ハードディスクドライブ（Hard Disk Drive；ＨＤＤ）１０４、通信インタフェース１０５、キーボード１０６、マウス１０７等がある。
【００１７】
ＨＤＤ１０４は、ハードディスク（Hard Disk；ＨＤ）１０４ａに対して磁気的にデータの書き込み及び読み出しを行う。ＨＤＤ１０４には、ＯＳのプログラム、アプリケーションプログラム、及び各種データが格納される。通信インタフェース１０５は、ネットワークに接続され、ネットワークを介して、他のコンピュータ又は通信機器との間でデータの送受信を行う。また、キーボード１０６やマウス１０７から送られてくる信号は、バス１１０を介してＣＰＵ１０１に送信される。尚、マウス１０７は、ポインティングデバイスの一例であり、タッチパネル、タブレット、タッチパッド、トラックボール等、他のポインティングデバイスを用いることも可能である。
【００１８】
バス１１０には、更に、その他の周辺機器１０８が接続されていてもよい。その他の周辺機器１０８としては、例えば、グラフィック処理装置や光学ドライブ装置等が挙げられる。この場合、グラフィック処理装置には、モニタ（ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置等）が接続され、グラフィック処理装置は、ＣＰＵ１０１からの命令に従って、画像をモニタの画面に表示させる。また、光学ドライブ装置は、レーザ光等を利用して、光ディスク（ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等）に記録されたデータの読み取りを行う。
【００１９】
このような構成を有するコンピュータ１００の、例えばＨＤ１０４ａに、ＲＴＬの論理回路（検証対象）の設計データ１２０、論理シミュレータ１３０、ＲＴＬの論理回路に対する命令を記述したシナリオを組み込んだテストベンチ１４０等が格納される。コンピュータ１００は、ＨＤＤ１０４を駆動し、ＨＤ１０４ａに格納されたこれらの情報を用いて、検証対象である論理回路の論理シミュレーションを実行する。この論理シミュレーションの結果に基づき、論理回路の機能、動作が適正か否かが検証される。
【００２０】
次に、論理シミュレーションを用いた検証作業の一例について説明する。
図２は検証作業フローの一例を示す図である。
論理シミュレーションを行う検証作業では、まず、検証対象である論理回路の仕様書（設計仕様書）（Ｓ１０）を基に、検証仕様書が作成される（Ｓ１１，Ｓ１２）。そして、作成された検証仕様書からテストベンチの構成が検討され、テストベンチ仕様書が作成される（Ｓ１３，Ｓ１４）。このテストベンチ仕様書を基に、テストベンチの開発が行われる（Ｓ１５，Ｓ１６）。開発されたテストベンチを用いて論理シミュレーション（検証作業）が行われ、その結果（検証結果）が取得される（Ｓ１７，Ｓ１８）。論理シミュレーションで得られる検証結果から、検証対象の論理回路が適正に動作するか否かが、開発者或いはコンピュータ１００によって、判定される。
【００２１】
更にテストベンチ開発（Ｓ１５，Ｓ１６）に着目して説明する。
図３はテストベンチ開発作業フローの一例を示す図である。
図３のテストベンチ開発作業フローでは、開発者が、テストベンチ仕様書（Ｓ２０）から更にテストベンチの構成要素となる部品（モデル）毎の仕様を設定し、部品毎に開発を行う（Ｓ２１〜Ｓ２３）。図３の例では、チェッカの開発（Ｓ２１）、トランザクタの開発（Ｓ２２）、シナリオの開発（Ｓ２３）を行っている。そして、各部品について単体テストを実施し、問題がないことを確認して、各部品を取得する（Ｓ２４）。このようにして取得された各部品を、検証対象の論理回路と共に組み上げることで（Ｓ２５）、テストベンチ（論理回路を含むシミュレーションの全体環境）を取得する（Ｓ２６）。
【００２２】
テストベンチ開発段階でのテストベンチの構成例を図４に示す。
図４のテストベンチ２００は、部品として、シナリオ２１１及びトランザクタ２１２を含むモデル２１０、プロトコルチェッカ２２０、及び期待値比較チェッカ２３０を備えている（テストベンチ開発環境）。
【００２３】
シナリオ２１１には、ＲＴＬで設計された検証対象３００の論理回路に対する命令の手順が記述されている。シナリオ２１１は、トランザクタ２１２の仕様に合わせ、トランザクタ２１２に対し、検証対象３００を制御する（動作させる）命令を与える。
【００２４】
トランザクタ２１２は、シナリオ２１１からの命令に従い、検証対象３００との間のインタフェース仕様に合わせて信号を制御し、シナリオ２１１からの命令の情報を検証対象３００に伝える。検証対象３００は、このトランザクタ２１２からの情報を受けて、その情報が示す命令の動作を実行する。また、トランザクタ２１２は、検証対象３００から送られてくる情報を受信し、受信した情報をシナリオ２１１へ通知する。
【００２５】
プロトコルチェッカ２２０は、プロトコルが存在するインタフェースに対し、関連する入出力端子を参照し、プロトコルに特化したチェックを行う。プロトコルチェッカ２２０は、プロトコル違反を検出した場合、エラーを報告する。
【００２６】
期待値比較チェッカ２３０は、検証対象３００の入出力端子を参照し、検証対象３００の出力端子（データ値、信号制御等）が設計仕様通り動作しているかのチェックを行う。期待値比較チェッカ２３０は、設計仕様違反を検出した場合、エラーを報告する。
【００２７】
図３のテストベンチ開発作業フローにおいて、このような構成を有するテストベンチを取得（Ｓ２６）した後は、コンピュータを用い、テストベンチで検証対象の論理回路を動作させ、最終的な動作確認テスト（全体シミュレーション）を行う（Ｓ２７）。この全体シミュレーションの結果（テストベンチに組み込まれたチェッカによるチェック結果）は、ログファイルとして出力される（Ｓ２８）。このログファイルの情報から開発者がエラーの発生有無を判断する（Ｓ２９）。エラーが発生している場合、そのエラー要因を特定するために波形データが必要になる。この波形データを取得する目的で、コンピュータを用いた再シミュレーションを行う（Ｓ３０，Ｓ３１）。取得した波形データを開発者が目視で確認し、エラー要因を特定する（Ｓ３２）。エラー要因は、まず、検証対象の論理回路側にある場合と、テストベンチ側にある場合の２つに分けられる（Ｓ３３）。
【００２８】
エラー要因が検証対象の論理回路側にある場合には（Ｓ３３）、開発者が、ＲＴＬで設計されたその論理回路の修正を行い（Ｓ３４）、修正後の論理回路を作成し（Ｓ３５）、修正後の論理回路と共に、再度テストベンチを取得する（Ｓ２５，Ｓ２６）。そして、その再取得したテストベンチを用いて全体シミュレーション（Ｓ２７）以降の作業を実施する。
【００２９】
一方、エラー要因がテストベンチ側にある場合（Ｓ３３）、エラー要因は、テストベンチ内のシナリオ、トランザクタ、チェッカ等の部品の、少なくともいずれかに存在している（Ｓ３６）。例えば、図４のテストベンチ２００の場合、シナリオ２１１、トランザクタ２１２、プロトコルチェッカ２２０、期待値比較チェッカ２３０のいずれかにエラー要因が存在する。
【００３０】
シナリオにエラー要因（シナリオミス）がある場合には（Ｓ３６）、シナリオ開発（Ｓ２３）に戻り、シナリオのエラー要因を修正する。トランザクタにエラー要因（トランザクタミス）がある場合には（Ｓ３６）、トランザクタ開発（Ｓ２２）に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因（チェッカミス）がある場合には（Ｓ３６）、チェッカ開発（Ｓ２１）に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し（Ｓ２４）、テストベンチを取得（Ｓ２５，Ｓ２６）して、全体シミュレーション（Ｓ２７）以降の作業を実施する。
【００３１】
全体シミュレーションでエラーが検出されず（Ｓ２９）、更に異なる条件で全体シミュレーション（テスト）を行う場合には（Ｓ３７）、シミュレーション条件を変更してテストを行う（Ｓ２７）。エラーなく全てのテストが終了すれば（Ｓ３７）、テストベンチ開発作業は終了となる。開発したテストベンチを用いて、上記図２の論理シミュレーション（検証作業）が行われる（Ｓ１７，Ｓ１８）。
【００３２】
テストベンチは、例えば上記図３のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図３の作業フローでは、全体シミュレーションの結果（Ｓ２７，Ｓ２８）、チェッカによりエラーが検出された場合（Ｓ２９）、再シミュレーションで波形データが取得され（Ｓ３０，Ｓ３１）、その目視確認が行われる（Ｓ３２）。
【００３３】
開発済みの適正なテストベンチが用いられている場合、チェッカがエラーを検出すれば、検証対象の論理回路側に問題があると判断できる。しかし、テストベンチの開発段階では、チェッカ自体が適正であるか否かが確定しておらず、その品質に問題が残っているため、検出されたエラーがチェッカ自体のミスによるものである可能性がある。更に、テストベンチの開発段階では、シナリオに問題がある場合も、チェッカによりエラーとして検出されてくる。このようにエラーの要因がシナリオにある場合、その要因の特定には時間がかかる。その理由を、次の図５を参照して説明する。
【００３４】
図５はシナリオ要因のエラー発生例を示す図である。図５において、（Ａ）はテストベンチの一例、（Ｂ），（Ｃ）は波形データの一例である。
まず、チェッカがエラーを検出するのは、検証対象の出力端子が仕様違反、規格違反した動作に対してであり、検証対象の出力動作は入力パターンで決まる。つまり、検証対象への入力パターン（シナリオの命令）にミスがあると、チェッカによってエラーが検出される。
【００３５】
今、図５（Ａ）のテストベンチ２００における一方のモデル２１０ａのシナリオ２１１ａに従い、図５（Ｂ）のような入力パターン（出力信号１，２）がトランザクタ２１２ａを介して検証対象３００に出力されたものとする。そして、その入力パターンに基づき、検証対象３００からは、図５（Ｃ）のような出力（出力信号１，２）が得られ、その出力がもう一方のモデル２１０ｂ（シナリオ２１１ｂ、トランザクタ２１２ｂ）に送られるものとする。この検証対象３００からの出力に対し、Ｂプロトコルチェッカ２２０ｂがＸ部にエラーを検出したものとする。即ち、この例では、Ｂプロトコルチェッカ２２０ｂが、出力のＸ部における、クロックの立ち上がりで出力信号１，２が共にハイ（Ｈ）レベルとなるエラーを検出する。このＢプロトコルチェッカ２２０ｂで検出されたエラーは、シナリオ２１１ａからの入力パターンにおける、Ｙ部の入力パターンミスが根本原因になっている。
【００３６】
このように、検証対象３００の出力についてＢプロトコルチェッカ２２０ｂで検出されるエラー要因が、検証対象３００に対する入力パターンにあると、エラーの検出ポイント（Ｘ部）と、その要因となる入力パターン（Ｙ部）の間には、時間差Ｔが生じる。エラー要因がシナリオ２１１ａにあり、その要因を波形データから特定しようとすると、この時間差Ｔのために、解析が複雑になる場合があり、解析に長時間を要してしまう場合もある。
【００３７】
尚、このような課題に対し、検証対象３００への入力パターンの制約違反のチェックを行うチェッカを開発することも考えられる。例えば、Ａプロトコルチェッカ２２０ａに検証対象３００への入力パターンをチェックするアサーションを実装することで、課題の改善には繋がる。しかし、チェッカ開発工数が増える、チェッカ開発が完了しないとチェックが行えない等、根本的な解決には至らない。
【００３８】
シナリオは、例えば次のような作業フローで開発されている。
図６はシナリオ開発作業フローの一例を示す図である。
図６のシナリオ開発作業フローでは、開発者が、検証対象の設計に用いる仕様書（Ｓ４０）を基に、シナリオの仕様の検討を行い（Ｓ４１）、シナリオに設定する設定手順（Ｓ４２）、シナリオを設定するうえでの制限事項（設定制限事項）（Ｓ４３）を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成し（Ｓ４４，Ｓ４５）、それを組み込んだテストベンチを取得する（Ｓ４６，Ｓ４７）。そして、取得したテストベンチの動作確認のため、コンピュータを用いてシミュレーションを行い（Ｓ４８）、その結果（波形データ）を取得する（Ｓ４９）。
【００３９】
シナリオ開発段階でのテストベンチの構成例を図７に示す。
シナリオ開発段階のシミュレーション（Ｓ４８）に用いるテストベンチ２００Ａは、検証対象３００、その検証対象３００を動作させる、シナリオ２１１及びトランザクタ２１２を含むモデル２１０を備えている（シナリオ開発環境）。
【００４０】
シナリオ開発環境には、検証対象の入出力をチェックする機能が設けられていない。そのため、シミュレーション時（Ｓ４８）には、波形データを取得し（Ｓ４９）、その波形データを目視確認することで（Ｓ５０）、シナリオの動作を確認する。動作確認の結果、シナリオに問題が見つかった場合には、修正したシナリオを作成し（Ｓ４４，Ｓ４５）、それを組み込んだテストベンチを取得して（Ｓ４６，Ｓ４７）、再度シミュレーションを行い（Ｓ４８，Ｓ４９）、その波形データを確認する（Ｓ５０）。動作確認でシナリオに問題がなく（Ｓ５０）、更に異なる条件でシミュレーション（テスト）を行う場合には（Ｓ５１）、シミュレーション条件を変更してテストを行う（Ｓ４８）。エラーなく全てのテストが終了すれば（Ｓ５１）、シナリオ開発作業は終了となる。
【００４１】
シナリオは、例えば上記図６のような作業フローで開発が可能であるが、以下のような課題もある。
例えば、上記図６の作業フローでは、シナリオの動作確認を、シミュレーション時（Ｓ４８）に取得した波形データ（Ｓ４９）の目視確認によって行っている（Ｓ５０）。
【００４２】
シナリオは、検証対象の状態やその受信状態よって、生成する入力パターンが変わるため、組み合わせを考慮すると、膨大な入力パターンが存在し得る。それら全ての組み合わせについて、波形データを目視で確認し、シナリオの動作確認を行うことは、困難である。そのため、組み合わせを考慮しない、機能毎の動作確認までしか行わない場合もある。
【００４３】
このようにしてシナリオの動作確認を行い、その開発作業を完了させたとしても、全入力パターンの動作確認が済んでいるわけではないため、シナリオが設定制限事項に違反した入力パターンを生成してしまう等、その後の工程に影響を及ぼしてしまう場合がある。例えば、上記図３のテストベンチ開発作業フローで述べた全体シミュレーション（Ｓ２７，Ｓ２８）、更にその結果に基づく再シミュレーション（Ｓ２９〜Ｓ３１）において、上記のようなシナリオ要因の問題が発生してしまう場合がある。
【００４４】
以上説明したように、検証対象の論理回路検証に用いるシナリオの開発（及びシナリオを組み込んだテストベンチの開発）においては、検証の早い段階で、適正な、安定した品質のシナリオを取得することが難しい。適正なシナリオを取得するために、開発中のシナリオ、テストベンチを実際に動作させたときの波形データを取得し、それを開発者が目視で確認する作業が必要になるため、開発に時間を要してしまう。
【００４５】
また、以上の説明では、シナリオ（及びシナリオを組み込んだテストベンチ）の開発を例にしたが、論理回路を制御するファームウェアの開発においても同様のことが起こり得る。
【００４６】
即ち、ファームウェアの開発段階では、作成したファームウェアを用いて論理回路を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラー要因が論理回路側にあるのか、ファームウェア側にあるのかの判定に時間がかかってしまう。これは、上記図５において述べたのと同様に、エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。このように論理回路を制御するためのファームウェアでも、その動作確認に時間を要してしまい、論理回路検証の早い段階で、適正な、安定した品質のファームウェアを取得することが難しい。
【００４７】
シナリオ、ファームウェアのいずれの場合においても、それらを実際に動作させたときに取得される波形データの目視確認を行うことが、それらの開発効率を低下させ、更に、検証対象である論理回路の検証作業効率を低下させる一因になっている。
【００４８】
そこで以下では、このような波形データの目視確認によらずに、適正なシナリオ、ファームウェアを効率的に取得する手法について、詳細に説明していく。ここでは主にシナリオを例に説明する。
【００４９】
図８はシナリオ開発作業フローの一例を示す図である。
図８のシナリオ開発作業フローでは、上記図６で述べた作業フロー同様、まず開発者が、検証対象の設計に用いる仕様書（Ｓ６０）を基に、シナリオの仕様の検討を行い（Ｓ６１）、シナリオの設定手順（Ｓ６２）、シナリオの設定制限事項（Ｓ６３）を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成する（Ｓ６４，Ｓ６５）。
【００５０】
シナリオの作成後、この図８のシナリオ開発作業フローでは、開発者が、シナリオの仕様検討時に抽出した設定制限事項（Ｓ６３）、及び作成したシナリオ（Ｓ６５）を基に、設定制限リストを作成する（Ｓ６６，Ｓ６７）。設定制限リストには、例えば、作成したシナリオの所定記述部分の命令実行を制限する、上記設定制限事項の内容に対応した情報（制限情報）や、その記述部分に対応する所定行番号等の情報が含まれる。尚、設定制限リストの詳細については後述する。
【００５１】
そして、コンピュータを用い、このような設定制限リスト（Ｓ６７）を入力とし、シナリオの動作をチェックするためのシナリオチェッカを自動生成する（Ｓ６８，Ｓ６９）。コンピュータは、例えば、設定制限リスト（Ｓ６７）の内容を、シナリオと同じ言語を用いて、所定記述のシナリオチェッカに書き換える。シナリオチェッカは、例えば、上記したシナリオの所定記述部分の命令が実行されるときに、その命令が上記制限情報を含むか否か、即ち、命令（入力パターン）が設定制限事項に違反していないかをチェックする。尚、この点の詳細については後述する。
【００５２】
設定制限リスト（Ｓ６７）は、このシナリオチェッカの生成のほか（Ｓ６８，Ｓ６９）、シナリオへのシナリオチェッカ組み込み処理に用いられる（Ｓ７０，Ｓ７１）。コンピュータは、例えば、設定制限リスト（Ｓ６７)に示された、上記したシナリオの所定記述部分に対応した行番号を基に、シナリオのその行番号の箇所に、生成したシナリオチェッカ（Ｓ６９）を呼び出すための命令文を挿入する（Ｓ７０）。これにより、当該所定記述部分の命令実行時に、生成されたシナリオチェッカ（Ｓ６９）を呼び出し可能にしたシナリオが取得される（Ｓ７１）。尚、この点の詳細については後述する。
【００５３】
開発者は、このようにして取得されたシナリオチェッカ（Ｓ６９）と、そのシナリオチェッカ（Ｓ６９）を所定記述部分で呼び出し可能なシナリオ（Ｓ７１）とを組み込んだテストベンチを取得する（Ｓ７２，Ｓ７３）。
【００５４】
シナリオ開発段階でのテストベンチの構成例を図９に示す。
シナリオ開発段階のテストベンチ２００Ａは、検証対象３００、その検証対象３００を駆動するモデル２１０であるシナリオ２１１及びトランザクタ２１２を備えている（シナリオ開発環境）。このシナリオ２１１に、シナリオチェッカ２１３が、所定記述部分で呼び出されるように組み込まれている。
【００５５】
シナリオ２１１に従って検証対象３００を動作させると、シナリオ２１１の当該所定記述部分でシナリオチェッカ２１３が呼び出される。呼び出されたシナリオチェッカ２１３は、シナリオ２１１からの命令（入力パターン）に上記制限情報が含まれていないか、即ち、設定制限事項に違反した入力パターンが生成されていないか、チェックする。このようなチェックが、続く、コンピュータを用いたシミュレーション（Ｓ７４）によって行われる。
【００５６】
即ち、取得したテストベンチの動作確認のため、コンピュータを用いたシミュレーションが行われ（Ｓ７４）、コンピュータが、そのシミュレーション結果の情報（ログファイル）を生成する（Ｓ７５）。ここで生成されるシミュレーション結果の情報は、テストベンチにシナリオチェッカが組み込まれているため、シナリオチェッカでエラーを検出したか否かを示すログファイルとなる。上記図６で述べた作業フローにおけるように、シミュレーション結果として、必ずしも波形データを取得することを要しない。
【００５７】
開発者は、シミュレーション結果のログファイルの情報を基に、シナリオから検証対象に対し、設定制限事項に違反しない、適正な命令（入力パターン）が入力されたか否かを判断することができ、そのシナリオの動作確認を行うことができる（Ｓ７６）。従って、シナリオの動作確認のために、上記のような波形データの目視確認を行うことが不要になり、シナリオの動作確認を効率的に行うことができる。
【００５８】
作成したシナリオの動作確認の結果、エラーが検出された場合には、修正したシナリオを作成する（Ｓ６４，Ｓ６５）。そして、上記同様、設定制限リストの作成（Ｓ６６，Ｓ６７）、シナリオチェッカの生成（Ｓ６８，Ｓ６９）及び組み込み（Ｓ７０，Ｓ７１）を行い、テストベンチを取得して（Ｓ７２，Ｓ７３）、再度シミュレーションを行う（Ｓ７４，Ｓ７５）。そのログファイルの情報から、修正したシナリオの動作確認を行う（Ｓ７６）。
【００５９】
動作確認でエラーが検出されず（Ｓ７６）、更に異なる条件でシミュレーション（テスト）を行う場合には（Ｓ７７）、シミュレーション条件を変更してテストを行う（Ｓ７４）。エラーなく全てのテストが終了すれば（Ｓ７７）、シナリオ開発作業は終了となる。
【００６０】
更に、シナリオ開発後の工程について説明する。
図１０はテストベンチ開発作業フローの一例を示す図である。
図１０のテストベンチ開発作業フローでは、上記図３で述べた作業フロー同様、開発者が、テストベンチ仕様書（Ｓ８０）を基に、テストベンチの構成要素の部品毎に、チェッカの開発（Ｓ８１）、トランザクタの開発（Ｓ８２）、シナリオの開発（Ｓ８３，Ｓ６０〜Ｓ７７）を行う。そして、テスト済みの各部品を取得し（Ｓ８４）、それらを組み込んだテストベンチを取得する（Ｓ８５，Ｓ８６）。
【００６１】
テストベンチ開発段階でのテストベンチの構成例を図１１に示す。
図１１のテストベンチ２００は、シナリオ２１１及びトランザクタ２１２を含むモデル２１０、プロトコルチェッカ２２０、及び期待値比較チェッカ２３０を備えている（テストベンチ開発環境）。このシナリオ２１１に、シナリオチェッカ２１３が組み込まれている。
【００６２】
シナリオ開発（図９）で用いられたシナリオチェッカは、シナリオに組み込まれた構成（呼び出し可能な構成）になっており、テストベンチ開発のテストベンチにおいてもそのまま用いることができる。このようなテストベンチ（Ｓ８６）を用いて、上記図３で述べた作業フロー同様、検証対象の論理回路を動作させる全体シミュレーションを行う（Ｓ８７）。この全体シミュレーションの結果は、テストベンチに組み込まれたチェッカ（プロトコルチェッカ、期待値比較チェッカ、シナリオチェッカ）によるチェック結果のログファイルとして出力される（Ｓ８８）。このログファイルの情報から開発者がエラーの発生有無を判断する（Ｓ８９）。
【００６３】
ここで、シナリオチェッカによりエラーが検出されている場合には（Ｓ８９）、シナリオ開発（Ｓ８３）に戻り、シナリオのエラー要因を修正する。ここではシナリオチェッカを設けているため、このように全体シミュレーション（Ｓ８７）のログファイルの結果確認段階で、シナリオのエラー（シナリオミス）を検出することが可能になっている。そのため、検証の比較的早い段階でシナリオの修正を行い、適正なシナリオを作成することができる。また、この時点でシナリオチェッカのエラーがなく、その他のチェッカエラーが検出されていれば、そのエラー要因が、検証対象か、テストベンチのシナリオ以外の部品にあると判断することができる。
【００６４】
シナリオ以外についてのエラーが検出されている場合には（Ｓ８９）、コンピュータを用いた再シミュレーションを行って波形データを取得する（Ｓ９０，Ｓ９１）。取得した波形データを開発者が目視で確認し、エラー要因を特定する（Ｓ９２）。
【００６５】
エラー要因が検証対象の論理回路側にある場合には（Ｓ９３）、開発者が、その論理回路の修正を行い（Ｓ９４）、修正後の論理回路を作成し（Ｓ９５）、修正後の論理回路と共に、再度テストベンチを取得する（Ｓ８５，Ｓ８６）。そして、その再取得したテストベンチを用いて全体シミュレーション（Ｓ８７）以降の作業を実施する。
【００６６】
エラー要因がテストベンチ側にある場合、エラー要因は、テストベンチ内のトランザクタ又はチェッカに分けられる（Ｓ９６）。トランザクタにエラー要因（トランザクタミス）がある場合には（Ｓ９６）、トランザクタ開発（Ｓ８２）に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因（チェッカミス）がある場合には（Ｓ９６）、チェッカ開発（Ｓ８１）に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得し（Ｓ８４）、テストベンチを取得（Ｓ８５，Ｓ８６）して、全体シミュレーション（Ｓ８７）以降の作業を実施する。
【００６７】
全体シミュレーションでエラーが検出されず（Ｓ８９）、更に異なる条件で全体シミュレーション（テスト）を行う場合には（Ｓ９７）、シミュレーション条件を変更してテストを行う（Ｓ８７）。エラーなく全てのテストが終了すれば（Ｓ９７）、テストベンチ開発作業は終了となる。
【００６８】
このように、シナリオにシナリオチェッカを組み込むことで、シナリオ開発及びテストベンチ開発において、シナリオミスについては、シミュレーションによる波形データの取得、取得した波形データの目視確認を不要にすることができる。それにより、適正なシナリオを比較的早期に作成することができ、シナリオ開発を効率化し、更に、テストベンチ開発、論理回路検証の効率化を図ることができる。
【００６９】
上記図８のシナリオ開発作業フローには、上記図６の作業フローと異なり、設定制限リストの作成（Ｓ６６，Ｓ６７）、シナリオチェッカの生成（Ｓ６８，Ｓ６９）、シナリオチェッカの組み込み（Ｓ７０，Ｓ７１）、ログファイルの確認（Ｓ７５，Ｓ７６）を含む。これらのステップを含むことにより、上記のようなシナリオ開発の効率化が図られている。これらの各ステップは、以下のように行われる。
【００７０】
まず、設定制限リスト作成ステップ（Ｓ６６，Ｓ６７）について説明する。
設定制限リスト（Ｓ６７）の作成は、開発者が行う。設定制限リストの作成は、設定制限事項（Ｓ６３）及びシナリオ（Ｓ６５）を入力として行われる。
【００７１】
設定制限事項には、検証対象に対する入力動作（命令）を制限する制限事項の内容が、自然言語で記載されているものとする。また、入力動作を制限する各事項について、対応する番号（Ｎｏ．）が付与されているものとする。シナリオは、トランザクタへの命令を記述したソースコードである。このような設定制限事項及びシナリオを用いて、開発者が設定制限リストを作成する。
【００７２】
図１２に設定制限リストのフォーマットの一例を示す。
図１２の設定制限リストのフォーマット４００ａには、各種情報を記入（入力）する欄４０１ａ〜４０６ａが設けられている。
【００７３】
欄４０１ａには、設定制限リストからシナリオチェッカ生成ステップ（Ｓ６８、Ｓ６９）で生成するシナリオチェッカの名称（チェッカ名）が記入される。チェッカ名の欄４０１ａには、生成するシナリオチェッカの機能を表すような任意の文字列が記入される。この欄４０１ａに記入されたチェッカ名は、シナリオチェッカ生成ステップで生成されるファイル名の一部として使用される。また、このチェッカ名は、チェッカエラー時のメッセージに出力される文字列にも使用される。
【００７４】
欄４０２ａには、シナリオ（Ｓ６５）の、設定制限事項（Ｓ６３）に関する入力動作を行う記述がある部分のファイルの名称（参照ファイル名）が記入される。欄４０３ａには、シナリオチェッカ生成ステップで生成されるシナリオチェッカを、上記参照ファイル名のファイル中に挿入する行番号（挿入行番号）が記入される。
【００７５】
欄４０４ａのＮｏ．（番号１〜ｎ）は、シナリオの入力動作についての各設定制限事項に対応して付与されている。入力１〜ｍの欄４０５ａには、各設定制限事項の入力動作の内容を決定する変数名が記入される。条件１＿１〜ｎ＿ｍの欄４０６ａには、各設定制限事項の入力動作の内容を決定する変数名（入力１〜ｍ）に対応した具体的な変数が記入される。欄４０６ａのその他条件１〜ｍには、入力１〜ｍの変数名に対応した変数以外の条件が記入される。欄４０５ａ、欄４０６ａは、該当する条件がない場合には空欄とされる。
【００７６】
開発者は、設定制限事項（Ｓ６３）及びシナリオ（Ｓ６５）を用いて、フォーマット４００ａの各欄４０１ａ〜４０６ａの内容を記入し、設定制限リスト（Ｓ６７）を作成する。尚、設定制限リストを作成するうえで、行数及び列数は、設定制限事項の数（番号の数）及び変数名の数等に応じて適宜調節される。
【００７７】
続いて、シナリオチェッカ生成ステップ（Ｓ６８，Ｓ６９）について説明する。
シナリオチェッカ（Ｓ６９）の生成は、開発者がシナリオチェッカ生成スクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの生成は、設定制限リスト（Ｓ６７）を入力として行われる。
【００７８】
シナリオチェッカは１つ又は２つ以上のチェッカを含むファイルである。設定制限リストを入力としてシナリオチェッカ生成スクリプトを実行することにより、設定制限リストの内容を記述したシナリオチェッカが生成され、ファイルに出力される。このときのファイル名は“［チェッカ名］．［拡張子］”となる。拡張子は、テストベンチ（Ｓ７３）で使用する言語に依存する。
【００７９】
生成されるシナリオチェッカの記述内容は、テストベンチで使用する言語によって異なる。但し、いずれの言語においても、シミュレーションを実行してシナリオチェッカがエラーとなったときに、どの設定制限事項に対してのエラーであるかが判別できるようにする。そのため、ログファイルにエラーの内容と共に、“［チェッカ名］＿［番号ｉ］”（ｉ＝１〜ｎ）という文字列（ラベル名）を出力するようなシナリオチェッカを生成する。
【００８０】
続いて、シナリオチェッカ組み込みステップ（Ｓ７０，Ｓ７１）について説明する。
シナリオチェッカ（Ｓ６９）の組み込みは、開発者がシナリオチェッカ組み込みスクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの組み込みは、設定制限リスト（Ｓ６７）、シナリオチェッカ（Ｓ６９）、シナリオ（６５）を入力として行われる。シナリオチェッカ組み込みスクリプトを実行することで、設定制限リストに記載された参照ファイル名（欄４０２ａ）に該当するファイルの、挿入行番号（欄４０３ａ）に該当する行番号に、シナリオチェッカ（Ｓ６９）のファイルのインクルード文が追加される。
【００８１】
続いて、ログファイル確認ステップ（Ｓ７５，Ｓ７６）について説明する。
ログファイルの確認は、開発者が行う。ログファイルの確認では、シミュレーションを行った結果が出力されるログファイル（Ｓ７５）の内容から、シナリオチェッカのエラー出力メッセージの有無を確認し、シナリオ修正の要否が判断される。シミュレーションにおいてシナリオチェッカのエラーが発生した場合、ログファイルには、エラーを検出したチェッカ名と、そのエラーの内容を示す情報（設定制限事項の番号）を含んだラベル名の文字列が出力される。このようなログファイルに含まれる情報を基に、シナリオ修正の要否が判断される。
【００８２】
以下、上記手法を、実施例によって、より具体的に説明する。
まず、第１実施例について説明する。
図１３は第１実施例に係る検証対象とシナリオの関係を示す図である。
【００８３】
第１実施例のテストベンチで使用する言語は、ＳｙｓｔｅｍＶｅｒｉｌｏｇとする。
図１３の検証対象３００はメモリモデルとなっており、内部にレジスタ領域３０１を有している。検証対象３００への入力動作として、レジスタ領域３０１への書き込み動作がある。検証対象３００には、アドレスＡＤＤＲ（３２’ｈ００００００００〜３２’ｈＦＦＦＦＦＦＦＣ）とデータＤＡＴＡを指定した、シナリオ２１１からの書き込み動作の命令が、トランザクタ２１２を介して送られる。検証対象３００では、指定されたアドレスＡＤＤＲの示すレジスタ領域３０１に、指定されたデータＤＡＴＡが格納される。
【００８４】
即ち、まずシナリオ２１１において、レジスタ領域３０１への書き込み動作のアドレスＡＤＤＲとデータＤＡＴＡの内容を決定する。次いで、シナリオ２１１がトランザクタ２１２に、レジスタ領域３０１への書き込み動作を行うように、アドレスＡＤＤＲとデータＤＡＴＡの情報を与えて命令する。トランザクタ２１２が検証対象３００に対してレジスタ領域３０１への書き込み動作の入力動作を行い、検証対象３００にアドレスＡＤＤＲとデータＤＡＴＡの情報を伝える。検証対象３００は、トランザクタ２１２からのレジスタ領域３０１への書き込み動作の情報を受けて、指定されたアドレスＡＤＤＲのレジスタ領域３０１に、指定されたデータＤＡＴＡを格納する。
【００８５】
第１実施例では、このようなレジスタ領域３０１への書き込み動作に関し、シナリオ２１１を設定するうえでの設定制限事項があるものとする。図１４は第１実施例に係る設定制限事項の一例を示す図である。図１４に例示する設定制限事項５００では、まず第１（Ｎｏ．０００１）の設定制限事項の内容として、アドレス３２’ｈ００００００００に対して３２’ｈ０００００００１の書き込み禁止が設定されている。更に、第２（Ｎｏ．０００２）の設定制限事項の内容として、ｔｏｐ．ＲＥＡＤＹｏ＝＝０のときアドレス３２’ｈ０００００００４に対して書き込み禁止が設定されている。
【００８６】
図１５は第１実施例に係るシナリオの記述部分の一例を示す図である。図１５には、第１実施例のシナリオ２１１に含まれるレジスタ領域３０１への書き込み動作を行う記述部分（一部）を例示している。第１実施例のシナリオ２１１には、“ｓｃｅｎａｒｉｏ．ｓｖ”という名称のファイル２１１ｆａが含まれており、このファイル２１１ｆａに、レジスタ領域３０１への書き込み動作を行う記述（ｗｒｉｔｅ＿ａｃｃｅｓｓタスク）が含まれている。
【００８７】
上記のような設定制限事項５００及びシナリオ２１１を用いた設定制限リストの作成を、例えば、図１６〜図１９のような流れで行っていく。
設定制限リスト４００の作成では、まず図１６のように、生成しようとするシナリオチェッカの機能を表すような任意の文字列、ここでは“ＷＲＩＴＥ”という文字列を、チェッカ名の欄４０１（図１２のフォーマット４００ａの欄４０１ａ）に記入する。
【００８８】
次いで、図１７のように、設定制限事項５００に関する入力動作を行う記述のあるファイル２１１ｆａの名称“ｓｃｅｎａｒｉｏ．ｓｖ”を、参照ファイル名の欄４０２（図１２のフォーマット４００ａの欄４０２ａ）に記入する。更に、後のシナリオチェッカ生成ステップで生成されるファイルを“ｓｃｅｎａｒｉｏ．ｓｖ”内でインクルードする行番号を、挿入行番号の欄４０３（図１２のフォーマット４００ａの欄４０３ａ）に記入する。この第１実施例では、生成されるファイルを、レジスタ領域３０１に対する書き込み動作の内容（アドレスＡＤＤＲ、データＤＡＴＡ）を参照できる箇所である１０１行目に挿入することになるため、欄４０３には“１０１”を記入する。
【００８９】
次いで、図１８のように、入力（変数名）の欄４０５（図１２のフォーマット４００ａの欄４０５ａ（入力１及び入力２））に、変数名を記入する。この第１実施例では、レジスタ領域３０１に対する書き込み動作の内容を決定する変数がアドレスＡＤＤＲとデータＤＡＴＡであるため、欄４０５に“ＡＤＤＲ”及び“ＤＡＴＡ”を記入する。
【００９０】
次いで、設定制限事項５００に記載されている内容を解釈して、図１９のように、各条件の欄４０６（図１２のフォーマット４００ａの欄４０６ａ）に、具体的な条件を記入する。第１実施例では、Ｎｏ．０００１の設定制限事項について、“ＡＤＤＲ”に対して“３２’ｈ００００００００”を記入し、“ＤＡＴＡ”に対して“３２’ｈ０００００００１”を記入し、その他条件は空欄とする。また、Ｎｏ．０００２の設定事項については、“ＡＤＤＲ”に対して“３２’ｈ０００００００４”を記入し、“ＤＡＴＡ”は空欄とし、その他条件に対して“ｔｏｐ．ＲＥＡＤＹｏ＝＝０”を記入する。
【００９１】
このようにして設定制限リスト４００の作成が行われる。
続いて、作成された設定制限リスト４００を用いたシナリオチェッカ２１３の生成について、図２０及び図２１を参照して説明する。
【００９２】
ここでは、ＳｙｓｔｅｍＶｅｒｉｌｏｇを用いている場合を例に説明する。ＳｙｓｔｅｍＶｅｒｉｌｏｇのチェッカのアサーションは、“［ラベル名］：ａｓｓｅｒｔ（［エラー条件］）”というフォーマットになる。［ラベル名］は任意の文字列となり、［エラー条件］はＳｙｓｔｅｍＶｅｒｉｌｏｇの文法における論理式となる。このチェッカがシミュレーション中に実行されたときに、［エラー条件］の論理式が真を示すと、結果(ログファイル)に、［ラベル名］と共に、エラーであることが記録される。
【００９３】
ＳｙｓｔｅｍＶｅｒｉｌｏｇの場合のシナリオチェッカ生成では、シナリオチェッカ生成スクリプトを実行することにより、作成された設定制限リスト４００を基に、［ラベル名］と［エラー条件］の部分の文字列を生成し、シナリオチェッカ２１３を生成する。シナリオチェッカ２１３は、“［チェッカ名］．ｓｖｈ”というファイル名で生成する。
【００９４】
図２０に、シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す。図２０には、設定制限リストのフォーマット４００ａの記載と、それから生成されるシナリオチェッカ２１３の記述との対応を示している。
【００９５】
各Ｎｏ．（番号１〜ｎ）について、それぞれ１つのチェッカが生成される。各チェッカの［ラベル名］は、“チェッカ名＿番号ｉ”（ｉ＝１〜ｎ）という文字列で生成される。［エラー条件］は、例えばＮｏ．０００１では、“（入力１＝＝条件１＿１）＆＆（入力２＝＝条件１＿２）・・・（入力ｍ＝＝条件１＿ｍ）＆＆（その他条件１）”という文字列で生成される。但し、条件が空欄の場合は、その部分の論理式は生成されない。
【００９６】
第１実施例では次の図２１に示すようになる。
図２１は第１実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。
【００９７】
図２１のように、設定制限リスト４００より、Ｎｏ．０００１については［ラベル名］が“ＷＲＩＴＥ＿０００１”、［エラー条件］が“ＡＤＤＲ＝＝３２’ｈ００００００００）＆＆（ＤＡＴＡ＝＝３２’ｈ０００００００１）”のチェッカ２１３ａが生成される。また、設定制限リスト４００より、Ｎｏ．０００２については［ラベル名］が“ＷＲＩＴＥ＿０００２”、［エラー条件］が“ＡＤＤＲ＝＝３２’ｈ０００００００４）＆＆（ｔｏｐ．ＲＥＡＤＹｏ＝＝０）”のチェッカ２１３ｂが生成される。
【００９８】
このようなチェッカ２１３ａ，２１３ｂを含むシナリオチェッカ２１３のファイル名は、“ＷＲＩＴＥ．ｓｖｈ”となる。
続いて、生成されたシナリオチェッカの組み込みについて、図２２を参照して説明する。
【００９９】
図２２は第１実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。
図２２のように、シナリオチェッカ組み込みスクリプトを実行することで、設定制限リスト４００の情報を基に、シナリオ２１１の“ｓｃｅｎａｒｉｏ．ｓｖ”のファイル２１１ｆａの１０１行目に、“ＷＲＩＴＥ．ｓｖｈ”のインクルード文２１１ｃが挿入される。これにより、図２１のようなシナリオチェッカ２１３がシナリオ２１１に組み込まれた記述（シナリオチェッカ２１３を呼び出し可能な記述）が得られる。
【０１００】
このようなシナリオ２１１を用いたシナリオ開発やテストベンチ開発の段階で行われるシミュレーションの際には、シナリオの“ｓｃｅｎａｒｉｏ．ｓｖ”の記述部分の命令実行時に、“ＷＲＩＴＥ．ｓｖｈ”のシナリオチェッカ２１３が呼び出される。そして、呼び出されたシナリオチェッカ２１３により、シナリオ２１１が実行する命令に、その実行を制限する制限情報（アドレスＡＤＤＲ、データＤＡＴＡ、その他条件）が含まれるか否か（エラー条件の論理式が真を示すか否か）がチェックされる。シナリオ２１１の命令実行を制限する制限情報が含まれていればエラーとなる。エラーか否かのチェック結果は、ログファイルとして出力される。
【０１０１】
続いて、シナリオチェッカを用いたシミュレーションの結果得られるログファイルについて、図２３を参照して説明する。
図２３は第１実施例に係るログファイルの出力例である。
【０１０２】
第１実施例のシナリオチェッカ２１３がシミュレーションでエラーを検出した場合、シミュレーションの結果得られるログファイル６００には、チェッカ２１３ａ，２１３ｂの［ラベル名］の文字列が出力される。即ち、この例では、“ＷＲＩＴＥ＿０００１”や“ＷＲＩＴＥ＿０００２”というラベル名６０１がログファイル６００に出力される。
【０１０３】
開発者は、シミュレーションの結果得られるログファイル６００を確認し、このようにチェッカ２１３ａ，２１３ｂの［ラベル名］が出力されている場合は、シナリオ２１１にエラーがあるとみなし、シナリオ２１１を修正する工程へ進むことになる。
【０１０４】
次に、第２実施例について説明する。
上記第１実施例では、レジスタ領域３０１への書き込み動作における設定制限事項の場合について例示したが、このような単一の動作に対するもののほか、ある機能の一連の処理全体に対する設定制限事項の場合も同様に、上記手法を適用することができる。このような例を、第２実施例として説明する。
【０１０５】
第２実施例の検証対象は、次のような構成を有しているものとする。この検証対象は、ＤＭＡ（Direct Memory Access）機能を有している。検証対象は、複数のＤＭＡ機能設定レジスタを備え、ＤＭＡ機能設定レジスタに行いたい動作の設定を書き込んでＤＭＡ機能が起動されると、ＤＭＡ機能設定レジスタに書き込まれた設定値に従ってＤＭＡ機能の動作を行う。
【０１０６】
ＤＭＡ機能設定レジスタには、転送方向（ＯＵＴ／ＩＮ）、ＤＭＡモード（ブロック／デマンド）、バーストモード（ＳＩＮＧＬＥ／ＩＮＣＲ）の各設定項目があるものとする。尚、ＤＭＡモードのブロックは、１回の転送要求にてブロック単位で１回の転送を行うモードを示し、デマンドは、転送要求がアクティブの期間、転送を行うモードを示す。バーストモードのＳＩＮＧＬＥは、１回の転送要求で単独転送を行うモードを示し、ＩＮＣＲは、インクリメント式のバースト転送を行うモードを示す。このほか、ＤＭＡ機能設定レジスタには更に、総転送数（ＬＥＮＧＴＨ）（１６ｂｉｔ）、転送元（ＳＲＣ）アドレス（３２ｂｉｔ）、転送先（ＤＳＴ）アドレス（３２ｂｉｔ）の各設定項目があるものとする。
【０１０７】
このような検証対象のＤＭＡ機能の動作に関し、シナリオ２１１を設定するうえでの設定制限事項があるものとする。図２４は第２実施例に係る設定制限事項の一例を示す図である。図２４に例示する設定制限事項５１０では、まずＮｏ．０００１の設定制限事項の内容として、総転送数０でのＤＭＡ起動禁止が設定されている。Ｎｏ．０００２の設定制限事項の内容として、転送方向がＩＮ且つＤＭＡモードがデマンドでのＤＭＡ起動禁止が設定されている。Ｎｏ．０００３の設定制限事項の内容として、ＤＭＡモードがブロック且つバーストモードがＩＮＣＲでのＤＭＡ起動禁止が設定されている。
【０１０８】
図２５は第２実施例に係るシナリオの記述部分の一例を示す図である。図２５には、第２実施例のシナリオ２１１に含まれるＤＭＡ機能の起動処理を行う記述部分（一部）を例示している。第２実施例のシナリオ２１１には、“ｓｃｅｎａｒｉｏ．ｓｖ”という名称のファイル２１１ｆｂが含まれており、このファイル２１１ｆｂに、ＤＭＡ機能の起動処理を行う記述（ｄｍａ＿ｐｒｏｃｅｓｓタスク）が含まれている。ｄｍａ＿ｐｒｏｃｅｓｓタスクは、入力されたＤＭＡ機能設定レジスタの設定項目の情報に従ってレジスタの書き込みを行い、一連のＤＭＡ機能の起動処理を行うタスクである。
【０１０９】
上記のような設定制限事項５１０及びシナリオ２１１を用いて作成される、第２実施例に係る設定制限リストの一例を図２６に示す。
図２６の設定制限リスト４１０は、上記第１実施例と同様の手順で作成することができる。この第２実施例の設定制限リスト４１０では、チェッカ名の欄４１１（図１２のフォーマット４００ａの欄４０１ａ）に“ＤＭＡ”という文字列が記入される。
【０１１０】
参照ファイル名の欄４１２（図１２のフォーマット４００ａの欄４０２ａ）には、ＤＭＡ機能の起動処理を行う記述のあるファイル２１１ｆｂの名称“ｓｃｅｎａｒｉｏ．ｓｖ”が記入される。
【０１１１】
挿入行番号の欄４１３（図１２のフォーマット４００ａの欄４０３ａ）には、シナリオチェッカ生成ステップで生成されるファイルをインクルードする行番号が記入される。この第２実施例では、生成されるファイルを、ＤＭＡ機能の起動処理の内容（ディレクトリＤＩＲ、ＤＭＡモードＤＭＡ＿ＭＯＤＥ、バーストモードＢＵＲＳＴ＿ＭＯＤＥ、ＬＥＮＧＴＨ）を参照できる行である“２０７”が欄４１３に記入される。
【０１１２】
入力（変数名）の欄４１５（図１２のフォーマット４００ａの欄４０５ａ）には、ＤＭＡ機能の起動処理の内容を決定するディレクトリＤＩＲ、ＤＭＡモードＤＭＡ＿ＭＯＤＥ、バーストモードＢＵＲＳＴ＿ＭＯＤＥ、ＬＥＮＧＴＨの各変数名が記入される。
【０１１３】
各条件の欄４１６（図１２のフォーマット４００ａの欄４０６ａ）には、設定制限事項５１０の内容が解釈されて具体的な制限情報が記入される。第２実施例では、Ｎｏ．０００１の設定制限事項について、“ＬＥＮＧＴＨ”に対して“１６’ｈ００００”が記入され、それ以外は空欄とされる。Ｎｏ．０００２の設定事項については、“ＤＩＲ”及び“ＤＭＡ＿ＭＯＤＥ”に対して“１’ｂ１”が記入され、それ以外は空欄とされる。Ｎｏ．０００３の設定事項については、“ＤＭＡ＿ＭＯＤＥ”に対して“１’ｂ０”が記入され、“ＢＵＲＳＴ＿ＭＯＤＥ”に対して“１’ｂ１”が記入され、それ以外は空欄とされる。
【０１１４】
図２７は第２実施例に係るシナリオチェッカの一例を示す図である。
上記のような設定制限リスト４１０を基に、シナリオチェッカ生成スクリプトを実行することで、Ｎｏ．０００１，０００２，０００３の各チェッカ２１３ｃ，２１３ｄ，２１３ｅを含むシナリオチェッカ２１３が生成される。各チェッカ２１３ｃ，２１３ｄ，２１３ｅは、第１実施例同様、“［ラベル名］：ａｓｓｅｒｔ（［エラー条件］）”というフォーマットに従って生成される。この第２実施例の場合、生成されるシナリオチェッカ２１３は、“ＤＭＡ．ｓｖｈ”というファイル名になる。
【０１１５】
そして、上記第１実施例同様、シナリオチェッカ組み込みスクリプトを実行し、設定制限リスト４１０を基に、これらのチェッカ２１３ｃ，２１３ｄ，２１３ｅを含むシナリオチェッカ２１３をファイル２１１ｆｂの２０７行目に呼び出すインクルード文を挿入する。それにより、それにより、当該シナリオチェッカ２１３が、ファイル２１１ｆｂの２０７行目で呼び出されるように組み込まれたシナリオ２１１が得られるようになる。
【０１１６】
このようなシナリオ２１１が用いられてシナリオ開発やテストベンチ開発で行われるシミュレーションでは、エラー検出の際のログファイルに“ＤＭＡ＿０００１”、“ＤＭＡ＿０００２”、“ＤＭＡ＿０００３”の［ラベル名］が出力される。開発者は、シミュレーションの結果得られるログファイルを確認し、このようにチェッカ２１３ｃ，２１３ｄ，２１３ｅの［ラベル名］が出力されている場合は、シナリオ２１１にエラーがあるとみなし、シナリオ２１１を修正する工程へ進む。
【０１１７】
以上説明した手法によれば、シナリオ開発段階、テストベンチ開発段階で行われるシミュレーションにおいて、シナリオのエラーの有無及びエラーの内容を示す情報を、ログファイルの確認で行うことができる。そのため、シナリオのエラーが検出されたときに、敢えて波形データを取得することが不要になり、更に、取得した波形データを開発者が目視で確認し解析することによってそのエラー要因を特定するといった作業が不要になる。従って、シナリオ要因のエラーの解析時間を短縮することが可能になる。例えば、テストベンチ開発段階で、シナリオ要因のエラーとそれ以外のエラーがそれぞれ５割の割合で発生していた場合、全体としてのエラーの解析時間がおよそ２分の１になることになる。
【０１１８】
更に、以上説明した手法では、シナリオ開発段階でのシナリオの動作確認（検証）をログファイルの確認で行うことができる。一方、シナリオの動作確認を波形データの目視確認によって行うと、時間がかかり、あまり多くの動作について確認が行えない場合があった。上記手法によれば、シナリオの動作確認をログファイルの確認で行え、波形データの目視確認を不要とすることができるため、動作確認に要する時間を短縮できる。その結果、より多くの動作について確認を行うことも可能になり、シナリオの動作確認を十分に行うことが可能になる。
【０１１９】
尚、以上の説明では、シナリオ（及びシナリオを組み込んだテストベンチ）の開発を例にしたが、論理回路を制御するファームウェアの開発においても、上記同様の手法を用いることができる。
【０１２０】
即ち、検証対象の仕様、ファームウェアの仕様等を基に、ファームウェアの制御動作を設定するうえでの設定制限事項を得る。その設定制限事項を基に、上記シナリオの例に従い、ファームウェアの所定記述部分の命令実行を制限する制限情報を含んだ設定制限リストを作成する。そして、作成した設定制限リストの内容を記述したファームウェアのチェッカを生成し、生成したチェッカを、ファームウェアに対し、その所定記述部分の命令実行時に呼び出せるように組み込む。このファームウェアを用いて論理回路を動作させ、所定記述部分でチェッカを呼び出し、その所定記述部分の命令にその実行を制限する制限情報が含まれるか否かを、呼び出したチェッカによってチェックする。ファームウェアの命令実行を制限する制限情報が含まれていればエラーとなる。エラーの有無及びエラーの内容を示す情報を、ログファイルとして出力する。
【０１２１】
このような手法によれば、検出されるエラーがファームウェアによるものであることをログファイルから判定でき、更に、ファームウェア要因のエラーについて、波形データの解析が不要になる。そのため、ファームウェア要因のエラーを波形データの目視確認で行う場合に比べ、エラーの解析時間を短縮することが可能になる。
【０１２２】
尚、上記のシナリオ、テストベンチ、及びファームウェア、並びにそれらを用いた対象回路の検証は、コンピュータを用いて実現することができ、その場合、コンピュータが実行する処理機能の内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、ＨＤ、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷ等がある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）等がある。
【０１２３】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１２４】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム若しくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。尚、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１２５】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現することもできる。
【符号の説明】
【０１２６】
１００ コンピュータ
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＨＤＤ
１０４ａ ＨＤ
１０５ 通信インタフェース
１０６ キーボード
１０７ マウス
１０８ 周辺機器
１１０ バス
１２０ 設計データ
１３０ 論理シミュレータ
１４０，２００，２００Ａ テストベンチ
２１０，２１０ａ，２１０ｂ モデル
２１１，２１１ａ，２１１ｂ シナリオ
２１１ｃ インクルード文
２１１ｆａ，２１１ｆｂ ファイル
２１２，２１２ａ，２１２ｂ トランザクタ
２１３ シナリオチェッカ
２１３ａ，２１３ｂ，２１３ｃ，２１３ｄ，２１３ｅ チェッカ
２２０ プロトコルチェッカ
２２０ａ Ａプロトコルチェッカ
２２０ｂ Ｂプロトコルチェッカ
２３０ 期待値比較チェッカ
３００ 検証対象
３０１ レジスタ領域
４００，４１０ 設定制限リスト
４００ａ フォーマット
４０１ａ，４０２ａ，４０３ａ，４０４ａ，４０５ａ，４０６ａ，４０１，４０２，４０３，４０５，４０６，４１１，４１２，４１３，４１５，４１６ 欄
５００，５１０ 設定制限事項
６００ ログファイル
６０１ ラベル名
【特許請求の範囲】
【請求項１】
コンピュータが、
検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、
前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、
前記チェックの結果を示す結果情報を生成する、
ことを特徴とする検証方法。
【請求項２】
前記コンピュータは、前記所定記述部分の命令実行時に前記チェッカを呼び出し、前記チェックを行うことを特徴とする請求項１に記載の検証方法。
【請求項３】
前記リストは、当該リストから生成する前記チェッカを識別する識別情報、前記チェッカを呼び出す前記プログラム内の行番号、及び前記制限情報を含み、
前記コンピュータは、
前記リストから前記識別情報及び前記制限情報を含む前記チェッカを生成し、
前記チェッカの生成後、前記リストに基づいて、前記プログラムの前記行番号に、前記チェッカを呼び出すための前記識別情報を含む命令文を挿入し、
前記プログラムの前記行番号に、前記識別情報に基づいて前記チェッカを呼び出し、前記チェックを行う、
ことを特徴とする請求項２に記載の検証方法。
【請求項４】
前記制限情報は、前記検証対象に対する命令の内容を決定する変数を含むことを特徴とする請求項１乃至３のいずれかに記載の検証方法。
【請求項５】
コンピュータに、
検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、
前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、
前記チェックの結果を示す結果情報を生成する、
処理を実行させることを特徴とする検証プログラム。
【請求項１】
コンピュータが、
検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、
前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、
前記チェックの結果を示す結果情報を生成する、
ことを特徴とする検証方法。
【請求項２】
前記コンピュータは、前記所定記述部分の命令実行時に前記チェッカを呼び出し、前記チェックを行うことを特徴とする請求項１に記載の検証方法。
【請求項３】
前記リストは、当該リストから生成する前記チェッカを識別する識別情報、前記チェッカを呼び出す前記プログラム内の行番号、及び前記制限情報を含み、
前記コンピュータは、
前記リストから前記識別情報及び前記制限情報を含む前記チェッカを生成し、
前記チェッカの生成後、前記リストに基づいて、前記プログラムの前記行番号に、前記チェッカを呼び出すための前記識別情報を含む命令文を挿入し、
前記プログラムの前記行番号に、前記識別情報に基づいて前記チェッカを呼び出し、前記チェックを行う、
ことを特徴とする請求項２に記載の検証方法。
【請求項４】
前記制限情報は、前記検証対象に対する命令の内容を決定する変数を含むことを特徴とする請求項１乃至３のいずれかに記載の検証方法。
【請求項５】
コンピュータに、
検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、
前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、
前記チェックの結果を示す結果情報を生成する、
処理を実行させることを特徴とする検証プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【公開番号】特開２０１２−２５２４３３（Ｐ２０１２−２５２４３３Ａ）
【公開日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願番号】特願２０１１−１２３０８０（Ｐ２０１１−１２３０８０）
【出願日】平成２３年６月１日（２０１１．６．１）
【出願人】（３０８０１４３４１）富士通セミコンダクター株式会社 (2,507)
【Ｆターム（参考）】
【公開日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願日】平成２３年６月１日（２０１１．６．１）
【出願人】（３０８０１４３４１）富士通セミコンダクター株式会社 (2,507)
【Ｆターム（参考）】
[ Back to top ]