JP6331400B2 - 検証方法、検証装置および検証プログラム - Google Patents

Description

本発明は検証方法、検証装置および検証プログラムに関する。

現在、電子装置などの開発では、予め用意された所定の機能を実現する回路（ＩＰ（Intellectual Property）と呼ばれることがある）を組み込んで利用することがある。ＩＰを用いることで、電子装置の設計期間の短縮化を図れる。

ここで、電子装置の設計では、電子装置に実装される回路が意図した動作を行うか否かを検証することで、品質の向上が図られている。例えば、テストパターンを用いた論理シミュレーションにより、ＬＳＩ（Large-Scale Integration）の設計の正しさを確かめる検証を行うことが考えられている。また、テストパターンを用いることなく網羅的な検証を行う形式的手法に基づく検証も考えられている。

更に、ハードウェアモジュールの設計内容に関するハードウェア記述情報およびハードウェアモジュールの通信手順に関するインタフェース仕様記述情報に基づいて、ハードウェアモジュールの動作を論理検証する方法も提案されている。この提案では、インタフェース仕様記述情報の内容から、ハードウェアモジュールの状態遷移を認識する。

特開２０１１−３４５１７号公報 特開２００６−５３８１３号公報

ところで、ＩＰの動作仕様に対する検証はＩＰの提供元により行われる。これに対し、ＩＰを実装した装置を開発する利用側でも、装置に実装して問題なく利用できることを確認するためにＩＰの動作検証を行うことがある。ＩＰの提供元での検証は提供元の基準で行われるものであり、実装されたＩＰが適切に動作するかは不明だからである。

そこで、論理シミュレーション（例えば、テスト用の入力ベクタに対する出力の判定など）により、実装を考慮したＩＰの検証を行うことが考えられる。しかし、実際の利用時に想定される入力の組み合わせや順序などには際限がなく、どの程度まで検証を行えばよいかが明確でない。このため、テスト用の入力ベクタをあらゆる状況を想定して網羅的に作成することは容易ではなく、入力ベクタの作成には手間と時間がかかるという問題がある。

１つの側面では、本発明は、入力ベクタの効率的な作成を支援する検証方法、検証装置および検証プログラムを提供することを目的とする。

１つの態様では、検証方法が提供される。この検証方法では、コンピュータが、入力ベクタを用いた検証対象の回路の論理シミュレーションにより取得された回路の出力信号を参照して当該出力信号の変化のパターンを検出し、検出結果に応じて入力ベクタに対して発生した回路の内部状態の遷移を示す情報を生成し、生成した情報に基づいて、回路の仕様モデルを用いた形式的検証により特定される回路の内部状態の遷移のうち、上記の入力ベクタを用いた論理シミュレーションでは発生しない遷移の情報を出力し、上記パターンの検出では、入力ベクタをランダムに生成し、生成した入力ベクタを用いて回路の論理シミュレーションを実行することで、回路の出力に対応する変数値の組の変化を検出し、変数値の組の変化と回路の内部状態の遷移との対応関係を示す情報を参照して、検出された変数値の組の変化を検索し、当該変化に対応する内部状態の遷移に対して入力ベクタを生成済みであることを記録する。

また、１つの態様では、検証装置が提供される。この検証装置は、記憶部と演算部とを有する。記憶部は、検証対象の回路に対する入力ベクタを記憶する。演算部は、入力ベクタを用いた回路の論理シミュレーションにより取得された回路の出力信号を参照して当該出力信号の変化のパターンを検出し、検出結果に応じて入力ベクタに対して発生した回路の内部状態の遷移を示す情報を生成し、生成した情報に基づいて、回路の仕様モデルを用いた形式的検証により特定される回路の内部状態の遷移のうち、上記の入力ベクタを用いた論理シミュレーションでは発生しない遷移の情報を出力する。演算部は、上記パターンの検出では、入力ベクタをランダムに生成し、生成した入力ベクタを用いて回路の論理シミュレーションを実行することで、回路の出力に対応する変数値の組の変化を検出し、変数値の組の変化と回路の内部状態の遷移との対応関係を示す情報を参照して、検出された変数値の組の変化を検索し、当該変化に対応する内部状態の遷移に対して入力ベクタを生成済みであることを記録する。

また、１つの態様では、コンピュータによって実行される検証プログラムが提供される。この検証プログラムは、コンピュータに、入力ベクタを用いた検証対象の回路の論理シミュレーションにより取得された回路の出力信号を参照して当該出力信号の変化のパターンを検出し、検出結果に応じて入力ベクタに対して発生した回路の内部状態の遷移を示す情報を生成し、生成した情報に基づいて、回路の仕様モデルを用いた形式的検証により特定される回路の内部状態の遷移のうち、上記の入力ベクタを用いた論理シミュレーションでは発生しない遷移の情報を出力し、上記パターンの検出では、入力ベクタをランダムに生成し、生成した入力ベクタを用いて回路の論理シミュレーションを実行することで、回路の出力に対応する変数値の組の変化を検出し、変数値の組の変化と回路の内部状態の遷移との対応関係を示す情報を参照して、検出された変数値の組の変化を検索し、当該変化に対応する内部状態の遷移に対して入力ベクタを生成済みであることを記録する処理を実行させる。

１つの側面では、入力ベクタの効率的な作成を支援できる。

第１の実施の形態の検証装置を示す図である。 第２の実施の形態の検証装置のハードウェア例を示す図である。 検証装置の機能例を示すブロック図である。 状態チェックテーブルの例を示す図である。 状態遷移と出力信号の変化との対応関係の例を示す図である。 入力ベクタの生成処理の例を示すフローチャートである。 検証処理の例を示すフローチャートである。 制約データの生成例を示す図である。 ＳＰＩＮを用いた検証の例を示す図である。 制約データ（ＮｅｖｅｒＣｌａｉｍ）の例を示す図である。 反例パターンの例（その１）を示す図である。 反例パターンの例（その２）を示す図である。 論理シミュレーションで未カバーである状態遷移の例を示す図である。 検証範囲の例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の検証装置を示す図である。検証装置１は、回路２の動作の検証を行う。回路２はＩＰと呼ばれるものでもよい。回路２は、例えば電子装置に組み込まれて、電子装置の所定の機能の一部（例えば、ＵＳＢ（Universal Serial Bus）などの規格による機能）を担う。回路２は、その提供元により仕様（例えば、ＵＳＢなどの規格による仕様）に応じた動作の検証が行われている。一方、回路２を提供元から取得し、回路２を実装した電子装置を設計する開発者は、電子装置に実装された回路２が適切に動作するかを、検証装置１を用いて再度検証する。

