JP4112886B2 - デバイスのバス・プロトコル準拠試験方法およびシステム - Google Patents
デバイスのバス・プロトコル準拠試験方法およびシステム Download PDFInfo
- Publication number
- JP4112886B2 JP4112886B2 JP2002098913A JP2002098913A JP4112886B2 JP 4112886 B2 JP4112886 B2 JP 4112886B2 JP 2002098913 A JP2002098913 A JP 2002098913A JP 2002098913 A JP2002098913 A JP 2002098913A JP 4112886 B2 JP4112886 B2 JP 4112886B2
- Authority
- JP
- Japan
- Prior art keywords
- test
- bus
- compliance
- configuration file
- protocol
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はデバイスのバス・プロトコル準拠を試験するための方法およびシステムに関する。
【０００２】
【従来の技術】
システムに統合するための部品を開発する場合、その部品がシステムに統合されたときに所定の動作をするかどうかを確認するために複数の試験手順が実行されるのが普通である。しばしばシステムは１以上のバスを介して互いに接続された複数個の個別部品で構成される。バス仕様が各部品に標準インタフェースを提供することによって、部品供給業者はその部品を最終的に統合するシステムに関する知識なしでもその部品を設計および試験できる場合が多い。
【０００３】
しかし、システム内で特別なバス仕様に従うバスへ接続する部品を開発する場合には、その部品が、その定義されたバス仕様に従うそのバスとインタフェースすることをチェックする必要があるのは明らかである。
【０００４】
ハード的な部品開発は複数の段階を経て行なわれるのが一般的である。まず最初に、その部品の機能的な動作／ビヘイビアが、例えばレジスタ・トランスファ・ランゲージ（ＲＴＬ）を使用して定義される。広く用いられる２つのＲＴＬはＶＨＤＬおよびＶｅｒｉｌｏｇである。更に、そのようなＲＴＬコーディングの前に、設計意図が正しいことをトランザクション・レベルで検証するために、ＵＭＬ（ユニバーサル・モデリング・ランゲージ）を用いてビヘイビア・モデルを構築しても良い。
【０００５】
一旦ハードウエア部品のＲＴＬ表現が開発されれば、次にこれを複数個の既知の合成ツールの任意のものを用いて一連のハードウエア要素の形に合成する。次に、この合成で得られるハードウエア設計を用いて、例えばシリコン上へ部品を適切に作製することによって実際のハードウエア部品が作製される。部品が実際にハードウエアの形に実現された後でその部品に対して試験手順を施すのは明らかにコストを要するので、その代わりに、ＲＴＬ表現から生成される実際のハードウエアが正しく動作することを確認するために、部品のＲＴＬ表現に対して厳格な試験を行なうのが一般的である。
【０００６】
従って、１つの部品が既知のバス仕様と正しくインタフェースすることをチェックするプロセスが部品のＲＴＬ表現に対して適用され、それがバス仕様に定義されたバス・プロトコルに従っていることをチェックするようになっている。そのようなプロトコル・チェックを実行する複数の方法が知られている。
【０００７】
まず、その中に被験デバイス（ＤＵＴ）と呼ぶ試験すべき部品のＲＴＬ表現を含むＲＴＬテストベンチを生成することができる。次に、その他のデバイスのＲＴＬ表現も準備され、バスを介してＤＵＴのＲＴＬ表現と互いにつながれてＲＴＬテストベンチ内にシステム・シミュレーションが生成される。次に、１つのデバイスから別のデバイスへスティミュラスが与えられて、その結果の波形が目で見える形で観測されるか、あるいはシステム・シミュレーションに統合される自己点検機構またはモジュールによって観測される。このプロセスはバス・プロトコルで定義されたトランザクションをチェックできるし、また一般的にすべてのバス・プロトコル・トランザクションが正しく記録されるまでそのチェックを徹底的に繰り返すことができる。
【０００８】
上で述べたＲＴＬテストベンチでバス・プロトコル準拠をチェックするために利用できる別の方法は、ＲＴＬで精巧なバス・フォロワを構築し、次にバス・トラフィックをモニタすることによってバス・フォロワ内部のステート・マシンが任意の有効なポイントにおいて実際のシステム・シミュレーションで観測されるものと合致することを確認するものである。
【０００９】
準拠性をチェックする別の代替法はインテグレーション試験コードを使用するもので、マスタ・デバイスに対してスレーブ・デバイスへのバス上で読出しおよび書込みトランザクションを実行させ、次に目標データが正しく読出しおよび／または書込みされたことをチェックするものである。マスタ・デバイスはバスを介してトランスファ要求を発行するように設計されたデバイスであると考えることができ、またスレーブ・デバイスはそのようなトランスファ要求の受け手のデバイスであると考えることができる。一例として、プロセッサ・コアはマスタ・デバイスとして使用され、メモリからインテグレーション試験コードを読み出すように、またその後でバス・プロトコル準拠性をチェックするために予め定められた一連の読出しおよび書込みトランザクションを実行する試験コードを実行するように構成することができる。そのようなコード・シーケンスはデバイス間の調停を引き起こし、またバス・プロトコルのその他の仕様をチェックするためにデバイスからの特定の応答を誘発するためにも実行することができる。このやり方は、一般に比較的低速であること、またバス・プロトコルを直接的にモニタせずに、バスを介して誘発されたアクションの結果をモニタすることでバス・プロトコル準拠性について仮定する点で既に述べた２つの方法に比べて満足度は劣る。それにも拘らず、このやり方はバス上でのデバイス相互接続を試験する形式として現在でも使用されている。
【００１０】
先に述べたＲＴＬテストベンチ方式の代わりに使用できるプロトコル・チェックを実行する別の既知の方法は、例えばＶｅｒａまたはＳｐｅｃｍａｎのようなＨＶＬ（ハイレベル・ベリフィケーション・ランゲージ）開発ツールを使用してアブストラクト・レベルでバス・トランザクションをモニタするものである。システム・シミュレーション中の各デバイスのＲＴＬ表現を生成する代わりに、それをＲＴＬで書き下ろすことなしに、ＨＶＬ開発ツールを用いてデバイスをモデル化できる。次にそれは例えば開始されたトランスファや進行中のトランスファ等のアブストラクト情報を記録することによってバス・トランザクションをモニタすることができる。
【００１１】
【発明の解決しようとする課題】
当業者には理解されるように、上述の方法の任意のものを用いる場合でも、特に例えば、各デバイスの多数のコンフィグレーションおよび機能を考慮すると、インクリメント・バーストのみをサポートするマスタ・デバイスや書込みトランザクションを受け付けないスレーブ・デバイスのように、特別なマスタ・デバイスやスレーブ・デバイス、あるいはマスタ・デバイスとスレーブ・デバイスとの組合せを試験するプロセスは時間の掛かるプロセスである。最初の２つの方法について考えると、これらのパラメータを提供するためにスティミュラス発生またはＲＴＬバス・フォロワに対して一定のコンフィギュレーションを追加することはできるが、それでもＲＴＬテストベンチは例えばＶＨＤＬやＶｅｒｉｌｏｇのような特別なＲＴＬで表現したＤＵＴのみを試験できるのが普通である。従って、一例として、ＶｅｒｉｌｏｇＤＵＴ用にＶｅｒｉｌｏｇテストベンチを構築すれば、そのＤＵＴのＶＨＤＬバージョンを検証するためにＶＨＤＬテストベンチも必要になるのが普通である。更に、バス・ハンドオーバやアーリー・バースト・ターミネーションのような特定のバス活動が必要となれば、専用のＲＴＬなしにそのタスクの実行を励起することは極めて困難で、デバイスを設計および検証するために要する時間が更に追加されることになる。
【００１２】
ＨＶＬ開発ツール方式はＲＴＬ言語依存性の問題を軽減するが、要求されるチェック・ルーチンを実現するためには高度な技能が必要である。更に、そのようなチェック・ルーチンが再利用できるようにライブラリ・モジュールとして実現できたとしても、各々のチェック環境のコンフィギュレーションおよびデバッグは必要である。
【００１３】
従って、デバイスのバス・プロトコル準拠を試験するための進歩した方法を提供することが望ましい。
【００１４】
【課題を解決するための手段】
第１の態様から眺めると、本発明はデバイスのバス・プロトコル準拠を試験する方法を提供し、その方法は：（ａ）そのデバイスのタイプおよびそのデバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルを読み出す工程；（ｂ）コンフィギュレーション・エンジンを採用して、前記コンフィギュレーション・ファイルに従って選ばれ、バスを介してデバイス表現と接続される試験部品を生成することによってデバイス用の試験環境を動的に生成する工程；（ｃ）テスト・シーケンスを実行させる工程；および（ｄ）テスト・シーケンスの実行中に前記デバイス表現と１個以上の前記試験部品との間で受け渡される信号をモニタすることによってバス・プロトコル準拠性を表示する結果のデータを生成する工程；を含む。
【００１５】
本発明に従えば、デバイスのタイプおよびそのデバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルが用意され、次に、バスを介してデバイス表現とつながれて試験環境を生成するための選ばれた試験部品を生成することによって、試験すべきデバイス用の試験環境が動的に生成される。試験部品はコンフィギュレーション・ファイルに従って選ばれる。次に、テスト・シーケンスを実行でき、テスト・シーケンスの実行中に、デバイス表現と１個以上の試験部品との間で受け渡される信号をモニタしてバス・プロトコル準拠性を表示する結果のデータを生成することができる。
【００１６】
従って、本発明に従えば、コンフィギュレーション・ファイルに定義された被験デバイス（ＤＵＴ）に関連する試験環境が自動的に生成される。コンフィギュレーション・エンジンは多様な異なる試験部品にアクセスし、コンフィギュレーション・ファイルに含まれる情報に基づいて、試験環境へ取り込むために選択できることが好ましい。例えば、コンフィギュレーション・ファイルが試験すべきデバイスをマスタ・デバイスと指定してあれば、コンフィギュレーション・エンジンは試験環境中にデコーダ、アービタ、複数のスレーブ・デバイス、およびダミー・マスタ・デバイスを生成およびコンフィギュアするように構成されよう。アービタは複数のマスタ・デバイス間で行なわれるバス・アクセス要求を調停するために使用され、デコーダはバス上へ発行された任意の特定のトランスファ要求が指しているスレーブ・デバイスを同定するために使用される。
【００１７】
１つの実施の形態では、試験部品はオブジェクト指向型プログラミング（ＯＯＰ）のオブジェクトとして書かれ、試験環境に含めるための試験部品を生成する工程には、試験部品のインスタンス化（すなわち、オブジェクトのインスタンス生成）が含まれ、このオブジェクトのメソッドがインスタンス化された試験部品の試験環境内でのビヘイビアを定義する。しかし明らかなように、ＯＯＰ技術を使用する必要は必ずしもなく、試験部品は任意のその他の適当なやり方で表現することができる。
【００１８】
本発明の方法に従ってデバイスの試験準備を行なう場合、ユーザはコンフィギュレーション・エンジンがそのデバイスに適した試験環境を動的に生成するために知っておく必要があるパラメータを含むコンフィギュレーション・ファイルを用意する必要がある。好適な実施の形態では、コンフィギュレーション・ファイルは１組のコンフィギュレーション・ファイル・テンプレートから選ばれる。その組には各デバイス・タイプについてのコンフィギュレーション・ファイル・テンプレートが含まれ、各コンフィギュレーション・ファイルにはそのデバイスに特有なコンフィギュレーション情報を提供するための複数のエントリが含まれる。コンフィギュレーション情報は多様な形態を取るが、典型的にはそのデバイスのタイプの同定、およびそのデバイスの機能を含む。すなわち一例として、デバイスのタイプはマスタ、スレーブ、アービタ、デコーダ等と指定される。デバイスの機能は、例えば、そのデバイスがサポートする必要のあるバス・プロトコルのサブセットを指定する。すなわち、ＤＵＴは必ずしもそのバスの性能のすべてを利用する必要はなく、デバイスによって利用されないバス・プロトコル部分に関する準拠性を試験する必要はない。
【００１９】
デバイスのタイプおよびデバイスの機能に加えて、コンフィギュレーション・ファイル中のその他のコンフィギュレーション情報には、ＤＵＴ内で使用される信号名がバス仕様の信号名とどのように対応するかを示す信号マップのほかに、例えば、デバッグやシステム環境設定に関連する一般的なテストベンチ・パラメータが含まれる。
【００２０】
明らかなように、テスト・シーケンス実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号をモニタするために使用できる複数のプロセスが存在する。好適な実施の形態では、このモニタ工程には、プロトコル・チェック・コンポネントを採用して、テスト・シーケンス実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号が、バス・プロトコルの予め定められた１組の規則に違反しないことをチェックする工程が含まれる。そのようなプロトコル・チェックには、被験デバイスが予め定められた１組の規則に従うことを確認するためのサイクル毎のチェックが含まれる。試験されるデバイスはそれがバス・プロトコルに準拠すると判断されるためには、それらの規則のいずれにも違反してはならない。典型的は、予め定められた規則の組は試験されるデバイスに拘わらず同一であり、従って予め定められた規則の組は好適な実施の形態のコンフィギュレーション・ファイルの内容によって影響されない。
【００２１】
好適な実施の形態で採用できる別のモニタ・プロセスは、カバレッジ・モニタ・コンポネントを採用して、テスト・シーケンスの実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号をモニタして、１組のカバレッジ・ポイントが観測されるかどうかを判定する工程を含む。カバレッジ・ポイントは典型的には、バス・プロトコル準拠を表明する前に試験環境内で確認すべき各種バス・トランザクションのリストである。カバレッジ・ポイントの目的は、実行されるテスト・シーケンス（単数または複数）が試験されるデバイスを十分活用して準拠性が表明できることを保証することである。
【００２２】
好適な実施の形態では、カバレッジ・ポイントの組は試験方法の工程（ａ）で読み出されるコンフィギュレーション・ファイルに依存してコンフィギュアされる。従って、試験される任意の特定デバイスはバス・プロトコルのすべての機能を使用しなくてもよく、カバレッジ・ポイントはコンフィギュレーション・ファイルに基づいて、試験されるデバイスに関連するカバレッジ・ポイントの組を指定するように調整することができる。標準的な予め定義されたバス・トランザクションのシーケンスの代わりにカバレッジ・ポイントを使用することの利点は、そうすることによって、特別なトランザクション・シーケンスを必要とするだけで特定デバイスがバス・インタフェースを完全に活用することができるということである。
【００２３】
好適な実施の形態では、試験方法の工程（ｄ）でプロトコル・チェック・コンポネントおよびカバレッジ・モニタ・コンポネントの両方が使用され、それによって、前記組中のすべてのカバレッジ・ポイントがバス・プロトコルの予め定められた規則に違反せずに観測されれば、この方法は更にバス・プロトコル準拠を確認する出力を発生する工程を含む。この出力は、例えばコンフィギュレーション・ファイルに規定された元のデバイス性能を与えた場合にバス・プロトコル準拠を保証するチェック・サム証明のような準拠性証明の形を取る。
【００２４】
先に述べたように、コンフィギュレーション・エンジンは、コンフィギュレーション・ファイルに従って選ばれた試験部品を生成するように構成される。好適な実施の形態では、生成すべき試験部品は試験すべきデバイスのタイプに従って選ばれる。このデバイス・タイプはコンフィギュレーション・ファイルに規定される。
【００２５】
更に好適な実施の形態では、少なくとも１つの試験部品はそれに付随してそれが示すであろう複数のビヘイビアを有しており、ビヘイビアの選択は試験すべきデバイスのタイプに依存してその試験部品が生成されるときに決まる。例えば、試験すべきそのデバイスがスレーブ・デバイスで、試験部品の１つとしてデコーダが生成される場合、好適な実施の形態では、試験すべきデバイスの選択を解除して、別のスレーブを選択させるようなビヘイビアを採用する。これは明らかに、スレーブ・デバイスを試験するときに、デコーダに含めるべき有用なビヘイビアである。しかし、試験すべきデバイスがマスタ・デバイスである場合には、デコーダのこのビヘイビアは関連性がなく、デコーダ試験部品のビヘイビア全体から省くことができる。先に述べたように、好適な実施の形態では、各試験部品はＯＯＰオブジェクトとして書かれ、それらのオブジェクトのインスタンス化は、次に、試験環境を生成するときにコンフィギュレーション・エンジンによって生成される。そのような実施の形態では、複数のビヘイビアがＯＯＰオブジェクトの個別メソッドとして実現され、そのメソッド（単数または複数）はインスタンスを作成する場合に選ばれる任意のインスタンスに適用可能である。これをＯＯＰ用語では“継承”と呼ぶ。
【００２６】
明らかなように、工程（ｃ）で試験方法が実行するテスト・シーケンスは多様な形態を取ることができる。例えば、テスト・シーケンスは予め決められたテスト・シーケンスの組から選ぶことができる。しかし、好適な実施の形態では、テスト・シーケンスは試験すべきデバイス用に特別に開発されたユーザ定義のテスト・シーケンスであり、試験すべきその特別なデバイスに関連するバス・プロトコル部分への準拠性を試験する目的を持つ。試験方法の工程（ｃ）および（ｄ）は、バス・プロトコルとの準拠性を確定するため十分なトランザクションが観測されるまで、工程（ｃ）において毎回テスト・シーケンスを変更または修正しながら繰り返してよい。
【００２７】
明らかなように、デバイス表現は複数のやり方で試験環境に取り込むことができる。しかし、好適な実施の形態では、デバイス表現はインタフェース・モジュール中に生成され、試験環境を生成する前記工程（ｂ）にはインタフェース・モジュール中の信号を試験環境中の信号へマッピングする工程が含まれる。このマッピングはコンフィギュレーション・ファイルに定義されている。インタフェース・モジュールはデバイス表現を取り巻く“ラッパ”として機能し、試験環境の残りの部分に対してインタフェースを提供する。
【００２８】
典型的には、デバイス表現はインタフェース・モジュールの唯一の要素ではない。例えば、インタフェース・モジュールの一部として何らかのクロックおよび多重化機能を提供することも可能であり、実際に或る実施の形態ではその他のデバイス表現がインタフェース・モジュールに含まれている。従って、本発明の好適な実施の形態では、信号のマッピングを容易にするために、インタフェース・モジュール内のデバイス表現の階層レベルをコンフィギュレーション・ファイルが指定する。
【００２９】
好ましくは、本方法は更に、バス・プロトコルと互換性を持ち、汎用の入力／出力インタフェースを備えるトリックボックス・コンポネントを提供する工程を含む。トリックボックスは、バス・プロトコルには関連しないが被験デバイスに関連する信号の制御および観測を許容する。トリックボックスは一般に、そのような信号を入力および出力するための入力および出力ポートを持ち、そのほかにトリックボックスを制御するための、バスへのスレーブ・インタフェースを備える。スレーブ・インタフェースは、トリックボックスが試験環境内でインスタンス化できて、被験デバイスよりもトリックボックスにアクセスするテスト・シーケンスを用いて制御できることを意味する。好適な実施の形態では、トリックボックスは試験すべきデバイス表現を含むインタフェース・モジュールに含まれている。明らかなように、或る実施例では、異なる試験手順を容易にするために複数のトリックボックス・コンポネントが採用されよう。
【００３０】
先に述べたように、試験すべきデバイスのタイプは好ましくはマスタ、スレーブ、アービタ、あるいはデコーダのいずれかである。好適な実施の形態では、バス・プロトコルはＡＲＭ ＡＭＢＡバス・プロトコルであり、バスはシステム・バスおよびペリフェラル・バスを含み、試験されるデバイスのタイプにはシステム・バス・マスタ、システム・バス・スレーブ、ペリフェラル・バス・マスタ、ペリフェラル・バス・スレーブ、アービタ、あるいはデコーダが含まれる。当業者には明らかなように、ペリフェラル・バス・マスタはペリフェラル・バスとシステム・バスとを接続するブリッジである。
【００３１】
試験環境に取り込まれるデバイス表現は多様な形態を取る。しかし、好適な実施の形態では、デバイス表現はレジスタ・トランスファ・ランゲージ（ＲＴＬ）表現である。
【００３２】
第２の態様から眺めると、本発明は、本発明の第１の態様に従う、デバイス準拠性を試験する方法を実行するように処理ユニットをコンフィギュアするように働くコンピュータ・プログラムを提供する。本発明はまた、本発明の第２の態様に従うコンピュータ・プログラムを含む運搬媒体を提供する。
【００３３】
第３の態様から眺めた場合、本発明はデバイスのバス・プロトコル準拠を試験するためのデータ処理システムを提供する。本システムは：デバイスのタイプおよびデバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルを記憶するためのメモリ；および次の：（ｉ）コンフィギュレーション・ファイルに従って選ばれ、バスを介してデバイス表現と接続されて試験環境を形成する試験部品を生成することによって、デバイスのための試験環境を動的に生成する工程；（ii）テスト・シーケンスを実行する工程；および（iii）前記テスト・シーケンスの実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号をモニタして、バス・プロトコル準拠性を表示する結果のデータ生成する工程；を実行するように構成された処理ユニット；を含む。
【００３４】
本発明は試験すべきデバイスが１個の場合について説明してきたが、明らかなように、本方法を複数デバイスの同時試験に適用することを妨げるものは原理的に何もない。
【００３５】
本発明は試験すべきデバイスのための試験環境を動的に生成する。試験環境は試験すべきデバイスに関連するコンフィギュレーション・ファイルに含まれる情報に従って生成される。この試験法を今後は“能動”モードと呼ぶことにする。しかし、好適な実施の形態では、既述の試験法を提供するために用いるソフトウエア・ツールを、システム・シミュレーション環境が既に存在し、従って試験環境を動的に生成する必要がない過去のシミュレーション環境に対しても互換的に使用することができる。このモードを今後“受動”動作モードと呼ぶ。このような動作モードでもコンフィギュレーション・ファイルが定義され、それを用いて、試験中にシステム・シミュレーション環境内の各種デバイス間で受け渡される信号をモニタするために使用されるプロセスをコンフィギュアする。
【００３６】
本発明は更に、一例として添付図面に示す本発明の好適な実施の形態を参照しながら説明する。
【００３７】
【発明の実施の形態】
本発明の好適な実施の形態を説明するために、ＡＲＭ社によって開発された“アドバンスト・マイクロコントローラ・バス・アーキテクチャ”（ＡＭＢＡ）仕様に従って動作するバスへつながるデバイスの試験について説明する。試験手順を詳しく説明する前に、ＡＭＢＡ仕様に従って動作するバスを採用するデバイスの実現について図１を参照しながら簡単に説明する。
【００３８】
図１はマイクロコントローラ・チップあるいはシステム・オン・チップ（ＳｏＣ）１０の形の集積回路を示しており、それはパーソナル・オーガナイザ、移動電話、テレビ用トップボックス等の装置に使用されよう。チップ１０は、ブリッジ回路１７０を介してつながれたシステム・バス１１０（今後はＡＨＢとも呼ぶ）およびペリフェラル・バス１９５（今後はＡＰＢとも呼ぶ）を含む。これらのバスはＡＭＢＡ仕様に従って動作する。ＡＭＢＡ仕様は高性能の３２ビットおよび１６ビット埋め込みマイクロコントローラを設計するためのオンチップ通信標準を定義しており、システム・バス１１０は高性能なシステム・モジュール用に、またペリフェラル・バスは低電力周辺デバイス用に用いられる。高性能システム・バス１１０は、ＣＰＵおよびその他のダイレクト・メモリ・アクセス・デバイスをシステム・バス上においたままで外部メモリ帯域幅を維持することができ、他方ブリッジ回路１７０はシステム・バスをより狭いペリフェラル・バス１９５へ接続し、ペリフェラル・バス上には狭帯域幅の周辺デバイスが配置される。ブリッジ回路１７０はシステム・バス１１０とペリフェラル・バス１９５との間で必要なプロトコル変換を実行する。
【００３９】
チップ１０は例えばＣＰＵ１４０やＤＭＡコントローラ１４５のような、システム・バス１１０へつながれる複数のマスタ論理ユニットを含むことができる。ここでは説明の便宜上、“マスタ”論理ユニットという用語は処理要求を発行するように設計された論理ユニットを意味し、他方そのような処理要求の受け手として設計された論理ユニットを“スレーブ”論理ユニットと呼ぶことにする。時間的に任意の瞬間にシステム・バスへアクセスするのはマスタ論理ユニットのうちの１つだけであり、このためシステム・バス１１０への各種マスタ論理ユニットによるアクセスを制御するためにアービタ１２０が提供される。１つのマスタ論理ユニットがシステム・バス１１０へアクセスしようとするときは、それはアービタ１２０に対してバス要求信号を発行する。時間的に任意の瞬間にアービタ１２０によって受信されるバス要求信号が１つのみであれば、それはそのバス要求信号を発行したマスタ論理ユニットに対してアクセスを許可する。しかし、時間的に任意の瞬間にアービタ１２０によって２つ以上のバス要求信号が受信されれば、アービタはどのマスタ論理ユニットにシステム・バス１１０へのアクセスを与えるかを決めるために、予め定められた優先基準を適用するようになっている。バスへのアクセスを要求するすべてのマスタ論理ユニットのうちで、アービタ１２０は最も高い優先度を有するマスタ論理ユニットにアクセスを許可する。
【００４０】
マスタ論理ユニットに加えて、１以上のスレーブ論理ユニットをシステム・バス１１０へつなぐこともある。分かり易いように、１つのスレーブ論理ユニット、例えばランダム・アクセス・メモリ（ＲＡＭ）１６０だけが図１には示されている。トランスファ要求がスレーブ論理ユニットに対して発行された場合、アドレスがシステム・バス１１０上へ出力され、それがデコーダ論理１６５で復号されてどのスレーブ論理ユニットがそのトランスファ要求を処理することになっているかが決められる。デコーダは次にそれに従って適当なスレーブ論理ユニットを指定する。
【００４１】
システム・バス１１０はまた外部バス・インタフェース１３０を介して外部バス１１５へつなぐことができる。好適な実施の形態では、外部バス１１５は３２ビットのベクトル・バスである。
【００４２】
また、システム・バス１１０へつながれる各種の論理ユニットの動作周波数を制御するためにクロック発生器１７５が設けられる。これによって、マスタ論理ユニットによって出力されるトランスファ要求信号のタイミングはクロック発生器１７５のクロック周波数で決まることになる。
【００４３】
ペリフェラル・バス１９５には複数の周辺デバイスが接続されよう。そのような周辺デバイスの例は、シリアル・データを受信および送信するための“ユニバーサル非同期受信および送信”（ＵＡＲＴ）論理ユニット１５０、例えば割り込みを発生するために用いられるタイマ１５５、短距離の高速赤外通信のために用いられる赤外線通信（ＩｒＤＡ）インタフェース１８０、ユニバーサル・シリアル・バス（ＵＳＢ）１８５、同期データ・リンク制御（ＳＤＬＣ）インタフェース２００、およびアナログ・ディジタル（Ａ／Ｄ）およびディジタル・アナログ（Ｄ／Ａ）変換器２０５および２１０である。
【００４４】
図１に示すマイクロコントローラ・チップ１０では、ペリフェラル・バス１９５はシステム・バス１１０と同じクロック速度で動作するように構成されている。従って、システム・バス１１０用としてクロック発生器１７５で生成されるクロック信号はブリッジ１７０にも送られ、ブリッジ１７０は周辺ユニット１５０、１５５、１８０、１８５、２００、２０５、および２１０の動作を制御するために必要なクロック信号を発生させるように構成されている。
【００４５】
マスタ論理ユニット１４０、１４５が、ペリフェラル・バス１９５へつながれた周辺ユニットによるハンドリングを要求する処理要求をシステム・バス１１０上へ発行するときは、ブリッジ１７０がその処理要求信号を受信し、周辺ユニット１５０、１５５、１８０、１８５、２００、２０５、２１０のどれに対してその処理要求が向けられているかを判断し、正しい周辺ユニットに対して、その周辺ユニットの動作を制御するために必要なクロック信号と一緒にその処理要求を出力する。更に、その処理要求をペリフェラル・バス上へ出力する前に、システム・バス１１０で使用されるプロトコルと、ペリフェラル・バス１９５で使用されるプロトコルとの間で必要なプロトコル変換工程がブリッジ１７０によって実行される。
【００４６】
図１に示す構造では、メイン・システム・バス１１０に負荷を掛けずに複数の周辺ユニットをペリフェラル・バス１９５へつなぐことができ、ペリフェラル・バス１９５は１つの周辺ユニットへアクセスする必要が生じたときだけ使用されるので、全体として電力消費が削減される。
【００４７】
ＡＭＢＡ仕様は、複数の異なる部品を集積化することによって迅速にＳｏＣデバイスを構築することを目的にしている。ＡＭＢＡ仕様は、標準インタフェースを提供することでこのプロセスを可能にする。これにより、個々の個別部品の開発業者は標準インタフェースを利用することで、その部品が最終的に統合されるシステムに関して知識を何ら持たなくても、その部品（ここでは被験デバイス（ＤＵＴ）とも呼ぶ）を設計および試験することができるようになる。従って、一例として、図１のＣＰＵ１４０をＳｏＣ１０へ統合するように設計する場合、設計者はＳｏＣ１０にはそのほかにどのようなデバイスが組み込まれるかを知る必要がない。
【００４８】
しかし、ＡＭＢＡ仕様に従うバスを利用して後にＳｏＣへ組み込まれる個別デバイスを設計する場合には、設計者がそのデバイスがＡＭＢＡ仕様によって規定されるバス・プロトコルに従っていることを確認するための試験を実行することは明らかに重要なことである。実際に、ＳｏＣ設計者は、集積業者に対してその部品がＳｏＣ設計の残りの部分と統合されたときに正しく機能することを確信させるために、個別部品がＡＭＢＡバス・プロトコルに準拠するという何らかの確証を得たいと思うのが普通である。
【００４９】
【実施例】
図２は、ＤＵＴがＡＭＢＡバス・プロトコルに準拠することを本発明の好適な実施の形態の能動モードにおいて試験するために提供される論理要素を模式的に示すブロック図である。図２に示すように、ＤＵＴ３３０は、ＤＵＴ３３０用の試験環境を生成するために使用されるＡＭＢＡ部品テストベンチ３００へバス３４０を介してつながれる。好適な実施の形態では、ＡＭＢＡ部品テストベンチはソフトウエア的に実現され、ユーザが定義するテスト・シーケンス・ファイル３０５からスティミュラス発生および応答チェック情報を読み出すように構成されている。このファイルはそのＤＵＴが利用するＡＭＢＡバス・プロトコル部分に対するＤＵＴの準拠性を試験する目的を持ってそのＤＵＴ３３０に関心を持つユーザによって提供される。
【００５０】
図２に示すシミュレーション環境はまた、プロトコル・チェック・コンポネント３２０およびカバレッジ・モニタ・コンポネント３１０を含む。プロトコル・チェック・コンポネント３２０は好適な実施の形態では、ＤＵＴ３３０がＡＭＢＡ仕様の規則に従うことを確認するためのチェックをサイクル毎の実行するように構成されている。プロトコル・チェックはＡＭＢＡ仕様から取り出された一定の規則群であり、ＤＵＴはＡＭＢＡ仕様に準拠することを主張するためにはそれらの規則のどれにも違反してならない。それらの規則はＤＵＴ３３０がどのようなタイプのものであろうとも従わなければならないし、従ってＤＵＴ３３０に依存してプロトコル規則をコンフィギュアするようなことはない。
【００５１】
当業者には明らかなように、どんな特殊なバス・プロトコルに対しても、チェックする必要のあるそのような規則はかなり多いのが普通である。ＡＭＢＡ ＡＨＢマスタ・プロトコル規則の一例は、“ＳｐｌｉｔあるいはＲｅｔｒｙ応答の第２サイクルで、マスタはＨＴＲＡＮＳをＩＤＬＥにドライブしなければならない”である。ＳｐｌｉｔまたはＲｅｔｒｙ応答はスレーブ・デバイスからマスタ・デバイスへの応答であって、スレーブ・デバイスがその時点に行なわれたマスタからのトランスファ要求を処理できないことを示す。ＨＴＲＡＮＳ信号はマスタによって発行される制御信号であって、マスタが実行しているバス・トランスファのタイプ、例えばノンシーケンシャル、シーケンシャル、アイドル、あるいはビジーを示す。トランスファ要求のｒｅｔｒｙを試みる前に、スレーブ・デバイスが別のトランスファ要求を受信する準備ができている状態に戻る機会を与えるためには、ＳｐｌｉｔまたはＲｅｔｒｙ応答に続くサイクルでアイドル・トランスファをアサートする必要がある。
【００５２】
カバレッジ・モニタ・コンポネント３１０は、テスト・シーケンス３０５実行中に、ＡＭＢＡ部品テストベンチ３００によって生成される試験環境内でＤＵＴ３３０とその他の任意の試験部品との間で受け渡される信号をモニタすることによって１組のカバレッジ・ポイントが観測されるかどうか決定するために使用される。カバレッジ・ポイントは、準拠性を主張できる前に、試験環境内で観測すべき各種バス・トランザクションのリストである。従って、カバレッジ・ポイントの目的は、準拠性を主張できる前に、試験によってＤＵＴが十分に調べられたことを保証することである。カバレッジ・ポイントの一例は、“バス・スレーブは同じアドレスへの書込みトランスファが直後に続く読出しトランスファによってアクセスされなければならない”である。
【００５３】
明らかなように、確認する必要のあるカバレッジ・ポイントはＤＵＴ３３０に依存する。例えば、マスタＤＵＴは異なるやり方でスレーブＤＵＴとインタフェースするであろうから、準拠性を保証するために確認すべき各種バス・トランザクションはＤＵＴのタイプ毎に異なるであろう。従って、カバレッジ・モニタ・コンポネント３１０は試験される特定のＤＵＴ３３０に関連して得られるコンフィギュレーション情報３１５に従ってコンフィギュアされる。
【００５４】
従って、理解されるように、標準的な予め定義されたバス・トランザクションのシーケンスの代わりにカバレッジ・ポイントを使用する利点は、カバレッジ・ポイントを利用することによって、バス・インタフェースを完全に活用するためには特定のＤＵＴが１つの特別なトランザクション・シーケンスを必要とするだけでよいということである。
【００５５】
注意すべきことは、プロトコル・チェック・コンポネント３２０およびカバレッジ・モニタ・コンポネント３１０は準拠性試験中にトランスファされる実際のデータの完全性を自動的にはチェックしないということである。ユーザは準拠性実行中にＤＵＴが正しく動作することを確認しなければならない。しかし、図２のようにコンフィギュアされたときは、シミュレーション環境は、ユーザが定義するテスト・シーケンス入力ファイルの“データ・チェック・コマンド”をサポートすることによってＤＵＴの動作試験を支援する。例えば、データがスレーブＤＵＴに記憶され、そしてその後でスレーブＤＵＴから読み戻される場合、ユーザが定義するテスト・シーケンスはスレーブＤＵＴから返されると期待されるデータの値を指定することができ、それをチェックして正しい動作を確認することができる。
【００５６】
後でもっと詳細に説明することになるが、図２に模式的に示す能動モードのシミュレーション環境を利用する場合、ユーザはユーザが定義するテスト・シーケンス３０５、ＤＵＴ３３０のＲＴＬ実現、およびＤＵＴに特有なコンフィギュレーション情報を提供するユーザ・コンフィギュレーション・ファイルを提供することが好ましい。これら３つのアイテムは好適な実施の形態ではテストベンチのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を通して供給され、それらがその後に試験環境を生成する。このプロセスは後でもっと詳しく説明する。
【００５７】
上で述べた能動動作モードでは、ＤＵＴ３３０のバス・プロトコル準拠を試験するためにＤＵＴ３３０と相互作用するために必要な各種のその他部品に対してユーザがＲＴＬモデルを生成する必要はない。好適な実施の形態では、好適な実施の形態のテストベンチＡＰＩが準拠性ツールの中に組み込まれ、このツールが次に既知のハイレベル・ベリフィケーション・ランゲージ（ＨＶＬ）シミュレーション・ツール、例えばＶｅｒａやＳｐｅｃｍａｎとインタフェースする。準拠性ツール、およびこのツールの一部を構成するコンフィギュレーションＡＰＩの存在は、ユーザによって与えられる入力、すなわちユーザ・コンフィギュレーション・ファイル、ユーザが定義するテスト・シーケンス、およびＤＵＴのＲＴＬ表現に基づく試験環境の動的生成を可能にする。従って、準拠性ツールは、さもなければＨＶＬシミュレーション・ツールを使用して必要とされるチェック・ルーチンを実現するために要したであろう高度な技能を不要とし、また各チェック環境のコンフィギュレーションおよびデバッグを不要とする。
【００５８】
上で図２を参照しながら説明した準拠性ツールの能動モードは最初からＤＵＴ３３０を生成する場合には明らかに有利であるが、例えばバスを介してインタリンクされた部品の複数のＲＴＬ実現を含めて、ユーザがかなりうまくシステム・シミュレーション環境を既に開発している状況も多いと思われる。好適な実施の形態では、そのようなシステム・シミュレーション環境を利用できるようにするために、準拠性ツールは図５に示す受動的な動作モードもサポートする。図５に示すように、既存のシステム・シミュレーション環境５００を準拠性ツールにロードし、バス３４０を介してＤＵＴ５１０へ接続することができる。それでもなお、カバレッジ・モニタ３１０およびプロトコル・チェッカ３２０は維持され、試験中に各種デバイス間で受け渡される信号に対して必要なチェックを実行できるし、またカバレッジ・モニタ３１０もＤＵＴ５１０に関連するコンフィギュレーション情報３１５に基づいてコンフィギュアできる。従って、図５の受動モード実施例では、ユーザがコンフィギュレーションＡＰＩを介して、ユーザ・コンフィギュレーション・ファイル、既存のシステム・シミュレーション環境５００、およびＤＵＴ５１０のＲＴＬ実現を提供する。
【００５９】
従って、要約すれば、好適な実施の形態の準拠性ツールは、図２に示すような能動モードか、あるいは図５に示すような受動モードのいずれかで動作するようにコンフィギュアできる。ここでコンフィギュレーションＡＰＩが提供されるため、ユーザはそれら２つの異なるコンフィギュレーションを指定するために必要な情報を入力できる。
【００６０】
能動モードのコンフィギュレーションを実現する２つの例が図３および図４に示されている。これらの好適な実施の形態では、能動モードのコンフィギュレーションは次のようなデバイスをサポートする：ＡＨＢマスタ、ＡＨＢスレーブ、ＡＰＢマスタ（すなわち、ブリッジ）、ＡＰＢスレーブ、アービタ、およびデコーダ。図３はＤＵＴ３３０がスレーブＤＵＴである能動モードのコンフィギュレーションを示している。このコンフィギュレーションでは、準拠性ツールのＡＭＢＡ部品テストベンチ・コア３５０内のコンフィギュレーション・エンジンは、例えばデコーダのような必要とされる任意のその他の試験部品とともに、適当なＡＨＢ／ＡＰＢマスタ部品３５５を動的に生成しよう。スレーブＤＵＴ３３０はそれがマスタ・デバイスに応答するかのようにバスにアクセスする。しかし、その回りに生成される試験環境はユーザが定義するテスト・シーケンス３０５によって指図されるような命令された応答をドライブする。プロトコル・チェック・コンポネント３２０およびカバレッジ・モニタ・コンポネント３１０は、それに従ってテスト・シーケンスの実行中にバス上で受け渡される信号をモニタすることによって、スレーブＤＵＴがバス・プロトコルに準拠するかどうかを示すデータを生成する。
【００６１】
好適な実施の形態では、ユーザ・トリックボックス・コンポネント３６０も提供されて、ビヘイビアを追加できるようにスレーブ応答信号との多重化が行なわれる。ユーザ・トリックボックス３６０は好適な実施の形態ではＲＴＬで書かれ、ユーザ・トリックボックス３６０とスレーブＤＵＴ３３０の両方を含むインタフェース・モジュール内でインスタンス化される。後で詳しく説明するように、このインタフェース・モジュールは次に、適当な信号のマッピングを介して準拠性ツールによって生成される試験環境の残りの部分とインタフェースする。従って、ＲＴＬトリックボックス３６０はＤＵＴ３３０とインタフェースすることができ、ＤＵＴの非ＡＭＢＡ信号を制御および観測することを可能にする。
【００６２】
好適な実施の形態のトリックボックスは、トリックボックスを制御するための標準的なＡＨＢ／ＡＰＢスレーブ・インタフェースのほかに、３２ビット出力ポートおよび３２ビット入力ポートを有する。ＡＨＢ／ＡＰＢインタフェースはトリックボックスがテストベンチでインスタンス化され、ＤＵＴではなくトリックボックスにアクセスするテストベクトルを用いて制御されることを可能にする。この文脈で用いられるように、“ベクトル”という用語はユーザが定義するテスト・シーケンス３０５の１要素を意味し、それはバス上で実行されるアクションおよび／または特別な時間におけるバス・ステータスを定義する。トリックボックス３６０を用いて導入される付加的なビヘイビアの一例として、もしも図３の能動モードがＡＨＢ能動モードであると仮定すれば、トリックボックス３６０を用いて別のスレーブ・デバイスのような期待される応答を提供することができ、デコーダ試験部品を用いてスレーブＤＵＴ３３０の選択を解除し、トリックボックス・スレーブ・デバイスを選択することができる。
【００６３】
図４はマスタＤＵＴ４００を試験するために実現される別の能動モードを示す。この構成では、準拠性ツールのＡＭＢＡ部品テストベンチ・コア３５０内のコンフィギュレーション・エンジンを使用して、例えばアービタ、デコーダ、およびダミー・マスタのような必要とされるその他任意の試験部品と一緒にＡＨＢ／ＡＰＢスレーブ部品４１０が生成されよう。コンフィギュレーションおよび／またはＤＵＴのタイプに依存して準拠性ツールの中からある種のファシリティを追加することもできる。例えば、ＡＨＢマスタ・コンフィギュレーションの場合は、メモリ初期化ファイル４２０を有するビヘイビア・メモリ・スレーブ・デバイスを生成することが好ましく、それはそれ自身が同じフォーマットのメモリ・ダンプを生成する。メモリ・ダンプ・ファイルはテストベンチ・コア３５０内に実現されたメモリ・モデルの内容のファイル表現であり、試験が完了した後で生成される。試験中にメモリ・モデルに対して修正がなければ、結果のメモリ・ダンプ・ファイルはメモリ初期化ファイルと同じ内容を有することになる。
【００６４】
図４のマスタＤＵＴ４００はあたかもスレーブ・デバイスを通信しているようにバスにアクセスする。しかし、その回りに生成される試験環境はユーザが定義するテスト・シーケンス３０５によって定義されるような命令された応答をドライブ・バックする。図３の例と同じように、ユーザ・トリックボックス・コンポネント３６０を提供して、それをスレーブ応答信号と多重化することによってビヘイビアを追加することができる。
【００６５】
上の能動モードの説明から明らかなように、準拠性ツールの能動モードコンフィギュレーションは各ＤＵＴに対してポイント・ソリューションとなるテストベンチを生成しなければならないという負担を大幅に軽減する。準拠性ツールそれ自身は、ユーザが供給するスティミュラスを準拠性試験の過程で提供するように、ＤＵＴを取り巻く、必要なすべてのＡＭＢＡ“ファブリック”を生成する。
【００６６】
これとは対照的に、先に述べた受動モードは、主としてシステム中の試験環境を目的としている。受動モードは準拠性ツールによるＡＭＢＡファブリックの動的生成という概念を等価的に禁止し、そうでなければ能動モードで利用できたスティミュラス・ドライブ機能を禁止する。既に述べたように、同じユーザ・コンフィギュレーション・ファイルをＤＵＴそれ自身に関する詳細を指定するためにも使用することが好ましい。しかし受動モードでは、能動モード特有のコンフィギュレーション・オプションはすべて無視される。
【００６７】
受動モードはまた過去の設計を検証するためにも理想的であり、ユーザは準拠性試験のためにＤＵＴを能動モードのテストベンチへ分離する必要がない。しかし注意すべきことは、ＤＵＴへのスティミュラスの発生源が限られたトランザクションまたはシナリオ生成能力しか持たない場合は（すなわち、能動モードにおいて使用される、ユーザが定義するテスト・シーケンスの場合ほどにはＤＵＴに対して適するように調整されていないのが普通である）、全カバレッジを達成することは受動モードのほうがより困難であろうということである。もっと可能性の高いシナリオは、受動モードを使用して、試験実行シーケンスの過程でＤＵＴがＡＭＢＡプロトコル違反を何ら行なわなかったことを保証することであろう。
【００６８】
いずれの動作モードでも、準拠性ツールは試験実行の終わりにオプションで目に見える形でカバレッジ・レポートを生成することが好ましい。これはそのＤＵＴに付随する、完了し傑出した準拠性カバレッジ目標とその特別な機能に関するコンフィギュレーションの両方を表示するグラフィカル・ユーザ・インタフェース（ＧＵＩ）の形であることが好ましい。このデータからＡＭＢＡ準拠性の証明を発行できる。好適な実施の形態では、ＡＭＢＡ準拠性証明は、ＡＭＢＡ仕様改訂版番号、準拠性コンフィギュレーション、および試験しなかったすべての準拠性カバレッジ・ポイントの説明を指定するであろう。好適な実施の形態では、準拠性ツールはまた、ＤＵＴ用の試験環境を許可し、それとともにユーザが準拠性試験を繰り返すことができるように必要な任意のテストベクトルを出力することを許可する。
【００６９】
既に述べたように、好適な実施の形態では、準拠性ツールは標準的なＨＶＬシミュレーション・ツールと組み合わせて実行するのが好ましい。ここで、シミュレーション・ツールと準拠性ツールとが一緒になって準拠性チェックを実行するプロセスについて、図６および図７のフロー図を参照しながら詳細に説明する。
【００７０】
図６に示すように、準拠性チェックは工程６００から始まり、工程６０５へ進んでそこからシミュレーション・ツールが始動する。シミュレーション・ツールが始動すると、それは準拠性ツールを使用すべきことを指示する。プロセスは次に工程６１０へ進み、ＤＵＴインタフェース・モジュールがロードされる。既に述べたように、このインタフェース・モジュールはその中へＤＵＴのＲＴＬ表現をインスタンス化するモジュールである。好適な実施の形態では、インタフェース・モジュールはまたユーザ・トリックボックスのＲＴＬ表現も含む。更に、インタフェース・モジュールはオプションのクロックおよびリセット信号を提供し、それと一緒に、ＲＴＬと準拠性ツールの試験環境それ自身との間の付随する信号多重化も提供する。このことから、インタフェース・モジュールは、与えられたユーザ・コンフィギュレーション・ファイルに基づいてシミュレーション時点で能動モードにおいて動的に生成される準拠性ツール試験環境とのインタフェースを構成する簡単なＲＴＬの最上位モジュールとみなすことができる。
【００７１】
工程６１５では準拠性ツールがロードされるが、これは能動あるいは受動のいずれかのモードにツールをコンフィギュアするために使用されるコンフィギュレーションＡＰＩを、カバレッジ・モニタおよびプロトコル・チェック機能と一緒に導入する。工程６２０では、シミュレーション・ツールが準拠性ツールに処理を渡し、その後プロセスは工程６２５へ進む。
【００７２】
工程６２５では、準拠性ツールが、ユーザによってコンフィギュレーションＡＰＩを介して与えられるユーザ・コンフィギュレーション・ファイルを読み込んでチェックする。好適な実施の形態では、各々の準拠性ツールの動作モード、例えばＡＨＢ＿マスタ、ＡＨＢ＿スレーブ、ＡＰＢ＿マスタ、ＡＰＢ＿スレーブ、アービタ、あるいはデコーダに対してテンプレートのユーザ・コンフィギュレーション・ファイルが提供される。従って、ユーザがＡＨＢマスタ・デバイスを試験しようとする場合には、ユーザはＡＨＢ＿マスタのテンプレート・ユーザ・コンフィギュレーション・ファイルを選ぶ。コンフィギュレーション・ファイルにはそのデバイスに特有なコンフィギュレーション情報を規定する予め定められたパラメータが含まれる。それらのエントリの少なくともいくつかは、試験される特定デバイスに関心を持つユーザによって入力される必要がある。好適な実施の形態では、コンフィギュレーション・ファイルに含まれるエントリは次のものを規定する：
【００７３】
１．ＤＵＴ名およびオプションＩＤ；
２．ＤＵＴ設計の階層構造のＨＤＬパス／レベル
３．ＤＵＴ信号マップ、例えばＨＣＬＫ＝ＨＣＬＫｓｙｓ、あるいは上記２をオーバーライドするためのＨＣＬＫ＝〜／ｔｏｐ／ＨＣＬＫ
４．一般的なテストベンチ・パラメータ、例えばＥＮＤＩＡＮＥＳＳ＝ＬＩＴＴＬＥ、ＥＲＲＯＲＳＴＯＰ＝ＹＥＳ、ＶＥＲＢＯＳＩＴＹ＝ＥＲＲＯＲＳ＿ＯＮＬＹ；および
５．カバレッジ・コンフィギュレーション、例えば読出し専用デバイスに対してＤＩＲＥＣＴＩＯＮ＝ＮＯ＿ＷＲＩＴＥ
【００７４】
ＡＨＢマスタＤＵＴ用のユーザ・コンフィギュレーション・ファイルの一例を次に示す。
【００７５】
【表１】
【００７６】
上のことから明らかなように、このファイルの第１エントリは試験されるデバイス名を示しており、ここではＡＲＭプロセッサ・コアとなっている。第２エントリの“ＨＤＬＰＡＴＨ”はＤＵＴの階層構造のレベルを示す。次には、マスタＤＵＴによって使用され、ＤＵＴ内部で使用される名前をＡＭＢＡ信号名に対してどのようにマッピングするかを示すすべての信号を示す複数のエントリが続く。例えば、ＤＵＴによって使用される信号ＨＷＲＩＴＥｏｕｔはＡＭＢＡバス信号ＨＷＲＩＴＥにマッピングされる。
【００７７】
コンフィギュレーション・ファイル中の次のエントリはデバイスを能動モードと受動モードのどちらで試験すべきかを指定する。ここでは受動モードを使用することが確認されている。次のエントリはスティミュラスとして使用すべきユーザが定義するテスト・シーケンスを指定する。この例では、２つのテストベクトル・ファイル、すなわちｍｅｍｏｒｙ．ｖｅｃおよびｐｅｒｉｐｈｅｒａｌ．ｖｅｃが指定されている。図４を参照すると、ベクトル・ファイルｐｅｒｉｐｈｅｒａｌ．ｖｅｃはユーザが定義するテスト・シーケンス３０５であり、ベクトル・ファイルｍｅｍｏｒｙ．ｖｅｃはメモリ４２０に置くべきデータを含んでいる。試験が始まると、プロセッサ・コアのＤＵＴはメモリ４２０からデータを読み込む。このデータはコアによって実行すべき一連の命令を規定する。これはバス３４０上でバス・トランスファを引き起こし、ユーザが定義するテスト・シーケンス３０５、すなわちこの例ではｐｅｒｉｐｈｅｒａｌ．ｖｅｃがスレーブ試験部品によって提供される応答を命令する。このエントリはまた試験ランを開始する前に入力ファイルの文法チェックをすべきかどうかを指定する。
【００７８】
好適な実施の形態では、スティミュラス・ベクトル・ファイルのフォーマットは、それをＰｅｒｌやＣのような言語を使用して手書き、あるいはもっと便利な自動生成できるように特別に設計されている。
【００７９】
ユーザ・コンフィギュレーション・ファイルの次のエントリは、受動モードにおいて特別に使用されるいくつかの追加信号を指定する。その次には、試験に関連するデバッグおよびシステム環境設定を提供するいくつかの一般的なパラメータが続く。例えば、特定例では、バス幅が３２ビットであると指定される。
【００８０】
その後には能動モードに特有なコンフィギュレーション情報を提供するエントリが続く。最後に、ファイル中の最後に３つのエントリは、例えばカバレッジ・モニタによってチェックすべきカバレッジ・ポイントを決めるときに使用されるデバイス機能を規定する。
【００８１】
図６に戻って、ユーザ・コンフィギュレーション・ファイルが一旦読み込まれチェックされると、次に準拠性ツールはプロトコル・チェック・コンポネントを生成し、またカバレッジ・モニタ・コンポネントを生成およびコンフィギュアする。上で述べたように、カバレッジ・モニタのコンフィギュレーションはユーザ・コンフィギュレーション・ファイルに規定されたデバイス機能を考慮して行われる。
【００８２】
準拠性ツールは次に工程６３０においてＤＵＴを能動モードで実行させるべきかどうかを決定する。先に述べたように、この情報はユーザ・コンフィギュレーション・ファイルに与えられている。もしＤＵＴを受動モードで実行させるべきであれば、プロセスは工程６３５へ分岐して、カバレッジおよびプロトコル・チェックに関する信号マッピングが実行される。これはユーザ・コンフィギュレーション・ファイルに与えられる信号マッピング情報を用いて行なわれる。次にプロセスは分岐して工程６５０のシミュレータ・ツールへ戻り、その後で工程６６０で試験が実行される。受動モードでは、この試験は既存のシステム・シミュレーション環境内に定義されよう。
【００８３】
しかし工程６３０でＤＵＴが能動モードで実行すべきことが決まった場合には、プロセスは工程６４０へ進み、準拠性ツールによってＤＵＴ用の試験環境が動的に生成される。このプロセスは図７に関してもっと詳細に説明する。
【００８４】
図７に示すように、第１工程（工程７００）は生成する必要のある環境のタイプを規定する。この情報は被験デバイスのタイプから決まる。例えば、試験すべきデバイスがＡＨＢマスタ・デバイスであれば、好適な実施の形態では試験環境はアービタ、デコーダ、デフォルト・マスタ、および１以上のスレーブ・モデルを含む必要がある。あるいは、ＤＵＴがＡＨＢスレーブであれば、試験環境は少なくともデコーダおよびマスタ・モデルを含む必要がある。
【００８５】
一旦環境のタイプが指定されれば、次には必要なオブジェクトのインスタンスが工程７１０で生成される。従って、この時点で試験環境に必要な試験部品が生成され、好適な実施の形態では各試験部品がＯＯＰオブジェクトとしてインスタンス化される。次に、すぐ上で述べたＡＨＢマスタＤＵＴの例に戻って、工程７１０でＤＵＴと組み合わせることによって試験環境を形成するためにアービタ、デフォルト・マスタ、およびスレーブ・オブジェクトが生成される。
【００８６】
当業者には明らかなように、ＯＯＰプログラミングでは、各オブジェクトにはそれの関数を定義する複数のメソッドが付随する。本発明の好適な実施の形態に従えば、オブジェクトの各インスタンスに付随させるべき実際のメソッドは工程７００で検出される環境のタイプに依存する。例えば、ＤＵＴがマスタ・デバイスであれば、生成されるデコーダ・オブジェクトは単にマスタからの要求に応答するスレーブを選ぶことができればよい。しかし、ＤＵＴがスレーブ・デバイスであれば、デコーダもＤＵＴの選択を解除して、別のスレーブを選択することができ、それによってスレーブＤＵＴがビヘイビアをデコーダによる選択解除時に決定できるようにする機能も含むことが好ましい。
【００８７】
プロセスは次に工程７２０へ進み、そこでデバイス間の信号マッピングが更新される。既に説明したように、これにはユーザ・コンフィギュレーション・ファイルに与えられる信号マッピング情報への参照が含まれ、またＤＵＴによって使用される信号名を試験環境の残りの部分で使用されるＡＭＢＡ信号名へマッピングすることが含まれる。
【００８８】
プロセスは次に工程７３０へ進んで、各信号の初期値が設定される。例えば、ＤＵＴがスレーブ・デバイスの場合、それがマスタ・デバイスからトランスファ要求を受信する準備ができていることを確認する論理１のＨＲＥＡＤＹ信号をアサートする必要がある。
【００８９】
工程７３０の完了に続いて、プロセスは図６の工程６５０へ戻って、処理がシミュレータ・ツールへ戻される。工程６６０では、シミュレータは能動モードで試験を実行する。これはユーザが定義するテスト・シーケンスであるか、あるいはユーザ・コンフィギュレーション・ファイルに定義されたテスト・シーケンスである。オプションとして、準拠性ツールはユーザ・コンフィギュレーション・ファイルをチェックするときに、ユーザが定義するテスト・シーケンスが有効であることをチェックするためにユーザ・コンフィギュレーション・ファイルに定義されたユーザが定義するテスト・シーケンスのチェックを実際に実行するように構成できる。そのような工程は工程６２５において行われることが多い。この時点でこのチェックを実行することは有益である。それは、後の都合のよい時点、例えば夜通しで実際の試験を実行するように考えているし、また工程６６０において試験を開始する前にテスト・シーケンスには何も悪いところは基本的にないことを知るのが好ましいのは明らかだからである。
【００９０】
能動または受動モードのいずれかで準拠性試験を実行させるために好適な実施の形態で実行されるプロセスについて説明してきたが、好適な実施の形態で実行されるプロトコル・チェックおよびカバレッジ・モニタのより詳しいことについて次に説明する。
【００９１】
既に述べたように、プロトコル規則のコンフィギュレーションは行なわれない。またＡＭＢＡバス準拠性を主張するためにはＤＵＴはＡＭＢＡプロトコル規則のどれにも違反してはならない。
【００９２】
しかし、これとは対照的に、好適な実施の形態ではカバレッジ・ポイントは、いくつかのＤＵＴはＡＭＢＡバスの機能のすべてを利用しなくてもよいことを想定してコンフィギュアされる。ＤＵＴに対して許容できるコンフィギュレーションは、ＳｏＣに組み込まれるすべての部品が常に一緒に正しく動作するように定義されることが重要である。
【００９３】
基本的な規則として、ＡＭＢＡ部品は考えうるすべての入力組合せを受け入れる必要があるが、考えうるすべての出力の組合せを生成する必要はない。
【００９４】
一例として、Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ、Ｔｒａｎｓｆｅｒ Ｒｅｓｐｏｎｓｅ、およびＢｕｓ Ｇｒａｎｔに関する入力信号を有するバス・マスタはそれら入力の考えうるすべての組合せを処理できなければならない。しかし、考えうるすべての出力組合せを生成する必要はなく、それの動作にとって適切なタイプのバーストおよびトランスファ・サイズを生成するだけでよい。
【００９５】
注意すべき点は、或るカバレッジ・ポイントをターン・オフさせればプロトコル・チェックを付加できるということである。例えば、もしもバス・マスタ準拠性チェックが４ビート・ラッピング・バーストをサポートしないバス・マスタとしてコンフィギュアされれば、このコンフィギュレーション・オプションは各種タイプの４ビート・ラッピング・バーストを観測するカバレッジ・ポイントを除去する効果を持つ。しかし、これはマスタがこの種のトランスファを決して実行しないことを保証する付加的なチェックを許容する。
【００９６】
スレーブ・デバイスもまた、考えうるすべての入力を受け入れることができ、トランスファのすべての異なる組合せを正しく処理できなければならない。しかし、バス上で利用可能なトランスファ情報のすべてを利用するわけではないスレーブ・デバイスを構築することは認められる。この典型的な例はバースト情報を利用しないスレーブ・デバイスであろう。そのようなスレーブ・デバイスの準拠性試験を簡略化するために、スレーブ・デバイスの入力に特定の信号が含まれない場合には、それらの入力の異なる組合せに関連するカバレッジ・ポイントを省略することができる。
【００９７】
ここでプロトコル・チェック関数の詳細について詳しく見てみると、ＡＭＢＡバスのプロトコルをチェックする基本原理は、ＡＭＢＡバス・プロトコルがトランザクション中に観測されることを確認するチェック・シーケンスを採用することであり、それには個別トランスファのバーストが複数個含まれる。好適な実施の形態では、準拠性ツールは、シミュレーション・イベントがそれらのプロトコル・チェックを記述する発見的方法をトリガすることを許容する時間表現を利用する。
【００９８】
時間表現はビヘイビアを記述するイベントおよび時間的オペレータの組合せである。時間表現は試験中にイベント、フィールドの値、変数、あるいはその他のアイテム間の時間的関係を取り込む。
【００９９】
明らかなように、好適な実施の形態の準拠性ツールには非常に多い可変数個の時間表現が用いられる。説明のために、そのような構成をどのように使用するかについて以下に簡単に見てみよう。
【０１００】
好適な実施の形態では、Ｖｅｒｉｓｉｔｙ Ｓｐｅｃｍａｎ“ｅ”言語を使用して時間表現が定義される。図８の一番上には時間経過のグラフィカルな表現として使用できる４つの凡例が示されている。図８の残りの部分は、一例としてＡＭＢＡ ＡＨＢシーケンス評価を提供しており、ＨＴＲＡＮＳ信号がＩＤＬＥにセットされた場合（ｈｔｒａｎｓ．ｉｄｌｅイベント）のｈｇｒａｎｔイベントのモニタリングの様子を示している。
【０１０１】
図８を参照すると、ＨＣＬＫイベントはｈｇｒａｎｔおよびｈｔｒａｎｓ．ｉｄｌｅイベントを含む２つのシーケンスについてのサンプリング・イベントである。ｈｃｌｋイベントそれ自身はＨＣＬＫ信号の立ち上がりで発生される。
【０１０２】
図８から分かるように、示されたいくつかのイベントは信号値に直接関連しており、他方、その他のイベントは基準イベントでサンプリングされた信号状態の組合せで定義される。この例では、基準イベントはＨＣＬＫの立ち上がり端である。
【０１０３】
｛＠ｈｇｒａｎｔ；＠ｈｔｒａｎｓ．ｉｄｌｅ｝シーケンスはｈｃｌｋにおいてｈｇｒａｎｔが発生する度に評価をスタートさせる。ｈｇｒａｎｔのｈｃｌｋ１個分後でｈｔｒａｎｓ．ｉｄｌｅがサンプリングされるとき、このシーケンスは成功である。
【０１０４】
｛＠ｈｇｒａｎｔ；［１］；＠ｈｔｒａｎｓ．ｉｄｌｅ｝シーケンスもまたｈｃｌｋでの最初のｈｇｒａｎｔの発生によって評価を開始するが、“１サイクル続く”文節（［１］）のために次のｈｃｌｋが発生するとシフトする。第３のｈｃｌｋが発生すると、シーケンスはｈｔｒａｎｓ．ｉｄｌｅイベントが存在すれば成功する。しかし図８から分かるように、この時間表現は第５サイクルの後は評価しない。それはｈｔｒａｎｓ．ｉｄｌｅイベントが存在しないためである。
【０１０５】
このように、図８に関連して上述したイベントを用いて特定の規則が観測されない条件を捉えることによってプロトコル・エラーを定義できるのが普通である。そのようなイベントは更に別のイベント・シーケンスを構築するために用いられたり、あるいは論理的に組み合わせてアサート・ステートメントを生成するために用いられたりする。準拠性ツールのプロトコル規則の典型的な形式は次のようになっている：
【０１０６】
【数１】
ｅｘｐｅｃｔ＜規則＞ｉｓ｛＜時間表現＞｝＠ｈｃｌｋ；
【０１０７】
時間表現を使用する代わりに採用できる別の方式は形式論的な数学技法に基づいて利用できるプロパティ・チェッカ・ツールを使用するものである。フォーマル・プロパティ・チェックにはシステム要求に密接に合致するプロパティを書くこと、そして次にそのプロパティがその設計で確保されていることを完全に証明することが含まれる。この方法が完全であるということは機能シミュレーションによってカバーできないバグを見出すことができるということを意味する。
【０１０８】
プロパティ・チェッカ・ツールはブロック・レベルで最も良く働く。１００Ｋゲートより小さいブロックが理想的である。
【０１０９】
プロパティ・チェック・ツールによってチェックされるプロパティの例は、ＡＨＢマスタが認められない場合にＨＴＲＡＮＳ信号出力がＩＤＬＥまたはＮＯＮ−ＳＥＱＵＥＮＴＩＡＬになるという要求である。このプロパティは図９Ａに示すタイミング図と合致するように書くことができる。図９Ａのタイミング図で、時間ｔおよびｔ＋１はクロック・サイクルを表す。ドット領域の値が仮定であり、続くＩＤＬＥ／ＮＳＥＱ部が証明しなければならない部分である。タイミング図が意味することは、もしもＨＧＲＡＮＴ信号が１つのクロック・サイクル（時間ｔ）で低レベルであれば、次のクロック・サイクルではＨＴＲＡＮＳ信号はＩＤＬＥまたはＮＳＥＱでなければならないということである。この証明は時間ｔが任意のクロック・サイクルで成り立つように徹底的に行われなければならない。すなわち、プロパティ・チェックはシミュレーション全体でタイミング図をスライドさせるようにみなすことができる。仮定が成り立つ場合はいつでもオブリゲーション部も成り立たなければならない。
【０１１０】
もしプロパティが保持されることが分かれば、ＤＵＴのＲＴＬ表現はそのプロパティによって指定される要求を常に満たさなければならない。どこかの瞬間にプロパティが保持されなければ、プロパティ・チェッカはエラーを指摘する短い波形ファイルを出力するのが好ましく、それを用いてデバッグが可能となる。
【０１１１】
そのようなデバッグの一例として、図９Ａのプロパティを試験環境にあるＤＵＴに適用した場合のデバッグ波形を観測したら、それは時間ｔにおいてＨＧＲＡＮＴ信号が低レベルで、ｔ＋１ではＨＴＲＡＮＳ信号がＳＥＱであるというプロパティの誤りをハイライト表示した。実際にはＤＵＴのＲＴＬ表現にはバグがないが、その代わりにプロパティそれ自身が不完全であった。事実、もしＡＨＢマスタが待機していれば（ＨＲＥＡＤＹ信号入力が低レベル）、ＨＴＲＡＮＳは保持されるべきであるという状況が存在する。すなわち、図９Ｂのタイミング図改訂版によって、正しいプロパティを示すことができる。
【０１１２】
図９Ｂのタイミング図によって示されるプロパティは、もしマスタが認められずまた待機状態でなければ、ＨＴＲＡＮＳ信号は続くクロック・サイクルでＩＤＬＥまたはＮＳＥＱでなければならないことを言っている。
【０１１３】
プロパティ・チェックについて議論してきたが、ここでカバレッジ・モニタについて簡単に説明しよう。既に述べたように、カバレッジはバス活動の特定のシーケンスを観測するプロセスである。好適な実施の形態では、ＶｅｒｉｓｉｔｙＳｐｅｃｍａｎツールが用いられる。これはカバレッジ・グループの定義を通してカバレッジ・モニタを可能とする。１つのカバレッジ・グループは、時間的にデータを収集したデータ・アイテムのリストを含むプログラム構造／オブジェクト・メンバである。
【０１１４】
Ｓｐｅｃｍａｎツールはまた、カバレッジ・データ・アイテム間相互作用の観測を可能とするクロス・カバレッジを実行できる。クロス・カバレッジを利用するＡＭＢＡ ＡＨＢマスタの例は、バーストの各タイプ（ＳＩＮＧＬＥ、ＩＮＣＲ、ＷＲＡＰ４、ＩＮＣＲ４、ＷＲＡＰ８、ＩＮＣＲ８、ＷＲＡＰ１６、ＩＮＣＲ１６）について、読出しおよび書込みの両バーストに対して異なるタイプのスレーブ応答が観測されることを確認することであろう。先に述べたように、試験実行のランの終わりに、すべてのカバレッジ情報は１つのＧＵＩに順序正しくまとめられる。このＧＵＩはそのＤＵＴについて要求されるカバレッジ・ポイントのうちどのくらいがモニタされたかをユーザに対して表示することができるようになっている。
【０１１５】
好適な実施の形態の試験準拠性ツールについて詳細に説明してきたが、準拠性ツールをその中で使用できるデータ処理システムについても図１０を参照しながら簡単に説明しよう。
【０１１６】
図１０はデータ処理装置を示しており、それはプロセッサ・コア８００、読出し専用メモリ（ＲＯＭ）８１０、ランダム・アクセス・メモリ（ＲＡＭ）８３０、入力／出力（Ｉ／Ｏ）デバイス８４０、およびディスプレイ８５０を含んでおり、それらは適当なバス・ネットワーク８２０を介して相互に接続されている。明らかなように、バス８２０は単一バスでもよいが、部品を互いに接続するために必要なバスの任意の組合せで構わない。
【０１１７】
好適な実施の形態では、好適な実施の形態のシミュレータ・ツールおよび準拠性ツールはＲＡＭ８３０へロードされ、次にプロセッサ・コア８００上で実行される。オペレーティング・システム、例えばＢＩＯＳはＲＯＭ８１０に記憶されるのが普通である。
【０１１８】
任意の特定の試験を実行するために必要な入力は一般的にはユーザによってＩ／Ｏデバイス８４０を介して入力され、ＲＡＭ８３０に記憶される。従って、能動モードでは、ユーザはＩ／Ｏデバイス８４０を介して、ＤＵＴを含むインタフェース・モジュール、ユーザ・コンフィギュレーション・ファイル、およびユーザが定義するテスト・シーケンスを入力する。これらは例えばディスクからＩ／Ｏデバイス８４０によって読み出される。この情報は次に、シミュレータ・ツールおよび準拠性ツールの実行中に必要に応じてプロセッサ・コア８００によってＲＡＭ８３０から取り出される。試験実行中あるいは実行後に、試験結果は例えばＶＤＵのようなディスプレイ・デバイス８５０上へ表示されよう。プロトコル規則のどれも違反されずにカバレッジ・ポイントすべてがモニタされれば、任意の適当な出力デバイスへＩ／Ｏデバイス８４０を介して出力するための準拠性証明を作製できる。
【０１１９】
要約すれば、理解されるように、好適な実施の形態の準拠性ツールはデバイスのバス・プロトコル準拠性を試験するための特に使いやすく効率的な方法を提供する。能動モードでは、ＤＵＴは非ＡＭＢＡのＩ／Ｏ信号とインタフェースするために試験者が利用できるトリックボックス・デバイスをオプションとした、単独ユニットとして試験される。このオプションのトリックボックスは試験者の制御下でデバイスの或る要求されるビヘイビアを誘発するために使用できる。能動モードでは、ユーザが生成するスティミュラス・ファイルを準拠性ツールによって読み出して、ユーザ・コンフィギュレーション・ファイルに指定されたバス・インタフェース信号上の所望のスティミュラスをドライブする。マスタＤＵＴの場合には、ベクトル・スティミュラス・ファイルが供給され、それによって、データ・チェックのためのデバイスへの予期されるアクセスとともに、待機ステータス、応答タイプ、グラント・ステータスを含むスレーブ応答ビヘイビアを決定する。スレーブＤＵＴの場合は、ユーザによって与えられるベクトル・スティミュラス・ファイルが有効なマスタ・バス・トランザクションを指定する。両方のタイプの入力スティミュラス・ファイルで、ユーザは試験環境がランダムに生成されるビヘイビアで以ってユーザが定義するスティミュラスをオーバライドするかどうかを制御できる。スレーブ・テストベンチの場合は、ランダム生成は待機ステータス、応答、およびグラント・ステータス等をカバーできる。
【０１２０】
受動モードでは、デバイスはシステムの一部として試験される。すなわち、準拠性ツールはドライブ機能を何も提供しないし、またデコーダ、アービタ、マスタ、およびスレーブのような試験部品の動的生成をサポートしない。ドライブすべきＤＵＴのためのサポート用インフラストラクチャ全体を提供するのは試験者のテストベンチである。このことは過去のＳｏＣ設計の準拠性試験において、また初めて周辺機器を一緒に統合する場合に特に有用である。準拠性ツールのドライブ機能が停止している状態では、プロトコル・チェックおよびカバレッジ・ポイント収集機構は能動モードで使用されたものと同じように働く。
【０１２１】
好適な実施の形態では、バス・プロトコル・エラーが発生せずに試験ランが完了したときは、ＤＵＴに関するカバレッジの詳細を表示するＧＵＩがロードされる。ここでカバレッジ・ホールを同定することができるため、後続の試験ランで前に見逃したカバレッジ・ポイントを満たすように、ＤＵＴをより明確な方向にドライブすることができる。このように準拠性を実現することに成功した後で、元の指定されたデバイス機能が与えられれば、バス・プロトコルに準拠することを認めるチェック・サムの準拠性証明が発行されよう。例えば、もしマスタＤＵＴがインクリメント・バーストのみをサポートすると指定されれば、それの準拠性証明はその事実を明確に述べる。
【０１２２】
本発明の特別な実施の形態についてここに述べてきたが、本発明がそれらに限定されず、本発明の範囲内で多くの修正および追加が可能であることは明らかであろう。例えば、本発明の範囲から外れることなしに、クレームの従属項の特徴を独立項の特徴と組み合わせることができる。
【図面の簡単な説明】
【図１】ＡＲＭ社によって開発されたアドバンスト・マイクロコントローラ・バス・アーキテクチャ仕様に従って動作するバスを介して相互接続されたデバイスを含むシステム・オン・チップを示すブロック図。
【図２】本発明の好適な実施の形態の能動モードに従う試験手順を実行するときに用いられる論理要素を模式的に示すブロック図。
【図３】スレーブ・デバイスを試験するときに、好適な実施の形態の能動モードで用いられる論理要素の更に詳細を示すブロック図。
【図４】マスタ・デバイスを試験するときに、好適な実施の形態の能動モードで用いられる論理要素の更に詳細を示すブロック図。
【図５】本発明の好適な実施の形態の受動モードに従って試験を実行するときに用いられる論理要素を模式的に示すブロック図。
【図６】本発明の好適な実施の形態に従って準拠性チェックを実行するために実行される工程を示すフロー図。
【図７】被験デバイス用の準拠性試験環境を生成するプロセスの詳細を示すブロック図。
【図８】本発明の好適な実施の形態に従ってプロトコル・チェックを実行するときの時間シーケンスの評価を表すために用いられるグラフ表記の例。
【図９】プロトコル・チェックを実行するときに、チェックされるプロパティを表すタイミング図。
【図１０】好適な実施の形態の試験手順が実行されるデータ処理システムを模式的に示すブロック図。
【符号の説明】
１０ ＳｏＣ
１１０ システム・バス
１１５ 外部バス
１２０ アービタ
１３０ 外部バス・インタフェース
１４０ ＣＰＵ
１４５ ＤＭＡコントローラ
１５０ ＵＡＲＴ論理ユニット
１５５ タイマ
１６０ ＲＡＭ
１６５ デコーダ論理
１７０ ブリッジ回路
１７５ クロック発生器
１８０ 赤外通信インタフェース
１８５ ＵＳＢ
１９５ ペリフェラル・バス
２００ ＳＤＬＣインタフェース
２０５ Ａ／Ｄコンバータ
２１０ Ｄ／Ａコンバータ
３００ テストベンチ
３０５ テスト・シーケンス・ファイル
３１０ カバレッジ・モニタ・コンポネント
３１５ コンフィギュレーション情報
３２０ プロトコル・チェック・コンポネント
３３０ ＤＵＴ
３４０ バス
３５０ ＡＭＢＡ部品テストベンチ・コア
３５５ ＡＨＢ／ＡＰＢマスタ部品
３６０ ユーザ・トリックボックス部品
４００ マスタＤＵＴ
４１０ ＡＨＢ／ＡＰＢスレーブ部品
４２０ メモリ初期化ファイル
５００ システム・シミュレーション環境
５１０ ＤＵＴ
８００ プロセッサ・コア
８１０ ＲＯＭ
８２０ バス
８３０ ＲＡＭ
８４０ 入力／出力デバイス
８５０ ディスプレイ
【発明の属する技術分野】
本発明はデバイスのバス・プロトコル準拠を試験するための方法およびシステムに関する。
【０００２】
【従来の技術】
システムに統合するための部品を開発する場合、その部品がシステムに統合されたときに所定の動作をするかどうかを確認するために複数の試験手順が実行されるのが普通である。しばしばシステムは１以上のバスを介して互いに接続された複数個の個別部品で構成される。バス仕様が各部品に標準インタフェースを提供することによって、部品供給業者はその部品を最終的に統合するシステムに関する知識なしでもその部品を設計および試験できる場合が多い。
【０００３】
しかし、システム内で特別なバス仕様に従うバスへ接続する部品を開発する場合には、その部品が、その定義されたバス仕様に従うそのバスとインタフェースすることをチェックする必要があるのは明らかである。
【０００４】
ハード的な部品開発は複数の段階を経て行なわれるのが一般的である。まず最初に、その部品の機能的な動作／ビヘイビアが、例えばレジスタ・トランスファ・ランゲージ（ＲＴＬ）を使用して定義される。広く用いられる２つのＲＴＬはＶＨＤＬおよびＶｅｒｉｌｏｇである。更に、そのようなＲＴＬコーディングの前に、設計意図が正しいことをトランザクション・レベルで検証するために、ＵＭＬ（ユニバーサル・モデリング・ランゲージ）を用いてビヘイビア・モデルを構築しても良い。
【０００５】
一旦ハードウエア部品のＲＴＬ表現が開発されれば、次にこれを複数個の既知の合成ツールの任意のものを用いて一連のハードウエア要素の形に合成する。次に、この合成で得られるハードウエア設計を用いて、例えばシリコン上へ部品を適切に作製することによって実際のハードウエア部品が作製される。部品が実際にハードウエアの形に実現された後でその部品に対して試験手順を施すのは明らかにコストを要するので、その代わりに、ＲＴＬ表現から生成される実際のハードウエアが正しく動作することを確認するために、部品のＲＴＬ表現に対して厳格な試験を行なうのが一般的である。
【０００６】
従って、１つの部品が既知のバス仕様と正しくインタフェースすることをチェックするプロセスが部品のＲＴＬ表現に対して適用され、それがバス仕様に定義されたバス・プロトコルに従っていることをチェックするようになっている。そのようなプロトコル・チェックを実行する複数の方法が知られている。
【０００７】
まず、その中に被験デバイス（ＤＵＴ）と呼ぶ試験すべき部品のＲＴＬ表現を含むＲＴＬテストベンチを生成することができる。次に、その他のデバイスのＲＴＬ表現も準備され、バスを介してＤＵＴのＲＴＬ表現と互いにつながれてＲＴＬテストベンチ内にシステム・シミュレーションが生成される。次に、１つのデバイスから別のデバイスへスティミュラスが与えられて、その結果の波形が目で見える形で観測されるか、あるいはシステム・シミュレーションに統合される自己点検機構またはモジュールによって観測される。このプロセスはバス・プロトコルで定義されたトランザクションをチェックできるし、また一般的にすべてのバス・プロトコル・トランザクションが正しく記録されるまでそのチェックを徹底的に繰り返すことができる。
【０００８】
上で述べたＲＴＬテストベンチでバス・プロトコル準拠をチェックするために利用できる別の方法は、ＲＴＬで精巧なバス・フォロワを構築し、次にバス・トラフィックをモニタすることによってバス・フォロワ内部のステート・マシンが任意の有効なポイントにおいて実際のシステム・シミュレーションで観測されるものと合致することを確認するものである。
【０００９】
準拠性をチェックする別の代替法はインテグレーション試験コードを使用するもので、マスタ・デバイスに対してスレーブ・デバイスへのバス上で読出しおよび書込みトランザクションを実行させ、次に目標データが正しく読出しおよび／または書込みされたことをチェックするものである。マスタ・デバイスはバスを介してトランスファ要求を発行するように設計されたデバイスであると考えることができ、またスレーブ・デバイスはそのようなトランスファ要求の受け手のデバイスであると考えることができる。一例として、プロセッサ・コアはマスタ・デバイスとして使用され、メモリからインテグレーション試験コードを読み出すように、またその後でバス・プロトコル準拠性をチェックするために予め定められた一連の読出しおよび書込みトランザクションを実行する試験コードを実行するように構成することができる。そのようなコード・シーケンスはデバイス間の調停を引き起こし、またバス・プロトコルのその他の仕様をチェックするためにデバイスからの特定の応答を誘発するためにも実行することができる。このやり方は、一般に比較的低速であること、またバス・プロトコルを直接的にモニタせずに、バスを介して誘発されたアクションの結果をモニタすることでバス・プロトコル準拠性について仮定する点で既に述べた２つの方法に比べて満足度は劣る。それにも拘らず、このやり方はバス上でのデバイス相互接続を試験する形式として現在でも使用されている。
【００１０】
先に述べたＲＴＬテストベンチ方式の代わりに使用できるプロトコル・チェックを実行する別の既知の方法は、例えばＶｅｒａまたはＳｐｅｃｍａｎのようなＨＶＬ（ハイレベル・ベリフィケーション・ランゲージ）開発ツールを使用してアブストラクト・レベルでバス・トランザクションをモニタするものである。システム・シミュレーション中の各デバイスのＲＴＬ表現を生成する代わりに、それをＲＴＬで書き下ろすことなしに、ＨＶＬ開発ツールを用いてデバイスをモデル化できる。次にそれは例えば開始されたトランスファや進行中のトランスファ等のアブストラクト情報を記録することによってバス・トランザクションをモニタすることができる。
【００１１】
【発明の解決しようとする課題】
当業者には理解されるように、上述の方法の任意のものを用いる場合でも、特に例えば、各デバイスの多数のコンフィグレーションおよび機能を考慮すると、インクリメント・バーストのみをサポートするマスタ・デバイスや書込みトランザクションを受け付けないスレーブ・デバイスのように、特別なマスタ・デバイスやスレーブ・デバイス、あるいはマスタ・デバイスとスレーブ・デバイスとの組合せを試験するプロセスは時間の掛かるプロセスである。最初の２つの方法について考えると、これらのパラメータを提供するためにスティミュラス発生またはＲＴＬバス・フォロワに対して一定のコンフィギュレーションを追加することはできるが、それでもＲＴＬテストベンチは例えばＶＨＤＬやＶｅｒｉｌｏｇのような特別なＲＴＬで表現したＤＵＴのみを試験できるのが普通である。従って、一例として、ＶｅｒｉｌｏｇＤＵＴ用にＶｅｒｉｌｏｇテストベンチを構築すれば、そのＤＵＴのＶＨＤＬバージョンを検証するためにＶＨＤＬテストベンチも必要になるのが普通である。更に、バス・ハンドオーバやアーリー・バースト・ターミネーションのような特定のバス活動が必要となれば、専用のＲＴＬなしにそのタスクの実行を励起することは極めて困難で、デバイスを設計および検証するために要する時間が更に追加されることになる。
【００１２】
ＨＶＬ開発ツール方式はＲＴＬ言語依存性の問題を軽減するが、要求されるチェック・ルーチンを実現するためには高度な技能が必要である。更に、そのようなチェック・ルーチンが再利用できるようにライブラリ・モジュールとして実現できたとしても、各々のチェック環境のコンフィギュレーションおよびデバッグは必要である。
【００１３】
従って、デバイスのバス・プロトコル準拠を試験するための進歩した方法を提供することが望ましい。
【００１４】
【課題を解決するための手段】
第１の態様から眺めると、本発明はデバイスのバス・プロトコル準拠を試験する方法を提供し、その方法は：（ａ）そのデバイスのタイプおよびそのデバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルを読み出す工程；（ｂ）コンフィギュレーション・エンジンを採用して、前記コンフィギュレーション・ファイルに従って選ばれ、バスを介してデバイス表現と接続される試験部品を生成することによってデバイス用の試験環境を動的に生成する工程；（ｃ）テスト・シーケンスを実行させる工程；および（ｄ）テスト・シーケンスの実行中に前記デバイス表現と１個以上の前記試験部品との間で受け渡される信号をモニタすることによってバス・プロトコル準拠性を表示する結果のデータを生成する工程；を含む。
【００１５】
本発明に従えば、デバイスのタイプおよびそのデバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルが用意され、次に、バスを介してデバイス表現とつながれて試験環境を生成するための選ばれた試験部品を生成することによって、試験すべきデバイス用の試験環境が動的に生成される。試験部品はコンフィギュレーション・ファイルに従って選ばれる。次に、テスト・シーケンスを実行でき、テスト・シーケンスの実行中に、デバイス表現と１個以上の試験部品との間で受け渡される信号をモニタしてバス・プロトコル準拠性を表示する結果のデータを生成することができる。
【００１６】
従って、本発明に従えば、コンフィギュレーション・ファイルに定義された被験デバイス（ＤＵＴ）に関連する試験環境が自動的に生成される。コンフィギュレーション・エンジンは多様な異なる試験部品にアクセスし、コンフィギュレーション・ファイルに含まれる情報に基づいて、試験環境へ取り込むために選択できることが好ましい。例えば、コンフィギュレーション・ファイルが試験すべきデバイスをマスタ・デバイスと指定してあれば、コンフィギュレーション・エンジンは試験環境中にデコーダ、アービタ、複数のスレーブ・デバイス、およびダミー・マスタ・デバイスを生成およびコンフィギュアするように構成されよう。アービタは複数のマスタ・デバイス間で行なわれるバス・アクセス要求を調停するために使用され、デコーダはバス上へ発行された任意の特定のトランスファ要求が指しているスレーブ・デバイスを同定するために使用される。
【００１７】
１つの実施の形態では、試験部品はオブジェクト指向型プログラミング（ＯＯＰ）のオブジェクトとして書かれ、試験環境に含めるための試験部品を生成する工程には、試験部品のインスタンス化（すなわち、オブジェクトのインスタンス生成）が含まれ、このオブジェクトのメソッドがインスタンス化された試験部品の試験環境内でのビヘイビアを定義する。しかし明らかなように、ＯＯＰ技術を使用する必要は必ずしもなく、試験部品は任意のその他の適当なやり方で表現することができる。
【００１８】
本発明の方法に従ってデバイスの試験準備を行なう場合、ユーザはコンフィギュレーション・エンジンがそのデバイスに適した試験環境を動的に生成するために知っておく必要があるパラメータを含むコンフィギュレーション・ファイルを用意する必要がある。好適な実施の形態では、コンフィギュレーション・ファイルは１組のコンフィギュレーション・ファイル・テンプレートから選ばれる。その組には各デバイス・タイプについてのコンフィギュレーション・ファイル・テンプレートが含まれ、各コンフィギュレーション・ファイルにはそのデバイスに特有なコンフィギュレーション情報を提供するための複数のエントリが含まれる。コンフィギュレーション情報は多様な形態を取るが、典型的にはそのデバイスのタイプの同定、およびそのデバイスの機能を含む。すなわち一例として、デバイスのタイプはマスタ、スレーブ、アービタ、デコーダ等と指定される。デバイスの機能は、例えば、そのデバイスがサポートする必要のあるバス・プロトコルのサブセットを指定する。すなわち、ＤＵＴは必ずしもそのバスの性能のすべてを利用する必要はなく、デバイスによって利用されないバス・プロトコル部分に関する準拠性を試験する必要はない。
【００１９】
デバイスのタイプおよびデバイスの機能に加えて、コンフィギュレーション・ファイル中のその他のコンフィギュレーション情報には、ＤＵＴ内で使用される信号名がバス仕様の信号名とどのように対応するかを示す信号マップのほかに、例えば、デバッグやシステム環境設定に関連する一般的なテストベンチ・パラメータが含まれる。
【００２０】
明らかなように、テスト・シーケンス実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号をモニタするために使用できる複数のプロセスが存在する。好適な実施の形態では、このモニタ工程には、プロトコル・チェック・コンポネントを採用して、テスト・シーケンス実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号が、バス・プロトコルの予め定められた１組の規則に違反しないことをチェックする工程が含まれる。そのようなプロトコル・チェックには、被験デバイスが予め定められた１組の規則に従うことを確認するためのサイクル毎のチェックが含まれる。試験されるデバイスはそれがバス・プロトコルに準拠すると判断されるためには、それらの規則のいずれにも違反してはならない。典型的は、予め定められた規則の組は試験されるデバイスに拘わらず同一であり、従って予め定められた規則の組は好適な実施の形態のコンフィギュレーション・ファイルの内容によって影響されない。
【００２１】
好適な実施の形態で採用できる別のモニタ・プロセスは、カバレッジ・モニタ・コンポネントを採用して、テスト・シーケンスの実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号をモニタして、１組のカバレッジ・ポイントが観測されるかどうかを判定する工程を含む。カバレッジ・ポイントは典型的には、バス・プロトコル準拠を表明する前に試験環境内で確認すべき各種バス・トランザクションのリストである。カバレッジ・ポイントの目的は、実行されるテスト・シーケンス（単数または複数）が試験されるデバイスを十分活用して準拠性が表明できることを保証することである。
【００２２】
好適な実施の形態では、カバレッジ・ポイントの組は試験方法の工程（ａ）で読み出されるコンフィギュレーション・ファイルに依存してコンフィギュアされる。従って、試験される任意の特定デバイスはバス・プロトコルのすべての機能を使用しなくてもよく、カバレッジ・ポイントはコンフィギュレーション・ファイルに基づいて、試験されるデバイスに関連するカバレッジ・ポイントの組を指定するように調整することができる。標準的な予め定義されたバス・トランザクションのシーケンスの代わりにカバレッジ・ポイントを使用することの利点は、そうすることによって、特別なトランザクション・シーケンスを必要とするだけで特定デバイスがバス・インタフェースを完全に活用することができるということである。
【００２３】
好適な実施の形態では、試験方法の工程（ｄ）でプロトコル・チェック・コンポネントおよびカバレッジ・モニタ・コンポネントの両方が使用され、それによって、前記組中のすべてのカバレッジ・ポイントがバス・プロトコルの予め定められた規則に違反せずに観測されれば、この方法は更にバス・プロトコル準拠を確認する出力を発生する工程を含む。この出力は、例えばコンフィギュレーション・ファイルに規定された元のデバイス性能を与えた場合にバス・プロトコル準拠を保証するチェック・サム証明のような準拠性証明の形を取る。
【００２４】
先に述べたように、コンフィギュレーション・エンジンは、コンフィギュレーション・ファイルに従って選ばれた試験部品を生成するように構成される。好適な実施の形態では、生成すべき試験部品は試験すべきデバイスのタイプに従って選ばれる。このデバイス・タイプはコンフィギュレーション・ファイルに規定される。
【００２５】
更に好適な実施の形態では、少なくとも１つの試験部品はそれに付随してそれが示すであろう複数のビヘイビアを有しており、ビヘイビアの選択は試験すべきデバイスのタイプに依存してその試験部品が生成されるときに決まる。例えば、試験すべきそのデバイスがスレーブ・デバイスで、試験部品の１つとしてデコーダが生成される場合、好適な実施の形態では、試験すべきデバイスの選択を解除して、別のスレーブを選択させるようなビヘイビアを採用する。これは明らかに、スレーブ・デバイスを試験するときに、デコーダに含めるべき有用なビヘイビアである。しかし、試験すべきデバイスがマスタ・デバイスである場合には、デコーダのこのビヘイビアは関連性がなく、デコーダ試験部品のビヘイビア全体から省くことができる。先に述べたように、好適な実施の形態では、各試験部品はＯＯＰオブジェクトとして書かれ、それらのオブジェクトのインスタンス化は、次に、試験環境を生成するときにコンフィギュレーション・エンジンによって生成される。そのような実施の形態では、複数のビヘイビアがＯＯＰオブジェクトの個別メソッドとして実現され、そのメソッド（単数または複数）はインスタンスを作成する場合に選ばれる任意のインスタンスに適用可能である。これをＯＯＰ用語では“継承”と呼ぶ。
【００２６】
明らかなように、工程（ｃ）で試験方法が実行するテスト・シーケンスは多様な形態を取ることができる。例えば、テスト・シーケンスは予め決められたテスト・シーケンスの組から選ぶことができる。しかし、好適な実施の形態では、テスト・シーケンスは試験すべきデバイス用に特別に開発されたユーザ定義のテスト・シーケンスであり、試験すべきその特別なデバイスに関連するバス・プロトコル部分への準拠性を試験する目的を持つ。試験方法の工程（ｃ）および（ｄ）は、バス・プロトコルとの準拠性を確定するため十分なトランザクションが観測されるまで、工程（ｃ）において毎回テスト・シーケンスを変更または修正しながら繰り返してよい。
【００２７】
明らかなように、デバイス表現は複数のやり方で試験環境に取り込むことができる。しかし、好適な実施の形態では、デバイス表現はインタフェース・モジュール中に生成され、試験環境を生成する前記工程（ｂ）にはインタフェース・モジュール中の信号を試験環境中の信号へマッピングする工程が含まれる。このマッピングはコンフィギュレーション・ファイルに定義されている。インタフェース・モジュールはデバイス表現を取り巻く“ラッパ”として機能し、試験環境の残りの部分に対してインタフェースを提供する。
【００２８】
典型的には、デバイス表現はインタフェース・モジュールの唯一の要素ではない。例えば、インタフェース・モジュールの一部として何らかのクロックおよび多重化機能を提供することも可能であり、実際に或る実施の形態ではその他のデバイス表現がインタフェース・モジュールに含まれている。従って、本発明の好適な実施の形態では、信号のマッピングを容易にするために、インタフェース・モジュール内のデバイス表現の階層レベルをコンフィギュレーション・ファイルが指定する。
【００２９】
好ましくは、本方法は更に、バス・プロトコルと互換性を持ち、汎用の入力／出力インタフェースを備えるトリックボックス・コンポネントを提供する工程を含む。トリックボックスは、バス・プロトコルには関連しないが被験デバイスに関連する信号の制御および観測を許容する。トリックボックスは一般に、そのような信号を入力および出力するための入力および出力ポートを持ち、そのほかにトリックボックスを制御するための、バスへのスレーブ・インタフェースを備える。スレーブ・インタフェースは、トリックボックスが試験環境内でインスタンス化できて、被験デバイスよりもトリックボックスにアクセスするテスト・シーケンスを用いて制御できることを意味する。好適な実施の形態では、トリックボックスは試験すべきデバイス表現を含むインタフェース・モジュールに含まれている。明らかなように、或る実施例では、異なる試験手順を容易にするために複数のトリックボックス・コンポネントが採用されよう。
【００３０】
先に述べたように、試験すべきデバイスのタイプは好ましくはマスタ、スレーブ、アービタ、あるいはデコーダのいずれかである。好適な実施の形態では、バス・プロトコルはＡＲＭ ＡＭＢＡバス・プロトコルであり、バスはシステム・バスおよびペリフェラル・バスを含み、試験されるデバイスのタイプにはシステム・バス・マスタ、システム・バス・スレーブ、ペリフェラル・バス・マスタ、ペリフェラル・バス・スレーブ、アービタ、あるいはデコーダが含まれる。当業者には明らかなように、ペリフェラル・バス・マスタはペリフェラル・バスとシステム・バスとを接続するブリッジである。
【００３１】
試験環境に取り込まれるデバイス表現は多様な形態を取る。しかし、好適な実施の形態では、デバイス表現はレジスタ・トランスファ・ランゲージ（ＲＴＬ）表現である。
【００３２】
第２の態様から眺めると、本発明は、本発明の第１の態様に従う、デバイス準拠性を試験する方法を実行するように処理ユニットをコンフィギュアするように働くコンピュータ・プログラムを提供する。本発明はまた、本発明の第２の態様に従うコンピュータ・プログラムを含む運搬媒体を提供する。
【００３３】
第３の態様から眺めた場合、本発明はデバイスのバス・プロトコル準拠を試験するためのデータ処理システムを提供する。本システムは：デバイスのタイプおよびデバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルを記憶するためのメモリ；および次の：（ｉ）コンフィギュレーション・ファイルに従って選ばれ、バスを介してデバイス表現と接続されて試験環境を形成する試験部品を生成することによって、デバイスのための試験環境を動的に生成する工程；（ii）テスト・シーケンスを実行する工程；および（iii）前記テスト・シーケンスの実行中にデバイス表現と１個以上の試験部品との間で受け渡される信号をモニタして、バス・プロトコル準拠性を表示する結果のデータ生成する工程；を実行するように構成された処理ユニット；を含む。
【００３４】
本発明は試験すべきデバイスが１個の場合について説明してきたが、明らかなように、本方法を複数デバイスの同時試験に適用することを妨げるものは原理的に何もない。
【００３５】
本発明は試験すべきデバイスのための試験環境を動的に生成する。試験環境は試験すべきデバイスに関連するコンフィギュレーション・ファイルに含まれる情報に従って生成される。この試験法を今後は“能動”モードと呼ぶことにする。しかし、好適な実施の形態では、既述の試験法を提供するために用いるソフトウエア・ツールを、システム・シミュレーション環境が既に存在し、従って試験環境を動的に生成する必要がない過去のシミュレーション環境に対しても互換的に使用することができる。このモードを今後“受動”動作モードと呼ぶ。このような動作モードでもコンフィギュレーション・ファイルが定義され、それを用いて、試験中にシステム・シミュレーション環境内の各種デバイス間で受け渡される信号をモニタするために使用されるプロセスをコンフィギュアする。
【００３６】
本発明は更に、一例として添付図面に示す本発明の好適な実施の形態を参照しながら説明する。
【００３７】
【発明の実施の形態】
本発明の好適な実施の形態を説明するために、ＡＲＭ社によって開発された“アドバンスト・マイクロコントローラ・バス・アーキテクチャ”（ＡＭＢＡ）仕様に従って動作するバスへつながるデバイスの試験について説明する。試験手順を詳しく説明する前に、ＡＭＢＡ仕様に従って動作するバスを採用するデバイスの実現について図１を参照しながら簡単に説明する。
【００３８】
図１はマイクロコントローラ・チップあるいはシステム・オン・チップ（ＳｏＣ）１０の形の集積回路を示しており、それはパーソナル・オーガナイザ、移動電話、テレビ用トップボックス等の装置に使用されよう。チップ１０は、ブリッジ回路１７０を介してつながれたシステム・バス１１０（今後はＡＨＢとも呼ぶ）およびペリフェラル・バス１９５（今後はＡＰＢとも呼ぶ）を含む。これらのバスはＡＭＢＡ仕様に従って動作する。ＡＭＢＡ仕様は高性能の３２ビットおよび１６ビット埋め込みマイクロコントローラを設計するためのオンチップ通信標準を定義しており、システム・バス１１０は高性能なシステム・モジュール用に、またペリフェラル・バスは低電力周辺デバイス用に用いられる。高性能システム・バス１１０は、ＣＰＵおよびその他のダイレクト・メモリ・アクセス・デバイスをシステム・バス上においたままで外部メモリ帯域幅を維持することができ、他方ブリッジ回路１７０はシステム・バスをより狭いペリフェラル・バス１９５へ接続し、ペリフェラル・バス上には狭帯域幅の周辺デバイスが配置される。ブリッジ回路１７０はシステム・バス１１０とペリフェラル・バス１９５との間で必要なプロトコル変換を実行する。
【００３９】
チップ１０は例えばＣＰＵ１４０やＤＭＡコントローラ１４５のような、システム・バス１１０へつながれる複数のマスタ論理ユニットを含むことができる。ここでは説明の便宜上、“マスタ”論理ユニットという用語は処理要求を発行するように設計された論理ユニットを意味し、他方そのような処理要求の受け手として設計された論理ユニットを“スレーブ”論理ユニットと呼ぶことにする。時間的に任意の瞬間にシステム・バスへアクセスするのはマスタ論理ユニットのうちの１つだけであり、このためシステム・バス１１０への各種マスタ論理ユニットによるアクセスを制御するためにアービタ１２０が提供される。１つのマスタ論理ユニットがシステム・バス１１０へアクセスしようとするときは、それはアービタ１２０に対してバス要求信号を発行する。時間的に任意の瞬間にアービタ１２０によって受信されるバス要求信号が１つのみであれば、それはそのバス要求信号を発行したマスタ論理ユニットに対してアクセスを許可する。しかし、時間的に任意の瞬間にアービタ１２０によって２つ以上のバス要求信号が受信されれば、アービタはどのマスタ論理ユニットにシステム・バス１１０へのアクセスを与えるかを決めるために、予め定められた優先基準を適用するようになっている。バスへのアクセスを要求するすべてのマスタ論理ユニットのうちで、アービタ１２０は最も高い優先度を有するマスタ論理ユニットにアクセスを許可する。
【００４０】
マスタ論理ユニットに加えて、１以上のスレーブ論理ユニットをシステム・バス１１０へつなぐこともある。分かり易いように、１つのスレーブ論理ユニット、例えばランダム・アクセス・メモリ（ＲＡＭ）１６０だけが図１には示されている。トランスファ要求がスレーブ論理ユニットに対して発行された場合、アドレスがシステム・バス１１０上へ出力され、それがデコーダ論理１６５で復号されてどのスレーブ論理ユニットがそのトランスファ要求を処理することになっているかが決められる。デコーダは次にそれに従って適当なスレーブ論理ユニットを指定する。
【００４１】
システム・バス１１０はまた外部バス・インタフェース１３０を介して外部バス１１５へつなぐことができる。好適な実施の形態では、外部バス１１５は３２ビットのベクトル・バスである。
【００４２】
また、システム・バス１１０へつながれる各種の論理ユニットの動作周波数を制御するためにクロック発生器１７５が設けられる。これによって、マスタ論理ユニットによって出力されるトランスファ要求信号のタイミングはクロック発生器１７５のクロック周波数で決まることになる。
【００４３】
ペリフェラル・バス１９５には複数の周辺デバイスが接続されよう。そのような周辺デバイスの例は、シリアル・データを受信および送信するための“ユニバーサル非同期受信および送信”（ＵＡＲＴ）論理ユニット１５０、例えば割り込みを発生するために用いられるタイマ１５５、短距離の高速赤外通信のために用いられる赤外線通信（ＩｒＤＡ）インタフェース１８０、ユニバーサル・シリアル・バス（ＵＳＢ）１８５、同期データ・リンク制御（ＳＤＬＣ）インタフェース２００、およびアナログ・ディジタル（Ａ／Ｄ）およびディジタル・アナログ（Ｄ／Ａ）変換器２０５および２１０である。
【００４４】
図１に示すマイクロコントローラ・チップ１０では、ペリフェラル・バス１９５はシステム・バス１１０と同じクロック速度で動作するように構成されている。従って、システム・バス１１０用としてクロック発生器１７５で生成されるクロック信号はブリッジ１７０にも送られ、ブリッジ１７０は周辺ユニット１５０、１５５、１８０、１８５、２００、２０５、および２１０の動作を制御するために必要なクロック信号を発生させるように構成されている。
【００４５】
マスタ論理ユニット１４０、１４５が、ペリフェラル・バス１９５へつながれた周辺ユニットによるハンドリングを要求する処理要求をシステム・バス１１０上へ発行するときは、ブリッジ１７０がその処理要求信号を受信し、周辺ユニット１５０、１５５、１８０、１８５、２００、２０５、２１０のどれに対してその処理要求が向けられているかを判断し、正しい周辺ユニットに対して、その周辺ユニットの動作を制御するために必要なクロック信号と一緒にその処理要求を出力する。更に、その処理要求をペリフェラル・バス上へ出力する前に、システム・バス１１０で使用されるプロトコルと、ペリフェラル・バス１９５で使用されるプロトコルとの間で必要なプロトコル変換工程がブリッジ１７０によって実行される。
【００４６】
図１に示す構造では、メイン・システム・バス１１０に負荷を掛けずに複数の周辺ユニットをペリフェラル・バス１９５へつなぐことができ、ペリフェラル・バス１９５は１つの周辺ユニットへアクセスする必要が生じたときだけ使用されるので、全体として電力消費が削減される。
【００４７】
ＡＭＢＡ仕様は、複数の異なる部品を集積化することによって迅速にＳｏＣデバイスを構築することを目的にしている。ＡＭＢＡ仕様は、標準インタフェースを提供することでこのプロセスを可能にする。これにより、個々の個別部品の開発業者は標準インタフェースを利用することで、その部品が最終的に統合されるシステムに関して知識を何ら持たなくても、その部品（ここでは被験デバイス（ＤＵＴ）とも呼ぶ）を設計および試験することができるようになる。従って、一例として、図１のＣＰＵ１４０をＳｏＣ１０へ統合するように設計する場合、設計者はＳｏＣ１０にはそのほかにどのようなデバイスが組み込まれるかを知る必要がない。
【００４８】
しかし、ＡＭＢＡ仕様に従うバスを利用して後にＳｏＣへ組み込まれる個別デバイスを設計する場合には、設計者がそのデバイスがＡＭＢＡ仕様によって規定されるバス・プロトコルに従っていることを確認するための試験を実行することは明らかに重要なことである。実際に、ＳｏＣ設計者は、集積業者に対してその部品がＳｏＣ設計の残りの部分と統合されたときに正しく機能することを確信させるために、個別部品がＡＭＢＡバス・プロトコルに準拠するという何らかの確証を得たいと思うのが普通である。
【００４９】
【実施例】
図２は、ＤＵＴがＡＭＢＡバス・プロトコルに準拠することを本発明の好適な実施の形態の能動モードにおいて試験するために提供される論理要素を模式的に示すブロック図である。図２に示すように、ＤＵＴ３３０は、ＤＵＴ３３０用の試験環境を生成するために使用されるＡＭＢＡ部品テストベンチ３００へバス３４０を介してつながれる。好適な実施の形態では、ＡＭＢＡ部品テストベンチはソフトウエア的に実現され、ユーザが定義するテスト・シーケンス・ファイル３０５からスティミュラス発生および応答チェック情報を読み出すように構成されている。このファイルはそのＤＵＴが利用するＡＭＢＡバス・プロトコル部分に対するＤＵＴの準拠性を試験する目的を持ってそのＤＵＴ３３０に関心を持つユーザによって提供される。
【００５０】
図２に示すシミュレーション環境はまた、プロトコル・チェック・コンポネント３２０およびカバレッジ・モニタ・コンポネント３１０を含む。プロトコル・チェック・コンポネント３２０は好適な実施の形態では、ＤＵＴ３３０がＡＭＢＡ仕様の規則に従うことを確認するためのチェックをサイクル毎の実行するように構成されている。プロトコル・チェックはＡＭＢＡ仕様から取り出された一定の規則群であり、ＤＵＴはＡＭＢＡ仕様に準拠することを主張するためにはそれらの規則のどれにも違反してならない。それらの規則はＤＵＴ３３０がどのようなタイプのものであろうとも従わなければならないし、従ってＤＵＴ３３０に依存してプロトコル規則をコンフィギュアするようなことはない。
【００５１】
当業者には明らかなように、どんな特殊なバス・プロトコルに対しても、チェックする必要のあるそのような規則はかなり多いのが普通である。ＡＭＢＡ ＡＨＢマスタ・プロトコル規則の一例は、“ＳｐｌｉｔあるいはＲｅｔｒｙ応答の第２サイクルで、マスタはＨＴＲＡＮＳをＩＤＬＥにドライブしなければならない”である。ＳｐｌｉｔまたはＲｅｔｒｙ応答はスレーブ・デバイスからマスタ・デバイスへの応答であって、スレーブ・デバイスがその時点に行なわれたマスタからのトランスファ要求を処理できないことを示す。ＨＴＲＡＮＳ信号はマスタによって発行される制御信号であって、マスタが実行しているバス・トランスファのタイプ、例えばノンシーケンシャル、シーケンシャル、アイドル、あるいはビジーを示す。トランスファ要求のｒｅｔｒｙを試みる前に、スレーブ・デバイスが別のトランスファ要求を受信する準備ができている状態に戻る機会を与えるためには、ＳｐｌｉｔまたはＲｅｔｒｙ応答に続くサイクルでアイドル・トランスファをアサートする必要がある。
【００５２】
カバレッジ・モニタ・コンポネント３１０は、テスト・シーケンス３０５実行中に、ＡＭＢＡ部品テストベンチ３００によって生成される試験環境内でＤＵＴ３３０とその他の任意の試験部品との間で受け渡される信号をモニタすることによって１組のカバレッジ・ポイントが観測されるかどうか決定するために使用される。カバレッジ・ポイントは、準拠性を主張できる前に、試験環境内で観測すべき各種バス・トランザクションのリストである。従って、カバレッジ・ポイントの目的は、準拠性を主張できる前に、試験によってＤＵＴが十分に調べられたことを保証することである。カバレッジ・ポイントの一例は、“バス・スレーブは同じアドレスへの書込みトランスファが直後に続く読出しトランスファによってアクセスされなければならない”である。
【００５３】
明らかなように、確認する必要のあるカバレッジ・ポイントはＤＵＴ３３０に依存する。例えば、マスタＤＵＴは異なるやり方でスレーブＤＵＴとインタフェースするであろうから、準拠性を保証するために確認すべき各種バス・トランザクションはＤＵＴのタイプ毎に異なるであろう。従って、カバレッジ・モニタ・コンポネント３１０は試験される特定のＤＵＴ３３０に関連して得られるコンフィギュレーション情報３１５に従ってコンフィギュアされる。
【００５４】
従って、理解されるように、標準的な予め定義されたバス・トランザクションのシーケンスの代わりにカバレッジ・ポイントを使用する利点は、カバレッジ・ポイントを利用することによって、バス・インタフェースを完全に活用するためには特定のＤＵＴが１つの特別なトランザクション・シーケンスを必要とするだけでよいということである。
【００５５】
注意すべきことは、プロトコル・チェック・コンポネント３２０およびカバレッジ・モニタ・コンポネント３１０は準拠性試験中にトランスファされる実際のデータの完全性を自動的にはチェックしないということである。ユーザは準拠性実行中にＤＵＴが正しく動作することを確認しなければならない。しかし、図２のようにコンフィギュアされたときは、シミュレーション環境は、ユーザが定義するテスト・シーケンス入力ファイルの“データ・チェック・コマンド”をサポートすることによってＤＵＴの動作試験を支援する。例えば、データがスレーブＤＵＴに記憶され、そしてその後でスレーブＤＵＴから読み戻される場合、ユーザが定義するテスト・シーケンスはスレーブＤＵＴから返されると期待されるデータの値を指定することができ、それをチェックして正しい動作を確認することができる。
【００５６】
後でもっと詳細に説明することになるが、図２に模式的に示す能動モードのシミュレーション環境を利用する場合、ユーザはユーザが定義するテスト・シーケンス３０５、ＤＵＴ３３０のＲＴＬ実現、およびＤＵＴに特有なコンフィギュレーション情報を提供するユーザ・コンフィギュレーション・ファイルを提供することが好ましい。これら３つのアイテムは好適な実施の形態ではテストベンチのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を通して供給され、それらがその後に試験環境を生成する。このプロセスは後でもっと詳しく説明する。
【００５７】
上で述べた能動動作モードでは、ＤＵＴ３３０のバス・プロトコル準拠を試験するためにＤＵＴ３３０と相互作用するために必要な各種のその他部品に対してユーザがＲＴＬモデルを生成する必要はない。好適な実施の形態では、好適な実施の形態のテストベンチＡＰＩが準拠性ツールの中に組み込まれ、このツールが次に既知のハイレベル・ベリフィケーション・ランゲージ（ＨＶＬ）シミュレーション・ツール、例えばＶｅｒａやＳｐｅｃｍａｎとインタフェースする。準拠性ツール、およびこのツールの一部を構成するコンフィギュレーションＡＰＩの存在は、ユーザによって与えられる入力、すなわちユーザ・コンフィギュレーション・ファイル、ユーザが定義するテスト・シーケンス、およびＤＵＴのＲＴＬ表現に基づく試験環境の動的生成を可能にする。従って、準拠性ツールは、さもなければＨＶＬシミュレーション・ツールを使用して必要とされるチェック・ルーチンを実現するために要したであろう高度な技能を不要とし、また各チェック環境のコンフィギュレーションおよびデバッグを不要とする。
【００５８】
上で図２を参照しながら説明した準拠性ツールの能動モードは最初からＤＵＴ３３０を生成する場合には明らかに有利であるが、例えばバスを介してインタリンクされた部品の複数のＲＴＬ実現を含めて、ユーザがかなりうまくシステム・シミュレーション環境を既に開発している状況も多いと思われる。好適な実施の形態では、そのようなシステム・シミュレーション環境を利用できるようにするために、準拠性ツールは図５に示す受動的な動作モードもサポートする。図５に示すように、既存のシステム・シミュレーション環境５００を準拠性ツールにロードし、バス３４０を介してＤＵＴ５１０へ接続することができる。それでもなお、カバレッジ・モニタ３１０およびプロトコル・チェッカ３２０は維持され、試験中に各種デバイス間で受け渡される信号に対して必要なチェックを実行できるし、またカバレッジ・モニタ３１０もＤＵＴ５１０に関連するコンフィギュレーション情報３１５に基づいてコンフィギュアできる。従って、図５の受動モード実施例では、ユーザがコンフィギュレーションＡＰＩを介して、ユーザ・コンフィギュレーション・ファイル、既存のシステム・シミュレーション環境５００、およびＤＵＴ５１０のＲＴＬ実現を提供する。
【００５９】
従って、要約すれば、好適な実施の形態の準拠性ツールは、図２に示すような能動モードか、あるいは図５に示すような受動モードのいずれかで動作するようにコンフィギュアできる。ここでコンフィギュレーションＡＰＩが提供されるため、ユーザはそれら２つの異なるコンフィギュレーションを指定するために必要な情報を入力できる。
【００６０】
能動モードのコンフィギュレーションを実現する２つの例が図３および図４に示されている。これらの好適な実施の形態では、能動モードのコンフィギュレーションは次のようなデバイスをサポートする：ＡＨＢマスタ、ＡＨＢスレーブ、ＡＰＢマスタ（すなわち、ブリッジ）、ＡＰＢスレーブ、アービタ、およびデコーダ。図３はＤＵＴ３３０がスレーブＤＵＴである能動モードのコンフィギュレーションを示している。このコンフィギュレーションでは、準拠性ツールのＡＭＢＡ部品テストベンチ・コア３５０内のコンフィギュレーション・エンジンは、例えばデコーダのような必要とされる任意のその他の試験部品とともに、適当なＡＨＢ／ＡＰＢマスタ部品３５５を動的に生成しよう。スレーブＤＵＴ３３０はそれがマスタ・デバイスに応答するかのようにバスにアクセスする。しかし、その回りに生成される試験環境はユーザが定義するテスト・シーケンス３０５によって指図されるような命令された応答をドライブする。プロトコル・チェック・コンポネント３２０およびカバレッジ・モニタ・コンポネント３１０は、それに従ってテスト・シーケンスの実行中にバス上で受け渡される信号をモニタすることによって、スレーブＤＵＴがバス・プロトコルに準拠するかどうかを示すデータを生成する。
【００６１】
好適な実施の形態では、ユーザ・トリックボックス・コンポネント３６０も提供されて、ビヘイビアを追加できるようにスレーブ応答信号との多重化が行なわれる。ユーザ・トリックボックス３６０は好適な実施の形態ではＲＴＬで書かれ、ユーザ・トリックボックス３６０とスレーブＤＵＴ３３０の両方を含むインタフェース・モジュール内でインスタンス化される。後で詳しく説明するように、このインタフェース・モジュールは次に、適当な信号のマッピングを介して準拠性ツールによって生成される試験環境の残りの部分とインタフェースする。従って、ＲＴＬトリックボックス３６０はＤＵＴ３３０とインタフェースすることができ、ＤＵＴの非ＡＭＢＡ信号を制御および観測することを可能にする。
【００６２】
好適な実施の形態のトリックボックスは、トリックボックスを制御するための標準的なＡＨＢ／ＡＰＢスレーブ・インタフェースのほかに、３２ビット出力ポートおよび３２ビット入力ポートを有する。ＡＨＢ／ＡＰＢインタフェースはトリックボックスがテストベンチでインスタンス化され、ＤＵＴではなくトリックボックスにアクセスするテストベクトルを用いて制御されることを可能にする。この文脈で用いられるように、“ベクトル”という用語はユーザが定義するテスト・シーケンス３０５の１要素を意味し、それはバス上で実行されるアクションおよび／または特別な時間におけるバス・ステータスを定義する。トリックボックス３６０を用いて導入される付加的なビヘイビアの一例として、もしも図３の能動モードがＡＨＢ能動モードであると仮定すれば、トリックボックス３６０を用いて別のスレーブ・デバイスのような期待される応答を提供することができ、デコーダ試験部品を用いてスレーブＤＵＴ３３０の選択を解除し、トリックボックス・スレーブ・デバイスを選択することができる。
【００６３】
図４はマスタＤＵＴ４００を試験するために実現される別の能動モードを示す。この構成では、準拠性ツールのＡＭＢＡ部品テストベンチ・コア３５０内のコンフィギュレーション・エンジンを使用して、例えばアービタ、デコーダ、およびダミー・マスタのような必要とされるその他任意の試験部品と一緒にＡＨＢ／ＡＰＢスレーブ部品４１０が生成されよう。コンフィギュレーションおよび／またはＤＵＴのタイプに依存して準拠性ツールの中からある種のファシリティを追加することもできる。例えば、ＡＨＢマスタ・コンフィギュレーションの場合は、メモリ初期化ファイル４２０を有するビヘイビア・メモリ・スレーブ・デバイスを生成することが好ましく、それはそれ自身が同じフォーマットのメモリ・ダンプを生成する。メモリ・ダンプ・ファイルはテストベンチ・コア３５０内に実現されたメモリ・モデルの内容のファイル表現であり、試験が完了した後で生成される。試験中にメモリ・モデルに対して修正がなければ、結果のメモリ・ダンプ・ファイルはメモリ初期化ファイルと同じ内容を有することになる。
【００６４】
図４のマスタＤＵＴ４００はあたかもスレーブ・デバイスを通信しているようにバスにアクセスする。しかし、その回りに生成される試験環境はユーザが定義するテスト・シーケンス３０５によって定義されるような命令された応答をドライブ・バックする。図３の例と同じように、ユーザ・トリックボックス・コンポネント３６０を提供して、それをスレーブ応答信号と多重化することによってビヘイビアを追加することができる。
【００６５】
上の能動モードの説明から明らかなように、準拠性ツールの能動モードコンフィギュレーションは各ＤＵＴに対してポイント・ソリューションとなるテストベンチを生成しなければならないという負担を大幅に軽減する。準拠性ツールそれ自身は、ユーザが供給するスティミュラスを準拠性試験の過程で提供するように、ＤＵＴを取り巻く、必要なすべてのＡＭＢＡ“ファブリック”を生成する。
【００６６】
これとは対照的に、先に述べた受動モードは、主としてシステム中の試験環境を目的としている。受動モードは準拠性ツールによるＡＭＢＡファブリックの動的生成という概念を等価的に禁止し、そうでなければ能動モードで利用できたスティミュラス・ドライブ機能を禁止する。既に述べたように、同じユーザ・コンフィギュレーション・ファイルをＤＵＴそれ自身に関する詳細を指定するためにも使用することが好ましい。しかし受動モードでは、能動モード特有のコンフィギュレーション・オプションはすべて無視される。
【００６７】
受動モードはまた過去の設計を検証するためにも理想的であり、ユーザは準拠性試験のためにＤＵＴを能動モードのテストベンチへ分離する必要がない。しかし注意すべきことは、ＤＵＴへのスティミュラスの発生源が限られたトランザクションまたはシナリオ生成能力しか持たない場合は（すなわち、能動モードにおいて使用される、ユーザが定義するテスト・シーケンスの場合ほどにはＤＵＴに対して適するように調整されていないのが普通である）、全カバレッジを達成することは受動モードのほうがより困難であろうということである。もっと可能性の高いシナリオは、受動モードを使用して、試験実行シーケンスの過程でＤＵＴがＡＭＢＡプロトコル違反を何ら行なわなかったことを保証することであろう。
【００６８】
いずれの動作モードでも、準拠性ツールは試験実行の終わりにオプションで目に見える形でカバレッジ・レポートを生成することが好ましい。これはそのＤＵＴに付随する、完了し傑出した準拠性カバレッジ目標とその特別な機能に関するコンフィギュレーションの両方を表示するグラフィカル・ユーザ・インタフェース（ＧＵＩ）の形であることが好ましい。このデータからＡＭＢＡ準拠性の証明を発行できる。好適な実施の形態では、ＡＭＢＡ準拠性証明は、ＡＭＢＡ仕様改訂版番号、準拠性コンフィギュレーション、および試験しなかったすべての準拠性カバレッジ・ポイントの説明を指定するであろう。好適な実施の形態では、準拠性ツールはまた、ＤＵＴ用の試験環境を許可し、それとともにユーザが準拠性試験を繰り返すことができるように必要な任意のテストベクトルを出力することを許可する。
【００６９】
既に述べたように、好適な実施の形態では、準拠性ツールは標準的なＨＶＬシミュレーション・ツールと組み合わせて実行するのが好ましい。ここで、シミュレーション・ツールと準拠性ツールとが一緒になって準拠性チェックを実行するプロセスについて、図６および図７のフロー図を参照しながら詳細に説明する。
【００７０】
図６に示すように、準拠性チェックは工程６００から始まり、工程６０５へ進んでそこからシミュレーション・ツールが始動する。シミュレーション・ツールが始動すると、それは準拠性ツールを使用すべきことを指示する。プロセスは次に工程６１０へ進み、ＤＵＴインタフェース・モジュールがロードされる。既に述べたように、このインタフェース・モジュールはその中へＤＵＴのＲＴＬ表現をインスタンス化するモジュールである。好適な実施の形態では、インタフェース・モジュールはまたユーザ・トリックボックスのＲＴＬ表現も含む。更に、インタフェース・モジュールはオプションのクロックおよびリセット信号を提供し、それと一緒に、ＲＴＬと準拠性ツールの試験環境それ自身との間の付随する信号多重化も提供する。このことから、インタフェース・モジュールは、与えられたユーザ・コンフィギュレーション・ファイルに基づいてシミュレーション時点で能動モードにおいて動的に生成される準拠性ツール試験環境とのインタフェースを構成する簡単なＲＴＬの最上位モジュールとみなすことができる。
【００７１】
工程６１５では準拠性ツールがロードされるが、これは能動あるいは受動のいずれかのモードにツールをコンフィギュアするために使用されるコンフィギュレーションＡＰＩを、カバレッジ・モニタおよびプロトコル・チェック機能と一緒に導入する。工程６２０では、シミュレーション・ツールが準拠性ツールに処理を渡し、その後プロセスは工程６２５へ進む。
【００７２】
工程６２５では、準拠性ツールが、ユーザによってコンフィギュレーションＡＰＩを介して与えられるユーザ・コンフィギュレーション・ファイルを読み込んでチェックする。好適な実施の形態では、各々の準拠性ツールの動作モード、例えばＡＨＢ＿マスタ、ＡＨＢ＿スレーブ、ＡＰＢ＿マスタ、ＡＰＢ＿スレーブ、アービタ、あるいはデコーダに対してテンプレートのユーザ・コンフィギュレーション・ファイルが提供される。従って、ユーザがＡＨＢマスタ・デバイスを試験しようとする場合には、ユーザはＡＨＢ＿マスタのテンプレート・ユーザ・コンフィギュレーション・ファイルを選ぶ。コンフィギュレーション・ファイルにはそのデバイスに特有なコンフィギュレーション情報を規定する予め定められたパラメータが含まれる。それらのエントリの少なくともいくつかは、試験される特定デバイスに関心を持つユーザによって入力される必要がある。好適な実施の形態では、コンフィギュレーション・ファイルに含まれるエントリは次のものを規定する：
【００７３】
１．ＤＵＴ名およびオプションＩＤ；
２．ＤＵＴ設計の階層構造のＨＤＬパス／レベル
３．ＤＵＴ信号マップ、例えばＨＣＬＫ＝ＨＣＬＫｓｙｓ、あるいは上記２をオーバーライドするためのＨＣＬＫ＝〜／ｔｏｐ／ＨＣＬＫ
４．一般的なテストベンチ・パラメータ、例えばＥＮＤＩＡＮＥＳＳ＝ＬＩＴＴＬＥ、ＥＲＲＯＲＳＴＯＰ＝ＹＥＳ、ＶＥＲＢＯＳＩＴＹ＝ＥＲＲＯＲＳ＿ＯＮＬＹ；および
５．カバレッジ・コンフィギュレーション、例えば読出し専用デバイスに対してＤＩＲＥＣＴＩＯＮ＝ＮＯ＿ＷＲＩＴＥ
【００７４】
ＡＨＢマスタＤＵＴ用のユーザ・コンフィギュレーション・ファイルの一例を次に示す。
【００７５】
【表１】
上のことから明らかなように、このファイルの第１エントリは試験されるデバイス名を示しており、ここではＡＲＭプロセッサ・コアとなっている。第２エントリの“ＨＤＬＰＡＴＨ”はＤＵＴの階層構造のレベルを示す。次には、マスタＤＵＴによって使用され、ＤＵＴ内部で使用される名前をＡＭＢＡ信号名に対してどのようにマッピングするかを示すすべての信号を示す複数のエントリが続く。例えば、ＤＵＴによって使用される信号ＨＷＲＩＴＥｏｕｔはＡＭＢＡバス信号ＨＷＲＩＴＥにマッピングされる。
【００７７】
コンフィギュレーション・ファイル中の次のエントリはデバイスを能動モードと受動モードのどちらで試験すべきかを指定する。ここでは受動モードを使用することが確認されている。次のエントリはスティミュラスとして使用すべきユーザが定義するテスト・シーケンスを指定する。この例では、２つのテストベクトル・ファイル、すなわちｍｅｍｏｒｙ．ｖｅｃおよびｐｅｒｉｐｈｅｒａｌ．ｖｅｃが指定されている。図４を参照すると、ベクトル・ファイルｐｅｒｉｐｈｅｒａｌ．ｖｅｃはユーザが定義するテスト・シーケンス３０５であり、ベクトル・ファイルｍｅｍｏｒｙ．ｖｅｃはメモリ４２０に置くべきデータを含んでいる。試験が始まると、プロセッサ・コアのＤＵＴはメモリ４２０からデータを読み込む。このデータはコアによって実行すべき一連の命令を規定する。これはバス３４０上でバス・トランスファを引き起こし、ユーザが定義するテスト・シーケンス３０５、すなわちこの例ではｐｅｒｉｐｈｅｒａｌ．ｖｅｃがスレーブ試験部品によって提供される応答を命令する。このエントリはまた試験ランを開始する前に入力ファイルの文法チェックをすべきかどうかを指定する。
【００７８】
好適な実施の形態では、スティミュラス・ベクトル・ファイルのフォーマットは、それをＰｅｒｌやＣのような言語を使用して手書き、あるいはもっと便利な自動生成できるように特別に設計されている。
【００７９】
ユーザ・コンフィギュレーション・ファイルの次のエントリは、受動モードにおいて特別に使用されるいくつかの追加信号を指定する。その次には、試験に関連するデバッグおよびシステム環境設定を提供するいくつかの一般的なパラメータが続く。例えば、特定例では、バス幅が３２ビットであると指定される。
【００８０】
その後には能動モードに特有なコンフィギュレーション情報を提供するエントリが続く。最後に、ファイル中の最後に３つのエントリは、例えばカバレッジ・モニタによってチェックすべきカバレッジ・ポイントを決めるときに使用されるデバイス機能を規定する。
【００８１】
図６に戻って、ユーザ・コンフィギュレーション・ファイルが一旦読み込まれチェックされると、次に準拠性ツールはプロトコル・チェック・コンポネントを生成し、またカバレッジ・モニタ・コンポネントを生成およびコンフィギュアする。上で述べたように、カバレッジ・モニタのコンフィギュレーションはユーザ・コンフィギュレーション・ファイルに規定されたデバイス機能を考慮して行われる。
【００８２】
準拠性ツールは次に工程６３０においてＤＵＴを能動モードで実行させるべきかどうかを決定する。先に述べたように、この情報はユーザ・コンフィギュレーション・ファイルに与えられている。もしＤＵＴを受動モードで実行させるべきであれば、プロセスは工程６３５へ分岐して、カバレッジおよびプロトコル・チェックに関する信号マッピングが実行される。これはユーザ・コンフィギュレーション・ファイルに与えられる信号マッピング情報を用いて行なわれる。次にプロセスは分岐して工程６５０のシミュレータ・ツールへ戻り、その後で工程６６０で試験が実行される。受動モードでは、この試験は既存のシステム・シミュレーション環境内に定義されよう。
【００８３】
しかし工程６３０でＤＵＴが能動モードで実行すべきことが決まった場合には、プロセスは工程６４０へ進み、準拠性ツールによってＤＵＴ用の試験環境が動的に生成される。このプロセスは図７に関してもっと詳細に説明する。
【００８４】
図７に示すように、第１工程（工程７００）は生成する必要のある環境のタイプを規定する。この情報は被験デバイスのタイプから決まる。例えば、試験すべきデバイスがＡＨＢマスタ・デバイスであれば、好適な実施の形態では試験環境はアービタ、デコーダ、デフォルト・マスタ、および１以上のスレーブ・モデルを含む必要がある。あるいは、ＤＵＴがＡＨＢスレーブであれば、試験環境は少なくともデコーダおよびマスタ・モデルを含む必要がある。
【００８５】
一旦環境のタイプが指定されれば、次には必要なオブジェクトのインスタンスが工程７１０で生成される。従って、この時点で試験環境に必要な試験部品が生成され、好適な実施の形態では各試験部品がＯＯＰオブジェクトとしてインスタンス化される。次に、すぐ上で述べたＡＨＢマスタＤＵＴの例に戻って、工程７１０でＤＵＴと組み合わせることによって試験環境を形成するためにアービタ、デフォルト・マスタ、およびスレーブ・オブジェクトが生成される。
【００８６】
当業者には明らかなように、ＯＯＰプログラミングでは、各オブジェクトにはそれの関数を定義する複数のメソッドが付随する。本発明の好適な実施の形態に従えば、オブジェクトの各インスタンスに付随させるべき実際のメソッドは工程７００で検出される環境のタイプに依存する。例えば、ＤＵＴがマスタ・デバイスであれば、生成されるデコーダ・オブジェクトは単にマスタからの要求に応答するスレーブを選ぶことができればよい。しかし、ＤＵＴがスレーブ・デバイスであれば、デコーダもＤＵＴの選択を解除して、別のスレーブを選択することができ、それによってスレーブＤＵＴがビヘイビアをデコーダによる選択解除時に決定できるようにする機能も含むことが好ましい。
【００８７】
プロセスは次に工程７２０へ進み、そこでデバイス間の信号マッピングが更新される。既に説明したように、これにはユーザ・コンフィギュレーション・ファイルに与えられる信号マッピング情報への参照が含まれ、またＤＵＴによって使用される信号名を試験環境の残りの部分で使用されるＡＭＢＡ信号名へマッピングすることが含まれる。
【００８８】
プロセスは次に工程７３０へ進んで、各信号の初期値が設定される。例えば、ＤＵＴがスレーブ・デバイスの場合、それがマスタ・デバイスからトランスファ要求を受信する準備ができていることを確認する論理１のＨＲＥＡＤＹ信号をアサートする必要がある。
【００８９】
工程７３０の完了に続いて、プロセスは図６の工程６５０へ戻って、処理がシミュレータ・ツールへ戻される。工程６６０では、シミュレータは能動モードで試験を実行する。これはユーザが定義するテスト・シーケンスであるか、あるいはユーザ・コンフィギュレーション・ファイルに定義されたテスト・シーケンスである。オプションとして、準拠性ツールはユーザ・コンフィギュレーション・ファイルをチェックするときに、ユーザが定義するテスト・シーケンスが有効であることをチェックするためにユーザ・コンフィギュレーション・ファイルに定義されたユーザが定義するテスト・シーケンスのチェックを実際に実行するように構成できる。そのような工程は工程６２５において行われることが多い。この時点でこのチェックを実行することは有益である。それは、後の都合のよい時点、例えば夜通しで実際の試験を実行するように考えているし、また工程６６０において試験を開始する前にテスト・シーケンスには何も悪いところは基本的にないことを知るのが好ましいのは明らかだからである。
【００９０】
能動または受動モードのいずれかで準拠性試験を実行させるために好適な実施の形態で実行されるプロセスについて説明してきたが、好適な実施の形態で実行されるプロトコル・チェックおよびカバレッジ・モニタのより詳しいことについて次に説明する。
【００９１】
既に述べたように、プロトコル規則のコンフィギュレーションは行なわれない。またＡＭＢＡバス準拠性を主張するためにはＤＵＴはＡＭＢＡプロトコル規則のどれにも違反してはならない。
【００９２】
しかし、これとは対照的に、好適な実施の形態ではカバレッジ・ポイントは、いくつかのＤＵＴはＡＭＢＡバスの機能のすべてを利用しなくてもよいことを想定してコンフィギュアされる。ＤＵＴに対して許容できるコンフィギュレーションは、ＳｏＣに組み込まれるすべての部品が常に一緒に正しく動作するように定義されることが重要である。
【００９３】
基本的な規則として、ＡＭＢＡ部品は考えうるすべての入力組合せを受け入れる必要があるが、考えうるすべての出力の組合せを生成する必要はない。
【００９４】
一例として、Ｔｒａｎｓｆｅｒ Ｒｅａｄｙ、Ｔｒａｎｓｆｅｒ Ｒｅｓｐｏｎｓｅ、およびＢｕｓ Ｇｒａｎｔに関する入力信号を有するバス・マスタはそれら入力の考えうるすべての組合せを処理できなければならない。しかし、考えうるすべての出力組合せを生成する必要はなく、それの動作にとって適切なタイプのバーストおよびトランスファ・サイズを生成するだけでよい。
【００９５】
注意すべき点は、或るカバレッジ・ポイントをターン・オフさせればプロトコル・チェックを付加できるということである。例えば、もしもバス・マスタ準拠性チェックが４ビート・ラッピング・バーストをサポートしないバス・マスタとしてコンフィギュアされれば、このコンフィギュレーション・オプションは各種タイプの４ビート・ラッピング・バーストを観測するカバレッジ・ポイントを除去する効果を持つ。しかし、これはマスタがこの種のトランスファを決して実行しないことを保証する付加的なチェックを許容する。
【００９６】
スレーブ・デバイスもまた、考えうるすべての入力を受け入れることができ、トランスファのすべての異なる組合せを正しく処理できなければならない。しかし、バス上で利用可能なトランスファ情報のすべてを利用するわけではないスレーブ・デバイスを構築することは認められる。この典型的な例はバースト情報を利用しないスレーブ・デバイスであろう。そのようなスレーブ・デバイスの準拠性試験を簡略化するために、スレーブ・デバイスの入力に特定の信号が含まれない場合には、それらの入力の異なる組合せに関連するカバレッジ・ポイントを省略することができる。
【００９７】
ここでプロトコル・チェック関数の詳細について詳しく見てみると、ＡＭＢＡバスのプロトコルをチェックする基本原理は、ＡＭＢＡバス・プロトコルがトランザクション中に観測されることを確認するチェック・シーケンスを採用することであり、それには個別トランスファのバーストが複数個含まれる。好適な実施の形態では、準拠性ツールは、シミュレーション・イベントがそれらのプロトコル・チェックを記述する発見的方法をトリガすることを許容する時間表現を利用する。
【００９８】
時間表現はビヘイビアを記述するイベントおよび時間的オペレータの組合せである。時間表現は試験中にイベント、フィールドの値、変数、あるいはその他のアイテム間の時間的関係を取り込む。
【００９９】
明らかなように、好適な実施の形態の準拠性ツールには非常に多い可変数個の時間表現が用いられる。説明のために、そのような構成をどのように使用するかについて以下に簡単に見てみよう。
【０１００】
好適な実施の形態では、Ｖｅｒｉｓｉｔｙ Ｓｐｅｃｍａｎ“ｅ”言語を使用して時間表現が定義される。図８の一番上には時間経過のグラフィカルな表現として使用できる４つの凡例が示されている。図８の残りの部分は、一例としてＡＭＢＡ ＡＨＢシーケンス評価を提供しており、ＨＴＲＡＮＳ信号がＩＤＬＥにセットされた場合（ｈｔｒａｎｓ．ｉｄｌｅイベント）のｈｇｒａｎｔイベントのモニタリングの様子を示している。
【０１０１】
図８を参照すると、ＨＣＬＫイベントはｈｇｒａｎｔおよびｈｔｒａｎｓ．ｉｄｌｅイベントを含む２つのシーケンスについてのサンプリング・イベントである。ｈｃｌｋイベントそれ自身はＨＣＬＫ信号の立ち上がりで発生される。
【０１０２】
図８から分かるように、示されたいくつかのイベントは信号値に直接関連しており、他方、その他のイベントは基準イベントでサンプリングされた信号状態の組合せで定義される。この例では、基準イベントはＨＣＬＫの立ち上がり端である。
【０１０３】
｛＠ｈｇｒａｎｔ；＠ｈｔｒａｎｓ．ｉｄｌｅ｝シーケンスはｈｃｌｋにおいてｈｇｒａｎｔが発生する度に評価をスタートさせる。ｈｇｒａｎｔのｈｃｌｋ１個分後でｈｔｒａｎｓ．ｉｄｌｅがサンプリングされるとき、このシーケンスは成功である。
【０１０４】
｛＠ｈｇｒａｎｔ；［１］；＠ｈｔｒａｎｓ．ｉｄｌｅ｝シーケンスもまたｈｃｌｋでの最初のｈｇｒａｎｔの発生によって評価を開始するが、“１サイクル続く”文節（［１］）のために次のｈｃｌｋが発生するとシフトする。第３のｈｃｌｋが発生すると、シーケンスはｈｔｒａｎｓ．ｉｄｌｅイベントが存在すれば成功する。しかし図８から分かるように、この時間表現は第５サイクルの後は評価しない。それはｈｔｒａｎｓ．ｉｄｌｅイベントが存在しないためである。
【０１０５】
このように、図８に関連して上述したイベントを用いて特定の規則が観測されない条件を捉えることによってプロトコル・エラーを定義できるのが普通である。そのようなイベントは更に別のイベント・シーケンスを構築するために用いられたり、あるいは論理的に組み合わせてアサート・ステートメントを生成するために用いられたりする。準拠性ツールのプロトコル規則の典型的な形式は次のようになっている：
【０１０６】
【数１】
ｅｘｐｅｃｔ＜規則＞ｉｓ｛＜時間表現＞｝＠ｈｃｌｋ；
【０１０７】
時間表現を使用する代わりに採用できる別の方式は形式論的な数学技法に基づいて利用できるプロパティ・チェッカ・ツールを使用するものである。フォーマル・プロパティ・チェックにはシステム要求に密接に合致するプロパティを書くこと、そして次にそのプロパティがその設計で確保されていることを完全に証明することが含まれる。この方法が完全であるということは機能シミュレーションによってカバーできないバグを見出すことができるということを意味する。
【０１０８】
プロパティ・チェッカ・ツールはブロック・レベルで最も良く働く。１００Ｋゲートより小さいブロックが理想的である。
【０１０９】
プロパティ・チェック・ツールによってチェックされるプロパティの例は、ＡＨＢマスタが認められない場合にＨＴＲＡＮＳ信号出力がＩＤＬＥまたはＮＯＮ−ＳＥＱＵＥＮＴＩＡＬになるという要求である。このプロパティは図９Ａに示すタイミング図と合致するように書くことができる。図９Ａのタイミング図で、時間ｔおよびｔ＋１はクロック・サイクルを表す。ドット領域の値が仮定であり、続くＩＤＬＥ／ＮＳＥＱ部が証明しなければならない部分である。タイミング図が意味することは、もしもＨＧＲＡＮＴ信号が１つのクロック・サイクル（時間ｔ）で低レベルであれば、次のクロック・サイクルではＨＴＲＡＮＳ信号はＩＤＬＥまたはＮＳＥＱでなければならないということである。この証明は時間ｔが任意のクロック・サイクルで成り立つように徹底的に行われなければならない。すなわち、プロパティ・チェックはシミュレーション全体でタイミング図をスライドさせるようにみなすことができる。仮定が成り立つ場合はいつでもオブリゲーション部も成り立たなければならない。
【０１１０】
もしプロパティが保持されることが分かれば、ＤＵＴのＲＴＬ表現はそのプロパティによって指定される要求を常に満たさなければならない。どこかの瞬間にプロパティが保持されなければ、プロパティ・チェッカはエラーを指摘する短い波形ファイルを出力するのが好ましく、それを用いてデバッグが可能となる。
【０１１１】
そのようなデバッグの一例として、図９Ａのプロパティを試験環境にあるＤＵＴに適用した場合のデバッグ波形を観測したら、それは時間ｔにおいてＨＧＲＡＮＴ信号が低レベルで、ｔ＋１ではＨＴＲＡＮＳ信号がＳＥＱであるというプロパティの誤りをハイライト表示した。実際にはＤＵＴのＲＴＬ表現にはバグがないが、その代わりにプロパティそれ自身が不完全であった。事実、もしＡＨＢマスタが待機していれば（ＨＲＥＡＤＹ信号入力が低レベル）、ＨＴＲＡＮＳは保持されるべきであるという状況が存在する。すなわち、図９Ｂのタイミング図改訂版によって、正しいプロパティを示すことができる。
【０１１２】
図９Ｂのタイミング図によって示されるプロパティは、もしマスタが認められずまた待機状態でなければ、ＨＴＲＡＮＳ信号は続くクロック・サイクルでＩＤＬＥまたはＮＳＥＱでなければならないことを言っている。
【０１１３】
プロパティ・チェックについて議論してきたが、ここでカバレッジ・モニタについて簡単に説明しよう。既に述べたように、カバレッジはバス活動の特定のシーケンスを観測するプロセスである。好適な実施の形態では、ＶｅｒｉｓｉｔｙＳｐｅｃｍａｎツールが用いられる。これはカバレッジ・グループの定義を通してカバレッジ・モニタを可能とする。１つのカバレッジ・グループは、時間的にデータを収集したデータ・アイテムのリストを含むプログラム構造／オブジェクト・メンバである。
【０１１４】
Ｓｐｅｃｍａｎツールはまた、カバレッジ・データ・アイテム間相互作用の観測を可能とするクロス・カバレッジを実行できる。クロス・カバレッジを利用するＡＭＢＡ ＡＨＢマスタの例は、バーストの各タイプ（ＳＩＮＧＬＥ、ＩＮＣＲ、ＷＲＡＰ４、ＩＮＣＲ４、ＷＲＡＰ８、ＩＮＣＲ８、ＷＲＡＰ１６、ＩＮＣＲ１６）について、読出しおよび書込みの両バーストに対して異なるタイプのスレーブ応答が観測されることを確認することであろう。先に述べたように、試験実行のランの終わりに、すべてのカバレッジ情報は１つのＧＵＩに順序正しくまとめられる。このＧＵＩはそのＤＵＴについて要求されるカバレッジ・ポイントのうちどのくらいがモニタされたかをユーザに対して表示することができるようになっている。
【０１１５】
好適な実施の形態の試験準拠性ツールについて詳細に説明してきたが、準拠性ツールをその中で使用できるデータ処理システムについても図１０を参照しながら簡単に説明しよう。
【０１１６】
図１０はデータ処理装置を示しており、それはプロセッサ・コア８００、読出し専用メモリ（ＲＯＭ）８１０、ランダム・アクセス・メモリ（ＲＡＭ）８３０、入力／出力（Ｉ／Ｏ）デバイス８４０、およびディスプレイ８５０を含んでおり、それらは適当なバス・ネットワーク８２０を介して相互に接続されている。明らかなように、バス８２０は単一バスでもよいが、部品を互いに接続するために必要なバスの任意の組合せで構わない。
【０１１７】
好適な実施の形態では、好適な実施の形態のシミュレータ・ツールおよび準拠性ツールはＲＡＭ８３０へロードされ、次にプロセッサ・コア８００上で実行される。オペレーティング・システム、例えばＢＩＯＳはＲＯＭ８１０に記憶されるのが普通である。
【０１１８】
任意の特定の試験を実行するために必要な入力は一般的にはユーザによってＩ／Ｏデバイス８４０を介して入力され、ＲＡＭ８３０に記憶される。従って、能動モードでは、ユーザはＩ／Ｏデバイス８４０を介して、ＤＵＴを含むインタフェース・モジュール、ユーザ・コンフィギュレーション・ファイル、およびユーザが定義するテスト・シーケンスを入力する。これらは例えばディスクからＩ／Ｏデバイス８４０によって読み出される。この情報は次に、シミュレータ・ツールおよび準拠性ツールの実行中に必要に応じてプロセッサ・コア８００によってＲＡＭ８３０から取り出される。試験実行中あるいは実行後に、試験結果は例えばＶＤＵのようなディスプレイ・デバイス８５０上へ表示されよう。プロトコル規則のどれも違反されずにカバレッジ・ポイントすべてがモニタされれば、任意の適当な出力デバイスへＩ／Ｏデバイス８４０を介して出力するための準拠性証明を作製できる。
【０１１９】
要約すれば、理解されるように、好適な実施の形態の準拠性ツールはデバイスのバス・プロトコル準拠性を試験するための特に使いやすく効率的な方法を提供する。能動モードでは、ＤＵＴは非ＡＭＢＡのＩ／Ｏ信号とインタフェースするために試験者が利用できるトリックボックス・デバイスをオプションとした、単独ユニットとして試験される。このオプションのトリックボックスは試験者の制御下でデバイスの或る要求されるビヘイビアを誘発するために使用できる。能動モードでは、ユーザが生成するスティミュラス・ファイルを準拠性ツールによって読み出して、ユーザ・コンフィギュレーション・ファイルに指定されたバス・インタフェース信号上の所望のスティミュラスをドライブする。マスタＤＵＴの場合には、ベクトル・スティミュラス・ファイルが供給され、それによって、データ・チェックのためのデバイスへの予期されるアクセスとともに、待機ステータス、応答タイプ、グラント・ステータスを含むスレーブ応答ビヘイビアを決定する。スレーブＤＵＴの場合は、ユーザによって与えられるベクトル・スティミュラス・ファイルが有効なマスタ・バス・トランザクションを指定する。両方のタイプの入力スティミュラス・ファイルで、ユーザは試験環境がランダムに生成されるビヘイビアで以ってユーザが定義するスティミュラスをオーバライドするかどうかを制御できる。スレーブ・テストベンチの場合は、ランダム生成は待機ステータス、応答、およびグラント・ステータス等をカバーできる。
【０１２０】
受動モードでは、デバイスはシステムの一部として試験される。すなわち、準拠性ツールはドライブ機能を何も提供しないし、またデコーダ、アービタ、マスタ、およびスレーブのような試験部品の動的生成をサポートしない。ドライブすべきＤＵＴのためのサポート用インフラストラクチャ全体を提供するのは試験者のテストベンチである。このことは過去のＳｏＣ設計の準拠性試験において、また初めて周辺機器を一緒に統合する場合に特に有用である。準拠性ツールのドライブ機能が停止している状態では、プロトコル・チェックおよびカバレッジ・ポイント収集機構は能動モードで使用されたものと同じように働く。
【０１２１】
好適な実施の形態では、バス・プロトコル・エラーが発生せずに試験ランが完了したときは、ＤＵＴに関するカバレッジの詳細を表示するＧＵＩがロードされる。ここでカバレッジ・ホールを同定することができるため、後続の試験ランで前に見逃したカバレッジ・ポイントを満たすように、ＤＵＴをより明確な方向にドライブすることができる。このように準拠性を実現することに成功した後で、元の指定されたデバイス機能が与えられれば、バス・プロトコルに準拠することを認めるチェック・サムの準拠性証明が発行されよう。例えば、もしマスタＤＵＴがインクリメント・バーストのみをサポートすると指定されれば、それの準拠性証明はその事実を明確に述べる。
【０１２２】
本発明の特別な実施の形態についてここに述べてきたが、本発明がそれらに限定されず、本発明の範囲内で多くの修正および追加が可能であることは明らかであろう。例えば、本発明の範囲から外れることなしに、クレームの従属項の特徴を独立項の特徴と組み合わせることができる。
【図面の簡単な説明】
【図１】ＡＲＭ社によって開発されたアドバンスト・マイクロコントローラ・バス・アーキテクチャ仕様に従って動作するバスを介して相互接続されたデバイスを含むシステム・オン・チップを示すブロック図。
【図２】本発明の好適な実施の形態の能動モードに従う試験手順を実行するときに用いられる論理要素を模式的に示すブロック図。
【図３】スレーブ・デバイスを試験するときに、好適な実施の形態の能動モードで用いられる論理要素の更に詳細を示すブロック図。
【図４】マスタ・デバイスを試験するときに、好適な実施の形態の能動モードで用いられる論理要素の更に詳細を示すブロック図。
【図５】本発明の好適な実施の形態の受動モードに従って試験を実行するときに用いられる論理要素を模式的に示すブロック図。
【図６】本発明の好適な実施の形態に従って準拠性チェックを実行するために実行される工程を示すフロー図。
【図７】被験デバイス用の準拠性試験環境を生成するプロセスの詳細を示すブロック図。
【図８】本発明の好適な実施の形態に従ってプロトコル・チェックを実行するときの時間シーケンスの評価を表すために用いられるグラフ表記の例。
【図９】プロトコル・チェックを実行するときに、チェックされるプロパティを表すタイミング図。
【図１０】好適な実施の形態の試験手順が実行されるデータ処理システムを模式的に示すブロック図。
【符号の説明】
１０ ＳｏＣ
１１０ システム・バス
１１５ 外部バス
１２０ アービタ
１３０ 外部バス・インタフェース
１４０ ＣＰＵ
１４５ ＤＭＡコントローラ
１５０ ＵＡＲＴ論理ユニット
１５５ タイマ
１６０ ＲＡＭ
１６５ デコーダ論理
１７０ ブリッジ回路
１７５ クロック発生器
１８０ 赤外通信インタフェース
１８５ ＵＳＢ
１９５ ペリフェラル・バス
２００ ＳＤＬＣインタフェース
２０５ Ａ／Ｄコンバータ
２１０ Ｄ／Ａコンバータ
３００ テストベンチ
３０５ テスト・シーケンス・ファイル
３１０ カバレッジ・モニタ・コンポネント
３１５ コンフィギュレーション情報
３２０ プロトコル・チェック・コンポネント
３３０ ＤＵＴ
３４０ バス
３５０ ＡＭＢＡ部品テストベンチ・コア
３５５ ＡＨＢ／ＡＰＢマスタ部品
３６０ ユーザ・トリックボックス部品
４００ マスタＤＵＴ
４１０ ＡＨＢ／ＡＰＢスレーブ部品
４２０ メモリ初期化ファイル
５００ システム・シミュレーション環境
５１０ ＤＵＴ
８００ プロセッサ・コア
８１０ ＲＯＭ
８２０ バス
８３０ ＲＡＭ
８４０ 入力／出力デバイス
８５０ ディスプレイ
Claims (18)
- デバイスのバス・プロトコル準拠性を試験する方法であって：
（ａ）前記デバイスのタイプおよび前記デバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルを読み込む工程；
（ｂ）コンフィギュレーション・エンジンを採用して、前記コンフィギュレーション・ファイルに従って選ばれ、デバイス表現とバスを介して接続されて試験環境を形成するための試験部品を生成することによって前記デバイスのための試験環境を動的に生成する工程；
（ｃ）テスト・シーケンスを実行させる工程；および
（ｄ）前記テスト・シーケンスの実行中に前記デバイス表現と１個以上の前記試験部品との間で受け渡される信号をモニタして、前記バス・プロトコルへの準拠性を示す結果のデータを作成する工程；
を含む方法。 - 請求項１に記載の方法であって、前記コンフィギュレーション・ファイルがコンフィギュレーション・ファイルの１組のテンプレートから選ばれたものであり、また前記組が各デバイス・タイプ毎に１つのコンフィギュレーション・ファイル・テンプレートを含んでおり、また各コンフィギュレーション・ファイルにはそのデバイスに特有のコンフィギュレーション情報を提供するための複数のエントリが含まれている方法。
- 請求項１に記載の方法であって、前記工程（ｄ）が、プロトコル・チェック・コンポネントを採用して、前記テスト・シーケンス実行中に前記デバイス表現と１個以上の前記試験部品との間で受け渡される信号が、前記バス・プロトコルの予め定められた規則の組のどれにも違反しないことをチェックする工程を含んでいる方法。
- 請求項１に記載の方法であって、前記工程（ｄ）が、カバレッジ・モニタ・コンポネントを採用して、前記テスト・シーケンス実行中に前記デバイス表現と１個以上の前記試験部品との間で受け渡される信号をモニタして、１組のカバレッジ・ポイントが観測されるかどうかを決定する工程を含んでいる方法。
- 請求項４に記載の方法であって、前記カバレッジ・ポイントの組が前記工程（ａ）において読み込まれる前記コンフィギュレーション・ファイルに従ってコンフィギュアされる方法。
- 請求項５に記載の方法であって、前記工程（ｄ）が、プロトコル・チェック・コンポネントを採用して、前記テスト・シーケンス実行中に前記デバイス表現と１個以上の前記試験部品との間で受け渡される信号が前記バス・プロトコルの予め定められた規則の組のどれにも違反しないことをチェックする工程を含んでおり、また前記バス・プロトコルの予め定められた規則の組に違反しないで前記組中のすべてのカバレッジ・ポイントが観測された場合には、前記方法が更に前記バス・プロトコル準拠性を確認する出力を生成する工程を含んでいる方法。
- 請求項１に記載の方法であって、前記工程（ｂ）において、選ばれた試験部品を生成する前記工程が、試験すべきデバイスのタイプに依存して生成すべき前記試験部品を選択する工程を含んでいる方法。
- 請求項７に記載の方法であって、少なくとも１個の試験部品が、それに付随してそれが呈する複数のビヘイビアを有しており、試験すべきデバイスのタイプに依存して前記試験部品が生成されるときにビヘイビアの選択が決まるようになった方法。
- 請求項１に記載の方法であって、前記テスト・シーケンスが、試験すべきデバイス用に開発されたユーザが定義可能なテスト・シーケンスである方法。
- 請求項１に記載の方法であって、前記デバイス表現がインタフェース・モジュール内に生成され、試験環境を生成する前記工程（ｂ）が、前記インタフェース・モジュール内の信号を前記試験環境内の信号へ、前記コンフィギュレーション・ファイルに定義されたやり方に従ってマッピングする工程を含んでいる方法。
- 請求項１０に記載の方法であって、前記コンフィギュレーション・ファイルが、前記信号のマッピングを容易にするために、前記インタフェース・モジュール内の前記デバイス表現の階層構造レベルを規定している方法。
- 請求項１に記載の方法であって、更に：
前記バス・プロトコルと互換性を有し、汎用の入力／出力インタフェースを備えたトリックボックス・コンポネントを提供する工程；
を含む方法。 - 請求項１に記載の方法であって、試験されるデバイスのタイプがマスタ、スレーブ、アービタ、またはデコーダを含んでいる方法。
- 請求項１に記載の方法であって、前記バス・プロトコルがＡＲＭ ＡＭＢＡバス・プロトコルであり、前記バスがシステム・バスとペリフェラル・バスとを含んでおり、試験されるデバイスのタイプがシステム・バス・マスタ、システム・バス・スレーブ、ペリフェラル・バス・マスタ、ペリフェラル・バス・スレーブ、アービタ、またはデコーダを含んでいる方法。
- 請求項１に記載の方法であって、前記デバイス表現がレジスタ・トランスファ・ランゲージ（ＲＴＬ）表現である方法。
- 請求項１に記載されたデバイスの準拠性を試験する方法を実行するように処理ユニットをコンフィギュアするように動作するコンピュータ・プログラム。
- 請求項１６に記載のコンピュータ・プログラムを含む運搬媒体。
- デバイスのバス・プロトコル準拠性を試験するためのデータ処理システムであって：
前記デバイスのタイプおよび前記デバイスの機能を規定する予め定められたパラメータを含むコンフィギュレーション・ファイルを記憶するためのメモリ；
および
処理ユニットであって：
（ｉ）バスを介してデバイス表現と接続されて試験環境を形成する、前記コンフィギュレーション・ファイルに従って選ばれた試験部品を生成することによって前記デバイスのための試験環境を動的に生成する工程；
（ii）テスト・シーケンスを実行する工程；および
（iii）前記テスト・シーケンス実行中に前記デバイス表現と１個以上の試験部品との間で受け渡される信号をモニタして、前記バス・プロトコルとの準拠性を示す結果のデータを作成する工程；
を実行するように構成された処理ユニット；
を含むデータ処理システム。
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0109283.2A GB0109283D0 (en) | 2001-04-12 | 2001-04-12 | Testing for compliance |
| GB0111195.4 | 2001-05-08 | ||
| GB0109283.2 | 2001-05-08 | ||
| GB0111195A GB2374434B (en) | 2001-04-12 | 2001-05-08 | Testing compliance of a device with a bus protocol |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002358249A JP2002358249A (ja) | 2002-12-13 |
| JP4112886B2 true JP4112886B2 (ja) | 2008-07-02 |
Family
ID=26245977
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002098913A Expired - Fee Related JP4112886B2 (ja) | 2001-04-12 | 2002-04-01 | デバイスのバス・プロトコル準拠試験方法およびシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6876941B2 (ja) |
| JP (1) | JP4112886B2 (ja) |
Families Citing this family (75)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8176296B2 (en) | 2000-10-26 | 2012-05-08 | Cypress Semiconductor Corporation | Programmable microcontroller architecture |
| US8160864B1 (en) | 2000-10-26 | 2012-04-17 | Cypress Semiconductor Corporation | In-circuit emulator and pod synchronized boot |
| US6724220B1 (en) | 2000-10-26 | 2004-04-20 | Cyress Semiconductor Corporation | Programmable microcontroller architecture (mixed analog/digital) |
| US8103496B1 (en) | 2000-10-26 | 2012-01-24 | Cypress Semicondutor Corporation | Breakpoint control in an in-circuit emulation system |
| US8149048B1 (en) | 2000-10-26 | 2012-04-03 | Cypress Semiconductor Corporation | Apparatus and method for programmable power management in a programmable analog circuit block |
| US7542867B2 (en) * | 2001-08-14 | 2009-06-02 | National Instruments Corporation | Measurement system with modular measurement modules that convey interface information |
| US7406674B1 (en) | 2001-10-24 | 2008-07-29 | Cypress Semiconductor Corporation | Method and apparatus for generating microcontroller configuration information |
| US8078970B1 (en) | 2001-11-09 | 2011-12-13 | Cypress Semiconductor Corporation | Graphical user interface with user-selectable list-box |
| US8042093B1 (en) | 2001-11-15 | 2011-10-18 | Cypress Semiconductor Corporation | System providing automatic source code generation for personalization and parameterization of user modules |
| US7010773B1 (en) | 2001-11-19 | 2006-03-07 | Cypress Semiconductor Corp. | Method for designing a circuit for programmable microcontrollers |
| US6966039B1 (en) * | 2001-11-19 | 2005-11-15 | Cypress Semiconductor Corp. | Method for facilitating microcontroller programming |
| US7844437B1 (en) | 2001-11-19 | 2010-11-30 | Cypress Semiconductor Corporation | System and method for performing next placements and pruning of disallowed placements for programming an integrated circuit |
| US6971004B1 (en) | 2001-11-19 | 2005-11-29 | Cypress Semiconductor Corp. | System and method of dynamically reconfiguring a programmable integrated circuit |
| US20030145290A1 (en) * | 2002-01-30 | 2003-07-31 | International Business Machines Corporation | System for controlling external models used for verification of system on a chip (SOC) interfaces |
| JP3510618B2 (ja) * | 2002-02-05 | 2004-03-29 | 沖電気工業株式会社 | バスブリッジ回路及びそのアクセス制御方法 |
| US7577540B2 (en) * | 2002-03-01 | 2009-08-18 | Nec Corporation | Re-configurable embedded core test protocol for system-on-chips (SOC) and circuit boards |
| US8103497B1 (en) | 2002-03-28 | 2012-01-24 | Cypress Semiconductor Corporation | External interface for event architecture |
| US7308608B1 (en) | 2002-05-01 | 2007-12-11 | Cypress Semiconductor Corporation | Reconfigurable testing system and method |
| US6661724B1 (en) | 2002-06-13 | 2003-12-09 | Cypress Semiconductor Corporation | Method and system for programming a memory device |
| US6698004B2 (en) * | 2002-06-20 | 2004-02-24 | Sun Microsystems, Inc. | Pin toggling using an object oriented programming language |
| EP1447759A1 (en) * | 2003-02-07 | 2004-08-18 | ARM Limited | Generation of a testbench for a representation of a device |
| US7137078B2 (en) * | 2003-03-27 | 2006-11-14 | Jasper Design Automation, Inc. | Trace based method for design navigation |
| US7206387B2 (en) * | 2003-08-21 | 2007-04-17 | International Business Machines Corporation | Resource allocation for voice processing applications |
| CN100512274C (zh) * | 2004-03-04 | 2009-07-08 | 安立股份有限公司 | 能够容易控制协议消息的通信***的模拟装置与模拟方法 |
| US7295049B1 (en) | 2004-03-25 | 2007-11-13 | Cypress Semiconductor Corporation | Method and circuit for rapid alignment of signals |
| JP2005346513A (ja) * | 2004-06-04 | 2005-12-15 | Renesas Technology Corp | 半導体装置 |
| GB2415270A (en) * | 2004-06-16 | 2005-12-21 | Argo Interactive Ltd | A method of generating a test routine |
| US20060025984A1 (en) * | 2004-08-02 | 2006-02-02 | Microsoft Corporation | Automatic validation and calibration of transaction-based performance models |
| US7743151B2 (en) * | 2004-08-05 | 2010-06-22 | Cardiac Pacemakers, Inc. | System and method for providing digital data communications over a wireless intra-body network |
| US7332976B1 (en) * | 2005-02-04 | 2008-02-19 | Cypress Semiconductor Corporation | Poly-phase frequency synthesis oscillator |
| US7440863B2 (en) * | 2005-04-29 | 2008-10-21 | Agilent Technologies, Inc. | Integrated tool for compliance testing within an enterprise content management system |
| US7890285B2 (en) * | 2005-04-29 | 2011-02-15 | Agilent Technologies, Inc. | Scalable integrated tool for compliance testing |
| US7400183B1 (en) | 2005-05-05 | 2008-07-15 | Cypress Semiconductor Corporation | Voltage controlled oscillator delay cell and method |
| US7506281B1 (en) * | 2005-05-18 | 2009-03-17 | Xilinx, Inc. | Two-pass method for implementing a flexible testbench |
| US20070027669A1 (en) * | 2005-07-13 | 2007-02-01 | International Business Machines Corporation | System and method for the offline development of passive simulation clients |
| US7610444B2 (en) * | 2005-09-13 | 2009-10-27 | Agere Systems Inc. | Method and apparatus for disk address and transfer size management |
| US20070204076A1 (en) * | 2006-02-28 | 2007-08-30 | Agere Systems Inc. | Method and apparatus for burst transfer |
| US7599364B2 (en) * | 2005-09-13 | 2009-10-06 | Agere Systems Inc. | Configurable network connection address forming hardware |
| US8218770B2 (en) * | 2005-09-13 | 2012-07-10 | Agere Systems Inc. | Method and apparatus for secure key management and protection |
| US8521955B2 (en) | 2005-09-13 | 2013-08-27 | Lsi Corporation | Aligned data storage for network attached media streaming systems |
| US7461214B2 (en) * | 2005-11-15 | 2008-12-02 | Agere Systems Inc. | Method and system for accessing a single port memory |
| US7912060B1 (en) | 2006-03-20 | 2011-03-22 | Agere Systems Inc. | Protocol accelerator and method of using same |
| US7797467B2 (en) * | 2005-11-01 | 2010-09-14 | Lsi Corporation | Systems for implementing SDRAM controllers, and buses adapted to include advanced high performance bus features |
| US8085067B1 (en) | 2005-12-21 | 2011-12-27 | Cypress Semiconductor Corporation | Differential-to-single ended signal converter circuit and method |
| US7526742B1 (en) | 2006-01-31 | 2009-04-28 | Xilinx, Inc. | One-pass method for implementing a flexible testbench |
| CN100448239C (zh) * | 2006-02-28 | 2008-12-31 | 西安西电捷通无线网络通信有限公司 | 鉴别服务实体的安全接入协议符合性测试的方法及其*** |
| US8067948B2 (en) | 2006-03-27 | 2011-11-29 | Cypress Semiconductor Corporation | Input/output multiplexer bus |
| US20080133165A1 (en) * | 2006-12-04 | 2008-06-05 | Advantest Corporation | Test apparatus and device interface |
| US8092083B2 (en) * | 2007-04-17 | 2012-01-10 | Cypress Semiconductor Corporation | Temperature sensor with digital bandgap |
| US8040266B2 (en) * | 2007-04-17 | 2011-10-18 | Cypress Semiconductor Corporation | Programmable sigma-delta analog-to-digital converter |
| US8130025B2 (en) | 2007-04-17 | 2012-03-06 | Cypress Semiconductor Corporation | Numerical band gap |
| US8026739B2 (en) | 2007-04-17 | 2011-09-27 | Cypress Semiconductor Corporation | System level interconnect with programmable switching |
| US8266575B1 (en) | 2007-04-25 | 2012-09-11 | Cypress Semiconductor Corporation | Systems and methods for dynamically reconfiguring a programmable system on a chip |
| US9720805B1 (en) | 2007-04-25 | 2017-08-01 | Cypress Semiconductor Corporation | System and method for controlling a target device |
| US8065653B1 (en) | 2007-04-25 | 2011-11-22 | Cypress Semiconductor Corporation | Configuration of programmable IC design elements |
| US8049569B1 (en) | 2007-09-05 | 2011-11-01 | Cypress Semiconductor Corporation | Circuit and method for improving the accuracy of a crystal-less oscillator having dual-frequency modes |
| US20090113245A1 (en) * | 2007-10-30 | 2009-04-30 | Teradyne, Inc. | Protocol aware digital channel apparatus |
| US9448964B2 (en) | 2009-05-04 | 2016-09-20 | Cypress Semiconductor Corporation | Autonomous control in a programmable system |
| US8423314B2 (en) * | 2009-11-18 | 2013-04-16 | National Instruments Corporation | Deterministic reconfiguration of measurement modules using double buffered DMA |
| US20130024178A1 (en) * | 2011-07-20 | 2013-01-24 | Narendran Kumaragurunathan | Playback methodology for verification components |
| US8639981B2 (en) | 2011-08-29 | 2014-01-28 | Apple Inc. | Flexible SoC design verification environment |
| US8788886B2 (en) | 2011-08-31 | 2014-07-22 | Apple Inc. | Verification of SoC scan dump and memory dump operations |
| US9218271B2 (en) * | 2011-10-04 | 2015-12-22 | International Business Machines Corporation | Test planning based on dynamic coverage analysis |
| US9329967B2 (en) * | 2012-11-13 | 2016-05-03 | Tektronix, Inc. | Methods and systems for aiding the analysis of a signal |
| US9495281B2 (en) * | 2012-11-21 | 2016-11-15 | Hewlett Packard Enterprise Development Lp | User interface coverage |
| KR20140113175A (ko) * | 2013-03-15 | 2014-09-24 | 삼성전자주식회사 | 버스 프로토콜 검사기, 이를 포함하는 시스템 온 칩 및 버스 프로토콜 검사 방법 |
| CN105447212A (zh) * | 2014-08-25 | 2016-03-30 | 联发科技（新加坡）私人有限公司 | 产生集成电路的验证平台文件的方法与编译*** |
| US10082538B2 (en) | 2014-11-14 | 2018-09-25 | Cavium, Inc. | Testbench builder, system, device and method |
| US10126362B2 (en) * | 2014-12-15 | 2018-11-13 | International Business Machines Corporation | Controlling a test run on a device under test without controlling the test equipment testing the device under test |
| US10282315B2 (en) | 2015-03-27 | 2019-05-07 | Cavium, Llc | Software assisted hardware configuration for software defined network system-on-chip |
| US9672127B2 (en) * | 2015-04-16 | 2017-06-06 | Teradyne, Inc. | Bus interface system for interfacing to different buses |
| US10031991B1 (en) * | 2016-07-28 | 2018-07-24 | Cadence Design Systems, Inc. | System, method, and computer program product for testbench coverage |
| US11394633B2 (en) * | 2018-12-13 | 2022-07-19 | Microsoft Technology Licensing, Llc | Internet of things (IOT) device and solution certification as a service |
| US11144693B1 (en) * | 2019-11-27 | 2021-10-12 | Cadence Design Systems, Inc. | Method and system for generating verification tests at runtime |
| CN115470752B (zh) * | 2022-09-22 | 2023-07-14 | 沐曦科技(北京)有限公司 | 基于追踪文件的芯片功能验证*** |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6457152B1 (en) | 1998-10-16 | 2002-09-24 | Insilicon Corporation | Device and method for testing a device through resolution of data into atomic operations |
| US6366973B1 (en) * | 1999-05-03 | 2002-04-02 | 3Com Corporation | Slave interface circuit for providing communication between a peripheral component interconnect (PCI) domain and an advanced system bus (ASB) |
| US6425071B1 (en) * | 1999-05-03 | 2002-07-23 | 3Com Corporation | Subsystem bridge of AMBA's ASB bus to peripheral component interconnect (PCI) bus |
| US6574691B1 (en) * | 1999-07-28 | 2003-06-03 | Koninklijke Philips Electronics N.V. | Apparatus and method for interfacing a non-sequential 486 interface burst interface to a sequential ASB interface |
| US6678645B1 (en) * | 1999-10-28 | 2004-01-13 | Advantest Corp. | Method and apparatus for SoC design validation |
| US6581019B1 (en) * | 2000-03-20 | 2003-06-17 | Koninklijke Philips Electronics N.V. | Computer-system-on-a-chip with test-mode addressing of normally off-bus input/output ports |
-
2002
- 2002-02-28 US US10/084,145 patent/US6876941B2/en not_active Expired - Lifetime
- 2002-04-01 JP JP2002098913A patent/JP4112886B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020183956A1 (en) | 2002-12-05 |
| US6876941B2 (en) | 2005-04-05 |
| JP2002358249A (ja) | 2002-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4112886B2 (ja) | デバイスのバス・プロトコル準拠試験方法およびシステム | |
| Mehta | ASIC/SoC functional design verification | |
| US8180620B2 (en) | Apparatus and method for performing hardware and software co-verification testing | |
| US8607174B2 (en) | Verification module apparatus to serve as a prototype for functionally debugging an electronic design that exceeds the capacity of a single FPGA | |
| US20220292248A1 (en) | Method, system and verifying platform for system on chip verification | |
| CN115841089A (zh) | 一种基于uvm的***级芯片验证平台及验证方法 | |
| TW594513B (en) | Apparatus and method for in-circuit emulation using high-level programming language | |
| WO2018018978A1 (zh) | 一种通用串行总线控制器验证方法、***及设备 | |
| CN115146568A (zh) | 一种基于uvm的芯片验证***及验证方法 | |
| US20050144436A1 (en) | Multitasking system level platform for HW/SW co-verification | |
| CN106844118B (zh) | 一种基于Tbus总线标准的片内总线测试*** | |
| Chang et al. | A unified GDB-based source-transaction level SW/HW co-debugging | |
| Ke et al. | Verification of AMBA bus model using SystemVerilog | |
| CN115618800A (zh) | 基于dpi的gpu联合仿真*** | |
| Crouch et al. | Generalizing access to instrumentation embedded in a semiconductor device | |
| US7017097B1 (en) | Simultaneously driving a hardware device and a software model during a test | |
| US9581643B1 (en) | Methods and circuits for testing partial circuit designs | |
| GB2374434A (en) | Testing compliance of device with bus protocol | |
| Lissel et al. | Introducing new verification methods into a company's design flow: an industrial user's point of view | |
| Deng et al. | A Standalone FPGA-test Platform with Bi-directional Ports Supported | |
| Ramakrishna et al. | Verification of advanced high speed bus in UVM methodology | |
| Tan | Design of a direct memory access module for 32-BIT RISC32 processor | |
| Gianarro | An innovative amba compliant crossbar scheme and its fault tolerance analysis | |
| Allara et al. | Bringing constrained random into SoC SW-driven verification | |
| de Kock et al. | A configurable test infrastructure using a mixed-language and mixed-level IP integration IP-XACT flow |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040524 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070322 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070330 |
|
| 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: 20080401 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080410 |
|
| 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: 20110418 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140418 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |