特表 2024-532660 自動試験機器、被試験デバイス、試験機器構成、確認応答信号を用いる方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-09-10

(54)【発明の名称】自動試験機器、被試験デバイス、試験機器構成、確認応答信号を用いる方法

(51)【国際特許分類】

   G01R 31/28 20060101AFI20240903BHJP

   G06F 11/22 20060101ALI20240903BHJP

【ＦＩ】

G01R31/28 H

G06F11/22 673A

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024502206

(86)(22)【出願日】2021-11-08

(85)【翻訳文提出日】2024-01-15

(86)【国際出願番号】 EP2021080989

(87)【国際公開番号】W WO2023078571

(87)【国際公開日】2023-05-11

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＴＨＵＮＤＥＲＢＯＬＴ

(71)【出願人】

【識別番号】390005175

【氏名又は名称】株式会社アドバンテスト

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(74)【代理人】

【識別番号】100109047

【弁理士】

【氏名又は名称】村田 雄祐

(74)【代理人】

【識別番号】100109081

【弁理士】

【氏名又は名称】三木 友由

(74)【代理人】

【識別番号】100133215

【弁理士】

【氏名又は名称】真家 大樹

(72)【発明者】

【氏名】ヒリゲス、クラウス・ダイエッター

(72)【発明者】

【氏名】バッカー、マルクス

(72)【発明者】

【氏名】シュルツェ・ヴェステンホルスト、マーカス

(72)【発明者】

【氏名】ポエッペ、オラフ

(72)【発明者】

【氏名】グロス、トーマス

【テーマコード（参考）】

2G132

5B048

【Ｆターム（参考）】

2G132AA00

2G132AB00

2G132AE11

2G132AE23

2G132AH07

2G132AL06

2G132AL07

2G132AL11

5B048DD03

(57)【要約】

【解決手段】一つ以上の被試験デバイスを試験するための自動試験機器は、一つ以上のテスタリソースの更新を要求するコマンドを、被試験デバイスまたはテスターケースから受信するよう構成される。自動試験機器は、被試験デバイスまたはテストケースによって提供されるコマンドに応答して、一つ以上のテスタリソースを更新するように構成される。自動試験機器は、被試験デバイスまたはテストケースに確認応答信号を提供し、被試験デバイスまたはテストケースによって要求されたテスタリソース更新の完了を通知するように構成される。被試験デバイス、方法およびコンピュータプログラムも記載される。
【選択図】図１

【特許請求の範囲】

【請求項1】

一つ以上の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）を試験する自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）であって、
前記自動試験機器は、前記被試験デバイスから、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の更新を要求するコマンドを受信するように構成され、
前記自動試験機器は、前記被試験デバイスによって提供されるコマンドに応答して、一つ以上のテスタリソースを更新するように構成される、
自動試験機器。

【請求項2】

前記自動試験機器は、確認応答信号を前記被試験デバイスに送信し、前記被試験デバイスによって要求されたテスタリソース更新の完了を通知するように構成される、
請求項１に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項3】

前記自動試験機器は、被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）から、パラメータ化されたメッセージの形式のコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を受信するように構成され、前記メッセージのパラメータは、テスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の所望の設定を記述する、
請求項１または２に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項4】

前記自動試験機器は、前記確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）をメッセージの形式で提供するように構成される、
請求項２または３に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項5】

前記自動試験機器は、高帯域幅インタフェースを介して、前記被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）からコマンドを受信するよう構成され、および／または、
前記自動試験機器は、高帯域幅インタフェースを介して、前記被試験デバイスに前記確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を提供するように構成される、
請求項２から４のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項6】

前記自動試験機器は、前記被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）上でのテストケース（７４０；８３２；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）の実行中に、前記被試験デバイスによって提供されるコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）に応答して、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）を更新するように構成される、
請求項１から５のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項7】

前記自動試験機器は、前記被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）上で実行されるテストケース（７４０；８３２；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）が使用するアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供するように構成され、
前記アプリケーション・プログラミング・インタフェースは、前記被試験デバイスから前記自動試験機器に、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の適合を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を送信するための一つ以上のルーチンを提供するように構成され、および／または、
前記アプリケーション・プログラミング・インタフェースは、前記被試験デバイスと前記自動試験機器との間の時間的同期のための一つ以上のルーチンを提供するように構成される、
請求項１から６のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項8】

前記自動試験機器は、オン・チップ・システム・テスト（ＯＣＳＴ）コントローラ（８２６；９３０；１３５２；１４５２；１７２６；１８２６）と、テストプログラム（７２４；８２４；１３２４；１４２４；１５２４；１６２４；１７２４；１８２４）を実行するテストプログラム実行器（７２２；８２２；１３２２；１４２２；１５２２；１６２２；１７２２；１８２２）と、一つ以上のテストリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）とを備え、
前記オン・チップ・システム・テストコントローラは、一つ以上のテスタリソースの更新を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を前記被試験デバイスから受信し、テストプログラムを実行する前記テストプログラム実行器にコマンドを転送するように構成され、
前記テストプログラムは、前記コマンドに応答して一つ以上のテスタリソースの更新を生じさせるように構成されるメッセージハンドラを備える、
請求項１から７のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項9】

前記メッセージハンドラは、テスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の記号参照を備えるコマンド（７５０；８６２；９５８；１７６０）を、テスタハードウェア関連のテスタリソース調整に変換するように構成される、
請求項８に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項10】

前記メッセージハンドラは、確認応答メッセージ（８６２；９６８；１７６２）を生成し、前記生成された確認応答メッセージを前記オン・チップ・システム・テストコントローラ（８２６；９３０；１３５２；１４５２；１７２６）に提供するように構成され、
前記オンチップ・システム・テストコントローラは、前記メッセージハンドラによって提供された前記確認応答メッセージを前記被試験デバイスに転送するか、または前記メッセージハンドラによって提供された前記確認応答メッセージに応答して確認応答メッセージを前記被試験デバイスに提供するように構成される、
請求項８または９に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項11】

前記自動試験機器は、テストプログラム（７２４；８２４；１３２４；１４２４；１５２４；１６２４；１７２４；１８２４）を実行するように構成され、
前記テストプログラムは、前記自動試験機器のテストリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）を初期化し、前記被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）上でのプログラム実行の開始を可能にするよう構成され、
前記テストプログラムは、前記被試験デバイスの制御下で前記テストリソースのさらなる更新を生じさせるように構成される、
請求項１から１０のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項12】

前記自動試験機器は、オン・チップ・システム・テストコントローラ（８２６；９３０；１３５２；１４５２；１７２６）を備え、
前記自動試験機器は、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）を備え、
前記オン・チップ・システム・テストコントローラは、前記一つ以上のテスタリソースに結合され、
前記オン・チップ・システム・テストコントローラは、前記被試験デバイスからのコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）に応答して一つ以上のテスタリソースを更新するために、前記一つ以上のテスタリソースに制御信号を提供するように構成される、
請求項２から１１のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項13】

前記オン・チップ・システム・テストコントローラ（８２６；９３０；１３５２；１４５２；１７２６）は、テスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の記号参照を備えるコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）をテスタハードウェア関連のテスタリソース調整に変換するように構成される、
請求項１２に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項14】

前記オン・チップ・システム・テストコントローラ（８２６；９３０；１３５２；１４５２；１７２６）は、データバス（１８８０）を介して、および同期ラインまたは同期バス（１８８０）を介して、前記一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）に結合され、
前記オン・チップ・システム・テストコントローラは、前記データバスを介して、前記被試験デバイスから受信した前記コマンドのメッセージパラメータに依存して、選択されたテスタリソースの新しい設定を準備するように構成され、
前記オン・チップ・システム・テストコントローラは、前記同期ラインを介して、または前記同期バスを介して、前記選択されたテスタリソースの前記準備された新しい設定をアクティブ化するように構成される、
請求項１２または１３に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項15】

前記オン・チップ・システム・テストコントローラ（８２６；９３０；１３５２；１４５２；１７２６）は、前記被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）に前記確認応答信号（１２４；８５２；９７０；１７５２；１８５２）を提供するように構成される、
請求項１２から１４のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）。

【請求項16】

被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）であって、
前記被試験デバイスは、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の更新を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）に提供するように構成される、
被試験デバイス。

【請求項17】

前記被試験デバイスは、前記被試験デバイスによって要求されたテスタリソース更新の完了を示す確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）が前記被試験デバイスによって受信されるまで、テストケース（７４０；８４０；９４０；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）の実行を一時停止するように構成される、
請求項１６に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）。

【請求項18】

前記被試験デバイスは、システムオンチップであり、
前記被試験デバイスは、テストケース（７４０；８４０；９４０；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）を実行するように構成され、
前記被試験デバイスは、前記テストケースの制御下で前記自動試験機器に前記コマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を提供するように構成される、
請求項１６または１７に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）。

【請求項19】

前記被試験デバイスは、パラメータ化されたメッセージの形式で前記コマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を提供するように構成され、前記メッセージのパラメータは、テスタリソースの所望の設定を記述する、
請求項１６から１８のいずれか一項に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）。

【請求項20】

前記被試験デバイスは、前記確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）をメッセージの形式で受信するように構成される、
請求項１７から１９のいずれか一項に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）。

【請求項21】

前記被試験デバイスは、高帯域幅インタフェースを介して、前記自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）に前記コマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を提供するように構成され、および／または、
前記被試験デバイスは、高帯域幅インタフェースを介して、前記確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を受信するように構成される、
請求項１７から２０のいずれか一項に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）。

【請求項22】

前記被試験デバイスは、前記コマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を提供するために、および／または前記確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を評価するために、一つ以上のライブラリルーチンを使用するように構成される、
請求項１７から２１のいずれか一項に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）。

【請求項23】

試験機器構成（７００；８００；１３００；１４００；１５００；１６００；１７００；１８００）であって、
前記試験機器構成は、請求項１から１５のいずれか一項に記載の自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）と、請求項１６から２２のいずれか一項に記載の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）とを備える、
試験機器構成。

【請求項24】

自動試験機器を動作させる方法であって、
前記方法は、
一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の更新を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）から受信することと、
前記被試験デバイスによって提供される前記コマンドに応答して、一つ以上のテスタリソースを更新することと、を含む、
方法。

【請求項25】

前記方法は、
確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を前記被試験デバイスに提供し、前記被試験デバイスによって要求されるテスタリソース更新の完了を通知することを含む、
請求項２４に記載の方法。

【請求項26】

被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）を試験する方法であって、
前記方法は、
一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の更新を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を、被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）から自動試験機器に、前記被試験デバイス上で実行されるテストケース（７４０；８４０；９４０；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）の制御下で提供することと、
前記被試験デバイスによって提供される前記コマンドに応答して一つ以上のテスタリソースを更新することと、
前記被試験デバイスによって前記確認応答信号が検出されると、前記テストケースの実行を継続することと、を含む、
方法。

【請求項27】

請求項２２に記載の自動試験機器を動作させる方法であって、
前記方法は、
前記被試験デバイスによって要求されたテスタリソース更新の完了を示す確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）が前記被試験デバイスによって受信されるまで、前記テストケースの実行を一時停止することと、
確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を前記被試験デバイスに提供し、前記被試験デバイスによって要求されたテスタリソース更新の完了を通知することと、を含む、
方法。

【請求項28】

コンピュータプログラムがプロセッサ上で実行されたときに請求項２４から２７のいずれか一項に記載の方法を実行する、コンピュータプログラム。

【請求項29】

一つ以上の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）を試験する自動試験機器（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）であって、
前記自動試験機器は、テストケース（７４０；８４０；９４０；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）から、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の更新を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を受信するように構成され、
前記自動試験機器は、前記テストケースによって提供される前記コマンドに応答して一つ以上のテスタリソースを更新するように構成される、
自動試験機器。

【請求項30】

一つ以上の被試験デバイス（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）を試験する自動試験機器（１１０；７３０；８３０；１３３０；１４３０；１５３０；１６３０；１７３０；１８３０）であって、
前記自動試験機器は、前記テストケースに確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を提供し、前記テストケースによって要求されたテスタリソース更新の完了を通知するように構成される、
請求項２９に記載の自動試験機器。

【請求項31】

自動試験機器（１００；７１０；８１０；１３１０；１４１０；１５１０；１６１０；１７１０；１８１０）を動作させる方法であって、
前記方法は、
テストケース（７４０；８４０；９４０；１３４０；１４４０；１５４０；１６４０；１７４０；１８４０）から、一つ以上のテスタリソース（７２０；８２０；９１０；１３２０；１４２０；１５２０；１６２０；１７２０；１８２０）の更新を要求するコマンド（１２２；７５０；８５０；９５４；１７５０；１８５０）を受信することと、
前記テストケースによって提供される前記コマンドに応答して一つ以上のテスタリソースを更新することと、を含む、
方法。

【請求項32】

前記方法は、
前記テストケースに確認応答信号（１２４；７５２；８５２；９７０；１７５２；１８５２）を提供し、前記テストケースによって要求されたテスタリソース更新の完了を通知することを含む、
請求項３１に記載の方法。

【請求項33】

コンピュータプログラムがプロセッサ上で実行されたときに請求項３２に記載の方法を実行する、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明に係る実施の形態は、一つ以上の被試験デバイスを試験する自動試験機器に関する。

【0002】

本発明に係る別の実施の形態は、被試験デバイスに関する。

【0003】

本発明に係る別の実施の形態は、試験機器構成に関する。

【0004】

本発明に係る別の実施の形態は、自動試験機器を動作させる方法に関する。

【0005】

本発明に係る別の実施の形態は、被試験デバイスを試験する方法に関する。

【0006】

本発明に係る別の実施の形態は、コンピュータプログラムに関する。

【0007】

一般的に言えば、本発明に係る実施の形態は、オン・チップ・システム・テストによる生産テスタ制御に関する。

【背景技術】

【0008】

自動試験機器（ＡＴＥ）は、高速な自動化されたテストケースの実行と、被試験デバイス（ＤＵＴ）の外部テスト条件の柔軟な制御とを有する製造試験およびポストシリコン検証のためのプラットフォームである。

【0009】

デジタル集積回路の製造試験は、従来ＡＴＥ上で構造試験によって行われてきた。サイクル精度入力パターンを被試験デバイス（ＤＵＴ）に適用し、得られた出力パターンを予想パターンと比較することにより、故障デバイスが検出される。

【0010】

ＤＵＴの内部構造は、ネットワークオンチップファブリックによって相互接続されるマルチプロセッサ、メモリ、およびペリフェラルユニットを有する多数のサブシステムを含む複雑なシステムオンチップ（ＳｏＣ）デバイスに移行しつつある。構造試験で９９．５％のカバレッジを実現したとしても、これらのＳＯＣでは数百万個の未試験トランジスタが存在することになり、これがオンチップシステムテスト（ＯＣＳＴ）の導入につながった。

【0011】

ＯＣＳＴは、ＤＵＴのプロセッサ環境上で組込みソフトウェアによってリアルタイムシナリオとして実行され、ＳｏＣの全てのサブシステムを含む重要なユースケースの機能性能チェックによってテストギャップを埋める。

【0012】

テストパターン別にＯＣＳＴ／機能テストをアップロードする従来手法

【0013】

以下では、パターンテストによってＯＣＳＴ／機能テストをアップロードする従来手法について説明する。

【0014】

図４は、機能テストケース（ＴＣ）のソフトウェア（ＳＷ）を被試験デバイス（ＤＵＴ）のメモリにアップロードするＡＴＥシステム上の一般的な手法を示す。ＳＷは、ＤＵＴ上のメモリインタフェースに適用されるサイクル精度パターンのシーケンスによってアップロードされる。欠点は、ＳＷコードからパターンシーケンスへの変換に時間がかかること、デジタルチャネルの最大クロックレートによってダウンロード速度が制限されることである。

【0015】

結論として、図４は、テストパターンによるＯＣＳＴ／機能テストのアップロードおよび制御を示す。例えば、自動試験機器４１０は、ＡＴＥテストプログラム４２４を実行するワークステーション４２２と結合されるテスタリソース４２０を備えてもよい。例えば、テスタリソースの一部でありうるデジタルチャネルは、パターンに基づくＯＣＳＴアップロードおよびデジタルチャネルを介した制御のために使用されうる。言い換えれば、デジタルチャネルは、例えば、テストプログラム（例えば、ＯＣＳＴテストケース４３２）を被試験デバイス４３０にアップロードするために使用されうる。この目的のために、ＡＴＥのデジタルチャネルは、被試験デバイスへの（例えばＯＣＳＴテストケースの）プログラムのアップロードを制御するパターンを提供するようにプログラムされうる。さらに、例えばデジタルチャネル、および／またはアナログチャネル、および／または供給ラインなどの追加のテスタリソースは、例えば入力信号および／または一つ以上の供給電圧などの被試験デバイスのための信号を提供するために使用されうる。さらに、テスタリソース４２０は、被試験デバイス４３０から一つ以上の信号を受信し、被試験デバイスからこれらの信号を評価するためにも使用されうる。例えば、適切な供給電圧が被試験デバイスに供給され、それぞれのテスタリソースを用いて自動試験機器と被試験デバイスとの間で相互作用があってもよい。さらに、テスタリソースは、任意選択で、測定を実行して被試験デバイスを評価するために使用されてもよい。

【0016】

結論として、ＯＣＳＴテストケースのアップロードは、適切なテスタリソースを使用して自動試験機器によって実行されてよく、自動試験機器のテスタリソースを使用して、自動試験機器と被試験デバイスとの間で相互作用があってもよい。

【0017】

高速ＩＯによるＯＣＳＴ／機能テストアップロードおよび制御

【0018】

以下では、高速ＩＯによるＯＣＳＴ／機能テストアップロードおよび制御について説明する。

【0019】

機能テストケースの取り扱いの進歩は、被試験デバイス（ＤＵＴ）のＨＳＩＯインタフェース（ＵＳＢ、ＰＣＩｅ、ＥＴＨなど）をネイティブモードで使用することである。これは、例えば、テストケースのソフトウェア（ＳＷ）がアップロードされ、例えば、完全にプロトコルでサポートされた高速インタフェースによって制御されることを意味し、もはやサイクル指向の決定性パターンではないことを意味する。ＨＳＩＯインタフェースをサポートするためには、ドライバを被試験デバイス（ＤＵＴ）にあらかじめインストールし、例えばＪＴＡＧによってアップロードおよびアクティブ化しておく必要があるかもしれない。

【0020】

図５は、高速ＩＯによる機能テストアップロードおよび制御の概略図を示す。この概念では、例えば、テスタリソース５２０とワークステーション５２２を備える自動試験機器５１０があってもよい。さらに、被試験デバイス５３０がある。例えば、ＡＴＥテストプログラムは、ＯＣＳＴ－ＴＣアップロード（例えば、オンチップシステムテスト・テストケースのアップロード）を生じさせてもよい。さらに、テストプログラムは、実行制御を行ってもよい。例えば、ＯＣＳＴ－ＴＣアップロードおよび実行制御の双方は、例えばユニバーサル・シリアル・バス・インタフェース、「ペリフェラル・コンポーネント・インターコネクト・エクスプレス（ＰＣＩｅ）」インタフェース、またはイーサネット・インタフェース（ＥＴＨ）のような高速入出力（ＨＳＩＯ）を使用して実行されてもよい。このように、典型的なプロトコルベースの高速入出力インタフェースは、テストケースＴＣのアップロードおよびテストケースの実行制御に使用されてもよい。この点に関して、ＯＣＳＴテストケース５３２は典型的にはソフトウェアであり、被試験デバイス５４０を使用して（または被試験デバイス５４０上で）（例えば、被試験デバイス５３０の一つ以上のプロセッサを使用して）実行されることに留意されたい。

【0021】

さらに、被試験デバイス５３０は、テスタリソース５２０と接続されてもよく、例えば、デジタルチャネルおよび／またはアナログチャネルおよび／または供給ラインが使用されてもよい。例えば、ＤＵＴへの供給、試験相互作用および測定のためのＡＴＥ制御信号が使用されてもよい。言い換えれば、テスタリソースは、例えば、一つ以上のデバイス電源を備えてもよく、これは、例えば、被試験デバイスに一つ以上の電源電圧を供給してもよい。さらに、テスタリソースは、例えば、被試験デバイスにデジタル信号を提供し、および／または被試験デバイスからデジタル信号を受信する一つ以上のデジタルチャネルを備えてもよい。例えば、自動試験機器５１０は、被試験デバイス５３０との相互作用のために一位以上のデジタルチャネルを使用してもよく、自動試験機器５１０は、任意選択で、デジタルチャネルを使用して測定を行ってもよい。さらに、テスタリソース５２０は、例えば、被試験デバイス５３０に一つ以上のアナログ信号を提供するため、および／または被試験デバイス５３０から一つ以上のアナログ信号を受信するために使用されうる一つ以上のアナログチャネルを備えてもよい。さらに、一つ以上のアナログチャネルは、任意選択で、例えば被試験デバイス５３０から受信した信号を評価するために、測定するために使用されてもよい。

【0022】

結論として、高速ＩＯによるＯＣＳＴ／機能テストアップロードおよび制御が図５を参照して説明された。

【0023】

図６は、ＯＣＳＴ／機能テストに別個のコントローラを使用することによる変形例の概略図を示す。

【0024】

図６の構成６００は、自動試験機器６１０であり、テスタリソース６２０およびワークステーション６２２を備える。さらに、図６による試験構成６００には、ＯＣＳＴテストケース６３２が実行されうる被試験デバイス６３０もある。

【0025】

しかしながら、図５による試験構成５００に加えて、図６による試験構成６００は、例えば自動試験機器６１０の一部でありうるオン・チップ・システム・テストコントローラ６４０を備える。オン・チップ・システム・テストコントローラ６４０は、例えば、高速入出力インタフェースＨＳＩＯ（例えば、ＵＳＢ、ＰＣＩｅまたはＥＴＨ）を使用して、ワークステーション６２２に結合されてもよい。例えば、ワークステーション６２２上で実行されるＡＴＥテストプログラム６２４は、インタフェースを介して（例えば、ＨＳＩＯインタフェースを介して）ＯＣＳＴコントローラ６４０と通信し、ＯＣＳＴ－ＴＣアップロードおよび／または実行制御を開始、サポートまたは制御してもよい。例えば、ＡＴＥテストプログラムは、ＯＣＳＴテストケース（ＴＣ）の表現をＯＣＳＴコントローラ６４０に提供し、例えば、当該ＯＣＳＴテストケースを被試験デバイス６４０にアップロードするようにＯＣＳＴコントローラ６４０に指令してもよい。その後、ＯＣＳＴコントローラ６４０は、例えば、ＯＣＳＴテストケースの被試験デバイス６３０へのアップロードを実行してもよい。さらに、ＡＴＥテストプログラム６２４は、ＯＣＳＴコントローラと（例えばＨＳＩＯインタフェースを介して）通信し、テストケースの実行を制御してもよい。例えば、ＡＴＥテストプログラム６２４とＯＣＳＴコントローラ６４０との間の通信は、（例えば双方向矢印で示されるように）双方向であってもよい。さらに、ＯＣＳＴコントローラ６４０は、被試験デバイス６３０上で実行されるＯＣＳＴテストケース６３２と通信し、テストケースの実行を制御するように構成されてもよい。例えば、ＯＣＳＴコントローラ６４０とＯＣＳＴテストケース６３２との間の通信は、（例えば双方向矢印で示されるように）双方向であってもよい。

【0026】

さらに、テスタリソース６２０の機能は、上述した試験構成５００内のテスタリソース５２０の機能と同様であってもよい。言い換えれば、テスタリソース６２０は、例えば、一つ以上のデバイス電源と、一つ以上のデジタルチャネルおよび／またはアナログチャネルとを備えてもよい。したがって、テスタリソース６２０は、ＤＵＴへの供給のために、および試験相互作用および測定のためにＡＴＥ制御信号を提供するように適合されてもよい。

【0027】

したがって、被試験デバイスは、試験構成６００で試験されてもよい。結論として、図６は、ＯＳＣＴ／機能テストのための別個のコントローラを使用することによる変形例を示す。

【0028】

さらに、このセクションで説明される特徴、機能および詳細はいずれも、（本発明に係る実施の形態と矛盾しない限り）本発明に係る実施の形態で任意選択で使用されてもよいことに留意されたい。このような特徴、機能および詳細は、本発明に係る任意の実施の形態に、個別にまたは組み合わせて導入されてもよいことに留意されたい。

【0029】

しかしながら、従来手法を考慮すると、オン・チップ・システム・テストの機能性、オン・チップ・システム・テストのテスト開発工数および実装工数のトレードオフの改善を提供する、被試験デバイスを試験するための概念が望まれる。

【発明の概要】

【課題を解決するための手段】

【0030】

本発明に係る一実施の形態は、一つ以上の被試験デバイスを試験するための自動試験機器を生成する。自動試験機器は、被試験デバイスから（すなわち、テストケースから）、一つ以上のテスタリソースの更新を要求するコマンドを（例えば、メッセージ形式で）受信するように構成される。さらに、自動試験機器は、被試験デバイス(すなわち、テストケース)によって提供されるコマンドに応答して、一つ以上のテスタリソースを更新するように構成され、自動試験機器は、確認応答信号（または、アクノリッジメント信号）（例えば確認応答メッセージ）を被試験デバイスに送信し、被試験デバイスによって要求されたテスタリソース更新の完了を通知する。

【0031】

本発明のこの実施の形態は、そのような概念を使用すると、テストケースの開発およびテストケースの実行が大幅に容易になるという発見に基づく。例えば、このような概念を使用すると、（自動試験機器で実行されうる）ＡＴＥテストプログラムを特別に適合させる必要性なしに、テストケースの実行を自動試験機器の動作と簡単に同期させることができる。例えば、被試験デバイス上で実行されるテストケースは、一つ以上のテスタリソースの更新を要求するコマンドを提供するようにプログラムでき、被試験デバイス上で実行されるテストケースはアクノレッジ信号を評価することもできる。しかしながら、確認応答信号は、一つ以上のテスタリソースの更新を要求するコマンドに対する「標準化された」応答であるかもしれないため、ＡＴＥによるコマンドの評価は「標準化された」プロセスであってもよく（例えば、異なるテストケースで同じであるかもしれない）、自動試験機器による確認応答信号の提供は、被試験デバイスで現在実行されているテストケースに対する自動試験機器（または、ＡＴＥで実行されるＡＴＥテストプログラム）の特別な適合を必要としないかもしれない。したがって、一つ以上のテスタリソースの更新を要求するコマンドを、被試験デバイス上で実行されるテストケースに発行する指令を追加するときに、ＡＴＥテストプログラムに特別な適合を行う必要がないかもしれない。その結果、一つ以上のテストリソースの適合（または更新）がテストケースの完全な制御下にあるため、テスト開発が大幅に容易になる（例えば、ＡＴＥおよびＡＴＥ上で実行されるテストプログラムは単に、テストケースによって提供されるコマンドを実行する「スレーブ」として機能する）。

【0032】

さらに、確認応答信号を提供することで、自動試験機器は、被試験デバイスがテスタリソースの更新と同期して動作することを可能にする。その結果、一つ以上のテストリソースの更新を要求するコマンドと、テスタリソースの更新の実際の完了との間の遅延（これは通常、被試験デバイスにとって未知であり、場合によっては非決定的でありうる）は、被試験デバイスによって容易に対処されることができる。このように、自動試験機器によってアクノレッジ信号を提供し、被試験デバイスによって要求されたテスタリソースの更新の完了を通知することは、自動試験機器の機能性に関する詳細な知識を有することなく、自動試験機器のテストプログラムのコードを修正することなく、被試験デバイス上で実行される信頼性の高いテストケースを検証エンジニアが設計することを可能にする。その結果、ここで説明される自動試験機器は、テストケースを一元的な設計を可能にし、また、被試験デバイス上でのテストケースを確実かつ迅速な実行を可能にする（例えば、テスタリソースの更新を待つために不必要な予防的遅延を追加する必要がなく、代わりに確認応答信号を使用する）。

【0033】

好ましい実施の形態において、自動試験機器は、被試験デバイスから（すなわち、テストケースから）、パラメータ化されたメッセージの形式のコマンドを受信するように構成され、メッセージのパラメータは、テスタリソースの所望の設定（例えば、所望の電源電圧、所望のクロック周波数、所望の信号特性など）を記述する。

【0034】

予め定義された構文を有し、テスタリソースの所望の設定を記述する一つ以上のパラメータを備えるメッセージを評価する機能を自動試験機器に提供することにより、ＡＴＥテストプログラムを特定の被試験デバイスの試験に特別に適合させる必要がなくなりうる。むしろ、ＡＴＥテストプログラムが「標準化された」パラメータ化されたメッセージ（例えば、所定の構文に従って、例えば、変更されるべきテスタリソースと所望の新しい設定を指定するパラメータ化されたメッセージ）を扱う機能を提供すれば十分である一方、被試験デバイス上で実行されるテストケースを設計する検証エンジニアは、自動試験機器（例えば、自動試験機器のＡＴＥテストプログラム）によって取り扱うことのできるコマンドの構文を知っていればよく、あるいは、コマンドを生成するＡＰＩ関数の構文を知っていればよい。このように、自動試験機器においてパラメータ化されたメッセージを取り扱う機能が提供されることにより、テスト開発が大幅に容易になり、ＡＴＥ試験プログラムを特定の被試験デバイスの試験に特別に適合させる必要がなくなる。さらに、検証エンジニアは、被試験デバイス上で実行されるテストケースを、テストリソースの所望の設定を変更するために迅速かつ効率的に適合させることもできる。

【0035】

好ましい実施の形態において、自動試験機器は、確認応答信号をメッセージの形式で提供するように構成される。メッセージ（例えば、メッセージヘッダ、コマンドを識別する一つ以上のビット、パラメータを識別する一つ以上のビット、オプションのエラー訂正情報、およびオプションのメッセージターミネータを含む、予め定義されたフォーマットを有するメッセージ）の送信は、自動試験機器と被試験デバイスとの間のインタフェースを介して効率的に行うことができることが判明している。例えば、このようなメッセージの伝送は、自動試験機器と被試験デバイスとの間の高速インタフェースおよび（またはＨＳＩＯインタフェース）を介して効率的に行うことができる。さらに、例えば特定のインタフェース種類に適したメッセージ形式によるメッセージの送信は、特定のインタフェース種類に適合したインタフェースドライバを使用して効率的に実行できることが判明している。したがって、特定の（例えば高速）インタフェースは、例えば、パラメータ化されたメッセージの送信と確認応答信号の送信の双方に使用でき、また、自動試験機器と被試験デバイス装置との間の他のデータ交換にも使用できる。このように、異なる種類のメッセージの伝送のために特定のインタフェースを共有できるため、専用の信号線（例えば確認応答信号用）が不要になる。

【0036】

さらに、パラメータ化されたメッセージ形式のコマンドおよびメッセージ形式の確認応答信号の双方を使用するという概念は、インタフェースドライバや非決定性タイミング動作を有するインタフェースによって取り扱われうる（例えばパラメータ化された）メッセージを使用することが可能であるように、タイミング要件を緩和することに留意されたい。例えば、テスト実行を進める前に確認応答信号を待つ機会を被試験デバイスに与えることで、（コマンドメッセージおよび確認応答信号メッセージの双方の）メッセージ送信におけるわずかな遅延は、被試験デバイス上でのテストケースの実行に大きな影響を与えず、特に、テストケースの実行と一つ以上のテストリソースの所望の更新との間の同期を危険にさらすことがない。

【0037】

好ましい実施の形態において、自動試験機器は、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、高速インタフェースを介して、例えば、ＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）、被試験デバイスからコマンドを受信するよう構成される。代替的または追加的に、自動試験機器は、確認応答信号（例えば、確認応答メッセージ）を、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、高速インタフェースを介して、例えば、ＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）、被試験デバイスに提供するよう構成される。被試験デバイスから自動試験機器へのコマンドの送信および／または自動試験機器から被試験デバイスへの確認信号の送信に、このような高帯域幅インタフェースを使用することにより、遅延を適度に小さく抑えることができ、当該インタフェースを流用することもできる。例えば、上述の高速インタフェースは、被試験デバイスへのオンチップシステム試験ソフトウェアのアップロードおよび／または被試験デバイスから自動試験機器への結果データのダウンロードに流用できる。しかしながら、テストケースの実行中、当該高帯域幅インタフェースは、通常、被試験デバイスから自動試験機器へのコマンドの送信および自動試験機器から被試験デバイスへの確認応答信号の送信に利用可能な十分な帯域幅を有しうることが判明している。当該インタフェースは、典型的にほとんどの場合、オン・チップ・システム・テストの開始前およびオン・チップ・システム・テストの完了後（例えば試験結果の送信用）にロードされることが判明している。したがって、高速インタフェースは、オン・チップ・システムのテストにおいて他の目的にも典型的に使用され、自動試験機器側と被試験デバイス側の双方で高速インタフェース用のドライバが使用可能であるため、コマンドの送信および確認応答信号の送信に適しています。さらに、高速（または高帯域幅）インタフェースの種類によっては、タイムスロットの予約さえ可能であるため、被試験デバイスから自動試験機器へのコマンドの転送および／または自動試験機器から被試験デバイス装置への確認応答信号の転送を、ほぼリアルタイム（または、ほぼ時間決定性）で行うことができる。さらに、上述の高帯域幅インタフェースは、利用可能な帯域幅が広いため、予約されたタイムスロットがない場合でも、典型的にほぼリアルタイムに近い伝送を提供する。

【0038】

好ましい実施の形態において、自動試験機器は、被試験デバイス（例えば、システムオンチップ）上でのテストケースの実行中に、被試験デバイスによる（すなわち、テストケースによる）コマンドに応答して（例えば、被試験デバイス上で実行されるテストケースの制御下で）、一つ以上のテスタリソースを更新するように構成される。しかしながら、被試験デバイス上でのテストケースの実行中に一つ以上のテスタリソースを更新することは、本発明の手法を用いて大きな問題なく可能であることが判明している。例えば、テストケースは、一つ以上のテストリソースの更新を要求するコマンドを発行し、その後、一つ以上のテスタリソースの更新に影響を受けないテストケースルーチンの実行を継続（その後、確認応答信号の受信をチェック）してもよいし、または確認応答信号の受信を待つために一時停止してもよい。このため、自動試験機器は、確認応答信号の提供を除いて、テスタリソースの更新を完了するために、被試験デバイスに追加の制御信号を提供する必要がない。例えば、リソース更新前にテストケースの実行を中断するために、またはリソース更新後にテストケースの実行を開始するために、自動試験機器が明示的な信号または制御信号を提供することを回避できる。その結果、自動試験機器によるテストケースの実行の明示的な制御によって生じるであろう遅延は、自動試験機器から被試験デバイスに確認応答信号を提供することによって回避できる。特に、リソースの更新中もテストケースの実行を継続できるため、貴重なテスト時間を短縮できる。また、確認応答信号の待機は、ＤＵＴ上で実行されるテストケースの制御下で行うことができるため、ＤＵＴ上で実行中のテストケースの実行を中断する必要がない。

【0039】

好ましい実施の形態において、自動試験機器は、被試験デバイス上で実行されるテストケースが使用するためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供するように構成される。アプリケーション・プログラミング・インタフェースは、被試験デバイス（すなわち、テストケース）から自動試験機器に一つ以上のテスタリソースの適合（または更新）を要求するコマンドを送信するための一つ以上のルーチン（例えば、メソッドまたは関数）を提供するように構成される。代替的または追加的に、アプリケーション・プログラミング・インタフェースは、被試験デバイスと自動試験機器との間の時間的同期のための一つ以上のルーチン（例えば、メソッドまたは関数）（例えば、テスタリソース更新の完了を示す信号を受信するまで（例えば、被試験デバイス上で実行されるテストケースの）プログラム実行を一時停止するための一つ以上のルーチン）を提供するように構成される。

【0040】

テストケースによる使用のためにアプリケーション・プログラミングインタ・フェースを提供することにより、自動試験機器装置は、テストケースの開発を有意にサポートできる。被試験デバイスから自動試験機器への一つ以上のテスタリソースの適合（または更新）を要求するコマンドを送信するための一つ以上のルーチンを提供することにより、検証エンジニアが自動試験機器の内部やコマンドの構文に関する詳細を知る必要がない。むしろ、検証エンジニアは、一つ以上のルーチンをアプリケーション・プログラミング・インタフェースからテストプログラムに（例えば、ＤＵＴ上で実行されるテストケースに）追加するだけで十分であり、これは、ルーチンが十分に文書化されている場合には通常簡単である。また、アプリケーション・プログラミング・インタフェースは、テストプログラム開発が実際のテスタハードウェアから、または自動試験機器上のソフトウェアの改訂から実質的に独立しているような方法で、設計されることもある。その結果、検証エンジニアは非常に効率的なツールを手に入れることができ、一つ以上のテスタリソースが更新されるテストケースの開発は非常に簡単であり、自動試験機器上で実行されるテストプログラムの詳細を扱う必要がない。また、被試験デバイスと自動試験機器との間の時間的同期のための一つ以上のルーチンを提供する場合も同様である。このようなルーチンは、検証エンジニアが自動試験機器の内部やＡＴＥ試験プログラムに関する詳細な知識を持つことを必要とせずに、検証エンジニアが（被試験デバイス上で実行される）テストケースに容易に含めることができる。このように、適切なＡＴＥを提供することにより、テストケースとテスタリソースの更新との間の同期を簡単な方法で生じさせてもよく、テストプログラムの開発は、実際のテスタハードウェアおよび／またはＡＴＥソフトウェアのソフトウェアリビジョンから独立することさえもできる。これは、エラーリスクの低減と高い移植性を有する効率的なソフトウェア開発を可能にする。

【0041】

好ましい実施の形態において、自動試験機器は、オン・チップ・システム・テスト（ＯＣＳＴ）コントローラと、テストプログラムを実行するテストプログラム実行器と、一つ以上のテストリソース（例えば、一つ以上のデバイス電源、および／または一つ以上のアナログまたはデジタル信号発生器）とを備える。オン・チップ・システム・テスト・コントローラは、一つ以上のテスタ・リソースの更新を要求するコマンドを（例えば、メッセージの形態で）被試験デバイスから（すなわち、テストケースから）（例えば、高帯域幅インタフェースを介して）受信し、テストプログラムを実行するテストプログラム実行器にコマンド（例えば、メッセージ）を転送するように構成される。さらに、テストプログラムは、（転送された）コマンド（例えば、転送されたメッセージの形式）に応答して、例えば、転送されたメッセージを（例えば、転送されたメッセージに含まれる一つ以上のパラメータに依存して）解読および／または解釈した後に、一つ以上のテスタリソースの更新を生じさせる（例えば、実行する）ように構成されるメッセージハンドラを備える。

【0042】

このような概念を用いると、テスタリソース（本書でテストリソースと呼ぶこともある）を制御するための基本的な機能をテストプログラム実行器に実装することが可能である一方、オン・チップ・システム・テストのための具体的なサポートがオン・チップ・システム・テストコントローラによって提供される。例えば、テストプログラム実行器は、テストプログラムによって定義される方法で（テストプログラムは、例えば、被試験デバイスから受信したテスタリソースの更新のためのコマンドの扱いを定義する）、テスタリソースに対する制御を実行しうる。したがって、自動試験機器の基本的な機能は、ＡＴＥテストプログラムによって定義されることができ、これにより現在のテストシナリオに十分に適合した方法で自動試験機器を構成できる。一方、オン・チップ・システム・テスト・コントローラは、オン・チップ・システム・テストに関連する特定の機能を、テストプログラム実行器よりも効率的な方法で提供しうる。例えば、オン・チップ・システム・テストコントローラは、オン・チップ・システム・テストに関連する高速インタフェース機能を（例えば、専用のハードウェアサポートを使用して）効率的に実装しうる。例えば、オン・チップ・システム・テスト・コントローラは、被試験デバイスとの通信に適した、システムオンチップであってもよい高速入出力インタフェースのハードウェア実装を備えてもよい。被試験デバイスとの通信のための効率的な（おそらくハードウェアでサポートされる）実装を有することにより、オン・チップ・システム・テスト・コントローラは、テストプログラム実行器に対する要件を緩和し、例えば、被試験デバイスとの通信のための通信プロトコルの処理を引き受けてもよい。さらに、オン・チップ・システム・テストコントローラは、一つ以上の被試験デバイスへのテストケースのアップロード、および／または一つ以上の被試験デバイスからの試験結果のダウンロード、および／または試験結果の評価などのオン・チップ・システム・テストに必要な追加機能をサポートしてもよい。例えば、オン・チップ・システム・テストコントローラは、従来のテスタリソースでは一般的に扱うことが困難な、被試験デバイスとの任意のプロトコルに基づくデータ交換を有意にサポートしてもよい。

【0043】

さらに、オン・チップ・システム・テストコントローラは、被試験デバイスから一つ以上の試験リソースの更新を要求するコマンドを受信するのに適してもよく、特に、テストプログラム実行器に比べてオン・チップ・システム・テストコントローラによってより良好に扱うことができるインタフェース技術および／または通信プロトコルを使用してそのようなコマンドが送信される場合に適している。したがって、テスタリソースの更新を要求するコマンドの受信にオン・チップ・システム・テストコントローラの性能を利用することにより、当該コマンドの送信に広帯域通信を適用でき、プロトコルに基づく高速通信の実装が困難な他のテスタリソースの使用を回避できる。オンチップ・システム・テスト・コントローラは、例えば、高速通信プロトコルからコマンドを抽出し、そのコマンドを（例えば、元の形式または変換された形式で）テストプログラム実行器に転送することができ、ここで、オン・チップ・システム・テストコントローラは、通常、高データレートＡＴＥ内部インタフェースによってテストプログラム実行器とリンクされうることに留意されたい。したがって、「従来」のテスタリソースおよびテストプログラム実行器は、被試験デバイスから高速通信を受信するという典型的に非常に難しいタスクを引き受ける必要はなく、強力な仲介役としてオン・チップ・システム・テストコントローラに依存する。さらに、テストプログラム実行器は、通常わずかな労力でオン・チップ・システム・テストコントローラからの通信を受信でき、テストプログラム実行器上で実行されるテストプログラムは、ＡＴＥテストプログラムによって柔軟に構成可能な方法で、この転送されたコマンドを評価しうる。言い換えれば、オン・チップ・システム・テストコントローラは、転送インスタンスとして機能してもよく、被試験デバイスとの通信のためのプロトコルの取り扱いを引き受けてもよく、テストプログラム実行器は、ＡＴＥテストプログラムの制御下で実際のテスタリソースを制御してもよく、当該ＡＴＥテストプログラムは、順に、オン・チップ・システム・テストコントローラによって転送されたコマンドを評価し、そのコマンドを自動試験機器のテスタリソースを構成するためのテスタ内部（例えば、ハードウェア関連）のコマンドに変換してもよい。その結果、自動試験機器内で非常に効率的なタスクの共有を達成でき、リソース効率の高い方法でコマンドを扱うことが可能になる。

【0044】

好ましい実施の形態において、メッセージハンドラは、テスタリソースの（例えば、電源電圧のまたは信号の）記号参照（例えば、「ＶＣＣ２」）を備えるコマンド（例えば、メッセージ）を、テスタハードウェア関連のテスタリソース調整に（例えば、自動試験機器の（物理的な）リソースチャネルを所望の値に設定する命令に）変換するように構成される。

【0045】

このような概念を使用することにより、被試験デバイス上で実行されるテストケースによって生成されるコマンドは、自動試験機器の特定のハードウェアを認識する必要がなく、試験リソースを制御するためのＡＴＥ内部のコマンドも認識する必要がない。むしろ、被試験デバイス上で実行されるテストケースは、検証エンジニアにとって理解しやすい記号参照に依存できる。さらに、これらの記号参照からテスタハードウェア関連の制御コマンドへの変換は、構成可能な方法でメッセージハンドラによってもたらされるため、記号参照と物理的なテスタリソースとの関連付けは、例えば、テスタプログラム実行器によって実行されるＡＴＥテストプログラム内で定義されてよい。その結果、実際の物理的なテスタリソース構成が異なるテスタは、ＡＴＥテストプログラムの１回限りの適合によって、特定の記号参照を使用して所定のテストケースを適切に取り扱うために、所与のテストケースとともに使用するために適合されることができる。その結果、実際の物理的なテスタハードウェアが変更されても、テストケースを書き直す必要はなく、修正する必要さえない。その結果、ＡＴＥのテストプログラム実行器によって実行されるＡＴＥテストプログラムは、物理的な抽象化メカニズムを構成し、異なる自動試験機器上での被試験デバイスの試験を有意に円滑化する。

【0046】

好ましい実施の形態において、メッセージハンドラは、確認応答メッセージを生成し、生成された確認応答メッセージを（例えば、被試験デバイスによって要求された一つ以上のテスタリソースの更新の完了後に）オン・チップ・システム・テストコントローラに提供するように構成される。さらに、オンチップ・システム・テスト・コントローラは、メッセージハンドラによって提供された確認応答メッセージを被試験デバイスに転送するか、またはメッセージハンドラによって提供された確認応答メッセージに応答して確認応答メッセージを被試験デバイスに提供するように構成される。

【0047】

このような概念を使用することにより、確認応答メッセージは、通常テスタリソースに非常に近い物理的アクセスを持ち、テスタリソースの更新がいつ完了したかを確実に判断できるテストプログラム実行器で生成できる。したがって、メッセージハンドラは、確認応答メッセージを生成するのに最適である一方、オン・チップ・システム・テストコントローラは確認応答メッセージの転送に最適であることが判明しており、この確認応答メッセージの転送は、例えば、被試験デバイスとの通信のためのプロトコル処理を備えてもよい。その結果、メッセージハンドラとオン・チップ・システム・テストコントローラとの間の典型的に高速な通信と、オン・チップ・システム・テストコントローラによって有効化される（または最適にサポートされる）被試験デバイスに向けた高速通信とを使用できる。このように、利用可能なリソースを効率的に使用して、確認応答メッセージの送信のための高速メカニズムを実装できる。

【0048】

好ましい実施の形態において、自動試験機器は、テストプログラムを実行するように構成され、テストプログラムは、自動試験機器のテストリソースを初期化し、被試験デバイス上でのテストプログラム実行の開始を可能にするように構成される。さらに、テストプログラムは、被試験デバイスの制御下で（例えば、被試験デバイス上で実行される一つ以上のオン・チップ・システム・テスト・テストケースの制御下で）テストリソースのさらなる更新を生じさせるように構成される。したがって、ＡＴＥテストプログラムと被試験デバイス上で実行されるテストケースとの間でタスクの共有を達成できる。被試験デバイスの信頼性の高い起動に最適となる起動条件は、例えば、被試験デバイス上でテストケースが実行されていないタイミングに、ＡＴＥテストプログラムによって引き起こされる可能性がある。その後、被試験デバイスの制御下でのテスタリソースの更新によって引き起こされる様々なテスト条件に、例えばテストケースの上位の制御下で到達することができる。したがって、例えば、限界条件下での被試験デバイスのテストを生じさせるかもしれない困難なテストは、テストケースによって制御されうる。このような概念は、テスト開発を特に簡単かつ信頼できるものすることが判明している。

【0049】

好ましい実施の形態において、自動試験機器は、オン・チップ・システム・テストコントローラを備える。自動試験機器は、一つ以上のテスタリソース（例えば、一つ以上のデバイス電源、および／または一つ以上のアナログまたはデジタル信号発生器）を備える。オン・チップ・システム・テストコントローラは、一つ以上のテスタリソースに結合される（例えば、直接結合される、例えば、テストプログラム実行器をバイパスする方法で結合される）。さらに、オン・チップ・システム・テストコントローラは、被試験デバイスから（すなわち、テストケースから）のコマンドに応答して一つ以上のテスタリソースを更新するために、一つ以上のテスタリソースに制御信号を（例えば、データバスを介して、および／または一つ以上の同期化ラインを介して、および／または同期化バスを介して）提供するように構成される。

【0050】

このような概念を用いると、被試験デバイスからのコマンドに応答して一つ以上のテスタリソースを非常に高速に更新することが可能となる。例えば、オン・チップ・システム・テストコントローラは、高速インタフェース（例えば、ＨＳＩＯ）を使用して、被試験デバイスと非常に高速に通信するように適合させうる。オン・チップ・システム・テストコントローラは、高速インタフェースのプロトコルを扱うように構成されてもよく、これにより、オン・チップ・システム・テストコントローラと被試験デバイスとの間でわずかな労力で高速通信が可能になる。このように、オン・チップ・システム・テストコントローラは、被試験デバイスから一つ以上のテスタリソースの更新を要求するコマンドを受信するのに十分に適合する。さらに、一つ以上のテスタリソースの直接制御を可能にするインタフェースを提供することによって、例えば自動試験機器を制御するテストプログラム実行器やワークステーションが関与することなく、オン・チップ・システム・テストコントローラは、被試験デバイスによって（例えば高速インタフェースを介して）発行されたコマンドに応答して、一つ以上のテスタリソースの更新を非常に迅速に生じさせることができる。例えば、オン・チップ・システム・テストコントローラは、一つ以上のテスタリソースの構成（または再構成）を可能にするインタフェース（例えば、データバス）への直接アクセスを提供してもよい。したがって、被試験デバイスからのコマンドに応答した一つ以上のテスタリソースの更新のレイテンシ（遅延時間）は、例えば一つ以上のテスタリソースの更新にテストプログラム実行器も関与する他の解決方法に比べて、短縮されることができる。

【0051】

好ましい実施の形態において、オン・チップ・システム・テストコントローラは、テスタリソースの（例えば、電源電圧のまたは信号の）記号参照（例えば、「ＶＣＣ２」）備えるコマンド（例えば、メッセージ）を、テスタハードウェア関連のテスタリソース調整に（例えば、自動試験機器の（物理的な）リソースチャネルを所望の値に設定する命令に）変換するように構成される。

【0052】

このような記号参照からテスタハードウェア関連のテスタリソース調整への変換を使用することにより、テストプログラムの開発が検証エンジニアにとって大幅に容易になる。例えば、テストケースを設計する検証エンジニアは、記号参照を参照するだけでよく、自動試験機器の具体的な物理的構成を意識する必要はない。さらに、テストケースは、異なる構成の自動試験機器上で（例えば、変更なしで）実行可能でありうる。このように、コマンドの変換を使用する概念は、テスト開発およびテスト実行にとって非常に大きな利点を有する。さらに、テストプログラム実行器におけるコマンド変換に関する上記説明も参照されたい。

【0053】

好ましい実施の形態において、オン・チップ・システム・テストコントローラは、データバスを介して、および同期ラインまたは同期バスを介して、一つ以上のテスタリソースに結合される。オン・チップ・システム・テストコントローラは、選択されたテスタリソース（例えば、その出力電圧が変更されるデバイス電源）の新しい設定（例えば、新しい電圧）を、データバスを介して、被試験デバイスから（すなわち、テストケースから）受信したコマンドのメッセージパラメータ（例えば、新しい電圧を定義するメッセージパラメータ）に依存して、（例えば選択されたテスタリソースの今後の特性を定義するために）準備（例えば、初期化）するように構成される。さらに、オン・チップ・システム・テストコントローラは、同期ラインを介して、または同期バスを介して（例えば、同期バスイベントまたは同期バスメッセージを使用して）、選択されたテスタリソースの準備された新しい設定をアクティブ化するように構成される。このような概念を使用すると、オン・チップ・システム・テストコントローラは、テストリソースの更新が実際に準備されるときに非常に正確な情報を取得できる。被試験デバイスから受信したコマンドのメッセージパラメータに依存して、データバスを介して所望の新しい設定を通信することは、テストリソースの更新が実際に行われる時点を正確に決定できないかもしれない一方で、通常、同期ラインのアクティブ化または同期バスを介したデータ送信と、テスタリソースが実際に更新される時点との間のタイミング関係は、極めて良く予測可能である。したがって、確認応答メッセージは、「念のため」の不必要な遅延を追加する必要なく、オン・チップ・システム・テストコントローラによって高い信頼性で生成されることができる。したがって、このような概念は、高速なテストの実行を可能にし、テストのコストの削減に役立つ。

【0054】

好ましい実施の形態において、オン・チップ・システム・テストコントローラは、被試験デバイスに確認応答信号を（例えば、確認応答メッセージの形式で）を提供するように構成される。したがって、被試験デバイス上でのテストケースの実行との同期を確保でき、オン・チップ・システム・テストコントローラから被試験デバイスへの通信は、通常、高速インタフェースを効率的に使用するためのオン・チップ・システム・テストコントローラの能力の観点でにおいて特に高速である。

【0055】

本発明に係る実施の形態は、被試験デバイスを生成する。被試験デバイスは、（例えば、被試験デバイス上で実行されるテストケースの制御下で）一つ以上のテスタリソースの更新を要求するコマンドを（メッセージの形式で）自動試験機器に提供するように構成される。さらに、被試験デバイスは、被試験デバイスによって要求されたテスタリソース更新の完了を示す確認応答信号（例えば、確認応答メッセージ）が被試験デバイスによって受信されるまで、テストケースの実行を一時停止するように構成される。

【0056】

この被試験デバイスは、特に効率的なテストの実行を可能にする。被試験デバイス（または被試験デバイス上で実行されるテストケース）は、被試験デバイスの試験環境（例えば、被試験デバイスに供給する一つ以上の電源電圧の設定、および／または被試験デバイスの一つ以上のクロック周波数、および／または自動試験機器によって被試験デバイスに提供される入力信号の特性）を制御できる。また、被試験デバイスによって要求されたテストリソース更新の完了を示す確認応答信号が被試験デバイスによって受信されるまでテストケースの実行を一時停止することにより、被試験デバイス上で実行されるテストケースと一つ以上のテスタリソースの更新との間のタイミング同期を実現できる。例えば、被試験デバイスは、確認応答信号が受信されるまで、一つ以上のテスタリソースの更新を必要とするテストプログラムステップの実行を待機することができ、テストケースが適切な期待された試験環境で常に実行されることの確保に役立つ。また、確認応答信号を使用することにより、「安全側にある」不必要な遅延を回避できる。その結果、テストケースは、高速かつ非常に高い信頼性で実行できる（例えば、予防的に大きな固定遅延を使用するのではなく、確認応答信号を受信したときにテストケースの実行を直ちに継続することによって）。さらに、このようなテストケースの開発は、試験環境の変更が被試験デバイス上で実行されるテストケースに含まれる各コマンドによって引き起こされ、自動試験機器上で実行されるテストプログラムの適合の必要がないため、通常検証エンジニアにとって非常に簡単である。したがって、ＤＵＴ上で実行されるテストケースの開発およびデバッグの両方は、単純かつ堅実である。

【0057】

好ましい実施の形態において、被試験デバイスはシステム・オン・チップである。被試験デバイスは、テストケース（例えば、被試験デバイスを試験するための試験手順を実行するプログラム）を実行するように構成される。さらに、被試験デバイスは、テストケースの制御下で修正されたテスト機器にコマンドを提供するように構成される。したがって、テストケースは、一つ以上のテスタリソースの更新（例えば、パラメータ変更）を要求することができ、このようなテスタリソースの更新の完了を示す信号を評価することができるため、試験環境の調整を非常に信頼性高く制御できる。

【0058】

したがって、テストケース自体は、試験環境（例えば、被試験デバイスの供給電圧、または自動試験機器によって被試験デバイスに提供される一つ以上の信号の物理パラメータ）を制御できる。これは、実質的にテストケースの（上位）制御下にある極めて完璧なテストを可能にし、テストケースを設計する検証エンジニアによってテストケースを効率的にテストを定義できる。

【0059】

好ましい実施の形態では、被試験デバイスは、パラメータ化されたメッセージの形式でコマンドを提供するように構成され、メッセージのパラメータは、テスタリソースの所望の設定（例えば、所望の供給電圧、所望のクロック周波数、所望の信号特性など）を記述する。パラメータ化されたメッセージの形式でのコマンドの使用は、自動試験機器に特定の要件を伝達することが検証エンジニアにとって簡単になることが判明している。さらに、パラメータ化されたコマンドは通常、テストケースの基礎となるプログラムコードの可読性を非常に良くすることが判明している。さらに、パラメータ化されたメッセージの形式でコマンドを使用することによって提供される上述の利点に対する参照もなされる。

【0060】

好ましい実施の形態において、被試験デバイスは、メッセージの形式で確認応答信号を受信するように構成される。一つ以上の高速インタフェースを備える被試験デバイスは、通常、メッセージを取り扱いできる通信インタフェースドライバを備えているため、メッセージの受信に適することが判明している（このようなメッセージは、例えば、メッセージヘッダ、メッセージデータ、オプションのエラー修正情報、およびオプションのメッセージターミネータを備えてもよい）。さらに、メッセージの取り扱いは、通常、被試験デバイス上で実行されるソフトウェアによって、例えば被試験デバイス上で実行されるオペレーティングシステムによってサポートされるか、またはメッセージの受信を待機するループを使用することによって可能であることが判明している。また、メッセージの評価は、通常、有限状態機械を使用して簡単に行うことができ、これは、ほどほどの労力でＤＵＴに実装できる。

【0061】

好ましい実施の形態において、被試験デバイスは、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、ＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）、自動試験機器へのコマンド（例えば自動試験機器へのメッセージ）を提供するように構成される。代替的または追加的に、被試験デバイスは、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、高速インタフェースを介して、例えば、ＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）、確認応答信号（例えば、確認応答メッセージ）を（例えば自動試験機器から）受信するように構成される。

【0062】

このような高速インタフェース（または高帯域幅インタフェース）の使用は、これらのインタフェースの一つ以上をオンチップで備えうる、これらのインタフェースの一つ以上のドライバを備えうる多くの被試験デバイスに適することが判明している。例えば、当該インタフェースは、例えば、自動試験機器から被試験デバイスへのテストケースのアップロード用、および／または被試験デバイスから自動試験機器への試験結果のダウンロード用、および／またはインタフェース自体のテスト用といった、オンチップシステムテスト中の複数の目的に流用されてもよい。したがって、高速インタフェースは、自動試験機器へのコマンドの送信用、および自動試験機器からの確認応答信号の受信用に容易に使用可能であり、このような高速インタフェースの使用は、低遅延を可能にする。

【0063】

好ましい実施の形態において、被試験デバイスは、コマンドを提供するために、および／または確認応答信号を評価するために、（例えば、自動試験機器によって提供されるソフトウェアライブラリの）一つ以上のライブラリルーチンを使用するように構成される（その使用は、例えば、自動試験機器によって提供されるアプリケーション・プログラミング・インタフェースによって可能であってもよい）。被試験デバイスによるライブラリルーチンの使用は、コマンドの提供および／または確認応答信号の評価を容易にし、検証エンジニアが適切なテストプログラムを開発することを容易にする。例えば、ライブラリルーチンは、自動試験機器の製造業者によって提供されてもよく、したがって自動試験機器に十分に適合してもよい。例えば、テストケースを設計する検証エンジニアは、自動試験機器の内部についての、および／またはメッセージの送信用または確認応答信号の送信用のプロトコルについての詳細な知識を有する必要はない。むしろ、デバイス上で実行されるテストケースを設計する検証エンジニアは、例えば、自動試験機器によって（例えば、自動試験機器ソフトウェアの一部として）提供されるアプリケーション・プログラミング・インタフェースを単に利用するだけでよいかもしれない。したがって、検証エンジニアは、堅実かつ快適にテストプログラムを開発できる。

【0064】

本発明に係る一実施の形態は、試験機器構成（テストセットアップ）を生成する。試験機器構成は、上記で概説した自動試験機器と、上記で概説した被試験デバイスとを備える。この試験機器構成は、上述の自動試験機器および被試験デバイスと同様の考察に基づく。

【0065】

本発明に係る別の実施の形態は、自動試験機器を動作させる方法を生成する。この方法は、一つ以上のテスタリソースの更新を要求するコマンドを（例えば、メッセージの形式で）被試験デバイスから（すなわち、テストケースから）受信することを備える。さらに、この方法は、被試験デバイスによって（すなわち、テストケースから）提供されるコマンドに応答して、一つ以上のテスタリソースを更新することを備える。さらに、この方法は、確認応答信号（例えば、確認応答メッセージ）を被試験デバイスに提供し、被試験デバイスによって要求されたテスタリソース更新の完了を通知することを備える。この方法は、上述の自動試験機器と同じ考察に基づく。さらに、この方法は、自動試験機器に関しても、本書で議論した任意の特徴、機能および詳細によって任意選択で補足されることができる。この方法は、任意選択で、そのような特徴、機能および詳細によって、個別にまたは組み合わせて補足されることができる。

【0066】

本発明に係る別の実施の形態は、被試験デバイスを試験するための方法を生成する。この方法は、（例えば被試験デバイスで事項されるテストケースの制御下で）一つ以上のテスタリソースの更新を要求するコマンドを（例えばメッセージの形式で）、被試験デバイスから（すなわち、テストケースから）自動試験機器へ、被試験デバイス上で実行されるテストケースの制御下で提供することを備える。この方法は、被試験デバイスによって要求されたテスタリソース更新の完了を示す確認応答信号（例えば、確認応答メッセージ）が被試験デバイスによって受信される（および、例えばテストケースによって検出される）まで、テストケースの実行を（例えばテストケースの制御下で）一時停止することを備える。さらに、この方法は、被試験デバイスによって（すなわち、テストケースによって）提供されるコマンドに応答して、一つ以上のテストリソースを更新することを備える。また、この方法は、被試験デバイスへ確認応答信号（例えば、確認応答メッセージ）を提供し、被試験デバイスによって要求されたテスタリソース更新の完了を通知することを備えてもよい。さらに、この方法は、被試験デバイスによって確認応答信号が検出されると、テストケースの実行を継続することを備える。

【0067】

この方法は、上記で議論した自動試験機器および上記で議論した被試験デバイスの間の相互作用を実装する。したがって、この方法は、自動試験機器に関して、および被試験デバイスに関して議論したものと同じ考察に基づき、同じ利点を備える。さらに、この方法は、自動試験機器に関して、および被試験デバイスに関して本書で議論された任意の特徴、機能および詳細によって、任意選択で、個別にまたは組み合わせて補足されることができる。

【0068】

本発明に係る別の実施の形態は、ここで議論される方法を実行するためのコンピュータプログラムを生成する。

【0069】

本発明に係るさらに別の実施の形態は、一つ以上のデバイスをテスト上で試験するための自動試験機器を生成する。自動試験機器は、一つ以上のテストリソースの更新を要求するコマンドを（例えば、メッセージの形式で）テストケースから受信するように構成される。自動試験機器は、テストケースによって提供されるコマンドに応答して、一つ以上のテストリソースを更新するように構成される。さらに、自動試験機器は、確認応答信号（例えば、確認応答メッセージ）をテストケースに提供し、テストケースによって要求されたテスタリソース更新の完了を通知するように構成される。この自動試験機器は、前述の自動試験機器と同様の考察に基づく。しかしながら、自動試験機器は、たいていの場合、テストケースからコマンドを受信するように構成され、テストケースは通常、被試験デバイス上で実行される（ただし、分散方式で実行されてもよく、例えば、自動試験機器と被試験デバイスの間で分散されてもよい）。さらに、自動試験は、任意選択で、本書で議論され、また被試験デバイスからコマンドを受信する自動試験機器に関して議論される任意の特徴、機能および詳細によって補足されてもよいことに留意されたい。例えば、テストケースからのコマンド受信は、被試験バイスからのコマンドの受信に置き換えられてもよい。自動試験機器は、そのような特徴、機能および詳細を、個別にまたは組み合わせて補足されてもよい（この場合、必要に応じて、テストケースがＤＵＴを置き換えてもよい）。

【0070】

本発明に係る別の実施の形態は、自動試験機器を動作させる方法を生成する。この方法は、一つ以上のテストリソースの更新を要求するコマンドを（例えば、メッセージの形式で）テストケースから受信することを備える。この方法は、テストケースによって提供されるコマンドに応答して、一つ以上のテストリソースを更新することを備える。さらに、この方法は、テストケースに確認応答信号（例えば確認応答メッセージ）を提供し、テストケースによって要求されたテスタリソース更新の完了を通知するステップを備える。この方法は、前述の自動試験機器を動作させる方法と同じ考察に基づき、コマンドはテストケースによって提供される。この方法は、任意選択で、本書で議論され、また対応する自動試験機器装置に関して議論される任意の特徴、機能および詳細によって補足されてもよい。この方法は、そのような機能によって、個別にまたは組み合わせて補足されてもよい（この場合、必要に応じて、テストケースがＤＵＴを置き換えてもよい）。

【0071】

さらに、本発明に係る実施の形態は、それぞれのコンピュータプログラムも生成する。

【0072】

本発明に係る一実施の形態は、被試験デバイスを試験するための自動試験機器を生成する。自動試験機器は、被試験デバイスによって（すなわち、例えば被試験デバイス上で実行されうるテストケースによって）制御可能なトリガライン（例えば、ハードウェアトリガライン、例えばＧＰＯトリガライン）を備える。自動試験機器は、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行されうるテストケースによる）トリガラインのアクティブ化に応答して、一つ以上のテスタリソース（本書ではテストリソースとも呼ばれる）を更新する（例えば、自動試験機器によって被試験デバイスに提供される一つ以上の供給電圧を変更する、または自動試験機器によって被試験デバイスに提供される一つ以上のアナログまたはデジタル信号の一つ以上の信号特性を変更する）ように構成される。

【0073】

本発明に係るこの実施の形態は、一つ以上のテスタリソースの更新を被試験デバイスがトリガできるようにするトリガラインを自動試験機器において提供することによって、被試験デバイス（これは、例えばシステム・オン・チップであってもよい）の制御下の高いタイミング精度で試験が実行されうるという着想に基づく。したがって、被試験デバイスは、少ない労力であるが高いタイミング精度で試験環境に影響を与えることが可能である。例えば、一つ以上のテスタリソースの更新をトリガするトリガラインへのアクセスを被試験デバイスに提供することにより、本発明の自動試験機器は、デバイスがコマンドを送信する必要なく、例えばプロトコルベースのインタフェースを使用して、自動試験機器の（より正確には一つ以上のテストリソースの）設定を変更する可能性を被試験デバイスに提供する。したがって、被試験デバイスは、単一の出力ピン（たとえば、汎用出力ピン、または任意の他の出力ピン）または単一の入出力ピンの単純なアクティブ化（または非アクティブ化）によって一つ以上のテスタリソースの更新を生じさせ（またはトリガし）てもよく、これは通常、非常に少ない労力かつ非常に高いタイミング精度で可能である。

【0074】

