JP4268830B2 - アーキテクチャのシミュレーションシステム及びシミュレーション方法 - Google Patents
アーキテクチャのシミュレーションシステム及びシミュレーション方法 Download PDFInfo
- Publication number
- JP4268830B2 JP4268830B2 JP2003136240A JP2003136240A JP4268830B2 JP 4268830 B2 JP4268830 B2 JP 4268830B2 JP 2003136240 A JP2003136240 A JP 2003136240A JP 2003136240 A JP2003136240 A JP 2003136240A JP 4268830 B2 JP4268830 B2 JP 4268830B2
- Authority
- JP
- Japan
- Prior art keywords
- arbiter
- path
- route
- exclusive control
- simulation system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、デジタルシステムのアーキテクチャを自動構成するための設計環境を提供するシミュレーションシステム及びシミュレーション方法に関するものである。
【０００２】
【従来の技術】
近年、オブジェクト指向モデリングに基づき、設計者が指定したデータから、アーキテクチャを自動構成するためのデータベース及びデータベース管理機構を含むシミュレーション方式が開発されつつある。この環境を実現するオブジェクトは、ＳｙｓｔｅｍＣのようなオブジェクト指向言語に基づくシミュレーション環境のライブラリとして実装し、ＳｙｓｔｅｍＣのようなオブジェクト指向言語によるソースコードをコンパイル処理する際にシミュレーション用の記述と一緒に読み込まれ、シミュレーションを実行する実行コードの中に埋め込まれ、実行時に、データベースが作成され、シミュレーション実行中に適宜参照され、所望の動作を実現するものである。
【０００３】
なお、本発明に関連する従来の技術として、特開平１１−３３６７号公報には、デジタルシステムのインプリメント可能な記述を生成する設計環境及び方法が開示されている。
【０００４】
【特許文献１】
特開平１１−３３６７号公報
【０００５】
【発明が解決しようとする課題】
従来の方式では、基本的オブジェクトのみを利用して記述しているため、所望の動作をさせるために多くの記述を必要としていた。従来の方式で用いられる記述は、実際の回路の記述に近い記述で直感的ではあるが、アーキテクチャの動作を再現する目的からすると冗長である。
【０００６】
また、従来の方式では、バス／セレクタなど排他制御を行うオブジェクトと、転送を実現するチャネル・オブジェクトとが直接関係していないことが問題をさらに複雑化にしている。このような実現方法をとっているため、バス／セレクタとチャネルの制御を機能ブロック内で行わなければならず、記述量／記述変更量の増加を引き起こしている。
【０００７】
従来の方式では、しばしば、アービトレーション・アルゴリズムをバスモデルの記述中に入れる必要がある。このような記述がポートを増やす原因、バス・アクセスの書き換えの要因となっている。
【０００８】
例えば、図３の処理を実現するアーキテクチャとして、図４乃至図６のアーキテクチャ例とマッピングで設計しようとする場合、従来の方式を用いると、設計者は、図７乃至図９のようにそれぞれ記述する必要がある。
【０００９】
図３の処理は、機能ブロック１（２１）、機能ブロック２（２２）、機能ブロック３（２３）、機能ブロック４（２４）の間でデータを、図３の矢印で示したように転送する処理（転送１、転送２、転送３、転送４）である。
【００１０】
図４の（ａ）で示したアーキテクチャ例では、各転送をバス１、アービタ２５を用いて実現する。図４の（ｂ）で示したマッピングでは、転送１、転送２、転送３、転送４のイニシエータを、それぞれ、機能ブロック１、機能ブロック２、機能ブロック３、機能ブロック１としている。
【００１１】
図５の（ａ）で示したアーキテクチャ例では、転送２のみをバス１と異なるデータ線を用いて実現する。図５の（ｂ）で示したマッピングでは、転送１、転送２、転送３、転送４のイニシエータを、それぞれ、機能ブロック１、機能ブロック２、機能ブロック３、機能ブロック１としている。
【００１２】
図６の（ａ）で示したアーキテクチャ例では、各転送をバス１、バス２、アービタ２５、セレクタ２６を用いて実現する。図６の（ｂ）で示したマッピングでは、転送１と転送２には、バス１を使用し、転送３と転送４には、バス２を用いる。また、転送１、転送２、転送３、転送４のイニシエータを、それぞれ、機能ブロック１、機能ブロック２、機能ブロック３、機能ブロック１としている。
【００１３】
図７に示したアクセスの記述２０Ａでは、チャネル１（３１）での転送を定義するため、ポート２１１とポート２２１を、チャネル２（３２）での転送を定義するため、ポート２２２とポート２３１を、チャネル３（３３）での転送を定義するため、ポート２３３とポート２４１を、チャネル４（３４）での転送を定義するため、ポート２１３とポート２４２をそれぞれ記載している。例えば、チャネル１で機能ブロック１と機能ブロック２間の転送（転送１）をするには、バスリクエスト、バスグラント待ち等のアービトレーションを行うため、バス３５と連結させたポート２１２とポート２２３を用いる必要がある。バス３５の内部の詳細を記述するブロック３５Ａでは、排他制御とアービトレーションを定義する必要がある。
【００１４】
図８の記述２０Ａでは、図７の記述と同様に、チャネル１で機能ブロック１と機能ブロック２間の転送（転送１）をするには、バスリクエスト、バスグラント待ち等のアービトレーションを行うため、バス３５と連結させたポート２１２とポート２２３を用いる必要がある。同時に、バス３５の内部の詳細を記述するブロック３５Ａで、排他制御とアービトレーションを記述する必要がある。また、ダミーバス１（３６）での転送を定義するため、ポート２２３を用いる必要がある。
【００１５】
図９の記述２０Ａでは、セレクタ２６、バス１（３７）、バス２（３８）を定義するため、各機能ブロックにさらに余分なポートを設ける必要がある。例えば、チャネル１で機能ブロック１と機能ブロック２間の転送（転送１）をする際には、バス１リクエスト、セレクタリクエスト、バス１グラント待ち、セレクタグラント待ち等のアービトレーションを行うため、バス１（３７）と連結させたポート２１２とポート２２３、及びセレクタ２６と連結させたポート２１４とポート２３３を用いる必要がある。
【００１６】
従来の方式を用いて、設計者が、図７の記述例を図８の記述例に変更する場合、直結を表すために本来不要であるダミーバスを加える必要があり、設計者に不要な手間をかけることになる。
【００１７】
あるいは、図７の記述例から図９の記述例に変更する場合、増やしたバス／セレクタのデータを機能ブロックに伝播させるため、ポートを増やす必要がある。さらに、所望の動作になるように、バスにアクセスするための記述を書き直さなければならず、設計者に不要な手間をかけることになる。
【００１８】
図１０の記述２０Ａは、従来の方式を用いて、図４のアーキテクチャ例の場合の性能評価データのダンプをとる例を示す。ファイル２７への性能評価データの転送を定義するため、ポート２１３、ポート２２４、ポート２４３等をさらに用いる必要がある。
【００１９】
性能評価をする場合には、図１０の記述例のようにファイルを受け渡す必要があり、バスアクセスの記述に設計者がファイルアクセスを適切に加える必要があり、設計者に不要な手間をかけることになる。
【００２０】
これらの手間は、従来のシミュレーション方式を用いた場合に必要となる記述であり、目的のシミュレーションにおいて本質的な記述ではないため、非効率的である。
【００２１】
同様の理由から、機能ブロック内部または機能ブロックとバスを仲介するブロックの中にあるオブジェクトのデータをダンプする場合には記述量がかかる。このような例としてメモリがある。メモリはメモリ使用量などの計測を行う必要がある。
【００２２】
機能ブロックの中には複数のバス・アクセスを表現する記述が含まれることがある。この場合、あるバス・アクセス記述の処理が終わってから、次のバス・記述の開始までｎサイクル遅延させて、このイベントがパイプライン的に起きることがある。これを実現するために、どちらかをサイクルベースの記述にして、複数のカウンタを用意して、所望のサイクルになったらイベントを伝播するなどの方法がとられていた。更に、なんらかの理由で動作が停止する場合には、カウンタを停止する処理の記述を書き加える方法がとられている。このため、これらの方法では手間がかかり、記述量が多くなっていた。
【００２３】
本発明は、上記の点に鑑みてなされたものであり、アーキテクチャのシミュレーションを行う際に設計者が記述する記述量を削減すると共に、アーキテクチャを変更する際に必要となる記述量を削減することで、性能評価データを簡単に集計できるようにするアーキテクチャのシミュレーションシステム及びシミュレーション方法を提供することを目的とする。
【００２４】
【課題を解決するための手段】
上記課題を解決するため、本発明のシミュレーションシステムは、バスを介し接続された複数の機能ブロックと、転送経路と、アービタとを含むアーキテクチャを、設計者がハードウェア設計用のオブジェクト指向言語を用いて記述した、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを含むソースコードをコンパイル処理して実行コードを生成するシミュレーションシステムであって、前記排他制御オブジェクトを管理するための排他制御管理データベースと、前記経路オブジェクトを管理するための経路管理データベースと、前記アービタオブジェクトを管理するためのアービタ管理データベースとを有し、前記シミュレーションシステムが、前記排他制御オブジェクト、前記経路オブジェクト、及び前記アービタオブジェクトから生成した各実行コードにより、前記排他制御オブジェクト、前記経路オブジェクト、及び前記アービタオブジェクトを参照するための識別データを前記排他制御管理データベース、前記経路管理データベース、及び前記アービタ管理データベースにそれぞれ登録し、前記シミュレーションシステムが、設計者の記述した前記経路オブジェクトへの前記排他制御オブジェクトのアサインから生成した実行コードにより、前記排他制御オブジェクトを前記経路オブジェクトの内部領域に登録し、 前記シミュレーションシステムが、設計者の記述した前記アービタオブジェクトへの前記排他制御オブジェクトのアサインから生成した実行コードにより、前記アービタオブジェクトが制御する前記排他制御オブジェクトを含む経路オブジェクトを全て前記アービタオブジェクトの内部領域に登録することにより、シミュレーション実行時に、各管理データベースと通信する機能を提供して、前記アーキテクチャの性能評価データを生成することを特徴とする。
【００２６】
本発明のシミュレーション方式によれば、従来方式で処理やアーキテクチャを記述する場合に必要であった機能ブロック内部の記述、ポートの書き換えが不要となり、設計者による記述の量や記述の変更量を削減することができる。また、本発明のシミュレーション方式では、パイプラインイベントオブジェクトを使用すると、従来方式のようにカウンタの記述をすることなく、通常のイベントと同様に、イベント発行とイベント受理で記述することができ、少ない記述量で所望の動作を実現できる。
【００２７】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００２８】
本発明の一実施例として、ＳｙｓｔｅｍＣを利用したアーキテクチャのシミュレーションシステムを示す。
【００２９】
本発明のシミュレーションシステムでは、図２に示した管理オブジェクトを含むデータベースを利用する。
【００３０】
図２の経路管理オブジェクト１１１、排他制御管理オブジェクト１１２、アービタ管理オブジェクト１１３は、それぞれ経路オブジェクト、排他制御オブジェクト、アービタオブジェクトの参照を保持するデータベース（ライブラリ）である。
【００３１】
データダンプオブジェクト１１４は、経路管理オブジェクト１１１、排他制御管理オブジェクト１１２、アービタ管理オブジェクト１１３の参照を持ち、アーキテクチャの構成をダンプする（図１の１１４）。データダンプオブジェクト１１４は、サンプリングクロックオブジェクト１１８のサンプリングクロックに同期して性能評価データをファイルに記録する（図１の１１５）ため、経路管理オブジェクト１１１を経由して経路オブジェクトが保持する性能データをファイルに反映させるとともに、次の計測が開始できる状態にリセットする。
【００３２】
経路管理オブジェクト１１１、排他制御管理オブジェクト１１２、アービタ管理オブジェクト１１３の実装の一形態として、それぞれの管理オブジェクトをシングルトンとして実装する方法がある。シングルトンとしての実装の一例として、経路オブジェクト、排他制御オブジェクト、アービタオブジェクトのｓｔａｔｉｃ＿ｍｅｍｂｅｒ変数とし、ライブラリ内でこれらの管理オブジェクトを宣言しておく方法がある。
【００３３】
図１は、本発明の一実施例に係るアーキテクチャのシミュレーションシステムを示す。
【００３４】
図１のシミュレーションシステム１００は、図２に示すデータモデルをもつデータベース（ライブラリ）を使用して、設計者がデジタルシステムのアーキテクチャ（シミュレーションモデル）のソースコードを記述することを可能にする。シミュレーションシステム１００は、このソースコードをコンパイル処理してシミュレーション実行コードを生成する。データベースの作成、アーキテクチャの自動構成はこの実行コードの中で行われる。
【００３５】
最初に、設計者が記述するソースコードに含まれる、各オブジェクトのデータ構造について説明する。このソースコードは、少なくとも、経路オブジェクト、アービタオブジェクト、排他制御オブジェクトを含む。
【００３６】
排他制御オブジェクトは、通常Ｍｕｔｅｘと呼ばれるものと同一である。
【００３７】
経路オブジェクト、アービタ基底クラスについてはクラス図でデータ構造を示す。ただし、ここでは属性になっている個々のオブジェクトを、見やすくするため、クラスとこのクラスに含まれるメンバーのオブジェクトを関係「もっている」で関連づけて表記してある。また、ネストクラスがある場合には、関係「ネストクラス」で明示した。
【００３８】
図１６は、経路オブジェクトのデータ構造を示す。
【００３９】
図１６に示したように、経路クラス１３１は、ビート数６１、稼働時間６２、開始時間６３をもっている。また、経路クラス１３１は、経路状態６４、排他制御リスト６５、アービタのイベントリスト６６、ｒｅｑｕｅｓｔ＿ｅｖｅｎｔ６７、ｇｒａｎｔ＿ｅｖｅｎｔ６８、ｓｅｎｄ＿ｅｖｅｎｔ６９、ｅｎｄ＿ｅｖｅｎｔ７０、転送数カウンタ７１をもっている。
【００４０】
また、本実施例のシミュレーションシステム１００は、図１５のような経路オブジェクトの状態を管理するＦＳＭ（ｆｉｎｉｔｅ＿ｓｔａｔｅ＿ｍａｃｈｉｎｅ）を備えている。図１５に示したように、このＦＳＭは、イベントの発生状況に応じて、アイドル状態５１、グラント状態５２、送信待ち状態５３、終了待ち状態５４、送信中状態５５の中で、経路オブジェクトがある1つの状態から別の状態への遷移を監視している。図１６に示した経路状態６４がこのＦＳＭに相当する。
【００４１】
図１６に示したｅｖｅｎｔ型は、シミュレーション・ライブラリが提供するイベント型の機能を表す。ＳｙｓｔｅｍＣの場合、ｓｃ＿ｅｖｅｎｔがこのイベント型に相当する。
【００４２】
排他制御リスト６５は、この経路オブジェクトが表現する経路が使用する排他制御オブジェクトの集合を保持するリスト（または集合）である。
【００４３】
アービタのイベントリスト６６は、図１７のｗａｋｅｕｐ＿ｅｖｅｎｔの参照を保持するリストである。このリストには、経路が使用する排他制御オブジェクトを制御するアービタのｗａｋｅｕｐ＿ｅｖｅｎｔの参照をあつめている。
【００４４】
このイベントリスト６６は、経路オブジェクトがｒｅｑｕｅｓｔを受付けたときに、この経路オブジェクトが使用する排他制御オブジェクトを制御するアービタを起動するために使用する。
【００４５】
図１６のｒｅｑｕｅｓｔ＿ｅｖｅｎｔ６７、ｇｒａｎｔ＿ｅｖｅｎｔ６８、ｓｅｎｄ＿ｅｖｅｎｔ６９、ｅｎｄ＿ｅｖｅｎｔ７０は、ｒｅｑｕｅｓｔ（転送要求）、ｇｒａｎｔ（転送受付）、ｓｅｎｄ（転送開始）、 ｅｎｄ（バスの開放）を送信元と送信先の機能ブロック間、又は機能ブロックとアービタ間で通信するために使用される。
【００４６】
転送数カウンタ７１は、転送したビート数をカウントする機能ブロックである。ビート数６１は、転送ビート数を保持する。稼働時間６２は、単位時間当たりの経路の活性化した時間の合計を保持する。開始時間６３は、活性化した時間を保持する。稼働時間６２は、主にデータダンプオブジェクト１１４により参照され、データダンプオブジェクト１１４を駆動しているサンプリングクロックの時間でこの稼働時間６２を割算することで経路オブジェクトの活性化率を算出することができる。
【００４７】
次に、アービタ基底クラス１３３について説明する。
【００４８】
実際に使うアービタクラスは、このアービタ基底クラス１３３から継承したクラスを作成し、この中にアービタアルゴリズムを記述したクラスである。この作成したクラスのオブジェクトを使ってアービトレーションをする。アービタ基底クラス１３３は、少なくとも、アービタが共通してもつ経路オブジェクトと通信する機能を実装したものである。
【００４９】
図１７は、アービタ基底クラス１３３のデータ構造を示す。
【００５０】
アービタはクロックに同期して動く。ＳｙｓｔｅｍＣによる実装の場合、通常クロックに同期するオブジェクトはｓｃ＿ｍｏｄｕｌｅの継承クラスであることから、図１７ではアービタ基底クラス１３３をｓｃ＿ｍｏｄｕｌｅ７０の継承クラスとした。
【００５１】
アービタ基底クラス１３３に含まれるオブジェクトについて説明する。アービタ基底クラス１３３は、排他制御オブジェクトの参照を保持する排他制御リスト７４をもっている。アービタ基底クラス１３３は、このアービタが制御する経路オブジェクトの一覧を保持する経路リスト７５をもっている。また、アービタ基底クラス１３３は、ｅｖｅｎｔ型のｗａｋｅｕｐ＿ｅｖｅｎｔ７６をもっている。このイベントは、経路リスト７５からリクエストが到着した時にイベントを発生する。
【００５２】
このイベントを使用することにより、リクエストが来たタイミングで、アービトレーションの処理を開始または再開するようなアービトレーション・アルゴリズムを少ない記述量で記述することを可能にする。
【００５３】
また、アービタ基底クラス１３３のネストクラスとして、ある時点でリクエストを発行した経路オブジェクトの一覧を優先順位順にスキャンするイテレータ（ｉｔｅｌａｔｏｒ）クラス７３をもっている。これにより、スキャンの記述量が削減できる。
【００５４】
アービタ基底クラス１３３から継承クラスを作成する方法の例として、ＦＣＦＳを実装する記述例を図２２に示す。ＦＣＦＳは過去のリクエストを蓄える履歴リストをもっている。
【００５５】
図２２に示したように、履歴リストが空ならば、新しいリクエストが来るまでは何もすることがないので、ｗａｉｔ（ｗａｋｅｕｐ＿ｅｖｅｎｔ）でイベントの発生をまつ。つまり、新しいリクエストを待つ。
【００５６】
次に、ｗａｉｔ（０，ＳＣ＿ＮＳ）でデルタ遅延の時間間隔だけ待つ。バッファが空ではなかったら、次のサイクルを待って、更にデルタ遅延だけ待って、履歴リストに含まれているリクエストを順次評価する。
【００５７】
ｇｒａｎｔが可能（すなわち、ｇｒａｎｔ対象の経路オブジェクトが使用する排他制御オブジェクトすべてがｏｐｅｎ）であれば、そのリクエストを履歴リストから除外し、ｇｒａｎｔを出力する。一方、ｇｒａｎｔできなければ、そのままにしておく。
【００５８】
この後、現在到着したリクエストの集合を、優先順位に従って、順次評価する。ｇｒａｎｔ可能なリクエストに対しては、ｇｒａｎｔ信号を送出し、リクエストがｇｒａｎｔ不可能な場合には、ｇｒａｎｔ信号を受信したことを履歴リストに記録する。
【００５９】
このようにして、アービタ基底クラスから継承クラスを作成して所望のアービタを実現することができる。
【００６０】
この方式では、アービトレーション・アルゴリズムが同一であれば、複数の排他制御オブジェクトを一つのアービタで制御することができ、少ない記述で済ませることができる。また、イテレータにより少ない記述でアービトレーション・アルゴリズムを記述できる。
【００６１】
次に、図１を用いて、本実施例のシミュレーションシステム１００による、ソースコードの初期化手順について説明する。
【００６２】
図１中、設計者の記述と示された部分は、設計者（ユーザ）が記述するソースコードの部分である。本実施例のシミュレーションシステム１００は、図２のデータモデルを利用して、自動でアーキテクチャを構成する。
【００６３】
シミュレーションの実行１２７に対しては、シミュレーションを実行するとともに、性能評価データ１１５がダンプされる。
【００６４】
また、性能評価データ１１５の解析をするために、設計者（ユーザ）が指定したアーキテクチャ情報がダンプされたアーキテクチャ構造データ１１９が生成される。また、経路の状態を波形で観察したい場合がある。この波形データは、シミュレーション実行中、波形データ１１６にダンプされる。
【００６５】
図１９と図２０は、設計者によるＳｙｓｔｅｍＣを用いたソースコードの記述例を示す。具体的には、図１９はメイン関数の記述例を示し、図２０はトップ階層の記述例を示す。
【００６６】
図１９において、（１）に示した記述でトップモジュールを宣言している。（４）に示した記述で性能評価ファイル名を渡し、（５）に示した記述でサンプリング・クロックを与えている。（４）と（５）の記述は、図１の性能評価データ用指定１２６に相当する。（２）に示した記述で波形ファイルを宣言している。この記述方法はＳｙｓｔｅｍＣによる。（３）に示した記述で波形ファイルをシミュレーションシステムに渡している。（２）と（３）の記述は、図１の波形ファイル指定１２５に相当する。
【００６７】
図１９において、（３）に示した記述で波形ファイルのポインタをｎａｍｅｓｐａｃｅ ｏｏの経路クラス（ｒｏｕｔｅ）の（ｓｔａｔｉｃ ｍｅｍｂｅｒ変数で宣言されている）経路管理オブジェクト（ｈｅａｄ）に渡している。（３）の記述は図１の波形ファイル指定１２５に相当する。（６）に示した記述でシミュレーションを実行している。この記述はＳｙｓｔｅｍＣによる。（６）の記述は図１のシミュレーション実行１２７に相当する。
【００６８】
図２０は図１９における（１）の記述で宣言しているトップモジュールの記述例である。図２０において、ｏｏ：：ｒｏｕｔｅは経路クラス、ｏｏ：：ｅｘｃｌｕｓｉｖｅは排他制御クラス、ｆｃｆｓ＿ａｒｂｉｔｅｒはアービタ基底クラスから継承して作られたクラス、ｂｌｏｃｋ１〜ｂｌｏｃｋ４は処理ブロックの記述をしたクラスである。
【００６９】
図２０において、ＳＣ＿ＣＴＯＲ（ｔｏｐ）はＳｙｓｔｅｍＣの記述方法でコンストラクタである。コンストラクタの内容をｔｏｐ：：ｔｏｐ（ｓｃ＿ｍｏｄｕｌｅ＿ｎａｍｅ）以降に記述している。ｒｏｕｔｅ１〜ｒｏｕｔｅ４の宣言、ｂｕｓ１の宣言、ａｒｂ１の宣言はそれぞれ、図１の経路オブジェクトのコンストラクション１２０、排他制御オブジェクトのコンストラクション１２１、アービタオブジェクトのコンストラクション１２２に相当する。「ｒｏｕｔｅ１〜ｒｏｕｔｅ４．登録処理（ｂｕｓ１）」としている記述が図１の経路オブジェクトへの排他制御オブジェクトのアサイン１２３に相当する。「ａｒｂ１．登録処理（ｂｕｓ１）」としている記述が図１のアービタオブジェクトへの排他制御オブジェクトのアサイン１２４に相当する。
【００７０】
図１において、実行コード１０１は経路管理オブジェクトに自分自身を参照できるデータを渡す（登録する）。これにより、任意の経路オブジェクトは経路管理オブジェクトから参照できるようになる。同様に、実行コード１０２、１０３により、排他制御オブジェクト、アービタオブジェクトはそれぞれの管理オブジェクトから参照できるようになる。
【００７１】
また、管理オブジェクトからＩＤ番号をもらうことにより、ＩＤ番号を割当てることができる。実行コード１０４により、経路管理オブジェクトに排他制御オブジェクトを参照できるデータを登録している。
【００７２】
実行コード１０５により、アービタオブジェクトは登録された排他制御オブジェクトを通る経路オブジェクトを探す。この経路オブジェクトを探す方法としては、例えば、経路管理オブジェクトにある経路オブジェクトを参照するデータを使って、順番に経路オブジェクトをアクセスし、経路オブジェクトに上記の排他制御オブジェクトを通るかどうか問合せる方法がある。
【００７３】
経路オブジェクトがこの問合せに応答する方法としては、例えば、経路オブジェクトが管理している排他制御オブジェクトの集合の中に問合せられた排他制御オブジェクトがあるか否かを検出する方法がある。
【００７４】
この一連の処理により、実行コード１０５の処理でアービタオブジェクトは、このアービタオブジェクトが制御する排他制御オブジェクトを含む経路オブジェクトを全て探し出すことができる。実行コード１０６の処理で、アービタオブジェクトは見つけた経路オブジェクトをこのアービタオブジェクト内部のＤＢ（データベース）領域に登録する。
【００７５】
更に、アービタオブジェクトは、見つけた経路オブジェクトの中のアービタイベントリストに自分自身のｗａｋｅｕｐ＿ｅｖｅｎｔを登録する。これにより、経路オブジェクトがアービタのｗａｋｅｕｐ＿ｅｖｅｎｔを起こせるようになる。
【００７６】
実行コード１０７の処理は、適宜な方法で経路オブジェクト内部の信号（シグナル）に波形ファイルを関係付けする処理をする。一例として、ＳｙｓｔｅｍＣの場合を挙げる。ＳｙｓｔｅｍＣでは、シグナルｓｃ＿ｓｉｇｎａｌ＜ｓｃ＿ｌｖ＜３＞＞ｓｉｇ１がある場合に、これを波形ファイルｆｐに波形ダンプするための処理は、ｓｃ＿ｔｒａｃｅ（ｆｐ，ｓｉｇ１，“ｓｉｇ１”）と記述すればよい。
【００７７】
図１の実行コード１０７の処理は、波形ファイル指定１２５で指定されたファイルを経路管理オブジェクトに登録されている経路オブジェクトに順次与える。経路オブジェクトは、ファイルをもらうと、経路オブジェクトに含まれるシグナルとファイルをｓｃ＿ｔｒａｃｅを使って関連付けする。経路オブジェクトの状態をシグナルに連結することで経路オブジェクトの状態を波形データに反映することができるようになる。
【００７８】
図１の実行コード１０８の処理は、性能評価データ用指定１２６でもらった性能評価データファイル名に性能評価用のデータを書き出す準備をする。一例として、図１に示したように、アーキテクチャ構造データ１１９をダンプして、性能評価データ１１５を出力する場合には、同じファイル名に別の拡張子をつけることで区別することができる。
【００７９】
図１のアーキテクチャ構造データ１１９をダンプする場合、経路管理オブジェクト、排他制御管理オブジェクト、アービタ管理オブジェクトに問合せをして、経路オブジェクトとＩＤ番号の対の一覧、それぞれの経路オブジェクトが使う排他制御オブジェクトとＩＤ番号の対の一覧、アービタ管理オブジェクトが制御する制御オブジェクトとＩＤ番号の対の一覧、排他制御オブジェクトとＩＤ番号の対の一覧などのアーキテクチャ・データをダンプする。各管理オブジェクトは問合せを受けると、各々の管理オブジェクトが管理対象のオブジェクト全ての情報を調べ、所望のデータを作成し、これをデータダンプオブジェクト１１４に返す。このようにアーキテクチャ構造データ１１９をダンプすることができる。
【００８０】
ここでは、経路オブジェクト、排他制御オブジェクト、アービタオブジェクトのみについて書いたが、実際には、アーキテクチャの重要な要素であるメモリも同様の方法でアーキテクチャ構造データとしてダンプすることができる。最大利用率の情報を収集する等の適用がある。
【００８１】
アーキテクチャ構造データと各経路オブジェクトの活性化率を利用すると、各バスの利用率、バスの利用率の内訳を後処理で作成することができ、同様の計測を複数することなくシミュレーションすることが可能になる。
【００８２】
図１の性能評価データ１１５は、必要であればヘッダをつける。実際のデータの書き出しは、シミュレーション実行１２７の処理中に行われる。書き出すタイミングは、データダンプオブジェクトに入れたサンプリングクロックに同期して行われる。サンプリングクロックに同期する方法は、ＳｙｓｔｅｍＣであれば、ＳＣ＿ＴＨＲＥＡＤを利用することにより実現できる。
【００８３】
データダンプオブジェクトは、サンプリングクロックが発生するたびに、ダンプ対象となっているオブジェクトの管理オブジェクトに問合せをかける。例えば、経路管理オブジェクトの活性化率を問合せる場合には、経路管理オブジェクトに問合せをして、問合せを受けた経路管理オブジェクトは、自分自身の管理する各々の経路オブジェクトに対して、稼働時間をもらい、稼働時間をサンプリングクロックの周期で割って活性化率を算出し、稼働時間をゼロ（０）に初期化する。算出した稼動時間データを経路オブジェクトのＩＤ番号をつけるなどして性能評価データ１１５に反映させる。その他の性能評価データをとる場合も、上述したのと同様の手続きでダンプすることが可能である。
【００８４】
以上により、シミュレーション時に各オブジェクトが通信するための環境が構築できる。
【００８５】
例えば、前述の図３の処理を実現するアーキテクチャとして、図４乃至図６のアーキテクチャ例とマッピングで設計しようとする場合、本実施例のシミュレーション方式を用いることにより、設計者は図１１乃至図１３のようにそれぞれ記述すればよい。
【００８６】
図１１に示したアクセスの記述２０では、転送１を定義するため、経路１（４１）と、経路１と連結するポート２１１とポート２２１を用いている。同様に、転送２（４２）、転送３（４３）、転送４（４４）を定義するため、それぞれの経路と、当該経路と連結するポート対を用いている。バス４５は、それぞれの経路４１−４４と直結される。バス４５は、アービタ４７と連結される。バス４５の内部の詳細を記述するブロック４５Ａでは、排他制御のみを定義する。
【００８７】
図１２に示したアクセスの記述２０は、基本的に図１１と同様である。この例では、バス４５は、経路４１（転送１）、経路４３（転送３）、経路４４（転送４）と直結されるが、経路４２（転送２）とは直結されない。ポート対が増加することはない。
【００８８】
図１３に示したアクセスの記述２０は、基本的に図１１と同様である。この例では、バス１（４８）は、転送１の経路４１と転送２の経路４２と直結される。バス２（４９）は、転送３の経路４３と転送４の経路４４と直結される。セレクタ４６は、転送３の経路４３と転送４の経路４４と直結される。バス１（４８）、バス２（４９）、セレクタ４６は、それぞれアービタ４７と連結される。
【００８９】
図１４の記述２０は、本実施例のアーキテクチャ方式を用いて、図４のアーキテクチャ例の場合の性能評価データのダンプの例を示す。図１４に示したように、転送１の経路４１、転送２の経路４２、転送３の経路４３、転送４の経路４４が性能評価のための計測機能をもっているため、ファイル２７への性能評価データの転送（ダンプ）を行うためには、設計者は、データダンプオブジェクト１１４を用いて、そのアーキテクチャ情報を指定するだけでよい。
【００９０】
次に、シミュレーション時の通信方法について説明する。図１８は、経路オブジェクトが有する処理（メソッド）を実行するための処理手順を示す。
【００９１】
経路オブジェクトには、通信用のメソッドとして、少なくとも、リクエスト処理、グラント処理、送信処理、レディ処理、中断処理、終了処理、アンロック問合せ処理がある。
【００９２】
通信の説明をするために、イニシエータとレスポンダーの記述例を図２１に示す。イニシエータとは、ｒｅｑｕｅｓｔを送出してバスを確保する処理をするブロックのことで、レスポンダーとは、イニシエータから送られてきたデータをリアクティブに処理するブロックのことである。
【００９３】
図２３はビート転送をする場合の例を示している。また、アービタは図２２に示したＦＣＦＳアービタを使用する。この時、通信は図２３に示したシーケンス図のようになる。
【００９４】
図２１に示したように、経路オブジェクトのリクエスト処理をコールする。そして、ｗａｉｔ（ｐｏｒｔ１−＞ｅｖＧｒａｎｔ（））で、経路オブジェクト内のｇｒａｎｔ＿ｅｖｅｎｔの参照をもらい、ｇｒａｎｔ＿ｅｖｅｎｔが発生するのを待つ。
【００９５】
図２１のイニシエータ記述中の（ａ）で示した記述がこれに相当する。ｐｏｒｔ１は経路オブジェクト（のインターフェイス）のポートである。このポートを利用することにより、経路オブジェクトのメソッドをコールすることができる。
【００９６】
リクエスト処理ｒｅｑｕｅｓｔ（）がコールされると、図１８のリクエスト処理（ａ）が実行される。最初に、経路オブジェクトはグラント待ちの状態に遷移させる（Ｓ１５）。直結しているかどうかを判定する（Ｓ１６）。判定の方法は直結の表現方法に依存する。図１８では、排他制御オブジェクトのリストが空の時に直結していると判定する例を示している。直結している場合（ステップＳ１６の判定結果がＮＯの場合）、本来リクエストを必要としない。しかし、この実施例ではアービタがある場合と同じ手続きにするため、リクエストを使用する。直結している場合にはアービトレーションがないのでリクエストが来たら即座にグラントを返す（Ｓ１８）。
【００９７】
一方、排他制御オブジェクトのリストが空でない場合は、直結していない場合（ステップＳ１６の判定結果がＹＥＳの場合）であり、アービタリストの中のイベントｗａｋｅｕｐ＿ｅｖｅｎｔを発生させる（Ｓ１７）。このイベントが発生すると、アービタはスリープ状態からアクティブ状態に遷移する。
【００９８】
図２２の例では、初期状態では、履歴リストは空なので、ｗａｉｔ（ｗａｋｅｕｐ＿ｅｖｅｎｔ）で待っている状態で停止している。この状態で、ｗａｋｅｕｐ＿ｅｖｅｎｔが発生すると、アービタは動作し始める。そして、アービタの動作は、ｗａｉｔ（０，ＳＣ＿ＮＳ）で停止する。ここまでの処理は、図２３の１サイクル目（１ｓｔ＿Ｃｙｃｌｅ）の処理手順に相当する。
【００９９】
アービタ基底クラスがリクエストを発行した経路オブジェクトの集合を得る方法にはいくつかある。例えば、アービタ基底クラス内の経路オブジェクトリストから、グラント待ちになっている経路オブジェクトを抽出する方法、グラント待ち以外の経路オブジェクトをマスクする方法、アービタ基底クラスにリクエスト用のバッファを追加して、経路オブジェクトの参照を挿入する方法等がある。また、優先順位順に並べる方法としては、例えば、ＳＴＬのｓｅｔコンテナを使用する方法がある。
【０１００】
上記したｗａｉｔ（０，ＳＣ＿ＮＳ）は、デルタ遅延後に待ち状態から抜ける。このとき、リクエストの集合がすでに完成しているので、イテレータを用いて優先順位に従って順次スキャンする。この実施例では、アービタは、経路オブジェクトのアンロック問合せ処理（図１８の（ｇ））を行う。
【０１０１】
図１８のアンロック問合せ処理（ｇ）が開始すると、排他制御リストの要素が全てアンロック状態であるか否かを調べる（Ｓ２４）。この問合せ処理の結果はｂｏｏｌ値として返す。
【０１０２】
アンロック問合せ処理（ｇ）が行われ、経路オブジェクトがオープン（ｏｐｅｎ）ならば、経路オブジェクトのグラント処理を行う。
【０１０３】
図１８のグラント処理（ｅ）が開始すると、経路オブジェクトは送信待ちの状態に遷移する（Ｓ２０）。次に、ロック処理を行う（Ｓ２１）。従って、優先順位順に従って、上記した処理手順を繰り返すことでアービトレーションを実現できる。そして、経路オブジェクトはグラント処理が行われることにより、ｇｒａｎｔ＿ｅｖｅｎｔを発生する（Ｓ２２）。これにより、図２１の記述例では、 ｗａｉｔ（ｐｏｒｔ１−＞ｅｖＧｒａｎｔ（））（ここで、ｐｏｒｔ１−＞ｅｖＧｒａｎｔ（）はｇｒａｎｔ＿ｅｖｅｎｔの参照をもらう関数）で待っていたイニシエータが動き出し、次行のｗａｉｔ（）で次のクロックを待つ。
【０１０４】
また、経路オブジェクトが有する、その他の処理について説明する。
【０１０５】
図１８の登録処理（ａ）が開始すると、上述したように、排他制御リストに登録する処理が行われる（Ｓ１１）。
【０１０６】
図１８の中断処理（ｄ）が開始すると、図１８の転送終わり処理（ｉ）が行われる（Ｓ１９）。この転送終わり処理（ｉ）が開始すると、経路オブジェクトは終了待ちの状態に遷移する（Ｓ２８）。そして、ｅｎｄ＿ｅｖｅｎｔを発生させて（Ｓ２９）、転送終わり処理が終了する。
【０１０７】
図１８の終了（バス開放）処理（ｆ）が開始すると、経路オブジェクトはアイドル状態に遷移して（Ｓ２３）から、処理を終了する。
【０１０８】
図１８の通信処理（ｈ）が開始すると、まず、送信するビット数をセットする（Ｓ２５）。次に、経路オブジェクトは送信待ちの状態から送信中の状態に遷移する（Ｓ２６）。そして、ｓｅｎｄ＿ｅｖｅｎｔを発生して（Ｓ２７）から、処理を終了する。
【０１０９】
図１８のロック処理（ｊ）が開始すると、上述したように、排他制御リストの全ての要素をロックする処理が行われる（Ｓ３０）。
【０１１０】
アービタ基底クラスと経路オブジェクトが上記のような通信を行ってアービトレーションを実現しているので、このアービタは容易に複数の排他制御オブジェクトを制御することができる。経路には通常、優先順位か、順番（ラウンドロビン等で使われる）が割当てられる。このため、設計者が、あるアービタで制御される経路の集合に順序関係を割当てる必要がある。
【０１１１】
一方、あるアービタで制御される経路と別のアービタで制御される経路には、設計者は優先順位も順番も割当てる必要がない。この場合、これらの経路間に任意の関係を導入しても差し支えがない。
【０１１２】
これら２つの経路はアービタを共有しないことから、共有する排他制御オブジェクトがないので、どちらの経路からグラント処理をしても結果は同じになる。このため、任意の関係を導入して差支えがない。例えば、同じ優先順位や順番をもつ複数の経路があった場合、ＩＤ番号順に評価することとしてもよい。このようにすると、すべての経路間に順序関係を割当てることができる。このため、同一のアービトレーション・アルゴリズムで制御されるアービタは１つのアービタで制御しても結果が変わらない。従って、図６（ａ）のような回路であっても１つのアービタで扱えるようになる。また、図６（ａ）のセレクタ２６のように排他制御する要素が含まれていても、セレクタ固有の制御をする必要がない。
【０１１３】
本実施例のシミュレーション方式では、経路を構成する要素を１個増やすだけで済み、容易に複数の排他制御オブジェクトの制御が可能になる。
【０１１４】
以上説明したのがイニシエータとアービタの通信方法である。次に、イニシエータとレスポンダーの通信方法について説明する。
【０１１５】
イニシエータは、図２２の記述例では、転送ビート数を書き込んだ（図２２の（ｄ））後、アドレスの代わりに転送開始を示すｓｅｎｄ（）を転送している（図２２の（ｅ））。アドレスを送る拡張がなされている場合にはアドレスを書きこむ。
【０１１６】
また、データを転送するように拡張されている場合には、データも入力する。イニシエータはいずれの場合も、ｓｅｎｄ＿ｅｖｅｎｔを発生する。図２３に示したように、レスポンダーはｓｅｎｄ＿ｅｖｅｎｔが発生するのを待っているので、このイベントの発生により動作を開始する。
【０１１７】
レスポンダーは、図２１の記述例では、転送ビート数を調べる。もし、アドレスが送られている場合ならば、アドレスを取り出す。この記述例では ｒｅａｄｙ（）を１個返している。あるいは、ｒｅａｄｙ（個数）を返すことで、複数個のｒｅａｄｙ信号を一括して返すことも可能である。
【０１１８】
図１８のレディ処理（ｂ）が開始すると、転送カウンタに転送ビート数を加算する（Ｓ１２）。次に、転送カウンタがビート数に達したか否かを判定する（Ｓ１３）。転送カウンタがビート数に達したら、ｅｎｄ＿ｅｖｅｎｔを発生して正常終了する（Ｓ１４）。
【０１１９】
一方、転送カウンタがビート数に達する前に中断処理が行われる場合には、ｅｎｄ＿ｅｖｅｎｔを発生して異常終了する。
【０１２０】
イニシエータは、ｗａｉｔ（ｐｏｒｔ１−＞ｅｖＥｎｄ（））でｅｎｄ＿ｅｖｅｎｔの発生を待っている。このため、ｅｎｄ＿ｅｖｅｎｔが発生すると、図２３に示したように動作を再開する。
【０１２１】
ここで、異常終了もありえる場合には、図２３に示したように正常終了したかどうかを問合せる。正常終了したかどうかの判定は、転送カウンタとビート数が一致しているかどうかで判定できる。また、異常終了の場合、成功した転送ビート数が必要になることがあるが、転送カウンタの値を参照することで調べられる。
【０１２２】
上記した処理手順までで所望の転送処理が終わる。図２３の記述例では、次のサイクル（４ｔｈ＿Ｃｙｃｌｅ）で終了処理ｅｎｄ（）をコールしてバスを開放している。
【０１２３】
もし、開放しない場合には終了処理ｅｎｄ（）を行うことなく、次の処理手順を開始する。終了処理ｅｎｄ（）がコールされると、経路オブジェクト内にある排他制御オブジェクトのリストにある排他制御オブジェクト全てをアンロックする。
【０１２４】
このようにして、一連の転送が実現できる。また、図１８と図１５に示したように、関数コールにトリガーされて状態が遷移する。状態が変化に応じてトリガーされて状態値をシグナル（ＳｙｓｔｅｍＣの場合、ｓｃ＿ｓｉｇｎａｌ）に代入することで、状態を波形データとして反映させることができる。
【０１２５】
また、このＦＳＭを用いて経路の稼働時間を計測することができる。経路の稼動期間を、例えば、グラント処理から終了処理までとすると、グラント処理がコールされた時に現在の時間をもらう処理（ＳｙｓｔｅｍＣの場合、ｓｃ＿ｃｌｏｃｋ：：ｔｉｍｅ＿ｓｔａｍｐ（））を行って、得られた時間を開始時間に代入し、終了処理時に、同様にして現在の時間をもらい、得られた終了時間と開始時間の差を稼働時間に加算することで、稼働時間を求めることができる。この稼動時間はダンプオブジェクトにより利用される。
【０１２６】
次にパイプラインオブジェクトについて説明する。
【０１２７】
パイプラインオブジェクトは、イベントをパイプライン化する。パイプラインオブジェクトには、例えば、ＳｙｓｔｅｍＣによる実装の場合、イベントが起こるまでの時間を保持するＦＩＦＯバッファと、前のイベントが起こる時刻、内部制御用イベントオブジェクトと（外部参照用）イベントオブジェクト、動作中／サスペンド中を表現できるフラグが定義される。
【０１２８】
まず、パイプラインオブジェクトのイベント登録方法を説明する。最初に、イベント発生までの時間をもらう。もし、ＦＩＦＯバッファが空だったら、ＦＩＦＯバッファにイベントまでの時間を格納し、内部制御用イベントオブジェクトにイベント発生までの時間を通知する（ｎｏｔｉｆｙ）。ｓｃ＿ｅｖｅｎｔはｎｏｔｉｆｙ（時間）がコールされると、現在の時刻からｎｏｔｉｆｙ（）の引数で与えられた時間が経過すると、イベントを発生する。また、前のイベントが発生する時刻に、現在の時刻にイベント発生までの時間を加算したものを代入する。
【０１２９】
もし、ＦＩＦＯバッファが空でなかったら、ＦＩＦＯバッファに現在の時刻にイベント発生までの時間を加え、この時間から前のイベントが発生する時刻を差し引いた時間を代入する。前の時刻に、現在の時刻にイベント発生までの時間を加えたものを代入する。
【０１３０】
次に、パイプラインオブジェクトのイベントの発生方法を説明する。
【０１３１】
ＳｙｓｔｅｍＣの場合、ｓｃ＿ｔｈｒｅａｄを用いてイベントを発生させる。ｓｃ＿ｔｈｒｅａｄの中に無限ループを置く。ループの先頭でパイプラインオブジェクトが有する内部制御用イベントオブジェクトの発生を待つ。発生したら、外部参照用のイベントオブジェクトをｎｏｔｉｆｙ（）して、ＦＩＦＯバッファをポップする。この後、ＦＩＦＯバッファが空でなかったら、ＦＩＦＯバッファの先頭に格納されている時間を参照して、ｎｏｔｉｆｙ（参照して得られた時間）とする。
【０１３２】
これによりイベントをパイプライン化できる。イベントの発生はブロードキャストされるので、後段のパイプラインをサスペンドする必要がなければ、内部制御用イベントオブジェクトを外部参照用イベントオブジェクトで代用し、外部参照のイベントオブジェクトのｎｏｔｉｆｙ（）を省略することができる。
【０１３３】
次に、パイプラインオブジェクトの時間を中断・再開する方法を説明する。
【０１３４】
中断処理（ｐｅ．ｓｕｓｐｅｎｄ（））がコールされた時、ＦＩＦＯバッファの先頭の要素を書き換える。先頭の要素の値から現在の時刻を差し引き、直前のイベントの発生時刻を加えたものを先頭に書き込む。さらに、フラグをサスペンド中にする。サスペンド中に内部制御イベントが発生した場合、何もせずに内部制御イベント待ちにする。
【０１３５】
再開処理（ｐｅ．ｒｅｓｕｍｅ（））がコールされた時、前のイベントの発生時刻に現在の時刻を書き込み、内部制御オブジェクトに対してｎｏｔｉｆｙ（ＦＩＦＯバッファの先頭の値）をコールする。このようにしてパイプラインイベントを中断／再開させることができる。
【０１３６】
以上説明したように、図３乃至図６に示した事例を従来の方式で記述すると、図７乃至図１０のようになるが、本実施例のシミュレーション方式によれば図１１乃至図１４のようになる。したがって、設計者は、機能ブロック内部の記述を変更する必要がなくなる。また、ポートの書き換えが不要である。各機能ブロックにファイルを渡す記述の代わりに、データダンプオブジェクトにファイルを渡す記述に置き換えられることにより、記述量／記述変更量の削減が可能である。また、パイプラインイベントオブジェクトを使うと、従来方式のようにカウンタの記述等をすることなく、図２４のように通常のイベントと同様に、イベント発行とイベント受理で記述することができる。さらに、パイプラインイベントの動作を停止したい場合にも、中断処理ｓｕｓｐｅｎｄ（）をコールするだけで動作を停止することができ、少ない記述量で所望の動作を実現できる。
【０１３７】
本発明のシミュレーションシステムでは、バス／セレクタを実現する排他制御オブジェクトと、従来方式のチャネル・オブジェクトの代わりとなる経路オブジェクトと、従来方式ではバスに含まれていたアービトレーション・アルゴリズムを記述したアービタ基底クラスの継承クラスのオブジェクトを基本要素とし、アーキテクチャをこれらの基本要素で表現する。
【０１３８】
本発明のシミュレーションシステムは、排他制御オブジェクトと経路オブジェクトを関係づけ、経路オブジェクトに機能ブロックとの通信機能を集約し、排他制御オブジェクトが必要に応じて、アービタオブジェクトにアクセスする機能を与える手段を有する。また、経路オブジェクトがアーキテクチャの状態を計測する機能を与える手段を有する。
【０１３９】
したがって、各機能ブロックには経路オブジェクトを渡すだけでよい。また、転送と排他制御は各オブジェクトの中で処理でき、従来方式のように設計者側の記述で対処する必要がなくなり、冗長な記述の削減ができる。
【０１４０】
本発明のシミュレーションシステムは、基本要素の宣言、基本要素間の関係づけの宣言により、アーキテクチャ情報を経路管理オブジェクト、排他制御管理オブジェクト、アービタ管理オブジェクトに登録する手段を有し、登録の際に自動でアーキテクチャを生成する手段を有する。
【０１４１】
したがって、キーの要素を指定すれば、実行コードの実行中にそのほかの制御要素を自動生成できるようになる。設計者はキー要素の指定だけで所望の機能を実現できるようになり、記述量の削減／記述変更量の削減ができる。
【０１４２】
本発明のシミュレーションシステムは、アービタ基底クラスについて制御の対象となる経路オブジェクトの集合を記憶する手段を有し、アービタで制御される排他制御オブジェクトの集合を記憶する手段を有する。アービタで制御される排他制御オブジェクトが登録されると、排他制御オブジェクトに記憶する。経路管理オブジェクトを用いて、登録された排他制御オブジェクトを通る経路オブジェクトを取り出す手段を有し、取り出したオブジェクトを前記経路オブジェクトの集合に記憶することができる。
【０１４３】
したがって、アービタ基底クラスに排他制御オブジェクトを登録するだけで、経路オブジェクトの集合を保持できるようになり、記述量の削減／記述変更量の削減ができる。
【０１４４】
本発明のシミュレーションシステムは、経路オブジェクトを利用して行われる通信を監視して、経路の状態（例えば、アイドル、グラント待ち、送信待ち、送信中、終了待ちの状態）を管理する手段を有し、この経路が単位時間当たりに実際に利用した時間や単位時間当たりにリクエストから処理を終えるまでの時間を計測する手段を有する。また、データダンプオブジェクトは各管理オブジェクトを参照する手段を有し、各管理オブジェクトを各々の管理対象となるオブジェクトを参照する手段を有し、データダンプオブジェクトから任意のオブジェクトにアクセスする手段を有する。
【０１４５】
したがって、経路オブジェクトのみでバスの状態に関わるデータを計測することができ、収集したアーキテクチャ構成データをダンプすることができる。また、簡単にバス占有率、あるバスの経路別の利用率を算出することが可能になる。本発明のシミュレーション方式によれば、活性化率計算の記述量が削減できるとともにデータダンプ処理のための記述量が削減できる。
【０１４６】
本発明のシミュレーションシステムは、経路オブジェクトについてのアービトレーションの優先順位を保持する手段を有し、アービタ基底クラスの登録により経路オブジェクトの集合を作成する際に、この優先順位の順に従って配列する手段を有する。アービタ基底クラスについてはこの優先順位の順に経路オブジェクトを参照する機能を与える手段を有する。したがって、優先順位を利用するアービタアルゴリズムの記述量／変更記述量を削減することができる。
【０１４７】
本発明のシミュレーションシステムは、経路オブジェクトに基づいてイニシエータがアドレスを入力する処理を実行する手段を有し、経路オブジェクトにアドレスを保持する手段を有し、レスポンダーがアドレスを読み出す処理を実行する手段を有する。したがって、アドレスの転送を可能にすることができる。これにより、アドレスを使用する記述であっても、記述量／変更記述量の削減が可能になる。
【０１４８】
本発明のシミュレーションシステムは、経路オブジェクトが、実際の回路ではあるアドレス空間と対応することに着目して、経路オブジェクトにアドレス空間を保持する手段を有し、伝達されるアドレスがアドレス空間に含まれるか否かを判定する手段を有する。したがって、アドレスが指定したアドレス空間に含まれているか否かを、少ない記述量で判定することが可能になる。
【０１４９】
本発明のシミュレーションシステムにおいては、経路オブジェクトが経路管理オブジェクトに集約されていることから、経路管理オブジェクトが経路オブジェクトのアドレス空間の重複を検査する手段を有し、同一のアドレス空間をアクセスする経路の集合とアドレス空間の関係表をダンプする手段を有する。あるいは、同一のアドレス空間をアクセスする経路が１つであるアドレス空間とこの経路の関係表をダンプする手段を有する。
【０１５０】
したがって、指定したアドレス空間が適切であるか視認検査できるようになる。このような検査が少ない記述量で実現できる。
【０１５１】
本発明のシミュレーションシステムにおいては、経路オブジェクトが一連の処理において、前段の処理が後段の処理を起動するイベントを有し、経路オブジェクトを用いて起動信号の授受を実現する。これにより記述量／記述変更量の削減ができる。
【０１５２】
本発明のシミュレーションシステムにおいては、複数の経路オブジェクトの順序列を入力として受け取り、先頭のオブジェクトの起動をかけるイベントを最後尾のオブジェクトのイベントに置き換える手段を有する。例えば、ＳＤＲＡＭやチップ上のＳＲＡＭに一旦データを書きこむ経路と、ＳＤＲＡＭやチップ上のＳＲＡＭから書き込まれたデータを読み出す経路により、間接的に繋がっている２つの機能ブロック間で起動信号の授受をすることを可能にする。
【０１５３】
本発明のシミュレーションシステムにおいては、排他制御オブジェクトがデータ幅を有し、経路オブジェクトがこの経路を構成する排他制御オブジェクトのうち最小のデータ幅を探す手段を有する。データの幅が重要であるアーキテクチャのシミュレーションが可能になる。排他制御オブジェクトは本質的にデータ幅を保持する対象であることから、記述量を低く抑えた実装を可能にしている。
【０１５４】
本発明のシミュレーションシステムにおいては、イベントをパイプライン化する手段を有するオブジェクトをデータベースに設けることができる。これにより、機能記述ブロック内部のバス・アクセス記述内部、または複数のバス・アクセス記述間のイベントのやり取りを簡易化でき、記述量の削減ができる。
【０１５５】
（付記１） アーキテクチャを、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを基本要素として表現したソースコードからシミュレーション実行コードを生成するシミュレーションシステムであって、前記排他制御オブジェクトを管理する排他制御管理オブジェクトと、前記経路オブジェクトを管理する経路管理オブジェクトと、前記アービタオブジェクトを管理するアービタ管理オブジェクトと、前記排他制御オブジェクトと前記経路オブジェクトを関係づけ、前記経路オブジェクトに機能ブロックとの通信機能を集約し、前記排他制御オブジェクトが必要に応じて、前記アービタオブジェクトにアクセスする機能を与える手段と、前記経路オブジェクトがアーキテクチャの状態を計測する機能を与える手段とを備えることを特徴とするシミュレーションシステム。
【０１５６】
（付記２） 前記経路オブジェクトについてのアービトレーションの優先順位を保持する手段と、前記アービタオブジェクトの登録により経路オブジェクトの集合を作成する際に、前記優先順位の順に従って配列する手段と、前記アービタオブジェクトが前記優先順位の順に経路オブジェクトを参照する機能を与える手段とを備えることを特徴とする付記１記載のシミュレーションシステム。
【０１５７】
（付記３） 前記経路オブジェクトに基づいてアドレス空間を保持する手段と、伝達されるアドレスが前記アドレス空間に含まれるか否かを判定する手段とを備えることを特徴とする付記１記載のシミュレーションシステム。
【０１５８】
（付記４） 前記経路オブジェクトに基づいて、送信元の機能ブロックを実現するオブジェクトからのアドレスを入力し、前記経路オブジェクトに前記アドレスを保持する処理を実行する手段と、送信先の機能ブロックを実現するオブジェクトが前記アドレスを読み出す処理を実行する手段を備えることを特徴とする付記１記載のシミュレーションシステム。
【０１５９】
（付記５） アーキテクチャを、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを基本要素として表現したソースコードからシミュレーション実行コードを生成するシミュレーション方法であって、前記排他制御オブジェクトを管理する排他制御管理オブジェクトと、前記経路オブジェクトを管理する経路管理オブジェクトと、前記アービタオブジェクトを管理するアービタ管理オブジェクトとを含むシミュレーションシステムを作成する手順と、前記排他制御オブジェクトと前記経路オブジェクトを関係づける手順と、前記経路オブジェクトに機能ブロックとの通信機能を集約する手順と、前記排他制御オブジェクトが必要に応じて、前記アービタオブジェクトにアクセスする機能を与える手順と、
前記経路オブジェクトがアーキテクチャの状態を計測する機能を与える手順とを有することを特徴とするシミュレーション方法。
【０１６０】
（付記６） 前記経路オブジェクトのアドレス空間と前記経路オブジェクトとの関係を保持する手段と、前記経路オブジェクトの経路を通るアドレスが前記アドレス空間に含まれるか否かを判定する手段とを備え、正しいアドレスが送付されているかを検査できるよう構成したことを特徴とする付記３記載のシミュレーションシステム。
【０１６１】
（付記７） 複数の経路オブジェクトで構成される経路を宣言する手段と、前記複数の経路オブジェクトで構成される前記経路の先頭の経路オブジェクトに与えられた処理開始イベントを、前記複数の経路オブジェクトで構成される前記経路の末尾の経路オブジェクトに伝達させる手段とを備え、前記末尾の経路オブジェクトに伝達された処理開始イベントを参照できるよう構成したことを特徴とする付記４記載のシミュレーションシステム。
【０１６２】
（付記８） パイプラインイベントオブジェクトと、パイプラインイベントにイベントをパイプライン化して発生させる手段と、イベントの発生時間を遅延させる手段とを備えることを特徴とする付記１記載のシミュレーションシステム。
【０１６３】
（付記９） 前記シミュレーションシステムが、前記経路オブジェクトに基づいて、送信元の機能ブロックを実現するオブジェクトからのアドレスを入力し、前記経路オブジェクトに前記アドレスを保持する処理を実行する手段と、送信先の機能ブロックを実現するオブジェクトが前記アドレスを読み出す処理を実行する手段を備えるよう作成され、かつ、複数の経路オブジェクトで構成される経路を宣言する手順と、前記複数の経路オブジェクトで構成される前記経路の先頭の経路オブジェクトに与えられた処理開始イベントを、前記複数の経路オブジェクトで構成される前記経路の末尾の経路オブジェクトに伝達させる手順とを有することを特徴とする付記５記載のシミュレーション方法。
【０１６４】
（付記１０） 前記シミュレーションシステムが、パイプラインイベントオブジェクトと、パイプラインイベントにイベントをパイプライン化して発生させる手段と、イベントの発生時間を遅延させる手段とを備えるよう作成されることを特徴とする付記５記載のシミュレーション方法。
【発明の効果】
以上説明したように、本発明のシミュレーション方式によれば、従来方式で処理やアーキテクチャを記述する場合に必要であった機能ブロック内部の記述、ポートの書き換えが不要となり、設計者による記述の量や記述の変更量を削減することができる。また、本発明のシミュレーション方式では、パイプラインイベントオブジェクトを使用すると、従来方式のようにカウンタの記述をすることなく、通常のイベントと同様に、イベント発行とイベント受理で記述することができ、少ない記述量で所望の動作を実現できる。
【０１６５】
【図面の簡単な説明】
【図１】本発明の一実施例に係るアーキテクチャのシミュレーションシステムを示すブロック図である。
【図２】図１のシミュレーションシステムが利用するデータベースの構成を示すブロック図である。
【図３】従来の方式と本発明を比較するために使用する処理例を示す図である。
【図４】従来の方式と本発明を比較するために使用する、処理例とアーキテクチャ例の関係を示す図である。
【図５】従来の方式と本発明を比較するために使用する、処理例とバイパスを加えたアーキテクチャ例の関係を示す図である。
【図６】従来の方式と本発明を比較するために使用する、処理例とマルチレイヤバスにしたアーキテクチャ例の関係を示す図である。
【図７】図４の処理例とアーキテクチャ例に従来の方式を適用した場合のモデル構成の例を示す図である。
【図８】図５の処理例とアーキテクチャ例に従来の方式を適用した場合のモデル構成の例を示す図である。
【図９】図６の処理例とアーキテクチャ例に従来の方式を適用した場合のモデル構成の例を示す図である。
【図１０】従来の方式を適用した場合の性能評価データのダンプの例を示す図である。
【図１１】図４の処理例とアーキテクチャ例に本発明のシミュレーション方式を適用した場合のモデル構成の例を示す図である。
【図１２】図５の処理例とアーキテクチャ例に本発明のシミュレーション方式を適用した場合のモデル構成の例を示す図である。
【図１３】図６の処理例とアーキテクチャ例に本発明のシミュレーション方式を適用した場合のモデル構成の例を示す図である。
【図１４】本発明のシミュレーション方式を適用した場合の性能評価データのダンプの例を示す図である。
【図１５】経路オブジェクトの状態遷移を説明するため図である。
【図１６】経路クラスの構成を示す図である。
【図１７】アービタ基底クラスの構成を示す図である。
【図１８】経路クラスが有する処理を実行するための処理手順を説明するためのフロー図である。
【図１９】メイン関数の記述例を示す図である。
【図２０】トップ階層の記述例を示す図である。
【図２１】イニシエータとレスポンダの記述例を示す図である。
【図２２】アービタ基底クラスから継承したクラスの記述例を示す図である。
【図２３】図１９乃至図２２の記述例を用いてシミュレーションを行う場合の転送シーケンスを説明するための図である。
【図２４】パイプラインオブジェクトの記述例を示す図である。
【符号の説明】
１００ シミュレーションシステム
１１１ 経路管理オブジェクト
１１２ 排他制御管理オブジェクト
１１３ アービタ管理オブジェクト
１１４ データダンプオブジェクト
１１５ 性能評価データ
１１６ 波形データ
１１８ サンプリングクロックオブジェクト
１１９ アーキテクチャ構造データ
１２０ 経路オブジェクトのコンストラクション
１２１ 排他制御オブジェクトのコンストラクション
１２２ アービタオブジェクトのコンストラクション
１２３ 経路オブジェクトへの排他制御オブジェクのアサイン
１２４ アービタオブジェクトへの排他制御オブジェクトのアサイン
１２５ 波形ファイル指定
１２６ 性能評価データ用指定
１２７ シミュレーション実行
【発明の属する技術分野】
本発明は、デジタルシステムのアーキテクチャを自動構成するための設計環境を提供するシミュレーションシステム及びシミュレーション方法に関するものである。
【０００２】
【従来の技術】
近年、オブジェクト指向モデリングに基づき、設計者が指定したデータから、アーキテクチャを自動構成するためのデータベース及びデータベース管理機構を含むシミュレーション方式が開発されつつある。この環境を実現するオブジェクトは、ＳｙｓｔｅｍＣのようなオブジェクト指向言語に基づくシミュレーション環境のライブラリとして実装し、ＳｙｓｔｅｍＣのようなオブジェクト指向言語によるソースコードをコンパイル処理する際にシミュレーション用の記述と一緒に読み込まれ、シミュレーションを実行する実行コードの中に埋め込まれ、実行時に、データベースが作成され、シミュレーション実行中に適宜参照され、所望の動作を実現するものである。
【０００３】
なお、本発明に関連する従来の技術として、特開平１１−３３６７号公報には、デジタルシステムのインプリメント可能な記述を生成する設計環境及び方法が開示されている。
【０００４】
【特許文献１】
特開平１１−３３６７号公報
【０００５】
【発明が解決しようとする課題】
従来の方式では、基本的オブジェクトのみを利用して記述しているため、所望の動作をさせるために多くの記述を必要としていた。従来の方式で用いられる記述は、実際の回路の記述に近い記述で直感的ではあるが、アーキテクチャの動作を再現する目的からすると冗長である。
【０００６】
また、従来の方式では、バス／セレクタなど排他制御を行うオブジェクトと、転送を実現するチャネル・オブジェクトとが直接関係していないことが問題をさらに複雑化にしている。このような実現方法をとっているため、バス／セレクタとチャネルの制御を機能ブロック内で行わなければならず、記述量／記述変更量の増加を引き起こしている。
【０００７】
従来の方式では、しばしば、アービトレーション・アルゴリズムをバスモデルの記述中に入れる必要がある。このような記述がポートを増やす原因、バス・アクセスの書き換えの要因となっている。
【０００８】
例えば、図３の処理を実現するアーキテクチャとして、図４乃至図６のアーキテクチャ例とマッピングで設計しようとする場合、従来の方式を用いると、設計者は、図７乃至図９のようにそれぞれ記述する必要がある。
【０００９】
図３の処理は、機能ブロック１（２１）、機能ブロック２（２２）、機能ブロック３（２３）、機能ブロック４（２４）の間でデータを、図３の矢印で示したように転送する処理（転送１、転送２、転送３、転送４）である。
【００１０】
図４の（ａ）で示したアーキテクチャ例では、各転送をバス１、アービタ２５を用いて実現する。図４の（ｂ）で示したマッピングでは、転送１、転送２、転送３、転送４のイニシエータを、それぞれ、機能ブロック１、機能ブロック２、機能ブロック３、機能ブロック１としている。
【００１１】
図５の（ａ）で示したアーキテクチャ例では、転送２のみをバス１と異なるデータ線を用いて実現する。図５の（ｂ）で示したマッピングでは、転送１、転送２、転送３、転送４のイニシエータを、それぞれ、機能ブロック１、機能ブロック２、機能ブロック３、機能ブロック１としている。
【００１２】
図６の（ａ）で示したアーキテクチャ例では、各転送をバス１、バス２、アービタ２５、セレクタ２６を用いて実現する。図６の（ｂ）で示したマッピングでは、転送１と転送２には、バス１を使用し、転送３と転送４には、バス２を用いる。また、転送１、転送２、転送３、転送４のイニシエータを、それぞれ、機能ブロック１、機能ブロック２、機能ブロック３、機能ブロック１としている。
【００１３】
図７に示したアクセスの記述２０Ａでは、チャネル１（３１）での転送を定義するため、ポート２１１とポート２２１を、チャネル２（３２）での転送を定義するため、ポート２２２とポート２３１を、チャネル３（３３）での転送を定義するため、ポート２３３とポート２４１を、チャネル４（３４）での転送を定義するため、ポート２１３とポート２４２をそれぞれ記載している。例えば、チャネル１で機能ブロック１と機能ブロック２間の転送（転送１）をするには、バスリクエスト、バスグラント待ち等のアービトレーションを行うため、バス３５と連結させたポート２１２とポート２２３を用いる必要がある。バス３５の内部の詳細を記述するブロック３５Ａでは、排他制御とアービトレーションを定義する必要がある。
【００１４】
図８の記述２０Ａでは、図７の記述と同様に、チャネル１で機能ブロック１と機能ブロック２間の転送（転送１）をするには、バスリクエスト、バスグラント待ち等のアービトレーションを行うため、バス３５と連結させたポート２１２とポート２２３を用いる必要がある。同時に、バス３５の内部の詳細を記述するブロック３５Ａで、排他制御とアービトレーションを記述する必要がある。また、ダミーバス１（３６）での転送を定義するため、ポート２２３を用いる必要がある。
【００１５】
図９の記述２０Ａでは、セレクタ２６、バス１（３７）、バス２（３８）を定義するため、各機能ブロックにさらに余分なポートを設ける必要がある。例えば、チャネル１で機能ブロック１と機能ブロック２間の転送（転送１）をする際には、バス１リクエスト、セレクタリクエスト、バス１グラント待ち、セレクタグラント待ち等のアービトレーションを行うため、バス１（３７）と連結させたポート２１２とポート２２３、及びセレクタ２６と連結させたポート２１４とポート２３３を用いる必要がある。
【００１６】
従来の方式を用いて、設計者が、図７の記述例を図８の記述例に変更する場合、直結を表すために本来不要であるダミーバスを加える必要があり、設計者に不要な手間をかけることになる。
【００１７】
あるいは、図７の記述例から図９の記述例に変更する場合、増やしたバス／セレクタのデータを機能ブロックに伝播させるため、ポートを増やす必要がある。さらに、所望の動作になるように、バスにアクセスするための記述を書き直さなければならず、設計者に不要な手間をかけることになる。
【００１８】
図１０の記述２０Ａは、従来の方式を用いて、図４のアーキテクチャ例の場合の性能評価データのダンプをとる例を示す。ファイル２７への性能評価データの転送を定義するため、ポート２１３、ポート２２４、ポート２４３等をさらに用いる必要がある。
【００１９】
性能評価をする場合には、図１０の記述例のようにファイルを受け渡す必要があり、バスアクセスの記述に設計者がファイルアクセスを適切に加える必要があり、設計者に不要な手間をかけることになる。
【００２０】
これらの手間は、従来のシミュレーション方式を用いた場合に必要となる記述であり、目的のシミュレーションにおいて本質的な記述ではないため、非効率的である。
【００２１】
同様の理由から、機能ブロック内部または機能ブロックとバスを仲介するブロックの中にあるオブジェクトのデータをダンプする場合には記述量がかかる。このような例としてメモリがある。メモリはメモリ使用量などの計測を行う必要がある。
【００２２】
機能ブロックの中には複数のバス・アクセスを表現する記述が含まれることがある。この場合、あるバス・アクセス記述の処理が終わってから、次のバス・記述の開始までｎサイクル遅延させて、このイベントがパイプライン的に起きることがある。これを実現するために、どちらかをサイクルベースの記述にして、複数のカウンタを用意して、所望のサイクルになったらイベントを伝播するなどの方法がとられていた。更に、なんらかの理由で動作が停止する場合には、カウンタを停止する処理の記述を書き加える方法がとられている。このため、これらの方法では手間がかかり、記述量が多くなっていた。
【００２３】
本発明は、上記の点に鑑みてなされたものであり、アーキテクチャのシミュレーションを行う際に設計者が記述する記述量を削減すると共に、アーキテクチャを変更する際に必要となる記述量を削減することで、性能評価データを簡単に集計できるようにするアーキテクチャのシミュレーションシステム及びシミュレーション方法を提供することを目的とする。
【００２４】
【課題を解決するための手段】
上記課題を解決するため、本発明のシミュレーションシステムは、バスを介し接続された複数の機能ブロックと、転送経路と、アービタとを含むアーキテクチャを、設計者がハードウェア設計用のオブジェクト指向言語を用いて記述した、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを含むソースコードをコンパイル処理して実行コードを生成するシミュレーションシステムであって、前記排他制御オブジェクトを管理するための排他制御管理データベースと、前記経路オブジェクトを管理するための経路管理データベースと、前記アービタオブジェクトを管理するためのアービタ管理データベースとを有し、前記シミュレーションシステムが、前記排他制御オブジェクト、前記経路オブジェクト、及び前記アービタオブジェクトから生成した各実行コードにより、前記排他制御オブジェクト、前記経路オブジェクト、及び前記アービタオブジェクトを参照するための識別データを前記排他制御管理データベース、前記経路管理データベース、及び前記アービタ管理データベースにそれぞれ登録し、前記シミュレーションシステムが、設計者の記述した前記経路オブジェクトへの前記排他制御オブジェクトのアサインから生成した実行コードにより、前記排他制御オブジェクトを前記経路オブジェクトの内部領域に登録し、 前記シミュレーションシステムが、設計者の記述した前記アービタオブジェクトへの前記排他制御オブジェクトのアサインから生成した実行コードにより、前記アービタオブジェクトが制御する前記排他制御オブジェクトを含む経路オブジェクトを全て前記アービタオブジェクトの内部領域に登録することにより、シミュレーション実行時に、各管理データベースと通信する機能を提供して、前記アーキテクチャの性能評価データを生成することを特徴とする。
【００２６】
本発明のシミュレーション方式によれば、従来方式で処理やアーキテクチャを記述する場合に必要であった機能ブロック内部の記述、ポートの書き換えが不要となり、設計者による記述の量や記述の変更量を削減することができる。また、本発明のシミュレーション方式では、パイプラインイベントオブジェクトを使用すると、従来方式のようにカウンタの記述をすることなく、通常のイベントと同様に、イベント発行とイベント受理で記述することができ、少ない記述量で所望の動作を実現できる。
【００２７】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００２８】
本発明の一実施例として、ＳｙｓｔｅｍＣを利用したアーキテクチャのシミュレーションシステムを示す。
【００２９】
本発明のシミュレーションシステムでは、図２に示した管理オブジェクトを含むデータベースを利用する。
【００３０】
図２の経路管理オブジェクト１１１、排他制御管理オブジェクト１１２、アービタ管理オブジェクト１１３は、それぞれ経路オブジェクト、排他制御オブジェクト、アービタオブジェクトの参照を保持するデータベース（ライブラリ）である。
【００３１】
データダンプオブジェクト１１４は、経路管理オブジェクト１１１、排他制御管理オブジェクト１１２、アービタ管理オブジェクト１１３の参照を持ち、アーキテクチャの構成をダンプする（図１の１１４）。データダンプオブジェクト１１４は、サンプリングクロックオブジェクト１１８のサンプリングクロックに同期して性能評価データをファイルに記録する（図１の１１５）ため、経路管理オブジェクト１１１を経由して経路オブジェクトが保持する性能データをファイルに反映させるとともに、次の計測が開始できる状態にリセットする。
【００３２】
経路管理オブジェクト１１１、排他制御管理オブジェクト１１２、アービタ管理オブジェクト１１３の実装の一形態として、それぞれの管理オブジェクトをシングルトンとして実装する方法がある。シングルトンとしての実装の一例として、経路オブジェクト、排他制御オブジェクト、アービタオブジェクトのｓｔａｔｉｃ＿ｍｅｍｂｅｒ変数とし、ライブラリ内でこれらの管理オブジェクトを宣言しておく方法がある。
【００３３】
図１は、本発明の一実施例に係るアーキテクチャのシミュレーションシステムを示す。
【００３４】
図１のシミュレーションシステム１００は、図２に示すデータモデルをもつデータベース（ライブラリ）を使用して、設計者がデジタルシステムのアーキテクチャ（シミュレーションモデル）のソースコードを記述することを可能にする。シミュレーションシステム１００は、このソースコードをコンパイル処理してシミュレーション実行コードを生成する。データベースの作成、アーキテクチャの自動構成はこの実行コードの中で行われる。
【００３５】
最初に、設計者が記述するソースコードに含まれる、各オブジェクトのデータ構造について説明する。このソースコードは、少なくとも、経路オブジェクト、アービタオブジェクト、排他制御オブジェクトを含む。
【００３６】
排他制御オブジェクトは、通常Ｍｕｔｅｘと呼ばれるものと同一である。
【００３７】
経路オブジェクト、アービタ基底クラスについてはクラス図でデータ構造を示す。ただし、ここでは属性になっている個々のオブジェクトを、見やすくするため、クラスとこのクラスに含まれるメンバーのオブジェクトを関係「もっている」で関連づけて表記してある。また、ネストクラスがある場合には、関係「ネストクラス」で明示した。
【００３８】
図１６は、経路オブジェクトのデータ構造を示す。
【００３９】
図１６に示したように、経路クラス１３１は、ビート数６１、稼働時間６２、開始時間６３をもっている。また、経路クラス１３１は、経路状態６４、排他制御リスト６５、アービタのイベントリスト６６、ｒｅｑｕｅｓｔ＿ｅｖｅｎｔ６７、ｇｒａｎｔ＿ｅｖｅｎｔ６８、ｓｅｎｄ＿ｅｖｅｎｔ６９、ｅｎｄ＿ｅｖｅｎｔ７０、転送数カウンタ７１をもっている。
【００４０】
また、本実施例のシミュレーションシステム１００は、図１５のような経路オブジェクトの状態を管理するＦＳＭ（ｆｉｎｉｔｅ＿ｓｔａｔｅ＿ｍａｃｈｉｎｅ）を備えている。図１５に示したように、このＦＳＭは、イベントの発生状況に応じて、アイドル状態５１、グラント状態５２、送信待ち状態５３、終了待ち状態５４、送信中状態５５の中で、経路オブジェクトがある1つの状態から別の状態への遷移を監視している。図１６に示した経路状態６４がこのＦＳＭに相当する。
【００４１】
図１６に示したｅｖｅｎｔ型は、シミュレーション・ライブラリが提供するイベント型の機能を表す。ＳｙｓｔｅｍＣの場合、ｓｃ＿ｅｖｅｎｔがこのイベント型に相当する。
【００４２】
排他制御リスト６５は、この経路オブジェクトが表現する経路が使用する排他制御オブジェクトの集合を保持するリスト（または集合）である。
【００４３】
アービタのイベントリスト６６は、図１７のｗａｋｅｕｐ＿ｅｖｅｎｔの参照を保持するリストである。このリストには、経路が使用する排他制御オブジェクトを制御するアービタのｗａｋｅｕｐ＿ｅｖｅｎｔの参照をあつめている。
【００４４】
このイベントリスト６６は、経路オブジェクトがｒｅｑｕｅｓｔを受付けたときに、この経路オブジェクトが使用する排他制御オブジェクトを制御するアービタを起動するために使用する。
【００４５】
図１６のｒｅｑｕｅｓｔ＿ｅｖｅｎｔ６７、ｇｒａｎｔ＿ｅｖｅｎｔ６８、ｓｅｎｄ＿ｅｖｅｎｔ６９、ｅｎｄ＿ｅｖｅｎｔ７０は、ｒｅｑｕｅｓｔ（転送要求）、ｇｒａｎｔ（転送受付）、ｓｅｎｄ（転送開始）、 ｅｎｄ（バスの開放）を送信元と送信先の機能ブロック間、又は機能ブロックとアービタ間で通信するために使用される。
【００４６】
転送数カウンタ７１は、転送したビート数をカウントする機能ブロックである。ビート数６１は、転送ビート数を保持する。稼働時間６２は、単位時間当たりの経路の活性化した時間の合計を保持する。開始時間６３は、活性化した時間を保持する。稼働時間６２は、主にデータダンプオブジェクト１１４により参照され、データダンプオブジェクト１１４を駆動しているサンプリングクロックの時間でこの稼働時間６２を割算することで経路オブジェクトの活性化率を算出することができる。
【００４７】
次に、アービタ基底クラス１３３について説明する。
【００４８】
実際に使うアービタクラスは、このアービタ基底クラス１３３から継承したクラスを作成し、この中にアービタアルゴリズムを記述したクラスである。この作成したクラスのオブジェクトを使ってアービトレーションをする。アービタ基底クラス１３３は、少なくとも、アービタが共通してもつ経路オブジェクトと通信する機能を実装したものである。
【００４９】
図１７は、アービタ基底クラス１３３のデータ構造を示す。
【００５０】
アービタはクロックに同期して動く。ＳｙｓｔｅｍＣによる実装の場合、通常クロックに同期するオブジェクトはｓｃ＿ｍｏｄｕｌｅの継承クラスであることから、図１７ではアービタ基底クラス１３３をｓｃ＿ｍｏｄｕｌｅ７０の継承クラスとした。
【００５１】
アービタ基底クラス１３３に含まれるオブジェクトについて説明する。アービタ基底クラス１３３は、排他制御オブジェクトの参照を保持する排他制御リスト７４をもっている。アービタ基底クラス１３３は、このアービタが制御する経路オブジェクトの一覧を保持する経路リスト７５をもっている。また、アービタ基底クラス１３３は、ｅｖｅｎｔ型のｗａｋｅｕｐ＿ｅｖｅｎｔ７６をもっている。このイベントは、経路リスト７５からリクエストが到着した時にイベントを発生する。
【００５２】
このイベントを使用することにより、リクエストが来たタイミングで、アービトレーションの処理を開始または再開するようなアービトレーション・アルゴリズムを少ない記述量で記述することを可能にする。
【００５３】
また、アービタ基底クラス１３３のネストクラスとして、ある時点でリクエストを発行した経路オブジェクトの一覧を優先順位順にスキャンするイテレータ（ｉｔｅｌａｔｏｒ）クラス７３をもっている。これにより、スキャンの記述量が削減できる。
【００５４】
アービタ基底クラス１３３から継承クラスを作成する方法の例として、ＦＣＦＳを実装する記述例を図２２に示す。ＦＣＦＳは過去のリクエストを蓄える履歴リストをもっている。
【００５５】
図２２に示したように、履歴リストが空ならば、新しいリクエストが来るまでは何もすることがないので、ｗａｉｔ（ｗａｋｅｕｐ＿ｅｖｅｎｔ）でイベントの発生をまつ。つまり、新しいリクエストを待つ。
【００５６】
次に、ｗａｉｔ（０，ＳＣ＿ＮＳ）でデルタ遅延の時間間隔だけ待つ。バッファが空ではなかったら、次のサイクルを待って、更にデルタ遅延だけ待って、履歴リストに含まれているリクエストを順次評価する。
【００５７】
ｇｒａｎｔが可能（すなわち、ｇｒａｎｔ対象の経路オブジェクトが使用する排他制御オブジェクトすべてがｏｐｅｎ）であれば、そのリクエストを履歴リストから除外し、ｇｒａｎｔを出力する。一方、ｇｒａｎｔできなければ、そのままにしておく。
【００５８】
この後、現在到着したリクエストの集合を、優先順位に従って、順次評価する。ｇｒａｎｔ可能なリクエストに対しては、ｇｒａｎｔ信号を送出し、リクエストがｇｒａｎｔ不可能な場合には、ｇｒａｎｔ信号を受信したことを履歴リストに記録する。
【００５９】
このようにして、アービタ基底クラスから継承クラスを作成して所望のアービタを実現することができる。
【００６０】
この方式では、アービトレーション・アルゴリズムが同一であれば、複数の排他制御オブジェクトを一つのアービタで制御することができ、少ない記述で済ませることができる。また、イテレータにより少ない記述でアービトレーション・アルゴリズムを記述できる。
【００６１】
次に、図１を用いて、本実施例のシミュレーションシステム１００による、ソースコードの初期化手順について説明する。
【００６２】
図１中、設計者の記述と示された部分は、設計者（ユーザ）が記述するソースコードの部分である。本実施例のシミュレーションシステム１００は、図２のデータモデルを利用して、自動でアーキテクチャを構成する。
【００６３】
シミュレーションの実行１２７に対しては、シミュレーションを実行するとともに、性能評価データ１１５がダンプされる。
【００６４】
また、性能評価データ１１５の解析をするために、設計者（ユーザ）が指定したアーキテクチャ情報がダンプされたアーキテクチャ構造データ１１９が生成される。また、経路の状態を波形で観察したい場合がある。この波形データは、シミュレーション実行中、波形データ１１６にダンプされる。
【００６５】
図１９と図２０は、設計者によるＳｙｓｔｅｍＣを用いたソースコードの記述例を示す。具体的には、図１９はメイン関数の記述例を示し、図２０はトップ階層の記述例を示す。
【００６６】
図１９において、（１）に示した記述でトップモジュールを宣言している。（４）に示した記述で性能評価ファイル名を渡し、（５）に示した記述でサンプリング・クロックを与えている。（４）と（５）の記述は、図１の性能評価データ用指定１２６に相当する。（２）に示した記述で波形ファイルを宣言している。この記述方法はＳｙｓｔｅｍＣによる。（３）に示した記述で波形ファイルをシミュレーションシステムに渡している。（２）と（３）の記述は、図１の波形ファイル指定１２５に相当する。
【００６７】
図１９において、（３）に示した記述で波形ファイルのポインタをｎａｍｅｓｐａｃｅ ｏｏの経路クラス（ｒｏｕｔｅ）の（ｓｔａｔｉｃ ｍｅｍｂｅｒ変数で宣言されている）経路管理オブジェクト（ｈｅａｄ）に渡している。（３）の記述は図１の波形ファイル指定１２５に相当する。（６）に示した記述でシミュレーションを実行している。この記述はＳｙｓｔｅｍＣによる。（６）の記述は図１のシミュレーション実行１２７に相当する。
【００６８】
図２０は図１９における（１）の記述で宣言しているトップモジュールの記述例である。図２０において、ｏｏ：：ｒｏｕｔｅは経路クラス、ｏｏ：：ｅｘｃｌｕｓｉｖｅは排他制御クラス、ｆｃｆｓ＿ａｒｂｉｔｅｒはアービタ基底クラスから継承して作られたクラス、ｂｌｏｃｋ１〜ｂｌｏｃｋ４は処理ブロックの記述をしたクラスである。
【００６９】
図２０において、ＳＣ＿ＣＴＯＲ（ｔｏｐ）はＳｙｓｔｅｍＣの記述方法でコンストラクタである。コンストラクタの内容をｔｏｐ：：ｔｏｐ（ｓｃ＿ｍｏｄｕｌｅ＿ｎａｍｅ）以降に記述している。ｒｏｕｔｅ１〜ｒｏｕｔｅ４の宣言、ｂｕｓ１の宣言、ａｒｂ１の宣言はそれぞれ、図１の経路オブジェクトのコンストラクション１２０、排他制御オブジェクトのコンストラクション１２１、アービタオブジェクトのコンストラクション１２２に相当する。「ｒｏｕｔｅ１〜ｒｏｕｔｅ４．登録処理（ｂｕｓ１）」としている記述が図１の経路オブジェクトへの排他制御オブジェクトのアサイン１２３に相当する。「ａｒｂ１．登録処理（ｂｕｓ１）」としている記述が図１のアービタオブジェクトへの排他制御オブジェクトのアサイン１２４に相当する。
【００７０】
図１において、実行コード１０１は経路管理オブジェクトに自分自身を参照できるデータを渡す（登録する）。これにより、任意の経路オブジェクトは経路管理オブジェクトから参照できるようになる。同様に、実行コード１０２、１０３により、排他制御オブジェクト、アービタオブジェクトはそれぞれの管理オブジェクトから参照できるようになる。
【００７１】
また、管理オブジェクトからＩＤ番号をもらうことにより、ＩＤ番号を割当てることができる。実行コード１０４により、経路管理オブジェクトに排他制御オブジェクトを参照できるデータを登録している。
【００７２】
実行コード１０５により、アービタオブジェクトは登録された排他制御オブジェクトを通る経路オブジェクトを探す。この経路オブジェクトを探す方法としては、例えば、経路管理オブジェクトにある経路オブジェクトを参照するデータを使って、順番に経路オブジェクトをアクセスし、経路オブジェクトに上記の排他制御オブジェクトを通るかどうか問合せる方法がある。
【００７３】
経路オブジェクトがこの問合せに応答する方法としては、例えば、経路オブジェクトが管理している排他制御オブジェクトの集合の中に問合せられた排他制御オブジェクトがあるか否かを検出する方法がある。
【００７４】
この一連の処理により、実行コード１０５の処理でアービタオブジェクトは、このアービタオブジェクトが制御する排他制御オブジェクトを含む経路オブジェクトを全て探し出すことができる。実行コード１０６の処理で、アービタオブジェクトは見つけた経路オブジェクトをこのアービタオブジェクト内部のＤＢ（データベース）領域に登録する。
【００７５】
更に、アービタオブジェクトは、見つけた経路オブジェクトの中のアービタイベントリストに自分自身のｗａｋｅｕｐ＿ｅｖｅｎｔを登録する。これにより、経路オブジェクトがアービタのｗａｋｅｕｐ＿ｅｖｅｎｔを起こせるようになる。
【００７６】
実行コード１０７の処理は、適宜な方法で経路オブジェクト内部の信号（シグナル）に波形ファイルを関係付けする処理をする。一例として、ＳｙｓｔｅｍＣの場合を挙げる。ＳｙｓｔｅｍＣでは、シグナルｓｃ＿ｓｉｇｎａｌ＜ｓｃ＿ｌｖ＜３＞＞ｓｉｇ１がある場合に、これを波形ファイルｆｐに波形ダンプするための処理は、ｓｃ＿ｔｒａｃｅ（ｆｐ，ｓｉｇ１，“ｓｉｇ１”）と記述すればよい。
【００７７】
図１の実行コード１０７の処理は、波形ファイル指定１２５で指定されたファイルを経路管理オブジェクトに登録されている経路オブジェクトに順次与える。経路オブジェクトは、ファイルをもらうと、経路オブジェクトに含まれるシグナルとファイルをｓｃ＿ｔｒａｃｅを使って関連付けする。経路オブジェクトの状態をシグナルに連結することで経路オブジェクトの状態を波形データに反映することができるようになる。
【００７８】
図１の実行コード１０８の処理は、性能評価データ用指定１２６でもらった性能評価データファイル名に性能評価用のデータを書き出す準備をする。一例として、図１に示したように、アーキテクチャ構造データ１１９をダンプして、性能評価データ１１５を出力する場合には、同じファイル名に別の拡張子をつけることで区別することができる。
【００７９】
図１のアーキテクチャ構造データ１１９をダンプする場合、経路管理オブジェクト、排他制御管理オブジェクト、アービタ管理オブジェクトに問合せをして、経路オブジェクトとＩＤ番号の対の一覧、それぞれの経路オブジェクトが使う排他制御オブジェクトとＩＤ番号の対の一覧、アービタ管理オブジェクトが制御する制御オブジェクトとＩＤ番号の対の一覧、排他制御オブジェクトとＩＤ番号の対の一覧などのアーキテクチャ・データをダンプする。各管理オブジェクトは問合せを受けると、各々の管理オブジェクトが管理対象のオブジェクト全ての情報を調べ、所望のデータを作成し、これをデータダンプオブジェクト１１４に返す。このようにアーキテクチャ構造データ１１９をダンプすることができる。
【００８０】
ここでは、経路オブジェクト、排他制御オブジェクト、アービタオブジェクトのみについて書いたが、実際には、アーキテクチャの重要な要素であるメモリも同様の方法でアーキテクチャ構造データとしてダンプすることができる。最大利用率の情報を収集する等の適用がある。
【００８１】
アーキテクチャ構造データと各経路オブジェクトの活性化率を利用すると、各バスの利用率、バスの利用率の内訳を後処理で作成することができ、同様の計測を複数することなくシミュレーションすることが可能になる。
【００８２】
図１の性能評価データ１１５は、必要であればヘッダをつける。実際のデータの書き出しは、シミュレーション実行１２７の処理中に行われる。書き出すタイミングは、データダンプオブジェクトに入れたサンプリングクロックに同期して行われる。サンプリングクロックに同期する方法は、ＳｙｓｔｅｍＣであれば、ＳＣ＿ＴＨＲＥＡＤを利用することにより実現できる。
【００８３】
データダンプオブジェクトは、サンプリングクロックが発生するたびに、ダンプ対象となっているオブジェクトの管理オブジェクトに問合せをかける。例えば、経路管理オブジェクトの活性化率を問合せる場合には、経路管理オブジェクトに問合せをして、問合せを受けた経路管理オブジェクトは、自分自身の管理する各々の経路オブジェクトに対して、稼働時間をもらい、稼働時間をサンプリングクロックの周期で割って活性化率を算出し、稼働時間をゼロ（０）に初期化する。算出した稼動時間データを経路オブジェクトのＩＤ番号をつけるなどして性能評価データ１１５に反映させる。その他の性能評価データをとる場合も、上述したのと同様の手続きでダンプすることが可能である。
【００８４】
以上により、シミュレーション時に各オブジェクトが通信するための環境が構築できる。
【００８５】
例えば、前述の図３の処理を実現するアーキテクチャとして、図４乃至図６のアーキテクチャ例とマッピングで設計しようとする場合、本実施例のシミュレーション方式を用いることにより、設計者は図１１乃至図１３のようにそれぞれ記述すればよい。
【００８６】
図１１に示したアクセスの記述２０では、転送１を定義するため、経路１（４１）と、経路１と連結するポート２１１とポート２２１を用いている。同様に、転送２（４２）、転送３（４３）、転送４（４４）を定義するため、それぞれの経路と、当該経路と連結するポート対を用いている。バス４５は、それぞれの経路４１−４４と直結される。バス４５は、アービタ４７と連結される。バス４５の内部の詳細を記述するブロック４５Ａでは、排他制御のみを定義する。
【００８７】
図１２に示したアクセスの記述２０は、基本的に図１１と同様である。この例では、バス４５は、経路４１（転送１）、経路４３（転送３）、経路４４（転送４）と直結されるが、経路４２（転送２）とは直結されない。ポート対が増加することはない。
【００８８】
図１３に示したアクセスの記述２０は、基本的に図１１と同様である。この例では、バス１（４８）は、転送１の経路４１と転送２の経路４２と直結される。バス２（４９）は、転送３の経路４３と転送４の経路４４と直結される。セレクタ４６は、転送３の経路４３と転送４の経路４４と直結される。バス１（４８）、バス２（４９）、セレクタ４６は、それぞれアービタ４７と連結される。
【００８９】
図１４の記述２０は、本実施例のアーキテクチャ方式を用いて、図４のアーキテクチャ例の場合の性能評価データのダンプの例を示す。図１４に示したように、転送１の経路４１、転送２の経路４２、転送３の経路４３、転送４の経路４４が性能評価のための計測機能をもっているため、ファイル２７への性能評価データの転送（ダンプ）を行うためには、設計者は、データダンプオブジェクト１１４を用いて、そのアーキテクチャ情報を指定するだけでよい。
【００９０】
次に、シミュレーション時の通信方法について説明する。図１８は、経路オブジェクトが有する処理（メソッド）を実行するための処理手順を示す。
【００９１】
経路オブジェクトには、通信用のメソッドとして、少なくとも、リクエスト処理、グラント処理、送信処理、レディ処理、中断処理、終了処理、アンロック問合せ処理がある。
【００９２】
通信の説明をするために、イニシエータとレスポンダーの記述例を図２１に示す。イニシエータとは、ｒｅｑｕｅｓｔを送出してバスを確保する処理をするブロックのことで、レスポンダーとは、イニシエータから送られてきたデータをリアクティブに処理するブロックのことである。
【００９３】
図２３はビート転送をする場合の例を示している。また、アービタは図２２に示したＦＣＦＳアービタを使用する。この時、通信は図２３に示したシーケンス図のようになる。
【００９４】
図２１に示したように、経路オブジェクトのリクエスト処理をコールする。そして、ｗａｉｔ（ｐｏｒｔ１−＞ｅｖＧｒａｎｔ（））で、経路オブジェクト内のｇｒａｎｔ＿ｅｖｅｎｔの参照をもらい、ｇｒａｎｔ＿ｅｖｅｎｔが発生するのを待つ。
【００９５】
図２１のイニシエータ記述中の（ａ）で示した記述がこれに相当する。ｐｏｒｔ１は経路オブジェクト（のインターフェイス）のポートである。このポートを利用することにより、経路オブジェクトのメソッドをコールすることができる。
【００９６】
リクエスト処理ｒｅｑｕｅｓｔ（）がコールされると、図１８のリクエスト処理（ａ）が実行される。最初に、経路オブジェクトはグラント待ちの状態に遷移させる（Ｓ１５）。直結しているかどうかを判定する（Ｓ１６）。判定の方法は直結の表現方法に依存する。図１８では、排他制御オブジェクトのリストが空の時に直結していると判定する例を示している。直結している場合（ステップＳ１６の判定結果がＮＯの場合）、本来リクエストを必要としない。しかし、この実施例ではアービタがある場合と同じ手続きにするため、リクエストを使用する。直結している場合にはアービトレーションがないのでリクエストが来たら即座にグラントを返す（Ｓ１８）。
【００９７】
一方、排他制御オブジェクトのリストが空でない場合は、直結していない場合（ステップＳ１６の判定結果がＹＥＳの場合）であり、アービタリストの中のイベントｗａｋｅｕｐ＿ｅｖｅｎｔを発生させる（Ｓ１７）。このイベントが発生すると、アービタはスリープ状態からアクティブ状態に遷移する。
【００９８】
図２２の例では、初期状態では、履歴リストは空なので、ｗａｉｔ（ｗａｋｅｕｐ＿ｅｖｅｎｔ）で待っている状態で停止している。この状態で、ｗａｋｅｕｐ＿ｅｖｅｎｔが発生すると、アービタは動作し始める。そして、アービタの動作は、ｗａｉｔ（０，ＳＣ＿ＮＳ）で停止する。ここまでの処理は、図２３の１サイクル目（１ｓｔ＿Ｃｙｃｌｅ）の処理手順に相当する。
【００９９】
アービタ基底クラスがリクエストを発行した経路オブジェクトの集合を得る方法にはいくつかある。例えば、アービタ基底クラス内の経路オブジェクトリストから、グラント待ちになっている経路オブジェクトを抽出する方法、グラント待ち以外の経路オブジェクトをマスクする方法、アービタ基底クラスにリクエスト用のバッファを追加して、経路オブジェクトの参照を挿入する方法等がある。また、優先順位順に並べる方法としては、例えば、ＳＴＬのｓｅｔコンテナを使用する方法がある。
【０１００】
上記したｗａｉｔ（０，ＳＣ＿ＮＳ）は、デルタ遅延後に待ち状態から抜ける。このとき、リクエストの集合がすでに完成しているので、イテレータを用いて優先順位に従って順次スキャンする。この実施例では、アービタは、経路オブジェクトのアンロック問合せ処理（図１８の（ｇ））を行う。
【０１０１】
図１８のアンロック問合せ処理（ｇ）が開始すると、排他制御リストの要素が全てアンロック状態であるか否かを調べる（Ｓ２４）。この問合せ処理の結果はｂｏｏｌ値として返す。
【０１０２】
アンロック問合せ処理（ｇ）が行われ、経路オブジェクトがオープン（ｏｐｅｎ）ならば、経路オブジェクトのグラント処理を行う。
【０１０３】
図１８のグラント処理（ｅ）が開始すると、経路オブジェクトは送信待ちの状態に遷移する（Ｓ２０）。次に、ロック処理を行う（Ｓ２１）。従って、優先順位順に従って、上記した処理手順を繰り返すことでアービトレーションを実現できる。そして、経路オブジェクトはグラント処理が行われることにより、ｇｒａｎｔ＿ｅｖｅｎｔを発生する（Ｓ２２）。これにより、図２１の記述例では、 ｗａｉｔ（ｐｏｒｔ１−＞ｅｖＧｒａｎｔ（））（ここで、ｐｏｒｔ１−＞ｅｖＧｒａｎｔ（）はｇｒａｎｔ＿ｅｖｅｎｔの参照をもらう関数）で待っていたイニシエータが動き出し、次行のｗａｉｔ（）で次のクロックを待つ。
【０１０４】
また、経路オブジェクトが有する、その他の処理について説明する。
【０１０５】
図１８の登録処理（ａ）が開始すると、上述したように、排他制御リストに登録する処理が行われる（Ｓ１１）。
【０１０６】
図１８の中断処理（ｄ）が開始すると、図１８の転送終わり処理（ｉ）が行われる（Ｓ１９）。この転送終わり処理（ｉ）が開始すると、経路オブジェクトは終了待ちの状態に遷移する（Ｓ２８）。そして、ｅｎｄ＿ｅｖｅｎｔを発生させて（Ｓ２９）、転送終わり処理が終了する。
【０１０７】
図１８の終了（バス開放）処理（ｆ）が開始すると、経路オブジェクトはアイドル状態に遷移して（Ｓ２３）から、処理を終了する。
【０１０８】
図１８の通信処理（ｈ）が開始すると、まず、送信するビット数をセットする（Ｓ２５）。次に、経路オブジェクトは送信待ちの状態から送信中の状態に遷移する（Ｓ２６）。そして、ｓｅｎｄ＿ｅｖｅｎｔを発生して（Ｓ２７）から、処理を終了する。
【０１０９】
図１８のロック処理（ｊ）が開始すると、上述したように、排他制御リストの全ての要素をロックする処理が行われる（Ｓ３０）。
【０１１０】
アービタ基底クラスと経路オブジェクトが上記のような通信を行ってアービトレーションを実現しているので、このアービタは容易に複数の排他制御オブジェクトを制御することができる。経路には通常、優先順位か、順番（ラウンドロビン等で使われる）が割当てられる。このため、設計者が、あるアービタで制御される経路の集合に順序関係を割当てる必要がある。
【０１１１】
一方、あるアービタで制御される経路と別のアービタで制御される経路には、設計者は優先順位も順番も割当てる必要がない。この場合、これらの経路間に任意の関係を導入しても差し支えがない。
【０１１２】
これら２つの経路はアービタを共有しないことから、共有する排他制御オブジェクトがないので、どちらの経路からグラント処理をしても結果は同じになる。このため、任意の関係を導入して差支えがない。例えば、同じ優先順位や順番をもつ複数の経路があった場合、ＩＤ番号順に評価することとしてもよい。このようにすると、すべての経路間に順序関係を割当てることができる。このため、同一のアービトレーション・アルゴリズムで制御されるアービタは１つのアービタで制御しても結果が変わらない。従って、図６（ａ）のような回路であっても１つのアービタで扱えるようになる。また、図６（ａ）のセレクタ２６のように排他制御する要素が含まれていても、セレクタ固有の制御をする必要がない。
【０１１３】
本実施例のシミュレーション方式では、経路を構成する要素を１個増やすだけで済み、容易に複数の排他制御オブジェクトの制御が可能になる。
【０１１４】
以上説明したのがイニシエータとアービタの通信方法である。次に、イニシエータとレスポンダーの通信方法について説明する。
【０１１５】
イニシエータは、図２２の記述例では、転送ビート数を書き込んだ（図２２の（ｄ））後、アドレスの代わりに転送開始を示すｓｅｎｄ（）を転送している（図２２の（ｅ））。アドレスを送る拡張がなされている場合にはアドレスを書きこむ。
【０１１６】
また、データを転送するように拡張されている場合には、データも入力する。イニシエータはいずれの場合も、ｓｅｎｄ＿ｅｖｅｎｔを発生する。図２３に示したように、レスポンダーはｓｅｎｄ＿ｅｖｅｎｔが発生するのを待っているので、このイベントの発生により動作を開始する。
【０１１７】
レスポンダーは、図２１の記述例では、転送ビート数を調べる。もし、アドレスが送られている場合ならば、アドレスを取り出す。この記述例では ｒｅａｄｙ（）を１個返している。あるいは、ｒｅａｄｙ（個数）を返すことで、複数個のｒｅａｄｙ信号を一括して返すことも可能である。
【０１１８】
図１８のレディ処理（ｂ）が開始すると、転送カウンタに転送ビート数を加算する（Ｓ１２）。次に、転送カウンタがビート数に達したか否かを判定する（Ｓ１３）。転送カウンタがビート数に達したら、ｅｎｄ＿ｅｖｅｎｔを発生して正常終了する（Ｓ１４）。
【０１１９】
一方、転送カウンタがビート数に達する前に中断処理が行われる場合には、ｅｎｄ＿ｅｖｅｎｔを発生して異常終了する。
【０１２０】
イニシエータは、ｗａｉｔ（ｐｏｒｔ１−＞ｅｖＥｎｄ（））でｅｎｄ＿ｅｖｅｎｔの発生を待っている。このため、ｅｎｄ＿ｅｖｅｎｔが発生すると、図２３に示したように動作を再開する。
【０１２１】
ここで、異常終了もありえる場合には、図２３に示したように正常終了したかどうかを問合せる。正常終了したかどうかの判定は、転送カウンタとビート数が一致しているかどうかで判定できる。また、異常終了の場合、成功した転送ビート数が必要になることがあるが、転送カウンタの値を参照することで調べられる。
【０１２２】
上記した処理手順までで所望の転送処理が終わる。図２３の記述例では、次のサイクル（４ｔｈ＿Ｃｙｃｌｅ）で終了処理ｅｎｄ（）をコールしてバスを開放している。
【０１２３】
もし、開放しない場合には終了処理ｅｎｄ（）を行うことなく、次の処理手順を開始する。終了処理ｅｎｄ（）がコールされると、経路オブジェクト内にある排他制御オブジェクトのリストにある排他制御オブジェクト全てをアンロックする。
【０１２４】
このようにして、一連の転送が実現できる。また、図１８と図１５に示したように、関数コールにトリガーされて状態が遷移する。状態が変化に応じてトリガーされて状態値をシグナル（ＳｙｓｔｅｍＣの場合、ｓｃ＿ｓｉｇｎａｌ）に代入することで、状態を波形データとして反映させることができる。
【０１２５】
また、このＦＳＭを用いて経路の稼働時間を計測することができる。経路の稼動期間を、例えば、グラント処理から終了処理までとすると、グラント処理がコールされた時に現在の時間をもらう処理（ＳｙｓｔｅｍＣの場合、ｓｃ＿ｃｌｏｃｋ：：ｔｉｍｅ＿ｓｔａｍｐ（））を行って、得られた時間を開始時間に代入し、終了処理時に、同様にして現在の時間をもらい、得られた終了時間と開始時間の差を稼働時間に加算することで、稼働時間を求めることができる。この稼動時間はダンプオブジェクトにより利用される。
【０１２６】
次にパイプラインオブジェクトについて説明する。
【０１２７】
パイプラインオブジェクトは、イベントをパイプライン化する。パイプラインオブジェクトには、例えば、ＳｙｓｔｅｍＣによる実装の場合、イベントが起こるまでの時間を保持するＦＩＦＯバッファと、前のイベントが起こる時刻、内部制御用イベントオブジェクトと（外部参照用）イベントオブジェクト、動作中／サスペンド中を表現できるフラグが定義される。
【０１２８】
まず、パイプラインオブジェクトのイベント登録方法を説明する。最初に、イベント発生までの時間をもらう。もし、ＦＩＦＯバッファが空だったら、ＦＩＦＯバッファにイベントまでの時間を格納し、内部制御用イベントオブジェクトにイベント発生までの時間を通知する（ｎｏｔｉｆｙ）。ｓｃ＿ｅｖｅｎｔはｎｏｔｉｆｙ（時間）がコールされると、現在の時刻からｎｏｔｉｆｙ（）の引数で与えられた時間が経過すると、イベントを発生する。また、前のイベントが発生する時刻に、現在の時刻にイベント発生までの時間を加算したものを代入する。
【０１２９】
もし、ＦＩＦＯバッファが空でなかったら、ＦＩＦＯバッファに現在の時刻にイベント発生までの時間を加え、この時間から前のイベントが発生する時刻を差し引いた時間を代入する。前の時刻に、現在の時刻にイベント発生までの時間を加えたものを代入する。
【０１３０】
次に、パイプラインオブジェクトのイベントの発生方法を説明する。
【０１３１】
ＳｙｓｔｅｍＣの場合、ｓｃ＿ｔｈｒｅａｄを用いてイベントを発生させる。ｓｃ＿ｔｈｒｅａｄの中に無限ループを置く。ループの先頭でパイプラインオブジェクトが有する内部制御用イベントオブジェクトの発生を待つ。発生したら、外部参照用のイベントオブジェクトをｎｏｔｉｆｙ（）して、ＦＩＦＯバッファをポップする。この後、ＦＩＦＯバッファが空でなかったら、ＦＩＦＯバッファの先頭に格納されている時間を参照して、ｎｏｔｉｆｙ（参照して得られた時間）とする。
【０１３２】
これによりイベントをパイプライン化できる。イベントの発生はブロードキャストされるので、後段のパイプラインをサスペンドする必要がなければ、内部制御用イベントオブジェクトを外部参照用イベントオブジェクトで代用し、外部参照のイベントオブジェクトのｎｏｔｉｆｙ（）を省略することができる。
【０１３３】
次に、パイプラインオブジェクトの時間を中断・再開する方法を説明する。
【０１３４】
中断処理（ｐｅ．ｓｕｓｐｅｎｄ（））がコールされた時、ＦＩＦＯバッファの先頭の要素を書き換える。先頭の要素の値から現在の時刻を差し引き、直前のイベントの発生時刻を加えたものを先頭に書き込む。さらに、フラグをサスペンド中にする。サスペンド中に内部制御イベントが発生した場合、何もせずに内部制御イベント待ちにする。
【０１３５】
再開処理（ｐｅ．ｒｅｓｕｍｅ（））がコールされた時、前のイベントの発生時刻に現在の時刻を書き込み、内部制御オブジェクトに対してｎｏｔｉｆｙ（ＦＩＦＯバッファの先頭の値）をコールする。このようにしてパイプラインイベントを中断／再開させることができる。
【０１３６】
以上説明したように、図３乃至図６に示した事例を従来の方式で記述すると、図７乃至図１０のようになるが、本実施例のシミュレーション方式によれば図１１乃至図１４のようになる。したがって、設計者は、機能ブロック内部の記述を変更する必要がなくなる。また、ポートの書き換えが不要である。各機能ブロックにファイルを渡す記述の代わりに、データダンプオブジェクトにファイルを渡す記述に置き換えられることにより、記述量／記述変更量の削減が可能である。また、パイプラインイベントオブジェクトを使うと、従来方式のようにカウンタの記述等をすることなく、図２４のように通常のイベントと同様に、イベント発行とイベント受理で記述することができる。さらに、パイプラインイベントの動作を停止したい場合にも、中断処理ｓｕｓｐｅｎｄ（）をコールするだけで動作を停止することができ、少ない記述量で所望の動作を実現できる。
【０１３７】
本発明のシミュレーションシステムでは、バス／セレクタを実現する排他制御オブジェクトと、従来方式のチャネル・オブジェクトの代わりとなる経路オブジェクトと、従来方式ではバスに含まれていたアービトレーション・アルゴリズムを記述したアービタ基底クラスの継承クラスのオブジェクトを基本要素とし、アーキテクチャをこれらの基本要素で表現する。
【０１３８】
本発明のシミュレーションシステムは、排他制御オブジェクトと経路オブジェクトを関係づけ、経路オブジェクトに機能ブロックとの通信機能を集約し、排他制御オブジェクトが必要に応じて、アービタオブジェクトにアクセスする機能を与える手段を有する。また、経路オブジェクトがアーキテクチャの状態を計測する機能を与える手段を有する。
【０１３９】
したがって、各機能ブロックには経路オブジェクトを渡すだけでよい。また、転送と排他制御は各オブジェクトの中で処理でき、従来方式のように設計者側の記述で対処する必要がなくなり、冗長な記述の削減ができる。
【０１４０】
本発明のシミュレーションシステムは、基本要素の宣言、基本要素間の関係づけの宣言により、アーキテクチャ情報を経路管理オブジェクト、排他制御管理オブジェクト、アービタ管理オブジェクトに登録する手段を有し、登録の際に自動でアーキテクチャを生成する手段を有する。
【０１４１】
したがって、キーの要素を指定すれば、実行コードの実行中にそのほかの制御要素を自動生成できるようになる。設計者はキー要素の指定だけで所望の機能を実現できるようになり、記述量の削減／記述変更量の削減ができる。
【０１４２】
本発明のシミュレーションシステムは、アービタ基底クラスについて制御の対象となる経路オブジェクトの集合を記憶する手段を有し、アービタで制御される排他制御オブジェクトの集合を記憶する手段を有する。アービタで制御される排他制御オブジェクトが登録されると、排他制御オブジェクトに記憶する。経路管理オブジェクトを用いて、登録された排他制御オブジェクトを通る経路オブジェクトを取り出す手段を有し、取り出したオブジェクトを前記経路オブジェクトの集合に記憶することができる。
【０１４３】
したがって、アービタ基底クラスに排他制御オブジェクトを登録するだけで、経路オブジェクトの集合を保持できるようになり、記述量の削減／記述変更量の削減ができる。
【０１４４】
本発明のシミュレーションシステムは、経路オブジェクトを利用して行われる通信を監視して、経路の状態（例えば、アイドル、グラント待ち、送信待ち、送信中、終了待ちの状態）を管理する手段を有し、この経路が単位時間当たりに実際に利用した時間や単位時間当たりにリクエストから処理を終えるまでの時間を計測する手段を有する。また、データダンプオブジェクトは各管理オブジェクトを参照する手段を有し、各管理オブジェクトを各々の管理対象となるオブジェクトを参照する手段を有し、データダンプオブジェクトから任意のオブジェクトにアクセスする手段を有する。
【０１４５】
したがって、経路オブジェクトのみでバスの状態に関わるデータを計測することができ、収集したアーキテクチャ構成データをダンプすることができる。また、簡単にバス占有率、あるバスの経路別の利用率を算出することが可能になる。本発明のシミュレーション方式によれば、活性化率計算の記述量が削減できるとともにデータダンプ処理のための記述量が削減できる。
【０１４６】
本発明のシミュレーションシステムは、経路オブジェクトについてのアービトレーションの優先順位を保持する手段を有し、アービタ基底クラスの登録により経路オブジェクトの集合を作成する際に、この優先順位の順に従って配列する手段を有する。アービタ基底クラスについてはこの優先順位の順に経路オブジェクトを参照する機能を与える手段を有する。したがって、優先順位を利用するアービタアルゴリズムの記述量／変更記述量を削減することができる。
【０１４７】
本発明のシミュレーションシステムは、経路オブジェクトに基づいてイニシエータがアドレスを入力する処理を実行する手段を有し、経路オブジェクトにアドレスを保持する手段を有し、レスポンダーがアドレスを読み出す処理を実行する手段を有する。したがって、アドレスの転送を可能にすることができる。これにより、アドレスを使用する記述であっても、記述量／変更記述量の削減が可能になる。
【０１４８】
本発明のシミュレーションシステムは、経路オブジェクトが、実際の回路ではあるアドレス空間と対応することに着目して、経路オブジェクトにアドレス空間を保持する手段を有し、伝達されるアドレスがアドレス空間に含まれるか否かを判定する手段を有する。したがって、アドレスが指定したアドレス空間に含まれているか否かを、少ない記述量で判定することが可能になる。
【０１４９】
本発明のシミュレーションシステムにおいては、経路オブジェクトが経路管理オブジェクトに集約されていることから、経路管理オブジェクトが経路オブジェクトのアドレス空間の重複を検査する手段を有し、同一のアドレス空間をアクセスする経路の集合とアドレス空間の関係表をダンプする手段を有する。あるいは、同一のアドレス空間をアクセスする経路が１つであるアドレス空間とこの経路の関係表をダンプする手段を有する。
【０１５０】
したがって、指定したアドレス空間が適切であるか視認検査できるようになる。このような検査が少ない記述量で実現できる。
【０１５１】
本発明のシミュレーションシステムにおいては、経路オブジェクトが一連の処理において、前段の処理が後段の処理を起動するイベントを有し、経路オブジェクトを用いて起動信号の授受を実現する。これにより記述量／記述変更量の削減ができる。
【０１５２】
本発明のシミュレーションシステムにおいては、複数の経路オブジェクトの順序列を入力として受け取り、先頭のオブジェクトの起動をかけるイベントを最後尾のオブジェクトのイベントに置き換える手段を有する。例えば、ＳＤＲＡＭやチップ上のＳＲＡＭに一旦データを書きこむ経路と、ＳＤＲＡＭやチップ上のＳＲＡＭから書き込まれたデータを読み出す経路により、間接的に繋がっている２つの機能ブロック間で起動信号の授受をすることを可能にする。
【０１５３】
本発明のシミュレーションシステムにおいては、排他制御オブジェクトがデータ幅を有し、経路オブジェクトがこの経路を構成する排他制御オブジェクトのうち最小のデータ幅を探す手段を有する。データの幅が重要であるアーキテクチャのシミュレーションが可能になる。排他制御オブジェクトは本質的にデータ幅を保持する対象であることから、記述量を低く抑えた実装を可能にしている。
【０１５４】
本発明のシミュレーションシステムにおいては、イベントをパイプライン化する手段を有するオブジェクトをデータベースに設けることができる。これにより、機能記述ブロック内部のバス・アクセス記述内部、または複数のバス・アクセス記述間のイベントのやり取りを簡易化でき、記述量の削減ができる。
【０１５５】
（付記１） アーキテクチャを、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを基本要素として表現したソースコードからシミュレーション実行コードを生成するシミュレーションシステムであって、前記排他制御オブジェクトを管理する排他制御管理オブジェクトと、前記経路オブジェクトを管理する経路管理オブジェクトと、前記アービタオブジェクトを管理するアービタ管理オブジェクトと、前記排他制御オブジェクトと前記経路オブジェクトを関係づけ、前記経路オブジェクトに機能ブロックとの通信機能を集約し、前記排他制御オブジェクトが必要に応じて、前記アービタオブジェクトにアクセスする機能を与える手段と、前記経路オブジェクトがアーキテクチャの状態を計測する機能を与える手段とを備えることを特徴とするシミュレーションシステム。
【０１５６】
（付記２） 前記経路オブジェクトについてのアービトレーションの優先順位を保持する手段と、前記アービタオブジェクトの登録により経路オブジェクトの集合を作成する際に、前記優先順位の順に従って配列する手段と、前記アービタオブジェクトが前記優先順位の順に経路オブジェクトを参照する機能を与える手段とを備えることを特徴とする付記１記載のシミュレーションシステム。
【０１５７】
（付記３） 前記経路オブジェクトに基づいてアドレス空間を保持する手段と、伝達されるアドレスが前記アドレス空間に含まれるか否かを判定する手段とを備えることを特徴とする付記１記載のシミュレーションシステム。
【０１５８】
（付記４） 前記経路オブジェクトに基づいて、送信元の機能ブロックを実現するオブジェクトからのアドレスを入力し、前記経路オブジェクトに前記アドレスを保持する処理を実行する手段と、送信先の機能ブロックを実現するオブジェクトが前記アドレスを読み出す処理を実行する手段を備えることを特徴とする付記１記載のシミュレーションシステム。
【０１５９】
（付記５） アーキテクチャを、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを基本要素として表現したソースコードからシミュレーション実行コードを生成するシミュレーション方法であって、前記排他制御オブジェクトを管理する排他制御管理オブジェクトと、前記経路オブジェクトを管理する経路管理オブジェクトと、前記アービタオブジェクトを管理するアービタ管理オブジェクトとを含むシミュレーションシステムを作成する手順と、前記排他制御オブジェクトと前記経路オブジェクトを関係づける手順と、前記経路オブジェクトに機能ブロックとの通信機能を集約する手順と、前記排他制御オブジェクトが必要に応じて、前記アービタオブジェクトにアクセスする機能を与える手順と、
前記経路オブジェクトがアーキテクチャの状態を計測する機能を与える手順とを有することを特徴とするシミュレーション方法。
【０１６０】
（付記６） 前記経路オブジェクトのアドレス空間と前記経路オブジェクトとの関係を保持する手段と、前記経路オブジェクトの経路を通るアドレスが前記アドレス空間に含まれるか否かを判定する手段とを備え、正しいアドレスが送付されているかを検査できるよう構成したことを特徴とする付記３記載のシミュレーションシステム。
【０１６１】
（付記７） 複数の経路オブジェクトで構成される経路を宣言する手段と、前記複数の経路オブジェクトで構成される前記経路の先頭の経路オブジェクトに与えられた処理開始イベントを、前記複数の経路オブジェクトで構成される前記経路の末尾の経路オブジェクトに伝達させる手段とを備え、前記末尾の経路オブジェクトに伝達された処理開始イベントを参照できるよう構成したことを特徴とする付記４記載のシミュレーションシステム。
【０１６２】
（付記８） パイプラインイベントオブジェクトと、パイプラインイベントにイベントをパイプライン化して発生させる手段と、イベントの発生時間を遅延させる手段とを備えることを特徴とする付記１記載のシミュレーションシステム。
【０１６３】
（付記９） 前記シミュレーションシステムが、前記経路オブジェクトに基づいて、送信元の機能ブロックを実現するオブジェクトからのアドレスを入力し、前記経路オブジェクトに前記アドレスを保持する処理を実行する手段と、送信先の機能ブロックを実現するオブジェクトが前記アドレスを読み出す処理を実行する手段を備えるよう作成され、かつ、複数の経路オブジェクトで構成される経路を宣言する手順と、前記複数の経路オブジェクトで構成される前記経路の先頭の経路オブジェクトに与えられた処理開始イベントを、前記複数の経路オブジェクトで構成される前記経路の末尾の経路オブジェクトに伝達させる手順とを有することを特徴とする付記５記載のシミュレーション方法。
【０１６４】
（付記１０） 前記シミュレーションシステムが、パイプラインイベントオブジェクトと、パイプラインイベントにイベントをパイプライン化して発生させる手段と、イベントの発生時間を遅延させる手段とを備えるよう作成されることを特徴とする付記５記載のシミュレーション方法。
【発明の効果】
以上説明したように、本発明のシミュレーション方式によれば、従来方式で処理やアーキテクチャを記述する場合に必要であった機能ブロック内部の記述、ポートの書き換えが不要となり、設計者による記述の量や記述の変更量を削減することができる。また、本発明のシミュレーション方式では、パイプラインイベントオブジェクトを使用すると、従来方式のようにカウンタの記述をすることなく、通常のイベントと同様に、イベント発行とイベント受理で記述することができ、少ない記述量で所望の動作を実現できる。
【０１６５】
【図面の簡単な説明】
【図１】本発明の一実施例に係るアーキテクチャのシミュレーションシステムを示すブロック図である。
【図２】図１のシミュレーションシステムが利用するデータベースの構成を示すブロック図である。
【図３】従来の方式と本発明を比較するために使用する処理例を示す図である。
【図４】従来の方式と本発明を比較するために使用する、処理例とアーキテクチャ例の関係を示す図である。
【図５】従来の方式と本発明を比較するために使用する、処理例とバイパスを加えたアーキテクチャ例の関係を示す図である。
【図６】従来の方式と本発明を比較するために使用する、処理例とマルチレイヤバスにしたアーキテクチャ例の関係を示す図である。
【図７】図４の処理例とアーキテクチャ例に従来の方式を適用した場合のモデル構成の例を示す図である。
【図８】図５の処理例とアーキテクチャ例に従来の方式を適用した場合のモデル構成の例を示す図である。
【図９】図６の処理例とアーキテクチャ例に従来の方式を適用した場合のモデル構成の例を示す図である。
【図１０】従来の方式を適用した場合の性能評価データのダンプの例を示す図である。
【図１１】図４の処理例とアーキテクチャ例に本発明のシミュレーション方式を適用した場合のモデル構成の例を示す図である。
【図１２】図５の処理例とアーキテクチャ例に本発明のシミュレーション方式を適用した場合のモデル構成の例を示す図である。
【図１３】図６の処理例とアーキテクチャ例に本発明のシミュレーション方式を適用した場合のモデル構成の例を示す図である。
【図１４】本発明のシミュレーション方式を適用した場合の性能評価データのダンプの例を示す図である。
【図１５】経路オブジェクトの状態遷移を説明するため図である。
【図１６】経路クラスの構成を示す図である。
【図１７】アービタ基底クラスの構成を示す図である。
【図１８】経路クラスが有する処理を実行するための処理手順を説明するためのフロー図である。
【図１９】メイン関数の記述例を示す図である。
【図２０】トップ階層の記述例を示す図である。
【図２１】イニシエータとレスポンダの記述例を示す図である。
【図２２】アービタ基底クラスから継承したクラスの記述例を示す図である。
【図２３】図１９乃至図２２の記述例を用いてシミュレーションを行う場合の転送シーケンスを説明するための図である。
【図２４】パイプラインオブジェクトの記述例を示す図である。
【符号の説明】
１００ シミュレーションシステム
１１１ 経路管理オブジェクト
１１２ 排他制御管理オブジェクト
１１３ アービタ管理オブジェクト
１１４ データダンプオブジェクト
１１５ 性能評価データ
１１６ 波形データ
１１８ サンプリングクロックオブジェクト
１１９ アーキテクチャ構造データ
１２０ 経路オブジェクトのコンストラクション
１２１ 排他制御オブジェクトのコンストラクション
１２２ アービタオブジェクトのコンストラクション
１２３ 経路オブジェクトへの排他制御オブジェクのアサイン
１２４ アービタオブジェクトへの排他制御オブジェクトのアサイン
１２５ 波形ファイル指定
１２６ 性能評価データ用指定
１２７ シミュレーション実行
Claims (5)
- バスを介し接続された複数の機能ブロックと、転送経路と、アービタとを含むアーキテクチャを、設計者がハードウェア設計用のオブジェクト指向言語を用いて記述した、排他制御オブジェクト、経路オブジェクト、アービタオブジェクトを含むソースコードをコンパイル処理して実行コードを生成するシミュレーションシステムであって、
前記排他制御オブジェクトを管理するための排他制御管理データベースと、
前記経路オブジェクトを管理するための経路管理データベースと、
前記アービタオブジェクトを管理するためのアービタ管理データベースとを有し、
前記シミュレーションシステムは、前記排他制御オブジェクト、前記経路オブジェクト、及び前記アービタオブジェクトから生成した各実行コードにより、前記排他制御オブジェクト、前記経路オブジェクト、及び前記アービタオブジェクトを参照するための識別データを前記排他制御管理データベース、前記経路管理データベース、及び前記アービタ管理データベースにそれぞれ登録し、
前記シミュレーションシステムは、設計者の記述した前記経路オブジェクトへの前記排他制御オブジェクトのアサインから生成した実行コードにより、前記排他制御オブジェクトを前記経路オブジェクトの内部領域に登録し、
前記シミュレーションシステムは、設計者の記述した前記アービタオブジェクトへの前記排他制御オブジェクトのアサインから生成した実行コードにより、前記アービタオブジェクトが制御する前記排他制御オブジェクトを含む経路オブジェクトを全て前記アービタオブジェクトの内部領域に登録することにより、
シミュレーション実行時に、各管理データベースと通信する機能を提供して、前記アーキテクチャの性能評価データを生成することを特徴とするシミュレーションシステム。 - 前記シミュレーションシステムは、前記経路オブジェクトについてのアービトレーションの優先順位を保持し、前記アービタオブジェクトの登録により経路オブジェクトの集合を作成する際に、前記優先順位の順に従って配列し、前記アービタオブジェクトが前記優先順位の順に経路オブジェクトを参照する機能を提供することを特徴とする請求項１記載のシミュレーションシステム。
- 前記シミュレーションシステムは、前記経路オブジェクトに基づいてアドレス空間を保持し、伝達されるアドレスが前記アドレス空間に含まれるか否かを判定することを特徴とする請求項１記載のシミュレーションシステム。
- 前記シミュレーションシステムは、前記経路オブジェクトに基づいて、送信元の機能ブロックを実現するオブジェクトからのアドレスを入力し、前記経路オブジェクトに前記アドレスを保持する処理を実行し、送信先の機能ブロックを実現するオブジェクトが前記アドレスを読み出す処理を実行することを特徴とする請求項１記載のシミュレーションシステム。
- 前記シミュレーションシステムは、設計者の記述した性能評価データ用指定を管理するためのデータダンプオブジェクトを有し、前記性能評価データ用指定から生成した実行コードにより、性能評価データファイル名とサンプリングクロックを前記データダンプオブジェクトに登録し、前記データダンプオブジェクトが前記排他制御管理データベース、前記経路管理データベース、及び前記アービタ管理データベースと通信することにより、前記アーキテクチャの性能評価データを性能評価データファイルに転送することを特徴とする請求項１記載のシミュレーションシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003136240A JP4268830B2 (ja) | 2003-05-14 | 2003-05-14 | アーキテクチャのシミュレーションシステム及びシミュレーション方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003136240A JP4268830B2 (ja) | 2003-05-14 | 2003-05-14 | アーキテクチャのシミュレーションシステム及びシミュレーション方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004341737A JP2004341737A (ja) | 2004-12-02 |
| JP4268830B2 true JP4268830B2 (ja) | 2009-05-27 |
Family
ID=33526269
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003136240A Expired - Fee Related JP4268830B2 (ja) | 2003-05-14 | 2003-05-14 | アーキテクチャのシミュレーションシステム及びシミュレーション方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4268830B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7734785B2 (en) * | 2004-12-09 | 2010-06-08 | International Business Machines Corporation | On demand message based financial network integration middleware |
| CN111950219B (zh) * | 2019-04-30 | 2024-06-18 | 北京百度网讯科技有限公司 | 用于实现模拟器的方法、装置、设备以及介质 |
-
2003
- 2003-05-14 JP JP2003136240A patent/JP4268830B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004341737A (ja) | 2004-12-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6154816A (en) | Low occupancy protocol for managing concurrent transactions with dependencies | |
| US7735087B2 (en) | Task switching apparatus, method and program | |
| US6014690A (en) | Employing multiple channels for deadlock avoidance in a cache coherency protocol | |
| Attiya et al. | Sequential consistency versus linearizability | |
| US6085276A (en) | Multi-processor computer system having a data switch with simultaneous insertion buffers for eliminating arbitration interdependencies | |
| EP0911731B1 (en) | Order supporting mechanisms for use in a switch-based multi-processor system | |
| US7720891B2 (en) | Synchronized objects for software transactional memory | |
| US6094686A (en) | Multi-processor system for transferring data without incurring deadlock using hierarchical virtual channels | |
| US7475198B2 (en) | Asynchronous symmetric multiprocessing | |
| US8156507B2 (en) | User mode file system serialization and reliability | |
| KR100280161B1 (ko) | 순서를 벗어난 작업처리 방법 및 장치 | |
| CN107729050B (zh) | 基于let编程模型的实时系统及任务构建方法 | |
| US8140503B2 (en) | Information processing apparatus having process units operable in parallel | |
| JP3899104B2 (ja) | システム開発方法及びデータ処理システム | |
| JP3162321B2 (ja) | 論理シミュレーション方法及び論理シミュレーション方法を実現させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP4268830B2 (ja) | アーキテクチャのシミュレーションシステム及びシミュレーション方法 | |
| Wang et al. | Synthesizing operating system based device drivers in embedded systems | |
| CN111767337B (zh) | 区块的验证方法、装置及设备 | |
| JPH09120387A (ja) | データ処理装置 | |
| JP3261766B2 (ja) | マルチプロセッサシステム、共有変数更新装置、プロセッサユニット及び共有変数更新方法 | |
| Gainer et al. | Multi-scale verification of distributed synchronisation | |
| US7216194B2 (en) | Methods and systems for improving delayed read handling | |
| Skjellum et al. | The Real‐Time Message Passing Interface Standard (MPI/RT‐1.1) | |
| Cao et al. | Transaction Scheduling: From Conflicts to Runtime Conflicts | |
| Oswald | Automatic generation of highly concurrent, hierarchical and heterogeneous cache coherence protocols from atomic specifications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060308 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080924 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080930 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081125 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090217 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090223 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120227 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130227 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140227 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |