(57)【要約】【課題】  ＬＳＩの論理検証におけるテストコードの再利用性の向上、及び論理検証の効率化を図る。【解決手段】  検証対象ブロックにアクセスするにバスマスター、及び検証対象ブロックがアクセスするバススレーブ等を変更する場合、既に論理検証用に作成し、使用した実績のあるテストコードの大部分を、全く変更することなく再利用して、テストコードを容易に作成する。【選択図】  図１
2006127108.tif 000002
【特許請求の範囲】
【請求項１】
ＬＳＩの論理検証において、検証対象となる機能ブロックと、機能ブロックが接続されるバスと、このバスを介して機能ブロックへアクセスする１つ、または複数のバスマスターモデルと、このバスを介して機能ブロックがアクセスする１つまたは複数のスレーブモデルと、
前記マスターモデル、スレーブモデルを制御するそれぞれのコマンド群と、前記モデルやテストベンチの管理を行うユーティリティーコマンド群と、
前記モデルやユーティリティーのコマンド群を、引数を元に選択的に特定するコマンドラッパーと、
前記コマンドラッパーを使用して書かれたシーケンスファイル群と、
前記シーケンスファイル群を取り込み、シーケンスファイルで使用しているコマンドラッパーの引数に制約を与えてコマンドを特定するテストファイル群からなるテストベンチ、及び前記テストベンチを使用してＬＳＩの論理検証を行う論理検証方法。
【請求項２】
前記テストファイルにおいて、取り込んだシーケンスファイルで使用している、コマンドラッパーのもつコマンドを選択する引数に、ある固定の値を与えず、複数の選択可能な値からランダムに選択して与えるように記述した事を特徴とする、請求項１に記載した論理検証方法。
【請求項３】
前記検証対象となる機能ブロックが別のＬＳＩに搭載された際に、前記シーケンスファイル群を全く変更することなく、前記コマンドラッパー及び前記テストファイル群のみを変更することにより論理検証を行うことを特徴とする、請求項１に記載した論理検証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＬＳＩの論理検証におけるテストコードの再利用性の向上、及び論理検証の効率化に関するものである。
【背景技術】
【０００２】
年々、半導体の集積度が飛躍的に向上し、１つのＬＳＩに搭載できる論理回路規模が膨大になっている。これに伴い、この論理回路の機能を保障するための検証項目が膨大になり、検証に要する期間が非常に長期化している。論理検証にかかる期間は、ＬＳＩ開発期間の、７０％を占めるとも言われている。このため、ＬＳＩ開発期間の短縮の観点から、検証期間の短縮、効率化に対する要求は非常に高い。
【０００３】
例えばある１つのＬＳＩに搭載された、ある１つの機能モジュール（ブロック）の動作を保障するためには、非常に多くのテスト項目（アイテム）を検証しなければならない。すなわち、このテスト項目を検証するためには非常に多くのテストコード（テストシーケンス）が必要となり、コーディングには非常に多くの時間を必要とする。
【０００４】
図２に従来の検証方法の実施例を示す。
【０００５】
Ｔｅｓｔ  Ｂｅｎｃｈ  Ｂ  ２１０は、検証対象のＬＳＩ、検証用モデル、検証用Ｕｔｉｌｉｔｙコマンド、テストファイルを含む、検証環境全体（テストベンチ）である。１００は検証対象のＬＳＩであり、１０は今回検証の対象とする機能ブロックＡである。機能ブロックＡ１０はバス８０に接続されている。バス８０にはこのバスマスターとなるマスターモデルＡ２０、及びバススレーブとなるスレーブモデルＡ２２が接続されている。バス８０はバスブリッジ１３を介して別のバス８１に接続されている。バス８１にはこのバスのバスマスターとなるマスターモデルＢ２１とバススレーブとなるスレーブモデルＢ２３が接続されている。各マスターモデルは実際のバスマスターとなるブロック、例えばＣＰＵの代わりに検証用に用意されたバスファンクションモデル（ＢＦＭ）である。また各スレーブモデルも実際のバススレーブとなるブロックの代わりに検証用に用意されたＢＦＭである。ここで、ＬＳＩ  Ａ１００は検証対象の機能ブロックＡ１０の動作に関連するブロックのみが抜き出されて書かれており、実際にはバス８０、バス８１共に様々な機能ブロックが接続されるが省略されている。
【０００６】
初めに、この例で使用する機能ブロックＡ１０の機能を説明する。機能モブロックＡ１０は例えば画処理を行うモジュールとする。機能ブロックＡ１０は、この画処理を行う画処理部と、様々なパラメータを保持するレジスター部と、バススレーブとのデータのやり取りを行うＤＭＡＣ部から構成される。
【０００７】
このレジスター部にバスマスターにより、様々なパラメータが設定される。パラメータは例えば画像処理の入力データが置かれたバススレーブのアドレス、画像処理の出力データを格納するバススレーブのアドレス、また、画処理の演算パラメータ等である。また、画処理を開始する起動トリガを掌るレジスターが存在する。
【０００８】
バスマスターは、まず機能ブロックＡ１０に必要なパラメータをレジスター設定する。この後、起動トリガレジスターにアクセスし、機能ブロックＡ１０の動作を開始させる。機能ブロックＡ１０は設定されたレジスター値に従い、所望のバススレーブの所望のアドレスより所望の量のデータを読み込む。読み込まれたデータに対し、レジスター設定されたパラメータに従い所望の画処理を行う。画処理結果は、レジスター設定された値に従い、所望のバススレーブの所望のアドレスに格納する。設定された所望のサイズの画処理を完了すると、機能ブロックＡ１０は何らかの形でマスターに対して画像処理終了を通知する。終了通知の方法は、例えばマスターに対する割り込み信号を使ったものや、画像処理ステータスをレジスターにて示し、マスターにポーリングさせる等である。
【０００９】
次に、以上のような機能ブロックＡ１０を論理検証する際の実際の論理検証方法、検証環境、及びテストコード記述について説明する。
【００１０】
前記バスマスターはＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、バススレーブにはＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２２で置き換えた。これらは接続されるバスのプロトコルに従ってアクセスや応答ができるモデルであり、汎用的なバスに関しては、数多くのＥＤＡベンダーや半導体ベンダーから有償、または無償で提供されている。ローカルなバスに関しては自作する。Ｍａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、Ｓｌａｖｅ  Ｍｏｄｅｌ  Ａ２２は、それぞれこれらを制御するＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａ３０、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ａ３２を有する。また、テストに有用なユーティリティーコマンド  Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ａ４０を用意した。ユーティリティーコマンドは、例えばＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２２のアドレス領域から任意のアドレス領域を割り振ってアドレスを返すコマンドを作成した。これを用いると、前記、画像処理の入力データが格納されたアドレスの指定を、ある値に固定することなく、テストの度に任意の値を与えて検証したい場合などに有効である。これらコマンドはコマンドレイヤー１１０に示されている。これらコマンドの一例を次に示す。
【００１１】
ａ）ＭＳＴ＿Ａ．ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）
ｂ）ＭＳＴ＿Ａ．ｒｅａｄ（ａｄｄｒｅｓｓ）＝ｄａｔａ
ｃ）ＳＬＶ＿Ａ．ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）
ｄ）ＳＬＶ＿Ａ．ｒｅａｄ（ａｄｄｒｅｓｓ）＝ｄａｔａ
ｅ）ＵＴＩＬ＿Ａ．ａｌｌｏｃ（ｓｉｚｅ）＝ａｄｄｒｅｓｓ
ａ）、ｂ）はＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａ３０のコマンドの一例で、それぞれバスに対して書き込み、読み出しのトランザクションを発行するコマンドである。ａ）は引数にアドレスとデータを持ち、バスに対して所望のアドレスに所望のデータを書き込むトランザクションを発行することができるコマンドである。ｂ）は引数にアドレスを持ち、バスに対して所望のアドレスからデータを読み出すトランザクションを発行することができる。返り値として読み出されたデータを返すコマンドである。
【００１２】
ｃ）、ｄ）はＳｌａｖｅ  Ｃｏｍｍａｎｄ  Ａ３２のコマンドの一例で、それぞれバスを介さずにテストからモデルに直接データの読み書きができるコマンドである。ｃ）は引数にアドレスとデータを持ち、スレーブモデルの指定したアドレスに指定したデータを書き込むことができるコマンドである。ｄ）は引数にアドレスを持ち、スレーブモデルの指定したアドレスからデータを読むことができるコマンドである。
【００１３】
ｅ）はＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ａ４０で、引数に「サイズ」を持ち、Ｓｌａｖｅ  Ｍｏｄｅｌ  Ａ２２のアドレス領域から、指定したサイズの任意のアドレスを返すコマンドである。
【００１４】
これらコマンドを用いて記述したテストが、Ｔｅｓｔ  Ｌａｙｅｒ１４０に示したテスト群である。このテストコードの例を図３に示す。テスト記述に使用した言語は仮想的なものであり、どのような言語でも構わない。
【００１５】
１，  ２行目ではＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ａ４０を用いて、それぞれ画像処理の入力データ、及び出力データのアドレスを任意に割り当てている。３行目から８行目の前まででは、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａ３０を用いて前記割り当てられたアドレスやサイズ、各種画処理パラメータを機能ブロック１０のレジスターに書き込んでいる。８行目から１０行目では、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ａ３２を用いてＳｌａｖｅ  Ｍｏｄｅｌ２２に、画像処理の入力データを予め書き込んでいる。１１行目では再びＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａ３０を用いて画像処理開始命令を機能ブロックＡ１０に与えている。１２行目から１５行目では画像処理終了を待つ記述をしている。ここでは画像処理の終了をＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ３０を用いて機能ブロック１０のステータスレジスターを定期的に読みに行き、終了フラグ「１」が立つのを待っている。１６行目から２３行目では再びＳｌａｖｅ  Ｃｏｍｍａｎｄ  Ａ３２を用いて、Ｓｌａｖｅ  Ｍｏｄｅｌ  ２２から画処理結果を読み出し、期待値と比較している。期待値と一致したならば「ＰＡＳＳ」を、一致しなければ「ＦＡＩＬ」を出力する。
【００１６】
これはひとつのテストコード例であるが、様々なパラメータ、画像サイズの組み合わせを検証する必要があるため、この様なテストが数十本、時には１００本を超えるテストが必要となる。図２のＴｅｓｔ  Ｂｅｎｃｈ  Ｂ２００におけるＴｅｓｔ  Ｌａｙｅｒ  Ａ１４０ではテスト本数ｍ本ある様子を示している。これらテストコードの作成は、作成してはシミュレーションを行い、テストコードの有用性を確かめながら行うため、非常に時間のかかる作業である。
【００１７】
又、別の従来例としては、テストベンチ上に実際に起こるよりも厳しい条件を簡単に発生させ、検証対象回路のバグ出しを行ない設計品質の向上を図る課題に対して、テストベンチ上に実際の回路とは異なるマスタモデルやスレーブモデルを複数配置し各種データ転送をランダムに発生させる論理検証手法（例えば特許文献１参照）をあげることが出来る。
【特許文献１】特開２００３−１５７１８２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１８】
これまでに述べたテストは、機能ブロックＡ１０をＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０によってアクセスした場合、及び機能ブロックＡ１０がＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２２へアクセスした場合についてのものであるが、ＬＳＩ  Ａ１００には他のマスターＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｂ２１と他のスレーブＳｌａｖｅ  Ｍｏｄｅｌ  Ｂ２３があり、機能ブロックＡ１０はこれらのマスターからアクセス、及びスレーブへアクセスすることができる。すなわち機能ブロックＡ１０の論理検証としては、これらのマスター、スレーブブロックとのやり取りに関する検証も行わなければならない。検証項目としては機能ブロックＡ１０のパラメータは変わらないため、Ｍａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、及びＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｂ２２を使用したときと同じ内容、同じ本数のテストを行えばよい。にもかかわらず、Ｍａｓｔｅｒ  Ｍｏｄｅｌ  Ｂ２１を制御するコマンドはＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｂ３１、Ｓｌａｖｅ  Ｍｏｄｅｌ  Ｂ２３を制御するコマンドはＳｌａｖｅ  Ｃｏｍｍａｎｄ  Ｂ  ３３、更にＳｌａｖｅ  Ｍｏｄｅｌ  Ｂ用に用意したユーティリティーコマンドはＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｂであるため、これまでに作成したＴｅｓｔ  Ｌａｙｅｒ  Ａ１４０のｍ本のテストを全て作成しなおさなければならないという問題があった。この様子を図４に示す。図４において、図２と同一の構成要素には同一符号を付した。図４中のＴｅｓｔ  Ｌａｙｅｒ  Ｂ１４１はこの作り直したｍ本のテストを示している。
【００１９】
また、これまでに機能ブロックＡ１０はあるバススレーブから画処理データを入力し、同じバススレーブに対して画処理結果データを格納する場合について述べたが、例えば入力をＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２１から、出力をＳｌａｖｅ  Ｍｏｄｅｌ  Ｂ２３へという処理も可能である。この場合更にｍ本のテストが必要になるという問題があった。
【００２０】
また、例えばバス８０とバス８１のバス幅が同じである場合には、この様にテストを再作成する際にも、Ｔｅｓｔ  Ｌａｙｅｒ  Ａ１４０のテストを、コマンド名の変更をする等、文字置換程度の変更で構わないが、バス幅が異なる場合にはＭａｓｔｅｒ  ＭｏｄｅｌやＳｌａｖｅ  Ｍｏｄｅｌのコマンドのアクセスサイズも異なるため、単純な文字置換では済まないという問題があった。
【００２１】
また、文字置換で済んだとしても、テストのコード数は単純に２倍となり、シミュレーションを実行するコンピューターの記憶装置の容量も２倍必要となるという問題があった。
【００２２】
また、大部分を書き換えなくて済むとはいえ、人の手の介在したものにはヒューマンエラーが混入する可能性があり、変更前の実績のあるテストコードの持つ信頼性を損なうという問題があった。
【００２３】
これらの問題は論理検証の時間を長引かせ、製品開発日程に影響を及ぼす。
【課題を解決するための手段】
【００２４】
上記問題を解決する手段は、ＬＳＩの論理検証において、検証対象となる機能ブロックと、機能ブロックが接続されるバスと、前記バスを介して機能ブロックへアクセスする１つ、または複数のバスマスターモデルと、前記バスを介して機能ブロックがアクセスする１つまたは複数のスレーブモデルと、
前記マスターモデル、スレーブモデルを制御するそれぞれのコマンド群と、前記モデルやテストベンチの管理を行うユーティリティーコマンド群と、
前記モデルやユーティリティーのコマンド群を、引数を元に選択的に特定するコマンドラッパーと、
前記コマンドラッパーを使用して書かれたシーケンスファイル群と、
前記シーケンスファイル群を使用し、シーケンスファイルで使用しているコマンドラッパーの引数に制約を与えてコマンドを特定するテストファイル群からなるテストベンチ、及び前記テストベンチを使用してＬＳＩの論理検証を行う論理検証方法による。
【００２５】
（作用）
本発明による作用は、既に論理検証用に作成し、使用した実績のあるテストコードの大部分を、全く変更することなく再利用して、検証対象ブロックにアクセスするにバスマスター、及び検証対象ブロックがアクセスするバススレーブ等を変更した場合のテストコードを容易に作成し、論理検証を行うことができることである。
【００２６】
また、同一チップ、及び異なるチップに搭載された既に検証された機能ブロックと同一の機能を有する機能ブロックを、既に検証に使用した実績のあるテストコードの大部分を、全く変更することなく再利用して、容易に論理検証が行えることである。
【００２７】
このことは、テストコードの記述量の削減、及び論理検証期間の短縮に効果がある。
【００２８】
また、全く変更しなかった大部分のテストコードに関し、実績のあるテストコードの信頼性を損なうことがない。
【発明の効果】
【００２９】
以上のように本発明によれば、既に論理検証用に作成し、使用した実績のあるテストコードの大部分を、全く変更することなく再利用して、検証対象ブロックにアクセスするにバスマスター、及び検証対象ブロックがアクセスするバススレーブ等を変更した場合のテストコードを容易に作成し、論理検証を行うことができることである。
【００３０】
また、同一チップ、及び異なるチップに搭載された既に検証された機能ブロックと同一の機能を有する機能ブロックを、既に検証に使用した実績のあるテストコードの大部分を、全く変更することなく再利用して、容易に論理検証が行えることである。
【００３１】
このことは、テストコードの記述量の削減、及び論理検証期間の短縮に効果がある。
【００３２】
また、全く変更しなかった大部分のテストコードに関し、実績のあるテストコードの信頼性を損なうことがない。
【発明を実施するための最良の形態】
【００３３】
（実施例１）
図１は本発明に係わるテストベンチ、及び検証方法の一実施形態を示すものである。図１において図２（従来の実施例）と同一の構成要素には同一符号を付した。
【００３４】
図１において、Ｔｅｓｔ  Ｂｅｎｃｈ  Ａ２００は、検証対象のＬＳＩ、検証用モデル、検証用Ｕｔｉｌｉｔｙコマンド、テストファイルを含む、検証環境全体（テストベンチ）である。１００は検証対象のＬＳＩであり、１０は今回検証の対象とする機能ブロックＡである。機能ブロックＡ１０はバス８０に接続されている。バス８０にはこのバスマスターとなるマスターモデルＡ２０、及びバススレーブとなるスレーブモデルＡ２２が接続されている。バス８０はバスブリッジ１３を介して別のバス８１に接続されている。バス８１にはこのバスのバスマスターとなるマスターモデルＢ２１とバススレーブとなるスレーブモデルＢ２３が接続されている。各マスターモデルは実際のバスマスターとなるブロック、例えばＣＰＵの代わりに検証用に用意されたバスファンクションモデル（ＢＦＭ）である。また各スレーブモデルも実際のバススレーブとなるブロックの代わりに検証用に用意されたＢＦＭである。ここで、ＬＳＩ  Ａ１００は検証対象の機能ブロックＡ１０の動作に関連するブロックのみが抜き出されて書かれており、実際にはバス８０、バス８１共に様々な機能ブロックが接続されるが省略されている。
【００３５】
初めに、この例で使用する機能ブロックＡ１０の機能を説明する。機能モブロックＡ１０は例えば画処理を行うモジュールとする。機能ブロックＡ１０は、この画処理を行う画処理部と、様々なパラメータを保持するレジスター部と、バススレーブとのデータのやり取りを行うＤＭＡＣ部から構成される。
【００３６】
このレジスター部にバスマスターにより、様々なパラメータが設定される。パラメータは例えば画像処理の入力データが置かれたバススレーブのアドレス、画像処理の出力データを格納するバススレーブのアドレス、また、画処理の演算パラメータ等である。また、画処理を開始する起動トリガを掌るレジスターが存在する。
【００３７】
バスマスターは、まず機能ブロックＡ１０に必要なパラメータをレジスター設定する。この後、起動トリガレジスターにアクセスし、機能ブロックＡ１０の動作を開始させる。機能ブロックＡ１０は設定されたレジスター値に従い、所望のバススレーブの所望のアドレスより所望の量のデータを読み込む。読み込まれたデータに対し、レジスター設定されたパラメータに従い所望の画処理を行う。画処理結果は、レジスター設定された値に従い、所望のバススレーブの所望のアドレスに格納する。設定された所望のサイズの画処理を完了すると、機能ブロックＡ１０は何らかの形でマスターに対して画像処理終了を通知する。終了通知の方法は、例えばマスターに対する割り込み信号を使ったものや、画像処理ステータスをレジスターにて示し、マスターにポーリングさせる等である。
【００３８】
次に、以上のような機能ブロックＡ１０を論理検証する際の実際の論理検証方法、検証環境、及びテストコード記述について説明する。
【００３９】
前記バスマスターはＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、バススレーブにはＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２２で置き換えた。これらは接続されるバスのプロトコルに従ってアクセスや応答ができるモデルであり、汎用的なバスに関しては、数多くのＥＤＡベンダーや半導体ベンダーから有償、または無償で提供されている。ローカルなバスに関しては自作する。Ｍａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、Ｓｌａｖｅ  Ｍｏｄｅｌ  Ａ２２は、それぞれこれらを制御するＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａ３０、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ａ３２を有する。また、テストに有用なユーティリティーコマンド  Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ａ４０を用意した。ユーティリティーコマンドは、例えばＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２２のアドレス領域から任意のアドレス領域を割り振ってアドレスを返すコマンドを作成した。これを用いると、前記、画像処理の入力データが格納されたアドレスの指定を、ある値に固定することなく、テストの度に任意の値を与えて検証したい場合などに有効である。同様にＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｂ４１を作成した。これらコマンドはコマンドレイヤー１１０に示されている。これらコマンドの一例を次に示す。
【００４０】
ｆ）ＭＳＴ＿Ａ．ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）
ｇ）ＭＳＴ＿Ａ．ｒｅａｄ（ａｄｄｒｅｓｓ）＝ｄａｔａ
ｈ）ＳＬＶ＿Ａ．ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）
ｉ）ＳＬＶ＿Ａ．ｒｅａｄ（ａｄｄｒｅｓｓ）＝ｄａｔａ
ｊ）ＵＴＩＬ＿Ａ．ａｌｌｏｃ（ｓｉｚｅ）＝ａｄｄｒｅｓｓ
ａ）、ｂ）はＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａ３０のコマンドの一例で、それぞれバスに対して書き込み、読み出しのトランザクションを発行するコマンドである。ａ）は引数にアドレスとデータを持ち、バスに対して所望のアドレスに所望のデータを書き込むトランザクションを発行することができるコマンドである。ｂ）は引数にアドレスを持ち、バスに対して所望のアドレスからデータを読み出すトランザクションを発行することができる。返り値として読み出されたデータを返すコマンドである。
【００４１】
ｃ）、ｄ）はＳｌａｖｅ  Ｃｏｍｍａｎｄ  Ａ３２のコマンドの一例で、それぞれバスを介さずにテストからモデルに直接データの読み書きができるコマンドである。ｃ）は引数にアドレスとデータを持ち、スレーブモデルの指定したアドレスに指定したデータを書き込むことができるコマンドである。ｄ）は引数にアドレスを持ち、スレーブモデルの指定したアドレスからデータを読むことができるコマンドである。
【００４２】
ｅ）はＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ａ４０で、引数に「サイズ」を持ち、Ｓｌａｖｅ  Ｍｏｄｅｌ  Ａ２２のアドレス領域から、指定したサイズの任意のアドレスを返すコマンドである。
【００４３】
Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｂ３１、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ｂ３３、Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ４１についても同様のコマンドを作成した。
【００４４】
さらに本発明では、これらＣｏｍｍａｎｄ  Ｌａｙｅｒ１１０のコマンドを間接的に呼ぶことができるＷｒａｐｐｅｒ  Ｌａｙｅｒ１２０を作成した。この例では、同一機能のＭｏｄｅｌやＵｔｉｌｉｔｙ毎にＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒを作成している。Ｍａｓｔｅｒ  ＣｏｍｍａｎｄをまとめるものがＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０、Ｓｌａｖｅ  ＣｏｍｍａｎｄをまとめるものがＳｌａｖｅ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５１、Ｕｔｉｌｉｔｙ  ＣｏｍｍａｎｄをまとめるものがＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ  ５２である。これらＷｒａｐｐｅｒ  Ｃｏｍｍａｎｄは、例えばＩＤを指定する引数によってどのＭｏｄｅｌのＣｏｍｍａｎｄであるのかを特定する。Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０の一例を次に示す。
【００４５】
ＭＳＴ＿ＣＭＤ．ｗｒｉｔｅ（ｍｓｔ＿ｉｄ，ａｄｄｒｅｓｓ，ｄａｔａ）
このコマンドを前述のａ）のコマンドと比較すると、”ｍｓｔ＿ｉｄ”の引数が追加されているのが分かる。この”ｍｓｔ＿ｉｄ”が実際にどのＭｏｄｅｌのコマンドであるかを指定するＩＤである。
【００４６】
図５にＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０のフローチャートの一例を示す。
【００４７】
４００でコマンドを受け付けると、４２０にてｍｓｔ＿ｉｄを評価する。ｍｓｔ＿ｉｄがＭＳＴ＿Ａであれば４３０にてＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０のＷｒｉｔｅ  Ｃｏｍｍａｎｄを発行する。また、４２０にてｍｓｔ＿ｉｄがＭＳＴ＿Ａでなければ４２１へ遷移し、再度ｍｓｔ＿ｉｄの評価を行う。ｍｓｔ＿ｉｄがＭＳＴ＿Ｂであれば４３１にてＭＳＴ＿ＢのＷｒｉｔｅ  Ｃｏｍｍａｎｄを発行する。もし、３２１においてＭＳＴ＿Ｂでなければ、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０のサポートしないＭａｓｔｅｒが指定されたとして、４４０にてＥｒｒｏｒを通知する。ここではシミュレーターにＥｒｒｏｒを通知することを仮定しているが、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄに返り値を持たせて、テストコード側でエラーのハンドリングをしても構わない。
【００４８】
本発明では、これらＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒを用いてテストを記述するが、テストのＬａｙｅｒを図１で示すように、Ｓｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０とＴｅｓｔ  Ｌａｙｅｒ１４０の２つに分けた。Ｓｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０ではＷｒａｐｐｅｒ  Ｌａｙｅｒ１２０のＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒを使用してＳｅｑｕｅｎｃｅコードを記述する。Ｓｅｑｕｅｎｃｅコードの例を図６に示す。テスト記述に使用した言語は仮想的なものであり、どのような言語でも構わない。
【００４９】
１，２行目ではＵｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５２を用いて、それぞれ画像処理の入力データ、及び出力データのアドレスを任意に割り当てている。３行目から８行目の前まででは、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０を用いて前記割り当てられたアドレスやサイズ、各種画処理パラメータを機能ブロック１０のレジスターに書き込んでいる。８行目から１０行目では、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５１を用いてＳｌａｖｅ  Ｍｏｄｅｌに、画像処理の入力データを予め書き込んでいる。１１行目では再びＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０を用いて画像処理開始命令を機能ブロックＡ１０に与えている。１２行目から１５行目では画像処理終了を待つ記述をしている。ここでは画像処理の終了をＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｗｒａｐｐｅｒ５０を用いて機能ブロック１０のステータスレジスターを定期的に読みに行き、終了フラグ「１」が立つのを待っている。１６行目から２３行目では再びＳｌａｖｅ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５２を用いて、Ｓｌａｖｅ  Ｍｏｄｅｌから画処理結果を読み出し、期待値と比較している。期待値と一致したならば「ＰＡＳＳ」を、一致しなければ「ＦＡＩＬ」を出力する。
【００５０】
このＳｅｑｕｅｎｃｅコード３００ではＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５１、Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５２のＩＤに関する引数を、それぞれｍｓｔ＿ｉｄ、ｓｌｖ＿ｉｄ、ｕｔｉｌ＿ｉｄとして変数で与えており、ＩＤの特定を行っていない。
【００５１】
これらＩＤの特定はＴｅｓｔ  Ｌａｙｅｒ１４０のテストコードにおいて行う。テストコードの例を図７に示す。
【００５２】
図７のテストコード３１０において、１行目でＳｅｑｕｅｎｃｅコードＳｅｑｕｅｎｃｅ＿１を取り込んでいる。２行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｍｓｔ＿ｉｄをＭＳＴ＿Ａとして、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ａであることを特定している。３行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｓｌｖ＿ｉｄをＳＬＶ＿Ａとして、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ａであることを特定している。また、４行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｕｔｉｌ＿ｉｄをＵＴＩＬ＿Ａとして、Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ａであることを特定している。
【００５３】
このようにして、様々なパラメータ、画像サイズの組み合わせを機能検証するためのテストアイテム毎にテストを作成した。この様なテストは数十本、時には１００本を超えるテストが必要となる。図１のＳｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０にてＳｅｑｕｅｎｃｅコードがｍ本、Ｔｅｓｔ  Ｌａｙｅｒ  Ａ１４０にてＴｅｓｔコードがｍ本ある様子を示している。これらテストコードの作成は、作成してはシミュレーションを行い、テストコードの有用性を確かめながら行うため、非常に時間のかかる作業である。
【００５４】
これまでに述べたテストは、機能ブロックＡ１０をＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ  ２０によってアクセスした場合、及び機能ブロックＡ１０がＳｌａｖｅ  Ｍｏｄｅｌ  Ａ  ２２へアクセスした場合についてのものであるが、ＬＳＩ  Ａ１００には他のマスターＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｂ２１と他のスレーブＳｌａｖｅ  Ｍｏｄｅｌ  Ｂ２３があり、機能ブロックＡ１０はこれらのマスターからアクセス、及びスレーブへアクセスすることができる。すなわち機能ブロックＡ１０の論理検証としては、これらのマスター、スレーブブロックとのやり取りに関する検証も行わなければならない。検証項目としては機能ブロックＡ１０のパラメータは変わらないため、Ｍａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、及びＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｂ２２を使用したときと同じ内容、同じ本数のテストを行えばよい。
【００５５】
このテストのためのテストベンチを図８に示す。図８において図１と同一の構成要素には同一の符号を付した。この図から分かるように、Ｔｅｓｔ  Ｂｅｎｃｈ  Ａ’２０１ではＳｅｑｕｅｎｃｅ  Ｌａｙｅｒ１２０から下のＬａｙｅｒは、図１のＴｅｓｔ  Ｂｅｎｃｈ  Ａ  ２００と全く同じである。図１のＴｅｓｔ  Ｌａｙｅｒ  Ａ１４０をＴｅｓｔ  Ｌａｙｅｒ  Ｂ１４１に置き換え、テストを作り直した。このテストの１例を図９に示す。この図９のＴｅｓｔ  １’３０２と図７のＴｅｓｔ  １  ３０１とを比較する。１行目のＳｅｑｕｅｎｃｅコードＳｅｑｕｅｎｃｅ＿１を取り込んでいる行は全く同じである。２行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｍｓｔ＿ｉｄをＭＳＴ＿ＡからＭＳＴ＿Ｂとして、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｂであることを特定している。３行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｓｌｖ＿ｉｄをＳＬＶ＿ＡからＳＬＶ＿Ｂとして、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ｂであることを特定している。また、４行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｕｔｉｌ＿ｉｄをＵＴＩＬ＿ＡからＵＴＩＬ＿Ｂとして、Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｂであることを特定している。この様にＴｅｓｔ  Ｌａｙｅｒ  Ａのｍ本のテストコード群を単純な文字置換によりｍ本のＴｅｓｔ  Ｌａｙｅｒ  Ｂのテストコード群に容易に書き換えることができる。
【００５６】
この様に、機能ブロックＡ  １０をＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０によってアクセスした場合、及び機能ブロックＡ  １０がＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２２へアクセスした場合について作成したテストを、他のマスターＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｂ２１からのアクセス、他のスレーブＳｌａｖｅ  Ｍｏｄｅｌ  Ｂ２３へのアクセスを行うテストに容易に変更することができる。
【００５７】
また、この例では機能ブロックＡ１０があるひとつのバススレーブから画処理データを入力し、同じバススレーブに対して画処理結果データを格納する場合について述べたが、例えば入力をＳｌａｖｅ  Ｍｏｄｅｌ  Ａ２１から、出力をＳｌａｖｅ  Ｍｏｄｅｌ  Ｂ２３へという様に、入力と出力を別々のＳｌａｖｅから行う場合についても、Ｓｅｑｕｅｎｃｅコードを書く際にｓｌｖ＿ｉｄを、例えば入力に使用するｓｌｖ＿ｉｄ＿ｉと出力に使用するｓｌｖ＿ｉｄ＿ｏの様に分けて記述しておけばよく、これらをＴｅｓｔコードで書き換えることにより容易にテストを変更することができる。
【００５８】
また、例えばバス８０とバス８１のバス幅が異なる場合にも、異なるアクセスサイズのＭａｓｔｅｒ  ＭｏｄｅｌやＳｌａｖｅ  ＭｏｄｅｌのコマンドをＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒ  Ｌａｙｅｒで吸収することができる。
【００５９】
また、テストのコード数は単純に２倍となるが、Ｓｅｑｕｅｎｃｅコードと分離したため、テストコードのライン数は非常に少なく、シミュレーションを実行するコンピューターの記憶装置の容量も最小限の増加で済む。
【００６０】
また、Ｓｅｑｕｅｎｃｅコード部には全く手が加えられずに再利用できるため、実績のあるテストコードの持つ信頼性を損なうことがない。
【００６１】
これらの効果により論理検証の時間を短縮し、製品開発日程短縮することが可能になる。
【００６２】
本実施例において、バスマスターは機能ブロックＡと同じＬＳＩ  Ａ上にあるとしたが、ＬＳＩ  Ａの外にあっても構わない。バススレーブに関しても同様である。
【００６３】
また、本実施例において示した各モデルやＵｔｉｌｉｔｙのコマンドは１例であり、これらのコマンドに限定したものではない。
【００６４】
また、本実施例では、検証対象の論理ブロックとしてとして、画像処理ブロックを想定したが、これに限定されるものではない。
【００６５】
（実施例２）
実施例１では、図１のＴｅｓｔ  Ｌａｙｅｒ１４０の各テストにおいて、Ｓｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０で使用した各Ｃｏｍｍａｎｄ  ＷｒａｐｐｅｒのＩＤ引数を特定した。しかし、この様な方法では、例えば検証対象の機能ブロックＡ１０にアクセスできるバスマスターが複数ある場合、（Ｔｅｓｔ  Ｌａｙｅｒ１４０のテスト数×マスターの数）分のテスト数が必要になることになる。
本実施例ではＴｅｓｔ  Ｌａｙｅｒの各テストで、Ｓｅｑｕｅｎｃｅ  Ｌａｙｅｒで使用した各Ｃｏｍｍａｎｄ  ＷｒａｐｐｅｒのＩＤ引数をある１つの固定ＩＤとすることなく、テストを実行する度に用意されたＩＤの中からランダムに選択するようにした。
【００６６】
この時のＴｅｓｔコードの例を図１０に示す。
【００６７】
テストコード３０３において、１行目でＳｅｑｕｅｎｃｅコードＳｅｑｕｅｎｃｅ＿１を取り込んでいるところは実施例１と同じである。３行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｍｓｔ＿ｉｄをＭＳＴ＿Ａ、ＭＡＴ＿Ｂから任意に選択している。４行目ではＳｅｑｕｅｎｃｅ＿１で使用したｍｓｔ＿ｉｄを、この選択されたＭａｓｔｅｒ  ＩＤに特定している。５行目においては、Ｓｅｑｕｅｎｃｅ＿１で使用したｓｌｖ＿ｉｄをＳＬＶ＿Ａ、ＳＬＶ＿Ｂから任意に選択している。６行目において、Ｓｅｑｕｅｎｃｅ＿１で使用したｓｌｖ＿ｉｄをこの選択されたＳｌａｖｅ  ＩＤに特定している。Ｓｌａｖｅ  ＩＤが決まると、このＳｌａｖｅに対するＵｔｉｌｉｔｙを使用したいため、ＵｔｉｌｉｔｙのＩＤは一義的に決まる。この様子を７〜１０行目が示している。１１行目ではＳｅｑｕｅｎｃｅ＿１の終了を待っている。
【００６８】
この様にＴｅｓｔコードの記述を変更することによって、あるモデルやユーティリティーに固定しないテストを作成した。１回のテストでは１種類の組み合わせしかできないため、３行目から１１行目を繰り返すように２行目で繰り返し回数を指定し、１２行目でこれを括っている。繰り返し回数は所望の組み合わせが起きるのに十分な値にすればよい。
【００６９】
このことにより、唯一のＴｅｓｔ  ＣｏｄｅセットによりモデルやＵｔｉｌｉｔｙを固定しない複数マスター、複数スレーブに対応したテストを提供することができる。
【００７０】
（実施例３）
実施例１では、ある一つのＬＳＩ上で複数のバスマスター、バススレーブとのやり取りを行う論理検証方法の実施例について述べた。本実施例ではあるＬＳＩに搭載された既に論理検証済みの機能ブロックＡが、他のＬＳＩに搭載された場合の論理検証方法の実施例を示す。
【００７１】
図１１に本実施例の実施形態を示す。図１１において図１と同一の構成要素には同一符号を付した。
【００７２】
図１１において、左半分は既に論理検証済みの機能ブロックＡおよびこのテストベンチであり、図１で示したテストベンチからバス８１に接続されたものを全て取り除いた図である。機能ブロックＡ１０を論理検証するために作成したテストコードはＳｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０のＳｅｑｕｅｎｃｅファイル群、及びＴｅｓｔ  Ｌａｙｅｒ１４０のＴｅｓｔファイル群である。
【００７３】
図１１の右半分に、機能ブロックＡ１０が別のＬＳＩ  Ｃに搭載された時のＴｅｓｔ  Ｂｅｎｃｈ  Ｃ２０２を示す。機能ブロックは、バス８０とは別のバス８２に接続されている。バス８２にはこのバスのマスターとなるマスターモデルＣ２４、及びバスのスレーブとなるスレーブモデルＣ２５が接続されており、これらはＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０、Ｓｌａｖｅ  Ｍｏｄｅｌ  Ａ２２とは異なるものである。Ｃｏｍｍａｎｄ  ＬａｙｅｒにはＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｃ２４を制御するＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｃ３４、Ｓｌａｖｅ  Ｍｏｄｅｌ  ｃ２５を制御する、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ｃ３５を有する。また、テストに有用なユーティリティーコマンド  Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｃ４３を用意した。
【００７４】
この様な場合において、Ｔｅｓｔ  Ｂｅｎｃｈ  Ａ２００のＷｒａｐｐｅｒ  Ｌａｙｅｒ１２０、及びＴｅｓｔＬａｙｅｒ１４０を変更することにより、機能ブロックＡを論理検証するのに十分なＳｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０のＳｅｑｕｅｎｃｅ  Ｆｉｌｅ群を全く変更することなく再利用した。
【００７５】
Ｗｒａｐｐｅｒ  ＬａｙｅｒのＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒのフローチャートを変更した様子を図１２に示し、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ  ５０とＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５３とを比較しながら説明する。
【００７６】
図１２において、左側がＭａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０のフローチャート５０１である。４００でコマンドを受け付けると、４２０にてｍｓｔ＿ｉｄを評価する。ｍｓｔ＿ｉｄがＭＳＴ＿Ａであれば４３０にてＭａｓｔｅｒ  Ｍｏｄｅｌ  Ａ２０のＷｒｉｔｅ  Ｃｏｍｍａｎｄを発行する。また、４２０にてｍｓｔ＿ｉｄがＭＳＴ＿Ａでなければ、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５０のサポートしないＭａｓｔｅｒが指定されたとして、４４０にてＥｒｒｏｒを通知する。実施例１ではＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒは複数のマスターから１つのマスターを選択的に特定するために使用したが、この例の様に１つのマスターのみをサポートしても構わない。このフローチャートにおける４１０で示す破線で囲われた部分をＴｅｓｔ  Ｂｅｎｃｈ  Ｃ２０２用に変更し、フローチャート５０２における４１１で示す破線で囲われた部分とした。この中で４２１にてｍｓｔ＿ｉｄを評価し、ｍｓｔ＿ｉｄがＭＳＴ＿Ｃであれば４３１にてＭａｓｔｅｒ  Ｍｏｄｅｌ  Ｃ２４のＷｒｉｔｅ  Ｃｏｍｍａｎｄを発行する。また、４２１にてｍｓｔ＿ｉｄがＭＳＴ＿Ｃでなければ、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｗｒａｐｐｅｒ５３のサポートしないＭａｓｔｅｒが指定されたとして、４４１にてＥｒｒｏｒを通知する。
【００７７】
この様にＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒを変更することは、変更量が少なく、単純で、テストシーケンス群を変更することに比べ、非常に用意である。
次にＴｅｓｔ  Ｌａｙｅｒの変更例を図１３に示す。テストコード３０４は、図７で示したＴｅｓｔ  Ｂｅｎｃｈ  Ａ２００用に作成したテストコード３０１を変更したものである。
【００７８】
１行目のＳｅｑｕｅｎｃｅコードＳｅｑｕｅｎｃｅ＿１を取り込んでいる行は全く同じである。２行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｍｓｔ＿ｉｄをＭＳＴ＿ＡからＭＳＴ＿Ｃとして、Ｍａｓｔｅｒ  Ｃｏｍｍａｎｄ  Ｃであることを特定している。３行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｓｌｖ＿ｉｄをＳＬＶ＿ＡからＳＬＶ＿Ｃとして、Ｓｌａｖｅ  Ｃｏｍｍａｎｄ  Ｃであることを特定している。また、４行目において、この取り込んだＳｅｑｕｅｎｃｅ＿１で使用したｕｔｉｌ＿ｉｄをＵＴＩＬ＿ＡからＵＴＩＬ＿Ｃとして、Ｕｔｉｌｉｔｙ  Ｃｏｍｍａｎｄ  Ｃであることを特定している。この様にＴｅｓｔ  Ｌａｙｅｒ  Ａ１４０のｍ本のテストコード群を単純な文字置換によりｍ本のＴｅｓｔ  Ｌａｙｅｒ  Ｃ１４２のテストコード群に容易に書き換えることができる。
【００７９】
この様に、既に論理検証済みの機能ブロックＡが、他のＬＳＩに搭載された場合において、既に作成したＳｅｑｕｅｎｃｅ  Ｌａｙｅｒ１３０のＳｅｑｕｅｎｃｅコードファイル群を全く変更することなく、Ｗｒａｐｐｅｒ  Ｌａｙｅｒのわずかな変更、及びＴｅｓｔ  Ｌａｙｅｒの文字置換程度の変更で論理検証を行うことができる。
【００８０】
また、Ｓｅｑｕｅｎｃｅコード部には全く手が加えられずに再利用できるため、実績のあるテストコードの持つ信頼性を損なうことがない。
【図面の簡単な説明】
【００８１】
【図１】本発明の検証方法の一実施例の構成図。
【図２】従来の検証方法の構成図。
【図３】従来の検証方法によるテストコードの一例。
【図４】従来の検証方法の構成図。
【図５】本発明の検証方法によるＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒのフローチャートの一実施例。
【図６】本発明の検証方法によるＳｅｑｕｅｎｃｅコードの一実施例。
【図７】本発明の検証方法によるＴｅｓｔコードの一実施例。
【図８】本発明の検証方法による別の実施例の構成図。
【図９】本発明の検証方法によるＴｅｓｔコードの一実施例。
【図１０】本発明の検証方法によるＴｅｓｔコードの一実施例。
【図１１】本発明の検証方法による別の実施例の構成図。
【図１２】本発明の検証方法によるＣｏｍｍａｎｄ  Ｗｒａｐｐｅｒのフローチャートの別の実施例である。
【図１３】本発明の検証方法によるＴｅｓｔコードの一実施例。
【図１】
2006127108.tif 000003
【図２】
2006127108.tif 000004
【図３】
2006127108.tif 000005
【図４】
2006127108.tif 000006
【図５】
2006127108.tif 000007
【図６】
2006127108.tif 000008
【図７】
2006127108.tif 000009
【図８】
2006127108.tif 000010
【図９】
2006127108.tif 000011
【図１０】
2006127108.tif 000012
【図１１】
2006127108.tif 000013
【図１２】
2006127108.tif 000014
【図１３】
2006127108.tif 000015