例えば、このような概念を使用すると、システム・オン・チップでありうる被試験デバイスは、出力（または、より正確には、単一の出力ピンまたは単一の入出力ピン）をアクティブまたは非アクティブにして、（例えば、当該出力ピンまたは入力／出力ピンのエッジによって）一つ以上のテストリソースの更新をトリガするための単一の機械命令（または非常に少ない数の機械命令）のみを必要としてもよい。このような出力のアクティブ化（または非アクティブ化）は、トリガラインと結合されてもよく、非常に短い時間内で可能であってもよく、例えば、複雑なドライバや通信プロトコルの使用を必要としなくてもよい。プロトコルベースの高速インタフェースを動作させるために必要でありうるドライバによって生じる可能性のある遅延またはタイミングの非決定性は、この方法で回避（またはバイパス）されてもよい。

【0075】

さらに、トリガラインの単なるアクティブ化（例えばトリガラインの立ち上がりまたは立ち下がりエッジ）は通常、自動試験機器側での複雑なプロトコル処理やコマンド変換を必要としないため、自動試験機器における追加の遅延も、上述のトリガラインの使用によって回避されてよく、労力と遅延の双方を回避できる。むしろ、専用のトリガラインでありうるトリガラインは、テストリソースに直接的に作用してもよく、それによって遅延と構成の複雑性の両方を最小化してもよい。したがって、当該トリガライン上の単純な立ち下がりまたは立ち上がりエッジは、テスタリソースの更新を生じさせてもよい。

【0076】

結論として、被試験デバイスに上記トリガラインへのアクセスを提供することは、反応時間、実装の労力、および使いやすさの間で非常に優れた妥協点を与える。

【0077】

好ましい実施の形態において、自動試験機器は、トリガラインのアクティブ化（例えば、トリガライン上の単純なエッジまたは遷移）によって一つ以上のテストリソースの更新を直接的にトリガし、テストプログラムを実行するテストプログラム実行器（例えば、ＡＴＥテストプログラムを実行する自動試験機器のテストプログラム実行器）をバイパスするように構成される。テストプログラム実行器をバイパスすることにより、不要な遅延を回避でき、ＡＴＥ電源、アナログチャネルモジュール、またはデジタルチャネルモジュールなどのテスタリソースを被試験デバイスによって直接的にトリガできる。さらに、ＡＴＥテストプログラムの実行も、トリガラインのアクティブ化によって中断されないため、テストプログラム実行器はその動作（例えば、被試験デバイスによって提供される結果データの評価など）を中断されない方法で実行してもよく、これはテスト時間の短縮に役立つ。また、データの損失につながる可能性のあるテストプログラム実行器の動作の中断（例えば、テストプログラム実行器が被試験デバイスからの結果データを取得に責任を負う場合）も回避できる。

【0078】

好ましい実施の形態において、自動試験機器は、一つ以上のテスタリソース（例えば、一つ以上のデバイス電源、および／または一つ以上のデジタル信号モジュールもしくは信号源、および／または一つ以上のアナログ信号モジュールもしくは信号源、および／または一つ以上の混合信号モジュール）を備える。さらに、一つ以上のテスタリソース（テストリソースとも呼ばれる）は、インタフェースを介してテストプログラム実行器に結合され、テストプログラムの制御下の（例えば、自動試験機器のテストプログラム実行器によって実行されるＡＴＥテストプログラムの制御下の）一つ以上のテストリソースの一つ以上の特性（例えば供給電圧、例えばデジタルパターン、例えばデジタル波形など）のプログラミングが可能になる。さらに、一つ以上のテスタリソースは、被試験デバイス（すなわち、例えば被試験デバイス上で実行されうるテストケース）によって制御可能なトリガラインに結合される。さらに、一つ以上のテスタリソースは、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行されうるテストケースによる）トリガラインのアクティブ化に応答して、テストプログラムの制御下で事前プログラムされた方法で（例えば、ある値に）信号特性を更新するように構成される。

【0079】

この概念において、テストプログラム実行器は、一つ以上のテスタリソースが設定される実際のパラメータの制御を維持する。したがって、テストプログラム実行器と被試験デバイスとの間で責任が分担されてもよく、テストプログラム実行器は、一つ以上のテストリソースの特性をプログラミングする責任を負い、一つ以上のテスタリソースの設定を事前プログラミングする責任も負い、これは、トリガ信号のアクティブ化に応答して引き受けるべきである一方、被試験デバイスは、トリガ信号を（例えば、ＤＵＴで実行されるテストケースによって決定される）適切な時間にアクティブ化するだけでよい。したがって、被試験デバイス（通常、システム・オン・チップなどのインテリジェントな被試験デバイスである）は、機能の小さな部分（一つ以上のテスタリソースの信号特性をテストプログラム実行器によって事前プログラムされた値に更新することをトリガする）を引き受けるだけで済み、被試験デバイスと自動試験機器との間の非常に簡単な通信を可能にする（トリガ信号を提供する被試験デバイスの単一の出力のアクティブ化または非アクティブ化のみが必要である）。一方で、自動試験機器のテストプログラム実行器は通常、被試験デバイスに必要な一つ以上のテストリソースの更新に関する知識を備えており、被試験デバイス上でのテストケースの実行とのいくつかのタイミング調整も行うことが望ましいであろう。しかしながら、自動試験機器のテストプログラム実行器と被試験デバイス上でのテストケースの実行との間のこのような「粗い」タイミング同期は、テストプログラム実行器が通常テストケースの被試験デバイスへのアップロードを制御し、また被試験デバイスと通信して被試験デバイスから試験結果情報を受信するために、普通なされる。したがって、テストプログラム実行器は、通常、被試験デバイスの状態を認識しており、その結果、一つ以上テストリソースのどの更新が被試験デバイスによって次に必要とされるかについての知識も有しているため、テストプログラム実行器は、一つ以上のテスタリソースを容易に事前にプログラムすることができ、一つ以上のテストリソースのうちの一つ以上のパラメータのどの更新が被試験でバスによるトリガラインの次のアクティブ化に応答して行われるべきかを容易に事前にプログラムすることができる。したがって、非常に高いタイミング精度を提供しながら、被試験デバイスと自動試験機器との間の通信が容易になるため、本書で言及した概念が非常に効率的であることは明らかである。

【0080】

好ましい実施の形態において、自動試験機器は、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行され得るテストケースによる）トリガラインのアクティブ化に対する一つ以上のテスタリソースの応答（例えば、新しいパラメータ値に対する信号特性の変更）を予め定義するために、一つ以上のテスタリソースを事前プログラムするように構成されるテストプログラム実行器を備える。ＡＴＥテストプログラムの制御下で被試験デバイスによるトリガラインのアクティブ化に対する一つ以上のテスタリソースの応答を予め定義することにより、被試験デバイスと自動試験機器との間の通信を非常に単純にすることができ、その結果、被試験デバイスによるトリガ信号の単なるアクティブ化は一つ以上のテスタリソースの十分に定義された応答を引き起こすのに十分であり、当該応答はテストプログラム実行器によって（例えば、ＡＴＥテストプログラムの制御下で）予め定義される。

【0081】

好ましい実施の形態において、自動試験機器（例えば、自動試験機器のテストプログラム実行器）は、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行されうるテストケースによる）トリガラインのアクティブ化に対する一つ以上のテスタリソースの応答（例えば、新しいパラメータ値に対する信号特性の変更）を予め定義するために、テストプログラムにおいて（例えば、ＡＴＥのテストプログラム実行器によって実行されるＡＴＥテストプログラムにおいて）提供される一つ以上の命令（例えば、事前プログラミングのための所望のパラメータを定義する命令）にしたがって一つ以上のテスタリソースを事前プログラミングするように構成される。テストプログラム（例えば、ＡＴＥテストプログラム）において提供される命令を使用して一つ以上のテスタリソースの事前プログラミングを定義することにより、一つ以上のテスタリソースの適切な更新は、ＡＴＥ側のテストプログラムの適切な開発によってプログラム可能な方法で準備されることができる（これは、いずれにしても被試験デバイスにおけるテストケースの実行と少なくとも粗く時間的に同期されるべきである）。一方、被試験デバイスから自動試験機器へのテスタリソース更新のためのパラメータ通信は不要である（かつ省略可能である）。

【0082】

好ましい実施の形態において、自動試験機器（例えば、自動試験機器のテストプログラム実行器）は、被試験デバイスから（すなわち、例えば被試験デバイス上で実行されうるテストケースから）、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義する（例えばメッセージ形式の）コマンドを受信するように構成される（ここで、当該更新は、例えばパラメータを定義するコマンドによってトリガされるのではなく、トリガラインの（その後の）アクティブ化によってトリガされる）。さらに、自動試験機器（例えば、自動試験機器のテストプログラム実行器）は、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行されうるテストケースによる）トリガラインのアクティブ化に対する一つ以上のテスタリソースの応答（例えば、新しいパラメータ値に対する信号特性の変更）を予め定義するために、被試験デバイスから（すなわち、例えば被試験デバイス上で実行されうるテストケースから）受信したコマンドにしたがって（例えば、更新用の一つ以上のパラメータを定義するコマンドにしたがって）一つ以上のテスタリソースを事前プログラミングするよう構成される。

【0083】

このような概念を用いることにより、被試験デバイス自体は、一つ以上のテスタリソースの一つ以上のパラメータのうちのどの更新が次に要求されるかを自動試験機器に通知してもよい。しかしながら、一つ以上のテスタリソースの更新の実際の時間は、（上述したように）非常に時間的に正確な方法で行うことができる被試験デバイスによるトリガラインのアクティブ化によって決定されるため、被試験デバイスから自動試験機器へのこの通知は、例えば、緩和した時間要件下で実行されてもよい。このような概念を用いると、自動試験機器（または自動試験機器のテストプログラム実行器）は、被試験デバイスによって一つ以上のテスタリソースのどのパラメータ更新が次に要求されるかをもはや知る必要がない。このため、被試験デバイスにおけるテストケースの実行と、自動試験機器のテストプログラム実行器におけるＡＴＥテストプログラムの実行との間で同期は不要である。また、検証エンジニアは、被試験デバイス上で実行されるテストケース内において、一つ以上のテスタリソースの更新を行うべき時刻を定義しなくてもよいだけでなく、更新時に一つ以上のテスタリソースに設定されるべき一つ以上のパラメータも定義しなくてもよい。このため、検証エンジニアは、テスタリソースの適切な更新を定義するために、被試験デバイス上で実行されるテストケースとＡＴＥテストプログラムの双方を変更する必要がない。したがって、（例えば、メッセージの形式の）コマンドを使用して一つ以上のテスタリソースの所望の新しいパラメータを転送する際にＡＴＥテストプログラムを適合させる必要がないため、検証エンジニアがテストケースを開発するのが著しく容易になり、かつ、エラーの可能性も低くなる。

【0084】

したがって、少なくとも試験環境の適合（更新）に関して、テストケースの開発は、このような概念を使用するＡＴＥテストプログラムの適合から実質的に独立している。さらに、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンドと、被試験デバイスによるトリガ信号の実際のアクティブ化とを区別することにより、時間的にクリティカルではない部分の「コマンド」（一つ以上のテストリソースの今後の更新のための一つ以上のパラメータを定義するコマンド）と、当該更新の実際のトリガ実行との間が分離される（ここで、後者は非常に時間的にクリティカルなプロセスである）。その結果、通常より多くのデータを備えるコマンドは、例えば、プロトコルベースであり、かつ、非リアルタイム対応でありうる（または理想的なリアルタイムではない対応でありうる）高速インタフェースを使用して伝送することができる一方、トリガ信号は、被試験デバイスの単一出力の単純なアクティブ化によって生成でき、これは非常に時間精度の高い方法で実行されることができる。

【0085】

好ましい実施の形態において、一つ以上のテスタリソースは、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行されうるテストケースによる）トリガラインのアクティブ化に応答して、（例えば、各テスタリソースによって被試験デバイスに提供される信号の）信号特性（例えば、被試験デバイスに供給される信号電圧、または被試験デバイスに供給されるクロック信号の周波数）を更新するように構成されるトリガ機構を備える。このようなトリガ機構を一つ以上のテスタリソースに設けることにより、非常に速い反応時間を達成することが可能となり、（トリガ信号のアクティブ化に応答してテストリソースが切り替えるべき）所望の新しい値を事前プログラムすることが可能となり、事前プログラミングが時間的にクリティカルではなくなる。対照的に、（被試験デバイスまたはテストケースによって提供される）トリガラインのアクティブ化の際、テストリソースは、（事前にプログラムされている）一つ以上の新しい信号パラメータの使用に迅速に切り替えることができ、テスタリソースは、更新の実際の実行のために、（例えばトリガラインを介して）被試験デバイスからトリガ信号を受信するだけでよい。このように、トリガラインのアクティブ化に応答して使用されるべき、所望の新しい値の時間的にクリティカルではない事前プログラミングは、時間的にクリティカルなトリガラインのアクティブ化から分離されることができる。したがって、非常に短い応答時間を達成することができ、一つ以上のテストリソースの更新の実際のトリガ実行は、一つ以上のテスタリソースに向けて所望の新しいパラメータのジャストインタイム伝送をもはや必要としない。

【0086】

好ましい実施の形態において、自動試験機器は、オン・チップ・システム・テストコントローラと、テストプログラム実行器と、一つ以上のテストリソースとを備える。この場合、トリガラインは、自動試験機器の被試験デバイスインタフェースから、オン・チップ・システム・テストコントローラおよびテストプログラム実行器をバイパスして、一つ以上のテスタリソース（例えば、デバイス電源、信号発生モジュール、チャネルモジュールなど）へ直接延びるハードウェアラインである。

【0087】

このような手法を用いると、一つ以上のテスタリソースの更新を最小限のレイテンシでトリガすることができ、一つ以上のテスタリソースの更新のトリガは、オン・チップ・システム・テストコントローラまたはテストプログラム実行器に追加の処理要件を課すこともない。したがって、オン・チップ・システム・テストコントローラまたはテストプログラム実行器の機能の中断が回避される一方、一つ以上のテスタリソースの更新は非常に迅速に引き起こされることができる。

【0088】

好ましい実施の形態において、一つ以上のテスタリソースは、デバイス電源、信号発生器モジュールおよび／またはチャネルモジュールのうちの一つ以上を備える。このような種類のテスタリソースは、典型的に、一つ以上のパラメータの迅速な更新に適しており、被試験デバイスの試験環境を有意に決定することが判明している。その結果、被試験デバイスの直接的な制御下で、このようなテスタリソースの一つ以上の信号パラメータの更新を直接的にトリガすることが非常に有利であることが判明している。

【0089】

好ましい実施の形態において、一つ以上のテスタリソースは、インタフェースを介してテストプログラム実行器に結合される。したがって、テストプログラム実行器は、当該一つ以上のテスタリソースを初期化することが可能である（例えば、テストケースが被試験デバイス上で実行される前であっても）。さらに、一つ以上のテスタリソースとテストプログラム実行器とを結合するインタフェースを設けることにより、テストプログラム実行器はさらに、（例えば、ＡＴＥテストプログラムの制御下で）一つ以上のテスタリソースに対する所望の更新を事前プログラムすることができる。さらに、テスタリソースとテストプログラム実行器との間にインタフェースを提供することによって、このインタフェースを介してテスタリソースを完全に制御することも可能である。結論として、一つ以上のテスタリソースとテストプログラム実行器との間のインタフェースと、一つ以上のテスタリソースと被試験デバイスのインタフェースとの間を直接延びるトリガラインとの双方を有することが有利であることは明らかである。

【0090】

好ましい実施の形態において、一つ以上のテスタリソースは、テストプログラム実行器から（好ましくはＯＣＳＴコントローラからも）物理的に分離されている（例えば、異なるプリント回路基板、または異なる交換可能モジュールである）。

【0091】

このような物理的に分離され、好ましくはモジュール化された概念を用いることにより、自動試験機器は、特定の試験ニーズに柔軟に対応することができる。さらに、異なる機能を物理的に分離された構成要素に分離することによって、シグナルインテグリティ（信号品質）の歪みを適度に小さく維持できる。さらに、テストプログラム実行器は、典型的には、複数の顕著に異なるテスタリソース（例えば、一つ以上のデバイス電源、および一つ以上のアナログチャネルモジュール、および一つ以上のデジタルチャネルモジュールなど）を制御するように適合されており、テスタリソースの数は、典型的には異なるアプリケーション間で異なることに留意されたい。したがって、例えば、複数の異なるテスタリソース（例えば、一つ以上のデバイス電源、および一つ以上のチャネルモジュールなど、例えばアナログチャネルモジュールおよび／またはデジタルチャネルモジュール）に結合される一つのテストプログラム実行器を有することが強く推奨される。このようなシステム構成において、被試験デバイスインタフェースから一つ以上のテスタリソースに直接延びる一つ以上のトリガラインを用いてテストプログラム実行器をバイパスすることは、テストプログラム実行器が同時に複数の異なるテスタリソースに関するタスクに関与する結果、著しい遅延を受ける可能性があるために、特に効率的である。

【0092】

本発明に係る実施の形態は、被試験デバイスを生成する。被試験デバイスは、専用のトリガラインを介して、自動試験機器にトリガ信号を提供し、一つ以上のテストリソースの更新をトリガするように構成される（ここで、例えば、被試験デバイスは、テストケースの制御下にありうる）。トリガラインのアクティブ化を使用して一つ以上のテスタリソースの更新を直接的にトリガする機能を被試験デバイスに提供することにより、リソース更新を生じさせるためのレイテンシを最小限にすることができ、リソース更新を少ない労力で生じさせることができる。例えば、このような概念において、被試験デバイスの制御下で一つ以上のテストリソースの更新をトリガすることが可能であり、被試験デバイスは専用のトリガラインの状態を変更すればよいため、リソース更新のトリガは非常に小さなソフトウェアおよびハードウェアの労力で可能である。しかしながら、被試験デバイスは、例えば、複雑なドライバを必要とし、しばしば遅延やリアルタイム性の欠如の影響を受ける可能性のあるプロトコルベースの通信を使用する必要はない。このように、被試験デバイス上で実行されうるテストケースは、最小限のレイテンシで、デバイスドライバのオーバーヘッドを必要とせずに、試験環境に対して非常に高度な制御性を有する。

【0093】

好ましい実施の形態において、被試験デバイスは、（例えば、一つ以上のプログラマブルプロセッサデバイスを使用して、および／または一つ以上のマイクロプロセッサコアを使用して）被試験デバイスによって実行されるテストケースの制御下でトリガ信号を提供するように構成される。このような手法を用いると、テストケースを実行可能な「インテリジェント」な被試験デバイスは、被試験デバイスによって実行されるテストケースの制御下で、一つ以上のテスタリソースの更新をトリガできる。しかしながら、一つ以上のテスタリソースの更新をトリガするために、当該テストケースは、トリガラインに結合される（トリガ信号を出力する）被試験デバイスの単一の出力ピンの状態を変更するためのコマンドのような非常に単純なコマンドのみを必要としうる。このように、被試験デバイスは、テストリソースの更新に対して非常に直接的な低いレイテンシの影響を有する。

【0094】

好ましい実施の形態において、被試験デバイスは、（例えば、トリガラインのアクティブ化に対する一つ以上のテスタリソースの応答の事前定義を開始するために）一つ以上の試験リソースの更新のための一つ以上のパラメータを定義するコマンドを自動試験機器に（例えば、専用のトリガラインとは異なる共通インタフェースを介して）提供するように構成される。さらに、被試験デバイスは、（例えば自動試験機器に、例えばテスタリソースに直接的に）トリガ信号を（例えば、専用のトリガラインを介して）提供し、一つ以上のパラメータを使用して一つ以上のテスタリソースの更新をトリガするように構成される。

【0095】

このような２段階の機構を使用することにより、被試験デバイスは、一つ以上のテストリソースの更新のための一つ以上のパラメータを定義する通常特に時間的にクリティカルでないコマンドを自動試験機器に送信するための適切なインタフェース（例えば、プロトコルベースの高速インタフェース）を使用できる。例えば、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンドは、一つ以上のテスタリソースの実際の更新よりかなり前に、被試験デバイスによって自動試験機器に送信されてもよい。例えば、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンドは、一つ以上のテスタリソースの以前の更新をトリガした直後に自動試験機器に送信されてもよく、その結果、プロトコルベースのインタフェースを用いた自動試験機器へのコマンドの送信と、自動試験機器による当該コマンドの処理との双方に十分な時間が確保される（ここで、自動試験機器によるコマンドの処理は、例えば、テストプログラム実行器によるコマンドの解析と、テストプログラム実行器による自動試験機器の一つ以上のテスタリソースの事前プログラミングとを備えうる）。さらに、一つ以上のテスタリソースを更新させる実際に時間的にクリティカルなトリガの実行は、（例えば、専用のトリガラインを介した）トリガ信号の提供（またはアクティブ化）によって生じてもよく、これは、レイテンシを低く維持し、自動試験機器のテストプログラム実行器の（優先度の高い）中断を回避するのに役立つ。その結果、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンドを、一つ以上のテスタリソースの更新の実際のトリガから分離して自動試験機器に提供する概念は、効率とレイテンシとの間の良い妥協点を提供する。

【0096】

本発明に係る実施の形態は、試験機器構成（テストセットアップ）を生成し、試験機器構成は、前述の自動試験機器と、前述の被試験デバイスとを備える。

【0097】

本発明に係る一実施の形態は、自動試験機器を動作させる方法を生成し、自動試験機器は、被試験デバイスによって（すなわち、例えば被試験デバイス上で実行されうるテストケースによって）制御可能なトリガライン（例えばハードウェアトリガライン、例えばＧＰＯトリガライン）を備える。この方法は、被試験デバイスによる（すなわち、例えば被試験デバイス上で実行されうるテストケースによる）トリガラインのアクティブ化に応答して、一つ以上のテスタリソースを更新する（例えば、自動試験機器によって被試験デバイスに提供される一つ以上の供給電圧を変更する、または自動試験機器によって被試験デバイスに提供される一つ以上のアナログまたはデジタル信号の信号特性を変更する）ことを備える。

【0098】

この自動試験機器を動作させる方法は、上述した自動試験機器と同様の考察に基づく。さらに、自動試験機器を動作させる方法は、（自動試験機器に関して）本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0099】

本発明に係る別の実施の形態は、被試験デバイスを試験するための方法を生成する。この方法は、テストプログラム実行器を用いて、トリガ信号に応答して引き受けるべき一つ以上の各パラメータの値に一つ以上のテスタリソースを（例えば、自動試験機器の制御下で）事前プログラムすることを備える。この方法は、一つ以上のテスタリソースに事前プログラムされた一つ以上の各パラメータの値を引き受けさせるトリガ信号を、被試験デバイスから一つ以上のテスタリソースに直接的に（例えば、テストプログラム実行器をバイパスして）提供することを備える。

【0100】

被試験デバイスを試験するこの方法もまた、上述した自動試験機器および上述した被試験デバイスなどと同様の考察に基づく。したがって、この方法は、自動試験機器に関しておよび被試験デバイスに関して、本書に記載される任意の特徴、機能および詳細によって任意選択で補足されてもよい。この方法は、そのような特徴、機能および詳細によって個別にまたは組み合わせて、任意選択で補足されてもよい。

【0101】

本発明に係るさらに別の実施の形態は、一つ以上のコンピュータ上で、および／または一つ以上のマイクロプロセッサ上で、および／または一つ以上のマイクロコントローラ上でコンピュータプログラムが実行される際に、当該方法を実行するためのコンピュータプログラムを生成する。

【0102】

本発明に係るさらに別の実施の形態は、被試験デバイスを試験するための自動試験機器を生成する。自動試験機器は、（例えば、被試験デバイス上で実行されうるが、代替的に被試験デバイス上で部分的に実行され、かつ、自動試験機器上で部分的に実行されうる）テストケースによって制御可能なトリガライン（例えばハードウェアトリガライン、例えばＧＰＯトリガライン）を備える。自動試験機器は、テストケースによるトリガラインのアクティブ化に応答して、一つ以上のテストリソースを更新する（例えば、自動試験機器によって被試験デバイスに提供される一つ以上の供給電圧を変更する、または、自動試験機器によって被試験デバイスに提供される一つ以上のアナログまたはデジタル信号の一つ以上の信号特性を変更する）ように構成される。

【0103】

この実施の形態は、上述した自動試験機器と同様の考察に基づくが、本実施の形態において、トリガラインは、テストケースによって（テストケースが被試験デバイスの役割を担うように）制御可能である（例えば、テストケースが被試験デバイスと自動試験機器との間でどのように分配されるかという問題から独立している）ことに留意されたい。

【0104】

さらに、この自動試験機器は、他の自動試験機器に関して本書に記載される任意の特徴、機能および詳細によって任意選択で補足されてもよいことに留意されたい。自動試験機器は、そのような特徴、機能および詳細によって、個別にまたは組み合わせて補足されてもよい。

【0105】

本発明に係るさらに別の実施の形態は、（例えば、被試験デバイス上で実行されうる、または被試験デバイスと自動試験機器との間で分配されうる）テストケースによって制御可能なトリガライン（例えばハードウェアトリガライン、例えばＧＰＯトリガライン）を備える自動試験機器を動作させる方法に向けられる。この方法は、（例えば、被試験デバイス上で実行されうる、または被試験デバイスと自動試験機器との間で分配されうる）テストケースによるトリガラインのアクティブ化に応答して、一つ以上のテストリソースを更新する（例えば、自動試験機器によって被試験デバイスに提供される一つ以上の供給電圧を変更する、または自動試験機器によって被試験デバイスに提供される一つ以上のアナログまたはデジタル信号の信号特性を変更する）ことを備える。

【0106】

自動試験機器を動作させるためのこの方法は、本書に記載される自動試験機器を動作させる他の方法と同様の考察に基づく。しかしながら、テストケースは、被試験デバイスの機能を引き受けることに留意されたい。さらに、自動試験機器を動作させる方法は、自動試験機器に関して、および被試験デバイスに関して本書に開示される任意の特徴、機能および詳細によって任意選択で補足されてもよいことに留意されたい。この方法は、そのような特徴、機能および詳細によって、個別にまたは組み合わせて、任意選択で補足されてもよい。

【0107】

本発明に係る一実施の形態は、被試験デバイスを試験する方法を生成する。この方法は、テストプログラム実行器を用いて、トリガ信号に応答して引き受けるべき一つ以上の各パラメータの値に一つ以上のテスタリソースを（例えば、自動試験機器の制御下で）事前プログラムすることを備える。さらに、この方法は、一つ以上のテスタリソースに事前プログラムされた一つ以上の各パラメータの値を引き受けさせるトリガ信号を、テストケースから一つ以上のテスタリソースに直接的に（例えば、テストプログラム実行器をバイパスして）提供することを備える。

【0108】

被試験デバイスを試験するこの方法は、テストケースが被試験デバイスの役割を担う、上述した被試験デバイスを試験する方法と同様である。さらに、この方法は、自動試験機器に関して、および被試験デバイスに関して本書に記載される任意の特徴、機能および詳細によって任意選択で補足されてもよいことに留意されたい。この方法は、これらの特徴によって、個別にまたは組み合わせて、任意選択で補足されてもよい。

【0109】

本発明に係る別の実施の形態は、一つ以上のコンピュータ上で、および／または一つ以上のマイクロプロセッサ上で、および／または一つ以上のマイクロコントローラ上でコンピュータプログラムが実行される際に、本書に記載される方法を実行するためのコンピュータプログラムを生成する。

【0110】

本発明に係る実施の形態は、一つ以上の被試験デバイスを試験するための自動試験機器を生成する。自動試験機器は、（例えば被試験デバイスに供給される供給電圧の、例えば被試験デバイスに供給される電流の、例えば被試験デバイスによって供給される信号の信号特性の、例えば被試験デバイスに供給される信号の信号特性の、例えば被試験デバイスに供給されるクロック信号のクロック周波数の、例えば被試験デバイスの環境における温度、湿度、気圧、電界または磁界などの環境パラメータなどの）一つ以上の物理量の測定を要求する（例えば、メッセージの形式の）コマンドを、被試験デバイスから受信するように構成される。さらに、自動試験機器は、被試験デバイスによって提供されるコマンドに応答して、一つ以上の物理量の測定を実行または開始するように構成される。さらに、自動試験機器は、被試験デバイスに測定結果信号（例えば、確認応答メッセージ）を提供し、被試験デバイスによって要求された測定結果を通知するように構成される。

【0111】

このような概念を用いると、測定結果が測定結果信号を用いて被試験デバイス（すなわち、テストケース）に提供されるため、被試験デバイス、すなわち、被試験デバイス上で実行されるテストケースは、一つ以上の測定の実行に対する制御を有し、さらに測定結果を処理してもよい。その結果、被試験デバイスは、被試験デバイスの機能または性能を特徴付けるために実行される測定を含む、テストの実行をかなりの程度まで制御きる。その結果、試験を設計する検証エンジニアは、被試験デバイス上で実行されるテストケースに、自動試験機器による一つ以上の物理量の測定を要求する一つ以上のコマンドを提供させるプログラム命令を追加してもよく、（測定結果信号を使用して自動試験機器によって被試験デバイスに提供される）一つ以上の測定結果を評価するために被試験デバイス上で実行されるテストケースに命令を配置してもよい。その結果、試験のほとんどのステップは、被試験デバイス（または被試験デバイス上で実行されるテストケース）により制御することができ、これは、検証エンジニアが、被試験デバイス上で実行されるテストケースの開発に集中でき、自動試験機器上で実行されるＡＴＥテストプログラムの開発に集中する必要がないことを意味する。例えば、本書に開示される概念を用いると、検証エンジニアは、テストケースが実行される特定の時点で測定を実行するために、自動試験機器で実行されるテストプログラムを適合させる必要がないかもしれない。むしろ、ＡＴＥテストプログラムは、被試験デバイスから提供されるコマンドに対する標準応答（例えば、予め定義されるフォーマット）を定義するだけでよく、当該標準応答は、例えば、測定を実行するための物理的テスタリソースの適切な制御および測定結果信号の提供を備えてもよい。その結果、被試験デバイス（すなわち、被試験デバイス上で実行されるテストケース）は、被試験デバイス上のテストケースの実行の進捗の観点で適切であればいつでも、一つ以上の物理量の測定を要求してもよく、被試験デバイス（または被試験デバイス上で実行されるテストケース）は測定結果をプロトコルおよび／または評価してもよい。例えば、被試験デバイスは、試験のさらなる実行に関する決定のために測定結果を使用してもよく、例えば、測定結果に依存してテストケースの実行を変更してもよい。

【0112】

さらに、被試験デバイスは、自動試験機器から測定結果信号を受信したときに測定が完了したことを確認できる（また、被試験デバイスは、被試験デバイスが一つ以上の物理量の測定を要求する前に測定が実行されていないことを知る）ため、被試験デバイスに測定結果信号を提供し、被試験デバイスによって要求された測定結果を通知することによって、自動試験機器は、自動試験機器および被試験デバイスの動作間の時間的同期を簡単に行うことが可能である。その結果、本書に開示される機構は、測定が「正しい時間に」、すなわち、被試験デバイスによるテストケースの実行の正しい時点で行われることを確保できる。

【0113】

結論として、測定に対する制御がテストケースに移行し、被試験デバイスと測定の実行との間の良好なタイミング同期を提供し、さらに被試験デバイス（または被試験デバイス上で実行されるテストケース）に試験を制御するための測定結果を使用する機会を与えるため、ここで説明される概念は検証エンジニアの作業を著しく容易にする。

【0114】

好ましい実施の形態において、自動試験機器は、被試験デバイスから、パラメータ化されたメッセージの形式のコマンドを受信するように構成され、メッセージのパラメータは、測定されるべき物理量（例えば、電源電圧、クロック周波数、信号特性、環境特性など）を記述する。しかしながら、パラメータ化されたメッセージの使用は、検証エンジニアによる試験の開発（例えば、被試験デバイス上で実行されるテストケースを開発すること）が特に容易になることが判明している。特に、パラメータ化されたメッセージは、通常、検証エンジニアにとって特に読みやすく、パラメータ化されたメッセージの使用は、異なる物理量を測定きるアプリケーションに十分に適合することが判明している。その結果、例えば、メッセージのパラメータは、どの物理量が測定されるかを指定してもよく、パラメータは（任意選択で）測定を特徴付ける追加情報を提供してもよい（例えば、フィルタまたは平均化が使用されるべきかを定義してもよいし、測定分解能を定義してもよいし、自動試験機器の測定リソースの一つ以上のパラメータの任意の他の設定を定義してもよい）。その結果、このようなパラメータ化されたメッセージを使用することにより、被試験デバイスは、測定要件をより詳細に定義できる。

【0115】

さらに、被試験デバイスは、例えば、メッセージの通信に適した一つ以上のプロトコルベースのインタフェースを備えてもよいため、メッセージは通常、被試験デバイスから自動試験機器への送信に適していることに留意されたい（ここで、メッセージは、例えば、メッセージヘッダ、メッセージペイロード、および任意選択でエラー検出情報またはエラー訂正情報およびメッセージターミネータを備えてもよい）。しかしながら、パラメータ化されたメッセージは、このようなインタフェースを介して容易に伝送されてもよく、メッセージは、単純な場合、ＡＳＣＩＩ文字列を使用して符号化されることが判明している。結論として、被試験デバイスからパラメータ化されたメッセージの形式でコマンドを受信するという概念は、簡単に実装でき、測定を正確に定義できることが分かっている。

【0116】

好ましい実施の形態において、自動試験機器は、測定結果信号をメッセージの形式で提供するように構成される。測定結果信号をメッセージの形式で提供することにより、自動試験機器から被試験デバイスに測定結果を通信することが、通常容易に可能となる。例えば、被試験デバイスは、メッセージを受信（および解読）することが可能な一つ以上のインタフェース（例えば、高速インタフェース）を備えることが多い。特に、結果情報は通常、例えば構文解析機能を用いて、メッセージから計算上効率的な方法で抽出されうる。このように、メッセージの形式で測定結果信号を提供することは、被試験デバイスへの測定結果の効率的な通信に十分に適合する。

【0117】

好ましい実施の形態において、自動試験機器は、被試験デバイスからのコマンド（例えば、被試験デバイスからのメッセージ）を、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、高速インタフェースを介して、例えばＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）受信するように構成される。代替的または追加的に、自動試験機器は、測定結果信号（例えば、測定結果メッセージ）を被試験デバイスに、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、高速インタフェースを介して、例えばＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）提供するように構成される。

【0118】

このような高速インタフェースは、一般的に十分に小さいレイテンシと十分に高い帯域幅を備えるため、被試験デバイスから自動試験機器へのコマンドの送信、および自動試験機器から被試験デバイスへの測定結果信号の送信に特に適していることが判明している。さらに、典型的な被試験デバイスは、本質的に一つ以上の高帯域幅インタフェースを備え、当該高帯域幅インタフェースの少なくとも一つは、被試験デバイスを試験する際、例えば、被試験デバイスへのテストケースのアップロードおよび／または被試験デバイスから自動試験機器への試験結果のダウンロードのために通常使用される。さらに、多くの状況において、高帯域インタフェースの少なくとも一つは、自動試験機器によっても試験される。したがって、自動試験機器と被試験デバイスとの間で通信するための機能は、いずれにしても多くの試験構成に設けられ、被試験デバイスから自動試験機器に一つ以上の物理量の測定を要求するコマンドを送信するため、および／または自動試験機器から被試験デバイスに測定結果信号を送信するために効率的に流用できることが判明している。特に、典型的な高帯域幅インタフェースは、被試験デバイスの試験をサポートする他のデータ（例えば、テストケースデータまたは試験結果データなど）に加えて、一つ以上の物理量の測定を要求するコマンドおよび／または測定結果信号を伝送するのに十分なデータ伝送容量を有することが判明している。さらに、被試験デバイスから自動試験機器に一つ以上の物理量の測定を要求するコマンドを送信し、測定結果信号の使用もするという概念を用いることにより、被試験デバイスに測定結果を通知することで典型的に測定のタイミングをクリティカルではなくし、プロトコルベースでありうる、および／または異なる目的のために共有されうる高帯域幅インタフェースの使用が可能になり、その結果、タイミングの非決定性をもたらすかもしれない。結論として、測定の要求および／または測定結果信号の受信に高帯域幅のインタフェースを使用することで、実装の労力とタイミング精度との間で良好な妥協点を提供することが判明している。

【0119】

好ましい実施の形態において、自動試験機器は、被試験デバイス（例えば、システム・オン・チップ）上のテストケースの実行中に、被試験デバイスによって提供されるコマンドに応答して（例えば、被試験デバイスによって実行されるテストケースの制御下で）一つ以上の物理量の測定を実行するように構成される。物理量の測定が被試験デバイスによって要求されるという概念を有することにより、例えば被試験デバイスにおけるテストケースの実行が非決定性でありうるテストケースの実行と良好に同期して測定を実行できる。言い換えれば、本発明の一態様によれば、自動試験機器（または、自動試験機器上で実行されるテストプログラム）は、自動試験機器が被試験デバイスから一つ以上の物理量の測定を要求するコマンドを受信するまで、測定をいつ実行すべきかの詳細な知識を有していなくてもよい。しかしながら、本概念によれば、測定のために被試験デバイスにおけるテストケースの実行を中断する必要はない。むしろ、テストケースの制御下で、したがって、テストケースの現在の実行状況の観点で測定が所望の結果をもたらす時に、測定を行うことさえ可能である。一例として、被試験デバイス上で実行されるテストケースは、消費電流やダイ温度などの一つ以上の物理量の測定（または監視）を必要とするテストケースのフェーズに入る直前に、一つ以上の物理量の測定を要求するコマンドを発行してもよい。結論として、被試験デバイスが一つ以上の物理量の測定を要求することを可能にすることによって、テストケースを中断する必要性なしに、被試験デバイス上のテストケースの実行と同期して測定を行うことができ、測定結果信号を被試験デバイスに提供することによって、テストケースも、測定が完了する時間およびテストケースが別の処理ステップに進むことができる時間について十分に認識することができる。このように、上述した概念によれば、自動試験機器と被試験デバイス上で実行されるテストケースとの間のタイミング同期のためにテストケースの実行を中断する必要がないため、特に高速な試験が可能になる。

【0120】

好ましい実施の形態において、自動試験機器は、被試験デバイス上で実行されるテストケースによる使用のためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を提供するように構成される。アプリケーション・プログラミング・インタフェースは、被試験デバイスから自動試験機器への一つ以上の物理量の測定を要求するコマンドの送信のための一つ以上のルーチン（例えば、メソッドまたは関数）および／またはルーチンヘッダ（例えば、メソッドヘッダまたは関数ヘッダ）を提供するように構成される。代替的または追加的に、アプリケーション・プログラミング・インタフェースは、被試験デバイスと自動試験機器との間の時間的同期のための一つ以上のルーチン（例えば、メソッドまたは関数）またはルーチンヘッダ（例えば、メソッドヘッダまたは関数ヘッダ）（例えば、測定結果を示す信号の受信まで（例えば、被試験デバイス上で実行されるテストケースの）プログラムの実行を一時停止するための一つ以上のルーチンまたはルーチンヘッダ）を提供するように構成される。

【0121】

アプリケーション・プログラム・インタフェースを提供することにより、検証エンジニアによるテストケースの開発を大幅に促進できる。例えば、テストケースを開発する検証エンジニアは、アプリケーション・プログラミング・インタフェースが提供する（または表現する）メソッドや関数の構文に関する知識を有していればよく、自動試験機器の内部に関する詳細な知識を必要としないかもしれない。したがって、アプリケーション・プログラミング・インタフェースを（例えば、自動試験機器のソフトウェア・リポジトリで）提供することにより、自動試験機器の製造者は、自動試験機器の詳細に関する優れた知識を使用して、アプリケーション・プログラミング・インタフェースを提供し、これにより、テストケースを設計する検証エンジニアは、単純な（おそらくパラメータ化された）関数呼び出しまたはメソッド呼び出しを用いて自動試験機器によって提供される測定機能性にアクセスできるようにする。さらに、アプリケーション・プログラミング・インタフェースは、テストケースを設計する検証エンジニアが、測定結果信号を待機する機能またはメソッドなどの、被試験デバイスと自動試験機器との間の時間同期をサポートする一つ以上のメソッドまたは関数を使用できるようにしてもよい。このような関数は、測定結果を戻り値としてテストケースに提供してもよく、したがって、測定とテストケースの実行との間の同期をサポートしてもよい。さらに、このような機能は、テストケースの別の実行における測定結果の利用を容易にする。

【0122】

アプリケーション・プログラミング・インタフェースのメソッドまたは関数は、この場合、一つ以上の物理量の測定を要求するコマンドの提供を取り扱い、測定結果信号の評価（例えば、解析および／または翻訳）を取り扱ってもよく、テストケースで扱いやすい形式（例えば、数値表現）で測定結果を提供してもよい。

【0123】

好ましい実施の形態において、自動試験機器は、オン・チップ・システム・テスト（ＯＳＣＴ）コントローラと、テストプログラムを実行するテストプログラム実行器と、一つ以上のテスタリソース（例えば、一つ以上のデバイス電源、および／または一つ以上のアナログまたはデジタル信号発生器、および／または一つ以上の測定リソース）とを備える。オン・チップ・システム・テストコントローラは、被試験デバイスから一つ以上の物理量の測定を要求するコマンドを（例えば、メッセージの形式で）受信し（例えば、高帯域幅インタフェースを介して）、コマンド（例えば、メッセージ）をテストプログラムを実行するテストプログラム実行器に転送するように構成される。さらに、テストプログラムは、（転送された）コマンド（例えば、転送されたメッセージの形式）に応答して、例えば、転送されたメッセージを（例えば、転送されたメッセージに含まれる一つ以上のパラメータに依存して）解読および／または解釈した後に、一つ以上の物理量の測定を生じさせる（例えば実行する）ように構成されるメッセージハンドラを備える。

【0124】

このような概念を用いて、ＯＣＳＴコントローラは、例えば、被試験デバイスと自動試験機器との間の通信を取り扱ってもよく、オン・チップ・システム・テストコントローラは、例えば、被試験デバイスとの高速通信に特に適合された専用の処理手段（例えば、専用のハードウェア）を有してもよい。さらに、オン・チップ・システム・テストコントローラは、例えば、テストプログラム（またはテストケース）を被試験デバイスにアップロードする機能および試験結果を被試験デバイスからダウンロードする機能など、システム・オン・チップの試験をサポートする追加機能を備えてもよい。さらに、オン・チップ・システム・テストコントローラは、被試験デバイスから提供される試験結果の評価を可能にする追加機能を備えてもよい。好ましくは、オン・チップ・システム・テストコントローラは、被試験デバイスとのリアルタイム（しかしながら典型的には非決定性またはプロトコルベース）の通信を効率的に取り扱うように構成されてもよく、したがってオン・チップ・システムとのデータ交換に適していてもよい。一方で、テストプログラム実行器は、ＡＴＥテストプログラムを実行するように構成されてもよく、例えば、一つ以上のデバイス電源、および／または一つ以上のデジタルチャネルモジュール、および／または一つ以上のアナログチャネルモジュール、および／または一つ以上の測定器（ここで、これら全ての構成要素を備える必要はなく、測定器は、例えばアナログチャネルモジュールまたはデジタルチャネルモジュールまたはデバイス電源の一部であってもよい）などのテスタリソースと密接にリンク（または直接通信）してもよい。

【0125】

例えば、テストプログラム実行器は、一つ以上の物理量の測定を要求するコマンドを解釈でき、適切な測定リソースまたは測定器に要求された測定を行わせることができるテストプログラムを備えてもよい。例えば、コマンドの解釈と実行を担当する（テストプログラム実行器上で実行される）ＡＴＥテストプログラムの一部は、テストケースのプログラムコードから独立していてよく、したがって、異なるテストケースでも同等のままであってよい。したがって、このような概念を用いることにより、オン・チップ・システム・テストコントローラとテストプログラム実行器との間で効率的な機能分担がなされてもよい。例えば、オンチップ・システム・テスト・コントローラは、リアルタイムまたは高速で実行されるべき（おそらく）非決定性タスクに使用される一方、テストプログラム実行器は、他のテスタリソース（デバイス電源、アナログチャネルモジュール、デジタルチャネルモジュール、および測定リソースなど）に対するより密接な制御を引き受けてもよく、例えば、被試験デバイスの試験環境（例えば、一つ以上の電源電圧、一つ以上のクロック信号、一つ以上の予め定義された入力信号など）を定義しうる典型的に自由に構成可能なＡＴＥテストプログラムを実行してもよい。したがって、テストを効率的に実行することができ、オン・チップ・システム・テストコントローラは、被試験デバイスとテストプログラム実行器との間の仲介役として機能できる。

【0126】

好ましい実施の形態において、（テストプログラムの一部でありうる）メッセージハンドラは、（例えば、供給電圧または信号の）テストリソースの記号参照（例えば、「ＶＣＣ２」）を備えるコマンド（例えば、メッセージ）をテスタハードウェア関連の測定命令（例えば、電圧または温度または信号特性の測定を生じさせる命令）に変換するように構成される。

【0127】

このような記号参照を利用するコマンド変換を用いることにより、エンジニアはテストプログラム内で理解しやすい記号参照を使用できる一方、メッセージハンドラは、このコマンドをテスタハードウェア関連の測定命令に変換できる。したがって、テストケースをプログラミングするエンジニアは、自動試験機器の内部の知識を持つ必要がなく、記号参照を効率的にできる。ここで、記号参照の使用は、典型的に自動試験機器の特定のハードウェアリソースの仕様よりもエラーの可能性が非常に少ないことに留意されたい。対照的に、メッセージハンドラは、（例えば、自動試験機器の物理的リソース、およびＡＴＥの物理的リソースと被試験デバイスの特定のピン（またはパッド）との接続の双方を考慮して）記号参照と現在のテスタ構成における当該記号参照に関連する物理的なテスタハードウェアとの間の割り当てをするように（例えば、自動試験機器の内部の物理的詳細をよく理解している技術者によって）適合されることができる。

【0128】

このような概念を用いると、テストケースは、記号参照を備えるコマンドを使用するために、異なるテスタハードウェア上で使用可能となりうる一方で、メッセージハンドラのみを特定のハードウェアに（例えば、利用可能なテスタリソースに、およびＡＴＥハードウェアと被試験デバイスのピンとの間の接続に）適合させればよい。その結果、テストケースの開発効率を高めることができる。

【0129】

好ましい実施の形態において、メッセージハンドラは、測定結果メッセージを生成し、生成された測定結果メッセージを（例えば、測定の実行後に）オン・チップ・システム・テストコントローラに提供するように構成される。さらに、オン・チップ・システム・テストコントローラは、メッセージハンドラによって提供された測定結果メッセージを被試験デバイスに転送し、またはメッセージハンドラによって提供された測定結果メッセージに応答して測定結果メッセージを被試験デバイスに提供するように構成される。このような概念を用いると、オン・チップ・システム・テストコントローラが被試験デバイスと効率的に通信する（例えば、プロトコルベースの高速インタフェースを使用する）能力を利用できる一方、測定結果メッセージは、テスタリソース（例えば、測定リソース）へのより直接的なアクセスを通常備えるメッセージハンドラによって生成される（または引き起こされる）。したがって、測定結果は、非常に効率的な方法で被試験デバイス（または被試験デバイス上で実行されるテストケース）に通信されることができ、オン・チップ・システム・テストコントローラは、測定結果を変更しない方法で転送してもよいし、測定結果メッセージを（例えば、使用される特定の高速インタフェースの要件に）適合させるための何らかのメッセージ変換を適用してもよい。このように、非常にリソース効率の高い概念を実現できる。

【0130】

好ましい実施の形態において、自動試験機器（例えば、自動試験機器のテストプログラム実行器）は、テストプログラムを実行するように構成される。テストプログラムは、自動試験機器のテスタリソースを初期化し、被試験デバイス上でのプログラム実行の開始を可能にするように構成される。さらに、テストプログラムは、被試験デバイスの制御下で（例えば、被試験デバイス上で実行される一つ以上のテストケースの制御下で）テストリソースのさらなる更新を生じさせるように構成される。代替的に、テストプログラムは、被試験デバイスの制御下で（例えば、被試験デバイス上で実行される一つ以上のＯＣＳＴテストケースの制御下で）一つ以上の測定を生じさせるように構成される。

【0131】

このような概念を用いると、テストプログラム（すなわち、例えば自動試験機器のテストプログラム実行器上で実行されうるＡＴＥテストプログラム）は、複数の機能性を引き受けることができる。テストプログラムは、例えば、被試験デバイスの非常に信頼性の高い動作を可能にする供給電圧を提供するように電源を設定することによって、被試験デバイスの信頼性の高い起動を可能にするように自動試験機器のテスタリソースを予め構成できる。したがって、自動試験機器のテストプログラム実行器で実行されるテストプログラムは、信頼性の高い条件を提供することによって、被試験デバイスへのテストケースの安全なアップロードをサポートできる。

【0132】

さらに、テストプログラムは、例えば被試験デバイスの初期化を制御（または少なくともサポート）してもよく、任意選択で、例えば高速インタフェースを用いて被試験デバイスとオン・チップ・システム・テストコントローラとの間の通信の確立を可能にする初期プログラムコードのアップロードも制御してもよい。被試験デバイスの制御下でテストリソースのさらなる更新を生じさせることにより、被試験デバイスの試験環境を、例えば最初の試験環境よりも「挑戦的」に変更し、「ストレス」条件下でテストケースを実行してもよい。このように、被試験デバイスの制御下でテストリソースのさらなる更新を可能にすることで、被試験デバイス上で実行されるテストケースを大部分として試験を定義することができ、テスト開発に大きな利点をもたらす。また、被試験デバイスの制御下でテストリソースを更新（結果として試験環境を更新）することにより、試験を定義する検証エンジニアがＡＴＥテストプログラムを変更することなく、被試験デバイス上でのテストケースの実行と試験環境の変更との間での良好な調整が可能となる。さらに、被試験デバイス（またはテストケース）に、試験環境の更新および自動試験機器のリソースによって実行される測定の両方を制御する機能を任意選択で提供することにより、被試験デバイスによって実行されるテストケースは、被試験デバイスの完全なテストに必要なすべての機能性の非常に大きな部分を制御できる。そのため、試験の設計が特に容易になる。さらに、ＡＴＥ側のテストプログラムと被試験デバイス上で実行されるテストケースとの間で、機能性を効率的に共有できる。

【0133】

好ましい実施の形態において、自動試験機器は、オン・チップ・システム・テストコントローラを備える。自動試験機器は、一つ以上のテスタリソース、例えば、一つ以上のデバイス電源、および／または一つ以上のアナログまたはデジタル信号発生器、および／または一つ以上の測定リソースを備える。オン・チップ・システム・テストコントローラは、一つ以上のテスタリソースに結合される（例えば直接結合される、例えばテストプログラム実行器をバイパスする方法で結合される）。さらに、オン・チップ・システム・テストコントローラは、被試験デバイスからのコマンドに応答して一つ以上の物理量の測定を生じさせるために、一つ以上のテスタリソースに制御信号を（例えばデータバスを介して、および／または一つ以上の同期ラインを介して、および／または同期バスを介して）提供するように構成される。

【0134】

このような、オン・チップ・システム・コントローラがテスタリソースに直接アクセスする（テストプログラム実行器をバイパスする）構成を用いることで、テストプログラム実行器によって実行されるＡＴＥテストプログラムの実行を妨げることなく、特に高速に測定を生じさせることができる。このようなコンセプトを用いることにより、被試験デバイスとのプロトコルベースの高速通信を効率的な方法で（例えば、専用ハードウェアを使用して）実施するためのオン・チップ・システム・テストコントローラの機能性を活用できる。オン・チップ・システム・テストコントローラに、一つ以上のテスタリソース、例えば一つ以上の測定リソースを直接制御する機能を持たせることにより、テストプログラム実行器に起因するような遅延を回避できる。さらに、一つ以上の物理量の測定を要求するコマンドによってテストプログラム実行器の動作を妨害することも回避でき、テストプログラム実行器が試験結果を評価するタスクをより効率的に扱えるようにできる。その結果、より高速で資源効率の高い試験の実行を実現できる。

【0135】

好ましい実施の形態において、オン・チップ・システム・テストコントローラは、（例えば、電源電圧のまたは信号の）テスタリソースの（またはテスタリソースに対する）記号参照（例えば、「ＶＣＣ２」）を備えるコマンド（例えば、メッセージ）を、テスタハードウェア関連の測定命令（例えば、自動試験機器の測定リソースによる一つ以上の物理量の測定を生じさせる命令）に変換するように構成される。

【0136】

オン・チップ・システム・テストコントローラに、記号参照を備えるコマンドをテスタハードウェア関連の測定命令に変換する機能を設けることにより、被試験デバイス上で実行されるテストケースの開発をテスタハードウェアに依存しないようにすることができる。被試験デバイスから自動試験機器に送信されるコマンドに記号参照を使用することにより、テストケースは、自動試験機器の異なるハードウェア構成で使用することができ、記号参照からテスタ（ＡＴＥ）の実際の物理的リソースへのマッピングは、現在のテスタ構成について一度定義されればよく、オン・チップ・システム・テストコントローラに構成情報として提供されてもよい。その結果、異なるハードウェア構成を有する自動試験機器の使用は、テストケースを適合させることなく容易に可能となる。

【0137】

好ましい実施の形態において、オン・チップ・システム・テストコントローラは、データバスおよび同期ラインまたは同期バスを介して、一つ以上のテスタリソースと結合される。さらに、オン・チップ・システム・テストコントローラは、（例えば、選択されたテスタリソースまたは今後の測定の今後の特性を定義するために）被試験デバイスから受信したコマンドのメッセージパラメータ（例えば、測定される物理量を定義するメッセージパラメータ）に依存して、データバスを介して、選択された物理量（例えば、供給電圧または供給電流または環境温度）の測定（例えば、電圧測定または電流測定または温度測定）を準備（例えば、初期化）するよう構成される。さらに、オン・チップ・システム・テストコントローラは、同期バスまたは同期ラインによって（例えば、同期バスイベントまたは同期バスメッセージを使用して）測定すべき物理量の測定をトリガするように構成される。

【0138】

このような概念を用いると、オン・チップ・システム・テストコントローラは、高いタイミング精度で測定を実行できる。選択された物理量の測定を事前構成することにより、測定リソースが測定のトリガ実行に非常に迅速に反応できるように、測定リソースの設定を準備することができる。したがって、オン・チップ・システム・テストコントローラは、最初にメッセージパラメータにしたがって測定リソースを初期化してもよく（ここで、メッセージパラメータは、例えばどの電圧を測定すべきか、および／または、そのような測定においてどのフィルタリングもしくは平均化を使用すべきかを決定しうる）、その後、オン・チップ・システム・テストコントローラによって高いタイミング精度で実際の測定がトリガされてもよい。したがって、被試験デバイスは、特定の測定タイミングを要求することさえ可能であり、オン・チップ・システム・テストコントローラは、最初に（例えば、各測定リソースを適切な状態または構成に設定することによって）測定を事前構成してもよく、その後、測定リソースを所望のタイミングでトリガしてもよい。したがって、テストケースに定義された要件に適合する、非常に正確な測定を行うことができる。

【0139】

好ましい実施の形態において、オン・チップ・システム・テストコントローラは、測定結果信号を（例えば、測定結果メッセージの形式で）被試験デバイスに提供するように構成される。被試験デバイスに測定結果信号を提供する機能性をオン・チップ・システム・テストコントローラに実装させることにより、高効率かつ短いレイテンシを達成できる。

【0140】

本発明に係る一実施の形態は、被試験デバイスを生成する。被試験デバイスは、（例えば、被試験デバイス上で実行されるテストケースの制御下で）一つ以上の物理量の測定を要求するコマンドを（例えば、メッセージの形式で）自動試験機器に提供するように構成される。さらに、被試験デバイスは、被試験デバイスによって要求された測定結果を示す測定結果信号（例えば、測定結果メッセージ）の受信を待つように構成される（例えば、被試験デバイスによって要求された測定結果を被試験デバイスが受信するまでテストケースの実行を一時停止することによる）。このような被試験デバイスは、一つ以上の物理量の測定を効率的に制御することができ、さらに、テストケースの実行をこのような測定と時間的に同期させることができる。被試験デバイスによって要求された測定結果を示す測定結果信号を待つことで、測定結果が実際に得られる前にテストの実行を進めること（例えば、試験結果を偽造する可能性）を回避できる。このような手順は、被試験デバイス上および自動試験機器上でのテストケースの実行間で完全なタイミングで同期されなかったとしても、このような手順により、被試験デバイスの制御下で信頼性の高い測定結果を取得することができる。例えば、被試験デバイスが測定結果信号を受信するまで、被測定機は、測定を行うべき状態を維持してもよく、その結果、測定結果が有効であることを保証できる。

【0141】

このように、被試験デバイスと自動試験機器との間に完全なタイミング同期機構がなくても、信頼性の高い測定を行うことができる（これは、厳密なタイミング決定論を備えない多くのシステム・オン・チップに合致しうる）。

【0142】

好ましい実施の形態において、被試験デバイスは、システム・オン・チップである。被試験デバイスは、テストケースを実行する（例えば、被試験デバイスを試験するための試験を実行する）ように構成される。さらに、被試験デバイスは、テストケースの制御下で、自動試験機器にコマンドを提供するように構成される。ここに開示される概念は、例えば、一つ以上の内部プロセッサまたはプロセッサコアを用いてテストケースを実行することが可能なシステム・オン・チップの試験に特に適していることが判明している。特に、テストケースは、通常、例えば基礎となるインタフェースドライバを使用して、一つ以上の高速インタフェースにアクセスできるため、自動テスト機器にコマンドを提供するのに適していることが判明している。

【0143】

好ましい実施の形態において、被試験デバイスは、パラメータ化されたメッセージの形式でコマンドを提供するように構成され、メッセージのパラメータは、例えば、電源電圧、電源電流、クロック周波数、信号特性、または環境パラメータなどの測定すべき一つ以上の物理量を記述する。

【0144】

パラメータ化されたメッセージを使用することで、上述の利点を達成できる。特に、パラメータ化されたメッセージを使用することにより、検証エンジニアは、どの物理量を測定べきかを記述し、任意選択で、測定の実行時に適用すべき測定設定（例えば、測定範囲、平均化動作、フィルタリング動作など）も記述する一つ以上のパラメータを使用できるため、テストプログラムの記述が検証エンジニアにとって容易になる。また、例えば、測定すべき量（例えば、被試験デバイスの特定ピンにおける特定電圧、または被試験デバイスの特定ピンに流れる特定電流など）を定義しうるパラメータを用いることにより、コマンドセットを小さく維持でき、実際に測定される量をむしろパラメータによって記述できる。これは、非常に「読みやすい」コードを可能にし、被試験デバイスと自動試験機器との間の効率的な通信を可能にする（例えば、オン・チップ・システム・テストコントローラまたはテストプログラム実行器は、そこに記述されたコマンドおよびパラメータを評価してもよい）。さらに、多くの高速インタフェースが典型的にメッセージの伝送に適しているため、メッセージの使用は（例えば、プロトコルベースの）高速インタフェースを介した伝送に特に適していることに留意されたい（ここで、メッセージは、例えば、メッセージヘッダ、メッセージ識別子およびパラメータを備えてもよいメッセージデータペイロード、および任意選択でエラー検出情報またはエラー訂正情報、および任意選択でメッセージターミネータを備えてもよい）。このような十分に定義されたメッセージは、通常、高速インタフェースを介して容易に伝送することができ、被試験デバイスに存在しうる各インタフェースドライバは、メッセージ伝送をサポートできる。このように、非常に効率的な概念が提供される。

【0145】

好ましい実施の形態において、被試験デバイスは、測定結果信号をメッセージの形式で受信するように構成される。前述のように、メッセージは、（例えば、プロトコルベースの）高速インタフェースを介した通信に適しているため、他の機能（例えば、被試験デバイスへのテストケースのアップロードおよび／または被試験デバイスから自動試験機器への試験結果のダウンロード）のためにも共有されうるインタフェースを介して高速通信が可能である。

【0146】

測定結果信号をメッセージの形式で評価することにより、例えば、被試験デバイスに向けて受信情報の解析により、メッセージを検出できる。典型的にメッセージヘッダによって特徴付けられるメッセージが使用されるため、測定結果を通知するメッセージは、例えば、他の受信情報と容易に区別されうる。したがって、メッセージの形式での測定結果信号の受信は、メッセージの解析が適度な労力で達成できるため、非常に有利であることが判明している。

【0147】

好ましい実施の形態において、被試験デバイスは、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、ＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースなどを介して）、自動試験機器へのコマンド（例えば自動試験機器へのメッセージ）を提供するように構成される。代替的または追加的に、被試験デバイスは、（好ましくはプロトコルベースの）高帯域幅インタフェースを介して（例えば、高速インタフェースを介して、例えば、ＵＳＢインタフェース、またはＰＣＩインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓインタフェース、またはＰＣＩ－ｅｘｐｒｅｓｓ準拠インタフェース、またはｔｈｕｎｄｅｒｂｏｌｔインタフェース、またはイーサネットインタフェース、またはＩＥＥＥ－１３９４インタフェース、またはＳＡＴＡインタフェース、またはＩＥＥＥ－１１４９インタフェース、またはＩＥＥＥ－１５００インタフェース、またはＩＥＥＥ－１６８７インタフェースを介して）、測定結果信号（例えば、測定結果メッセージ）を（例えば自動試験機器から）受信するように構成される。

【0148】

このようなインタフェースの使用は、前述のような利点をもたらす。特に、このような高帯域幅インタフェースを介した自動試験機器へのコマンドの提供、および／またははこのような高帯域幅インタフェースを介した測定結果信号の受信は、非常に高速な通信を可能にし、さらに、被試験デバイスへのテストケースの更新または自動試験機器への試験結果データの提供などの他の目的にも通常使用される当該高帯域幅インタフェースを流用を可能にする。さらに、高帯域幅インタフェースは、通常、他のペイロードに加えて、測定関連情報（例えば、測定を要求するコマンドおよび測定結果信号）を伝送するのに十分な帯域幅を有する。さらに、高帯域幅インタフェースは、多くの場合、異なる種類のペイロードを混在させる（例えば、ショートメッセージを他のデータ通信プロセスに割り込ませる）ことが可能である。その結果、被試験デバイスの利用可能なリソースを効率的に使用することが可能である。さらに、インタフェースの高帯域幅特性は、典型的に、レイテンシを比較的小さくし、測定のトリガ実行にも有利であり、テスト時間の短縮化に役立つ。

【0149】

好ましい実施の形態において、被試験デバイスは、コマンドを提供するために、および／または測定結果信号を評価するために、（例えば、自動試験機器によって提供されるソフトウェアライブラリの）一つ以上のライブラリルーチンを使用するように構成される（その使用は、例えば、自動試験機器によって提供されるアプリケーション・プログラミング・インタフェースによって可能になってもよい）。

【0150】

コマンドを提供するために、および／または測定結果信号を評価するために一つ以上のライブラリルーチンを使用することは、上記で議論した利点をもたらし、被試験デバイス上で実行されるべきテストケースの開発を著しく容易にする。また、エラーリスクも低減される。

【0151】

好ましい実施の形態において、被試験デバイスは、測定結果信号によって示される測定結果に依存して（例えば、測定結果に依存して選択的に分岐することによって）テストケースの実行を継続するように構成される。

【0152】

したがって、テストケースの実行を実際の測定結果に依存させることができ、例えば、被試験デバイスの最大定格の識別に役立てられてもよい。例えば、特定のテストケースにおいて被試験デバイスの電流消費や加熱が過大となった場合、後続の試験は、被試験デバイスに過度なストレスが回避するために処理負荷を軽減した状態で実行されてもよい。このように、被試験デバイス、すなわち、被試験デバイス上で実行されるテストケースは、測定結果を効率的に考慮することができ、したがってテストケースの実行を適合させることができる。

【0153】

本発明に係る実施の形態は、試験機器構成（テストセットアップ）を生成する。試験機器構成は、前述した自動試験機器と、前述した被試験デバイスとを備える。試験機器構成は、前述した自動試験機器および前述した被試験デバイスと同様の考察に基づく。試験機器構成は、自動試験機器に関しておよび被試験デバイスに関して、本書に開示された任意の特徴、機能および詳細によって任意選択に補足されてもよい。試験機器構成は、これらの特徴または機能または詳細によって、個別にまたは組み合わせて任意選択で補足されてもよい。

【0154】

本発明に係る一実施の形態は、自動試験機器を動作させる方法を生成する。この方法は、被試験デバイスから、一つ以上の物理量の測定を要求するコマンドを（例えば、メッセージの形式で）を受信することを備える。この方法は、被試験デバイスから提供されたコマンドに応答して、一つ以上の物理量の測定を実行または開始することをさらに備える。さらに、この方法は、被試験デバイスに測定結果信号（例えば、測定結果メッセージ）を提供し、被試験デバイスによって要求された測定結果を通知することを備える。この方法は、上述した自動試験機器と同様の考察に基づく。さらに、この方法は、自動試験機器に関して、本書に開示された任意の特徴、機能および詳細によって任意選択で補足されてもよい。この方法は、そのような特徴、機能および詳細によって、個別にまたは組み合わせて補足されてもよい。

【0155】

本発明に係る一実施の形態は、被試験デバイスを試験する方法を生成する。この方法は、被試験デバイスから、被試験デバイス上で実行されるテストケースの制御下にある自動試験機器に、一つ以上の物理量の測定を要求するコマンドを（例えば、メッセージの形式で）提供することを備える。さらに、この方法は、被試験デバイスによって要求された測定結果を示す測定結果信号（例えば、測定結果信号または測定結果メッセージ）が被試験デバイスによって受信されるまで（かつ、例えばテストケースによって検出されるまで）、テストケースの実行を（例えば、テストケースの制御下で）一時停止することを備える。さらに、この方法は、被試験デバイスによって提供されたコマンドに応答して、一つ以上の物理量の測定を実行することを備える。さらに、この方法は、被試験デバイスに測定結果信号（例えば、測定結果メッセージ）を提供し、被試験デバイスによって要求された測定結果を通知することを備える。さらに、この方法は、被試験デバイスによる測定結果信号の受信に応答して、テストケースの実行を継続することを備える。

【0156】

この方法は、上述の自動試験機器および上述の被試験デバイスと同様の考察に基づく。この方法は、自動試験機器に関して、および被試験デバイスに関して本書に開示された任意の特徴、機能および詳細によって任意選択に補足されてもよい。この方法は、そのような特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよい。

【0157】

本発明に係る別の実施の形態は、このような方法を実行するコンピュータプログラムを生成する。

【0158】

本発明に係るさらに別の実施の形態は、一つ以上の被試験デバイスを試験するための自動試験機器を生成する。自動試験機器は、テストケースから、（例えば被試験デバイスに供給される供給電圧の、例えば被試験デバイスに供給される電流の、例えば被試験デバイスによって供給される信号の信号特性の、例えば被試験デバイスに供給される信号の信号特性の、例えば被試験デバイスに供給されるクロック信号のクロック周波数の、例えば被試験デバイスの環境における温度、湿度、気圧、電界または磁界などの環境パラメータなどの）一つ以上の物理量の測定を要求するコマンドを（例えば、メッセージの形式で）受信するように構成される。さらに、自動試験機器は、テストケースによって提供されるコマンドに応答して、一つ以上の物理量の測定を実行または開始するように構成される。さらに、自動試験機器は、測定結果信号（例えば、確認応答メッセージ）をテストケースに提供し、測定結果をテストケースに通知するように構成される。

