JP2008204100A - 論理検証方法及び検証装置 - Google Patents

Abstract

【課題】 十分な検証精度を得るために、実用的な時間で、機能の組み合わせの依存関係を解析し、機能を分類する。
【解決手段】 検証対象の機能の特徴を表す属性に基づいてその機能の依存関係を解析し、依存関係の有無により機能を分類する。そして依存関係の有る機能間にクロスファンクションカバレッジの取得を設定し、依存関係の無い機能のテストは並行して実行するようにテスト実行手順を作成する。
【選択図】 図９

Description

本発明は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせからなる検証対象の論理システムを検証する技術に関する。

ＬＳＩを含む論理システムの規模や論理システムが有する機能は年毎に増加している。これに伴い、論理システムの検証にかかる工数も増加している。一方、市場には消費者が欲するときに製品を投入しなければならず、ＬＳＩを始めとした論理システムの開発期間は短くなっている。そこで、論理システムの検証効率を向上させる必要が生じている。

また、論理システムの検証において、論理システムが持つ個々の機能を単独で検証するだけでなく、機能の組み合わせも検証しなければいけない。これは、依存関係のある機能間では、組み合わせにより初めて出現する事象が存在するからである。

現在、論理システムの検証には、シミュレータを使用した動的検証を用いることが多い。この動的検証において、検証作業を管理するために、ファンクションカバレッジを取得する。ここで、ファンクションカバレッジは、事象が出現した回数が閾値に占める割合である。

事象が出現する条件と閾値とを予め設定しておき、動的検証実行時に事象の出現条件が成立する回数を計測する。そして、事象が出現する条件に、複数の機能に関係する条件を含めれば、機能の組み合わせについてファンクションカバレッジを取得することが可能である。

ファンクションカバレッジが１００％以上ならば、その事象の検証を実施したと判断する。予め出現条件を設定した事象全てについて、ファンクションカバレッジが１００％を超えたならば、検証完了とする。このファンクションカバレッジの取得は、市販の検証用ツール、例えばCadence社のSpecman-eliteで可能である。

尚、ファンクションカバレッジを設定していない事象は、検証を実施したか否かの判断ができないため、検証未実施になる可能性がある。反対に、依存関係のない組み合わせにファンクションカバレッジを設定すると、検証が終了しない恐れがある。

即ち、検証作業の管理にファンクションカバレッジを用いる場合、検証精度と検証効率はファンクションカバレッジ取得の品質に左右される。従って、依存関係を抽出する精度や調査の範囲が重要である。

依存関係を抽出する精度や調査の範囲が重要であることを、ａ，ｂ，ｃの３機能を持つ論理システムを例に説明する。ここで、活性化している機能を｛｝で囲って表す。即ち、｛ａ｝は機能ａが活性化していること示している。そして、｛ａｂ｝は機能ａと機能ｂが活性化することを示している。このとき、機能ａと機能ｂが活性化する順番は問わない。機能ａが活性化してから機能ｂが活性化しても、機能ｂが活性化してから機能ａが活性化しても良い。更に、機能ａと機能ｂが同時に活性化しても良い。ただし、機能ａ及び機能ｂ以外の機能、即ち機能ｃが活性化してはならない。また｛φ｝はａ，ｂ，ｃの何れの機能も活性化していない状態を示している。

この論理システムが取りうる機能の組み合わせは、｛φ｝，｛ａ｝，｛ｂ｝，｛ｃ｝，｛ａｂ｝，｛ｂｃ｝，｛ａｃ｝，｛ａｂｃ｝の８通りになる。この８通り全てについて、検証を実施することが必要である。

