JP2019121265A

JP2019121265A - 検証手順生成プログラム、検証手順生成方法、及び検証手順生成装置

Info

Publication number: JP2019121265A
Application number: JP2018001833A
Authority: JP
Inventors: 正高峯; Masataka Mine
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2018-01-10
Filing date: 2018-01-10
Publication date: 2019-07-22

Abstract

【課題】本発明の課題は、検証項目及びテストシナリオを自動生成することを目的とする。【解決手段】上記課題は、記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、特定した組み合わせ数に基づいて各パラメータの値を設定し、論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成し、前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成する、処理をコンピュータに実行させる検証手順生成プログラムにより達成される。【選択図】図６

Description

本発明は、検証手順生成プログラム、検証手順生成方法、及び検証手順生成装置に関する。

近年、ＬＳＩ（Large Scale Integration）／ＦＰＧＡ（Field-Programmable Gate Array）の開発は、その大規模化によって論理検証の工数が膨大となり問題になっている。そのため、ＬＳＩの論理検証に必要な検証項目やテストシナリオ等の検証環境を作成するオペレータの負担を軽減する様々な技術が提案されている。

初期設定情報が記述されたシナリオテンプレートと検証項目とに基づいて、テストシナリオを生成する技術、ユーザにより選択された検証項目の組み合わせと、検証対象の論理検証に関する概略シナリオデータとを用いて、検証シナリオデータを生成する技術等が知られている。

特開２００８−２１０００４号公報特開２００７−３１７０９６号公報

大規模化したＬＳＩ／ＦＰＧＡの論理検証では、検証項目、テストシナリオ等の作成にかかる工数に加えて、シミュレーションに係る時間も大きな課題の一つである。シミュレータは数十Mgate規模の場合、数十Hz程度しかでないため、シミュレーションで、通常、例えば、１GHz性能のＬＳＩの１秒のシミュレーションを実行しようとすると、シミュレータが１００Hzの性能を出せたとして１０Ｍ秒（凡そ４ヶ月程度）かかることになる。

論理検証の期間内において、如何に、効果のある検証パターンで論理検証を行うかが重要となってきている。

しかしながら、従来より、開発者によって検証項目に基づいてテストシナリオが作成されるため、同一の内容（重複）の異なる検証項目が存在した場合、トランザクションと更に組み合わせてテストベンチを生成する過程で、検証項目の重複の判別は困難となる。結果として、不要なテストシナリオを含んだままシミュレーションが行われてしまう。上述した従来技術では、この課題を解決することができない。

したがって、１つの側面では、論理検証のシミュレーションにかかる時間を削減する、検証項目及びテストシナリオを自動生成することを目的とする。

一態様によれば、記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、特定した組み合わせ数に基づいて各パラメータの値を設定し、論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成し、前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成する、処理をコンピュータに実行させる検証手順生成プログラムが提供される。

また、上記課題を解決するための手段として、検証手順生成方法、及び、検証手順生成装置とすることもできる。

論理検証のシミュレーションにかかる時間を削減する、検証項目及びテストシナリオを自動生成することができる。

一般的なテストベンチ構成を示す図である。論理検証の工程を説明するためのフローチャート図である。一般的なテストシナリオで記述される動作例を説明するためのフローチャート図である。入力制御データとトランザクションの関連を説明するための図である。本実施例における用語の概念を説明するための図である。本実施例の検証手順生成部とテストベンチとの関係を説明するための図である。本実施例における論理検証処理の全体フローを示す図である。検証手順生成装置のハードウェア構成を示す図である。検証手順生成部における入出力を説明するための図である。パラメータ定義表のデータ構成例を示す図である。メモリ定義表のデータ構成例を示す図である。レジスタ以外の構造定義表のデータ構成例を示す図である。レジスタに関する構造定義表のデータ構成例（その１）を示す図である。レジスタに関する構造定義表のデータ構成例（その２）を示す図である。組合せ検証項目表について説明するための図である。検証構成表の例を示す図である。組合せ詳細表の例を示す図である。検証項目番号からテナント番号への変換例を説明するための図である。階層単位の組合せ回避処理の例を説明するためのフローチャート図である。階層間の組合せ回避処理の例を説明するためのフローチャート図である。検証手順生成処理の全体の流れを説明するためのフローチャート図である。論理積テーブル作成処理を説明するためのフローチャート図である。検証項目テーブル作成処理を説明するためのフローチャート図である。テストシナリオ生成処理の実行例を説明するためのフローチャート図である。生成されたテストベンチの構造とデータの流れを説明するための図である。図２５のステップＳ５１でのオーナー毎の処理を説明するためのフローチャート図である。図２５のステップＳ５２でのトランザクションの生成処理を説明するためのフローチャート図である。図２５のステップＳ５３でのトランザクションの送信処理を説明するためのフローチャート図である。

以下、本発明の実施の形態を図面に基づいて説明する。まず、集積回路の論理検証を行うための、一般的なテストベンチ構成について説明する。

図１は、一般的なテストベンチ構成を示す図である。図１において、通常、検証を行う際には、機能単位、もしくはユースケース単位に検証項目表１を作成し、ＤＵＴ（Device Under Test）５０の振る舞い（出力結果）が正しいか否かを確認する。検証項目表１において、１項目は基本的に１テストシナリオが対応し、流用は可能である。検証の環境は、図１に示すようなテストベンチ９０を記述する。テストベンチ９０は、テストプログラムである。

テストベンチ９０は、厳密な時間の概念がないトランザクションレベル（ＴＬＭ：transaction level modeling）で記述され、時間概念のある（即ち、クロックで動作する）ハード部（即ち、ＤＵＴ５０）をうまく結合するための仕組みを持つ構造が一般的である。テストベンチ９０は、テストシナリオ２と、シナリオ切り替え４と、ドライバー５と、モニタ６と、疑似モデル７と、期待値比較部８とを有する。

テストシナリオ２には、検証項目表１の各項目に対応し、検証の手順が記述されている。シナリオ切り替え４が、検証目的に応じてテストシナリオ２を切り替えることで、トランザクションＴＲがテストシナリオ２から出力される。出力されたトランザクションＴＲは、ドライバー５と、疑似モデル７とに提供される。

ドライバー５は、入力されたトランザクションＴＲを複数の信号線、時系列に分割して、ＤＵＴ５０に送信する。ＤＵＴ５０は、Verilog等のハードウェア記述言語により表される所定の処理を受信した信号に対して行い、その結果として信号を出力する。ＤＵＴ５０から出力された信号は、テストベンチ９０のモニタ６により受信される。

モニタ６は、受信した信号をトランザクションＴＲに再構築し、所定のダンプ用の記憶領域に受信した出力信号をダンプデータとして記録し、また、疑似モデル７と期待値比較部８とに提供する。トランザクションＴＲは、転送処理の単位データで転送され、人が理解し易い形式のデータである。

疑似モデル７は、モニタ６から受信したトランザクションＴＲを用いて、検証対象のハード部の後段の処理を疑似的に行うソフトウェアによるモデルである。期待値比較部８は、モニタ６から受信したトランザクションＴＲと、疑似モデル７によって処理された結果とを比較し、比較結果を出力する。

上述したテストベンチ９０による論理検証は、論理設計工数の７０％を占め、開発の長期化の要因の一つである。論理検証の主な工程について図２で説明する。

図２は、論理検証の工程を説明するためのフローチャート図である。図２において、論理検証は、
・仕様分析の工程ａ
・検証項目抽出の工程ｂ
・テストベンチの開発（検証環境構築）の工程ｃ
・テストシナリオ作成（テストデータ作成）の工程ｄ
・シミュレーション（及びバグ解析）の工程ｅ
を有する。

仕様分析の工程ａでは、機能仕様書３２を読み込んで、
・機能
・入出力信号(プロトコル）
・データフォーマット
・レジスタ
などの分析が行われる。機能仕様書３２は、検証対象のハード部の機能を定めた仕様を記憶したデータファイル等である。

検証項目抽出の工程ｂでは、
・ユースケース分析/機能分析
等が行われる。この工程ｂにより検証項目表１が作成される。

テストベンチの開発の工程ｃでは、高いスキルを持つ開発者によって行われる工程であり、
・全体フレームワーク
・トランザクション生成
・シナリオＩＦ
・ドライバー
・モニタ
・期待値モデル（擬似モデル）
・エラー挿入処理
等が行われる。

テストシナリオ作成の工程ｄでは、検証項目表１を使用して、テストシナリオ２を作成する工程である。検証項目表１の複数の項目のそれぞれに対応するテストシナリオ２が作成される。

シミュレーションの工程ｅでは、テストベンチ９０上でテストシナリオ２を選択し、選択したテストシナリオ２に従ってシミュレーションが行われる。

品質を高めるためには、限られた時間（又は期間）内で、有効な検証データを大量にＤＵＴ５０に送信可能とすることが望まれている。つまり、検証の割合を上げ、それ以外の工程は極力小さくすることである。

大規模ＬＳＩ／ＦＰＧＡでは、機能の複雑化により、テストベンチ９０の開発規模や難易度が上がると共に、検証項目数は、数千項目におよび、テストシナリオ２を作成するだけでも、多大な工数を必要とする。特に、テストシナリオ２の作成は、検証項目に合わせフローを大量に記述しなければならない。共通化は可能だが、多人数で好き勝手に共通化されると、検証項目と一致するのかさえアヤフヤになるなどの問題点も多い。加えて、検証項目は、機能単位、ユースケース単位に作成するため、重複したデータが多量に存在し、無駄が多くなる。

上述した課題を解決するために、本実施例では、検証手法（各工程）の見直しと、定型化（ルール化）を行う。後述される定型化により、自動生成が可能となり無駄なテストパターンの排除とテストシナリオ開発工数の削減が可能となる。

＜検証手法（各工程）の見直し＞
無駄なテストパターンが多く発生するのは、検証項目抽出工程に起因するため、人手による検証項目策定をやめ、ＤＵＴ５０を動作させるためのパラメータから検証項目を生成することを考える。

検証項目抽出は、「機能仕様書を整理したものに過ぎない」との考えの基、逆に入力データ仕様から生成された検証項目書と、機能仕様書のリンクを明確化することで、機能漏れや記載漏れなどの上流バグの流失を早期に検出でき、品質向上が見込まれると考えられる。

仕様分析工程は、必ず、動作条件を明確化するため、従来のやり方とは大きく乖離しない。本実施例の特徴は、現状の検証項目抽出工程で、すべての入力データ、手順、タイミングをパラメータ化することである。

＜定型化（ルール化）＞
通常、ＤＵＴ５０の入出力はまちまちで、機能も動作手順も定型化は、規格化されているＩＰを除き、困難である。ＤＵＴ５０を動作させるため検証処理は、以下の動作が必要である。
（１）動作モード
リセット信号、動作イネーブル信号、変化タイミング（時間）などである。
（２）レジスタ設定
閾値や、機能切り替え、様々な演算のための定数などである。
（３）通信からの機能情報
例えば画像や、通信パケット等の入力データや、通信するための信号やり取り（プロトコル）の範囲、信号やパケットの投入タイミング（時間）などである。
（４）テストベンチの振る舞い
対向のシュード（動作モデル：ＤＵＴ５０の出力結果により動的に振る舞いを変える）や、エラー挿入などの仕組みなどである。

ＤＵＴ５０の実行には必ず、動作手順（大きくは、初期化と実行の２フェーズ）が存在する。初期化においては、レジスタ設定順番も規定されている。検証項目に合わせ、手順のコード化（テストシナリオ）が必要になる。（図３参照）。

これは、ＬＳＩ／ＦＰＧＡを制御するためのファームウエアの処理と同等となる。つまり、ファームウェアは、（２）レジスタ設定のみ、正常データのみとなる。（３）（４）もマッピングされている別ハードウェアのレジスタをアクセスすることになる。

現状のテストシナリオは複雑化し、定型化が困難（どんなＬＳＩ／ＦＰＧＡでも同じルールで使用できるようにするのは難しい）な理由は、制御とデータ生成が混在しているためである。まず、制御も含めてデータ生成を完全に分離する。テストシナリオ２は、制御だけになり、シンプルになる。次に、制御の要素もデータとして扱うと、テストシナリオ２は定型化できる。

即ち、上記（１）〜（４）の動作を全て、ＤＵＴ５０を動作させるためのパラメータとして定義する。つまり、疑似モデル７のようなシュードの動作もコマンドとしてパラメータ化する。その際、動作異常やエラー挿入などもパラメータとする。

上述したように、発明者は、ＤＵＴ５０の動作を外部からのパラメータだけで制御可能とすることで、どんなＬＳＩ／ＦＰＧＡであろうが、テストシナリオ２の作成方法を定型化することができることに着目した。

図３は、一般的なテストシナリオで記述される動作例を説明するためのフローチャート図である。図３において、テストシナリオ２がシナリオ切り替え４で選択されると、選択されたテストシナリオ２からトランザクションがドライバー５に提供され、ドライバー５は、トランザクションを分割して、複数の信号をＤＵＴ５０へと送信を開始する。

トランザクションによって行われる動作を説明する。まず、ハード部（ＤＵＴ５０）をリセットする（ステップＳ２１）。トランザクションにより、各種動作モード信号が設定され（ステップＳ２２）、ドライバー５によって、必要なレジスタへ初期値の書き込みが行われる（ステップＳ２３）。このステップＳ２２及びＳ２３は、検証項目によってフローが異なる。

トランザクションは、更に、動作を開始するためのレジスタへの書き込みをドライバー５に行わせ（ステップＳ２４）、所定時間後、開始可能レジスタを読み込ませて（ステップＳ２５）、開始可能か否かを判定させる（ステップＳ２６）。開始可能でない場合（ステップＳ２６のＮｏ）、所定時間毎に、ステップＳ２５が繰り返される。一方、開始可能の場合（ステップＳ２６のＹｅｓ）、時間調整後、ドライバー５により、ＤＵＴ５０に対して、様々なパケット送信や、レジスタ値の変更が行われる（ステップＳ２７）。時間調整及びステップＳ２７は、検証項目によってフローが異なる。

ドライバー５は、全てのトランザクションを終了したか否かを判断する（ステップＳ２８）。終了していない場合（ステップＳ２８のＮｏ）、時間調整とステップＳ２７とが繰り返される。一方、終了している場合（ステップＳ２８のＹｅｓ）、選択されたテストシナリオ２による論理検証を終了する。上述したステップＳ２１〜Ｓ２９は、論理検証全体を終了するまで繰り返し行われる。

従来では、開発者が上述した動作をプログラミングしていた。以下に、検証項目１の自動作成に加え、複数のテストシナリオ２を自動的に生成する本実施例について説明する。まず、発明者により着目され見出された手法について説明する。まず、概念とその定義を以下に示す。

＜概念とその定義＞
上述した定型化をうまく活用できるように、テストベンチ９０は、ＴＬＭを前提に、全ての信号生成を可能とするトランザクションデータを定義する。本実施例において、トランザクションデータの項目の設定値を外側から定義することを「検証項目」とする。ここでは、トランザクションデータの項目をパラメータ、外側から定義する、実行できる検証項目を「テストシナリオ」と定義する。トランザクション生成の情報として、パラメータ定義、構造定義、メモリ定義を検証者が作成する。

図４は、入力制御データとトランザクションの関連を説明するための図である。図４において、入力制御データ１１１は、パラメータ定義表１１２と、メモリ定義表１１３と、構造定義表１１４とを有し、検証者によって作成される。

構造定義表１１４には、領域データと形式データとがあり、領域データがトランザクションの領域で、形式データはその領域を定めた形式で使用することを定義する。ＤＵＴ５０を様々な検証のために動作させるパラメータが、トランザクションの領域に全て用意されている必要がある．
パラメータ定義表１１２のみで定義される構造定義表１１４と、メモリ定義表１１３とパラメータ定義表１１２とで定義される構造定義表１１４とがある。

この例では、領域データ０−０及び形式データ０−０−０〜形式データ０−０−ｍと、領域データ０−ｎ及び形式データ０−ｎ−０〜形式データ０−ｎ−ｍとが1つの構造定義表１１４に相当する。

この構造定義表１１４は、領域データ０−０〜０−ｎにより定義したトランザクション０−０から０−ｎで構成される。領域データ０−０及び形式データ０−０−０〜形式データ０−０−ｍとがトランザクション０−０に相当し、領域データ０−ｎ及び形式データ０−ｎ−０〜形式データ０−ｎ−ｍとがトランザクション０−ｎに相当する。領域データ１−０〜１−ｎにより定義したトランザクション１−０から１−ｎで構成される構造定義表１１４も同様である。

また、パラメータ定義表１１２とメモリ定義表１１３とで定義される構造定義表１１４は、レジスタの制御に係る定義に相当し、領域データｐ−０〜ｐ−ｎにより定義したトランザクション０−０から０−ｎで構成される。領域データｐ−０及び形式データｐ−０−０〜形式データｐ−０−ｍとがトランザクションｐ−０に相当し、領域データｐ−ｎ及び形式データｐ−ｎ−０〜形式データｐ−ｎ−ｍとがトランザクション０−ｎに相当する。

ドライバー５及びモニタ６は、インタフェースＩＦ０〜ＩＦｐを有する。ＤＵＴ５０との信号の送受信は、ＩＦ０〜ＩＦｐで行われる。ＩＦ０では、トランザクション０−０〜０−ｎに従った信号の送受信が行われる。他のＩＦ１〜ＩＦｐにおいても対応するトランザクション１−０〜１−ｎ、・・・、トランザクションｐ−０〜ｐ−ｎに従った信号の送受信が行われる。

本実施例において、以降、上述した領域データを「オーナー」、形式データを「テナント」と呼ぶものとする。図５は、本実施例における用語の概念を説明するための図である。図５において、トランザクション−０〜トランザクション−ｋのそれぞれは、複数のオーナーで構成される。

トランザクション−０は、オーナー０−０〜オーナー０−ｎの領域データによって構成される。また、トランザクション−ｋは、オーｋ−０〜オーナーｋ−ｎの領域データによって構成される。他のトランザクションにおいても同様である。

更に、オーナー０−０に関連付けられる形式データは、テナント０−０−０〜０−０−ｍであり、オーナー０−ｎに関連付けられる形式データは、テナント０−ｎ−０〜０−ｎ−ｍであり、他オーナーについても同様に形式データが関連付けられる。各オーナーには操作するアドレスが設定され、テナントにはパラメータが設定される。

図５に示した概念において、発明者は、
（１）パラメータの組合せの数は膨大にならないか
（２）意味不明な検証項目にならないか
について考察した。

（１）パラメータの組合せの数は膨大にならないか
パラメータの値は、大きさ（Ｂｉｔ数）で範囲が決まる。通常検証を行う際には、Ｍｉｎ／Ｍａｘ／典型値を使用する。ほとんどのパラメータは、Ｍｉｎ／Ｍａｘ値のみで十分だが、ＤＵＴ５０の実装依存によっては、いくつかの典型値を必要とするケースもある。また一つのパラメータが決まると連動して決定されるパラメータ等も存在する。

タイミングに関しては、Ｍｉｎ／Ｍａｘ値以外は、制約付ランダムを使用するのが望ましい（人が予想しない衝突などの可能性がある）。完全な検証を行う場合は、全てのパラメータの組合せはアンド論理で行う必要があり、Ｍｉｎ／Ｍａｘ値だけだとしても２のｎ乗となり間違いなくパラメータの組合せは、爆発的に膨大になる。従って、制約が必要となり、グループ単位に行うことで、明確化すると共に、組合せ数を削減する。

（ア）パラメータ間の関係強度の設定
パラメータには、パラメータ間で影響しあうもの、影響しない（直交する）ものが存在する。ただし、直交するかどうかは、ＤＵＴ５０の実装依存である。直交するパラメータはオア論理で組み合わせると大幅なパラメータ削減が可能となる。関係強度は、アンド論理が必要なものをグループ分けする。また、組合せ数を抑制する目的で、強度を優先順位として扱う。閾値を越えた場合は、優先度が低い順にアンドをオアに変更し、調整する。

（イ）アンド組合せをトランザクション内に限定する
トランザクションの中身に着目すると、動作モードやデータ内容によっては、使用するパラメータが限定できる。即ちトランザクションの中身の設定を排他定義できるようにする。トランザクション領域毎に複数の構造定義表（テナント定義）を行うことで排他的に定義する。本実施例では、このデータの塊で組合せを管理する。

（２）意味不明な検証項目にならないか
（１）の（イ）のトランザクションをうまく使用すると、データの組合せの検証項目表１になる。図５に示すように、トランザクションは１又は複数のオーナーで構成され、オーナーは１又は複数のテナントで定義される。つまり、トランザクションはテナントの組合せで表現できる。テナント名を意味のある名前にすると、十分に検証項目として活用できる。

テストシナリオは、階層毎に、１以上のトランザクションを有し、複数のパラメータでトランザクションの形式データを定義する１以上のテナントが対応付けられ、トランザクションは、複数のテナントによって領域データを表すオーナーを１つ以上含むように構成する。本実施例では、このテナント（形式データ）の組合せの検証項目表１を自動生成することで、無駄なテストパターンの排除を行う。定型化と、パラメータ定義、構造定義、及びメモリ定義を行うことで、テストシナリオ２のソースコード及びテストベンチ９０の自動生成を行う本実施例における検証手順生成部８０（図６）について詳述する。

本実施例の実現方法は２つのフェーズに分けられる。
（１）制御データを読み込み、検証項目表１を作成し、テストベンチ９０のソースコードを生成する。
（２）シミュレータで、テストデータを生成し、信号発生する。

アルゴリズムを（１）及び（２）で分担するいくつかの方法が考えられる。ここでは、シミュレーションの性能面や、テストベンチ９０の使いやすさや、汎用面を考慮した以下の方法での実現方法を記載する。

上記（１）では、機能仕様書に含まれるテーブルを静的に展開したソースコードを生成する。上記（２）では、ループ変数から動的に、トランザクションを生成する。

図６は、本実施例の検証手順生成部とテストベンチとの関係を説明するための図である。図６において、検証手順生成部８０は、検証項目表１と、テストシナリオ２と、シナリオ切り替え４と、トランザクションＴＲとを自動的に生成する。

既存の手法では、テストシナリオ２を自動生成できないが、本実施例では、検証項目表１に加えて、テストシナリオ２を自動的に生成する。

図７は、本実施例における論理検証処理の全体フローを示す図である。図７において、論理検証は、
・仕様分析の工程Ｉ
・パラメータ定義表の作成の工程ＩＩ
・構造体定義表の作成の工程ＩＩＩ
・テストベンチの開発の工程ＩＶ
・検証手順の生成（検証項目、テストシナリオの生成）の工程Ｖ
・シミュレーション（及びバグ解析）の工程ＶＩ
を有する。

仕様分析の工程Ｉでは、機能仕様書３２を読み込んで、
・機能
・入出力信号(プロトコル）
・データフォーマット
・レジスタ
などの分析が行われる。機能仕様書３２は、検証対象のハード部の機能を定めた仕様を記憶したデータファイル等である。

パラメータ定義表の作成の工程ＩＩでは、
・全ての変数(レジスタ、データ)に固有名(パラメータ名)を付ける
・タイミング(時間)をパラメータ化
・制御をパラメータ化
・パラメータ値の試験値、デフォルト値（固定値）を明確化する
等が行われる。パラメータ定義表１１２が作成される。

構造体定義表の作成の工程ＩＩＩでは、
・領域を定義（オーナー構造）
レジスタの場合はアドレス範囲も定義
・領域の仕切り（パラメータ名使用）を定義（テナント構造）
・機能単位に分ける
等が行われる。メモリ定義表１１３及び構造定義表１１４が作成される。

テストベンチの開発の工程ＩＶでは、
・ドライバー
・モニタ
・期待値モデル（擬似モデル）
・エラー挿入処理
等が行われる。検証者（又は開発者）は、全体のフレームワークを考えなくてよいため、スキル依存度を低減できる。それによって、本実施例により、検証者（又は開発者）の作業量を大きく削減でき、テストベンチ９０の個別動作部分（テストベンチ個別動作部９０−１）だけを記述すればよいことになる。テストベンチ個別動作部９０−１は、システム記述言語により記述されたプログラムであり、図６において、ドライバー５と、モニタ６と、疑似モデル７と、期待値比較部８とを実現する。

検証手順の生成の（検証項目、テストシナリオの生成）の工程Ｖでは、
・組合せ検証項目表１１６
等が作成される。検証手順の生成の工程Ｖでは、主に、検証項目を作成し、検証項目に対応するテストシナリオ２を自動生成する。工程Ｖにより、組合せ検証項目表１１６と、テストベンチ部品１１７とが作成される。

組合せ検証項目表１１６では、構造定義表１１４毎に、１又は複数の検証項目が示される。テストベンチ部品１１７には、
・テストベンチのフレームワーク
・メイン（テスト）タスク部
・シナリオタスク部
・トランザクションＩＦ用の関数部
が含まれる。メインタスク部は、組合せ検証項目表１１６の検証項目に対応する。

シミュレーションの工程ＶＩでは、テストベンチ９０上でテストシナリオ２を選択し、選択したテストシナリオ２に従ってシミュレーションが行われる。

上述した、本実施例における論理検証の工程Ｉ〜ＩＩＩ、Ｖ、及びＶＩは、図８に示すようなハードウェア構成を有する検証手順生成装置１００により実現される。図８は、検証手順生成装置のハードウェア構成を示す図である。

図８において、検証手順生成装置１００は、コンピュータによって制御される情報処理装置であって、ＣＰＵ（Central Processing Unit）１１と、主記憶装置１２と、補助記憶装置１３と、入力装置１４と、表示装置１５と、通信Ｉ／Ｆ（インターフェース）１７と、ドライブ装置１８とを有し、バスＢ１に接続される。

ＣＰＵ１１は、主記憶装置１２に格納されたプログラムに従って検証手順生成装置１００を制御するプロセッサに相当する。主記憶装置１２には、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１にて実行されるプログラム、ＣＰＵ１１での処理に必要なデータ、ＣＰＵ１１での処理にて得られたデータ等を記憶又は一時保存する。

補助記憶装置１３には、ＨＤＤ（Hard Disk Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１３に格納されているプログラムの一部が主記憶装置１２にロードされ、ＣＰＵ１１に実行されることによって、各種処理が実現される。

入力装置１４は、マウス、キーボード等を有し、ユーザである検証者（又は開発者）が検証手順生成装置１００による処理に必要な各種情報を入力するために用いられる。表示装置１５は、ＣＰＵ１１の制御のもとに必要な各種情報を表示する。入力装置１４と表示装置１５とは、一体化したタッチパネル等によるユーザインタフェースであってもよい
。通信Ｉ／Ｆ１７は、有線又は無線などのネットワークを通じて通信を行う。通信Ｉ／Ｆ１７による通信は無線又は有線に限定されるものではない。

検証手順生成装置１００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９によって検証手順生成装置１００に提供される。

ドライブ装置１８は、ドライブ装置１８にセットされた記憶媒体１９（例えば、ＣＤ−ＲＯＭ等）と検証手順生成装置１００とのインターフェースを行う。

また、記憶媒体１９に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体１９に格納されたプログラムは、ドライブ装置１８を介して検証手順生成装置１００にインストールされる。インストールされたプログラムは、検証手順生成装置１００により実行可能となる。

尚、プログラムを格納する記憶媒体１９はＣＤ−ＲＯＭに限定されず、コンピュータが読み取り可能な、データ構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤ（Digital Versatile Disk）ディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。

主記憶装置１２、補助記憶装置１３、種々の外部記憶装置を含めて、記憶部１３０と呼ぶものとする。記憶部１３０には、図６の検証手順生成部８０と、テストベンチ個別動作部９０−１と、ドライバー５と、モニタ６と、ＤＵＴ５０のそれぞれのプログラムが記憶され、ＣＰＵ１１がそれらを実行することにより、対応する機能が実現される。

先ず、本実施例における入出力について説明する。図９は、検証手順生成部における入出力を説明するための図である。図９において、検証手順生成部８０に対して、制御データ８１と、パターン数制限８３とが入力される。

制御データ８１は、パラメータ定義表１１２、メモリ定義表１１３、及び構造定義表１１４を含む。
（１）パラメータ定義表１１２
データの最小単位で、ＤＵＴ５０を実行する機能を確定するモード（レジスタ値）や、データの中身（例えばパケットフォーマットの項目）、信号値、信号動作タイミング変数などを指定する。テストベンチ制御（具体的には、擬似モデル７の制御）のための変数なども含まれる。即ち、検証において、１機能を確認する際に固定される変数が指定される。
（２）メモリ定義表１１３
レジスタ設定に必要な情報が定義されている。開始アドレス、領域の大きさなどを含む。レジスタ設定用のトランザクションの構造定義表１１４にリンクされる。
（３）構造定義表１１４
パラメータのトランザクション単位の集合を表す。ＤＵＴ５０のインターフェースの機能信号単位や、データやり取り単位、テストベンチ９０の制御単位など、制御の集合や、データの塊の集合が定義される。テストシナリオ２とドライバー５及びモニタ６とのインターフェースフォーマットの定義となる（図６参照）。

パターン数制限８３は、本実施例において生成されるパターン振り回数の上限を示すデータである。パターン振り回数が上限（閾値）を超えた場合、組合せを緩和（＆を｜に変更）し、再度実行し、上限内に収まるまで繰り返えされる。

組合せ検証項目表１１６は、オーナー毎に関連付けられたテナントを１レコードとして示したテーブルである。詳細は後述される。テストベンチ部品１１７は、テストベンチ個別動作部９０−１に組み込まれる。

次に、制御データ８１に含まれる各定義表１１２〜１１４のデータ構成例について説明する。図１０は、パラメータ定義表のデータ構成例を示す図である。図１０において、パラメータ定義表１１２は、パラメータ毎に定義される情報を示したテーブルであり、パラメータ名、ビット数、試験値、関係強度、連動関数、生成関数、回数、定数０〜定数ｎ等の項目を有する。

パラメータ名は、パラメータの識別名を示す。パラメータ名は固有名である。ビット数は、パラメータの領域サイズを示す。試験値は、試験する値を指定する。試験する値を特定しない場合、試験値は空欄（null）となる。

関係強度は、関係のあるパラメータ同士を同一番号で示す。番号の大小に意味は無い。パラメータ設定はＡＮＤとなるが、パターン数が上限の閾値を超えた場合にはＯＲに切り替えられる。連動関数は、他パラメータによって値が決定するものの論理を記述した関数を指定する。連動するパラメータ名が指定される。

生成関数は、制約付きランダム発生などの論理を記述した関数を指定する。回数は、生成関数の呼出し回数を指定する。定数０〜定数ｎは、パラメータ値を固定値で使用したい場合の値を指定する。テナント構造で指定される。

図１１は、メモリ定義表のデータ構成例を示す図である。図１１（Ａ）において、メモリ定義表１１３は、メモリ毎に図１１（Ｂ）に示すような領域に関する情報を定義し、メモリ名、ワード数、ビット幅、絶対アドレス、開始アドレス等の項目を有する。

メモリ名は、メモリ領域単位に与えられた識別名を示し、メモリ定義表１１３において固有である。具体的には、レジスタを特定する値である。ワード数は、図１１（Ｂ）に示すように領域内のワード数ｎを示す。ビット幅は、図１１（Ｂ）に示すように領域内のビット幅を示す。

絶対アドレスは、記憶部１３０内の基点となるアドレスを示す。開始アドレスは、絶対アドレスからの相対アドレスを示し、絶対アドレスに示された相対アドレスを加算することで、メモリ名で特定される領域の開始アドレスとなる。

図１２は、レジスタ以外の構造定義表のデータ構成例を示す図である。図１２において、構造定義表１１４は、図１１で説明したメモリ定義表１１３で定義されるメモリ（即ち、レジスタ）以外について定義したテーブルであり、オーナー毎に定義したオーナー定義表１１４ａと、テナント毎に定義したテナント定義表１１４ｂとを有する。レジスタに関する構造定義表１１４は、図１３で説明する。

オーナー定義表１１４ａは、オーナー（領域データ）毎の定義情報を示し、オーナー構造名、処理階層、トランザクション、項目名、ビット数等の項目を有する。オーナー構造名は、オーナーを特定する識別名を示し、オーナー定義表１１４ａ全体において固有である。

処理階層は、定義情報（トランザクション）の実行階層を指定する。実行階層間の組合せはＡＮＤになる。トランザクションは、トランザクションを特定する識別名を示す。同一トランザクションで複数のオーナーを使用する場合には、同じ識別名が指定される。同一識別名の複数のオーナーが一つのトランザクションにマッピングされる。項目名は、領域の名前を指定する。ビット数は、大きさを指定する。

テナント定義表１１４ｂは、テナント（形式データ）毎の定義情報を示し、テナント構造名、オーナー名、項目名、振る舞い、ビット数等の項目を有する。テナント定義表１１４ｂでは、１つのテナント構造に対して複数の項目名が対応付けられる。

テナント構造名は、テナントを特定する識別名を示す。オーナー名は、属するオーナーを特定する識別名を指定する。項目は、対応パラメータ名を指定する。対応パラメータが無い場合、当該テナント構造内で固有な識別名を指定する。この場合、生成関数、ビット数が指定される。

振る舞いは、項目名がパラメータの場合、省略（“試験値”を選択とみなす）か、“連動関数”、“生成関数”（値はパラメータ表に指定した関数値で生成、組合せは“回数”）等が指定される。定数０〜定数ｎが指定（値が固定され、組合せの対象から外れる）される。また、パラメータで無い場合、振る舞いには、値を生成する関数が指定される。

ビット数は、項目名がパラメータの場合は、空欄か、或いは同じ値を示す。パラメータではない場合、ビット数には領域のサイズが指定される。ビット数の合計は、オーナーと同じにしなければならない。

オーナー定義表１１４ａのオーナー構造名とテナント定義表１１４ｂのオーナー名とにより互いに関連付けされる。

次に、レジスタに関する構造定義表１１４について図１３及び図１４で説明する。図１３は、レジスタに関する構造定義表のデータ構成例（その１）を示す図である。図１３では、レジスタに関する構造定義表１１４のうち、オーナー定義表１１４ｇを示し、オーナー構造名、処理階層、トランザクション、メモリ名、開始ワード、項目名、ビット数、読み書き種別、初期値、優先度、リセット１〜リセットｎ等の項目を有する。オーナー定義表１１４ｇでは、１つのオーナー構造に対して複数の項目名が対応付けられる。

オーナー構造名は、オーナーを特定する識別名を示し、オーナー定義表１１４ｇ全体において固有である。処理階層は、当該構造定義（トランザクション）の実行階層を指定する。実行階層間の組合せはＡＮＤになる。トランザクションは、同一トランザクションで複数のオーナーを使用する場合のみ、同じ識別名を示す。同一識別名の複数のオーナーが一つのトランザクションにマッピングされる。

メモリ名は、当該構造定義の領域が対応するメモリの識別名を指定する。開始ワードは、対応するメモリの開始ワード位置を指定する。項目名は、領域の識別名を指定し、該当構造定義内では固有である。ビット数は、項目のビット数を指定し、メモリ定義表１１３のビット数と一致するか、整数倍である。

読み書き種別は、アクセス制限を示す。一例として、ビット単位に制限を示してもよい。制限は、u:無効、r:Readのみ、w:Writeのみ、b:Read/Write両方等で示される。初期値は、論理検証時の初期値を示す。優先度は、レジスタ書込み順番の優先度を指定する。数字の小さい順にWriteする。最大値は１つだけで最後に書く（スタートレジスタになる）。リセット１〜リセットｎのそれぞれでは、リセットを指定する。１を示す項目がリセットされる。また、t(X)を示す場合、t(X)を指定した項目の値がXになったときに実行することを示す。t(X)のtはtriggerである。

図１４は、レジスタに関する構造定義表のデータ構成例（その２）を示す図である。図１４では、レジスタに関する構造定義表１１４のうち、テナント定義表１１４ｈを示し、テナント構造名、オーナー名、項目名、振る舞い、ビット数等の項目を有する。テナント定義表１１４ｈでは、１つのテナント構造に対して複数の項目名が対応付けられる。

テナント構造名は、テナントを特定する識別名を示し、テナント定義表１１４ｈ全体で固有である。オーナー名は、属するオーナーを特定する識別名を指定する。項目名は、対応パラメータ名を指定する。対応するパラメータが無い場合は、当該テナント構造内で固有な識別名を指定する。この場合、生成関数、ビット数が指定される。

オーナー定義表１１４ｇのオーナー構造名とテナント定義表１１４ｈのオーナー名とにより互いに関連付けされる。

次に、出力について説明する。まず、組合せ検証項目表１１６について説明する。図１５は、組合せ検証項目表について説明するための図である。図１５では、３つのトランザクションがあった場合のオーナーとテナントの対応関係を定義した対応付けリスト１１５ａを示している。

この例では、トランザクション０に対して、１つのオーナー０が対応付けられ、更に、２つのテナント１−０と１−１とが対応付けられている。同様に、トランザクション１に対しては、１つのオーナー１、３つのテナント２−０、２−１、及び２−３が対応付けられている。また、トランザクション２に対しては、２つのオーナー２及び３が対応付けられ、オーナー２に対して２つのテナント３−０及び３−１が対応付けられ、オーナー３に対してオーナー３に対して１つのテナント４−０が対応付けられている。

組合せリスト１１５ｂは、この対応付けリスト１１５ａから得られる。組合せリスト１１５ｂは、組合せ検証項目表１１６で示される全ての検証項目の構成の概要を示している。組合せリスト１１５ｂは、トランザクション０、１、及び３のテナントを組み合わせることで作成される。

対応付けリスト１１５ａを参照して、トランザクション毎に、オーナーのうちテナント数が最大の値を採用することで、組合せの検証項目を全て抽出することができる。上述の対応付けリスト１１５ａのデータ例では、トランザクション０では、オーナー数は「１」及びテナント数は「２」である。トランザクション１では、オーナー数は「１」及びテナント数は「３」である。トランザクション２では、オーナー数は「２」であるため、いずれかテナント数が最大となる数を採用する。この例では「２」又は「１」であるため、「２」を採用する。従って、組合せの検証項目の総数は、
２×３×ｍａｘ（２，１）＝１２
を得る。

組合せリスト１１５ｂに示すように、検証項目０〜１１までの１２個が作成される。検証項目０〜１１では、トランザクション０〜２のそれぞれに対応付けられるテナントが組み合わされている。

上述したように検証項目を作成した場合の組合せ検証項目表１１６のデータ構成例について以下に示す。図１６は、検証構成表の例を示す図である。図１６において、検証構成表１１６−１は、検証項目毎に検証構成を示すテーブルであり、検証項目名、パターン数、階層１、階層２、階層３等の項目を有する。

検証項目名は、検証項目を特定する識別名を示す。パターン数は、階層１〜ｎのパターン数の総積を示す。階層１〜階層３は、フェーズを表し、フェーズ内のパターン数を示す。フェーズとして、初期化、実行等がある。

階層１〜３それぞれは、テナントの総数と、利用されるテナントの識別名とを示す。テナントの総数は、各階層のパターン数を示す。テナントの識別名は、この例では、tenantN_nの場合、Ｎはオーナー番号を特定し、ｎは特定されたオーナーにおけるテナントを特定する。

図１６に示す検証構成表１１６−１の最後の検証項目「TEST_nnnnn」では、パターン数は、各階層のパターン数を用いて、６×３２×８１により１５５５２が示されている。また、テナント識別名の最後の文字x，y，z，o，及びpはテナントの最大数を示すことになる。

図１７は、組合せ詳細表の例を示す図である。図１７において、組合せ詳細表１１６−２は、検証項目毎に各テナントによって与えられるパラメータ情報を示すテーブルである。組合せ詳細表１１６−２は、検証項目名、構造定義、パターン、論理、パラメータ、値１〜値１２等の項目を有する。

検証項目名は、検証項目を特定する識別名を示す。構造定義は、テナントを特定する識別名を示す。パターンは、関連するパラメータの個数の最大数（ｍａｘ）と、利用数（ｕｓｅ）とを示す。論理は、ＡＮＤ又はＯＲ（以下記号で表される場合がある）を示す。パラメータは、パラメータを特定する識別名を示す。値１〜値１２は、パラメータの値を示す。連動関数や、生成関数の場合、値「＊」が示される。連動関数の場合、連動するパラメータと同じ値であることを意味する。

図９に示すテストベンチ部品１１７は、テストベンチ個別動作部９０−１に組み込まれる分であり、System Verilog, SystemC等のシステム記述言語で記述される。テストベンチ部品１１７には、テストベンチ固有部から呼び出す（コールする）サービス関数（関数部）が含まれている。この関数部のアルゴリズムについて以下に詳述する。

関数部は、主に以下の動作を行う。
（１）制御データ８１を読み込み、組合せ検証項目表１１６を作成し、テストベンチ９０のソースコードを生成する。
（２）シミュレータで、テストデータを生成し、信号を発生する。

上述（１）及び（２）の内容は、アルゴリズム（Ｃ又はＣ＋＋等のソフトウェア）と、出力結果として生成されたテスト部品の処理アルゴリズム（SystemVerilog又はSystemCなどのシステム記述言語）とにより表現される。

本実施例における基本方式は、全体の処理を全て組合せで管理し、１処理の番号から個々の処理を確定する。ここでは、シナリオ番号からテナントを決定するループ番号からパラメータの値を決定する（関連強度が高い場合＆とみなす）、方法に使用している。以下に処理番号から、設定値のインデックス番号を確定する計算式を示す。

組合せを作りたいＡ，Ｂ，Ｃをそれぞれ、
A[n]=｛A0,A1,A2,..,An} n=0,1,2,3..
B[m]=｛B0,B1,B2,..,Bm} m=0,1,2,3..
C[k]=｛C0,C1,C2,..,Bk} k=0,1,2,3..
とする。Ａ−Ｂ−Ｃの順で組み合わせると、
Aインデクス番号 = (n-1) - (処理番号 % (n*m*k)) / (m*k) ;
Bインデクス番号 = (m-1) - (処理番号 % (m*k)) / k ;
Cインデクス番号 = (n-1) - (処理番号 % k) ;
となる。ただし、処理番号は逆順となる。ここで、検証項目番号からテナント番号への変換例について図１８に示す。図１８は、検証項目番号からテナント番号への変換例を説明するための図である。

図１８（Ａ）では、オーナーとテナントとの対応関係の例を示している。オーナー「Owner0」には４つのテナントが対応付けられ、オーナー「Owner1」には３つのテナントが対応付けられ、オーナー「Owner2」には２つのテナントが対応付けられている。これらの対応付けを配列use[]で表すと、
Owner0のテナント数はuse[0]=4で表され、
Owner1のテナント数はuse[1]=3で表され、
Owner2のテナント数はuse[2]=2で表される。

更に、Owner0、Owner1、そしてOwner2の順番で、テナントのインデックスを並べて数字を作成し、Owner0,1,2を桁として配列max[]で表現すると、
Owner0の組合せ桁数はmax[0]=24で表され、
Owner1の組合せ桁数はmax[1]=6で表され、
Owner2の組合せ桁数はmax[2]=2で表され、
max[3]=1で表される。

そして、オーナーのテナント取得計算式は、
Owner0のテナント取得計算式=use[0]-1-(r_no%max[0])/max[1]で表され、
Owner1のテナント取得計算式=use[1]-1-(r_no%max[1])/max[2]で表され、
Owner2のテナント取得計算式=use[2]-1-(r_no%max[2])/max[3]で表される。

図１８（Ｂ）では、上述したテナント取得計算式により得られるテナント名を一覧表で示している。図１８（Ｂ）に示す一覧表は、図１８（Ａ）のオーナーとテナントとの対応関係に基づいて、所定の組合せ規則に従って組合せた場合の表に相当し、ｎｏ、オーナーの識別名毎のテナント［配列番号］＝テナント名、ｒ＿ｎｏ等の項目を示している。

