JP2005222371A - 論理回路の機能検証システムおよび方法 - Google Patents

Abstract

【課題】 ＤＵＴの機能検証用のテスト項目、テスト仕様、テストを高品質かつ高効率に作成可能とし、ＤＵＴの機能検証を効率よく行う。
【解決手段】 論理回路の機能検証システムに、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してテスト仕様を自動生成するテスト仕様生成部３２と、当該テスト項目、テスト仕様、論理回路仕様、検証ライブラリを解析して当該論理回路の機能検証に必要となる検証モジュール群を自動抽出する検証モジュール群抽出部３３と、当該テスト項目、テスト仕様、論理回路仕様、テストテンプレート群を解析して当該論理回路の機能検証に必要となるテスト群を自動生成するテスト群生成部３４とを備える。
【選択図】 図１

Description

本発明は、論理回路の機能検証システムおよび方法に関し、必要十分な機能検証項目の設定及び当該機能検証項目に関わる機能検証を効率的かつ高品質に実施可能な機能検証システムおよび方法に関するものである。

従来、ＤＵＴの機能検証は当該ＤＵＴが機能仕様書に記載された機能仕様通りに機能するかを、動的或いは静的な検証手法によって機能検証が実施されてきた。通常、検証対象のＤＵＴの機能検証を実施する検証者は、実際にＤＵＴの各機能がどのように実装されているかという部分には踏み込まずに、ＤＵＴの可観測な端子の信号の状態を調べて、ＤＵＴが機能仕様通りに機能するかブラックボックス的に検証する。当該ＤＵＴ検証にあたっては、検証者がＤＵＴの機能仕様書から検証すべきテスト項目を抽出して、テスト仕様書を作成し、設計者がテスト項目の抜けが無いかレビュー等で確認した上で、検証者が完成されたテスト仕様書に基づきテストを作成し、検証を実施していた。

検証すべきテスト項目の抽出にあたっては、予め準備された各機能毎に抽出すべきテスト項目を網羅したテスト項目一覧を参照して、テスト項目の抽出抜けが無いか確認される場合もあった。また、設計者が検証者からテスト項目のレビューを受けることにより検証者が抽出したテスト項目に抜けが無いかを確認する場合もあった。これらの場合はテスト項目の抽出抜け回避にある程度効果は出ていた。

近年、ソフトウェア開発の分野において、構造化手法やオブジェクト指向方法論に基づき、仕様からプログラムを自動生成することが可能となって来ている。また、グラフィカルユーザインターフェースを介して入力されたソフトウェア要求仕様に基づいて、ソフトウェアコードを自動生成させる技術が考案されている（例えば、特許文献１参照）。
特開２００２−０７３３３６号公報

上述した様に、従来のＤＵＴの機能検証に際しては、ＤＵＴの機能仕様から検証すべきテスト項目を抽出する工程、テスト仕様書を作成する工程、テスト仕様をレビューする工程、そして、テストを作成する工程、テストを実行する工程に要する負荷が、ＤＵＴの大規模化に伴い、大幅に増大し、検証期間増大を招いているという問題点があった。また、機能仕様から検証すべきテスト項目の抽出が、担当する検証者のスキルに依存し、検証の品質を大きく左右するという問題点があった。検証項目抜けを回避する為に、予め準備された各機能毎に抽出すべきテスト項目を網羅したテスト項目一覧を参照することを検証者が行った場合でも不注意等により発生する検証漏れは回避できなかった。また、検証者によるテストアイテム抽出後に設計者と検証者と対となってテストレビューを実施しても、検証すべきテスト項目の一部が抜けてしまう場合も少なくなかった。また、上記検証に関わる工程のうち、最も上流の工程である、検証すべきテスト項目抽出工程において、いかに必要十分なテスト項目を抽出するかその後の検証品質を大きく左右する為、検証項目抽出の信頼性と生産性の向上を両立させることは大きな課題である。また、抽出したテスト項目に関する適切なテストを作成することも検証品質の観点から重要なポイントであり、その信頼性と生産性の向上を両立させることも大きな課題である。

また、上述した様に、仕様からプログラムを自動生成することが可能となってきているが、適用分野は主にアプリケーション或いは組込みソフトウェアの開発の分野においてあり、ハードウェア開発の分野でも一部適用が試みられてきている。即ち、実現すべきソフトウェアの仕様から当該ソフトウェアのプログラムを自動生成するものや、実現すべきハードウェアの機能仕様から当該ハードウェアの機能をハードウェア記述向けの拡張Ｃ言語等で記述されたプログラムを自動生成するものである。

また、実現すべきソフトウェアの仕様あるいはプログラムから当該ソフトウェアのテスト項目、そして、テストプログラムを自動生成する技術も提案されてきている。

しかし、ハードウェアの機能検証の分野において、機能検証用のテスト仕様、テストプログラムを自動生成する技術は開示されておらず、ＤＵＴの機能仕様から、当該機能に関する機能検証用のテスト項目、テスト仕様、テストを作成する工程を高品質に効率化する必要性が高まっている。

本発明の目的は、ＤＵＴの機能検証に関わり、実績のあるテスト項目一覧、パラメタライズ化されたモデル、モニタ等の検証モジュール、テスト項目に対応したテストテンプレートを有効活用することにより、当該ＤＵＴの機能検証用のテスト項目、テスト仕様、テストを高品質かつ高効率に作成可能とする機能検証システムおよび方法を提供することである。

