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

Description

この発明は、システムのハードウェア設計の検証を支援するための検証支援プログラム、検証支援装置および検証支援方法に関する。

従来より、半導体集積回路による新たなシステムを設計すると、実機の製造に移行する前段に、設計したシステムに所望の動作をさせた場合のシステム全体の消費電力や処理性能（所望の動作が完了するまでの処理時間）を見積もる検証工程が必要となる。検証工程では、設計者によって、設計内容が適切であるかが判断される。また、設計者が検証結果を参照し必要に応じて設計内容を修正することにより、消費電力の低減や処理性能の向上が可能となり、利用者にニーズに即したより高品質なシステムを提供することができる。

検証工程において、システム全体の消費電力ならびに処理性能を見積もるための技術としては、一般的に検証対象となるシステムをソフトウェアによって実現したシステムモデルを用いた検証対象システムの動作シミュレーションが広く知られている。

ここで、図１８は、検証対象システムの構成例を示す説明図である。検証対象システム１０の動作をシミュレーションする場合、検証対象システム１０のシステムモデルを用意する必要がある。システムモデルには、検証システム１０内の各ハードウェア（たとえばＣＰＵ、メモリ、モジュールＡ）同士の接続状態と、各ハードウェアの実装情報とが含まれている。そして、検証対象システム１０のシミュレーション実行した際の消費電力や処理性能が検証対象システム１０の見積もり値として提供される。

また、各ハードウェアの実装情報として、従来は、ＲＴＬ（Ｒｅｇｉｓｔｅｒ Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）記述レベルもしくはそれ以上の詳細度が要求されていた。しかしながら、近年では、ＲＴＬよりも詳細度の低いＴＬ（Ｔｒａｎｓｆｅｒ Ｌｅｖｅｌ）記述レベルの実装情報によるシミュレーションも可能になっている。さらに、ＲＴＬ記述とＴＬ記述とが混在した実装情報であってもＣｏ−ＳＩＭ（協働シミュレーション）によるシミュレーションが可能になっている。

したがって、検証対象システムのシミュレーションを実行するには、各ハードウェアの実装情報を用意すればよい。ハードウェアの中でも、汎用性の高いＣＰＵやメモリなどは、設計の機会が多いことや、他のシステム用に設計された実装情報を流用できる場合もあり、比較的容易に実装情報を用意できる。

一方、検証対象システム１０のモジュールＡのような、新たに設計されたり、専門性の高い処理を目的としたハードウェアは、ＣＰＵやメモリと比べて実装情報を用意するために多くの時間を要する傾向にある。システム全体のシミュレーションを実行する際には、下記のようなシミュレーション用のシナリオが提供される。

＜シナリオ例＞
ＣＰＵ（モジュールＡへのライトトランザクション）
・ＷｒｉｔｅＡｄｄｒｅｓｓ（ａｄｄｒｅｓｓ）／／モジュールＡへのライト要求
・ＷｒｉｔｅＤａｔａ（ａ）／／ライトデータａ送信
・ＷａｉｔＡｃｋ／／モジュールＡからの応答待ち
・ …（以下略）
モジュールＡ（ＣＰＵからのライト要求を受信）
・ＧｅｔＡｄｄｒｅｓｓ（ａｄｄｅｒｓｓ）／／アドレス要求待ち
・ …（以下略）

上記のシナリオ例のように、ＣＰＵがシナリオに応じた適切な動作をおこなうにはモジュールＡからの応答を受け付けなければならない。すなわち、システム全体のシミュレーションには、モジュールＡを含め検証対象システム１０内のすべてのハードウェアの実装が不可欠である。したがって、いずれかのハードウェアの実装情報の開発が遅れると、遅れている開発工程が、システム全体のシミュレーションを実行する際のボトルネックとなってしまっていた。

さらに、システムの設計の現場では、各ハードウェアの実装情報が用意された後に、急遽通信プロトコルなどの各種仕様が変更されるような事態も発生する。図１９は、検証対象システムのプロトコル変更に伴う問題を示す説明図である。図１９の左側には、ＡＨＢ（Ａｄｖａｎｃｅｄ Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｂｕｓ）仕様に基づいて設計された検証対象システム（従来システム）１０を表している。そして図１９の右側には、通信プロトコルがＡＸＩ（Ａｄｖａｎｃｅｄ ｅＸｔｅｎｓｉｂｌｅ Ｉｎｔｅｒｆａｃｅ）仕様に変更された更新システム２０を表している。なお、更新システム２０では、モジュールＡ以外の、ＣＰＵやメモリなど汎用性の高いハードウェアについては、ＡＸＩ仕様が適合された実装情報が用意されているものとする。

また、各システムの下には、ＣＰＵからモジュールＡへアクセスした際の、モジュールＡの動作を示している。更新システム２０の場合、モジュールＡは、ＡＸＩ仕様に基づいて、ＣＰＵからのアクセス信号（ＷｒｉｔｅＡｄｄｒｅｓｓ）に応じて新たに応答２１（Ｒｅｓｐｏｎｓｅ１）を出力しなければならない。実際には、モジュールＡはＡＸＩ仕様に変更されていないため、応答２１を出力できず、更新システム２０でのシミュレーションは破綻をきたしてしまう。

現状では、モジュールの実装情報が間に合わない、仕様変更に伴うシミュレーションの不都合が解消するといった問題に対して、いくつかの対応策が提供されている。たとえば、検証対象システム１０の中の一部のハードウェアの実装情報が間に合わない場合には、モジュールＡの代わりに実装情報を含まない空のスードモデルを接続して、いち早くシステム全体のシミュレーションを実行するための技術がある。

また、図１９のように仕様が変更になった場合には、モジュールＡの通信プロトコルを変換するためのブリッジを用意する技術が知られている。図２０は、ブリッジ挿入によるプロトコル変換例を示す説明図である。図２０のように、ＡＸＩ仕様のバスと、モジュールＡとの間に、ブリッジを接続することによって、ＡＸＩ仕様のモジュールＡを用意せずとも更新システム２０全体のシミュレーションが可能となる。

特表２００５−５２５６６０号公報

しかしながら、上述した従来技術のうち、モジュールＡに代わってスードモデルを接続する技術の場合、モデル内に実装情報が含まれていないために、シミュレーションの実行結果にはモジュールＡについての評価が反映されない。すなわち、シミュレーションが実行可能になっても、見積もり値の精度が悪いという問題があった。

また、図２０のように、ブリッジを用意する技術の場合、実際にブリッジの実装情報を用意するには、モジュールＡの設計と同等の時間を要することが想定される。それ故、結果として更新システム２０のＡＸＩ仕様が適合されたモジュールＡの開発を待つのと変わらず、システム全体のシミュレーションを実行する際のボトルネックとなるという問題があった。

本開示技術は、上述した従来技術による問題点を解消するため、システム内のモジュールの実装情報が用意されていないようなシステム設計の早期段階であっても、システム全体を動作させた際の電力・性能の見積もりを可能にする検証支援プログラム、検証支援装置および検証支援方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本開示技術は、バスモデルに接続され前記バスモデルと同一の第１の仕様に適合する第１のハードウェアモデルと前記バスモデルに接続され前記バスモデルと異なる第２の仕様に適合する第２のハードウェアモデルとの通信を制御するシミュレーションを実行するコンピュータが、前記第２のハードウェアモデルからの前記第２の仕様に基づくデータを受信する処理と、前記第１の仕様に基づいて、受信されたデータを前記第１の仕様に適合するデータに変換する処理と、変換されたデータを、前記バスモデルを経由して送信先となるハードウェアモデルに送信する処理と、を含むことを特徴とする。

本検証支援プログラム、検証支援装置および検証支援方法によれば、システム設計の早期段階であっても、システム全体を動作させた際の電力・性能の見積もりを可能にするという効果を奏する。

本実施の形態にかかる検証支援処理の概要を示す説明図である。 情報処理装置のハードウェア構成を示すブロック図である。 情報処理装置の機能的構成を示すブロック図である。 仕様の異なるハードウェアモデルへのデータ送信手順を示すフローチャートである。 検証支援処理によるシステムモデルの変更例を示す説明図である。 従来システムにおけるモジュールＡの動作を示すシーケンス図である。 更新システムにおけるモジュールＡの動作を示すシーケンス図である。 更新システムによるシミュレーション実行手順を示すフローチャートである。 更新システムに追加するラッパモデルの作成手順を示すフローチャートである。 ＡＨＢバスのポート情報の一例を示す説明図である。 ＡＸＩバスのポート情報の一例を示す説明図である。 シミュレーション実行時の消費電力見積もり処理を示す説明図である。 シミュレーション実行時の消費電力見積もり処理の補正例を示す説明図である。 ＡＸＩ仕様のハードウェアモデルＡの見積もり例を示すデータテーブルである。 ＡＨＢ仕様のハードウェアモデルＡの見積もり例を示すデータテーブルである。 ＡＸＩ仕様のハードウェアモデルＷの見積もり例を示すデータテーブルである。 ハードウェアモデルＷを挿入したＡＨＢ仕様のハードウェアモデルＡの見積もり例を示すデータテーブルである。 検証対象システムの構成例を示す説明図である。 検証対象システムのプロトコル変更に伴う問題を示す説明図である。 ブリッジ挿入によるプロトコル変換例を示す説明図である。

以下に添付図面を参照して、開示する技術の好適な実施の形態を詳細に説明する。本実施の形態では、検証対象となるシステムのシミュレーション実行の際に、バスの仕様の異なるハードウェアから他のハードウェアへ送信するためのデータが出力されると、このデータに対して、システム内のバスの仕様に適合させるための変換処理が施される。以下、このような動作を実現するための具体的な構成について説明する。

（検証支援処理の概要）
まず、本実施の形態にかかる検証支援処理の概要について説明する。図１は、本実施の形態にかかる検証支援処理の概要を示す説明図である。

本実施の形態では、情報処理装置１００によって検証対象システムのソフトウェアにより再現したシステムモデル１２０のシミュレーションを実行するシステムモデルシミュレータ１１０が構成される。そして、システムモデルシミュレータ１１０によって、システムモデル１２０のシミュレーションを実行することで、検証対象システムの設計段階でシステムを実際に実行させた際の消費電力や処理性能の見積もりを可能にする。

特に、本実施の形態にかかる検証支援処理の場合、システムモデル１２０内に、仕様の異なるハードウェアが混在した場合であっても、システムモデル１２０全体のシミュレーションを実行させることができる。図１のシステムモデル１２０の場合も、バスモデル１２１の仕様（たとえば仕様１）と同じ仕様１の実装情報のモデルＡ、モデルＣと、バスモデル１２１の仕様と異なる仕様２の実装情報のモデルＢ、モデルＤが混在した状態でシミュレーションを実行させる。

システムモデルシミュレータ１１０では、仕様１の実装情報によって構成されたモデルＡ，Ｃの動作については、そのまま、実装情報に基づいたシミュレーションを実行する。一方、仕様２の実装情報によって構成されたモデルＢ，Ｄの動作については、データ送信処理の際に、特定の処理が施される。

たとえば、図１のように各モデル（Ａ〜Ｄ）から、他のいずれかのモデルへデータが送信される場合、当然のことながら、仕様２のモデルＢとモデルＤとから送信されるデータは仕様２の実装情報に基づいて作成されている。そこで、システムモデルシミュレータ１１０は、モデルＢとモデルＤとからバスモデル１２１に出力されるデータを、バスモデル１２１と同じ仕様１に適合したデータに変換する。

このように、仕様２の実装情報によって構成されたモデルから送信されたデータは、仕様１に適合したデータに変換された状態でバスモデル１２１を伝送して、送信先となるモデルへ出力される。そして、各モデルは、仕様に依存することなくバスモデル１２１を介してデータを受信することができる。したがって、送信先となるモデルの仕様がバスモデル１２１の仕様が反映されていなくても、仕様１のデータを受信することができる。

モデルＤから送信されたデータを受信したモデルが、仕様１のモデルＡもしくはモデルＣであった場合、受信したデータに応答したデータが出力されると、このデータはそのまま、バスモデル１２１を介して、送信先となるモデルに送信される。そして、モデルＤから送信されたデータを受信したモデルが、仕様２のモデルＢであった場合、受信したデータに応答したデータが出力されると、モデルＤと同様に、仕様１に適合したデータに変換された後、バスモデル１２１へ出力される。

このように、本実施の形態にかかる検証支援処理を用いることにより、検証対象システム内のハードウェアモデルが開発途中であったり、バスの仕様が変更になった場合であっても、ハードウェアモデルの開発を待たずにシミュレーションを実行することができる。さらに、バスの仕様が異なる場合それぞれについてどのような動作になるかをシミュレーションしたい場合であっても、柔軟にハードウェアモデルの実装情報を入れ替えたシミュレーションの実行も可能になる。そして、このシミュレーション結果を用いて、システム全体を検証するための見積もり値を得ることができる。以下に、本実施の形態にかかる検証支援処理を実現するための具体的な構成ならびに動作について順次説明する。

（情報処理装置のハードウェア構成）
まず、本実施の形態にかかる検証支援処理を実現する情報処理装置のハードウェア構成について説明する。図２は、情報処理装置１００のハードウェア構成を示すブロック図である。図２において、情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、磁気ディスクドライブ２０４と、磁気ディスク２０５と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２０６と、入力デバイス２０７と、出力デバイス２０８と、を備えている。また、各構成部はバス２１０によってそれぞれ接続されている。

ここで、ＣＰＵ２０１は、情報処理装置１００の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムや、本実施の形態にかかる検証支援処理を実現するための検証支援プログラムなどの各種プログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。磁気ディスクドライブ２０４は、ＣＰＵ２０１の制御にしたがって磁気ディスク２０５に対するデータの更新／参照を制御する。磁気ディスク２０５は、磁気ディスクドライブ２０４の制御で書き込まれたデータを記憶する。なお、図４のハードウェア構成では、記録媒体として、磁気ディスク２０５を用いているが、光ディスクや、フラッシュメモリなど他の記録媒体を利用してもよい。

通信Ｉ／Ｆ２０６は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク（ＮＥＴ）２０９に接続され、このネットワーク２０９を介して他の情報処理装置１００やその他の外部装置に接続される。そして、通信Ｉ／Ｆ２０６は、ネットワーク２０９と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。通信Ｉ／Ｆ２０６の構成例としては、たとえばモデムやＬＡＮアダプタなどを採用することができる。

入力デバイス２０７は、情報処理装置１００に対しての外部からの入力を受け付ける。入力デバイス２０７としては、具体的には、キーボード、マウスなどが挙げられる。なお、図２に示したような情報処理装置１００によって、シミュレーションを行うアプリケーションは、ＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域にあらかじめ格納されていてもよいが、入力デバイス２０７から入力されて、上述の記憶領域に格納されてもよい。

キーボードの場合、たとえば、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウスの場合、たとえば、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。また、ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

出力デバイス２０８は、情報処理装置１００に配置されたデータや、シミュレーションの実行結果などを出力する。出力デバイス２０８としては、具体的には、ディスプレイ、プリンタなどが挙げられる。

ディスプレイの場合、たとえば、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイとしてさらに、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。また、プリンタの場合、たとえば、画像データや文書データを印刷する。さらに、レーザプリンタやインクジェットプリンタを採用することができる。

（情報処理装置の機能的構成）
つぎに、情報処理装置１００の機能的構成について説明する。情報処理装置１００では、バスモデル１２１に接続されたバスモデル１２１の仕様１に適合するハードウェアモデル（たとえば、図１のモデルＡ，Ｃ）と、異なる仕様２に適合するハードウェアモデル（たとえば、図１のモデルＢ，Ｄ）との通信を制御するシミュレーションが実行される。このとき、システムモデル１２０のシミュレーション自体は、公知の技術を用いる。

すなわち、情報処理装置１００の機能のうち本実施の形態独自の機能として提供されるのは、シミュレーション実行によって生じるシステムモデル１２０への制御のうち仕様２が適合されたハードウェアモデルからデータが送信された際の処理に関する機能である。したがって、以下には、情報処理装置１００の機能的構成として、仕様２が適合されたハードウェアモデルからデータが送信された際の処理に関する機能部について説明する。

図３は、情報処理装置の機能的構成を示すブロック図である。図３のように、情報処理装置１００は、本実施の形態独自の機能部として受信部３０１と、変換部３０２と、送信部３０３と、消費電力関連付け部３０４と、消費電力呼び出し部３０５と、処理性能関連付け部３０６と、処理性能呼び出し部３０７と、を含む構成である。この制御部となる機能（受信部３０１〜処理性能呼び出し部３０７）は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶された検証支援プログラムをＣＰＵ２０１に実行させることにより、または、通信Ｉ／Ｆ２０６により、その機能を実現する。

受信部３０１は、システムモデル１２０によって検証対象システムのシミュレーションが実行された際に、バスモデル１２１の仕様と異なる仕様２のハードウェアモデルから出力されたデータを受信する機能を有する。また、受信されたデータは、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。仕様２のハードウェアモデルから出力されたデータは、仕様２に基づいたデータであるため、そのままでは、バスモデル１２１との仕様の違いによって図１９にて説明したような不具合を起こす可能性がある。したがって、受信したデータは、後述する変換処理を施すために変換部３０２へ出力される。

また、受信部３０１は、仕様２のハードウェアモデルからの送信データにかかわらず、仕様が特定されていない任意のハードウェアモデルから送信されたデータをすべて受信するような構成であってもよい。このような構成の場合、受信部３０１は、さらに、受信したデータの仕様が、仕様１と一致するか否かを判断する機能を有する。そして、受信部３０１は、受信データの仕様が仕様１と一致しない場合にのみ、受信データを後述する変換部３０２へ出力する。

このように、受信部３０１を設けることによって、仕様２のハードウェアモデルから出力されたデータ、もしくは、システムモデル１２０内のハードウェアモデルから出力されたデータをすべて受信することができる。したがって、仕様２に適合したデータは、仕様１のバスモデル１２１へは出力されないため、仕様２に適合したデータが仕様１のハードウェアモデルに入力されることによるシミュレーションの破綻を防ぐことができる。

