JP2011165166A - 設計検証装置および設計検証プログラム - Google Patents

Abstract

【課題】設計仕様の検証項目毎の制約条件を網羅する検証用情報を生成すること。
【解決手段】設計検証装置１は、設計対象の第１の設計仕様２を検証する検証用情報＃１、＃２が有する制約条件に、設計対象の第２の設計仕様４のＡモード、Ｂモード、Ｃモードの処理手順２０ｄ、２０ｅ、２０ｆが備えるシーケンスに設けられた、第１の設計仕様２が備えるシーケンスに対するリンクに基づいて、第２の設計仕様４の制約条件を付与する制約条件付与部１ｃと、制約条件付与部１ｃによって制約条件が付与された検証用情報＃１、＃２を、対応するモードとともに出力する出力部１ｄと、を有している。
【選択図】図１

Description

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

ソフトウェアやハードウェアの開発対象を設計開発するに際し、開発対象に対する動作検証を行い、開発対象の動作を確認しつつ、設計を進めることが行われている。
開発対象には、一般的に複数の設計仕様を設けることができる。例えば、開発対象が回路である場合、その回路の機能に関する仕様を設けることができる。また、ＣＰＦ（Common Power Format）やＵＰＦ（Unified Power Format）等の回路の電力制御のための制御信号を管理する仕様（電力管理仕様）を設けることができる。

開発対象に設けた一つの仕様を変更する場合、その仕様の変更に伴い、他の仕様を変更する必要が生じる場合がある。
例えば、開発対象が回路である場合、設計の各フェーズで実装回路の設計変更に伴い、消費電力の測定、実装を変更することの繰り返し（iteration）の作業が行われている。

電力管理仕様に基づいた設計を行う場合、開発対象全体に対する制御の概要をアーキテクチャレベルで設定した上で実装を行っている。
例えば、電力管理仕様にクロックゲーティングが設定されている場合、開発対象の回路のＲＴＬ（Register Transfer Level）を生成した後に、ＲＴＬの構造解析を行う。そして、ＣＡＤソフトウェアが、クロックゲーティングとして合成しやすいＲＴＬに変更したり、ユーザが、手作業によってクロックゲーティングとして合成しやすいＲＴＬに変更したりしている。

米国特許第７２７５２３１号明細書 特開２００４−１８５５９２号公報

設計変更に伴い消費電力を測定する際には、回路の機能を検証するテストベクタ（test vector）を作成し、そのテストベクタを実行した結果、得られる消費電力を取得し、目標とする消費電力とのずれを計算し、ずれが生じていれば実装を変更するような方法を用いている。

しかしながら、この方法は、機能を検証するベクタを用いているため、電力管理仕様を網羅的に検証すること、すなわち、電力制御のための制御信号の制御が正しく行われているか否かを網羅的に検証することが難しいという問題がある。

なお、電力管理仕様だけでなく、他の仕様に基づいて設計を検証する場合についても同様に、その仕様の制御が正しく行われているか否かを検証することが難しいという問題がある。

本発明はこのような点に鑑みてなされたものであり、設計仕様の検証項目毎の制約条件を網羅する検証用情報を生成することができる設計検証装置および設計検証プログラムを提供することを目的とする。

上記目的を達成するために、開示の設計検証装置が提供される。この設計検証装置は、設計対象の第１の設計仕様を検証する検証用情報が有する制約条件に、設計対象の第２の設計仕様の検証項目毎の処理手順が備える処理単位に設けられた、第１の設計仕様が備える処理単位に対するリンクに基づいて、第２の設計仕様の制約条件を付与する制約条件付与部と、制約条件付与部によって制約条件が付与された検証用情報を識別する情報を、対応する検証項目とともに出力する出力部と、を有している。

開示の設計検証装置によれば、設計仕様の検証項目毎の制約条件を網羅する検証用情報を生成することができる。

第１の実施の形態の設計検証装置を説明する図である。 第１の実施の形態の設計検証装置を説明する図である。 制約条件を付与する例を示す図である。 第２の実施の形態のシステムを示す図である。 第２の実施の形態のＬＳＩの設計仕様の構成を示す図である。 ＬＳＩの設計仕様のデータ構造の一例を示す図である。 メッセージ・シーケンス・チャート間の関係と階層構造を説明する図である。 メッセージ・シーケンス・チャートの構成を説明する図である。 メッセージ・シーケンス・チャートの他の例を示す図である。 設計検証装置のハードウェア構成例を示す図である。 設計検証装置の機能を示すブロック図である。 電力管理仕様のデータ構造の一例を示す図である。 モードテーブルの一例を示す図である。 事前条件テーブルの一例を示す図である。 設計検証装置の全体処理を示すフローチャートである。 検証用シナリオ生成処理を示すフローチャートである。 検証用シナリオ生成処理を示すフローチャートである。 ラベル付与処理を示すフローチャートである。 制約条件付与処理を示すフローチャートである。 モードテーブル作成処理を示すフローチャートである。 事前条件テーブル作成処理を示すフローチャートである。 ＬＳＩの設計仕様のデータ構造の具体例を示す図である。 メッセージ・シーケンス・チャートの具体例を示す図である。 ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ラベルを付与したＬＳＩの設計仕様のデータ構造例を示す図である。 ＬＳＩの設計仕様にラベルを付与する他の具体例を示す図である。 有限ステートマシンに変換する処理を説明するメッセージ・シーケンス・チャートを示す図である。 図２９に示すメッセージ・シーケンス・チャートに関連する状態マトリックスを示す図である。 状態マトリックスに関する状態図を示す図である。 有限ステートマシンにラベルを付与する具体例を示す図である。 有限ステートマシンにラベルの付与が終了したときの状態を示す図である。 状態マトリックスに関する状態図を示す図である。 有限ステートマシンのデータ構造例を示す図である。 検証用シナリオ格納部に格納されている検証用シナリオを示す図である。 具体例の電力管理仕様を示す図である。 モードテーブルおよび事前条件テーブルの作成例を示す図である。 電力管理検証用シナリオの有向グラフを示す図である。 電力管理検証用シナリオのデータ構造を示す図である。 電力管理検証用シナリオのデータ構造を示す図である。 シナリオリストを示す図である。 電力管理仕様にパワーゲーティングの条件を追加した場合を説明する図である。 デコーダ回路の機能を示すブロック図である。 メッセージ・シーケンス・チャートの電圧条件として、デコーダ回路全体の電圧の条件を設定する例を示す図である。 デコーダ回路が有する各機能の配置位置の一例を示す図である。 電力管理仕様に電圧の条件を追加した場合を説明する図である。

以下、実施の形態を、図面を参照して詳細に説明する。
まず、第１の実施の形態の設計検証装置について説明し、その後、第２の実施の形態以降、設計検証装置をより具体的に説明する。

＜第１の実施の形態＞
図１および図２は、第１の実施の形態の設計検証装置を説明する図である。
実施の形態の設計検証装置１は、生成部１ａと、格納部１ｂと、制約条件付与部１ｃと、出力部１ｄとを有している。

生成部１ａは、設計対象の設計仕様である第１の仕様を検証する検証用情報を生成する。
ここで、設計対象は、設計検証装置１によるテストおよび検証対象となるハードウェアコンポーネントまたはシステムやソフトウェアモジュールである。

この設計対象の設計仕様は、実装が守るべき約束事を記したものであり、少なくとも１つの機能により実現される。
図１では、機能２ａを有する第１の設計仕様２を示している。機能２ａは、機能２ａを実現する３つの処理手順（処理のシナリオ）２０ａと処理手順２０ｂと処理手順２０ｃとを有している。

処理手順２０ａは、機能２ａの基本動作についての処理手順である。処理手順２０ｂは、例外動作についての処理手順である。処理手順２０ｃは、代替動作についての処理手順である。

各処理手順２０ａ、２０ｂ、２０ｃそれぞれには、処理手順の実行を制約する制約条件（ガード条件）として、事前条件、事後条件、不変条件（の１つまたは複数）が定義されている場合がある。

事前条件とは、機能を実現する一連の操作の実行前に満たすべき（真となる）条件である。
事後条件とは、一連の操作の実行後に満たすべき条件である。

不変条件とは、事後条件が発生するまでの間（一連の操作の実行中）に要求される条件である。
図１では、一例として、基本動作、例外動作、代替動作ともに事前条件が定義されている。

ところで、処理手順２０ａ〜２０ｃは枝構造を有しており、ノードとなる部分に動作（例えば、処理手順２０ａであれば基本動作）の実行すべき処理単位が設定されている。この処理単位としては、例えば、機能２ａの実現に関わっている全てのオブジェクト間のやり取りを明確にした仕様であるメッセージ・シーケンス・チャート（Message Sequence Chart）等が挙げられる。なお、メッセージ・シーケンス・チャートについては、特許文献１を参照のこと。

処理手順２０ａ〜処理手順２０ｃの関係は、図２に示す構造体３によって示される。
この構造体３を用いることで、第１の設計仕様２をコンパクトに表示することができる。

構造体３は、初期状態ブロックと、第１のシーケンス、第２のシーケンス、第３のシーケンス、第４のシーケンス、第５のシーケンスと、これら各シーケンス間の関係を示すブランチ（branch）およびマージ（merge）を有している。

各シーケンスのブロックを接続する矢印は、機能が実行される順序を記述する。
処理手順２０ａは、初期状態ブロック３ａから第１のシーケンス、第２のシーケンス、第３のシーケンスの順番に処理が行われることを示している。

処理手順２０ｂは、初期状態ブロック３ａから第１のシーケンス、第２のシーケンス、第４のシーケンスの順番に処理が行われることを示している。
処理手順２０ｃは、初期状態ブロック３ａから第１のシーケンス、第５のシーケンスの順番に処理が行われることを示している。

従って、構造体３は、処理手順２０ａ、２０ｂと処理手順２０ｃは、第１のシーケンスまで同じ動作を有するが、それ以降の動作は異なっていることを示す。また、処理手順２０ａと処理手順２０ｂは、第２のシーケンスまで同じ動作を有するが、それ以降の動作は異なっていることを示す。

構造体３のエッジは有向であり、制約条件が付与されている場合がある。
制約条件は、各シーケンスの終了後、制約条件が成立すればエッジ先のシーケンスに遷移することを示している。

図２では、初期状態ブロック３ａから第１のシーケンスに遷移する。そして、第１のシーケンスの処理後、ｉ＞０の制約条件が成立すれば、第２のシーケンスに遷移する。そして、第２のシーケンスの処理後、ｊ＞０の制約条件が成立すれば、第３のシーケンスに遷移する。一方、第２のシーケンスの処理後、ｊ≦０の制約条件が成立すれば、第４のシーケンスに遷移する。

また、第１のシーケンスの処理後、ｉ≦０の制約条件が成立すれば、第５のシーケンスに遷移する。
ところで、検証用情報は、処理手順を検証（例えば処理手順の成否を検証）するものである。この検証用情報には、各処理手順が有する処理単位それぞれに、設計仕様の検証対象となる部位（検証対象部位）を識別する識別情報（ラベル）が関連付けられている場合がある。

図１に示す機能２ａの場合、生成部１ａは、処理手順２０ａ、すなわち、基本動作に対し、処理手順２０ａが備える第１のシーケンス、第２のシーケンス、第３のシーケンスそれぞれに設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する。

検証対象部位は、例えば、機能、処理手順、処理単位等が挙げられる。図２では、第１のシーケンス、第２のシーケンス、第３のシーケンスそれぞれに、機能２ａを識別する識別情報「機能＃１」、処理手順２０ａを識別する識別情報「基本動作」を関連付ける。

また、生成部１ａは、処理手順２０ｂ、すなわち、例外動作に対し、処理手順２０ｂが備える第１のシーケンス、第２のシーケンス、第４のシーケンスそれぞれに設計仕様の検証対象部位を関連付けた検証用情報を生成する。

図２では、第１のシーケンス、第２のシーケンス、第４のシーケンスそれぞれに、機能２ａを識別する識別情報「機能＃１」、処理手順２０ｂを識別する識別情報「例外動作」を関連付ける。

さらに、生成部１ａは、処理手順２０ｃ、すなわち、代替動作に対し、処理手順２０ｃが備える第１のシーケンス、第５のシーケンスそれぞれに設計仕様の検証対象部位を関連付けた検証用情報を生成する。

図２では、第１のシーケンス、第５のシーケンスそれぞれに、機能２ａを識別する識別情報「機能＃１」、処理手順２０ｃを識別する識別情報「代替動作」を関連付ける。
この結果、第１のシーケンスには、識別情報「機能＃１：基本動作」、「機能＃１：例外動作」、「機能＃１：代替動作」が関連付けられる。第２のシーケンスには、識別情報「機能＃１：基本動作」、「機能＃１：例外動作」が関連付けられる。第３のシーケンスには、識別情報「機能＃１：基本動作」が関連付けられる。第４のシーケンスには、識別情報「機能＃１：例外動作」が関連付けられる。第５のシーケンスには、識別情報「機能＃１：代替動作」が関連付けられる。

そして、生成部１ａは、同じ識別情報を備えるシーケンスを抽出し、抽出したシーケンスの集合をそれぞれ検証用情報とする。
図２では、識別情報「基本動作」を備える第１のシーケンス、第２のシーケンス、第３のシーケンスの集合を１つの検証用情報３ｂとする。換言すれば、検証用情報３ｂは、機能２ａの基本動作を検証するための情報となる。

また、識別情報「例外動作」を備える第１のシーケンス、第２のシーケンス、第４のシーケンスの集合を１つの検証用情報３ｃとする。換言すれば、検証用情報３ｃは、機能２ａの例外動作を検証するための情報となる。

さらに、識別情報「代替動作」を備える第１のシーケンス、第５のシーケンスの集合を１つの検証用情報３ｄとする。換言すれば、検証用情報３ｄは、機能２ａの代替動作を検証するための情報となる。

再び図１に戻って説明する。
図１では、第２の設計仕様４は、それぞれ異なる検証項目（Ａモード〜Ｃモード）を備えている。

各モードは、それぞれ処理手順（処理のシナリオ）を有している。Ａモードは、処理手順２０ｄを有している。Ｂモードは、処理手順２０ｅを有している。Ｃモードは、処理手順２０ｆを有している。

処理手順２０ｄ〜２０ｆは、それぞれ枝構造を有しており、ノードとなる部分に各モードの実行すべき処理単位が設定されている。
処理手順２０ｄは、処理単位である第６のシーケンス、第７のシーケンス、第８のシーケンスの順番に処理が行われることを示している。

処理手順２０ｅは、処理単位である第６のシーケンス、第７のシーケンス、第９のシーケンスの順番に処理が行われることを示している。
処理手順２０ｆは、処理単位である第６のシーケンス、第１０のシーケンスの順番に処理が行われることを示している。

制約条件付与部１ｃは、各モードの処理手順２０ｄ〜２０ｆに基づいて、設計対象の第２の設計仕様４の制約条件を作成する。そして、作成された制約条件を、検証用情報３ｂ、３ｃ、３ｄに付与する。

なお、検証用情報３ｂ、３ｃ、３ｄのどの制約条件に、作成されたどの制約条件を付与するかは、例えば、処理手順２０ｄ〜２０ｆがそれぞれ有する処理単位に、検証用情報３ｂ、３ｃ、３ｄが有する処理単位に対するリンクが設定される等して予め定められている。

図１では、第６のシーケンスは、第１のシーケンスへのリンクが設定されている。これにより、第６のシーケンスは、第１のシーケンスに関連づけられていることを示している。同様に、第７のシーケンスは、第２のシーケンスへのリンクが設定されている。第８のシーケンスは、第３のシーケンスへのリンクが設定されている。第９のシーケンスは、第４のシーケンスへのリンクが設定されている。第１０のシーケンスは、第５のシーケンスへのリンクが設定されている。

本実施の形態では、制約条件付与部１ｃは、第１の設計仕様２が有する処理単位に対し、共通のリンクが設けられた処理単位を有する処理手順２０ｄ〜２０ｆに遷移する条件を、第２の設計仕様４の制約条件とする。

図３は、制約条件を付与する例を示す図である。なお、図３では、識別情報の図示を省略している。
第１のシーケンスへのリンクが設定されている第６シーケンスを有する処理手順は、処理手順２０ｄ〜２０ｆである。

従って、制約条件付与部１ｃは、これらの処理手順２０ｄ〜２０ｆが第１のシーケンスへのリンクが設定されているシーケンスを有する処理手順であることを示すために、第６のシーケンスを有する処理手順２０ｄのモード名「Ａモード」、処理手順２０ｅのモード名「Ｂモード」、処理手順２０ｆのモード名「Ｃモード」を、それぞれ「ｏｒ」で接続する。これを第１のシーケンスの事前条件とする。そして、この事前条件を第１のシーケンスと関連づける。

