JP2007026181A - 論理検証手法および論理検証装置 - Google Patents

Abstract

【課題】 内部構成や仕様が明確でない検証対象に対し、外端の動作仕様のみを用いて検証をおこなうと検証抜けが生じ、検証精度が低下する。十分な検証精度が得られないことにより、十分な精度を持つ論理システムを予定の期間内に完成させることができず市場が欲するときに製品を投入できないという課題や不十分な精度のまま製品を市場に投入してしまう課題が生じる。
【解決手段】 機能ブロックを定義するプロパティを予め登録しておく。このプロパティを用いて検証対象の内部構成を抽出する。この内部構成から、予め登録したプロパティに一致しない部分について、入出力制約条件を求める。この入出力制約条件を用いて論理検証をおこなう。
【選択図】 図１

Description

本発明は、ハードウエア記述言語で記述した論理システムの検証に係わる。

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

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

しかし、ブラックボックス検証は検証対象の外端仕様のみで検証を実施し、検証対象の内部状態を考慮しない。そのため、検証対象が取り得る全事象を実施したか確認することが困難である。また、入力ポートに対するデータ入力のみで、検証対象が取り得る状態を全て実現することも困難である。そのため、ブラックボックス検証の検証精度が低いことは否めない。

一方、検証対象の内部構成や仕様も併せて使用して検証をおこなうホワイトボックス検証は、検証対象の内部構成や仕様も参照しているため、ブラックボックス検証に比較して検証対象が取り得る全事象を実施したか確認することが容易である。また、検証対象が取り得る状態を全て実現することも容易である。しかし、ホワイトボックス検証は、検証対象内部の構成や仕様が明確でないと実施できない。また、ホワイトボックス検証では、検証対象内部の構成や仕様を参照するので、検証対象内部の構成や仕様に合わせてテストを作成してしまう恐れがある。検証対象内部の構成や仕様に合わせて作成したテストを用いれば検証対象の出力は期待値に一致するので、検証をおこなう意味がない。

又、従来例としては、例えば特許文献１をあげることが出来る。
特開2002-368104号公報

以上のようにブラックボックス検証であってもホワイトボックス検証であっても、検証精度を低下させる要因を含んでいる。よって、従来の手法では十分な検証精度が得られるとは限らない。十分な検証精度が得られないことにより、十分な精度を持つ論理システムを予定の期間内に完成させることができず市場が欲するときに製品を投入できないという課題や不十分な精度のまま製品を市場に投入してしまう課題が生じる。

本発明は、上記課題を解決するためになされたもので、外端の仕様のみ定義された検証対象に対して、検証漏れを無くし検証精度を向上させる手段を提供する。

本発明に係わるハードウエア記述言語により記述された論理システムの検証手法および検証検証装置は、
前記ハードウエア記述言語で記述された論理システムを論理表現に変換し最適化をおこない正規化論理表現を生成する正規化論理表現生成手段と、
論理システムの構成部品である機能ブロックに対応する動作仕様記述の正規化論理表現を記録する機能ブロック保持手段と、
前記機能ブロック保持手段から正規化論理表現を選択し前記正規化論理表現生成手段で生成した正規化論理表現と比較をおこなうことで前記機能ブロックの存在を判定し、前記ハードウエア記述言語で記述された論理システムの内部構成を抽出する内部構成抽出手段と、
前記内部構成抽出手段で抽出した各ブロックの入力および出力制約条件を求める手段を具備することを特徴とする。

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

また、本発明によれば、検証対象の論理システム内に存在する機能が既知である機能ブロックの動作仕様のみを用いて内部ブロックの入出力制約条件を生成するため、検証対象内部の構成や仕様に合わせてテストを作成する恐れが無い。

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

以下、図面を参照しながら本発明の実施形態を説明する。

図１は、本発明の一実施例を示す図である。ＤＵＴ１１はVerilog あるいはVHDL で記述した論理システムの設計データである。本発明により、このＤＵＴ１１の論理検証をおこなう。機能ブロック一覧表１２は、論理システムを構成する部品である機能ブロックの一覧である。この機能ブロック一覧表１２は、開発する論理システム全てに対して共通に使用するものであって、個々の論理システムごとに作成するものではない。ＤＵＴ入出力制約条件１５は、ＤＵＴ１１の入力および出力の動作を定義する。

機能ブロック一覧表１２に記載の機能ブロック毎に、動作を定義したプロパティをプロパティ生成手順３１で作成し、内部表現変換器２２で本発明の内部で使用する内部表現に変換する。そして、プロパティと内部表現を対にして機能ブロック毎にプロパティ・ライブラリ１３として保存する。プロパティ・ライブラリ１３は機能ブロック一覧表１２に変更が無ければ、テスト毎に生成しなおす必要は無い。そのため、機能ブロック一覧表１２からプロパティを生成する工程を自動化せず、人手でプロパティを作成してもよい。勿論、プロパティ自動生成ツールの使用を妨げるものではない。また、テストを実行するたび、あるいは論理システムごとにプロパティ・ライブラリ１３を生成することを妨げるものではない。

内部表現変換器２１はＤＵＴ１１を本発明の内部で使用する内部表現に変換する。比較器２３は内部表現を使用して、ＤＵＴ１１とプロパティ・ライブラリ中のプロパティを比較する。比較器２３で、ＤＵＴ１１が当該プロパティを包含していると判断したならば、当該プロパティが該当する機能ブロックの情報をＤＵＴ内部構成表１４に登録する。ＤＵＴ１１の内部表現中、どのプロパティの内部表現とも一致しない残りの部分は、ＵＮＫＮＯＷＮ ＢＬＯＣＫとしてＤＵＴ内部構成表１４に登録する。既知の機能ブロックに一致しないので，ＵＮＫＮＯＷＮ ＢＬＯＣＫは未知の機能を持っている可能性がある。

ＤＵＴ入出力制約条件１５とＤＵＴ内部構成表１４からＵＮＫＮＯＷＮ ＢＬＯＣＫおよび各機能ブロックの入力と出力の制約条件を内部ブロック入出力制約条件生成器２４で生成する。以下、特に区別する必要が無い限り入力と出力の制約条件を合わせて入出力制約条件と呼ぶ。生成した入出力制約条件を内部ブロック入出力制約条件１６として保存する。但し、常に内部ブロック入出力制約条件生成器２４は、ＵＮＫＮＯＷＮ ＢＬＯＣＫを含めた全ての機能ブロックについて入出力制約条件を生成しなければならないわけではない。内部ブロック入出力制約条件生成器２４が生成する入出力制約条件１６は、内部ブロック入出力制約条件１６の使用目的によって変化する。例えば、ＵＮＫＮＯＷＮ ＢＬＯＣＫに注目して検証をおこなう場合、ＵＮＫＮＯＷＮ ＢＬＯＣＫの入出力制約条件と、ＵＮＫＮＯＷＮ ＢＬＯＣＫと依存関係のある機能ブロックの入出力制約条件を求めるだけでよい。

次に、8 bit down counterの動作を定義するプロパティを例にとり、プロパティの一実施例を説明する。以下に本実施例で使用する記号を示す。

; 動作記述の区切り
a=>b aが成立するならばbが成り立つ
&& 論理積
|| 論理和
~ 論理否定
' 次クロック・サイクルの状態
// コメント
== 論理等価
1'b1 ２進数一桁、値は'1'
rst_n_in カウンタ・リセット信号('0'でリセット)
do_out カウンタ値出力(8bit)
enb_in カウンタ・イネーブル信号('1'でカウントダウン,'0'で保持)
以下に示すプロパティは、8 bit down counterの動作を定義するプロパティの一部である。
(~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が'1'、つまりrst_n_inが'0'、
すなわちカウンタ・リセット信号が有効
'(do_out)==8'b00000000 ： 次クロック・サイクルのカウンタ値が0
(enb_in==1'b1) ：カウンタ・イネーブル信号が有効
すなわち、カウントダウン動作
'(do_out)==do_out-1'b1 ： 次クロック・サイクルのカウンタ値は、
現在のカウンタ値から 1 減じた値
よって、プロパティP-1 は以下の動作記述を定義している。

「カウンタ・リセット信号が有効ならば、
次クロック・サイクルでカウンタの値は全て0になる」
また、プロパティP-2 は以下の動作記述を定義している。

「カウンタ・リセット信号が無効で、かつカウント・イネーブル信号が有効ならば、
次クロック・サイクルのカウンタ値は、現在のカウンタから1減じた値」
次に、本発明で用いる内部表現について説明する。比較器２３で内部表現の比較をおこなうため、本発明で使用する内部表現は同一の論理関数が同一の表現にならなければならない。また、容量が大きくならず、内部表現による比較の手順が容易である必要がある。同一の論理関数が同一の表現となる表現方法として、ＢＤＤ（Binary Decision Diagram）、真理値表、積和標準形がある。真理値表は入力数の指数乗の項数を必要とする。また、積和標準形も最悪の場合、真理値表と同じく入力数の指数乗の項数を必要とする。しかし、ＢＤＤでは多くの場合、真理値表や積和標準形より少ない項数で論理関数を表現可能である。また、真理値表と積和標準形では、内部表現への変換工数が論理関数の複雑度に影響し、複雑になるにつれて内部表現への変換工数が増加する。一方、ＢＤＤでは論理関数の複雑度に関係なく変換工数がきまる。そのため、本実施例では、内部表現としてＢＤＤを用いることとする。勿論、内部表現をＢＤＤに限定するのものではなく、同一の論理関数が同一の表現になるならばどのような表現を用いてよい。

ＢＤＤを内部表現に使用するプログラムや市販のツールでは、ＢＤＤ生成アルゴリズムとして、applyアルゴリズムが広く使用されている。このapplyアルゴリズムは1984年にRandal E. Bryant氏により開発された、ＢＤＤ生成アルゴリズムである。このapplyアルゴリズムは、既に数多く使用されており、公知の技術である。そこで、内部表現変換器２１はＤＵＴ１１をＢＤＤに変換する手法として、また内部表現変換器２２は機能ブロックのプロパティをＢＤＤに変換する手法として、applyアルゴリズムを使用する。ただし、本発明は、ＢＤＤ生成アルゴリズムに依存した発明ではないので、内部表現変換器２１、および内部表現変換器２２が使用するアルゴリズムをapplyアルゴリズムに限定するものではない。

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

図２は、本発明による論理検証手法および論理検証装置を用いた検証の流れの一例を説明するフローチャートである。図２に示すフローチャートは、本発明による論理検証手法および論理検証装置を用い、より詳細にＵＮＫＮＯＷＮ ＢＬＯＣＫの検証をおこなう手順を示している。前提条件として、ＤＵＴ１１内に機能が未知であるＵＮＫＮＯＷＮ ＢＬＯＣＫが存在し、プロパティ・ライブラリ１３は予め生成してあるとする。図２の処理は、ＤＵＴ １１を入力したときから開始される。
ステップＳ１００：
プロパティ・ライブラリ１３内の情報を基にＤＵＴ１１の内部構成を求め、ＤＵＴ内部構成表１４を生成
ステップＳ２００：
ＤＵＴ内部構成表１４の情報を基にＤＵＴ入出力制約条件１５からＵＮＫＮＯＷＮ ＢＬＯＣＫの入出力制約条件を生成
本実施例ではＵＮＫＮＯＷＮ ＢＬＯＣＫに注目しているのでＵＮＫＮＯＷＮ ＢＬＯＣＫの入出力制約条件を生成。
ステップＳ３００：
ステップＳ２００の結果を使用してＵＮＫＮＯＷＮ ＢＬＯＣＫを検証
ＵＮＫＮＯＷＮ ＢＬＯＣＫの検証には動的シミュレーション手法を用いても、静的検証手法を用いてもよい。

引き続き、図２中の各ステップの動作を詳しく説明する。図３は、ステップＳ１００の動作を詳しく説明するフローチャートである。図３を用いて、ＤＵＴ１１の内部構成を抽出する手順を説明する。
ステップＳ１１０：
内部表現変換器２１を使用してＤＵＴ１１をＢＤＤに変換
以下、変換後のＢＤＤをＢＤＤ（ＤＵＴ）と呼ぶ
ステップＳ１２０：
プロパティ・ラブラリ１３から１機能ブロックと、その動作を定義する全てのプロパティのＢＤＤを選択
以下、このＢＤＤをＢＤＤ（ｐｒｏｐｅｒｔｙ）と呼ぶ
ステップＳ１３０〜ステップＳ１４０：
比較器２３でＢＤＤ（ＤＵＴ）がＢＤＤ（ｐｒｏｐｅｒｔｙ）を包含しているかを判定
ＢＤＤ（ＤＵＴ）はステップＳ１２０で選択した全てのＢＤＤ（ｐｒｏｐｅｒｔｙ）を包含している：ステップＳ１５０に分岐
ＢＤＤ（ＤＵＴ）はステップＳ１２０で選択した全てのＢＤＤ（ｐｒｏｐｅｒｔｙ）を包含していない：ステップＳ１７０に分岐
ステップＳ１５０：
Ａ）ステップＳ１２０で選択した機能ブロックの情報をＤＵＴ内部構成表１４に登録
Ｂ）ＤＵＴ１１の信号名やポート名とプロパティ内の変数との対応を求め、
併せてＤＵＴ内部構成表１４に登録
Ｃ）ＤＵＴ内部構成表１４内で信号名やポート名を検索し、接続情報を求め、
併せてＤＵＴ内部構成表１４に登録
ステップＳ１６０：
ＢＤＤ（ｐｒｏｐｅｒｔｙ）の各節に対応するＢＤＤ（ＤＵＴ）の節に登録済み印をつける
ステップＳ１７０：
終了条件を判定
プロパティ・ライブラリ１３内に、
未比較の機能ブロックが存在 ：ステップＳ１２０に分岐
未比較の機能ブロックが存在しない ：ステップＳ１８０に分岐
ステップＳ１８０：
Ａ）ＢＤＤ（ＤＵＴ）で、登録済み印がついていない節からなる部分を
ＵＮＫＮＯＷＮ ＢＬＯＣＫとする
ＵＮＫＮＯＷＮ ＢＬＯＣＫは、登録済みの機能ブロックに一致しない部分であり、未知の機能を含んでいる可能性がある
Ｂ）ＵＮＫＮＯＷＮ ＢＬＯＣＫにおいて、ＤＵＴ１１の信号名やポート名と
プロパティ内の変数との対応を求めＤＵＴ内部構成表１４に登録
Ｃ）ＤＵＴ内部構成表１４内で信号名やポート名を検索し、
ＵＮＫＮＯＷＮ ＢＬＯＣＫの接続情報を求め併せてＤＵＴ内部構成表１４に登録
次に、ＤＵＴ内部構成表１４の実施例を説明する。ＤＵＴ内部構成表１４の一実施例を図４に示す。図４に示すＤＵＴ内部構成表１４は４列からなる。左から、機能ブロック番号１０１、機能ブロック名１０２、プロパティ番号１０３、信号対応表１０４である。信号対応表列１０４は、さらに５列に分かれている。ＤＵＴ内部構成表１４は、新しい機能ブロックを登録するたびに一行ずつ増加する。

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

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

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

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

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

方向１１３は機能ブロックからみた信号の方向を示している。"IN"と"OUT"の二状態を取る。"IN"は入力信号を、"OUT"は出力信号を示す。

接続先１１４と接続先信号名１１５は、接続先と接続先の信号名を示す。接続先がＤＵＴ内部構成表１４に登録済みの機能ブロックならば、接続先１１４はその機能ブロック番号になる。接続先がＤＵＴ１１の入力あるいは出力ポートならば"PORT"とする。ＤＵＴ１１内部に接続しているのに関わらず、ＤＵＴ内部構成表１４に登録が無い場合は未定にしておく。そして、図３中のステップS１８０で、ＤＵＴ内部構成表１４を再走査し、接続先１１４の値を確定させる。このとき、接続先が、ＵＮＫＮＯＷＮ ＢＬＯＣＫならば接続先１１４の値は"UNKNOWN BLOCK"とする。

続いてステップＳ１５０の動作を、図５と図６を用いて詳細に説明する。図５はステップＳ１５０の動作をくわしく説明するフローチャートである。図６はＢＤＤ（ＤＵＴ）とＢＤＤ（ｐｒｏｐｅｒｔｙ）の一例である。図３のステップＳ１４０で、ＢＤＤ（ＤＵＴ）３１は、ＢＤＤ（ｐｒｏｐｅｒｔｙ）３２を包含していると判明している。ＢＤＤ（ＤＵＴ）３１は、ＢＤＤ（ＤＵＴ）全体のうち、ＢＤＤ（ｐｒｏｐｅｒｔｙ）３２と同形な部分を抜き出したものである。ＢＤＤ（ＤＵＴ）３１、ＢＤＤ（ｐｒｏｐｅｒｔｙ）３２とも、説明に用いる部分以外は簡略化して記述してある。

以下の説明では、8 bit loadable down counterの動作を定義したプロパティを使用した場合を例に取る。
ステップＳ１５１：
ＤＵＴ内部構成表１４に一行追加し、機能ブロック番号を附加（nとする）
新たな機能ブロックがＤＵＴ１１に存在することがステップＳ１４０で判明したのでＤＵＴ内部構成表１４に一行追加する。
ステップＳ１５２：
機能ブロック名を機能ブロック番号 n の機能ブロック名１０２に記載
機能ブロック名１０２には、機能ブロックの名称"8 bit loadable down counter"を記載する。
ステップＳ１５３：
ステップＳ１２０で選択した全てのプロパティのプロパティ番号を、機能ブロック番号nのプロパティ番号１０３に記載
8 bit loadable down counterの動作を定義するプロパティのプロパティ番号を全て記載
ステップＳ１５４：
プロパティが使用する変数（プロパティ変数）と、
ＤＵＴ１１の信号名やポート名（デザイン変数）の対応を作成
図６を用いてステップＳ１５４の動作を詳しく説明する。図６中、ＢＤＤ（ＤＵＴ）３１とＢＤＤ（ｐｒｏｐｅｒｔｙ）３２は同形と判断されているとする。同形のＢＤＤであるので、それぞれ対応する節が明らかになる。図６中ＢＤＤ（ＤＵＴ）３１の節３３と、ＢＤＤ（ｐｒｏｐｅｒｔｙ）３２の節３４は、それぞれ対応する節である。節３３はＤＵＴの信号あるいはポートを示しており、その名称は"do_out"である。また、節３４はプロパティ内の変数を示しており、その名称は"data_out"である。節３３と節３４は対応する節なので、プロパティ変数名は"data_out"であり、それに対応するデザイン変数名は"do_out"である。プロパティ変数名（"data_out"）とデザイン変数名（"do_out"）をそれぞれ、プロパティ変数１１１とデザイン変数１１２に記載する。
ステップＳ１５５〜ステップＳ１５９：
接続先と接続先信号名を求め、接続先１１４と接続先信号名１１５に記載
接続先がポート以外で、 ＤＵＴ内部構成表１４に未登録ならば、接続先は未定
図６を用いてステップＳ１５５〜ステップＳ１５９の動作を説明する。図６中、ＢＤＤ（ＤＵＴ）３１の節３３は、ＢＤＤ（ｐｒｏｐｅｒｔｙ）３２と同形の範囲において最終の節である。この節３３は節３５と接続している。そして接続先の節３５は登録済みの印が存在しない。よって、ステップＳ１５６７に分岐し、接続先１１４は未定にする。続いてステップ１５９で、節３３の接続先の信号名 "di_in" を接続先変数名１１５に登録する。一方、節３６は、ＢＤＤ（ｐｒｏｐｅｒｔｙ）３２と同形の範囲において最初の節である。節３６の接続先の節３７はＤＵＴ１１のポートである。よって、ステップＳ１５５では、ステップＳ１５６に分岐し、ポートを示す"PORT"を接続先１１４に記載する。続いてステップ１５９で、節３６の接続先のポート名"di_in"を接続先変数名１１５に登録する。

続いて、ステップＳ２００の動作を図７を用いて説明する。本実施例で使用するＤＵＴ１１の構造を図８に示す。図８は説明に必要ない部分は省略して記述してある。本実施例では、ＢＬＯＣＫ５２の外端信号のうち、cnt_in６１の生成手順を説明する。それ以外の信号についても入出力制約条件の生成手順は同じである。図８に示すように、このcnt_in６１はカウンタ５１のdo_out６２に接続している。リセット信号rst_n_in６３はＤＵＴ１１のポート、rst_sync_n_in６４に接続している。また、カウンタ５１の制御信号、enb_in６６は、ＵＮＫＮＯＷＮ ＢＬＯＣＫ５２のcnt_enb_out６５に接続している。以下、説明にあたり適宜、図４も用いる。なお、ＤＵＴ１１の外端ポートは制約条件を持たないとする。
ステップＳ２１０：
ＤＵＴ 内部構成表１４から、ＵＮＫＮＯＷＮ ＢＬＯＣＫ５２の外端信号を取り出す
ＵＮＫＮＯＷＮ ＢＬＯＣＫ５２の外端信号のリストは以下のとおり
(cnt_in, rst_n_in, cc_out, ld_cmd_out, cnt_enb_out, state_in,...)
ステップＳ２２０：
引数から変数をひとつ取り出す
その接続先信号名とプロパティをＤＵＴ内部構成表１４から検索
ＤＵＴ内部構成表１４を参照すると、先頭の変数、cnt_inは、接続先がn、すなわち8 bit loadable down counter（カウンタ５１）であり、その接続先名はdo_outである。

do_outの動作を定義したプロパティをプロパティ・ライブラリ１３から取り出す。

このプロパティの一部を以下に示す。

(~rst_n_in==1'b0)=>
'(do_out)==8'b00000000; //P-1
(~rst_n_in==1'b1)&&(enb_in==1'b1)=>
'(do_out)==do_out-1'b1; //P-2
ステップＳ２３０：
プロパティが存在しないならば、ステップＳ２３５へ分岐
ステップＳ２４０：
ステップＳ２１０で取り出したプロパティ中の接続先変数名を、
Ｓ２２０で選択した変数で置換
(~rst_n_in==1'b0)=>
'(cnt_in)==8'b00000000; //P-3
(~rst_n_in==1'b1)&&(enb_in==1'b1)=>
'(cnt_in)==cnt_in-1'b1; //P-4
ステップＳ２５０：
プロパティにカウンタ５１の外端信号（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)//P-5
ステップＳ２７０：
まだ引数が残っているので、ステップＳ２２０へ戻る
ステップＳ２１０：
引数から変数をひとつ（enb_in）取り出す
enb_inの接続先信号名とプロパティをＤＵＴ内部構成表１４から検索
ＤＵＴ内部構成表１４を参照すると、カウンタ５１のenb_inの接続先は、UNKNOWN BLOCK で、接続先信号名はcnt_enb_out。ＵＮＫＮＯＷＮ ＢＬＯＣＫなのでプロパティは存在しない。
ステップＳ２３０：
プロパティが存在しないためステップＳ２３５へ分岐
ステップＳ２３５：
接続先信号のみのプロパティを作成
(cnt_enb_out)//P-6
ステップＳ２７０：
引数は終了したので、このルーチンは終了
ステップＳ２７５：
ステップＳ２３５に戻り、戻り値は、
(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; //P-7
(~rst_sync_n_in==1'b1)&&(cnt_enb_out ==1'b1)=>
'(cnt_in)==cnt_in-1'b1; //P-8
ステップＳ２６０：
プロパティP-1とＰ-2には、ＤＵＴ１１のポート信号（rst_sync_n_in）が存在
ステップＳ２６５へ分岐
ステップＳ２６５：
本実施例では、ＤＵＴ１１の外端ポートは制約条件を持たないので、
プロパティは変更なし
ステップＳ２７０：
引数は終了したのでステップＳ２７５へ分岐
ステップＳ２７５：
求めたプロパティを出力し、終了
(~rst_sync_n_in==1'b0)=>
'(cnt_in)==8'b00000000; //P-9
(~rst_sync_n_in==1'b1)&&(cnt_enb_out==1'b1)=>
'(cnt_in)==cnt_in-1'b1; //P-10
このプロパティがＵＮＫＮＯＷＮ ＢＬＯＣＫ５２の入出力制約条件になる。

次にステップＳ３００の動作を説明する。ステップＳ３００ではステップＳ２００で求めた入出力制約条件を使用して論理検証を実行する。論理検証には、論理シミュレータを使用した動的検証と、数学的に判定する静的検証のどちらを用いてもよい。動的検証を用いる場合は、ステップＳ２００で求めた入出力制約条件から、アサーションやテンポラルを作成し、テストベンチに組み込んでシミュレーションを実行する。アサーションやテンポラルを記述する検証用言語は複数存在するが、本発明は言語仕様に依存しないためどの検証用言語を用いてもよい。一方、静的検証を用いる場合は、ステップＳ２００で求めた入出力制約条件を用いて静的検証を実行する。静的検証の場合も複数の言語が存在するがどの言語を用いてもよい。また、本発明は動的検証か静的検証のどちらかのみ使用に限ったものではないので、検証対象により使用する検証手法を変えてもよいし、同じ検証対象に対して動的検証と静的検証の双方を組み合わせて使用してもよい。

本発明の一実施例を示す図である。 本発明による検証手順の一実施例を示す図である。 本発明による内部構成抽出手順の一実施例を示す図である。 ＤＵＴ内部構成表の一実施例を示す図である。 本発明による内部構成抽出手順の一実施例を示す図である。 ＢＤＤの同形性判定手法を説明する図である。 本発明による入出力制約条件生成手順の一実施例を示す図である。 ＤＵＴの一例を示す図である。

符号の説明

１１ ＤＵＴ
１２ 機能ブロック一覧表
１３ プロパティ・ライブラリ
１４ ＤＵＴ内部構成表
１５ ＤＵＴ入出力制約条件
１６ 内部ブロック入出力制約条件
２１ 内部表現変換器（ＨＤＬ用）
２２ 内部表現変換器（プロパティ用）
２３ 比較器
２４ 内部ブロック入出力制約条件生成器
３１ ＢＤＤ（ＤＵＴ）
３２ ＢＤＤ（ｐｒｏｐｅｒｔｙ）
３３〜３７ ＢＤＤの節
５１ カウンタ（8 bit loadable down counter）
５２ ＵＮＫＮＯＷＮ ＢＬＯＣＫ
６１ cnt_in
６２ do_out
６３ rst_n_in
６４ rst_sync_n_in
６５ cnt_enb_out
６６ enb_in
７１ プロパティ
１０１ 機能ブロック番号
１０２ 機能ブロック名
１０３ プロパティ番号
１０４ 信号対応表
１１１ プロパティ変数名
１１２ デザイン変数名
１１３ 方向
１１４ 接続先
１１５ 接続先信号名

Claims (1)

1. ハードウエア記述言語により記述された論理システムの検証装置において、
   前記ハードウエア記述言語で記述された論理システムを論理表現に変換し最適化をおこない正規化論理表現を生成する正規化論理表現生成手段と、
   論理システムの構成部品である機能ブロックに対応する動作仕様記述の正規化論理表現を記録する機能ブロック保持手段と、
   前記機能ブロック保持手段から正規化論理表現を選択し前記正規化論理表現生成手段で生成した正規化論理表現と比較をおこなうことで前記機能ブロックの存在を判定し、前記ハードウエア記述言語で記述された論理システムの内部構成を抽出する内部構成抽出手段と、
   前記内部構成抽出手段で抽出した各ブロックの入力および出力制約条件を求める手段を具備することを特徴とする、ハードウエア記述言語により記述された論理システムの検証装置。

Images