変換部３０２は、仕様１に基づいて、受信部３０１によって受信されたデータを仕様１の仕様に適合するデータに変換する機能を有する。仕様１に適合するデータへ変換するため、変換部３０２は、たとえば、仕様１としてあらかじめ与えられたトランザクション定義に応じて、受信されたデータを仕様１に適合するデータに変換するような手法がある。なお、変換されたデータは、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。

このように、変換部３０２を設けることによって、システムモデル１２０のバスの仕様（仕様１）に適合していないデータが、自動的に仕様１に適合したデータに変換される。すなわち、バスの仕様に適合していないデータであっても、システムモデル１２０内で正しく動作するデータとして利用されることを意味する。

また、一旦ハードウェアモデルから出力されたデータは、上記の受信部３０１によって受信した後、変換部３０２による変換が施されている。つまり、検証支援処理をおこなう際に、設計者がハードウェアモデル自体に個別に修正を施すような処理負担は発生しない。したがって、設計者は、シミュレーション用の一時的なハードウェアモデルの開発に追われることなく、仕様１に適合したハードウェアモデルの設計に専念できる。

送信部３０３は、変換部３０２によって変換されたデータを、バスモデル１２１を経由して送信先となるハードウェアモデルに送信する機能を有する。なお、送信部３０３によって送信されたデータは、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。

消費電力関連付け部３０４は、送信部３０３によるデータの送信処理に、この送信処理を実行した際に生じる消費電力を関連付ける機能を有する。具体的には、消費電力関連付け部３０４では、変換部３０２によって変換されたデータを、送信先となるハードウェアモデルに送信する送信処理に、あらかじめ設定された消費電力値を消費電力情報として関連付ける。

消費電力関連付け部３０４において設定される消費電力値とは、実際に仕様１のハードウェアモデルを動作させた場合の消費電力値である。消費電力値は、実際に動作させた場合の値を用意してもよいし、検証値でもよい。なお、消費電力関連付け部３０４によって関連付けられた情報は、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。

消費電力呼び出し部３０５は、システムモデル１２０においてデータの送信処理に関するシミュレーションが実行されると、消費電力関連付け部３０４によって関連付けられた消費電力情報を呼び出す機能を有する。すなわち、送信処理に関するシミュレーションとは、送信部３０３によって仕様１に適合するよう変換されたデータがバスモデル１２１へ送信される処理を意味する。したがって、送信処理のシミュレーションが実行された場合、消費電力関連付け部３０４によって関連付けられた消費電力情報が見積もり値３００として出力される。なお、呼び出された消費電力値は、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。

処理性能関連付け部３０６は、送信部３０３によるデータの送信処理に、この送信処理を実行した際に生じる処理時間を関連付ける機能を有する。具体的には、処理性能関連付け部３０６では、上述した消費電力関連付け部３０４の機能と同様にデータの送信処理に、あらかじめ設定された処理時間を処理性能情報として関連付ける。ここで設定される処理時間とは、仕様１のハードウェアを動作させた場合の処理時間であり、実際に動作させた場合の値でも検証値でもよい。なお、処理性能関連付け部３０６によって関連付けられた情報は、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。

処理性能呼び出し部３０７は、システムモデル１２０においてデータの送信処理に関するシミュレーションが実行されると、処理性能関連付け部３０６によって関連付けられた処理性能情報を呼び出す機能を有する。したがって、送信処理のシミュレーションが実行された場合、処理性能関連付け部３０６によって関連付けられた処理性能情報が見積もり値３００として出力される。なお、呼び出された処理時間は、ＲＡＭ２０３、磁気ディスク２０５などの記憶領域に記憶される。

このように、消費電力関連付け部３０４、消費電力呼び出し部３０５、処理性能関連付け部３０６および処理性能呼び出し部３０７を設けることによって、情報処理装置１００によるシミュレーションの精度を向上させることができる。システムモデル１２０では、本来、仕様１のハードウェアモデルを利用したいが、用意できずに、仕様２のハードウェアモデルを利用している状態である。

そこで、情報処理装置１００では、消費電力関連付け部３０４および処理性能関連付け部３０６により、仕様１に適合したハードウェアモデルによってデータを送信した場合の消費電力値および処理時間を設定しておく。結果として、実際には仕様１に適合していないハードウェアモデルを代用しているにもかかわらず、実際の動作に近い見積もり値３００を得ることができる。したがって、情報処理装置１００では、精度の高いシミュレーションが実行されていることになる。

（データ送信手順）
つぎに、図３にて説明した機能部による仕様の異なるハードウェアモデルへのデータ送信の手順について説明する。図４は、仕様の異なるハードウェアモデルへのデータ送信手順を示すフローチャートである。図４のフローチャートにおいて、まず、受信部３０１が、システムモデル１２０による仕様の異なるハードウェアモデルから他のハードウェアモデルへ送信するデータを受信したか否かを判断する（ステップＳ４０１）。上述したように、送信先のハードウェアモデルは仕様１であっても、仕様２であってもバスモデル１２１へ適切なデータが送信されるため、受信側の他のハードウェアモデルの仕様は問わない。

ステップＳ４０１において、他のハードウェアモデルへの送信データを受信するまで待ち（ステップＳ４０１：Ｎｏのループ）、送信データを受信すると（ステップＳ４０１：Ｙｅｓ）、受信部３０１は、受信データの仕様とバスモデルの仕様とが一致するか否かを判断する（ステップＳ４０２）。

ステップＳ４０２において受信データの仕様とバスモデル１２１の仕様とが一致すると判断された場合（ステップＳ４０２：Ｙｅｓ）、受信データは仕様１に基づいたデータであるため、送信部３０３が、受信したデータをそのままバスモデル１２１へ出力して（ステップＳ４０５）、一連の処理を終了する。たとえば、受信部３０１が仕様１のハードウェアモデルから出力されたデータを受信した場合には、上述のような処理になる。

一方、ステップＳ４０２において、受信したデータの仕様とバスモデル１２１の仕様とが一致しない場合（ステップＳ４０２：Ｎｏ）、つぎに、変換部３０２によって受信したデータをバスモデル１２１の仕様に適合したデータに変換する（ステップＳ４０３）。さらに、消費電力関連付け部３０４および処理性能関連付け部３０６によって、データの送信処理に（後述するステップＳ４０５の処理に相当）、あらかじめ設定した消費電力情報と、処理性能情報とを関連付ける（ステップＳ４０４）。なお、ステップＳ４０３，４０４の順序は問わない。

ステップＳ４０３によるデータ変換処理およびステップＳ４０４の関連付け処理が終わると、最後に、送信部３０３が、変換後のデータをバスモデル１２１へ出力して（ステップＳ４０５）、一連の処理を終了する。たとえば、受信部３０１が仕様２のハードウェアモデルから出力されたデータを受信した場合には、上述のような処理になる。

以上説明したように、情報処理装置１００では、システムモデル１２０のシミュレーションをおこなう際に、仕様の異なるハードウェアモデルから出力されたデータをシステムモデル１２０の仕様と適合するように変換する。すなわち、システムモデル１２０内に仕様の異なるハードウェアモデルが含まれている場合であっても、破綻をきたすことなく正しいシミュレーションを実行させることができる。

（実装例）
つぎに、具体的な実装例として、ＣＰＵ、メモリ、モジュールＡの構成を持つ検証対象システムのバスの仕様がＡＨＢからＡＸＩへ変更された場合について説明する。以下、ＡＨＢが適合されたバスによるシステムを「従来システム」、ＡＸＩが適合されたバスによるシステムを「更新システム」とする。また、システム内のハードウェアのうち、モジュールＡのみがＡＸＩに適合されていないものとして以下説明をおこなう。

図５は、検証支援処理によるシステムモデルの変更例を示す説明図である。図５のように、従来システム５００は、ＣＰＵ、メモリおよびモジュールＡが同一のＡＨＢバスに接続されている。従来システム５００を構成するＣＰＵ、メモリおよびモジュールＡは、ＡＨＢバスと同じＡＨＢ仕様に適合した実装情報によって構成されている。

その後、設計変更が生じ、従来システム５００と同一のハードウェア構成のまま、バスの仕様がＡＸＩへ変更された更新システム５１０が新たな検証対象システムとなる。したがって、更新システム５１０についてのシミュレーションを実行して、消費電力や処理性能を見積もらなければならない。このとき、更新システム５１０を構成するハードウェアのうち、ＣＰＵおよびメモリについてはＡＸＩに適合した実装情報が用意されている。そして、モジュールＡは従来システム５００と同様にＡＨＢに適合した実装情報によって構成されている。

ここで、図６は、従来システムにおけるモジュールＡの動作を示すシーケンス図である。モジュールＡは、ＡＨＢ仕様の実装情報によって構成されている。したがって、図６のように、ＣＰＵからのアクセス（ＷｒｉｔｅＡｄｄｒｅｓ，ＷｒｉｔｅＤａｔａ）を受け付け、実際のデータの書き込み処理であるＷｒｉｔｅＤａｔａの処理が終了すると、応答信号としてＣＰＵへＲｅｓｐｏｎｓｅを送信する。上述のようなモジュールＡの動作は、ＡＨＢ仕様に則した正しい動作であるが、図１９を用いて従来の課題として説明したように、ＡＸＩ仕様の更新システム５１０では、応答信号として不十分となり、更新システム５１０全体の動作が滞ってしまう。

モジュールＡから正しい応答信号を出力させるためには、図３にて説明した機能部を追加する必要がある。そこで、本実装例では、図５のように、モジュールＡとＡＸＩバスと間に、図３にて説明した機能部に相当する処理を実行するモジュールＷを追加する。図７は、更新システムにおけるモジュールＡの動作を示すシーケンス図である。図７のように、更新システム５１０に追加されたモジュールＷでは、モジュールＡの応答信号の出力（Ｒｅｓｐｏｎｓｅ２）にあわせて、ＡＸＩ仕様に適合した応答信号７０１（Ｒｅｓｐｏｎｓｅ１）を出力させる。

ＣＰＵによるモジュールＡへアクセスがおこなわれると、応答信号としてＲｅｓｐｏｎｃｅ１，２が送信される。これら応答信号は、実際には、モジュールＡとモジュールＷとからそれぞれ送信されている。ところが、応答信号自体には、モジュールＡが送信元として設定されているため、ＣＰＵは、ＡＸＩ仕様のモジュールＡから送信された応答信号を受信したものとして、動作することができる。

図７のシーケンス例に限らず、モジュールＡからいずれかのデータが出力された場合には、モジュールＷによる変換処理が施される。したがって、ＣＰＵ、メモリともにＡＸＩ仕様に応じた動作がおこなわれ、更新システム５１０のシミュレーションによる消費電力や処理性能の見積もりが可能となる。

（シミュレーション実行手順）
つぎに、情報処理装置１００の更新システム５１０によるシミュレーション実行手順について説明する。図８は、更新システムによるシミュレーション実行手順を示すフローチャートである。図８のフローチャートにおいて、まず、情報処理装置１００は、従来システム５００と更新システム５１０とのシステムモデルを取得する（ステップＳ８０１）。システムモデルとは、ハードウェアを情報処理装置１００によって仮想的に再現するための情報である。具体的には、システムを構成するハードウェアの接続情報や、各ハードウェアの実装を表す実装情報（たとえばＲＴＬ記述やＴＬ記述）や、仕様書などが含まれている。

つぎに、情報処理装置１００では、ステップＳ８０１において取得した従来システム５００と更新システム５１０との構成を比較し、更新システム５１０の中の実装情報が用意されていないモジュールＡを抽出する（ステップＳ８０２）。モジュールＡが抽出されると、情報処理装置１００では、更新システム５１０のシステムモデルとモジュールＡのモデル（ＡＨＢの実装情報）とを比較してモジュールＷを作成する（ステップＳ８０３）。

本実装例の場合、ステップＳ８０３においてモジュールＷを作成するための手法として、モジュールＡからの出力データを加工するラッパモデルを作成することによって、モジュールＷを作成する。ラッパモデルとは、あるプログラムの返り値を別のプログラムに渡すためのプログラムである。なお、ステップＳ８０３によってモジュールＷを作成するためのラッパモデルの作成については詳しく後述する。

ステップＳ８０３によってモジュールＷが作成されると、情報処理装置１００は、つぎに、更新システム５１０のシステムモデルにモジュールＡおよびモジュールＷのモデルを追加し（ステップＳ８０４）、各モジュール追加後の更新システム５１０のシステムモデルを用いたシミュレーションを実行し（ステップＳ８０５）、一連の処理を終了する。

なお、本実装例では、ＲＴＬ記述の実装情報が提供されているが、その他にも、ＴＬ記述など、抽象度の異なるハードウェア記述が提供される場合もある。このような場合は、各記述レベルに応じた複数のシミュレータを用意し、これら複数のシミュレータを協働させることによって、同一の更新システム５１０についてのシミュレーションが可能になる。

（ラッパモデルの作成手順）
つぎに、図８のステップＳ８０３においてモジュールＷを作成するための、ラッパモデルの作成手順について説明する。図９は、更新システムに追加するラッパモデルの作成手順を示すフローチャートである。図９のフローチャートにおいて、情報処理装置１００は、まず、モジュールＷを設定する（ステップＳ９０１）。このステップＳ９０１の時点では、モジュールＷ内の処理の内容は設定されておらず、いわば空の箱が用意された状態となる。

つぎに、情報処理装置１００は、モジュールＡのバスの接続情報を抽出する（ステップＳ９０２）。ステップＳ９０２においてモジュールＡのバスの接続情報を抽出するため、情報処理装置１００は、まず、モジュールＡの実装情報からポート情報を抽出する。なお、実装情報として提供されるハードウェア記述にはＲＴＬ記述やＴＬ記述などが想定されるが、ここでは、ＲＴＬ記述の実装情報が提供されているものとして説明する。

ここで、図１０は、ＡＨＢバスのポート情報の一例を示す説明図である。モジュールＡにおいてデータの送受が生じる場合には、通常、ポート情報１０００のようにＡＨＢ仕様に応じて設定されたポートにそれぞれ応答をおこなう（たとえば、図６のモジュールＡの動作）。

さらに、情報処理装置１００は、モジュールＡの仕様書からトランザクション情報を抽出する。トランザクション情報とは、モジュールＡに対して各種動作に応じたアクセスがおこなわれた場合のモジュールＡの振る舞いを設定した情報である。したがって、ステップＳ９０２では、下記のように定義されたトランザクション情報の中から、モジュールＡへのアクセスに応じたトランザクション情報を抽出する。なお、実際のトランザクション情報としては設定された振る舞いを実行させるための各種の仕様記述各種言語によって記載されているが、ここでは、振る舞いの内容をわかりやすくさせるため、自然言語で記述している。

＜ＡＨＢトランザクションの定義＞
○ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）の場合
１）
ＨＡＤＤＲにａｄｄｒｅｓｓを送出する。ＨＷＤＡＴＡにｄａｔａを送出する。
ＨＷＲＩＴＥに１（書き込み）を送出する。
ＨＢＵＲＳＴに０（シングル転送）を送出する。
その他の出力信号は任意の値を送出する。
２）
ＨＲＥＳＰ信号が１を出力するのを待つ。
○ｒｅａｄ（ａｄｄｒｅｓｓ）
１）
ＨＡＤＤＲにａｄｄｒｅｓｓを送出する。
ＨＷＲＩＴＥに０（読み出し）を送出する。
ＨＢＵＲＳＴに０（シングル転送）を送出する。
その他の出力信号は任意の値を送出する。
２）
ＨＲＥＳＰ信号が１を出力するのを待つ。
３）
ＨＲＤＡＴＡの値を受信データとする。
○ｉｎｉｔ（）
１）
ＨＲＥＳＥＴｎ信号を０にする。
２）
ＨＲＥＳＥＴｎ信号を１にする。

ステップＳ９０２によってモジュールＡのバスの接続情報が抽出されると、情報処理装置１００は、更新システム５１０のバスの接続情報を抽出する（ステップＳ９０３）。更新システム５１０のバスの接続情報を抽出する場合も、情報処理装置１００は、まず、実装情報からポート情報を抽出する。

ここで、図１１は、ＡＸＩバスのポート情報の一例を示す説明図である。更新システム５１０の各モジュールにおいてデータの送受が生じる場合には、ポート情報１１００のようにＡＸＩ仕様に応じて設定されたポートにそれぞれ応答をおこなう（たとえば、図７のモジュールＡの動作）。

そして、情報処理装置１００は、更新システム５１０の仕様書からトランザクション情報を抽出する。したがって、ステップＳ９０３では、上述のように定義されたトランザクション情報の中から、各モジュールへのアクセスに応じたトランザクション情報を抽出する。

＜ＡＸＩトランザクションの定義＞
○ｗｒｉｔｅ（ａｄｄｒｅｓｓ，ｄａｔａ）
１）
ＡＷＡＤＤＲにａｄｄｒｅｓｓを送出する。
ＷＤＡＴＡにｄａｔａを送出する。
ＡＷＩＤ、ＡＷＬＥＮ、ＷＩＤ、ＷＶＡＬＩＤは０を送出する。
ＡＷＶＡＬＩＤ、ＢＲＥＡＤＹに１を送出する。
他の出力信号は任意の値を送出する。
２）
ＡＷＲＥＳＰ信号が１を受信するのを待つ。
３）
ＷＤＡＴＡにｄａｔａを送出する。ＷＶＡＬＩＤに１を送出する。
４）
ＢＩＤとＷＲＥＳＰが０を、ＢＶＡＬＩＤが１を受信するのを待つ。
○ｒｅａｄ（ａｄｄｒｅｓｓ）
１）
ＡＲＡＤＤＲにａｄｄｒｅｓｓを送出する。
ＡＲＩＤ、ＡＲＬＥＮに０を送出する。
ＲＶＡＬＩＤに１を送出する。
その他の出力信号は任意の値を送出する。
２）
ＲＲＥＡＤＹが０を受信するのを待つ。
３）
ＲＤＡＴＡの値を受信データとする。
○ｉｎｉｔ（）
１）
ＡＲＥＳＥＴｎ信号が０を受信するのを待つ。
２）
ＡＲＥＳＥＴｎ信号が１を受信するのを待つ。
○ｉｎｔｅｒｒｕｐｔ（）
１）
ＡＷＲＥＡＤＹ、ＷＲＥＡＤＹ、ＢＲＥＳＰ、ＡＲＲＥＡＤＹ、ＲＲＥＡＤＹに０を送出する。
他の出力信号は任意の値を送出する。