第２のシーケンスへのリンクが設定されている第７シーケンスを有する処理手順は、処理手順２０ｄ、２０ｅである。
従って、制約条件付与部１ｃは、これらの処理手順２０ｄ、２０ｅが第２のシーケンスへのリンクが設定されているシーケンスを有する処理手順であることを示すために、第７のシーケンスを有する処理手順２０ｄのモード名「Ａモード」、処理手順２０ｅのモード名「Ｂモード」を、それぞれ「ｏｒ」で接続する。これを第２のシーケンスの事前条件とする。そして、この事前条件を第２のシーケンスと関連づける。

第３のシーケンスへのリンクが設定されている第８シーケンスを有する処理手順は、処理手順２０ｄである。
従って、制約条件付与部１ｃは、処理手順２０ｄが第３のシーケンスへのリンクが設定されているシーケンスを有する処理手順であることを示すために、第８のシーケンスを有する処理手順２０ｄのモード名「Ａモード」を、第３のシーケンスの事前条件とする。そして、この事前条件を第３のシーケンスと関連づける。

第４のシーケンスへのリンクが設定されている第９シーケンスを有する処理手順は、処理手順２０ｅである。
従って、制約条件付与部１ｃは、処理手順２０ｅが第４のシーケンスへのリンクが設定されているシーケンスを有する処理手順であることを示すために、第９のシーケンスを有する処理手順２０ｅのモード名「Ｂモード」を、第４のシーケンスの事前条件とする。そして、この事前条件を第４のシーケンスと関連づける。

第５のシーケンスへのリンクが設定されている第１０シーケンスを有する処理手順は、処理手順２０ｆである。
従って、制約条件付与部１ｃは、処理手順２０ｆが第５のシーケンスへのリンクが設定されているシーケンスを有する処理手順であることを示すために、第１０のシーケンスを有する処理手順２０ｆのモード名「Ｃモード」を、第５のシーケンスの事前条件とする。そして、この事前条件を第５のシーケンスと関連づける。

そして、制約条件付与部１ｃは、生成された事前条件を格納部１ｂに格納されている検証用情報３ｂ〜３ｄが有する制約条件に付与する。
具体的には、「初期状態ブロック３ａからモード名「Ａモード」、「Ｂモード」、「Ｃモード」のいずれかの処理手順が選択されたときに第１のシーケンスに遷移する」という事前条件を付与する。

また、「第１のシーケンスからモード名「Ａモード」、「Ｂモード」のいずれかの処理手順が選択されたときに第２のシーケンスに遷移する」という事前条件を付与する。ここで、第２のシーケンスには、既に事前条件ｉ＞０が設定されている。この場合、既に設定されている事前条件ｉ＞０と付与する事前条件を「＆」で接続する。これにより、第１のシーケンスからモード名「Ａモード」、「Ｂモード」のいずれかの処理手順が選択され、かつ、ｉ＞０であるときに第２のシーケンスに遷移することとなる。

また、「第２のシーケンスからモード名「Ａモード」の処理手順が選択されたときに第３のシーケンスに遷移する」という事前条件を付与する。ここで、第３のシーケンスには、既に事前条件ｊ＞０が設定されている。この場合、既に設定されている事前条件ｊ＞０と付与する事前条件を「＆」で接続する。これにより、第２のシーケンスからモード名「Ａモード」の処理手順が選択され、かつ、ｊ＞０であるときに第３のシーケンスに遷移することとなる。

また、「第２のシーケンスからモード名「Ｂモード」の処理手順が選択されたときに第４のシーケンスに遷移する」という事前条件を付与する。ここで、第４のシーケンスには、既に事前条件ｊ≦０が設定されている。この場合、既に設定されている事前条件ｊ≦０と付与する事前条件を「＆」で接続する。これにより、第２のシーケンスからモード名「Ｂモード」の処理手順が選択され、かつ、ｊ≦０であるときに第４のシーケンスに遷移することとなる。

また、「第１のシーケンスからモード名「Ｃモード」の処理手順が選択されたときに第５のシーケンスに遷移する」という事前条件を付与する。ここで、第５のシーケンスには、既に事前条件ｉ≦０が設定されている。この場合、既に設定されている事前条件ｉ≦０と付与する事前条件を「＆」で接続する。これにより、第１のシーケンスからモード名「Ｃモード」の処理手順が選択され、かつ、ｉ≦０であるときに第５のシーケンスに遷移することとなる。

これにより、モード名「Ａモード」の処理手順２０ｄを実現する検証用情報は、検証用情報３ｂのみに絞られる。モード名「Ｂモード」の処理手順２０ｅを実現する検証用情報は、検証用情報３ｃのみに絞られる。モード名「Ｃモード」の処理手順２０ｆを実現する検証用情報は、検証用情報３ｄのみに絞られる。

再び図１に戻って説明する。
出力部１ｄは、第２の設計仕様４の処理手順それぞれに対応する検証用情報３ｂ〜３ｄの集合を識別する情報を出力する。

従って、モード名「Ａモード」に検証用情報３ｂを示す検証用情報＃１を関連付けたレコードと、モード名「Ｂモード」に検証用情報３ｃを示す検証用情報＃２を関連付けたレコードと、モード名「Ｃモード」に検証用情報３ｄを示す検証用情報＃３を関連付けたレコードとを備える出力結果５を出力する。

このような設計検証装置１によれば、制約条件付与部１ｃが、設計対象の設計仕様である第２の設計仕様４の制約条件を作成し、作成された制約条件を、検証用情報３ｂ、３ｃ、３ｄに付与するようにした。これにより、設計仕様の検証項目毎の制約条件を網羅する検証用情報３ｂ、３ｃ、３ｄを生成することができる。

これにより、ユーザは、各モードに対応する検証用情報３ｂ、３ｃ、３ｄを検証することで、第２の設計仕様４の制御のための制御信号が正しく行われているかの網羅的な検証を行うことができるため、検証漏れや重複検証を抑制することができる。具体的には、処理手順２０ａ〜２０ｃに対し、制約条件を付与したので、その制約条件を満たさない処理手順は、そのモードを検証する検証用情報から除外される。一方、制約条件を満たす処理手順を検証する検証用情報の組み合わせについては全て出力されるので漏れがない。例えば、Ｃモードについて検証を行うときは、第２のシーケンスに設けられた制約条件を満たさないので、第２のシーケンスには遷移しない。これにより、第２のシーケンスに遷移する検証用情報３ｂ、３ｃは、検証の対象外とすることができる。従って、前述した具体例では、モード名「Ｃモード」の処理手順２０ｆを検証するときは、検証用情報＃３のみを実行するだけでよい。

なお、本実施の形態では、設計検証装置１が、検証用情報を生成する生成部１ａを備える構成とした。しかし、これに限らず、設計検証装置１が、他の装置によって生成された、検証用情報を読み込み、制約条件付与部１ｃが、読み込んだ検証用情報に制約条件を付与するようにしてもよい。この場合、設計検証装置１は、生成部１ａおよび格納部１ｂの機能を省略することができる。

また、本実施の形態では、各処理手順が備えるシーケンスそれぞれに設計仕様の検証対象部位を関連付けた検証用情報を生成した。これにより、設計仕様の複数の検証対象部位およびこれら検証対象部位の処理優先度情報の入力に応じて、検証用情報毎に処理優先度を付与するような処理を行うこともできる。

但し、生成部１ａは、処理手順それぞれが有するシーケンスが明らかになる検証用情報を生成すればよく、検証用情報に、各処理手順が備えるシーケンスそれぞれに設計仕様の検証対象部位を関連付ける処理は、省略してもよい。

以下、第１の実施の形態をより具体的に説明する。
＜第２の実施の形態＞
図４は、第２の実施の形態のシステムを示す図である。

システム１００は、設計検証装置１０と、信号インタフェース２００とテスト対象装置３００とを有している。
設計検証装置１０は、テスト対象装置３００が設計仕様に従って動作するか判断するため、設計仕様が備えるシナリオ毎に、これらシナリオを検証するための検証用シナリオを生成する。

そして、設計検証装置１０は、検証用シナリオに優先順位を付与する。
さらに、設計検証装置１０は、優先順位が付与された検証用シナリオを利用して、テスト対象装置３００がこの検証用シナリオに従って動作するか否かを判断するため、信号インタフェース２００を介しテスト対象装置３００と通信する。

この際、付与した優先順位に従って、検証用シナリオをテスト対象装置３００に流す。
信号インタフェース２００は、設計検証装置１０とテスト対象装置３００とを接続するための装置を表す。信号インタフェース２００は、設計検証装置１０により通信される信号を設計検証装置１０による利用に適した信号に変換する。

なお、例えば、設計検証装置１０とテスト対象装置３００が互換的な信号を使用する場合、信号インタフェース２００は省略されてもよい。
テスト対象装置３００は、設計検証装置１０によるテストおよび検証対象となるハードウェアコンポーネントまたはシステムやソフトウェアモジュールを表す。

テスト対象装置３００は、製品開発中に製造される設計プロトタイプであってもよいし、設計検証装置１０によって生成されるステートマシン（State Machine）であってもよい。以下、テスト対象装置３００がＬＳＩ（Large Scale Integration）である場合を例にとって説明する。

＜ＬＳＩの設計仕様＞
図５は、第２の実施の形態のＬＳＩの設計仕様の構成を示す図である。
前述したように、設計仕様とは、実装が守るべき約束事を記したものであり、複数の機能により実現される。

なお、設計仕様は、リスト構造で表現される。このリスト構造は、例えば、ＸＭＬ（eXtensible Markup Language）形式で表現される。
各機能ブロック２１、２２、２３には、それぞれ１つの機能が対応付けられている。対応付けられた各機能は、例えば、ソフトウェアにより呼び出されるハードウェアで実現する機能であり、または、ハードウェアに依存するソフトウェアで実現する機能である。

各機能ブロック２１、２２、２３は、それぞれ、１つまたは複数のシナリオブロックを有している。例えば、機能ブロック２１は、シナリオブロック２１ａとシナリオブロック２１ｂとを有している。

各シナリオブロック２１ａ、２１ｂには、それぞれ、１つのシナリオが対応付けられている。対応付けられた各シナリオは、機能の実体であり、呼び出し時の条件により複数存在する。

より詳しくは、シナリオは、機能を実現するために実行される一連の操作を定義するものである。言い換えると、シナリオは、オブジェクト間で送受信されるメッセージの順序および組み合わせを表すものである。

各シナリオブロック２１ａ、２１ｂは、それぞれ、１つまたは複数のメッセージ・シーケンス・チャートブロック（以下、「ＭＳＣブロック」と言う）を有している。例えば、シナリオブロック２１ａは、ＭＳＣブロック２１１ａと、ＭＳＣブロック２１２ａとを有している。

ＭＳＣブロック２１１ａ、２１２ａには、それぞれ、１つのメッセージ・シーケンス・チャートが対応付けられている。
メッセージ・シーケンス・チャートは、シナリオが備えるサブ機能群である。具体的には、メッセージ・シーケンス・チャートは、機能の実現に関わっている全てのオブジェクト間のやり取りを明確にしたものである。このオブジェクトは、ＬＳＩ２０が備える機能や、このＬＳＩ２０を含むシステムに干渉する外部環境を含む。

＜ＬＳＩの設計仕様のデータ構造＞
次に、ＬＳＩ２０の設計仕様のデータ構造を説明する。
図６は、ＬＳＩの設計仕様のデータ構造の一例を示す図である。

前述したように、ＬＳＩ２０の設計仕様は、複数の機能により実現される。図６では、図５に示した設計仕様をツリー構造で示し、そのうちの１つの機能を示している。
各機能それぞれには、制約条件として、事前条件、事後条件、不変条件（の１つまたは複数）が定義されている場合がある。

これら各条件が存在する場合には、その条件が設定される。また、条件が存在しない場合には、「条件なし」が設定される。例えば、事前条件のみが定義されている場合は、事後条件、不変条件は「条件なし」が設定される。

前述したように、機能ブロック２１に対応付けられている機能は、シナリオブロック２１ａに対応付けられているシナリオＡ１とシナリオブロック２１ｂに対応付けられているシナリオＡ２とを有している。

シナリオＡ１、Ａ２は、それぞれ、「基本動作」、「代替動作」、「例外動作」のいずれか１つの属性を有している。その属性が、種類として記載されている。
また、各シナリオＡ１、Ａ２それぞれには、制約条件として、事前条件、事後条件、不変条件（の１つまたは複数）が定義されている場合がある。これら各条件が存在する場合には、その条件が設定される。また、条件が存在しない場合には、「条件なし」が設定される。

図６では、シナリオＡ１は、基本動作についてのシナリオであり、事前条件と、事後条件と、不変条件とを有している。
シナリオＡ２は、シナリオＡ１に対する代替動作についてのシナリオであり、基本動作と同様に、事前条件と、事後条件と、不変条件とを有している。

ＭＳＣブロック２１１ａ、２１２ａに対応付けられているメッセージ・シーケンス・チャートは、メッセージ・シーケンス・チャートを識別するための名前（ＭＳＣ名）を有している。ＭＳＣブロック２１１ａに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃Ａ」であり、ＭＳＣブロック２１２ａに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃Ｂ」である。

メッセージ・シーケンス・チャートは、制約条件として、事前条件、事後条件、不変条件（の１つまたは複数）が定義されている場合がある。これら各条件が存在する場合には、その条件が設定される。また、条件が存在しない場合には、「条件なし」が設定される。

ＭＳＣ名「ＭＳＣ＃Ａ」のメッセージ・シーケンス・チャートは、事前条件と、不変条件と、事後条件とを有している。
ＭＳＣ名「ＭＳＣ＃Ｂ」のメッセージ・シーケンス・チャートは、事前条件と、不変条件と、事後条件とを有している。

なお、シナリオブロック２１ｂも少なくとも１つのＭＳＣブロックを有しているが、図６ではその図示を省略している。
ところで、ＬＳＩ２０の設計仕様は、複数のメッセージ・シーケンス・チャートを含む単一の有向グラフによって表されてもよいし、単一の平坦化されたメッセージ図によって表されてもよい。

この平坦化されたメッセージ・シーケンス・チャートは、オブジェクト間で通信されるメッセージの順序を示すものである。
さらに、ＬＳＩ２０の設計仕様は、互いに埋め込まれた複数の有向グラフと複数のメッセージ・シーケンス・チャートによって表されてもよい。

図７は、メッセージ・シーケンス・チャート間の関係と階層構造を説明する図である。
本実施の形態では、ＬＳＩ２０の設計仕様は、有向グラフ３０によって、階層的に形成されている。

この有向グラフ３０を用いることで、ＬＳＩ２０の設計仕様をコンパクトに表示することができる。
前述したように、有向グラフ３０は、複数のメッセージ・シーケンス・チャートと、これらメッセージ・シーケンス・チャート間の関係を示すブランチおよびマージを有している。この関係は、メッセージ・シーケンス・チャートを１以上のシーケンスに順序付けするものである。

他方、各メッセージ・シーケンス・チャートは、オブジェクト間の関係を示すものである。メッセージ・シーケンス・チャートは、オブジェクト間で通信されるメッセージを特定し、少なくとも一部のメッセージが通信される順序を示すものである。

有向グラフ３０は、将来的なユーザを認証するためある機能によって実行される複数の機能の関係を記述する。これら機能は、形状によって表されるメッセージ・シーケンス・チャートによって規定される。各メッセージ・シーケンス・チャートは、機能によって表現されている。各ブロックを接続する矢印は、機能が実行される順序を記述する。

また、有向グラフ３０のエッジは有向であり、制約条件が付与されている場合がある。
図７に示すように、有向グラフ３０は、各自がメッセージ・シーケンス・チャート３２、メッセージ・シーケンス・チャート３３およびｈメッセージ・シーケンス・チャート３４によって表される独立したメッセージ・シーケンス・チャートによって規定される３つの機能を有している。

ここで、ｈメッセージ・シーケンス・チャート３４は、複数のメッセージ・シーケンス・チャートの階層構造をまとめて表したものである。
初期状態ブロック３１は、仮想的な状態であり、エントリポイントを有向グラフ３０に提供する。具体的には、どのメッセージ・シーケンス・チャートが最初に「起動」されるかを指定する。

従って、初期状態ブロック３１とメッセージ・シーケンス・チャート３２との間の矢印は、メッセージ・シーケンス・チャート３２に関連するメッセージ・シーケンス・チャートが有向グラフ３０へのエントリ後に直面することを示す。

メッセージ・シーケンス・チャート３２により表されるメッセージ・シーケンス・チャートに規定されるメッセージの通信後、メッセージ・シーケンス・チャート３３またはｈメッセージ・シーケンス・チャート３４のいずれかに実行が継続される。

従って、有向グラフ３０は、２つのシナリオを含む。
１つのシナリオは、初期状態ブロック３１、メッセージ・シーケンス・チャート３２およびメッセージ・シーケンス・チャート３３を介し進行するパスに関する。

他のシナリオは、初期状態ブロック３１、メッセージ・シーケンス・チャート３２およびｈメッセージ・シーケンス・チャート３４を介し進行するパスに関する。
従って、有向グラフ３０は、これら２つのシナリオがメッセージ・シーケンス・チャート３２まで同じ動作を有するが、メッセージ・シーケンス・チャート３２からの動作は異なっていることを示す。

有向グラフ３０のエッジは有向であり、制約条件が付与されている。
制約条件は、メッセージ・シーケンス・チャートに記述されたメッセージのシーケンスの終了後、制約条件が成立すればエッジ先のメッセージ・シーケンス・チャート、または、その階層内のメッセージ・シーケンス・チャートへ遷移する。

図７では、メッセージ・シーケンス・チャート３２の処理後、ｉ＞０の制約条件が成立すれば、メッセージ・シーケンス・チャート３３に移行する。一方、ｉ＜＝０の制約条件が成立すれば、ｈメッセージ・シーケンス・チャート３４に移行する。

この情報は、２つのシナリオの共通部分が設計に関する有向グラフ３０を完全にテストするのに繰り返される必要はないため、検証および検証目的に有用に利用される。
ここで、有向グラフ３０が有する各メッセージ・シーケンス・チャートは、同一のオブジェクト群を利用してもよい。さらに、あるメッセージ・シーケンス・チャートによって規定される各メッセージが、次のメッセージ・シーケンス・チャートがパスに沿って実行可能となる前に実行される必要があると言うことを示すルールが、有向グラフ３０に関連して設けられていてもよい。

次に、メッセージ・シーケンス・チャートの一般的な構成を説明する。
＜メッセージ・シーケンス・チャート＞
図８は、メッセージ・シーケンス・チャートの構成を説明する図である。

前述したように、メッセージ・シーケンス・チャートは、機能の実現に関わっている全てのオブジェクト間のやり取りを明確にしたものである。
メッセージ・シーケンス・チャートは、ＬＳＩが備えるハードウェアブロック、または、システムと干渉する外部環境であるオブジェクトを有している。

図８に示すメッセージ・シーケンス・チャート（ＭＳＣ）４０には、複数のオブジェクトとして、ハードウェア（ＨＷ）４１、４２、４３が設けられている。
これらのオブジェクトが生成された後、データ・イベント・メッセージはオブジェクト間で通信されるものとして示される。

このデータ・イベント・メッセージは、ユーザにより指定されるものである。ユーザは当該メッセージがどのオブジェクト間で通信されるか指定することができる。
例えば、ユーザにより、１つのオブジェクトが選択され、その後に図示しないポインティングツールを用いて第２のオブジェクトが選択される。

メッセージ・シーケンス・チャート４０の生成時には、送信イベントを有する第１オブジェクトと受信イベントを有する第２オブジェクトからなる示された２つのオブジェクトの間においてデータ・イベント・メッセージが生成される。このようにして、データ・イベント・メッセージｍ１〜ｍ４の矢印が、メッセージ・シーケンス・チャート４０に示されるハードウェア４１、４２、４３間で送受信されるデータ・イベント・メッセージｍ１〜ｍ４の４個のメッセージを表すよう生成される。

具体的には、オブジェクトライン４４、４５、４６を相互接続する水平矢印は、データ・イベント・メッセージが、オブジェクト間で送受信されることを示す。
各データ・イベント・メッセージは、送信オブジェクトと受信オブジェクトを関連付けている。オブジェクトライン４４、４５、４６とデータ・イベント・メッセージｍ１〜ｍ４とが交差する位置は、イベントと呼ばれる。

各データ・イベント・メッセージは、送信オブジェクトに関連する送信イベントと、受信オブジェクトに関連する受信イベントを含む。例えば、データ・イベント・メッセージｍ１は、オブジェクトライン４５とオブジェクトライン４４とを接続する。

このため、データ・イベント・メッセージｍ１は、ハードウェア４１および送信オブジェクトと、ハードウェア４２および受信オブジェクトとを関連付ける。
さらに、データ・イベント・メッセージｍ１のオブジェクトライン４４との交点は送信イベントを生成し、データ・イベント・メッセージｍ１とオブジェクトライン４５との交点は受信イベントを生成する。

ここで、メッセージ・シーケンス・チャートによって特定される関係について、以下の２つのルールが設けられている。
第１のルール：任意のデータ・イベント・メッセージｍに対して、送信イベント（ｓ（ｍ））は、対応する受信イベント（ｒ（ｍ））の前に発生する。

従って、ｓ（ｍ）＜ｒ（ｍ）となる。
第２のルール：オブジェクトライン上のイベントは、上から下に順序付けされる。
これら２つのルールは、メッセージ・シーケンス・チャートがオブジェクト間で送受信されるデータ・イベント・メッセージの順序を記述することを示している。

例えば、第１のルールにより、メッセージ・シーケンス・チャート４０は、データ・イベント・メッセージｍ１に関する送信イベントが同じメッセージに関する受信イベントの前に発生することを示している。

また、第２のルールにより、メッセージ・シーケンス・チャート４０は、データ・イベント・メッセージｍ２に関する送信イベントが、データ・イベント・メッセージｍ４に関する受信イベントの前に発生すると言うことを示している。

図８に示すデータ・イベント・メッセージの送信は受信より先に起きる。
ハードウェア４１の時間軸ではデータ・イベント・メッセージｍ１とデータ・イベント・メッセージｍ２とが、この順番に送信される。その後、データ・イベント・メッセージｍ４が受信される。

ハードウェア４２の時間軸ではデータ・イベント・メッセージｍ１が受信された後、データ・イベント・メッセージｍ３が受信される。
ハードウェア４３の時間軸ではデータ・イベント・メッセージｍ２が受信されてから、データ・イベント・メッセージｍ３とデータ・イベント・メッセージｍ４とを、この順番に送信する。

ここで、上記ルールは推移的である。例えば、イベントｅ１がイベントｅ２（ｅ１＜ｅ２）の前に発生し、イベントｅ２がイベントｅ３（ｅ２＜ｅ３）の前に発生する場合、イベントｅ１は、イベントｅ３（ｅ１＜ｅ３）の前に発生する。

しかしながら、これら２つのルールは、全てのデータ・イベント・メッセージの間の順序付けされた関係を規定するものではない。
例えば、４つのオブジェクトを含むが、２つのデータ・イベント・メッセージしか含まないメッセージ・シーケンス・チャートを考える。

第１のデータ・イベント・メッセージが第１オブジェクトと第２オブジェクトとの間で送受信され、第２のデータ・イベント・メッセージが第３オブジェクトと第４オブジェクトとの間で送受信される場合、これら２つのデータ・イベント・メッセージの間の順序付けされた関係はこれら２つのルールによっては規定されない。この場合、２つのデータ・イベント・メッセージは任意の順序で発生する。

図８では、ハードウェア４２とハードウェア４３は時間軸の順序関係を共有しないため、データ・イベント・メッセージｍ１とデータ・イベント・メッセージｍ２の受信順序は図８に表現した順序と異なってもかまわない。

ハードウェア４１とハードウェア４２は時間軸の順序関係を共有しないため、データ・イベント・メッセージｍ３とデータ・イベント・メッセージｍ４の受信順序は、図８に表現した順序と異なってもかまわない。

図９は、メッセージ・シーケンス・チャートの他の例を示す図である。
メッセージ・シーケンス・チャート４０ａには、複数のオブジェクトとして、ハードウェア４１、４２、４３が設けられている。

メッセージ・シーケンス・チャート４０ａは、同時性制約、タイムアウト制約および同期エッジの３つの（先進的）機能を有している。
同時性制約およびタイムアウト制約については、イベントを包囲するボックスが描画されている。

同時性制約を示すボックス４７には、このボックス４７がこれらのイベントを同時イベントにグループ化することを示す「ｓｉｍｕｌ」がラベル付けされている。
ボックス４７は、データ・イベント・メッセージｍ５とデータ・イベント・メッセージｍ６に関する送信イベントをグループ化している。

タイムアウト制約を示すボックス４８には、タイムアウト制約のタイムアウト値を表す整数がラベル付けされている。
実行がタイムアウト制約に直面すると、示されたタイムアウト期間が経過するまで実行が停止される。時限実行モデルでは、タイムアウト期間が経過して初めて実行が継続する。

従って、データ・イベント・メッセージｍ７は、ボックス４８のラベルに付されている「３」時刻単位後経過した後に、送信される。
同期エッジは、データ・イベント・メッセージの順序を特定するために用いられる。同期エッジの表示は、名前「ｓｙｎｃｈ」が同期エッジに利用可能であると言う点を除いて、データ・イベント・メッセージと同様に描かれている。

「ｓｙｎｃｈ」とラベル付けされたデータ・イベント・メッセージ（以下、「同期メッセージ」と言う）を利用して、順序付けされた関係を確立する。例えば、ハードウェア４２に関する送信イベントと、ハードウェア４１に関する受信イベントを含む同期エッジを考える。同期メッセージは、ハードウェア４２がデータ・イベント・メッセージｍ８を受信した後に送信されるものとして示される。同期メッセージは、また、データ・イベント・メッセージｍ９が送信されるまでにハードウェア４１により受信されるものとして示される。

メッセージ・シーケンス・チャート４０ａによれば、ハードウェア４２におけるデータ・イベント・メッセージｍ８の受信は、ハードウェア４１におけるデータ・イベント・メッセージｍ９の送信前に発生する必要がある。

ここで、同期エッジは関連性のないオブジェクト間の関係を生成する。しかしながら、ある実施例によると、同期エッジによって関連するオブジェクト間において実際にメッセージは送受信されない。

同期メッセージは、データ・イベント・メッセージｍ７およびデータ・イベント・メッセージｍ８と、データ・イベント・メッセージｍ５およびデータ・イベント・メッセージｍ６とを比較して、これらの間の順序を生成するものではない。

しかしながら、同期メッセージは、データ・イベント・メッセージｍ７とデータ・イベント・メッセージｍ８に関する受信イベントの後にデータ・イベント・メッセージｍ９に関する送信イベントを発生させる。

次に、設計検証装置１０の構成を説明する。
＜設計検証装置＞
図１０は、設計検証装置のハードウェア構成例を示す図である。

設計検証装置１０は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０９を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、外部補助記憶装置１０６、インタフェース１０７および通信インタフェース１０８が接続されている。

ＣＰＵ１０１は、入力インタフェース１０５、外部補助記憶装置１０６、インタフェース１０７および通信インタフェース１０８から受信した情報を処理するよう動作する。
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。また、ＨＤＤ１０３内には、ＸＭＬ（eXtensible Markup Language）形式で表現されたリスト構造や、プログラムファイルが格納される。

グラフィック処理装置１０４には、モニタ１０４ａが接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１０４ａの画面に表示させる。入力インタフェース１０５には、キーボード１０５ａとマウス１０５ｂとが接続されている。入力インタフェース１０５は、キーボード１０５ａやマウス１０５ｂから送られてくる信号を、バス１０９を介してＣＰＵ１０１に送信する。

外部補助記憶装置１０６は、記録媒体に書き込まれた情報を読み取ったり、記録媒体に情報を書き込んだりする。外部補助記憶装置１０６で読み書きが可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。

インタフェース１０７は、設計検証装置１０に接続された装置から情報を送受信するよう動作可能なハードウェアである。具体的には、インタフェース１０７は、信号インタフェース２００およびテスト対象装置３００と通信する。

通信インタフェース１０８は、ネットワーク４００に接続されている。通信インタフェース１０８は、ネットワーク４００を介して、他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。このようなハードウェア構成の設計検証装置１０内には、以下のような機能が設けられる。

図１１は、設計検証装置の機能を示すブロック図である。
設計検証装置１０は、検証用シナリオ生成部１１と、検証用シナリオ格納部１２と、条件付与部１３と、電力管理検証用シナリオ格納部１４と、出力部１５とを有している。

また、図示していないが、設計検証装置１０は、他にもメッセージ・シーケンス・チャートを生成するツールや、設計の実現形態の動作を検証するため、メッセージ・シーケンス・チャートに基づくステートマシン（State Machine）を生成するためのツールを有していてもよい。

検証用シナリオ生成部１１は、図５および図６にて説明したＬＳＩ２０の設計仕様のデータに基づいて、シナリオ毎に検証用シナリオを生成する。
ここで、検証用シナリオは、ＬＳＩ２０の設計仕様の各シナリオが備えるメッセージ・シーケンス・チャートそれぞれに設計仕様のラベル（検証対象部位を識別する識別情報）を関連付けた情報である。なお、検証対象部位としては、例えば、機能、シナリオ、メッセージ・シーケンス・チャート等が挙げられる。

この検証用シナリオは、条件付与部１３の処理対象となる中間的なデータである。
また、検証用シナリオ生成部１１は、検証用シナリオを生成する際に作成するデータを一時記憶する機能も有している。

検証用シナリオ格納部１２は、検証用シナリオ生成部１１により生成された検証用シナリオを格納する。
条件付与部１３は、入力される電力管理仕様に基づいて、検証用シナリオ格納部１２に格納されている検証用シナリオに制約条件を付与する。

電力管理仕様は、電力制御のための制御信号に対する仕様である。
条件付与部１３は、制約条件を付与する際に、モードテーブルと、事前条件テーブルを作成する。

モードテーブルは、入力された電力管理仕様のメッセージ・シーケンス・チャートに対応するモードとの関係を示すテーブルである。
事前条件テーブルは、作成したモードテーブルの各メッセージ・シーケンス・チャートそれぞれに関連するモードとの関係を示すテーブルである。なお、モードテーブルおよび事前条件テーブルの生成方法については後述する。

そして、条件付与部１３は、事前条件テーブルに格納された情報に基づいて、検証用シナリオに制約条件を付与することで、制約条件が付与された検証用シナリオは、ＬＳＩ２０の設計仕様に、電力管理仕様が関連づけられたシナリオになる。以下、このシナリオを電力管理検証用シナリオと言う。

条件付与部１３は、作成した電力管理検証用シナリオを、電力管理検証用シナリオ格納部１４に格納する。
出力部１５は、予め用意されたフォーマットに従って、電力管理検証用シナリオの集合に関するリスト（シナリオリスト１５ａ）を出力する。

次に、電力管理仕様のデータ構造を説明する。
図１２は、電力管理仕様のデータ構造の一例を示す図である。
電力管理仕様は、パワーの動作モードを示す複数のシナリオにより実現される。

図１２に示す電力管理仕様は、シナリオブロック５１ａに対応付けられているシナリオ「モード：Ｆｕｌｌ」とシナリオブロック５１ｂに対応付けられているシナリオ「モード：Ｇａｔｉｎｇ」とシナリオブロック５１ｃに対応付けられているシナリオ「モード：Ｓｕｓｐｅｎｄ」とを有している。

ここで、シナリオ「モード：Ｆｕｌｌ」は、当該シナリオの実行時に、クロックゲーティングを行わず、ＬＳＩ２０の全ての回路に電圧を供給するシナリオである。
シナリオ「モード：Ｇａｔｉｎｇ」は、当該シナリオの実行時に、ＬＳＩ２０の指定された回路に対しクロックゲーティングを行うシナリオである。

シナリオ「モード：Ｓｕｓｐｅｎｄ」は、当該シナリオの実行時に、例えば、ＬＳＩ２０の使用を一旦中断する際に、作業状態をメモリに保存し、再開時に電源を切る直前の状態に戻すモード（省電力モード）を行うシナリオである。

各シナリオは、シナリオを実現するためのメッセージ・シーケンス・チャートを１つまたは複数有している。
シナリオブロック５１ａは、ＭＳＣブロック５１１ａと、ＭＳＣブロック５１２ａと、ＭＳＣブロック５１３ａとを有している。

シナリオブロック５１ｂは、ＭＳＣブロック５１１ｂと、ＭＳＣブロック５１２ｂと、ＭＳＣブロック５１３ｂとを有している。
シナリオブロック５１ｃは、ＭＳＣブロック５１１ｃと、ＭＳＣブロック５１２ｃとを有している。

各ＭＳＣブロックに対応付けられているメッセージ・シーケンス・チャートは、メッセージ・シーケンス・チャートを識別するためのＭＳＣ名を有している。例えば、ＭＳＣブロック５１１ａ、ＭＳＣブロック５１１ｂ、ＭＳＣブロック５１１ｃに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃ａ」である。ＭＳＣブロック５１２ａ、ＭＳＣブロック５１２ｂに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃ｂ」である。ＭＳＣブロック５１３ａに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃ｃ」である。ＭＳＣブロック５１３ｂに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃ｄ」である。ＭＳＣブロック５１２ｃに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名は、「ＭＳＣ＃ｅ」である。

各メッセージ・シーケンス・チャートには、ＬＳＩ２０の機能仕様が有するメッセージ・シーケンス・チャートへのリンクが設けられている。
例えば、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートには、図６に示すＭＳＣ名「ＭＳＣ＃Ａ」のメッセージ・シーケンス・チャートへのリンクが張られている。このリンクによって、電力管理仕様が有するメッセージ・シーケンス・チャートの事前条件がＬＳＩ２０の設計仕様が有する機能の制約条件に関連づけられている。

また、電力管理仕様が有する各メッセージ・シーケンス・チャートは、制約条件として、事前条件、事後条件、不変条件のうちの１つまたは複数が定義されている場合がある。これら各条件が存在する場合には、その条件が設定される。

なお、同じＭＳＣ名のメッセージ・シーケンス・チャートにおいても異なる制約条件が定義されている場合がある。例えば、シナリオ「モード：Ｆｕｌｌ」が有するＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートの制約条件は、「ｃｌｏｃｋ ｇａｔｉｎｇ ＯＦＦ」である。他方、シナリオ「モード：Ｇａｔｉｎｇ」が有するＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートの制約条件は、「ｃｌｏｃｋ ｇａｔｉｎｇ ＯＮ」である。

さらに、電力管理仕様が有する各メッセージ・シーケンス・チャートは、該当するモードを駆動する電圧設定条件が定義されている場合がある。例えば、シナリオ「モード：Ｆｕｌｌ」が有するＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートの電圧設定条件は、「１．５Ｖ」である。他方、シナリオ「モード：Ｇａｔｉｎｇ」が有するＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートの電圧設定条件は、「１．５Ｖ」である。

次に、モードテーブルおよび事前条件テーブルを説明する。
図１３は、モードテーブルの一例を示す図である。
モードテーブル１３１ａには、ＭＳＣ名とモード名の欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。

モードテーブル１３１ａには、電力管理仕様が有するシナリオの各モードにおける全てのメッセージ・シーケンス・チャートのリンク先のＭＳＣ名を識別する情報が格納される。

図１３では、シナリオ「モード：Ｆｕｌｌ」は、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートと、ＭＳＣ名「ＭＳＣ＃ｂ」のメッセージ・シーケンス・チャートと、ＭＳＣ名「ＭＳＣ＃ｃ」のメッセージ・シーケンス・チャートとを有している。従って、モードテーブル１３１ａのＭＳＣ名の欄には、それぞれ、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ａ」、ＭＳＣ名「ＭＳＣ＃ｂ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ｂ」、ＭＳＣ名「ＭＳＣ＃ｃ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ｃ」が格納されている。

そして、対応するモード名の欄には、ＭＳＣ名の欄のリンク元のメッセージ・シーケンス・チャートを有する電力管理仕様のシナリオ名を識別するモード名「Ｆｕｌｌ」が格納されている。

また、シナリオ「モード：Ｇａｔｉｎｇ」は、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートと、ＭＳＣ名「ＭＳＣ＃ｂ」のメッセージ・シーケンス・チャートと、ＭＳＣ名「ＭＳＣ＃ｄ」のメッセージ・シーケンス・チャートとを有している。従って、モードテーブル１３１ａのＭＳＣ名の欄には、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ａ」、ＭＳＣ名「ＭＳＣ＃ｂ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ｂ」、ＭＳＣ名「ＭＳＣ＃ｄ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ｄ」が格納されている。

そして、対応するモード名の欄には、ＭＳＣ名の欄のリンク元のメッセージ・シーケンス・チャートを有する電力管理仕様のシナリオ名を識別するモード名「Ｇａｔｉｎｇ」が格納されている。

また、シナリオ「モード：Ｓｕｓｐｅｎｄ」は、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートと、ＭＳＣ名「ＭＳＣ＃ｅ」のメッセージ・シーケンス・チャートとを有している。従って、モードテーブル１３１ａのＭＳＣ名の欄には、ＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ａ」、ＭＳＣ名「ＭＳＣ＃ｅ」のメッセージ・シーケンス・チャートのリンク先のメッセージ・シーケンス・チャートのＭＳＣ名「ＭＳＣ＃Ｅ」が格納されている。

そして、対応するモード名の欄には、ＭＳＣ名の欄のリンク元のメッセージ・シーケンス・チャートを有する電力管理仕様のシナリオ名を識別するモード名「Ｓｕｓｐｅｎｄ」が格納されている。

図１４は、事前条件テーブルの一例を示す図である。
事前条件テーブル１３１ｂには、ＭＳＣ名と事前条件の欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。

ＭＳＣ名の欄には、モードテーブル１３１ａのＭＳＣ名の欄に格納された全てのメッセージ・シーケンス・チャートの種別を識別する情報が格納される。図１４では、図１３に示すモードテーブル１３１ａのＭＳＣ名の欄に格納されたＭＳＣ名「ＭＳＣ＃Ａ」〜「ＭＳＣ＃Ｅ」が格納されている。

事前条件の欄には、ＭＳＣ名の欄に格納されているＭＳＣ名のメッセージ・シーケンス・チャートに対応するモード名が格納されている。図１４では、例えば、ＭＳＣ名「ＭＳＣ＃Ａ」のメッセージ・シーケンス・チャートに対応するモード名「Ｆｕｌｌ」、「Ｇａｔｉｎｇ」、「Ｓｕｓｐｅｎｄ」が格納されている。なお、各モード名間は、「ｏｒ」で接続されている。

この事前条件の欄に格納されたモード名は、対応するＭＳＣ名の欄に格納されているＭＳＣ名のメッセージ・シーケンス・チャートに遷移するときの事前条件を示している。例えば、一番上のレコードは、モード名「Ｆｕｌｌ」、「Ｇａｔｉｎｇ」、「Ｓｕｓｐｅｎｄ」のシナリオのいずれかであれば、すなわち、「Ｆｕｌｌ ｏｒ Ｇａｔｉｎｇ ｏｒ Ｓｕｓｐｅｎｄ＝ｔｒｕｅ」であれば、ＭＳＣ名「ＭＳＣ＃Ａ」のメッセージ・シーケンス・チャートに遷移することを示している。

次に、設計検証装置１０の全体処理を説明する。
図１５は、設計検証装置の全体処理を示すフローチャートである。
まず、検証用シナリオ生成部１１が、ユーザにより入力されたＬＳＩ２０の設計仕様に基づいて、検証用シナリオ生成処理を行って検証用シナリオを生成する（ステップＳ１）。生成した検証用シナリオは、検証用シナリオ格納部１２に格納する。

次に、条件付与部１３が、ユーザにより入力された電力管理仕様および検証用シナリオ格納部１２に格納されている検証用シナリオに基づいて、制約条件付与処理を行って検証用シナリオに制約条件を付与する（ステップＳ２）。当該処理により生成された電力管理検証用シナリオは、電力管理検証用シナリオ格納部１４に格納する。

次に、出力部１５が、シナリオリスト１５ａを出力する（ステップＳ３）。
以上で、全体処理の説明を終了する。
なお、検証用シナリオ生成処理を予め行って生成した検証用シナリオを検証用シナリオ格納部１２に格納しておいて、ユーザによる電力管理仕様の入力を待って制約条件付与処理を行うようにしてもよい。また、ユーザによる電力管理仕様の入力時に、検証用シナリオ生成処理を開始するようにしてもよい。

次に、ステップＳ１に示す検証用シナリオ生成処理を説明する。
図１６および図１７は、検証用シナリオ生成処理を示すフローチャートである。
まず、ＬＳＩ２０の設計仕様にラベルを付与する（ステップＳ１１）。この処理については、後に詳述する。

次に、ステップＳ１１にて付与された設計仕様において、メッセージ・シーケンス・チャートを備える有向グラフを平坦化（Flatten）する（ステップＳ１２）。具体的には、有向グラフの階層構造を取り払う。

次に、平坦化した有向グラフからメッセージ・シーケンス・チャートを１つ選択する（ステップＳ１３）。
次に、選択したメッセージ・シーケンス・チャートを有限ステートマシン（FSM）に変換する（ステップＳ１４）。これにより、一連のメッセージ・シーケンス・チャートを組み合わせたデータ・イベント・メッセージのやり取りを有限ステートマシンで表現する。この処理については、後に詳述する。

次に、変換された有限ステートマシンの各ステートに、メッセージ・シーケンス・チャートに付されていたラベルを付与する（ステップＳ１５）。
ステップＳ１４およびステップＳ１５の処理により、有限ステートマシンの各ステートにラベルが付与される。各ステートにラベルが付与された有限ステートマシンは、検証用シナリオ生成部１１が一時記憶する。

次に、未処理のメッセージ・シーケンス・チャートが存在するか否かを判断する（ステップＳ１６）。
未処理のメッセージ・シーケンス・チャートが存在する場合（ステップＳ１６のＹｅｓ）、ステップＳ１３に移行して未処理のメッセージ・シーケンス・チャートを選択し、選択したメッセージ・シーケンス・チャートについて、ステップＳ１４以降の処理を引き続き行う。

一方、未処理のメッセージ・シーケンス・チャートが存在しない場合（ステップＳ１６のＮｏ）、ステップＳ１１にてラベルが付与された設計仕様を参照し、設計仕様が備えるメッセージ・シーケンス・チャートを１つ選択する（ステップＳ１７）。

次に、メッセージ・シーケンス・チャートの制約（synchやtimeout等）から、選択したメッセージ・シーケンス・チャートの有限ステートマシンの不要なステートを刈る（ステップＳ１８）。この処理は後に詳述する。

次に、未処理のメッセージ・シーケンス・チャートが存在するか否かを判断する（ステップＳ１９）。
未処理のメッセージ・シーケンス・チャートが存在する場合（ステップＳ１９のＹｅｓ）、ステップＳ１７に移行し、未処理のメッセージ・シーケンス・チャートを選択する。そして、選択したメッセージ・シーケンス・チャートについてステップＳ１８以降の処理を引き続き行う。

一方、未処理のメッセージ・シーケンス・チャートが存在しない場合（ステップＳ１９のＮｏ）、ステップＳ１１にてラベルが付与されたＬＳＩ２０の設計仕様を参照し、設計仕様が備える機能を選択する（図１７のステップＳ２０）。

次に、選択された機能からシナリオを選択する（ステップＳ２１）。
次に、ステップＳ１５にてラベルが付与された有限ステートマシンから、選択したシナリオと同じラベルを有する有限ステートマシンを抽出する（ステップＳ２２）。

次に、選択したシナリオと同じラベルを有する有限ステートマシンの部分（以下、「部分有限ステートマシン」と言う）を抽出する（ステップＳ２３）。検証用シナリオ生成部１１は、抽出した有限ステートマシンの部分を一時記憶する。

次に、ステップＳ２３にて抽出した有限ステートマシンの部分から検証用シナリオを生成し、生成した検証用シナリオを検証用シナリオ格納部１２に格納する（ステップＳ２４）。なお、有限ステートマシンの部分から検証用シナリオを生成する方法は、後に詳述する。

次に、ステップＳ２０にて選択した機能に、未処理のシナリオが存在するか否かを判断する（ステップＳ２５）。
未処理のシナリオが存在する場合（ステップＳ２５のＹｅｓ）、ステップＳ２１に移行し、未処理のシナリオを選択し、選択したシナリオについてステップＳ２２以降の処理を引き続き行う。

一方、ステップＳ２０にて選択した機能に、未処理のシナリオが存在しない場合（ステップＳ２５のＮｏ）、ＬＳＩ２０の設計仕様に、未処理の機能が存在するか否かを判断する（ステップＳ２６）。

未処理の機能が存在する場合（ステップＳ２６のＹｅｓ）、ステップＳ２０に移行し、未処理の機能を選択し、選択した機能についてステップＳ２１以降の処理を引き続き行う。

一方、未処理の機能が存在しない場合（ステップＳ２６のＮｏ）、処理を終了する。
以上で、検証用シナリオ生成処理の説明を終了する。
次に、ステップＳ１１のラベルの付与の処理（ラベル付与処理）を詳しく説明する。

図１８は、ラベル付与処理を示すフローチャートである。
まず、ＬＳＩ２０の設計仕様を参照し、機能を１つ選択する（ステップＳ３１）。
次に、選択した機能からシナリオを１つ選択する（ステップＳ３２）。

次に、選択したシナリオに付属するメッセージ・シーケンス・チャートを１つ選択する（ステップＳ３３）。
次に、選択したメッセージ・シーケンス・チャートに、ステップＳ３１にて選択した機能名（現在選択されている機能名）およびステップＳ３２にて選択したシナリオ名（現在選択されているシナリオ名）をラベルとして付与する（ステップＳ３４）。また、既にラベルが付与されている場合は、ラベルを追加する。

なお、ラベルには、機能名・シナリオ名に加え、メッセージ・シーケンス・チャート名を付するようにしてもよい。
次に、当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断する（ステップＳ３５）。

当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在する場合（ステップＳ３５のＹｅｓ）、ステップＳ３３に移行し、当該シナリオ内の未処理のメッセージ・シーケンス・チャートを選択し、選択したメッセージ・シーケンス・チャートについてステップＳ３４以降の処理を引き続き行う。

一方、当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在しない場合（ステップＳ３５のＮｏ）、未処理のシナリオが存在するか否かを判断する（ステップＳ３６）。

未処理のシナリオが存在する場合（ステップＳ３６のＹｅｓ）、ステップＳ３２に移行し、未処理のシナリオを選択し、選択したシナリオについてステップＳ３３以降の処理を引き続き行う。

一方、未処理のシナリオが存在しない場合（ステップＳ３６のＮｏ）、未処理の機能が存在するか否かを判断する（ステップＳ３７）。
未処理の機能が存在する場合（ステップＳ３７のＹｅｓ）、ステップＳ３１に移行し、未処理の機能を選択し、選択した機能についてステップＳ３２以降の処理を引き続き行う。

一方、未処理の機能が存在しない場合（ステップＳ３７のＮｏ）、処理を終了する。
以上で、ラベル付与処理の説明を終了する。
次に、ステップＳ２に示す制約条件付与処理を説明する。

図１９は、制約条件付与処理を示すフローチャートである。
まず、条件付与部１３が、モードテーブル作成処理を行ってモードテーブル１３１ａを作成する（ステップＳ４１）。

次に、条件付与部１３が、事前条件テーブル作成処理を行って事前条件テーブル１３１ｂを作成する（ステップＳ４２）。このとき、条件付与部１３が、作成された事前条件テーブル１３１ｂに基づいて、検証用シナリオに制約条件を付与する。その後、処理を終了する。

以上で、制約条件付与処理の説明を終了する。
次に、ステップＳ４１に示すモードテーブル作成処理を説明する。
図２０は、モードテーブル作成処理を示すフローチャートである。

まず、条件付与部１３が、入力された電力管理仕様からモード名Ｍ（Ｍはパラメータ）を選択する（ステップＳ５１）。
次に、モード名ＭのＭＳＣ名を１つ選択する。そして、選択したＭＳＣ名のメッセージ・シーケンス・チャートに設けられているリンクを辿って、対応するメッセージ・シーケンス・チャートのＭＳＣ名を選択する（ステップＳ５２）。

次に、選択したＭＳＣ名に一致するＭＳＣ名が、モードテーブル１３１ａに格納されているか否かを判断する（ステップＳ５３）。
選択したＭＳＣ名に一致するＭＳＣ名が、モードテーブル１３１ａに格納されていない場合（ステップＳ５３のＮｏ）、モードテーブル１３１ａに、選択したＭＳＣのＭＳＣ名とモード名Ｍを登録する（ステップＳ５４）。その後、ステップＳ５７に移行する。

一方、選択したＭＳＣ名が、モードテーブル１３１ａに格納されている場合（ステップＳ５３のＹｅｓ）、モードテーブル１３１ａからそのＭＳＣ名に関連づけられているモード名Ｖ（Ｖはパラメータ）を参照する（ステップＳ５５）。

次に、モード名Ｍとモード名Ｖが一致するか否かを判断する（ステップＳ５６）。
モード名Ｍとモード名Ｖが一致しない場合（ステップＳ５６のＮｏ）、ステップＳ５４に移行する。そして、ステップＳ５４以降の処理を引き続き行う。

一方、モード名Ｍとモード名Ｖが一致する場合（ステップＳ５６のＹｅｓ）、または、ステップＳ５４の処理後に、ステップＳ５１にて選択したモード名Ｍに未選択のＭＳＣが存在するか否かを判断する（ステップＳ５７）。

モード名Ｍに未選択のＭＳＣが存在する場合（ステップＳ５７のＹｅｓ）、ステップＳ５２に移行する。そして、未選択のＭＳＣ名を選択し、ステップＳ５３以降の処理を引き続き行う。

一方、モード名Ｍに未選択のＭＳＣ名が存在しない場合（ステップＳ５７のＮｏ）、電力管理仕様に未選択のモード名が存在するか否かを判断する（ステップＳ５８）。
電力管理仕様に未選択のモード名が存在する場合（ステップＳ５８のＹｅｓ）、ステップＳ５１に移行する。そして、電力管理仕様から未選択のモード名Ｍを選択し、ステップＳ５２以降の処理を引き続き行う。

一方、電力管理仕様に未選択のモード名が存在しない場合（ステップＳ５８のＮｏ）、処理を終了する。
以上でモードテーブル作成処理の説明を終了する。

次に、ステップＳ４２に示す事前条件テーブル作成処理を説明する。
図２１は、事前条件テーブル作成処理を示すフローチャートである。
まず、モードテーブル１３１ａからＭＳＣ名を１つ選択する（ステップＳ６１）。

次に、選択したＭＳＣ名と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在するか否かを判断する（ステップＳ６２）。
選択したＭＳＣ名と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在しない場合（ステップＳ６２のＮｏ）、選択したＭＳＣ名を事前条件テーブル１３１ｂのＭＳＣ名の欄に格納する。そして、選択したＭＳＣ名に対応するモード名を事前条件テーブル１３１ｂの事前条件の欄に格納する（ステップＳ６３）。その後、ステップＳ６５に移行する。

一方、選択したＭＳＣ名と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在する場合（ステップＳ６２のＹｅｓ）、選択したＭＳＣ名を事前条件テーブル１３１ｂのＭＳＣ名の欄に格納する。そして、各レコードのモード名を「ｏｒ」で接続して事前条件テーブル１３１ｂの事前条件の欄に格納する（ステップＳ６４）。

次に、事前条件テーブル１３１ｂに格納した事前条件を、検証用シナリオが有するメッセージ・シーケンス・チャートの事前条件に設定する（ステップＳ６５）。これにより、電力管理仕様のメッセージ・シーケンス・チャートの事前条件が、検証用シナリオのメッセージ・シーケンス・チャートに反映される。

次に、モードテーブル１３１ａに未選択のＭＳＣ名が存在するか否かを判断する（ステップＳ６６）。
モードテーブル１３１ａに未選択のＭＳＣ名が存在する場合（ステップＳ６６のＹｅｓ）、ステップＳ６１に移行する。そして、モードテーブル１３１ａから未選択のＭＳＣ名を選択し、ステップＳ６２以降の処理を引き続き行う。

一方、モードテーブル１３１ａに未選択のＭＳＣ名が存在しない場合（ステップＳ６６のＮｏ）、処理を終了する。
以上で事前条件テーブル作成処理の説明を終了する。

以下、具体例を用いて設計検証装置１０の処理を説明する。
＜具体例＞
次に、ラベル付与処理の具体例を説明する。

図２２は、ＬＳＩの設計仕様のデータ構造の具体例を示す図である。
図２２に示すＬＳＩ２０の設計仕様は、グラフィック演算（図２２ではＧ演算と表記）に関する機能を表している。

この設計仕様は、ＣＰＵのグラフィックアクセラレータに対する起動要求によりグラフィックス演算を実行する簡単化された記述を提供する。
具体的には、機能ブロック５２にはグラフィック演算開始機能が設定されている。

図２２に示すＬＳＩ２０の設計仕様には、２つのシナリオが用意されている。
第１のシナリオは、起動要求により演算終了通知を受け付けるシナリオである。
この第１のシナリオは、機能ブロック５２に対応付けられている機能、シナリオブロック５２ａに対応付けられているシナリオ、シナリオブロック５２ａに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この検証用シナリオは、ＭＳＣブロック５２１ａ、５２２ａに対応付けられているメッセージ・シーケンス・チャートによって実現される。
ここで、ＭＳＣブロック５２２ａに対応付けられているメッセージ・シーケンス・チャートには、事前条件として「Ｖ＝ｔｒｕｅ」が設定されている。

第２のシナリオは、起動要求によりエラー通知を受け付けるシナリオである。
この第２のシナリオは、機能ブロック５２に対応付けられている機能、シナリオブロック５２ｂに対応付けられているシナリオ、シナリオブロック５２ｂに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この検証用シナリオは、ＭＳＣブロック５２１ｂ、５２２ｂに対応付けられているメッセージ・シーケンス・チャートによって実現される。
ここで、ＭＳＣブロック５２２ｂに対応付けられているメッセージ・シーケンス・チャートには、事前条件として「Ｖ＝ｆａｌｓｅ」が設定されている。

以下、第１のシナリオをシナリオ「成功」と言い、第２のシナリオをシナリオ「失敗」と言う。
図２３は、メッセージ・シーケンス・チャートの具体例を示す図である。

図２３（ａ）〜図２３（ｃ）は、それぞれ、検証用シナリオに関するメッセージ・シーケンス・チャートを示す図である。
図２３（ａ）に示すメッセージ・シーケンス・チャート４０ｂは、ＭＳＣブロック５２１ａに対応付けられているＭＳＣ名「問い合わせ」に関するメッセージ・シーケンス・チャート（以下、単にＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートと言う）である。

図２３（ａ）に示すオブジェクトは、ＬＳＩ２０が有するオブジェクトを示している。
このオブジェクトは、ＣＰＵ４１ａ、グラフィックスアクセラレータ（ＧＡ）４２ａおよびメモリコントローラ４３ａによって表される。

各オブジェクトはまた、ＣＰＵライン４４ａ、グラフィックスアクセラレータライン４５ａおよびメモリコントローラライン４６ａを含むオブジェクトラインを含む。
前述したルールを利用して、メッセージ・シーケンス・チャート４０ｂは、以下の処理を行う。

まず、ＣＰＵ４１ａは、起動要求をグラフィックスアクセラレータ４２ａに送信する（ステップＳ７１）。
起動要求の受信後、グラフィックスアクセラレータ４２ａは、データ取得要求をメモリコントローラ４３ａに送信する（ステップＳ７２）。

図２３（ｂ）に示すメッセージ・シーケンス・チャート４０ｃは、ＭＳＣブロック５２２ａに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名「データ取得成功」に関するメッセージ・シーケンス・チャート（以下、単にＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートと言う）である。

メッセージ・シーケンス・チャート４０ｃは、ＣＰＵ４１ａ、グラフィックスアクセラレータ４２ａおよびメモリコントローラ４３ａに関するメッセージ・シーケンス・チャートにおいて用いられる同一のオブジェクトの表示を含む。

前述したルールを利用して、メッセージ・シーケンス・チャート４０ｃは、以下の処理を行う。
データ取得要求の受信後、メモリコントローラ４３ａは、データ取得要求に対するデータをグラフィックスアクセラレータ４２ａに転送する（ステップＳ７３）。

グラフィックスアクセラレータ４２ａが、データを受信した後、グラフィックスアクセラレータ４２ａは、受信したデータを用いて演算を行う。
演算終了後、演算終了通知をＣＰＵ４１ａに送信する（ステップＳ７４）。

図２３（ｃ）に示すメッセージ・シーケンス・チャート４０ｄは、ＭＳＣブロック５２２ｂに対応付けられているメッセージ・シーケンス・チャートのＭＳＣ名「データ取得失敗」に関するメッセージ・シーケンス・チャート（以下、単にＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートと言う）である。

メッセージ・シーケンス・チャート４０ｄは、ＣＰＵ４１ａ、グラフィックスアクセラレータ４２ａおよびメモリコントローラ４３ａに関連するメッセージ・シーケンス・チャートで用いられる同一のオブジェクトの表現を含む。

前述したルールを利用して、メッセージ・シーケンス・チャート４０ｄは、以下の処理を行う。
メモリコントローラ４３ａは、エラーをグラフィックスアクセラレータ４２ａに送信する（ステップＳ７５）。グラフィックスアクセラレータ４２ａがエラーを受信した後、グラフィックスアクセラレータ４２ａは、エラーメッセージをＣＰＵ４１ａに送信する（ステップＳ７６）。

図２４〜図２６は、ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。
有向グラフ３０ａは、初期状態ブロック３１ａと、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５と、ＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャート３６と、ＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャート３７とを有している。

まず、ＬＳＩ２０の設計仕様を参照し、機能ブロック５２に対応付けられている機能「グラフィックス演算開始」を選択する。
次に、選択した機能からシナリオブロック５２ａに対応付けられているシナリオ「成功」を選択する。

次に、選択したシナリオ「成功」に対応付けられているＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５を選択する。
次に、選択したＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５にラベルを付与する。

前述したように、ラベルとして、現在選択されている機能名および現在選択されているシナリオ名を付与する。またラベルは、機能名・シナリオ名：シナリオの種類の順に付与する。従って、図２４に示す例では、「グラフィックス演算開始・成功：基本動作」のラベル５２１ａ１を付与する。

図２４は、ここまでの例を示している。
次に、当該シナリオブロック５２ａ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、未処理のＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートが存在する。従って、このＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートを選択する。

次に、選択したＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートに「グラフィックス演算開始・成功：基本動作」のラベル５２２ａ１を付与する。
次に、当該シナリオブロック５２ａ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、当該シナリオブロック５２ａ内に未処理のメッセージ・シーケンス・チャートは存在しない。

従って、機能ブロック５２内に未処理のシナリオが存在するか否かを判断すると、シナリオブロック５２ｂの未処理のシナリオ「失敗」が存在する。
そこで、このシナリオ「失敗」を選択する。

次に、選択したシナリオ「失敗」に対応付けられているＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートを選択する。
次に、選択したＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートに「グラフィックス演算開始・失敗：例外動作」のラベルを付与する。ここでは、既にラベル５２１ａ１が付与されているので、「グラフィックス演算開始・失敗：例外動作」のラベルをラベル５２１ａ１に追加する。

図２５ではここまでの例を示している。
次に、当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、未処理のＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートが存在する。従って、このＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートを選択する。

次に、選択したＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートに「グラフィックス演算開始・失敗：例外動作」のラベル５２２ｂ１を付与する。
次に、当該シナリオブロック５２ｂ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、当該シナリオブロック５２ｂ内に未選択のメッセージ・シーケンス・チャートは存在しない。

従って、機能ブロック５２内に未処理のシナリオが存在するか否かを判断すると、未処理のシナリオは存在しない。
従って、処理を終了する。

図２６は、ここまでの処理を示している。
図２７は、ラベルを付与したＬＳＩの設計仕様のデータ構造例を示す図である。
ラベルを付与したＬＳＩ２０のデータ６０は、ＸＭＬ形式で表現されている。

記述６１は、メッセージ・シーケンス・チャート４０ｂに関する記述部分を示している。また、記述６２は、メッセージ・シーケンス・チャート４０ｃに関する記述部分を示している。また、記述６３は、メッセージ・シーケンス・チャート４０ｄに関する記述部分を示している。

ここで、記述６１ａ、６２ａ、６３ａは、それぞれ、ラベル付与処理によって追記された行である。ラベル付与処理によって追記された行には、ラベル名であることを識別するＸＭＬタグ＜label name＞が付されている。また、タグ内の内容は、それぞれ付与されたラベルの内容を示している。

なお、前述したように、ラベルには、機能名・シナリオ名：シナリオの種類に加え、メッセージ・シーケンス・チャート名を付与するようにしてもよい。
図２８は、ＬＳＩの設計仕様にラベルを付与する他の具体例を示す図である。

図２８に示すラベル５２１ａ１、５２２ａ１、５２２ｂ１には、いずれも機能名・シナリオ名：シナリオの種類に加え、メッセージ・シーケンス・チャート名が付与されている。

次に、ステップＳ１４の、メッセージ・シーケンス・チャートを有限ステートマシンに変換する処理を、具体例を用いて説明する。
図２９は、有限ステートマシンに変換する処理を説明するメッセージ・シーケンス・チャートを示す図である。

有向グラフを有限ステートマシンに変換するため、有向グラフの備える各メッセージ・シーケンス・チャートによって規定されるイベントを用いて、有限ステートマシンのステートを特定する。

メッセージ・シーケンス・チャートは可能なイベント順序を規定し、各オブジェクトにおいて完了されたイベントは状態に対応する。例えば、初期状態はいずれのオブジェクトにおいても完了されないイベントに対応する。最終状態は、各オブジェクトにおいて完了した全てのイベントに対応する。

ここで、メッセージ・シーケンス・チャート７０を検討すると、メッセージ・シーケンス・チャート７０の一部が、オブジェクトの一部のイベント群を考慮することによって有限ステートマシンに投影される。

図２９に示すオブジェクトは、送信オブジェクト７１、長距離送信オブジェクト７２、受信オブジェクト７３および長距離受信オブジェクト７４によって表される。
例えば、メッセージ・シーケンス・チャート７０では、有限ステートマシンが、送信オブジェクト７１と受信オブジェクト７３に対して生成される。図示されるように、送信オブジェクト７１は送信イベントｔ１〜ｔ５を有している。受信オブジェクト７３は、受信イベントｒ１〜ｒ６を有している。

ここで、送信オブジェクト７１と受信オブジェクト７３は、メッセージを交換することなく、２つの同期エッジによって関連付けされる。
図３０は、図２９に示すメッセージ・シーケンス・チャートに関連する状態マトリックスを示す図である。

状態マトリックス８０を利用して、有限ステートマシンの生成方法をさらに説明する。
２つのみしかオブジェクトが存在しない場合、メッセージ・シーケンス・チャート７０の有限ステートマシンは、２次元の状態マトリックス８０として可視化することができる。

状態マトリックス８０の各ブロックは、送信オブジェクト７１が送信イベントｔｉを終了させ、受信オブジェクト７３が受信イベントｒｊを終了させた状態に対応している。
このため、状態マトリックス８０の各ブロックは、状態（ｔｉ，ｒｊ）を規定する。

ここで、状態マトリックス８０の原点は、左上隅に設けられている。初期状態は、記号⊥を用いて各オブジェクトに対して示される。
状態マトリックス８０の左上隅の状態が初期状態であるため、状態遷移は各状態から右下にトレースすることによって特定される。最終状態は、右下隅に示す状態となる。

送信オブジェクト７１と受信オブジェクト７３とが２つの同期エッジによっては関連付けされていない場合、状態マトリックス８０は、（ｎ×ｍ）の完全な２次元の状態マトリックスとなる（但し、ｎは、送信オブジェクト７１により送信されるメッセージの個数であり、ｍは、受信オブジェクト７３によって受信されるメッセージの個数である）。

しかしながら、メッセージ・シーケンス・チャート７０の同期エッジの存在は、状態マトリックス８０に示されるような有効な状態の個数を減少させる。
同期エッジにより、状態マトリックス８０に示される一部の状態は有効とはならず、２次元マトリックスから「クロスアウト（cross out）」させることが可能である。

例えば、送信イベントｔ３が送信オブジェクト７１から受信オブジェクト７３への同期エッジに対応する送信イベントであると仮定する。
受信イベントｒ３は、同一の同期エッジに関連する対応する受信イベントである。受信イベントｒ２の後に発生する受信オブジェクト７３におけるいずれのイベントも、送信イベントｔ３の後に発生する必要がある。従って、受信イベントｒ３〜ｒ６は送信イベントｔ３の前に発生することはできない。

このオブジェクトを利用して、無効状態に対応する状態マトリックス８０の領域８１は、クロスアウトされる。同様のオブジェクトを用いて、メッセージ・シーケンス・チャート７０の第２同期エッジに関連する領域８２をクロスアウトする。

残りのマトリックスは、メッセージ・シーケンス・チャート７０を正確に表している。送信イベントｔ２や受信イベントｒ１等の状態は、送信オブジェクト７１が送信イベントｔ２を終了させ、受信オブジェクト７３が受信イベントｒ１を終了させた状態を表す。

図３１は、状態マトリックスに関する状態図を示す図である。
状態図９０に示す１つのステート９１は、図３０に示した状態マトリックス８０の１つの領域に対応している。

ステート９１内の値は、状態を示している。
状態図９０の各水平方向への遷移は、メッセージの受信に対応している。このため有限ステートマシンによるメッセージの送信として実現される。

同様に、状態図９０の各垂直方向への遷移は、メッセージの送信に対応している。このため、有限ステートマシンによるメッセージの受信待機として実現される。
現在、状態図９０の水平方向への遷移と垂直方向への遷移の両方が行われうる状態（ｉ，ｊ）であるとき、水平方向への遷移は適切なメッセージを送信することにより行われる。

その後、垂直方向への遷移が予想されるメッセージが受信されたか判断することによって試行される。後者の状態が満たされる場合、垂直方向への遷移が行われてもよく、次の状態は状態（ｉ＋１，ｊ＋１）となる。

後者の状態が満たされていない場合、水平方向への遷移のみが行われ、次の状態は（ｉ＋１，ｊ）となる。
オブジェクトが永久に待機することがないように、メッセージの受信待機中にタイマが利用される。

すなわち、適切なタイムアウト期間後に待機は終了する。垂直または水平のみの遷移しかある状態から行うことができない場合、これらの動作のみが生成される。
遷移方向が生成可能な有限ステートマシンに影響する１つの変数である一方、他の変数はあるステートに関する特定のタイプのイベントである。

例えば、図２９に示す送信オブジェクト７１と受信オブジェクト７３において、オブジェクトラインに関連する各イベントは３つのタイプのうちの１つである。送信オブジェクト７１では、これらのタイプはメッセージ送信イベント、タイマ始動イベントおよびタイムアウト信号受信イベントである。

受信オブジェクト７３では、これらのタイプは、メッセージ受信イベント、タイマ始動イベントおよびタイムアウト信号受信イベントである。各オブジェクトのこれら３つのタイプのイベントは、有限ステートマシンの各ステートに対して生成されるコードが当該状態の正確な組み合わせに依存するため、有限ステートマシン変換中に考慮される９つの組み合わせを生じさせる。

これらの技術を利用して、有限ステートマシンがメッセージ・シーケンス・チャートに対して生成される。
シナリオに対する有限ステートマシンを生成するため、有限ステートマシンがパスに沿って各メッセージ・シーケンス・チャートに対して生成され、必要に応じて合成される。例えば、１つのメッセージ・シーケンス・チャートの終わりの次の状態は、パスに沿った次のメッセージ・シーケンス・チャートの開始状態となる。

信号および変数宣言の全てを組み合わせることによって、有限ステートマシンを自動的に生成、編集することができる。また、生成、編集された有限ステートマシンを用いてテスト対象装置３００の動作をシミュレートすることができる。

次に、ステップＳ１５に示す有限ステートマシンにラベルを付与する処理を具体的に説明する。
図３２は、有限ステートマシンにラベルを付与する具体例を示す図である。

まず、前述した方法にて生成した有限ステートマシン９０ａのステート１つ１つに対し、対応するメッセージ・シーケンス・チャートのデータ・イベント・メッセージをラベルとして付与する。

図３２では、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートから有限ステートマシンのステートＳｔ１、Ｓｔ２が生成されている。
ここで、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートには、「グラフィックス演算開始・成功：基本動作」のラベルと「グラフィックス演算開始・失敗：例外動作」のラベルが付与されている。

従って、これらステートＳｔ１、Ｓｔ２それぞれにも、「グラフィックス演算開始・成功：基本動作」のラベルと「グラフィックス演算開始・失敗：例外動作」のラベルを付与する。

図３３は、有限ステートマシンにラベルの付与が終了したときの状態を示す図である。
図３３では、ＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートからステートＳｔ３、Ｓｔ４が生成されている。

ここで、ＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートには、「グラフィックス演算開始・成功：基本動作」のラベルが付与されている。
従って、これらステートＳｔ３、Ｓｔ４それぞれにも、「グラフィックス演算開始・成功：基本動作」のラベルを付与する。

また、ＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートからステートＳｔ５、Ｓｔ６が生成されている。
ここで、ＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートには、「グラフィックス演算開始・失敗：例外動作」のラベルが付与されている。

従って、これらステートＳｔ５、Ｓｔ６それぞれにも、「グラフィックス演算開始・失敗：例外動作」のラベルを付与する。
次に、ステップＳ１８のメッセージ・シーケンス・チャートの制約から有限ステートマシンの状態を刈る処理を、具体例を用いて説明する。

図３４は、状態マトリックスに関する状態図を示す図である。
同期イベントは、実際の動作イベントの部分的順序付けを外部または他の装置により限定するのに利用されているだけであるため、状態図９０から削除してもよい。同期イベントを削除することにより、図３４に示される簡単化された状態図９２が得られる。

図３５は、有限ステートマシンのデータ構造例を示す図である。
有限ステートマシンのデータ１１０は、ＸＭＬ形式で表現されている。
記述１１０ａは、有限ステートマシン９０ａの識別子に関する記述部分を示している。当該記述１１０ａには、有限ステートマシンであることを識別する有限ステートマシンタグ＜fsm name＞が付されている。また、タグ内の内容は、それぞれ付与されたラベルの内容を示している。

また、記述１１１〜１１６は、それぞれ各ステートＳｔ１〜Ｓｔ６に関する記述部分を示している。
また、記述１１７は、各ステートＳｔ１〜Ｓｔ６に関する遷移方向を示している。

次に、図２２に示すＬＳＩ２０の設計仕様および図３３に示すラベル付与済みの有限ステートマシン９０ａを用いてシナリオ毎の検証用シナリオを生成する具体例を説明する。
まず、図２２に示す設計仕様から機能ブロック５２に対応付けられている機能「グラフィックス演算開始」を選択する。

次に、選択した機能「グラフィックス演算開始」からシナリオ「成功」を選択する。
次に、選択したシナリオ「成功」と同じラベルを備える有限ステートマシンを抽出する。

具体的には、図３３に示す有限ステートマシン９０ａを抽出する。
次に、選択したシナリオと同じラベルを持つ有限ステートマシンの部分を抽出する。
図３３に示すように、シナリオ「成功」は、「グラフィックス演算開始・成功：基本動作」のラベルを備えているため、このラベルと同じラベルを備えるステートＳｔ１、Ｓｔ２、Ｓｔ３、Ｓｔ４を抽出する。

次に、抽出した有限ステートマシンの部分を、シナリオ「成功」を検証する検証用シナリオとして検証用シナリオ格納部１２に格納する。
次に、選択した機能に未処理のシナリオが残っているか否かを判断すると、シナリオ「失敗」が残っている。

従って、選択した機能「グラフィックス演算開始」からシナリオ「失敗」を選択する。
次に、選択したシナリオ「失敗」と同じラベルを備える有限ステートマシンを抽出する。

具体的には、図３３に示す有限ステートマシン９０ａを抽出する。
次に、選択したシナリオと同じラベルを持つ有限ステートマシンの部分を抽出する。
図３３に示すように、シナリオ「失敗」は、「グラフィックス演算開始・失敗：例外動作」のラベルを備えているため、このラベルと同じラベルを備えるステートＳｔ１、Ｓｔ２、Ｓｔ５、Ｓｔ６を抽出する。

次に、抽出した部分有限ステートマシンを、シナリオ「失敗」を検証する検証用シナリオとして検証用シナリオ格納部１２に格納する。
次に、選択した機能に未処理のシナリオが残っているか否かを判断すると、残っていない。

次に、未処理の機能が残っているか否かを判断すると、残っていない。
従って、処理を終了する。
図３６は、検証用シナリオ格納部に格納されている検証用シナリオを示す図である。

図３６に示すように、シナリオ「成功」を検証する検証用シナリオＳｃ１およびシナリオ「失敗」を検証する検証用シナリオＳｃ２が格納されている。
次に、検証用シナリオ生成処理におけるステップＳ２４の有限ステートマシンの部分から検証用シナリオを生成する方法を詳しく説明する。

＜検証用シナリオの生成＞
前述した具体例では、有限ステートマシンの部分から検証用シナリオを容易に作成することができた。

しかしながら、有限ステートマシンの部分のステートがループしている場合等がある。 この場合、検証用シナリオ生成部１１は、有限ステートマシンの部分を、いくつかの構成単位に「切断」または分割した、検証用シナリオを生成する。

例えば、有限ステートマシンの部分は、パスにおいて再出現するステートに従って切断されてもよい。代わりに、または加えて、「少なくとも最小数または最大数以下のステートが各検証用シナリオにおいて特定されることを要求する」と言う制約を有する複数の検証用シナリオに切断されてもよい。

例えば、以下の有限ステートマシンの部分が抽出されたものとする。
Ｓｔ２→Ｓｔ４→Ｓｔ６→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ６→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ２
有限ステートマシンの部分を分割する１つの論理的方法は、再出現するステートを切断することである。

例えば、ステートＳｔ２は、この長い有限ステートマシンの部分を４つの検証用シナリオに切断するのに利用される。
（１）Ｓｔ２→Ｓｔ４→Ｓｔ６→Ｓｔ７
（２）Ｓｔ２→Ｓｔ３→Ｓｔ６→Ｓｔ７
（３）Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ７
（４）Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ２
より長い検証用シナリオを生成するため、検証用シナリオ生成部１１は、ステートＳｔ２を用いて切断処理を実行すると共に、各検証用シナリオが少なくとも５つのステートを含むことを要求することができる。

これらの制約を用いて、以下の２つの検証用シナリオが特定される。
（５）Ｓｔ２→Ｓｔ４→Ｓｔ６→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ６→Ｓｔ７
（６）Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ２
次に、モード条件を付与する具体例を説明する。

以下具体例として、図２２に示すＬＳＩ２０のグラフィックス演算機能に対し、図３７に示す電力管理仕様を用いてモードテーブル１３１ａおよび事前条件テーブル１３１ｂを作成する例を説明する。

図３７は、具体例の電力管理仕様を示す図である。
図３７に示す機能ブロック５３に対応付けられた電力管理仕様は、シナリオブロック５３ａに対応付けられているシナリオ「モード：Ｆｕｌｌ」とシナリオブロック５３ｂに対応付けられているシナリオ「モード：Ｓｕｓｐｅｎｄ」とを有している。

シナリオ「モード：Ｆｕｌｌ」は、ＭＳＣブロック５３１ａに対応付けられているＭＳＣ名「ＭＳＣ＃１」のメッセージ・シーケンス・チャートとＭＳＣブロック５３２ａに対応付けられているＭＳＣ名「ＭＳＣ＃２」のメッセージ・シーケンス・チャートにより実現されるシナリオである。

このシナリオ「モード：Ｆｕｌｌ」は、データ取得成功時には、Ｆｕｌｌモードに切り替わるシナリオである。
シナリオ「モード：Ｓｕｓｐｅｎｄ」は、ＭＳＣブロック５３１ｂに対応付けられているＭＳＣ名「ＭＳＣ＃１」のメッセージ・シーケンス・チャートとＭＳＣブロック５３２ｂに対応付けられているＭＳＣ名「ＭＳＣ＃３」のメッセージ・シーケンス・チャートにより実現されるシナリオである。

このシナリオ「モード：Ｓｕｓｐｅｎｄ」は、データ取得失敗時には、Ｓｕｓｐｅｎｄモードに切り替わるシナリオである。
各メッセージ・シーケンス・チャートには、ＬＳＩ２０の設計仕様が有する機能へのリンクが設けられている。

すなわち、電力管理仕様のＭＳＣ名「ＭＳＣ＃１」のメッセージ・シーケンス・チャートには、図２２に示すＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートへのリンクが張られている。

また、電力管理仕様のＭＳＣ名「ＭＳＣ＃２」のメッセージ・シーケンス・チャートには、図２２に示すＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートへのリンクが張られている。

また、電力管理仕様のＭＳＣ名「ＭＳＣ＃３」のメッセージ・シーケンス・チャートには、図２２に示すＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートへのリンクが張られている。

また、電力管理仕様が有する各メッセージ・シーケンス・チャートには、事前条件が定義されている。
図３８は、モードテーブルおよび事前条件テーブルの作成例を示す図である。

処理開始前のモードテーブル１３１ａのＭＳＣ名およびモード名の欄は空欄である。
まず、条件付与部１３が、入力された電力管理仕様からモード名「Ｆｕｌｌ」を選択する。

次に、モード名「Ｆｕｌｌ」のＭＳＣ名「ＭＳＣ＃１」を選択する。そして、選択したＭＳＣ名「ＭＳＣ＃１」のメッセージ・シーケンス・チャートに設けられているリンクを辿って、対応するメッセージ・シーケンス・チャートのＭＳＣ名「問い合わせ」を選択する。

次に、条件付与部１３は、選択したＭＳＣ名「問い合わせ」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されているか否かを判断する。
選択したＭＳＣ名「問い合わせ」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されていないので、モードテーブル１３１ａに、選択したＭＳＣ名「問い合わせ」とモード名「Ｆｕｌｌ」を格納する。

次に、条件付与部１３は、選択したモード名「Ｆｕｌｌ」に未選択のＭＳＣが存在するか否かを判断する。
未選択のＭＳＣ名「ＭＳＣ＃２」が存在するため、ＭＳＣ名「ＭＳＣ＃２」を選択する。そして、選択したＭＳＣ名「ＭＳＣ＃２」のメッセージ・シーケンス・チャートに設けられているリンクを辿って、対応するメッセージ・シーケンス・チャートのＭＳＣ名「データ取得成功」を選択する。

次に、条件付与部１３は、選択したＭＳＣ名「データ取得成功」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されているか否かを判断する。
選択したＭＳＣ名「データ取得成功」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されていないので、モードテーブル１３１ａに、選択したＭＳＣ名「データ取得成功」とモード名「Ｆｕｌｌ」を格納する。

次に、条件付与部１３は、選択したモード名「Ｆｕｌｌ」に未選択のＭＳＣが存在するか否かを判断する。
未選択のＭＳＣ名は存在しないため、電力管理仕様に未選択のモード名が存在するか否かを判断する。

電力管理仕様に未選択のモード名「Ｓｕｓｐｅｎｄ」が存在するため、モード名「Ｓｕｓｐｅｎｄ」を選択する。
次に、条件付与部１３は、モード名「Ｓｕｓｐｅｎｄ」のＭＳＣ名「ＭＳＣ＃１」を選択する。そして、選択したＭＳＣ名「ＭＳＣ＃１」のメッセージ・シーケンス・チャートに設けられているリンクを辿って、対応するメッセージ・シーケンス・チャートのＭＳＣ名「問い合わせ」を選択する。

次に、条件付与部１３は、選択したＭＳＣ名「問い合わせ」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されているか否かを判断する。
選択したＭＳＣ名「問い合わせ」が、モードテーブル１３１ａに格納されているため、モードテーブル１３１ａからそのＭＳＣ名「問い合わせ」に関連付けられているモード名「Ｆｕｌｌ」を参照する。

次に、条件付与部１３は、モード名「Ｓｕｓｐｅｎｄ」とモード名「Ｆｕｌｌ」が一致するか否かを判断する。モード名「Ｓｕｓｐｅｎｄ」とモード名「Ｆｕｌｌ」は一致しないため、選択したＭＳＣ名「問い合わせ」とモード名「Ｓｕｓｐｅｎｄ」をモードテーブル１３１ａに格納する。

次に、条件付与部１３は、選択したモード名「Ｓｕｓｐｅｎｄ」に未選択のＭＳＣ名が存在するか否かを判断する。
未選択のＭＳＣ名「ＭＳＣ＃３」が存在するため、ＭＳＣ名「ＭＳＣ＃３」を選択する。そして、選択したＭＳＣ名「ＭＳＣ＃３」のメッセージ・シーケンス・チャートに設けられているリンクを辿って、対応するメッセージ・シーケンス・チャートのＭＳＣ名「データ取得失敗」を選択する。

次に、条件付与部１３は、選択したＭＳＣ名「データ取得失敗」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されているか否かを判断する。
選択したＭＳＣ名「データ取得失敗」に一致するＭＳＣ名が、モードテーブル１３１ａに格納されていないので、モードテーブル１３１ａに、選択したＭＳＣ名「データ取得失敗」とモード名「Ｓｕｓｐｅｎｄ」を格納する。

次に、条件付与部１３は、選択したモード名「Ｓｕｓｐｅｎｄ」に未選択のＭＳＣ名が存在するか否かを判断する。
未選択のＭＳＣ名は存在しないため、電力管理仕様に未選択のモード名が存在するか否かを判断する。

