(57)【要約】遅延スケジューリング能力は、テストされるユニットのスキャン・チェーンを介してテスティングを実行する時に、遅延スケジューリングをサポートする。処理モジュールは、テストされるユニットの複数のセグメントに関連する複数のテスト動作を受け取り、そこから、テスト・アクセス・ポート（ＴＡＰ）を介してテストされるユニットに適用されるように構成された入力テスト・データを生成するように構成されている。リオーダリング・バッファ・モジュールは、処理要素から入力テスト・データを受け取り、テストされるユニットのスキャン・チェーンの入力テスト・ベクトルを構成するために入力テスト・データをリオーダリングする形で入力テスト・データをバッファリングするように構成されている。ベクトル変換モジュールは、リオーダリング・バッファ・モジュールから入力テスト・ベクトルを受け取り、入力テスト・ベクトルに関するベクトル変換を適用するように構成されている。
2015507743.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサおよび前記プロセッサに通信的に接続されたメモリを備える装置であって、前記プロセッサは、
テストされるユニットのスキャン・チェーンの複数のセグメントに関連する複数のテスト動作を受け取り、
前記テスト動作から、テスト・アクセス・ポート（ＴＡＰ）を介して前記テストされるユニットに適用されるように構成された入力テスト・データを生成し、
前記テストされるユニットの前記スキャン・チェーンの入力テスト・ベクトルを構成するために前記入力テスト・データをリオーダリングする形で前記入力テスト・データをバッファリングし、
前記入力テスト・ベクトルに関してベクトル変換を適用する
ように構成されている、装置。
【請求項２】
前記テスト動作の少なくとも一部は、
テスト動作を生成するように構成されたアプリケーション、
テスト動作をスケジューリングするように構成されたスケジューラ、および
テスティング・ツール
のうちの１つから受け取られる、請求項１に記載の装置。
【請求項３】
前記入力テスト・ベクトルに関する前記ベクトル変換の適用は、変換された入力テスト・ベクトルを作るように構成され、前記プロセッサは、
前記変換された入力テスト・ベクトルをＴＡＰに供給する
ように構成されている、請求項１に記載の装置。
【請求項４】
前記プロセッサは、
前記入力テスト・データを生成するように構成された処理モジュールと、
前記テストされるユニットの前記スキャン・チェーンの前記入力テスト・ベクトルを構成するために前記入力テスト・データをリオーダリングする形で前記入力テスト・データをバッファリングするように構成されたリオーダリング・バッファ・モジュールと、
前記入力テスト・ベクトルに関して前記ベクトル変換を適用するように構成されたベクトル変換モジュールと
を実行するように構成されている、請求項１に記載の装置。
【請求項５】
前記プロセッサは、
前記テストされるユニットの出力テスト・ベクトルを受け取ることであって、前記出力テスト・ベクトルは、出力テスト・データを含む、受け取ることと、
変換された出力テスト・データを提供するために前記出力テスト・ベクトルにベクトル変換を適用することと
を行うようにさらに構成されている、請求項１に記載の装置。
【請求項６】
前記プロセッサは、
前記テストされるユニットの前記スキャン・チェーンの完全な出力テスト・ベクトルを形成するために前記変換された出力テスト・データを表す前記変換された出力テスト・データをバッファ内に保存し、
前記変換された出力テスト・データを、前記スキャン・チェーンのそれぞれの前記セグメントの位置および長さに対応するバッファリングされたセグメントに区分する
ようにさらに構成されている、請求項５に記載の装置。
【請求項７】
前記プロセッサは、
前記変換された出力テスト・データを、前記出力テスト・データがそれに関して要求されたテスト動作にマッピングし、
前記テスト動作に関連する１つまたは複数のユーザ・アプリケーションを決定し、
前記テスト動作に関連する前記１つまたは複数のユーザ・アプリケーションにテスト結果データを提供する
ようにさらに構成されている、請求項６に記載の装置。
【請求項８】
前記プロセッサは、
前記テスト結果データが関連する前記１つまたは複数のユーザ・アプリケーションに向かって前記テスト結果データを伝搬させること、または
前記テスト動作がそこから受け取られたスケジューラに向かって前記テスト結果データを伝搬させること
うちの少なくとも１つのためにさらに構成される、請求項７に記載の装置。
【請求項９】
プロセッサによって実行された時に、前記プロセッサに方法を実行させる命令を格納する非一時的コンピュータ可読記憶媒体であって、前記方法は、
テストされるユニットのスキャン・チェーンの複数のセグメントに関連する複数のテスト動作を受け取るステップと、
前記テスト動作から、テスト・アクセス・ポート（ＴＡＰ）を介して前記テストされるユニットに適用されるように構成された入力テスト・データを生成するステップと、
前記テストされるユニットの前記スキャン・チェーンの入力テスト・ベクトルを構成するために前記入力テスト・データをリオーダリングする形で前記入力テスト・データをバッファリングするステップと、
前記入力テスト・ベクトルに関してベクトル変換を適用するステップと
を含む、非一時的コンピュータ可読記憶媒体。
【請求項１０】
テストされるユニットのスキャン・チェーンの複数のセグメントに関連する複数のテスト動作を受け取るステップと、
前記テスト動作から、テスト・アクセス・ポート（ＴＡＰ）を介して前記テストされるユニットに適用されるように構成された入力テスト・データを生成するステップと、
前記テストされるユニットの前記スキャン・チェーンの入力テスト・ベクトルを構成するために前記入力テスト・データをリオーダリングする形で前記入力テスト・データをバッファリングするステップと、
前記入力テスト・ベクトルに関してベクトル変換を適用するステップと
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、それぞれが２００９年３月４日に出願した米国特許仮出願第６１／１５７４１２号、名称「ＴＥＳＴ  ＩＮＳＴＲＵＣＴＩＯＮ  ＳＥＴ  ＡＲＣＨＩＴＥＣＴＵＲＥ」の利益を主張する、それぞれ２００９年６月３０日に出願した、米国特許出願第１２／４９５２３７号、名称「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＳＹＳＴＥＭ  ＴＥＳＴＩＮＧ  ＵＳＩＮＧ  ＭＵＬＴＩＰＬＥ  ＩＮＳＴＲＵＣＴＩＯＮ  ＴＹＰＥＳ」（弁理士整理番号第ＡＬＵ／１３０１３７号）、米国特許出願第１２／４９５２９５号、名称「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＳＹＳＴＥＭ  ＴＥＳＴＩＮＧ  ＵＳＩＮＧ  ＭＵＬＴＩＰＬＥ  ＰＲＯＣＥＳＳＯＲＳ」（弁理士整理番号第ＡＬＵ／１３０１３７−２号）、および米国特許出願第１２／４９５３３６号、名称「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＳＹＳＴＥＭ  ＴＥＳＴＩＮＧ  ＵＳＩＮＧ  ＳＣＡＮ  ＣＨＡＩＮ  ＤＥＣＯＭＰＯＳＩＴＩＯＮ」（弁理士整理番号第ＡＬＵ／１３０１３７−３号）の一部継続出願であり、これらの特許出願は、これによってその全体が参照によって本明細書に組み込まれている。本願は、これによってその全体が参照によって本明細書に組み込まれている、米国特許出願第１３／３３８４３１号、名称「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＰＯＳＩＴＩＯＮ−ＢＡＳＥＤ  ＳＣＨＥＤＵＬＩＮＧ  ＦＯＲ  ＪＴＡＧ  ＳＹＳＴＥＭＳ」（弁理士整理番号第８０９７３２−ＵＳ−ＣＩＰ号）に関する。
【０００２】
本発明は、一般に、ＪＴＡＧシステムに関し、より詳細には、それに限定されないが、ＪＴＡＧシステムでのテスティングのスケジューリングに関する。
【背景技術】
【０００３】
Joint Test Action Group（ＪＴＡＧ）アプリケーションでは、テストされるシステム（System Under Test、ＳＵＴ）へのアクセスは、ＳＵＴのスキャン・チェーンへのベクトルの適用によって実現される。ベクトルは、ＳＵＴのスキャン・チェーンへのインターフェースを提供する標準化されたテスト・アクセス・ポート（Test Access Port、ＴＡＰ）に直列に適用される。ベクトルは、スキャン・チェーン内の各ビットのバイナリ値を表す。通常のテスト・ルーチンは、２〜３個のベクトル・ビットから多数のベクトル・ビット（たとえば、数百個、数千個、またはそれ以上）の範囲を含むことができる。その結果、ベクトル・セットを計算し、ＴＡＰに直列に適用しなければならないことを考慮すると、ベクトル・セットのサイズは、特に組込みアプリケーションで、ＳＵＴのテスティングにおける重要な考慮事項である。さらに、ベクトルは、特定のＪＴＡＧセットアップのために計算され、したがって、ＪＴＡＧセットアップが変化するたびに変更される必要がある（特に再標的化（retargeting）するサブシステムが複雑な時に非常に煩わしい、再標的化として知られている動作）。その結果、動的テスティング（たとえば、ベクトル入力を実際の出力に基づいて「オン・ザ・フライで」適合させなければならない状況）は、スキャン・チェーン全体の連続的な再標的化を必要とするので制限され、同様に、動的トポロジの使用（たとえば、スキャン・チェーンの長さが、ある要素の値に応じて変化する場合）は、命令の並列使用が、要求される再標的化に関連する計算強度のゆえに非常に難しいので制限される。したがって、理論的には可能であるが、上で説明した問題は、動的でポータブルなテスティングを実現不能にする。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】ＩＥＥＥ１１４９．１標準規格
【非特許文献２】「Ｔｈｅ  ＳＰＡＲＣ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｍａｎｕａｌ  Ｖｅｒｓｉｏｎ  ８」、ＳＰＡＲＣ  Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ刊、１９９２年
【非特許文献３】「Ｓｅｒｉａｌ  Ｖｅｃｔｏｒ  Ｆｏｒｍａｔ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ＡＳＳＥＴ  ＩｎｔｅｒＴｅｃｈ，Ｉｎｃ．、１９９７年
【非特許文献４】ＳＰＡＲＣ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｍａｎｕａｌの項４．２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来技術のさまざまな不足は、スキャン・チェーン・アクセスのスケジューリングによって対処される。
【課題を解決するための手段】
【０００６】
一実施形態では、装置は、処理モジュール、リオーダリング・バッファ・モジュール、およびベクトル変換モジュールを含む。処理モジュールは、テストされるユニットの複数のセグメントに関連する複数のテスト動作を受け取り、そこから、テスト・アクセス・ポート（ＴＡＰ）を介してテストされるユニットに適用されるように構成された入力テスト・データを生成するように構成されている。リオーダリング・バッファ・モジュールは、処理要素から入力テスト・データを受け取り、テストされるユニットのスキャン・チェーンの入力テスト・ベクトルを構成するために入力テスト・データをリオーダリングする形で入力テスト・データをバッファリングするように構成されている。ベクトル変換モジュールは、リオーダリング・バッファ・モジュールから入力テスト・ベクトルを受け取り、入力テスト・ベクトルに関してベクトル変換を適用するように構成されている。
【０００７】
一実施形態では、非一時的コンピュータ可読記憶媒体は、プロセッサによって実行された時に、プロセッサに、テストされるユニットの複数のセグメントに関連する複数のテスト動作を受け取るステップと、テスト動作から、テスト・アクセス・ポート（ＴＡＰ）を介してテストされるユニットに適用されるように構成された入力テスト・データを生成するステップと、テストされるユニットのスキャン・チェーンの入力テスト・ベクトルを構成するために入力テスト・データをリオーダリングする形で入力テスト・データをバッファリングするステップと、入力テスト・ベクトルに関してベクトル変換を適用するステップとを含む方法を実行させる命令を格納する。
【０００８】
一実施形態では、方法は、テストされるユニットの複数のセグメントに関連する複数のテスト動作を受け取るステップと、テスト動作から、テスト・アクセス・ポート（ＴＡＰ）を介してテストされるユニットに適用されるように構成された入力テスト・データを生成するステップと、テストされるユニットのスキャン・チェーンの入力テスト・ベクトルを構成するために入力テスト・データをリオーダリングする形で入力テスト・データをバッファリングするステップと、入力テスト・ベクトルに関してベクトル変換を適用するステップとを含む。
【０００９】
本明細書で提示される教示は、添付図面に関連して以下の詳細な説明を検討することによって容易に理解することができる。
【図面の簡単な説明】
【００１０】
【図１】テスティング・システムおよびテストされるシステムを含むシステム・テスティング環境を示す高水準ブロック図である。
【図２】テストされるシステム用のテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態を示す高水準ブロック図である。
【図３】テストされるシステム用のテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態を示す高水準ブロック図である。
【図４Ａ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態用の命令コーディングの詳細を示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図４Ｂ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態用の命令コーディングの詳細を示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図４Ｃ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態用の命令コーディングの詳細を示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図４Ｄ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態用の命令コーディングの詳細を示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図４Ｅ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態用の命令コーディングの詳細を示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図５Ａ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態の例示的なＴＩＳＡアーキテクチャを示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図５Ｂ】ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態の例示的なＴＩＳＡアーキテクチャを示す、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態を示す図である。
【図６】対話テスティング能力をサポートするＴＩＳＡベースのテスティング環境の実施形態を示す図である。
【図７】図６のＴＩＳＡベースのテスティング環境の例示的実装形態を示す図である。
【図８】図５Ａのテストされるシステムのトランスミッタ−レシーバ・チャネルの最適化を実行する例示的なプログラム・アーキテクチャを示す図である。
【図９】テスト命令セット・アーキテクチャ（Test Instruction Set Architecture、ＴＩＳＡ）フローを形成するためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法の一実施形態を示す図である。
【図１０】テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す図である。
【図１１Ａ】テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す図である。
【図１１Ｂ】テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す図である。
【図１２】ＴＩＳＡプロセッサ・アーキテクチャの例示的実施形態を示す図である。
【図１３】システム・テスティング能力を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す図である。
【図１４】テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す図である。
【図１５】テスト付属プロセッサ（test adjunct processor）アーキテクチャの例示的実施形態を示す図である。
【図１６】ＴＩＳＡプロセッサによって使用され得る例示的なレジスタ・セットを示す図である。
【図１７】テストされるシステムの例示的スキャン・チェーンの例示的分解を示す、テストされるシステムを示す高水準ブロック図である。
【図１８】スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用する、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態を示す高水準ブロック図である。
【図１９】テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す図である。
【図２０】例示的なスキャン・チェーン合成物のための例示的なＴＩＳＡセグメント連結を示す図である。
【図２１】図１９のテストされるシステムに関する例示的なスキャン・チェーン合成物および関連する回路モデルを示す図である。
【図２２】クリティカル・セクションの概念を使用するアクセス要求の位置ベースのスケジューリングを実行するプロセスの一実施形態を示す図である。
【図２３】テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す図である。
【図２４】スキャン・チェーン合成物が動的セグメントを含む場合の、例示的なスキャン・チェーン合成物および関連する回路モデルを示す図である。
【図２５】テストされるシステムをテストするための位置ベースのスケジューリングをサポートする方法の一実施形態を示す図である。
【図２６】テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す図である。
【図２７】テストされるシステムをテストするための位置ベースのスケジューリングをサポートする方法の一実施形態を示す図である。
【図２８】テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成された遅延スケジューラ実行アーキテクチャの一実施形態を示す図である。
【図２９】テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す図である。
【図３０】本明細書で説明される機能を実行する際の使用に適するコンピュータを示す高水準ブロック図である。
【発明を実施するための形態】
【００１１】
理解を容易にするために、可能な場合には、同一の符号が、複数の図面に共通する同一の要素を指定するのに使用されている。
【００１２】
さまざまなテスティング能力が、テストされるシステム（ＳＵＴ）のテスティングを実行する際の使用のために提供される。
【００１３】
一実施形態では、テスト命令セット・アーキテクチャ（ＴＩＳＡ）が提供される。ＴＩＳＡは、システム・テスティングを実行する際に使用するために提供される。ＴＩＳＡは、対話テスティング能力、リモート・テスティング能力、および本明細書で説明するさまざまな他の能力を含む改善されたシステム・テスティング能力を提供するために、コンピュータ・サイエンス能力をシステム・テスティング能力と組み合わせる。ＴＩＳＡは、システム・テスティング能力を使用してソフトウェアベースの命令セット・アーキテクチャ（ＩＳＡ）を適合させることによって形成される。ソフトウェアベースのＩＳＡは、任意の適切なソフトウェア・プログラミング言語（たとえば、Ｃ＋＋、およびＪａｖａなど、ならびにそのさまざまな組合せ）を利用することができ、任意の適切なプロセッサを使用して実施され得る。システム・テスティング能力は、ＩＥＥＥ１１４９．１（ＪＴＡＧとしても知られる）ＴＡＰまたは任意の他の適切なＴＡＰなどの任意の適切なＴＡＰを利用することができる。概して、ＴＩＳＡは、ソフトウェア・プロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成される。ＴＩＳＡでは、テスト手順のアルゴリズム部分が、ソフトウェア・フローによって処理され、テスト手順のアルゴリズム部分が原子的テスティング動作に変換されるようになっている。ＴＩＳＡは、ソフトウェア・プロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成され、原始的テスティング動作が、テスト手順のアルゴリズム部分を処理しているソフトウェア・プロセスの原子的動作と同一の形で扱われるようになっている。これは、組込みテスト実行、リモート・テスト実行、および図示され本明細書で説明されるさまざまな他の改善されたシステム・テスティング能力のより細かい粒度の制御を可能にする。
【００１４】
図１に、テスティング・システムとテストされるシステムとを含むシステム・テスティング環境の高水準ブロック図を示す。
【００１５】
図１に示されているように、システム・テスティング環境１００は、テスティング・システム（ＴＳ）１１０およびテストされるシステム（ＳＵＴ）１２０を含む。
【００１６】
ＴＳ１１０は、ＳＵＴ１２０をテストするのに適する任意のシステムとすることができる。ＴＳ１１０は、ＳＵＴ１２０をテストするために構成される。ＴＳ１１０は、ＳＵＴ１２０の任意のテスティング、たとえば、ＳＵＴ１２０の１つまたは複数の個々のコンポーネント、ＳＵＴ１２０のコンポーネントの１つまたは複数の組合せ、ＳＵＴ１２０のコンポーネントの間の１つまたは複数の相互接続、およびＳＵＴ１２０の１つまたは複数のシステム・レベル機能など、ならびにそのさまざまな組合せのテスティングを実行することができる。ＴＳ１１０は、テスト手順の実行、テストされるシステムへの入力データの供給、テストされるシステムからの出力データの受取、システム・テスティング結果を決定するためのテストされるシステムから受け取られた出力データの処理、および同様の機能、ならびにそのさまざまな組合せなど、通常はテストされるシステムのテスティングに関連する機能のいずれをも実行することができる。テストされるシステムをテストするためのＴＳ１１０の設計および使用を、下でさらに詳細に説明する。
【００１７】
ＳＵＴ１２０は、ＴＳ１１０を使用してテストすることのできる任意のシステムとすることができる。ＳＵＴ１２０は、その少なくとも一部をＴＳ１１０によって個別におよび／または組み合わせてテストできる任意のコンポーネント（１つまたは複数）を含むことができる。ＴＳ１１０は、ＳＵＴ１２０によってテストされるコンポーネント（１つまたは複数）へのアクセスを提供する関連する入力アクセス・ピンおよび出力アクセス・ピンの１つまたは複数のセットを有する１つまたは複数のスキャン・チェーンを含むことができる。ＳＵＴ１２０をテストするためにＳＵＴ１２０内でスキャン・チェーン（１つまたは複数）を利用できる形は、当業者によって了解されるであろう。たとえば、ＳＵＴ１２０は、１つまたは複数の基板を含むことができ、この基板のテスティングは、ＳＵＴ１２０に入力テスティング信号を適用し、ＳＵＴ１２０から出力テスティング信号を収集するために使用できる関連する入力アクセス・ピンおよび出力アクセス・ピンを有する１つまたは複数のスキャン・チェーンを使用して実行することができる。
【００１８】
図１に示されているように、ＴＳ１１０は、テスト・アクセス・インターフェース（ＴＡＩ）１１５を介してＳＵＴ１２０にアクセスする。テスト・アクセス・インターフェースを、任意の適切なテスト・アクセス・インターフェースを使用して実施することができ、このテスト・アクセス・インターフェースは、ＴＳ１１０、ＳＵＴ１２０、および実行されるテスティングのタイプなど、ならびにそのさまざまな組合せのうちの１つまたは複数に依存する可能性がある。
【００１９】
たとえば、ＴＡＩ１１５は、参照によってその全体が本明細書に組み込まれているＩＥＥＥ１１４９．１標準規格で標準化されているＪｏｉｎｔ  Ｔｅｓｔ  Ａｃｔｉｏｎ  Ｇｒｏｕｐ（ＪＴＡＧ）テスト・アクセス・ポート（ＴＡＰ）を含むことができる。ＩＥＥＥ１１４９．１標準規格は、Ｔｅｓｔ  Ｄａｔａ  Ｉｎ（ＴＤＩ）、Ｔｅｓｔ  Ｄａｔａ  Ｏｕｔ（ＴＤＯ）、Ｔｅｓｔ  Ｍｏｄｅ  Ｓｅｌｅｃｔ（ＴＭＳ）、Ｔｅｓｔ  Ｃｌｏｃｋ（ＴＣＫ）、および、オプションでＴｅｓｔ  Ｒｅｓｅｔ  Ｓｉｇｎａｌ（ＴＲＳＴ）という信号のセットをサポートするＴＡＰを定義する。ＳＵＴ１２０のＴＤＩピンおよびＴＤＯピンは、ＴＳ１１０がＳＵＴ１２０の少なくとも一部をテストするためにＳＵＴ１２０にそれによってアクセスできるバウンダリ・スキャン・チェーン内で相互接続される。
【００２０】
ＴＡＩ１１５は、任意の他の適切なテスト・アクセス・インターフェースを含むことができる。
【００２１】
当業者は、ＴＳ１１０、ＴＡＩ１１５、およびＳＵＴ１２０を、本明細書に含まれる実施形態の特徴を提供するのに適する任意の形で実施できることを了解するであろう。
【００２２】
本明細書で説明するように、ＴＩＳＡは、システム・テスティングにおける大きい改善を提供するためにシステム・テスティング能力と組み合わせてコンピュータ・サイエンス能力を活用することができる。システム・テスティング能力およびコンピュータ・サイエンス能力の全般的な説明がこれに続き、コンピュータ・サイエンス能力およびシステム・テスティング能力を一緒に利用してＴＩＳＡを提供する形の説明がそれに続く。
【００２３】
ＴＩＳＡは、コンピュータ・サイエンス能力を活用することによってシステム・テスティング能力を改善する。システム・テスティング能力は、「自動化テスト」フロー（概して、テスト・アルゴリズム（１つまたは複数）の定義から実際のテスティング動作に達するのに必要である可能性があるステップおよびリソースのすべてを含む）のすべてのステージで概してサポートされる能力を含むことができる。
【００２４】
テスト自動化を助けるために、テスト・リソースは、しばしば、基板およびデバイスの内部に組み込まれ、通常はテスト・アクセス・ポート（ＴＡＰ）と呼ばれる標準化されたインターフェースを使用してアクセスされ得る。これは、ピン・カウントを制限し、リソース・アクセスおよび管理を合理化するという効果を有する。複数の言語が、テストされるシステムの内部のリソースを記述するのに使用可能であり、したがって、これをテスト生成ツール（ＴＧＴ）への入力として使用することができる。ＴＧＴは、ＴＡＰに指令し、関連するテスティング動作を実行するのにテスト制御ユニット（ＴＣＵ）によって使用され得るテスティング・シーケンスを生成するためにアルゴリズムを適用することができる。テスティング動作の特徴および性能は、３つの要素すなわち、アクセス標準規格、データ・フォーマット、およびＴＣＵ実装形態に依存する。
【００２５】
ＴＩＳＡは、改善されたシステム・テスティング能力を提供するためにコンピュータ・サイエンス能力を活用することができる。これは、「ソフトウェア開発フロー」（概して、コンパイル、命令セット・アーキテクチャ（ＩＳＡ）、および対話デバッギングなど、ならびにそのさまざまな組合せなど、選ばれたソフトウェア言語（１つまたは複数）でコーディングされたソフトウェア・アルゴリズムからターゲット・プロセッサ上での最終的なデバッギングおよび実行に達するのに必要である可能性があるステップおよびリソースのいずれかまたはすべてを含む）のすべてのステージで使用可能なコンピュータ・サイエンス能力の使用を含むことができる。
【００２６】
コンピュータ・サイエンスにおいてコンパイルを使用すると、プログラマフレンドリな高水準抽象化で定義されたアルゴリズムが一連の機械実行可能命令にまとめられる。このプロセスは、入力プログラミング言語およびプロジェクトの複雑さに応じて大幅に変化する可能性があるが、手法のすべてではないにせよほとんどが、すべてのアルゴリズムをその複雑さに関わりなく基本的な命令に分解できるという同一の基本的な仮定を共有する。これは、古典的な言語ならびにたとえばＣ＋＋、Ｊａｖａ、およびＰｙｔｈｏｎなどのより近代的な高水準言語およびオブジェクト指向言語にあてはまる。
【００２７】
命令セット・アーキテクチャ（ＩＳＡ）は、すべてのプロセッサの核であり、その理由は、コンパイルが非常に有効であることである。概して、各プロセッサは、そのプロセッサを操作できる形を定義する命令のセットを提供する。これらの命令は、そのプロセッサのＩＳＡの少なくとも一部を形成する。ＩＳＡを、レジスタ、アドレッシング・モード、オペコード、およびメモリ構造など、ならびにそのさまざまな組合せなど、命令に関連するさまざまな構造を含むと考えることができることを了解されたい。ＩＳＡは、プロセッサが、メモリから／への値の読取り／書込みなどの単純な命令を実行し、レジスタに対する論理演算または算術演算を実行し、割込みを処理することなどを可能にする。この基本的な挙動は、経時的に本質的に変更されないままであり、現代のプロセッサは、非常に多くのリソースを効率的に活用できるので例外的な性能を達成し、したがって、ほぼ同一の時間ではるかに多数のそのような基本的な命令を完了することができる。さらに、コプロセッサ（たとえば、浮動小数点コプロセッサ、およびグラフィカル・コプロセッサなど）の使用から、さらにより高い性能に達することができ、このコプロセッサは、複雑な動作をハード・コーディングすることによってメイン・プロセッサを助けることができる。
【００２８】
コンピュータ・サイエンスにおいてデバッギングを使用すると、ソフトウェア開発および実行プロセスの監視および検証が可能になる。概して、ソフトウェア開発は、長く難しいプロセスであり、このプロセスは、最終製品が誤りまたは通常呼ばれるように「バグ」がないことを保証するために厳格に監視され、検証される。ソフトウェア・プログラムをテストするのを助けるために、ソフトウェア開発フローは、多数の強力なデバッグ機能を提供する。たとえば、一般的なソフトウェア開発フロー・デバッグ機能は、ステップバイステップ実行、すべてのレジスタおよびメモリ位置の観察可能性／制御可能性、ブレークポイントおよびウォッチポイントの使用などを含む。これらのデバッグ機能ならびにさまざまな他のデバッグ機能は、よりしばしば、ソフトウェア・コンパイラによって最終コードに埋め込まれるアルゴリズムおよび構造によって使用可能にされるが、プロセッサの内部で使用可能なハードウェア・リソースによって支援することもできる。この情報から、デバッガは、オリジナル・コードを再構成し、すべてのＩＳＡレベル動作をプログラミング抽象化レイヤに相関させることができる。
【００２９】
改善されたシステム・テスティング能力を使用可能にするために自動化テスト実行能力およびコンピュータ・サイエンス・ソフトウェア能力を一緒に使用することは、図２および図３を参照することによってよりよく理解することができる。
【００３０】
図２に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態の高水準ブロック図を示す。
【００３１】
図２に示されているように、ＴＳ１１０は、テスト生成ツール（ＴＧＴ）２１０およびソフトウェア・コンパイラ（ＳＣ）２２０を含む。
【００３２】
ＴＧＴ２１０は、ＴＧＴコンポーザ２１２およびＴＧＴアルゴリズム２１４を含む。
【００３３】
ＴＧＴコンポーザ２１２は、入力としてシステム記述ファイル２１１を受け入れる。システム記述ファイル２１１は、テストされるシステムをテストするためのテスティング命令／ベクトルを作るのにＴＧＴによって使用され得る任意の適切な記述ファイルを含むことができる。たとえば、システム記述ファイル２１１は、回路記述ファイル、基板／治具ネットリスト・ファイル、および他の記述ファイルなど、ならびにそのさまざまな組合せを含むことができる。システム記述ファイル２１１を、ＴＧＴ２１０上で使用可能とすることができ、かつ／または１つもしくは複数のリモート・コンポーネントおよび／もしくはシステムから入手することができる。
【００３４】
システム記述ファイル２１１は、１つまたは複数の回路記述ファイルを含むことができる。回路記述ファイルは、Boundary Scan Description Language（ＢＳＤＬ、基板レベルＪＴＡＧに関するＩＥＥＥ１１４９．１標準規格の一部として開発された）、Hierarchical Scan Description Language（ＨＳＤＬ、ＢＳＤＬの拡張として開発された）、およびNew Scan Description Language（ＮＳＤＬ）など、ならびにそのさまざまな組合せなど、任意の適切な記述言語（１つまたは複数）を使用して指定することができる。
【００３５】
システム記述ファイル２１１は、１つまたは複数の基板／治具ネットリスト・ファイルを含むことができる。基板／治具ネットリスト・ファイルは、ネットリスト、接続、および類似する情報を記述する、デバイス（１つまたは複数）の物理記述に関係するファイルを含むことができる。基板／治具ネットリスト・ファイルは、ＰＣＢ、Ｇｅｒｂｅｒ、および／または基板／治具ネットリスト・ファイルに適する任意の他のフォーマットなど、任意の適切なフォーマットで指定することができる。
【００３６】
システム記述ファイル２１１は、１つまたは複数の他の記述ファイルを含むことができる。他の記述ファイルは、回路モデルを作るための入力として使用できる任意の他の適切な記述ファイルを含むことができる。たとえば、他の記述ファイルは、Ａｓｓｅｔ社のＭａｃｒｏ  Ｌａｎｇｕａｇｅ、Ｇｏｅｐｅｌ社のＣＡＳＬＡＮ言語、および／または任意の他の適切な記述言語ファイルなど、任意の適切なアプリケーション固有および／またはツール固有の記述言語ファイルを含むことができる。
【００３７】
ＴＧＴコンポーザ２１２は、システム記述ファイル２１１を処理して回路モデル２１３を作る。回路モデル２１３を作るためのＴＧＴコンポーザ２１２によるシステム記述ファイル２１１の処理は、任意の適切な形で実行することができる。回路モデル２１３は、テストされるシステムまたはテストされるシステムのうちでＴＧＴ２１０がそれのために実行されつつある部分のモデルを指定する。ＴＧＴコンポーザ２１２は、回路モデル２１３をＴＧＴアルゴリズム２１４に供給する。
【００３８】
ＴＧＴアルゴリズム２１４は、回路モデル２１３を受け入れる。ＴＧＴアルゴリズム２１４は、回路モデル２１３を処理して、ＴＧＴ原子的テスト動作２１６を作る。ＴＧＴ原子的テスト動作２１６を作るためのＴＧＴアルゴリズム２１４による回路モデル２１３の処理は、任意の適切な形で実行することができる。
【００３９】
ＳＣ２２０は、ＳＣフロントエンド・アルゴリズム２２２およびＳＣバックエンド・アルゴリズム２２４を含む。
【００４０】
ＳＣフロントエンド・アルゴリズム２２２は、入力としてコンピュータ・サイエンス・ソース・ファイル２２１を受け入れる。コンピュータ・サイエンス・ソース・ファイル２２１は、コンパイラによってコンパイルできる任意の適切なコンピュータ・サイエンス・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル２２１は、Ｃ＋＋、Ｊａｖａ、およびＰｙｔｈｏｎなど、ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語（１つまたは複数）のコンピュータ・サイエンス・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル２２１は、１つもしくは複数のＣファイル、１つもしくは複数のＣ＋＋ファイル、および／または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの１つまたは複数を含むことができる。
【００４１】
ＳＣフロントエンド・アルゴリズム２２２は、コンピュータ・サイエンス・ソース・ファイル２２１を処理してプログラム・モデル２２３を作る。プログラム・モデル２２３は、コンピュータ・サイエンス・ソース・ファイル２２１の中間表現を指定する。ＳＣフロントエンド・アルゴリズム２２２は、プログラム・モデル２２３をＳＣバックエンド・アルゴリズム２２４に供給する。
【００４２】
ＳＣバックエンド・アルゴリズム２２４は、入力としてプログラム・モデル２２３を受け入れる。ＳＣバックエンド・アルゴリズム２２４は、プログラム・モデル２２３を処理して、ＩＳＡ原子的動作２２６を含む１つまたは複数のＩＳＡバイナリ・ファイル２２５を作る。ＩＳＡ原子的動作２２６を含むＩＳＡバイナリ・ファイル２２５を形成するためのＳＣバックエンド・アルゴリズム２２４によるプログラム・モデル２２３の処理は、任意の適切な形で実行することができる。ＩＳＡ原子的動作２２６は、ＴＩＳＡがそれのために実施されるプロセッサによってサポートされるアセンブリレベル命令である。
【００４３】
図２に示されているように、ＴＧＴ２１０およびＳＣ２２０のそれぞれの処理フローに加えて、ＴＧＴ２１０とＳＣ２２０との間の追加の相互作用を、ＴＩＳＡ原子的動作２４６の生成を制御するのに利用することができる。一実施形態では、ＳＣバックエンド・アルゴリズム２２４は、ＴＧＴアルゴリズム２１４への１つまたは複数のベクトル計算要求２３０を開始することができる。ＳＣバックエンド・アルゴリズム２２４は、ＳＣバックエンド・アルゴリズムがＴＡＰにアクセスすることを必要とする時に、ベクトル計算要求２３０を開始することができる。ＴＧＴアルゴリズム２１４は、ＳＣバックエンド・アルゴリズム２２４からベクトル計算要求２３０を受け取った時に、受け取られたベクトル計算要求２３０に基づいてＴＡＰに関する１つまたは複数のＴＧＴ原子的テスト動作２１６を生成する。ＴＧＴ原子的テスト動作２１６が、ＩＳＡ原子的動作２２６と組み合わされて、ＩＳＡ原子的動作２２６を使用するＴＧＴ原子的テスト動作２１６に対するアルゴリズム的制御を可能にするので、次に、１つまたは複数のＴＧＴ原子的テスト動作２１６をＳＣバックエンド・アルゴリズム２２４によって制御される形でＴＡＰに適用することができる。この形で、ＳＣ２２０は、ＴＡＰへのアクセスのアルゴリズム的制御を提供する。
【００４４】
図２に示されているように、ＴＧＴ２１０およびＳＣ２２０に加えて、ＴＳ１１０は、さらに、ＴＩＳＡコンポーザ２４０を含む。ＴＩＳＡコンポーザ２４０は、ＴＧＴ原子的テスト動作２１６およびＩＳＡ原子的動作２２６を受け入れる。ＴＩＳＡコンポーザ２４０は、ＴＧＴ原子的テスト動作２１６をＴＩＳＡ命令に変換し、それらのＴＩＳＡ命令をＩＳＡバイナリ・ファイル（１つまたは複数）２２５に挿入する（すなわち、ＴＩＳＡ命令をＩＳＡ原子的動作２２６と組み合わせて、これによって、ＴＩＳＡ原子的動作２４６を含むＴＩＳＡバイナリ・ファイル２４５を形成する）。ＴＩＳＡコンポーザ２４０は、ＴＧＴ２１０の一部とするか、ＳＣ２２０の一部とするか、ＴＧＴ２１０およびＳＣ２２０にまたがって分割されるか、ＴＧＴ２１０およびＳＣ２２０とは別々に実施されるものなどとすることができる。
【００４５】
図２に示し、これに関して説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ／または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
【００４６】
図３に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態の高水準ブロック図を示す。
【００４７】
図３に示されているように、図３のＴＳ１１０は、ＴＩＳＡ原子的動作を含むＴＩＳＡバイナリ・ファイルがテスト生成ツールとソフトウェア・コンパイラとの間の相互作用を使用して生成されるという点で、図２のＴＳ１１０に似た形で動作する。しかし、図３のＴＳ１１０でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用は、図２のＴＳ１１０でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用とは異なる。
【００４８】
図３に示されているように、ＴＳ１１０は、テスト生成ツール（ＴＧＴ）３１０およびソフトウェア・コンパイラ（ＳＣ）３２０を含む。
【００４９】
ＴＧＴ３１０は、ＴＧＴコンポーザ３１２およびＴＧＴアルゴリズム３１４を含む。
【００５０】
ＴＧＴコンポーザ３１２は、入力としてシステム記述ファイル３１１を受け入れる。システム記述ファイル３１１は、テストされるシステムをテストするためのテスティング命令／ベクトルを作るのにＴＧＴによって使用され得る任意の適切な記述ファイルを含む。たとえば、システム記述ファイル３１１は、回路記述ファイル、基板／治具ネットリスト・ファイル、および他の記述ファイルなど、ならびにそのさまざまな組合せを含むことができる。図３のシステム記述ファイル３１１は、図２に示し、これに関して説明したシステム記述ファイル２１１に似たシステム記述ファイル（たとえば、１つまたは複数の回路記述ファイル、１つまたは複数の基板／治具ネットリスト・ファイル、および１つまたは複数の他の記述ファイルなど、ならびにそのさまざまな組合せ）を含むことができる。システム記述ファイル３１１を、ＴＧＴ３１０上で使用可能とすることができ、かつ／あるいは１つまたは複数のリモート・コンポーネントおよび／もしくはシステムから入手することができる。
【００５１】
ＴＧＴコンポーザ３１２は、入力として１つまたは複数のテスト動作記述ファイル３３１１〜３３１Ｎ（集合的にテスト動作記述ファイル３３１）を受け入れる。テスト動作記述ファイル３３１は、ＳＣ３２０によって生成される。ＳＣ３２０によるテスト動作記述ファイル３３１の生成を、下で詳細に説明する。
【００５２】
ＴＧＴコンポーザ３１２は、システム記述ファイル３１１およびテスト動作記述ファイル３３１を処理して、回路モデル３１３を作る。回路モデル３１３を作るためのＴＧＴコンポーザ３１２によるシステム記述ファイル３１１の処理は、任意の適切な形で実行することができる。回路モデル３１３は、テストされるシステムまたはテストされるシステムのうちでＴＧＴ３１０がそれのために実行されつつある部分のモデルを指定する。テスト動作記述ファイル３３１に関連するシステム記述ファイル３１１の処理は、ＴＧＴ３１０が適切なＴＡＰ原子的動作を作ることを可能にする形で、ＴＧＴコンポーザ３１２が回路モデル３１３を作ることを可能にする。ＴＧＴコンポーザ３１２は、回路モデル３１３をＴＧＴアルゴリズム３１４に供給する。
【００５３】
ＴＧＴアルゴリズム３１４は、回路モデル３１３を受け入れる。ＴＧＴアルゴリズム３１４は、回路モデル３１３を処理して、ＴＧＴ原子的テスト動作３１６を作る。ＴＧＴ原子的テスト動作３１６を作るためのＴＧＴアルゴリズム３１４による回路モデル３１３の処理は、任意の適切な形で実行することができる。
【００５４】
図３に示されているように、ＴＧＴ３１０およびＳＣ３２０に加えて、ＴＳ１１０は、ＴＩＳＡトランスレータ３４０を含む。ＴＩＳＡトランスレータ３４０は、ＴＧＴ原子的テスト動作３１６を受け取る。ＴＩＳＡトランスレータ３４０は、ＴＧＴ原子的テスト動作３１６を変換して、ＴＩＳＡ原子的テスト動作３４６を形成する。ＴＩＳＡトランスレータ３４０は、ソフトウェア・コンパイル・プロセスに含めるために、ＴＩＳＡ原子的テスト動作３４６をＳＣ３２０に供給する。ＳＣ３２０によるＴＩＳＡ原子的テスト動作３４６の使用を、下で詳細に説明する。ＴＩＳＡトランスレータ３４０は、ＴＧＴ３１０の一部とするか、ＳＣ３２０の一部とするか、ＴＧＴ３１０およびＳＣ３２０にまたがって分割されるか、ＴＧＴ３１０およびＳＣ３２０とは別々に実施されるものなどとすることができる。
【００５５】
ＳＣ３２０は、ＳＣプリコンパイラ３３０、ＳＣフロントエンド・アルゴリズム３２２、およびＳＣバックエンド・アルゴリズム３２４を含む。
【００５６】
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を受け入れる。
【００５７】
コンピュータ・サイエンス・ソース・ファイル３２１は、コンパイラによってコンパイルできる任意の適切なコンピュータ・プログラミング・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル３２１は、Ｃ＋＋、Ｊａｖａ、およびＰｙｔｈｏｎなど、ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語（１つまたは複数）のコンピュータ・プログラミング・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル３２１は、１つもしくは複数のＣファイル、１つもしくは複数のＣ＋＋ファイル、および／または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの１つあるいは複数を含むことができる。
【００５８】
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を処理する。
【００５９】
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を処理し、そこから前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを作る。コンピュータ・サイエンス・ソース・ファイル３２１をＳＣプリコンパイラ３３０によって前処理して、任意の適切な形で前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを形成することができる。ＳＣプリコンパイラ３３０は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐをフロントエンド・アルゴリズム３２２に供給する。
【００６０】
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１の処理中にテスト動作を検出し、テスト動作記述ファイル３３１を生成する。テスト動作記述ファイル３３１は、任意の適切なテスト記述言語を使用して（たとえば、１つまたは複数の標準テスト記述言語を使用して、かつＴＧＴ３１０に固有のテスト記述言語を使用してなど、ならびにそのさまざまな組合せ）指定することができる。ＳＣプリコンパイラ３３０は、テスト動作記述ファイル３３１をＴＧＴ３１０に（実例として、回路モデル３１３を作るためにシステム記述ファイル３１１に関連してテスト動作記述ファイル３３１を処理する、ＴＧＴ３１０のＴＧＴコンポーザ３１２に）供給する。
【００６１】
ＳＣフロントエンド・アルゴリズム３２２は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを受け入れる。ＳＣフロントエンド・アルゴリズム３２２は、ＴＩＳＡ原子的テスト動作３４６をも受け入れ、このＴＩＳＡ原子的テスト動作３４６は、テスト動作記述ファイル３３１からＴＧＴ３１０によって作られたＴＧＴ原子的テスト動作３１６を使用してＴＩＳＡトランスレータ３４０によって作られる。ＳＣフロントエンド・アルゴリズム３２２は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１ＰおよびＴＩＳＡ原子的テスト動作３４６をコンパイルして、プログラム・モデル３２３を作る。プログラム・モデル３２３は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐの中間表現を指定し、この中間表現は、ＴＩＳＡ原子的動作を形成するためにＴＩＳＡ原子的テスト動作３４６をＩＳＡ原子的動作内に統合できるように、ＴＩＳＡ原子的テスト動作３４６を含む。ＳＣフロントエンド・アルゴリズム３２２は、プログラム・モデル３２３をＳＣバックエンド・アルゴリズム３２４に供給する。
【００６２】
ＳＣバックエンド・アルゴリズム３２４は、プログラム・モデル３２３を受け入れる。ＳＣバックエンド・アルゴリズム３２４は、プログラム・モデル３２３を処理して、ＴＩＳＡ原子的動作３５６を含む１つまたは複数のＴＩＳＡバイナリ・ファイル３５５を作る。ＴＩＳＡ原子的動作３５６を含むＴＩＳＡバイナリ・ファイル３５５を形成するためのＳＣバックエンド・アルゴリズム３２４によるプログラム・モデル３２３の処理は、任意の適切な形で実行することができる。
【００６３】
ＴＩＳＡ原子的動作３５６は、ＩＳＡ原子的動作（すなわち、ＴＩＳＡがそれのために実施されるプロセッサによってサポートされるアセンブリレベル命令）およびＴＩＳＡ原子的テスト動作３４６を含む。
【００６４】
ＴＩＳＡ原子的動作３５６は、ＴＧＴ原子的テスト動作３１６（すなわち、ＴＩＳＡ原子的テスト動作３４６の形の）に対するアルゴリズム的制御（ＩＳＡ原子的動作を使用する）を提供し、これによって、ＴＩＳＡ原子的動作３５６が適用されるテストされるシステムの改善されたシステム・テスティングを可能にする。したがって、ＴＧＴ原子的テスト動作３１６が、ＩＳＡ原子的動作を使用するＴＧＴ原子的テスト動作３１６に対するアルゴリズム的制御を可能にするために、ＩＳＡ原子的動作と組み合わされるので、ＴＧＴ原子的テスト動作３１６（すなわち、ＴＩＳＡ原子的テスト動作３４６の形の）をＳＣバックエンド・アルゴリズム３２４によって制御される形でＴＡＰに適用することができる。この形で、ＳＣ３２０は、ＴＡＰへのアクセスのアルゴリズム的制御を提供する。
【００６５】
図３に示し、これに関して説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ／または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
【００６６】
図２および図３に関して、主に特定の個数の入力ファイル、中間ファイル、モデル、および出力ファイルなどに関して図示し、説明したが、図２および図３の実施形態ならびに本明細書で提供されるさまざまな関連する教示を、任意の適切な個数の入力ファイル、中間ファイル、モデル、および出力ファイルなどを使用して実施できることを了解されたい。
【００６７】
図２および図３は、コンピュータ・サイエンス能力を活用してシステム・テスティング能力を改善する形を示す（たとえば、システム・テスティングの細粒度制御の提供、対話システム・テスティングの使用可能化、システム・テスティング中の対話デバッギングの使用可能化、および図示され本明細書で説明されるさまざまな他の利益の提供）。図２および図３のシステム・テスティング方式は、ＳＴＡＰＬなどの既存手法に対する改善を提供し、これらの既存手法では、目標は、ベクトル・フォーマットにプログラミング機能を追加することであり、したがって、デバッギング機能、リモート・アクセス機能、および対話性機能が、ゼロから追加される。対照的に、ＴＩＳＡは、システム・テスティング用のテスト・アクセスを制御するために、コンピュータ・プログラミングおよび組込みアプリケーションからの豊富な情報を活用する。
【００６８】
図２および３を参照して、ＴＩＳＡの能力および特徴が、その抽象化レベルによって定義される、すなわち、ＴＩＳＡ原子的動作の定義が微細であればあるほど、ＴＩＳＡがより良い性能を提供することを了解されたい。
【００６９】
ＴＩＳＡがＪＴＡＧアーキテクチャ内で実施される一実施形態では、３つの抽象化レベルを、スキャン動作のためにサポートすることができる。
【００７０】
第１の抽象化レベルは、ベクトル・レベルである。ベクトル・レベルは、３つの抽象化レベルのうちで最も粗い粒度であり、ここでは、原子的動作は、スキャン・ベクトルの入力および出力である。ベクトル・レベルは、シリアル・ベクトル形式（Serial Vector Format、ＳＶＦ）または任意の他の適切なベクトル・フォーマットなどのベクトル・フォーマットで最もよく表され、最高レベルの制御を与える。
【００７１】
第２の抽象化レベルは、ＴＡＰレベルである。ＴＡＰレベルでは、原子的動作は、ＴＡＰ状態機械に対する十分な制御を可能にするために機能強化される。これは、スキャン動作に対するより洗練された制御、非標準シーケンス（たとえば、たとえばアドレス指定可能なシャドウ・プロトコル（Addressable Shadow Protocol）または他の類似するプロトコルで要求されるシーケンスなど）のサポートを可能にする。
【００７２】
第３の抽象化レベルは、スキャン・セグメント・レベルである。スキャン・セグメント・レベルは、３つの抽象化レベルのうちで最も微細な粒度である。ベクトル・レベルおよびＴＡＰレベルの抽象化レベルは、原子的データ・フォーマットとしてスキャン・ベクトルを使用し、これは、スキャン・チェーン全体が用いられる伝統的な導通テストには十分であるが、スキャン・チェーンを構成する数十個または数百個の機器に対する細粒度制御の必要がある機器ベースのテスティング（instrument-based testing）には面倒である。スキャン・セグメント・レベルは、全体的なスキャン・パスの内部の「スキャン・セグメント」の定義を可能にし、このスキャン・セグメントは、別々に処理することができ、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。この手法は、使用可能な計算リソースが非常に限られている場合がある組込みアプリケーションで有利である。スキャン・セグメント・レベルの使用を、図示し、下でさらに詳細に説明する
【００７３】
図２および図３に示されているように、スキャン動作の抽象化レベルに関わりなく、ＴＧＴによって計算される、結果のＴＡＰ原子的動作（実例として、ＴＧＴ原子的テスト動作２１６およびＴＧＴ原子的テスト動作３１６）は、対応するＴＩＳＡ原子的テスト動作に変換され、バイナリ実行可能ファイルに（すなわち、ＳＣによって生成されたＩＳＡ原子的動作に）挿入される。
【００７４】
図２を参照すると、ＴＧＴ原子的テスト動作２１６およびＩＳＡ原子的動作２２６を処理して、ＴＩＳＡバイナリ実行可能ファイル（実例として、ＴＩＳＡバイナリ・ファイル２４５）内のＴＩＳＡ原子的動作２４６を形成することができる。ＴＩＳＡ原子的動作２４６は、ＴＩＳＡ原子的テスト動作およびＩＳＡ原子的動作を含む。
【００７５】
図３を参照すると、ＴＩＳＡ原子的テスト動作（ＴＧＴ３１０によって作られたＴＧＴ原子的テスト動作３１６からＴＩＳＡトランスレータ３４０によって生成される）を、ＳＣ３２０のＳＣフロントエンド３２４を変更することを全く必要とせずに、前コンパイル済みアセンブリ命令としてＳＣフロントエンド３２２に入力することができる。ほとんどすべてのプログラミング言語が、そのような動作を可能にすることを了解されたい。たとえば、Ｃでは、この動作が、「ａｓｍ」コマンドを使用して得られる。一実施形態では、ＳＣバックエンド・アルゴリズム３２４に対する些細な変更が必要になる場合がある（たとえば、ＴＩＳＡアセンブラ命令のバイナリ変換を処理するために）。そのようなプロセスの例を、図１１に示し、これに関して本明細書で説明する。
【００７６】
主にＪＴＡＧアーキテクチャでのＴＩＳＡ原子的動作の粒度のレベルに関して図示し、説明したが、当業者は、ＴＩＳＡ原子的動作の粒度の同一のレベルを他のアーキテクチャで利用でき、ＴＩＳＡ原子的動作の粒度の異なるレベルを、ＪＴＡＧアーキテクチャおよび／または他のアーキテクチャなど、ならびにそのさまざまな組合せで利用できることを了解するであろう。
【００７７】
上で説明したように、ＴＩＳＡを、任意の適切な命令セット・アーキテクチャ（ＩＳＡ）を使用して実施することができる。たとえば、ＴＩＳＡを、ＳＰＡＲＣ  Ｖ８  ＩＳＡ、およびＩＮＴＥＬ  ＩＳＡなどを使用して実施することができる。
【００７８】
ＴＩＳＡの実装形態を説明する際に明瞭にするために、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの例示的実装形態を、図４Ａ〜図４Ｅに示し、これらに関して本明細書で説明する。この例示的実装形態では、ＴＩＳＡは、ベクトル・レベルＴＩＳＡとして実施され、このベクトル・レベルＴＩＳＡは、ＳＶＦフォーマットを構成する命令の直接コーディングを可能にするが、上で説明したように、ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実施を、ＴＩＳＡがＴＡＰレベルＴＩＳＡまたはスキャン・セグメント・レベルＴＩＳＡとして実施される場合にも実行できることを了解されたい。
【００７９】
ＳＰＡＲＣ  Ｖ８  ＩＳＡは、オープンソース・ソフト・プロセッサ・ファミリＬｅｏｎ  ２およびＬｅｏｎ  ３など、多数の製品で実施されている。
【００８０】
「The SPARC Architecture Manual Version 8」、SPARC International,Inc刊、１９９２年（以下では「SPARC Architecture Manual」）の再検討によって、ＳＰＡＲＣ  Ｖ８  ＩＳＡによって活用されていない多数の符号語があることが明らかになる。これは、少なくともＡppendix Fの「opcodes and condition codes（オペコードおよび条件コード）」の再検討から明白である。
【００８１】
図４Ａに、ＳＰＡＲＣ  Ｖ８  ＩＳＡの未活用符号語を示す。図４Ａに示された未活用符号語は、ＴＩＳＡの「テスト」命令をコーディングするのに使用することができる。より具体的には、「ｏｐ」と「ｏｐ２」との両方に０がセットされている時に、その命令は、「The SPARC Architecture Manual Version 8」では未実装としてマークされ、その命令をＴＩＳＡに使用できるようになっている。
【００８２】
図４Ｂに、１３個のＳＶＦ命令のすべてを表すことができるコーディング・フォーマットを示す。図４Ｂに示されているように、ビット３０〜２５は、命令コーディング自体を含み、ビット２１〜１８は、ＴＡＰ状態が命令と共に使用される場合にそのＴＡＰ状態をコーディングするのに使用することができ、ビット１７〜１４は、必要な場合にオプション情報を指定するのに各命令によって使用することができる。
【００８３】
図４Ｃに、ＩＥＥＥ１１４９．１のＴＡＰについてのＴＡＰ状態の例示的ビット・コーディングを示す。ＴＡＰ状態のビット・コーディングは、ＩＥＥＥ１１４９．１のＴＡＰ状態名を識別する第１列、ＩＥＥＥ１１４９．１のＴＡＰ状態名に関連するＳＶＦのＴＡＰ状態名を識別する第２列、および図４Ｂのビット２１〜１８のビット・コーディングを識別する第３列を使用して表されている。ビット・コーディングを、さまざまな他の形でＴＡＰ状態に割り当てることができることを了解されたい。
【００８４】
ＳＶＦ命令は、複数のパラメータを可能にし、これらのパラメータは、最終的なコードの内部でコーディングされる必要がある。パラメータを表すために、また、命令およびデータを分離して保つという通常のアーキテクチャ的ベスト・プラクティスのために、レジスタベースのパラメータ渡しが、ベクトル・レベルＴＩＳＡのこの例示的実装形態のために定義される。したがって、ベクトル・レベルＴＩＳＡは、６つの専用３２ビット・レジスタすなわち、ＧＥＮＥＲＩＣ１、ＧＥＮＥＲＩＣ２、ＴＤＩ、ＴＤＯ、ＭＡＳＫ、およびＳＭＡＳＫを提示する。この６つの専用３２ビット・レジスタを、図４Ｄに示す。６つの専用３２ビット・レジスタの使用を、下で詳細に説明するが、一般的ルールとして、これらのレジスタは、パラメータを格納するか、パラメータが格納されるメモリ位置をポイントするかのいずれかに使用される。したがって、コンパイル時に、通常のＩＳＡ命令を使用して、ＴＩＳＡ命令が呼び出される前にこれらのレジスタにロードすることができる。より具体的には、ＴＩＳＡのこのＳＰＡＲＣ  Ｖ８  ＩＳＡ実装形態では、コプロセッサ・レジスタを、通常のロード／ストア命令のパラメータとして直接に使用することができる。
【００８５】
ＴＩＳＡのこのＳＰＡＲＣ  Ｖ８  ＩＳＡ実装形態で利用できるＳＶＦ命令は、ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ、ＦＲＥＱＵＥＮＣＹ、ＰＩＯ、ＰＩＯＭＡＰ、ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ、ＳＤＲ、ＳＩＲ、およびＲＵＮＴＥＳＴを含む。これらのＳＶＦ命令は、参照によってその全体が本明細書に組み込まれている、「Serial Vector Format Specification」、ASSET InterTech,Inc.、１９９７年（以下ではＳＶＦマニュアルと称する）を参照することによってよりよく理解することができる。ＴＩＳＡのこのＳＰＡＲＣ  Ｖ８  ＩＳＡ実装形態でのこれらのＳＶＦ命令の使用を、下でより詳細に説明する。
【００８６】
ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ
ＥＮＤＤＲ命令およびＥＮＤＩＲ命令は、ＴＡＰインターフェースがその動作を終了するＴＡＰ状態を示す。ＳＴＡＴＥ命令は、強制的にＴＡＰインターフェースを指定された状態にする。ＴＩＳＡのこの例示的実装形態では、ＥＮＤＤＲ命令、ＥＮＤＩＲ命令、およびＳＴＡＴＥ命令のＳＶＦコーディングは、図４Ｅに示されているようにそれぞれ「００００００」、「０００００１」、および「００００１０」である。これらのＳＶＦ命令のＳＶＦコーディングは、必要に応じて「ＴＡＰ状態」ファイル（すなわち、図４Ｃに示されたＴＡＰ状態の例示的ビット・コーディング）を使用して実行することができる。少なくともＳＶＦマニュアルの再検討から、ＳＴＡＴＥ命令がオプションでパラメータとして状態の明示的シーケンスをとることができることを了解されたい。ＴＩＳＡのこの例示的実装形態では、パラメータとして状態の明示的シーケンスをとることは、シーケンス内の状態ごとに１命令の、一連の命令によってコーディングされるはずである。
【００８７】
ＦＲＥＱＵＥＮＣＹ
ＦＲＥＱＵＥＮＣＹ命令は、ＴＡＰインターフェースの動作周波数を指定するのに使用される。ＦＲＥＱＵＥＮＣＹ命令は、Ｈｚサイクルの３２ビット整数として表される。ＴＩＳＡのこの例示的実装形態では、ＦＲＥＱＵＥＮＣＹ命令のＳＶＦコーディングは、図４Ｅに示されているように、「００００１１」である。ＦＲＥＱＵＥＮＣＹ命令の値は、ＧＥＮＥＲＩＣ１レジスタに格納される。
【００８８】
ＰＩＯ、ＰＩＯＭＡＰ
ＰＩＯ命令は、ＰＩＯＭＡＰへの呼出しによって以前にセットされたフォーマットの並列ベクトルを処理するのに使用することができる。ＴＩＳＡのこの例示的実装形態では、ＰＩＯＭＡＰは、ＴＡＰインターフェースをセット・アップするのに適切なコマンドを生成するプリプロセッサ・ディレクティブとみなされる。したがって、ＰＩＯ命令は、単に、並列ベクトルを表すことを必要とし、この並列ベクトルは、この並列ベクトルが格納されているアドレスを示す（ＧＥＮＥＲＩＣ１レジスタ内で）ことによって表すことができる。ベクトルを構成する語数「ｎ」は、この命令のビット１３〜０で指定され、したがって、ベクトルは、２１３＝８Ｋ語＝３２Ｋバイトのサイズ上限を有する。ベクトル・サイズが１語の正確な倍数ではない場合には、必要に応じてパディングおよび再アライメントをメモリ内で提供することができる。ＴＩＳＡのこの例示的実装形態では、ＰＩＯ命令のＳＶＦコーディングは、「０００１００」である。
【００８９】
ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ
ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令の役割は、異なる。ここでは、これらのＳＶＦ命令を一緒に検討するのは、（１）これらのＳＶＦ命令が、機能的に類似し（すなわち、これらのすべてが、異なる性質のものである場合であっても、シフト演算を指令する）、（２）これらのＳＶＦ命令が、次の同一のパラメータを受け入れるからである。
（１）ｌｅｎｇｔｈ：シフトすべきビット数を表す３２ビット数、
（２）ＴＤＩ（オプション）：入力シフト・ベクトル、
（３）ＴＤＯ（オプション）：期待される出力シフト・ベクトル、
（４）ＭＡＳＫ（オプション）：実際の値をＴＤＯと比較する時に使用すべきマスク（ただし、「１」は関係を示し、「０」は無関係を示す）、および
（５）ＳＭＡＳＫ（オプション）：実際の値をＴＤＩと比較する時に使用すべきマスク（ただし、「１」は関係を示し、「０」は無関係を示す）。
【００９０】
ＴＩＳＡのこの例示的実装形態では、ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令のＳＶＦコーディングは、図４Ｅに示されているように、それぞれ「０００１１０」、「０００１１１」、「００１０１０」、および「００１０１１」である。
【００９１】
ＴＩＳＡのこの例示的実装形態では、次の追加のコーディングを使用することができる。
（１）ｌｅｎｇｔｈは、ＧＥＮＥＲＩＣ１レジスタに格納される。
（２）Ｏ１は、ＴＤＩが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＴＤＩレジスタは、入力ベクトルが格納されているアドレスを含む。
（３）Ｏ２は、ＴＤＯが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＴＤＯレジスタは、期待される出力が格納されているアドレスを含む。
（４）Ｏ３は、ＭＡＳＫが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＭＡＳＫレジスタは、出力マスクが格納されているアドレスを含む。
（５）Ｏ４は、ＳＭＡＳＫが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＳＭＡＳＫレジスタは、出力マスクが格納されているアドレスを含む。
【００９２】
ＳＤＲ、ＳＩＲ
ＳＤＲ命令およびＳＩＲ命令は、ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令と同一の構文を有するが、機能的相違を有し、ＳＤＲおよびＳＩＲは、ＴＡＰに対する実際のスキャン動作をトリガする。対話テスティングでは、システムから読み取られた実際の出力ベクトルが、アルゴリズムの基礎であり、したがって、ＴＩＳＡは、実際の出力ベクトルをメモリ内に格納する可能性を提供する。「ＴＡＰ状態」フィールド（図４Ｂに示されたビット２１〜１８）が０とは異なる時には、ＧＥＮＥＲＩＣ２レジスタは、実際の出力ベクトルのストレージ位置を示す。したがって、ＳＤＲおよびＳＩＲは、最大７個のパラメータをサポートすることができる。ＴＤＯが指定され、実際の出力ベクトルが期待される出力ベクトルとは異なる場合には、ＳＰＡＲＣ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｍａｎｕａｌの項４．２に記載されているように、オーバーフロー・フラグがプロセッサ状態レジスタ（ＰＳＲ）内でセットされる。
【００９３】
ＲＵＮＴＥＳＴ
ＲＵＮＴＥＳＴ命令は、強制的にＴＡＰインターフェースに指定された長さの時間だけ指定された状態でテストを実行させ、主にＲＵＮＢＩＳＴ動作（たとえば、ＩＥＥＥ１１４９．１で定義されている）を制御するのに使用される。ＲＵＮＴＥＳＴ命令は、次のパラメータ（すべてがオプションである）のうちの１つまたは複数を受け入れる。
（１）ｒｕｎ＿ｓｔａｔｅ：インターフェースがテスト実行中に維持しなければならない状態、
（２）ｒｕｎ＿ｃｏｕｎｔ：テストが費やさなければならないクロック・サイクル数、
（３）ｒｕｎ＿ｃｌｋ：ｒｕｎ＿ｃｏｕｎｔがどのクロックを参照するのか（ＴＣＫ：ＴＡＰクロック、ＳＣＫ：システム・クロック）、
（４）ｍｉｎ＿ｔｉｍｅ：実数として表された、秒単位の最小動作時間、
（５）ｍａｘ＿ｔｉｍｅ：実数として表された、秒単位の最大動作時間、および
（６）ｅｎｄｓｔａｔｅ：インターフェースがコマンドの終りに達しなければならない状態。
【００９４】
ＴＩＳＡのこの例示的実装形態では、ＲＵＮＴＥＳＴ命令のＳＶＦコーディングを、「０００１０１」または「１００１０１」とすることができる。
【００９５】
ＴＩＳＡのこの例示的実装形態では、次の追加のコーディングを使用することができる。
（１）ＴＡＰ＿ＳＴＡＴＥ：それについて定義されたｒｕｎ＿ｓｔａｔｅを含む。
（２）Ｏ１：ＴＡＰ＿ＳＴＡＴＥが定義されている場合には「１」、そうでない場合には「０」。
（３）Ｏ２：ｍｉｎ＿ｃｏｕｎｔが指定されている場合には「１」、そうでない場合には「０」。セットされている場合には、ＧＥＮＥＲＩＣ１レジスタが、ｍｉｎ＿ｃｏｕｎｔの３２ビット符号なし表現を含む。
（４）Ｏ３：ｍａｘ＿ｔｉｍｅが指定されている場合には「１」、そうでない場合には「０」。セットされている場合には、ＧＥＮＥＲＩＣ２レジスタが、ｍａｘ＿ｃｏｕｎｔの３２ビット符号なし表現を含む。
（５）Ｏ４：ｅｎｄｓｔａｔｅがセットされている場合には「１」、そうでない場合には「０」。セットされている場合には、ビット１３〜１０が終了状態を含む。
（６）ビット９〜０：ｒｕｎ＿ｃｏｕｎｔが指定されている場合には、符号なし整数として表される（最大ｒｕｎ＿ｃｏｕｎｔ＝２１０＝１０２４）。このフィールドが「０」ではない場合には、ビット３０がｒｕｎ＿ｃｌｏｃｋを示す（「１」＝ＴＣＫ、「０」＝ＳＣＫ）。
【００９６】
主にＴＩＳＡのこのＳＰＡＲＣ  Ｖ８  ＩＳＡ実装形態での特定のＳＶＦ命令（すなわち、ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ、ＦＲＥＱＵＥＮＣＹ、ＰＩＯ、ＰＩＯＭＡＰ、ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ、ＳＤＲ、ＳＩＲ、およびＲＵＮＴＥＳＴ）の使用に関して図示し、本明細書で説明したが、より少数またはより多数のＳＶＦ命令を使用できることを了解されたい。
【００９７】
主にＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの実装形態に関して図示し、本明細書で説明したが、さまざまな他のＩＳＡを利用して、図示され本明細書で説明されるＴＩＳＡ教示によるＴＩＳＡを実施できることを了解されたい。
【００９８】
対話テスティング手法では、データ・ハンドオフ・ポイントが非常に重要である。上で説明したように、テスト・プログラムは、２つの主要部分すなわち、アルゴリズム部分（ソフトウェア・コンパイラによって表される）およびテスト・アクセス部分（テスト生成ツールによって表される）からなる。テスティング・プログラムを使用するテスト動作中には、テスト・プログラムがテストされるシステムにアクセスしている瞬間と、テスト・プログラムがテスト結果を検査し、必要な次のステップ（１つまたは複数）を判断している瞬間とがある。この２つの動作の間でのハンドオフは、効率的な対話テスティングを得るために重要である。
【００９９】
ＳＶＦおよびＳＴＡＰＬなどの既存のスクリプトベースの手法では、スクリプトが、ベクトル・レベルですべてのＴＡＰ動作の世話をする。このレベルでは、インターフェース（または「プレイヤ」）は、ＴＡＰプロトコルを用いて通信し、テストされるシステムへ／からベクトルを送る／受け取ることができる。さらに、ＳＴＡＰＬは、いくつかの基本的なフロー制御（ｉｆ−ｔｈｅｎ−ｅｌｓｅ）およびビット・ベクトルに対するアルゴリズム的操作をも可能にする。より洗練された処理（たとえば、受け取られたベクトルの内部のレジスタを識別する、または特定のデバイスにアクセスするためのベクトルを計算する）の必要がある場合には、プレイヤは、アルゴリズム部分に制御をハンド・オーバーする。ＳＴＡＰＬでは、これが「ｅｘｐｏｒｔ」コマンドを介して行われる。しかし、不利なことに、ＳＶＦおよびＳＴＡＰＬの両方が、これに関する標準化されたフォーマットを有しない（たとえば、ＳＴＡＰＬの場合に、ハンドオフ・プロセスは、通常は、所与のベンダにプロプライエタリである）。
【０１００】
Ericsson社のMaster Test Controller（ＭＴＣ）およびSystem BIST Processorなどの既存の組込み手法では、アルゴリズム部分とテスト・アクセス部分との間の同一の区分が使用される。そのような組込み手法では、アルゴリズム部分およびテスト・アクセス部分は、別々にプログラムされなければならない異なるプロセッサによって実行される。さらに、アルゴリズム部分およびテスト・アクセス部分のメモリ空間は、物理的に異なり、結果のハンドオフ機構が、ＳＴＡＰＬのハンドオフ機構に類似するようになっている。その結果は、テスト・アクセス部分用のコプロセッサが、アルゴリズム部分へのハンドオフの前に大量のスキャン部分を格納することを強制されることであり、これは、スキャン・チェーンの増加するサイズを考慮すると、大量のリソースを必要とする可能性がある。
【０１０１】
統合テスティングに対する既存手法（たとえば、ＳＶＦおよびＳＴＡＰＬなどのスクリプトベースの手法ならびにＭＴＣおよびSystem BIST Processorなどの組込み手法）とは対照的に、ＴＩＳＡは、テスト・アクセス部分（すなわち、テスト動作）をアルゴリズム部分（すなわち、古典的ＩＳＡ）の内部に統合し、テスト・アクセス部分およびアルゴリズム部分が同一の物理メモリ空間を共有するようにし、これによって、テスト・アクセス部分とアルゴリズム部分との間のハンドオフ（したがって、データ渡し）を自動的にする。ＴＩＳＡでは、テスト・アクセス部分とアルゴリズム部分との間のハンドオフは、命令レベルで行われ、プロセッサが、関連するスケジューリング戦略に従って必要に応じてスキャンおよびアルゴリズムを自由に混合（すなわち、テスト動作およびアルゴリズム動作を自由に混合）できるようになっている。
【０１０２】
ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡのこの例示的実装形態では、ベクトルを扱うすべての動作が、絶対アドレッシングを使用する（ＳＶＦ命令に関して上で説明したように）。その結果、テスティング・ベクトルを、ＩＳＡプログラムの内部の通常の変数のように使用することができ、これによって、テスト・アクセス部分とアルゴリズム部分との間のインターフェースが自動的にされる。例として、上で説明したＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの例示的実装形態に基づいて、次のステップは、原型的なテスティング・シーケンスを例示するものである。
（１）ＳＤＲ命令が、テストされるシステムからテスティング出力データを入手するのに使用される。結果の出力データは、特定のメモリ位置に配置される（たとえば、ＧＥＮＥＲＩＣ２レジスタ内の「ａｃｔｕａｌ」パラメータ）。
（２）古典的なＬＯＡＤ命令が、ロードされるべきこの出力データをレジスタに転送することができる。
（３）出力データがレジスタにロードされた後に、算術演算および／または論理演算を使用して、出力データを処理することができる（ＳＰＡＲＣ  Ｖ８  ＩＳＡはロード／ストア・アーキテクチャなので、すべてのデータが、処理される前にレジスタにロードされなければならないことに留意されたい）。
（４）古典的なＳＴＯＲＥ命令が、アルゴリズムの結果をメモリに転送するのに使用される。および
（５）ＳＤＲ命令が、新しいテスティング入力データをＴＡＰに送ることができる（たとえば、ＴＤＩレジスタ内の「ＴＤＩ」パラメータを使用して）。
【０１０３】
古典的なアルゴリズム動作（２）から（４）が、すべてのＩＳＡアルゴリズム実装形態について標準的であり、いかなる形でもＴＩＳＡによって変更されないことに留意されたい。
【０１０４】
したがって、この単純な例から、ＴＩＳＡを、アルゴリズム部分とテスト・アクセス部分との間の自然で効率的なハンドオフと共に、任意の所与のアルゴリズムまたはコンピュータ・プログラムを使用してサポートできることは、明白である。
【０１０５】
ＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡのこの例示的実装形態では、絶対アドレッシングが使用される（ＴＩＳＡを説明する際に明瞭にするために）が、本明細書の教示によって情報を与えられた当業者は、SPARC Architecture Manualに記載されたすべての正当なＳＰＡＲＣ  Ｖ８アドレッシング・モードをサポートするためにＴＩＳＡのこの例示的実装形態を修正できるはずである。
【０１０６】
本明細書で主にＳＶＦが使用されるＴＩＳＡの例示的実装形態に関して図示し、説明したが、ＳＶＦは、１１４９．１のＴＡＰの、基本的であるとしても完全な処理を提供することがわかっている周知のフォーマットなので、この例示的実施形態で使用された。本明細書の教示によって情報を与えられた当業者は、ＴＩＳＡを任意の他の適切な制御フォーマットを使用して実施でき、それらの制御フォーマットの多くが、ＴＡＰ状態機械のより細粒度の制御を可能にし、より洗練されたテスティング動作をサポートすることができることを了解するであろう。
【０１０７】
本明細書で主に抽象化レベルがベクトル・レベルであるＴＩＳＡの例示的実装形態に関して図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、図示され本明細書で説明される例示的ＴＩＳＡ実装形態を、ＴＩＳＡの抽象化レベルがＴＡＰレベルまたはスキャン・セグメント・レベルになるように変更できることを了解するであろう。
【０１０８】
ＴＩＳＡを説明する際に明瞭にするために、例示的なテストされるシステムに対してテスティングを実行するためのＴＩＳＡの例示的使用を、図５および６に示し、これらに関して本明細書で説明する。ＴＩＳＡのこの例示的使用では、ＴＩＳＡは、ＳＰＡＲＣ  Ｖ８  ＩＳＡおよびＳＶＦを使用するベクトル・レベルＴＩＳＡとして（すなわち、図４Ａ〜図４Ｅに示され、これらに関して説明された例示的実装形態の継続で）実施される。
【０１０９】
図５Ａおよび図５Ｂに、テストされるシステムに対してテスティングを実行するためのＴＩＳＡの例示的使用を示す。
【０１１０】
図５Ａに、ＪＴＡＧのＴＡＰ５１０およびテストされるシステム５２０を含むシステム・テスト環境５００を示す。
【０１１１】
ＪＴＡＧのＴＡＰ５１０は、テストされるシステム５２０へのテスト・アクセスを提供する。ＪＴＡＧのＴＡＰ５１０は、テストされるシステム５２０に入力データを送り、テストされるシステム５２０から出力データを受け取るために、テストされるシステム５２０へのテスト・アクセスを提供する。ＪＴＡＧのＴＡＰ５１０は、命令レジスタ（ＩＲ）５１２を含み、ＩＲ  ５１２は、８ビット命令レジスタである。
【０１１２】
ＪＴＡＧのＴＡＰ５１０は、テスティング・システム（たとえば、明瞭にするために省略されている、図３に示し、これに関して説明したテスティング・システム１１０など）によって制御される。
【０１１３】
テストされるシステム５２０は、第１基板５２１（Ｂ１と表される）および第２基板５２５（Ｂ２と表される）を含む。第１基板５２１は、トランスミッタ５２２（Ｔと表される）を含む。第２基板５２５は、レシーバ５２６（Ｒと表される）を含む。トランスミッタ５２２は、接続５２９上でデータをレシーバ５２６に送る。この例では、接続５２９は、８ビット接続である。
【０１１４】
図５Ａに示されているように、各基板は、それ自体のスキャン・チェーンを介してＪＴＡＧのＴＡＰ５１０からアクセス可能である。すなわち、第１基板５２１は、第１スキャン・チェーン５２３を介してアクセス可能であり、第２基板５２５は、第２スキャン・チェーン５２７を介してアクセス可能である。第１スキャン・チェーン５２３および第２スキャン・チェーン５２７は、ＪＴＡＧのＴＡＰ５１０のＩＲ  ５１２によって選択可能である（たとえば、ＩＲ＝０は第１基板Ｂ１を選択し、ＩＲ＝１は第２基板Ｂ２を選択する）。トランスミッタ５２２およびレシーバ５２６は、その基板上で単独であるのではなく、より広いスキャン・チェーン（たとえば、この例において、それぞれ２４ビットおよび１６ビット）の一部である。
【０１１５】
テスト・プログラムでは、入力データが、第１スキャン・チェーン５２３を介してトランスミッタ５２２に送られ、結果の出力データが、第２スキャン・チェーン５２７を活用することによってレシーバ５２６から収集される。網羅的テストを実行するために、すべての可能な値が接続５２９を介して送られ、２８＝２５６個のベクトルが接続５２９を介して送られるようになっている。Ｃを使用すると、例示的プログラムを、次とすることができる。
１  ｉｎｃｌｕｄｅ  ＜ｓｔｄｉｏ．ｈ＞
２  ｉｎｃｌｕｄｅ  ＜ｊｔａｇ．ｈ＞
３
４  ｃｈａｒ  ｓｅｎｔ＿ｖａｌｕｅ，  ｒｅｃｅｉｖｅｄ  ｖａｌｕｅ；
５
６  ｄｅｆｉｎｅ  ＭＡＸ＿ＣＯＵＮＴ  ２５６；
７
８  ｖｏｉｄ  ｍａｉｎ（ｖｏｉｄ）
９  ｛
１０    ｆｏｒ  （ｓｅｎｔ＿ｖａｌｕｅ＝０；ｓｅｎｔ＿ｖａｌｕｅ＜ＭＡＸ＿ＣＯＵＮＴ；ｓｅｎｔ＿ｖａｌｕｅ＋＋）
１１    ｛
１２      ａｐｐｌｙ＿ＪＴＡＧ（ｓｅｎｔ＿ｖａｌｕｅ，Ｂ１．Ｔ）；
１３      ｒｅａｄ＿ＪＴＡＧ（ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ，Ｂ２．Ｒ）；
１４      ｉｆ  （ｓｅｎｔ＿ｖａｌｕｅ  ！＝  ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ）  ｅｘｉｔ  （０）；
１５    ｝
１６    ｅｘｉｔ（１）；
１７  ｝
【０１１６】
このプログラムでは、行２は、ＪＴＡＧ動作を処理しているＣモジュールを含み、このＣモジュールでは、それぞれ行１２および１３で使用される関数「ａｐｐｌｙ＿ＪＴＡＧ」および「Ｒｅａｄ＿ＪＴＡＧ」が定義される。ＳＣ３２０のプリコンパイラ３３０は、これらの関数を認識し、ＴＧＴ３１０用のテスト動作記述ファイル３３１を生成する。テスト動作記述ファイル３３１のフォーマットは、第１基板５２１および第２基板５２５の実際の実装形態に応じて変化する可能性がある。たとえば、第１基板５２１と第２基板５２５との両方がＩＪＴＡＧ準拠である場合には、テスト動作記述ファイル３３１を、たとえばNew Scan Description Language（ＮＳＤＬ）コードを使用して指定することができる。ＴＧＴ３１０は、テスト動作記述ファイル３３１を使用して、ＴＧＴ原子的テスト動作３１６を生成し、このＴＧＴ原子的テスト動作３１６は、ＴＩＳＡトランスレータ３４０によってＴＩＳＡ原子的テスト動作３４６に変換される。ＴＩＳＡ原子的テスト動作３４６は、ＳＣ３２０のフロントエンドアルゴリズム３２２に供給される。ＴＧＴ原子的テスト動作３１６、関連するＴＩＳＡ原子的テスト動作３４６、および結果のＴＩＳＡバイナリ・コードが、図５Ｂに示されている。
【０１１７】
図５Ｂに、図５Ａのシステム・テスト環境５００のテスティングを実行するテスティング・システムによる使用のためのＣコマンドからＴＩＳＡコーディングへのマッピングを示す。
【０１１８】
図５Ｂに示されているように、ＣコマンドからＴＩＳＡコーディングへのマッピングは、４つの列すなわち「Ｃコマンド」列５４１、「ＳＶＦ命令」列５４２、「ＴＩＳＡアセンブラ」列５４３、および「ＴＩＳＡコーディング」列５４４を有するテーブル５４０を使用して表される。テーブル５４０は、左から右へ、ＣコマンドをＳＶＦ命令に変換できる形を示し、このＳＶＦ命令をＴＩＳＡアセンブラに変換することができ、このＴＩＳＡアセンブラをＴＩＳＡバイナリ・コーディングにコーディングすることができる。
【０１１９】
Ａｐｐｌｙ＿ＪＴＡＧ（ｖａｌｕｅ，Ｂ１．Ｔ）コマンドは、２つのＳＶＦ命令すなわちＳＩＲ  ８  ＴＤＩ（００）およびＳＤＲ  ２４  ＴＤＩ（ｖａｌｕｅ）に変換される。
【０１２０】
ＳＩＲ  ８  ＴＤＩ（００）ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ  ８，  ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ  ００，  ％ｃＴＤＩ
ＳＩＲ  ＴＤＩ、これは、１２０１００００としてＴＩＳＡコーディングに変換される。
【０１２１】
ＳＤＲ  ２４  ＴＤＩ（ｖａｌｕｅ）ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ  ２４，  ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ  ｖａｌｕｅ，  ％ｃＴＤＩ
ＳＤＲ  ＴＤＩ、これは、１００１００００としてＴＩＳＡコーディングに変換される。
【０１２２】
Ｒｅａｄ＿ＪＴＡＧ（ｖａｌｕｅ，Ｂ２．Ｒ）コマンドは、２つのＳＶＦ命令すなわちＳＩＲ  ８  ＴＤＩ（０１）およびＳＤＲ  １６  ＡＣＴＵＡＬ（ｖａｌｕｅ）に変換される。
【０１２３】
ＳＩＲ  ８  ＴＤＩ（０１）ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ  ８，  ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ  ０１，  ％ｃＴＤＩ
ＳＩＲ  ＴＤＩ、これは、１２０１００００としてＴＩＳＡコーディングに変換される。
【０１２４】
ＳＤＲ  １６  ＡＣＴＵＡＬ（ｖａｌｕｅ）ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ  １６，  ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ  ”ｖａｌｕｅ”，  ％ｃＧＥＮＥＲＩＣ２
ＳＤＲ  ＡＣＴＵＡＬ、これは、１０００８０００としてＴＩＳＡコーディングに変換される。
【０１２５】
ＳＥＴ動作のＴＩＳＡコーディングは、ＳＰＡＲＣ  Ｖ８  Ｍａｎｕａｌが、これらを、プロセッサの実装形態に従って異なるコーディングを有することができる「擬似命令」として識別するので、指定されない。
【０１２６】
決定されたＴＩＳＡコーディングを使用して、プリコンパイラ３３０は、今や、高水準ＪＴＡＧアクセスをそれに関連するＴＩＳＡアセンブラ命令に置換することができる。その結果が、Ｃを使用して指定された次のコードであり、このコードでは、ＪＴＡＧのＴＡＰへの呼出しが、関連するＴＩＳＡアセンブラ・コーディングによって置換されている。
１  ｉｎｃｌｕｄｅ  ＜ｓｔｄｉｏ．ｈ＞
２  ｉｎｃｌｕｄｅ  ＜ｊｔａｇ．ｈ＞
３
４  ｃｈａｒ  ｓｅｎｔ＿ｖａｌｕｅ，  ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ；
５
６  ｄｅｆｉｎｅ  ＭＡＸ＿ＣＯＵＮＴ  ２５６；
７
８  ｖｏｉｄ  ｍａｉｎ（ｖｏｉｄ）
９  ｛
１０  ｆｏｒ  （ｓｅｎｔ＿ｖａｌｕｅ＝０；ｓｅｎｔ＿ｖａｌｕｅ＜ＭＡＸ＿ＣＯＵＮＴ；ｓｅｎｔ＿ｖａｌｕｅ＋＋）
１１  ｛
１２    ａｓｍ  ｖｏｌａｔｉｌｅ  （”ＳＥＴ  ８，  ％ｃＧＥＮＥＲＩＣ１；
１３                    ＳＥＴ  ００，  ％ｃＴＤＩ；
１４                    ＳＩＲ  ＴＤＩ；
１５                    ＳＥＴ  ２４，  ％ｃＧＥＮＥＲＩＣ１；
１６                    ＳＥＴ  ＆ｓｅｎｔ＿ｖａｌｕｅ，  ％ｃＴＤＩ；
１７                    ＳＤＲ  ＴＤＩ；”）；
１８    ａｓｍ  ｖｏｌａｔｉｌｅ  （”ＳＥＴ  ８，  ％ｃＧＥＮＥＲＩＣ１；
１９                    ＳＥＴ  ０１，  ％ｃＴＤＩ；
２０                    ＳＩＲ  ＴＤＩ；
２１                    ＳＥＴ  １６，  ％ｃＧＥＮＥＲＩＣ１；
２２                    ＳＥＴ  ＆ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ，  ％ｃＧＥＮＥＲＩＣ２；
２３                    ＳＤＲ  ＡＣＴＵＡＬ”）；
２４        ｉｆ  （ｓｅｎｔ＿ｖａｌｕｅ  ！＝  ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ）  ｅｘｉｔ  （０）；
２５    ｝
２６    ｅｘｉｔ（１）；
２７  ｝
【０１２７】
このコードを、フロントエンド・アルゴリズム３２２に入力することができ、フロントエンド・アルゴリズム３２２は、プログラム・モデル３２３を生成する。プログラム・モデル３２３を、バックエンド・アルゴリズム３２４に入力することができ、バックエンド・アルゴリズム３２４は、ＴＩＳＡ原子的動作３５６を含む実行可能ＴＩＳＡバイナリ・ファイル（１つまたは複数）３５５を生成する。
【０１２８】
テーブル５４０の「ＴＩＳＡコーディング」列５４４は、ＴＩＳＡアセンブラ命令のバイナリ・コーディングを示す（たとえば、図４Ａ〜図４Ｅに示し、これに関して説明したようにＳＰＡＲＣ  Ｖ８  ＩＳＡを使用するＴＩＳＡの例示的実装形態に関して定義されるさまざまなルールを使用して）。
【０１２９】
本明細書で説明するように、ＴＩＳＡは、テストされるシステムのテスティングを実行する際のテスト粒度に関して完全な自由を提供する（すなわち、ＴＡＰレベルからスキャン・セグメント・レベルまで）。図２および図３に示され、図４Ａ〜図４Ｅおよび図５Ａ〜図５Ｂの例示的ＴＩＳＡ実装形態を使用してさらに説明されるように、テスト・パターンを、テスト生成ツールに対するソフトウェア・コンパイラによる明示的照会を使用して計算することができ、ソフトウェア・アルゴリズムに関する唯一の制限は、照会自体の解決である。
【０１３０】
例として、粗いレベルで、ＳＣからＴＧＴへの照会は、テストされるシステムのスキャン・チェーン全体を含むことができる（たとえば、古典的なＢＳＤＬベースのバウンダリ・スキャン・テスティングの場合など）。
【０１３１】
例として、微細なレベルで、ＳＣからＴＧＴへの照会は、レジスタまたはビットさえも含むことができる。たとえば、専用スキャン・セグメント・プリミティブは、機器アクセスおよびＴＡＰ再構成を大幅に加速し、コード再利用を増やし、さまざまな他の利益を提供することができる。
【０１３２】
例として、粗いレベルと微細なレベルとの間の中間レベルでは、ＳＣからＴＧＴへの照会を、関数的に行うことができる（たとえば、ＩＪＴＡＧおよび他の適切な標準規格などの標準規格を使用し、ＮＳＤＬおよび他の適切なオブジェクト指向記述言語などの記述言語を使用して）。
【０１３３】
この形で、ＴＩＳＡは、デバイス／レジスタ・アクセスがモデル空間で（すなわち、ＴＧＴ内で）解決されることを強制するのではなく、開発者がデバイス／レジスタ・アクセスをプログラム空間で（すなわち、ＳＣ内で）処理することを可能にし、これによって、開発者が分析粒度を彼らの必要および使用可能なリソースに適合させることを可能にする。
【０１３４】
さらに、ＴＩＳＡプロセッサが、たとえば自動テスト装置（Automated Test Equipment、ＡＴＥ）の場合など、十分なリソースを有する実施形態では、回路モデルの少なくとも一部を、プログラム・モデル内で実施することができ、これによって、ＴＩＳＡマシンがベクトル・パターンを直接に計算することが可能になる。
【０１３５】
さらに、ＴＩＳＡは、対話デバッギング（ローカルにおよび／またはリモートに）を含む対話テスティング、並列性、およびポータビリティなど、ならびにそのさまざまな組合せなど、ＴＩＳＡなしでは以前に可能でなかったさまざまな他のシステム・テスト能力をサポートすることを可能にする。これらの追加の能力に、これからさらに詳細に対処する。
【０１３６】
図６に、対話テスティング能力をサポートするＴＩＳＡベースのテスティング環境の実施形態を示す。
【０１３７】
図６に示されているように、ＴＩＳＡベースのテスティング環境６００は、ホスト・コンピュータ（ＨＣ）６０１、テスティング・システム（ＴＳ）６１０、およびテストされるシステム（ＳＵＴ）６２０を含む。
【０１３８】
ＨＣ６０１は、ＳＵＴ６２０のテスティングを制御するためにＴＳ６１０を制御するように構成されている。ＨＣ６０１は、メモリ６０４に結合されたプロセッサ６０２を含む。プロセッサ６０２およびメモリ６０４は、任意の適切なプロセッサおよびメモリとすることができる。
【０１３９】
メモリ６０４は、１つまたは複数のデバッガ制御プログラム６０５を格納する。デバッガ制御プログラム（１つまたは複数）は、ＨＣ６０１がＴＳ６１０上で動作するコンピュータ・プログラム（１つまたは複数）の実行をトレースし、望まれるか必要な場合にこれを変更することを可能にする。たとえば、デバッガ制御プログラム（１つまたは複数）６０５は、GNU Debugger（ＧＤＢ）、ｄｂｘデバッガ、Ｐｅｒｌデバッガ、Ｂａｓｈデバッガ、Ｐｙｔｈｏｎデバッガ、および同様の適切なデバッガ・プログラム、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【０１４０】
メモリ６０４は、１つまたは複数のデバッガ表示プログラム６０６をも格納することができる。デバッガ表示プログラム（１つまたは複数）は、ＨＣ６０１がデバッガ制御プログラム（１つまたは複数）６０５に関連する情報を表示することを可能にする。デバッガ制御プログラム（１つまたは複数）６０５に関連する情報を、デバッガ表示プログラム（１つまたは複数）６０６によって任意の適切な形で（たとえば、１つまたは複数のディスプレイ・デバイスを使用して）表示することができる。たとえば、デバッガ表示プログラム（１つまたは複数）６０６は、Ｉｎｓｉｇｈｔ（ＧＤＢへのグラフィカル・ユーザ・インターフェースである）、Data Display Debugger（ＤＤＤ、ＧＤＢおよび他のデバッガなどのさまざまなコマンドライン・デバッガのグラフィカル・ユーザ・インターフェースを提供する）、および同様の適切なデバッガ表示プログラム、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【０１４１】
ＴＳ６１０は、ＳＵＴ６２０をテストするためにＨＣ６０１によって制御される。ＴＳ６１０は、ＴＩＳＡと一貫する形で（たとえば、図１〜図３のＴＳ１１０に関して図示し、説明したものなど）機能するように構成され、さらに、対話テスティングをサポートする（たとえば、ＨＣ６０１上で動作するデバッガによるアクセスを使用可能にすることによって）ように構成されている。
【０１４２】
ＴＳ６１０は、メモリ６１４に結合されたＴＩＳＡプロセッサ６１２を含む。ＴＩＳＡプロセッサ６１２は、ＳＰＡＲＣ  Ｖ８（図４Ａ〜図４Ｅおよび図５に関して図示し、上で説明した）、およびＩＮＴＥＬなどの任意の適切なプロセッサを使用して実施することができる。メモリ６０４は、任意の適切なメモリとすることができる。
【０１４３】
メモリ６１４は、１つまたは複数のデバッガ・プログラム・スタブ６１５を格納する。デバッガ・プログラム・スタブ６１５は、ＨＣ６０１上で動作する対応するデバッガ制御プログラム（１つまたは複数）６０５のデバッガ制御を理解し、これによって、ＨＣ６０１がＴＳ６１０と通信することを可能にする。たとえば、デバッガ・スタブ（１つまたは複数）６１５は、ＧＤＢスタブ、ＤＢＸスタブ、Ｐｅｒｌスタブ、Ｂａｓｈスタブ、Ｐｙｔｈｏｎスタブ、および同様の適切なデバッガ・プログラム・スタブ、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【０１４４】
メモリ６１４は、ＴＩＳＡバイナリ・ファイル６１６を格納する。ＴＩＳＡバイナリ・ファイル６１６は、本明細書で図２および図３に示し、これに関して説明した形でＴＳ６１０によって生成される。ＴＩＳＡバイナリ・ファイル６１６は、ＳＵＴ６２０に対するテスティングを実行するためにＴＩＳＡプロセッサ６１２によって実行される。
【０１４５】
ＴＳ６１０は、ＴＩＳＡプロセッサ６１２に結合されたテスト・アクセス・ポート（ＴＡＰ）６１８をも含む。ＴＡＰ６１８は、ＨＣ６０１によって制御されている間にＴＩＳＡプロセッサ６１２がＳＵＴ６２０のテスティングを実行することを可能にするために、ＴＩＳＡプロセッサ６１２とＳＵＴ６２０との間のテスト・インターフェースを提供する。ＴＡＰ６１８は、任意の適切なＴＡＰ（たとえば、１１４９．１のＴＡＰ）とすることができる。
【０１４６】
ＴＩＳＡプロセッサ６１２は、インターフェース６１７を使用してＴＡＰ６１８とインターフェースする。インターフェース６１７は、ＴＡＰとテストされるシステムとの間の任意の適切なインターフェース（たとえば、ＴＣＫ、ＴＭＳ、ＴＤＩ、ＴＤＯ、およびオプションでＴＲＳＴ（ＴＡＰ６１８が１１４９．１のＴＡＰとして実施される場合）をサポートするインターフェースなど）とすることができる。
【０１４７】
図６に示されているように、ＨＣ６０１とＴＳ６１０との間にインターフェース６０９がある。インターフェース６０９は、ＨＣ６０１とＴＳ６１０との間のローカル通信および／またはリモート通信をサポートすることができる。したがって、ＨＣ６０１は、ローカルにおよび／またはリモートにＴＳ６１０を介してＳＵＴ６２０の対話テスティングを制御することができる。
【０１４８】
たとえば、ローカル・テスティングに関して、インターフェース６０９を、汎用非同期送受信回路（ＵＡＲＴ）インターフェース、および直列インターフェースなど、ならびにそのさまざまな組合せのうちの１つまたは複数として実施することができる。
【０１４９】
たとえば、リモート・テスティングに関して、インターフェース６０９を、伝送制御プロトコル（ＴＣＰ）／インターネット・プロトコル（ＩＰ）または任意の他の適切な通信プロトコルなどの任意の適切な通信能力を使用して実施することができる。これは、ＨＣ６０１およびＴＳ６１０が長い地理的距離だけ分離される可能性があり、それでもＨＣ６０１がＳＵＴ６２０のテスティングを実行するためにＴＳ６１０を制御することができる、リモート・テスティングを可能にする。
【０１５０】
ＴＩＳＡベースのテスティング環境６００では、ＨＣ６０１は、標準的な接続（たとえば、ＵＡＲＴ、およびＴＣＰ／ＩＰなど）を介してＴＳ６１０の動作を制御することによってＳＵＴ６２０に対するテスト実行をステップごとに制御することができ、これによって、対話テスティング能力および対話デバッギング能力を使用可能にする。
【０１５１】
明瞭にするために省略されてはいるが、ＨＣ６０１およびＴＳ６１０が、追加のプロセッサ、追加のメモリ、内部通信バス、入出力モジュール、および追加のサポート回路（たとえば、電源）など、ならびにそのさまざまな組合せなどのさまざまな他のコンポーネントを含むことができることを了解されたい。
【０１５２】
明瞭にするために省略されてはいるが、ＳＵＴ６２０を、ＴＩＳＡを使用してテストできる任意のテストされるシステムとすることができることを了解されたい。
【０１５３】
主に特定のタイプのデバッガ制御プログラム、デバッガ表示プログラム、およびインターフェースなどに関して図示し、説明したが、ＴＩＳＡベースのテスティング環境６００を、さまざまな他のデバッガ制御プログラム、デバッガ表示プログラム、およびインターフェースなど、ならびにそのさまざまな組合せを使用して完全に対話的なテスティング能力を使用可能にする形で実施できることを了解されたい。
【０１５４】
図７に、図６のＴＩＳＡベースのテスティング環境の例示的実装形態を示す。
【０１５５】
図７に示されているように、図７の例示的なＴＩＳＡベースのテスティング環境７００は、ＧＮＵツール・スイートが図５Ａの例示的なシステム・テスティング環境５００の対話テスティングをサポートするのに使用される、図６のＴＩＳＡベースのテスティング環境６００の実装形態である。
【０１５６】
図７に示されているように、例示的なＴＩＳＡベースのテスティング環境７００は、ホスト・コンピュータ（ＨＣ）７０１、テスティング・システム（ＴＳ）７１０、およびテストされるシステム（ＳＵＴ）７２０を含む。
【０１５７】
ＨＣ７０１は、プロセッサ７０２およびメモリ７０４を含む。図７のＨＣ７０１は、デバッガ制御プログラム（１つまたは複数）６０５がＧＤＢ（ＧＤＢ７０５）を使用して実施され、デバッガ表示プログラム（１つまたは複数）６０６がＤＤＤ（ＤＤＤ７０６）を使用して実施される、図６のＨＣ６０１の実装形態である。
【０１５８】
ＴＳ７１０は、ＴＩＳＡプロセッサ７１２およびメモリ７１４を含む。図７のＴＳ７１０は、ＴＩＳＡプロセッサ６１２がＳＰＡＲＣ  Ｖ８  ＩＳＡを使用して実施され（ＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサ７１２と表される）、デバッガ・プログラム・スタブ（１つまたは複数）６１５がＧＤＢスタブ（ＧＤＢスタブ７１５）を使用して実施され、ＴＩＳＡバイナリ・ファイル６１６がＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサ７１２に関連するＳＰＡＲＣ  Ｖ８  ＩＳＡに基づいて生成される（ＴＩＳＡバイナリ・ファイル７１６）、図６のＴＳ６１０の実装形態である。
【０１５９】
ＴＳ７１０は、ＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサ７１２に結合されたテスト・アクセス・ポート（ＴＡＰ）７１８をも含む。図７のＴＳ７１０は、ＴＡＰ６１８が１１４９．１のＴＡＰ（１１４９．１のＴＡＰ７１８）を使用して実施される、図６のＴＳ６１０の実装形態である。
【０１６０】
ＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサ７１２は、インターフェース７１７を使用して１１４９．１のＴＡＰ７１８とインターフェースする。インターフェース７１７は、ＴＣＫ、ＴＭＳ、ＴＤＩ、ＴＤＯ、およびオプションでＴＲＳＴをサポートする標準１１４９．１インターフェースである。
【０１６１】
ＳＵＴ７２０は、図５ＡのＳＵＴ５２０である。ＳＵＴ７２０は、図５ＡのＳＵＴ５２０のように、異なる基板上のトランスミッタおよびレシーバを含む。
【０１６２】
１１４９．１のＴＡＰ７１８は、ＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサ７１２がＨＣ７０１によって制御されている間にＳＵＴ７２０のテスティングを実行することを可能にするために、ＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサ７１２とＳＵＴ７２０との間のテスト・インターフェースを提供する。
【０１６３】
図７に示されているように、ＨＣ７０１とＴＳ７１０との間にインターフェース７０９がある。インターフェース７０９は、ＨＣ７０１とＴＳ７１０との間のローカル通信および／またはリモート通信（たとえば、ネットワークを介する）をサポートすることができる。したがって、ＨＣ７０１は、ローカルにおよび／またはリモートにＴＳ７１０を介してＳＵＴ７２０の対話テスティングを制御することができる。
【０１６４】
例示的なＴＩＳＡベースのテスティング環境７００では、ＨＣ７０１は、インターフェース７０９を介してＴＳ７１０の動作を制御することによってＳＵＴ７２０に対するテスト実行をステップごとに制御することができ、これによって、対話テスティング能力および対話デバッギング能力を使用可能にする。
【０１６５】
図７の左側のほとんどが、既存のコンピュータ・サイエンス要素すなわちＨＣ７０１全体ならびにＴＳ７１０上のＧＤＢスタブ７１５を再利用することを了解されたい。これは、図７の中央部分についても同一であり、中央部分では、ＨＣ７０１とＴＳ７１０（ならびにそれらに関連する副要素）との間の類似が明白である。ＴＩＳＡは、システム・テスティングを提供するためにこのインフラストラクチャ全体を活用することを可能にする。
【０１６６】
例として、図５Ａのシステム・テスト環境５００（関連する例示的なＣプログラム、ＳＶＦ命令、ＴＩＳＡアセンブラ命令、およびＴＩＳＡコーディングを含む）を参照すると、（ａ）変数「ｓｅｎｔ＿ｖａｌｕｅ」および「ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ」を監視している間のステップごとの実行、（ｂ）ｔａｐに送るべき値（変数「ｓｅｎｔ＿ｖａｌｕｅ」）のオン・ザ・フライ変更、（ｃ）ループ終了条件の変更、および（ｄ）すべての変数の監視など、ならびにそのさまざまな組合せなど、ＧＤＢ（または任意の他の適切なデバッガ）を活用することによってＴＩＳＡが使用可能にすることのできる多数の対話テスト動作がある。これらの対話テスト動作は、ＧＤＢの標準動作であり、ＴＩＳＡは、上で説明したアルゴリズム部分とテスト・アクセス部分との間の制御を自動的にハンドオフするＴＩＳＡの能力に起因して、これらを直接に使用することができる。ＴＩＳＡがない場合には、特殊なツーリングを開発し、各ハンドオフ実装形態に適合させる必要があるはずである。
【０１６７】
図７の例示的なＴＩＳＡベースのテスティング環境７００を、主に、特定のテストされるシステムの対話テスティングをサポートするのにＧＮＵツール・スイートを使用することに関して本明細書で図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、ＴＩＳＡベースのテスト環境での対話テスティング能力を、任意のタイプのテストされるシステムをテストするために任意の適切なツール・スイートを使用して実現できることを了解するであろう。
【０１６８】
図６のＴＩＳＡベースのテスティング環境６００および図７の例示的なＴＩＳＡベースのテスティング環境７００を、主に、テスティングが事前に決定されたアルゴリズムに従ってステップごとに行われる直線的なテスト手順に関して本明細書で図示し、説明したが（ＴＩＳＡによって使用可能にされる対話テスティング能力を説明する際に明瞭にするために）、ＴＩＳＡによって使用可能にされるコンピュータ・サイエンス経験およびコンピュータ・サイエンス技法の活用に起因して、他のより複雑な対話テスティング・シナリオが可能であることを了解されたい。ＴＩＳＡによって使用可能にされるより複雑な対話テスティング・シナリオの例を、図８に示し、これに関して本明細書で説明する。これが、単に１つの例であり、本明細書の教示によって情報を与えられた当業者が多数の他の対話テスティング・シナリオおよび対話テスティング・アプリケーションでＴＩＳＡを使用できることを了解されたい。
【０１６９】
本明細書で説明されるように、粒度と対話との両方をサポートすることに加えて、ＴＩＳＡは、並列性をもサポートする。
【０１７０】
ＴＩＳＡは、システム・テスティング・フローをコンピュータ・サイエンス・ソフトウェア・フローと自然に十分に合併し、したがって、両方のフローの最良の態様を活用することができる。例として、ＳＴＡＰＬなどの手法は、定義により、完全に順次的なので、機器の並列制御を扱うのが困難である。さらに、ＭＴＣおよびＳｙｓｔｅｍＢＩＳＴなどの手法は、本質的に順次的であり、シングルタスクであり、したがって、並列性をサポートするためにそのような手法をプログラムすることは難しく、不便であるはずである。対照的に、並列実行は、コンピュータ・サイエンスでは周知の問題であり、現在は、たとえば、すべてのオペレーティング・システムの根底にある。並列実行をサポートする大量のライブラリが使用可能であり（たとえば、ＰＯＳＩＸスイート、およびＢＯＯＳＴスイートなど）、ほとんどの現代のプロセッサは、マルチタスキングおよびコンテキスト切替えを効率的にサポートするように設計されている（たとえば、たとえばＳＰＡＲＣ  Ｖ８は、回転するレジスタ・ウィンドウを実施する）。ＴＩＳＡによって使用可能にされるシステム・テスティング・フローとコンピュータ・サイエンス・ソフトウェア・フローとの間の自然な相互作用は、ＴＩＳＡが並列性に対するそのようなコンピュータ・サイエンス手法を完全に活用することを可能にする。
【０１７１】
ＴＩＳＡによる並列性能力のサポートは、例によってよりよく理解することができる。例として、図５Ａおよび図７のテストされるシステム５２０のトランスミッタ５２２とレシーバ５２６との間のＴＲチャネルのデータ転送速度を最適化するという問題を検討されたい。これは、第１基板５２１上のトランスミッタ５２２からデータ・パターンのストリームを送ることと、第２基板５２５上のレシーバ５２６でデータ・パターンの対応するストリームを受け取ることと、ビット速度／誤り率を計算し、それ相応にトランスミッタ５２２および／またはレシーバ５２６のパラメータを調整するためにデータ・パターンの送られたストリームおよび受け取られたストリームを比較することとを含むはずである。この最適化を、並列に動作する３つのプログラムを使用して効率的に実行することができる。
【０１７２】
図８に、図５Ａおよび図７のテストされるシステムのトランスミッタ−レシーバ・チャネルの最適化を実行するための例示的プログラム・アーキテクチャを示す。
【０１７３】
図８に示されているように、例示的なプログラム・アーキテクチャは、パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６を含む。パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６は、協力して、図５Ａおよび図７のテストされるシステム５２０のトランスミッタ５２２とレシーバ５２６との間のＴＲチャネルのデータ転送速度を最適化する。
【０１７４】
パターン・ジェネレータ８０２は、適切な入力データ・パターンを第１基板５２１上のトランスミッタ５２２（Ｔ）に送る。パターン・ジェネレータ８０２は、第１基板５２１（Ｂ１）のスキャン・チェーン５２３を介してトランスミッタ５２２に入力データ・パターンを供給するために、ＴＡＰ（実例として、図５ＡのＴＡＰ５１０、図７のＴＡＰ７１８）にアクセスすることができる。パターン・ジェネレータ８０２は、任意の適切な形で（たとえば、図５Ａに関して本明細書で説明したコードの行１２〜１３で指定されるように）トランスミッタ５２２に入力データ・パターンを供給することができる。入力データ・パターンは、トランスミッタ５２２とレシーバ５２６との間のＴＲチャネルを最適化するのに適する任意のデータ・パターンとすることができる。たとえば、入力データ・パターンを、事前に計算されたパターン、およびランダム・パターンなど、ならびにそのさまざまな組合せとすることができる。
【０１７５】
パターン・レシーバ８０４は、第２基板５２５上のレシーバ５２６（Ｒ）から適切な出力データ・パターンを収集する。パターン・レシーバ８０４は、第２基板５２５（Ｂ２）のスキャン・チェーン５２７を介してレシーバ５２６から出力データ・パターンを収集するために、ＴＡＰ（実例として、図５ＡのＴＡＰ５１０、図７のＴＡＰ７１８）にアクセスすることができる。パターン・レシーバ８０４は、任意の適切な形で（たとえば、図５Ａに関して本明細書で説明したコードの行１４〜１５で指定されるように）レシーバ５２６から出力データ・パターンを収集することができる。
【０１７６】
コンパレータ８０６は、パターン・ジェネレータ８０２およびパターン・レシーバ８０４と通信する。コンパレータは、入力データ・パターンと出力データ・パターンとを比較する。コンパレータ８０６は、ＴＲチャネルのビット伝送速度およびビット誤り率を評価し、この比較の結果に基づいて、ＴＲチャネルのパラメータを最適化するためにトランスミッタ５２２とレシーバ５２６との両方の制御レジスタ（明瞭にするために図５Ａおよび図７では省略されている）にアクセスすることができる。
【０１７７】
そのような最適化テスティング手順を実行するために、パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６は、並列に働く必要があり、それぞれが、他とは独立にＴＡＰにアクセスできなければならない。このタイプの制御構造は、ＴＡＰを介する１点直列ハンドオフ制御だけをサポートするように開発された伝統的な環境では、コーディングするのが非常に難しい。このタイプの制御構造は、やはり同一の直列ＴＡＰアクセス・パラダイムを共有するＭＴＣまたは他のそのような手法を使用する環境でも、コーディングするのが非常に難しい。対照的に、ＴＩＳＡは、テスト・アクセスに関するそのような仮定を伴って設計されているのではなく、ＴＩＳＡでは、テスト・アクセスが、他のプロセッサ・リソースに似た形で処理され、テスト・アクセス命令は、古典的なＩＳＡ命令と直接に混合される。ＴＩＳＡを使用すると、図８の最適化テスティング手順を、プロセス、およびスレッド・プロセス間通信（ＩＰＣ）など、ならびにそのさまざまな組合せなどの標準的構造を使用する任意のマルチタスク・オペレーティング・システムによって実行することができる。この形で、パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６は、ＴＡＰへのアクセスを共有することができ、たとえば、たとえばダイクストラのセマフォなどの周知の構造およびアルゴリズムを使用して、すべてのプロセッサ・リソースについて行われるのと同様に、すべての最終的なＴＡＰ共有問題を解決することができる。したがって、既存のシステム・テスティング能力は並列性をサポートしないが、ＴＩＳＡが簡単に完全に並列性をサポートすることは明白である。
【０１７８】
上で説明したように、ＴＩＳＡは、テスト・アクセス方法または関連するテスト・プログラム区分に関する仮定を一切設けず、テスト命令は、テスト命令と古典的ＩＳＡ命令との間の先験的分離を全く伴わずに、古典的ＩＳＡ命令と同一の形または実質的に同一の形で扱われる。これは、ＴＩＳＡをすべての既存の（および最もありそうなことに将来の）コンピュータ・サイエンス・アルゴリズムおよびコンピュータ・サイエンス構造と完全に互換にすることを可能にし、これは、既存のテスト・プロセッサ手法がサポートできないことである。
【０１７９】
したがって、すべての既存ソフトウェア・ライブラリをＴＩＳＡアーキテクチャにポーティングできることを了解されたい。たとえば、ＰＯＳＩＸスイートおよびＢＯＯＳＴスイートを活用することによって、マルチタスキングおよび並列性を入手することは、簡単であるはずである（たとえば、図８に示し、これに関して本明細書で説明したように）。さらに、ＴＩＳＡが既存ＩＳＡの一般化として入手される（たとえば、図５Ａおよび図５Ｂに示し、これに関して説明した例示的なＳＰＡＲＣ  Ｖ８  ＴＩＳＡ実装形態に関して図示し、説明したように）場合には、ＴＩＳＡの開発元であるＩＳＡが既にそのようなソフトウェア・ライブラリを含むので、ポーティングが必要でない場合さえあることを了解されたい。
【０１８０】
さらに、さまざまな他のコンピュータ・サイエンス技法を、ＴＩＳＡを使用する改善されたシステム・テスティングを提供するために利用できることを了解されたい。たとえば、ＴＩＳＡのために活用できるそのようなコンピュータ・サイエンス技法のいくつかの例は、（ａ）プラットフォーム独立コーディング・スタイルの使用、（ｂ）ＩＳＡ対ＩＳＡコンバータの使用、（ｃ）プラットフォーム独立バイトコードを入手するための、たとえばＪａｖａのような、仮想マシン手法の使用、またはＴＩＳＡになるためのＪａｖａ仮想マシン自体の拡張、および（ｄ）その後に適切なドライバによってプリミティブに変換される、いくつかのＴＩＳＡソフトウェア・インターフェースを標準化するためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）の使用を含む。これらの例が、単にＴＩＳＡのために活用できるコンピュータ・サイエンス技法の少数の例であることを了解されたい。
【０１８１】
図９に、テストされるシステムの少なくとも一部をテストする際のプロセッサによる使用のために適合されたテスト命令セット・アーキテクチャ（ＴＩＳＡ）命令を含むＴＩＳＡフローを形成するためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法の一実施形態を示す。
【０１８２】
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法９００のステップの少なくとも一部を、同時にまたは図９に関して図示され説明されるものとは異なる順序で実行することができる。
【０１８３】
ステップ９０２では、方法９００が開始される。
【０１８４】
ステップ９０４では、命令の第１セットを生成する。命令の第１セットは、プロセッサによってサポートされるＩＳＡ命令を含む（すなわち、プロセッサにＴＩＳＡを提供するために活用されるＩＳＡ命令）。
【０１８５】
ステップ９０６では、命令の第２セットを生成する。命令の第２セットは、テストされるシステムに関連するテスト命令を含む。命令の第２セットは、たとえば図２のＴＧＴ２１０に関して図示し、説明したように、図３のＴＧＴ３１０に関して図示し、説明したように、および／またはテスト命令を生成する任意の他の適切な方法を使用して、任意の適切な形で生成することができる。
【０１８６】
ステップ９０８では、命令の第１セットおよび命令の第２セットを統合して、これによってＴＩＳＡ命令を形成する。ＴＩＳＡ命令は、プロセッサにＴＩＳＡを提供する。
【０１８７】
ステップ９１０では、ＴＩＳＡ命令を格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。ＴＩＳＡ命令を、任意の他の適切な形で処理することができる。
【０１８８】
ステップ９１２では、方法９００が終了する。
【０１８９】
ＴＩＳＡを、任意の適切な形で、たとえば、図１０の方法１０００に関して図示し、説明するように、図２のテスト・システムおよび図１１Ａの関連する方法１１１０に関して図示し、説明するように、図３のテスト・システムおよび図１１Ｂの関連する方法１１２０に関して図示し、説明するように、ならびに／またはＴＩＳＡを形成する任意の適切な方法を使用して、形成することができる。
【０１９０】
図１０に、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法１０００のステップの少なくとも一部を、同時にまたは図１０に関して図示され説明されるものとは異なる順序で実行することができる。ステップ１００２で、方法１０００が開始される。
【０１９１】
ステップ１００４では、命令の第１セットを生成する。命令の第１セットは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成される命令（たとえば、プロセッサによってサポートされるＩＳＡのＩＳＡ命令）を含む。
【０１９２】
ステップ１００６では、命令の第２セットを生成する。命令の第２セットは、テストされるシステムに関連する少なくとも１つの記述ファイルをコンパイルすることによって生成されるテスト命令を含む。
【０１９３】
ステップ１００８では、命令の第１セットおよび第２セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第１セットの命令が、命令の第２セットのテスト命令の実行を制御する際の使用のために適合される。
【０１９４】
ステップ１０１０では、命令の組み合わされたセットを格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
【０１９５】
ステップ１０１２で、方法１０００は終了する。
【０１９６】
図１１Ａおよび図１１Ｂに、図９に示し、これに関して説明した方法９００および／または図１０に示し、これに関して説明した方法１０００のより詳細な実施形態を示す。
【０１９７】
図１１Ａに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に特定のシーケンスで実行されるものとして図示され、説明されるが、図１１Ａの方法１１１０のステップの少なくとも一部を、図１１Ａに示し、これに関して説明するものとは異なる順序で実行することができる。図１１Ａを、図２および図２に関連する説明と共に見ることによってよりよく理解することができる。
【０１９８】
ステップ１１１１で、方法１１１０が開始される。
【０１９９】
ステップ１１１２では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成され（たとえば、プロセッサによってサポートされるＩＳＡのＩＳＡ命令）、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルは、少なくとも１つの呼出しを含む。
【０２００】
ステップ１１１３では、命令の第１セットを生成する。命令の第１セットは、プログラム・モデルを使用して生成される。少なくとも１つの計算要求も、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルに含まれる少なくとも１つの呼出しを使用して生成される。
【０２０１】
ステップ１１１４では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも１つのシステム記述ファイルをコンパイルすることによって生成される。
【０２０２】
ステップ１１１５では、命令の第２セットを生成する。命令の第２セットは、回路モデルおよび少なくとも１つの計算要求を使用して生成される。
【０２０３】
ステップ１１１６では、命令の第１セットおよび第２セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第１セットの命令が、命令の第２セットのテスト命令の実行を制御する際の使用のために適合される。
【０２０４】
ステップ１１１７では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
【０２０５】
ステップ１１１８では、方法１０００が終了する。図１１Ｂに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に順次実行されるものとして図示され、説明されるが、図１１Ｂの方法１１２０のステップの少なくとも一部を、同時にまたは図１１Ｂに示し、これに関して説明するものとは異なる順序で実行することができる。図１１Ｂを、図３および図３に関連する説明と共に見ることによってよりよく理解することができる。
【０２０６】
ステップ１１２１で、方法１１２０が開始される。
【０２０７】
ステップ１１２２では、少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよび少なくとも１つのテスト動作記述ファイルを、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルを前処理することによって生成する。
【０２０８】
ステップ１１２３では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも１つのシステム記述ファイルおよび少なくとも１つのテスト動作記述ファイルをコンパイルすることによって生成される。
【０２０９】
ステップ１１２４では、テスト動作のセットを生成する。テスト動作のセットは、回路モデルを使用して生成される。テスト動作のセットからのテスト動作は、テスト・プリミティブ（たとえば、回路モデルを生成するテスト生成ツールによって定義されるテスト・プリミティブ）のセットを使用して記述される。テスト・プリミティブのセットは、テストされるシステムをテストする際の使用のために適合されたテスト動作を含む。
【０２１０】
ステップ１１２５では、テスト動作のセットのテスト・プリミティブを命令セット・アーキテクチャのソフトウェア命令と組み合わせての使用のために適合されたテスト命令に変換することによって、テスト動作のセットをテスト命令のセットに変換する。
【０２１１】
ステップ１１２６では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよびテスト命令のセットをコンパイルすることによって生成される。
【０２１２】
ステップ１１２７では、命令の組み合わされたセットを生成する。命令の組み合わされたセットは、プログラム・モデルを使用して生成される。命令の組み合わされたセットは、（ａ）少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルから決定されたソフトウェア命令および（ｂ）テスト命令のセットからのテスト命令を含む。
【０２１３】
ステップ１１２８では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
【０２１４】
ステップ１１２９では、方法１１２０が終了する。
【０２１５】
図１２に、ＴＩＳＡプロセッサ・アーキテクチャの例示的実施形態を示す。
【０２１６】
図１２に示されているように、ＴＩＳＡプロセッサ・アーキテクチャ１２００は、ＴＩＳＡプロセッサ１２１０およびメモリ１２２０を含む。
【０２１７】
ＴＩＳＡプロセッサ１２１０は、ＳＰＡＲＣ  Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、ＴＩＳＡを使用するシステム・テスティングを実行するのに適する任意のプロセッサとすることができる。
【０２１８】
メモリ１２２０は、ランダム・アクセス・メモリ、および持続性メモリなど、ならびにそのさまざまな組合せのうちの１つまたは複数を含む、ＴＩＳＡを使用するシステム・テスティングをサポートするためのＴＩＳＡプロセッサ１２１０による使用に適する任意のメモリを含むことができる。メモリ１２２０は、テスト・プログラム、ＴＩＳＡ命令、およびテスティング・データなど、ならびにそのさまざまな組合せなど、ＴＩＳＡを使用するシステム・テスティングを実行するのに必要な任意の情報を格納することができる。
【０２１９】
一実施形態では、たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００は、図２および図３に示し、これに関して説明したＴＩＳＡフローをサポートすることができる。
【０２２０】
一実施形態では、たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００は、図６に示し、これに関して説明したテスティング・システム６１０のＴＩＳＡプロセッサ６１２およびメモリ６１４に似た形で動作することができる。たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００を、図７に示し、これに関して説明したテスティング・システム７１０内など、ＳＰＡＲＣ  Ｖ８  ＴＩＳＡプロセッサおよび関連するメモリを使用して実施することができる。そのような実施形態では、ＴＩＳＡプロセッサ１２１０自体が、ＩＳＡ命令とＴＩＳＡ命令との両方を解釈し、実行する。
【０２２１】
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用される装置は、テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をＴＡＰを介してテストするためにテスト命令セット・アーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セット・アーキテクチャの命令のセットは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、ＴＡＰに関連する複数のテスト命令を含む命令の第２セットとを含み、命令の第１セットの命令および命令の第２セットの命令は、これによってテスト命令セット・アーキテクチャの命令のセットを形成するために統合される。
【０２２２】
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用されるＴＩＳＡプロセッサは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含む命令の第１クラスと、ＴＡＰに関連するテスト命令を含む命令の第２クラスとを含み、命令の第１セットのＩＳＡ命令および命令の第２セットのテスト命令は、テストされるシステムの少なくとも一部をテストするために適合されたＴＩＳＡを形成するために統合される。
【０２２３】
一実施形態では、テストされるシステム（ＳＵＴ）をテスト・アクセス・ポート（ＴＡＰ）を介してテストするコンピュータ・プロセッサは、ＴＡＰを介するテストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セット・アーキテクチャ（ＴＩＳＡ）に従って命令を処理するように構成された回路網を含む。ＴＩＳＡは、第１タイプの複数の命令および第２タイプの複数の命令を含み、命令の第１タイプは、コンピュータ・プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含み、命令の第２タイプは、ＴＡＰを介してテストされるシステムをテストするためのテスト命令を含む。
【０２２４】
主にＴＩＳＡプロセッサが特定の形で（たとえば、異なるクラスおよび／またはタイプの命令を記述するのに特定の言語を使用して）定義される実施形態に関して上で図示し、説明したが、ＴＩＳＡを、本明細書で提供されるさまざまなＴＩＳＡの図示および説明によって完全にサポートされる他の形で定義できることを了解されたい。
【０２２５】
主に、ＴＩＳＡをサポートするのに単一プロセッサを使用してＴＩＳＡプロセッサ・アーキテクチャが実施される実施形態に関して本明細書で図示され、説明されるが、他の実施形態では、ＴＩＳＡプロセッサ・アーキテクチャを、複数のプロセッサを使用して実施することができる。
【０２２６】
図１３に、システム・テスティング能力を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す。
【０２２７】
図１３に示されているように、テスト・プロセッサ・アーキテクチャ１３００は、通信経路１３３０を介して通信する主プロセッサ１３１０および副プロセッサ１３２０を含む。
【０２２８】
主プロセッサ１３１０は、ＳＰＡＲＣ  Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。主プロセッサ１３１０は、テストされるシステムをテストする命令を実行する。一実施形態では、たとえば、主プロセッサ１３１０は、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００のＣＰＵ１２１０によってサポートされる機能に似たテスティング機能をサポートすることができる（たとえば、テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用する場合に）。一実施形態では、たとえば、主プロセッサ１３１０は、ＴＩＳＡを利用しないテスト・プロセッサ・アーキテクチャ内のテストするプロセッサによってサポートされるテスティング機能をサポートすることができる。主プロセッサ１３１０は、さまざまな他のテスティング能力をサポートすることができる。
【０２２９】
副プロセッサ１３２０は、ＳＰＡＲＣ  Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。副プロセッサ１３２０は、テストされるシステム（明瞭にするために省略されている）へのテスト・アクセス・ポート（ＴＡＰ）インターフェースをサポートする。このＴＡＰインターフェースは、任意の適切なＴＡＰとインターフェースすることができる。たとえば、このＴＡＰインターフェースは、ＩＥＥＥ１１４９．１のＴＡＰまたはテストされるシステムをテストするのに使用できる任意の他の適切なＴＡＰへのインターフェースを提供することができる。
【０２３０】
主プロセッサ１３１０および副プロセッサ１３２０は、テストされるシステムの少なくとも一部のテストを実行するために協力する。
【０２３１】
主プロセッサ１３１０は、テストされるシステムをテストするテスト命令を実行する。このテスト命令は、ＴＩＳＡのテスト命令とすることができ（テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用する場合）、あるいはＴＩＳＡに関連しないテスト命令とすることができる（テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用しない場合）。主プロセッサ１３１０は、テスト命令の実行中に、テストされるシステムのＴＡＰの制御に関係する命令（たとえば、テストされるシステムのＴＡＰコントローラに入力データをロードする命令、テストされるシステムのＴＡＰコントローラから出力データを読み取る命令、および同様の命令、ならびにそのさまざまな組合せなど）を検出する。主プロセッサ１３１０は、副プロセッサ１３２０にＴＡＰ関連命令を供給する。副プロセッサ１３２０は、主プロセッサ１３１０からそのＴＡＰ関連命令を受け取る。副プロセッサ１３２０は、そのＴＡＰ関連命令を実行する。主プロセッサ１３１０は、副プロセッサ１３２０が主プロセッサ１３１０から受け取ったＴＡＰ関連命令を実行する間に、テスト命令の実行を継続する。この形で、主プロセッサ１３１０は、副プロセッサ１３２０がテストされるシステムのＴＡＰを介するスキャン動作を制御する間に、コンテキスト切替えを実行し、動作を継続することができる。これは、単一プロセッサがＴＡＰを制御している間に、その単一プロセッサが、他の動作の実行を止められるので、単一プロセッサ手法を使用すると困難である。したがって、テスト・プロセッサ・アーキテクチャ１３００内のような複数プロセッサの使用は、特にＴＡＰを介する動作が通常はプロセッサが単一の動作を実行するのに要する時間と比較して長い時間を要することを考慮すると、ハイエンド・プロセッサを使用する必要なしにテスティング効率の大幅な改善を提供する。
【０２３２】
テストされるシステムの少なくとも一部のテストを実行するための主プロセッサ１３１０と副プロセッサ１３２０との間の協力は、通信経路１３３０によって容易にされる。通信経路１３３０は、主プロセッサ１３１０と副プロセッサ１３２０との間通信の任意の適切な手段を使用して実施することができ、この手段は、テスト・プロセッサ・アーキテクチャ１３００がそれを用いて実施されるマルチプロセッサ・アーキテクチャのタイプに依存する可能性がある。たとえば、通信経路１３３０は、メイン・プロセッサ・インターフェース・バス、補助プロセッサ・インターフェース、および通信インターフェース（たとえば、シリアライザ−デシリアライザ（ＳＥＲＤＥＳ）インターフェースまたは他の適切な通信インターフェース）など、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【０２３３】
明瞭にするために省略されているが、テスト・プロセッサ・アーキテクチャ１３００が、メモリ（たとえば、ランダム・アクセス・メモリ、持続性メモリ、およびキャッシュ・メモリなど、ならびにそのさまざまな組合せ）を含む。テスト・プロセッサ・アーキテクチャ１３００のメモリは、主プロセッサ１３１０および副プロセッサ１３２０によって共有されるメモリ、主プロセッサ１３１０に専用のメモリ、および副プロセッサ１３２０に専用のメモリなど、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【０２３４】
明瞭にするために省略されているが、テスト・プロセッサ・アーキテクチャ１３００が、バス、およびＩ／Ｏ回路など、ならびにそのさまざまな組合せなどのさまざまな他のサポート回路を含むことができることを了解されたい。
【０２３５】
図１３のテスト・プロセッサ・アーキテクチャ１３００を、複数の形で実施することができる。
【０２３６】
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置（ＣＰＵ）がシステム・テスティングをサポートするためにテスト・コプロセッサ・ユニット（ＴＣＰＵ）と協力する、テスト・コプロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図１４に示し、これに関して説明する。
【０２３７】
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置（ＣＰＵ）がシステム・テスティングをサポートするためにテスト付属プロセッサ・ユニット（ＴＡＰＵ）と協力する、テスト付属プロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図１５に示し、これに関して説明する。
【０２３８】
図１４に、テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す。テスト・コプロセッサ・アーキテクチャ１４００は、ＴＩＳＡを使用するシステム・テスティングをサポートするためのＴＩＳＡプロセッサ・アーキテクチャとしての使用に適する。テスト・コプロセッサ・アーキテクチャ１４００は、ＴＩＳＡを使用しないシステム・テスティングをサポートするためのテスト・プロセッサ・アーキテクチャとしての使用にも適する。
【０２３９】
テスト・コプロセッサ・アーキテクチャ１４００は、中央処理装置（ＣＰＵ）１４１０、テスト・コプロセッサ・ユニット（ＴＣＰＵ）１４２０、メイン・メモリ１４３０、およびフラッシュ・メモリ１４４０を含む。
【０２４０】
テスト・コプロセッサ・アーキテクチャ１４００は、メイン・プロセッサ・インターフェース・バス１４５１を含む。ＣＰＵ１４１０、ＴＣＰＵ１４２０、メイン・メモリ１４３０、およびフラッシュ・メモリ１４４０は、それぞれ、メイン・プロセッサ・インターフェース・バス１４５１に結合される（または、他の形でこれと通信できるように構成されている）。
【０２４１】
テスト・コプロセッサ・アーキテクチャ１４００は、補助プロセッサ・インターフェース１４５２をも含むことができ、補助プロセッサ・インターフェース１４５２は、ＣＰＵ１４１０およびＴＣＰＵ１４２０を直接に結合し、これによって、ＣＰＵ１４１０とＴＣＰＵ１４２０との間の直接通信を可能にする。
【０２４２】
ＣＰＵ１４１０は、テストされるシステムのシステム・テスティングを実行するのに適する任意のＣＰＵとすることができる。ＣＰＵ１４１０は、図１３に示し、これに関して説明した主プロセッサ１３１０によってサポートされるテスティング能力をサポートする。
【０２４３】
ＴＣＰＵ１４２０は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のＣＰＵとすることができる。ＴＣＰＵ１４２０は、テスト・アクセス・ポート（ＴＡＰ）インターフェース１４６０をサポートし、ＴＡＰインターフェース１４６０は、任意の適切なＴＡＰ（たとえば、ＩＥＥＥ１１４９．１のＴＡＰまたはテストされるシステムをテストするのに使用される任意の他の適切なＴＡＰなど）とインターフェースすることができる。ＴＣＰＵ１４２０は、図１３に示し、これに関して説明した副プロセッサ１３２０によってサポートされるテスティング能力をサポートする。
【０２４４】
ＣＰＵ１４１０およびＴＣＰＵ１４２０は、図１３に示し、これに関して説明した主プロセッサ１３１０および副プロセッサ１３２０に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。ＣＰＵ１４１０およびＴＣＰＵ１４２０は、ＴＣＰＵ１４２０がテスティング中にテストされるシステムのＴＡＰを制御するＴＡＰ関連命令を実行する間にＣＰＵ１４１０がテスト命令を処理する動作を継続することを可能にするために、命令例外処理を利用する。
【０２４５】
ＣＰＵ１４１０は、テストされるシステムをテストするテスト命令を実行する。ＣＰＵ１４１０は、テスト命令の実行中に命令例外（すなわち、テストされるシステムのＴＡＰの制御に関係する命令）を検出し、その命令例外をＴＣＰＵ１４２０に供給する。ＴＣＰＵ１４２０は、ＣＰＵ１４１０からその命令例外を受け取り、その命令例外を処理し、ＴＣＰＵ１４２０が、ＣＰＵ１４１０が他のタスク（たとえば、他のテスティング命令の実行）を実行するために動作し続ける間にその命令例外を処理できるようになっている。言い換えると、ＣＰＵ１４１０およびＴＣＰＵ１４２０は、システム・テスティング中に協力し、ＴＣＰＵ１４２０がＣＰＵ１４１０によって検出された命令例外を処理する間にＣＰＵ１４１０がコンテキストを切り替え、他のタスクを実行するために動作し続けられるようにし、これによって、システム・テスティング効率を改善する。
【０２４６】
一実施形態では、ＣＰＵ１４１０は、たとえばＣＰＵ１４１０の性能を改善するために、キャッシュ１４１１を含む。
【０２４７】
一実施形態では、ＴＣＰＵ１４２０は、直接メモリ・アクセス（ＤＭＡ）ユニット１４２１を含み、ＤＭＡユニット１４２１は、システム・テスティングをサポートして使用するのに適する任意のタイプのＤＭＡユニットとすることができる。一実施形態では、たとえば、ＤＭＡユニット１４２１は、スキャッタ／ギャザ（Ｓ／Ｇ）ＤＭＡユニットである。ＴＣＰＵ１４２０は、ＣＰＵ１４１０から受け取った命令例外を処理するためおよびメモリ内に格納された実体的なデータに効率的にアクセスするためにＤＭＡユニット１４２１を利用することができる。一実施形態では、ＣＰＵ１４１０は、命令例外に出会う前に、Ｓ／ＧのＤＭＡテーブルを構成することができる。
【０２４８】
一実施形態では、ＴＣＰＵ１４２０は、特殊化されたＴＣＰＵ命令のセットをサポートする。特殊化されたＴＣＰＵ命令のセットは、ＴＡＰアクセスおよびＴＡＰ制御をサポートすることができる。特殊化されたＴＣＰＵ命令のセットを、ＴＡＰ状態機械に対して特定のＴＡＰ動作を実行するためにＴＣＰＵ１４２０によって使用することができる。
【０２４９】
ＣＰＵ１４１０およびＴＣＰＵ１４２０は、ＣＰＵ１４１０によるテスト命令の実行、ＴＣＰＵ１４２０による命令例外処理、およびＴＣＰＵ１４２０によるＴＣＰＵ命令の実行など、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ１４３０および／またはフラッシュ・メモリ１４４０を利用する。メイン・メモリ１４３０は、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ１４４０は、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の持続性メモリとすることができる。ＣＰＵ１４１０およびＴＣＰＵ１４２０は、調停されるアクセスを用いてメモリを共有する。ＣＰＵ１４１０およびＴＣＰＵ１４２０は、情報を交換するためにメモリを共有することもできる。主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、ＣＰＵ１４１０およびＴＣＰＵ１４２０によって実行される機能をサポートするために使用できることを了解されたい。
【０２５０】
ＣＰＵ１４１０およびＴＣＰＵ１４２０は、ＣＰＵ１４１０とＴＣＰＵ１４２０との間の通信、およびＣＰＵ１４１０および／またはＴＣＰＵ１４２０とテスト・コプロセッサ・アーキテクチャ１４００の他のコンポーネント（たとえば、メイン・メモリ１４３０、フラッシュ・メモリ１４４０、および他のコンポーネント）など、ならびにそのさまざまな組合せを使用して、テストされるシステムのテスティングを実行する。この通信を、メイン・プロセッサ・インターフェース・バス１４５１および補助プロセッサ・インターフェース１４５２の一方または両方を使用してサポートすることができる。ＣＰＵ１４１０とＴＣＰＵ１４２０との間の通信は、命令例外通知、割込みアクセス、およびＤＭＡ調停など、ならびにそのさまざまな組合せに関連する通信を含むことができる。ＣＰＵ１４１０およびＴＣＰＵ１４２０とテスト・コプロセッサ・アーキテクチャ１４００の他のコンポーネントとの間の通信は、メモリからの読取り、メモリへの書込み、および／またはテストされるシステムをテストするのを支援して実行できる任意の他のタスクに関連する通信を含むことができる。
【０２５１】
図１５に、テスト付属プロセッサ・アーキテクチャの例示的実施形態を示す。テスト付属プロセッサ・アーキテクチャ１５００は、ＴＩＳＡを使用するシステム・テスティングをサポートするＴＩＳＡプロセッサ・アーキテクチャとしての使用に適する。テスト付属プロセッサ・アーキテクチャ１５００は、ＴＩＳＡを使用しないシステム・テスティングをサポートするテスト・プロセッサ・アーキテクチャとしての使用にも適する。
【０２５２】
テスト付属プロセッサ・アーキテクチャ１５００は、中央処理装置（ＣＰＵ）１５１０およびテスト付属プロセッサ・ユニット（ＴＡＰＵ）１５２０を含む。ＣＰＵ１５１０およびＴＡＰＵ１５２０は、同一基板上に存在することができ、あるいは、異なる基板上に存在することができる。
【０２５３】
ＣＰＵ１５１０は、テストされるシステムのシステム・テスティングを実行するのに適する任意のＣＰＵとすることができる。ＣＰＵ１５１０は、図１３に示し、これに関して説明した主プロセッサ１３１０によってサポートされるテスティング能力をサポートする。
【０２５４】
ＣＰＵ１５１０は、それに関連するメイン・メモリ１５３０Ｍ、フラッシュ・メモリ１５３０Ｆ、および入出力モジュール１５４０を有する。ＣＰＵ１５１０は、それに関連するメイン・プロセッサ・インターフェース・バス１５５０を有する。ＣＰＵ１５１０、メイン・メモリ１５３０Ｍ、フラッシュ・メモリ１５３０Ｆ、および入出力モジュール１５４０は、それぞれ、メイン・プロセッサ・インターフェース・バス１５５０に結合される（または、他の形でこれと通信できるように構成されている）。
【０２５５】
一実施形態では、ＣＰＵ１５１０は、たとえばＣＰＵ１５１０の性能を改善するために、キャッシュ１５１１を含む。
【０２５６】
ＴＡＰＵ１５２０は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のＣＰＵとすることができる。ＴＡＰＵ１５２０は、入出力モジュール１５２１を含む。ＴＡＰＵ１５２０は、テスト・アクセス・ポート（ＴＡＰ）インターフェース１５９０をサポートし、ＴＡＰインターフェース１５９０は、任意の適切なＴＡＰ（たとえば、ＩＥＥＥ１１４９．１のＴＡＰまたはテストされるシステムをテストするのに使用される任意の他の適切なＴＡＰなど）とインターフェースすることができる。ＴＡＰＵ１５２０は、図１３に示し、これに関して説明した副プロセッサ１３２０によってサポートされるテスティング能力をサポートする。
【０２５７】
ＴＡＰＵ１５２０は、それに関連するローカル・テスト・メモリ１５６０を有する。ＴＡＰＵ１５２０は、それに関連する内部インターフェース・バス１５７０を有する。ＴＡＰＵ１５２０およびローカル・テスト・メモリ１５６０は、それぞれ、内部インターフェース・バス１５７０に結合される（または、他の形でこれと通信できるように構成されている）。
【０２５８】
ＣＰＵ１５１０に関連する入出力モジュール１５４０およびＴＡＰＵ１５２０の入出力モジュール１５２１は、ＣＰＵ１５１０とＴＡＰＵ１５２０との間の通信を使用可能にする通信インターフェース１５８０をサポートする。通信インターフェース１５８０は、ＣＰＵ１５１０からＴＡＰＵ１５２０へのＴＡＰ関連コマンドのストリーミングをサポートする。
【０２５９】
一実施形態では、ＣＰＵ１５１０に関連する入出力モジュール１５４０およびＴＡＰＵ１５２０の入出力モジュール１５２１は、は、シリアライザ−デシリアライザ（ＳＥＲＤＥＳ）通信能力をサポートし、したがって、通信インターフェース１５８０は、ＳＥＲＤＥＳベースの通信インターフェースである。この実施形態では、ＳＥＲＤＥＳベースの通信インターフェース１５８０を、任意の適切なＳＥＲＤＥＳ通信プロトコル（たとえば、ギガビット・イーサネット（ＧｉｇＥ）、Ｓｅｒｉａｌ  Ｒａｐｉｄ  ＩＯ（ＳＲＩＯ）、およびＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ（ＰＣＩｅ）など）を使用して実施することができる。主にＣＰＵ１５１０とＴＡＰＵ１５２０との間のＳＥＲＤＥＳベースの通信の使用に関して図示され、本明細書で説明されるが、他の適切な通信能力を、ＣＰＵ１５１０とＴＡＰＵ１５２０との間の通信をサポートするために使用することができる。
【０２６０】
ＣＰＵ１５１０およびＴＡＰＵ１５２０は、図１３に示し、これに関して説明した主プロセッサ１３１０および副プロセッサ１３２０に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。ＣＰＵ１５１０およびＴＡＰＵ１５２０は、ＴＡＰＵ１５２０がテスティング中にテストされるシステムのＴＡＰを制御するＴＡＰ関連命令を実行する間にＣＰＵ１５１０がテスト命令を処理するために動作を継続することを可能にするために、通信インターフェース１５８０を介するコマンド・ストリーミングを利用する。
【０２６１】
ＣＰＵ１５１０は、テストされるシステムをテストするテスト命令を実行する。ＣＰＵ１５１０は、それらのテスト命令の実行中に、テストされるシステムのＴＡＰの制御に関係する命令を検出する。ＣＰＵ１５１０は、それらのＴＡＰ関連命令をＴＡＰＵ１５２０に通信インターフェース１５８０を介して（すなわち、通信インターフェース１５８０を介する伝搬のために、ＣＰＵ１５１０からメイン・プロセッサ・インターフェース・バス１５５０を介して入出力モジュール１５４０に）伝搬させる。ＴＡＰＵ１５２０は、ＣＰＵ１５１０からＴＡＰ関連命令を受け取り、ＣＰＵ１５１０が他のタスク（たとえば、他のテスティング命令の実行）を実行するために動作し続ける間にＴＡＰＵ１５２０がＴＡＰの制御を処理できるように、それらのＴＡＰ関連命令を処理する。言い換えると、ＣＰＵ１５１０およびＴＡＰＵ１５２０は、ＴＡＰＵ１５２０がＣＰＵ１５１０によって検出されたＴＡＰ関連命令を処理する間にＣＰＵ１５１０がコンテキストを切り替え、他のタスクを実行するために動作し続けられるように、システム・テスティング中に協力し、これによってシステム・テスティング効率を改善する。
【０２６２】
一実施形態では、ＣＰＵ１５１０によって検出され、ＴＡＰＵ１５２０によって処理されるＴＡＰ関連命令は、ＴＡＰＵ１５２０への伝搬のためにＣＰＵ１５１０によってパケット化される。
【０２６３】
一実施形態では、ＣＰＵ１５１０によって検出され、ＴＡＰＵ１５２０によって処理されるＴＡＰ関連命令は、ＴＡＰＵ１５２０によってサポートされるオペコードを含む。１つのそのような実施形態では、ＴＡＰ関連命令は、ＣＰＵ１５１０に関連するメモリとＴＡＰＵ１５２０に関連するメモリとの間（たとえば、メイン・メモリ１５３０Ｍとローカル・テスト・メモリ１５６０との間）でブロック・メモリ・コピーを実行する際の使用に適合された１つまたは複数の拡張コマンドを含むこともできる。
【０２６４】
ＣＰＵ１５１０は、テスト命令の実行、ＴＡＰ関連命令の検出、およびＴＡＰ関連命令のパケット化など、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ１５３０Ｍおよび／またはフラッシュ・メモリ１５３０Ｆを利用する。メイン・メモリ１５３０Ｍは、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ１５３０Ｆは、任意の適切なフラッシュ・メモリまたは任意の他の適切な持続性メモリとすることができる。
【０２６５】
ＴＡＰＵ１５２０は、ＣＰＵ１５１０から受け取ったＴＡＰ関連命令の格納、およびＣＰＵ１５１０から受け取ったＴＡＰ関連命令の処理、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにローカル・テスト・メモリ１５６０を利用する。ローカル・テスト・メモリ１５６０は、任意の適切なプロセッサ・メモリとすることができる。一実施形態では、ローカル・テスト・メモリ１５６０が、スキャン・チェーン全体（オンチップ・メモリ内で要求される場合があるように）ではなく、テストされるシステムのスキャン・チェーンのスキャン・チェーン・セグメントの処理を扱うので、ローカル・テスト・メモリ１５６０を比較的小さくすることができる。
【０２６６】
主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、ＣＰＵ１５１０およびＴＡＰＵ１５２０によって実行される機能をサポートするために使用できることを了解されたい。
【０２６７】
主にＴＩＳＡを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、ＴＩＳＡを、任意の適切なプロセッサ・アーキテクチャを使用して実施でき、このプロセッサ・アーキテクチャが、コプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャ以外のプロセッサ・アーキテクチャを含むことができることを了解されたい。したがって、ＴＩＳＡプロセッサ・アーキテクチャを、さまざまな他の形で複数のプロセッサを使用して実施することができ、これらの形のうちの少なくともいくつかは、ＴＩＳＡをサポートするための３つ以上のプロセッサの使用を含むことができる。
【０２６８】
主にＴＩＳＡアーキテクチャを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、コプロセッサ・アーキテクチャおよび付属プロセッサ・アーキテクチャを、それぞれ、他のタイプのテスティング・アーキテクチャ（すなわち、ＴＩＳＡを使用しない他のテスティング・アーキテクチャ）を実施するのに使用できることを了解するであろう。
【０２６９】
テスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャが、それぞれＴＩＳＡを２つの通信するプロセッサによって実行することを可能にするという点で機能的に似ていることを了解されたい。所与のアプリケーションで、この２つのアーキテクチャの間の選択は、使用可能なリソース、コスト、性能、物理的制約（同一チップ内の集積、異なるチップおよび／または基板内、あるいはその任意の組合せ）、ならびに任意の他の実装形態パラメータなど、実装形態依存パラメータを基礎として設計者が行うことができる。主にテスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャに関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、これらの実装形態考慮事項が、すべての他のタイプのテスティング・アーキテクチャ／インフラストラクチャにあてはまることを了解するであろう。
【０２７０】
図示され、本明細書で説明されるＴＩＳＡプロセッサ・アーキテクチャは、システム・テスティングを実行する際に使用されるすべての適切なＴＩＳＡを使用することができる。
【０２７１】
ＴＩＳＡプロセッサ・アーキテクチャと共に使用されるように適合されたＴＩＳＡの１つの例示的実施形態の説明が、これに続く。ＴＩＳＡのこの例示的実施形態は、図示され、本明細書で説明されるスキャン・セグメント・レベル・プリミティブの実装形態である。スキャン・セグメント・レベル抽象化レベルでは、テストされるシステムのスキャン・チェーン全体が、セグメントに分割され、これらのセグメントは、アルゴリズムのデータ・アトムとして使用される。テストされるシステムを、アルゴリズム開発者（人間および／または自動化ツールとすることができる）によってスキャン・セグメントに区分できることを了解されたい。スキャン動作をスキャン・セグメント・レベルで実行することを可能にするためのＴＩＳＡの使用のより概括的な説明すなわち、この例示的なＴＩＳＡ実装形態とは独立な説明を、下で詳細に提供する。
【０２７２】
ＴＩＳＡの次の実施形態は、これらのスキャン・セグメントを定義し、処理することのできるレジスタおよび命令のセットを処理する。次の実施形態は、３２ビット・サイズのＴＩＳＡに基づくが、これを任意の他の語サイズ（たとえば、１６ビット、６４ビット、または任意の他の適切な語サイズ）に適合させることができる。
【０２７３】
図１６に、ＴＩＳＡプロセッサによって使用され得る例示的なレジスタ・セットを示す。例示的なＴＩＳＡは、それぞれ図１６Ａ〜図１６Ｄに示された、４つのレジスタ・セット（レジスタ・セットＲ１からＲ４と表される）を含む。
【０２７４】
図１６Ａに示されているように、第１レジスタ・セットＲ１は、次のユーザ・アクセス可能データ・レジスタを含む。
・  ＳｔａｔｕｓＲｅｇｉｓｔｅｒ：状況状態情報を含む３２ビット・レジスタ、
・  ＣｏｎｔｒｏｌＲｅｇｉｓｔｅｒ：コマンド・エンコーディングを含む３２ビット・レジスタ、
・  ＢｌｏｃｋＲｅｇｉｓｔｅｒ：スキャン・データ・イン（ギャザ・データ）およびデータ・アウト（スキャッタ・データ）を書き込むべき場所を間接的にポイントする事前にフォーマットされたデータ構造へのメモリ内のオフセットを含む３２ビット・レジスタ［スキャッタ／ギャザ・セグメント記述にアクセスするすべてのスキャン動作および比較動作に使用される］、
・  ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ：スキャンされるべきままである現在のビット数が常駐する３２ビット・レジスタ（ブロック・モード・オペコードのスキャッタ／ギャザ・セグメント記述から自動的に取り込まれもする）、
・  ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ：スキャン動作のｓｔａｒｔＳｔａｔｅ、ｓｃａｎＳｔａｔｅ、およびｅｎｄＳｔａｔｅを表す４ビットの３つのバンクを含む３２ビット・レジスタ（４ビットは、ＴＡＰ状態機械の１６個の状態のエンコーディングを表す（ブロック・モードでスキャッタ／ギャザ・セグメント記述から取り込まれもする））、ならびに
・  ＵｓｅｒＤａｔａＲｅｇｉｓｔｅｒｓ［１〜１１］：小さいスキャン動作およびデータ再利用のためのスキャン・セグメント・データを含む３２ビット・レジスタ（ソース・レジスタまたは宛先レジスタになることができる）。
【０２７５】
図１６Ｂに示されているように、第２レジスタ・セットＲ２は、次の内部スクラッチ・レジスタを含む。
・  ＢｌｏｃｋＰｏｉｎｔｅｒＲｅｇｉｓｔｅｒ  Ｍｕｌｔｉｐｌｅ：Ｓｃａｎ命令中に処理される現在のスキャッタ／ギャザ・セグメント記述参照をポイントする３２ビット・レジスタ、
・  ＢｌｏｃｋＣｏｕｎｔＲｅｇｉｓｔｅｒ  Ｍｕｌｔｉｐｌｅ：Ｓｃａｎ命令中に処理されるスキャッタ／ギャザ・セグメント記述のカウントを含む３２ビット・レジスタ、および
・  ＩｎｓｔｒｕｃｔｉｏｎＲｅｇｉｓｔｅｒ：現在のオペコードがデコーディングのために置かれる３２ビット・レジスタ。
【０２７６】
図１６Ｃに示されているように、第３レジスタ・セットＲ３は、次のスキャッタ／ギャザ・セグメント記述レジスタを含む。
・  ＢｌｏｃｋＯｆｆｓｅｔＦｉｅｌｄ：６４ビット・アーキテクチャが使用される時のアドレスのバンクを記述する３２ビット数、
・  ＳｃａｎＬｅｎｇｔｈＦｉｅｌｄ：このセグメントについてスキャンすべきビット数を指定する３２ビット整数、
・  ＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄ：それぞれこのスキャン動作の開始状態、スキャン状態、および終了状態を表す４ビットの３つのフィールド（各４ビットは、１６状態ＴＡＰ状態機械状態を表す）、
・  ＳｏｕｒｃｅＬｏｃａｔｉｏｎＦｉｅｌｄ：ＴＤＩデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス、
・  ＤｅｓｔｉｎａｔｉｏｎＬｏｃａｔｉｏｎＦｉｅｌｄ：ＴＤＯデータがメモリ内で格納される場所に関する３２ビット・ベース・アドレス、
・  ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄ：期待されるベクトルがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス、
・  ＲｅｓｐｏｎｓｅＬｏｃａｔｉｏｎＦｉｅｌｄ：キャプチャされたＴＤＩデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス、
・  ＭａｓｋＦｉｅｌｄ：比較動作を制限するのに使用されるＭＡＳＫデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス、ならびに
・  ＲｅｓｕｌｔＬｏｃａｔｉｏｎＦｉｅｌｄ：：比較の結果がメモリ内で格納される場所に関する３２ビット・ベース・アドレス。
【０２７７】
図１６Ｄに示されているように、第４レジスタ・セットＲ４は、次のマルチブロック・スキャッタ／ギャザ・セグメント記述レジスタを含む。
・  ＢｌｏｃｋＯｆｆｓｅｔＦｉｅｌｄ：６４ビット・アーキテクチャが使用される時のアドレスのバンクを記述する３２ビット数、
・  ＢｌｏｃｋＣｏｕｎｔＦｉｅｌｄ：このＭｕｌｔｉＢｌｏｃｋスキャンによって表されるスキャン・セグメントの個数を定義する３２ビット数（ＭｕｌｔｉＢｌｏｃｋスキャン動作中にＢｌｏｃｋＣｏｕｎｔＲｅｇｉｓｔｅｒを初期化するのに使用される）、
・  ＳｃａｔｔｅｒＧａｔｈｅｒＯｐｃｏｄｅＦｉｅｌｄ：関連するＳｃａｔｔｅｒＧａｔｈｅｒＢｌｏｃｋＦｉｅｌｄによってポイントされるスキャッタ／ギャザ・セグメント記述に使用される３２ビット・コマンド・オペコード、および
・  ＳｃａｔｔｅｒＧａｔｈｅｒＢｌｏｃｋＦｉｅｌｄ：前のｅｒＧａｔｈｅｒＯｐｃｏｄｅＦｉｅｌｄに関連するスキャッタ／ギャザ・セグメント記述がメモリ内で配置される場所に関する３２ビット・アドレス。
【０２７８】
例示的なＴＩＳＡレジスタ・セットを、任意の適切な形で変更できることを了解されたい。たとえば、例示的なレジスタ・セットのそれぞれを、より少数の、より多数の、および／または異なるレジスタを含むように変更することができる。たとえば、例示的なレジスタを、より少数の、より多数の、および／または異なるセットに再グループ化することができる。たとえば、より少数の、より多数の、および／または異なるレジスタ・セットを使用することができる。言い換えると、例示的なＴＩＳＡレジスタ・セットを、ＴＩＳＡプロセッサ・アーキテクチャを実施するためにＴＩＳＡ命令セットと共に使用するのに適する任意の他のＴＩＳＡレジスタ・セット（１つまたは複数）に置換することができる。
【０２７９】
例示的なＴＩＳＡは、システム・テスティングを実行する際に使用される任意の適切なＴＩＳＡ命令セット（すなわち、コマンド辞書）を使用することができる。
【０２８０】
例示的なＴＩＳＡ命令セットは、次のオペコードを含み、これらのオペコードは、図１６Ａ〜図１６Ｄに関して図示され、説明されたレジスタ・セットＲ１からＲ４ならびに図示され、本明細書で説明されるオリジナルＩＳＡレジスタ・セットを操作するのに利用することができる。
【０２８１】
ＳｔａｔｅＴｒａｎｓｉｔｉｏｎ  ＜ＴＭＳ  Ｖａｌｕｅ＞，＜ＴＣＫ  ｃｙｃｌｅｓ＞
・  このオペコードは、所与の個数のＴＣＫクロック・サイクルの間にＴＭＳの値を使用してＴＡＰ状態機械をトラバースするのに使用される。このオペコードは、ＴＡＰ状態機械の状態の間で全般的な状態遷移を実行するのに使用される。＜ＴＭＳ  Ｖａｌｕｅ＞は、単一ビットを表し、＜ＴＣＫ  ｃｙｃｌｅｓ＞は、オペコードの残りのデータ・ビットを表す。
【０２８２】
ＲｕｎＴｅｓｔ  ＜ｓｔａｒｔＳｔａｔｅ＞，＜ｔｅｓｔＳｔａｔｅ＞，＜ｅｎｄＳｔａｔｅ＞
・  このオペコードは、＜ｓｔａｒｔＳｔａｔｅ＞から＜ｔｅｓｔＳｔａｔｅ＞に遷移し、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒによって指定される個数のＴＣＫサイクルの間に＜ｔｅｓｔＳｔａｔｅ＞でループするのに使用される。このオペコードは、ルーピングの結末として＜ｅｎｄＳｔａｔｅ＞に遷移するのに使用される。
【０２８３】
ＳｃａｎＲｅｇｉｓｔｅｒ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ  ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ  ｒｅｇｉｓｔｅｒ＞］
・  このオペコードは、ユーザ・データ・レジスタ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞内のデータをスキャンし、キャプチャされた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞が存在する場合には、存在するならば最終的に＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞を使用して、キャプチャされた値を＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞と比較し、それに従ってエラーを送出する。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。
【０２８４】
ＳｃａｎＲｅｇｉｓｔｅｒＺｅｒｏ  ＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ  ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ  ｒｅｇｉｓｔｅｒ＞］
・  このオペコードは、すべて「０」のベクトル値をスキャンし、キャプチャされた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞および＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞は、ＳｃａｎＲｅｇｉｓｔｅｒ命令と同様に使用される。
【０２８５】
ＳｃａｎＲｅｇｉｓｔｅｒＯｎｅ  ＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ  ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ  ｒｅｇｉｓｔｅｒ＞］
・  このオペコードは、すべて「１」のベクトルをスキャンし、キャプチャされた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞および＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞は、ＳｃａｎＲｅｇｉｓｔｅｒ命令と同様に使用される。
【０２８６】
ＳｃａｎＢｌｏｃｋ
・  このオペコードは、ＳＵＴに対してＢｌｏｃｋＲｅｇｉｓｔｅｒによってポイントされるデータをスキャンし、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定する。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＴＤＯからのデータは、保存されない。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
【０２８７】
ＳｃａｎＢｌｏｃｋＣａｐｔｕｒｅ
・  このオペコードは、ＳＵＴに対してＢｌｏｃｋＲｅｇｉｓｔｅｒによってポイントされるデータをスキャンし、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定する。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＴＤＯからキャプチャされたデータは、保存される。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
【０２８８】
ＳｃａｎＢｌｏｃｋＺｅｒｏＣａｐｔｕｒｅ
・  このオペコードは、ＳＵＴに対してすべて「０」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、ＢｌｏｃｋＲｅｇｉｓｔｅｒによって定義されるレジスタに結果をキャプチャする。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
【０２８９】
ＳｃａｎＢｌｏｃｋＺｅｒｏ
・  このオペコードは、ＳＵＴに対してすべて「０」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、結果はキャプチャされない。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
【０２９０】
ＳｃａｎＢｌｏｃｋＯｎｅＣａｐｔｕｒｅ
・  このオペコードは、ＳＵＴに対してすべて「１」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、ＢｌｏｃｋＲｅｇｉｓｔｅｒによって定義されるレジスタに結果をキャプチャする。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
【０２９１】
ＳｃａｎＢｌｏｃｋＯｎｅ
・  このオペコードは、ＳＵＴに対してすべて「１」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、結果はキャプチャされない。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
【０２９２】
例示的なＴＩＳＡ命令セットは、明示的な値を使用する次のレジスタ変更命令を含む。
【０２９３】
ＬｏａｄＲｅｇｉｓｔｅｒＥｘｐｌｉｃｉｔ  ＜ｃｏｎｓｔ  ｖａｌｕｅ＞，＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞
・  この命令は、＜ｃｏｎｓｔ  ｖａｌｕｅ＞の定数値を、＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞によって名前を指定されたレジスタにロードする。
【０２９４】
ＣｏｐｙＲｅｇｉｓｔｅｒ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞
・  この命令は、＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞として名前を指定されたレジスタの内容を＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞によって名前を指定されたレジスタにコピーする。
【０２９５】
例示的なＴＩＳＡ命令セットは、暗黙の値を使用する次のレジスタ変更命令含む。
【０２９６】
ＬｏａｄＲｅｇｉｓｔｅｒＩｍｐｌｉｃｉｔ  ＜ｕｓｅｒ  ｄａｔａ  ｒｅｇｉｓｔｅｒ＞，＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞
・  この命令は、名前を指定された＜ｕｓｅｒ  ｄａｔａ  ｒｅｇｉｓｔｅｒ＞内の値を、実際のデータが存在するメモリ位置へのポインタ参照として使用し、参照された値を＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞によって名前を指定されたレジスタに格納する。
【０２９７】
例示的なＴＩＳＡ命令セットは、次のレジスタ保存命令を含む。
【０２９８】
ＳｔｏｒｅＲｅｇｉｓｔｅｒＩｍｐｌｉｃｉｔ  ＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞，＜ｕｓｅｒ  ｄａｔａ  ｒｅｇｉｓｔｅｒ＞
・  この命令は、名前を指定された＜ｕｓｅｒ  ｄａｔａ  ｒｅｇｉｓｔｅｒ＞内の値を、＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞によって名前を指定されたレジスタ内の値が格納されるメモリ位置へのポインタ参照として使用する。
【０２９９】
ＳｔｏｒｅＲｅｇｉｓｔｅｒＥｘｐｌｉｃｉｔ  ＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞，＜ｃｏｎｓｔ  ｖａｌｕｅ＞
・  この命令は、＜ｒｅｇｉｓｔｅｒ  ｎａｍｅ＞によって名前を指定されたレジスタの値を、＜ｃｏｎｓｔ  ｖａｌｕｅ＞によって指定されるメモリ位置に格納する。
【０３００】
例示的なＴＩＳＡ命令セットは、次の、レジスタに対する論理演算を含む。
【０３０１】
ＡＮＤ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞
・  この演算は、＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞との間の論理ＡＮＤ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に置く。
【０３０２】
ＯＲ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞
・  この演算は、＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞との間の論理ＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に置く。
【０３０３】
ＸＯＲ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞
・  この演算は、＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞との間の論理ＸＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に置く。
【０３０４】
ＮＯＴ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞
・  この演算は、＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞に対して論理ＮＯＴ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に置く。
【０３０５】
ＸＯＲＭ  ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞，＜ｍａｓｋ  ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞
・  この演算は、「１」の値を含むユーザ・データ・レジスタ＜ｍａｓｋ  ｒｅｇｉｓｔｅｒ＞ビットと位置が合っているビットだけを比較しながらユーザ・データ・レジスタ＜ｓｏｕｒｃｅ  ｒｅｇｉｓｔｅｒ＞とユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞との間の論理ＸＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞に置く。比較されないビットは、＜ｄｅｓｔｉｎａｔｉｏｎ  ｒｅｇｉｓｔｅｒ＞内で「０」の値をもたらすことに留意されたい。
【０３０６】
例示的なＴＩＳＡ命令セットは、次の、レジスタに対するその他の動作を含む。
【０３０７】
ＮＯＰ
・  いくつかのＩＳＡ命令セットでアライメントを実現するためのフィルタとして使用されるノー・オペレーション・オペコード。
【０３０８】
例示的なＴＩＳＡ命令セットは、付属プロセッサ・アーキテクチャを使用する実施形態のためにストリーミングのサポートを拡張する次の命令を含む。
【０３０９】
ＭｅｍｏｒｙＷｒｉｔｅ
・  この命令は、引数＜ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（シーケンス番号）＞、＜ｂｌｏｃｋ  ｏｆｆｓｅｔ（ブロック・オフセット）（３２ビット・オフセット）＞、＜ｎｕｍｂｅｒ  ｏｆ  ｂｙｔｅｓ  ｔｏ  ｔｒａｎｓｆｅｒ（転送すべきバイト数）＞、＜ｄｅｓｔｉｎａｔｉｏｎ  ａｄｄｒｅｓｓ（宛先アドレス）（指定されたメモリ・ブロック内の）＞、＜ｄａｔａ  ｂｙｔｅ（データ・バイト）（１つまたは複数）＞を使用して、ローカル・テスト・メモリに書き込む。
【０３１０】
ＭｅｍｏｒｙＲｅａｄ
・  この命令は、引数＜ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ（シーケンス番号）＞、＜ｂｌｏｃｋ  ｏｆｆｓｅｔ（ブロック・オフセット）（３２ビット・オフセット）＞、＜ｎｕｍｂｅｒ  ｏｆ  ｂｙｔｅｓ  ｔｏ  ｔｒａｎｓｆｅｒ（転送すべきバイト数）＞、＜ｓｏｕｒｃｅ  ａｄｄｒｅｓｓ（ソース・アドレス）（指定されたメモリ・ブロック内の）＞を使用して、ローカル・テスト・メモリから読み取る。この命令は、シーケンス番号および転送されるバイト数を用いてタグ付けされたデータ・バイトのストリームを返す。
【０３１１】
例示的なＴＩＳＡ命令セットは、スキャン状態に関する次の値を含む。
【０３１２】
ＳｔａｒｔＳｔａｔｅ、ＳｃａｎＳｔａｔｅ、ＥｎｄＳｔａｔｅ
・  スキャン状態コードは、ＴｅｓｔＬｏｇｉｃＲｅｓｅｔ（ＴＬＲ）、ＲｕｎＴｅｓｔ／Ｉｄｌｅ（ＲＴＩ）、ＰａｕｓｅＤＲ（ＰＤＲ）、ＰａｕｓｅＩＲ（ＰＩＲ）、ＳｃａｎＤＲ（ＳＤＲ）、ＳｃａｎＩＲ（ＳＩＲ）を含む。これらは、状態コードあたり４ビットの表現であり、１２ビットが、スキャン動作に関する状態遷移シーケンス全体を記述するのに使用される。
【０３１３】
本明細書の教示によって情報を与えられた当業者は、さまざまな他のＴＩＳＡ実装形態を、図示され本明細書で説明されるＴＩＳＡプロセッサ・アーキテクチャと共に使用できることを了解するであろう。たとえば、他のＴＩＳＡ実装形態は、より少数の、より多数の、および／または異なるレジスタを使用することができ、かつより少数の、より多数の、および／または異なる命令セットを使用することができるなど、ならびにそのさまざまな組合せを使用することができる。一実施形態では、異なるプロセッサ・アーキテクチャが使用される場合に、特定の適用例によりよく適するＴＩＳＡ実装形態を提供するためおよび／または任意の他の適切な理由のために、他のＴＩＳＡ実装形態を利用することができる。
【０３１４】
上で説明したように、ＪＴＡＧアーキテクチャでのＴＩＳＡの使用は、スキャン動作をスキャン・セグメント・レベルで実行することを可能にし、これは、スキャン・パス全体の内部での独立に制御可能な「スキャン・セグメント」の定義を可能にし、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。
【０３１５】
概して、ＪＴＡＧ動作は、すべてのビットが１つずつ直列にスキャン・インされると同時に、ビットが１つずつ直列にスキャン・アウトされるスキャン動作に基づく。これは、スキャン動作を実行できるために、スキャン・チェーン内のビットごとにどの値が必要とされるか（すなわち、入力ベクトルおよび出力ベクトル）の知識が要求されることを意味する。ＴＧＴは、通常、ＢＳＤＬなどの記述言語を介して入手されるシステム・モデルから必要なベクトルを計算することによって、伝統的な構造テスティングのためにこの能力を提供する。さらに、ＳＶＦおよびＳＴＡＰＬのようなフォーマットが、これを反映するのは、これらが、ユーザがこれらのベクトルを操作することを可能にするからである。この形でのテスティングは、テスティングの構造的な（および他のタイプの）には十分であるが、この形でのテスティングは、スキャン・チェーン全体にアクセスする実際の必要がない対話セットアップには非常に非効率的である。この非効率性は、例を検討することによって理解することができる。
【０３１６】
たとえば、それぞれが１６ビットを有する１００個の機器からなるスキャン・チェーンを検討されたい。ユーザが、スキャン・チェーン内の７６番目の機器のレジスタに０ｘ１２３４を書き込む必要がある場合には、ＴＧＴは、スキャン・チェーン全体のベクトル（１００＊１６＝１６００ビット）を生成し、スキャン・チェーンに入力するためにこれをＴＡＰインターフェースに送る必要がある。同様に、ユーザが、関連する出力を読み取ることを望む場合には、ＴＧＴは、所望の出力情報を抽出できるようになる前に、１６００ビットのベクトル全体を受け取る必要がある。この例では、スキャン効率が、目標の１つではないので（そうではなく、この例では、目標は、主にスキャン・チェーンの一特定のエンティティに効率的にアクセスできることである）、スキャン・ビットの大多数が役に立たないという事実は重要ではない。
【０３１７】
このタイプの手法は、少なくとも次の理由から問題である。（ａ）長いベクトルを扱うという計算的な必要がある（たとえば、大量のメモリ転送は、性能に対する大きい影響を有する）、（ｂ）ベクトル（１つまたは複数）全体をメモリに格納する必要がある（長いチェーンについて問題になる可能性がある）、（ｃ）メモリ・ストレージが、データ入力およびデータ出力に制限されるのではなく、期待されるデータ、入力マスク、および出力マスク、などをも含む（これによって、入力データおよび出力データだけから既に潜在的に過大な負担を受けているメモリ要件を増やす）、および（ｄ）機器−ベクトル−機器の変換を、毎回行わなければならない（これは、計算能力および時間を必要とする）。
【０３１８】
スキャン・セグメント・レベル抽象化レベルは、スキャン効率に対する特別な強調を全く用いずに（もちろん、必要な場合にそれを使用可能にする場合であっても）テストされるシステムのスキャン・チェーンの個々のエンティティまたはエンティティのグループへの効率的なアクセスを提供する強力なツールである。
【０３１９】
一実施形態では、スキャン・セグメント・レベル抽象化は、スキャン・チェーンを一連のセグメントに分解することと、セグメントのそれぞれに対する１つまたは複数のスキャン動作を定義することとによって実施される。スキャン・チェーンは、複数の要素からなり、各セグメントは、スキャン・チェーンの要素のうちの少なくとも１つを含む。要素を、テストされるシステムの多数のレベルで定義することができ（たとえば、要素を、デバイス、機器、レジスタ、およびレジスタのセグメントなど、ならびにそのさまざまな組合せとすることができる）、したがって、スキャン・チェーンがそれに分解されるセグメントを、テストされるシステムの多数のレベルで定義することができる（たとえば、セグメントを、１つまたは複数のデバイス、デバイス（１つまたは複数）の一部、１つまたは複数の機器、機器（１つまたは複数）の一部、１つまたは複数のレジスタ、レジスタ（１つまたは複数）の一部、および１つまたは複数のレジスタ・セグメントなど、ならびにそのさまざまな組合せとすることができる）。この形で、セグメントは、スキャン・チェーンの最小の制御単位を表すことができる。
【０３２０】
一実施形態では、セグメントへのスキャン・チェーンの分解を、階層的とすることができる。たとえば、スキャン・チェーンをセグメントに分解することができ、そのセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、そのサブセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、以下同様である。この形で、スキャン・チェーンの階層分解を、あるセグメントを他のセグメントから構成できる木の構造を有するとみなすことができる。１つのそのような実施形態では、木の葉のセグメントを、セグメントと呼ぶことができ（それらがスキャン・チェーンの最小の制御単位を表すという点で）、木の葉の上に位置するセグメントを、スーパーセグメントと呼ぶことができる。一実施形態では、スキャン・チェーンのセグメントのうちの１つまたは複数を、ユーザ／システムに透過的である形でのみ制御可能である仮想サブセグメントから構成することができることを了解されたい）。スキャン・チェーンの階層分解を、任意の他の適切な形で定義することができる。
【０３２１】
セグメント化の使用は、セグメントのタイプおよび／またはセグメント組合せのタイプに関するエンティティの定義を可能にする。エンティティは、あるタイプのターゲットの包括的記述であり、この記述は、そのタイプのターゲットの各物理インスタンスについて有効であり、そのタイプのターゲットの物理インスタンスごとに再利用することができる。たとえば、あるエンティティが、デバイス、デバイスのグループ、デバイスの一部、機器、機器のグループ、および機器の一部など、ならびにそのさまざまな組合せの記述を定義することができる。したがって、スキャン・チェーンを、スキャン・チェーンのセグメントが特定の要素または要素の組合せを含むように分解することができるので、エンティティを、スキャン・チェーンのそれぞれのセグメントおよび／またはセグメントのそれぞれの組合せについて定義することができる。たとえば、スキャン・チェーンが、１つのセグメントが１つの機器を含むように分解される場合には、エンティティを、そのタイプのセグメント（すなわち、そのタイプの機器を含む各セグメント）について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。同様に、たとえば、スキャン・チェーンが、１つのセグメントが複数の機器を含むように分解される場合には、エンティティを、そのタイプのセグメント（すなわち、そのタイプ組合せの機器を含む各セグメント）について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。これは、下で説明するように、追加の特徴および機能をサポートすることを可能にする。
【０３２２】
セグメント化の使用は、エンティティ（すなわち、制御下のあるタイプのセグメントの記述）を、そのエンティティと通信するのに使用される物理プロトコルと相関させることを可能にする。その結果、記述言語（たとえば、ＮＳＤＬ、およびＰ１６８７  ＩＪＴＡＧ  ＰＤＬなど）を、特にそのエンティティのために記述することができ、接続性記述部分（たとえば、ＮＳＤＬまたはＩＪＴＡＧ  ＨＤＬの構造）は、セグメント化命令の順序付けを記述する。
【０３２３】
ＴＩＳＡは、ＴＩＳＡ命令がモデルベースの動作ではなくセグメントベースの動作なので、特定のエンティティ・タイプのすべてのオカレンスについて１回定義できる再利用可能なモジュラ性を提供する。したがって、ＴＩＳＡは、モジュラと特定のセグメント内のテストされるエンティティについて自律的との両方であるので、ＴＩＳＡは、既存アーキテクチャに対する大きい利益を提供する。
【０３２４】
ＴＩＳＡは、既存のツールが必要とするように接続性全体を静的モデルとして前もって定義する必要なしに、必要な任意の順序でスキャン・プロセス内の任意の点で実行フローに組み入れることのできる再利用可能でポーティング可能なモジュールへのテスト・データ・レジスタ定義の直接マッピングを可能にする。ＴＩＳＡは、統一された制御フローおよび標準的なコンピュータ・サイエンス技法に基づく単一解空間アーキテクチャとして、スキャン動作との非スキャンであるポート／信号インターフェースの統合を可能にする（ネイティブ言語構造が非スキャン動作へのアクセスを提供するのに使用される解決策に対する大きい利益を提供する）。
【０３２５】
ＴＩＳＡは、同一エンティティの複数のインスタンスに関する命令シーケンスの再利用を可能にし、これによって、システム内のコード・ストレージ要件の削減を可能にする。たとえば、管理プログラムによって呼び出される記述言語関数にマッピングされる一般化された関数を記述することができる。この例では、関数のそれぞれは、エンティティを表すネイティブ言語オブジェクトのメソッドであり、システム内で定義されたエンティティごとにこれらのオブジェクトの別々のインスタンスがある場合があるが、これらのインスタンスのそれぞれと通信するのに使用されるコードの単一のコピーがあるものとすることができる。この形で、ネイティブ言語実装形態モデルは、回路の接続性および機能性を指定するのに使用される記述言語を直接に制御する。
【０３２６】
上で与えた例を参照すると、スキャン・セグメント・レベル抽象化の使用は、機器１から７５を含むセグメントＳ１、機器７６を含むセグメントＳ２、および機器７７から１００を含むセグメントＳ３という３つのセグメントの定義を可能にする。この形で、機器７６へのアクセスが、大幅に単純化される。たとえば、機器７６へのアクセスを、セグメントＳ３の「ダミー・シフト」を行うこと（たとえば、ＳｃａｎＢｌｏｃｋＺｅｒｏ）と、セグメントＳ２（すなわち、機器７６）について命令（１つまたは複数）を実行することと、セグメントＳ１について別のダミー・シフトを行うことと、その後、更新を伴って終了することとによって得ることができる。そのようなシーケンスでは、セグメントＳ２（すなわち、スキャン・チェーン内の特定の機器）へのアクセスは、その長さを除いてセグメントＳ１またはセグメントＳ３の知識を全く必要とせずに実現される。これが、単に１つの例であり、したがって、１００個の機器の長さのチェーンの別の分解が、他の機器または機器グループへのアクセスを可能にするために可能であることを了解されたい。
【０３２７】
図１７に、テストされるシステムの例示的スキャン・チェーンの例示的分解を示す、テストされるシステムの高水準ブロック図を示す。
【０３２８】
例示的なＳＵＴ１７００は、４つのデバイス１７１０１〜１７１０４（集合的にデバイス１７１０、図７ではそれぞれデバイス１、デバイス２、デバイス３、およびデバイス４と表される）を含む。デバイス１７１０は、スキャン・チェーン１７２０を形成するためにＳＵＴ１７００内で直列に配置される。スキャン・チェーン１７２０は、次のようになっている。ＴＡＰのＴＤＩは、デバイス１７１０４の入力ポートに接続され、デバイス１７１０４の出力ポートは、デバイス１７１０３の入力ポートに接続され、デバイス１７１０３の出力ポートは、デバイス１７１０２の入力ポートに接続され、デバイス１７１０２の出力ポートは、デバイス１７１０１の入力ポートに接続され、デバイス１７１０１の出力ポートは、ＴＡＰのＴＤＯに接続される。
【０３２９】
例示的なＳＵＴ１７００内では、デバイス１７１０のそれぞれが、（１）テスト命令レジスタ（ＴＩＲ）およびテスト・データ・レジスタ（ＴＤＲ）に入力を供給する入力デマルチプレクサ、および（２）ＴＩＲおよびＴＤＲから出力を収集する出力マルチプレクサを含む。各デバイス１７１０のＴＩＲおよびＴＤＲは、並列レジスタである。デバイス１７１０３は、入力デマルチプレクサが入力を１つのＴＩＲおよび２つのＴＤＲに供給し、その１つのＴＩＲおよび２つのＴＤＲから出力を収集するように、１つの追加のＴＤＲを含み、この１つのＴＩＲおよび２つのＴＤＲは、すべてが並列になっている。ＴＩＲおよびＴＤＲは、それぞれ、直列シフト・レジスタとして図示され、それぞれが９個の関連する要素（たとえば、フリップフロップ）を含む。この形で、（ａ）ＴＩＲは、３６個の直列要素を含む１つのスキャン・チェーン（テスト命令スキャン・チェーンと表される）を形成し、（ｂ）ＴＤＲは、合計４５個の要素および３６個の直列要素（すなわち、デバイス１７１０３の２つのＴＤＲは並列なので）を含むもう１つのスキャン・チェーン（テスト・データ・スキャン・チェーンと表される）を形成する。
【０３３０】
例示的なＳＵＴ１７００内では、テスト命令スキャン・チェーンが、デバイス１７１０４のＴＩＲの９個の要素を含む第１セグメントＳＩ４、デバイス１７１０３のＴＩＲの９個の要素を含む第２セグメントＳＩ３、デバイス１７１０２のＴＩＲの９個の要素を含む第３セグメントＳＩ２、およびデバイス１７１０１のＴＩＲの９個の要素を含む第４セグメントＳＩ１という４つのセグメントに分解されている。この形で、テスティング・システムは、ＳＵＴ１７００の他のＴＩＲの最小限の（それらを構成する要素数以外の）知識を用いて、ＳＵＴ１７００のＴＩＲのいずれにも個別にまたは組み合わせてアクセスすることができる。
【０３３１】
例示的なＳＵＴ１７００内では、テスト・データ・スキャン・チェーンは、デバイス１７１０４のＴＤＲの９個の要素を含む第１セグメントＳＤ４、デバイス１７１０３のＴＤＲの９個の要素を含む第２セグメントＳＤ３、デバイス１７１０２の第１ＴＤＲの９個の要素（サブセグメントＳＤ２．１と表される）またはデバイス１７１０２の第２ＴＤＲの９個の要素（サブセグメントＳＤ２．２と表される）を含む第２セグメントＳＤ３（これらは、セグメントの総数を数えるために別々のセグメントとしてカウントされる）、ならびに、デバイス１７１０１のＴＤＲの最初の３つの要素を含む第１サブセグメント（サブセグメントＳＤ１．１と表される）、デバイス１７１０１のＴＤＲの次の４つの要素を含む第２サブセグメント（サブセグメントＳＤ１．２と表される）、およびデバイス１７１０１のＴＤＲの最後の２つの要素を含む第３サブセグメント（サブセグメントＳＤ１．３と表される）という３つの直列サブセグメントにさらに分解される第４セグメントという６つの直列セグメント（合計７つのセグメント）に分解されている。この形で、テスティング・システムは、ＳＵＴ１７００の他のＴＤＲの最小限の（それらを構成する要素数以外の）知識を用いて、ＳＵＴ１７００のＴＤＲのいずれにも（またはデバイス１７１０１のＴＤＲのサブ部分にさえ）個別にまたは組み合わせてアクセスすることができる。
【０３３２】
図１７のＳＵＴ１７００が、テストされるシステムのスキャン・チェーン（１つまたは複数）をスキャン・セグメント・レベル抽象化を提供する際の使用のために分解できる形の単に１つの例であることを了解されたい。要素、およびコンポーネントなどの特定のタイプ、個数、および配置に関して図示され、本明細書で説明されるが、そのスキャン・チェーン（１つまたは複数）が分解されるテストされるシステムが、要素、およびコンポーネントなどのさまざまな他のタイプ、個数、および／または配置を含むことができることを了解されたい。
【０３３３】
本明細書で説明するように、テストされるシステムのスキャン・チェーンの分解は、スキャン動作をセグメントに対して定義することを可能にし、これによってテスティング効率を改善する。分解されたスキャン・チェーンのセグメントに関するスキャン動作を含む命令のセットを生成する、一実施形態による方法を、図１８に関して図示し、本明細書で説明する。
【０３３４】
スキャン分解およびスキャン・セグメント動作の生成のより詳細な説明を、次で提供する。
【０３３５】
概括的な例として、各基板がセグメント（それぞれ第１基板、第２基板、および第３基板に関連してセグメントＡ、Ｂ、およびＣと表す）を含む３つの基板を含むスキャン・チェーンを検討されたい。この例では、スキャン・セグメントが階層的である場合に、第１基板上のセグメントＡを、複数のサブセグメント（たとえば、サブセグメントＡ１からＡｎ）から構成することができ、第２基板上のセグメントＢを、複数のサブセグメント（たとえば、サブセグメントＢ１からＢｎ）から構成することができ、かつ／または第３基板上のセグメントＣを、複数のサブセグメント（たとえば、サブセグメントＣ１からＣｎ）から構成することができる。
【０３３６】
より具体的な例として、アプリケーションおよびＳＵＴに従って、セグメントを、機器の内部の１つまたは複数のレジスタ、機器、レジスタのクラスタ、および１つまたは複数の基板など、ならびにそのさまざまな組合せとすることができる。
【０３３７】
したがって、全体的なスキャン動作は、一連のセグメント・スキャン動作に分解される。その結果、最終的なスキャン・チェーン動作を得るために必要なものは、一連の単純な原子的動作だけである。したがって、スキャン・セグメント・レベル抽象化の実施形態は、これに排他的に限定はされないが、原子的テスト動作がプロセッサ動作のように扱われる実装形態で（たとえば、図示され本明細書で説明されるさまざまなＴＩＳＡ実装形態または原子的テスト動作がプロセッサ動作のように扱われる任意の他の類似する実装形態で）特に有効である。
【０３３８】
スキャン・セグメント・レベル抽象化のそのような実施形態では、スキャン・セグメント・レベル・スキャン動作の実際の実装形態が、ＪＴＡＧにリンクされた１つまたは複数の技術的制約に対処することを必要とする場合がある。たとえば、とりわけＴＡＰマシンの状態を定義する必要およびＰａｕｓｅ−ＤＲ状態（必ず実施されるわけではない）を使用することの危険性などの制約に対処する必要がある場合がある。
【０３３９】
スキャン・チェーン内の機器／セグメントの位置に基づいてスキャン・チェーンを介して受け取られる出力ビットストリーム内の機器／セグメント出力を識別するために、スキャン・インされる最初のセグメントが、スキャン・アウトされる最初のセグメントにもなるように（スキャン・チェーンの終りに最も近いので）、スキャン・チェーンを、先入れ先出し（ＦＩＦＯ）システムとして扱うことができる（その直列の性質を考慮して）。
【０３４０】
ＳＵＴにスキャン・セグメント動作のシーケンスを単一スキャン動作のように「経験」させるために、ＴＣＫを、セグメント動作の間に凍結することができる。スキャン・チェーンの内部のすべての要素が同期式なので、この形でのＴＣＫの凍結の効果は、スキャン・チェーンがＴＣＫと一緒に凍結されることである。
【０３４１】
ＴＩＳＡベースのテスティング・システムでのスキャン・セグメント・レベルの使用は、少数の例によってよりよく理解することができる。次の例では、テストされるシステム（ＳＵＴ）が、３つのセグメント（その順番でＡ、Ｂ、およびＣと表される）からなり、ユーザが、セグメントＢの内部に値Ｖを書き込む必要があると仮定する。
【０３４２】
第１の例として、システムの３つのセグメント（Ａ、Ｂ、およびＣ）が、同一のＪＴＡＧデバイスの内部で実施されると仮定する。この第１の例では、３つのセグメントがメモリ内で定義された後に、ＴＩＳＡ動作は、
ｉ．  Ｓｔａｒｔｓｔａｔｅ＝Ｒｕｎ−Ｔｅｓｔ−Ｉｄｌｅ、Ｓｃａｎｓｔａｔｅ＝Ｅｎｄｓｔａｔｅ＝ＳｈｉｆｔＤＲをセットする
ｉｉ．  ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＡの長さをセットする
ｉｉｉ．  セグメントＡにバイパス・シーケンスをスキャンする
ｉｖ．  Ｓｔａｒｔｓｔａｔｅ＝Ｓｃａｎｓｔａｔｅ＝Ｅｎｄｓｔａｔｅ＝ＳｈｉｆｔＤＲをセットする
ｖ．  ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＢの長さをセットする
ｖｉ．  セグメントＢにＶをスキャンする
ｖｉｉ．  Ｓｔａｒｔｓｔａｔｅ＝Ｓｃａｎｓｔａｔｅ＝ＳｈｉｆｔＤＲ、Ｅｎｄｓｔａｔｅ＝Ｒｕｎ−Ｔｅｓｔ−Ｉｄｌｅをセットする
ｖｉｉｉ．  ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＣの長さをセットする
ｉｘ．  セグメントＣにバイパス・シーケンスをスキャンする
になる。
【０３４３】
第１の例に関して、ＴＡＰ有限状態機械（ＦＳＭ）をＳｈｉｆｔＤＲ状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。これは、第１の例から見ることができ、第１の例では、ＳｈｉｆｔＤｒから出た後にのみＵｐｄａｔｅＤＲ状態に達することを考慮すると、ステップ（ｉ）からステップ（ｉｘ）までＴＡＰ  ＦＳＭをＳｈｉｆｔＤＲ状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。
【０３４４】
さらに第１の例に関して、スキャン・クロックＴＣＫは、スキャン動作中（すなわち、ステップ（ｉｉｉ）、（ｖｉ）、および（ｉｘ））のみアクティブであり、残りの状態では凍結される。その効果は、ＳＵＴが、ＴＣＫと同期する動作に基づくＳＵＴの観点から、ステップ（ｉｉｉ）、（ｖｉ）、および（ｉｘ）を連続ビットストリームとみなすことである。
【０３４５】
さらに第１の例に関して、「バイパス・シーケンス」は、スキャン・セグメントのプロパティであり、たとえば、所与のシーケンス（すべて０、すべて１、または任意の他の適切なシーケンス）または「ドントケア」とすることができ、そのようなシーケンスを判断することは、ＴＧＴに委ねられる。
【０３４６】
第２の例として、システムの３つのセグメント（Ａ、Ｂ、およびＣ）が、異なるＪＴＡＧデバイス（１つまたは複数のカード内）上で実施されると仮定する。この第２の例では、３つのセグメントがメモリ内で定義された後に、ＴＩＳＡ動作は、
ｉ．  セグメントＡの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＩＲ（ｇａｔｅＴＣＫインジケータ）
ｉｉ．  セグメントＡのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＡのＩＲの長さをセットする
ｉｉｉ．  セグメントＡののＢＹＰＡＳＳ命令パターンを用いてＳｃａｎＢｌｏｃｋを動作させる
ｉｖ．  セグメントＢの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＩＲ（ｇａｔｅＴＣＫインジケータ）
ｖ．  セグメントＢのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＢのＩＲの長さをセットする
ｖｉ．  セグメントＢのＥＸＴＥＳＴ命令パターンを用いてＳｃａｎＢｌｏｃｋを動作させる
ｖｉｉ．  セグメントＣの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ
ｖｉｉｉ．  セグメントＣのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＣのＩＲの長さをセットする
ｉｘ．  セグメントＣのＢＹＰＡＳＳ命令パターンを用いてＳｃａｎＢｌｏｃｋを動作させる
ｘ．  セグメントＡの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＤＲ（ｇａｔｅＴＣＫ）
ｘｉ．  セグメントＡのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＡの選択されたＤＲの長さをセットする（１ビットＢＹＰＡＳＳ  ＤＲ）
ｘｉｉ．  セグメントＡのＢＹＰＡＳＳデータ・パターンを用いてＳｃａｎＢｌｏｃｋを動作させる
ｘｉｉｉ．  セグメントＢの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＤＲ（ｇａｔｅＴＣＫ）
ｘｉｖ．  セグメントＢのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＢの選択されたＤＲの長さをセットする（ピンへのｎビットＢＳＲ  ＤＲ）
ｘｖ．  セグメントＢのＥＸＴＥＳＴデータ・パターンを用いてＳｃａｎＢｌｏｃｋを動作させる
ｘｖｉ．  セグメントＣの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ
ｘｖｉｉ．  セグメントＣのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＣの選択されたＤＲの長さをセットする（１ビットＢＹＰＡＳＳ  ＤＲ）
ｘｖｉｉｉ．  セグメントＣのＢＹＰＡＳＳデータ・パターンを用いてＳｃａｎＢｌｏｃｋを動作させる
になる。
【０３４７】
第１の例と第２の例との比較において、第２の例に関連する追加の複雑さが、セグメントを選択／選択解除するために各ＪＴＡＧデバイスの命令レジスタ（ＩＲ）を使用する必要に由来することを理解されたい。その場合に、未使用セグメントは、関連するＪＴＡＧデバイスを１１４９．１標準規格のＢＹＰＡＳＳモードにすることによって（第２の例のステップ（ｉｉｉ）および（ｘｖｉｉ）に示されているように）直接にチェーンから外される。
【０３４８】
１つまたは複数のＪＴＡＧデバイス上で定義される任意の個数のセグメントを伴う、上の２つの例のすべての合成物が可能であることを了解されたい。さらに、上の２つの例が、単にテストされるシステムをテストするためのスキャン・セグメント・レベルの使用を示すために提供される例であり、したがって、スキャン・セグメント・レベルがテストされるシステムのテスティングに使用される実施形態がこれらの例によって限定されることは意図されていないことを了解されたい。
【０３４９】
そのような実施形態では、ＴＩＳＡ命令の実際のシーケンスは、次のうちの１つまたは複数を含む複数の出所を有することができる。（１）ＴＩＳＡ命令を、ＴＧＴによって静的に計算することができ、この場合には、ユーザがセグメントにアクセスすることを望むたびに、チェーン全体をスキャンしなければならない（この解決策は、スキャン時間に関しては最適化されないが、限られた計算リソースを有し、時間制約がほとんどまたは全くない組込みシステムに有用である可能性があることを了解されたい）、（２）ＴＩＳＡ命令を、アクセス要求を受け取り、これらをスキャン動作に合成するソフトウェア・スケジューラによって発行することができ、かつ／または（３）ＴＩＳＡ命令を、ハードウェア・スケジューラによって発行することができる（たとえば、いくつかの高性能プロセッサ内で命令リオーダリングおよびバイパスに関して行われるものなどであるが、これらに限定はされない）。スキャン・セグメント・レベル制御に関連するＴＩＳＡ命令を、任意の他の適切な形で発行することができ、これらの形が、上で説明した方法および／または上で説明した方法のうちの１つもしくは複数の代わりにもしくはそれに加えて使用できる１つもしくは複数の他の適切な方法の組合せを含むことができることを了解されたい。
【０３５０】
スキャン・セグメント・レベル抽象化レベルは、ＩＥＥＥ  Ｐ１６８７標準規格によって提案されるものおよび他の動的トポロジなどの動的トポロジを処理する強力なツールである。スキャン・チェーンのあるセクションが、アクティブ・スキャン・パスに取り込まれ、外される（たとえば、ＩＥＥＥ  Ｐ１６８７標準規格によって提案されるＳＩＢセルまたは任意の他の適切な階層を使用可能にするコンポーネント（１つまたは複数）を使用して）場合には、そのセクションを、１つ（または複数）のセグメントとしてマークすることができる。次に、テスティング・スケジューラは、システム状態から、このセグメント（１つまたは複数）がアクティブであるか否かに関する知識を有し、したがって、このセグメントをＴＩＳＡ命令スケジューリングに含めなければならないかどうかに関する知識を有する。本明細書の教示によって情報を与えられた当業者は、この原理を、ホットスワップ基板（たとえば、状況レジスタからその存在を検出することによって）または任意の他の適切な動的要素など、他の動的要素にも使用できることを了解するであろう。
【０３５１】
図１８に、スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用する、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態の高水準ブロック図を示す。
【０３５２】
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法１８００のステップの少なくとも一部を、同時にまたは図１８に関して図示され説明されるものとは異なる順序で実行することができる。
【０３５３】
ステップ１８０２で、方法１８００が開始される。
【０３５４】
ステップ１８０４では、スキャン・チェーンを複数のセグメントに分解する。スキャン・チェーンは、複数の要素に分解され、各セグメントは、スキャン・チェーンの要素のうちの少なくとも１つを含む。上で説明したように、スキャン・チェーンを任意の適切な形で分解することができる。本明細書で説明するように、セグメントへのスキャン・チェーンの分解を、開発フロー内のどこにでも適用することができる（たとえば、テスト開発者によって、テスト生成ツールによって、および組込み回路モデルによってなど）。
【０３５５】
ステップ１８０６では、命令のセットを生成する。命令のセットは、ＩＳＡに関連するプロセッサ命令と、テストされるシステムの一部分をテストするテスト命令とを含む。テスト命令は、スキャン・チェーンのセグメントごとに、そのセグメントに対して実行すべき少なくとも１つのスキャン動作を含む。テスト命令は、従来のテスト命令、およびＴＩＳＡのテスト命令など、任意のタイプのテスト命令とすることができ、したがって、任意の適切な形で生成することができる。命令のセットを、任意の適切な形で生成することができる（たとえば、上で図示し説明したものと同一のまたはこれに類似する形で。
【０３５６】
ステップ１８０８では、テストされるシステムの一部分をテストするために命令のセットを実行する。命令のセットは、任意の適切な形で実行することができ、この形は、命令のセットの命令のタイプに依存する場合がある。
【０３５７】
ステップ１８１０で、方法１８００は終了する。
【０３５８】
主にＴＩＳＡの実施形態がスキャン動作をスキャン・セグメント・レベルで実行することを可能にするのに使用される実施形態に関して図示され、本明細書で説明されるが、図示され本明細書で説明されるスキャン・セグメント・レベル実施形態のうちの１つまたは複数を、ＴＩＳＡ様命令アーキテクチャを使用する環境、非ＴＩＳＡ命令アーキテクチャ、および／または非ＴＩＳＡテスティング環境実装形態などで提供することもできることを了解されたい。
【０３５９】
図示され本明細書で説明されるように形成し、利用することのできるＴＩＳＡの例示的実施形態によって使用可能にされる機能強化されたシステム・テスティング能力を説明するために本明細書で「ｔｈｅ  ＴＩＳＡ」に言及するが、ＴＩＳＡがそれのために形成されるプロセッサのＩＳＡ、ＴＩＳＡがそれのために形成されるＳＵＴの特性、およびＴＩＳＡが実行すると思われるテスト・アルゴリズムの特性などのうちの１つまたは複数、ならびにそのさまざまな組合せなどのさまざまな要因に応じて、多数の異なるＴＩＳＡを形成できることを了解されたい。したがって、本明細書での「ｔｈｅ  ＴＩＳＡ」への言及は、多数の異なるタイプのＴＩＳＡを形成できるという点で、より概括的に「ａ  ＴＩＳＡ」と解釈することもできる。
【０３６０】
Ｊｏｉｎｔ  Ｔｅｓｔ  Ａｃｔｉｏｎ  Ｇｒｏｕｐ（ＪＴＡＧ）ハードウェアのテスティングをサポートする位置ベースのスケジューリング能力を、図示し、本明細書で説明する。
【０３６１】
一実施形態では、位置ベースのスケジューリング能力は、ＴＩＳＡのさまざまな能力を利用する。ＴＩＳＡでは、スキャン・チェーンは、セグメントと呼ばれるサブ要素の合成物とみなされ、これは、次の利益をもたらす。（１）セグメントに対する操作は、ローカルであり（すなわち、セグメントがその一部であるトポロジとは独立である）、（２）スキャン動作全体が、スキャン・チェーンがそれから構成されるセグメントに対する順序付けられた一連のスキャン動作によって構成される。そのような環境で、「ベクトル」の概念が、もはや必要ではなく、スキャン・チェーンの内部でのセグメントの位置だけが必要であることに留意されたい。したがって、一実施形態では、位置ベースのスケジューリング能力は、スキャン・チェーンの諸部分へのアクセスを必要とする要素が、要素がそれに従ってスキャン・チェーンの要求される部分にアクセスできるスケジュールを決定するように構成されたスケジューラにアクセス要求を提供するように構成され、これによって、要素のそれぞれがスキャン・チェーン全体の完全なベクトルを計算する必要をなくす。
【０３６２】
図１９に、テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す。
【０３６３】
図１９に示されているように、スケジューラ実行アーキテクチャ１９００は、テストされるシステム（ＳＵＴ）１９１０、ＴＩＳＡプロセッサ１９２０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を含む。
【０３６４】
ＳＵＴ１９１０は、ＴＩＳＡプロセッサ１９２０および明瞭にするために省略されているＴＡＰを介してアクセス可能なＪＴＡＧスキャン・チェーン１９１１を含む。ＪＴＡＧスキャン・チェーン１９１１は、４つのデバイス１９１２をトラバースする。４つのデバイス１９１２は、ＴＤＩからＴＤＯへの方向で、デバイス４、デバイス３、デバイス２、およびデバイス１と表され、これらのデバイスのそれぞれが、複数のレジスタ１９１３を含む。ＳＵＴ１９１０は、デバイス１９１２上に配置され、ＪＴＡＧスキャン・チェーン１９１１を介してアクセス可能な８つの機器１９１５を含む。８つの機器１９１５は、ＴＤＩからＴＤＯへの方向で、機器４．２および４．１（デバイス４上で直列に配置される）、機器３．２および３．１（デバイス３上で直列に配置される）、機器２（デバイス２上に配置される）、ならびに機器１．３、１．２、および１．１（デバイス１で直列に配置される）と表される。８つの機器１９１５は、ＪＴＡＧスキャン・チェーン１９１１の別々のセグメントと考えられる（たとえば、図１から１９のうちの１つまたは複数に関して本明細書で図示され、説明されるように）。セグメントを、個別に制御することができ、したがって、セグメントは、図１９に示されたスキャン・セグメント合成物１９１９をもたらす（すなわち、ＪＴＡＧスキャン・チェーン１９１１を、ＪＴＡＧスキャン・チェーン１９１１のデバイス１９１２のそれぞれのレジスタ１９１３のそれぞれからなるのではなく、８つの機器１９１５に対応する８つのスキャン・セグメントのシーケンスからなると考えることができる）。
【０３６５】
ＴＩＳＡプロセッサ１９２０は、ＳＵＴ１９１０のテスティングのためにスケジューラ１９３０によって決定されたスケジュールに基づいて、ユーザ・アプリケーション１９４０からＴＩＳＡ動作を受け取るように構成されている。ＴＩＳＡ動作は、ＴＩＳＡ命令を含むことができる（および、オプションで、他のタイプの情報を含むこともできる）。ＴＩＳＡプロセッサ１９２０は、ＳＵＴ１９１０に適用される関連する入力テスト・データを生成するためにＴＩＳＡ動作を処理し、オプションで、ＳＵＴ１９１０によって生成された出力テスト・データを受け取るように構成されている。少なくともいくつかの実施形態について、ＴＩＳＡプロセッサ１９２０の動作を、図１〜図１８を参照することによってよりよく理解できることに留意されたい。動作がＴＩＳＡプロセッサ１９２０によって実行され、入力テスト・データが生成される時に、ＴＩＳＡ動作は、ＪＴＡＧスキャン・チェーン１９１１内で正しい位置に整列される（すなわち、ＴＩＳＡ動作は、それぞれ、ＴＩＳＡ動作がそれのためのものであるスキャン・セグメントに関連付けられる）ことに留意されたい。一例を、図２０に示し、これに関して説明する。すなわち、図２０は、例示的なスキャン・チェーン合成物のための例示的なＴＩＳＡセグメント連結を示す図である。本明細書に上で説明したように、ＴＩＳＡプロセッサ（図１９に示され、これに関して説明されるＴＩＳＡプロセッサ１９２０など）は、スキャン・チェーンの部分的セクション（セグメント）に対する動作を実行し、動作の間にクロックを含むすべての信号を凍結するように構成されている。図２０では、信号線ＴＣＫ、ＴＭＳ、ＴＤＩは、ＴＩＳＡプロセッサのＪＴＡＧ出力を示し、ＴＤＩは、テストされるシステムからの入力を示す。図２０では、「ＦＳＭ」は、ＳＵＴに属するＪＴＡＧ有限状態機械の状態を示し、その状態遷移が、セグメント動作の間の一時停止からどれほど独立であるのかがわかる。図２０では、最後の２行は、それぞれＴＤＩおよびＴＤＯからの入出力ストリームが、異なるセグメントの間でどのように分配されるのかを示す。
【０３６６】
スケジューラ１９３０は、ユーザ・アプリケーション１９４０からアクセス要求を受け取り、アクセス要求の位置ベースのスケジューリングを実行し、ユーザ・アプリケーション１９４０がＳＵＴ１９１０のＪＴＡＧスキャン・チェーン１９１１の部分に対してＴＩＳＡ動作（それぞれアクセス要求／応答に関連する）を実行できる時に関して示すアクセス応答をユーザ・アプリケーション１９４０に応答するように構成されている。
【０３６７】
スケジューラ１９３０は、１つまたは複数のスケジューラ・コア・プロセス１９３２および回路モデル１９３４を含む。
【０３６８】
スケジューラ・コア・プロセス１９３２は、回路モデル１９３４を使用して、スケジューラ１９３０で受け取られたアクセス要求の位置ベースのスケジューリングを実行するように構成されたプロセスである。例示的なスケジューラ・コア・プロセス１９３２を、図２２に示し、これに関して説明する。スケジューラ・コア・プロセス１９３２は、まず回路モデル１９３４を検討することによってよりよく理解することができる。
【０３６９】
回路モデル１９３４は、ＳＵＴ１９１０のＪＴＡＧスキャン・チェーン１９１１がそれから構成されるスキャン・セグメントに関して指定される、ＳＵＴ１９１０の単純化されたモデルである。
【０３７０】
回路モデル１９３４は、ＳＵＴ１９１０のスキャン・セグメントの順序を指定するように構成されている（たとえば、スキャン・セグメント合成物１９１９に示されているように）。回路モデル１９３４は、ＴＩＳＡプロセッサ１９２０による対応するＴＩＳＡ動作の実行に関するアクセス要求／応答のスケジューリングを決定する際のスケジューラ１９３０による使用に適する任意の他の情報を含むこともできる。
【０３７１】
一実施形態では、回路モデル１９３４は、木構造を使用して実施される。この実施形態では、ＪＴＡＧスキャン・チェーン１９１１がそれから構成される各セグメントは、木内の葉ノードとして表され、木の残りは、ＪＴＡＧスキャン・チェーン１９１１の階層的な性質を表すスーパーセグメント（１つまたは複数の階層レベルにわたって配置される）を含む。木のルート・ノードは、ＳＵＴ１９１０を表す。木によって表される回路モデル１９３４が、（１）木の各葉ノードを、木内のそのパスに従って一意に識別することができ、（２）回路モデル１９３４が、本質的に階層的であり、システムを、回路モデル１９３４に部分木全体を単純に追加することによって構成することができ、（３）木の単純な深さ優先（ポストオーダーとも称する）トラバースが、ＳＵＴ１９１０のＪＴＡＧスキャン・チェーン１９１１上のセグメント・アクセスの正しい順序を提供することを含む、複数の特性を有することに留意されたい。例示的なスキャン・チェーン合成物およびＳＵＴ１９１０の回路モデル１９３４として使用される、それに関連する回路モデルを、図２１に示す。
【０３７２】
図２１に、図１９のテストされるシステムに関する例示的なスキャン・チェーン合成物および関連する回路モデルを示す。
【０３７３】
図２１に示されているように、例示的なスキャン・チェーン合成物２１１０は、デバイス１が、機器１．１、１．２、および１．３に対応する３つのセグメントから成り、デバイス２が、機器２に対応する１つのセグメントから成り、デバイス３が、機器３．１および３．２に対応する２つのセグメントから成り、デバイス４が、機器４．１および４．２に対応する２つのセグメントから成るように構成されている。
【０３７４】
図２１にさらに示されているように、例示的な回路モデル２１２０は、例示的なスキャン・チェーン合成物２１１０の木ベースのモデルである。例示的な回路モデル２１２０のルート（ＳＵＴと示されている）は、ＳＵＴ１９１０に対応する。例示的な回路モデル２１２０の次のレベルは、４つのノードを含む（デバイス１、機器２、デバイス３、およびデバイス４と示され、デバイス１、３、および４のノードは、それぞれ、そこから包む追加ノードを有し、機器２のノードは葉ノードである。例示的な回路モデル２１２０の最も下のレベルは、機器１９１５の一部がそれから成る７つのセグメントに対応する７つの葉ノードを含む（すなわち、デバイス１ノードは、デバイス１がそれから成る機器１．１、１．２、および１．３を表す３つの葉ノードの親であり、デバイス３ノードは、デバイス３がそれから成る機器３．１および３．２を表す２つの葉ノードの親であり、デバイス４ノードは、デバイス４がそれから成る機器４．１および４．２を表す２つの葉ノードの親である）。回路モデル２１２０では、スキャン・セグメントは、長方形のノードとして示され、残りのノードは、楕円形のノードとして示されている。
【０３７５】
回路モデル２１２０では、各スキャン・セグメントを、木内のそのパスによって一意に識別することができる。たとえば、機器１．３を表すセグメントは、パスＳＵＴ．デバイス１．機器１．３によって一意に識別され、機器２を表すセグメントは、パスＳＵＴ．機器２によって一意に識別され、機器４．２を表すセグメントは、パスＳＵＴ．デバイス４．機器４．２によって一意に識別されるなどである。したがって、例示的なスキャン・チェーン合成物２１１０を、例示的な回路モデル２１２０の深さ優先トラバーサルを実行することによって、例示的な回路モデル２１２０から入手することができる。一実施形態では、そのようなパスを使用する処理を支援するために、スケジューラ１９３０を、一意識別子を使用してそれぞれパスを表すことができるように（任意の適切なタイプの一意識別子を使用してパスを表すことができることを了解されたいが、たとえば、文字列より扱いが簡単である可能性がある一意整数識別子を使用して）一意識別子をパスに関連付けるように構成することができる。
【０３７６】
スケジューラ１９３０は、ユーザ・アプリケーション１９４０から順序付けられていないアクセス要求を受け取り、スケジューラ１９３０から使用可能なＳＵＴ１９１０の回路モデル１９３４からスケジューラ１９３０によって決定されたスキャン・セグメント合成物１９１９に基づいて、順序付けられていないアクセス要求のスケジューリングを決定し、アクセス応答をユーザ・アプリケーション１９４０に供給し、ここで、アクセス応答は、ユーザ・アプリケーション１９４０が関連するＴＩＳＡ動作（それぞれアクセス要求およびアクセス応答に関連する）を実行のためにＴＩＳＡプロセッサ１９２０に供給できる時に関して示す。この意味で、スケジューラ１９３０は、スケジューラ１９３０が、アクセス要求に関連するＴＩＳＡ動作をＴＩＳＡプロセッサ１９２０による処理のためにＴＩＳＡプロセッサ１９２０に供給できる順序に関してユーザ・アプリケーション１９４０に指示できるように、ユーザ・アプリケーション１９４０から受け取られたアクセス要求の順序付けられていないセットを処理し、アクセス応答の順序付けられたセット（たとえば、ＳＵＴ１９１０の回路モデル１９３４からスケジューラ１９３０によって決定されたスキャン・セグメント合成物１９１９にに従って順序付けられる）を生成する。
【０３７７】
スケジューラ１９３０を、クリティカル・セクションの概念を使用してアクセス要求の位置ベースのスケジューリングを実行するように構成することができ、このクリティカル・セクションの概念は、マルチタスク・オペレーティング・システムで相互に排他的なアクセスを調停するのに使用され得る。それによってスケジューラ１９３０がクリティカル・セクションの概念を使用してアクセス要求の位置ベースのスケジューリングを実行することができる例示的なプロセスを、図２２に示し、これに関して説明する。
【０３７８】
ユーザ・アプリケーション１９４０は、ＳＵＴ１９１０のテスティングに関連するアクセス要求を発行するように構成されている。ユーザ・アプリケーション１９４０は、機器１９１５のいずれに関するアクセス要求をも発行することができる。ユーザ・アプリケーション１９４０は、ＳＵＴ１９１０のスキャン・セグメント合成物１９１９の知識を有するのではなく、単に、アクセス要求に関連するＴＩＳＡ動作をＳＵＴ１９１０に適用できるまたは適用しなければならない順序を考慮に入れずにアクセス要求を発行する。ユーザ・アプリケーション１９４０によって発行されたアクセス要求は、ＳＵＴ１９１０の回路モデルからスケジューラ１９３０によって決定されるスキャン・セグメント合成物１９１９に基づくスケジューリングのためにスケジューラ１９３０によって受け取られる。ユーザ・アプリケーション１９４０は、さらに、アクセス要求に応答するスケジューラ１９３０からのアクセス応答を受け取り、アクセス応答に応答してＴＩＳＡプロセッサ１９２０にＴＩＳＡ動作を供給するように構成されている。それによってユーザ・アプリケーション１９４０がクリティカル・セクションの概念を使用してＪＴＡＧスキャン・チェーン１９１１の諸部分へのアクセスを要求し、受け取ることができる例示的なプロセスを、図２２に示し、これに関して説明する。
【０３７９】
図１９に示されているように、ユーザ・アプリケーション１９４０は、並列の形で動作することができる複数のユーザ・アプリケーション要素１９４１１〜１９４１Ｎ（集合的にユーザ・アプリケーション要素１９４１）を含む。ユーザ・アプリケーション１９４０によって送られるアクセス要求を、ユーザ・アプリケーション要素１９４１のうちの１つによって送ることができ、同様に、ユーザ・アプリケーション１９４０によって受け取られ、処理されるアクセス応答を、ユーザ・アプリケーション要素１９４１のうちで関連するアクセス要求がそこから送られたユーザ・アプリケーション要素によって受け取り、処理することができる。ユーザ・アプリケーション要素１９４１は、アクセス要求を送り、アクセス応答を受け取り、処理する際の使用のために構成された、アプリケーション・スレッドまたは任意の他のハードウェア・ベースの要素および／もしくはソフトウェアベースの要素とすることができる。
【０３８０】
図１９に示されているように、ユーザ・アプリケーション１９４０は、ＪＴＡＧスキャン・チェーン１９１１のセグメントへのアクセスを要求する順序付けられていないアクセス要求を送る。スケジューラ１９３０は、ユーザ・アプリケーション１９４０からアクセス要求を受け取る。順序付けられていないアクセス要求は、機器３．２、機器１．１、機器３．１、機器２、機器４．２、機器１．２、機器４．１、および機器１．３という初期順序でのセグメントに関するアクセス要求を含む。スケジューラ１９３０は、回路モデル１９３４を使用して、アクセス要求のスケジューリングを決定する。スケジューラ１９３０は、回路モデル１９３４を使用して、ＪＴＡＧスキャン・チェーン１９１１のスキャン・セグメントの順序付け（すなわち、スキャン・セグメント合成物１９１９）を決定する。スケジューラ１９３０は、回路モデル１９３４を使用して決定されたスキャン・セグメント合成物１９１９に基づいて、アクセス要求の順序付けを決定する。スケジューラ１９３０は、ユーザ・アプリケーションに供給されるそれぞれのアクセス応答を用いて、アクセス要求に応答する。順序付けられたアクセス応答のセットは、機器１．１、機器１，２、機器１．３、機器２、機器３．１、機器３．２、機器４．１、および機器４．２という順序でのセグメントに関するアクセス応答を含む。ユーザ・アプリケーション１９４０は、スケジューラ１９３０から順序付けられたアクセス応答のセットを受け取る。ユーザ・アプリケーション１９４０は、順序付けられたアクセス応答のセットによって指定されるセグメントの順序付けに基づいて（すなわち、機器１．１、機器１，２、機器１．３、機器２、機器３．１、機器３．２、機器４．１、および機器４．２という順序で）ＳＵＴ１９１０のＪＴＡＧスキャン・チェーン１９１１に対するＴＩＳＡ動作を実行する。
【０３８１】
図２２に、クリティカル・セクションの概念を使用するアクセス要求の位置ベースのスケジューリングを実行するプロセスの一実施形態を示す。
【０３８２】
ステップ２２１０では、ユーザ・アプリケーション１９４０が、スケジューラ１９３０にアクセス要求（要求として示される）を送る。
【０３８３】
ユーザ・アプリケーション１９４０は、ＳＵＴ１９１０のリソースにアクセスル必要がある時には、いつでもアクセス要求を開始することができる。
【０３８４】
アクセス要求は、ＳＵＴ１９１０のリソースへのユーザ・アプリケーション１９４０によるアクセスを要求するように構成されている。アクセス要求のリソースは、任意の適切なタイプのリソース（たとえば、ＳＵＴ１９１０のスキャン・セグメントおよび／または任意の他の適切なタイプのリソース）とすることができる。
【０３８５】
アクセス要求は、任意の適切な形でＳＵＴ１９１０のリソースを識別することができる。一実施形態では、たとえば、アクセス要求は、ユーザ・アプリケーション１９４０がそれへのアクセスを要求しつつあるＳＵＴ１９１０のリソースを指定する一意識別子（本明細書では一意識別子（ＵＩＤ）と表される場合がある）を含むことができる。
【０３８６】
少なくとも、スケジューラ１９３０が、関連するアクセス応答をユーザ・アプリケーション１９４０に返すように構成されているので（その時に、ユーザ・アプリケーション１９４０は、関連するＴＩＳＡ動作（１つまたは複数）をＴＩＳＡプロセッサ１９２０に供給する時に、ユーザ・アプリケーション１９４０でおよび／またはユーザ・アプリケーション１９４０から使用可能な関連するテスト・データを使用することができる）、アクセス要求が、それへのアクセスが要求されるリソースについてスキャンされる関連するテスト・データを含む必要がないことに留意されたい。
【０３８７】
ユーザ・アプリケーション１９４０は、スケジューラ１９３０からのアクセス応答を待ち、その間に、ユーザ・アプリケーション１９４０は、任意の適切な形で動作することができる（たとえば、スリープ状態または他の適切な待機状態に入る、スケジューラ１９３０への１つまたは複数の追加のアクセス要求を開始する、かつ１つまたは複数の他の処理機能を実行するなど）。
【０３８８】
ステップ２２２０では、スケジューラ１９３０が、アクセス要求の認可を決定する。
【０３８９】
スケジューラ１９３０は、ＳＵＴ１９１０のリソースへのアクセスに関する複数の順序付けられていないアクセス要求（図２２に示された要求と、明瞭にするために図２２から省略されている１つまたは複数の他のアクセス要求とを含む）を受け取り、ＳＵＴ１９１０の回路モデル１９３４からスケジューラ１９３０によって決定されたスキャン・セグメント合成物１９１９に基づく順序付けられていないアクセス要求のスケジューリングを決定するために複数の順序付けられていないアクセス要求を処理するように構成されている。この意味で、図２２の特定のアクセス要求について、スケジューラ１９３０は、ユーザ・アプリケーション１９４０が図２２のアクセス要求で指定されたＳＵＴ１９１０のリソースへのアクセスをグラントされる時を決定するように構成されている（やはり明瞭にするために図２２から省略されているユーザ・アプリケーション１９４０から受け取られるＳＵＴ１９１０のリソースに関する他のアクセス要求の認可のコンテキスト内で）。
【０３９０】
スケジューラ１９３０は、アクセス要求のスケジューリングを決定するために、回路モデル１９３４を処理する。スケジューラ１９３０が、任意の適切な形で回路モデル１９３４を探査できることに留意されたい。たとえば、回路モデル１９３４の探査を、正確な戦略に従って起動することができる（たとえば、すべての葉を保留としてマークする、時間によってトリガされる、および明示的要求など）。たとえば、スキャン・セグメントに関するアクセス要求を受け取った時に、スケジューラ１９３０は、回路モデル１９３４の関連する葉ノード（要求されたスキャン・セグメントに対応する）を保留としてマークする。たとえば、探査中に、保留ではないセグメントに出会った場合に、その代わりにデフォルト・シーケンスがシフトされる（たとえば、シーケンスを、固定することができる、かつ葉（たとえば、機器の提供者によって定義される）の内部に含めることができるなど）。機器動作がスキャン動作によって乱される可能性がある場合には、葉ノードが、ある長さの時間の間にアクセスを抑制するようにスケジューラ１９３０に要求することができることに留意されたい。
【０３９１】
ステップ２２３０では、スケジューラ１９３０が、ユーザ・アプリケーション１９４０から受け取ったアクセス要求（要求）に応答して、ユーザ・アプリケーション１９４０にアクセス応答（応答と表される）を送る。
【０３９２】
アクセス応答は、ユーザ・アプリケーション１９４０がスケジューラ１９３０によってそれへのアクセスをグラントされたＳＵＴ１９１０のリソース（１つまたは複数）を指定する、アクセス要求内で供給される一意識別子（やはり、本明細書ではＵＩＤと表される）を含む。
【０３９３】
アクセス応答は、ユーザ・アプリケーション１９４０がＵＩＤによって識別されるＳＵＴ１９１０のリソースへのアクセス権を有する唯一のエンティティであることをユーザ・アプリケーション１９４０に示す（すなわち、ＵＩＤによって識別されるＳＵＴ１９１０のリソースは、アクセスがスケジューラ１９３０によってグラントされたユーザ・アプリケーション１９４０による使用のためにロックされる）。したがって、アクセス応答の送出に関連して、スケジューラ１９３０は、ＵＩＤによって識別されるＳＵＴ１９１０のリソースをロックする。スケジューラ１９３０は、ＵＩＤによって識別されるＳＵＴ１９１０のリソースを任意の適切な形で（たとえば、ＵＩＤによって識別されるＳＵＴ１９１０のリソースに関連する回路モデル１９３４のノードに関連する１つまたは複数の値を変更することを介して、または任意の他の適切な形で）ロックすることができる。
【０３９４】
ステップ２２４０では、アクセス応答を受け取った後に、ユーザ・アプリケーション１９４０が、ＵＩＤによって識別されるＳＵＴ１９１０のリソースへのアクセス権を有し（ユーザ・アプリケーション１９４０が、ＵＩＤによって識別されるＳＵＴ１９１０のリソースへのアクセス権を現在有する唯一のエンティティであることの保証を伴って）、ＵＩＤによって識別されるＳＵＴ１９１０のリソースに対して１つまたは複数のＴＩＳＡ動作を実行する。動作は、ＵＩＤによって識別されるＳＵＴ１９１０のリソースに関する１つまたは複数のＴＩＳＡ動作をＴＩＳＡプロセッサ１９２０による実行のためにユーザ・アプリケーション１９４０からＴＩＳＡプロセッサ１９２０に送ることを含むことができる。ユーザ・アプリケーション１９４０によって実行される動作（１つまたは複数）は、ＳＵＴ１９１０へのＴＩＳＡプロセッサ１９２０を介する任意の適切な個数のＴＩＳＡアクセスを含むことができる。ユーザ・アプリケーション１９４０は、もはやＵＩＤによって識別されるＳＵＴ１９１０のリソースにアクセスする必要がなくなるまで、ＵＩＤによって識別されるＳＵＴ１９１０のリソースを使用し続けることができ、必要がなくなった時には、ユーザ・アプリケーション１９４０は、ＵＩＤによって識別されるＳＵＴ１９１０のリソースの解放を開始することができる。
【０３９５】
ステップ２２５０では、ユーザ・アプリケーション１９４０が、スケジューラ１９３０にリソース解放メッセージ（解放と表される）を送る。ユーザ・アプリケーション１９４０は、ユーザ・アプリケーションが、それに関するアクセスが最初に要求されたＳＵＴ１９１０のリソースへのアクセスをもはや必要としない時に、リソース解放メッセージを送る。リソース解放メッセージは、ユーザ・アプリケーション１９４０がスケジューラ１９３０によってそれへのアクセスをグラントされたＳＵＴ１９１０のリソースを指定する、アクセス要求内で供給された一意識別子（やはり、本明細書ではＵＩＤと表される場合がある）を含む。スケジューラ１９３０は、リソース解放メッセージを受け取った時に、ＵＩＤによって識別されるＳＵＴ１９１０のリソースを解放する。スケジューラ１９３０は、ＵＩＤによって識別されるＳＵＴ１９１０のリソースを任意の適切な形で（たとえば、ＵＩＤによって識別されるＳＵＴ１９１０のリソースに関連する回路モデル１９３４のノードに関連する１つまたは複数の値を変更することを介して）解放することができる。
【０３９６】
主にアクセス要求が単一のリソースへのアクセスを要求するように構成されている実施形態に関して図示され、説明されるが、複数のリソースへのアクセスを、１つまたは複数の関連するアクセス要求を介して要求できることに留意されたい。
【０３９７】
プロセス２２００が、ユーザ・アプリケーション１９４０によって開始されるアクセス要求ごとに繰り返され、これによって、スケジューラ１９３０がＪＴＡＧスキャン・チェーン１９１１にコヒーレントな形で複数のアクセス要求を認可することが可能にされ、同様に、ユーザ・アプリケーション１９４０がＪＴＡＧスキャン・チェーン１９１１全体の完全なベクトルを計算することを必要とせずに、ユーザ・アプリケーション１９４０が、ＪＴＡＧスキャン・チェーン１９１１のスキャン・セグメント合成物１９１９に基づく順序でＪＴＡＧスキャン・チェーン１９１１の諸部分にアクセスすることが可能にされることに留意されたい。この意味で、ユーザ・アプリケーション１９４０の展望から、プロセス２２００を、ユーザ・アプリケーション要素１９４１のうちのさまざまなユーザ・アプリケーション要素１９４１がアクセス要求を発行し、関連するアクセス応答を受け取り、処理する時に、ユーザ・アプリケーション要素１９４１のうちのさまざまなユーザ・アプリケーション要素１９４１によって並列に実行できることに留意されたい。プロセス２２００を、任意の適切な形で実施できることに留意されたい。一実施形態では、たとえば、プロセス２２００を、セマフォおよびミューテックスを使用して実施することができる。たとえば、コンピュータ・サイエンス技法の一般的な使用、より具体的にはダイクストラ（Ｄｉｊｋｓｔｒａ）のセマフォ定式化に関して、要求２２１０は、「Ｐ」動作と同等であり、解放２２５０は、「Ｖ」動作と同等である。
【０３９８】
位置ベースのスケジューリング能力のさまざまな実施形態が、ユーザ・アプリケーション１９４０の単純化を可能にすることに留意されたい。位置ベースのスケジューリング能力がないと、ユーザ・アプリケーション１９４０は、ＳＵＴ１９１０全体をモデル化する関連する回路モデルを維持する必要があるはずである。たとえば、ユーザ・アプリケーション１９４０は、（１）ＳＵＴ１９１０内のデバイスごとに、デバイスの構造的記述（たとえば、デバイス内のレジスタ（１つまたは複数）、レジスタ（１つまたは複数）にアクセスするのに使用される命令（１つまたは複数）、およびレジスタ（１つまたは複数）の長さ（１つまたは複数）など）および（２）ＳＵＴ１９１０のデバイスの間の接続を記述するリンク・リストを含む、ＳＵＴ１９１０の記述を提供する回路モデルを維持する必要があるはずである。同様に、位置ベースのスケジューリング能力がないと、ユーザ・アプリケーション１９４０が、ＳＵＴ１９１０内の特定のレジスタになにかを書き込みたい時に、ユーザ・アプリケーション１９４０は、そのデバイスを見つけ、そのデバイス内のレジスタを見つけ、レジスタを更新する必要があるはずであり、関連するスキャン動作ごとに、アクティブである現在のレジスタのベクトル情報のすべてを収集するためにデバイスのリンク・リストを通って進行し、ＳＵＴ１９１０のスキャン・チェーン内のデバイスのすべてを表すスーパーベクトルを書き出し、出力データを読み取り、出力データを分析するためにＳＵＴ１９１０の回路モデルに戻って出力データを返すために出力データを処理する必要もあるはずである。位置ベースのスケジューリング能力は、ユーザ・アプリケーション１９４０が、ＳＵＴ１９１０全体を記述する回路モデルを維持する必要をなくし、ユーザ・アプリケーション１９４０は、単に、関心を持たれる（たとえば、そのＵＩＤによって表される）ＳＵＴ１９１０の諸部分を知ることだけを必要とするはずである。位置ベースのスケジューリング能力は、ユーザ・アプリケーション１９４０が、ＳＵＴ１９１０に対して動作を実行する時にＳＵＴ１９１０のスキャン・チェーン全体を扱う必要をもなくす（たとえば、ユーザ・アプリケーション１９４０が、ＳＵＴ１９１０のスキャン・チェーン全体のスーパー入力ベクトルを構成し、ＳＵＴ１９１０の一部だけに対する動作を実行する時を含めて、ＳＵＴ１９１０に対して動作を実行する時にＳＵＴ１９１０のスキャン・チェーン全体に関するスーパー出力ベクトルを処理する必要をなくす）。そうではなく、ＴＩＳＡでは、セグメント（および、木の深さ優先トラバーサルが、ＳＵＴ１９１０のスキャン・チェーンがそれらから構成されるスキャン・セグメントの合成物をもたらす木ベースの表現である回路モデル内のスキャン・セグメントの関連する表現）の使用は、ＴＩＳＡモデル内のユーザ・アプリケーション１９４０から（たとえば、特定のスキャン・セグメントによって表される特定のデバイスまたはレジスタを対象とする動作を、その動作を送ることによって処理できる場合）から、そのスキャン・セグメントを表す回路モデルのノードへの動作の委譲を可能にし、そのノードは、そのデバイスまたはレジスタのみに固有のＴＩＳＡを用いてスキャン動作を実行できるようになる。言い替えると、所期の動作を実行するために、ＳＵＴ１９１０のスキャン・チェーン全体のベクトル全体を構成する必要はない。これが、実際のスキャン・チェーンに適合される必要がない、ユーザ・アプリケーション１９４０の可搬性に対する巨大な後押しであることに留意されたい。たとえば、ユーザ・アプリケーション１９４０が、ＳＵＴ１９１０のデバイス４との相互作用だけに関心を持っている（たとえば、ユーザ・アプリケーション１９４０が、エミュレーション・アプリケーションであり、デバイス４が、マイクロプロセッサ・チップである）場合に、ユーザ・アプリケーション１９４０は、（１）ＳＵＴ１９１０のデバイス３、デバイス２、またはデバイス１について知ることを要求されず、したがって、ＳＵＴ１９１０のデバイス３、デバイス２、またはデバイス１の情報を含む回路モデルを維持することを要求されず、かつ（２）ＳＵＴ１９１０のスキャン・チェーン全体のスーパー入力ベクトルを構成し、ＳＵＴ１９１０に対する動作を実行する時に、ＳＵＴ１９１０のスキャン・チェーン全体についてスーパー出力ベクトルを処理することを要求されない。そうではなく、ユーザ・アプリケーション１９４０は、単に、アクセス要求が、ユーザ・アプリケーション１９４０がデバイス４に対して実行することを望む動作（たとえば、デバイス４内の特定のレジスタの更新、または任意の他の適切な動作）を示す場合に、スケジューラ１９３０にアクセス要求を送る必要がある。この形で、要求された動作のハンドリングは、モデル化の問題（構造的記述およびリンク・リスト情報からスーパー入力ベクトルを構成し、所望の結果を分析するために関連するスーパー出力ベクトルを処理することを試みる時に、関連する処理およびそれに関連する効率の問題を含む）から、スケジューリングの問題（さまざまなコンピュータ・サイエンス機能を使用してスケジューラ１９３０によって処理することができる）に変換される。したがって、位置ベースのスケジューリング能力のさまざまな実施形態は、存在するテスティング能力より効率的である。
【０３９９】
明瞭にするために省略されているが、スケジューラ実行アーキテクチャ１９００のさまざまな要素を、１つまたは複数のデバイスを使用して実施することができ、同様に、スケジューラ実行アーキテクチャ１９００のさまざまな要素の間の通信を、任意の適切な形で（たとえば、使用されるデバイスの個数、およびデバイスの位置などに応じて）実行できることに留意されたい。さらに、スケジューラ実行アーキテクチャのさまざまな要素を、ハードウェアおよび／またはソフトウェアを使用して実施できることに留意されたい。たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０のそれぞれを、ハードウェアでまたは、１つもしくは複数のメモリに格納され、１つもしくは複数のプロセッサ（たとえば、ＴＩＳＡプロセッサ１９２０および／またはＴＩＳＡプロセッサ１９２０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０の位置に依存するものとすることができる任意の他の適切なプロセッサ（１つまたは複数））による実行のために構成されたソフトウェアベースのモジュールとして、実施することができる。
【０４００】
一実施形態では、たとえば、ＴＩＳＡプロセッサ１９２０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を、１つまたは複数の通信ネットワークを介して（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介して）お互いと通信することができる別々のデバイス内で実施することができる。
【０４０１】
一実施形態では、たとえば、ＴＩＳＡプロセッサ１９２０およびスケジューラ１９３０を、単一のデバイス内で同一位置に配置することができ、ユーザ・アプリケーション１９４０を、別々のデバイス内で実施することができる。たとえば、スケジューラ１９３０を、図示され本明細書で説明されるさまざまな機能を提供するためにスケジューラ１９３０を実行するように構成された、１つまたは複数のプロセッサ（たとえば、ＴＩＳＡプロセッサ１９２０および／またはＴＩＳＡプロセッサ１９２０と協力することができる１つもしくは複数の他のプロセッサ）からアクセス可能な１つまたは複数のメモリに格納されたソフトウェアベースのモジュールとすることができる。たとえば、ユーザ・アプリケーション１９４０を、ハードウェア内で、または、１つもしくは複数のメモリ内に格納され、図示され本明細書で説明されるさまざまな機能を提供するために１つもしくは複数のプロセッサによる実行のために構成されたソフトウェアベースのモジュールとして、実施することができる。たとえば、スケジューラ１９３０とユーザ・アプリケーション１９４０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができる。
【０４０２】
一実施形態では、たとえば、ＴＩＳＡプロセッサ１９２０およびユーザ・アプリケーション１９４０を、単一のデバイス内で同一位置に配置することができ、スケジューラ１９３０を、別々のデバイス内で実施することができる。たとえば、ユーザ・アプリケーション１９４０を、図示され本明細書で説明されるさまざまな機能を提供するためにユーザ・アプリケーション１９４０を実行するように構成された１つまたは複数のプロセッサ（たとえば、ＴＩＳＡプロセッサ１９２０および／またはＴＩＳＡプロセッサ１９２０と協力することができる１つもしくは複数の他のプロセッサ）からアクセス可能な１つまたは複数のメモリに格納されたソフトウェアベースのモジュールとすることができる。たとえば、スケジューラ１９３０を、ハードウェアで実施するか、１つまたは複数のメモリに格納され、図示され本明細書で説明されるさまざまな機能を提供するために１つまたは複数のプロセッサによって実行されるように構成された、ソフトウェアベースのモジュールとして実施することができる。たとえば、ユーザ・アプリケーション１９４０とスケジューラ１９３０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができる。
【０４０３】
一実施形態では、たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、単一のデバイス内で同一位置に配置することができ、ＴＩＳＡプロセッサ１９２０を、別々のデバイス内で実施することができる。たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、それぞれ、ハードウェアで実施するか、１つまたは複数のメモリに格納され、図示され本明細書で説明されるさまざまな機能を提供するために１つまたは複数のプロセッサによって実行されるように構成された、ソフトウェアベースのモジュールとして実施することができる。たとえば、ユーザ・アプリケーション１９４０とＴＩＳＡプロセッサ１９２０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができる。
【０４０４】
一実施形態では、たとえば、ＴＩＳＡプロセッサ１９２０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を、単一のデバイス内で同一位置に配置することができる。たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、図示され本明細書で説明されるさまざまな機能を提供するためにスケジューラ１９３０およびユーザ・アプリケーション１９４０を実行するように構成された１つまたは複数のプロセッサ（たとえば、ＴＩＳＡプロセッサ１９２０および／またはＴＩＳＡプロセッサ１９２０と協力することができる１つもしくは複数の他のプロセッサ）からアクセス可能な１つまたは複数のメモリに格納されたソフトウェアベースのモジュールとすることができる。例示的な実施形態を、図２３に示し、これに関して説明する。
【０４０５】
図２３に、テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す。
【０４０６】
図２３に示されているように、スケジューラ実行アーキテクチャ２３００は、図１９のスケジューラ実行アーキテクチャ１９００に類似するが、テストされるシステム（ＳＵＴ）２３１０、メインＣＰＵ２３２０、スケジューラ２３３０、およびユーザ・アプリケーション２３４０を含む。明瞭にするために、ＳＵＴ２３１０が、ＳＵＴ１９１０と同等であり、メインＣＰＵ２３２０が、ＴＩＳＡプロセッサ１９２０と同等であり、スケジューラ２３３０が、スケジューラ１９３０と同等であり、ユーザ・アプリケーション２３４０が、ユーザ・アプリケーション１９４０と同等である（セグメント・スレッド２３４１１から２３４１Ｎが、それぞれユーザ・アプリケーション要素１９４１１から１９４１Ｎと同等である）ことに留意されたい。
【０４０７】
ＳＵＴ２３１０は、メインＣＰＵ２３２０およびＴＡＰ（明瞭にするために省略されている）を介してアクセス可能なＪＴＡＧスキャン・チェーン２３１１を含む。ＪＴＡＧスキャン・チェーン２３１１は、複数のスキャン・セグメント２３１９１〜２３１９Ｍ（集合的にスキャン・セグメント２３１９）からなる関連するスキャン・チェーン合成物２３１８を有する。
【０４０８】
メインＣＰＵ２３２０は、ＴＩＳＡ２３２２をサポートし、メインＣＰＵ２３２０が、ＴＩＳＡプロセッサとして機能するように構成されているようになっている（たとえば、図１９に示され、これに関して説明されたＴＩＳＡプロセッサ１９２０に類似する形で）。
【０４０９】
メインＣＰＵ２３２０は、メモリ２３２４へのアクセスを有し、メモリ２３２４は、スケジューラ２３３０およびユーザ・アプリケーション２３４０を格納する。
【０４１０】
スケジューラ２３３０は、ユーザ・アプリケーション２３４０からアクセス要求を受け取り、アクセス要求の位置ベースのスケジューリングを実行し、ユーザ・アプリケーション２３４０がそれぞれアクセス要求／応答に関連するＳＵＴ２３１０のＪＴＡＧスキャン・チェーン２３１１の部分に対してＴＩＳＡ動作を実行できる時に関して示すアクセス応答を用いてユーザ・アプリケーション２３４０に応答するように構成されている。たとえば、ＴＩＳＡ動作は、処理のためにＴＩＳＡプロセッサ２３２０にＴＩＳＡ動作を供給することを含むことができる。
【０４１１】
スケジューラ２３３０は、１つまたは複数のスケジューラ・コア・プロセス２３３２および回路モデル２３３４を含む。
【０４１２】
スケジューラ・コア・プロセス２３３２は、回路モデル２３３４を使用して、スケジューラ２３３０で受け取られたアクセス要求の位置ベースのスケジューリングを実行するように構成されたプロセスである。スケジューラ２３３０は、ユーザ・アプリケーション２３４０がそれを介してスケジューラ・コア・プロセス２３３２にアクセスするアプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供するアクセスＡＰＩ２３３３をも含む。アクセスＡＰＩ２３３３は、ユーザ・アプリケーション２３４０がアクセス・スケジューリング・プロトコル（たとえば、図２２に示され、これに関して説明されたアクセス・スケジューリング・プロトコル２２００）を使用してスケジューラ２３３０と通信することを可能にするように構成されている。スケジューラ・コア・プロセス２３３２を、スケジューラ１９３０によって実行されるものとして図示され、説明されたアクセス・スケジューリング・プロトコルの諸部分を実行するように構成することができる。
【０４１３】
回路モデル２３３４は、ＳＵＴ２３１０のＪＴＡＧスキャン・チェーン２３１１がそれから構成されるスキャン・セグメント２３１９に関して指定される、ＳＵＴ２３１０の単純化されたモデルである。スケジューラ２３３０は、ユーザ・アプリケーション２３４０がそれを介して回路モデル２３３４にアクセスするアプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供する回路モデルＡＰＩ２３３５をも含む。回路モデルＡＰＩ２３３５は、ユーザ・アプリケーション２３４０が回路モデル１９３４を作り、変更することを可能にするように構成されている。回路モデル２３３４を、図２１の例示的な回路モデル２１２０に関して図示し、説明したように、回路モデルＡＰＩ２３３５を介して作り／変更することができることに留意されたい。
【０４１４】
ユーザ・アプリケーション２３４０は、ＳＵＴ２３１０のテスティングに関連するアクセス要求を発行するように構成されている。ユーザ・アプリケーション２３４０は、ＳＵＴ２３１０のスキャン・セグメント２３１９のいずれに関するアクセス要求をも発行することができる。ユーザ・アプリケーション２３４０は、ＳＵＴ２３１０のスキャン・セグメント合成物２３２３の知識を有するのではなく、単に、アクセス要求をＳＵＴ２３１０に適用できるまたは適用しなければならない順序を考慮に入れずにアクセス要求を発行する。ユーザ・アプリケーション２３４０によって発行されたアクセス要求は、ＳＵＴ２３１０の回路モデルからスケジューラ２３３０によって決定されるスキャン・セグメント合成物２３２３に基づくスケジューリングのためにスケジューラ２３３０によって受け取られる。
【０４１５】
ユーザ・アプリケーション２３４０は、複数のスキャン・セグメント・スレッド２３４２１〜２３４２Ｎ（集合的にスキャン・セグメント・スレッド２３４２）およびメイン・スレッド２３４４を含む。スキャン・セグメント・スレッド２３４２は、メイン・スレッド２３４４によってサポートされる。
【０４１６】
ユーザ・アプリケーション２３４０のスキャン・セグメント・スレッド２３４２は、それぞれ、アクセス・スケジューリング・プロトコル（たとえば、図２２に図示され、これに関して説明されたアクセス・スケジューリング・プロトコル２２００）のそれぞれのインスタンスを使用してアクセスＡＰＩ２３３３を介してスケジューラ・コア・プロセス２３３２と通信するように構成されている。この意味で、スキャン・セグメント・スレッド２３４２は、スキャン・セグメント・スレッド２３４２のうちの１つまたは複数が任意の所与の時にアクセスＡＰＩ２３３３を介するスケジューラ２３３０とのアクセス・アービトレーションに含まれ得るので、マルチタスキングをサポートする。
【０４１７】
ユーザ・アプリケーション２３４０のメイン・スレッド２３４４は、スケジューラ２３３０の回路モデルＡＰＩ２３３５を介してスケジューラ２３３０の回路モデル２３３４を作り、変更するように構成されている。
【０４１８】
図２３のスケジューラ実行アーキテクチャ２３００が図１９のスケジューラ実行アーキテクチャ１９００に関連して再検討される時に、メインＣＰＵ２３２０を介してＳＵＴ２３１０をテストする際のユーザ・アプリケーション２３４０およびスケジューラ２３３０の動作をよりよく理解できることに留意されたい。
【０４１９】
本明細書で注記したように、メインＣＰＵ２３２０は、メモリ２３２４へのアクセスを有し、メモリ２３２４は、スケジューラ２３３０およびユーザ・アプリケーション２３４０を格納する。この意味で、スケジューラ２３３０のスケジューラ・コア・プロセス２３３２には、図示され本明細書で説明されるスケジューラ２３３０のさまざまな機能を提供するためにメインＣＰＵ２３２０によってアクセスし、実行することができる。同様に、ユーザ・アプリケーション２３４０のセグメント・スレッド２３４２は、ＴＩＳＡ２３２２を介してＳＵＴ２３１０のＪＴＡＧスキャン・チェーン２３１１へのＴＩＳＡアクセスを実行するためにメインＣＰＵ２３２０と通信することができる。主に単一のメモリ２３２４の使用に関して図示され、説明されるが、スケジューラ２３３０および／またはユーザ・アプリケーション２３４０を、任意の適切な個数のメモリを使用して提供できることに留意されたい。
【０４２０】
少なくともいくつかの実施形態で、スケジューラ実行アーキテクチャ２３００が、さまざまなマルチタスク・オペレーティング・システム（ＯＳ）および／または他のタイプのフレームワークと互換であることに留意されたい。一実施形態では、たとえば、ＰＯＳＩＸを使用するスケジューラ実行アーキテクチャ２３００の実装形態は、スケジューラ実行アーキテクチャ２３００を、縮小されたスレッド・スケジューラを組み込んだ独立型アプリケーションとして動作させることを可能にする。主に、静的パスのスケジューリングに関する位置ベースのスケジューリング能力の使用に関して図示され、本明細書で説明されるが、位置ベースのスケジューリング能力のさまざまな実施形態が、動的パスのスケジューリングをサポートできることに留意されたい。概して、動的パスは、主に動的パスが大量のベクトル再生成および／または変更を強制するという事実に起因して、伝統的な再標的化の主要な制限の１つである。
【０４２１】
位置ベースのスケジューリング能力の一実施形態では、必要または望みに応じてＳＵＴのスキャン・チェーンに１つまたは複数の動的セグメントを挿入し、除去することを可能にすることによって、ＳＵＴの動的スキャン・パスをサポートすることができる。一実施形態では、動的セグメントを、ＳＵＴについて定義される制御エンティティを介してスキャン・チェーンに動的に挿入されまたはスキャン・チェーンから除去されるように構成することができ、ここで、動的セグメントは、木内で、制御エンティティを表す関連する親ノードを有する葉ノードとして表される。制御エンティティは、階層内で動的セグメントに直接に隣接して存在することができるが、そうである必要はない。たとえば、動的セグメントを、複数のセグメントだけ離れたある他のデータ・レジスタによって制御することができる。たとえば、動的セグメントを、ＳＵＴのスキャン・チェーン内でもはやアクセス可能ではないが、その状態が１１４９．１標準規格による定義に従って保存される、１１４９．１のＴＡＰコントローラ内のそれ自体の命令を介してアクセスされる別々のデータ・レジスタによって制御することができる。言い替えると、制御の多数の異なるタイプの表現が可能であり、したがって、制御エンティティを、複数の異なる形で実施することができる。ツールによってモデル化され、制御され得る制御エンティティの制御態様の事前定義の記述が存在するという意味で、制御エンティティが、ＳＵＴのために定義されることに留意されたい。
【０４２２】
位置ベースのスケジューリング能力の一実施形態では、動的パスをスーパーセグメントとして表すことによって、動的スキャン・パスのスケジューリングをサポートすることができる。この実施形態を、図２４を検討することによってよりよく理解することができる。
【０４２３】
図２４に、スキャン・チェーン合成物が動的セグメントを含む場合の、例示的なスキャン・チェーン合成物および関連する回路モデルを示す。
【０４２４】
図２４に示されているように、例示的なＳＵＴ２４１０は、要素をＳＵＴ２４１０のＪＴＡＧスキャン・チェーン２４１１に動的に挿入でき、除去できる動的スキャン・パスをサポートする。ＳＵＴ２４１０は、ＳＵＴ２４１０のＪＴＡＧスキャン・チェーン２４１１内に含まれるセル（実例として、セルＸ）の値に依存する２つの異なる構成をサポートする。ＳＵＴ２４１０の第１の構成（ＳＵＴ２４１０１と表される）では、セルＸの値は、セルＸおよび静的部分（静的と表される）だけが、ＪＴＡＧスキャン・チェーン２４１１内でアクティブになるようにセットされる。ＳＵＴ２４１０の第２の構成（ＳＵＴ２４１０２と表される）では、セルＸの値は、動的セクション（動的と表される）が、セルＸとアクティブ部分との間でＪＴＡＧスキャン・チェーン２４１１に追加されるようにすなわち、セルＸ、動的セクション、および静的セクション（静的と表される）が、ＪＴＡＧスキャン・チェーン２４１１内でアクティブになるように、セットされる。ＪＴＡＧスキャン・チェーン２４１１への動的セクションの挿入およびＪＴＡＧスキャン・チェーン２４１１からの動的セクションの除去を、セルＸの値を変更することによって制御することができる。セルＸを、任意の適切な要素を使用して（たとえば、ＩＥＥＥ１６８７ドラフト標準規格のＳｅｇｍｅｎｔ  Ｉｎｓｅｒｔｉｏｎ  Ｂｉｔ（ＳＩＢ）を使用してまたは任意の他の適切な要素（１つまたは複数）を使用して）実施できることに留意されたい。
【０４２５】
図２４にさらに示されているように、動的なＪＴＡＧスキャン・パス２４１１をサポートする例示的なＳＵＴ２４１０を、回路モデル２４２０を使用して表すことができる。回路モデル２４２０では、セルＸは、スーパーセグメント２４２１（図２４では台形として表される）として表される。セルＸは、スーパーセグメント２４２１がそれに関連する状況を有するように、それに関連する状況を有する。回路モデル２４２０の深さ優先トラバーサルが実行される時に、セルＸを介する再帰は、セルＸの状況に依存する（たとえば、セルＸを介する再帰は、セルＸの状況が「開」である時に許可され、そうではなく、セルＸの状況が「閉」である時には、セルＸは葉セグメントとして扱われる）。
【０４２６】
一実施形態では、関連するスケジューラ（たとえば、スケジューラ１９３０および／またはスケジューラ２３３０）は、再標的化の必要を全く伴わずに、回路モデル２４２０の現在の状況に基づいてオン・ザ・フライで適合することができる。
【０４２７】
一実施形態では、関連するスケジューラは、回路モデル２４２０の「動的」ノードがアクティブではない時（セルＸの状況が「閉」であり、セルＸのスーパーセグメント２４２１が閉じられている時）に、回路モデル２４２０の「動的」ノードへの要求を検出し、それに応答して、非アクティブ「動的」葉ノードが関連付けられる（これによって、回路モデル２４２０の「動的」ノードにアクティブにならせる）セルＸのスーパーセグメント２４２１を開く１つまたは複数のスキャン・セグメント動作を生成するように構成されている。より概括的には、一実施形態で、スケジューラは、非アクティブ葉ノードへの要求を検出し、それに応答して、非アクティブ葉ノードがアクティブになるように、関連するスーパーセグメント（すなわち、非アクティブ葉ノードが関連付けられるスーパーセグメント）の状況を「閉」から「開」に変更する１つまたは複数のスキャン・セグメント動作を生成するように構成されている。スーパーセグメントの状態を変更する動作を、必要に応じて単純にまたは複雑にすることができ、オブジェクト指向パラダイムでは、スケジューラ２３３０によって実装メソッドに簡単に委譲することができる（たとえば、ビジタ・デザイン・パターンまたは任意の他の適切な機構を使用して）ことに留意されたい。
【０４２８】
そのような実施形態で、任意の適切なシステム値を使用して、回路モデル２４２０の深さ優先トラバーサルを制御できることに留意されたい。一実施形態では、たとえば、「開」（ノードのトラバーサルが許可されることを示す）、「閉」（再帰がこのノードで終了し、状態が同一のままになることを示す）、および「保留」（再帰がこのノードで終了し、ノードの状態が次の反復のために「開」に変更されることを示す）の状況値をサポートすることができる。状況値の異なるセットを使用することもできることに留意されたい。
【０４２９】
そのような実施形態では、回路モデル２４２０内のノードの状況を、任意の適切な形で管理できることに留意されたい。たとえば、一実施形態では、グラフ彩色を使用して、回路モデル２４２０のノードの状況を管理することができ、これによって、回路モデル２４２０の各ノードは、そのノードに関して行うべきアクション（１つまたは複数）を決定するために深さ優先トラバーサル・プロセスによって使用され得る色を割り当てられる。
【０４３０】
主に、単一の動的セグメントへのアクセスを規制するためのスーパーセグメント２４２１の使用に関して図示され、説明されるが、スーパーセグメント２４２１を使用して、複数の動的セグメントへのアクセスを規制することができる。この場合に、スーパーセグメントの状態（すなわち、セルＸの値）は、どの１つまたは複数の動的セグメントがアクティブであるのかと、それらをトラバースすべき順序とを決定することができる。
【０４３１】
図２５に、テストされるシステムをテストするための位置ベースのスケジューリングをサポートする方法の一実施形態を示す。
【０４３２】
図２５に示されているように、ステップが、テストされるシステムをテストするのに使用されるユーザ・アプリケーション、スケジューラ、およびＴＩＳＡプロセッサ（たとえば、図１９に示し、これに関して説明したユーザ・アプリケーション１９４０、スケジューラ１９３０、およびＴＩＳＡプロセッサ１９２０）によって実行される。主に、特定の順序で直列に実行されるものとして図示され、説明されるが、方法２５００のステップの少なくとも一部を、同時におよび／または図２５に示されたものとは異なる順序で実行することができる。
【０４３３】
ステップ２５０５で、方法２５００が開始される。ステップ２５１０では、ユーザ・アプリケーション１９４０が、テストされるシステムのそれぞれの部分へのアクセスを要求する、順序付けられていないアクセス要求を生成する。ステップ２５１５では、ユーザ・アプリケーション１９４０が、順序付けられていないアクセス要求をスケジューラ１９３０に送る。ステップ２５２０では、スケジューラ１９３０が、ユーザ・アプリケーション１９４０から順序付けられていないアクセス要求を受け取る。ステップ２５２５では、スケジューラ１９３０が、関連する回路モデルを使用して順序付けられていないアクセス要求のスケジューリングを決定する。ステップ２５３０では、スケジューラ１９３０が、順序付けられていないアクセス要求に関連する順序付けられたアクセス応答を生成する。ステップ２５３５では、スケジューラ１９３０が、順序付けられたアクセス応答をユーザ・アプリケーション１９４０に送る。ステップ２５４０では、ユーザ・アプリケーション１９４０が、スケジューラ１９３０から順序付けられたアクセス応答を受け取る。ステップ２５４５では、ユーザ・アプリケーション１９４０が、順序付けられたアクセス応答に関連するＴＩＳＡ動作を生成する。ステップ２５５０では、ユーザ・アプリケーション１９４０が、ＴＩＳＡ動作をＴＩＳＡプロセッサ１９２０に送る。ステップ２５５５では、ＴＩＳＡプロセッサ１９２０が、ＴＩＳＡ動作を受け取る。ステップ２５６０では、ＴＩＳＡプロセッサ１９２０が、ＴＩＳＡ動作を処理する。ステップ２５６５では、方法２５００が終了する。方法２５００のさまざまなステップを、図１９〜図２４の説明に関連して考慮する時によりよく理解できることに留意されたい。
【０４３４】
図１９〜図２５は、主に、本明細書で、ユーザ・アプリケーション１９４０からＳＵＴ１９１０に向かうテスティング入力方向での位置ベースのスケジューリング（たとえば、ＳＵＴ１９１０に対するテストを開始するための）のサポートに関して図示され、説明されるが、位置ベースのスケジューリングのさまざまな機能を、ＳＵＴ１９１０からユーザ・アプリケーション１９４０に向かうテスティング出力方向での位置ベースのスケジューリング（たとえば、ＳＵＴ１９１０について開始されたテストの結果を受け取り、分析するための）をサポートするために反対の順序で実行できることを了解されたい。一実施形態では、たとえば、処理は、（１）ＴＩＳＡプロセッサ１９２０が、ＴＤＯを介してＳＵＴ１９１０からテスティング出力データを受け取り、ＳＵＴ１９１０に供給されるテスティング入力データを作るためにＴＩＳＡプロセッサ１９２０によって処理されたＴＩＳＡ動作に関連するテスティング出力結果を作るためにテスティング出力データを処理し、テスティング出力結果をユーザ・アプリケーション１９４０に向かって伝搬させ、（２）ユーザ・アプリケーション１９４０が、ＴＩＳＡプロセッサ１９２０からテスティング出力結果を受け取り、テスティング出力結果を処理する（たとえば、ＳＵＴ１９１０について開始されたテストの結果を分析するために）、のように進行することができる。主にユーザ・アプリケーションがＴＩＳＡプロセッサにＴＩＳＡ動作を供給する責任を負う実施形態の文脈で図示され、説明されるが、一実施形態では、スケジューラが、ＴＩＳＡプロセッサにＴＩＳＡ動作を供給する責任を負うことができることに留意されたい。例示的な実施形態を、図２６に示し、これに関して説明する。
【０４３５】
図２６に、テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成されたスケジューラ実行アーキテクチャの一実施形態を示す。
【０４３６】
図２６に示されているように、図２６のスケジューラ実行アーキテクチャ２６００は、ユーザ・アプリケーション１９４０ではなくスケジューラ１９３０が、ＴＩＳＡプロセッサ１９２０にＴＩＳＡ動作を供給するように構成されていることを例外として、図１９のスケジューラ実行アーキテクチャ１９００に類似する。
【０４３７】
ユーザ・アプリケーション１９４０は、順序付けられていないアクセス要求をスケジューラ１９３０に送る。さらに、ユーザ・アプリケーション１９４０は、アクセス要求の関連するテスト・データをもスケジューラ１９３０に供給する。テスト・データを、アクセス要求と共におよび／またはアクセス要求とは別々に供給することができる。アクセス要求および関連するテスト・データを、任意の適切なフォーマットで（たとえば、パケット、およびメッセージなど、ならびにそのさまざまな組合せとして）ユーザ・アプリケーション１９４０からスケジューラ１９３０に供給することができる。
【０４３８】
スケジューラ１９３０は、順序付けられていないアクセス要求およびアクセス要求の関連するテスト・データをユーザ・アプリケーション１９４０から受け取る。スケジューラ１９３０は、順序付けられたアクセス応答をユーザ・アプリケーション１９４０に供給する（図１９に関して図示され、説明されるように）のではなく、アクセス要求のスケジューリングを決定し、アクセス要求の決定されたスケジューリングに基づいて、適当なＴＩＳＡ動作をＴＩＳＡプロセッサ１９２０に発行する。スケジューラ１９３０は、それぞれアクセス要求のＴＩＳＡ動作を生成するために、アクセス要求のテスト・データを使用するように構成されている。スケジューラ１９３０は、スケジューラ１９３０によって決定されたアクセス要求のスケジューリング／ＴＩＳＡ動作に基づいて、ＴＩＳＡプロセッサ１９２０にＴＩＳＡ動作を発行する。
【０４３９】
ＴＩＳＡプロセッサ１９２０は、スケジューラ１９３０からＴＩＳＡ動作を受け取り、処理は、図１９のスケジューラ実行アーキテクチャ１９００に関して図示され、説明されるように進行する。
【０４４０】
図２７に、テストされるシステムをテストするための位置ベースのスケジューリングをサポートする方法の一実施形態を示す。図２７に示されているように、ステップが、テストされるシステムをテストするのに使用されるユーザ・アプリケーション、スケジューラ、およびＴＩＳＡプロセッサ（たとえば、図１９に示し、これに関して説明したユーザ・アプリケーション１９４０、スケジューラ１９３０、およびＴＩＳＡプロセッサ１９２０）によって実行される。主に、特定の順序で直列に実行されるものとして図示され、説明されるが、方法２７００のステップの少なくとも一部を、同時におよび／または図２７に示されたものとは異なる順序で実行することができる。
【０４４１】
ステップ２７０５で、方法２７００が開始される。ステップ２７１０では、ユーザ・アプリケーション１９４０が、テストされるシステムのそれぞれの部分へのアクセスを要求する、順序付けられていないアクセス要求を生成する。ステップ２７１５では、ユーザ・アプリケーション１９４０が、順序付けられていないアクセス要求およびアクセス要求の関連する入力テスト・データをスケジューラ１９３０に送る。ステップ２７２０では、スケジューラ１９３０が、ユーザ・アプリケーション１９４０から順序付けられていないアクセス要求を受け取る。ステップ２７２５では、スケジューラ１９３０が、関連する回路モデルを使用して順序付けられていないアクセス要求のスケジューリングを決定する。ステップ２７３０では、スケジューラ１９３０が、スケジューリングされたアクセス要求に関連するＴＩＳＡ動作を生成する。ステップ２７３５では、スケジューラ１９３０が、ＴＩＳＡ動作をＴＩＳＡプロセッサ１９２０に送る。ステップ２７４０では、ＴＩＳＡプロセッサ１９２０が、ＴＩＳＡ動作を受け取る。ステップ２７４５では、ＴＩＳＡプロセッサ１９２０が、ＴＩＳＡ動作を処理する。ステップ２７５０では、方法２７００が終了する。方法２７００のさまざまなステップを、図１９〜図２６の説明に関連して考慮する時によりよく理解できることに留意されたい。
【０４４２】
図２６および図２７を、主に、入力テスティング・データがユーザ・アプリケーション１９４０からスケジューラ１９３０に供給され、スケジューラ１９３０がＴＩＳＡプロセッサ１９２０に供給される関連するＴＩＳＡ動作を生成する実施形態に関して図示し、説明したが、少なくともいくつかの実施形態で、（１）ユーザ・アプリケーション１９４０が、ＴＩＳＡ動作を生成し、ＴＩＳＡ動作のスケジューリングのためにＴＩＳＡ動作をスケジューラ１９３０に供給するように構成され、（２）スケジューラ１９３０が、ユーザ・アプリケーション１９４０から受け取られたＴＩＳＡ動作をスケジューリングし、ＴＩＳＡ動作の決定されたスケジューリングに基づいてＴＩＳＡ動作をＴＩＳＡプロセッサ１９２０に供給するように構成されていることに留意されたい。図２６および２７で図示し、説明した実施形態に関して、ユーザ・アプリケーション１９４０を、スケジューラ１９３０にアクセス要求を送るように構成することができ、ここで、アクセス要求の入力テスティング・データを供給するのではなく、ユーザ・アプリケーション１９４０は、アクセス要求のＴＩＳＡ動作（および関連する入力テスティング・データ）を供給する（たとえば、図２６および２７に図示し、これらに関して説明した実施形態に似て、アクセス要求の一部としておよび／またはアクセス要求とは別々に）。そのような実施形態が、スケジューラ１９３０がＴＩＳＡ動作を生成する必要をなくすが、ユーザ・アプリケーション１９４０からスケジューラ１９３０により大量の情報を送ることを必要とするという犠牲を払うことに留意されたい。
【０４４３】
図２６および図２７を、主に、ユーザ・アプリケーション１９４０からＳＵＴ１９１０に向かうテスティング入力方向での位置ベースのスケジューリング（たとえば、ＳＵＴ１９１０に対するテストを開始するための）のサポートに関して本明細書で図示し、説明したが、位置ベースのスケジューリングのさまざまな機能を、ＳＵＴ１９１０からユーザ・アプリケーション１９４０に向かうテスティング出力方向での位置ベースのスケジューリング（たとえば、ＳＵＴ１９１０について開始されたテストの結果を受け取り、分析するための）をサポートするために反対の順序で実行できることを了解されたい。一実施形態では、たとえば、処理は、（１）ＴＩＳＡプロセッサ１９２０が、ＴＤＯを介してＳＵＴ１９１０からテスティング出力データを受け取り、ＳＵＴ１９１０に供給されるテスティング入力データを作るためにＴＩＳＡプロセッサ１９２０によって処理されたＴＩＳＡ動作に関連するテスティング出力結果を作るためにテスティング出力データを処理し、テスティング出力結果をスケジューラ１９３０に向かって伝搬させ、（２）スケジューラ１９３０が、ＴＩＳＡプロセッサ１９２０からテスティング出力結果を受け取り、テスティング出力結果をユーザ・アプリケーション１９４０に向かって伝搬させ、（３）ユーザ・アプリケーション１９４０が、スケジューラ１９３０からテスティング出力結果を受け取り、テスティング出力結果を処理する（たとえば、ＳＵＴ１９１０について開始されたテストの結果を分析するために）、のように進行することができる。
【０４４４】
明瞭にするために省略されているが、スケジューラ実行アーキテクチャ２６００のさまざまな要素の間の通信を、任意の適切な形で実行できることに留意されたい。多くのそのような実施形態は、図１９に示され、これに関して説明される。ＴＩＳＡプロセッサ１９２０およびスケジューラ１９３０が別々のデバイスとして実施されるスケジューラ実行アーキテクチャ２６００の場合に、ＴＩＳＡプロセッサ１９２０とスケジューラ１９３０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができることに留意されたい。
【０４４５】
主に、スケジューラ１９３０が、ＴＩＳＡプロセッサ１９２０とは別々に実施され、ＴＩＳＡプロセッサ１９２０が、ＳＵＴ１９１０とは別々に実施される実施形態に関して図示され、説明されたが、スケジューラ実行アーキテクチャを、さまざまな他の形で実施できることに留意されたい。一実施形態では、たとえば、スケジューラ１９３０を、ＴＩＳＡプロセッサ１９２０に組み込むことができる。一実施形態では、たとえば、ＴＩＳＡプロセッサ１９２０およびスケジューラ１９３０を、ＳＵＴ１９１０内に組み込むことができる。さまざまな他の配置が企図されている。
【０４４６】
主に、スケジューラがテスト動作の発行を可能にする時にテスト動作が発行される実施形態に関して図示され、説明されたが、一実施形態では、テスト動作の発行を、遅延スケジューリング能力を使用して遅延させることができる。
【０４４７】
図２８に、テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成された遅延スケジューラ実行アーキテクチャの一実施形態を示す図である。
【０４４８】
図２８に示されているように、遅延スケジューラ実行アーキテクチャ２８００は、図１９に示され、これに関して説明されたスケジューラ実行アーキテクチャ１９００の変更されたバージョンである。
【０４４９】
遅延スケジューラ実行アーキテクチャ２８００は、ＳＵＴ１９１０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を含み、これらのそれぞれを、図１９のスケジューラ実行アーキテクチャ１９００の実施形態に関して図示され、説明されたように機能するように構成することができる。遅延スケジューラ実行アーキテクチャ２８００は、遅延スケジューリング・モジュール２８０１をも含む。遅延スケジューリング・モジュール２８０１は、ＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、ベクトル変換モジュール２８３０、およびＪＴＡＧのＴＡＰ２８４０を含む。ＴＩＳＡモジュール２８１０は、ユーザ・アプリケーション１９４０とリオーダリング・バッファ・モジュール２８２０との間に配置される。リオーダリング・バッファ・モジュール２８２０は、ＴＩＳＡモジュール２８１０とベクトル変換モジュール２８３０との間に配置される。ベクトル変換モジュール２８３０は、リオーダリング・バッファ・モジュール２８２０とＪＴＡＧのＴＡＰ２８４０との間に配置される。ＪＴＡＧのＴＡＰ２８４０は、ベクトル変換モジュール２８３０とＳＵＴ１９１０（または、オプションで、他のタイプの動作を実行するように構成され得る１つまたは複数の追加のモジュール）との間に配置される。
【０４５０】
遅延スケジューリング・モジュール２８０１、より具体的にはＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、およびベクトル変換モジュール２８３０を、ハードウェアおよび／またはソフトウェアを使用して実施できることに留意されたい。
【０４５１】
一実施形態では、たとえば、ＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、およびベクトル変換モジュール２８３０を、ハードウェアで（たとえば、１つまたは複数のハードウェア・コンポーネントを使用して）実施することができる。
【０４５２】
一実施形態では、たとえば、ＴＩＳＡモジュール２８１０およびリオーダリング・バッファ・モジュール２８２０は、ソフトウェアで（たとえば、１つまたは複数のプロセッサまたは他の適切なハードウェア上で動作するように構成された１つまたは複数のソフトウェア・モジュールとして）実施され、ベクトル変換モジュール２８３０は、ハードウェアで（たとえば、１つまたは複数のハードウェア・コンポーネントを使用して）実施される。
【０４５３】
一実施形態では、たとえば、ＴＩＳＡモジュール２８１０は、ソフトウェアで（たとえば、１つまたは複数のプロセッサまたは他の適切なハードウェア上で動作するように構成された１つまたは複数のソフトウェア・モジュールとして）実施され、リオーダリング・バッファ・モジュール２８２０およびベクトル変換モジュール２８３０は、ハードウェアで（たとえば、１つまたは複数のハードウェア・コンポーネントを使用して）実施される。
【０４５４】
一実施形態では、たとえば、ＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、およびベクトル変換モジュール２８３０は、すべてが、ソフトウェアで（たとえば、１つまたは複数のプロセッサまたは他の適切なハードウェア上で動作するように構成された１つまたは複数のソフトウェア・モジュールとして）実施される。
【０４５５】
少なくともいくつかの実装形態では、上で示したように、ＴＩＳＡモジュール２８１０を、純ソフトウェアＴＩＳＡとして実施することができる。１つのそのような実施形態では、ＴＩＳＡモジュール２８１０は、伝統的なベクトルＪＴＡＧインターフェースを介してＳＵＴ１９１０にアクセスするように構成された純ソフトウェアＴＩＳＡとして実施される。少なくとも、伝統的なベクトルＪＴＡＧインターフェースを有する純ソフトウェアＴＩＳＡの実装形態が、伝統的なＪＴＡＧインターフェースを介して入力ベクトルを送り、出力ベクトルを受け取ることが可能になるように、ＴＩＳＡ動作からのベクトル全体の再構成を使用するので、遅延スケジューラ実行アーキテクチャ２８００の使用が、そのような実施形態を可能にすることに留意されたい。この形で、ＪＴＡＧのＴＡＰが伝統的なＪＴＡＧのＴＡＰ（ＴＡＰ  ＴＣＫ信号のゲーティングをサポートするゲート処理されたＴＣＫアプリケーションまたはゲート処理されたＴＣＫのＴＡＰコントローラを含む可能性があるＴＩＳＡ用に設計されたＴＡＰではなく）である場合であっても、図１９〜図２７に示し、これらに関して本明細書で説明したＴＩＳＡスケジューリングを使用することができる。
【０４５６】
ＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、およびベクトル変換モジュール２８３０を、任意の適切な形でハードウェアおよび／またはソフトウェアを使用して実施できることに留意されたい。
【０４５７】
ＳＵＴ１９１０に向かう方向で、ＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、およびベクトル変換モジュール２８３０は、ＴＩＳＡモジュール２８１０で受け取られたＴＩＳＡ動作を、ＳＵＴ１９１０のスキャン・チェーンの完全な入力テスト・ベクトルとしてＳＵＴに適用することを可能にする機能を実行するように構成されている。ＴＩＳＡモジュール２８１０は、ＳＵＴ１９１０の入力テスト・データ（たとえば、入力テスト・データ・ビット）を決定するためにＴＩＳＡ動作を実行し、入力テスト・データをリオーダリング・バッファ・モジュール２８２０に供給するように構成されている。リオーダリング・バッファ・モジュール２８２０は、ＴＩＳＡモジュール２８１０から入力テスト・データを受け取り、ＳＵＴ１９１０のスキャン・チェーンの完全な入力テスト・ベクトルを形成するために入力テスト・データのリオーダリングを可能にする形で入力データをバッファリングし、完全な入力テスト・ベクトルの入力テスト・データをベクトル変換モジュール２８３０に供給するように構成されている。ベクトル変換モジュール２８３０は、リオーダリング・バッファ・モジュール２８２０から完全な入力テスト・ベクトルの入力テスト・データを受け取り、ＪＴＡＧのＴＡＰ２８４０による使用のために完全な入力テスト・ベクトルの入力テスト・データを変換し、変換された入力テスト・ベクトルの入力テスト・データ（たとえば、入力テスト・データ・ビット）をＪＴＡＧのＴＡＰ２８４０に供給するように構成されている。
【０４５８】
ＳＵＴ１９１０からの方向では、ベクトル変換モジュール２８３０、リオーダリング・バッファ・モジュール２８２０、およびＴＩＳＡモジュール２８１０は、ＳＵＴ１９１０のスキャン・チェーンから受け取られた出力テスト・ベクトルを、ＳＵＴ１９１０のスキャン・チェーンに適用された関連する入力テスト・ベクトルのＴＩＳＡ動作に戻ってマッピングすることを可能にする機能を実行するように構成されている。ベクトル変換モジュール２８３０は、ＪＴＡＧのＴＡＰ２８４０から出力テスト・データ（たとえば、出力テスト・データ・ビット）を含む出力テスト・ベクトルを受け取り、変換された出力テスト・データを含む変換された出力テスト・ベクトルを供給するために出力テスト・ベクトルにベクトル変換を適用し、変換された出力テスト・ベクトルの変換された出力テスト・データをリオーダリング・バッファ・モジュール２８２０に供給するように構成されている。リオーダリング・バッファ・モジュール２８２０は、ベクトル変換モジュール２８３０から変換された出力テスト・ベクトルの変換された出力テスト・データを受け取り、ＳＵＴ１９１０のスキャン・チェーンの完全な出力ベクトルを形成するために、変換された出力テスト・データを表す変換された出力テスト・データをバッファ内に保存し、変換された出力テスト・データを、対応するセグメントの位置および長さに対応するバッファリングされたセグメントに区分し、変換された出力テスト・データをＴＩＳＡモジュール２８１０に供給するように構成されている。リオーダリング・バッファ・モジュール２８２０内で表されるテスト・データ・セグメントのそれぞれが、ユーザ・アプリケーション（この例示的実施形態では、ユーザ・アプリケーション１９４０）によって要求されたスキャン・セグメントを表すことに留意されたい。ＴＩＳＡモジュール２８１０は、リオーダリング・バッファ・モジュール２８２０から変換された出力テスト・データを受け取り、変換された出力テスト・データを、関連する出力テスト・データが要求されたＴＩＳＡ動作にマッピングし、それぞれのＴＩＳＡ動作を実行する関連するユーザ・アプリケーション（１つまたは複数）（やはり、この例示的実施形態では、ユーザ・アプリケーション１９４０）を決定し、供給すべきテスト結果データをユーザ・アプリケーション（１つまたは複数）に供給する（たとえば、ＴＩＳＡモジュール２８１０がユーザ・アプリケーション１９４０と直接に相互作用する場合には直接に、または、ＴＩＳＡモジュール２８１０がスケジューラ１９３０と相互作用し、スケジューラがユーザ・アプリケーション１９４０と相互作用する場合にはスケジューラを介して）ように構成されている。アクセス要求が複数のユーザ・アプリケーションによって発行され、したがって、複数のユーザ・アプリケーションのＴＩＳＡ動作の発行をもたらす場合には、ユーザ・アプリケーションが、テスト結果データのうちでそのユーザ・アプリケーションがそれぞれ開始したＴＩＳＡ動作に関連する部分を受け取るように、テスト結果データは、ユーザ・アプリケーションのＴＩＳＡ動作にマッピングされる。
【０４５９】
明瞭にするために省略されているが、ＳＵＴ１９１０に関連する回路モデル１９３４が、そのルートとしてベクトル変換モジュールを含むように変更されることに留意されたい。図２１に示されているように、回路モデル２１２０は、「ＳＵＴ」ノードの上に親ノードを含むはずであり、その親ノードは、ベクトル変換モジュール２８３０を表す。
【０４６０】
遅延スケジューラ実行アーキテクチャ２８００を介するものなどの遅延スケジューリングの使用が、関連するスキャン・セグメントからのスキャン・チェーン全体の再構成を可能にし、これによって、さまざまなタイプの動作をＳＵＴ１９１０のスキャン・チェーン全体に対して実行することを可能にする（たとえば、スクランブリング、およびオーバースキャン・ベクトル動作など、ならびにそのさまざまな組合せ）ことに留意されたい。たとえば、オーバースキャン・ベクトルでは、１つまたは複数の追加ビットが、スキャン・ベクトル入力に追加され、したがって、スキャン・ベクトル出力の一部として受け取られ、スキャン・ベクトル出力から除去されなければならず（すなわち、このケースでは、スキャン・ベクトルの入力および出力が直接の１：１関係ではない）、遅延スケジューラ実行アーキテクチャ２８００の使用は、シフトされるスキャン・ベクトルのビットの再整列が、このタイプのビット・パディングを考慮に入れることを可能にする。
【０４６１】
遅延スケジューラ実行アーキテクチャ２８００を介するものなど、遅延スケジューリングの使用が、ＴＣＫのゲーティングがサポートされないか使用可能でない場合であってもＴＩＳＡまたはＴＩＳＡ様のテスト命令セット・アーキテクチャの使用を可能にすることに留意されたい。
【０４６２】
主に、本明細書では図１９に示され、これに関して説明されたスケジューラ実行アーキテクチャ１９００の変更されたバージョンである遅延スケジューラ実行アーキテクチャの実施形態に関して図示され、説明されるが、遅延スケジューラ実行を、図２６のスケジューラ実行アーキテクチャ２６００と共に使用することもできることに留意されたい。この実施形態では、遅延スケジューリング・モジュール２８０１は、ユーザ・アプリケーション１９４０とＪＴＡＧのＴＡＰ２８４０との間ではなく、スケジューラ１９３０とＪＴＡＧのＴＡＰ２８４０との間に配置されるはずである。
【０４６３】
明瞭にするために省略されているが、遅延スケジューラ実行アーキテクチャ２８００のさまざまな要素を、１つまたは複数のデバイスを使用して実施することができ、同様に、遅延スケジューラ実行アーキテクチャ２８００のさまざまな要素の間の通信を、任意の適切な形で（たとえば、使用されるデバイスの個数、およびデバイスの位置などに依存する）実行できることに留意されたい。
【０４６４】
遅延スケジューラ実行アーキテクチャ２８００のさまざまな要素を、ハードウェアおよび／またはソフトウェアを使用して実施できることに留意されたい。たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、それぞれ、ハードウェアでまたは、１つもしくは複数のメモリに格納され、１つもしくは複数のプロセッサ（たとえば、ＴＩＳＡモジュール２８１０ならびに／またはＴＩＳＡモジュール２８１０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０の位置に依存するものとすることができる任意の他の適切なプロセッサ（１つまたは複数））による実行のために構成されたソフトウェアベースのモジュールとして、実施することができる。スケジューラ１９３０、ユーザ・アプリケーション１９４０、およびＴＩＳＡモジュール２８１０（たとえば、図１９のＴＩＳＡプロセッサ１９２０）に関する多数のそのような実施形態が、図１９に示され、これに関して説明される。同様に、たとえば、本明細書に上で説明したように、遅延スケジューリング・モジュール２８０１を、ハードウェアおよび／またはソフトウェア（ハードウェアおよび／またはソフトウェアでの遅延スケジューリング・モジュール２８０１の要素のそれぞれの実装形態を含むことができる）で実施することができる。
【０４６５】
遅延スケジューリング・モジュール２８０１を、ＪＴＡＧのＴＡＰ２８４０と同一位置に配置し、ユーザ・アプリケーション１９４０から分離することができ、ユーザ・アプリケーション１９４０と同一位置に配置し、ＪＴＡＧのＴＡＰ２８４０から分離することができ、ＪＴＡＧのＴＡＰ２８４０およびユーザ・アプリケーション１９４０と同一位置に配置することができ（スケジューラ１９３０と同一位置またはこれとは別々）、あるいは、ＪＴＡＧのＴＡＰ２８４０とユーザ・アプリケーション１９４０との両方から分離することができることに留意されたい。そのような配置が、図１９に示され、これに関して説明されたＴＩＳＡモジュール２８１０（たとえば、ＴＩＳＡプロセッサ１９２０）、スケジューラ１９３０、およびユーザ・アプリケーション１９４０のさまざまな配置に加えられるものであることに留意されたい。そのような実施形態では、遅延スケジューリング・モジュール２８０１とＪＴＡＧのＴＡＰ２８４０との間、遅延スケジューリング・モジュール２８０１とユーザ・アプリケーション１９４０との間（たとえば、遅延スケジューラ実行アーキテクチャ２８００が、ユーザ・アプリケーション１９４０がＪＴＡＧのＴＡＰ２８４０にＴＩＳＡ動作を供給するように構成されているスケジューラ実行アーキテクチャ１９００の変更されたバージョンとして実施される場合）、および遅延スケジューリング・モジュール２８０１とスケジューラ１９３０との間（たとえば、遅延スケジューラ実行アーキテクチャ２８００が、スケジューラ１９３０がＪＴＡＧのＴＡＰ２８４０にＴＩＳＡ動作を供給するように構成されているスケジューラ実行アーキテクチャ２６００の変更されたバージョンとして実施される場合）の通信を、任意の適切な形で（たとえば、直接通信を使用して、および１つまたは複数の通信ネットワークを介する通信を使用してなど）提供することができる。
【０４６６】
一実施形態では、たとえば、遅延スケジューリング・モジュール２８０１、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を、１つまたは複数の通信ネットワークを介して（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介して）お互いと通信することができる別々のデバイス内で実施することができる。
【０４６７】
一実施形態では、たとえば、遅延スケジューリング・モジュール２８０１およびスケジューラ１９３０を、単一のデバイス内で同一位置に配置することができ、ユーザ・アプリケーション１９４０を、別々のデバイス内で実施することができる。たとえば、スケジューラ１９３０を、図示され本明細書で説明されるさまざまな機能を提供するためにスケジューラ１９３０を実行するように構成された１つまたは複数のプロセッサ（たとえば、ＴＩＳＡモジュール２８１０および／または１つまたは複数の他のプロセッサ）からアクセス可能な１つまたは複数のメモリに格納されたソフトウェアベースのモジュールとすることができる。たとえば、ユーザ・アプリケーション１９４０を、ハードウェアで、または、１つもしくは複数のメモリに格納され、図示され本明細書で説明されるさまざまな機能を提供するための１つもしくは複数のプロセッサによる実行のために構成されたソフトウェアベースのモジュールとして、実施することができる。たとえば、スケジューラ１９３０とユーザ・アプリケーション１９４０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができる。
【０４６８】
一実施形態では、たとえば、遅延スケジューリング・モジュール２８０１およびユーザ・アプリケーション１９４０を、単一のデバイス内で同一位置に配置することができ、スケジューラ１９３０を、別々のデバイス内で実施することができる。たとえば、ユーザ・アプリケーション１９４０を、図示され本明細書で説明されるさまざまな機能を提供するためにユーザ・アプリケーション１９４０を実行するように構成された１つまたは複数のプロセッサ（たとえば、ＴＩＳＡモジュール２８１０および／または１つまたは複数の他のプロセッサ）からアクセス可能な１つまたは複数のメモリに格納されたソフトウェアベースのモジュールとすることができる。たとえば、スケジューラ１９３０を、ハードウェアで、または、１つもしくは複数のメモリに格納され、図示され本明細書で説明されるさまざまな機能を提供するための１つもしくは複数のプロセッサによる実行のために構成されたソフトウェアベースのモジュールとして、実施することができる。たとえば、ユーザ・アプリケーション１９４０とスケジューラ１９３０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができる。
【０４６９】
一実施形態では、たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、単一のデバイス内で同一位置に配置することができ、遅延スケジューリング・モジュール２８０１を、別々のデバイスとして実施することができる。たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、それぞれ、ハードウェアで、または、１つもしくは複数のメモリに格納され、図示され本明細書で説明されるさまざまな機能を提供するための１つもしくは複数のプロセッサによる実行のために構成されたソフトウェアベースのモジュールとして、実施することができる。たとえば、ユーザ・アプリケーション１９４０とＴＩＳＡモジュール２８１０との間の通信を、１つまたは複数の通信ネットワークを介する（たとえば、イーサネット・ネットワーク、およびインターネットなど、ならびにそのさまざまな組合せを介する）ものとすることができる。
【０４７０】
一実施形態では、たとえば、遅延スケジューリング・モジュール２８０１、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を、単一のデバイス内で同一位置に配置することができる。たとえば、ＴＩＳＡプロセッサ１９２０、スケジューラ１９３０、およびユーザ・アプリケーション１９４０を、１つまたは複数のメモリに格納され、１つまたは複数のプロセッサ上で実行されるソフトウェアベースのモジュールとすることができる。たとえば、スケジューラ１９３０およびユーザ・アプリケーション１９４０を、図示され本明細書で説明されるさまざまな機能を提供するためにスケジューラ１９３０およびユーザ・アプリケーション１９４０にアクセスし、実行することができる１つまたは複数のプロセッサからアクセス可能な１つまたは複数のメモリに格納されたソフトウェアベースのモジュールとすることができる。たとえば、ＴＩＳＡモジュール２８１０を、ＴＩＳＡプロセッサ（たとえば、ＴＩＳＡプロセッサ１９２０）の動作をエミュレートするＩＳＡ命令のライブラリを動作させるアプリケーションとすることができ、これによって、ＳＵＴへの実際の書込みおよび読取りが、その後にＳＵＴに統一されたベクトルとして適用するためにベクトル・データをリオーダリング・バッファ・モジュール２８２０に配置することによって延期される。例示的な実施形態を、図２９に示し、これに関して説明する。
【０４７１】
図２９に、テストされるシステムをテストするための位置ベースのスケジューリングを提供するように構成された遅延スケジューラ実行アーキテクチャの一実施形態を示す。
【０４７２】
図２９に示されているように、遅延スケジューラ実行アーキテクチャ２９００は、図２８の遅延スケジューラ実行アーキテクチャ２８００に類似する（かつ、図１９のスケジューラ実行アーキテクチャ１９００の例示的実施形態を示す図２３のスケジューラ実行アーキテクチャ２３００の変更されたバージョンでもある）。
【０４７３】
遅延スケジューラ実行アーキテクチャ２９００は、図２８の遅延スケジューラ実行アーキテクチャ２８００の実施形態（実例として、遅延スケジューラ実行アーキテクチャ２８００がソフトウェアで実施される例示的実施形態）をサポートするためのメインＣＰＵ２３２０およびメモリ２３２４に対する変更を含む、図２３のスケジューラ実行アーキテクチャ２３００のＳＵＴ２３１０、メインＣＰＵ２３２０、およびメモリ２３２４を含む。
【０４７４】
メモリ２３２４は、図２３のスケジューラ実行アーキテクチャ２３００のスケジューラ２３３０およびユーザ・アプリケーション２３４０を含むことに加えて、遅延スケジューリング・モジュール２９０１をも含む。遅延スケジューリング・モジュール２９０１は、それぞれ図２８の遅延スケジューラ実行アーキテクチャ２８００のＴＩＳＡモジュール２８１０、リオーダリング・バッファ・モジュール２８２０、およびベクトル変換モジュール２８３０のソフトウェアベースの実装形態であるＴＩＳＡモジュール２９１０、リオーダリング・バッファ・モジュール２９２０、およびベクトル変換モジュール２９３０を含む。
【０４７５】
図２３のスケジューラ実行アーキテクチャ２３００のＴＩＳＡ２３２２ではなくメインＣＰＵ２３２０が（ＴＩＳＡ処理がメモリ２３２４の遅延スケジューリング・モジュール２９０１のＴＩＳＡモジュール２９１０によって提供されるので）、図２８の遅延スケジューラ実行アーキテクチャ２８００のＪＴＡＧのＴＡＰ２８４０に対応するＪＴＡＧのＴＡＰ２９４０を含む。
【０４７６】
図２９は、主に、遅延スケジューリング能力がソフトウェア内で実施される実施形態に関して図示され、本明細書で説明されるが、（図２８の遅延スケジューラ実行アーキテクチャ２８００に関して図示され、説明されるように）遅延スケジューリング能力を、ハードウェアおよび／またはソフトウェアを使用して実施できることを了解されたい。一実施形態では、たとえば、ベクトル変換モジュール２９３０を、メモリ２３２４の外部のハードウェア・モジュールとして実施することができ、リオーダリング・バッファ２９２０およびＴＩＳＡモジュール２９１０を、ソフトウェアを使用して実施することができ、したがって、メモリ２３２４内に格納することができる。一実施形態では、たとえば、ベクトル変換モジュール２９３０およびリオーダリング・バッファ２９２０を、メモリ２３２４の外部の１つまたは複数のハードウェア・モジュールとして実施することができ、ＴＩＳＡモジュール２９１０を、ソフトウェアを使用して実施することができ、したがって、メモリ２３２４内に格納することができる。さまざまな他の配置が企図されている。
【０４７７】
主に、遅延スケジューラ実行アーキテクチャが、図１９のスケジューラ実行アーキテクチャ１９００（ユーザ・アプリケーション１９４０が、ＴＩＳＡプロセッサ１９２０と相互作用する）に基づいて実施される実施形態に関して図示され、本明細書で説明されるが、遅延スケジューラ実行アーキテクチャを、図２６のスケジューラ実行アーキテクチャ２６００（スケジューラ１９３０が、ＴＩＳＡプロセッサ１９２０／ＴＩＳＡモジュール２８１０と相互作用する）に基づいて実施することもできることに留意されたい。この後者の解決策は、ＴＩＳＡ動作の単一の発生点（すなわち、スケジューラ１９３０）を表すという利益を有し、ＴＩＳＡモジュール２８１０またはＴＩＳＡモジュール２９１０とのインターフェースおよび同期化をはるかに簡単にする。
【０４７８】
主に、遅延スケジューリング能力が、図示され本明細書で説明されるスケジューラ実行アーキテクチャおよび環境に関連して提供される実施形態に関して図示され、本明細書で説明されるが、遅延スケジューリング能力を、任意の他の適切なタイプのスケジューリングベースのテスティング・アーキテクチャおよび環境に関連して提供することができることに留意されたい。
【０４７９】
図示され本明細書で説明される位置ベースのスケジューリングの実施形態の多くでは、ＳＵＴのスキャン・チェーンのスキャン・セグメントのそれぞれが、アプリケーションを割り当てられ、このアプリケーション（１つまたは複数）が、スキャン・チェーン全体を取り込むのに十分なテスト・データを提供するようになっているとい仮定する。しかし、多くの場合に、位置ベースのスケジューリングを使用してテストが実行される時に、スキャン・チェーンがそれから構成されるセグメントのうちの１つまたは複数が、アプリケーションを全く割り当てられていない可能性がある。この場合に、データは、それでも、スキャン・チェーンのこれらの未使用のセグメントについて供給される必要がある。言い替えると、アプリケーションが、セグメントの更新を特に要求しておらず、セグメントが、アプリケーションの割り振られたセグメントと直列である場合には、スキャン・チェーン・スキャン全体が、それでも、スキャン・チェーン内のこれらのギャップに関連するデータを有することを必要とする。これは、複数の形で処理することができる。
【０４８０】
一実施形態では、たとえば、スケジューラは、未使用セグメントを充填するためにデータを供給できるように、スキャン・チェーンの各セグメントに関するデフォルト・データ（たとえば、ＴＩＳＡ動作）を含む（または、少なくともそれへのアクセスを有する）。
【０４８１】
一実施形態では、たとえば、スキャン・チェーンの割り振られていないスキャン・セグメントを処理するように構成されたアプリケーションは、完全なスキャン・ベクトルを生成できるように、割り振られていないセグメントにデータを供給するためにスケジューラと連繋する。ＴＩＳＡが、任意の所与のアプリケーションがスキャン・チェーン全体ではなくスキャン・チェーンのサブセット（たとえば、スキャン・チェーンがそれから構成される１つまたは複数のターゲット・セグメント）だけに焦点を合わせることを可能にする場合であっても、スキャン・シーケンス全体を完了するためにスキャン・チェーンのすべてのセグメントがスキャンされることを１１４９．１のＪＴＡＧ標準規格が要求するので、スキャン・チェーンの各セグメント（割り振られていないセグメントを含む）にデータを供給するそのような能力が、ＴＩＳＡベースの実装形態の場合に特に関連することに留意されたい。一実施形態では、スケジューラが、スキャン・チェーン全体のトポロジを知っているので、この能力を、スケジューラからの肯定応答の一部として含めることができる。
【０４８２】
主に、ＴＩＳＡ（および関連するＴＩＳＡ動作）を使用するテスティング・アーキテクチャでの位置ベースのスケジューリングの提供の文脈で図示され、本明細書で説明されるが、位置ベースのスケジューリングのさまざまな実施形態を、他のタイプのテスト命令セット（および他のタイプの関連するテスト動作）を使用するテスティング・アーキテクチャで提供できることに留意されたい。同様に、主に、ＴＩＳＡ（および関連するＴＩＳＡ動作）を使用するテスティング・アーキテクチャでの遅延スケジューリングの提供の文脈で図示され、本明細書で説明されるが、遅延スケジューリングのさまざまな実施形態を、他のタイプのテスト命令セット（および他のタイプの関連するテスト動作）を使用するテスティング・アーキテクチャで提供できることに留意されたい。
【０４８３】
図３０に、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。図３０に示されているように、コンピュータ３０００は、プロセッサ要素３００２（たとえば、中央処理装置（ＣＰＵ）または他の適切なプロセッサ（１つまたは複数））、メモリ３００４（たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、および／または任意の他の適切なタイプのメモリ）、図示され本明細書で説明されるシステム・テスティング能力を実行するように適合されたシステム・テスティング・モジュール／プロセス３００５、およびさまざまな入出力デバイス３００６（たとえば、ユーザ入力デバイス（キーボード、キーパッド、およびマウスなど）、ユーザ出力デバイス（ディスプレイ、およびスピーカなど）、入力ポート、出力ポート、レシーバ、トランスミッタ、およびストレージ・デバイス（たとえば、テープ・ドライブ、フロッピ・ドライブ、ハード・ディスク・ドライブ、およびコンパクト・ディスク・ドライブなど））を含む。
【０４８４】
図示され本明細書で説明されるシステム・テスティング能力を、ソフトウェアならびに／あるいはソフトウェアおよびハードウェアの組合せで、たとえば、汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または任意の他のハードウェア同等物を使用して、実施できることに留意されたい。一実施形態では、システム・テスティング・プロセス３００５を、メモリ３００４にロードし、プロセッサ３００２によって実行して、上で説明したシステム・テスティング能力の少なくとも一部を実施し、かつ／またはその実装形態をサポートすることができる。したがって、システム・テスティング・プロセス３００５（関連するデータ構造を含む）を、コンピュータ可読記憶媒体または担体、たとえば、ＲＡＭメモリ、磁気ドライブ、磁気ディスケット、光ドライブ、および光ディスケットなどに格納することができる。
【０４８５】
本明細書でソフトウェア方法として論じたステップのうちのいくつかを、ハードウェア内で、たとえばさまざまな方法ステップを実行するためにプロセッサと協力する回路網内で実施できることが企図されている。本明細書で説明された機能／要素の諸部分を、コンピュータ・プログラム製品として実施することができ、ここで、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および／または技法が呼び出されるか他の形で提供されるように、コンピュータの動作を適合させる。本発明的方法を呼び出す命令を、固定媒体または取外し可能媒体に格納し、放送媒体または他の信号担持媒体内のデータ・ストリームを介して伝送し、かつ／または命令に従って動作するコンピューティング・デバイス内のメモリ内に格納することができる。
【０４８６】
さまざまな実施形態の態様は、特許請求の範囲で指定される。さまざまな実施形態のこれらおよび他の態様は、以下の番号付きの条項で指定される。
【図１】
2015507743.tif 000003
【図２】
2015507743.tif 000004
【図３】
2015507743.tif 000005
【図４Ａ】
2015507743.tif 000006
【図４Ｂ】
2015507743.tif 000007
【図４Ｃ】
2015507743.tif 000008
【図４Ｄ】
2015507743.tif 000009
【図４Ｅ】
2015507743.tif 000010
【図５Ａ】
2015507743.tif 000011
【図５Ｂ】
2015507743.tif 000012
【図６】
2015507743.tif 000013
【図７】
2015507743.tif 000014
【図８】
2015507743.tif 000015
【図９】
2015507743.tif 000016
【図１０】
2015507743.tif 000017
【図１１Ａ】
2015507743.tif 000018
【図１１Ｂ】
2015507743.tif 000019
【図１２】
2015507743.tif 000020
【図１３】
2015507743.tif 000021
【図１４】
2015507743.tif 000022
【図１５】
2015507743.tif 000023
【図１６】
2015507743.tif 000024
【図１７】
2015507743.tif 000025
【図１８】
2015507743.tif 000026
【図１９】
2015507743.tif 000027
【図２０】
2015507743.tif 000028
【図２１】
2015507743.tif 000029
【図２２】
2015507743.tif 000030
【図２３】
2015507743.tif 000031
【図２４】
2015507743.tif 000032
【図２５】
2015507743.tif 000033
【図２６】
2015507743.tif 000034
【図２７】
2015507743.tif 000035
【図２８】
2015507743.tif 000036
【図２９】
2015507743.tif 000037
【図３０】
2015507743.tif 000038
【国際調査報告】
2015507743.tif 000039
2015507743.tif 000040