JP2006163598A - 検証方法及び検証装置 - Google Patents

Abstract

【課題】 論理システムの動作と仕様とが一致しない不具合が発生した場合に、その原因箇所を探索する時間を短縮する。
【解決手段】 ハードウェア記述言語で記述した論理システムを検証する際に、その論理システムの内部構成及び入出力制約条件を生成し（Ｓ２００、Ｓ３００）、論理システムを動的シミュレータで実行して動的シミュレーションの実行状態を記録し（Ｓ１００）、その論理システムの内部構成、入出力制約条件、及び動的シミュレーションの実行状態に基づいて論理システムの動作を定義するプロパティを生成し、そのプロパティに基づいて論理検証を行う（Ｓ４００、Ｓ５００）。
【選択図】 図４

Description

本発明は、論理システムを検証する技術に関するものである。

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

現在、ＬＳＩを含む論理システムの検証では、検証対象の外端仕様のみを用いて検証を行うブラックボックス検証が主流である。このブラックボックス検証は、検証対象の内部構成や仕様に依存しないため、流用性や可読性が高く、取りまわしが便利である。

しかし、ブラックボックス検証は検証対象の外端仕様のみで検証を実施し、検証対象の内部状態を考慮していない。また、ブラックボックス検証は論理シミュレータで検証対象を擬似的に動かす動的シミュレーション手法で実現している。そのため、検証対象の動作と仕様とが一致しない不具合、例えば実行値と期待値との不一致が発生した場合に、その原因箇所の探索に多くの時間がかかってしまう。この主な原因は以下の二点である。
１）検証対象の内部構成や仕様が不明であるため、検証対象の論理記述を端から解析する必要がある
２）不具合事象の再現や修正を確認するために、何度も動的シミュレーションを実行する必要がある。

一方、検証対象の内部構成や仕様も併せて使用して検証を行うホワイトボックス検証では、検証対象の内部構成や仕様も参照しているため、検証対象の動作が仕様に一致しない場合、その原因箇所の探索はブラックボックス検証に比較して容易である。

しかし、検証対象の内部構成や仕様が明確になっていなければ、ホワイトボックス検証を実施することはできない。

背景技術としては、特許文献１が挙げられる。特許文献１には、外部モジュールのプロパティ情報（回路の動作仕様を専用の書式で表現したもの）から、検証対象モジュールに入力を与えるシミュレーション環境を自動生成し、また、検証対象モジュールのプロパティ情報から、検証対象モジュールの出力を期待値と比較するシミュレーション環境を自動生成することが記載されている。
特開2003-196342号公報

上述したように、検証対象の仕様が外端のみ定義されている場合は、ブラックボックス検証を用いらなければならなかった。しかし、ブラックボックス検証で検証対象の動作と仕様とが一致しない不具合が発生した場合に、その原因箇所の探索には長い時間が必要である。

よって、従来の手法では、十分な精度を持つ論理システムを予定の期間内に完成させることができず、市場が欲するときに製品を投入できないという問題や不十分な精度のまま製品を市場に投入してしまうという問題が生じる。

本発明は、上記課題を解決するためになされたもので、論理システムの動作と仕様とが一致しない不具合が発生した場合に、その原因箇所を探索する時間を短縮することを目的とする。

本発明は、論理システムを検証する検証方法であって、前記論理システムの内部構成を抽出する抽出工程と、前記論理システムの入出力制約条件を生成する入出力制約条件生成工程と、前記論理システムを動的シミュレータで実行し、該動的シミュレーションの実行状態を記録する動的シミュレーション実行工程と、前記論理システムの内部構成、前記入出力制約条件、及び前記動的シミュレーションの実行状態に基づいて前記論理システムの動作を定義するプロパティを生成し、そのプロパティに基づいて前記論理システムの論理検証を行う検証工程とを有することを特徴とする。

また、本発明は、論理システムを検証する検証装置であって、前記論理システムの内部構成を抽出する抽出手段と、前記論理システムの入出力制約条件を生成する入出力制約条件生成手段と、前記論理システムを動的シミュレータで実行し、該動的シミュレーションの実行状態を記録する動的シミュレーション実行手段と、前記論理システムの内部構成、前記入出力制約条件、及び前記動的シミュレーションの実行状態に基づいて前記論理システムの動作を定義するプロパティを生成し、そのプロパティに基づいて前記論理システムの論理検証を行う検証手段とを有することを特徴とする。

本発明によれば、論理システムの動作と仕様とが一致しない不具合が発生した場合に、その原因箇所を探索する時間を短縮することができる。

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

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

図１は、本実施形態における論理システムの検証方法を示す図である。図１において、１１は検証対象のＤＵＴ（Design Under Test）であり、Verilog 或いはＶＨＤＬ（VHSIC Hardware Description Language）などのハードウェア記述言語で記述した論理システムの設計データである。ここで、ＤＵＴ１１の外端の仕様は定義されているが、ＤＵＴ１１内部の構成や仕様は、明確に定義していなくても良い。

本実施形態では、このＤＵＴ１１を論理検証するためのプロパティ（property）を生成するものであり、このプロパティは検証対象の動作仕様を表す式である。

１３はＤＵＴ入出力制約条件であり、ＤＵＴ１１の入力及び出力の動作を定義するものである。１４はプロパティライブラリであり、論理システムを構成する部品である「機能ブロック」のプロパティを纏めたものである。即ち、機能ブロックを予め定義しておき、機能ブロック毎にプロパティを定義し、プロパティライブラリ１４として保存しておく。このプロパティライブラリ１４は開発する論理システム全てに対して共通に使用するものであって、個々の論理システム毎に作成するものではない。

２１は動的シミュレーションであり、ＤＵＴ１１の動的検証を実施する。この検証時に使用する検証環境であるテストベンチは、ＤＵＴ１１に入力したデータの値、ＤＵＴ１１の実行値、及び期待値を時刻と共に記録する機能が必要である。この記録機能があれば、従来の動的検証で用いたテストベンチをそのまま用いても良い。しかし、この記録機能が無ければ、従来の動的検証で用いたテストベンチに記録機能を追加し、そのテストベンチを用いても良い。勿論、新規にテストベンチを作成するのを妨げるものではない。

ここで、ＤＵＴ１１に入力したデータの値、ＤＵＴ１１の実行値、期待値、及び時刻は、１７の動的シミュレーションログに記録される。

２２は内部構成・内部ブロック入出力条件抽出器であり、上述したＤＵＴ１１、ＤＵＴ入出力制約条件１３、及びプロパティライブラリ１４に基づいて、ＤＵＴ内部構成表及び内部ブロック入出力制約条件を生成し、１５のＤＵＴ内部構成表及び１６の内部ブロック入出力制約条件に保存する。尚、内部構成・内部ブロック入出力条件抽出器２２の詳細については図２を用いて更に後述する。

そして、２３は内部ブロックプロパティ生成器であり、上述したプロパティライブラリ１４、ＤＵＴ内部構成表１５、内部ブロック入出力制約条件１６、及び動的シミュレーションログ１７に基づいて、ＤＵＴ１１を構成する内部ブロック毎にプロパティを生成し、１８の内部ブロックプロパティに保存する。

次に、図２を用いて図１に示す内部構成・内部ブロック入出力条件抽出器２２の詳細な構成及び動作について説明する。

図２は、内部構成・内部ブロック入出力条件抽出器２２の構成の一例を示す図である。図示するように、内部構成・内部ブロック入出力条件抽出器２２は、内部表現変換器３２、比較器３３、内部ブロック入出力条件生成器３４から構成されている。

内部表現変換器３２は、ＤＵＴ１１の内部構成や仕様をプロパティライブラリ１４中のプロパティと比較できる内部表現に変換する。比較器３３は、内部表現変換器３２で変換された内部表現とプロパティライブラリ１４中のプロパティとを比較する。ここで、内部表現がプロパティライブラリ１４中のあるプロパティを包含していると判断したならば、そのプロパティが該当する機能ブロックの情報をＤＵＴ内部構成表１５に登録する。また、ＤＵＴ１１の変換された内部表現中、どのプロパティをも包含していない内部表現は、未知ブロック（unknown block）としてＤＵＴ内部構成表１５に登録する。

尚、この未知ブロックは、既知の機能ブロックに一致しないので、未知の機能を持っている可能性がある。

従って、ＤＵＴ内部構成表１５には、未知ブロックを含む機能ブロックの情報がＤＵＴ１１を構成する内部構成として登録される。以下、ＤＵＴ１１を構成する機能ブロックを「内部ブロック」と呼ぶ。

次に、内部ブロック入出力制約条件生成器３４は、ＤＵＴ入出力制約条件１３とＤＵＴ内部構成表１５に登録された情報から内部ブロックの入力と出力の制約条件を生成する。以下、特に区別する必要が無い限り入力と出力の制約条件を合わせて「入出力制約条件」と呼ぶ。そして、生成した入出力制約条件を内部ブロック入出力制約条件１６として保存する。

但し、内部ブロック入出力制約条件生成器３４は、全ての内部ブロックについて入出力制約条件を常に生成しなければならないわけではない。内部ブロック入出力制約条件生成器３４が生成する入出力制約条件１６は、内部ブロック入出力制約条件１６の使用目的によって変化する。例えば、未知ブロックのプロパティの生成のみを実施する場合は、未知ブロックの入出力制約条件と、未知ブロックと依存関係のある内部ブロックの入出力制約条件を求めるだけで良い。

一方、動的シミュレーションで生じた検証対象の動作と仕様の不一致の原因箇所を探求する場合は、全ての内部ブロックの入出力制約条件を求める。或いは、原因箇所の絞込みができているならば、原因箇所が存在すると予想される内部ブロックとその周辺ブロックに、入出力制約条件の生成を限っても良い。勿論、全ての内部ブロックについて入出力制約条件を常に生成することを妨げるものではない。

次に、８ビットダウンカウンタ（8 bit down counter）の動作を定義するプロパティを例にとり、プロパティの具体例について説明する。以下に、本実施形態で使用する記号を示す。

; 動作記述の区切り
a =＞ b ａが成立するならばｂが成り立つ
&& 論理積
|| 論理和
~ 論理否定
' 次クロック・サイクルの状態
// コメント
== 論理等価
1'b1 ２進数一桁、値は '1'
rst_n_in カウンタ・リセット信号 ('0' でリセット)
do_out カウンタ値出力 (8 bit)
enb_in カウンタ・イネーブル信号 ('1' でカウントダウン, '0' で保持)
以下に示すプロパティは、８ビットダウンカウンタの動作を定義するプロパティの一部である。

(~rst_n_in == 1'b1) =＞
'(do_out) == 8'b00000000; // Ｐ−１
(~rst_n_in == 1'b0) && (enb_in == 1'b1) =＞
'(do_out) == do_out - 1'b1; // Ｐ−２
各項の意味は以下の通りである。

(~rst_n_in == 1'b1) ： ~rst_n_in が '1' 、つまり rst_n_in が '0' 、
即ち、カウンタ・リセット信号が有効
'(do_out) == 8'b00000000 ： 次クロック・サイクルのカウンタ値が 0
(enb_in == 1'b1) ： カウンタ・イネーブル信号が有効、
即ち、カウントダウン動作
'(do_out) == do_out - 1'b1： 次クロック・サイクルのカウンタ値は現在のカウンタ 値から 1 減じた値
よって、プロパティＰ−１、Ｐ−２は以下の動作記述を定義している。
Ｐ−１「カウンタ・リセット信号が有効ならば、次クロック・サイクルでカウンタの値は全て 0 になる」
Ｐ−２「カウンタ・リセット信号が無効で、かつカウント・イネーブル信号が有効ならば、次クロック・サイクルのカウンタ値は、現在のカウンタから 1 減じた値」
但し、本発明はプロパティの書式や言語仕様に依存した発明ではないので、プロパティは上記の例に限定されるものではない。

次に、本実施形態の内部表現変換器３２で変換される内部表現について説明する。上述した比較器３３で内部表現の比較を行うために、本実施形態で使用する内部表現は、同一の論理関数が同一の表現にならなければならない。また、容量が大きくならず、内部表現による比較の手順が容易である必要がある。

同一の論理関数が同一の表現となる表現方法として、例えば二分決定グラフ（ＢＤＤ：Binary Decision Diagram）、真理値表、積和標準形が知られている。この真理値表は、入力数の指数乗の項を必要とする。また、積和標準形も最悪の場合、真理値表と同様に、入力数の指数乗の項を必要とする。しかし、ＢＤＤでは多くの場合、真理値表や積和標準形より少ない項で論理関数を表現可能である。また、真理値表と積和標準形では、内部表現への変換工数が論理関数の複雑度に影響し、複雑になるにつれて内部表現への変換工数が増加する。

一方、ＢＤＤでは、論理関数の複雑度に関係なく変換工数が決定するため、本実施形態では、内部表現としてＢＤＤを用いるものとする。勿論、内部表現はＢＤＤに限定されるものではなく、同一の論理関数が同一の表現になるならばどのような表現が用いられても良い。

ＢＤＤを内部表現に使用するプログラムや市販のツールでは、ＢＤＤ生成アルゴリズムとして、applyアルゴリズムが広く使用されている。このapplyアルゴリズムは、1984年にRandal E. Bryant氏により開発されたＢＤＤ生成アルゴリズムである。また、このapplyアルゴリズムは、既に数多く使用されており、公知の技術である。

そこで、上述した内部表現変換器３２は、ＤＵＴ１１やプロパティをＢＤＤに変換する手法として、applyアルゴリズムを使用するものとする。

尚、本発明は、ＢＤＤ生成アルゴリズムに依存した発明ではないので、内部表現変換器３２が使用するアルゴリズムはapplyアルゴリズムに限定されるものではない。

ここで、比較器３３は、ＤＵＴ１１のＢＤＤとプロパティのＢＤＤの同形性を判定し、ＤＵＴ１１のＢＤＤがプロパティのＢＤＤを包含しているか否かを判断する。このＢＤＤの同形性判定アルゴリズムは、従来から多くの提案が存在している。

尚、本発明は、同形性判定アルゴリズムに依存した発明ではないので、どの同形性判定アルゴリズムを用いても良い。例えば、ある節に注目し、'1'の枝の形と、'0'の枝の形を再帰的に比較することで同形性を判定する手法を用いても良い。

次に、図３を用いてプロパティライブラリ１４を作成する方法について説明する。尚、図３に示す機能ブロック一覧表１２は、論理システムを構成する部品である機能ブロックの一覧である。この機能ブロック一覧表１２は、開発する論理システム全てに対して共通に使用するものであって、個々の論理システム毎に作成するものではない。よって、予め必要な機能ブロックが何であるかを検討し、機能ブロック一覧表１２を作成しておく。

図３は、本実施形態におけるプロパティライブラリ１４の作成方法の一例を示す図である。まず、機能ブロック一覧表１２に記載の機能ブロック毎に動作を定義したプロパティをプロパティ生成手順３１で作成し、内部表現変換器３２で上述の内部表現に変換する。そして、プロパティと内部表現を対にして機能ブロック毎にプロパティライブラリ１４として保存する。

尚、プロパティライブラリ１４は機能ブロック一覧表１２に変更が無ければ、毎回生成し直す必要は無い。そのため、プロパティ生成手順３１では、機能ブロック一覧表１２からプロパティを生成する工程を自動化せず、人手でプロパティを作成しても良い。勿論、プロパティ自動生成ツールの使用を妨げるものではない。また、本実施形態における論理検証手法及び論理検証装置を用いる度に、或いは論理システム毎にプロパティライブラリ１４を生成することを妨げるものでもない。

図４は、本実施形態における論理検証手法及び論理検証装置を用いた検証の流れの一例を示すフローチャートである。ここでは、論理検証手法及び論理検証装置を用いて、より詳細にＤＵＴ１１の検証を行う手順を示している。前提条件として、ＤＵＴ１１内に機能が未知である未知ブロックが存在し、プロパティライブラリ１４は予め生成してあるものとする。また、図４に示す処理は、ＤＵＴ１１を入力したときから開始される。

まず、ステップＳ１００において、動的シミュレーション２１がＤＵＴ１１の動的検証を実施し、ＤＵＴ１１に入力したデータの値、ＤＵＴ１１の実行値、期待値、及び時刻を動的シミュレーションログ１７に記録する。

一方、ステップＳ２００では、内部構成・内部ブロック入出力条件抽出器２２内の内部表現変換器３２及び比較器３３によりプロパティライブラリ１４内の内部表現に基づいてＤＵＴ１１の内部構成を求め、ＤＵＴ内部構成表１５を生成する。

また、ステップＳ３００では、ＤＵＴ入出力制約条件１３とＤＵＴ内部構成表１５から内部ブロック入出力条件１６を生成する。

次に、ステップＳ４００において、内部ブロックプロパティ生成器２３が、ステップＳ１００の結果（動的シミュレーションログ１７）、ステップＳ２００の結果（ＤＵＴ内部構成表１５）、及びステップＳ３００の結果（内部ブロック入出力制約条件１６）から、内部ブロックプロパティ１８を生成する。

そして、ステップＳ５００では、ステップＳ４００で生成した内部ブロックプロパティ１８を用いて検証や原因箇所の探索を行う。

引き続き、図４に示す各ステップの詳細な動作について説明する。最初に図５を用いて図４に示すステップＳ２００の「ＤＵＴ１１の内部構成を抽出し、ＤＵＴ内部構成表１５を作成する」動作について説明する。

図５は、図４に示すステップＳ２００の詳細な動作を示すフローチャートである。まず、ステップＳ２１０において、内部表現変換器３２を使用してＤＵＴ１１をＢＤＤに変換する。以下、変換後のＢＤＤを「ＢＤＤ（ＤＵＴ）」と呼ぶ。次に、ステップＳ２２０において、プロパティライブラリ１４から機能ブロックを一つ選択し、この機能ブロックの動作を定義する全てのプロパティをプロパティライブラリ１４から選択し、ＢＤＤに変換する。以下、このＢＤＤを「ＢＤＤ（property）」と呼ぶ。

次に、ステップＳ２３０〜ステップＳ２４０において、比較器３３でＢＤＤ（ＤＵＴ）がＢＤＤ（property）を包含しているかを判定する。ここで、ＢＤＤ（property）を包含している場合はステップＳ２５０へ分岐し、包含していないＢＤＤ（property）が存在する場合はステップＳ２７０へ分岐する。

ステップＳ２５０では、ステップＳ２２０で選択した機能ブロックについてＤＵＴ内部構成表１５に以下の情報を登録する。
（Ａ）機能ブロック名称と、その動作を定義する全てのプロパティの番号
（Ｂ）ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応
（Ｃ）機能ブロック間の接続情報
尚、（Ｃ）の情報は、ステップＳ２２０で選択した機能ブロックの信号名とポート名を、ＤＵＴ内部構成表１５内で検索して求める情報である。このとき、接続先機能ブロックの項に、ステップＳ２２０で選択した機能ブロックの情報が記載されていなければ、情報を追加する。

次に、ステップＳ２６０では、ＢＤＤ（property）の各節に対応するＢＤＤ（ＤＵＴ）の節に登録済み印を付ける。

次に、ステップＳ２７０では、プロパティライブラリ１４内に未比較の機能ブロックが存在するかを調べ、終了条件を判定する。ここで、未比較の機能ブロックが存在する場合はステップＳ２２０に戻り、未比較の機能ブロックが存在しない場合はステップＳ２８０へ分岐する。

尚、ＢＤＤ（ＤＵＴ）で登録済み印が付いていない節からなる部分、即ち、ＤＵＴ１１においてプロパティライブラリ１４内の何れの機能ブロックにも相当しない部分である、この部分を未知ブロックと呼ぶ。未知ブロックは、未知の機能を含んでいるため、何れの機能ブロックにも一致しないと考えられる。或いは、ＤＵＴ１１の記述誤りにより、未知ブロックは、何れの機能ブロックにも一致しなかったとも考えられる。

ステップＳ２８０では、このＢＤＤ（ＤＵＴ）で登録済み印がついていない節を変換して未知ブロックのプロパティを生成する。未知ブロックのプロパティ番号は、Ｕ−１，Ｕ−２，…とする。ここで生成したプロパティは未知ブロックの動作を示しているが、仕様通りであるとは限らない。なぜならば、ＤＵＴ１１の記述誤りにより何れの機能ブロックにも一致せず、未知ブロックに分類されている可能性があるためである。

そして、未知ブロックの情報をＤＵＴ内部構成表１５に登録する。名称を未知ブロックとする以外、ステップＳ２５０と動作は同じである。
（Ａ）機能ブロック名称と、その動作を定義する全てのプロパティの番号
（Ｂ）ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応
（Ｃ）機能ブロック間の接続情報
尚、（Ｃ）の情報は、未知ブロックの信号名とポート名を、ＤＵＴ内部構成表１５内で検索して求める。このとき、接続先機能ブロックの項に、未知ブロックの情報が記載されていなければ、情報を追加する。

ここで、本実施形態におけるＤＵＴ内部構成表１５の構成について説明する。図６は、ＤＵＴ内部構成表１５の構成の一例を示す図である。図６に示すように、ＤＵＴ内部構成表１５は、左から順に機能ブロック番号１０１、機能ブロック名１０２、プロパティ番号１０３、信号対応表１０４の４列で構成されている。また、信号対応表列１０４は、更に５列に分かれている。そして、ＤＵＴ内部構成表１５は、新しい機能ブロックを登録する毎に、一行ずつ増加する。

図６に示す機能ブロック番号１０１内の番号は登録順に付けられる。また、この番号は、ＤＵＴ内部構成表１５の信号対応表で接続先を示すのにも使用される。

機能ブロック名１０２は機能ブロックの名称である。ここで使用する名称はプロパティライブラリ１４に登録してある機能ブロック名である。

プロパティ番号１０３には、プロパティを一意に定めることができる情報を記載する。プロパティそのものでもプロパティに付けた番号でも良い。本実施形態では、プロパティ毎に付けたプロパティ番号を記録するものとする。また、当該機能ブロックの動作が複数のプロパティで定義されている場合は、全てのプロパティ番号を記入する。

信号対応表１０４は、ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応と機能ブロック間の接続情報とを記録する。また、信号対応表１０４は、プロパティ変数名１１１、デザイン変数名１１２、方向１１３、接続先１１４、接続先信号名１１５の５列で構成されている。

プロパティ変数名１１１及びデザイン変数名１１２は、プロパティ内の変数名とＤＵＴ１１の信号名やポート名との対応を示している。プロパティ変数名１１１は、プロパティで使用している変数名を記録している。また、デザイン変数名１１２は、プロパティ変数名１１１に対応する信号名或いはポート名を記録している。

方向１１３は機能ブロックからみた信号の方向を示し、“ＩＮ”と“ＯＵＴ”の２つの状態を取る。ここで“ＩＮ”は入力信号を、“ＯＵＴ”は出力信号を示す。

接続先１１４及び接続先信号名１１５は、接続先と接続先の信号名とを示す。具体的には、接続先がＤＵＴ内部構成表１４に登録済みの機能ブロックであれば、接続先１１４はその機能ブロック番号となる。

また、接続先がＤＵＴ１１の入力或いは出力ポートであれば、接続先１１４は“ポート（PORT）”とする。ＤＵＴ１１内部に接続しているのに関わらず、ＤＵＴ内部構成表１５に登録が無い場合は未定にしておく。そして、図５におけるステップＳ２８０で、ＤＵＴ内部構成表１４を再走査し、接続先１１４の値を確定させる。このとき、接続先が、未知ブロックならば接続先１１４の値は“未知ブロック”とする。
続いて、図７及び図８を用いて図５に示すステップＳ２５０の詳細な動作について説明する。図７は、図５に示すステップＳ２５０の詳細な動作を示すフローチャートである。また、図８は、ＢＤＤ（ＤＵＴ）及びＢＤＤ（property）の一例を示す図である。図８に示すように、図５に示すステップＳ２４０でＢＤＤ（ＤＵＴ）４１がＢＤＤ（property）４２を包含している場合である。ここで、ＢＤＤ（ＤＵＴ）４１はＢＤＤ（ＤＵＴ）全体のうち、ＢＤＤ（property）４２と同形な部分を抜き出したものである。また、ＢＤＤ（ＤＵＴ）４１、ＢＤＤ（property）４２とも説明に用いる部分以外は簡略化して記述している。

尚、以下では、８ビットローダブルダウンカウンタ（8 bit loadable down counter）の動作を定義したプロパティを使用した場合を例に説明する。

まず、ステップＳ２５１において、新たな機能ブロックがＤＵＴ１１に存在することがステップＳ２４０で判明したので、ＤＵＴ内部構成表１５に一行追加する（ここで、機能ブロック番号はｎとする）。そして、ステップＳ２５２において、機能ブロック番号ｎの機能ブロック名１０２に機能ブロック名として“8 bit loadable down counter”を記載する。

次に、ステップＳ２５３において、機能ブロック番号ｎのプロパティ番号１０３に上述のステップＳ２２０で選択した全てのプロパティのプロパティ番号を記載する。そして、ステップＳ２５４において、プロパティが使用する変数（プロパティ変数）とＤＵＴ１１の信号名やポート名（デザイン変数）の対応を作成する。

ここで、図８を用いてステップＳ２５４の詳細な動作について説明する。尚、ＢＤＤ（ＤＵＴ）４１及びＢＤＤ（property）４２は同形と判断されているものとする。また同形のＢＤＤであるので、それぞれ対応する節が明らかになる。

図８において、ＢＤＤ（ＤＵＴ）４１の節４３と、ＢＤＤ（property）４２の節４４とは、それぞれ対応する節である。節４３はＤＵＴの信号或いはポートを示しており、その名称は“do_out”である。また、節４４はプロパティ内の変数を示しており、その名称は“data_out”である。そして、節４３と節４４とは対応する節なので、プロパティ変数名は“data_out”であり、それに対応するデザイン変数名は“do_out”である。

このように、ステップＳ２５４で、プロパティ変数名（“data_out”）とデザイン変数名（“do_out”）をそれぞれプロパティ変数１１１とデザイン変数１１２に記載する。

図７に戻り、ステップＳ２５５〜ステップＳ２５９において、接続先と接続先信号名を求め、接続先１１４と接続先信号名１１５に記載する。この時、接続先がポート以外で、ＤＵＴ内部構成表１５に未登録ならば、接続先は未定とする。

図８を用いてステップＳ２５５〜ステップＳ２５９の動作を説明する。図８において、ＢＤＤ（ＤＵＴ）４１の節４３は、ＢＤＤ（property）４２と同形の範囲において最終の節である。この節４３は節４５と接続している。そして、接続先の節４５は登録済みの印が存在しない。よって、ステップＳ２５８に分岐し、接続先１１４は未定にする。

次に、ステップ２５９において、接続先変数名１１５に節４３の接続先の信号名として“di_in”を登録する。一方、節４６は、ＢＤＤ（property）４２と同形の範囲において最初の節である。節４６の接続先の節４７はＤＵＴ１１のポートである。

よって、ステップＳ２５６では、ステップＳ２５７へ分岐し、接続先１１４にポートを示す“PORT”を記載する。そして、ステップ２５９では、接続先変数名１１５に節４６の接続先のポート名として“di_in”を登録する。

次に、図９を用いて図４に示すステップＳ３００の「ＤＵＴ入出力制約条件１３とＤＵＴ内部構成表１５から内部ブロック入出力条件１６を生成する」詳細な動作について説明する。

図９は、図４に示すステップＳ３００の詳細な動作を示すフローチャートである。また図１０は、本実施形態で使用するＤＵＴ１１の構造の一例を示す図である。図１０では、説明に必要ない部分は省略して記述している。

本実施形態では、ブロック５２の外端信号のうち、cnt_in６１の生成手順を説明する。それ以外の信号についても入出力制約条件の生成手順は同じである。図１０に示すように、このcnt_in６１はカウンタ５１のdo_out６２に接続している。カウンタ５１のリセット信号 rst_n_in６３はＤＵＴ１１のポート、rst_sync_n_in６４に接続している。そして、カウンタ５１の制御信号、enb_in６６は未知ブロック５２のcnt_enb_out６５に接続している。以下、説明にあたり適宜、ＤＵＴ内部構成表１５の一例を示す図６も用いる。尚、ＤＵＴ１１の外端ポートは制約条件を持たないとする。

まず、ステップＳ３１０において、ＤＵＴ内部構成表１５から未知ブロック５２の外端信号を取り出す。図６に示すＤＵＴ内部構成表１５より、未知ブロック５２の外端信号のリストは以下の通りである。

（rst_n_in, cc_out, ld_cmd_out, cnt_in, cnt_enb_out, state_in, …）
次に、ステップＳ３２０において、引数から変数を１つ取り出す。そして、その接続先信号名とプロパティをＤＵＴ内部構成表１５から検索する。

この例では、図６に示すＤＵＴ内部構成表１５を参照すると、デザイン変数名１１２、cnt_inは接続先１１４がｎ、即ち、機能ブロック番号ｎの8 bit loadable down counter （カウンタ５１）であり、その接続先信号名１１５はdo_outである。

従って、このdo_outの動作を定義したプロパティをプロパティライブラリ１３から取り出す。このプロパティの一部を以下に示す。

(~rst_n_in == 1'b0) =＞
'(do_out) == 8'b00000000; //Ｐ−１
(~rst_n_in == 1'b1) && (enb_in == 1'b1) =＞
'(do_out) == do_out - 1'b1; //Ｐ−２
次に、ステップＳ３３０において、プロパティが存在しないならばステップＳ３３５へ分岐し、存在するならばステップＳ３４０へ分岐する。

このステップＳ３４０では、ステップＳ３１０で取り出したプロパティ中の接続先変数名をステップＳ３２０で選択した変数で置換する。

(~rst_n_in == 1'b0) =＞
'(cnt_in) == 8'b00000000; //Ｐ−３
(~rst_n_in == 1'b1) && (enb_in == 1'b1) =＞
'(cnt_in) == cnt_in - 1'b1; //Ｐ−４
次に、ステップＳ３５０において、プロパティの引数に機能ブロックの外端信号が存在するか否かを判定し、この例では、プロパティ（Ｐ−３、Ｐ−４）にカウンタ５１の外端信号（rst_n_inとenb_in）が存在するので、ステップＳ３５５へ分岐する。

このステップＳ３５５では、機能ブロックであるカウンタ５１の外端信号（rst_n_inとenb_in）を引数にステップＳ３２０を再帰的に実行する。

即ち、ステップＳ３２０において、引数（rst_n_inとenb_in）から１つの引数rst_n_inを取り出す。そして、この引数rst_n_inの接続先信号名とプロパティをＤＵＴ内部構成表１５から検索する。

ＤＵＴ内部構成表１５を参照すると、カウンタ５１のrst_n_inの接続先は、“PORT”で、接続先の信号名はrst_sync_n_inである。ＤＵＴ１１の外端ポートには制約条件をつけていないので、プロパティは存在しない。

そして、ステップＳ３３０の判定で、プロパティは存在しないのでステップＳ３３５へ分岐する。このステップＳ３３５では、接続先信号のみのプロパティを作成する。

(rst_sync_n_in) //Ｐ−５
次に、ステップＳ３７０において、引数が残っているかを調べ、この例では引数が１つ残っているのでステップＳ３２０へ戻る。

このステップＳ３２０では、次の引数enb_inを取り出す。そして、この引数enb_in の接続先信号名とプロパティをＤＵＴ内部構成表１５から検索する。

ＤＵＴ内部構成表１５を参照すると、カウンタ５１のenb_inの接続先は、未知ブロックで、接続先信号名はcnt_enb_outである。未知ブロックなのでプロパティは存在しない。

そして、ステップＳ３３０の判定で、プロパティが存在しないためステップＳ３３５へ分岐する。このステップＳ３３５では、接続先信号のみのプロパティを作成する。

(cnt_enb_out) //Ｐ−６
次に、ステップＳ３７０において、引数が残っているかを調べ、この例では全ての引数について実行が終了したので、このルーチンを終了し、ステップＳ３７５では、ステップＳ３３５に戻る。戻り値は、以下の通りである。

(rst_sync_n_in)
(cnt_enb_out)
ここで、ステップＳ３５５では、上述したルーチンから戻ってきたので、戻り値で引数を置換する。即ち、rst_n_inはrst_sync_n_inで置換し、enb_inはcnt_enb_outで置換し、プロパティは以下のようになる。

(~rst_sync_n_in == 1'b0) =＞
'(cnt_in) == 8'b00000000; //Ｐ−７
(~rst_sync_n_in == 1'b1) && (cnt_enb_out == 1'b1) =＞
'(cnt_in) == cnt_in - 1'b1; //Ｐ−８
次に、ステップＳ３６０において、プロパティＰ−１とＰ−２にはＤＵＴ１１のポート信号（rst_sync_n_in）が存在するので、ステップＳ３６５へ分岐する。

このステップＳ３６５では、本実施形態におけるＤＵＴ１１の外端ポートは制約条件を持たないため、プロパティは変更なしである。

そして、ステップＳ３７０において、引数が残っているかを調べ、引数は終了したのでステップＳ３７５へ分岐する。

このステップＳ３７５では、求めたプロパティを出力し、終了する。

(~rst_sync_n_in == 1'b0) =＞
'(cnt_in) == 8'b00000000; //Ｐ−９
(~rst_sync_n_in == 1'b1) && (cnt_enb_out == 1'b1) =＞
'(cnt_in) == cnt_in - 1'b1; //Ｐ−１０
このプロパティが未知ブロック５２の入出力制約条件になる。

次に、図１１を用いて図４に示すステップＳ４００の「各内部ブロックのプロパティを生成する」詳細な動作について説明する。

図１１は、図４に示すステップＳ４００の詳細な動作を示すフローチャートである。まず、ステップＳ４１０において、ＤＵＴ内部構成表１５から機能ブロック番号１０１順に内部ブロックの情報を取り出す。そして、ステップＳ４２０において、ステップＳ４１０で取り出した機能ブロックの種類により分岐する。ここで、機能ブロックが未知ブロックの場合はステップＳ４４０へ分岐し、機能ブロックが未知ブロック以外の場合はステップＳ４３０へ分岐する。

このステップＳ４３０では、未知ブロック以外の機能ブロックはプロパティライブラリ１４に対応するプロパティが存在しているので、ＤＵＴ内部構成表１５のプロパティ番号１０３に記載された全てのプロパティをプロパティライブラリ１４から選択する。

一方、ステップＳ４４０では、未知ブロックのプロパティを推定する。

次に、ステップＳ４５０において、ステップＳ４３０及びステップＳ４４０で得た内部ブロックプロパティ１８を出力する。

次に、ステップＳ４６０では、ＤＵＴ内部構成表１５に登録した全ての内部ブロックについて処理を終了したか否かを判断し、未処理の内部ブロックが存在しないならば、この処理を終了するが、未処理の内部ブロックが存在するならば、ステップＳ４１０に戻り、上述の処理を繰り返す。

次に、上述したステップＳ４４０の詳細な動作について説明する。まず、「ｔ」を動的シミュレーションの時刻を表す変数とし、I(t)、O(t)、S(t)を次のように定義する。

I(t) ： 時刻 t の未知ブロックの入力値
O(t) ： 時刻 t の未知ブロックの出力値
S(t) ： 時刻 t の未知ブロックの内部状態
また、未知ブロックの動作は以下の式で表すことができる。

O(t) = g(S(t), I(t))
ここで、g()は、未知ブロックの出力を求める函数である。未知ブロックの内部状態を表すS(t)は、未知ブロックの内部状態と入力値を用いて以下の式で表すことができる。

S(t+1) = h(S(t), I(t))
よって、
S(t+1) = h(h(S(t - 1), I(t)), I(t))
S(t+1) = H(I(0), I(1), … , I(t))
従って、O(t)は以下の式で表される。

O(t) = g(H(I(0), I(1), … , I(t)), I(t)) = f(I(0), I(1), … , I(t))
函数f()は、未知ブロックの入力値のみで、出力値を定義している。この函数f()を求めれば、未知ブロックの動作を定義したプロパティを生成することが可能となる。この函数f()を求めるには、例えば差分法が使用できる。この手法は、二つの出力値O(t)、O(t-1)の差分と、それらに対応する入力値の差分からf()を推測する方法である。或いは、暗号解読に用いる線形解読法も使用可能である。但し、本発明は函数f()を求める手法に依存した発明ではないので、これらの方法に限定するものではない。

上述した未知ブロックの入力値I(t)と出力値O(t)は、例えば以下の手順で求めることが可能である。

まず、動的シミュレーションログ１７から、実行値と期待値とが不一致になった時刻と、その時の期待値を抽出する。この時刻をｎ、期待値をexp(n)とする。実行値と一致する期待値を用いると、不具合の原因箇所が活性化していないため、不具合の原因箇所を排除できず、その結果、誤りを含んだプロパティを生成してしまう恐れがある。もし、実行値と期待値とが全て一致しているならば、最後の比較に用いた期待値をexp(n)として作業を続ける。

次に、上述のexp(n)から、未知ブロックの出力値O(m)を求める。この時、ＤＵＴ構成表１５に登録した各内部ブロックのプロパティを用いて、ＤＵＴ１１の出力から順に求めてゆく。ここで、m ＜= nである。なぜならば、未知ブロックからＤＵＴ１１の出力までの間には０サイクル以上の伝播遅延が存在するからである。

次に、時刻ｍにおける未知ブロックの入力値I(m)を求める。ＤＵＴ構成表１５に登録した各内部ブロックのプロパティを用いてＤＵＴ１１の入力値から順に求めて行く。ＤＵＴ１１の入力値は動的シミュレーションログ１７から必要に応じて抽出する。

但し、本発明は未知ブロックの入力値I(t)と出力値O(t)の抽出方法に依存した発明ではないので、未知ブロックの入力値I(t)と出力値O(t)の抽出方法を上述の例に限定するものではない。

次に、図４に示すステップＳ５００の詳細な動作について説明する。ステップＳ５００では、ステップＳ３００で求めた内部ブロック入出力制約条件１６と、ステップＳ４００で求めた内部ブロックプロパティ１８とを用いて静的検証をＤＵＴ１１に適用する。この時、全ての内部ブロックに対して静的検証を実施しなければならないわけではない。

例えば、明らかに不具合の原因が存在しないと判断した内部ブロックに対しては実施しないように構成することも可能である。また、反対に、明らかに不具合の原因が存在すると判断した内部ブロックに対してのみ実施するように構成しても良い。勿論、全ての内部ブロックに対して静的検証を実施することを妨げるものではない。

以上説明したように、本実施形態によれば、機能が既知である機能ブロックが検証対象の論理システム内に存在すれば、その機能ブロックの動作仕様のみを用いて論理システムの内部構成を抽出し、内部ブロックの入出力制約条件を生成することにより、検証対象の論理システムの内部構成や内部仕様が明確でなくとも、論理システムの内部構成抽出と、内部ブロックの入出力制約条件生成が可能となる。

また、抽出した内部構成や生成した内部ブロック入出力制約条件に加えて、動的シミュレーションの実行状態も併せて使用することにより、既知の機能ブロックに一致せずに、動作仕様を表したプロパティを生成できなかったブロックに対してもプロパティの生成が可能になる。

更に、内部ブロックの入出力制約条件とプロパティを生成し、この内部ブロックの入出力制約条件とプロパティを用いることにより、ブラックボックス検証時に発生する不具合の原因箇所を探索する際に、探索範囲を限定でき、検証対象の論理記述を端から解析する必要が無くなる。従って、不具合の原因箇所探索に費やす時間を減少させることが可能となる。

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

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

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

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

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

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

本実施形態における論理システムの検証方法を示す図である。 内部構成・内部ブロック入出力条件抽出器２２の構成の一例を示す図である。 本実施形態におけるプロパティライブラリ１４の作成方法の一例を示す図である。 本実施形態における論理検証手法及び論理検証装置を用いた検証の流れの一例を示すフローチャートである。 図４に示すステップＳ２００の詳細な動作を示すフローチャートである。 ＤＵＴ内部構成表１５の構成の一例を示す図である。 図５に示すステップＳ２５０の詳細な動作を示すフローチャートである。 ＢＤＤ（ＤＵＴ）及びＢＤＤ（property）の一例を示す図である。 図４に示すステップＳ３００の詳細な動作を示すフローチャートである。 本実施形態で使用するＤＵＴ１１の構造の一例を示す図である。 図４に示すステップＳ４００の詳細な動作を示すフローチャートである。

符号の説明

１１ ＤＵＴ
１２ 機能ブロック一覧表
１３ ＤＵＴ入出力制約条件
１４ プロパティライブラリ
１５ ＤＵＴ内部構成表
１６ 内部ブロック入出力制約条件
１７ 動的シミュレーションログ
１８ 内部ブロックプロパティ
２１ 動的シミュレーション
２２ 内部構成・内部ブロック入出力条件抽出器
２３ 内部ブロックプロパティ生成器
３１ プロパティ生成手順
３２ 内部表現変換器
３３ 比較器
３４ 内部ブロック入出力制約条件生成器

Claims (7)

1. 論理システムを検証する検証方法であって、
   前記論理システムの内部構成を抽出する抽出工程と、
   前記論理システムの入出力制約条件を生成する入出力制約条件生成工程と、
   前記論理システムを動的シミュレータで実行し、該動的シミュレーションの実行状態を記録する動的シミュレーション実行工程と、
   前記論理システムの内部構成、前記入出力制約条件、及び前記動的シミュレーションの実行状態に基づいて前記論理システムの動作を定義するプロパティを生成し、そのプロパティに基づいて前記論理システムの論理検証を行う検証工程とを有することを特徴とする検証方法。
2. 前記抽出工程では、論理システムの動作仕様を規定する既知の機能ブロックを参照し、前記論理システムの内部構成を抽出することを特徴とする請求項１記載の検証方法。
3. 前記入出力制約条件は、前記機能ブロックの間の入出力信号の接続に関する条件であることを特徴とする請求項２記載の検証方法。
4. 前記動的シミュレーション実行工程では、前記論理システムの実行値及び期待値を時刻と共に記録することを特徴とする請求項１記載の検証方法。
5. 論理システムを検証する検証装置であって、
   前記論理システムの内部構成を抽出する抽出手段と、
   前記論理システムの入出力制約条件を生成する入出力制約条件生成手段と、
   前記論理システムを動的シミュレータで実行し、該動的シミュレーションの実行状態を記録する動的シミュレーション実行手段と、
   前記論理システムの内部構成、前記入出力制約条件、及び前記動的シミュレーションの実行状態に基づいて前記論理システムの動作を定義するプロパティを生成し、そのプロパティに基づいて前記論理システムの論理検証を行う検証手段とを有することを特徴とする検証装置。
6. 請求項１乃至請求項４の何れか一項記載の検証方法をコンピュータに実行させるためのプログラム。
7. 請求項６記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images