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

Abstract

【課題】 検証対象の内部仕様を漏れなく定義することなく、外端の仕様のみが定義された検証対象に対して、擬似エラーの発生を抑止し、検証精度を向上させる。
【解決手段】 内部構成抽出器２１で論理システム（ＤＵＴ）１１の内部構成を抽出し、内部ブロック入出力制約条件生成器２２でＤＵＴ内部構成表１３により内部構成の入出力制約条件を生成する。そして、論理システム１１の仕様を表すプロパティを検証用のプロパティに基づいて検証を行い、検証したプロパティの反例１６と矛盾する入出力制約条件１４を検証用の更新プロパティ１７に追加して更新する。
【選択図】 図１

Description

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

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

ＬＳＩを含む論理システムの検証方法には、検証対象の外端仕様のみ着目するブラックボックス検証と、検証対象の外端仕様と内部仕様の双方に着目するホワイトボックス検証がある。ブラックボックス検証では、検証対象の外端仕様のみを用いてテストを記述している。このテストは検証対象の内部構成や仕様に依存しないため、流用性や可読性が高く、取りまわしが便利である。しかし、ブラックボックス検証は検証対象の内部状態を考慮しないため、検証対象が取り得る状態を全て実現することも、実施したか確認することも困難である。

一方、ホワイトボックス検証は、検証対象の内部仕様も併せて使用して検証を行うため、ブラックボックス検証に比較して検証対象が取り得る全事象を実施したか確認することが容易である。更に、検証対象が取り得る状態を全て実現することも容易である。但し、検証対象の内部仕様を漏れなく定義することは困難である。

従来、ＬＳＩを含む論理システムの検証には、ブラックボックス検証方法に基づく動的検証が用いられてきた。この検証方法は、論理シミュレータを用いて論理システムを動作させて検証を実施する。ここで使用するテストは、検証対象の外端仕様のみ用いて記述し、検証対象の内部仕様や構成に依存しない。そのため、この検証方法のテストは、流用性や可読性が高く、便利である。しかし、ブラックボックス検証であるため、検証対象が取り得る状態を全て実現することと、実施したか確認することが困難である。従って、この検証方法の検証精度が低いことは否めない。

この課題を解決するためにいくつかの方法が提案されている。論理システムの動作仕様と論理システムの設計データの等価性を数学的に判定することで検証を行うプロパティ検証もその一つである（例えば、特許文献１参照）。プロパティ検証では、論理システムの動作仕様をプロパティとして定義し、このプロパティと論理システムの設計データの等価性を判定する。ここで、双方が一致しない場合、プロパティを満たさない変数値の一例を、反例として出力する。
特開2001-318959号公報

しかしながら、プロパティ検証方法では、動作仕様を正確に記述しないと正しく検証を行うことができない。また、動作仕様を記述した範囲のみが検証対象であり、動作仕様が記述していなければ検証対象にすらならない。

例えば、図２に示す機能ブロック３１に対してプロパティ検証を適用することを考える。ここで、機能ブロック３１内のカウンタ３２の仕様が誤って仕様書に記載されていたとする。この仕様書に基づきカウンタ３２の動作仕様を記述してプロパティ検証を用いると、検証結果が誤ったものとなり、仕様と異なるカウンタになってしまう。また、仕様書の記載が正しくても、動作仕様を記述する際に解釈を誤り間違った動作仕様を記述すると、同じく検証結果が誤る。或いは、機能ブロック３１の仕様書にＦＳＭ（Finite State Machine）３３の記述が無かったとする。この場合、ＦＳＭ３３の動作仕様を記述することはなく、ＦＳＭ３３の検証は実施されない。その結果、ＦＳＭ３３に誤りがあっても発見できない。

更に、論理システムの設計者が、意図せず機能ブロックや機能ブロック内の部品を作り込んでしまうことがある。例えば、信号Ａが有効な場合に機能Ａを選択肢、信号Ａが無効で、かつ信号Ｂが有効な場合には機能Ｂを選択するセレクタを設計したとする。そして、このセレクタはアービタ機能も併せて持っているものとする。

しかし、論理システムの設計者はアービタを設計しようと意図していたとは限らない。そのため、仕様書にはアービタの記載が無く、このような場合、アービタとしての検証は実施されない。

ここで挙げた問題点を解決するためには、プロパティ検証をホワイトボックス検証方法に基づき実施する必要がある。反対に、ブラックボックス検証に基づきプロパティ検証を実施すると、動作仕様を満たさない反例を多く検出する。この反例のうち多くは、本来は取り得ない状態、即ち擬似エラーである。内部仕様が曖昧なため、動作仕様に本来含めるべき制約条件が抜けていることにより、この擬似エラーを検出してしまう。

そこで、プロパティ検証をホワイトボックス検証方法に基づき実施するには、検証対象の外端仕様のみならず、検証対象の内部仕様を漏れなく定義することが必要となる。しかし、検証対象の内部仕様まで漏れなく定義することは困難である。また、動作仕様の記述が検証対象の内部構成や仕様に依存してしまうため、流用性や可読性が悪い。このことにより、記述した動作仕様の正当性を保証できず、記述した動作仕様に誤りが無いとは言い切れない。

即ち、ブラックボックス検証方法に基づく動的検証でも、ホワイトボックス検証方法に基づくプロパティ検証でも、従来の方法では、十分な検証精度が得られるとは限らない。十分な検証精度が得られないことにより、精度を持つ論理システムを予定の期間内に完成させることができず、市場が欲するときに製品を投入できないという問題が生じる。更に、不十分な精度のまま製品を市場に投入してしまうという問題が生じる。

本発明は、検証対象の内部仕様を漏れなく定義することなく、外端の仕様のみが定義された検証対象に対して、擬似エラーの発生を抑止し、検証精度を向上させることを目的とする。

本発明は、論理システムを検証する検証方法であって、前記論理システムの内部構成を抽出する内部構成抽出工程と、前記内部構成の入出力制約条件を生成する入出力制約条件生成工程と、前記論理システムの仕様を表すプロパティを検証用のプロパティに基づいて検証を行うプロパティ検証工程と、前記プロパティ検証工程で検証したプロパティの反例と矛盾する入出力制約条件を前記検証用のプロパティに追加して更新するプロパティ更新工程とを有することを特徴とする。

本発明によれば、外端仕様のみで動作を定義した論理システムに対して、擬似エラーを解消するようにプロパティを更新する。そのため、検証対象の論理システムの内部構成や内部仕様が明確でなくとも、プロパティ検証を実施可能である。

また、検証対象の論理システムの内部構成や内部仕様に依存したプロパティを記述する必要が無いため、プロパティの流用性や可読性が向上する。

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

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

図１は、本実施形態における論理システムの検証方法を示す図である。図１において、１１は検証対象のＤＵＴ（Design Under Test）であり、Verilog 或いはＶＨＤＬなどのハードウェア記述言語で記述した論理システムの設計データである。ここで、ＶＨＤＬはVHSIC Hardware Description Languageの略である。

尚、ＤＵＴ１１の外端仕様は定義されているが、ＤＵＴ１１内部の構成や仕様は明確に定義されていなくても良い。

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

１２はＤＵＴ入出力制約条件であり、ＤＵＴ１１の入力或いは出力ポートの動作仕様を定義している。例えば、req_a と req_b 二つの入力ポートがあるとする。req_a と req_b は同時に有効にならない仕様ならば、以下の条件が、ポート req_a とポート req_b に対するＤＵＴ入出力制約条件１２になる。

a）req_a が有効ならば req_b は無効
b）req_b が有効ならば req_a は無効
２１は内部構成抽出器であり、ＤＵＴ１１からその内部構成を抽出する。１３はＤＵＴ内部構成表であり、内部構成抽出器２１で抽出されたＤＵＴ１１の内部構成を格納する。尚、このＤＵＴ内部構成表１３については、図４を用いて更に詳述する。

２２は内部ブロック入出力制約条件生成器であり、ＤＵＴ入出力制約条件１２とＤＵＴ内部構成表１３からＤＵＴ１１を構成する各ブロックの入力ポート又は出力ポートの動作仕様を求める。１４は内部ブロック入出力制約条件であり、内部ブロック入出力制約条件生成器２２で求めた動作仕様を格納する。

１５は初期プロパティであり、ＤＵＴ１１の動作仕様を予め定義したプロパティの集合である。ここで、ＤＵＴ１１は外端仕様のみで動作が定義され、内部構成や内部の仕様は不明であるため、初期プロパティ１５のプロパティはＤＵＴ１１の外端のみを用いて記述されているものとする。

２３はプロパティ選択器であり、後述する２４のプロパティ検証部が用いるプロパティを選択する。このプロパティ選択器２３は、初回は初期プロパティ１５を選択し、二回目以降は生成されたプロパティの集合、即ち後述する１７の更新プロパティを選択する。

２４はプロパティ検証部であり、プロパティ選択器２３が選択したプロパティを用いてＤＵＴ１１に対するプロパティ検証を実行する。ここで、選択されたプロパティとＤＵＴ１１が不一致の場合、このプロパティを満たさないＤＵＴ１１内の変数の値を反例１６として出力する。

尚、本実施形態では、プロパティ検証部２４のアルゴリズムに依存しない。そのため、結果として反例１６を得ることができるならば、どのアルゴリズムやツールを使用しても良い。多くのプロパティ検証で用いているアルゴリズムに充足可能性判定法（ＳＡＴ）がある。このＳＡＴを用いて反例１６を求めても良い。

ＳＡＴは、論理式の値を１’ｂ１にする変数の組み合わせが存在するか否かを判定する判定法である。プロパティとＤＵＴ１１を論理式で表し、排他的論理和をとった論理式を求める。この論理式の値が１’ｂ１になるならば、プロパティとＤＵＴ１１は不一致である。そして、この論理式の値が１’ｂ１になる変数の組が反例１６になる。このＳＡＴの解法には様々な公知技術が存在する。しかし、ＳＡＴの解法に依存した発明ではないので、どのような公知技術を用いても良い。

２５はプロパティ更新器であり、内部ブロック入出力制約条件１４と反例１６とを比較する。ここで、矛盾が存在するならば、擬似エラーと判定する。そして、反例１６と矛盾する内部ブロック入出力制約条件１４をプロパティに新たな制約条件として追加し、更新プロパティ１７を生成する。

次に、図３を用いて、図１に示す内部構成抽出器２１の構成について説明する。図３は、本実施形態における内部構成抽出器２１の構成の一例を示す図である。

図３において、１８は機能ブロック一覧表であり、論理システムを構成する部品である機能ブロックの一覧である。この機能ブロック一覧表１８は、開発する論理システム全てに対して共通に使用するものであり、個々の論理システム毎に作成するものではない。

２６はプロパティ生成手順であり、機能ブロック一覧表１８に記載の機能ブロック毎に動作を定義したプロパティを作成する。２７は内部表現変換器であり、プロパティ生成手順２６で生成されたプロパティを内部で使用する内部表現に変換する。１９はプロパティライブラリであり、プロパティ生成手順２６で生成されたプロパティと内部表現変換器２７で変換された内部表現とを対にして機能ブロック毎に保存する。

尚、プロパティライブラリ１９は、機能ブロック一覧表１８に変更が無ければ、プロパティ検証を実行する度に生成し直す必要は無い。そのため、機能ブロック一覧表１８からプロパティを生成する工程を自動化せずに、人手でプロパティを作成しても良い。勿論、プロパティ自動生成ツールの使用を妨げるものではない。

また、プロパティ検証を実行する毎に、或いは論理システム毎にプロパティライブラリ１９を生成することを妨げるものではない。

２８は内部表現変換器であり、内部表現変換器２７と同様に、ＤＵＴ１１を内部で使用する内部表現に変換する。２９は比較器であり、内部表現を使用してＤＵＴ１１とプロパティライブラリ１９のプロパティとを比較する。ここで、比較器２９でＤＵＴ１１が当該プロパティを包含していると判断したならば、当該プロパティが該当する機能ブロックの情報をＤＵＴ内部構成表１３に登録する。また、ＤＵＴ１１の内部表現で、プロパティのどの内部表現とも一致しない残りの部分は、未知のブロックとしてＤＵＴ内部構成表１３に登録する。尚、既知の機能ブロックに一致しないので，未知のブロックは未知の機能を持っている可能性がある。

ここで、機能ブロックとして８ビットダウンカウンタ（8 bit down counter）を例に、その動作を定義するプロパティの実施形態を説明する。以下に本実施形態で使用する記号を示す。

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

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

（~rst_n_in == 1'b1) ： ~rst_n_in が“１”、rst_n_in が“０”
即ち、カウンタリセット信号が有効
'(do_out) == 8'b00000000 ： 次クロックサイクルのカウンタ値が０
（enb_in == 1'b1） ： カウンタイネーブル信号が有効
即ち、カウントダウン動作
'(do_out) == do_out - 1'b1： 次クロックサイクルのカウンタ値は、
現在のカウンタ値から１を減じた値
よって、プロパティＰ−１は以下の動作記述を定義している。
「カウンタリセット信号が有効ならば、次クロックサイクルでカウンタの値は全て“０”になる」また、プロパティＰ−２は以下の動作記述を定義している。
「カウンタリセット信号が無効で、かつカウントイネーブル信号が有効ならば、次クロックサイクルのカウンタ値は、現在のカウンタから“１”を減じた値」
次に、比較器２９の内部で比較に用いられる内部表現について説明する。比較器２９で内部表現の比較を行うために、本実施形態で使用する内部表現は同一の論理関数が同一の表現にならなければならない。また、容量が大きくならず、内部表現による比較の手順が容易である必要がある。

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

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

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

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

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

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

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

比較器２９は、ＤＵＴ１１のＢＤＤとプロパティのＢＤＤの同形性を判定し、ＤＵＴ１１のＢＤＤがプロパティのＢＤＤを包含しているか否かを判断する。ＢＤＤの同形性判定アルゴリズムは、既に多くの提案が存在する。本発明は、同形性判定アルゴリズムに依存した発明ではないので、どの同形性判定アルゴリズムを用いてもよい。例えば、ある節に注目し、'1' の枝の形と '0' の枝の形を再帰的に比較することで同形性を判定する方法を用いても良い。

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

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

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

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

信号対応表１０４は、ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応と機能ブロック間の接続情報を記録する。信号対応表１０４は、プロパティ変数名１１１、デザイン変数名１１２、方向１１３、接続先１１４、接続先信号名１１５と内部ブロック入出力制約条件１４の６列からなる。尚、図４では、内部ブロック入出力制約条件１４の列名を制約条件と略記している。

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

方向１１３は機能ブロックから見た信号の方向を示している。“IN”と“OUT”の２つの状態を取る。ここで、“IN”は入力信号を示し、“OUT”は出力信号を示す。

接続先１１４及び接続先信号名１１５は、接続先及び接続先の信号名を示す。接続先がＤＵＴ内部構成表１３に登録済みの機能ブロックの場合、接続先１１４はその機能ブロック番号になる。接続先がＤＵＴ１１の入力或いは出力ポートならば“PORT”とする。またＤＵＴ１１内部に接続しているのに関わらず、ＤＵＴ内部構成表１３に登録が無い場合は未定にしておく。そして、ＤＵＴ内部構成表１３を再走査し、接続先１１４の値を確定させる。このとき、接続先が未知のブロックならば接続先１１４の値は“UKB”とする。

そして、内部ブロック入出力制約条件１４は内部ブロック入出力制約条件生成器２２で生成したＤＵＴ１１内部ブロックの入力ポート或いは出力ポートの入出力制約条件を記録している。

図５は、本実施形態における論理検証方法及び論理検証装置を用いた検証の流れの一例を示すフローチャートである。図５では、内部の構成や仕様が明らかでないＤＵＴ１１に対してプロパティ検証を実行する手順を示している。前提条件として、ＤＵＴ入出力制約条件１２と初期プロパティ１５は存在するものとする。また、この処理は、ＤＵＴ１１を入力したときから開始される。

まず、ステップＳ１００において、内部構成抽出器２１でＤＵＴ１１の内部構成を抽出し、ＤＵＴ内部構成表１３を生成する。次に、ステップＳ２００において、ＤＵＴ入出力制約条件１２とＤＵＴ内部構成表１３からＤＵＴ１１内部ブロックの入出力制約条件１４を求める。

次に、ステップＳ３００において、プロパティ選択器２３で初回の場合には初期プロパティ１５が選択され、プロパティ検証部２４でＤＵＴ１１に対するプロパティ検証を実行する。ここで、プロパティとＤＵＴ１１が一致しなければ反例１６を出力する。そして、ステップＳ４００において、プロパティ更新器２５で反例１６と内部ブロック入出力制約条件１４とを比較する。その結果、反例１６と内部ブロック入出力制約条件１４に矛盾が存在するならば、擬似エラーと判定し、ステップＳ５００に分岐する。矛盾が無ければ、反例は全て真性エラーと判断し、プロパティの検証処理を終了する。この後、真性エラーの解析を実行する。

一方、ステップＳ５００では、ステップＳ４００で発見した矛盾を起こす内部ブロック入出力制約条件１４を新しい制約条件としてプロパティに追加し、更新プロパティ１７とする。その後、ステップＳ３００に分岐し、プロパティ選択器２３で更新プロパティ１７が選択され、プロパティ検証部２４でＤＵＴ１１に対する二回目以降のプロパティ検証を実行する。そして、プロパティとＤＵＴ１１が一致しなければ反例１６を出力する。

これ以降、ステップＳ３００からステップＳ５００までの処理を繰り返す。ここでは、反例１６と内部ブロック入出力制約条件１４に矛盾がなくなるまで繰り返される。しかし、ＤＵＴ１１の動作仕様の定義が粗いと、膨大な数の擬似エラーが発生する場合もあり、矛盾の収束に時間がかかる恐れがある。

そこで、上述のような状態に陥る可能性を予見できる場合、或いは実行中に予め定めた閾値を繰り返し回数が超えた場合は、矛盾がなくなるまで繰り返さずに、打ち切る機能を備えても良い。

引き続き、図５に示す各ステップの処理をより詳しく説明する。まず、図６を用いて、ステップＳ１００の処理について詳細に説明する。図６は、ＤＵＴ１１の内部構成を抽出する手順を示すフローチャートである。

まず、ステップＳ１１０において、内部表現変換器２８を使用してＤＵＴ１１をＢＤＤに変換する。以下、変換後のＢＤＤをＢＤＤ（ＤＵＴ）とする。次に、ステップＳ１２０において、プロパティライブラリ１９から１機能ブロックと、その動作を定義する、全てのプロパティのＢＤＤを選択する。以下、このＢＤＤをＢＤＤ（プロパティ）とする。

次に、ステップＳ１３０において、比較器２９でＢＤＤ（ＤＵＴ）とステップＳ１２０で選択した全てのＢＤＤ（プロパティ）とを比較する。そして、ステップＳ１４０において、ＢＤＤ（ＤＵＴ）がＢＤＤ（プロパティ）を包含しているか否かを判定する。ここで、ＢＤＤ（ＤＵＴ）がＢＤＤ（プロパティ）を包含していると判定した場合はステップＳ１５０に分岐する。また、ＢＤＤ（ＤＵＴ）はステップＳ１２０で選択した全てのＢＤＤ（プロパティ）を包含していないと判定した場合はステップＳ１７０に分岐する。

このステップＳ１５０では、ステップＳ１２０で選択した機能ブロックの情報をＤＵＴ内部構成表１３に登録する。また、ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応を求め、併せてＤＵＴ内部構成表１３に登録する。更に、ＤＵＴ内部構成表１３内で信号名やポート名を検索し、接続情報を求め、併せてＤＵＴ内部構成表１３に登録する。そして、ステップＳ１６０において、ＢＤＤ（プロパティ）の各節に対応するＢＤＤ（ＤＵＴ）の節に登録済み印を付ける。

また、ステップＳ１７０では、プロパティライブラリ１３内に、未比較の機能ブロックが存在するか否かを終了条件として判定する。未比較の機能ブロックが存在する場合は、上述のステップＳ１２０に分岐する。また、未比較の機能ブロックが存在しない場合にはステップＳ１８０に分岐し、ＢＤＤ（ＤＵＴ）で、登録済み印がついていない節からなる部分を未知のブロックとし、ＤＵＴ内部構成表１３に登録する。また、ＢＤＤ（ＤＵＴ）で、登録済み印がついていない節をプロパティの形式に変換する。このプロパティをＰｕｋｂとする。プロパティ番号１０３には、Ｐｕｋｂと登録する。

また、未知のブロックにおいて、ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応を求めＤＵＴ内部構成表１３に登録する。更に、ＤＵＴ内部構成表１３内で信号名やポート名を検索し、未知のブロックの接続情報を求め、併せてＤＵＴ内部構成表１３に登録する。

続いて、図６に示すステップＳ１５０の処理を、図７と図８を用いて詳細に説明する。図７は、本実施形態におけるＤＵＴ内部構成表１３に登録する手順を示すフローチャートである。図８は、ＢＤＤ（ＤＵＴ）とＢＤＤ（プロパティ）の一例を示す図である。

図６に示すステップＳ１４０で、ＢＤＤ（ＤＵＴ）がＢＤＤ（プロパティ）を包含していると判明されている。ここで、図８に示すＢＤＤ（ＤＵＴ）４１は、ＢＤＤ（ＤＵＴ）全体のうち、ＢＤＤ（プロパティ）４２と同形な部分を抜き出したものである。図８では、ＢＤＤ（ＤＵＴ）４１、ＢＤＤ（プロパティ）４２とも、説明に用いる部分以外は簡略化して記述してある。

尚、以下では、８ビットのロード可能なダウンカウンタの動作を定義したプロパティを使用した場合を例に挙げて説明する。

まず、ステップＳ１５１において、ＤＵＴ内部構成表１３に一行追加し、機能ブロック番号（ｎとする）を付加する。つまり、新たな機能ブロックがＤＵＴ１１に存在することがステップＳ１４０で判明したので、ＤＵＴ内部構成表１３に一行追加する。

次に、ステップＳ１５２において、機能ブロック番号ｎの機能ブロック名１０２に機能ブロック名を記載する。機能ブロック名１０２には、機能ブロックの名称として「8 bit loadable down counter」を記載する。

そして、ステップＳ１５３において、ステップＳ１２０で選択した全てのプロパティのプロパティ番号を、機能ブロック番号ｎのプロパティ番号１０３に記載する。ここでは、８ビットのロード可能なダウンカウンタの動作を定義するプロパティのプロパティ番号を全て記載する。

次に、ステップＳ１５４において、プロパティが使用する変数（プロパティ変数）と、ＤＵＴ１１の信号名やポート名（デザイン変数）の対応を作成する。

ここで、図８を用いて、このステップＳ１５４の処理を詳しく説明する。図８ではＢＤＤ（ＤＵＴ）４１とＢＤＤ（プロパティ）４２は同形と判断されているものとする。同形のＢＤＤであるので、それぞれ対応する節が明らかになる。また、ＢＤＤ（ＤＵＴ）４１の節４３と、ＢＤＤ（プロパティ）４２の節４４は、それぞれ対応する節である。節４３はＤＵＴの信号或いはポートを示し、その名称は「do_out」である。また、節４４はプロパティ内の変数を示し、その名称は「data_out」である。節４３と節４４は対応する節なので、プロパティ変数名は「data_out」であり、それに対応するデザイン変数名は「do_out」である。プロパティ変数名（data_out） とデザイン変数名（do_out）をそれぞれ、プロパティ変数名１１１とデザイン変数名１１２に記載する。

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

このステップＳ１５５〜ステップＳ１５９の動作を詳細に説明する。図８に示すＢＤＤ（ＤＵＴ）４１の節４３は、ＢＤＤ（プロパティ）４２と同形の範囲において最終の節である。この節４３は節４５と接続している。そして、接続先の節４５は、登録済みの印が存在しない。よって、ステップＳ１５６からステップＳ１５８に分岐し、接続先１１４を未定とする。続いて、ステップＳ１５９で、節４３の接続先の信号名「di_in」を接続先変数名１１５に登録する。

一方、節４６は、ＢＤＤ（プロパティ）４２と同形の範囲において最初の節である。この節４６の接続先の節４７はＤＵＴ１１のポートである。よって、ステップＳ１５６からステップＳ１５７に分岐し、ポートを示す「PORT」を接続先１１４に記載する。続いて、ステップＳ１５９で、節４６の接続先のポート名「di_in」を接続先変数名１１５に登録する。

次に、図５に示すステップＳ２００の詳細を説明する。図９は、ＤＵＴ内部モジュールの入出力制約条件を生成する処理を示すフローチャートである。

まず、ステップＳ２１０において、ＤＵＴ内部構成表１３より接続先１１４がＰＯＲＴの変数を選択し、その接続先信号名１１５を得る。そして、ステップＳ２２０において、ステップＳ２１０で得た接続先信号名１１５でＤＵＴ入出力制約条件１２を検索し、対応する制約条件が存在するか否かを判定する。ここで、制約条件が存在する場合はステップＳ２３０に分岐し、その制約条件を内部ブロック入出力制約条件１４に登録する。また、対応する制約条件が存在しなければステップＳ２４０に分岐し、制約条件無しを意味する「−」を内部ブロック入出力制約条件１４に登録する。

次に、ステップＳ２５０において、接続先１１４がＰＯＲＴで、かつ内部ブロック入出力制約条件１４が未定の変数が存在するならば、ステップＳ２１０から繰り返す。また、接続先１１４がＰＯＲＴで、かつ、内部ブロック入出力制約条件１４が未定の変数が存在しなければ、ステップＳ２６０に分岐する。ステップＳ２６０では、内部ブロックの出力ポートがそのまま同じ内部ブロックの入力ポートに接続しているならば、その入力ポートの内部ブロック入出力制約条件１４に制約条件無しを意味する「−」を登録する。

次に、ステップＳ２７０において、制約条件無しも含め全ての入力ポートについて制約条件が定まった内部ブロックのプロパティ番号１０３に登録したプロパティに基づき内部ブロック入出力制約条件１４を用いて出力の制約条件を求める。そして、求めた制約条件を内部ブロック入出力制約条件１４に登録する。次に、ステップＳ２８０において、ステップＳ２５０で求めた出力ポートの接続先変数を接続先１１４と接続先信号名１１５から検索する。そして、接続先変数の制約条件１６にステップＳ２５０で求めた出力ポートの制約条件を追加する。但し、接続先変数の制約条件１６が制約条件無し「−」の場合は、ステップＳ２５０で求めた出力ポートの制約条件で置き換える。

次に、ステップＳ２９０において、全ての内部ブロックについて出力ポートの制約条件を求めるまで、上述のステップＳ２７０から繰り返す。全ての内部ブロックについて出力ポートの制約条件を求めたならば、この処理を終了する。

次に、図５に示すステップＳ３００の詳細を説明する。このステップＳ３００では初期プロパティ１５或いは更新プロパティ１７を用いて、ＤＵＴ１１に対してプロパティ検証部２４でプロパティ検証を実施する。初回はプロパティ選択器２３で初期プロパティ１５を選択する。二回目以降はプロパティ選択器２３で更新プロパティ１７を選択する。

尚、プロパティ検証部２４は、プロパティ検証のアルゴリズムに依存したものではないので、プロパティ検証方法には何を用いても良い。

次に、図５に示すステップＳ４００の詳細を説明する。このステップＳ４００ではプロパティ更新器２５で、ステップＳ３００での結果得られた反例１６と内部ブロック入出力制約条件１４とを比較し、矛盾が存在するか否かを判定する。矛盾が生じたならば、制約条件を満たさない有り得ない状況下での現象とし、擬似エラーと判断する。擬似エラーが生じた場合はステップＳ５００でプロパティを更新する。例えば、対応する内部ブロックの入力制約条件と反例１６が以下の通りであったとする。

内部ブロック入出力制約条件：（req_a == 1’b1 && req_b == 1’b0) ||
（req_a == 1’b0 && req_b == 1’b1）
反例 ： req_a == 1’b1 && req_b == 1’b1
内部ブロック入出力制約条件１４から、req_a と req_b が同時に 1’b1 になることは無いはずである。しかし、実際には内部ブロック入出力制約条件１４と矛盾する反例１６が検出されている。内部ブロック入出力制約条件１４と矛盾していることから、この反例１６はプロパティの制約条件が不足していたため生じた擬似エラーと判断できる。

また、矛盾が存在しないならば、擬似エラーは解消したと判断し、この処理を終了する。このとき、反例１６が存在するならば、その反例１６は真性エラーである。引き続き、反例１６を解析してＤＵＴ１１のデバックを行う必要がある。

最後に、図５に示すステップＳ５００の詳細を説明する。このステップＳ５００では擬似エラー解消のために、プロパティを更新し、更新プロパティ１７を作成する。ステップＳ４００で矛盾が生じた内部ブロック入出力制約条件１４を、制約条件として該当するプロパティに追加する。

上記例では、以下の制約条件をプロパティに追加し、更新プロパティ１７とする。

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

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

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

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

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

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

本実施形態における論理システムの検証方法を示す図である。 検証対象である機能ブロックの一例を示す図である。 本実施形態における内部構成抽出器２１の構成の一例を示す図である。 本実施形態におけるＤＵＴ内部構成表１３の構成の一例を示す図である。 本実施形態における論理検証方法及び論理検証装置を用いた検証の流れの一例を示すフローチャートである。 ＤＵＴ１１の内部構成を抽出する手順を示すフローチャートである。 本実施形態におけるＤＵＴ内部構成表１３に登録する手順を示すフローチャートである。 ＢＤＤ（ＤＵＴ）とＢＤＤ（プロパティ）の一例を示す図である。 ＤＵＴ内部モジュールの入出力制約条件を生成する処理を示すフローチャートである。

符号の説明

１１ ＤＵＴ
１２ ＤＵＴ入出力制約条件
１３ ＤＵＴ内部構成表
１４ 内部ブロック入出力制約条件
１５ 初期プロパティ
１６ 反例
１７ 更新プロパティ
１８ 機能ブロック一覧表
１９ プロパティライブラリ
２１ 内部構成抽出器
２２ 内部ブロック入出力制約条件生成器
２３ プロパティ選択器
２４ プロパティ検証部
２５ プロパティ更新器
２６ プロパティ生成手順
２７ 内部表現変換器
２８ 内部表現変換器
２９ 比較器
３１ 機能ブロック
３２ カウンタ
３３ ＦＳＭ
３４ ランダム論理
３５ シーケンサ

Claims (6)

1. 論理システムを検証する検証方法であって、
   前記論理システムの内部構成を抽出する内部構成抽出工程と、
   前記内部構成の入出力制約条件を生成する入出力制約条件生成工程と、
   前記論理システムの仕様を表すプロパティを検証用のプロパティに基づいて検証を行うプロパティ検証工程と、
   前記プロパティ検証工程で検証したプロパティの反例と矛盾する入出力制約条件を前記検証用のプロパティに追加して更新するプロパティ更新工程と、
   を有することを特徴とする検証方法。
2. 前記内部構成抽出工程は、前記論理システムを論理表現に変換して、正規化論理表現を生成する工程と、
   前記論理システムの構成部品である機能ブロックに対応する動作仕様記述の正規化論理表現を記録する工程とを有し、
   前記記録した正規化論理表現と前記生成した正規化論理表現との比較を行い、前記機能ブロックの存在を判定することにより、内部構成を抽出することを特徴とする請求項１に記載の検証方法。
3. 前記入出力制約条件は、前記機能ブロックの間の入出力信号の接続に関する条件であることを特徴とする請求項２に記載の検証方法。
4. 論理システムを検証する検証装置であって、
   前記論理システムの内部構成を抽出する内部構成抽出手段と、
   前記内部構成の入出力制約条件を生成する入出力制約条件生成手段と、
   前記論理システムの仕様を表すプロパティを検証用のプロパティに基づいて検証を行うプロパティ検証手段と、
   前記プロパティ検証手段で検証したプロパティの反例と矛盾する入出力制約条件を前記検証用のプロパティに追加して更新するプロパティ更新手段と、
   を有することを特徴とする検証装置。
5. 請求項１乃至請求項３の何れか一項に記載の検証方法をコンピュータに実行させるためのプログラム。
6. 請求項５記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images