JP2007058431A - シミュレーションモデル、及びシミュレーション方法 - Google Patents

シミュレーションモデル、及びシミュレーション方法 Download PDF

Info

Publication number
JP2007058431A
JP2007058431A JP2005241342A JP2005241342A JP2007058431A JP 2007058431 A JP2007058431 A JP 2007058431A JP 2005241342 A JP2005241342 A JP 2005241342A JP 2005241342 A JP2005241342 A JP 2005241342A JP 2007058431 A JP2007058431 A JP 2007058431A
Authority
JP
Japan
Prior art keywords
error
attribute information
transaction
hardware
simulation
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.)
Withdrawn
Application number
JP2005241342A
Other languages
English (en)
Inventor
Amamitsu Sengoku
天光 千石
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2005241342A priority Critical patent/JP2007058431A/ja
Publication of JP2007058431A publication Critical patent/JP2007058431A/ja
Withdrawn legal-status Critical Current

Links

Images

Abstract

【課題】 エラー発生のタイミングや抽象化したエラー発生位置の指定等を、トランザクション付加属性として組み込み、エラーを発生するシミュレーションを実施することで，エラーに関する検証を容易化し効率を高めることを目的とする。
【解決手段】 システムのエラー生成を伴うシミュレーションにおいて、エラー発生指示が、シミュレーション時刻による指定や、プログラムのステップによるエラー発生指示といった方法でなく、特定のトランザクションの特定のフェーズでエラーを発行する、という様に、従来例より抽象度の高い指示を行うことができるシミュレーションモデル。
【選択図】 図７

Description

本発明は、論理回路から構成されるハードウェアシステムをシミュレーションするための、システム記述言語により高速シミュレーションが可能なモデルとして、高い抽象度で記述されたシミュレーションモデルに関する。
半導体のプロセス技術の進歩によりＬＳＩの集積度が増大し、これまでボードで実現していたシステムをシステムＬＳＩとして１チップ上に搭載することが可能となった。また、チップ上に搭載する機能モジュールも多様化し、回路規模が増大している。
これに伴い、システムＬＳＩを効率的に設計する手法として、従来のＶｅｒｉｌｏｇ−ＨＤＬやＶＨＤＬといった、ハードウェア記述言語を使用した設計から、ＳｙｓｔｅｍＣやＳｐｅｃＣといった、システム記述言語による設計が普及してきた。
システム記述言語による設計支援ツールとして、Ｓｙｎｏｐｓｙｓ社のＣｏＣｅｎｔｒｉｃや、ＣｏＷａｒｅ社のＣｏｎｖｅｒｇｅｎＳＣが知られている。システム記述言語により記述したモジュールを、ブロック図入力画面で入力し、システムＬＳＩの設計を行うことが可能になっている。
実際のハードウェアを作成する前に、シミュレーションによりシステムの評価を行うことにより、仕様の不具合や性能不足を回避することができる。また、システムＬＳＩの設計が終了すると、設計支援ツールからシミュレーションモデルを生成し、シミュレータを起動してシステムシミュレーションを行い、システムＬＳＩの機能や性能を確認することができる。
システム記述言語によるモジュール記述には、記述の抽象度により次の３種類の記述レベルが一般に知られている。
１．トランザクションレベル（ＴＬ）
モジュール間のバス通信を捉えて機能を記述する抽象度である。通信の開始および終了の時刻、通信データにより動作するため、クロックに対する精度は低い。イベントにより機能をシミュレートするため、シミュレーション速度は非常に速い。システムとしての動作が実際のハードウェアの動作と一致するため、システム全体の評価に適している。ＡＲＭ社による定義では、さらに細かく分類されておりＰＶ（プログラマーズビュー）、ＰＶＴ（プログラマーズビュー+タイミング）、ＣＬ（サイクルレベル）が相当する。
２．バスサイクルアキュレート（ＢＣＡ）
モジュールの入力と出力のイベントとして機能を記述する抽象度である。動作クロックに対し、入力および出力で正確にシミュレートすることができる。
ＡＲＭ社による定義では、ＣＣ（サイクルコーラブル）が相当する。
３．レジスタトランスファレベル（ＲＴＬ）
レジスタファイル間の同期転送を捉えて、回路を記述する抽象度である。動作クロックに対し、正確に機能動作をシミュレートすることができ精度が非常に高い。１クロックごとに機能をシミュレートするため、シミュレーション速度は非常に遅い。ＡＲＭ社による定義ではＲＴ（ＲＴＬイベントドリブン）が相当する。
一般に、抽象度が高いほど、シミュレーション速度は速く、抽象度が低いほどシミュレーション精度は高くなる。
システムのシミュレーションを行うためのシミュレーションモデルは、トランザクションレベルにより記述される。トランザクションレベルによるシミュレーションモデルとして、ＡＲＭ社により公開されているＡＭＢＡバスモデルが広く知られている。（ＡＭＢＡ ＡＨＢ Ｃｙｃｌｅ Ｌｅｖｅｌ Ｉｎｔｅｒｆａｃｅ（ＡＨＢ ＣＬＩ）Ｓｐｅｃｉｆｉｃａｔｉｏｎ、２００３年７月１５日公開）
図１にＡＨＢ ＣＬＩで定義されているバスのトランザクションを示す。これらのトランザクションのメソッドは、ＡＭＢＡ ＡＨＢプロトコルで規定されたハードウェア信号に対応する。図２に各メソッドと信号の対応を示す。アトリビュートおよびメソッドが、少なくとも１つのハードウェア信号に対応する。
これらのメソッドを使用し、バスの動作をシミュレートすることが可能である。
図３の波形と、図４の各シミュレーション時刻でのメソッド呼び出しの様子から、バスの動作シミュレーションの方法を説明する。
時刻Ｔ１において、マスタ１がバス使用要求信号信号（バスリクエスト）を発行する。このときマスタ１はrequest()メソッドを起動する。これは、HBUSREQ_M1信号のアサートに相当する。また、バスはアービタに対し、アービトレーションを開始させる（arbitrate()）。また、バスからマスタに対し、response()[OKAY，READY]メソッドが発行される。これは、HREADYおよびHRESP信号に相当する。
時刻Ｔ２において、マスタ２がバス使用要求（バスリクエスト）を発行する（request()）。これは、HBUSREQ_M2信号のアサートに相当する。同時に、バスからマスタ1に対し、グラントが与えられる(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()）。
時刻Ｔ６で、バスはマスタ2に対しグラントを与える(arbitrate()[grant M2])。
時刻Ｔ７でマスタ２は、グラントを検知しバスアクセスを開始する。
このように、各トランザクションメソッドは、ハードウェア信号の挙動と同じ挙動を生成する機能を有しており、メソッドおよびアトリビュートはハードウェア信号にマッピングできるものであることがわかる。
ＡＨＢ ＣＬＩでは、トランザクションメソッドの他に、バスのコンフィギュレーションを変更するためのメソッドが用意されている。このメソッドにより、バスのアドレス幅、データ幅、アドレスマップを変更することが可能である。
図５にバスコンフィギュレーションメソッドを示す。シミュレータがシミュレーション実行前に、システムモデルを読み込む（エラボレーション）時に作動するメソッドと、シミュレーション実行時に作動するメソッドに分けられる。シミュレーション実行中にバスのコンフィギュレーションを変更するメソッドは、デコーダのinitialize_map()とアービタのpriority()、set_default_master()である。
これらは、ハードウェアの信号動作に関係しており、initialize_map()はremap信号動作に、priority()、set_dafulat_master()はアービタ内のレジスタアクセス信号動作に相当する。
また、ＡＨＢ ＣＬＩには、検証目的で使用するメソッドが用意されている。ハードウェアの検証に一般的に使用されているバックドア機能に対応するメソッドである。バスのプロトコルとは無関係に、指定したアドレスのデータを直接読み書きすることが可能である。
図６にこれらのメソッドを示す。マスタが使用する引数はアドレス、データへのポインタ、転送サイズの３つであり、ハードウェアと関連したものである。スレーブが使用する引数は、マスタＩＤ、アドレス、データへのポインタ、転送サイズの４つであり、これらもハードウェアと関連したものである。
次に、従来の技術における実施例について、図を用いて説明する。
図８は、従来の技術におけるシミュレーションモデルにより、１回のトランザクションとエラーの発行についてシミュレーションを実施する例である。また、図１０は従来の技術におけるシミュレーションモデルの一部であるテストシナリオの例である。左記テストシナリオは、複数のトランザクションの定義とエラー生成指示を含む。シミュレーションが始まると、トランザクションおよびエラー生成手段（８０４）が、左記テストシナリオを、トランザクションＡ，Ｂ，Ｃの順に読み込み、それぞれのトランザクションについて、図８に示した構成でシミュレーションを実施する。
まず、従来の技術における実施例の構成（図８）を説明する。
図８において、テストシナリオ保有手段（８０１）は、１トランザクションのアトリビュート情報として、生成トランザクション定義、エラー生成定義、生成エラー定義（８０２）を持つ。
エラー生成定義は、エラーが生成するタイミングの定義であり、シミュレーションのステータスを必要とするために、モニタが必要である。
生成エラー定義は、エラーを生成する位置等の定義である。
ハードウェアにマッピングするアトリビュート情報は、発行するトランザクションのアトリビュート情報である、マスタ名、スレーブ名、バーストタイプ、データサイズ、リード／ライト（トランザクションの方向）、トランザクションの先頭アドレス、データ値等をアトリビュート情報として持つ。
シミュレーションが始まると、トランザクションおよびエラー生成発行手段（８０４）は、テストシナリオ保有手段（８０１）から１トランザクション分のアトリビュート情報（８０２）を読み込み（８０３）、モニタ（８１６）から得られるシミュレーションのステータスやアトリビュート情報（８０２）をもとに、発行すべきトランザクションとエラーを構築し、必要なアトリビュート情報を、所定のタイミングで所定の対象に対して設定し、トランザクションとエラーを発行する。図中、トランザクションとエラーは、バス（８１０）への設定（８０６）と、マスタモジュール（８１３）への設定（８０７）と、スレーブモジュール（８１４）への設定（８０８）と、メモリモジュール（８１５）への設定（８０９）の後、トランザクション（８１１）を発行する。シミュレーションは、クロック生成器（８０５）が発行するクロックに同期させるため、サイクル精度のシミュレーションが実施される。
次に、従来の技術における実施例の構成（図８）を利用した、従来の技術における実施例のエラー生成、発行を含む、テストシナリオ（図１０）を用いたシミュレーションについて説明する。テストシナリオは、トランザクションＡ、Ｂ、Ｃをアトリビュート情報のセットによって定義している。トランザクションＡ、Ｂは、エラーを生成しないトランザクションである。一方、トランザクションＣは、通常のトランザクションのアトリビュート情報のほかに、エラーを生成、発行するためのアトリビュート情報を定義している。生成、発行するエラーは次のアトリビュート情報によって定義される。
エラー位置：3 rd transfer
エラーアドレス：0x4000_----
４ビートバーストの、第３の転送で、アクセスが禁止されている領域（0x4000_0000〜0x4FFF_FFFF）へアクセスし、エラーを発生させる設定である。本テストは、４ビートバーストの第３の転送のタイミングを知るためのモニタを作成する。
また、シミュレーションのステータスとして、warningレベルの上記エラーの発生を禁止するフラグがアクティブである場合、フラグのモニタを作成し、左記モニタから得た情報をもとに、エラーの発行を中断する。
また、エラーが発行されるとき、エラー処理として、デフォルトスレーブの起動が期待されるので、関連するモニタでエラー処理を観測する場合、デフォルトスレーブ観測モニタを、シミュレーションの開始時から接続して観測を続けるか、あるいは、デフォルトスレーブが起動することを示す情報を、バスを観測するモニタから得て、デフォルトスレーブモニタを起動する。
従来の技術によれば、あるトランザクションでエラーを起こす検証を実施するときには、まず、テストシナリオにエラー発生指示命令を記述してから、シミュレーションにより転送を開始し、シミュレーションが、テストシナリオのエラー発生支持記述部に到達した時にエラーが発生し、所望の検証を実現する。この時、エラーを生成するタイミングを決定する方法は、テストシナリオでエラーを生成するイベントを発行するシミュレーション時刻を設定する方法や、シミュレーション中のシステムのステータスを条件として発行タイミングを決定する方法がある。
前者は、検証対象であるバスの状態数は一般的に膨大であるので、エラーを生成する時刻をダイレクトにテストシナリオ内で指定する方法は、エラー生成を伴う検証においては有効ではない。
一方後者は、エラー発行のタイミングを、システムのステータスから決定するため、膨大なシステムの状態の中で、システムがある特定の状態になった時を狙って、エラーを生成することができ、エラー生成を伴う検証では有効な方法であり、該方法がエラーを伴う検証に利用されている。
しかしながら、該方法では、エラー生成タイミングを決定するために、システムのステータスを把握するためのモニタと、そのステータスの条件の組み合わせ（以下、モニタとエラー生成条件）を定義する必要があり、これが非常に手間のかかるものであった。
モニタとエラー生成条件の設定は検証の抽象度や言語の異なるツールごとに発生するので、例えば、トランザクションレベル、ＲＴＬの両段階で必要な作業であり、二度手間になるという問題もある。
また、一般にモニタはそれ自体が一つのモジュールとして実装されるが、モニタの対象とする情報の解析に機能モジュールのみが保持している情報を必要とする場合がある。例えば、バスモデルは内部にアドレスデコーダの機能が含まれるが、アドレスマップの情報は外側からトランザクションを観測しても取得することはできない。このような場合には、機能モジュールとモニタの間で情報の共有を必要とし、このようなモニタを実装することは非常に手間がかかる。
また、トランザクションレベルでは、各モジュールのメソッドと呼ばれる関数を呼び出すことによりトランザクションが発行されるため、容易にモニタを作成することができない。ＡＨＢ ＣＬＩではモニタのためのメソッドが用意されているが、他のモデルは、モニタ用のメソッドが用意されていないことがほとんどである。
ＡＨＢ ＣＬＩのモニタのためのメソッドは、信号レベルと準信号レベルでＡＨＢの挙動を観測することができる。信号レベルでは、マスタ、スレーブ、バスがドライブする各信号を見る手段が用意されていて、準信号レベルでは、トランザクションの各タイプ、例えば、responseの各状態[OKAY,ERROR,RETRY,SPLIT]を観測するメソッドが容易されている。しかし、バスのステータスから、エラー発行タイミングを決定する条件は定義しなければならない。
また、ＡＨＢ ＣＬＩのように、検証用のメソッドが定義されていることもあるが、実際のハードウェア動作のシミュレーション実行中に、シミュレーション結果に影響を及ぼさないようにメソッドを呼び出す必要があり、これらのメソッドを使用して検証を行うのは手間がかかるものである。また、メソッドを多用し検証を行うことは、シミュレーション時のイベントの増加を招き、シミュレーション速度への影響が大きくなり、結果的にシミュレーション速度を低下させるものであった。
検証にメソッドを使わない方法として、各モジュールのトランザクション情報を波形としてダンプし、観測する方法が知られているが、システムの膨大なシミュレーション結果を波形により検証するのはほぼ不可能に近い状況であった。また、波形情報をファイルに保持していくためには、膨大なディスク容量を必要とし、長い時間シミュレーションを実行させることが困難であるという問題もあった。
近年のシステムＬＳＩの大規模化、高機能化により、システム内部に存在する機能モジュールの数、バスの本数は増大している。このような複雑なシステムを性能解析及び検証するには、上で挙げた従来の手法では非常に困難である。
本発明は上記問題点を解決するためになされたもので、トランザクションレベルのシミュレーションモデルにおいて、大規模且つ複雑なシステムに対応する性能解析及び検証を容易に行う方法を提供することを目的とする。
上記課題を解決するための本発明によるシミュレーションモデルは、トランザクションとシステムのエラーに関する、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有する、エラーに関するアトリビュート情報保有手段と、
トランザクションに関し、かつシステムのエラーに関しない、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有する、エラーに関しないアトリビュート情報保有手段と、
前記エラーに関するアトリビュート情報保有手段とエラーに関しないアトリビュート情報保有手段が保有するアトリビュート情報を基にして、トランザクションとエラーを生成し発行するトランザクションおよびエラー生成発行手段とを備える。
また、上記課題を解決するための本発明によるシミュレーション方法は、
トランザクションとシステムのエラーに関する、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有する、エラーに関するアトリビュート情報保有ステップと、
トランザクションに関し、かつシステムのエラーに関しない、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有する、エラーに関しないアトリビュート情報保有ステップと、
前記エラーに関するアトリビュート情報保有ステップとエラーに関しないアトリビュート情報保有ステップが保有するアトリビュート情報を基にして、トランザクションとエラーを生成し発行するトランザクションおよびエラー生成発行ステップとを備える。
以上、説明したように本発明の実施例によれば、バスを介して通信されるトランザクションに、ハードウェアにマッピングするか否かを示すハードウェアマッピングフラグを設け、ハードウェアにマッピングしないアトリビュート情報の付加を可能とし、生成時にハードウェアにマッピングしないアトリビュート情報を付加したトランザクションを発行し、トランザクションを受信したモジュールにおいてハードウェアにマッピングしないアトリビュート情報を利用できるようにしたため以下のような効果が得られる。
１．システムのエラー生成を伴うシミュレーションにおいて、エラー発生指示が、シミュレーション時刻による指定や、プログラムのステップによるエラー発生指示といった方法でなく、特定のトランザクションの特定のフェーズでエラーを発行する、という様に、従来例より抽象度の高い指示を行うことができる。このため、シミュレーションにおけるデバッグや性能検証、機能検証にかかる時間の短縮が可能である。
２．バス及び機能モジュール内に保持されている情報を用いなければ発見できないような間違いについて、バスモニタを一切使うこと無く、シミュレーション中に動的に発見することが可能であるから、検証時間の短縮が可能となる。
３．バス及び機能モジュールに、必要な情報を取得するためのモニタ専用メソッドを用意することなく、既存のトランザクション操作メソッドを拡張することで、設計者がシミュレーション中のバス及び機能モジュール内の状況や、既に発行したトランザクションの履歴を参照することが可能となる。また、これによってモニタ専用メソッドを呼ぶことによるイベントの増加、ひいてはシミュレーション速度の低下を避けることが可能となる。
４．バス及び機能モジュールが、トランザクション処理と同時にその内部の情報を利用してエラーチェック等の処理を行うことができ、シミュレーション後ではなくシミュレーション中に動的にそれらの情報を設計者に通知することが可能となる。また、これによってエラー発生後の無駄なシミュレーション実行を回避し、設計時間の短縮が可能となる。
５．バス及び機能モジュールの観測機能の設定を、実行時間による指定やプログラムのステップによる指示といった方法でなく、特定のトランザクションが特定の位置に転送されたときという様な、より詳細な指示が行えるようになる。このため、シミュレーションにおけるデバッグや機能検証作業にかかる時間を短縮することが可能である。
次に、本発明における実施例を、図面を用いて説明する。
図７は、本発明のシミュレーションモデルにより、１回のトランザクションとエラーの発行についてシミュレーションを実施する例である。また、図９は本発明のシミュレーションモデルの一部であるテストシナリオの例である。左記テストシナリオは、複数のトランザクションの定義とエラー生成指示を含む。シミュレーションが始まると、トランザクションおよびエラー生成手段（７０８）が、左記テストシナリオを、トランザクションＡ，Ｂ，Ｃの順に読み込み、それぞれのトランザクションについて、図７に示した構成でシミュレーションを実施する。
まず、本発明における実施例の構成（図７）を説明する。
図７において、テストシナリオ（７００）は、１トランザクションのアトリビュート情報について、エラーに関するもの（７０１）とエラーに関しないもの（７０２）を持つ。
エラーに関するトランザクションのアトリビュート情報は、エラー発生指示の内容として、エラーの順序や、エラーを生成させるソフトウェアやハードウェアと、エラーを関連付けるためのエラーＩＤ、プロトコルエラー・アクセス（アドレス）エラー・ショート／オープンエラー・オーバー／アンダーフロー・タイムアウト・コンペアエラー等のエラー種類、無視可能・注意・警告・致命的等のエラーレベル、エラーを発生させる時刻やサイクル、また、システムの機能ブロックやバスの中のエラー位置、エラー発生時に起動するエラーに関連するモジュール（例えば、デフォルトスレーブ、エラー発生位置のモニタ）、
アクセス（アドレス）エラーを生成するためのアドレスマップ等をアトリビュート情報として持つ。
エラーに関しないトランザクションのアトリビュート情報は、発行するトランザクションの構成として、ハードウェアにマッピングするものとしては、発行するトランザクションのアトリビュート情報である、マスタ名、スレーブ名、バーストタイプ、データサイズ、リード／ライト（トランザクションの方向）、トランザクションの先頭アドレス、データ値等をアトリビュート情報として持つ。
シミュレーションが始まると、トランザクションおよびエラー生成発行手段（７０８）は、テストシナリオ（７００）から１トランザクション分のアトリビュート情報（７０１）と（７０２）を読み込み、シミュレーションのステータスやアトリビュート情報をもとに、発行すべきトランザクションとエラーを構築し、必要なアトリビュート情報を、所定のタイミングで所定の対象に対して設定し、トランザクションとエラーを発行する。図中、トランザクションとエラーは、バス（７１３）への設定（７０９）と、マスタモジュール（７１４）への設定（７１０）と、スレーブモジュール（７１５）への設定（７１１）と、メモリモジュール（７１６）への設定（７１２）の後、トランザクション（７１７）を発行する。シミュレーションは、クロック生成器（７１８）が発行するクロックに同期させるため、サイクル精度のシミュレーションが実施される。
次に、本発明の実施例の構成（図７）を利用した、本発明の実施例のエラー生成シナリオ（図９）を用いたシミュレーションについて説明する。
テストシナリオは、トランザクションＡ、Ｂ、Ｃをアトリビュート情報のセットによって定義している。トランザクションＡ、Ｂは、エラーを生成しないトランザクションであるため、それぞれについて、エラーに関するアトリビュート情報は空欄である。一方、トランザクションＣでは、エラーを発行するためのアトリビュートを定義している。発行するエラーは次のアトリビュート情報によって定義される。
エラーＩＤ：1
エラー種類：access_error_1
エラーレベル：warning
エラー位置：3 rd transfer
処理モジュール：Default Slave
エラーアドレス：0x4000_----
４ビートバーストの、第３の転送で、アクセスが禁止されている領域（0x4000_0000〜0x4FFF_FFFF）へアクセスし、エラーを発生させる設定である。ただし、シミュレーションのステータスとして、warningレベルのエラーの発生を禁止するフラグがアクティブである場合、本エラーは発行されない。エラーが発行されるとき、エラー処理として、デフォルトスレーブの起動が期待されるので、関連するモニタがエラー処理時に接続するために、処理モジュール（Default Slave）を設定する。トランザクションＡと、トランザクションＣは、ハードウェアにマッピングされるアトリビュート情報は同一であるが、ハードウェアにマッピングしないアトリビュート情報について差異がある。仮に、ハードウェアにマッピングしないエラーに関するアトリビュート情報を持たない従来の方法で、同様のエラーを生成、発行するシミュレーションを実行するならば、トランザクションＡとトランザクションＣの区別はハードウェアにマッピングするアトリビュート情報からは区別することができないため、両トランザクションを区別するためのモニタを作成する必要がある。
従来技術のトランザクションメソッド例を示す図。 従来技術のトランザクションメソッド及びアトリビュートとハードウェアの対応を示す図。 従来技術のトランザクションメソッドと信号波形を示す図。 従来技術のトランザクションメソッドを用いたシミュレーションを説明する図。 従来技術のハードウェアコンフィギュレーションメソッドを示す図。 従来技術の検証メソッドを示す図。 本発明の実施例の構成を示す図。 従来技術の構成例と従来技術を適用するシステム例を示す図。 本発明の実施例のエラー生成シナリオを示す図。 本発明の実施例のエラー生成シナリオを示す図。
符号の説明
（７００） １トランザクションのアトリビュート情報を定義したパケット
（７０１） エラーに関するトランザクションのアトリビュート保有手段
（７０２） エラーに関しないトランザクションのアトリビュート保有手段
（７０３） トランザクションのアトリビュート情報
（７０４） アトリビュート情報をハードウェアへマッピングするか否かを示す属性
（７０５） アトリビュート情報をハードウェアへマッピングすることを示すフラグ
（７０６） エラーに関するハードウェアにマッピングしないアトリビュート情報
（７０７） トランザクション生成手段がパケットを読み込む
（７０８） トランザクション生成手段
（７０９） バスにエラー生成
（７１０） マスタへ定義されたアトリビュート情報でトランザクション生成
（７１１） スレーブへ定義されたアトリビュート情報でトランザクション生成
（７１２） メモリモジュールにエラー生成
（７１３） バス
（７１４） マスタモジュール
（７１５） スレーブモジュール
（７１６） メモリモジュール
（７１７） マスタ，スレーブ，メモリモジュールがバスに生成するトランザクション
（７１８） クロック生成器
（８０１） テストシナリオ保有手段
（８０２） トランザクションとエラー定義
（８０３） トランザクションおよびエラー生成手段の、パケット（テストシナリオ）読み込み
（８０４） トランザクションおよびエラー生成手段
（８０５） クロック生成器
（８０６） バスにエラー生成
（８０７） マスタへ定義されたアトリビュート情報でトランザクション生成
（８０８） スレーブへ定義されたアトリビュート情報でトランザクション生成
（８０９） メモリモジュールにエラー生成
（８１０） バス
（８１１） マスタ，スレーブ，メモリモジュールがバスに生成するトランザクション
（８１２） マスタ，スレーブ，メモリモジュール，バスの状況を観測する
（８１３） マスタモジュール
（８１４） スレーブモジュール
（８１５） メモリモジュール
（８１６） モニタ
（８１７） 測定値をトランザクションおよびエラー生成手段へ渡す

Claims (10)

  1. システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーションモデルにおいて、
    トランザクションとシステムのエラーに関する、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有するエラーに関するアトリビュート情報保有手段と、
    トランザクションに関し、かつシステムのエラーに関しない、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有するエラーに関しないアトリビュート情報保有手段と、
    前記エラーに関するアトリビュート情報保有手段とエラーに関しないアトリビュート情報保有手段が保有するアトリビュート情報を基にして、トランザクションとエラーを生成し発行するトランザクションおよびエラー生成発行手段と
    を備える、シミュレーションモデル。
  2. 前記エラーに関するアトリビュート情報保有手段において、ハードウェアにマッピングしないアトリビュート情報として、エラーＩＤ、エラーの種類、エラーの重要度、エラーを発生させるモジュール内の位置、エラー処理の期待値、エラーメッセージ、エラー発生時刻を含み、ハードウェアにマッピングするアトリビュート情報として、エラーを生成するトランザクション生成情報を含むことを特徴とする請求項１に記載のシミュレーションモデル。
  3. 前記トランザクションおよびエラー生成発行手段において、前記エラーに関するアトリビュート情報保有手段と前記エラーに関しないアトリビュート情報保有手段が有するアトリビュート情報とシミュレーションのステータス情報を蓄積して、その情報を利用可能とすることを特徴とする請求項１に記載のシミュレーションモデル。
  4. 前記トランザクションおよびエラー生成発行手段において、前記エラーに関するアトリビュート情報保有手段と前記エラーに関しないアトリビュート情報保有手段が有するアトリビュート情報と前記アトリビュート情報とステータスの蓄積データを加工して、トランザクションやエラーを生成し発行することを特徴とする請求項１に記載のシミュレーションモデル。
  5. 前記トランザクションおよびエラー生成手段において、シミュレーションのステータスと、前記アトリビュート情報保有手段が有するアトリビュート情報と前記アトリビュート情報とステータスの蓄積データに応じて、前記アトリビュート情報保有手段が有するアトリビュート情報を変更し、かつトランザクションやエラーに反映するか否か判定することを特徴とする請求項１に記載のシミュレーションモデル。
  6. システム記述言語によりバス上の通信をトランザクションにより行うトランザクションレベルで記述されたシミュレーション方法において、
    トランザクションとシステムのエラーに関する、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有する、エラーに関するアトリビュート情報保有ステップと、
    トランザクションに関し、かつシステムのエラーに関しない、ハードウェアにマッピングするアトリビュート情報と、ハードウェアにマッピングしないアトリビュート情報とを有し、かつ前記アトリビュート情報をハードウェアにマッピングするかどうかを識別するためのフラグを有する、エラーに関しないアトリビュート情報保有ステップと、
    前記エラーに関するアトリビュート情報保有ステップとエラーに関しないアトリビュート情報保有ステップが保有するアトリビュート情報を基にして、トランザクションとエラーを生成し発行するトランザクションおよびエラー生成発行ステップとを備える、シミュレーション方法。
  7. 前記エラーに関するアトリビュート情報保有ステップにおいて、ハードウェアにマッピングしないアトリビュート情報として、エラーＩＤ、エラーの種類、エラーの重要度、エラーを発生させるモジュール内の位置、エラー処理の期待値、エラーメッセージ、エラー発生時刻を含み、ハードウェアにマッピングするアトリビュート情報として、エラーを生成するトランザクション生成情報を含むことを特徴とする請求項６に記載のシミュレーション方法。
  8. 前記トランザクションおよびエラー生成発行ステップにおいて、前記エラーに関するアトリビュート情報保有ステップと前記エラーに関しないアトリビュート情報保有ステップが有するアトリビュート情報とシミュレーションのステータス情報を蓄積して、その情報を利用可能とすることを特徴とする請求項６に記載のシミュレーション方法。
  9. 前記トランザクションおよびエラー生成発行ステップにおいて、前記エラーに関するアトリビュート情報保有ステップと前記エラーに関しないアトリビュート情報保有ステップが有するアトリビュート情報を加工して、トランザクションやエラーを生成し発行することを特徴とする請求項６に記載のシミュレーション方法。
  10. 前記トランザクションおよびエラー生成ステップにおいて、シミュレーションのステータスと、前記アトリビュート情報保有ステップが有するアトリビュート情報に応じて、前記アトリビュート情報保有ステップが有するアトリビュート情報を変更し、かつトランザクションやエラーに反映するか否か判定することを特徴とする請求項６に記載のシミュレーション方法。
JP2005241342A 2005-08-23 2005-08-23 シミュレーションモデル、及びシミュレーション方法 Withdrawn JP2007058431A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005241342A JP2007058431A (ja) 2005-08-23 2005-08-23 シミュレーションモデル、及びシミュレーション方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005241342A JP2007058431A (ja) 2005-08-23 2005-08-23 シミュレーションモデル、及びシミュレーション方法

Publications (1)

Publication Number Publication Date
JP2007058431A true JP2007058431A (ja) 2007-03-08

Family

ID=37921901

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005241342A Withdrawn JP2007058431A (ja) 2005-08-23 2005-08-23 シミュレーションモデル、及びシミュレーション方法

Country Status (1)

Country Link
JP (1) JP2007058431A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009009270A (ja) * 2007-06-27 2009-01-15 Nec Electronics Corp 論理検証装置、論理検証方法
JP2009093491A (ja) * 2007-10-10 2009-04-30 Fujitsu Ltd 検証シナリオ作成プログラム、該プログラムを記録した記録媒体、検証シナリオ作成装置、および検証シナリオ作成方法
CN115510782A (zh) * 2022-08-31 2022-12-23 芯华章科技股份有限公司 定位验证错误的方法、电子设备和存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009009270A (ja) * 2007-06-27 2009-01-15 Nec Electronics Corp 論理検証装置、論理検証方法
JP2009093491A (ja) * 2007-10-10 2009-04-30 Fujitsu Ltd 検証シナリオ作成プログラム、該プログラムを記録した記録媒体、検証シナリオ作成装置、および検証シナリオ作成方法
CN115510782A (zh) * 2022-08-31 2022-12-23 芯华章科技股份有限公司 定位验证错误的方法、电子设备和存储介质
CN115510782B (zh) * 2022-08-31 2024-04-26 芯华章科技股份有限公司 定位验证错误的方法、电子设备和存储介质

Similar Documents

Publication Publication Date Title
US8020124B2 (en) Various methods and apparatuses for cycle accurate C-models of components
JP3131177B2 (ja) エミュレーションとシミュレーションを用いた設計検証のための方法および装置
US7917348B2 (en) Method of switching external models in an automated system-on-chip integrated circuit design verification system
US7607116B2 (en) Method and apparatus for verifying system-on-chip model
US6571204B1 (en) Bus modeling language generator
Mahadevan et al. Network traffic generator model for fast network-on-chip simulation
US7584456B1 (en) Method and apparatus for debugging embedded systems having read only memory
JP2017523488A (ja) メモリ物理層インタフェースのトレーニング用統合型コントローラ
EP3369015B1 (en) Methods and circuits for debugging circuit designs
US8000950B2 (en) Random initialization of latches in an integrated circuit design for simulation
US10664563B2 (en) Concurrent testbench and software driven verification
GB2450130A (en) An Apparatus for Performing Verification of the Design of a Data Processing System using Alternative Hardware Components
US7865345B2 (en) Simulation apparatus and method
JP2007058431A (ja) シミュレーションモデル、及びシミュレーション方法
WO2024046362A1 (zh) 验证系统、验证方法、电子设备以及存储介质
US9864830B1 (en) Method and apparatus for placement and routing of circuit designs
Ghosh et al. Case Study: SoC Performance Verification and Static Verification of RTL Parameters
Kim et al. Fast and accurate transaction level modeling of an extended AMBA2. 0 bus architecture
Lin et al. AMBA AHB bus potocol checker with efficient debugging mechanism
Carbognani et al. Qualifying precision of abstract systemc models using the systemc verification standard
Rust et al. From high-level Petri nets to SystemC
US11295052B1 (en) Time correlation in hybrid emulation system
US7505887B1 (en) Building a simulation of design block using a bus functional model and an HDL testbench
JP2007052783A (ja) データ処理装置のシミュレーション
Kommineni et al. Design & verification of AMBA AHB-Lite memory controller

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20081104