JP5830955B2 - 検証装置、検証方法及び検証プログラム - Google Patents

Description

本発明は、検証装置、検証方法及び検証プログラムに関し、動作記述と抽象インタフェイスの組み合わせによって起こり得る設計間違いを効率的に検出することができる検証装置、検証方法及び検証プログラムに関する。

半導体集積回路（以下、回路）の設計業務においては、設計者が、まず回路の動作レベルでの設計を行い、その後、動作レベルの設計に基づいてハードウェアレベルの設計を行う手法が広く採用されている。

動作レベルの設計は、一般に、設計者が動作記述を作成することにより行う。動作記述の作成には、例えばＶｅｒｉｌｏｇ−ＨＤＬ（Ｖｅｒｉｌｏｇ Ｈａｒｄｗａｒｅ Ｄｉｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、ＶＨＤＬ（Ｖｅｒｙ Ｈｉｇｈ Ｓｐｅｅｄ Ｈａｒｄｗａｒｅ Ｄｉｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、ＳｙｓｔｅｍＶｅｒｉｌｏｇ等のハードウェア記述言語、Ｃ、Ｃ＋＋、Ｃ＃、ＪＡＶＡ（登録商標）、Ｐｅｒｌ、Ｓｃｈｅｍｅ、Ｌｉｓｐ等のプログラム言語及びＳｙｓｔｅｍＣ、ＳｐｅｃＣ等のプログラミング言語に回路設計のための拡張を施した言語が用いられる。

一方、ハードウェアレベルの設計は、一般に、動作合成装置がＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）記述を作成することにより行う。動作合成装置は、後述の方法により、動作記述を変換してＲＴＬ記述を作成する。また、ＲＴＬ記述の作成においても、動作記述と同様の言語が用いられる。

動作合成装置は、動作記述に対し、変形処理（関数呼出し処理の解決、不要コードの削除、言語レベルの最適化等の処理）、スケジューリング処理（どのタイミングでどのような処理や演算を実行すべきかを決定する処理）、レジスタバインディング処理（レジスタの生成、レジスタへの変数の割当て等の処理）及び演算器バインディング処理（演算器への演算子の割当て等の処理）等を行うことによって、ＲＴＬ記述を作成する（非特許文献１参照）。

ところで、人がプログラミング言語を用いてシステムを設計する際には、設計作業の効率向上のため、複雑で再利用可能な処理についてはモジュール化を行い、プログラム本体から必要に応じてモジュールを呼出す手法が広く用いられている。

動作記述の設計においても、同様の課題を解決するため、特に回路を構成するモジュール間及びスレッド間の通信処理についてモジュール化、換言すれば抽象化し得ることが提案されている（非特許文献２参照）。モジュール間及びスレッド間の通信処理は複雑であり、設計者が都度記述していたのでは煩雑かつ間違いが混入しやすいためである。

このような抽象化された通信処理モジュールを、抽象インタフェイスと呼ぶ。抽象インタフェイスとは、具体的には、モジュール間及びスレッド間の通信処理を予め定義したデータ送出関数、データ取得関数等を１つのパッケージとしてまとめたソフトウェアモジュールである。設計者は、動作記述を作成する際、抽象インタフェイスに含まれるこれらの関数を呼び出すことによって、動作記述のプログラムの中に上記通信処理を容易に含めることができる。

抽象インタフェイスを利用することにより、設計者は、回路の動作の設計と上記通信処理の設計とを分離することができる。そのため、設計者は、回路の動作の設計という本質的な作業に注力することができるようになる。また、設計者は、一度設計した抽象インタフェイスを、他の回路を設計する際に再利用することも可能となる。

Ｊｏｈｎ Ｐ． Ｅｌｌｉｏｔｔ，Ｕｎｄｅｒｓｔａｎｄｉｎｇ Ｂｅｈａｖｉｏｒａｌ Ｓｙｎｔｈｅｓｉｓ，Ｋｌｕｗｅｒ Ａｃａｄｅｍｉｃ Ｐｕｂｌｉｓｈｅｒｓ，第２５−４０頁 桜井至著，ＳｙｓｔｅｍＣを使ったハードウェア設計，ＣＱ出版社，２００６年１１月１５日，第９２−９８頁

多くの場合、抽象インタフェイスの開発においては、性能向上や開発工数の節約が要請されるため、動作記述との適合性が十分に担保されない抽象インタフェイスが作成されてしまうことがある。このような抽象インタフェイスを利用すると、例えば、動作記述ａと組合せた場合には正しい回路が生成されるとしても、動作記述ｂと組合せた場合には正常に動作しない回路が生成されてしまうという問題が生じ得る。

以下に、この問題が顕在化する状況を具体的に示す。

図２１は、動作記述を示している。この動作記述は、「ＳｙｓｔｅｍＣ言語」を用いて表記されているが、本発明の説明に関連のない部分は一部省略されている。

この動作記述は概略以下のように動作をする。入力有効端子ｉｎ０＿ｅｎの値が真である時に入力端子ｉｎ０の値が読み出され、その値は、出力有効端子ｏｕｔ０＿ｅｎの値が真である時に出力端子ｏｕｔ０へ書出される。

この動作は、２つのスレッドｉｎｉ及びｔａｒによって実現されている。そして、これらスレッド間の通信は、後述する抽象インタフェイスのデータ送出関数ｐｕｔ（）とデータ取得関数ｇｅｔ（）を用いて記述されている。以下に、これらスレッドの動作の概略を示す。

スレッドｉｎｉは、入力有効端子ｉｎ０＿ｅｎの値を１つ読み出し、その値が真になるまで待つ。端子ｉｎ０＿ｅｎの値が真になったところで、スレッドｉｎｉは、入力端子ｉｎ０の値を一つ読み出し、抽象インタフェイスｉｎｆ＿ｔ型のインスタンスｉｎｆのデータ送出関数ｐｕｔ（）を用いて、その値をスレッドｔａｒに送出する。

一方、スレッドｔａｒは、出力有効端子ｏｕｔ０＿ｅｎの値を一つ読み出し、その値が真になるまで待つ。端子ｏｕｔ０＿ｅｎの値が真になったところで、スレッドｔａｒは、ｉｎｆのデータ取得関数ｇｅｔ（）を用いて、スレッドｉｎｉからの値を取得し、出力端子ｏｕｔ０へ書出す。

このように、動作記述内で抽象インタフェイスの関数を呼出すことで、設計者は、２つのスレッドｉｎｉとｔａｒがどのようにスレッド間の通信を実現するかについては考慮することなく、いかにして入力端子ｉｎ０の値を出力端子ｏｕｔ０へ書き出すかという本来の動作の設計に注力することができる。

図２２は、抽象インタフェイスを示している。この抽象インタフェイスｉｎｆ＿ｔ型は、２つの端子ｄａｔ及びｖｌｄを有し、データ送出関数ｐｕｔ（）及びデータ取得関数ｇｅｔ（）を含んでいる。

データ送出関数ｐｕｔ（）は概略以下のような動作をする。ｐｕｔ（）は、送出すべき値を端子ｄａｔに書き出すとともに、端子ｖｌｄに値１を書出す。さらに、ｐｕｔ（）は、クロック境界に同期して、端子ｄａｔおよび端子ｖｌｄにそれぞれ値０を書出す。

一方、データ取得関数ｇｅｔ（）は概略以下のような動作をする。ｇｅｔ（）は、端子ｖｌｄの値が真になるまで待ち、真になったところで端子ｄａｔの値を読出す。そして、ｇｅｔ（）は、読出した値を通信路から取得した値として動作記述に出力する。

図２１の動作記述、図２２の抽象インタフェイスは、動作合成装置によって組合され、ＲＴＬ記述に変換される。動作合成装置の動作は概略以下のとおりである。

動作合成装置は、図２１の動作記述中に含まれるデータ送出関数、データ取得関数の呼出し部分を、図２２の抽象インタフェイス中に含まれるデータ送出関数、データ取得関数の定義でそれぞれ置き換える。さらに、動作合成装置は、スケジューリング処理及びバインディング処理等を経て、ＲＴＬ記述を生成する。

図２３に、動作合成装置が生成するＲＴＬ記述の例を示す。このＲＴＬ記述は、データパス付拡張有限状態機械（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｍａｃｈｉｎｅ ｗｉｔｈ Ｄａｔａｐａｔｈ；ＦＳＭＤ）形式で表現されている。ＦＳＭＤとは、ＲＴＬの回路を有限状態機械（ＦＳＭ）で表現される制御と、ＦＳＭの各状態での動作で表現する形式である。

