"インサーキットエミュレーションICEを使用してターゲットハードウェアの1つまたは複数のコンポーネントをテストする際に使用される方法であって、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャンセグメント動作を受け取るステップであって、前記複数のターゲットICEコントローラは、前記ターゲットハードウェアの複数のコンポーネントに関連する、ステップと、前記ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、前記受け取られたスキャンセグメント動作をスケジューリングするステップであって、これによってスキャンセグメント動作のスケジューリングされたセットを形成するステップと、前記ターゲットハードウェアの1つまたは1つまたは複数のコンポーネントをテストするためにスキャンセグメント動作の前記スケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作の前記スケジューリングされたセットを伝搬させるステップとを含む方法。前記受け取られたスキャンセグメント動作のうちの少なくとも1つについて、前記受け取られたスキャンセグメント動作は、前記少なくとも1つのICEホストのターゲットICEコントローラによって生成され、前記ターゲットハードウェア上のプロセッサコアのためのものである、請求項1に記載の方法。前記受け取られたスキャンセグメント動作のうちの少なくとも1つについて、前記受け取られたスキャンセグメント動作は、前記少なくとも1つのICEホストのアプリケーションによって生成され、前記ターゲットハードウェア上の特定用途向け集積回路ASICの少なくとも1つのプロセッサコアのためのものである、請求項1に記載の方法。前記方法は、待ち行列付き状態機械によって実行され、前記待ち行列付き状態機械は、イベントループ、コマンドハンドラ、および回路制御モデルを含み、前記イベントループは、前記ターゲットICEコントローラによって生成された前記スキャンセグメント動作を受け取り、前記スキャンセグメント動作を前記コマンドハンドラに提供するように構成され、前記コマンドハンドラは、前記イベントループから前記スキャンセグメント動作を受け取り、前記スキャンセグメント動作を前記回路モデルに提供するように構成され、前記回路制御モデルは、スキャンセグメント動作の前記スケジューリングされたセットを作るように構成される請求項1に記載の方法。スキャンセグメント動作の前記スケジューリングされたセットは、回路制御モデルを使用して作られる、請求項1に記載の方法。前記回路制御モデルは、前記ターゲットICEコントローラに関連する複数の回路モデルの回路モデル情報と、前記ターゲットハードウェアのスキャントポロジをモデル化するスキャントポロジ情報であって、前記回路制御モデルは、前記スキャントポロジ情報を使用してスキャンセグメント動作の前記スケジューリングされたセットを作る、スキャントポロジ情報とを含む、請求項5に記載の方法。前記受け取られたスキャンセグメント動作のそれぞれについて、前記回路制御モデルは、前記スキャンセグメント動作の所期の宛先であって前記ターゲットハードウェアの前記コンポーネントのうちの1つである所期の宛先を認識するために、前記スキャンセグメント動作を処理し、前記回路制御モデルのうちで前記スキャンセグメント動作の前記所期の宛先に関連する部分に前記スキャンセグメント動作を委譲する請求項5に記載の方法。前記複数のターゲットICEコントローラは、単一のICEホストに関連し、前記プロセッサは、第1プロセッサであり、前記単一のICEホストは、第2プロセッサを含み、前記第2プロセッサは、中央処理装置CPUとして動作し、前記第1プロセッサは、前記第2プロセッサのスキャンセグメント動作の前記スケジューリングされたセットを処理するためのコプロセッサとして動作する、請求項1に記載の方法。ターゲットハードウェアの1つまたは複数のコンポーネントをテストする際に使用される装置であって、少なくとも1つのICEホストの複数のターゲットICEマネージャによって生成されたスキャンセグメント動作を受け取ることであって、前記複数のターゲットICEマネージャは、前記ターゲットハードウェアの複数のコンポーネントに関連する、受け取ることと、前記ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、前記受け取られたスキャンセグメント動作をスケジューリングすることと、前記ターゲットハードウェアの1つまたは複数のデバイスをテストするためにスキャンセグメント動作の前記スケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作の前記スケジューリングされたセットを伝搬させることとを行うように構成された待ち行列付き状態機械を含む装置。プロセッサによって実行された時に、前記プロセッサに、インサーキットエミュレーションICEを使用してターゲットハードウェアの1つまたは複数のコンポーネントをテストする際に使用される方法を実行させる命令を格納したコンピュータ可読記憶媒体であって、前記方法は、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャンセグメント動作を受け取るステップであって、前記複数のターゲットICEコントローラは、前記ターゲットハードウェアの複数のコンポーネントに関連する、ステップと、前記ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、前記受け取られたスキャンセグメント動作をスケジューリングするステップであって、これによってスキャンセグメント動作のスケジューリングされたセットを形成するステップと、前記ターゲットハードウェアの1つまたは1つまたは複数のコンポーネントをテストするためにスキャンセグメント動作の前記スケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作の前記スケジューリングされたセットを伝搬させるステップとを含む、コンピュータ可読記憶媒体。従来技術のさまざまな不足は、仮想インサーキットエミュレーションICEを提供する方法および装置を介して対処される。一実施形態では、方法は、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャンセグメント動作を受け取るステップであって、複数のターゲットICEコントローラは、ターゲットハードウェアの複数のコンポーネントに関連する、ステップと、ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、受け取られたスキャンセグメント動作をスケジューリングするステップであって、これによってスキャンセグメント動作のスケジューリングされたセットを形成するステップと、ターゲットハードウェアの1つまたは複数のコンポーネントをテストするためにスキャンセグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作のスケジューリングされたセットを伝搬させるステップとを含む。本明細書で提示される教示は、添付図面に関連して次の詳細な説明を検討することによってたやすく理解することができる。理解を容易にするために、可能な場合には、同一の符号が、複数の図面に共通する同一の要素を指定するのに使用された。さまざまなテスティング機能が、テストされるシステムSUTのテスティングを実行する際の使用のために提供される。一実施形態では、テスト命令セットアーキテクチャTISAが提供される。TISAは、システムテスティングを実行する際に使用するために提供される。TISAは、対話テスティング機能、リモートテスティング機能、および本明細書で説明するさまざまな他の機能を含む改善されたシステムテスティング機能を提供するために、コンピュータサイエンス機能をシステムテスティング機能と組み合わせる。TISAは、システムテスティング機能を使用してソフトウェアベースの命令セットアーキテクチャISAを適合させることによって形成される。ソフトウェアベースのISAは、任意の適切なソフトウェアプログラミング言語たとえば、C、Java、および類似物、ならびにそのさまざまな組合せを利用することができ、任意の適切なプロセッサを使用して実施され得る。システムテスティング機能は、IEEE1149.1JTAGとしても知られるTAPまたは任意の他の適切なTAPなどの任意の適切なTAPを利用することができる。一般に、TISAは、ソフトウェアプロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成される。TISAでは、テスト手順のアルゴリズム部分が、ソフトウェアフローによって処理され、テスト手順のアルゴリズム部分が原子的テスティング動作に変換されるようになっている。TISAは、ソフトウェアプロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成され、原子的テスティング動作が、テスト手順のアルゴリズム部分を処理しているソフトウェアプロセスの原子的動作と同一の形で扱われるようになっている。これは、組込みテスト実行、リモートテスト実行、および図示され本明細書で説明されるさまざまな他の改善されたシステムテスティング機能のより細粒度の制御を可能にする。図1に、テスティングシステムとテストされるシステムとを含むシステムテスティング環境の高水準ブロック図を示す。図1に示されているように、システムテスティング環境100は、テスティングシステムTS110およびテストされるシステムSUT120を含む。TS110は、SUT120をテストするのに適する任意のシステムとすることができる。TS110は、SUT120をテストするために構成される。TS110は、SUT120の任意のテスティング、たとえば、SUT120の1つまたは複数の個々のコンポーネント、SUT120のコンポーネントの1つまたは複数の組合せ、SUT120のコンポーネントの間の1つまたは複数の相互接続、SUT120の1つまたは複数のシステムレベル機能、および類似物、ならびにそのさまざまな組合せのテスティングを実行することができる。TS110は、テスト手順の実行、テストされるシステムへの入力データの供給、テストされるシステムからの出力データの受取、システムテスティング結果を判定するためのテストされるシステムから受け取られた出力データの処理、および同様の機能、ならびにそのさまざまな組合せなど、通常はテストされるシステムのテスティングに関連する機能のいずれをも実行することができる。テストされるシステムをテストするためのTS110の設計および使用を、下でさらに詳細に説明する。SUT120は、TS110を使用してテストすることのできる任意のシステムとすることができる。SUT120は、その少なくとも一部をTS110によって個別におよび/または組み合わせてテストできる任意のコンポーネント1つまたは複数を含むことができる。TS120は、SUT120によってテストされるコンポーネント1つまたは複数へのアクセスを提供する関連する入力アクセスピンおよび出力アクセスピンの1つまたは複数のセットを有する1つまたは複数のスキャンチェーンを含むことができる。スキャンチェーン1つまたは複数をSUT120をテストするためにSUT120内で利用できる形は、当業者によって了解されるであろう。たとえば、SUT120は、1つまたは複数の基板を含むことができ、この基板のテスティングは、SUT120に入力テスティング信号を印加し、SUT120から出力テスティング信号を収集するために使用できる関連する入力アクセスピンおよび出力アクセスピンを有する1つまたは複数のスキャンチェーンを使用して実行することができる。図1に示されているように、TS110は、テストアクセスインターフェースTAI115を介してSUT120にアクセスする。テストアクセスインターフェースを、任意の適切なテストアクセスインターフェースを使用して実施することができ、このテストアクセスインターフェースは、TS110、SUT120、実行されるテスティングのタイプ、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数に依存するものとすることができる。たとえば、TAI115は、参照によってその全体が本明細書に組み込まれているIEEE1149.1標準規格で標準化されているJointTestActionGroupJTAGテストアクセスポートTestAccessPort、TAPを含むことができる。IEEE1149.1標準規格は、TestDataInTDI、TestDataOutTDO、TestModeSelectTMS、TestClockTCK、および、オプションでTestResetSignalTRSTという信号のセットをサポートするTAPを定義する。SUT120のTDIピンおよびTDOピンは、TS110がSUT120の少なくとも一部をテストするためにSUT120にそれによってアクセスできるバウンダリスキャンチェーン内で相互接続される。TAI115は、任意の他の適切なテストアクセスインターフェースを含むことができる。当業者は、TS110、TAI115、およびSUT120を、本明細書に含まれる実施形態の特徴を提供するのに適する任意の形で実施できることを了解するであろう。本明細書で説明するように、TISAは、システムテスティングにおける大きい改善を提供するためにシステムテスティング機能と組み合わせてコンピュータサイエンス機能を活用することができる。システムテスティング機能およびコンピュータサイエンス機能の全般的な説明がこれに続き、コンピュータサイエンス機能およびシステムテスティング機能を一緒に利用してTISAを提供する形の説明がそれに続く。TISAは、コンピュータサイエンス機能を活用することによってシステムテスティング機能を改善する。システムテスティング機能は、自動化テストフロー一般に、テストアルゴリズム1つまたは複数の定義から実際のテスティング動作に達するのに必要である可能性があるステップおよびリソースのすべてを含むのすべてのステージで一般にサポートされる機能を含むことができる。テスト自動化を助けるために、テストリソースは、しばしば、基板およびデバイスの内部に組み込まれ、通常はテストアクセスポートTAPと呼ばれる標準化されたインターフェースを使用してアクセスされ得る。これは、ピンカウントを制限し、リソースアクセスおよび管理を合理化するという効果を有する。複数の言語が、テストされるシステムの内部のリソースを記述するのに使用可能であり、したがって、これをテスト生成ツールTGTへの入力として使用することができる。TGTは、TAPに指令し、関連するテスティング動作を実行するのにテスト制御ユニットTestControlUnit、TCUによって使用できるテスティングシーケンスを生成するためにアルゴリズムを適用することができる。テスティング動作の特徴および性能は、3つの要素すなわち、アクセス標準規格、データフォーマット、およびTCU実施態様に依存する。TISAは、改善されたシステムテスティング機能を提供するためにコンピュータサイエンス機能を活用することができる。これは、ソフトウェア開発フロー一般に、コンパイル、命令セットアーキテクチャISA、対話デバッギング、および類似物、ならびにそのさまざまな組合せなど、選ばれたソフトウェア言語1つまたは複数でコーディングされたソフトウェアアルゴリズムからターゲットプロセッサ上での最終的なデバッギングおよび実行に達するのに必要である可能性があるステップおよびリソースのいずれかまたはすべてを含むのすべてのステージで使用可能なコンピュータサイエンス機能の使用を含むことができる。コンピュータサイエンスでのコンパイルの使用は、プログラマフレンドリな高水準抽象化で定義されたアルゴリズムを一連の機械実行可能命令に変形する。このプロセスは、入力プログラミング言語およびプロジェクトの複雑さに依存して大幅に変化する可能性があるが、手法のすべてではないにせよほとんどが、すべてのアルゴリズムをその複雑さに関わりなく基本的な命令に分解できるという同一の基本的な仮定を共有する。これは、古典的な言語ならびにたとえばC、Java、Python、および類似物などのより近代的な高水準言語およびオブジェクト指向言語にあてはまる。命令セットアーキテクチャISAは、すべてのプロセッサの核であり、その理由は、コンパイルが非常に有効であることである。一般に、各プロセッサは、そのプロセッサを操作できる形を定義する命令のセットを提供する。これらの命令は、そのプロセッサのISAの少なくとも一部を形成する。ISAを、レジスタ、アドレッシングモード、オペコード、メモリ構造、および類似物、ならびにそのさまざまな組合せなど、命令に関連するさまざまな構造を含むと考えることができることを了解されたい。ISAは、プロセッサが、メモリから/への値の読取/書込などの単純な命令を実行し、レジスタに対する論理演算または算術演算を実行し、割込みを処理することなどを可能にする。この基本的な挙動は、経時的に本質的に変更されないままであり、現代のプロセッサは、非常に多くのリソースを効率的に活用できるので例外的な性能を達成し、したがって、ほぼ同一の時間ではるかに多数のそのような基本的な命令を完了することができる。さらに、コプロセッサたとえば、浮動小数点コプロセッサ、グラフィカルコプロセッサ、および類似物の使用から、さらにより高い性能に達することができ、このコプロセッサは、複雑な動作をハードコーディングすることによってメインプロセッサを助けることができる。コンピュータサイエンスでのデバッギングの使用は、ソフトウェア開発および実行プロセスの監視および検証を可能にする。一般に、ソフトウェア開発は、長くむずかしいプロセスであり、このプロセスは、最終製品が誤りまたは通常呼ばれるようにバグがないことを保証するために厳格に監視され、検証される。ソフトウェアプログラムをテストするのを助けるために、ソフトウェア開発フローは、多数の強力なデバッグ機能を提供する。たとえば、一般的なソフトウェア開発フローデバッグ機能は、ステップバイステップ実行、すべてのレジスタおよびメモリ位置の観察可能性/制御可能性、ブレークポイントおよびウォッチポイントの使用、ならびに類似物を含む。これらのデバッグ機能ならびにさまざまな他のデバッグ機能は、よりしばしば、ソフトウェアコンパイラによって最終コードに埋め込まれるアルゴリズムおよび構造によって使用可能にされるが、プロセッサの内部で使用可能なハードウェアリソースによって支援することもできる。この情報から、デバッガは、オリジナルコードを再構成し、すべてのISAレベル動作をプログラミング抽象化レイヤに相関させることができる。改善されたシステムテスティング機能を使用可能にするために自動化テスト実行機能およびコンピュータサイエンスソフトウェア機能を一緒に使用することは、図2および図3を参照することによってよりよく理解することができる。図2に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェアコンパイラを含む、図1のテスティングシステムの一実施形態の高水準ブロック図を示す。図2に示されているように、TS110は、テスト生成ツールTGT210およびソフトウェアコンパイラSC220を含む。TGT210は、TGTコンポーザ212およびTGTアルゴリズム214を含む。TGTコンポーザ212は、入力としてシステム記述ファイル211を受け入れる。システム記述ファイル211は、テストされるシステムをテストするためのテスティング命令/ベクトルを作るのにTGTによって使用できる任意の適切な記述ファイルを含むことができる。たとえば、システム記述ファイル211は、回路記述ファイル、基板/治具ネットリストファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。システム記述ファイル211を、TGT210上で使用可能とすることができ、かつ/または1つもしくは複数のリモートコンポーネントおよび/もしくはシステムから入手することができる。システム記述ファイル211は、1つまたは複数の回路記述ファイルを含むことができる。回路記述ファイルは、BoundaryScanDescriptionLanguageBSDL、基板レベルJTAGに関するIEEE1149.1標準規格の一部として開発された、HierarchicalScanDescriptionLanguageHSDL、BSDLの拡張として開発された、NewScanDescriptionLanguageNSDL、および類似物ならびにそのさまざまな組合せなど、任意の適切な記述言語1つまたは複数を使用して指定することができる。システム記述ファイル211は、1つまたは複数の基板/治具ネットリストファイルを含むことができる。基板/治具ネットリストファイルは、ネットリスト、接続、および類似する情報を記述する、デバイス1つまたは複数の物理記述に関係するファイルを含むことができる。基板/治具ネットリストファイルは、PCB、Gerber、および/または基板/治具ネットリストファイルに適する任意の他のフォーマットなど、任意の適切なフォーマットで指定することができる。システム記述ファイル211は、1つまたは複数の他の記述ファイルを含むことができる。他の記述ファイルは、回路モデルを作るための入力として使用できる任意の他の適切な記述ファイルを含むことができる。たとえば、他の記述ファイルは、Asset社のMacroLanguage、Goepel社のCASLAN言語、および/または任意の他の適切な記述言語ファイルなど、任意の適切なアプリケーション固有および/またはツール固有の記述言語ファイルを含むことができる。TGTコンポーザ212は、システム記述ファイル211を処理して回路モデル213を作る。回路モデル213を作るためのTGTコンポーザ212によるシステム記述ファイル211の処理は、任意の適切な形で実行することができる。回路モデル213は、テストされるシステムまたはテストされるシステムのうちでTGT210がそれのために実行されつつある部分のモデルを指定する。TGTコンポーザ212は、回路モデル213をTGTアルゴリズム214に供給する。TGTアルゴリズム214は、回路モデル213を受け入れる。TGTアルゴリズム214は、回路モデル213を処理して、TGT原子的テスト動作216を作る。TGT原子的テスト動作216を作るためのTGTアルゴリズム214による回路モデル213の処理は、任意の適切な形で実行することができる。SC220は、SCフロントエンドアルゴリズム222およびSCバックエンドアルゴリズム224を含む。SCフロントエンドアルゴリズム222は、入力としてコンピュータサイエンスソースファイル221を受け入れる。コンピュータサイエンスソースファイル221は、コンパイラによってコンパイルできる任意の適切なコンピュータサイエンスソースファイルを含む。たとえば、コンピュータサイエンスソースファイル221は、C、Java、Python、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータプログラミング言語1つまたは複数のコンピュータサイエンスソースファイルを含むことができる。たとえば、コンピュータサイエンスソースファイル221は、1つもしくは複数のCファイル、1つもしくは複数のCファイル、および/または任意の他の適切なコンピュータサイエンスソースファイルのうちの1つまたは複数を含むことができる。SCフロントエンドアルゴリズム222は、コンピュータサイエンスソースファイル221を処理してプログラムモデル223を作る。プログラムモデル223は、コンピュータサイエンスソースファイル221の中間表現を指定する。SCフロントエンドアルゴリズム222は、プログラムモデル223をSCバックエンドアルゴリズム224に供給する。SCバックエンドアルゴリズム224は、入力としてプログラムモデル223を受け入れる。SCバックエンドアルゴリズム224は、プログラムモデル223を処理して、ISA原子的動作226を含む1つまたは複数のISA2進ファイル225を作る。ISA原子的動作226を含むISA2進ファイル225を形成するためのSCバックエンドアルゴリズム224によるプログラムモデル223の処理は、任意の適切な形で実行することができる。ISA原子的動作226は、TISAがそれのために実施されるプロセッサによってサポートされるアセンブリレベル命令である。図2に示されているように、TGT210およびSC220のそれぞれの処理フローに加えて、TGT210とSC220との間の追加の相互作用を、TISA原子的動作235の生成を制御するのに利用することができる。一実施形態では、SCバックエンドアルゴリズム224は、TGTアルゴリズム214への1つまたは複数のベクトル計算要求230を開始することができる。SCバックエンドアルゴリズム224は、SCバックエンドアルゴリズムがTAPにアクセスすることを必要とする時に、ベクトル計算要求230を開始することができる。TGTアルゴリズム214は、SCバックエンドアルゴリズム224からベクトル計算要求230を受け取った時に、受け取られたベクトル計算要求230に基づいてTAPに関する1つまたは複数のTGT原子的テスト動作216を生成する。次に、1つまたは複数のTGT原子的テスト動作216を、SCバックエンドアルゴリズム224によって制御される形でTAPに適用することができる。というのは、TGT原子的テスト動作216が、ISA原子的動作226と組み合わされて、ISA原子的動作226を使用するTGT原子的テスト動作216に対するアルゴリズム的制御を可能にするからである。この形で、SC220は、TAPへのアクセスのアルゴリズム的制御を提供する。図2に示されているように、TGT210およびSC220に加えて、TS110は、さらに、TISAコンポーザ240を含む。TISAコンポーザ240は、TGT原子的テスト動作216およびISA原子的動作226を受け入れる。TISAコンポーザ240は、TGT原子的テスト動作216をTISA命令に変換し、それらのTISA命令をISA2進ファイル1つまたは複数225に挿入するすなわち、TISA命令をISA原子的動作226と組み合わせて、これによって、TISA原子的動作246を含むTISA2進ファイル245を形成する。TISAコンポーザ240は、TGT210の一部とするか、SC220の一部とするか、TGT210およびSC220にまたがって分割されるか、TGT210およびSC220とは別々に実施されるものなどとすることができる。図2に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ/または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。図3に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェアコンパイラを含む、図1のテスティングシステムの一実施形態の高水準ブロック図を示す。図3に示されているように、図3のTS110は、TISA原子的動作を含むTISA2進ファイルがテスト生成ツールとソフトウェアコンパイラとの間の相互作用を使用して生成されるという点で、図2のTS110に似た形で動作する。しかし、図3のTS110でのテスト生成ツールとソフトウェアコンパイラとの間の相互作用は、図2のTS110でのテスト生成ツールとソフトウェアコンパイラとの間の相互作用とは異なる。図3に示されているように、TS110は、テスト生成ツールTGT310およびソフトウェアコンパイラSC320を含む。TGT310は、TGTコンポーザ312およびTGTアルゴリズム314を含む。TGTコンポーザ312は、入力としてシステム記述ファイル311を受け入れる。システム記述ファイル311は、テストされるシステムをテストするためのテスティング命令/ベクトルを作るのにTGTによって使用できる任意の適切な記述ファイルを含む。たとえば、システム記述ファイル311は、回路記述ファイル、基板/治具ネットリストファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。図3のシステム記述ファイル311は、図2に関して図示し、説明したシステム記述ファイル211に似たシステム記述ファイルたとえば、1つまたは複数の回路記述ファイル、1つまたは複数の基板/治具ネットリストファイル、1つまたは複数の他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。システム記述ファイル311を、TGT310上で使用可能とすることができ、かつ/または1つもしくは複数のリモートコンポーネントおよび/もしくはシステムから入手することができる。TGTコンポーザ312は、入力として1つまたは複数のテスト動作記述ファイル3311-331N集合的にテスト動作記述ファイル331を受け入れる。テスト動作記述ファイル331は、SC320によって生成される。SC320によるテスト動作記述ファイル331の生成を、下で詳細に説明する。TGTコンポーザ312は、システム記述ファイル311およびテスト動作記述ファイル331を処理して、回路モデル313を作る。回路モデル313を作るためのTGTコンポーザ312によるシステム記述ファイル311の処理は、任意の適切な形で実行することができる。回路モデル313は、回路モデル313は、テストされるシステムまたはテストされるシステムのうちでTGT310がそれのために実行されつつある部分のモデルを指定する。テスト動作記述ファイル331に関連するシステム記述ファイル311の処理は、TGT310が適切なTAP原子的動作を作ることを可能にする形で、TGTコンポーザ312が回路モデル313を作ることを可能にする。TGTコンポーザ312は、回路モデル313をTGTアルゴリズム314に供給する。TGTアルゴリズム314は、回路モデル313を受け入れる。TGTアルゴリズム314は、回路モデル313を処理して、TGT原子的テスト動作316を作る。TGT原子的テスト動作316を作るためのTGTアルゴリズム314による回路モデル313の処理は、任意の適切な形で実行することができる。図3に示されているように、TGT310およびSC320に加えて、TS110は、TISAトランスレータ340を含む。TISAトランスレータ340は、TGT原子的テスト動作316を受け取る。TISAトランスレータ340は、TGT原子的テスト動作316を変換して、TISA原子的テスト動作346を形成する。TISAトランスレータ340は、ソフトウェアコンパイルプロセスに含めるために、TISA原子的テスト動作346をSC320に供給する。SC320によるTISA原子的テスト動作346の使用を、下で詳細に説明する。TISAトランスレータ340は、TGT310の一部とするか、SC320の一部とするか、TGT310およびSC320にまたがって分割されるか、TGT310およびSC320とは別々に実施されるものなどとすることができる。SC320は、SCプリコンパイラ330、SCフロントエンドアルゴリズム322、およびSCバックエンドアルゴリズム324を含む。SCプリコンパイラ330は、コンピュータサイエンスソースファイル321を受け入れる。コンピュータサイエンスソースファイル321は、コンパイラによってコンパイルできる任意の適切なコンピュータプログラミングソースファイルを含む。たとえば、コンピュータサイエンスソースファイル321は、C、Java、Python、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータプログラミング言語1つまたは複数のコンピュータプログラミングソースファイルを含むことができる。たとえば、コンピュータサイエンスソースファイル321は、1つもしくは複数のCファイル、1つもしくは複数のCファイル、および/または任意の他の適切なコンピュータサイエンスソースファイルのうちの1つまたは複数を含むことができる。SCプリコンパイラ330は、コンピュータサイエンスソースファイル321を処理する。SCプリコンパイラ330は、コンピュータサイエンスソースファイル321を処理し、それから前処理済みコンピュータサイエンスソースファイル321Pを作る。コンピュータサイエンスソースファイル321をSCプリコンパイラ330によって前処理して、任意の適切な形で前処理済みコンピュータサイエンスソースファイル321Pを形成することができる。SCプリコンパイラ330は、前処理済みコンピュータサイエンスソースファイル321Pをフロントエンドアルゴリズム322に供給する。SCプリコンパイラ330は、コンピュータサイエンスソースファイル321の処理中にテスト動作を検出し、テスト動作記述ファイル331を生成する。テスト動作記述ファイル331は、任意の適切なテスト記述言語を使用してたとえば、1つまたは複数の標準テスト記述言語を使用して、TGT310に固有のテスト記述言語を使用して、および類似物、ならびにそのさまざまな組合せ指定することができる。SCプリコンパイラ330は、テスト動作記述ファイル331をTGT310に実例として、回路モデル313を作るためにシステム記述ファイル311に関連してテスト動作記述ファイル331を処理する、TGT310のTGTコンポーザ312に供給する。SCフロントエンドアルゴリズム322は、前処理済みコンピュータサイエンスソースファイル321Pを受け入れる。SCフロントエンドアルゴリズム322は、TISA原子的テスト動作346をも受け入れ、このTISA原子的テスト動作346は、テスト動作記述ファイル331からTGT310によって作られたTGT原子的テスト動作316を使用してTISAトランスレータ340によって作られる。SCフロントエンドアルゴリズム222は、前処理済みコンピュータサイエンスソースファイル321PおよびTISA原子的テスト動作346をコンパイルして、プログラムモデル323を作る。プログラムモデル323は、前処理済みコンピュータサイエンスソースファイル321Pの中間表現を指定し、この中間表現は、TISA原子的動作を形成するためにTISA原子的テスト動作346をISA原子的動作内に統合できるように、TISA原子的テスト動作346を含む。SCフロントエンドアルゴリズム322は、プログラムモデル323をSCバックエンドアルゴリズム324に供給する。SCバックエンドアルゴリズム324は、プログラムモデル323を受け入れる。SCバックエンドアルゴリズム324は、プログラムモデル223を処理して、TISA原子的動作356を含む1つまたは複数のTISA2進ファイル355を作る。TISA原子的動作356を含むTISA2進ファイル355を形成するためのSCバックエンドアルゴリズム324によるプログラムモデル323の処理は、任意の適切な形で実行することができる。TISA原子的動作356は、ISA原子的動作すなわち、TISAがそれために実施されるプロセッサによってサポートされるアセンブリレベル命令およびTISA原子的テスト動作346を含む。TISA原子的動作356は、TGT原子的テスト動作316すなわち、TISA原子的テスト動作346の形のに対するアルゴリズム的制御ISA原子的動作を使用するを提供し、これによって、TISA原子的動作356が適用されるテストされるシステムの改善されたシステムテスティングを可能にする。したがって、TGT原子的テスト動作316すなわち、TISA原子的テスト動作346の形のを、SCバックエンドアルゴリズム324によって制御される形でTAPに適用することができる。というのは、TGT原子的テスト動作316が、ISA原子的動作を使用するTGT原子的テスト動作316に対するアルゴリズム的制御を可能にするために、ISA原子的動作と組み合わされるからである。この形で、SC220は、TAPへのアクセスのアルゴリズム的制御を提供する。図3に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ/または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。図2および図3に関して、主に特定の個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物に関して図示し、説明したが、図2および図3の実施形態ならびに本明細書で提供されるさまざまな関連する教示を、任意の適切な個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物を使用して実施できることを了解されたい。図2および図3は、コンピュータサイエンス機能を活用してシステムテスティング機能を改善する形を示すたとえば、システムテスティングの細粒度制御の提供、対話システムテスティングの使用可能化、システムテスティング中の対話デバッギングの使用可能化、および図示され本明細書で説明されるさまざまな他の利益の提供。図2および図3のシステムテスティング方式は、STAPLなどの既存手法に対する改善を提供し、これらの既存手法では、目標は、ベクトルフォーマットにプログラミング機能を追加することであり、したがって、デバッギング機能、リモートアクセス機能、および対話性機能が、ゼロから追加される。対照的に、TISAは、システムテスティング用のテストアクセスを制御するために、コンピュータプログラミングおよび組込みアプリケーションからの豊富な情報を活用する。図2および3を参照して、TISAの機能および特徴が、その抽象化レベルによって定義される、すなわち、TISA原子的動作の定義が微細であればあるほど、TISAがより良い性能を提供することを了解されたい。TISAがJTAGアーキテクチャ内で実施される一実施形態では、3つの抽象化レベルを、スキャン動作のためにサポートすることができる。第1の抽象化レベルは、ベクトルレベルである。ベクトルレベルは、3つの抽象化レベルのうちで最も粗な粒度であり、ここでは、原子的動作は、スキャンベクトルの入力および出力である。ベクトルレベルは、SerialVectorformatSVFまたは任意の他の適切なベクトルフォーマットなどのベクトルフォーマットで最もよく表され、最高レベルの制御を与える。第2の抽象化レベルは、TAPレベルである。TAPレベルでは、原子的動作は、TAP状態機械に対する十分な制御を可能にするために機能強化される。これは、スキャン動作に対するより洗練された制御、非標準シーケンスたとえば、たとえばアドレッサブルシャドウプロトコルAddressableShadowProtocolまたは他の類似するプロトコルで要求されるシーケンスなどのサポートを可能にする。第3の抽象化レベルは、スキャンセグメントレベルである。スキャンセグメントレベルは、3つの抽象化レベルのうちで最も微細な粒度である。ベクトルレベルおよびTAPレベルの抽象化レベルは、原子的データフォーマットとしてスキャンベクトルを使用し、これは、スキャンチェーン全体が用いられる伝統的な導通テストには十分であるが、スキャンチェーンを構成する数十個または数百個の機器に対する細粒度制御の必要がある機器ベースのテスティングinstrument-basedtestingには面倒である。スキャンセグメントレベルは、全体的なスキャンパスの内部のスキャンセグメントの定義を可能にし、このスキャンセグメントは、別々に処理することができ、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。この手法は、使用可能な計算リソースが非常に限られている場合がある組込み応用例で有利である。スキャンセグメントレベルの使用を、図示し、下でさらに詳細に説明する図2および図3に示されているように、スキャン動作の抽象化レベルに関わりなく、TGTによって計算される、結果のTAP原子的動作実例として、TGT原子的テスト動作216およびTGT原子的テスト動作316は、対応するTISA原子的テスト動作に変換され、2進実行可能ファイルにたとえば、SCによって生成されたISA原子的動作に挿入される。図2を参照すると、TGT原子的テスト動作216およびISA原子的動作226を処理して、TISA2進実行可能ファイル実例として、TISA2進ファイル245内のTISA原子的動作246を形成することができる。TISA原子的動作246は、TISA原子的テスト動作およびISA原子的動作を含む。図3を参照すると、TISA原子的テスト動作TGT310によって作られたTGT原子的テスト動作316からTISAトランスレータ340によって生成されるを、SC310のSCフロントエンド324を変更することを全く必要とせずに、前コンパイル済みアセンブリ命令としてSCフロントエンド324に入力することができる。ほとんどすべてのプログラミング言語が、そのような動作を可能にすることを了解されたい。たとえば、Cでは、この動作が、asmコマンドを使用して得られる。一実施形態では、SCバックエンドアルゴリズム324に対する些細な変更が必要になる場合があるたとえば、TISAアセンブラ命令の2進変換を処理するために。そのようなプロセスの例を、図11に関して図示し、本明細書で説明する。主にJTAGアーキテクチャでのTISA原子的動作の粒度のレベルに関して図示し、説明したが、当業者は、TISA原子的動作の粒度の同一のレベルを他のアーキテクチャで利用でき、TISA原子的動作の粒度の異なるレベルの粒度を、JTAGアーキテクチャおよび/または他のアーキテクチャ、類似物、ならびにそのさまざまな組合せで利用できることを了解するであろう。上で説明したように、TISAを、任意の適切な命令セットアーキテクチャISAを使用して実施することができる。たとえば、TISAを、SPARCV8ISA、INTELISA、および類似物を使用して実施することができる。TISAの実施態様を説明する際の明瞭さのために、SPARCV8ISAを使用するTISAの例示的実施態様を、本明細書で図4A~4Eに関して図示し、説明する。この例示的実施態様では、TISAは、ベクトルレベルTISAとして実施され、このベクトルレベルTISAは、SVFフォーマットを構成する命令の直接コーディングを可能にするが、上で説明したように、SPARCV8ISAを使用するTISAの実施を、TISAがTAPレベルTISAまたはスキャンセグメントレベルTISAとして実施される場合にも実行できることを了解されたい。SPARCV8ISAは、オープンソースソフトプロセッサファミリLeon2およびLeon3など、多数の製品で実施されている。TheSPARCArchitectureManualVersion8、SPARCInternational,Inc刊、1992年以下ではSPARCArchitectureManualの再検討によって、SPARCV8ISAによって活用されていない多数の符号語があることが明らかになる。これは、少なくともAppendixFのopcodesandconditioncodesオペコードおよび条件コードの再検討から明白である。図4Aに、SPARCV8ISAの未活用符号語を示す。図4Aに示された未活用符号語は、TISAのテスト命令をコーディングするのに使用することができる。より具体的には、opとop2との両方に0がセットされている時に、その命令は、TheSPARCArchitectureManualVersion8では未実施としてマークされ、その命令をTISAに使用できるようになっている。図4Bに、13個のSVF命令のすべてを表すことができるコーディングフォーマットを示す。図4Bに示されているように、ビット30~25は、命令コーディング自体を含み、ビット21~18は、TAP状態が命令と共に使用される場合にそのTAP状態をコーディングするのに使用することができ、ビット17~14は、必要な場合にオプション情報を指定するのに各命令によって使用することができる。図4Cに、IEEE1149.1TAPのTAP状態の例示的ビットコーディングを示す。TAP状態のビットコーディングは、IEEE1149.1TAP状態名を識別する第1列、IEEE1149.1TAP状態名に関連するSVFTAP状態名を識別する第2列、および図4Bのビット21~18のビットコーディングを識別する第3列を使用して表されている。ビットコーディングを、さまざまな他の形でTAP状態に割り当てることができることを了解されたい。SVF命令は、複数のパラメータを可能にし、これらのパラメータは、最終的なコードの内部でコーディングされる必要がある。パラメータを表すために、また、命令およびデータを別々に保つという通常のアーキテクチャ的ベストプラクティスのために、レジスタベースのパラメータ渡しが、ベクトルレベルTISAのこの例示的実施態様のために定義される。したがって、ベクトルレベルTISAは、6つの専用32ビットレジスタすなわち、GENERIC1、GENERIC2、TDI、TDO、MASK、およびSMASKを提示する。この6つの専用32ビットレジスタを、図4Dに示す。6つの専用32ビットレジスタの使用を、下で詳細に説明するが、一般的ルールとして、これらのレジスタは、パラメータを格納するか、パラメータが格納されるメモリ位置をポイントするかのいずれかに使用される。したがって、コンパイル時に、通常のISA命令を使用して、TISA命令が呼び出される前にこれらのレジスタにロードすることができる。より具体的には、TISAのこのSPARCV8ISA実施態様では、コプロセッサレジスタを、通常のロード/ストア命令のパラメータとして直接に使用することができる。TISAのこのSPARCV8ISA実施態様で利用できるSVF命令は、ENDDR、ENDIR、STATE、FREQUENCY、PIO、PIOMAP、HDR、HIR、TDR、TIR、SDR、SIR、およびRUNTESTを含む。これらのSVF命令は、参照によってその全体が本明細書に組み込まれている、SerialVectorFormatSpecification、ASSETInterTech,Inc.、1997年以下ではSVFマニュアルと称するを参照することによってよりよく理解することができる。TISAのこのSPARCV8ISA実施態様でのこれらのSVF命令の使用を、下でより詳細に説明する。ENDDR、ENDIR、STATEENDDR命令およびENDIR命令は、TAPインターフェースがその動作を終了するTAP状態を示す。STATE命令は、強制的にTAPインターフェースを指定された状態にする。TISAのこの例示的実施態様では、ENDDR命令、ENDIR命令、およびSTATE命令のSVFコーディングは、図4Eに示されているようにそれぞれ000000、000001、および000010である。これらのSVF命令のSVFコーディングは、必要に応じてTAP状態ファイルすなわち、図4Cに示されたTAP状態の例示的ビットコーディングを使用して実行することができる。少なくともSVFマニュアルの再検討から、STATE命令がオプションでパラメータとして状態の明示的シーケンスをとることができることを了解されたい。TISAのこの例示的実施態様では、パラメータとして状態の明示的シーケンスをとることは、シーケンス内の状態ごとに1命令の、一連の命令によってコーディングされるはずである。FREQUENCYFREQUENCY命令は、TAPインターフェースの動作周波数を指定するのに使用される。FREQUENCY命令は、Hzサイクルの32ビット整数として表される。TISAのこの例示的実施態様では、FREQUENCY命令のSVFコーディングは、図4Eに示されているように、000011である。FREQUENCY命令の値は、GENERIC1レジスタに格納される。PIO、PIOMAPPIO命令は、PIOMAPへの呼出しによって以前にセットされたフォーマットの並列ベクトルを処理するのに使用することができる。RISAのこの例示的実施態様では、PIOMAPは、TAPインターフェースをセットアップするのに適切なコマンドを生成するプリプロセッサディレクティブとみなされる。したがって、PIO命令は、単に、並列ベクトルを表すことを必要とし、この並列ベクトルは、この並列ベクトルが格納されているアドレスを示すGENERIC1レジスタ内でことによって表すことができる。ベクトルを構成する語数nは、この命令のビット13~0で指定され、したがって、ベクトルは、213=8K語=32Kバイトのサイズ上限を有する。ベクトルサイズが1語の正確な倍数ではない場合には、必要に応じてパディングおよび再アライメントをメモリ内で提供することができる。TISAのこの例示的実施態様では、PIO命令のSVFコーディングは、000100である。HDR、HIR、TDR、TIRHDR命令、HIR命令、TDR命令、およびTIR命令の役割は、異なる。ここでは、これらのSVF命令を一緒に検討する。というのは、1これらのSVF命令が、機能的に類似しすなわち、これらのすべてが、異なる性質のものである場合であっても、シフト演算を指令する、2これらのSVF命令が、次の同一のパラメータを受け入れるからである。1lengthシフトすべきビット数を表す32ビット数2TDIオプション入力シフトベクトル3TDOオプション期待される出力シフトベクトル4MASKオプション実際の値をTDOと比較する時に使用すべきマスク。1は関係を示し、0は無関係を示す。5SMASKオプション実際の値をTDIと比較する時に使用すべきマスク。1は関係を示し、0は無関係を示す。TISAのこの例示的実施態様では、HDR命令、HIR命令、TDR命令、およびTIR命令のSVFコーディングは、図4Eに示されているように、それぞれ000110、000111、001010、および001011である。TISAのこの例示的実施態様では、次の追加のコーディングを使用することができる。1lengthは、GENERIC1レジスタに格納される。2O1は、TDIが存在する時には1であり、そうでない時には0である。セットされている場合に、TDIレジスタは、入力ベクトルが格納されているアドレスを含む。3O2は、TDOが存在する時には1であり、そうでない時には0である。セットされている場合に、TDOレジスタは、期待される出力が格納されているアドレスを含む。4O3は、MASKが存在する時には1であり、そうでない時には0である。セットされている場合に、MASKレジスタは、出力マスクが格納されているアドレスを含む。5O4は、SMASKが存在する時には1であり、そうでない時には0である。セットされている場合に、SMASKレジスタは、出力マスクが格納されているアドレスを含む。SDR、SIRSDR命令およびSIR命令は、HDR命令、HIR命令、TDR命令、およびTIR命令と同一の構文を有するが、機能的相違を有し、SDRおよびSIRは、TAPに対する実際のスキャン動作をトリガする。対話テスティングでは、システムから読み取られた実際の出力ベクトルが、アルゴリズムの基礎であり、したがって、TISAは、実際の出力ベクトルをメモリ内に格納する可能性を提供する。TAP状態フィールド図4Bに示されたビット21~18が0とは異なる時には、GENERIC2レジスタは、実際の出力ベクトルのストレージ位置を示す。したがって、SDRおよびSIRは、最大7個のパラメータをサポートすることができる。TDOが指定され、実際の出力ベクトルが期待される出力ベクトルとは異なる場合には、SPARCArchitectureManualのSection4.2に記載されているように、オーバーフローフラグがプロセッサ状態レジスタPSR内でセットされる。RUNTESTRUNTEST命令は、強制的にTAPインターフェースに指定された長さの時間だけ指定された状態でテストを実行させ、主にRUNBIST動作たとえば、IEEE1149.1で定義されているを制御するのに使用される。RUNTEST命令は、次のパラメータすべてがオプションであるのうちの1つまたは複数を受け入れる。1run_stateインターフェースがテスト実行中に維持しなければならない状態2run_countテストが費やさなければならないクロックサイクル数3run_clkrun_countがどのクロックを参照するのかTCK:TAPクロック、SCK:システムクロック4min_time実数として表された、秒単位の最小走行時間5max_time実数として表された、秒単位の最大走行時間6endstateインターフェースがコマンドの終りに達しなければならない状態TISAのこの例示的実施態様では、RUNTEST命令のSVFコーディングを、000101または100101とすることができる。TISAのこの例示的実施態様では、次の追加のコーディングを使用することができる。1TAP_STATEそれについて定義されたrun_stateを含む。2O1TAP_STATEが定義されている場合には1、そうでない場合には03O2min_countが指定されている場合には1、そうでない場合には0。セットされている場合には、GENERIC1レジスタが、min_countの32ビット符号なし表現を含む。4O3max_timeが指定されている場合には1、そうでない場合には0。セットされている場合には、GENERIC2レジスタが、max_countの32ビット符号なし表現を含む。5O4endstateがセットされている場合には1、そうでない場合には0。セットされている場合には、ビット13~10が終了状態を含む。6ビット9~0run_countが指定されている場合には、符号なし整数として表される最大run_count=210=1024。このフィールドが0ではない場合には、ビット30がrun_clockを示す1=TCK、0=SCK。主にTISAのこのSPARCV8ISA実施態様での特定のSVF命令すなわち、ENDDR、ENDIR、STATE、FREQUENCY、PIO、PIOMAP、HDR、HIR、TDR、TIR、SDR、SIR、およびRUNTESTの使用に関して図示し、本明細書で説明したが、より少数またはより多数のSVF命令を使用できることを了解されたい。主にSPARCV8ISAを使用するTISAの実施態様に関して図示し、本明細書で説明したが、他のISAを利用して、図示され本明細書で説明されるTISA教示によるTISAを実施できることを了解されたい。対話テスティング手法では、データハンドオフポイントが非常に重要である。上で説明したように、テストプログラムは、2つの主要部分すなわち、アルゴリズム部分ソフトウェアコンパイラによって表されるおよびテストアクセス部分テスト生成ツールによって表されるからなる。テスティングプログラムを使用するテスト動作中には、テストプログラムがテストされるシステムにアクセスしている瞬間と、テストプログラムがテスト結果を検査し、必要な次のステップ1つまたは複数を判断している瞬間とがある。この2つの動作の間でのハンドオフは、効率的な対話テスティングを得るために重要である。SVFおよびSTAPLなどの既存のスクリプトベースの手法では、スクリプトが、ベクトルレベルですべてのTAP動作の世話をする。このレベルでは、インターフェースまたはプレイヤは、TAPプロトコルを用いて通信し、テストされるシステムへ/からベクトルを送る/受け取ることができる。さらに、STAPLは、いくつかの基本的なフロー制御if-then-elseおよびビットベクトルに対するアルゴリズム的操作をも可能にする。より洗練された処理たとえば、受け取られたベクトルの内部のレジスタを識別する、または特定のデバイスにアクセスするためのベクトルを計算するの必要がある場合には、プレイヤは、アルゴリズム部分に制御をハンドオーバーする。STAPLでは、これがexportコマンドを介して行われる。しかし、不利なことに、SVFおよびSTAPLの両方が、これに関する標準化されたフォーマットを有しないたとえば、STAPLの場合に、ハンドオフプロセスは、通常は、所与のベンダにプロプライエタリである。Ericsson社のMasterTestControllerMTCおよびSystemBISTProcessorなどの既存の組込み手法では、アルゴリズム部分とテストアクセス部分との間の同一の区分が使用される。そのような組込み手法では、アルゴリズム部分およびテストアクセス部分は、別々にプログラムされなければならない異なるプロセッサによって実行される。さらに、アルゴリズム部分およびテストアクセス部分のメモリ空間は、物理的に異なり、結果のハンドオフ機構が、STAPLのハンドオフ機構に類似するようになっている。その結果は、テストアクセス部分用のコプロセッサが、アルゴリズム部分へのハンドオフの前に大量のスキャン部分を格納することを強制されることであり、これは、スキャンチェーンの増加するサイズを考慮すると、膨大な量のリソースを必要とする可能性がある。統合テスティングに対する既存手法たとえば、SVFおよびSTAPLなどのスクリプトベースの手法ならびにMTCおよびSystemBISTProcessorなどの組込み手法とは対照的に、TISAは、テストアクセス部分すなわち、テスト動作をアルゴリズム部分すなわち、古典的ISAの内部に統合し、テストアクセス部分およびアルゴリズム部分が同一の物理メモリ空間を共有するようにし、これによって、テストアクセス部分とアルゴリズム部分との間のハンドオフしたがって、データ渡しを自動的にする。TISAでは、テストアクセス部分とアルゴリズム部分との間のハンドオフは、命令レベルで行われ、プロセッサが、関連するスケジューリング戦略に従って必要に応じてスキャンおよびアルゴリズムを自由に混合すなわち、テスト動作およびアルゴリズム動作を自由に混合できるようになっている。SPARCV8ISAを使用するTISAのこの例示的実施態様では、ベクトルを扱うすべての動作が、絶対アドレッシングを使用するSVF命令に関して上で説明したように。その結果、テスティングベクトルを、ISAプログラムの内部の通常の変数のように使用することができ、これによって、テストアクセス部分とアルゴリズム部分との間のインターフェースを自動的にする。例として、上で説明したSPARCV8ISAを使用するTISAの例示的実施態様に基づいて、次のステップは、原型的なテスティングシーケンスを例示するものである。1SDR命令が、テストされるシステムからテスティング出力データを入手するのに使用される。結果の出力データは、特定のメモリ位置に配置されるたとえば、GENERIC2レジスタ内のactualパラメータ2古典的なLOAD命令が、ロードされるべきこの出力データをレジスタに転送することができる3出力データがレジスタにロードされた後に、算術演算および/または論理演算を使用して、出力データを処理することができるSPARCV8ISAはロード/ストアアーキテクチャなので、すべてのデータが、処理される前にレジスタにロードされなければならないことに留意されたい4古典的なSTORE命令が、アルゴリズムの結果をメモリに転送するのに使用される5SDR命令が、新しいテスティング入力データをTAPに送ることができるたとえば、TDIレジスタ内のTDIパラメータを使用して古典的なアルゴリズム動作2から4が、ISAアルゴリズム実施態様について標準的であり、いかなる形でもTISAによって変更されないことに留意されたい。したがって、この単純な例から、TISAを、アルゴリズム部分とテストアクセス部分との間の自然で効率的なハンドオフと共に、任意の所与のアルゴリズムまたはコンピュータプログラムを使用してサポートできることは、明白である。SPARCV8ISAを使用するTISAのこの例示的実施態様では、絶対アドレッシングが使用されるTISAを説明する際の明瞭さのためにが、本明細書の教示によって情報を与えられた当業者は、SPARCArchitectureManualに記載されたすべての正当なSPARCV8アドレッシングモードをサポートするためにTISAのこの例示的実施態様を修正できるはずである。本明細書で主にSVFが使用されるTISAの例示的実施態様に関して図示し、説明したが、SVFは、1149.1TAPの、基本的であるとしても完全な処理を提供することがわかっている周知のフォーマットなので、この例示的実施形態で使用された。本明細書の教示によって情報を与えられた当業者は、TISAを任意の他の適切な制御フォーマットを使用して実施でき、それらの制御フォーマットの多くが、TAP状態機械のより細粒度の制御を可能にし、より洗練されたテスティング動作をサポートすることができることを了解するであろう。本明細書で主に抽象化レベルがベクトルレベルであるTISAの例示的実施態様に関して図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、図示され本明細書で説明される例示的TISA実施態様を、TISAの抽象化レベルがTAPレベルまたはスキャンセグメントレベルになるように変更できることを了解するであろう。TISAを説明する際の明瞭さのために、例示的なテストされるシステムに対してテスティングを実行するためのTISAの例示的使用を、図5および6に関して図示し、本明細書で説明する。TISAのこの例示的使用では、TISAは、SPARCV8ISAおよびSVFを使用するベクトルレベルTISAとしてすなわち、図4A~4Eに関して図示され、説明された例示的実施態様の継続で実施される。図5Aおよび図5Bに、テストされるシステムに対してテスティングを実行するためのTISAの例示的使用を示す。図5Aに、JTAGTAP510およびテストされるシステム520を含むシステムテスト環境500を示す。JTAGTAP510は、テストされるシステム520へのテストアクセスを提供する。JTAGTAP510は、テストされるシステム520に入力データを送り、テストされるシステム520から出力データを受け取るために、テストされるシステム520へのテストアクセスを提供する。JTAGTAP510は、命令レジスタIR512を含み、IR512は、8ビット命令レジスタである。JTAGTAP510は、テスティングシステムたとえば、明瞭にするために省略されている、図3に関して図示し、説明したテスティングシステム110などによって制御される。テストされるシステム520は、第1基板521B1と表されるおよび第2基板525B2と表されるを含む。第1基板521は、送信器522Tと表されるを含む。第2基板525は、受信器526Rと表されるを含む。送信器522は、接続529上でデータを受信器526に送信する。この例では、接続529は、8ビット接続である。図5Aに示されているように、各基板は、それ自体のスキャンチェーンを介してJTAGTAP510からアクセス可能である。すなわち、第1基板521は、第1スキャンチェーン523を介してアクセス可能であり、第2基板525は、第2スキャンチェーン527を介してアクセス可能である。第1スキャンチェーン523および第2スキャンチェーン527は、JTAGTAP510のIR512によってアクセス可能であるたとえば、IR=0は第1基板B1を選択し、IR=1は第2基板B2を選択する。送信器522および受信器526は、その基板上で単独であるのではなく、より広いスキャンチェーンたとえば、この例において、それぞれ24ビットおよび16ビットの一部である。テストプログラムでは、入力データが、第1スキャンチェーン523を介して送信器522に送られ、結果の出力データが、第2スキャンチェーン527を活用することによって受信器526から収集される。網羅的テストを実行するために、すべての可能な値が接続529を介して送信され、28=256個のベクトルが接続529を介して送信されるようになっている。Cを使用すると、例示的プログラムを、次とすることができる。1include<stdio.h>2include<jtag.h>34charsent_value,receivedvalue;56defineMAX_COUNT256;78voidmainvoid9{10forsent_value=0;sent_value<MAX_COUNT;sent_value11{12apply_JTAGsent_value,B1.T;13read_JTAGreceived_value,B2.R;14ifsent_value=receivedvalueexit0;15}16exit1;17}このプログラムでは、行2は、JTAG動作を処理しているCモジュールを含み、このCモジュールでは、それぞれ行12および13で使用される関数apply_JTAGおよびRead_JTAGが定義される。SC320のプリコンパイラ330は、これらの関数を認識し、TGT310用のテスト動作記述ファイル331を生成する。テスト動作記述ファイル331のフォーマットは、第1基板521および第2基板525の実際の実施態様に依存して変化する可能性がある。たとえば、第1基板521と第2基板525との両方がIJTAG準拠である場合には、テスト動作記述ファイル331を、たとえばNewScanDescriptionLanguageNSDLコードを使用して指定することができる。TGT310は、テスト動作記述ファイル331を使用して、TGT原子的テスト動作316を生成し、このTGT原子的テスト動作316は、TISAトランスレータ340によってTISA原子的テスト動作346に変換される。TISA原子的テスト動作346は、SC320のフロントエンド324に供給される。TGT原子的テスト動作316、関連するTISA原子的テスト動作346、および結果のTISA2進コードが、図5Bに示されている。図5Bに、図5Aのシステムテスト環境500のテスティングを実行するテスティングシステムによる使用のためのCコマンドからTISAコーディングへのマッピングを示す。図5Bに示されているように、TISAコーディングへのCコマンドのマッピングは、4つの列すなわちCコマンド列541、SVF命令列542、TISAアセンブラ列543、およびTISAコーディング列544を有するテーブル540を使用して表される。テーブル540は、左から右へ、CコマンドをSVF命令に変換できる形を示し、このSVF命令をTISAアセンブラに変換することができ、このTISAアセンブラをTISA2進コーディングにコーディングすることができる。Apply_JTAGvalue,B1.Tコマンドは、2つのSVF命令すなわちSIR8TDI00およびSDR24TDIvalueに変換される。SIR8TDI00SVF命令は、次の3つの動作としてTISAアセンブラに変換される。SET8,cGENERIC1SET00,cTDISIRTDI、12010000としてTISAコーディングに変換される。SDR24TDIvalueSVF命令は、次の3つの動作としてTISAアセンブラに変換される。SET24,cGENERIC1SETvalue,cTDISDRTDI、10010000としてTISAコーディングに変換される。Read_JTAGvalue,B2.Rコマンドは、2つのSVF命令すなわちSIR8TDI01およびSDR16ACTUALvalueに変換される。SIR8TDI01SVF命令は、次の3つの動作としてTISAアセンブラに変換される。SET8,cGENERIC1SET01,cTDISIRTDI、12010000としてTISAコーディングに変換される。SDR16ACTUALvalueSVF命令は、次の3つの動作としてTISAアセンブラに変換される。SET16,cGENERIC1SETvalue,cGENERIC2SDRACTUAL、10008000としてTISAコーディングに変換される。SET動作のTISAコーディングは、指定されない。というのは、SPARCV8Manualが、これらを、プロセッサの実施態様に従って異なるコーディングを有することができる擬似命令として識別するからである。決定されたTISAコーディングを使用して、プリコンパイラ330は、今や、高水準JTAGアクセスをそれに関連するTISAアセンブラ命令に置換することができる。その結果が、Cを使用して指定された次のコードであり、このコードでは、JTAGTAPへの呼出しが、関連するTISAアセンブラコーディングによって置換されている。1include<stdio.h>2include<jtag.h>34charsent_value,receivedvalue;56defineMAX_COUNT256;78voidmainvoid9{10forsent_value=0;sent_value<MAX_COUNT;sent_value11{12asmvolatileSET8,cGENERIC1;13SET00,cTDI;14SIRTDI;15SET24,cGENERIC1;16SETsent_value,cTDI;17SDRTDI;;18asmvolatileSET8,cGENERIC1;19SET01,cTDI;20SIRTDI;21SET16,cGENERIC1;22SETreceived_value,cGENERIC2;23SDRACTUAL;24ifsent_value=receivedvalueexit0;25}26exit1;27}このコードを、フロントエンドアルゴリズム322に入力することができ、フロントエンドアルゴリズム322は、プログラムモデル323を生成する。プログラムモデル323を、バックエンドアルゴリズム324に入力することができ、バックエンドアルゴリズム324は、TISA原子的動作356を含む実行可能TISA2進ファイル1つまたは複数355を生成する。テーブル540のTISAコーディング列544は、TISAアセンブラ命令の2進コーディングを示すたとえば、図4A~4Eに関して図示し、説明したようにSPARCV8ISAを使用するTISAの例示的実施態様に関して定義されるさまざまなルールを使用して。本明細書で説明するように、TISAは、テストされるシステムのテスティングを実行する際のテスト粒度に関して完全な自由を提供するすなわち、TAPレベルからスキャンセグメントレベルまで。図2および図3に示され、図4A~4Eおよび図5A~5Bの例示的TISA実施態様を使用してさらに説明されるように、テストパターンを、テスト生成ツールに対するソフトウェアコンパイラによる明示的照会を使用して計算することができ、ソフトウェアアルゴリズムに関する唯一の制限は、照会自体の解決である。例として、粗なレベルで、SCからTGTへの照会は、テストされるシステムのスキャンチェーン全体を含むことができるたとえば、古典的なBSDLベースのバウンダリスキャンテスティングの場合など。例として、微細なレベルで、SCからTGTへの照会は、レジスタまたはビットさえも含むことができる。たとえば、専用スキャンセグメントプリミティブは、機器アクセスおよびTAP再構成を大幅に加速し、コード再利用を増やし、さまざまな他の利益を提供することができる。例として、粗なレベルと微細なレベルとの間の中間レベルでは、SCからTGTへの照会を、関数的に行うことができるたとえば、IJTAGおよび他の適切な標準規格などの標準規格を使用し、NSDLおよび他の適切なオブジェクト指向記述言語などの記述言語を使用して。この形で、TISAは、デバイス/レジスタアクセスがモデル空間ですなわち、TGT内で解決されることを強制するのではなく、開発者がデバイス/レジスタアクセスをプログラム空間ですなわち、SC内で処理することを可能にし、これによって、開発者が分析粒度を彼らの必要および使用可能なリソースに適合させることを可能にする。さらに、TISAプロセッサが、たとえば自動テスト装置ATEの場合など、十分なリソースを有する環境では、回路モデルの少なくとも一部を、プログラムモデル内で実施することができ、これによって、TISAマシンがベクトルパターンを直接に計算することが可能になる。さらに、TISAは、対話デバッギングローカルにおよび/またはリモートにを含む対話テスティング、並列性、ポータビリティ、および類似物、ならびにそのさまざまな組合せなど、TISAなしでは以前に可能でなかったさまざまな他のシステムテスト機能をサポートすることを可能にする。これらの追加機能に、これからさらに詳細に対処する。図6に、対話テスティング機能をサポートするTISAベースのテスティング環境の実施形態を示す。図6に示されているように、TISAベースのテスティング環境600は、ホストコンピュータHC601、テスティングシステムTS610、およびテストされるシステムSUT620を含む。HC601は、SUT620のテスティングを制御するためにTS610を制御するように構成される。HC601は、メモリ604に結合されたプロセッサ602を含む。プロセッサ602およびメモリ604は、任意の適切なプロセッサおよびメモリとすることができる。メモリ604は、1つまたは複数のデバッガ制御プログラム605を格納する。デバッガ制御プログラム1つまたは複数は、HC601がTS610上で走行するコンピュータプログラム1つまたは複数の実行をトレースし、望まれるか必要な場合にこれを変更することを可能にする。たとえば、デバッガ制御プログラム1つまたは複数605は、GNUDebuggerGDB、dbxデバッガ、Perlデバッガ、Bashデバッガ、Pythonデバッガ、および同様の適切なデバッガプログラム、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。メモリ604は、1つまたは複数のデバッガ表示プログラム606をも格納することができる。デバッガ表示プログラム1つまたは複数は、HC601がデバッガ制御プログラム1つまたは複数605に関連する情報を表示することを可能にする。デバッガ制御プログラム1つまたは複数605に関連する情報を、デバッガ表示プログラム1つまたは複数606によって任意の適切な形でたとえば、1つまたは複数のディスプレイデバイスを使用して表示することができる。たとえば、デバッガ表示プログラム1つまたは複数606は、InsightGDBへのグラフィカルユーザインターフェースである、DataDisplayDebuggerDDD、GDBおよび他のデバッガなどのさまざまなコマンドラインデバッガのグラフィカルユーザインターフェースを提供する、および同様の適切なデバッガ表示プログラム、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。TS610は、SUT620をテストするためにHC601によって制御される。TS610は、TISAと一貫する形でたとえば、図1~図3のTS110に関して図示し、説明したものなど機能するように構成され、さらに、対話テスティングをサポートするたとえば、HC601上で走行するデバッガによるアクセスを使用可能にすることによってように構成される。TS610は、メモリ614に結合されたTISAプロセッサ612を含む。TISAプロセッサ612は、SPARCV8図4A~4Eおよび図5に関して図示し、上で説明した、INTEL、および類似物などの任意の適切なプロセッサを使用して実施することができる。メモリ604は、任意の適切なメモリとすることができる。メモリ614は、1つまたは複数のデバッガプログラムスタブ615を格納する。デバッガプログラムスタブ615は、HC601上で走行する対応するデバッガ制御プログラム1つまたは複数605のデバッガ制御を理解し、これによって、HC601がTS610と通信することを可能にする。たとえば、デバッガスタブ1つまたは複数615は、GDBスタブ、DBXスタブ、Perlスタブ、Bashスタブ、Pythonスタブ、および同様の適切なデバッガプログラムスタブ、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。メモリ614は、TISA2進ファイル616を格納する。TISA2進ファイル616は、本明細書で図2および図3に関して図示し、説明した形でTS610によって生成される。TISA2進ファイル616は、SUT620に対するテスティングを実行するためにTISAプロセッサ612によって実行される。TS610は、TISAプロセッサ612に結合されたテストアクセスポートTAP618をも含む。TAP618は、HC601によって制御されている間にTISAプロセッサ612がSUT620のテスティングを実行することを可能にするために、TISAプロセッサ612とSUT620との間のテストインターフェースを提供する。TAP618は、任意の適切なTAPたとえば、1149.1TAPとすることができる。TISAプロセッサ612は、インターフェース617を使用してTAP618とインターフェースする。インターフェース617は、TAPとテストされるシステムとの間の任意の適切なインターフェースたとえば、TCK、TMS、TDI、TDO、およびオプションでTRSTTAP618が1149.1TAPとして実施される場合をサポートするインターフェースなどとすることができる。図6に示されているように、HC601とTS610との間にインターフェース609がある。インターフェース609は、HC601とTS610との間のローカル通信および/またはリモート通信をサポートすることができる。したがって、HC601は、ローカルにおよび/またはリモートにTS610を介してSUT620の対話テスティングを制御することができる。たとえば、ローカルテスティングに関して、インターフェース609を、汎用非同期送受信回路UARTインターフェース、直列インターフェース、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数として実施することができる。たとえば、リモートテスティングに関して、インターフェース609を、伝送制御プロトコルTCP/インターネットプロトコルIPまたは任意の他の適切な通信プロトコルなどの任意の適切な通信機能を使用して実施することができる。これは、HC601およびTS610が長い地理的距離だけ分離される可能性があり、それでもHC601がSUT620のテスティングを実行するためにTS610を制御することができる、リモートテスティングを可能にする。TISAベースのテスティング環境600では、HC601は、標準的な接続たとえば、UART、TCP/IP、および類似物を介してTS610の動作を制御することによってSUT620のテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。明瞭にするために省略されてはいるが、HC601およびTS610が、追加のプロセッサ、追加のメモリ、内部通信バス、入出力モジュール、追加のサポート回路たとえば、電源、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のコンポーネントを含むことができることを了解されたい。明瞭にするために省略されてはいるが、SUT620を、TISAを使用してテストできる任意のテストされるシステムとすることができることを了解されたい。主に特定のタイプのデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物に関して図示し、説明したが、TISAベースのテスティング環境600を、さまざまな他のデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物、ならびにそのさまざまな組合せを使用して完全に対話的なテスティング機能を使用可能にする形で実施できることを了解されたい。図7に、図6のTISAベースのテスティング環境の例示的実施態様を示す。図7に示されているように、図7の例示的なTISAベースのテスティング環境700は、GNUツールスイートが図5Aの例示的なシステムテスト環境500の対話テスティングをサポートするのに使用される、図6のTISAベースのテスティング環境600の実施態様である。図7に示されているように、例示的なTISAベースのテスティング環境700は、ホストコンピュータHC701、テスティングシステムTS710、およびテストされるシステムSUT720を含む。HC701は、プロセッサ702およびメモリ704を含む。図7のHC701は、デバッガ制御プログラム1つまたは複数605がGDBGDB705を使用して実施され、デバッガ表示プログラム1つまたは複数606がDDDDDD706を使用して実施される、図6のHC601の実施態様である。TS710は、TISAプロセッサ712およびメモリ714を含む。図7のTS710は、TISAプロセッサ612がSPARCV8ISAを使用して実施されSPARCV8TISAプロセッサ712と表される、デバッガプログラムスタブ1つまたは複数615がGDBスタブGDBスタブ715を使用して実施され、TISA2進ファイル616がSPARCV8TISAプロセッサ712に関連するSPARCV8ISAに基づいて生成されるTISA2進ファイル716、図6のTS610の実施態様である。TS710は、SPARCV8TISAプロセッサ712に結合されたテストアクセスポートTAP718をも含む。図7のTS710は、TAP618が1149.1TAP1149.1TAP718を使用して実施される、図6のTS610の実施態様である。SPARCV8TISAプロセッサ712は、インターフェース717を使用して1149.1TAP718とインターフェースする。インターフェース717は、TCK、TMS、TDI、TDO、およびオプションでTRSTをサポートする標準1149.1インターフェースである。SUT720は、図5AのSUT520である。SUT720は、図5AのSUT520のように、異なる基板上の送信器および受信器を含む。1149.1TAP718は、SPARCV8TISAプロセッサ712がHC701によって制御されている間にSUT720のテスティングを実行することを可能にするために、SPARCV8TISAプロセッサ712とSUT720との間のテストインターフェースを提供する。図7に示されているように、HC701とTS710との間にインターフェース709がある。インターフェース709は、HC701とTS710との間のローカル通信および/またはリモート通信たとえば、ネットワークを介するをサポートすることができる。したがって、HC701は、ローカルにおよび/またはリモートにTS710を介してSUT720の対話テスティングを制御することができる。例示的なTISAベースのテスティング環境700では、HC701は、インターフェース709を介してTS710の動作を制御することによってSUT720に対するテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。図7の左側のほとんどが、既存のコンピュータサイエンス要素すなわちHC701全体ならびにTS710上のGDBスタブ715を再利用することを了解されたい。これは、図7の中央部分についても同一であり、中央部分では、HC701とTS710ならびにそれらに関連する副要素との間の類似が明白である。TISAは、システムテスティングを提供するためにこのインフラストラクチャ全体を活用することを可能にする。例として、図5Aのシステムテスト環境500関連する例示的なCプログラム、SVF命令、TISAアセンブラ命令、およびTISAコーディングを含むを参照すると、a変数sent_valueおよびreceived_valueを監視している間のステップごとの実行、btapに送るべき値変数sent_valueのオンザフライ変更、cループ終了条件の変更、dすべての変数の監視、および類似物、ならびにそのさまざまな組合せなど、GDBまたは任意の他の適切なデバッガを活用することによってTISAが使用可能にすることのできる多数の対話テスト動作がある。これらの対話テスト動作は、GDBの標準動作であり、TISAは、上で説明したアルゴリズム部分とテストアクセス部分との間の制御を自動的にハンドオフするTISAの能力に起因して、これらを直接に使用することができる。TISAがない場合には、特殊なツーリングを開発し、各ハンドオフ実施態様に適合させる必要があるはずである。図7の例示的なTISAベースのテスティング環境700を、主に、特定のテストされるシステムの対話テスティングをサポートするのにGNUツールスイートを使用することに関して本明細書で図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、TISAベースのテスト環境での対話テスティング機能を、任意のタイプのテストされるシステムをテストするために任意の適切なツールスイートを使用して実現できることを了解するであろう。図6のTISAベースのテスティング環境600および図7の例示的なTISAベースのテスティング環境700を、主に、テスティングが事前に決定されたアルゴリズムに従ってステップごとに行われる直線的なテスト手順に関して本明細書で図示し、説明したがTISAによって使用可能にされる対話テスティング機能を説明する際の明瞭さのために、TISAによって使用可能にされるコンピュータサイエンス経験およびコンピュータサイエンス技法の活用に起因して、他のより複雑な対話テスティングシナリオが可能であることを了解されたい。TISAによって使用可能にされるより複雑な対話テスティングシナリオの例を、図8に関して図示し、本明細書で説明する。これが、単に1つの例であり、本明細書の教示によって情報を与えられた当業者が多数の他の対話テスティングシナリオおよび対話テスティング応用例でTISAを使用できることを了解されたい。本明細書で説明されるように、粒度と対話との両方をサポートすることに加えて、TISAは、並列性をもサポートする。TISAは、システムテスティングフローをコンピュータサイエンスソフトウェアフローと自然に十分に合併し、したがって、両方のフローの最良の態様を活用することができる。例として、STAPLなどの手法は、定義により、完全に順次的なので、機器の並列制御を扱うのが困難である。さらに、MTCおよびSystemBISTなどの手法は、本質的に順次的であり、シングルタスクであり、したがって、並列性をサポートするためにそのような手法をプログラムすることは、むずかしく、不便であるはずである。対照的に、並列実行は、コンピュータサイエンスでは周知の問題であり、現在は、たとえば、すべてのオペレーティングシステムの根底にある。並列実行をサポートする大量のライブラリが使用可能でありたとえば、POSIXスイート、BOOSTスイート、および類似物、ほとんどの現代のプロセッサは、マルチタスキングおよびコンテキスト切替を効率的にサポートするように設計されているたとえば、たとえばSPARCV8は、回転するレジスタウィンドウを実施する。TISAによって使用可能にされるシステムテスティングフローとコンピュータサイエンスソフトウェアフローとの間の自然な相互作用は、TISAが並列性に対するそのようなコンピュータサイエンス手法を完全に活用することを可能にする。TISAによる並列性機能のサポートは、例によってよりよく理解することができる。例として、図5Aおよび図7のテストされるシステム520の送信器522と受信器526との間のT-Rチャネルのデータ転送速度を最適化するという問題を検討されたい。これは、第1基板521上の送信器522からデータパターンのストリームを送信することと、第2基板525上の受信器526でデータパターンの対応するストリームを受信することと、ビット速度/誤り率を計算し、それ相応に送信器522および/または受信器526のパラメータを調整するためにデータパターンの送信されたストリームおよび受信されたストリームを比較することとを含むはずである。この最適化を、並列に動作する3つのプログラムを使用して効率的に実行することができる。図8に、図5Aおよび図7のテストされるシステムの送信器-受信器チャネルの最適化を実行するための例示的プログラムアーキテクチャを示す。図8に示されているように、例示的なプログラムアーキテクチャは、パターンジェネレータ802、パターン受信器804、およびコンパレータ806を含む。パターンジェネレータ802、パターン受信器804、およびコンパレータ806は、協力して、図5Aおよび図7のテストされるシステム520の送信器522と受信器526との間のT-Rチャネルのデータ転送速度を最適化する。パターンジェネレータ802は、適切な入力データパターンを第1基板521上の送信器522Tに送る。パターンジェネレータ802は、第1基板521B1のスキャンチェーン523を介して送信器522に入力データパターンを供給するために、TAP実例として、図5AのTAP510、図7のTAP718にアクセスすることができる。パターンジェネレータ802は、任意の適切な形でたとえば、図5Aに関して本明細書で説明したコードの行12~13で指定されるように送信器522に入力データパターンを供給することができる。入力データパターンは、送信器522と受信器526との間のT-Rチャネルを最適化するのに適する任意のデータパターンとすることができる。たとえば、入力データパターンを、事前に計算されたパターン、ランダムパターン、および類似物、ならびにそのさまざまな組合せとすることができる。パターン受信器804は、第2基板525上の受信器526Rから適切な出力データパターンを収集する。パターン受信器804は、第2基板525B2のスキャンチェーン527を介して受信器526から出力データパターンを収集するために、TAP実例として、図5AのTAP510、図7のTAP718にアクセスすることができる。パターン受信器804は、任意の適切な形でたとえば、図5Aに関して本明細書で説明したコードの行14~15で指定されるように受信器526から出力データパターンを収集することができる。コンパレータ806は、パターンジェネレータ802およびパターン受信器804と通信する。コンパレータは、入力データパターンと出力データパターンとを比較する。コンパレータ806は、T-Rチャネルのビット伝送速度およびビット誤り率を評価し、この比較の結果に基づいて、T-Rチャネルのパラメータを最適化するために送信器522と受信器526との両方の制御レジスタ明瞭にするために図5Aおよび図7では省略されているにアクセスすることができる。そのような最適化テスティング手順を実行するために、パターンジェネレータ802、パターン受信器804、およびコンパレータ806は、並列に働く必要があり、それぞれが、他とは独立にTAPにアクセスできなければならない。このタイプの制御構造は、TAPを介する1点直列ハンドオフ制御だけをサポートするように開発された伝統的な環境では、コーディングするのが非常にむずかしい。このタイプの制御構造は、やはり同一の直列TAPアクセスパラダイムを共有するMTCまたは他のそのような手法を使用する環境でも、コーディングするのが非常にむずかしい。対照的に、TISAは、テストアクセスに関するそのような仮定を伴って設計されているのではなく、TISAでは、テストアクセスが、他のプロセッサリソースに似た形で処理され、テストアクセス命令は、古典的なISA命令と直接に混合される。TISAを使用すると、図8の最適化テスティング手順を、プロセス、スレッドプロセス間通信IPC、および類似物、ならびにそのさまざまな組合せなどの標準的構造を使用する任意のマルチタスキングオペレーティングシステムによって実行することができる。この形で、パターンジェネレータ802、パターン受信器804、およびコンパレータ806は、TAPへのアクセスを共有することができ、たとえば、たとえばダイクストラのセマフォなどの周知の構造およびアルゴリズムを使用して、すべてのプロセッサリソースについて行われるのと同様に、すべての最終的なTAP共有問題を解決することができる。したがって、既存のシステムテスティング機能は並列性をサポートしないが、TISAが簡単に完全に並列性をサポートすることは明白である。上で説明したように、TISAは、テストアクセス方法または関連するテストプログラム区分に関する仮定を一切設けず、テスト命令は、テスト命令と古典的ISA命令との間の先見的分離を全く伴わずに、古典的ISA命令と同一の形または実質的に同一の形で扱われる。これは、TISAをすべての既存のおよび最もありそうなことに将来のコンピュータサイエンスアルゴリズムおよびコンピュータサイエンス構造と完全に互換にすることを可能にし、これは、既存のテストプロセッサ手法がサポートできないことである。したがって、すべての既存ソフトウェアライブラリをTISAアーキテクチャに移植できることを了解されたい。たとえば、POSIXスイートおよびBOOSTスイートを活用することによって、マルチタスキングおよび並列性を入手することは、簡単であるはずであるたとえば、図8に関して本明細書で図示し、説明したように。さらに、TISAが既存ISAの一般化として入手されるたとえば、図5Aおよび図5Bに関して図示し、説明した例示的なSPARCV8TISA実施態様に関して図示し、説明したように場合には、TISAがそれから開発されたISAが既にそのようなソフトウェアライブラリを含むので、移植が必要でない場合さえあることを了解されたい。さらに、さまざまな他のコンピュータサイエンス技法を、TISAを使用する改善されたシステムテスティングを提供するために利用できることを了解されたい。たとえば、TISAのために活用できるそのようなコンピュータサイエンス技法のいくつかの例は、aプラットフォーム独立コーディングスタイルの使用、bISA対ISAコンバータの使用、cプラットフォーム独立バイトコードを入手するための、たとえばJavaのような、仮想マシン手法の使用、またはTISAになるためのJava仮想マシン自体の拡張の使用、およびdその後に適切なドライバによってプリミティブに変換される、いくつかのTISAソフトウェアインターフェースを標準化するためのアプリケーションプログラミングインターフェースAPIの使用を含む。これらの例が、単にTISAのために活用できるコンピュータサイエンス技法の少数の例であることを了解されたい。図9に、テストされるシステムの少なくとも一部をテストする際のプロセッサによる使用のために適合されたテスト命令セットアーキテクチャTISA命令を含むTISAフローを形成するためにプロセッサの命令セットアーキテクチャISAフローを適合させる方法の一実施形態を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法900のステップの少なくとも一部を、同時にまたは図9に関して図示され説明されるものとは異なる順序で実行することができる。ステップ902では、方法900が開始される。ステップ904では、命令の第1セットを生成する。命令の第1セットは、プロセッサによってサポートされるISA命令を含むすなわち、プロセッサにTISAを提供するために活用されるISA命令。ステップ906では、命令の第2セットを生成する。命令の第2セットは、テストされるシステムに関連するテスト命令を含む。命令の第2セットは、たとえば図2のTGT210に関して図示し、説明したように、図3のTGT310に関して図示し、説明したように、および/またはテスト命令を生成する任意の他の適切な方法を使用して、任意の適切な形で生成することができる。ステップ908では、命令の第1セットおよび命令の第2セットを統合して、これによってTISA命令を形成する。TISA命令は、プロセッサにTISAを提供する。ステップ910では、TISA命令を格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。TISA命令を、任意の他の適切な形で処理することができる。ステップ912では、方法900が終了する。TISAを、任意の適切な形で、たとえば、図10の方法1000に関して図示し、説明するように、図2のテストシステムおよび図11Aの関連する方法1110に関して図示し、説明するように、図3のテストシステムおよび図11Bの関連する方法1120に関して図示し、説明するように、ならびに/またはTISAを形成する任意の適切な方法を使用して、形成することができる。図10に、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法1000のステップの少なくとも一部を、同時にまたは図10に関して図示され説明されるものとは異なる順序で実行することができる。ステップ1002で、方法1000が開始される。ステップ1004では、命令の第1セットを生成する。命令の第1セットは、少なくとも1つのコンピュータサイエンスソフトウェアファイルをコンパイルすることによって生成される命令たとえば、プロセッサによってサポートされるISAのISA命令を含む。ステップ1006では、命令の第2セットを生成する。命令の第2セットは、テストされるシステムに関連する少なくとも1つの記述ファイルをコンパイルすることによって生成されるテスト命令を含む。ステップ1008では、命令の第1セットおよび第2セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第1セットの命令が、命令の第2セットのテスト命令の実行を制御する際の使用のために適合される。ステップ1010では、命令の組み合わされたセットを格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。ステップ1012で、方法1000は終了する。図11Aおよび図11Bに、図9に関して図示し、説明した方法900および/または図10に関して図示し、説明した方法1000のより詳細な実施形態を示す。図11Aに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に特定のシーケンスで実行されるものとして図示され、説明されるが、図11Aの方法1110のステップの少なくとも一部を、図11Aに関して図示し、説明するものとは異なる順序で実行することができる。図11Aを、図2および図2の関連する説明と共に見ることによってよりよく理解することができる。ステップ1111で、方法1000が開始される。ステップ1112では、プログラムモデルを生成する。プログラムモデルは、少なくとも1つのコンピュータサイエンスソフトウェアファイルをコンパイルすることによって生成されたとえば、プロセッサによってサポートされるISAのISA命令、少なくとも1つのコンピュータサイエンスソフトウェアファイルは、少なくとも1つの呼出しを含む。ステップ1113では、命令の第1セットを生成する。命令の第1セットは、プログラムモデルを使用して生成される。少なくとも1つの計算要求も、少なくとも1つのコンピュータサイエンスソフトウェアファイルに含まれる少なくとも1つの呼出しを使用して生成される。ステップ1114では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも1つのシステム記述ファイルをコンパイルすることによって生成される。ステップ1115では、命令の第2セットを生成する。命令の第2セットは、回路モデルおよび少なくとも1つの計算要求を使用して生成される。ステップ1116では、命令の第1セットおよび第2セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第1セットの命令が、命令の第2セットのテスト命令の実行を制御する際の使用のために適合される。ステップ1117では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。ステップ1118では、方法1000が終了する。図11Bに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に順次実行されるものとして図示され、説明されるが、図11Bの方法1120のステップの少なくとも一部を、同時にまたは図11Bに関して図示し、説明するものとは異なる順序で実行することができる。図11Bを、図3および図3の関連する説明と共に見ることによってよりよく理解することができる。ステップ1121で、方法1100が開始される。ステップ1122では、少なくとも1つの前処理済みコンピュータサイエンスソフトウェアファイルおよび少なくとも1つのテスト動作記述ファイルを、少なくとも1つのコンピュータサイエンスソフトウェアファイルを前処理することによって生成する。ステップ1123では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも1つのシステム記述ファイルおよび少なくとも1つのテスト動作記述ファイルをコンパイルすることによって生成される。ステップ1124では、テスト動作のセットを生成する。テスト動作のセットは、回路モデルを使用して生成される。テスト動作のセットからのテスト動作は、テストプリミティブたとえば、回路モデルを生成するテスト生成ツールによって定義されるテストプリミティブのセットを使用して記述される。テストプリミティブのセットは、テストされるシステムをテストする際の使用のために適合されたテスト動作を含む。ステップ1125では、テスト動作のセットのテストプリミティブを命令セットアーキテクチャのソフトウェア命令と組み合わせての使用のために適合されたテスト命令に変換することによって、テスト動作のセットをテスト命令のセットに変換する。ステップ1126では、プログラムモデルを生成する。プログラムモデルは、少なくとも1つの前処理済みコンピュータサイエンスソフトウェアファイルおよびテスト命令のセットをコンパイルすることによって生成される。ステップ1127では、命令の組み合わされたセットを生成する。命令の組み合わされたセットは、プログラムモデルを使用して生成される。命令の組み合わされたセットは、a少なくとも1つの前処理済みコンピュータサイエンスソフトウェアファイルから決定されたソフトウェア命令およびbテスト命令のセットからのテスト命令を含む。ステップ1128では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。ステップ1129では、方法1120が終了する。図12に、TISAプロセッサアーキテクチャの例示的実施形態を示す。図12に示されているように、TISAプロセッサアーキテクチャ1200は、TISAプロセッサ1210およびメモリ1220を含む。TISAプロセッサ1210は、SPARCV8プロセッサ、INTELプロセッサ、または任意の他の適切なプロセッサなど、TISAを使用するシステムテスティングを実行するのに適する任意のプロセッサとすることができる。メモリ1220は、ランダムアクセスメモリ、永続メモリ、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数を含む、TISAを使用するシステムテスティングをサポートするためのTISAプロセッサ1210による使用に適する任意のメモリを含むことができる。メモリ1220は、テストプログラム、TISA命令、テスティングデータ、および類似物、ならびにそのさまざまな組合せなど、TISAを使用するシステムテスティングを実行するのに必要な任意の情報を格納することができる。一実施形態では、たとえば、図12のTISAプロセッサアーキテクチャ1200は、図2および図3に関して図示し、説明したTISAフローをサポートすることができる。一実施形態では、たとえば、図12のTISAプロセッサアーキテクチャ1200は、図6に関して図示し、説明したテスティングシステム610のTISAプロセッサ612およびメモリ614に似た形で動作することができる。たとえば、図12のTISAプロセッサアーキテクチャ1200を、図7に関して図示し、説明したテスティングシステム710内など、SPARCV8TISAプロセッサおよび関連するメモリを使用して実施することができる。そのような実施形態では、TISAプロセッサ1210自体が、ISA命令とTISA命令との両方を解釈し、実行する。一実施形態では、テストされるシステムの少なくとも一部をテストアクセスポートTAPを介してテストする際に使用される装置は、テスト命令セットアーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をTAPを介してテストするためにテスト命令セットアーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セットアーキテクチャの命令のセットは、プロセッサによってサポートされる命令セットアーキテクチャISAの複数の命令を含む命令の第1セットと、TAPに関連する複数のテスト命令を含む命令の第2セットとを含み、命令の第1クラスの命令および命令の第2クラスの命令は、これによってテスト命令セットアーキテクチャの命令のセットを形成するために統合される。一実施形態では、テストされるシステムの少なくとも一部をテストアクセスポートTAPを介してテストする際に使用されるTISAプロセッサは、プロセッサによってサポートされる命令セットアーキテクチャISAの命令を含む命令の第1クラスと、TAPに関連するテスト命令を含む命令の第2クラスとを含み、命令の第1セットのISA命令および命令の第2セットのテスト命令は、テストされるシステムの少なくとも一部をテストするために適合されたTISAを形成するために統合される。一実施形態では、テストされるシステムSUTをテストアクセスポートTAPを介してテストするコンピュータプロセッサは、TAPを介するテストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セットアーキテクチャTISAに従って命令を処理するように構成された回路網を含む。TISAは、第1タイプの複数の命令および第2タイプの複数の命令を含み、命令の第1タイプは、コンピュータプロセッサによってサポートされる命令セットアーキテクチャISAの命令を含み、命令の第2タイプは、TAPを介してテストされるシステムをテストするためのテスト命令を含む。主にTISAプロセッサが特定の形でたとえば、異なるクラスおよび/またはタイプの命令を記述するのに特定の言語を使用して定義される実施形態に関して上で図示し、説明したが、TISAを、本明細書で提供されるさまざまなTISAの図示および説明によって完全にサポートされる他の形で定義できることを了解されたい。主に、TISAをサポートするのに単一プロセッサを使用してTISAプロセッサアーキテクチャが実施される実施形態に関して本明細書で図示され、説明されるが、他の実施形態では、TISAプロセッサアーキテクチャを、複数のプロセッサを使用して実施することができる。図13に、システムテスティング機能を提供するために複数のプロセッサを利用するテストプロセッサアーキテクチャの例示的実施形態を示す。図13に示されているように、テストプロセッサアーキテクチャ1300は、通信経路1330を介して通信する主プロセッサ1310および副プロセッサ1320を含む。主プロセッサ1310は、SPARCV8プロセッサ、INTELプロセッサ、または任意の他の適切なプロセッサなど、システムテスティングをサポートするのに適する任意のプロセッサとすることができる。主プロセッサ1310は、テストされるシステムをテストする命令を実行する。一実施形態では、たとえば、主プロセッサ1310は、図12のTISAプロセッサアーキテクチャ1200のCPU1210によってサポートされる機能に似たテスティング機能をサポートすることができるたとえば、テストプロセッサアーキテクチャ1300がTISAを利用する場合に。一実施形態では、たとえば、主プロセッサ1310は、TISAを利用しないテストプロセッサアーキテクチャ内のテストするプロセッサによってサポートされるテスティング機能をサポートすることができる。主プロセッサ1310は、さまざまな他のテスティング機能をサポートすることができる。副プロセッサ1320は、SPARCV8プロセッサ、INTELプロセッサ、または任意の他の適切なプロセッサなど、システムテスティングをサポートするのに適する任意のプロセッサとすることができる。副プロセッサ1320は、テストされるシステム明瞭さのために省略されているへのテストアクセスポートTAPインターフェースをサポートする。このTAPインターフェースは、任意の適切なTAPとインターフェースすることができる。たとえば、このTAPインターフェースは、IEEE1149.1TAPまたはテストされるシステムをテストするのに使用できる任意の他の適切なTAPへのインターフェースを提供することができる。主プロセッサ1310および副プロセッサ1320は、テストされるシステムの少なくとも一部のテストを実行するために協力する。主プロセッサ1310は、テストされるシステムをテストするテスト命令を実行する。このテスト命令は、TISAのテスト命令とすることができテストプロセッサアーキテクチャ1300がTISAを利用する場合、あるいはTISAに関連しないテスト命令とすることができるテストプロセッサアーキテクチャ1300がTISAを利用しない場合。主プロセッサ1310は、テスト命令の実行中に、テストされるシステムのTAPの制御に関係する命令たとえば、テストされるシステムのTAPコントローラに入力データをロードする命令、テストされるシステムのTAPコントローラから出力データを読み取る命令、および同様の命令、ならびにそのさまざまな組合せなどを検出する。主プロセッサ1310は、副プロセッサ1320にTAP関連命令を供給する。副プロセッサ1320は、主プロセッサ1310からそのTAP関連命令を受け取る。副プロセッサ1320は、そのTAP関連命令を実行する。主プロセッサ1310は、副プロセッサ1320が主プロセッサ1310から受け取ったTAP関連命令を実行する間に、テスト命令の実行を継続する。この形で、主プロセッサ1310は、副プロセッサ1320がテストされるシステムのTAPを介するスキャン動作を制御する間に、コンテキスト切替を実行し、動作を継続することができる。これは、単一プロセッサ手法を使用すると困難である。というのは、単一プロセッサがTAPを制御している間に、その単一プロセッサが、他の動作の実行を止められるからである。したがって、テストプロセッサアーキテクチャ1300内のような複数プロセッサの使用は、特にTAPを介する動作が通常はプロセッサが単一の動作を実行するのに要する時間と比較して長い時間を要することを考慮すると、ハイエンドプロセッサを使用する必要なしにテスティング効率の大幅な改善を提供する。テストされるシステムの少なくとも一部のテストを実行するための主プロセッサ1310と副プロセッサ1320との間の協力は、通信経路1330によって容易にされる。通信経路1330は、主プロセッサ1310と副プロセッサ1320との間通信の任意の適切な手段を使用して実施することができ、この手段は、テストプロセッサアーキテクチャ1300がそれを用いて実施されるマルチプロセッサアーキテクチャのタイプに依存する可能性がある。たとえば、通信経路1330は、メインプロセッサインターフェースバス、補助プロセッサインターフェース、通信インターフェースたとえば、シリアライザ-デシリアライザSERDESインターフェースまたは他の適切な通信インターフェース、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。明瞭さのために省略されているが、テストプロセッサアーキテクチャ1300が、メモリたとえば、ランダムアクセスメモリ、永続メモリ、キャッシュメモリ、および類似物、ならびにそのさまざまな組合せを含むことを了解されたい。テストプロセッサアーキテクチャ1300のメモリは、主プロセッサ1310および副プロセッサ1320によって共有されるメモリ、主プロセッサ1310に専用のメモリ、副プロセッサ1320に専用のメモリ、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。明瞭さのために省略されているが、テストプロセッサアーキテクチャ1300が、バス、I/O回路、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のサポート回路を含むことができることを了解されたい。図13のテストプロセッサアーキテクチャ1300を、複数の形で実施することができる。一実施形態では、たとえば、テストプロセッサアーキテクチャは、中央処理装置CPUがシステムテスティングをサポートするためにテストコプロセッサユニットTCPUと協力する、テストコプロセッサユニットアーキテクチャを使用することができる。例示的実施形態を、図14に関して図示し、説明する。一実施形態では、たとえば、テストプロセッサアーキテクチャは、中央処理装置CPUがシステムテスティングをサポートするためにテスト付属プロセッサユニットTAPUと協力する、テスト付属プロセッサユニットアーキテクチャを使用することができる。例示的実施形態を、図15に関して図示し、説明する。図14に、テストコプロセッサアーキテクチャの例示的実施形態を示す。テストコプロセッサアーキテクチャ1400は、TISAを使用するシステムテスティングをサポートするためのTISAプロセッサアーキテクチャとしての使用に適する。テストコプロセッサアーキテクチャ1400は、TISAを使用しないシステムテスティングをサポートするためのテストプロセッサアーキテクチャとしての使用にも適する。テストコプロセッサアーキテクチャ1400は、中央処理装置CPU1410、テストコプロセッサユニットTCPU1420、メインメモリ1430、およびフラッシュメモリ1440を含む。テストコプロセッサアーキテクチャ1400は、メインプロセッサインターフェースバス1451を含む。CPU1410、TCPU1420、メインメモリ1430、およびフラッシュメモリ1440は、それぞれ、メインプロセッサインターフェースバス1451に結合されるまたは、他の形でこれと通信できるように構成される。テストコプロセッサアーキテクチャ1400は、補助プロセッサインターフェース1452をも含むことができ、補助プロセッサインターフェース1452は、CPU1410およびTCPU1420を直接に結合し、これによって、CPU1410とTCPU1420との間の直接通信を可能にする。CPU1410は、テストされるシステムのシステムテスティングを実行するのに適する任意のCPUとすることができる。CPU1410は、図13に関して図示し、説明した主プロセッサ1310によってサポートされるテスティング機能をサポートする。TCPU1420は、テストされるシステムのシステムテスティングを容易にするのに適する任意のCPUとすることができる。TCPU1420は、テストアクセスポートTAPインターフェース1460をサポートし、TAPインターフェース1460は、任意の適切なTAPたとえば、IEEE1149.1TAPまたはテストされるシステムをテストするのに使用される任意の他の適切なTAPなどとインターフェースすることができる。TCPU1420は、図13に関して図示し、説明した副プロセッサ1320によってサポートされるテスティング機能をサポートする。CPU1410およびTCPU1420は、図13に関して図示し、説明した主プロセッサ1310および副プロセッサ1320に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。CPU1410およびTCPU1420は、TCPU1420がテスティング中にテストされるシステムのTAPを制御するTAP関連命令を実行する間にCPU1410がテスト命令を処理する動作を継続することを可能にするために、命令例外処理を利用する。CPU1410は、テストされるシステムをテストするテスト命令を実行する。CPU1410は、テスト命令の実行中に命令例外すなわち、テストされるシステムのTAPの制御に関係する命令を検出し、その命令例外をTCPU1420に供給する。TCPU1420は、CPU1410からその命令例外を受け取り、その命令例外を処理し、TCPU1420が、CPU1410が他のタスクたとえば、他のテスティング命令の実行を実行するために動作し続ける間にその命令例外を処理できるようになっている。言い換えると、CPU1410およびTCPU1420は、システムテスティング中に協力し、TCPU1420がCPU1410によって検出された命令例外を処理する間にCPU1410がコンテキストを切り替え、他のタスクを実行するために動作し続けられるようにし、これによって、システムテスティング効率を改善する。一実施形態では、CPU1410は、たとえばCPU1410の性能を改善するために、キャッシュ1411を含む。一実施形態では、TCPU1420は、直接メモリアクセスDMAユニット1421を含み、DMAユニット1421は、システムテスティングをサポートして使用するのに適する任意のタイプのDMAユニットとすることができる。一実施形態では、たとえば、DMAユニット1421は、スキャッタ/ギャザS/GDMAユニットである。TCPU1420は、CPU1410から受け取った命令例外を処理するためおよびメモリ内に格納された実体的なデータに効率的にアクセスするためにDMAユニット1421を利用することができる。一実施形態では、CPU1410は、命令例外に出会う前に、S/GDMAテーブルを構成することができる。一実施形態では、TCPU1420は、特殊化されたTCPU命令のセットをサポートする。特殊化されたTCPU命令のセットは、TAPアクセスおよびTAP制御をサポートすることができる。特殊化されたTCPU命令のセットを、TAP状態機械に対して特定のTAP動作を実行するためにTCPU1420によって使用することができる。CPU1410およびTCPU1420は、CPU1410によるテスト命令の実行、TCPU1420による命令例外処理、TCPU1420によるTCPU命令の実行、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメインメモリ1430および/またはフラッシュメモリ1440を利用する。メインメモリ1430は、任意の適切なプロセッサメモリとすることができる。フラッシュメモリ1440は、任意の適切なフラッシュメモリまたは任意の他の適切な形の永続メモリとすることができる。CPU1410およびTCPU1420は、調停されるアクセスを用いてメモリを共有する。CPU1410およびTCPU1420は、情報を交換するためにメモリを共有することもできる。主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、CPU1410およびTCPU1420によって実行される機能をサポートするために使用できることを了解されたい。CPU1410およびTCPU1420は、CPU1410とTCPU1420との間の通信、CPU1410および/またはTCPU1420とテストコプロセッサアーキテクチャ1400の他のコンポーネントたとえば、メインメモリ1430、フラッシュメモリ1440、および他のコンポーネントとの間の通信、および類似物、ならびにそのさまざまな組合せを使用して、テストされるシステムのテスティングを実行する。この通信を、メインプロセッサインターフェースバス1441および補助プロセッサインターフェース1452の一方または両方を使用してサポートすることができる。CPU1410とTCPU1420との間の通信は、命令例外通知、割込みアクセス、DMA調停、および類似物、ならびにそのさまざまな組合せに関連する通信を含むことができる。CPU1410およびTCPU1420とテストコプロセッサアーキテクチャ1400の他のコンポーネントとの間の通信は、メモリからの読取、メモリへの書込、および/またはテストされるシステムをテストするのを支援して実行できる任意の他のタスクに関連する通信を含むことができる。図15に、テスト付属プロセッサアーキテクチャの例示的実施形態を示す。テスト付属プロセッサアーキテクチャ1500は、TISAを使用するシステムテスティングをサポートするTISAプロセッサアーキテクチャとしての使用に適する。テスト付属プロセッサアーキテクチャ1500は、TISAを使用しないシステムテスティングをサポートするテストプロセッサアーキテクチャとしての使用にも適する。テスト付属プロセッサアーキテクチャ1500は、中央処理装置CPU1510およびテスト付属プロセッサユニットTAPU1520を含む。CPU1510およびTAPU1520は、同一基板上に存在することができ、あるいは、異なる基板上に存在することができる。CPU1510は、テストされるシステムのシステムテスティングを実行するのに適する任意のCPUとすることができる。CPU1510は、図13に関して図示し、説明した主プロセッサ1310によってサポートされるテスティング機能をサポートする。CPU1510は、それに関連するメインメモリ1530M、フラッシュメモリ1530F、および入出力モジュール1540を有する。CPU1510は、それに関連するメインプロセッサインターフェースバス1550を有する。CPU1510、メインメモリ1530M、フラッシュメモリ1530F、および入出力モジュール1540は、それぞれ、メインプロセッサインターフェースバス1550に結合されるまたは、他の形でこれと通信できるように構成される。一実施形態では、CPU1510は、たとえばCPU1510の性能を改善するために、キャッシュ1511を含む。TAPU1520は、テストされるシステムのシステムテスティングを容易にするのに適する任意のCPUとすることができる。TAPU1520は、入出力モジュール1521を含む。TAPU1520は、テストアクセスポートTAPインターフェース1590をサポートし、TAPインターフェース1590は、任意の適切なTAPたとえば、IEEE1149.1TAPまたはテストされるシステムをテストするのに使用される任意の他の適切なTAPなどとインターフェースすることができる。TAPU1520は、図13に関して図示し、説明した副プロセッサ1320によってサポートされるテスティング機能をサポートする。TAPU1520は、それに関連するローカルテストメモリ1560を有する。TAPU1520は、それに関連する内部インターフェースバス1570を有する。TAPU1520およびローカルテストメモリ1560は、それぞれ、内部インターフェースバス1570に結合されるまたは、他の形でこれと通信できるように構成される。CPU1510に関連する入出力モジュール1540およびTAPU1520の入出力モジュール1521は、CPU1510とTAPU1520との間の通信を使用可能にする通信インターフェース1580をサポートする。通信インターフェース1580は、CPU1510からTAPU1520へのTAP関連通信のストリーミングをサポートする。一実施形態では、CPU1510に関連する入出力モジュール1540およびTAPU1520の入出力モジュール1521は、シリアライザ-デシリアライザSERDES通信機能をサポートし、したがって、通信インターフェース1580は、SERDESベースの通信インターフェースである。この実施形態では、SERDESベースの通信インターフェース1580を、任意の適切なSERDES通信プロトコルたとえば、ギガビットイーサネットGigE、SerialRapidIOSRIO、PeripheralComponentInterconnectExpressPCIe、および類似物などを使用して実施することができる。主にCPU1510とTAPU1520との間のSERDESベースの通信の使用に関して図示され、本明細書で説明されるが、他の適切な通信機能を、CPU1510とTAPU1520との間の通信をサポートするために使用することができる。CPU1510およびTAPU1520は、図13に関して図示し、説明した主プロセッサ1310および副プロセッサ1320に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。CPU1510およびTAPU1520は、TAPU1520がテスティング中にテストされるシステムのTAPを制御するTAP関連命令を実行する間にCPU1510がテスト命令を処理するために動作を継続することを可能にするために、通信インターフェース1580を介するコマンドストリーミングを利用する。CPU1510は、テストされるシステムをテストするテスト命令を実行する。CPU1510は、それらのテスト命令の実行中に、テストされるシステムのTAPの制御に関係する命令を検出する。CPU1510は、それらのTAP関連命令を通信インターフェース1580を介してTAPU1520にすなわち、通信インターフェース1580を介する伝搬のために、CPU1510からメインプロセッサインターフェースバス1550を介して入出力モジュール1540に伝搬させる。TAPU1520は、CPU1510からTAP関連命令を受け取り、CPU1510が他のタスクたとえば、他のテスティング命令の実行を実行するために動作し続ける間にTAPU1520がTAPの制御を処理できるように、それらのTAP関連命令を処理する。言い換えると、CPU1510およびTAPU1520は、TAPU1520がCPU1510によって検出されたTAP関連命令を処理する間にCPU1510がコンテキストを切り替え、他のタスクを実行するために動作し続けられるように、システムテスティング中に協力し、これによってシステムテスティング効率を改善する。一実施形態では、CPU1510によって検出され、TAPU1520によって処理されるTAP関連命令は、TAPU1520への伝搬のためにCPU1510によってパケット化される。一実施形態では、CPU1510によって検出され、TAPU1520によって処理されるTAP関連命令は、TAPU1520によってサポートされるオペコードを含む。1つのそのような実施形態では、TAP関連命令は、CPU1510に関連するメモリとTAPU1520に関連するメモリとの間たとえば、メインメモリ1530Mとローカルテストメモリ1560との間でブロックメモリコピーを実行する際の使用に適合された1つまたは複数の拡張コマンドを含むこともできる。CPU1510は、テスト命令の実行、TAP関連命令の検出、TAP関連命令のパケット化、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメインメモリ1530Mおよび/またはフラッシュメモリ1530Fを利用する。メインメモリ1530Mは、任意の適切なプロセッサメモリとすることができる。フラッシュメモリ1530Fは、任意の適切なフラッシュメモリまたは任意の他の適切な形の永続メモリとすることができる。TAPU1520は、CPU1510から受け取ったTAP関連命令の格納、CPU1510から受け取ったTAP関連命令の処理、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにローカルテストメモリ1560を利用する。ローカルテストメモリ1560は、任意の適切なプロセッサメモリとすることができる。一実施形態では、ローカルテストメモリ1560を、比較的小さくすることができる。というのは、ローカルテストメモリ1560が、スキャンチェーン全体オンチップメモリ内で要求される場合があるようにではなく、テストされるシステムのスキャンチェーンのスキャンチェーンセグメントの処理を扱うからである。主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、CPU1510およびTAPU1520によって実行される機能をサポートするために使用できることを了解されたい。主にTISAを実施するためのコプロセッサアーキテクチャまたは付属プロセッサアーキテクチャの使用に関して図示され、本明細書で説明されるが、TISAを、任意の適切なプロセッサアーキテクチャを使用して実施でき、このプロセッサアーキテクチャが、コプロセッサアーキテクチャまたは付属プロセッサアーキテクチャ以外のプロセッサアーキテクチャを含むことができることを了解されたい。したがって、TISAプロセッサアーキテクチャを、さまざまな他の形で複数のプロセッサを使用して実施することができ、これらの形のうちの少なくともいくつかは、TISAをサポートするための3つ以上のプロセッサの使用を含むことができる。主にTISAアーキテクチャを実施するためのコプロセッサアーキテクチャまたは付属プロセッサアーキテクチャの使用に関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、コプロセッサアーキテクチャおよび付属プロセッサアーキテクチャを、それぞれ、他のタイプのテスティングアーキテクチャすなわち、TISAを使用しない他のテスティングアーキテクチャを実施するのに使用できることを了解するであろう。テストコプロセッサアーキテクチャおよびテスト付属プロセッサアーキテクチャは、それぞれがTISAを2つの通信するプロセッサによって実行することを可能にするという点で機能的に似ていることを了解されたい。所与のアプリケーションで、この2つのアーキテクチャの間の選択は、使用可能なリソース、コスト、性能、物理的制約同一チップ内、異なるチップおよび/または基板内での統合、あるいはその任意の組合せ、ならびに任意の他の実施態様パラメータなど、実施態様依存パラメータを基礎として設計者が行うことができる。主にテストコプロセッサアーキテクチャおよびテスト付属プロセッサアーキテクチャに関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、これらの実施態様考慮事項が、すべての他のタイプのテスティングアーキテクチャ/インフラストラクチャにあてはまることを了解するであろう。図示され、本明細書で説明されるTISAプロセッサアーキテクチャは、システムテスティングを実行する際に使用されるすべての適切なTISAを使用することができる。TISAプロセッサアーキテクチャと共に使用されるように適合されたTISAの1つの例示的実施形態の説明が、これに続く。TISAのこの例示的実施形態は、図示され、本明細書で説明されるスキャンセグメントレベルプリミティブの実施態様である。スキャンセグメントレベル抽象化レベルでは、テストされるシステムのスキャンチェーン全体が、セグメントに分割され、これらのセグメントは、アルゴリズムのデータアトムとして使用される。テストされるシステムを、アルゴリズム開発者人間および/または自動化ツールとすることができるによってスキャンセグメントに区分できることを了解されたい。スキャン動作をスキャンセグメントレベルで実行することを可能にするためのTISAの使用のより一般的な説明すなわち、この例示的なTISA実施態様とは独立な説明を、下で詳細に提供する。TISAの次の実施形態は、これらのスキャンセグメントを定義し、処理することのできるレジスタおよび命令のセットを処理する。次の実施形態は、32ビットサイズのTISAに基づくが、これを任意の他の語サイズたとえば、16ビット、64ビット、または任意の他の適切な語サイズに適合させることができる。図16に、TISAプロセッサによって使用できる例示的なレジスタセットを示す。例示的なTISAは、それぞれ図16A~16Dに示された、4つのレジスタセットレジスタセットR1からR4と表されるを含む。図16Aに示されているように、第1レジスタセットR1は、次のユーザアクセス可能データレジスタを含む。StatusRegister状況状態情報を含む32ビットレジスタControlRegisterコマンドエンコーディングを含む32ビットレジスタBlockRegisterスキャンデータインギャザデータおよびデータアウトスキャッタデータを書き込むべき場所を間接的にポイントする事前にフォーマットされたデータ構造へのメモリ内のオフセットを含む32ビットレジスタ[スキャッタ/ギャザセグメント記述にアクセスするすべてのスキャン動作および比較動作に使用される]ScanLengthRegisterスキャンされるべきままである現在のビット数が常駐する32ビットレジスタブロックモードオペコードのスキャッタ/ギャザセグメント記述から自動的に取り込まれもするScanStateRegisterスキャン動作のstartState、scanState、およびendStateを表す4ビットの3つのバンクを含む32ビットレジスタ。4ビットは、TAP状態機械の16個の状態のエンコーディングを表すブロックモードでスキャッタ/ギャザセグメント記述から取り込まれもするUserDataRegisters[1~11]小さいスキャン動作およびデータ再利用のためのスキャンセグメントデータを含む32ビットレジスタソースレジスタまたは宛先レジスタになることができる図16Bに示されているように、第2レジスタセットR2は、次の内部スクラッチレジスタを含む。BlockPointerRegisterMultipleScan命令中に処理される現在のスキャッタ/ギャザセグメント記述参照をポイントする32ビットレジスタBlockCountRegisterMultipleScan命令中に処理されるスキャッタ/ギャザセグメント記述のカウントを含む32ビットレジスタInstructionRegister現在のオペコードがデコーディングのために置かれる32ビットレジスタ図16Cに示されているように、第3レジスタセットR3は、次のスキャッタ/ギャザセグメント記述レジスタを含む。BlockOffsetField64ビットアーキテクチャが使用される時のアドレスのバンクを記述する32ビット数ScanLengthFieldこのセグメントについてスキャンすべきビット数を指定する32ビット数StateTraversalFieldそれぞれこのスキャン動作の開始状態、スキャン状態、および終了状態を表す4ビットの3つのフィールド各4ビットは、16状態TAP状態機械状態を表すSourceLocationFieldTDIデータがメモリ内のどこに存在するのかに関する32ビットベースアドレスDestinationLocationFieldTDOデータがメモリ内で格納される場所に関する32ビットベースアドレスExpectedValueField期待されるベクトルがメモリ内のどこに存在するのかに関する32ビットベースアドレスResponseLocationField取り込まれたTDIデータがメモリ内のどこに存在するのかに関する32ビットベースアドレスMaskField比較動作を制限するのに使用されるMASKデータがメモリ内のどこに存在するのかに関する32ビットベースアドレスResultLocationField比較の結果がメモリ内で格納される場所に関する32ビットベースアドレス図16Dに示されているように、第4レジスタセットR4は、次のマルチブロックスキャッタ/ギャザセグメント記述レジスタを含む。BlockOffsetField64ビットアーキテクチャが使用される時のアドレスのバンクを記述する32ビット数BlockCountFieldこのMultiBlockスキャンによって表されるスキャンセグメントの個数を定義する32ビット数MultiBlockスキャン動作中にBlockCountRegisterを初期化するのに使用されるScatterGatherOpcodeField関連するScatterGatherBlockFieldによってポイントされるスキャッタ/ギャザセグメント記述に使用される32ビットコマンドオペコードScatterGatherBlockField前のScatterGatherOpcodeFieldに関連するスキャッタ/ギャザセグメント記述がメモリ内で配置される場所に関する32ビットアドレス例示的なTISAレジスタセットを、任意の適切な形で変更できることを了解されたい。たとえば、例示的なレジスタセットのそれぞれを、より少数の、より多数の、および/または異なるレジスタを含むように変更することができる。たとえば、例示的なレジスタを、より少数の、より多数の、および/または異なるセットに再グループ化することができる。たとえば、より少数の、より多数の、および/または異なるレジスタセットを使用することができる。言い換えると、例示的なTISAレジスタセットを、TISAプロセッサアーキテクチャを実施するためにTISA命令セットと共に使用するのに適する任意の他のTISAレジスタセット1つまたは複数に置換することができる。例示的なTISAは、システムテスティングを実行する際に使用される任意の適切なTISA命令セットすなわち、コマンド辞書を使用することができる。例示的なTISA命令セットは、次のオペコードを含み、これらのオペコードは、図16A~16Dに関して図示され、説明されたレジスタセットR1からRならびに図示され、本明細書で説明されるオリジナルISAレジスタセットを操作するのに利用することができる。StateTransition<TMSValue>,<TCKcycles>このオペコードは、所与の個数のTCKクロックサイクルの間にTMSの値を使用してTAP状態機械をトラバースするのに使用される。このオペコードは、TAP状態機械の状態の間で一般的な状態遷移を実行するのに使用される。<TMSValue>は、単一ビットを表し、<TCKcycles>は、オペコードの残りのデータビットを表す。RunTest<startState>,<testState>,<endState>このオペコードは、<startState>から<testState>に遷移し、ScanLengthRegisterによって指定される個数のTCKサイクルの間に<testState>でループするのに使用される。このオペコードは、ルーピングの結末として<endState>に遷移するのに使用される。ScanRegister<sourceregister>,<destinationregister>[,<expectedregister>][,<maskregister>]このオペコードは、ユーザデータレジスタ<sourceregister>内のデータをスキャンし、取り込まれた値をユーザデータレジスタ<destinationregister>に格納するのに使用される。<expected_register>が存在する場合には、存在するならば最終的に<mask_register>を使用して、取り込まれた値をこれと比較し、それに従ってエラーを送出する。スキャンされるビット数は、ScanLengthRegister内で定義される0<=n<32。開始状態、スキャン状態、および終了状態は、ScanStateRegister内で定義される。ScanRegisterZero<destinationregister>[,<expectedregister>][,<maskregister>]このオペコードは、すべて0のベクトル値をスキャンし、取り込まれた値をユーザデータレジスタ<destinationregister>に格納するのに使用される。スキャンされるビット数は、ScanLengthRegister内で定義される0<=n<32。開始状態、スキャン状態、および終了状態は、ScanStateRegister内で定義される。<expected_register>および<mask_register>は、ScanRegister命令と同様に使用される。ScanRegisterOne<destinationregister>[,<expectedregister>][,<maskregister>]このオペコードは、すべて1のベクトルをスキャンし、取り込まれた値をユーザデータレジスタ<destinationregister>に格納するのに使用される。スキャンされるビット数は、ScanLengthRegister内で定義される0<=n<32。開始状態、スキャン状態、および終了状態は、ScanStateRegister内で定義される。<expected_register>および<mask_register>は、ScanRegister命令と同様に使用される。ScanBlockこのオペコードは、SUTに対してBlockRegisterによってポイントされるデータをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定する。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。TDOからのデータは、保存されない。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。ScanBlockCaptureこのオペコードは、SUTに対してBlockRegisterによってポイントされるデータをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定する。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。TDOから取り込まれたデータは、保存される。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。ScanBlockZeroCaptureこのオペコードは、SUTに対してすべて0のデータベクトルをスキャンするのに使用され、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、BlockRegisterによって定義されるレジスタに結果を取り込む。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。ScanBlockZeroこのオペコードは、SUTに対してすべて0のデータベクトルをスキャンするのに使用され、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、結果は取り込まれない。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。ScanBlockOneCaptureこのオペコードは、SUTに対してすべて1のデータベクトルをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、BlockRegisterによって定義されるレジスタに結果を取り込む。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。ScanBlockOneこのオペコードは、SUTに対してすべて1のデータベクトルをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、結果は取り込まれない。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。例示的なTISA命令セットは、明示的な値を使用する次のレジスタ変更命令を含む。LoadRegisterExplicit<constvalue>,<registername>この命令は、<constvalue>の定数値を、<registername>によって名前を指定されたレジスタにロードする。CopyRegister<sourceregister>,<destinationregister>この命令は、<sourceregister>として名前を指定されたレジスタの内容を<destinationregister>によって名前を指定されたレジスタにコピーする。例示的なTISA命令セットは、暗黙の値を使用する次のレジスタ変更命令含む。LoadRegisterImplicit<userdataregister>,<registername>この命令は、名前を指定された<userdataregister>内の値を、実際のデータが存在するメモリ位置へのポインタ参照として使用し、参照された値を<registername>によって名前を指定されたレジスタに格納する。例示的なTISA命令セットは、次のレジスタ保存命令を含む。StoreRegisterImplicit<registername>,<userdataregister>この命令は、名前を指定された<userdataregister>内の値を、<registername>によって名前を指定されたレジスタ内の値が格納されるメモリ位置へのポインタ参照として使用する。StoreRegisterExplicit<registername>,<constvalue>この命令は、<registername>によって名前を指定されたレジスタの値を、<constvalue>によって指定されるメモリ位置に格納する。例示的なTISA命令セットは、次の、レジスタに対する論理演算を含む。AND<sourceregister>,<destinationregister>この演算は、<sourceregister>と<destinationregister>との間の論理AND演算を実行し、結果の値を<destinationregister>に置く。OR<sourceregister>,<destinationregister>この演算は、<sourceregister>と<destinationregister>との間の論理OR演算を実行し、結果の値を<destinationregister>に置く。XOR<sourceregister>,<destinationregister>この演算は、<sourceregister>と<destinationregister>との間の論理XOR演算を実行し、結果の値を<destinationregister>に置く。NOT<sourceregister>,<destinationregister>この演算は、<sourceregister>に対して論理NOT演算を実行し、結果の値を<destinationregister>に置く。XORM<sourceregister>,<maskregister>,<destinationregister>この演算は、1の値を含むユーザデータレジスタ<maskregister>ビットと位置が合っているビットだけを比較しながらユーザデータレジスタ<sourceregister>とユーザデータレジスタ<destinationregister>との間の論理XOR演算を実行し、結果の値を<destinationregister>に置く。比較されないビットは、<destinationregister>内で0の値をもたらすことに留意されたい。例示的なTISA命令セットは、次の、レジスタに対するその他の動作を含む。NOPいくつかのISA命令セットでアライメントを実現するためのフィルタとして使用されるノーオペレーションオペコード。例示的なTISA命令セットは、付属プロセッサアーキテクチャを使用する実施形態のためにストリーミングのサポートを拡張する次の命令を含む。MemoryWriteこの命令は、引数<sequencenumberシーケンス番号>、<blockoffsetブロックオフセット32ビットオフセット>、<numberofbytestotransfer転送すべきバイト数>、<destinationaddress宛先アドレス指定されたメモリブロック内の>、<databyteデータバイト1つまたは複数>を使用して、ローカルテストメモリに書き込む。MemoryReadこの命令は、引数<sequencenumberシーケンス番号>、<blockoffsetブロックオフセット32ビットオフセット>、<numberofbytestotransfer転送すべきバイト数>、<sourceaddressソースアドレス指定されたメモリブロック内の>を使用して、ローカルテストメモリから読み取る。この命令は、シーケンス番号および転送されるバイト数を用いてタグ付けされたデータバイトのストリームを返す。例示的なTISA命令セットは、スキャン状態に関する次の値を含む。StartState、ScanState、EndStateスキャン状態コードは、TestLogicResetTLR、RunTest/IdleRTI、PauseDRPDR、PauseIRPIR、ScanDRSDR、ScanIRSIRを含む。これらは、状態コードあたり4ビットの表現であり、12ビットが、スキャン動作に関する状態遷移シーケンス全体を記述するのに使用される。本明細書の教示によって情報を与えられた当業者は、さまざまな他のTISA実施態様を、図示され本明細書で説明されるTISAプロセッサアーキテクチャと共に使用できることを了解するであろう。たとえば、他のTISA実施態様は、より少数の、より多数の、および/または異なるレジスタを使用することができ、より少数の、より多数の、および/または異なる命令セットを使用することができ、類似物を使用することができ、ならびにそのさまざまな組合せを使用することができる。一実施形態では、異なるプロセッサアーキテクチャが使用される場合に、特定の応用例によりよく適するTISA実施態様を提供するためおよび/または任意の他の適切な理由のために、他のTISA実施態様を利用することができる。上で説明したように、JTAGアーキテクチャでのTISAの使用は、スキャン動作をスキャンセグメントレベルで実行することを可能にし、これは、スキャンパス全体の内部での独立に制御可能なスキャンセグメントの定義を可能にし、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。一般に、JTAG動作は、すべてのビットが1つずつ直列にスキャンインされると同時に、ビットが1つずつ直列にスキャンアウトされるスキャン動作に基づく。これは、スキャン動作を実行できるために、スキャンチェーン内のビットごとにどの値が必要とされるかすなわち、入力ベクトルおよび出力ベクトルの知識が要求されることを意味する。TGTは、通常、BSDLなどの記述言語を介して入手されるシステムモデルから必要なベクトルを計算することによって、伝統的な構造テスティングのためにこの機能を提供する。さらに、SVFおよびSTAPLのようなフォーマットは、これを反映する。というのは、これらが、ユーザがこれらのベクトルを操作することを可能にするからである。この形でのテスティングは、構造的なおよび他のタイプのテスティングには十分であるが、この形でのテスティングは、スキャンチェーン全体にアクセスする実際の必要がない対話セットアップには非常に非効率的である。この非効率性は、例を検討することによって理解することができる。たとえば、それぞれが16ビットを有する100個の機器からなるスキャンチェーンを検討されたい。ユーザが、スキャンチェーン内の76番目の機器のレジスタに0x1234を書き込む必要がある場合には、TGTは、スキャンチェーン全体のベクトル10016=1600ビットを生成し、スキャンチェーンに入力するためにこれをTAPインターフェースに送る必要がある。同様に、ユーザが、関連する出力を読み取ることを望む場合には、TGTは、所望の出力情報を抽出できるようになる前に、1600ビットのベクトル全体を受け取る必要がある。この例では、スキャンビットの大多数が役に立たないという事実は重要ではない。というのは、スキャン効率が、目標の1つではないからであるそうではなく、この例では、目標は、主にスキャンチェーンの一特定のエンティティに効率的にアクセスできることである。このタイプの手法は、少なくとも次の理由から問題である。a長いベクトルを扱うという計算的な必要があるたとえば、大量のメモリ転送は、性能に対する大きい影響を有する、bベクトル1つまたは複数全体をメモリに格納する必要がある長いチェーンについて問題になる可能性がある、cメモリストレージが、データ入力およびデータ出力に制限されるのではなく、期待されるデータ、入力マスク、出力マスク、および類似物をも含むこれによって、入力データおよび出力データだけから既に潜在的に過大な負担を受けているメモリ要件を増やす、およびd機器-ベクトル-機器の変換を、毎回行わなければならないこれは、計算能力および時間を必要とする。スキャンセグメントレベル抽象化レベルは、スキャン効率に対する特別な強調を全く用いずにもちろん、必要な場合にそれを使用可能にする場合であってもテストされるシステムのスキャンチェーンの個々のエンティティまたはエンティティのグループへの効率的なアクセスを提供する強力なツールである。一実施形態では、スキャンセグメントレベル抽象化は、スキャンチェーンを一連のセグメントに分解することと、セグメントのそれぞれに対する1つまたは複数のスキャン動作を定義することとによって実施される。スキャンチェーンは、複数の要素からなり、各セグメントは、スキャンチェーンの要素のうちの少なくとも1つを含む。要素を、テストされるシステムの多数のレベルで定義することができたとえば、要素を、デバイス、機器、レジスタ、レジスタのセグメント、および類似物、ならびにそのさまざまな組合せとすることができる、したがって、スキャンチェーンがそれに分解されるセグメントを、テストされるシステムの多数のレベルで定義することができるたとえば、セグメントを、1つまたは複数のデバイス、デバイス1つまたは複数の一部、1つまたは複数の機器、機器1つまたは複数の一部、1つまたは複数のレジスタ、レジスタ1つまたは複数の一部、1つまたは複数のレジスタセグメント、および類似物、ならびにそのさまざまな組合せとすることができる。この形で、セグメントは、スキャンチェーンの最小の制御単位を表すことができる。一実施形態では、セグメントへのスキャンチェーンの分解を、階層的とすることができる。たとえば、スキャンチェーンをセグメントに分解することができ、そのセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、そのサブセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、以下同様である。この形で、スキャンチェーンの階層分解を、あるセグメントを他のセグメントから構成できるツリーベースの構造を有するとみなすことができる。1つのそのような実施形態では、ツリーの葉のセグメントを、セグメントと呼ぶことができそれらがスキャンチェーンの最小の制御単位を表すという点で、ツリーの葉の上に位置するセグメントを、スーパーセグメントと呼ぶことができる。一実施形態では、スキャンチェーンのセグメントのうちの1つまたは複数を、ユーザ/システムに透過的である形でのみ制御可能である仮想サブセグメントから構成することができることを了解されたい。スキャンチェーンの階層分解を、任意の他の適切な形で定義することができる。セグメント化の使用は、セグメントのタイプおよび/またはセグメント組合せのタイプに関するエンティティの定義を可能にする。エンティティは、あるタイプのターゲットの包括的記述であり、この記述は、そのタイプのターゲットの各物理インスタンスについて有効であり、そのタイプのターゲットの物理インスタンスごとに再利用することができる。たとえば、あるエンティティが、デバイス、デバイスのグループ、デバイスの一部、機器、機器のグループ、機器の一部、および類似物、ならびにそのさまざまな組合せを定義することができる。したがって、スキャンチェーンを、スキャンチェーンのセグメントが特定の要素または要素の組合せを含むように分解することができるので、エンティティを、スキャンチェーンのそれぞれのセグメントおよび/またはセグメントのそれぞれの組合せについて定義することができる。たとえば、スキャンチェーンが、1つのセグメントが1つの機器を含むように分解される場合には、エンティティを、そのタイプのセグメントすなわち、そのタイプの機器を含む各セグメントについて定義することができ、そのエンティティを、スキャンチェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。同様に、たとえば、スキャンチェーンが、1つのセグメントが複数の機器を含むように分解される場合には、エンティティを、そのタイプのセグメントすなわち、そのタイプ組合せの機器を含む各セグメントについて定義することができ、そのエンティティを、スキャンチェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。これは、下で説明するように、追加の特徴および機能をサポートすることを可能にする。セグメント化の使用は、エンティティすなわち、制御下のあるタイプのセグメントの記述を、そのエンティティと通信するのに使用される物理プロトコルと相関させることを可能にする。その結果、記述言語たとえば、NSDL、P1687IJTAGPDL、および類似物などを、特にそのエンティティのために記述することができ、接続性記述部分たとえば、NSDLまたはIJTAGHDLの構造は、セグメント化命令の順序付けを記述する。TISAは、TISA命令がモデルベースの動作ではなくセグメントベースの動作なので、特定のエンティティタイプのすべてのオカレンスについて1回定義できる再利用可能なモジュラ性を提供する。したがって、TISAは、モジュラと特定のセグメント内のテストされるエンティティについて自律的との両方であるので、TISAは、既存アーキテクチャに対する大きい利益を提供する。TISAは、既存のツールが必要とするように接続性全体を静的モデルとして前もって定義する必要なしに、必要な任意の順序でスキャンプロセス内の任意の点で実行フローに組み入れることのできる再利用可能で移植可能なモジュールへのテストデータレジスタ定義の直接マッピングを可能にする。TISAは、統一された制御フローおよび標準的なコンピュータサイエンス技法に基づく単一解空間アーキテクチャとして、スキャン動作との非スキャンであるポート/信号インターフェースの統合を可能にするネイティブ言語構造が非スキャン動作へのアクセスを提供するのに使用される解決策に対する大きい利益を提供する。TISAは、同一エンティティの複数のインスタンスに関する命令シーケンスの再利用を可能にし、これによって、システム内のコードストレージ要件の削減を可能にする。たとえば、管理プログラムによって呼び出される記述言語関数にマッピングされる一般化された関数を記述することができる。この例では、関数のそれぞれは、エンティティを表すネイティブ言語オブジェクトのメソッドであり、システム内で定義されたエンティティごとにこれらのオブジェクトの別々のインスタンスがある場合があるが、これらのインスタンスのそれぞれと通信するのに使用されるコードの単一のコピーがあるものとすることができる。この形で、ネイティブ言語実施態様モデルは、回路の接続性および機能性を指定するのに使用される記述言語を直接に制御する。上で与えた例を参照すると、スキャンセグメントレベル抽象化は、機器1から75を含むセグメントS1、機器76を含むセグメントS2、および機器77から100を含むセグメントS3という3つのセグメントの定義を可能にする。この形で、機器76へのアクセスが、大幅に単純化される。たとえば、機器76へのアクセスを、セグメントS3のダミーシフトを行うことたとえば、ScanBlockZeroと、セグメントS2すなわち、機器76について命令1つまたは複数を実行することと、セグメントS1について別のダミーシフトを行うことと、その後、更新を伴って終了することとによって得ることができる。そのようなシーケンスでは、セグメントS2すなわち、スキャンチェーン内の特定の機器へのアクセスは、その長さを除いてセグメントS1またはセグメントS3の知識を全く必要とせずに実現される。これが、単に1つの例であり、したがって、100個の機器の長さのチェーンの別の分解が、他の機器または機器グループへのアクセスを可能にするために可能であることを了解されたい。図17に、テストされるシステムの例示的スキャンチェーンの例示的分解を示す、テストされるシステムの高水準ブロック図を示す。例示的なSUT1700は、4つのデバイス17101~17104集合的にデバイス1710、図17ではそれぞれデバイス1、デバイス2、デバイス3、およびデバイス4と表されるを含む。デバイス1710は、スキャンチェーン1720を形成するためにSUT1700内で直列に配置される。スキャンチェーン1720は、次のようになっている。TAPのTDIは、デバイス17104の入力ポートに接続され、デバイス17104の出力ポートは、デバイス17103の入力ポートに接続され、デバイス17103の出力ポートは、デバイス17102の入力ポートに接続され、デバイス17102の出力ポートは、デバイス17101の入力ポートに接続され、デバイス17101の出力ポートは、TAPのTDOに接続される。例示的なSUT1700内では、デバイス1710のそれぞれが、1テスト命令レジスタTIRおよびテストデータレジスタTDRに入力を供給する入力デマルチプレクサ、ならびに2TIRおよびTDRから出力を収集する出力マルチプレクサを含む。各デバイス1710のTIRおよびTDRは、並列レジスタである。デバイス17103は、入力デマルチプレクサが入力を1つのTIRおよび2つのTDRに供給し、その1つのTIRおよび2つのTDRから出力を収集するように、1つの追加のTDRを含み、この1つのTIRおよび2つのTDRは、すべてが並列になっている。TIRおよびTDRは、それぞれ、直列シフトレジスタとして図示され、それぞれが9個の関連する要素たとえば、フリップフロップを含む。この形で、aTIRは、36個の直列要素を含む1つのスキャンチェーンテスト命令スキャンチェーンと表されるを形成し、bTDRは、合計45個の要素および36個の直列要素すなわち、デバイス17103の2つのTDRは並列なのでを含むもう1つのスキャンチェーンテストデータスキャンチェーンと表されるを形成する。例示的なSUT1700内では、テスト命令スキャンチェーンが、デバイス17104のTIRの9個の要素を含む第1セグメントSI4、デバイス17103のTIRの9個の要素を含む第2セグメントSI3、デバイス17102のTIRの9個の要素を含む第3セグメントSI2、およびデバイス17101のTIRの9個の要素を含む第4セグメントSI1という4つのセグメントに分解されている。この形で、テスティングシステムは、SUT1700の他のTIRの最小限のそれらを構成する要素数以外の知識を用いて、SUT1700のTIRのいずれにも個別にまたは組み合わせてアクセスすることができる。例示的なSUT1700内では、テストデータスキャンチェーンは、デバイス17104のTDRの9個の要素を含む第1セグメントSD4、デバイス17103のTDRの9個の要素を含む第2セグメントSD3、デバイス17102の第1TDRの9個の要素サブセグメントSD2.1と表されるまたはデバイス17102の第2TDRの9個の要素サブセグメントSD2.2と表されるのいずれかを含む第3セグメントSD2、これらは、セグメントの総数を数えるために別々のセグメントとしてカウントされる、ならびに、デバイス17101のTDRの最初の3つの要素を含む第1サブセグメントサブセグメントSD1.1と表される、デバイス17101のTDRの次の4つの要素を含む第2サブセグメントサブセグメントSD1.2と表される、およびデバイス17101のTDRの最後の2つの要素を含む第3サブセグメントサブセグメントSD1.3と表されるという3つの直列サブセグメントにさらに分解される第4セグメントという6つの直列セグメント合計7つのセグメントに分解されている。この形で、テスティングシステムは、SUT1700の他のTDRの最小限のそれらを構成する要素数以外の知識を用いて、SUT1700のTDRのいずれにもまたはデバイス17101のTDRのサブ部分にさえ個別にまたは組み合わせてアクセスすることができる。図17のSUT1700が、テストされるシステムのスキャンチェーン1つまたは複数をスキャンセグメントレベル抽象化を提供する際の使用のために分解できる形の単に1つの例であることを了解されたい。要素、コンポーネント、および類似物の特定のタイプ、個数、および配置に関して図示され、本明細書で説明されるが、そのスキャンチェーン1つまたは複数が分解されるテストされるシステムが、要素、コンポーネント、および類似物のさまざまな他のタイプ、個数、および/または配置を含むことができることを了解されたい。本明細書で説明するように、テストされるシステムのスキャンチェーンの分解は、スキャン動作をセグメントに対して定義することを可能にし、これによってテスティング効率を改善する。分解されたスキャンチェーンのセグメントに関するスキャン動作を含む命令のセットを生成する、一実施形態による方法を、図18に関して図示し、本明細書で説明する。スキャン分解およびスキャンセグメント動作の生成のより詳細な説明を、次で提供する。一般的な例として、各基板がセグメントそれぞれ第1基板、第2基板、および第3基板に関連してセグメントA、B、およびCと表すを含む3つの基板を含むスキャンチェーンを検討されたい。この例では、スキャンセグメントが階層的である場合に、第1基板上のセグメントAを、複数のサブセグメントたとえば、サブセグメントA1からAnから構成することができ、第2基板上のセグメントBを、複数のサブセグメントたとえば、サブセグメントB1からBnから構成することができ、かつ/または第3基板上のセグメントCを、複数のサブセグメントたとえば、サブセグメントC1からCnから構成することができる。より具体的な例として、アプリケーションおよびSUTに従って、セグメントを、機器の内部の1つまたは複数のレジスタ、機器、レジスタのクラスタ、1つまたは複数の基板、および類似物、ならびにそのさまざまな組合せとすることができる。したがって、全体的なスキャン動作は、一連のセグメントスキャン動作に分解される。その結果、最終的なスキャンチェーン動作を得るために必要なものは、一連の単純な原子的動作だけである。したがって、スキャンセグメントレベル抽象化の実施形態は、これに排他的に限定はされないが、原子的テスト動作がプロセッサ動作のように扱われる実施態様でたとえば、図示され本明細書で説明されるさまざまなTISA実施態様または原子的テスト動作がプロセッサ動作のように扱われる任意の他の類似する実施態様で特に有効である。スキャンセグメントレベル抽象化のそのような実施形態では、スキャンセグメントレベルスキャン動作の実際の実施態様が、JTAGにリンクされた1つまたは複数の技術的制約に対処することを必要とする場合がある。たとえば、とりわけTAPマシンの状態を定義する必要およびPause-DR状態必ず実施されるわけではないを使用することの危険性などの制約に対処する必要がある場合がある。スキャンチェーン内の機器/セグメントの位置に基づいてスキャンチェーンを介して受け取られる出力ビットストリーム内の機器/セグメント出力を識別するために、スキャンインされる最初のセグメントが、スキャンアウトされる最初のセグメントにもなるようにスキャンチェーンの終りに最も近いので、スキャンチェーンを、先入れ先出しFIFOシステムとして扱うことができるその直列の性質を考慮して。SUTにスキャンセグメント動作のシーケンスを単一スキャン動作のように経験させるために、TCKを、セグメント動作の間に凍結することができる。スキャンチェーンの内部のすべての要素が同期式なので、この形でのTCKの凍結の効果は、スキャンチェーンがTCKと一緒に凍結されることである。TISAベースのテスティングシステムでのスキャンセグメントレベルの使用は、少数の例によってよりよく理解することができる。次の例では、テストされるシステムSUTが、3つのセグメントその順番でA、B、およびCと表されるからなり、ユーザが、セグメントBの内部に値Vを書き込む必要があると仮定する。第1の例として、システムの3つのセグメントA、B、およびCが、同一のJTAGデバイスの内部で実施されると仮定する。この第1の例では、3つのセグメントがメモリ内で定義された後に、TISA動作は、i.Startstate=Run-Test-Idle、Scanstate=Endstate=ShiftDRをセットするii.ScanLenghtFieldにセグメントAの長さをセットするiii.セグメントAにバイパスシーケンスをスキャンするiv.Startstate=Scanstate=Endstate=ShiftDRをセットするv.ScanLenghtFieldにセグメントBの長さをセットするvi.セグメントBにVをスキャンするvii.Startstate=Scanstate=ShiftDR、Endstate=Run-Test-Idleをセットするviii.ScanLenghtFieldにセグメントCの長さをセットするix.セグメントCにバイパスシーケンスをスキャンするになる。第1の例に関して、TAP有限状態機械FSMをShiftDR状態に保つことによって、スキャンチェーンに対する更新がないことが保証される。これは、第1の例から見ることができ、第1の例では、ShiftDrから出た後にのみUpdateDR状態に達することを考慮すると、ステップiからステップixまでTAPFSMをShiftDR状態に保つことによって、スキャンチェーンに対する更新がないことが保証される。さらに第1の例に関して、スキャンクロックTCKは、スキャン動作中すなわち、ステップiii、vi、およびixのみアクティブであり、残りの状態では凍結される。その効果は、SUTが、TCKと同期する動作に基づくSUTの観点から、ステップiii、vi、およびixを連続ビットストリームとみなすことである。さらに第1の例に関して、バイパスシーケンスは、スキャンセグメントのプロパティであり、たとえば、所与のシーケンスすべて0、すべて1、または任意の他の適切なシーケンスまたはドントケアとすることができ、そのようなシーケンスを判断することは、TGTに委ねられる。第2の例として、システムの3つのセグメントA、B、およびCが、異なるJTAGデバイス1つまたは複数のカード内上で実施されると仮定する。この第2の例では、3つのセグメントがメモリ内で定義された後に、TISA動作は、i.セグメントAの状態をセットする、すなわち、StartState=RunTest/Idle、ScanState=ShiftIR、EndState=ShiftIRgateTCKインジケータii.セグメントAのScanLengthFieldにセグメントAのIRの長さをセットするiii.セグメントAのBYPASS命令パターンを用いてScanBlockを走行させるiv.セグメントBの状態をセットする、すなわち、StartState=ShiftIR、ScanState=ShiftIR、EndState=ShiftIRgateTCKインジケータv.セグメントBのScanLengthFieldにセグメントBのIRの長さをセットするvi.セグメントBのEXTEST命令パターンを用いてScanBlockを走行させるvii.セグメントCの状態をセットする、すなわち、StartState=ShiftIR、ScanState=ShiftIR、EndState=RunTest/Idleviii.セグメントCのScanLengthFieldにセグメントCのIRの長さをセットするix.セグメントCのBYPASS命令パターンを用いてScanBlockを走行させるx.セグメントAの状態をセットする、すなわち、StartState=RunTest/Idle、ScanState=ShiftDR、EndState=ShiftDRgateTCKxi.セグメントAのScanLengthFieldにセグメントAの選択されたDRの長さをセットする1ビットBYPASSDRxii.セグメントAのBYPASSデータパターンを用いてScanBlockを走行させるxiii.セグメントBの状態をセットする、すなわち、StartState=ShiftDR、ScanState=ShiftDR、EndState=ShiftDRgateTCKxiv.セグメントBのScanLengthFieldにセグメントBの選択されたDRの長さをセットするピンへのnビットBSRDRxv.セグメントBのEXTESTデータパターンを用いてScanBlockを走行させるxvi.セグメントCの状態をセットする、すなわち、StartState=ShiftDR、ScanState=ShiftDR、EndState=RunTest/Idlexvii.セグメントCのScanLengthFieldにセグメントCの選択されたDRの長さをセットする1ビットBYPASSDRxviii.セグメントCのBYPASSデータパターンを用いてScanBlockを走行させるになる。第1の例と第2の例との比較において、第2の例に関連する追加の複雑さが、セグメントを選択/選択解除するために各JTAGデバイスの命令レジスタIRを使用する必要に由来することを理解されたい。その場合に、未使用セグメントは、関連するJTAGデバイスを1149.1標準規格のBYPASSモードにすることによって第2の例のステップiiiおよびxviiに示されているように直接にチェーンから外される。1つまたは複数のJTAGデバイス上で定義される任意の個数のセグメントを伴う、上の2つの例のすべての合成が可能であることを了解されたい。さらに、上の2つの例が、単にテストされるシステムをテストするためのスキャンセグメントレベルの使用を示すために提供される例であり、したがって、スキャンセグメントレベルがテストされるシステムのテスティングに使用される実施形態がこれらの例によって限定されることは意図されていないことを了解されたい。そのような実施形態では、TISA命令の実際のシーケンスは、次のうちの1つまたは複数を含む複数の出所を有することができる。1TISA命令を、TGTによって静的に計算することができ、この場合には、ユーザがセグメントにアクセスすることを望むたびに、チェーン全体をスキャンしなければならないこの解決策は、スキャン時間に関しては最適化されないが、限られた計算リソースを有し、時間制約がほとんどまたは全くない組込みシステムに有用である可能性があることを了解されたい、2TISA命令を、アクセス要求を受け取り、これらをスキャン動作に合成するソフトウェアスケジューラによって発行することができ、かつ/または3TISA命令を、ハードウェアスケジューラによって発行することができるたとえば、いくつかの高性能プロセッサ内で命令リオーダリングおよびバイパスに関して行われるものなどであるが、これらに限定はされない。スキャンセグメントレベル制御に関連するTISA命令を、任意の他の適切な形で発行することができ、これらの形が、上で説明した方法および/または上で説明した方法のうちの1つもしくは複数の代わりにもしくはそれに加えて使用できる1つもしくは複数の他の適切な方法の組合せを含むことができることを了解されたい。スキャンセグメントレベル抽象化レベルは、IEEEP1687標準規格によって提案されるものおよび他の動的トポロジなどの動的トポロジを処理する強力なツールである。スキャンチェーンのあるセクションが、アクティブスキャンパスに取り込まれ、外されるたとえば、IEEEP1687標準規格によって提案されるSIBセルまたは任意の他の適切な階層を使用可能にするコンポーネント1つまたは複数を使用して場合には、そのセクションを、1つまたは複数のセグメントとしてマークすることができる。次に、テスティングスケジューラは、システム状態から、このセグメント1つまたは複数がアクティブであるか否かに関する知識を有し、したがって、このセグメントをTISA命令スケジューリングに含めなければならないかどうかに関する知識を有する。本明細書の教示によって情報を与えられた当業者は、この原理を、ホットスワップ基板たとえば、状況レジスタからその存在を検出することによってまたは任意の他の適切な動的要素など、他の動的要素にも使用できることを了解するであろう。図18に、スキャンチェーンのスキャンセグメントレベル抽象化を使用する、テストされるシステムのスキャンチェーンを介してテストされるシステムの一部をテストする方法の一実施形態の高水準ブロック図を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法1800のステップの少なくとも一部を、同時にまたは図18に関して図示され説明されるものとは異なる順序で実行することができる。ステップ1802で、方法1800が開始される。ステップ1804では、スキャンチェーンを複数のセグメントに分解する。スキャンチェーンは、複数の要素に分解され、各セグメントは、スキャンチェーンの要素のうちの少なくとも1つを含む。上で説明したように、スキャンチェーンを任意の適切な形で分解することができる。本明細書で説明するように、セグメントへのスキャンチェーンの分解を、開発フロー内のどこにでも適用することができるたとえば、テスト開発者によって、テスト生成ツールによって、組込み回路モデルによって、および類似物。ステップ1806では、命令のセットを生成する。命令のセットは、ISAに関連するプロセッサ命令と、テストされるシステムの一部分をテストするテスト命令とを含む。テスト命令は、スキャンチェーンのセグメントごとに、そのセグメントに対して実行すべき少なくとも1つのスキャン動作を含む。テスト命令は、従来のテスト命令、TISAのテスト命令、および類似物など、任意のタイプのテスト命令とすることができ、したがって、任意の適切な形で生成することができる。命令のセットを、任意の適切な形で生成することができるたとえば、に関して図示し、上で説明したものと同一のまたはこれに類似する形でステップ1808では、テストされるシステムの一部分をテストするために命令のセットを実行する。命令のセットは、任意の適切な形で実行することができ、この形は、命令のセットの命令のタイプに依存する場合がある。ステップ1810で、方法1800は終了する。主にTISAの実施形態がスキャン動作をスキャンセグメントレベルで実行することを可能にするのに使用される実施形態に関して図示され、本明細書で説明されるが、図示され本明細書で説明されるスキャンセグメントレベル実施形態のうちの1つまたは複数を、TISA様命令アーキテクチャを使用する環境、非TISA命令アーキテクチャ、および/または非TISAテスティング環境実施態様、ならびに類似物で提供することもできることを了解されたい。図示され本明細書で説明されるように形成し、利用することのできるTISAの例示的実施形態によって使用可能にされる機能強化されたシステムテスティング機能を説明するために本明細書でtheTISAに言及するが、TISAがそれのために形成されるプロセッサのISA、TISAがそれのために形成されるSUTの特性、TISAが実行すると思われるテストアルゴリズムの特性、および類似物のうちの1つまたは複数、ならびにそのさまざまな組合せなどのさまざまな要因に依存して、多数の異なるTISAを形成できることを了解されたい。したがって、本明細書でのtheTISAへの言及は、多数の異なるタイプのTISAを形成できるという点で、より一般的にaTISAと解釈することもできる。仮想インサーキットエミュレーションICE機能は、本明細書ではJointTestActionGroupJTAGハードウェアのテスティングをサポートするために提供される。一実施形態では、仮想インサーキットエミュレーションICE機能は、仮想ICEドライバを含み、そのさまざまな実施形態を、本明細書で図示し、説明する。仮想ICEドライバは、任意の標準的なデバッグソフトウェアが柔軟でスケーラブルな形でJTAG対応ハードウェアとインターフェースすることを可能にするように構成される。仮想ICEドライバは、仮想ICEドライバと共に使用されるテスト命令セットがベクトルを計算することを要求されないように構成される。というのは、JTAG動作が、スキャンセグメントに対するローカルネイティブ命令として表され、これによって、ICEリソースに直接にアクセスすることを可能にするからである。仮想ICEドライバは、ICEを機器ベースのJTAG手法たとえば、IEEEP1687標準規格および他の適切な手法などと組み合わせられるように構成される。仮想ICEドライバは、本明細書で提供される仮想ICEドライバの説明から理解されるさまざまな他の機能および利益を提供する。本明細書では主に仮想ICEドライバがテスト命令セットアーキテクチャTISAと共に利用される実施形態の文脈で図示され、説明されるが、仮想ICEドライバを任意の適切なテスト命令セットと共に利用できることを了解されたい。TISAでは、レジスタの並列制御を、高水準ソフトウェア呼出しを使用し、高水準プログラミング言語およびオペレーティングシステムを活用して実行することができる。その結果、TISAを用いると、ICEインターフェーシングを、ターゲットハードウェアのスキャントポロジに従うTISAスキャンセグメント動作の発行を管理するTISAベースの回路制御モデルへの調整された待ち行列に入れられたコマンド呼出しのセットに縮小することができる。したがって、TISAを用いると、ICEインターフェースのそれぞれを、TISAオペコードにマッピングされるデバイスレジスタに対する動作の独立だが階層的なセットとして記述することができる。言い替えると、ICEインターフェースのそれぞれを、自律的な機器レジスタとみなすことができ、TISAによってサポートされるJTAG抽象化レベルの起因して、TISAは、これらのレジスタを独立のスキャンセグメントして表すことによって、これらのレジスタのそれぞれを自律的に制御することができる。これは、ベクトルを扱うためにTGTによって使用される回路モデルよりはるかに単純である。というのは、TISAプロセッサが、スキャンセグメント動作だけをスケジューリングする必要がある既存解決策で要求されるようにテスティングベクトルを再ターゲティングするのではなくからである。仮想ICEドライバの上記およびさまざまな他の実施形態ならびに関連する仮想ICEドライバ機能を、図19および20を参照することによってよりよく理解することができる。図19に、ターゲットハードウェアのテスティングで使用されるように構成された仮想ICEドライバを含むシステムの一実施形態の高水準ブロック図を示す。図19に示されているように、システム1900は、ターゲットハードウェア1910、TAPインターフェース1915、仮想ICEドライバ1920、およびICEホスト1930を含む。ターゲットハードウェア1910は、複数のJTAGアクセス可能デバイス19111~19116集合的に、JTAGアクセス可能デバイス1911を含む。JTAGアクセス可能デバイス1911は、第1中央処理ユニットCPU1、第2中央処理ユニットCPU2、および4つの装着された特定用途向け集積回路ASIC装着されたASIC1~4を含む。特定のタイプおよび個数のJTAGアクセス可能デバイス1911を有するものとして図示され、説明されるが、ターゲットハードウェア1910が、任意の適切なタイプおよび個数のJTAGアクセス可能デバイス1911を含むことができることを了解されたい。CPUを、任意のJTAGアクセス可能CPUとすることができる。たとえば、CPU1およびCPU2の一方または両方を、1149.1ICEターゲットとすることができる。たとえば、CPU1およびCPU2の一方または両方を、独立にアクセスされる必要がある複数のプロセッサコアを有する1149.7ICEターゲットとすることができる。CPUは、任意の他の適切なタイプのCPUを含むことができる。装備されたASICを、任意のJTAGアクセス可能ASICとすることができる。たとえば、装備されたASIC1~4のうちの1つまたは複数を、P1687ICEターゲットとすることができる。図1の例では、装備されたASIC1~4のそれぞれが、P1687ICEターゲットである。ターゲットハードウェア1910は、それに関連するスキャンチェーントポロジを有し、JTAGアクセス可能デバイス1911のそれぞれが、そのスキャンチェーントポロジの一部を形成する。ターゲットハードウェア1910のJTAGアクセス可能デバイス1911は、TAPインターフェース1915を介して指令され、TAPインターフェース1915は、仮想ICEドライバ1920に接続される。TAPインターフェース1915は、ターゲットハードウェア1910と仮想ICEドライバ1920との間のインターフェースを提供し、これによって、仮想ICEドライバ1920が、ターゲットハードウェア1910のJTAGアクセス可能デバイスにアクセスすることを可能にする。TAPインターフェース1915を、1149.1TAPまたは他の適切なTAPなど、任意の適切なTAPを使用して実施することができる。仮想ICEドライバ1920は、待ち行列付き状態機械QueuedStateMachine1921およびTISAプロセッサ1925を含む。仮想ICEドライバ1920は、ICEホスト1930によるターゲットハードウェア1910へのアクセスを容易にする。ICEホスト1930は、ターゲットハードウェア1910のテスティングを可能にするように構成される。ICEホスト1930は、ターゲットハードウェア1910のCPU1に関連する第1ターゲットICEコントローラ19311、ターゲットハードウェア1910のCPU2に関連する第2ターゲットICEコントローラ19312、およびターゲットハードウェア1910の装備されたASIC1~4に関連する第3ターゲットICEコントローラ19313を含む複数のターゲットICEコントローラ1931を含む。ICEホスト1930は、より少数またはより多数のそのようなターゲットICEコントローラを含むことができる。ICEホスト1930は、ICEホスト1930のターゲットICEコントローラ1931のそれぞれと仮想ICEドライバ1920との間の通信を容易にするように構成されたホストメッセージングAPI1935をも含む。第1ターゲットICEコントローラ19311は、CPU1用のGBUGUI19321およびターゲットICEマネージャ19331を含む。CPU1用のGBUGUI19321は、それを介してテスタがターゲットハードウェア1910上のCPU1をテストするために実行されるテストを構成すできるインターフェースを提供する。ターゲットICEマネージャ19331は、CPU1内に含まれるレジスタを記述する回路モデルを含む情報、CPU1のさまざまなレジスタがCPU1内で配置される形、およびCPU1がターゲットハードウェア1910のスキャンチェーン内の唯一のデバイスである場合にCPU1のレジスタへのアクセスを可能にする情報を有する。ターゲットICEマネージャ19331は、CPU1のスキャンセグメントへのCPU1のレジスタのマッピングを定義する情報をも有する。GBUGUI19321を使用して、CPU1のレジスタに対して実行される動作を指定することができる。ターゲットICEマネージャ19331は、ターゲットハードウェア1910上のCPU1にアクセスし、これをテストするための適当なスキャンセグメント動作を生成する。ターゲットICEマネージャ19331は、ターゲットハードウェア1910上のCPU1にアクセスし、これをテストするための生成されたスキャンセグメント動作をホストメッセージングAPI1935に供給し、ホストメッセージングAPI1935は、生成されたスキャンセグメント動作を仮想ICEドライバ1920に通信する。第2ターゲットICEコントローラ19312は、CPU2用のGBUGUI19322およびターゲットICEマネージャ19332を含む。CPU2用のGBUGUI19322は、それを介してテスタがターゲットハードウェア1910上のCPU2をテストするために実行されるテストを構成できるインターフェースを提供する。ターゲットICEマネージャ19332は、CPU2内に含まれるレジスタを記述する回路モデルを含む情報、CPU2のさまざまなレジスタがCPU2内で配置される形、およびCPU2がターゲットハードウェア1910のスキャンチェーン内の唯一のデバイスである場合にCPU2のレジスタへのアクセスを可能にする情報を有する。ターゲットICEマネージャ19331は、CPU2のスキャンセグメントへのCPU2のレジスタのマッピングを定義する情報をも有する。GBUGUI19322を使用して、CPU2のレジスタに対して実行される動作を指定することができる。ターゲットICEマネージャ19332は、ターゲットハードウェア1910上のCPU2にアクセスするための適当なスキャンセグメント動作を生成する。ターゲットICEマネージャ19332は、ターゲットハードウェア1910上のCPU2にアクセスするための生成されたスキャンセグメント動作をホストメッセージングAPI1935に供給し、ホストメッセージングAPI1935は、生成されたスキャンセグメント動作を仮想ICEドライバ1920に通信する。上で説明したように、GDBGUI1932は、それを介してテスタがターゲットハードウェア1910上のデバイスをテストするために実行されるテストを構成できるインターフェースを提供する。一般に、ICEの目的について、デバッガCPU1用のGBUGUI19321およびCPU2用のGBUGUI19322などのGDBデバッガを含むは、本質的に、ターゲットマシンを、3つの基本要素すなわちレジスタのバック、メモリのブロック、およびスタックフレームを含む抽象化モデルとみなす。ターゲットマシンのターゲットマシン記述を使用して、ICEインフラストラクチャを介して抽象化モデルをターゲットマシンの実際のハードウェアにマッピングすることができる。ターゲットハードウェア1910などのJTAGアクセス可能システムでは、実際のハードウェアは、1つまたは複数のスキャンチェーン上のJTAGアクセス可能レジスタとして表される。GDBでは、アプリケーションプログラミングインターフェースAPIを、1インデクシングされたレジスタを読み取る/書き込む関数のセット、2メモリを読み取る/書き込む関数のセット、3プログラムカウンタレジスタを読み取る/書き込む関数のセット、および4スタックポインタレジスタを読み取る/書き込む関数のセットからなるものとすることができる。GDBでは、これらの関数が、GDBGUIたとえば、CPU1用のGBUGUI19321およびCPU2用のGBUGUI19322を介して開始されたGDBアクセス要求をターゲットICEに関するたとえば、ターゲットハードウェア1910のCPU1およびCPU2のレジスタに関するアクセスコマンドに変換する。これらのアクセスコマンドは、スキャンセグメント動作であり、スキャンセグメント動作は、ターゲットハードウェア1910の組込みコンポーネントのレジスタに基づいて定義されるスキャンセグメント上で指定される。この意味で、各スキャンセグメントは、テストに使用可能なターゲットハードウェア1910のレジスタの全体的に順序付けられたセットのサブセットになる。本明細書では主にターゲットハードウェア1910のJTAGアクセス可能デバイス1911をテストするためのGDBの使用に関して図示され、説明されるが、任意の適切なデバッガを、ターゲットハードウェア1910のJTAGアクセス可能デバイス1911をテストするのに利用できることを了解されたい。第3ターゲットICEコントローラ19313は、装備されたASIC1~4のP1687アプリケーション19543を含む。装備されたASIC1~4のP1687アプリケーション19343は、それを介してテスタがターゲットハードウェア1910上の装備されたASIC1~4のうちの1つまたは複数をテストするために実行されるテストを構成できるインターフェースを提供する。装備されたASIC1~4のP1687アプリケーション19343は、GDBの機能に似た機能を提供する。装備されたASIC1~4のP1687アプリケーション19343は、ターゲットハードウェア1910上の装備されたASIC1~4にアクセスするための適当なスキャンセグメント動作を生成する。装備されたASIC1~4のP1687アプリケーション19543は、ターゲットハードウェア1910上の装備されたASIC1~4にアクセスするための生成されたスキャンセグメント動作をホストメッセージングAPI1935に供給し、ホストメッセージングAPI1935は、生成されたスキャンセグメント動作を仮想ICEドライバ1920に通信する。本明細書で示すように、各ターゲットICEコントローラ1931は、スキャンセグメント動作の順序付けられたセットすなわち、関連するターゲットハードウェア1910の内部の1つまたは複数のセグメントへの定義された順序付けられた命令のセットを生成するように構成される。ホストメッセージングAPI1935は、ICEホスト1930のターゲットICEコントローラ1931のそれぞれと仮想ICEドライバ1920との間の通信を容易にする。ホストメッセージングAPI1935は、ターゲットICEコントローラ1931によって生成されたスキャンセグメント動作の順序付けられたセットの、ICEホスト1930のターゲットICEコントローラ1931から仮想ICEドライバ1920への通信を容易にする。ホストメッセージングAPI1935は、ICEホスト1930のターゲットICEコントローラ1931と仮想ICEドライバ1920との間の通信を容易にするために任意の適切な通信機能を使用することができる。たとえば、ホストメッセージングAPI1935は、物理接続たとえば、PCI、シリアル、および類似物、ネットワーク化された接続たとえば、イーサネットベースの接続、インターネットプロトコルIPベースの接続、および類似物、ソフトウェアアプリケーションたとえば、パイプ、ファイル、メッセージ、プロセス間通信、および類似物、および類似物、ならびにそのさまざまな組合せなどの通信機能を利用することができる。本明細書では主にターゲットICEコントローラ1931が単一のICEホストすなわち、ICEホスト1930に存在する実施形態に関して図示され、説明されるが、他の実施形態では、ICEホスト1930のターゲットICEコントローラ1931が、複数のICEホスト上に存在することができる。ターゲットICEコントローラ1931を、任意の適切な形で複数のホストにまたがって分散させることができるたとえば、各ターゲットICEコントローラ1931が、それ自体の専用ホスト上で実施され、ターゲットICEコントローラ1931のうちの少なくともいくつかが、1つまたは複数のホストを共有し、および類似物、ならびにそのさまざまな組合せ。そのような実施形態では、ホストメッセージングAPI1935は、分散されたターゲットICEコントローラ1931の通信を容易にするように構成されるたとえば、物理接続を介して、IP接続および/または任意の他の適切なネットワーク化された接続などのネットワーク化された接続を介して、および類似物、ならびにそのさまざまな組合せ。一実施形態では、仮想ICEドライバ1920は、待ち行列付き状態機械1921およびTISAプロセッサ1925を含む。待ち行列付き状態機械1921は、ICEホスト1930とTISAプロセッサ1925との間のインターフェースとして動作する。待ち行列付き状態機械1921は、ICEホスト1930のターゲットICEコントローラ1931からスキャンセグメント動作の順序付けられたセットを受け取る。待ち行列付き状態機械1921は、スキャンセグメント動作のスケジューリングされたセットを作るためにスキャンセグメント動作の順序付けられたセットを処理し、スキャンセグメント動作のスケジューリングされたセットは、ターゲットハードウェア1910の内部の各スキャンセグメントの位置を考慮に入れることによって実行され得る。待ち行列付き状態機械1921は、ターゲットハードウェア1910のJTAGスキャンチェーンに必要なおよび/または効率的なスケジュールを使用してスキャンセグメント動作をスケジューリングするように構成される。待ち行列付き状態機械1921は、スキャンセグメント動作のスケジューリングされたセットをTISAプロセッサ1925に供給する。待ち行列付き状態機械1921を、任意の適切な形で実施することができる。一実施形態では、たとえば、待ち行列付き状態機械1921は、イベントループ1922、コマンドハンドラ1923、および回路制御モデル1924を含む。イベントループ1922は、ICEホスト1930のホストメッセージングAPI1935からスキャンセグメント動作の順序付けられたセットを受け取る。スキャンセグメント動作は、ICEホスト1930のターゲットICEコントローラ1931のうちの1つまたは複数によって発行されるスキャンセグメント動作を含む。イベントループ1922は、スキャンセグメント動作の順序付けられたセットをコマンドハンドラ1923に供給する。コマンドハンドラ1923は、イベントループ1922からスキャンセグメント動作の順序付けられたセットを受け取る。コマンドハンドラ1923は、スキャンセグメント動作の順序付けられたセットを回路制御モデル1924に供給する。回路制御モデル1924は、コマンドハンドラ1923からスキャンセグメント動作の順序付けられたセットを受け取り、TISAプロセッサ1925に供給されるスキャンセグメント動作のスケジューリングされたセットを生成する。回路制御モデル1924は、ターゲットICEコントローラ1931のそれぞれの回路モデルのそれぞれの回路モデル情報を含み、ターゲットICEコントローラ1931のそれぞれによって発行されるスキャンセグメント動作のハンドリングを可能にするための集合体としてこの情報を管理する。回路制御モデル1924は、JTAG対応デバイス1911のそれぞれのスキャントポロジ、それを介してJTAG対応デバイス1911が相互接続されるスキャントポロジ、および類似物、ならびにそのさまざまな組合せなどの情報を含む、ターゲットハードウェア1910のスキャントポロジをモデル化するためのスキャントポロジ情報を含む。各所与の瞬間に、回路制御モデル1924の状態は、ターゲットハードウェア1910の状態の鏡像になる。回路制御モデル1924は、スキャンセグメントセットと称する場合もあるスキャンセグメントモデルの順序付けられたコレクションを含み、スキャンセグメントセットのそれぞれ自体は、他のスキャンセグメントのサブセットとすることができ、スキャンセグメントサブセットのそれぞれは、その順序付けに関してそれ自体を管理することができる。TISAのオブジェクト指向機能は、スキャンセグメントセットがそのそれぞれのスキャンセグメント動作を実行する時の順序付けの、スキャンセグメントセットへの委譲を可能にし、さらに、関連するコードが変更されないままである間にスキャンセグメントセットが階層全体の中のどこにでも移動することを可能にする。回路制御モデル1924は、スキャントポロジ情報から決定されるターゲットハードウェア1910のスキャントポロジに基づいて、スキャンセグメント動作の順序付けられたセットからスキャンセグメント動作をスケジューリングする。回路制御モデル1924は、受け取られたスキャンセグメント動作のそれぞれを処理する。回路制御モデル1924は、スキャンセグメント動作を受け取る時に、スキャンセグメント動作の所期の宛先たとえば、ターゲットハードウェア1910のJTAGアクセス可能デバイス1911のうちの1つを認識するためにスキャンセグメント動作を処理する。回路制御モデル1924は、スキャンセグメント動作を、回路制御モデル1924のうちでそのスキャンセグメント動作の所期の宛先に関連する部分、たとえば、スキャンセグメント動作に関する適当な関数1つまたは複数への呼出し1つまたは複数を作成するように構成されたスキャンセグメントセットに委譲し、呼び出される関数1つまたは複数は、スキャンセグメント動作を実行するための関連するTISAプロセッサ命令を有する。回路制御モデル1924は、スキャンセグメント動作のスケジューリングされたセットをTISAプロセッサ1925に供給する。回路制御モデル1924が、スキャンセグメント動作のスケジューリングを実行するのに必要な情報だけを必要とするので、回路制御モデル1924を、ベクトル再ターゲティングに使用されるモデルより大幅に単純にすることができることを了解されたい。TISAプロセッサ1925は、TAPインターフェース1915を介してターゲットハードウェア1910のJTAGアクセス可能デバイス1911を制御するように構成される。TISAプロセッサ1925は、TISAプロセッサ1925によってサポートされるTISA命令を使用して、ターゲットハードウェア1910のJTAGアクセス可能デバイスを制御するように構成される。TISAプロセッサ1925は、待ち行列付き状態機械1921からスキャンセグメント動作のスケジューリングされたセットを受け取り、ターゲットハードウェア1910の関連するJTAGアクセス可能デバイス1911のソフトウェアをデバッグするために、ターゲットハードウェア1910のTAPインターフェース1915およびスキャントポロジを介してスキャンセグメント動作のスケジューリングされたセットを実行する。TISAプロセッサ1925の展望から、ターゲットハードウェア1910は、ターゲットハードウェア1910の実際の複雑さに関わりなく、単純にスキャンセグメントのセットである。TISAプロセッサ1925は、図1~18を参照することによってよりよく理解することができる。仮想ICEドライバ1920を、例を考慮することによってよりよく理解することができる。たとえば、ターゲットハードウェア1910のCPU2に関連するCPU2用のGBUGUI19322が、CPU2内のプログラムカウンタの値の更新を要求するコマンドを発行すると仮定する。ターゲットICEマネージャ19332は、そのコマンドをイベントループ1922に渡す。イベントループ1922は、メッセージをコマンドハンドラ1923に渡す。コマンドハンドラ1923は、コマンドを回路制御モデル1924に渡し、回路制御モデル1924は、そのコマンドがCPU2宛であることを認識し、その結果、回路制御モデル1924およびターゲットハードウェア1910の現在の状態でCPU2にアクセスするのに必要なTISA命令を生成する。必要な場合には、コマンドハンドラ1923は、回路制御モデル1924をCPU2がアクセス可能な状態にするのに必要な命令をも生成する。その後、回路制御モデル1924は、CPU2内の特定のレジスタに書き込めるようになるために、CPU2に関連する回路モデル1924のスキャンセグメントセットにコマンドを委譲する。CPU2に適当なベクトルを適用するように構成されたスキャンセグメントセットは、CPU2のプログラムカウンタレジスタに書き込むために呼び出される適当なレジスタ関数への呼出しを作成する。CPU2のプログラムカウンタレジスタに書き込むために呼び出されるレジスタ関数は、CPU2のプログラムカウンタレジスタに特定のデータを書き込むためにスキャンセグメントコマンドの特定のデータを適用する適当なTISAプロセッサ命令を有する。したがって、データが経時的に変化することができると同時に、データがレジスタに書き込まれる形を制御する関数は、経時的に同一のままになる。仮想ICEドライバ1920は、TISAを利用することによって、ターゲットハードウェア1910のJTAGアクセス可能デバイス1911のそれぞれを独立の自律的なスキャンセグメントとして扱うことができる。これは、少なくとも部分的に、1149.1TAPのTCKクロックを命令セット内の任意の所望の点で一時停止することを可能にし、これによって、1149.1TAPがスキャン動作を一時停止するために安定した状態に切り替わる必要をなくす、TISAの機能に起因するすなわち、通常、1149.1TAPインターフェースは、4つの安定した状態のうちの1つでのみTCKをゲーティングするすなわち、クロックをオフに切り替える。これは、ScanSegmentプリミティブの特性に関連して、回路制御モデル1924が、単純に、これ自体の内部状態に基づいてコマンドハンドラ1923から受け取るTISA命令をスケジューリングしなければならないこと、および回路制御モデル1924がそのTISA命令を変更する必要がないことを保証する。これは、既存のICE手法のベクトル再ターゲティングと比較して、重大な単純化である。仮想ICEドライバ1920は、TISAを利用することによって、ターゲットハードウェア1910の組込みコンポーネント上で実行されるスキャンセグメント動作を同期化することによってターゲットハードウェア1910の組込みコンポーネントの間の同期化を提供することができる。したがって、仮想ICEドライバ1920は、TISAを利用することによって、単に、スキャンセグメント動作を順序付け、実行する必要があるターゲットICEコントローラがスキャンチェーンベクトルを再ターゲティングする必要がある既存のICE手法とは異なって、すなわち、仮想ICEドライバ1920は、テスト生成ツールTGTの使用を必要とするスキャンチェーンベクトルの生成および再ターゲティングを必要とするのではなく、ソフトウェア関数を直接に再ターゲティングする。仮想ICEドライバ1920は、ターゲットハードウェア1910の複数のJTAGアクセス可能デバイス1911への並列アクセスおよびその並列テスティングを可能にし、JTAGアクセス可能デバイス1911は、異なるタイプのデバイスたとえば、CPU、ASIC、および類似物、ならびにそのさまざまな組合せを含むことができ、そのようなデバイスがお互いから分離して処理されるという既存ICE機構の要件を除去し、したがって、既存ICE機構を超えるさまざまな最適化を可能にするたとえば、ターゲットハードウェア1910のリソースの共有、ターゲットハードウェア1910のコンポーネントへのアクセスおよびそのテスティングの並列化、および類似物、ならびにそのさまざまな組合せ。仮想ICEドライバ1920は、複数のターゲットICEコントローラ1931によるターゲットハードウェア1910の複数のJTAGアクセス可能デバイス1911への並列アクセスおよびその並列テスティングを可能にし、任意の所与の時に単一のターゲットICEコントローラ1931だけがターゲットハードウェア1910の単一のJTAGアクセス可能デバイス1911だけにアクセスでき、これをテストできるという既存ICE機構の要件を除去し、したがって、スキャンチェーンベクトルの再ターゲティングの必要をなくす。仮想ICEドライバ1920は、ターゲットハードウェア1910のすべてのターゲットデバイスに関するスキャンチェーンベクトルセット全体を入手するためにすべてのターゲットデバイスが同一のスキャンチェーン上にある場合、ターゲットICEコントローラ1931によるテスティングデータの前処理たとえば、ターゲットICEコントローラ1931からのすべてのディレクティブに関するの必要をなくし、これは、既存のICE手法を用いて提供することがむずかしいか不可能でさえある機能である。既存のICE手法のこの制限が、理論的理由から生じるのではなく、実用的理由から生じることを了解されたい。実際に、そのような応用例のベクトル再ターゲティングは、計算要件とモデリングの必要との両方に関して、非常に複雑になる可能性がある。その結果、ほとんどの既存のテスト生成ツールは、そのような状況を許容しないか、システムに事前に定義され単純化された構成を強制する。対照的に、TISAは、このプロセスをスケジューリング問題に縮小し、このスケジューリング問題は、多数の既知の最適化された解決策を有する古典的な周知の情報理論問題である。その結果、仮想ICEドライバ1920は、ターゲットICEコントローラ1931が、ターゲットハードウェア1910のさまざまなコンポーネントをテストするコマンドを発行するので、そのような処理をリアルタイムで実行することを可能にする。仮想ICEドライバ1920は、柔軟でスケーラブルなICE機能を提供し、任意の1149.1対応ターゲットハードウェアおよび/または1149.7対応ターゲットハードウェアを、基礎になるアーキテクチャを変更する必要なしに制御ソフトウェアに接続することを可能にし、さらに、制御ソフトウェアが必要なだけ大きくなり、ICEホスト1930のリソースのすべてを活用することを可能にする。仮想ICEドライバ1920は、ターゲットハードウェア1910上でホスティングされるGDBまたはP1687アプリケーションの変更を全く必要とせずに、ターゲットハードウェア1910のICEベースのテスティングを可能にする。仮想ICEドライバ1920を、したがって図19のシステムを、要素/機能/関数の任意の適切なグループ化および/または区分を含むことができる任意の適切な形で実施することができる。一実施形態では、たとえば、仮想ICEドライバ1920は、ICEホスト1930とターゲットハードウェア1910との間に配置された独立型の1つまたは複数のデバイスとして実施される。一実施形態では、たとえば、待ち行列付き状態機械1921およびICEホスト1930は、任意の適切なインターフェース/接続たとえば、PCI、シリアル、イーサネット、および類似物を介してTISAプロセッサ1925に接続され得るホストマシン内で実施される。この実施形態では、TISAプロセッサ1925は、標準JTAG接続を介してターゲットハードウェア1910に接続される。この実施形態では、ホストメッセージングAPI1935を、任意の適切なコンピュータサイエンス構造1つまたは複数たとえば、メッセージキュー、メールボックス、および類似物、ならびにそのさまざまな組合せを使用して実施することができる。一実施形態では、たとえば、仮想ICEドライバ1920が完全にターゲットハードウェア1910内に組み込まれるように、仮想ICEドライバ1920を実施することができる。一実施形態では、たとえば、ICEホスト1930を、TISAプロセッサとすることができる。この実施形態では、TISAプロセッサ1925は、図13および14に関して本明細書で図示し、説明したように、TISAコプロセッサとして実施される。そのような実施形態のさまざまな組合せを実施でき、かつ/または任意の他の適切な実施態様を使用できることを了解されたい。本明細書では主に、ICEホスト1930が複数のターゲットICEコントローラ1931を含み、複数のターゲットICEコントローラ1931がターゲットハードウェア1910に並列にアクセスできる実施形態に関して図示され、説明されるが、他の実施形態では、ICEホスト1930は、複数のターゲットICEコントローラ1931のうちの1つだけが任意の所与の時にアクティブである、複数のターゲットICEコントローラ1931を含むことができ、あるいは、ICEホスト1930は、1つのターゲットICEコントローラ1931だけを含むことができる。そのような実施形態では、仮想ICEドライバ1920は、待ち行列付き状態機械1921の使用を必要とせず、したがって、この要素を仮想ICEドライバ1920から省略することができる。そのような実施形態では、仮想ICEドライバ1920は、TISAプロセッサ1925を含み、アクティブの/唯一のターゲットICEコントローラ1931によって供給されるスキャンセグメント動作は、TISAプロセッサ1925に直接にすなわち、待ち行列付き状態機械1921を使用せずに供給され得る。主に、仮想ICEドライバ1920が単一のTAPインターフェース1915を介してターゲットハードウェア1910とインターフェースする実施形態に関して図示され、説明されるが、他の実施形態では、ターゲットハードウェア1910は、それに接続された複数のターゲットICEコントローラ1931を有することができる複数の入力ポートたとえば、1149.1TAPを含むことができる。そのような実施形態では、仮想ICEドライバ1920は、ターゲットハードウェア1910の複数のTAPインターフェースのそれぞれを介して受け取られたスキャンベクトルの、ターゲットハードウェア1910の適当なJTAGアクセス可能デバイス1911へのルーティングを管理するように構成される。そのような実施形態では、ターゲットICEコントローラ1931は、実際にはTISAプロセッサのスキャンセグメント呼出しとしてデータベクトルをターゲットハードウェア1910内の適当な点に再マッピングしているTISAプロセッサと通信している時に、それ自体のスキャンチェーン内のそれ自体のデバイスと通信していると考える。したがって、そのような実施形態では、ターゲットハードウェア1910の変更がある場合に、対応する変更は、ターゲットICEコントローラ1931内では要求されず、ターゲットハードウェア1910の変更をサポートするために必要な唯一のステップは、TISAプロセッサの回路モデルを再ロードすることになるはずである。本明細書では主に仮想ICEドライバ1920がターゲットハードウェアのソフトウェアをデバッグするのに使用される実施形態に関して図示され、説明されるが、他の実施形態では、仮想ICEドライバ1920を使用して、1149.1TAPインターフェースをその中に組み込まれた通信デバイスたとえば、コンピュータ、スマートホン、および類似物へのリモート更新を実行することができる。図20に、ターゲットハードウェアをテストするのに仮想ICEドライバを使用する方法の一実施形態を示す。図20の方法2000は、図19の仮想ICEドライバに関連して考慮する時によりよく理解することができる。ステップ2002で、方法2000が開始される。ステップ2004では、スキャンセグメント動作を受け取る。スキャンセグメント動作は、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成される。ターゲットICEコントローラは、ターゲットハードウェアの複数のコンポーネントに関連する。ステップ2006では、スキャンセグメント動作のスケジューリングされたセットを形成するために、スキャンセグメント動作をスケジューリングする。スキャンセグメント動作は、ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいてスケジューリングされる。ステップ2008では、スキャンセグメント動作のスケジューリングされたセットを、ターゲットハードウェアの1つまたは複数のコンポーネントをテストするためにスキャンセグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向けて伝搬させる。ステップ2010で、方法2000は終了する。図21に、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。図21に示されているように、コンピュータ2100は、プロセッサ要素2102たとえば、中央処理装置CPUまたは他の適切なプロセッサ1つまたは複数、メモリ2104たとえば、ランダムアクセスメモリRAM、読取り専用メモリROM、および/または任意の他の適切なタイプのメモリ、図示され本明細書で説明されるシステムテスティング機能を実行するように適合されたシステムテスティングモジュール/プロセス2105、およびさまざまな入出力デバイス2106たとえば、ユーザ入力デバイスキーボード、キーパッド、マウス、および類似物など、ユーザ出力デバイスディスプレイ、スピーカ、および類似物など、入力ポート、出力ポート、受信器、送信器、およびストレージデバイスたとえば、テープドライブ、フロッピドライブ、ハードディスクドライブ、コンパクトディスクドライブ、および類似物を含む。図示され本明細書で説明されるシステムテスティング機能を、ソフトウェアならびに/あるいはソフトウェアおよびハードウェアの組合せで、たとえば、汎用コンピュータ、1つまたは複数の特定用途向け集積回路ASIC、および/または任意の他のハードウェア同等物を使用して、実施できることに留意されたい。一実施形態では、システムテスティングプロセス2105を、メモリ2104にロードし、プロセッサ2102によって実行して、上で説明したシステムテスティング機能の少なくとも一部を実施し、かつ/またはその実施態様をサポートすることができる。したがって、システムテスティングプロセス2105関連するデータ構造を含むを、コンピュータ可読記憶媒体または担体、たとえば、RAMメモリ、磁気ドライブ、磁気ディスケット、光ドライブ、光ディスケット、および類似物に格納することができる。本明細書でソフトウェア方法として論じたステップのうちのいくつかを、ハードウェア内で、たとえばさまざまな方法ステップを実行するためにプロセッサと協力する回路網として実施できることが企図されている。本明細書で説明された機能/要素の諸部分を、コンピュータプログラム製品として実施することができ、ここで、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および/または技法が呼び出されるか他の形で提供されるように、コンピュータの動作を適合させる。本発明的方法を呼び出す命令を、固定媒体または取外し可能媒体に格納し、放送媒体または他の信号担持媒体内のデータストリームを介して伝送し、かつ/または命令に従って動作するコンピューティングデバイス内のメモリ内に格納することができる。さまざまな実施形態の態様は、特許請求の範囲で指定される。さまざまな実施形態の上記および他の態様は、次の番号付きの句で指定される。1.インサーキットエミュレーションICEを使用してターゲットハードウェアの1つまたは複数のコンポーネントをテストする際に使用される方法であって、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャンセグメント動作を受け取るステップであって、複数のターゲットICEコントローラは、ターゲットハードウェアの複数のコンポーネントに関連する、ステップと、ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、受け取られたスキャンセグメント動作をスケジューリングするステップであって、これによってスキャンセグメント動作のスケジューリングされたセットを形成するステップと、ターゲットハードウェアの1つまたは複数のコンポーネントをテストするためにスキャンセグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作のスケジューリングされたセットを伝搬させるステップと、を含む方法。2.受け取られたスキャンセグメント動作のうちの少なくとも1つについて、受け取られたスキャンセグメント動作は、少なくとも1つのICEホストのターゲットICEコントローラによって生成され、ターゲットハードウェア上のプロセッサコアのためのものである、句1に記載の方法。3.少なくとも1つのICEホストのターゲットICEコントローラは、デバッガに関連する、句2に記載の方法。4.受け取られたスキャンセグメント動作のうちの少なくとも1つについて、受け取られたスキャンセグメント動作は、少なくとも1つのICEホストのアプリケーションによって生成され、ターゲットハードウェア上の特定用途向け集積回路ASICの少なくとも1つのプロセッサコアのためのものである、句1に記載の方法。5.アプリケーションは、P1687アプリケーションであり、特定用途向け集積回路は、P1687標準規格に準拠する、句4に記載の方法。6.スキャンセグメント動作は、物理接続およびネットワーク化された接続のうちの少なくとも1つを介して受け取られる、句1に記載の方法。7.スキャンセグメント動作は、複数のターゲットICEコントローラの通信をサポートするホストメッセージングAPIから受け取られる、句1に記載の方法。8.方法は、待ち行列付き状態機械によって実行される、句1に記載の方法。9.待ち行列付き状態機械は、イベントループ、コマンドハンドラ、および回路制御モデルを含み、イベントループは、ターゲットICEコントローラによって生成されたスキャンセグメント動作を受け取り、スキャンセグメント動作をコマンドハンドラに提供するように構成され、コマンドハンドラは、イベントループからスキャンセグメント動作を受け取り、スキャンセグメント動作を回路モデルに提供するように構成され、回路制御モデルは、スキャンセグメント動作のスケジューリングされたセットを作るように構成される句8に記載の方法。10.スキャンセグメント動作のスケジューリングされたセットは、回路制御モデルを使用して作られる、句1に記載の方法。11.回路制御モデルは、ターゲットICEコントローラに関連する複数の回路モデルの回路モデル情報を含む、句10に記載の方法。12.回路制御モデルは、ターゲットハードウェアのスキャントポロジをモデル化するスキャントポロジ情報であって、回路制御モデルは、スキャントポロジ情報を使用してスキャンセグメント動作のスケジューリングされたセットを作る、スキャントポロジ情報を含む、句10に記載の方法。13.受け取られたスキャンセグメント動作のそれぞれについて、回路制御モデルは、スキャンセグメント動作の所期の宛先であってターゲットハードウェアのコンポーネントのうちの1つである所期の宛先を認識するために、スキャンセグメント動作を処理し、回路制御モデルのうちでスキャンセグメント動作の所期の宛先に関連する部分にスキャンセグメント動作を委譲する句10に記載の方法。14.回路制御モデルのうちでスキャン制御動作の所期の宛先に関連する部分は、スキャンセグメント動作に関する少なくとも1つの関数への少なくとも1つの呼出しを作成するように構成されたスキャンセグメントセットを含み、少なくとも1つの関数は、スキャンセグメント動作を実行するように構成されたプロセッサ命令を含む、句13に記載の方法。15.プロセッサは、ターゲットハードウェア内に組み込まれる、句1に記載の方法。16.方法は、仮想ICEドライバによって実行され、仮想ICEドライバは、ターゲットハードウェア内に組み込まれる、句15に記載の方法。17.複数のターゲットICEコントローラは、単一のICEホストに関連し、プロセッサは、第1プロセッサであり、単一のICEホストは、第2プロセッサを含み、第2プロセッサは、中央処理装置CPUとして動作し、第1プロセッサは、第2プロセッサのスキャンセグメント動作のスケジューリングされたセットを処理するためのコプロセッサとして動作する、句1に記載の方法。18.第1プロセッサおよび第2プロセッサは、TISAプロセッサである、句17に記載の方法。19.ターゲットハードウェアの1つまたは複数のコンポーネントをテストする際に使用される装置であって、少なくとも1つのICEホストの複数のターゲットICEマネージャによって生成されたスキャンセグメント動作を受け取ることであって、複数のターゲットICEマネージャは、ターゲットハードウェアの複数のコンポーネントに関連する、受け取ることと、ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、受け取られたスキャンセグメント動作をスケジューリングすることと、ターゲットハードウェアの1つまたは複数のデバイスをテストするためにスキャンセグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作のスケジューリングされたセットを伝搬させることとを行うように構成された待ち行列付き状態機械を含む装置。20.プロセッサによって実行された時に、プロセッサに、インサーキットエミュレーションICEを使用してターゲットハードウェアの1つまたは複数のコンポーネントをテストする際に使用される方法を実行させる命令を格納したコンピュータ可読記憶媒体であって、方法は、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャンセグメント動作を受け取るステップであって、複数のターゲットICEコントローラは、ターゲットハードウェアの複数のコンポーネントに関連する、ステップと、ターゲットハードウェアのスキャンチェーンに少なくとも部分的に基づいて、受け取られたスキャンセグメント動作をスケジューリングするステップであって、これによってスキャンセグメント動作のスケジューリングされたセットを形成するステップと、ターゲットハードウェアの1つまたは複数のコンポーネントをテストするためにスキャンセグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャンセグメント動作のスケジューリングされたセットを伝搬させるステップと、を含む、コンピュータ可読記憶媒体。本発明の教示を組み込まれたさまざまな実施形態を図示し、本明細書で詳細に説明したが、当業者は、これらの教示を組み込まれた、多数の他の変更された実施形態をたやすく考案することができる。"