JP4262174B2 - シミュレーション時間取得方法 - Google Patents
シミュレーション時間取得方法 Download PDFInfo
- Publication number
- JP4262174B2 JP4262174B2 JP2004262953A JP2004262953A JP4262174B2 JP 4262174 B2 JP4262174 B2 JP 4262174B2 JP 2004262953 A JP2004262953 A JP 2004262953A JP 2004262953 A JP2004262953 A JP 2004262953A JP 4262174 B2 JP4262174 B2 JP 4262174B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- bus
- master
- hardware
- time
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Design And Manufacture Of Integrated Circuits (AREA)
- Debugging And Monitoring (AREA)
Description
本発明は、シミュレーション装置がシミュレーションモデルを用いたシミュレーションを実行することにより、シミュレーション時間を取得する方法に関するものである。
プロセス技術の進歩によりＬＳＩの集積度が増大し、これまではボードで実現していたシステムをシステムＬＳＩとして１チップ上に搭載することが可能となっている。また、チップ上に搭載する機能モジュールも多様化し、回路規模も増大している。これに伴い、システムＬＳＩを効率的に設計するための手法として、従来の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日公開
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;
また、第１のマスタ８０２はアドレストランザクション７００のハードウェアにマッピングされない（置き換え不可能な）アトリビュート情報７０１〜７０３の値を以下のように設定する。
ADDRESS = 0xff00_0000;
WDATA = 0x1234;
BYTE_ENABLE = 0xffff;
また、第１のマスタ８０２はアドレストランザクション７００のハードウェアにマッピングされない（置き換え不可能な）アトリビュート情報７０１〜７０３の値を以下のように設定する。
CURRENT_TIME = 13:13:10;
SOURCE_MODEL_NAME = MASTER1;
DEST_MODEL_NAME = SLAVE1;
尚、ハードウェアマッピングフラグ７０９は固定情報であり、第１のマスタ８０２が変更することはできない。
SOURCE_MODEL_NAME = MASTER1;
DEST_MODEL_NAME = SLAVE1;
尚、ハードウェアマッピングフラグ７０９は固定情報であり、第１のマスタ８０２が変更することはできない。
このように、第１のマスタ８０２がハードウェアに置き換え可能なアトリビュート情報７０４〜７０７と、ハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３の設定を行うと、ステップＳ１００３において、バス８０６に対してアドレストランザクション７００を発行する。
一方、ステップＳ１１０１において、バス８０６がアービトレーションを開始し、第１のマスタ８０２に対してバス権を与えると、第１のマスタ８０２からのアドレストランザクション７００を受け取る。
次に、ステップＳ１１０２において、バス８０６はアドレストランザクション７００のハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３を取得し、ステップＳ１１０３において、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７を取得する。
次に、ステップＳ１１０４において、バス８０６はアトリビュート情報７０４〜７０７のうちアドレス７０５をデコードし、第１のスレーブ８０４に対して第１のマスタ８０２からのアドレストランザクション７００を中継する。
次に、ステップＳ１１０５において、バス８０６はハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３における発行時刻７０１、発行元モデル名７０２、発行先モデル名７０３をトランザクション履歴９０１に追加する。また同時に、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７の情報をトランザクション履歴９０１に追加する。
次に、第１のスレーブ８０４は、バス８０６からのアドレストランザクション７００を受け取り、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７のアドレス７０５、ライトデータ７０６、バイトイネーブル７０７に従って該当するアドレスへデータを書き込む。
［データの読み出し］
次に、図１０〜図１２を用いて第２のマスタ８０３が第１のスレーブ８０４からデータの読み出しを行う場合の処理について説明する。
次に、図１０〜図１２を用いて第２のマスタ８０３が第１のスレーブ８０４からデータの読み出しを行う場合の処理について説明する。
尚、第２のマスタ８０３の処理は、図１０に示したフローチャートと同様であり、バス８０６の処理は図１１に示したフローチャートと同様である。
図１２は、実施例１における第１のスレーブ８０４の処理を示すフローチャートである。
上述した第１のマスタ８０２からのアドレストランザクション７００の発行と同様に、まず第２のマスタ８０３がバス８０６に対してアドレストランザクション７００の発行を行う（Ｓ１００１〜Ｓ１００３）。
即ち、第２のマスタ８０３はアドレストランザクション７００のハードウェアに置き換え可能なアトリビュート情報７０４〜７０７に値を以下のように設定する。
READ/WRITE = READ;
ADDRESS = 0xff00_0000;
WDATA = ;
BYTE_ENABLE = 0xffff;
また、第２のマスタ８０３はアドレストランザクション７００のハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３に値を以下のように設定する。
ADDRESS = 0xff00_0000;
WDATA = ;
BYTE_ENABLE = 0xffff;
また、第２のマスタ８０３はアドレストランザクション７００のハードウェアに置き換え不可能なアトリビュート情報７０１〜７０３に値を以下のように設定する。
CURRENT_TIME = 13:13:20;
SOURCE_MODEL_NAME = MASTER2;
DEST_MODEL_NAME = SLAVE1;
バス８０６はアービトレーションを開始し、第２のマスタ８０３にバス権を与えると、第２のマスタ８０３からのアドレストランザクション７００を受け取る（Ｓ１１０１）。そして、上述したデータの書き込みと同様に、アトリビュート情報７０１〜７０７の取得及び処理（Ｓ１１０２〜Ｓ１１０４）を行う。
SOURCE_MODEL_NAME = MASTER2;
DEST_MODEL_NAME = SLAVE1;
バス８０６はアービトレーションを開始し、第２のマスタ８０３にバス権を与えると、第２のマスタ８０３からのアドレストランザクション７００を受け取る（Ｓ１１０１）。そして、上述したデータの書き込みと同様に、アトリビュート情報７０１〜７０７の取得及び処理（Ｓ１１０２〜Ｓ１１０４）を行う。
次に、バス８０６はトランザクション履歴９０１に第２のマスタ８０３からのアドレストランザクション７００の情報を追加する（Ｓ１１０５）。
一方、第１のスレーブ８０４は、ステップＳ１２０１において、バス８０６からのアドレストランザクション７００を受け取り、ステップＳ１２０２において、ハードウェアに置き換え可能なアトリビュート情報７０４〜７０７のアドレス７０５、バイトイネーブル７０７に従って該当するアドレスのデータを読み出す。
そして、ステップＳ１２０３において、第１のスレーブ８０４は、バス８０６に対してリードデータトランザクション７１０の発行を開始する。
まず、第１のスレーブ８０４はリードデータトランザクション７１０のハードウェアに置き換え可能なアトリビュート情報７１４の値を以下のように設定する。
RDATA = 0x1234;
また、第１のスレーブ８０４は、リードデータトランザクション７１０のハードウェアに置き換え不可能なアトリビュート情報７１１〜７１３の値を以下のように設定する。
また、第１のスレーブ８０４は、リードデータトランザクション７１０のハードウェアに置き換え不可能なアトリビュート情報７１１〜７１３の値を以下のように設定する。
CURRENT_TIME = 13:13:30;
SOURCE_MODEL_NAME = SLAVE1;
DEST_MODEL_NAME = MASTER2;
尚、ハードウェアマッピングフラグ７１９は固定情報であり、第１のスレーブ８０４が変更することはできない。
SOURCE_MODEL_NAME = SLAVE1;
DEST_MODEL_NAME = MASTER2;
尚、ハードウェアマッピングフラグ７１９は固定情報であり、第１のスレーブ８０４が変更することはできない。
このように、第１のスレーブ８０４はハードウェアに置き換え可能なアトリビュート情報７１４と、ハードウェアに置き換え不可能なアトリビュート情報７１１〜７１３の設定を行うと、バス８０６に対してリードデータトランザクション７１０を発行する。
一方、バス８０６は第１のスレーブ８０４からのリードデータトランザクション７１０を受け取ると（Ｓ１１０１）、アトリビュート情報を取得し（Ｓ１１０２、Ｓ１１０３）、第２のマスタ８０３に対して第１のスレーブ８０４からのリードデータトランザクション７１０を中継する（Ｓ１１０４）。そして、トランザクション履歴９０１にリードデータトランザクション７１０の情報を追加する（Ｓ１１０５）。
シミュレーションが終了すると、設計者は、トランザクション履歴９０１に追加されたトランザクション発行時刻、トランザクション発行元モデル名、トランザクション発行先モデル名により、トランザクション履歴９０１の検索・並び替えを行い、システムが所望の動作を実行したか否かを確認する。
尚、実施例１では、１つのバスを例に説明したが、複数のバスを含むシステムに本発明を適用することも可能である。その場合、各バスが生成したシミュレーション履歴を個別に、或いは１つに纏めて表示し、検索・並び替えを行えば良い。
以上、詳細に説明したように、実施例１によれば、バスを介して通信されるトランザクションに、ハードウェアの信号に相当することを示すハードウェアマッピングフラグと、ハードウェアの信号に置き換え不可能なアトリビュート情報とを設け、トランザクションを発行するモジュールでハードウェアに置き換え不可能なアトリビュート情報を生成し、トランザクションを受信したモジュールでハードウェアに置き換え不可能なアトリビュート情報を履歴として追加できるようにしたため、以下のような効果が得られる。
（１）ハードウェアに置き換え不可能なアトリビュート情報によりシミュレーション履歴を容易に蓄積でき、シミュレーション履歴を視認しやすくすることができる。このため、検証にかかる時間を短縮することが可能である。
（２）ハードウェアに置き換え不可能なアトリビュート情報によりシミュレーション履歴の検索・並び替えが容易に実行できる。このため、設計者が所望する情報を容易に検索でき、効率的に検証を行うことが可能である。
（１）ハードウェアに置き換え不可能なアトリビュート情報によりシミュレーション履歴を容易に蓄積でき、シミュレーション履歴を視認しやすくすることができる。このため、検証にかかる時間を短縮することが可能である。
（２）ハードウェアに置き換え不可能なアトリビュート情報によりシミュレーション履歴の検索・並び替えが容易に実行できる。このため、設計者が所望する情報を容易に検索でき、効率的に検証を行うことが可能である。
次に、図面を参照しながら本発明に係る実施例２について詳細に説明する。実施例２では、マスタからのトランザクションにより処理を実行するスレーブである機能モジュールがハードウェアにマッピングされないアトリビュート情報としてシミュレーション時間をトランザクションに付加するものである。
図１３は、実施例２におけるシミュレーションモデルで使用するトランザクションの構成の一例を示す図である。図１３において、１３００はアドレストランザクションであり、バスにより通信され、マスタもしくはバスからのスレーブに対するアクセス要求に相当するトランザクションである。アドレストランザクション１３００において、１３０１〜１３０５はハードウェアであるバス信号にマッピングされるアトリビュート情報である。このアトリビュート情報はバスプロトコルに依存するものであり、バスの種類によってトランザクションに含まれるアトリビュート情報は異なってくる。
１３１０はリードデータトランザクションであり、マスタもしくはバスからのリードアクセス要求に対するリードデータに相当するトランザクションである。このリードデータトランザクション１３１０において、１３１６〜１３１９はハードウェアであるバス信号にマッピングされないアトリビュート情報であり、実施例２では以下の情報が保持される。
即ち、リードリクエストのアドレストランザクションを機能モジュールが受信した時のシミュレーション時間である処理開始時間１３１６と、リードリクエストが遅延を生じる外部要因がない場合に処理が完了する時のシミュレーション時間である最短処理完了時間１３１７と、リードリクエストの処理が実際に完了した時のシミュレーション時間である処理完了時間１３１８と、リードデータトランザクションを発行した機能モジュール名称１３１９が保持される。
また、１３１１はハードウェアであるバス信号にマッピングされるアトリビュート情報である。
１３２０、１３２５はハードウェアマッピングフラグであり、アトリビュート情報１３０１〜１３０５、１３１１、１３１６〜１３１９がハードウェアであるバス信号にマッピングされるか否かを示すフラグである。実施例２では、ハードウェアマッピングフラグ１３２０において、黒丸で示されるものがハードウェアにマッピングされることを、黒丸が無いものがハードウェアにマッピングされないことを示している。
図１４は、実施例２におけるシミュレーションモデルのシステム構成の一例を示す図である。図１４において、１４０１はクロック生成器であり、システムの各機能モジュール（後述する第１のマスタ、第２のマスタ、第１のスレーブ、第２のスレーブ）に対してクロックを供給する。
１４１１、１４１２は対象とするシステムを構成する第１、第２のバスであり、バスに対してマスタとして接続する機能モジュールからのトランザクションを受信し、バスのアービトレーション、アドレスデコードを行い、アービトレーションによって選択された機能モジュールのトランザクションを、バスに対してスレーブとして接続する機能モジュールに対して中継する。
１４２１はシステムを構成する機能モジュールの１つである第１のマスタである。この第１のマスタ１４２１は、第１のバス１４１１に対してマスタとして接続しており、第１のバス１４１１に対してトランザクションを発行し、スレーブからのトランザクションを受信する。
１４２２はシステムを構成する機能モジュールの１つである第２のマスタである。この第２のマスタ１４２２は、第２のバス１４１２に対してマスタとして接続しており、第２のバス１４１２に対してトランザクションを発行し、スレーブからのトランザクションを受信する。
１４３１はシステムを構成する機能モジュールの１つである第１のスレーブである。この第１のスレーブ１４３１は、第１のバス１４１１に対してスレーブとして接続しており、第１のバス１４１１からトランザクションを受信し、マスタからのリードに相当するトランザクションに対してはリードデータに相当するトランザクションを発行する。
１４３２はシステムを構成する機能モジュールの１つである第２のスレーブである。この第２のスレーブ１４３２は第１のバス１４１１と第２のバス１４１２に対してスレーブとして接続しており、第１のバス１４１１又は第２のバス１４１２からトランザクションを受信し、マスタからのリードに相当するトランザクションに対してはリードデータに相当するトランザクションを発行する。
１４０２はトランザクションにより通信を行うポートである。第１のマスタ１４２１、第２のマスタ１４２２、第１のスレーブ１４３１、第２のスレーブ１４３２、第１のバス１４１１、及び第２のバス１４１２にそれぞれ存在する。そして、１４０３は信号ポートであり、クロック生成器１４０１からのクロックを受信するポートである。
以上の構成において、まず、第１のマスタ１４２１が第２のスレーブ１４３２に対して読み込みを行う場合の処理について説明する。
シミュレーションが開始されると、第１のマスタ１４２１が第１のバス１４１１に対してトランザクションを発行できる状態であれば、アドレストランザクションの発行を行う。第１のマスタ１４２１は、アドレストランザクション１３００のハードウェアにマッピングされるアトリビュート情報１３０１、１３０２、１３０４の値を以下のように設定する。
transaction.read_write.value = READ;
transaction.address.value = 0x08000000;
transaction.byte_enable.value = 0xf;
尚、アドレストランザクション１３００のハードウェアマッピングフラグ１３２０は読み出し専用情報として以下に示す値が予め保持されており、第１のマスタ１４２１が変更することはできない。
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.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は第２のスレーブ１４３２がリードリクエストに対してリード処理の実際の処理完了時間１３１８である。
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.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.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.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までの差が小さい。
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）してプロットしたものである。
これにより、遅延を生じる外部要因がない場合のスレーブでのリード処理時間１５０１と、実際のスレーブでのリード処理時間１５０２を示すことができる。
図１６に示す縦軸はマスタの種類を示しており、Ｍ１は第１のマスタ１４２１、Ｍ２は第２のマスタ１４２２である。横軸はシミュレーション時間を示している。
図１６において、１６０１はシミュレーション時間ｔ０からｔ２の期間に第１のマスタ１４２１が第２のスレーブ１４３２（Ｓ２）にアクセスしていることを示している。また、１６０２はシミュレーション時間ｔ２からｔ３の期間に第１のマスタ１４２１が第１のスレーブ１４３１（Ｓ１）にアクセスしていることを示している。
１６０３はシミュレーション時間ｔ１からｔ３の期間に第２のマスタ１４２２が第２のスレーブ１４３２（Ｓ２）にアクセスしていることを示している。尚、第２のマスタ１４２２はシミュレーション時間ｔ０からｔ１の期間にはどこにもアクセスしていない。
図１５及び図１６から明らかなように、ｔ０〜ｔ１の期間のリード処理は余計な遅延が生じることなく処理が行われていること、ｔ１〜ｔ２の期間のリード処理は第２のマスタ１４２２の影響により余計な遅延が生じてしまっていること、ｔ２〜ｔ３の期間のリード処理は余計な遅延が生じることなく処理が行われていることが分かる。
ここで、ｔ０〜ｔ１の期間とｔ２〜ｔ３の期間とは、リード処理にかかっている時間が異なっているが、どちらも余計な遅延は生じていないことが一見して分かるようになっている。
これらの情報は、スレーブに対して行ったリード処理の所要時間をマスタ側で単に計測しただけでは得ることができない。特に、外部からの要因によって遅延が生じない場合の処理時間はスレーブ内部のみに保持されている情報であり、その情報を専用のインタフェースを用いることなく、既に用意されているトランザクションによって通信を行うポートを用いて取得している。
このように、トランザクションが到達する可能性のあるスレーブ全てにモニタを設置し、専用のインタフェースから情報を取得し、各モニタ間で情報の共有を行うといったような複雑な仕組みを用いることなく、トランザクションを受けた機能モジュールがそのトランザクションのアトリビュート情報を参照するだけで、スレーブ内部が保持する情報を取得することが可能となる。
以上に説明したように、実施例２によれば、バスを介して通信されるトランザクションに、ハードウェアの信号に相当することを示すハードウェアマッピングフラグと、ハードウェアの信号に無関係な情報を付加できるようにし、トランザクションを発行するモジュールにおいて情報を付加し、トランザクションを受信したモジュールにおいて付加情報を利用できるようにしたため、以下のような効果が得られる。
（１）機能モジュール内に保持されている情報を用いなければ取得できないような情報を得ることができ、それによりシステム設計者はシステムの性能解析及び検証の効率を大幅に向上させることが可能である。特に各機能モジュールが、他の機能モジュールから処理を依頼されてから完了するまでに費やされた待ち時間が、他の機能モジュールとの競合等によるものなのか、本来そのモジュールが最低限必要としているものなのかを容易に把握可能となり、設計者による性能解析の効率が向上する。
（２）バス及び機能モジュールに、必要な情報を取得するためのモニタ専用メソッドを用意することなく、既存のトランザクション操作メソッドを拡張することで、設計者がシミュレーション中のバス及び機能モジュール内の必要な情報を確認することが可能となる。また、これによってモニタ専用メソッドを呼ぶことによるイベントの増加、更にはシミュレーション速度の低下を避けることが可能となる。
（１）機能モジュール内に保持されている情報を用いなければ取得できないような情報を得ることができ、それによりシステム設計者はシステムの性能解析及び検証の効率を大幅に向上させることが可能である。特に各機能モジュールが、他の機能モジュールから処理を依頼されてから完了するまでに費やされた待ち時間が、他の機能モジュールとの競合等によるものなのか、本来そのモジュールが最低限必要としているものなのかを容易に把握可能となり、設計者による性能解析の効率が向上する。
（２）バス及び機能モジュールに、必要な情報を取得するためのモニタ専用メソッドを用意することなく、既存のトランザクション操作メソッドを拡張することで、設計者がシミュレーション中のバス及び機能モジュール内の必要な情報を確認することが可能となる。また、これによってモニタ専用メソッドを呼ぶことによるイベントの増加、更にはシミュレーション速度の低下を避けることが可能となる。
尚、本発明は複数の機器（例えば、ホストコンピュータ，インターフェース機器，リーダ，プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用しても良い。
また、本発明の目的は前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
この場合、記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
このプログラムコードを供給するための記録媒体としては、例えばフロッピー（登録商標）ディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
更に、記録媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
７００ アドレストランザクション
７０１ トランザクション発行時刻
７０２ トランザクション発行元モデル名称
７０３ トランザクション発行先モデル名称
７０４ リード／ライト
７０５ アドレス
７０６ ライトデータ
７０７ バイトイネーブル
７０９ ハードウェアマッピングフラグ
７１０ リードデータトランザクション
７１１ トランザクション発行時刻
７１２ トランザクション発行元モデル名称
７１３ トランザクション発行先モデル名称
７１４ リードデータ
７１９ ハードウェアマッピングフラグ
８０１ クロック生成器
８０２ 第１のマスタ
８０３ 第２のマスタ
８０４ 第１のスレーブ
８０５ 第２のスレーブ
８０６ バス
８０７ トランザクションポート
８０８ 信号ポート
９０１ トランザクション履歴
７０１ トランザクション発行時刻
７０２ トランザクション発行元モデル名称
７０３ トランザクション発行先モデル名称
７０４ リード／ライト
７０５ アドレス
７０６ ライトデータ
７０７ バイトイネーブル
７０９ ハードウェアマッピングフラグ
７１０ リードデータトランザクション
７１１ トランザクション発行時刻
７１２ トランザクション発行元モデル名称
７１３ トランザクション発行先モデル名称
７１４ リードデータ
７１９ ハードウェアマッピングフラグ
８０１ クロック生成器
８０２ 第１のマスタ
８０３ 第２のマスタ
８０４ 第１のスレーブ
８０５ 第２のスレーブ
８０６ バス
８０７ トランザクションポート
８０８ 信号ポート
９０１ トランザクション履歴
Claims (1)
- シミュレーション装置が、バス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーションモデルを用いたシミュレーションを実行することにより、マスタとして前記バスに接続する第１の機能モジュールがスレーブとして前記バスに接続する第２の機能モジュールにリードアクセスした場合のシミュレーション時間を前記第１の機能モジュールが取得するシミュレーション時間取得方法であって、
第１の発行手段が、前記第１の機能モジュールから前記第２の機能モジュールに対するリードアクセス要求に相当する第１のトランザクションに、ハードウェアにマッピングされる第１のアトリビュート情報としてアドレスの値を設定し、前記第１のトランザクションを前記バスに発行する工程を実行し、
第２の発行手段が、前記第２の機能モジュールが前記第１のアトリビュート情報として前記アドレスの値が設定された前記第１のトランザクションを前記バスから受け取り、該当するアドレスのデータを読み出して、前記第１のトランザクションに対するリードデータに相当する第２のトランザクションを前記バスに発行する工程を実行し、
前記第２の機能モジュールが前記第２のトランザクションを前記バスに発行する工程では、前記第２のトランザクションに、ハードウェアにマッピングしない第２のアトリビュート情報として、前記第２の機能モジュールが前記リードアクセス要求の処理を完了したシミュレーション時間と、遅延を生じる外部要因がない場合に前記処理を完了する時間とを設定し、
更に、
取得手段が、前記第１の機能モジュールが前記第２のトランザクションを前記バスから受け取り、前記第２のアトリビュート情報として前記第２のトランザクションに設定された前記シミュレーション時間と前記外部要因がない場合に前記処理を完了する時間を取得する工程を実行することを特徴とするシミュレーション時間取得方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004262953A JP4262174B2 (ja) | 2004-09-09 | 2004-09-09 | シミュレーション時間取得方法 |
| US11/221,686 US7865345B2 (en) | 2004-09-09 | 2005-09-08 | Simulation apparatus and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004262953A JP4262174B2 (ja) | 2004-09-09 | 2004-09-09 | シミュレーション時間取得方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2006079369A JP2006079369A (ja) | 2006-03-23 |
| JP4262174B2 true JP4262174B2 (ja) | 2009-05-13 |
Family
ID=35997331
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004262953A Expired - Fee Related JP4262174B2 (ja) | 2004-09-09 | 2004-09-09 | シミュレーション時間取得方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7865345B2 (ja) |
| JP (1) | JP4262174B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7453017B2 (ja) | 2020-02-25 | 2024-03-19 | アズビル株式会社 | 弁機構 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7778815B2 (en) * | 2005-05-26 | 2010-08-17 | The Regents Of The University Of California | Method for the fast exploration of bus-based communication architectures at the cycle-count-accurate-at-transaction-boundaries (CCATB) abstraction |
| US7673259B2 (en) * | 2005-12-30 | 2010-03-02 | Cadence Design Systems, Inc. | System and method for synthesis reuse |
| JP5034916B2 (ja) * | 2007-12-10 | 2012-09-26 | 富士通セミコンダクター株式会社 | 性能評価モデル生成方法、システム性能評価方法、及び性能評価モデル生成装置 |
| US8949545B2 (en) * | 2008-12-04 | 2015-02-03 | Freescale Semiconductor, Inc. | Memory interface device and methods thereof |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6151567A (en) * | 1994-05-27 | 2000-11-21 | Hamilton Sundstrand Corporation | Data communication analysis and simulation tool |
| EP0689141A3 (en) * | 1994-06-20 | 1997-10-15 | At & T Corp | Disruption-based hardware support for system performance profiling |
| US5958035A (en) * | 1997-07-31 | 1999-09-28 | Advanced Micro Devices, Inc. | State machine based bus cycle completion checking in a bus bridge verification system |
| JP3476665B2 (ja) * | 1997-11-13 | 2003-12-10 | 富士通株式会社 | 中継装置試験システム及び通信装置並びに通信方法 |
| US6434517B1 (en) * | 1998-12-04 | 2002-08-13 | Xilinx, Inc. | Method and system for demonstrating simulation of a communications bus |
| JP4475621B2 (ja) | 2001-04-18 | 2010-06-09 | キヤノン株式会社 | メモリ制御回路の論理検証装置及び方法 |
| JP2003015968A (ja) | 2001-06-29 | 2003-01-17 | Fujitsu Ltd | バスシミュレータ |
| US6807636B2 (en) * | 2002-02-13 | 2004-10-19 | Hitachi Computer Products (America), Inc. | Methods and apparatus for facilitating security in a network |
| US6845341B2 (en) * | 2002-05-14 | 2005-01-18 | Cadence Design Systems, Inc. | Method and mechanism for improved performance analysis in transaction level models |
| AU2003240948A1 (en) * | 2002-05-28 | 2003-12-12 | Cadence Design Systems, Inc. | Assertion-based transaction recording |
| JP2005108007A (ja) | 2003-09-30 | 2005-04-21 | Matsushita Electric Ind Co Ltd | Ｌｓｉ設計検証装置及びｌｓｉ設計検証方法 |
| US20070162475A1 (en) * | 2005-12-30 | 2007-07-12 | Intel Corporation | Method and apparatus for hardware-based dynamic escape detection in managed run-time environments |
-
2004
- 2004-09-09 JP JP2004262953A patent/JP4262174B2/ja not_active Expired - Fee Related
-
2005
- 2005-09-08 US US11/221,686 patent/US7865345B2/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7453017B2 (ja) | 2020-02-25 | 2024-03-19 | アズビル株式会社 | 弁機構 |
Also Published As
| Publication number | Publication date |
|---|---|
| US7865345B2 (en) | 2011-01-04 |
| JP2006079369A (ja) | 2006-03-23 |
| US20060052995A1 (en) | 2006-03-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7472361B2 (en) | System and method for generating a plurality of models at different levels of abstraction from a single master model | |
| KR102011092B1 (ko) | 프로그래머블 지연을 가진 동적 랜덤 액세스 메모리(dram) 명령을 생성하기 위한 메모리 물리 계층 인터페이스 로직 | |
| JP3131177B2 (ja) | エミュレーションとシミュレーションを用いた設計検証のための方法および装置 | |
| US6363509B1 (en) | Method and apparatus for transforming system simulation tests to test patterns for IC testers | |
| US7607116B2 (en) | Method and apparatus for verifying system-on-chip model | |
| US8868397B2 (en) | Transaction co-validation across abstraction layers | |
| US20080133206A1 (en) | Method of switching external models in an automated system-on-chip integrated circuit design verification system | |
| EP1447759A1 (en) | Generation of a testbench for a representation of a device | |
| US7865345B2 (en) | Simulation apparatus and method | |
| Hussien et al. | Development of a generic and a reconfigurable UVM-Based verification environment for SoC buses | |
| JP5034916B2 (ja) | 性能評価モデル生成方法、システム性能評価方法、及び性能評価モデル生成装置 | |
| US20050144436A1 (en) | Multitasking system level platform for HW/SW co-verification | |
| US7228513B2 (en) | Circuit operation verification device and method | |
| Pasricha et al. | Fast exploration of bus-based communication architectures at the CCATB abstraction | |
| US6543034B1 (en) | Multi-environment testing with a responder | |
| JP2007058431A (ja) | シミュレーションモデル、及びシミュレーション方法 | |
| CN1312583C (zh) | 仿真装置和仿真方法 | |
| JP2006221474A (ja) | シミュレーション装置及びその履歴情報記録方法 | |
| JP2005510787A5 (ja) | ||
| JP2006079370A (ja) | シミュレーション装置及びシミュレーション方法 | |
| JP5664430B2 (ja) | 試験装置、検証モデル開発方法及びプログラム | |
| US6983437B2 (en) | Timing verification, automated multicycle generation and verification | |
| US20070038431A1 (en) | Data processing apparatus simulation | |
| JP5001126B2 (ja) | ハードウェア検証用プログラミング記述生成装置、ハードウェア検証用プログラミング記述生成方法、制御プログラムおよび可読記録媒体 | |
| JP2006079464A (ja) | シミュレーション装置及びシミュレーション方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080801 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080925 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081110 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081224 |
|
| 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: 20090202 |
|
| 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: 20090206 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120220 Year of fee payment: 3 |
|
| 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: 20130220 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140220 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |