(57)【要約】【課題】  システム記述言語により高速にシミュレーションを行える装置において、シミュレーション速度を低下させることなく検証を容易に行う。【解決手段】  システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーション装置であって、トランザクションに、ハードウェアにマッピングするアトリビュート情報であるか否かを示す情報と、ハードウェアにマッピングしないアトリビュート情報とを有する。【選択図】      図７
2006079369.tif 000002
【特許請求の範囲】
【請求項１】
システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーション装置であって、
前記トランザクションに、ハードウェアにマッピングするアトリビュート情報であるか否かを示す情報と、
ハードウェアにマッピングしないアトリビュート情報とを有することを特徴とするシミュレーション装置。
【請求項２】
前記ハードウェアにマッピングしないアトリビュート情報を生成する生成手段を有することを特徴とする請求項１記載のシミュレーション装置。
【請求項３】
前記ハードウェアにマッピングしないアトリビュート情報を利用する利用手段を有することを特徴とする請求項１記載のシミュレーション装置。
【請求項４】
前記ハードウェアにマッピングしないアトリビュート情報に、少なくとも装置の名称及びトランザクション発行時刻を含むことを特徴とする請求項１記載のシミュレーション装置。
【請求項５】
前記ハードウェアにマッピングしないアトリビュート情報に、シミュレーション時間を含むことを特徴とする請求項１記載のシミュレーション装置。
【請求項６】
前記シミュレーション時間として、前記トランザクションを送受信するバスに接続する機能モジュールが他の機能モジュールから処理を依頼された時の時間を含むことを特徴とする請求項５記載のシミュレーション装置。
【請求項７】
前記シミュレーション時間として、前記トランザクションを送受信するバスに接続する機能モジュールが他の機能モジュールから依頼された処理を完了した時の時間を含むことを特徴とする請求項５記載のシミュレーション装置。
【請求項８】
前記シミュレーション時間は、遅延を生じる外部要因がない場合に前記処理を完了した時の時間であることを特徴とする請求項７記載のシミュレーション装置。
【請求項９】
システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーション装置の履歴生成方法であって、
前記トランザクションを受信する工程と、
受信したトランザクションからハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを読み出す工程と、
読み出した各アトリビュート情報に基づいてシミュレーションの履歴データを生成する工程とを有することを特徴とするシミュレーション装置の履歴生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、論理回路から構成されるハードウェアシステムを、システム記述言語により高速シミュレーション可能なモデルとして高い抽象度で記述されたシミュレーション装置に関するものである。
【背景技術】
【０００２】
プロセス技術の進歩によりＬＳＩの集積度が増大し、これまではボードで実現していたシステムをシステムＬＳＩとして１チップ上に搭載することが可能となっている。また、チップ上に搭載する機能モジュールも多様化し、回路規模も増大している。これに伴い、システムＬＳＩを効率的に設計するための手法として、従来のVerilog-HDLやVHDLといったハードウェア記述言語を使用した設計から、SystemCやSpecCといったシステム記述言語による設計が普及してきている。
【０００３】
システム記述言語による設計支援ツールとしては、Synopsys社のCoCentricやCoWare社のConvergenSCが知られている。そして、システム記述言語により記述したモジュールをブロック図入力画面で入力し、システムＬＳＩの設計を行うことが可能になっている。
【０００４】
このシステムＬＳＩの設計が終了すると、設計支援ツールからシミュレーションモデルを生成し、シミュレータを起動してシステムシミュレーションを行い、設計したシステムＬＳＩの機能や性能を確認することができる。即ち、実際のハードウェアを作成する前に、シミュレーションによりシステムの評価を行うことにより、仕様の不具合や性能不足を回避している。
【０００５】
上述のシステム記述言語によるモジュール記述には、記述の抽象度により以下の３種類の記述レベルが一般に知られている。
【０００６】
トランザクションレベル（TL）：
モジュール間のバス通信を捉えて機能を記述する抽象度レベルである。通信の開始及び終了の時間、通信データにより動作するため、クロックに対する精度は低い。イベントにより機能をシミュレートするため、シミュレーション速度は非常に速い。システムとしての動作が実際のハードウェアと一致するため、システム全体の評価に適している。
【０００７】
ARM社による定義では、更に細かく分類されておりPV（プログラマーズビュー）、PVT（プログラマーズビュー＋タイミング）、CL（サイクルレベル）に相当する。
【０００８】
バスサイクルアキュレート（BCA）：
モジュールの入力及び出力のイベントとして機能を記述する抽象度レベルである。動作クロックに対して、入力及び出力部で正確にシミュレートすることができる。
【０００９】
ARM社による定義では、CC（サイクルコーラブル）に相当する。
【００１０】
レジスタトランスファレベル（RTL）：
レジスタファイル間の同期転送を捉えて回路を記述する抽象度レベルである。動作クロックに対して、正確に機能動作をシミュレートすることができ、精度が非常に高い。１クロック毎に機能をシミュレートするため、シミュレーション速度は非常に遅い。
【００１１】
ARM社による定義ではRT（RTLイベントドリブン）に相当する。
【００１２】
一般的に、抽象度が高いほどシミュレーション速度は速くなり、また抽象度が低いほどシミュレーション精度は高くなる。
【００１３】
システムのシミュレーションを行うためのシミュレーションモデルは、トランザクションレベルにより記述される。
【００１４】
トランザクションレベルによるシミュレーションモデルとして、ARM社により公開されているAMBAバスモデルが広く知られている（AMBA AHB Cycle Level Interface (AHB CLI) Specification, 2003年7月15日公開）。
【００１５】
図１は、AHB CLIで定義されているバストランザクションを示す図である。図１に示すトランザクションメソッドは、AMBA AHBバスプロトコルで規定されたハードウェア信号に対応させることができる。図２は、トランザクションメソッド、アトリビュート、ハードウェアの対応を示す図である。図２に示すように、アトリビュート及びメソッド自身が、少なくとも１つのハードウェア信号に対応している。これらのメソッドを使用してバスの動作をシミュレーションすることが可能である。
【００１６】
図３、図４を用いてバスの動作をシミュレーションする方法を説明する。図３は、トランザクションメソッドと信号波形の対応を示す図である。図４は、トランザクションメソッドを用いたシミュレーションを説明するための図である。
【００１７】
時刻Ｔ１において、バスマスター１がバスへのリクエスト要求を行う。このとき、バスマスター１はrequest()メソッドを呼び出し、バスに対して発行する。これはHBUSREQ_M1信号のアサートに相当する。また、バスはアービターに対してアービトレーションを開始させる（arbitrate()）。また、バスからマスターに対してresponse()[OKAY,READY]メソッドが発行される。これはHREADY及びHRESP信号に相当する。
【００１８】
時刻Ｔ２において、マスター２がバスへのリクエスト要求を行う（request()）。これはHBUSREQ_M2信号のアサートに相当する。同時に、バスからマスター１に対してグラントが与えられる（arbitrate()[grant M1]）。これはHGRANT_M1のアサートに相当する。
【００１９】
時刻Ｔ３において、マスター１はグラントを検知（has_grant()[TRUE]）し、バスへのリクエストを取り下げる（end_request()）。これはHBUSREQ_M1信号のデアサートに相当する。また、トランザクションを開始する（set_protection()、init_transaction()）。これらはHPROTO、HTRANS、HADDR、HBURST、HWRITE、HSIZEといった信号に相当する。また同時に、バスはアドレスデコードを行い、スレーブに対してトランザクションを発行する（write()[address A1]、control_info[NONSEQ,INCR4]）。
【００２０】
時刻Ｔ４からＴ７でマスター１は、バスに対してデータを送る（set_data()）。これはHWDATA信号に相当する。そして、バスは、スレーブに対してマスターからのデータを送付する（set_data()）。
【００２１】
時刻Ｔ６でバスはマスター２に対してグラントを与える（arbitrate()[grant M2]）。時刻Ｔ７でマスター２はグラントを検知し、バスアクセスを開始する。
【００２２】
このように、各トランザクションメソッドは、ハードウェア信号の挙動と同じ機能を有しており、メソッド及びアトリビュートはハードウェア信号にマッピングできるものであることがわかる。
【００２３】
AHB CLIでは、トランザクションメソッドの他にバスのコンフィギュレーションを変更するためのメソッドが用意されている。このメソッドにより、バスのアドレス幅、データ幅、アドレスマップを変更することが可能である。
【００２４】
図５は、ハードウェアコンフィギュレーションメソッドを示す図である。図５に示すようにシミュレータがシステムモデルを読み出すエラボレーション時に実行されるメソッドと、シミュレーション実行時に使用することができるメソッドとに分けられる。ここで、シミュレーション実行を行いながら、バスのコンフィギュレーションを変更するメソッドは、デコーダのinitialize_map()及びアービターのpriority()、set_default_master()である。
【００２５】
これらは、実際のハードウェアの動作に関係しており、initialize_map()はremap信号に相当し、priority()、set_dafulat_maste()はアービター内のレジスタアクセス信号に相当する。
【００２６】
また、AHB CLIには、検証目的で使用するメソッドが用意されている。ハードウェアの検証に一般的に使用されているバックドア機能に対応するメソッドである。バスのプロトコルとは無関係に、指定したアドレスのデータを直接読書きすることが可能である。
【００２７】
図６は、検証メソッドを示す図である。マスターが使用する引数はアドレス、データへのポインタ、転送サイズの３つであり、ハードウェアと関連したものである。スレーブが使用する引数は、マスターＩＤ、アドレス、データへのポインタ、転送サイズの４つであり、これらもハードウェアと関連したものである。
【非特許文献１】AMBA AHB Cycle Level Interface (AHB CLI) Specification, 2003年7月15日公開
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかしながら、上記従来の技術では、システムや各モジュールの検証を行うために、各トランザクションを監視するためのモニタを別途作成する必要があった。一般的に、より低い抽象度であるRTLにおいても、検証用にモニタを作成する必要があり、モニタ開発が二度手間になるという問題があった。
【００２９】
また、一般的に、モニタはそれ自体が一つのモジュールとして実装されるが、モニタの対象とする情報の解析に機能モジュールのみが保持している情報を必要とする場合がある。例えば、バスモデルは内部にアドレスデコーダの機能が含まれるが、アドレスマップの情報は外側からトランザクションを観測しても取得することはできない。このような場合には、機能モジュールとモニタとの間で情報の共有を必要とし、このようなモニタを実装することは非常に手間がかかる。
【００３０】
また、トランザクションレベルでは、各モジュールのメソッドと呼ばれる関数を呼び出すことにより行われるため、容易にモニタを作成することはできなかった。AHB CLIでは、モニタのためのメソッドが用意されているが、モニタ用のメソッドが用意されていないことが殆どである。
【００３１】
また、AHB CLIにあるように検証用のメソッドが定義されていることもあるが、実際のハードウェア動作のシミュレーションを実行している間に、シミュレーション結果に影響を及ぼさないように、メソッドを呼び出す必要があり、これらのメソッドを使用して検証を行うのは手間がかかるものであった。
【００３２】
また、メソッドを多用して検証を行うことは、シミュレーション時のイベントの増加を招き、シミュレーション速度への影響が大きくなり、結果としてシミュレーション速度を低下させるものであった。
【００３３】
一方、システムや各モジュールの検証にメソッドを使わない方法として、各モジュールのトランザクション情報を波形としてダンプし、その波形を観測する方法が知られているが、システムの膨大なシミュレーション結果を波形により検証していくのはほぼ不可能に近い状況であった。また、波形情報をファイルに保持していくためには、膨大なディスク容量を必要とし、充分な時間シミュレーションを実行させることが困難であるという問題もあった。
【００３４】
更に、性能解析においては各機能モジュールでの処理で消費されるレイテンシを単純に比較することは従来から行われてきたが、それではレイテンシが他機能モジュールとの競合による余計なものなのか、その機能モジュールが最低限必要としているものなのかが不明なため、設計者が性能解析し、システム構成及び処理シーケンスの最適化を行う情報としては不十分であった。
【００３５】
近年のシステムＬＤＩの大規模化、高機能化により、システム内部に存在する機能モジュール数、バスの本数は増大している。このような複雑なシステムを性能解析及び検証していくのには、上で挙げた従来の手法では非常に困難である。
【００３６】
本発明は、システム記述言語により高速にシミュレーションを行える装置において、シミュレーション速度を低下させることなく検証を容易に行うことを目的とする。
【００３７】
また、本発明は、トランザクションレベルのシミュレーションにおいて、大規模、且つ複雑なシステムに対応でき、性能解析及び検証を容易に行うことを目的とする。
【課題を解決するための手段】
【００３８】
本発明は、システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーション装置であって、前記トランザクションに、ハードウェアにマッピングするアトリビュート情報であるか否かを示す情報と、ハードウェアにマッピングしないアトリビュート情報とを有することを特徴とする。
【００３９】
また、本発明は、システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーション装置の履歴生成方法であって、前記トランザクションを受信する工程と、受信したトランザクションからハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを読み出す工程と、読み出した各アトリビュート情報に基づいてシミュレーションの履歴データを生成する工程とを有することを特徴とする。
【発明の効果】
【００４０】
本発明によれば、システム記述言語により高速にシミュレーションを行える装置において、シミュレーション速度を低下させることなく検証を容易に行うことができる。
【発明を実施するための最良の形態】
【００４１】
以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。
【実施例１】
【００４２】
実施例１では、トランザクションを送信するマスタやスレーブである機能モジュールがトランザクションに、ハードウェアにマッピングされないアトリビュート情報として付加情報を設定し、トランザクションを中継するバスが付加情報に基づいてシミュレーションの履歴を生成するものである。
【００４３】
図７は、実施例１におけるシミュレーションモデルで使用するトランザクションの構成の一例を示す図である。図７において、７００はアドレストランザクションであり、バスにより通信され、マスタもしくはバスからスレーブに対するアクセス要求に相当するトランザクションである。このアドレストランザクション７００において、７０１〜７０３はハードウェアであるバス信号にマッピングされないアトリビュート情報であり、実施例１では以下の情報が保持される。
【００４４】
即ち、トランザクションが発行された時刻であるトランザクション発行時刻７０１と、トランザクションを発行するモデル名称であるトランザクション発行元モデル名称７０２と、トランザクションの発行先のモデル名称であるトランザクション発行先モデル名称７０３が保持される。
【００４５】
７０４〜７０７はハードウェアであるバス信号にマッピングされるアトリビュート情報である。アトリビュート情報７０４〜７０７はバスのプロトコルに依存するものであり、バスの種類によってアドレストランザクション７００に含まれるアトリビュート情報も異なってくる。
【００４６】
７０９はハードウェアマッピングフラグであり、アトリビュート情報７０１〜７０７がハードウェアであるバス信号にマッピングされるか否かを示すフラグである。実施例１では、ハードウェアマッピングフラグ７０９において、黒丸で示されるものがハードウェアにマッピングされることを、黒丸が無いものがハードウェアにマッピングされないことを示している。
【００４７】
７１０はリードデータトランザクションであり、バスにより通信され、マスタもしくはバスからのリードアクセス要求に対するリードデータに相当するトランザクションである。このリードデータトランザクション７１０において、７１１〜７１３は上述した７０１〜７０３に対応するアトリビュート情報である。７１４はハードウェアであるバス信号にマッピングされるアトリビュート情報である。７１９は上述した７０９に対応するハードウェアマッピングフラグである。
【００４８】
図８は、実施例１におけるシミュレーションモデルのシステム構成の一例を示す図である。図８において、８０１はクロック生成器であり、システムの各機能モジュール（後述する第１のマスタ、第２のマスタ、第１のスレーブ、第２のスレーブ）に対してクロックを供給する。
【００４９】
８０２は第１のマスタであり、バスに対してトランザクションを発行し、スレーブからのトランザクションを受信する。８０３は第２のマスタであり、バスに対してトランザクションを発行し、スレーブからのトランザクションを受信する。
【００５０】
８０４は第１のスレーブであり、バスからのトランザクションを受信し、リードに相当するトランザクションに対してはリードデータに相当するトランザクションを発行する。８０５は第２のスレーブであり、バスからのトランザクションを受信し、リードに相当するトランザクションに対してはリードデータに相当するトランザクションを発行する。
【００５１】
８０６はバスであり、第１のマスタ８０２又は第２のマスタ８０３からのトランザクションを受信し、バスのアービトレーション、アドレスデコードを行い、アービトレーションにより選択された第１のマスタ８０２又は第２のマスタ８０３のトランザクションを、第１のスレーブ８０４又は第２のスレーブ８０５に対して中継する。
【００５２】
８０７はトランザクションにより通信を行うポートである。第１のマスタ８０２、第２のマスタ８０３、第１のスレーブ８０４、第２のスレーブ８０５及びバス８０６にそれぞれ存在する。そして、８０８は信号ポートであり、クロック生成器８０１からのクロックを受信するポートである。
【００５３】
図９は、バス８０６におけるトランザクション履歴９０１である。バス８０６を介して通信されるトランザクションの履歴情報である。
【００５４】
［データの書き込み］
以上の構成において、図１０及び図１１を用いて第１のマスタ８０２が第１のスレーブ８０４へデータの書き込みを行う場合の処理について説明する。
【００５５】
図１０は、実施例１における第１のマスタの処理を示すフローチャートである。また、図１１は、実施例１におけるバスの処理を示すフローチャートである。
【００５６】
シミュレーションが開始されると、ステップＳ１００１において、第１のマスタ８０２がバス８０６に対してトランザクションを発行できる状態であればステップＳ１００２へ進み、アドレストランザクション７００の発行を開始する。
【００５７】
このステップＳ１００２で、第１のマスタ８０２はアドレストランザクション７００のハードウェアにマッピングされる（置き換え可能な）アトリビュート情報７０４〜７０７の値を以下のように設定する。
【００５８】
READ/WRITE = WRITE;
ADDRESS = 0xff00_0000;
WDATA = 0x1234;
BYTE_ENABLE = 0xffff;
また、第１のマスタ８０２はアドレストランザクション７００のハードウェアにマッピングされない（置き換え不可能な）アトリビュート情報７０１〜７０３の値を以下のように設定する。
【００５９】
CURRENT_TIME = 13:13:10;
SOURCE_MODEL_NAME = MASTER1;
DEST_MODEL_NAME = SLAVE1;
尚、ハードウェアマッピングフラグ７０９は固定情報であり、第１のマスタ８０２が変更することはできない。
【００６０】
このように、第１のマスタ８０２がハードウェアに置き換え可能なアトリビュート情報７０４〜７０７と、ハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３の設定を行うと、ステップＳ１００３において、バス８０６に対してアドレストランザクション７００を発行する。
【００６１】
一方、ステップＳ１１０１において、バス８０６がアービトレーションを開始し、第１のマスタ８０２に対してバス権を与えると、第１のマスタ８０２からのアドレストランザクション７００を受け取る。
【００６２】
次に、ステップＳ１１０２において、バス８０６はアドレストランザクション７００のハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３を取得し、ステップＳ１１０３において、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７を取得する。
【００６３】
次に、ステップＳ１１０４において、バス８０６はアトリビュート情報７０４〜７０７のうちアドレス７０５をデコードし、第１のスレーブ８０４に対して第１のマスタ８０２からのアドレストランザクション７００を中継する。
【００６４】
次に、ステップＳ１１０５において、バス８０６はハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３における発行時刻７０１、発行元モデル名７０２、発行先モデル名７０３をトランザクション履歴９０１に追加する。また同時に、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７の情報をトランザクション履歴９０１に追加する。
【００６５】
次に、第１のスレーブ８０４は、バス８０６からのアドレストランザクション７００を受け取り、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７のアドレス７０５、ライトデータ７０６、バイトイネーブル７０７に従って該当するアドレスへデータを書き込む。
【００６６】
［データの読み出し］
次に、図１０〜図１２を用いて第２のマスタ８０３が第１のスレーブ８０４からデータの読み出しを行う場合の処理について説明する。
【００６７】
尚、第２のマスタ８０３の処理は、図１０に示したフローチャートと同様であり、バス８０６の処理は図１１に示したフローチャートと同様である。
【００６８】
図１２は、実施例１における第１のスレーブ８０４の処理を示すフローチャートである。
【００６９】
上述した第１のマスタ８０２からのアドレストランザクション７００の発行と同様に、まず第２のマスタ８０３がバス８０６に対してアドレストランザクション７００の発行を行う（Ｓ１００１〜Ｓ１００３）。
【００７０】
即ち、第２のマスタ８０３はアドレストランザクション７００のハードウェアに置き換え可能なアトリビュート情報７０４〜７０７に値を以下のように設定する。
【００７１】
READ/WRITE = READ;
ADDRESS = 0xff00_0000;
WDATA =  ;
BYTE_ENABLE = 0xffff;
また、第２のマスタ８０３はアドレストランザクション７００のハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３に値を以下のように設定する。
【００７２】
CURRENT_TIME = 13:13:20;
SOURCE_MODEL_NAME = MASTER2;
DEST_MODEL_NAME = SLAVE1;
バス８０６はアービトレーションを開始し、第２のマスタ８０３にバス権を与えると、第２のマスタ８０３からのアドレストランザクション７００を受け取る（Ｓ１１０１）。そして、上述したデータの書き込みと同様に、アトリビュート情報７０１〜７０７の取得及び処理（Ｓ１１０２〜Ｓ１１０４）を行う。
【００７３】
次に、バス８０６はトランザクション履歴９０１に第２のマスタ８０３からのアドレストランザクション７００の情報を追加する（Ｓ１１０５）。
【００７４】
一方、第１のスレーブ８０４は、ステップＳ１２０１において、バス８０６からのアドレストランザクション７００を受け取り、ステップＳ１２０２において、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７のアドレス７０５、バイトイネーブル７０７に従って該当するアドレスのデータを読み出す。
【００７５】
そして、ステップＳ１２０３において、第１のスレーブ８０４は、バス８０６に対してリードデータトランザクション７１０の発行を開始する。
【００７６】
まず、第１のスレーブ８０４はリードデータトランザクション７１０のハードウェアに置き換え可能なアトリビュート情報７１４の値を以下のように設定する。
【００７７】
RDATA = 0x1234;
また、第１のスレーブ８０４は、リードデータトランザクション７１０のハードウェアに置き換え不可能なアトリビュート情報７１１〜７１３の値を以下のように設定する。
【００７８】
CURRENT_TIME = 13:13:30;
SOURCE_MODEL_NAME = SLAVE1;
DEST_MODEL_NAME = MASTER2;
尚、ハードウェアマッピングフラグ７１９は固定情報であり、第１のスレーブ８０４が変更することはできない。
【００７９】
このように、第１のスレーブ８０４はハードウェアに置き換え可能なアトリビュート情報７１４と、ハードウェアに置き換え不可能なアトリビュート情報７１１〜７１３の設定を行うと、バス８０６に対してリードデータトランザクション７１０を発行する。
【００８０】
一方、バス８０６は第１のスレーブ８０４からのリードデータトランザクション７１０を受け取ると（Ｓ１１０１）、アトリビュート情報を取得し（Ｓ１１０２、Ｓ１１０３）、第２のマスタ８０３に対して第１のスレーブ８０４からのリードデータトランザクション７１０を中継する（Ｓ１１０４）。そして、トランザクション履歴９０１にリードデータトランザクション７１０の情報を追加する（Ｓ１１０５）。
【００８１】
シミュレーションが終了すると、設計者は、トランザクション履歴９０１に追加されたトランザクション発行時刻、トランザクション発行元モデル名、トランザクション発行先モデル名により、トランザクション履歴９０１の検索・並び替えを行い、システムが所望の動作を実行したか否かを確認する。
【００８２】
尚、実施例１では、１つのバスを例に説明したが、複数のバスを含むシステムに本発明を適用することも可能である。その場合、各バスが生成したシミュレーション履歴を個別に、或いは１つに纏めて表示し、検索・並び替えを行えば良い。
【００８３】
以上、詳細に説明したように、実施例１によれば、バスを介して通信されるトランザクションに、ハードウェアの信号に相当することを示すハードウェアマッピングフラグと、ハードウェアの信号に置き換え不可能なアトリビュート情報とを設け、トランザクションを発行するモジュールでハードウェアに置き換え不可能なアトリビュート情報を生成し、トランザクションを受信したモジュールでハードウェアに置き換え不可能なアトリビュート情報を履歴として追加できるようにしたため、以下のような効果が得られる。
（１）ハードウェアに置き換え不可能なアトリビュート情報によりシミュレーション履歴を容易に蓄積でき、シミュレーション履歴を視認しやすくすることができる。このため、検証にかかる時間を短縮することが可能である。
（２）ハードウェアに置き換え不可能なアトリビュート情報によりシミュレーション履歴の検索・並び替えが容易に実行できる。このため、設計者が所望する情報を容易に検索でき、効率的に検証を行うことが可能である。
【実施例２】
【００８４】
次に、図面を参照しながら本発明に係る実施例２について詳細に説明する。実施例２では、マスタからのトランザクションにより処理を実行するスレーブである機能モジュールがハードウェアにマッピングされないアトリビュート情報としてシミュレーション時間をトランザクションに付加するものである。
【００８５】
図１３は、実施例２におけるシミュレーションモデルで使用するトランザクションの構成の一例を示す図である。図１３において、１３００はアドレストランザクションであり、バスにより通信され、マスタもしくはバスからのスレーブに対するアクセス要求に相当するトランザクションである。アドレストランザクション１３００において、１３０１〜１３０５はハードウェアであるバス信号にマッピングされるアトリビュート情報である。このアトリビュート情報はバスプロトコルに依存するものであり、バスの種類によってトランザクションに含まれるアトリビュート情報は異なってくる。
【００８６】
１３１０はリードデータトランザクションであり、マスタもしくはバスからのリードアクセス要求に対するリードデータに相当するトランザクションである。このリードデータトランザクション１３１０において、１３１６〜１３１９はハードウェアであるバス信号にマッピングされないアトリビュート情報であり、実施例２では以下の情報が保持される。
【００８７】
即ち、リードリクエストのアドレストランザクションを機能モジュールが受信した時のシミュレーション時間である処理開始時間１３１６と、リードリクエストが遅延を生じる外部要因がない場合に処理が完了する時のシミュレーション時間である最短処理完了時間１３１７と、リードリクエストの処理が実際に完了した時のシミュレーション時間である処理完了時間１３１８と、リードデータトランザクションを発行した機能モジュール名称１３１９が保持される。
【００８８】
また、１３１１はハードウェアであるバス信号にマッピングされるアトリビュート情報である。
【００８９】
１３２０、１３２５はハードウェアマッピングフラグであり、アトリビュート情報１３０１〜１３０５、１３１１、１３１６〜１３１９がハードウェアであるバス信号にマッピングされるか否かを示すフラグである。実施例２では、ハードウェアマッピングフラグ１３２０において、黒丸で示されるものがハードウェアにマッピングされることを、黒丸が無いものがハードウェアにマッピングされないことを示している。
【００９０】
図１４は、実施例２におけるシミュレーションモデルのシステム構成の一例を示す図である。図１４において、１４０１はクロック生成器であり、システムの各機能モジュール（後述する第１のマスタ、第２のマスタ、第１のスレーブ、第２のスレーブ）に対してクロックを供給する。
【００９１】
１４１１、１４１２は対象とするシステムを構成する第１、第２のバスであり、バスに対してマスタとして接続する機能モジュールからのトランザクションを受信し、バスのアービトレーション、アドレスデコードを行い、アービトレーションによって選択された機能モジュールのトランザクションを、バスに対してスレーブとして接続する機能モジュールに対して中継する。
【００９２】
１４２１はシステムを構成する機能モジュールの１つである第１のマスタである。この第１のマスタ１４２１は、第１のバス１４１１に対してマスタとして接続しており、第１のバス１４１１に対してトランザクションを発行し、スレーブからのトランザクションを受信する。
【００９３】
１４２２はシステムを構成する機能モジュールの１つである第２のマスタである。この第２のマスタ１４２２は、第２のバス１４１２に対してマスタとして接続しており、第２のバス１４１２に対してトランザクションを発行し、スレーブからのトランザクションを受信する。
【００９４】
１４３１はシステムを構成する機能モジュールの１つである第１のスレーブである。この第１のスレーブ１４３１は、第１のバス１４１１に対してスレーブとして接続しており、第１のバス１４１１からトランザクションを受信し、マスタからのリードに相当するトランザクションに対してはリードデータに相当するトランザクションを発行する。
【００９５】
１４３２はシステムを構成する機能モジュールの１つである第２のスレーブである。この第２のスレーブ１４３２は第１のバス１４１１と第２のバス１４１２に対してスレーブとして接続しており、第１のバス１４１１又は第２のバス１４１２からトランザクションを受信し、マスタからのリードに相当するトランザクションに対してはリードデータに相当するトランザクションを発行する。
【００９６】
１４０２はトランザクションにより通信を行うポートである。第１のマスタ１４２１、第２のマスタ１４２２、第１のスレーブ１４３１、第２のスレーブ１４３２、第１のバス１４１１、及び第２のバス１４１２にそれぞれ存在する。そして、１４０３は信号ポートであり、クロック生成器１４０１からのクロックを受信するポートである。
【００９７】
以上の構成において、まず、第１のマスタ１４２１が第２のスレーブ１４３２に対して読み込みを行う場合の処理について説明する。
【００９８】
シミュレーションが開始されると、第１のマスタ１４２１が第１のバス１４１１に対してトランザクションを発行できる状態であれば、アドレストランザクションの発行を行う。第１のマスタ１４２１は、アドレストランザクション１３００のハードウェアにマッピングされるアトリビュート情報１３０１、１３０２、１３０４の値を以下のように設定する。
【００９９】
transaction.read_write.value  = READ;
transaction.address.value     = 0x08000000;
transaction.byte_enable.value = 0xf;
尚、アドレストランザクション１３００のハードウェアマッピングフラグ１３２０は読み出し専用情報として以下に示す値が予め保持されており、第１のマスタ１４２１が変更することはできない。
【０１００】
transaction.read_write.hw_flag  == true
transaction.address.hw_flag     == true
transaction.write_data.hw_flag  == true
transaction.byte_enable.hw_flag == true
このように、第１のマスタ１４２１がアトリビュート情報の設定を行うと、第１のバス１４１１に対してアドレストランザクション１３００を発行する。
【０１０１】
一方、第１のバス１４１１は、第１のマスタ１４２１からのアドレストランザクション１３００を受け取り、アドレストランザクション１３００のハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５の値を読み出す。
【０１０２】
そして、第１のバス１４１１は、ハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５のうちアドレス１３０２の値をデコードし、第２のスレーブ１４３２に対して第１のマスタ１４２１からのアドレストランザクション１３００を中継する。
【０１０３】
一方、第２のスレーブ１４３２は、第１のバス１４１１からトランザクションが受け取り可能な状態であれば、アドレストランザクション１３００を受け取り、アドレストランザクション１３００のハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５の値を読み出す。
【０１０４】
そして、ハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５のアドレス１３０２、バイトイネーブル１３０４、バースト長１３０５に従って該当するアドレスのデータを読み出す。
【０１０５】
その後、第２のスレーブ１４３２は、第１のバス１４１１に対してリードデータトランザクション１３１０の発行を開始する。
【０１０６】
ここでは、リードデータトランザクション１３１０のハードウェアにマッピングされるアトリビュート情報１３１１の値を以下のように設定する。
【０１０７】
transaction.read_data.value = 0x76543210;
また、リードデータトランザクション１３１０のハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９に値を以下のように設定する。
【０１０８】
transaction.model_name.value = SLAVE2;
transaction.start_time.value = 120;
transaction.base_time.value  = 140;
transaction.done_time.value  = 140;
ここで、start_timeは第２のスレーブ１４３２がリードリクエストのアドレストランザクション１３００を受け取り、リードの処理を開始したシミュレーション時間１３１６である。base_timeは第２のスレーブ１４３２がリードリクエストに対してリード処理が遅延を生じる外部要因がない場合の処理完了時間１３１７である。done_timeは第２のスレーブ１４３２がリードリクエストに対してリード処理の実際の処理完了時間１３１８である。
【０１０９】
また、第２のスレーブ１４３２がリード処理を行うに当たり、遅延を生じる要因は無いため、base_timeとdone_timeが同一となっている。
【０１１０】
尚、リードデータトランザクション１３１０のハードウェアマッピングフラグ１３２５は読み出し専用情報として以下に示す値が予め保持されており、第２のスレーブ１４３２が変更することはできない。
【０１１１】
transaction.read_data.hw_flag  == true
transaction.model_name.hw_flag == false
transaction.start_time.hw_flag == false
transaction.base_time.hw_flag  == false
transaction.done_time.hw_flag  == false
第２のスレーブ１４３２は、ハードウェアにマッピングされるアトリビュート情報１３１１と、ハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の設定を行うと、第１のバス１４１１に対してリードデータトランザクション１３１０を発行する。
【０１１２】
第１のマスタ１４２１は、第１のバス１４１１からリードデータトランザクション１３１０を受け取り、ハードウェアにマッピングされるアトリビュート情報１３１１の値と、ハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の値を読み出し、第１のマスタ１４２１内部の所定の処理を行うことでリードの処理が完了する。
【０１１３】
次に、第２のマスタ１４２２が第２のスレーブ１４３２に対してリードリクエストしているのと同時に、上述したように第１のマスタ１４２１がリードリクエストしている場合について説明する。
【０１１４】
上述したように、第１のマスタ１４２１がリードリクエストのアドレストランザクションを発行し、第１のバス１４１１を通じて第２のスレーブ１４３２が受け取り、リード処理を開始する。
【０１１５】
ところが、第２のスレーブ１４３２は第１のマスタ１４２１のリードリクエストを受信する直前に、第２のマスタ１４２２からのリードリクエストを受信しており、そのリード処理を完了するまで第１のマスタ１４２１のリード処理は持ち状態となる。
【０１１６】
第２のマスタ１４２２からのリード処理が完了後、第１のマスタ１４２１からのアドレストランザクション１３００のハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５の値を読み出す。
【０１１７】
そして、ハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５のアドレス１３０２、バイトイネーブル１３０４、バースト長１３０５に従って該当するアドレスのデータを読み出す。
【０１１８】
その後、第２のスレーブ１４３２は、第１のバス１４１１に対してリードデータトランザクション１３１０の発行を開始する。
【０１１９】
リードデータトランザクション１３１０のハードウェアにマッピングされるアトリビュート情報１３１１に値を以下のように設定する。
【０１２０】
transaction.read_data.value = 0xfedcba98;
また、リードデータトランザクション１３１０のハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の値も以下のように設定する。
【０１２１】
transaction.model_name.value = SLAVE2;
transaction.start_time.value = 370;
transaction.base_time.value  = 390;
transaction.done_time.value  = 410;
ここで、start_time、base_time、done_timeの意味は上述した通りである。ここでは、第２のスレーブ１４３２がリード処理を行うに当たり、他のリード処理の完了持ちが発生したために、base_timeに比べて実際の処理完了時間done_timeが遅くなっている。
【０１２２】
尚、リードデータトランザクション１３１０のハードウェアマッピングフラグ１３２５は読み出し専用情報として以下に示す値が予め保持されており、第２のスレーブ１４３２が変更することはできない。
【０１２３】
transaction.read_data.hw_flag  == true
transaction.model_name.hw_flag == false
transaction.start_time.hw_flag == false
transaction.base_time.hw_flag  == false
transaction.done_time.hw_flag  == false
第２のスレーブ１４３２はハードウェアにマッピングされるアトリビュート情報１３１１と、ハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の設定を行うと、第１のバス１４１１に対してリードデータトランザクション１３１０を発行する。
【０１２４】
第１のマスタ１４２１は、第１のバス１４１１からリードデータトランザクション１３１０を受け取り、ハードウェアにマッピングされるアトリビュート情報１３１１の値と、ハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の値を読み出し、第１のマスタ１４２１内部の所定の処理を行うことでリード処理が完了する。
【０１２５】
次に、第２のマスタ１４２２が第１のスレーブ１４３１に対してリードリクエストする場合について説明する。
【０１２６】
上述したデータ読み出しと同様に、第１のマスタ１４２１がリードリクエストのアドレストランザクションを発行し、第１のバス１４１１を通じて第１のスレーブ１４３１が受け取り、リード処理を開始する。
【０１２７】
第１のマスタ１４２１からのアドレストランザクション１３００のハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５の値を読み出し、ハードウェアにマッピングされるアトリビュート情報１３０１〜１３０５のアドレス１３０２、バイトイネーブル１３０４、バースト長１３０５に従って該当するアドレスのデータを読み出す。
【０１２８】
その後、第２のスレーブ１４３２は、第１のバス１４１１に対してリードデータトランザクション１３１０の発行を開始する。
【０１２９】
リードデータトランザクション１３１０のハードウェアにマッピングされるアトリビュート情報１３１１に値を以下のように設定する。
【０１３０】
transaction.read_data.value = 0x332１４１１00;
また、リードデータトランザクション１３１０のハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の値も以下のように設定する。
【０１３１】
transaction.start_time.value = 610;
transaction.base_time.value  = 620;
transaction.done_time.value  = 620;
transaction.model_name.value = SLAVE1;
ここで、start_time、base_time、done_timeの意味は上述した通りである。ここでは、第１のスレーブ１４３１は高速にリード処理を行うことが可能なので、第２のスレーブ１４３２に比べてstart_timeからbase_timeまでの差が小さい。
【０１３２】
また、第１のスレーブ１４３１は第１のバス１４１１とだけ接続しており、第２のバス１４１２と接続している第２のマスタ１４２２からの影響を受けることが無く、base_timeとdone_timeが同一となっている。
【０１３３】
リードトランザクション１３１０のハードウェアマッピングフラグ１３２５は上述した場合と同様に保持され、第１のバス１４１１に対してリードデータトランザクション１３１０を発行する。
【０１３４】
第１のマスタ１４２１は、第１のバス１４１１からリードデータトランザクション１３１０を受け取り、ハードウェアにマッピングされるアトリビュート情報１３１１の値と、ハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９の値を読み出し、第１のマスタ内部の所定の処理を行うことでリード処理が完了する。
【０１３５】
以上、実施例２によれば、第１のマスタ１４２１から第１のスレーブ１４３１及び第２のスレーブ１４３２へリードアクセスした場合のシミュレーション時間に関する情報を、専用のインタフェースを用いたモニタを実装すること無く、第１のマスタ１４２１が取得することができる。この情報を用いてグラフとして図示したものが図１５である。また、この時の第１のマスタ１４２１及び第２のマスタ１４２２のスレーブへのアクセス状況を示したものが図１６である。
【０１３６】
図１５に示す縦軸は第１のマスタ１４２１からスレーブに対して行ったリードデータのスレーブでの処理時間であり、横軸はシミュレーション時間である。
【０１３７】
図１５において、１５０１はスレーブから受信したリードデータトランザクション１３１０のハードウェアにマッピングされないアトリビュート情報１３１６〜１３１９のうち最短処理完了時間１３１７から処理開始時間１３１６を減算（base_time - start_time）してプロットしたものである。また、１５０２は処理完了時間１３１８から処理開始時間１３１６を減算（done_time - start_time）してプロットしたものである。
【０１３８】
これにより、遅延を生じる外部要因がない場合のスレーブでのリード処理時間１５０１と、実際のスレーブでのリード処理時間１５０２を示すことができる。
【０１３９】
図１６に示す縦軸はマスタの種類を示しており、Ｍ１は第１のマスタ１４２１、Ｍ２は第２のマスタ１４２２である。横軸はシミュレーション時間を示している。
【０１４０】
図１６において、１６０１はシミュレーション時間ｔ０からｔ２の期間に第１のマスタ１４２１が第２のスレーブ１４３２（Ｓ２）にアクセスしていることを示している。また、１６０２はシミュレーション時間ｔ２からｔ３の期間に第１のマスタ１４２１が第１のスレーブ１４３１（Ｓ１）にアクセスしていることを示している。
【０１４１】
１６０３はシミュレーション時間ｔ１からｔ３の期間に第２のマスタ１４２２が第２のスレーブ１４３２（Ｓ２）にアクセスしていることを示している。尚、第２のマスタ１４２２はシミュレーション時間ｔ０からｔ１の期間にはどこにもアクセスしていない。
【０１４２】
図１５及び図１６から明らかなように、ｔ０〜ｔ１の期間のリード処理は余計な遅延が生じることなく処理が行われていること、ｔ１〜ｔ２の期間のリード処理は第２のマスタ１４２２の影響により余計な遅延が生じてしまっていること、ｔ２〜ｔ３の期間のリード処理は余計な遅延が生じることなく処理が行われていることが分かる。
【０１４３】
ここで、ｔ０〜ｔ１の期間とｔ２〜ｔ３の期間とは、リード処理にかかっている時間が異なっているが、どちらも余計な遅延は生じていないことが一見して分かるようになっている。
【０１４４】
これらの情報は、スレーブに対して行ったリード処理の所要時間をマスタ側で単に計測しただけでは得ることができない。特に、外部からの要因によって遅延が生じない場合の処理時間はスレーブ内部のみに保持されている情報であり、その情報を専用のインタフェースを用いることなく、既に用意されているトランザクションによって通信を行うポートを用いて取得している。
【０１４５】
このように、トランザクションが到達する可能性のあるスレーブ全てにモニタを設置し、専用のインタフェースから情報を取得し、各モニタ間で情報の共有を行うといったような複雑な仕組みを用いることなく、トランザクションを受けた機能モジュールがそのトランザクションのアトリビュート情報を参照するだけで、スレーブ内部が保持する情報を取得することが可能となる。
【０１４６】
以上に説明したように、実施例２によれば、バスを介して通信されるトランザクションに、ハードウェアの信号に相当することを示すハードウェアマッピングフラグと、ハードウェアの信号に無関係な情報を付加できるようにし、トランザクションを発行するモジュールにおいて情報を付加し、トランザクションを受信したモジュールにおいて付加情報を利用できるようにしたため、以下のような効果が得られる。
（１）機能モジュール内に保持されている情報を用いなければ取得できないような情報を得ることができ、それによりシステム設計者はシステムの性能解析及び検証の効率を大幅に向上させることが可能である。特に各機能モジュールが、他の機能モジュールから処理を依頼されてから完了するまでに費やされた待ち時間が、他の機能モジュールとの競合等によるものなのか、本来そのモジュールが最低限必要としているものなのかを容易に把握可能となり、設計者による性能解析の効率が向上する。
（２）バス及び機能モジュールに、必要な情報を取得するためのモニタ専用メソッドを用意することなく、既存のトランザクション操作メソッドを拡張することで、設計者がシミュレーション中のバス及び機能モジュール内の必要な情報を確認することが可能となる。また、これによってモニタ専用メソッドを呼ぶことによるイベントの増加、更にはシミュレーション速度の低下を避けることが可能となる。
【０１４７】
尚、本発明は複数の機器（例えば、ホストコンピュータ，インターフェース機器，リーダ，プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用しても良い。
【０１４８】
また、本発明の目的は前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１４９】
この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１５０】
このプログラムコードを供給するための記録媒体としては、例えばフロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１５１】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１５２】
更に、記録媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０１５３】
【図１】AHB CLIで定義されているバストランザクションを示す図である。
【図２】トランザクションメソッド、アトリビュート、ハードウェアの対応を示す図である。
【図３】トランザクションメソッドと信号波形の対応を示す図である。
【図４】トランザクションメソッドを用いたシミュレーションを説明するための図である。
【図５】ハードウェアコンフィギュレーションメソッドを示す図である。
【図６】検証メソッドを示す図である。
【図７】実施例１におけるシミュレーションモデルで使用するトランザクションの構成の一例を示す図である。
【図８】実施例１におけるシミュレーションモデルのシステム構成の一例を示す図である。
【図９】バス８０６におけるトランザクション履歴９０１である。
【図１０】実施例１における第１のマスタの処理を示すフローチャートである。
【図１１】実施例１におけるバスの処理を示すフローチャートである。
【図１２】実施例１における第１のスレーブ８０４の処理を示すフローチャートである。
【図１３】実施例２におけるシミュレーションモデルで使用するトランザクションの構成の一例を示す図である。
【図１４】実施例２におけるシミュレーションモデルのシステム構成の一例を示す図である。
【図１５】リード処理時間の相違を説明するための図である。
【図１６】リード処理時間の相違を説明するための図である。
【符号の説明】
【０１５４】
７００  アドレストランザクション
７０１  トランザクション発行時刻
７０２  トランザクション発行元モデル名称
７０３  トランザクション発行先モデル名称
７０４  リード／ライト
７０５  アドレス
７０６  ライトデータ
７０７  バイトイネーブル
７０９  ハードウェアマッピングフラグ
７１０  リードデータトランザクション
７１１  トランザクション発行時刻
７１２  トランザクション発行元モデル名称
７１３  トランザクション発行先モデル名称
７１４  リードデータ
７１９  ハードウェアマッピングフラグ
８０１  クロック生成器
８０２  第１のマスタ
８０３  第２のマスタ
８０４  第１のスレーブ
８０５  第２のスレーブ
８０６  バス
８０７  トランザクションポート
８０８  信号ポート
９０１  トランザクション履歴
【図１】
2006079369.tif 000003
【図２】
2006079369.tif 000004
【図３】
2006079369.tif 000005
【図４】
2006079369.tif 000006
【図５】
2006079369.tif 000007
【図６】
2006079369.tif 000008
【図７】
2006079369.tif 000009
【図８】
2006079369.tif 000010
【図９】
2006079369.tif 000011
【図１０】
2006079369.tif 000012
【図１１】
2006079369.tif 000013
【図１２】
2006079369.tif 000014
【図１３】
2006079369.tif 000015
【図１４】
2006079369.tif 000016
【図１５】
2006079369.tif 000017
【図１６】
2006079369.tif 000018
【手続補正書】
【提出日】平成17年11月25日(2005.11.25)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０１２５
【補正方法】変更
【補正の内容】
【０１２５】
次に、第１のマスタ１４２１が第１のスレーブ１４３１に対してリードリクエストする場合について説明する。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１２８
【補正方法】変更
【補正の内容】
【０１２８】
その後、第１のスレーブ１４３１は、第１のバス１４１１に対してリードデータトランザクション１３１０の発行を開始する。