図２３の１行目から２１行目は、スレッドｉｎｉに対応するＲＴＬ記述である。スレッドｉｎｉに対応するＲＴＬ記述は、ＳＴ１、ＳＴ２及びＳＴ３の３つの状態を持つ。２２行目から４４行目は、スレッドｔａｒに対応するＲＴＬ記述である。スレッドｔａｒに対応するＲＴＬ記述は、ＳＴ４、ＳＴ５及びＳＴ６の３つの状態を持つ。

スレッドｉｎｉに対応するＲＴＬ記述の状態ＳＴ１では、端子ｉｎ０＿ｅｎから読み出した値が真になるまで待ち、端子ｉｎ０＿ｅｎの値が真になったところで、端子ｉｎ０から値を読み出して状態ＳＴ２に遷移する。状態ＳＴ２，状態ＳＴ３では、それぞれ、データ送出関数ｐｕｔ（） の処理を実行する。状態ＳＴ２では、端子ｉｎｆ＿ｄａｔに送出する値を書き出し、端子ｉｎｆ＿ｖｌｄに値ｔｒｕｅを書き出す。状態ＳＴ３では、端子ｉｎｆ＿ｄａｔに値０を書き出し、端子ｉｎｆ＿ｖｌｄの値をｆａｌｓｅとする。

一方、スレッドｔａｒに対応するＲＴＬ記述の状態ＳＴ４では、端子ｏｕｔ０＿ｅｎから読み出した値が真になるまで待ち、端子ｏｕｔ０＿ｅｎの値が真になったところで、状態ＳＴ５に遷移する。状態ＳＴ５，状態ＳＴ６では、それぞれデータ取得関数ｇｅｔ（）の処理を実行する。状態ＳＴ５では、端子ｉｎｆ＿ｖｌｄから読み出した値が真になるまで待ち、端子ｉｎｆ＿ｖｌｄの値が真になったところで、端子ｉｎｆ＿ｄａｔの値を読み出し状態ＳＴ６に遷移する。状態ＳＴ６では、読み出した値を端子ｏｕｔ０に書き出す。

ここで、図２４に、このＲＴＬ記述の一動作例としての波形図を示す。この動作例は、図２３のＲＴＬ記述が動作するとき、設計者の意図どおりにデータ転送が行われない場合を示している。

このＲＴＬ記述において、スレッドｉｎｉからスレッドｔａｒへのデータ転送が正しく行われるためには、スレッドｉｎｉの状態ＳＴ２とスレッドｔａｒの状態ＳＴ５が同時に実行される必要がある。これは、状態ＳＴ２で端子ｉｎｆ＿ｄａｔに書き出した値を状態ＳＴ５で読み出さなければならないためである。

しかしながら、図２４の波形を参照すると、時刻１で端子ｉｎ０＿ｅｎの値がｔｒｕｅになり、遅れて、時刻３で端子ｏｕｔ０＿ｅｎの値がｔｒｕｅになっている。そのため、スレッドｉｎｉが時刻２で状態ＳＴ２を実行するのに対して、スレッドｔａｒが状態ＳＴ５を実行するのは時刻４以降である。よって、スレッドｉｎｉからスレッドｔａｒへのデータ転送は正しく行われないこととなる。

以上の実証から、動作記述と抽象インタフェイスとの分離は、設計の効率化等のメリットをもたらす一方、間違った組合せによる設計不具合という新たなデメリットを引き起こす場合があることが明らかとなった。

そこで、設計者は、抽象インタフェイスと動作記述とが正しく組み合わせられているかを検証する必要がある。

しかしながら、検証時には抽象インタフェイスが動作記述から分離されていることがマイナスに働く。すなわち、抽象インタフェイスを用意する側から考えると、設計不具合が動作記述との組み合わせで生じてしまうことから、インタフェイスそのものをいくら検証しても不具合をなくすことはできない。他方、抽象インタフェイスを利用する側から考えると、抽象インタフェイスの内部構造が外部から隠ぺいされているため、検証は抽象インタフェイスを利用しない場合に比べて難しい。

そこで、抽象インタフェイスを用意する側にとっては、抽象インタフェイスをどのような動作記述と組合せた場合であっても、適合性を容易に検証できる手法が望まれる。また、抽象インタフェイスを利用する側にとっても、抽象インタフェイスの内部構造に関知することなく適合性の検証を行うことができる手法が望まれる。

なお、動作記述の動作を論理的に検証する方法としては、プロパティ（アサーション）を用いた検証方法が広く知られている（例として、特開２００６−２８５３３３号公報参照）。しかしながら、この方法では、動作記述に対応するプロパティをその都度作成する必要がある。そのうえ、上述のように抽象インタフェイスの内容構造は一般に隠ぺいされているから、動作記述の設計者がプロパティを作成することは容易ではない。そこで、抽象インタフェイスの利点を生かしながら、プロパティを利用した設計検証が行える手法の確立が望まれる。

本発明は、このような問題点を解決するためになされたものであり、動作記述と抽象インタフェイスの組み合わせによって起こり得る設計間違いを効率的に検出することができる検証装置、検証方法及び検証プログラムを提供することを目的とする。

本発明に係る検証装置は、電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かを検証するための検証装置であって、前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとが入力される入力手段と、前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する動作合成手段と、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成する対応関係記述生成手段と、前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換するプロパティ変換手段と、前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するプロパティ検証手段とを有するものである。

また、本発明にかかる検証方法は、電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かを検証する方法であって、前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとの入力を受けると、前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する際、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するものである。

また、本発明に係るプログラムは、電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かをコンピュータに検証させるプログラムであって、前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、前記コンピュータを、検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとの入力を受けると、前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する際、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するよう動作させるものである。

本発明により、動作記述と抽象インタフェイスの組み合わせによって起こり得る設計間違いを効率的に検出することができる検証装置、検証方法及び検証プログラムを提供することができる。

本発明の実施の形態１の構成を示す図である。 本発明の実施の形態１の処理を示す図である。 本発明の実施の形態１を説明するための動作記述の例である。 本発明の実施の形態１を説明するための抽象インタフェイスの例である。 本発明の実施の形態１を説明するための第１のプロパティの例である。 本発明の実施の形態１を説明するためのＲＴＬ記述の例である。 本発明の実施の形態１を説明するための対応関係記述の例である。 本発明の実施の形態１を説明するための第２のプロパティの例である。 図６のＲＴＬ記述の動作を表す波形図である。 本発明の実施の形態１を説明するための動作記述の例である。 本発明の実施の形態１を説明するためのＲＴＬ記述の例である。 図１１のＲＴＬ記述の動作を表す波形図である。 本発明の実施の形態１を説明するための抽象インタフェイスの例である。 本発明の実施の形態１を説明するためのＲＴＬ記述の例である。 図１５のＲＴＬ記述の動作を表す波形図である。 本発明の実施の形態２の構成を示す図である。 本発明の実施の形態２の処理を示す図である。 本発明の実施の形態３の構成を示す図である。 本発明の実施の形態４の構成を示す図である。 本発明の実施の形態４の処理を示す図である。 動作記述の例を示す図である。 抽象インタフェイスの例を示す図である。 ＲＴＬ記述の例を示す図である。 図２３のＲＴＬ記述の動作を表す波形図である。

＜実施の形態１＞
まず、図１を用いて、本発明の実施の形態１にかかる検証装置１００の構成について説明する。

検証装置１００は、入力手段１０１、動作合成手段１０２、対応関係記述生成手段１０３、プロパティ変換手段１０４、プロパティ検証手段１０５を備えている。

検証装置１００は、例えばサーバコンピュータ、パーソナルコンピュータ（ＰＣ）、シンクライアント端末、ワークステーション、メインフレーム、スーパーコンピュータ等であり、典型的には処理装置（ＣＰＵ、マイクロプロセッサ等）、記憶装置（ＲＯＭ、ＲＡＭ、フラッシュメモリ、ハードディスク、ＳＳＤ、ＣＤ、ＤＶＤ、メモリカード等）を有し、入出力装置（ディスプレイ、キーボード、マウス等）を備えていてもよい。記憶装置は、コンピュータ本体に内蔵された記憶装置に限らず、外付け周辺機器や外部のストレージサーバ等に設置された記憶装置、或いは、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）であっても良い。また、検証装置１００は、物理的に単一である必要はなく、複数のコンピュータで分散的に処理を行う構成であってもよい。

入力手段１０１、動作合成手段１０２、対応関係記述生成手段１０３、プロパティ変換手段１０４、プロパティ検証手段１０５及び出力手段１０７は、プログラムに基づいて各種制御を実行する機能を有し、具体的には、処理装置、記憶装置、入出力ポート等により実現され得る。

つぎに、図２を用いて、本発明の実施の形態１における各手段の動作について説明する。

はじめに、入力手段１０１は、検証対象である動作記述及び抽象インタフェイスの入力を受付ける（ステップＳ１０１）。動作記述及び抽象インタフェイスは、図示しない記憶装置に予め記憶されているものを読み出してもよく、図示しない入出力装置や通信回線等の任意の手段により検証装置１００の外部から供給されてもよい。

動作記述とは、電子回路の動作を記述したものである。動作記述の作成には、例えばＶｅｒｉｌｏｇ−ＨＤＬ（Ｖｅｒｉｌｏｇ Ｈａｒｄｗａｒｅ Ｄｉｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、ＶＨＤＬ（Ｖｅｒｙ Ｈｉｇｈ Ｓｐｅｅｄ Ｈａｒｄｗａｒｅ Ｄｉｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、ＳｙｓｔｅｍＶｅｒｉｌｏｇ等のハードウェア記述言語、Ｃ、Ｃ＋＋、Ｃ＃、ＪＡＶＡ（登録商標）、Ｐｅｒｌ、Ｓｃｈｅｍｅ、Ｌｉｓｐ等のプログラム言語及びＳｙｓｔｅｍＣ、ＳｐｅｃＣ等のプログラミング言語に回路設計のための拡張を施した言語が用いられる（以下、総じて単にプログラミング言語という）。

この動作記述は、入出力に関する処理は、抽象インタフェイスを利用して記述されているものとする。抽象インタフェイスとは、モジュール間及びスレッド間の通信処理を予め定義したデータ送出関数、データ取得関数等を１つのパッケージとしてまとめたソフトウェアモジュールである。設計者は、動作記述の中でこれらの関数を呼び出すことにより、上記通信処理を動作記述のプログラムに含める。

つぎに、動作合成手段１０２は、動作記述をＲＴＬ記述に変換する（ステップＳ１０２）。この変換処理を動作合成という。

ＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）記述とは、電子回路のハードウェアレベルの構成を記述したものである。ＲＴＬ記述の作成においても、動作記述と同様のプログラミング言語が用いられる。

動作合成は、以下の処理を含む。動作合成手段１０２は、動作記述中のデータ送出関数の呼び出し、データ取得関数の呼び出しを、抽象インタフェイス内に記述されたデータ送出関数、データ取得関数の定義でそれぞれ置き換えるとともに、不要コードの削除、言語レベルの最適化等を行う（変形処理）。また、動作合成手段１０２は、動作記述に記載された、端子アクセス（読み出しや書き出し等）、信号アクセス、変数アクセス、演算式（算術演算・論理演算・比較演算等）、文、ブロック、プラグマ、イベントを実行するコントロールステップを決定する（スケジューリング処理）。さらに、動作合成手段１０２は、動作記述に記載された端子や信号を、ＲＴＬ記述の端子や信号に割り当てるとともに、動作記述の変数のデータを格納するＲＴＬ記述のレジスタや信号線（ｗｉｒｅ）を決定し、動作記述の演算式を行う演算器を決定し、動作記述の文をＲＴＬ記述の文に割り当て、動作記述のプラグマをＲＴＬ記述のプラグマに割り当てる。また、動作記述のイベントを、端子へのアクセスなどに割り当てる（バインディング処理）。加えて、動作合成手段１０２は、スケジューリング処理にて決定されたステップを制御する制御論理を備えた制御回路を作成する（制御回路作成処理）。最後に、動作合成手段１０２は、スケジューリング処理及びバインディング処理にて決定された演算器とレジスタからデータパスを作成し、そのデータパスと制御回路作成処理において作成された制御回路とを備えたＲＴＬ記述を作成する（ＲＴＬ記述生成処理）。

つぎに、対応関係記述生成手段１０３が、対応関係記述を生成する（ステップＳ１０３）。

対応関係記述とは、例えば、動作記述とその動作記述から生成されたＲＴＬ記述との間の、端子の対応関係、信号の対応関係、変数とレジスタの対応関係、変数と信号線の対応関係、演算式と演算器の対応関係、文の対応関係、プラグマの対応関係、イベントの対応関係等を記述したものである。

対応関係記述は、動作記述に応じて生成される。そのため、異なる動作記述を基に動作合成すれば、生成される対応関係記述の内容も異なるものとなり得る。対応関係記述は、より具体的には、例えば上掲の特開２００６−２８５３３３号公報において非特許文献２として示されている、若林一敏、他１名、アイ・イー・イー・イー・トランザクションズ・オン・コンピュータ・エイディド・デザイン（ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ），２０００年１１月、第１５０７−１５２２頁に記載の既存の技術を用いて作成することが可能である。

つづいて、入力手段１０１は、第１のプロパティの入力を受付ける（ステップＳ１０４）。第１のプロパティは、抽象インタフェイスに応じて、抽象インタフェイスの設計者によって、予め用意される。作成された第１のプロパティは、図示しない記憶装置等に予め記録し、これを読み出してもよく、図示しない入出力装置や通信回線等の任意の手段により検証装置１００の外部から供給されてもよい。

ここで、第１のプロパティとは、抽象インタフェイスが正しく動作するための条件を所定のプログラミング言語を用いて記述したものである。この条件とは、抽象インタフェイスの設計者が望ましいと考える、抽象インタフェイス内に記述された端子、信号、変数、演算式、文、ブロック、プラグマ、イベント等の要素の状態、換言すれば、電子回路が設計者の意図どおりに動作するための前提条件となるべき上記要素の状態を指定したものである。より具体的には、設計者は、例えば上掲の特開２００６−２８５３３３号公報において非特許文献１として示されている、ハリー・フォスター他、アサーションベースドデザイン、クルーワーアカデミックパブリッシャーズ、２００３年、第１−２０頁に記載された手法を用いて、第１のプロパティを作成することが可能である。

ついで、プロパティ変換手段１０４は、上述の対応関係記述に基づいて、第１のプロパティを第２のプロパティに変換する（ステップＳ１０５）。これをプロパティ変換という。

プロパティ変換は、プロパティ変換手段１０４が、第１のプロパティ内に記述されている端子、信号、変数、演算式、文、ブロック、プラグマ、イベント等の要素を、上述の対応関係記述をもとに置き換えることにより、第２のプロパティを生成して実現される。

第２のプロパティは、対応関係記述に基づいて生成される。そのため、同じ第１のプロパティから変換した場合であっても、異なる対応関係記述を用いて変換した場合の変換結果は異なるものとなり得る。そして、上述のように、対応関係記述は、基となる動作記述に応じて内容が異なるものであり得る。すなわち、第２のプロパティは、原則的に、検証対象である動作記述に応じてユニークな内容となる。プロパティ変換は、より具体的には、例えば上掲の特開２００６−２８５３３３号公報記載の技術により実施することができる。

最後に、プロパティ検証手段１０５は、ＲＴＬ記述が第２のプロパティに記述された条件を満たしているかどうかを検証する（ステップＳ１０６）。この検証処理をプロパティ検証という。

プロパティ検証は、例えば、Ｊ．Ｒ．Ｂｕｒｃｈ他，Ｓｙｍｂｏｌｉｃ Ｍｏｄｅｌ Ｃｈｅｃｋｉｎｇ：１０＾｛２０｝ Ｓｔａｔｅｓ ａｎｄ Ｂｅｙｏｎｄ， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ Ｆｉｆｔｈ Ａｎｎｕａｌ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｌｏｇｉｃ ｉｎ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ，１９９０，第４２８−４３９頁に記載の技術を利用することにより、実施することができる。

図３乃至図９を用いて、上記ステップＳ１０１乃至Ｓ１０６において用いられる動作記述、抽象インタフェイス及び第１のプロパティ、これらのステップにおいて作成されるＲＴＬ記述、対応関係記述及び第２のプロパティ、並びにプロパティ検証の結果の具体例を示す。

ステップＳ１０１において、入力手段１０１が入力を受付ける動作記述及び抽象インタフェイスの例を、図３乃至図４に示す。

図３に、動作記述の例（動作記述Ａ）を示す。動作記述Ａは、「ＳｙｓｔｅｍＣ言語」を用いて表記されているが、本実施の形態の説明に関連のない部分は一部省略されている。

動作記述Ａにはモジュールｆｏｏの動作が記述されている。モジュール ｆｏｏは、概略以下のような動作をする。入力有効端子ｉｎ０＿ｅｎ の値が真である時に入力端子ｉｎ０の値を読み出し、それをそのまま、出力端子ｏｕｔ０へ、出力有効端子ｏｕｔ０＿ｅｎの値が真である時に、書き出す。

図３の１行目乃至７行目は、ｆｏｏという名前のモジュールを定義するコードである。２行目乃至５行目では、入出力端子の宣言がなされている。モジュールｆｏｏは、入力端子ｉｎ０とその入力有効信号端子ｉｎ０＿ｅｎ、及び出力端子ｏｕｔ０とその出力有効信号端子ｏｕｔ０＿ｅｎを有する。さらに、６行目では、抽象インタフェイスｉｎｆ＿ｔ型の通信路ｉｎｆを有することが宣言されている。モジュールｆｏｏは、２つのスレッド（ＳＣ＿ＣＴＨＲＥＡＤ）ｉｎｉとｔａｒを有し、抽象インタフェイスの通信路ｉｎｆを介して通信する。この通信は、データ送出関数ｐｕｔ（）とデータ取得関数ｇｅｔ（）を用いて記述されている。

８行目乃至１８行目は、スレッドｉｎｉの定義を示している。１０行目では、スレッドｉｎｉは、１１行目乃至１６行目までの動作を永遠に繰り返すことが指定されている。１１行目乃至１４行目では、入力有効信号端子ｉｎ０＿ｅｎから値を一つ読み出し、その値が真（ｔｒｕｅ）でない間は１２行目記載のクロック境界を待つｗａｉｔ（）文を繰り返すことが指定されている。さらに、端子ｉｎ０＿ｅｎから読みだした値が真（ｔｒｕｅ）であれば、入力端子ｉｎ０から値を一つ読みだして変数ｖに格納することが指定されている。１５行目では、変数ｖの値を、データ送出関数ｐｕｔ（）により、通信路ｉｎｆを介して、スレッドｔａｒに送出することが指定されている。値の送出が完了すると、１６行目のｗａｉｔ（）文で、クロック境界を待つことが示されている。

１９行目乃至２９行目は、スレッドｔａｒの定義を示している。２１行目では、スレッドｔａｒは、スレッドｉｎｉと同様に、２２行目乃至２７行目の動作を永遠に繰り返すことが指定されている。２２行目乃至２４行目では、出力有効信号端子ｏｕｔ０＿ｅｎから値を一つ読み出し、その値が真（ｔｒｕｅ）でない間は２３行目記載のクロック境界を待つｗａｉｔ（）文を繰り返すことが指定されている。さらに、端子ｏｕｔ０＿ｅｎから読み出した値が真（ｔｒｕｅ）であれば、２５行目で、通信路ｉｎｆからデータ取得関数ｇｅｔ（）を用いて値を取得し、変数ｖに格納することが指定されている。２６行目では、通信路ｉｎｆからの値の取得が完了すると、出力端子ｏｕｔ０へ変数ｖの値を書き出すことが指定されている。その後、２７行目のｗａｉｔ（）文で、クロック境界を待つことが示されている。

図４に、抽象インタフェイスの例（抽象インタフェイスＡ）を示す。抽象インタフェイスＡは、抽象インタフェイスｉｎｆ＿ｔ型として定義されている。

図４の３行目乃至４行目では、抽象インタフェイスｉｎｆ＿ｔ型は、内部の変数として、転送される値を保持する端子ｄａｔ及び値を転送可能かどうかを示す端子ｖｌｄを有することが示されている。

５行目乃至１４行目は、抽象インタフェイスｉｎｆ＿ｔ型のデータ送出関数ｐｕｔ（）の定義を示している。６行目では、データ送出関数ｐｕｔ（）を実行するときに、同時にイベント＄ｉｎｉ．ｔｒａｎｓｆｅｒ＝１が発生することが示されている。このイベントは、第１のプロパティを作成する際に使用される。７行目乃至９行目では、端子ｖｌｄに値１を、端子ｄａｔに変数ｖａｌの値を書き出し、クロック境界を待つことが指定されている。１０行目乃至１３行目では、端子ｖｌｄ及び端子ｄａｔに、ともに値０を書き出し、クロック境界を待つことが指定されている。また、同時にイベント＄ｉｎｉ．ｔｒａｎｓｆｅｒ＝０が発生することが示されている。

１５行目乃至２４行目は、抽象インタフェイスｉｎｆ＿ｔ型のデータ取得関数ｇｅｔ（）の定義を示している。１７行目では、データ取得関数ｇｅｔ（）を実行するときに、同時にイベント＄ｔａｒ．ｗａｉｔ＝１が発生することが示されている。このイベントは、第１のプロパティを指定する際に使用される。１８行目乃至２０行目では、端子ｖｌｄから値を一つ読み出し、その値が真（ｔｒｕｅ）でない間は１９行目のクロック境界を待つ関数ｗａｉｔ（）を繰り返すことが指定されている。さらに、端子ｖｌｄの値が真（ｔｒｕｅ）であれば、２１行目で、端子ｄａｔから値を一つ読み出し、変数ｖａｌに格納することが指定されている。２３行目では、変数ｖａｌの値を、通信路から取得した値として返すことが指定されている。また、同時にイベント＄ｔａｒ．ｗａｉｔ＝０が発生することが示されている。

ステップＳ１０２において、動作合成手段１０２が動作合成を行うことによって作成するＲＴＬ記述の例を、図６に示す。

図６は、図３の動作記述Ａと図４に示された抽象インタフェイスＡとを用い、動作合成して作成した、ＲＴＬ記述の例（ＲＴＬ記述Ａ）を示している。ＲＴＬ記述Ａは、「ＳｙｓｔｅｍＣ言語」を用いて表記されているが、本実施の形態の説明に関連が薄い部分は一部省略されている。また、ＲＴＬ記述Ａは、データパス付拡張有限状態機械（Ｆｉｎｉｔｅ Ｓｔａｔｅ Ｍａｃｈｉｎｅ ｗｉｔｈ Ｄａｔａｐａｔｈ：ＦＳＭＤ）の形式で表現されている。ＦＳＭＤは、ＲＴＬの回路を、有限状態機械（ＦＳＭ）で表現される制御とＦＳＭの各状態での動作で表現する形式である。

図６の１行目乃至２３行目は、スレッドｉｎｉに対応するＲＴＬ記述を示している。スレッドｉｎｉに対応するＲＴＬ記述は、ＳＴ１、ＳＴ２及びＳＴ３の３つの状態を持つ。３行目乃至１０行目は、状態ＳＴ１の動作を示している。状態ＳＴ１の動作は、図３の１１行目乃至１４行目に示されている動作記述Ａの動作に対応している。状態ＳＴ１では、入力端子ｉｎ０＿ｅｎから値がひとつ読み出され、その値が真（ｔｒｕｅ）であれば入力端子ｉｎ０から値が読みだされる。読み出された値はレジスタＲＧ＿ｖに格納される。その後、クロック境界に同期して状態ＳＴ２に遷移する。一方、端子ｉｎ０＿ｅｎから読み出した値が真でない場合は、クロック境界に同期して再度状態ＳＴ１に遷移する。端子ｉｎ０＿ｅｎから読み出した値が真（ｔｒｕｅ）となるまで状態ＳＴ１の実行が繰り返される。１１行目乃至１５行目は、状態ＳＴ２の動作を示している。状態ＳＴ２の動作は、図３の１５行目に示されている動作記述Ａのデータ送出関数ｐｕｔ（）の動作に対応している。また、図４の抽象インタフェイスＡのデータ送出関数ｐｕｔ（）の定義における、６行目乃至９行目に対応している。状態ＳＴ２では、端子ｉｎｆ＿ｖｌｄに値ｔｒｕｅが書き出され、端子ｉｎｆ＿ｄａｔにレジスタＲＧ＿ｖの値が書き出される。同時に、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇに値１が書き出される。その後、クロック境界に同期して状態ＳＴ３に遷移する。１６行目乃至２１行目は、状態ＳＴ３の動作を示している。状態ＳＴ３の動作は、図３の１５行目に示されている動作記述Ａのデータ送出関数ｐｕｔ（）の動作に対応している。また、図４のデータ送出関数ｐｕｔ（）の定義における、１０行目乃至１３行目に対応している。状態ＳＴ３では、端子ｉｎｆ＿ｖｌｄおよび端子ｉｎｆ＿ｄａｔに、値ｆａｌｓｅおよび０がそれぞれ書き出される。その後、クロック境界に同期して状態ＳＴ３に遷移する。

２４行目乃至４８行目は、スレッドｔａｒに対応するＲＴＬ記述を示している。スレッドｔａｒに対応するＲＴＬ記述は、ＳＴ４、ＳＴ５及びＳＴ６の３つの状態を持つ。２６行目乃至３２行目は、状態ＳＴ４の動作を示している。状態ＳＴ４の動作は、図３の２２行目乃至２４行目に示されている動作記述Ａの動作に対応している。状態ＳＴ４では、入力端子ｏｕｔ０＿ｅｎから値が一つ読み出され、その値が真（ｔｒｕｅ）であれば、クロック境界に同期して状態ＳＴ５に遷移する。一方、端子ｏｕｔ０＿ｅｎから読み出された値が真でない場合は、クロック境界に同期して再度状態ＳＴ４に遷移する。端子ｏｕｔ０＿ｅｎから読み出された値が真（ｔｒｕｅ）となるまで状態ＳＴ４の実行が繰り返される。
３３行目乃至４１行目は、状態ＳＴ５の動作を示している。状態ＳＴ５の動作は、図３の２５行目に示されている動作記述Ａのデータ取得関数ｇｅｔ（）の動作に対応している。また、図４の抽象インタフェイスＡのデータ取得関数ｇｅｔ（）の定義における１７行目乃至２１行目に対応している。状態ＳＴ５では、端子ｉｎｆ＿ｖｌｄから値が一つ読み出され、その値が真（ｔｒｕｅ）であれば、さらに端子ｉｎｆ＿ｄａｔから値が一つ読み出され、その値がレジスタＲＧ＿ｗに格納される。その後、クロック境界に同期して状態ＳＴ５に遷移する。この時、同時に、端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇに値１が書き出される。端子ｉｎｆ＿ｖｌｄから読み出された値が真（ｔｒｕｅ）でなければ、クロック境界に同期して再度状態ＳＴ５に遷移する。端子ｉｎｆ＿ｖｌｄから読み出された値が真（ｔｒｕｅ）となるまで状態ＳＴ５の実行が繰り返される。４２行目乃至４６行目は、状態ＳＴ６の動作を示している。状態ＳＴ６の動作は、図３の２５行目に示されている動作記述Ａのデータ取得関数ｇｅｔ（）の動作に対応している。また、図４の抽象インタフェイスＡのデータ取得関数ｇｅｔ（）の定義における２２行目乃至２３行目に対応している。さらに、状態ＳＴ６の動作は、図３の２６行目乃至２７行目に示されている動作記述Ａの動作にも対応している。状態ＳＴ６では、レジスタＲＧ＿ｗの値が出力端子ｏｕｔ０に書き出される。同時に、端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇに値０が書き出される。その後、クロック境界に同期して状態ＳＴ４に遷移する。

ステップＳ１０３において、対応関係記述生成手段１０３が作成する対応関係記述の例を、図７に示す。

図７に、対応関係記述の例（対応関係記述Ａ）を示す。対応関係記述Ａでは、動作記述中のイベント名とＲＴＬ記述中の端子名の対応関係が特定されている。

対応関係記述Ａは、動作記述中の抽象インタフェイスｉｎｆ＿ｔ型の通信路ｉｎｆにおけるイベントｉｎｉ＿ｔｒａｎｓｆｅｒ（ｉｎｆ．ｉｎｉ＿ｔｒａｎｓｆｅｒ）が、ＲＴＬ記述中の端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇに対応していることを示している。同様に、動作記述中の抽象インタフェイスｉｎｆ＿ｔ型の通信路ｉｎｆにおけるイベントｔａｒ＿ｗａｉｔ（ｉｎｆ．ｔａｒ＿ｗａｉｔ）が、ＲＴＬ記述中の端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇに対応していることを示している。

ステップＳ１０４において、入力手段１０１が入力を受付ける第１のプロパティの例を、図５に示す。

図５に、第１のプロパティの例（第１のプロパティＡ）を示す。第１のプロパティは、図４の抽象インタフェイスＡ中に定義されているイベント＄ｉｎｉ．ｔｒａｎｓｆｅｒと＄ｔａｒ．ｗａｉｔを使用して定義されている。

図５の第１のプロパティＡは、＄ｉｎｉ．ｔｒａｎｓｆｅｒ＝１であるときには、必ず、同時に、＄ｔａｒ．ｗａｉｔ＝１であるべきことを示している。これは、すなわち、抽象インタフェイスｉｎｆ＿ｔ型の通信路を通じて値の授受をする場合、値の送出側が値を送出しようとしたときに、値の受け取り側は信号ｖｌｄの値が真（ｔｒｕｅ）になるまで待つ状態になければならないことを意味している。より具体的には、送出側が値の送出をするために送出関数ｐｕｔ（）を呼び出したときに、値の受け取り側は値を取得するための取得関数ｇｅｔ（）をあらかじめ呼び出していなければならないことを意味している。

ステップＳ１０５において、プロパティ変換手段１０４がプロパティ変換を行うことによって生成する第２のプロパティの例を、図８に示す。

図８に、第２のプロパティの例（第２のプロパティＡ）を示す。第２のプロパティＡは、図５の第１のプロパティＡに記述された動作記述Ａ中のイベントを、図７の対応関係Ａに基づいて、ＲＴＬ記述Ａ中の端子に置き換えることにより作成される。

第２のプロパティＡは、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇの値が１の時は、同時に端子ｉｎｆ＿ｔａｒ＿ｔｒａｎｓｆｅｒ＿ｆｌｇの値が１であるという性質を示している。すなわち、図６に示したＲＴＬ記述Ａにおいて、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇには状態ＳＴ２で値１が書き込まれること、端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇには状態ＳＴ５で値１が書き込まれることを勘案すると、スレッドｉｎｉに対応するＦＳＭが状態ＳＴ２に到達しデータ送出動作を行うときにはスレッドｔａｒに対応するＦＳＭが状態ＳＴ５にあらかじめ到達していなければならないことを指定していることになる。

ステップＳ１０６において、プロパティ検証手段１０５がプロパティ検証を行った結果の一出力例を、図９に示す。

図９に、プロパティ検証の結果を波形図として出力した例を示す。図９の波形図は、プロパティ検証手段１０５が発見した反例、すなわち図６に示されたＲＴＬ記述Ａが、図８に示された第２のプロパティＡを満たさない場合を示すものである。

図９の波形図を参照すると、時刻１で入力端子ｉｎ０＿ｅｎが真（ｔｒｕｅ）であるにもかかわらず、入力端子ｏｕｔ０＿ｅｎが真（ｔｒｕｅ）でない場合が発生する。そのため、スレッドｉｎｉに対応するＦＳＭが状態ＳＴ２に到達するにもかかわらず、スレッドｔａｒに対応するＦＳＭが状態ＳＴ４にとどまったままとなる。結果として、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇの値が１になっていても、端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇの値が０のままとなる。これは、図８に示された第２のプロパティＡに違反した結果である。これにより、図４の動作記述Ａと図５の抽象インタフェイスＡとを組合せて使用すると、データ転送が正しく行われない場合があることがわかる。

なお、このように、動作記述と抽象インタフェイスとの組合せが適切でないという問題が判明したならば、設計者は、動作記述又は抽象インタフェイスのいずれかを修正することにより、かかる問題に対処することができる。

図１０乃至図１５を用いて、設計者がとり得る対処方法と、かかる対処を行った後に再度プロパティ検証を行った結果の例を示す。

第１の対処方法は、動作記述を修正することである。図１０に、設計者が動作記述Ａを修正することにより作成した、動作記述の例（動作記述Ｂ）を示す。動作記述Ｂは、動作記述Ａに比べて、出力有効信号端子ｏｕｔ０＿ｅｎがなく、２２行目乃至２４行目の端子ｏｕｔ０＿ｅｎの値が真になるまで待つ動作がないことが異なる。

図１１に、動作合成手段１０２が、図１０の動作記述Ｂと図４に示された抽象インタフェイスＡとを用い、動作合成して作成した、ＲＴＬ記述の例（ＲＴＬ記述Ｂ）を示す。ＲＴＬ記述Ｂは、ＲＴＬ記述Ａに比べて、出力有効信号端子ｏｕｔ０＿ｅｎがなく、２６行目乃至３２行目までの状態ＳＴ４がないことが異なる。すなわち、端子ｏｕｔ０＿ｅｎの値が真になるまで待つ動作がないことが異なる。

また、対応関係記述生成手段１０３は、動作記述Ｂと抽象インタフェイスＡとに基づいて、対応関係記述を作成する。この対応関係記述は、図７に示した対応関係記述Ａと同一内容となる。

図１２に、プロパティ検証手段１０５がプロパティ検証を実施した結果の出力例を示す。図１２は、ＲＴＬ記述Ｂの実行例を波形図として出力したものである。今回は、プロパティ検証手段１０５は、図１１のＲＴＬ記述Ｂは、図８の第２のプロパティＡを満たすと判定している。図１２では、時刻２において、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇの値が１となるときに、端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇの値も１である。よって、第２のプロパティＡが満たされていることがわかる。確かに、スレッドｉｎｉが状態ＳＴ２に到達したときに、スレッドｔａｒの状態があらかじめＳＴ５に到達しているため、正しくデータ転送が行われている。

第２の対処方法は、抽象インタフェイスを修正することである。図１３に、抽象インタフェイスの設計者が抽象インタフェイスＡを修正して作成した、抽象インタフェイスの例（抽象インタフェイスＢ）を示す。抽象インタフェイスＢは、図４の抽象インタフェイスＡと比較して、端子ｅｎが追加されていることが異なる。また、データ送出関数ｐｕｔ（）の８行目乃至１０行目において、端子ｅｎから値を読み出し、その値が真（ｔｒｕｅ）になるまで待つ動作が追加されていることが異なる。さらに、データ取得関数ｇｅｔ（）の２４行目において、端子ｖｌｄから読み出した値が真（ｔｒｕｅ）になるまで待つ間に端子ｅｎに値ｔｒｕｅを書き出す動作が追加されていること、及び端子ｖｌｄから読み出した値が真（ｔｒｕｅ）であれば、端子ｅｎに値ｆａｌｓｅを書き出す動作が追加されていることが異なる。これらの違いにより、抽象インタフェイスＢの送出関数ｐｕｔ（）は、データ取得側が値の取得ができる状態になるまで待つように動作する点で、抽象インタフェイスＡの送出関数と異なる。

図１４に、動作合成手段１０２が、図３に示された動作記述Ａと図１３に示された抽象インタフェイスＢとを用い、動作合成して作成した、ＲＴＬ記述の例（ＲＴＬ記述Ｃ）を示す。ＲＴＬ記述Ｃは、ＲＴＬ記述Ａに比べて、スレッドｉｎｉに対応するＲＴＬ記述の状態ＳＴ２の動作内容が異なる。具体的には、端子ｉｎｆ＿ｅｎの値が真（ｔｒｕｅ）になるまで状態ＳＴ２を繰り返すことが異なる。すなわち、端子ｉｎｆ＿ｅｎから値を一つ読み出し、その値が真（ｔｒｕｅ）であるかどうかを検査する。端子ｉｎｆ＿ｅｎの値が真（ｔｒｕｅ）である場合は、端子ｉｎｆ＿ｖｌｄに値ｔｒｕｅを書き出し、端子ｉｎｆ＿ｄａｔにレジスタＲＧ＿ｖの値を書き出す。同時に、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇに値１を書き出す。さらに、クロック境界に同期して状態ＳＴ３に遷移する。端子ｉｎｆ＿ｅｎの値が真でない場合には、クロック境界に同期して、再度状態ＳＴ２に遷移する。これらの違いにより、ＲＴＬ記述Ｃは、データ取得側が値の取得ができる状態になるまでデータ送出側が待ち合わせるように動作する点で、ＲＴＬ記述Ａと異なる。

また、対応関係記述生成手段１０３は、動作記述Ａと抽象インタフェイスＢとに基づいて、対応関係記述を作成する。この対応関係記述は、図７に示した対応関係記述Ａと同一内容となる。

図１５に、プロパティ検証手段１０５がプロパティ検証を実施した結果の出力例を示す。図１５は、ＲＴＬ記述Ｃの実行例を波形図として出力したものである。この例でも、プロパティ検証手段１０５は、図１４のＲＴＬ記述Ｃは、図８の第２のプロパティＡを満たすと判定している。図１５では、時刻４において、端子ｉｎｆ＿ｉｎｉ＿ｔｒａｎｓｆｅｒ＿ｆｌｇの値が１となるときに、端子ｉｎｆ＿ｔａｒ＿ｗａｉｔ＿ｆｌｇの値も１である。よって、第２のプロパティＡが満たされていることがわかる。確かに、スレッドスレッドｔａｒの状態があらかじめＳＴ５に到達し端子ｉｎｆ＿ｅｎの値が真（ｔｒｕｅ）になるまで、スレッドｉｎｉが状態ＳＴ２で待つため、正しくデータ転送が行われている。

本実施の形態においては、抽象インタフェイスに対応する第１のプロパティが予め用意され、検証装置１００が、この第１のプロパティを、動作記述をＲＴＬ記述に変換する際にともに生成される対応関係記述に基づいて第２のプロパティに変換し、この第２のプロパティを用いてＲＴＬ記述のプロパティ検証を行う構成とした。これにより、動作記述の設計者は、動作記述を作成するたびに、動作記述に応じたプロパティを作成する必要がなく、動作記述と抽象インタフェイスの組み合わせによって起こり得る設計間違いを効率的に検出することができる。また、抽象インタフェイスの設計者は、抽象インタフェイスに対応する第１のプロパティを一度用意すれば、この第１のプロパティをどのような動作記述と組み合わせる場合であっても、同じ方法で、動作記述と抽象インタフェイスの組み合わせによって起こり得る設計間違いを効率的に検出することができる。

＜実施の形態２＞
図１６を用いて、本発明の実施の形態２にかかる検証装置１００の構成について説明する。

検証装置１００は、記憶手段１０６を備える点で、実施の形態１と異なる。その余の構成については、実施の形態１と同様である。

記憶手段１０６は、予め所与のデータを記憶し、他の手段の要求に応じてデータを記憶及び出力する機能を有する。具体的には、ＲＯＭ、ＲＡＭ、フラッシュメモリ、ハードディスク、ＳＳＤ、ＣＤ、ＤＶＤ、メモリカード等により実現され得る。

つぎに、図１７を用いて、本発明の実施の形態２における各手段の動作について説明する。

ステップＳ１０１乃至Ｓ１０３は、実施の形態１と同様である。すなわち、入力手段１０１は、検証対象である動作記述及び抽象インタフェイスの入力を受付ける（ステップＳ１０１）。つぎに、動作合成手段１０２は、動作記述をＲＴＬ記述に変換する（動作合成）（ステップＳ１０２）。また、対応関係記述生成手段１０３は、対応関係記述を生成する（ステップＳ１０３）。

かかる処理の後、入力手段１０１は、動作記述の中で使用されている抽象インタフェイスを特定する（ステップＳ２０１）。例えば、図３の動作記述Ａでは、６行目の記述から、ｉｎｆ＿ｔ型の抽象インタフェイスが使用されていることが特定できる。

つづいて、入力手段１０１は、記憶手段１０６を参照して、ステップＳ２０１で特定された抽象インタフェイスに対応する第１のプロパティを取得する。例えば、動作記述Ａで使用されている抽象インタフェイスはｉｎｆ＿ｔ型であった。図１６の記憶手段１０６を参照すると、ｉｎｆ＿ｔ型に対応する第１のプロパティとして、"ａｌｗａｙｓ（（＄ｉｎｉ．ｔｒａｎｆｅｒ＝＝１）−＞（＄ｔａｒ．ｗａｉｔ＝＝１））；"が記憶されている。よって、入力手段１０１は、この第１のプロパティを取得し、つづくステップの処理において使用する。

これらの処理の後、ステップＳ１０５乃至Ｓ１０６が実行される。ステップＳ１０５乃至Ｓ１０６は、実施の形態１と同様である。すなわち、プロパティ変換手段１０４は、対応関係記述に基づいて、ステップＳ２０２において記憶手段１０６から取得した第１のプロパティを、第２のプロパティに変換する（プロパティ変換）（ステップＳ１０５）。最後に、プロパティ検証手段１０５は、ＲＴＬ記述が第２のプロパティに記述された条件を満たしているかどうかを検証する（プロパティ検証）（ステップＳ１０６）。

本実施の形態においては、抽象インタフェイスに対応する第１のプロパティが予め記憶手段１０６に記録され、入力手段１０１は、プロパティ変換を行う際に自動的に第１のプロパティを取得するので、設計者はプロパティ変換の都度第１のプロパティを入力する必要がなく、動作記述と抽象インタフェイスの組み合わせによって起こり得る設計間違いを効率的に検出することができる。

＜実施の形態３＞
図１８を用いて、本発明の実施の形態３にかかる検証装置１００の構成について説明する。

検証装置１００は、出力手段１０７を備える点で、実施の形態１又は２と異なる。その余の構成については、実施の形態１又は２と同様である。

出力手段１０７は、ＣＲＴ、液晶ディスプレイ、プリンタ等によって構成され得る。

出力手段１０７は、プロパティ検証の結果を、例えば図９、図１５及び図２４に示すようなＲＴＬ記述の実行結果の波形図として出力することができる。

また、出力手段１０７は、ＲＴＬ記述の実行結果を、時系列の入出力データとして出力するものであってもよい。すなわち、各端子毎に、端子に入出力されるビット値を、クロック毎に並べた数列として出力することができる。

さらに、出力手段１０７は、ＲＴＬ記述の動作を再現するためのテストベンチを出力するものであってもよい。

＜実施の形態４＞
本発明の実施の形態４にかかる検証装置１００は、複数の抽象インタフェイスが予め用意されている場合に、これらの抽象インタフェイスから生成されるＲＴＬ記述を比較して、最も設計者の意図に沿うＲＴＬ記述を選択することを可能とするものである。

図１９を用いて、本発明の実施の形態４にかかる検証装置１００の構成について説明する。

検証装置１００は、記憶装置１０６及びＲＴＬ選択手段１０８を備える点で、実施の形態１と異なる。その余の構成については、実施の形態１と同様である。

記憶手段１０６は、予め所与のデータを記憶し、他の手段の要求に応じてデータを記憶及び出力する機能を有する。具体的には、ＲＯＭ、ＲＡＭ、フラッシュメモリ、ハードディスク、ＳＳＤ、ＣＤ、ＤＶＤ、メモリカード等により実現され得る。

ＲＴＬ選択手段１０８は、プログラムに基づいて各種制御を実行する機能を有し、具体的には、処理装置、記憶装置、入出力ポート等により実現され得る。

つぎに、図２０を用いて、本発明の実施の形態４における各手段の動作について説明する。

記憶手段１０６は、抽象インタフェイスとその抽象インタフェイスに対応する第１のプロパティとの組を複数含むライブラリを予め記憶しているものとする。この複数の抽象インタフェイスは、ＲＴＬ回路に変換されたとき、回路の面積、遅延、スループット等の点においてそれぞれ異なるパフォーマンスを示すものである。

はじめに、入力手段１０１は、記憶手段１０６のライブラリから抽象インタフェイス及び第１のプロパティの組を１組取得する（ステップＳ３０１）。以降、ステップＳ１０１、Ｓ１０２、Ｓ１０３、Ｓ１０５、Ｓ１０６及びＳ３０２の処理が、ここで取得した抽象インタフェイス及び第１のプロパティの組に対して実施される。この組に対する上記処理が完了したならば、入力手段１０１は、記憶手段１０６のライブラリから、既に取得したものとは異なる抽象インタフェイス及び第１のプロパティの組を１組取得し、この組に対し、上記ステップＳ１０１乃至Ｓ３０２の処理が再び実行される。同様の処理が、記憶手段１０６から、比較対象となるすべての抽象インタフェイス及び第１のプロパティの組が取得されるまで繰り返される。

上記ステップＳ１０１乃至Ｓ３０２の処理の内容を以下に示す。

まず、ステップＳ１０１乃至ステップＳ１０６の処理が行われる。各ステップにおける処理の内容は、実施の形態１と同様である。すなわち、入力手段１０１は、動作記述の入力を受付ける（ステップＳ１０１）。動作合成手段１０２は、ステップＳ１０1で入力された動作記述と、ステップＳ３０１で取得された抽象インタフェイスとを、ＲＴＬ記述に変換する（ステップＳ１０２）。対応関係記述生成手段１０３は、対応関係記述を生成する（ステップＳ１０３）。プロパティ変換手段１０４は、上述の対応関係記述に基づいて、ステップＳ３０１で取得された第１のプロパティを、第２のプロパティに変換する（ステップＳ１０５）。プロパティ検証手段１０５は、ＲＴＬ記述が第２のプロパティに記述された条件を満たしているかどうかを検証する（ステップＳ１０６）。

ここで、プロパティ検証手段１０５が、ＲＴＬ記述は第２のプロパティを満たすと判定した場合、ＲＴＬ選択手段１０８は、そのＲＴＬ記述を所定の評価関数により評価する（ステップＳ３０２）。この評価関数とは、ＲＴＬ記述を入力すると、そのＲＴＬ記述のパフォーマンス、例えば面積、遅延、スループット等について、定量的な評価値を出力することが可能な関数である。この評価関数は、回路設計者の設計意図に応じて適切なものが選択されるべきである。評価関数が出力した評価値は、所定の記憶領域に保持され、後の処理に利用される。

比較対象となるすべての抽象インタフェイス及び第１のプロパティの組について上述の処理が完了したならば、ＲＴＬ選択手段１０８は、ステップＳ３０２において出力された各ＲＴＬ記述の評価値に基づいて、設計者の設計意図に最も適合したＲＴＬ記述を選択する（ステップＳ３０３）。すなわち、評価関数による評価結果が所定の条件を満足するＲＴＬ記述を選択する。ここで、所定の条件は、回路設計者の設計意図に基づいて適宜決定することができる。

例えば、回路設計者が、最もスループットの大きい回路を設計することを意図している場合であれば、ＲＴＬ選択手段１０８を、ステップＳ３０２では、スループットが大きいほど大きな評価値を出力する評価関数を利用し、ステップＳ３０３においては、かかる評価関数の評価値が最も大きいＲＴＬ記述を選択するよう設計することができる。

本実施の形態においては、抽象インタフェイスと第１のプロパティとの複数の組が予め記憶手段１０６に記録され、入力手段１０１、動作合成手段１０２、対応関係記述生成手段１０３、プロパティ変換手段１０４及びプロパティ検証手段１０５が、その抽象インタフェイス及び第１のプロパティに基づいて正常に動作するＲＴＬ記述を複数出力し、ＲＴＬ選択手段１０８が、それらのＲＴＬ記述の中から所定の評価関数による評価結果が所定の条件を満足するＲＴＬ記述を選択するので、設計者は、設計意図に最も適合するＲＴＬ記述を効率的に得ることができる。

特に、本実施の形態においては、抽象インタフェイスと第１のプロパティとが予め対応付けられて記憶手段１０６に格納されているため、設計者は容易に複数のＲＴＬ記述を生成し、それらのＲＴＬ記述を比較検討することが可能である。

なお、本発明は上述した実施の形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

例えば、上述の実施の形態において示した処理の手順は、処理結果に影響を与えない範囲内において、適宜順序を変更して実施することが可能である。

また、上述の実施の形態では、ハードウェアの構成として説明したが、これに限定されるものではなく、任意の処理を、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）にコンピュータプログラムを実行させることにより実現することも可能である。この場合、コンピュータプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記実施の形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）
電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かを検証するための検証装置であって、
前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、
検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとが入力される入力手段と、
前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する動作合成手段と、
前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成する対応関係記述生成手段と、
前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換するプロパティ変換手段と、
前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するプロパティ検証手段とを有する
検証装置。

（付記２）
前記検証装置は記憶手段を更に有し、
前記記憶手段は、前記第１のプロパティを、前記抽象インタフェイスとの対応関係とともに予め記憶しており、
前記入力手段は、検証対象の前記動作記述中で利用されている前記抽象インタフェイスを特定し、特定された抽象インタフェイスに対応する前記第１のプロパティを前記記憶手段から取得する
付記１記載の検証装置。

（付記３）
前記検証装置は記憶手段及びＲＴＬ選択手段を更に有し、
前記記憶手段は、前記抽象インタフェイスと前記第１のプロパティとの組を複数含むライブラリを記憶しており、
前記ライブラリに含まれる前記抽象インタフェイスと前記第１のプロパティとの組のそれぞれについて、
前記入力手段は、前記抽象インタフェイスと前記第１のプロパティの組を前記記憶手段から取得し、
前記動作合成手段は、前記入力手段が取得した前記抽象インタフェイスと前記動作記述とを前記ＲＴＬ記述に変換し、
前記対応関係生成手段は、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
前記プロパティ変換手段は、前記入力手段が取得した前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
前記プロパティ検証手段は、前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証し、
前記ＲＴＬ選択手段は、前記プロパティ手段が正常に動作すると判断した前記ＲＴＬ記述であって、所定の評価関数による評価結果が所定のしきい値を満足する前記ＲＴＬ回路を選択する
付記１記載の検証装置。

（付記４）
前記検証装置は、前記検証結果を、前記電子回路の入出力動作を時系列に表示した波形図として出力する出力手段を更に有する
付記１乃至３いずれか１項に記載の検証装置。

（付記５）
前記検証装置は、前記検証結果を、前記電子回路の時系列の入出力データとして出力する出力手段を更に有する
付記１乃至３いずれか１項に記載の検証装置。

（付記６）
前記検証装置は、前記検証結果を、前記電子回路の動作を再現するためのテストベンチとして出力する出力手段を更に有する
付記１乃至３いずれか１項に記載の検証装置。

（付記７）
電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かを検証する方法であって、
前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、
検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとの入力を受けると、
前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する際、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証する
検証方法。

（付記８）
検証対象の前記動作記述中で利用されている前記抽象インタフェイスを特定し、
前記第１のプロパティを前記抽象インタフェイスとの対応関係とともに予め記憶している記憶手段から、前記特定された抽象インタフェイスに対応する前記第１のプロパティを取得する
付記７記載の検証方法。

（付記９）
記憶手段に複数記憶されている、前記抽象インタフェイスと前記第１のプロパティとの組のそれぞれについて、
前記抽象インタフェイスと前記第１のプロパティの組を前記記憶手段から取得し、
前記記憶手段から取得した前記抽象インタフェイスと前記動作記述とを前記ＲＴＬ記述に変換し、
前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
前記記憶手段から取得した前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証し、
前記プロパティ手段が正常に動作すると判断した前記ＲＴＬ記述であって、所定の評価関数による評価結果が所定のしきい値を満足する前記ＲＴＬ回路を選択する
付記７記載の検証方法。

（付記１０）
前記検証結果を、前記電子回路の入出力動作を時系列に表示した波形図として出力する
付記７乃至９いずれか１項に記載の検証方法。

（付記１１）
前記検証結果を、前記電子回路の時系列の入出力データとして出力する
付記７乃至９いずれか１項に記載の検証方法。

（付記１２）
前記検証結果を、前記電子回路の動作を再現するためのテストベンチとして出力する
付記７乃至９いずれか１項に記載の検証方法。

（付記１３）
電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かをコンピュータに検証させるプログラムであって、
前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、
前記コンピュータを、
検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとの入力を受けると、
前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する際、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するよう動作させる
検証プログラム。

（付記１４）
前記コンピュータを、
検証対象の前記動作記述中で利用されている前記抽象インタフェイスを特定し、
前記第１のプロパティを前記抽象インタフェイスとの対応関係とともに予め記憶している記憶手段から、前記特定された抽象インタフェイスに対応する前記第１のプロパティを取得するよう動作させる
付記１３記載の検証プログラム。

（付記１５）
前記コンピュータを、
記憶手段に複数記憶されている、前記抽象インタフェイスと前記第１のプロパティとの組のそれぞれについて、
前記抽象インタフェイスと前記第１のプロパティの組を前記記憶手段から取得し、
前記記憶手段から取得した前記抽象インタフェイスと前記動作記述とを前記ＲＴＬ記述に変換し、
前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
前記記憶手段から取得した前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証し、
前記プロパティ手段が正常に動作すると判断した前記ＲＴＬ記述であって、所定の評価関数による評価結果が所定のしきい値を満足する前記ＲＴＬ回路を選択するよう動作させる
付記１３記載の検証プログラム。

（付記１６）
前記コンピュータを、
前記検証結果を、前記電子回路の入出力動作を時系列に表示した波形図として出力するよう動作させる
付記１３乃至１５いずれか１項に記載の検証プログラム。

（付記１７）
前記コンピュータを、
前記検証結果を、前記電子回路の時系列の入出力データとして出力するよう動作させる
付記１３乃至１５いずれか１項に記載の検証プログラム。

（付記１８）
前記コンピュータを、
前記検証結果を、前記電子回路の動作を再現するためのテストベンチとして出力するよう動作させる
付記１３乃至１５いずれか１項に記載の検証プログラム。

１００ 検証装置
１０１ 入力手段
１０２ 動作合成手段
１０３ 対応関係記述生成手段
１０４ プロパティ変換手段
１０５ プロパティ検証手段
１０６ 記憶手段
１０７ 出力手段
１０８ ＲＴＬ選択手段

Claims (10)

1. 電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かを検証するための検証装置であって、
   前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、
   検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとが入力される入力手段と、
   前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する動作合成手段と、
   前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成する対応関係記述生成手段と、
   前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換するプロパティ変換手段と、
   前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するプロパティ検証手段とを有する
   検証装置。
2. 前記検証装置は記憶手段を更に有し、
   前記記憶手段は、前記第１のプロパティを、前記抽象インタフェイスとの対応関係とともに予め記憶しており、
   前記入力手段は、検証対象の前記動作記述中で利用されている前記抽象インタフェイスを特定し、特定された抽象インタフェイスに対応する前記第１のプロパティを前記記憶手段から取得する
   請求項１記載の検証装置。
3. 前記検証装置は記憶手段及びＲＴＬ選択手段を更に有し、
   前記記憶手段は、前記抽象インタフェイスと前記第１のプロパティとの組を複数含むライブラリを記憶しており、
   前記ライブラリに含まれる前記抽象インタフェイスと前記第１のプロパティとの組のそれぞれについて、
   前記入力手段は、前記抽象インタフェイスと前記第１のプロパティの組を前記記憶手段から取得し、
   前記動作合成手段は、前記入力手段が取得した前記抽象インタフェイスと前記動作記述とを前記ＲＴＬ記述に変換し、
   前記対応関係記述生成手段は、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
   前記プロパティ変換手段は、前記入力手段が取得した前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
   前記プロパティ検証手段は、前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証し、
   前記ＲＴＬ選択手段は、前記プロパティ検証手段が正常に動作すると判断した前記ＲＴＬ記述であって、所定の評価関数による評価結果が所定のしきい値を満足する前記ＲＴＬ記述を選択する
   請求項１記載の検証装置。
4. 前記検証装置は、前記検証結果を、前記電子回路の入出力動作を時系列に表示した波形図として出力する出力手段を更に有する
   請求項１乃至３いずれか１項に記載の検証装置。
5. 前記検証装置は、前記検証結果を、前記電子回路の時系列の入出力データとして出力する出力手段を更に有する
   請求項１乃至３いずれか１項に記載の検証装置。
6. 前記検証装置は、前記検証結果を、前記電子回路の動作を再現するためのテストベンチとして出力する出力手段を更に有する
   請求項１乃至３いずれか１項に記載の検証装置。
7. 電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かをコンピュータが検証する方法であって、
   前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、
   前記コンピュータが、
   検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとの入力を受けると、
   前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する際、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
   前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
   前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証する
   検証方法。
8. 前記コンピュータが、
   検証対象の前記動作記述中で利用されている前記抽象インタフェイスを特定し、
   前記第１のプロパティを前記抽象インタフェイスとの対応関係とともに予め記憶している記憶手段から、前記特定された抽象インタフェイスに対応する前記第１のプロパティを取得する
   請求項７記載の検証方法。
9. 記憶手段に複数記憶されている、前記抽象インタフェイスと前記第１のプロパティとの組のそれぞれについて、
   前記コンピュータが、
   前記抽象インタフェイスと前記第１のプロパティの組を前記記憶手段から取得し、
   前記記憶手段から取得した前記抽象インタフェイスと前記動作記述とを前記ＲＴＬ記述に変換し、
   前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
   前記記憶手段から取得した前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
   前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証し、
   正常に動作すると判断した前記ＲＴＬ記述であって、所定の評価関数による評価結果が所定のしきい値を満足する前記ＲＴＬ記述を選択する
   請求項７記載の検証方法。
10. 電子回路の動作をプログラミング言語により記述した動作記述が、正常に動作するものか否かをコンピュータに検証させるプログラムであって、
    前記動作記述は、所定のプログラミング言語で記述され、入出力処理をモジュール化した抽象インタフェイスを利用して記述されたものであり、
    前記コンピュータを、
    検証対象の前記動作記述と、前記抽象インタフェイスが正常に動作するための条件が記述されたものであって、前記抽象インタフェイスに対応して予め用意された第１のプロパティとの入力を受けると、
    前記動作記述を、前記電子回路の構成を記述したＲＴＬ記述に変換する際、前記動作記述と前記ＲＴＬ記述との対応関係を記述した対応関係記述を生成し、
    前記第１のプロパティを、前記対応関係記述に記述された対応関係に従って、第２のプロパティに変換し、
    前記第２のプロパティに基づき、前記ＲＴＬ記述が正常に動作するか否かを検証するよう動作させる
    検証プログラム。

Images