"コンピュータが、検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、前記チェックの結果を示す結果情報を生成する、ことを特徴とする検証方法。前記コンピュータは、前記所定記述部分の命令実行時に前記チェッカを呼び出し、前記チェックを行うことを特徴とする請求項1に記載の検証方法。前記リストは、当該リストから生成する前記チェッカを識別する識別情報、前記チェッカを呼び出す前記プログラム内の行番号、及び前記制限情報を含み、前記コンピュータは、前記リストから前記識別情報及び前記制限情報を含む前記チェッカを生成し、前記チェッカの生成後、前記リストに基づいて、前記プログラムの前記行番号に、前記チェッカを呼び出すための前記識別情報を含む命令文を挿入し、前記プログラムの前記行番号に、前記識別情報に基づいて前記チェッカを呼び出し、前記チェックを行う、ことを特徴とする請求項2に記載の検証方法。前記制限情報は、前記検証対象に対する命令の内容を決定する変数を含むことを特徴とする請求項1乃至3のいずれかに記載の検証方法。コンピュータに、検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、前記チェックの結果を示す結果情報を生成する、処理を実行させることを特徴とする検証プログラム。ところで、シナリオを組み込んだテストベンチを用いて検証対象の検証を行う場合、検出されるエラーは、検証対象が原因である場合のほか、テストベンチの開発段階ではそのテストベンチ、例えば組み込まれているシナリオが原因である場合もある。シナリオが原因である場合には、例えば、シミュレーション時の波形データを用いて、エラーを引き起こしたシナリオの命令箇所を特定する。しかし、エラーの発生タイミングとそのエラーを引き起こしたシナリオの命令タイミングには時間差があるため、エラーを引き起こしたシナリオの原因箇所を特定する作業が複雑になり、エラー原因の解析に長時間を要してしまうことがある。一方、上記のような検証に用いるシナリオの開発段階では、検証対象の設計仕様書に基づき、一定条件の場合の命令実行を制限する制限事項を考慮してシナリオを作成し、それを組み込んだテストベンチを用いてシミュレーションが行われる。このシミュレーション時の波形データを目視確認することで、シナリオの動作が検証される。しかし、このような波形データの目視確認には長時間を要してしまうことがある。更に、シナリオに基づく検証対象への入力命令の数が膨大になると、それら全てについて波形データの目視確認で検証を行うことは難しくなる。このようにして検証されなかった命令や、制限事項が適正に考慮されていない命令が、上記のようなシナリオが原因のエラーを発生させる一因にもなっている。ここではシナリオを例にしたが、回路を制御するファームウェアでも同様に、その開発段階では、作成したファームウェアを用いて回路検証対象を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラーの原因が検証対象の回路側にあるのか、それを制御するファームウェア側にあるのかの判定に時間がかかってしまう。エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。本発明の一観点によれば、コンピュータが実行する検証方法であって、検証対象に対する命令を記述したプログラムの所定記述部分の命令実行を制限する制限情報を含むリストを用い、前記リストの内容を示すチェッカを生成し、前記プログラムを用いて前記検証対象を動作させ、前記所定記述部分の命令実行時に、前記チェッカを用いて前記所定記述部分の命令が前記制限情報を含むか否かのチェックを行い、前記チェックの結果を示す結果情報を生成する検証方法が提供される。また、本発明の一観点によれば、このような検証方法を実現するための処理をコンピュータに実行させる検証プログラムが提供される。開示の技術によれば、シナリオやファームウェア等のプログラムを、当該プログラムの実行時にチェッカを用いてチェックし、そのチェックの結果から検証することが可能になる。それにより、当該プログラムの検証時や、当該プログラムを用いた検証時に、波形データの取得、取得した波形データの目視確認作業を不要にすることが可能になる。適正なシナリオやファームウェア等のプログラムを、効率的に開発することが可能になり、当該プログラムを用いた検証作業を効率的に行うことが可能になる。LSI開発では、設計仕様を基にRTLで設計された論理回路の機能、動作を、コンピュータを用いた論理シミュレーションを行って検証する。図1に論理シミュレーション環境の一例を示す。論理シミュレーション環境は、コンピュータ100を用いて構築される。コンピュータ100は、CPUCentralProcessingUnit101によって装置全体が制御される。CPU101には、バス110を介して、ROMReadOnlyMemory102及びRAMRandomAccessMemory103が接続される。ROM102には、シミュレーションを行う論理回路を制御するファームウェア等のプログラムが格納される。RAM103には、CPU101に実行させるOSOperatingSystemのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM103には、CPU101による処理に必要な各種データが格納される。バス110には、複数の周辺機器が接続される。バス110に接続される周辺機器としては、ハードディスクドライブHardDiskDrive;HDD104、通信インタフェース105、キーボード106、マウス107等がある。HDD104は、ハードディスクHardDisk;HD104aに対して磁気的にデータの書き込み及び読み出しを行う。HDD104には、OSのプログラム、アプリケーションプログラム、及び各種データが格納される。通信インタフェース105は、ネットワークに接続され、ネットワークを介して、他のコンピュータ又は通信機器との間でデータの送受信を行う。また、キーボード106やマウス107から送られてくる信号は、バス110を介してCPU101に送信される。尚、マウス107は、ポインティングデバイスの一例であり、タッチパネル、タブレット、タッチパッド、トラックボール等、他のポインティングデバイスを用いることも可能である。バス110には、更に、その他の周辺機器108が接続されていてもよい。その他の周辺機器108としては、例えば、グラフィック処理装置や光学ドライブ装置等が挙げられる。この場合、グラフィック処理装置には、モニタCRTCathodeRayTubeを用いた表示装置や液晶表示装置等が接続され、グラフィック処理装置は、CPU101からの命令に従って、画像をモニタの画面に表示させる。また、光学ドライブ装置は、レーザ光等を利用して、光ディスクDVDDigitalVersatileDisc、DVD-RAM、CD-ROMCompactDiscReadOnlyMemory、CD-RRecordable/RWReWritable等に記録されたデータの読み取りを行う。このような構成を有するコンピュータ100の、例えばHD104aに、RTLの論理回路検証対象の設計データ120、論理シミュレータ130、RTLの論理回路に対する命令を記述したシナリオを組み込んだテストベンチ140等が格納される。コンピュータ100は、HDD104を駆動し、HD104aに格納されたこれらの情報を用いて、検証対象である論理回路の論理シミュレーションを実行する。この論理シミュレーションの結果に基づき、論理回路の機能、動作が適正か否かが検証される。次に、論理シミュレーションを用いた検証作業の一例について説明する。図2は検証作業フローの一例を示す図である。論理シミュレーションを行う検証作業では、まず、検証対象である論理回路の仕様書設計仕様書S10を基に、検証仕様書が作成されるS11,S12。そして、作成された検証仕様書からテストベンチの構成が検討され、テストベンチ仕様書が作成されるS13,S14。このテストベンチ仕様書を基に、テストベンチの開発が行われるS15,S16。開発されたテストベンチを用いて論理シミュレーション検証作業が行われ、その結果検証結果が取得されるS17,S18。論理シミュレーションで得られる検証結果から、検証対象の論理回路が適正に動作するか否かが、開発者或いはコンピュータ100によって、判定される。更にテストベンチ開発S15,S16に着目して説明する。図3はテストベンチ開発作業フローの一例を示す図である。図3のテストベンチ開発作業フローでは、開発者が、テストベンチ仕様書S20から更にテストベンチの構成要素となる部品モデル毎の仕様を設定し、部品毎に開発を行うS21~S23。図3の例では、チェッカの開発S21、トランザクタの開発S22、シナリオの開発S23を行っている。そして、各部品について単体テストを実施し、問題がないことを確認して、各部品を取得するS24。このようにして取得された各部品を、検証対象の論理回路と共に組み上げることでS25、テストベンチ論理回路を含むシミュレーションの全体環境を取得するS26。テストベンチ開発段階でのテストベンチの構成例を図4に示す。図4のテストベンチ200は、部品として、シナリオ211及びトランザクタ212を含むモデル210、プロトコルチェッカ220、及び期待値比較チェッカ230を備えているテストベンチ開発環境。シナリオ211には、RTLで設計された検証対象300の論理回路に対する命令の手順が記述されている。シナリオ211は、トランザクタ212の仕様に合わせ、トランザクタ212に対し、検証対象300を制御する動作させる命令を与える。トランザクタ212は、シナリオ211からの命令に従い、検証対象300との間のインタフェース仕様に合わせて信号を制御し、シナリオ211からの命令の情報を検証対象300に伝える。検証対象300は、このトランザクタ212からの情報を受けて、その情報が示す命令の動作を実行する。また、トランザクタ212は、検証対象300から送られてくる情報を受信し、受信した情報をシナリオ211へ通知する。プロトコルチェッカ220は、プロトコルが存在するインタフェースに対し、関連する入出力端子を参照し、プロトコルに特化したチェックを行う。プロトコルチェッカ220は、プロトコル違反を検出した場合、エラーを報告する。期待値比較チェッカ230は、検証対象300の入出力端子を参照し、検証対象300の出力端子データ値、信号制御等が設計仕様通り動作しているかのチェックを行う。期待値比較チェッカ230は、設計仕様違反を検出した場合、エラーを報告する。図3のテストベンチ開発作業フローにおいて、このような構成を有するテストベンチを取得S26した後は、コンピュータを用い、テストベンチで検証対象の論理回路を動作させ、最終的な動作確認テスト全体シミュレーションを行うS27。この全体シミュレーションの結果テストベンチに組み込まれたチェッカによるチェック結果は、ログファイルとして出力されるS28。このログファイルの情報から開発者がエラーの発生有無を判断するS29。エラーが発生している場合、そのエラー要因を特定するために波形データが必要になる。この波形データを取得する目的で、コンピュータを用いた再シミュレーションを行うS30,S31。取得した波形データを開発者が目視で確認し、エラー要因を特定するS32。エラー要因は、まず、検証対象の論理回路側にある場合と、テストベンチ側にある場合の2つに分けられるS33。エラー要因が検証対象の論理回路側にある場合にはS33、開発者が、RTLで設計されたその論理回路の修正を行いS34、修正後の論理回路を作成しS35、修正後の論理回路と共に、再度テストベンチを取得するS25,S26。そして、その再取得したテストベンチを用いて全体シミュレーションS27以降の作業を実施する。一方、エラー要因がテストベンチ側にある場合S33、エラー要因は、テストベンチ内のシナリオ、トランザクタ、チェッカ等の部品の、少なくともいずれかに存在しているS36。例えば、図4のテストベンチ200の場合、シナリオ211、トランザクタ212、プロトコルチェッカ220、期待値比較チェッカ230のいずれかにエラー要因が存在する。シナリオにエラー要因シナリオミスがある場合にはS36、シナリオ開発S23に戻り、シナリオのエラー要因を修正する。トランザクタにエラー要因トランザクタミスがある場合にはS36、トランザクタ開発S22に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因チェッカミスがある場合にはS36、チェッカ開発S21に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得しS24、テストベンチを取得S25,S26して、全体シミュレーションS27以降の作業を実施する。全体シミュレーションでエラーが検出されずS29、更に異なる条件で全体シミュレーションテストを行う場合にはS37、シミュレーション条件を変更してテストを行うS27。エラーなく全てのテストが終了すればS37、テストベンチ開発作業は終了となる。開発したテストベンチを用いて、上記図2の論理シミュレーション検証作業が行われるS17,S18。テストベンチは、例えば上記図3のような作業フローで開発が可能であるが、以下のような課題もある。例えば、上記図3の作業フローでは、全体シミュレーションの結果S27,S28、チェッカによりエラーが検出された場合S29、再シミュレーションで波形データが取得されS30,S31、その目視確認が行われるS32。開発済みの適正なテストベンチが用いられている場合、チェッカがエラーを検出すれば、検証対象の論理回路側に問題があると判断できる。しかし、テストベンチの開発段階では、チェッカ自体が適正であるか否かが確定しておらず、その品質に問題が残っているため、検出されたエラーがチェッカ自体のミスによるものである可能性がある。更に、テストベンチの開発段階では、シナリオに問題がある場合も、チェッカによりエラーとして検出されてくる。このようにエラーの要因がシナリオにある場合、その要因の特定には時間がかかる。その理由を、次の図5を参照して説明する。図5はシナリオ要因のエラー発生例を示す図である。図5において、Aはテストベンチの一例、B,Cは波形データの一例である。まず、チェッカがエラーを検出するのは、検証対象の出力端子が仕様違反、規格違反した動作に対してであり、検証対象の出力動作は入力パターンで決まる。つまり、検証対象への入力パターンシナリオの命令にミスがあると、チェッカによってエラーが検出される。今、図5Aのテストベンチ200における一方のモデル210aのシナリオ211aに従い、図5Bのような入力パターン出力信号1,2がトランザクタ212aを介して検証対象300に出力されたものとする。そして、その入力パターンに基づき、検証対象300からは、図5Cのような出力出力信号1,2が得られ、その出力がもう一方のモデル210bシナリオ211b、トランザクタ212bに送られるものとする。この検証対象300からの出力に対し、Bプロトコルチェッカ220bがX部にエラーを検出したものとする。即ち、この例では、Bプロトコルチェッカ220bが、出力のX部における、クロックの立ち上がりで出力信号1,2が共にハイHレベルとなるエラーを検出する。このBプロトコルチェッカ220bで検出されたエラーは、シナリオ211aからの入力パターンにおける、Y部の入力パターンミスが根本原因になっている。このように、検証対象300の出力についてBプロトコルチェッカ220bで検出されるエラー要因が、検証対象300に対する入力パターンにあると、エラーの検出ポイントX部と、その要因となる入力パターンY部の間には、時間差Tが生じる。エラー要因がシナリオ211aにあり、その要因を波形データから特定しようとすると、この時間差Tのために、解析が複雑になる場合があり、解析に長時間を要してしまう場合もある。尚、このような課題に対し、検証対象300への入力パターンの制約違反のチェックを行うチェッカを開発することも考えられる。例えば、Aプロトコルチェッカ220aに検証対象300への入力パターンをチェックするアサーションを実装することで、課題の改善には繋がる。しかし、チェッカ開発工数が増える、チェッカ開発が完了しないとチェックが行えない等、根本的な解決には至らない。シナリオは、例えば次のような作業フローで開発されている。図6はシナリオ開発作業フローの一例を示す図である。図6のシナリオ開発作業フローでは、開発者が、検証対象の設計に用いる仕様書S40を基に、シナリオの仕様の検討を行いS41、シナリオに設定する設定手順S42、シナリオを設定するうえでの制限事項設定制限事項S43を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成しS44,S45、それを組み込んだテストベンチを取得するS46,S47。そして、取得したテストベンチの動作確認のため、コンピュータを用いてシミュレーションを行いS48、その結果波形データを取得するS49。シナリオ開発段階でのテストベンチの構成例を図7に示す。シナリオ開発段階のシミュレーションS48に用いるテストベンチ200Aは、検証対象300、その検証対象300を動作させる、シナリオ211及びトランザクタ212を含むモデル210を備えているシナリオ開発環境。シナリオ開発環境には、検証対象の入出力をチェックする機能が設けられていない。そのため、シミュレーション時S48には、波形データを取得しS49、その波形データを目視確認することでS50、シナリオの動作を確認する。動作確認の結果、シナリオに問題が見つかった場合には、修正したシナリオを作成しS44,S45、それを組み込んだテストベンチを取得してS46,S47、再度シミュレーションを行いS48,S49、その波形データを確認するS50。動作確認でシナリオに問題がなくS50、更に異なる条件でシミュレーションテストを行う場合にはS51、シミュレーション条件を変更してテストを行うS48。エラーなく全てのテストが終了すればS51、シナリオ開発作業は終了となる。シナリオは、例えば上記図6のような作業フローで開発が可能であるが、以下のような課題もある。例えば、上記図6の作業フローでは、シナリオの動作確認を、シミュレーション時S48に取得した波形データS49の目視確認によって行っているS50。シナリオは、検証対象の状態やその受信状態よって、生成する入力パターンが変わるため、組み合わせを考慮すると、膨大な入力パターンが存在し得る。それら全ての組み合わせについて、波形データを目視で確認し、シナリオの動作確認を行うことは、困難である。そのため、組み合わせを考慮しない、機能毎の動作確認までしか行わない場合もある。このようにしてシナリオの動作確認を行い、その開発作業を完了させたとしても、全入力パターンの動作確認が済んでいるわけではないため、シナリオが設定制限事項に違反した入力パターンを生成してしまう等、その後の工程に影響を及ぼしてしまう場合がある。例えば、上記図3のテストベンチ開発作業フローで述べた全体シミュレーションS27,S28、更にその結果に基づく再シミュレーションS29~S31において、上記のようなシナリオ要因の問題が発生してしまう場合がある。以上説明したように、検証対象の論理回路検証に用いるシナリオの開発及びシナリオを組み込んだテストベンチの開発においては、検証の早い段階で、適正な、安定した品質のシナリオを取得することが難しい。適正なシナリオを取得するために、開発中のシナリオ、テストベンチを実際に動作させたときの波形データを取得し、それを開発者が目視で確認する作業が必要になるため、開発に時間を要してしまう。また、以上の説明では、シナリオ及びシナリオを組み込んだテストベンチの開発を例にしたが、論理回路を制御するファームウェアの開発においても同様のことが起こり得る。即ち、ファームウェアの開発段階では、作成したファームウェアを用いて論理回路を動作させ、エラーが検出された場合には、波形データの目視確認が行われる。このとき、エラー要因が論理回路側にあるのか、ファームウェア側にあるのかの判定に時間がかかってしまう。これは、上記図5において述べたのと同様に、エラーの発生タイミングとそのエラーを引き起こしたファームウェアの命令タイミングに時間差があり、波形データを用いた解析が複雑になるためである。このように論理回路を制御するためのファームウェアでも、その動作確認に時間を要してしまい、論理回路検証の早い段階で、適正な、安定した品質のファームウェアを取得することが難しい。シナリオ、ファームウェアのいずれの場合においても、それらを実際に動作させたときに取得される波形データの目視確認を行うことが、それらの開発効率を低下させ、更に、検証対象である論理回路の検証作業効率を低下させる一因になっている。そこで以下では、このような波形データの目視確認によらずに、適正なシナリオ、ファームウェアを効率的に取得する手法について、詳細に説明していく。ここでは主にシナリオを例に説明する。図8はシナリオ開発作業フローの一例を示す図である。図8のシナリオ開発作業フローでは、上記図6で述べた作業フロー同様、まず開発者が、検証対象の設計に用いる仕様書S60を基に、シナリオの仕様の検討を行いS61、シナリオの設定手順S62、シナリオの設定制限事項S63を抽出する。開発者は、抽出したこれらの情報を基に、シナリオを作成するS64,S65。シナリオの作成後、この図8のシナリオ開発作業フローでは、開発者が、シナリオの仕様検討時に抽出した設定制限事項S63、及び作成したシナリオS65を基に、設定制限リストを作成するS66,S67。設定制限リストには、例えば、作成したシナリオの所定記述部分の命令実行を制限する、上記設定制限事項の内容に対応した情報制限情報や、その記述部分に対応する所定行番号等の情報が含まれる。尚、設定制限リストの詳細については後述する。そして、コンピュータを用い、このような設定制限リストS67を入力とし、シナリオの動作をチェックするためのシナリオチェッカを自動生成するS68,S69。コンピュータは、例えば、設定制限リストS67の内容を、シナリオと同じ言語を用いて、所定記述のシナリオチェッカに書き換える。シナリオチェッカは、例えば、上記したシナリオの所定記述部分の命令が実行されるときに、その命令が上記制限情報を含むか否か、即ち、命令入力パターンが設定制限事項に違反していないかをチェックする。尚、この点の詳細については後述する。設定制限リストS67は、このシナリオチェッカの生成のほかS68,S69、シナリオへのシナリオチェッカ組み込み処理に用いられるS70,S71。コンピュータは、例えば、設定制限リストS67に示された、上記したシナリオの所定記述部分に対応した行番号を基に、シナリオのその行番号の箇所に、生成したシナリオチェッカS69を呼び出すための命令文を挿入するS70。これにより、当該所定記述部分の命令実行時に、生成されたシナリオチェッカS69を呼び出し可能にしたシナリオが取得されるS71。尚、この点の詳細については後述する。開発者は、このようにして取得されたシナリオチェッカS69と、そのシナリオチェッカS69を所定記述部分で呼び出し可能なシナリオS71とを組み込んだテストベンチを取得するS72,S73。シナリオ開発段階でのテストベンチの構成例を図9に示す。シナリオ開発段階のテストベンチ200Aは、検証対象300、その検証対象300を駆動するモデル210であるシナリオ211及びトランザクタ212を備えているシナリオ開発環境。このシナリオ211に、シナリオチェッカ213が、所定記述部分で呼び出されるように組み込まれている。シナリオ211に従って検証対象300を動作させると、シナリオ211の当該所定記述部分でシナリオチェッカ213が呼び出される。呼び出されたシナリオチェッカ213は、シナリオ211からの命令入力パターンに上記制限情報が含まれていないか、即ち、設定制限事項に違反した入力パターンが生成されていないか、チェックする。このようなチェックが、続く、コンピュータを用いたシミュレーションS74によって行われる。即ち、取得したテストベンチの動作確認のため、コンピュータを用いたシミュレーションが行われS74、コンピュータが、そのシミュレーション結果の情報ログファイルを生成するS75。ここで生成されるシミュレーション結果の情報は、テストベンチにシナリオチェッカが組み込まれているため、シナリオチェッカでエラーを検出したか否かを示すログファイルとなる。上記図6で述べた作業フローにおけるように、シミュレーション結果として、必ずしも波形データを取得することを要しない。開発者は、シミュレーション結果のログファイルの情報を基に、シナリオから検証対象に対し、設定制限事項に違反しない、適正な命令入力パターンが入力されたか否かを判断することができ、そのシナリオの動作確認を行うことができるS76。従って、シナリオの動作確認のために、上記のような波形データの目視確認を行うことが不要になり、シナリオの動作確認を効率的に行うことができる。作成したシナリオの動作確認の結果、エラーが検出された場合には、修正したシナリオを作成するS64,S65。そして、上記同様、設定制限リストの作成S66,S67、シナリオチェッカの生成S68,S69及び組み込みS70,S71を行い、テストベンチを取得してS72,S73、再度シミュレーションを行うS74,S75。そのログファイルの情報から、修正したシナリオの動作確認を行うS76。動作確認でエラーが検出されずS76、更に異なる条件でシミュレーションテストを行う場合にはS77、シミュレーション条件を変更してテストを行うS74。エラーなく全てのテストが終了すればS77、シナリオ開発作業は終了となる。更に、シナリオ開発後の工程について説明する。図10はテストベンチ開発作業フローの一例を示す図である。図10のテストベンチ開発作業フローでは、上記図3で述べた作業フロー同様、開発者が、テストベンチ仕様書S80を基に、テストベンチの構成要素の部品毎に、チェッカの開発S81、トランザクタの開発S82、シナリオの開発S83,S60~S77を行う。そして、テスト済みの各部品を取得しS84、それらを組み込んだテストベンチを取得するS85,S86。テストベンチ開発段階でのテストベンチの構成例を図11に示す。図11のテストベンチ200は、シナリオ211及びトランザクタ212を含むモデル210、プロトコルチェッカ220、及び期待値比較チェッカ230を備えているテストベンチ開発環境。このシナリオ211に、シナリオチェッカ213が組み込まれている。シナリオ開発図9で用いられたシナリオチェッカは、シナリオに組み込まれた構成呼び出し可能な構成になっており、テストベンチ開発のテストベンチにおいてもそのまま用いることができる。このようなテストベンチS86を用いて、上記図3で述べた作業フロー同様、検証対象の論理回路を動作させる全体シミュレーションを行うS87。この全体シミュレーションの結果は、テストベンチに組み込まれたチェッカプロトコルチェッカ、期待値比較チェッカ、シナリオチェッカによるチェック結果のログファイルとして出力されるS88。このログファイルの情報から開発者がエラーの発生有無を判断するS89。ここで、シナリオチェッカによりエラーが検出されている場合にはS89、シナリオ開発S83に戻り、シナリオのエラー要因を修正する。ここではシナリオチェッカを設けているため、このように全体シミュレーションS87のログファイルの結果確認段階で、シナリオのエラーシナリオミスを検出することが可能になっている。そのため、検証の比較的早い段階でシナリオの修正を行い、適正なシナリオを作成することができる。また、この時点でシナリオチェッカのエラーがなく、その他のチェッカエラーが検出されていれば、そのエラー要因が、検証対象か、テストベンチのシナリオ以外の部品にあると判断することができる。シナリオ以外についてのエラーが検出されている場合にはS89、コンピュータを用いた再シミュレーションを行って波形データを取得するS90,S91。取得した波形データを開発者が目視で確認し、エラー要因を特定するS92。エラー要因が検証対象の論理回路側にある場合にはS93、開発者が、その論理回路の修正を行いS94、修正後の論理回路を作成しS95、修正後の論理回路と共に、再度テストベンチを取得するS85,S86。そして、その再取得したテストベンチを用いて全体シミュレーションS87以降の作業を実施する。エラー要因がテストベンチ側にある場合、エラー要因は、テストベンチ内のトランザクタ又はチェッカに分けられるS96。トランザクタにエラー要因トランザクタミスがある場合にはS96、トランザクタ開発S82に戻り、トランザクタのエラー要因を修正する。チェッカにエラー要因チェッカミスがある場合にはS96、チェッカ開発S81に戻り、チェッカのエラー要因を修正する。そして、上記同様、単体テストを実施して各部品を取得しS84、テストベンチを取得S85,S86して、全体シミュレーションS87以降の作業を実施する。全体シミュレーションでエラーが検出されずS89、更に異なる条件で全体シミュレーションテストを行う場合にはS97、シミュレーション条件を変更してテストを行うS87。エラーなく全てのテストが終了すればS97、テストベンチ開発作業は終了となる。このように、シナリオにシナリオチェッカを組み込むことで、シナリオ開発及びテストベンチ開発において、シナリオミスについては、シミュレーションによる波形データの取得、取得した波形データの目視確認を不要にすることができる。それにより、適正なシナリオを比較的早期に作成することができ、シナリオ開発を効率化し、更に、テストベンチ開発、論理回路検証の効率化を図ることができる。上記図8のシナリオ開発作業フローには、上記図6の作業フローと異なり、設定制限リストの作成S66,S67、シナリオチェッカの生成S68,S69、シナリオチェッカの組み込みS70,S71、ログファイルの確認S75,S76を含む。これらのステップを含むことにより、上記のようなシナリオ開発の効率化が図られている。これらの各ステップは、以下のように行われる。まず、設定制限リスト作成ステップS66,S67について説明する。設定制限リストS67の作成は、開発者が行う。設定制限リストの作成は、設定制限事項S63及びシナリオS65を入力として行われる。設定制限事項には、検証対象に対する入力動作命令を制限する制限事項の内容が、自然言語で記載されているものとする。また、入力動作を制限する各事項について、対応する番号No.が付与されているものとする。シナリオは、トランザクタへの命令を記述したソースコードである。このような設定制限事項及びシナリオを用いて、開発者が設定制限リストを作成する。図12に設定制限リストのフォーマットの一例を示す。図12の設定制限リストのフォーマット400aには、各種情報を記入入力する欄401a~406aが設けられている。欄401aには、設定制限リストからシナリオチェッカ生成ステップS68、S69で生成するシナリオチェッカの名称チェッカ名が記入される。チェッカ名の欄401aには、生成するシナリオチェッカの機能を表すような任意の文字列が記入される。この欄401aに記入されたチェッカ名は、シナリオチェッカ生成ステップで生成されるファイル名の一部として使用される。また、このチェッカ名は、チェッカエラー時のメッセージに出力される文字列にも使用される。欄402aには、シナリオS65の、設定制限事項S63に関する入力動作を行う記述がある部分のファイルの名称参照ファイル名が記入される。欄403aには、シナリオチェッカ生成ステップで生成されるシナリオチェッカを、上記参照ファイル名のファイル中に挿入する行番号挿入行番号が記入される。欄404aのNo.番号1~nは、シナリオの入力動作についての各設定制限事項に対応して付与されている。入力1~mの欄405aには、各設定制限事項の入力動作の内容を決定する変数名が記入される。条件1_1~n_mの欄406aには、各設定制限事項の入力動作の内容を決定する変数名入力1~mに対応した具体的な変数が記入される。欄406aのその他条件1~mには、入力1~mの変数名に対応した変数以外の条件が記入される。欄405a、欄406aは、該当する条件がない場合には空欄とされる。開発者は、設定制限事項S63及びシナリオS65を用いて、フォーマット400aの各欄401a~406aの内容を記入し、設定制限リストS67を作成する。尚、設定制限リストを作成するうえで、行数及び列数は、設定制限事項の数番号の数及び変数名の数等に応じて適宜調節される。続いて、シナリオチェッカ生成ステップS68,S69について説明する。シナリオチェッカS69の生成は、開発者がシナリオチェッカ生成スクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの生成は、設定制限リストS67を入力として行われる。シナリオチェッカは1つ又は2つ以上のチェッカを含むファイルである。設定制限リストを入力としてシナリオチェッカ生成スクリプトを実行することにより、設定制限リストの内容を記述したシナリオチェッカが生成され、ファイルに出力される。このときのファイル名は[チェッカ名].[拡張子]となる。拡張子は、テストベンチS73で使用する言語に依存する。生成されるシナリオチェッカの記述内容は、テストベンチで使用する言語によって異なる。但し、いずれの言語においても、シミュレーションを実行してシナリオチェッカがエラーとなったときに、どの設定制限事項に対してのエラーであるかが判別できるようにする。そのため、ログファイルにエラーの内容と共に、[チェッカ名]_[番号i]i=1~nという文字列ラベル名を出力するようなシナリオチェッカを生成する。続いて、シナリオチェッカ組み込みステップS70,S71について説明する。シナリオチェッカS69の組み込みは、開発者がシナリオチェッカ組み込みスクリプトを起動することにより、コンピュータの処理によって行われる。シナリオチェッカの組み込みは、設定制限リストS67、シナリオチェッカS69、シナリオ65を入力として行われる。シナリオチェッカ組み込みスクリプトを実行することで、設定制限リストに記載された参照ファイル名欄402aに該当するファイルの、挿入行番号欄403aに該当する行番号に、シナリオチェッカS69のファイルのインクルード文が追加される。続いて、ログファイル確認ステップS75,S76について説明する。ログファイルの確認は、開発者が行う。ログファイルの確認では、シミュレーションを行った結果が出力されるログファイルS75の内容から、シナリオチェッカのエラー出力メッセージの有無を確認し、シナリオ修正の要否が判断される。シミュレーションにおいてシナリオチェッカのエラーが発生した場合、ログファイルには、エラーを検出したチェッカ名と、そのエラーの内容を示す情報設定制限事項の番号を含んだラベル名の文字列が出力される。このようなログファイルに含まれる情報を基に、シナリオ修正の要否が判断される。以下、上記手法を、実施例によって、より具体的に説明する。まず、第1実施例について説明する。図13は第1実施例に係る検証対象とシナリオの関係を示す図である。第1実施例のテストベンチで使用する言語は、SystemVerilogとする。図13の検証対象300はメモリモデルとなっており、内部にレジスタ領域301を有している。検証対象300への入力動作として、レジスタ領域301への書き込み動作がある。検証対象300には、アドレスADDR32’h00000000~32’hFFFFFFFCとデータDATAを指定した、シナリオ211からの書き込み動作の命令が、トランザクタ212を介して送られる。検証対象300では、指定されたアドレスADDRの示すレジスタ領域301に、指定されたデータDATAが格納される。即ち、まずシナリオ211において、レジスタ領域301への書き込み動作のアドレスADDRとデータDATAの内容を決定する。次いで、シナリオ211がトランザクタ212に、レジスタ領域301への書き込み動作を行うように、アドレスADDRとデータDATAの情報を与えて命令する。トランザクタ212が検証対象300に対してレジスタ領域301への書き込み動作の入力動作を行い、検証対象300にアドレスADDRとデータDATAの情報を伝える。検証対象300は、トランザクタ212からのレジスタ領域301への書き込み動作の情報を受けて、指定されたアドレスADDRのレジスタ領域301に、指定されたデータDATAを格納する。第1実施例では、このようなレジスタ領域301への書き込み動作に関し、シナリオ211を設定するうえでの設定制限事項があるものとする。図14は第1実施例に係る設定制限事項の一例を示す図である。図14に例示する設定制限事項500では、まず第1No.0001の設定制限事項の内容として、アドレス32’h00000000に対して32’h00000001の書き込み禁止が設定されている。更に、第2No.0002の設定制限事項の内容として、top.READYo==0のときアドレス32’h00000004に対して書き込み禁止が設定されている。図15は第1実施例に係るシナリオの記述部分の一例を示す図である。図15には、第1実施例のシナリオ211に含まれるレジスタ領域301への書き込み動作を行う記述部分一部を例示している。第1実施例のシナリオ211には、scenario.svという名称のファイル211faが含まれており、このファイル211faに、レジスタ領域301への書き込み動作を行う記述write_accessタスクが含まれている。上記のような設定制限事項500及びシナリオ211を用いた設定制限リストの作成を、例えば、図16~図19のような流れで行っていく。設定制限リスト400の作成では、まず図16のように、生成しようとするシナリオチェッカの機能を表すような任意の文字列、ここではWRITEという文字列を、チェッカ名の欄401図12のフォーマット400aの欄401aに記入する。次いで、図17のように、設定制限事項500に関する入力動作を行う記述のあるファイル211faの名称scenario.svを、参照ファイル名の欄402図12のフォーマット400aの欄402aに記入する。更に、後のシナリオチェッカ生成ステップで生成されるファイルをscenario.sv内でインクルードする行番号を、挿入行番号の欄403図12のフォーマット400aの欄403aに記入する。この第1実施例では、生成されるファイルを、レジスタ領域301に対する書き込み動作の内容アドレスADDR、データDATAを参照できる箇所である101行目に挿入することになるため、欄403には101を記入する。次いで、図18のように、入力変数名の欄405図12のフォーマット400aの欄405a入力1及び入力2に、変数名を記入する。この第1実施例では、レジスタ領域301に対する書き込み動作の内容を決定する変数がアドレスADDRとデータDATAであるため、欄405にADDR及びDATAを記入する。次いで、設定制限事項500に記載されている内容を解釈して、図19のように、各条件の欄406図12のフォーマット400aの欄406aに、具体的な条件を記入する。第1実施例では、No.0001の設定制限事項について、ADDRに対して32’h00000000を記入し、DATAに対して32’h00000001を記入し、その他条件は空欄とする。また、No.0002の設定事項については、ADDRに対して32’h00000004を記入し、DATAは空欄とし、その他条件に対してtop.READYo==0を記入する。このようにして設定制限リスト400の作成が行われる。続いて、作成された設定制限リスト400を用いたシナリオチェッカ213の生成について、図20及び図21を参照して説明する。ここでは、SystemVerilogを用いている場合を例に説明する。SystemVerilogのチェッカのアサーションは、[ラベル名]:assert[エラー条件]というフォーマットになる。[ラベル名]は任意の文字列となり、[エラー条件]はSystemVerilogの文法における論理式となる。このチェッカがシミュレーション中に実行されたときに、[エラー条件]の論理式が真を示すと、結果に、[ラベル名]と共に、エラーであることが記録される。SystemVerilogの場合のシナリオチェッカ生成では、シナリオチェッカ生成スクリプトを実行することにより、作成された設定制限リスト400を基に、[ラベル名]と[エラー条件]の部分の文字列を生成し、シナリオチェッカ213を生成する。シナリオチェッカ213は、[チェッカ名].svhというファイル名で生成する。図20に、シナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換形式を示す。図20には、設定制限リストのフォーマット400aの記載と、それから生成されるシナリオチェッカ213の記述との対応を示している。各No.番号1~nについて、それぞれ1つのチェッカが生成される。各チェッカの[ラベル名]は、チェッカ名_番号ii=1~nという文字列で生成される。[エラー条件]は、例えばNo.0001では、入力1==条件1_1入力2==条件1_2入力m==条件1_mその他条件1という文字列で生成される。但し、条件が空欄の場合は、その部分の論理式は生成されない。第1実施例では次の図21に示すようになる。図21は第1実施例に係るシナリオチェッカ生成スクリプトによる設定制限リストからシナリオチェッカへの変換例を示す図である。図21のように、設定制限リスト400より、No.0001については[ラベル名]がWRITE_0001、[エラー条件]がADDR==32’h00000000DATA==32’h00000001のチェッカ213aが生成される。また、設定制限リスト400より、No.0002については[ラベル名]がWRITE_0002、[エラー条件]がADDR==32’h00000004top.READYo==0のチェッカ213bが生成される。このようなチェッカ213a,213bを含むシナリオチェッカ213のファイル名は、WRITE.svhとなる。続いて、生成されたシナリオチェッカの組み込みについて、図22を参照して説明する。図22は第1実施例に係るシナリオチェッカ組み込みスクリプトによるシナリオチェッカのシナリオへの組み込み例を示す図である。図22のように、シナリオチェッカ組み込みスクリプトを実行することで、設定制限リスト400の情報を基に、シナリオ211のscenario.svのファイル211faの101行目に、WRITE.svhのインクルード文211cが挿入される。これにより、図21のようなシナリオチェッカ213がシナリオ211に組み込まれた記述シナリオチェッカ213を呼び出し可能な記述が得られる。このようなシナリオ211を用いたシナリオ開発やテストベンチ開発の段階で行われるシミュレーションの際には、シナリオのscenario.svの記述部分の命令実行時に、WRITE.svhのシナリオチェッカ213が呼び出される。そして、呼び出されたシナリオチェッカ213により、シナリオ211が実行する命令に、その実行を制限する制限情報アドレスADDR、データDATA、その他条件が含まれるか否かエラー条件の論理式が真を示すか否かがチェックされる。シナリオ211の命令実行を制限する制限情報が含まれていればエラーとなる。エラーか否かのチェック結果は、ログファイルとして出力される。続いて、シナリオチェッカを用いたシミュレーションの結果得られるログファイルについて、図23を参照して説明する。図23は第1実施例に係るログファイルの出力例である。第1実施例のシナリオチェッカ213がシミュレーションでエラーを検出した場合、シミュレーションの結果得られるログファイル600には、チェッカ213a,213bの[ラベル名]の文字列が出力される。即ち、この例では、WRITE_0001やWRITE_0002というラベル名601がログファイル600に出力される。開発者は、シミュレーションの結果得られるログファイル600を確認し、このようにチェッカ213a,213bの[ラベル名]が出力されている場合は、シナリオ211にエラーがあるとみなし、シナリオ211を修正する工程へ進むことになる。次に、第2実施例について説明する。上記第1実施例では、レジスタ領域301への書き込み動作における設定制限事項の場合について例示したが、このような単一の動作に対するもののほか、ある機能の一連の処理全体に対する設定制限事項の場合も同様に、上記手法を適用することができる。このような例を、第2実施例として説明する。第2実施例の検証対象は、次のような構成を有しているものとする。この検証対象は、DMADirectMemoryAccess機能を有している。検証対象は、複数のDMA機能設定レジスタを備え、DMA機能設定レジスタに行いたい動作の設定を書き込んでDMA機能が起動されると、DMA機能設定レジスタに書き込まれた設定値に従ってDMA機能の動作を行う。DMA機能設定レジスタには、転送方向OUT/IN、DMAモードブロック/デマンド、バーストモードSINGLE/INCRの各設定項目があるものとする。尚、DMAモードのブロックは、1回の転送要求にてブロック単位で1回の転送を行うモードを示し、デマンドは、転送要求がアクティブの期間、転送を行うモードを示す。バーストモードのSINGLEは、1回の転送要求で単独転送を行うモードを示し、INCRは、インクリメント式のバースト転送を行うモードを示す。このほか、DMA機能設定レジスタには更に、総転送数LENGTH16bit、転送元SRCアドレス32bit、転送先DSTアドレス32bitの各設定項目があるものとする。このような検証対象のDMA機能の動作に関し、シナリオ211を設定するうえでの設定制限事項があるものとする。図24は第2実施例に係る設定制限事項の一例を示す図である。図24に例示する設定制限事項510では、まずNo.0001の設定制限事項の内容として、総転送数0でのDMA起動禁止が設定されている。No.0002の設定制限事項の内容として、転送方向がIN且つDMAモードがデマンドでのDMA起動禁止が設定されている。No.0003の設定制限事項の内容として、DMAモードがブロック且つバーストモードがINCRでのDMA起動禁止が設定されている。図25は第2実施例に係るシナリオの記述部分の一例を示す図である。図25には、第2実施例のシナリオ211に含まれるDMA機能の起動処理を行う記述部分一部を例示している。第2実施例のシナリオ211には、scenario.svという名称のファイル211fbが含まれており、このファイル211fbに、DMA機能の起動処理を行う記述dma_processタスクが含まれている。dma_processタスクは、入力されたDMA機能設定レジスタの設定項目の情報に従ってレジスタの書き込みを行い、一連のDMA機能の起動処理を行うタスクである。上記のような設定制限事項510及びシナリオ211を用いて作成される、第2実施例に係る設定制限リストの一例を図26に示す。図26の設定制限リスト410は、上記第1実施例と同様の手順で作成することができる。この第2実施例の設定制限リスト410では、チェッカ名の欄411図12のフォーマット400aの欄401aにDMAという文字列が記入される。参照ファイル名の欄412図12のフォーマット400aの欄402aには、DMA機能の起動処理を行う記述のあるファイル211fbの名称scenario.svが記入される。挿入行番号の欄413図12のフォーマット400aの欄403aには、シナリオチェッカ生成ステップで生成されるファイルをインクルードする行番号が記入される。この第2実施例では、生成されるファイルを、DMA機能の起動処理の内容ディレクトリDIR、DMAモードDMA_MODE、バーストモードBURST_MODE、LENGTHを参照できる行である207が欄413に記入される。入力変数名の欄415図12のフォーマット400aの欄405aには、DMA機能の起動処理の内容を決定するディレクトリDIR、DMAモードDMA_MODE、バーストモードBURST_MODE、LENGTHの各変数名が記入される。各条件の欄416図12のフォーマット400aの欄406aには、設定制限事項510の内容が解釈されて具体的な制限情報が記入される。第2実施例では、No.0001の設定制限事項について、LENGTHに対して16’h0000が記入され、それ以外は空欄とされる。No.0002の設定事項については、DIR及びDMA_MODEに対して1’b1が記入され、それ以外は空欄とされる。No.0003の設定事項については、DMA_MODEに対して1’b0が記入され、BURST_MODEに対して1’b1が記入され、それ以外は空欄とされる。図27は第2実施例に係るシナリオチェッカの一例を示す図である。上記のような設定制限リスト410を基に、シナリオチェッカ生成スクリプトを実行することで、No.0001,0002,0003の各チェッカ213c,213d,213eを含むシナリオチェッカ213が生成される。各チェッカ213c,213d,213eは、第1実施例同様、[ラベル名]:assert[エラー条件]というフォーマットに従って生成される。この第2実施例の場合、生成されるシナリオチェッカ213は、DMA.svhというファイル名になる。そして、上記第1実施例同様、シナリオチェッカ組み込みスクリプトを実行し、設定制限リスト410を基に、これらのチェッカ213c,213d,213eを含むシナリオチェッカ213をファイル211fbの207行目に呼び出すインクルード文を挿入する。それにより、それにより、当該シナリオチェッカ213が、ファイル211fbの207行目で呼び出されるように組み込まれたシナリオ211が得られるようになる。このようなシナリオ211が用いられてシナリオ開発やテストベンチ開発で行われるシミュレーションでは、エラー検出の際のログファイルにDMA_0001、DMA_0002、DMA_0003の[ラベル名]が出力される。開発者は、シミュレーションの結果得られるログファイルを確認し、このようにチェッカ213c,213d,213eの[ラベル名]が出力されている場合は、シナリオ211にエラーがあるとみなし、シナリオ211を修正する工程へ進む。以上説明した手法によれば、シナリオ開発段階、テストベンチ開発段階で行われるシミュレーションにおいて、シナリオのエラーの有無及びエラーの内容を示す情報を、ログファイルの確認で行うことができる。そのため、シナリオのエラーが検出されたときに、敢えて波形データを取得することが不要になり、更に、取得した波形データを開発者が目視で確認し解析することによってそのエラー要因を特定するといった作業が不要になる。従って、シナリオ要因のエラーの解析時間を短縮することが可能になる。例えば、テストベンチ開発段階で、シナリオ要因のエラーとそれ以外のエラーがそれぞれ5割の割合で発生していた場合、全体としてのエラーの解析時間がおよそ2分の1になることになる。更に、以上説明した手法では、シナリオ開発段階でのシナリオの動作確認検証をログファイルの確認で行うことができる。一方、シナリオの動作確認を波形データの目視確認によって行うと、時間がかかり、あまり多くの動作について確認が行えない場合があった。上記手法によれば、シナリオの動作確認をログファイルの確認で行え、波形データの目視確認を不要とすることができるため、動作確認に要する時間を短縮できる。その結果、より多くの動作について確認を行うことも可能になり、シナリオの動作確認を十分に行うことが可能になる。尚、以上の説明では、シナリオ及びシナリオを組み込んだテストベンチの開発を例にしたが、論理回路を制御するファームウェアの開発においても、上記同様の手法を用いることができる。即ち、検証対象の仕様、ファームウェアの仕様等を基に、ファームウェアの制御動作を設定するうえでの設定制限事項を得る。その設定制限事項を基に、上記シナリオの例に従い、ファームウェアの所定記述部分の命令実行を制限する制限情報を含んだ設定制限リストを作成する。そして、作成した設定制限リストの内容を記述したファームウェアのチェッカを生成し、生成したチェッカを、ファームウェアに対し、その所定記述部分の命令実行時に呼び出せるように組み込む。このファームウェアを用いて論理回路を動作させ、所定記述部分でチェッカを呼び出し、その所定記述部分の命令にその実行を制限する制限情報が含まれるか否かを、呼び出したチェッカによってチェックする。ファームウェアの命令実行を制限する制限情報が含まれていればエラーとなる。エラーの有無及びエラーの内容を示す情報を、ログファイルとして出力する。このような手法によれば、検出されるエラーがファームウェアによるものであることをログファイルから判定でき、更に、ファームウェア要因のエラーについて、波形データの解析が不要になる。そのため、ファームウェア要因のエラーを波形データの目視確認で行う場合に比べ、エラーの解析時間を短縮することが可能になる。尚、上記のシナリオ、テストベンチ、及びファームウェア、並びにそれらを用いた対象回路の検証は、コンピュータを用いて実現することができ、その場合、コンピュータが実行する処理機能の内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、HD、フレキシブルディスクFD、磁気テープ等がある。光ディスクには、DVD、DVD-RAM、CD-ROM/RW等がある。光磁気記録媒体には、MOMagnetoOpticaldisk等がある。プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD-ROM等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラム若しくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。尚、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。また、上記の処理機能の少なくとも一部を、DSPDigitalSignalProcessor、ASICApplicationSpecificIntegratedCircuit、PLDProgrammableLogicDevice等の電子回路で実現することもできる。"