検証装置１は、回路２の動作をコンピュータ上でシミュレートすることで回路２の動作検証を行える。例えば、検証装置１は、電子装置に実装された回路２のＲＴＬ（Register Transfer Level）記述を用いて、テスト用の入力ベクタを回路２に入力したときの出力信号をシミュレートする。ここで、入力ベクタは、回路２に対して与える入力信号の時系列変化を記述した情報である。検証装置１は、入力信号に対する出力信号の正否を判定することで、実装後も回路２が期待した動作を行うかを検証する。

検証装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂはプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。

記憶部１ａは、回路２に入力する入力ベクタを記憶する。入力ベクタは、演算部１ｂにより所定の方法により生成（例えば、ランダム生成）されたものでもよい。
演算部１ｂは、記憶部１ａに記憶された入力ベクタを用いた回路２の論理シミュレーションにより取得された回路２の出力信号を参照して出力信号の変化のパターンを検出する。演算部１ｂは、出力信号の変化のパターンの検出結果に応じて入力ベクタに対して発生した回路２の内部状態の遷移（状態遷移）を示す情報を生成する。演算部１ｂは生成した情報を記憶部１ａに格納する。例えば、演算部１ｂは、論理シミュレーションによって得られた回路２の出力信号を統計的に解析することで、出力信号の変化のパターンを検出する。

ここで、出力信号の変化のパターンと、仕様から得られる回路２の状態遷移との対応を示す情報は予め作成され、記憶部１ａに格納される。演算部１ｂは、記憶部１ａに記憶された当該情報と出力信号の変化のパターンとを照合して、信号変化のパターンに対応する状態遷移を特定できる。

例えば、演算部１ｂは、記憶部１ａに記憶された入力ベクタを用いて回路２に関する次のような状態遷移を特定する。状態Ｓ０−＞状態Ｓ１。状態Ｓ１−＞状態Ｓ２。状態Ｓ２−＞状態Ｓ０。ここで、“−＞”の表記は右向きの矢印を表し、当該表記の左側の状態から右側の状態へ遷移することを示す（以下同様）。例えば、“状態Ｓ０−＞状態Ｓ１”の表記は、状態Ｓ０から状態Ｓ１への遷移を示している。これらの状態遷移は、現状の入力ベクタによる論理シミュレーションで検証可能な（カバー済の）状態遷移といえる。演算部１ｂは、回路２に対する制約を示す線形時相論理（ＬＴＬ：Linear Temporal Logic）式を用いて、現状の論理シミュレーションで検証可能な状態遷移を記述し得る。

演算部１ｂは、入力ベクタに対して発生した回路２の状態遷移の情報に基づいて、回路２の仕様モデルを用いた形式的検証により特定される回路２の状態遷移のうち、現状の入力ベクタを用いた論理シミュレーションでは発生しない状態遷移の情報を出力する。

ここで、回路２の仕様モデルは、回路２の形式仕様記述（例えば、Ｐｒｏｍｅｌａ（Process Meta Language）と呼ばれる言語による記述）である。例えば、Ｐｒｏｍｅｌａで記述された仕様モデルは、ＳＰＩＮ（Simple Promela INterpreter）と呼ばれるモデル検証ツールによる形式的検証に用いられる。Ｐｒｏｍｅｌａ記述の仕様モデルに対する制約式はＮｅｖｅｒＣｌａｉｍと呼ばれる記述で表せる。

演算部１ｂは、仕様モデルを用いた形式的検証により、回路２の仕様上の動作に応じた状態遷移を再現する。例えば、次のような状態遷移を再現する。状態Ｓ０−＞状態Ｓ１−＞状態Ｓ２−＞状態Ｓ０（状態Ｓ０を起点に状態Ｓ１，Ｓ２，Ｓ０と順に遷移することを示す）。状態Ｓ０−＞状態Ｓ１−＞状態Ｓ２−＞状態Ｓ１（状態Ｓ０を起点に状態Ｓ１，Ｓ２，Ｓ１と順に遷移することを示す）。状態Ｓ０−＞状態Ｓ１−＞状態Ｓ３（状態Ｓ０を起点に状態Ｓ１，Ｓ３と順に遷移することを示す）。これらの状態遷移は、仕様モデルから得られる状態遷移といえる。

この場合、演算部１ｂは、記憶部１ａに記憶された入力ベクタでは発生しない回路２の状態遷移として次のような遷移の情報を出力する。状態Ｓ２−＞状態Ｓ１。状態Ｓ１−＞状態Ｓ３。これらの状態遷移は、現状の入力ベクタによる論理シミュレーションでは検証できない（未カバーの）状態遷移である。

検証装置１によれば、入力ベクタを回路２に入力する論理シミュレーションにより取得された回路２の出力信号が参照されて、出力信号の変化のパターンが検出される。検出結果に応じて、入力ベクタに対して発生した回路２の内部状態の遷移を示す情報が生成される。生成された情報に基づいて、回路２の仕様モデルを示す仕様データを用いて特定される回路２の内部状態の遷移のうち、現状の入力ベクタを用いた論理シミュレーションでは発生しない遷移の情報が出力される。これにより、入力ベクタの効率的な作成を支援できる。

具体的には、演算部１ｂにより出力された状態遷移（「状態Ｓ２−＞状態Ｓ１」の遷移や「状態Ｓ１−＞状態Ｓ３」の遷移）は仕様上の動作では発生し得る。しかし、論理シミュレーションによりこれらの状態遷移が発生しないということは、入力ベクタの内容が現状では不足していることを意味する。したがって、電子装置の開発者は、出力された情報を参照して、「状態Ｓ２−＞状態Ｓ１」の遷移や「状態Ｓ１−＞状態Ｓ３」の遷移を論理シミュレーションでカバーできるよう、不足している入力ベクタの内容を補完し得る。未カバーの状態遷移が発生するように入力ベクタの内容を補完していけば、仕様で規定された機能に対する検証の網羅率（カバレッジ）を向上していくことができる。

このように、入力ベクタの作成の目標を「仕様上の動作をカバーできる」点にすることで、実装に対して起こり得る回路２の全ての内部状態を実現するよう入力ベクタを作成するよりも、入力ベクタの作成作業の効率化（例えば、作成作業の短縮化）を図れる。また、仕様上の動作をカバーするように検証を行えるので、基準を定めずに作成した入力ベクタを用いて検証を行うよりも、より現実的で有意義なテスト内容に絞り込めることになる。よって、回路２の動作検証の効率化（例えば、動作検証の短縮化）を図れる。

［第２の実施の形態］
図２は、第２の実施の形態の検証装置のハードウェア例を示す図である。検証装置１００は、電子装置に実装するＩＰの動作検証を行うコンピュータである。検証装置１００は、ＩＰの提供元からＩＰを取得して、電子装置を開発する開発者によって利用される。検証装置１００は、提供元から取得したＩＰが電子装置に組み込んで適正に動作することの検証に用いられる。

検証装置１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力処理部１０５、読み取り装置１０６および通信インタフェース１０７を有する。各ユニットが検証装置１００のバスに接続されている。

プロセッサ１０１は、検証装置１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、検証装置１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。

ＨＤＤ１０３は、検証装置１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。検証装置１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

画像信号処理部１０４は、プロセッサ１０１からの命令に従って、検証装置１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、有機ＥＬ（Electro-Luminescence）ディスプレイなど各種のディスプレイを用いることができる。

入力処理部１０５は、検証装置１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、マウスやタッチパネルなどのポインティングデバイス、キーボード、ボタンスイッチなど各種の入力デバイスを用いることができる。また、検証装置１００には複数の種類の入力デバイスが接続されてもよい。

読み取り装置１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。読み取り装置１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信インタフェース１０７は、ネットワーク１０を介して他のコンピュータ（例えば、サーバコンピュータ）と通信を行う。
図３は、検証装置の機能例を示すブロック図である。検証装置１００は、記憶部１１０，１２０、入力ベクタ生成部１３０、制約生成部１４０および検証部１５０を有する。記憶部１１０，１２０は、ＲＡＭ１０２やＨＤＤ１０３に確保された記憶領域を用いて実現できる。入力ベクタ生成部１３０、制約生成部１４０および検証部１５０は、プロセッサ１０１によって実行されるプログラムのモジュールであってもよい。

記憶部１１０は、形式的検証に用いられるデータや形式的検証の結果を示すデータを記憶する。具体的には、記憶部１１０は、仕様データ１１１、制約データ１１２およびＦａｉｌパターンデータ１１３を記憶する。

仕様データ１１１は、ＩＰの仕様モデルを示すデータである。例えば、仕様データ１１１は、ＩＰの仕様書から開発者（ユーザということがある）により予め作成され、記憶部１１０に格納される。仕様データ１１１は、Ｐｒｏｍｅｌａと呼ばれるモデル記述言語を用いて作成される。すなわち、仕様データ１１１は、自然言語で表されたＩＰの仕様からユーザにより作成された仕様モデルのＰｒｏｍｅｌａ記述である。

制約データ１１２は、実装されたＩＰ（実装ＩＰということがある）の動作を記述したデータである。制約データ１１２は、実装されたＩＰの論理シミュレーションの結果に基づいて、制約生成部１４０によりＬＴＬ式や手続き型プログラミング言語を用いて生成される。なお、論理シミュレーションには、例えば所定のＥＤＡ（Electronic Design Automation）ツールを利用し得る。また、「制約データ」という名称は、後述するモデル検証ツールにおいて、ＬＴＬ式や手続き型プログラミング言語による記述が仕様モデルに対する制約として扱われる点を考慮したものである。

Ｆａｉｌパターンデータ１１３は、仕様データ１１１と制約データ１１２とを用いた形式的検証の結果、仕様データ１１１からは導かれるが、制約データ１１２で規定された条件に合致しない状態遷移（反例の状態遷移）を示すデータである。

記憶部１２０は、論理シミュレーションに用いられるデータを記憶する。具体的には、記憶部１２０は、実装ＩＰデータ１２１、入力ベクタ１２２および状態チェックテーブル１２３を記憶する。実装ＩＰデータ１２１は、論理シミュレーションによる検証対象の回路を記述したデータである。具体的には、実装ＩＰデータ１２１は、所定のハードウェア記述言語（ＨＤＬ：Hardware Description Language）を用いた実装ＩＰのＲＴＬ記述である。ＨＤＬでは、例えば、入出力信号などに対応する変数を用いて検証対象の回路が記述される。信号の入出力用のポートは、ＩＰの仕様で規定されるインタフェースに予め対応付けられる。入力ベクタ１２２は、実装ＩＰの論理シミュレーションに用いられる入力ベクタである。入力ベクタ１２２は、１つ以上用意されることになる。

状態チェックテーブル１２３は、ＩＰの仕様モデルにおける状態遷移と実装ＩＰデータ１２１上の出力信号に対応する変数値の組の変化との対応関係を示す情報である。当該対応関係は、仕様データ１１１および実装ＩＰデータ１２１に基づいてユーザにより予め特定され、状態チェックテーブル１２３に登録される。ただし、仕様データ１１１および実装ＩＰデータ１２１の記述ルールに基づいて、検証装置１００が状態チェックテーブル１２３を生成することも考えられる。後述するように、状態チェックテーブル１２３に登録される対応関係では少なくとも２状態間の遷移に対する変数値の組の変化が登録されていればよい。

入力ベクタ生成部１３０は、入力ベクタをランダムに生成する。入力ベクタ生成部１３０は、生成した入力ベクタを用いて実装ＩＰの論理シミュレーションを実行する。入力ベクタ生成部１３０は、論理シミュレーションにより得られる実装ＩＰからの出力信号に対応する変数値の組の変化を検出し、生成した入力ベクタにより状態チェックテーブル１２３の何れの状態遷移が発生したかを記録する。

制約生成部１４０は、入力ベクタ生成部１３０が生成した入力ベクタによる論理シミュレーションの結果に基づいて、制約データ１１２を生成する。具体的には、制約生成部１４０は、論理シミュレーションの結果として得られた出力信号を解析し、出力信号の因果関係の定型のパターン（例えば、コマンド“Ａ”が発生した後に、コマンド“Ｂ”が発生するという事象が頻繁に起こる、など）を抽出する。制約生成部１４０は、定型のパターンの抽出結果を基に制約データ１１２を生成する。

検証部１５０は、仕様データ１１１および制約データ１１２を用いて形式的手法による検証（形式的検証）を行い、検証結果を出力する。具体的には、検証部１５０は、検証に失敗した状態遷移の情報をＦａｉｌパターンデータ１１３として出力する。形式的検証を行うツールとして、ＳＰＩＮを想定する。制約データ１１２は、Ｐｒｏｍｅｌａ記述の仕様データ１１１に対するＮｅｖｅｒＣｌａｉｍである。

ここで、ＳＰＩＮによるモデル検証の方法としては、文献“吉岡信和、外２名、「ＳＰＩＮによる設計モデル検証」、２００８年９月、近代科学社、８５頁−９５頁”を参考にできる。この文献には、交差点に設けられた２つの信号機の例により、Ｐｒｏｍｅｌａ、ＮｅｖｅｒＣｌａｉｍおよび反例出力の具体例が示されている。

図４は、状態チェックテーブルの例を示す図である。状態チェックテーブル１２３は、状態遷移、変数、変数と条件および生成チェックフラグの項目を含む。状態遷移の項目には、仕様から特定されるＩＰの状態遷移の情報が登録される。変数の項目には、複数の出力信号に対応する実装ＩＰデータ１２１上の変数の組を示す情報が登録される。変数と条件の項目には、状態遷移に対応する変数値の組の変化を示す情報が登録される。生成チェックフラグの項目には、変数値の組の変化（すなわち、状態遷移）に対応する入力ベクタを生成済か否かを示すフラグが登録される（“ｔｒｕｅ”なら生成済であり、“ｆａｌｓｅ”なら未生成である）。生成チェックフラグの初期値は“ｆａｌｓｅ”である。

例えば、状態チェックテーブル１２３には、状態遷移が“Ｓ０−＞Ｓ１”、変数が“（ｘ，ｙ）”、変数と条件が“（０，０）−＞（１，０）”、生成チェックフラグが“ｔｒｕｅ”という情報が登録されている。この情報は、ＩＰの仕様上の状態遷移“Ｓ０−＞Ｓ１”（状態Ｓ０から状態Ｓ１への遷移）が実装ＩＰデータ１２１における変数“（ｘ，ｙ）”の値の変化“（０，０）−＞（１，０）”に対応しており、当該変化を発生させる入力ベクタを生成済であることを示す。

図５は、状態遷移と出力信号の変化との対応関係の例を示す図である。図５では、論理シミュレーションにより得られた３つの信号（変数ＣＬＫ，ｘ，ｙに相当する３つの信号）の波形を例示している。例えば、変数（ｘ，ｙ）の値の組（０，０）が、ＩＰの状態Ｓ０に相当する。変数（ｘ，ｙ）の値の組（１，１）が、ＩＰの状態Ｓ２に相当する。変数（ｘ，ｙ）の値の組（１，０）が、ＩＰの状態Ｓ１に相当する。

例えば、変数（ｘ，ｙ）について、信号（または、変数）の因果関係から“（０，０）の後に（１，１）へ変化”するという変化パターンを抽出できれば、状態Ｓ０から状態Ｓ１への遷移が実現されたことになる。同様に、変数（ｘ，ｙ）について、信号（または、変数）の因果関係から“（１，０）の後に（０，０）へ変化”するという変化パターンを抽出できれば、状態Ｓ１から状態Ｓ０への遷移が実現されたことになる。

次に、検証装置１００の処理手順を説明する。まず、入力ベクタの生成処理を説明する。
図６は、入力ベクタの生成処理の例を示すフローチャートである。以下、図６に示す処理をステップ番号に沿って説明する。

（Ｓ１１）入力ベクタ生成部１３０は、回数閾値ｎ（ｎは１以上の整数）、回数ｋ＝０を設定する。回数閾値ｎとしては、開発する装置のテスト規模に応じた値がユーザにより予め設定される。回数ｋは、入力ベクタの生成回数を示す変数である。

（Ｓ１２）入力ベクタ生成部１３０は、回数ｋが回数閾値ｎよりも小さい（ｋ＜ｎ）か否かを判定する。回数ｋが回数閾値ｎよりも小さい場合、処理をステップＳ１３に進める。回数ｋが回数閾値ｎよりも小さくない場合（すなわち、回数ｋが回数閾値ｎと等しい場合）、処理を終了する。

（Ｓ１３）入力ベクタ生成部１３０は、回数ｋにｋ＋１を代入する。
（Ｓ１４）入力ベクタ生成部１３０は、実装ＩＰの論理シミュレーションを行うための入力ベクタをランダム生成する。なお、入力ベクタの生成方法としては種々の方法が考えられる。例えば、ステップＳ１４を繰り返し実行するたびに、１つの入力ベクタのファイル内に、複数の入力信号の時系列の変化のパターンを順次追加していってもよい（何れかの入力信号を固定して他の入力信号を変更するなど）。また、例えば、ステップＳ１４を繰り返し実行するたびに、新しい入力ベクタのファイルを生成していってもよい。

（Ｓ１５）入力ベクタ生成部１３０は、ステップＳ１４で生成した入力ベクタを用いて、実装ＩＰの論理シミュレーションを実行する。入力ベクタ生成部１３０は、論理シミュレーションの結果（実装ＩＰの出力信号のデータを含む）を記憶部１２０に格納する。

（Ｓ１６）入力ベクタ生成部１３０は、状態チェックテーブル１２３を参照して、実装ＩＰデータ１２１における変数値の組の変化から、論理シミュレーションにより実現された状態遷移を特定する。ここで、入力ベクタ生成部１３０は、状態チェックテーブル１２３のレコードうち、生成チェックフラグが“ｆａｌｓｅ”のレコードを順番に走査していけばよい。

（Ｓ１７）入力ベクタ生成部１３０は、ステップＳ１６で特定した状態遷移に対応する入力ベクタを生成済であることを状態チェックテーブル１２３に記録する。具体的には、入力ベクタ生成部１３０は、ステップＳ１６で特定された状態遷移（変数値の組の変化）に対し、状態チェックテーブル１２３の生成チェックフラグを“ｆａｌｓｅ”から“ｔｒｕｅ”に変更する。

（Ｓ１８）入力ベクタ生成部１３０は、状態チェックテーブル１２３に登録された全ての状態遷移に対して、入力ベクタを生成済である旨が記録されたか否かを判定する。全ての状態遷移に対して入力ベクタを生成済である場合、処理を終了する。全ての状態遷移に対して入力ベクタを生成済でない場合、処理をステップＳ１２に進める。

このようにして、検証装置１００は、状態チェックテーブル１２３に登録された各状態遷移を実現する入力ベクタを生成していく。図６の手順の直後では、状態チェックテーブル１２３に登録された全ての状態遷移を網羅する入力ベクタが生成されていなくてもよい。すなわち、状態チェックテーブル１２３に登録された全ての状態遷移に対応する入力ベクタが生成されていなくても、入力ベクタの生成を終えることを許容する。後述するモデル検証の結果から、不足の入力ベクタを事後的に補完できるためである。このため、上記入力ベクタの生成処理を高速化できる。

また、例えば、ステップＳ１６では少なくとも２状態間での１回の状態遷移が特定されていればよい。連続した状態遷移については、後述する検証部１５０によるモデル検証で特定できるためである。このため、例えば、ステップＳ１６で２状態間での１回の状態遷移に限定して特定するよう制御すれば、状態遷移の特定を高速に行える。その結果、上記入力ベクタの生成処理を高速化できる。

なお、ステップＳ１６で、状態チェックテーブル１２３に登録された状態遷移を特定できない場合も考えられる。この場合、入力ベクタ生成部１３０は、ステップＳ１７をスキップしてステップＳ１８を実行する。

上記の手順の結果、状態チェックテーブル１２３には、各状態遷移に対して入力ベクタを生成済か否かのフラグが設定されることになる。ユーザは、以下に示す検証処理の結果と、状態チェックテーブル１２３の内容とを参照することで、不足している入力ベクタを効率的に把握し得る。

図７は、検証処理の例を示すフローチャートである。以下、図７に示す処理をステップ番号に沿って説明する。
（Ｓ２１）制約生成部１４０は、図６のステップＳ１５における論理シミュレーションにより得られた出力信号を解析し、コマンドのシーケンスを生成する。具体的には、ビットパターン（実装ＩＰデータ１２１における変数値の組に相当）とコマンドとの対応を示すテーブルを記憶部１２０に予め格納しておく。すると、制約生成部１４０は、論理シミュレーションの結果と記憶部１２０に記憶されたテーブルとに基づいて、出力信号で示されるビットパターンから実装ＩＰにより出力されたコマンド（または、実装ＩＰに入力されたコマンド）を特定し得る。コマンドは、実装ＩＰデータ１２１における変数値の組に対応付けられるので、コマンドの変化は状態遷移に対応付けることができる。

（Ｓ２２）制約生成部１４０は、生成したシーケンスから定型のパターンを抽出する。例えば、制約生成部１４０は、ある特定のコマンド（第１のコマンドとする）に対して、特定の別のコマンド（第２のコマンドとする）が頻繁に発生する（例えば、所定の頻度を上回る）ことを検出する。すると、制約生成部１４０は、第１のコマンドの後に第２のコマンドが発生するという定型のパターンを抽出する。

（Ｓ２３）制約生成部１４０は、抽出した定型のパターンにより制約データ１１２を生成する。また、検証部１５０ではＳＰＩＮによるモデル検証を行うため、制約生成部１４０は、ＳＰＩＮに入力するための制約データ１１２を生成する。制約データ１１２は、ＳＰＩＮにおけるＮｅｖｅｒＣｌａｉｍである。例えば、制約生成部１４０は、抽出した定型のパターンで特定される状態遷移以外の状態遷移が発生した場合に、ＮｅｖｅｒＣｌａｉｍが受理（accept）されるよう、制約データ１１２を生成する。

（Ｓ２４）検証部１５０は、仕様データ１１１および制約データ１１２を用いた形式的検証を実行する。検証部１５０は、形式的検証を行うツールとして、ＳＰＩＮを利用できる。検証部１５０は、ＳＰＩＮを用いた検証により、ＩＰの仕様と設計（実装ＩＰ）との間の状態遷移の不整合を検出する。具体的には、検証部１５０は、Ｐｒｏｍｅｌａ記述の仕様データ１１１に、制約データ１１２のＮｅｖｅｒＣｌａｉｍを追加したデータを生成し、ＳＰＩＮに入力する。検証部１５０は、仕様モデルにおける状態遷移の検証時、ＮｅｖｅｒＣｌａｉｍで規定された所定の条件が成立すると、成立に至るまでの状態遷移の情報を反例として生成する。

（Ｓ２５）検証部１５０は、ステップＳ２４の検証結果を出力する。例えば、検証部１５０は、仕様上は発生し得る状態遷移のうち、実装ＩＰに対する論理シミュレーションでは発生しなかった状態遷移の情報をディスプレイ１１に表示させる。

このようにして、検証装置１００は、仕様モデルに対して、論理シミュレーションでは成立しない状態遷移の情報を出力する。制約データ１１２は、現状生成済である入力ベクタを用いた論理シミュレーションの結果から作成された情報である。このため、出力された状態遷移は、現状の入力ベクタでは発生しない状態遷移と考えることができる。出力された状態遷移は、論理シミュレーションでは未カバーである仕様上の動作シーケンスであるということもできる。

したがって、検証装置１００により出力された状態遷移を、不足している入力ベクタを補完する際の制約条件として利用できる。更に、状態チェックテーブル１２３から入力ベクタが未生成である状態遷移を特定し、不足している入力ベクタの補完に利用することもできる。このように、形式的検証の結果と、状態チェックテーブル１２３との両方を活用することで、論理シミュレーションにおける入力ベクタの効率的な作成を支援できる。

図８は、制約データの生成例を示す図である。図８では、ＵＳＢ（Universal Serial Bus）３．０で用いられるコマンドを例示している。例えば、制約生成部１４０は、実装ＩＰの論理シミュレーションにより得られた出力信号の波形を解析することで、出力信号のビットパターンを取得する。ここで、当該ビットパターンは、状態チェックテーブル１２３における変数値の組に対応する。例えば、ビットパターンとコマンドとの対応関係を示すテーブルを、記憶部１２０に予め格納しておき、制約生成部１４０によるコマンドの特定に利用する。例えば、出力信号が４つ（対応する変数も４つ）であれば、そのビットパターンの１つ（例えば“０１１０”など）を１つのコマンドに対応付けることができる。

シーケンス２０１は、このようにして得られたコマンドの時系列を例示している。シーケンス２０１では下側のコマンドほど後の時間に発生したコマンドを示す。ここで、ＬＧＯＯＤ＿Ｎ（Ｎはシーケンス番号であり、０〜４の整数）は、相手側の装置にフレームの受信成功を通知するためのメッセージである。また、ＬＣＲＤ＿Ｘ（Ｘはバッファ番号であり、Ａ，Ｂ，Ｃ，Ｄの何れか）は、相手側の装置にバッファの準備を通知するためのメッセージである。なお、実装ＩＰに対して何らかのコマンドが入力される場合も、論理シミュレーションにより得られた出力信号のビットパターンから入力されたコマンドを特定し得る。

制約生成部１４０は、統計的手法によりシーケンス２０１から比較的高頻度で発生する定型のパターン（時系列に発生するコマンドの発生ルール）を抽出し、パターンセット２０２を生成する。例えば、パターンセット２０２は、次のような定型のパターンを含む。

（１）ＬＧＯＯＤ＿ＮにＬＣＲＤ＿Ｘが対応する。（２）ＬＧＯＯＤの直後にＬＣＲＤが返らなくてもよい。（３）ＬＧＯＯＤのシーケンス番号Ｘは０〜４で、順番は入れ替わらない。（４）ＬＣＲＤのバッファ番号ＮはＡ，Ｂ，Ｃ，Ｄで、順番は入れ替わらない。

例えば、制約生成部１４０は、ＬＧＯＯＤ＿Ｎの後にＬＣＲＤ＿Ｘが発生していること、ＬＧＯＯＤ＿Ｎ後のＬＣＲＤ＿Ｘの発生が比較的高頻度であること、をシーケンス２０１から抽出することで、（１）のパターンを抽出できる。制約生成部１４０は、パターンセット２０２をＬＴＬ式で記述することで、制約データ１１２を生成する。制約データ１１２は、（１）のパターンのＬＴＬ式での記述例を示している（他のパターンの記述例は図示を省略している）。

ここで、コマンドは、実装ＩＰデータ１２１における変数値の組に対応付けられるので、コマンドの変化を状態遷移に対応付けることができる。したがって、制約データ１１２は、論理シミュレーションによる出力信号のパターンから得られた実装ＩＰの状態遷移を示す情報であるといえる。検証部１５０は、制約データ１１２を利用して、ＳＰＩＮによる検証を行う。

図９は、ＳＰＩＮを用いた検証の例を示す図である。検証部１５０は、仕様データ１１１および制約データ１１２を用いてＳＰＩＮによる検証を行う。ここでは、仕様データ１１１のファイル名を“ｔｅｓｔ．ｐｍｌ”としている。図９では、仕様データ１１１の記述の一部も例示されている。また、制約データ１１２のファイル名を“ｎｅｖｅｒ．ｐｍｌ”としている。

検証部１５０は、仕様データ１１１と制約データ１１２とを合わせたデータ（例えば、ファイル名を仕様データ１１１のファイル名とする）を生成し、ＳＰＩＮへの入力とする。ＳＰＩＮでは、仕様モデルにおける状態遷移の検証時、ＮｅｖｅｒＣｌａｉｍで規定された所定の条件が成立すると（図９では否定の受理と称している）、ＳＰＩＮにより再現可能であるエラーシーケンスの情報を含む反例データ１１３ａを生成する。ここでは、反例データ１１３ａのファイル名を“ｔｅｓｔ．ｐｍｌ．ｔｒａｉｌ”としている。

検証部１５０は、反例データ１１３ａを用いてＳＰＩＮを再度実行することで、仕様モデルで実現される状態遷移のうち、ＮｅｖｅｒＣｌａｉｍで規定された条件に合致しない状態遷移の情報を含むＦａｉｌパターンデータ１１３を生成し、ユーザに提示する。

図１０は、制約データ（ＮｅｖｅｒＣｌａｉｍ）の例を示す図である。図１０ではＵＳＢ３．０でのデータの送受信を想定している。ここで、実装ＩＰを含むホストコントローラを“Ｔｘ”、ホストコントローラと接続されたＵＳＢメモリなどのデバイスを“Ｒｘ”と表記している（以下、同様）。

例えば、論理シミュレーションの結果から、コマンドのパターンＰ１，Ｐ２，Ｐ３が得られているとする。パターンＰ１は、デバイス側へのＡＣＫ（ACKnowledgement）送信に対してデバイス側からＤＰ（Data Packet）が応答されるパターンである。パターンＰ２は、デバイス側へのＡＣＫ送信に対して、デバイス側から（未準備を通知する）ＮＲＤＹ（Not ReaDY）が応答されるパターンである。パターンＰ３は、デバイス側へのＡＣＫ送信に対して、デバイス側から（受信不可を通知する）ＳＴＡＬＬが応答されるパターンである。

例えば、制約生成部１４０は、パターンＰ１を表す記述として、“：：ｐ＿ｔｐ＝＝ＡＣＫ＿ＴＰ ＆＆ ｃ＿ｔｐ＝＝ＤＰ −＞ ｇｏｔｏ ｓｔ；”を生成し、制約データ１１２に追加する。パターンＰ２を表す記述として、“：：ｐ＿ｔｐ＝＝ＡＣＫ＿ＴＰ ＆＆ ｃ＿ｔｐ＝＝ＮＲＤＹ＿ＴＰ −＞ ｇｏｔｏ ｓｔ；”を生成し、制約データ１１２に追加する。パターンＰ３を表す記述として、“：：ｐ＿ｔｐ＝＝ＡＣＫ＿ＴＰ ＆＆ ｃ＿ｔｐ＝＝ＳＴＡＬＬ＿ＴＰ −＞ ｇｏｔｏ ｓｔ；”を生成し、制約データ１１２に追加する。更に、制約生成部１４０は、パターンＰ１，Ｐ２，Ｐ３以外のパターンに関する記述として、“：：ｅｌｓｅ −＞ ａｃｃｅｐｔ；”を生成し、制約データ１１２に追加する。

すなわち、パターンＰ１，Ｐ２，Ｐ３に相当する状態が発生した場合は、“ｓｔ”でラベルされた非受理状態へ遷移することになる。パターンＰ１，Ｐ２，Ｐ３以外のパターンに相当する状態が発生した場合は、“ａｃｃｅｐｔ”でラベルされた受理状態へ遷移することになる。受理状態への遷移は、反例データ１１３ａによりエラーとして通知される。

図１１は、反例パターンの例（その１）を示す図である。例えば、ＳＰＩＮによる検証の結果、パターンＰ１，Ｐ２，Ｐ３とは異なる反例パターン（反例の状態遷移）として、デバイス側へのＡＣＫ送信に対して、デバイス側からＤＰが連続して応答されるパターンが検出される。検出されたパターンは、仕様モデルにはあるが、実装ＩＰの論理シミュレーションから導かれたＮｅｖｅｒＣｌａｉｍにはないパターン（反例の状態遷移）である。なお、ＤＰは、ＤＰＨ（Data Packet Header）とＤＰＰ（Data Packet Payload）とを含むため、「ＤＰを連続して応答する」ことを「ＤＰＰを連続して応答する」ことと考えてもよい。

検証部１５０は、仕様モデルにはあるがＮｅｖｅｒＣｌａｉｍにはないパターンの情報を反例データ１１３ａとして出力する。例えば、検証部１５０は、反例出力画面３００をディスプレイ１１に表示させることで、反例データ１１３ａの出力をユーザに通知する。反例出力画面３００では、反例データ１１３ａのファイル名“ｔｅｓｔ．ｐｍｌ．ｔｒａｉｌ”が表示される。更に、検証部１５０は、反例データ１１３ａをＳＰＩＮに入力することで、反例の状態遷移を再現した内容を含むＦａｉｌパターンデータ１１３を生成し、ディスプレイ１１に表示させる。

図１２は、反例パターンの例（その２）を示す図である。図１２では、パターンＰ１，Ｐ２，Ｐ３で示される状態遷移および図１１で示した反例の状態遷移を例示している。ＡＣＫの送信は、初期状態からデータの転送可能状態への状態遷移に相当する。例えば、ＡＣＫ送信時の実装ＩＰからの出力信号のビットパターン（変数値の組）を転送可能状態に対応付けることができる。ＤＰの受信は、転送可能状態からデータの転送状態への状態遷移に相当する。例えば、ＤＰ受信時の実装ＩＰからの出力信号のビットパターンを転送状態に対応付けることができる。ＮＲＤＹまたはＳＴＡＬＬの受信は、データの転送可能状態から初期状態への状態遷移に相当する。例えば、ＮＲＤＹ受信時またはＳＴＡＬＬ受信時の実装ＩＰからの出力信号のビットパターンを初期状態に対応付けることができる。

図１１で示した反例の状態遷移によれば、転送状態から転送状態への遷移（自己遷移）が論理シミュレーションではカバーされていないことになる。これは、現状の入力ベクタでは、仕様モデルで実現され得る状態を全て検証するには不十分であることを意味する。したがって、反例パターンで示される状態遷移を発生させることを入力ベクタの補完時の制約（または、要件）として利用できる。すなわち、デバイス側へのＡＣＫ送信に対して、ＤＰが連続して応答されるという動作を発生させる入力ベクタを作成することで、論理シミュレーションでも当該動作をカバーできることになる。

図１３は、論理シミュレーションで未カバーである状態遷移の例を示す図である。前述のように、状態チェックテーブル１２３および初期の入力ベクタの作成時には、少なくとも２状態間の状態遷移が特定されていればよい。複数の状態遷移を経なければ発生しない状態遷移は、検証部１５０での形式的検証により検出可能だからである。図１３の例において、仕様モデルでは、“状態Ｓ２−＞状態Ｓ０”の遷移が“状態Ｓ０−＞状態Ｓ１−＞状態Ｓ２”という遷移を経なければ発生しないことも考えられる。例えば、ＳＰＩＮを用いることで、このように複数の状態遷移を経て初めて現れる状態遷移も抽出可能となる。Ｆａｉｌパターンデータ１１３には、論理シミュレーションでカバーされていない状態遷移、および、その状態遷移に至るまでの他の状態遷移の情報が含まれる。

また、状態チェックテーブル１２３の作成段階では、２状態間の状態遷移が特定されていればよいので、３状態以上の間の状態遷移の発生を想定して状態チェックテーブル１２３を作成するよりもユーザの作業を簡略化できる。また、図６で例示した入力ベクタの生成も、２状態間の状態遷移がカバーされていればよいので、３状態以上の間の状態遷移の発生を想定して入力ベクタを生成するよりも処理を簡略化できる。前述のように、当初の入力ベクタでは未カバーである仕様モデル上の状態遷移は、検証部１５０による検証結果から把握できるので、未カバーの状態遷移が発生するよう事後的に入力ベクタの内容を補完できるためである。

図１４は、検証範囲の例を示す図である。図１４（Ａ）では、比較例として、通常の形式的検証による検証範囲を例示している。具体的には、仕様と（ＩＰの実装を含む）設計との包含関係をチェックし、仕様モデルでは発生し得ないが、設計モデルでは発生する状態遷移がバグとして検出される。

一方、図１４（Ｂ）では、第２の実施の形態の検証方法における検証範囲の例を示している。具体的には、論理シミュレーションでは発生しないが仕様モデルでは発生し得る状態遷移が、論理シミュレーションでカバーされない状態遷移として検出される。上記のように、未カバーの状態遷移が発生するように入力ベクタの内容を補完していけば、仕様上の機能に対する検証の網羅率（カバレッジ）を向上していくことができる。

特に、ＩＰの仕様モデルで実現され得る状態遷移を論理シミュレーションでもカバーしておくことは重要である。品質向上の観点からは、ＩＰで仕様上実現される全ての動作に対して、ＩＰを電子装置に組み込んだ場合に不具合がないことを検証しておくことが好ましいからである。

以上のように、検証装置１００は、論理シミュレーションと形式的検証とを組み合わせて利用することで、仕様上の機能に対する論理シミュレーションでの検証の網羅性を確認する。入力ベクタの作成の目標を「仕様上の動作をカバーできる」点にすることで、実装に対して起こり得るＩＰの全ての内部状態を実現するよう入力ベクタを作成するよりも、入力ベクタの作成作業の効率化（例えば、作成作業の短縮化）を図れる。

また、仕様上の動作をカバーするように検証を行えるので、基準を定めずに作成した入力ベクタを用いて論理シミュレーションによる検証を行うよりも、より現実的で有意義なテスト内容に絞り込める。よって、実装ＩＰの動作検証の効率化（例えば、動作検証の短縮化）を図れる。

更に、状態チェックテーブル１２３の内容を参照することで、何れの変数値の組（すなわち、コマンド）に対して入力ベクタを作成済であり、何れの変数値の組に対して入力ベクタを未作成であるかを把握できる。このため、状態チェックテーブル１２３を入力ベクタの内容の補完に用いることができる。例えば、状態チェックテーブル１２３で生成チェックフラグが“ｆａｌｓｅ”である状態遷移をカバーする入力ベクタの内容を優先的に補完することが考えられる。

また、論理シミュレーションにおいて、実装ＩＰが仕様通りに動作するかを検証するためのアサーションを用意する手間を省くこともできる。実装ＩＰと仕様モデルとの不整合は、検証部１５０による形式的検証により検出されるからである。このため、論理シミュレーションによる検証におけるユーザの作業の省力化を図れるという利点もある。

なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。

例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１ 検証装置
１ａ 記憶部
１ｂ 演算部
２ 回路

Claims (6)

1. コンピュータが、
   入力ベクタを用いた検証対象の回路の論理シミュレーションにより取得された前記回路の出力信号を参照して当該出力信号の変化のパターンを検出し、検出結果に応じて前記入力ベクタに対して発生した前記回路の内部状態の遷移を示す情報を生成し、
   生成した前記情報に基づいて、前記回路の仕様モデルを用いた形式的検証により特定される前記回路の内部状態の遷移のうち、前記入力ベクタを用いた前記論理シミュレーションでは発生しない遷移の情報を出力し、
   前記パターンの検出では、前記入力ベクタをランダムに生成し、生成した前記入力ベクタを用いて前記回路の前記論理シミュレーションを実行することで、前記回路の出力に対応する変数値の組の変化を検出し、変数値の組の変化と前記回路の内部状態の遷移との対応関係を示す情報を参照して、検出された変数値の組の変化を検索し、当該変化に対応する内部状態の遷移に対して前記入力ベクタを生成済みであることを記録する、
   検証方法。
2. 前記生成では、前記入力ベクタに対して発生した前記回路の内部状態の遷移の情報を前記仕様モデルに対する制約として生成し、
   前記出力では、前記仕様モデルと前記制約とを用いた形式的検証を行うことで、前記制約を満たさない前記仕様モデルにおける内部状態の遷移を検出し、検出した遷移の情報を出力する、請求項１記載の検証方法。
3. 前記対応関係に含まれる前記回路の内部状態の遷移のうち、２状態間の遷移に対応する変数値の組の変化を検出する、請求項１または２記載の検証方法。
4. 前記入力ベクタをランダムに繰り返し生成し、前記対応関係に含まれる全ての内部状態の遷移に対して前記入力ベクタを生成できていなくても、前記入力ベクタの生成を終えることを許容する、請求項１乃至３の何れか１項に記載の検証方法。
5. 検証対象の回路に対する入力ベクタを記憶する記憶部と、
   前記入力ベクタを用いた前記回路の論理シミュレーションにより取得された前記回路の出力信号を参照して当該出力信号の変化のパターンを検出し、検出結果に応じて前記入力ベクタに対して発生した前記回路の内部状態の遷移を示す情報を生成し、
   生成した前記情報に基づいて、前記回路の仕様モデルを用いた形式的検証により特定される前記回路の内部状態の遷移のうち、前記入力ベクタを用いた前記論理シミュレーションでは発生しない遷移の情報を出力する、演算部と、を有し、
   前記演算部は、前記パターンの検出では、前記入力ベクタをランダムに生成し、生成した前記入力ベクタを用いて前記回路の前記論理シミュレーションを実行することで、前記回路の出力に対応する変数値の組の変化を検出し、変数値の組の変化と前記回路の内部状態の遷移との対応関係を示す情報を参照して、検出された変数値の組の変化を検索し、当該変化に対応する内部状態の遷移に対して前記入力ベクタを生成済みであることを記録する、
   検証装置。
6. コンピュータに、
   入力ベクタを用いた検証対象の回路の論理シミュレーションにより取得された前記回路の出力信号を参照して当該出力信号の変化のパターンを検出し、検出結果に応じて前記入力ベクタに対して発生した前記回路の内部状態の遷移を示す情報を生成し、
   生成した前記情報に基づいて、前記回路の仕様モデルを用いた形式的検証により特定される前記回路の内部状態の遷移のうち、前記入力ベクタを用いた前記論理シミュレーションでは発生しない遷移の情報を出力し、
   前記パターンの検出では、前記入力ベクタをランダムに生成し、生成した前記入力ベクタを用いて前記回路の前記論理シミュレーションを実行することで、前記回路の出力に対応する変数値の組の変化を検出し、変数値の組の変化と前記回路の内部状態の遷移との対応関係を示す情報を参照して、検出された変数値の組の変化を検索し、当該変化に対応する内部状態の遷移に対して前記入力ベクタを生成済みであることを記録する、
   処理を実行させる検証プログラム。

Images