ｎｏは、組合せが作成された順に与えられ、組合せを特定する番号（組合せ番号）である。テナント［配列番号］＝テナント名は、組合せ番号で特定されるテナントの組合せを示している。ｒ＿ｎｏは、上述した本実施例のテナント取得計算式を単純化するためのｎｏの逆順を示す。

本実施例では、パラメータの組合せが膨大にならないように制約を与える。制約には、大きく以下の（Ａ）及び（Ｂ）の２種類を設定する。

（Ａ）パラメータの組合せの制約
完全な、ブラックボックス検証を行うためには、パラメータの値は、取りうる全ての値を使用し、パラメタを全て組み合わせて（ＡＮＤ）シミュレーションしなければならないので有限時間内には終わらない。大規模ＬＳＩでは、パラメータ数が、数百となるため、検証の値、組合せに制約を持たせる必要がある。

入力となる制御データ（パラメータ）は、テストシナリオ２を自動生成するにあたり以下の制約を定義する。

（ア）パラメータの試験値
検証に必要な値(最小値、最大値、典型値など)を任意に設定する。

（イ）関係強度
パラメータ同士の関係が深いものを定義する。関係が深いパラメータ群はＡＮＤで値を組合せる。関係が浅いパラメータはＯＲとなる。ＡＮＤの組合せ数は、総積となり、ＯＲは、相手との組合せは何でも良いため、足し算ではなく最大値でよい。テナント内のみでの組合せとなる。
一例として、カッコ内は、試験値の数
A(3)&B(6)|C(2)&D(3)|E(6)
は、A(3)&B(6)が最大組合せ数「１８」なので、組合せ数は１８となる。

（ウ）連動関数
他のパラメータに連動するパラメータを規定する。連動元のパラメータによって設置される関数を指定することで、複数のパラメータは１つに集約できる。

（Ｂ）シナリオ生成のための制約
トランザクションを定義する際、それを構成する項目は、同じレベルでの実行単位でなくてはならない。実行単位は、大きく、初期化フェーズと、通常動作に分類できる。さらに初期化フェーズなどは、手順が存在し、その順番に合わせて実行しなければならない。

つまり、シナリオを生成するためには、階層を意識する必要がある。また、これは、初期化フェーズ完了後（初期化時のパラメータを固定化し）、通常動作時のパラメタを与えることになるため、初期化トランザクションの変数と、通常動作時のトランザクションの変数は必然的に＆になる。これは、組合せの爆発を誘発する可能性がある。

（ア）処理階層の指定
トランザクションの実行単位の階層を指定する。例えば、初期化フェーズで実行するトランザクションの処理階層を最上位０とし、動作フェーズで実行するトランザクションを１にする。動作フェーズで実行するトランザクション内でさらに実行順番を規定する場合は、２にする。以下同様である。このようにして、処理階層条件を付与する。通常２階層、多くても３階層である。例えば、通信系であれば、初期化（信号設定や、レジスタ設定）が１、パケット種別設定や動的レジスタ設定が２、パケット生成が３になる（２と３は分けなくても良い）。

（イ）レジスタの実行優先度
レジスタは、初期化設定、実行開始設定、及び動的設定に分類できる。これらを設定優先フラグで規定する。

以下に、検証手順生成部８０によって行われる関係強度による組合せの回避処理の例を説明する。階層単位で計算した後、階層間で実施する。まず、階層単位の組合せ回避処理について説明する。

図１９は、階層単位の組合せ回避処理の例を説明するためのフローチャート図である。図１９では、処理例も合わせて示している。階層単位の組合せ回避処理は、全ての階層に対して組合せ数を決定するまで、階層毎に行われる。

図１９において、階層単位の組合せ回避処理が開始されると、階層単位の最大組合せ数を入力する（ステップＳ１１）。検証構成表１１６−１及びテナント定義表１１４ｈを参照して、パラメータ定義表１１２を用いて、階層内のテナントにあるパラメータのうち、関係強度の番号が同じパラメータを集めて、組合せ数（総積）を求める（ステップＳ１２）。そして、組合せ数が、予め定めた最大組合せ数を超えたか否かを判断する（ステップＳ１３）。

組合せ数が最大組合せ数を超えていない場合（ステップＳ１３のＮｏ）、処理対象の階層の組合せ数として決定し（ステップＳ１５）、この階層単位の組合せ回避処理を終了する。

一方、組合せ数が最大組合せ数を超えている場合（ステップＳ１３のＹｅｓ）、最大組合せ数をこえている関係高度の番号のパラメータの組合せ数をＯＲにし（ステップＳ１４）、ＯＲにした組合せ数を処理対象の階層の組合せ数として決定し（ステップＳ１５）、この階層単位の組合せ回避処理を終了する。

処理例では、最大組合せ数を３０００として、上記階層単位の組合せ回避処理を説明する。関係強度１にはaaa、bbb、ccc、及びdddのパラメータが存在し、それぞれ取りえる値が４値、７値、６値、及び２１値であるとする。関係強度１に関して、＆でパターン数を算出する（ステップＳ１２）。

aaa&bbb&ccc&ddd
より、３５２８パターンであることが分かる。

関係強度２にはeee、fff、及びgggのパラメータが存在し、それぞれ取りえる値が３値、１０値、及び５値であるとする。関係強度２に関して、＆でパターン数を算出する（ステップＳ１２）。

eee&fff&ggg
より、１５０パターンであることが分かる。

関係強度３にはhhh、iii、及びjjjのパラメータが存在し、それぞれ取りえる値が５値、３値、及び２値であるとする。関係強度３に関して、＆でパターン数を算出する（ステップＳ１２）。

hhh&iii&jjj
より、３０パターンであることが分かる。

更に、パターン数のうち最大数を取得する（ステップＳ１２）。

aaa&bbb&ccc&ddd | eee&fff&ggg | hhh&iii&jjj
より、３５２８パターンを得る。即ち、最大数を示すaaa&bbb&ccc&dddのパターン数が採用される。

この場合、取得した３５２８パターンが最大組合せ数「３０００」を超えているため（ステップＳ１３のＮｏ）、関係強度１が最大組合せ数を超えているためＯＲにする（ステップＳ１４）。つまり、
aaa|bbb|ccc|ddd
とし、２１パターンを得る。取りえる値が最も大きいパラメータはdddであり、その値の数は２１である。

よって、処理対象の階層の組合せ数は、関係強度１に対してＯＲとした、
aaa|bbb|ccc|ddd | eee&fff&ggg | hhh&iii&jjj
により求められ、つまり、最大値をとるeee&fff&gggが１５０パターンであるから、１５０パターンが組合せ数として決定される。

図２０は、階層間の組合せ回避処理の例を説明するためのフローチャート図である。図２０の階層間の組合せ回避処理では、全階層に対する最大組合せ数を入力し（ステップＳ３１）、階層［ｉ］の変数ｉを初期値「０」に設定する（ステップＳ３２）。

階層［ｉ］までの階層［ｉ］までの最大値の総積を求めて、組合せ数を得る（ステップＳ３３）。組合せ数は、

により得られる。

組合せ数を得た後、取得した組合せ数は、最大組合せ数を超えたか否かを判定する（ステップＳ３４）。最大組合せ数を超えていない場合（ステップＳ３４のＮｏ）、ステップＳ３６へと進む。一方、最大組合せ数を超えた場合（ステップＳ３４のＹｅｓ）、階層［ｉ］に属するテナントの組合せを全てＯＲにし、テナント内の組合せを１つにする（ステップＳ３５）。

そして、全階層を終了したか否かを判定する（ステップＳ３６）。未処理の階層がある場合（ステップＳ３６のＮｏ）、変数ｉを１インクリメントし（ステップＳ３７）、ステップＳ３３へ戻り上述した同様の処理を繰り返す。一方、全階層を終了した場合（ステップＳ３６のＹｅｓ）、この階層間の組合せ回避処理は終了する。

次に、検証手順生成部８０による検証手順生成処理の全体の流れについて説明する。図２１は、検証手順生成処理の全体の流れを説明するためのフローチャート図である。図２１において、検証手順生成部８０は、パターン数の最大値を閾値として読み込み（ステップＳ２０１）、制御データ８１を読み込む（ステップＳ２０２）。

次に、検証手順生成部８０は、パラメータ定義表１１２からパラメータテーブル７１２を作成する（ステップＳ２０３）。パラメータテーブル７１２は、パラメータ名、ビット数、試験値例スト［ｎ］、連動関数名、生成関数名及び回数、関係強度、Const_リスト［ｎ］等の項目を有する。各項目は、パラメータ定義表１１２の項目に対応する。

検証手順生成部８０は、構造定義表１１４からオーナー構造テーブル７１４ａ、７１４ｇ及びテナント構造テーブル７１４ｂ、７１４ｈを作成する（ステップＳ２０４）。
オーナー構造テーブル７１４ａ、７１４ｇは、構造名（オーナー名）、処理階層、トランザクション名、項目［ｎ］等を有し、項目［ｎ］は、項目名、ビット数、レジスタ読書き種別、レジスタ初期値、レジスタ優先度等の要素を有する。更に、レジスタのみの場合、オーナー構造テーブル７１４ｇは、更に、メモリ名、メモリ開始位置等の項目を有する。
テナント構造テーブル７１４ｂ、７１４ｈは、構造名（テナント名）、項目リスト［ｎ］、オーナー名、組合せ数、論理積等の項目を有し、項目リスト［ｎ］は、項目名、ビット数、パラメータフラグ（ＯＮ：項目＝パラメータ）、振る舞い等の要素を有する。
オーナー構造テーブル７１４ａ、７１４ｇ及びテナント構造テーブル７１４ｂ、７１４ｈは、図１２〜図１４に示されるテーブルを、テストベンチ９０で動作可能な形式で記述したテーブルである。項目名、項目数は適宜変更可能である。

また、検証手順生成部８０は、メモリ定義表１１３からメモリテーブル７１３ａを作成する（ステップＳ２０５）。メモリテーブル７１３ａは、メモリ名、開始アドレス、終了アドレス等の項目を有する。

次に、検証手順生成部８０は、論理積作成処理（図２２）を行う（ステップＳ２０６）。論理積作成処理により論理積テーブル７１５が出力される。論理積テーブル７１５は、関係強度、組合せ数、項目リスト［ｎ］等の項目を有し、項目リスト［ｎ］は、パラメータ名、変化数等の要素を有する。

更に、検証手順生成部８０は、検証項目テーブル作成処理（図２３）を行う（ステップＳ２０７）。検証項目テーブル作成処理により検証項目テーブル７１６ａが出力される。検証項目テーブル７１６ａは、検証項目名、パターン数、階層［ｎ］等の項目を有し、階層［ｎ］は、パターン数、テナント名［ｍ］等の要素を有する。検証項目テーブル７１６ａは、検証構成表１１６−１（図１６）と、組合せ詳細表１１６−２（図１７）の内容を含む。

検証手順生成部８０は、検証項目テーブル７１６ａを用いて、検証項目の数だけ繰り返し処理することにより組合せ検証項目表１１６を出力する（ステップＳ２０８）、
組合せ検証項目表１１６が出力されると、検証手順生成部８０は、テストシナリオ生成処理を行う（ステップＳ２０９）。テストシナリオ２が記憶部１３０に出力され、この検証手順生成を終了する。その後、テストベンチ９０によって、自動生成されたテストシナリオ２が読み込まれ、トランザクションＴＲが出力されることで、ＤＵＴ５０の論理検証を行われる。

図２１のフローチャートにおいて、ステップＳ２０１及びＳ２０２の処理はデータ読み込み部に相当し、ステップＳ２０３の処理はパラメータ作成部に相当し、ステップＳ２０４の処理は定義表作成部に相当する。また、ステップＳ２０５の処理は、メモリテーブル作成部による処理に相当する。

上述したフローチャートにおいて、ステップＳ２０６の論理積テーブル作成処理は、論理積テーブル作成部の一例であり、ステップＳ２０７の検証項目テーブル作成処理は、検証項目テーブル作成部の一例である。また、論理積テーブル作成部及び検証項目テーブル作成部は、組合せ検証項目作成部の一例である。ステップＳ２０９のテストシナリオ生成処理は、テストシナリオ生成部の一例である。

図２２は、図２１のステップＳ２０６での論理積テーブル作成処理を説明するためのフローチャート図である。図２２において、論理積テーブル作成処理は、オーナー構造テーブル７１４ａ（又は７１４ｇ）からオーナーを１つ選択し、選択したオーナーのテナント構造テーブル７１４ｂ（又は７１４ｈ）を決定する（ステップＳ２５１）。

決定したテナント構造テーブル７１４ｂ（又は７１４ｈ）から項目を１つ取得し（ステップＳ２５２）、取得した項目がパラメータか否かを判断する（ステップＳ２５３）。パラメータでない場合（ステップＳ２５３のＮｏ）、次の項目をステップＳ２５２へと戻り次の項目を取得し（ステップＳ２５２）、パラメータか否かを判断する（ステップＳ２５３）処理を繰り返す。一方、パラメータの場合（ステップＳ２５３のＹｅｓ）、パラメータテーブル７１２からパラメータの情報を取得する（ステップＳ２５４）。

取得したレコードで示される振る舞いは試験値か否かを判断する（ステップＳ２５５）。振る舞いが試験値の場合（ステップＳ２５５のＹｅｓ）、変化数に試験値数を設定し（ステップＳ２５６）、ステップＳ２６０へと進む。一方、振る舞いが試験値でない場合（ステップＳ２５５のＮｏ）、更に、振る舞いは生成関数か否かを判断する（ステップＳ２５７）。生成関数の場合（ステップＳ２５７のＹｅｓ）、変化数に呼出回数を設定し、ステップＳ２６０へと進む。一方、生成関数でない場合（ステップＳ２５７のＮｏ）、変化数に１を設定し（ステップＳ２５９）、関数強度をキーとした論理積テーブル７１５を作成する（ステップＳ２６０）。

論理積テーブル７１５は、関係強度毎に、組合せ数、項目リスト［ｍ］等の項目を有し、項目リスト［ｍ］は、パラメータ名、変化数等の要素を有する。

作成された論理積テーブル７１５を参照して、関係強度毎の組合せ数を求める（ステップＳ２６１）。関係強度ｎの組合せ数は、

で表されるように、総積により求められる。

組合せパターン数が求まると、組合せ数が最大組合せ数を超えたか否かを判断する（ステップＳ２６２）。最大組合せ数を超えた場合（ステップＳ２６２のＹｅｓ）、組合せ数を１つにする（ステップＳ２６３）。即ち、ＯＲに切り替えて、最大値をとる関係強度を選択する。

一方、最大組合せ数を超えない場合（ステップＳ２６２のＮｏ）、関係強度毎の組合せ数が最大値のテナントの組合せを採用する（ステップＳ２６４）。具体的には、ステップＳ２５１で決定したテナント構造テーブル７１４ｂ（又は７１４ｈ）の組合せ数に最大値を代入し、論理積に論理積テーブル７１５をリンクする。

上述したステップＳ２５１〜２６４の処理は、オーナー構造テーブル７１４ａ（又は７１４ｈ）を参照して、全てのオーナーに対して繰り返される。上述したステップＳ２５１〜Ｓ２６４の処理は、オーナー毎に、関連付けられる全てのテナントに対して繰り返される。上述したステップＳ２５２〜Ｓ２６０の処理は、テナント毎に、全ての項目に対して繰り返される。上述したステップＳ２６１の処理は、全ての関係強度に対して繰り返される。

図２３は、図２１のステップＳ２０７での検証項目テーブル作成処理を説明するためのフローチャート図である。図２３において、上述した関数部のアルゴリズムに従い、使用するテナントを決定するために作業用変数を作成する初期化を行う（ステップＳ２７１）。

具体的には、use[オーナー数]及びmax[オーナー数＋１]の変数を作成する。変数の作成は、例えば、以下のようなプログラミングにより行える。

//オーナー毎のテナント数
int use[オーナー数];
for(ix=0:ix<オーナー数;ix++){→ix:オーナー番号
use[ix]=従属テナント数；
}
//最大桁数を生成
int max[オーナー数+1] ;
max[オーナー数]=1 ;
for(ix=オーナー数-1:ix>=0;ix--) {→ix:オーナー番号
max[ix] = use[ix] * max[ix+1] ；
}
トータル検証項目数は、max[0]となる。

次に、図１８で説明したように、検証項目番号（項目番号）からテナント番号を決定する（ステップＳ２７２）。具体的には、
//テナント番号の決定
int no = トータル検証項目数-項目番号 -1 ;
int テナント番号配列[オーナー数] ;//←オーナー毎のテナント番号
for(kx=0:kx<オーナー数;kx++) {//kx: オーナー番号
テナント番号配列[kx] = (use[kx]-1)-(no %max[kx]) /max[kx+1] ;
}
このようなプログラミングによりテナント番号を取得することができる。

次に、テスト名を作成する（ステップＳ２７３）。ここでは、TEST_項目番号の所定の形式でテスト名を生成し、検証項目テーブル７１６ａの検証項目名に設定する。検証項目毎に、オーナーを決定し、オーナー毎にテナントを決定する。決定した情報は、検証項目テーブル７１６ａに設定される。

まず、階層の一致に基づき、オーナーを特定し、オーナー番号を決定する（ステップＳ２７４）。そして、階層ｎ構造名を出力し、オーナー番号からテナント番号を取得する（ステップＳ２７５）。対応付けリスト１１５ａ（図１５）を参照することで、オーナー番号からテナント番号を取得できる。

次に、取得したテナント番号に対応するテナント構造テーブル７１４ｂ（又は７１４ｈ）からテナント名を取得し、検証項目テーブル７１６ａに設定する（ステップＳ２７６）。更に、テナント構造テーブル７１４ｂ（又は７１４ｈ）を参照して、組合せ数の最大値を取得する（ステップＳ２７７）。組合せ数の最大値は、ループにより更新され、全てのオーナーにおいて最大値ｔなる組合せ数が特定される。

その後、階層毎の組合せの最大値（ＭＡＸ）を、検証項目テーブル７１６ａの該当する階層のパターン数に設定する（ステップＳ２７８）。全ての階層に対して、最大値が設定されると、階層毎のパターン数の最大値を総積することで、検証項目の総数を得る（ステップＳ２７９）。検証項目の総数は、

により得られる。そして、検証項目テーブル作成処理が終了する。設定値が与えられた検証項目テーブル７１６ａと、検証項目総数とに基づいて、組合せ検証項目表１１６が作成される。

従来では、図３で説明した内容を開発者による人手の作業によって行われていたのに対して、上述したように、本実施例では、起動待ち、時間調整等も含めてパラメータ化することで、テストシナリオ２を定型化でき、組合せ検証項目表１１６の自動生成を可能とする。以下に、３階層を例として、テストシナリオを自動生成する処理例について説明する。

図２４は、図２１のステップＳ２０９でのテストシナリオ生成処理の実行例を説明するためのフローチャート図である。図２４において、パターン数の最大値、制御データ８１の読み込み等の初期化後（ステップＳ３１０）、階層０の最大組合せループ（ｉｘ）が実行される。

このループ（ｉｘ）内では、fork〜joinによって、トランザクション生成タスク１−０（ｉｘ、テナント種別）からトランザクション生成タスク１−ｎ（ｉｘ、テナント種別）までをマルチタスク動作で行う（ステップＳ３２０）。

そして、ループ（ｉｘ）内において、階層１の最大組合せ数のループ（ｊｘ）が実行され、このループ（ｊｘ）内において、fork〜joinによって、トランザクション生成タスク２−０（ｊｘ、テナント種別）からトランザクション生成タスク２−ｎ（ｊｘ、テナント種別）までをマルチタスク動作で行う（ステップＳ３３０）。

ループ（ｊｘ）内において、階層２の最大組合せ数のループ（ｋｘ）が実行され、このループ（ｋｘ）内において、fork〜joinによって、トランザクション生成タスク３−０（ｋｘ、テナント種別）からトランザクション生成タスク３−ｎ（ｋｘ、テナント種別）までをマルチタスク動作で行う（ステップＳ３４０）。

よって、ループ（ｉｘ）の終了により、３階層による組合せ検証項目表１１６が出力される。

次に、本実施例において生成されたテストベンチ９０の構造とデータの流れについて説明する。図２５は、生成されたテストベンチの構造とデータの流れを説明するための図である。図２５において、テストベンチ９０の全体をテストｎテーブル４０で表している。テストｎテーブル４０は、必要なデータと、動作を定義したクラスに相当し、パラメータテーブル４１１と、シナリオメソッド４３と、その他サービス関数・タスク４５とを定義している。

パラメータテーブル４１１は、全パラメータの値を表で管理し、指定の値を取得するパラメータ値取得関数（配列番号、取得種別）を有している。また、パラメータテーブル４１１では、オーナー毎にテーブルを有する。一例として、オーナーＮテーブル４１２は、共用体インスタンスに相当し、オーナー毎のオーナー構造体を有し、各オーナーに属するテナントはそれぞれのテナント構造体により表される。テナント構造体では、テナントが使用するパラメータの値が、パラメータテーブル４１１に基づいて設定されている。レジスタの場合は、レジスタの初期値、書き込み種別、優先度、リセット情報等が設定されている。

また、オーナーＮテーブル４１２は、論理積テーブル４１３へのリンクと、指定されたテナントの項目値を取得するテナント項目値取得関数（）とを有している。

論理積テーブル４１３は、テナント内のパラメータの組み合わせを求める計算部分を含んでいる。シナリオメソッド４３から与えられるループ番号から配列番号へと変換する変換関数が含まれる。

シナリオメソッド４３は、forkからjoinまでを階層０の最大数まで繰り返す。forkからjoinでは、並列動作タスクにより、トランザクション毎の処理が行われる。トランザクションｎを一例とした場合、階層ｘの最大数まで、以下の処理が繰り返される。オーナー毎の処理（ステップＳ５１）が行われるが、一例として、オーナーｍの処理で説明する。

オーナーｍに対して、パラメータ値の取り出しが行われる（ステップＳ５１ａ）。論理積テーブル４１３に、ループ番号（繰り返し回数）で問い合わせることで配列番号へと変換し、得られた配列番号を用いて、パラメータテーブル４１１に問い合わせることで、パラメータ値を取得できる。

次に、シナリオメソッド４３は、テナントの項目を代入する（ステップＳ５１ｂ）。オーナーを指定してテナント項目値取得関数を呼び出すことで、共用体インスタンスの各テナントに各項目の値が設定される。他のオーナーｍ+１についても同様の処理を行う。

全てのオーナーについてステップＳ５１と同様の処理が完了すると、シナリオメソッド４３は、トランザクションＴＲを生成する（ステップＳ５２）。レジスタ以外では、直接送信可能なトランザクションＴＲとして作成され、レジスタの場合、レジスタ領域テーブル５５０にトランザクションＴＲが記録されたのち、送信可能なトランザクションＴＲとなる。

レジスタ領域テーブル５５０は、記憶部１３０の共通領域に展開されるテーブルであり、レジスタ情報クローンを記憶する。ＤＵＴ５０内のレジスタ値のクローンを記憶部１３０の共通領域に保持することで、テストベンチ９０内からいつでもレジスタ値の参照が可能となる。

レジスタ領域テーブル５５０は、レジスタ書き込みリスト生成関数、レジスタ値取得関数、レジスタ値登録関数、その他サービス関数等を有する。レジスタ書き込みリスト生成関数は、レジスタに対応する変数に変化があった場合に書き込み対象とし、また、変数の順番もランダム化することでバリエーションを増やす。レジスタ値取得関数は、テストベンチ個別動作部９０−１からの呼び出し（ＣＡＬＬ）に応じて、テストベンチ個別動作部９０−１へレジスタ値を渡す。

レジスタ値登録関数は、テストベンチ個別動作部９０−１からの呼び出し（ＣＡＬＬ）に応じて、レジスタ値を登録する。テストベンチ個別動作部９０−１は、レジスタ領域テーブル５５０がレジスタ値のクローンを保持することから、値を読み出した場合には、必ずレジスタ値登録関数を呼び出して同期をとる。

再実行抑止テーブル５６０は、記憶部１３０の共通領域に展開され、同一のトランザクションＴＲが再実行されないように制御する。再実行抑止テーブル５６０は、実行変数登録・実行可否判断関数により、トランザクションＴＲが記録され、既に実行済みのトランザクションＴＲを送信しない制御が可能となる。

送信可能なトランザクションＴＲは、再実行抑止テーブル５６０に記録されたのち、ドライバー５に送信される（ステップＳ５３）。具体的には、トランザクション毎通信領域５７０にトランザクションＴＲが格納されたのち、トライバー５によって受信される。

トランザクション毎通信領域５７０は、トランザクション構造テーブル５７１と、レジスタテーブル５７２とを有する。トランザクション構造テーブル５７１は、各項目を宣言した共用体であるとともに、サービス関数を有する。レジスタテーブル５７２は、アドレス及びデータ領域［］を有するとともに、サービス関数を有する。レジスタテーブル５７２は、レジスタの場合、アドレスとデータのリストのテーブルになる。

ステップＳ５１〜Ｓ５３の処理は、階層ｘの最大数まで繰り返される。他のトランザクションにおいても同様の処理が行われる。

図２６は、図２５のステップＳ５１でのオーナー毎の処理を説明するためのフローチャート図である。図２６において、オーナー毎の処理では、検証番号によって使用するテナントを決定し、決定したテナントのパラメータを取得する（ステップＳ５１１）。

取得したパラメータは試験値か否かを判定する（ステップＳ５１２）。パラメータが試験値の場合（ステップＳ５１２のＹｅｓ）、上述したアルゴリズムに従って、ループ番号により選択されたパラメータの配列番号を決定し（ステップＳ５１３）、パラメータテーブル４１１からパラメータ値を取得する（ステップＳ５１４）。そして、テナント構造体に値を代入し（ステップＳ５１８）、このオーナー毎の処理を終了する。

一方、パラメータが試験値でない場合（ステップＳ５１２のＮｏ）、ユーザ関数を含む生成関数か否かを判断する（ステップＳ５１５）。生成関数の場合（ステップＳ５１５のＹｅｓ）、当該関数を実行し（ステップＳ５１６）、テナント構造体に値を代入し（ステップＳ５１８）、このオーナー毎の処理を終了する。生成関数でない場合（ステップＳ５１５のＮｏ）、典型値を設定し（ステップＳ５１７）、テナント構造体に値を代入し（ステップＳ５１８）、このオーナー毎の処理を終了する。

図２７は、図２５のステップＳ５２でのトランザクションの生成処理を説明するためのフローチャート図である。図２６において、トランザクションＴＲの生成処理では、オーナーの領域を記憶部１３０に確保し（ステップＳ５２１）、対象のテナントに取得値を設定する（ステップＳ５２２）。

そして、オーナーはレジスタか否かを判定する（ステップＳ５２３）。レジスタでない場合（ステップＳ５２３のＮｏ）、オーナーの領域をトランザクションＴＲにし（ステップＳ５２４）、このトランザクションの生成処理は終了する。

一方、レジスタの場合（ステップＳ５２３のＹｅｓ）、クローン［アドレス］値とオーナー［アドレス］値とは同じ値か否かを判断する（ステップＳ５２５）。同じ値の場合、全てのオーナーのアドレスについて比較終了したか否かを判定する（ステップＳ５２５−２）。比較終了していないアドレスがある場合（ステップＳ５２５−２のＮｏ）、そのアドレスを選択して、ステップＳ２５２を繰り返す。一方、全て終了している場合（ステップＳ５２５−２のＹｅｓ）、ステップＳ５２７へと進む。

クローン［アドレス］値とオーナー［アドレス］値とが同じ値でない場合（ステップＳ５２５のＮｏ）、レジスタ領域テーブル５５０のレジスタ書き込みリスト生成関数を呼び出して、書込みリストにアドレスと値とを追加する（ステップＳ５２６）。

その後、オーナー構造テーブル７１４ｇを参照して、書込みリスト内のレジスタを優先度順に並び替える（ステップＳ５２７）。同一優先度のレジスタはランダムに並び替える（ステップＳ５２８）。そして、書込みリストをトランザクションＴＲにして（ステップＳ５２９）、このトランザクションの生成処理は終了する。

図２８は、図２５のステップＳ５３でのトランザクションの送信処理を説明するためのフローチャート図である。図２８において、トランザクションＴＲの送信処理では、再実行抑止領域の初期化処理を行い（ステップＳ５４０）、トランザクションＴＲの重複制御による送信処理を行い（ステップＳ５５０）、送信終了処理を行って（ステップＳ５６０）、このトランザクションＴＲの送信処理は終了する。

ステップＳ５４０の初期化処理では、再実行抑止領域を記憶部１３０に作成し、初期化する。パラメータの値の数の論理積（＆）の最大ビット数を取得し、管理する変数分の再実行抑止領域を作成する。最大ビット数は、
(A&B)|(C&D)|(E&F&G)
等のように、関係強度が同じパラメータの値の種類の数をandし、関係強度が異なるパラメータ間ではorをとる論理式により得られる。よって、論理和(|)の数だけ変数が作成される。

ビット位置が対応する変数の値の実行ビットとなる。一例として、
PARA1の値が３種（値１１、値１２、値１３）
PARA2の値が２種（値２１、値２２）
PARA3の値が２種（値３１、値３２）
であるならば、３×２×２＝１２ビットで表現することになる。

再実行抑止領域を読み込み、論理式が同じテストのものが存在したら、フラグを設定する。最大ビット数領域（PARA1&PARA2&PARA3）に対応付けて、複数のパラメータの複数の値の組み合わせが表現される。一例として、
PARA1の値１１には［０］を割り当て、値１２には［１］を割り当て、値１３には［２］を割り当て、
PARA2の値２１には［０］を割り当て、値２２には［１］を割り当て、
PARA3の値３１には［０］を割り当て、値３２には［１］を割り当てる。

そして、「００」ビット位置から「１１」ビット位置の最大ビット数領域（PARA1&PARA2&PARA3）に対して、
PARA1：００００１１１１２２２２
PARA2：００１１００１１００１１
PARA3：０１０１０１０１０１０１
のように割り当てられた値を対応付ける。同一ビット位置の値で組合せるパラメータ値を示す。組合せるパラメータ値を示す領域を組合せ領域６０２という。また、上述したパラメータPARA1、PARA2、及びPARA3に対する最大ビット数領域（PARA1&PARA2&PARA3）の実行ビット領域６０１が設けられる。したがって、再実行抑止領域６００には、実行ビット領域６０１と、組合せ領域６０２とが含まれる。そして、ステップＳ５４０の初期化処理は終了する。

ステップＳ５５０の送信処理では、トランザクションＴＲの値を登録し（ステップＳ５５１）、設定された値からビット位置を特定する（ステップＳ５５２）。つまり、例えば、
PARA1の設定値が値１２ならば［１］
PARA2の設定値が値２２ならば［１］
PARA3の設定値が値３１ならば［０］
従って、最大ビット数領域において、（PARA1、PARA2、PARA3）が（１、１、０）を示すビット位置を特定すればよい。

そして、設定値の組合せがあったか否かを判断する（ステップＳ５５３）。即ち、ビット位置が特定できたか否かを判断するればよい。設定値の組合せが存在しない場合は、関数生成値やランダム値が、パラメータのいずれの値（図１７）とも一致しないことを示すため、フラグ設定の対象外とする制御を行う。

設定値の組合せが無かった場合（ステップＳ５５３のＮｏ）、トランザクションＴＲの送信を行わずに、この送信処理を終了する。一方、設定値の組合せが有った場合（ステップＳ５５３のＹｅｓ）、実行ビット領域６０１を参照して、組合せの実行ビットはＯＮか否かを判断する（ステップＳ５５４）。即ち、実行可否判断関数を呼び出すことで、再実行抑止領域６００の実行ビット領域６０１における、設定値の組合せに対応する実行ビットの状態を取得すればよい。組合せの実行ビットがＯＮの場合（ステップＳ５５４のＹｅｓ）、既にトランザクションＴＲは実行済みであるため送信せずに、この送信処理を終了する。

一方、組合せの実行ビットがＯＮでない場合（ステップＳ５５４のＮｏ）、組合せの実行ビットをＯＮにして（ステップＳ５５５）、トランザクションＴＲを送信し（ステップＳ５５６）、この送信処理を終了する。

ステップＳ５６０の送信終了処理では、全てのトランザクションＴＲの生成に係る論理式と、再実行抑止領域６００とを記憶部１３０に格納する。検証項目単位で記憶される。

上述したフローチャートにおいて、ステップＳ５４０の初期化処理は、初期化処理部の一例であり、ステップＳ５５０の送信処理は、送信処理部の一例であり、ステップＳ５６０の送信終了処理は、送信終了処理部の一例である。

上述したように、本実施例では、ＤＵＴ５０の検証時の実行手順（フェーズ）を階層化し、各フェーズの動作内容をパラメータ化することで、検証項目の作成を含めて、テストシナリオ２を全て自動生成可能とする。検証項目は重複無く作成されるため、無駄なテストシナリオ２が生成されない効果がある。

また、パラメータの値の種類の数と、組み合わせるパラメータ数とに基づいて、トランザクションの各パラメータとそのパラメータ値（試験値）の組合せ方を選択するため、組合せ数の膨大化を制御できる。

論理積テーブル作成処理を行う論理積テーブル作成部は設定部に相当し、検証項目テーブル作成処理を行う検証項目テーブル作成部は作成部に相当する。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、主々の変形や変更が可能である。

以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、
特定した組み合わせ数に基づいて各パラメータの値を設定し、
論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成し、
前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成する、
処理をコンピュータに実行させる検証手順生成プログラム。
（付記２）
前記論理検証の前記動作手順を階層化し、前記テストシナリオは、階層毎に、１以上のトランザクションを有し、複数のパラメータで該トランザクションの形式データを定義する１以上のテナントが対応付けられ、該テナント毎に、関係のあるパラメータ同士を分類し、分類に基づいて値の組合せ数を取得し、
各分類の前記組合せ数の総積又は複数の該分類の中の最大の組合せ数のいずれかを採用することで、各テナントにおける組合せ数を制限して前記パラメータの値を決定する
ことを特徴とする付記１又は２記載の検証手順生成プログラム。
（付記３）
前記階層毎に組合せ数の最大値を取得し、全階層を対象として取得した前記最大値に基づいて前記検証項目の総数を決定し、
前記階層化に従って、前記トランザクション毎に、前記組合せ数の最大値の制限により決定される各テナントの前記パラメータの値の組合せを用いて、前記総数の前記検証項目を作成する
ことを特徴とする付記２記載の検証手順生成プログラム。
（付記４）
前記トランザクションは、複数の前記テナントによって領域データを表すオーナーを１つ以上含むことを特徴とする付記３記載の検証手順生成プログラム。
（付記５）
前記複数のパラメータは、起動待ちと時間調整の１つ以上のパラメータを含むことを特徴とする付記１乃至４のいずれか一項記載の検証手順生成プログラム。
（付記６）
前記制御データから、パラメータの定義情報を示すパラメータテーブルと、前記オーナーの定義情報を示すオーナー構造テーブルと、メモリの定義情報を示すメモリ定義表とを生成する
処理を前記コンピュータに行わせる付記１乃至５のいずれか一項記載の検証手順生成プログラム。
（付記７）
付記１乃至５のいずれか一項記載の前記階層毎に決定した前記パラメータの値の組合せを用いて、前記トランザクションを生成し、
前記パラメータの値の組合せに対応付けられた送信状態を示すピット値が未送信を示す場合に前記トランザクションを送信し、送信済みを示す場合は該トランザクションの送信を抑止する
処理をコンピュータに実行させるテストベンチプログラム。
（付記８）
記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、
特定した組み合わせ数に基づいて各パラメータの値を設定し、
論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成し、
前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成する、
処理をコンピュータが実行する検証手順生成方法。
（付記９）
記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、特定した組み合わせ数に基づいて各パラメータの値を設定する設定部と、
論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成する作成部と、
前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成するテストシナリオ生成部と、
を有する検証手順生成装置。

１検証項目表
２テストシナリオ
５ドライバー
６モニタ
７疑似モデル
８期待値比較部
９ダンプデータ
３２機能仕様書
８０検証手順生成部
８１制御データ
９０−１テストベンチ個別動作部
９０テストベンチ
１００検証手順生成装置
１１２パラメータ定義書
１１３メモリ定義書
１１４構造定義
１１６組合せ検証項目表
１１７テストベンチ部品
ＴＲトランザクション

Claims

記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、
特定した組み合わせ数に基づいて各パラメータの値を設定し、
論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成し、
前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成する、
処理をコンピュータに実行させる検証手順生成プログラム。
前記論理検証の前記動作手順を階層化し、前記テストシナリオは、階層毎に、１以上のトランザクションを有し、複数のパラメータで該トランザクションの形式データを定義する１以上のテナントが対応付けられ、該テナント毎に、関係のあるパラメータ同士を分類し、分類に基づいて値の組合せ数を取得し、
各分類の前記組合せ数の総積又は複数の該分類の中の最大の組合せ数のいずれかを採用することで、各テナントにおける組合せ数を制限して前記パラメータの値を決定する
ことを特徴とする請求項１記載の検証手順生成プログラム。
前記階層毎に組合せ数の最大値を取得し、全階層を対象として取得した前記最大値に基づいて前記検証項目の総数を決定し、
前記階層化に従って、前記トランザクション毎に、前記組合せ数の最大値の制限により決定される各テナントの前記パラメータの値の組合せを用いて、前記総数の前記検証項目を作成する
ことを特徴とする請求項２記載の検証手順生成プログラム。
前記トランザクションは、複数の前記テナントによって領域データを表すオーナーを１つ以上含むことを特徴とする請求項３記載の検証手順生成プログラム。
記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、
特定した組み合わせ数に基づいて各パラメータの値を設定し、
論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成し、
前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成する、
処理をコンピュータが実行する検証手順生成方法。
記憶部に記憶された制御データによって定義される検証対象の動作情報をパラメータとして定義し、定義した該パラメータにおいて、関係する複数のパラメータ毎に、取り得る値の組合せ数を特定し、特定した組み合わせ数に基づいて各パラメータの値を設定する設定部と、
論理検証の動作手順の単位で複数のパラメータの値が組み合わされた検証項目を示す組合せ検証項目表を作成する作成部と、
前記組合せ検証項目表を参照して、前記検証項目ごとに、前記動作手順ごとのパラメータの値の組合せを用いて前記検証対象をテストするテストシナリオを生成するテストシナリオ生成部と、
を有する検証手順生成装置。