JP2006309576A - 論理システムの検証装置及び検証方法、記憶媒体及びコンピュータプログラム - Google Patents

Abstract

【課題】 動的シミュレーションの際に発見されたエラー原因の解析工数を削減することを目的とする。
【解決手段】 ハードウェア記述言語により記述された論理システムの検証装置であって、動的シミュレーションを実行するテストベンチ作成手段と、静的検証を実行する静的検証手段と、前記動的シミュレーションと前記静的検証の結果から、エラー箇所を特定するエラー箇所特定手段を具備することを特徴とする論理システムの検証装置等、を提供する。
【選択図】 図１

Description

本発明は、ハードウェア記述言語で記述した論理システムの検証装置等に関し、例えば、動的シミュレーションの際に発見されたエラー原因を解析するために用いて好適な技術に関する。

従来、近年、市場はより高機能な製品を要求している。これに伴い、ＬＳＩを含む論理システムの規模は年々増加している。そのため、論理システムの検証には膨大な時間が必要となってきている。また、市場には消費者が欲するときに製品を投入しなければならず、ＬＳＩをはじめとした論理システムの開発期間は短くなっている。そのため、論理システムの検証効率向上を図る必要性が生じている。

ＬＳＩを含む論理システムの検証には、従来から使用されている動的シミュレーション手法と併せて静的検証手法を用いるようになってきた。動的シミュレーション手法とは、ＤＵＴ（検証対象）を実際にシミュレータにより動作させ検証をおこなうものである。静的検証はプロパティチェックと等価性チェックの二種類に分けられる。本発明において、静的検証はプロパティチェックを取り扱うこととする。プロパティチェックはプロパティと呼ばれる仕様を数式で表わしたものと、ＤＵＴとの一致性を数学的に判定することで検証をおこなう。このとき静的検証においてシミュレータは不要である。

動的シミュレーションでは主にランダム手法が用いられ、事象を乱数で発生させて検証をおこなう。これは広範囲の検証が可能であるが、一方でランダムに事象を発生させているために全ての事象を発生させることは不可能に近く、また検証精度を向上させるためには複数のシミュレーションを実施し、より多くの事象を発生させなければならないので長い検証時間を必要とする。

一方で静的検証はその性質上、プロパティ記述が可能な検証項目に対しては網羅検証が可能で、またシミュレータを必要としないために検証時間が大変短いが、プロパティ記述が不可能である検証項目に対しては、まったく検証不可能である。そのため検証精度の向上、検証工数の削減のためには、動的シミュレーションと静的検証手法の併用が不可欠である。

以上のように、動的シミュレーションと静的検証の併用は不可欠であるが、動的シミュレーションを実施するにはテストベンチの構築に多くの工数が必要となる。また開発期間内にテストベンチの検証を完璧に行うことも難しく、テストベンチにバグが混入しているままＤＵＴの検証を始めてしまう恐れがある。このためテストベンチ構築後、実際にＤＵＴを用いてシミュレーションを開始した後にエラーが発見された場合、必ずしもＤＵＴのバグではなくテストベンチ構築の際に発見できなかったテストベンチのバグである可能性もある。このことにより、動的シミュレーションにおいてエラーが検出された場合、エラーの原因がＤＵＴにあるのかテストベンチにあるのかを特定することが難しくエラー解析に多くの工数を有するという問題がある。

また近年ではテストベンチの再利用性を高める動きも出ている。テストベンチを再利用しているにもかかわらず、依然としてテストベンチにバグが潜んでいる可能性は捨てきれない。また、誤ったテストベンチを使用することによりＤＵＴのバグを見逃してしまう恐れもある。

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

本発明は前述の問題点にかんがみ、動的シミュレーションの際に発見されたエラー原因の解析工数を削減する手段を提供する。

本発明の論理システムの検証装置は、ハードウェア記述言語により記述された論理システムの検証装置であって、動的シミュレーションを実行するテストベンチ作成手段と、静的検証を実行する静的検証手段と、前記動的シミュレーションと前記静的検証の結果から、エラー箇所を特定するエラー箇所特定手段を具備することを特徴とする。

本発明の論理システムの検証方法は、ハードウェア記述言語により記述された論理システムの検証手法であって、動的シミュレーションを実行するテストベンチ作成工程と、静的検証を実行する静的検証工程と、前記動的シミュレーションと前記静的検証の結果から、エラー箇所を特定するエラー箇所特定工程を具備することを特徴とする。

本発明によれば、動的シミュレーションにおいて困難であったエラー箇所の特定が可能となる。これによりバグ原因の切り分けが容易になり、テストベンチのバグを取り除くことが出来るようになり、テストベンチの不備によってＤＵＴのバグが隠蔽されることが防げる。

その結果、本発明によれば、テストベンチのバグを正確に取り除くことによってテストベンチの再利用性を向上することが可能となる。またテストベンチの再利用性を向上させることにより、検証工数の削減を図ることが可能となる。その結果、十分な精度を持つ論理システムを予定の期間内に完成させることができ、市場が欲するときに製品を投入することが可能となる。

（第１の実施の形態）
以下、図面を参照しながら本発明の実施の形態を説明する。
図１は本実施の形態を実現するための検証装置の一例を示す図である。以下、順をおって説明する。
ＤＵＴ仕様０１は、設計データの仕様が記載されているデータである。この仕様は自然言語その他、いかなる言語で記述されていてもかまわない。また、本実施の形態においてはいかなる場合においてもＤＵＴ仕様０１の記述が正しいものとし、その他のデータは全てＤＵＴ仕様０１の情報に基づいて作成されるものとする。

ＤＵＴ０２は、ＤＵＴ仕様０１に基づいて、ＶｅｒｉｌｏｇあるいはＶＨＤＬにより記述された論理システムの設計データである。モデル仕様０３は、ＤＵＴ０２のテストを実施するために必要な機能についての仕様が記載されているデータである。この仕様は自然言語その他、いかなる言語で記述されていてもかまわない。

プロパティ０４は、ＤＵＴ仕様０１に基づいてテストアイテムチェックリスト等から作成されたものである。これは、ＤＵＴ０２の静的検証おこなうことが可能であれば、いかなる言語であってもかまわない。

テストベンチ生成手段２１は、本実施の形態において必要なテストベンチを生成するための手順である。この手順にはＤＵＴ仕様０１、ＤＵＴ０２、モデル仕様０３およびプロパティ０４が必要となる。テストベンチ生成手段２１の詳しい説明は後に図２を用いておこなうこととする。

動的シミュレーション３１をテストベンチ生成手段２１から得たテストベンチを用いて実施する。このとき、動的シミュレーションの方法は、テストベンチ生成手段２１で生成したテストベンチを用いて行えば、いかなる方法でもかまわない。

静的検証３２をＤＵＴ０２およびプロパティ０４を用いて実施する。プロトコルエラーログ０５は、動的シミュレーション３１の結果、後に説明するアサーション１２から得たエラーログである。期待値エラーログ０６は、動的シミュレーション３１の結果、後に説明するモニタ１４から得たエラーログである。プロパティエラーログ０７は、静的検証３２の結果得たエラーログである。指標０８は、あらかじめ用意されたエラーの位置を確定するための表である。この表の内容については、後に詳しく説明する。

以上、プロトコルエラーログ０５、期待値エラーログ０６、プロパティエラーログ０７および指標０８を用いて、エラー箇所特定手段２２を実施することにより、エラー位置情報０９を得る。エラー箇所特定手段２２については、指標０８の説明と共に詳しくすることにする。

図２は、本実施の形態に用いるテストベンチ生成装置の一例を示す図である。この図は、図１におけるテストベンチ作成手段２１を示している。
モデル１１は、モデル仕様０３に基づいて作成されたモデルの設計データである。これは、ＤＵＴ０１のシミュレーションを実行できる環境になっていればいかなる言語で記述されていてもかまわない。

アサーション生成器２３では、ＤＵＴ仕様０１によって既知であるＤＵＴ０２の外端仕様を元にモデル１１とＤＵＴ０２間のプロトコル違反を監視するアサーション１２を生成する。アサーションが必要となる理由は、後に説明する。テスト１３は、ＤＵＴ仕様０１に基づいてテストアイテムチェックリスト等から作成されたものである。これは、ＤＵＴ０２のシミュレーションを実行するためのテストであればいかなる言語であってもかまわない。

モニタ生成器２４は、静的検証の結果と動的シミュレーションの結果を正確に比較するためのモニタ１４を生成する。このようなモニタが必要である理由およびモニタが必要とする情報、モニタの作成方法等は後に詳しく説明する。

テストベンチ２５は、前記で作成したモデル１１、テスト１３、モニタ１４および、アサーション１２を取り付け、ＤＵＴ０２に対する動的シミュレーションの実行を可能としたものである。これを用いて動的シミュレーション３１を実施する。

図３は、本実施の形態におけるエラー解析手順の一例を示すフローチャートである。以下、順を追って説明する。
ステップＳ１００で、テストアイテムを一つずつとりだし、ステップＳ１１０にて動的シミュレーションおよび静的検証を実施する。次に、ステップＳ１２０にてエラーログを取得し、指標と比較する。ステップＳ１３０にてバグの位置が確定すればステップＳ１５０へ分岐し、未定であればステップＳ１４０へ分岐する。

ステップＳ１４０にてステップＳ１２０で得たログを元に、もう一度検証を実施し、ステップＳ１３０へ分岐する。ステップＳ１５０にてバグを修正し、ステップＳ１６０にてテストアイテムはすべて終了したらこの処理を終了し、終了していない場合にはステップＳ１００へ分岐する。

ステップＳ１００では、テストアイテムチェックリスト等をもとにして、テストおよびプロパティから同様のテストアイテムをひとつずつ取り出す。ステップＳ１１０では、ステップＳ１００で取り出したテストアイテムについての動的シミュレーションおよび静的検証を実施する。

ステップＳ１２０では、ステップＳ１１０の結果から得た、アサーション、期待値、プロパティの３種類のエラーログ状況と、あらかじめ用意されているバグの位置を切り分ける指標を比較する。指標については、後に詳しく説明する。

ステップＳ１３０では、ステップＳ１２０で比較した結果、バグの位置が特定できたかどうかを判定する。バグの位置が特定できた場合はステップＳ１５０へ、複数の位置にバグがある可能性がある場合は、ステップＳ１４０へ分岐する。

ステップＳ１４０では、ステップＳ１１０の結果から得たエラー状況を用いて、最終的にバグの位置確定がしやすいように再度検証を実施する。この実施方法については、後に指標の説明と共に詳しく説明する。検証を実施したら、ステップＳ１２０へ戻り、同様にしてエラーログと指標を比較してバグの位置を特定する。

ステップＳ１５０では、バグの位置を指標により定めることが出来たので、バグを修正する。ステップＳ１６０では、全てのテストアイテムの検証が終了したかを判定する。全てのテストアイテムについて、検証が終了しているならばこの処理を終了とする。まだ検証するべきテストアイテムが残っているならば、ステップＳ１００へ戻り次のテストアイテムを選び、テストアイテムが全て終了するまで同様の処理を繰り返す。

ここで、動的シミュレーションに用いるテスト環境について説明する。
図４は、本実施の形態で用いるエラーログ取得機能を備えた動的シミュレーションのテスト環境の一例を示す図である。
ＤＵＴ４１は、ＶｅｌｉｒｏｇあるいはＶＨＤＬで記述された論理システムの設計データであり、検証対象となるものである。

モデル４２は、ＤＵＴ４１を検証するために仕様を基に作成されたものである。簡単のために図ではモデルが一つとなっているが、ＤＵＴ４１が必要とする数のモデルがあればかまわない。また、いかなる言語で記述されていてもよく、作成は人手でも自動でもかまわない。

アサーション４３は、ＤＵＴ４１の外端の仕様が分かっているという前提から、ＤＵＴ４１とモデル４２間のプロトコル違反がないかどうかをみる機能である。あらかじめプロトコル違反となるルールを記述しておき、動的シミュレーションの実施中にプロトコル違反が起こった場合に、エラーとしてログを取る機能をつけておく。これをつけておくことにより、エラー位置の特定をより容易にすることが可能である。

テスト４４は、ＤＵＴ４１を検証するために仕様を基に作成されたものである。簡単のために図４ではテストが一つのファイルとなっているが、ＤＵＴ４１が必要とする数のテストファイルがあればかまわない。また、いかなる言語で記述されていてもよく、人手で作成されても自動で作成されてもかまわない。

モニタ４５は、ＤＵＴ４１のエラーを発見するために仕様を基に作成されたものである。本来、モニタには期待値と実行値を比較する機能があるが、本実施の形態では静的検証と併用するため、一度プロパティを読み込み、比較に必要な情報を取得する機能を付加する。この方法の詳細については後に説明する。また、モニタはいかなる言語で記述されていてもよく、人手で作成されても自動で作成されてもかまわない。

以上説明したように、動的シミュレーションを行うためにはこのように複雑なテスト環境が必要である。従来、動的シミュレーションはＤＵＴのバグを発見するための機構であるにもかかわらず、これだけの機能をつけなければならないため、実際にエラーが報告された際に、ＤＵＴのみならずモデルのバグやテストのバグである可能性も捨てきれない。そのため、エラーの解析に非常に時間がかかってしまう。本実施の形態では、その問題を解決するために、テスト環境にアサーションおよび特別なモニタをつけ、さらにテストベンチの必要ない静的検証を併用する。

次に、モニタ生成器２４について説明する。
図５は、本実施の形態で使用するモニタ生成手順の一例を示すフローチャートである。本実施の形態において、これから説明するようなモニタが必要となるのは次のような理由があるためである。一般的な動的シミュレーションにおけるモニタは、期待値と実行値を比較し、それらの値が異なっていればエラーであることを知らせる機能を持っている。

本来、動的シミュレーションのみを実施するのであれば、そのエラーを元に時間をさかのぼり人手でエラー原因を突き止める。しかし、本実施の形態では動的シミュレーションに静的検証を併用し、そのエラー結果を比較する。そのためには、従来のモニタの機能だけでは不十分である。

静的検証はエラーとなった際に、エラーの原因となる信号および時刻を知らせる機能を持っている。この機能を用いて、従来のモニタに前記のような情報を取得する機能を取り付ければ、エラーの比較および解析が容易になる。以下に、その手順を説明する。

ステップＳ１０１にて仕様を基にモニタを作成し、ステップＳ１０２にてプロパティを読み込み、必要な情報を取得する。ステップＳ１０３にて、ステップＳ１０２で取得した情報を基にモニタを生成し、ステップＳ１０１では仕様を基に、従来どおりモニタを作成する。このモニタの機能はログが取れる構成になっていればその他の機能は任意でかまわない。このときモニタの作成方法は、いかなる言語で作成してもよくまた自動でも人手でもかまわない。

ステップＳ１０２では、ステップＳ１０１と同様に仕様を基に書かれたプロパティを読み込み、ログ比較する際に必要な情報を得る。ここで取得しなければならない情報とは、必要な時刻における入出力信号の値、内部信号の値、および出力信号の期待値、またそれぞれの信号名である。これらが必要である理由および必要な時刻等の説明は後に記述する。ステップＳ１０３では、ステップＳ１０２で得た情報を基にモニタを作成する。

ステップＳ１０２およびステップＳ１０３の一具体例を以下に示す。
プロパティ： cond_a => reslt_a//p-1。
cond_b => X3(reslt_b)//p-2。

ここで、前記に示したプロパティ記述の説明をする。以下に、本実施の形態で使用する記号を示す。
a => b：aが成立するならばbが成立する。
&&：論理積。
||：論理和。
~：論理否定。
'：次クロックサイクルの状態。
Xｎ (ｎは数字)：nクロックサイクルの状態。
==：論理等価。

よって前記記述したプロパティp-1は以下の動作記述を定義している。
「cond_aという状態であれば、同時刻においてreslt_aという状態である」
また、プロパティp-2は以下の動作記述を定義している。
「cond_bという状態であれば、３クロックサイクル後にreslt_bという状態である」
前記プロパティｐ-1であれば、同時刻の情報だけあればよいのであえて新しくモニタの情報収集要素を付け加える必要はない。

プロパティｐ-2の場合は、仮にエラーが起こったとするとその原因は３サイクル前までの中にある。静的検証のエラーログにおいては現在から３クロックサイクル後までの情報全てが記録される。なぜならば、現在から３クロックサイクルまでの間に起こる内部状態などにより、エラーとなる可能性があるためである。そのため、動的シミュレーションのログについても同様に、エラーとなった時刻から３サイクル前までの必要な信号値全てを記録しておく必要がある。またこれを記録しておけば後のエラー解析の際に、記録した状況だけを参照すればよい。

エラーログが取得する必要のある情報は、前記に示したような時刻の信号の値と、入力信号およびその値、出力信号およびその値、出力信号の期待値およびその値である。

このようにすることにより、エラーが起こった原因を解析することが可能となり、また静的検証と動的シミュレーションのエラーログを比較することが可能となる。ただし、ステップＳ１０１を省略して、既に作成されているモニタを流用して本実施の形態を実施してもかまわない。

図６は、バグの位置を切り分けるための指標の一例を示す図である。ここではアサーションおよびモニタは正しいものと仮定し、最終的に辻褄が合わなくなった場合にアサーションまたはモニタの誤りを摘出することとするが、これは本実施の形態の一例であり、この方法に限定されるものではない。この表について、順を追って説明する。

以下の説明において、パスとは動的シミュレーションおよび静的検証の結果が何も問題なく終了したこと、フェイルとは動的シミュレーションおよび静的検証の結果がエラーになったことを示す。また、図中のクエスチョンマークは、エラーの位置を特定出来ないことを表わす。

状態５０は、アサーション、期待値比較、静的検証においてエラーが生じなかった状態であり、この場合はもちろん全ての場所にエラーはない。状態５１は、アサーション、期待値比較においてはエラーが生じなかったが、静的検証でエラーとなった場合である。この場合、エラーの原因がＤＵＴ、モデル、テストあるいはプロパティのどこにあるのか確定できない。したがって、状態５２から状態５５の検査を行う。

状態５２から状態５５は状態５１で判定したエラー箇所をさらに特定するために、静的検証から得たエラー状況を再び動的シミュレーションのテストとして再現し、動的シミュレーションを実施する。これを二度目の検証とする。

状態５１から状態５５までの一具体例を以下に示す。
仕様と一度目の静的検証の結果から得たエラーログが以下のように示されていたとする。
仕様：cond_aが成立するとidel_state から inprog_stateへ遷移する。
エラーログ(静)：T0 :cond_a , idle_state T1: suspend_state。
プロパティの記述ミス、もしくは制約漏れにより静的検証でフェイルとなったので、プロパティのエラーである。
テストの記述ミスにより、本来ＤＵＴのバグであることを見つけられなかったのでテストおよびＤＵＴのエラーである。

以上の二つの状態が考えられる。これらの状態を正確に一つの状態に特定するために、静的検証から得たエラーログの状況を動的シミュレーションのテストで再現し、動的シミュレーションを実行する。

その結果から以下の情報を得ることが可能である。
状態５２ではアサーション、期待値比較の結果が共にパスしているので、プロパティでエラーとなった入力制約条件のプロトコルは許されている。また、プロトコルの正しい入力制約条件を用いた動的シミュレーションの結果はパスすることが考えられるため、プロパティそのものが間違っているといえる。状態５３ではアサーションではパス、期待値比較ではフェイルしているので、プロパティでエラーとなった入力制約条件のプロトコルは許されている。

また、プロトコルの正しい入力制約条件を用いた動的シミュレーションの結果がエラーとなったことが考えられるため、テストが不十分であったことが考えられる。またこの場合、プロパティは正しいので、プロパティがフェイルした箇所に該当するＤＵＴエラーでもある。

状態５４、状態５５ではアサーションがフェイルしているので、プロパティでエラーとなった入力制約条件はプロトコル違反していることが考えられるため、これと同じ状況が起こらないようにプロパティにコンストレイント（制約）を加え、もう一度動的シミュレーションを実施する。これをプロトコル違反がなくなるまで繰り返す。

状態５６はアサーションではパス、期待値比較ではフェイル、静的検証ではパスしている場合である。この場合、エラーの原因がＤＵＴ、モデル、テストあるいはプロパティのどこにあるのか確定できない。したがって、状態５７から状態５８の検査を行う。

状態５７から状態５８では状態５６で判定したエラー箇所をさらに特定するために、動的シミュレーションから得たエラー状況をプロパティの制約条件として再現し、静的検証を実施する。これを二度目の検証とする。

状態５６から状態５８の一具体例を以下に示す。
仕様と、動的シミュレーションの期待値比較の結果から得たエラーログが以下のように示されていたとする。
仕様：cond_aが成立するとidel_state から inprog_stateへ遷移する。
エラーログ(動)：T0 :cond_a , idle_state T1: suspend_state。
テストの間違いにより、間違ってないものを間違いと判断してしまった場合にはテストのエラーである。
プロパティの記述ミスにより、本来ＤＵＴエラーであることが見つけられなかった場合にはプロパティとＤＵＴのエラーである。

以上の二つの状態が考えられる。これらの状態を一つの状態に特定するために、動的シミュレーションの期待値比較におけるエラーログをプロパティの制約条件として用い、静的検証を実施する。その結果から以下の情報を得ることが可能である。

状態５７では、二度目の検証において静的検証がパスしているので、本来、動的動的シミュレーションにおいてもパスしなければならない状況においてフェイルとなっていることが考えられる。この場合は例外的に、本来正しいとしていたモニタにエラーがある可能性が高い。そのため、モニタの期待値および比較機能が正しいかを確認し、もう一度検証を実施する。

状態５８では、静的検証がフェイルしているのでプロパティでエラーとなる状況を起こせなかったが考えられ、プロパティおよびＤＵＴのエラーであることが分かる。状態５９は、アサーションではパス、期待値比較ではフェイル、静的検証でもフェイルしている場合である。この場合、エラーの原因がモデル、テスト或いはプロパティのどこにあるのか確定できない。したがって、状態６０から状態６１の検査を行う。

状態６０から状態６１では、状態５９で判定したエラー箇所をさらに特定するために、動的シミュレーションの結果からエラー状況をプロパティの制約条件として再現し、静的検証を実施する。これを二度目の検証とする。

状態５９から状態６１の一具体例を以下に示す。
仕様と、動的シミュレーションの期待値比較の結果および静的検証の結果から得たエラーログが以下のように示されていたとする。
仕様：cond_aが成立するとidel_state から inprog_stateへ遷移する。
エラーログ(動) ：T0 :cond_a , idle_state T1: suspend_state。
エラーログ(静)１：T0 :cond_a , idle_state T1: suspend_state。
エラーログ(静)２：T0 :cond_a , idle_state T1: done_state。
動的シミュレーションのエラーログと静的検証のエラーログが同じ場合(前記エラーログ(静)１の場合)は以下のような状況が考えられる。
テストとプロパティが同じ状況でフェイルしているのでＤＵＴのエラーである。
動的シミュレーションのエラーログと静的検証のエラーログが異なる場合(前記エラーログ(静)２の場合)は以下のような状況が考えられる。
テストとプロパティは異なる状況でフェイルしているのでテストとＤＵＴもしくはプロパティとＤＵＴのエラーである。

以上の二つの状態が考えられる。これらの状態を一つの状態に特定するために、動的シミュレーションの期待値比較におけるエラーログをプロパティの制約条件として用い、静的検証を実施する。状態５９の場合は、静的検証のエラーログを動的シミュレーションの入力値として再現することも可能だが、静的検証の方が短時間で検証結果を得ることが出来るため、本実施の形態では二度目の検証を静的検証で実施することにした。二度目の検証の結果から以下の情報を得ることが可能である。

状態６０は二度目の検証の静的検証がパスしているので、前記動的シミュレーションのエラーログに対して、静的検証のエラーログはエラーログ(静)２であることが考えられる。つまり、動的シミュレーションと静的検証は共にフェイルしたのだが、互いに異なる状況でフェイルしたといえる。

この場合、動的シミュレーションでフェイルした結果を静的検証の入力制約条件として代入したらパスしたため、動的シミュレーションにおける期待値比較が誤っていたもでモニタのエラーであることが考えられる。

状態５７と同様で、本来モニタの機能は正しいとしていたのでこれは例外的な処理となるが、該当箇所のモニタを修正しもう一度検証を実施する。状態６１は二度目の検証の静的検証がフェイルしているので、前記動的シミュレーションのエラーログに対して、静的検証のエラーログはエラーログ(静)1であることが考えられる。つまり、動的シミュレーションと静的検証は共にフェイルし、かつ互いに同じ状況でフェイルしたといえる。この場合、動的シミュレーションでフェイルした結果を静的検証の入力制約条件として代入したら、当然エラーログ(静)１と同じ状況でフェイルするのでＤＵＴのエラーであることが考えられる。

状態６２から６５はすべて、アサーションでフェイルしている状況を示している。この場合は、状態５０から状態６１までとは異なり、二度目の検証を実施しなくてもエラーの位置を確定することが可能である。

状態６２は、アサーションでフェイル、期待値比較でパス、静的検証でパスしているので、モデルの動きが誤っていることによりアサーションでフェイルするのであれば期待値比較でもおかしな値が出るはずであり、モデルによる出力異常ではない。

前記のような状況にも関わらず、アサーションがフェイルしているのはＤＵＴからの応答がおかしいことが考えられるのでＤＵＴのエラーである。前記のようにＤＵＴのエラーがあるにも関わらず静的検証がパスしているということは静的検証でＤＵＴのエラーが発見できなかったのでプロパティが不足している、という状況が考えられるので、ＤＵＴおよびプロパティのエラーである。

状態６３は、アサーションでフェイル、期待値比較でパス、静的検証でフェイルしているので、モデルの動きが誤っていることによりアサーションでフェイルするのであれば期待値比較でもおかしな値が出るはずであり、モデルによる出力異常ではない。

また、前記のような状況にも関わらず、アサーションがフェイルしているのはＤＵＴからの応答がおかしいことが考えられるのでＤＵＴのエラーである。前記のように、ＤＵＴにエラーがあるにも関わらず、動的シミュレーションにおける期待値比較はパスしているのでテストのエラーである。

ＤＵＴにエラーがあるため、静的検証ではフェイルしているのでプロパティは間違っていないという状況が考えられるので、ＤＵＴおよびテストのエラーである。状態６４では、アサーションでフェイル、期待値比較でフェイル、静的検証でパスしているので、モデルの動きが誤っていることによりアサーションでフェイルしており、モデルのエラーである。
モデルの動きが誤っていることにより、期待値比較でもフェイルしているのでテストは正しい。

静的検証はパスしているためＤＵＴは正しい可能性があるが、モデルに誤りがあり動的シミュレーションを正しく行えないため、本当にプロパティとＤＵＴが正しいと言えるか分からないのでＤＵＴおよびプロパティが正しいかは不明、という状況が考えられるため、アサーションがフェイルした状況に基づいてモデルを修正し、改めて検証を実施する必要がある。

状態６５では、アサーションでフェイル、期待値比較でフェイル、静的検証でパスしているので、モデルの動きが誤っていることによりアサーションでフェイルしているのでモデルのエラーである。モデルの動きが誤っていることにより、期待値比較でもフェイルしているのでテストは正しい。

静的検証はフェイルしているためＤＵＴにエラーがある可能性があるが、モデルに誤りがあり動的シミュレーションを正しく行えないため、本当にプロパティが正しくＤＵＴにエラーがあるかは分からないので、ＤＵＴおよびプロパティが正しいかは不明、という状況が考えられるため、状態６４と同様にアサーションがフェイルした状況に基づいてモデルを修正し、改めて検証を実施する必要がある。

以上により、本実施の形態によれば動的シミュレーションと静的検証を併用し双方のエラー発生の有無を考えることにより、従来特定することが困難であった動的シミュレーションにおけるエラーの原因となる場所を特定することが可能となる。また、テストベンチとＤＵＴのエラー原因の切り分けが容易になることにより、テストベンチのバグを確実に取り除くことが可能となる。

このようにしてバグのないテストベンチを使用することが可能となることにより、テストベンチの再利用性が向上し検証環境構築にかかる工数を削減することが可能となる。また、バグのあるテストベンチを使用することによりＤＵＴのバグを発見できない危険を避けることができ、バグが残ったまま製品を市場に投入してしまう恐れがなくなる。

（本発明に係る他の実施の形態）
前述した本発明の実施の形態における論理システムの検証装置を構成する各手段、並びに論理システムの検証方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施の形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラム（実施の形態では図３、５に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

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

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記録媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施の形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施の形態の機能が実現され得る。

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

本実施の形態の検証装置の一例を示す図である。 本実施の形態のテストベンチ生成装置の一例を示す図である。 本実施の形態におけるエラー解析手順の一例を示すフローチャートである。 本実施の形態によるテストベンチ構成の一例を示す図である。 本実施の形態によるモニタ生成手順の一例を示すフローチャートである。 本実施の形態によるエラー特定方法の指標の一例を示す図である。

符号の説明

０１ ＤＵＴ仕様
０２ ＤＵＴ
０３ モデル仕様
０４ プロパティ
０５ プロトコルエラーログ
０６ 期待値エラーログ
０７ プロパティエラーログ
０８ エラー特定の指標
０９ エラー位置情報
１１ モデル
１２ アサーション
１３ テスト
１４ モニタ
２１ テストベンチ作成手段
２２ エラー箇所特定手段
２３ アサーション生成器
２４ モニタ生成器
２５ テストベンチ
３１ 動的シミュレーションの実施手順
３２ 静的検証の実施手順
４１ ＤＵＴ
４２ モデル
４３ アサーション
４４ テスト
４５ モニタ
５０〜６５ バグ位置を決定するための指標

Claims (8)

1. ハードウェア記述言語により記述された論理システムの検証装置であって、
   動的シミュレーションを実行するテストベンチ作成手段と、
   静的検証を実行する静的検証手段と、
   前記動的シミュレーションと前記静的検証の結果から、エラー箇所を特定するエラー箇所特定手段とを具備することを特徴とする論理システムの検証装置。
2. 前記テストベンチ作成手段は、前記静的検証で用いるプロパティを読み込み実行値と期待値の比較をおこなうモニタ作成手段と、
   前記論理システムの入出力のプロトコル違反を検出するアサーション作成手段とを具備することを特徴とする請求項１に記載の論理システムの検証装置。
3. 前記モニタ作成手段は、前記論理システムにおける時刻、入力信号の値および信号名、出力信号の値および信号名、内部信号の値および信号名を取得することを特徴とする請求項２に記載の論理システムの検証装置。
4. 前記エラー箇所特定手段は、前記動的シミュレーションの結果および前記静的検証の結果を基に、予め用意したエラー箇所特定指標に基づき前記エラー箇所を特定することを特徴とする請求項１に記載の論理システムの検証装置。
5. 前記エラー箇所特定指標は、前記動的シミュレーションの結果および前記静的検証の結果の組み合わせとエラーが存在する箇所の対応であることを特徴とする請求項４に記載の論理システムの検証装置。
6. ハードウェア記述言語により記述された論理システムの検証方法であって、
   動的シミュレーションを実行するテストベンチ作成工程と、
   静的検証を実行する静的検証工程と、
   前記動的シミュレーションと前記静的検証の結果から、エラー箇所を特定するエラー箇所特定工程とを有することを特徴とする論理システムの検証方法。
7. 請求項６に記載の方法の各工程をコンピュータに実施させるプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。
8. 請求項６記載の方法の各工程をコンピュータに実施させることを特徴とするコンピュータプログラム。

Images