JP2003015968A

JP2003015968A - バスシミュレータ

Info

Publication number: JP2003015968A
Application number: JP2001198539A
Authority: JP
Inventors: Yoshihisa Saito; 美寿齋藤; Shigetoshi Wakayama; 繁俊若山
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2001-06-29
Filing date: 2001-06-29
Publication date: 2003-01-17

Abstract

(57)【要約】【課題】本発明は、バスの構成をフレキシブルに変える
ことが可能なバスシミュレータを提供することを目的と
する。【解決手段】バスシミュレータは、バスへのバストラン
ザクションの発行及びバスからのバストランザクション
の受信の少なくとも一方を実行するモジュールと、バス
に発行されたバストランザクションを記録するテーブル
を含みテーブルからバストランザクションを選択するこ
とでバス調停を実行し選択されたバストランザクション
を発行先モジュールに転送するバス部を含み、バストラ
ンザクションを表現するデータ構造はバストランザクシ
ョン間で共通の項目を含み、共通項目は少なくとも発行
元モジュールを識別する項目及び発行先モジュールを識
別する項目を含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般にシミュレータ
に関し、詳しくは、メモリサイクル及びバスサイクル精
度の高いバスシミュレータに関する。

【０００２】

【従来の技術】ＬＳＩ技術の高度化に伴い、システムの
広範囲な部分を単一のＬＳＩに出来るようになってきて
いる。ＬＳＩ上にシステムを構成するにあたって重要な
役割を担うのが、各リソース間の情報のやり取りを媒介
するバスである。

【０００３】従来、バス設計をする場合には、必要とさ
れるバンド幅の条件や設計者の経験等に基づいて、バス
幅やバス形態等を決定していた。リアルタイム性が必要
とされるプログラム開発では、プロセッサのシミュレー
タについては高いサイクル精度で動作するものがある
が、バス部分まで含めてサイクル精度が高いシミュレー
ションを高速に実行できるものはない。

【０００４】例えば特許公報第２６６３８９３には、プ
ロセッサ等に用いられるアーキテクチャシミュレータが
開示されている。このシミュレータの場合、バス部はバ
ス遅延情報をハードウェア毎に用意することになり、バ
スサイクルに関しては高い精度を実現出来るものではな
い。またバス形態やパラメータを変更することを想定し
ていないため、バスの構成が変わればシミュレータを作
り直す必要がある。

【０００５】一方、バスの構成を評価する従来の技術と
しては、特開平１０−３４０２５１に開示の技術があ
る。この方式では、バスの調停モデルにバス内モジュー
ルからリクエストを発行し、調停後グラントを返し、グ
ラントを受け取ったモジュールが動作権を得て動作する
ことでバス動作をシミュレートしている。この方式では
バスプロトコルをリクエスト、グラントに統一すること
で、細かな制御信号等を削除して、汎用性を出す工夫を
している。この方式では、バス調停そのものは抽象化さ
れているが、モジュール動作は各固有動作を行う。

【０００６】

【発明が解決しようとする課題】特開平１０−３４０２
５１の方式では調停の仕方を変えることで複数のバス形
態を実現できるが、ハードウェアのバスに近いプロトコ
ル（リクエスト、グラント）を用いており、ハードウェ
アの信号に近い形のシミュレーションである。このた
め、バストランザクションが開始してから終了するまで
のトランザクション全体の情報や、そのトランザクショ
ンが新たなトランザクションを生み出した場合に新規ト
ランザクションまで含めた全ての情報を集めることが難
しい。つまり、シミュレータで得られた結果を、有効に
利用することが難しい。

【０００７】例えばバスにプロセッサが接続されている
場合、プロセッサの性能を調べるためには、プロセッサ
のある命令を実行して、動作の推移を逐次調べていく必
要がある。即ち例えば、ある命令がバスのトランザクシ
ョンを生成し、そのトランザクション終了後の結果をプ
ロセッサに返すような場合、この命令から追跡して、そ
れに関わるキャッシュやバス等の動作を全て把握する必
要がある。しかし特開平１０−３４０２５１の方式で
は、こうした情報を把握して、プロセッサの性能評価に
利用することは難しい。

【０００８】このような動的な情報を利用できるのであ
れば、ソフトウェア開発時において、ソフトウェア開発
者は、バスのレイテンシや競合の有無等の情報に基づい
てシステムを最適化することができる。またハードウェ
アのアーキテクチャ設計の面からも、ハードウェア構成
上ボトルネックになっている箇所とソフトウェア処理と
の関連が分かるため、ターゲットとするアプリケーショ
ンに即してハードウェアを最適化すること等が可能とな
る。

【０００９】更に特開平１０−３４０２５１の方式で
は、シミュレーションの形態がハードウェアの信号に近
いために、リクエスト・グラント方式とは異なるバス構
成、例えばビジー制御によるバス構成等の実現が難し
く、柔軟性が十分でない。またバスパラメータやアーキ
テクチャを設定する方法がない。

【００１０】以上を鑑みて、本発明は、バスの構成をフ
レキシブルに変えることが可能なバスシミュレータを提
供することを目的とする。

【００１１】

【課題を解決するための手段】本発明によるバスシミュ
レータは、バスへのバストランザクションの発行及び該
バスからのバストランザクションの受信の少なくとも一
方を実行するモジュールと、該バスに発行された該バス
トランザクションを記録するテーブルを含み該テーブル
からバストランザクションを選択することでバス調停を
実行し該選択されたバストランザクションを発行先モジ
ュールに転送するバス部を含み、該バストランザクショ
ンを表現するデータ構造は該バストランザクション間で
共通の項目を含み、該共通項目は少なくとも発行元モジ
ュールを識別する項目及び発行先モジュールを識別する
項目を含むことを特徴とする。

【００１２】上記発明では、バストランザクションを選
択して発行先に渡すことで、このトランザクションに関
して、バスへの発行、バス内での調停、発行先への到達
をシミュレーション表現できる。このようにトランザク
ションを選択して発行先に渡すことは、実際のハードウ
ェアにおいて、複数のリクエストがバス内モジュールか
らバスに発行されたときに、その中の一つにバス権を与
えることに相当する。即ち、調停によりバス権を選択的
に付与するのと同じことを、抽象的にシミュレーション
によって実現することが出来る。これにより、バス部に
おけるデータ調停に相当する選択処理を種々の異なった
方式で実行することが容易となり、複数種類のバスを容
易に実現することができる。この際、各モジュールは、
バスを表現するテーブルにバストランザクションを発行
する機能と、そのテーブルからバストランザクションを
受け取る機能を備えればよい。従って、テーブルでの選
択の仕方即ちバスの種類に変更があっても、各モジュー
ルには変更を加える必要はない。このようにして本発明
では、バスの形態をシミュレーション実行単位で容易に
変更することが可能となる。

【００１３】

【発明の実施の形態】以下に、本発明の実施例を添付の
図面を用いて詳細に説明する。

【００１４】図１は、トランザクションを表現するデー
タ構造の一部を示す図である。

【００１５】本発明においては、図１に示されるように
データ構造としてバスのトランザクションを表現する。
このように、リクエスト及びグラントのようなハードウ
ェア依存のバスプロトコルに関する情報ではなく、バス
トランザクションやメモリトランザクションといった一
連の動き全体を纏めてデータ構造として与えることで、
トランザクションの抽象化を行い、バスの抽象化を実現
することが出来る。この結果、任意のバス形態及びパラ
メータ設定に対する柔軟性、更にトランザクションが纏
まっていることによる容易なボトルネック解析を提供す
ることが出来る。

【００１６】一連のバストランザクションは、バスへの
コマンド発行、コマンド調停、コマンドの発行元受取、
バスへのデータ発行、データ調停、データの発行先受取
等を含む。このトランザクションを図１に示されるよう
なデータ構造で表現し、バストランザクションの情報に
関してバスモジュール発行元への依存性をなくすため
に、発行元モジュールを識別するメンバ、発行先モジュ
ールを識別するメンバ等の共通メンバをデータ構造内に
設ける。ここで共通メンバとは、異なる種類のトランザ
クションであっても全てのトランザクションに共通して
設けられるメンバである。このような共通メンバを設け
ることによって、統一的なバストランクションの調停が
可能になる。

【００１７】図２は、図１のデータ構造を用いたバスト
ランザクションの概念を示す図である。

【００１８】図１のデータ構造をもつトランザクション
を、バス部を表現するテーブルに入れることがバスへの
リクエスト発行に相当する。そのテーブル内にエントリ
がある場合はバスにリクエストが存在する状態であり、
エントリが無い場合はリクエストが存在しない状態であ
る。当該テーブル内にエントリが一つだけ存在する場合
には、それを選択する。選択されたトランザクションの
データ構造において、発行先モジュールを表現するメン
バを参照し、発行先のバス内モジュールを特定する。特
定されたバス内モジュールに対して、本発明のデータ構
造を有するトランザクションを渡す。

【００１９】バステーブル内にエントリが複数ある場合
には、優先順位に従って、当該データ構造を有するトラ
ンザクションを一つ選択する。この優先順位は、発行元
モジュールの種類（source_module）、発行先モジュー
ルの種類（destination_module）、トランザクションの
バスへの発行時間（time_bus_issue）等に基づいて設定
することが出来る。このように優先順位に従って選択す
る選択行為が、バス部におけるデータ調停に相当する。
この選択を種々の異なった方式で実行することで、複数
種類のバスを実現することができる。

【００２０】上述のようにしてトランザクションを選択
して発行先に渡すことで、このトランザクションに関し
て、バスへの発行、バス内での調停、発行先への到達を
シミュレーション表現できる。このようにトランザクシ
ョンを選択して発行先に渡すことは、実際のハードウェ
アにおいて、複数のリクエストがバス内モジュールから
バスに発行されたときに、その中の一つにバス権を与え
ることに相当する。即ち、調停によりバス権を選択的に
付与するのと同じことを、抽象的にシミュレーションに
よって実現している。

【００２１】バス内モジュールは、本発明のデータ構造
を有するトランザクションを、バスを表現するテーブル
に発行する機能と、そのテーブルから当該データ構造を
有するトランザクションを受け取る機能を備えればよ
い。従って、テーブルでの選択の仕方即ちバスの種類に
変更があっても、バス内モジュールには変更を加える必
要はない。

【００２２】図３は、優勢順位テーブルの構成例を示す
図である。

【００２３】バス部に発行されたトランザクションは、
バスを表現するテーブルにリンクされる。このバスのテ
ーブルからトランザクションを選択するための優先順位
の決定を、優先順位を記載したテーブルを参照して実行
することが出来る。図３は、そのような優先順位を記載
したテーブルをポインタによるリンクで模式的に示した
図である。このテーブルは初期化時に設定可能であり、
またテーブル内の順序をシミュレーション中に動的に変
える機構をもたせてもよい。シミュレータは、このテー
ブルに登録される優先順位とトランザクションデータ構
造内に記載されている発行元モジュールや発行先モジュ
ールとを比べて、優先順位の高いトランザクションを選
択する。

【００２４】図４乃至図６は、優先順位に従って選択す
る選択行為を種々の異なった方式で実行することで、複
数種類のバスを実現する様子を説明するための図であ
る。

【００２５】図４は、１本のバスで構成される場合のバ
ストランザクション選択を示す図である。

【００２６】図４に示されるように、バス部に発行され
たトランザクションがリンクされたバス内テーブルか
ら、優先順位テーブルに記載された優先順位に従って、
一つのトランザクションを選択する。これは即ち、実際
のハードウェアにおいて、複数のリクエストがモジュー
ルから１本のバスに発行されたときに、その中の一つに
バス権を与えることに相当する。

【００２７】図５は、複数のバスで構成される場合のバ
ストランザクション選択を示す図である。

【００２８】図５に示されるように、バス部に発行され
たトランザクションがリンクされたバス内テーブルか
ら、優先順位テーブルに記載された優先順位に従って、
最大n個のトランザクションを選択する。これは即ち、
実際のハードウェアにおいて、複数のリクエストがモジ
ュールから複数本（ｎ本）のバスに発行されたときに、
その中から最大n個のリクエストにバス権を与えるのと
同じことを抽象的に実現している。

【００２９】図６は、クロスバー構成のバスの場合につ
いてバストランザクション選択を示す図である。

【００３０】クロスバー構成のバスは、概念的には、縦
方向に一列に配置されたモジュールと横方向に一列に配
置されたモジュールとの間で、バスが縦横に二次元配列
された構成であり、縦方向のバスと横方向のバスを辿る
ことで、任意のモジュールから任意のモジュールに接続
することが出来る。クロスバー構成のバスにおいては、
転送先が異なる複数のリクエスト間には衝突はないが、
転送先が同一である複数のリクエスト間では衝突するた
め一つのリクエストを選択するよう調停する必要があ
る。

【００３１】図６に示されるように、バス部のテーブル
内にエントリがあるとき、まずエントリ（トランザクシ
ョン）を発行先毎に分けたテーブルを生成する。発行先
毎に分けたテーブルから、発行先別に用意した優先順位
テーブルに記載された優先順位に従ってトランザクショ
ンを選択する。この選択したトランザクションを発行先
に渡す。このように発行先ごとに調停を行うことで、発
行先が受け取り可能な状態の場合には、一つの選択され
たトランザクションを受け取ることができる。また、発
行先が異なるトランザクション同士の間では、互いに影
響し合うことはない。

【００３２】図７は、転送データの状態を表現するデー
タ構造のメンバを有するトランザクションのデータ構造
を示す図である。

【００３３】図７に示されるトランザクションデータ構
造は、共通メンバとして少なくともバス内モジュールの
発行元モジュールを識別するメンバ、発行先モジュール
を識別するメンバを有し、更に転送データの状態を表現
するデータ構造を持つメンバ（data_state）を有する。

【００３４】その転送データの状態を表現するメンバは
少なくともバースト数分（MAX_BURST_LENGTH）のフィー
ルドを備え、各フィールドは転送データの状態を保持す
る。その状態には少なくとも、「データ発行元にあ
る」、「バス内にある」、「データ発行先にある」とい
う３つの状態がある。このフィールドを「データ発行元
にある」から開始して、「バス内にある」、更に「デー
タ発行先にある」の順で遷移させることによってバース
ト内の各データを転送する。

【００３５】図８は、図７のデータ構造を用いた場合の
データのバス転送を示す。

【００３６】データを表現するメンバは、先頭のデータ
と共に、バス内を発行元から発行先に転送される。後続
のバーストデータは、各バーストデータを表すフィール
ドの状態を遷移していくことで、データの転送を表現す
ることが出来る。

【００３７】以下に、本発明によるバスシミュレータの
動作フローを詳細に説明する。

【００３８】図９は、本発明によるバスシミュレータの
動作を示すフローチャートである。図９には、各サイク
ルでトランザクションが処理されていく様子についての
概要を示す。バス形態としては、スプリットバス（コマ
ンドとデータとが別々に調停される構成）でバス本数が
1本の場合を例としている。なお図面左にある@cycle
n、@cycle n+1、等は、シミュレーション上でのクロッ
クサイクルを示す。

【００３９】ステップＳ１で、request(command)を、so
urce module からcommand busへ発行する。

【００４０】ステップＳ２で、request(command)をcomm
and bus 内で調停・選択し、更に選択されたrequest を
destination へ発行する。

【００４１】ステップＳ３で、request(command)を受け
取ったdestination の動作を実行する。

【００４２】ステップＳ４で、Read reply data を(当
該request に関する)destination module からbus へ発
行する。これをburst 長分繰り返す。

【００４３】ステップＳ５で、Read reply data をbus
から(当該request に関する)sourcemodule へ発行す
る。これをburst 長分繰り返す。

【００４４】ステップＳ６で、Write data を(当該requ
est に関する)source module からbus へ発行する。こ
れをburst 長分繰り返す。

【００４５】ステップＳ７で、Write data をbus から
(当該request に関する)destinationmodule へ発行す
る。これをburst 長分繰り返す。

【００４６】図１０は、図９のcycle nでのrequest(com
mand)発行モジュール（ステップＳ１）での動作フロー
を示す。この処理は、各モジュールにおいて独立に実行
されるものであり、図１０には、例えばモジュールＡで
のリクエスト発行処理をしめす。

【００４７】ステップＳ１で、bus に発行したいreques
t はあるか判定する。ＮＯならステップＳ４に進む。

【００４８】ステップＳ２で、module A 内先行の自mod
ule からのrequest がバスに残っているか（=bus 内tab
le_1 に先行request があるか）を判定する。ＹＥＳな
らステップＳ４に進む。

【００４９】ステップＳ３で、request をbus に発行す
る（=bus 内table_1 用にtransaction をenqueueす
る）。

【００５０】ステップＳ４で、本cycle でのmodule A
からのrequest 発行routine を終了する。

【００５１】図１１は、図９のcycle n+1（ステップＳ
２）でのbus内table_1（request(command)）用バス内テ
ーブルの動作フローを示す。

【００５２】ステップＳ１で、bus 内にrequest(transa
ction)があるか（=bus 内table_1にtransactionがある
か）を判定する。ＮＯであれば、ステップＳ５に進む。

【００５３】ステップＳ２で、transaction を選択す
る。

【００５４】ステップＳ３で、選択したtransaction 内
のdestination 情報を読み取る。

【００５５】ステップＳ４で、選択したtransaction を
destination module に発行（=bus内table_1からtrans
action をdequeue し、destination module 内queue_1
にtransaction をenqueue）する。

【００５６】ステップＳ５で、本cycle でのbus 内tabl
e_1 での動作routine を終了する。

【００５７】図１２は、図9のステップＳ３でのコマン
ドを受け取ったmoduleの動作を示すフローチャートであ
る。transactionがキューにあるか判定し（ステップＳ
１）、transactionを選択し（ステップＳ２）、transac
tionがReadであるかWriteであるかを判定する（ステッ
プＳ３）。Readコマンドであった場合には各モジュール
特有のRead シーケンスが起動する（ステップＳ４）。R
eadシーケンスは基本的には、モジュールや他のコマン
ドとの干渉によって決定され、あるレイテンシ後Read r
eplyデータが用意される。Writeコマンドであった場合
には、Writeシーケンスが起動される（ステップＳ
５）。Writeシーケンスは基本的には、コマンド発行元
からのWriteデータを待ち、各モジュール特有のWrite動
作を行う。

【００５８】図１３は、図１２のステップＳ４のRead
シーケンスの一部に相当し、コマンド受取側モジュール
（= data発行側モジュール）からのバスへのリードリプ
ライデータの発行フローを示す。

【００５９】Reply dataがあるかを判定し（ステップＳ
１）、ＹＥＳであれば、更にバス内に本モジュールから
の先行read reply dataがあるかを判定する（ステップ
Ｓ２）。ＹＥＳであれば処理を終了する。

【００６０】ステップＳ３で、リードデータの先頭(バ
ーストデータの先頭)がバスに発行される場合と、リー
ドデータの後続（バーストデータの後続）の場合とを判
別する。リードデータの先頭(バーストデータの先頭)を
バスに発行する場合の動作が、ステップＳ４乃至Ｓ６で
実行される。リードデータの後続（バーストデータの後
続）をバスに発行する場合の動作が、ステップＳ７及び
Ｓ８で実行される。リードデータはdata_transactionと
して図中に示されている。またバーストデータ転送を
表現するために、data_transactionのメンバとしてdata
_no_of_in_busを使用する。

【００６１】ステップＳ９で、このデータは該data_tra
nsaction の最後尾データか否かを判定する。ＮＯの場
合には、ステップＳ１１に進む。

【００６２】ステップＳ１０で、destination module
内data_queue2 から当該data_transaction をdequeue
する。

【００６３】ステップＳ１１で、本サイクルでのdestin
ation module からのread reply 動作を終了する。

【００６４】図１４は、Read dataのバス内table_2 (Re
ad data 用table)の動作フローを示す。図１４の処理
で、Read dataのバス内での調停及びデータ転送を行
う。リードデータはdata_transactionとして示される。
またバーストデータ転送を表現するために、data_trans
actionのメンバとしてdata_no_of_in_data_accept_modu
leを使用する。

【００６５】ステップＳ１で、bus 内にread reply dat
a があるか（=bus 内table_2 にdata_transaction があ
るか）を判定する。ＮＯの場合は、本cycle でのbus 内
table_2 での動作routine を終了する。

【００６６】ステップＳ２で、新規にdata_transaction
を選択できるか（すなわちread data bus 占有flag が
bus 本数未満か）を判定する。ＹＥＳならステップＳ３
に進み、ＮＯならステップＳ１０に進む。

【００６７】ステップＳ３で、（data_state[ 0] == IN
_DATA_BUS）であるdata_transaction を優先順位に従い
選択する。

【００６８】ステップＳ４で、当該data_transaction
をdata accept module に発行する（すなわち当該data_
transaction をdata accept module 内のqueue_2 にenq
ueue する）。

【００６９】ステップＳ５で、当該data_transaction
のdata_state を更新し、data_transaction->data_no_o
f_data_accept_module を１に設定する（すなわちdata_
state[ data_transaction->data_no_of_data_accept_mo
dule] =DATA_IN_ACCEPT_MODULE;data_transaction->dat
a_no_of_data_accept_module =1;とする）。

【００７０】ステップＳ６で、当該data_transaction
内の最後のdataであるか否かを判定する。ＹＥＳであれ
ば、ステップＳ７及びＳ８で、当該data_transaction
をbus内table_2 からdequeue して、read data bus 占
有flag は変更しない。ステップＳ６でＮＯであれば、
ステップＳ９において、read data bus 占有flag を＋
１する。

【００７１】ステップＳ１０で、先頭データをdata acc
ept module に発行済のdata_transaction はあるか（す
なわち data__state[ 0] ==IN_DATA_ACCEPT_MODULE で
あるdata_transaction があるか）を判定する。ＮＯの
場合は、本cycle でのbus 内table_2 での動作routine
を終了する。

【００７２】ステップＳ１１で、当該data_transaction
のdata_state を更新し、data_transaction->data_no_
of_data_accept_module を＋１する（すなわちdata_sta
te[data_transaction->data_no_of_data_accept_modul
e] =DATA_IN_ACCEPT_MODULE;++data_transaction->data
_no_of_data_accept_module;とする）。

【００７３】ステップＳ１２で、当該data_transaction
内の最後のdataであるか判定する。ＮＯの場合は、ス
テップＳ１０に戻る。ステップＳ１０では、bus 内tabl
e_2内の次のエントリについて操作を繰り返す。これら
の動作をbus 内table_2 内のエントリについて一周分行
う。

【００７４】ステップＳ１３で、当該data_transaction
をbus 内table_2 からdequeue する。

【００７５】ステップＳ１４で、read data bus 占有fl
ag を−１する。その後、処理はステップＳ１０に戻
る。ステップＳ１０では、bus 内table_2 内の次のエン
トリについて操作を繰り返す。これらの動作をbus 内ta
ble_2 内のエントリについて一周分行う。

【００７６】図１５は、図１２のステップＳ５のWrite
シーケンスの一部に相当し、Write時のコマンド発行側
モジュール（= data発行側モジュール）からのバスへの
ライトデータの発行フローを示す。

【００７７】Write dataがあるかを判定し（ステップＳ
１）、ＹＥＳであれば、更にバス内に本モジュールから
の先行write dataがあるかを判定する（ステップＳ
２）。ＹＥＳであれば処理を終了する。

【００７８】ステップＳ３で、ライトデータの先頭(バ
ーストデータの先頭)がバスに発行される場合と、ライ
トデータの後続（バーストデータの後続）の場合とを判
別する。ライトデータの先頭(バーストデータの先頭)を
バスに発行する場合の動作が、ステップＳ４乃至Ｓ６で
実行される。ライトデータの後続（バーストデータの後
続）をバスに発行する場合の動作が、ステップＳ７及び
Ｓ８で実行される。ライトデータはdata_transactionと
して図中に示されている。またバーストデータ転送を表
現するために、data_transactionのメンバとしてdata_n
o_of_in_busを使用する。

【００７９】ステップＳ９で、このデータは該data_tra
nsaction の最後尾データか否かを判定する。ＮＯの場
合には、ステップＳ１１に進む。

【００８０】ステップＳ１０で、destination module
内data_queue3 から当該data_transaction をdequeue
する。

【００８１】ステップＳ１１で、本サイクルでのsource
moduleからのwrite動作を終了する。

【００８２】図１６は、Write dataのバス内table_3 (W
rite data 用table)の動作フローを示す。この処理で、
Write dataのバス内での調停及びデータ転送を行う。ラ
イトデータはdata_transactionとして示される。またバ
ーストデータ転送を表現するために、data_transaction
のメンバとしてdata_no_of_in_data_accept_moduleを使
用する。

【００８３】ステップＳ１で、bus 内にwrite data が
あるか（=bus 内table_3 にdata_transaction がある
か）を判定する。ＮＯの場合は、本cycle でのbus 内ta
ble_3での動作routine を終了する。

【００８４】ステップＳ２で、新規にdata_transaction
を選択できるか（すなわちwrite data bus 占有flag
がbus 本数未満か）を判定する。ＹＥＳならステップＳ
３に進み、ＮＯならステップＳ１０に進む。

【００８５】ステップＳ３で、（data_state[ 0] == IN
_DATA_BUS）であるdata_transaction を優先順位に従い
選択する。

【００８６】ステップＳ４で、当該data_transaction
をdata accept module に発行する（すなわち当該data_
transaction をdata accept module 内のqueue_3 にenq
ueue する）。

【００８７】ステップＳ５で、当該data_transaction
のdata_state を更新し、data_transaction->data_no_o
f_data_accept_module を１に設定する（すなわちdata_
state[ data_transaction->data_no_of_data_accept_mo
dule] =DATA_IN_ACCEPT_MODULE;data_transaction->dat
a_no_of_data_accept_module =1;とする）。

【００８８】ステップＳ６で、当該data_transaction
内の最後のdataであるか否かを判定する。ＹＥＳであれ
ば、ステップＳ７及びＳ８で、当該data_transaction
をbus内table_3 からdequeue して、write data bus 占
有flag は変更しない。ステップＳ６でＮＯであれば、
ステップＳ９において、write data bus 占有flag を＋
１する。

【００８９】ステップＳ１０で、先頭データをdata acc
ept module に発行済のdata_transaction はあるか（す
なわち data__state[ 0] ==IN_DATA_ACCEPT_MODULE で
あるdata_transaction があるか）を判定する。ＮＯの
場合は、本cycle でのbus 内table_3 での動作routine
を終了する。

【００９０】ステップＳ１１で、当該data_transaction
のdata_state を更新し、data_transaction->data_no_
of_data_accept_module を＋１する（すなわちdata_sta
te[data_transaction->data_no_of_data_accept_modul
e] =DATA_IN_ACCEPT_MODULE;++data_transaction->data
_no_of_data_accept_module;とする）。

【００９１】ステップＳ１２で、当該data_transaction
内の最後のdataであるか判定する。ＮＯの場合は、ス
テップＳ１０に戻る。ステップＳ１０では、bus 内tabl
e_3内の次のエントリについて操作を繰り返す。この操
作はbus 内table_3 内のエントリについて一周分行う。

【００９２】ステップＳ１３で、当該data_transaction
をbus 内table_3 からdequeue する。

【００９３】ステップＳ１４で、write data bus 占有f
lag を−１する。その後、処理はステップＳ１０に戻
る。ステップＳ１０では、bus 内table_3 内の次のエン
トリについて操作を繰り返す。この操作はbus 内table_
3 内のエントリについて一周分行う。

【００９４】図９乃至１６は、あるトランザクションに
注目しその処理の流れを説明している。しかし実際の動
作においては、シミュレータはハードウェアをシミュレ
ートしているために、全てのバス内オペレーションが並
列に動作する。

【００９５】図１７は、スプリットバスの場合のシミュ
レータの構成の例を示す図である。（ａ）にはバス内各
モジュールの構成が示され、（ｂ）にはバス部の構成が
示される。各モジュール１０−１乃至１０−ｎは、ソー
スモジュール部分１１と、デスティネーションモジュー
ル部分１２を含む。ソースモジュール部分１１は、リク
エスト発行部１３、Writeデータ発行部１４、Readデー
タ受取部１５を含む。またデスティネーションモジュー
ル部分１２は、リクエスト受取部１６、Writeデータ受
取部１７、Readデータ発行部１８を含む。またバス部２
０は、リクエストテーブル２１（table_1）、リードデ
ータテーブル２２（table_2）、及びライトデータテー
ブル２３（table_3）を含む。

【００９６】各モジュールの各部分及びバス部の各部分
は関数であり、サイクル毎に並列に動作する。トランザ
クションはオブジェクトとしてバス内を移動しながら、
各部分における関数により動作する。

【００９７】図１８は、シミュレータの動作の仕方を示
す図である。

【００９８】ソフトウェアはハードウェアと異なり実際
にはシーケンシャルに記述される。従って図１８のよう
に、あるクロックサイクルにおいて各関数を逐次動作さ
せて、その後次のクロックサイクルに設定し、更に各関
数を逐次動作させるという動作を順次繰り返す。これに
よって、サイクル内（同一クロック内）での擬似的な並
列動作を実現することが出来る。

【００９９】図１９は、本発明のバスシミュレータを実
行する際の構成の一例を示す図である。

【０１００】図１９では、プロセッササイクルアキュレ
ットシミュレータ３１とキャッシュシミュレータ３２と
が、本発明によるバスシミュレータ３０に接続される。
バスシミュレータ３０から見ると、プロセッサシミュレ
ータ３１はキャッシュシミュレータ３２を介してバスシ
ミュレータ３０につながっており、キャッシュシミュレ
ータ３２がバス内モジュールの一つとなる。またバスシ
ミュレータ３０にはバス内モジュールとしてメモリコン
トローラ３３とＩＯコントローラ３４とがつながる。メ
モリコントローラ３３はその内部にメモリモデル３３ａ
を備え、その制御はハードウェアをシミュレートしたも
のである。またＩＯコントローラ３４は外部バス３５を
備える。これらの構成は、バスアーキテクチャファイル
内に記載される情報であり、各々のシミュレーション単
位で自由に変更することが可能である。図２０は、本発
明によるバスシミュレータとインプット及びアウトプッ
トを示す模式図である。

【０１０１】シミュレータ４０は、コンピュータにより
実現され、具体的にはＲＡＭに格納されたシミュレータ
プログラムをＣＰＵが実行することにより実現される。
シミュレータプログラムは、例えば、フロッピー（登録
商標）ディスク、ＣＤ−ＲＯＭ、ＣＤ、メモリカード、
或いはネットワーク上のリモートサイトに存在するスト
レージ等の記憶媒体４６によって提供される。このシミ
ュレータプログラムをコンピュータのメモリにロードし
てシミュレーションを実行する。

【０１０２】まず初期化時に、シミュレータ４０にバス
アーキテクチャ情報４４を取り込むことにより、バスの
構成及びバス内モジュールの種類と個数が設定される。
バスアーキテクチャ情報４４には、バス幅等パラメータ
系の情報も含まれている。その後シミュレータ４０の実
行開始をすると、データ部４１からはシミュレーション
対象のデータ情報、プロセッサ部４２からはシミュレー
ション対象の命令情報が与えられる。また、外部からの
ＩＯアクセスに対応するデータとして、トランザクショ
ンがＩＯアクセス情報ファイル４３から供給される。シ
ミュレータ４０による実行の結果が、実行結果ファイル
４５に出力される。実行結果ファイル４５に出力される
情報には、プロセッサの命令実行結果、実行サイクル
数、バスアクセスを生じる命令毎のバスでの遅延情報、
命令フェッチに関わるバスでの遅延情報、バス内トラン
ザクションの干渉やレイテンシ情報が含まれる。更に、
ＩＯからのトランザクションの遅延情報や、バス内のト
ランザクションの干渉情報が出力される。

【０１０３】図２１は、本発明によるバスアーキテクチ
ャファイルの一部を示す図である。

【０１０４】図２１に示されるように、バス形態情報、
バス内パラメータ（バス幅、周波数比等）、バスでのレ
イテンシ情報、バスにつながるバス内モジュールの種
類、バスにつながるバス内モジュール数等のバスに関わ
る情報が、バスアーキテクチャファイルに含まれる。シ
ミュレーション時に、このファイルの情報をシミュレー
タ内に取り込み、バス形態、パラメータ、レイテンシ、
バスにつながるバス内モジュール種、バスにつながるバ
ス内モジュール数、バス調停に関わる優先順位情報等バ
スに関わる情報を設定し、その設定情報に従ってシミュ
レータが動作する。

【０１０５】このバスアーキテクチャファイルの内容を
変更することによって、他の部分に特に修正を施すこと
なく、シミュレーション対象のバス構成やバス調停の優
先順位等を自由に変更することが出来る。

【０１０６】図２２は、本発明によるバストランザクシ
ョンを表現するデータ構造の例を示す図である。

【０１０７】図２２に示されるように、本発明によるバ
ストランザクションを表現するデータ構造には、トラン
ザクション発行元モジュールタイプ、トランザクション
発行元モジュールＩＤ、トランザクション発行先モジュ
ールタイプ、トランザクション発行先モジュールＩＤの
メンバが含まれる。また、トランザクションのデータサ
イズ、READ/WRITEの属性をあらわすメンバ、トランザク
ションの対象アドレスが設けられる。また、データ転送
をつかさどるメンバ（“rdata”及び“wdata”）のリン
クノードを有する。

【０１０８】更に、本発明によるバストランザクション
を表現するデータ構造は、バス内でのイベントがおきた
時間を記録するメンバ（event_information）を含む。
従って、ハードウェアでは個々に分離されてしまうバス
トランザクション内の動作を、一括して管理することが
できる。このイベント情報はシミュレーションを実行中
にトランザクションが進行するにつれて、リアルタイム
で更新されていく。この情報を用いればトランザクショ
ンが何時発生して、バス内の競合により滞留した時間、
発行先で消費した時間等の情報が分かる。これらの情報
を使用すれば、ボトルネックの部分の把握ができ、ハー
ドウェア構成の最適化、アプリケーションソフトウェア
の最適化が可能になる。

【０１０９】図２３は、本発明によるバスアーキテクチ
ャファイルの具体例を示す図である。このバスアーキテ
クチャファイルは、バスが一本であり、コマンドとデー
タが一体になったインターロックバスを示す。図２４
は、図２３のバスアーキテクチャファイルによって実現
されるバス構成を概念的に示す。

【０１１０】図２５は、バス構造がインターロック型で
ある場合においてバストランザクションの動作の一例を
示す図である。

【０１１１】バス内モジュールでトランザクションを発
行し（サイクル０）、バス内トランザクションテーブル
に発行されたトランザクションをリンクする（サイクル
１）。バス内トランザクションテーブルからトランザク
ションを選択し、そのトランザクションを発行先に渡す
（サイクル２）。そのトランザクションと同時又は一定
レイテンシ後（これらの設定はパラメータで規定され
る）に、データ転送を表現するメンバ(データトランザ
クション)を発行元から発行先に渡す（サイクル３）。
その後サイクルが進むごとにメンバ内の転送データの状
態を、「データ発行元にある」状態から、「バス内にあ
る」状態、更に「データ発行先にある」状態に遷移させ
ていくことで、データ転送を表現する。最後のデータま
で転送完了状態になったら、再びトランザクションをリ
ンクしているテーブルから次のトランザクションを選択
し、データ転送を開始する。

【０１１２】図２６は、本発明によるバスアーキテクチ
ャファイルの別の具体例を示す図である。このバスアー
キテクチャファイルは、バスが一本であり、コマンドと
データとを独立に動作させるスプリットバスに相当す
る。データに関しては、read/writeが共通バスである構
成となっている。図２７は、図２６のバスアーキテクチ
ャファイルによって実現されるバス構成を概念的に示
す。図２８（ａ）は、図２６のバスアーキテクチャファ
イルによって実現されるバストランザクション動作を示
し、コマンド系の動作に相当する。図２８（ｂ）は、図
２６のバスアーキテクチャファイルによって実現される
データトランザクション動作を示し、データ系の動作に
相当する。

【０１１３】上記の構成では、データ転送に関して、ト
ランザクション内の転送データを表現するデータ構造を
有するメンバ（データトランザクション）をリンクでき
るテーブルをバス部に設け、そのテーブルをリードデー
タ及びライトデータで共用する。

【０１１４】図２９は、バス構造がスプリット型である
場合においてバストランザクションの動作の一例を示す
図である。

【０１１５】コマンド系のトランザクションを管理する
テーブルとは別に、データ転送に関して、トランザクシ
ョン内の転送データを表現するデータ構造を有するメン
バ（データトランザクション）をリンクできるテーブル
をバス部に設ける。また、データ選択用の優先順位を記
載したテーブルも別途設ける。この形態で、トランザク
ションがバス内モジュールからバスへ発行されると、そ
のトランザクションは、バスへ発行されたトランザクシ
ョンをリンクするテーブルに入れられる。そのテーブル
から優先順位テーブル内の優先順位にしたがいトランザ
クションを選択し、選択したトランザクションを発行先
に渡す。このとき受取先ではコマンドのリクエストが来
たと解釈する。このときデータの転送は起動されない。

【０１１６】上記選択されたトランザクションが発行先
に渡ったあと、データ発行元（ライトならトランザクシ
ョン発行元、リードならトランザクション発行先）か
ら、データトランザクションを上記データトランザクシ
ョン用のバス内テーブルに発行する（サイクル１）。こ
のときこのデータトランザクションの先頭データを表す
フィールドのデータの状態は「データ発行元にある」状
態から「バス内にある」状態に遷移する。データトラン
ザクション用のバス内テーブルから、トランザクション
の場合と同様に、別途用意した優先順位テーブルに記載
された優先順位に従い、データトランザクションを表現
するデータ構造を選択し、データ発行先に渡す（サイク
ル２）。このとき先頭データの状態は「バス内にある」
状態から「データ発行先」にある状態に遷移する。も
し、このデータトランザクションが後続のデータ転送を
伴っている場合には直後のデータから順番に「バス内に
ある」状態から「データ発行先にある」状態にサイクル
を追うごとに遷移していき、後続データ転送を行う。最
後のデータまで転送完了状態になったら、再びバスから
発行されたトランザクションをリンクしているテーブル
から次のトランザクションを選択し、データ転送を開始
する。

【０１１７】図３０は、本発明によるバスアーキテクチ
ャファイルの一例を示す図である。このバスアーキテク
チャファイルは、バスが１本（１セット：コマンドバ
ス、リードデータバス、ライトデータバス）であり、コ
マンドとデータを独立に動作させるスプリットバスに相
当する。データに関してはread/write夫々が、独立のバ
スである構成となっている。図３１は、図３０のバスア
ーキテクチャファイルによって実現されるバス構成を概
念的に示す。図３２（ａ）は、図３１のバスアーキテク
チャファイルによって実現されるバストランザクション
動作を示し、コマンド系の動作に相当する。図３２
（ｂ）は、図３１のバスアーキテクチャファイルによっ
て実現されるデータトランザクション動作を示し、リー
ドデータ系の動作に相当する。更に図３２（ｃ）は、図
３１のバスアーキテクチャファイルによって実現される
データトランザクション動作を示し、ライトデータ系の
動作に相当する。

【０１１８】上記構成では、データ転送に関して、トラ
ンザクション内の転送データを表現するデータ構造を有
するメンバ（データトランザクション）をリンクできる
テーブルをバス部に設け、そのテーブルをリードデータ
用とライトデータ用とに別々に用意し、更に、データト
ランザクションの選択用の優先順位テーブルもリードデ
ータ用とライトデータ用とで別々に設ける。リードデー
タに関しては、リードデータトランザクションのテーブ
ルから、リードデータ用の優先順位テーブルに記載され
る優先順位に従って選択する。ライトデータに関して
は、ライトデータトランザクションのテーブルから、ラ
イトデータ用の優先順位テーブルに記載される優先順位
に従って選択する。

【０１１９】図３３及び図３４は、本発明によるバスア
ーキテクチャファイルの一例を示す図である。このバス
アーキテクチャファイルは、バスの形態がクロスバーで
あり、且つスプリットバスでリード/ライトが独立動作
する構成である。図３５は、図３３及び３４のバスアー
キテクチャファイルによって実現されるバス構成を概念
的に示す。図３５に示されるように、バスには、４つの
メモリコントローラと一つのＩＯが接続される。更にＩ
キャッシュとＤキャッシュとがバスに接続される。プロ
セッサは、このキャッシュを介してバスとやり取りをす
る。この場合、コマンド系、リードデータ系、及びライ
トデータ系のトランザクション動作は、全て図６に示さ
れるトランザクションの流れと同様である。

【０１２０】図３６は、本発明によるバスアーキテクチ
ャファイルの一例を示す図である。このバスアーキテク
チャファイルは、バスが２本（２セット：コマンドバス
ｘ２、リードデータバスｘ２、ライトデータバスｘ２）
であり、コマンドとデータを独立に動作させるスプリッ
トバスに相当する。データに関してはread/write夫々
が、独立のバスである構成となっている。またマルチプ
ロセッサであり２次キャッシュが設けられる構成となっ
ている。図３７は、図３６のバスアーキテクチャファイ
ルによって実現されるバス構成を概念的に示す。バスに
は２つのプロセッサと一つの２次キャッシュが接続さ
れ、更に、メモリコントローラとＩＯとが一つづつ接続
される。図３８（ａ）は、図３６のバスアーキテクチャ
ファイルによって実現されるバストランザクション動作
を示し、コマンド系の動作に相当する。図３８（ｂ）
は、図３６のバスアーキテクチャファイルによって実現
されるデータトランザクション動作を示し、リードデー
タ系の動作に相当する。更に図３８（ｃ）は、図３６の
バスアーキテクチャファイルによって実現されるデータ
トランザクション動作を示し、ライトデータ系の動作に
相当する。

【０１２１】以下に、本発明の第２の実施例を説明す
る。

【０１２２】図３９は、本発明の第２の実施例によるト
ランザクションのデータ構造の一部を示す。

【０１２３】当該データ構造には、トランザクション発
行元モジュールタイプ、トランザクション発行元モジュ
ールＩＤ、トランザクション発行先モジュールタイプ、
トランザクション発行先モジュールＩＤのメンバが含ま
れる。また、トランザクションのデータサイズ、READ/W
RITEの属性をあらわすメンバ、及びトランザクションの
対象アドレスが設けられる。更に、データ転送をつかさ
どるメンバ“rdata”“wdata”のリンクノードを有す
る。また、このトランザクションに関連するトランザク
ションを示すリンクノード prev_relation及びnext_rel
ationが設けられ、このノードを使用することで、関連
するトランザクション同士はlist構造を構成するように
リンクされる。このリンクノードを辿れば、お互いに関
係するトランザクションを知ることができる。また更
に、トランザクションＩＤメンバが設けられ、トランザ
クションの発生順に順次ＩＤがアサインされる。これに
よって、一連のトランザクションを発生順にトレースす
ることができる。

【０１２４】互いに関連するトランザクションとして
は、例えば、ＤＭＡ転送が複数のトランザクションに分
割される場合の各トランザクションが考えられる。例え
ば、図４０のようなバス構成で、ＤＭＡコントローラ１
００によってＤＭＡ転送する場合を想定する。適切な形
にアーキテクチャファイルを記述することで、図４０の
バス構成を実現することができる。

【０１２５】図４０において、バス１１０にはＩキャッ
シュ１０１及びＤキャッシュ１０２が接続され、これら
のキャッシュ経由でプロセッサ１０３がバス１１０に接
続される。バス１１０には更に、メモリコントローラ１
０４、ＩＯユニット１０５、及びDMAコントローラ１０
０が接続される。

【０１２６】図４０の構成において、プロセッサ１０３
がＤＭＡコントローラ１００内のＤＭＡレジスタを設定
すると、ＤＭＡが起動する。例えば、２５６バイトのデ
ータをメモリコントローラ１０４に繋がるＤＲＡＭから
リードし、ＩＯユニット１０５に出力するためにＤＭＡ
を起動する。ここで、この場合のバス構成では、最大転
送サイズが６４バイトであると想定する。

【０１２７】図４１は、ＤＭＡオペレーションの処理の
流れを示す図である。ＤＭＡコントローラ１００は、２
５６バイトのアクセスを４つのアクセスに分割する。ト
ランザクションとしては８個に分割される。ＣＰＵ１０
３がＤＭＡ起動をリクエストすると（ステップＳ１）、
ＤＭＡコントローラ１００がメモリコントローラ１０４
を介して６４バイトをＤＲＡＭから読み出し（ステップ
Ｓ２：トランザクション１）、読み出した６４バイトデ
ータをＩＯユニット１０５にライトする（ステップＳ
３：トランザクション２）。この動作を４回繰り返すこ
とで、２５６バイトのアクセスを４つのアクセスに分割
して実行する。

【０１２８】図４２は、トランザクションのリンク及び
ＩＤ割り当ての様子を示す。図４２に示されるように、
トランザクションは発生した順にリンクさせ、その順番
にＩＤが割り当てられる。このようなリンク構造を使用
することで、ＤＭＡ動作が開始されてから終わるまでの
一連の動作をトレースすることができる。実際にはこの
ＤＭＡ動作の間に他のバスアクセスが入ってくるため
に、単純に８回連続するわけではない。従って、このよ
うに関連するトランザクションを一括して管理できる方
法が提供されていないと、上記8個のトランザクション
は独立した別個のものとして扱われ、トレースすること
ができないことになる。

【０１２９】なお上記本発明の説明において、データ構
造はC言語でインプリメントされているが、言語はこれ
に限定されるものではない。

【０１３０】以上、本発明を実施例に基づいて説明した
が、本発明は上記実施例に限定されるものではなく、特
許請求の範囲に記載の範囲内で様々な変形が可能であ
る。

【０１３１】

【発明の効果】本発明は、バスの動作をハードウェアに
即して容易にかつ忠実に表現する手段を提供する。従っ
て、バスの構成に関わらず高いサイクル精度のシミュレ
ーション結果が得られる。またバスの形態やパラメータ
をシミュレーション実行単位で容易に変更することが可
能な手段を提供する。

【０１３２】またハードウェアとは独立してトランザク
ション単位でデータ管理をすることで、リクエスト・グ
ラント論理以外の例えばビジー制御に基づいたバス構成
等の実現が容易であるだけでなく、シミュレーション実
行後のボトルネックの解析や、これを用いたアーキテク
チャ、アプリケーションソフトウェアの最適化が可能と
なる。

【図面の簡単な説明】

【図１】トランザクションを表現するデータ構造の一部
を示す図である。

【図２】図１のデータ構造を用いたバストランザクショ
ンの概念を示す図である

【図３】優勢順位テーブルの構成例を示す図である。

【図４】１本のバスで構成される場合のバストランザク
ション選択を示す図である。

【図５】複数のバスで構成される場合のバストランザク
ション選択を示す図である。

【図６】クロスバー構成のバスの場合についてバストラ
ンザクション選択を示す図である。

【図７】転送データの状態を表現するデータ構造のメン
バを有するトランザクションのデータ構造を示す図であ
る。

【図８】図７のデータ構造を用いた場合のデータのバス
転送を示す図である。

【図９】本発明によるバスシミュレータの動作を示すフ
ローチャートである。

【図１０】図９のcycle nでのrequest発行モジュールで
の動作フローを示す図である。

【図１１】図９のcycle n+1でのバス内テーブルの動作
フローを示す図である。

【図１２】図9のステップＳ３でのコマンドを受け取っ
たmoduleの動作を示すフローチャートである。

