JP2012519912A - 複数の命令タイプを使用するシステム・テスティングの方法および装置 - Google Patents

複数の命令タイプを使用するシステム・テスティングの方法および装置 Download PDF

Info

Publication number
JP2012519912A
JP2012519912A JP2011553067A JP2011553067A JP2012519912A JP 2012519912 A JP2012519912 A JP 2012519912A JP 2011553067 A JP2011553067 A JP 2011553067A JP 2011553067 A JP2011553067 A JP 2011553067A JP 2012519912 A JP2012519912 A JP 2012519912A
Authority
JP
Japan
Prior art keywords
instructions
test
tisa
tap
testing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2011553067A
Other languages
English (en)
Other versions
JP5489249B2 (ja
Inventor
ゴヤル，スレシュ
ポートラン，ミシェル
トローレン，ブラッドフォード ヴァン
Original Assignee
アルカテル−ルーセント
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アルカテル−ルーセント filed Critical アルカテル−ルーセント
Publication of JP2012519912A publication Critical patent/JP2012519912A/ja
Application granted granted Critical
Publication of JP5489249B2 publication Critical patent/JP5489249B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318533—Reconfiguring for testing, e.g. LSSD, partitioning using scanning techniques, e.g. LSSD, Boundary Scan, JTAG
    • G01R31/318558—Addressing or selecting of subparts of the device under test

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Tests Of Electronic Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用される装置を提供する。この装置は、テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をＴＡＰを介してテストするためにテスト命令セット・アーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セット・アーキテクチャの命令のセットは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、ＴＡＰに関連する複数のテスト命令を含む命令の第２セットとを含む。命令の第１セットの命令および命令の第２セットの命令は、テスト命令セット・アーキテクチャの命令のセットを形成するために統合される。

Description

関連出願の相互参照
本願は、参照によってその全体が本明細書に組み込まれている、２００９年３月４日に出願した米国特許仮出願第６１／１５７４１２号、名称「ＴＥＳＴ ＩＮＳＴＲＵＣＴＩＯＮ ＳＥＴ ＡＲＣＨＩＴＥＣＴＵＲＥ」の利益を主張するものである。
本願は、それぞれが本願と同時に出願され、参照によってその全体が本明細書に組み込まれている、米国特許出願第１２／４９５２９５号、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＳＹＳＴＥＭ ＴＥＳＴＩＮＧ ＵＳＩＮＧ ＭＵＬＴＩＰＬＥ ＰＲＯＣＥＳＳＯＲＳ」、弁理士整理番号第ＡＬＵ／１３０１３７−２号および米国特許出願第１２／４９５３３６号、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＳＹＳＴＥＭ ＴＥＳＴＩＮＧ ＵＳＩＮＧ ＳＣＡＮ ＣＨＡＩＮ ＤＥＣＯＭＰＯＳＩＴＩＯＮ」、弁理士整理番号第ＡＬＵ／１３０１３７−３号に関連する。
本発明は、システム・テスティングの分野に関し、排他的ではなく、より具体的には、システム・テスティング用の命令の生成および制御に関する。
電子回路は、通常、電気回路を形成するためにさまざまなデバイス端子を相互接続する導電トレースを有するプリント回路基板にはんだ付けされた複数の電子コンポーネントを含むプリント回路基板（ＰＣＢ）の形で構成される。ＰＣＢおよびその実装される電気回路は、しばしば複雑なので、製造時の基板テスティングは、ますます自動化されるようになってきた。これに関して、基板テスティング装置は、高水準自動化機能テスティングのための実装されたＰＣＢのＩ／Ｏコネクタに接続する単純なＩ／Ｏ機能テスタから、高水準テスティングおよび低水準テスティングの実行ためにテストされる基板の回路ノードのすべてまたは一部と電気接触するプローブ・ピンを含むテスト治具、テストされる基板の個々の回路ノードを外部からプローブする必要なしにＰＣＢの自動化テスティングを提供する統合されたテスティング・デバイスへと進化してきた。
基板およびデバイス内の電子回路のテスティングは、通常、テスティング自動化ツール（Ｔｅｓｔｉｎｇ Ａｕｔｏｍａｔｉｏｎ Ｔｏｏｌ）によって制御され、このテスティング自動化ツールは、テスト・アルゴリズムの定義から実際のテスティング動作まで進行するのに必要なステップをサポートする。テスティング自動化を容易にするために、テスティング・リソースは、しばしば、基板およびデバイスの内部に組み込まれ、通常はテスト・アクセス・ポート（Ｔｅｓｔ Ａｃｃｅｓｓ Ｐｏｒｔ、ＴＡＰ）と呼ばれる標準化されたインターフェースを使用してアクセスすることができる。これは、ピン数を制限し、リソース・アクセスおよび管理を合理化するという効果を有する。一般に、既存標準規格のほとんどは、テストされるシステム（ｓｙｓｔｅｍ ｕｎｄｅｒ ｔｅｓｔ、ＳＵＴ）の内部のリソースを記述するのに使用でき、テスティング自動化ツールへの入力として使用できる１つまたは複数の言語を提供する。これらのテスティング自動化ツールは、ＴＡＰを活用するテスティング・シーケンスを生成するために、それら自体のアルゴリズムを適用することができる。次に、これらのテスティング・シーケンスをテスト制御ユニット（Ｔｅｓｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、ＴＣＵ）によって使用して、ＴＡＰに指令し、テスティング動作を実行することができる。テスティング動作の特徴および性能は、これらの要素のそれぞれすなわち、アクセス標準規格、データ・フォーマット、およびＴＣＵ実施態様に依存する。
ＪＴＡＧ（Ｊｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ）は、ＩＥＥＥ １１４９．１と表される回路基板テスティング標準規格を開発した。ＩＥＥＥ １１４９．１は、回路基板をテストするためのテスト・アクセス・ポート（ＴＡＰ）を指定する。ＩＥＥＥ １１４９．１は、テストされる回路基板上に含まれるテスト・デバイスを介するハードウェアのバウンダリ・スキャン（ＢＳ）テスティングをサポートする。バウンダリ・スキャン・テスティングは、他の方法で実現可能である可能性があるテスト・カバレージを超えるテスト・カバレージを実現するためにソフトウェアの制御の下でＪＴＡＧ互換デバイスのバウンダリ・ピンを制御し、監視することを含む。さらに、ＩＪＴＡＧ（Ｉｎｓｔｒｕｃｔｉｏｎ ＪＴＡＧ）が、基板レベルＪＴＡＧからチップレベルＪＴＡＧへの移行に関連する既存のＪＴＡＧ制限を克服するために標準化されようとしている（Ｐ１６８７と表される）。
ＪＴＡＧおよびＩＪＴＡＧを自動化テスト生成（Ａｕｔｏｍａｔｅｄ Ｔｅｓｔ Ｇｅｎｅｒａｔｉｏｎ、ＡＴＧ）ツールによって使用して、チップおよび電子デバイスをテストすることができる。ＪＴＡＧは、チップの内部で実装されたリソースへの最小限のオーバーヘッドを伴う直列アクセスを可能にする単純な５ワイヤＴＡＰを提示する。このアクセス・インフラストラクチャを、ＢＳＤＬ（Ｂｏｕｎｄａｒｙ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などの特定の言語に記述することができ、この特定の言語を、多数の市販ＴＧＴによって使用して、テスティング・ベクトル（ｔｅｓｔｉｎｇ ｖｅｃｔｏｒ）を生成することができる。これらのテスティング・ベクトルは、通常、ＳＶＦ（Ｓｅｒｉａｌ Ｖｅｃｔｏｒ Ｆｏｒｍａｔ）と呼ばれるフォーマットで保存され、このＳＶＦは、１１４９．１ ＴＡＰの基本的動作の高水準記述を可能にする。ＳＶＦに対するより複雑な代替案が、ＳＴＡＰＬであり、ＳＴＡＰＬは、基本的なフロー制御（ｉｆ−ｔｈｅｎ−ｅｌｓｅ）およびテスト・ベクトルに対する算術演算を可能にするために、ＳＶＦのベクトル動作を拡張する。ＪＴＡＧ準拠ＴＡＰは、ＳＶＦプレイヤまたはＳＴＡＰＬプレイヤからコマンドを受け取り、後にオフラインで解釈できる単純なＧｏ／ＮｏＧｏ結果を生成する。
不利なことに、これらの既存の手法は、多数の制限を有する。第１の制限は、データ・フォーマットにある。というのは、テスト・プレイヤが、テストされるシステムの知識を全く有しておらず、したがって、非常に基本的な動作しか実行できないからである。第２の制限は、対話テスティング（ローカルまたはリモート）をサポートすることができず、すべてのテスティング結果をオフラインで調べなければならないことである。さらに、これらの既存手法は、実施態様依存であり、通常はプロプライエタリである。
ＩＥＥＥ １１４９．１標準規格 「Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ Ｖｅｒｓｉｏｎ ８」、ＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ刊、１９９２年 「Ｓｅｒｉａｌ Ｖｅｃｔｏｒ Ｆｏｒｍａｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ＡＳＳＥＴ ＩｎｔｅｒＴｅｃｈ，Ｉｎｃ．、１９９７年
従来技術のさまざまな欠陥は、システム・テスティングの実行に使用するためのテスト命令を生成する方法および装置を介して対処される。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用される装置は、テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をＴＡＰを介してテストするためのテスト命令セット・アーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セット・アーキテクチャの命令のセットは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、ＴＡＰに関連する複数のテスト命令を含む命令の第２セットとを含む。命令の第１セットの命令および命令の第２セットの命令は、テスト命令セット・アーキテクチャの命令のセットを形成するために統合される。
一実施形態では、テストされるシステムをテスト・アクセス・ポート（ＴＡＰ）を介してテストするコンピュータ・プロセッサは、ＴＡＰを介するテストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セット・アーキテクチャに従って命令を処理するように構成された回路網を含む。テスト命令セット・アーキテクチャは、第１タイプの複数の命令および第２タイプの複数の命令を含む。第１タイプ命令は、コンピュータ・プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含む。第２タイプ命令は、ＴＡＰを介してテストされるシステムをテストするためのテスト命令を含む。
一実施形態では、テストされるシステムの少なくとも一部のテスト・アクセス・ポート（ＴＡＰ）を介するプロセッサによるテスティングをサポートするためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法が提供される。この方法は、プロセッサによってサポートされるＩＳＡ命令を含む命令の第１セットを生成するステップと、ＴＡＰに関連するテスト命令を含む命令の第２セットを生成するステップと、これによってＴＩＳＡ命令のセットを形成するために命令の第１セットおよび命令の第２セットを統合するステップと、ＴＩＳＡ命令を格納するステップ、実行するステップ、または伝搬させるステップのうちの少なくとも１つを実行するステップとを含む。
本明細書の教示は、添付図面に関連して次の詳細な説明を検討することによってたやすく理解することができる。
テスティング・システムとテストされるシステムとを含むシステム・テスティング環境を示す高水準ブロック図である。 テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態を示す高水準ブロック図である。 テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態を示す高水準ブロック図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の例示的なＴＩＳＡアーキテクチャを示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の例示的なＴＩＳＡアーキテクチャを示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 対話テスティング機能をサポートするＴＩＳＡベースのテスティング環境の実施形態を示す図である。 図６のＴＩＳＡベースのテスティング環境の例示的実施態様を示す図である。 図５Ａのテストされるシステムの送信器−受信器チャネルの最適化を実行するための例示的プログラム・アーキテクチャを示す図である。 テスト命令セット・アーキテクチャ（Ｔｅｓｔ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＴＩＳＡ）フローを形成するためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法の一実施形態を示す図である。 テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す図である。 テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す図である。 テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す図である。 ＴＩＳＡプロセッサ・アーキテクチャの例示的実施形態を示す図である。 システム・テスティング機能を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す図である。 テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す図である。 テスト付属プロセッサ（ｔｅｓｔ ａｄｊｕｎｃｔ ｐｒｏｃｅｓｓｏｒ）アーキテクチャの例示的実施形態を示す図である。 ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す図である。 テストされるシステムの例示的スキャン・チェーンの例示的分解を示す、テストされるシステムを示す高水準ブロック図である。 スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用する、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態を示す高水準ブロック図である。 本明細書で説明される機能を実行する際の使用に適するコンピュータを示す高水準ブロック図である。
理解を容易にするために、可能な場合には、同一の符号が、複数の図面に共通する同一の要素を指定するのに使用された。
さまざまなテスティング機能が、テストされるシステム（ＳＵＴ）のテスティングを実行する際の使用のために提供される。
一実施形態では、テスト命令セット・アーキテクチャ（ＴＩＳＡ）が提供される。ＴＩＳＡは、システム・テスティングを実行する際に使用するために提供される。ＴＩＳＡは、対話テスティング機能、リモート・テスティング機能、および本明細書で説明するさまざまな他の機能を含む改善されたシステム・テスティング機能を提供するために、コンピュータ・サイエンス機能をシステム・テスティング機能と組み合わせる。ＴＩＳＡは、システム・テスティング機能を使用してソフトウェア・ベースの命令セット・アーキテクチャ（ＩＳＡ）を適合させることによって形成される。ソフトウェア・ベースのＩＳＡは、任意の適切なソフトウェア・プログラミング言語（たとえば、Ｃ＋＋、Ｊａｖａ、および類似物、ならびにそのさまざまな組合せ）を利用することができ、任意の適切なプロセッサを使用して実施され得る。システム・テスティング機能は、ＩＥＥＥ １１４９．１（ＪＴＡＧとしても知られる）ＴＡＰまたは任意の他の適切なＴＡＰなどの任意の適切なＴＡＰを利用することができる。一般に、ＴＩＳＡは、ソフトウェア・プロセスの不可分動作をテスト手順の不可分テスティング動作と組み合わせることによって形成される。ＴＩＳＡでは、テスト手順のアルゴリズム部分が、ソフトウェア・フローによって処理され、テスト手順のアルゴリズム部分が不可分テスティング動作に変換されるようになっている。ＴＩＳＡは、ソフトウェア・プロセスの不可分動作をテスト手順の不可分テスティング動作と組み合わせることによって形成され、不可分テスティング動作が、テスト手順のアルゴリズム部分を処理しているソフトウェア・プロセスの不可分動作と同一の形で扱われるようになっている。これは、組込みテスト実行、リモート・テスト実行、および図示され本明細書で説明されるさまざまな他の改善されたシステム・テスティング機能のより細粒度の制御を可能にする。
図１に、テスティング・システムとテストされるシステムとを含むシステム・テスティング環境の高水準ブロック図を示す。
図１に示されているように、システム・テスティング環境１００は、テスティング・システム（ＴＳ）１１０およびテストされるシステム（ＳＵＴ）１２０を含む。
ＴＳ １１０は、ＳＵＴ １２０をテストするのに適する任意のシステムとすることができる。ＴＳ １１０は、ＳＵＴ １２０をテストするために構成される。ＴＳ １１０は、ＳＵＴ １２０の任意のテスティング、たとえば、ＳＵＴ １２０の１つまたは複数の個々のコンポーネント、ＳＵＴ １２０のコンポーネントの１つまたは複数の組合せ、ＳＵＴ １２０のコンポーネントの間の１つまたは複数の相互接続、ＳＵＴ １２０の１つまたは複数のシステム・レベル機能、および類似物、ならびにそのさまざまな組合せのテスティングを実行することができる。ＴＳ １１０は、テスト手順の実行、テストされるシステムへの入力データの供給、テストされるシステムからの出力データの受取り、システム・テスティング結果を判定するためのテストされるシステムから受け取られた出力データの処理、および同様の機能、ならびにそのさまざまな組合せなど、通常はテストされるシステムのテスティングに関連する機能のいずれをも実行することができる。テストされるシステムをテストするためのＴＳ １１０の設計および使用を、下でさらに詳細に説明する。
ＳＵＴ １２０は、ＴＳ １１０を使用してテストすることのできる任意のシステムとすることができる。ＳＵＴ １２０は、その少なくとも一部をＴＳ １１０によって個別におよび／または組み合わせてテストできる任意のコンポーネント（１つまたは複数）を含むことができる。ＴＳ １２０は、ＳＵＴ １２０によってテストされるコンポーネント（１つまたは複数）へのアクセスを提供する関連する入力アクセス・ピンおよび出力アクセス・ピンの１つまたは複数のセットを有する１つまたは複数のスキャン・チェーンを含むことができる。スキャン・チェーン（１つまたは複数）をＳＵＴ １２０をテストするためにＳＵＴ １２０内で利用できる形は、当業者によって了解されるであろう。たとえば、ＳＵＴ １２０は、１つまたは複数の基板を含むことができ、この基板のテスティングは、ＳＵＴ １２０に入力テスティング信号を印加し、ＳＵＴ １２０から出力テスティング信号を収集するために使用できる関連する入力アクセス・ピンおよび出力アクセス・ピンを有する１つまたは複数のスキャン・チェーンを使用して実行することができる。
図１に示されているように、ＴＳ １１０は、テスト・アクセス・インターフェース（ＴＡＩ）１１５を介してＳＵＴ １２０にアクセスする。テスト・アクセス・インターフェースを、任意の適切なテスト・アクセス・インターフェースを使用して実施することができ、このテスト・アクセス・インターフェースは、ＴＳ １１０、ＳＵＴ １２０、実行されるテスティングのタイプ、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数に依存する可能性がある。
たとえば、ＴＡＩ １１５は、参照によってその全体が本明細書に組み込まれているＩＥＥＥ １１４９．１標準規格で標準化されているＪＴＡＧ（Ｊｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ）テスト・アクセス・ポート（ＴＡＰ）を含むことができる。ＩＥＥＥ １１４９．１標準規格は、ＴＤＩ（Ｔｅｓｔ Ｄａｔａ Ｉｎ）、ＴＤＯ（Ｔｅｓｔ Ｄａｔａ Ｏｕｔ）、ＴＭＳ（Ｔｅｓｔ Ｍｏｄｅ Ｓｅｌｅｃｔ）、ＴＣＫ（Ｔｅｓｔ Ｃｌｏｃｋ）、および、オプションでＴＲＳＴ（Ｔｅｓｔ Ｒｅｓｅｔ Ｓｉｇｎａｌ）という信号のセットをサポートするＴＡＰを定義する。ＳＵＴ １２０のＴＤＩピンおよびＴＤＯピンは、ＴＳ １１０がＳＵＴ １２０の少なくとも一部をテストするためにＳＵＴ １２０にそれによってアクセスできるバウンダリ・スキャン・チェーン内で相互接続される。
ＴＡＩ １１５は、任意の他の適切なテスト・アクセス・インターフェースを含むことができる。
当業者は、ＴＳ １１０、ＴＡＩ １１５、およびＳＵＴ １２０を、本明細書に含まれる実施形態の特徴を提供するのに適する任意の形で実施できることを了解するであろう。
本明細書で説明するように、ＴＩＳＡは、システム・テスティングにおける大きい改善を提供するためにシステム・テスティング機能と組み合わせてコンピュータ・サイエンス機能を活用することができる。システム・テスティング機能およびコンピュータ・サイエンス機能の全般的な説明がこれに続き、コンピュータ・サイエンス機能およびシステム・テスティング機能を一緒に利用してＴＩＳＡを提供できる形の説明がそれに続く。
ＴＩＳＡは、コンピュータ・サイエンス機能を活用することによってシステム・テスティング機能を改善する。システム・テスティング機能は、「自動化テスト」フロー（一般に、テスト・アルゴリズム（１つまたは複数）の定義から実際のテスティング動作に達するのに必要である可能性があるステップおよびリソースのすべてを含む）のすべてのステージで一般にサポートされる機能を含むことができる。
テスト自動化を助けるために、テスト・リソースは、しばしば、基板およびデバイスの内部に組み込まれ、通常はテスト・アクセス・ポート（ＴＡＰ）と呼ばれる標準化されたインターフェースを使用してアクセスされ得る。これは、ピン数を制限し、リソース・アクセスおよび管理を合理化するという効果を有する。複数の言語が、テストされるシステムの内部のリソースを記述するのに使用可能であり、したがって、これをテスト生成ツール（ＴＧＴ）への入力として使用することができる。ＴＧＴは、ＴＡＰに指令し、関連するテスティング動作を実行するのにテスト制御ユニット（ＴＣＵ）によって使用できるテスティング・シーケンスを生成するためにアルゴリズムを適用することができる。テスティング動作の特徴および性能は、３つの要素すなわち、アクセス標準規格、データ・フォーマット、およびＴＣＵ実施態様に依存する。
ＴＩＳＡは、改善されたシステム・テスティング機能を提供するためにコンピュータ・サイエンス機能を活用することができる。これは、「ソフトウェア開発フロー」（一般に、コンパイル、命令セット・アーキテクチャ（ＩＳＡ）、対話デバッギング、および類似物、ならびにそのさまざまな組合せなど、選ばれたソフトウェア言語（１つまたは複数）でコーディングされたソフトウェア・アルゴリズムからターゲット・プロセッサ上での最終的なデバッギングおよび実行に達するのに必要である可能性があるステップおよびリソースのいずれかまたはすべてを含む）のすべてのステージで使用可能なコンピュータ・サイエンス機能の使用を含むことができる。
コンピュータ・サイエンスでのコンパイルの使用は、プログラマフレンドリな高水準抽象化で定義されたアルゴリズムを一連の機械実行可能命令に変形する。このプロセスは、入力プログラミング言語およびプロジェクトの複雑さに依存して大幅に変化する可能性があるが、手法のすべてではないにせよほとんどが、すべてのアルゴリズムをその複雑さに関わりなく基本的な命令に分解できるという同一の基本的な仮定を共有する。これは、古典的な言語ならびにたとえばＣ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、および類似物などのより近代的な高水準言語およびオブジェクト指向言語にあてはまる。
命令セット・アーキテクチャ（ＩＳＡ）は、すべてのプロセッサの核であり、その理由は、コンパイルが非常に有効であることである。一般に、各プロセッサは、そのプロセッサを操作できる形を定義する命令のセットを提供する。これらの命令は、そのプロセッサのＩＳＡの少なくとも一部を形成する。ＩＳＡを、レジスタ、アドレッシング・モード、オペコード、メモリ構造、および類似物、ならびにそのさまざまな組合せなど、命令に関連するさまざまな構造を含むと考えることができることを了解されたい。ＩＳＡは、プロセッサが、メモリから／への値の読取り／書込みなどの単純な命令を実行し、レジスタに対する論理演算または算術演算を実行し、割込みを処理することなどを可能にする。この基本的な挙動は、経時的に本質的に変更されないままであり、現代のプロセッサは、非常に多くのリソースを効率的に活用できるので例外的な性能を達成し、したがって、ほぼ同一の時間ではるかに多数のそのような基本的な命令を完了することができる。さらに、コプロセッサ（たとえば、浮動小数点コプロセッサ、グラフィカル・コプロセッサ、および類似物）の使用から、さらにより高い性能に達することができ、このコプロセッサは、複雑な動作をハード・コーディングすることによってメイン・プロセッサを助けることができる。
コンピュータ・サイエンスでのデバッギングの使用は、ソフトウェア開発および実行プロセスの監視および検証を可能にする。一般に、ソフトウェア開発は、長くむずかしいプロセスであり、このプロセスは、最終製品が誤りまたは通常呼ばれるように「バグ」がないことを保証するために厳格に監視され、検証される。ソフトウェア・プログラムをテストするのを助けるために、ソフトウェア開発フローは、多数の強力なデバッグ機能を提供する。たとえば、一般的なソフトウェア開発フロー・デバッグ機能は、ステップバイステップ実行、すべてのレジスタおよびメモリ位置の観察可能性／制御可能性、ブレークポイントおよびウォッチポイントの使用、ならびに類似物を含む。これらのデバッグ機能ならびにさまざまな他のデバッグ機能は、よりしばしば、ソフトウェア・コンパイラによって最終コードに埋め込まれるアルゴリズムおよび構造によって使用可能にされるが、プロセッサの内部で使用可能なハードウェア・リソースによって支援することもできる。この情報から、デバッガは、オリジナル・コードを再構成し、すべてのＩＳＡレベル動作をプログラミング抽象化レイヤに相関させることができる。
改善されたシステム・テスティング機能を使用可能にするために自動化テスト実行機能およびコンピュータ・サイエンス・ソフトウェア機能を一緒に使用することは、図２および図３を参照することによってよりよく理解することができる。
図２に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態の高水準ブロック図を示す。
図２に示されているように、ＴＳ １１０は、テスト生成ツール（ＴＧＴ）２１０およびソフトウェア・コンパイラ（ＳＣ）２２０を含む。
ＴＧＴ ２１０は、ＴＧＴコンポーザ２１２およびＴＧＴアルゴリズム２１４を含む。
ＴＧＴコンポーザ２１２は、入力としてシステム記述ファイル２１１を受け入れる。システム記述ファイル２１１は、テストされるシステムをテストするためのテスティング命令／ベクトルを作るのにＴＧＴによって使用できる任意の適切な記述ファイルを含む。たとえば、システム記述ファイル２１１は、回路記述ファイル、基板／治具ネットリスト・ファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。システム記述ファイル２１１を、ＴＧＴ ２１０上で使用可能とすることができ、かつ／または１つもしくは複数のリモート・コンポーネントおよび／もしくはシステムから入手することができる。
システム記述ファイル２１１は、１つまたは複数の回路記述ファイルを含むことができる。回路記述ファイルは、ＢＳＤＬ（Ｂｏｕｎｄａｒｙ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ、基板レベルＪＴＡＧに関するＩＥＥＥ １１４９．１標準規格の一部として開発された）、ＨＳＤＬ（Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ、ＢＳＤＬの拡張として開発された）、ＮＳＤＬ（Ｎｅｗ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、および類似物ならびにそのさまざまな組合せなど、任意の適切な記述言語（１つまたは複数）を使用して指定することができる。
システム記述ファイル２１１は、１つまたは複数の基板／治具ネットリスト・ファイルを含むことができる。基板／治具ネットリスト・ファイルは、ネットリスト、接続、および類似する情報を記述する、デバイス（１つまたは複数）の物理記述に関係するファイルを含むことができる。基板／治具ネットリスト・ファイルは、ＰＣＢ、Ｇｅｒｂｅｒ、および／または基板／治具ネットリスト・ファイルに適する任意の他のフォーマットなど、任意の適切なフォーマットで指定することができる。
システム記述ファイル２１１は、１つまたは複数の他の記述ファイルを含むことができる。他の記述ファイルは、回路モデルを作るための入力として使用できる任意の他の適切な記述ファイルを含むことができる。たとえば、他の記述ファイルは、Ａｓｓｅｔ社のＭａｃｒｏ Ｌａｎｇｕａｇｅ、Ｇｏｅｐｅｌ社のＣＡＳＬＡＮ言語、および／または任意の他の適切な記述言語ファイルなど、任意の適切なアプリケーション固有および／またはツール固有の記述言語ファイルを含むことができる。
ＴＧＴコンポーザ２１２は、システム記述ファイル２１１を処理して回路モデル２１３を作る。回路モデル２１３を作るためのＴＧＴコンポーザ２１２によるシステム記述ファイル２１１の処理は、任意の適切な形で実行することができる。回路モデル２１３は、テストされるシステムまたはテストされるシステムのうちでＴＧＴ ２１０がそれのために実行されつつある部分のモデルを指定する。ＴＧＴコンポーザ２１２は、回路モデル２１３をＴＧＴアルゴリズム２１４に供給する。
ＴＧＴアルゴリズム２１４は、回路モデル２１３を受け入れる。ＴＧＴアルゴリズム２１４は、回路モデル２１３を処理して、ＴＧＴ不可分テスト動作２１６を作る。ＴＧＴ不可分テスト動作２１６を作るためのＴＧＴアルゴリズム２１４による回路モデル２１３の処理は、任意の適切な形で実行することができる。
ＳＣ ２２０は、ＳＣフロントエンド・アルゴリズム２２２およびＳＣバックエンド・アルゴリズム２２４を含む。
ＳＣフロントエンド・アルゴリズム２２２は、入力としてコンピュータ・サイエンス・ソース・ファイル２２１を受け入れる。コンピュータ・サイエンス・ソース・ファイル２２１は、コンパイラによってコンパイルできる任意の適切なコンピュータ・サイエンス・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル２２１は、Ｃ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語（１つまたは複数）のコンピュータ・サイエンス・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル２２１は、１つもしくは複数のＣファイル、１つもしくは複数のＣ＋＋ファイル、および／または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの１つまたは複数を含むことができる。
ＳＣフロントエンド・アルゴリズム２２２は、コンピュータ・サイエンス・ソース・ファイル２２１を処理してプログラム・モデル２２３を作る。プログラム・モデル２２３は、コンピュータ・サイエンス・ソース・ファイル２２１の中間表現を指定する。ＳＣフロントエンド・アルゴリズム２２２は、プログラム・モデル２２３をＳＣバックエンド・アルゴリズム２２４に供給する。
ＳＣバックエンド・アルゴリズム２２４は、入力としてプログラム・モデル２２３を受け入れる。ＳＣバックエンド・アルゴリズム２２４は、プログラム・モデル２２３を処理して、ＩＳＡ不可分動作２２６を含む１つまたは複数のＩＳＡ２進ファイル２２５を作る。ＩＳＡ不可分動作２２６を含むＩＳＡ２進ファイル２２５を形成するためのＳＣバックエンド・アルゴリズム２２４によるプログラム・モデル２２３の処理は、任意の適切な形で実行することができる。ＩＳＡ不可分動作２２６は、ＴＩＳＡがそれのために実施されるプロセッサによってサポートされるアセンブリレベル命令である。
図２に示されているように、ＴＧＴ ２１０およびＳＣ ２２０のそれぞれの処理フローに加えて、ＴＧＴ ２１０とＳＣ ２２０との間の追加の相互作用を、ＴＩＳＡ不可分動作２３５の生成を制御するのに利用することができる。一実施形態では、ＳＣバックエンド・アルゴリズム２２４は、ＴＧＴアルゴリズム２１４への１つまたは複数のベクトル計算要求２３０を開始することができる。ＳＣバックエンド・アルゴリズム２２４は、ＳＣバックエンド・アルゴリズムがＴＡＰにアクセスすることを必要とする時に、ベクトル計算要求２３０を開始することができる。ＴＧＴアルゴリズム２１４は、ＳＣバックエンド・アルゴリズム２２４からベクトル計算要求２３０を受け取った時に、受け取られたベクトル計算要求２３０に基づいてＴＡＰに関する１つまたは複数のＴＧＴ不可分テスト動作２１６を生成する。次に、１つまたは複数のＴＧＴ不可分テスト動作２１６を、ＳＣバックエンド・アルゴリズム２２４によって制御される形でＴＡＰに適用することができる。というのは、ＴＧＴ不可分テスト動作２１６が、ＩＳＡ不可分動作２２６と組み合わされて、ＩＳＡ不可分動作２２６を使用するＴＧＴ不可分テスト動作２１６に対するアルゴリズム的制御を可能にするからである。この形で、ＳＣ ２２０は、ＴＡＰへのアクセスのアルゴリズム的制御を提供する。
図２に示されているように、ＴＧＴ ２１０およびＳＣ ２２０に加えて、ＴＳ １１０は、さらに、ＴＩＳＡコンポーザ２４０を含む。ＴＩＳＡコンポーザ２４０は、ＴＧＴ不可分テスト動作２１６およびＩＳＡ不可分動作２２６を受け入れる。ＴＩＳＡコンポーザ２４０は、ＴＧＴ不可分テスト動作２１６をＴＩＳＡ命令に変換し、それらのＴＩＳＡ命令をＩＳＡ２進ファイル（１つまたは複数）２２５に挿入する（すなわち、ＴＩＳＡ命令をＩＳＡ不可分動作２２６と組み合わせて、これによって、ＴＩＳＡ不可分動作２４６を含むＴＩＳＡ２進ファイル２４５を形成する。ＴＩＳＡコンポーザ２４０は、ＴＧＴ ２１０の一部とするか、ＳＣ ２２０の一部とするか、ＴＧＴ ２１０およびＳＣ ２２０にまたがって分割されるか、ＴＧＴ ２１０およびＳＣ ２２０とは別々に実施されるものなどとすることができる。
図２に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ／または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
図３に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態の高水準ブロック図を示す。
図３に示されているように、図３のＴＳ １１０は、ＴＩＳＡ不可分動作を含むＴＩＳＡ２進ファイルがテスト生成ツールとソフトウェア・コンパイラとの間の相互作用を使用して生成されるという点で、図２のＴＳ １１０に似た形で動作する。しかし、図３のＴＳ １１０でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用は、図２のＴＳ １１０でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用とは異なる。
図３に示されているように、ＴＳ １１０は、テスト生成ツール（ＴＧＴ）３１０およびソフトウェア・コンパイラ（ＳＣ）３２０を含む。
ＴＧＴ ３１０は、ＴＧＴコンポーザ３１２およびＴＧＴアルゴリズム３１４を含む。
ＴＧＴコンポーザ３１２は、入力としてシステム記述ファイル３１１を受け入れる。システム記述ファイル３１１は、テストされるシステムをテストするためのテスティング命令／ベクトルを作るのにＴＧＴによって使用できる任意の適切な記述ファイルを含む。たとえば、システム記述ファイル３１１は、回路記述ファイル、基板／治具ネットリスト・ファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。図３のシステム記述ファイル３１１は、図２に関して図示し、説明したシステム記述ファイル２１１に似たシステム記述ファイル（たとえば、１つまたは複数の回路記述ファイル、１つまたは複数の基板／治具ネットリスト・ファイル、１つまたは複数の他の記述ファイル、および類似物、ならびにそのさまざまな組合せ）を含むことができる。システム記述ファイル３１１を、ＴＧＴ ３１０上で使用可能とすることができ、かつ／または１つもしくは複数のリモート・コンポーネントおよび／もしくはシステムから入手することができる。
ＴＧＴコンポーザ３１２は、入力として１つまたは複数のテスト動作記述ファイル３３１１−３３１Ｎ（集合的にテスト動作記述ファイル３３１）を受け入れる。テスト動作記述ファイル３３１は、ＳＣ ３２０によって生成される。ＳＣ ３２０によるテスト動作記述ファイル３３１の生成を、下で詳細に説明する。
ＴＧＴコンポーザ３１２は、システム記述ファイル３１１およびテスト動作記述ファイル３３１を処理して、回路モデル３１３を作る。回路モデル３１３を作るためのＴＧＴコンポーザ３１２によるシステム記述ファイル３１１の処理は、任意の適切な形で実行することができる。回路モデル３１３は、テストされるシステムまたはテストされるシステムのうちでＴＧＴ ３１０がそれのために実行されつつある部分のモデルを指定する。テスト動作記述ファイル３３１に関連するシステム記述ファイル３１１の処理は、ＴＧＴ ３１０が適切なＴＡＰ不可分動作を作ることを可能にする形で、ＴＧＴコンポーザ３１２が回路モデル３１３を作ることを可能にする。ＴＧＴコンポーザ３１２は、回路モデル３１３をＴＧＴアルゴリズム３１４に供給する。
ＴＧＴアルゴリズム３１４は、回路モデル３１３を受け入れる。ＴＧＴアルゴリズム３１４は、回路モデル３１３を処理して、ＴＧＴ不可分テスト動作３１６を作る。ＴＧＴ不可分テスト動作３１６を作るためのＴＧＴアルゴリズム３１４による回路モデル３１３の処理は、任意の適切な形で実行することができる。
図３に示されているように、ＴＧＴ ３１０およびＳＣ ３２０に加えて、ＴＳ １１０は、ＴＩＳＡトランスレータ３４０を含む。ＴＩＳＡトランスレータ３４０は、ＴＧＴ不可分テスト動作３１６を受け取る。ＴＩＳＡトランスレータ３４０は、ＴＧＴ不可分テスト動作３１６を変換して、ＴＩＳＡ不可分テスト動作３４６を形成する。ＴＩＳＡトランスレータ３４０は、ソフトウェア・コンパイル・プロセスに含めるために、ＴＩＳＡ不可分テスト動作３４６をＳＣ ３２０に供給する。ＳＣ ３２０によるＴＩＳＡ不可分テスト動作３４６の使用を、下で詳細に説明する。ＴＩＳＡトランスレータ３４０は、ＴＧＴ ３１０の一部とするか、ＳＣ ３２０の一部とするか、ＴＧＴ ３１０およびＳＣ ３２０にまたがって分割されるか、ＴＧＴ ３１０およびＳＣ ３２０とは別々に実施されるものなどとすることができる。
ＳＣ ３２０は、ＳＣプリコンパイラ３３０、ＳＣフロントエンド・アルゴリズム３２２、およびＳＣバックエンド・アルゴリズム３２４を含む。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を受け入れる。
コンピュータ・サイエンス・ソース・ファイル３２１は、コンパイラによってコンパイルできる任意の適切なコンピュータ・サイエンス・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル３２１は、Ｃ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語（１つまたは複数）のコンピュータ・プログラミング・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル３２１は、１つもしくは複数のＣファイル、１つもしくは複数のＣ＋＋ファイル、および／または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの１つまたは複数を含むことができる。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を処理する。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を処理し、それから前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを作る。コンピュータ・サイエンス・ソース・ファイル３２１をＳＣプリコンパイラ３３０によって前処理して、任意の適切な形で前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを形成することができる。ＳＣプリコンパイラ３３０は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐをフロントエンド・アルゴリズム３２２に供給する。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１の処理中にテスト動作を検出し、テスト動作記述ファイル３３１を生成する。テスト動作記述ファイル３３１は、任意の適切なテスト記述言語を使用して（たとえば、１つまたは複数の標準テスト記述言語を使用して、ＴＧＴ ３１０に固有のテスト記述言語を使用して、および類似物、ならびにそのさまざまな組合せ）指定することができる。ＳＣプリコンパイラ３３０は、テスト動作記述ファイル３３１をＴＧＴ ３１０に（実例として、回路モデル３１３を作るためにシステム記述ファイル３１１に関連してテスト動作記述ファイル３３１を処理する、ＴＧＴ ３１０のＴＧＴコンポーザ３１２に供給する。
ＳＣフロントエンド・アルゴリズム３２２は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを受け入れる。ＳＣフロントエンド・アルゴリズム３２２は、ＴＩＳＡ不可分テスト動作３４６をも受け入れ、このＴＩＳＡ不可分テスト動作３４６は、テスト動作記述ファイル３３１からＴＧＴ ３１０によって作られたＴＧＴ不可分テスト動作３１６を使用してＴＩＳＡトランスレータ３４０によって作られる。ＳＣフロントエンド・アルゴリズム２２２は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１ＰおよびＴＩＳＡ不可分テスト動作３４６をコンパイルして、プログラム・モデル３２３を作る。プログラム・モデル３２３は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐの中間表現を指定し、この中間表現は、ＴＩＳＡ不可分動作を形成するためにＴＩＳＡ不可分テスト動作３４６をＩＳＡ不可分動作内に統合できるように、ＴＩＳＡ不可分テスト動作３４６を含む。ＳＣフロントエンド・アルゴリズム３２２は、プログラム・モデル３２３をＳＣバックエンド・アルゴリズム３２４に供給する。
ＳＣバックエンド・アルゴリズム３２４は、プログラム・モデル３２３を受け入れる。ＳＣバックエンド・アルゴリズム３２４は、プログラム・モデル２２３を処理して、ＴＩＳＡ不可分動作３５６を含む１つまたは複数のＴＩＳＡ２進ファイル３５５を作る。ＴＩＳＡ不可分動作３５６を含むＴＩＳＡ２進ファイル３５５を形成するためのＳＣバックエンド・アルゴリズム３２４によるプログラム・モデル３２３の処理は、任意の適切な形で実行することができる。
ＴＩＳＡ不可分動作３５６は、ＩＳＡ不可分動作（すなわち、ＴＩＳＡがそれに対して実施されるプロセッサによってサポートされるアセンブリレベル命令）およびＴＩＳＡ不可分テスト動作３４６を含む。
ＴＩＳＡ不可分動作３５６は、ＴＧＴ不可分テスト動作３１６（すなわち、ＴＩＳＡ不可分テスト動作３４６の形の）に対するアルゴリズム的制御（ＩＳＡ不可分動作を使用する）を提供し、これによって、ＴＩＳＡ不可分動作３５６が適用されるテストされるシステムの改善されたシステム・テスティングを可能にする。したがって、ＴＧＴ不可分テスト動作３１６（すなわち、ＴＩＳＡ不可分テスト動作３４６の形の）を、ＳＣバックエンド・アルゴリズム３２４によって制御される形でＴＡＰに適用することができる。というのは、ＴＧＴ不可分テスト動作３１６が、ＩＳＡ不可分動作を使用するＴＧＴ不可分テスト動作３１６に対するアルゴリズム的制御を可能にするために、ＩＳＡ不可分動作と組み合わされるからである。この形で、ＳＣ ２２０は、ＴＡＰへのアクセスのアルゴリズム的制御を提供する。
図３に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ／または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
図２および図３に関して、主に特定の個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物に関して図示し、説明したが、図２および図３の実施形態ならびに本明細書で提供されるさまざまな関連する教示を、任意の適切な個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物を使用して実施できることを了解されたい。
図２および図３は、コンピュータ・サイエンス機能を活用してシステム・テスティング機能が改善され得る形を示す（たとえば、システム・テスティングの細粒度制御の提供、対話システム・テスティングの使用可能化、システム・テスティング中の対話デバッギングの使用可能化、および図示され本明細書で説明されるさまざまな他の利益の提供）。図２および図３のシステム・テスティング方式は、ＳＴＡＰＬなどの既存手法に対する改善を提供し、これらの既存手法では、目標は、ベクトル・フォーマットにプログラミング機能を追加することであり、したがって、デバッギング機能、リモート・アクセス機能、および対話性機能が、ゼロから追加される。対照的に、ＴＩＳＡは、システム・テスティング用のテスト・アクセスを制御するために、コンピュータ・プログラミングおよび組込みアプリケーションからの豊富な情報を活用する。
図２および３を参照して、ＴＩＳＡの機能および特徴が、その抽象化レベルによって定義される、すなわち、ＴＩＳＡ不可分動作の定義が微細であればあるほど、ＴＩＳＡがより良い性能を提供することを了解されたい。
ＴＩＳＡがＪＴＡＧアーキテクチャ内で実施される一実施形態では、３つの抽象化レベルを、スキャン動作のためにサポートすることができる。
第１の抽象化レベルは、ベクトル・レベルである。ベクトル・レベルは、３つの抽象化レベルのうちで最も粗な粒度であり、ここでは、不可分動作は、スキャン・ベクトルの入力および出力である。ベクトル・レベルは、ＳＶＦ（Ｓｅｒｉａｌ Ｖｅｃｔｏｒ Ｆｏｒｍａｔ）または任意の他の適切なベクトル・フォーマットなどのベクトル・フォーマットで最もよく表され、最高レベルの制御を与える。
第２の抽象化レベルは、ＴＡＰレベルである。ＴＡＰレベルでは、不可分動作は、ＴＡＰ状態機械に対する十分な制御を可能にするために機能強化される。これは、スキャン動作に対するより洗練された制御、非標準シーケンス（たとえば、たとえばＡｄｄｒｅｓｓａｂｌｅ Ｓｈａｄｏｗ Ｐｒｏｔｏｃｏｌまたは他の類似するプロトコルで要求されるシーケンスなど）のサポートを可能にする。
第３の抽象化レベルは、スキャン・セグメント・レベルである。スキャン・セグメント・レベルは、３つの抽象化レベルのうちで最も微細な粒度である。ベクトル・レベルおよびＴＡＰレベルの抽象化レベルは、不可分データ・フォーマットとしてスキャン・ベクトルを使用し、これは、スキャン・チェーン全体が用いられる伝統的な導通テストには十分であるが、スキャン・チェーンを構成する数十個または数百個の機器に対する細粒度制御の必要がある機器ベースのテスティング（ｉｎｓｔｒｕｍｅｎｔ−ｂａｓｅｄ ｔｅｓｔｉｎｇ）には面倒である。スキャン・セグメント・レベルは、全体的なスキャン・パスの内部の「スキャン・セグメント」の定義を可能にし、このスキャン・セグメントは、別々に処理することができ、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。この手法は、使用可能な計算リソースが非常に限られている場合がある組込み応用例で有利である。スキャン・セグメント・レベルの使用を、図示し、下でさらに詳細に説明する
図２および図３に示されているように、スキャン動作の抽象化レベルに関わりなく、ＴＧＴによって計算される、結果のＴＡＰ不可分動作（実例として、ＴＧＴ不可分テスト動作２１６およびＴＧＴ不可分テスト動作３１６）は、対応するＴＩＳＡ不可分テスト動作に変換され、２進実行可能ファイルに（たとえば、ＳＣによって生成されたＩＳＡ不可分動作に）挿入される。
図２を参照すると、ＴＧＴ不可分テスト動作２１６およびＩＳＡ不可分動作２２６を処理して、ＴＩＳＡ２進実行可能ファイル（実例として、ＴＩＳＡ２進ファイル２４５）内のＴＩＳＡ不可分動作２４６を形成することができる。ＴＩＳＡ不可分動作２４６は、ＴＩＳＡ不可分テスト動作およびＩＳＡ不可分動作を含む。
図３を参照すると、ＴＩＳＡ不可分テスト動作（ＴＧＴ ３１０によって作られたＴＧＴ不可分テスト動作３１６からＴＩＳＡトランスレータ３４０によって生成される）を、ＳＣ ３１０のＳＣフロントエンド３２４を変更することを全く必要とせずに、前コンパイル済みアセンブリ命令としてＳＣフロントエンド３２４に入力することができる。ほとんどすべてのプログラミング言語が、そのような動作を可能にすることを了解されたい。たとえば、Ｃでは、この動作が、「ａｓｍ」コマンドを使用して得られる。一実施形態では、ＳＣバックエンド・アルゴリズム３２４に対する些細な変更が必要になる場合がある（たとえば、ＴＩＳＡアセンブラ命令の２進変換を処理するために）。そのようなプロセスの例を、図１１に関して図示し、本明細書で説明する。
主にＪＴＡＧアーキテクチャでのＴＩＳＡ不可分動作の粒度のレベルに関して図示し、説明したが、当業者は、ＴＩＳＡ不可分動作の粒度の同一のレベルを他のアーキテクチャで利用でき、ＴＩＳＡ不可分動作の粒度の異なるレベルを、ＪＴＡＧアーキテクチャおよび／または他のアーキテクチャ、類似物、ならびにそのさまざまな組合せで利用できることを了解するであろう。
上で説明したように、ＴＩＳＡを、任意の適切な命令セット・アーキテクチャ（ＩＳＡ）を使用して実施することができる。たとえば、ＴＩＳＡを、ＳＰＡＲＣ Ｖ８ ＩＳＡ、ＩＮＴＥＬ ＩＳＡ、および類似物を使用して実施することができる。
ＴＩＳＡの実施態様を説明する際の明瞭さのために、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの例示的実施態様を、本明細書で図４Ａ〜４Ｅに関して図示し、説明する。この例示的実施態様では、ＴＩＳＡは、ベクトル・レベルＴＩＳＡとして実施され、このベクトル・レベルＴＩＳＡは、ＳＶＦフォーマットを構成する命令の直接コーディングを可能にするが、上で説明したように、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施を、ＴＩＳＡがＴＡＰレベルＴＩＳＡまたはスキャン・セグメント・レベルＴＩＳＡとして実施される場合にも実行できることを了解されたい。
ＳＰＡＲＣ Ｖ８ ＩＳＡは、オープンソース・ソフト・プロセッサ・ファミリＬｅｏｎ ２およびＬｅｏｎ ３など、多数の製品で実施されている。
「Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ Ｖｅｒｓｉｏｎ ８」、ＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ刊、１９９２年（以下では「ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ」）の再検討によって、ＳＰＡＲＣ Ｖ８ ＩＳＡによって活用されていない多数の符号語があることが明らかになる。これは、少なくともＡｐｐｅｎｄｉｘ Ｆの「ｏｐｃｏｄｅｓ ａｎｄ ｃｏｎｄｉｔｉｏｎ ｃｏｄｅｓ（オペコードおよび条件コード）」の再検討から明白である。
図４Ａに、ＳＰＡＲＣ Ｖ８ ＩＳＡの未活用符号語を示す。図４Ａに示された未活用符号語は、ＴＩＳＡの「テスト」命令をコーディングするのに使用することができる。より具体的には、「ｏｐ」と「ｏｐ２」との両方に０がセットされている時に、その命令は、「Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ Ｖｅｒｓｉｏｎ ８」では未実施としてマークされ、その命令をＴＩＳＡに使用できるようになっている。
図４Ｂに、１３個のＳＶＦ命令のすべてを表すことができるコーディング・フォーマットを示す。図４Ｂに示されているように、ビット３０〜２５は、命令コーディング自体を含み、ビット２１〜１８は、ＴＡＰ状態が命令と共に使用される場合にそのＴＡＰ状態をコーディングするのに使用することができ、ビット１７〜１４は、必要な場合にオプション情報を指定するのに各命令によって使用することができる。
図４Ｃに、ＩＥＥＥ １１４９．１ ＴＡＰのＴＡＰ状態の例示的ビット・コーディングを示す。ＴＡＰ状態のビット・コーディングは、ＩＥＥＥ １１４９．１ ＴＡＰ状態名を識別する第１列、ＩＥＥＥ １１４９．１ ＴＡＰ状態名に関連するＳＶＦ ＴＡＰ状態名を識別する第２列、および図４Ｂのビット２１〜１８のビット・コーディングを識別する第３列を使用して表されている。ビット・コーディングを、さまざまな他の形でＴＡＰ状態に割り当てることができることを了解されたい。
ＳＶＦ命令は、複数のパラメータを可能にし、これらのパラメータは、最終的なコードの内部でコーディングされる必要がある。パラメータを表すために、また、命令およびデータを別々に保つという通常のアーキテクチャ的ベスト・プラクティスのために、レジスタベースのパラメータ渡しが、ベクトル・レベルＴＩＳＡのこの例示的実施態様のために定義される。したがって、ベクトル・レベルＴＩＳＡは、６つの専用３２ビット・レジスタすなわち、ＧＥＮＥＲＩＣ１、ＧＥＮＥＲＩＣ２、ＴＤＩ、ＴＤＯ、ＭＡＳＫ、およびＳＭＡＳＫを提示する。この６つの専用３２ビット・レジスタを、図４Ｄに示す。６つの専用３２ビット・レジスタの使用を、下で詳細に説明するが、一般的ルールとして、これらのレジスタは、パラメータを格納するか、パラメータが格納されるメモリ位置をポイントするかのいずれかに使用される。したがって、コンパイル時に、通常のＩＳＡ命令を使用して、ＴＩＳＡ命令が呼び出される前にこれらのレジスタをロードすることができる。より具体的には、ＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様では、コプロセッサ・レジスタを、通常のロード／ストア命令のパラメータとして直接に使用することができる。
ＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様で利用できるＳＶＦ命令は、ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ、ＦＲＥＱＵＥＮＣＹ、ＰＩＯ、ＰＩＯＭＡＰ、ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ、ＳＤＲ、ＳＩＲ、およびＲＵＮＴＥＳＴを含む。これらのＳＶＦ命令は、参照によってその全体が本明細書に組み込まれている、「Ｓｅｒｉａｌ Ｖｅｃｔｏｒ Ｆｏｒｍａｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ＡＳＳＥＴ ＩｎｔｅｒＴｅｃｈ，Ｉｎｃ．、１９９７年（以下ではＳＶＦマニュアルと称する）を参照することによってよりよく理解することができる。ＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様でのこれらのＳＶＦ命令の使用を、下でより詳細に説明する。
ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ
ＥＮＤＤＲ命令およびＥＮＤＩＲ命令は、ＴＡＰインターフェースがその動作を終了するＴＡＰ状態を示す。ＳＴＡＴＥ命令は、強制的にＴＡＰインターフェースを指定された状態にする。ＴＩＳＡのこの例示的実施態様では、ＥＮＤＤＲ命令、ＥＮＤＩＲ命令、およびＳＴＡＴＥ命令のＳＶＦコーディングは、図４Ｅに示されているようにそれぞれ「００００００」、「０００００１」、および「００００１０」である。これらのＳＶＦ命令のＳＶＦコーディングは、必要に応じて「ＴＡＰ状態」ファイル（すなわち、図４Ｃに示されたＴＡＰ状態の例示的ビット・コーディング）を使用して実行することができる。少なくともＳＶＦマニュアルの再検討から、ＳＴＡＴＥ命令がオプションでパラメータとして状態の明示的シーケンスをとることができることを了解されたい。ＴＩＳＡのこの例示的実施態様では、パラメータとして状態の明示的シーケンスをとることは、シーケンス内の状態ごとに１命令の、一連の命令によってコーディングされるはずである。
ＦＲＥＱＵＥＮＣＹ
ＦＲＥＱＵＥＮＣＹ命令は、ＴＡＰインターフェースの動作周波数を指定するのに使用される。ＦＲＥＱＵＥＮＣＹ命令は、Ｈｚサイクルの３２ビット整数として表される。ＴＩＳＡのこの例示的実施態様では、ＦＲＥＱＵＥＮＣＹ命令のＳＶＦコーディングは、図４Ｅに示されているように、「００００１１」である。ＦＲＥＱＵＥＮＣＹ命令の値は、ＧＥＮＥＲＩＣ１レジスタに格納される。
ＰＩＯ、ＰＩＯＭＡＰ
ＰＩＯ命令は、ＰＩＯＭＡＰへの呼出しによって以前にセットされたフォーマットの並列ベクトルを処理するのに使用することができる。ＲＩＳＡのこの例示的実施態様では、ＰＩＯＭＡＰは、ＴＡＰインターフェースをセットアップするのに適切なコマンドを生成するプリプロセッサ・ディレクティブとみなされる。したがって、ＰＩＯ命令は、単に、並列ベクトルを表すことを必要とし、この並列ベクトルは、この並列ベクトルが格納されているアドレスを示す（ＧＥＮＥＲＩＣ１レジスタ内で）ことによって表すことができる。ベクトルを構成する語数「ｎ」は、この命令のビット１３〜０で指定され、したがって、ベクトルは、２１３＝８Ｋ語＝３２Ｋバイトのサイズ上限を有する。ベクトル・サイズが１語の正確な倍数ではない場合には、必要に応じてパディングおよび再アライメントをメモリ内で提供することができる。ＴＩＳＡのこの例示的実施態様では、ＰＩＯ命令のＳＶＦコーディングは、「０００１００」である。
ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ
ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令の役割は、異なる。ここでは、これらのＳＶＦ命令を一緒に検討する。というのは、（１）これらのＳＶＦ命令が、機能的に類似し（すなわち、これらのすべてが、異なる性質のものである場合であっても、シフト演算を指令する）、（２）これらのＳＶＦ命令が、次の同一のパラメータを受け入れるからである。
（１）ｌｅｎｇｔｈ シフトすべきビット数を表す３２ビット数
（２）ＴＤＩ（オプション） 入力シフト・ベクトル
（３）ＴＤＯ（オプション） 期待される出力シフト・ベクトル
（４）ＭＡＳＫ（オプション） 実際の値をＴＤＯと比較する時に使用すべきマスク。「１」は関係を示し、「０」は無関係を示す。
（５）ＳＭＡＳＫ（オプション） どのビットをＴＤＩにおいて考慮すべきか示すためのマスク。「１」は関係を示し、「０」は無関係を示す。
ＴＩＳＡのこの例示的実施態様では、ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令のＳＶＦコーディングは、図４Ｅに示されているように、それぞれ「０００１１０」、「０００１１１」、「００１０１０」、および「００１０１１」である。
ＴＩＳＡのこの例示的実施態様では、次の追加のコーディングを使用することができる。
（１）ｌｅｎｇｔｈは、ＧＥＮＥＲＩＣ１レジスタに格納される。
（２）Ｏ１は、ＴＤＩが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＴＤＩレジスタは、入力ベクトルが格納されているアドレスを含む。
（３）Ｏ２は、ＴＤＯが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＴＤＯレジスタは、期待される出力が格納されているアドレスを含む。
（４）Ｏ３は、ＭＡＳＫが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＭＡＳＫレジスタは、出力マスクが格納されているアドレスを含む。
（５）Ｏ４は、ＳＭＡＳＫが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＳＭＡＳＫレジスタは、出力マスクが格納されているアドレスを含む。
ＳＤＲ、ＳＩＲ
ＳＤＲ命令およびＳＩＲ命令は、ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令と同一の構文を有するが、機能的相違を有し、ＳＤＲおよびＳＩＲは、ＴＡＰに対する実際のスキャン動作をトリガする。対話テスティングでは、システムから読み取られた実際の出力ベクトルが、アルゴリズムの基礎であり、したがって、ＴＩＳＡは、実際の出力ベクトルをメモリ内に格納する可能性を提供する。「ＴＡＰ状態」フィールド（図４Ｂに示されたビット２１〜１８）が０とは異なる時には、ＧＥＮＥＲＩＣ２レジスタは、実際の出力ベクトルのストレージ位置を示す。したがって、ＳＤＲおよびＳＩＲは、最大７個のパラメータをサポートすることができる。ＴＤＯが指定され、実際の出力ベクトルが期待される出力ベクトルとは異なる場合には、ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ ＭａｎｕａｌのＳｅｃｔｉｏｎ ４．２に記載されているように、オーバーフロー・フラグがプロセッサ状態レジスタ（ＰＳＲ）内でセットされる。
ＲＵＮＴＥＳＴ
ＲＵＮＴＥＳＴ命令は、強制的にＴＡＰインターフェースに指定された長さの時間だけ指定された状態でテストを実行させ、主にＲＵＮＢＩＳＴ動作（たとえば、ＩＥＥＥ １１４９．１で定義されている）を制御するのに使用される。ＲＵＮＴＥＳＴ命令は、次のパラメータ（すべてがオプションである）のうちの１つまたは複数を受け入れる。
（１）ｒｕｎ＿ｓｔａｔｅ インターフェースがテスト実行中に維持しなければならない状態
（２）ｒｕｎ＿ｃｏｕｎｔ テストが費やさなければならないクロック・サイクル数
（３）ｒｕｎ＿ｃｌｋ ｒｕｎ＿ｃｏｕｎｔがどのクロックを参照するのか（ＴＣＫ：ＴＡＰクロック、ＳＣＫ：システム・クロック）
（４）ｍｉｎ＿ｔｉｍｅ 実数として表された、秒単位の最小実行時間
（５）ｍａｘ＿ｔｉｍｅ 実数として表された、秒単位の最大実行時間
（６）ｅｎｄｓｔａｔｅ インターフェースがコマンドの終りに達しなければならない状態
ＴＩＳＡのこの例示的実施態様では、ＲＵＮＴＥＳＴ命令のＳＶＦコーディングを、「０００１０１」または「１００１０１」とすることができる。
ＴＩＳＡのこの例示的実施態様では、次の追加のコーディングを使用することができる。
（１）ＴＡＰ＿ＳＴＡＴＥ それについて定義されたｒｕｎ＿ｓｔａｔｅを含む。
（２）Ｏ１ ＴＡＰ＿ＳＴＡＴＥが定義されている場合には「１」、そうでない場合には「０」
（３）Ｏ２ ｍｉｎ＿ｃｏｕｎｔが指定されている場合には「１」、そうでない場合には「０」。セットされている場合には、ＧＥＮＥＲＩＣ１レジスタが、ｍｉｎ＿ｃｏｕｎｔの３２ビット符号なし表現を含む。
（４）Ｏ３ ｍａｘ＿ｔｉｍｅが指定されている場合には「１」、そうでない場合には「０」。セットされている場合には、ＧＥＮＥＲＩＣ２レジスタが、ｍａｘ＿ｃｏｕｎｔの３２ビット符号なし表現を含む。
（５）Ｏ４ ｅｎｄｓｔａｔｅがセットされている場合には「１」、そうでない場合には「０」。セットされている場合には、ビット１３〜１０が終了状態を含む。
（６）ビット９〜０ ｒｕｎ＿ｃｏｕｎｔが指定されている場合には、符号なし整数として表される（最大ｒｕｎ＿ｃｏｕｎｔ＝２１０＝１０２４）。このフィールドが「０」ではない場合には、ビット３０がｒｕｎ＿ｃｌｏｃｋを示す（「１」＝ＴＣＫ、「０」＝ＳＣＫ）。
主にＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様での特定のＳＶＦ命令（すなわち、ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ、ＦＲＥＱＵＥＮＣＹ、ＰＩＯ、ＰＩＯＭＡＰ、ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ、ＳＤＲ、ＳＩＲ、およびＲＵＮＴＥＳＴ）の使用に関して図示し、本明細書で説明したが、より少数またはより多数のＳＶＦ命令を使用できることを了解されたい。
主にＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様に関して図示し、本明細書で説明したが、さまざまな他のＩＳＡを利用して、図示され本明細書で説明されるＴＩＳＡ教示によるＴＩＳＡを実施できることを了解されたい。
対話テスティング手法では、データ・ハンドオフ・ポイントが非常に重要である。上で説明したように、テスト・プログラムは、２つの主要部分すなわち、アルゴリズム部分（ソフトウェア・コンパイラによって表される）およびテスト・アクセス部分（テスト生成ツールによって表される）からなる。テスティング・プログラムを使用するテスト動作中には、テスト・プログラムがテストされるシステムにアクセスしている瞬間と、テスト・プログラムがテスト結果を検査し、必要な次のステップ（１つまたは複数）を判断している瞬間とがある。この２つの動作の間でのハンドオフは、効率的な対話テスティングを得るために重要である。
ＳＶＦおよびＳＴＡＰＬなどの既存のスクリプトベースの手法では、スクリプトが、ベクトル・レベルですべてのＴＡＰ動作の世話をする。このレベルでは、インターフェース（または「プレイヤ」）は、ＴＡＰプロトコルを用いて通信し、テストされるシステムへ／からベクトルを送る／受け取ることができる。さらに、ＳＴＡＰＬは、いくつかの基本的なフロー制御（ｉｆ−ｔｈｅｎ−ｅｌｓｅ）およびビット・ベクトルに対するアルゴリズム的操作をも可能にする。より洗練された処理（たとえば、受け取られたベクトルの内部のレジスタを識別する、または特定のデバイスにアクセスするためのベクトルを計算する）の必要がある場合には、プレイヤは、アルゴリズム部分に制御をハンド・オーバーする。ＳＴＡＰＬでは、これが「ｅｘｐｏｒｔ」コマンドを介して行われる。しかし、不利なことに、ＳＶＦおよびＳＴＡＰＬの両方が、これに関する標準化されたフォーマットを有しない（たとえば、ＳＴＡＰＬの場合に、ハンドオフ・プロセスは、通常は、所与のベンダにプロプライエタリである）。
Ｅｒｉｃｓｓｏｎ社のＭＴＣ（Ｍａｓｔｅｒ Ｔｅｓｔ Ｃｏｎｔｒｏｌｌｅｒ）およびＳｙｓｔｅｍ ＢＩＳＴ Ｐｒｏｃｅｓｓｏｒなどの既存の組込み手法では、アルゴリズム部分とテスト・アクセス部分との間の同一の区分が使用される。そのような組込み手法では、アルゴリズム部分およびテスト・アクセス部分は、別々にプログラムされなければならない異なるプロセッサによって実行される。さらに、アルゴリズム部分およびテスト・アクセス部分のメモリ空間は、物理的に異なり、結果のハンドオフ機構が、ＳＴＡＰＬのハンドオフ機構に類似するようになっている。その結果は、テスト・アクセス部分用のコプロセッサが、アルゴリズム部分へのハンドオフの前に大量のスキャン部分を格納することを強制されることであり、これは、スキャン・チェーンの増加するサイズを考慮すると、大量のリソースを必要とする可能性がある。
統合テスティングに対する既存手法（たとえば、ＳＶＦおよびＳＴＡＰＬなどのスクリプトベースの手法ならびにＭＴＣおよびＳｙｓｔｅｍ ＢＩＳＴ Ｐｒｏｃｅｓｓｏｒなどの組込み手法）とは対照的に、ＴＩＳＡは、テスト・アクセス部分（すなわち、テスト動作）をアルゴリズム部分（すなわち、古典的ＩＳＡ）の内部に統合し、テスト・アクセス部分およびアルゴリズム部分が同一の物理メモリ空間を共有するようにし、これによって、テスト・アクセス部分とアルゴリズム部分との間のハンドオフ（したがって、データ渡し）を自動的にする。ＴＩＳＡでは、テスト・アクセス部分とアルゴリズム部分との間のハンドオフは、命令レベルで行われ、プロセッサが、関連するスケジューリング戦略に従って必要に応じてスキャンおよびアルゴリズムを自由に混合（すなわち、テスト動作およびアルゴリズム動作を自由に混合）できるようになっている。
ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡのこの例示的実施態様では、ベクトルを扱うすべての動作が、絶対アドレッシングを使用する（ＳＶＦ命令に関して上で説明したように）。その結果、テスティング・ベクトルを、ＩＳＡプログラムの内部の通常の変数のように使用することができ、これによって、テスト・アクセス部分とアルゴリズム部分との間のインターフェースを自動的にする。例として、上で説明したＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの例示的実施態様に基づいて、次のステップは、原型的なテスティング・シーケンスを例示するものである。
（１）ＳＤＲ命令が、テストされるシステムからテスティング出力データを入手するのに使用される。結果の出力データは、特定のメモリ位置に配置される（たとえば、ＧＥＮＥＲＩＣ２レジスタ内の「ａｃｔｕａｌ」パラメータ）
（２）古典的なＬＯＡＤ命令が、ロードされるべきこの出力データをレジスタに転送することができる
（３）出力データがレジスタにロードされた後に、算術演算および／または論理演算を使用して、出力データを処理することができる（ＳＰＡＲＣ Ｖ８ ＩＳＡはロード／ストア・アーキテクチャなので、すべてのデータが処理される前にレジスタにロードされなければならないことに留意されたい）
（４）古典的なＳＴＯＲＥ命令が、アルゴリズムの結果をメモリに転送するのに使用される
（５）ＳＤＲ命令が、新しいテスティング入力データをＴＡＰに送ることができる（たとえば、ＴＤＩレジスタ内の「ＴＤＩ」パラメータを使用して）
古典的なアルゴリズム動作（２）から（４）が、ＩＳＡアルゴリズム実施態様について標準的であり、いかなる形でもＴＩＳＡによって変更されないことに留意されたい。
したがって、この単純な例から、ＴＩＳＡを、アルゴリズム部分とテスト・アクセス部分との間の自然で効率的なハンドオフと共に、任意の所与のアルゴリズムまたはコンピュータ・プログラムを使用してサポートできることは、明白である。
ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡのこの例示的実施態様では、絶対アドレッシングが使用される（ＴＩＳＡを説明する際の明瞭さのために）が、本明細書の教示によって情報を与えられた当業者は、ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌに記載されたすべての正当なＳＰＡＲＣ Ｖ８アドレッシング・モードをサポートするためにＴＩＳＡのこの例示的実施態様を修正できるはずである。
本明細書で主にＳＶＦが使用されるＴＩＳＡの例示的実施態様に関して図示し、説明したが、ＳＶＦは、１１４９．１ ＴＡＰの、基本的であるとしても完全な処理を提供することがわかっている周知のフォーマットなので、この例示的実施形態で使用された。本明細書の教示によって情報を与えられた当業者は、ＴＩＳＡを任意の他の適切な制御フォーマットを使用して実施でき、それらの制御フォーマットの多くが、ＴＡＰ状態機械のより細粒度の制御を可能にし、より洗練されたテスティング動作をサポートすることができることを了解するであろう。
本明細書で主に抽象化レベルがベクトル・レベルであるＴＩＳＡの例示的実施態様に関して図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、図示され本明細書で説明される例示的ＴＩＳＡ実施態様を、ＴＩＳＡの抽象化レベルがＴＡＰレベルまたはスキャン・セグメント・レベルになるように変更できることを了解するであろう。
ＴＩＳＡを説明する際の明瞭さのために、例示的なテストされるシステムに対してテスティングを実行するためのＴＩＳＡの例示的使用を、図５および６に関して図示し、本明細書で説明する。ＴＩＳＡのこの例示的使用では、ＴＩＳＡは、ＳＰＡＲＣ Ｖ８ ＩＳＡおよびＳＶＦを使用するベクトル・レベルＴＩＳＡとして（すなわち、図４Ａ〜４Ｅに関して図示され、説明された例示的実施態様の継続で）実施される。
図５Ａおよび図５Ｂに、テストされるシステムに対してテスティングを実行するためのＴＩＳＡの例示的使用を示す。
図５Ａに、ＪＴＡＧ ＴＡＰ ５１０およびテストされるシステム５２０を含むシステム・テスト環境５００を示す。
ＪＴＡＧ ＴＡＰ ５１０は、テストされるシステム５２０へのテスト・アクセスを提供する。ＪＴＡＧ ＴＡＰ ５１０は、テストされるシステム５２０に入力データを送り、テストされるシステム５２０から出力データを受け取るために、テストされるシステム５２０へのテスト・アクセスを提供する。ＪＴＡＧ ＴＡＰ ５１０は、命令レジスタ（ＩＲ）５１２を含み、ＩＲ ５１２は、８ビット命令レジスタである。
ＪＴＡＧ ＴＡＰ ５１０は、テスティング・システム（たとえば、明瞭にするために省略されている、図３に関して図示し、説明したテスティング・システム１１０など）によって制御される。
テストされるシステム５２０は、第１基板５２１（Ｂ１と表される）および第２基板５２５（Ｂ２と表される）を含む。第１基板５２１は、送信器５２２（Ｔと表される）を含む。第２基板５２５は、受信器５２６（Ｒと表される）を含む。送信器５２２は、接続５２９上でデータを受信器５２６に送信する。この例では、接続５２９は、８ビット接続である。
図５Ａに示されているように、各基板は、それ自体のスキャン・チェーンを介してＪＴＡＧ ＴＡＰ ５１０からアクセス可能である。すなわち、第１基板５２１は、第１スキャン・チェーン５２３を介してアクセス可能であり、第２基板５２５は、第２スキャン・チェーン５２７を介してアクセス可能である。第１スキャン・チェーン５２３および第２スキャン・チェーン５２７は、ＪＴＡＧ ＴＡＰ ５１０のＩＲ ５１２によって選択可能である（たとえば、ＩＲ＝０は第１基板Ｂ１を選択し、ＩＲ＝１は第２基板Ｂ２を選択する）。送信器５２２および受信器５２６は、その基板上で単独であるのではなく、より広いスキャン・チェーン（たとえば、この例において、それぞれ２４ビットおよび１６ビット）の一部である。
テスト・プログラムでは、入力データが、第１スキャン・チェーン５２３を介して送信器５２２に送られ、結果の出力データが、第２スキャン・チェーン５２７を活用することによって受信器５２６から収集される。網羅的テストを実行するために、すべての可能な値が接続５２９を介して送信され、２８＝２５６個のベクトルが接続５２９を介して送信されるようになっている。Ｃを使用すると、例示的プログラムを、次とすることができる。
1 include <stdio.h>
2 include <jtag.h>
3
4 char sent_value, received value;
5
6 define MAX_COUNT 256;
7
8 void main(void)
9 {
10 for (sent_value=0;sent_value<MAX_COUNT;sent_ value++)
11 {
12 apply_JTAG(sent_value,B1.T);
13 read_JTAG (received_value,B2.R);
14 if (sent_value != received value) exit (0);
15 }
16 exit(1);
17 }
このプログラムでは、行２は、ＪＴＡＧ動作を処理しているＣモジュールを含み、このＣモジュールでは、それぞれ行１２および１３で使用される関数「ａｐｐｌｙ＿ＪＴＡＧ」および「Ｒｅａｄ＿ＪＴＡＧ」が定義される。ＳＣ ３２０のプリコンパイラ３３０は、これらの関数を認識し、ＴＧＴ ３１０用のテスト動作記述ファイル３３１を生成する。テスト動作記述ファイル３３１のフォーマットは、第１基板５２１および第２基板５２５の実際の実施態様に依存して変化する可能性がある。たとえば、第１基板５２１と第２基板５２５との両方がＩＪＴＡＧ準拠である場合には、テスト動作記述ファイル３３１を、たとえばＮＳＤＬ（Ｎｅｗ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）コードを使用して指定することができる。ＴＧＴ ３１０は、テスト動作記述ファイル３３１を使用して、ＴＧＴ不可分テスト動作３１６を生成し、このＴＧＴ不可分テスト動作３１６は、ＴＩＳＡトランスレータ３４０によってＴＩＳＡ不可分テスト動作３４６に変換される。ＴＩＳＡ不可分テスト動作３４６は、ＳＣ ３２０のフロントエンド３２４に供給される。ＴＧＴ不可分テスト動作３１６、関連するＴＩＳＡ不可分テスト動作３４６、および結果のＴＩＳＡ２進コードが、図５Ｂに示されている。
図５Ｂに、図５Ａのシステム・テスト環境５００のテスティングを実行するテスティング・システムによる使用のためのＣコマンドからＴＩＳＡコーディングへのマッピングを示す。
図５Ｂに示されているように、ＣコマンドからＴＩＳＡコーディングへのマッピングは、４つの列すなわち「Ｃコマンド」列５４１、「ＳＶＦ命令」列５４２、「ＴＩＳＡアセンブラ」列５４３、および「ＴＩＳＡコーディング」列５４４を有するテーブル５４０を使用して表される。テーブル５４０は、左から右へ、ＣコマンドをＳＶＦ命令に変換できる形を示し、このＳＶＦ命令をＴＩＳＡアセンブラに変換することができ、このＴＩＳＡアセンブラをＴＩＳＡ２進コーディングにコーディングすることができる。
Ａｐｐｌｙ＿ＪＴＡＧ（ｖａｌｕｅ，Ｂ１．Ｔ）コマンドは、２つのＳＶＦ命令すなわちＳＩＲ ８ ＴＤＩ（００）およびＳＤＲ ２４ ＴＤＩ（ｖａｌｕｅ）に変換される。
ＳＩＲ ８ ＴＤＩ（００） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
SET 8, %cGENERIC1
SET 00, %cTDI
SIR TDI, １２０１００００としてＴＩＳＡコーディングに変換される
ＳＤＲ ２４ ＴＤＩ（ｖａｌｕｅ） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
SET 24, %cGENERIC1
SET value, %cTDI
SDR TDI, １００１００００としてＴＩＳＡコーディングに変換される
Ｒｅａｄ＿ＪＴＡＧ（ｖａｌｕｅ，Ｂ２．Ｒ）コマンドは、２つのＳＶＦ命令すなわちＳＩＲ ８ ＴＤＩ（０１）およびＳＤＲ １６ ＡＣＴＵＡＬ（ｖａｌｕｅ）に変換される。
ＳＩＲ ８ ＴＤＩ（０１） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
SET 8, %cGENERIC1
SET 01, %cTDI
SIR TDI, １２０１００００としてＴＩＳＡコーディングに変換される
ＳＤＲ １６ ＡＣＴＵＡＬ（ｖａｌｕｅ） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
SET 16, %cGENERIC1
SET “value”，%cGENERIC2
SDR ACTUAL, １０００８０００としてＴＩＳＡコーディングに変換される
ＳＥＴ動作のＴＩＳＡコーディングは、指定されない。というのは、ＳＰＡＲＣ Ｖ８ Ｍａｎｕａｌが、これらを、プロセッサの実施態様に従って異なるコーディングを有することができる「擬似命令」として識別するからである。
決定されたＴＩＳＡコーディングを使用して、プリコンパイラ３３０は、今や、高水準ＪＴＡＧアクセスをそれに関連するＴＩＳＡアセンブラ命令に置換することができる。その結果が、Ｃを使用して指定された次のコードであり、このコードでは、ＪＴＡＧ ＴＡＰへの呼出しが、関連するＴＩＳＡアセンブラ・コーディングによって置換されている。
1 include <stdio.h>
2 include <jtag.h>
3
4 char sent_value, received value;
5
6 define MAX_COUNT 256;
7
8 void main(void)
9 {
10 for (sent_value=0;Sent_value<MAX_COUNT;sent_value++)
11 {
12 asm volatile ("SET 8, %cGENERIC1;
13 SET 00, %cTDI;
14 SIR TDI;
15 SET 24, %cGENERIC1;
16 SET &sent_value, %cTDI;
17 SDR TDI;");
18 asm volatile ("SET 8, %cGENERIC1;
19 SET 01, %cTDI;
20 SIR TDI;
21 SET 16, %cGENERIC1;
22 SET &received_value, %cGENERIC2;
23 SDR ACTUAL");
24 if (sent_value != received value) exit (0);
25 }
26 exit(1);
27 }
このコードを、フロントエンド・アルゴリズム３２２に入力することができ、フロントエンド・アルゴリズム３２２は、プログラム・モデル３２３を生成する。プログラム・モデル３２３を、バックエンド・アルゴリズム３２４に入力することができ、バックエンド・アルゴリズム３２４は、ＴＩＳＡ不可分動作３５６を含む実行可能ＴＩＳＡ２進ファイル（１つまたは複数）３５５を生成する。
テーブル５４０の「ＴＩＳＡコーディング」列５４４は、ＴＩＳＡアセンブラ命令の２進コーディングを示す（たとえば、図４Ａ〜４Ｅに関して図示し、説明したようにＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの例示的実施態様に関して定義されるさまざまなルールを使用して）。
本明細書で説明するように、ＴＩＳＡは、テストされるシステムのテスティングを実行する際のテスト粒度に関して完全な自由を提供する（すなわち、ＴＡＰレベルからスキャン・セグメント・レベルまで）。図２および図３に示され、図４Ａ〜４Ｅおよび図５Ａ〜５Ｂの例示的ＴＩＳＡ実施態様を使用してさらに説明されるように、テスト・パターンを、テスト生成ツールに対するソフトウェア・コンパイラによる明示的照会を使用して計算することができ、ソフトウェア・アルゴリズムに関する唯一の制限は、照会自体の解決である。
例として、粗なレベルで、ＳＣからＴＧＴへの照会は、テストされるシステムのスキャン・チェーン全体を含むことができる（たとえば、古典的なＢＳＤＬベースのバウンダリ・スキャン・テスティングの場合など）。
例として、微細なレベルで、ＳＣからＴＧＴへの照会は、レジスタまたはビットさえも含むことができる。たとえば、専用スキャン・セグメント・プリミティブは、機器アクセスおよびＴＡＰ再構成を大幅に加速し、コード再利用を増やし、さまざまな他の利益を提供することができる。
例として、粗なレベルと微細なレベルとの間の中間レベルでは、ＳＣからＴＧＴへの照会を、関数的に行うことができる（たとえば、ＩＪＴＡＧおよび他の適切な標準規格などの標準規格を使用し、ＮＳＤＬおよび他の適切なオブジェクト指向記述言語などの記述言語を使用して）。
この形で、ＴＩＳＡは、デバイス／レジスタ・アクセスがモデル空間で（すなわち、ＴＧＴ内で）解決されることを強制するのではなく、開発者がデバイス／レジスタ・アクセスをプログラム空間で（すなわち、ＳＣ内で）処理することを可能にし、これによって、開発者が分析粒度を彼らの必要および使用可能なリソースに適合させることを可能にする。
さらに、ＴＩＳＡプロセッサが、たとえばＡＴＥ（Ａｕｔｏｍａｔｅｄ Ｔｅｓｔ Ｅｑｕｉｐｍｅｎｔ）の場合など、十分なリソースを有する実施形態では、回路モデルの少なくとも一部を、プログラム・モデル内で実施することができ、これによって、ＴＩＳＡマシンがベクトル・パターンを直接に計算することが可能になる。
さらに、ＴＩＳＡは、対話デバッギング（ローカルにおよび／またはリモートに）を含む対話テスティング、並列性、ポータビリティ、および類似物、ならびにそのさまざまな組合せなど、ＴＩＳＡなしでは以前に可能でなかったさまざまな他のシステム・テスト機能をサポートすることを可能にする。これらの追加機能に、これからさらに詳細に対処する。
図６に、対話テスティング機能をサポートするＴＩＳＡベースのテスティング環境の実施形態を示す。
図６に示されているように、ＴＩＳＡベースのテスティング環境６００は、ホスト・コンピュータ（ＨＣ）６０１、テスティング・システム（ＴＳ）６１０、およびテストされるシステム（ＳＵＴ）６２０を含む。
ＨＣ ６０１は、ＳＵＴ ６２０のテスティングを制御するためにＴＳ ６１０を制御するように構成される。ＨＣ ６０１は、メモリ６０４に結合されたプロセッサ６０２を含む。プロセッサ６０２およびメモリ６０４は、任意の適切なプロセッサおよびメモリとすることができる。
メモリ６０４は、１つまたは複数のデバッガ制御プログラム６０５を格納する。デバッガ制御プログラム（１つまたは複数）は、ＨＣ ６０１がＴＳ ６１０上で実行するコンピュータ・プログラム（１つまたは複数）の実行をトレースし、望まれるか必要な場合にこれを変更することを可能にする。たとえば、デバッガ制御プログラム（１つまたは複数）６０５は、ＧＮＵ Ｄｅｂｕｇｇｅｒ（ＧＤＢ）、ｄｂｘデバッガ、Ｐｅｒｌデバッガ、Ｂａｓｈデバッガ、Ｐｙｔｈｏｎデバッガ、および同様の適切なデバッガ・プログラム、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
メモリ６０４は、１つまたは複数のデバッガ表示プログラム６０６をも格納することができる。デバッガ表示プログラム（１つまたは複数）は、ＨＣ ６０１がデバッガ制御プログラム（１つまたは複数）６０５に関連する情報を表示することを可能にする。デバッガ制御プログラム（１つまたは複数）６０５に関連する情報を、デバッガ表示プログラム（１つまたは複数）６０６によって任意の適切な形で（たとえば、１つまたは複数のディスプレイ・デバイスを使用して）表示することができる。たとえば、デバッガ表示プログラム（１つまたは複数）６０６は、Ｉｎｓｉｇｈｔ（ＧＤＢへのグラフィカル・ユーザ・インターフェースである）、Ｄａｔａ Ｄｉｓｐｌａｙ Ｄｅｂｕｇｇｅｒ（ＤＤＤ、ＧＤＢおよび他のデバッガなどのさまざまなコマンドライン・デバッガのグラフィカル・ユーザ・インターフェースを提供する）、および同様の適切なデバッガ表示プログラム、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
ＴＳ ６１０は、ＳＵＴ ６２０をテストするためにＨＣ ６０１によって制御される。ＴＳ ６１０は、ＴＩＳＡと一貫する形で（たとえば、図１〜図３のＴＳ １１０に関して図示し、説明したものなど）機能するように構成され、さらに、対話テスティングをサポートする（たとえば、ＨＣ ６０１上で実行するデバッガによるアクセスを使用可能にすることによって）ように構成される。
ＴＳ ６１０は、メモリ６１４に結合されたＴＩＳＡプロセッサ６１２を含む。ＴＩＳＡプロセッサ６１２は、ＳＰＡＲＣ Ｖ８（図４Ａ〜４Ｅおよび図５に関して図示し、上で説明した）、ＩＮＴＥＬ、および類似物などの任意の適切なプロセッサを使用して実施することができる。メモリ６０４は、任意の適切なメモリとすることができる。
メモリ６１４は、１つまたは複数のデバッガ・プログラム・スタブ６１５を格納する。デバッガ・プログラム・スタブ６１５は、ＨＣ ６０１上で実行する対応するデバッガ制御プログラム（１つまたは複数）６０５のデバッガ・プロトコルを理解し、これによって、ＨＣ ６０１がＴＳ ６１０と通信することを可能にする。たとえば、デバッガ・スタブ（１つまたは複数）６１５は、ＧＤＢスタブ、ＤＢＸスタブ、Ｐｅｒｌスタブ、Ｂａｓｈスタブ、Ｐｙｔｈｏｎスタブ、および同様の適切なデバッガ・プログラム・スタブ、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
メモリ６１４は、ＴＩＳＡ２進ファイル６１６を格納する。ＴＩＳＡ２進ファイル６１６は、本明細書で図２および図３に関して図示し、説明した形でＴＳ ６１０によって生成される。ＴＩＳＡ２進ファイル６１６は、ＳＵＴ ６２０に対するテスティングを実行するためにＴＩＳＡプロセッサ６１２によって実行される。
ＴＳ ６１０は、ＴＩＳＡプロセッサ６１２に結合されたテスト・アクセス・ポート（ＴＡＰ）６１８をも含む。ＴＡＰ ６１８は、ＨＣ ６０１によって制御されている間にＴＩＳＡプロセッサ６１２がＳＵＴ ６２０のテスティングを実行することを可能にするために、ＴＩＳＡプロセッサ６１２とＳＵＴ ６２０との間のテスト・インターフェースを提供する。ＴＡＰ ６１８は、任意の適切なＴＡＰ（たとえば、１１４９．１ ＴＡＰ）とすることができる。
ＴＩＳＡプロセッサ６１２は、インターフェース６１７を使用してＴＡＰ ６１８とインターフェースする。インターフェース６１７は、ＴＡＰとテストされるシステムとの間の任意の適切なインターフェース（たとえば、ＴＣＫ、ＴＭＳ、ＴＤＩ、ＴＤＯ、およびオプションでＴＲＳＴ（ＴＡＰ ６１８が１１４９．１ ＴＡＰとして実施される場合）をサポートするインターフェースなど）とすることができる。
図６に示されているように、ＨＣ ６０１とＴＳ ６１０との間にインターフェース６０９がある。インターフェース６０９は、ＨＣ ６０１とＴＳ ６１０との間のローカル通信および／またはリモート通信をサポートすることができる。したがって、ＨＣ ６０１は、ローカルにおよび／またはリモートにＴＳ ６１０を介してＳＵＴ ６２０の対話テスティングを制御することができる
たとえば、ローカル・テスティングに関して、インターフェース６０９を、汎用非同期送受信回路（ＵＡＲＴ）インターフェース、直列インターフェース、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数として実施することができる。
たとえば、リモート・テスティングに関して、インターフェース６０９を、伝送制御プロトコル（ＴＣＰ）／インターネット・プロトコル（ＩＰ）または任意の他の適切な通信プロトコルなどの任意の適切な通信機能を使用して実施することができる。これは、ＨＣ ６０１およびＴＳ ６１０が長い地理的距離だけ分離される可能性があり、それでもＨＣ ６０１がＳＵＴ ６２０のテスティングを実行するためにＴＳ ６１０を制御することができる、リモート・テスティングを可能にする。
ＴＩＳＡベースのテスティング環境６００では、ＨＣ ６０１は、標準的な接続（たとえば、ＵＡＲＴ、ＴＣＰ／ＩＰ、および類似物）を介してＴＳ ６１０の動作を制御することによってＳＵＴ ６２０のテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。
明瞭にするために省略されてはいるが、ＨＣ ６０１およびＴＳ ６１０が、追加のプロセッサ、追加のメモリ、内部通信バス、入出力モジュール、追加のサポート回路（たとえば、電源）、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のコンポーネントを含むことができることを了解されたい。
明瞭にするために省略されてはいるが、ＳＵＴ ６２０を、ＴＩＳＡを使用してテストできる任意のテストされるシステムとすることができることを了解されたい。
主に特定のタイプのデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物に関して図示し、説明したが、ＴＩＳＡベースのテスティング環境６００を、さまざまな他のデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物、ならびにそのさまざまな組合せを使用して完全に対話的なテスティング機能を使用可能にする形で実施できることを了解されたい。
図７に、図６のＴＩＳＡベースのテスティング環境の例示的実施態様を示す。
図７に示されているように、図７の例示的なＴＩＳＡベースのテスティング環境７００は、ＧＮＵツール・スイートが図５Ａの例示的なシステム・テスト環境５００の対話テスティングをサポートするのに使用される、図６のＴＩＳＡベースのテスティング環境６００の実施態様である。
図７に示されているように、例示的なＴＩＳＡベースのテスティング環境７００は、ホスト・コンピュータ（ＨＣ）７０１、テスティング・システム（ＴＳ）７１０、およびテストされるシステム（ＳＵＴ）７２０を含む。
ＨＣ ７０１は、プロセッサ７０２およびメモリ７０４を含む。図７のＨＣ ７０１は、デバッガ制御プログラム（１つまたは複数）６０５がＧＤＢ（ＧＤＢ ７０５）を使用して実施され、デバッガ表示プログラム（１つまたは複数）６０６がＤＤＤ（ＤＤＤ ７０６）を使用して実施される、図６のＨＣ ６０１の実施態様である。
ＴＳ ７１０は、ＴＩＳＡプロセッサ７１２およびメモリ７１４を含む。図７のＴＳ ７１０は、ＴＩＳＡプロセッサ６１２がＳＰＡＲＣ Ｖ８ ＩＳＡを使用して実施され（ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２と表される）、デバッガ・プログラム・スタブ（１つまたは複数）６１５がＧＤＢスタブ（ＧＤＢスタブ７１５）を使用して実施され、ＴＩＳＡ２進ファイル６１６がＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２に関連するＳＰＡＲＣ Ｖ８ ＩＳＡに基づいて生成される（ＴＩＳＡ２進ファイル７１６）、図６のＴＳ ６１０の実施態様である。
ＴＳ ７１０は、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２に結合されたテスト・アクセス・ポート（ＴＡＰ）７１８をも含む。図７のＴＳ ７１０は、ＴＡＰ ６１８が１１４９．１ ＴＡＰ（１１４９．１ ＴＡＰ ７１８）を使用して実施される、図６のＴＳ ６１０の実施態様である。
ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２は、インターフェース７１７を使用して１１４９．１ ＴＡＰ ７１８とインターフェースする。インターフェース７１７は、ＴＣＫ、ＴＭＳ、ＴＤＩ、ＴＤＯ、およびオプションでＴＲＳＴをサポートする標準１１４９．１インターフェースである。
ＳＵＴ ７２０は、図５ＡのＳＵＴ ５２０である。ＳＵＴ ７２０は、図５ＡのＳＵＴ ５２０のように、異なる基板上の送信器および受信器を含む。
１１４９．１ ＴＡＰ ７１８は、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２がＨＣ ７０１によって制御されている間にＳＵＴ ７２０のテスティングを実行することを可能にするために、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２とＳＵＴ ７２０との間のテスト・インターフェースを提供する。
図７に示されているように、ＨＣ ７０１とＴＳ ７１０との間にインターフェース７０９がある。インターフェース７０９は、ＨＣ ７０１とＴＳ ７１０との間のローカル通信および／またはリモート通信（たとえば、ネットワークを介する）をサポートすることができる。したがって、ＨＣ ７０１は、ローカルにおよび／またはリモートにＴＳ ７１０を介してＳＵＴ ７２０の対話テスティングを制御することができる。
例示的なＴＩＳＡベースのテスティング環境７００では、ＨＣ ７０１は、インターフェース７０９を介してＴＳ ７１０の動作を制御することによってＳＵＴ ７２０に対するテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。
図７の左側のほとんどが、既存のコンピュータ・サイエンス要素すなわちＨＣ ７０１全体ならびにＴＳ ７１０上のＧＤＢスタブ７１５を再利用することを了解されたい。これは、図７の中央部分についても同一であり、中央部分では、ＨＣ ７０１とＴＳ ７１０（ならびにそれらに関連する副要素）との間の類似が明白である。ＴＩＳＡは、システム・テスティングを提供するためにこのインフラストラクチャ全体を活用することを可能にする。
例として、図５Ａのシステム・テスト環境５００（関連する例示的なＣプログラム、ＳＶＦ命令、ＴＩＳＡアセンブラ命令、およびＴＩＳＡコーディングを含む）を参照すると、（ａ）変数「ｓｅｎｔ＿ｖａｌｕｅ」および「ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ」を監視している間のステップごとの実行、（ｂ）ｔａｐに送るべき値（変数「ｓｅｎｔ＿ｖａｌｕｅ」）のオンザフライ変更、（ｃ）ループ終了条件の変更、（ｄ）すべての変数の監視、および類似物、ならびにそのさまざまな組合せなど、ＧＤＢ（または任意の他の適切なデバッガ）を活用することによってＴＩＳＡが使用可能にすることのできる多数の対話テスト動作がある。これらの対話テスト動作は、ＧＤＢの標準動作であり、ＴＩＳＡは、上で説明したアルゴリズム部分とテスト・アクセス部分との間の制御を自動的にハンドオフするＴＩＳＡの能力に起因して、これらを直接に使用することができる。ＴＩＳＡがない場合には、特殊なツーリングを開発し、各ハンドオフ実施態様に適合させる必要があるはずである。
図７の例示的なＴＩＳＡベースのテスティング環境７００を、主に、特定のテストされるシステムの対話テスティングをサポートするのにＧＮＵツール・スイートを使用することに関して本明細書で図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、ＴＩＳＡベースのテスト環境での対話テスティング機能を、任意のタイプのテストされるシステムをテストするために任意の適切なツール・スイートを使用して実現できることを了解するであろう。
図６のＴＩＳＡベースのテスティング環境６００および図７の例示的なＴＩＳＡベースのテスティング環境７００を、主に、テスティングが事前に決定されたアルゴリズムに従ってステップごとに行われる直線的なテスト手順に関して本明細書で図示し、説明したが（ＴＩＳＡによって使用可能にされる対話テスティング機能を説明する際の明瞭さのために）、ＴＩＳＡによって使用可能にされるコンピュータ・サイエンス経験およびコンピュータ・サイエンス技法の活用に起因して、他のより複雑な対話テスティング・シナリオが可能であることを了解されたい。ＴＩＳＡによって使用可能にされるより複雑な対話テスティング・シナリオの例を、図８に関して図示し、本明細書で説明する。これが、単に１つの例であり、本明細書の教示によって情報を与えられた当業者が多数の他の対話テスティング・シナリオおよび対話テスティング応用例でＴＩＳＡを使用できることを了解されたい。
本明細書で説明されるように、粒度と対話との両方をサポートすることに加えて、ＴＩＳＡは、並列性をもサポートする。
ＴＩＳＡは、システム・テスティング・フローをコンピュータ・サイエンス・ソフトウェア・フローと自然に十分に合併し、したがって、両方のフローの最良の態様を活用することができる。例として、ＳＴＡＰＬなどの手法は、定義により、完全に順次的なので、機器の並列制御を扱うのが困難である。さらに、ＭＴＣおよびＳｙｓｔｅｍＢＩＳＴなどの手法は、本質的に順次的であり、シングルタスクであり、したがって、並列性をサポートするためにそのような手法をプログラムすることは、むずかしく、不便であるはずである。対照的に、並列実行は、コンピュータ・サイエンスでは周知の問題であり、現在は、たとえば、すべてのオペレーティング・システムの根底にある。並列実行をサポートする大量のライブラリが使用可能であり（たとえば、ＰＯＳＩＸスイート、ＢＯＯＳＴスイート、および類似物）、ほとんどの現代のプロセッサは、マルチタスキングおよびコンテキスト切替を効率的にサポートするように設計されている（たとえば、たとえばＳＰＡＲＣ Ｖ８は、回転するレジスタ・ウィンドウを実装する）。ＴＩＳＡによって使用可能にされるシステム・テスティング・フローとコンピュータ・サイエンス・ソフトウェア・フローとの間の自然な相互作用は、ＴＩＳＡが並列性に対するそのようなコンピュータ・サイエンス手法を完全に活用することを可能にする。
ＴＩＳＡによる並列性機能のサポートは、例によってよりよく理解することができる。例として、図５Ａおよび図７のテストされるシステム５２０の送信器５２２と受信器５２６との間のＴ−Ｒチャネルのデータ転送速度を最適化するという問題を検討されたい。これは、第１基板５２１上の送信器５２２からデータ・パターンのストリームを送信することと、第２基板５２５上の受信器５２６でデータ・パターンの対応するストリームを受信することと、ビット速度／誤り率を計算し、それ相応に送信器５２２および／または受信器５２６のパラメータを調整するためにデータ・パターンの送信されたストリームおよび受信されたストリームを比較することとを含むはずである。この最適化を、並列に動作する３つのプログラムを使用して効率的に実行することができる。
図８に、図５Ａおよび図７のテストされるシステムの送信器−受信器チャネルの最適化を実行するための例示的プログラム・アーキテクチャを示す。
図８に示されているように、例示的なプログラム・アーキテクチャは、パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６を含む。パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６は、協力して、図５Ａおよび図７のテストされるシステム５２０の送信器５２２と受信器５２６との間のＴ−Ｒチャネルのデータ転送速度を最適化する。
パターン・ジェネレータ８０２は、適切な入力データ・パターンを第１基板５２１上の送信器５２２（Ｔ）に送る。パターン・ジェネレータ８０２は、第１基板５２１（Ｂ１）のスキャン・チェーン５２３を介して送信器５２２に入力データ・パターンを供給するために、ＴＡＰ（実例として、図５ＡのＴＡＰ ５１０、図７のＴＡＰ ７１８）にアクセスすることができる。パターン・ジェネレータ８０２は、任意の適切な形で（たとえば、図５Ａに関して本明細書で説明したコードの行１２〜１３で指定されるように）送信器５２２に入力データ・パターンを供給することができる。入力データ・パターンは、送信器５２２と受信器５２６との間のＴ−Ｒチャネルを最適化するのに適する任意のデータ・パターンとすることができる。たとえば、入力データ・パターンを、事前に計算されたパターン、ランダム・パターン、および類似物、ならびにそのさまざまな組合せとすることができる。
パターン・レシーバ８０４は、第２基板５２５上の受信器５２６（Ｒ）から適切な出力データ・パターンを収集する。パターン・レシーバ８０４は、第２基板５２５（Ｂ２）のスキャン・チェーン５２７を介して受信器５２６から出力データ・パターンを収集するために、ＴＡＰ（実例として、図５ＡのＴＡＰ ５１０、図７のＴＡＰ ７１８）にアクセスすることができる。パターン・レシーバ８０４は、任意の適切な形で（たとえば、図５Ａに関して本明細書で説明したコードの行１４〜１５で指定されるように）受信器５２６から出力データ・パターンを収集することができる。
コンパレータ８０６は、パターン・ジェネレータ８０２およびパターン・レシーバ８０４と通信する。コンパレータは、入力データ・パターンと出力データ・パターンとを比較する。コンパレータ８０６は、Ｔ−Ｒチャネルのビット伝送速度およびビット誤り率を評価し、この比較の結果に基づいて、Ｔ−Ｒチャネルのパラメータを最適化するために送信器５２２と受信器５２６との両方の制御レジスタ（明瞭にするために図５Ａおよび図７では省略されている）にアクセスすることができる。
そのような最適化テスティング手順を実行するために、パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６は、並列に働く必要があり、それぞれが、他とは独立にＴＡＰにアクセスできなければならない。このタイプの制御構造は、ＴＡＰを介する１点直列ハンドオフ制御だけをサポートするように開発された伝統的な環境では、コーディングするのが非常にむずかしい。このタイプの制御構造は、やはり同一の直列ＴＡＰアクセス・パラダイムを共有するＭＴＣまたは他のそのような手法を使用する環境でも、コーディングするのが非常にむずかしい。対照的に、ＴＩＳＡは、テスト・アクセスに関するそのようないかなる仮定をも伴って設計されているのではなく、ＴＩＳＡでは、テスト・アクセスが、他のプロセッサ・リソースに似た形で処理され、テスト・アクセス命令は、古典的なＩＳＡ命令と直接に混合される。ＴＩＳＡを使用すると、図８の最適化テスティング手順を、プロセス、スレッド、プロセス間通信（ＩＰＣ）、および類似物、ならびにそのさまざまな組合せなどの標準的構造を使用する任意のマルチタスキング・オペレーティング・システムによって実行することができる。この形で、パターン・ジェネレータ８０２、パターン・レシーバ８０４、およびコンパレータ８０６は、ＴＡＰへのアクセスを共有することができ、たとえば、たとえばダイクストラのセマフォなどの周知の構造およびアルゴリズムを使用して、すべてのプロセッサ・リソースについて行われるのと同様に、すべての最終的なＴＡＰ共有問題を解決することができる。したがって、既存のシステム・テスティング機能は並列性をサポートしないが、ＴＩＳＡが簡単に完全に並列性をサポートすることは明白である。
上で説明したように、ＴＩＳＡは、テスト・アクセス方法または関連するテスト・プログラム区分に関する仮定を一切設けず、テスト命令は、テスト命令と古典的ＩＳＡ命令との間の先見的分離を全く伴わずに、古典的ＩＳＡ命令と同一の形または実質的に同一の形で扱われる。これは、ＴＩＳＡをすべての既存の（および最もありそうなことに将来の）コンピュータ・サイエンス・アルゴリズムおよびコンピュータ・サイエンス構造と完全に互換することを可能にし、これは、既存のテスト・プロセッサ手法がサポートできないことである。
したがって、すべての既存ソフトウェア・ライブラリをＴＩＳＡアーキテクチャに移植できることを了解されたい。たとえば、ＰＯＳＩＸスイートおよびＢＯＯＳＴスイートを活用することによって、マルチタスキングおよび並列性を入手することは、簡単であるはずである（たとえば、図８に関して本明細書で図示し、説明したように）。さらに、ＴＩＳＡが既存ＩＳＡの一般化として入手される（たとえば、図５Ａおよび図５Ｂに関して図示し、説明した例示的なＳＰＡＲＣ Ｖ８ ＴＩＳＡ実施態様に関して図示し、説明したように）場合には、ＴＩＳＡがそれから開発されたＩＳＡが既にそのようなソフトウェア・ライブラリを含むので、移植が必要でない場合さえあることを了解されたい。
さらに、さまざまな他のコンピュータ・サイエンス技法を、ＴＩＳＡを使用する改善されたシステム・テスティングを提供するために利用できることを了解されたい。たとえば、ＴＩＳＡのために活用できるそのようなコンピュータ・サイエンス技法のいくつかの例は、（ａ）プラットフォーム独立コーディング・スタイルの使用、（ｂ）ＩＳＡ対ＩＳＡコンバータの使用、（ｃ）プラットフォーム独立バイトコードを入手するための、たとえばＪａｖａのような、仮想マシン手法の使用、またはＴＩＳＡになるためのＪａｖａ仮想マシン自体の拡張、および（ｄ）その後に適切なドライバによってプリミティブに変換される、いくつかのＴＩＳＡソフトウェア・インターフェースを標準化するためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）の使用を含む。これらの例が、単にＴＩＳＡのために活用できるコンピュータ・サイエンス技法の少数の例であることを了解されたい。
図９に、テストされるシステムの少なくとも一部をテストする際のプロセッサによる使用のために適合されたテスト命令セット・アーキテクチャ（ＴＩＳＡ）命令を含むＴＩＳＡフローを形成するためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法の一実施形態を示す。
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法９００のステップの少なくとも一部を、同時にまたは図９に関して図示され説明されるものとは異なる順序で実行することができる。
ステップ９０２では、方法９００が開始される。
ステップ９０４では、命令の第１セットを生成する。命令の第１セットは、プロセッサによってサポートされるＩＳＡ命令を含む（すなわち、プロセッサにＴＩＳＡを提供するために活用されているＩＳＡ命令）。
ステップ９０６では、命令の第２セットを生成する。命令の第２セットは、テストされるシステムに関連するテスト命令を含む。命令の第２セットは、たとえば図２のＴＧＴ ２１０に関して図示し、説明したように、図３のＴＧＴ ３１０に関して図示し、説明したように、および／またはテスト命令を生成する任意の他の適切な方法を使用して、任意の適切な形で生成することができる。
ステップ９０８では、命令の第１セットおよび命令の第２セットを統合して、これによってＴＩＳＡ命令を形成する。ＴＩＳＡ命令は、プロセッサにＴＩＳＡを提供する。
ステップ９１０では、ＴＩＳＡ命令を格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。ＴＩＳＡ命令を、任意の他の適切な形で処理することができる。
ステップ９１２では、方法９００が終了する。
ＴＩＳＡを、任意の適切な形で、たとえば、図１０の方法１０００に関して図示し、説明するように、図２のテスト・システムおよび図１１Ａの関連する方法１１１０に関して図示し、説明するように、図３のテスト・システムおよび図１１Ｂの関連する方法１１２０に関して図示し、説明するように、ならびに／またはＴＩＳＡを形成する任意の適切な方法を使用して、形成することができる。
図１０に、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法１０００のステップの少なくとも一部を、同時にまたは図１０に関して図示され説明されるものとは異なる順序で実行することができる。ステップ１００２で、方法１０００が開始される。
ステップ１００４では、命令の第１セットを生成する。命令の第１セットは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成される命令（たとえば、プロセッサによってサポートされるＩＳＡのＩＳＡ命令）を含む。
ステップ１００６では、命令の第２セットを生成する。命令の第２セットは、テストされるシステムに関連する少なくとも１つの記述ファイルをコンパイルすることによって生成されるテスト命令を含む。
ステップ１００８では、命令の第１セットおよび第２セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第１セットの命令が、命令の第２セットのテスト命令の実行を制御する際の使用のために適合される。
ステップ１０１０では、命令の組み合わされたセットを格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ１０１２で、方法１０００は終了する。
図１１Ａおよび図１１Ｂに、図９に関して図示し、説明した方法９００および／または図１０に関して図示し、説明した方法１０００のより詳細な実施形態を示す。
図１１Ａに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に特定のシーケンスで実行されるものとして図示され、説明されるが、図１１Ａの方法１１１０のステップの少なくとも一部を、図１１Ａに関して図示し、説明するものとは異なる順序で実行することができる。図１１Ａを、図２および図２に関連する説明と共に見ることによってよりよく理解することができる。
ステップ１１１１で、方法１０００が開始される。
ステップ１１１２では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成され（たとえば、プロセッサによってサポートされるＩＳＡのＩＳＡ命令）、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルは、少なくとも１つの呼出しを含む。
ステップ１１１３では、命令の第１セットを生成する。命令の第１セットは、プログラム・モデルを使用して生成される。少なくとも１つの計算要求も、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルに含まれる少なくとも１つの呼出しを使用して生成される。
ステップ１１１４では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも１つのシステム記述ファイルをコンパイルすることによって生成される。
ステップ１１１５では、命令の第２セットを生成する。命令の第２セットは、回路モデルおよび少なくとも１つの計算要求を使用して生成される。
ステップ１１１６では、命令の第１セットおよび第２セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第１セットの命令が、命令の第２セットのテスト命令の実行を制御する際の使用のために適合される。
ステップ１１１７では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ１１１８では、方法１０００が終了する。図１１Ｂに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に順次実行されるものとして図示され、説明されるが、図１１Ｂの方法１１２０のステップの少なくとも一部を、同時にまたは図１１Ｂに関して図示し、説明するものとは異なる順序で実行することができる。図１１Ｂを、図３および図３に関連する説明と共に見ることによってよりよく理解することができる。
ステップ１１２１で、方法１１００が開始される。
ステップ１１２２では、少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよび少なくとも１つのテスト動作記述ファイルを、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルを前処理することによって生成する。
ステップ１１２３では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも１つのシステム記述ファイルおよび少なくとも１つのテスト動作記述ファイルをコンパイルすることによって生成される。
ステップ１１２４では、テスト動作のセットを生成する。テスト動作のセットは、回路モデルを使用して生成される。テスト動作のセットからのテスト動作は、テスト・プリミティブ（たとえば、回路モデルを生成するテスト生成ツールによって定義されるテスト・プリミティブ）のセットを使用して記述される。テスト・プリミティブのセットは、テストされるシステムをテストする際の使用のために適合されたテスト動作を含む。
ステップ１１２５では、テスト動作のセットのテスト・プリミティブを命令セット・アーキテクチャのソフトウェア命令と組み合わせての使用のために適合されたテスト命令に変換することによって、テスト動作のセットをテスト命令のセットに変換する。
ステップ１１２６では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよびテスト命令のセットをコンパイルすることによって生成される。
ステップ１１２７では、命令の組み合わされたセットを生成する。命令の組み合わされたセットは、プログラム・モデルを使用して生成される。命令の組み合わされたセットは、（ａ）少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルから決定されたソフトウェア命令および（ｂ）テスト命令のセットからのテスト命令を含む。
ステップ１１２８では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ１１２９では、方法１１２０が終了する。
図１２に、ＴＩＳＡプロセッサ・アーキテクチャの例示的実施形態を示す。
図１２に示されているように、ＴＩＳＡプロセッサ・アーキテクチャ１２００は、ＴＩＳＡプロセッサ１２１０およびメモリ１２２０を含む。
ＴＩＳＡプロセッサ１２１０は、ＳＰＡＲＣ Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、ＴＩＳＡを使用するシステム・テスティングを実行するのに適する任意のプロセッサとすることができる。
メモリ１２２０は、ランダム・アクセス・メモリ、永続メモリ、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数を含む、ＴＩＳＡを使用するシステム・テスティングをサポートするためのＴＩＳＡプロセッサ１２１０による使用に適する任意のメモリを含むことができる。メモリ１２２０は、テスト・プログラム、ＴＩＳＡ命令、テスティング・データ、および類似物、ならびにそのさまざまな組合せなど、ＴＩＳＡを使用するシステム・テスティングを実行するのに必要な任意の情報を格納することができる。
一実施形態では、たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００は、図２および図３に関して図示し、説明したＴＩＳＡフローをサポートすることができる。
一実施形態では、たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００は、図６に関して図示し、説明したテスティング・システム６１０のＴＩＳＡプロセッサ６１２およびメモリ６１４に似た形で動作することができる。たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００を、図７に関して図示し、説明したテスティング・システム７１０内など、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサおよび関連するメモリを使用して実施することができる。そのような実施形態では、ＴＩＳＡプロセッサ１２１０自体が、ＩＳＡ命令とＴＩＳＡ命令との両方を解釈し、実行する。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用される装置は、テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をＴＡＰを介してテストするためにテスト命令セット・アーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セット・アーキテクチャの命令のセットは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、ＴＡＰに関連する複数のテスト命令を含む命令の第２セットとを含み、命令の第１クラスの命令および命令の第２クラスの命令は、これによってテスト命令セット・アーキテクチャの命令のセットを形成するために統合される。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用されるＴＩＳＡプロセッサは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含む命令の第１クラスと、ＴＡＰに関連するテスト命令を含む命令の第２クラスとを含み、命令の第１セットのＩＳＡ命令および命令の第２セットのテスト命令は、テストされるシステムの少なくとも一部をテストするために適合されたＴＩＳＡを形成するために統合される。
一実施形態では、テストされるシステム（ＳＵＴ）をテスト・アクセス・ポート（ＴＡＰ）を介してテストするコンピュータ・プロセッサは、ＴＡＰを介するテストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セット・アーキテクチャ（ＴＩＳＡ）に従って命令を処理するように構成された回路網を含む。ＴＩＳＡは、第１タイプの複数の命令および第２タイプの複数の命令を含み、命令の第１タイプは、コンピュータ・プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含み、命令の第２タイプは、ＴＡＰを介してテストされるシステムをテストするためのテスト命令を含む。
主にＴＩＳＡプロセッサが特定の形で（たとえば、異なるクラスおよび／またはタイプの命令を記述するのに特定の言語を使用して）定義される実施形態に関して上で図示し、説明したが、ＴＩＳＡを、本明細書で提供されるさまざまなＴＩＳＡの図示および説明によって完全にサポートされる他の形で定義できることを了解されたい。
主に、ＴＩＳＡをサポートするのに単一プロセッサを使用してＴＩＳＡプロセッサ・アーキテクチャが実施される実施形態に関して本明細書で図示され、説明されるが、他の実施形態では、ＴＩＳＡプロセッサ・アーキテクチャを、複数のプロセッサを使用して実施することができる。
図１３に、システム・テスティング機能を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す。
図１３に示されているように、テスト・プロセッサ・アーキテクチャ１３００は、通信経路１３３０を介して通信する主プロセッサ１３１０および副プロセッサ１３２０を含む。
主プロセッサ１３１０は、ＳＰＡＲＣ Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。主プロセッサ１３１０は、テストされるシステムをテストする命令を実行する。一実施形態では、たとえば、主プロセッサ１３１０は、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００のＣＰＵ １２１０によってサポートされる機能に似たテスティング機能をサポートすることができる（たとえば、テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用する場合に）。一実施形態では、たとえば、主プロセッサ１３１０は、ＴＩＳＡを利用しないテスト・プロセッサ・アーキテクチャ内のテストするプロセッサによってサポートされるテスティング機能をサポートすることができる。主プロセッサ１３１０は、さまざまな他のテスティング機能をサポートすることができる。
副プロセッサ１３２０は、ＳＰＡＲＣ Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。副プロセッサ１３２０は、テストされるシステム（明瞭さのために省略されている）へのテスト・アクセス・ポート（ＴＡＰ）インターフェースをサポートする。このＴＡＰインターフェースは、任意の適切なＴＡＰとインターフェースすることができる。たとえば、このＴＡＰインターフェースは、ＩＥＥＥ １１４９．１ ＴＡＰまたはテストされるシステムをテストするのに使用できる任意の他の適切なＴＡＰへのインターフェースを提供することができる。
主プロセッサ１３１０および副プロセッサ１３２０は、テストされるシステムの少なくとも一部のテストを実行するために協力する。
主プロセッサ１３１０は、テストされるシステムをテストするテスト命令を実行する。このテスト命令は、ＴＩＳＡのテスト命令とすることができ（テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用する場合）、あるいはＴＩＳＡに関連しないテスト命令とすることができる（テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用しない場合）。主プロセッサ１３１０は、テスト命令の実行中に、テストされるシステムのＴＡＰの制御に関係する命令（たとえば、テストされるシステムのＴＡＰコントローラに入力データをロードする命令、テストされるシステムのＴＡＰコントローラから出力データを読み取る命令、および同様の命令、ならびにそのさまざまな組合せなど）を検出する。主プロセッサ１３１０は、副プロセッサ１３２０にＴＡＰ関連命令を供給する。副プロセッサ１３２０は、主プロセッサ１３１０からそのＴＡＰ関連命令を受け取る。副プロセッサ１３２０は、そのＴＡＰ関連命令を実行する。主プロセッサ１３１０は、副プロセッサ１３２０が主プロセッサ１３１０から受け取ったＴＡＰ関連命令を実行する間に、テスト命令の実行を継続する。この形で、主プロセッサ１３１０は、副プロセッサ１３２０がテストされるシステムのＴＡＰを介するスキャン動作を制御する間に、コンテキスト切替を実行し、動作を継続することができる。これは、単一プロセッサ手法を使用すると困難である。というのは、単一プロセッサがＴＡＰを制御している間は、その単一プロセッサが、他の動作の実行を止められるからである。したがって、テスト・プロセッサ・アーキテクチャ１３００内のような複数プロセッサの使用は、特にＴＡＰを介する動作が通常はプロセッサが単一の動作を実行するのに要する時間と比較して長い時間を要することを考慮すると、ハイエンド・プロセッサを使用する必要なしにテスティング効率の大幅な改善を提供する。
テストされるシステムの少なくとも一部のテストを実行するための主プロセッサ１３１０と副プロセッサ１３２０との間の協力は、通信経路１３３０によって容易にされる。通信経路１３３０は、主プロセッサ１３１０と副プロセッサ１３２０との間の通信の任意の適切な手段を使用して実施することができ、この手段は、テスト・プロセッサ・アーキテクチャ１３００がそれを用いて実施されるマルチプロセッサ・アーキテクチャのタイプに依存する可能性がある。たとえば、通信経路１３３０は、メイン・プロセッサ・インターフェース・バス、補助プロセッサ・インターフェース、通信インターフェース（たとえば、シリアライザ−デシリアライザ（ＳＥＲＤＥＳ）インターフェースまたは他の適切な通信インターフェース）、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
明瞭さのために省略されているが、テスト・プロセッサ・アーキテクチャ１３００が、メモリ（たとえば、ランダム・アクセス・メモリ、永続メモリ、キャッシュ・メモリ、および類似物、ならびにそのさまざまな組合せ）を含むことを了解されたい。テスト・プロセッサ・アーキテクチャ１３００のメモリは、主プロセッサ１３１０および副プロセッサ１３２０によって共有されるメモリ、主プロセッサ１３１０に専用のメモリ、副プロセッサ１３２０に専用のメモリ、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
明瞭さのために省略されているが、テスト・プロセッサ・アーキテクチャ１３００が、バス、Ｉ／Ｏ回路、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のサポート回路を含むことができることを了解されたい。
図１３のテスト・プロセッサ・アーキテクチャ１３００を、複数の形で実施することができる。
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置（ＣＰＵ）がシステム・テスティングをサポートするためにテスト・コプロセッサ・ユニット（ＴＣＰＵ）と協力する、テスト・コプロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図１４に関して図示し、説明する。
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置（ＣＰＵ）がシステム・テスティングをサポートするためにテスト付属プロセッサ・ユニット（ＴＡＰＵ）と協力する、テスト付属プロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図１５に関して図示し、説明する。
図１４に、テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す。テスト・コプロセッサ・アーキテクチャ１４００は、ＴＩＳＡを使用するシステム・テスティングをサポートするためのＴＩＳＡプロセッサ・アーキテクチャとしての使用に適する。テスト・コプロセッサ・アーキテクチャ１４００は、ＴＩＳＡを使用しないシステム・テスティングをサポートするためのテスト・プロセッサ・アーキテクチャとしての使用にも適する。
テスト・コプロセッサ・アーキテクチャ１４００は、中央処理装置（ＣＰＵ）１４１０、テスト・コプロセッサ・ユニット（ＴＣＰＵ）１４２０、メイン・メモリ１４３０、およびフラッシュ・メモリ１４４０を含む。
テスト・コプロセッサ・アーキテクチャ１４００は、メイン・プロセッサ・インターフェース・バス１４５１を含む。ＣＰＵ １４１０、ＴＣＰＵ １４２０、メイン・メモリ１４３０、およびフラッシュ・メモリ１４４０は、それぞれ、メイン・プロセッサ・インターフェース・バス１４５１に結合される（または、他の形でこれと通信できるように構成される）。
テスト・コプロセッサ・アーキテクチャ１４００は、補助プロセッサ・インターフェース１４５２をも含むことができ、補助プロセッサ・インターフェース１４５２は、ＣＰＵ １４１０およびＴＣＰＵ １４２０を直接に結合し、これによって、ＣＰＵ １４１０とＴＣＰＵ １４２０との間の直接通信を可能にする。
ＣＰＵ １４１０は、テストされるシステムのシステム・テスティングを実行するのに適する任意のＣＰＵとすることができる。ＣＰＵ １４１０は、図１３に関して図示し、説明した主プロセッサ１３１０によってサポートされるテスティング機能をサポートする。
ＴＣＰＵ １４２０は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のＣＰＵとすることができる。ＴＣＰＵ １４２０は、テスト・アクセス・ポート（ＴＡＰ）インターフェース１４６０をサポートし、ＴＡＰインターフェース１４６０は、任意の適切なＴＡＰ（たとえば、ＩＥＥＥ １１４９．１ ＴＡＰまたはテストされるシステムをテストするのに使用される任意の他の適切なＴＡＰなど）とインターフェースすることができる。ＴＣＰＵ １４２０は、図１３に関して図示し、説明した副プロセッサ１３２０によってサポートされるテスティング機能をサポートする。
ＣＰＵ １４１０およびＴＣＰＵ １４２０は、図１３に関して図示し、説明した主プロセッサ１３１０および副プロセッサ１３２０に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。ＣＰＵ １４１０およびＴＣＰＵ １４２０は、ＴＣＰＵ １４２０がテスティング中にテストされるシステムのＴＡＰを制御するＴＡＰ関連命令を実行する間にＣＰＵ １４１０がテスト命令を処理する動作を継続することを可能にするために、命令例外処理を利用する。
ＣＰＵ １４１０は、テストされるシステムをテストするテスト命令を実行する。ＣＰＵ １４１０は、テスト命令の実行中に命令例外（すなわち、テストされるシステムのＴＡＰの制御に関係する命令）を検出し、その命令例外をＴＣＰＵ １４２０に供給する。ＴＣＰＵ １４２０は、ＣＰＵ １４１０からその命令例外を受け取り、その命令例外を処理し、ＴＣＰＵ １４２０が、ＣＰＵ １４１０が他のタスク（たとえば、他のテスティング命令の実行）を実行するために動作し続ける間にその命令例外を処理できるようになっている。言い換えると、ＣＰＵ １４１０およびＴＣＰＵ １４２０は、システム・テスティング中に協力し、ＴＣＰＵ １４２０がＣＰＵ １４１０によって検出された命令例外を処理する間にＣＰＵ １４１０がコンテキストを切り替え、他のタスクを実行するために動作し続けられるようにし、これによって、システム・テスティング効率を改善する。
一実施形態では、ＣＰＵ １４１０は、たとえばＣＰＵ １４１０の性能を改善するために、キャッシュ１４１１を含む。
一実施形態では、ＴＣＰＵ １４２０は、直接メモリ・アクセス（ＤＭＡ）ユニット１４２１を含み、ＤＭＡユニット１４２１は、システム・テスティングのサポートに使用するのに適する任意のタイプのＤＭＡユニットとすることができる。一実施形態では、たとえば、ＤＭＡユニット１４２１は、スキャッタ／ギャザ（Ｓ／Ｇ）ＤＭＡユニットである。ＴＣＰＵ １４２０は、ＣＰＵ １４１０から受け取った命令例外を処理するためおよびメモリ内に格納された実体的なデータに効率的にアクセスするためにＤＭＡユニット１４２１を利用することができる。一実施形態では、ＣＰＵ １４１０は、命令例外に出会う前に、Ｓ／Ｇ ＤＭＡテーブルを構成することができる。
一実施形態では、ＴＣＰＵ １４２０は、特殊化されたＴＣＰＵ命令のセットをサポートする。特殊化されたＴＣＰＵ命令のセットは、ＴＡＰアクセスおよびＴＡＰ制御をサポートすることができる。特殊化されたＴＣＰＵ命令のセットを、ＴＡＰ状態機械に対して特定のＴＡＰ動作を実行するためにＴＣＰＵ １４２０によって使用することができる。
ＣＰＵ １４１０およびＴＣＰＵ １４２０は、ＣＰＵ １４１０によるテスト命令の実行、ＴＣＰＵ １４２０による命令例外処理、ＴＣＰＵ １４２０によるＴＣＰＵ命令の実行、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ１４３０および／またはフラッシュ・メモリ１４４０を利用する。メイン・メモリ１４３０は、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ１４４０は、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の永続メモリとすることができる。ＣＰＵ １４１０およびＴＣＰＵ １４２０は、調停されるアクセスを用いてメモリを共有する。ＣＰＵ １４１０およびＴＣＰＵ １４２０は、情報を交換するためにメモリを共有することもできる。主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、ＣＰＵ １４１０およびＴＣＰＵ １４２０によって実行される機能をサポートするために使用できることを了解されたい。
ＣＰＵ １４１０およびＴＣＰＵ １４２０は、ＣＰＵ １４１０とＴＣＰＵ １４２０との間の通信、ＣＰＵ １４１０および／またはＴＣＰＵ １４２０とテスト・コプロセッサ・アーキテクチャ１４００の他のコンポーネント（たとえば、メイン・メモリ１４３０、フラッシュ・メモリ１４４０、および他のコンポーネント）との間の通信、および類似物、ならびにそのさまざまな組合せを使用して、テストされるシステムのテスティングを実行する。この通信を、メイン・プロセッサ・インターフェース・バス１４４１および補助プロセッサ・インターフェース１４５２の一方または両方を使用してサポートすることができる。ＣＰＵ １４１０とＴＣＰＵ １４２０との間の通信は、命令例外通知、割込みアクセス、ＤＭＡ調停、および類似物、ならびにそのさまざまな組合せに関連する通信を含むことができる。ＣＰＵ １４１０およびＴＣＰＵ １４２０とテスト・コプロセッサ・アーキテクチャ１４００の他のコンポーネントとの間の通信は、メモリからの読取り、メモリへの書込み、および／またはテストされるシステムをテストするのを支援して実行できる任意の他のタスクに関連する通信を含むことができる。
図１５に、テスト付属プロセッサ・アーキテクチャの例示的実施形態を示す。テスト付属プロセッサ・アーキテクチャ１５００は、ＴＩＳＡを使用するシステム・テスティングをサポートするＴＩＳＡプロセッサ・アーキテクチャとしての使用に適する。テスト付属プロセッサ・アーキテクチャ１５００は、ＴＩＳＡを使用しないシステム・テスティングをサポートするテスト・プロセッサ・アーキテクチャとしての使用にも適する。
テスト付属プロセッサ・アーキテクチャ１５００は、中央処理装置（ＣＰＵ）１５１０およびテスト付属プロセッサ・ユニット（ＴＡＰＵ）１５２０を含む。ＣＰＵ １５１０およびＴＡＰＵ １５２０は、同一基板上に存在することができ、あるいは、異なる基板上に存在することができる。
ＣＰＵ １５１０は、テストされるシステムのシステム・テスティングを実行するのに適する任意のＣＰＵとすることができる。ＣＰＵ １５１０は、図１３に関して図示し、説明した主プロセッサ１３１０によってサポートされるテスティング機能をサポートする。
ＣＰＵ １５１０は、それに関連するメイン・メモリ１５３０Ｍ、フラッシュ・メモリ１５３０Ｆ、および入出力モジュール１５４０を有する。ＣＰＵ １５１０は、それに関連するメイン・プロセッサ・インターフェース・バス１５５０を有する。ＣＰＵ １５１０、メイン・メモリ１５３０Ｍ、フラッシュ・メモリ１５３０Ｆ、および入出力モジュール１５４０は、それぞれ、メイン・プロセッサ・インターフェース・バス１５５０に結合される（または、他の形でこれと通信できるように構成される）。
一実施形態では、ＣＰＵ １５１０は、たとえばＣＰＵ １５１０の性能を改善するために、キャッシュ１５１１を含む。
ＴＡＰＵ １５２０は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のＣＰＵとすることができる。ＴＡＰＵ １５２０は、入出力モジュール１５２１を含む。ＴＡＰＵ １５２０は、テスト・アクセス・ポート（ＴＡＰ）インターフェース１５９０をサポートし、ＴＡＰインターフェース１５９０は、任意の適切なＴＡＰ（たとえば、ＩＥＥＥ １１４９．１ ＴＡＰまたはテストされるシステムをテストするのに使用される任意の他の適切なＴＡＰなど）とインターフェースすることができる。ＴＡＰＵ １５２０は、図１３に関して図示し、説明した副プロセッサ１３２０によってサポートされるテスティング機能をサポートする。
ＴＡＰＵ １５２０は、それに関連するローカル・テスト・メモリ１５６０を有する。ＴＡＰＵ １５２０は、それに関連する内部インターフェース・バス１５７０を有する。ＴＡＰＵ １５２０およびローカル・テスト・メモリ１５６０は、それぞれ、内部インターフェース・バス１５７０に結合される（または、他の形でこれと通信できるように構成される）。
ＣＰＵ １５１０に関連する入出力モジュール１５４０およびＴＡＰＵ １５２０の入出力モジュール１５２１は、ＣＰＵ １５１０とＴＡＰＵ １５２０との間の通信を使用可能にする通信インターフェース１５８０をサポートする。通信インターフェース１５８０は、ＣＰＵ １５１０からＴＡＰＵ １５２０へのＴＡＰ関連コマンドのストリーミングをサポートする。
一実施形態では、ＣＰＵ １５１０に関連する入出力モジュール１５４０およびＴＡＰＵ １５２０の入出力モジュール１５２１は、は、シリアライザ−デシリアライザ（ＳＥＲＤＥＳ）通信機能をサポートし、したがって、通信インターフェース１５８０は、ＳＥＲＤＥＳベースの通信インターフェースである。この実施形態では、ＳＥＲＤＥＳベースの通信インターフェース１５８０を、任意の適切なＳＥＲＤＥＳ通信プロトコル（たとえば、ギガビット・イーサネット（ＧｉｇＥ）、ＳＲＩＯ（Ｓｅｒｉａｌ Ｒａｐｉｄ ＩＯ）、ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ、および類似物など）を使用して実施することができる。主にＣＰＵ １５１０とＴＡＰＵ １５２０との間のＳＥＲＤＥＳベースの通信の使用に関して図示され、本明細書で説明されるが、他の適切な通信機能を、ＣＰＵ １５１０とＴＡＰＵ １５２０との間の通信をサポートするために使用することができる。
ＣＰＵ １５１０およびＴＡＰＵ １５２０は、図１３に関して図示し、説明した主プロセッサ１３１０および副プロセッサ１３２０に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。ＣＰＵ １５１０およびＴＡＰＵ １５２０は、ＴＡＰＵ １５２０がテスティング中にテストされるシステムのＴＡＰを制御するＴＡＰ関連命令を実行する間にＣＰＵ １５１０がテスト命令を処理するために動作を継続することを可能にするために、通信インターフェース１５８０を介するコマンド・ストリーミングを利用する。
ＣＰＵ １５１０は、テストされるシステムをテストするテスト命令を実行する。ＣＰＵ １５１０は、それらのテスト命令の実行中に、テストされるシステムのＴＡＰの制御に関係する命令を検出する。ＣＰＵ １５１０は、それらのＴＡＰ関連命令をＴＡＰＵ １５２０に通信インターフェース１５８０を介して（すなわち、通信インターフェース１５８０を介する伝搬のために、ＣＰＵ １５１０からメイン・プロセッサ・インターフェース・バス１５５０を介して入出力モジュール１５４０に）伝搬させる。ＴＡＰＵ １５２０は、ＣＰＵ １５１０からＴＡＰ関連命令を受け取り、ＣＰＵ １５１０が他のタスク（たとえば、他のテスティング命令の実行）を実行するために動作し続ける間にＴＡＰＵ １５２０がＴＡＰの制御を処理できるように、それらのＴＡＰ関連命令を処理する。言い換えると、ＣＰＵ １５１０およびＴＡＰＵ １５２０は、ＴＡＰＵ １５２０がＣＰＵ １５１０によって検出されたＴＡＰ関連命令を処理する間にＣＰＵ １５１０がコンテキストを切り替え、他のタスクを実行するために動作し続けられるように、システム・テスティング中に協力し、これによってシステム・テスティング効率を改善する。
一実施形態では、ＣＰＵ １５１０によって検出され、ＴＡＰＵ １５２０によって処理されるＴＡＰ関連命令は、ＴＡＰＵ １５２０への伝搬のためにＣＰＵ １５１０によってパケット化される。
一実施形態では、ＣＰＵ １５１０によって検出され、ＴＡＰＵ １５２０によって処理されるＴＡＰ関連命令は、ＴＡＰＵ １５２０によってサポートされるオペコードを含む。１つのそのような実施形態では、ＴＡＰ関連命令は、ＣＰＵ １５１０に関連するメモリとＴＡＰＵ １５２０に関連するメモリとの間（たとえば、メイン・メモリ１５３０Ｍとローカル・テスト・メモリ１５６０との間）でブロック・メモリ・コピーを実行する際の使用に適合された１つまたは複数の拡張コマンドを含むこともできる。
ＣＰＵ １５１０は、テスト命令の実行、ＴＡＰ関連命令の検出、ＴＡＰ関連命令のパケット化、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ１５３０Ｍおよび／またはフラッシュ・メモリ１５３０Ｆを利用する。メイン・メモリ１５３０Ｍは、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ１５３０Ｆは、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の永続メモリとすることができる。
ＴＡＰＵ １５２０は、ＣＰＵ １５１０から受け取ったＴＡＰ関連命令の格納、ＣＰＵ １５１０から受け取ったＴＡＰ関連命令の処理、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにローカル・テスト・メモリ１５６０を利用する。ローカル・テスト・メモリ１５６０は、任意の適切なプロセッサ・メモリとすることができる。一実施形態では、ローカル・テスト・メモリ１５６０を、比較的小さくすることができる。というのは、ローカル・テスト・メモリ１５６０が、スキャン・チェーン全体（オンチップ・メモリ内で要求される場合があるように）ではなく、テストされるシステムのスキャン・チェーンのスキャン・チェーン・セグメントの処理を扱うからである。
主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、ＣＰＵ １５１０およびＴＡＰＵ １５２０によって実行される機能をサポートするために使用できることを了解されたい。
主にＴＩＳＡを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、ＴＩＳＡを、任意の適切なプロセッサ・アーキテクチャを使用して実施でき、このプロセッサ・アーキテクチャが、コプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャ以外のプロセッサ・アーキテクチャを含むことができることを了解されたい。したがって、ＴＩＳＡプロセッサ・アーキテクチャを、さまざまな他の形で複数のプロセッサを使用して実施することができ、これらの形のうちの少なくともいくつかは、ＴＩＳＡをサポートするための３つ以上のプロセッサの使用を含むことができる。
主にＴＩＳＡアーキテクチャを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、コプロセッサ・アーキテクチャおよび付属プロセッサ・アーキテクチャを、それぞれ、他のタイプのテスティング・アーキテクチャ（すなわち、ＴＩＳＡを使用しない他のテスティング・アーキテクチャ）を実施するのに使用できることを了解するであろう。
テスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャが、それぞれＴＩＳＡを２つの通信するプロセッサによって実行することを可能にするという点で機能的に似ていることを了解されたい。所与のアプリケーションで、この２つのアーキテクチャの間の選択は、使用可能なリソース、コスト、性能、物理的制約（同一チップ内の集積、異なるチップおよび／または基板内、あるいはその任意の組合せ）、ならびに任意の他の実施態様パラメータなど、実施態様依存パラメータを基礎として設計者が行うことができる。主にテスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャに関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、これらの実施態様考慮事項が、すべての他のタイプのテスティング・アーキテクチャ／インフラストラクチャにあてはまることを了解するであろう。
図示され、本明細書で説明されるＴＩＳＡプロセッサ・アーキテクチャは、システム・テスティングを実行する際に使用に適切な任意のＴＩＳＡを使用することができる。
ＴＩＳＡプロセッサ・アーキテクチャと共に使用されるように適合されたＴＩＳＡの１つの例示的実施形態の説明が、これに続く。ＴＩＳＡのこの例示的実施形態は、図示され、本明細書で説明されるスキャン・セグメント・レベル・プリミティブの実施態様である。スキャン・セグメント・レベル抽象化レベルでは、テストされるシステムのスキャン・チェーン全体が、セグメントに分割され、これらのセグメントは、アルゴリズムのデータ・アトムとして使用される。テストされるシステムを、アルゴリズム開発者（人間および／または自動化ツールとすることができる）によってスキャン・セグメントに区分できることを了解されたい。スキャン動作をスキャン・セグメント・レベルで実行することを可能にするためのＴＩＳＡの使用のより一般的な説明すなわち、この例示的なＴＩＳＡ実施態様とは独立な説明を、下で詳細に提供する。
ＴＩＳＡの次の実施形態は、これらのスキャン・セグメントを定義し、処理することのできるレジスタおよび命令のセットを処理する。次の実施形態は、３２ビット・サイズのＴＩＳＡに基づくが、これを任意の他の語サイズ（たとえば、１６ビット、６４ビット、または任意の他の適切な語サイズ）に適合させることができる。
図１６に、ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す。例示的なＴＩＳＡは、それぞれ図１６Ａ〜１６Ｄに示された、４つのレジスタ・セット（レジスタ・セットＲ１からＲ４と表される）を含む。
図１６Ａに示されているように、第１レジスタ・セットＲ１は、次のユーザ・アクセス可能データ・レジスタを含む。
・ＳｔａｔｕｓＲｅｇｉｓｔｅｒ 状況状態情報を含む３２ビット・レジスタ
・ＣｏｎｔｒｏｌＲｅｇｉｓｔｅｒ コマンド・エンコーディングを含む３２ビット・レジスタ
・ＢｌｏｃｋＲｅｇｉｓｔｅｒ スキャン・データ・イン（ギャザ・データ）およびデータ・アウト（スキャッタ・データ）を書き込むべき場所を間接的にポイントする事前にフォーマットされたデータ構造へのメモリ内のオフセットを含む３２ビット・レジスタ［スキャッタ／ギャザ・セグメント記述にアクセスするすべてのスキャン動作および比較動作に使用される］
・ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ スキャンされずに残っている現在のビット数が常駐する３２ビット・レジスタ（ブロック・モード・オペコードのスキャッタ／ギャザ・セグメント記述から自動的に取り込まれもする）
・ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ スキャン動作のｓｔａｒｔＳｔａｔｅ、ｓｃａｎＳｔａｔｅ、およびｅｎｄＳｔａｔｅを表す４ビットの３つのバンクを含む３２ビット・レジスタ。４ビットは、ＴＡＰ状態機械の１６個の状態のエンコーディングを表す（ブロック・モードでスキャッタ／ギャザ・セグメント記述から取り込まれもする）
・ＵｓｅｒＤａｔａＲｅｇｉｓｔｅｒｓ［１〜１１］ 小さいスキャン動作およびデータ再利用のためのスキャン・セグメント・データを含む３２ビット・レジスタ（ソース・レジスタまたは宛先レジスタになることができる）
図１６Ｂに示されているように、第２レジスタ・セットＲ２は、次の内部スクラッチ・レジスタを含む。
・ＢｌｏｃｋＰｏｉｎｔｅｒＲｅｇｉｓｔｅｒ ＭｕｌｔｉｐｌｅＳｃａｎ命令中に処理される現在のスキャッタ／ギャザ・セグメント記述参照をポイントする３２ビット・レジスタ
・ＢｌｏｃｋＣｏｕｎｔＲｅｇｉｓｔｅｒ ＭｕｌｔｉｐｌｅＳｃａｎ命令中に処理されるスキャッタ／ギャザ・セグメント記述のカウントを含む３２ビット・レジスタ
・ＩｎｓｔｒｕｃｔｉｏｎＲｅｇｉｓｔｅｒ 現在のオペコードがデコーディングのために置かれる３２ビット・レジスタ
図１６Ｃに示されているように、第３レジスタ・セットＲ３は、次のスキャッタ／ギャザ・セグメント記述レジスタを含む。
・ＢｌｏｃｋＯｆｆｓｅｔＦｉｅｌｄ ６４ビット・アーキテクチャが使用される時のアドレスのバンクを記述する３２ビット数
・ＳｃａｎＬｅｎｇｔｈＦｉｅｌｄ このセグメントについてスキャンすべきビット数を指定する３２ビット整数
・ＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄ それぞれこのスキャン動作の開始状態、スキャン状態、および終了状態を表す４ビットの３つのフィールド（各４ビットは、１６状態ＴＡＰ状態機械状態を表す）。
・ＳｏｕｒｃｅＬｏｃａｔｉｏｎＦｉｅｌｄ ＴＤＩデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＤｅｓｔｉｎａｔｉｏｎＬｏｃａｔｉｏｎＦｉｅｌｄ ＴＤＯデータがメモリ内で格納される場所に関する３２ビット・ベース・アドレス
・ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄ 期待されるベクトルがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＲｅｓｐｏｎｓｅＬｏｃａｔｉｏｎＦｉｅｌｄ キャプチャされたＴＤＩデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＭａｓｋＦｉｅｌｄ 比較動作を制限するのに使用されるＭＡＳＫデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＲｅｓｕｌｔＬｏｃａｔｉｏｎＦｉｅｌｄ 比較の結果がメモリ内で格納される場所に関する３２ビット・ベース・アドレス
図１６Ｄに示されているように、第４レジスタ・セットＲ４は、次のマルチブロック・スキャッタ／ギャザ・セグメント記述レジスタを含む。
・ＢｌｏｃｋＯｆｆｓｅｔＦｉｅｌｄ ６４ビット・アーキテクチャが使用される時のアドレスのバンクを記述する３２ビット数
・ＢｌｏｃｋＣｏｕｎｔＦｉｅｌｄ このＭｕｌｔｉＢｌｏｃｋスキャンによって表されるスキャン・セグメントの個数を定義する３２ビット数（ＭｕｌｔｉＢｌｏｃｋスキャン動作中にＢｌｏｃｋＣｏｕｎｔＲｅｇｉｓｔｅｒを初期化するのに使用される）
・ＳｃａｔｔｅｒＧａｔｈｅｒＯｐｃｏｄｅＦｉｅｌｄ 関連するＳｃａｔｔｅｒＧａｔｈｅｒＢｌｏｃｋＦｉｅｌｄによってポイントされるスキャッタ／ギャザ・セグメント記述に使用される３２ビット・コマンド・オペコード
・ＳｃａｔｔｅｒＧａｔｈｅｒＢｌｏｃｋＦｉｅｌｄ 前のＳｃａｔｔｅｒＧａｔｈｅｒＯｐｃｏｄｅＦｉｅｌｄに関連するスキャッタ／ギャザ・セグメント記述がメモリ内で配置される場所に関する３２ビット・アドレス
例示的なＴＩＳＡレジスタ・セットを、任意の適切な形で変更できることを了解されたい。たとえば、例示的なレジスタ・セットのそれぞれを、より少数の、より多数の、および／または異なるレジスタを含むように変更することができる。たとえば、例示的なレジスタを、より少数の、より多数の、および／または異なるセットに再グループ化することができる。たとえば、より少数の、より多数の、および／または異なるレジスタ・セットを使用することができる。言い換えると、例示的なＴＩＳＡレジスタ・セットを、ＴＩＳＡプロセッサ・アーキテクチャを実施するためにＴＩＳＡ命令セットと共に使用するのに適する任意の他のＴＩＳＡレジスタ・セット（１つまたは複数）に置換することができる。
例示的なＴＩＳＡは、システム・テスティングを実行する際に使用するのに適切な任意のＴＩＳＡ命令セット（すなわち、コマンド辞書）を使用することができる。
例示的なＴＩＳＡ命令セットは、次のオペコードを含み、これらのオペコードは、図１６Ａ〜１６Ｄに関して図示され、説明されたレジスタ・セットＲ１からＲならびに図示され、本明細書で説明されるオリジナルＩＳＡレジスタ・セットを操作するのに利用することができる。
ＳｔａｔｅＴｒａｎｓｉｔｉｏｎ ＜ＴＭＳ Ｖａｌｕｅ＞，＜ＴＣＫ ｃｙｃｌｅｓ＞
・このオペコードは、所与の個数のＴＣＫクロック・サイクルの間にＴＭＳの値を使用してＴＡＰ状態機械をトラバースするのに使用される。このオペコードは、ＴＡＰ状態機械の状態の間で一般的な状態遷移を実行するのに使用される。＜ＴＭＳ Ｖａｌｕｅ＞は、単一ビットを表し、＜ＴＣＫ ｃｙｃｌｅｓ＞は、オペコードの残りのデータ・ビットを表す。
ＲｕｎＴｅｓｔ ＜ｓｔａｒｔＳｔａｔｅ＞，＜ｔｅｓｔＳｔａｔｅ＞，＜ｅｎｄＳｔａｔｅ＞
・このオペコードは、＜ｓｔａｒｔＳｔａｔｅ＞から＜ｔｅｓｔＳｔａｔｅ＞に遷移し、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒによって指定される個数のＴＣＫサイクルの間に＜ｔｅｓｔＳｔａｔｅ＞でループするのに使用される。このオペコードは、ルーピングの結末として＜ｅｎｄＳｔａｔｅ＞に遷移するのに使用される。
ＳｃａｎＲｅｇｉｓｔｅｒ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞］
・このオペコードは、ユーザ・データ・レジスタ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞内のデータをスキャンし、キャプチャされた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞が存在する場合には、存在するならば最終的に＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞を使用して、キャプチャされた値をこれと比較し、それに従ってエラーを送出する。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。
ＳｃａｎＲｅｇｉｓｔｅｒＺｅｒｏ ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞］
・このオペコードは、すべて「０」のベクトル値をスキャンし、キャプチャされた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞および＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞は、ＳｃａｎＲｅｇｉｓｔｅｒ命令と同様に使用される。
ＳｃａｎＲｅｇｉｓｔｅｒＯｎｅ ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞］
・このオペコードは、すべて「１」のベクトル値をスキャンし、キャプチャされた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞および＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞は、ＳｃａｎＲｅｇｉｓｔｅｒ命令と同様に使用される。
ＳｃａｎＢｌｏｃｋ
・このオペコードは、ＳＵＴに対してＢｌｏｃｋＲｅｇｉｓｔｅｒによってポイントされるデータをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンし、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定する。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＴＤＯからのデータは、保存されない。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＣａｐｔｕｒｅ
・このオペコードは、ＳＵＴに対してＢｌｏｃｋＲｅｇｉｓｔｅｒによってポイントされるデータをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンし、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定する。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＴＤＯからキャプチャされたデータは、保存される。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＺｅｒｏＣａｐｔｕｒｅ
・このオペコードは、ＳＵＴに対してすべて「０」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンし、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、ＢｌｏｃｋＲｅｇｉｓｔｅｒによって定義されるレジスタに結果をキャプチャする。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＺｅｒｏ
・このオペコードは、ＳＵＴに対してすべて「０」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンし、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、結果はキャプチャされない。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＯｎｅＣａｐｔｕｒｅ
・このオペコードは、ＳＵＴに対してすべて「１」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンし、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、ＢｌｏｃｋＲｅｇｉｓｔｅｒによって定義されるレジスタに結果をキャプチャする。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＯｎｅ
・このオペコードは、ＳＵＴに対してすべて「１」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンし、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、結果はキャプチャされない。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
例示的なＴＩＳＡ命令セットは、明示的な値を使用する次のレジスタ変更命令を含む。
ＬｏａｄＲｅｇｉｓｔｅｒＥｘｐｌｉｃｉｔ ＜ｃｏｎｓｔ ｖａｌｕｅ＞，＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞
・この命令は、＜ｃｏｎｓｔ ｖａｌｕｅ＞の定数値を、＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタにロードする。
ＣｏｐｙＲｅｇｉｓｔｅｒ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この命令は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞として名前を指定されたレジスタの内容を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞によって名前を指定されたレジスタにコピーする。
例示的なＴＩＳＡ命令セットは、暗黙の値を使用する次のレジスタ変更命令を含む。
ＬｏａｄＲｅｇｉｓｔｅｒＩｍｐｌｉｃｉｔ ＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞，＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞
・この命令は、名前を指定された＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞内の値を、実際のデータが存在するメモリ位置へのポインタ参照として使用し、参照された値を＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタに格納する。
例示的なＴＩＳＡ命令セットは、次のレジスタ保存命令を含む。
ＳｔｏｒｅＲｅｇｉｓｔｅｒＩｍｐｌｉｃｉｔ ＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞，＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞
・この命令は、名前を指定された＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞内の値を、＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタ内の値が格納されるべきメモリ位置へのポインタ参照として使用する。
ＳｔｏｒｅＲｅｇｉｓｔｅｒＥｘｐｌｉｃｉｔ ＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞，＜ｃｏｎｓｔ ｖａｌｕｅ＞
・この命令は、＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタの値を、＜ｃｏｎｓｔ ｖａｌｕｅ＞によって指定されるメモリ位置に格納する。
例示的なＴＩＳＡ命令セットは、次の、レジスタに対する論理演算を含む。
ＡＮＤ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＡＮＤ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＯＲ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＸＯＲ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＸＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＮＯＴ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞に対して論理ＮＯＴ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＸＯＲＭ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、「１」の値を含むユーザ・データ・レジスタ＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞ビットと位置が合っているビットだけを比較しながらユーザ・データ・レジスタ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞とユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＸＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。比較されないビットは、＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞内で「０」の値をもたらすことに留意されたい。
例示的なＴＩＳＡ命令セットは、次の、レジスタに対するその他の動作を含む。
ＮＯＰ
・いくつかのＩＳＡ命令セットでアライメントを実現するためのフィルタとして使用されるノー・オペレーション・オペコード。
例示的なＴＩＳＡ命令セットは、付属プロセッサ・アーキテクチャを使用する実施形態のためにストリーミングのサポートを拡張する次の命令を含む。
ＭｅｍｏｒｙＷｒｉｔｅ
・この命令は、引数＜ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ（シーケンス番号）＞、＜ｂｌｏｃｋ ｏｆｆｓｅｔ（ブロック・オフセット）（３２ビット・オフセット）＞、＜ｎｕｍｂｅｒ ｏｆ ｂｙｔｅｓ ｔｏ ｔｒａｎｓｆｅｒ（転送すべきバイト数）＞、＜ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓ（宛先アドレス）（指定されたメモリ・ブロック内の）＞、＜ｄａｔａ ｂｙｔｅ（データ・バイト）（１つまたは複数）＞を使用して、ローカル・テスト・メモリに書き込む。
ＭｅｍｏｒｙＲｅａｄ
・この命令は、引数＜ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ（シーケンス番号）＞、＜ｂｌｏｃｋ ｏｆｆｓｅｔ（ブロック・オフセット）（３２ビット・オフセット）＞、＜ｎｕｍｂｅｒ ｏｆ ｂｙｔｅｓ ｔｏ ｔｒａｎｓｆｅｒ（転送すべきバイト数）＞、＜ｓｏｕｒｃｅ ａｄｄｒｅｓｓ（ソース・アドレス）（指定されたメモリ・ブロック内の）＞を使用して、ローカル・テスト・メモリから読み取る。この命令は、シーケンス番号および転送されるバイト数を用いてタグ付けされたデータ・バイトのストリームを返す。
例示的なＴＩＳＡ命令セットは、スキャン状態に関する次の値を含む。
ＳｔａｒｔＳｔａｔｅ、ＳｃａｎＳｔａｔｅ、ＥｎｄＳｔａｔｅ
・スキャン状態コードは、ＴｅｓｔＬｏｇｉｃＲｅｓｅｔ（ＴＬＲ）、ＲｕｎＴｅｓｔ／Ｉｄｌｅ（ＲＴＩ）、ＰａｕｓｅＤＲ（ＰＤＲ）、ＰａｕｓｅＩＲ（ＰＩＲ）、ＳｃａｎＤＲ（ＳＤＲ）、ＳｃａｎＩＲ（ＳＩＲ）を含む。状態コードあたり４ビットの表現が存在し、１２ビットが、スキャン動作に関する状態遷移シーケンス全体を記述するのに使用される。
本明細書の教示によって情報を与えられた当業者は、さまざまな他のＴＩＳＡ実施態様を、図示され本明細書で説明されるＴＩＳＡプロセッサ・アーキテクチャと共に使用できることを了解するであろう。たとえば、他のＴＩＳＡ実施態様は、より少数の、より多数の、および／または異なるレジスタを使用することができ、より少数の、より多数の、および／または異なる命令セットを使用することができ、類似物を使用することができ、ならびにそのさまざまな組合せを使用することができる。一実施形態では、異なるプロセッサ・アーキテクチャが使用される場合に、特定の応用例によりよく適するＴＩＳＡ実施態様を提供するためおよび／または任意の他の適切な理由のために、他のＴＩＳＡ実施態様を利用することができる。
上で説明したように、ＪＴＡＧアーキテクチャでのＴＩＳＡの使用は、スキャン動作をスキャン・セグメント・レベルで実行することを可能にし、これは、スキャン・パス全体の内部での独立に制御可能な「スキャン・セグメント」の定義を可能にし、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。
一般に、ＪＴＡＧ動作は、すべてのビットが１つずつ直列にスキャン・インされると同時に、ビットが１つずつ直列にスキャン・アウトされるスキャン動作に基づく。これは、スキャン動作を実行できるために、スキャン・チェーン内のビットごとにどの値が必要とされるか（すなわち、入力ベクトルおよび出力ベクトル）の知識が要求されることを意味する。ＴＧＴは、通常、ＢＳＤＬなどの記述言語を介して入手されるシステム・モデルから必要なベクトルを計算することによって、伝統的な構造テスティングのためにこの機能を提供する。さらに、ＳＶＦおよびＳＴＡＰＬのようなフォーマットは、これを反映する。というのは、これらが、ユーザがこれらのベクトルを操作することを可能にするからである。この形でのテスティングは、テスティングの構造的な（および他のタイプ）には十分であるが、この形でのテスティングは、スキャン・チェーン全体にアクセスする実際の必要がない対話セットアップには非常に非効率的である。この非効率性は、例を検討することによって理解することができる。
たとえば、それぞれが１６ビットを有する１００個の機器からなるスキャン・チェーンを検討されたい。ユーザが、スキャン・チェーン内の７６番目の機器のレジスタに０ｘ１２３４を書き込む必要がある場合には、ＴＧＴは、スキャン・チェーン全体のベクトル（１００＊１６＝１６００ビット）を生成し、スキャン・チェーンに入力するためにこれをＴＡＰインターフェースに送る必要がある。同様に、ユーザが、関連する出力を読み取ることを望む場合には、ＴＧＴは、所望の出力情報を抽出できるようになる前に、１６００ビットのベクトル全体を受け取る必要がある。この例では、スキャン・ビットの大多数が役に立たないという事実は重要ではない。というのは、スキャン効率が、目標の１つではないからである（そうではなく、この例では、目標は、主にスキャン・チェーンの一特定のエンティティに効率的にアクセスできることである）。
このタイプの手法は、少なくとも次の理由から問題である。（ａ）長いベクトルを扱うという計算的な必要がある（たとえば、大量のメモリ転送は、性能に対する大きい影響を有する）、（ｂ）ベクトル（１つまたは複数）全体をメモリに格納する必要がある（長いチェーンについて問題になる可能性がある）、（ｃ）メモリ・ストレージが、データ入力およびデータ出力に制限されるのではなく、期待されるデータ、入力マスク、出力マスク、および類似物をも含む（これによって、入力データおよび出力データだけから既に潜在的に過大な負担を受けているメモリ要件を増やす）、および（ｄ）機器−ベクトル−機器の変換を、毎回行わなければならない（これは、計算能力および時間を必要とする）。
スキャン・セグメント・レベル抽象化レベルは、スキャン効率に対する特別な強調を全く用いずに（もちろん、必要な場合にそれを使用可能にする場合であっても）テストされるシステムのスキャン・チェーンの個々のエンティティまたはエンティティのグループへの効率的なアクセスを提供する強力なツールである。
一実施形態では、スキャン・セグメント・レベル抽象化は、スキャン・チェーンを一連のセグメントに分解することと、セグメントのそれぞれに対する１つまたは複数のスキャン動作を定義することとによって実施される。スキャン・チェーンは、複数の要素からなり、各セグメントは、スキャン・チェーンの要素のうちの少なくとも１つを含む。要素を、テストされるシステムの多数のレベルで定義することができ（たとえば、要素を、デバイス、機器、レジスタ、レジスタのセグメント、および類似物、ならびにそのさまざまな組合せとすることができる）、したがって、スキャン・チェーンがそれに分解されるセグメントを、テストされるシステムの多数のレベルで定義することができる（たとえば、セグメントを、１つまたは複数のデバイス、デバイス（１つまたは複数）の一部、１つまたは複数の機器、機器（１つまたは複数）の一部、１つまたは複数のレジスタ、レジスタ（１つまたは複数）の一部、１つまたは複数のレジスタ・セグメント、および類似物、ならびにそのさまざまな組合せとすることができる）。この形で、セグメントは、スキャン・チェーンの最小の制御単位を表すことができる。
一実施形態では、セグメントへのスキャン・チェーンの分解を、階層的とすることができる。たとえば、スキャン・チェーンをセグメントに分解することができ、そのセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、そのサブセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、以下同様である。この形で、スキャン・チェーンの階層分解を、あるセグメントを他のセグメントから構成できるツリーベースの構造を有するとみなすことができる。１つのそのような実施形態では、ツリーの葉のセグメントを、セグメントと呼ぶことができ（それらがスキャン・チェーンの最小の制御単位を表すという点で）、ツリーの葉の上に位置するセグメントを、スーパーセグメントと呼ぶことができる。一実施形態では、スキャン・チェーンのセグメントのうちの１つまたは複数を、ユーザ／システムに透過的である形でのみ制御可能である仮想サブセグメントから構成することができることを了解されたい）。スキャン・チェーンの階層分解を、任意の他の適切な形で定義することができる。
セグメント化の使用は、セグメントのタイプおよび／またはセグメント組合せのタイプに関するエンティティの定義を可能にする。エンティティは、あるタイプのターゲットの包括的記述であり、この記述は、そのタイプのターゲットの各物理インスタンスについて有効であり、そのタイプのターゲットの物理インスタンスごとに再利用することができる。たとえば、あるエンティティが、デバイス、デバイスのグループ、デバイスの一部、機器、機器のグループ、機器の一部、および類似物、ならびにそのさまざまな組合せを定義することができる。したがって、スキャン・チェーンを、スキャン・チェーンのセグメントが特定の要素または要素の組合せを含むように分解することができるので、エンティティを、スキャン・チェーンのそれぞれのセグメントおよび／またはセグメントのそれぞれの組合せについて定義することができる。たとえば、スキャン・チェーンが、１つのセグメントが１つの機器を含むように分解される場合には、エンティティを、そのタイプのセグメント（すなわち、そのタイプの機器を含む各セグメント）について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。同様に、たとえば、スキャン・チェーンが、１つのセグメントが複数の機器を含むように分解される場合には、エンティティを、そのタイプのセグメント（すなわち、そのタイプの機器の組合せを含む各セグメント）について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。これは、下で説明するように、追加の特徴および機能をサポートすることを可能にする。
セグメント化の使用は、エンティティ（すなわち、制御下のあるタイプのセグメントの記述）を、そのエンティティと通信するのに使用される物理プロトコルと相関させることを可能にする。その結果、記述言語（たとえば、ＮＳＤＬ、Ｐ１６８７ ＩＪＴＡＧ ＰＤＬ、および類似物など）を、特にそのエンティティのために記述することができ、接続性記述部分（たとえば、ＮＳＤＬまたはＩＪＴＡＧ ＨＤＬの構造）は、セグメント化命令の順序付けを記述する。
ＴＩＳＡは、ＴＩＳＡ命令がモデルベースの動作ではなくセグメントベースの動作なので、特定のエンティティ・タイプのすべてのオカレンスについて１回定義できる再利用可能なモジュラ性を提供する。したがって、ＴＩＳＡは、モジュラであるとともに、特定のセグメント内のテストされるエンティティについて自律的でもあるので、ＴＩＳＡは、既存アーキテクチャに対する大きい利益を提供する。
ＴＩＳＡは、既存のツールが必要とするように接続性全体を静的モデルとして前もって定義する必要なしに、必要な任意の順序でスキャン・プロセス内の任意の点で実行フローに組み入れることのできる再利用可能で移植可能なモジュールへのテスト・データ・レジスタ定義の直接マッピングを可能にする。ＴＩＳＡは、統一された制御フローおよび標準的なコンピュータ・サイエンス技法に基づく単一解空間アーキテクチャとして、スキャン動作との非スキャンであるポート／信号インターフェースの統合を可能にする（ネイティブ言語構造が非スキャン動作へのアクセスを提供するのに使用される解決策に対する大きい利益を提供する）。
ＴＩＳＡは、同一エンティティの複数のインスタンスに関する命令シーケンスの再利用を可能にし、これによって、システム内のコード・ストレージ要件の削減を可能にする。たとえば、管理プログラムによって呼び出される記述言語関数にマッピングされる一般化された関数を記述することができる。この例では、関数のそれぞれは、エンティティを表すネイティブ言語オブジェクトのメソッドであり、システム内で定義されたエンティティごとにこれらのオブジェクトの別々のインスタンスがある場合があるが、これらのインスタンスのそれぞれと通信するのに使用されるコードの単一のコピーがあるものとすることができる。この形で、ネイティブ言語実施モデルは、回路の接続性および機能性を指定するのに使用される記述言語を直接に制御する。
上で与えた例を参照すると、スキャン・セグメント・レベル抽象化の使用は、機器１から７５を含むセグメントＳ１、機器７６を含むセグメントＳ２、および機器７７から１００を含むセグメントＳ３という３つのセグメントの定義を可能にする。この形で、機器７６へのアクセスが、大幅に単純化される。たとえば、機器７６へのアクセスを、セグメントＳ３の「ダミー・シフト」を行うこと（たとえば、ＳｃａｎＢｌｏｃｋＺｅｒｏ）と、セグメントＳ２（すなわち、機器７６）について命令（１つまたは複数）を実行することと、セグメントＳ１について別のダミー・シフトを行うことと、その後、更新を伴って終了することとによって得ることができる。そのようなシーケンスでは、セグメントＳ２（すなわち、スキャン・チェーン内の特定の機器）へのアクセスは、その長さを除いてセグメントＳ１またはセグメントＳ３の知識を全く必要とせずに実現される。これが、単に１つの例であり、したがって、１００個の機器の長さのチェーンの別の分解が、他の機器または機器グループへのアクセスを可能にするために可能であることを了解されたい。
図１７に、テストされるシステムの例示的スキャン・チェーンの例示的分解を示す、テストされるシステムの高水準ブロック図を示す。
例示的なＳＵＴ １７００は、４つのデバイス１７１０１〜１７１０４（集合的にデバイス１７１０、図１７ではそれぞれデバイス１、デバイス２、デバイス３、およびデバイス４と表される）を含む。デバイス１７１０は、スキャン・チェーン１７２０を形成するためにＳＵＴ １７００内で直列に配置される。スキャン・チェーン１７２０は、次のようになっている。ＴＡＰのＴＤＩは、デバイス１７１０４の入力ポートに接続され、デバイス１７１０４の出力ポートは、デバイス１７１０３の入力ポートに接続され、デバイス１７１０３の出力ポートは、デバイス１７１０２の入力ポートに接続され、デバイス１７１０２の出力ポートは、デバイス１７１０１の入力ポートに接続され、デバイス１７１０１の出力ポートは、ＴＡＰのＴＤＯに接続される。
例示的なＳＵＴ １７００内では、デバイス１７１０のそれぞれが、（１）テスト命令レジスタ（ＴＩＲ）およびテスト・データ・レジスタ（ＴＤＲ）に入力を供給する入力デマルチプレクサ、および（２）ＴＩＲおよびＴＤＲから出力を収集する出力マルチプレクサを含む。各デバイス１７１０のＴＩＲおよびＴＤＲは、並列レジスタである。デバイス１７１０３は、入力デマルチプレクサが入力を１つのＴＩＲおよび２つのＴＤＲに供給し、その１つのＴＩＲおよび２つのＴＤＲから出力を収集するように、１つの追加のＴＤＲを含み、この１つのＴＩＲおよび２つのＴＤＲは、すべてが並列になっている。ＴＩＲおよびＴＤＲは、それぞれ、直列シフト・レジスタとして図示され、それぞれが９個の関連する要素（たとえば、フリップフロップ）を含む。この形で、（ａ）ＴＩＲは、３６個の直列要素を含む１つのスキャン・チェーン（テスト命令スキャン・チェーンと表される）を形成し、（ｂ）ＴＤＲは、合計４５個の要素および３６個の直列要素（すなわち、デバイス１７１０３の２つのＴＤＲは並列なので）を含むもう１つのスキャン・チェーン（テスト・データ・スキャン・チェーンと表される）を形成する。
例示的なＳＵＴ １７００内では、テスト命令スキャン・チェーンが、デバイス１７１０４のＴＩＲの９個の要素を含む第１セグメントＳＩ４、デバイス１７１０３のＴＩＲの９個の要素を含む第２セグメントＳＩ３、デバイス１７１０２のＴＩＲの９個の要素を含む第３セグメントＳＩ２、およびデバイス１７１０１のＴＩＲの９個の要素を含む第４セグメントＳＩ１という４つのセグメントに分解されている。この形で、テスティング・システムは、ＳＵＴ １７００の他のＴＩＲの最小限の（それらを構成する要素数以外の）知識を用いて、ＳＵＴ １７００のＴＩＲのいずれにも個別にまたは組み合わせてアクセスすることができる。
例示的なＳＵＴ １７００内では、テスト・データ・スキャン・チェーンは、デバイス１７１０４のＴＤＲの９個の要素を含む第１セグメントＳＤ４、デバイス１７１０３のＴＤＲの９個の要素を含む第２セグメントＳＤ３、デバイス１７１０２の第１ＴＤＲの９個の要素（サブセグメントＳＤ２．１と表される）またはデバイス１７１０２の第２ＴＤＲの９個の要素（サブセグメントＳＤ２．２と表される）を含む第３セグメントＳＤ２（これらは、セグメントの総数を数えるために別々のセグメントとしてカウントされる）、ならびに、デバイス１７１０１のＴＤＲの最初の３つの要素を含む第１サブセグメント（サブセグメントＳＤ１．１と表される）、デバイス１７１０１のＴＤＲの次の４つの要素を含む第２サブセグメント（サブセグメントＳＤ１．２と表される）、およびデバイス１７１０１のＴＤＲの最後の２つの要素を含む第３サブセグメント（サブセグメントＳＤ１．３と表される）という３つの直列サブセグメントにさらに分解される第４セグメントという６つの直列セグメント（合計７つのセグメント）に分解されている。この形で、テスティング・システムは、ＳＵＴ １７００の他のＴＤＲの最小限の（それらを構成する要素数以外の）知識を用いて、ＳＵＴ １７００のＴＤＲのいずれにも（またはデバイス１７１０１のＴＤＲのサブ部分にさえ）個別にまたは組み合わせてアクセスすることができる。
図１７のＳＵＴ １７００が、テストされるシステムのスキャン・チェーン（１つまたは複数）をスキャン・セグメント・レベル抽象化を提供する際の使用のために分解できる形の単に１つの例であることを了解されたい。要素、コンポーネント、および類似物の特定のタイプ、個数、および配置に関して図示され、本明細書で説明されるが、そのスキャン・チェーン（１つまたは複数）が分解されるテストされるシステムが、要素、コンポーネント、および類似物のさまざまな他のタイプ、個数、および／または配置を含むことができることを了解されたい。
本明細書で説明するように、テストされるシステムのスキャン・チェーンの分解は、スキャン動作をセグメントに対して定義することを可能にし、これによってテスティング効率を改善する。分解されたスキャン・チェーンのセグメントに関するスキャン動作を含む命令のセットを生成する、一実施形態による方法を、図１８に関して図示し、本明細書で説明する。
スキャン分解およびスキャン・セグメント動作の生成のより詳細な説明を、以下に行う。
一般的な例として、各基板がセグメント（それぞれ第１基板、第２基板、および第３基板に関連してセグメントＡ、Ｂ、およびＣと表す）を含む３つの基板を含むスキャン・チェーンを検討されたい。この例では、スキャン・セグメントが階層的である場合に、第１基板上のセグメントＡを、複数のサブセグメント（たとえば、サブセグメントＡ１からＡｎ）から構成することができ、第２基板上のセグメントＢを、複数のサブセグメント（たとえば、サブセグメントＢ１からＢｎ）から構成することができ、かつ／または第３基板上のセグメントＣを、複数のサブセグメント（たとえば、サブセグメントＣ１からＣｎ）から構成することができる。
より具体的な例として、アプリケーションおよびＳＵＴに従って、セグメントを、機器の内部の１つまたは複数のレジスタ、機器、レジスタのクラスタ、１つまたは複数の基板、および類似物、ならびにそのさまざまな組合せとすることができる。
したがって、全体的なスキャン動作は、一連のセグメント・スキャン動作に分解される。その結果、最終的なスキャン・チェーン動作を得るために必要なものは、一連の単純な不可分動作だけである。したがって、スキャン・セグメント・レベル抽象化の実施形態は、これに排他的に限定はされないが、不可分テスト動作がプロセッサ動作のように扱われる実施態様で（たとえば、図示され本明細書で説明されるさまざまなＴＩＳＡ実施態様または不可分テスト動作がプロセッサ動作のように扱われる任意の他の類似する実施態様で）特に有効である。
スキャン・セグメント・レベル抽象化のそのような実施形態では、スキャン・セグメント・レベル・スキャン動作の実際の実施態様が、ＪＴＡＧにリンクされた１つまたは複数の技術的制約に対処することを必要とする場合がある。たとえば、とりわけＴＡＰマシンの状態を定義する必要性およびＰａｕｓｅ−ＤＲ状態（必ず実施されるわけではない）を使用することの危険性などの制約に対処する必要がある場合がある。
スキャン・チェーン内の機器／セグメントの位置に基づいてスキャン・チェーンを介して受け取られる出力ビットストリーム内の機器／セグメント出力を識別するために、スキャン・インされる最初のセグメントが、スキャン・アウトされる最初のセグメントにもなるように（スキャン・チェーンの終りに最も近いので）、スキャン・チェーンを、先入れ先出し（ＦＩＦＯ）システムとして扱うことができる（その直列の性質を考慮して）。
ＳＵＴにスキャン・セグメント動作のシーケンスを単一スキャン動作のように「経験」させるために、ＴＣＫを、セグメント動作の間に凍結することができる。スキャン・チェーンの内部のすべての要素が同期式なので、この形でのＴＣＫの凍結の効果は、スキャン・チェーンがＴＣＫと一緒に凍結されることである。
ＴＩＳＡベースのテスティング・システムでのスキャン・セグメント・レベルの使用は、少数の例によってよりよく理解することができる。次の例では、テストされるシステム（ＳＵＴ）が、３つのセグメント（その順番でＡ、Ｂ、およびＣと表される）からなり、ユーザが、セグメントＢの内部に値Ｖを書き込む必要があると仮定する。
第１の例として、システムの３つのセグメント（Ａ、Ｂ、およびＣ）が、同一のＪＴＡＧデバイスの内部で実施されると仮定する。この第１の例では、３つのセグメントがメモリ内で定義された後に、ＴＩＳＡ動作は、
ｉ． Ｓｔａｒｔｓｔａｔｅ＝Ｒｕｎ−Ｔｅｓｔ−Ｉｄｌｅ、Ｓｃａｎｓｔａｔｅ＝Ｅｎｄｓｔａｔｅ＝ＳｈｉｆｔＤＲをセットする
ｉｉ． ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＡの長さをセットする
ｉｉｉ． セグメントＡにバイパス・シーケンスをスキャンする
ｉｖ． Ｓｔａｒｔｓｔａｔｅ＝Ｓｃａｎｓｔａｔｅ＝Ｅｎｄｓｔａｔｅ＝ＳｈｉｆｔＤＲをセットする
ｖ． ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＢの長さをセットする
ｖｉ． セグメントＢにＶをスキャンする
ｖｉｉ． Ｓｔａｒｔｓｔａｔｅ＝Ｓｃａｎｓｔａｔｅ＝ＳｈｉｆｔＤＲ、Ｅｎｄｓｔａｔｅ＝Ｒｕｎ−Ｔｅｓｔ−Ｉｄｌｅをセットする
ｖｉｉｉ． ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＣの長さをセットする
ｉｘ． セグメントＣにバイパス・シーケンスをスキャンする
になる。
第１の例に関して、ＴＡＰ有限状態機械（ＦＳＭ）をＳｈｉｆｔＤＲ状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。これは、第１の例から見ることができ、第１の例では、ＳｈｉｆｔＤｒから出た後にのみＵｐｄａｔｅＤＲ状態に達することを考慮すると、ステップ（ｉ）からステップ（ｉｘ）までＴＡＰ ＦＳＭをＳｈｉｆｔＤＲ状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。
さらに第１の例に関して、スキャン・クロックＴＣＫは、スキャン動作中（すなわち、ステップ（ｉｉｉ）、（ｖｉ）、および（ｉｘ））のみアクティブであり、残りの状態では凍結される。その効果は、ＳＵＴが、ＴＣＫと同期する動作に基づくＳＵＴの観点から、ステップ（ｉｉｉ）、（ｖｉ）、および（ｉｘ）を連続ビットストリームとみなすことである。
さらに第１の例に関して、「バイパス・シーケンス」は、スキャン・セグメントのプロパティであり、たとえば、所与のシーケンス（すべて０、すべて１、または任意の他の適切なシーケンス）または「ドントケア」とすることができ、そのようなシーケンスを決定することは、ＴＧＴに委ねられる。
第２の例として、システムの３つのセグメント（Ａ、Ｂ、およびＣ）が、異なるＪＴＡＧデバイス（１つまたは複数のカード内）上で実施されると仮定する。この第２の例では、３つのセグメントがメモリ内で定義された後に、ＴＩＳＡ動作は、
ｉ． セグメントＡの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＩＲ（ｇａｔｅＴＣＫインジケータ）
ｉｉ． セグメントＡのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＡのＩＲの長さをセットする
ｉｉｉ． セグメントＡのＢＹＰＡＳＳ命令パターンを用いてＳｃａｎＢｌｏｃｋを実行させる
ｉｖ． セグメントＢの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＩＲ（ｇａｔｅＴＣＫインジケータ）
ｖ． セグメントＢのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＢのＩＲの長さをセットする
ｖｉ． セグメントＢのＥＸＴＥＳＴ命令パターンを用いてＳｃａｎＢｌｏｃｋを実行させる
ｖｉｉ． セグメントＣの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ
ｖｉｉｉ． セグメントＣのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＣのＩＲの長さをセットする
ｉｘ． セグメントＣのＢＹＰＡＳＳ命令パターンを用いてＳｃａｎＢｌｏｃｋを実行させる
ｘ． セグメントＡの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＤＲ（ｇａｔｅＴＣＫ）
ｘｉ． セグメントＡのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＡの選択されたＤＲの長さをセットする（１ビットＢＹＰＡＳＳ ＤＲ）
ｘｉｉ． セグメントＡのＢＹＰＡＳＳデータ・パターンを用いてＳｃａｎＢｌｏｃｋを実行させる
ｘｉｉｉ． セグメントＢの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＤＲ（ｇａｔｅＴＣＫ）
ｘｉｖ． セグメントＢのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＢの選択されたＤＲの長さをセットする（ピンへのｎビットＢＳＲ ＤＲ）
ｘｖ． セグメントＢのＥＸＴＥＳＴデータ・パターンを用いてＳｃａｎＢｌｏｃｋを実行させる
ｘｖｉ． セグメントＣの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ
ｘｖｉｉ． セグメントＣのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＣの選択されたＤＲの長さをセットする（１ビットＢＹＰＡＳＳ ＤＲ）
ｘｖｉｉｉ． セグメントＣのＢＹＰＡＳＳデータ・パターンを用いてＳｃａｎＢｌｏｃｋを実行させる
になる。
第１の例と第２の例との比較において、第２の例に関連する追加の複雑さが、セグメントを選択／選択解除するために各ＪＴＡＧデバイスの命令レジスタ（ＩＲ）を使用する必要性に由来することを理解されたい。その場合に、未使用セグメントは、関連するＪＴＡＧデバイスを１１４９．１標準規格のＢＹＰＡＳＳモードにすることによって（第２の例のステップ（ｉｉｉ）および（ｘｖｉｉ）に示されているように）直接にチェーンから外される。
１つまたは複数のＪＴＡＧデバイス上で定義される任意の個数のセグメントを伴う、上の２つの例のすべての合成が可能であることを了解されたい。さらに、上の２つの例が、単にテストされるシステムをテストするためのスキャン・セグメント・レベルの使用を示すために提供される例であり、したがって、スキャン・セグメント・レベルがテストされるシステムのテスティングに使用される実施形態がこれらの例によって限定されることは意図されていないことを了解されたい。
そのような実施形態では、ＴＩＳＡ命令の実際のシーケンスは、次のうちの１つまたは複数を含む複数の出所を有することができる。（１）ＴＩＳＡ命令を、ＴＧＴによって静的に計算することができ、この場合には、ユーザがセグメントにアクセスすることを望むたびに、チェーン全体をスキャンしなければならない（この解決策は、スキャン時間に関しては最適化されないが、限られた計算リソースを有し、時間制約がほとんどまたは全くない組込みシステムに有用である可能性があることを了解されたい）、（２）ＴＩＳＡ命令を、アクセス要求を受け取り、これらをスキャン動作に合成するソフトウェア・スケジューラによって発行することができ、かつ／または（３）ＴＩＳＡ命令を、ハードウェア・スケジューラによって発行することができる（たとえば、いくつかの高性能プロセッサ内で命令リオーダリングおよびバイパスに関して行われるものなどであるが、これらに限定はされない）。スキャン・セグメント・レベル制御に関連するＴＩＳＡ命令を、任意の他の適切な形で発行することができ、これらの形が、上で説明した方法および／または上で説明した方法のうちの１つもしくは複数の代わりにもしくはそれに加えて使用できる１つもしくは複数の他の適切な方法の組合せを含むことができることを了解されたい。
スキャン・セグメント・レベル抽象化レベルは、ＩＥＥＥ Ｐ１６８７標準規格によって提案されるものおよび他の動的トポロジなどの動的トポロジを処理する強力なツールである。スキャン・チェーンのあるセクションが、アクティブ・スキャン・パスに取り込まれ、外される（たとえば、ＩＥＥＥ Ｐ１６８７標準規格によって提案されるＳＩＢセルまたは任意の他の適切な階層を使用可能にするコンポーネント（１つまたは複数）を使用して）場合には、そのセクションを、１つ（または複数）のセグメントとしてマークすることができる。次に、テスティング・スケジューラは、システム状態から、このセグメント（１つまたは複数）がアクティブであるか否かに関する知識を有し、したがって、このセグメントをＴＩＳＡ命令スケジューリングに含めなければならないかどうかに関する知識を有する。本明細書の教示によって情報を与えられた当業者は、この原理を、ホットスワップ基板（たとえば、状況レジスタからその存在を検出することによって）または任意の他の適切な動的要素など、他の動的要素にも使用できることを了解するであろう。
図１８に、スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用する、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態の高水準ブロック図を示す。
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法１８００のステップの少なくとも一部を、同時にまたは図１８に関して図示され説明されるものとは異なる順序で実行することができる。
ステップ１８０２で、方法１８００が開始される。
ステップ１８７０４では、スキャン・チェーンを複数のセグメントに分解する。スキャン・チェーンは、複数の要素に分解され、各セグメントは、スキャン・チェーンの要素のうちの少なくとも１つを含む。上で説明したように、スキャン・チェーンを任意の適切な形でセグメントに分解することができる。本明細書で説明するように、セグメントへのスキャン・チェーンの分解を、開発フロー内のどこにでも適用することができる（たとえば、テスト開発者によって、テスト生成ツールによって、組込み回路モデルによって、および類似物）。
ステップ１８０６では、命令のセットを生成する。命令のセットは、ＩＳＡに関連するプロセッサ命令と、テストされるシステムの一部分をテストするテスト命令とを含む。テスト命令は、スキャン・チェーンのセグメントごとに、そのセグメントに対して実行すべき少なくとも１つのスキャン動作を含む。テスト命令は、従来のテスト命令、ＴＩＳＡのテスト命令、および類似物など、任意のタイプのテスト命令とすることができ、したがって、任意の適切な形で生成することができる。命令のセットを、任意の適切な形で生成することができる（たとえば、に関して図示し、上で説明したものと同一のまたはこれに類似する形で
ステップ１８０８では、テストされるシステムの一部分をテストするために命令のセットを実行する。命令のセットは、任意の適切な形で実行することができ、この形は、命令のセットの命令のタイプに依存する場合がある。
ステップ１８１０で、方法１８００は終了する。
主にＴＩＳＡの実施形態がスキャン動作をスキャン・セグメント・レベルで実行することを可能にするのに使用される実施形態に関して図示され、本明細書で説明されるが、図示され本明細書で説明されるスキャン・セグメント・レベル実施形態のうちの１つまたは複数を、ＴＩＳＡ様命令アーキテクチャ、非ＴＩＳＡ命令アーキテクチャ、および／または非ＴＩＳＡテスティング環境実施態様、ならびに類似物を使用する環境で提供することもできることを了解されたい。
図示され本明細書で説明されるように形成し、利用することのできるＴＩＳＡの例示的実施形態によって使用可能にされる機能強化されたシステム・テスティング機能を説明するために本明細書で「ｔｈｅ ＴＩＳＡ」に言及するが、ＴＩＳＡがそれのために形成されるプロセッサのＩＳＡ、ＴＩＳＡがそれのために形成されるＳＵＴの特性、ＴＩＳＡが実行すると思われるテスト・アルゴリズムの特性、および類似物のうちの１つまたは複数、ならびにそのさまざまな組合せなどのさまざまな要因に依存して、多数の異なるＴＩＳＡを形成できることを了解されたい。したがって、本明細書での「ｔｈｅ ＴＩＳＡ」への言及は、多数の異なるタイプのＴＩＳＡを形成できるという点で、より一般的に「ａ ＴＩＳＡ」と解釈することもできる。
図１９に、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。図１９に示されているように、コンピュータ１９００は、プロセッサ要素１９０２（たとえば、中央処理装置（ＣＰＵ）または他の適切なプロセッサ（１つまたは複数））、メモリ１９０４（たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、および／または任意の他の適切なタイプのメモリ）、図示され本明細書で説明されるシステム・テスティング機能を実行するように適合されたシステム・テスティング・モジュール／プロセス１９０５、およびさまざまな入出力デバイス１９０６（たとえば、ユーザ入力デバイス（キーボード、キーパッド、マウス、および類似物など）、ユーザ出力デバイス（ディスプレイ、スピーカ、および類似物など）、入力ポート、出力ポート、受信器、送信器、およびストレージ・デバイス（たとえば、テープ・ドライブ、フロッピ・ドライブ、ハード・ディスク・ドライブ、コンパクト・ディスク・ドライブ、および類似物））を含む。
図示され本明細書で説明されるシステム・テスティング機能を、ソフトウェアならびに／あるいはソフトウェアおよびハードウェアの組合せで、たとえば、汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または任意の他のハードウェア同等物を使用して、実施できることに留意されたい。一実施形態では、システム・テスティング・プロセス１９０５を、メモリ１９０４にロードし、プロセッサ１９０２によって実行して、上で説明したシステム・テスティング機能の少なくとも一部を実施し、かつ／またはその実施をサポートすることができる。したがって、システム・テスティング・プロセス１９０５（関連するデータ構造を含む）を、コンピュータ可読記憶媒体または担体、たとえば、ＲＡＭメモリ、磁気ドライブ、磁気ディスケット、光ドライブ、光ディスケット、および類似物に格納することができる。
本明細書でソフトウェア方法として論じたステップのうちのいくつかを、ハードウェア内で、たとえばさまざまな方法ステップを実行するためにプロセッサと協力する回路網内で実施できることが企図されている。本明細書で説明された機能／要素の諸部分を、コンピュータ・プログラム製品として実施することができ、ここで、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および／または技法が呼び出されるか他の形で提供されるように、コンピュータの動作を適合させる。本発明的方法を呼び出す命令を、固定媒体または取外し可能媒体に格納し、放送媒体または他の信号担持媒体内のデータ・ストリームを介して伝送し、かつ／または命令に従って動作するコンピューティング・デバイス内のメモリ内に格納することができる。
本発明の教示が組み込まれたさまざまな実施形態を図示し、本明細書で詳細に説明したが、当業者は、これらの教示が組み込まれた、多数の他の変更された実施形態をたやすく考案することができる。

Claims (10)

  1. テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用される装置であって、
    テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、
    前記テストされるシステムの少なくとも一部を前記ＴＡＰを介してテストするために前記テスト命令セット・アーキテクチャの命令の前記セットを実行するプロセッサと、を含み、
    前記テスト命令セット・アーキテクチャの命令の前記セットは、
    前記プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、
    前記ＴＡＰに関連する複数のテスト命令を含む命令の第２セットと、を含み、
    命令の前記第１セットの命令および命令の前記第２セットの命令が統合され、これによって、前記テスト命令セット・アーキテクチャの命令の前記セットを形成する、装置。
  2. 前記プロセッサによってサポートされる前記ＩＳＡの前記命令は、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルを使用して生成される、請求項１に記載の装置。
  3. 前記プロセッサによってサポートされる前記ＩＳＡの前記命令は、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルを前処理することによって生成される少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルを使用して生成される、請求項１に記載の装置。
  4. 前記ＴＡＰに関連する前記テスト命令は、前記テストされるシステムに関連する少なくとも１つの記述ファイルを使用して生成される、請求項１に記載の装置。
  5. 前記ＴＡＰに関連する前記テスト命令は、前記テストされるシステムに関連する少なくとも１つの記述ファイルおよび少なくとも１つのテスト動作ファイルを使用して生成され、前記少なくとも１つのテスト動作ファイルは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルを前処理することによって生成される、請求項１に記載の装置。
  6. 命令の前記第１セットからの命令は、命令の前記第２セットからの命令の実行を制御する際の使用のために適合される、請求項１に記載の装置。
  7. テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする装置であって、
    テスト命令セット・アーキテクチャの命令のセットを格納する手段と、
    前記テストされるシステムの少なくとも一部を前記ＴＡＰを介してテストするために前記テスト命令セット・アーキテクチャの命令の前記セットを実行する手段と、を含み、
    前記テスト命令セット・アーキテクチャの命令の前記セットは、
    前記実行する手段によってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、
    前記ＴＡＰに関連する複数のテスト命令を含む命令の第２セットと、を含み、
    命令の前記第１セットの命令および命令の前記第２セットの命令が統合され、これによって、前記テスト命令セット・アーキテクチャの命令の前記セットを形成する、装置。
  8. テストされるシステムをテスト・アクセス・ポート（ＴＡＰ）を介してテストするコンピュータ・プロセッサであって、前記コンピュータ・プロセッサは、前記ＴＡＰを介する前記テストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セット・アーキテクチャに従って命令を処理するように構成された回路網を含み、前記テスト命令セット・アーキテクチャは、第１タイプの複数の命令および第２タイプの複数の命令を含み、命令の前記第１タイプは、前記コンピュータ・プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含み、命令の前記第２タイプは、前記ＴＡＰを介して前記テストされるシステムをテストするためのテスト命令を含む、コンピュータ・プロセッサ。
  9. テストされるシステムの少なくとも一部のテスト・アクセス・ポート（ＴＡＰ）を介するプロセッサによるテスティングをサポートするために前記プロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法であって、
    前記プロセッサによってサポートされるＩＳＡ命令を含む命令の第１セットを生成するステップと、
    前記ＴＡＰに関連するテスト命令を含む命令の第２セットを生成するステップと、
    命令の前記第１セットおよび命令の前記第２セットを統合し、これによって、テスト命令セット・アーキテクチャ（ＴＩＳＡ）命令のセットを形成するステップと、
    前記ＴＩＳＡ命令を格納するステップ、前記ＴＩＳＡ命令を実行するステップ、または前記ＴＩＳＡ命令を伝搬させるステップのうちの少なくとも１つを実行するステップとを含む、方法。
  10. テストされるシステムをテスト・アクセス・ポート（ＴＡＰ）を介してテストする際の使用のために適合された命令を生成する方法であって、
    組み合わされた命令のセットを生成するステップを含み、前記組み合わされた命令のセットは、
    命令セット・アーキテクチャの複数の命令を含む命令の第１セットと、
    前記ＴＡＰに関連する複数のテスト命令を含む命令の第２セットと、を含み、さらに、
    命令の前記組み合わされたセットを格納するステップ、命令の前記組み合わされたセットを実行するステップ、または命令の前記組み合わされたセットを伝搬させるステップのうちの少なくとも１つを実行するステップを含む、方法。
JP2011553067A 2009-03-04 2010-03-03 複数の命令タイプを使用するシステム・テスティングの方法および装置 Expired - Fee Related JP5489249B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15741209P 2009-03-04 2009-03-04
US61/157,412 2009-03-04
PCT/US2010/026022 WO2010101984A1 (en) 2009-03-04 2010-03-03 Method and apparatus for system testing using multiple instruction types

Publications (2)

Publication Number Publication Date
JP2012519912A true JP2012519912A (ja) 2012-08-30
JP5489249B2 JP5489249B2 (ja) 2014-05-14

Family

ID=42167394

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2011553067A Expired - Fee Related JP5489249B2 (ja) 2009-03-04 2010-03-03 複数の命令タイプを使用するシステム・テスティングの方法および装置
JP2011553072A Expired - Fee Related JP5683502B2 (ja) 2009-03-04 2010-03-03 複数のプロセッサを使用するシステム・テスティングの方法および装置
JP2011553080A Expired - Fee Related JP5684739B2 (ja) 2009-03-04 2010-03-03 スキャン・チェーン分解を使用するシステム・テスティングの方法および装置
JP2013243882A Pending JP2014067436A (ja) 2009-03-04 2013-11-26 複数のプロセッサを使用するシステム・テスティングの方法および装置

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2011553072A Expired - Fee Related JP5683502B2 (ja) 2009-03-04 2010-03-03 複数のプロセッサを使用するシステム・テスティングの方法および装置
JP2011553080A Expired - Fee Related JP5684739B2 (ja) 2009-03-04 2010-03-03 スキャン・チェーン分解を使用するシステム・テスティングの方法および装置
JP2013243882A Pending JP2014067436A (ja) 2009-03-04 2013-11-26 複数のプロセッサを使用するシステム・テスティングの方法および装置

Country Status (6)

Country Link
US (3) US8533545B2 (ja)
EP (3) EP2404184B1 (ja)
JP (4) JP5489249B2 (ja)
KR (5) KR20130100018A (ja)
CN (3) CN102439470B (ja)
WO (3) WO2010101984A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210079348A (ko) * 2019-01-22 2021-06-29 주식회사 아도반테스토 커맨드 오류 처리를 위해 하나 이상의 테스트 대상 디바이스를 테스트하기 위한 자동 테스트 장비, 하나 이상의 테스트 대상 디바이스의 자동 테스트를 위한 방법 및 컴퓨터 프로그램

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7984336B2 (en) * 2006-05-24 2011-07-19 Freescale Semiconductor, Inc. Method and system for storing data from a plurality of processors
US8719649B2 (en) 2009-03-04 2014-05-06 Alcatel Lucent Method and apparatus for deferred scheduling for JTAG systems
US8533545B2 (en) * 2009-03-04 2013-09-10 Alcatel Lucent Method and apparatus for system testing using multiple instruction types
US8572433B2 (en) * 2010-03-10 2013-10-29 Texas Instruments Incorporated JTAG IC with commandable circuit controlling data register control router
US8112669B2 (en) * 2009-08-31 2012-02-07 Comsonics, Inc. Wireless diagnostic system
US20110087861A1 (en) * 2009-10-12 2011-04-14 The Regents Of The University Of Michigan System for High-Efficiency Post-Silicon Verification of a Processor
CN102110037A (zh) * 2009-12-29 2011-06-29 鸿富锦精密工业（深圳）有限公司 电子装置测试系统
US9316690B2 (en) * 2010-03-19 2016-04-19 Qualcomm Incorporated Data recirculation in configured scan paths
US8352791B2 (en) * 2010-06-04 2013-01-08 GM Global Technology Operations LLC Configurable test suite
US8516318B2 (en) * 2010-12-15 2013-08-20 International Business Machines Corporation Dynamic scan
US8570077B2 (en) * 2010-12-17 2013-10-29 Qualcomm Incorporated Methods and implementation of low-power power-on control circuits
US8423343B2 (en) * 2011-01-24 2013-04-16 National Tsing Hua University High-parallelism synchronization approach for multi-core instruction-set simulation
US8677324B2 (en) 2011-01-31 2014-03-18 Hewlett-Packard Development Company, L.P. Evaluating performance of an application using event-driven transactions
CN103458086B (zh) * 2012-06-04 2016-12-14 联想(北京)有限公司 一种智能手机及其故障检测方法
CN102799528B (zh) * 2012-07-12 2015-12-09 中国科学院声学研究所 一种用于电路板级测试的脚本调试方法、装置及其系统
US9121892B2 (en) * 2012-08-13 2015-09-01 Analog Devices Global Semiconductor circuit and methodology for in-system scan testing
TWI461907B (zh) * 2012-10-11 2014-11-21 Mstar Semiconductor Inc 配合多個應用程式之整合系統和測試系統
US9959186B2 (en) * 2012-11-19 2018-05-01 Teradyne, Inc. Debugging in a semiconductor device test environment
CN103092188B (zh) * 2012-12-28 2018-01-12 派芬自控（上海）股份有限公司 一种测试方法及系统
US9183105B2 (en) 2013-02-04 2015-11-10 Alcatel Lucent Systems and methods for dynamic scan scheduling
US9810729B2 (en) * 2013-02-28 2017-11-07 Advantest Corporation Tester with acceleration for packet building within a FPGA block
US9239360B2 (en) * 2014-01-28 2016-01-19 Texas Instruments Incorporated DFT approach to enable faster scan chain diagnosis
US11042929B2 (en) 2014-09-09 2021-06-22 Oracle Financial Services Software Limited Generating instruction sets implementing business rules designed to update business objects of financial applications
CN104749515B (zh) * 2015-03-31 2017-12-15 中国人民解放军国防科学技术大学 一种基于顺序等分分段式的低功耗扫描测试方法和装置
CN105138364B (zh) * 2015-08-21 2019-03-01 Oppo广东移动通信有限公司 一种终端系统升级的方法及装置
US9640280B1 (en) * 2015-11-02 2017-05-02 Cadence Design Systems, Inc. Power domain aware insertion methods and designs for testing and repairing memory
WO2017107125A1 (en) * 2015-12-24 2017-06-29 Intel Corporation Conflict mask generation
WO2017129242A1 (en) * 2016-01-27 2017-08-03 Advantest Corporation Deterministic concurrent test program executor for an automated test equipment
KR102675841B1 (ko) 2016-05-17 2024-06-18 삼성전자주식회사 바이너리 벡터 기반의 테스트 장치
CN109863413B (zh) * 2016-05-20 2022-03-25 默升科技集团有限公司 Serdes应用中基于扫描的测试设计
WO2018089295A1 (en) * 2016-11-08 2018-05-17 Xcerra Corporation Multi-node testing system and method
US10521344B1 (en) * 2017-03-10 2019-12-31 Pure Storage, Inc. Servicing input/output (‘I/O’) operations directed to a dataset that is synchronized across a plurality of storage systems
US10592370B2 (en) * 2017-04-28 2020-03-17 Advantest Corporation User control of automated test features with software application programming interface (API)
CN110658438B (zh) * 2018-06-29 2024-09-17 是德科技股份有限公司 扫描测试系统及其控制装置和控制方法
CN109408382A (zh) * 2018-10-11 2019-03-01 网宿科技股份有限公司 一种持续集成方法和持续集成系统
US11069420B2 (en) 2019-07-25 2021-07-20 Micron Technology, Inc. In-system test of a memory device
CN110634530B (zh) * 2019-09-10 2021-05-25 珠海博雅科技有限公司 芯片的测试系统和测试方法
CN111176961B (zh) * 2019-12-05 2022-03-29 腾讯科技（深圳）有限公司 一种应用程序测试方法、装置及存储介质
CN111209210A (zh) * 2020-01-15 2020-05-29 北京明略软件系统有限公司 一种生成测试用例方法、装置、电子设备及存储介质
US11243252B1 (en) 2020-08-17 2022-02-08 Cisco Technology, Inc. Processor to JTAG test data register interface
CN112100954B (zh) * 2020-08-31 2024-07-09 北京百度网讯科技有限公司 验证芯片的方法、装置和计算机存储介质
CN113342583B (zh) * 2021-06-08 2022-11-29 海光信息技术股份有限公司 芯片验证系统、方法、装置、设备和存储介质
CN113358070B (zh) * 2021-07-07 2023-03-28 苏州鑫睿益荣信息技术有限公司 一种汽车刹车片平整度及销钉高度检测系统及其检测方法
CN113552473B (zh) * 2021-09-22 2021-12-28 北京紫光青藤微系统有限公司 用于芯片测试的系统和待测芯片装置
CN114036885A (zh) * 2021-11-08 2022-02-11 上海兆芯集成电路有限公司 内建自测试的方法及互连接口
CN114416450B (zh) * 2022-01-18 2022-09-27 深圳市百泰实业股份有限公司 一种pcba生产测试管理方法
WO2024186533A1 (en) * 2023-03-08 2024-09-12 Qorvo Us, Inc. Scan test in a single-wire bus circuit

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694399A (en) * 1996-04-10 1997-12-02 Xilinix, Inc. Processing unit for generating signals for communication with a test access port
US20030163773A1 (en) * 2002-02-26 2003-08-28 O'brien James J. Multi-core controller
JP2004280588A (ja) * 2003-03-17 2004-10-07 Cats Kk システムｌｓｉ設計支援装置およびシステムｌｓｉ設計支援プログラム
JP2004310776A (ja) * 2003-04-02 2004-11-04 Microsoft Corp 拡張ランタイムホスティング

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08233904A (ja) * 1995-02-27 1996-09-13 Nec Eng Ltd バウンダリスキャン回路
JPH0926807A (ja) * 1995-07-12 1997-01-28 Keyence Corp プログラマブルコントローラ
US5838568A (en) * 1996-06-28 1998-11-17 International Business Machines Corporation Heated circuit assembly tester and method
US5949692A (en) 1996-08-28 1999-09-07 Synopsys, Inc. Hierarchical scan architecture for design for test applications
US5828579A (en) 1996-08-28 1998-10-27 Synopsys, Inc. Scan segment processing within hierarchical scan architecture for design for test applications
JP3385210B2 (ja) 1998-03-31 2003-03-10 富士通株式会社 テストデータスキャン装置およびスキャン方法
US6061709A (en) 1998-07-31 2000-05-09 Integrated Systems Design Center, Inc. Integrated hardware and software task control executive
US6195774B1 (en) * 1998-08-13 2001-02-27 Xilinx, Inc. Boundary-scan method using object-oriented programming language
US6370664B1 (en) 1998-10-29 2002-04-09 Agere Systems Guardian Corp. Method and apparatus for partitioning long scan chains in scan based BIST architecture
US7392431B2 (en) * 1999-02-19 2008-06-24 Texas Instruments Incorporated Emulation system with peripherals recording emulation frame when stop generated
US7089404B1 (en) * 1999-06-14 2006-08-08 Transmeta Corporation Method and apparatus for enhancing scheduling in an advanced microprocessor
JP2001201543A (ja) * 2000-01-18 2001-07-27 Rooran:Kk スキャン・パス構築用プログラムを記録した記録媒体とスキャン・パスの構築方法及びこのスキャン・パスを組み込んだ演算処理システム
US6453456B1 (en) * 2000-03-22 2002-09-17 Xilinx, Inc. System and method for interactive implementation and testing of logic cores on a programmable logic device
US6640322B1 (en) * 2000-03-22 2003-10-28 Sun Microsystems, Inc. Integrated circuit having distributed control and status registers and associated signal routing means
US6691270B2 (en) 2000-12-22 2004-02-10 Arm Limited Integrated circuit and method of operation of such a circuit employing serial test scan chains
JP3751531B2 (ja) * 2001-03-16 2006-03-01 沖電気工業株式会社 Ｊｔａｇインターフェース回路及びそれを用いたｊｔａｇ対応半導体装置のテスト方法とデバッグ方法
KR100941563B1 (ko) * 2001-10-17 2010-02-10 엔엑스피 비 브이 전자 장치 및 전자 장치의 자동 설정 방법
US6957371B2 (en) 2001-12-04 2005-10-18 Intellitech Corporation Method and apparatus for embedded built-in self-test (BIST) of electronic circuits and systems
US7047462B2 (en) 2002-01-04 2006-05-16 Hewlett-Packard Development Company, Lp. Method and apparatus for providing JTAG functionality in a remote server management controller
JP2003228999A (ja) * 2002-02-01 2003-08-15 Rohm Co Ltd 半導体記憶装置
US7073110B1 (en) 2002-04-26 2006-07-04 Xilinx, Inc. Method and system for programmable boundary-scan instruction register
US7039841B2 (en) 2002-05-08 2006-05-02 Credence Systems Corporation Tester system having multiple instruction memories
US7234092B2 (en) 2002-06-11 2007-06-19 On-Chip Technologies, Inc. Variable clocked scan test circuitry and method
US6832539B2 (en) * 2002-07-15 2004-12-21 Delaware Capital Formation, Inc. Cylinder lock
JP4182202B2 (ja) 2002-08-02 2008-11-19 富士通マイクロエレクトロニクス株式会社 シミュレーション用カバレッジ算出装置及びシミュレーション用カバレッジ算出方法
AU2003275388A1 (en) * 2002-10-01 2004-04-23 Chad Walter Billmyer A system and method for wireless audio communication with a computer
US20040078179A1 (en) * 2002-10-17 2004-04-22 Renesas Technology Corp. Logic verification system
US7539915B1 (en) * 2003-01-07 2009-05-26 Marvell Israel (Misl) Ltd. Integrated circuit testing using segmented scan chains
US7305586B2 (en) 2003-04-25 2007-12-04 International Business Machines Corporation Accessing and manipulating microprocessor state
US7080789B2 (en) * 2003-05-09 2006-07-25 Stmicroelectronics, Inc. Smart card including a JTAG test controller and related methods
US7346821B2 (en) 2003-08-28 2008-03-18 Texas Instrument Incorporated IC with JTAG port, linking module, and off-chip TAP interface
US7149943B2 (en) 2004-01-12 2006-12-12 Lucent Technologies Inc. System for flexible embedded Boundary Scan testing
US7139950B2 (en) * 2004-01-28 2006-11-21 International Business Machines Corporation Segmented scan chains with dynamic reconfigurations
KR100880832B1 (ko) 2004-02-10 2009-01-30 삼성전자주식회사 코-디버깅 기능을 지원하는 반도체 집적회로 및 반도체집적회로 테스트 시스템
GB2411331A (en) 2004-02-19 2005-08-24 Trigenix Ltd Rendering user interface using actor attributes
US7334060B2 (en) 2004-03-19 2008-02-19 International Business Machines Corporation System and method for increasing the speed of serially inputting data into a JTAG-compliant device
US7143324B2 (en) 2004-11-04 2006-11-28 Avago Technologies General Ip (Singapore) Pte. Ltd. System and method for automatic masking of compressed scan chains with unbalanced lengths
JP2006146757A (ja) 2004-11-24 2006-06-08 Toshiba Corp デバッグ用レジスタおよびデータ転送方法
US7206983B2 (en) 2005-03-31 2007-04-17 Lsi Logic Corporation Segmented addressable scan architecture and method for implementing scan-based testing of integrated circuits
US7383478B1 (en) * 2005-07-20 2008-06-03 Xilinx, Inc. Wireless dynamic boundary-scan topologies for field
US7844721B2 (en) 2005-11-23 2010-11-30 Qualcomm Incorporated Method for delivery of software upgrade notification to devices in communication systems
JP2007147352A (ja) 2005-11-25 2007-06-14 Sony Corp 無線インターフェースモジュール及び電子機器
JP4805134B2 (ja) * 2006-12-28 2011-11-02 富士通株式会社 集積回路の内部ラッチをスキャンする方法及び装置並びに集積回路
JP2008165534A (ja) * 2006-12-28 2008-07-17 Oki Electric Ind Co Ltd 半導体装置
US8015462B2 (en) * 2007-05-11 2011-09-06 Renesas Electronics Corporation Test circuit
US8418008B2 (en) * 2008-12-18 2013-04-09 Lsi Corporation Test technique to apply a variable scan clock including a scan clock modifier on an integrated circuit
US8533545B2 (en) * 2009-03-04 2013-09-10 Alcatel Lucent Method and apparatus for system testing using multiple instruction types
US8621301B2 (en) 2009-03-04 2013-12-31 Alcatel Lucent Method and apparatus for virtual in-circuit emulation
US8055948B2 (en) * 2009-09-14 2011-11-08 International Business Machines Corporation Resilient software-controlled redundant array of independent disks (RAID)

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5694399A (en) * 1996-04-10 1997-12-02 Xilinix, Inc. Processing unit for generating signals for communication with a test access port
US20030163773A1 (en) * 2002-02-26 2003-08-28 O'brien James J. Multi-core controller
JP2004280588A (ja) * 2003-03-17 2004-10-07 Cats Kk システムｌｓｉ設計支援装置およびシステムｌｓｉ設計支援プログラム
JP2004310776A (ja) * 2003-04-02 2004-11-04 Microsoft Corp 拡張ランタイムホスティング

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210079348A (ko) * 2019-01-22 2021-06-29 주식회사 아도반테스토 커맨드 오류 처리를 위해 하나 이상의 테스트 대상 디바이스를 테스트하기 위한 자동 테스트 장비, 하나 이상의 테스트 대상 디바이스의 자동 테스트를 위한 방법 및 컴퓨터 프로그램
KR102569335B1 (ko) 2019-01-22 2023-08-22 주식회사 아도반테스토 커맨드 오류 처리를 위해 하나 이상의 테스트 대상 디바이스를 테스트하기 위한 자동 테스트 장비, 하나 이상의 테스트 대상 디바이스의 자동 테스트를 위한 방법 및 컴퓨터 프로그램

Also Published As

Publication number Publication date
EP2404184A1 (en) 2012-01-11
EP2404182B1 (en) 2014-05-21
WO2010101995A1 (en) 2010-09-10
EP2404183A1 (en) 2012-01-11
JP5684739B2 (ja) 2015-03-18
CN102341718B (zh) 2015-05-20
US20100229058A1 (en) 2010-09-09
JP5489249B2 (ja) 2014-05-14
CN102439470B (zh) 2014-07-16
KR20120023601A (ko) 2012-03-13
JP2012519854A (ja) 2012-08-30
KR20130100018A (ko) 2013-09-06
WO2010102019A8 (en) 2010-11-18
JP2014067436A (ja) 2014-04-17
KR20130081717A (ko) 2013-07-17
KR20110124274A (ko) 2011-11-16
EP2404183B1 (en) 2014-08-13
KR101533170B1 (ko) 2015-07-02
WO2010101984A1 (en) 2010-09-10
CN102341718A (zh) 2012-02-01
JP5683502B2 (ja) 2015-03-11
KR101329465B1 (ko) 2013-11-13
EP2404182A1 (en) 2012-01-11
KR101489550B1 (ko) 2015-03-24
CN102341719A (zh) 2012-02-01
US20100229036A1 (en) 2010-09-09
US20100229042A1 (en) 2010-09-09
WO2010102019A1 (en) 2010-09-10
US8533545B2 (en) 2013-09-10
KR20110122165A (ko) 2011-11-09
CN102439470A (zh) 2012-05-02
CN102341719B (zh) 2015-04-01
JP2012519853A (ja) 2012-08-30
US8677198B2 (en) 2014-03-18
EP2404184B1 (en) 2013-10-02

Similar Documents

Publication Publication Date Title
JP5489249B2 (ja) 複数の命令タイプを使用するシステム・テスティングの方法および装置
JP5570662B2 (ja) 仮想インサーキット・エミュレーションの方法および装置
US8719649B2 (en) Method and apparatus for deferred scheduling for JTAG systems
US8775884B2 (en) Method and apparatus for position-based scheduling for JTAG systems

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20120713

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130222

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130305

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130605

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140123

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140220

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140221

R150 Certificate of patent or registration of utility model

Ref document number: 5489249

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees