(57)【要約】【課題】仕様が異なるモジュールをフレキシブルに接続し、設計早期の段階で、容易にシステム全体のシミュレーションを実行可能とする。【解決手段】シミュレーション装置１００は、ハードウェアモジュール又はバスモデルの複数の仕様のうちの１つである第１の仕様に従ったハードウェアモジュール又はバスモデルである第１のモデルと、複数の仕様のうちの１つであって第１の仕様とは異なる第２の仕様に従ったハードウェアモジュール又はバスモデルである第２のモデルとの間の通信のシミュレーションを行う。マスタ部実行部１０１１は、第１のモデルにより生成された第１の仕様に従った通信データを解析し、通信データから、全ての仕様のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を抽出する。スレーブ部実行部１０１３は、抽出された共通データ要素を用いて第２の仕様に従った第２のモデル宛ての通信データを生成する。【選択図】図３
2015170221.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアモジュール又はバスモデルの複数の仕様のうちの１つである第１の仕様に従ったハードウェアモジュール又はバスモデルである第１のモデルと、前記複数の仕様のうちの１つであって前記第１の仕様とは異なる第２の仕様に従ったハードウェアモジュール又はバスモデルである第２のモデルとの間の通信のシミュレーションを行うシミュレーション装置であって、
前記第１のモデルにより生成された前記第１の仕様に従った通信データを解析し、前記通信データから、前記複数の仕様の全ての仕様に対する通信のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を抽出する第１の通信データ管理部と、
前記第１の通信データ管理部により抽出された共通データ要素を用いて前記第２の仕様に従った前記第２のモデル宛ての通信データを生成する第２の通信データ管理部とを有することを特徴とするシミュレーション装置。
【請求項２】
前記第１の通信データ管理部は、
前記第１の仕様に従った通信データから、複数の属性の複数の共通データ要素を抽出し、
前記シミュレーション装置は、更に、
共通データ要素の属性ごとに設けられた複数の記憶領域と、
前記第１の通信データ管理部により抽出された前記複数の共通データ要素を属性ごとに分類し、前記複数の共通データ要素を、それぞれ、対応する属性の記憶領域に格納するとともに、前記複数の記憶領域から前記複数の共通データ要素を読み出す共通データ要素管理部とを有し、
前記第２の通信データ管理部は、
前記共通データ要素管理部により前記複数の記憶領域から読み出された前記複数の共通データ要素を用いて前記第２の仕様に従った通信データを生成することを特徴とする請求項１に記載のシミュレーション装置。
【請求項３】
ハードウェアモジュール又はバスモデルの複数の仕様のうちの１つである第１の仕様に従ったハードウェアモジュール又はバスモデルである第１のモデルと、前記複数の仕様のうちの１つであって前記第１の仕様とは異なる第２の仕様に従ったハードウェアモジュール又はバスモデルである第２のモデルとの間の通信のシミュレーションを行うコンピュータに、
前記第１のモデルにより生成された前記第１の仕様に従った通信データを解析し、前記通信データから、前記複数の仕様の全ての仕様に対する通信のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を抽出する第１の通信データ管理処理と、
前記第１の通信データ管理処理により抽出された共通データ要素を用いて前記第２の仕様に従った前記第２のモデル宛ての通信データを生成する第２の通信データ管理処理とを実行させることを特徴とするプログラム。
【請求項４】
前記第１の通信データ管理処理において、
前記コンピュータに、
前記第１の仕様に従った通信データから、複数の属性の複数の共通データ要素を抽出させ、
前記プログラムは、更に、
前記第１の通信データ管理処理により抽出された前記複数の共通データ要素を属性ごとに分類し、前記複数の共通データ要素を、それぞれ、共通データ要素の属性ごとに設けられた前記コンピュータ内の複数の記憶領域のうちの対応する属性の記憶領域に格納するとともに、前記複数の記憶領域から前記複数の共通データ要素を読み出す共通データ要素管理処理を、前記コンピュータに実行させ、
前記第２の通信データ管理処理において、
前記コンピュータに、
前記共通データ要素管理処理により前記複数の記憶領域から読み出された前記複数の共通データ要素を用いて前記第２の仕様に従った通信データを生成させることを特徴とする請求項３に記載のプログラム。
【請求項５】
ハードウェアモジュール又はバスモデルの複数の仕様のうちの１つである第１の仕様に従ったハードウェアモジュール又はバスモデルである第１のモデルと、前記複数の仕様のうちの１つであって前記第１の仕様とは異なる第２の仕様に従ったハードウェアモジュール又はバスモデルである第２のモデルとの間の通信のシミュレーションが行われる際に、前記第１のモデルと前記第２のモデルとのインタフェースとして機能するプログラムであるインタフェースモジュールを生成するインタフェースモジュール生成装置であって、
前記第１の仕様を解析し、前記第１のモデルにより前記第１の仕様に従って生成される通信データに含まれるデータ要素のうち、前記複数の仕様の全ての仕様に対する通信のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を判別し、判別結果に基づき、前記インタフェースモジュールに含まれるプログラムコードであって、前記通信データから前記共通データ要素を抽出するプログラムコードを、第１のプログラムコードとして生成する第１のプログラムコード生成部と、
前記第２の仕様を解析し、前記インタフェースモジュールに含まれるプログラムコードであって、前記第１のプログラムコードの実行により抽出された共通データ要素を用いて前記第２の仕様に従った前記第２のモデル宛ての通信データを生成するプログラムコードを、第２のプログラムコードとして生成する第２のプログラムコード生成部とを有することを特徴とするインタフェースモジュール生成装置。
【請求項６】
ハードウェアモジュール又はバスモデルの複数の仕様のうちの１つである第１の仕様に従ったハードウェアモジュール又はバスモデルである第１のモデルと、前記複数の仕様のうちの１つであって前記第１の仕様とは異なる第２の仕様に従ったハードウェアモジュール又はバスモデルである第２のモデルとの間の通信のシミュレーションが行われる際に、前記第１のモデルと前記第２のモデルとのインタフェースとして機能するプログラムであるインタフェースモジュールを生成するコンピュータに、
前記第１の仕様を解析し、前記第１のモデルにより前記第１の仕様に従って生成される通信データに含まれるデータ要素のうち、前記複数の仕様の全ての仕様に対する通信のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を判別し、判別結果に基づき、前記インタフェースモジュールに含まれるプログラムコードであって、前記通信データから前記共通データ要素を抽出するプログラムコードを、第１のプログラムコードとして生成する第１のプログラムコード生成処理と、
前記第２の仕様を解析し、前記インタフェースモジュールに含まれるプログラムコードであって、前記第１のプログラムコードの実行により抽出された共通データ要素を用いて前記第２の仕様に従った前記第２のモデル宛ての通信データを生成するプログラムコードを、第２のプログラムコードとして生成する第２のプログラムコード生成処理とを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＬＳＩ開発において、ＲＴＬやＳｙｓｔｅｍＣ（トランザクションレベル、ピンレベル）等でそれぞれ設計された既存モジュールを用い、早期の段階でシステム全体の検証を容易に実施可能とするための、インタフェース（Ｉ／Ｆ）モジュール等に関するものである。
【背景技術】
【０００２】
従来、ＬＳＩ開発では、Ｖｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬといったハードウェア記述言語による設計（以下、ＲＴＬ設計と呼ぶ）、検証をメインで行ってきた。
しかし、近年のＬＳＩの大規模化に伴いＲＴＬ設計されたハードウェアモジュール（以下、ＲＴＬモジュールと呼ぶ）を用いてのシステム全体検証は多大な時間を要することが問題となっており、ハードウェア記述言語よりも抽象度の高いＣ言語、Ｃ＋＋言語、ＳｙｓｔｅｍＣ言語などの高級言語を用いて設計（以下、高位設計と呼ぶ）、検証を行うことで、検証時間の短縮を図る技術が実用化されてきている。
さらに、高位設計されたハードウェアモジュール（以下、高位モジュールと呼ぶ）と既存のＲＴＬモジュールを混在させての検証を可能とする技術もあり、設計の早期段階でシステム全体検証が可能となってきている。
【０００３】
しかし、開発するＬＳＩのプロトコルと、既存のＲＴＬモジュールのプロトコルが異なる場合や、設計早期の段階でプロトコルが決定しておらず、高位モジュール（ハードウェアモジュールやバスモデル）ではトランザクションレベルでの通信を行い、ＲＴＬモジュールのピンレベルでの通信と抽象度が異なる場合などは、そのままでは各モジュール間の接続ができなかった。
そこで、抽象度やプロトコルの異なる各モジュール間に、変換アダプタ（ブリッジ、ラッパ、等で呼ばれることもある）を挿入する技術が一般的に用いられる。
しかし、変換アダプタの処理は、抽象度やプロトコル毎に異なるため、接続するモジュールおよびバスモデル間の抽象度とプロトコルの組み合わせの数だけ、変換アダプタが必要となる。
変換アダプタの作成は、ハードウェアモジュールの設計と同等の時間を要する場合もあるため、バス周辺構成の変更や、プロトコルの変更があると、その分作成期間を要することになり、変換アダプタ作成が、システム全体検証のボトルネックになってしまう。
【０００４】
従来技術は、上記のような問題点を解決するため、バスモデルと同一のプロトコル仕様であるハードウェアモジュール１と、バスモデルと異なるプロトコル仕様であるハードウェアモジュール２との通信を可能とする、データ受信手段と、データ変換手段と、データ送信手段を備えるラッパモデルを自動生成していた（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２３１６３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術では、バスモデルと異なるプロトコルを実装したハードウェアモジュール２を、バスモデルに接続可能とするラッパモデルの自動生成時に、ハードウェアモジュール２の実装情報からバス接続情報を取得し、ハードウェアモジュール２の仕様書からトランザクション情報（プロトコル）を抽出し、それらの情報とバスモデルの仕様に基づき、データ受信手段、データ変換手段、データ送信手段を備えるラッパモデルを生成していた。
しかし、仕様書は作成者毎に記述方法がまちまちであり、一様に情報を抽出可能とは限らない。
また、早期段階でのシステム全体検証は、高位モジュールとＲＴＬモジュールが混在した環境で行う場合があるが、従来技術のラッパモデル自動生成方法は、ハードウェアモジュール２およびバスモデルがどちらもピンレベルで設計されている場合のみ開示されており、抽象度が異なる場合の自動生成方法については開示されていない。
【０００７】
本発明は、このような課題を解決し、抽象度やプロトコルといった仕様が異なるモジュールをフレキシブルに接続し、設計早期の段階で、容易にシステム全体のシミュレーションを実行可能とすることを主な目的とする。
【課題を解決するための手段】
【０００８】
本発明に係るシミュレーション装置は、
ハードウェアモジュール又はバスモデルの複数の仕様のうちの１つである第１の仕様に従ったハードウェアモジュール又はバスモデルである第１のモデルと、前記複数の仕様のうちの１つであって前記第１の仕様とは異なる第２の仕様に従ったハードウェアモジュール又はバスモデルである第２のモデルとの間の通信のシミュレーションを行うシミュレーション装置であって、
前記第１のモデルにより生成された前記第１の仕様に従った通信データを解析し、前記通信データから、前記複数の仕様の全ての仕様に対する通信のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を抽出する第１の通信データ管理部と、
前記第１の通信データ管理部により抽出された共通データ要素を用いて前記第２の仕様に従った前記第２のモデル宛ての通信データを生成する第２の通信データ管理部とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、第１の仕様に従った通信データから、全ての仕様のシミュレーションにおいて共通に利用される共通データ要素を抽出し、抽出した共通データ要素を用いて第２の仕様に従った通信データを生成するため、仕様が異なるモジュールをフレキシブルに接続し、設計早期の段階で、容易にシステム全体のシミュレーションを実行することができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態１に係るＩ／Ｆモジュールの構成例を示す図。
【図２】実施の形態１に係るＩ／Ｆモジュールを用いたバス周辺構成を示す図。
【図３】実施の形態１に係るシミュレーション装置の構成例を示す図。
【図４】実施の形態１に係るマスタ・スレーブ生成装置の構成例を示す図。
【図５】実施の形態１に係るマスタ・スレーブ生成フローを示すフローチャート図。
【図６】実施の形態１に係るパラメータ設定ファイルの記述例を示す図。
【図７】実施の形態１に係るマスタ部の処理タイミングを示す図。
【図８】実施の形態１に係るシミュレーション装置及びマスタ・スレーブ生成装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１は、実施の形態１によるＩ／Ｆモジュールの構成を示したものである。
【００１２】
Ｉ／Ｆモジュール１は、マスタのハードウェアモジュールと、スレーブのハードウェアモジュール又はバスモデルとの間の通信のシミュレーションを行うコンピュータにより実行されるプログラムである。
Ｉ／Ｆモジュール１は、データ通信のマスタとなるハードウェアモジュールとの接続を行うマスタ部２と、データ通信のスレーブとなるハードウェアモジュールまたはバスモデルとの接続を行うスレーブ部３と、マスタ部２とスレーブ部３を仲介する共通部４で構成される。
以下では、ハードウェアモジュールまたはバスモデルのプロトコル、抽象度を仕様と表記する。
また、以下では、マスタとなるハードウェアモジュールの仕様（プロトコル、抽象度）を、マスタ仕様と表記する。
更に、スレーブとなるハードウェアモジュールまたはバスモデルの仕様（プロトコル、抽象度）を、スレーブ仕様と表記する。
マスタ仕様、スレーブ仕様は、それぞれ、ハードウェアモジュールまたはバスモデルの複数の仕様のうちの１つである。
【００１３】
図１において、マスタ部２は、マスタ仕様に対応しており、マスタのハードウェアモジュールにより生成されたマスタ仕様に従った通信データを解析し、当該通信データから、複数の仕様の全ての仕様に対する通信のシミュレーションにおいて共通に利用されるデータ要素である共通データ要素を抽出する。
そして、マスタ部２は、抽出した共通データ要素を、共通部４に渡す。
より具体的には、マスタ部２は、共通データ要素として、通信データから、コマンド関連情報と、データ部分（ペイロード）と、第１の通信データのうちの有効箇所を指定するバイトイネーブルを抽出する。
【００１４】
共通部４は、第１の通信データから抽出されたコマンド関連情報を格納するコマンド用バッファ５と、データ部分（ペイロード）を格納するデータ用バッファ６と、第１の通信データのうちの有効箇所を指定するバイトイネーブルを格納するバイトイネーブル用バッファ７と、バッファ制御部８から構成される。
図１では、説明の便宜上、コマンド用バッファ５、データ用バッファ６、バイトイネーブル用バッファ７をＩ／Ｆモジュール１の構成要素としているが、現実には、これらのバッファはＩ／Ｆモジュール１を実行するコンピュータ内の複数の記憶領域である。
バッファ制御部８は、マスタ部２により抽出された複数の共通データ要素を属性ごとに分類し、複数の共通データ要素を、それぞれに対応する属性のバッファに格納する。
つまり、バッファ制御部８は、第１の通信データから抽出されたコマンド関連情報をコマンド用バッファ５に格納し、データ部分（ペイロード）をデータ用バッファ６に格納し、バイトイネーブルをバイトイネーブル用バッファ７に格納する。
また、バッファ制御部８は、各バッファから共通データ要素を読み出し、読み出した共通データ要素をスレーブ部３に渡す。
【００１５】
スレーブ部３は、スレーブ仕様に対応している。
スレーブ部３は、バッファ制御部８により読み出された複数の共通データ要素を用いて、スレーブとなるハードウェアモジュールまたはバスモデル宛てのスレーブ仕様に従った通信データを生成する。
【００１６】
信号線９は、マスタとなるハードウェアモジュールからマスタ部２へ送信される読み出し・書き込み要求関連の情報、マスタ部２からハードウェアモジュールへ送信される応答情報、および、通信データ等である。
信号線１０は、スレーブ部３からスレーブとなるハードウェアモジュールへ送信される読み出し・書き込み要求関連の情報、ハードウェアモジュールからスレーブ部３へ送信される応答情報、および、通信データ等である。
信号線１１は、マスタ部２と共通部４のバッファ制御部８で送受信される各種抽象度・プロトコルに共通の情報であり、信号線１２は、スレーブ部３と共通部４のバッファ制御部８で送受信される各種抽象度・プロトコルに共通の情報であり、信号線１３、１４、１５は、それぞれ、コマンド関連情報、データ、バイトイネーブルである。
【００１７】
マスタとなるハードウェアモジュールからＩ／Ｆモジュール１を介してスレーブとなるハードウェアモジュール又はバスモデルへ通信データを送信するシミュレーションでは、マスタ部２が第１の通信データ管理処理に対応し、スレーブ部３が第２の通信データ管理処理に対応する。
また、マスタとなるハードウェアモジュールが第１のモデルに対応し、スレーブとなるハードウェアモジュール又はバスモデルが第２のモデルに対応する。
また、マスタ仕様が第１の仕様に対応し、スレーブ仕様が第２の仕様に対応する。
スレーブとなるハードウェアモジュール又はバスモデルからＩ／Ｆモジュール１を介してマスタとなるハードウェアモジュールへ通信データを送信するシミュレーションでは、スレーブ部３が第１の通信データ管理処理に対応し、マスタ部２が第２の通信データ管理処理に対応する。
また、スレーブ仕様が第１の仕様に対応し、マスタ仕様が第２の仕様に対応する。
また、いずれのシミュレーションにおいても、バッファ制御部８が共通データ要素管理処理に対応する。
【００１８】
図２に、実施の形態１によるＩ／Ｆモジュール１を用いたバス周辺構成を示す。
プロトコルＡが実装されているバスモデル２０に、プロトコルＡが実装されているモジュール１（２１）、トランザクションレベルで実装されているモジュール２（２２）、プロトコルＡで実装されているモジュール３（２３）、プロトコルＢで実装されているモジュール４（２４）が接続されている。
このとき、バスモデル２０と同じプロトコルで実装されているモジュール１（２１）とモジュール３（２３）は、直接接続可能であるが、バスモデル２０とは異なる抽象度、または、プロトコルが実装されているモジュール２（２２）およびモジュール４（２４）は、直接は接続できないため、それぞれＩ／Ｆモジュール１の挿入が必要である。
【００１９】
図３は、図１に示したＩ／Ｆモジュール１を実行するコンピュータであるシミュレーション装置１００の構成例を示す。
【００２０】
Ｉ／Ｆモジュール実行部１０１は、Ｉ／Ｆモジュール１を実行する。
バッファ領域１０２は、図１に示すコマンド用バッファ５、データ用バッファ６、バイトイネーブル用バッファ７に対応する記憶領域である。
マスタ・スレーブ実行部１０３は、マスタとなるハードウェアモジュール、スレーブとなるハードウェアモジュールまたはバスモデルを実行する。
プログラム記憶部１０４は、Ｉ／Ｆモジュール１、マスタとなるハードウェアモジュール、スレーブとなるハードウェアモジュールまたはバスモデルのそれぞれに対応するプログラムを記憶する。
【００２１】
Ｉ／Ｆモジュール実行部１０１において、マスタ部実行部１０１１は、Ｉ／Ｆモジュール１のマスタ部２を実行する。
すなわち、マスタ部実行部１０１１は、マスタ部２を実行して、マスタ仕様に従った通信データから共通データ要素を抽出し、抽出した共通データ要素をバッファ制御部８（バッファ制御部実行部１０１２）に渡す処理を行う。
また、マスタ部実行部１０１１は、マスタ部２を実行して、バッファ制御部８（バッファ制御部実行部１０１２）から渡された共通データ要素を用いてマスタ仕様に従った通信データを生成する処理を行う。
マスタ部実行部１０１１は、マスタのハードウェアモジュールからスレーブのハードウェアモジュールまたはバスモデルへの通信のシミュレーションでは、第１の通信データ管理部として機能する。
また、マスタ部実行部１０１１は、スレーブのハードウェアモジュールまたはバスモデルからマスタのハードウェアモジュールへの通信のシミュレーションでは、第２の通信データ管理部として機能する。
【００２２】
バッファ制御部実行部１０１２は、Ｉ／Ｆモジュール１のバッファ制御部８を実行する。
すなわち、バッファ制御部実行部１０１２は、バッファ制御部８を実行して、マスタ部２（マスタ部実行部１０１１）から渡された共通データ要素を、それぞれに対応するバッファ（コマンド用バッファ、データ用バッファ、バイトイネーブル用バッファ）に格納し、また、各バッファ内の共通データ要素をスレーブ部３（スレーブ部実行部１０１３）に渡す処理を行う。
また、バッファ制御部実行部１０１２は、バッファ制御部８を実行して、スレーブ部３（スレーブ部実行部１０１３）から渡された共通データ要素を、それぞれに対応するバッファ（コマンド用バッファ、データ用バッファ、バイトイネーブル用バッファ）に格納し、また、各バッファ内の共通データ要素をマスタ部２（マスタ部実行部１０１１）に渡す処理を行う。
バッファ制御部実行部１０１２は、共通データ要素管理部の例に相当する。
【００２３】
スレーブ部実行部１０１３は、Ｉ／Ｆモジュール１のスレーブ部３を実行する。
すなわち、スレーブ部実行部１０１３は、スレーブ部３を実行して、バッファ制御部８（バッファ制御部実行部１０１２）から渡された共通データ要素を用いてスレーブ仕様に従った通信データを生成する処理を行う。
また、スレーブ部実行部１０１３は、スレーブ部３を実行して、スレーブ仕様に従った通信データから共通データ要素を抽出し、抽出した共通データ要素をバッファ制御部８（バッファ制御部実行部１０１２）に渡す処理を行う。
スレーブ部実行部１０１３は、マスタのハードウェアモジュールからスレーブのハードウェアモジュールまたはバスモデルへの通信のシミュレーションでは、第２の通信データ管理部として機能する。
また、スレーブ部実行部１０１３は、スレーブのハードウェアモジュールまたはバスモデルからマスタのハードウェアモジュールへの通信のシミュレーションでは、第１の通信データ管理部として機能する。
【００２４】
図４は、図１に示したＩ／Ｆモジュール１のマスタ部２及びスレーブ部３を生成するマスタ・スレーブ生成装置３０の構成例を示す。
マスタ・スレーブ生成装置３０は、Ｉ／Ｆモジュール生成装置の例に相当する。
【００２５】
マスタ・スレーブ生成装置３０において、パラメータ解析部３１は、外部から入力されるパラメータ設定ファイルから、マスタ部２が接続するハードウェアモジュール、およびスレーブ部３が接続するハードウェアモジュールまたはバスモデルについての抽象度やプロトコルに関する情報を解析する。
【００２６】
Ｉ／Ｏ解析部３２は、外部から入力される接続モジュールのＩ／Ｏ記述ファイルから、マスタ部２が接続するハードウェアモジュール、およびスレーブ部３が接続するハードウェアモジュールまたはバスモデルのＩ／Ｏ情報を解析する。
【００２７】
生成部３３は、パラメータ解析部３１とＩ／Ｏ解析部３２からの情報に従ってマスタ部記述（マスタ部２に対応するプログラムコード）およびスレーブ部記述（スレーブ部３に対応するプログラムコード）を生成する。
【００２８】
ライブラリ３６は、各種抽象度におけるマスタ部２およびスレーブ部３のテンプレート記述と、一般的に用いられるプロトコルにおけるマスタ部記述とスレーブ部記述を予め格納する。
【００２９】
ライブラリ読み出し部３５は、パラメータ設定ファイルの抽象度やプロトコルに関する情報に基づき、ライブラリ３６よりマスタ部２およびスレーブ部３のテンプレート記述、または一般的に用いられるプロトコルにおけるマスタ部記述およびスレーブ部記述を読み出し、生成部３３または出力部３４に渡す。
【００３０】
出力部３４は、生成部３３またはライブラリ読み出し部３５より渡されたマスタ部記述およびスレーブ部記述を外部に出力する。
【００３１】
信号線３７は、予めライブラリ３６に書き込まれる各種テンプレート記述、マスタ部記述、および、スレーブ部記述である。
信号線３８は、パラメータ設定ファイルから入力される各種パラメータ情報である。
信号線３９は、Ｉ／Ｏ記述ファイルから入力されるＩ／Ｏ情報である。
信号線４０は、生成部３３からパラメータ解析部３１へのパラメータ解析命令である。
信号線４１は、パラメータ解析部３１から出力されるパラメータ解析結果である。
信号線４２は、生成部３３からＩ／Ｏ解析部３２へのＩ／Ｏ解析命令である。
信号線４３は、Ｉ／Ｏ解析部３２から出力されるＩ／Ｏ解析結果である。
信号線４４は、生成部３３からライブラリ読み出し部３５へのライブラリ読み出し命令である。
信号線４５は、ライブラリ３６からライブラリ読み出し部３５に読み出されるテンプレート記述、マスタ部記述、および、スレーブ部記述である。
信号線４６は、ライブラリ読み出し部３５から生成部３３または出力部３４へ渡すテンプレート記述、マスタ部記述、および、スレーブ部記述である。
信号線４７は、生成部３３が生成したマスタ部記述およびスレーブ部記述である。
信号線４８は、出力部３４から外部へ出力されるマスタ部記述である。
信号線４９は、出力部３４から外部へ出力されるスレーブ部記述である。
【００３２】
図４において、生成部３３が生成するマスタ部記述及びスレーブ部記述は、第１のプログラムコード及び第２のプログラムコードに対応する。
また、パラメータ解析部３１、Ｉ／Ｏ解析部３２及び生成部３３は、第１のプログラムコード生成部及び第２のプログラムコード生成部の例に相当する。
【００３３】
図５は、実施の形態１によるマスタ・スレーブ生成装置３０で実行する、マスタ・スレーブ生成のフロー図であり、マスタ部２、スレーブ部３それぞれについて本フローが実行される。
【００３４】
Ｐ０１では、生成部３３が、パラメータ解析部３１へ抽象度パラメータの解析命令を出力し、パラメータ解析部３１はパラメータ設定ファイルより抽象度パラメータを抽出し解析する。
【００３５】
Ｐ０２では、Ｐ０１で解析した抽象度がトランザクションレベル（ＴＬＭ）を示す識別子（例えば、Ｌｏｏｓｅｌｙ  ＴｉｍｅｄのＬＴや、Ａｐｐｒｏｘｉｍａｔｅｌｙ  ＴｉｍｅｄのＡＴ）であるか、ピンレベルを示す識別子（例えば、ＰＩＮ）であるかによって分岐する。
【００３６】
Ｐ１１では、Ｐ０２でＴＬＭを示す識別子ならば、生成部３３が、ライブラリ読み出し部３５へＴＬＭ用テンプレートのライブラリ読み出し命令を出力し、ライブラリ読み出し部３５はライブラリ３６かから対応するテンプレート記述を読み出し、生成部３３へ渡す。
【００３７】
Ｐ１２では、Ｐ１１に続き、生成部３３がパラメータ解析部３１へＴＬＭ用のパラメータ解析命令を出力し、パラメータ解析部３１はパラメータ設定ファイルよりＴＬＭ用の各種パラメータを抽出し解析する。
【００３８】
Ｐ１３では、生成部３３が、Ｐ１２で得られたパラメータ解析結果に基づき、Ｐ１１で取得したテンプレート記述を書き換え、出力部３４へ渡す。
【００３９】
Ｐ０３では、Ｐ０２でピンレベルを示す識別子ならば、生成部３３がパラメータ解析部３１へＩＦ分類パラメータ解析命令を出力し、パラメータ解析部３１がパラメータ設定ファイルよりＩＦ分類のパラメータを抽出し解析する。
【００４０】
Ｐ０４では、Ｐ０３で解析したＩＦ分類がＡＸＩやＡＨＢ等の一般的なプロトコルであり既にライブラリに用意しているプロトコルであるか、それ以外のプロトコル（ＯＴＨＥＲ）であるかによって分岐する。
【００４１】
Ｐ２１では、Ｐ０４でそれ以外のプロトコルを示す識別子（ＯＴＨＥＲ）ならば、生成部３３が、ライブラリ読み出し部３５へＰＩＮ用テンプレートのライブラリ読み出し命令を出力し、ライブラリ読み出し部３５はライブラリ３６から対応するテンプレート記述を読み出し、生成部３３へ渡す。
【００４２】
Ｐ２２では、Ｐ２１に続き、生成部３３がＩ／Ｏ解析部３２へＩ／Ｏ解析命令を出力し、Ｉ／Ｏ解析部３２はＩ／Ｏ記述ファイルよりＩ／Ｏ情報を抽出し解析する。
【００４３】
Ｐ２３では、Ｐ２２に続き、生成部３３がパラメータ解析部３１へピンレベル用のパラメータ解析命令を出力し、パラメータ解析部３１はパラメータ設定ファイルよりピンレベル用の各種パラメータを抽出し解析する。
【００４４】
Ｐ２４では、生成部３３が、Ｐ２２とＰ２１で得られたＩ／Ｏ解析結果およびパラメータ解析結果に基づき、Ｐ２１で取得したテンプレート記述を書き換え、出力部３４へ渡す。
【００４５】
Ｐ３１では、Ｐ０４で一般的なプロトコルであり既にライブラリに用意しているプロトコルを示す識別子ならば、生成部３３が、ライブラリ読み出し部３５へ対応するマスタ部記述またはスレーブ部記述のライブラリ読み出し命令を出力し、ライブラリ読み出し部３５はライブラリ３６から対応するマスタ部記述またはスレーブ部記述を読み出し、出力部３４へ渡す。
【００４６】
Ｐ０５では、出力部３４が、Ｐ１３、Ｐ２４、または、Ｐ３１で得られたマスタ部記述またはスレーブ部記述を外部へ出力する。
【００４７】
続いて、図６（ａ）、（ｂ）、（ｃ）は、実施の形態１によるパラメータ解析部３１が解析するパラメータ設定ファイル内の記述例である。
【００４８】
図６（ａ）は、マスタ部２に接続するハードウェアモジュールの抽象度がＬＴであることを示しており、以下ＡＲＧＵＭＥＮＴ、ＴＬ＿ＣＭＤ、ＴＬ＿ＡＤＤＲ、ＴＬ＿ＬＥＮ等は、抽象度がＴＬＭである場合のパラメータであり、共通部４に格納するコマンド関連情報、データ等がどの変数に対応しているのかを示す。
一方、スレーブ部３に接続するハードウェアモジュールまたはバスモデルの抽象度はピンレベルであることを示している。
【００４９】
図６（ｂ）は、マスタ部２に接続するハードウェアモジュールの抽象度がピンレベルであり、ＩＦ分類がＡＸＩであり、既にライブラリ３６にマスタ部記述が用意されていることを示している。
【００５０】
図６（ｃ）は、マスタ部２に接続するハードウェアモジュールの抽象度がピンレベルであり、ＩＦ分類がＯＴＨＥＲであることを示している。
以下、ＷＣＭＤ、ＲＣＭＤ、ＲＥＳＰ、ＷＤＡＴＡ等は抽象度がピンレベルである場合のパラメータであり、共通部４に格納するコマンド関連情報、データ等がどの信号に対応しているのかを示す。
【００５１】
図７は、図６（ｃ）のパラメータ設定である場合のマスタ部の処理をタイミング図で示したものである。
【００５２】
“ＷＣＭＤ＝｛Ｍａｄｄｒ｝＠（ＭＣｍｄ＝１）”は、ＭＣｍｄが１のときに書き込み要求としてＭａｄｄｒを取得することを意味する。
“ＷＤＡＴＡ＝｛Ｍｄａｔａ｝＠（ＭＣｍｄ＝１）”は、Ｍｃｍｄが１のときに書き込みデータとしてＭｄａｔａを取得することを意味する。
このため、図７の５０のＭｃｍｄ＝１のタイミングにおいて、マスタ部２は、ＭＡｄｄｒとＭｄａｔａをハードウェアモジュールから取得し、共通部４へ送信する。
共通部４は、書き込み要求を正常に受理すると、受理したことを示すＡＣＣＥＰＴ信号をマスタ部２へ送信する。
“ＲＥＳＰ＝｛ＳＣｍｄＡｃｃｅｐｔ＝１｝＠ＡＣＣＥＰＴ”は、ＡＣＣＥＰＴ信号がアサートされたら応答としてＳＣｍｄＡｃｃｅｐｔに１をアサートすることを意味しているので、マスタ部２は図７の５１でＳＣｍｄＡｃｃｅｐｔを１にする。
【００５３】
以上のように、本実施の形態に係るＩ／Ｆモジュール１を用いれば、ハードウェアモジュールまたはバスモデルの各種抽象度や各種プロトコルで共通に情報を処理する共通部４を設けているため、抽象度が異なる場合の変換も可能である。
つまり、Ｉ／Ｆモジュール１をマスタ部２、スレーブ部３、および、共通部４で構成し、各種抽象度やプロトコルで共通に必要となる情報をバッファに格納するようにしたこと、および、パラメータ設定ファイルにおいて抽象度の指定ができるようにしたことで、従来技術では開示されていなかった、異なる抽象度間の変換にも対応可能となる。
また、パラメータ設定ファイルから、抽象度やプロトコルに関連する情報を指定可能としたことで、作成者によらず一様に、一意にＩ／Ｆモジュール１のマスタ部２およびスレーブ部３を自動生成することができるので、設計の早期段階でのシステム全体検証を容易に実施可能となる。
つまり、作成者によらず一様に、一意に情報を取得可能となるので、作成者によって記述方法が異なる仕様書から一様に情報を抽出することが困難であった従来技術の課題を解決できる。
【００５４】
最後に、本実施の形態に示したシミュレーション装置１００及びマスタ・スレーブ生成装置３０のハードウェア構成例を図８を参照して説明する。
シミュレーション装置１００及びマスタ・スレーブ生成装置３０はコンピュータであり、シミュレーション装置１００及びマスタ・スレーブ生成装置３０の各要素をプログラムで実現することができる。
シミュレーション装置１００及びマスタ・スレーブ生成装置３０のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。
【００５５】
演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。
通信装置９０４は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）である。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。
図３のバッファ領域１０２は、例えば、主記憶装置９０３で実現される。
また、図３のプログラム記憶部１０４、図４のライブラリ３６は、例えば、外部記憶装置９０２で実現される。
【００５６】
プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図３及び図４に示す「〜部」（プログラム記憶部１０４を除く、以下も同様）として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図３及び図４に示す「〜部」の機能を実現するプログラムを実行する。
また、本実施の形態の説明において、「〜の抽出」、「〜の解析」、「〜の生成」、「〜の検知」、「〜の設定」、「〜の選択」、等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。
【００５７】
なお、図８の構成は、あくまでもシミュレーション装置１００及びマスタ・スレーブ生成装置３０のハードウェア構成の一例を示すものであり、シミュレーション装置１００及びマスタ・スレーブ生成装置３０のハードウェア構成は図８に記載の構成に限らず、他の構成であってもよい。
【符号の説明】
【００５８】
１  Ｉ／Ｆモジュール、２  マスタ部、３  スレーブ部、４  共通部、５  コマンド用バッファ、６  データ用バッファ、７  バイトイネーブル用バッファ、８  バッファ制御部、９  信号線、１０  信号線、１１  信号線、１２  信号線、１３  信号線、１４  信号線、１５  信号線、３０  マスタ・スレーブ生成装置、３１  パラメータ解析部、３２  Ｉ／Ｏ解析部、３３  生成部、３４  出力部、３５  ライブラリ読み出し部、３６  ライブラリ、３７  信号線、３８  信号線、３９  信号線、４０  信号線、４１  信号線、４２  信号線、４３  信号線、４４  信号線、４５  信号線、４６  信号線、４７  信号線、４８  信号線、４９  信号線、１００  シミュレーション装置、１０１  Ｉ／Ｆモジュール実行部、１０２  バッファ領域、１０３  マスタ・スレーブ実行部、１０４  プログラム記憶部、１０１１  マスタ部実行部、１０１２  バッファ制御部実行部、１０１３  スレーブ部実行部。
【図１】
2015170221.tif 000003
【図２】
2015170221.tif 000004
【図３】
2015170221.tif 000005
【図４】
2015170221.tif 000006
【図５】
2015170221.tif 000007
【図６】
2015170221.tif 000008
【図７】
2015170221.tif 000009
【図８】
2015170221.tif 000010