JP5570662B2 - 仮想インサーキット・エミュレーションの方法および装置 - Google Patents

仮想インサーキット・エミュレーションの方法および装置 Download PDF

Info

Publication number
JP5570662B2
JP5570662B2 JP2013518437A JP2013518437A JP5570662B2 JP 5570662 B2 JP5570662 B2 JP 5570662B2 JP 2013518437 A JP2013518437 A JP 2013518437A JP 2013518437 A JP2013518437 A JP 2013518437A JP 5570662 B2 JP5570662 B2 JP 5570662B2
Authority
JP
Japan
Prior art keywords
tisa
scan
test
processor
ice
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.)
Expired - Fee Related
Application number
JP2013518437A
Other languages
English (en)
Other versions
JP2013537662A (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 JP2013537662A publication Critical patent/JP2013537662A/ja
Application granted granted Critical
Publication of JP5570662B2 publication Critical patent/JP5570662B2/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
    • 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/318544—Scanning methods, algorithms and patterns
    • 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/3177—Testing of logic operation, e.g. by logic analysers
    • 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
    • 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/318572—Input/Output interfaces

Landscapes

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

Description

関連出願の相互参照
本願は、それぞれが２００９年３月４日に出願した米国特許仮出願第６１／１５７４１２号、名称「ＴＥＳＴ ＩＮＳＴＲＵＣＴＩＯＮ ＳＥＴ ＡＲＣＨＩＴＥＣＴＵＲＥ」の利益を主張する、それぞれ２００９年６月３０日に出願した、米国特許出願第１２／４９５２３７号、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＳＹＳＴＥＭ ＴＥＳＴＩＮＧ ＵＳＩＮＧ ＭＵＬＴＩＰＬＥ ＩＮＳＴＲＵＣＴＩＯＮ ＴＹＰＥＳ」（代理人整理番号第ＡＬＵ／１３０１３７号）、米国特許出願第１２／４９５２９５号、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＳＹＳＴＥＭ ＴＥＳＴＩＮＧ ＵＳＩＮＧ ＭＵＬＴＩＰＬＥ ＰＲＯＣＥＳＳＯＲＳ」（代理人整理番号第ＡＬＵ／１３０１３７−２号）、および米国特許出願第１２／４９５３３６号、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＳＹＳＴＥＭ ＴＥＳＴＩＮＧ ＵＳＩＮＧ ＳＣＡＮ ＣＨＡＩＮ ＤＥＣＯＭＰＯＳＩＴＩＯＮ」（代理人整理番号第ＡＬＵ／１３０１３７−３号）の一部継続出願であり、それらの出願は参照により全体が本明細書に組み込まれる。
本発明は、組込みシステムの分野に関し、排他的ではなくより具体的には、インサーキット・エミュレーション（ＩＣＥ）を使用する組込みシステムのテスティングに関する。
組込みシステムのテスティングでは、インサーキット・エミュレーション（ＩＣＥ）が、１つまたは複数のプロセッサ上で動作する組込みソフトウェアをデバッグするのに使用される技法である。ＩＣＥでは、組込みソフトウェアは、通常、デバッギング・インフラストラクチャを使用して（たとえば、ＧＮＵ Ｄｅｂｕｇｇｅｒ（ＧＤＢ）などのデバッガを使用して）デバッグされる。ＩＣＥでは、プロセッサのコンポーネントをＪＴＡＧインフラストラクチャに接続することができ、その結果、デバッガは、リモート・プログラム実行の知識を得るためにコンポーネントにアクセスし、必要に応じてリモート・プログラム実行を変更できるようになる。たとえば、デバッガは、レジスタ（たとえば、状態レジスタおよびユーザ・レジスタ）、ウォッチポイント、メモリ・バンク、クロック制御ブロック、および他の要素の知識を得ることができる。これは、ソフトウェアをその最終的な環境でデバッグするための強力な機構を提供するが、ＪＴＡＧの実際の特徴によって抑制される。たとえば、所与のプロセッサ・コア用の通常のＩＣＥが、数十個の要素にアクセスする必要がある場合があり、既存の組込み設計が、多数のプロセッサ・コアからなる場合がある。その結果、ＪＴＡＧ動作の効率的なハンドリングは、重要であり、最も単純なデバッグ動作を実行するためでさえ、必要なかなりの個数のアクセスを考慮すると、困難な問題を提示する。
既存のＪＴＡＧベースのＩＣＥ機能は、複数の形で不完全である。第１に、既存のＩＣＥ解決策は、一時に１つのＪＴＡＧ ＩＣＥインターフェースだけの使用を要求する（または、複数のＩＣＥインターフェースが同一のターゲット・ボード上に共存することを可能にするために、プロセッサ・コアごとに特殊な分離ロジックを必要とする）。第２に、既存のＩＣＥ解決策は、ＪＴＡＧ動作のハンドリングのためにテスト生成ツール（ＴＧＴ）に強く頼り、ＴＧＴは、プロセッサ・コアを囲むスキャン・チェーンのトポロジを指定するためにユーザ入力に強く頼る。実際には、既存のＩＣＥ解決策で、ＪＴＡＧ動作は、デバイス内部の知識がない場合に、ベクトル・レベルでのみ行うことができる。第３に、既存のＩＣＥ解決策は、通常、ターゲット・ボードのコンポーネントにアクセスするためにバウンダリ・スキャン・アクセスに頼り、これによって、実行されるテスティングに関わりなく完全なテスティング・ベクトル（ｔｅｓｔｉｎｇ ｖｅｃｔｏｒ）の生成を必要とし、さらに、複数のデバイスがバウンダリ・スキャン・チェーン内に存在する時には、テスティング・ベクトルの再ターゲティングを必要とする。そのような不足の結果として、ＴＧＴは、要求されるベクトルを生成でき、結果を解釈し、復号できるために、システムの完全だが単純化されたモデルを維持しなければならない。不利なことに、これは、かなりの量の計算能力を要求し、これによって、特にリソースを制約された組込み手法について、この解決策のスケーラビリティを制限する。さらに、組込みコントローラは、基本的な入出力解決策だけを実行でき、ＴＧＴを実行するために強力なホスト・コンピュータを参照しなければならず、ＴＧＴとのインターフェースは、通常、ベンダ依存であり、プロプライエタリであり、これによって、追加のコストおよび柔軟性の消失をもたらす。したがって、既存のＩＣＥ解決策は、ＩＣＥの複数のインスタンスをサポートすることを事実上不可能にする。
既存のＩＣＥ機能は、複数のプロセッサ・コアを効率的に同時にサポートできないという点で、さらに不完全である。既存のＩＣＥ解決策では、複数のプロセッサ・コアにについて同時にＩＣＥをサポートするために、実質的により複雑なＴＧＴおよび関連するモデルが、ホスト・マシン上で動作するＩＣＥインスタンスのそれぞれによるコマンド要求の調整をサポートするために必要である。これは、各スキャン動作の間でそのトポロジを変化させる可能性があるスキャン・チェーン全体の展望に基づく再ターゲティングというかなりの厄介な作業を伴う、すなわち、ターゲット・ハードウェアに送られるデータは、各スキャン動作の間で可変長ビット・ストリームである。これは、ターゲット・ハードウェアのスキャン・チェーンに適用され、これから回復されるデータ・ベクトルの固定長ビット・ストリーム表現を仮定する既存ＴＧＴによって簡単には達成されない。既存のＩＣＥ機能は、複数のプロセッサ・コアを同時に効率的にサポートできないという点で不完全であるが、単一のターゲット・プロセッサ内の複数のプロセッサ・コアにアクセスするための潜在的な解決策は、ＩＥＥＥ １１４９．７標準規格であり、これは、ターゲット・プロセッサにアクセスするためにデバッガによって使用できる、各プロセッサ・コアへの標準化されたＩＣＥ−ＪＴＡＧインターフェースを提案するものである。しかし、不利なことに、ＴＧＴを介してベクトルを扱うことに伴う複雑さは、並列性のサポートを完全に除外することを含めて、ＩＥＥＥ １１４９．７標準規格を用いて実施できる特徴を厳しく制限する。
ＩＥＥＥ １１４９．７標準規格 ＩＥＥＥ １１４９．１標準規格 「Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ Ｖｅｒｓｉｏｎ ８」、ＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ刊、１９９２年 「Ｓｅｒｉａｌ Ｖｅｃｔｏｒ Ｆｏｒｍａｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ＡＳＳＥＴ ＩｎｔｅｒＴｅｃｈ，Ｉｎｃ．、１９９７年 ＩＥＥＥ Ｐ１６８７標準規格
従来技術のさまざまな不足は、仮想インサーキット・エミュレーション（ＩＣＥ）を提供する方法および装置を介して対処される。
一実施形態では、方法は、少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、複数のターゲットＩＣＥコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させるステップとを含む。
本明細書で提示される教示は、添付図面に関連して次の詳細な説明を検討することによってたやすく理解することができる。
テスティング・システムおよびテストされるシステム（ｓｙｓｔｅｍ ｕｎｄｅｒ ｔｅｓｔ）を含むシステム・テスティング環境を示す高水準ブロック図である。 テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態を示す高水準ブロック図である。 テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態を示す高水準ブロック図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の命令コーディングの詳細を示す、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の例示的なＴＩＳＡアーキテクチャのシステム・テスト環境を示す図である。 ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様の例示的なＴＩＳＡアーキテクチャのシステム・テスト環境で使用するＣコマンドからＴＩＳＡコーディングへのマッピングを示す図である。 対話型テスティング機能をサポートするＴＩＳＡベースのテスティング環境の実施形態を示す図である。 図６のＴＩＳＡベースのテスティング環境の例示的実施態様を示す図である。 図５Ａのテストされるシステムの送信器−受信器チャネルの最適化を実行する例示的なプログラム・アーキテクチャを示す図である。 テスト命令セット・アーキテクチャ（Ｔｅｓｔ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＴＩＳＡ）フローを形成するためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）を適合させる方法の一実施形態を示す図である。 テストされるシステムの少なくとも一部のテスティングで使用されるように適合された命令を生成する方法の一実施形態を示す図である。 テストされるシステムの少なくとも一部のテスティングで使用されるように適合された命令を生成する方法の一実施形態を示す図である。 テストされるシステムの少なくとも一部のテスティングで使用されるように適合された命令を生成する方法の一実施形態を示す図である。 ＴＩＳＡプロセッサ・アーキテクチャの例示的実施形態を示す図である。 システム・テスティング機能を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す図である。 テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す図である。 テスト付属プロセッサ（ｔｅｓｔ ａｄｊｕｎｃｔ ｐｒｏｃｅｓｓｏｒ）アーキテクチャの例示的実施形態を示す図である。 ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す図である。 ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す図である。 ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す図である。 ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す図である。 テストされるシステムの例示的なスキャン・チェーンの例示的分解を示す、テストされるシステムを示す高水準ブロック図である。 スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用して、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態を示す高水準ブロック図である。 ターゲット・ハードウェアのテスティングで使用されるように構成された仮想ＩＣＥドライバを含むシステムの一実施形態を示す高水準ブロック図である。 ターゲット・ハードウェアをテストするのに仮想ＩＣＥドライバを使用する方法の一実施形態を示す図である。 本明細書で説明する機能を実行する際の使用に適するコンピュータを示す高水準ブロック図である。
理解を容易にするために、可能な場合には、同一の符号が、複数の図面に共通する同一の要素を指定するのに使用された。
さまざまなテスティング機能が、テストされるシステム（ＳＵＴ）のテスティングを実行する際の使用のために提供される。
一実施形態では、テスト命令セット・アーキテクチャ（ＴＩＳＡ）が提供される。ＴＩＳＡは、システム・テスティングを実行する際に使用するために提供される。ＴＩＳＡは、対話テスティング機能、リモート・テスティング機能、および本明細書で説明するさまざまな他の機能を含む改善されたシステム・テスティング機能を提供するために、コンピュータ・サイエンス機能をシステム・テスティング機能と組み合わせる。ＴＩＳＡは、システム・テスティング機能を使用してソフトウェア・ベースの命令セット・アーキテクチャ（ＩＳＡ）を適合させることによって形成される。ソフトウェア・ベースのＩＳＡは、任意の適切なソフトウェア・プログラミング言語（たとえば、Ｃ＋＋、Ｊａｖａ、および類似物、ならびにそのさまざまな組合せ）を利用することができ、任意の適切なプロセッサを使用して実施され得る。システム・テスティング機能は、ＩＥＥＥ １１４９．１（ＪＴＡＧとしても知られる）ＴＡＰまたは任意の他の適切なＴＡＰなどの任意の適切なＴＡＰを利用することができる。一般に、ＴＩＳＡは、ソフトウェア・プロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成される。ＴＩＳＡでは、テスト手順のアルゴリズム部分が、ソフトウェア・フローによって処理され、テスト手順のアルゴリズム部分が原子的テスティング動作に変換されるようになっている。ＴＩＳＡは、ソフトウェア・プロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成され、原子的テスティング動作が、テスト手順のアルゴリズム部分を処理しているソフトウェア・プロセスの原子的動作と同一の形で扱われるようになっている。これは、組込みテスト実行、リモート・テスト実行、および図示され本明細書で説明されるさまざまな他の改善されたシステム・テスティング機能のより細粒度の制御を可能にする。
図１に、テスティング・システムとテストされるシステムとを含むシステム・テスティング環境の高水準ブロック図を示す。
図１に示されているように、システム・テスティング環境１００は、テスティング・システム（ＴＳ）１１０およびテストされるシステム（ＳＵＴ）１２０を含む。
ＴＳ １１０は、ＳＵＴ １２０をテストするのに適する任意のシステムとすることができる。ＴＳ １１０は、ＳＵＴ １２０をテストするために構成される。ＴＳ １１０は、ＳＵＴ １２０の任意のテスティング、たとえば、ＳＵＴ １２０の１つまたは複数の個々のコンポーネント、ＳＵＴ １２０のコンポーネントの１つまたは複数の組合せ、ＳＵＴ １２０のコンポーネントの間の１つまたは複数の相互接続、ＳＵＴ １２０の１つまたは複数のシステム・レベル機能、および類似物、ならびにそのさまざまな組合せのテスティングを実行することができる。ＴＳ １１０は、テスト手順の実行、テストされるシステムへの入力データの供給、テストされるシステムからの出力データの受取、システム・テスティング結果を判定するためのテストされるシステムから受け取られた出力データの処理、および同様の機能、ならびにそのさまざまな組合せなど、通常はテストされるシステムのテスティングに関連する機能のいずれをも実行することができる。テストされるシステムをテストするためのＴＳ １１０の設計および使用を、下でさらに詳細に説明する。
ＳＵＴ １２０は、ＴＳ １１０を使用してテストすることのできる任意のシステムとすることができる。ＳＵＴ １２０は、その少なくとも一部をＴＳ １１０によって個別におよび／または組み合わせてテストできる任意のコンポーネント（１つまたは複数）を含むことができる。ＴＳ １１０は、ＳＵＴ １２０によってテストされるコンポーネント（１つまたは複数）へのアクセスを提供する関連する入力アクセス・ピンおよび出力アクセス・ピンの１つまたは複数のセットを有する１つまたは複数のスキャン・チェーンを含むことができる。スキャン・チェーン（１つまたは複数）をＳＵＴ １２０をテストするためにＳＵＴ １２０内で利用できる形は、当業者によって了解されるであろう。たとえば、ＳＵＴ １２０は、１つまたは複数の基板を含むことができ、この基板のテスティングは、ＳＵＴ １２０に入力テスティング信号を印加し、ＳＵＴ １２０から出力テスティング信号を収集するために使用できる関連する入力アクセス・ピンおよび出力アクセス・ピンを有する１つまたは複数のスキャン・チェーンを使用して実行することができる。
図１に示されているように、ＴＳ １１０は、テスト・アクセス・インターフェース（ＴＡＩ）１１５を介してＳＵＴ １２０にアクセスする。テスト・アクセス・インターフェースを、任意の適切なテスト・アクセス・インターフェースを使用して実施することができ、このテスト・アクセス・インターフェースは、ＴＳ １１０、ＳＵＴ １２０、実行されるテスティングのタイプ、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数に依存するものとすることができる。
たとえば、ＴＡＩ １１５は、参照によってその全体が本明細書に組み込まれているＩＥＥＥ １１４９．１標準規格で標準化されているＪｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ（ＪＴＡＧ）テスト・アクセス・ポート（Ｔｅｓｔ Ａｃｃｅｓｓ Ｐｏｒｔ、ＴＡＰ）を含むことができる。ＩＥＥＥ １１４９．１標準規格は、Ｔｅｓｔ Ｄａｔａ Ｉｎ（ＴＤＩ）、Ｔｅｓｔ Ｄａｔａ Ｏｕｔ（ＴＤＯ）、Ｔｅｓｔ Ｍｏｄｅ Ｓｅｌｅｃｔ（ＴＭＳ）、Ｔｅｓｔ Ｃｌｏｃｋ（ＴＣＫ）、および、オプションでＴｅｓｔ Ｒｅｓｅｔ Ｓｉｇｎａｌ（ＴＲＳＴ）という信号のセットをサポートするＴＡＰを定義する。ＳＵＴ １２０のＴＤＩピンおよびＴＤＯピンは、ＴＳ １１０がＳＵＴ １２０の少なくとも一部をテストするためにＳＵＴ １２０にそれによってアクセスできるバウンダリ・スキャン・チェーン内で相互接続される。
ＴＡＩ １１５は、任意の他の適切なテスト・アクセス・インターフェースを含むことができる。
当業者は、ＴＳ １１０、ＴＡＩ １１５、およびＳＵＴ １２０を、本明細書に含まれる実施形態の特徴を提供するのに適する任意の形で実施できることを了解するであろう。
本明細書で説明するように、ＴＩＳＡは、システム・テスティングにおける大きい改善を提供するためにシステム・テスティング機能と組み合わせてコンピュータ・サイエンス機能を活用することができる。システム・テスティング機能およびコンピュータ・サイエンス機能の全般的な説明がこれに続き、コンピュータ・サイエンス機能およびシステム・テスティング機能を一緒に利用してＴＩＳＡを提供する形の説明がそれに続く。
ＴＩＳＡは、コンピュータ・サイエンス機能を活用することによってシステム・テスティング機能を改善する。システム・テスティング機能は、「自動化テスト」フロー（一般に、テスト・アルゴリズム（１つまたは複数）の定義から実際のテスティング動作に達するのに必要である可能性があるステップおよびリソースのすべてを含む）のすべてのステージで一般にサポートされる機能を含むことができる。
テスト自動化を助けるために、テスト・リソースは、しばしば、基板およびデバイスの内部に組み込まれ、通常はテスト・アクセス・ポート（ＴＡＰ）と呼ばれる標準化されたインターフェースを使用してアクセスされ得る。これは、ピン・カウントを制限し、リソース・アクセスおよび管理を合理化するという効果を有する。複数の言語が、テストされるシステムの内部のリソースを記述するのに使用可能であり、したがって、これをテスト生成ツール（ＴＧＴ）への入力として使用することができる。ＴＧＴは、ＴＡＰに指令し、関連するテスティング動作を実行するのにテスト制御ユニット（Ｔｅｓｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、ＴＣＵ）によって使用できるテスティング・シーケンスを生成するためにアルゴリズムを適用することができる。テスティング動作の特徴および性能は、３つの要素すなわち、アクセス標準規格、データ・フォーマット、およびＴＣＵ実施態様に依存する。
ＴＩＳＡは、改善されたシステム・テスティング機能を提供するためにコンピュータ・サイエンス機能を活用することができる。これは、「ソフトウェア開発フロー」（一般に、コンパイル、命令セット・アーキテクチャ（ＩＳＡ）、対話デバッギング、および類似物、ならびにそのさまざまな組合せなど、選ばれたソフトウェア言語（１つまたは複数）でコーディングされたソフトウェア・アルゴリズムからターゲット・プロセッサ上での最終的なデバッギングおよび実行に達するのに必要である可能性があるステップおよびリソースのいずれかまたはすべてを含む）のすべてのステージで使用可能なコンピュータ・サイエンス機能の使用を含むことができる。
コンピュータ・サイエンスでのコンパイルの使用は、プログラマフレンドリな高水準抽象化で定義されたアルゴリズムを一連の機械実行可能命令に変形する。このプロセスは、入力プログラミング言語およびプロジェクトの複雑さに依存して大幅に変化する可能性があるが、手法のすべてではないにせよほとんどが、すべてのアルゴリズムをその複雑さに関わりなく基本的な命令に分解できるという同一の基本的な仮定を共有する。これは、古典的な言語ならびにたとえばＣ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、および類似物などのより近代的な高水準言語およびオブジェクト指向言語にあてはまる。
命令セット・アーキテクチャ（ＩＳＡ）は、すべてのプロセッサの核であり、その理由は、コンパイルが非常に有効であることである。一般に、各プロセッサは、そのプロセッサを操作できる形を定義する命令のセットを提供する。これらの命令は、そのプロセッサのＩＳＡの少なくとも一部を形成する。ＩＳＡを、レジスタ、アドレッシング・モード、オペコード、メモリ構造、および類似物、ならびにそのさまざまな組合せなど、命令に関連するさまざまな構造を含むと考えることができることを了解されたい。ＩＳＡは、プロセッサが、メモリから／への値の読取／書込などの単純な命令を実行し、レジスタに対する論理演算または算術演算を実行し、割込みを処理することなどを可能にする。この基本的な挙動は、経時的に本質的に変更されないままであり、現代のプロセッサは、非常に多くのリソースを効率的に活用できるので例外的な性能を達成し、したがって、ほぼ同一の時間ではるかに多数のそのような基本的な命令を完了することができる。さらに、コプロセッサ（たとえば、浮動小数点コプロセッサ、グラフィカル・コプロセッサ、および類似物）の使用から、さらにより高い性能に達することができ、このコプロセッサは、複雑な動作をハード・コーディングすることによってメイン・プロセッサを助けることができる。
コンピュータ・サイエンスでのデバッギングの使用は、ソフトウェア開発および実行プロセスの監視および検証を可能にする。一般に、ソフトウェア開発は、長くむずかしいプロセスであり、このプロセスは、最終製品が誤りまたは通常呼ばれるように「バグ」がないことを保証するために厳格に監視され、検証される。ソフトウェア・プログラムをテストするのを助けるために、ソフトウェア開発フローは、多数の強力なデバッグ機能を提供する。たとえば、一般的なソフトウェア開発フロー・デバッグ機能は、ステップバイステップ実行、すべてのレジスタおよびメモリ位置の観察可能性／制御可能性、ブレークポイントおよびウォッチポイントの使用、ならびに類似物を含む。これらのデバッグ機能ならびにさまざまな他のデバッグ機能は、よりしばしば、ソフトウェア・コンパイラによって最終コードに埋め込まれるアルゴリズムおよび構造によって使用可能にされるが、プロセッサの内部で使用可能なハードウェア・リソースによって支援することもできる。この情報から、デバッガは、オリジナル・コードを再構成し、すべてのＩＳＡレベル動作をプログラミング抽象化レイヤに相関させることができる。
改善されたシステム・テスティング機能を使用可能にするために自動化テスト実行機能およびコンピュータ・サイエンス・ソフトウェア機能を一緒に使用することは、図２および図３を参照することによってよりよく理解することができる。
図２に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態の高水準ブロック図を示す。
図２に示されているように、ＴＳ １１０は、テスト生成ツール（ＴＧＴ）２１０およびソフトウェア・コンパイラ（ＳＣ）２２０を含む。
ＴＧＴ ２１０は、ＴＧＴコンポーザ２１２およびＴＧＴアルゴリズム２１４を含む。
ＴＧＴコンポーザ２１２は、入力としてシステム記述ファイル２１１を受け入れる。システム記述ファイル２１１は、テストされるシステムをテストするためのテスティング命令／ベクトルを作るのにＴＧＴによって使用できる任意の適切な記述ファイルを含むことができる。たとえば、システム記述ファイル２１１は、回路記述ファイル、基板／治具ネットリスト・ファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。システム記述ファイル２１１を、ＴＧＴ ２１０上で使用可能とすることができ、かつ／または１つもしくは複数のリモート・コンポーネントおよび／もしくはシステムから入手することができる。
システム記述ファイル２１１は、１つまたは複数の回路記述ファイルを含むことができる。回路記述ファイルは、Ｂｏｕｎｄａｒｙ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＢＳＤＬ、基板レベルＪＴＡＧに関するＩＥＥＥ １１４９．１標準規格の一部として開発された）、Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＨＳＤＬ、ＢＳＤＬの拡張として開発された）、Ｎｅｗ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＮＳＤＬ）、および類似物ならびにそのさまざまな組合せなど、任意の適切な記述言語（１つまたは複数）を使用して指定することができる。
システム記述ファイル２１１は、１つまたは複数の基板／治具ネットリスト・ファイルを含むことができる。基板／治具ネットリスト・ファイルは、ネットリスト、接続、および類似する情報を記述する、デバイス（１つまたは複数）の物理記述に関係するファイルを含むことができる。基板／治具ネットリスト・ファイルは、ＰＣＢ、Ｇｅｒｂｅｒ、および／または基板／治具ネットリスト・ファイルに適する任意の他のフォーマットなど、任意の適切なフォーマットで指定することができる。
システム記述ファイル２１１は、１つまたは複数の他の記述ファイルを含むことができる。他の記述ファイルは、回路モデルを作るための入力として使用できる任意の他の適切な記述ファイルを含むことができる。たとえば、他の記述ファイルは、Ａｓｓｅｔ社のＭａｃｒｏ Ｌａｎｇｕａｇｅ、Ｇｏｅｐｅｌ社のＣＡＳＬＡＮ言語、および／または任意の他の適切な記述言語ファイルなど、任意の適切なアプリケーション固有および／またはツール固有の記述言語ファイルを含むことができる。
ＴＧＴコンポーザ２１２は、システム記述ファイル２１１を処理して回路モデル２１３を作る。回路モデル２１３を作るためのＴＧＴコンポーザ２１２によるシステム記述ファイル２１１の処理は、任意の適切な形で実行することができる。回路モデル２１３は、テストされるシステムまたはテストされるシステムのうちでＴＧＴ ２１０がそれのために実行されつつある部分のモデルを指定する。ＴＧＴコンポーザ２１２は、回路モデル２１３をＴＧＴアルゴリズム２１４に供給する。
ＴＧＴアルゴリズム２１４は、回路モデル２１３を受け入れる。ＴＧＴアルゴリズム２１４は、回路モデル２１３を処理して、ＴＧＴ原子的テスト動作２１６を作る。ＴＧＴ原子的テスト動作２１６を作るためのＴＧＴアルゴリズム２１４による回路モデル２１３の処理は、任意の適切な形で実行することができる。
ＳＣ ２２０は、ＳＣフロントエンド・アルゴリズム２２２およびＳＣバックエンド・アルゴリズム２２４を含む。
ＳＣフロントエンド・アルゴリズム２２２は、入力としてコンピュータ・サイエンス・ソース・ファイル２２１を受け入れる。コンピュータ・サイエンス・ソース・ファイル２２１は、コンパイラによってコンパイルできる任意の適切なコンピュータ・サイエンス・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル２２１は、Ｃ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語（１つまたは複数）のコンピュータ・サイエンス・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル２２１は、１つもしくは複数のＣファイル、１つもしくは複数のＣ＋＋ファイル、および／または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの１つまたは複数を含むことができる。
ＳＣフロントエンド・アルゴリズム２２２は、コンピュータ・サイエンス・ソース・ファイル２２１を処理してプログラム・モデル２２３を作る。プログラム・モデル２２３は、コンピュータ・サイエンス・ソース・ファイル２２１の中間表現を指定する。ＳＣフロントエンド・アルゴリズム２２２は、プログラム・モデル２２３をＳＣバックエンド・アルゴリズム２２４に供給する。
ＳＣバックエンド・アルゴリズム２２４は、入力としてプログラム・モデル２２３を受け入れる。ＳＣバックエンド・アルゴリズム２２４は、プログラム・モデル２２３を処理して、ＩＳＡ原子的動作２２６を含む１つまたは複数のＩＳＡ２進ファイル２２５を作る。ＩＳＡ原子的動作２２６を含むＩＳＡ２進ファイル２２５を形成するためのＳＣバックエンド・アルゴリズム２２４によるプログラム・モデル２２３の処理は、任意の適切な形で実行することができる。ＩＳＡ原子的動作２２６は、ＴＩＳＡがそれのために実施されるプロセッサによってサポートされるアセンブリレベル命令である。
図２に示されているように、ＴＧＴ ２１０およびＳＣ ２２０のそれぞれの処理フローに加えて、ＴＧＴ ２１０とＳＣ ２２０との間の追加の相互作用を、ＴＩＳＡ原子的動作２３５の生成を制御するのに利用することができる。一実施形態では、ＳＣバックエンド・アルゴリズム２２４は、ＴＧＴアルゴリズム２１４への１つまたは複数のベクトル計算要求２３０を開始することができる。ＳＣバックエンド・アルゴリズム２２４は、ＳＣバックエンド・アルゴリズムがＴＡＰにアクセスすることを必要とする時に、ベクトル計算要求２３０を開始することができる。ＴＧＴアルゴリズム２１４は、ＳＣバックエンド・アルゴリズム２２４からベクトル計算要求２３０を受け取った時に、受け取られたベクトル計算要求２３０に基づいてＴＡＰに関する１つまたは複数のＴＧＴ原子的テスト動作２１６を生成する。次に、１つまたは複数のＴＧＴ原子的テスト動作２１６を、ＳＣバックエンド・アルゴリズム２２４によって制御される形でＴＡＰに適用することができる。というのは、ＴＧＴ原子的テスト動作２１６が、ＩＳＡ原子的動作２２６と組み合わされて、ＩＳＡ原子的動作２２６を使用するＴＧＴ原子的テスト動作２１６に対するアルゴリズム的制御を可能にするからである。この形で、ＳＣ ２２０は、ＴＡＰへのアクセスのアルゴリズム的制御を提供する。
図２に示されているように、ＴＧＴ ２１０およびＳＣ ２２０に加えて、ＴＳ １１０は、さらに、ＴＩＳＡコンポーザ２４０を含む。ＴＩＳＡコンポーザ２４０は、ＴＧＴ原子的テスト動作２１６およびＩＳＡ原子的動作２２６を受け入れる。ＴＩＳＡコンポーザ２４０は、ＴＧＴ原子的テスト動作２１６をＴＩＳＡ命令に変換し、それらのＴＩＳＡ命令をＩＳＡ２進ファイル（１つまたは複数）２２５に挿入する（すなわち、ＴＩＳＡ命令をＩＳＡ原子的動作２２６と組み合わせて、これによって、ＴＩＳＡ原子的動作２４６を含むＴＩＳＡ２進ファイル２４５を形成する）。ＴＩＳＡコンポーザ２４０は、ＴＧＴ ２１０の一部とするか、ＳＣ ２２０の一部とするか、ＴＧＴ ２１０およびＳＣ ２２０にまたがって分割されるか、ＴＧＴ ２１０およびＳＣ ２２０とは別々に実施されるものなどとすることができる。
図２に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬さ せ、かつ／または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
図３に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図１のテスティング・システムの一実施形態の高水準ブロック図を示す。
図３に示されているように、図３のＴＳ １１０は、ＴＩＳＡ原子的動作を含むＴＩＳＡ２進ファイルがテスト生成ツールとソフトウェア・コンパイラとの間の相互作用を使用して生成されるという点で、図２のＴＳ １１０に似た形で動作する。しかし、図３のＴＳ １１０でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用は、図２のＴＳ １１０でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用とは異なる。
図３に示されているように、ＴＳ １１０は、テスト生成ツール（ＴＧＴ）３１０およびソフトウェア・コンパイラ（ＳＣ）３２０を含む。
ＴＧＴ ３１０は、ＴＧＴコンポーザ３１２およびＴＧＴアルゴリズム３１４を含む。
ＴＧＴコンポーザ３１２は、入力としてシステム記述ファイル３１１を受け入れる。システム記述ファイル３１１は、テストされるシステムをテストするためのテスティング命令／ベクトルを作るのにＴＧＴによって使用できる任意の適切な記述ファイルを含む。たとえば、システム記述ファイル３１１は、回路記述ファイル、基板／治具ネットリスト・ファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。図３のシステム記述ファイル３１１は、図２に関して図示し、説明したシステム記述ファイル２１１に似たシステム記述ファイル（たとえば、１つまたは複数の回路記述ファイル、１つまたは複数の基板／治具ネットリスト・ファイル、１つまたは複数の他の記述ファイル、および類似物、ならびにそのさまざまな組合せ）を含むことができる。システム記述ファイル３１１を、ＴＧＴ ３１０上で使用可能とすることができ、かつ／または１つもしくは複数のリモート・コンポーネントおよび／もしくはシステムから入手することができる。
ＴＧＴコンポーザ３１２は、入力として１つまたは複数のテスト動作記述ファイル３３１１−３３１Ｎ（集合的にテスト動作記述ファイル３３１）を受け入れる。テスト動作記述ファイル３３１は、ＳＣ ３２０によって生成される。ＳＣ ３２０によるテスト動作記述ファイル３３１の生成を、下で詳細に説明する。
ＴＧＴコンポーザ３１２は、システム記述ファイル３１１およびテスト動作記述ファイル３３１を処理して、回路モデル３１３を作る。回路モデル３１３を作るためのＴＧＴコンポーザ３１２によるシステム記述ファイル３１１の処理は、任意の適切な形で実行することができる。回路モデル３１３は、回路モデル３１３は、テストされるシステムまたはテストされるシステムのうちでＴＧＴ ３１０がそれのために実行されつつある部分のモデルを指定する。テスト動作記述ファイル３３１に関連するシステム記述ファイル３１１の処理は、ＴＧＴ ３１０が適切なＴＡＰ原子的動作を作ることを可能にする形で、ＴＧＴコンポーザ３１２が回路モデル３１３を作ることを可能にする。ＴＧＴコンポーザ３１２は、回路モデル３１３をＴＧＴアルゴリズム３１４に供給する。
ＴＧＴアルゴリズム３１４は、回路モデル３１３を受け入れる。ＴＧＴアルゴリズム３１４は、回路モデル３１３を処理して、ＴＧＴ原子的テスト動作３１６を作る。ＴＧＴ原子的テスト動作３１６を作るためのＴＧＴアルゴリズム３１４による回路モデル３１３の処理は、任意の適切な形で実行することができる。
図３に示されているように、ＴＧＴ ３１０およびＳＣ ３２０に加えて、ＴＳ １１０は、ＴＩＳＡトランスレータ３４０を含む。ＴＩＳＡトランスレータ３４０は、ＴＧＴ原子的テスト動作３１６を受け取る。ＴＩＳＡトランスレータ３４０は、ＴＧＴ原子的テスト動作３１６を変換して、ＴＩＳＡ原子的テスト動作３４６を形成する。ＴＩＳＡトランスレータ３４０は、ソフトウェア・コンパイル・プロセスに含めるために、ＴＩＳＡ原子的テスト動作３４６をＳＣ ３２０に供給する。ＳＣ ３２０によるＴＩＳＡ原子的テスト動作３４６の使用を、下で詳細に説明する。ＴＩＳＡトランスレータ３４０は、ＴＧＴ ３１０の一部とするか、ＳＣ ３２０の一部とするか、ＴＧＴ ３１０およびＳＣ ３２０にまたがって分割されるか、ＴＧＴ ３１０およびＳＣ ３２０とは別々に実施されるものなどとすることができる。
ＳＣ ３２０は、ＳＣプリコンパイラ３３０、ＳＣフロントエンド・アルゴリズム３２２、およびＳＣバックエンド・アルゴリズム３２４を含む。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を受け入れる。
コンピュータ・サイエンス・ソース・ファイル３２１は、コンパイラによってコンパイルできる任意の適切なコンピュータ・プログラミング・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル３２１は、Ｃ＋＋、Ｊａｖａ、Ｐｙｔｈｏｎ、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語（１つまたは複数）のコンピュータ・プログラミング・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル３２１は、１つもしくは複数のＣファイル、１つもしくは複数のＣ＋＋ファイル、および／または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの１つまたは複数を含むことができる。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を処理する。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１を処理し、それから前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを作る。コンピュータ・サイエンス・ソース・ファイル３２１をＳＣプリコンパイラ３３０によって前処理して、任意の適切な形で前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを形成することができる。ＳＣプリコンパイラ３３０は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐをフロントエンド・アルゴリズム３２２に供給する。
ＳＣプリコンパイラ３３０は、コンピュータ・サイエンス・ソース・ファイル３２１の処理中にテスト動作を検出し、テスト動作記述ファイル３３１を生成する。テスト動作記述ファイル３３１は、任意の適切なテスト記述言語を使用して（たとえば、１つまたは複数の標準テスト記述言語を使用して、ＴＧＴ ３１０に固有のテスト記述言語を使用して、および類似物、ならびにそのさまざまな組合せ）指定することができる。ＳＣプリコンパイラ３３０は、テスト動作記述ファイル３３１をＴＧＴ ３１０に（実例として、回路モデル３１３を作るためにシステム記述ファイル３１１に関連してテスト動作記述ファイル３３１を処理する、ＴＧＴ ３１０のＴＧＴコンポーザ３１２に）供給する。
ＳＣフロントエンド・アルゴリズム３２２は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐを受け入れる。ＳＣフロントエンド・アルゴリズム３２２は、ＴＩＳＡ原子的テスト動作３４６をも受け入れ、このＴＩＳＡ原子的テスト動作３４６は、テスト動作記述ファイル３３１からＴＧＴ ３１０によって作られたＴＧＴ原子的テスト動作３１６を使用してＴＩＳＡトランスレータ３４０によって作られる。ＳＣフロントエンド・アルゴリズム２２２は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１ＰおよびＴＩＳＡ原子的テスト動作３４６をコンパイルして、プログラム・モデル３２３を作る。プログラム・モデル３２３は、前処理済みコンピュータ・サイエンス・ソース・ファイル３２１Ｐの中間表現を指定し、この中間表現は、ＴＩＳＡ原子的動作を形成するためにＴＩＳＡ原子的テスト動作３４６をＩＳＡ原子的動作内に統合できるように、ＴＩＳＡ原子的テスト動作３４６を含む。ＳＣフロントエンド・アルゴリズム３２２は、プログラム・モデル３２３をＳＣバックエンド・アルゴリズム３２４に供給する。
ＳＣバックエンド・アルゴリズム３２４は、プログラム・モデル３２３を受け入れる。ＳＣバックエンド・アルゴリズム３２４は、プログラム・モデル２２３を処理して、ＴＩＳＡ原子的動作３５６を含む１つまたは複数のＴＩＳＡ２進ファイル３５５を作る。ＴＩＳＡ原子的動作３５６を含むＴＩＳＡ２進ファイル３５５を形成するためのＳＣバックエンド・アルゴリズム３２４によるプログラム・モデル３２３の処理は、任意の適切な形で実行することができる。
ＴＩＳＡ原子的動作３５６は、ＩＳＡ原子的動作（すなわち、ＴＩＳＡがそれために実施されるプロセッサによってサポートされるアセンブリレベル命令）およびＴＩＳＡ原子的テスト動作３４６を含む。
ＴＩＳＡ原子的動作３５６は、ＴＧＴ原子的テスト動作３１６（すなわち、ＴＩＳＡ原子的テスト動作３４６の形の）に対するアルゴリズム的制御（ＩＳＡ原子的動作を使用する）を提供し、これによって、ＴＩＳＡ原子的動作３５６が適用されるテストされるシステムの改善されたシステム・テスティングを可能にする。したがって、ＴＧＴ原子的テスト動作３１６（すなわち、ＴＩＳＡ原子的テスト動作３４６の形の）を、ＳＣバックエンド・アルゴリズム３２４によって制御される形でＴＡＰに適用することができる。というのは、ＴＧＴ原子的テスト動作３１６が、ＩＳＡ原子的動作を使用するＴＧＴ原子的テスト動作３１６に対するアルゴリズム的制御を可能にするために、ＩＳＡ原子的動作と組み合わされるからである。この形で、ＳＣ ２２０は、ＴＡＰへのアクセスのアルゴリズム的制御を提供する。
図３に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ／または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
図２および図３に関して、主に特定の個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物に関して図示し、説明したが、図２および図３の実施形態ならびに本明細書で提供されるさまざまな関連する教示を、任意の適切な個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物を使用して実施できることを了解されたい。
図２および図３は、コンピュータ・サイエンス機能を活用してシステム・テスティング機能を改善する形を示す（たとえば、システム・テスティングの細粒度制御の提供、対話システム・テスティングの使用可能化、システム・テスティング中の対話デバッギングの使用可能化、および図示され本明細書で説明されるさまざまな他の利益の提供）。図２および図３のシステム・テスティング方式は、ＳＴＡＰＬなどの既存手法に対する改善を提供し、これらの既存手法では、目標は、ベクトル・フォーマットにプログラミング機能を追加することであり、したがって、デバッギング機能、リモート・アクセス機能、および対話性機能が、ゼロから追加される。対照的に、ＴＩＳＡは、システム・テスティング用のテスト・アクセスを制御するために、コンピュータ・プログラミングおよび組込みアプリケーションからの豊富な情報を活用する。
図２および３を参照して、ＴＩＳＡの機能および特徴が、その抽象化レベルによって定義される、すなわち、ＴＩＳＡ原子的動作の定義が微細であればあるほど、ＴＩＳＡがより良い性能を提供することを了解されたい。
ＴＩＳＡがＪＴＡＧアーキテクチャ内で実施される一実施形態では、３つの抽象化レベルを、スキャン動作のためにサポートすることができる。
第１の抽象化レベルは、ベクトル・レベルである。ベクトル・レベルは、３つの抽象化レベルのうちで最も粗な粒度であり、ここでは、原子的動作は、スキャン・ベクトルの入力および出力である。ベクトル・レベルは、Ｓｅｒｉａｌ Ｖｅｃｔｏｒ ｆｏｒｍａｔ（ＳＶＦ）または任意の他の適切なベクトル・フォーマットなどのベクトル・フォーマットで最もよく表され、最高レベルの制御を与える。
第２の抽象化レベルは、ＴＡＰレベルである。ＴＡＰレベルでは、原子的動作は、ＴＡＰ状態機械に対する十分な制御を可能にするために機能強化される。これは、スキャン動作に対するより洗練された制御、非標準シーケンス（たとえば、たとえばアドレッサブル・シャドウ・プロトコル（Ａｄｄｒｅｓｓａｂｌｅ Ｓｈａｄｏｗ Ｐｒｏｔｏｃｏｌ）または他の類似するプロトコルで要求されるシーケンスなど）のサポートを可能にする。
第３の抽象化レベルは、スキャン・セグメント・レベルである。スキャン・セグメント・レベルは、３つの抽象化レベルのうちで最も微細な粒度である。ベクトル・レベルおよびＴＡＰレベルの抽象化レベルは、原子的データ・フォーマットとしてスキャン・ベクトルを使用し、これは、スキャン・チェーン全体が用いられる伝統的な導通テストには十分であるが、スキャン・チェーンを構成する数十個または数百個の機器に対する細粒度制御の必要がある機器ベースのテスティング（ｉｎｓｔｒｕｍｅｎｔ−ｂａｓｅｄ ｔｅｓｔｉｎｇ）には面倒である。スキャン・セグメント・レベルは、全体的なスキャン・パスの内部の「スキャン・セグメント」の定義を可能にし、このスキャン・セグメントは、別々に処理することができ、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。この手法は、使用可能な計算リソースが非常に限られている場合がある組込み応用例で有利である。スキャン・セグメント・レベルの使用を、図示し、下でさらに詳細に説明する
図２および図３に示されているように、スキャン動作の抽象化レベルに関わりなく、ＴＧＴによって計算される、結果のＴＡＰ原子的動作（実例として、ＴＧＴ原子的テスト動作２１６およびＴＧＴ原子的テスト動作３１６）は、対応するＴＩＳＡ原子的テスト動作に変換され、２進実行可能ファイルに（たとえば、ＳＣによって生成されたＩＳＡ原子的動作に）挿入される。
図２を参照すると、ＴＧＴ原子的テスト動作２１６およびＩＳＡ原子的動作２２６を処理して、ＴＩＳＡ２進実行可能ファイル（実例として、ＴＩＳＡ２進ファイル２４５）内のＴＩＳＡ原子的動作２４６を形成することができる。ＴＩＳＡ原子的動作２４６は、ＴＩＳＡ原子的テスト動作およびＩＳＡ原子的動作を含む。
図３を参照すると、ＴＩＳＡ原子的テスト動作（ＴＧＴ ３１０によって作られたＴＧＴ原子的テスト動作３１６からＴＩＳＡトランスレータ３４０によって生成される）を、ＳＣ ３１０のＳＣフロントエンド３２４を変更することを全く必要とせずに、前コンパイル済みアセンブリ命令としてＳＣフロントエンド３２４に入力することができる。ほとんどすべてのプログラミング言語が、そのような動作を可能にすることを了解されたい。たとえば、Ｃでは、この動作が、「ａｓｍ」コマンドを使用して得られる。一実施形態では、ＳＣバックエンド・アルゴリズム３２４に対する些細な変更が必要になる場合がある（たとえば、ＴＩＳＡアセンブラ命令の２進変換を処理するために）。そのようなプロセスの例を、図１１に関して図示し、本明細書で説明する。
主にＪＴＡＧアーキテクチャでのＴＩＳＡ原子的動作の粒度のレベルに関して図示し、説明したが、当業者は、ＴＩＳＡ原子的動作の粒度の同一のレベルを他のアーキテクチャで利用でき、ＴＩＳＡ原子的動作の粒度の異なるレベルの粒度を、ＪＴＡＧアーキテクチャおよび／または他のアーキテクチャ、類似物、ならびにそのさまざまな組合せで利用できることを了解するであろう。
上で説明したように、ＴＩＳＡを、任意の適切な命令セット・アーキテクチャ（ＩＳＡ）を使用して実施することができる。たとえば、ＴＩＳＡを、ＳＰＡＲＣ Ｖ８ ＩＳＡ、ＩＮＴＥＬ ＩＳＡ、および類似物を使用して実施することができる。
ＴＩＳＡの実施態様を説明する際の明瞭さのために、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの例示的実施態様を、本明細書で図４Ａ〜４Ｅに関して図示し、説明する。この例示的実施態様では、ＴＩＳＡは、ベクトル・レベルＴＩＳＡとして実施され、このベクトル・レベルＴＩＳＡは、ＳＶＦフォーマットを構成する命令の直接コーディングを可能にするが、上で説明したように、ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施を、ＴＩＳＡがＴＡＰレベルＴＩＳＡまたはスキャン・セグメント・レベルＴＩＳＡとして実施される場合にも実行できることを了解されたい。
ＳＰＡＲＣ Ｖ８ ＩＳＡは、オープンソース・ソフト・プロセッサ・ファミリＬｅｏｎ ２およびＬｅｏｎ ３など、多数の製品で実施されている。
「Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ Ｖｅｒｓｉｏｎ ８」、ＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ刊、１９９２年（以下では「ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ」）の再検討によって、ＳＰＡＲＣ Ｖ８ ＩＳＡによって活用されていない多数の符号語があることが明らかになる。これは、少なくともＡｐｐｅｎｄｉｘ Ｆの「ｏｐｃｏｄｅｓ ａｎｄ ｃｏｎｄｉｔｉｏｎ ｃｏｄｅｓ（オペコードおよび条件コード）」の再検討から明白である。
図４Ａに、ＳＰＡＲＣ Ｖ８ ＩＳＡの未活用符号語を示す。図４Ａに示された未活用符号語は、ＴＩＳＡの「テスト」命令をコーディングするのに使用することができる。より具体的には、「ｏｐ」と「ｏｐ２」との両方に０がセットされている時に、その命令は、「Ｔｈｅ ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ Ｖｅｒｓｉｏｎ ８」では未実施としてマークされ、その命令をＴＩＳＡに使用できるようになっている。
図４Ｂに、１３個のＳＶＦ命令のすべてを表すことができるコーディング・フォーマットを示す。図４Ｂに示されているように、ビット３０〜２５は、命令コーディング自体を含み、ビット２１〜１８は、ＴＡＰ状態が命令と共に使用される場合にそのＴＡＰ状態をコーディングするのに使用することができ、ビット１７〜１４は、必要な場合にオプション情報を指定するのに各命令によって使用することができる。
図４Ｃに、ＩＥＥＥ １１４９．１ ＴＡＰのＴＡＰ状態の例示的ビット・コーディングを示す。ＴＡＰ状態のビット・コーディングは、ＩＥＥＥ １１４９．１ ＴＡＰ状態名を識別する第１列、ＩＥＥＥ １１４９．１ ＴＡＰ状態名に関連するＳＶＦ ＴＡＰ状態名を識別する第２列、および図４Ｂのビット２１〜１８のビット・コーディングを識別する第３列を使用して表されている。ビット・コーディングを、さまざまな他の形でＴＡＰ状態に割り当てることができることを了解されたい。
ＳＶＦ命令は、複数のパラメータを可能にし、これらのパラメータは、最終的なコードの内部でコーディングされる必要がある。パラメータを表すために、また、命令およびデータを別々に保つという通常のアーキテクチャ的ベスト・プラクティスのために、レジスタベースのパラメータ渡しが、ベクトル・レベルＴＩＳＡのこの例示的実施態様のために定義される。したがって、ベクトル・レベルＴＩＳＡは、６つの専用３２ビット・レジスタすなわち、ＧＥＮＥＲＩＣ１、ＧＥＮＥＲＩＣ２、ＴＤＩ、ＴＤＯ、ＭＡＳＫ、およびＳＭＡＳＫを提示する。この６つの専用３２ビット・レジスタを、図４Ｄに示す。６つの専用３２ビット・レジスタの使用を、下で詳細に説明するが、一般的ルールとして、これらのレジスタは、パラメータを格納するか、パラメータが格納されるメモリ位置をポイントするかのいずれかに使用される。したがって、コンパイル時に、通常のＩＳＡ命令を使用して、ＴＩＳＡ命令が呼び出される前にこれらのレジスタにロードすることができる。より具体的には、ＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様では、コプロセッサ・レジスタを、通常のロード／ストア命令のパラメータとして直接に使用することができる。
ＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様で利用できるＳＶＦ命令は、ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ、ＦＲＥＱＵＥＮＣＹ、ＰＩＯ、ＰＩＯＭＡＰ、ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ、ＳＤＲ、ＳＩＲ、およびＲＵＮＴＥＳＴを含む。これらのＳＶＦ命令は、参照によってその全体が本明細書に組み込まれている、「Ｓｅｒｉａｌ Ｖｅｃｔｏｒ Ｆｏｒｍａｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ＡＳＳＥＴ ＩｎｔｅｒＴｅｃｈ，Ｉｎｃ．、１９９７年（以下ではＳＶＦマニュアルと称する）を参照することによってよりよく理解することができる。ＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様でのこれらのＳＶＦ命令の使用を、下でより詳細に説明する。
ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ
ＥＮＤＤＲ命令およびＥＮＤＩＲ命令は、ＴＡＰインターフェースがその動作を終了するＴＡＰ状態を示す。ＳＴＡＴＥ命令は、強制的にＴＡＰインターフェースを指定された状態にする。ＴＩＳＡのこの例示的実施態様では、ＥＮＤＤＲ命令、ＥＮＤＩＲ命令、およびＳＴＡＴＥ命令のＳＶＦコーディングは、図４Ｅに示されているようにそれぞれ「００００００」、「０００００１」、および「００００１０」である。これらのＳＶＦ命令のＳＶＦコーディングは、必要に応じて「ＴＡＰ状態」ファイル（すなわち、図４Ｃに示されたＴＡＰ状態の例示的ビット・コーディング）を使用して実行することができる。少なくともＳＶＦマニュアルの再検討から、ＳＴＡＴＥ命令がオプションでパラメータとして状態の明示的シーケンスをとることができることを了解されたい。ＴＩＳＡのこの例示的実施態様では、パラメータとして状態の明示的シーケンスをとることは、シーケンス内の状態ごとに１命令の、一連の命令によってコーディングされるはずである。
ＦＲＥＱＵＥＮＣＹ
ＦＲＥＱＵＥＮＣＹ命令は、ＴＡＰインターフェースの動作周波数を指定するのに使用される。ＦＲＥＱＵＥＮＣＹ命令は、Ｈｚサイクルの３２ビット整数として表される。ＴＩＳＡのこの例示的実施態様では、ＦＲＥＱＵＥＮＣＹ命令のＳＶＦコーディングは、図４Ｅに示されているように、「００００１１」である。ＦＲＥＱＵＥＮＣＹ命令の値は、ＧＥＮＥＲＩＣ１レジスタに格納される。
ＰＩＯ、ＰＩＯＭＡＰ
ＰＩＯ命令は、ＰＩＯＭＡＰへの呼出しによって以前にセットされたフォーマットの並列ベクトルを処理するのに使用することができる。ＲＩＳＡのこの例示的実施態様では、ＰＩＯＭＡＰは、ＴＡＰインターフェースをセット・アップするのに適切なコマンドを生成するプリプロセッサ・ディレクティブとみなされる。したがって、ＰＩＯ命令は、単に、並列ベクトルを表すことを必要とし、この並列ベクトルは、この並列ベクトルが格納されているアドレスを示す（ＧＥＮＥＲＩＣ１レジスタ内で）ことによって表すことができる。ベクトルを構成する語数「ｎ」は、この命令のビット１３〜０で指定され、したがって、ベクトルは、２１３＝８Ｋ語＝３２Ｋバイトのサイズ上限を有する。ベクトル・サイズが１語の正確な倍数ではない場合には、必要に応じてパディングおよび再アライメントをメモリ内で提供することができる。ＴＩＳＡのこの例示的実施態様では、ＰＩＯ命令のＳＶＦコーディングは、「０００１００」である。
ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ
ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令の役割は、異なる。ここでは、これらのＳＶＦ命令を一緒に検討する。というのは、（１）これらのＳＶＦ命令が、機能的に類似し（すなわち、これらのすべてが、異なる性質のものである場合であっても、シフト演算を指令する）、（２）これらのＳＶＦ命令が、次の同一のパラメータを受け入れるからである。
（１）ｌｅｎｇｔｈ シフトすべきビット数を表す３２ビット数
（２）ＴＤＩ（オプション） 入力シフト・ベクトル
（３）ＴＤＯ（オプション） 期待される出力シフト・ベクトル
（４）ＭＡＳＫ（オプション） 実際の値をＴＤＯと比較する時に使用すべきマスク。「１」は関係を示し、「０」は無関係を示す。
（５）ＳＭＡＳＫ（オプション） 実際の値をＴＤＩと比較する時に使用すべきマスク。「１」は関係を示し、「０」は無関係を示す。
ＴＩＳＡのこの例示的実施態様では、ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令のＳＶＦコーディングは、図４Ｅに示されているように、それぞれ「０００１１０」、「０００１１１」、「００１０１０」、および「００１０１１」である。
ＴＩＳＡのこの例示的実施態様では、次の追加のコーディングを使用することができる。
（１）ｌｅｎｇｔｈは、ＧＥＮＥＲＩＣ１レジスタに格納される。
（２）Ｏ１は、ＴＤＩが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＴＤＩレジスタは、入力ベクトルが格納されているアドレスを含む。
（３）Ｏ２は、ＴＤＯが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＴＤＯレジスタは、期待される出力が格納されているアドレスを含む。
（４）Ｏ３は、ＭＡＳＫが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＭＡＳＫレジスタは、出力マスクが格納されているアドレスを含む。
（５）Ｏ４は、ＳＭＡＳＫが存在する時には「１」であり、そうでない時には「０」である。セットされている場合に、ＳＭＡＳＫレジスタは、出力マスクが格納されているアドレスを含む。
ＳＤＲ、ＳＩＲ
ＳＤＲ命令およびＳＩＲ命令は、ＨＤＲ命令、ＨＩＲ命令、ＴＤＲ命令、およびＴＩＲ命令と同一の構文を有するが、機能的相違を有し、ＳＤＲおよびＳＩＲは、ＴＡＰに対する実際のスキャン動作をトリガする。対話テスティングでは、システムから読み取られた実際の出力ベクトルが、アルゴリズムの基礎であり、したがって、ＴＩＳＡは、実際の出力ベクトルをメモリ内に格納する可能性を提供する。「ＴＡＰ状態」フィールド（図４Ｂに示されたビット２１〜１８）が０とは異なる時には、ＧＥＮＥＲＩＣ２レジスタは、実際の出力ベクトルのストレージ位置を示す。したがって、ＳＤＲおよびＳＩＲは、最大７個のパラメータをサポートすることができる。ＴＤＯが指定され、実際の出力ベクトルが期待される出力ベクトルとは異なる場合には、ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌ」のＳｅｃｔｉｏｎ ４．２に記載されているように、オーバーフロー・フラグがプロセッサ状態レジスタ（ＰＳＲ）内でセットされる。
ＲＵＮＴＥＳＴ
ＲＵＮＴＥＳＴ命令は、強制的にＴＡＰインターフェースに指定された長さの時間だけ指定された状態でテストを実行させ、主にＲＵＮＢＩＳＴ動作（たとえば、ＩＥＥＥ １１４９．１で定義されている）を制御するのに使用される。ＲＵＮＴＥＳＴ命令は、次のパラメータ（すべてがオプションである）のうちの１つまたは複数を受け入れる。
（１）ｒｕｎ＿ｓｔａｔｅ インターフェースがテスト実行中に維持しなければならない状態
（２）ｒｕｎ＿ｃｏｕｎｔ テストが費やさなければならないクロック・サイクル数
（３）ｒｕｎ＿ｃｌｋ ｒｕｎ＿ｃｏｕｎｔがどのクロックを参照するのか（ＴＣＫ：ＴＡＰクロック、ＳＣＫ：システム・クロック）
（４）ｍｉｎ＿ｔｉｍｅ 実数として表された、秒単位の最小走行時間
（５）ｍａｘ＿ｔｉｍｅ 実数として表された、秒単位の最大走行時間
（６）ｅｎｄｓｔａｔｅ インターフェースがコマンドの終りに達しなければならない状態
ＴＩＳＡのこの例示的実施態様では、ＲＵＮＴＥＳＴ命令のＳＶＦコーディングを、「０００１０１」または「１００１０１」とすることができる。
ＴＩＳＡのこの例示的実施態様では、次の追加のコーディングを使用することができる。
（１）ＴＡＰ＿ＳＴＡＴＥ それについて定義されたｒｕｎ＿ｓｔａｔｅを含む。
（２）Ｏ１ ＴＡＰ＿ＳＴＡＴＥが定義されている場合には「１」、そうでない場合には「０」
（３）Ｏ２ ｍｉｎ＿ｃｏｕｎｔが指定されている場合には「１」、そうでない場合には「０」。セットされている場合には、ＧＥＮＥＲＩＣ１レジスタが、ｍｉｎ＿ｃｏｕｎｔの３２ビット符号なし表現を含む。
（４）Ｏ３ ｍａｘ＿ｔｉｍｅが指定されている場合には「１」、そうでない場合には「０」。セットされている場合には、ＧＥＮＥＲＩＣ２レジスタが、ｍａｘ＿ｃｏｕｎｔの３２ビット符号なし表現を含む。
（５）Ｏ４ ｅｎｄｓｔａｔｅがセットされている場合には「１」、そうでない場合には「０」。セットされている場合には、ビット１３〜１０が終了状態を含む。
（６）ビット９〜０ ｒｕｎ＿ｃｏｕｎｔが指定されている場合には、符号なし整数として表される（最大ｒｕｎ＿ｃｏｕｎｔ＝２１０＝１０２４）。このフィールドが「０」ではない場合には、ビット３０がｒｕｎ＿ｃｌｏｃｋを示す（「１」＝ＴＣＫ、「０」＝ＳＣＫ）。
主にＴＩＳＡのこのＳＰＡＲＣ Ｖ８ ＩＳＡ実施態様での特定のＳＶＦ命令（すなわち、ＥＮＤＤＲ、ＥＮＤＩＲ、ＳＴＡＴＥ、ＦＲＥＱＵＥＮＣＹ、ＰＩＯ、ＰＩＯＭＡＰ、ＨＤＲ、ＨＩＲ、ＴＤＲ、ＴＩＲ、ＳＤＲ、ＳＩＲ、およびＲＵＮＴＥＳＴ）の使用に関して図示し、本明細書で説明したが、より少数またはより多数のＳＶＦ命令を使用できることを了解されたい。
主にＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの実施態様に関して図示し、本明細書で説明したが、他のＩＳＡを利用して、図示され本明細書で説明されるＴＩＳＡ教示によるＴＩＳＡを実施できることを了解されたい。
対話テスティング手法では、データ・ハンドオフ・ポイントが非常に重要である。上で説明したように、テスト・プログラムは、２つの主要部分すなわち、アルゴリズム部分（ソフトウェア・コンパイラによって表される）およびテスト・アクセス部分（テスト生成ツールによって表される）からなる。テスティング・プログラムを使用するテスト動作中には、テスト・プログラムがテストされるシステムにアクセスしている瞬間と、テスト・プログラムがテスト結果を検査し、必要な次のステップ（１つまたは複数）を判断している瞬間とがある。この２つの動作の間でのハンドオフは、効率的な対話テスティングを得るために重要である。
ＳＶＦおよびＳＴＡＰＬなどの既存のスクリプトベースの手法では、スクリプトが、ベクトル・レベルですべてのＴＡＰ動作の世話をする。このレベルでは、インターフェース（または「プレイヤ」）は、ＴＡＰプロトコルを用いて通信し、テストされるシステムへ／からベクトルを送る／受け取ることができる。さらに、ＳＴＡＰＬは、いくつかの基本的なフロー制御（ｉｆ−ｔｈｅｎ−ｅｌｓｅ）およびビット・ベクトルに対するアルゴリズム的操作をも可能にする。より洗練された処理（たとえば、受け取られたベクトルの内部のレジスタを識別する、または特定のデバイスにアクセスするためのベクトルを計算する）の必要がある場合には、プレイヤは、アルゴリズム部分に制御をハンド・オーバーする。ＳＴＡＰＬでは、これが「ｅｘｐｏｒｔ」コマンドを介して行われる。しかし、不利なことに、ＳＶＦおよびＳＴＡＰＬの両方が、これに関する標準化されたフォーマットを有しない（たとえば、ＳＴＡＰＬの場合に、ハンドオフ・プロセスは、通常は、所与のベンダにプロプライエタリである）。
Ｅｒｉｃｓｓｏｎ社のＭａｓｔｅｒ Ｔｅｓｔ Ｃｏｎｔｒｏｌｌｅｒ（ＭＴＣ）およびＳｙｓｔｅｍ ＢＩＳＴ Ｐｒｏｃｅｓｓｏｒなどの既存の組込み手法では、アルゴリズム部分とテスト・アクセス部分との間の同一の区分が使用される。そのような組込み手法では、アルゴリズム部分およびテスト・アクセス部分は、別々にプログラムされなければならない異なるプロセッサによって実行される。さらに、アルゴリズム部分およびテスト・アクセス部分のメモリ空間は、物理的に異なり、結果のハンドオフ機構が、ＳＴＡＰＬのハンドオフ機構に類似するようになっている。その結果は、テスト・アクセス部分用のコプロセッサが、アルゴリズム部分へのハンドオフの前に大量のスキャン部分を格納することを強制されることであり、これは、スキャン・チェーンの増加するサイズを考慮すると、膨大な量のリソースを必要とする可能性がある。
統合テスティングに対する既存手法（たとえば、ＳＶＦおよびＳＴＡＰＬなどのスクリプトベースの手法ならびにＭＴＣおよびＳｙｓｔｅｍ ＢＩＳＴ Ｐｒｏｃｅｓｓｏｒなどの組込み手法）とは対照的に、ＴＩＳＡは、テスト・アクセス部分（すなわち、テスト動作）をアルゴリズム部分（すなわち、古典的ＩＳＡ）の内部に統合し、テスト・アクセス部分およびアルゴリズム部分が同一の物理メモリ空間を共有するようにし、これによって、テスト・アクセス部分とアルゴリズム部分との間のハンドオフ（したがって、データ渡し）を自動的にする。ＴＩＳＡでは、テスト・アクセス部分とアルゴリズム部分との間のハンドオフは、命令レベルで行われ、プロセッサが、関連するスケジューリング戦略に従って必要に応じてスキャンおよびアルゴリズムを自由に混合（すなわち、テスト動作およびアルゴリズム動作を自由に混合）できるようになっている。
ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡのこの例示的実施態様では、ベクトルを扱うすべての動作が、絶対アドレッシングを使用する（ＳＶＦ命令に関して上で説明したように）。その結果、テスティング・ベクトルを、ＩＳＡプログラムの内部の通常の変数のように使用することができ、これによって、テスト・アクセス部分とアルゴリズム部分との間のインターフェースを自動的にする。例として、上で説明したＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの例示的実施態様に基づいて、次のステップは、原型的なテスティング・シーケンスを例示するものである。
（１）ＳＤＲ命令が、テストされるシステムからテスティング出力データを入手するのに使用される。結果の出力データは、特定のメモリ位置に配置される（たとえば、ＧＥＮＥＲＩＣ２レジスタ内の「ａｃｔｕａｌ」パラメータ）
（２）古典的なＬＯＡＤ命令が、ロードされるべきこの出力データをレジスタに転送することができる
（３）出力データがレジスタにロードされた後に、算術演算および／または論理演算を使用して、出力データを処理することができる（ＳＰＡＲＣ Ｖ８ ＩＳＡはロード／ストア・アーキテクチャなので、すべてのデータが、処理される前にレジスタにロードされなければならないことに留意されたい）
（４）古典的なＳＴＯＲＥ命令が、アルゴリズムの結果をメモリに転送するのに使用される
（５）ＳＤＲ命令が、新しいテスティング入力データをＴＡＰに送ることができる（たとえば、ＴＤＩレジスタ内の「ＴＤＩ」パラメータを使用して）
古典的なアルゴリズム動作（２）から（４）が、ＩＳＡアルゴリズム実施態様について標準的であり、いかなる形でもＴＩＳＡによって変更されないことに留意されたい。
したがって、この単純な例から、ＴＩＳＡを、アルゴリズム部分とテスト・アクセス部分との間の自然で効率的なハンドオフと共に、任意の所与のアルゴリズムまたはコンピュータ・プログラムを使用してサポートできることは、明白である。
ＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡのこの例示的実施態様では、絶対アドレッシングが使用される（ＴＩＳＡを説明する際の明瞭さのために）が、本明細書の教示によって情報を与えられた当業者は、ＳＰＡＲＣ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｍａｎｕａｌに記載されたすべての正当なＳＰＡＲＣ Ｖ８アドレッシング・モードをサポートするためにＴＩＳＡのこの例示的実施態様を修正できるはずである。
本明細書で主にＳＶＦが使用されるＴＩＳＡの例示的実施態様に関して図示し、説明したが、ＳＶＦは、１１４９．１ ＴＡＰの、基本的であるとしても完全な処理を提供することがわかっている周知のフォーマットなので、この例示的実施形態で使用された。本明細書の教示によって情報を与えられた当業者は、ＴＩＳＡを任意の他の適切な制御フォーマットを使用して実施でき、それらの制御フォーマットの多くが、ＴＡＰ状態機械のより細粒度の制御を可能にし、より洗練されたテスティング動作をサポートすることができることを了解するであろう。
本明細書で主に抽象化レベルがベクトル・レベルであるＴＩＳＡの例示的実施態様に関して図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、図示され本明細書で説明される例示的ＴＩＳＡ実施態様を、ＴＩＳＡの抽象化レベルがＴＡＰレベルまたはスキャン・セグメント・レベルになるように変更できることを了解するであろう。
ＴＩＳＡを説明する際の明瞭さのために、例示的なテストされるシステムに対してテスティングを実行するためのＴＩＳＡの例示的使用を、図５および６に関して図示し、本明細書で説明する。ＴＩＳＡのこの例示的使用では、ＴＩＳＡは、ＳＰＡＲＣ Ｖ８ ＩＳＡおよびＳＶＦを使用するベクトル・レベルＴＩＳＡとして（すなわち、図４Ａ〜４Ｅに関して図示され、説明された例示的実施態様の継続で）実施される。
図５Ａおよび図５Ｂに、テストされるシステムに対してテスティングを実行するためのＴＩＳＡの例示的使用を示す。
図５Ａに、ＪＴＡＧ ＴＡＰ ５１０およびテストされるシステム５２０を含むシステム・テスト環境５００を示す。
ＪＴＡＧ ＴＡＰ ５１０は、テストされるシステム５２０へのテスト・アクセスを提供する。ＪＴＡＧ ＴＡＰ ５１０は、テストされるシステム５２０に入力データを送り、テストされるシステム５２０から出力データを受け取るために、テストされるシステム５２０へのテスト・アクセスを提供する。ＪＴＡＧ ＴＡＰ ５１０は、命令レジスタ（ＩＲ）５１２を含み、ＩＲ ５１２は、８ビット命令レジスタである。
ＪＴＡＧ ＴＡＰ ５１０は、テスティング・システム（たとえば、明瞭にするために省略されている、図３に関して図示し、説明したテスティング・システム１１０など）によって制御される。
テストされるシステム５２０は、第１基板５２１（Ｂ１と表される）および第２基板５２５（Ｂ２と表される）を含む。第１基板５２１は、送信器５２２（Ｔと表される）を含む。第２基板５２５は、受信器５２６（Ｒと表される）を含む。送信器５２２は、接続５２９上でデータを受信器５２６に送信する。この例では、接続５２９は、８ビット接続である。
図５Ａに示されているように、各基板は、それ自体のスキャン・チェーンを介してＪＴＡＧ ＴＡＰ ５１０からアクセス可能である。すなわち、第１基板５２１は、第１スキャン・チェーン５２３を介してアクセス可能であり、第２基板５２５は、第２スキャン・チェーン５２７を介してアクセス可能である。第１スキャン・チェーン５２３および第２スキャン・チェーン５２７は、ＪＴＡＧ ＴＡＰ ５１０のＩＲ ５１２によってアクセス可能である（たとえば、ＩＲ＝０は第１基板Ｂ１を選択し、ＩＲ＝１は第２基板Ｂ２を選択する）。送信器５２２および受信器５２６は、その基板上で単独であるのではなく、より広いスキャン・チェーン（たとえば、この例において、それぞれ２４ビットおよび１６ビット）の一部である。
テスト・プログラムでは、入力データが、第１スキャン・チェーン５２３を介して送信器５２２に送られ、結果の出力データが、第２スキャン・チェーン５２７を活用することによって受信器５２６から収集される。網羅的テストを実行するために、すべての可能な値が接続５２９を介して送信され、２８＝２５６個のベクトルが接続５２９を介して送信されるようになっている。Ｃを使用すると、例示的プログラムを、次とすることができる。
１ ｉｎｃｌｕｄｅ ＜ｓｔｄｉｏ．ｈ＞
２ ｉｎｃｌｕｄｅ ＜ｊｔａｇ．ｈ＞
３
４ ｃｈａｒ ｓｅｎｔ＿ｖａｌｕｅ， ｒｅｃｅｉｖｅｄ ｖａｌｕｅ；
５
６ ｄｅｆｉｎｅ ＭＡＸ＿ＣＯＵＮＴ ２５６；
７
８ ｖｏｉｄ ｍａｉｎ（ｖｏｉｄ）
９ ｛
１０ ｆｏｒ （ｓｅｎｔ＿ｖａｌｕｅ＝０；ｓｅｎｔ＿ｖａｌｕｅ＜ＭＡＸ＿ＣＯＵＮＴ；ｓｅｎｔ＿ｖａｌｕｅ＋＋）
１１ ｛
１２ ａｐｐｌｙ＿ＪＴＡＧ（ｓｅｎｔ＿ｖａｌｕｅ，Ｂ１．Ｔ）；
１３ ｒｅａｄ＿ＪＴＡＧ （ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ，Ｂ２．Ｒ）；
１４ ｉｆ （ｓｅｎｔ＿ｖａｌｕｅ ！＝ ｒｅｃｅｉｖｅｄ ｖａｌｕｅ） ｅｘｉｔ （０）；
１５ ｝
１６ ｅｘｉｔ（１）；
１７ ｝
このプログラムでは、行２は、ＪＴＡＧ動作を処理しているＣモジュールを含み、このＣモジュールでは、それぞれ行１２および１３で使用される関数「ａｐｐｌｙ＿ＪＴＡＧ」および「Ｒｅａｄ＿ＪＴＡＧ」が定義される。ＳＣ ３２０のプリコンパイラ３３０は、これらの関数を認識し、ＴＧＴ ３１０用のテスト動作記述ファイル３３１を生成する。テスト動作記述ファイル３３１のフォーマットは、第１基板５２１および第２基板５２５の実際の実施態様に依存して変化する可能性がある。たとえば、第１基板５２１と第２基板５２５との両方がＩＪＴＡＧ準拠である場合には、テスト動作記述ファイル３３１を、たとえばＮｅｗ Ｓｃａｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＮＳＤＬ）コードを使用して指定することができる。ＴＧＴ ３１０は、テスト動作記述ファイル３３１を使用して、ＴＧＴ原子的テスト動作３１６を生成し、このＴＧＴ原子的テスト動作３１６は、ＴＩＳＡトランスレータ３４０によってＴＩＳＡ原子的テスト動作３４６に変換される。ＴＩＳＡ原子的テスト動作３４６は、ＳＣ ３２０のフロントエンド３２４に供給される。ＴＧＴ原子的テスト動作３１６、関連するＴＩＳＡ原子的テスト動作３４６、および結果のＴＩＳＡ２進コードが、図５Ｂに示されている。
図５Ｂに、図５Ａのシステム・テスト環境５００のテスティングを実行するテスティング・システムによる使用のためのＣコマンドからＴＩＳＡコーディングへのマッピングを示す。
図５Ｂに示されているように、ＴＩＳＡコーディングへのＣコマンドのマッピングは、４つの列すなわち「Ｃコマンド」列５４１、「ＳＶＦ命令」列５４２、「ＴＩＳＡアセンブラ」列５４３、および「ＴＩＳＡコーディング」列５４４を有するテーブル５４０を使用して表される。テーブル５４０は、左から右へ、ＣコマンドをＳＶＦ命令に変換できる形を示し、このＳＶＦ命令をＴＩＳＡアセンブラに変換することができ、このＴＩＳＡアセンブラをＴＩＳＡ２進コーディングにコーディングすることができる。
Ａｐｐｌｙ＿ＪＴＡＧ（ｖａｌｕｅ，Ｂ１．Ｔ）コマンドは、２つのＳＶＦ命令すなわちＳＩＲ ８ ＴＤＩ（００）およびＳＤＲ ２４ ＴＤＩ（ｖａｌｕｅ）に変換される。
ＳＩＲ ８ ＴＤＩ（００） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ ８， ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ ００， ％ｃＴＤＩ
ＳＩＲ ＴＤＩ、１２０１００００としてＴＩＳＡコーディングに変換される。
ＳＤＲ ２４ ＴＤＩ（ｖａｌｕｅ） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ ２４， ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ ｖａｌｕｅ， ％ｃＴＤＩ
ＳＤＲ ＴＤＩ、１００１００００としてＴＩＳＡコーディングに変換される。
Ｒｅａｄ＿ＪＴＡＧ（ｖａｌｕｅ，Ｂ２．Ｒ）コマンドは、２つのＳＶＦ命令すなわちＳＩＲ ８ ＴＤＩ（０１）およびＳＤＲ １６ ＡＣＴＵＡＬ（ｖａｌｕｅ）に変換される。
ＳＩＲ ８ ＴＤＩ（０１） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ ８， ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ ０１， ％ｃＴＤＩ
ＳＩＲ ＴＤＩ、１２０１００００としてＴＩＳＡコーディングに変換される。
ＳＤＲ １６ ＡＣＴＵＡＬ（ｖａｌｕｅ） ＳＶＦ命令は、次の３つの動作としてＴＩＳＡアセンブラに変換される。
ＳＥＴ １６， ％ｃＧＥＮＥＲＩＣ１
ＳＥＴ ”ｖａｌｕｅ”， ％ｃＧＥＮＥＲＩＣ２
ＳＤＲ ＡＣＴＵＡＬ、１０００８０００としてＴＩＳＡコーディングに変換される。
ＳＥＴ動作のＴＩＳＡコーディングは、指定されない。というのは、ＳＰＡＲＣ Ｖ８ Ｍａｎｕａｌが、これらを、プロセッサの実施態様に従って異なるコーディングを有することができる「擬似命令」として識別するからである。
決定されたＴＩＳＡコーディングを使用して、プリコンパイラ３３０は、今や、高水準ＪＴＡＧアクセスをそれに関連するＴＩＳＡアセンブラ命令に置換することができる。その結果が、Ｃを使用して指定された次のコードであり、このコードでは、ＪＴＡＧ ＴＡＰへの呼出しが、関連するＴＩＳＡアセンブラ・コーディングによって置換されている。
１ ｉｎｃｌｕｄｅ ＜ｓｔｄｉｏ．ｈ＞
２ ｉｎｃｌｕｄｅ ＜ｊｔａｇ．ｈ＞
３
４ ｃｈａｒ ｓｅｎｔ＿ｖａｌｕｅ， ｒｅｃｅｉｖｅｄ ｖａｌｕｅ；
５
６ ｄｅｆｉｎｅ ＭＡＸ＿ＣＯＵＮＴ ２５６；
７
８ ｖｏｉｄ ｍａｉｎ（ｖｏｉｄ）
９ ｛
１０ ｆｏｒ （ｓｅｎｔ＿ｖａｌｕｅ＝０；ｓｅｎｔ＿ｖａｌｕｅ＜ＭＡＸ＿ＣＯＵＮＴ；ｓｅｎｔ＿ｖａｌｕｅ＋＋）
１１ ｛
１２ ａｓｍ ｖｏｌａｔｉｌｅ （”ＳＥＴ ８， ％ｃＧＥＮＥＲＩＣ１；
１３ ＳＥＴ ００， ％ｃＴＤＩ；
１４ ＳＩＲ ＴＤＩ；
１５ ＳＥＴ ２４， ％ｃＧＥＮＥＲＩＣ１；
１６ ＳＥＴ ＆ｓｅｎｔ＿ｖａｌｕｅ， ％ｃＴＤＩ；
１７ ＳＤＲ ＴＤＩ；”）；
１８ ａｓｍ ｖｏｌａｔｉｌｅ （”ＳＥＴ ８， ％ｃＧＥＮＥＲＩＣ１；
１９ ＳＥＴ ０１， ％ｃＴＤＩ；
２０ ＳＩＲ ＴＤＩ；
２１ ＳＥＴ １６， ％ｃＧＥＮＥＲＩＣ１；
２２ ＳＥＴ ＆ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ， ％ｃＧＥＮＥＲＩＣ２；
２３ ＳＤＲ ＡＣＴＵＡＬ”）；
２４ ｉｆ （ｓｅｎｔ＿ｖａｌｕｅ ！＝ ｒｅｃｅｉｖｅｄ ｖａｌｕｅ） ｅｘｉｔ （０）；
２５ ｝
２６ ｅｘｉｔ（１）；
２７ ｝
このコードを、フロントエンド・アルゴリズム３２２に入力することができ、フロントエンド・アルゴリズム３２２は、プログラム・モデル３２３を生成する。プログラム・モデル３２３を、バックエンド・アルゴリズム３２４に入力することができ、バックエンド・アルゴリズム３２４は、ＴＩＳＡ原子的動作３５６を含む実行可能ＴＩＳＡ２進ファイル（１つまたは複数）３５５を生成する。
テーブル５４０の「ＴＩＳＡコーディング」列５４４は、ＴＩＳＡアセンブラ命令の２進コーディングを示す（たとえば、図４Ａ〜４Ｅに関して図示し、説明したようにＳＰＡＲＣ Ｖ８ ＩＳＡを使用するＴＩＳＡの例示的実施態様に関して定義されるさまざまなルールを使用して）。
本明細書で説明するように、ＴＩＳＡは、テストされるシステムのテスティングを実行する際のテスト粒度に関して完全な自由を提供する（すなわち、ＴＡＰレベルからスキャン・セグメント・レベルまで）。図２および図３に示され、図４Ａ〜４Ｅおよび図５Ａ〜５Ｂの例示的ＴＩＳＡ実施態様を使用してさらに説明されるように、テスト・パターンを、テスト生成ツールに対するソフトウェア・コンパイラによる明示的照会を使用して計算することができ、ソフトウェア・アルゴリズムに関する唯一の制限は、照会自体の解決である。
例として、粗なレベルで、ＳＣからＴＧＴへの照会は、テストされるシステムのスキャン・チェーン全体を含むことができる（たとえば、古典的なＢＳＤＬベースのバウンダリ・スキャン・テスティングの場合など）。
例として、微細なレベルで、ＳＣからＴＧＴへの照会は、レジスタまたはビットさえも含むことができる。たとえば、専用スキャン・セグメント・プリミティブは、機器アクセスおよびＴＡＰ再構成を大幅に加速し、コード再利用を増やし、さまざまな他の利益を提供することができる。
例として、粗なレベルと微細なレベルとの間の中間レベルでは、ＳＣからＴＧＴへの照会を、関数的に行うことができる（たとえば、ＩＪＴＡＧおよび他の適切な標準規格などの標準規格を使用し、ＮＳＤＬおよび他の適切なオブジェクト指向記述言語などの記述言語を使用して）。
この形で、ＴＩＳＡは、デバイス／レジスタ・アクセスがモデル空間で（すなわち、ＴＧＴ内で）解決されることを強制するのではなく、開発者がデバイス／レジスタ・アクセスをプログラム空間で（すなわち、ＳＣ内で）処理することを可能にし、これによって、開発者が分析粒度を彼らの必要および使用可能なリソースに適合させることを可能にする。
さらに、ＴＩＳＡプロセッサが、たとえば自動テスト装置（ＡＴＥ）の場合など、十分なリソースを有する環境では、回路モデルの少なくとも一部を、プログラム・モデル内で実施することができ、これによって、ＴＩＳＡマシンがベクトル・パターンを直接に計算することが可能になる。
さらに、ＴＩＳＡは、対話デバッギング（ローカルにおよび／またはリモートに）を含む対話テスティング、並列性、ポータビリティ、および類似物、ならびにそのさまざまな組合せなど、ＴＩＳＡなしでは以前に可能でなかったさまざまな他のシステム・テスト機能をサポートすることを可能にする。これらの追加機能に、これからさらに詳細に対処する。
図６に、対話テスティング機能をサポートするＴＩＳＡベースのテスティング環境の実施形態を示す。
図６に示されているように、ＴＩＳＡベースのテスティング環境６００は、ホスト・コンピュータ（ＨＣ）６０１、テスティング・システム（ＴＳ）６１０、およびテストされるシステム（ＳＵＴ）６２０を含む。
ＨＣ ６０１は、ＳＵＴ ６２０のテスティングを制御するためにＴＳ ６１０を制御するように構成される。ＨＣ ６０１は、メモリ６０４に結合されたプロセッサ６０２を含む。プロセッサ６０２およびメモリ６０４は、任意の適切なプロセッサおよびメモリとすることができる。
メモリ６０４は、１つまたは複数のデバッガ制御プログラム６０５を格納する。デバッガ制御プログラム（１つまたは複数）は、ＨＣ ６０１がＴＳ ６１０上で走行するコンピュータ・プログラム（１つまたは複数）の実行をトレースし、望まれるか必要な場合にこれを変更することを可能にする。たとえば、デバッガ制御プログラム（１つまたは複数）６０５は、ＧＮＵ Ｄｅｂｕｇｇｅｒ（ＧＤＢ）、ｄｂｘデバッガ、Ｐｅｒｌデバッガ、Ｂａｓｈデバッガ、Ｐｙｔｈｏｎデバッガ、および同様の適切なデバッガ・プログラム、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
メモリ６０４は、１つまたは複数のデバッガ表示プログラム６０６をも格納することができる。デバッガ表示プログラム（１つまたは複数）は、ＨＣ ６０１がデバッガ制御プログラム（１つまたは複数）６０５に関連する情報を表示することを可能にする。デバッガ制御プログラム（１つまたは複数）６０５に関連する情報を、デバッガ表示プログラム（１つまたは複数）６０６によって任意の適切な形で（たとえば、１つまたは複数のディスプレイ・デバイスを使用して）表示することができる。たとえば、デバッガ表示プログラム（１つまたは複数）６０６は、Ｉｎｓｉｇｈｔ（ＧＤＢへのグラフィカル・ユーザ・インターフェースである）、Ｄａｔａ Ｄｉｓｐｌａｙ Ｄｅｂｕｇｇｅｒ（ＤＤＤ、ＧＤＢおよび他のデバッガなどのさまざまなコマンドライン・デバッガのグラフィカル・ユーザ・インターフェースを提供する）、および同様の適切なデバッガ表示プログラム、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
ＴＳ ６１０は、ＳＵＴ ６２０をテストするためにＨＣ ６０１によって制御される。ＴＳ ６１０は、ＴＩＳＡと一貫する形で（たとえば、図１〜図３のＴＳ １１０に関して図示し、説明したものなど）機能するように構成され、さらに、対話テスティングをサポートする（たとえば、ＨＣ ６０１上で走行するデバッガによるアクセスを使用可能にすることによって）ように構成される。
ＴＳ ６１０は、メモリ６１４に結合されたＴＩＳＡプロセッサ６１２を含む。ＴＩＳＡプロセッサ６１２は、ＳＰＡＲＣ Ｖ８（図４Ａ〜４Ｅおよび図５に関して図示し、上で説明した）、ＩＮＴＥＬ、および類似物などの任意の適切なプロセッサを使用して実施することができる。メモリ６０４は、任意の適切なメモリとすることができる。
メモリ６１４は、１つまたは複数のデバッガ・プログラム・スタブ６１５を格納する。デバッガ・プログラム・スタブ６１５は、ＨＣ ６０１上で走行する対応するデバッガ制御プログラム（１つまたは複数）６０５のデバッガ制御を理解し、これによって、ＨＣ ６０１がＴＳ ６１０と通信することを可能にする。たとえば、デバッガ・スタブ（１つまたは複数）６１５は、ＧＤＢスタブ、ＤＢＸスタブ、Ｐｅｒｌスタブ、Ｂａｓｈスタブ、Ｐｙｔｈｏｎスタブ、および同様の適切なデバッガ・プログラム・スタブ、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
メモリ６１４は、ＴＩＳＡ２進ファイル６１６を格納する。ＴＩＳＡ２進ファイル６１６は、本明細書で図２および図３に関して図示し、説明した形でＴＳ ６１０によって生成される。ＴＩＳＡ２進ファイル６１６は、ＳＵＴ ６２０に対するテスティングを実行するためにＴＩＳＡプロセッサ６１２によって実行される。
ＴＳ ６１０は、ＴＩＳＡプロセッサ６１２に結合されたテスト・アクセス・ポート（ＴＡＰ）６１８をも含む。ＴＡＰ ６１８は、ＨＣ ６０１によって制御されている間にＴＩＳＡプロセッサ６１２がＳＵＴ ６２０のテスティングを実行することを可能にするために、ＴＩＳＡプロセッサ６１２とＳＵＴ ６２０との間のテスト・インターフェースを提供する。ＴＡＰ ６１８は、任意の適切なＴＡＰ（たとえば、１１４９．１ ＴＡＰ）とすることができる。
ＴＩＳＡプロセッサ６１２は、インターフェース６１７を使用してＴＡＰ ６１８とインターフェースする。インターフェース６１７は、ＴＡＰとテストされるシステムとの間の任意の適切なインターフェース（たとえば、ＴＣＫ、ＴＭＳ、ＴＤＩ、ＴＤＯ、およびオプションでＴＲＳＴ（ＴＡＰ ６１８が１１４９．１ ＴＡＰとして実施される場合）をサポートするインターフェースなど）とすることができる。
図６に示されているように、ＨＣ ６０１とＴＳ ６１０との間にインターフェース６０９がある。インターフェース６０９は、ＨＣ ６０１とＴＳ ６１０との間のローカル通信および／またはリモート通信をサポートすることができる。したがって、ＨＣ ６０１は、ローカルにおよび／またはリモートにＴＳ ６１０を介してＳＵＴ ６２０の対話テスティングを制御することができる。
たとえば、ローカル・テスティングに関して、インターフェース６０９を、汎用非同期送受信回路（ＵＡＲＴ）インターフェース、直列インターフェース、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数として実施することができる。
たとえば、リモート・テスティングに関して、インターフェース６０９を、伝送制御プロトコル（ＴＣＰ）／インターネット・プロトコル（ＩＰ）または任意の他の適切な通信プロトコルなどの任意の適切な通信機能を使用して実施することができる。これは、ＨＣ ６０１およびＴＳ ６１０が長い地理的距離だけ分離される可能性があり、それでもＨＣ ６０１がＳＵＴ ６２０のテスティングを実行するためにＴＳ ６１０を制御することができる、リモート・テスティングを可能にする。
ＴＩＳＡベースのテスティング環境６００では、ＨＣ ６０１は、標準的な接続（たとえば、ＵＡＲＴ、ＴＣＰ／ＩＰ、および類似物）を介してＴＳ ６１０の動作を制御することによってＳＵＴ ６２０のテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。
明瞭にするために省略されてはいるが、ＨＣ ６０１およびＴＳ ６１０が、追加のプロセッサ、追加のメモリ、内部通信バス、入出力モジュール、追加のサポート回路（たとえば、電源）、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のコンポーネントを含むことができることを了解されたい。
明瞭にするために省略されてはいるが、ＳＵＴ ６２０を、ＴＩＳＡを使用してテストできる任意のテストされるシステムとすることができることを了解されたい。
主に特定のタイプのデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物に関して図示し、説明したが、ＴＩＳＡベースのテスティング環境６００を、さまざまな他のデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物、ならびにそのさまざまな組合せを使用して完全に対話的なテスティング機能を使用可能にする形で実施できることを了解されたい。
図７に、図６のＴＩＳＡベースのテスティング環境の例示的実施態様を示す。
図７に示されているように、図７の例示的なＴＩＳＡベースのテスティング環境７００は、ＧＮＵツール・スイートが図５Ａの例示的なシステム・テスト環境５００の対話テスティングをサポートするのに使用される、図６のＴＩＳＡベースのテスティング環境６００の実施態様である。
図７に示されているように、例示的なＴＩＳＡベースのテスティング環境７００は、ホスト・コンピュータ（ＨＣ）７０１、テスティング・システム（ＴＳ）７１０、およびテストされるシステム（ＳＵＴ）７２０を含む。
ＨＣ ７０１は、プロセッサ７０２およびメモリ７０４を含む。図７のＨＣ ７０１は、デバッガ制御プログラム（１つまたは複数）６０５がＧＤＢ（ＧＤＢ ７０５）を使用して実施され、デバッガ表示プログラム（１つまたは複数）６０６がＤＤＤ（ＤＤＤ ７０６）を使用して実施される、図６のＨＣ ６０１の実施態様である。
ＴＳ ７１０は、ＴＩＳＡプロセッサ７１２およびメモリ７１４を含む。図７のＴＳ ７１０は、ＴＩＳＡプロセッサ６１２がＳＰＡＲＣ Ｖ８ ＩＳＡを使用して実施され（ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２と表される）、デバッガ・プログラム・スタブ（１つまたは複数）６１５がＧＤＢスタブ（ＧＤＢスタブ７１５）を使用して実施され、ＴＩＳＡ２進ファイル６１６がＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２に関連するＳＰＡＲＣ Ｖ８ ＩＳＡに基づいて生成される（ＴＩＳＡ２進ファイル７１６）、図６のＴＳ ６１０の実施態様である。
ＴＳ ７１０は、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２に結合されたテスト・アクセス・ポート（ＴＡＰ）７１８をも含む。図７のＴＳ ７１０は、ＴＡＰ ６１８が１１４９．１ ＴＡＰ（１１４９．１ ＴＡＰ ７１８）を使用して実施される、図６のＴＳ ６１０の実施態様である。
ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２は、インターフェース７１７を使用して１１４９．１ ＴＡＰ ７１８とインターフェースする。インターフェース７１７は、ＴＣＫ、ＴＭＳ、ＴＤＩ、ＴＤＯ、およびオプションでＴＲＳＴをサポートする標準１１４９．１インターフェースである。
ＳＵＴ ７２０は、図５ＡのＳＵＴ ５２０である。ＳＵＴ ７２０は、図５ＡのＳＵＴ ５２０のように、異なる基板上の送信器および受信器を含む。
１１４９．１ ＴＡＰ ７１８は、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２がＨＣ ７０１によって制御されている間にＳＵＴ ７２０のテスティングを実行することを可能にするために、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサ７１２とＳＵＴ ７２０との間のテスト・インターフェースを提供する。
図７に示されているように、ＨＣ ７０１とＴＳ ７１０との間にインターフェース７０９がある。インターフェース７０９は、ＨＣ ７０１とＴＳ ７１０との間のローカル通信および／またはリモート通信（たとえば、ネットワークを介する）をサポートすることができる。したがって、ＨＣ ７０１は、ローカルにおよび／またはリモートにＴＳ ７１０を介してＳＵＴ ７２０の対話テスティングを制御することができる。
例示的なＴＩＳＡベースのテスティング環境７００では、ＨＣ ７０１は、インターフェース７０９を介してＴＳ ７１０の動作を制御することによってＳＵＴ ７２０に対するテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。
図７の左側のほとんどが、既存のコンピュータ・サイエンス要素すなわちＨＣ ７０１全体ならびにＴＳ ７１０上のＧＤＢスタブ７１５を再利用することを了解されたい。これは、図７の中央部分についても同一であり、中央部分では、ＨＣ ７０１とＴＳ ７１０（ならびにそれらに関連する副要素）との間の類似が明白である。ＴＩＳＡは、システム・テスティングを提供するためにこのインフラストラクチャ全体を活用することを可能にする。
例として、図５Ａのシステム・テスト環境５００（関連する例示的なＣプログラム、ＳＶＦ命令、ＴＩＳＡアセンブラ命令、およびＴＩＳＡコーディングを含む）を参照すると、（ａ）変数「ｓｅｎｔ＿ｖａｌｕｅ」および「ｒｅｃｅｉｖｅｄ＿ｖａｌｕｅ」を監視している間のステップごとの実行、（ｂ）ｔａｐに送るべき値（変数「ｓｅｎｔ＿ｖａｌｕｅ」）のオンザフライ変更、（ｃ）ループ終了条件の変更、（ｄ）すべての変数の監視、および類似物、ならびにそのさまざまな組合せなど、ＧＤＢ（または任意の他の適切なデバッガ）を活用することによってＴＩＳＡが使用可能にすることのできる多数の対話テスト動作がある。これらの対話テスト動作は、ＧＤＢの標準動作であり、ＴＩＳＡは、上で説明したアルゴリズム部分とテスト・アクセス部分との間の制御を自動的にハンドオフするＴＩＳＡの能力に起因して、これらを直接に使用することができる。ＴＩＳＡがない場合には、特殊なツーリングを開発し、各ハンドオフ実施態様に適合させる必要があるはずである。
図７の例示的なＴＩＳＡベースのテスティング環境７００を、主に、特定のテストされるシステムの対話テスティングをサポートするのにＧＮＵツール・スイートを使用することに関して本明細書で図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、ＴＩＳＡベースのテスト環境での対話テスティング機能を、任意のタイプのテストされるシステムをテストするために任意の適切なツール・スイートを使用して実現できることを了解するであろう。
図６のＴＩＳＡベースのテスティング環境６００および図７の例示的なＴＩＳＡベースのテスティング環境７００を、主に、テスティングが事前に決定されたアルゴリズムに従ってステップごとに行われる直線的なテスト手順に関して本明細書で図示し、説明したが（ＴＩＳＡによって使用可能にされる対話テスティング機能を説明する際の明瞭さのために）、ＴＩＳＡによって使用可能にされるコンピュータ・サイエンス経験およびコンピュータ・サイエンス技法の活用に起因して、他のより複雑な対話テスティング・シナリオが可能であることを了解されたい。ＴＩＳＡによって使用可能にされるより複雑な対話テスティング・シナリオの例を、図８に関して図示し、本明細書で説明する。これが、単に１つの例であり、本明細書の教示によって情報を与えられた当業者が多数の他の対話テスティング・シナリオおよび対話テスティング応用例でＴＩＳＡを使用できることを了解されたい。
本明細書で説明されるように、粒度と対話との両方をサポートすることに加えて、ＴＩＳＡは、並列性をもサポートする。
ＴＩＳＡは、システム・テスティング・フローをコンピュータ・サイエンス・ソフトウェア・フローと自然に十分に合併し、したがって、両方のフローの最良の態様を活用することができる。例として、ＳＴＡＰＬなどの手法は、定義により、完全に順次的なので、機器の並列制御を扱うのが困難である。さらに、ＭＴＣおよびＳｙｓｔｅｍＢＩＳＴなどの手法は、本質的に順次的であり、シングルタスクであり、したがって、並列性をサポートするためにそのような手法をプログラムすることは、むずかしく、不便であるはずである。対照的に、並列実行は、コンピュータ・サイエンスでは周知の問題であり、現在は、たとえば、すべてのオペレーティング・システムの根底にある。並列実行をサポートする大量のライブラリが使用可能であり（たとえば、ＰＯＳＩＸスイート、ＢＯＯＳＴスイート、および類似物）、ほとんどの現代のプロセッサは、マルチタスキングおよびコンテキスト切替を効率的にサポートするように設計されている（たとえば、たとえばＳＰＡＲＣ Ｖ８は、回転するレジスタ・ウィンドウを実施する）。ＴＩＳＡによって使用可能にされるシステム・テスティング・フローとコンピュータ・サイエンス・ソフトウェア・フローとの間の自然な相互作用は、ＴＩＳＡが並列性に対するそのようなコンピュータ・サイエンス手法を完全に活用することを可能にする。
ＴＩＳＡによる並列性機能のサポートは、例によってよりよく理解することができる。例として、図５Ａおよび図７のテストされるシステム５２０の送信器５２２と受信器５２６との間のＴ−Ｒチャネルのデータ転送速度を最適化するという問題を検討されたい。これは、第１基板５２１上の送信器５２２からデータ・パターンのストリームを送信することと、第２基板５２５上の受信器５２６でデータ・パターンの対応するストリームを受信することと、ビット速度／誤り率を計算し、それ相応に送信器５２２および／または受信器５２６のパラメータを調整するためにデータ・パターンの送信されたストリームおよび受信されたストリームを比較することとを含むはずである。この最適化を、並列に動作する３つのプログラムを使用して効率的に実行することができる。
図８に、図５Ａおよび図７のテストされるシステムの送信器−受信器チャネルの最適化を実行するための例示的プログラム・アーキテクチャを示す。
図８に示されているように、例示的なプログラム・アーキテクチャは、パターン・ジェネレータ８０２、パターン受信器８０４、およびコンパレータ８０６を含む。パターン・ジェネレータ８０２、パターン受信器８０４、およびコンパレータ８０６は、協力して、図５Ａおよび図７のテストされるシステム５２０の送信器５２２と受信器５２６との間のＴ−Ｒチャネルのデータ転送速度を最適化する。
パターン・ジェネレータ８０２は、適切な入力データ・パターンを第１基板５２１上の送信器５２２（Ｔ）に送る。パターン・ジェネレータ８０２は、第１基板５２１（Ｂ１）のスキャン・チェーン５２３を介して送信器５２２に入力データ・パターンを供給するために、ＴＡＰ（実例として、図５ＡのＴＡＰ ５１０、図７のＴＡＰ ７１８）にアクセスすることができる。パターン・ジェネレータ８０２は、任意の適切な形で（たとえば、図５Ａに関して本明細書で説明したコードの行１２〜１３で指定されるように）送信器５２２に入力データ・パターンを供給することができる。入力データ・パターンは、送信器５２２と受信器５２６との間のＴ−Ｒチャネルを最適化するのに適する任意のデータ・パターンとすることができる。たとえば、入力データ・パターンを、事前に計算されたパターン、ランダム・パターン、および類似物、ならびにそのさまざまな組合せとすることができる。
パターン受信器８０４は、第２基板５２５上の受信器５２６（Ｒ）から適切な出力データ・パターンを収集する。パターン受信器８０４は、第２基板５２５（Ｂ２）のスキャン・チェーン５２７を介して受信器５２６から出力データ・パターンを収集するために、ＴＡＰ（実例として、図５ＡのＴＡＰ ５１０、図７のＴＡＰ ７１８）にアクセスすることができる。パターン受信器８０４は、任意の適切な形で（たとえば、図５Ａに関して本明細書で説明したコードの行１４〜１５で指定されるように）受信器５２６から出力データ・パターンを収集することができる。
コンパレータ８０６は、パターン・ジェネレータ８０２およびパターン受信器８０４と通信する。コンパレータは、入力データ・パターンと出力データ・パターンとを比較する。コンパレータ８０６は、Ｔ−Ｒチャネルのビット伝送速度およびビット誤り率を評価し、この比較の結果に基づいて、Ｔ−Ｒチャネルのパラメータを最適化するために送信器５２２と受信器５２６との両方の制御レジスタ（明瞭にするために図５Ａおよび図７では省略されている）にアクセスすることができる。
そのような最適化テスティング手順を実行するために、パターン・ジェネレータ８０２、パターン受信器８０４、およびコンパレータ８０６は、並列に働く必要があり、それぞれが、他とは独立にＴＡＰにアクセスできなければならない。このタイプの制御構造は、ＴＡＰを介する１点直列ハンドオフ制御だけをサポートするように開発された伝統的な環境では、コーディングするのが非常にむずかしい。このタイプの制御構造は、やはり同一の直列ＴＡＰアクセス・パラダイムを共有するＭＴＣまたは他のそのような手法を使用する環境でも、コーディングするのが非常にむずかしい。対照的に、ＴＩＳＡは、テスト・アクセスに関するそのような仮定を伴って設計されているのではなく、ＴＩＳＡでは、テスト・アクセスが、他のプロセッサ・リソースに似た形で処理され、テスト・アクセス命令は、古典的なＩＳＡ命令と直接に混合される。ＴＩＳＡを使用すると、図８の最適化テスティング手順を、プロセス、スレッド・プロセス間通信（ＩＰＣ）、および類似物、ならびにそのさまざまな組合せなどの標準的構造を使用する任意のマルチタスキング・オペレーティング・システムによって実行することができる。この形で、パターン・ジェネレータ８０２、パターン受信器８０４、およびコンパレータ８０６は、ＴＡＰへのアクセスを共有することができ、たとえば、たとえばダイクストラのセマフォなどの周知の構造およびアルゴリズムを使用して、すべてのプロセッサ・リソースについて行われるのと同様に、すべての最終的なＴＡＰ共有問題を解決することができる。したがって、既存のシステム・テスティング機能は並列性をサポートしないが、ＴＩＳＡが簡単に完全に並列性をサポートすることは明白である。
上で説明したように、ＴＩＳＡは、テスト・アクセス方法または関連するテスト・プログラム区分に関する仮定を一切設けず、テスト命令は、テスト命令と古典的ＩＳＡ命令との間の先見的分離を全く伴わずに、古典的ＩＳＡ命令と同一の形または実質的に同一の形で扱われる。これは、ＴＩＳＡをすべての既存の（および最もありそうなことに将来の）コンピュータ・サイエンス・アルゴリズムおよびコンピュータ・サイエンス構造と完全に互換にすることを可能にし、これは、既存のテスト・プロセッサ手法がサポートできないことである。
したがって、すべての既存ソフトウェア・ライブラリをＴＩＳＡアーキテクチャに移植できることを了解されたい。たとえば、ＰＯＳＩＸスイートおよびＢＯＯＳＴスイートを活用することによって、マルチタスキングおよび並列性を入手することは、簡単であるはずである（たとえば、図８に関して本明細書で図示し、説明したように）。さらに、ＴＩＳＡが既存ＩＳＡの一般化として入手される（たとえば、図５Ａおよび図５Ｂに関して図示し、説明した例示的なＳＰＡＲＣ Ｖ８ ＴＩＳＡ実施態様に関して図示し、説明したように）場合には、ＴＩＳＡがそれから開発されたＩＳＡが既にそのようなソフトウェア・ライブラリを含むので、移植が必要でない場合さえあることを了解されたい。
さらに、さまざまな他のコンピュータ・サイエンス技法を、ＴＩＳＡを使用する改善されたシステム・テスティングを提供するために利用できることを了解されたい。たとえば、ＴＩＳＡのために活用できるそのようなコンピュータ・サイエンス技法のいくつかの例は、（ａ）プラットフォーム独立コーディング・スタイルの使用、（ｂ）ＩＳＡ対ＩＳＡコンバータの使用、（ｃ）プラットフォーム独立バイトコードを入手するための、たとえばＪａｖａのような、仮想マシン手法の使用、またはＴＩＳＡになるためのＪａｖａ仮想マシン自体の拡張の使用、および（ｄ）その後に適切なドライバによってプリミティブに変換される、いくつかのＴＩＳＡソフトウェア・インターフェースを標準化するためのアプリケーション・プログラミング・インターフェース（ＡＰＩ）の使用を含む。これらの例が、単にＴＩＳＡのために活用できるコンピュータ・サイエンス技法の少数の例であることを了解されたい。
図９に、テストされるシステムの少なくとも一部をテストする際のプロセッサによる使用のために適合されたテスト命令セット・アーキテクチャ（ＴＩＳＡ）命令を含むＴＩＳＡフローを形成するためにプロセッサの命令セット・アーキテクチャ（ＩＳＡ）フローを適合させる方法の一実施形態を示す。
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法９００のステップの少なくとも一部を、同時にまたは図９に関して図示され説明されるものとは異なる順序で実行することができる。
ステップ９０２では、方法９００が開始される。
ステップ９０４では、命令の第１セットを生成する。命令の第１セットは、プロセッサによってサポートされるＩＳＡ命令を含む（すなわち、プロセッサにＴＩＳＡを提供するために活用されるＩＳＡ命令）。
ステップ９０６では、命令の第２セットを生成する。命令の第２セットは、テストされるシステムに関連するテスト命令を含む。命令の第２セットは、たとえば図２のＴＧＴ ２１０に関して図示し、説明したように、図３のＴＧＴ ３１０に関して図示し、説明したように、および／またはテスト命令を生成する任意の他の適切な方法を使用して、任意の適切な形で生成することができる。
ステップ９０８では、命令の第１セットおよび命令の第２セットを統合して、これによってＴＩＳＡ命令を形成する。ＴＩＳＡ命令は、プロセッサにＴＩＳＡを提供する。
ステップ９１０では、ＴＩＳＡ命令を格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。ＴＩＳＡ命令を、任意の他の適切な形で処理することができる。
ステップ９１２では、方法９００が終了する。
ＴＩＳＡを、任意の適切な形で、たとえば、図１０の方法１０００に関して図示し、説明するように、図２のテスト・システムおよび図１１Ａの関連する方法１１１０に関して図示し、説明するように、図３のテスト・システムおよび図１１Ｂの関連する方法１１２０に関して図示し、説明するように、ならびに／またはＴＩＳＡを形成する任意の適切な方法を使用して、形成することができる。
図１０に、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法１０００のステップの少なくとも一部を、同時にまたは図１０に関して図示され説明されるものとは異なる順序で実行することができる。ステップ１００２で、方法１０００が開始される。
ステップ１００４では、命令の第１セットを生成する。命令の第１セットは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成される命令（たとえば、プロセッサによってサポートされるＩＳＡのＩＳＡ命令）を含む。
ステップ１００６では、命令の第２セットを生成する。命令の第２セットは、テストされるシステムに関連する少なくとも１つの記述ファイルをコンパイルすることによって生成されるテスト命令を含む。
ステップ１００８では、命令の第１セットおよび第２セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第１セットの命令が、命令の第２セットのテスト命令の実行を制御する際の使用のために適合される。
ステップ１０１０では、命令の組み合わされたセットを格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ１０１２で、方法１０００は終了する。
図１１Ａおよび図１１Ｂに、図９に関して図示し、説明した方法９００および／または図１０に関して図示し、説明した方法１０００のより詳細な実施形態を示す。
図１１Ａに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に特定のシーケンスで実行されるものとして図示され、説明されるが、図１１Ａの方法１１１０のステップの少なくとも一部を、図１１Ａに関して図示し、説明するものとは異なる順序で実行することができる。図１１Ａを、図２および図２の関連する説明と共に見ることによってよりよく理解することができる。
ステップ１１１１で、方法１０００が開始される。
ステップ１１１２では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成され（たとえば、プロセッサによってサポートされるＩＳＡのＩＳＡ命令）、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルは、少なくとも１つの呼出しを含む。
ステップ１１１３では、命令の第１セットを生成する。命令の第１セットは、プログラム・モデルを使用して生成される。少なくとも１つの計算要求も、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルに含まれる少なくとも１つの呼出しを使用して生成される。
ステップ１１１４では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも１つのシステム記述ファイルをコンパイルすることによって生成される。
ステップ１１１５では、命令の第２セットを生成する。命令の第２セットは、回路モデルおよび少なくとも１つの計算要求を使用して生成される。
ステップ１１１６では、命令の第１セットおよび第２セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第１セットの命令が、命令の第２セットのテスト命令の実行を制御する際の使用のために適合される。
ステップ１１１７では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ１１１８では、方法１０００が終了する。図１１Ｂに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に順次実行されるものとして図示され、説明されるが、図１１Ｂの方法１１２０のステップの少なくとも一部を、同時にまたは図１１Ｂに関して図示し、説明するものとは異なる順序で実行することができる。図１１Ｂを、図３および図３の関連する説明と共に見ることによってよりよく理解することができる。
ステップ１１２１で、方法１１００が開始される。
ステップ１１２２では、少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよび少なくとも１つのテスト動作記述ファイルを、少なくとも１つのコンピュータ・サイエンス・ソフトウェア・ファイルを前処理することによって生成する。
ステップ１１２３では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも１つのシステム記述ファイルおよび少なくとも１つのテスト動作記述ファイルをコンパイルすることによって生成される。
ステップ１１２４では、テスト動作のセットを生成する。テスト動作のセットは、回路モデルを使用して生成される。テスト動作のセットからのテスト動作は、テスト・プリミティブ（たとえば、回路モデルを生成するテスト生成ツールによって定義されるテスト・プリミティブ）のセットを使用して記述される。テスト・プリミティブのセットは、テストされるシステムをテストする際の使用のために適合されたテスト動作を含む。
ステップ１１２５では、テスト動作のセットのテスト・プリミティブを命令セット・アーキテクチャのソフトウェア命令と組み合わせての使用のために適合されたテスト命令に変換することによって、テスト動作のセットをテスト命令のセットに変換する。
ステップ１１２６では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよびテスト命令のセットをコンパイルすることによって生成される。
ステップ１１２７では、命令の組み合わされたセットを生成する。命令の組み合わされたセットは、プログラム・モデルを使用して生成される。命令の組み合わされたセットは、（ａ）少なくとも１つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルから決定されたソフトウェア命令および（ｂ）テスト命令のセットからのテスト命令を含む。
ステップ１１２８では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ／または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ１１２９では、方法１１２０が終了する。
図１２に、ＴＩＳＡプロセッサ・アーキテクチャの例示的実施形態を示す。
図１２に示されているように、ＴＩＳＡプロセッサ・アーキテクチャ１２００は、ＴＩＳＡプロセッサ１２１０およびメモリ１２２０を含む。
ＴＩＳＡプロセッサ１２１０は、ＳＰＡＲＣ Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、ＴＩＳＡを使用するシステム・テスティングを実行するのに適する任意のプロセッサとすることができる。
メモリ１２２０は、ランダム・アクセス・メモリ、永続メモリ、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数を含む、ＴＩＳＡを使用するシステム・テスティングをサポートするためのＴＩＳＡプロセッサ１２１０による使用に適する任意のメモリを含むことができる。メモリ１２２０は、テスト・プログラム、ＴＩＳＡ命令、テスティング・データ、および類似物、ならびにそのさまざまな組合せなど、ＴＩＳＡを使用するシステム・テスティングを実行するのに必要な任意の情報を格納することができる。
一実施形態では、たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００は、図２および図３に関して図示し、説明したＴＩＳＡフローをサポートすることができる。
一実施形態では、たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００は、図６に関して図示し、説明したテスティング・システム６１０のＴＩＳＡプロセッサ６１２およびメモリ６１４に似た形で動作することができる。たとえば、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００を、図７に関して図示し、説明したテスティング・システム７１０内など、ＳＰＡＲＣ Ｖ８ ＴＩＳＡプロセッサおよび関連するメモリを使用して実施することができる。そのような実施形態では、ＴＩＳＡプロセッサ１２１０自体が、ＩＳＡ命令とＴＩＳＡ命令との両方を解釈し、実行する。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用される装置は、テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をＴＡＰを介してテストするためにテスト命令セット・アーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セット・アーキテクチャの命令のセットは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の複数の命令を含む命令の第１セットと、ＴＡＰに関連する複数のテスト命令を含む命令の第２セットとを含み、命令の第１クラスの命令および命令の第２クラスの命令は、これによってテスト命令セット・アーキテクチャの命令のセットを形成するために統合される。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート（ＴＡＰ）を介してテストする際に使用されるＴＩＳＡプロセッサは、プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含む命令の第１クラスと、ＴＡＰに関連するテスト命令を含む命令の第２クラスとを含み、命令の第１セットのＩＳＡ命令および命令の第２セットのテスト命令は、テストされるシステムの少なくとも一部をテストするために適合されたＴＩＳＡを形成するために統合される。
一実施形態では、テストされるシステム（ＳＵＴ）をテスト・アクセス・ポート（ＴＡＰ）を介してテストするコンピュータ・プロセッサは、ＴＡＰを介するテストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セット・アーキテクチャ（ＴＩＳＡ）に従って命令を処理するように構成された回路網を含む。ＴＩＳＡは、第１タイプの複数の命令および第２タイプの複数の命令を含み、命令の第１タイプは、コンピュータ・プロセッサによってサポートされる命令セット・アーキテクチャ（ＩＳＡ）の命令を含み、命令の第２タイプは、ＴＡＰを介してテストされるシステムをテストするためのテスト命令を含む。
主にＴＩＳＡプロセッサが特定の形で（たとえば、異なるクラスおよび／またはタイプの命令を記述するのに特定の言語を使用して）定義される実施形態に関して上で図示し、説明したが、ＴＩＳＡを、本明細書で提供されるさまざまなＴＩＳＡの図示および説明によって完全にサポートされる他の形で定義できることを了解されたい。
主に、ＴＩＳＡをサポートするのに単一プロセッサを使用してＴＩＳＡプロセッサ・アーキテクチャが実施される実施形態に関して本明細書で図示され、説明されるが、他の実施形態では、ＴＩＳＡプロセッサ・アーキテクチャを、複数のプロセッサを使用して実施することができる。
図１３に、システム・テスティング機能を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す。
図１３に示されているように、テスト・プロセッサ・アーキテクチャ１３００は、通信経路１３３０を介して通信する主プロセッサ１３１０および副プロセッサ１３２０を含む。
主プロセッサ１３１０は、ＳＰＡＲＣ Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。主プロセッサ１３１０は、テストされるシステムをテストする命令を実行する。一実施形態では、たとえば、主プロセッサ１３１０は、図１２のＴＩＳＡプロセッサ・アーキテクチャ１２００のＣＰＵ １２１０によってサポートされる機能に似たテスティング機能をサポートすることができる（たとえば、テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用する場合に）。一実施形態では、たとえば、主プロセッサ１３１０は、ＴＩＳＡを利用しないテスト・プロセッサ・アーキテクチャ内のテストするプロセッサによってサポートされるテスティング機能をサポートすることができる。主プロセッサ１３１０は、さまざまな他のテスティング機能をサポートすることができる。
副プロセッサ１３２０は、ＳＰＡＲＣ Ｖ８プロセッサ、ＩＮＴＥＬプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。副プロセッサ１３２０は、テストされるシステム（明瞭さのために省略されている）へのテスト・アクセス・ポート（ＴＡＰ）インターフェースをサポートする。このＴＡＰインターフェースは、任意の適切なＴＡＰとインターフェースすることができる。たとえば、このＴＡＰインターフェースは、ＩＥＥＥ １１４９．１ ＴＡＰまたはテストされるシステムをテストするのに使用できる任意の他の適切なＴＡＰへのインターフェースを提供することができる。
主プロセッサ１３１０および副プロセッサ１３２０は、テストされるシステムの少なくとも一部のテストを実行するために協力する。
主プロセッサ１３１０は、テストされるシステムをテストするテスト命令を実行する。このテスト命令は、ＴＩＳＡのテスト命令とすることができ（テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用する場合）、あるいはＴＩＳＡに関連しないテスト命令とすることができる（テスト・プロセッサ・アーキテクチャ１３００がＴＩＳＡを利用しない場合）。主プロセッサ１３１０は、テスト命令の実行中に、テストされるシステムのＴＡＰの制御に関係する命令（たとえば、テストされるシステムのＴＡＰコントローラに入力データをロードする命令、テストされるシステムのＴＡＰコントローラから出力データを読み取る命令、および同様の命令、ならびにそのさまざまな組合せなど）を検出する。主プロセッサ１３１０は、副プロセッサ１３２０にＴＡＰ関連命令を供給する。副プロセッサ１３２０は、主プロセッサ１３１０からそのＴＡＰ関連命令を受け取る。副プロセッサ１３２０は、そのＴＡＰ関連命令を実行する。主プロセッサ１３１０は、副プロセッサ１３２０が主プロセッサ１３１０から受け取ったＴＡＰ関連命令を実行する間に、テスト命令の実行を継続する。この形で、主プロセッサ１３１０は、副プロセッサ１３２０がテストされるシステムのＴＡＰを介するスキャン動作を制御する間に、コンテキスト切替を実行し、動作を継続することができる。これは、単一プロセッサ手法を使用すると困難である。というのは、単一プロセッサがＴＡＰを制御している間に、その単一プロセッサが、他の動作の実行を止められるからである。したがって、テスト・プロセッサ・アーキテクチャ１３００内のような複数プロセッサの使用は、特にＴＡＰを介する動作が通常はプロセッサが単一の動作を実行するのに要する時間と比較して長い時間を要することを考慮すると、ハイエンド・プロセッサを使用する必要なしにテスティング効率の大幅な改善を提供する。
テストされるシステムの少なくとも一部のテストを実行するための主プロセッサ１３１０と副プロセッサ１３２０との間の協力は、通信経路１３３０によって容易にされる。通信経路１３３０は、主プロセッサ１３１０と副プロセッサ１３２０との間通信の任意の適切な手段を使用して実施することができ、この手段は、テスト・プロセッサ・アーキテクチャ１３００がそれを用いて実施されるマルチプロセッサ・アーキテクチャのタイプに依存する可能性がある。たとえば、通信経路１３３０は、メイン・プロセッサ・インターフェース・バス、補助プロセッサ・インターフェース、通信インターフェース（たとえば、シリアライザ−デシリアライザ（ＳＥＲＤＥＳ）インターフェースまたは他の適切な通信インターフェース）、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
明瞭さのために省略されているが、テスト・プロセッサ・アーキテクチャ１３００が、メモリ（たとえば、ランダム・アクセス・メモリ、永続メモリ、キャッシュ・メモリ、および類似物、ならびにそのさまざまな組合せ）を含むことを了解されたい。テスト・プロセッサ・アーキテクチャ１３００のメモリは、主プロセッサ１３１０および副プロセッサ１３２０によって共有されるメモリ、主プロセッサ１３１０に専用のメモリ、副プロセッサ１３２０に専用のメモリ、および類似物、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
明瞭さのために省略されているが、テスト・プロセッサ・アーキテクチャ１３００が、バス、Ｉ／Ｏ回路、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のサポート回路を含むことができることを了解されたい。
図１３のテスト・プロセッサ・アーキテクチャ１３００を、複数の形で実施することができる。
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置（ＣＰＵ）がシステム・テスティングをサポートするためにテスト・コプロセッサ・ユニット（ＴＣＰＵ）と協力する、テスト・コプロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図１４に関して図示し、説明する。
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置（ＣＰＵ）がシステム・テスティングをサポートするためにテスト付属プロセッサ・ユニット（ＴＡＰＵ）と協力する、テスト付属プロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図１５に関して図示し、説明する。
図１４に、テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す。テスト・コプロセッサ・アーキテクチャ１４００は、ＴＩＳＡを使用するシステム・テスティングをサポートするためのＴＩＳＡプロセッサ・アーキテクチャとしての使用に適する。テスト・コプロセッサ・アーキテクチャ１４００は、ＴＩＳＡを使用しないシステム・テスティングをサポートするためのテスト・プロセッサ・アーキテクチャとしての使用にも適する。
テスト・コプロセッサ・アーキテクチャ１４００は、中央処理装置（ＣＰＵ）１４１０、テスト・コプロセッサ・ユニット（ＴＣＰＵ）１４２０、メイン・メモリ１４３０、およびフラッシュ・メモリ１４４０を含む。
テスト・コプロセッサ・アーキテクチャ１４００は、メイン・プロセッサ・インターフェース・バス１４５１を含む。ＣＰＵ １４１０、ＴＣＰＵ １４２０、メイン・メモリ１４３０、およびフラッシュ・メモリ１４４０は、それぞれ、メイン・プロセッサ・インターフェース・バス１４５１に結合される（または、他の形でこれと通信できるように構成される）。
テスト・コプロセッサ・アーキテクチャ１４００は、補助プロセッサ・インターフェース１４５２をも含むことができ、補助プロセッサ・インターフェース１４５２は、ＣＰＵ １４１０およびＴＣＰＵ １４２０を直接に結合し、これによって、ＣＰＵ １４１０とＴＣＰＵ １４２０との間の直接通信を可能にする。
ＣＰＵ １４１０は、テストされるシステムのシステム・テスティングを実行するのに適する任意のＣＰＵとすることができる。ＣＰＵ １４１０は、図１３に関して図示し、説明した主プロセッサ１３１０によってサポートされるテスティング機能をサポートする。
ＴＣＰＵ １４２０は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のＣＰＵとすることができる。ＴＣＰＵ １４２０は、テスト・アクセス・ポート（ＴＡＰ）インターフェース１４６０をサポートし、ＴＡＰインターフェース１４６０は、任意の適切なＴＡＰ（たとえば、ＩＥＥＥ １１４９．１ ＴＡＰまたはテストされるシステムをテストするのに使用される任意の他の適切なＴＡＰなど）とインターフェースすることができる。ＴＣＰＵ １４２０は、図１３に関して図示し、説明した副プロセッサ１３２０によってサポートされるテスティング機能をサポートする。
ＣＰＵ １４１０およびＴＣＰＵ １４２０は、図１３に関して図示し、説明した主プロセッサ１３１０および副プロセッサ１３２０に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。ＣＰＵ １４１０およびＴＣＰＵ １４２０は、ＴＣＰＵ １４２０がテスティング中にテストされるシステムのＴＡＰを制御するＴＡＰ関連命令を実行する間にＣＰＵ １４１０がテスト命令を処理する動作を継続することを可能にするために、命令例外処理を利用する。
ＣＰＵ １４１０は、テストされるシステムをテストするテスト命令を実行する。ＣＰＵ １４１０は、テスト命令の実行中に命令例外（すなわち、テストされるシステムのＴＡＰの制御に関係する命令）を検出し、その命令例外をＴＣＰＵ １４２０に供給する。ＴＣＰＵ １４２０は、ＣＰＵ １４１０からその命令例外を受け取り、その命令例外を処理し、ＴＣＰＵ １４２０が、ＣＰＵ １４１０が他のタスク（たとえば、他のテスティング命令の実行）を実行するために動作し続ける間にその命令例外を処理できるようになっている。言い換えると、ＣＰＵ １４１０およびＴＣＰＵ １４２０は、システム・テスティング中に協力し、ＴＣＰＵ １４２０がＣＰＵ １４１０によって検出された命令例外を処理する間にＣＰＵ １４１０がコンテキストを切り替え、他のタスクを実行するために動作し続けられるようにし、これによって、システム・テスティング効率を改善する。
一実施形態では、ＣＰＵ １４１０は、たとえばＣＰＵ １４１０の性能を改善するために、キャッシュ１４１１を含む。
一実施形態では、ＴＣＰＵ １４２０は、直接メモリ・アクセス（ＤＭＡ）ユニット１４２１を含み、ＤＭＡユニット１４２１は、システム・テスティングをサポートして使用するのに適する任意のタイプのＤＭＡユニットとすることができる。一実施形態では、たとえば、ＤＭＡユニット１４２１は、スキャッタ／ギャザ（Ｓ／Ｇ）ＤＭＡユニットである。ＴＣＰＵ １４２０は、ＣＰＵ １４１０から受け取った命令例外を処理するためおよびメモリ内に格納された実体的なデータに効率的にアクセスするためにＤＭＡユニット１４２１を利用することができる。一実施形態では、ＣＰＵ １４１０は、命令例外に出会う前に、Ｓ／Ｇ ＤＭＡテーブルを構成することができる。
一実施形態では、ＴＣＰＵ １４２０は、特殊化されたＴＣＰＵ命令のセットをサポートする。特殊化されたＴＣＰＵ命令のセットは、ＴＡＰアクセスおよびＴＡＰ制御をサポートすることができる。特殊化されたＴＣＰＵ命令のセットを、ＴＡＰ状態機械に対して特定のＴＡＰ動作を実行するためにＴＣＰＵ １４２０によって使用することができる。
ＣＰＵ １４１０およびＴＣＰＵ １４２０は、ＣＰＵ １４１０によるテスト命令の実行、ＴＣＰＵ １４２０による命令例外処理、ＴＣＰＵ １４２０によるＴＣＰＵ命令の実行、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ１４３０および／またはフラッシュ・メモリ１４４０を利用する。メイン・メモリ１４３０は、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ１４４０は、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の永続メモリとすることができる。ＣＰＵ １４１０およびＴＣＰＵ １４２０は、調停されるアクセスを用いてメモリを共有する。ＣＰＵ １４１０およびＴＣＰＵ １４２０は、情報を交換するためにメモリを共有することもできる。主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、ＣＰＵ １４１０およびＴＣＰＵ １４２０によって実行される機能をサポートするために使用できることを了解されたい。
ＣＰＵ １４１０およびＴＣＰＵ １４２０は、ＣＰＵ １４１０とＴＣＰＵ １４２０との間の通信、ＣＰＵ １４１０および／またはＴＣＰＵ １４２０とテスト・コプロセッサ・アーキテクチャ１４００の他のコンポーネント（たとえば、メイン・メモリ１４３０、フラッシュ・メモリ１４４０、および他のコンポーネント）との間の通信、および類似物、ならびにそのさまざまな組合せを使用して、テストされるシステムのテスティングを実行する。この通信を、メイン・プロセッサ・インターフェース・バス１４４１および補助プロセッサ・インターフェース１４５２の一方または両方を使用してサポートすることができる。ＣＰＵ １４１０とＴＣＰＵ １４２０との間の通信は、命令例外通知、割込みアクセス、ＤＭＡ調停、および類似物、ならびにそのさまざまな組合せに関連する通信を含むことができる。ＣＰＵ １４１０およびＴＣＰＵ １４２０とテスト・コプロセッサ・アーキテクチャ１４００の他のコンポーネントとの間の通信は、メモリからの読取、メモリへの書込、および／またはテストされるシステムをテストするのを支援して実行できる任意の他のタスクに関連する通信を含むことができる。
図１５に、テスト付属プロセッサ・アーキテクチャの例示的実施形態を示す。テスト付属プロセッサ・アーキテクチャ１５００は、ＴＩＳＡを使用するシステム・テスティングをサポートするＴＩＳＡプロセッサ・アーキテクチャとしての使用に適する。テスト付属プロセッサ・アーキテクチャ１５００は、ＴＩＳＡを使用しないシステム・テスティングをサポートするテスト・プロセッサ・アーキテクチャとしての使用にも適する。
テスト付属プロセッサ・アーキテクチャ１５００は、中央処理装置（ＣＰＵ）１５１０およびテスト付属プロセッサ・ユニット（ＴＡＰＵ）１５２０を含む。ＣＰＵ １５１０およびＴＡＰＵ １５２０は、同一基板上に存在することができ、あるいは、異なる基板上に存在することができる。
ＣＰＵ １５１０は、テストされるシステムのシステム・テスティングを実行するのに適する任意のＣＰＵとすることができる。ＣＰＵ １５１０は、図１３に関して図示し、説明した主プロセッサ１３１０によってサポートされるテスティング機能をサポートする。
ＣＰＵ １５１０は、それに関連するメイン・メモリ１５３０Ｍ、フラッシュ・メモリ１５３０Ｆ、および入出力モジュール１５４０を有する。ＣＰＵ １５１０は、それに関連するメイン・プロセッサ・インターフェース・バス１５５０を有する。ＣＰＵ １５１０、メイン・メモリ１５３０Ｍ、フラッシュ・メモリ１５３０Ｆ、および入出力モジュール１５４０は、それぞれ、メイン・プロセッサ・インターフェース・バス１５５０に結合される（または、他の形でこれと通信できるように構成される）。
一実施形態では、ＣＰＵ １５１０は、たとえばＣＰＵ １５１０の性能を改善するために、キャッシュ１５１１を含む。
ＴＡＰＵ １５２０は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のＣＰＵとすることができる。ＴＡＰＵ １５２０は、入出力モジュール１５２１を含む。ＴＡＰＵ １５２０は、テスト・アクセス・ポート（ＴＡＰ）インターフェース１５９０をサポートし、ＴＡＰインターフェース１５９０は、任意の適切なＴＡＰ（たとえば、ＩＥＥＥ １１４９．１ ＴＡＰまたはテストされるシステムをテストするのに使用される任意の他の適切なＴＡＰなど）とインターフェースすることができる。ＴＡＰＵ １５２０は、図１３に関して図示し、説明した副プロセッサ１３２０によってサポートされるテスティング機能をサポートする。
ＴＡＰＵ １５２０は、それに関連するローカル・テスト・メモリ１５６０を有する。ＴＡＰＵ １５２０は、それに関連する内部インターフェース・バス１５７０を有する。ＴＡＰＵ １５２０およびローカル・テスト・メモリ１５６０は、それぞれ、内部インターフェース・バス１５７０に結合される（または、他の形でこれと通信できるように構成される）。
ＣＰＵ １５１０に関連する入出力モジュール１５４０およびＴＡＰＵ １５２０の入出力モジュール１５２１は、ＣＰＵ １５１０とＴＡＰＵ １５２０との間の通信を使用可能にする通信インターフェース１５８０をサポートする。通信インターフェース１５８０は、ＣＰＵ １５１０からＴＡＰＵ １５２０へのＴＡＰ関連通信のストリーミングをサポートする。
一実施形態では、ＣＰＵ １５１０に関連する入出力モジュール１５４０およびＴＡＰＵ １５２０の入出力モジュール１５２１は、シリアライザ−デシリアライザ（ＳＥＲＤＥＳ）通信機能をサポートし、したがって、通信インターフェース１５８０は、ＳＥＲＤＥＳベースの通信インターフェースである。この実施形態では、ＳＥＲＤＥＳベースの通信インターフェース１５８０を、任意の適切なＳＥＲＤＥＳ通信プロトコル（たとえば、ギガビット・イーサネット（ＧｉｇＥ）、Ｓｅｒｉａｌ Ｒａｐｉｄ ＩＯ（ＳＲＩＯ）、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）、および類似物など）を使用して実施することができる。主にＣＰＵ １５１０とＴＡＰＵ １５２０との間のＳＥＲＤＥＳベースの通信の使用に関して図示され、本明細書で説明されるが、他の適切な通信機能を、ＣＰＵ １５１０とＴＡＰＵ １５２０との間の通信をサポートするために使用することができる。
ＣＰＵ １５１０およびＴＡＰＵ １５２０は、図１３に関して図示し、説明した主プロセッサ１３１０および副プロセッサ１３２０に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。ＣＰＵ １５１０およびＴＡＰＵ １５２０は、ＴＡＰＵ １５２０がテスティング中にテストされるシステムのＴＡＰを制御するＴＡＰ関連命令を実行する間にＣＰＵ １５１０がテスト命令を処理するために動作を継続することを可能にするために、通信インターフェース１５８０を介するコマンド・ストリーミングを利用する。
ＣＰＵ １５１０は、テストされるシステムをテストするテスト命令を実行する。ＣＰＵ １５１０は、それらのテスト命令の実行中に、テストされるシステムのＴＡＰの制御に関係する命令を検出する。ＣＰＵ １５１０は、それらのＴＡＰ関連命令を通信インターフェース１５８０を介してＴＡＰＵ １５２０に（すなわち、通信インターフェース１５８０を介する伝搬のために、ＣＰＵ １５１０からメイン・プロセッサ・インターフェース・バス１５５０を介して入出力モジュール１５４０に）伝搬させる。ＴＡＰＵ １５２０は、ＣＰＵ １５１０からＴＡＰ関連命令を受け取り、ＣＰＵ １５１０が他のタスク（たとえば、他のテスティング命令の実行）を実行するために動作し続ける間にＴＡＰＵ １５２０がＴＡＰの制御を処理できるように、それらのＴＡＰ関連命令を処理する。言い換えると、ＣＰＵ １５１０およびＴＡＰＵ １５２０は、ＴＡＰＵ １５２０がＣＰＵ １５１０によって検出されたＴＡＰ関連命令を処理する間にＣＰＵ １５１０がコンテキストを切り替え、他のタスクを実行するために動作し続けられるように、システム・テスティング中に協力し、これによってシステム・テスティング効率を改善する。
一実施形態では、ＣＰＵ １５１０によって検出され、ＴＡＰＵ １５２０によって処理されるＴＡＰ関連命令は、ＴＡＰＵ １５２０への伝搬のためにＣＰＵ １５１０によってパケット化される。
一実施形態では、ＣＰＵ １５１０によって検出され、ＴＡＰＵ １５２０によって処理されるＴＡＰ関連命令は、ＴＡＰＵ １５２０によってサポートされるオペコードを含む。１つのそのような実施形態では、ＴＡＰ関連命令は、ＣＰＵ １５１０に関連するメモリとＴＡＰＵ １５２０に関連するメモリとの間（たとえば、メイン・メモリ１５３０Ｍとローカル・テスト・メモリ１５６０との間）でブロック・メモリ・コピーを実行する際の使用に適合された１つまたは複数の拡張コマンドを含むこともできる。
ＣＰＵ １５１０は、テスト命令の実行、ＴＡＰ関連命令の検出、ＴＡＰ関連命令のパケット化、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ１５３０Ｍおよび／またはフラッシュ・メモリ１５３０Ｆを利用する。メイン・メモリ１５３０Ｍは、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ１５３０Ｆは、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の永続メモリとすることができる。
ＴＡＰＵ １５２０は、ＣＰＵ １５１０から受け取ったＴＡＰ関連命令の格納、ＣＰＵ １５１０から受け取ったＴＡＰ関連命令の処理、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにローカル・テスト・メモリ１５６０を利用する。ローカル・テスト・メモリ１５６０は、任意の適切なプロセッサ・メモリとすることができる。一実施形態では、ローカル・テスト・メモリ１５６０を、比較的小さくすることができる。というのは、ローカル・テスト・メモリ１５６０が、スキャン・チェーン全体（オンチップ・メモリ内で要求される場合があるように）ではなく、テストされるシステムのスキャン・チェーンのスキャン・チェーン・セグメントの処理を扱うからである。
主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、ＣＰＵ １５１０およびＴＡＰＵ １５２０によって実行される機能をサポートするために使用できることを了解されたい。
主にＴＩＳＡを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、ＴＩＳＡを、任意の適切なプロセッサ・アーキテクチャを使用して実施でき、このプロセッサ・アーキテクチャが、コプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャ以外のプロセッサ・アーキテクチャを含むことができることを了解されたい。したがって、ＴＩＳＡプロセッサ・アーキテクチャを、さまざまな他の形で複数のプロセッサを使用して実施することができ、これらの形のうちの少なくともいくつかは、ＴＩＳＡをサポートするための３つ以上のプロセッサの使用を含むことができる。
主にＴＩＳＡアーキテクチャを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、コプロセッサ・アーキテクチャおよび付属プロセッサ・アーキテクチャを、それぞれ、他のタイプのテスティング・アーキテクチャ（すなわち、ＴＩＳＡを使用しない他のテスティング・アーキテクチャ）を実施するのに使用できることを了解するであろう。
テスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャは、それぞれがＴＩＳＡを２つの通信するプロセッサによって実行することを可能にするという点で機能的に似ていることを了解されたい。所与のアプリケーションで、この２つのアーキテクチャの間の選択は、使用可能なリソース、コスト、性能、物理的制約（同一チップ内、異なるチップおよび／または基板内での統合、あるいはその任意の組合せ）、ならびに任意の他の実施態様パラメータなど、実施態様依存パラメータを基礎として設計者が行うことができる。主にテスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャに関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、これらの実施態様考慮事項が、すべての他のタイプのテスティング・アーキテクチャ／インフラストラクチャにあてはまることを了解するであろう。
図示され、本明細書で説明されるＴＩＳＡプロセッサ・アーキテクチャは、システム・テスティングを実行する際に使用されるすべての適切なＴＩＳＡを使用することができる。
ＴＩＳＡプロセッサ・アーキテクチャと共に使用されるように適合されたＴＩＳＡの１つの例示的実施形態の説明が、これに続く。ＴＩＳＡのこの例示的実施形態は、図示され、本明細書で説明されるスキャン・セグメント・レベル・プリミティブの実施態様である。スキャン・セグメント・レベル抽象化レベルでは、テストされるシステムのスキャン・チェーン全体が、セグメントに分割され、これらのセグメントは、アルゴリズムのデータ・アトムとして使用される。テストされるシステムを、アルゴリズム開発者（人間および／または自動化ツールとすることができる）によってスキャン・セグメントに区分できることを了解されたい。スキャン動作をスキャン・セグメント・レベルで実行することを可能にするためのＴＩＳＡの使用のより一般的な説明すなわち、この例示的なＴＩＳＡ実施態様とは独立な説明を、下で詳細に提供する。
ＴＩＳＡの次の実施形態は、これらのスキャン・セグメントを定義し、処理することのできるレジスタおよび命令のセットを処理する。次の実施形態は、３２ビット・サイズのＴＩＳＡに基づくが、これを任意の他の語サイズ（たとえば、１６ビット、６４ビット、または任意の他の適切な語サイズ）に適合させることができる。
図１６に、ＴＩＳＡプロセッサによって使用できる例示的なレジスタ・セットを示す。例示的なＴＩＳＡは、それぞれ図１６Ａ〜１６Ｄに示された、４つのレジスタ・セット（レジスタ・セットＲ１からＲ４と表される）を含む。
図１６Ａに示されているように、第１レジスタ・セットＲ１は、次のユーザ・アクセス可能データ・レジスタを含む。
・ＳｔａｔｕｓＲｅｇｉｓｔｅｒ 状況状態情報を含む３２ビット・レジスタ
・ＣｏｎｔｒｏｌＲｅｇｉｓｔｅｒ コマンド・エンコーディングを含む３２ビット・レジスタ
・ＢｌｏｃｋＲｅｇｉｓｔｅｒ スキャン・データ・イン（ギャザ・データ）およびデータ・アウト（スキャッタ・データ）を書き込むべき場所を間接的にポイントする事前にフォーマットされたデータ構造へのメモリ内のオフセットを含む３２ビット・レジスタ［スキャッタ／ギャザ・セグメント記述にアクセスするすべてのスキャン動作および比較動作に使用される］
・ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ スキャンされるべきままである現在のビット数が常駐する３２ビット・レジスタ（ブロック・モード・オペコードのスキャッタ／ギャザ・セグメント記述から自動的に取り込まれもする）
・ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ スキャン動作のｓｔａｒｔＳｔａｔｅ、ｓｃａｎＳｔａｔｅ、およびｅｎｄＳｔａｔｅを表す４ビットの３つのバンクを含む３２ビット・レジスタ。４ビットは、ＴＡＰ状態機械の１６個の状態のエンコーディングを表す（ブロック・モードでスキャッタ／ギャザ・セグメント記述から取り込まれもする）
・ＵｓｅｒＤａｔａＲｅｇｉｓｔｅｒｓ［１〜１１］ 小さいスキャン動作およびデータ再利用のためのスキャン・セグメント・データを含む３２ビット・レジスタ（ソース・レジスタまたは宛先レジスタになることができる）
図１６Ｂに示されているように、第２レジスタ・セットＲ２は、次の内部スクラッチ・レジスタを含む。
・ＢｌｏｃｋＰｏｉｎｔｅｒＲｅｇｉｓｔｅｒ ＭｕｌｔｉｐｌｅＳｃａｎ命令中に処理される現在のスキャッタ／ギャザ・セグメント記述参照をポイントする３２ビット・レジスタ
・ＢｌｏｃｋＣｏｕｎｔＲｅｇｉｓｔｅｒ ＭｕｌｔｉｐｌｅＳｃａｎ命令中に処理されるスキャッタ／ギャザ・セグメント記述のカウントを含む３２ビット・レジスタ
・ＩｎｓｔｒｕｃｔｉｏｎＲｅｇｉｓｔｅｒ 現在のオペコードがデコーディングのために置かれる３２ビット・レジスタ
図１６Ｃに示されているように、第３レジスタ・セットＲ３は、次のスキャッタ／ギャザ・セグメント記述レジスタを含む。
・ＢｌｏｃｋＯｆｆｓｅｔＦｉｅｌｄ ６４ビット・アーキテクチャが使用される時のアドレスのバンクを記述する３２ビット数
・ＳｃａｎＬｅｎｇｔｈＦｉｅｌｄ このセグメントについてスキャンすべきビット数を指定する３２ビット数
・ＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄ それぞれこのスキャン動作の開始状態、スキャン状態、および終了状態を表す４ビットの３つのフィールド（各４ビットは、１６状態ＴＡＰ状態機械状態を表す）
・ＳｏｕｒｃｅＬｏｃａｔｉｏｎＦｉｅｌｄ ＴＤＩデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＤｅｓｔｉｎａｔｉｏｎＬｏｃａｔｉｏｎＦｉｅｌｄ ＴＤＯデータがメモリ内で格納される場所に関する３２ビット・ベース・アドレス
・ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄ 期待されるベクトルがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＲｅｓｐｏｎｓｅＬｏｃａｔｉｏｎＦｉｅｌｄ 取り込まれたＴＤＩデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＭａｓｋＦｉｅｌｄ 比較動作を制限するのに使用されるＭＡＳＫデータがメモリ内のどこに存在するのかに関する３２ビット・ベース・アドレス
・ＲｅｓｕｌｔＬｏｃａｔｉｏｎＦｉｅｌｄ 比較の結果がメモリ内で格納される場所に関する３２ビット・ベース・アドレス
図１６Ｄに示されているように、第４レジスタ・セットＲ４は、次のマルチブロック・スキャッタ／ギャザ・セグメント記述レジスタを含む。
・ＢｌｏｃｋＯｆｆｓｅｔＦｉｅｌｄ ６４ビット・アーキテクチャが使用される時のアドレスのバンクを記述する３２ビット数
・ＢｌｏｃｋＣｏｕｎｔＦｉｅｌｄ このＭｕｌｔｉＢｌｏｃｋスキャンによって表されるスキャン・セグメントの個数を定義する３２ビット数（ＭｕｌｔｉＢｌｏｃｋスキャン動作中にＢｌｏｃｋＣｏｕｎｔＲｅｇｉｓｔｅｒを初期化するのに使用される）
・ＳｃａｔｔｅｒＧａｔｈｅｒＯｐｃｏｄｅＦｉｅｌｄ 関連するＳｃａｔｔｅｒＧａｔｈｅｒＢｌｏｃｋＦｉｅｌｄによってポイントされるスキャッタ／ギャザ・セグメント記述に使用される３２ビット・コマンド・オペコード
・ＳｃａｔｔｅｒＧａｔｈｅｒＢｌｏｃｋＦｉｅｌｄ 前のＳｃａｔｔｅｒＧａｔｈｅｒＯｐｃｏｄｅＦｉｅｌｄに関連するスキャッタ／ギャザ・セグメント記述がメモリ内で配置される場所に関する３２ビット・アドレス
例示的なＴＩＳＡレジスタ・セットを、任意の適切な形で変更できることを了解されたい。たとえば、例示的なレジスタ・セットのそれぞれを、より少数の、より多数の、および／または異なるレジスタを含むように変更することができる。たとえば、例示的なレジスタを、より少数の、より多数の、および／または異なるセットに再グループ化することができる。たとえば、より少数の、より多数の、および／または異なるレジスタ・セットを使用することができる。言い換えると、例示的なＴＩＳＡレジスタ・セットを、ＴＩＳＡプロセッサ・アーキテクチャを実施するためにＴＩＳＡ命令セットと共に使用するのに適する任意の他のＴＩＳＡレジスタ・セット（１つまたは複数）に置換することができる。
例示的なＴＩＳＡは、システム・テスティングを実行する際に使用される任意の適切なＴＩＳＡ命令セット（すなわち、コマンド辞書）を使用することができる。
例示的なＴＩＳＡ命令セットは、次のオペコードを含み、これらのオペコードは、図１６Ａ〜１６Ｄに関して図示され、説明されたレジスタ・セットＲ１からＲ４ならびに図示され、本明細書で説明されるオリジナルＩＳＡレジスタ・セットを操作するのに利用することができる。
ＳｔａｔｅＴｒａｎｓｉｔｉｏｎ ＜ＴＭＳ Ｖａｌｕｅ＞，＜ＴＣＫ ｃｙｃｌｅｓ＞
・このオペコードは、所与の個数のＴＣＫクロック・サイクルの間にＴＭＳの値を使用してＴＡＰ状態機械をトラバースするのに使用される。このオペコードは、ＴＡＰ状態機械の状態の間で一般的な状態遷移を実行するのに使用される。＜ＴＭＳ Ｖａｌｕｅ＞は、単一ビットを表し、＜ＴＣＫ ｃｙｃｌｅｓ＞は、オペコードの残りのデータ・ビットを表す。
ＲｕｎＴｅｓｔ ＜ｓｔａｒｔＳｔａｔｅ＞，＜ｔｅｓｔＳｔａｔｅ＞，＜ｅｎｄＳｔａｔｅ＞
・このオペコードは、＜ｓｔａｒｔＳｔａｔｅ＞から＜ｔｅｓｔＳｔａｔｅ＞に遷移し、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒによって指定される個数のＴＣＫサイクルの間に＜ｔｅｓｔＳｔａｔｅ＞でループするのに使用される。このオペコードは、ルーピングの結末として＜ｅｎｄＳｔａｔｅ＞に遷移するのに使用される。
ＳｃａｎＲｅｇｉｓｔｅｒ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞］
・このオペコードは、ユーザ・データ・レジスタ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞内のデータをスキャンし、取り込まれた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞が存在する場合には、存在するならば最終的に＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞を使用して、取り込まれた値をこれと比較し、それに従ってエラーを送出する。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。
ＳｃａｎＲｅｇｉｓｔｅｒＺｅｒｏ ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞］
・このオペコードは、すべて「０」のベクトル値をスキャンし、取り込まれた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞および＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞は、ＳｃａｎＲｅｇｉｓｔｅｒ命令と同様に使用される。
ＳｃａｎＲｅｇｉｓｔｅｒＯｎｅ ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞［，＜ｅｘｐｅｃｔｅｄ ｒｅｇｉｓｔｅｒ＞］［，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞］
・このオペコードは、すべて「１」のベクトルをスキャンし、取り込まれた値をユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に格納するのに使用される。スキャンされるビット数は、ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒ内で定義される（０＜＝ｎ＜３２）。開始状態、スキャン状態、および終了状態は、ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒ内で定義される。＜ｅｘｐｅｃｔｅｄ＿ｒｅｇｉｓｔｅｒ＞および＜ｍａｓｋ＿ｒｅｇｉｓｔｅｒ＞は、ＳｃａｎＲｅｇｉｓｔｅｒ命令と同様に使用される。
ＳｃａｎＢｌｏｃｋ
・このオペコードは、ＳＵＴに対してＢｌｏｃｋＲｅｇｉｓｔｅｒによってポイントされるデータをスキャンし、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定する。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＴＤＯからのデータは、保存されない。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＣａｐｔｕｒｅ
・このオペコードは、ＳＵＴに対してＢｌｏｃｋＲｅｇｉｓｔｅｒによってポイントされるデータをスキャンし、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定する。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＴＤＯから取り込まれたデータは、保存される。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＺｅｒｏＣａｐｔｕｒｅ
・このオペコードは、ＳＵＴに対してすべて「０」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、ＢｌｏｃｋＲｅｇｉｓｔｅｒによって定義されるレジスタに結果を取り込む。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＺｅｒｏ
・このオペコードは、ＳＵＴに対してすべて「０」のデータ・ベクトルをスキャンするのに使用され、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、結果は取り込まれない。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＯｎｅＣａｐｔｕｒｅ
・このオペコードは、ＳＵＴに対してすべて「１」のデータ・ベクトルをスキャンし、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、ＢｌｏｃｋＲｅｇｉｓｔｅｒによって定義されるレジスタに結果を取り込む。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
ＳｃａｎＢｌｏｃｋＯｎｅ
・このオペコードは、ＳＵＴに対してすべて「１」のデータ・ベクトルをスキャンし、＜ｓｔａｒｔＳｔａｔｅ＞で始めて、＜ｓｃａｎＳｔａｔｅ＞のデータをスキャンするのに使用され、＜ｅｎｄＳｔａｔｅ＞は、そのブロックのＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄによって定義される動作状態を最終決定し、結果は取り込まれない。ＳｃａｎＳｔａｔｅＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｔａｔｅＴｒａｖｅｒｓａｌＦｉｅｌｄからのデータが取り込まれる。ＳｃａｎＬｅｎｇｔｈＲｅｇｉｓｔｅｒには、スキャン動作の前にＳｃａｎＬｅｎｇｔｈＦｉｅｌｄからのデータが取り込まれる。ＥｘｐｅｃｔｅｄＶａｌｕｅＦｉｅｌｄおよびＭａｓｋｆｉｅｌｄがセットされている場合には、それに従って比較およびエラー生成が行われる。
例示的なＴＩＳＡ命令セットは、明示的な値を使用する次のレジスタ変更命令を含む。
ＬｏａｄＲｅｇｉｓｔｅｒＥｘｐｌｉｃｉｔ ＜ｃｏｎｓｔ ｖａｌｕｅ＞，＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞
・この命令は、＜ｃｏｎｓｔ ｖａｌｕｅ＞の定数値を、＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタにロードする。
ＣｏｐｙＲｅｇｉｓｔｅｒ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この命令は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞として名前を指定されたレジスタの内容を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞によって名前を指定されたレジスタにコピーする。
例示的なＴＩＳＡ命令セットは、暗黙の値を使用する次のレジスタ変更命令含む。
ＬｏａｄＲｅｇｉｓｔｅｒＩｍｐｌｉｃｉｔ ＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞，＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞
・この命令は、名前を指定された＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞内の値を、実際のデータが存在するメモリ位置へのポインタ参照として使用し、参照された値を＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタに格納する。
例示的なＴＩＳＡ命令セットは、次のレジスタ保存命令を含む。
ＳｔｏｒｅＲｅｇｉｓｔｅｒＩｍｐｌｉｃｉｔ ＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞，＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞
・この命令は、名前を指定された＜ｕｓｅｒ ｄａｔａ ｒｅｇｉｓｔｅｒ＞内の値を、＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタ内の値が格納されるメモリ位置へのポインタ参照として使用する。
ＳｔｏｒｅＲｅｇｉｓｔｅｒＥｘｐｌｉｃｉｔ ＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞，＜ｃｏｎｓｔ ｖａｌｕｅ＞
・この命令は、＜ｒｅｇｉｓｔｅｒ ｎａｍｅ＞によって名前を指定されたレジスタの値を、＜ｃｏｎｓｔ ｖａｌｕｅ＞によって指定されるメモリ位置に格納する。
例示的なＴＩＳＡ命令セットは、次の、レジスタに対する論理演算を含む。
ＡＮＤ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＡＮＤ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＯＲ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＸＯＲ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞と＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＸＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＮＯＴ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞に対して論理ＮＯＴ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。
ＸＯＲＭ ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞，＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞，＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞
・この演算は、「１」の値を含むユーザ・データ・レジスタ＜ｍａｓｋ ｒｅｇｉｓｔｅｒ＞ビットと位置が合っているビットだけを比較しながらユーザ・データ・レジスタ＜ｓｏｕｒｃｅ ｒｅｇｉｓｔｅｒ＞とユーザ・データ・レジスタ＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞との間の論理ＸＯＲ演算を実行し、結果の値を＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞に置く。比較されないビットは、＜ｄｅｓｔｉｎａｔｉｏｎ ｒｅｇｉｓｔｅｒ＞内で「０」の値をもたらすことに留意されたい。
例示的なＴＩＳＡ命令セットは、次の、レジスタに対するその他の動作を含む。
ＮＯＰ
・いくつかのＩＳＡ命令セットでアライメントを実現するためのフィルタとして使用されるノー・オペレーション・オペコード。
例示的なＴＩＳＡ命令セットは、付属プロセッサ・アーキテクチャを使用する実施形態のためにストリーミングのサポートを拡張する次の命令を含む。
ＭｅｍｏｒｙＷｒｉｔｅ
・この命令は、引数＜ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ（シーケンス番号）＞、＜ｂｌｏｃｋ ｏｆｆｓｅｔ（ブロック・オフセット）（３２ビット・オフセット）＞、＜ｎｕｍｂｅｒ ｏｆ ｂｙｔｅｓ ｔｏ ｔｒａｎｓｆｅｒ（転送すべきバイト数）＞、＜ｄｅｓｔｉｎａｔｉｏｎ ａｄｄｒｅｓｓ（宛先アドレス）（指定されたメモリ・ブロック内の）＞、＜ｄａｔａ ｂｙｔｅ（データ・バイト）（１つまたは複数）＞を使用して、ローカル・テスト・メモリに書き込む。
ＭｅｍｏｒｙＲｅａｄ
・この命令は、引数＜ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ（シーケンス番号）＞、＜ｂｌｏｃｋ ｏｆｆｓｅｔ（ブロック・オフセット）（３２ビット・オフセット）＞、＜ｎｕｍｂｅｒ ｏｆ ｂｙｔｅｓ ｔｏ ｔｒａｎｓｆｅｒ（転送すべきバイト数）＞、＜ｓｏｕｒｃｅ ａｄｄｒｅｓｓ（ソース・アドレス）（指定されたメモリ・ブロック内の）＞を使用して、ローカル・テスト・メモリから読み取る。この命令は、シーケンス番号および転送されるバイト数を用いてタグ付けされたデータ・バイトのストリームを返す。
例示的なＴＩＳＡ命令セットは、スキャン状態に関する次の値を含む。
ＳｔａｒｔＳｔａｔｅ、ＳｃａｎＳｔａｔｅ、ＥｎｄＳｔａｔｅ
・スキャン状態コードは、ＴｅｓｔＬｏｇｉｃＲｅｓｅｔ（ＴＬＲ）、ＲｕｎＴｅｓｔ／Ｉｄｌｅ（ＲＴＩ）、ＰａｕｓｅＤＲ（ＰＤＲ）、ＰａｕｓｅＩＲ（ＰＩＲ）、ＳｃａｎＤＲ（ＳＤＲ）、ＳｃａｎＩＲ（ＳＩＲ）を含む。これらは、状態コードあたり４ビットの表現であり、１２ビットが、スキャン動作に関する状態遷移シーケンス全体を記述するのに使用される。
本明細書の教示によって情報を与えられた当業者は、さまざまな他のＴＩＳＡ実施態様を、図示され本明細書で説明されるＴＩＳＡプロセッサ・アーキテクチャと共に使用できることを了解するであろう。たとえば、他のＴＩＳＡ実施態様は、より少数の、より多数の、および／または異なるレジスタを使用することができ、より少数の、より多数の、および／または異なる命令セットを使用することができ、類似物を使用することができ、ならびにそのさまざまな組合せを使用することができる。一実施形態では、異なるプロセッサ・アーキテクチャが使用される場合に、特定の応用例によりよく適するＴＩＳＡ実施態様を提供するためおよび／または任意の他の適切な理由のために、他のＴＩＳＡ実施態様を利用することができる。
上で説明したように、ＪＴＡＧアーキテクチャでのＴＩＳＡの使用は、スキャン動作をスキャン・セグメント・レベルで実行することを可能にし、これは、スキャン・パス全体の内部での独立に制御可能な「スキャン・セグメント」の定義を可能にし、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。
一般に、ＪＴＡＧ動作は、すべてのビットが１つずつ直列にスキャン・インされると同時に、ビットが１つずつ直列にスキャン・アウトされるスキャン動作に基づく。これは、スキャン動作を実行できるために、スキャン・チェーン内のビットごとにどの値が必要とされるか（すなわち、入力ベクトルおよび出力ベクトル）の知識が要求されることを意味する。ＴＧＴは、通常、ＢＳＤＬなどの記述言語を介して入手されるシステム・モデルから必要なベクトルを計算することによって、伝統的な構造テスティングのためにこの機能を提供する。さらに、ＳＶＦおよびＳＴＡＰＬのようなフォーマットは、これを反映する。というのは、これらが、ユーザがこれらのベクトルを操作することを可能にするからである。この形でのテスティングは、構造的な（および他のタイプの）テスティングには十分であるが、この形でのテスティングは、スキャン・チェーン全体にアクセスする実際の必要がない対話セット・アップには非常に非効率的である。この非効率性は、例を検討することによって理解することができる。
たとえば、それぞれが１６ビットを有する１００個の機器からなるスキャン・チェーンを検討されたい。ユーザが、スキャン・チェーン内の７６番目の機器のレジスタに０ｘ１２３４を書き込む必要がある場合には、ＴＧＴは、スキャン・チェーン全体のベクトル（１００＊１６＝１６００ビット）を生成し、スキャン・チェーンに入力するためにこれをＴＡＰインターフェースに送る必要がある。同様に、ユーザが、関連する出力を読み取ることを望む場合には、ＴＧＴは、所望の出力情報を抽出できるようになる前に、１６００ビットのベクトル全体を受け取る必要がある。この例では、スキャン・ビットの大多数が役に立たないという事実は重要ではない。というのは、スキャン効率が、目標の１つではないからである（そうではなく、この例では、目標は、主にスキャン・チェーンの一特定のエンティティに効率的にアクセスできることである）。
このタイプの手法は、少なくとも次の理由から問題である。（ａ）長いベクトルを扱うという計算的な必要がある（たとえば、大量のメモリ転送は、性能に対する大きい影響を有する）、（ｂ）ベクトル（１つまたは複数）全体をメモリに格納する必要がある（長いチェーンについて問題になる可能性がある）、（ｃ）メモリ・ストレージが、データ入力およびデータ出力に制限されるのではなく、期待されるデータ、入力マスク、出力マスク、および類似物をも含む（これによって、入力データおよび出力データだけから既に潜在的に過大な負担を受けているメモリ要件を増やす）、および（ｄ）機器−ベクトル−機器の変換を、毎回行わなければならない（これは、計算能力および時間を必要とする）。
スキャン・セグメント・レベル抽象化レベルは、スキャン効率に対する特別な強調を全く用いずに（もちろん、必要な場合にそれを使用可能にする場合であっても）テストされるシステムのスキャン・チェーンの個々のエンティティまたはエンティティのグループへの効率的なアクセスを提供する強力なツールである。
一実施形態では、スキャン・セグメント・レベル抽象化は、スキャン・チェーンを一連のセグメントに分解することと、セグメントのそれぞれに対する１つまたは複数のスキャン動作を定義することとによって実施される。スキャン・チェーンは、複数の要素からなり、各セグメントは、スキャン・チェーンの要素のうちの少なくとも１つを含む。要素を、テストされるシステムの多数のレベルで定義することができ（たとえば、要素を、デバイス、機器、レジスタ、レジスタのセグメント、および類似物、ならびにそのさまざまな組合せとすることができる）、したがって、スキャン・チェーンがそれに分解されるセグメントを、テストされるシステムの多数のレベルで定義することができる（たとえば、セグメントを、１つまたは複数のデバイス、デバイス（１つまたは複数）の一部、１つまたは複数の機器、機器（１つまたは複数）の一部、１つまたは複数のレジスタ、レジスタ（１つまたは複数）の一部、１つまたは複数のレジスタ・セグメント、および類似物、ならびにそのさまざまな組合せとすることができる）。この形で、セグメントは、スキャン・チェーンの最小の制御単位を表すことができる。
一実施形態では、セグメントへのスキャン・チェーンの分解を、階層的とすることができる。たとえば、スキャン・チェーンをセグメントに分解することができ、そのセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、そのサブセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、以下同様である。この形で、スキャン・チェーンの階層分解を、あるセグメントを他のセグメントから構成できるツリーベースの構造を有するとみなすことができる。１つのそのような実施形態では、ツリーの葉のセグメントを、セグメントと呼ぶことができ（それらがスキャン・チェーンの最小の制御単位を表すという点で）、ツリーの葉の上に位置するセグメントを、スーパーセグメントと呼ぶことができる。一実施形態では、スキャン・チェーンのセグメントのうちの１つまたは複数を、ユーザ／システムに透過的である形でのみ制御可能である仮想サブセグメントから構成することができることを了解されたい。スキャン・チェーンの階層分解を、任意の他の適切な形で定義することができる。
セグメント化の使用は、セグメントのタイプおよび／またはセグメント組合せのタイプに関するエンティティの定義を可能にする。エンティティは、あるタイプのターゲットの包括的記述であり、この記述は、そのタイプのターゲットの各物理インスタンスについて有効であり、そのタイプのターゲットの物理インスタンスごとに再利用することができる。たとえば、あるエンティティが、デバイス、デバイスのグループ、デバイスの一部、機器、機器のグループ、機器の一部、および類似物、ならびにそのさまざまな組合せを定義することができる。したがって、スキャン・チェーンを、スキャン・チェーンのセグメントが特定の要素または要素の組合せを含むように分解することができるので、エンティティを、スキャン・チェーンのそれぞれのセグメントおよび／またはセグメントのそれぞれの組合せについて定義することができる。たとえば、スキャン・チェーンが、１つのセグメントが１つの機器を含むように分解される場合には、エンティティを、そのタイプのセグメント（すなわち、そのタイプの機器を含む各セグメント）について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。同様に、たとえば、スキャン・チェーンが、１つのセグメントが複数の機器を含むように分解される場合には、エンティティを、そのタイプのセグメント（すなわち、そのタイプ組合せの機器を含む各セグメント）について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。これは、下で説明するように、追加の特徴および機能をサポートすることを可能にする。
セグメント化の使用は、エンティティ（すなわち、制御下のあるタイプのセグメントの記述）を、そのエンティティと通信するのに使用される物理プロトコルと相関させることを可能にする。その結果、記述言語（たとえば、ＮＳＤＬ、Ｐ１６８７ ＩＪＴＡＧ ＰＤＬ、および類似物など）を、特にそのエンティティのために記述することができ、接続性記述部分（たとえば、ＮＳＤＬまたはＩＪＴＡＧ ＨＤＬの構造）は、セグメント化命令の順序付けを記述する。
ＴＩＳＡは、ＴＩＳＡ命令がモデルベースの動作ではなくセグメントベースの動作なので、特定のエンティティ・タイプのすべてのオカレンスについて１回定義できる再利用可能なモジュラ性を提供する。したがって、ＴＩＳＡは、モジュラと特定のセグメント内のテストされるエンティティについて自律的との両方であるので、ＴＩＳＡは、既存アーキテクチャに対する大きい利益を提供する。
ＴＩＳＡは、既存のツールが必要とするように接続性全体を静的モデルとして前もって定義する必要なしに、必要な任意の順序でスキャン・プロセス内の任意の点で実行フローに組み入れることのできる再利用可能で移植可能なモジュールへのテスト・データ・レジスタ定義の直接マッピングを可能にする。ＴＩＳＡは、統一された制御フローおよび標準的なコンピュータ・サイエンス技法に基づく単一解空間アーキテクチャとして、スキャン動作との非スキャンであるポート／信号インターフェースの統合を可能にする（ネイティブ言語構造が非スキャン動作へのアクセスを提供するのに使用される解決策に対する大きい利益を提供する）。
ＴＩＳＡは、同一エンティティの複数のインスタンスに関する命令シーケンスの再利用を可能にし、これによって、システム内のコード・ストレージ要件の削減を可能にする。たとえば、管理プログラムによって呼び出される記述言語関数にマッピングされる一般化された関数を記述することができる。この例では、関数のそれぞれは、エンティティを表すネイティブ言語オブジェクトのメソッドであり、システム内で定義されたエンティティごとにこれらのオブジェクトの別々のインスタンスがある場合があるが、これらのインスタンスのそれぞれと通信するのに使用されるコードの単一のコピーがあるものとすることができる。この形で、ネイティブ言語実施態様モデルは、回路の接続性および機能性を指定するのに使用される記述言語を直接に制御する。
上で与えた例を参照すると、スキャン・セグメント・レベル抽象化は、機器１から７５を含むセグメントＳ１、機器７６を含むセグメントＳ２、および機器７７から１００を含むセグメントＳ３という３つのセグメントの定義を可能にする。この形で、機器７６へのアクセスが、大幅に単純化される。たとえば、機器７６へのアクセスを、セグメントＳ３の「ダミー・シフト」を行うこと（たとえば、ＳｃａｎＢｌｏｃｋＺｅｒｏ）と、セグメントＳ２（すなわち、機器７６）について命令（１つまたは複数）を実行することと、セグメントＳ１について別のダミー・シフトを行うことと、その後、更新を伴って終了することとによって得ることができる。そのようなシーケンスでは、セグメントＳ２（すなわち、スキャン・チェーン内の特定の機器）へのアクセスは、その長さを除いてセグメントＳ１またはセグメントＳ３の知識を全く必要とせずに実現される。これが、単に１つの例であり、したがって、１００個の機器の長さのチェーンの別の分解が、他の機器または機器グループへのアクセスを可能にするために可能であることを了解されたい。
図１７に、テストされるシステムの例示的スキャン・チェーンの例示的分解を示す、テストされるシステムの高水準ブロック図を示す。
例示的なＳＵＴ １７００は、４つのデバイス１７１０１〜１７１０４（集合的にデバイス１７１０、図１７ではそれぞれデバイス１、デバイス２、デバイス３、およびデバイス４と表される）を含む。デバイス１７１０は、スキャン・チェーン１７２０を形成するためにＳＵＴ １７００内で直列に配置される。スキャン・チェーン１７２０は、次のようになっている。ＴＡＰのＴＤＩは、デバイス１７１０４の入力ポートに接続され、デバイス１７１０４の出力ポートは、デバイス１７１０３の入力ポートに接続され、デバイス１７１０３の出力ポートは、デバイス１７１０２の入力ポートに接続され、デバイス１７１０２の出力ポートは、デバイス１７１０１の入力ポートに接続され、デバイス１７１０１の出力ポートは、ＴＡＰのＴＤＯに接続される。
例示的なＳＵＴ １７００内では、デバイス１７１０のそれぞれが、（１）テスト命令レジスタ（ＴＩＲ）およびテスト・データ・レジスタ（ＴＤＲ）に入力を供給する入力デマルチプレクサ、ならびに（２）ＴＩＲおよびＴＤＲから出力を収集する出力マルチプレクサを含む。各デバイス１７１０のＴＩＲおよびＴＤＲは、並列レジスタである。デバイス１７１０ ２ は、入力デマルチプレクサが入力を１つのＴＩＲおよび２つのＴＤＲに供給し、その１つのＴＩＲおよび２つのＴＤＲから出力を収集するように、１つの追加のＴＤＲを含み、この１つのＴＩＲおよび２つのＴＤＲは、すべてが並列になっている。ＴＩＲおよびＴＤＲは、それぞれ、直列シフト・レジスタとして図示され、それぞれが９個の関連する要素（たとえば、フリップフロップ）を含む。この形で、（ａ）ＴＩＲは、３６個の直列要素を含む１つのスキャン・チェーン（テスト命令スキャン・チェーンと表される）を形成し、（ｂ）ＴＤＲは、合計４５個の要素および３６個の直列要素（すなわち、デバイス１７１０ ２ の２つのＴＤＲは並列なので）を含むもう１つのスキャン・チェーン（テスト・データ・スキャン・チェーンと表される）を形成する。
例示的なＳＵＴ １７００内では、テスト命令スキャン・チェーンが、デバイス１７１０４のＴＩＲの９個の要素を含む第１セグメントＳＩ４、デバイス１７１０３のＴＩＲの９個の要素を含む第２セグメントＳＩ３、デバイス１７１０２のＴＩＲの９個の要素を含む第３セグメントＳＩ２、およびデバイス１７１０１のＴＩＲの９個の要素を含む第４セグメントＳＩ１という４つのセグメントに分解されている。この形で、テスティング・システムは、ＳＵＴ １７００の他のＴＩＲの最小限の（それらを構成する要素数以外の）知識を用いて、ＳＵＴ １７００のＴＩＲのいずれにも個別にまたは組み合わせてアクセスすることができる。
例示的なＳＵＴ １７００内では、テスト・データ・スキャン・チェーンは、デバイス１７１０４のＴＤＲの９個の要素を含む第１セグメントＳＤ４、デバイス１７１０３のＴＤＲの９個の要素を含む第２セグメントＳＤ３、デバイス１７１０２の第１ＴＤＲの９個の要素（サブセグメントＳＤ２．１と表される）またはデバイス１７１０２の第２ＴＤＲの９個の要素（サブセグメントＳＤ２．２と表される）のいずれかを含む第３セグメントＳＤ２、これらは、セグメントの総数を数えるために別々のセグメントとしてカウントされる、ならびに、デバイス１７１０１のＴＤＲの最初の３つの要素を含む第１サブセグメント（サブセグメントＳＤ１．１と表される）、デバイス１７１０１のＴＤＲの次の４つの要素を含む第２サブセグメント（サブセグメントＳＤ１．２と表される）、およびデバイス１７１０１のＴＤＲの最後の２つの要素を含む第３サブセグメント（サブセグメントＳＤ１．３と表される）という３つの直列サブセグメントにさらに分解される第４セグメントという６つの直列セグメント（合計７つのセグメント）に分解されている。この形で、テスティング・システムは、ＳＵＴ １７００の他のＴＤＲの最小限の（それらを構成する要素数以外の）知識を用いて、ＳＵＴ １７００のＴＤＲのいずれにも（またはデバイス１７１０１のＴＤＲのサブ部分にさえ）個別にまたは組み合わせてアクセスすることができる。
図１７のＳＵＴ １７００が、テストされるシステムのスキャン・チェーン（１つまたは複数）をスキャン・セグメント・レベル抽象化を提供する際の使用のために分解できる形の単に１つの例であることを了解されたい。要素、コンポーネント、および類似物の特定のタイプ、個数、および配置に関して図示され、本明細書で説明されるが、そのスキャン・チェーン（１つまたは複数）が分解されるテストされるシステムが、要素、コンポーネント、および類似物のさまざまな他のタイプ、個数、および／または配置を含むことができることを了解されたい。
本明細書で説明するように、テストされるシステムのスキャン・チェーンの分解は、スキャン動作をセグメントに対して定義することを可能にし、これによってテスティング効率を改善する。分解されたスキャン・チェーンのセグメントに関するスキャン動作を含む命令のセットを生成する、一実施形態による方法を、図１８に関して図示し、本明細書で説明する。
スキャン分解およびスキャン・セグメント動作の生成のより詳細な説明を、次で提供する。
一般的な例として、各基板がセグメント（それぞれ第１基板、第２基板、および第３基板に関連してセグメントＡ、Ｂ、およびＣと表す）を含む３つの基板を含むスキャン・チェーンを検討されたい。この例では、スキャン・セグメントが階層的である場合に、第１基板上のセグメントＡを、複数のサブセグメント（たとえば、サブセグメントＡ１からＡｎ）から構成することができ、第２基板上のセグメントＢを、複数のサブセグメント（たとえば、サブセグメントＢ１からＢｎ）から構成することができ、かつ／または第３基板上のセグメントＣを、複数のサブセグメント（たとえば、サブセグメントＣ１からＣｎ）から構成することができる。
より具体的な例として、アプリケーションおよびＳＵＴに従って、セグメントを、機器の内部の１つまたは複数のレジスタ、機器、レジスタのクラスタ、１つまたは複数の基板、および類似物、ならびにそのさまざまな組合せとすることができる。
したがって、全体的なスキャン動作は、一連のセグメント・スキャン動作に分解される。その結果、最終的なスキャン・チェーン動作を得るために必要なものは、一連の単純な原子的動作だけである。したがって、スキャン・セグメント・レベル抽象化の実施形態は、これに排他的に限定はされないが、原子的テスト動作がプロセッサ動作のように扱われる実施態様で（たとえば、図示され本明細書で説明されるさまざまなＴＩＳＡ実施態様または原子的テスト動作がプロセッサ動作のように扱われる任意の他の類似する実施態様で）特に有効である。
スキャン・セグメント・レベル抽象化のそのような実施形態では、スキャン・セグメント・レベル・スキャン動作の実際の実施態様が、ＪＴＡＧにリンクされた１つまたは複数の技術的制約に対処することを必要とする場合がある。たとえば、とりわけＴＡＰマシンの状態を定義する必要およびＰａｕｓｅ−ＤＲ状態（必ず実施されるわけではない）を使用することの危険性などの制約に対処する必要がある場合がある。
スキャン・チェーン内の機器／セグメントの位置に基づいてスキャン・チェーンを介して受け取られる出力ビットストリーム内の機器／セグメント出力を識別するために、スキャン・インされる最初のセグメントが、スキャン・アウトされる最初のセグメントにもなるように（スキャン・チェーンの終りに最も近いので）、スキャン・チェーンを、先入れ先出し（ＦＩＦＯ）システムとして扱うことができる（その直列の性質を考慮して）。
ＳＵＴにスキャン・セグメント動作のシーケンスを単一スキャン動作のように「経験」させるために、ＴＣＫを、セグメント動作の間に凍結することができる。スキャン・チェーンの内部のすべての要素が同期式なので、この形でのＴＣＫの凍結の効果は、スキャン・チェーンがＴＣＫと一緒に凍結されることである。
ＴＩＳＡベースのテスティング・システムでのスキャン・セグメント・レベルの使用は、少数の例によってよりよく理解することができる。次の例では、テストされるシステム（ＳＵＴ）が、３つのセグメント（その順番でＡ、Ｂ、およびＣと表される）からなり、ユーザが、セグメントＢの内部に値Ｖを書き込む必要があると仮定する。
第１の例として、システムの３つのセグメント（Ａ、Ｂ、およびＣ）が、同一のＪＴＡＧデバイスの内部で実施されると仮定する。この第１の例では、３つのセグメントがメモリ内で定義された後に、ＴＩＳＡ動作は、
ｉ． Ｓｔａｒｔｓｔａｔｅ＝Ｒｕｎ−Ｔｅｓｔ−Ｉｄｌｅ、Ｓｃａｎｓｔａｔｅ＝Ｅｎｄｓｔａｔｅ＝ＳｈｉｆｔＤＲをセットする
ｉｉ． ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＡの長さをセットする
ｉｉｉ． セグメントＡにバイパス・シーケンスをスキャンする
ｉｖ． Ｓｔａｒｔｓｔａｔｅ＝Ｓｃａｎｓｔａｔｅ＝Ｅｎｄｓｔａｔｅ＝ＳｈｉｆｔＤＲをセットする
ｖ． ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＢの長さをセットする
ｖｉ． セグメントＢにＶをスキャンする
ｖｉｉ． Ｓｔａｒｔｓｔａｔｅ＝Ｓｃａｎｓｔａｔｅ＝ＳｈｉｆｔＤＲ、Ｅｎｄｓｔａｔｅ＝Ｒｕｎ−Ｔｅｓｔ−Ｉｄｌｅをセットする
ｖｉｉｉ．ＳｃａｎＬｅｎｇｈｔＦｉｅｌｄにセグメントＣの長さをセットする
ｉｘ． セグメントＣにバイパス・シーケンスをスキャンする
になる。
第１の例に関して、ＴＡＰ有限状態機械（ＦＳＭ）をＳｈｉｆｔＤＲ状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。これは、第１の例から見ることができ、第１の例では、ＳｈｉｆｔＤＲから出た後にのみＵｐｄａｔｅＤＲ状態に達することを考慮すると、ステップ（ｉ）からステップ（ｉｘ）までＴＡＰ ＦＳＭをＳｈｉｆｔＤＲ状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。
さらに第１の例に関して、スキャン・クロックＴＣＫは、スキャン動作中（すなわち、ステップ（ｉｉｉ）、（ｖｉ）、および（ｉｘ））のみアクティブであり、残りの状態では凍結される。その効果は、ＳＵＴが、ＴＣＫと同期する動作に基づくＳＵＴの観点から、ステップ（ｉｉｉ）、（ｖｉ）、および（ｉｘ）を連続ビット・ストリームとみなすことである。
さらに第１の例に関して、「バイパス・シーケンス」は、スキャン・セグメントのプロパティであり、たとえば、所与のシーケンス（すべて０、すべて１、または任意の他の適切なシーケンス）または「ドントケア」とすることができ、そのようなシーケンスを判断することは、ＴＧＴに委ねられる。
第２の例として、システムの３つのセグメント（Ａ、Ｂ、およびＣ）が、異なるＪＴＡＧデバイス（１つまたは複数のカード内）上で実施されると仮定する。この第２の例では、３つのセグメントがメモリ内で定義された後に、ＴＩＳＡ動作は、
ｉ． セグメントＡの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＩＲ（ｇａｔｅＴＣＫインジケータ）
ｉｉ． セグメントＡのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＡのＩＲの長さをセットする
ｉｉｉ． セグメントＡのＢＹＰＡＳＳ命令パターンを用いてＳｃａｎＢｌｏｃｋを走行させる
ｉｖ． セグメントＢの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＩＲ（ｇａｔｅＴＣＫインジケータ）
ｖ． セグメントＢのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＢのＩＲの長さをセットする
ｖｉ． セグメントＢのＥＸＴＥＳＴ命令パターンを用いてＳｃａｎＢｌｏｃｋを走行させる
ｖｉｉ． セグメントＣの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＩＲ、ＥｎｄＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ
ｖｉｉｉ． セグメントＣのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＣのＩＲの長さをセットする
ｉｘ． セグメントＣのＢＹＰＡＳＳ命令パターンを用いてＳｃａｎＢｌｏｃｋを走行させる
ｘ． セグメントＡの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＤＲ（ｇａｔｅＴＣＫ）
ｘｉ． セグメントＡのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＡの選択されたＤＲの長さをセットする（１ビットＢＹＰＡＳＳ ＤＲ）
ｘｉｉ． セグメントＡのＢＹＰＡＳＳデータ・パターンを用いてＳｃａｎＢｌｏｃｋを走行させる
ｘｉｉｉ． セグメントＢの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＳｈｉｆｔＤＲ（ｇａｔｅＴＣＫ）
ｘｉｖ． セグメントＢのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＢの選択されたＤＲの長さをセットする（ピンへのｎビットＢＳＲ ＤＲ）
ｘｖ． セグメントＢのＥＸＴＥＳＴデータ・パターンを用いてＳｃａｎＢｌｏｃｋを走行させる
ｘｖｉ． セグメントＣの状態をセットする、すなわち、ＳｔａｒｔＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＳｃａｎＳｔａｔｅ＝ＳｈｉｆｔＤＲ、ＥｎｄＳｔａｔｅ＝ＲｕｎＴｅｓｔ／Ｉｄｌｅ
ｘｖｉｉ． セグメントＣのＳｃａｎＬｅｎｇｔｈＦｉｅｌｄにセグメントＣの選択されたＤＲの長さをセットする（１ビットＢＹＰＡＳＳ ＤＲ）
ｘｖｉｉｉ．セグメントＣのＢＹＰＡＳＳデータ・パターンを用いてＳｃａｎＢｌｏｃｋを走行させる
になる。
第１の例と第２の例との比較において、第２の例に関連する追加の複雑さが、セグメントを選択／選択解除するために各ＪＴＡＧデバイスの命令レジスタ（ＩＲ）を使用する必要に由来することを理解されたい。その場合に、未使用セグメントは、関連するＪＴＡＧデバイスを１１４９．１標準規格のＢＹＰＡＳＳモードにすることによって（第２の例のステップ（ｉｉｉ）および（ｘｖｉｉ）に示されているように）直接にチェーンから外される。
１つまたは複数のＪＴＡＧデバイス上で定義される任意の個数のセグメントを伴う、上の２つの例のすべての合成が可能であることを了解されたい。さらに、上の２つの例が、単にテストされるシステムをテストするためのスキャン・セグメント・レベルの使用を示すために提供される例であり、したがって、スキャン・セグメント・レベルがテストされるシステムのテスティングに使用される実施形態がこれらの例によって限定されることは意図されていないことを了解されたい。
そのような実施形態では、ＴＩＳＡ命令の実際のシーケンスは、次のうちの１つまたは複数を含む複数の出所を有することができる。（１）ＴＩＳＡ命令を、ＴＧＴによって静的に計算することができ、この場合には、ユーザがセグメントにアクセスすることを望むたびに、チェーン全体をスキャンしなければならない（この解決策は、スキャン時間に関しては最適化されないが、限られた計算リソースを有し、時間制約がほとんどまたは全くない組込みシステムに有用である可能性があることを了解されたい）、（２）ＴＩＳＡ命令を、アクセス要求を受け取り、これらをスキャン動作に合成するソフトウェア・スケジューラによって発行することができ、かつ／または（３）ＴＩＳＡ命令を、ハードウェア・スケジューラによって発行することができる（たとえば、いくつかの高性能プロセッサ内で命令リオーダリングおよびバイパスに関して行われるものなどであるが、これらに限定はされない）。スキャン・セグメント・レベル制御に関連するＴＩＳＡ命令を、任意の他の適切な形で発行することができ、これらの形が、上で説明した方法および／または上で説明した方法のうちの１つもしくは複数の代わりにもしくはそれに加えて使用できる１つもしくは複数の他の適切な方法の組合せを含むことができることを了解されたい。
スキャン・セグメント・レベル抽象化レベルは、ＩＥＥＥ Ｐ１６８７標準規格によって提案されるものおよび他の動的トポロジなどの動的トポロジを処理する強力なツールである。スキャン・チェーンのあるセクションが、アクティブ・スキャン・パスに取り込まれ、外される（たとえば、ＩＥＥＥ Ｐ１６８７標準規格によって提案されるＳＩＢセルまたは任意の他の適切な階層を使用可能にするコンポーネント（１つまたは複数）を使用して）場合には、そのセクションを、１つ（または複数）のセグメントとしてマークすることができる。次に、テスティング・スケジューラは、システム状態から、このセグメント（１つまたは複数）がアクティブであるか否かに関する知識を有し、したがって、このセグメントをＴＩＳＡ命令スケジューリングに含めなければならないかどうかに関する知識を有する。本明細書の教示によって情報を与えられた当業者は、この原理を、ホットスワップ基板（たとえば、状況レジスタからその存在を検出することによって）または任意の他の適切な動的要素など、他の動的要素にも使用できることを了解するであろう。
図１８に、スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用する、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態の高水準ブロック図を示す。
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法１８００のステップの少なくとも一部を、同時にまたは図１８に関して図示され説明されるものとは異なる順序で実行することができる。
ステップ１８０２で、方法１８００が開始される。
ステップ１８０４では、スキャン・チェーンを複数のセグメントに分解する。スキャン・チェーンは、複数の要素に分解され、各セグメントは、スキャン・チェーンの要素のうちの少なくとも１つを含む。上で説明したように、スキャン・チェーンを任意の適切な形で分解することができる。本明細書で説明するように、セグメントへのスキャン・チェーンの分解を、開発フロー内のどこにでも適用することができる（たとえば、テスト開発者によって、テスト生成ツールによって、組込み回路モデルによって、および類似物）。
ステップ１８０６では、命令のセットを生成する。命令のセットは、ＩＳＡに関連するプロセッサ命令と、テストされるシステムの一部分をテストするテスト命令とを含む。テスト命令は、スキャン・チェーンのセグメントごとに、そのセグメントに対して実行すべき少なくとも１つのスキャン動作を含む。テスト命令は、従来のテスト命令、ＴＩＳＡのテスト命令、および類似物など、任意のタイプのテスト命令とすることができ、したがって、任意の適切な形で生成することができる。命令のセットを、任意の適切な形で生成することができる（たとえば、に関して図示し、上で説明したものと同一のまたはこれに類似する形で
ステップ１８０８では、テストされるシステムの一部分をテストするために命令のセットを実行する。命令のセットは、任意の適切な形で実行することができ、この形は、命令のセットの命令のタイプに依存する場合がある。
ステップ１８１０で、方法１８００は終了する。
主にＴＩＳＡの実施形態がスキャン動作をスキャン・セグメント・レベルで実行することを可能にするのに使用される実施形態に関して図示され、本明細書で説明されるが、図示され本明細書で説明されるスキャン・セグメント・レベル実施形態のうちの１つまたは複数を、ＴＩＳＡ様命令アーキテクチャを使用する環境、非ＴＩＳＡ命令アーキテクチャ、および／または非ＴＩＳＡテスティング環境実施態様、ならびに類似物で提供することもできることを了解されたい。
図示され本明細書で説明されるように形成し、利用することのできるＴＩＳＡの例示的実施形態によって使用可能にされる機能強化されたシステム・テスティング機能を説明するために本明細書で「ｔｈｅ ＴＩＳＡ」に言及するが、ＴＩＳＡがそれのために形成されるプロセッサのＩＳＡ、ＴＩＳＡがそれのために形成されるＳＵＴの特性、ＴＩＳＡが実行すると思われるテスト・アルゴリズムの特性、および類似物のうちの１つまたは複数、ならびにそのさまざまな組合せなどのさまざまな要因に依存して、多数の異なるＴＩＳＡを形成できることを了解されたい。したがって、本明細書での「ｔｈｅ ＴＩＳＡ」への言及は、多数の異なるタイプのＴＩＳＡを形成できるという点で、より一般的に「ａ ＴＩＳＡ」と解釈することもできる。
仮想インサーキット・エミュレーション（ＩＣＥ）機能は、本明細書ではＪｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ（ＪＴＡＧ）ハードウェアのテスティングをサポートするために提供される。一実施形態では、仮想インサーキット・エミュレーション（ＩＣＥ）機能は、仮想ＩＣＥドライバを含み、そのさまざまな実施形態を、本明細書で図示し、説明する。仮想ＩＣＥドライバは、任意の標準的なデバッグ・ソフトウェアが柔軟でスケーラブルな形でＪＴＡＧ対応ハードウェアとインターフェースすることを可能にするように構成される。仮想ＩＣＥドライバは、仮想ＩＣＥドライバと共に使用されるテスト命令セットがベクトルを計算することを要求されないように構成される。というのは、ＪＴＡＧ動作が、スキャン・セグメントに対するローカル・ネイティブ命令として表され、これによって、ＩＣＥリソースに直接にアクセスすることを可能にするからである。仮想ＩＣＥドライバは、ＩＣＥを機器ベースのＪＴＡＧ手法（たとえば、ＩＥＥＥ Ｐ１６８７標準規格および他の適切な手法など）と組み合わせられるように構成される。仮想ＩＣＥドライバは、本明細書で提供される仮想ＩＣＥドライバの説明から理解されるさまざまな他の機能および利益を提供する。本明細書では主に仮想ＩＣＥドライバがテスト命令セット・アーキテクチャ（ＴＩＳＡ）と共に利用される実施形態の文脈で図示され、説明されるが、仮想ＩＣＥドライバを任意の適切なテスト命令セットと共に利用できることを了解されたい。
ＴＩＳＡでは、レジスタの並列制御を、高水準ソフトウェア呼出しを使用し、高水準プログラミング言語およびオペレーティング・システムを活用して実行することができる。その結果、ＴＩＳＡを用いると、ＩＣＥインターフェーシングを、ターゲット・ハードウェアのスキャン・トポロジに従うＴＩＳＡスキャン・セグメント動作の発行を管理するＴＩＳＡベースの回路制御モデルへの調整された待ち行列に入れられたコマンド呼出しのセットに縮小することができる。したがって、ＴＩＳＡを用いると、ＩＣＥインターフェースのそれぞれを、ＴＩＳＡオペコードにマッピングされるデバイス・レジスタに対する動作の独立だが階層的なセットとして記述することができる。言い替えると、ＩＣＥインターフェースのそれぞれを、自律的な機器レジスタとみなすことができ、ＴＩＳＡによってサポートされるＪＴＡＧ抽象化レベルの起因して、ＴＩＳＡは、これらのレジスタを独立のスキャン・セグメントして表すことによって、これらのレジスタのそれぞれを自律的に制御することができる。これは、ベクトルを扱うためにＴＧＴによって使用される回路モデルよりはるかに単純である。というのは、ＴＩＳＡプロセッサが、スキャン・セグメント動作だけをスケジューリングする必要がある（既存解決策で要求されるようにテスティング・ベクトルを再ターゲティングするのではなく）からである。
仮想ＩＣＥドライバの上記およびさまざまな他の実施形態ならびに関連する仮想ＩＣＥドライバ機能を、図１９および２０を参照することによってよりよく理解することができる。
図１９に、ターゲット・ハードウェアのテスティングで使用されるように構成された仮想ＩＣＥドライバを含むシステムの一実施形態の高水準ブロック図を示す。
図１９に示されているように、システム１９００は、ターゲット・ハードウェア１９１０、ＴＡＰインターフェース１９１５、仮想ＩＣＥドライバ１９２０、およびＩＣＥホスト１９３０を含む。
ターゲット・ハードウェア１９１０は、複数のＪＴＡＧアクセス可能デバイス１９１１１〜１９１１６（集合的に、ＪＴＡＧアクセス可能デバイス１９１１）を含む。ＪＴＡＧアクセス可能デバイス１９１１は、第１中央処理ユニット（ＣＰＵ１）、第２中央処理ユニット（ＣＰＵ２）、および４つの装着された特定用途向け集積回路（ＡＳＩＣ）（装着されたＡＳＩＣ １〜４）を含む。特定のタイプおよび個数のＪＴＡＧアクセス可能デバイス１９１１を有するものとして図示され、説明されるが、ターゲット・ハードウェア１９１０が、任意の適切なタイプおよび個数のＪＴＡＧアクセス可能デバイス１９１１を含むことができることを了解されたい。
ＣＰＵを、任意のＪＴＡＧアクセス可能ＣＰＵとすることができる。たとえば、ＣＰＵ１およびＣＰＵ２の一方または両方を、１１４９．１ ＩＣＥターゲットとすることができる。たとえば、ＣＰＵ１およびＣＰＵ２の一方または両方を、独立にアクセスされる必要がある複数のプロセッサ・コアを有する１１４９．７ ＩＣＥターゲットとすることができる。ＣＰＵは、任意の他の適切なタイプのＣＰＵを含むことができる。
装備されたＡＳＩＣを、任意のＪＴＡＧアクセス可能ＡＳＩＣとすることができる。たとえば、装備されたＡＳＩＣ １〜４のうちの１つまたは複数を、Ｐ１６８７ ＩＣＥターゲットとすることができる。図１の例では、装備されたＡＳＩＣ １〜４のそれぞれが、Ｐ１６８７ ＩＣＥターゲットである。
ターゲット・ハードウェア１９１０は、それに関連するスキャン・チェーン・トポロジを有し、ＪＴＡＧアクセス可能デバイス１９１１のそれぞれが、そのスキャン・チェーン・トポロジの一部を形成する。
ターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイス１９１１は、ＴＡＰインターフェース１９１５を介して指令され、ＴＡＰインターフェース１９１５は、仮想ＩＣＥドライバ１９２０に接続される。
ＴＡＰインターフェース１９１５は、ターゲット・ハードウェア１９１０と仮想ＩＣＥドライバ１９２０との間のインターフェースを提供し、これによって、仮想ＩＣＥドライバ１９２０が、ターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイスにアクセスすることを可能にする。ＴＡＰインターフェース１９１５を、１１４９．１ ＴＡＰまたは他の適切なＴＡＰなど、任意の適切なＴＡＰを使用して実施することができる。
仮想ＩＣＥドライバ１９２０は、待ち行列付き状態機械（Ｑｕｅｕｅｄ Ｓｔａｔｅ Ｍａｃｈｉｎｅ）１９２１およびＴＩＳＡプロセッサ１９２５を含む。仮想ＩＣＥドライバ１９２０は、ＩＣＥホスト１９３０によるターゲット・ハードウェア１９１０へのアクセスを容易にする。
ＩＣＥホスト１９３０は、ターゲット・ハードウェア１９１０のテスティングを可能にするように構成される。
ＩＣＥホスト１９３０は、ターゲット・ハードウェア１９１０のＣＰＵ１に関連する第１ターゲットＩＣＥコントローラ１９３１１、ターゲット・ハードウェア１９１０のＣＰＵ２に関連する第２ターゲットＩＣＥコントローラ１９３１２、およびターゲット・ハードウェア１９１０の装備されたＡＳＩＣ １〜４に関連する第３ターゲットＩＣＥコントローラ１９３１３を含む複数のターゲットＩＣＥコントローラ１９３１を含む。ＩＣＥホスト１９３０は、より少数またはより多数のそのようなターゲットＩＣＥコントローラを含むことができる。ＩＣＥホスト１９３０は、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１のそれぞれと仮想ＩＣＥドライバ１９２０との間の通信を容易にするように構成されたホスト・メッセージングＡＰＩ １９３５をも含む。
第１ターゲットＩＣＥコントローラ１９３１１は、ＣＰＵ１用のＧＢＵ ＧＵＩ １９３２１およびターゲットＩＣＥマネージャ１９３３１を含む。ＣＰＵ１用のＧＢＵ ＧＵＩ １９３２１は、それを介してテスタがターゲット・ハードウェア１９１０上のＣＰＵ１をテストするために実行されるテストを構成すできるインターフェースを提供する。ターゲットＩＣＥマネージャ１９３３１は、ＣＰＵ１内に含まれるレジスタを記述する回路モデルを含む情報、ＣＰＵ１のさまざまなレジスタがＣＰＵ１内で配置される形、およびＣＰＵ１がターゲット・ハードウェア１９１０のスキャン・チェーン内の唯一のデバイスである場合にＣＰＵ１のレジスタへのアクセスを可能にする情報を有する。ターゲットＩＣＥマネージャ１９３３１は、ＣＰＵ１のスキャン・セグメントへのＣＰＵ１のレジスタのマッピングを定義する情報をも有する。ＧＢＵ ＧＵＩ １９３２１を使用して、ＣＰＵ１のレジスタに対して実行される動作を指定することができる。ターゲットＩＣＥマネージャ１９３３１は、ターゲット・ハードウェア１９１０上のＣＰＵ１にアクセスし、これをテストするための適当なスキャン・セグメント動作を生成する。ターゲットＩＣＥマネージャ１９３３１は、ターゲット・ハードウェア１９１０上のＣＰＵ１にアクセスし、これをテストするための生成されたスキャン・セグメント動作をホスト・メッセージングＡＰＩ １９３５に供給し、ホスト・メッセージングＡＰＩ １９３５は、生成されたスキャン・セグメント動作を仮想ＩＣＥドライバ１９２０に通信する。
第２ターゲットＩＣＥコントローラ１９３１２は、ＣＰＵ２用のＧＢＵ ＧＵＩ １９３２２およびターゲットＩＣＥマネージャ１９３３２を含む。ＣＰＵ２用のＧＢＵ ＧＵＩ １９３２２は、それを介してテスタがターゲット・ハードウェア１９１０上のＣＰＵ２をテストするために実行されるテストを構成できるインターフェースを提供する。ターゲットＩＣＥマネージャ１９３３２は、ＣＰＵ２内に含まれるレジスタを記述する回路モデルを含む情報、ＣＰＵ２のさまざまなレジスタがＣＰＵ２内で配置される形、およびＣＰＵ２がターゲット・ハードウェア１９１０のスキャン・チェーン内の唯一のデバイスである場合にＣＰＵ２のレジスタへのアクセスを可能にする情報を有する。ターゲットＩＣＥマネージャ１９３３１は、ＣＰＵ２のスキャン・セグメントへのＣＰＵ２のレジスタのマッピングを定義する情報をも有する。ＧＢＵ ＧＵＩ １９３２２を使用して、ＣＰＵ２のレジスタに対して実行される動作を指定することができる。ターゲットＩＣＥマネージャ１９３３２は、ターゲット・ハードウェア１９１０上のＣＰＵ２にアクセスするための適当なスキャン・セグメント動作を生成する。ターゲットＩＣＥマネージャ１９３３２は、ターゲット・ハードウェア１９１０上のＣＰＵ２にアクセスするための生成されたスキャン・セグメント動作をホスト・メッセージングＡＰＩ １９３５に供給し、ホスト・メッセージングＡＰＩ １９３５は、生成されたスキャン・セグメント動作を仮想ＩＣＥドライバ１９２０に通信する。
上で説明したように、ＧＤＢ ＧＵＩ １９３２は、それを介してテスタがターゲット・ハードウェア１９１０上のデバイスをテストするために実行されるテストを構成できるインターフェースを提供する。一般に、ＩＣＥの目的について、デバッガ（ＣＰＵ１用のＧＢＵ ＧＵＩ １９３２１およびＣＰＵ２用のＧＢＵ ＧＵＩ １９３２２などのＧＤＢデバッガを含む）は、本質的に、ターゲット・マシンを、３つの基本要素すなわちレジスタのバック、メモリのブロック、およびスタック・フレームを含む抽象化モデルとみなす。ターゲット・マシンのターゲット・マシン記述を使用して、ＩＣＥインフラストラクチャを介して抽象化モデルをターゲット・マシンの実際のハードウェアにマッピングすることができる。ターゲット・ハードウェア１９１０などのＪＴＡＧアクセス可能システムでは、実際のハードウェアは、１つまたは複数のスキャン・チェーン上のＪＴＡＧアクセス可能レジスタとして表される。ＧＤＢでは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を、（１）インデクシングされたレジスタを読み取る／書き込む関数のセット、（２）メモリを読み取る／書き込む関数のセット、（３）プログラム・カウンタ・レジスタを読み取る／書き込む関数のセット、および（４）スタック・ポインタ・レジスタを読み取る／書き込む関数のセットからなるものとすることができる。ＧＤＢでは、これらの関数が、ＧＤＢ ＧＵＩ（たとえば、ＣＰＵ１用のＧＢＵ ＧＵＩ １９３２１およびＣＰＵ２用のＧＢＵ ＧＵＩ １９３２２）を介して開始されたＧＤＢアクセス要求をターゲットＩＣＥに関する（たとえば、ターゲット・ハードウェア１９１０のＣＰＵ１およびＣＰＵ２のレジスタに関する）アクセス・コマンドに変換する。これらのアクセス・コマンドは、スキャン・セグメント動作であり、スキャン・セグメント動作は、ターゲット・ハードウェア１９１０の組込みコンポーネントのレジスタに基づいて定義されるスキャン・セグメント上で指定される。この意味で、各スキャン・セグメントは、テストに使用可能なターゲット・ハードウェア１９１０のレジスタの全体的に順序付けられたセットのサブセットになる。
本明細書では主にターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイス１９１１をテストするためのＧＤＢの使用に関して図示され、説明されるが、任意の適切なデバッガを、ターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイス１９１１をテストするのに利用できることを了解されたい。
第３ターゲットＩＣＥコントローラ１９３１３は、装備されたＡＳＩＣ １〜４のＰ１６８７アプリケーション１９５４３を含む。装備されたＡＳＩＣ １〜４のＰ１６８７アプリケーション１９３４３は、それを介してテスタがターゲット・ハードウェア１９１０上の装備されたＡＳＩＣ １〜４のうちの１つまたは複数をテストするために実行されるテストを構成できるインターフェースを提供する。装備されたＡＳＩＣ １〜４のＰ１６８７アプリケーション１９３４３は、ＧＤＢの機能に似た機能を提供する。装備されたＡＳＩＣ １〜４のＰ１６８７アプリケーション１９３４３は、ターゲット・ハードウェア１９１０上の装備されたＡＳＩＣ １〜４にアクセスするための適当なスキャン・セグメント動作を生成する。装備されたＡＳＩＣ １〜４のＰ１６８７アプリケーション１９５４３は、ターゲット・ハードウェア１９１０上の装備されたＡＳＩＣ １〜４にアクセスするための生成されたスキャン・セグメント動作をホスト・メッセージングＡＰＩ １９３５に供給し、ホスト・メッセージングＡＰＩ １９３５は、生成されたスキャン・セグメント動作を仮想ＩＣＥドライバ１９２０に通信する。
本明細書で示すように、各ターゲットＩＣＥコントローラ１９３１は、スキャン・セグメント動作の順序付けられたセットすなわち、関連するターゲット・ハードウェア１９１０の内部の１つまたは複数のセグメントへの定義された順序付けられた命令のセットを生成するように構成される。
ホスト・メッセージングＡＰＩ １９３５は、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１のそれぞれと仮想ＩＣＥドライバ１９２０との間の通信を容易にする。
ホスト・メッセージングＡＰＩ １９３５は、ターゲットＩＣＥコントローラ１９３１によって生成されたスキャン・セグメント動作の順序付けられたセットの、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１から仮想ＩＣＥドライバ１９２０への通信を容易にする。
ホスト・メッセージングＡＰＩ １９３５は、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１と仮想ＩＣＥドライバ１９２０との間の通信を容易にするために任意の適切な通信機能を使用することができる。たとえば、ホスト・メッセージングＡＰＩ １９３５は、物理接続（たとえば、ＰＣＩ、シリアル、および類似物）、ネットワーク化された接続（たとえば、イーサネットベースの接続、インターネット・プロトコル（ＩＰ）ベースの接続、および類似物）、ソフトウェア・アプリケーション（たとえば、パイプ、ファイル、メッセージ、プロセス間通信、および類似物）、および類似物、ならびにそのさまざまな組合せなどの通信機能を利用することができる。
本明細書では主にターゲットＩＣＥコントローラ１９３１が単一のＩＣＥホスト（すなわち、ＩＣＥホスト１９３０）に存在する実施形態に関して図示され、説明されるが、他の実施形態では、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１が、複数のＩＣＥホスト上に存在することができる。ターゲットＩＣＥコントローラ１９３１を、任意の適切な形で複数のホストにまたがって分散させることができる（たとえば、各ターゲットＩＣＥコントローラ１９３１が、それ自体の専用ホスト上で実施され、ターゲットＩＣＥコントローラ１９３１のうちの少なくともいくつかが、１つまたは複数のホストを共有し、および類似物、ならびにそのさまざまな組合せ）。そのような実施形態では、ホスト・メッセージングＡＰＩ １９３５は、分散されたターゲットＩＣＥコントローラ１９３１の通信を容易にするように構成される（たとえば、物理接続を介して、ＩＰ接続および／または任意の他の適切なネットワーク化された接続などのネットワーク化された接続を介して、および類似物、ならびにそのさまざまな組合せ）。
一実施形態では、仮想ＩＣＥドライバ１９２０は、待ち行列付き状態機械１９２１およびＴＩＳＡプロセッサ１９２５を含む。
待ち行列付き状態機械１９２１は、ＩＣＥホスト１９３０とＴＩＳＡプロセッサ１９２５との間のインターフェースとして動作する。待ち行列付き状態機械１９２１は、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１からスキャン・セグメント動作の順序付けられたセットを受け取る。待ち行列付き状態機械１９２１は、スキャン・セグメント動作のスケジューリングされたセットを作るためにスキャン・セグメント動作の順序付けられたセットを処理し、スキャン・セグメント動作のスケジューリングされたセットは、ターゲット・ハードウェア１９１０の内部の各スキャン・セグメントの位置を考慮に入れることによって実行され得る。待ち行列付き状態機械１９２１は、ターゲット・ハードウェア１９１０のＪＴＡＧスキャン・チェーンに必要なおよび／または効率的なスケジュールを使用してスキャン・セグメント動作をスケジューリングするように構成される。待ち行列付き状態機械１９２１は、スキャン・セグメント動作のスケジューリングされたセットをＴＩＳＡプロセッサ１９２５に供給する。
待ち行列付き状態機械１９２１を、任意の適切な形で実施することができる。
一実施形態では、たとえば、待ち行列付き状態機械１９２１は、イベント・ループ１９２２、コマンド・ハンドラ１９２３、および回路制御モデル１９２４を含む。
イベント・ループ１９２２は、ＩＣＥホスト１９３０のホスト・メッセージングＡＰＩ １９３５からスキャン・セグメント動作の順序付けられたセットを受け取る。スキャン・セグメント動作は、ＩＣＥホスト１９３０のターゲットＩＣＥコントローラ１９３１のうちの１つまたは複数によって発行されるスキャン・セグメント動作を含む。イベント・ループ１９２２は、スキャン・セグメント動作の順序付けられたセットをコマンド・ハンドラ１９２３に供給する。
コマンド・ハンドラ１９２３は、イベント・ループ１９２２からスキャン・セグメント動作の順序付けられたセットを受け取る。コマンド・ハンドラ１９２３は、スキャン・セグメント動作の順序付けられたセットを回路制御モデル１９２４に供給する。
回路制御モデル１９２４は、コマンド・ハンドラ１９２３からスキャン・セグメント動作の順序付けられたセットを受け取り、ＴＩＳＡプロセッサ１９２５に供給されるスキャン・セグメント動作のスケジューリングされたセットを生成する。
回路制御モデル１９２４は、ターゲットＩＣＥコントローラ１９３１のそれぞれの回路モデルのそれぞれの回路モデル情報を含み、ターゲットＩＣＥコントローラ１９３１のそれぞれによって発行されるスキャン・セグメント動作のハンドリングを可能にするための集合体としてこの情報を管理する。
回路制御モデル１９２４は、ＪＴＡＧ対応デバイス１９１１のそれぞれのスキャン・トポロジ、それを介してＪＴＡＧ対応デバイス１９１１が相互接続されるスキャン・トポロジ、および類似物、ならびにそのさまざまな組合せなどの情報を含む、ターゲット・ハードウェア１９１０のスキャン・トポロジをモデル化するためのスキャン・トポロジ情報を含む。各所与の瞬間に、回路制御モデル１９２４の状態は、ターゲット・ハードウェア１９１０の状態の鏡像になる。
回路制御モデル１９２４は、スキャン・セグメント・セットと称する場合もあるスキャン・セグメント・モデルの順序付けられたコレクションを含み、スキャン・セグメント・セットのそれぞれ自体は、他のスキャン・セグメントのサブセットとすることができ、スキャン・セグメント・サブセットのそれぞれは、その順序付けに関してそれ自体を管理することができる。ＴＩＳＡのオブジェクト指向機能は、スキャン・セグメント・セットがそのそれぞれのスキャン・セグメント動作を実行する時の順序付けの、スキャン・セグメント・セットへの委譲を可能にし、さらに、関連するコードが変更されないままである間にスキャン・セグメント・セットが階層全体の中のどこにでも移動することを可能にする。
回路制御モデル１９２４は、スキャン・トポロジ情報から決定されるターゲット・ハードウェア１９１０のスキャン・トポロジに基づいて、スキャン・セグメント動作の順序付けられたセットからスキャン・セグメント動作をスケジューリングする。回路制御モデル１９２４は、受け取られたスキャン・セグメント動作のそれぞれを処理する。回路制御モデル１９２４は、スキャン・セグメント動作を受け取る時に、スキャン・セグメント動作の所期の宛先（たとえば、ターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイス１９１１のうちの１つ）を認識するためにスキャン・セグメント動作を処理する。回路制御モデル１９２４は、スキャン・セグメント動作を、回路制御モデル１９２４のうちでそのスキャン・セグメント動作の所期の宛先に関連する部分、たとえば、スキャン・セグメント動作に関する適当な関数（１つまたは複数）への呼出し（１つまたは複数）を作成するように構成されたスキャン・セグメント・セットに委譲し、呼び出される関数（１つまたは複数）は、スキャン・セグメント動作を実行するための関連するＴＩＳＡプロセッサ命令を有する。
回路制御モデル１９２４は、スキャン・セグメント動作のスケジューリングされたセットをＴＩＳＡプロセッサ１９２５に供給する。
回路制御モデル１９２４が、スキャン・セグメント動作のスケジューリングを実行するのに必要な情報だけを必要とするので、回路制御モデル１９２４を、ベクトル再ターゲティングに使用されるモデルより大幅に単純にすることができることを了解されたい。
ＴＩＳＡプロセッサ１９２５は、ＴＡＰインターフェース１９１５を介してターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイス１９１１を制御するように構成される。ＴＩＳＡプロセッサ１９２５は、ＴＩＳＡプロセッサ１９２５によってサポートされるＴＩＳＡ命令を使用して、ターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイスを制御するように構成される。ＴＩＳＡプロセッサ１９２５は、待ち行列付き状態機械１９２１からスキャン・セグメント動作のスケジューリングされたセットを受け取り、ターゲット・ハードウェア１９１０の関連するＪＴＡＧアクセス可能デバイス１９１１のソフトウェアをデバッグするために、ターゲット・ハードウェア１９１０のＴＡＰインターフェース１９１５およびスキャン・トポロジを介してスキャン・セグメント動作のスケジューリングされたセットを実行する。ＴＩＳＡプロセッサ１９２５の展望から、ターゲット・ハードウェア１９１０は、ターゲット・ハードウェア１９１０の実際の複雑さに関わりなく、単純にスキャン・セグメントのセットである。ＴＩＳＡプロセッサ１９２５は、図１〜１８を参照することによってよりよく理解することができる。
仮想ＩＣＥドライバ１９２０を、例を考慮することによってよりよく理解することができる。たとえば、ターゲット・ハードウェア１９１０のＣＰＵ２に関連するＣＰＵ２用のＧＢＵ ＧＵＩ １９３２２が、ＣＰＵ２内のプログラム・カウンタの値の更新を要求するコマンドを発行すると仮定する。ターゲットＩＣＥマネージャ１９３３２は、そのコマンドをイベント・ループ１９２２に渡す。イベント・ループ１９２２は、メッセージをコマンド・ハンドラ１９２３に渡す。コマンド・ハンドラ１９２３は、コマンドを回路制御モデル１９２４に渡し、回路制御モデル１９２４は、そのコマンドがＣＰＵ２宛であることを認識し、その結果、回路制御モデル１９２４およびターゲット・ハードウェア１９１０の現在の状態でＣＰＵ２にアクセスするのに必要なＴＩＳＡ命令を生成する。必要な場合には、コマンド・ハンドラ１９２３は、回路制御モデル１９２４をＣＰＵ２がアクセス可能な状態にするのに必要な命令をも生成する。その後、回路制御モデル１９２４は、ＣＰＵ２内の特定のレジスタに書き込めるようになるために、ＣＰＵ２に関連する回路モデル１９２４のスキャン・セグメント・セットにコマンドを委譲する。ＣＰＵ２に適当なベクトルを適用するように構成されたスキャン・セグメント・セットは、ＣＰＵ２のプログラム・カウンタ・レジスタに書き込むために呼び出される適当なレジスタ関数への呼出しを作成する。ＣＰＵ２のプログラム・カウンタ・レジスタに書き込むために呼び出されるレジスタ関数は、ＣＰＵ２のプログラム・カウンタ・レジスタに特定のデータを書き込むためにスキャン・セグメント・コマンドの特定のデータを適用する適当なＴＩＳＡプロセッサ命令を有する。したがって、データが経時的に変化することができると同時に、データがレジスタに書き込まれる形を制御する関数は、経時的に同一のままになる。
仮想ＩＣＥドライバ１９２０は、ＴＩＳＡを利用することによって、ターゲット・ハードウェア１９１０のＪＴＡＧアクセス可能デバイス１９１１のそれぞれを独立の自律的なスキャン・セグメントとして扱うことができる。これは、少なくとも部分的に、１１４９．１ ＴＡＰのＴＣＫクロックを命令セット内の任意の所望の点で一時停止することを可能にし、これによって、１１４９．１ ＴＡＰがスキャン動作を一時停止するために安定した状態に切り替わる必要をなくす、ＴＩＳＡの機能に起因する（すなわち、通常、１１４９．１ ＴＡＰインターフェースは、４つの安定した状態のうちの１つでのみＴＣＫをゲーティングする（すなわち、クロックをオフに切り替える））。これは、Ｓｃａｎ Ｓｅｇｍｅｎｔプリミティブの特性に関連して、回路制御モデル１９２４が、単純に、これ自体の内部状態に基づいてコマンド・ハンドラ１９２３から受け取るＴＩＳＡ命令をスケジューリングしなければならないこと、および回路制御モデル１９２４がそのＴＩＳＡ命令を変更する必要がないことを保証する。これは、既存のＩＣＥ手法のベクトル再ターゲティングと比較して、重大な単純化である。
仮想ＩＣＥドライバ１９２０は、ＴＩＳＡを利用することによって、ターゲット・ハードウェア１９１０の組込みコンポーネント上で実行されるスキャン・セグメント動作を同期化することによってターゲット・ハードウェア１９１０の組込みコンポーネントの間の同期化を提供することができる。したがって、仮想ＩＣＥドライバ１９２０は、ＴＩＳＡを利用することによって、単に、スキャン・セグメント動作を順序付け、実行する必要がある（ターゲットＩＣＥコントローラがスキャン・チェーン・ベクトルを再ターゲティングする必要がある既存のＩＣＥ手法とは異なって）、すなわち、仮想ＩＣＥドライバ１９２０は、テスト生成ツール（ＴＧＴ）の使用を必要とするスキャン・チェーン・ベクトルの生成および再ターゲティングを必要とするのではなく、ソフトウェア関数を直接に再ターゲティングする。
仮想ＩＣＥドライバ１９２０は、ターゲット・ハードウェア１９１０の複数のＪＴＡＧアクセス可能デバイス１９１１への並列アクセスおよびその並列テスティングを可能にし、ＪＴＡＧアクセス可能デバイス１９１１は、異なるタイプのデバイス（たとえば、ＣＰＵ、ＡＳＩＣ、および類似物、ならびにそのさまざまな組合せ）を含むことができ、そのようなデバイスがお互いから分離して処理されるという既存ＩＣＥ機構の要件を除去し、したがって、既存ＩＣＥ機構を超えるさまざまな最適化を可能にする（たとえば、ターゲット・ハードウェア１９１０のリソースの共有、ターゲット・ハードウェア１９１０のコンポーネントへのアクセスおよびそのテスティングの並列化、および類似物、ならびにそのさまざまな組合せ）。
仮想ＩＣＥドライバ１９２０は、複数のターゲットＩＣＥコントローラ１９３１によるターゲット・ハードウェア１９１０の複数のＪＴＡＧアクセス可能デバイス１９１１への並列アクセスおよびその並列テスティングを可能にし、任意の所与の時に単一のターゲットＩＣＥコントローラ１９３１だけがターゲット・ハードウェア１９１０の単一のＪＴＡＧアクセス可能デバイス１９１１だけにアクセスでき、これをテストできるという既存ＩＣＥ機構の要件を除去し、したがって、スキャン・チェーン・ベクトルの再ターゲティングの必要をなくす。
仮想ＩＣＥドライバ１９２０は、ターゲット・ハードウェア１９１０のすべてのターゲット・デバイスに関するスキャン・チェーン・ベクトル・セット全体を入手するために（すべてのターゲット・デバイスが同一のスキャン・チェーン上にある場合）、ターゲットＩＣＥコントローラ１９３１によるテスティング・データの前処理（たとえば、ターゲットＩＣＥコントローラ１９３１からのすべてのディレクティブに関する）の必要をなくし、これは、既存のＩＣＥ手法を用いて提供することがむずかしいか不可能でさえある機能である。既存のＩＣＥ手法のこの制限が、理論的理由から生じるのではなく、実用的理由から生じることを了解されたい。実際に、そのような応用例のベクトル再ターゲティングは、計算要件とモデリングの必要との両方に関して、非常に複雑になる可能性がある。その結果、ほとんどの既存のテスト生成ツールは、そのような状況を許容しないか、システムに事前に定義され単純化された構成を強制する。対照的に、ＴＩＳＡは、このプロセスをスケジューリング問題に縮小し、このスケジューリング問題は、多数の既知の最適化された解決策を有する古典的な周知の情報理論問題である。
その結果、仮想ＩＣＥドライバ１９２０は、ターゲットＩＣＥコントローラ１９３１が、ターゲット・ハードウェア１９１０のさまざまなコンポーネントをテストするコマンドを発行するので、そのような処理をリアル・タイムで実行することを可能にする。
仮想ＩＣＥドライバ１９２０は、柔軟でスケーラブルなＩＣＥ機能を提供し、任意の１１４９．１対応ターゲット・ハードウェアおよび／または１１４９．７対応ターゲット・ハードウェアを、基礎になるアーキテクチャを変更する必要なしに制御ソフトウェアに接続することを可能にし、さらに、制御ソフトウェアが必要なだけ大きくなり、ＩＣＥホスト１９３０のリソースのすべてを活用することを可能にする。
仮想ＩＣＥドライバ１９２０は、ターゲット・ハードウェア１９１０上でホスティングされるＧＤＢまたはＰ１６８７アプリケーションの変更を全く必要とせずに、ターゲット・ハードウェア１９１０のＩＣＥベースのテスティングを可能にする。
仮想ＩＣＥドライバ１９２０を、したがって図１９のシステムを、要素／機能／関数の任意の適切なグループ化および／または区分を含むことができる任意の適切な形で実施することができる。
一実施形態では、たとえば、仮想ＩＣＥドライバ１９２０は、ＩＣＥホスト１９３０とターゲット・ハードウェア１９１０との間に配置された独立型の１つまたは複数のデバイスとして実施される。
一実施形態では、たとえば、待ち行列付き状態機械１９２１およびＩＣＥホスト１９３０は、任意の適切なインターフェース／接続（たとえば、ＰＣＩ、シリアル、イーサネット、および類似物）を介してＴＩＳＡプロセッサ１９２５に接続され得るホスト・マシン内で実施される。この実施形態では、ＴＩＳＡプロセッサ１９２５は、標準ＪＴＡＧ接続を介してターゲット・ハードウェア１９１０に接続される。この実施形態では、ホスト・メッセージングＡＰＩ １９３５を、任意の適切なコンピュータ・サイエンス構造（１つまたは複数）（たとえば、メッセージ・キュー、メールボックス、および類似物、ならびにそのさまざまな組合せ）を使用して実施することができる。
一実施形態では、たとえば、仮想ＩＣＥドライバ１９２０が完全にターゲット・ハードウェア１９１０内に組み込まれるように、仮想ＩＣＥドライバ１９２０を実施することができる。
一実施形態では、たとえば、ＩＣＥホスト１９３０を、ＴＩＳＡプロセッサとすることができる。この実施形態では、ＴＩＳＡプロセッサ１９２５は、図１３および１４に関して本明細書で図示し、説明したように、ＴＩＳＡコプロセッサとして実施される。
そのような実施形態のさまざまな組合せを実施でき、かつ／または任意の他の適切な実施態様を使用できることを了解されたい。
本明細書では主に、ＩＣＥホスト１９３０が複数のターゲットＩＣＥコントローラ１９３１を含み、複数のターゲットＩＣＥコントローラ１９３１がターゲット・ハードウェア１９１０に並列にアクセスできる実施形態に関して図示され、説明されるが、他の実施形態では、ＩＣＥホスト１９３０は、複数のターゲットＩＣＥコントローラ１９３１のうちの１つだけが任意の所与の時にアクティブである、複数のターゲットＩＣＥコントローラ１９３１を含むことができ、あるいは、ＩＣＥホスト１９３０は、１つのターゲットＩＣＥコントローラ１９３１だけを含むことができる。そのような実施形態では、仮想ＩＣＥドライバ１９２０は、待ち行列付き状態機械１９２１の使用を必要とせず、したがって、この要素を仮想ＩＣＥドライバ１９２０から省略することができる。そのような実施形態では、仮想ＩＣＥドライバ１９２０は、ＴＩＳＡプロセッサ１９２５を含み、アクティブの／唯一のターゲットＩＣＥコントローラ１９３１によって供給されるスキャン・セグメント動作は、ＴＩＳＡプロセッサ１９２５に直接に（すなわち、待ち行列付き状態機械１９２１を使用せずに）供給され得る。
主に、仮想ＩＣＥドライバ１９２０が単一のＴＡＰインターフェース１９１５を介してターゲット・ハードウェア１９１０とインターフェースする実施形態に関して図示され、説明されるが、他の実施形態では、ターゲット・ハードウェア１９１０は、それに接続された複数のターゲットＩＣＥコントローラ１９３１を有することができる複数の入力ポート（たとえば、１１４９．１ ＴＡＰ）を含むことができる。そのような実施形態では、仮想ＩＣＥドライバ１９２０は、ターゲット・ハードウェア１９１０の複数のＴＡＰインターフェースのそれぞれを介して受け取られたスキャン・ベクトルの、ターゲット・ハードウェア１９１０の適当なＪＴＡＧアクセス可能デバイス１９１１へのルーティングを管理するように構成される。そのような実施形態では、ターゲットＩＣＥコントローラ１９３１は、実際にはＴＩＳＡプロセッサのスキャン・セグメント呼出しとしてデータ・ベクトルをターゲット・ハードウェア１９１０内の適当な点に再マッピングしているＴＩＳＡプロセッサと通信している時に、それ自体のスキャン・チェーン内のそれ自体のデバイスと通信していると考える。したがって、そのような実施形態では、ターゲット・ハードウェア１９１０の変更がある場合に、対応する変更は、ターゲットＩＣＥコントローラ１９３１内では要求されず、ターゲット・ハードウェア１９１０の変更をサポートするために必要な唯一のステップは、ＴＩＳＡプロセッサの回路モデルを再ロードすることになるはずである。
本明細書では主に仮想ＩＣＥドライバ１９２０がターゲット・ハードウェアのソフトウェアをデバッグするのに使用される実施形態に関して図示され、説明されるが、他の実施形態では、仮想ＩＣＥドライバ１９２０を使用して、１１４９．１ ＴＡＰインターフェースをその中に組み込まれた通信デバイス（たとえば、コンピュータ、スマートホン、および類似物）へのリモート更新を実行することができる。
図２０に、ターゲット・ハードウェアをテストするのに仮想ＩＣＥドライバを使用する方法の一実施形態を示す。図２０の方法２０００は、図１９の仮想ＩＣＥドライバに関連して考慮する時によりよく理解することができる。
ステップ２００２で、方法２０００が開始される。
ステップ２００４では、スキャン・セグメント動作を受け取る。スキャン・セグメント動作は、少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥコントローラによって生成される。ターゲットＩＣＥコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する。
ステップ２００６では、スキャン・セグメント動作のスケジューリングされたセットを形成するために、スキャン・セグメント動作をスケジューリングする。スキャン・セグメント動作は、ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいてスケジューリングされる。
ステップ２００８では、スキャン・セグメント動作のスケジューリングされたセットを、ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向けて伝搬させる。
ステップ２０１０で、方法２０００は終了する。
図２１に、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。図２１に示されているように、コンピュータ２１００は、プロセッサ要素２１０２（たとえば、中央処理装置（ＣＰＵ）または他の適切なプロセッサ（１つまたは複数））、メモリ２１０４（たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、および／または任意の他の適切なタイプのメモリ）、図示され本明細書で説明されるシステム・テスティング機能を実行するように適合されたシステム・テスティング・モジュール／プロセス２１０５、およびさまざまな入出力デバイス２１０６（たとえば、ユーザ入力デバイス（キーボード、キーパッド、マウス、および類似物など）、ユーザ出力デバイス（ディスプレイ、スピーカ、および類似物など）、入力ポート、出力ポート、受信器、送信器、およびストレージ・デバイス（たとえば、テープ・ドライブ、フロッピ・ドライブ、ハード・ディスク・ドライブ、コンパクト・ディスク・ドライブ、および類似物））を含む。
図示され本明細書で説明されるシステム・テスティング機能を、ソフトウェアならびに／あるいはソフトウェアおよびハードウェアの組合せで、たとえば、汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または任意の他のハードウェア同等物を使用して、実施できることに留意されたい。一実施形態では、システム・テスティング・プロセス２１０５を、メモリ２１０４にロードし、プロセッサ２１０２によって実行して、上で説明したシステム・テスティング機能の少なくとも一部を実施し、かつ／またはその実施態様をサポートすることができる。したがって、システム・テスティング・プロセス２１０５（関連するデータ構造を含む）を、コンピュータ可読記憶媒体または担体、たとえば、ＲＡＭメモリ、磁気ドライブ、磁気ディスケット、光ドライブ、光ディスケット、および類似物に格納することができる。
本明細書でソフトウェア方法として論じたステップのうちのいくつかを、ハードウェア内で、たとえばさまざまな方法ステップを実行するためにプロセッサと協力する回路網として実施できることが企図されている。本明細書で説明された機能／要素の諸部分を、コンピュータ・プログラム製品として実施することができ、ここで、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および／または技法が呼び出されるか他の形で提供されるように、コンピュータの動作を適合させる。本発明的方法を呼び出す命令を、固定媒体または取外し可能媒体に格納し、放送媒体または他の信号担持媒体内のデータ・ストリームを介して伝送し、かつ／または命令に従って動作するコンピューティング・デバイス内のメモリ内に格納することができる。
さまざまな実施形態の態様は、特許請求の範囲で指定される。さまざまな実施形態の上記および他の態様は、次の番号付きの句で指定される。
１．インサーキット・エミュレーション（ＩＣＥ）を使用してターゲット・ハードウェアの１つまたは複数のコンポーネントをテストする際に使用される方法であって、
少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、複数のターゲットＩＣＥコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、
ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、
ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させるステップと、
を含む方法。
２．受け取られたスキャン・セグメント動作のうちの少なくとも１つについて、受け取られたスキャン・セグメント動作は、少なくとも１つのＩＣＥホストのターゲットＩＣＥコントローラによって生成され、ターゲット・ハードウェア上のプロセッサ・コアのためのものである、句１に記載の方法。
３．少なくとも１つのＩＣＥホストのターゲットＩＣＥコントローラは、デバッガに関連する、句２に記載の方法。
４．受け取られたスキャン・セグメント動作のうちの少なくとも１つについて、受け取られたスキャン・セグメント動作は、少なくとも１つのＩＣＥホストのアプリケーションによって生成され、ターゲット・ハードウェア上の特定用途向け集積回路（ＡＳＩＣ）の少なくとも１つのプロセッサ・コアのためのものである、句１に記載の方法。
５．アプリケーションは、Ｐ１６８７アプリケーションであり、特定用途向け集積回路は、Ｐ１６８７標準規格に準拠する、句４に記載の方法。
６．スキャン・セグメント動作は、物理接続およびネットワーク化された接続のうちの少なくとも１つを介して受け取られる、句１に記載の方法。
７．スキャン・セグメント動作は、複数のターゲットＩＣＥコントローラの通信をサポートするホスト・メッセージングＡＰＩから受け取られる、句１に記載の方法。
８．方法は、待ち行列付き状態機械によって実行される、句１に記載の方法。
９．待ち行列付き状態機械は、
イベント・ループ、コマンド・ハンドラ、および回路制御モデル
を含み、イベント・ループは、ターゲットＩＣＥコントローラによって生成されたスキャン・セグメント動作を受け取り、スキャン・セグメント動作をコマンド・ハンドラに提供するように構成され、
コマンド・ハンドラは、イベント・ループからスキャン・セグメント動作を受け取り、スキャン・セグメント動作を回路モデルに提供するように構成され、
回路制御モデルは、スキャン・セグメント動作のスケジューリングされたセットを作るように構成される
句８に記載の方法。
１０．スキャン・セグメント動作のスケジューリングされたセットは、回路制御モデルを使用して作られる、句１に記載の方法。
１１．回路制御モデルは、
ターゲットＩＣＥコントローラに関連する複数の回路モデルの回路モデル情報
を含む、句１０に記載の方法。
１２．回路制御モデルは、
ターゲット・ハードウェアのスキャン・トポロジをモデル化するスキャン・トポロジ情報であって、回路制御モデルは、スキャン・トポロジ情報を使用してスキャン・セグメント動作のスケジューリングされたセットを作る、スキャン・トポロジ情報
を含む、句１０に記載の方法。
１３．受け取られたスキャン・セグメント動作のそれぞれについて、回路制御モデルは、
スキャン・セグメント動作の所期の宛先であってターゲット・ハードウェアのコンポーネントのうちの１つである所期の宛先を認識するために、スキャン・セグメント動作を処理し、
回路制御モデルのうちでスキャン・セグメント動作の所期の宛先に関連する部分にスキャン・セグメント動作を委譲する
句１０に記載の方法。
１４．回路制御モデルのうちでスキャン制御動作の所期の宛先に関連する部分は、スキャン・セグメント動作に関する少なくとも１つの関数への少なくとも１つの呼出しを作成するように構成されたスキャン・セグメント・セットを含み、少なくとも１つの関数は、スキャン・セグメント動作を実行するように構成されたプロセッサ命令を含む、句１３に記載の方法。
１５．プロセッサは、ターゲット・ハードウェア内に組み込まれる、句１に記載の方法。
１６．方法は、仮想ＩＣＥドライバによって実行され、仮想ＩＣＥドライバは、ターゲット・ハードウェア内に組み込まれる、句１５に記載の方法。
１７．複数のターゲットＩＣＥコントローラは、単一のＩＣＥホストに関連し、プロセッサは、第１プロセッサであり、単一のＩＣＥホストは、第２プロセッサを含み、第２プロセッサは、中央処理装置（ＣＰＵ）として動作し、第１プロセッサは、第２プロセッサのスキャン・セグメント動作のスケジューリングされたセットを処理するためのコプロセッサとして動作する、句１に記載の方法。
１８．第１プロセッサおよび第２プロセッサは、ＴＩＳＡプロセッサである、句１７に記載の方法。
１９．ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストする際に使用される装置であって、
少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥマネージャによって生成されたスキャン・セグメント動作を受け取ることであって、複数のターゲットＩＣＥマネージャは、ターゲット・ハードウェアの複数のコンポーネントに関連する、受け取ることと、
ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングすることと、
ターゲット・ハードウェアの１つまたは複数のデバイスをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させることと
を行うように構成された待ち行列付き状態機械
を含む装置。
２０．プロセッサによって実行された時に、プロセッサに、インサーキット・エミュレーション（ＩＣＥ）を使用してターゲット・ハードウェアの１つまたは複数のコンポーネントをテストする際に使用される方法を実行させる命令を格納したコンピュータ可読記憶媒体であって、方法は、
少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、複数のターゲットＩＣＥコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、
ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、
ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させるステップと、
を含む、コンピュータ可読記憶媒体。
本発明の教示を組み込まれたさまざまな実施形態を図示し、本明細書で詳細に説明したが、当業者は、これらの教示を組み込まれた、多数の他の変更された実施形態をたやすく考案することができる。

Claims (10)

  1. インサーキット・エミュレーション（ＩＣＥ）を使用してターゲット・ハードウェアの１つまたは複数のコンポーネントをテストする際にスケジューラによって使用される方法であって、
    少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、前記複数のターゲットＩＣＥコントローラは、前記ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、
    前記ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、前記受け取ったスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、
    前記ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作の前記スケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作の前記スケジューリングされたセットを伝搬させるステップと
    を含む方法。
  2. 前記受け取ったスキャン・セグメント動作のうちの少なくとも１つについて、前記受け取ったスキャン・セグメント動作は、前記少なくとも１つのＩＣＥホストのターゲットＩＣＥコントローラによって生成され、前記ターゲット・ハードウェア上のプロセッサ・コアのためのものである、請求項１に記載の方法。
  3. 前記受け取ったスキャン・セグメント動作のうちの少なくとも１つについて、前記受け取ったスキャン・セグメント動作は、前記少なくとも１つのＩＣＥホストのアプリケーションによって生成され、前記ターゲット・ハードウェア上の特定用途向け集積回路（ＡＳＩＣ）の少なくとも１つのプロセッサ・コアのためのものである、請求項１に記載の方法。
  4. 前記方法は、待ち行列付き状態機械によって実行され、前記待ち行列付き状態機械は、
    イベント・ループ、コマンド・ハンドラ、および回路制御モデル
    を含み、
    前記イベント・ループは、前記ターゲットＩＣＥコントローラによって生成された前記スキャン・セグメント動作を受け取り、前記スキャン・セグメント動作を前記コマンド・ハンドラに提供するように構成され、
    前記コマンド・ハンドラは、前記イベント・ループから前記スキャン・セグメント動作を受け取り、前記スキャン・セグメント動作を前記回路モデルに提供するように構成され、
    前記回路制御モデルは、スキャン・セグメント動作の前記スケジューリングされたセットを作るように構成される
    請求項１に記載の方法。
  5. スキャン・セグメント動作の前記スケジューリングされたセットは、回路制御モデルを使用して作られる、請求項１に記載の方法。
  6. 前記回路制御モデルは、
    前記ターゲットＩＣＥコントローラに関連する複数の回路モデルの回路モデル情報と、
    前記ターゲット・ハードウェアのスキャン・トポロジをモデル化するスキャン・トポロジ情報であって、前記回路制御モデルは、前記スキャン・トポロジ情報を使用してスキャン・セグメント動作の前記スケジューリングされたセットを作る、スキャン・トポロジ情報と
    を含む、請求項５に記載の方法。
  7. 前記受け取ったスキャン・セグメント動作のそれぞれについて、前記回路制御モデルは、
    前記スキャン・セグメント動作の所期の宛先であって前記ターゲット・ハードウェアの前記コンポーネントのうちの１つである所期の宛先を認識するために、前記スキャン・セグメント動作を処理し、
    前記回路制御モデルのうちで前記スキャン・セグメント動作の前記所期の宛先に関連する部分に前記スキャン・セグメント動作を委譲する
    請求項５に記載の方法。
  8. 前記複数のターゲットＩＣＥコントローラは、単一のＩＣＥホストに関連し、前記プロセッサは、第１プロセッサであり、前記単一のＩＣＥホストは、第２プロセッサを含み、前記第２プロセッサは、中央処理装置（ＣＰＵ）として動作し、前記第１プロセッサは、前記第２プロセッサのスキャン・セグメント動作の前記スケジューリングされたセットを処理するためのコプロセッサとして動作する、請求項１に記載の方法。
  9. ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストする際に使用される装置であって、
    少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥマネージャによって生成されたスキャン・セグメント動作を受け取ることであって、前記複数のターゲットＩＣＥマネージャは、前記ターゲット・ハードウェアの複数のコンポーネントに関連する、受け取ることと、
    前記ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、前記受け取ったスキャン・セグメント動作をスケジューリングすることと、
    前記ターゲット・ハードウェアの１つまたは複数のデバイスをテストするためにスキャン・セグメント動作の前記スケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作の前記スケジューリングされたセットを伝搬させることと
    を行うように構成された待ち行列付き状態機械
    を含む装置。
  10. プロセッサによって実行された時に、前記プロセッサに、インサーキット・エミュレーション（ＩＣＥ）を使用してターゲット・ハードウェアの１つまたは複数のコンポーネントをテストする際にスケジューラによって使用される方法を実行させる命令を格納したコンピュータ可読記憶媒体であって、前記方法は、
    少なくとも１つのＩＣＥホストの複数のターゲットＩＣＥコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、前記複数のターゲットＩＣＥコントローラは、前記ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、
    前記ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、前記受け取ったスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、
    前記ターゲット・ハードウェアの１つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作の前記スケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作の前記スケジューリングされたセットを伝搬させるステップと
    を含む、コンピュータ可読記憶媒体。
JP2013518437A 2010-06-30 2011-06-15 仮想インサーキット・エミュレーションの方法および装置 Expired - Fee Related JP5570662B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/827,556 2010-06-30
US12/827,556 US8621301B2 (en) 2009-03-04 2010-06-30 Method and apparatus for virtual in-circuit emulation
PCT/US2011/040420 WO2012005895A1 (en) 2010-06-30 2011-06-15 Method and apparatus for virtual in-circuit emulation

Publications (2)

Publication Number Publication Date
JP2013537662A JP2013537662A (ja) 2013-10-03
JP5570662B2 true JP5570662B2 (ja) 2014-08-13

Family

ID=44627246

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013518437A Expired - Fee Related JP5570662B2 (ja) 2010-06-30 2011-06-15 仮想インサーキット・エミュレーションの方法および装置

Country Status (7)

Country Link
US (1) US8621301B2 (ja)
EP (1) EP2588875B8 (ja)
JP (1) JP5570662B2 (ja)
KR (1) KR101364397B1 (ja)
CN (1) CN103080761B (ja)
TW (1) TWI432756B (ja)
WO (1) WO2012005895A1 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8775884B2 (en) * 2009-03-04 2014-07-08 Alcatel Lucent Method and apparatus for position-based scheduling for JTAG systems
US8677198B2 (en) * 2009-03-04 2014-03-18 Alcatel Lucent Method and apparatus for system testing using multiple processors
US8719649B2 (en) * 2009-03-04 2014-05-06 Alcatel Lucent Method and apparatus for deferred scheduling for JTAG systems
WO2013095461A1 (en) * 2011-12-21 2013-06-27 Intel Corporation Secure direct memory access
TWI472912B (zh) * 2012-09-11 2015-02-11 Univ Nat Cheng Kung 以電路內部事件作為觸發條件之除錯控制系統及其方法
US9292422B2 (en) 2012-10-12 2016-03-22 Vmware, Inc. Scheduled software item testing
US10387294B2 (en) * 2012-10-12 2019-08-20 Vmware, Inc. Altering a test
US8839201B2 (en) 2012-10-12 2014-09-16 Vmware, Inc. Capturing test data associated with error conditions in software item testing
US8839202B2 (en) 2012-10-12 2014-09-16 Vmware, Inc. Test environment managed within tests
US9684587B2 (en) 2012-10-12 2017-06-20 Vmware, Inc. Test creation with execution
US8949794B2 (en) 2012-10-12 2015-02-03 Vmware, Inc. Binding a software item to a plain english control name
US9292416B2 (en) 2012-10-12 2016-03-22 Vmware, Inc. Software development kit testing
US9069902B2 (en) 2012-10-12 2015-06-30 Vmware, Inc. Software test automation
US10067858B2 (en) 2012-10-12 2018-09-04 Vmware, Inc. Cloud-based software testing
US9183105B2 (en) * 2013-02-04 2015-11-10 Alcatel Lucent Systems and methods for dynamic scan scheduling
US9217774B2 (en) * 2013-11-01 2015-12-22 International Business Machines Corporation Cycle-accurate replay and debugging of running FPGA systems
US10387584B1 (en) * 2014-12-03 2019-08-20 The Mathworks, Inc. Streaming on hardware-software platforms in model based designs
US9772376B1 (en) * 2016-04-29 2017-09-26 Texas Instruments Incorporated Increase data transfer throughput by enabling dynamic JTAG test mode entry and sharing of all JTAG pins
CN108226763B (zh) * 2016-12-15 2021-08-20 三星电子株式会社 用于扫描链重新排序的方法、设备和计算机程序产品
CN110658438A (zh) * 2018-06-29 2020-01-07 是德科技股份有限公司 扫描测试系统及其控制装置和控制方法
CN111443892B (zh) * 2019-01-16 2022-04-29 长鑫存储技术有限公司 仿真结果的比较方法
CN112148391A (zh) 2019-06-26 2020-12-29 北京百度网讯科技有限公司 生成基于芯片的计算功能的方法、装置、设备和存储介质
TWI699101B (zh) * 2019-09-19 2020-07-11 英業達股份有限公司 基於邊界掃描的在線級聯加載韌體系統及其方法
TWI775307B (zh) * 2021-02-04 2022-08-21 新唐科技股份有限公司 半導體裝置及其操作方法
CN114036885A (zh) * 2021-11-08 2022-02-11 上海兆芯集成电路有限公司 内建自测试的方法及互连接口
CN115343967B (zh) * 2022-10-19 2023-01-10 蘑菇物联技术（深圳）有限公司 用于对空压站进行仿真控制的方法、设备和介质

Family Cites Families (35)

* 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
US5828579A (en) * 1996-08-28 1998-10-27 Synopsys, Inc. Scan segment processing within hierarchical scan architecture for design for test applications
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
US20060117274A1 (en) * 1998-08-31 2006-06-01 Tseng Ping-Sheng Behavior processor system and method
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
JP3763385B2 (ja) * 1999-11-09 2006-04-05 シャープ株式会社 半導体装置
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
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
US20030163773A1 (en) * 2002-02-26 2003-08-28 O'brien James J. Multi-core controller
US7073110B1 (en) * 2002-04-26 2006-07-04 Xilinx, Inc. Method and system for programmable boundary-scan instruction register
KR20050007473A (ko) * 2002-05-08 2005-01-18 엔피테스트, 인코포레이티드 다중 명령 메모리들을 포함하는 테스터 시스템
US6832539B2 (en) * 2002-07-15 2004-12-21 Delaware Capital Formation, Inc. Cylinder lock
JP4182202B2 (ja) 2002-08-02 2008-11-19 富士通マイクロエレクトロニクス株式会社 シミュレーション用カバレッジ算出装置及びシミュレーション用カバレッジ算出方法
CN1331007C (zh) * 2002-12-12 2007-08-08 精工爱普生株式会社 电光装置用基板、该基板的制造方法及其应用、以及掩模
US7539915B1 (en) * 2003-01-07 2009-05-26 Marvell Israel (Misl) Ltd. Integrated circuit testing using segmented scan chains
JP2004280588A (ja) 2003-03-17 2004-10-07 Cats Kk システムｌｓｉ設計支援装置およびシステムｌｓｉ設計支援プログラム
US7406699B2 (en) * 2003-04-02 2008-07-29 Microsoft Corporation Enhanced runtime hosting
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
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
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
US20070060114A1 (en) * 2005-09-14 2007-03-15 Jorey Ramer Predictive text completion for a mobile communication facility
JP2007147352A (ja) * 2005-11-25 2007-06-14 Sony Corp 無線インターフェースモジュール及び電子機器
JP4450787B2 (ja) * 2005-11-28 2010-04-14 株式会社ルネサステクノロジ 半導体集積回路装置
US8015462B2 (en) * 2007-05-11 2011-09-06 Renesas Electronics Corporation Test circuit

Also Published As

Publication number Publication date
JP2013537662A (ja) 2013-10-03
KR101364397B1 (ko) 2014-02-26
US8621301B2 (en) 2013-12-31
WO2012005895A1 (en) 2012-01-12
EP2588875B8 (en) 2015-02-25
EP2588875B1 (en) 2015-01-14
TW201215901A (en) 2012-04-16
US20100293423A1 (en) 2010-11-18
CN103080761B (zh) 2015-06-03
KR20130021466A (ko) 2013-03-05
EP2588875A1 (en) 2013-05-08
CN103080761A (zh) 2013-05-01
TWI432756B (zh) 2014-04-01

Similar Documents

Publication Publication Date Title
JP5570662B2 (ja) 仮想インサーキット・エミュレーションの方法および装置
JP5684739B2 (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
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140124

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140204

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140430

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: 20140527

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140624

R150 Certificate of patent or registration of utility model

Ref document number: 5570662

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