しかし、上記８通りの組み合わせを検証したのみでは、十分ではない。例えば、以下の二つの事象を考える。
１）機能ａが活性化し、機能ａ，ｂ，ｃが活性化（｛ａ｝，｛ａ，ｂ，ｃ｝）
２）機能ｂが活性化し機能ａ，ｂ，ｃが活性化（｛ｂ｝，｛ａ，ｂ，ｃ｝）
ここで、｛ａ｝と｛ａ，ｂ，ｃ｝の間に依存関係が存在するが、｛ｂ｝と｛ａ，ｂ，ｃ｝の間には依存関係が存在しないとする。この場合、論理システムの状態と出力値とが、上記１）と２）で異なる可能性がある。従って、上記１）と２）の双方の検証を実施しなければならない。一方、｛ａ｝、｛ｂ｝、及び｛ａ，ｂ，ｃ｝間に依存関係が存在しないならば、｛ａ｝、｛ｂ｝、｛ａ，ｂ，ｃ｝をそれぞれ独立して検証して良い。

即ち、必要かつ十分な検証精度を得るには、機能の組み合わせの依存関係まで考慮して検証を実施しなければならない。そして、機能の組み合わせの依存関係を抽出するためには、機能の組み合わせの組み合わせ全てについて依存関係を調査しなければならない。

しかし、機能の数が多くなると、機能の組み合わせの組み合わせ数は莫大な数になる。例えば、機能の数が３、５、１０の場合を考える。それぞれの場合について、機能の組み合わせ数と機能の組み合わせの組み合わせ数は以下のようになる。
１）機能数が３
機能の組み合わせ数 （２³ ＝８）通り
機能の組み合わせの組み合わせ数（２⁸ ＝２５６）通り
２）機能数が５
機能の組み合わせ数 （２⁵ ＝３２）通り
機能の組み合わせの組み合わせ数（２³²＝４２９４９６７２９６）通り
３）機能数が１０
機能の組み合わせ数 （２¹⁰＝１０２４）通り
機能の組み合わせの組み合わせ数（２¹⁰²⁴＝１．７９Ｅ３０８）通り。
Y.Matsunaga,"An exact and efficient algorithm for disjunctive decomposition," In Proc. of SASIMI-98,pp.44-50,1998. 湊、「ゼロサプレス型ＢＤＤに基づく組合せ集合の単直交分解の抽出」、ＤＡシンポジウム２００５論文集、ｐｐ１７５−１８０、２００５年

従来、検証担当者が論理システムの仕様に基づき依存関係を抽出している。一方、論理システムが有する機能の数は年毎に増加しており、多くの論理システムで機能の数が１０を超えている。

従って、多くの論理システムにおいては、機能の組み合わせ間の依存関係のみならず、機能間の依存関係ですら、従来の手法で全て抽出することは事実上不可能である。

全ての依存関係を抽出できなければ、存在する依存関係を見落とす可能性や存在しない依存関係を抽出する可能性が否定できない。これは、ファンクションカバレッジの取得の品質を低下させる原因になる。

従って、十分な検証精度が得られない、或いは検証に時間がかかることにより、十分な精度を持つ論理システムを予定の期間内に完成させることができず、市場が欲するときに製品を投入できない。また、不十分な精度のまま製品を市場に投入してしまう。

本発明は、上記課題を解決するためになされたものであり、十分な検証精度を得るために、実用的な時間で、機能の組み合わせの依存関係を解析し、機能を分類することを目的とする。

本発明は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせからなる検証対象の論理システムを検証するための論理検証装置にて実行される論理検証方法であって、前記検証対象の複数の機能を分類する分類工程と、前記分類された機能に基づいて検証実行手順を作成する作成工程とを有することを特徴とする。

また、本発明は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせからなる検証対象の論理システムを検証するための論理検証装置であって、前記検証対象の複数の機能を分類する分類手段と、前記分類された機能に基づいて検証実行手順を作成する作成手段とを有することを特徴とする。

本発明によれば、ハードウェア、ソフトウェア、或いはハードウェアとソフトウェアの組み合わせからなる論理システムが有する機能の組み合わせの依存関係を実用的な時間で全て抽出することが可能となる。その結果、機能の組み合わせの依存関係まで考慮して、ファンクションカバレッジを取得し、検証を実施することが可能となる。

また、機能の依存関係を考慮した検証順の設定が容易になる。従って、検証精度と検証効率を向上させることが可能となる。

従って、十分な精度を持つ論理システムを予定の期間内に完成させることができ、市場が欲するときに製品を投入することが可能となる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。

［第１の実施形態］
第１の実施形態では、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせからなる検証対象を論理検証する際に、機能の組み合わせの依存関係により機能を分類する方法を説明する。

図１は、第１の実施形態における機能の依存関係を解析する解析方法を説明するための図である。図１において、１１は機能属性、１２は機能分類結果、２１は依存関係解析器である。依存関係解析器２１は、機能属性１１に基づいて機能の依存関係を解析し、その解析結果を機能分類結果１２として出力する。

ここで機能の依存関係を解析する依存関係解析器２１の解析処理を説明する前に、まず機能属性１１について図２及び図３を用いて説明する。

機能属性１１は検証対象の持つ機能の特徴を表す項目である。機能の特徴を表す項目の例として、バスライトやバスリードといった動作の種類やデータ長などがある。しかし、ここでは複数の項目の中から値が一意に定まる特徴の項目を機能属性１１とする。また、機能属性１１の数に制約はないが、できるだけ多いほうが望ましい。

図２は、検証対象であるモジュールの構成の一例を示す図である。図２に示すように、モジュール３１はバスＡ３２とバスＢ３３の二系統のバスを持つ。バスＡ３２には、バスマスタａ３４とバススレーブｂ３５の各ブロックが接続されている。一方、バスＢ３３には、バスマスタｃ３７とバススレーブｄ３８の各ブロックが接続されている。更に、バスＡ３２とバスＢ３３はバスブリッジ３６で相互に接続されている。

バスＡ３２に接続するバスマスタａ３４とバススレーブｂ３５は、バスＡ３２を介してデータの書き込み（ｗｒｉｔｅ）動作と読み込み（ｒｅａｄ）動作とが可能である。また同様に、バスＢ３３に接続するバスマスタｃ３７とバススレーブｄ３８も、バスＢ３３を介してｗｒｉｔｅ動作とｒｅａｄ動作とが可能である。

また、バスマスタａ３４とバススレーブｄ３８或いはバスマスタｃ３７とバススレーブｂ３５は、それぞれバスブリッジ３６を介してｗｒｉｔｅ動作とｒｅａｄ動作とが可能である。

バススレーブｂ３５が持つアドレス空間を０ｘ００００〜０ｘ３ｆｆｆとする。ここで「０ｘ」は１６進数を表している。即ち、バスマスタａ３４はアドレス値を０ｘ００００〜０ｘ３ｆｆｆにして、ｒｅａｄ動作を実行すればバススレーブｂ３５からデータを読み出し、ｗｒｉｔｅ動作を実行すればバススレーブｂ３５にデータを書き込む。

一方、バスマスタｃ３７がアドレス値を０ｘ００００〜０ｘ３ｆｆｆにして、ｒｅａｄ動作を実行すれば、バスブリッジ３６を介してバススレーブｂ３５からデータを読み出す。そして、バスマスタｃ３７がアドレス値を０ｘ００００〜０ｘ３ｆｆｆにして、ｗｒｉｔｅ動作を実行すれば、バスブリッジ３６を介してバススレーブｂ３５にデータを書き込む。

図３は、図２に示すモジュール３１が持つ機能の一覧を示す図である。図３に示すように、機能一覧４１に記載の機能は、モジュール３１が持つ複数の機能のうちｒｅａｄ動作とｗｒｉｔｅ動作の一部である。そして、機能一覧４１に記載の項目がモジュール３１が持つ機能の機能属性１１である。

図３において、機能名４２は、モジュール３１が持つ機能の名称である。動作４３は、ｒｅａｄ動作かｗｒｉｔｅ動作の何れであるかを示している。転送元４４及び転送先４５は、それぞれデータの転送元のブロック名、データの転送先のブロック名を示している。使用バス４６は、データ転送に使用するバスを示している。この使用バス４６において、値「Ｄ」は、バスブリッジ３６を介してバスＡ３２とバスＢ３３の両方を使用することを表すものとする。この機能一覧４１において、機能ｒ＿ＭａＳｂの機能属性１１の値は、以下のようになっている。

機能名４２ ｒ＿ＭａＳｂ
動作４３ ｒｅａｄ
転送元４４ スレーブｂ
転送先４５ マスタａ
使用バス４６ Ａ
即ち、この機能ｒ＿ＭａＳｂは、バスマスタａ３４がバススレーブｂ３５からデータを、バスＡ３２を使用して読み込む（ｒｅａｄ）動作である。同様に、機能ｗ＿ＭｃＳｂの機能属性１１の値は、以下の通りである。

機能名４２ ｗ＿ＭｃＳｂ
動作４３ ｗｒｉｔｅ
転送元４４ マスタｃ
転送先４５ スレーブｂ
使用バス４６ Ｄ
即ち、この機能ｗ＿ＭｃＳｂは、バスマスタｃ３７がバスブリッジ３６を介してバスＡ３２に接続するバススレーブｂ３５にデータを書き込む（ｗｒｉｔｅ）動作である。

次に、機能の依存関係を解析する依存関係解析器２１の処理を説明する。依存関係解析器２１は、機能属性１１に基づき機能の組み合わせ間の依存関係を求め、グループ分けを行う。そして、グループ分けした結果を機能分類結果１２として出力する。

ここで、依存関係解析器２１が行うグループ分けを説明する。機能属性１１に基づいて機能や機能の組み合わせの依存関係を求める。尚、機能の組み合わせ間の依存関係を抽出するためには、機能の組み合わせの組み合わせを調査する必要がある。しかし、既に説明したように、機能の組み合わせの組み合わせは数が多い。そこで、第１の実施形態では、抽出範囲を機能の依存関係に限定し、グループ分けを行う場合を詳細に説明する。

機能の例として、機能一覧４１に示す機能のうち、ｒ＿ＭａＳｂ、ｗ＿ＭａＳｂ、ｒ＿ＭｃＳｄ、ｗ＿ＭｃＳｄを用いる。まず、機能属性１１に基づき、互いに依存関係の有る機能を同じグループに、依存関係の無い機能を別のグループに分類する。

グループＡ：｛ｒ＿ＭａＳｂ｝、｛ｒ＿ＭｃＳｄ｝
グループＢ：｛ｗ＿ＭａＳｂ｝、｛ｗ＿ＭｃＳｄ｝
グループＡはｒｅａｄ動作のグループであり、グループＢはｗｒｉｔｅ動作のグループである。即ち、動作４３が同じ値を持つ機能名４２を同じグループに分類し、動作４３が異なる値を持つ機能名４２を別のグループに分類する。また、この４機能は以下のようにも分類できる。

グループＣ：｛ｒ＿ＭａＳｂ｝、｛ｗ＿ＭａＳｂ｝
グループＤ：｛ｒ＿ＭｃＳｄ｝、｛ｗ＿ＭｃＳｄ｝
グループＣはバスＡ３２のみを使用するグループであり、グループＤはバスＢ３３のみを使用するグループである。即ち、使用バス４６の値で分類する。

図４又は図５は、機能をグループ分けした状態を示す図である。図４は、グループＡとグループＢに分けた場合を示す図である。集合Ｓｄ（ａ）がグループＡ、集合Ｓｄ（ｂ）がグループＢである。また同様に、図５は、グループＣとグループＤに分けた場合を示す図である。集合Ｓｄ（ｃ）がグループＣ、集合Ｓｄ（ｄ）がグループＤである。

即ち、依存関係解析器２１の処理は、機能の組み合わせを要素とする集合Ｓを、互いに要素を共有しない集合Ｓｄに分解する処理であると言える。

尚、上述の集合Ｓを、要素を共有しない集合に分解する方法として、特性関数とＢＤＤ（Binary Decision Diagrams：二分決定グラフ）を使用することができる。即ち、集合を特性関数に対応付け、その特性関数をＢＤＤで非明示的に表現する。このＢＤＤを操作し、特性関数を互いに変数を共有しない部分関数に分解する。分解の結果得られた部分関数が表す集合が求める集合である。

特性関数は、集合に対応付けた１つの論理関数である。例えば、次のように集合と論理関数を対応付けすることができる。例として、図６に示す真理値表を考える。図６に示すａ，ｂ，ｃの各変数のうち、真（１）の変数を集合の要素とする。例えば、ａ，ｂ，ｃの各変数の値が１，０，０ならば｛ａ｝になる。また、Ｆが真（１）になる要素の集合は、以下の集合である。

｛ａｂ，ａｂｃ，ｂｃ，ｃ｝
また、Ｆを表す論理関数を求めると、以下に示す（１）式となる。

Ｆ＝ａｂ＋¬ａｃ …（１）
ここで、記号「¬」は否定（ｎｏｔ）を表すものとする。このように、集合と論理関数を対応付けすることができる。式１が、集合｛ａｂ，ａｂｃ，ｂｃ，ｃ｝を表す特性関数である。

次に、ＢＤＤを使用して論理関数や集合を分解する方法は、従来数多く提案されており、周知技術である。非特許文献１には、論理関数を分解するアルゴリズムが示されている。また、非特許文献２には、組み合わせ集合を、要素を共有しない集合に分解するアルゴリズムが示されている。

尚、本発明は、集合を分解する方法やアルゴリズムに依存したものではないので、機能の組み合わせを要素とする集合Ｓを分解する方法やアルゴリズムを特性関数とＢＤＤとを用いる方法に限定するものではない。

第１の実施形態によれば、機能属性に基づいて検証対象の論理システムが有する機能の組み合わせの依存関係を実用的な時間で全て抽出することができる。

［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態を詳細に説明する。第２の実施形態では、第１の実施形態で分類された機能の依存関係の有無に基づいてファンクションカバレッジを取得すると共に、検証実行手順を作成する方法を説明する。

図７は、第２の実施形態におけるファンクションカバレッジの生成方法を説明するための図である。第１の実施形態で説明した機能分類結果１２からファンクションカバレッジ生成器２２がファンクションカバレッジ１３を生成し、検証実施予定表作成器２３が検証実施予定表１４を生成する。

機能分類結果１２には、依存関係の有る機能の組み合わせが同じグループに分類されている。グループ分けの一例として、以下のグループＥを使用する。尚、ｒ＿ＭａＳｂ、ｗ＿ＭａＳｂは、機能一覧４１に示した機能である。

グループＥ：｛ｒ＿ＭａＳｂ｝、｛ｗ＿ＭａＳｂ｝、｛ｒ＿ＭａＳｂ，ｗ＿ＭａＳｂ｝
ファンクションカバレッジ生成器２２は、グループの各要素に対応するファンクションカバレッジを生成する。ここでは、グループＥの｛ｒ＿ＭａＳｂ｝、｛ｗ＿ＭａＳｂ｝、｛ｒ＿ＭａＳｂ，ｗ＿ＭａＳｂ｝の各要素に対応するファンクションカバレッジを生成する。

ここで、ファンクションカバレッジ生成器２２が生成するファンクションカバレッジの一例を、図８を用いて説明する。

図８は、グループＥに対して設定したファンクションカバレッジの定義の一例を示す図である。この例５１は、市販の検証環境であるSpecman-eliteで使われているｅ言語で、ファンクションカバレッジを定義した例である。尚、本発明はファンクションカバレッジを定義する言語に依存した発明ではないので、ファンクションカバレッジの定義をｅ言語に限定するものではない。

図８に示すように、まずｅｖｅｎｔ文でファンクションカバレッジを取得するきっかけ、つまりイベントを定義する。そして、ｃｏｖｅｒ文で定義したイベントに対応するファンクションカバレッジの取得を定義する。

一行目は、イベントｒ＿ｂｕｓａ＿ｏｐを定義している。このイベント定義は、イベントｒ＿ＭａＳｂが信号ｍａ＿ｒｄ＿ｅｎｂの立ち上がり（ｒｉｓｅ）で有効になることを示している。尚、信号ｍａ＿ｒｄ＿ｅｎｂはバスマスタａ３４が出力するｒｅａｄ動作を示す信号である。即ち、イベントｒ＿ｂｕｓａ＿ｏｐはバスマスタａ３４のｒｅａｄ動作時に有効になる。次のイベントｗ＿ｂｕｓａ＿ｏｐはバスマスタａ３４のｗｒｉｔｅ動作時に有効になる。

三番目のイベント定義と四番目のイベント定義は、イベントｒ＿ｂｕｓａ＿ｏｐとイベントｗ＿ｂｕｓａ＿ｏｐの組み合わせに対応するイベントを定義する。イベントの定義では発生順が重要であるため、発生順を明示しイベントを定義する。三番目のイベント定義は、以下の通りである。

＠ｗ＿ｂｕｓａ＿ｏｐ イベントｗ＿ｂｕｓａ＿ｏｐが発生
［．．］ 任意の時間が経過
＠ｒ＿ｂｕｓａ＿ｏｐ イベントｒ＿ｂｕｓａ＿ｏｐが発生
つまり、イベントｗ＿ｂｕｓａ＿ｏｐの後、イベントｒ＿ｂｕｓａ＿ｏｐが発生するが、その発生間隔は任意である。ただし、イベントｗ＿ｂｕｓａ＿ｏｐとイベントｒ＿ｂｕｓａ＿ｏｐの間に別のイベントが発生してはいけない。

四番目のイベント定義は、イベントｒ＿ｂｕｓａ＿ｏｐ、イベントｗ＿ｂｕｓａ＿ｏｐの順に発生するイベントを定義している。

続くｃｏｖｅｒ文で、グループＥの各要素に対応するファンクションカバレッジを定義する。一番目のｃｏｖｅｒ文は、イベントｒ＿ｂｕｓａ＿ｏｐが発生し、かつ信号ａｄｄの値が０ｘ００００〜０ｘ３ｆｆｆの範囲であれば、ファンクションカバレッジを取得することを定義している。信号ａｄｄはアドレスを示す信号である。従って、バスマスタａ３４がバススレーブｂ３５からデータを読み込むｒｅａｄ動作、機能ｒ＿ＭａＳｂが発生すると、ファンクションカバレッジを取得する。つまり、グループＥの要素｛ｒ＿ＭａＳｂ｝に対応するファンクションカバレッジを取得することを定義している。二番目のｃｏｖｅｒ文は、｛ｗ＿ＭａＳｂ｝に対応するファンクションカバレッジの取得を定義する。そして、三番目と四番目のｃｏｖｅｒ文で、｛ｒ＿ＭａＳｂ，ｗ＿ＭａＳｂ｝に対応するファンクションカバレッジを定義している。

このように、依存関係の有る機能間にクロスファンクションカバレッジの取得を定義し、検証精度と検証効率を向上させることができるファンクションカバレッジを取得可能となる。

次に、検証実施予定表作成器２３の処理を説明する。ここでは、グループ分けの一例として、ファンクションカバレッジ生成器２２の説明に使用したグループＥ及び以下のような要素からなるグループＦを使用する。尚、ｒ＿ＭａＳｂ、ｗ＿ＭａＳｂ、ｒ＿ＭｃＳｄ、ｗ＿ＭｃＳｄは、機能一覧４１に示した機能である。

グループＥ：｛ｒ＿ＭａＳｂ｝、｛ｗ＿ＭａＳｂ｝、｛ｒ＿ＭａＳｂ，ｗ＿ＭａＳｂ｝
グループＦ：｛ｒ＿ＭｃＳｄ｝、｛ｗ＿ＭｃＳｄ｝、｛ｒ＿ＭｃＳｄ，ｗ＿ＭｃＳｄ｝
グループＥはバスＡ３２のみを使用する機能、グループＦはバスＢ３３のみを使用する機能である。従って、グループＥとグループＦの機能は互いに独立して動作可能である。そこで、グループＥとグループＦから一要素ずつ選択しテストを作成すれば、互いに独立した機能を並行して実行可能なテストを作成できる。ここで、機能の組み合わせからなる要素｛ｒ＿ＭａＳｂ，ｗ＿ＭａＳｂ｝、｛ｒ＿ＭｃＳｄ，ｗ＿ＭｃＳｄ｝は、順序を考慮してテストを作成する。

このように、検証実施予定表作成器２３は、依存関係の無いテストは並行して実行するように検証実施予定表（検証実行手順）１４を作成する。

図９は、第１及び第２の実施形態で説明した図１及び図７を組み合わせて機能の検証を実施する方法を説明するための図である。図９に示すように、機能属性１１に基づき依存関係解析器２１が機能の依存関係を解析して機能分類結果１２を出力する。そして、その機能分類結果１２からファンクションカバレッジ生成器２２がファンクションカバレッジを生成し、検証実施予定表作成器２３が検証実施予定表１４を作成する。

第２の実施形態によれば、機能の組み合わせの依存関係まで考慮して、ファンクションカバレッジを取得し、検証を実施することが可能となる。また、機能の依存関係を考慮した検証順の設定が容易になり、検証精度と検証効率を向上させることが可能となる。

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

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

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

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

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

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

第１の実施形態における機能の依存関係を解析する解析方法を説明するための図である。 検証対象であるモジュールの構成の一例を示す図である。 図２に示すモジュール３１が持つ機能の一覧を示す図である。 機能をグループＡとグループＢに分けた場合を示す図である。 機能をグループＣとグループＤに分けた場合を示す図である。 集合と論理関数を対応付ける真理値表を示す図である。 第２の実施形態におけるファンクションカバレッジの生成方法を説明するための図である。 グループＥに対して設定したファンクションカバレッジの定義の一例を示す図である。 第１及び第２の実施形態で説明した図１及び図７を組み合わせて機能の検証を実施する方法を説明するための図である。

符号の説明

１１ 機能属性
１２ 機能分類結果
１３ ファンクションカバレッジ
１４ 検証実施予定表
２１ 依存関係解析器
２２ ファンクションカバレッジ生成器
２３ 検証実施予定表作成器

Claims (7)

1. ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせからなる検証対象の論理システムを検証するための検証装置にて実行される論理検証方法であって、
   前記検証対象の複数の機能を分類する分類工程と、
   前記分類された機能に基づいて検証実行手順を作成する作成工程とを有することを特徴とする論理検証方法。
2. 前記分類工程は、前記機能の特徴を表す属性に基づいて前記複数の機能間の依存関係を解析し、該依存関係の有無により前記機能を分類することを特徴とする請求項１に記載の論理検証方法。
3. 前記分類された機能に基づいてファンクションカバレッジの取得を設定する工程を更に有し、
   前記設定する工程は、前記依存関係の有る機能間にクロスファンクションカバレッジの取得を設定することを特徴とする請求項２に記載の論理検証方法。
4. 前記作成工程は、前記依存関係の無い機能間の検証は並行して実行するように前記検証実行手順を作成することを特徴とする請求項２又は３に記載の論理検証方法。
5. ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせからなる検証対象の論理システムを検証するための検証装置であって、
   前記検証対象の複数の機能を分類する分類手段と、
   前記分類された機能に基づいて検証実行手順を作成する作成手段とを有することを特徴とする検証装置。
6. 請求項１乃至４の何れか１項に記載の論理検証方法をコンピュータに実行させるためのプログラム。
7. 請求項６に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images