【0159】

この自動試験機器は、上述した自動試験機器と同様の考察に基づいており、テストケースが自動試験機器の役割を引き受けている。しかしながら、テストケースは、好ましくは被試験デバイス上で実行されてもよいが、被試験デバイスと自動試験機器との間で分配されてもよいことに留意されたい。さらに、この自動試験機器は、他の自動試験機器に関して本書に開示された任意の特徴、機能および詳細によって任意選択で補足されてもよい。自動試験機器は、そのような特徴、機能および詳細によって、個別にまたは組み合わせて補足されてもよい。

【0160】

本発明に係る別の実施の形態は、自動試験機器を動作させる方法を生成する。この方法は、テストケース（例えば、被試験デバイス上で実行されてもよいが、被試験デバイスと自動試験機器との間で分配されてもよい）から、一つ以上の物理量の測定を要求するコマンドを（例えば、メッセージの形式で）を受信することを備える。この方法は、テストケースによって提供されたコマンドに応答して、一つ以上の物理量の測定を実行または開始することをさらに備える。さらに、この方法は、測定結果信号（例えば、測定結果メッセージ）をテストケースに提供し、テストケースによって要求された測定結果を通知することを備える。

【0161】

この方法は、上述の方法と同様の考察に基づいており、テストケースが被試験デバイスの代わりとなる。この方法は、任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよい。

【0162】

本発明に係るさらに別の実施の形態は、それぞれのコンピュータプログラムを生成する。

【図面の簡単な説明】

【0163】

本発明に係る実施の形態は、以下の添付の図面を参照して後述される。

【図1a】本発明の一実施の形態に係る自動試験機器の概略図を示す。

【図1b】本発明の一実施の形態に係る被試験デバイスの概略図を示す。

【図2a】本発明の一実施の形態に係る自動試験機器の概略図を示す。

【図2b】本発明の一実施の形態に係る被試験デバイスの概略図を示す。

【図2c】本発明の一実施の形態に係る自動試験機器の概略図を示す。

【図3a】本発明の一実施の形態に係る自動試験機器の概略図を示す。

【図3b】本発明の一実施の形態に係る被試験デバイスの概略図を示す。

【図4】テストパターンによるオン・チップ・システム・テスト（ＯＣＳＴ）／機能テストのアップロードおよび制御の概略図を示す。

【図5】高速入出力（ＩＯ）によるオン・チップ・システム・テスト（ＯＣＳＴ）／機能テストのアップロードおよび制御の概略図を示す。

【図6】ＯＣＳＴ／機能テスト用に別個のコントローラを使用する変形例の概略図を示す。

【図7】本発明の一実施の形態に係る、テスタリソース制御経路によって拡張されたオン・チップ・システム・テスト（ＯＣＳＴ）の概略図を示す。

【図8】本発明の一実施の形態に係る、テスタリソース制御経路を含めるためのＯＣＳＴコントローラを含む変形例の概略図を示す。

【図9】本発明の一実施の形態に係る、テスタリソース制御のメッセージフローの概略図を示す。

【図10】本発明の一実施の形態に係る、テスタリソース測定経路によって拡張されたＯＣＳＴの概略図を示す。

【図11】本発明の一実施の形態に係る、テスタリソース制御経路を含めるためのＯＣＳＴコントローラを含む変形例の概略図を示す。

【図12】本発明の一実施の形態に係る、テスタリソース測定のメッセージフローの概略図を示す。

【図13】本発明の一実施の形態に係る、オン・チップ・システム・テストによって制御される生産テスタの概略図を示す。

【図14】本発明の一実施の形態に係る、オン・チップ・システム・テストによって制御される生産テスタの概略図を示す。

【図15】本発明の一実施の形態に係る、機能テストケースがＤＵＴ上に完全に配置されるシナリオの概略図を示す。

【図16】本発明の一実施の形態に係る、機能テストケースがＤＵＴ上に完全に配置されるシナリオの概略図を示す。

【図17】本発明の一実施の形態に係る、ライブラリサポートＡＴＥ環境制御を備えるコンセプトの概略図を示す。

【図18】本発明の一実施の形態に係る、データバスおよび同期バスによって制御されるリソースの概略図を示す。

【図19】本発明の一実施の形態に係る、ＧＰＯトリガによって制御されるテスタリソースの概略図を示す。

【発明を実施するための形態】

【0164】

１．図１ａに係る自動試験機器

【0165】

図１ａは、本発明の一実施の形態に係る自動試験機器の概略図を示す。図１ａに示される自動試験機器は、１００で指定される。自動試験機器は、通常、被試験デバイス１１０と結合されることが意図される。自動試験機器１００は、被試験デバイス１１０から（すなわち、テストケースから）、一つ以上のテスタリソースの更新を要求するコマンド１２２を受信するように構成される。さらに、自動試験機器は、被試験デバイス１１０から提供されたコマンド１２２に応答して、一つ以上のテスタリソースを更新するように構成される。さらに、自動試験機器は、確認応答信号１２４を提供し、被試験デバイス１１０によって要求されたテストリソース更新の完了を通知するように構成される。

【0166】

したがって、自動試験機器１００は、一つ以上のテスタリソースの更新を要求するコマンド１２２を提供することによって、被試験デバイス１１０が一つ以上のテスタリソースに対する制御を行使することを可能にする。したがって、被試験デバイス１１０は、自動試験機器にテスタリソースのパラメータを変更させるコマンドを発行することができ、例えば、被試験デバイス１１０の要求で、被試験デバイス１１０の供給電圧を変更させる、または被試験デバイス１１０に供給される別の信号の特性を変更させる。さらに、自動試験機器１００は、被試験デバイス１１０が一つ以上のテストリソースの更新の実行について十分に知らされるように、確認応答信号１２４を被試験デバイスに提供することもできる。したがって、被試験デバイス１１０は、確認応答信号１２４を使用して、適切な実行のために一つ以上のテスタリソースの要求された更新を必要としうるテスト実行をいつ継続するかを決定できる。したがって、被試験デバイスの制御下で、信頼性の高い試験を実施できる。

【0167】

さらに、被試験デバイス２００は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0168】

２．図１ｂに係る被試験デバイス

【0169】

図１ｂは、本発明の一実施の形態に係る被試験デバイス２００の概略図を示す。被試験デバイス２００は、例えば、テストケースを実行するように構成されてもよい。したがって、被試験デバイス２００は、一つ以上のテスタリソースの更新を要求するコマンド２１２を（例えば、メッセージの形式で）（例えば、自動試験機器に）提供するよう構成されてもよい。当該コマンド２１２の提供は、例えば、被試験デバイス上で実行されるテストケースの制御下に置かれてもよい。このコマンド２１２の生成は、例えば、コマンドを生成するための機能を定義し、ユーザフレンドリーな方法でコマンドの生成を可能にしうるライブラリルーチンを使用して、被試験デバイス２００において実行されてもよい。

【0170】

さらに、被試験デバイスは、テスタリソース更新の完了を示す確認応答信号２１４を受信するように構成される。さらに、被試験デバイスは、被試験デバイスによって要求されたテスタリソース更新の完了を示す確認応答信号２１４（例えば、確認応答メッセージ）が被試験デバイスによって受信されるまで、テストケースの実行を一時停止するように構成される。この目的のために、被試験デバイス２００は、例えば、ライブラリルーチンを使用して、確認応答メッセージを評価するように構成されてもよい。例えば、ライブラリルーチンは、確認応答信号２１４を検出または評価するための関数を定義してもよく、また、例えば、確認応答信号が受信（または検出）されるまでテストケースの実行を一時停止する機能をユーザフレンドリーな方法で提供することも可能である。

【0171】

したがって、被試験デバイスは、自動試験機器（例えば、自動試験機器１００）に一つ以上のテスタリソースを更新するように指示することができ、被試験デバイス２００は、例えば、確認応答信号２１４が受信されるまでテストケースの実行を一時停止することにより、テストケースの実行を一つ以上のテスタリソースの更新の完了と同期させてもよい。その結果、被試験デバイス２００（すなわち、被試験デバイス上で実行されるテストケース）は、被試験デバイス２００が動作するテスト環境の更新を要求することができ、確認信号を受信するまでテストケースの実行を一時停止することによって、一つ以上のテストリソースが更新されたときにのみテストケースの実行を確実に継続させることもできる。その結果、被試験デバイスの制御下で試験の大部分を行うことができ、テスタリソースの更新の完了を示す確認応答信号の評価により、試験の信頼性を高めることができる。

【0172】

さらに、被試験デバイス２００は、ここで説明した任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0173】

３．図２に係る自動試験機器

【0174】

図２は、本発明の一実施の形態に係る自動試験機器２４０の概略図を示す。自動試験機器２４０は、被試験デバイス２４２（すなわち、例えば被試験デバイス２４２上で実行されうるテストケース）によって制御可能なトリガライン２５０（例えばハードウェアトリガライン、例えばＧＰＯトリガライン）を備える。例えば、トリガラインは、被試験デバイスの汎用出力によって制御可能であってよく、例えば、単一のエッジに反応してもよい。さらに、自動試験機器は、被試験デバイス２４２による（すなわち、例えば、被試験デバイス上で実行されうるテストケースによる）トリガライン２５０の（例えば、状態の単一／単純な切替（トグリング）の意味における）アクティブ化に応答して、一つ以上のテスタリソースを更新する（例えば、自動試験機器によって被試験デバイス２４２に提供される一つ以上の供給電圧を変更する、または自動試験機器によって被試験デバイス２４２に提供される一つ以上のアナログまたはデジタル信号の一つ以上の信号特性を変更する）ように構成される。

【0175】

したがって、自動試験機器２４０は、（例えば、トリガライン上の単一エッジまたは単一パルスの生成という意味において）トリガライン２５０の（単純な）アクティブ化によって一つ以上のテスタリソースの更新を被試験デバイス２４２がトリガすることを可能にしうる。したがって、自動試験機器２４０は、一つ以上のテスタリソースの更新のトリガが被試験デバイス２４２による直接的な影響を受けることができ、したがって、自動試験機器のテストプログラム実行器および／または自動試験機器２４０のオン・チップ・システム・テストコントローラ内に存在しうるレイテンシによる影響を受けないので、一つ以上のテストリソースの更新に対する非常に正確な時間制御を被試験デバイス２４０に与える。したがって、自動試験機器２４０は、被試験デバイス２４２によって直接的に制御できる非常に高いタイミング精度を可能にする。したがって、被試験デバイス２４２は、被試験デバイスによって非常によく制御可能となるタイミングで、一つ以上のテスタリソースの更新をトリガできる。その結果、被試験デバイスは、実際のテスタリソースの典型的に低いレイテンシだけを考慮すればよく、自動試験機器のテストプログラム実行器の（典型的には非決定性の）レイテンシ、および／または自動試験機器のオン・チップ・テストコントローラのレイテンシ、および／またはプロトコルベース通信のレイテンシを考慮しなくてよいため、トリガラインのアクティブ化後に試験の実行（例えばテストケースの実行）を迅速に継続できる。

【0176】

その結果、被試験デバイス（したがって、被試験デバイス上で通常実行されるテストケース）によって十分に制御可能な、特に高速な試験を達成できる。また、（ＡＴＥ側で）トリガラインを提供することにより、被試験デバイスは、トリガラインに結合される単一のピンをアクティブ化（またはトグル）するだけでよく、これは、典型的に非常に低いソフトウェア労力で可能であり、被試験デバイスの単一のピンを使用するだけでよい。その結果、自動試験機器２４０は、自動試験機器に一つ以上のテスタリソースを更新させることによって、自身のテスト環境を制御可能な被試験デバイスの試験に対して非常に優れたサポートを提供する。

【0177】

さらに、自動試験機器２４０は、本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0178】

４．図２ｂに係る被試験デバイス

【0179】

図２ｂは、本発明の一実施の形態に係る被試験デバイス２６０の概略図を示す。被試験デバイス２６０は、例えば、テストケース２６２を実行するように構成されてもよい。さらに、被試験デバイス２６０は、トリガ信号２６４を（例えば、自動試験機器に）提供し、専用のトリガラインを介して一つ以上のテスタリソースの更新をトリガするように構成される。この点に関して、被試験デバイス２６０は、例えば被試験デバイス２４２に対応してもよく、トリガ信号２６４は、例えばトリガライン２５０に提供されてもよいことに留意されたい。

【0180】

さらに、被試験デバイスは、例えば、被試験デバイスによって実行されるテストケース２６２の制御下に置かれてもよいことに留意されたい。さらに、任意選択で、被試験デバイス２６０は、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンド２６６を提供するように構成されてもよいことに留意されたい。したがって、被試験デバイス２６０は、トリガ信号２６４のアクティブ化の前に、トリガ信号のアクティブ化に応答してどの新しいパラメータを一つ以上のテスタリソースのそれぞれに設定すべきかを定義することによって、一つ以上のテストリソースの更新のために自動試験機器（または自動試験機器のテスタリソース）を準備してもよい。したがって、被試験デバイスは、その試験環境に対して非常に高い制御を行うことができる。任意選択で、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンド２６６を提供することによって、被試験デバイスは、一つ以上のテスタリソースの更新に関する詳細を決定できる。さらに、トリガ信号２６６のアクティブ化によって、被試験デバイスは、一つ以上のテスタリソースの更新がいつ実行されるべきかを非常に高いタイミング精度で決定できる。その結果、被試験デバイス２６０は、自動試験機器と同期するための同期オーバーヘッドを比較的小さくして、例えば、試験の大部分を高いタイミング精度で制御し、したがって、試験を迅速に実行しうる。

【0181】

さらに、被試験デバイス２６０は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0182】

５．図２ｃに係る自動試験機器

【0183】

図２ｃは、本発明の一実施の形態に係る自動試験機器２８０の概略図を示す。自動試験機器２８０は、テストプログラム２８４を実行するように構成されるテストプログラム実行器２８２を備える。さらに、自動試験機器２８０は、システム・オン・チップの試験をサポートするように構成されうるオン・チップ・システム・テストコントローラ２８６も備える。さらに、自動試験機器２８０は、複数のテスタリソース２８８ａ、２８８ｂ、２２８ｃを備える。例えば、テスタリソース２８８ａ～２８８ｃは、デバイス電源および／またはデジタルチャネルモジュール（またはデジタル信号モジュール）および／またはアナログチャネルモジュール（またはアナログ信号モジュール）および／または信号発生器モジュールを備えてもよい。例えば、テスタリソース２８８ａ、２８８ｂ、２８８ｃのうちの一つ以上は、例えば、各テスタリソースの更新としても指定される各テスタリソースの設定の変更を生じさせうる、トリガ機構２８９ｃを備えてもよい。例えば、テストプログラム実行器２８２は、インタフェースを介してテスタリソース２８８ａ、２８８ｂ、２８８ｃに結合されてもよく、例えば、一つ以上のテスタリソースをプログラムしてもよい。例えば、テストプログラム実行器は、テスタリソース２８８ａ、２８８ｂ、２８８ｃの一つ以上のパラメータを設定することができ、また例えば、トリガ機構と（例えば、トリガ機構２８９ｃと）結合されうるトリガラインのアクティブ化に応答して一つ以上のテスタリソースが示す動作を予めプログラムするよう構成されてもよい。さらに、自動試験機器は、被試験デバイスインタフェース２９０を含んでもよく、一つ以上のテスタリソースの信号２９２ａ、２９２ｂ、２９２ｃは、被試験デバイスインタフェース２９０を介して被試験デバイスに提供されてもよい。さらに、被試験デバイスインタフェースは、（例えば、被試験デバイスインタフェース２９０の一部として）トリガ入力２９４を有してもよく、このトリガ入力は、被試験デバイスからトリガ信号を受信するように構成されてもよく、例えば、一つ以上のテスタリソース２８８ａ～２８８ｃのトリガ機構と直接結合されうるトリガライン２９５に結合されてもよい。例えば、図２ｃは、トリガライン２９５がテスタリソース２８８ｃのトリガ機構２８９ｃに結合されていることを示すが、他のテスタリソース２８８ａ、２８８ｂもそれぞれのトリガ機構を備えてもよい。

【0184】

さらに、自動試験機器２８０は、被試験デバイスインタフェース２９０を介して、一つ以上のテスタリソースの更新のための一つ以上のパラメータを定義するコマンド２９６を受信するように構成されてもよい。このコマンド２９６は、好ましくは、被試験デバイスから受信しうるが、一般的には、このコマンドは、（被試験デバイス上で実行されうる、また、被試験デバイス上および自動試験機器上で部分的に実行されうる）テストケースから受信してもよい。当該コマンド２９６は、例えば、オン・チップ・システム・テストコントローラ２８６によって受信されてもよく、または、テストプログラム実行器２８２によって受信されてもよい。いくつかの構成において、当該コマンド２９６は、最初にオンチップ・システム・テストコントローラ２８６によって受信されてもよく、その後、オンチップ・システム・テストコントローラ２８６からテストプログラム実行器２８２に（その元の形式で、または修正された形式で）転送されてもよい。テストプログラム実行器２８２は、例えば、コマンドに応答して一つ以上のテスタリソース２８８ａ、２８８ｂ、２８８ｃを事前構成してもよい。

【0185】

したがって、一つ以上のテストリソースの更新のための一つ以上のパラメータを定義するコマンド２９６に応答して事前構成される一つ以上のテストリソースは、その後、一つ以上のパラメータの変更を伴う被試験デバイスによるトリガライン２９５のアクティブ化に応答してもよく、当該変更（例えば変更後に使用される一つ以上の新しいパラメータ）は、例えば事前構成によって定義され。その結果、一つ以上のテスタリソースは、トリガラインのアクティブ化に対して非常に速く反応してもよく、一つ以上のテスタリソースの実際の更新が望まれる時点で、一つ以上のテストリソース２８８ａ～２８８ｃに追加の情報を提供する必要がなくてもよい。その結果、被試験デバイスは、一つ以上のテスタリソースの構成に対して非常に高速な制御を実施できる。

【0186】

さらに、一つ以上のテストリソースの更新のための一つ以上のパラメータを定義するコマンドは、代替的にテストケースから受信されてもよいことに留意されたい。このようなコマンドは、２９８で指定される。テストケースからのコマンドは、オンチップシステムテストコントローラ２８６またはテストプログラム実行器２８２に向けられてもよい。この問題に関して、テストケースは、例えば、被試験デバイス上でのみ実行されてもよく、テストケースは、代替的に、被試験デバイス上で部分的に実行され、自動試験機器上で部分的に実行されてもよいことに留意されたい。しかしながら、コマンド２９８は、一つ以上のテスタリソースの事前構成に影響を与えることによって、トリガラインのアクティブ化に対する一つ以上のテスタリソースの反応を定義しうる一方で、トリガ信号は依然として、例えば入力２９４を介して被試験デバイスから受信されてもよい。

【0187】

結論として、自動試験機器２８０は、単なるトリガラインのアクティブ化による、非常に簡単な方法で、被試験デバイスに提供される一つ以上の信号の信号特性の変化を生じさせる（またはトリガする）可能性を被試験デバイスに提供し、典型的に非常に小さなレイテンシを被試験デバイスに提供する。

【0188】

さらに、自動試験機器２８０は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0189】

６．図３ａに係る自動試験機器

【0190】

図３ａは、本発明の一実施の形態に係る自動試験機器３００の概略図を示す。自動試験機器３００は、自動試験機器に結合されうる被試験デバイス３１０を試験するように構成される。例えば、自動試験機器は、被試験デバイス３１０から、（例えば被試験デバイスに供給される供給電圧の、例えば被試験デバイスに供給される電流の、例えば被試験デバイスによって供給される信号の信号特性の、例えば被試験デバイスに供給される信号の信号特性の、例えば被試験デバイスに供給されるクロック信号のクロック周波数の、例えば被試験デバイスの環境における温度、湿度、気圧、電界または磁界などの環境パラメータなどの）一つ以上の物理量の測定を要求するコマンド３２２を（例えば、メッセージの形式で）を受信するように構成される。さらに、自動試験機器は、被試験デバイスに提供されるコマンドに応答して、一つ以上の物理量の測定を実行または開始するように構成される。

【0191】

例えば、自動試験機器は、自動試験機器の一つ以上の内部測定リソースに、コマンドで指定された一つ以上の物理量の測定を行わせて（またはトリガして）もよい。例えば、自動試験機器の一つ以上のチャネルモジュールの測定機能を使用して測定を行ってもよい。しかしながら、代替的に、自動試験機器は、一つ以上の外部測定リソース（例えば、外部精密測定機器または外部高周波測定機器、または外部光学測定機器など）を制御して、要求された測定を行ってもよい。さらに、自動試験機器は、被試験デバイス３１０に測定結果信号３２４（例えば、確認応答メッセージまたは測定結果を備えるメッセージ）を提供して、被試験デバイスによって要求された測定結果を通知するように構成される。

【0192】

したがって、自動試験機器３００は、例えば、自動試験機器によって実行（または開始）されるべき測定を被試験デバイス３１０がトリガすることを可能にし、例えば、被試験デバイス上で実行されるテストケースが、テストケースの実行のどの時点でどの測定が行われるかを定義しうるようにする。その結果、テストケースの実行中に自動試験機器によって実行される活動の大部分がテストケース自体で定義できるため、被試験デバイスの制御下で測定を行うことができ、試験開発が著しく容易になる。

【0193】

さらに、測定結果を被試験デバイスに通知し、測定が完了したことも被試験デバイスに示しうる測定結果信号を提供することにより、被試験デバイスは、測定結果の利用が可能になる。例えば、被試験デバイスは、測定結果を利用して、測定結果に依存するテストケースのさらなる実行について決定してもよい。他の例として、被試験デバイス３１０は、測定結果を利用して試験結果情報を生成してもよい。結論として、自動試験機器３００は、被試験デバイスに測定を要求させ、また、測定結果を被試験デバイスに転送させる。したがって、試験またはテストケースは、大部分が被試験デバイスの制御下で実行されてもよく、これは、テストケースの生成を著しく容易にし、テストケース実行の制御のために測定結果さえ利用しうる、非常に強力かつ効率的なテストケースの定義を可能にする。

【0194】

さらに、自動試験機器３００は、本書に開示される任意の特徴、機能および詳細のいずれかによって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0195】

７．図３ｂに係る被試験デバイス

【0196】

図３ｂは、本発明の一実施の形態に係る被試験デバイス３５０の概略図を示す。被試験デバイス３５０は、（例えば、被試験デバイス上で実行されるテストケースの制御下で）一つ以上の物理量の測定を要求するコマンド３１２を（例えば、メッセージの形式で）自動試験機器に提供するように構成される。さらに、被試験デバイス３５０は、（例えば、被試験デバイスによって要求された測定結果が受信されるまでテストケースの実行を一時停止することによって）、被試験デバイスによって要求された測定結果を示す測定結果信号３１４（例えば、測定結果メッセージ）の受信を待つように構成される。

【0197】

したがって、被試験デバイス３５０は、自動試験機器（または自動試験機器に結合される外部測定機器）によって測定の実行を開始させることも、被試験デバイスが測定結果を受信して被試験デバイス上でのテストケースの実行を測定に同期させることも可能である。例えば、測定結果信号３１４は、測定結果信号３１４が被試験デバイスによって受信されたときに被試験デバイス３５０がテストケースの実行を継続できるように、測定が完了したことを示してもよい。結果として、被試験デバイス３５０は、測定が完了する前に（例えば、新たなテストステップを用いた）テストケースの実行が継続されないことを確保でき、測定結果の偽造の回避に役立つ。さらに、被試験デバイス（または、被試験デバイス上で実行されるテストケース）は、例えば、テストケースをさらにどのように実行するかの判断のために、測定結果を考慮できる。したがって、被試験デバイス３５０は、被試験デバイス上で実行されるテストケースが被試験デバイス上で実行される処理動作を決定し、また自動試験機器によって行われるべき測定を決定しうるため、試験に対して大幅な制御性を有する。ここで、一つ以上の物理量の測定を要求するコマンドを提供し、自動試験機器からの測定結果信号の受信を待機するための上述の機構は、被試験デバイス上で実行されるテストケースと自動試験機器によって行われるべき測定との間の良好な時間的同期を可能にする。

【0198】

さらに、被試験デバイス３５０は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0199】

８．図７に係る測定構成

【0200】

図７は、本発明の一実施の形態に係る測定構成７００の概略図を示す。測定構成７００は、自動試験機器７１０および被試験デバイス７３０を備える。自動試験機器７１０は、テスタリソース７２０と、ＡＴＥテストプログラム７２４を実行するように適合されうるワークステーション７２２と、を備える。被試験デバイス７３０は、ＯＣＳＴテストケース７４０を実行するように構成されてもよい。

【0201】

自動試験機器７１０のテスタリソース７２０は、例えば、一つ以上のデジタルチャネル（またはデジタルチャネルモジュール）、および／または一つ以上のアナログチャネル（またはチャネルモジュール）、および／または一つ以上の電源（例えば、デバイス電源）を備えてもよい。したがって、テスタリソース７２０は、被試験デバイス７３０と結合されてもよい。例えば、テスタリソース７２０の一つ以上のデジタルチャネルは、被試験デバイス７３０のデジタルピン（例えば、デジタル入力またはデジタル出力またはデジタル入出力）と結合されてもよい。代替的または追加的に、テスタリソース７２０の一つ以上のアナログチャネルは、被試験デバイス７３０の一つ以上のアナログピン（例えば、アナログ入力またはアナログ出力またはアナログ入出力）と結合されてもよい。代替的または追加的に、テスタリソース７２０のうちの一つ以上の電源またはデバイス電源と結合されうる一つ以上の供給ラインは、被試験デバイス７３０と結合されてもよい（例えば、被試験デバイス７３０の供給ピンまたは供給パッドと結合される）。したがって、アナログ信号および／またはデジタル信号は、各テスタリソースによって被試験デバイス７３０に提供されてもよい。さらに、一つ以上の供給電圧および／または供給電流は、各テスタリソースによって被試験デバイス７３０に提供されてもよい。一般的に、テスタリソース７２０と被試験デバイス７３０との間の結合は、ＤＵＴ供給、試験相互作用および測定のためのＡＴＥ制御信号に使用されてもよい。特に、テスタリソース７２０と被試験デバイス７３０との間の結合は、例えば、双方向であってよいことに留意されたい。例えば、一つ以上のデジタル信号および／または一つ以上のアナログ信号は、各テスタリソースを使用して被試験デバイス７３０に提供されてもよい。代替的または追加的に、一つ以上のデジタル信号および／または一つ以上のアナログ信号は、被試験デバイス７３０によって提供されてもよく、各テスタリソース７２０によって受信（および典型的には評価）されてもよい。例えば、テスタリソース７２０は、被試験デバイス７３０に対して一つ以上のデジタルおよび／またはアナログ刺激信号を提供してもよく、任意選択で被試験デバイスの一つ以上のデジタルおよび／またはアナログ応答信号を評価してもよい。被試験デバイス７３０がシステム・オン・チップを備える場合、テスタリソース７２０は、例えば、このシステム・オン・チップを初期化するために使用されてもよく、または、例えば、被試験デバイス７３０の安全な起動を可能にする適切な信号を適用してもよい。さらに、テストリソース７２０は、例えば、被試験デバイス７３０上でのテストケース７４０の実行を準備するために、（例えば、被試験デバイスのＪＴＡＧポートなどを用いた）被試験デバイスへのテストプログラムおよび／または基本オペレーティングシステムのアップロードに用いられてもよい。

【0202】

さらに、被試験デバイス７３０は、例えばオン・チップ・システム・テスト・テストケースアップロード（ＯＣＳＴ－ＴＣアップロード）および実行制御を可能にするために、自動試験機器と結合されてもよい。例えば、自動試験機器７００は、ＡＴＥテストプログラム７２４とＯＣＳＴテストケース７４０との間（または、より一般的には、ワークステーション７２２と被試験デバイス７３０との間）の通信を可能にするように適合されてもよい。例えば、高速入出力（ＨＳＩＯ）（例えば高速インタフェース）は、自動試験機器と被試験デバイスとの間の通信のために使用されてもよい（例えば、ＡＴＥテストプログラムとＯＣＳＴテストケースとの間の通信のために、またはＡＴＥテストプログラムと被試験デバイス７３０上で実行される制御ソフトウェアとの間の通信のために使用されてもよく、当該制御ソフトウェアは、例えば、一つ以上のテストケースのアップロードを可能にする機能および一つ以上のテストケースの実行の制御を可能にする機能を有してもよい）。例えば、ＨＳＩＯは、ＵＳＢインタフェースおよび／またはＰＣＩｅインタフェース、またはイーサネットインタフェース（ＥＴＨ）、または任意の他の種類の高速インタフェースを備えてもよい。結論として、一般的に、ＯＣＳＴ－ＴＣアップロードおよび実行制御は、自動試験機器と被試験デバイスとの間の高速インタフェース（または高帯域幅インタフェース、または高データレートインタフェース）を使用して実行されてもよい。

【0203】

さらに、ＡＴＥおよび被試験デバイスは、ＯＣＳＴテストケース７４０によるリソースの更新の要求を可能にするように構成されてもよい。例えば、ＯＣＳＴテストケース７４０は、ＡＴＥテストプログラム７２４から、例えば、パラメータ化されたメッセージを使用して、リソース更新を要求してもよい。さらに、ＡＴＥテストプログラム７２４は、ＯＣＳＴテストケース７４０に確認応答を（例えば確認応答メッセージの形式で、または確認応答信号の形式で）提供してもよい。したがって、ＯＣＳＴテストケース７４０とＡＴＥテストプログラム７２４との間には、例えば、リソース更新要求メッセージ７５０（リソース更新要求メッセージとも指定される）および確認応答メッセージ７５２（確認応答メッセージとも指定される）を用いたメッセージ交換が存在してもよい。例えば、リソース更新要求メッセージ７５０および確認応答メッセージ７５２を含むメッセージ交換は、ＨＳＩＯを介したテスタリソース制御のために使用されてもよい。別の言い方をすれば、リソース更新要求メッセージ７５０と確認応答メッセージ７５２は、例えば、ＨＳＩＯを使用してＯＣＳＴテストケース７４０とＡＴＥテストプログラム７２４との間で交換されてもよい。例えば、リソース更新要求メッセージ７５０と確認応答メッセージ７５２を備えるメッセージ交換は、ＯＣＳＴテストケースのアップロードおよび実行制御にも使用される同じＨＳＩＯを使用してもよい。

【0204】

したがって、ＯＣＳＴテストケース７４０は、リソース更新要求メッセージ７５０を用いてリソース更新を要求することにより、被試験デバイスに対してテストルーチンを実行する機能を有するとともに、ＤＵＴの試験環境の変更を要求する機能を有する。さらに、ＯＣＳＴテストケース７４０は、確認応答メッセージ７５２も受信し、この確認応答メッセージをタイミング同期のために使用できる。

【0205】

例えば、リソース更新要求メッセージ７５０は、テストリソース７２０の一つのパラメータの変更（または更新）を要求してもよい。単なる一例として、ＯＣＳＴテストケース７４０は、テスタリソース７２０の一部であるデバイス電源の設定を変更することにより、被試験デバイス７３０に供給される電源電圧の変更を要求してもよい。さらに、ＡＴＥテストプログラムは、リソース更新の完了を通知する確認応答メッセージ７５２をＯＣＳＴテストケース７４０（または、一般的には被試験デバイス７３０）に提供し、ＯＣＳＴテストケース７４０は、確認応答メッセージ７５２の受信後に新たなテストステップの実行を継続してもよい。したがって、ＯＣＳＴテストケースは、要求された適切な試験条件が、試験（または新たなテストステップ）に対して存在することを確認できる。

【0206】

結論として、図７に係る試験構成７００は、試験実行の制御をＯＣＳＴテストケースによってかなりの程度まで実行できる、非常に効率的な試験を可能にする。

【0207】

さらに、ここで説明されるＡＴＥ自体は、本発明の一実施の形態として考慮されるべきであることに留意されたい。さらに、ここで説明されるような被試験デバイスも、本発明の一実施の形態として考慮されるべきであることに留意されたい。さらに、試験構成、自動試験機器、および被試験デバイスの全ては、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0208】

９．図８に係る試験構成

【0209】

図８は、本発明の一実施の形態に係る試験構成８００の概略図を示す。

【0210】

試験構成８００は、試験構成７００と同様である。したがって、試験構成７００に関する上記の説明を参照されたい。

【0211】

試験構成８００は、自動試験機器８１０および被試験デバイス８３０を備える。自動試験機器８１０は、例えば、上記の説明も適用されるように、テスタリソース７２０に非常に類似したテスタリソース８２０を備える。自動試験機器８１０は、ワークステーション７２２と同様でありうる、ワークステーション８２２も備える。ワークステーション８２２は、様々な機能を引き受けうるＡＴＥテストプログラムを実行するように適合される。例えば、ＡＴＥテストプログラム８２４は、テスタリソース（例えば、テスタリソース８２０）の初期化を実行するように構成されてもよい。例えば、ＡＴＥテストプログラム８２４は、被試験デバイス８３０上でのプログラム実行の開始を可能にするために、テスタリソース８２０を初期化するように構成されてもよい。さらに、ＡＴＥテストプログラム８２４は、例えば、メッセージハンドラを含んでもよい。メッセージハンドラは、例えば、メッセージの変換を実行してもよく、例えば、確認応答メッセージ生成を含んでもよい。さらに、ＡＴＥテストプログラムは、例えば、メッセージハンドラによって評価されたメッセージに応答して、被試験デバイスの制御下で一つ以上のテスタリソース８２０のさらなる更新を生じさせるように構成されてもよい。

【0212】

しかしながら、テスタリソース８２０およびワークステーション８２２に加えて、試験機器８１０は、オン・チップ・システム・テストコントローラ８２６も備え、これは、例えば、被試験デバイス８３０とワークステーション８２２との間に結合されてもよい。例えば、オン・チップ・システム・テストコントローラは、被試験デバイス８３０から、または被試験デバイス８３０上で実行されるＯＣＳＴテストケース８３２から、リソース更新の要求を受信するように構成されてもよい。さらに、オン・チップ・システム・テストコントローラ８２６は、この要求またはコマンドを転送するように構成されてもよい。代替的または追加的に、ＯＳＣＴコントローラ８２６は、例えば、リソース更新のための要求８５０を第１コマンド形式から第２コマンド形式に変換することによって、コマンド変換を実行するように構成されてもよい。例えば、オン・チップ・システム・テストコントローラ８２６は、リソース更新のための要求８６０をワークステーション８２２またはＡＴＥテストプログラム８２４に提供するよう構成されてもよい。例えば、ＯＣＳＴコントローラ８２６は、要求（または要求メッセージ）８５０を修正せずに転送してもよく、要求（または要求メッセージ）８６０が要求（または要求メッセージ）８５０と同一となるようにしてもよい。しかしながら、ＯＣＳＴコントローラ８２６は、変換を実行して、ＯＣＳＴテストケース８３２によって提供されるリソース更新のための要求（または要求メッセージ）８５０を異なる形式に変換し、リソース更新のための要求（または要求メッセージ）８６０の形式がリソース更新のための要求（または要求メッセージ）８５０の形式と異なるようにしてもよい。しかしながら、ＯＣＳＴコントローラ８２６は、例えば、高速インタフェースプロトコルを取り扱ってもよく、例えば、通信プロトコルから要求（または要求メッセージ）８５０を解除（アンラップ）し、解除された要求（または要求メッセージ）をＡＴＥテストプログラム８２４に転送してもよいことに留意されたい。言い換えれば、ＯＣＳＴコントローラは、例えば、通信プロトコルから要求（または要求メッセージ）の表現を抽出し、要求の「プレーン」形式をＡＴＥテストプログラム８２４に提供してもよい。

【0213】

さらに、ＯＣＳＴコントローラ８２６は、ＡＴＥテストプログラム８２４から確認応答情報（または確認応答信号、または確認応答メッセージ）を受信してもよく、この確認応答情報をＯＣＳＴテストケース８３２に転送してもよい。しかしながら、ＯＣＳＴコントローラ８２６は、例えば、ＡＴＥテストプログラム８２４から確認応答情報（例えば、ＯＣＳＴテストケースによって発行された要求に応答して一つ以上のテスタリソースの更新を確認応答する確認応答情報）を受信し、ＯＣＳＴテストケース８３２に転送するための確認応答信号または確認応答メッセージを生成してもよい。例えば、ＡＴＥテストプログラムによってＯＣＳＴコントローラ８２６に提供される確認応答情報は、８６２で指定され、ＯＣＳＴコントローラ８２６によってＯＣＳＴテストケース８３２に提供される確認応答信号または確認応答メッセージは、８５２で指定される。例えば、テスタリソース制御のためのメッセージ交換は、ＨＳＩＯを使用して（例えば、高速インタフェースまたは高帯域幅インタフェースを使用して）実行されてもよい。例えば、ＯＣＳＴコントローラ８２６とＯＣＳＴテストケース８３２との間の通信に高速インタフェースまたは高帯域幅インタフェースが使用されてもよく、ここで、ＯＣＳＴコントローラ８２６は、例えば、そのような高速インタフェースの使用に対するハードウェアサポートを提供してもよい（ここで、高速インタフェースは典型的にプロトコルベースであり、ＯＣＳＴコントローラ８２６は高速インタフェースのプロトコルに対する取り扱いのサポートを備えてもよい）。さらに、被試験デバイス８３０は、典型的に、例えば、ＯＣＳＴテストケース８３２に高速インタフェースへのアクセスを与える専用ハードウェアおよび適切な高速インタフェースドライバなどの、高速インタフェースのサポートを備えてもよい。任意選択で、高速インタフェースは、ＯＣＳＴコントローラ８２６とワークステーション８２２またはＡＴＥテストプログラム８２４との間の通信に使用されてもよい。例えば、ＨＳＩＯは、ＯＣＳＴコントローラ８２６からＡＴＥテストプログラム８２４へのリソース更新要求メッセージ８６０の送信のために、また、ＡＴＥテストプログラム８２４からＯＣＳＴコントローラ８２６への確認応答情報８６２の提供のために使用されてもよい。しかしながら、ＡＴＥテストプログラムとＯＣＳＴコントローラとの間の通信と、ＯＣＳＴコントローラとＯＣＳＴテストケースとの間の通信とに、異なる種類のインタフェースが使用されてもよい。

【0214】

さらに、ＡＴＥテストプログラム８２４は、例えば、ＯＣＳＴテストケースのアップロードおよび／または実行制御のために、ＯＣＳＴコントローラ８２６と通信してもよい。さらに、ＯＣＳＴテストケースアップロードおよび／または実行制御のために、ＯＣＳＴコントローラ８２６とＯＣＳＴテストケース８３２との間の通信があってもよい。例えば、ＡＴＥテストプログラム８２４は、ＡＴＥテストプログラム８２４とＯＣＳＴコントローラ８２６との間の適切なインタフェースを用いて、被試験デバイスにアップロードされるべきＯＣＳＴテストケースをＯＣＳＴコントローラ８２６に提供してもよい。さらに、ＯＣＳＴコントローラ８２６は、ＯＣＳＴコントローラ８２６と被試験デバイス８３０（またはテストケース８３２）との間の適切なインタフェースを用いて、このＯＣＳＴテストケースを被試験デバイスにアップロードしてもよい。同様に、被試験デバイス上での試験の実行を制御するために、ＡＴＥテストプログラム８２４とＯＣＳＴコントローラ８２６との間に通信があってもよい。この通信は、例えば、双方向であってもよい。さらに、テストケースの実行を制御するために、ＯＣＳＴコントローラ８２６とＯＣＳＴテストケース８３２との間にも通信があってもよい。この通信も双方向であってもよい。

【0215】

例えば、ＯＣＳＴテストケースのアップロードおよび実行制御のためのＡＴＥテストプログラム８２４とＯＣＳＴコントローラとの間の通信は、例えばＵＳＢインタフェース、またはＰＣＩｅインタフェース、またはイーサネットインタフェースＥＴＨなどの高速インタフェース（ＨＳＩＯ）を使用して実行されてもよい。さらに、ＯＣＳＴテストケースアップロードおよび実行制御のためのＯＣＳＴコントローラ８２６とＯＣＳＴテストケース８３２との間の通信も、ＵＳＢインタフェース、ＰＣＩｅインタフェース、またはイーサネットインタフェース（ＥＴＨ）などの高速インタフェース（ＨＳＩＯ）を使用して実行されてもよい。

【0216】

しかしながら、例えば、リソース更新の要求８５０および確認応答８５２は、ＯＣＳＴテストケースのアップロードおよび／または実行制御などと同じ高速インタフェースを使用して通信されてもよいことに留意されたい。同様に、リソース更新要求メッセージ（または信号、またはコマンド）８６０および確認応答８６２は、ＯＣＳＴテストケースのアップロードおよび／または実行制御などと同じ高速インタフェースを使用して通信されてもよい。言い換えれば、ＯＣＳＴコントローラとＯＣＳＴテストケースとの間の高速インタフェースは、例えば、ＯＣＳＴテストケースのアップロードおよび実行制御と共有されてもよく、メッセージ８５０、８５２とも共有されてもよい。同様に、ＡＴＥテストプログラム８２４とＯＣＳＴコントローラ８２６との間の高速インタフェースは、メッセージ８６０、８６２と共有されてもよく、ＯＣＳＴテストケースのアップロードおよび／または実行制御と共有されてもよい。

【0217】

結論として、図８に係る試験構成８００において、ＯＳＣＴコントローラ８２６は、例えば、ＡＴＥテストプログラム８２４と被試験デバイス８３０（またはＯＣＳＴテストケース８３２）との間の仲介役として使用されてもよい。例えば、ＯＣＳＴコントローラは、ＡＴＥテストプログラム８２４の上位制御下で、被試験デバイス８３０との、またはＯＣＳＴテストケース８３２との時間的にクリティカルな（そしておそらく非時間決定性である）通信を引き受けてもよい。このように、ＯＣＳＴコントローラ８２６は、例えば、一つ以上のテストケースを被試験デバイス８３０にアップロードするタスクと、一つ以上のテストケースの実行を制御するコマンドを（例えば、被試験デバイス８３０上で動作するテストケース実行器ソフトウェアに）発行するタスクを引き受けてもよい。さらに、ＯＣＳＴコントローラは、例えば、ＤＵＴからの試験結果のダウンロードを取り扱ってもよいし、任意選択で、試験結果を報告する前に、これらの試験結果の事前処理を実行してもよいし、それらの事前処理されたバージョンをＡＴＥテストプログラム８２４に通知してもよい。

【0218】

さらに、ＯＣＳＴコントローラ８２６は、例えば、ＯＣＳＴテストケースがリソース更新を要求するときに、仲介者の役割を担ってもよい。ＯＣＳＴコントローラ８２６は、リソース更新のためのそのような要求をＡＴＥテストプログラム８２４に転送してもよく、ＡＴＥテストプログラム８２４は、テスタリソース８２０との直接通信を担当してもよい。

【0219】

しかしながら、代替的に、ＯＣＳＴコントローラ８２６は、例えば、データバスおよび／または同期バスおよび／または一つ以上の同期ラインを使用して、テストリソース８２０に結合されてもよい。したがって、ＯＣＳＴコントローラ８２６は、任意選択で、ＯＣＳＴコントローラ８２６とテスタリソース８２０との間の直接接続（例えば、データバスおよび／または同期バスおよび／または一つ以上の同期ライン）を用いて、（例えば、ワークステーション８２２およびＡＴＥテストプログラム８２４をバイパスして）テストリソース８２０に直接アクセスし、ＯＣＳＴテストケース８３２が要求するように一つ以上のテスタリソースの更新を生じさせてもよい。この場合、ＯＣＳＴコントローラがリソース更新要求メッセージ８６０をＡＴＥテストプログラム８２４に転送すること、またはＡＴＥテストプログラム８２４から確認応答８６２を受信することも必要ではない。

【0220】

結論として、自動試験機器におけるＯＣＳＴテストケース８３２からのリソース更新要求メッセージ８５０を処理する一般的な概念は、ＯＣＳＴコントローラ８２６によってサポートされてもよく、ここで、ＯＣＳＴコントローラは、ＯＣＳＴテストケース８３２とＡＴＥテストプログラム８２４との間の仲介者として作用してもよいし、またはＯＣＳＴコントローラ８２６は、要求されたリソース更新を（例えばテスタリソース８２０との直接接続を用いて）直接的に取り扱ってもよい。さらに、ＯＣＳＴコントローラは、例えば、ＡＴＥテストプログラム８２４とＯＣＳＴテストケースとの間の仲介者として、ＯＣＳＴテストケースへの確認応答８５２の転送をサポートしてもよく、または、確認応答メッセージ８５２をそれ自身の制御下で提供してもよい。その結果、ＡＴＥ試験工程に対する高度な制御がＯＣＳＴテストケース８３２に提供される。

【0221】

本発明の一実施の形態は、ＯＣＳＴコントローラ８２６を備える自動試験機器８１０に見ることができることに留意されたい。さらに、本発明に係る別の実施の形態は、被試験デバイス８３０に見ることができる。

【0222】

さらに、試験構成８００、または自動試験機器８１０、または被試験デバイス８３０は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0223】

１０．図９に係るメッセージフロー

【0224】

図９は、本発明に係る実施の形態で使用できる、テスタリソース制御のためのメッセージフローの概略図を示す。例えば、メッセージフローは、本書に開示される任意の自動試験機器において使用できる。ある例として、図９のメッセージフローは、図８に係る試験構成８００において使用されてもよい。

【0225】

メッセージフローに関して、メッセージフローに関連する四つの本体（エンティティ）が存在することに留意されたい。テスタリソース９１０は、例えばテスタリソース８２０に対応してもよく、ＡＴＥテストプログラム９２０は、例えばＡＴＥテストプログラム８２４に対応してもよく、ＯＣＳＴコントローラ９３０は、例えばＯＣＳＴコントローラ８２６に対応してもよく、ＯＣＳＴテストケース９４０は、例えばＯＣＳＴテストケース８３２に対応してもよい。

【0226】

メッセージフローは、例えば、参照符号９５０で示されるＯＣＳＴテストケースが実行中である事実から開始されてもよい。テスタリソース更新要求は、テストケース内に（例えば、プログラム命令の形式で）存在してもよく、これは参照符号９５２で示される。テストケース内のテストリソース更新要求に応答して、メッセージ９５４が生じてもよく、これは、例えば、テストケースから（または被試験デバイスから）ＯＣＳＴコントローラ９３０に送信されてもよい。このメッセージは、例えば、「ＶＣＣ１を５．５ボルトに設定」というコマンドを（例えば、符号化された形式で）備えてもよい。このメッセージは、例えば、予め定義された構文を使用して符号化されてもよく、例えば、適切なＡＳＣＩＩ文字列によって表されてもよい。メッセージ９５４は、ＯＳＣＴコントローラ９３０によって受信されてもよく、このコントローラは、メッセージをＡＴＥテストプログラムに転送してもよい。メッセージの転送は、参照符号９５６で示され、メッセージの転送されたバージョンは、参照符号９５８で示される。転送されたメッセージ９５８は、例えば、メッセージ９５４と同じ形式を備えてもよく、例えば「ＶＣＣ１を５．５ボルトに設定」というコマンドを表してもよい。しかしながら、メッセージ９５４を転送するとき、ＯＣＳＴコントローラ９３０は、例えば、ＡＴＥテストプログラムによってメッセージ９５８がより容易に取り扱いできるように、プロトコルベースの高速通信からメッセージ９５４をアンラップ（解除）してもよい。任意選択で、ＯＣＳＴコントローラは、メッセージ９５４に基づいてメッセージ９５８を提供する際に、例えば構文変換の形式でメッセージ変換を実行してもよい。しかしながら、ＯＣＳＴコントローラ９３０は、メッセージ９５８がメッセージ９５４と同一となるように、メッセージ９５４を変更されない態様で転送することもできる。

【0227】

ＡＴＥテストプログラム９２０において、参照符号９６２で示されるメッセージハンドラがアクティブであってもよい。メッセージハンドラは、メッセージ９５８の受信を認識してもよく、例えば、メッセージ９５８を解析し、および／またはメッセージ９５８を解釈してもよい。例えば、ＡＴＥプログラム内のメッセージハンドラは、メッセージ９５８を「解読（デコード）」してもよく、メッセージ９５８を、テスタリソースの要求された更新をもたらし、テスタリソース９１０に転送される物理コマンド９６４に変換してもよい。例えば、メッセージハンドラ９６２は、メッセージ９５８を受信および評価し、メッセージを、テスタリソースの要求された更新を表すバスアクセスコマンドに変換してもよい。例えば、メッセージハンドラは、記号参照（例えば、「ＶＣＣ１」）を、適切なテスタリソース（例えば、「ＶＣＣ１」で参照される電源電圧を提供するデバイス電源）が所望の値を取るように指令する低レベル（例えばバスアクセス）コマンドに置き換えてもよい。この目的のために、メッセージハンドラは、メッセージ９５８内の数値表現を、特定のテスタリソースに適合する数値表現に変換してもよい。このように、ＡＴＥテストプログラム９２０は、テストリソースの所望の更新をもたらすメッセージ９６４を提供する。今回の場合では、メッセージ解読の結果、ＶＣＣ１電源が例えば５．５ボルトに更新される。さらに、テストリソース９１０は、ＡＴＥテストプログラム９２０に「更新成功」メッセージ９６６（これは、例えば、任意選択とみなされてもよい）を提供してもよい。したがって、ＡＴＥテストプログラム９２０は、リソース更新の完了を認識してもよい。しかしながら、ＡＴＥテストプログラムは、タイミングの評価から、更新が正常に完了したと結論付けてもよい。例えば、ＡＴＥテストプログラム９２０は、例えば、テスタリソース９１０への更新コマンドの提供から特定時間が経過したときに、テストリソースの更新が正常に完了したと仮定してもよい。

【0228】

しかしながら、ＡＴＥテストプログラムは、テスタリソースの更新が成功したことを（例えば、更新成功メッセージ９６６に基づいて、または時間評価に基づいて）確認した場合、確認メッセージ９６８をＯＣＳＴコントローラに提供する。さらに、確認応答メッセージ９６８の受信に応答して、ＯＣＳＴコントローラ９３０は、確認応答メッセージ（例えば、電圧更新成功による確認応答メッセージ）をＯＣＳＴテストケース９４０に提供する。ＯＣＳＴコントローラからＯＣＳＴテストケースに提供される確認応答メッセージは、９７０で指定されてもよい。例えば、ＯＣＳＴコントローラ９３０は、確認応答メッセージ９６８をＯＣＳＴテストケースに単に転送してもよいし、またはＯＣＳＴコントローラ９３０は、ＡＴＥテストプログラムからの確認応答メッセージ９６８の受信に応答して確認応答メッセージ９７０を生成してもよい。その後、ＯＣＳＴテストケースは、テスタリソース更新のための確認応答を受信し、参照符号９７４で示される実行を継続する。

【0229】

しかしながら、一態様によれば、ＯＣＳＴテストケース９４０は、メッセージ９４４の送信と確認応答メッセージ９７０の受信との間で「確認応答待機」状態であってもよい。この待機状態の間、ＯＣＳＴテストケースは、例えば、テストケースの実行を一時停止してもよいし、またはＯＣＳＴテストケースは、テストリソースの更新を必要とせず、好ましくはテスタリソースの更新に対して影響されない一つ以上の試験を実行してもよい。しかしながら、ＯＣＳＴテストケースは、確認メッセージ９７０が受信されるまで、テストリソースの更新を必要とするあらゆるテストの実行を遅延させてもよい。このようなメッセージフローを使用すると、テスタリソースの更新を必要とするテストケースの信頼性の高い実行は、テストケースの制御下で主に実施できる。

【0230】

ここで説明されるようなメッセージフローは、任意選択で、本発明に係る任意の実施の形態においても使用されてよく、メッセージ９５４は、ＯＳＣＴテストケースによって提供されてもよく、メッセージ９７０は、ＯＣＳＴテストケースによって評価されてもよく、メッセージ９５４は、自試験機器によって受信されてもよく、９７０は、自動試験機器によって提供されてもよいことに留意されたい。メッセージ９５８、９６４、９６６、および９６８は、ＡＴＥの内部メッセージであってもよい。

【0231】

さらに、図９に係るメッセージフローは、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0232】

１１．図１０に係る試験構成

【0233】

図１０は、本発明の一実施の形態に係る、試験構成の概略図を示す。図１０に係る試験構成１０００は、図７に係る試験構成７００と同様であり、同等の構成要素は、ここでは再説明されないことに留意されたい。むしろ、上記説明を参照されたい。

【0234】

試験構成１０００は、自動試験機器７１０と同様でありうる自動試験機器１０１０を備える。自動試験機器１０１０は、一つ以上のテスタリソース１０２０を備えてもよく、これは、テスタリソース７２０と同様であってよい。しかしながら、一つ以上のテスタリソース１０２０は、例えば、被試験デバイスに提供されるアナログまたはデジタル信号の物理特性、または被試験デバイスから受信するアナログまたはデジタル信号の物理特性などの物理量を測定するように構成される少なくとも一つの測定リソースを備えてもよいことに留意されたい。しかしながら、テスタリソース１０２０は、（例えば、被試験デバイスの環境における）温度、圧力、湿度などの環境パラメータを測定するように構成される測定リソースを備えてもよい。自動試験機器１０１０はまた、ワークステーション７２２と同様でありうるワークステーション１０２２を備える。ワークステーション１０２２は、ＡＴＥテストプログラム１０２４を実行するように構成されてもよい。

【0235】

さらに、被試験デバイス１０３０があり、これは、例えば図７を参照して説明したような方法で、一つ以上のテスタリソース１０２０と結合されてもよい。したがって、一つ以上のテスタリソース１０２２と被試験デバイス１０３０との間には、例えば、ＤＵＴへの供給、試験相互作用および測定のためのＡＴＥ制御信号を提供する一つ以上の接続が存在してもよい。

【0236】

しかしながら、試験構成７００は、ＯＣＳＴテストケース１０４０とＡＴＥテストプログラム１０２４との間で異なる種類の通信が実行される点で、試験構成１０００とは区別される。試験構成１０００において、ＯＣＳＴテストケース１０４０は、ＡＴＥテストプログラム１０２４からリソース測定を要求するように構成される。この目的のために、ＯＣＳＴテストケース１０４０は、リソース測定要求メッセージ１０５０（リソース測定要求メッセージとも指定される）をＡＴＥテストプログラム１０２４に送信し、このメッセージは、例えば、パラメトリックスメッセージであってもよい。このメッセージ１０５０に応答して、ＡＴＥテストプログラム１０２４は、テスタリソースのうちの一つ、例えば測定リソースに、要求された測定を実行して測定結果を提供するように指示してもよい。例えば、ＡＴＥテストプログラム１０２４は、デバイス電源に電流測定の実行を指示してもよい。あるいは、ＡＴＥテスト１０２４は、被試験デバイスによって提供されるデジタル信号について測定を実行するようにデジタルチャネルモジュールに指示してもよく、またはＡＴＥテストプログラム１０２４は、被試験デバイスによって提供されるアナログ信号について測定を実行するようにアナログチャネルモジュールに指示してもよい。しかしながら、ＡＴＥテストプログラム１０２４は、代替的に、物理量の任意の他の測定を実行するように（テスタリソース１０２０の一部でありうる）測定リソースに指示してもよい。

【0237】

測定が完了すると、ＡＴＥテストプログラム１０２４は、測定結果メッセージをＯＣＳＴテストケース１０４０に提供してもよい。測定結果メッセージは、１０５２で指定される。

【0238】

したがって、ＯＣＳＴテストケース１０４０は、テストリソースの一つによって実行される測定を要求することができ、ＡＴＥプログラム１０２４は、適切な測定リソースにこのような測定の実行を指示することによってこの要求に応答する。その後、ＡＴＥテストプログラム１０２４は、測定結果メッセージ１０５２を使用して、測定結果をＯＣＳＴテストケースに報告する。ＯＣＳＴテストケースは、例えば、不適切なテストケースステップの実行によって測定結果が偽造されないようにするために、測定結果メッセージ１０５２を待機できる。このように、ＯＣＳＴテストケースが高度な制御を実施し、測定を時間的に同期できるようにすることが可能である。さらに、測定結果は、ＯＣＳＴテストケースのさらなる実行において考慮されることができる。

【0239】

さらに、試験構成１１００は、本書に記載される任意の特徴、機能および詳細のいずれかによって、個別にまたは組み合わせて補足されてもよいことに留意されたい。さらに、自動試験機器１０１０は、本発明の実施の形態と見なされてもよいことに留意されたい。同様に、被試験デバイス１０３０も本発明の実施の形態と見なされてもよい。

【0240】

１２．図１１に係る試験構成

【0241】

図１１は、本発明の一実施の形態に係るテスト構成１１００の概略図を示す。テスト構成１１００は、自動試験機器１１１０および被試験デバイス１１３０を備える。

【0242】

自動試験機器１１１０は、例えば、テストリソース１１２０に対応しうるテストリソース１１２０を備えてもよい。さらに、自動試験機器１１１０は、例えば、上述したワークステーション１０２０に対応しうるワークステーション１１２２を備える。ワークステーション１１２２は、例えば、ＡＴＥテストプログラム１０２４に対応しうるＡＴＥテストプログラム１１２４を実行するように構成される。しかしながら、自動試験機器１０１０に加えて、自動試験機器１１１０は、オン・チップ・システム・テストコントローラ１１５０も備え、これは、例えば、ワークステーション１１２２と結合されてよく、任意選択でテスタリソース１１２０とも結合されてもよい。さらに、オン・チップ・システム・テストコントローラ１１４０は、典型的に、被試験デバイス１１３０から、または被試験デバイス１１３０上で実行されるテストケース１１４０から、リソース測定要求１１６０を受信するように構成されるとともに、被試験デバイス１１３０に、または被試験デバイス１１３０上で実行されるＯＣＳＴテストケース１１４０に測定結果１１６２を提供するように構成される。

【0243】

例えば、ＯＣＳＴコントローラ１１５０は、高速インタフェース（ＨＳＩＯ）を介してテスタリソース測定用のメッセージ交換のために被試験デバイス１１３０と結合されてもよい。さらに、ＯＣＳＴコントローラ１１５０は、リソース測定要求（またはリソース測定要求メッセージ）１１７０をワークステーション１１２２またはワークステーション１１２２上で実行されるＡＴＥテストプログラム１１２４に提供するために、ワークステーション１１２２と結合されてもよい。さらに、ＯＣＳＴコントローラは、ワークステーション１１２２から、またはＡＴＥテストプログラム１１２４から測定結果（または測定結果メッセージ）１１７２を受信するように構成されてもよい。言い換えれば、ＯＣＳＴコントローラ１１５０は、高速インタフェース（ＨＳＩＯ）を介してテスタリソース測定用のメッセージ交換をワークステーション１１２２またはＡＴＥテストプログラム１１２４とともに実施するよう構成されてもよい。しかしながら、ＯＣＳＴコントローラ１１５０とワークステーション１１２２との間の高速インタフェースは、被試験デバイス１１３０とＯＣＳＴコントローラ１１５０との間の高速インタフェースとは当然のことながら異なっていてもよいことに留意されたい。さらに、ＯＣＳＴコントローラは、被試験デバイス１１３０と（またはＯＣＳＴテストケース１１４０と）通信して、ＯＣＳＴテストケースのアップロードおよび／または実行制御を実行するように構成されてもよい。さらに、ＯＣＳＴコントローラ１１５０は、ＯＣＳＴ－ＴＣアップロードおよび／または実行制御を実行するために、ワークステーション１１２２と、またはワークステーション１１２２上で実行されるＡＴＥテストプログラム１１２４と（例えば双方向に）通信するように構成されてもよい。ＯＣＳＴ－ＴＣアップロードおよび／または実行制御を実行するために、ＯＣＳＴコントローラ１１５０とＤＵＴ１１３０との間の通信は、例えば、高速インタフェース（例えば、ＵＳＢ、ＰＣＩｅ、ＥＴＨ、または任意の他の適切な高速インタフェース）を用いてもよい。

【0244】

同様に、ＯＣＳＴコントローラ１１５０と、ワークステーション１１２２またはＡＴＥテストプログラム１１２４との間における、ＯＣＳＴ－ＴＣアップロードおよび／または実行制御の実行またはサポートまたは制御の通信は、例えば、高速インタフェース（例えば、ＵＳＢ、ＰＣＩｅ、ＥＴＨ、または任意の他の適切なインタフェース）を使用して実行されてもよい。したがって、ＯＣＳＴコントローラは、オン・チップ・システム・テストをサポートしてもよい。例えば、被試験デバイスまたはＯＣＳＴテストケース１１４０と高速通信を実行する特に優れた能力を有することにより、ＯＣＳＴコントローラ１１５０は、被試験デバイス１１３０へのオン・チップ・システム・テストのテストケースのアップロードを特に高速な方法で実行してもよく、これは試験の高速化に役立つ。さらに、オン・チップ・システム・テストコントローラ１１５０は、例えば、高速インタフェースを介して、被試験デバイス１１３０またはＯＣＳＴテストケース１１４０に実行制御情報および／または実行制御コマンドを提供してもよい。このように、ＯＣＳＴコントローラは、ＯＣＳＴテストを高速かつ時間短縮された方法で実行するのに役立つことができる。しかしながら、ＯＣＳＴコントローラ１１４０は、例えば、全体のテストフローを制御しうるＡＴＥテストプログラムからＯＣＳＴテストケースを受信してもよい。さらに、ＡＴＥテストプログラムは、ＯＣＳＴコントローラ１１５０に所望の全体的なテストフローに関する情報も提供してよく、ＯＣＳＴコントローラ１１５０は、それに基づいて被試験デバイス１１３０またはＯＣＳＴテストケース１１４０に実行制御情報および／または実行制御コマンドを提供するようにしてもよい。このように、ＯＣＳＴテストコントローラ１１５０は、一方側のワークステーション１１２０またはＡＴＥテストプログラム１１２４と、他方側のＤＵＴ１１３０またはＯＣＳＴテストケース１１４０との間の仲介者として機能してもよい。

【0245】

さらに、ＯＣＳＴテストコントローラ１１５０は、本書に記載されるリソース測定手順における仲介者として機能してもよい。例えば、ＯＣＳＴコントローラは、ＯＣＳＴテストケース１１４０からリソース測定要求１１６０を受信し、このリソース測定要求（リソース測定コマンドまたはリソース測定要求メッセージとみなすこともできる）をワークステーション１１２０またはＡＴＥテストプログラム１１２４に（例えば、リソース測定要求１１７０の形式で）転送するよう構成されていてもよい。ＯＣＳＴコントローラは、リソース測定要求をその元の形式で転送してもよく、例えば、ＯＣＳＴコントローラ１１５０とＤＵＴ１１３０との間の高速インタフェースの通信プロトコルのみを取り扱ってもよい。しかしながら、ＯＣＳＴコントローラ１１５０は、リソース測定要求の変換を交互に実行してもよく、これは「コマンド変換」とみなすことができる。したがって、ＯＣＳＴコントローラ１１５０は、リソース測定要求１１７０がリソース測定要求１１６０の変換バージョンであるようにして、リソース測定要求１１７０を提供してもよい。例えば、ＯＣＳＴコントローラ１１５０は、ＯＣＳＴコントローラ１１５０とワークステーション１１２２との間の特定のインタフェースまたは通信形式の観点でこれが適切である場合、このようなコマンド変換を実行してもよい。

【0246】

さらに、ＯＣＳＴコントローラ１１５０は、ワークステーション１１２２によって提供される、またはＡＴＥテストプログラム１１２４によって提供される測定結果情報１１７２を、ＤＵＴ１１３０またはＯＣＳＴテストケース１１４０に変更されない態様で転送してもよく、ここでＯＣＳＴコントローラ１１５０は、例えばＯＣＳＴコントローラ１１５０と被試験デバイス１１３０との間の高速インタフェースに対するプロトコルハンドリングを引き受けてもよい。しかしながら、ＯＣＳＴコントローラ１１５０は、ワークステーション１１２２からまたはＡＴＥテストプログラム１１２４から受信した測定結果情報１１７２に基づいて、測定結果１１６２を生成してもよい。

【0247】

結論として、ＯＣＳＴコントローラは、ＯＣＳＴテストケース１１４０からＡＴＥテストプログラム１１２４にリソース測定要求１１６０を修正なしで単に転送し、ＡＴＥテストプログラム１１２４からＯＣＳＴテストケース１１４０に測定結果１１７２を修正なしで転送し、高速通信プロトコルのみを扱う「単純な仲介者」として機能してもよい。しかしながら、代替的に、ＯＣＳＴコントローラは、例えば、（プロトコル処理に加えて）コマンド変換および／または測定結果メッセージ変換または測定結果メッセージ生成を備えうる、拡張機能を備えてもよい。

【0248】

したがって、被試験デバイス１１３０上で実行されるＯＣＳＴテストケース１１４０は、一つ以上の物理量の測定を要求するコマンド（例えば、リソース測定要求１１６０）を提供することができ、測定結果信号１１６２を受信することができる。ＯＣＳＴコントローラ１１５２は、仲介者として機能し、自動試験機器１１１０と被試験デバイス１１３０との間の高速通信用のプロトコル扱いを引き受ける。ＯＣＳＴコントローラ１１５０は、ＡＴＥテストプログラム１１２４と通信し、リソース測定要求１０６０を元の形式または変換された形式でＡＴＥテストプログラム１１２４に転送する。さらに、ＯＣＳＴコントローラ１１５０は、ＡＴＥテストプログラム１１２４からＯＣＳＴテストケース１１４０への測定結果信号の仲介役としても機能する。さらに、ＯＣＳＴコントローラは、任意選択で、ＯＣＳＴテストケースのアップロードおよび／または実行制御における機能も引き受け、例えば、ＯＣＳＴコントローラ１１５０と被試験デバイス１１３０との間と同じ物理インタフェースが、一方側ではＯＣＳＴテストケースのアップロードおよび／または実行制御のために用いられ、他方側ではリソース測定要求１１６０および測定結果信号１１６２の送信のために用いられてもよい。したがって、ＯＣＳＴコントローラ１１５０と被試験デバイス１１３０との間の高速インタフェースは、複数の目的のために特に有利な方法で使用することができる。

【0249】

さらに、この概念の基本的な機能に関して、図１０の説明が参照されることにも留意されたい。

【0250】

加えて、試験構成１１００は、本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。さらに、本書に記載される自動試験機器１１１０および被試験デバイス１１３０の双方は、本発明の実施の形態としてみなされるべきであることに留意されたい。

【0251】

１３．図１２に係るテストフロー

【0252】

図１２は、本発明の一実施の形態に係るテストフロー１２００の概略図を示す。テストフローは、例えば、試験構成１１００において実行されてもよい。

【0253】

図１２は、通信またはメッセージフローを示し、これは、テスタリソース１２１０（例えば、テスタリソース１１２０に対応しうる）と、ＡＴＥテストプログラム１２２０（例えば、ＡＴＥテストプログラム１１２４に対応しうる）と、ＯＣＳＴコントローラ１２３０（例えば、ＯＣＳＴコントローラ１１５０に対応しうる）と、ＯＣＳＴテストケース１２４０（例えば、ＯＣＳＴテストケース１１４０に対応しうる）とに関する。図示されるように、ＯＣＳＴテストケースは、参照符号１２５０で示されるように実行中である。ＯＣＳＴテストケースは、物理量の測定を要求するメッセージ１２５４、例えばメッセージ「ＶＣＣ１を測定」をＯＣＳＴコントローラ１２３０に送信する。ＯＣＳＴコントローラ１２３０は、メッセージ転送機能１２５６を備える。この例において、ＯＣＳＴコントローラ１２３０は、このメッセージを、例えばメッセージ１２５８の形式で、ＡＴＥテストプログラム１２２０に転送する。例えば、メッセージ１２５８は、コマンド「ＶＣＣ１を測定」を依然として備える。ＡＴＥテストプログラム１２０２は、ＯＣＳＴコントローラから受信したメッセージ１２５８を評価するアクティブなメッセージハンドラ１２６２を備える。

【0254】

メッセージハンドラ１２６２は、例えば、メッセージ１２５８のメッセージ解読を実行し、その結果、メッセージ（またはコマンド）１２６４をテストリソース１２１０に提供してもよく、当該コマンド１２６４は、物理量の要求された測定を生じさせてもよい。例えば、メッセージまたはコマンド１２６４は、テストリソース１２１０に所望の測定を行わせる（物理）ハードウェアコマンドの形式であってよい。したがって、ＡＴＥテストプログラム１２２０は、テストリソース１２１０から測定結果情報１２６６（例えば、測定結果メッセージ）を受信する。測定結果情報１２６６は、例えば、物理量（例えば、測定されるべきＶＣＣ１）の特定の値を示してもよい。しかしながら、ＡＴＥテストプログラム１２２０は、例えば、測定結果情報１２６６をテスタリソース１２１０からアクティブに読み出してもよいことに留意されたい。代替的に、測定リソース１２１０は、測定結果情報１２６６を測定結果メッセージの形式でＡＴＥテストプログラム１２２０に提供してもよい。ＡＴＥテストプログラム１２２０は、結果として、測定されるべき物理量の値を示す結果メッセージ１２６８を生成し、この測定結果メッセージをＯＣＳＴコントローラ１２３０に提供してもよい。ＯＣＳＴコントローラ１２３０は、例えば、測定結果メッセージ１２６８を測定結果メッセージ１２７０の形式でＯＣＳＴテストケースに転送してもよい。しかしながら、ＯＣＳＴコントローラ１２３０は、任意選択で、例えば構文を修正することによって、メッセージ１２６８をメッセージ１２７０に変換する機能を備えてもよいことに留意されたい。その後、ＯＣＳＴテストケース１２４０は、測定結果メッセージ１２７０を受信および評価してもよい。例えば、ＯＣＳＴテストケース１２４０は、結果メッセージ１２７０を解析し、測定結果メッセージ１２７０から測定結果情報を抽出してもよい。さらに、任意選択で、テストケースの実行は、受信した結果に依存して（例えば、測定結果に依存して）継続してもよい。しかしながら、代替的に、ＯＣＳＴテストケース１２４０は、単に測定結果を保存し、後で自動試験機器に報告してもよい（または、テストケース側でテスト結果の決定に使用してもよい）。

【0255】

結論として、図１２のメッセージフローを使用して、ＯＣＳＴテストケースは物理量の測定を要求することができ、自動試験機器は、この要求に対処するためにＯＣＳＴコントローラ１２３０のプロトコル取り扱い能力を利用できる。したがって、測定結果を効率的な方法でＯＣＳＴテストケース１２４０に通知でき、ＯＣＳＴテストケース１２４０はテスト結果を利用できる。

【0256】

さらに、図１２に係るメッセージフロー１２００は、本発明に係る任意の実施の形態において使用されてもよく、図１２のメッセージフロー１２００は、本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0257】

１４．図１３に係る試験構成

【0258】

図１３は、本発明の一実施の形態に係る試験構成１３００の概略図を示す。試験構成１３００は、本書に記載される他の自動試験機器に対応しうる、自動試験機器１３１０を備える。例えば、自動試験機器１３１０は、テスタリソース１３２０と、ＡＴＥテストプログラム１３２４を実行するように構成されうるワークステーション１３２２とを備えてもよい。自動試験機器１３１０は、いわゆる「ＦＴサービス機器１３５０」を備えてもよく、これは、ＤＵＴ試験コントローラを含むＣＰＵサポート型ハードウェアインスタンスでありうる機能テストケース・サービス機器であってもよい。ＦＴサービス機器１３５０のテストコントローラは、１３５２で指定される。例えば、テストコントローラ１３５２は、データ、制御、通信経路インタフェースでありうる、いわゆる「ＤＣＣＰ－ＩＦ」を使用して、ＡＴＥテストプログラム１３２４と通信するように構成されてもよい。さらに、テストコントローラ１３５２は、被試験デバイス１３３０上で実行されるテストケース１３４０と、データ、制御、通信経路インタフェースであるＤＣＣＰインタフェースを介して通信するように構成されてもよい。

【0259】

試験構成１３００の機能性に関して、例えば、上記の議論が参照され、自動試験機器１３１０は、例えば、自動試験機器８１０または自動試験機器１１１０に対応してもよいことに留意されたい。さらに、ＦＴサービス機器１３５２は、例えば、ＯＣＳＴコントローラ８２６またはＯＣＳＴコントローラ１１５０に対応してもよいことに留意されたい。ＤＣＣＰインタフェース１３６０は、例えば、ＯＣＳＴコントローラ８２６とＡＴＥプログラム８２４との間のインタフェースの機能を担ってもよく、ＤＣＣＰインタフェース１３６２は、例えば、ＯＣＳＴコントローラ８２６とＯＣＳＴテストケース８３２との間のインタフェースの役割を担ってもよい。

【0260】

図１３から分かるように、例えば、テストコントローラ１３５２とテストケース１３４０との間に単一のＤＣＣＰインタフェース１３６２を有することが十分でありうる。当該単一のＤＣＣＰインタフェース１３６２は、例えば、ＯＣＳＴテストケースのアップロードおよび／または実行制御に使用されてもよく、リソース更新要求（例えば８５０）および確認応答信号（例えば８５２）の送信に使用されてもよい。同様に、テストコントローラ１３５２とＡＴＥテストプログラム１３２４との間は、単一のＤＣＣＰインタフェース１３６０で十分でありうる。例えば、この単一のＤＣＣＰインタフェース１３６０は、ＯＣＳＴテストケースのアップロードおよび／または実行制御に使用されてもよく、また、テストコントローラ１３５２からＡＴＥテストプログラム１３２４へのリソース更新要求（例えば、８６０）の送信、およびＡＴＥテストプログラム１３２４からテストコントローラ１３５２への確認応答信号（例えば、８６２）の送信に使用されてもよい。

【0261】

結論として、図１３は、機能テストケース１３４０が被試験デバイス１３３０上に完全に配置されている試験構成１３００を示す。テストコントローラ１３５２へのＤＣＣＰインタフェースは、例えば、ＨＳＩＯ－ＰＣＩｅまたはＵＳＢのような物理インタフェースによって実現される。

【0262】

しかしながら、試験構成１３００は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。さらに、自動試験機器１３１０および被試験デバイス１３３０の双方は、本発明に係る実施の形態と見なされてもよいことに留意されたい。

【0263】

図１４に係る試験構成

【0264】

図１４は、本発明の一実施の形態に係る試験構成１４００の概略図を示す。試験構成１４００は、自動試験機器１４１０を備え、これは、上記の議論が参照されるように、試験構成１３００と同様でありうる。また、試験構成１４００は、被試験デバイス１４３０を備え、この被試験デバイスは、上記の説明に参照がなされるような被試験デバイス１３３０と同様である。

【0265】

自動試験機器１４１０は、テストリソース１３２０と同様であるテストリソース１４２０と、ワークステーション１３２２と同様であるワークステーション１４２２とを備える。したがって、上記の説明を参照されたい。例えば、ＡＴＥテストプログラム１４２４は、ワークステーション１４２２上で実行され、テストプログラム１４２４は、ワークステーション１３２２上で実行されるテストプログラム１３２４と同様または同一であってよい。さらに、自動試験機器１４１０は、ＦＴサービス機器（ＦＳＩ）とも称される機能テストケース・サービス装置１４５０を備える。機能テストケース・サービス機器１４５０は、例えば、機能テストケース・サービス機器１３５０に対応してもよく、例えば、オン・チップ・システム・テストコントローラ（例えば、オン・チップ・システム・テストコントローラ８２６）の機能を引き受けてもよい。

【0266】

しかしながら、図１４に係る試験構成１４００において、テストケース１４４０は、被試験デバイス１４３０と機能テストケース・サービス装置１４５０との間に分配される。例えば、テストケースの一部は、機能テストケース・サービス機器１４５０上で実行され、テストケースの別の部分は、被試験デバイス１４３０上で実行されてもよい。単なる一例として、機能テストケース・サービス機器１４５０は、被試験デバイス１４３０と密接に通信し、例えば、実環境において被試験デバイス１４３０に結合されるべきハードウェアの代わりとなるハードウェア構成要素を備えてもよい。

【0267】

一態様によれば、テストケース１４４０と機能テストケース・サービス機器１４５０のテストコントローラ１４５２との間に、ＤＣＣＰインタフェース１４６２が存在してもよい。したがって、ＤＣＣＰインタフェース１４６２は、例えば、ＯＣＳＴテストケースのアップロードおよび／または実行制御を可能にしてもよく、リソース更新要求（例えば、８５０）の送信および確認応答信号（例えば、８５２）の送信を扱ってもよい。さらに、テストコントローラ１４５２とＡＴＥテストプログラム１４２４との間には、ＤＣＣＰインタフェース１４６０も存在する。

【0268】

結論として、図１４に係る試験構成１４００において、機能テストケースは、ＤＵＴ部分とＦＳＩ部分とに論理的に分割される。テストコントローラとテストケースとの間のＤＣＣＰインタフェースは、例えば、ＦＳＩ上で実行されるソフトウェアによって実現される。ＦＳＩとＤＵＴの物理的な接続を取り扱うソフトウェアは、例えばテストケースの内部に配置されます。

【0269】

さらに、図１４に係る試験構成１４００は、本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0270】

さらに、ＡＴＥ１４１０および被試験デバイス１４３０の双方は、本発明に係る実施の形態と見なされてもよいことに留意されたい。

【0271】

結論として、図１４は、テストケースとの通信のための更なるインタフェース・トポロジーを取り扱う拡張を示す。一態様によれば、テストケースの内部にＤＵＴインタフェース制御が統合されてもよい。しかしながら、テストケースの内部でのＤＵＴインタフェース制御の統合も本発明の範囲に含まれる。

【0272】

図１５に係る試験構成

【0273】

図１５は、本発明の一実施の形態に係る試験構成１５００の概略図を示す。試験構成１５００は、自動試験機器１５１０と、被試験デバイス１５３０とを備える。自動試験機器１５１０は、テストリソース１５２０およびワークステーション１５２２を備え、ＡＴＥテストプログラム１５２４は、ワークステーション１５２２上で実行される。さらに、テストケース１５４０は、被試験デバイス上で実行される。

【0274】

自動試験機器に関して、例えば、同様の機能を備える図７に係る試験構成７００が参照される。例えば、自動試験機器１５１０は、自動試験機器７１０に対応してもよく、被試験デバイス１５３０は、被試験デバイス７３０に対応してもよい。図１５で分かるように、ＡＴＥテストプログラム１５２４とテストケース１５４０との間には、ＤＣＣＰインタフェース１５５０が存在する。例えば、ＤＣＣＰインタフェース１５５０は、図７を参照して説明したＯＣＳＴテストケースのアップロードおよび／または実行制御に使用されてもよく、ＤＣＣＰインタフェース１５５０は、リソース更新要求（例えば７５０）および確認応答信号（例えば７５２）に使用されてもよい。したがって、例えば、単一のＤＣＣＰインタフェース１５５０は、複数の目的に使用されてもよい。

【0275】

さらに、試験構成１５００の機能性は、上記の説明にも参照されるように、試験構成７００の機能性と同様であってよいことに留意されたい。

【0276】

結論として、図１５に係る試験構成１５００において、機能テストケースは完全に被試験デバイス上に配置される。ＡＴＥテストプログラムへのＤＣＣＰインタフェースは、例えば、ＨＳＩＯ－ＰＣＩｅまたはＵＳＢのような物理的インタフェースによって実現される。

【0277】

さらに、図１５に係る試験構成１５００は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。さらに、ＡＴＥ１５１０およびＤＵＴ１５３０の双方は、本発明に係る実施の形態とみなされてもよいに留意されたい。

【0278】

１７．図１６に係る試験構成

【0279】

図１６は、本発明の一実施の形態に係る、試験構成の概略図を示す。図１６に係る試験構成１６００は、自動試験機器１６１０および被試験デバイス１６３０を備える。自動試験機器１６１０は、例えば、図１５に係る自動試験機器１５１０に対応してもよい。自動試験機器１６１０は、例えば、テストリソース１５２０に対応しうるテストリソース１６２０を備え、自動試験機器１６１０は、例えば、ワークステーション１５２２に対応しうるワークステーション１６２２も備える。自動試験機器テストプログラム１６２４は、ワークステーション１６２２上で実行される。

【0280】

しかしながら、テストケース１６４０は、ワークステーション１６２２と被試験デバイス１６３０との間に分配される。したがって、機能試験は、例えば、ＤＵＴ部とワークステーション部とに（例えば、被試験デバイス１６３０上で実行されるＤＵＴ部と、ワークステーション１６２２上で実行されるワークステーション部とに）論理的に分割されてもよい。二つの部分の間のＤＣＣＰインタフェースは、例えば、ワークステーション１６２２上で実行されるソフトウェアによって実現される。ワークステーションとＤＵＴの物理的な接続を取り扱うソフトウェアは、例えば、テストケース１６４０の内部に配置される。

【0281】

さらに、ＡＴＥテストプログラム１６２４とテストケース１６４０との間のＤＣＣＰインタフェース１６５０は、例えば、ＤＣＣＰインタフェース１５５０の機能性と同等の機能性を備えてもよいことに留意されたい。例えば、ＤＣＣＰインタフェース１６５０は、（例えば、図５に関して説明したような）ＯＣＳＴテストケースのアップロードおよび／または実行制御のために使用されてもよく、ＤＣＣＰインタフェース１６５０は、リソース更新要求（例えば７５０）および確認応答信号（例えば７５２）の送信のために使用されてもよい。

【0282】

さらに、試験構成６００は、本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0283】

さらに、自動試験機器１６１０および被試験デバイス１６３０は、本発明に係る実施の形態とみなされてもよいことに留意されたい。

【0284】

結論として、図１６は、テストケースとの通信のためのさらなるインタフェース・トポロジーを取り扱う拡張を示す。一態様によれば、テストケースの内部にＤＵＴインタフェース制御が統合されてもよい。しかしながら、テストケース内部でのＤＵＴインタフェース制御の統合も本発明の範囲に含まれる。

【0285】

１８．図１７に係る試験構成

【0286】

図１７は、本発明の一実施の形態に係る試験構成１７００の概略図を示す。

【0287】

試験構成１７００は、例えば、自動試験機器８１０に対応しうる、自動試験機器１７１０を備える。例えば、自動試験機器１７１０は、例えば、テスタリソース８２０に対応しうるテスタリソース１７２０を備えてもよい。さらに、試験構成１７１０は、ワークステーション８２２に対応しうるワークステーション１７２２を備えてもよい。さらに、試験構成１７１０は、例えば、ＯＣＳＴコントローラ８２６に対応しうる、ＣＳＴコントローラ１７２６を備えてもよい。さらに、試験構成１７００は、例えば、被試験デバイス８３０に対応しうる被試験デバイス１７３０を備える。

【0288】

しかしながら、試験構成１７００は、例えば、自動試験機器１７１０の一部でありうるライブラリ１７７０も備える。ライブラリは、例えば、一つ以上のメッセージアプリケーション・プログラミング・インタフェース（ＡＰＩ）を備えてもよい。さらに、ライブラリ１７７０は、例えば、一つ以上の記号参照を備えてもよい。さらに、ライブラリ１７７０は、任意選択で、信号マッピングを備えてもよい。

【0289】

例えば、メッセージＡＰＩは、ライブラリ・プロシージャまたはライブラリ関数への呼び出しを定義してもよい。例えば、メッセージＡＰＩは、ＯＣＳＴテストケースの開発における利用のための手順または関数の呼び出しのための構文を（例えば、関数ヘッダまたはメソッドヘッダまたは関数インタフェースまたはメソッドインタフェースの形式で）定義してもよい。さらに、ライブラリは、任意選択で、当該関数またはメソッドの実装を（例えば、事前コンパイルされた形式、またはソースコードの形式で）を含んでもよい。例えば、ライブラリ１７７０のＡＰＩによって定義される関数またはメソッドは、リソース更新要求メッセージの生成（および送信）を定義してもよい。単なる一例として、メッセージＡＰＩは、関数またはメソッドを定義してもよく、その呼び出しは、テスタリソースのリソース更新の要求に役立つメッセージの生成をもたらす。そのような関数またはメソッドは、例えば、適切な構文でメッセージを生成することを定義し、高速インタフェースを介してそのようなメッセージをＯＣＳＴコントローラ１７２６に、またはＡＴＥテストプログラム１７２４に送信することを定義してもよい。したがって、ＯＣＳＴテストケースの開発者は、ライブラリ１７７０で定義された関数呼び出しまたはメソッド呼び出しをＯＣＳＴテストケースのソースコードに含めるだけでよく、その後、ＯＣＳＴテストケースの実行可能コードを（例えば、メッセージＡＰＩで定義された当該手順または関数の実装の適切な表現を用いて）生成することができる。

【0290】

結論として、ライブラリ１７７０に定義される関数またはメソッドの一つは、リソース更新要求メッセージの生成（および好ましくは送信も）を定義し、ライブラリに定義された別のメソッドまたは関数は、確認応答信号が被試験デバイスに到達したかどうかの検出を定義してもよく、または被試験デバイスでの確認応答信号の受信の待機を定義してもよい。

【0291】

代替的または追加的に、ライブラリに定義された関数またはメソッドの一つは、リソース測定要求メッセージの生成（および好ましくは送信も）を定義し、ライブラリに定義された別の関数またはメソッドは、測定結果信号の評価を定義してもよい。

【0292】

ライブラリ１７７０は、任意選択で、記号参照の表現を備えてもよく、当該記号参照は、抽象テストリソース制御および信号マッピングのための記号参照であってよい。例えば、ライブラリ１７７０は、例えば、ＶＣＣ１、ＶＣＣ２、ＶＣＣ３、ｆＣＬＫ１、ｆＣＬＫ２などのような、典型的に使用される信号名のための記号参照を備えてもよい。したがって、ライブラリ内の記号参照は、特定の被試験デバイスのための試験を設計する検証エンジニアが容易に理解できる、ユーザフレンドリーな信号名または信号特性であってもよい。

【0293】

さらに、ライブラリ１７７０は、任意選択で、例えば、自動試験機器１７１０によって提供される実際の物理信号への記号参照のマッピングを定義しうる信号マッピングを備えてもよい。

【0294】

さらに、ライブラリ１７７０は、テストケースのためのメッセージＡＰＩを備えてもよいだけでなく、テストケースおよび／またはＯＣＳＴコントローラおよび／またはテストプログラムのためのメッセージＡＰＩを備えてもよいことに留意されたい。例えば、ライブラリ１７７０は、ＯＣＳＴコントローラ１７２６上で実行されるプログラムの設計において使用することができ、例えば、リソース更新要求メッセージの評価および／または確認応答メッセージの生成のための関数またはメソッドを定義しうるメッセージＡＰＩを備えてもよい。さらに、ライブラリ１７７０に含まれるメッセージＡＰＩは、ＡＴＥテストプログラム１７２４に含めることができ、例えば、リソース更新要求メッセージを評価しうる、または確認応答メッセージを生成しうる関数またはメソッドを定義してもよい。このように、ライブラリ１７７０に含まれるメッセージＡＰＩは、ＯＣＳＴテストケースの開発をサポートしてもよく、またＡＴＥテストプログラムの開発をサポートしてもよい。さらに、ライブラリ１７７０に含まれるメッセージＡＰＩは、ＯＣＳＴコントローラ１７２６上で実行されるソフトウェアの開発をサポートしてもよい。

【0295】

さらに、記号参照は、例えばデバイスに関連する（例えば、デバイス仕様またはデバイスデータシートにおける各信号の命名に密接に関連する）態様で、信号および／または量を定義してもよいため、例えば、ＯＣＳＴテストケースの開発者をサポートしうる。

【0296】

さらに、信号マッピングは、例えば、ＯＣＳＴコントローラ１７２６上で実行されるプログラムの生成において、またはＡＴＥテストプログラム１７２４の開発において使用されてもよく、また、実行時にＯＣＳＴコントローラ１７２６またはＡＴＥテストプログラム１７２４においてで使用されてもよい。例えば、ライブラリ１７２６で定義される信号マッピングは、ＯＣＳＴコントローラ１７２６またはＡＴＥテストプログラム１７２４によって記号参照を変換するために使用されてもよく、例えば、ＯＣＳＴテストケースからのメッセージ（例えば、リソース更新要求メッセージに含まれる記号参照を含んでもよい）を特定の物理テスタリソースを参照するコマンドに変換するために使用されてもよい。

【0297】

単なる一例として、ＡＴＥテストプログラム１７２５は、リソース更新要求メッセージに含まれうる記号参照「ＶＣＣ１」を、特定のデバイス電源（例えば、デバイス電源１）の物理識別子（例えば、バスアドレス）に変換してもよい。記号参照は、例えば、自動試験機器の実際の物理的構成から独立していてもよく、むしろ被試験デバイスの命名規則に関連してもよいことに留意されたい。したがって、信号マッピングは、例えば、ＤＵＴ関連の記号参照から実際の物理的テスタリソースへの「変換ルール」を定義してもよい。

【0298】

結論として、ライブラリ１７７０は、ＯＣＳＴテストケースの開発、およびＡＴＥテストプログラムの開発を著しく容易にする。さらに、記号参照および信号マッピングの利用は、ＯＣＳＴテストケースの開発者のエラーリスクを低減し、さらに、異なるハードウェア構成のＡＴＥへの試験の移植を小さな労力で可能にする。

【0299】

さらに、ここで説明したライブラリ１７７０は、本書に開示される任意の他の試験構成および自動試験機器にも任意選択で導入されてもよいことに留意されたい。さらに、試験構成１７００は、本書に開示される任意の特徴、機能および詳細によって、別個にまたは組み合わせて任意選択で補完されてもよいことに留意されたい。

【0300】

さらに、ＡＴＥ１７１０および被試験デバイス１７３０の双方は、本発明に係る実施の形態とみなされてもよいことに留意されたい。

【0301】

１９．図１８に係る試験構成１８００

【0302】

図１８は、本発明の一実施の形態に係る試験構成１８００の概略図を示す。試験構成１８００は、自動試験機器１８１０と、被試験デバイス１８３０とを備える。自動試験機器は、テストリソース１８２０と、テストプログラム１８２４が実行されるワークステーション１８２２とを備える。さらに、自動試験機器１８１０は、ＯＣＳＴコントローラ１８２６も備える。被試験デバイス１８３０は、典型的にＯＣＳＴテストケース１８４０を実行するように構成される。

【0303】

自動試験機器１８１０に関して、テストリソース１８２０は、例えば上述したテストリソース８２０と同様でありうることに留意されたい。しかしながら、テスタリソース１８２０は、例えばＯＣＳＴコントローラ８２６と同様でありうるＯＣＳＴコントローラ１８２６にも（指向的に）結合されることに留意されたい。

【0304】

しかしながら、ＯＣＳＴコントローラ１８２６は、ＯＣＳＴテストケース１８４０からリソース更新要求１８５０を（例えば、メッセージの形式で）受信し、ＯＣＳＴテストケースに確認応答信号１８５２を（例えば、メッセージの形式で）提供するように構成されていることに留意されたい。しかしながら、ＯＣＳＴコントローラ１８２６は、例えばデータバスおよび同期バス１８８０を介して、一つ以上のテスタリソース１８２０に直接結合される。したがって、ＯＣＳＴコントローラ１８２６は、リソース更新要求１８５０に対する応答を直接的に（例えば、ワークステーション１８２２をバイパスする態様で）生じさせてもよい。例えば、ＯＣＳＴコントローラ１８２６は、リソース更新要求（またはリソース更新要求メッセージ）１８５０に応答して、データおよび同期バス１８８０（典型的には全てのテスタリソース１８２０とＯＣＳＴコントローラ１８２６とを相互接続するが、必ずしもそうではない）を介して一つ以上のテストリソース１８２０にアクセスしてもよい。したがって、リソース更新要求１８５０に応答して、ＯＣＳＴコントローラ１８２６は、リソース更新要求メッセージ１８５０で示される特定のテスタリソースにその特性を更新するように直接的に（例えば、ワークステーション１８２２をバイパスする態様で）指示してもよい。

【0305】

例えば、ＯＣＳＴコントローラ１８２６は、リソース更新要求１８５０にしたがって、特定のテスタリソース１８２０（例えば、デバイス電源またはクロック信号発生器など）にそのパラメータをＯＣＳＴコントローラ１８２６によって指定される新しいパラメータに変更させる命令またはコマンドを送信してもよい。例えば、ＯＣＳＴコントローラ１８２６は、ＯＣＳＴコントローラ１８２６と一つ以上のテスタリソース１８２０とを直接接続するデータバスに一つ以上のデータワードを書き込んでもよく、ＯＣＳＴコントローラ１８２６は、例えば、このようなデータバスアクセスにおいて所望のテスタリソース１８２０にアドレスを与えてもよい。例えば、データバス１８８０を介した一つ以上の適切なデータワードの送信は、指定された（またはアドレス指定された）テスタリソースにその特性（例えば、デバイス電源によって提供される電圧、またはクロック信号発生器によって提供されるクロック信号のクロック周波数）の更新を直接的に生じさせてもよい。しかし、いくつかの実装において、ＯＣＳＴコントローラ１８２６からデータバス１８８０を介して指定されたテスタリソースに通信される一つ以上のデータワードは、指定されたテスタリソースの新しいパラメータを単に定義してもよく、これは同期イベントに帯する応答においてのみアクティブになる。例えば、ＯＣＳＴコントローラは、同期バスを介して指定されたテスタリソース１８２０（または全てのテスタリソース１８２０）に対して同期イベントを通信することにより、その結果、テスタリソースの特性の実際の更新をトリガしてもよい。しかしながら、別の代替例として、ＯＣＳＴコントローラは、専用のトリガラインを介して指定されたテスタリソースにこのような同期を通信してもよい。例えば、同期ライン（図１８には不図示）のアクティブ化は、この同期ラインに結合される指定されたテスタリソースに新しい設定を引き受けさせてもよい（これは、テスタリソースの更新と見なすことができる）。

【0306】

結論として、ＯＣＳＴコントローラ１８２６とテスタリソース１８２０との間に（例えば、データおよび同期バス１８８０を介して、またはデータ接続および（任意選択で）一つ以上の専用同期ラインまたはトリガラインのような同期機構を用いて）直接結合を有することにより、ＯＣＳＴコントローラ１８２６は、非常に低いレイテンシで一つ以上のテスタリソースの更新を生じさせることができる。例えば、高速インタフェースを用いてＯＣＳＴテストケース１８４０との高速通信を確立するように通常構成されるＯＣＳＴコントローラ１８２６は、ＯＣＳＴテストケースからのリソース更新要求メッセージに非常に速く反応することができ、要求されたリソース更新の実行を一つ以上のテストリソースに直接的に指示することができる。したがって、ワークステーション１８２２またはＡＴＥテストプログラム１８２４によるリソース更新要求の取り扱いに依存する必要がなくなり、遅延時間を回避できるようになる。さらに、ＡＴＥテストプログラム１８２４の中断も、ＯＣＳＴコントローラに一つ以上のテスタリソースへの直接アクセスを与えるという概念を用いて回避できる。したがって、被試験デバイスの高速かつ効率的な試験を実現できる。

【0307】

さらに、試験構成１８００は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0308】

さらに、自動試験機器１８１０および被試験デバイス１８３０の双方は、本発明に係る実施の形態とみなされてもよいことに留意されたい。

【0309】

２０．図１９に係る試験構成

【0310】

図１９は、本発明の一実施の形態に係る試験構成１９００の概略図を示す。試験構成１９００は、自動試験機器１９１０および被試験デバイス１９３０を備える。自動試験機器は、例えばテスタリソース８２０、１８２０と同様でありうる、テスタリソース１９２０を備える。さらに、自動試験機器１９１０は、ワークステーション１９２２を備え、ＡＴＥテストプログラム１９２４は、ワークステーション１９２２上で実行されてもよい。ワークステーション１９２２は、例えば、上記の説明も適用されるように、ワークステーション８２２またはワークステーション１８２２と同様であってよい。さらに、自動試験機器１９１０は、例えばＯＣＳＴコントローラ８２６またはＯＣＳＴコントローラ１８２６と同様でありうる、ＯＣＳＴコントローラ１９２６を備える。

【0311】

しかしながら、一つ以上のテスタリソースは、ＧＰＯトリガライン１９９０からトリガ信号を受信するように構成されてもよい。例えば、自動試験機器１９１０は、ＤＵＴインタフェースでＧＰＯトリガラインにアクセス可能となるように構成されてもよい。例えば、ＧＰＯトリガラインは、（例えば、自動試験機器のＤＵＴインタフェースと被試験デバイス１９３０との間にあるロードボードを介して）被試験デバイス１９３０の汎用出力１９４２に結合されてもよい。例えば、被試験デバイス１９３０の汎用出力端子１９４２は、被試験デバイス上で実行されるテストケース１９４０によって制御されてもよい。したがって、ＯＣＳＴテストケース１９４０は、例えばＧＰＯトリガライン１９９０のアクティブ化によって、テストリソースの更新をトリガすることができる。その結果、ＯＣＳＴテストケース１９４０は、最小限のハードウェアおよびソフトウェアの労力を必要とする方法で、一つ以上のテスタリソース１９２０の更新を生じさせることが可能である。原則的には、試験構成において好ましくは他に使用されておらず、ＯＣＳＴテストケース１９４０によって合理的な労力でプログラムすることができる被試験デバイス１９３０の単一のピン（例えば、汎用出力ピン、または任意の他の出力ピン、または入出力ピン）を、テスタリソース更新をトリガするために使用できる。

【0312】

さらに、ＧＰＯトリガライン１９９０のアクティブ化に応答して更新される一つ以上のテスタリソースは、例えば、ＡＴＥテストプログラム１９２４によって事前プログラムされてもよいことに留意されたい。例えば、ＡＴＥテストプログラム１９２４は、特定のテスタリソース１９２０に、ＧＰＯトリガラインのアクティブ化に応答して（例えば、関連するＧＰＯトリガラインのアクティブ化に応答して）取るべき新しい状態を示す命令を提供してもよい。言い換えれば、ＡＴＥテストプログラムは、例えば、被試験デバイス１９３０上のＯＣＳＴテストケース１９４０の実行と粗い時間的同期をとってもよく、したがって、ＧＰＯトリガライン１９９０の次のアクティブ化に伴ってＯＣＳＴテストケース１９４０によってどのリソース更新が要求されるかを予測することが可能であってもよい。したがって、ＡＴＥテストプログラムは、特定のテスタリソースに今後の所望の特性に関する情報を提供することにより、次に更新される特性である特定のテスタリソースを事前構成してもよい。その後、特定テスタリソース１９２０は、ＯＣＳＴテストケースによるＧＰＯトリガライン１９９０のアクティブ化に応答して、事前構成された特性を使用するために更新を実行してもよい。したがって、ＡＴＥテストプログラム１９２０は、例えば、特定のテスタリソース１９２０で更新される新しい値を定義してもよく、ＯＣＳＴテストケース１９４０は、ＧＰＯトリガライン１９９０のアクティブ化によって、新しい特性（または新しい値）へのテスタリソースの更新がなされるべき正確なタイミングを決定する。このようなシナリオにおいて、事前設定が発生する時間は比較的クリティカルではない一方で、ＧＰＯトリガラインに対するアクティブ化に対する反応は、典型的には、十分に定義された時間期間内に（例えば、非常に高いタイミング精度で）発生する。このように、ＯＣＳＴテスト１９４０は、テスタリソースの更新のタイミングに対して非常に高い制御性を持つ一方で、テスタリソースの更新を実際に生じさせるためには、非常に単純な通信機構、すなわち単一のＧＰＯトリガラインで十分でありうる。

【0313】

しかしながら、いくつかの実施の形態において、ＯＣＳＴテストケース１９４０は、更新されるべき一つ以上のテスタリソースの所望の新しい特性（または所望の新しい設定）を通信することが可能であってもよい。例えば、ＯＣＳＴテストケース１９４０は、この目的のためにプロトコルベースの高速インタフェースを使用してもよく、通信は、例えば、ＯＣＳＴテストケース１９２０からＯＣＳＴコントローラに向けて、ＯＣＳＴコントローラからＡＴＥテストプログラムに向けて、およびＡＴＥテストプログラムからテスタリソースに向けて延びてもよい。しかしながら、代替的に、このような通信は、ＯＣＳＴテストケース１９４０からＯＣＳＴコントローラ１９２６に向けて、およびＯＣＳＴコントローラ１９２６からテスタリソース１９２０に向けて直接延びてもよく、ＯＣＳＴコントローラは、ＡＴＥテストプログラム１９２４をバイパスして、その特性の望ましい更新のためにテスタリソース１９２０を直接的に事前プログラムするようにしてもよい。

【0314】

結論として、一つ以上のテスタリソースの更新をトリガするトリガ信号を、被試験デバイスから受信する機能を自動試験機器に設けることにより、システム・オン・チップでありうる被試験デバイスが、テスタリソースの更新に対して非常に正確なタイミング制御を有することを実現できる。これにより、被試験デバイス上で実行されるＯＣＳＴテストケースの実行は、レイテンシが非常に低くなるため、非常に高速にすることが可能となる。また、例えば、電源電圧の一時的な低下や電源電圧のスパイクなど、試験環境の複雑な変化を、ＯＣＳＴテストケースの制御下で、ＯＣＳＴテストケースに対する非常に正確なタイミング関係で定義することができる。

【0315】

しかしながら、試験構成１９００は、本書に記載される任意の特徴、機能および詳細によって任意選択で補足されてもよいことに留意されたい。さらに、自動試験機器１９１０および被試験デバイス１９３０の双方は、本発明に係る実施の形態とみなされてもよいことに留意されたい。

【0316】

２０．さらなる実施の形態および態様

【0317】

一般的に言えば、ここに記載される技術革新に係る実施の形態は、ＡＴＥテスタリソース（ＴＲ）を制御する経路を介して、オン・チップ・システム・テスト能力を拡張するためのＡＴＥ統合ソリューションを説明する。

【0318】

２０．１．テスタリソース

【0319】

テスタリソースは、例えば、試験実行時にＤＵＴ（被試験デバイス）の電気環境、刺激生成、および信号評価の提供に用いられる自動試験機器（ＡＴＥ）に搭載されるハードウェア（ＨＷ）モジュールである。典型的なテストモジュールは、電源、デジタルＩＯ、混合信号ＩＯ、ＲＦＩＯなどの分野をカバーし、試験固有パターンおよび試験信号を適用および測定するための特徴を有する。

【0320】

２０．２．従来および新規のＴＲ制御経路の比較

【0321】

テスタリソースは、従来、例えばＡＴＥワークステーション上で実行されるＡＴＥテストプログラムによって制御される（例えば、図５と図６を参照）。ＡＴＥ環境の更新はいずれも、（例えば従来）テストプログラムによって開始され、ＯＣＳＴテストケースによる環境更新は予見されない。

【0322】

この概念において、テストケースは、例えば、テストケースが被試験デバイス（ＤＵＴ）上の組み込みソフトウェア（ＳＷ）として実行される機能的ＯＣＳＴテストケースであるような態様で定義されてもよい。また、テストプログラムは、例えば、テストを制御するためのワークステーション上で実行されるＡＴＥ固有のプログラムであるように定義される。

【0323】

しかしながら、ＡＴＥ環境を制御するためのＯＣＳＴテストケースの相互接続の欠如は、ＯＣＳＴ開発の使い勝手を大きく制限することが判明している。

【0324】

本発明の一態様によれば、ここで提案される解決策は、通信チャネルに基づくＯＣＳＴテストケースからＡＴＥテストプログラムへの新規の制御経路（例えば、図７および図８を参照）によってこの欠点を補償する。新規の制御経路は、例えばソフトウェアの手法によって実現され、テストケースとテストプログラムとの間で交換可能なメッセージを使用する。関連するメッセージの呼び出しは、例えばＡＰＩによって提供され、例えばテストケース内の任意のコード行に配置されることができる。

【0325】

上述のように、図７は、テスタリソース制御経路によって拡張されるＯＣＳＴの概略図を示す（ここで、テスタリソース制御経路は、例えば、リソース更新要求メッセージ７５０および確認メッセージ７５２の送信を可能にしてもよい）。

【0326】

さらに、図８は、テスタリソース制御経路を含むＯＣＳＴコントローラを含む変形例の概略図を示す。例えば、テスタリソース制御経路は、リソース更新要求メッセージ８５０、８６０の送信と、確認応答メッセージ８６２、８５２の送信とを可能にしてもよい。

【0327】

これらの機能は、本書に開示される任意の実施の形態において、個別にまたは組み合わせて任意選択で含まれてもよい。

【0328】

２０．３．メッセージに基づくテスタリソース制御フロー

【0329】

本発明の一態様によれば、ＡＴＥ環境構成は、例えば特定のパラメータ化されたメッセージをＡＴＥテストプログラムに送信することによって、ＯＣＳＴテストケースによって追加的に制御することができるようになった。例えば、テストプログラム内のメッセージハンドラは、メッセージを解釈し、メッセージパラメータに依存してテスタリソース更新を実行する。リソース更新の完了後、待機中のＤＵＴに確認応答メッセージが送信され、その後、ＤＵＴはテストケースの実行を継続する。

【0330】

図９は、テスタリソース制御のためのメッセージフローの概略図を示す。以下では、テスタリソース更新フローを簡単に説明する。

【0331】

テスタリソース更新フロー
１．ＯＣＳＴテストケースは、実行中にＡＰＩメッセージ呼び出しを使用してリソース更新を要求し、リソース更新確認応答メッセージを受信するまで待機ループに入る。
２．メッセージは、ＯＣＳＴコントローラを介してＡＴＥテストプログラムに伝搬され、メッセージハンドラによって解釈される。
３．テスタリソースは、解読（デコード）されたメッセージパラメータに依存して更新される。
４．確認応答メッセージは、同期化のためにテスタリソース更新の成功時にＯＣＳＴコントローラを介してＯＣＳＴテストケースに伝搬される。
５．ＯＣＳＴテストケースは、確認応答メッセージの受信後に実行を継続する。

【0332】

これらの機能は、本書に開示される任意の実施の形態に、個別にまたは組み合わせて人選択で含まれてもよい。

【0333】

２０．４．メッセージに基づくテスタリソース測定フロー

【0334】

本発明の一態様によれば、テスタリソースの制御の他に、メッセージインタフェースは、ＯＣＳＴテストケースによるリソース測定をトリガするためにも（代替的または追加的に）使用できる。これは、例えば、電源電圧のレベルや環境温度など、ＡＴＥ特有の環境条件に依存してＯＣＳＴテストケースを実行するのに有用である。

【0335】

例えば、図１０は、テスタリソース測定経路によって拡張されるＯＣＳＴの概略図を示す。例えば、テスタリソース測定経路は、リソース測定要求メッセージ１０５０および測定結果メッセージ１０５２の送信を可能にしてもよい。

【0336】

さらに、図１１は、テスタリソース制御経路を含むようにＯＣＳＴコントローラを含む変形例の概略図を示す。この場合、テスタリソース制御経路は、例えば、リソース測定要求メッセージ１１６０、１１７０の転送と、測定結果メッセージ１１７２、１１６２の送信とを可能にしてもよい。

【0337】

例えば、ＯＣＳＴテストケースは、ＡＴＥテストプログラム（例えば、ＡＴＥテストプログラム１１２４）にパラメータ化された測定メッセージ（例えば、メッセージ１１６０）を送信することによって、ＡＴＥリソース固有の測定をトリガできる。テストプログラム内（例えばＡＴＥテストプログラム１１２４内）のメッセージハンドラは、例えば、測定メッセージパラメータ（例えば電圧ＶＣＣ１を測定すべきことを示すパラメータ）を解釈してもよく、それは識別されたテスタリソース（例えば記号参照ＶＣＣ１によって指定された物理電圧を測定可能なテスタリソース）に測定の実行をトリガする。その後、リソース測定の結果は、例えば待機中のＤＵＴ１１３０に送り返され、ＤＵＴ１１３０は、例えば、受信した結果値（例えば、ＶＣＣ１が例えば５．４６Ｖなどの特定値を取ることを示す結果値）に依存してテストケースを継続する。

【0338】

図１２は、テスタリソース測定のためのメッセージフローの概略図を示す。

【0339】

以下では、テスタリソース測定フローの一例について説明する。

【0340】

テスタリソース測定フロー
１．ＯＣＳＴテストケースは、例えばＡＰＩメッセージ呼び出しを使用して実行中にリソース測定を要求し（例えばメッセージ１２５４）、例えば測定結果メッセージ（例えばメッセージ１２７０）を受信するまで待機ループに入る。
２．メッセージ（例えばメッセージ１２５４）は、例えばＯＣＳＴコントローラを介して、ＡＴＥテストプログラム（例えばＡＴＥテストプログラム１２２０）に伝搬され、メッセージハンドラによって（例えば、ＡＴＥテストプログラムの一部であるメッセージハンドラによって）解釈される。
３．テスタリソース（例えばテスタリソース１２１０）は、解読（デコード）されたメッセージパラメータに依存して（例えば、特定の電圧を測定すべきことを示すパラメータＶＣＣ１に依存して）測定を実行する。
４．測定値は、ＯＣＳＴコントローラを介してＯＣＳＴテストケースに伝搬される（例えば、メッセージ１２６０、１２７０を使用する）。
５．ＯＣＳＴテストケース（例えばＯＣＳＴテストケース１２４０）は、例えば、受信した結果に依存して（例えば、結果メッセージ１２７０によって記述された結果に依存して）実行を継続する。

【0341】

これらの機能は、本書に開示される任意の実施の形態に、個別にまたは組み合わせて任意選択で含まれてもよい。

【0342】

２０．５．テストケースの論理的展開および異なる試験類型のために必要な制御および通信インタフェース

【0343】

以下では、テストケースの論理的展開および異なる試験類型のために必要な制御および通信インタフェースについて説明する。

【0344】

以下では、いくつかの定義について説明する。例えば、テスタリソースは、試験実行中に電気環境、および／または刺激生成、および／またはＤＵＴの信号評価などを提供するために使用されるＡＴＥに実装されるハードウェア（ＨＷ）モジュールである。典型的にテスタモジュールは、例えば電源、デジタルＩＯ、混合信号ＩＯ、および／またはＲＦＩＯの分野をカバーし、例えば試験固有パターンおよび試験信号を適用および測定するための特徴を有する。

【0345】

ワークステーションは通常、ＡＴＥテストプログラムを実行し、テスタリソースを制御する。テストプログラムは、例えば、試験トポロジーに依存して、テストコントローラを制御するか、またはＤＣＣＰインタフェースを介してテストケースを直接制御する。例えば、ＤＣＣＰ－ＩＦを介して、テストコントローラまたはテストケースから入ってくる通信メッセージに追加的に耳を傾けている。例えば、ワークステーションは、被試験デバイスに直接結合されてもよいし、ＯＣＳＴコントローラは、ワークステーションと被試験デバイスとの間の仲介役として機能してもよい。

【0346】

ＦＴサービス機器（または機能テストケース・サービス機器）は、例えば、ＤＵＴテストコントローラ（例えば、ＯＣＳＴコントローラ）を含むＣＰＵでサポートされたハードウェア（ＨＷ）インスタンスである。

【0347】

テストコントローラ（またはＯＣＳＴコントローラ）は、例えば、ＤＵＴテストケースのアップロード処理を取り扱い、テストケースの実行を制御し、実行結果情報を収集する。

【0348】

テストケースは、例えば、ＤＵＴのプロセッサシステム上で実行される機能テストコードである。それは、例えば、ＦＴサービス機器またはワークステーションへの物理的なインタフェース部分を取り扱うためのソフトウェア（ＳＷ）部分を含むことができる。例えば、テストケースは、（例えば上記のような）高速インタフェースを介してワークステーションまたはＯＣＳＴコントローラと通信可能にするためのドライバソフトウェアを備えてもよい。しかしながら、ドライバソフトウェアは必ずしもテストケースの一部である必要はなく、例えば、被試験デバイス上で動作するオペレーティングシステムの一部であってもよい。

【0349】

ＤＣＣＰインタフェース（ＤＣＣＰ－ＩＦ）は、例えば、以下のために使用される、データ、制御、通信経路インタフェース（ＤＣＣＰ－ＩＦ）である。
－テストケースのアップロードおよび／または制御、および／または
－例えばテスタリソースの更新および／測定のための、テストプログラムとテストケースの間の通信経路。

【0350】

ＤＣＣＰインタフェースは、例えば、上述の高速インタフェースの一つであってもよい。

【0351】

ＤＵＴは、例えば、機能試験を実行するためのプロセッサシステムを含む被試験デバイスである。

【0352】

ＤＵＴは、例えば、機能試験を実行するためのプロセッサシステムを含む被試験デバイスである。

【0353】

図１３～１６は、異なる試験構成を示す。

【0354】

図１３は、機能テストケース１３４０が被試験デバイス１３３０上に完全に配置されている試験構成を示す。テストコントローラへのＤＣＣＰ－ＩＦ１３６２は、例えば、ＨＳＩＯ－ＰＣＩｅまたはＵＳＢのような物理インタフェースによって実現される。

【0355】

図１４は、機能テストケース１４４０がＤＵＴ部分とＦＳＩ部分に論理的に分割されている試験構成を示す。テストコントローラ１４５２とテストケース１４４０との間のＤＣＣＰインタフェース１４６２は、例えば、ＦＳＩ上で実行されるソフトウェア（ＳＷ）により実現される。ＦＳＩとＤＵＴの物理的な接続を取り扱うソフトウェアは、例えば、テストケースの内部に配置される。

【0356】

図１５は、テストケース１５４０が被試験デバイス１５３０上に完全に配置されている試験構成を示す。ＡＴＥテストプログラム１５２４へのＤＣＣＰ－ＩＦ１５５０は、例えば、ＨＳＩＯ－ＰＣＩｅやＵＳＢのような物理インタフェースによって実現される。

【0357】

図１６は、機能テスト１６４０がＤＵＴ部とワークステーション部に論理的に分割されている試験構成を示す。この二つの部分の間のＤＣＣＰインタフェースは、例えば、ワークステーション上で実行されるソフトウェアによって実現される。ワークステーション１６２２とＤＵＴ１６３０の物理的な接続を取り扱うソフトウェアは、例えば、テストケース１６４０の内部に配置されている。

【0358】

これらの機能は、本書に開示される任意の実施の形態に、個別にまたは組み合わせて任意選択で含まれてもよい。

【0359】

２０．６．ＯＣＳＴテストケースによるＡＴＥ環境制御を可能にする利点

【0360】

２０．６．１ リソース制御をテストケースの実行と同期できる。

【0361】

本発明の一態様によれば、テストケース実行中のテスタリソース更新が可能になった。更新は、例えば、テストケースの実行前だけでなく、テストケースプログラムの任意のコード行で発生させることができる。対照的に、従来手法は、テストケースの実行中にテストリソースを変化させることを許容しなかった。

【0362】

２０．６．２ テストケースパラメータによってテスタリソースを構成可能

【0363】

本発明の一態様によれば、テストケース呼び出しのパラメータは、テスタリソースの更新を開始するために使用できる。これにより、テストケースのバリエーションおよび柔軟性が拡張される。

【0364】

２０．６．３ ＡＴＥ専門家のサポートを必要としないＯＣＳＴテストケースの開発

【0365】

ユースケースに固有のテストケースは、一般的に検証エンジニアがＤＵＴの内部を熟知しているため、検証エンジニアによって開発される。しかし、従来は、特定のＡＴＥ環境でＯＣＳＴテストケースを実行するために、試験エンジニアによる更なるＡＴＥテストプログラムの適合が必要であった。

【0366】

単一のＯＣＳＴは、今まで（例えば従来）、以下を必要とした。
－テストプログラムとテストケースを整合させるための開発労力。
－ＯＣＳＴテストケースおよびＡＴＥテストプログラムを生成する検証エンジニアおよび試験エンジニア。

【0367】

ＯＣＳＴを開発する労力は、ＡＴＥ環境制御をテストプログラムからＯＣＳＴテストケースに移行するここに記載される解決策により、大幅に削減できることが判明している。例えば、独自のテストプログラムは、全てのＯＣＳＴテストケースで使用され、保証された安全なＤＵＴの起動のためのＡＴＥ環境の設定のために必要となるかもしれない。さらなるテストケース固有のＡＴＥ環境の更新は、ＯＣＳＴテストケース自体によって現在（例えば本発明の一態様にしたがって）制御されている。したがって、検証エンジニアは、ＡＴＥ環境を制御でき、テストケースを独自に実行できるようになったため、試験エンジニアから独立できる。オンチップ・システム・テストの開発は、例えば、ＯＣＳＴテストケースに限定されるようになった。

【0368】

２０．６．４ ＡＴＥ環境制御およびＯＣＳＴテストケースシーケンスの一本化

【0369】

本発明の一態様によれば、ＡＴＥテストプログラムとＯＣＳＴテストケースとの間に依存関係はもはや存在しない。本発明に係るいくつかの実施の形態において、テスタリソース制御およびテストケース開発は、現在、一つのテストケース・ソースファイルに配置される。

【0370】

しかしながら、例えば、テスタリソースの初期化は、依然としてＡＴＥテストプログラムにおいて提供されてもよいことに留意されたい。また、場合によっては、ＡＴＥテストプログラムとテストケースとの間に少なくとも粗い時間的同期が存在してもよい。

【0371】

２０．６．５ ＡＴＥに依存しないＯＣＳＴテストケースの開発可能性

【0372】

本発明の一態様によれば、テストケース開発のためのＡＴＥ環境に関する知識は必要とされない。テスタリソースは、例えば、検証エンジニアが抽象的な記号信号参照、目標値および／または一つ以上のメッセージパラメータの形式によるモード設定によって（またはそれを使用して）アクセスされる。パラメータの解釈と、それによって生じるテスタリソースのテスト固有のプログラミングシーケンスは、例えば、ＡＴＥテストプログラム内のメッセージハンドラによって実行される。

【0373】

２０．６．６ ハードウェア（ＨＷ）の適合は不要

【0374】

本発明の一態様によれば、テスタリソース更新の概念は、純粋なソフトウェア手法に基づく。場合によっては、本発明に係る概念を実装するために、ＡＴＥ上のハードウェアの適合は必要ない。

【0375】

しかしながら、上述した利点の一つ以上は、例えば、本発明に係る実施の形態に存在してもよいことに留意されたい。

【0376】

２１．ＡＴＥ環境制御をサポートするライブラリ

【0377】

以下では、本発明の（任意選択の）態様に係る、ＡＴＥ環境制御をサポートするライブラリの利用について説明する。

【0378】

これらの機能は、本書に開示される任意の実施の形態に、個別にまたは組み合わせて任意選択で含まれてもよい。

【0379】

例えば、図１７は、（例えば、試験構成の文脈で）ＡＴＥ環境制御をサポートするためのライブラリの概略図を示す。

【0380】

２１．１．異なるＤＵＴをサポートするためのメッセージＡＰＩ

【0381】

ＡＴＥ環境制御のためのＡＰＩは、例えば、ＡＴＥテストプログラムとのメッセージ交換のために、事前定義されるメソッドを使用する。ＤＵＴ固有のインタフェース（例えばＵＳＢおよび／またはＰＣＩｅ）に対応し、異なるＤＵＴプロセッサ・コア・タイプ（例ＡＲＭ、Ａｔｍｅｌ、マイクロチップなど）に適合するために、例えばメッセージＡＰＩの異なるバージョンを有するライブラリが準備されてもよい。

【0382】

例えば、ライブラリは、異なる種類のインタフェース（例えば、異なる種類の高速インタフェース）を介して一つ以上の種類のメッセージ（例えば、リソース更新要求メッセージまたはリソース測定要求メッセージ）の送信のためのアプリケーション・プログラミング・インタフェースを備えてもよい。さらに、ライブラリは、異なる種類のＤＵＴプロセッサコアでの利用に適合される、メッセージＡＰＩに予め定義される当該関数またはメソッドの実装を備えてもよい。

【0383】

したがって、検証エンジニアは、例えば、一つ以上の適切なメッセージＡＰＩを使用し、使用される異なる種類のＤＵＴプロセスコアおよび異なる種類の（高速）インタフェースのためにライブラリに提供される予め定義された実装を（例えば、リンカーを使用するテストケースに含めることができる、予めコンパイルされたコードの形式で）使用してテストケースを生成してもよい。したがって、検証エンジニアは、リソース更新要求またはリソース測定要求のための関数またはメソッドの特定の実装を気にする必要がなく、単にライブラリ１７７０で提供される予め定義されたメッセージＡＰＩを使用すればよいため、ＯＣＳＴテストケースの開発は検証エンジニアとって非常に簡単である。

【0384】

２１．２ リソースおよびチャネルを識別するための記号参照

【0385】

本発明の一態様によれば、テスタリソースの属性（プロパティ）、モードおよび信号は、メッセージのパラメータによって選択され、記号参照として表される。例えば、テストケース開発者は、それらの参照を使用して、例えば、ＤＵＴに適用される全ての種類の信号を制御し、例えば、ＤＵＴの供給環境を制御できる。例えば、ＡＴＥテストプログラム内のメッセージハンドラは、記号参照を使用して、テスタリソースおよび／またはテスタチャンネルおよび／または動作モードを識別し、予め定義されたリソース固有シーケンスによって要求される動作を実行する。

【0386】

以下に、単純な例を提供する。

【0387】

この例では、供給電圧ＶＣＣ２は５Ｖに設定されるべきである。

【0388】

例示的なＡＰＩ呼び出しは、「メッセージ（「ＶＣＣ２」，５Ｖ）」の形式を取ってもよい。

【0389】

メッセージハンドラは、例えばマッピングテーブルの記号参照「ＶＣＣ２」を検索することによって、パラメータ「ＶＣＣ２」を電源モジュール固有のテストリソースとして識別する。「ＶＣＣ２」の電圧設定は、目標電圧「５Ｖ」およびリソースチャネル「１０１０３」のパラメータを含む、予め定義されたサプライ・モジュール・プログラミング・シーケンスによって実行される。

【0390】

マッピングテーブルの例

【表1】

【0391】

結論として、マッピングテーブルは、例えば、「信号マッピング」を定義してもよく、例えば、ライブラリに含まれてもよい。例えば、マッピングテーブルは、信号または量の記号参照を、特定のテスタリソースを識別する物理リソース識別子にマッピングしてもよい。したがって、マッピングテーブルは、自動試験機器のハードウェア構成が変更された場合（例えば、テスタリソースモジュールの削除またはテスタリソースモジュールの追加によって）変更されてもよい。したがって、ＯＣＳＴテストケースは、記号参照を使用することができ、記号参照は、次に、例えばＡＴＥテストプログラムによって（または、代替的にＯＣＳＴコントローラによって）、マッピングテーブルを使用して物理テスタリソースの参照に変換される。

【0392】

２２．ＯＣＳＴによって制御されるＡＴＥ環境の別の変形例

【0393】

以下では、本発明に係る実施の形態にしたがって、ＯＣＳＴによって制御されるＡＴＥ環境の別の任意選択の変形例について説明する。

【0394】

２２．１．同期バスイベントによるテスタリソース制御

【0395】

本発明の一態様によれば、全てのテストリソース（または少なくとも一部のテストリソース）およびＯＣＳＴコントローラは、データ同期バスによって相互接続される。バスシステムは、データを交換し、バス・メンバー間で同期イベントを送信するために使用される。例えば、テスタリソースの更新は、ＯＣＳＴテストケースからＯＣＳＴコントローラに送信されるメッセージによって開始される。ＯＣＳＴコントローラは、データバス構成シーケンスによって、メッセージパラメータに依存して選択されたテスタリソースを初期化し、例えば、専用の同期バスイベントによって新しい設定をアクティブにする。

【0396】

図１８は、データ同期バスによるテスタリソースコントローラの概略図を示す。

【0397】

以下では、テストリソース更新フローの一例について説明する。
１．ＯＣＳＴテストケース（例えば、ＯＣＳＴケース１８４０）は、ＯＣＳＴコントローラ（例えば、ＯＣＳＴコントローラ１８２６）に送信されるメッセージ（例えば、メッセージ１８５０）によってテスタリソースの更新を要求し、例えば、ループに入って更新を確認応答するメッセージ（例えば、メッセージ１８５２）を待つ。
２．ＯＣＳＴコントローラ（例えば、ＯＣＳＴコントローラ１８２６）は、（例えば、リソース更新要求メッセージ１８５０に含まれる）メッセージパラメータに依存して（例えば、テストリソース１８２０の中から）選択されたテスタリソースを構成し、例えば、同期バス（例えば、データ同期バス１８８０）上の専用のトリガ信号を介して新しい設定をアクティブにする。
３．確認応答メッセージ（例えば、確認メッセージ１８５２）は、成功した更新にフラグを立てる（または通知する）ためにＯＣＳＴテストケースに送り返される。例えば、テストケースは、確認応答待ちループ（ＡＣＫ待機ループ）を離れ、処理を継続する。

【0398】

本発明に係るこの実施の形態は、本書に開示される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0399】

また、これらの機能性のいずれかも、個別にまたは組み合わせて、本書に開示される任意の実施の形態に任意選択で含まれてもよい。

【0400】

２２．２．ＧＰＯトリガによるテスタリソース制御

【0401】

本発明の一態様によれば、ＤＵＴのＧＰＯポート（例えば、汎用出力ポート）は、テスタリソースと相互接続され、事前構成されたリソース構成をアクティブ化するためのトリガラインとして使用される。単なる一例として、ＤＵＴの単一の汎用出力ポート（または汎用出力ピン）がテスタリソースと相互接続されてトリガラインとして使用されることで十分であってもよい。しかしながら、ＤＵＴの複数の汎用出力ポートまたは汎用出力ピンがテスタリソースと相互接続されてトリガラインとして使用されることも可能である。

【0402】

これにより、ＯＣＳＴテストケースは、関連するＧＰＯラインを設定することにより（すなわち、被試験デバイスの汎用出力ポートまたは汎用出力ピンを所定の状態、例えば、アクティブ状態に設定することにより）、テストリソースを更新することが可能である。

【0403】

ＯＣＳＴテストケースの実行前に意図された構成をＡＴＥテストプログラムによって準備する必要がありうるため、いくつかの場合、テストプログラムとテストケースが独立していないことがわずかな欠点となる。したがって、この手法は、いくつかの場合、動的なリソース更新に対して柔軟性に欠ける。また、いくつかの場合、ＧＰＯラインごとに一つの構成しかサポートできず、ＧＰＯラインをテスタリソースにルーティングするためのハードウェア変更が必要となる。

【0404】

しかしながら、これらのわずかな欠点は、例えば自動試験機器がＯＣＳＴテストケースの制御下で意図された更新構成を準備しうるように、例えばトリガラインのアクティブ化の前に、所望のリソース更新を自動試験機器に伝達する可能性をＯＣＳＴテストケースに提供することによって、任意選択で克服されてもよいことに留意されたい。さらに、特定のＧＰＯライン（またはトリガライン）のアクティブ化に応答して使用される更新構成を動的に変更することにより、非常に高いタイミング精度を有する良好な機能を達成できる。

【0405】

さらに、ＧＰＯラインをテスタリソースにルーティングするためのハードウェアの変更も、いくつかの場合にわずかとなる。

【0406】

一例として、図１９は、ＧＰＯトリガによるテスタリソース制御の概略図を示す。

【0407】

以下では、テストリソース更新フローの例が説明される。
１．ＡＴＥテストプログラム（例えば、ＡＴＥテストプログラム１９２４）は、（例えば、テストリソース１９２０から）各テスタリソースの目標構成を初期化する。
２．ＯＣＳＴテストケース（例えば、ＯＣＳＴテストケース１９４０）は、ＧＰＯラインアクティブ化によって（例えば、ＧＰＯトリガライン１９４０のアクティブ化によって）テスタリソース更新を要求する。
３．予め構成された（例えば、ステップ１で予め構成された）テスタリソース設定は、ＧＰＯトリガイベントの検出によってアクティブ化される（ここで、例えば、ＧＰＯトリガイベントの検出は、テスタリソースで生じる）。

【0408】

さらに、本発明に係るこの実施の形態は、本書に記載される任意の特徴、機能および詳細によって、個別にまたは組み合わせて任意選択で補足されてもよいことに留意されたい。

【0409】

２３．実施例の代替例

【0410】

いくつかの態様が装置の文脈で説明されたが、これらの態様は、ブロックまたはデバイスが方法ステップまたは方法ステップの特徴に対応する場合、対応する方法の説明も表していることは明らかである。同様に、方法ステップの文脈で説明される態様は、対応するブロックまたは項目または対応する装置の特徴の説明も表す。方法ステップの一部または全ては、例えば、マイクロプロセッサ、プログラマブル・コンピュータまたは電子回路などのハードウェア装置によって（またはそれを用いて）実行されてもよい。いくつかの実施の形態において、一つ以上の最も重要な方法ステップは、そのような装置によって実行されてもよい。

【0411】

特定の実装要件に依存して、本発明の実施の形態は、ハードウェアまたはソフトウェアで実装されることができる。実装は、例えばフロッピーディスク、ＤＶＤ、ブルーレイ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリなどのデジタル記憶媒体であって、それらに格納される電子的に読み取り可能な制御信号を有し、それぞれの方法が実行されるようにプログラム可能なコンピュータシステムと協働する（または協働できる）デジタル記憶媒体を用いて実行できる。したがって、デジタル記憶媒体は、コンピュータ可読であってもよい。

【0412】

本発明に係るいくつかの実施の形態は、電子的に読み取り可能な制御信号を有するデータキャリア（担体）であって、本書に記載される方法の一つが実行されるように、プログラム可能なコンピュータシステムと協働可能なデータキャリアを備える。

【0413】

一般に、本発明の実施の形態は、プログラムコードを有するコンピュータプログラム製品として実施されることができ、プログラムコードは、コンピュータプログラム製品がコンピュータ上で実行されるときに、方法の一つを実行するために動作可能である。プログラムコードは、例えば、機械読み取り可能な担体に格納されてもよい。

【0414】

他の実施の形態は、本書に記載される方法の一つを実行するための、機械可読担体に格納されるコンピュータプログラムを備える。

【0415】

言い換えれば、本発明の方法の実施の形態は、したがって、コンピュータプログラムがコンピュータ上で実行されるときに、本書に記載される方法の一つを実行するためのプログラムコードを有するコンピュータプログラムである。

【0416】

本発明の方法のさらなる実施の形態は、したがって、本書に記載される方法の一つを実行するためのコンピュータプログラムを記録して備えるデータキャリア（またはデジタル記憶媒体、またはコンピュータ可読媒体）である。データキャリア、デジタル記憶媒体、または記録媒体は、典型的には、有形および／または非一時的である。

【0417】

したがって、本発明の方法のさらなる実施の形態は、本書に記載される方法の一つを実行するためのコンピュータプログラムを表すデータストリームまたは信号のシーケンスである。データストリームまたは信号のシーケンスは、例えば、データ通信接続、例えばインターネットを介して転送されるように構成されてもよい。

【0418】

さらなる実施の形態は、本書に記載される方法の一つを実行するように構成または適合される、例えばコンピュータ、またはプログラマブル・ロジック・デバイスなどの処理手段を備える。

【0419】

さらなる実施の形態は、本書に記載される方法の一つを実行するためのコンピュータプログラムがインストールされたコンピュータを備える。

【0420】

本発明に係るさらなる実施の形態は、本書に記載される方法の一つを実行するためのコンピュータプログラムを受信器に（例えば、電子的または光学的に）転送するように構成される装置またはシステムを備える。受信器は、例えば、コンピュータ、モバイルデバイス、メモリデバイスなどであってもよい。装置またはシステムは、例えば、コンピュータプログラムを受信器に転送するためのファイルサーバを備えてもよい。

【0421】

いくつかの実施の形態において、プログラマブル・ロジック・デバイス（例えば、フィールド・プログラマブル・ゲート・アレイ）を使用して、本書に記載される方法の機能の一部または全てを実行してもよい。いくつかの実施の形態において、フィールド・プログラマブル・ゲート・アレイは、本書に記載される方法の一つを実行するためにマイクロプロセッサと協働してもよい。一般に、本方法は、任意のハードウェア装置によって実行されることが好ましい。

【0422】

本書に記載される装置は、ハードウェア装置を用いて、またはコンピュータを用いて、またはハードウェア装置とコンピュータの組み合わせを用いて実施されてもよい。

【0423】

本書に記載される装置、または本書に記載される装置の任意の構成要素は、少なくとも部分的にハードウェアおよび／またはソフトウェアで実装されてもよい。

【0424】

本書に記載される装置は、ハードウェア装置を用いて、またはコンピュータを用いて、またはハードウェア装置とコンピュータの組み合わせを用いて実施されてもよい。

【0425】

本書に記載される方法、または本書に記載される装置の任意の構成要素は、少なくとも部分的にハードウェアによって、および／またはソフトウェアによって実行されてもよい。

【0426】

上述した実施の形態は、本発明の原理について単なる例示をするものである。本書に記載される構成および詳細の修正および変形は、当業者には明らかであることが理解されよう。したがって、以下の特許請求項の範囲によってのみ限定され、本書における実施の形態の記載および説明によって提示される特定の詳細によって限定されないことが意図される。

【図1a】

【図1b】

【図2a】

【図2b】

【図2c】

【図3a】

【図3b】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【国際調査報告】