(57)【要約】  シミュレーション装置（９００）は、システムのアーキテクチャモデルとシナリオ記述を取得する。アーキテクチャモデルは、シナリオブロック、複数の計算ブロック、バスモデルおよびメモリモデルを含む。シナリオブロックは、複数の計算ブロックに起動信号を発行するとともに複数の計算ブロックからの終了信号を検出する。計算ブロックは、バスモデルを介してメモリモデルにアクセスして計算処理を行う。シナリオ記述は、計算ブロックごとに、一連の処理で行われる計算処理の回数、計算処理にかかるサイクル数、計算処理にかかるリードデータ量、計算処理にかかるライトデータ量および計算ブロックの動作周波数を示す。シミュレーション装置（９００）は、取得したアーキテクチャモデルとシナリオ記述に基づいて、アーキテクチャモデルのシミュレーションを実行する。
2014064788.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行させることを特徴とするシミュレーションプログラム。
【請求項２】
前記ブロックは、前記計算処理にかかるリードデータ量のデータを読み込む読込処理を行う読込部と、前記計算処理にかかるサイクル数分の遅延を発生させる計算部と、前記計算処理にかかるライトデータ量のデータを書き込む書込処理を行う書込部とを含み、
前記読込部は、前記シナリオブロックまたは前記計算部からの起動信号を検出したら前記読込処理を行って前記計算部に起動信号を発行し、
前記計算部は、前記ブロックの動作周波数に基づいて、前記読込部からの起動信号を検出してから前記計算処理にかかるサイクル数分の時間が経過したら前記書込部に起動信号を発行するとともに、前記書込部からの起動信号を検出したら前記読込部に起動信号を発行し、
前記書込部は、前記計算部からの起動信号を検出したら前記書込処理を行って前記計算部に起動信号を発行するとともに、前記計算処理の回数分の書込処理を行った場合に前記シナリオブロックに終了信号を発行することを特徴とする請求項１に記載のシミュレーションプログラム。
【請求項３】
前記バスモデルは、前記ブロックから前記リードデータ量のデータの発注書の転送要求を受け付けると、前記発注書を前記メモリモデルに書き込み、前記メモリモデルによって前記リードデータ量のデータが書き込まれると、前記ブロックに前記リードデータ量のデータを送信し、
前記メモリモデルは、前記バスモデルによって前記発注書が書き込まれると、前記リードデータ量のデータを前記バスモデルに書き込むことを特徴とする請求項２に記載のシミュレーションプログラム。
【請求項４】
前記バスモデルは、前記ブロックからライトデータ量のデータの転送要求を受け付けると、前記ライトデータ量のデータを前記メモリモデルに書き込むことを特徴とする請求項３に記載のシミュレーションプログラム。
【請求項５】
前記バスモデルは、バッファを有するネゴシエーターモデルと、前記バッファへのアクセスを排他制御するアービターモデルと、を有し、
前記ネゴシエーターモデルは、前記発注書の転送要求を受け付けた場合、前記アービターモデルの排他制御に従って、前記発注書を前記バッファに書き込み、前記バッファに書き込まれた前記発注書を前記メモリモデルに書き込んだ後に前記バッファを解放することを特徴とする請求項４に記載のシミュレーションプログラム。
【請求項６】
前記コンピュータに、
実行した前記アーキテクチャモデルのシミュレーションの実行結果を出力する処理を実行させることを特徴とする請求項５に記載のシミュレーションプログラム。
【請求項７】
コンピュータに、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行させるシミュレーションプログラムを記録したことを特徴とする前記コンピュータに読取可能な記録媒体。
【請求項８】
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得する第１処理部と、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得する第２処理部と、
前記第１処理部によって取得された前記アーキテクチャモデルと前記第２処理部によって取得された前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する第３処理部と、
を有することを特徴とするシミュレーション装置。
【請求項９】
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得する第１処理部と、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得する第２処理部と、
前記第１処理部によって取得された前記アーキテクチャモデルと前記第２処理部によって取得された前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する第３処理部と、
を有するコンピュータを含むことを特徴とするシミュレーション装置。
【請求項１０】
コンピュータが、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行することを特徴とするシミュレーション方法。
【請求項１１】
リード要求相当の動作として、あるブロックからデータの発注書を転送し、別のあるブロックが発注書を受信し、それに対応したデータを小包として発送する手段と、ライト要求相当の動作として、あるブロックから小包を発送する手段があり、データの一部に転送先などの制御情報をもち、転送を行う回路はこれらを解釈して所望のデータ転送を実現する手段をもったバスモデル、および、バス回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路に関する。
【背景技術】
【０００２】
従来、ＥＳＬ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｙｓｔｅｍ  Ｌｅｖｅｌ）などのＲＴＬ（Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ）よりも抽象度が高いレベルでシミュレーションモデルを作成してシステムの性能評価が行われる場合がある。また、表計算ソフトなどを用いたユーザの手計算により、システムの性能を見積もる場合がある。【０００３】
関連する先行技術としては、例えば、ＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）モデルを解析した解析結果を、利用者により入力された変換規則に従って変換して性能評価モデルを作成するものがある。また、複数の回路ブロックがバスで接続されているシステムの性能を、ソフトウェアを実行した際のバスの情報と、ライブラリに保持されているシステムにおける各回路ブロックに対する部品が持つバスオペレーションの情報とから算出するものがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−３１８８１２号公報
【特許文献２】特開２０００−２９３３９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来技術によれば、システムの性能を評価するためのシミュレーションモデルの作成に時間や手間がかかるという問題がある。例えば、ＥＳＬであってもシミュレーションモデルの作成に数ヶ月単位の期間を要することがあり、顧客との商談時などの設計段階よりも前の段階にシステムの性能を評価することが難しい。【０００６】
また、近年では、様々なハードウェアブロックを組み合わせてＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ａ  Ｃｈｉｐ）を設計する場合が多く、様々な機能が含まれるようになってきている。このため、表計算ソフトなどを用いた手計算でシステムの性能を見積もるには、多数の専門家が経験と勘を駆使して机上検討を行うことになり作業時間やコストが増大する。【０００７】
１つの側面では、本発明は、システムの性能を評価するシミュレーションの効率化を図ることができるシミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一側面によれば、複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行するシミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路が提案される。
【発明の効果】
【０００９】
本発明の一態様によれば、システムの性能を評価するシミュレーションの効率化を図ることができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、タスクの実行状況とバス流量との関係を示す説明図である。
【図２】図２は、ｓｔａｒｔ＿ｄｏｎｅの記述例を示す説明図である。
【図３】図３は、計算ブロックの一例を示す説明図である。
【図４】図４は、計算ブロックの記述例を示す説明図である。
【図５】図５は、リードインターフェースの記述例を示す説明図である。
【図６】図６は、アーキテクチャモデルの具体例を示す説明図である。
【図７】図７は、シナリオブロックＳＢのシナリオ記述例を示す説明図である。
【図８】図８は、結合記述例を示す説明図である。
【図９】図９は、シミュレーション装置９００のハードウェア構成例を示すブロック図である。
【図１０】図１０は、シミュレーション装置９００の機能的構成例を示すブロック図である。
【図１１】図１１は、シミュレーションの実行例を示す説明図である。
【図１２】図１２は、バスプロトコルの一例を示す説明図（その１）である。
【図１３】図１３は、バスプロトコルの一例を示す説明図（その２）である。
【図１４】図１４は、アービトレーションの回路例を示す説明図である。
【図１５】図１５は、トリッププランの回路例を示す説明図である。
【図１６】図１６は、アービトレーションモデルの具体例を示す説明図である。
【図１７】図１７は、データの転送例を示す説明図である。
【図１８】図１８は、トリッププランのクラス図の一例を示す説明図である。
【図１９】図１９は、ｒｏｕｔｅ＿ｎ＿１＿ｔのクラス図の一例を示す説明図である。
【図２０】図２０は、ｒｏｕｔｅ＿ｎ＿１＿ｔのｍａｋｅ（）の定義例を示す説明図である。
【図２１】図２１は、アーキテクチャのサンプル例を示す説明図である。
【図２２】図２２は、アーキテクチャの接続記述例を示す説明図である。
【図２３】図２３は、イニシエータの回路記述例を示す説明図である。
【図２４】図２４は、ターゲットの回路記述例を示す説明図である。
【図２５】図２５は、状態遷移例を示す説明図（その１）である。
【図２６】図２６は、状態遷移例を示す説明図（その２）である。
【図２７】図２７は、構造情報に関するクラス図である。
【図２８】図２８は、部品情報の出力例を示す説明図である。
【図２９】図２９は、プローブ情報に関するクラス図である。
【図３０】図３０は、状態の定義例を示す説明図である。
【図３１】図３１は、コンフィギュレーション情報の具体例を示す説明図である。
【図３２】図３２は、プローバー情報の具体例を示す説明図である。
【図３３】図３３は、波形ダンプの具体例を示す説明図である。
【図３４】図３４は、シミュレーション装置９００のシミュレーション処理手順の一例を示すフローチャートである。
【図３５】図３５は、シミュレーションの実行結果の解析例を示す説明図である。
【図３６】図３６は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図（その１）である。
【図３７】図３７は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図（その２）である。
【図３８】図３８は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図（その３）である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、本発明にかかるシミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路の実施の形態を詳細に説明する。
【００１２】
（シミュレーション方法の一実施例）
実施の形態にかかるシミュレーション方法の一実施例について説明する。本実施の形態では、ＥＳＬなどのＲＴＬよりも抽象度が高いレベルでのシステムの性能を評価するシミュレーション方法について説明する。
【００１３】
評価対象となるシステムは、例えば、複数のハードウェアブロックとメモリとがバスを介して接続されるシステムである。また、シミュレーションは、各ハードウェアブロックがバスにトランザクションを投げた際のバスの混み具合から、システムの性能が破綻しないかどうかを評価するためのものである。
【００１４】
ここでは、まず、ネットリストエミュレーションの結果を利用して、システム内の各ハードウェアブロックのタスクの実行状況とバス流量との関係について説明する。
【００１５】
図１は、タスクの実行状況とバス流量との関係を示す説明図である。図１において、グラフ１１０，１２０は、過去品種のＲＴＬ設計データを結合したＳｏＣシミュレーション環境から抽出した各ハードウェアブロックのタスクの実行状況とバス流量との関係を示している。
【００１６】
バス流量とは、バスを介して各ハードウェアブロックに入出力されるデータ量である。グラフ１１０，１２０の波形は２．５秒程度あり、グラフ１２０の１点は６［ｍｓ］程度の幅があり、この区間の流量率（例えば、［ｂｐｓ／ｓｅｃ］）が記載されている。図１中、ＤＳＣ１、ＡＦＮ、ＲＥＣ０、ＪＰＥＧは、ハードウェアブロックの名称を表している。
【００１７】
グラフ１１０，１２０によれば、タスクの実行状況に応じて全体のバス帯域の使用量が変化していることがわかる。また、各々のタスクの実行期間においては、バス流量の波形が、矩形に近い波形になっていることがわかる。また、例えば、ＲＥＣ０やＪＰＥＧが動作すると、ＡＦＮやＲＥＣ０のバス流量は、１／２以下になっていることがわかる。
【００１８】
これらのことから、バス流量は各ハードウェアブロックの計算量と比例関係にあり、同一の利用状況でのバスの使われ方は定常状態（矩形的）になると仮定することができる。また、どの実行状況においても定常状態になると仮定すると、バスの周辺のハードウェアブロックはサンプリング期間全体でみると、定期的なアクセスをしていると仮定することができる。また、バス帯域の使用量がほかの実行期間よりも小さくなっている区間は、バス帯域が不足している期間であると仮定することができる。
【００１９】
そこで、本実施の形態では、バス部分とメモリ部分（例えば、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））については、ある程度正確にモデル化するために、既存のバスモデルとメモリモデルを利用する。
【００２０】
データ量が多いアプリケーションに対する論理設計では、ＤＲＡＭアクセスの連続性を保証できるように設計される。このため、バス部分は、例えば、初期アドレスとオーバーヘッドと論理的なバースト長（ＤＲＡＭがサポートしているバースト長より長い）とで定義できる。また、ＤＲＡＭ部分は、仕様書よりモデル化できるため、ＤＲＡＭの転送を模擬するバスモデルを作成する。
【００２１】
なお、以下の説明では、ハードウェアブロックを単に「ブロック」と表記する場合がある。また、バスの利用権を取得できるブロックを「イニシエータ」と表記し、イニシエータによってデータを送られたり取られたりするブロックを「ターゲット」と表記する場合がある。
【００２２】
また、本実施の形態では、バスモデルを介してメモリモデルにアクセスして計算処理を行うブロックとして、指定サイズ分のデータのリード／ライトを行い、指定サイクル分の遅延時間を発生させて計算時間を再現する計算モデルを用いる。また、開発者は、各ブロックのタスクの実行状況を表現するためにシナリオを定義する。
【００２３】
シナリオは、起動したいブロックごとに、以下の処理を行う。具体的には、シナリオは、ブロックに対して、一連の処理で行われる計算回数、１回当たりの平均計算サイクル数、１回当たりの平均リードデータ量、１回当たりの平均ライトデータ量および周期を与えて、そのブロックに起動信号を送る。また、シナリオは、起動信号を送ったブロックからの終了信号を検出して、シナリオの変更を行い所望の処理を実現する。
【００２４】
ここで、一連の処理は、開発者が一つの連続した処理とみなす処理の集まりである。一連の処理の単位は、開発者の立場やアプリケーションによって異なる。例えば、動画像処理の開発者であれば、１画面分の画像データ（１フレーム）の処理を一連の処理とみなしたり、１マクロブロック（フレームを構成する画像を細分化した処理単位）の処理を一連の処理とみなす場合がある。
【００２５】
また、一連の処理で行われる計算回数は、一連の処理に対する計算回数である。上述したように、一連の処理は、開発者の立場によってどの粒度を処理単位とするかが変わる。例えば、１フレームの処理を一連の処理とみなす場合、ブロックは、１フレームの中で何度もバスにアクセスをして、そのブロックの処理に必要なデータを取得して計算をする。このため、一連処理に対して複数回の計算が行われる。アーキテクチャシミュレーションしてバス性能を見積もる場合、「一連処理に対して何回計算した場合のバス性能はどれくらい出るのか？」という設問を立てる。ここでは、このような場合の一連の処理に対する計算回数を「一連処理で行われる計算回数」と呼ぶ。
【００２６】
また、一回当たりの平均計算サイクル数は、一回の計算処理にかかるサイクル数の平均値である。一連の処理では複数回の計算が行われ、計算にかかるサイクル数はばらつくものであるが、ここでは、一回当たりの平均計算サイクル数は、例えば、アーキテクチャシミュレーション環境の利用者によって任意に設定される。例えば、後述するパラメータｄｅｌａｙに与える値が、一回当たりの平均計算サイクル数を使って求めた値になる。
【００２７】
また、１回当たりの平均リードデータ量は、一回の計算処理にかかるリードデータの平均値である。一連の処理では複数回の計算が行われ、計算ごとに読み込むデータのサイズは異なるものであるが、ここでは、１回当たりの平均リードデータ量は、例えば、アーキテクチャシミュレーション環境の利用者によって任意に設定される。例えば、後述するパラメータｃｏｕｎｔに与える値が、一回当たりの平均リードデータ量を使って求めた値になる。
【００２８】
また、１回当たりの平均ライトデータ量は、一回の計算処理にかかるライトデータの平均値である。一連の処理では複数回の計算が行われ、計算ごとに書き込むデータのサイズは異なるものであるが、ここでは、１回当たりの平均ライトデータ量は、例えば、アーキテクチャシミュレーション環境の利用者によって任意に設定される。
【００２９】
また、周期は、周辺ブロックの動作周波数である。周辺ブロックの動作周波数を変更する場合、プロセッサから設定レジスタに所定の値を書き込むことによって処理される。すなわち、周期は、アーキテクチャシミュレーションではシナリオから制御されるべきものになる。パラメータ名としては、例えば、後述するｐｅｒｉｏｄに当たる。
【００３０】
このようにシナリオを実現するブロックと計算を行うブロックとの間では、起動と終了を扱う通信が必要になる。このため、開発者は、シナリオを実現するブロックと計算を行うブロックとの間の通信を行う部品を定義する。
【００３１】
図２は、ｓｔａｒｔ＿ｄｏｎｅの記述例を示す説明図である。図２において、ｓｔａｒｔ＿ｄｏｎｅ記述２００は、シナリオを実現するブロック（シナリオブロック）と計算を行うブロック（計算ブロック）との間の通信を行うための部品の記述例である。ｓｔａｒｔ＿ｄｏｎｅ記述２００によれば、シナリオブロックと計算ブロックとの間の通信を実現することができる。また、ｓｔａｒｔ＿ｄｏｎｅ記述２００は、起動と終了のプロトコルでモデル化したいブロックの関係を表現したい場合に利用することができる。
【００３２】
図３は、計算ブロックの一例を示す説明図である。図３において、計算ブロックＢは、読込部Ｐ１と、計算部Ｐ２と、書込部Ｐ３と、を含む。読込部Ｐ１は、シナリオブロックから指定された、計算回数分、シナリオブロックから指定されたデータサイズのリードを行い、１回ごとに、計算部Ｐ２を起動する。
【００３３】
計算部Ｐ２は、シナリオブロックから指定された遅延時間分経過して書込部Ｐ３にデータを送る。書込部Ｐ３は、シナリオブロックから指定されたデータサイズのデータを送出する。読込部Ｐ１、計算部Ｐ２および書込部Ｐ３の各々は、ｓｔａｒｔ＿ｄｏｎｅのプロトコル（例えば、図２参照）で接続されている。
【００３４】
また、読込部Ｐ１は、計算部Ｐ２がｄｏｎｅであればデータを読み、計算部Ｐ２を起動する。計算部Ｐ２は、書込部Ｐ３をｓｔａｒｔして、ｄｏｎｅになったら自らもｄｏｎｅにするモデルである。これにより、バスの混雑による処理性能の低下を再現することができる。
【００３５】
また、読込部Ｐ１は、シナリオブロックからのｓｔａｒｔ＿ｄｏｎｅ＿ｔ信号を受け取って、シナリオブロックから指定された計算回数分の読み込みを行ったら、起動信号に最終起動フラグを付して計算部Ｐ２に送る。この場合、計算部Ｐ２は、書込部Ｐ３に起動をかける際に起動信号に最終起動フラグを付して送り、書込部Ｐ３は、シナリオブロックへｄｏｎｅ（終了信号）を返す。これにより、計算部Ｐ２の遅延について、バスの競合による遅延を考慮に入れた遅延を算出することができる。
【００３６】
図４は、計算ブロックの記述例を示す説明図である。図４において、計算ブロック記述４００は、計算ブロックＢ（図３参照）の動作を実現するための記述例である。開発者は、計算ブロック記述４００のようなブロックモデルを作成してＤＢ（データベース）に登録しておくことにより、シミュレーションを行う際に計算ブロック記述４００を再利用することができる。
【００３７】
図５は、リードインターフェースの記述例を示す説明図である。図５において、リードインターフェース記述５００は、イニシエータ（例えば、計算ブロックＢ）のリードインターフェースを実現するための記述例である。開発者は、リードインターフェース記述５００のようなインターフェースモデルを作成してＤＢに登録しておくことにより、シミュレーションを行う際にリードインターフェース記述５００を再利用することができる。なお、ライトインターフェースについても同様である。
【００３８】
図６は、アーキテクチャモデルの具体例を示す説明図である。図６において、アーキテクチャモデル６００は、シナリオブロックＳＢと、計算ブロックＢ１と、計算ブロックＢ２と、計算ブロックＢ３と、バスモデルＢＭと、メモリモデルＭＭと、を含む。アーキテクチャモデル６００では、計算ブロックＢ１〜Ｂ３の各々の計算ブロックＢが、バスモデルＢＭと通信する。
【００３９】
シナリオブロックＳＢは、計算ブロックＢ１〜Ｂ３に起動信号を発行するとともに、計算ブロックＢ１〜Ｂ３からの終了信号を検出するブロックである。シナリオブロックＳＢは、例えば、アーキテクチャモデル６００の全体を制御するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）に相当する。
【００４０】
また、シナリオブロックＳＢは、シナリオ（例えば、後述する図７に示すシナリオ記述７００）に基づいて、各計算ブロックＢ１〜Ｂ３に各種パラメータを設定する。各種パラメータは、例えば、上述した、一連の処理で行われる計算回数、一回当たりの平均計算サイクル数、１回当たりの平均リードデータ量、１回当たりの平均ライトデータ量、周期である。
【００４１】
計算ブロックＢ１〜Ｂ３は、バスモデルＢＭを介してメモリモデルＭＭにアクセスして計算処理を行う周辺ブロックである。具体的には、例えば、計算ブロックＢ１の読込部Ｐ１（図３参照）は、シナリオブロックＳＢからのｓｔａｒｔ＿ｄｏｎｅ＿ｔ信号を受けると、指定された計算回数分（例えば、１０００回）、指定されたデータサイズ（例えば、５０バイト）のデータを読み込む。読込部Ｐ１は、１回の読込処理が完了したら計算部Ｐ２（図３参照）に起動信号を送る。
【００４２】
より具体的には、例えば、読込部Ｐ１は、バスモデルＢＭのＲｅａｄ関数（読み込むデータのデータ量も指定）を呼び出して、Ｒｅａｄ関数が抜けたことをもって、読込処理が終了したことを検出し、ｄｏｎｅイベントを発行する。Ｒｅａｄ関数は、データを書き込んだ後に抜けるようになっている。
【００４３】
計算部Ｐ２は、読込部Ｐ１から起動信号を受けると、計算ブロックＢの動作周波数に基づいて、指定された遅延時間分経過したら、書込部Ｐ３（図３参照）に起動信号を送る。例えば、指定された遅延時間を１００サイクルとし、各計算ブロックＢ１〜Ｂ３の動作周波数（周期）を１０００Ｈｚとする。この場合、計算部Ｐ２は、読込部Ｐ１から起動信号を受けると、０．１秒（＝１００／１０００）経過したら、書込部Ｐ３に起動信号を送る。
【００４４】
書込部Ｐ３は、計算部Ｐ２から起動信号を受けると、指定されたデータサイズ（例えば、１００バイト）のデータを書き込む。より具体的には、例えば、書込部Ｐ３は、バスモデルＢＭのＷｒｉｔｅ関数（書き込むデータのデータ量も指定）を呼び出して、Ｗｒｉｔｅ関数が抜けたことをもって、書込処理が終了したことを検出し、ｄｏｎｅイベントを発行する。Ｗｒｉｔｅ関数は、データを書き込んだ後に抜けるようになっている。
【００４５】
バスモデルＢＭは、計算ブロックＢ１〜Ｂ３とメモリモデルＭＭとを接続するとともに各計算ブロックＢ１〜Ｂ３からメモリモデルＭＭへのアクセスを制御する。具体的には、例えば、バスモデルＢＭは、バスの機能とメモリコントローラの機能とを有する（ＢＵＳ＋ＤＲＡＭ  Ｉｎｔｅｒｆａｃｅ）。メモリモデルＭＭは、例えば、ＤＲＡＭモデルである。
【００４６】
より具体的には、例えば、バスモデルＢＭは、Ｗｒｉｔｅ関数が呼び出されると、メモリモデルＭＭに対してデータ（例えば、オールゼロのデータ）を書き込んで、データのサイズ分の遅延（例えば、１０サイクル）を発生させてＷｒｉｔｅ関数を終わる。すなわち、バスモデルＢＭは、ブロッキングの関数コールでディレイを発生させて関数を抜ける。
【００４７】
ここで、シナリオブロックＳＢが計算ブロックＢ１〜Ｂ３を同時に起動して、計算ブロックＢ１〜Ｂ３のすべての処理が終わったらシミュレーションを終了するシナリオを例に挙げて、シナリオブロックＳＢのシナリオ記述例について説明する。
【００４８】
図７は、シナリオブロックＳＢのシナリオ記述例を示す説明図である。図７において、シナリオ記述７００は、計算ブロックＢ１，Ｂ２，Ｂ３（図７中、０，１，２）を同時に起動して、計算ブロックＢ１〜Ｂ３のすべての処理が終わったらシミュレーションを終了するシナリオである。
【００４９】
具体的には、例えば、シナリオ記述７００には、各計算ブロックＢ１〜Ｂ３に設定される、一連の処理で行われる計算回数、一回当たりの平均計算サイクル数、１回当たりの平均リードデータ量、１回当たりの平均ライトデータ量および周期が記述されている。シナリオブロックＳＢと各計算ブロックＢ１〜Ｂ３には、パラメータを送る信号線ｐｅｒｉｏｄ，ｄｅｌａｙ，ｃｏｕｎｔがある。
【００５０】
ｐｅｒｉｏｄは、各計算ブロックＢ１〜Ｂ３の動作周波数である。ｄｅｌａｙは、各計算ブロックＢ１〜Ｂ３の計算部Ｐ２の遅延である。ｃｏｕｎｔは、各計算ブロックＢ１〜Ｂ３の計算処理の回数、すなわち、各計算ブロックＢ１〜Ｂ３の読込部Ｐ１の読み込み回数である。
【００５１】
シナリオ記述７００によれば、シナリオブロックＳＢは、各計算ブロックＢ１〜Ｂ３に各種パラメータを設定して、各計算ブロックＢ１〜Ｂ３に同時に起動信号を発行し、すべての計算ブロックＢ１〜Ｂ３から終了信号を検出するのを待つことになる（ｄｏ〜ｗｈｉｌｅ文）。
【００５２】
図８は、結合記述例を示す説明図である。図８において、結合記述８００は、図６に示したようなブロック間の結合をモデル化して表すアーキテクチャシミュレーション記述である。ここでは、バス競合の再現に十分な精度を持った計算ブロックＢ１〜Ｂ３を定義し、シナリオブロックＳＢとの通信の仕方を決めたことにより、全体の結合網をコンパクトして結合記述８００のように記述を単純化し工数を削減することができる。
【００５３】
（シミュレーション装置９００のハードウェア構成例）
つぎに、実施の形態にかかるシミュレーション装置９００のハードウェア構成例について説明する。図９は、シミュレーション装置９００のハードウェア構成例を示すブロック図である。図９において、シミュレーション装置９００は、ＣＰＵ９０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）９０２と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９０３と、磁気ディスクドライブ９０４と、磁気ディスク９０５と、光ディスクドライブ９０６と、光ディスク９０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）９０８と、ディスプレイ９０９と、キーボード９１０と、マウス９１１と、を有している。また、各構成部はバス９１２によってそれぞれ接続されている。
【００５４】
ここで、ＣＰＵ９０１は、シミュレーション装置９００の全体の制御を司る。ＲＯＭ９０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ９０３は、ＣＰＵ９０１のワークエリアとして使用される。磁気ディスクドライブ９０４は、ＣＰＵ９０１の制御に従って磁気ディスク９０５に対するデータのリード／ライトを制御する。磁気ディスク９０５は、磁気ディスクドライブ９０４の制御で書き込まれたデータを記憶する。
【００５５】
光ディスクドライブ９０６は、ＣＰＵ９０１の制御にしたがって光ディスク９０７に対するデータのリード／ライトを制御する。光ディスク９０７は、光ディスクドライブ９０６の制御で書き込まれたデータを記憶したり、光ディスク９０７に記憶されたデータをコンピュータに読み取らせたりする。
【００５６】
Ｉ／Ｆ９０８は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク９２０に接続され、ネットワーク９２０を介して他の装置に接続される。そして、Ｉ／Ｆ９０８は、ネットワーク９２０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ９０８には、例えば、モデムやＬＡＮアダプタなどを採用することができる。
【００５７】
ディスプレイ９０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ９０９は、例えば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００５８】
キーボード９１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス９１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
【００５９】
なお、シミュレーション装置９００は、上述した構成のうち、例えば、光ディスクドライブ９０６や光ディスク９０７を有さないことにしてもよい。また、シミュレーション装置９００は、上述した構成部のほかに、例えば、スキャナやプリンタを有することにしてもよい。
【００６０】
（シミュレーション装置９００の機能的構成例）
図１０は、シミュレーション装置９００の機能的構成例を示すブロック図である。図１０において、シミュレーション装置９００は、取得部１００１と、生成部１００２と、実行部１００３と、出力部１００４と、を含む構成である。取得部１００１〜出力部１００４は制御部となる機能であり、具体的には、例えば、図９に示したＲＯＭ９０２、ＲＡＭ９０３、磁気ディスク９０５、光ディスク９０７などの記憶装置に記憶されたプログラムをＣＰＵ９０１に実行させることにより、または、Ｉ／Ｆ９０８により、その機能を実現する。また、各機能部の処理結果は、例えば、ＲＡＭ９０３、磁気ディスク９０５、光ディスク９０７などの記憶装置に記憶される。
【００６１】
取得部１００１は、評価対象となるシステムのアーキテクチャモデルを取得する機能を有する。ここで、アーキテクチャモデルは、シナリオブロックＳＢと、複数の計算ブロックＢ（例えば、上述した計算ブロックＢ１〜Ｂ３）と、バスモデルＢＭと、メモリモデルＭＭと、を含む。
【００６２】
シナリオブロックＳＢは、複数の計算ブロックＢに起動信号を発行するとともに複数の計算ブロックＢからの終了信号を検出する。バスモデルＢＭは、複数の計算ブロックＢとメモリモデルＭＭとを接続するとともに計算ブロックＢからメモリモデルＭＭへのアクセスを制御する。計算ブロックＢは、バスモデルＢＭを介してメモリモデルＭＭにアクセスして計算処理を行う。
【００６３】
具体的には、例えば、アーキテクチャモデルは、例えば、周辺ブロック記述と、アーキテクチャシミュレーション記述と、を含む。周辺ブロック記述は、評価対象となるシステムに含まれる計算ブロックＢの記述情報である。周辺ブロック記述は、例えば、図４に示した計算ブロック記述４００や図５に示したリードインターフェース記述５００を含む。
【００６４】
また、周辺ブロック記述は、例えば、開発者により、ＤＢに登録されているブロックモデルやインターフェースモデル等を再利用または組み合わせることにより作成される。ＤＢから周辺ブロック記述を作成できない場合は、開発者により、一から周辺ブロック記述が記述される。
【００６５】
アーキテクチャシミュレーション記述は、例えば、図２に示したｓｔａｒｔ＿ｄｏｎｅ記述２００、図８に示した結合記述８００、後述の図１６に示すアービトレーションモデル１６００などを含む。なお、結合記述８００は、後述の図２２〜図２４に示すイニシエータとターゲットをｒｏｕｔｅ＿ｎ＿１＿ｔで接続した結合記述に置き換えることにしてもよい。
【００６６】
また、取得部１００１は、評価対象となるシステムのシナリオ記述を取得する機能を有する。シナリオ記述は、計算ブロックＢごとに、一連の処理で行われる計算処理の回数と、計算処理にかかるサイクル数と、計算処理にかかるリードデータ量と、計算処理にかかるライトデータ量と、計算ブロックＢの動作周波数と、を示す情報である。シナリオ記述は、例えば、図７に示したシナリオ記述７００である。
【００６７】
また、取得部１００１は、評価対象となるシステムのプローバー記述を取得する機能を有する。プローバー記述は、例えば、計算ブロックＢの仕様に依存する状態値をダンプするために状態を指定する情報である。プローバー記述は、例えば、後述の図３０に示すプローバー記述３０００である。
【００６８】
生成部１００２は、システムの性能を評価するシミュレーションの実行ファイルを生成する機能を有する。具体的には、例えば、生成部１００２は、取得された周辺ブロック記述、プローバー記述、アーキテクチャシミュレーション記述およびシナリオ記述に基づいて、シミュレーションの実行ファイル（バイナリ）を生成する。
【００６９】
より具体的には、例えば、生成部１００２は、ＡＳｉｍＬｉｂｒａｒｙとともに周辺ブロック記述、プローバー記述、アーキテクチャシミュレーション記述およびシナリオ記述をコンパイルすることにより、シミュレーションの実行ファイルを生成する。なお、ＡＳｉｍＬｉｂｒａｒｙは、ＳｙｓｔｅｍＣの拡張機能を記述したものである。
【００７０】
実行部１００３は、生成されたシミュレーションの実行ファイルを実行する機能を有する。実行ファイルが実行されるとシミュレーションが行われ、シミュレーションの実行結果が得られる。シミュレーションの実行結果は、例えば、結線データと、計測コンフィギュレーションデータと、計測データとを含む。
【００７１】
結線データは、部品の結線関係を示すデータである。結線データは、アーキテクチャ情報を他のツールに渡せるようにしたコンピュータリーダブルな情報である。例えば、結線データは、後述の図２８に示す部品情報２８００（ｐａｒｔｓ．ｘｍｌ）である。計測コンフィギュレーションデータは、計測データのＩＤ番号と実体の関係を示すデータである。例えば、計測コンフィギュレーションデータは、後述の図３１に示すコンフィギュレーション情報一覧３１００（ｃｏｎｆ．ｘｍｌ）である。計測データは、状態変化の履歴などの計測結果を記載したデータである。例えば、計測データは、後述の図３２に示すプローバー情報３２００（ｐｒｏｂｅ．ｃｓｖ）である。
【００７２】
出力部１００４は、シミュレーションの実行結果を出力する。出力部１００４の出力形式としては、例えば、ＲＡＭ９０３、磁気ディスク９０５、光ディスク９０７などの記憶装置への記憶、Ｉ／Ｆ９０８による外部装置への送信、ディスプレイ９０９への表示などがある。
【００７３】
（シミュレーションの実行例）
ここで、シナリオ記述７００に基づく、アーキテクチャモデル６００（図６参照）のシミュレーションの実行例について説明する。
【００７４】
図１１は、シミュレーションの実行例を示す説明図である。図１１において、グラフ１１０１，１１０２，１１０３は、各計算ブロックＢ１，Ｂ２，Ｂ３（図１１中、ＩＰ０，ＩＰ１，ＩＰ２）の実行状況を示すグラフである。図１１中、Ｒは、ラン状態を表し、ＳＴは、ストール状態を表し、Ｉは、アイドル状態を表し、ＳＬは、スリープ状態を表す。
【００７５】
グラフ１１０１〜１１０３によれば、各計算ブロックＢ１，Ｂ２，Ｂ３のストール状態が表されており、バスの競合が再現することができていることがわかる。また、各計算ブロックＢ１，Ｂ２，Ｂ３が指定回数分の処理を終えて、ｄｏｎｅフラグのｊｏｉｎがとれて終了していることが分かる。
【００７６】
（バスの汎用化）
上述した説明では、バスモデルＢＭとして既存のモデルを用いる場合について説明したが、バスには様々な種類があり、いずれの種類にも対応するバスモデルを用意するにはコストがかかってしまう。そこで、以下の説明では、バスの汎用化について説明する。
【００７７】
まず、バスプロトコルについて説明する。本バスプロトコルでは「データ発送」という処理を定義する。データ発送は、データを転送する処理である。そして、ライトアクセスを「データ発送」でモデル化する。また、リードアクセスを「データ発注書」のデータ発送と「発注されたデータ」のデータ発送とでモデル化する。すなわち、リードアクセスを、ターゲットに「データ発注書」を行い、ターゲットが「発注されたデータ発送」を行う一連の処理として解釈する。
【００７８】
具体的には、例えば、バスモデルＢＭは、計算ブロックＢに設定されたライトデータ量のデータの転送要求を計算ブロックＢから受け付けると、ライトデータ量のデータをメモリモデルＭＭに書き込む。
【００７９】
また、バスモデルＢＭは、計算ブロックＢからデータ発注書の転送要求を受け付けると、データ発注書をメモリモデルＭＭに書き込む。データ発注書には、計算ブロックＢに設定されたリードデータ量が記述されている。メモリモデルＭＭは、バスモデルＢＭによってデータ発注書が書き込まれると、データ発注書に記述されたリードデータ量のデータをバスモデルＢＭに書き込む。バスモデルＢＭは、メモリモデルＭＭによってリードデータ量のデータが書き込まれると、計算ブロックＢに、書き込まれたリードデータ量のデータを送信する。
【００８０】
以下、バスモデルＢＭのバスプロトコルの一例について説明する。なお、バスモデルと書いたがこれらの仕様に基づいたバスを実際の設計で用いるとしてもよい。以下に示すバスプロトコルは、Ｐａｃｋ信号線とＣｏｎｔｅｎｔｓ信号線によるシンプルで単純な信号線構成になっており、一部データの解釈で制御情報（アドレス値など）を取り出す機構になっており、アドレス線とデータ線を区別する一般的なオンチップバスとは大きく異なっている。したがって、このような性質が適したアプリケーションである場合や回路の自動生成のため単純化が望まれる場合であれば、このバスモデルを回路として利用することもあり得る。したがって，本バスモデルは設計で用いられるバス回路を含む広義のバスモデルであると考えてよい。
【００８１】
図１２は、バスプロトコルの一例を示す説明図（その１）である。図１２において、バスプロトコル１２００は、データのビットの意味を定義するものである。宛先は、３２ビットデータである。宛先のうちの最上位ビット、すなわち、３１ビット目は、転送のタイプがＬｅｔｔｅｒ型（手紙型）かＰａｒｃｅｌ型（小包型）かを示している。
【００８２】
Ｌｅｔｔｅｒ型は、発注書などを送る転送のタイプである。Ｐａｒｃｅｌ型は、実データを送る転送のタイプである。Ｌｅｔｔｅｒ型は最上位ビットの値が「０」であり、Ｐａｒｃｅｌ型は最上位ビットの値が「１」である。
【００８３】
また、最上位ビットの値が「１（Ｐａｒｃｅｌ型）」の場合、３０ビット目はアップロード「０」またはダウンロード「１」を示す。３０ビット目の値が「０（アップロード）」の場合、２９ビット目〜０ビット目は、送り先のアドレスと解釈される。一方、３０ビット目の値が「１（ダウンロード）」の場合、２９ビット目〜１６ビット目は、リザーブされており（例えば、０詰めされる）、この部分の値は解釈されない。１５ビット目〜０ビット目は、イニシエータのＩＤ番号が格納される。
【００８４】
また、最上位ビットの値が「０（Ｌｅｔｔｅｒ型）」の場合、３０ビット目はリザーブされ利用されない。また、２９ビット目〜０ビット目は送り先のアドレス（ターゲットアドレス）である。
【００８５】
発注書は、１ワード（３２ビット）データで、上位２バイトはデータを送り返すイニシエータのＩＤ番号であり、下位２バイトは送り返すデータのサイズである。ターゲットは、ターゲットアドレスで指定されたアドレスから発注書に記載されたサイズ分のデータを転送する。
【００８６】
バスプロトコル１２００によれば、データ転送を基本とするバストランザクションを定義することができる。これにより、アーキテクチャモデルでも同様にデータ転送（ライトアクセス）をモデル化すれば、所望のバストランザクションの説明ができることになる。また、バスプロトコル１２００と実際のバスプロトコルとを比較することにより、性能の概算を行うことが可能になる。
【００８７】
図１３は、バスプロトコルの一例を示す説明図（その２）である。図１３において、バスプロトコル１３００は、データのビットの意味を定義するものである。宛先は、３２ビットデータである。宛先のうちの３１ビット目〜３０ビット目は、転送のタイプを示している。
【００８８】
転送のタイプとしては、Ｌｅｔｔｅｒ型、Ｐａｒｃｅｌ型、Ｐａｒｃｅｌ  Ｗｉｔｈ  ＲｅｐｏｒｔＲｅｑｕｅｓｔ型、Ｒｅｐｏｒｔ型の４種類があり、各々に０，１，２，３の値が割り当てられている。また、３の場合には宛先を入荷報告という。
【００８９】
３１ビット目〜３０ビット目の値が「０（Ｌｅｔｔｅｒ型）」の場合、３０ビット目はリザーブされ、この部分の値は解釈されない。また、２９ビット目〜０ビット目は送り先のアドレス（ターゲットアドレス）である。
【００９０】
また、３１ビット目〜３０ビット目の値が「１（Ｐａｒｃｅｌ型）」の場合、２９ビット目はアップロード「０」またはダウンロード「１」を示す。２９ビット目の値が「０（アップロード）」の場合、２８ビット目〜０ビット目は送り先のアドレス（ターゲットアドレス）である。一方、２９ビット目の値が「１（ダウンロード）」の場合、２８ビット目〜１０ビット目はリザーブされ、この部分の値は解釈されない。９ビット目〜０ビット目は、イニシエータのＩＤ番号が格納される。
【００９１】
また、３１ビット目〜３０ビット目の値が「２（Ｐａｒｃｅｌ  Ｗｉｔｈ  ＲｅｐｏｒｔＲｅｑｕｅｓｔ型）」または「３（Ｒｅｐｏｒｔ型）」の場合、２８ビット目〜１０ビット目はリザーブされ、この部分の値は解釈されない。９ビット目〜０ビット目は、レポートを送付する先のＩＤ番号が書かれる。
【００９２】
発注書は、３１ビット目〜２６ビット目まではリザーブされ、２５ビット目〜１６ビット目まではデータを送り返すイニシエータのＩＤ番号であり、１５ビット目〜０ビット目は送り返すデータのサイズである。
【００９３】
入荷報告送付先書は、３１ビット目が次のデータセルがデータか、それとも入荷報告書の続きかを示す。「０」の場合は入荷報告書が続き、「１」の場合は入荷報告書が終わり、次からデータが続くことを示す。２９ビット目〜０ビット目は１０ビットずつ３個の入荷報告先を記載できる。「０」を欠番とし、「０」が書かれている場合には無効なＩＤ番号として無視される。
【００９４】
バスプロトコル１３００によれば、小包（データ）が届いたことを別のイニシエータに送信することができ、データの移動によって制御が発生する場合に適用できる。なお、図１２および図１３では、コンテンツ線の幅が３２ビットの場合を例に挙げて説明したが、コンテンツ線の幅を１６ビット幅にした場合には、宛先を２ワードとし、１データ当たり２ワードにすればよい。
【００９５】
（アービトレーション）
つぎに、アービトレーションについて説明する。アービトレーションは、複数の計算ブロックがバスを占有しないように調停する回路である。ここでは、転送経路の排他性を制御するアービトレーション（Ｒｏｕｔｅ  Ａｒｂｉｔｒａｔｉｏｎ）と、リソースの排他性を制御するアービトレーション（Ｒｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎ）とを用いる。
【００９６】
また、ゴールのリソースの占有権をとるかとらないかを決める必要がある場合がある。この場合の調停戦略としては、例えば、ゴールのネゴシエーションを行ってから転送を開始するパターンと、ローカルのネゴシエーションを進めていきゴールに近づいていくパターンとがある。なお、アービトレーションの必要がない場合は、ｎｏｎ−ａｒｂｉｔｒａｔｉｏｎによりアービトレーションしない。
【００９７】
図１４は、アービトレーションの回路例を示す説明図である。図１４において、転送機構１４００は、Ｒｏｕｔｅ  ＡｒｂｉｔｒａｔｉｏｎとＲｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎとを実現する回路例である。転送機構１４００は、４チャネル転送コネクタ１４１０と２チャネル転送コネクタ１４２０とを有する。４チャネル転送コネクタ１４１０と２チャネル転送コネクタ１４２０は、結合網１４３０によって結合されている。
【００９８】
４チャネル転送コネクタ１４１０は、データ受信部１４１１と、データ送信部１４１２と、バッファ０〜３とを有する。２チャネル転送コネクタ１４２０は、データ受信部１４２１と、データ送信部１４２２と、バッファ０，１とを有する。結合網１４３０は、Ｒｏｕｔｅ  Ａｒｂｉｔｒａｔｉｏｎの対象となる。バッファ０〜３と、バッファ０，１は、Ｒｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎの対象となる。
【００９９】
（トリッププラン）
つぎに、トリッププランについて説明する。トリッププランは、ネゴシエーターのリストであり、目的地（例えば、ターゲット）までのルートを表している。
【０１００】
図１５は、トリッププランの回路例を示す説明図である。図１５において、トリッププラン１５００は、ネゴシエーター１５０１〜１５０４を有する。各ネゴシエーター１５０１〜１５０４は、バッファとアクセス部分とを有する。
【０１０１】
荷物（Ｐａｒｃｅｌ型のデータ）や手紙（Ｌｅｔｔｅｒ型のデータ）は、ネゴシエーター１５０１〜１５０４の中のバッファを利用しながら目的地まで転送される。各ネゴシエーター１５０１〜１５０４のアクセス部分は、次の宿営地（例えば、次のネゴシエーターのバッファ）に移れるかをアービターに対してネゴシエーションする部分である。アービターから許可が出れば、荷物や手紙は次の宿営地に移動する。
【０１０２】
図１６は、アービトレーションモデルの具体例を示す説明図である。図１６において、アービトレーションモデル１６００において、ネゴシエーター間の荷物や手紙の移動は、移動元のネゴシエーターが、移動先のネゴシエーターが属しているアービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）に対して予約を行うことにより実現される。
【０１０３】
具体的には、アービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）は、リソース数を管理しており、空きリソースがあれば、移動元のネゴシエーターに許可を出す。一方、アービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）は、空きリソースがなければ保留とし、空きリソースができた段階で、移動元のネゴシエーターに許可を出す。
【０１０４】
また、移動元のネゴシエーターは、アービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）から許可が出れば荷物や手紙を送ることができるため、転送経路の確保を行う。転送経路の確保は、アービター（ｒｏｕｔｅ＿ａｒｂｉｔｅｒ）に対して予約を行うことにより実現される。
【０１０５】
また、移動元のネゴシエーターは、転送経路が確保できたら、荷物や手紙の転送を行う。そして、また、移動元のネゴシエーターは、荷物や手紙の転送が完了すると、移動元のネゴシエーターのバッファは空になるので、移動元のネゴシエーターが属するアービターに対して、ｃｈｅｃｋｏｕｔを伝えてリソースを解放する。
【０１０６】
図１７は、データの転送例を示す説明図である。図１７において、Ｎ番目のネゴシエーターから（Ｎ＋１）番目のネゴシエーターにトークン（データ）が転送される転送例が示されている。トークンは、例えば、タイプ、発注書、データバイト数、通過部品履歴等を含むデータである。
【０１０７】
図１７の転送例では、まず、Ｒｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎにより、転送経路１７０１，１７０２がリソースを確保する。つぎに、Ｒｏｕｔｅ  Ａｒｂｉｔｒａｔｉｏｎにより、転送経路１７０１が選択される。
【０１０８】
そして、転送経路１７０１が選択された結果、Ｎ番目のネゴシエーターから（Ｎ＋１）番目のネゴシエーターにトークンがバス転送時間をかけて移動する。具体的には、例えば、Ｎ番目のネゴシエーターが、（Ｎ＋１）番目のネゴシエーターにデータを書き込んだ後、所定時間を経過したら、アービターに対して転送経路１７０１の解放を通知する。
【０１０９】
このように、トリッププランで発送元（例えば、イニシエータ）と発送先（例えば、ターゲット）とをつなぎ、図１６に示したようにアービターと関連付けることにより、バスの動作を模擬することができる。また、ｎｏｎ−ａｒｂｉｔｒａｔｉｏｎクラスを接続することにより、その部分はリソース制約なしで転送を行うことができる。すなわち、トリッププランという経路によるモデル化により、排他制御のシミュレーションを再現することができる。
【０１１０】
（ｒｏｕｔｅ＿ｎ＿１＿ｔクラス）
つぎに、トリッププランをまとめたセカンダリィな要素として、ｒｏｕｔｅ＿ｎ＿１＿ｔを定義する。ここでは、まず、トリッププランのクラス図について説明する。
【０１１１】
図１８は、トリッププランのクラス図の一例を示す説明図である。図１８において、クラス図１８００は、トリッププランのクラス図である。クラス図１８００では、ｒｏｕｔｅ＿ｎ＿１＿ｔ用にｒｏｕｎｄ＿ｔｒｉｐ＿ｐｌａｎ＿ｔが定義されている。ｒｏｕｎｄ＿ｔｒｉｐ＿ｐｌａｎ＿ｔは、往路用と復路用のトリッププランを梱包している。
【０１１２】
図１９は、ｒｏｕｔｅ＿ｎ＿１＿ｔのクラス図の一例を示す説明図である。図１９において、クラス図１９００は、ｒｏｕｔｅ＿ｎ＿１＿ｔのクラス図である。ｒｏｕｔｅ＿ｎ＿１＿ｔは、ｎ個のイニシエータが１個のターゲットと関係する関係を示すクラスである。ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔは、イニシエータからのアクセスを受けるためのインターフェースである。
【０１１３】
一方、ｒｏｕｔｅ＿ｎ＿１＿ｔは、ターゲット側のインターフェースを兼ねている。ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔは、ｒｏｕｎｄ＿ｔｒｉｐ＿ｐｌａｎ＿ｔを持っている。従って、往路、復路のトリッププランを管理することができる。
【０１１４】
（準備処理の流れ）
ここで、シミュレーション装置９００の準備処理の流れについて説明する。まず、シミュレーション装置９００は、計測データのダンプを起動する。計測データのダンプが起動されると、インスタンスされたモジュールにダンプデータ用のファイルポインタが渡されて、イベント履歴を出力するように設定される。
【０１１５】
つぎに、シミュレーション装置９００は、図９に示したキーボード９１０やマウス９１１を用いたユーザの操作入力により、アーキテクチャの設定を行う。そして、シミュレーション装置９００は、設定されたアーキテクチャを生成する。
【０１１６】
なお、トリッププランの中のネゴシエーターは（＃ａｒｂｉｔｅｒ＋１）／２個インスタンスすることになるが、結線が先に行われてからアービターの設定がなされることがあるため、自動的にインスタンスするフェーズを設ける。また、テンプレートクラスのＭａｎ＿ｔの継承クラスであればｖｉｒｔｕａｌ  ｍａｋｅ（）が呼ばれるようになっているので、このフェーズで作るべき処理をｖｉｒｔｕａｌ  ｍａｋｅ（）の中で書いておけばよい。
【０１１７】
図２０は、ｒｏｕｔｅ＿ｎ＿１＿ｔのｍａｋｅ（）の定義例を示す説明図である。図２０において、定義２０００は、ｒｏｕｔｅ＿ｎ＿１＿ｔのｍａｋｅ（）の定義例である。ｒｏｕｔｅ＿ｎ＿１＿ｔではｉｎｉ（）が呼ばれるたびにｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔのリストとアービターのリストは出来上がっていたが、トリッププランは完成していなかった。これに対して、定義２０００では、トリッププランを作成している。これにより、アーキテクチャの設定の自由度を上げて記述性を向上させている。
【０１１８】
（アーキテクチャのサンプル）
図２１は、アーキテクチャのサンプル例を示す説明図である。図２１において、アーキテクチャ２１００は、Ｂｌｏｃｋ０と、Ｂｌｏｃｋ１と、Ｂ．Ｂと、ｔａｒとを含む。Ｂｌｏｃｋ１には、ライトポートとリードポートがある。ライトポートは、小包の転送を行う。リードポートは、手紙の転送を行う。ｔａｒは、ターゲットである。ｔａｒは、手紙を受け取ると、小包を発送する。
【０１１９】
図２２は、アーキテクチャの接続記述例を示す説明図である。図２２において、トップ記述２２００は、図２１に示したアーキテクチャ２１００の接続記述例である。トップ記述２２００において、ａｒｂｉｔｅｒ＿ｔは３種類あり、ｎｏｒｔｈ，ｃｅｎｔｅｒ，ｓｏｕｔｈがある。
【０１２０】
接続は、ｉｎｓｔ０．ａにａ＿ｂｕｓ．ｉｎｉ（）を渡している。ａ＿ｂｕｓ．ｉｎｉ（）が呼ばれると、ｒｏｕｔｅ＿ｎ＿１＿ｔの中のｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔのベクタコンテナに１個ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔが置かれ、このインターフェースがｉｎｓｔ０．ａに渡される。ｉｎｓｔ０．ｂも同様である。
【０１２１】
つぎに、ｔａｒ０．ａにａ＿ｂｕｓが渡されている。ａ＿ｂｕｓのアービターとして、イニシエータ側からｎｏｒｔｈ，ｃｅｎｔｅｒ，ｓｏｕｔｈを渡している。ｎｏｒｔｈは、Ｂ．Ｂとイニシエータの間の配線のアービターである。ｓｏｕｔｈは、Ｂ．Ｂとターゲットの間の配線のアービターである。ｃｅｎｔｅｒは、Ｂ．Ｂそのもののアービターである。また、宣言時に数字が省略されている場合、リソース数は１である。
【０１２２】
ａｓｉｍ＿ｔ：：ｗａｖｅ＿ｏｎ（）は、「計測データのダンプの起動」である。ａｓｉｍ＿ｔ：：ｓｔａｒｔは、「アーキテクチャの生成」をした後、ｓｃ＿ｓｔａｒｔをするメソッドである。また、ＤＥＣＬは、マクロでＤＥＣＬ（ｎｏｒｔｈ）はｎｏｒｔｈ（“ｎｏｒｔｈ”）に展開される。ここで、周辺の回路記述例について説明する。
【０１２３】
図２３は、イニシエータの回路記述例を示す説明図である。図２３において、回路記述２３００は、イニシエータとなるブロックの回路記述例である。図２４は、ターゲットの回路記述例を示す説明図である。図２４において、回路記述２４００は、ターゲットとなるブロックの回路記述例である。
【０１２４】
図２５および図２６は、状態遷移例を示す説明図である。図２５において、グラフ２５００は、図２２〜図２４に示した各記述例を用いてシミュレーションを実行した場合の各ネゴシエーターの状態遷移を示している。図２５，２６中、ｂＲｅｓはｂｏｏｋＲｅｓｏｕｒｃｅ（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）を表している。ｂＲｏｕはｂｏｏｋＲｏｕｔｅ（ｒｏｕｔｅ＿ａｒｂｉｔｅｒ）を表している。ｍＴｏｋはｍｏｖｅＴｏｋｅｎを表している。
【０１２５】
グラフ２５００では、例えば、カーソル「ＴｉｍｅＡ」から「Ｂａｓｅｌｉｎｅ」までの間、ｃｅｎｔｅｒのアービターが占有されている。また、イニシエータ側の配線を通ってＢ．Ｂ上のバッファに書かれ始めてから、Ｂ．Ｂ上のバッファのデータがターゲットに書き終わるまでの間占有されている。グラフ２５００によれば、ｃｅｎｔｅｒのアービターが混んでいることがわかる。
【０１２６】
グラフ２６００は、センターのリソース数を２に増やした場合の各ネゴシエーターの状態遷移を示している。具体的には、ＤＥＣＬ（ｃｅｎｔｅｒ）をＤＥＣＬ＿ＶＡ（ｃｅｎｔｅｒ，２）にする。グラフ２６００では、Ｂ．Ｂの部分でイニシエータ発行の小包と手紙が同時に停泊したり、イニシエータ発行の小包とターゲット発行の小包が入れ替わったりしている様子が見て取れ、バスの動きを模擬できていることがわかる。
【０１２７】
このように、トリッププランを組み合わせることにより、バスの動作を比較的ショートな記述で書けるようになり生産性を向上させることができる。また、アーキテクチャのモデル化、特に、イベント、転送を示すトークン、転送経路とアービトレーションとリソース数によるイベントベースのシミュレーションが可能な環境を構築することができる。また、これは本モデルが規定するバスがシンプルな構成であることを意味し、バスモデル、および、これを具体化した回路は単純な制御によるデータ転送をすることができる。
【０１２８】
（構造情報の出力）
つぎに、構造情報（アーキテクチャ情報）の出力の実現方法について説明する。ここでは、図２２に示したトップ記述２２００のａｓｉｍ＿ｔ：：ｓｔａｒｔまでに宣言されたアーキテクチャ要素と接続関係を出力する場合を例に挙げて説明する。
【０１２９】
図２７は、構造情報に関するクラス図である。図２７に示すクラス図２７００において、ｓｅｔｕｐ＿ｔは、各種の設定を持つクラスである。ａｓｉｍ＿ｔは、ｓｅｔｕｐ＿ｔをクラス変数に持つクラスである。ａｓｉｍ＿ｔは、ネームスペースとして使用される。Ｍａｎ＿ｒｏｏｔ＿ｔは、管理オブジェクトを管理するルートクラスである。Ｍａｎ＿ｒｏｏｔ＿ｔは、クラス変数として、管理対象名（後述するｃｎａｍｅよりｔｙｐｅｉｄ（ｃｎａｍｅ）で生成）からＭａｎ＿ｉｆ＿ｔの参照へのｍａｐをクラス変数として持つ。
【０１３０】
Ｍａｎ＿ｉｆ＿ｔは、Ｍａｎ＿ｒｏｏｔ＿ｔへのポインタをクラス変数に持つ。Ｍａｎ＿ｔは、ｃｎａｍｅのクラスの管理オブジェクトである。ｃｎａｍｅへのポインタを管理している。また、Ｍａｎ＿ｔは、インスタンスされるとｍ＿ｒｏｏｔにＭａｎ＿ｔ＜ｃｎａｍｅ＞を登録する。Ｍａｎ＿ｔは、ｃｎａｍｅへのポインタのベクタをクラス変数として持つ。
【０１３１】
ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔは、ｃｎａｍｅ→ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔとしたＭａｎ＿ｔの継承クラスである。このクラスがインスタンスされるとＭａｎ＿ｔのｍ＿ｍａｎ＿ｖｅｃｔｏｒに自分自身へのポインタを登録する。ｒｏｕｔｅ＿ｎ＿１＿ｔ，ｐｅｒｉｏｄ＿ｔも同様である。
【０１３２】
Ｍａｎ＿ｒｏｏｔ＿ｔ：：ｒｏｏｔ＿ｔｙｐｅから、全Ｍａｎ＿ｔが検索できる。さらに、Ｍａｎ＿ｔ＜ｃｎａｍｅ＞から、全ｃｎａｍｅのインスタンスが参照できる。このように、クラス図２７００によれば、主要部品の部品情報を出力することができる。ここで、部品情報の出力例について説明する。
【０１３３】
図２８は、部品情報の出力例を示す説明図である。図２８において、部品情報２８００は、本シミュレーション環境での定義をコンピュータリーダブルな形式で出力したものである。部品情報２８００は、例えば、デバッグ、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）、設計向けの定義データとして利用することができる。
【０１３４】
（プローブ情報の出力）
つぎに、プローブ情報の出力の実現方法について説明する。
【０１３５】
図２９は、プローブ情報に関するクラス図である。図２９に示すクラス図２９００において、ｐｒｏｂ＿ｒｏｏｔ＿ｔは、ｐｒｏｂ＿ｔへのポインタのベクタを持つ。ｐｒｏｂ＿ｔは、ｐｒｏｂ＿ｒｏｏｔ＿ｔをクラス変数に持つ。また、ｐｒｏｂ＿ｔは、自らをクラス変数ｍ＿ｒｏｏｔに登録する。
【０１３６】
ｐｒｏｂ＿ｘｘｘ＿ｔ（図２９中では、ｐｒｏｂ＿ｎｅｇｏ＿ｔ，ｐｒｏｂ＿ｃｏｍｐｌｅｘ０＿ｔ，ｐｒｏｂ＿ｐｒｉｍ＿ｔ）は、ｐｒｏｂ＿ｔを形式化した具体的な状態が定義されたクラスである。状態を可視化するオブジェクトは、ｐｒｏｂ＿ｘｘｘ＿ｔをインスタンスする。
【０１３７】
そして、オブジェクトは、状態遷移が起きたらｔｏ＜状態名＞（）というメソッドを呼んでｐｒｏｂ＿ｘｘｘ＿ｔの状態を変える。ｐｒｏｂ＿ｘｘｘ＿ｔは、この値（状態）をファイルに書き出す。このように、クラス図２９００によれば、プローブ情報を出力することができる。
【０１３８】
なお、ｐｒｏｂ＿ｔとｐｒｏｂ＿ｘｘｘとが分かれているのは、状態が異なるプローバーを定義しやすくするためである。ここで、状態の定義例について説明する。
【０１３９】
図３０は、状態の定義例を示す説明図である。図３０において、プローバー記述３０００は、状態のテーブルである。例えば、ＲＵＮ，ＩＤＬＥ，ＳＴＡＬＬのような状態は予め用意されている。一方、デコードモード、エンコードモードのようなアプリケーション特有の状態を持つ場合は、ユーザが状態を定義する。図３０中、ｃｏｍｐｌｅｘ０は、ユーザが定義した状態の一例である。
【０１４０】
このように定義することにより、ＰＲＯＢ＿ＸＸＸが、このような機能に相当するテンプレートクラスになっているので、ツールで該当機能を生成する処理を行うことができる。なお、プローバーで定義した状態値を観測するためには、周辺ブロック記述に状態が変わるタイミングで状態値を落とせるように記述を加えることにしてもよい。例えば，ｓｔａｔｅ．ＸＸＸＸがこれに相当する記述である。また、バスに関するデータ（データ流量など）についてはバス部品の中で落とすようになっている。ここで、図３１および図３２を用いて、プローバー記述３０００を実行した場合の出力例について説明する。
【０１４１】
図３１は、コンフィギュレーション情報の具体例を示す説明図である。図３１において、コンフィギュレーション情報一覧３１００は、プローバー記述３０００を実行した場合に、ａｓｉｍ＿ｔ：：ｓｔａｒｔ（）がコールされた段階で出力されるＩＤ番号と実体の一覧表である。
【０１４２】
コンフィギュレーション情報一覧３１００において、要素名ｃｏｎｆｉｇの開始タグと終了タグの間にコンフィギュレーション情報が書かれる。コンフィギュレーション情報には、要素名がｒｅｓｏｌｕｔｉｏｎとｐｒｏｂがある。要素名がｒｅｓｏｌｕｔｉｏｎのタグは、時間単位を表し、ｖａｌｕｅで指定された時間を１とする処理系であることを表す。要素名がｐｒｏｂは、プローバーに関する情報を表す。属性ｉｄは、プローバーのＩＤ番号を持つ。ｎａｍｅは、プローバーの名称を表す。
【０１４３】
図３２は、プローバー情報の具体例を示す説明図である。図３２において、プローバー情報３２００は、プローバー記述３０００の実行時に状態が変わるたびに出力される、発生時刻、ＩＤ番号、状態値および持続時間を表す情報である。
【０１４４】
具体的には、プローバー情報３２００は、ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）形式で４列ある。１列目は、イベントの発生時刻を示す。２列目はプローバーのＩＤ番号を示す。３列目は状態値を示す。４列目は、状態値が示す状態が続いた時間を示す。
【０１４５】
なお、ここでは状態値のプロービングの例のみを示しているが、コンフィギュレーション情報一覧３１００、プローバー情報３２００を拡張して流量や待ち時間を計測できるようにしてもよい。さらに、図３３に示すように拡張して、ａｓｉｍ＿ｔの配下でｔｒａｃｅ（ＶＡＲＩＡＢＬＥ，ｓｔｒｉｎｇ）で波形登録を可能にしてもよい。
【０１４６】
図３３は、波形ダンプの具体例を示す説明図である。図３３において、ｓｅｔｕｐは、ａｓｉｍ＿ｔの中にあるため、簡潔に書ける。波形ダンプは、ｓｃ＿ｓｔａｒｔ（）よりも前に実行されれば、ｖｉｒｔｕａｌ  ｍａｋｅ（）の中で定義してもよく、また、コンストラクタの中で定義してもよい。これにより、波形データ、すなわち、デバッグ情報を得ることができる。
【０１４７】
（シミュレーション装置９００のシミュレーション処理手順）
つぎに、実施の形態にかかるシミュレーション装置９００のシミュレーション処理手順について説明する。
【０１４８】
図３４は、シミュレーション装置９００のシミュレーション処理手順の一例を示すフローチャートである。図３４のフローチャートにおいて、まず、シミュレーション装置９００は、評価対象となるシステムに含まれる計算ブロックＢの周辺ブロック記述を取得する（ステップＳ３４０１）。
【０１４９】
つぎに、シミュレーション装置９００は、プローバー記述を取得する（ステップＳ３４０２）。つぎに、シミュレーション装置９００は、アーキテクチャシミュレーション記述を取得する（ステップＳ３４０３）。つぎに、シミュレーション装置９００は、シナリオ記述を取得する（ステップＳ３４０４）。
【０１５０】
そして、シミュレーション装置９００は、取得した周辺ブロック記述、プローバー記述、アーキテクチャシミュレーション記述およびシナリオ記述に基づいて、シミュレーションの実行ファイルを生成する（ステップＳ３４０５）。
【０１５１】
つぎに、シミュレーション装置９００は、生成したシミュレーションの実行ファイルを実行する（ステップＳ３４０６）。そして、シミュレーション装置９００は、シミュレーションの実行結果を出力して（ステップＳ３４０７）、本フローチャートによる一連の処理を終了する。これにより、アーキテクチャシミュレーションを実行することができる。
【０１５２】
（シミュレーションの実行結果の解析）
つぎに、シミュレーションの実行結果の解析について説明する。シミュレーションの実行結果の解析は、例えば、対話的に行われる。
【０１５３】
図３５は、シミュレーションの実行結果の解析例を示す説明図である。図３５において、シミュレーションの実行結果の解析を行う処理の手順が示されている。電力ライブラリは、周辺ブロックに対して、流量と状態値から電力を見積もれるようにした電力モデルを集めたライブラリである。
【０１５４】
ガントチャートは、周辺ブロックの状態を可視化したグラフである。流量波形データは、周辺ブロックごとに、指定されたサンプルの時間ごとに区切って流量を集計し、集計結果を可視化したグラフである。待ち時間波形データは、周辺ブロックごとに、指定されたサンプルの時間ごとに区切って待ち時間を集計し、集計結果を可視化したグラフである。
【０１５５】
電力波形データは、周辺ブロックごとに、指定されたサンプルの時間ごとに区切って電力を集計し、集計結果を可視化したグラフである。アーキテクチャ図は、アーキテクチャを示す記述（例えば、図２２に示したトップ記述２２００）を可視化した図面である。
【０１５６】
開発者は、例えば、シミュレーションの実行結果を用いて、ガントチャート作成、流量データ作成、待ち時間データ作成、電力データ作成、アーキテクチャ図作成等を行うことができる。また、このような可視化図面を作るためには記述に用いられる言語を解析して図示するツールが用いられるが、本実施の形態では、図示すべきデータをアーキテクチャシミュレーション時に生成し、このデータを可視化するため、ツールの複雑度が小さい方式といえる。
【０１５７】
図３６〜図３８は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図である。図３６において、アーキテクチャシミュレーション解析ビューアー３６００は、ガントチャートを表示するガントチャート表示部３６１０と、電力波形データを表示する電力波形表示部３６２０と、流量波形データを表示する流量波形表示部３６３０と、待ち時間波形データを表示する待ち時間波形表示部３６４０と、を含む。
【０１５８】
図３７において、アーキテクチャシミュレーション解析ビューアー３７００は、回路構成を表示する回路構成表示部３７１０を含む。図３８において、アーキテクチャシミュレーション解析ビューアー３８００は、インスタンスとライブラリ名とを関連付けて表す関連付け表を表示する関連付け表表示部３８１０を含む。
【０１５９】
アーキテクチャシミュレーション解析ビューアー３６００，３７００，３８００によれば、アーキテクチャシミュレーション解析ビューを構成することができる。また、アーキテクチャシミュレーション解析ビューアー３７００をアーキテクチャシミュレーションのエントリとして利用可能にすることにより、統合環境としての利用も可能になる。
【０１６０】
以上説明したように、実施の形態にかかるシミュレーション装置９００によれば、バスモデルＢＭを介してメモリモデルＭＭに対する指定サイズ分のデータの読み書きを行い、指定サイクル分の遅延を発生させて計算時間を再現する計算ブロックＢを用いてシステムの性能評価シミュレーションを実行することができる。これにより、評価対象となるシステム内の計算ブロックＢにかかるモデル記述を簡素化して、シミュレーションモデルの作成にかかる時間や手間を削減してシミュレーション期間の短縮化を図ることができる。
【０１６１】
また、シミュレーション装置９００によれば、ライトアクセスを「データ発送」でモデル化し、リードアクセスを「データ発注書のデータ発送」と「発注されたデータのデータ発送」でモデル化することにより、シミュレーションモデルを単純化することができる。
【０１６２】
また、シミュレーション装置９００によれば、バスモデルＢＭは、バッファを有するネゴシエーターモデルと、バッファへのアクセスを排他制御するアービターモデルと、を有することにしてもよい。また、ネゴシエーターモデルは、データ発注書の転送要求を受け付けた場合、アービターモデルの排他制御に従って、データ発注書をバッファに書き込み、バッファに書き込まれたデータ発注書をメモリモデルＭＭに書き込んだ後にバッファを解放することにしてもよい。これにより、複数の計算ブロックＢがバスモデルＢＭにアクセスする際にバスモデルＢＭの使用を一時的に制限する排他制御のシミュレーションを再現することができる。
【０１６３】
また、シミュレーション装置９００によれば、結線データ（例えば、部品情報２８００）、計測コンフィギュレーションデータ（例えば、コンフィギュレーション情報一覧３１００）、計測データ（例えば、プローバー情報３２００）などのシミュレーションの実行結果を出力することができる。
【０１６４】
これらのことから、シミュレーション装置９００によれば、シミュレーションモデルの作成工数を削減してシミュレーション期間を短縮させることにより、設計初期における性能評価、電力見積を可能にして商談、仕様検討に有益な情報を提供することができる。
【０１６５】
なお、本実施の形態で説明したシミュレーション方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本シミュレーションプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本シミュレーションプログラムは、インターネット等のネットワークを介して配布してもよい。
【符号の説明】
【０１６６】
９００  シミュレーション装置
１００１  取得部
１００２  生成部
１００３  実行部
１００４  出力部
Ｂ  計算ブロック
ＢＭ  バスモデル
ＭＭ  メモリモデル
ＳＢ  シナリオブロック
【図１】
2014064788.tif 000003
【図２】
2014064788.tif 000004
【図３】
2014064788.tif 000005
【図４】
2014064788.tif 000006
【図５】
2014064788.tif 000007
【図６】
2014064788.tif 000008
【図７】
2014064788.tif 000009
【図８】
2014064788.tif 000010
【図９】
2014064788.tif 000011
【図１０】
2014064788.tif 000012
【図１１】
2014064788.tif 000013
【図１２】
2014064788.tif 000014
【図１３】
2014064788.tif 000015
【図１４】
2014064788.tif 000016
【図１５】
2014064788.tif 000017
【図１６】
2014064788.tif 000018
【図１７】
2014064788.tif 000019
【図１８】
2014064788.tif 000020
【図１９】
2014064788.tif 000021
【図２０】
2014064788.tif 000022
【図２１】
2014064788.tif 000023
【図２２】
2014064788.tif 000024
【図２３】
2014064788.tif 000025
【図２４】
2014064788.tif 000026
【図２５】
2014064788.tif 000027
【図２６】
2014064788.tif 000028
【図２７】
2014064788.tif 000029
【図２８】
2014064788.tif 000030
【図２９】
2014064788.tif 000031
【図３０】
2014064788.tif 000032
【図３１】
2014064788.tif 000033
【図３２】
2014064788.tif 000034
【図３３】
2014064788.tif 000035
【図３４】
2014064788.tif 000036
【図３５】
2014064788.tif 000037
【図３６】
2014064788.tif 000038
【図３７】
2014064788.tif 000039
【図３８】
2014064788.tif 000040
【手続補正書】
【提出日】平成27年4月28日(2015.4.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータに、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行させることを特徴とするシミュレーションプログラム。
【請求項２】
前記ブロックは、前記計算処理にかかるリードデータ量のデータを読み込む読込処理を行う読込部と、前記計算処理にかかるサイクル数分の遅延を発生させる計算部と、前記計算処理にかかるライトデータ量のデータを書き込む書込処理を行う書込部とを含み、
前記読込部は、前記シナリオブロックまたは前記計算部からの起動信号を検出したら前記読込処理を行って前記計算部に起動信号を発行し、
前記計算部は、前記ブロックの動作周波数に基づいて、前記読込部からの起動信号を検出してから前記計算処理にかかるサイクル数分の時間が経過したら前記書込部に起動信号を発行するとともに、前記書込部からの起動信号を検出したら前記読込部に起動信号を発行し、
前記書込部は、前記計算部からの起動信号を検出したら前記書込処理を行って前記計算部に起動信号を発行するとともに、前記計算処理の回数分の書込処理を行った場合に前記シナリオブロックに終了信号を発行することを特徴とする請求項１に記載のシミュレーションプログラム。
【請求項３】
前記バスモデルは、前記ブロックから前記リードデータ量のデータの発注書の転送要求を受け付けると、前記発注書を前記メモリモデルに書き込み、前記メモリモデルによって前記リードデータ量のデータが書き込まれると、前記ブロックに前記リードデータ量のデータを送信し、
前記メモリモデルは、前記バスモデルによって前記発注書が書き込まれると、前記リードデータ量のデータを前記バスモデルに書き込むことを特徴とする請求項２に記載のシミュレーションプログラム。
【請求項４】
前記バスモデルは、前記ブロックからライトデータ量のデータの転送要求を受け付けると、前記ライトデータ量のデータを前記メモリモデルに書き込むことを特徴とする請求項３に記載のシミュレーションプログラム。
【請求項５】
前記バスモデルは、バッファを有するネゴシエーターモデルと、前記バッファへのアクセスを排他制御するアービターモデルと、を有し、
前記ネゴシエーターモデルは、前記発注書の転送要求を受け付けた場合、前記アービターモデルの排他制御に従って、前記発注書を前記バッファに書き込み、前記バッファに書き込まれた前記発注書を前記メモリモデルに書き込んだ後に前記バッファを解放することを特徴とする請求項４に記載のシミュレーションプログラム。
【請求項６】
前記コンピュータに、
実行した前記アーキテクチャモデルのシミュレーションの実行結果を出力する処理を実行させることを特徴とする請求項５に記載のシミュレーションプログラム。
【請求項７】
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得する第１処理部と、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得する第２処理部と、
前記第１処理部によって取得された前記アーキテクチャモデルと前記第２処理部によって取得された前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する第３処理部と、
を有することを特徴とするシミュレーション装置。
【請求項８】
コンピュータが、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行することを特徴とするシミュレーション方法。
【請求項９】
リード要求相当の動作として、あるブロックからデータの発注書を転送し、別のあるブロックが発注書を受信し、それに対応したデータを小包として発送する手段と、ライト要求相当の動作として、あるブロックから小包を発送する手段があり、データの一部に転送先などの制御情報をもち、転送を行う回路はこれらを解釈して所望のデータ転送を実現する手段をもったバスモデル、および、バス回路。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路に関する。
【背景技術】
【０００２】
従来、ＥＳＬ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｙｓｔｅｍ  Ｌｅｖｅｌ）などのＲＴＬ（Ｒｅｇｉｓｔｅｒ  Ｔｒａｎｓｆｅｒ  Ｌｅｖｅｌ）よりも抽象度が高いレベルでシミュレーションモデルを作成してシステムの性能評価が行われる場合がある。また、表計算ソフトなどを用いたユーザの手計算により、システムの性能を見積もる場合がある。
【０００３】
関連する先行技術としては、例えば、ＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）モデルを解析した解析結果を、利用者により入力された変換規則に従って変換して性能評価モデルを作成するものがある。また、複数の回路ブロックがバスで接続されているシステムの性能を、ソフトウェアを実行した際のバスの情報と、ライブラリに保持されているシステムにおける各回路ブロックに対する部品が持つバスオペレーションの情報とから算出するものがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−３１８８１２号公報
【特許文献２】特開２０００−２９３３９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来技術によれば、システムの性能を評価するためのシミュレーションモデルの作成に時間や手間がかかるという問題がある。例えば、ＥＳＬであってもシミュレーションモデルの作成に数ヶ月単位の期間を要することがあり、顧客との商談時などの設計段階よりも前の段階にシステムの性能を評価することが難しい。
【０００６】
また、近年では、様々なハードウェアブロックを組み合わせてＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ａ  Ｃｈｉｐ）を設計する場合が多く、様々な機能が含まれるようになってきている。このため、表計算ソフトなどを用いた手計算でシステムの性能を見積もるには、多数の専門家が経験と勘を駆使して机上検討を行うことになり作業時間やコストが増大する。
【０００７】
１つの側面では、本発明は、システムの性能を評価するシミュレーションの効率化を図ることができるシミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一側面によれば、複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行するシミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路が提案される。
【発明の効果】
【０００９】
本発明の一態様によれば、システムの性能を評価するシミュレーションの効率化を図ることができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、タスクの実行状況とバス流量との関係を示す説明図である。
【図２】図２は、ｓｔａｒｔ＿ｄｏｎｅの記述例を示す説明図である。
【図３】図３は、計算ブロックの一例を示す説明図である。
【図４】図４は、計算ブロックの記述例を示す説明図である。
【図５】図５は、リードインターフェースの記述例を示す説明図である。
【図６】図６は、アーキテクチャモデルの具体例を示す説明図である。
【図７】図７は、シナリオブロックＳＢのシナリオ記述例を示す説明図である。
【図８】図８は、結合記述例を示す説明図である。
【図９】図９は、シミュレーション装置９００のハードウェア構成例を示すブロック図である。
【図１０】図１０は、シミュレーション装置９００の機能的構成例を示すブロック図である。
【図１１】図１１は、シミュレーションの実行例を示す説明図である。
【図１２】図１２は、バスプロトコルの一例を示す説明図（その１）である。
【図１３】図１３は、バスプロトコルの一例を示す説明図（その２）である。
【図１４】図１４は、アービトレーションの回路例を示す説明図である。
【図１５】図１５は、トリッププランの回路例を示す説明図である。
【図１６】図１６は、アービトレーションモデルの具体例を示す説明図である。
【図１７】図１７は、データの転送例を示す説明図である。
【図１８】図１８は、トリッププランのクラス図の一例を示す説明図である。
【図１９】図１９は、ｒｏｕｔｅ＿ｎ＿１＿ｔのクラス図の一例を示す説明図である。
【図２０】図２０は、ｒｏｕｔｅ＿ｎ＿１＿ｔのｍａｋｅ（）の定義例を示す説明図である。
【図２１】図２１は、アーキテクチャのサンプル例を示す説明図である。
【図２２】図２２は、アーキテクチャの接続記述例を示す説明図である。
【図２３】図２３は、イニシエータの回路記述例を示す説明図である。
【図２４】図２４は、ターゲットの回路記述例を示す説明図である。
【図２５】図２５は、状態遷移例を示す説明図（その１）である。
【図２６】図２６は、状態遷移例を示す説明図（その２）である。
【図２７】図２７は、構造情報に関するクラス図である。
【図２８】図２８は、部品情報の出力例を示す説明図である。
【図２９】図２９は、プローブ情報に関するクラス図である。
【図３０】図３０は、状態の定義例を示す説明図である。
【図３１】図３１は、コンフィギュレーション情報の具体例を示す説明図である。
【図３２】図３２は、プローバー情報の具体例を示す説明図である。
【図３３】図３３は、波形ダンプの具体例を示す説明図である。
【図３４】図３４は、シミュレーション装置９００のシミュレーション処理手順の一例を示すフローチャートである。
【図３５】図３５は、シミュレーションの実行結果の解析例を示す説明図である。
【図３６】図３６は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図（その１）である。
【図３７】図３７は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図（その２）である。
【図３８】図３８は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図（その３）である。
【発明を実施するための形態】
【００１１】
以下に添付図面を参照して、本発明にかかるシミュレーションプログラム、シミュレーション装置、シミュレーション方法、バスモデルおよびバス回路の実施の形態を詳細に説明する。
【００１２】
（シミュレーション方法の一実施例）
実施の形態にかかるシミュレーション方法の一実施例について説明する。本実施の形態では、ＥＳＬなどのＲＴＬよりも抽象度が高いレベルでのシステムの性能を評価するシミュレーション方法について説明する。
【００１３】
評価対象となるシステムは、例えば、複数のハードウェアブロックとメモリとがバスを介して接続されるシステムである。また、シミュレーションは、各ハードウェアブロックがバスにトランザクションを投げた際のバスの混み具合から、システムの性能が破綻しないかどうかを評価するためのものである。
【００１４】
ここでは、まず、ネットリストエミュレーションの結果を利用して、システム内の各ハードウェアブロックのタスクの実行状況とバス流量との関係について説明する。
【００１５】
図１は、タスクの実行状況とバス流量との関係を示す説明図である。図１において、グラフ１１０，１２０は、過去品種のＲＴＬ設計データを結合したＳｏＣシミュレーション環境から抽出した各ハードウェアブロックのタスクの実行状況とバス流量との関係を示している。
【００１６】
バス流量とは、バスを介して各ハードウェアブロックに入出力されるデータ量である。グラフ１１０，１２０の波形は２．５秒程度あり、グラフ１２０の１点は６［ｍｓ］程度の幅があり、この区間の流量率（例えば、［ｂｐｓ／ｓｅｃ］）が記載されている。図１中、ＤＳＣ１、ＡＦＮ、ＲＥＣ０、ＪＰＥＧは、ハードウェアブロックの名称を表している。
【００１７】
グラフ１１０，１２０によれば、タスクの実行状況に応じて全体のバス帯域の使用量が変化していることがわかる。また、各々のタスクの実行期間においては、バス流量の波形が、矩形に近い波形になっていることがわかる。また、例えば、ＲＥＣ０やＪＰＥＧが動作すると、ＡＦＮやＲＥＣ０のバス流量は、１／２以下になっていることがわかる。
【００１８】
これらのことから、バス流量は各ハードウェアブロックの計算量と比例関係にあり、同一の利用状況でのバスの使われ方は定常状態（矩形的）になると仮定することができる。また、どの実行状況においても定常状態になると仮定すると、バスの周辺のハードウェアブロックはサンプリング期間全体でみると、定期的なアクセスをしていると仮定することができる。また、バス帯域の使用量がほかの実行期間よりも小さくなっている区間は、バス帯域が不足している期間であると仮定することができる。
【００１９】
そこで、本実施の形態では、バス部分とメモリ部分（例えば、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））については、ある程度正確にモデル化するために、既存のバスモデルとメモリモデルを利用する。
【００２０】
データ量が多いアプリケーションに対する論理設計では、ＤＲＡＭアクセスの連続性を保証できるように設計される。このため、バス部分は、例えば、初期アドレスとオーバーヘッドと論理的なバースト長（ＤＲＡＭがサポートしているバースト長より長い）とで定義できる。また、ＤＲＡＭ部分は、仕様書よりモデル化できるため、ＤＲＡＭの転送を模擬するバスモデルを作成する。
【００２１】
なお、以下の説明では、ハードウェアブロックを単に「ブロック」と表記する場合がある。また、バスの利用権を取得できるブロックを「イニシエータ」と表記し、イニシエータによってデータを送られたり取られたりするブロックを「ターゲット」と表記する場合がある。
【００２２】
また、本実施の形態では、バスモデルを介してメモリモデルにアクセスして計算処理を行うブロックとして、指定サイズ分のデータのリード／ライトを行い、指定サイクル分の遅延時間を発生させて計算時間を再現する計算モデルを用いる。また、開発者は、各ブロックのタスクの実行状況を表現するためにシナリオを定義する。
【００２３】
シナリオは、起動したいブロックごとに、以下の処理を行う。具体的には、シナリオは、ブロックに対して、一連の処理で行われる計算回数、１回当たりの平均計算サイクル数、１回当たりの平均リードデータ量、１回当たりの平均ライトデータ量および周期を与えて、そのブロックに起動信号を送る。また、シナリオは、起動信号を送ったブロックからの終了信号を検出して、シナリオの変更を行い所望の処理を実現する。
【００２４】
ここで、一連の処理は、開発者が一つの連続した処理とみなす処理の集まりである。一連の処理の単位は、開発者の立場やアプリケーションによって異なる。例えば、動画像処理の開発者であれば、１画面分の画像データ（１フレーム）の処理を一連の処理とみなしたり、１マクロブロック（フレームを構成する画像を細分化した処理単位）の処理を一連の処理とみなす場合がある。
【００２５】
また、一連の処理で行われる計算回数は、一連の処理に対する計算回数である。上述したように、一連の処理は、開発者の立場によってどの粒度を処理単位とするかが変わる。例えば、１フレームの処理を一連の処理とみなす場合、ブロックは、１フレームの中で何度もバスにアクセスをして、そのブロックの処理に必要なデータを取得して計算をする。このため、一連処理に対して複数回の計算が行われる。アーキテクチャシミュレーションしてバス性能を見積もる場合、「一連処理に対して何回計算した場合のバス性能はどれくらい出るのか？」という設問を立てる。ここでは、このような場合の一連の処理に対する計算回数を「一連処理で行われる計算回数」と呼ぶ。
【００２６】
また、一回当たりの平均計算サイクル数は、一回の計算処理にかかるサイクル数の平均値である。一連の処理では複数回の計算が行われ、計算にかかるサイクル数はばらつくものであるが、ここでは、一回当たりの平均計算サイクル数は、例えば、アーキテクチャシミュレーション環境の利用者によって任意に設定される。例えば、後述するパラメータｄｅｌａｙに与える値が、一回当たりの平均計算サイクル数を使って求めた値になる。
【００２７】
また、１回当たりの平均リードデータ量は、一回の計算処理にかかるリードデータの平均値である。一連の処理では複数回の計算が行われ、計算ごとに読み込むデータのサイズは異なるものであるが、ここでは、１回当たりの平均リードデータ量は、例えば、アーキテクチャシミュレーション環境の利用者によって任意に設定される。例えば、後述するパラメータｃｏｕｎｔに与える値が、一回当たりの平均リードデータ量を使って求めた値になる。
【００２８】
また、１回当たりの平均ライトデータ量は、一回の計算処理にかかるライトデータの平均値である。一連の処理では複数回の計算が行われ、計算ごとに書き込むデータのサイズは異なるものであるが、ここでは、１回当たりの平均ライトデータ量は、例えば、アーキテクチャシミュレーション環境の利用者によって任意に設定される。
【００２９】
また、周期は、周辺ブロックの動作周波数である。周辺ブロックの動作周波数を変更する場合、プロセッサから設定レジスタに所定の値を書き込むことによって処理される。すなわち、周期は、アーキテクチャシミュレーションではシナリオから制御されるべきものになる。パラメータ名としては、例えば、後述するｐｅｒｉｏｄに当たる。
【００３０】
このようにシナリオを実現するブロックと計算を行うブロックとの間では、起動と終了を扱う通信が必要になる。このため、開発者は、シナリオを実現するブロックと計算を行うブロックとの間の通信を行う部品を定義する。
【００３１】
図２は、ｓｔａｒｔ＿ｄｏｎｅの記述例を示す説明図である。図２において、ｓｔａｒｔ＿ｄｏｎｅ記述２００は、シナリオを実現するブロック（シナリオブロック）と計算を行うブロック（計算ブロック）との間の通信を行うための部品の記述例である。ｓｔａｒｔ＿ｄｏｎｅ記述２００によれば、シナリオブロックと計算ブロックとの間の通信を実現することができる。また、ｓｔａｒｔ＿ｄｏｎｅ記述２００は、起動と終了のプロトコルでモデル化したいブロックの関係を表現したい場合に利用することができる。
【００３２】
図３は、計算ブロックの一例を示す説明図である。図３において、計算ブロックＢは、読込部Ｐ１と、計算部Ｐ２と、書込部Ｐ３と、を含む。読込部Ｐ１は、シナリオブロックから指定された、計算回数分、シナリオブロックから指定されたデータサイズのリードを行い、１回ごとに、計算部Ｐ２を起動する。
【００３３】
計算部Ｐ２は、シナリオブロックから指定された遅延時間分経過して書込部Ｐ３にデータを送る。書込部Ｐ３は、シナリオブロックから指定されたデータサイズのデータを送出する。読込部Ｐ１、計算部Ｐ２および書込部Ｐ３の各々は、ｓｔａｒｔ＿ｄｏｎｅのプロトコル（例えば、図２参照）で接続されている。
【００３４】
また、読込部Ｐ１は、計算部Ｐ２がｄｏｎｅであればデータを読み、計算部Ｐ２を起動する。計算部Ｐ２は、書込部Ｐ３をｓｔａｒｔして、ｄｏｎｅになったら自らもｄｏｎｅにするモデルである。これにより、バスの混雑による処理性能の低下を再現することができる。
【００３５】
また、読込部Ｐ１は、シナリオブロックからのｓｔａｒｔ＿ｄｏｎｅ＿ｔ信号を受け取って、シナリオブロックから指定された計算回数分の読み込みを行ったら、起動信号に最終起動フラグを付して計算部Ｐ２に送る。この場合、計算部Ｐ２は、書込部Ｐ３に起動をかける際に起動信号に最終起動フラグを付して送り、書込部Ｐ３は、シナリオブロックへｄｏｎｅ（終了信号）を返す。これにより、計算部Ｐ２の遅延について、バスの競合による遅延を考慮に入れた遅延を算出することができる。
【００３６】
図４は、計算ブロックの記述例を示す説明図である。図４において、計算ブロック記述４００は、計算ブロックＢ（図３参照）の動作を実現するための記述例である。開発者は、計算ブロック記述４００のようなブロックモデルを作成してＤＢ（データベース）に登録しておくことにより、シミュレーションを行う際に計算ブロック記述４００を再利用することができる。
【００３７】
図５は、リードインターフェースの記述例を示す説明図である。図５において、リードインターフェース記述５００は、イニシエータ（例えば、計算ブロックＢ）のリードインターフェースを実現するための記述例である。開発者は、リードインターフェース記述５００のようなインターフェースモデルを作成してＤＢに登録しておくことにより、シミュレーションを行う際にリードインターフェース記述５００を再利用することができる。なお、ライトインターフェースについても同様である。
【００３８】
図６は、アーキテクチャモデルの具体例を示す説明図である。図６において、アーキテクチャモデル６００は、シナリオブロックＳＢと、計算ブロックＢ１と、計算ブロックＢ２と、計算ブロックＢ３と、バスモデルＢＭと、メモリモデルＭＭと、を含む。アーキテクチャモデル６００では、計算ブロックＢ１〜Ｂ３の各々の計算ブロックＢが、バスモデルＢＭと通信する。
【００３９】
シナリオブロックＳＢは、計算ブロックＢ１〜Ｂ３に起動信号を発行するとともに、計算ブロックＢ１〜Ｂ３からの終了信号を検出するブロックである。シナリオブロックＳＢは、例えば、アーキテクチャモデル６００の全体を制御するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）に相当する。
【００４０】
また、シナリオブロックＳＢは、シナリオ（例えば、後述する図７に示すシナリオ記述７００）に基づいて、各計算ブロックＢ１〜Ｂ３に各種パラメータを設定する。各種パラメータは、例えば、上述した、一連の処理で行われる計算回数、一回当たりの平均計算サイクル数、１回当たりの平均リードデータ量、１回当たりの平均ライトデータ量、周期である。
【００４１】
計算ブロックＢ１〜Ｂ３は、バスモデルＢＭを介してメモリモデルＭＭにアクセスして計算処理を行う周辺ブロックである。具体的には、例えば、計算ブロックＢ１の読込部Ｐ１（図３参照）は、シナリオブロックＳＢからのｓｔａｒｔ＿ｄｏｎｅ＿ｔ信号を受けると、指定された計算回数分（例えば、１０００回）、指定されたデータサイズ（例えば、５０バイト）のデータを読み込む。読込部Ｐ１は、１回の読込処理が完了したら計算部Ｐ２（図３参照）に起動信号を送る。
【００４２】
より具体的には、例えば、読込部Ｐ１は、バスモデルＢＭのＲｅａｄ関数（読み込むデータのデータ量も指定）を呼び出して、Ｒｅａｄ関数が抜けたことをもって、読込処理が終了したことを検出し、ｄｏｎｅイベントを発行する。Ｒｅａｄ関数は、データを書き込んだ後に抜けるようになっている。
【００４３】
計算部Ｐ２は、読込部Ｐ１から起動信号を受けると、計算ブロックＢの動作周波数に基づいて、指定された遅延時間分経過したら、書込部Ｐ３（図３参照）に起動信号を送る。例えば、指定された遅延時間を１００サイクルとし、各計算ブロックＢ１〜Ｂ３の動作周波数（周期）を１０００Ｈｚとする。この場合、計算部Ｐ２は、読込部Ｐ１から起動信号を受けると、０．１秒（＝１００／１０００）経過したら、書込部Ｐ３に起動信号を送る。
【００４４】
書込部Ｐ３は、計算部Ｐ２から起動信号を受けると、指定されたデータサイズ（例えば、１００バイト）のデータを書き込む。より具体的には、例えば、書込部Ｐ３は、バスモデルＢＭのＷｒｉｔｅ関数（書き込むデータのデータ量も指定）を呼び出して、Ｗｒｉｔｅ関数が抜けたことをもって、書込処理が終了したことを検出し、ｄｏｎｅイベントを発行する。Ｗｒｉｔｅ関数は、データを書き込んだ後に抜けるようになっている。
【００４５】
バスモデルＢＭは、計算ブロックＢ１〜Ｂ３とメモリモデルＭＭとを接続するとともに各計算ブロックＢ１〜Ｂ３からメモリモデルＭＭへのアクセスを制御する。具体的には、例えば、バスモデルＢＭは、バスの機能とメモリコントローラの機能とを有する（ＢＵＳ＋ＤＲＡＭ  Ｉｎｔｅｒｆａｃｅ）。メモリモデルＭＭは、例えば、ＤＲＡＭモデルである。
【００４６】
より具体的には、例えば、バスモデルＢＭは、Ｗｒｉｔｅ関数が呼び出されると、メモリモデルＭＭに対してデータ（例えば、オールゼロのデータ）を書き込んで、データのサイズ分の遅延（例えば、１０サイクル）を発生させてＷｒｉｔｅ関数を終わる。すなわち、バスモデルＢＭは、ブロッキングの関数コールでディレイを発生させて関数を抜ける。
【００４７】
ここで、シナリオブロックＳＢが計算ブロックＢ１〜Ｂ３を同時に起動して、計算ブロックＢ１〜Ｂ３のすべての処理が終わったらシミュレーションを終了するシナリオを例に挙げて、シナリオブロックＳＢのシナリオ記述例について説明する。
【００４８】
図７は、シナリオブロックＳＢのシナリオ記述例を示す説明図である。図７において、シナリオ記述７００は、計算ブロックＢ１，Ｂ２，Ｂ３（図７中、０，１，２）を同時に起動して、計算ブロックＢ１〜Ｂ３のすべての処理が終わったらシミュレーションを終了するシナリオである。
【００４９】
具体的には、例えば、シナリオ記述７００には、各計算ブロックＢ１〜Ｂ３に設定される、一連の処理で行われる計算回数、一回当たりの平均計算サイクル数、１回当たりの平均リードデータ量、１回当たりの平均ライトデータ量および周期が記述されている。シナリオブロックＳＢと各計算ブロックＢ１〜Ｂ３には、パラメータを送る信号線ｐｅｒｉｏｄ，ｄｅｌａｙ，ｃｏｕｎｔがある。
【００５０】
ｐｅｒｉｏｄは、各計算ブロックＢ１〜Ｂ３の動作周波数である。ｄｅｌａｙは、各計算ブロックＢ１〜Ｂ３の計算部Ｐ２の遅延である。ｃｏｕｎｔは、各計算ブロックＢ１〜Ｂ３の計算処理の回数、すなわち、各計算ブロックＢ１〜Ｂ３の読込部Ｐ１の読み込み回数である。
【００５１】
シナリオ記述７００によれば、シナリオブロックＳＢは、各計算ブロックＢ１〜Ｂ３に各種パラメータを設定して、各計算ブロックＢ１〜Ｂ３に同時に起動信号を発行し、すべての計算ブロックＢ１〜Ｂ３から終了信号を検出するのを待つことになる（ｄｏ〜ｗｈｉｌｅ文）。
【００５２】
図８は、結合記述例を示す説明図である。図８において、結合記述８００は、図６に示したようなブロック間の結合をモデル化して表すアーキテクチャシミュレーション記述である。ここでは、バス競合の再現に十分な精度を持った計算ブロックＢ１〜Ｂ３を定義し、シナリオブロックＳＢとの通信の仕方を決めたことにより、全体の結合網をコンパクトして結合記述８００のように記述を単純化し工数を削減することができる。
【００５３】
（シミュレーション装置９００のハードウェア構成例）
つぎに、実施の形態にかかるシミュレーション装置９００のハードウェア構成例について説明する。図９は、シミュレーション装置９００のハードウェア構成例を示すブロック図である。図９において、シミュレーション装置９００は、ＣＰＵ９０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）９０２と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９０３と、磁気ディスクドライブ９０４と、磁気ディスク９０５と、光ディスクドライブ９０６と、光ディスク９０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）９０８と、ディスプレイ９０９と、キーボード９１０と、マウス９１１と、を有している。また、各構成部はバス９１２によってそれぞれ接続されている。
【００５４】
ここで、ＣＰＵ９０１は、シミュレーション装置９００の全体の制御を司る。ＲＯＭ９０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ９０３は、ＣＰＵ９０１のワークエリアとして使用される。磁気ディスクドライブ９０４は、ＣＰＵ９０１の制御に従って磁気ディスク９０５に対するデータのリード／ライトを制御する。磁気ディスク９０５は、磁気ディスクドライブ９０４の制御で書き込まれたデータを記憶する。
【００５５】
光ディスクドライブ９０６は、ＣＰＵ９０１の制御にしたがって光ディスク９０７に対するデータのリード／ライトを制御する。光ディスク９０７は、光ディスクドライブ９０６の制御で書き込まれたデータを記憶したり、光ディスク９０７に記憶されたデータをコンピュータに読み取らせたりする。
【００５６】
Ｉ／Ｆ９０８は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク９２０に接続され、ネットワーク９２０を介して他の装置に接続される。そして、Ｉ／Ｆ９０８は、ネットワーク９２０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ９０８には、例えば、モデムやＬＡＮアダプタなどを採用することができる。
【００５７】
ディスプレイ９０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ９０９は、例えば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００５８】
キーボード９１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス９１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
【００５９】
なお、シミュレーション装置９００は、上述した構成のうち、例えば、光ディスクドライブ９０６や光ディスク９０７を有さないことにしてもよい。また、シミュレーション装置９００は、上述した構成部のほかに、例えば、スキャナやプリンタを有することにしてもよい。
【００６０】
（シミュレーション装置９００の機能的構成例）
図１０は、シミュレーション装置９００の機能的構成例を示すブロック図である。図１０において、シミュレーション装置９００は、取得部１００１と、生成部１００２と、実行部１００３と、出力部１００４と、を含む構成である。取得部１００１〜出力部１００４は制御部となる機能であり、具体的には、例えば、図９に示したＲＯＭ９０２、ＲＡＭ９０３、磁気ディスク９０５、光ディスク９０７などの記憶装置に記憶されたプログラムをＣＰＵ９０１に実行させることにより、または、Ｉ／Ｆ９０８により、その機能を実現する。また、各機能部の処理結果は、例えば、ＲＡＭ９０３、磁気ディスク９０５、光ディスク９０７などの記憶装置に記憶される。
【００６１】
取得部１００１は、評価対象となるシステムのアーキテクチャモデルを取得する機能を有する。ここで、アーキテクチャモデルは、シナリオブロックＳＢと、複数の計算ブロックＢ（例えば、上述した計算ブロックＢ１〜Ｂ３）と、バスモデルＢＭと、メモリモデルＭＭと、を含む。
【００６２】
シナリオブロックＳＢは、複数の計算ブロックＢに起動信号を発行するとともに複数の計算ブロックＢからの終了信号を検出する。バスモデルＢＭは、複数の計算ブロックＢとメモリモデルＭＭとを接続するとともに計算ブロックＢからメモリモデルＭＭへのアクセスを制御する。計算ブロックＢは、バスモデルＢＭを介してメモリモデルＭＭにアクセスして計算処理を行う。
【００６３】
具体的には、例えば、アーキテクチャモデルは、例えば、周辺ブロック記述と、アーキテクチャシミュレーション記述と、を含む。周辺ブロック記述は、評価対象となるシステムに含まれる計算ブロックＢの記述情報である。周辺ブロック記述は、例えば、図４に示した計算ブロック記述４００や図５に示したリードインターフェース記述５００を含む。
【００６４】
また、周辺ブロック記述は、例えば、開発者により、ＤＢに登録されているブロックモデルやインターフェースモデル等を再利用または組み合わせることにより作成される。ＤＢから周辺ブロック記述を作成できない場合は、開発者により、一から周辺ブロック記述が記述される。
【００６５】
アーキテクチャシミュレーション記述は、例えば、図２に示したｓｔａｒｔ＿ｄｏｎｅ記述２００、図８に示した結合記述８００、後述の図１６に示すアービトレーションモデル１６００などを含む。なお、結合記述８００は、後述の図２２〜図２４に示すイニシエータとターゲットをｒｏｕｔｅ＿ｎ＿１＿ｔで接続した結合記述に置き換えることにしてもよい。
【００６６】
また、取得部１００１は、評価対象となるシステムのシナリオ記述を取得する機能を有する。シナリオ記述は、計算ブロックＢごとに、一連の処理で行われる計算処理の回数と、計算処理にかかるサイクル数と、計算処理にかかるリードデータ量と、計算処理にかかるライトデータ量と、計算ブロックＢの動作周波数と、を示す情報である。シナリオ記述は、例えば、図７に示したシナリオ記述７００である。
【００６７】
また、取得部１００１は、評価対象となるシステムのプローバー記述を取得する機能を有する。プローバー記述は、例えば、計算ブロックＢの仕様に依存する状態値をダンプするために状態を指定する情報である。プローバー記述は、例えば、後述の図３０に示すプローバー記述３０００である。
【００６８】
生成部１００２は、システムの性能を評価するシミュレーションの実行ファイルを生成する機能を有する。具体的には、例えば、生成部１００２は、取得された周辺ブロック記述、プローバー記述、アーキテクチャシミュレーション記述およびシナリオ記述に基づいて、シミュレーションの実行ファイル（バイナリ）を生成する。
【００６９】
より具体的には、例えば、生成部１００２は、ＡＳｉｍＬｉｂｒａｒｙとともに周辺ブロック記述、プローバー記述、アーキテクチャシミュレーション記述およびシナリオ記述をコンパイルすることにより、シミュレーションの実行ファイルを生成する。なお、ＡＳｉｍＬｉｂｒａｒｙは、ＳｙｓｔｅｍＣの拡張機能を記述したものである。
【００７０】
実行部１００３は、生成されたシミュレーションの実行ファイルを実行する機能を有する。実行ファイルが実行されるとシミュレーションが行われ、シミュレーションの実行結果が得られる。シミュレーションの実行結果は、例えば、結線データと、計測コンフィギュレーションデータと、計測データとを含む。
【００７１】
結線データは、部品の結線関係を示すデータである。結線データは、アーキテクチャ情報を他のツールに渡せるようにしたコンピュータリーダブルな情報である。例えば、結線データは、後述の図２８に示す部品情報２８００（ｐａｒｔｓ．ｘｍｌ）である。計測コンフィギュレーションデータは、計測データのＩＤ番号と実体の関係を示すデータである。例えば、計測コンフィギュレーションデータは、後述の図３１に示すコンフィギュレーション情報一覧３１００（ｃｏｎｆ．ｘｍｌ）である。計測データは、状態変化の履歴などの計測結果を記載したデータである。例えば、計測データは、後述の図３２に示すプローバー情報３２００（ｐｒｏｂｅ．ｃｓｖ）である。
【００７２】
出力部１００４は、シミュレーションの実行結果を出力する。出力部１００４の出力形式としては、例えば、ＲＡＭ９０３、磁気ディスク９０５、光ディスク９０７などの記憶装置への記憶、Ｉ／Ｆ９０８による外部装置への送信、ディスプレイ９０９への表示などがある。
【００７３】
（シミュレーションの実行例）
ここで、シナリオ記述７００に基づく、アーキテクチャモデル６００（図６参照）のシミュレーションの実行例について説明する。
【００７４】
図１１は、シミュレーションの実行例を示す説明図である。図１１において、グラフ１１０１，１１０２，１１０３は、各計算ブロックＢ１，Ｂ２，Ｂ３（図１１中、ＩＰ０，ＩＰ１，ＩＰ２）の実行状況を示すグラフである。図１１中、Ｒは、ラン状態を表し、ＳＴは、ストール状態を表し、Ｉは、アイドル状態を表し、ＳＬは、スリープ状態を表す。
【００７５】
グラフ１１０１〜１１０３によれば、各計算ブロックＢ１，Ｂ２，Ｂ３のストール状態が表されており、バスの競合が再現することができていることがわかる。また、各計算ブロックＢ１，Ｂ２，Ｂ３が指定回数分の処理を終えて、ｄｏｎｅフラグのｊｏｉｎがとれて終了していることが分かる。
【００７６】
（バスの汎用化）
上述した説明では、バスモデルＢＭとして既存のモデルを用いる場合について説明したが、バスには様々な種類があり、いずれの種類にも対応するバスモデルを用意するにはコストがかかってしまう。そこで、以下の説明では、バスの汎用化について説明する。
【００７７】
まず、バスプロトコルについて説明する。本バスプロトコルでは「データ発送」という処理を定義する。データ発送は、データを転送する処理である。そして、ライトアクセスを「データ発送」でモデル化する。また、リードアクセスを「データ発注書」のデータ発送と「発注されたデータ」のデータ発送とでモデル化する。すなわち、リードアクセスを、ターゲットに「データ発注書」を行い、ターゲットが「発注されたデータ発送」を行う一連の処理として解釈する。
【００７８】
具体的には、例えば、バスモデルＢＭは、計算ブロックＢに設定されたライトデータ量のデータの転送要求を計算ブロックＢから受け付けると、ライトデータ量のデータをメモリモデルＭＭに書き込む。
【００７９】
また、バスモデルＢＭは、計算ブロックＢからデータ発注書の転送要求を受け付けると、データ発注書をメモリモデルＭＭに書き込む。データ発注書には、計算ブロックＢに設定されたリードデータ量が記述されている。メモリモデルＭＭは、バスモデルＢＭによってデータ発注書が書き込まれると、データ発注書に記述されたリードデータ量のデータをバスモデルＢＭに書き込む。バスモデルＢＭは、メモリモデルＭＭによってリードデータ量のデータが書き込まれると、計算ブロックＢに、書き込まれたリードデータ量のデータを送信する。
【００８０】
以下、バスモデルＢＭのバスプロトコルの一例について説明する。なお、バスモデルと書いたがこれらの仕様に基づいたバスを実際の設計で用いるとしてもよい。以下に示すバスプロトコルは、Ｐａｃｋ信号線とＣｏｎｔｅｎｔｓ信号線によるシンプルで単純な信号線構成になっており、一部データの解釈で制御情報（アドレス値など）を取り出す機構になっており、アドレス線とデータ線を区別する一般的なオンチップバスとは大きく異なっている。したがって、このような性質が適したアプリケーションである場合や回路の自動生成のため単純化が望まれる場合であれば、このバスモデルを回路として利用することもあり得る。したがって，本バスモデルは設計で用いられるバス回路を含む広義のバスモデルであると考えてよい。
【００８１】
図１２は、バスプロトコルの一例を示す説明図（その１）である。図１２において、バスプロトコル１２００は、データのビットの意味を定義するものである。宛先は、３２ビットデータである。宛先のうちの最上位ビット、すなわち、３１ビット目は、転送のタイプがＬｅｔｔｅｒ型（手紙型）かＰａｒｃｅｌ型（小包型）かを示している。
【００８２】
Ｌｅｔｔｅｒ型は、発注書などを送る転送のタイプである。Ｐａｒｃｅｌ型は、実データを送る転送のタイプである。Ｌｅｔｔｅｒ型は最上位ビットの値が「０」であり、Ｐａｒｃｅｌ型は最上位ビットの値が「１」である。
【００８３】
また、最上位ビットの値が「１（Ｐａｒｃｅｌ型）」の場合、３０ビット目はアップロード「０」またはダウンロード「１」を示す。３０ビット目の値が「０（アップロード）」の場合、２９ビット目〜０ビット目は、送り先のアドレスと解釈される。一方、３０ビット目の値が「１（ダウンロード）」の場合、２９ビット目〜１６ビット目は、リザーブされており（例えば、０詰めされる）、この部分の値は解釈されない。１５ビット目〜０ビット目は、イニシエータのＩＤ番号が格納される。
【００８４】
また、最上位ビットの値が「０（Ｌｅｔｔｅｒ型）」の場合、３０ビット目はリザーブされ利用されない。また、２９ビット目〜０ビット目は送り先のアドレス（ターゲットアドレス）である。
【００８５】
発注書は、１ワード（３２ビット）データで、上位２バイトはデータを送り返すイニシエータのＩＤ番号であり、下位２バイトは送り返すデータのサイズである。ターゲットは、ターゲットアドレスで指定されたアドレスから発注書に記載されたサイズ分のデータを転送する。
【００８６】
バスプロトコル１２００によれば、データ転送を基本とするバストランザクションを定義することができる。これにより、アーキテクチャモデルでも同様にデータ転送（ライトアクセス）をモデル化すれば、所望のバストランザクションの説明ができることになる。また、バスプロトコル１２００と実際のバスプロトコルとを比較することにより、性能の概算を行うことが可能になる。
【００８７】
図１３は、バスプロトコルの一例を示す説明図（その２）である。図１３において、バスプロトコル１３００は、データのビットの意味を定義するものである。宛先は、３２ビットデータである。宛先のうちの３１ビット目〜３０ビット目は、転送のタイプを示している。
【００８８】
転送のタイプとしては、Ｌｅｔｔｅｒ型、Ｐａｒｃｅｌ型、Ｐａｒｃｅｌ  Ｗｉｔｈ  ＲｅｐｏｒｔＲｅｑｕｅｓｔ型、Ｒｅｐｏｒｔ型の４種類があり、各々に０，１，２，３の値が割り当てられている。また、３の場合には宛先を入荷報告という。
【００８９】
３１ビット目〜３０ビット目の値が「０（Ｌｅｔｔｅｒ型）」の場合、３０ビット目はリザーブされ、この部分の値は解釈されない。また、２９ビット目〜０ビット目は送り先のアドレス（ターゲットアドレス）である。
【００９０】
また、３１ビット目〜３０ビット目の値が「１（Ｐａｒｃｅｌ型）」の場合、２９ビット目はアップロード「０」またはダウンロード「１」を示す。２９ビット目の値が「０（アップロード）」の場合、２８ビット目〜０ビット目は送り先のアドレス（ターゲットアドレス）である。一方、２９ビット目の値が「１（ダウンロード）」の場合、２８ビット目〜１０ビット目はリザーブされ、この部分の値は解釈されない。９ビット目〜０ビット目は、イニシエータのＩＤ番号が格納される。
【００９１】
また、３１ビット目〜３０ビット目の値が「２（Ｐａｒｃｅｌ  Ｗｉｔｈ  ＲｅｐｏｒｔＲｅｑｕｅｓｔ型）」または「３（Ｒｅｐｏｒｔ型）」の場合、２８ビット目〜１０ビット目はリザーブされ、この部分の値は解釈されない。９ビット目〜０ビット目は、レポートを送付する先のＩＤ番号が書かれる。
【００９２】
発注書は、３１ビット目〜２６ビット目まではリザーブされ、２５ビット目〜１６ビット目まではデータを送り返すイニシエータのＩＤ番号であり、１５ビット目〜０ビット目は送り返すデータのサイズである。
【００９３】
入荷報告送付先書は、３１ビット目が次のデータセルがデータか、それとも入荷報告書の続きかを示す。「０」の場合は入荷報告書が続き、「１」の場合は入荷報告書が終わり、次からデータが続くことを示す。２９ビット目〜０ビット目は１０ビットずつ３個の入荷報告先を記載できる。「０」を欠番とし、「０」が書かれている場合には無効なＩＤ番号として無視される。
【００９４】
バスプロトコル１３００によれば、小包（データ）が届いたことを別のイニシエータに送信することができ、データの移動によって制御が発生する場合に適用できる。なお、図１２および図１３では、コンテンツ線の幅が３２ビットの場合を例に挙げて説明したが、コンテンツ線の幅を１６ビット幅にした場合には、宛先を２ワードとし、１データ当たり２ワードにすればよい。
【００９５】
（アービトレーション）
つぎに、アービトレーションについて説明する。アービトレーションは、複数の計算ブロックがバスを占有しないように調停する回路である。ここでは、転送経路の排他性を制御するアービトレーション（Ｒｏｕｔｅ  Ａｒｂｉｔｒａｔｉｏｎ）と、リソースの排他性を制御するアービトレーション（Ｒｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎ）とを用いる。
【００９６】
また、ゴールのリソースの占有権をとるかとらないかを決める必要がある場合がある。この場合の調停戦略としては、例えば、ゴールのネゴシエーションを行ってから転送を開始するパターンと、ローカルのネゴシエーションを進めていきゴールに近づいていくパターンとがある。なお、アービトレーションの必要がない場合は、ｎｏｎ−ａｒｂｉｔｒａｔｉｏｎによりアービトレーションしない。
【００９７】
図１４は、アービトレーションの回路例を示す説明図である。図１４において、転送機構１４００は、Ｒｏｕｔｅ  ＡｒｂｉｔｒａｔｉｏｎとＲｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎとを実現する回路例である。転送機構１４００は、４チャネル転送コネクタ１４１０と２チャネル転送コネクタ１４２０とを有する。４チャネル転送コネクタ１４１０と２チャネル転送コネクタ１４２０は、結合網１４３０によって結合されている。
【００９８】
４チャネル転送コネクタ１４１０は、データ受信部１４１１と、データ送信部１４１２と、バッファ０〜３とを有する。２チャネル転送コネクタ１４２０は、データ受信部１４２１と、データ送信部１４２２と、バッファ０，１とを有する。結合網１４３０は、Ｒｏｕｔｅ  Ａｒｂｉｔｒａｔｉｏｎの対象となる。バッファ０〜３と、バッファ０，１は、Ｒｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎの対象となる。
【００９９】
（トリッププラン）
つぎに、トリッププランについて説明する。トリッププランは、ネゴシエーターのリストであり、目的地（例えば、ターゲット）までのルートを表している。
【０１００】
図１５は、トリッププランの回路例を示す説明図である。図１５において、トリッププラン１５００は、ネゴシエーター１５０１〜１５０４を有する。各ネゴシエーター１５０１〜１５０４は、バッファとアクセス部分とを有する。
【０１０１】
荷物（Ｐａｒｃｅｌ型のデータ）や手紙（Ｌｅｔｔｅｒ型のデータ）は、ネゴシエーター１５０１〜１５０４の中のバッファを利用しながら目的地まで転送される。各ネゴシエーター１５０１〜１５０４のアクセス部分は、次の宿営地（例えば、次のネゴシエーターのバッファ）に移れるかをアービターに対してネゴシエーションする部分である。アービターから許可が出れば、荷物や手紙は次の宿営地に移動する。
【０１０２】
図１６は、アービトレーションモデルの具体例を示す説明図である。図１６において、アービトレーションモデル１６００において、ネゴシエーター間の荷物や手紙の移動は、移動元のネゴシエーターが、移動先のネゴシエーターが属しているアービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）に対して予約を行うことにより実現される。
【０１０３】
具体的には、アービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）は、リソース数を管理しており、空きリソースがあれば、移動元のネゴシエーターに許可を出す。一方、アービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）は、空きリソースがなければ保留とし、空きリソースができた段階で、移動元のネゴシエーターに許可を出す。
【０１０４】
また、移動元のネゴシエーターは、アービター（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）から許可が出れば荷物や手紙を送ることができるため、転送経路の確保を行う。転送経路の確保は、アービター（ｒｏｕｔｅ＿ａｒｂｉｔｅｒ）に対して予約を行うことにより実現される。
【０１０５】
また、移動元のネゴシエーターは、転送経路が確保できたら、荷物や手紙の転送を行う。そして、また、移動元のネゴシエーターは、荷物や手紙の転送が完了すると、移動元のネゴシエーターのバッファは空になるので、移動元のネゴシエーターが属するアービターに対して、ｃｈｅｃｋｏｕｔを伝えてリソースを解放する。
【０１０６】
図１７は、データの転送例を示す説明図である。図１７において、Ｎ番目のネゴシエーターから（Ｎ＋１）番目のネゴシエーターにトークン（データ）が転送される転送例が示されている。トークンは、例えば、タイプ、発注書、データバイト数、通過部品履歴等を含むデータである。
【０１０７】
図１７の転送例では、まず、Ｒｅｓｏｕｒｃｅ  Ａｒｂｉｔｒａｔｉｏｎにより、転送経路１７０１，１７０２がリソースを確保する。つぎに、Ｒｏｕｔｅ  Ａｒｂｉｔｒａｔｉｏｎにより、転送経路１７０１が選択される。
【０１０８】
そして、転送経路１７０１が選択された結果、Ｎ番目のネゴシエーターから（Ｎ＋１）番目のネゴシエーターにトークンがバス転送時間をかけて移動する。具体的には、例えば、Ｎ番目のネゴシエーターが、（Ｎ＋１）番目のネゴシエーターにデータを書き込んだ後、所定時間を経過したら、アービターに対して転送経路１７０１の解放を通知する。
【０１０９】
このように、トリッププランで発送元（例えば、イニシエータ）と発送先（例えば、ターゲット）とをつなぎ、図１６に示したようにアービターと関連付けることにより、バスの動作を模擬することができる。また、ｎｏｎ−ａｒｂｉｔｒａｔｉｏｎクラスを接続することにより、その部分はリソース制約なしで転送を行うことができる。すなわち、トリッププランという経路によるモデル化により、排他制御のシミュレーションを再現することができる。
【０１１０】
（ｒｏｕｔｅ＿ｎ＿１＿ｔクラス）
つぎに、トリッププランをまとめたセカンダリィな要素として、ｒｏｕｔｅ＿ｎ＿１＿ｔを定義する。ここでは、まず、トリッププランのクラス図について説明する。
【０１１１】
図１８は、トリッププランのクラス図の一例を示す説明図である。図１８において、クラス図１８００は、トリッププランのクラス図である。クラス図１８００では、ｒｏｕｔｅ＿ｎ＿１＿ｔ用にｒｏｕｎｄ＿ｔｒｉｐ＿ｐｌａｎ＿ｔが定義されている。ｒｏｕｎｄ＿ｔｒｉｐ＿ｐｌａｎ＿ｔは、往路用と復路用のトリッププランを梱包している。
【０１１２】
図１９は、ｒｏｕｔｅ＿ｎ＿１＿ｔのクラス図の一例を示す説明図である。図１９において、クラス図１９００は、ｒｏｕｔｅ＿ｎ＿１＿ｔのクラス図である。ｒｏｕｔｅ＿ｎ＿１＿ｔは、ｎ個のイニシエータが１個のターゲットと関係する関係を示すクラスである。ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔは、イニシエータからのアクセスを受けるためのインターフェースである。
【０１１３】
一方、ｒｏｕｔｅ＿ｎ＿１＿ｔは、ターゲット側のインターフェースを兼ねている。ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔは、ｒｏｕｎｄ＿ｔｒｉｐ＿ｐｌａｎ＿ｔを持っている。従って、往路、復路のトリッププランを管理することができる。
【０１１４】
（準備処理の流れ）
ここで、シミュレーション装置９００の準備処理の流れについて説明する。まず、シミュレーション装置９００は、計測データのダンプを起動する。計測データのダンプが起動されると、インスタンスされたモジュールにダンプデータ用のファイルポインタが渡されて、イベント履歴を出力するように設定される。
【０１１５】
つぎに、シミュレーション装置９００は、図９に示したキーボード９１０やマウス９１１を用いたユーザの操作入力により、アーキテクチャの設定を行う。そして、シミュレーション装置９００は、設定されたアーキテクチャを生成する。
【０１１６】
なお、トリッププランの中のネゴシエーターは（＃ａｒｂｉｔｅｒ＋１）／２個インスタンスすることになるが、結線が先に行われてからアービターの設定がなされることがあるため、自動的にインスタンスするフェーズを設ける。また、テンプレートクラスのＭａｎ＿ｔの継承クラスであればｖｉｒｔｕａｌ  ｍａｋｅ（）が呼ばれるようになっているので、このフェーズで作るべき処理をｖｉｒｔｕａｌ  ｍａｋｅ（）の中で書いておけばよい。
【０１１７】
図２０は、ｒｏｕｔｅ＿ｎ＿１＿ｔのｍａｋｅ（）の定義例を示す説明図である。図２０において、定義２０００は、ｒｏｕｔｅ＿ｎ＿１＿ｔのｍａｋｅ（）の定義例である。ｒｏｕｔｅ＿ｎ＿１＿ｔではｉｎｉ（）が呼ばれるたびにｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔのリストとアービターのリストは出来上がっていたが、トリッププランは完成していなかった。これに対して、定義２０００では、トリッププランを作成している。これにより、アーキテクチャの設定の自由度を上げて記述性を向上させている。
【０１１８】
（アーキテクチャのサンプル）
図２１は、アーキテクチャのサンプル例を示す説明図である。図２１において、アーキテクチャ２１００は、Ｂｌｏｃｋ０と、Ｂｌｏｃｋ１と、Ｂ．Ｂと、ｔａｒとを含む。Ｂｌｏｃｋ１には、ライトポートとリードポートがある。ライトポートは、小包の転送を行う。リードポートは、手紙の転送を行う。ｔａｒは、ターゲットである。ｔａｒは、手紙を受け取ると、小包を発送する。
【０１１９】
図２２は、アーキテクチャの接続記述例を示す説明図である。図２２において、トップ記述２２００は、図２１に示したアーキテクチャ２１００の接続記述例である。トップ記述２２００において、ａｒｂｉｔｅｒ＿ｔは３種類あり、ｎｏｒｔｈ，ｃｅｎｔｅｒ，ｓｏｕｔｈがある。
【０１２０】
接続は、ｉｎｓｔ０．ａにａ＿ｂｕｓ．ｉｎｉ（）を渡している。ａ＿ｂｕｓ．ｉｎｉ（）が呼ばれると、ｒｏｕｔｅ＿ｎ＿１＿ｔの中のｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔのベクタコンテナに１個ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔが置かれ、このインターフェースがｉｎｓｔ０．ａに渡される。ｉｎｓｔ０．ｂも同様である。
【０１２１】
つぎに、ｔａｒ０．ａにａ＿ｂｕｓが渡されている。ａ＿ｂｕｓのアービターとして、イニシエータ側からｎｏｒｔｈ，ｃｅｎｔｅｒ，ｓｏｕｔｈを渡している。ｎｏｒｔｈは、Ｂ．Ｂとイニシエータの間の配線のアービターである。ｓｏｕｔｈは、Ｂ．Ｂとターゲットの間の配線のアービターである。ｃｅｎｔｅｒは、Ｂ．Ｂそのもののアービターである。また、宣言時に数字が省略されている場合、リソース数は１である。
【０１２２】
ａｓｉｍ＿ｔ：：ｗａｖｅ＿ｏｎ（）は、「計測データのダンプの起動」である。ａｓｉｍ＿ｔ：：ｓｔａｒｔは、「アーキテクチャの生成」をした後、ｓｃ＿ｓｔａｒｔをするメソッドである。また、ＤＥＣＬは、マクロでＤＥＣＬ（ｎｏｒｔｈ）はｎｏｒｔｈ（"ｎｏｒｔｈ"）に展開される。ここで、周辺の回路記述例について説明する。
【０１２３】
図２３は、イニシエータの回路記述例を示す説明図である。図２３において、回路記述２３００は、イニシエータとなるブロックの回路記述例である。図２４は、ターゲットの回路記述例を示す説明図である。図２４において、回路記述２４００は、ターゲットとなるブロックの回路記述例である。
【０１２４】
図２５および図２６は、状態遷移例を示す説明図である。図２５において、グラフ２５００は、図２２〜図２４に示した各記述例を用いてシミュレーションを実行した場合の各ネゴシエーターの状態遷移を示している。図２５，２６中、ｂＲｅｓはｂｏｏｋＲｅｓｏｕｒｃｅ（ｒｅｓｏｕｒｃｅ＿ａｒｂｉｔｅｒ）を表している。ｂＲｏｕはｂｏｏｋＲｏｕｔｅ（ｒｏｕｔｅ＿ａｒｂｉｔｅｒ）を表している。ｍＴｏｋはｍｏｖｅＴｏｋｅｎを表している。
【０１２５】
グラフ２５００では、例えば、カーソル「ＴｉｍｅＡ」から「Ｂａｓｅｌｉｎｅ」までの間、ｃｅｎｔｅｒのアービターが占有されている。また、イニシエータ側の配線を通ってＢ．Ｂ上のバッファに書かれ始めてから、Ｂ．Ｂ上のバッファのデータがターゲットに書き終わるまでの間占有されている。グラフ２５００によれば、ｃｅｎｔｅｒのアービターが混んでいることがわかる。
【０１２６】
グラフ２６００は、センターのリソース数を２に増やした場合の各ネゴシエーターの状態遷移を示している。具体的には、ＤＥＣＬ（ｃｅｎｔｅｒ）をＤＥＣＬ＿ＶＡ（ｃｅｎｔｅｒ，２）にする。グラフ２６００では、Ｂ．Ｂの部分でイニシエータ発行の小包と手紙が同時に停泊したり、イニシエータ発行の小包とターゲット発行の小包が入れ替わったりしている様子が見て取れ、バスの動きを模擬できていることがわかる。
【０１２７】
このように、トリッププランを組み合わせることにより、バスの動作を比較的ショートな記述で書けるようになり生産性を向上させることができる。また、アーキテクチャのモデル化、特に、イベント、転送を示すトークン、転送経路とアービトレーションとリソース数によるイベントベースのシミュレーションが可能な環境を構築することができる。また、これは本モデルが規定するバスがシンプルな構成であることを意味し、バスモデル、および、これを具体化した回路は単純な制御によるデータ転送をすることができる。
【０１２８】
（構造情報の出力）
つぎに、構造情報（アーキテクチャ情報）の出力の実現方法について説明する。ここでは、図２２に示したトップ記述２２００のａｓｉｍ＿ｔ：：ｓｔａｒｔまでに宣言されたアーキテクチャ要素と接続関係を出力する場合を例に挙げて説明する。
【０１２９】
図２７は、構造情報に関するクラス図である。図２７に示すクラス図２７００において、ｓｅｔｕｐ＿ｔは、各種の設定を持つクラスである。ａｓｉｍ＿ｔは、ｓｅｔｕｐ＿ｔをクラス変数に持つクラスである。ａｓｉｍ＿ｔは、ネームスペースとして使用される。Ｍａｎ＿ｒｏｏｔ＿ｔは、管理オブジェクトを管理するルートクラスである。Ｍａｎ＿ｒｏｏｔ＿ｔは、クラス変数として、管理対象名（後述するｃｎａｍｅよりｔｙｐｅｉｄ（ｃｎａｍｅ）で生成）からＭａｎ＿ｉｆ＿ｔの参照へのｍａｐをクラス変数として持つ。
【０１３０】
Ｍａｎ＿ｉｆ＿ｔは、Ｍａｎ＿ｒｏｏｔ＿ｔへのポインタをクラス変数に持つ。Ｍａｎ＿ｔは、ｃｎａｍｅのクラスの管理オブジェクトである。ｃｎａｍｅへのポインタを管理している。また、Ｍａｎ＿ｔは、インスタンスされるとｍ＿ｒｏｏｔにＭａｎ＿ｔ＜ｃｎａｍｅ＞を登録する。Ｍａｎ＿ｔは、ｃｎａｍｅへのポインタのベクタをクラス変数として持つ。
【０１３１】
ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔは、ｃｎａｍｅ→ｒｏｕｔｅ＿ｎ＿１＿ｉｎｉ＿ｔとしたＭａｎ＿ｔの継承クラスである。このクラスがインスタンスされるとＭａｎ＿ｔのｍ＿ｍａｎ＿ｖｅｃｔｏｒに自分自身へのポインタを登録する。ｒｏｕｔｅ＿ｎ＿１＿ｔ，ｐｅｒｉｏｄ＿ｔも同様である。
【０１３２】
Ｍａｎ＿ｒｏｏｔ＿ｔ：：ｒｏｏｔ＿ｔｙｐｅから、全Ｍａｎ＿ｔが検索できる。さらに、Ｍａｎ＿ｔ＜ｃｎａｍｅ＞から、全ｃｎａｍｅのインスタンスが参照できる。このように、クラス図２７００によれば、主要部品の部品情報を出力することができる。ここで、部品情報の出力例について説明する。
【０１３３】
図２８は、部品情報の出力例を示す説明図である。図２８において、部品情報２８００は、本シミュレーション環境での定義をコンピュータリーダブルな形式で出力したものである。部品情報２８００は、例えば、デバッグ、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）、設計向けの定義データとして利用することができる。
【０１３４】
（プローブ情報の出力）
つぎに、プローブ情報の出力の実現方法について説明する。
【０１３５】
図２９は、プローブ情報に関するクラス図である。図２９に示すクラス図２９００において、ｐｒｏｂ＿ｒｏｏｔ＿ｔは、ｐｒｏｂ＿ｔへのポインタのベクタを持つ。ｐｒｏｂ＿ｔは、ｐｒｏｂ＿ｒｏｏｔ＿ｔをクラス変数に持つ。また、ｐｒｏｂ＿ｔは、自らをクラス変数ｍ＿ｒｏｏｔに登録する。
【０１３６】
ｐｒｏｂ＿ｘｘｘ＿ｔ（図２９中では、ｐｒｏｂ＿ｎｅｇｏ＿ｔ，ｐｒｏｂ＿ｃｏｍｐｌｅｘ０＿ｔ，ｐｒｏｂ＿ｐｒｉｍ＿ｔ）は、ｐｒｏｂ＿ｔを形式化した具体的な状態が定義されたクラスである。状態を可視化するオブジェクトは、ｐｒｏｂ＿ｘｘｘ＿ｔをインスタンスする。
【０１３７】
そして、オブジェクトは、状態遷移が起きたらｔｏ＜状態名＞（）というメソッドを呼んでｐｒｏｂ＿ｘｘｘ＿ｔの状態を変える。ｐｒｏｂ＿ｘｘｘ＿ｔは、この値（状態）をファイルに書き出す。このように、クラス図２９００によれば、プローブ情報を出力することができる。
【０１３８】
なお、ｐｒｏｂ＿ｔとｐｒｏｂ＿ｘｘｘとが分かれているのは、状態が異なるプローバーを定義しやすくするためである。ここで、状態の定義例について説明する。
【０１３９】
図３０は、状態の定義例を示す説明図である。図３０において、プローバー記述３０００は、状態のテーブルである。例えば、ＲＵＮ，ＩＤＬＥ，ＳＴＡＬＬのような状態は予め用意されている。一方、デコードモード、エンコードモードのようなアプリケーション特有の状態を持つ場合は、ユーザが状態を定義する。図３０中、ｃｏｍｐｌｅｘ０は、ユーザが定義した状態の一例である。
【０１４０】
このように定義することにより、ＰＲＯＢ＿ＸＸＸが、このような機能に相当するテンプレートクラスになっているので、ツールで該当機能を生成する処理を行うことができる。なお、プローバーで定義した状態値を観測するためには、周辺ブロック記述に状態が変わるタイミングで状態値を落とせるように記述を加えることにしてもよい。例えば，ｓｔａｔｅ．ＸＸＸＸがこれに相当する記述である。また、バスに関するデータ（データ流量など）についてはバス部品の中で落とすようになっている。ここで、図３１および図３２を用いて、プローバー記述３０００を実行した場合の出力例について説明する。
【０１４１】
図３１は、コンフィギュレーション情報の具体例を示す説明図である。図３１において、コンフィギュレーション情報一覧３１００は、プローバー記述３０００を実行した場合に、ａｓｉｍ＿ｔ：：ｓｔａｒｔ（）がコールされた段階で出力されるＩＤ番号と実体の一覧表である。
【０１４２】
コンフィギュレーション情報一覧３１００において、要素名ｃｏｎｆｉｇの開始タグと終了タグの間にコンフィギュレーション情報が書かれる。コンフィギュレーション情報には、要素名がｒｅｓｏｌｕｔｉｏｎとｐｒｏｂがある。要素名がｒｅｓｏｌｕｔｉｏｎのタグは、時間単位を表し、ｖａｌｕｅで指定された時間を１とする処理系であることを表す。要素名がｐｒｏｂは、プローバーに関する情報を表す。属性ｉｄは、プローバーのＩＤ番号を持つ。ｎａｍｅは、プローバーの名称を表す。
【０１４３】
図３２は、プローバー情報の具体例を示す説明図である。図３２において、プローバー情報３２００は、プローバー記述３０００の実行時に状態が変わるたびに出力される、発生時刻、ＩＤ番号、状態値および持続時間を表す情報である。
【０１４４】
具体的には、プローバー情報３２００は、ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）形式で４列ある。１列目は、イベントの発生時刻を示す。２列目はプローバーのＩＤ番号を示す。３列目は状態値を示す。４列目は、状態値が示す状態が続いた時間を示す。
【０１４５】
なお、ここでは状態値のプロービングの例のみを示しているが、コンフィギュレーション情報一覧３１００、プローバー情報３２００を拡張して流量や待ち時間を計測できるようにしてもよい。さらに、図３３に示すように拡張して、ａｓｉｍ＿ｔの配下でｔｒａｃｅ（ＶＡＲＩＡＢＬＥ，ｓｔｒｉｎｇ）で波形登録を可能にしてもよい。
【０１４６】
図３３は、波形ダンプの具体例を示す説明図である。図３３において、ｓｅｔｕｐは、ａｓｉｍ＿ｔの中にあるため、簡潔に書ける。波形ダンプは、ｓｃ＿ｓｔａｒｔ（）よりも前に実行されれば、ｖｉｒｔｕａｌ  ｍａｋｅ（）の中で定義してもよく、また、コンストラクタの中で定義してもよい。これにより、波形データ、すなわち、デバッグ情報を得ることができる。
【０１４７】
（シミュレーション装置９００のシミュレーション処理手順）
つぎに、実施の形態にかかるシミュレーション装置９００のシミュレーション処理手順について説明する。
【０１４８】
図３４は、シミュレーション装置９００のシミュレーション処理手順の一例を示すフローチャートである。図３４のフローチャートにおいて、まず、シミュレーション装置９００は、評価対象となるシステムに含まれる計算ブロックＢの周辺ブロック記述を取得する（ステップＳ３４０１）。
【０１４９】
つぎに、シミュレーション装置９００は、プローバー記述を取得する（ステップＳ３４０２）。つぎに、シミュレーション装置９００は、アーキテクチャシミュレーション記述を取得する（ステップＳ３４０３）。つぎに、シミュレーション装置９００は、シナリオ記述を取得する（ステップＳ３４０４）。
【０１５０】
そして、シミュレーション装置９００は、取得した周辺ブロック記述、プローバー記述、アーキテクチャシミュレーション記述およびシナリオ記述に基づいて、シミュレーションの実行ファイルを生成する（ステップＳ３４０５）。
【０１５１】
つぎに、シミュレーション装置９００は、生成したシミュレーションの実行ファイルを実行する（ステップＳ３４０６）。そして、シミュレーション装置９００は、シミュレーションの実行結果を出力して（ステップＳ３４０７）、本フローチャートによる一連の処理を終了する。これにより、アーキテクチャシミュレーションを実行することができる。
【０１５２】
（シミュレーションの実行結果の解析）
つぎに、シミュレーションの実行結果の解析について説明する。シミュレーションの実行結果の解析は、例えば、対話的に行われる。
【０１５３】
図３５は、シミュレーションの実行結果の解析例を示す説明図である。図３５において、シミュレーションの実行結果の解析を行う処理の手順が示されている。電力ライブラリは、周辺ブロックに対して、流量と状態値から電力を見積もれるようにした電力モデルを集めたライブラリである。
【０１５４】
ガントチャートは、周辺ブロックの状態を可視化したグラフである。流量波形データは、周辺ブロックごとに、指定されたサンプルの時間ごとに区切って流量を集計し、集計結果を可視化したグラフである。待ち時間波形データは、周辺ブロックごとに、指定されたサンプルの時間ごとに区切って待ち時間を集計し、集計結果を可視化したグラフである。
【０１５５】
電力波形データは、周辺ブロックごとに、指定されたサンプルの時間ごとに区切って電力を集計し、集計結果を可視化したグラフである。アーキテクチャ図は、アーキテクチャを示す記述（例えば、図２２に示したトップ記述２２００）を可視化した図面である。
【０１５６】
開発者は、例えば、シミュレーションの実行結果を用いて、ガントチャート作成、流量データ作成、待ち時間データ作成、電力データ作成、アーキテクチャ図作成等を行うことができる。また、このような可視化図面を作るためには記述に用いられる言語を解析して図示するツールが用いられるが、本実施の形態では、図示すべきデータをアーキテクチャシミュレーション時に生成し、このデータを可視化するため、ツールの複雑度が小さい方式といえる。
【０１５７】
図３６〜図３８は、アーキテクチャシミュレーション解析ビューアーの一例を示す説明図である。図３６において、アーキテクチャシミュレーション解析ビューアー３６００は、ガントチャートを表示するガントチャート表示部３６１０と、電力波形データを表示する電力波形表示部３６２０と、流量波形データを表示する流量波形表示部３６３０と、待ち時間波形データを表示する待ち時間波形表示部３６４０と、を含む。
【０１５８】
図３７において、アーキテクチャシミュレーション解析ビューアー３７００は、回路構成を表示する回路構成表示部３７１０を含む。図３８において、アーキテクチャシミュレーション解析ビューアー３８００は、インスタンスとライブラリ名とを関連付けて表す関連付け表を表示する関連付け表表示部３８１０を含む。
【０１５９】
アーキテクチャシミュレーション解析ビューアー３６００，３７００，３８００によれば、アーキテクチャシミュレーション解析ビューを構成することができる。また、アーキテクチャシミュレーション解析ビューアー３７００をアーキテクチャシミュレーションのエントリとして利用可能にすることにより、統合環境としての利用も可能になる。
【０１６０】
以上説明したように、実施の形態にかかるシミュレーション装置９００によれば、バスモデルＢＭを介してメモリモデルＭＭに対する指定サイズ分のデータの読み書きを行い、指定サイクル分の遅延を発生させて計算時間を再現する計算ブロックＢを用いてシステムの性能評価シミュレーションを実行することができる。これにより、評価対象となるシステム内の計算ブロックＢにかかるモデル記述を簡素化して、シミュレーションモデルの作成にかかる時間や手間を削減してシミュレーション期間の短縮化を図ることができる。
【０１６１】
また、シミュレーション装置９００によれば、ライトアクセスを「データ発送」でモデル化し、リードアクセスを「データ発注書のデータ発送」と「発注されたデータのデータ発送」でモデル化することにより、シミュレーションモデルを単純化することができる。
【０１６２】
また、シミュレーション装置９００によれば、バスモデルＢＭは、バッファを有するネゴシエーターモデルと、バッファへのアクセスを排他制御するアービターモデルと、を有することにしてもよい。また、ネゴシエーターモデルは、データ発注書の転送要求を受け付けた場合、アービターモデルの排他制御に従って、データ発注書をバッファに書き込み、バッファに書き込まれたデータ発注書をメモリモデルＭＭに書き込んだ後にバッファを解放することにしてもよい。これにより、複数の計算ブロックＢがバスモデルＢＭにアクセスする際にバスモデルＢＭの使用を一時的に制限する排他制御のシミュレーションを再現することができる。
【０１６３】
また、シミュレーション装置９００によれば、結線データ（例えば、部品情報２８００）、計測コンフィギュレーションデータ（例えば、コンフィギュレーション情報一覧３１００）、計測データ（例えば、プローバー情報３２００）などのシミュレーションの実行結果を出力することができる。
【０１６４】
これらのことから、シミュレーション装置９００によれば、シミュレーションモデルの作成工数を削減してシミュレーション期間を短縮させることにより、設計初期における性能評価、電力見積を可能にして商談、仕様検討に有益な情報を提供することができる。
【０１６５】
なお、本実施の形態で説明したシミュレーション方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本シミュレーションプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本シミュレーションプログラムは、インターネット等のネットワークを介して配布してもよい。
【０１６６】
上述した実施の形態に関し、さらに以下の付記を開示する。
【０１６７】
（付記１）コンピュータに、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行させることを特徴とするシミュレーションプログラム。
【０１６８】
（付記２）前記ブロックは、前記計算処理にかかるリードデータ量のデータを読み込む読込処理を行う読込部と、前記計算処理にかかるサイクル数分の遅延を発生させる計算部と、前記計算処理にかかるライトデータ量のデータを書き込む書込処理を行う書込部とを含み、
前記読込部は、前記シナリオブロックまたは前記計算部からの起動信号を検出したら前記読込処理を行って前記計算部に起動信号を発行し、
前記計算部は、前記ブロックの動作周波数に基づいて、前記読込部からの起動信号を検出してから前記計算処理にかかるサイクル数分の時間が経過したら前記書込部に起動信号を発行するとともに、前記書込部からの起動信号を検出したら前記読込部に起動信号を発行し、
前記書込部は、前記計算部からの起動信号を検出したら前記書込処理を行って前記計算部に起動信号を発行するとともに、前記計算処理の回数分の書込処理を行った場合に前記シナリオブロックに終了信号を発行することを特徴とする付記１に記載のシミュレーションプログラム。
【０１６９】
（付記３）前記バスモデルは、前記ブロックから前記リードデータ量のデータの発注書の転送要求を受け付けると、前記発注書を前記メモリモデルに書き込み、前記メモリモデルによって前記リードデータ量のデータが書き込まれると、前記ブロックに前記リードデータ量のデータを送信し、
前記メモリモデルは、前記バスモデルによって前記発注書が書き込まれると、前記リードデータ量のデータを前記バスモデルに書き込むことを特徴とする付記２に記載のシミュレーションプログラム。
【０１７０】
（付記４）前記バスモデルは、前記ブロックからライトデータ量のデータの転送要求を受け付けると、前記ライトデータ量のデータを前記メモリモデルに書き込むことを特徴とする付記３に記載のシミュレーションプログラム。
【０１７１】
（付記５）前記バスモデルは、バッファを有するネゴシエーターモデルと、前記バッファへのアクセスを排他制御するアービターモデルと、を有し、
前記ネゴシエーターモデルは、前記発注書の転送要求を受け付けた場合、前記アービターモデルの排他制御に従って、前記発注書を前記バッファに書き込み、前記バッファに書き込まれた前記発注書を前記メモリモデルに書き込んだ後に前記バッファを解放することを特徴とする付記４に記載のシミュレーションプログラム。
【０１７２】
（付記６）前記コンピュータに、
実行した前記アーキテクチャモデルのシミュレーションの実行結果を出力する処理を実行させることを特徴とする付記５に記載のシミュレーションプログラム。
【０１７３】
（付記７）コンピュータに、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行させるシミュレーションプログラムを記録したことを特徴とする前記コンピュータに読取可能な記録媒体。
【０１７４】
（付記８）複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得する第１処理部と、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得する第２処理部と、
前記第１処理部によって取得された前記アーキテクチャモデルと前記第２処理部によって取得された前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する第３処理部と、
を有することを特徴とするシミュレーション装置。
【０１７５】
（付記９）複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得する第１処理部と、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得する第２処理部と、
前記第１処理部によって取得された前記アーキテクチャモデルと前記第２処理部によって取得された前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する第３処理部と、
を有するコンピュータを含むことを特徴とするシミュレーション装置。
【０１７６】
（付記１０）コンピュータが、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行することを特徴とするシミュレーション方法。
【０１７７】
（付記１１）リード要求相当の動作として、あるブロックからデータの発注書を転送し、別のあるブロックが発注書を受信し、それに対応したデータを小包として発送する手段と、ライト要求相当の動作として、あるブロックから小包を発送する手段があり、データの一部に転送先などの制御情報をもち、転送を行う回路はこれらを解釈して所望のデータ転送を実現する手段をもったバスモデル、および、バス回路。
【符号の説明】
【０１７８】
９００  シミュレーション装置
１００１  取得部
１００２  生成部
１００３  実行部
１００４  出力部
Ｂ  計算ブロック
ＢＭ  バスモデル
ＭＭ  メモリモデル
ＳＢ  シナリオブロック
【手続補正書】
【提出日】平成28年4月11日(2016.4.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータに、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行させることを特徴とするシミュレーションプログラム。
【請求項２】
前記ブロックは、前記計算処理にかかるリードデータ量のデータを読み込む読込処理を行う読込部と、前記計算処理にかかるサイクル数分の遅延を発生させる計算部と、前記計算処理にかかるライトデータ量のデータを書き込む書込処理を行う書込部とを含み、
前記読込部は、前記シナリオブロックまたは前記計算部からの起動信号を検出したら前記読込処理を行って前記計算部に起動信号を発行し、
前記計算部は、前記ブロックの動作周波数に基づいて、前記読込部からの起動信号を検出してから前記計算処理にかかるサイクル数分の時間が経過したら前記書込部に起動信号を発行するとともに、前記書込部からの起動信号を検出したら前記読込部に起動信号を発行し、
前記書込部は、前記計算部からの起動信号を検出したら前記書込処理を行って前記計算部に起動信号を発行するとともに、前記計算処理の回数分の書込処理を行った場合に前記シナリオブロックに終了信号を発行することを特徴とする請求項１に記載のシミュレーションプログラム。
【請求項３】
前記バスモデルは、前記ブロックから前記リードデータ量のデータの発注書の転送要求を受け付けると、前記発注書を前記メモリモデルに書き込み、前記メモリモデルによって前記リードデータ量のデータが書き込まれると、前記ブロックに前記リードデータ量のデータを送信し、
前記メモリモデルは、前記バスモデルによって前記発注書が書き込まれると、前記リードデータ量のデータを前記バスモデルに書き込むことを特徴とする請求項２に記載のシミュレーションプログラム。
【請求項４】
前記バスモデルは、前記ブロックからライトデータ量のデータの転送要求を受け付けると、前記ライトデータ量のデータを前記メモリモデルに書き込むことを特徴とする請求項３に記載のシミュレーションプログラム。
【請求項５】
前記バスモデルは、バッファを有するネゴシエーターモデルと、前記バッファへのアクセスを排他制御するアービターモデルと、を有し、
前記ネゴシエーターモデルは、前記発注書の転送要求を受け付けた場合、前記アービターモデルの排他制御に従って、前記発注書を前記バッファに書き込み、前記バッファに書き込まれた前記発注書を前記メモリモデルに書き込んだ後に前記バッファを解放することを特徴とする請求項４に記載のシミュレーションプログラム。
【請求項６】
前記コンピュータに、
実行した前記アーキテクチャモデルのシミュレーションの実行結果を出力する処理を実行させることを特徴とする請求項５に記載のシミュレーションプログラム。
【請求項７】
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得する第１処理部と、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得する第２処理部と、
前記第１処理部によって取得された前記アーキテクチャモデルと前記第２処理部によって取得された前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する第３処理部と、
を有することを特徴とするシミュレーション装置。
【請求項８】
コンピュータが、
複数のブロックに起動信号を発行するとともに前記複数のブロックからの終了信号を検出するシナリオブロックと、前記複数のブロックとメモリモデルとを接続するとともに前記ブロックから前記メモリモデルへのアクセスを制御するバスモデルと、前記バスモデルを介して前記メモリモデルにアクセスして計算処理を行う前記複数のブロックと、を含むアーキテクチャモデルを取得し、
前記ブロックごとに、一連の処理で行われる計算処理の回数と、前記計算処理にかかるサイクル数と、前記計算処理にかかるリードデータ量と、前記計算処理にかかるライトデータ量と、前記ブロックの動作周波数と、を示すシナリオ記述を取得し、
前記アーキテクチャモデルと前記シナリオ記述とに基づいて、前記アーキテクチャモデルのシミュレーションを実行する、
処理を実行することを特徴とするシミュレーション方法。
【国際調査報告】
2014064788.tif 000041
2014064788.tif 000042
2014064788.tif 000043
2014064788.tif 000044
2014064788.tif 000045
2014064788.tif 000046