JP2002358249A - デバイスのバス・プロトコル準拠試験方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 デバイスのバス・プロトコル準拠性を試験す
る特に使い易く効率的な方式を提供する。 【解決手段】 本方法は、デバイスのタイプおよびデバ
イスの機能を規定する予め定められたパラメータを含む
コンフィギュレーション・ファイルを読み込み、次に、
コンフィギュレーション・エンジンを採用して、前記コ
ンフィギュレーション・ファイルに従って選ばれ、バス
を介してデバイス表現と接続されることによって試験環
境を生成する試験部品を生成することによって前記デバ
イスのための試験環境を動的に生成する工程を含む。次
に、テスト・シーケンスを実行させ、その間に前記デバ
イス表現と１個以上の前記試験部品との間で受け渡され
る信号をモニタして、前記バス・プロトコルへの準拠性
を示す結果のデータを作成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデバイスのバス・プ
ロトコル準拠を試験するための方法およびシステムに関
する。

【０００２】

【従来の技術】システムに統合するための部品を開発す
る場合、その部品がシステムに統合されたときに所定の
動作をするかどうかを確認するために複数の試験手順が
実行されるのが普通である。しばしばシステムは１以上
のバスを介して互いに接続された複数個の個別部品で構
成される。バス仕様が各部品に標準インタフェースを提
供することによって、部品供給業者はその部品を最終的
に統合するシステムに関する知識なしでもその部品を設
計および試験できる場合が多い。

【０００３】しかし、システム内で特別なバス仕様に従
うバスへ接続する部品を開発する場合には、その部品
が、その定義されたバス仕様に従うそのバスとインタフ
ェースすることをチェックする必要があるのは明らかで
ある。

【０００４】ハード的な部品開発は複数の段階を経て行
なわれるのが一般的である。まず最初に、その部品の機
能的な動作／ビヘイビアが、例えばレジスタ・トランス
ファ・ランゲージ（ＲＴＬ）を使用して定義される。広
く用いられる２つのＲＴＬはＶＨＤＬおよびＶｅｒｉｌ
ｏｇである。更に、そのようなＲＴＬコーディングの前
に、設計意図が正しいことをトランザクション・レベル
で検証するために、ＵＭＬ（ユニバーサル・モデリング
・ランゲージ）を用いてビヘイビア・モデルを構築して
も良い。

【０００５】一旦ハードウエア部品のＲＴＬ表現が開発
されれば、次にこれを複数個の既知の合成ツールの任意
のものを用いて一連のハードウエア要素の形に合成す
る。次に、この合成で得られるハードウエア設計を用い
て、例えばシリコン上へ部品を適切に作製することによ
って実際のハードウエア部品が作製される。部品が実際
にハードウエアの形に実現された後でその部品に対して
試験手順を施すのは明らかにコストを要するので、その
代わりに、ＲＴＬ表現から生成される実際のハードウエ
アが正しく動作することを確認するために、部品のＲＴ
Ｌ表現に対して厳格な試験を行なうのが一般的である。

【０００６】従って、１つの部品が既知のバス仕様と正
しくインタフェースすることをチェックするプロセスが
部品のＲＴＬ表現に対して適用され、それがバス仕様に
定義されたバス・プロトコルに従っていることをチェッ
クするようになっている。そのようなプロトコル・チェ
ックを実行する複数の方法が知られている。

【０００７】まず、その中に被験デバイス（ＤＵＴ）と
呼ぶ試験すべき部品のＲＴＬ表現を含むＲＴＬテストベ
ンチを生成することができる。次に、その他のデバイス
のＲＴＬ表現も準備され、バスを介してＤＵＴのＲＴＬ
表現と互いにつながれてＲＴＬテストベンチ内にシステ
ム・シミュレーションが生成される。次に、１つのデバ
イスから別のデバイスへスティミュラスが与えられて、
その結果の波形が目で見える形で観測されるか、あるい
はシステム・シミュレーションに統合される自己点検機
構またはモジュールによって観測される。このプロセス
はバス・プロトコルで定義されたトランザクションをチ
ェックできるし、また一般的にすべてのバス・プロトコ
ル・トランザクションが正しく記録されるまでそのチェ
ックを徹底的に繰り返すことができる。

【０００８】上で述べたＲＴＬテストベンチでバス・プ
ロトコル準拠をチェックするために利用できる別の方法
は、ＲＴＬで精巧なバス・フォロワを構築し、次にバス
・トラフィックをモニタすることによってバス・フォロ
ワ内部のステート・マシンが任意の有効なポイントにお
いて実際のシステム・シミュレーションで観測されるも
のと合致することを確認するものである。

【０００９】準拠性をチェックする別の代替法はインテ
グレーション試験コードを使用するもので、マスタ・デ
バイスに対してスレーブ・デバイスへのバス上で読出し
および書込みトランザクションを実行させ、次に目標デ
ータが正しく読出しおよび／または書込みされたことを
チェックするものである。マスタ・デバイスはバスを介
してトランスファ要求を発行するように設計されたデバ
イスであると考えることができ、またスレーブ・デバイ
スはそのようなトランスファ要求の受け手のデバイスで
あると考えることができる。一例として、プロセッサ・
コアはマスタ・デバイスとして使用され、メモリからイ
ンテグレーション試験コードを読み出すように、またそ
の後でバス・プロトコル準拠性をチェックするために予
め定められた一連の読出しおよび書込みトランザクショ
ンを実行する試験コードを実行するように構成すること
ができる。そのようなコード・シーケンスはデバイス間
の調停を引き起こし、またバス・プロトコルのその他の
仕様をチェックするためにデバイスからの特定の応答を
誘発するためにも実行することができる。このやり方
は、一般に比較的低速であること、またバス・プロトコ
ルを直接的にモニタせずに、バスを介して誘発されたア
クションの結果をモニタすることでバス・プロトコル準
拠性について仮定する点で既に述べた２つの方法に比べ
て満足度は劣る。それにも拘らず、このやり方はバス上
でのデバイス相互接続を試験する形式として現在でも使
用されている。

【００１０】先に述べたＲＴＬテストベンチ方式の代わ
りに使用できるプロトコル・チェックを実行する別の既
知の方法は、例えばＶｅｒａまたはＳｐｅｃｍａｎのよ
うなＨＶＬ（ハイレベル・ベリフィケーション・ランゲ
ージ）開発ツールを使用してアブストラクト・レベルで
バス・トランザクションをモニタするものである。シス
テム・シミュレーション中の各デバイスのＲＴＬ表現を
生成する代わりに、それをＲＴＬで書き下ろすことなし
に、ＨＶＬ開発ツールを用いてデバイスをモデル化でき
る。次にそれは例えば開始されたトランスファや進行中
のトランスファ等のアブストラクト情報を記録すること
によってバス・トランザクションをモニタすることがで
きる。

【００１１】

【発明の解決しようとする課題】当業者には理解される
ように、上述の方法の任意のものを用いる場合でも、特
に例えば、各デバイスの多数のコンフィグレーションお
よび機能を考慮すると、インクリメント・バーストのみ
をサポートするマスタ・デバイスや書込みトランザクシ
ョンを受け付けないスレーブ・デバイスのように、特別
なマスタ・デバイスやスレーブ・デバイス、あるいはマ
スタ・デバイスとスレーブ・デバイスとの組合せを試験
するプロセスは時間の掛かるプロセスである。最初の２
つの方法について考えると、これらのパラメータを提供
するためにスティミュラス発生またはＲＴＬバス・フォ
ロワに対して一定のコンフィギュレーションを追加する
ことはできるが、それでもＲＴＬテストベンチは例えば
ＶＨＤＬやＶｅｒｉｌｏｇのような特別なＲＴＬで表現
したＤＵＴのみを試験できるのが普通である。従って、
一例として、ＶｅｒｉｌｏｇＤＵＴ用にＶｅｒｉｌｏｇ
テストベンチを構築すれば、そのＤＵＴのＶＨＤＬバー
ジョンを検証するためにＶＨＤＬテストベンチも必要に
なるのが普通である。更に、バス・ハンドオーバやアー
リー・バースト・ターミネーションのような特定のバス
活動が必要となれば、専用のＲＴＬなしにそのタスクの
実行を励起することは極めて困難で、デバイスを設計お
よび検証するために要する時間が更に追加されることに
なる。

【００１２】ＨＶＬ開発ツール方式はＲＴＬ言語依存性
の問題を軽減するが、要求されるチェック・ルーチンを
実現するためには高度な技能が必要である。更に、その
ようなチェック・ルーチンが再利用できるようにライブ
ラリ・モジュールとして実現できたとしても、各々のチ
ェック環境のコンフィギュレーションおよびデバッグは
必要である。

【００１３】従って、デバイスのバス・プロトコル準拠
を試験するための進歩した方法を提供することが望まし
い。

【００１４】

【課題を解決するための手段】第１の態様から眺める
と、本発明はデバイスのバス・プロトコル準拠を試験す
る方法を提供し、その方法は：（ａ）そのデバイスのタ
イプおよびそのデバイスの機能を規定する予め定められ
たパラメータを含むコンフィギュレーション・ファイル
を読み出す工程；（ｂ）コンフィギュレーション・エン
ジンを採用して、前記コンフィギュレーション・ファイ
ルに従って選ばれ、バスを介してデバイス表現と接続さ
れる試験部品を生成することによってデバイス用の試験
環境を動的に生成する工程；（ｃ）テスト・シーケンス
を実行させる工程；および（ｄ）テスト・シーケンスの
実行中に前記デバイス表現と１個以上の前記試験部品と
の間で受け渡される信号をモニタすることによってバス
・プロトコル準拠性を表示する結果のデータを生成する
工程；を含む。

【００１５】本発明に従えば、デバイスのタイプおよび
そのデバイスの機能を規定する予め定められたパラメー
タを含むコンフィギュレーション・ファイルが用意さ
れ、次に、バスを介してデバイス表現とつながれて試験
環境を生成するための選ばれた試験部品を生成すること
によって、試験すべきデバイス用の試験環境が動的に生
成される。試験部品はコンフィギュレーション・ファイ
ルに従って選ばれる。次に、テスト・シーケンスを実行
でき、テスト・シーケンスの実行中に、デバイス表現と
１個以上の試験部品との間で受け渡される信号をモニタ
してバス・プロトコル準拠性を表示する結果のデータを
生成することができる。

【００１６】従って、本発明に従えば、コンフィギュレ
ーション・ファイルに定義された被験デバイス（ＤＵ
Ｔ）に関連する試験環境が自動的に生成される。コンフ
ィギュレーション・エンジンは多様な異なる試験部品に
アクセスし、コンフィギュレーション・ファイルに含ま
れる情報に基づいて、試験環境へ取り込むために選択で
きることが好ましい。例えば、コンフィギュレーション
・ファイルが試験すべきデバイスをマスタ・デバイスと
指定してあれば、コンフィギュレーション・エンジンは
試験環境中にデコーダ、アービタ、複数のスレーブ・デ
バイス、およびダミー・マスタ・デバイスを生成および
コンフィギュアするように構成されよう。アービタは複
数のマスタ・デバイス間で行なわれるバス・アクセス要
求を調停するために使用され、デコーダはバス上へ発行
された任意の特定のトランスファ要求が指しているスレ
ーブ・デバイスを同定するために使用される。