かかる課題を解決する為、例えば、本発明の機能検証システムは、以下の構成を備える。

即ち、論理回路と当該論理回路機能検証用テストベンチ及びテストを含む検証環境を生成する機能検証システムであって、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してテスト仕様を自動生成するテスト仕様生成部と、当該テスト項目、テスト仕様、論理回路仕様、検証ライブラリを解析して当該論理回路の機能検証に必要となる検証モジュール群を自動抽出する検証モジュール群抽出部と、当該テスト項目、テスト仕様、論理回路仕様、テストテンプレート群を解析して当該論理回路の機能検証に必要となるテスト群を自動生成するテスト群生成部と、検証対象の論理回路の検証に必要なベースＨ／Ｗを作成し、前記抽出した検証モジュール群と併せてテストベンチを構成し、検証対象の論理回路とテスト群を接続した検証環境を生成することを特徴とする機能検証システム。

本発明によれば、ＤＵＴの機能検証に関わり、実績のあるテスト項目一覧、パラメタライズ化されたモデル、モニタ等の検証モジュール、テスト項目に対応したテストテンプレートを有効活用することにより、当該ＤＵＴの機能検証用のテスト項目、テスト仕様、テストを高品質かつ高効率に作成することができ、検証工数削減、検証期間短縮、検証品質向上を同時に実現することができるという大きな効果がある。

以下、添付図面に従って、本発明に係わる実施形態を詳細に説明する。

（第一の実施形態）
図１に本発明の第一の実施形態の、機能検証システムの構成を示す。

尚、本実施の形態においては、ＤＵＴとＤＵＴ検証用のテストベンチおよびテストをソフトウェアシミュレータ上でシミュレーションを実行することにより動的検証を行うことを想定している。

図１の機能検証システム１は、データ入力／編集部１０、データベース部２０、検証要素抽出部３０、検証要素群４０、検証環境構築部５０、検証環境６０とから構成される。

データベース部２０は、ＤＵＴ仕様２１、テスト項目一覧２２、テスト項目２３、検証ライブラリ２４、テストテンプレート群２５の電子データを格納するデータベース部であり、ワークステーション上のハードディスク等の電子データ蓄積デバイス上に電子データを格納し、当該電子データのバージョン管理等を行う。テスト項目一覧は、予め用意された、ＤＵＴの様々な機能毎にテスト項目として抽出すべき項目を網羅したテスト項目一覧のデータである。テスト項目群２３は検証者がＤＵＴ仕様２１よりテスト項目一覧２２を参照して、或いは、参照せずに作成した当該ＤＵＴに対するテスト項目群の電子データである。検証ライブラリ２４は予め用意された、様々なＤＵＴの機能検証に必要となるモデル、モニタ等の検証モジュールのライブラリである。テストテンプレート群２５は予め用意された、テスト項目一覧の各テスト項目に対応するテストのテンプレートのデータである。データ入力／編集部１０は前記データベース内の各種データの入力、編集を行う為のデータベースにネットワーク接続されたワークステーション等から構成される、ＧＵＩ等を有するマンマシンインタフェースである。

検証要素抽出部３０は、テスト仕様生成部３２、検証モジュール群抽出部３３、テスト群生成部３４から構成され、前記データベース部２０内の各種データを解析して、当該ＤＵＴの検証に必要な後述する検証要素群４０を抽出する検証要素抽出部である。検証要素群４０は、テスト項目群４１、テスト仕様４２、検証モジュール群４３、テスト群４４とから構成される。テスト項目群４１は前記テスト項目群２３と同一のものであり、本実施形態においては検証者にマニュアルで生成されたことを想定している。

テスト仕様４２は当該ＤＵＴの機能検証に必要な各テスト項目毎にＤＵＴ仕様に基づく制約条件を考慮したテスト仕様が自動抽出されたものである。検証モジュール群４３は当該ＤＵＴの機能検証に必要となる検証モジュールの集合である。テスト群４４は当該ＤＵＴの機能検証に必要となるテストの集合である。前記テスト仕様生成部３２は、当該ＤＵＴの機能検証として実施すべきテスト項目群２３の各テスト項目毎に、関連するＤＵＴ仕様２１を解析して当該対応ＤＵＴ仕様の制約条件を付加した各テスト仕様を自動生成し、全テスト項目群２３に対応するテスト仕様４２を自動生成する。

検証モジュール群抽出部３３は、当該ＤＵＴの機能検証として実施すべきテスト項目群２３の各テスト項目毎に、関連するＤＵＴ仕様２１と当該テスト仕様４２を解析して当該テスト項目に関する機能検証時にテスト側に実装すべき部分とモデル、モニタ等の検証モジュールの機能として実装すべき部分の切り分けを行い、当該テスト項目に関する機能検証に必要なモデル、モニタ等の検証モジュールを検証ライブラリ２４から抽出し、必要に応じてテスト実行時に検証モジュールに設定すべきパラメータ情報を保持し、全テスト項目群２３に対応する検証モジュール群を抽出する。

テスト群生成部３４は、テスト項目群２３の各テスト項目毎にテストテンプレート群２５を解析して、対応するテストテンプレートを抽出し、関連するＤＵＴ仕様２１とテスト仕様４２および前記検証モジュール抽出部に保持されたテスト側から検証モジュールに設定すべきパラメータ情報を解析して、必要なパラメータを当該テストテンプレートに追加して、当該ＤＵＴの機能検証として実施すべきテストを自動生成し、これを全てのテスト項目に対して実行し、テスト項目群２３に対応するテスト群４４を生成する。

検証環境６０は、テスト群４４とテストベンチ６３とＤＵＴ６１と検証部／シミュレータＩ／Ｆ６４とソフトウェアシミュレータ６５とから構成される。テストベンチ６３は、前記抽出された検証モジュール群とベースＨ／Ｗ６２とから構成される。ベースＨ／Ｗ６２はＤＵＴ６１を包含するＨ／Ｗのトップ階層であり、検証モジュール群と接続されテストベンチ６３を構成し、ソフトウェアシミュレータ上でシミュレーション実行が可能である。ソフトウェアシミュレータ６５はハードウェア記述言語等で機能記述されたハードウェアのプログラムを実行可能な論理シミュレータである。

検証部／シミュレータＩ／Ｆ６４はテスト群４４および検証モジュール群４３等検証言語等で記述された検証部をソフトウェアシミュレータ６５上で実行させる為のインタフェースである。検証環境構築部５０は、前記検証要素群４０を組合せて前記検証環境６０を自動構築する。

尚、本発明の第一の実施形態の上記各構成要素は、ワークステーション或いはＰＣ上において、主記憶あるいは補助記憶装置に保存され、中央演算処理装置の制御に基づき機能するものとする。

次に、図２の本発明の第一の実施形態の動作フローによって、本発明の第一の実施形態の機能検証システムの主要部分の検証要素抽出部３０と検証環境構築部５０の動作フローを説明する。

尚、本実施の形態においては、データベース部２０にＤＵＴ仕様２１、テスト項目一覧２２、テスト項目群２３、検証ライブラリ２４、テストテンプレート群２５、ＤＵＴ６１に加えて、抽出、生成される、テスト仕様４２、検証モジュール群４３、テスト群４４を保持する構成を想定している。

まず、検証要素抽出部の最初の工程としてＳ１０１で当該ＤＵＴに対応するテスト項目群２３のテスト項目Ｎｏ．の初期化処理（ｉ＝１）を行う。次に、Ｓ１０１で当該テスト項目に関連するＤＵＴ仕様を解析して当該ＤＵＴ仕様の制約条件を付加してテスト仕様を生成する。次にＳ１０２で当該テスト項目に関連するＤＵＴ仕様とテスト仕様を解析して、当該テスト項目に関する機能検証時にテスト側に実装すべき部分と検証モジュール側に実装すべき部分の切り分けを行った上で、必要な検証モジュールを検証ライブラリ２４より抽出し、必要に応じてテスト実行時に検証モジュールに設定すべきパラメータ情報を保持する。

次にＳ１０３でテストテンプレート群２５を解析して当該テスト項目に対応するテストテンプレートを抽出し、関連するＤＵＴ仕様とテスト仕様と検証モジュール抽出部３３に保持されたパラメータ情報を解析して、必要な制約条件を当該テストテンプレートに付加してテストを作成する。次にＳ１０４で次テスト項目を選択する為にｉをインクリメントする（ｉ＝ｉ＋１）。Ｓ１０５でｉが当該ＤＵＴのテスト項目群２３の総テスト項目数ｎを超えたら（ｉ＞ｎ）、検証要素抽出の工程を終了し、Ｓ１０６に進む。ｉがｎ以下の場合は、Ｓ１０１に進んで、検証要素抽出の工程を続ける。

Ｓ１０６で生成したテスト仕様４２をデータベース部２０に格納する。Ｓ１０７で抽出した検証モジュール群４３をデータベース部２０に格納する。Ｓ１０８で生成したテスト群４４をデータベース部２０に格納する。

次に、検証環境構築部５０の工程として、Ｓ１０９でＤＵＴ６１をテストベンチ６３に接続する為のＤＵＴ６１の上位階層のモジュールとなるベースＨ／Ｗ６２を生成し、ＤＵＴ６１を接続する。次にＳ１１０で前記抽出した検証モジュール群４３をベースＨ／Ｗ６２とＤＵＴ６１に接続し、テストベンチを構成する．次にＳ１１１で前記生成したテスト群４４をテストベンチに接続する。そして、最後にＳ１１２で全接続情報をデータベース部２０に格納し、シミュレータ環境にテスト群４４、テストベンチ６３、ＤＵＴ６１を組込んで、検証環境６０を構築する。

上記において、当該ＤＵＴの各テスト項目に関する機能検証に必要となるモデル、モニタ等の検証モジュールは検証ライブラリ２４に含まれており、同様に、当該ＤＵＴの各テスト項目に関する機能検証に必要となるテストに対応するテストテンプレートもテストテンプレート群に含まれていることを想定している。

当該ＤＵＴの各テスト項目に関する機能検証に必要となるモデル、モニタ、或いはテストテンプレートが抽出不可能な場合は、必要となるモデル、モニタ、或いは、テストテンプレートを新規或いは類似モジュールを編集することにより作成し、データ入力／編集部１０を介して、データベース部に追加する。

