JP2006178775A - 検証環境作成装置及びその処理方法 - Google Patents

Abstract

【課題】 論理検証を行う際に、論理検証の検証環境を自動的に作成することで論理回路の論理検証期間を短縮させる。
【解決手段】 複数の検証装置を登録している検証装置ライブラリから検証対象の論理回路と接続可能な検証装置を検索し、検索された検証装置を、検証対象の論理回路を検証装置により機能検証するための検証環境にインスタンスし、その検証装置と論理回路を接続し、接続された論理回路の未接続ポートを所定の処理ルールに従って処理して検証環境を作成する。
【選択図】 図１

Description

本発明は、ＬＳＩ開発における論理回路を機能検証する技術に関するものである。

現在、ＬＳＩ開発における主たる論理検証方法として、コンピュータ上で検証対象である論理回路（ＤＵＴ：Design Under Test）の動きをシミュレートさせる動的論理シミュレーションを用いた検証方法が提案されている。この方法は、ＤＵＴを検証するために、検証環境であるテストベンチを作成し、ＤＵＴに対してテストパターンを入力し、ＤＵＴからの出力及び内部状態のチェックを行うというものである（例えば、特許文献１参照）。

また、動的論理シミュレーションを用いた初歩的な論理検証方法では、ＤＵＴのポートへの“０”や“１”といった直接値の代入パターンを羅列したテストパターンを作成し、シミュレーションにおいて、そのテストパターン通りにＤＵＴの信号を変化させることによりバスのトランザクションを発生させ、それによるＤＵＴからの出力信号や内部状態などのシミュレーション結果の波形を目視により確認を行っている。従って、テストベンチによる検証は、ＤＵＴをインスタンスしただけの非常にシンプルなものであり、論理検証作業は、テストパターン作成と結果確認に時間を要していた。

しかし、ＬＳＩの複雑化・大規模化に伴い、上述の初歩的な論理検証方法では、テストパターン作成の負荷や目視による検証負荷が指数関数的に増大し、限られた時間内で確度の高い確実な検証が不可能となってきている。そこで、より効率的に論理検証を行うために、バスのトランザクションを発生させるためのバスモデルやバスプロトコル又はＤＵＴの内部状態を監視するモニタといった検証装置を用いた動的論理シミュレーションによる論理検証が行われている。

この論理検証方法では、モデルやモニタといった検証装置を作成し、それら検証装置をインスタンスし、ＤＵＴに接続したテストベンチを作成することでバストランザクションを発生させるためのモデルへのコマンド発行、及びモデルがトランザクションにより得たデータと期待値比較を行うテストを作成することで論理検証が行われる。このようなバスプロトコルやＤＵＴの内部状態の論理検証は、テスト実行による動的論理シミュレーション中にモニタにより自動的に行われる。この方法では、論理検証作業はテスト作成の他にテストベンチ作成に時間を要することとなる。また、テストベンチの作成は、各検証装置作成とその検証装置を用いたＤＵＴのテストベンチ作成の２つに大別される。

しかし、近年ＬＳＩの大規模化・複雑化に対して、ＬＳＩの開発効率を上げるために、バスやインターフェースの共通化が図られ、そのため、モデルやモニタを含む様々な検証装置もＬＳＩの開発ごとに作成するのではなく、以前のＬＳＩ開発で作成した検証装置を流用することが可能となってきている。従って、テストベンチの作成における作業負荷は、検証装置自身の作成よりも検証装置を用いたＤＵＴのテストベンチ作成のほうにシフトしてきている。以下、「テストベンチ作成」は、検証装置を用いたＤＵＴのテストベンチ作成を意味するものとする。

また、工業製品は小品種大量生産から多品種少量生産に移行してきており、ＬＳＩ開発においても短期間での多機種開発が要求されている。

このような状況の中、現在、テストベンチ作成は、手作業によって行われている。

また、米国Mentor社のデザインエントリ用のＥＤＡ（Electronic Design Automation）ツールである“ＨＤＳ”では、ワークエリア上にインスタンスしたＤＵＴのポートと検証装置のポートを、ポート名から類推して接続する機能を有している。

また、特許文献２には、回路設計において対象モデルの論理シミュレーションの実行に必要なテストパターン入力用のシミュレーション用回路にテストパターンを組込みかつ回路設計で用いられる言語で記述されたテストベンチを生成するテストベンチ生成システムが開示されている。
特開2000-132416号公報 特開平10-124557号公報

上述したように、テストベンチ作成は、従来手作業によって行われている。もしくは、米国Mentor社の“ＨＤＳ”を用いることにより半自動化が可能であるが、必要な検証装置のピックアップ、検証装置のインスタンス、そして、ＤＵＴにおける検証装置の接続されていないポートの処理に関しては、少なくともテストベンチ作成担当者が手作業で行わなければならない。
一般的に、ＬＳＩ開発期間の約７０％は、論理検証に費やされていると言われており、論理検証期間の短縮のためには、テストベンチ作成の時間を短縮することが重要となっている。しかし、手作業で行うということは、ミスが含まれることが考えられ、またＬＳＩは、今後益々複雑化・大規模化することが容易に予想されることから、手作業によるテストベンチ作成の負荷も益々増大するという問題がある。また、手作業によるテストベンチ作成では、短期開発・短期検証に対応することは不可能である。

本発明は、上記課題を解決するためになされたもので、論理検証を行う際に、論理検証の検証環境を自動的に作成することで論理回路の論理検証期間を短縮させることを目的とする。

本発明は、検証対象の論理回路を検証装置により機能検証するための検証環境を作成する検証環境作成装置であって、複数の検証装置を登録している検証装置ライブラリから前記検証対象の論理回路と接続可能な検証装置を検索する検索手段と、前記検索手段で検索された検証装置を前記検証環境にインスタンスし、当該検証装置と前記論理回路を接続する手段と、前記接続された論理回路の未接続ポートを所定の処理ルールに従って処理する手段とを有することを特徴とする。

また、本発明は、検証対象の論理回路を検証装置により機能検証するための検証環境を作成する検証環境作成装置の処理方法であって、複数の検証装置を登録している検証装置ライブラリから前記検証対象の論理回路と接続可能な検証装置を検索する検索工程と、前記検索工程で検索された検証装置を前記検証環境にインスタンスし、当該検証装置と前記論理回路を接続する工程と、前記接続された論理回路の未接続ポートを所定の処理ルールに従って処理する工程とを有することを特徴とする。

本発明によれば、論理検証を行う際に、論理検証の検証環境を自動的に作成することで論理回路の論理検証期間を短縮させることができる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。尚、本実施形態では、検証対象としての論理回路（ＤＵＴ：Design Under Test）を検証する際に検証環境であるテストベンチを作成するテストベンチ作成装置の構成及び動作について説明する。

図１は、本実施形態におけるテストベンチ作成装置の構成の一例を示す図である。図１において、１０１はテストベンチの作成対象であるＤＵＴ、１０２は本実施形態におけるテストベンチ作成装置、１０３はテストベンチ作成装置１０２が作成したテストベンチ、１０４はテストベンチ作成装置１０２が出力する処理結果レポート、１０５は検証装置を登録した検証装置ライブラリ、１０６は未接続ポートを処理する未接続ポート処理ルールである。尚、検証装置ライブラリ１０５及び未接続ポート処理ルール１０６の詳細な構成については、図２及び図３を用いて更に詳述する。

また、テストベンチ作成装置１０２は、検証装置ライブラリ１０５を記憶する検証装置ライブラリ記憶部１１１、ＤＵＴ１０１と接続可能な検証装置を検証装置ライブラリ記憶部１１１から検索する検証装置検索部１１２、ＤＵＴ１０１と検証装置とをテストベンチにインスタンスし、お互いに接続するインスタンス及び接続部１１３、未接続ポート処理ルール１０６を記憶する処理ルール記憶部１１４、未接続ポートを処理する未接続ポート処理部１１５、未接続ポート処理部１１５での処理結果をレポートするレポート部１１６から構成されている。

以上の構成において、テストベンチ作成装置１０２は検証装置ライブラリ記憶部１１１により検証装置ライブラリ１０５に登録されている検証装置を保持する。また処理ルール記憶部１１４により未接続ポート処理ルール１０６を保持する。テストベンチ作成対象であるＤＵＴ１０１をテストベンチ作成装置１０２に入力すると、検証装置検索部１１２により、検証装置ライブラリ１０５からＤＵＴ１０１と接続可能な検証装置を検索し、インスタンス及び接続部１１３により、ＤＵＴ１０１と該当する検証装置をテストベンチにインスタンスし、お互いを接続する。その後、未接続ポート処理部１１５により、検証装置と未接続であるＤＵＴのポートに対して、未接続ポート処理ルール１０６に従って未接続ポートを固定することによりＤＵＴ１０１のテストベンチ１０３を完成させて出力する。またレポート部１１６により、接続した検証装置名、検証装置のドキュメント名、ＤＵＴ１０１の未接続ポートに対する処理内容を含む処理結果レポート１０４を出力する。

次に、図２を用いて検証装置をライブラリとして登録した検証装置ライブラリ１０５の詳細な構成について説明する。

図２は、本実施形態における検証装置ライブラリ１０５の構成の一例を示す図である。図２に示すように、検証装置ライブラリ１０５には検証装置の各種情報が登録され、その登録項目として、検証装置がマスターモデルなのか、スレーブモデルなのか、バスモニタなのかといった検証装置の種類を示す種類２０１と、検証装置名２０２と、ドキュメントを格納したファイルサーバーへのパスを示すドキュメント格納場所２０３と、オプション信号であり、使用しなくてもよい検証装置ポートを示す未使用可能ポート２０４と、複数のバス幅対応をサポートするためのカスタマイズパラメータ２０５と、検証装置のトップモジュールを格納したファイルサーバーへのパスを示す格納場所２０６がある。そして、上述した検証装置のドキュメント及びトップモジュールはファイルサーバー２０７に格納される。

図２に示す例では、検証装置ライブラリ１０５の先頭に、種類２０１が「バスマスターモデル」、検証装置名２０２が「バスＡ_マスターモデル」、検証装置のドキュメントの格納場所２０３が「…/BusA_Model/Master.pdf」、未使用可能ポート２０４が「wait」、バス幅のカスタマイズパラメータ２０５が「BUS_WIDTH」、検証装置のトップモジュールの格納場所２０６が「/…/busa_master_model/top.v」のモデルが登録されている。

尚、１つの検証装置が複数のファイル若しくはブロックから構成されている場合に対応するため、格納場所２０６にはポートを参照するべき検証装置のトップモジュールを登録する。

更に、登録項目として種類２０１を持つことにより、テストベンチ作成装置１０２が、検証装置を検索する際に、種類２０１により検索対象範囲を切り替え可能となる。また、使用したい検証装置の種類のみを検索対象とする。若しくは、使用したくない検証装置の種類を検索対象から除外する。更に、検索対象範囲は種類２０１のみならず、任意に設定しても良い。

また、登録項目としてドキュメント格納場所２０３に検証装置のドキュメント格納場所を登録することにより、テストベンチ作成装置１０２が出力する処理結果レポート１０４において、接続した検証装置のドキュメントの場所を示すことが可能となる。

そして、ドキュメント格納場所２０３及び格納場所２０６には、パスを登録するので、ドキュメント及び検証装置をファイルサーバー２０７上に任意に置くことができる。

次に、図３を用いて未接続ポートを処理するルールを定義した未接続ポート処理ルール１０６の詳細な構成について説明する。

図３は、本実施形態における未接続ポート処理ルール１０６の詳細な構成を示す図である。図３に示すように、未接続ポートの処理ルールとして、ポートの方向３０１とポート名３０２を条件に、ポートの処理３０３の内容を定義している。尚、異なる処理ルールをテストベンチ作成装置１０２に格納することで未接続ポートの処理ルールを変更することができる。

図３に示す例では、ポートの方向３０１が「入力」で、ポート名３０２の最後が「_l」、「_L」、「_x」、「_X」、の場合は、ロウアクティブと判断し、ポートの処理３０３を「ハイ固定」とし、それ以外の「入力」ポートでは、ハイアクティブと判断し、ポートの処理３０３を「ロウ固定」とするように定義されている。

また、ポートの方向３０１が「双方向」で、ポート名３０２の最後が「_l」、「_L」、「_x」、「_X」の場合は、ポートの処理３０３を「プルアップ」とし、それ以外の「双方向」ポートでは、ポートの処理３０３を「プルダウン」とするように定義されている。

そして、ポートの方向３０１が「出力」の場合は、何も接続せず、ポートの処理３０３をオープンとするように定義されている。

尚、上述した処理ルールはこれだけに限らず、例えばユーザ毎に任意のルールを持っても良い。

次に、上述したテストベンチ作成装置１０２において、検証装置ライブラリ１０５及び未接続ポート処理ルール１０６に基づいてＤＵＴ１０１のテストベンチ１０３を作成する処理を、図４及び図５を用いて説明する。

尚、本実施形態では、ＤＵＴ１０１と接続可能な検証装置を検証装置ライブラリ１０５から検索する処理と、テストベンチへのインスタンス及びＤＵＴ１０１との接続処理とは、検証装置ライブラリ１０５の種類２０１に応じて、モニタ検証装置以外を一括対象とした処理と、モニタ検証装置を対象とした処理の別々の処理を有する。これは、モニタ検証装置以外の検証装置がＤＵＴ１０１の同一ポートに複数接続されることはないが、モニタ検証装置以外とモニタ検証装置とが同一ポートに接続されることはあり得るからである。

図４及び図５は、テストベンチを作成するテストベンチ作成処理を示すフローチャートである。上述のモニタ検証装置以外を対象とした処理がステップＳ４０４〜Ｓ４１０で、モニタ検証装置を対象とした検索とインスタンスと接続を行う処理がステップＳ５０３〜Ｓ５１０である。

まず、ステップＳ４０１で、テストベンチを作成するＤＵＴ１０１のトップモジュールのパスを入力する。次に、ステップＳ４０２で、ＤＵＴ１０１をインスタンスしたテストベンチのトップモジュールを作成する。

次に、ステップＳ４０３では、検証装置ライブラリ１０５にモニタ検証装置以外で検索対象となる検証装置があるか否かを判定する。ここで、モニタ検証装置以外で検索対象となる検証装置がある場合にはステップＳ４０４へ進む。また、モニタ検証装置以外で検索対象となる検証装置がない場合にはステップＳ５０１へ進む。

尚、本実施形態では、上述の判定は、モニタ検証装置以外の種類の検証装置がＤＵＴと接続可能か否かを判断することで判定しており、具体的には、検証装置の全てのポートとＤＵＴ１０１のポートにおいて以下の３つの条件が成立する場合、モニタ検証装置以外で検索対象となる検証装置があると判定するものである。
（１）ポート名３０２が一致。
（２）ポートの幅が一致。例えば、ＤＵＴ１０１のポートが１ビットであれば検証装置のポートも１ビットであり、ＤＵＴ１０１のポートが８ビットであれば検証装置のポートも８ビットであること。
（３）ポートの方向３０１に矛盾がない。例えば、ＤＵＴ１０１のポートの方向３０１が入力であれば、検証装置のポートの方向は出力であること。

ステップＳ４０４で、検証装置が未接続で、かつ、接続可能判定を行っていないＤＵＴ１０１のポートがあるか否かをチェックする。ここで、ポートが存在する場合はステップＳ４０５へ進む。また、ポートが存在しない場合はステップＳ５０１へ進む。

ステップＳ４０５では、ＤＵＴ１０１の接続可能判定をしていない１ポートに注目し、「ポート名」と「ポートの方向」を検索キーワードに検証装置ライブラリ１０５から接続できる可能性のある検証装置のポートを検索する。ここで、該当する検証装置のポートがある場合はステップＳ４０６へ進む。また、該当する検証装置のポートがない場合はステップＳ４１１へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ４０６では、該当する検証装置の持つ他の全てのポートと接続できる可能性のあるポートがＤＵＴ１０１に存在するかを「ポート名」と「ポートの方向」を検索キーワードに逆検索を行う。但し、ＤＵＴ１０１に存在しないポートが未使用可能ポート２０４のみである場合は、接続できる可能性があるポートがＤＵＴに存在すると判定する。

ここで、ポートが存在する場合はステップＳ４０７へ進む。また、ポートが存在しない場合はステップＳ４１１へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ４０７では、該当する全てのポートにおいて、「ポートの幅」が一致するか否かを判定する。尚、検証装置のポートの幅がカスタマイズパラメータにより可変の場合は、全てのポートで「ポートの幅」が一致するカスタマイズパラメータが存在する場合に一致すると判断する。

ここで、一致すると判定した場合はステップＳ４０８へ進む。また、一致しないと判定した場合はステップＳ４０８へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ４０８では、「ポートの名」、「ポートの方向」、「ポートの幅」の全てが一致するので、該当する検証装置がＤＵＴ１０１と接続可能であると判定する。そして、ステップＳ４０９で、ユーザーに該当する検証装置の検証装置名２０２を示し、接続してよいか否かを問い合わせる。この処理により、接続可能な検証装置であっても、検証項目によっては必要とせず、動的論理シミュレーションのスピードを低下させたくない場合、ユーザーは接続させないようにすることもできる。

ここで、ユーザーが接続してよいと判定した場合はステップＳ４１０へ進み、また接続させないと判定した場合はステップＳ４１１へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ４１０では、３つの条件が一致した検証装置をテストベンチにインスタンスし、ＤＵＴ１０１と接続する。尚、カスタマイズパラメータが存在する場合は、検証装置インスタンス時に適用する。そして、ステップＳ４１１へ進み、そのＤＵＴポートは接続可能判定済みとする。

上述したように、ＤＵＴポートの管理を行い、検証装置が未接続、かつ、接続可能なモニタ以外の検証装置があるか否かを検証装置ライブラリ１０５から検索していないＤＵＴポートがなくなるまで、上述したステップＳ４０５からステップＳ４１１までのループを繰り返し、ＤＵＴポートがなくなるとステップＳ５０１へ進む。

次に、モニタ検証装置がＤＵＴ１０１と接続可能である場合は、モニタ検証装置の全てのポートとＤＵＴ１０１のポートにおいて以下の２つの条件が成立する場合である。
・「ポート名」が一致。
・「ポートの幅」が一致。例えば、ＤＵＴ１０１のポートが１ビットであれば検証装置のポートも１ビット、ＤＵＴのポートが８ビットであれば検証装置のポートも８ビットであること。

尚、「ポートの方向」が条件にないのは、モニタ検証装置は、信号をサンプリングするのみ、即ち、入力のみであるためである。

まず、ステップＳ５０１で、モニタ検証装置を対象とした検索とインスタンスと接続を行う処理を実行する前に、ステップＳ４１１で行った接続判定情報をクリアする。そして、ステップＳ５０２で、検証装置ライブラリ１０５の検索対象にモニタ検証装置があるか否かを判定する。ここで、モニタ検証装置がある場合、モニタ検証装置を対象とした検索とインスタンスと接続を行うステップＳ５５０３へ進み、またモニタ検証装置がない場合はステップＳ５１１へ進み、未接続ポートの処理を行う。

ステップＳ５０３では、モニタ検証装置が未接続で、かつ、接続可能判定をしていないＤＵＴポートがあるか否かをチェックする。ここで、ポートが存在する場合はステップＳ５０４へ進む。また、ポートが存在しない場合はステップＳ５１０へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ５０４では、ＤＵＴ１０１の接続可能判定をしていないある１ポートに注目し、「ポート名」を検索キーワードに検証装置ライブラリ１０５から接続できる可能性のあるモニタ検証装置のポートを検索する。ここで、接続できる可能性のあるモニタ検証装置のポートが存在する場合はステップＳ５０５へ進む。また、存在しない場合はステップＳ５１０へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ５０５では、該当する検証装置のポートがある場合、該当する検証装置の持つ他の全てのポートと接続できる可能性のあるポートが、ＤＵＴ１０１に存在するかを、「ポート名」を検索キーワードに逆検索を行う。

但し、ＤＵＴ１０１に存在しないポートが未使用可能ポート２０４のみである場合は、接続できる可能性があるポートがＤＵＴ１０１に存在すると判定する。

ここで、存在する場合はステップＳ５０６へ進む。また、存在しない場合はステップＳ５１０へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ５０６では、該当する全てのポートにおいて、「ポートの幅」が一致するか否かを判定する。モニタ検証装置のポートの幅が、カスタマイズパラメータ２０５により可変の場合、全てのポートで「ポートの幅」が一致するカスタマイズパラメータ２０５が存在する場合、一致すると判定する。

ここで、全てのポートで「ポートの幅」が一致すると判定した場合はステップＳ５０７へ進む。また、一致しないと判定した場合はステップＳ５１０へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ５０７では、「ポートの名」、「ポートの幅」の全てが一致するので、該当するモニタ検証装置がＤＵＴ１０１と接続可能であると判定する。そして、ステップＳ５０８で、ユーザーに該当するモニタ検証装置の検証装置名２０２を示し、接続してよいか否かを問い合わせる。この処理により、接続可能なモニタ検証装置であっても、検証項目によっては必要とせず、動的論理シミュレーションのスピードを低下させたくない場合、ユーザーは接続させないようにすることもできる。

ここで、ユーザーが接続してよいと判定した場合はステップＳ５０９へ進み、また接続させないと判定した場合はステップＳ５１０へ進み、そのＤＵＴポートは接続可能判定済みとする。

ステップＳ５０９では、２つの条件が一致したモニタ検証装置をテストベンチにインスタンスし、ＤＵＴ１０１と接続する。尚、カスタマイズパラメータが存在する場合は、検証装置インスタンス時に適用する。そして、ステップＳ５１０へ進み、そのＤＵＴポートは接続可能判定済みとする。

上述したように、ＤＵＴポートの管理を行い、モニタ検証装置が未接続、かつ、接続可能なモニタ検証装置があるか否かを検証装置ライブラリ１０５から検索していないＤＵＴポートがなくなるまで、上述したステップＳ５０４からステップＳ５１０までのループを繰り返し、ＤＵＴポートがなくなるとステップＳ５１１へ進む。

ステップＳ５１１では、信号が接続されていないテストベンチ上の全てのＤＵＴ未接続ポートに対して図３に示した未接続ポートの処理ルールに従って信号を固定する。次に、ステップＳ５１２で、未接続ポートがなくなるまでステップＳ５１１の処理を繰り返し、未接続ポートがなくなるとステップＳ５１３へ進む。

ステップＳ５１３で、ＤＵＴ１０１のテストベンチ１０３が完成し、ステップＳ５１４で、ＤＵＴ１０１のテストベンチ１０３の出力と、接続した検証装置名とその検証装置のドキュメントの格納先と未使用検証装置ポート、検証装置カスタマイズパラメータ、未接続ポートに対して行った処理内容を含む処理結果レポート１０４を出力し、テストベンチ作成装置の処理を終了する。

尚、検証装置名と検証装置のドキュメント格納先は、検証装置ライブラリ１０５から取得する。

図６は、Verilogを用いた論理検証を説明するための図である。図６では、検証装置を検索する処理と未接続ポートの処理をＨＤＬ（Hardware Description Language）の１つであるVerilogを用いて説明したものである。

図６において、６０１はテストベンチ１０３を作成する検証対象であるＤＵＴ１０１のポートである。６０２はＤＵＴ１０１のポートをVerilogで記述した例である。６０３は検証装置ライブラリ１０５に登録されている検索対象の一つであるバスB_マスターモデルのポートである。６０４はバスB_マスターモデルのポート６０３をVerilogで記述した例である。

６０５は検証装置ライブラリ１０５に登録されている検索対象の一つであるバスA_マスターモデルのポートである。６０６はバスA_マスターモデルのポート６０５をVerilogで記述した例である。６０７は検証装置ライブラリ１０５に登録されている検索対象の一つであるバスA_スレーブモデルのポートである。６０８はバスA_スレーブモデルのポート６０７をVerilogで記述した例である。

６０９は検証装置ライブラリ１０５に登録されている検索対象の一つであり、種類としてはモニタに属するバスA_モニタのポートである。６１０はバスA_モニタのポート６０９をVerilogで記述した例である。６１１はＤＵＴの未接続ポートに対する処理である。

尚、図６に示す（１）〜（７）及び［×］［○］は、テストベンチ作成における処理の順番及び判定結果を示すものである。

まず、ＤＵＴ１０１の１ポートであるAREQと接続可能なモニタ以外の検証装置のポートを「ポート名」、「ポートの方向」を検索キーワードとして検証装置ライブラリ１０５から検索する。（１）で、バスB_マスターモデルのポート６０３を全て検索し、その結果は［×］であり、接続可能なポートがないことを示している。次の（２）で、バスA_マスターモデルのポート６０５を検索する。その結果、「ポート名」が一致するポートAREQがあるが、「ポートの方向」がＤＵＴ１０１とモデルでは矛盾するので、接続可能なポートはないことを示している。