電力管理仕様に未選択のモード名が存在しないため、処理を終了する。
これにより、図３８に示すモードテーブル１３１ａが完成する。
次に、条件付与部１３は、事前条件テーブル作成処理を行う。

処理開始前の事前条件テーブル１３１ｂのＭＳＣ名および事前条件の欄は空欄である。
まず、条件付与部１３は、モードテーブル１３１ａからＭＳＣ名「問い合わせ」を選択する。

次に、条件付与部１３は、選択したＭＳＣ名「問い合わせ」と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在するか否かを判断する。
ＭＳＣ名「問い合わせ」と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在するので、選択したＭＳＣ名「問い合わせ」を事前条件テーブル１３１ｂのＭＳＣ名の欄に格納する。そして、各レコードのモード名「Ｆｕｌｌ」、「Ｓｕｓｐｅｎｄ」を「ｏｒ」で接続して事前条件テーブル１３１ｂの事前条件の欄に格納する。

次に、条件付与部１３は、事前条件テーブル１３１ｂに格納した事前条件「Ｆｕｌｌ ｏｒ Ｓｕｓｐｅｎｄ＝ｔｒｕｅ」をＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５の事前条件として設定する。これにより、電力管理仕様のメッセージ・シーケンス・チャートの事前条件が、検証用シナリオのメッセージ・シーケンス・チャートに反映される。

次に、条件付与部１３は、モードテーブル１３１ａに未選択のＭＳＣ名が存在するか否かを判断する。
未選択のＭＳＣ名「データ取得成功」が存在するため、ＭＳＣ名「データ取得成功」を選択する。

次に、条件付与部１３は、選択したＭＳＣ名「データ取得成功」と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在するか否かを判断する。
ＭＳＣ名「データ取得成功」と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在しないので、選択したＭＳＣ名「データ取得成功」を事前条件テーブル１３１ｂのＭＳＣ名の欄に格納する。そして、ＭＳＣ名「データ取得成功」のモード名「Ｆｕｌｌ」を事前条件テーブル１３１ｂの事前条件の欄に格納する。

次に、条件付与部１３は、事前条件テーブル１３１ｂに格納した事前条件「Ｆｕｌｌ＝ｔｒｕｅ」をＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャート３６の事前条件として設定する。

なお、条件付与部１３は、ｔｒｕｅでないＳｕｓｐｅｎｄモードをｆａｌｓｅとする事前条件も同時に設定する。
次に、条件付与部１３は、モードテーブル１３１ａに未選択のＭＳＣ名が存在するか否かを判断する。

未選択のＭＳＣ名「データ取得失敗」が存在するため、ＭＳＣ名「データ取得失敗」を選択する。
次に、条件付与部１３は、選択したＭＳＣ名「データ取得失敗」と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在するか否かを判断する。

ＭＳＣ名「データ取得失敗」と同じＭＳＣ名を有するレコードがモードテーブル１３１ａ内に存在しないので、選択したＭＳＣ名「データ取得失敗」を事前条件テーブル１３１ｂのＭＳＣ名の欄に格納する。そして、ＭＳＣ名「データ取得失敗」のモード名「Ｓｕｓｐｅｎｄ」を事前条件テーブル１３１ｂの事前条件の欄に格納する。

次に、条件付与部１３は、事前条件テーブル１３１ｂに格納した事前条件「Ｓｕｓｐｅｎｄ」をＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャート３７の事前条件として設定する。

なお、条件付与部１３は、ｔｒｕｅでないＦｕｌｌモードをｆａｌｓｅとする事前条件も同時に設定する。
次に、条件付与部１３は、モードテーブル１３１ａに未選択のＭＳＣ名が存在するか否かを判断する。

モードテーブル１３１ａに未選択のＭＳＣ名が存在しないため、処理を終了する。
これにより、図３８に示す事前条件テーブル１３１ｂが完成する。
図３９は、電力管理検証用シナリオの有向グラフを示す図である。

有向グラフ３０ａは、初期状態ブロック３１ａと、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５と、ＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャート３６と、ＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャート３７とを有している。

図３９では、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５の処理後、Ｖ＝ｔｒｕｅ、かつ、Ｆｕｌｌ＝ｔｒｕｅ ｏｒ Ｓｕｓｐｅｎｄ＝ｆａｌｓｅの制約条件が成立すれば、メッセージ・シーケンス・チャート３６に遷移する事前条件が設定されている。一方、Ｖ＝ｆａｌｓｅ、かつ、Ｆｕｌｌ＝ｆａｌｓｅ ｏｒ Ｓｕｓｐｅｎｄ＝ｔｒｕｅの制約条件が成立すれば、メッセージ・シーケンス・チャート３７に遷移する事前条件が設定されている。

このような事前条件が、検証用シナリオＳｃ１、Ｓｃ２にそれぞれ設定されることにより、電力管理検証用シナリオが作成される。
図４０および図４１は、電力管理検証用シナリオのデータ構造を示す図である。

図４０は、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５の処理後、メッセージ・シーケンス・チャート３６に遷移する電力管理検証用シナリオＰＳｃ１のデータ構造を示している。

３行目には、＜fsm name=“グラフィックス演算開始ＦＳＭ” type=“scenario”＞と記述されている。この「type=“scenario”」が検証用シナリオであることを示している。

また、下から４行目には、制約条件が記述されている。具体的には、ステートＳｔ２からステートＳｔ３に遷移するときの制約条件＜transition from="St2" to="St3" guardexpr="V == true & Full = true‖ Suspend = false" /＞が記述されている。

図４１は、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャート３５の処理後、メッセージ・シーケンス・チャート３７に遷移する電力管理検証用シナリオＰＳｃ２のデータ構造を示している。

３行目には、＜fsm name=“グラフィックス演算開始ＦＳＭ” type=“scenario”＞と記述されている。この「type=“scenario”」が検証用シナリオであることを示している。

また、下から４行目には、制約条件が記述されている。具体的には、ステートＳｔ２からステートＳｔ５に遷移するときの制約条件＜transition from="St2" to="St5" guardexpr="V == false & Full = false‖ Suspend = true" /＞が記述されている。

図４２は、シナリオリストを示す図である。
シナリオリスト１５ａには、モード名、電力管理検証用シナリオ名の欄が設けられている。横方向に並べられた情報同士が互いに関連づけられている。

モード名の欄には、電力管理仕様に設定されているモード名が設定されている。図４２では、モード名「Ｆｕｌｌ」、「Ｓｕｓｐｅｎｄ」が設定されている。
電力管理検証用シナリオ名の欄には、モード名の欄のモードを検証する電力管理検証用シナリオのシナリオ名が設定されている。図４２では、Ｆｕｌｌモードを検証する電力管理検証用シナリオＰＳｃ１のシナリオ名「ＰＳｃ＃１」が設定されている。また、Ｓｕｓｐｅｎｄモードを検証する電力管理検証用シナリオＰＳｃ２のシナリオ名「ＰＳｃ＃２」が設定されている。

以上説明したように、設計検証装置１０によれば、生成した検証用シナリオに対して電力管理仕様から制約を加える、すなわち、ＬＳＩ２０の機能設計仕様にモード毎の制約条件を付与することで、電力管理検証用シナリオを生成するようにした。

ユーザは、モード毎の電力管理検証用シナリオを検証することで、電力制御のための制御信号が正しく行われているかの網羅的な検証を行うことができるため、検証漏れや重複検証を抑制することができる。具体的には、シナリオに対し、制約条件を与えているので、その制約条件を満たさないシナリオは電力管理検証用シナリオから除外される。一方、制約条件を満たす組み合わせについては全て出力されるので漏れがない。例えば、前述した具体例では、Ｓｕｓｐｅｎｄモード移行後は、グラフィックスアクセラレータ４２ａを使用しないので、グラフィックスアクセラレータ４２ａを使用する検証用シナリオ「データ取得成功」は、検証の対象外とすることができる。従って、前述した具体例では、Ｆｕｌｌモードを検証するときは、シナリオ名「ＰＳｃ＃１」の電力管理検証用シナリオのみを実行するだけでよい。一方、Ｓｕｓｐｅｎｄモードを検証するときは、シナリオ名「ＰＳｃ＃２」の電力管理検証用シナリオのみを実行するだけでよい。

なお、電力管理検証用シナリオは、設計の各フェーズにて電力管理検証用に用いることができる。例えば、ＬＳＩ２０の設計仕様からＲＴＬを生成し、生成したＲＴＬを解析、変更するときに電力管理検証用シナリオを用いることができる。また、変更後のＲＴＬに基づいてネットリストを合成し、合成したネットリストを解析、変更するときに電力管理検証用シナリオを用いることができる。

なお、本実施の形態では、シナリオリスト１５ａには、全てのモード名と、そのモード名に対応する電力管理検証用シナリオを表示するようにした。しかし、これに限らず、例えば、ユーザが、予め検証対象のモードを入力しておき、設計検証装置１０が、入力されたモードと、そのモードに対応する電力管理検証用シナリオをリスト化して出力するようにしてもよい。

なお、本実施の形態では、事前条件テーブル１３１ｂを作成し、メッセージ・シーケンス・チャートに事前条件を付与した。しかし、これに限らず、事後条件テーブル、不変条件テーブルを設定し、メッセージ・シーケンス・チャートに事後条件、不変条件を付与するようにしてもよい。

なお、本実施の形態では、モードテーブル１３１ａと事前条件テーブル１３１ｂを作成し、事前条件を付与するようにした。しかし、これに限らず、例えば、１つのハッシュテーブルを使って事前条件を付与するようにしてもよい。この場合、値を格納する際に条件をマージして登録するようにすればよい。

また、検証用シナリオを生成する際、以下の処理を行った。
検証用シナリオ生成部１１が、ＬＳＩ２０の設計仕様が備える複数のシナリオが備えるメッセージ・シーケンス・チャートそれぞれにラベルを関連付けた検証用シナリオを生成するようにした。これにより、１つのシナリオが備えるメッセージ・シーケンス・チャートを特定することができる。

そして、メッセージ・シーケンス・チャートから有限ステートマシンの生成を行った。但し、有限ステートマシンを生成する際、各ステートに対応するメッセージ・シーケンス・チャートのラベルを付与するようにした。これにより、１つのシナリオが備えるステートを特定することができる。

そして、ＬＳＩ２０の設計仕様の各シナリオに対応する有限ステートマシンを抽出し、抽出した各有限ステートマシンの検証用シナリオを生成するようにした。
これにより、入力されるパターンの入力に対応する（設計・検証の段階に応じた）検証用シナリオを生成することができる。

なお、本実施の形態では、電力管理仕様にクロックゲーティングを用いたが、これに限らず、電力管理仕様にパワーゲーティングや、電圧の変更等の他の条件を設定することができる。また、クロックゲーティングに加えてパワーゲーティングや、電圧の変更等の他の条件を追加することができる。

例えば、パワーゲーティングの条件を追加する場合、電力供給を停止するか否かを制御する制約条件を、メッセージ・シーケンス・チャートに加える。これにより、パワーゲーティングの制御を含めたシナリオを生成することができる。

電圧の条件を追加する場合、例えば、動作を保証する電圧等を規定し、規定電圧以下の場合、当該メッセージ・シーケンス・チャートに遷移しないという制約条件を、メッセージ・シーケンス・チャートに加える。これにより、条件を満たすシナリオだけを検証できるシナリオを生成することができる。

周波数の条件を追加する場合、例えば、必要な周波数を設計仕様によって決定する高速な動作が求められている場合に、周波数を上げたり、設定電圧に対応する周波数に設定したりするという制約条件を、メッセージ・シーケンス・チャートに加える。これにより、要求される周波数を満たすシナリオだけを検証できるシナリオを生成することができる。

さらに、別の電力管理仕様への制御信号の条件を追加する場合、電源ＩＣ（Integrated Circuit）等で規定されている電力制御バスへの信号を制御する条件をメッセージ・シーケンス・チャートに加える。これにより、ＬＳＩ２０の内部または外部の電源ＩＣの制御も含めたシナリオを生成することができる。

以下、電力管理仕様にパワーゲーティングの条件を追加した場合を説明する。
図４３は、電力管理仕様にパワーゲーティングの条件を追加した場合を説明する図である。

図４３に示す電力管理仕様は、シナリオ「モード：Ｆｕｌｌ」を実現するＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートが有する制約条件として「Ｃｌｏｃｋ Ｇａｔｉｎｇ＝ＯＦＦ」に加え、「Ｐｏｗｅｒ Ｇａｔｉｎｇ＝ＯＦＦ」が設定されている。

また、シナリオ「モード：Ｓｕｓｐｅｎｄ」を実現するＭＳＣ名「データ取得失敗」のメッセージ・シーケンス・チャートが有する制約条件として「Ｐｏｗｅｒ Ｇａｔｉｎｇ＝ＯＮ」が設定されている。

従って、Ｓｕｓｐｅｎｄモードに移行する際には、パワーゲーティングがＯＮすることにより、ＬＳＩ２０が有するグラフィックスアクセラレータ４２ａおよびメモリコントローラ４３ａへの電力の供給を停止する。図４３中点線で囲まれた部分が電力の供給が停止される範囲である。

この仕様を用いて検証用シナリオに事前条件を付与することにより、Ｓｕｓｐｅｎｄモード移行時は、グラフィックスアクセラレータ４２ａおよびメモリコントローラ４３ａに関するシナリオを全て除外した電力管理検証用シナリオを作成することができる。

次に、電力管理仕様に電圧の条件を追加した場合をＬＳＩ２０がデコーダ回路を有する場合を例にとって説明する。
図４４は、デコーダ回路の機能を示すブロック図である。

デコーダ回路１２０は、バッファ１２１と、ＶＬＤ（Variable Length Decoding）処理部１２２、１２３と、逆量子化処理部１２４と、ＩＤＣＴ（Inverse Discrete Cosine Transform）処理部１２５と、メモリ１２６と、ＭＣ（Motion Compensation）処理部１２７とを有している。

バッファ１２１は、入力されるビットストリームを一時保持する。
ＶＬＤ処理部１２２、１２３は、それぞれ、バッファ１２１に一時保持されたビットストリームを基本処理単位であるマクロブロックに分割する。そして各ブロックに対し離散コサイン変換（ＤＣＴ）を施してから量子化する。そして、量子化されたＤＣＴ係数と量子化幅を可変長符号化する。

逆量子化処理部１２４は、量子化されたＤＣＴ係数を逆量子化する。
ＩＤＣＴ処理部１２５は、逆離散コサイン変換を行い、予測誤差信号を再生する。
メモリ１２６は、再生された予測誤差信号を一時記憶する。

ＭＣ処理部１２７は、メモリ１２６に記憶された予測誤差信号と、検出された動きベクトルに基づき、データを圧縮、伸長する。
ところで、電力管理仕様に設定するメッセージ・シーケンス・チャートの電圧条件として、オブジェクト自体（デコーダ回路１２０全体）の電圧の条件を設定するようにしてもよいし、オブジェクトが有する個々の機能の電圧の条件を設定するようにしてもよい。

例えば、デコーダ回路１２０という単位でオブジェクトが設定されている場合には、図４４に示す各機能ブロックにより示されるデコーダ回路１２０（１つの大きな機能ブロック）がメッセージ・シーケンス・チャートのオブジェクトに対応する。以下、電力管理仕様に設定するメッセージ・シーケンス・チャートの電圧条件として、デコーダ回路１２０全体の電圧の条件を設定する例を図４５に示す。また、オブジェクトが有する個々の機能の電圧の条件を設定する例を図４６、図４７に示す。

図４５は、メッセージ・シーケンス・チャートの電圧条件として、デコーダ回路全体の電圧の条件を設定する例を示す図である。
図４５に示すオブジェクトは、ＬＳＩ２０が有するオブジェクトを示している。

このオブジェクトは、ＣＰＵ４１ａ、デコーダ回路１２０、メモリコントローラ４３ａおよびメモリ４７ａによって表される。
メッセージ・シーケンス・チャート４０ｅに現れるデコーダ回路１２０は、デコーダ回路１２０が有する複数の機能をひとつにまとめたオブジェクトである。

このメッセージ・シーケンス・チャート４０ｅは、ＭＳＣ名「問い合わせ」のメッセージ・シーケンス・チャートと、ＭＳＣ名「データ取得成功」のメッセージ・シーケンス・チャートを有している。

このメッセージ・シーケンス・チャート４０ｅは、以下の処理を行う。
まず、ＣＰＵ４１ａは、演算開始をデコーダ回路１２０に送信する（ステップＳ８１）。

演算開始の受信後、デコーダ回路１２０は、データリード要求をメモリコントローラ４３ａに送信する（ステップＳ８２）。
データリード要求の受信後、メモリコントローラ４３ａは、データリード要求をメモリ４７ａに送信する（ステップＳ８３）。

データリード要求の受信後、メモリ４７ａは、データリード要求に対するデータをメモリコントローラ４３ａに転送する（ステップＳ８４）。
データの受信後、メモリコントローラ４３ａは、受信したデータをデコーダ回路１２０に転送する（ステップＳ８５）。

データの受信後、デコーダ回路１２０は、受信したデータを用いて演算を行う。そして、演算の終了後、デコーダ回路１２０は、データライト要求をメモリコントローラ４３ａに送信する（ステップＳ８６）。

データライト要求の受信後、メモリコントローラ４３ａは、データライト要求をメモリ４７ａに送信する（ステップＳ８７）。
データライト要求の受信後、メモリ４７ａは、データライト要求に対するデータをメモリコントローラ４３ａに転送する（ステップＳ８８）。

データの受信後、メモリコントローラ４３ａは、受信したデータをデコーダ回路１２０に転送する（ステップＳ８９）。
デコーダ回路１２０は、演算終了通知をＣＰＵ４１ａに送信する（ステップＳ９０）。

図４６は、デコーダ回路が有する各機能の配置位置の一例を示す図である。
図４６の各領域が、デコーダ回路１２０が有する各機能の配置位置を示している。各領域の機能は、異なるモードが選択されているときは、異なる電圧で駆動させることができる。

図４７は、電力管理仕様に電圧の条件を追加した場合を説明する図である。
図４７は、デコーダ回路１２０の機能を実現するＭＳＣが複数の下位ｈＭＳＣを有しており、下位のｈＭＳＣの制約条件として電圧が設定されている状況の例を示している。

図４７に示す機能ブロック５４に対応付けられた電力管理仕様は、シナリオブロック５４ａに対応付けられているシナリオ「モード：Ｆｕｌｌ」とシナリオブロック５４ｂに対応付けられているシナリオ「モード：Ｓｕｓｐｅｎｄ」とを有している。

シナリオ「モード：Ｆｕｌｌ」は、ＭＳＣブロック５４１ａに対応付けられているＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャート等により実現されるシナリオである。

シナリオ「モード：Ｓｕｓｐｅｎｄ」は、ＭＳＣブロック５４１ｂに対応付けられているＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャート等により実現されるシナリオである。

図４７に示す電力管理仕様は、シナリオ「モード：Ｆｕｌｌ」を実現するＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートが有する制約条件として「Ｖｏｌｔａｇｅ＿ａｌｌ＝１．３Ｖ」、「Ｖｏｌｔａｇｅ＿ｂｕｆｆｅｒ＝１．１Ｖ」、「Ｖｏｌｔａｇｅ＿ＶＬＤ＝１．２Ｖ」、「Ｖｏｌｔａｇｅ＿逆量子化＝１．３Ｖ」、「Ｖｏｌｔａｇｅ＿ＩＤＣＴ＝１．３Ｖ」、「Ｖｏｌｔａｇｅ＿ＭＣ＝１．２Ｖ」が設定されている。

ここで、「Ｖｏｌｔａｇｅ＿ａｌｌ＝１．３Ｖ」は、Ｆｕｌｌモード時に各機能を動作させるときの電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ｂｕｆｆｅｒ＝１．１Ｖ」は、Ｆｕｌｌモード時にバッファ１２１を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ＶＬＤ＝１．２Ｖ」は、Ｆｕｌｌモード時にＶＬＤ処理部１２２、１２３を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿逆量子化＝１．３Ｖ」は、Ｆｕｌｌモード時に逆量子化処理部１２４を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ＩＤＣＴ＝１．３Ｖ」は、Ｆｕｌｌモード時にＩＤＣＴ処理部１２５を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ＭＣ＝１．２Ｖ」は、Ｆｕｌｌモード時にＭＣ処理部１２７を駆動するための電圧を示す制約条件である。

また、シナリオ「モード：Ｓｕｓｐｅｎｄ」を実現するＭＳＣ名「ＭＳＣ＃ａ」のメッセージ・シーケンス・チャートが有する制約条件として「Ｖｏｌｔａｇｅ＿ａｌｌ＝１．１Ｖ」、「Ｖｏｌｔａｇｅ＿ｂｕｆｆｅｒ＝１．１Ｖ」、「Ｖｏｌｔａｇｅ＿ＶＬＤ＝１．１Ｖ」、「Ｖｏｌｔａｇｅ＿逆量子化＝１．１Ｖ」、「Ｖｏｌｔａｇｅ＿ＩＤＣＴ＝１．１Ｖ」、「Ｖｏｌｔａｇｅ＿ＭＣ＝１．１Ｖ」が設定されている。

ここで、「Ｖｏｌｔａｇｅ＿ａｌｌ＝１．１Ｖ」は、Ｓｕｓｐｅｎｄモード時に各機能を動作させるときの電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ｂｕｆｆｅｒ＝１．１Ｖ」は、Ｓｕｓｐｅｎｄモード時にバッファ１２１を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ＶＬＤ＝１．１Ｖ」は、Ｓｕｓｐｅｎｄモード時にＶＬＤ処理部１２２、１２３を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿逆量子化＝１．１Ｖ」は、Ｓｕｓｐｅｎｄモード時に逆量子化処理部１２４を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ＩＤＣＴ＝１．１Ｖ」は、Ｓｕｓｐｅｎｄモード時にＩＤＣＴ処理部１２５を駆動するための電圧を示す制約条件である。「Ｖｏｌｔａｇｅ＿ＭＣ＝１．１Ｖ」は、Ｓｕｓｐｅｎｄモード時にＭＣ処理部１２７を駆動するための電圧を示す制約条件である。

この仕様を用いて検証用シナリオに制約条件を付与することにより、Ｆｕｌｌモード移行時は、制約条件として設定された電圧を印加するときの処理を示すメッセージ・シーケンス・チャート以外のメッセージ・シーケンス・チャートを有するシナリオを全て除外した電力管理検証用シナリオを得ることができる。すなわち、例えば、制約条件「Ｖｏｌｔａｇｅ＿ａｌｌ＝１．３Ｖ」を有するメッセージ・シーケンス・チャートを備えるシナリオが他に存在したとしても、そのシナリオの制約条件が、「Ｖｏｌｔａｇｅ＿ｂｕｆｆｅｒ＝１．１Ｖ」以外であれば、そのシナリオは、電力管理検証用シナリオから除外される。

同様に、サスペンドモード移行時は、デコーダ回路１２０の各機能に、１．１Ｖ以外の電圧を印加するときの処理を示すメッセージ・シーケンス・チャートを有するシナリオを全て除外した電力管理検証用シナリオを得ることができる。

なお、本実施の形態では、制約条件を付与する仕様として電力管理仕様を用いたが、これに限らず、例えば、性能（動作速度）を管理する仕様や、乗り心地を管理する仕様等の種々の検証対象の仕様を用いることができる。

また、本実施の形態では、２つの仕様（機能仕様、電力管理仕様）を用いる場合について説明したが、これに限らず、３つ以上の仕様を用いて検証用シナリオを生成する場合についても適用することができる。

なお、設計検証装置１０が行った処理が、複数の装置によって分散処理されるようにしてもよい。
例えば、１つの装置が、検証用シナリオ生成処理を行って検証用シナリオを生成しておき、他の装置が、その検証用シナリオを用いて電力管理検証用シナリオを生成する処理を行うようにしてもよい。

以上、本発明の設計検証装置および設計検証プログラムを、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。

また、本発明は、前述した各実施の形態のうちの、任意の２以上の構成（特徴）を組み合わせたものであってもよい。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、設計検証装置１０が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

設計検証プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

以上の第１〜第２の実施の形態に関し、さらに以下の付記を開示する。
（付記１） 設計対象の第１の設計仕様を検証する検証用情報が有する制約条件に、前記設計対象の第２の設計仕様の検証項目毎の処理手順が備える処理単位に設けられた、前記第１の設計仕様が備える処理単位に対するリンクに基づいて、前記第２の設計仕様の制約条件を付与する制約条件付与部と、
前記制約条件付与部によって前記制約条件が付与された前記検証用情報を識別する情報を、対応する前記検証項目とともに出力する出力部と、
を有することを特徴とする設計検証装置。

（付記２） 前記第２の設計仕様は、複数の処理手順を有し、
前記制約条件付与部は、前記第１の設計仕様が有する前記処理単位に対し、共通のリンクが設けられた前記処理単位を有する前記処理手順に遷移する条件を、前記第２の設計仕様の制約条件とすることを特徴とする付記１記載の設計検証装置。

（付記３） 前記第１の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けて前記検証用情報を生成する生成部をさらに有することを特徴とする付記１記載の設計検証装置。

（付記４） 前記生成部は、同じ前記識別情報を備える前記処理単位を抽出し、抽出した前記処理単位の集合をそれぞれ前記検証用情報とすることを特徴とする付記３記載の設計検証装置。

（付記５） 前記処理単位は、オブジェクト間で送受信される信号の関係を示すシーケンスを備えており、前記生成部は、前記シーケンスそれぞれに、前記識別情報を関連付けることを特徴とする付記３記載の設計検証装置。

（付記６） 前記生成部は、前記シーケンスに対応したステートマシンを生成し、生成した前記ステートマシンのステートそれぞれに当該ステートマシンの元となる前記シーケンスが備える前記識別情報を付与することを特徴とする付記５記載の設計検証装置。

（付記７） 前記識別情報は、前記検証対象部位を示す機能、前記処理手順、前記シーケンスのうちの少なくとも１つの情報を有しており、
前記生成部は、同じ前記識別情報を備える前記ステートマシンを抽出し、抽出した前記ステートマシンの部分を前記検証用情報とすることを特徴とする付記６記載の設計検証装置。

（付記８） 前記シーケンスの制約に基づいて、前記シーケンスそれぞれの処理に対応したステートの数を減らすことを特徴とする付記６記載の設計検証装置。
（付記９） コンピュータに、
設計対象の第１の設計仕様を検証する検証用情報が有する制約条件に、前記設計対象の第２の設計仕様の検証項目毎の処理手順が備える処理単位に設けられた、前記第１の設計仕様が備える処理単位に対するリンクに基づいて、前記第２の設計仕様の制約条件を付与する制約条件付与手順、
前記制約条件付与手順によって前記制約条件が付与された前記検証用情報を識別する情報を、対応する前記検証項目とともに出力する出力手順、
を実行させることを特徴とする設計検証プログラム。

１、１０ 設計検証装置
１ａ 生成部
１ｂ 格納部
１ｃ 制約条件付与部
１５ 出力部
２ 第１の設計仕様
２ａ 機能
３ 構造体
３ａ、３１、３１ａ 初期状態ブロック
３ｂ、３ｃ、３ｄ 検証用情報
４ 第２の設計仕様
５ 出力結果
１１ 検証用シナリオ生成部
１２ 検証用シナリオ格納部
１３ 条件付与部
１４ 電力管理検証用シナリオ格納部
１５ａ シナリオリスト
１６ 優先度ルール格納部
１７ パラメータ格納部
１８ 検証順位決定部
２０ ＬＳＩ
２０ａ〜２０ｆ 処理手順
２１、５１、５２、５３ 機能ブロック
２１ａ、２１ｂ、５１ａ〜５１ｃ、５２ａ、５２ｂ、５３ａ、５３ｂ シナリオブロック
３０、３０ａ 有向グラフ
３２〜３７、４０、４０ａ〜４０ｅ、７０ メッセージ・シーケンス・チャート（ＭＳＣ）
３４ ｈメッセージ・シーケンス・チャート（ｈＭＳＣ）
４１、４２、４３ ハードウェア（ＨＷ）
４１ａ ＣＰＵ
４２ａ グラフィックスアクセラレータ
４３ａ メモリコントローラ
４４、４５、４６ オブジェクトライン
４４ａ ＣＰＵライン
４５ａ グラフィックスアクセラレータライン
４６ａ メモリコントローラライン
４７ａ、１２６ メモリ
４７、４８ ボックス
６１〜６３、６１ａ〜６３ａ、１１０ａ、１１１〜１１７、１２０ａ 記述
６０、１１０ データ
７１ 送信オブジェクト
７２ 長距離送信オブジェクト
７３ 受信オブジェクト
７４ 長距離受信オブジェクト
８０ 状態マトリックス
８１、８２ 領域
９０、９２ 状態図
９０ａ 有限ステートマシン
９１、Ｓｔ１〜Ｓｔ８ ステート
１００ システム
１２０ デコーダ回路
１２１ バッファ
１２２、１２３ ＶＬＤ処理部
１２４ 逆量子化処理部
１２５ ＩＤＣＴ処理部
１２７ ＭＣ処理部
１３１ａ モードテーブル
１３１ｂ 事前条件テーブル
２００ 信号インタフェース
２１１ａ、２１２ａ、５１１ａ〜５１１ｃ、５１２ａ〜５１２ｃ、５１３ａ、５１３ｂ ５２１ａ、５２１ｂ、５２２ａ、５２２ｂ、５３１ａ、５３１ｂ、５３２ａ、５３２ｂ ＭＳＣブロック
３００ テスト対象装置
４００ ネットワーク
５２１ａ１、５２２ａ１、５２２ｂ１ ラベル
Ｓｃ１、Ｓｃ２ 検証用シナリオ
ｅ１、ｅ２、ｅ３ イベント
ｍ、ｍ１〜ｍ９ データ・イベント・メッセージ
ＰＳｃ１、ＰＳｃ２ 電力管理検証用シナリオ
ｒ１〜ｒ６、ｒｊ 受信イベント
ｔ１〜ｔ５、ｔｉ 送信イベント

Claims (8)

1. コンピュータに、
   設計対象の第１の設計仕様を検証する検証用情報が有する制約条件に、前記設計対象の第２の設計仕様の検証項目毎の処理手順が備える処理単位に設けられた、前記第１の設計仕様が備える処理単位に対するリンクに基づいて、前記第２の設計仕様の制約条件を付与する制約条件付与手順、
   前記制約条件付与手順によって前記制約条件が付与された前記検証用情報を識別する情報を、対応する前記検証項目とともに出力する出力手順、
   を実行させることを特徴とする設計検証プログラム。
2. 前記第２の設計仕様は、複数の処理手順を有し、
   前記制約条件付与手順では、前記第１の設計仕様が有する前記処理単位に対し、共通のリンクが設けられた前記処理単位を有する前記処理手順に遷移する条件を、前記第２の設計仕様の制約条件とすることを特徴とする請求項１記載の設計検証プログラム。
3. 前記第１の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記第１の設計仕様の検証対象部位を識別する識別情報を関連付けて前記検証用情報を生成する生成手順をさらに実行させることを特徴とする請求項１記載の設計検証プログラム。
4. 前記生成手順では、同じ前記識別情報を備える前記処理単位を抽出し、抽出した前記処理単位の集合をそれぞれ前記検証用情報とすることを特徴とする請求項３記載の設計検証プログラム。
5. 前記処理単位は、オブジェクト間で送受信される信号の関係を示すシーケンスを備えており、前記生成手順では、前記シーケンスそれぞれに、前記識別情報を関連付けることを特徴とする請求項３記載の設計検証プログラム。
6. 前記生成手順では、前記シーケンスに対応したステートマシンを生成し、生成した前記ステートマシンのステートそれぞれに当該ステートマシンの元となる前記シーケンスが備える前記識別情報を付与することを特徴とする請求項５記載の設計検証プログラム。
7. 前記識別情報は、前記検証対象部位を示す機能、前記処理手順、前記シーケンスのうちの少なくとも１つの情報を有しており、
   前記生成手順では、同じ前記識別情報を備える前記ステートマシンを抽出し、抽出した前記ステートマシンの部分を前記検証用情報とすることを特徴とする請求項６記載の設計検証プログラム。
8. 設計対象の第１の設計仕様を検証する検証用情報が有する制約条件に、前記設計対象の第２の設計仕様の検証項目毎の処理手順が備える処理単位に設けられた、前記第１の設計仕様が備える処理単位に対するリンクに基づいて、前記第２の設計仕様の制約条件を付与する制約条件付与部と、
   前記制約条件付与部によって前記制約条件が付与された前記検証用情報を識別する情報を、対応する前記検証項目とともに出力する出力部と、
   を有することを特徴とする設計検証装置。

Images