【００１７】１つの実施の形態では、試験部品はオブジ
ェクト指向型プログラミング（ＯＯＰ）のオブジェクト
として書かれ、試験環境に含めるための試験部品を生成
する工程には、試験部品のインスタンス化（すなわち、
オブジェクトのインスタンス生成）が含まれ、このオブ
ジェクトのメソッドがインスタンス化された試験部品の
試験環境内でのビヘイビアを定義する。しかし明らかな
ように、ＯＯＰ技術を使用する必要は必ずしもなく、試
験部品は任意のその他の適当なやり方で表現することが
できる。

【００１８】本発明の方法に従ってデバイスの試験準備
を行なう場合、ユーザはコンフィギュレーション・エン
ジンがそのデバイスに適した試験環境を動的に生成する
ために知っておく必要があるパラメータを含むコンフィ
ギュレーション・ファイルを用意する必要がある。好適
な実施の形態では、コンフィギュレーション・ファイル
は１組のコンフィギュレーション・ファイル・テンプレ
ートから選ばれる。その組には各デバイス・タイプにつ
いてのコンフィギュレーション・ファイル・テンプレー
トが含まれ、各コンフィギュレーション・ファイルには
そのデバイスに特有なコンフィギュレーション情報を提
供するための複数のエントリが含まれる。コンフィギュ
レーション情報は多様な形態を取るが、典型的にはその
デバイスのタイプの同定、およびそのデバイスの機能を
含む。すなわち一例として、デバイスのタイプはマス
タ、スレーブ、アービタ、デコーダ等と指定される。デ
バイスの機能は、例えば、そのデバイスがサポートする
必要のあるバス・プロトコルのサブセットを指定する。
すなわち、ＤＵＴは必ずしもそのバスの性能のすべてを
利用する必要はなく、デバイスによって利用されないバ
ス・プロトコル部分に関する準拠性を試験する必要はな
い。

【００１９】デバイスのタイプおよびデバイスの機能に
加えて、コンフィギュレーション・ファイル中のその他
のコンフィギュレーション情報には、ＤＵＴ内で使用さ
れる信号名がバス仕様の信号名とどのように対応するか
を示す信号マップのほかに、例えば、デバッグやシステ
ム環境設定に関連する一般的なテストベンチ・パラメー
タが含まれる。

【００２０】明らかなように、テスト・シーケンス実行
中にデバイス表現と１個以上の試験部品との間で受け渡
される信号をモニタするために使用できる複数のプロセ
スが存在する。好適な実施の形態では、このモニタ工程
には、プロトコル・チェック・コンポネントを採用し
て、テスト・シーケンス実行中にデバイス表現と１個以
上の試験部品との間で受け渡される信号が、バス・プロ
トコルの予め定められた１組の規則に違反しないことを
チェックする工程が含まれる。そのようなプロトコル・
チェックには、被験デバイスが予め定められた１組の規
則に従うことを確認するためのサイクル毎のチェックが
含まれる。試験されるデバイスはそれがバス・プロトコ
ルに準拠すると判断されるためには、それらの規則のい
ずれにも違反してはならない。典型的は、予め定められ
た規則の組は試験されるデバイスに拘わらず同一であ
り、従って予め定められた規則の組は好適な実施の形態
のコンフィギュレーション・ファイルの内容によって影
響されない。

【００２１】好適な実施の形態で採用できる別のモニタ
・プロセスは、カバレッジ・モニタ・コンポネントを採
用して、テスト・シーケンスの実行中にデバイス表現と
１個以上の試験部品との間で受け渡される信号をモニタ
して、１組のカバレッジ・ポイントが観測されるかどう
かを判定する工程を含む。カバレッジ・ポイントは典型
的には、バス・プロトコル準拠を表明する前に試験環境
内で確認すべき各種バス・トランザクションのリストで
ある。カバレッジ・ポイントの目的は、実行されるテス
ト・シーケンス（単数または複数）が試験されるデバイ
スを十分活用して準拠性が表明できることを保証するこ
とである。

【００２２】好適な実施の形態では、カバレッジ・ポイ
ントの組は試験方法の工程（ａ）で読み出されるコンフ
ィギュレーション・ファイルに依存してコンフィギュア
される。従って、試験される任意の特定デバイスはバス
・プロトコルのすべての機能を使用しなくてもよく、カ
バレッジ・ポイントはコンフィギュレーション・ファイ
ルに基づいて、試験されるデバイスに関連するカバレッ
ジ・ポイントの組を指定するように調整することができ
る。標準的な予め定義されたバス・トランザクションの
シーケンスの代わりにカバレッジ・ポイントを使用する
ことの利点は、そうすることによって、特別なトランザ
クション・シーケンスを必要とするだけで特定デバイス
がバス・インタフェースを完全に活用することができる
ということである。

【００２３】好適な実施の形態では、試験方法の工程
（ｄ）でプロトコル・チェック・コンポネントおよびカ
バレッジ・モニタ・コンポネントの両方が使用され、そ
れによって、前記組中のすべてのカバレッジ・ポイント
がバス・プロトコルの予め定められた規則に違反せずに
観測されれば、この方法は更にバス・プロトコル準拠を
確認する出力を発生する工程を含む。この出力は、例え
ばコンフィギュレーション・ファイルに規定された元の
デバイス性能を与えた場合にバス・プロトコル準拠を保
証するチェック・サム証明のような準拠性証明の形を取
る。

【００２４】先に述べたように、コンフィギュレーショ
ン・エンジンは、コンフィギュレーション・ファイルに
従って選ばれた試験部品を生成するように構成される。
好適な実施の形態では、生成すべき試験部品は試験すべ
きデバイスのタイプに従って選ばれる。このデバイス・
タイプはコンフィギュレーション・ファイルに規定され
る。

【００２５】更に好適な実施の形態では、少なくとも１
つの試験部品はそれに付随してそれが示すであろう複数
のビヘイビアを有しており、ビヘイビアの選択は試験す
べきデバイスのタイプに依存してその試験部品が生成さ
れるときに決まる。例えば、試験すべきそのデバイスが
スレーブ・デバイスで、試験部品の１つとしてデコーダ
が生成される場合、好適な実施の形態では、試験すべき
デバイスの選択を解除して、別のスレーブを選択させる
ようなビヘイビアを採用する。これは明らかに、スレー
ブ・デバイスを試験するときに、デコーダに含めるべき
有用なビヘイビアである。しかし、試験すべきデバイス
がマスタ・デバイスである場合には、デコーダのこのビ
ヘイビアは関連性がなく、デコーダ試験部品のビヘイビ
ア全体から省くことができる。先に述べたように、好適
な実施の形態では、各試験部品はＯＯＰオブジェクトと
して書かれ、それらのオブジェクトのインスタンス化
は、次に、試験環境を生成するときにコンフィギュレー
ション・エンジンによって生成される。そのような実施
の形態では、複数のビヘイビアがＯＯＰオブジェクトの
個別メソッドとして実現され、そのメソッド（単数また
は複数）はインスタンスを作成する場合に選ばれる任意
のインスタンスに適用可能である。これをＯＯＰ用語で
は“継承”と呼ぶ。

【００２６】明らかなように、工程（ｃ）で試験方法が
実行するテスト・シーケンスは多様な形態を取ることが
できる。例えば、テスト・シーケンスは予め決められた
テスト・シーケンスの組から選ぶことができる。しか
し、好適な実施の形態では、テスト・シーケンスは試験
すべきデバイス用に特別に開発されたユーザ定義のテス
ト・シーケンスであり、試験すべきその特別なデバイス
に関連するバス・プロトコル部分への準拠性を試験する
目的を持つ。試験方法の工程（ｃ）および（ｄ）は、バ
ス・プロトコルとの準拠性を確定するため十分なトラン
ザクションが観測されるまで、工程（ｃ）において毎回
テスト・シーケンスを変更または修正しながら繰り返し
てよい。

【００２７】明らかなように、デバイス表現は複数のや
り方で試験環境に取り込むことができる。しかし、好適
な実施の形態では、デバイス表現はインタフェース・モ
ジュール中に生成され、試験環境を生成する前記工程
（ｂ）にはインタフェース・モジュール中の信号を試験
環境中の信号へマッピングする工程が含まれる。このマ
ッピングはコンフィギュレーション・ファイルに定義さ
れている。インタフェース・モジュールはデバイス表現
を取り巻く“ラッパ”として機能し、試験環境の残りの
部分に対してインタフェースを提供する。

【００２８】典型的には、デバイス表現はインタフェー
ス・モジュールの唯一の要素ではない。例えば、インタ
フェース・モジュールの一部として何らかのクロックお
よび多重化機能を提供することも可能であり、実際に或
る実施の形態ではその他のデバイス表現がインタフェー
ス・モジュールに含まれている。従って、本発明の好適
な実施の形態では、信号のマッピングを容易にするため
に、インタフェース・モジュール内のデバイス表現の階
層レベルをコンフィギュレーション・ファイルが指定す
る。

【００２９】好ましくは、本方法は更に、バス・プロト
コルと互換性を持ち、汎用の入力／出力インタフェース
を備えるトリックボックス・コンポネントを提供する工
程を含む。トリックボックスは、バス・プロトコルには
関連しないが被験デバイスに関連する信号の制御および
観測を許容する。トリックボックスは一般に、そのよう
な信号を入力および出力するための入力および出力ポー
トを持ち、そのほかにトリックボックスを制御するため
の、バスへのスレーブ・インタフェースを備える。スレ
ーブ・インタフェースは、トリックボックスが試験環境
内でインスタンス化できて、被験デバイスよりもトリッ
クボックスにアクセスするテスト・シーケンスを用いて
制御できることを意味する。好適な実施の形態では、ト
リックボックスは試験すべきデバイス表現を含むインタ
フェース・モジュールに含まれている。明らかなよう
に、或る実施例では、異なる試験手順を容易にするため
に複数のトリックボックス・コンポネントが採用されよ
う。

【００３０】先に述べたように、試験すべきデバイスの
タイプは好ましくはマスタ、スレーブ、アービタ、ある
いはデコーダのいずれかである。好適な実施の形態で
は、バス・プロトコルはＡＲＭ ＡＭＢＡバス・プロト
コルであり、バスはシステム・バスおよびペリフェラル
・バスを含み、試験されるデバイスのタイプにはシステ
ム・バス・マスタ、システム・バス・スレーブ、ペリフ
ェラル・バス・マスタ、ペリフェラル・バス・スレー
ブ、アービタ、あるいはデコーダが含まれる。当業者に
は明らかなように、ペリフェラル・バス・マスタはペリ
フェラル・バスとシステム・バスとを接続するブリッジ
である。

【００３１】試験環境に取り込まれるデバイス表現は多
様な形態を取る。しかし、好適な実施の形態では、デバ
イス表現はレジスタ・トランスファ・ランゲージ（ＲＴ
Ｌ）表現である。

【００３２】第２の態様から眺めると、本発明は、本発
明の第１の態様に従う、デバイス準拠性を試験する方法
を実行するように処理ユニットをコンフィギュアするよ
うに働くコンピュータ・プログラムを提供する。本発明
はまた、本発明の第２の態様に従うコンピュータ・プロ
グラムを含む運搬媒体を提供する。

【００３３】第３の態様から眺めた場合、本発明はデバ
イスのバス・プロトコル準拠を試験するためのデータ処
理システムを提供する。本システムは：デバイスのタイ
プおよびデバイスの機能を規定する予め定められたパラ
メータを含むコンフィギュレーション・ファイルを記憶
するためのメモリ；および次の：（ｉ）コンフィギュレ
ーション・ファイルに従って選ばれ、バスを介してデバ
イス表現と接続されて試験環境を形成する試験部品を生
成することによって、デバイスのための試験環境を動的
に生成する工程；（ii）テスト・シーケンスを実行する
工程；および（iii）前記テスト・シーケンスの実行中
にデバイス表現と１個以上の試験部品との間で受け渡さ
れる信号をモニタして、バス・プロトコル準拠性を表示
する結果のデータ生成する工程；を実行するように構成
された処理ユニット；を含む。

【００３４】本発明は試験すべきデバイスが１個の場合
について説明してきたが、明らかなように、本方法を複
数デバイスの同時試験に適用することを妨げるものは原
理的に何もない。

【００３５】本発明は試験すべきデバイスのための試験
環境を動的に生成する。試験環境は試験すべきデバイス
に関連するコンフィギュレーション・ファイルに含まれ
る情報に従って生成される。この試験法を今後は“能
動”モードと呼ぶことにする。しかし、好適な実施の形
態では、既述の試験法を提供するために用いるソフトウ
エア・ツールを、システム・シミュレーション環境が既
に存在し、従って試験環境を動的に生成する必要がない
過去のシミュレーション環境に対しても互換的に使用す
ることができる。このモードを今後“受動”動作モード
と呼ぶ。このような動作モードでもコンフィギュレーシ
ョン・ファイルが定義され、それを用いて、試験中にシ
ステム・シミュレーション環境内の各種デバイス間で受
け渡される信号をモニタするために使用されるプロセス
をコンフィギュアする。

【００３６】本発明は更に、一例として添付図面に示す
本発明の好適な実施の形態を参照しながら説明する。

【００３７】

【発明の実施の形態】本発明の好適な実施の形態を説明
するために、ＡＲＭ社によって開発された“アドバンス
ト・マイクロコントローラ・バス・アーキテクチャ”
（ＡＭＢＡ）仕様に従って動作するバスへつながるデバ
イスの試験について説明する。試験手順を詳しく説明す
る前に、ＡＭＢＡ仕様に従って動作するバスを採用する
デバイスの実現について図１を参照しながら簡単に説明
する。

【００３８】図１はマイクロコントローラ・チップある
いはシステム・オン・チップ（ＳｏＣ）１０の形の集積
回路を示しており、それはパーソナル・オーガナイザ、
移動電話、テレビ用トップボックス等の装置に使用され
よう。チップ１０は、ブリッジ回路１７０を介してつな
がれたシステム・バス１１０（今後はＡＨＢとも呼ぶ）
およびペリフェラル・バス１９５（今後はＡＰＢとも呼
ぶ）を含む。これらのバスはＡＭＢＡ仕様に従って動作
する。ＡＭＢＡ仕様は高性能の３２ビットおよび１６ビ
ット埋め込みマイクロコントローラを設計するためのオ
ンチップ通信標準を定義しており、システム・バス１１
０は高性能なシステム・モジュール用に、またペリフェ
ラル・バスは低電力周辺デバイス用に用いられる。高性
能システム・バス１１０は、ＣＰＵおよびその他のダイ
レクト・メモリ・アクセス・デバイスをシステム・バス
上においたままで外部メモリ帯域幅を維持することがで
き、他方ブリッジ回路１７０はシステム・バスをより狭
いペリフェラル・バス１９５へ接続し、ペリフェラル・
バス上には狭帯域幅の周辺デバイスが配置される。ブリ
ッジ回路１７０はシステム・バス１１０とペリフェラル
・バス１９５との間で必要なプロトコル変換を実行す
る。

【００３９】チップ１０は例えばＣＰＵ１４０やＤＭＡ
コントローラ１４５のような、システム・バス１１０へ
つながれる複数のマスタ論理ユニットを含むことができ
る。ここでは説明の便宜上、“マスタ”論理ユニットと
いう用語は処理要求を発行するように設計された論理ユ
ニットを意味し、他方そのような処理要求の受け手とし
て設計された論理ユニットを“スレーブ”論理ユニット
と呼ぶことにする。時間的に任意の瞬間にシステム・バ
スへアクセスするのはマスタ論理ユニットのうちの１つ
だけであり、このためシステム・バス１１０への各種マ
スタ論理ユニットによるアクセスを制御するためにアー
ビタ１２０が提供される。１つのマスタ論理ユニットが
システム・バス１１０へアクセスしようとするときは、
それはアービタ１２０に対してバス要求信号を発行す
る。時間的に任意の瞬間にアービタ１２０によって受信
されるバス要求信号が１つのみであれば、それはそのバ
ス要求信号を発行したマスタ論理ユニットに対してアク
セスを許可する。しかし、時間的に任意の瞬間にアービ
タ１２０によって２つ以上のバス要求信号が受信されれ
ば、アービタはどのマスタ論理ユニットにシステム・バ
ス１１０へのアクセスを与えるかを決めるために、予め
定められた優先基準を適用するようになっている。バス
へのアクセスを要求するすべてのマスタ論理ユニットの
うちで、アービタ１２０は最も高い優先度を有するマス
タ論理ユニットにアクセスを許可する。

【００４０】マスタ論理ユニットに加えて、１以上のス
レーブ論理ユニットをシステム・バス１１０へつなぐこ
ともある。分かり易いように、１つのスレーブ論理ユニ
ット、例えばランダム・アクセス・メモリ（ＲＡＭ）１
６０だけが図１には示されている。トランスファ要求が
スレーブ論理ユニットに対して発行された場合、アドレ
スがシステム・バス１１０上へ出力され、それがデコー
ダ論理１６５で復号されてどのスレーブ論理ユニットが
そのトランスファ要求を処理することになっているかが
決められる。デコーダは次にそれに従って適当なスレー
ブ論理ユニットを指定する。

【００４１】システム・バス１１０はまた外部バス・イ
ンタフェース１３０を介して外部バス１１５へつなぐこ
とができる。好適な実施の形態では、外部バス１１５は
３２ビットのベクトル・バスである。

【００４２】また、システム・バス１１０へつながれる
各種の論理ユニットの動作周波数を制御するためにクロ
ック発生器１７５が設けられる。これによって、マスタ
論理ユニットによって出力されるトランスファ要求信号
のタイミングはクロック発生器１７５のクロック周波数
で決まることになる。

【００４３】ペリフェラル・バス１９５には複数の周辺
デバイスが接続されよう。そのような周辺デバイスの例
は、シリアル・データを受信および送信するための“ユ
ニバーサル非同期受信および送信”（ＵＡＲＴ）論理ユ
ニット１５０、例えば割り込みを発生するために用いら
れるタイマ１５５、短距離の高速赤外通信のために用い
られる赤外線通信（ＩｒＤＡ）インタフェース１８０、
ユニバーサル・シリアル・バス（ＵＳＢ）１８５、同期
データ・リンク制御（ＳＤＬＣ）インタフェース２０
０、およびアナログ・ディジタル（Ａ／Ｄ）およびディ
ジタル・アナログ（Ｄ／Ａ）変換器２０５および２１０
である。

【００４４】図１に示すマイクロコントローラ・チップ
１０では、ペリフェラル・バス１９５はシステム・バス
１１０と同じクロック速度で動作するように構成されて
いる。従って、システム・バス１１０用としてクロック
発生器１７５で生成されるクロック信号はブリッジ１７
０にも送られ、ブリッジ１７０は周辺ユニット１５０、
１５５、１８０、１８５、２００、２０５、および２１
０の動作を制御するために必要なクロック信号を発生さ
せるように構成されている。

【００４５】マスタ論理ユニット１４０、１４５が、ペ
リフェラル・バス１９５へつながれた周辺ユニットによ
るハンドリングを要求する処理要求をシステム・バス１
１０上へ発行するときは、ブリッジ１７０がその処理要
求信号を受信し、周辺ユニット１５０、１５５、１８
０、１８５、２００、２０５、２１０のどれに対してそ
の処理要求が向けられているかを判断し、正しい周辺ユ
ニットに対して、その周辺ユニットの動作を制御するた
めに必要なクロック信号と一緒にその処理要求を出力す
る。更に、その処理要求をペリフェラル・バス上へ出力
する前に、システム・バス１１０で使用されるプロトコ
ルと、ペリフェラル・バス１９５で使用されるプロトコ
ルとの間で必要なプロトコル変換工程がブリッジ１７０
によって実行される。

【００４６】図１に示す構造では、メイン・システム・
バス１１０に負荷を掛けずに複数の周辺ユニットをペリ
フェラル・バス１９５へつなぐことができ、ペリフェラ
ル・バス１９５は１つの周辺ユニットへアクセスする必
要が生じたときだけ使用されるので、全体として電力消
費が削減される。

【００４７】ＡＭＢＡ仕様は、複数の異なる部品を集積
化することによって迅速にＳｏＣデバイスを構築するこ
とを目的にしている。ＡＭＢＡ仕様は、標準インタフェ
ースを提供することでこのプロセスを可能にする。これ
により、個々の個別部品の開発業者は標準インタフェー
スを利用することで、その部品が最終的に統合されるシ
ステムに関して知識を何ら持たなくても、その部品（こ
こでは被験デバイス（ＤＵＴ）とも呼ぶ）を設計および
試験することができるようになる。従って、一例とし
て、図１のＣＰＵ１４０をＳｏＣ１０へ統合するように
設計する場合、設計者はＳｏＣ１０にはそのほかにどの
ようなデバイスが組み込まれるかを知る必要がない。

【００４８】しかし、ＡＭＢＡ仕様に従うバスを利用し
て後にＳｏＣへ組み込まれる個別デバイスを設計する場
合には、設計者がそのデバイスがＡＭＢＡ仕様によって
規定されるバス・プロトコルに従っていることを確認す
るための試験を実行することは明らかに重要なことであ
る。実際に、ＳｏＣ設計者は、集積業者に対してその部
品がＳｏＣ設計の残りの部分と統合されたときに正しく
機能することを確信させるために、個別部品がＡＭＢＡ
バス・プロトコルに準拠するという何らかの確証を得た
いと思うのが普通である。

【００４９】

【実施例】図２は、ＤＵＴがＡＭＢＡバス・プロトコル
に準拠することを本発明の好適な実施の形態の能動モー
ドにおいて試験するために提供される論理要素を模式的
に示すブロック図である。図２に示すように、ＤＵＴ３
３０は、ＤＵＴ３３０用の試験環境を生成するために使
用されるＡＭＢＡ部品テストベンチ３００へバス３４０
を介してつながれる。好適な実施の形態では、ＡＭＢＡ
部品テストベンチはソフトウエア的に実現され、ユーザ
が定義するテスト・シーケンス・ファイル３０５からス
ティミュラス発生および応答チェック情報を読み出すよ
うに構成されている。このファイルはそのＤＵＴが利用
するＡＭＢＡバス・プロトコル部分に対するＤＵＴの準
拠性を試験する目的を持ってそのＤＵＴ３３０に関心を
持つユーザによって提供される。

【００５０】図２に示すシミュレーション環境はまた、
プロトコル・チェック・コンポネント３２０およびカバ
レッジ・モニタ・コンポネント３１０を含む。プロトコ
ル・チェック・コンポネント３２０は好適な実施の形態
では、ＤＵＴ３３０がＡＭＢＡ仕様の規則に従うことを
確認するためのチェックをサイクル毎の実行するように
構成されている。プロトコル・チェックはＡＭＢＡ仕様
から取り出された一定の規則群であり、ＤＵＴはＡＭＢ
Ａ仕様に準拠することを主張するためにはそれらの規則
のどれにも違反してならない。それらの規則はＤＵＴ３
３０がどのようなタイプのものであろうとも従わなけれ
ばならないし、従ってＤＵＴ３３０に依存してプロトコ
ル規則をコンフィギュアするようなことはない。

【００５１】当業者には明らかなように、どんな特殊な
バス・プロトコルに対しても、チェックする必要のある
そのような規則はかなり多いのが普通である。ＡＭＢＡ
ＡＨＢマスタ・プロトコル規則の一例は、“Ｓｐｌｉ
ｔあるいはＲｅｔｒｙ応答の第２サイクルで、マスタは
ＨＴＲＡＮＳをＩＤＬＥにドライブしなければならな
い”である。ＳｐｌｉｔまたはＲｅｔｒｙ応答はスレー
ブ・デバイスからマスタ・デバイスへの応答であって、
スレーブ・デバイスがその時点に行なわれたマスタから
のトランスファ要求を処理できないことを示す。ＨＴＲ
ＡＮＳ信号はマスタによって発行される制御信号であっ
て、マスタが実行しているバス・トランスファのタイ
プ、例えばノンシーケンシャル、シーケンシャル、アイ
ドル、あるいはビジーを示す。トランスファ要求のｒｅ
ｔｒｙを試みる前に、スレーブ・デバイスが別のトラン
スファ要求を受信する準備ができている状態に戻る機会
を与えるためには、ＳｐｌｉｔまたはＲｅｔｒｙ応答に
続くサイクルでアイドル・トランスファをアサートする
必要がある。

【００５２】カバレッジ・モニタ・コンポネント３１０
は、テスト・シーケンス３０５実行中に、ＡＭＢＡ部品
テストベンチ３００によって生成される試験環境内でＤ
ＵＴ３３０とその他の任意の試験部品との間で受け渡さ
れる信号をモニタすることによって１組のカバレッジ・
ポイントが観測されるかどうか決定するために使用され
る。カバレッジ・ポイントは、準拠性を主張できる前
に、試験環境内で観測すべき各種バス・トランザクショ
ンのリストである。従って、カバレッジ・ポイントの目
的は、準拠性を主張できる前に、試験によってＤＵＴが
十分に調べられたことを保証することである。カバレッ
ジ・ポイントの一例は、“バス・スレーブは同じアドレ
スへの書込みトランスファが直後に続く読出しトランス
ファによってアクセスされなければならない”である。

【００５３】明らかなように、確認する必要のあるカバ
レッジ・ポイントはＤＵＴ３３０に依存する。例えば、
マスタＤＵＴは異なるやり方でスレーブＤＵＴとインタ
フェースするであろうから、準拠性を保証するために確
認すべき各種バス・トランザクションはＤＵＴのタイプ
毎に異なるであろう。従って、カバレッジ・モニタ・コ
ンポネント３１０は試験される特定のＤＵＴ３３０に関
連して得られるコンフィギュレーション情報３１５に従
ってコンフィギュアされる。

【００５４】従って、理解されるように、標準的な予め
定義されたバス・トランザクションのシーケンスの代わ
りにカバレッジ・ポイントを使用する利点は、カバレッ
ジ・ポイントを利用することによって、バス・インタフ
ェースを完全に活用するためには特定のＤＵＴが１つの
特別なトランザクション・シーケンスを必要とするだけ
でよいということである。

【００５５】注意すべきことは、プロトコル・チェック
・コンポネント３２０およびカバレッジ・モニタ・コン
ポネント３１０は準拠性試験中にトランスファされる実
際のデータの完全性を自動的にはチェックしないという
ことである。ユーザは準拠性実行中にＤＵＴが正しく動
作することを確認しなければならない。しかし、図２の
ようにコンフィギュアされたときは、シミュレーション
環境は、ユーザが定義するテスト・シーケンス入力ファ
イルの“データ・チェック・コマンド”をサポートする
ことによってＤＵＴの動作試験を支援する。例えば、デ
ータがスレーブＤＵＴに記憶され、そしてその後でスレ
ーブＤＵＴから読み戻される場合、ユーザが定義するテ
スト・シーケンスはスレーブＤＵＴから返されると期待
されるデータの値を指定することができ、それをチェッ
クして正しい動作を確認することができる。

【００５６】後でもっと詳細に説明することになるが、
図２に模式的に示す能動モードのシミュレーション環境
を利用する場合、ユーザはユーザが定義するテスト・シ
ーケンス３０５、ＤＵＴ３３０のＲＴＬ実現、およびＤ
ＵＴに特有なコンフィギュレーション情報を提供するユ
ーザ・コンフィギュレーション・ファイルを提供するこ
とが好ましい。これら３つのアイテムは好適な実施の形
態ではテストベンチのアプリケーション・プログラミン
グ・インタフェース（ＡＰＩ）を通して供給され、それ
らがその後に試験環境を生成する。このプロセスは後で
もっと詳しく説明する。

【００５７】上で述べた能動動作モードでは、ＤＵＴ３
３０のバス・プロトコル準拠を試験するためにＤＵＴ３
３０と相互作用するために必要な各種のその他部品に対
してユーザがＲＴＬモデルを生成する必要はない。好適
な実施の形態では、好適な実施の形態のテストベンチＡ
ＰＩが準拠性ツールの中に組み込まれ、このツールが次
に既知のハイレベル・ベリフィケーション・ランゲージ
（ＨＶＬ）シミュレーション・ツール、例えばＶｅｒａ
やＳｐｅｃｍａｎとインタフェースする。準拠性ツー
ル、およびこのツールの一部を構成するコンフィギュレ
ーションＡＰＩの存在は、ユーザによって与えられる入
力、すなわちユーザ・コンフィギュレーション・ファイ
ル、ユーザが定義するテスト・シーケンス、およびＤＵ
ＴのＲＴＬ表現に基づく試験環境の動的生成を可能にす
る。従って、準拠性ツールは、さもなければＨＶＬシミ
ュレーション・ツールを使用して必要とされるチェック
・ルーチンを実現するために要したであろう高度な技能
を不要とし、また各チェック環境のコンフィギュレーシ
ョンおよびデバッグを不要とする。

【００５８】上で図２を参照しながら説明した準拠性ツ
ールの能動モードは最初からＤＵＴ３３０を生成する場
合には明らかに有利であるが、例えばバスを介してイン
タリンクされた部品の複数のＲＴＬ実現を含めて、ユー
ザがかなりうまくシステム・シミュレーション環境を既
に開発している状況も多いと思われる。好適な実施の形
態では、そのようなシステム・シミュレーション環境を
利用できるようにするために、準拠性ツールは図５に示
す受動的な動作モードもサポートする。図５に示すよう
に、既存のシステム・シミュレーション環境５００を準
拠性ツールにロードし、バス３４０を介してＤＵＴ５１
０へ接続することができる。それでもなお、カバレッジ
・モニタ３１０およびプロトコル・チェッカ３２０は維
持され、試験中に各種デバイス間で受け渡される信号に
対して必要なチェックを実行できるし、またカバレッジ
・モニタ３１０もＤＵＴ５１０に関連するコンフィギュ
レーション情報３１５に基づいてコンフィギュアでき
る。従って、図５の受動モード実施例では、ユーザがコ
ンフィギュレーションＡＰＩを介して、ユーザ・コンフ
ィギュレーション・ファイル、既存のシステム・シミュ
レーション環境５００、およびＤＵＴ５１０のＲＴＬ実
現を提供する。

【００５９】従って、要約すれば、好適な実施の形態の
準拠性ツールは、図２に示すような能動モードか、ある
いは図５に示すような受動モードのいずれかで動作する
ようにコンフィギュアできる。ここでコンフィギュレー
ションＡＰＩが提供されるため、ユーザはそれら２つの
異なるコンフィギュレーションを指定するために必要な
情報を入力できる。

【００６０】能動モードのコンフィギュレーションを実
現する２つの例が図３および図４に示されている。これ
らの好適な実施の形態では、能動モードのコンフィギュ
レーションは次のようなデバイスをサポートする：ＡＨ
Ｂマスタ、ＡＨＢスレーブ、ＡＰＢマスタ（すなわち、
ブリッジ）、ＡＰＢスレーブ、アービタ、およびデコー
ダ。図３はＤＵＴ３３０がスレーブＤＵＴである能動モ
ードのコンフィギュレーションを示している。このコン
フィギュレーションでは、準拠性ツールのＡＭＢＡ部品
テストベンチ・コア３５０内のコンフィギュレーション
・エンジンは、例えばデコーダのような必要とされる任
意のその他の試験部品とともに、適当なＡＨＢ／ＡＰＢ
マスタ部品３５５を動的に生成しよう。スレーブＤＵＴ
３３０はそれがマスタ・デバイスに応答するかのように
バスにアクセスする。しかし、その回りに生成される試
験環境はユーザが定義するテスト・シーケンス３０５に
よって指図されるような命令された応答をドライブす
る。プロトコル・チェック・コンポネント３２０および
カバレッジ・モニタ・コンポネント３１０は、それに従
ってテスト・シーケンスの実行中にバス上で受け渡され
る信号をモニタすることによって、スレーブＤＵＴがバ
ス・プロトコルに準拠するかどうかを示すデータを生成
する。

【００６１】好適な実施の形態では、ユーザ・トリック
ボックス・コンポネント３６０も提供されて、ビヘイビ
アを追加できるようにスレーブ応答信号との多重化が行
なわれる。ユーザ・トリックボックス３６０は好適な実
施の形態ではＲＴＬで書かれ、ユーザ・トリックボック
ス３６０とスレーブＤＵＴ３３０の両方を含むインタフ
ェース・モジュール内でインスタンス化される。後で詳
しく説明するように、このインタフェース・モジュール
は次に、適当な信号のマッピングを介して準拠性ツール
によって生成される試験環境の残りの部分とインタフェ
ースする。従って、ＲＴＬトリックボックス３６０はＤ
ＵＴ３３０とインタフェースすることができ、ＤＵＴの
非ＡＭＢＡ信号を制御および観測することを可能にす
る。

【００６２】好適な実施の形態のトリックボックスは、
トリックボックスを制御するための標準的なＡＨＢ／Ａ
ＰＢスレーブ・インタフェースのほかに、３２ビット出
力ポートおよび３２ビット入力ポートを有する。ＡＨＢ
／ＡＰＢインタフェースはトリックボックスがテストベ
ンチでインスタンス化され、ＤＵＴではなくトリックボ
ックスにアクセスするテストベクトルを用いて制御され
ることを可能にする。この文脈で用いられるように、
“ベクトル”という用語はユーザが定義するテスト・シ
ーケンス３０５の１要素を意味し、それはバス上で実行
されるアクションおよび／または特別な時間におけるバ
ス・ステータスを定義する。トリックボックス３６０を
用いて導入される付加的なビヘイビアの一例として、も
しも図３の能動モードがＡＨＢ能動モードであると仮定
すれば、トリックボックス３６０を用いて別のスレーブ
・デバイスのような期待される応答を提供することがで
き、デコーダ試験部品を用いてスレーブＤＵＴ３３０の
選択を解除し、トリックボックス・スレーブ・デバイス
を選択することができる。

【００６３】図４はマスタＤＵＴ４００を試験するため
に実現される別の能動モードを示す。この構成では、準
拠性ツールのＡＭＢＡ部品テストベンチ・コア３５０内
のコンフィギュレーション・エンジンを使用して、例え
ばアービタ、デコーダ、およびダミー・マスタのような
必要とされるその他任意の試験部品と一緒にＡＨＢ／Ａ
ＰＢスレーブ部品４１０が生成されよう。コンフィギュ
レーションおよび／またはＤＵＴのタイプに依存して準
拠性ツールの中からある種のファシリティを追加するこ
ともできる。例えば、ＡＨＢマスタ・コンフィギュレー
ションの場合は、メモリ初期化ファイル４２０を有する
ビヘイビア・メモリ・スレーブ・デバイスを生成するこ
とが好ましく、それはそれ自身が同じフォーマットのメ
モリ・ダンプを生成する。メモリ・ダンプ・ファイルは
テストベンチ・コア３５０内に実現されたメモリ・モデ
ルの内容のファイル表現であり、試験が完了した後で生
成される。試験中にメモリ・モデルに対して修正がなけ
れば、結果のメモリ・ダンプ・ファイルはメモリ初期化
ファイルと同じ内容を有することになる。

【００６４】図４のマスタＤＵＴ４００はあたかもスレ
ーブ・デバイスを通信しているようにバスにアクセスす
る。しかし、その回りに生成される試験環境はユーザが
定義するテスト・シーケンス３０５によって定義される
ような命令された応答をドライブ・バックする。図３の
例と同じように、ユーザ・トリックボックス・コンポネ
ント３６０を提供して、それをスレーブ応答信号と多重
化することによってビヘイビアを追加することができ
る。

【００６５】上の能動モードの説明から明らかなよう
に、準拠性ツールの能動モードコンフィギュレーション
は各ＤＵＴに対してポイント・ソリューションとなるテ
ストベンチを生成しなければならないという負担を大幅
に軽減する。準拠性ツールそれ自身は、ユーザが供給す
るスティミュラスを準拠性試験の過程で提供するよう
に、ＤＵＴを取り巻く、必要なすべてのＡＭＢＡ“ファ
ブリック”を生成する。

【００６６】これとは対照的に、先に述べた受動モード
は、主としてシステム中の試験環境を目的としている。
受動モードは準拠性ツールによるＡＭＢＡファブリック
の動的生成という概念を等価的に禁止し、そうでなけれ
ば能動モードで利用できたスティミュラス・ドライブ機
能を禁止する。既に述べたように、同じユーザ・コンフ
ィギュレーション・ファイルをＤＵＴそれ自身に関する
詳細を指定するためにも使用することが好ましい。しか
し受動モードでは、能動モード特有のコンフィギュレー
ション・オプションはすべて無視される。

【００６７】受動モードはまた過去の設計を検証するた
めにも理想的であり、ユーザは準拠性試験のためにＤＵ
Ｔを能動モードのテストベンチへ分離する必要がない。
しかし注意すべきことは、ＤＵＴへのスティミュラスの
発生源が限られたトランザクションまたはシナリオ生成
能力しか持たない場合は（すなわち、能動モードにおい
て使用される、ユーザが定義するテスト・シーケンスの
場合ほどにはＤＵＴに対して適するように調整されてい
ないのが普通である）、全カバレッジを達成することは
受動モードのほうがより困難であろうということであ
る。もっと可能性の高いシナリオは、受動モードを使用
して、試験実行シーケンスの過程でＤＵＴがＡＭＢＡプ
ロトコル違反を何ら行なわなかったことを保証すること
であろう。

【００６８】いずれの動作モードでも、準拠性ツールは
試験実行の終わりにオプションで目に見える形でカバレ
ッジ・レポートを生成することが好ましい。これはその
ＤＵＴに付随する、完了し傑出した準拠性カバレッジ目
標とその特別な機能に関するコンフィギュレーションの
両方を表示するグラフィカル・ユーザ・インタフェース
（ＧＵＩ）の形であることが好ましい。このデータから
ＡＭＢＡ準拠性の証明を発行できる。好適な実施の形態
では、ＡＭＢＡ準拠性証明は、ＡＭＢＡ仕様改訂版番
号、準拠性コンフィギュレーション、および試験しなか
ったすべての準拠性カバレッジ・ポイントの説明を指定
するであろう。好適な実施の形態では、準拠性ツールは
また、ＤＵＴ用の試験環境を許可し、それとともにユー
ザが準拠性試験を繰り返すことができるように必要な任
意のテストベクトルを出力することを許可する。

【００６９】既に述べたように、好適な実施の形態で
は、準拠性ツールは標準的なＨＶＬシミュレーション・
ツールと組み合わせて実行するのが好ましい。ここで、
シミュレーション・ツールと準拠性ツールとが一緒にな
って準拠性チェックを実行するプロセスについて、図６
および図７のフロー図を参照しながら詳細に説明する。

【００７０】図６に示すように、準拠性チェックは工程
６００から始まり、工程６０５へ進んでそこからシミュ
レーション・ツールが始動する。シミュレーション・ツ
ールが始動すると、それは準拠性ツールを使用すべきこ
とを指示する。プロセスは次に工程６１０へ進み、ＤＵ
Ｔインタフェース・モジュールがロードされる。既に述
べたように、このインタフェース・モジュールはその中
へＤＵＴのＲＴＬ表現をインスタンス化するモジュール
である。好適な実施の形態では、インタフェース・モジ
ュールはまたユーザ・トリックボックスのＲＴＬ表現も
含む。更に、インタフェース・モジュールはオプション
のクロックおよびリセット信号を提供し、それと一緒
に、ＲＴＬと準拠性ツールの試験環境それ自身との間の
付随する信号多重化も提供する。このことから、インタ
フェース・モジュールは、与えられたユーザ・コンフィ
ギュレーション・ファイルに基づいてシミュレーション
時点で能動モードにおいて動的に生成される準拠性ツー
ル試験環境とのインタフェースを構成する簡単なＲＴＬ
の最上位モジュールとみなすことができる。

【００７１】工程６１５では準拠性ツールがロードされ
るが、これは能動あるいは受動のいずれかのモードにツ
ールをコンフィギュアするために使用されるコンフィギ
ュレーションＡＰＩを、カバレッジ・モニタおよびプロ
トコル・チェック機能と一緒に導入する。工程６２０で
は、シミュレーション・ツールが準拠性ツールに処理を
渡し、その後プロセスは工程６２５へ進む。

【００７２】工程６２５では、準拠性ツールが、ユーザ
によってコンフィギュレーションＡＰＩを介して与えら
れるユーザ・コンフィギュレーション・ファイルを読み
込んでチェックする。好適な実施の形態では、各々の準
拠性ツールの動作モード、例えばＡＨＢ＿マスタ、ＡＨ
Ｂ＿スレーブ、ＡＰＢ＿マスタ、ＡＰＢ＿スレーブ、ア
ービタ、あるいはデコーダに対してテンプレートのユー
ザ・コンフィギュレーション・ファイルが提供される。
従って、ユーザがＡＨＢマスタ・デバイスを試験しよう
とする場合には、ユーザはＡＨＢ＿マスタのテンプレー
ト・ユーザ・コンフィギュレーション・ファイルを選
ぶ。コンフィギュレーション・ファイルにはそのデバイ
スに特有なコンフィギュレーション情報を規定する予め
定められたパラメータが含まれる。それらのエントリの
少なくともいくつかは、試験される特定デバイスに関心
を持つユーザによって入力される必要がある。好適な実
施の形態では、コンフィギュレーション・ファイルに含
まれるエントリは次のものを規定する：

【００７３】１．ＤＵＴ名およびオプションＩＤ； ２．ＤＵＴ設計の階層構造のＨＤＬパス／レベル ３．ＤＵＴ信号マップ、例えばＨＣＬＫ＝ＨＣＬＫｓｙ
ｓ、あるいは上記２をオーバーライドするためのＨＣＬ
Ｋ＝〜／ｔｏｐ／ＨＣＬＫ ４．一般的なテストベンチ・パラメータ、例えばＥＮＤ
ＩＡＮＥＳＳ＝ＬＩＴＴＬＥ、ＥＲＲＯＲＳＴＯＰ＝Ｙ
ＥＳ、ＶＥＲＢＯＳＩＴＹ＝ＥＲＲＯＲＳ＿ＯＮＬＹ；
および ５．カバレッジ・コンフィギュレーション、例えば読出
し専用デバイスに対してＤＩＲＥＣＴＩＯＮ＝ＮＯ＿Ｗ
ＲＩＴＥ

【００７４】ＡＨＢマスタＤＵＴ用のユーザ・コンフィ
ギュレーション・ファイルの一例を次に示す。

【００７５】

【表１】

【００７６】上のことから明らかなように、このファイ
ルの第１エントリは試験されるデバイス名を示してお
り、ここではＡＲＭプロセッサ・コアとなっている。第
２エントリの“ＨＤＬＰＡＴＨ”はＤＵＴの階層構造の
レベルを示す。次には、マスタＤＵＴによって使用さ
れ、ＤＵＴ内部で使用される名前をＡＭＢＡ信号名に対
してどのようにマッピングするかを示すすべての信号を
示す複数のエントリが続く。例えば、ＤＵＴによって使
用される信号ＨＷＲＩＴＥｏｕｔはＡＭＢＡバス信号Ｈ
ＷＲＩＴＥにマッピングされる。

【００７７】コンフィギュレーション・ファイル中の次
のエントリはデバイスを能動モードと受動モードのどち
らで試験すべきかを指定する。ここでは受動モードを使
用することが確認されている。次のエントリはスティミ
ュラスとして使用すべきユーザが定義するテスト・シー
ケンスを指定する。この例では、２つのテストベクトル
・ファイル、すなわちｍｅｍｏｒｙ．ｖｅｃおよびｐｅ
ｒｉｐｈｅｒａｌ．ｖｅｃが指定されている。図４を参
照すると、ベクトル・ファイルｐｅｒｉｐｈｅｒａｌ．
ｖｅｃはユーザが定義するテスト・シーケンス３０５で
あり、ベクトル・ファイルｍｅｍｏｒｙ．ｖｅｃはメモ
リ４２０に置くべきデータを含んでいる。試験が始まる
と、プロセッサ・コアのＤＵＴはメモリ４２０からデー
タを読み込む。このデータはコアによって実行すべき一
連の命令を規定する。これはバス３４０上でバス・トラ
ンスファを引き起こし、ユーザが定義するテスト・シー
ケンス３０５、すなわちこの例ではｐｅｒｉｐｈｅｒａ
ｌ．ｖｅｃがスレーブ試験部品によって提供される応答
を命令する。このエントリはまた試験ランを開始する前
に入力ファイルの文法チェックをすべきかどうかを指定
する。