次に、（３）で、バスA_スレーブモデルのポート６０７を検索し、その結果は［○］であり、「ポート名」、「ポートの方向」が一致するポートAREQがあることを示している。次の（４）で、バスA_スレーブモデルの他のポートAADDR、A_WR、ADATA、AACK、WAITと、ＤＵＴ１０１に接続可能ポートがあるか逆検索を行う。その結果、WAIT以外のポートは、「ポート名」、「ポートの方向」共に一致するポートがあることを示している。尚、WAITは、図２に示すように、未使用可能ポート２０４に登録されているので、無視することとする。

次に、WAIT以外の全てのポートで「ポートの幅」が一致するか否かを調べる。カスタマイズパラメータ２０５に、BUS_WIDTHが登録されており、BUS_WIDTH=64のときにすべての「ポートの幅」が一致する。従って、ＤＵＴ１０１とバスA_スレーブモデルは、WAIT信号を未接続、BUS_WIDTH=64で、接続可能と判断して接続する。

次に、モニタ検証装置の検索及び接続を行う。（５）で、ＤＵＴ１０１の１ポートであるAREQとモニタ検証装置のポートを「ポート名」を検索キーワードとして検証装置ライブラリ１０５から検索する。バスA_モニタのポート６０９を検索し、その結果は［○］であり、「ポート名」が一致するポートAREQがあることを示している。

次に、（６）で、バスA_モニタの他のポートとＤＵＴ１０１に接続可能ポートがあるか逆検索を行う。モニタ検証装置とＤＵＴ１０１とは「ポート名」、「ポートの幅」が接続可能判定条件であり、未使用可能ポート２０４とカスタマイズパラメータ２０５から、ＤＵＴ１０１とバスA_モニタは、WAIT信号を未接続、BUS_WIDTH=64で、接続可能と判断して接続する。

そして、（７）で、ＤＵＴ１０１の他のポートTEST_OUT、TEST_IN、INT_Lは、どの検証装置とも一致しないので、図３で示したポートの処理ルールに従って処理される。この例では、ポートTEST_OUTは出力なので「オープン」に、ポートTEST_INはハイアクティブの入力ポートと判定して「ロウ固定」に、INT_Lはロウアクティブの入力ポートと判定して「ハイ固定」にする。

以上説明したように本実施形態によれば、検証対象となるＤＵＴ１０１を入力することにより、検証装置の接続されたＤＵＴ１０１のテストベンチ１０３を容易に作成することができる。

従って、検証担当者は、使用可能な検証装置が存在するかの調査、使用する検証装置の取得、ＤＵＴと検証装置のテストベンチへのインスタンス、ＤＵＴと検証装置の接続、未接続ポートの処理を行う必要がなくなり、テストベンチ作成時間を短縮でき、手作業によるテストベンチ作成におけるミスの排除を行うことができ、直ちにテスト作成に着手することが可能となる。

従って、ＬＳＩの論理検証期間の短縮、即ち、ＬＳＩ開発期間の短縮を図ることができ、製品開発の短縮が可能となる。また、今後のＬＳＩの複雑化・大規模化に伴う、多品種少量生産に対応したＬＳＩの短期開発・短期検証にも対応することが可能となる。

尚、本発明は複数の機器（例えば、ホストコンピュータ，インターフェース機器，リーダ，プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用しても良い。

また、本発明の目的は前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。

この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

このプログラムコードを供給するための記録媒体としては、例えばフロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

更に、記録媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本実施形態におけるテストベンチ作成装置の構成の一例を示す図である。 本実施形態における検証装置ライブラリ１０５の構成の一例を示す図である。 本実施形態における未接続ポート処理ルール１０６の詳細な構成を示す図である。 テストベンチを作成するテストベンチ作成処理を示すフローチャートである。 テストベンチを作成するテストベンチ作成処理を示すフローチャートである。 Verilogを用いた論理検証を説明するための図である。

符号の説明

１０１ ＤＵＴ
１０２ テストベンチ作成装置
１０３ テストベンチ
１０４ 処理結果レポート
１０５ 検証装置ライブラリ
１０６ 未接続ポート処理ルール
１１１ 検証装置ライブラリ記憶部
１１２ 検証装置検索部
１１３ インスタンス及び接続部
１１４ 処理ルール記憶部
１１５ 未接続ポート処理部
１１６ レポート部
２０１ 種類
２０２ 検証装置名
２０３ ドキュメント格納場所
２０４ 未使用可能ポート
２０５ カスタマイズパラメータ
２０６ 格納場所
２０７ ファイルサーバー

Claims (18)

1. 検証対象の論理回路を検証装置により機能検証するための検証環境を作成する検証環境作成装置であって、
   複数の検証装置を登録している検証装置ライブラリから前記検証対象の論理回路と接続可能な検証装置を検索する検索手段と、
   前記検索手段で検索された検証装置を前記検証環境にインスタンスし、当該検証装置と前記論理回路を接続する手段と、
   前記接続された論理回路の未接続ポートを所定の処理ルールに従って処理する手段とを有することを特徴とする検証環境作成装置。
2. 前記検証装置ライブラリは、検証装置として少なくともデバイスモデル、バスマスターモデル、バススレーブモデル、バスモニタ、クロックジェネレータ、及びリセットジェネレータを含むことを特徴とする請求項１記載の検証環境作成装置。
3. 前記検証装置ライブラリに登録されている検証装置は、登録情報として少なくとも検証装置の種類、検証装置名、検証装置のドキュメント格納先、未使用可能ポート情報、カスタマイズパラメータ、及び検証装置の格納先を含むことを特徴とする請求項１記載の検証環境作成装置。
4. 前記検索手段は、ポート情報であるポート名とポートの方向とポートの幅を検索キーワードとして、前記検証対象の論理回路と接続可能な検証装置を検索することを特徴とする請求項１記載の検証環境作成装置。
5. 前記検索手段は、ポート情報であるポート名とポートの幅を検索キーワードとして、前記検証対象の論理回路と接続可能なモニタ検証装置を検索することを特徴とする請求項１記載の検証環境作成装置。
6. 前記検索手段は、前記検証対象の論理回路と接続可能な検証装置が検索された後、当該検証装置の全てのポートが前記検証対象の論理回路と接続可能であるかを逆検索することを特徴とする請求項１記載の検証環境作成装置。
7. 前記検索手段は、前記未使用可能ポート情報が示すポート以外の全てのポートについて前記検証対象の論理回路と接続可能であるかを検索することを特徴とする請求項３記載の検証環境作成装置。
8. 前記検索装置ライブラリから検証装置を検索する検索範囲を切り換える切り換え手段を更に有することを特徴とする請求項３記載の検証環境作成装置。
9. 前記切り換え手段は、前記検証装置の種類により前記検索装置ライブラリにおける検索範囲を切り換え可能であることを特徴とする請求項８記載の検証環境作成装置。
10. 前記切り換え手段は、検索を禁止する検証装置の種類を指定することにより検索範囲を切り換えることを特徴とする請求項８記載の検証環境作成装置。
11. 前記インスタンス及び接続する手段は、前記検証対象の論理回路と検証装置を検証環境にインスタンスし、前記論理回路と検証装置のポートを接続することを特徴とする請求項１記載の検証環境作成装置。
12. 前記インスタンス及び接続する手段は、前記検証装置の検証環境へのインスタンス時に、ユーザーに問い合わせの上、インスタンス決定を行うことを特徴とする請求項１１記載の検証環境作成装置。
13. 前記論理回路のポート名とポートの方向を条件として、ポートの信号レベルをどのように固定するかを記述した処理ルールを記憶手段に格納していることを特徴とする請求項１記載の検証環境作成装置。
14. 前記未接続ポートの処理は、所定の処理ルールに従って前記検証対象の論理回路の信号が接続されていない全ポートに対して、ポートの信号レベルの固定処理を行うことを特徴とする請求項１記載の検証環境作成装置。
15. 前記検証対象の論理回路と接続した検証装置名、接続した検証装置のドキュメント格納先、未接続ポートに対して行った処理を含むレポートを出力する手段を更に有することを特徴とする請求項１記載の検証環境作成装置。
16. 検証対象の論理回路を検証装置により機能検証するための検証環境を作成する検証環境作成装置の処理方法であって、
    複数の検証装置を登録している検証装置ライブラリから前記検証対象の論理回路と接続可能な検証装置を検索する検索工程と、
    前記検索工程で検索された検証装置を前記検証環境にインスタンスし、当該検証装置と前記論理回路を接続する工程と、
    前記接続された論理回路の未接続ポートを所定の処理ルールに従って処理する工程とを有することを特徴とする検証環境作成装置の処理方法。
17. 請求項１６記載の検証環境作成装置の処理方法をコンピュータに実行させるためのプログラム。
18. 請求項１７記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images