つぎに、情報処理装置１００は、モジュールＷにモジュールＡとの接続情報を追加する（ステップＳ９０４）。すなわち、ステップＳ９０１において新たに設定したモジュールＷに、ステップＳ９０２において抽出した接続情報を追加する。図５に示したように、更新システム５１０では、バスとモジュールＡとの間にモジュールＷが接続されている。したがって、ステップＳ９０４では、ポート情報１０００のｉｎｐｕｔとｏｕｔｐｕｔとを入れ替えることによって、ステップＳ９０１において設定された空のモジュールＷに、モジュールＡとの接続を表すポート情報が追加される。

そして、情報処理装置１００は、モジュールＷに更新システム５１０との接続情報を追加する（ステップＳ９０５）。更新システム５１０との接続情報とは、モジュールＷとバスとの接続を表す情報である。したがって、ステップＳ９０５では、ポート情報１１００のｉｎｐｕｔとｏｕｔｐｕｔとを入れ替えることによって、モジュールＷに、バスとの接続を表すポート情報が追加される。

最後に、モジュールＷの実装情報に出力値、消費電力情報、処理性能情報を追加することによって（ステップＳ９０６）、モジュールＷの機能を実現するラッパが作成され、一連の処理を終了する。このステップＳ９０６によって実装情報に出力値を追加することによって、更新システム５１０における、モジュールＡの適切な動作を担保することができる。また、消費電力情報および処理性能情報は、情報処理装置１００による更新システム５１０のシミュレーションをおこなった際に、モジュールＡを用いた動作の見積もり値として出力される。

なお、出力値は、モジュールＡによる演算処理結果として正しい値を出力させる必要はないため、あらかじめ設定した値や、ランダムな値を出力値として利用してもよい。これは、情報処理装置１００が、更新システム５１０を動作させた際の消費電力や処理性能の検証を目的としているためである。すなわち、モジュールＡの演算結果として正確な値が出力されなくても、更新システム５１０が与えられたシナリオ通りに滞りなく動作すればよい。

（シミュレーションによる見積もり）
つぎに、上述したような、実装情報に追加された消費電力情報および処理性能情報を利用して、更新システム５１０のシミュレーションを実行した場合の消費電力や処理性能の見積もりについて説明する。

図１２は、シミュレーション実行時の消費電力見積もり処理を示す説明図である。図１２では、ＡＨＢ仕様のシステムにおいてモジュールＡを動作させた場合の見積もりを表している。消費電力は、モジュールＡへのアクセス（ＷｒｉｔｅＡｄｄｒｅｓ，ＷｒｉｔｅＤａｔａ）と、このアクセスに応答した応答信号（Ｒｅｓｐｏｎｓｅ）の出力を検知して、あらかじめ設定した消費電力を加算すればよい。ここでは、１つの処理に生じる電力が１ｍＷと設定されているため、３ｍＷの消費電力が見積もり値として提供される。

本実装例では、更新システム５１０におけるモジュールＡの動作についての見積もりをおこなう必要がある。そこで、更新システム５１０の場合、図１２にて説明した見積もりに補正を施して見積もり値を提供する。図１３は、シミュレーション実行時の消費電力値の補正例を示す説明図である。図１３では、ＡＸＩ仕様の更新システム５１０において、図１２と同様にＣＰＵからのアクセスに応じてモジュールＡが応答信号を送信する処理が示されている。

この場合も、ＣＰＵからのアクセス（ＷｒｉｔｅＡｄｄｒｅｓ，ＷｒｉｔｅＤａｔａ）と、このアクセスに応答した応答信号（Ｒｅｓｐｏｎｓｅ）が検出される。このとき、モジュールＷからＣＰＵやモジュールＡへのアクセス（太矢印）は、実機ではおこなわれないアクセスであるため、基本的には、あらかじめ０ｍＷの消費電力が設定されている。

このとき、例外として、モジュールＷによるデータの変換処理によって新たに生じた応答信号（Ｒｅｓｐｏｎｓｅ１）については、実際に更新システム５１０において発生するアクセスとして検知される。当然、検知された応答信号に対して、あらかじめ設定した消費電力１ｍＷが加算される。結果として、応答信号（Ｒｅｓｐｏｎｓｅ１）の見積もり値が補正値として１ｍＷが加算され、４ｍＷの消費電力が見積もり値として提供される。処理性能値についても検知されたアクセスにあらかじめ設定されていた処理時間が加算されることによって同様に、見積もり値が提供される。

そこで、以下には、具体的な見積もり手順について説明する。図１４は、ＡＸＩ仕様のハードウェアモデルＡの見積もり例を示すデータテーブルである。更新システム５１０において、仮に、ＡＸＩ仕様のモジュールＡのハードウェアモデル（ハードウェアモデルＡ）が用意された場合には、データテーブル１４００のような見積もり値が提供されるとする。

情報処理装置１００では、ＡＸＩ仕様のモジュールＡのハードウェアモデルは用意されていない。そこで、すでに用意されているハードウェアモデルを利用してＡＸＩ仕様のモジュールＡの見積もり値を求める処理をおこなう。そして、ＡＨＢ仕様のモジュールＡのハードウェアモデル（ハードウェアモデルＡ）と、ＡＸＩ仕様のモジュールＷのハードウェアモデル（ハードウェアモデルＷ）とは、すでに用意されているものとする。

図１５は、ＡＨＢ仕様のハードウェアモデルＡの見積もり例を示すデータテーブルであり、図１６は、ＡＸＩ仕様のハードウェアモデルＷの見積もり例を示すデータテーブルである。図９のステップＳ９０６にて消費電力情報と処理性能情報とが追加されているが、ここで追加された情報は、データテーブル１５００，１６００のように保持されている。

したがって、更新システム５１０にモジュールＷが追加された場合には、ハードウェアモデルＡとハードウェアモデルＷの見積もり値を合成する。図１７は、ハードウェアモデルＷを挿入したＡＨＢ仕様のハードウェアモデルＡの見積もり例を示すデータテーブルである。データテーブル１７００のように、データテーブル１５００の見積もり値と、データテーブル１６００の見積もり値を加算することによって、ＡＸＩ仕様のモジュールＡの見積もり値に近い見積もり値を求めることができる。

なお、図１７のデータテーブル１７００の見積もり値は図１４のデータテーブル１４００の値との誤差が生じているが、消費電力情報および処理性能情報の設定時の値の精度を向上させることによってよりデータテーブル１４００の値に近い見積もり値を提供することができる。

以上説明したように、本実施の形態にかかる検証支援処理によれば、バスモデルの仕様とは異なるハードウェアモデルが接続されたシステムであっても、異なる仕様のハードウェアモデルから送信されたデータは、自動的にバスモデルの仕様に適合するデータに変換される。

すなわち、データは、変換された後、初めてバスモデルに送信される。したがって、他のハードウェアと仕様の異なるハードウェアを含む場合であっても、このハードウェアの仕様変更を待たずにシステム全体のシミュレーションを実行することができる。これにより、システム設計の早期段階であっても、システム全体を動作させた際の電力・性能を見積ることができる。

また、上述した検証支援処理では、任意の仕様のモジュールから出力されたデータ、すなわちいずれの仕様に適合したデータかわからないデータを一意的に受け付けるような構成であってもよい。この場合、仕様の異なるデータであれば変換を施し、仕様が一致するデータであれば、そのままバスへ送信する。したがって、システム内の各ハードウェアモデルの仕様が特定できない場合であっても、適切に仕様の異なるデータのみを変換して、正確なシミュレーションを実行させることができる。

なお、本実施の形態で説明した検証支援方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。本検証支援プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本検証支援プログラムは、インターネットなどのネットワークを介して配布してもよい。

１００ 情報処理装置
１１０ システムモデルシミュレータ
１２０ システムモデル
３０１ 受信部
３０２ 変換部
３０３ 送信部
３０４ 消費電力関連付け部
３０５ 消費電力呼び出し部
３０６ 処理性能関連付け部
３０７ 処理性能呼び出し部
３００ 見積もり値
５００ 従来システム
５１０ 更新システム

Claims (6)

1. バスモデルに接続され前記バスモデルと同一の第１の仕様に適合する第１のハードウェアモデルと前記バスモデルに接続され前記バスモデルと異なる第２の仕様に適合する第２のハードウェアモデルとの通信を制御するシミュレーションを実行するコンピュータを、
   前記第２のハードウェアモデルからの前記第２の仕様に基づくデータを受信する受信手段、
   前記第１の仕様としてあらかじめ与えられたトランザクション定義に応じて、前記受信手段によって受信されたデータを前記第１の仕様に適合するデータに変換する変換手段、
   前記変換手段によって変換されたデータを、前記バスモデルを経由して送信先となるハードウェアモデルに送信する送信手段、
   として機能させることを特徴とする検証支援プログラム。
2. 前記受信手段は、任意の仕様のハードウェアモデルからの前記任意の仕様に基づくデータを受信した場合、前記任意の仕様が前記第１の仕様と一致するか否かを判断し、
   前記変換手段は、前記受信手段によって前記任意の仕様が前記第１の仕様と一致しない場合、前記第１の仕様に基づいて、前記受信手段によって受信されたデータを前記第１の仕様に適合するデータに変換することを特徴とする請求項１に記載の検証支援プログラム。
3. 前記コンピュータを、さらに、
   前記送信手段が、前記変換手段によって変換されたデータを前記送信先となるハードウェアモデルに送信する際の消費電力情報として、前記データの送信処理とあらかじめ設定された消費電力値とを関連付ける消費電力関連付け手段、
   前記シミュレーションが実行されると、前記消費電力関連付け手段によって関連付けられた消費電力情報を呼び出す消費電力呼び出し手段、として機能させる請求項１または２に記載の検証支援プログラム。
4. 前記コンピュータを、さらに、
   前記送信手段が、前記変換手段によって変換されたデータを前記送信先となるハードウェアモデルに送信する際の処理性能情報として、前記データの送信処理とあらかじめ設定された処理時間とを関連付ける処理性能関連付け手段、
   前記シミュレーションが実行されると、前記処理性能関連付け手段によって関連付けられた処理性能情報を呼び出す処理性能呼び出し手段、として機能させることを特徴とする請求項１〜３のいずれか一つに記載の検証支援プログラム。
5. バスモデルに接続され前記バスモデルと同一の第１の仕様に適合する第１のハードウェアモデルと前記バスモデルに接続され前記バスモデルと異なる第２の仕様に適合する第２のハードウェアモデルとの通信を制御するシミュレーションを実行する検証支援装置であって、
   前記第２のハードウェアモデルからの前記第２の仕様に基づくデータを受信する受信手段と、
   前記第１の仕様としてあらかじめ与えられたトランザクション定義に応じて、前記受信手段によって受信されたデータを前記第１の仕様に適合するデータに変換する変換手段と、
   前記変換手段によって変換されたデータを、前記バスモデルを経由して送信先となるハードウェアモデルに送信する送信手段と、
   を備えることを特徴とする検証支援装置。
6. バスモデルに接続され前記バスモデルと同一の第１の仕様に適合する第１のハードウェアモデルと前記バスモデルに接続され前記バスモデルと異なる第２の仕様に適合する第２のハードウェアモデルとの通信を制御するシミュレーションを実行するコンピュータが、
   前記第２のハードウェアモデルからの前記第２の仕様に基づくデータを受信する受信工程と、
   前記第１の仕様としてあらかじめ与えられたトランザクション定義に応じて、前記受信工程によって受信されたデータを前記第１の仕様に適合するデータに変換する変換工程と、
   前記変換工程によって変換されたデータを、前記バスモデルを経由して送信先となるハードウェアモデルに送信する送信工程と、
   を実行することを特徴とする検証支援方法。

Images