【００７８】好適な実施の形態では、スティミュラス・
ベクトル・ファイルのフォーマットは、それをＰｅｒｌ
やＣのような言語を使用して手書き、あるいはもっと便
利な自動生成できるように特別に設計されている。

【００７９】ユーザ・コンフィギュレーション・ファイ
ルの次のエントリは、受動モードにおいて特別に使用さ
れるいくつかの追加信号を指定する。その次には、試験
に関連するデバッグおよびシステム環境設定を提供する
いくつかの一般的なパラメータが続く。例えば、特定例
では、バス幅が３２ビットであると指定される。

【００８０】その後には能動モードに特有なコンフィギ
ュレーション情報を提供するエントリが続く。最後に、
ファイル中の最後に３つのエントリは、例えばカバレッ
ジ・モニタによってチェックすべきカバレッジ・ポイン
トを決めるときに使用されるデバイス機能を規定する。

【００８１】図６に戻って、ユーザ・コンフィギュレー
ション・ファイルが一旦読み込まれチェックされると、
次に準拠性ツールはプロトコル・チェック・コンポネン
トを生成し、またカバレッジ・モニタ・コンポネントを
生成およびコンフィギュアする。上で述べたように、カ
バレッジ・モニタのコンフィギュレーションはユーザ・
コンフィギュレーション・ファイルに規定されたデバイ
ス機能を考慮して行われる。

【００８２】準拠性ツールは次に工程６３０においてＤ
ＵＴを能動モードで実行させるべきかどうかを決定す
る。先に述べたように、この情報はユーザ・コンフィギ
ュレーション・ファイルに与えられている。もしＤＵＴ
を受動モードで実行させるべきであれば、プロセスは工
程６３５へ分岐して、カバレッジおよびプロトコル・チ
ェックに関する信号マッピングが実行される。これはユ
ーザ・コンフィギュレーション・ファイルに与えられる
信号マッピング情報を用いて行なわれる。次にプロセス
は分岐して工程６５０のシミュレータ・ツールへ戻り、
その後で工程６６０で試験が実行される。受動モードで
は、この試験は既存のシステム・シミュレーション環境
内に定義されよう。

【００８３】しかし工程６３０でＤＵＴが能動モードで
実行すべきことが決まった場合には、プロセスは工程６
４０へ進み、準拠性ツールによってＤＵＴ用の試験環境
が動的に生成される。このプロセスは図７に関してもっ
と詳細に説明する。

【００８４】図７に示すように、第１工程（工程７０
０）は生成する必要のある環境のタイプを規定する。こ
の情報は被験デバイスのタイプから決まる。例えば、試
験すべきデバイスがＡＨＢマスタ・デバイスであれば、
好適な実施の形態では試験環境はアービタ、デコーダ、
デフォルト・マスタ、および１以上のスレーブ・モデル
を含む必要がある。あるいは、ＤＵＴがＡＨＢスレーブ
であれば、試験環境は少なくともデコーダおよびマスタ
・モデルを含む必要がある。

【００８５】一旦環境のタイプが指定されれば、次には
必要なオブジェクトのインスタンスが工程７１０で生成
される。従って、この時点で試験環境に必要な試験部品
が生成され、好適な実施の形態では各試験部品がＯＯＰ
オブジェクトとしてインスタンス化される。次に、すぐ
上で述べたＡＨＢマスタＤＵＴの例に戻って、工程７１
０でＤＵＴと組み合わせることによって試験環境を形成
するためにアービタ、デフォルト・マスタ、およびスレ
ーブ・オブジェクトが生成される。

【００８６】当業者には明らかなように、ＯＯＰプログ
ラミングでは、各オブジェクトにはそれの関数を定義す
る複数のメソッドが付随する。本発明の好適な実施の形
態に従えば、オブジェクトの各インスタンスに付随させ
るべき実際のメソッドは工程７００で検出される環境の
タイプに依存する。例えば、ＤＵＴがマスタ・デバイス
であれば、生成されるデコーダ・オブジェクトは単にマ
スタからの要求に応答するスレーブを選ぶことができれ
ばよい。しかし、ＤＵＴがスレーブ・デバイスであれ
ば、デコーダもＤＵＴの選択を解除して、別のスレーブ
を選択することができ、それによってスレーブＤＵＴが
ビヘイビアをデコーダによる選択解除時に決定できるよ
うにする機能も含むことが好ましい。

【００８７】プロセスは次に工程７２０へ進み、そこで
デバイス間の信号マッピングが更新される。既に説明し
たように、これにはユーザ・コンフィギュレーション・
ファイルに与えられる信号マッピング情報への参照が含
まれ、またＤＵＴによって使用される信号名を試験環境
の残りの部分で使用されるＡＭＢＡ信号名へマッピング
することが含まれる。

【００８８】プロセスは次に工程７３０へ進んで、各信
号の初期値が設定される。例えば、ＤＵＴがスレーブ・
デバイスの場合、それがマスタ・デバイスからトランス
ファ要求を受信する準備ができていることを確認する論
理１のＨＲＥＡＤＹ信号をアサートする必要がある。

【００８９】工程７３０の完了に続いて、プロセスは図
６の工程６５０へ戻って、処理がシミュレータ・ツール
へ戻される。工程６６０では、シミュレータは能動モー
ドで試験を実行する。これはユーザが定義するテスト・
シーケンスであるか、あるいはユーザ・コンフィギュレ
ーション・ファイルに定義されたテスト・シーケンスで
ある。オプションとして、準拠性ツールはユーザ・コン
フィギュレーション・ファイルをチェックするときに、
ユーザが定義するテスト・シーケンスが有効であること
をチェックするためにユーザ・コンフィギュレーション
・ファイルに定義されたユーザが定義するテスト・シー
ケンスのチェックを実際に実行するように構成できる。
そのような工程は工程６２５において行われることが多
い。この時点でこのチェックを実行することは有益であ
る。それは、後の都合のよい時点、例えば夜通しで実際
の試験を実行するように考えているし、また工程６６０
において試験を開始する前にテスト・シーケンスには何
も悪いところは基本的にないことを知るのが好ましいの
は明らかだからである。

【００９０】能動または受動モードのいずれかで準拠性
試験を実行させるために好適な実施の形態で実行される
プロセスについて説明してきたが、好適な実施の形態で
実行されるプロトコル・チェックおよびカバレッジ・モ
ニタのより詳しいことについて次に説明する。

【００９１】既に述べたように、プロトコル規則のコン
フィギュレーションは行なわれない。またＡＭＢＡバス
準拠性を主張するためにはＤＵＴはＡＭＢＡプロトコル
規則のどれにも違反してはならない。

【００９２】しかし、これとは対照的に、好適な実施の
形態ではカバレッジ・ポイントは、いくつかのＤＵＴは
ＡＭＢＡバスの機能のすべてを利用しなくてもよいこと
を想定してコンフィギュアされる。ＤＵＴに対して許容
できるコンフィギュレーションは、ＳｏＣに組み込まれ
るすべての部品が常に一緒に正しく動作するように定義
されることが重要である。

【００９３】基本的な規則として、ＡＭＢＡ部品は考え
うるすべての入力組合せを受け入れる必要があるが、考
えうるすべての出力の組合せを生成する必要はない。

【００９４】一例として、Ｔｒａｎｓｆｅｒ Ｒｅａｄ
ｙ、Ｔｒａｎｓｆｅｒ Ｒｅｓｐｏｎｓｅ、およびＢｕ
ｓ Ｇｒａｎｔに関する入力信号を有するバス・マスタ
はそれら入力の考えうるすべての組合せを処理できなけ
ればならない。しかし、考えうるすべての出力組合せを
生成する必要はなく、それの動作にとって適切なタイプ
のバーストおよびトランスファ・サイズを生成するだけ
でよい。

【００９５】注意すべき点は、或るカバレッジ・ポイン
トをターン・オフさせればプロトコル・チェックを付加
できるということである。例えば、もしもバス・マスタ
準拠性チェックが４ビート・ラッピング・バーストをサ
ポートしないバス・マスタとしてコンフィギュアされれ
ば、このコンフィギュレーション・オプションは各種タ
イプの４ビート・ラッピング・バーストを観測するカバ
レッジ・ポイントを除去する効果を持つ。しかし、これ
はマスタがこの種のトランスファを決して実行しないこ
とを保証する付加的なチェックを許容する。

【００９６】スレーブ・デバイスもまた、考えうるすべ
ての入力を受け入れることができ、トランスファのすべ
ての異なる組合せを正しく処理できなければならない。
しかし、バス上で利用可能なトランスファ情報のすべて
を利用するわけではないスレーブ・デバイスを構築する
ことは認められる。この典型的な例はバースト情報を利
用しないスレーブ・デバイスであろう。そのようなスレ
ーブ・デバイスの準拠性試験を簡略化するために、スレ
ーブ・デバイスの入力に特定の信号が含まれない場合に
は、それらの入力の異なる組合せに関連するカバレッジ
・ポイントを省略することができる。

【００９７】ここでプロトコル・チェック関数の詳細に
ついて詳しく見てみると、ＡＭＢＡバスのプロトコルを
チェックする基本原理は、ＡＭＢＡバス・プロトコルが
トランザクション中に観測されることを確認するチェッ
ク・シーケンスを採用することであり、それには個別ト
ランスファのバーストが複数個含まれる。好適な実施の
形態では、準拠性ツールは、シミュレーション・イベン
トがそれらのプロトコル・チェックを記述する発見的方
法をトリガすることを許容する時間表現を利用する。

【００９８】時間表現はビヘイビアを記述するイベント
および時間的オペレータの組合せである。時間表現は試
験中にイベント、フィールドの値、変数、あるいはその
他のアイテム間の時間的関係を取り込む。

【００９９】明らかなように、好適な実施の形態の準拠
性ツールには非常に多い可変数個の時間表現が用いられ
る。説明のために、そのような構成をどのように使用す
るかについて以下に簡単に見てみよう。

【０１００】好適な実施の形態では、Ｖｅｒｉｓｉｔｙ
Ｓｐｅｃｍａｎ“ｅ”言語を使用して時間表現が定義
される。図８の一番上には時間経過のグラフィカルな表
現として使用できる４つの凡例が示されている。図８の
残りの部分は、一例としてＡＭＢＡ ＡＨＢシーケンス
評価を提供しており、ＨＴＲＡＮＳ信号がＩＤＬＥにセ
ットされた場合（ｈｔｒａｎｓ．ｉｄｌｅイベント）の
ｈｇｒａｎｔイベントのモニタリングの様子を示してい
る。

【０１０１】図８を参照すると、ＨＣＬＫイベントはｈ
ｇｒａｎｔおよびｈｔｒａｎｓ．ｉｄｌｅイベントを含
む２つのシーケンスについてのサンプリング・イベント
である。ｈｃｌｋイベントそれ自身はＨＣＬＫ信号の立
ち上がりで発生される。

【０１０２】図８から分かるように、示されたいくつか
のイベントは信号値に直接関連しており、他方、その他
のイベントは基準イベントでサンプリングされた信号状
態の組合せで定義される。この例では、基準イベントは
ＨＣＬＫの立ち上がり端である。

【０１０３】｛＠ｈｇｒａｎｔ；＠ｈｔｒａｎｓ．ｉｄ
ｌｅ｝シーケンスはｈｃｌｋにおいてｈｇｒａｎｔが発
生する度に評価をスタートさせる。ｈｇｒａｎｔのｈｃ
ｌｋ１個分後でｈｔｒａｎｓ．ｉｄｌｅがサンプリング
されるとき、このシーケンスは成功である。

【０１０４】｛＠ｈｇｒａｎｔ；［１］；＠ｈｔｒａｎ
ｓ．ｉｄｌｅ｝シーケンスもまたｈｃｌｋでの最初のｈ
ｇｒａｎｔの発生によって評価を開始するが、“１サイ
クル続く”文節（［１］）のために次のｈｃｌｋが発生
するとシフトする。第３のｈｃｌｋが発生すると、シー
ケンスはｈｔｒａｎｓ．ｉｄｌｅイベントが存在すれば
成功する。しかし図８から分かるように、この時間表現
は第５サイクルの後は評価しない。それはｈｔｒａｎ
ｓ．ｉｄｌｅイベントが存在しないためである。

【０１０５】このように、図８に関連して上述したイベ
ントを用いて特定の規則が観測されない条件を捉えるこ
とによってプロトコル・エラーを定義できるのが普通で
ある。そのようなイベントは更に別のイベント・シーケ
ンスを構築するために用いられたり、あるいは論理的に
組み合わせてアサート・ステートメントを生成するため
に用いられたりする。準拠性ツールのプロトコル規則の
典型的な形式は次のようになっている：

【０１０６】

【数１】ｅｘｐｅｃｔ＜規則＞ｉｓ｛＜時間表現＞｝＠
ｈｃｌｋ；

【０１０７】時間表現を使用する代わりに採用できる別
の方式は形式論的な数学技法に基づいて利用できるプロ
パティ・チェッカ・ツールを使用するものである。フォ
ーマル・プロパティ・チェックにはシステム要求に密接
に合致するプロパティを書くこと、そして次にそのプロ
パティがその設計で確保されていることを完全に証明す
ることが含まれる。この方法が完全であるということは
機能シミュレーションによってカバーできないバグを見
出すことができるということを意味する。

【０１０８】プロパティ・チェッカ・ツールはブロック
・レベルで最も良く働く。１００Ｋゲートより小さいブ
ロックが理想的である。

【０１０９】プロパティ・チェック・ツールによってチ
ェックされるプロパティの例は、ＡＨＢマスタが認めら
れない場合にＨＴＲＡＮＳ信号出力がＩＤＬＥまたはＮ
ＯＮ−ＳＥＱＵＥＮＴＩＡＬになるという要求である。
このプロパティは図９Ａに示すタイミング図と合致する
ように書くことができる。図９Ａのタイミング図で、時
間ｔおよびｔ＋１はクロック・サイクルを表す。ドット
領域の値が仮定であり、続くＩＤＬＥ／ＮＳＥＱ部が証
明しなければならない部分である。タイミング図が意味
することは、もしもＨＧＲＡＮＴ信号が１つのクロック
・サイクル（時間ｔ）で低レベルであれば、次のクロッ
ク・サイクルではＨＴＲＡＮＳ信号はＩＤＬＥまたはＮ
ＳＥＱでなければならないということである。この証明
は時間ｔが任意のクロック・サイクルで成り立つように
徹底的に行われなければならない。すなわち、プロパテ
ィ・チェックはシミュレーション全体でタイミング図を
スライドさせるようにみなすことができる。仮定が成り
立つ場合はいつでもオブリゲーション部も成り立たなけ
ればならない。

【０１１０】もしプロパティが保持されることが分かれ
ば、ＤＵＴのＲＴＬ表現はそのプロパティによって指定
される要求を常に満たさなければならない。どこかの瞬
間にプロパティが保持されなければ、プロパティ・チェ
ッカはエラーを指摘する短い波形ファイルを出力するの
が好ましく、それを用いてデバッグが可能となる。

【０１１１】そのようなデバッグの一例として、図９Ａ
のプロパティを試験環境にあるＤＵＴに適用した場合の
デバッグ波形を観測したら、それは時間ｔにおいてＨＧ
ＲＡＮＴ信号が低レベルで、ｔ＋１ではＨＴＲＡＮＳ信
号がＳＥＱであるというプロパティの誤りをハイライト
表示した。実際にはＤＵＴのＲＴＬ表現にはバグがない
が、その代わりにプロパティそれ自身が不完全であっ
た。事実、もしＡＨＢマスタが待機していれば（ＨＲＥ
ＡＤＹ信号入力が低レベル）、ＨＴＲＡＮＳは保持され
るべきであるという状況が存在する。すなわち、図９Ｂ
のタイミング図改訂版によって、正しいプロパティを示
すことができる。

【０１１２】図９Ｂのタイミング図によって示されるプ
ロパティは、もしマスタが認められずまた待機状態でな
ければ、ＨＴＲＡＮＳ信号は続くクロック・サイクルで
ＩＤＬＥまたはＮＳＥＱでなければならないことを言っ
ている。

【０１１３】プロパティ・チェックについて議論してき
たが、ここでカバレッジ・モニタについて簡単に説明し
よう。既に述べたように、カバレッジはバス活動の特定
のシーケンスを観測するプロセスである。好適な実施の
形態では、ＶｅｒｉｓｉｔｙＳｐｅｃｍａｎツールが用
いられる。これはカバレッジ・グループの定義を通して
カバレッジ・モニタを可能とする。１つのカバレッジ・
グループは、時間的にデータを収集したデータ・アイテ
ムのリストを含むプログラム構造／オブジェクト・メン
バである。

【０１１４】Ｓｐｅｃｍａｎツールはまた、カバレッジ
・データ・アイテム間相互作用の観測を可能とするクロ
ス・カバレッジを実行できる。クロス・カバレッジを利
用するＡＭＢＡ ＡＨＢマスタの例は、バーストの各タ
イプ（ＳＩＮＧＬＥ、ＩＮＣＲ、ＷＲＡＰ４、ＩＮＣＲ
４、ＷＲＡＰ８、ＩＮＣＲ８、ＷＲＡＰ１６、ＩＮＣＲ
１６）について、読出しおよび書込みの両バーストに対
して異なるタイプのスレーブ応答が観測されることを確
認することであろう。先に述べたように、試験実行のラ
ンの終わりに、すべてのカバレッジ情報は１つのＧＵＩ
に順序正しくまとめられる。このＧＵＩはそのＤＵＴに
ついて要求されるカバレッジ・ポイントのうちどのくら
いがモニタされたかをユーザに対して表示することがで
きるようになっている。

【０１１５】好適な実施の形態の試験準拠性ツールにつ
いて詳細に説明してきたが、準拠性ツールをその中で使
用できるデータ処理システムについても図１０を参照し
ながら簡単に説明しよう。

【０１１６】図１０はデータ処理装置を示しており、そ
れはプロセッサ・コア８００、読出し専用メモリ（ＲＯ
Ｍ）８１０、ランダム・アクセス・メモリ（ＲＡＭ）８
３０、入力／出力（Ｉ／Ｏ）デバイス８４０、およびデ
ィスプレイ８５０を含んでおり、それらは適当なバス・
ネットワーク８２０を介して相互に接続されている。明
らかなように、バス８２０は単一バスでもよいが、部品
を互いに接続するために必要なバスの任意の組合せで構
わない。

【０１１７】好適な実施の形態では、好適な実施の形態
のシミュレータ・ツールおよび準拠性ツールはＲＡＭ８
３０へロードされ、次にプロセッサ・コア８００上で実
行される。オペレーティング・システム、例えばＢＩＯ
ＳはＲＯＭ８１０に記憶されるのが普通である。

【０１１８】任意の特定の試験を実行するために必要な
入力は一般的にはユーザによってＩ／Ｏデバイス８４０
を介して入力され、ＲＡＭ８３０に記憶される。従っ
て、能動モードでは、ユーザはＩ／Ｏデバイス８４０を
介して、ＤＵＴを含むインタフェース・モジュール、ユ
ーザ・コンフィギュレーション・ファイル、およびユー
ザが定義するテスト・シーケンスを入力する。これらは
例えばディスクからＩ／Ｏデバイス８４０によって読み
出される。この情報は次に、シミュレータ・ツールおよ
び準拠性ツールの実行中に必要に応じてプロセッサ・コ
ア８００によってＲＡＭ８３０から取り出される。試験
実行中あるいは実行後に、試験結果は例えばＶＤＵのよ
うなディスプレイ・デバイス８５０上へ表示されよう。
プロトコル規則のどれも違反されずにカバレッジ・ポイ
ントすべてがモニタされれば、任意の適当な出力デバイ
スへＩ／Ｏデバイス８４０を介して出力するための準拠
性証明を作製できる。

【０１１９】要約すれば、理解されるように、好適な実
施の形態の準拠性ツールはデバイスのバス・プロトコル
準拠性を試験するための特に使いやすく効率的な方法を
提供する。能動モードでは、ＤＵＴは非ＡＭＢＡのＩ／
Ｏ信号とインタフェースするために試験者が利用できる
トリックボックス・デバイスをオプションとした、単独
ユニットとして試験される。このオプションのトリック
ボックスは試験者の制御下でデバイスの或る要求される
ビヘイビアを誘発するために使用できる。能動モードで
は、ユーザが生成するスティミュラス・ファイルを準拠
性ツールによって読み出して、ユーザ・コンフィギュレ
ーション・ファイルに指定されたバス・インタフェース
信号上の所望のスティミュラスをドライブする。マスタ
ＤＵＴの場合には、ベクトル・スティミュラス・ファイ
ルが供給され、それによって、データ・チェックのため
のデバイスへの予期されるアクセスとともに、待機ステ
ータス、応答タイプ、グラント・ステータスを含むスレ
ーブ応答ビヘイビアを決定する。スレーブＤＵＴの場合
は、ユーザによって与えられるベクトル・スティミュラ
ス・ファイルが有効なマスタ・バス・トランザクション
を指定する。両方のタイプの入力スティミュラス・ファ
イルで、ユーザは試験環境がランダムに生成されるビヘ
イビアで以ってユーザが定義するスティミュラスをオー
バライドするかどうかを制御できる。スレーブ・テスト
ベンチの場合は、ランダム生成は待機ステータス、応
答、およびグラント・ステータス等をカバーできる。

【０１２０】受動モードでは、デバイスはシステムの一
部として試験される。すなわち、準拠性ツールはドライ
ブ機能を何も提供しないし、またデコーダ、アービタ、
マスタ、およびスレーブのような試験部品の動的生成を
サポートしない。ドライブすべきＤＵＴのためのサポー
ト用インフラストラクチャ全体を提供するのは試験者の
テストベンチである。このことは過去のＳｏＣ設計の準
拠性試験において、また初めて周辺機器を一緒に統合す
る場合に特に有用である。準拠性ツールのドライブ機能
が停止している状態では、プロトコル・チェックおよび
カバレッジ・ポイント収集機構は能動モードで使用され
たものと同じように働く。

【０１２１】好適な実施の形態では、バス・プロトコル
・エラーが発生せずに試験ランが完了したときは、ＤＵ
Ｔに関するカバレッジの詳細を表示するＧＵＩがロード
される。ここでカバレッジ・ホールを同定することがで
きるため、後続の試験ランで前に見逃したカバレッジ・
ポイントを満たすように、ＤＵＴをより明確な方向にド
ライブすることができる。このように準拠性を実現する
ことに成功した後で、元の指定されたデバイス機能が与
えられれば、バス・プロトコルに準拠することを認める
チェック・サムの準拠性証明が発行されよう。例えば、
もしマスタＤＵＴがインクリメント・バーストのみをサ
ポートすると指定されれば、それの準拠性証明はその事
実を明確に述べる。

【０１２２】本発明の特別な実施の形態についてここに
述べてきたが、本発明がそれらに限定されず、本発明の
範囲内で多くの修正および追加が可能であることは明ら
かであろう。例えば、本発明の範囲から外れることなし
に、クレームの従属項の特徴を独立項の特徴と組み合わ
せることができる。

【図面の簡単な説明】

【図１】ＡＲＭ社によって開発されたアドバンスト・マ
イクロコントローラ・バス・アーキテクチャ仕様に従っ
て動作するバスを介して相互接続されたデバイスを含む
システム・オン・チップを示すブロック図。

【図２】本発明の好適な実施の形態の能動モードに従う
試験手順を実行するときに用いられる論理要素を模式的
に示すブロック図。

【図３】スレーブ・デバイスを試験するときに、好適な
実施の形態の能動モードで用いられる論理要素の更に詳
細を示すブロック図。

【図４】マスタ・デバイスを試験するときに、好適な実
施の形態の能動モードで用いられる論理要素の更に詳細
を示すブロック図。

【図５】本発明の好適な実施の形態の受動モードに従っ
て試験を実行するときに用いられる論理要素を模式的に
示すブロック図。

【図６】本発明の好適な実施の形態に従って準拠性チェ
ックを実行するために実行される工程を示すフロー図。

【図７】被験デバイス用の準拠性試験環境を生成するプ
ロセスの詳細を示すブロック図。

【図８】本発明の好適な実施の形態に従ってプロトコル
・チェックを実行するときの時間シーケンスの評価を表
すために用いられるグラフ表記の例。

【図９】プロトコル・チェックを実行するときに、チェ
ックされるプロパティを表すタイミング図。

【図１０】好適な実施の形態の試験手順が実行されるデ
ータ処理システムを模式的に示すブロック図。

【符号の説明】

１０ ＳｏＣ １１０ システム・バス １１５ 外部バス １２０ アービタ １３０ 外部バス・インタフェース １４０ ＣＰＵ １４５ ＤＭＡコントローラ １５０ ＵＡＲＴ論理ユニット １５５ タイマ １６０ ＲＡＭ １６５ デコーダ論理 １７０ ブリッジ回路 １７５ クロック発生器 １８０ 赤外通信インタフェース １８５ ＵＳＢ １９５ ペリフェラル・バス ２００ ＳＤＬＣインタフェース ２０５ Ａ／Ｄコンバータ ２１０ Ｄ／Ａコンバータ ３００ テストベンチ ３０５ テスト・シーケンス・ファイル ３１０ カバレッジ・モニタ・コンポネント ３１５ コンフィギュレーション情報 ３２０ プロトコル・チェック・コンポネント ３３０ ＤＵＴ ３４０ バス ３５０ ＡＭＢＡ部品テストベンチ・コア ３５５ ＡＨＢ／ＡＰＢマスタ部品 ３６０ ユーザ・トリックボックス部品 ４００ マスタＤＵＴ ４１０ ＡＨＢ／ＡＰＢスレーブ部品 ４２０ メモリ初期化ファイル ５００ システム・シミュレーション環境 ５１０ ＤＵＴ ８００ プロセッサ・コア ８１０ ＲＯＭ ８２０ バス ８３０ ＲＡＭ ８４０ 入力／出力デバイス ８５０ ディスプレイ

Claims (18)

【特許請求の範囲】
1. 【請求項１】 デバイスのバス・プロトコル準拠性を試
   験する方法であって： （ａ）前記デバイスのタイプおよび前記デバイスの機能
   を規定する予め定められたパラメータを含むコンフィギ
   ュレーション・ファイルを読み込む工程； （ｂ）コンフィギュレーション・エンジンを採用して、
   前記コンフィギュレーション・ファイルに従って選ば
   れ、デバイス表現とバスを介して接続されて試験環境を
   形成するための試験部品を生成することによって前記デ
   バイスのための試験環境を動的に生成する工程； （ｃ）テスト・シーケンスを実行させる工程；および （ｄ）前記テスト・シーケンスの実行中に前記デバイス
   表現と１個以上の前記試験部品との間で受け渡される信
   号をモニタして、前記バス・プロトコルへの準拠性を示
   す結果のデータを作成する工程；を含む方法。
2. 【請求項２】 請求項１に記載の方法であって、前記コ
   ンフィギュレーション・ファイルがコンフィギュレーシ
   ョン・ファイルの１組のテンプレートから選ばれたもの
   であり、また前記組が各デバイス・タイプ毎に１つのコ
   ンフィギュレーション・ファイル・テンプレートを含ん
   でおり、また各コンフィギュレーション・ファイルには
   そのデバイスに特有のコンフィギュレーション情報を提
   供するための複数のエントリが含まれている方法。
3. 【請求項３】 請求項１に記載の方法であって、前記工
   程（ｄ）が、プロトコル・チェック・コンポネントを採
   用して、前記テスト・シーケンス実行中に前記デバイス
   表現と１個以上の前記試験部品との間で受け渡される信
   号が、前記バス・プロトコルの予め定められた規則の組
   のどれにも違反しないことをチェックする工程を含んで
   いる方法。
4. 【請求項４】 請求項１に記載の方法であって、前記工
   程（ｄ）が、カバレッジ・モニタ・コンポネントを採用
   して、前記テスト・シーケンス実行中に前記デバイス表
   現と１個以上の前記試験部品との間で受け渡される信号
   をモニタして、１組のカバレッジ・ポイントが観測され
   るかどうかを決定する工程を含んでいる方法。
5. 【請求項５】 請求項４に記載の方法であって、前記カ
   バレッジ・ポイントの組が前記工程（ａ）において読み
   込まれる前記コンフィギュレーション・ファイルに従っ
   てコンフィギュアされる方法。
6. 【請求項６】 請求項５に記載の方法であって、前記工
   程（ｄ）が、プロトコル・チェック・コンポネントを採
   用して、前記テスト・シーケンス実行中に前記デバイス
   表現と１個以上の前記試験部品との間で受け渡される信
   号が前記バス・プロトコルの予め定められた規則の組の
   どれにも違反しないことをチェックする工程を含んでお
   り、また前記バス・プロトコルの予め定められた規則の
   組に違反しないで前記組中のすべてのカバレッジ・ポイ
   ントが観測された場合には、前記方法が更に前記バス・
   プロトコル準拠性を確認する出力を生成する工程を含ん
   でいる方法。
7. 【請求項７】 請求項１に記載の方法であって、前記工
   程（ｂ）において、選ばれた試験部品を生成する前記工
   程が、試験すべきデバイスのタイプに依存して生成すべ
   き前記試験部品を選択する工程を含んでいる方法。
8. 【請求項８】 請求項７に記載の方法であって、少なく
   とも１個の試験部品が、それに付随してそれが呈する複
   数のビヘイビアを有しており、試験すべきデバイスのタ
   イプに依存して前記試験部品が生成されるときにビヘイ
   ビアの選択が決まるようになった方法。
9. 【請求項９】 請求項１に記載の方法であって、前記テ
   スト・シーケンスが、試験すべきデバイス用に開発され
   たユーザが定義可能なテスト・シーケンスである方法。
10. 【請求項１０】 請求項１に記載の方法であって、前記
    デバイス表現がインタフェース・モジュール内に生成さ
    れ、試験環境を生成する前記工程（ｂ）が、前記インタ
    フェース・モジュール内の信号を前記試験環境内の信号
    へ、前記コンフィギュレーション・ファイルに定義され
    たやり方に従ってマッピングする工程を含んでいる方
    法。
11. 【請求項１１】 請求項１０に記載の方法であって、前
    記コンフィギュレーション・ファイルが、前記信号のマ
    ッピングを容易にするために、前記インタフェース・モ
    ジュール内の前記デバイス表現の階層構造レベルを規定
    している方法。
12. 【請求項１２】 請求項１に記載の方法であって、更
    に：前記バス・プロトコルと互換性を有し、汎用の入力
    ／出力インタフェースを備えたトリックボックス・コン
    ポネントを提供する工程；を含む方法。
13. 【請求項１３】 請求項１に記載の方法であって、試験
    されるデバイスのタイプがマスタ、スレーブ、アービ
    タ、またはデコーダを含んでいる方法。
14. 【請求項１４】 請求項１に記載の方法であって、前記
    バス・プロトコルがＡＲＭ ＡＭＢＡバス・プロトコル
    であり、前記バスがシステム・バスとペリフェラル・バ
    スとを含んでおり、試験されるデバイスのタイプがシス
    テム・バス・マスタ、システム・バス・スレーブ、ペリ
    フェラル・バス・マスタ、ペリフェラル・バス・スレー
    ブ、アービタ、またはデコーダを含んでいる方法。
15. 【請求項１５】 請求項１に記載の方法であって、前記
    デバイス表現がレジスタ・トランスファ・ランゲージ
    （ＲＴＬ）表現である方法。
16. 【請求項１６】 請求項１に記載されたデバイスの準拠
    性を試験する方法を実行するように処理ユニットをコン
    フィギュアするように動作するコンピュータ・プログラ
    ム。
17. 【請求項１７】 請求項１６に記載のコンピュータ・プ
    ログラムを含む運搬媒体。
18. 【請求項１８】 デバイスのバス・プロトコル準拠性を
    試験するためのデータ処理システムであって：前記デバ
    イスのタイプおよび前記デバイスの機能を規定する予め
    定められたパラメータを含むコンフィギュレーション・
    ファイルを記憶するためのメモリ；および処理ユニット
    であって： （ｉ）バスを介してデバイス表現と接続されて試験環境
    を形成する、前記コンフィギュレーション・ファイルに
    従って選ばれた試験部品を生成することによって前記デ
    バイスのための試験環境を動的に生成する工程； （ii）テスト・シーケンスを実行する工程；および （iii）前記テスト・シーケンス実行中に前記デバイス
    表現と１個以上の試験部品との間で受け渡される信号を
    モニタして、前記バス・プロトコルとの準拠性を示す結
    果のデータを作成する工程；を実行するように構成され
    た処理ユニット；を含むデータ処理システム。