【図１３】図１２のステップＳ４のRead シーケンスの
一部に相当し、コマンド受取側モジュールからのバスへ
のリードリプライデータの発行フローを示す図である。

【図１４】Read dataのバス内table_2の動作フローを示
す図である。

【図１５】図１２のステップＳ５のWrite シーケンスの
一部に相当し、Write時のコマンド発行側モジュールか
らのバスへのライトデータの発行フローを示す図であ
る。

【図１６】Write dataのバス内table_3の動作フローを
示す図である。

【図１７】スプリットバスの場合のシミュレータの構成
の例を示す図である。

【図１８】シミュレータの動作の仕方を示す図である。

【図１９】本発明のバスシミュレータを実行する際の構
成の一例を示す図である。

【図２０】本発明によるバスシミュレータとインプット
及びアウトプットを示す模式図である。

【図２１】本発明によるバスアーキテクチャファイルの
一部を示す図である。

【図２２】本発明によるバストランザクションを表現す
るデータ構造の例を示す図である。

【図２３】本発明によるバスアーキテクチャファイルの
具体例を示す図である。

【図２４】図２３のバスアーキテクチャファイルによっ
て実現されるバス構成を概念的に示す図である。

【図２５】バス構造がインターロック型である場合にお
いてバストランザクションの動作の一例を示す図であ
る。

【図２６】本発明によるバスアーキテクチャファイルの
別の具体例を示す図である。

【図２７】図２６のバスアーキテクチャファイルによっ
て実現されるバス構成を概念的に示す図である。

【図２８】（ａ）は、図２６のバスアーキテクチャファ
イルによって実現されるバストランザクション動作を示
し、（ｂ）は、図２６のバスアーキテクチャファイルに
よって実現されるデータトランザクション動作を示す図
である。

【図２９】バス構造がスプリット型である場合において
バストランザクションの動作の一例を示す図である。

【図３０】本発明によるバスアーキテクチャファイルの
一例を示す図である。

【図３１】図３０のバスアーキテクチャファイルによっ
て実現されるバス構成を概念的に示す図である。

【図３２】（ａ）は、図３１のバスアーキテクチャファ
イルによって実現されるバストランザクション動作を示
し、（ｂ）は、図３１のバスアーキテクチャファイルに
よって実現されるリードデータトランザクション動作を
示し、（ｃ）は、図３１のバスアーキテクチャファイル
によって実現されるライトデータトランザクション動作
を示す図である。

【図３３】本発明によるバスアーキテクチャファイルの
一例を示す図である。

【図３４】本発明によるバスアーキテクチャファイルの
一例を示す図である。

【図３５】図３３及び３４のバスアーキテクチャファイ
ルによって実現されるバス構成を概念的に示す図であ
る。

【図３６】本発明によるバスアーキテクチャファイルの
一例を示す図である。

【図３７】図３６のバスアーキテクチャファイルによっ
て実現されるバス構成を概念的に示す図である。

【図３８】（ａ）は、図３６のバスアーキテクチャファ
イルによって実現されるバストランザクション動作を示
し、（ｂ）は、図３６のバスアーキテクチャファイルに
よって実現されるリードデータトランザクション動作を
示し、（ｃ）は、図３６のバスアーキテクチャファイル
によって実現されるライトデータトランザクション動作
を示す図である。

【図３９】本発明の第２の実施例によるトランザクショ
ンのデータ構造の一部を示す図である。

【図４０】ＤＭＡコントローラが設けられるバス構造の
一例を示す図である。

【図４１】ＤＭＡオペレーションの処理の流れを示す図
である。

【図４２】トランザクションのリンク及びＩＤ割り当て
の様子を示す図である。

【符号の説明】

１１ソースモジュール部分１２デスティネーションモジュール１３リクエスト発行部１４ Writeデータ発行部１５ Readデータ受取部１６リクエスト受取部１７ Writeデータ受取部１８ Readデータ発行部２０バス部２１リクエストテーブル２２リードデータテーブル２３ライトデータテーブル

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5B046 AA07 JA04 5B083 AA08 CC11 EE11 EE12

Claims

【特許請求の範囲】

【請求項１】バスへのバストランザクションの発行及び
該バスからのバストランザクションの受信の少なくとも
一方を実行するモジュールと、該バスに発行された該バストランザクションを記録する
テーブルを含み該テーブルからバストランザクションを
選択することでバス調停を実行し該選択されたバストラ
ンザクションを発行先モジュールに転送するバス部を含
み、該バストランザクションを表現するデータ構造は該
バストランザクション間で共通の項目を含み、該共通項
目は少なくとも発行元モジュールを識別する項目及び発
行先モジュールを識別する項目を含むことを特徴とする
バスシミュレータ。
【請求項２】該バス部は該テーブルからバストランザク
ションを選択する優先順位を定義する優先順位テーブル
を含み、該優先順位テーブルを初期化時に設定すると共
に必要に応じて該優先順位テーブル内の優先順位を動的
に切り替えることを特徴とする請求項１記載のバスシミ
ュレータ。
【請求項３】該バス部は該テーブルから同時に選択する
バストランザクションの数によって該バスの本数を表現
することを特徴とする請求項１記載のバスシミュレー
タ。
【請求項４】該バス部は、該テーブル内に記録される該
バストランザクションを発行先毎に複数のグループに分
け、発行先毎に指定される優先順位に従い該複数のグル
ープの各々から一つのバストランザクションを選択する
ことを特徴とする請求項１記載のバスシミュレータ。
【請求項５】該共通の項目は転送データの状態を表現す
る項目を更に含み、該転送データの状態を表現する項目
は転送データ個数分だけのフィールドを含み、各フィー
ルドは「データ発行元にある」状態、「バス内にある」
状態、及び「データ発行先にある」状態のいずれかの状
態を持ち、該状態を遷移させることにより各データを転
送することを特徴とする請求項１記載のバスシミュレー
タ。
【請求項６】該テーブルからバストランザクションを選
択することで該転送データの転送を開始することを特徴
とする請求項５記載のバスシミュレータ。
【請求項７】データ転送元モジュールは該転送データの
状態を表現する項目を該バス部に発行し、該バス部は該
バス部に発行された該転送データの状態を表現する項目
を記録するデータトランザクションテーブルを含み、該
データトランザクションテーブルから該転送データの状
態を表現する項目を選択することで転送データの調停を
実行することを特徴とする請求項５記載のバスシミュレ
ータ。
【請求項８】該データトランザクションテーブルがデー
タ読み出し及びデータ書き込み間で同一であるか或いは
別々であるかによって異なったバス構成を表現すること
を特徴とする請求項７記載のバスシミュレータ。
【請求項９】該データ構造は、バス内でのイベントが起
きた時間を記録する項目を更に含むことを特徴とする請
求項１記載のバスシミュレータ。
【請求項１０】該データ構造は関連する他のバストラン
ザクションを示すリンクを含み、該リンクを介して関連
する複数のトランザクション同士をlist構造に連結する
ことを特徴とする請求項１記載のバスシミュレータ。