以上説明した本実施形態においては、検証要素抽出部の動作フローとして、各テスト項目毎に、テスト仕様抽出工程、検証モジュール抽出工程、テスト生成工程を実行して、次のテスト項目に移行しているが、全テスト項目分のテスト仕様抽出工程を実行した後に、全テスト項目分の検証モジュール抽出工程を実行し、更に、全テスト項目分のテスト生成工程を行うようにする、或いは、所定のテスト項目をまとめて、テスト仕様抽出工程、検証モジュール抽出工程、テスト生成工程を実行する等、検証要素抽出部の内部的な工程の進め方は様々な方法が考えられ、上述した方法に限定されるものではないということは言うまでもない。

次に、図３に示すＤＵＴ、テストベンチおよびテスト群の具体例に基づいて、本発明の第一の実施形態の、当該ＤＵＴの機能検証に必要となる、テスト項目群、テスト仕様、検証モジュールおよびテスト群の抽出／生成の方法に関して、具体例を挙げて説明する。

図３は本発明の第一の実施形態のＤＵＴ、テストベンチおよびテスト群の詳細構成例であり、ＤＵＴの中の後述するバスアービタの検証に関連するモジュールを示したものである。図３において、ＤＵＴ６１はバス６０２に接続されるバスアービタのみが示されているが、その他不図示の、当該バスに接続される４つのバスマスタ、アドレスデコーダ、バスマルチプレクサ等から構成されるものとする。テストベンチ６３には、検証モジュール群として、バスマスタモデル１ ２０１、バスマスタモデル２ ２０２、バスマスタモデル３ ２０３、バスマスタモデル４ ２０４、バススレーブモデル２０５、バスモニタ２０６が示されているが、その他不図示のＤＵＴの他の構成要素の機能検証に必要な検証モジュールとから構成されるものとする。また、テスト群４４には、バスアービタテスト２０５のみが示されているが、その他不図示のＤＵＴの他の構成要素の機能検証に必要なテストとから構成されるものとする。

バスマスタモデル１ ２０１からバスマスタモデル４ ２０４は各々当該バスのバスマスタとして機能する検証モジュールであり、バスアービタ６０１は当該バス上の前記４つのマスターモデルのバス権を調停する。バススレーブモデル２０５は前記バスマスタモデルからライト、リード等のアクセスを受ける検証モジュールである。当該バスの状態（信号のレベル、変化）、複数の信号の状態の時間関係はバスモニタ２０６によりモニタされる。また、バスアービタテスト２０５はテストベンチ６３内の各モジュールに必要なデータを設定し、必要な出力データを収集し、論理シミュレータによるシミュレーションにおいて当該バスアービタ６０１の機能検証を実施するためのテストプログラムである。

図４は後述する図５に示すテスト項目に着目した場合に、検証要素抽出部３０の中で解析すべき、本発明の第一の実施形態のＤＵＴ仕様の例を示したものである。

検証すべきテスト項目が定められると、検証要素抽出部３０の中の、テスト仕様生成部３２、検証モジュール群抽出部３３、テスト群生成部３４は、図示の直接該当するＤＵＴ仕様および関連するＤＵＴ仕様をピックアップする。

直接該当するＤＵＴ仕様として、Ｘ＿Ｂｕｓ＿Ａｒｂｉｔｅｒの仕様の Ｓｐｅｃ．ｘｘｘ＿２ “ｏｎｌｙ ｏｎｅ ｇｒａｎｔ ｓｉｇｎａｌ ｉｓ ｈｏｔ． ｉ．ｅ．ｇ＿ｋ＝１ ＆ ｇ＿ｉ＝０（ｉ≠ｋ） ｗｈｅｎ ｋ ｉｓ ｇｒａｎｔｅｄ （ｋ∈｛０，１，２，３｝）”が示されており、関連するＤＵＴ仕様として、Ｘ＿Ｂｕｓ＿Ａｒｂｉｔｅｒの仕様のＳｐｅｃ．ｘｘｘ＿１ “ｓｕｐｐｏｒｔ ｍａｓｔｅｒ０，ｍａｓｔｅｒ１，ｍａｓｔｅｒ２，ｍａｓｔｅｒ３．”と、Ｘ＿Ｂｕｓ＿Ｍａｓｔｅｒ０の仕様のＳｐｅｃ．ｙｙｙ＿１ “ｓｉｇｎａｌ ｐａｔｈ＝／ｓｙｓｔｅｍ０／…／…／ｘｂｕｓａｒｂ０”とが示されている。

図５は本発明の第一の実施形態のテスト項目一覧とテスト項目群の例を示したものである。テスト項目一覧には、例として、テスト項目ａａａ：ｇｒａｎｔ＿ｓｉｇｎａｌ＿ｆｏｒ＿ａｒｂｉｔｒａｔｉｏｎおよびテスト項目ｂｂｂ：ｐｒｉｏｒｉｔｙ＿ｏｆ＿ａｒｂｉｔｒａｔｉｏｎが 挙げられている。各テスト項目は、項目識番号：名称、概要、関連モジュール名が記載されているものとする。これらの記載事項は、特定の識別子（例においては“＃”）を付加されたキーワードで識別可能に記載されているものとする。本発明の第一の実施形態においては、テスト項目群は、検証者により当該テスト項目一覧を参照して当該ＤＵＴの機能検証に必要なテスト項目がピックアップされたものとし、前記テスト項目一覧のうち、テスト項目ａａａがピックアップされ、本説明においては、当該テスト項目ａａａに着目して、以下のテスト仕様生成、検証モジュール抽出、テスト群抽出の説明を行うものとする。

テスト項目ａａａにおいて、その概要“ｃｈｅｃｋ ｉｆ ｏｎｌｙ ｏｎｅ ｇｒａｎｔ ｓｉｇｎａｌ ｉｓ ｈｏｔ． ｉ．ｅ． ｇ＿ｋ＝１ ＆ ｇ＿ｉ＝０（ｉ≠ｋ） ｗｈｅｎ ｋ ｉｓ ｇｒａｎｔｅｄ）”は、同時には１つのｇｒａｎｔ信号のみ１（許可）となることをチェックするというものである。また、関連モジュールとしては、ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ、ｂｕｓ＿ｓｌａｖｅ＿ｍｏｄｅｌ、ｂｕｓ＿ｍｏｎｉｔｏｒが挙げられている。

図６は本発明の第一の実施形態のテスト項目群からのテスト仕様の生成例を示したものである。テスト仕様生成部３２において、前記テスト項目ａａａに対して、前記図４に示された当該ＤＵＴ仕様の制約条件を付加したテスト仕様が自動生成される。

テスト項目ａａａに対応する当該ＤＵＴに対するテスト仕様として、ＤＵＴ仕様（Ｘ＿Ｂｕｓ＿Ａｒｂｉｔｅｒの仕様のＳｐｅｃ．ｘｘｘ＿１）に合わせてバスマスタの数が４に制約されていると共に、当該ＤＵＴのバスの種類（ｘ＿ｂｕｓを使用）に合わせて、関連モジュールがｘ＿ｂｕｓのマスターモデルｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ、スレーブモデルｘ＿ｂｕｓ＿ｓｌａｖｅ＿ｍｏｄｅｌ、モニタｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒに制約されている。また、当該テスト項目ａａａ「バスアービタは同時には１つのｇｒａｎｔ信号のみ１（許可）とすることをチェックする」に対するテスト仕様の詳細として、テストステップ“ １．Ｉｓｓｕｅ ｗｒｉｔｅ ａｃｃｅｓｓ ｆｒｏｍ ａｌｌ ｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ ｔｏ ｘ＿ｂｕｓ＿ｓｌａｖｅ＿ｍｏｄｅｌ０ ｃｏｎｃｕｒｒｅｎｔｌｙ ｗｉｔｈ ｒａｍｄｏｍ ｄｅｌａｙ． ２．Ｃｈｅｃｋ ｉｆ ｏｎｌｙ ｏｎｅ ｇｒａｎｔ ｓｉｇｎａｌ ｉｓ ｈｏｔ ｂｙ ｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒ．”が示されている。

図７は本発明の第一の実施形態の検証ライブラリからの検証モジュール群の抽出例を示したものである。同図において、検証ライブラリには、ｘ＿ｂｕｓ以外にもａ＿ｂｕｓに関連する検証モジュールが含まれているものとする。検証モジュール群抽出部３３において、前記検証ライブラリより、当該テスト項目ａａａの検証に必要な検証モジュール群として、ｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ、ｘ＿ｂｕｓ＿ｓｌａｖｅ＿ｍｏｄｅｌ、ｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒが自動抽出される。

図８は本発明の第一の実施形態のテストテンプレートからのテスト群の生成例を示したものである。同図において、テストテンプレートとして、テスト項目ａａａ「バスアービタは同時には１つのｇｒａｎｔ信号のみ１（許可）とすることをチェックする」に対するテストのテンプレート“ｇｒａｎｔ＿ｓｉｇｎａｌ＿ｆｏｒ＿ａｒｂｉｔｒａｔｉｏｎ”が含まれている。本実施形態においては、当該テストは、検証専用言語を用いて記述されているものとし、０からｎ−１のｎ個のバスマスタモデルからバススレーブモデルに対してランダムな遅延を伴って、同時にアクセスを行うという内容が記載されている。テスト群生成部３４において、前記テストテンプレートより、当該テスト項目ａａａの検証用のテストとして、当該ＤＵＴ仕様およびテスト仕様の制約を付加した、テストが自動生成される。具体的には、テスト名が“ｓｙｓ０＿ｘ＿ｇｒａｎｔ＿ｓｉｇｎａｌ＿ｆｏｒ＿ａｒｂｉｔｒａｔｉｏｎ”に変更され、ｓｔｒｕｃｔ名、クロック名、各フィールド名に、例えば、“ｃｌｋ”が“ｘ＿ｃｌｋ”と変更されているように、“ｘ＿”が付加され、同時アクセスする関数ｗｒｉｔｅ（）の呼び出し数がＤＵＴ仕様のマスター数に応じてｎから４に変更されている。

図９は本発明の第一の実施形態のｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒにおけるｇｒａｎｔ信号チェック記述例を示したものである。当該“ｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒ”は、図６のテスト仕様に示した通り、当該テスト項目ａａａに対する機能検証を実施するのに必要となる、“ｃｈｅｃｋ ｉｆ ｏｎｌｙ ｏｎｅ ｇｒａｎｔ ｓｉｇｎａｌ ｉｓ ｈｏｔ”のチェック機能を記述した例である。本記述例においては、接続されるマスター数が仕様毎に異なるといった様々なＤＵＴ仕様に対応できるようにマスター数を最大１６個のマスター数をサポートできるように記述されている。即ち、ｘｇｒａｎｔのｂｉｔ数を１６としている。内容的には、１６ｂｉｔからなる信号ｘの各ｂｉｔの値の算術和を計算する関数ｂｉｔｓｕｍ（ｘ：ｉｎｔ（ｂｉｔｓ：１６））を用意し、あるマスターに対するｇｒａｎｔが発生時（これを “ｇｒａｎｔ”というｅｖｅｎｔと定義）に、ｂｉｔｓｕｍ（ｘｇｒａｎｔ）＝１であることをチェックするようにしている。また、ｘｇｒａｎｔはＤＵＴ仕様のＸ＿Ｂｕｓ＿Ｍａｓｔｅｒ０の仕様のＳｐｅｃ．ｙｙｙ＿１ “ｓｉｇｎａｌ ｐａｔｈ＝／ｓｙｓｔｅｍ０／…／…／ｘｂｕｓａｒｂ０”に応じてＤＵＴの信号をサンプルしたものである。

そして、検証環境構築部５０により、図７に示した抽出された検証モジュール群ｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ、ｘ＿ｂｕｓ＿ｓｌａｖｅ＿ｍｏｄｅｌ、ｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒは、図３に示されたテストベンチ構成に従って、マスターモデルはｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ０、ｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ１、ｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ２、ｘ＿ｂｕｓ＿ｍａｓｔｅｒ＿ｍｏｄｅｌ３の４つが、スレーブモデルは１つのｘ＿ｂｕｓ＿ｓｌａｖｅ＿ｍｏｄｅｌ０が、バスモニタは１つのｘ＿ｂｕｓ＿ｍｏｎｉｔｏｒ０がインスタンスされて、ＤＵＴとのＩ／Ｆとして生成されるベースＨ／Ｗと共にテストベンチを構築し、前記テストと共に、シミュレータ環境に組込まれて、テスト項目ａａａの機能検証の為のテストの実行が可能となる。

上記のようにして、本発明の第一の実施形態により、テスト項目群、検証対象のＤＵＴ仕様、検証資産である検証ライブラリおよびテストテンプレート群を元にして、着目するテスト項目の機能検証を実施する為のテスト仕様を自動生成し、必要となる検証モジュール群を自動抽出し、必要となるテストを自動生成することが可能となり、更に、ＤＵＴと検証モジュール群とテストからなる検証環境を構築することにより、当該テスト項目に対する機能検証を実行することが可能となる。

尚、上記説明した図３から図９のバスアービタのｇｒａｎｔ信号に関する機能検証は一例であって、説明した検証要素抽出および検証環境構築の方法は、他のＤＵＴ仕様、テスト項目に関しても適用可能で、この例に限られたものではないことは言うまでもない。

また、上述の説明においては、テスト項目一覧の各項目の内容として項目識番号：名称、概要、関連モジュール名が記載されているものとし、また、これらの記載事項は、特定の識別子（例においては“＃”）を付加されたキーワードで識別可能に記載されているものとするとしたが、テスト項目の記載の形式は上記に限らず、所定の細項目毎に表形式あるいは、所定タグを付加されたもの等、細項目毎の識別が可能であれば、他の形式であっても良いことは言うまでもない。

また、上述の説明においては、テスト項目とテスト仕様は項目識別番号および項目名称により対応付けをしていたが、項目毎の対応のさせ方は、上記に限らず、項目識別符号のみ、あるいは、所定のキーワード、タグ等、識別可能であれな、他の形式であっても良いことは言うまでもない。

また、上述の説明においては、テスト項目とＤＵＴ仕様はキーワードにより関連付けを解析したが、両者の関連性の解析は、上記に限らず、識別符号のみ、あるいは、所定のタグ等、識別可能であれな、他の形式であっても良いことは言うまでもない。

また、本発明の第一の実施形態においては、ＤＵＴ仕様、テスト仕様等は細項目毎に自然言語に近い形式で記述したが、これらはＵＭＬ等仕様記述言語により記述したものを解析するようにしても良いことは言うまでもない。

また、上述の説明において、テスト仕様はピックアップされたテスト項目に当該ＤＵＴ仕様の制約条件を付加して自動生成するものとしたが、予め、用意されたテスト項目に対するテスト仕様のテンプレートに対して当該ＤＵＴ仕様の制約条件を付加して自動生成するようにしても良いことは言うまでもない。

以上、説明したように、本発明の一実施形態に於いては、論理回路と当該論理回路機能検証用テストベンチ及びテストを含む検証環境を生成する機能検証システムであって、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してテスト仕様を自動抽出するテスト仕様生成部と、当該テスト項目、テスト仕様、論理回路仕様、検証ライブラリを解析して当該論理回路の機能検証に必要となる検証モジュール群を自動抽出する検証モジュール群抽出部と、当該テスト項目、テスト仕様、論理回路仕様、テストテンプレート群を解析して当該論理回路の機能検証に必要となるテスト群を自動生成するテスト群生成部と、検証対象の論理回路の検証に必要なベースＨ／Ｗを作成し、前記抽出した検証モジュール群と併せてテストベンチを構成し、検証対象の論理回路とテスト群を接続した検証環境を生成する検証環境構築部を設けることにより、実績のあるテスト項目一覧、パラメタライズ化されたモデル、モニタ等の検証モジュール、テスト項目に対応したテストテンプレートを有効活用して、当該ＤＵＴの機能検証用のテスト項目、テスト仕様、テストを高品質かつ高効率に作成可能とする機能検証システムおよび方法を提供することができる。

（第二の実施形態）
図１０に本発明の第二の実施形態の、機能検証システムの構成を示す。同図において、第一の実施形態の、機能検証システムの構成を示した図１と同一の部分は説明を省略する。

図１０において、テスト項目抽出部３１はＤＵＴ仕様２１をテスト項目一覧２２に基づいて解析することにより当該ＤＵＴの機能検証に必要なテスト項目群４１を自動生成する点が、第一の実施形態と異なる点である。

本発明の第二の実施形態によれば、ＤＵＴ仕様とテスト項目一覧から当該ＤＵＴの機能検証に必要となるテスト項目群を自動生成することにより、検証者が人手で多大な工数をかけてＤＵＴ仕様からテスト項目群を抽出し、その上検証者の人手で抽出する為に、テスト項目群に漏れが生じる可能性があるのに対して、人為ミスによる検証漏れを回避し、効率的かつ高品質に検証項目群を抽出可能であるという大きな効果がある。

（第三の実施形態）
第一、第二の実施形態がシミュレーションによる動的検証を想定していたのに対して、本実施形態はプロパティチェックによる静的検証を想定したものである。

図１１に本発明の第三の実施形態の、機能検証システムの構成を示す。同図において、第二の実施形態の、機能検証システムの構成を示した図１０と同一の部分は説明を省略する。

図１１において、プロパティライブラリ２６は予め用意された各種プロパティ仕様に対するプロパティのテンプレートのライブラリである。プロパティ仕様４５は当該ＤＵＴの機能検証に必要な各テスト項目毎にＤＵＴ仕様に基づく制約条件を考慮したプロパティ仕様が自動抽出されたものである。プロパティ群４６は当該ＤＵＴの機能検証に必要となるプロパティの集合である。プロパティ仕様生成部３５は、当該ＤＵＴの機能検証として実施すべきテスト項目群２３の各テスト項目毎に、関連するＤＵＴ仕様２１を解析して当該対応ＤＵＴ仕様の制約条件を付加した各プロパティ仕様を自動生成し、全テスト項目群２３に対応するプロパティ仕様４５を自動生成する。

プロパティ群生成部３６は、テスト項目群２３の各テスト項目毎にプロパティライブラリ２６を解析して、対応するプロパティテンプレートを抽出し、関連するＤＵＴ仕様２１とプロパティ仕様４５を解析して、必要なパラメータ等の制約条件を当該プロパティテンプレートに追加して、当該ＤＵＴの機能検証として実施すべきプロパティを自動生成し、これを全てのテスト項目に対して実行し、テスト項目群２３に対応するプロパティ群４６を生成する。

検証環境６０は、プロパティ群４４とＤＵＴ６１とプロパティチェッカー６７とから構成される。プロパティチェッカー６６は、ハードウェア記述言語等で機能記述されたハードウェアのプログラムを機能を、プロパティ専用言語等で記述されたプロパティに基づいて正当性を静的に検証する静的検証ツールである。検証環境構築部５０は、前記検証要素群４０を組合せて前記検証環境６０を自動構築する。

本発明の第一の実施形態の機能検証システムの構成図 本発明の第一の実施形態の動作フローを示す図 本発明の第一の実施形態のＤＵＴ、テストベンチおよびテスト群の詳細構成例を示す図 本発明の第一の実施形態のＤＵＴ仕様の例を示す図 本発明の第一の実施形態のテスト項目一覧とテスト項目群の例を示す図 本発明の第一の実施形態のテスト項目群からのテスト仕様の生成例を示す図 本発明の第一の実施形態の検証ライブラリからの検証モジュール群の抽出例を示す図 本発明の第一の実施形態のテストテンプレートからのテスト群の生成例を示す図 本発明の第一の実施形態のｘ＿ｂｕｓ＿ｍｏｎｉｏｒにおけるｇｒａｎｔ信号チェック記述例を示す図 本発明の第二の実施形態の機能検証システムの構成図 本発明の第三の実施形態の機能検証システムの構成図

符号の説明

１ 機能検証システム
１０ データ入力／編集部
２０ データベース部
２１ ＤＵＴ仕様
２２ テスト項目一覧
２３ テスト項目群
２４ 検証ライブラリ
２５ テストテンプレート群
３０ 検証要素抽出部
３１ テスト項目抽出部
３２ テスト仕様生成部
３３ 検証モジュール群抽出部
３４ テスト群生成部
４０ 検証要素群
４１ テスト項目群
４２ テスト仕様
４３ 検証モジュール群
４４ テスト群
５０ 検証環境構築部
６０ 検証環境
６１ ＤＵＴ
６２ ベースＨ／Ｗ
６３ テストベンチ
６４ 検証部／シミュレータＩ／Ｆ
６５ ソフトウェアシミュレータ

Claims (16)

1. 論理回路の機能検証システムであって、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してテスト仕様を自動生成するテスト仕様生成手段と、当該テスト項目、テスト仕様、論理回路仕様、検証ライブラリを解析して当該論理回路の機能検証に必要となる検証モジュール群を自動抽出する検証モジュール群抽出手段と、当該テスト項目、テスト仕様、論理回路仕様、テストテンプレート群を解析して当該論理回路の機能検証に必要となるテスト群を自動生成するテスト群生成手段とを有することを特徴とする機能検証システム。
2. さらに、前記検証対象の論理回路の検証に必要なベースＨ／Ｗを作成し、前記抽出した検証モジュール群と併せてテストベンチを構成し、検証対象の論理回路とテスト群を接続した検証環境を自動生成する検証環境自動生成手段とを有することを特徴とする請求項１記載の機能検証システム。
3. 前記テスト仕様生成手段は、当該テスト項目に関連する論理回路の仕様を解析して当該論理回路の仕様の制約条件を付加してテスト仕様を生成することを特徴とする請求項１または２記載の機能検証システム。
4. 前記検証モジュール群抽出手段は、当該テスト項目に関連する論理回路の仕様とテスト仕様を解析して、当該テスト項目に関する機能検証時にテスト側に実装すべき部分と検証モジュール側に実装すべき部分の切り分けを行った上で、必要な検証モジュールを検証ライブラリより抽出し、必要に応じてテスト実行時に検証モジュールに設定すべきパラメータ情報を保持することを特徴とする請求項１ないし３いずれか記載の機能検証システム。
5. 前記テスト群生成手段は、テストテンプレート群を解析して当該テスト項目に対応するテストテンプレートを抽出し、関連する論理回路の仕様とテスト仕様と前記検証モジュール抽出部に保持されたパラメータ情報を解析して、必要な制約条件を当該テストテンプレートに付加してテストを作成することを特徴とする請求項１ないし４いずれか記載の機能検証システム。
6. 論理回路の仕様をテスト項目一覧に基づいて解析することにより当該論理回路の機能検証に必要なテスト項目群を自動生成するテスト項目抽出手段を有することを特徴とする請求項１ないし５いずれか記載の機能検証システム。
7. 論理回路の機能検証方法であって、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してテスト仕様を自動生成するテスト仕様生成工程と、当該テスト項目、テスト仕様、論理回路仕様、検証ライブラリを解析して当該論理回路の機能検証に必要となる検証モジュール群を自動抽出する検証モジュール群抽出工程と、当該テスト項目、テスト仕様、論理回路仕様、テストテンプレート群を解析して当該論理回路の機能検証に必要となるテスト群を自動生成するテスト群生成工程とを有することを特徴とする機能検証方法。
8. さらに、前記検証対象の論理回路の検証に必要なベースＨ／Ｗを作成し、前記抽出した検証モジュール群と併せてテストベンチを構成し、検証対象の論理回路とテスト群を接続した検証環境を自動生成する検証環境自動生成工程とを有することを特徴とする請求項７記載の機能検証方法。
9. 前記テスト仕様生成工程は、当該テスト項目に関連する論理回路の仕様を解析して当該論理回路の仕様の制約条件を付加してテスト仕様を生成することを特徴とする請求項７または８記載の機能検証方法。
10. 前記検証モジュール群抽出工程は、当該テスト項目に関連する論理回路の仕様とテスト仕様を解析して、当該テスト項目に関する機能検証時にテスト側に実装すべき部分と検証モジュール側に実装すべき部分の切り分けを行った上で、必要な検証モジュールを検証ライブラリより抽出し、必要に応じてテスト実行時に検証モジュールに設定すべきパラメータ情報を保持することを特徴とする請求項７ないし９いずれか記載の機能検証方法。
11. 前記テスト群生成工程は、テストテンプレート群を解析して当該テスト項目に対応するテストテンプレートを抽出し、関連する論理回路の仕様とテスト仕様と前記検証モジュール抽出部に保持されたパラメータ情報を解析して、必要な制約条件を当該テストテンプレートに付加してテストを作成することを特徴とする請求項７ないし１０いずれか記載の機能検証方法。
12. 論理回路の仕様をテスト項目一覧に基づいて解析することにより当該論理回路の機能検証に必要なテスト項目群を自動生成するテスト項目抽出工程を有することを特徴とする請求項７ないし１１いずれか記載の機能検証方法。
13. 論理回路の機能検証システムであって、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してプロパティ仕様を自動生成するプロパティ仕様生成手段と、当該テスト項目、プロパティ仕様、論理回路仕様、プロパティライブラリを解析して当該論理回路の機能検証に必要となるプロパティ群を自動生成するプロパティ群生成手段とを有することを特徴とする機能検証システム。
14. 論理回路の仕様をテスト項目一覧に基づいて解析することにより当該論理回路の機能検証に必要なテスト項目群を自動生成するテスト項目生成手段を有することを特徴とする請求項１３記載の機能検証システム。
15. 論理回路の機能検証方法であって、論理回路の機能仕様に応じて機能検証すべきテスト項目を網羅したテスト項目一覧に基づいて抽出されたテスト項目と論理回路の仕様を解析してプロパティ仕様を自動生成するプロパティ仕様生成工程と、当該テスト項目、プロパティ仕様、論理回路仕様、プロパティライブラリを解析して当該論理回路の機能検証に必要となるプロパティ群を自動生成するプロパティ群生成工程とを有することを特徴とする機能検証方法。
16. 論理回路の仕様をテスト項目一覧に基づいて解析することにより当該論理回路の機能検証に必要なテスト項目群を自動生成するテスト項目生成工程を有することを特徴とする請求項１５記載の機能検証方法。

Images