理解を容易にするために、可能な場合には、同一の符号が、複数の図面に共通する同一の要素を指定するのに使用された。
さまざまなテスティング機能が、テストされるシステム(SUT)のテスティングを実行する際の使用のために提供される。
一実施形態では、テスト命令セット・アーキテクチャ(TISA)が提供される。TISAは、システム・テスティングを実行する際に使用するために提供される。TISAは、対話テスティング機能、リモート・テスティング機能、および本明細書で説明するさまざまな他の機能を含む改善されたシステム・テスティング機能を提供するために、コンピュータ・サイエンス機能をシステム・テスティング機能と組み合わせる。TISAは、システム・テスティング機能を使用してソフトウェア・ベースの命令セット・アーキテクチャ(ISA)を適合させることによって形成される。ソフトウェア・ベースのISAは、任意の適切なソフトウェア・プログラミング言語(たとえば、C++、Java、および類似物、ならびにそのさまざまな組合せ)を利用することができ、任意の適切なプロセッサを使用して実施され得る。システム・テスティング機能は、IEEE 1149.1(JTAGとしても知られる)TAPまたは任意の他の適切なTAPなどの任意の適切なTAPを利用することができる。一般に、TISAは、ソフトウェア・プロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成される。TISAでは、テスト手順のアルゴリズム部分が、ソフトウェア・フローによって処理され、テスト手順のアルゴリズム部分が原子的テスティング動作に変換されるようになっている。TISAは、ソフトウェア・プロセスの原子的動作をテスト手順の原子的テスティング動作と組み合わせることによって形成され、原子的テスティング動作が、テスト手順のアルゴリズム部分を処理しているソフトウェア・プロセスの原子的動作と同一の形で扱われるようになっている。これは、組込みテスト実行、リモート・テスト実行、および図示され本明細書で説明されるさまざまな他の改善されたシステム・テスティング機能のより細粒度の制御を可能にする。
図1に、テスティング・システムとテストされるシステムとを含むシステム・テスティング環境の高水準ブロック図を示す。
図1に示されているように、システム・テスティング環境100は、テスティング・システム(TS)110およびテストされるシステム(SUT)120を含む。
TS 110は、SUT 120をテストするのに適する任意のシステムとすることができる。TS 110は、SUT 120をテストするために構成される。TS 110は、SUT 120の任意のテスティング、たとえば、SUT 120の1つまたは複数の個々のコンポーネント、SUT 120のコンポーネントの1つまたは複数の組合せ、SUT 120のコンポーネントの間の1つまたは複数の相互接続、SUT 120の1つまたは複数のシステム・レベル機能、および類似物、ならびにそのさまざまな組合せのテスティングを実行することができる。TS 110は、テスト手順の実行、テストされるシステムへの入力データの供給、テストされるシステムからの出力データの受取、システム・テスティング結果を判定するためのテストされるシステムから受け取られた出力データの処理、および同様の機能、ならびにそのさまざまな組合せなど、通常はテストされるシステムのテスティングに関連する機能のいずれをも実行することができる。テストされるシステムをテストするためのTS 110の設計および使用を、下でさらに詳細に説明する。
SUT 120は、TS 110を使用してテストすることのできる任意のシステムとすることができる。SUT 120は、その少なくとも一部をTS 110によって個別におよび/または組み合わせてテストできる任意のコンポーネント(1つまたは複数)を含むことができる。TS 120は、SUT 120によってテストされるコンポーネント(1つまたは複数)へのアクセスを提供する関連する入力アクセス・ピンおよび出力アクセス・ピンの1つまたは複数のセットを有する1つまたは複数のスキャン・チェーンを含むことができる。スキャン・チェーン(1つまたは複数)をSUT 120をテストするためにSUT 120内で利用できる形は、当業者によって了解されるであろう。たとえば、SUT 120は、1つまたは複数の基板を含むことができ、この基板のテスティングは、SUT 120に入力テスティング信号を印加し、SUT 120から出力テスティング信号を収集するために使用できる関連する入力アクセス・ピンおよび出力アクセス・ピンを有する1つまたは複数のスキャン・チェーンを使用して実行することができる。
図1に示されているように、TS 110は、テスト・アクセス・インターフェース(TAI)115を介してSUT 120にアクセスする。テスト・アクセス・インターフェースを、任意の適切なテスト・アクセス・インターフェースを使用して実施することができ、このテスト・アクセス・インターフェースは、TS 110、SUT 120、実行されるテスティングのタイプ、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数に依存するものとすることができる。
たとえば、TAI 115は、参照によってその全体が本明細書に組み込まれているIEEE 1149.1標準規格で標準化されているJoint Test Action Group(JTAG)テスト・アクセス・ポート(Test Access Port、TAP)を含むことができる。IEEE 1149.1標準規格は、Test Data In(TDI)、Test Data Out(TDO)、Test Mode Select(TMS)、Test Clock(TCK)、および、オプションでTest Reset Signal(TRST)という信号のセットをサポートするTAPを定義する。SUT 120のTDIピンおよびTDOピンは、TS 110がSUT 120の少なくとも一部をテストするためにSUT 120にそれによってアクセスできるバウンダリ・スキャン・チェーン内で相互接続される。
TAI 115は、任意の他の適切なテスト・アクセス・インターフェースを含むことができる。
当業者は、TS 110、TAI 115、およびSUT 120を、本明細書に含まれる実施形態の特徴を提供するのに適する任意の形で実施できることを了解するであろう。
本明細書で説明するように、TISAは、システム・テスティングにおける大きい改善を提供するためにシステム・テスティング機能と組み合わせてコンピュータ・サイエンス機能を活用することができる。システム・テスティング機能およびコンピュータ・サイエンス機能の全般的な説明がこれに続き、コンピュータ・サイエンス機能およびシステム・テスティング機能を一緒に利用してTISAを提供する形の説明がそれに続く。
TISAは、コンピュータ・サイエンス機能を活用することによってシステム・テスティング機能を改善する。システム・テスティング機能は、「自動化テスト」フロー(一般に、テスト・アルゴリズム(1つまたは複数)の定義から実際のテスティング動作に達するのに必要である可能性があるステップおよびリソースのすべてを含む)のすべてのステージで一般にサポートされる機能を含むことができる。
テスト自動化を助けるために、テスト・リソースは、しばしば、基板およびデバイスの内部に組み込まれ、通常はテスト・アクセス・ポート(TAP)と呼ばれる標準化されたインターフェースを使用してアクセスされ得る。これは、ピン・カウントを制限し、リソース・アクセスおよび管理を合理化するという効果を有する。複数の言語が、テストされるシステムの内部のリソースを記述するのに使用可能であり、したがって、これをテスト生成ツール(TGT)への入力として使用することができる。TGTは、TAPに指令し、関連するテスティング動作を実行するのにテスト制御ユニット(Test Control Unit、TCU)によって使用できるテスティング・シーケンスを生成するためにアルゴリズムを適用することができる。テスティング動作の特徴および性能は、3つの要素すなわち、アクセス標準規格、データ・フォーマット、およびTCU実施態様に依存する。
TISAは、改善されたシステム・テスティング機能を提供するためにコンピュータ・サイエンス機能を活用することができる。これは、「ソフトウェア開発フロー」(一般に、コンパイル、命令セット・アーキテクチャ(ISA)、対話デバッギング、および類似物、ならびにそのさまざまな組合せなど、選ばれたソフトウェア言語(1つまたは複数)でコーディングされたソフトウェア・アルゴリズムからターゲット・プロセッサ上での最終的なデバッギングおよび実行に達するのに必要である可能性があるステップおよびリソースのいずれかまたはすべてを含む)のすべてのステージで使用可能なコンピュータ・サイエンス機能の使用を含むことができる。
コンピュータ・サイエンスでのコンパイルの使用は、プログラマフレンドリな高水準抽象化で定義されたアルゴリズムを一連の機械実行可能命令に変形する。このプロセスは、入力プログラミング言語およびプロジェクトの複雑さに依存して大幅に変化する可能性があるが、手法のすべてではないにせよほとんどが、すべてのアルゴリズムをその複雑さに関わりなく基本的な命令に分解できるという同一の基本的な仮定を共有する。これは、古典的な言語ならびにたとえばC++、Java、Python、および類似物などのより近代的な高水準言語およびオブジェクト指向言語にあてはまる。
命令セット・アーキテクチャ(ISA)は、すべてのプロセッサの核であり、その理由は、コンパイルが非常に有効であることである。一般に、各プロセッサは、そのプロセッサを操作できる形を定義する命令のセットを提供する。これらの命令は、そのプロセッサのISAの少なくとも一部を形成する。ISAを、レジスタ、アドレッシング・モード、オペコード、メモリ構造、および類似物、ならびにそのさまざまな組合せなど、命令に関連するさまざまな構造を含むと考えることができることを了解されたい。ISAは、プロセッサが、メモリから/への値の読取/書込などの単純な命令を実行し、レジスタに対する論理演算または算術演算を実行し、割込みを処理することなどを可能にする。この基本的な挙動は、経時的に本質的に変更されないままであり、現代のプロセッサは、非常に多くのリソースを効率的に活用できるので例外的な性能を達成し、したがって、ほぼ同一の時間ではるかに多数のそのような基本的な命令を完了することができる。さらに、コプロセッサ(たとえば、浮動小数点コプロセッサ、グラフィカル・コプロセッサ、および類似物)の使用から、さらにより高い性能に達することができ、このコプロセッサは、複雑な動作をハード・コーディングすることによってメイン・プロセッサを助けることができる。
コンピュータ・サイエンスでのデバッギングの使用は、ソフトウェア開発および実行プロセスの監視および検証を可能にする。一般に、ソフトウェア開発は、長くむずかしいプロセスであり、このプロセスは、最終製品が誤りまたは通常呼ばれるように「バグ」がないことを保証するために厳格に監視され、検証される。ソフトウェア・プログラムをテストするのを助けるために、ソフトウェア開発フローは、多数の強力なデバッグ機能を提供する。たとえば、一般的なソフトウェア開発フロー・デバッグ機能は、ステップバイステップ実行、すべてのレジスタおよびメモリ位置の観察可能性/制御可能性、ブレークポイントおよびウォッチポイントの使用、ならびに類似物を含む。これらのデバッグ機能ならびにさまざまな他のデバッグ機能は、よりしばしば、ソフトウェア・コンパイラによって最終コードに埋め込まれるアルゴリズムおよび構造によって使用可能にされるが、プロセッサの内部で使用可能なハードウェア・リソースによって支援することもできる。この情報から、デバッガは、オリジナル・コードを再構成し、すべてのISAレベル動作をプログラミング抽象化レイヤに相関させることができる。
改善されたシステム・テスティング機能を使用可能にするために自動化テスト実行機能およびコンピュータ・サイエンス・ソフトウェア機能を一緒に使用することは、図2および図3を参照することによってよりよく理解することができる。
図2に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図1のテスティング・システムの一実施形態の高水準ブロック図を示す。
図2に示されているように、TS 110は、テスト生成ツール(TGT)210およびソフトウェア・コンパイラ(SC)220を含む。
TGT 210は、TGTコンポーザ212およびTGTアルゴリズム214を含む。
TGTコンポーザ212は、入力としてシステム記述ファイル211を受け入れる。システム記述ファイル211は、テストされるシステムをテストするためのテスティング命令/ベクトルを作るのにTGTによって使用できる任意の適切な記述ファイルを含むことができる。たとえば、システム記述ファイル211は、回路記述ファイル、基板/治具ネットリスト・ファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。システム記述ファイル211を、TGT 210上で使用可能とすることができ、かつ/または1つもしくは複数のリモート・コンポーネントおよび/もしくはシステムから入手することができる。
システム記述ファイル211は、1つまたは複数の回路記述ファイルを含むことができる。回路記述ファイルは、Boundary Scan Description Language(BSDL、基板レベルJTAGに関するIEEE 1149.1標準規格の一部として開発された)、Hierarchical Scan Description Language(HSDL、BSDLの拡張として開発された)、New Scan Description Language(NSDL)、および類似物ならびにそのさまざまな組合せなど、任意の適切な記述言語(1つまたは複数)を使用して指定することができる。
システム記述ファイル211は、1つまたは複数の基板/治具ネットリスト・ファイルを含むことができる。基板/治具ネットリスト・ファイルは、ネットリスト、接続、および類似する情報を記述する、デバイス(1つまたは複数)の物理記述に関係するファイルを含むことができる。基板/治具ネットリスト・ファイルは、PCB、Gerber、および/または基板/治具ネットリスト・ファイルに適する任意の他のフォーマットなど、任意の適切なフォーマットで指定することができる。
システム記述ファイル211は、1つまたは複数の他の記述ファイルを含むことができる。他の記述ファイルは、回路モデルを作るための入力として使用できる任意の他の適切な記述ファイルを含むことができる。たとえば、他の記述ファイルは、Asset社のMacro Language、Goepel社のCASLAN言語、および/または任意の他の適切な記述言語ファイルなど、任意の適切なアプリケーション固有および/またはツール固有の記述言語ファイルを含むことができる。
TGTコンポーザ212は、システム記述ファイル211を処理して回路モデル213を作る。回路モデル213を作るためのTGTコンポーザ212によるシステム記述ファイル211の処理は、任意の適切な形で実行することができる。回路モデル213は、テストされるシステムまたはテストされるシステムのうちでTGT 210がそれのために実行されつつある部分のモデルを指定する。TGTコンポーザ212は、回路モデル213をTGTアルゴリズム214に供給する。
TGTアルゴリズム214は、回路モデル213を受け入れる。TGTアルゴリズム214は、回路モデル213を処理して、TGT原子的テスト動作216を作る。TGT原子的テスト動作216を作るためのTGTアルゴリズム214による回路モデル213の処理は、任意の適切な形で実行することができる。
SC 220は、SCフロントエンド・アルゴリズム222およびSCバックエンド・アルゴリズム224を含む。
SCフロントエンド・アルゴリズム222は、入力としてコンピュータ・サイエンス・ソース・ファイル221を受け入れる。コンピュータ・サイエンス・ソース・ファイル221は、コンパイラによってコンパイルできる任意の適切なコンピュータ・サイエンス・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル221は、C++、Java、Python、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語(1つまたは複数)のコンピュータ・サイエンス・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル221は、1つもしくは複数のCファイル、1つもしくは複数のC++ファイル、および/または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの1つまたは複数を含むことができる。
SCフロントエンド・アルゴリズム222は、コンピュータ・サイエンス・ソース・ファイル221を処理してプログラム・モデル223を作る。プログラム・モデル223は、コンピュータ・サイエンス・ソース・ファイル221の中間表現を指定する。SCフロントエンド・アルゴリズム222は、プログラム・モデル223をSCバックエンド・アルゴリズム224に供給する。
SCバックエンド・アルゴリズム224は、入力としてプログラム・モデル223を受け入れる。SCバックエンド・アルゴリズム224は、プログラム・モデル223を処理して、ISA原子的動作226を含む1つまたは複数のISA2進ファイル225を作る。ISA原子的動作226を含むISA2進ファイル225を形成するためのSCバックエンド・アルゴリズム224によるプログラム・モデル223の処理は、任意の適切な形で実行することができる。ISA原子的動作226は、TISAがそれのために実施されるプロセッサによってサポートされるアセンブリレベル命令である。
図2に示されているように、TGT 210およびSC 220のそれぞれの処理フローに加えて、TGT 210とSC 220との間の追加の相互作用を、TISA原子的動作235の生成を制御するのに利用することができる。一実施形態では、SCバックエンド・アルゴリズム224は、TGTアルゴリズム214への1つまたは複数のベクトル計算要求230を開始することができる。SCバックエンド・アルゴリズム224は、SCバックエンド・アルゴリズムがTAPにアクセスすることを必要とする時に、ベクトル計算要求230を開始することができる。TGTアルゴリズム214は、SCバックエンド・アルゴリズム224からベクトル計算要求230を受け取った時に、受け取られたベクトル計算要求230に基づいてTAPに関する1つまたは複数のTGT原子的テスト動作216を生成する。次に、1つまたは複数のTGT原子的テスト動作216を、SCバックエンド・アルゴリズム224によって制御される形でTAPに適用することができる。というのは、TGT原子的テスト動作216が、ISA原子的動作226と組み合わされて、ISA原子的動作226を使用するTGT原子的テスト動作216に対するアルゴリズム的制御を可能にするからである。この形で、SC 220は、TAPへのアクセスのアルゴリズム的制御を提供する。
図2に示されているように、TGT 210およびSC 220に加えて、TS 110は、さらに、TISAコンポーザ240を含む。TISAコンポーザ240は、TGT原子的テスト動作216およびISA原子的動作226を受け入れる。TISAコンポーザ240は、TGT原子的テスト動作216をTISA命令に変換し、それらのTISA命令をISA2進ファイル(1つまたは複数)225に挿入する(すなわち、TISA命令をISA原子的動作226と組み合わせて、これによって、TISA原子的動作246を含むTISA2進ファイル245を形成する)。TISAコンポーザ240は、TGT 210の一部とするか、SC 220の一部とするか、TGT 210およびSC 220にまたがって分割されるか、TGT 210およびSC 220とは別々に実施されるものなどとすることができる。
図2に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬さ せ、かつ/または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
図3に、テストされるシステムのテスト命令を生成するために協力するテスト生成ツールおよびソフトウェア・コンパイラを含む、図1のテスティング・システムの一実施形態の高水準ブロック図を示す。
図3に示されているように、図3のTS 110は、TISA原子的動作を含むTISA2進ファイルがテスト生成ツールとソフトウェア・コンパイラとの間の相互作用を使用して生成されるという点で、図2のTS 110に似た形で動作する。しかし、図3のTS 110でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用は、図2のTS 110でのテスト生成ツールとソフトウェア・コンパイラとの間の相互作用とは異なる。
図3に示されているように、TS 110は、テスト生成ツール(TGT)310およびソフトウェア・コンパイラ(SC)320を含む。
TGT 310は、TGTコンポーザ312およびTGTアルゴリズム314を含む。
TGTコンポーザ312は、入力としてシステム記述ファイル311を受け入れる。システム記述ファイル311は、テストされるシステムをテストするためのテスティング命令/ベクトルを作るのにTGTによって使用できる任意の適切な記述ファイルを含む。たとえば、システム記述ファイル311は、回路記述ファイル、基板/治具ネットリスト・ファイル、他の記述ファイル、および類似物、ならびにそのさまざまな組合せを含むことができる。図3のシステム記述ファイル311は、図2に関して図示し、説明したシステム記述ファイル211に似たシステム記述ファイル(たとえば、1つまたは複数の回路記述ファイル、1つまたは複数の基板/治具ネットリスト・ファイル、1つまたは複数の他の記述ファイル、および類似物、ならびにそのさまざまな組合せ)を含むことができる。システム記述ファイル311を、TGT 310上で使用可能とすることができ、かつ/または1つもしくは複数のリモート・コンポーネントおよび/もしくはシステムから入手することができる。
TGTコンポーザ312は、入力として1つまたは複数のテスト動作記述ファイル3311−331N(集合的にテスト動作記述ファイル331)を受け入れる。テスト動作記述ファイル331は、SC 320によって生成される。SC 320によるテスト動作記述ファイル331の生成を、下で詳細に説明する。
TGTコンポーザ312は、システム記述ファイル311およびテスト動作記述ファイル331を処理して、回路モデル313を作る。回路モデル313を作るためのTGTコンポーザ312によるシステム記述ファイル311の処理は、任意の適切な形で実行することができる。回路モデル313は、回路モデル313は、テストされるシステムまたはテストされるシステムのうちでTGT 310がそれのために実行されつつある部分のモデルを指定する。テスト動作記述ファイル331に関連するシステム記述ファイル311の処理は、TGT 310が適切なTAP原子的動作を作ることを可能にする形で、TGTコンポーザ312が回路モデル313を作ることを可能にする。TGTコンポーザ312は、回路モデル313をTGTアルゴリズム314に供給する。
TGTアルゴリズム314は、回路モデル313を受け入れる。TGTアルゴリズム314は、回路モデル313を処理して、TGT原子的テスト動作316を作る。TGT原子的テスト動作316を作るためのTGTアルゴリズム314による回路モデル313の処理は、任意の適切な形で実行することができる。
図3に示されているように、TGT 310およびSC 320に加えて、TS 110は、TISAトランスレータ340を含む。TISAトランスレータ340は、TGT原子的テスト動作316を受け取る。TISAトランスレータ340は、TGT原子的テスト動作316を変換して、TISA原子的テスト動作346を形成する。TISAトランスレータ340は、ソフトウェア・コンパイル・プロセスに含めるために、TISA原子的テスト動作346をSC 320に供給する。SC 320によるTISA原子的テスト動作346の使用を、下で詳細に説明する。TISAトランスレータ340は、TGT 310の一部とするか、SC 320の一部とするか、TGT 310およびSC 320にまたがって分割されるか、TGT 310およびSC 320とは別々に実施されるものなどとすることができる。
SC 320は、SCプリコンパイラ330、SCフロントエンド・アルゴリズム322、およびSCバックエンド・アルゴリズム324を含む。
SCプリコンパイラ330は、コンピュータ・サイエンス・ソース・ファイル321を受け入れる。
コンピュータ・サイエンス・ソース・ファイル321は、コンパイラによってコンパイルできる任意の適切なコンピュータ・プログラミング・ソース・ファイルを含む。たとえば、コンピュータ・サイエンス・ソース・ファイル321は、C++、Java、Python、および類似物ならびにそのさまざまな組合せなど、任意の適切なコンピュータ・プログラミング言語(1つまたは複数)のコンピュータ・プログラミング・ソース・ファイルを含むことができる。たとえば、コンピュータ・サイエンス・ソース・ファイル321は、1つもしくは複数のCファイル、1つもしくは複数のC++ファイル、および/または任意の他の適切なコンピュータ・サイエンス・ソース・ファイルのうちの1つまたは複数を含むことができる。
SCプリコンパイラ330は、コンピュータ・サイエンス・ソース・ファイル321を処理する。
SCプリコンパイラ330は、コンピュータ・サイエンス・ソース・ファイル321を処理し、それから前処理済みコンピュータ・サイエンス・ソース・ファイル321Pを作る。コンピュータ・サイエンス・ソース・ファイル321をSCプリコンパイラ330によって前処理して、任意の適切な形で前処理済みコンピュータ・サイエンス・ソース・ファイル321Pを形成することができる。SCプリコンパイラ330は、前処理済みコンピュータ・サイエンス・ソース・ファイル321Pをフロントエンド・アルゴリズム322に供給する。
SCプリコンパイラ330は、コンピュータ・サイエンス・ソース・ファイル321の処理中にテスト動作を検出し、テスト動作記述ファイル331を生成する。テスト動作記述ファイル331は、任意の適切なテスト記述言語を使用して(たとえば、1つまたは複数の標準テスト記述言語を使用して、TGT 310に固有のテスト記述言語を使用して、および類似物、ならびにそのさまざまな組合せ)指定することができる。SCプリコンパイラ330は、テスト動作記述ファイル331をTGT 310に(実例として、回路モデル313を作るためにシステム記述ファイル311に関連してテスト動作記述ファイル331を処理する、TGT 310のTGTコンポーザ312に供給する。
SCフロントエンド・アルゴリズム322は、前処理済みコンピュータ・サイエンス・ソース・ファイル321Pを受け入れる。SCフロントエンド・アルゴリズム322は、TISA原子的テスト動作346をも受け入れ、このTISA原子的テスト動作346は、テスト動作記述ファイル331からTGT 310によって作られたTGT原子的テスト動作316を使用してTISAトランスレータ340によって作られる。SCフロントエンド・アルゴリズム222は、前処理済みコンピュータ・サイエンス・ソース・ファイル321PおよびTISA原子的テスト動作346をコンパイルして、プログラム・モデル323を作る。プログラム・モデル323は、前処理済みコンピュータ・サイエンス・ソース・ファイル321Pの中間表現を指定し、この中間表現は、TISA原子的動作を形成するためにTISA原子的テスト動作346をISA原子的動作内に統合できるように、TISA原子的テスト動作346を含む。SCフロントエンド・アルゴリズム322は、プログラム・モデル323をSCバックエンド・アルゴリズム324に供給する。
SCバックエンド・アルゴリズム324は、プログラム・モデル323を受け入れる。SCバックエンド・アルゴリズム324は、プログラム・モデル223を処理して、TISA原子的動作356を含む1つまたは複数のTISA2進ファイル355を作る。TISA原子的動作356を含むTISA2進ファイル355を形成するためのSCバックエンド・アルゴリズム324によるプログラム・モデル323の処理は、任意の適切な形で実行することができる。
TISA原子的動作356は、ISA原子的動作(すなわち、TISAがそれために実施されるプロセッサによってサポートされるアセンブリレベル命令)およびTISA原子的テスト動作346を含む。
TISA原子的動作356は、TGT原子的テスト動作316(すなわち、TISA原子的テスト動作346の形の)に対するアルゴリズム的制御(ISA原子的動作を使用する)を提供し、これによって、TISA原子的動作356が適用されるテストされるシステムの改善されたシステム・テスティングを可能にする。したがって、TGT原子的テスト動作316(すなわち、TISA原子的テスト動作346の形の)を、SCバックエンド・アルゴリズム324によって制御される形でTAPに適用することができる。というのは、TGT原子的テスト動作316が、ISA原子的動作を使用するTGT原子的テスト動作316に対するアルゴリズム的制御を可能にするために、ISA原子的動作と組み合わされるからである。この形で、SC 220は、TAPへのアクセスのアルゴリズム的制御を提供する。
図3に関して図示し、説明したさまざまな入力および出力を、任意の他の適切な形で格納し、表示し、実行し、伝搬させ、かつ/または処理し、ならびにそのさまざまな組合せを実行することができることを了解されたい。
図2および図3に関して、主に特定の個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物に関して図示し、説明したが、図2および図3の実施形態ならびに本明細書で提供されるさまざまな関連する教示を、任意の適切な個数の入力ファイル、中間ファイル、モデル、出力ファイル、および類似物を使用して実施できることを了解されたい。
図2および図3は、コンピュータ・サイエンス機能を活用してシステム・テスティング機能を改善する形を示す(たとえば、システム・テスティングの細粒度制御の提供、対話システム・テスティングの使用可能化、システム・テスティング中の対話デバッギングの使用可能化、および図示され本明細書で説明されるさまざまな他の利益の提供)。図2および図3のシステム・テスティング方式は、STAPLなどの既存手法に対する改善を提供し、これらの既存手法では、目標は、ベクトル・フォーマットにプログラミング機能を追加することであり、したがって、デバッギング機能、リモート・アクセス機能、および対話性機能が、ゼロから追加される。対照的に、TISAは、システム・テスティング用のテスト・アクセスを制御するために、コンピュータ・プログラミングおよび組込みアプリケーションからの豊富な情報を活用する。
図2および3を参照して、TISAの機能および特徴が、その抽象化レベルによって定義される、すなわち、TISA原子的動作の定義が微細であればあるほど、TISAがより良い性能を提供することを了解されたい。
TISAがJTAGアーキテクチャ内で実施される一実施形態では、3つの抽象化レベルを、スキャン動作のためにサポートすることができる。
第1の抽象化レベルは、ベクトル・レベルである。ベクトル・レベルは、3つの抽象化レベルのうちで最も粗な粒度であり、ここでは、原子的動作は、スキャン・ベクトルの入力および出力である。ベクトル・レベルは、Serial Vector format(SVF)または任意の他の適切なベクトル・フォーマットなどのベクトル・フォーマットで最もよく表され、最高レベルの制御を与える。
第2の抽象化レベルは、TAPレベルである。TAPレベルでは、原子的動作は、TAP状態機械に対する十分な制御を可能にするために機能強化される。これは、スキャン動作に対するより洗練された制御、非標準シーケンス(たとえば、たとえばアドレッサブル・シャドウ・プロトコル(Addressable Shadow Protocol)または他の類似するプロトコルで要求されるシーケンスなど)のサポートを可能にする。
第3の抽象化レベルは、スキャン・セグメント・レベルである。スキャン・セグメント・レベルは、3つの抽象化レベルのうちで最も微細な粒度である。ベクトル・レベルおよびTAPレベルの抽象化レベルは、原子的データ・フォーマットとしてスキャン・ベクトルを使用し、これは、スキャン・チェーン全体が用いられる伝統的な導通テストには十分であるが、スキャン・チェーンを構成する数十個または数百個の機器に対する細粒度制御の必要がある機器ベースのテスティング(instrument−based testing)には面倒である。スキャン・セグメント・レベルは、全体的なスキャン・パスの内部の「スキャン・セグメント」の定義を可能にし、このスキャン・セグメントは、別々に処理することができ、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。この手法は、使用可能な計算リソースが非常に限られている場合がある組込み応用例で有利である。スキャン・セグメント・レベルの使用を、図示し、下でさらに詳細に説明する
図2および図3に示されているように、スキャン動作の抽象化レベルに関わりなく、TGTによって計算される、結果のTAP原子的動作(実例として、TGT原子的テスト動作216およびTGT原子的テスト動作316)は、対応するTISA原子的テスト動作に変換され、2進実行可能ファイルに(たとえば、SCによって生成されたISA原子的動作に)挿入される。
図2を参照すると、TGT原子的テスト動作216およびISA原子的動作226を処理して、TISA2進実行可能ファイル(実例として、TISA2進ファイル245)内のTISA原子的動作246を形成することができる。TISA原子的動作246は、TISA原子的テスト動作およびISA原子的動作を含む。
図3を参照すると、TISA原子的テスト動作(TGT 310によって作られたTGT原子的テスト動作316からTISAトランスレータ340によって生成される)を、SC 310のSCフロントエンド324を変更することを全く必要とせずに、前コンパイル済みアセンブリ命令としてSCフロントエンド324に入力することができる。ほとんどすべてのプログラミング言語が、そのような動作を可能にすることを了解されたい。たとえば、Cでは、この動作が、「asm」コマンドを使用して得られる。一実施形態では、SCバックエンド・アルゴリズム324に対する些細な変更が必要になる場合がある(たとえば、TISAアセンブラ命令の2進変換を処理するために)。そのようなプロセスの例を、図11に関して図示し、本明細書で説明する。
主にJTAGアーキテクチャでのTISA原子的動作の粒度のレベルに関して図示し、説明したが、当業者は、TISA原子的動作の粒度の同一のレベルを他のアーキテクチャで利用でき、TISA原子的動作の粒度の異なるレベルの粒度を、JTAGアーキテクチャおよび/または他のアーキテクチャ、類似物、ならびにそのさまざまな組合せで利用できることを了解するであろう。
上で説明したように、TISAを、任意の適切な命令セット・アーキテクチャ(ISA)を使用して実施することができる。たとえば、TISAを、SPARC V8 ISA、INTEL ISA、および類似物を使用して実施することができる。
TISAの実施態様を説明する際の明瞭さのために、SPARC V8 ISAを使用するTISAの例示的実施態様を、本明細書で図4A〜4Eに関して図示し、説明する。この例示的実施態様では、TISAは、ベクトル・レベルTISAとして実施され、このベクトル・レベルTISAは、SVFフォーマットを構成する命令の直接コーディングを可能にするが、上で説明したように、SPARC V8 ISAを使用するTISAの実施を、TISAがTAPレベルTISAまたはスキャン・セグメント・レベルTISAとして実施される場合にも実行できることを了解されたい。
SPARC V8 ISAは、オープンソース・ソフト・プロセッサ・ファミリLeon 2およびLeon 3など、多数の製品で実施されている。
「The SPARC Architecture Manual Version 8」、SPARC International,Inc刊、1992年(以下では「SPARC Architecture Manual」)の再検討によって、SPARC V8 ISAによって活用されていない多数の符号語があることが明らかになる。これは、少なくともAppendix Fの「opcodes and condition codes(オペコードおよび条件コード)」の再検討から明白である。
図4Aに、SPARC V8 ISAの未活用符号語を示す。図4Aに示された未活用符号語は、TISAの「テスト」命令をコーディングするのに使用することができる。より具体的には、「op」と「op2」との両方に0がセットされている時に、その命令は、「The SPARC Architecture Manual Version 8」では未実施としてマークされ、その命令をTISAに使用できるようになっている。
図4Bに、13個のSVF命令のすべてを表すことができるコーディング・フォーマットを示す。図4Bに示されているように、ビット30〜25は、命令コーディング自体を含み、ビット21〜18は、TAP状態が命令と共に使用される場合にそのTAP状態をコーディングするのに使用することができ、ビット17〜14は、必要な場合にオプション情報を指定するのに各命令によって使用することができる。
図4Cに、IEEE 1149.1 TAPのTAP状態の例示的ビット・コーディングを示す。TAP状態のビット・コーディングは、IEEE 1149.1 TAP状態名を識別する第1列、IEEE 1149.1 TAP状態名に関連するSVF TAP状態名を識別する第2列、および図4Bのビット21〜18のビット・コーディングを識別する第3列を使用して表されている。ビット・コーディングを、さまざまな他の形でTAP状態に割り当てることができることを了解されたい。
SVF命令は、複数のパラメータを可能にし、これらのパラメータは、最終的なコードの内部でコーディングされる必要がある。パラメータを表すために、また、命令およびデータを別々に保つという通常のアーキテクチャ的ベスト・プラクティスのために、レジスタベースのパラメータ渡しが、ベクトル・レベルTISAのこの例示的実施態様のために定義される。したがって、ベクトル・レベルTISAは、6つの専用32ビット・レジスタすなわち、GENERIC1、GENERIC2、TDI、TDO、MASK、およびSMASKを提示する。この6つの専用32ビット・レジスタを、図4Dに示す。6つの専用32ビット・レジスタの使用を、下で詳細に説明するが、一般的ルールとして、これらのレジスタは、パラメータを格納するか、パラメータが格納されるメモリ位置をポイントするかのいずれかに使用される。したがって、コンパイル時に、通常のISA命令を使用して、TISA命令が呼び出される前にこれらのレジスタにロードすることができる。より具体的には、TISAのこのSPARC V8 ISA実施態様では、コプロセッサ・レジスタを、通常のロード/ストア命令のパラメータとして直接に使用することができる。
TISAのこのSPARC V8 ISA実施態様で利用できるSVF命令は、ENDDR、ENDIR、STATE、FREQUENCY、PIO、PIOMAP、HDR、HIR、TDR、TIR、SDR、SIR、およびRUNTESTを含む。これらのSVF命令は、参照によってその全体が本明細書に組み込まれている、「Serial Vector Format Specification」、ASSET InterTech,Inc.、1997年(以下ではSVFマニュアルと称する)を参照することによってよりよく理解することができる。TISAのこのSPARC V8 ISA実施態様でのこれらのSVF命令の使用を、下でより詳細に説明する。
ENDDR、ENDIR、STATE
ENDDR命令およびENDIR命令は、TAPインターフェースがその動作を終了するTAP状態を示す。STATE命令は、強制的にTAPインターフェースを指定された状態にする。TISAのこの例示的実施態様では、ENDDR命令、ENDIR命令、およびSTATE命令のSVFコーディングは、図4Eに示されているようにそれぞれ「000000」、「000001」、および「000010」である。これらのSVF命令のSVFコーディングは、必要に応じて「TAP状態」ファイル(すなわち、図4Cに示されたTAP状態の例示的ビット・コーディング)を使用して実行することができる。少なくともSVFマニュアルの再検討から、STATE命令がオプションでパラメータとして状態の明示的シーケンスをとることができることを了解されたい。TISAのこの例示的実施態様では、パラメータとして状態の明示的シーケンスをとることは、シーケンス内の状態ごとに1命令の、一連の命令によってコーディングされるはずである。
FREQUENCY
FREQUENCY命令は、TAPインターフェースの動作周波数を指定するのに使用される。FREQUENCY命令は、Hzサイクルの32ビット整数として表される。TISAのこの例示的実施態様では、FREQUENCY命令のSVFコーディングは、図4Eに示されているように、「000011」である。FREQUENCY命令の値は、GENERIC1レジスタに格納される。
PIO、PIOMAP
PIO命令は、PIOMAPへの呼出しによって以前にセットされたフォーマットの並列ベクトルを処理するのに使用することができる。RISAのこの例示的実施態様では、PIOMAPは、TAPインターフェースをセット・アップするのに適切なコマンドを生成するプリプロセッサ・ディレクティブとみなされる。したがって、PIO命令は、単に、並列ベクトルを表すことを必要とし、この並列ベクトルは、この並列ベクトルが格納されているアドレスを示す(GENERIC1レジスタ内で)ことによって表すことができる。ベクトルを構成する語数「n」は、この命令のビット13〜0で指定され、したがって、ベクトルは、213=8K語=32Kバイトのサイズ上限を有する。ベクトル・サイズが1語の正確な倍数ではない場合には、必要に応じてパディングおよび再アライメントをメモリ内で提供することができる。TISAのこの例示的実施態様では、PIO命令のSVFコーディングは、「000100」である。
HDR、HIR、TDR、TIR
HDR命令、HIR命令、TDR命令、およびTIR命令の役割は、異なる。ここでは、これらのSVF命令を一緒に検討する。というのは、(1)これらのSVF命令が、機能的に類似し(すなわち、これらのすべてが、異なる性質のものである場合であっても、シフト演算を指令する)、(2)これらのSVF命令が、次の同一のパラメータを受け入れるからである。
(1)length シフトすべきビット数を表す32ビット数
(2)TDI(オプション) 入力シフト・ベクトル
(3)TDO(オプション) 期待される出力シフト・ベクトル
(4)MASK(オプション) 実際の値をTDOと比較する時に使用すべきマスク。「1」は関係を示し、「0」は無関係を示す。
(5)SMASK(オプション) 実際の値をTDIと比較する時に使用すべきマスク。「1」は関係を示し、「0」は無関係を示す。
TISAのこの例示的実施態様では、HDR命令、HIR命令、TDR命令、およびTIR命令のSVFコーディングは、図4Eに示されているように、それぞれ「000110」、「000111」、「001010」、および「001011」である。
TISAのこの例示的実施態様では、次の追加のコーディングを使用することができる。
(1)lengthは、GENERIC1レジスタに格納される。
(2)O1は、TDIが存在する時には「1」であり、そうでない時には「0」である。セットされている場合に、TDIレジスタは、入力ベクトルが格納されているアドレスを含む。
(3)O2は、TDOが存在する時には「1」であり、そうでない時には「0」である。セットされている場合に、TDOレジスタは、期待される出力が格納されているアドレスを含む。
(4)O3は、MASKが存在する時には「1」であり、そうでない時には「0」である。セットされている場合に、MASKレジスタは、出力マスクが格納されているアドレスを含む。
(5)O4は、SMASKが存在する時には「1」であり、そうでない時には「0」である。セットされている場合に、SMASKレジスタは、出力マスクが格納されているアドレスを含む。
SDR、SIR
SDR命令およびSIR命令は、HDR命令、HIR命令、TDR命令、およびTIR命令と同一の構文を有するが、機能的相違を有し、SDRおよびSIRは、TAPに対する実際のスキャン動作をトリガする。対話テスティングでは、システムから読み取られた実際の出力ベクトルが、アルゴリズムの基礎であり、したがって、TISAは、実際の出力ベクトルをメモリ内に格納する可能性を提供する。「TAP状態」フィールド(図4Bに示されたビット21〜18)が0とは異なる時には、GENERIC2レジスタは、実際の出力ベクトルのストレージ位置を示す。したがって、SDRおよびSIRは、最大7個のパラメータをサポートすることができる。TDOが指定され、実際の出力ベクトルが期待される出力ベクトルとは異なる場合には、SPARC Architecture Manual」のSection 4.2に記載されているように、オーバーフロー・フラグがプロセッサ状態レジスタ(PSR)内でセットされる。
RUNTEST
RUNTEST命令は、強制的にTAPインターフェースに指定された長さの時間だけ指定された状態でテストを実行させ、主にRUNBIST動作(たとえば、IEEE 1149.1で定義されている)を制御するのに使用される。RUNTEST命令は、次のパラメータ(すべてがオプションである)のうちの1つまたは複数を受け入れる。
(1)run_state インターフェースがテスト実行中に維持しなければならない状態
(2)run_count テストが費やさなければならないクロック・サイクル数
(3)run_clk run_countがどのクロックを参照するのか(TCK:TAPクロック、SCK:システム・クロック)
(4)min_time 実数として表された、秒単位の最小走行時間
(5)max_time 実数として表された、秒単位の最大走行時間
(6)endstate インターフェースがコマンドの終りに達しなければならない状態
TISAのこの例示的実施態様では、RUNTEST命令のSVFコーディングを、「000101」または「100101」とすることができる。
TISAのこの例示的実施態様では、次の追加のコーディングを使用することができる。
(1)TAP_STATE それについて定義されたrun_stateを含む。
(2)O1 TAP_STATEが定義されている場合には「1」、そうでない場合には「0」
(3)O2 min_countが指定されている場合には「1」、そうでない場合には「0」。セットされている場合には、GENERIC1レジスタが、min_countの32ビット符号なし表現を含む。
(4)O3 max_timeが指定されている場合には「1」、そうでない場合には「0」。セットされている場合には、GENERIC2レジスタが、max_countの32ビット符号なし表現を含む。
(5)O4 endstateがセットされている場合には「1」、そうでない場合には「0」。セットされている場合には、ビット13〜10が終了状態を含む。
(6)ビット9〜0 run_countが指定されている場合には、符号なし整数として表される(最大run_count=210=1024)。このフィールドが「0」ではない場合には、ビット30がrun_clockを示す(「1」=TCK、「0」=SCK)。
主にTISAのこのSPARC V8 ISA実施態様での特定のSVF命令(すなわち、ENDDR、ENDIR、STATE、FREQUENCY、PIO、PIOMAP、HDR、HIR、TDR、TIR、SDR、SIR、およびRUNTEST)の使用に関して図示し、本明細書で説明したが、より少数またはより多数のSVF命令を使用できることを了解されたい。
主にSPARC V8 ISAを使用するTISAの実施態様に関して図示し、本明細書で説明したが、他のISAを利用して、図示され本明細書で説明されるTISA教示によるTISAを実施できることを了解されたい。
対話テスティング手法では、データ・ハンドオフ・ポイントが非常に重要である。上で説明したように、テスト・プログラムは、2つの主要部分すなわち、アルゴリズム部分(ソフトウェア・コンパイラによって表される)およびテスト・アクセス部分(テスト生成ツールによって表される)からなる。テスティング・プログラムを使用するテスト動作中には、テスト・プログラムがテストされるシステムにアクセスしている瞬間と、テスト・プログラムがテスト結果を検査し、必要な次のステップ(1つまたは複数)を判断している瞬間とがある。この2つの動作の間でのハンドオフは、効率的な対話テスティングを得るために重要である。
SVFおよびSTAPLなどの既存のスクリプトベースの手法では、スクリプトが、ベクトル・レベルですべてのTAP動作の世話をする。このレベルでは、インターフェース(または「プレイヤ」)は、TAPプロトコルを用いて通信し、テストされるシステムへ/からベクトルを送る/受け取ることができる。さらに、STAPLは、いくつかの基本的なフロー制御(if−then−else)およびビット・ベクトルに対するアルゴリズム的操作をも可能にする。より洗練された処理(たとえば、受け取られたベクトルの内部のレジスタを識別する、または特定のデバイスにアクセスするためのベクトルを計算する)の必要がある場合には、プレイヤは、アルゴリズム部分に制御をハンド・オーバーする。STAPLでは、これが「export」コマンドを介して行われる。しかし、不利なことに、SVFおよびSTAPLの両方が、これに関する標準化されたフォーマットを有しない(たとえば、STAPLの場合に、ハンドオフ・プロセスは、通常は、所与のベンダにプロプライエタリである)。
Ericsson社のMaster Test Controller(MTC)およびSystem BIST Processorなどの既存の組込み手法では、アルゴリズム部分とテスト・アクセス部分との間の同一の区分が使用される。そのような組込み手法では、アルゴリズム部分およびテスト・アクセス部分は、別々にプログラムされなければならない異なるプロセッサによって実行される。さらに、アルゴリズム部分およびテスト・アクセス部分のメモリ空間は、物理的に異なり、結果のハンドオフ機構が、STAPLのハンドオフ機構に類似するようになっている。その結果は、テスト・アクセス部分用のコプロセッサが、アルゴリズム部分へのハンドオフの前に大量のスキャン部分を格納することを強制されることであり、これは、スキャン・チェーンの増加するサイズを考慮すると、膨大な量のリソースを必要とする可能性がある。
統合テスティングに対する既存手法(たとえば、SVFおよびSTAPLなどのスクリプトベースの手法ならびにMTCおよびSystem BIST Processorなどの組込み手法)とは対照的に、TISAは、テスト・アクセス部分(すなわち、テスト動作)をアルゴリズム部分(すなわち、古典的ISA)の内部に統合し、テスト・アクセス部分およびアルゴリズム部分が同一の物理メモリ空間を共有するようにし、これによって、テスト・アクセス部分とアルゴリズム部分との間のハンドオフ(したがって、データ渡し)を自動的にする。TISAでは、テスト・アクセス部分とアルゴリズム部分との間のハンドオフは、命令レベルで行われ、プロセッサが、関連するスケジューリング戦略に従って必要に応じてスキャンおよびアルゴリズムを自由に混合(すなわち、テスト動作およびアルゴリズム動作を自由に混合)できるようになっている。
SPARC V8 ISAを使用するTISAのこの例示的実施態様では、ベクトルを扱うすべての動作が、絶対アドレッシングを使用する(SVF命令に関して上で説明したように)。その結果、テスティング・ベクトルを、ISAプログラムの内部の通常の変数のように使用することができ、これによって、テスト・アクセス部分とアルゴリズム部分との間のインターフェースを自動的にする。例として、上で説明したSPARC V8 ISAを使用するTISAの例示的実施態様に基づいて、次のステップは、原型的なテスティング・シーケンスを例示するものである。
(1)SDR命令が、テストされるシステムからテスティング出力データを入手するのに使用される。結果の出力データは、特定のメモリ位置に配置される(たとえば、GENERIC2レジスタ内の「actual」パラメータ)
(2)古典的なLOAD命令が、ロードされるべきこの出力データをレジスタに転送することができる
(3)出力データがレジスタにロードされた後に、算術演算および/または論理演算を使用して、出力データを処理することができる(SPARC V8 ISAはロード/ストア・アーキテクチャなので、すべてのデータが、処理される前にレジスタにロードされなければならないことに留意されたい)
(4)古典的なSTORE命令が、アルゴリズムの結果をメモリに転送するのに使用される
(5)SDR命令が、新しいテスティング入力データをTAPに送ることができる(たとえば、TDIレジスタ内の「TDI」パラメータを使用して)
古典的なアルゴリズム動作(2)から(4)が、ISAアルゴリズム実施態様について標準的であり、いかなる形でもTISAによって変更されないことに留意されたい。
したがって、この単純な例から、TISAを、アルゴリズム部分とテスト・アクセス部分との間の自然で効率的なハンドオフと共に、任意の所与のアルゴリズムまたはコンピュータ・プログラムを使用してサポートできることは、明白である。
SPARC V8 ISAを使用するTISAのこの例示的実施態様では、絶対アドレッシングが使用される(TISAを説明する際の明瞭さのために)が、本明細書の教示によって情報を与えられた当業者は、SPARC Architecture Manualに記載されたすべての正当なSPARC V8アドレッシング・モードをサポートするためにTISAのこの例示的実施態様を修正できるはずである。
本明細書で主にSVFが使用されるTISAの例示的実施態様に関して図示し、説明したが、SVFは、1149.1 TAPの、基本的であるとしても完全な処理を提供することがわかっている周知のフォーマットなので、この例示的実施形態で使用された。本明細書の教示によって情報を与えられた当業者は、TISAを任意の他の適切な制御フォーマットを使用して実施でき、それらの制御フォーマットの多くが、TAP状態機械のより細粒度の制御を可能にし、より洗練されたテスティング動作をサポートすることができることを了解するであろう。
本明細書で主に抽象化レベルがベクトル・レベルであるTISAの例示的実施態様に関して図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、図示され本明細書で説明される例示的TISA実施態様を、TISAの抽象化レベルがTAPレベルまたはスキャン・セグメント・レベルになるように変更できることを了解するであろう。
TISAを説明する際の明瞭さのために、例示的なテストされるシステムに対してテスティングを実行するためのTISAの例示的使用を、図5および6に関して図示し、本明細書で説明する。TISAのこの例示的使用では、TISAは、SPARC V8 ISAおよびSVFを使用するベクトル・レベルTISAとして(すなわち、図4A〜4Eに関して図示され、説明された例示的実施態様の継続で)実施される。
図5Aおよび図5Bに、テストされるシステムに対してテスティングを実行するためのTISAの例示的使用を示す。
図5Aに、JTAG TAP 510およびテストされるシステム520を含むシステム・テスト環境500を示す。
JTAG TAP 510は、テストされるシステム520へのテスト・アクセスを提供する。JTAG TAP 510は、テストされるシステム520に入力データを送り、テストされるシステム520から出力データを受け取るために、テストされるシステム520へのテスト・アクセスを提供する。JTAG TAP 510は、命令レジスタ(IR)512を含み、IR 512は、8ビット命令レジスタである。
JTAG TAP 510は、テスティング・システム(たとえば、明瞭にするために省略されている、図3に関して図示し、説明したテスティング・システム110など)によって制御される。
テストされるシステム520は、第1基板521(B1と表される)および第2基板525(B2と表される)を含む。第1基板521は、送信器522(Tと表される)を含む。第2基板525は、受信器526(Rと表される)を含む。送信器522は、接続529上でデータを受信器526に送信する。この例では、接続529は、8ビット接続である。
図5Aに示されているように、各基板は、それ自体のスキャン・チェーンを介してJTAG TAP 510からアクセス可能である。すなわち、第1基板521は、第1スキャン・チェーン523を介してアクセス可能であり、第2基板525は、第2スキャン・チェーン527を介してアクセス可能である。第1スキャン・チェーン523および第2スキャン・チェーン527は、JTAG TAP 510のIR 512によってアクセス可能である(たとえば、IR=0は第1基板B1を選択し、IR=1は第2基板B2を選択する)。送信器522および受信器526は、その基板上で単独であるのではなく、より広いスキャン・チェーン(たとえば、この例において、それぞれ24ビットおよび16ビット)の一部である。
テスト・プログラムでは、入力データが、第1スキャン・チェーン523を介して送信器522に送られ、結果の出力データが、第2スキャン・チェーン527を活用することによって受信器526から収集される。網羅的テストを実行するために、すべての可能な値が接続529を介して送信され、28=256個のベクトルが接続529を介して送信されるようになっている。Cを使用すると、例示的プログラムを、次とすることができる。
1 include <stdio.h>
2 include <jtag.h>
3
4 char sent_value, received value;
5
6 define MAX_COUNT 256;
7
8 void main(void)
9 {
10 for (sent_value=0;sent_value<MAX_COUNT;sent_value++)
11 {
12 apply_JTAG(sent_value,B1.T);
13 read_JTAG (received_value,B2.R);
14 if (sent_value != received value) exit (0);
15 }
16 exit(1);
17 }
このプログラムでは、行2は、JTAG動作を処理しているCモジュールを含み、このCモジュールでは、それぞれ行12および13で使用される関数「apply_JTAG」および「Read_JTAG」が定義される。SC 320のプリコンパイラ330は、これらの関数を認識し、TGT 310用のテスト動作記述ファイル331を生成する。テスト動作記述ファイル331のフォーマットは、第1基板521および第2基板525の実際の実施態様に依存して変化する可能性がある。たとえば、第1基板521と第2基板525との両方がIJTAG準拠である場合には、テスト動作記述ファイル331を、たとえばNew Scan Description Language(NSDL)コードを使用して指定することができる。TGT 310は、テスト動作記述ファイル331を使用して、TGT原子的テスト動作316を生成し、このTGT原子的テスト動作316は、TISAトランスレータ340によってTISA原子的テスト動作346に変換される。TISA原子的テスト動作346は、SC 320のフロントエンド324に供給される。TGT原子的テスト動作316、関連するTISA原子的テスト動作346、および結果のTISA2進コードが、図5Bに示されている。
図5Bに、図5Aのシステム・テスト環境500のテスティングを実行するテスティング・システムによる使用のためのCコマンドからTISAコーディングへのマッピングを示す。
図5Bに示されているように、TISAコーディングへのCコマンドのマッピングは、4つの列すなわち「Cコマンド」列541、「SVF命令」列542、「TISAアセンブラ」列543、および「TISAコーディング」列544を有するテーブル540を使用して表される。テーブル540は、左から右へ、CコマンドをSVF命令に変換できる形を示し、このSVF命令をTISAアセンブラに変換することができ、このTISAアセンブラをTISA2進コーディングにコーディングすることができる。
Apply_JTAG(value,B1.T)コマンドは、2つのSVF命令すなわちSIR 8 TDI(00)およびSDR 24 TDI(value)に変換される。
SIR 8 TDI(00) SVF命令は、次の3つの動作としてTISAアセンブラに変換される。
SET 8, %cGENERIC1
SET 00, %cTDI
SIR TDI、12010000としてTISAコーディングに変換される。
SDR 24 TDI(value) SVF命令は、次の3つの動作としてTISAアセンブラに変換される。
SET 24, %cGENERIC1
SET value, %cTDI
SDR TDI、10010000としてTISAコーディングに変換される。
Read_JTAG(value,B2.R)コマンドは、2つのSVF命令すなわちSIR 8 TDI(01)およびSDR 16 ACTUAL(value)に変換される。
SIR 8 TDI(01) SVF命令は、次の3つの動作としてTISAアセンブラに変換される。
SET 8, %cGENERIC1
SET 01, %cTDI
SIR TDI、12010000としてTISAコーディングに変換される。
SDR 16 ACTUAL(value) SVF命令は、次の3つの動作としてTISAアセンブラに変換される。
SET 16, %cGENERIC1
SET ”value”, %cGENERIC2
SDR ACTUAL、10008000としてTISAコーディングに変換される。
SET動作のTISAコーディングは、指定されない。というのは、SPARC V8 Manualが、これらを、プロセッサの実施態様に従って異なるコーディングを有することができる「擬似命令」として識別するからである。
決定されたTISAコーディングを使用して、プリコンパイラ330は、今や、高水準JTAGアクセスをそれに関連するTISAアセンブラ命令に置換することができる。その結果が、Cを使用して指定された次のコードであり、このコードでは、JTAG TAPへの呼出しが、関連するTISAアセンブラ・コーディングによって置換されている。
1 include <stdio.h>
2 include <jtag.h>
3
4 char sent_value, received value;
5
6 define MAX_COUNT 256;
7
8 void main(void)
9 {
10 for (sent_value=0;sent_value<MAX_COUNT;sent_value++)
11 {
12 asm volatile (”SET 8, %cGENERIC1;
13 SET 00, %cTDI;
14 SIR TDI;
15 SET 24, %cGENERIC1;
16 SET &sent_value, %cTDI;
17 SDR TDI;”);
18 asm volatile (”SET 8, %cGENERIC1;
19 SET 01, %cTDI;
20 SIR TDI;
21 SET 16, %cGENERIC1;
22 SET &received_value, %cGENERIC2;
23 SDR ACTUAL”);
24 if (sent_value != received value) exit (0);
25 }
26 exit(1);
27 }
このコードを、フロントエンド・アルゴリズム322に入力することができ、フロントエンド・アルゴリズム322は、プログラム・モデル323を生成する。プログラム・モデル323を、バックエンド・アルゴリズム324に入力することができ、バックエンド・アルゴリズム324は、TISA原子的動作356を含む実行可能TISA2進ファイル(1つまたは複数)355を生成する。
テーブル540の「TISAコーディング」列544は、TISAアセンブラ命令の2進コーディングを示す(たとえば、図4A〜4Eに関して図示し、説明したようにSPARC V8 ISAを使用するTISAの例示的実施態様に関して定義されるさまざまなルールを使用して)。
本明細書で説明するように、TISAは、テストされるシステムのテスティングを実行する際のテスト粒度に関して完全な自由を提供する(すなわち、TAPレベルからスキャン・セグメント・レベルまで)。図2および図3に示され、図4A〜4Eおよび図5A〜5Bの例示的TISA実施態様を使用してさらに説明されるように、テスト・パターンを、テスト生成ツールに対するソフトウェア・コンパイラによる明示的照会を使用して計算することができ、ソフトウェア・アルゴリズムに関する唯一の制限は、照会自体の解決である。
例として、粗なレベルで、SCからTGTへの照会は、テストされるシステムのスキャン・チェーン全体を含むことができる(たとえば、古典的なBSDLベースのバウンダリ・スキャン・テスティングの場合など)。
例として、微細なレベルで、SCからTGTへの照会は、レジスタまたはビットさえも含むことができる。たとえば、専用スキャン・セグメント・プリミティブは、機器アクセスおよびTAP再構成を大幅に加速し、コード再利用を増やし、さまざまな他の利益を提供することができる。
例として、粗なレベルと微細なレベルとの間の中間レベルでは、SCからTGTへの照会を、関数的に行うことができる(たとえば、IJTAGおよび他の適切な標準規格などの標準規格を使用し、NSDLおよび他の適切なオブジェクト指向記述言語などの記述言語を使用して)。
この形で、TISAは、デバイス/レジスタ・アクセスがモデル空間で(すなわち、TGT内で)解決されることを強制するのではなく、開発者がデバイス/レジスタ・アクセスをプログラム空間で(すなわち、SC内で)処理することを可能にし、これによって、開発者が分析粒度を彼らの必要および使用可能なリソースに適合させることを可能にする。
さらに、TISAプロセッサが、たとえば自動テスト装置(ATE)の場合など、十分なリソースを有する環境では、回路モデルの少なくとも一部を、プログラム・モデル内で実施することができ、これによって、TISAマシンがベクトル・パターンを直接に計算することが可能になる。
さらに、TISAは、対話デバッギング(ローカルにおよび/またはリモートに)を含む対話テスティング、並列性、ポータビリティ、および類似物、ならびにそのさまざまな組合せなど、TISAなしでは以前に可能でなかったさまざまな他のシステム・テスト機能をサポートすることを可能にする。これらの追加機能に、これからさらに詳細に対処する。
図6に、対話テスティング機能をサポートするTISAベースのテスティング環境の実施形態を示す。
図6に示されているように、TISAベースのテスティング環境600は、ホスト・コンピュータ(HC)601、テスティング・システム(TS)610、およびテストされるシステム(SUT)620を含む。
HC 601は、SUT 620のテスティングを制御するためにTS 610を制御するように構成される。HC 601は、メモリ604に結合されたプロセッサ602を含む。プロセッサ602およびメモリ604は、任意の適切なプロセッサおよびメモリとすることができる。
メモリ604は、1つまたは複数のデバッガ制御プログラム605を格納する。デバッガ制御プログラム(1つまたは複数)は、HC 601がTS 610上で走行するコンピュータ・プログラム(1つまたは複数)の実行をトレースし、望まれるか必要な場合にこれを変更することを可能にする。たとえば、デバッガ制御プログラム(1つまたは複数)605は、GNU Debugger(GDB)、dbxデバッガ、Perlデバッガ、Bashデバッガ、Pythonデバッガ、および同様の適切なデバッガ・プログラム、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。
メモリ604は、1つまたは複数のデバッガ表示プログラム606をも格納することができる。デバッガ表示プログラム(1つまたは複数)は、HC 601がデバッガ制御プログラム(1つまたは複数)605に関連する情報を表示することを可能にする。デバッガ制御プログラム(1つまたは複数)605に関連する情報を、デバッガ表示プログラム(1つまたは複数)606によって任意の適切な形で(たとえば、1つまたは複数のディスプレイ・デバイスを使用して)表示することができる。たとえば、デバッガ表示プログラム(1つまたは複数)606は、Insight(GDBへのグラフィカル・ユーザ・インターフェースである)、Data Display Debugger(DDD、GDBおよび他のデバッガなどのさまざまなコマンドライン・デバッガのグラフィカル・ユーザ・インターフェースを提供する)、および同様の適切なデバッガ表示プログラム、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。
TS 610は、SUT 620をテストするためにHC 601によって制御される。TS 610は、TISAと一貫する形で(たとえば、図1〜図3のTS 110に関して図示し、説明したものなど)機能するように構成され、さらに、対話テスティングをサポートする(たとえば、HC 601上で走行するデバッガによるアクセスを使用可能にすることによって)ように構成される。
TS 610は、メモリ614に結合されたTISAプロセッサ612を含む。TISAプロセッサ612は、SPARC V8(図4A〜4Eおよび図5に関して図示し、上で説明した)、INTEL、および類似物などの任意の適切なプロセッサを使用して実施することができる。メモリ604は、任意の適切なメモリとすることができる。
メモリ614は、1つまたは複数のデバッガ・プログラム・スタブ615を格納する。デバッガ・プログラム・スタブ615は、HC 601上で走行する対応するデバッガ制御プログラム(1つまたは複数)605のデバッガ制御を理解し、これによって、HC 601がTS 610と通信することを可能にする。たとえば、デバッガ・スタブ(1つまたは複数)615は、GDBスタブ、DBXスタブ、Perlスタブ、Bashスタブ、Pythonスタブ、および同様の適切なデバッガ・プログラム・スタブ、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。
メモリ614は、TISA2進ファイル616を格納する。TISA2進ファイル616は、本明細書で図2および図3に関して図示し、説明した形でTS 610によって生成される。TISA2進ファイル616は、SUT 620に対するテスティングを実行するためにTISAプロセッサ612によって実行される。
TS 610は、TISAプロセッサ612に結合されたテスト・アクセス・ポート(TAP)618をも含む。TAP 618は、HC 601によって制御されている間にTISAプロセッサ612がSUT 620のテスティングを実行することを可能にするために、TISAプロセッサ612とSUT 620との間のテスト・インターフェースを提供する。TAP 618は、任意の適切なTAP(たとえば、1149.1 TAP)とすることができる。
TISAプロセッサ612は、インターフェース617を使用してTAP 618とインターフェースする。インターフェース617は、TAPとテストされるシステムとの間の任意の適切なインターフェース(たとえば、TCK、TMS、TDI、TDO、およびオプションでTRST(TAP 618が1149.1 TAPとして実施される場合)をサポートするインターフェースなど)とすることができる。
図6に示されているように、HC 601とTS 610との間にインターフェース609がある。インターフェース609は、HC 601とTS 610との間のローカル通信および/またはリモート通信をサポートすることができる。したがって、HC 601は、ローカルにおよび/またはリモートにTS 610を介してSUT 620の対話テスティングを制御することができる。
たとえば、ローカル・テスティングに関して、インターフェース609を、汎用非同期送受信回路(UART)インターフェース、直列インターフェース、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数として実施することができる。
たとえば、リモート・テスティングに関して、インターフェース609を、伝送制御プロトコル(TCP)/インターネット・プロトコル(IP)または任意の他の適切な通信プロトコルなどの任意の適切な通信機能を使用して実施することができる。これは、HC 601およびTS 610が長い地理的距離だけ分離される可能性があり、それでもHC 601がSUT 620のテスティングを実行するためにTS 610を制御することができる、リモート・テスティングを可能にする。
TISAベースのテスティング環境600では、HC 601は、標準的な接続(たとえば、UART、TCP/IP、および類似物)を介してTS 610の動作を制御することによってSUT 620のテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。
明瞭にするために省略されてはいるが、HC 601およびTS 610が、追加のプロセッサ、追加のメモリ、内部通信バス、入出力モジュール、追加のサポート回路(たとえば、電源)、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のコンポーネントを含むことができることを了解されたい。
明瞭にするために省略されてはいるが、SUT 620を、TISAを使用してテストできる任意のテストされるシステムとすることができることを了解されたい。
主に特定のタイプのデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物に関して図示し、説明したが、TISAベースのテスティング環境600を、さまざまな他のデバッガ制御プログラム、デバッガ表示プログラム、インターフェース、および類似物、ならびにそのさまざまな組合せを使用して完全に対話的なテスティング機能を使用可能にする形で実施できることを了解されたい。
図7に、図6のTISAベースのテスティング環境の例示的実施態様を示す。
図7に示されているように、図7の例示的なTISAベースのテスティング環境700は、GNUツール・スイートが図5Aの例示的なシステム・テスト環境500の対話テスティングをサポートするのに使用される、図6のTISAベースのテスティング環境600の実施態様である。
図7に示されているように、例示的なTISAベースのテスティング環境700は、ホスト・コンピュータ(HC)701、テスティング・システム(TS)710、およびテストされるシステム(SUT)720を含む。
HC 701は、プロセッサ702およびメモリ704を含む。図7のHC 701は、デバッガ制御プログラム(1つまたは複数)605がGDB(GDB 705)を使用して実施され、デバッガ表示プログラム(1つまたは複数)606がDDD(DDD 706)を使用して実施される、図6のHC 601の実施態様である。
TS 710は、TISAプロセッサ712およびメモリ714を含む。図7のTS 710は、TISAプロセッサ612がSPARC V8 ISAを使用して実施され(SPARC V8 TISAプロセッサ712と表される)、デバッガ・プログラム・スタブ(1つまたは複数)615がGDBスタブ(GDBスタブ715)を使用して実施され、TISA2進ファイル616がSPARC V8 TISAプロセッサ712に関連するSPARC V8 ISAに基づいて生成される(TISA2進ファイル716)、図6のTS 610の実施態様である。
TS 710は、SPARC V8 TISAプロセッサ712に結合されたテスト・アクセス・ポート(TAP)718をも含む。図7のTS 710は、TAP 618が1149.1 TAP(1149.1 TAP 718)を使用して実施される、図6のTS 610の実施態様である。
SPARC V8 TISAプロセッサ712は、インターフェース717を使用して1149.1 TAP 718とインターフェースする。インターフェース717は、TCK、TMS、TDI、TDO、およびオプションでTRSTをサポートする標準1149.1インターフェースである。
SUT 720は、図5AのSUT 520である。SUT 720は、図5AのSUT 520のように、異なる基板上の送信器および受信器を含む。
1149.1 TAP 718は、SPARC V8 TISAプロセッサ712がHC 701によって制御されている間にSUT 720のテスティングを実行することを可能にするために、SPARC V8 TISAプロセッサ712とSUT 720との間のテスト・インターフェースを提供する。
図7に示されているように、HC 701とTS 710との間にインターフェース709がある。インターフェース709は、HC 701とTS 710との間のローカル通信および/またはリモート通信(たとえば、ネットワークを介する)をサポートすることができる。したがって、HC 701は、ローカルにおよび/またはリモートにTS 710を介してSUT 720の対話テスティングを制御することができる。
例示的なTISAベースのテスティング環境700では、HC 701は、インターフェース709を介してTS 710の動作を制御することによってSUT 720に対するテスト実行をステップごとに制御することができ、これによって、対話テスティング機能および対話デバッギング機能を使用可能にする。
図7の左側のほとんどが、既存のコンピュータ・サイエンス要素すなわちHC 701全体ならびにTS 710上のGDBスタブ715を再利用することを了解されたい。これは、図7の中央部分についても同一であり、中央部分では、HC 701とTS 710(ならびにそれらに関連する副要素)との間の類似が明白である。TISAは、システム・テスティングを提供するためにこのインフラストラクチャ全体を活用することを可能にする。
例として、図5Aのシステム・テスト環境500(関連する例示的なCプログラム、SVF命令、TISAアセンブラ命令、およびTISAコーディングを含む)を参照すると、(a)変数「sent_value」および「received_value」を監視している間のステップごとの実行、(b)tapに送るべき値(変数「sent_value」)のオンザフライ変更、(c)ループ終了条件の変更、(d)すべての変数の監視、および類似物、ならびにそのさまざまな組合せなど、GDB(または任意の他の適切なデバッガ)を活用することによってTISAが使用可能にすることのできる多数の対話テスト動作がある。これらの対話テスト動作は、GDBの標準動作であり、TISAは、上で説明したアルゴリズム部分とテスト・アクセス部分との間の制御を自動的にハンドオフするTISAの能力に起因して、これらを直接に使用することができる。TISAがない場合には、特殊なツーリングを開発し、各ハンドオフ実施態様に適合させる必要があるはずである。
図7の例示的なTISAベースのテスティング環境700を、主に、特定のテストされるシステムの対話テスティングをサポートするのにGNUツール・スイートを使用することに関して本明細書で図示し、説明したが、本明細書の教示によって情報を与えられた当業者は、TISAベースのテスト環境での対話テスティング機能を、任意のタイプのテストされるシステムをテストするために任意の適切なツール・スイートを使用して実現できることを了解するであろう。
図6のTISAベースのテスティング環境600および図7の例示的なTISAベースのテスティング環境700を、主に、テスティングが事前に決定されたアルゴリズムに従ってステップごとに行われる直線的なテスト手順に関して本明細書で図示し、説明したが(TISAによって使用可能にされる対話テスティング機能を説明する際の明瞭さのために)、TISAによって使用可能にされるコンピュータ・サイエンス経験およびコンピュータ・サイエンス技法の活用に起因して、他のより複雑な対話テスティング・シナリオが可能であることを了解されたい。TISAによって使用可能にされるより複雑な対話テスティング・シナリオの例を、図8に関して図示し、本明細書で説明する。これが、単に1つの例であり、本明細書の教示によって情報を与えられた当業者が多数の他の対話テスティング・シナリオおよび対話テスティング応用例でTISAを使用できることを了解されたい。
本明細書で説明されるように、粒度と対話との両方をサポートすることに加えて、TISAは、並列性をもサポートする。
TISAは、システム・テスティング・フローをコンピュータ・サイエンス・ソフトウェア・フローと自然に十分に合併し、したがって、両方のフローの最良の態様を活用することができる。例として、STAPLなどの手法は、定義により、完全に順次的なので、機器の並列制御を扱うのが困難である。さらに、MTCおよびSystemBISTなどの手法は、本質的に順次的であり、シングルタスクであり、したがって、並列性をサポートするためにそのような手法をプログラムすることは、むずかしく、不便であるはずである。対照的に、並列実行は、コンピュータ・サイエンスでは周知の問題であり、現在は、たとえば、すべてのオペレーティング・システムの根底にある。並列実行をサポートする大量のライブラリが使用可能であり(たとえば、POSIXスイート、BOOSTスイート、および類似物)、ほとんどの現代のプロセッサは、マルチタスキングおよびコンテキスト切替を効率的にサポートするように設計されている(たとえば、たとえばSPARC V8は、回転するレジスタ・ウィンドウを実施する)。TISAによって使用可能にされるシステム・テスティング・フローとコンピュータ・サイエンス・ソフトウェア・フローとの間の自然な相互作用は、TISAが並列性に対するそのようなコンピュータ・サイエンス手法を完全に活用することを可能にする。
TISAによる並列性機能のサポートは、例によってよりよく理解することができる。例として、図5Aおよび図7のテストされるシステム520の送信器522と受信器526との間のT−Rチャネルのデータ転送速度を最適化するという問題を検討されたい。これは、第1基板521上の送信器522からデータ・パターンのストリームを送信することと、第2基板525上の受信器526でデータ・パターンの対応するストリームを受信することと、ビット速度/誤り率を計算し、それ相応に送信器522および/または受信器526のパラメータを調整するためにデータ・パターンの送信されたストリームおよび受信されたストリームを比較することとを含むはずである。この最適化を、並列に動作する3つのプログラムを使用して効率的に実行することができる。
図8に、図5Aおよび図7のテストされるシステムの送信器−受信器チャネルの最適化を実行するための例示的プログラム・アーキテクチャを示す。
図8に示されているように、例示的なプログラム・アーキテクチャは、パターン・ジェネレータ802、パターン受信器804、およびコンパレータ806を含む。パターン・ジェネレータ802、パターン受信器804、およびコンパレータ806は、協力して、図5Aおよび図7のテストされるシステム520の送信器522と受信器526との間のT−Rチャネルのデータ転送速度を最適化する。
パターン・ジェネレータ802は、適切な入力データ・パターンを第1基板521上の送信器522(T)に送る。パターン・ジェネレータ802は、第1基板521(B1)のスキャン・チェーン523を介して送信器522に入力データ・パターンを供給するために、TAP(実例として、図5AのTAP 510、図7のTAP 718)にアクセスすることができる。パターン・ジェネレータ802は、任意の適切な形で(たとえば、図5Aに関して本明細書で説明したコードの行12〜13で指定されるように)送信器522に入力データ・パターンを供給することができる。入力データ・パターンは、送信器522と受信器526との間のT−Rチャネルを最適化するのに適する任意のデータ・パターンとすることができる。たとえば、入力データ・パターンを、事前に計算されたパターン、ランダム・パターン、および類似物、ならびにそのさまざまな組合せとすることができる。
パターン受信器804は、第2基板525上の受信器526(R)から適切な出力データ・パターンを収集する。パターン受信器804は、第2基板525(B2)のスキャン・チェーン527を介して受信器526から出力データ・パターンを収集するために、TAP(実例として、図5AのTAP 510、図7のTAP 718)にアクセスすることができる。パターン受信器804は、任意の適切な形で(たとえば、図5Aに関して本明細書で説明したコードの行14〜15で指定されるように)受信器526から出力データ・パターンを収集することができる。
コンパレータ806は、パターン・ジェネレータ802およびパターン受信器804と通信する。コンパレータは、入力データ・パターンと出力データ・パターンとを比較する。コンパレータ806は、T−Rチャネルのビット伝送速度およびビット誤り率を評価し、この比較の結果に基づいて、T−Rチャネルのパラメータを最適化するために送信器522と受信器526との両方の制御レジスタ(明瞭にするために図5Aおよび図7では省略されている)にアクセスすることができる。
そのような最適化テスティング手順を実行するために、パターン・ジェネレータ802、パターン受信器804、およびコンパレータ806は、並列に働く必要があり、それぞれが、他とは独立にTAPにアクセスできなければならない。このタイプの制御構造は、TAPを介する1点直列ハンドオフ制御だけをサポートするように開発された伝統的な環境では、コーディングするのが非常にむずかしい。このタイプの制御構造は、やはり同一の直列TAPアクセス・パラダイムを共有するMTCまたは他のそのような手法を使用する環境でも、コーディングするのが非常にむずかしい。対照的に、TISAは、テスト・アクセスに関するそのような仮定を伴って設計されているのではなく、TISAでは、テスト・アクセスが、他のプロセッサ・リソースに似た形で処理され、テスト・アクセス命令は、古典的なISA命令と直接に混合される。TISAを使用すると、図8の最適化テスティング手順を、プロセス、スレッド・プロセス間通信(IPC)、および類似物、ならびにそのさまざまな組合せなどの標準的構造を使用する任意のマルチタスキング・オペレーティング・システムによって実行することができる。この形で、パターン・ジェネレータ802、パターン受信器804、およびコンパレータ806は、TAPへのアクセスを共有することができ、たとえば、たとえばダイクストラのセマフォなどの周知の構造およびアルゴリズムを使用して、すべてのプロセッサ・リソースについて行われるのと同様に、すべての最終的なTAP共有問題を解決することができる。したがって、既存のシステム・テスティング機能は並列性をサポートしないが、TISAが簡単に完全に並列性をサポートすることは明白である。
上で説明したように、TISAは、テスト・アクセス方法または関連するテスト・プログラム区分に関する仮定を一切設けず、テスト命令は、テスト命令と古典的ISA命令との間の先見的分離を全く伴わずに、古典的ISA命令と同一の形または実質的に同一の形で扱われる。これは、TISAをすべての既存の(および最もありそうなことに将来の)コンピュータ・サイエンス・アルゴリズムおよびコンピュータ・サイエンス構造と完全に互換にすることを可能にし、これは、既存のテスト・プロセッサ手法がサポートできないことである。
したがって、すべての既存ソフトウェア・ライブラリをTISAアーキテクチャに移植できることを了解されたい。たとえば、POSIXスイートおよびBOOSTスイートを活用することによって、マルチタスキングおよび並列性を入手することは、簡単であるはずである(たとえば、図8に関して本明細書で図示し、説明したように)。さらに、TISAが既存ISAの一般化として入手される(たとえば、図5Aおよび図5Bに関して図示し、説明した例示的なSPARC V8 TISA実施態様に関して図示し、説明したように)場合には、TISAがそれから開発されたISAが既にそのようなソフトウェア・ライブラリを含むので、移植が必要でない場合さえあることを了解されたい。
さらに、さまざまな他のコンピュータ・サイエンス技法を、TISAを使用する改善されたシステム・テスティングを提供するために利用できることを了解されたい。たとえば、TISAのために活用できるそのようなコンピュータ・サイエンス技法のいくつかの例は、(a)プラットフォーム独立コーディング・スタイルの使用、(b)ISA対ISAコンバータの使用、(c)プラットフォーム独立バイトコードを入手するための、たとえばJavaのような、仮想マシン手法の使用、またはTISAになるためのJava仮想マシン自体の拡張の使用、および(d)その後に適切なドライバによってプリミティブに変換される、いくつかのTISAソフトウェア・インターフェースを標準化するためのアプリケーション・プログラミング・インターフェース(API)の使用を含む。これらの例が、単にTISAのために活用できるコンピュータ・サイエンス技法の少数の例であることを了解されたい。
図9に、テストされるシステムの少なくとも一部をテストする際のプロセッサによる使用のために適合されたテスト命令セット・アーキテクチャ(TISA)命令を含むTISAフローを形成するためにプロセッサの命令セット・アーキテクチャ(ISA)フローを適合させる方法の一実施形態を示す。
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法900のステップの少なくとも一部を、同時にまたは図9に関して図示され説明されるものとは異なる順序で実行することができる。
ステップ902では、方法900が開始される。
ステップ904では、命令の第1セットを生成する。命令の第1セットは、プロセッサによってサポートされるISA命令を含む(すなわち、プロセッサにTISAを提供するために活用されるISA命令)。
ステップ906では、命令の第2セットを生成する。命令の第2セットは、テストされるシステムに関連するテスト命令を含む。命令の第2セットは、たとえば図2のTGT 210に関して図示し、説明したように、図3のTGT 310に関して図示し、説明したように、および/またはテスト命令を生成する任意の他の適切な方法を使用して、任意の適切な形で生成することができる。
ステップ908では、命令の第1セットおよび命令の第2セットを統合して、これによってTISA命令を形成する。TISA命令は、プロセッサにTISAを提供する。
ステップ910では、TISA命令を格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。TISA命令を、任意の他の適切な形で処理することができる。
ステップ912では、方法900が終了する。
TISAを、任意の適切な形で、たとえば、図10の方法1000に関して図示し、説明するように、図2のテスト・システムおよび図11Aの関連する方法1110に関して図示し、説明するように、図3のテスト・システムおよび図11Bの関連する方法1120に関して図示し、説明するように、ならびに/またはTISAを形成する任意の適切な方法を使用して、形成することができる。
図10に、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に直列に実行されるものとして図示され、本明細書で説明されるが、方法1000のステップの少なくとも一部を、同時にまたは図10に関して図示され説明されるものとは異なる順序で実行することができる。ステップ1002で、方法1000が開始される。
ステップ1004では、命令の第1セットを生成する。命令の第1セットは、少なくとも1つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成される命令(たとえば、プロセッサによってサポートされるISAのISA命令)を含む。
ステップ1006では、命令の第2セットを生成する。命令の第2セットは、テストされるシステムに関連する少なくとも1つの記述ファイルをコンパイルすることによって生成されるテスト命令を含む。
ステップ1008では、命令の第1セットおよび第2セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第1セットの命令が、命令の第2セットのテスト命令の実行を制御する際の使用のために適合される。
ステップ1010では、命令の組み合わされたセットを格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ1012で、方法1000は終了する。
図11Aおよび図11Bに、図9に関して図示し、説明した方法900および/または図10に関して図示し、説明した方法1000のより詳細な実施形態を示す。
図11Aに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に特定のシーケンスで実行されるものとして図示され、説明されるが、図11Aの方法1110のステップの少なくとも一部を、図11Aに関して図示し、説明するものとは異なる順序で実行することができる。図11Aを、図2および図2の関連する説明と共に見ることによってよりよく理解することができる。
ステップ1111で、方法1000が開始される。
ステップ1112では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも1つのコンピュータ・サイエンス・ソフトウェア・ファイルをコンパイルすることによって生成され(たとえば、プロセッサによってサポートされるISAのISA命令)、少なくとも1つのコンピュータ・サイエンス・ソフトウェア・ファイルは、少なくとも1つの呼出しを含む。
ステップ1113では、命令の第1セットを生成する。命令の第1セットは、プログラム・モデルを使用して生成される。少なくとも1つの計算要求も、少なくとも1つのコンピュータ・サイエンス・ソフトウェア・ファイルに含まれる少なくとも1つの呼出しを使用して生成される。
ステップ1114では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも1つのシステム記述ファイルをコンパイルすることによって生成される。
ステップ1115では、命令の第2セットを生成する。命令の第2セットは、回路モデルおよび少なくとも1つの計算要求を使用して生成される。
ステップ1116では、命令の第1セットおよび第2セットを組み合わせて、命令の組み合わされたセットを形成する。命令の組み合わされたセットでは、命令の第1セットの命令が、命令の第2セットのテスト命令の実行を制御する際の使用のために適合される。
ステップ1117では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ1118では、方法1000が終了する。図11Bに、テストされるシステムの少なくとも一部をテストする際の使用のために適合された命令を生成する方法の一実施形態を示す。主に順次実行されるものとして図示され、説明されるが、図11Bの方法1120のステップの少なくとも一部を、同時にまたは図11Bに関して図示し、説明するものとは異なる順序で実行することができる。図11Bを、図3および図3の関連する説明と共に見ることによってよりよく理解することができる。
ステップ1121で、方法1100が開始される。
ステップ1122では、少なくとも1つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよび少なくとも1つのテスト動作記述ファイルを、少なくとも1つのコンピュータ・サイエンス・ソフトウェア・ファイルを前処理することによって生成する。
ステップ1123では、回路モデルを生成する。回路モデルは、テストされるシステムに関連する少なくとも1つのシステム記述ファイルおよび少なくとも1つのテスト動作記述ファイルをコンパイルすることによって生成される。
ステップ1124では、テスト動作のセットを生成する。テスト動作のセットは、回路モデルを使用して生成される。テスト動作のセットからのテスト動作は、テスト・プリミティブ(たとえば、回路モデルを生成するテスト生成ツールによって定義されるテスト・プリミティブ)のセットを使用して記述される。テスト・プリミティブのセットは、テストされるシステムをテストする際の使用のために適合されたテスト動作を含む。
ステップ1125では、テスト動作のセットのテスト・プリミティブを命令セット・アーキテクチャのソフトウェア命令と組み合わせての使用のために適合されたテスト命令に変換することによって、テスト動作のセットをテスト命令のセットに変換する。
ステップ1126では、プログラム・モデルを生成する。プログラム・モデルは、少なくとも1つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルおよびテスト命令のセットをコンパイルすることによって生成される。
ステップ1127では、命令の組み合わされたセットを生成する。命令の組み合わされたセットは、プログラム・モデルを使用して生成される。命令の組み合わされたセットは、(a)少なくとも1つの前処理済みコンピュータ・サイエンス・ソフトウェア・ファイルから決定されたソフトウェア命令および(b)テスト命令のセットからのテスト命令を含む。
ステップ1128では、命令の組み合わされたセットを、格納し、表示し、伝搬させ、かつ/または実行し、あるいはその任意の組合せを行う。命令の組み合わされたセットを、任意の他の適切な形で処理することができる。
ステップ1129では、方法1120が終了する。
図12に、TISAプロセッサ・アーキテクチャの例示的実施形態を示す。
図12に示されているように、TISAプロセッサ・アーキテクチャ1200は、TISAプロセッサ1210およびメモリ1220を含む。
TISAプロセッサ1210は、SPARC V8プロセッサ、INTELプロセッサ、または任意の他の適切なプロセッサなど、TISAを使用するシステム・テスティングを実行するのに適する任意のプロセッサとすることができる。
メモリ1220は、ランダム・アクセス・メモリ、永続メモリ、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数を含む、TISAを使用するシステム・テスティングをサポートするためのTISAプロセッサ1210による使用に適する任意のメモリを含むことができる。メモリ1220は、テスト・プログラム、TISA命令、テスティング・データ、および類似物、ならびにそのさまざまな組合せなど、TISAを使用するシステム・テスティングを実行するのに必要な任意の情報を格納することができる。
一実施形態では、たとえば、図12のTISAプロセッサ・アーキテクチャ1200は、図2および図3に関して図示し、説明したTISAフローをサポートすることができる。
一実施形態では、たとえば、図12のTISAプロセッサ・アーキテクチャ1200は、図6に関して図示し、説明したテスティング・システム610のTISAプロセッサ612およびメモリ614に似た形で動作することができる。たとえば、図12のTISAプロセッサ・アーキテクチャ1200を、図7に関して図示し、説明したテスティング・システム710内など、SPARC V8 TISAプロセッサおよび関連するメモリを使用して実施することができる。そのような実施形態では、TISAプロセッサ1210自体が、ISA命令とTISA命令との両方を解釈し、実行する。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート(TAP)を介してテストする際に使用される装置は、テスト命令セット・アーキテクチャの命令のセットを格納するメモリと、テストされるシステムの少なくとも一部をTAPを介してテストするためにテスト命令セット・アーキテクチャの命令のセットを実行するプロセッサとを含む。テスト命令セット・アーキテクチャの命令のセットは、プロセッサによってサポートされる命令セット・アーキテクチャ(ISA)の複数の命令を含む命令の第1セットと、TAPに関連する複数のテスト命令を含む命令の第2セットとを含み、命令の第1クラスの命令および命令の第2クラスの命令は、これによってテスト命令セット・アーキテクチャの命令のセットを形成するために統合される。
一実施形態では、テストされるシステムの少なくとも一部をテスト・アクセス・ポート(TAP)を介してテストする際に使用されるTISAプロセッサは、プロセッサによってサポートされる命令セット・アーキテクチャ(ISA)の命令を含む命令の第1クラスと、TAPに関連するテスト命令を含む命令の第2クラスとを含み、命令の第1セットのISA命令および命令の第2セットのテスト命令は、テストされるシステムの少なくとも一部をテストするために適合されたTISAを形成するために統合される。
一実施形態では、テストされるシステム(SUT)をテスト・アクセス・ポート(TAP)を介してテストするコンピュータ・プロセッサは、TAPを介するテストされるシステムとの相互作用を可能にするセマンティクスを有するテスト命令セット・アーキテクチャ(TISA)に従って命令を処理するように構成された回路網を含む。TISAは、第1タイプの複数の命令および第2タイプの複数の命令を含み、命令の第1タイプは、コンピュータ・プロセッサによってサポートされる命令セット・アーキテクチャ(ISA)の命令を含み、命令の第2タイプは、TAPを介してテストされるシステムをテストするためのテスト命令を含む。
主にTISAプロセッサが特定の形で(たとえば、異なるクラスおよび/またはタイプの命令を記述するのに特定の言語を使用して)定義される実施形態に関して上で図示し、説明したが、TISAを、本明細書で提供されるさまざまなTISAの図示および説明によって完全にサポートされる他の形で定義できることを了解されたい。
主に、TISAをサポートするのに単一プロセッサを使用してTISAプロセッサ・アーキテクチャが実施される実施形態に関して本明細書で図示され、説明されるが、他の実施形態では、TISAプロセッサ・アーキテクチャを、複数のプロセッサを使用して実施することができる。
図13に、システム・テスティング機能を提供するために複数のプロセッサを利用するテスト・プロセッサ・アーキテクチャの例示的実施形態を示す。
図13に示されているように、テスト・プロセッサ・アーキテクチャ1300は、通信経路1330を介して通信する主プロセッサ1310および副プロセッサ1320を含む。
主プロセッサ1310は、SPARC V8プロセッサ、INTELプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。主プロセッサ1310は、テストされるシステムをテストする命令を実行する。一実施形態では、たとえば、主プロセッサ1310は、図12のTISAプロセッサ・アーキテクチャ1200のCPU 1210によってサポートされる機能に似たテスティング機能をサポートすることができる(たとえば、テスト・プロセッサ・アーキテクチャ1300がTISAを利用する場合に)。一実施形態では、たとえば、主プロセッサ1310は、TISAを利用しないテスト・プロセッサ・アーキテクチャ内のテストするプロセッサによってサポートされるテスティング機能をサポートすることができる。主プロセッサ1310は、さまざまな他のテスティング機能をサポートすることができる。
副プロセッサ1320は、SPARC V8プロセッサ、INTELプロセッサ、または任意の他の適切なプロセッサなど、システム・テスティングをサポートするのに適する任意のプロセッサとすることができる。副プロセッサ1320は、テストされるシステム(明瞭さのために省略されている)へのテスト・アクセス・ポート(TAP)インターフェースをサポートする。このTAPインターフェースは、任意の適切なTAPとインターフェースすることができる。たとえば、このTAPインターフェースは、IEEE 1149.1 TAPまたはテストされるシステムをテストするのに使用できる任意の他の適切なTAPへのインターフェースを提供することができる。
主プロセッサ1310および副プロセッサ1320は、テストされるシステムの少なくとも一部のテストを実行するために協力する。
主プロセッサ1310は、テストされるシステムをテストするテスト命令を実行する。このテスト命令は、TISAのテスト命令とすることができ(テスト・プロセッサ・アーキテクチャ1300がTISAを利用する場合)、あるいはTISAに関連しないテスト命令とすることができる(テスト・プロセッサ・アーキテクチャ1300がTISAを利用しない場合)。主プロセッサ1310は、テスト命令の実行中に、テストされるシステムのTAPの制御に関係する命令(たとえば、テストされるシステムのTAPコントローラに入力データをロードする命令、テストされるシステムのTAPコントローラから出力データを読み取る命令、および同様の命令、ならびにそのさまざまな組合せなど)を検出する。主プロセッサ1310は、副プロセッサ1320にTAP関連命令を供給する。副プロセッサ1320は、主プロセッサ1310からそのTAP関連命令を受け取る。副プロセッサ1320は、そのTAP関連命令を実行する。主プロセッサ1310は、副プロセッサ1320が主プロセッサ1310から受け取ったTAP関連命令を実行する間に、テスト命令の実行を継続する。この形で、主プロセッサ1310は、副プロセッサ1320がテストされるシステムのTAPを介するスキャン動作を制御する間に、コンテキスト切替を実行し、動作を継続することができる。これは、単一プロセッサ手法を使用すると困難である。というのは、単一プロセッサがTAPを制御している間に、その単一プロセッサが、他の動作の実行を止められるからである。したがって、テスト・プロセッサ・アーキテクチャ1300内のような複数プロセッサの使用は、特にTAPを介する動作が通常はプロセッサが単一の動作を実行するのに要する時間と比較して長い時間を要することを考慮すると、ハイエンド・プロセッサを使用する必要なしにテスティング効率の大幅な改善を提供する。
テストされるシステムの少なくとも一部のテストを実行するための主プロセッサ1310と副プロセッサ1320との間の協力は、通信経路1330によって容易にされる。通信経路1330は、主プロセッサ1310と副プロセッサ1320との間通信の任意の適切な手段を使用して実施することができ、この手段は、テスト・プロセッサ・アーキテクチャ1300がそれを用いて実施されるマルチプロセッサ・アーキテクチャのタイプに依存する可能性がある。たとえば、通信経路1330は、メイン・プロセッサ・インターフェース・バス、補助プロセッサ・インターフェース、通信インターフェース(たとえば、シリアライザ−デシリアライザ(SERDES)インターフェースまたは他の適切な通信インターフェース)、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。
明瞭さのために省略されているが、テスト・プロセッサ・アーキテクチャ1300が、メモリ(たとえば、ランダム・アクセス・メモリ、永続メモリ、キャッシュ・メモリ、および類似物、ならびにそのさまざまな組合せ)を含むことを了解されたい。テスト・プロセッサ・アーキテクチャ1300のメモリは、主プロセッサ1310および副プロセッサ1320によって共有されるメモリ、主プロセッサ1310に専用のメモリ、副プロセッサ1320に専用のメモリ、および類似物、ならびにそのさまざまな組合せのうちの1つまたは複数を含むことができる。
明瞭さのために省略されているが、テスト・プロセッサ・アーキテクチャ1300が、バス、I/O回路、および類似物、ならびにそのさまざまな組合せなどのさまざまな他のサポート回路を含むことができることを了解されたい。
図13のテスト・プロセッサ・アーキテクチャ1300を、複数の形で実施することができる。
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置(CPU)がシステム・テスティングをサポートするためにテスト・コプロセッサ・ユニット(TCPU)と協力する、テスト・コプロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図14に関して図示し、説明する。
一実施形態では、たとえば、テスト・プロセッサ・アーキテクチャは、中央処理装置(CPU)がシステム・テスティングをサポートするためにテスト付属プロセッサ・ユニット(TAPU)と協力する、テスト付属プロセッサ・ユニット・アーキテクチャを使用することができる。例示的実施形態を、図15に関して図示し、説明する。
図14に、テスト・コプロセッサ・アーキテクチャの例示的実施形態を示す。テスト・コプロセッサ・アーキテクチャ1400は、TISAを使用するシステム・テスティングをサポートするためのTISAプロセッサ・アーキテクチャとしての使用に適する。テスト・コプロセッサ・アーキテクチャ1400は、TISAを使用しないシステム・テスティングをサポートするためのテスト・プロセッサ・アーキテクチャとしての使用にも適する。
テスト・コプロセッサ・アーキテクチャ1400は、中央処理装置(CPU)1410、テスト・コプロセッサ・ユニット(TCPU)1420、メイン・メモリ1430、およびフラッシュ・メモリ1440を含む。
テスト・コプロセッサ・アーキテクチャ1400は、メイン・プロセッサ・インターフェース・バス1451を含む。CPU 1410、TCPU 1420、メイン・メモリ1430、およびフラッシュ・メモリ1440は、それぞれ、メイン・プロセッサ・インターフェース・バス1451に結合される(または、他の形でこれと通信できるように構成される)。
テスト・コプロセッサ・アーキテクチャ1400は、補助プロセッサ・インターフェース1452をも含むことができ、補助プロセッサ・インターフェース1452は、CPU 1410およびTCPU 1420を直接に結合し、これによって、CPU 1410とTCPU 1420との間の直接通信を可能にする。
CPU 1410は、テストされるシステムのシステム・テスティングを実行するのに適する任意のCPUとすることができる。CPU 1410は、図13に関して図示し、説明した主プロセッサ1310によってサポートされるテスティング機能をサポートする。
TCPU 1420は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のCPUとすることができる。TCPU 1420は、テスト・アクセス・ポート(TAP)インターフェース1460をサポートし、TAPインターフェース1460は、任意の適切なTAP(たとえば、IEEE 1149.1 TAPまたはテストされるシステムをテストするのに使用される任意の他の適切なTAPなど)とインターフェースすることができる。TCPU 1420は、図13に関して図示し、説明した副プロセッサ1320によってサポートされるテスティング機能をサポートする。
CPU 1410およびTCPU 1420は、図13に関して図示し、説明した主プロセッサ1310および副プロセッサ1320に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。CPU 1410およびTCPU 1420は、TCPU 1420がテスティング中にテストされるシステムのTAPを制御するTAP関連命令を実行する間にCPU 1410がテスト命令を処理する動作を継続することを可能にするために、命令例外処理を利用する。
CPU 1410は、テストされるシステムをテストするテスト命令を実行する。CPU 1410は、テスト命令の実行中に命令例外(すなわち、テストされるシステムのTAPの制御に関係する命令)を検出し、その命令例外をTCPU 1420に供給する。TCPU 1420は、CPU 1410からその命令例外を受け取り、その命令例外を処理し、TCPU 1420が、CPU 1410が他のタスク(たとえば、他のテスティング命令の実行)を実行するために動作し続ける間にその命令例外を処理できるようになっている。言い換えると、CPU 1410およびTCPU 1420は、システム・テスティング中に協力し、TCPU 1420がCPU 1410によって検出された命令例外を処理する間にCPU 1410がコンテキストを切り替え、他のタスクを実行するために動作し続けられるようにし、これによって、システム・テスティング効率を改善する。
一実施形態では、CPU 1410は、たとえばCPU 1410の性能を改善するために、キャッシュ1411を含む。
一実施形態では、TCPU 1420は、直接メモリ・アクセス(DMA)ユニット1421を含み、DMAユニット1421は、システム・テスティングをサポートして使用するのに適する任意のタイプのDMAユニットとすることができる。一実施形態では、たとえば、DMAユニット1421は、スキャッタ/ギャザ(S/G)DMAユニットである。TCPU 1420は、CPU 1410から受け取った命令例外を処理するためおよびメモリ内に格納された実体的なデータに効率的にアクセスするためにDMAユニット1421を利用することができる。一実施形態では、CPU 1410は、命令例外に出会う前に、S/G DMAテーブルを構成することができる。
一実施形態では、TCPU 1420は、特殊化されたTCPU命令のセットをサポートする。特殊化されたTCPU命令のセットは、TAPアクセスおよびTAP制御をサポートすることができる。特殊化されたTCPU命令のセットを、TAP状態機械に対して特定のTAP動作を実行するためにTCPU 1420によって使用することができる。
CPU 1410およびTCPU 1420は、CPU 1410によるテスト命令の実行、TCPU 1420による命令例外処理、TCPU 1420によるTCPU命令の実行、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ1430および/またはフラッシュ・メモリ1440を利用する。メイン・メモリ1430は、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ1440は、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の永続メモリとすることができる。CPU 1410およびTCPU 1420は、調停されるアクセスを用いてメモリを共有する。CPU 1410およびTCPU 1420は、情報を交換するためにメモリを共有することもできる。主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、CPU 1410およびTCPU 1420によって実行される機能をサポートするために使用できることを了解されたい。
CPU 1410およびTCPU 1420は、CPU 1410とTCPU 1420との間の通信、CPU 1410および/またはTCPU 1420とテスト・コプロセッサ・アーキテクチャ1400の他のコンポーネント(たとえば、メイン・メモリ1430、フラッシュ・メモリ1440、および他のコンポーネント)との間の通信、および類似物、ならびにそのさまざまな組合せを使用して、テストされるシステムのテスティングを実行する。この通信を、メイン・プロセッサ・インターフェース・バス1441および補助プロセッサ・インターフェース1452の一方または両方を使用してサポートすることができる。CPU 1410とTCPU 1420との間の通信は、命令例外通知、割込みアクセス、DMA調停、および類似物、ならびにそのさまざまな組合せに関連する通信を含むことができる。CPU 1410およびTCPU 1420とテスト・コプロセッサ・アーキテクチャ1400の他のコンポーネントとの間の通信は、メモリからの読取、メモリへの書込、および/またはテストされるシステムをテストするのを支援して実行できる任意の他のタスクに関連する通信を含むことができる。
図15に、テスト付属プロセッサ・アーキテクチャの例示的実施形態を示す。テスト付属プロセッサ・アーキテクチャ1500は、TISAを使用するシステム・テスティングをサポートするTISAプロセッサ・アーキテクチャとしての使用に適する。テスト付属プロセッサ・アーキテクチャ1500は、TISAを使用しないシステム・テスティングをサポートするテスト・プロセッサ・アーキテクチャとしての使用にも適する。
テスト付属プロセッサ・アーキテクチャ1500は、中央処理装置(CPU)1510およびテスト付属プロセッサ・ユニット(TAPU)1520を含む。CPU 1510およびTAPU 1520は、同一基板上に存在することができ、あるいは、異なる基板上に存在することができる。
CPU 1510は、テストされるシステムのシステム・テスティングを実行するのに適する任意のCPUとすることができる。CPU 1510は、図13に関して図示し、説明した主プロセッサ1310によってサポートされるテスティング機能をサポートする。
CPU 1510は、それに関連するメイン・メモリ1530M、フラッシュ・メモリ1530F、および入出力モジュール1540を有する。CPU 1510は、それに関連するメイン・プロセッサ・インターフェース・バス1550を有する。CPU 1510、メイン・メモリ1530M、フラッシュ・メモリ1530F、および入出力モジュール1540は、それぞれ、メイン・プロセッサ・インターフェース・バス1550に結合される(または、他の形でこれと通信できるように構成される)。
一実施形態では、CPU 1510は、たとえばCPU 1510の性能を改善するために、キャッシュ1511を含む。
TAPU 1520は、テストされるシステムのシステム・テスティングを容易にするのに適する任意のCPUとすることができる。TAPU 1520は、入出力モジュール1521を含む。TAPU 1520は、テスト・アクセス・ポート(TAP)インターフェース1590をサポートし、TAPインターフェース1590は、任意の適切なTAP(たとえば、IEEE 1149.1 TAPまたはテストされるシステムをテストするのに使用される任意の他の適切なTAPなど)とインターフェースすることができる。TAPU 1520は、図13に関して図示し、説明した副プロセッサ1320によってサポートされるテスティング機能をサポートする。
TAPU 1520は、それに関連するローカル・テスト・メモリ1560を有する。TAPU 1520は、それに関連する内部インターフェース・バス1570を有する。TAPU 1520およびローカル・テスト・メモリ1560は、それぞれ、内部インターフェース・バス1570に結合される(または、他の形でこれと通信できるように構成される)。
CPU 1510に関連する入出力モジュール1540およびTAPU 1520の入出力モジュール1521は、CPU 1510とTAPU 1520との間の通信を使用可能にする通信インターフェース1580をサポートする。通信インターフェース1580は、CPU 1510からTAPU 1520へのTAP関連通信のストリーミングをサポートする。
一実施形態では、CPU 1510に関連する入出力モジュール1540およびTAPU 1520の入出力モジュール1521は、シリアライザ−デシリアライザ(SERDES)通信機能をサポートし、したがって、通信インターフェース1580は、SERDESベースの通信インターフェースである。この実施形態では、SERDESベースの通信インターフェース1580を、任意の適切なSERDES通信プロトコル(たとえば、ギガビット・イーサネット(GigE)、Serial Rapid IO(SRIO)、Peripheral Component Interconnect Express(PCIe)、および類似物など)を使用して実施することができる。主にCPU 1510とTAPU 1520との間のSERDESベースの通信の使用に関して図示され、本明細書で説明されるが、他の適切な通信機能を、CPU 1510とTAPU 1520との間の通信をサポートするために使用することができる。
CPU 1510およびTAPU 1520は、図13に関して図示し、説明した主プロセッサ1310および副プロセッサ1320に似た形で、テストされるシステムの少なくとも一部のテスティングを実行するために協力する。CPU 1510およびTAPU 1520は、TAPU 1520がテスティング中にテストされるシステムのTAPを制御するTAP関連命令を実行する間にCPU 1510がテスト命令を処理するために動作を継続することを可能にするために、通信インターフェース1580を介するコマンド・ストリーミングを利用する。
CPU 1510は、テストされるシステムをテストするテスト命令を実行する。CPU 1510は、それらのテスト命令の実行中に、テストされるシステムのTAPの制御に関係する命令を検出する。CPU 1510は、それらのTAP関連命令を通信インターフェース1580を介してTAPU 1520に(すなわち、通信インターフェース1580を介する伝搬のために、CPU 1510からメイン・プロセッサ・インターフェース・バス1550を介して入出力モジュール1540に)伝搬させる。TAPU 1520は、CPU 1510からTAP関連命令を受け取り、CPU 1510が他のタスク(たとえば、他のテスティング命令の実行)を実行するために動作し続ける間にTAPU 1520がTAPの制御を処理できるように、それらのTAP関連命令を処理する。言い換えると、CPU 1510およびTAPU 1520は、TAPU 1520がCPU 1510によって検出されたTAP関連命令を処理する間にCPU 1510がコンテキストを切り替え、他のタスクを実行するために動作し続けられるように、システム・テスティング中に協力し、これによってシステム・テスティング効率を改善する。
一実施形態では、CPU 1510によって検出され、TAPU 1520によって処理されるTAP関連命令は、TAPU 1520への伝搬のためにCPU 1510によってパケット化される。
一実施形態では、CPU 1510によって検出され、TAPU 1520によって処理されるTAP関連命令は、TAPU 1520によってサポートされるオペコードを含む。1つのそのような実施形態では、TAP関連命令は、CPU 1510に関連するメモリとTAPU 1520に関連するメモリとの間(たとえば、メイン・メモリ1530Mとローカル・テスト・メモリ1560との間)でブロック・メモリ・コピーを実行する際の使用に適合された1つまたは複数の拡張コマンドを含むこともできる。
CPU 1510は、テスト命令の実行、TAP関連命令の検出、TAP関連命令のパケット化、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにメイン・メモリ1530Mおよび/またはフラッシュ・メモリ1530Fを利用する。メイン・メモリ1530Mは、任意の適切なプロセッサ・メモリとすることができる。フラッシュ・メモリ1530Fは、任意の適切なフラッシュ・メモリまたは任意の他の適切な形の永続メモリとすることができる。
TAPU 1520は、CPU 1510から受け取ったTAP関連命令の格納、CPU 1510から受け取ったTAP関連命令の処理、および類似物、ならびにそのさまざまな組合せなどのさまざまなテスティング機能を実行するためにローカル・テスト・メモリ1560を利用する。ローカル・テスト・メモリ1560は、任意の適切なプロセッサ・メモリとすることができる。一実施形態では、ローカル・テスト・メモリ1560を、比較的小さくすることができる。というのは、ローカル・テスト・メモリ1560が、スキャン・チェーン全体(オンチップ・メモリ内で要求される場合があるように)ではなく、テストされるシステムのスキャン・チェーンのスキャン・チェーン・セグメントの処理を扱うからである。
主に特定の個数およびタイプのメモリに関して図示され、説明されるが、さまざまな他のメモリ方式を、CPU 1510およびTAPU 1520によって実行される機能をサポートするために使用できることを了解されたい。
主にTISAを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、TISAを、任意の適切なプロセッサ・アーキテクチャを使用して実施でき、このプロセッサ・アーキテクチャが、コプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャ以外のプロセッサ・アーキテクチャを含むことができることを了解されたい。したがって、TISAプロセッサ・アーキテクチャを、さまざまな他の形で複数のプロセッサを使用して実施することができ、これらの形のうちの少なくともいくつかは、TISAをサポートするための3つ以上のプロセッサの使用を含むことができる。
主にTISAアーキテクチャを実施するためのコプロセッサ・アーキテクチャまたは付属プロセッサ・アーキテクチャの使用に関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、コプロセッサ・アーキテクチャおよび付属プロセッサ・アーキテクチャを、それぞれ、他のタイプのテスティング・アーキテクチャ(すなわち、TISAを使用しない他のテスティング・アーキテクチャ)を実施するのに使用できることを了解するであろう。
テスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャは、それぞれがTISAを2つの通信するプロセッサによって実行することを可能にするという点で機能的に似ていることを了解されたい。所与のアプリケーションで、この2つのアーキテクチャの間の選択は、使用可能なリソース、コスト、性能、物理的制約(同一チップ内、異なるチップおよび/または基板内での統合、あるいはその任意の組合せ)、ならびに任意の他の実施態様パラメータなど、実施態様依存パラメータを基礎として設計者が行うことができる。主にテスト・コプロセッサ・アーキテクチャおよびテスト付属プロセッサ・アーキテクチャに関して図示され、本明細書で説明されるが、本明細書の教示によって情報を与えられた当業者は、これらの実施態様考慮事項が、すべての他のタイプのテスティング・アーキテクチャ/インフラストラクチャにあてはまることを了解するであろう。
図示され、本明細書で説明されるTISAプロセッサ・アーキテクチャは、システム・テスティングを実行する際に使用されるすべての適切なTISAを使用することができる。
TISAプロセッサ・アーキテクチャと共に使用されるように適合されたTISAの1つの例示的実施形態の説明が、これに続く。TISAのこの例示的実施形態は、図示され、本明細書で説明されるスキャン・セグメント・レベル・プリミティブの実施態様である。スキャン・セグメント・レベル抽象化レベルでは、テストされるシステムのスキャン・チェーン全体が、セグメントに分割され、これらのセグメントは、アルゴリズムのデータ・アトムとして使用される。テストされるシステムを、アルゴリズム開発者(人間および/または自動化ツールとすることができる)によってスキャン・セグメントに区分できることを了解されたい。スキャン動作をスキャン・セグメント・レベルで実行することを可能にするためのTISAの使用のより一般的な説明すなわち、この例示的なTISA実施態様とは独立な説明を、下で詳細に提供する。
TISAの次の実施形態は、これらのスキャン・セグメントを定義し、処理することのできるレジスタおよび命令のセットを処理する。次の実施形態は、32ビット・サイズのTISAに基づくが、これを任意の他の語サイズ(たとえば、16ビット、64ビット、または任意の他の適切な語サイズ)に適合させることができる。
図16に、TISAプロセッサによって使用できる例示的なレジスタ・セットを示す。例示的なTISAは、それぞれ図16A〜16Dに示された、4つのレジスタ・セット(レジスタ・セットR1からR4と表される)を含む。
図16Aに示されているように、第1レジスタ・セットR1は、次のユーザ・アクセス可能データ・レジスタを含む。
・StatusRegister 状況状態情報を含む32ビット・レジスタ
・ControlRegister コマンド・エンコーディングを含む32ビット・レジスタ
・BlockRegister スキャン・データ・イン(ギャザ・データ)およびデータ・アウト(スキャッタ・データ)を書き込むべき場所を間接的にポイントする事前にフォーマットされたデータ構造へのメモリ内のオフセットを含む32ビット・レジスタ[スキャッタ/ギャザ・セグメント記述にアクセスするすべてのスキャン動作および比較動作に使用される]
・ScanLengthRegister スキャンされるべきままである現在のビット数が常駐する32ビット・レジスタ(ブロック・モード・オペコードのスキャッタ/ギャザ・セグメント記述から自動的に取り込まれもする)
・ScanStateRegister スキャン動作のstartState、scanState、およびendStateを表す4ビットの3つのバンクを含む32ビット・レジスタ。4ビットは、TAP状態機械の16個の状態のエンコーディングを表す(ブロック・モードでスキャッタ/ギャザ・セグメント記述から取り込まれもする)
・UserDataRegisters[1〜11] 小さいスキャン動作およびデータ再利用のためのスキャン・セグメント・データを含む32ビット・レジスタ(ソース・レジスタまたは宛先レジスタになることができる)
図16Bに示されているように、第2レジスタ・セットR2は、次の内部スクラッチ・レジスタを含む。
・BlockPointerRegister MultipleScan命令中に処理される現在のスキャッタ/ギャザ・セグメント記述参照をポイントする32ビット・レジスタ
・BlockCountRegister MultipleScan命令中に処理されるスキャッタ/ギャザ・セグメント記述のカウントを含む32ビット・レジスタ
・InstructionRegister 現在のオペコードがデコーディングのために置かれる32ビット・レジスタ
図16Cに示されているように、第3レジスタ・セットR3は、次のスキャッタ/ギャザ・セグメント記述レジスタを含む。
・BlockOffsetField 64ビット・アーキテクチャが使用される時のアドレスのバンクを記述する32ビット数
・ScanLengthField このセグメントについてスキャンすべきビット数を指定する32ビット数
・StateTraversalField それぞれこのスキャン動作の開始状態、スキャン状態、および終了状態を表す4ビットの3つのフィールド(各4ビットは、16状態TAP状態機械状態を表す)
・SourceLocationField TDIデータがメモリ内のどこに存在するのかに関する32ビット・ベース・アドレス
・DestinationLocationField TDOデータがメモリ内で格納される場所に関する32ビット・ベース・アドレス
・ExpectedValueField 期待されるベクトルがメモリ内のどこに存在するのかに関する32ビット・ベース・アドレス
・ResponseLocationField 取り込まれたTDIデータがメモリ内のどこに存在するのかに関する32ビット・ベース・アドレス
・MaskField 比較動作を制限するのに使用されるMASKデータがメモリ内のどこに存在するのかに関する32ビット・ベース・アドレス
・ResultLocationField 比較の結果がメモリ内で格納される場所に関する32ビット・ベース・アドレス
図16Dに示されているように、第4レジスタ・セットR4は、次のマルチブロック・スキャッタ/ギャザ・セグメント記述レジスタを含む。
・BlockOffsetField 64ビット・アーキテクチャが使用される時のアドレスのバンクを記述する32ビット数
・BlockCountField このMultiBlockスキャンによって表されるスキャン・セグメントの個数を定義する32ビット数(MultiBlockスキャン動作中にBlockCountRegisterを初期化するのに使用される)
・ScatterGatherOpcodeField 関連するScatterGatherBlockFieldによってポイントされるスキャッタ/ギャザ・セグメント記述に使用される32ビット・コマンド・オペコード
・ScatterGatherBlockField 前のScatterGatherOpcodeFieldに関連するスキャッタ/ギャザ・セグメント記述がメモリ内で配置される場所に関する32ビット・アドレス
例示的なTISAレジスタ・セットを、任意の適切な形で変更できることを了解されたい。たとえば、例示的なレジスタ・セットのそれぞれを、より少数の、より多数の、および/または異なるレジスタを含むように変更することができる。たとえば、例示的なレジスタを、より少数の、より多数の、および/または異なるセットに再グループ化することができる。たとえば、より少数の、より多数の、および/または異なるレジスタ・セットを使用することができる。言い換えると、例示的なTISAレジスタ・セットを、TISAプロセッサ・アーキテクチャを実施するためにTISA命令セットと共に使用するのに適する任意の他のTISAレジスタ・セット(1つまたは複数)に置換することができる。
例示的なTISAは、システム・テスティングを実行する際に使用される任意の適切なTISA命令セット(すなわち、コマンド辞書)を使用することができる。
例示的なTISA命令セットは、次のオペコードを含み、これらのオペコードは、図16A〜16Dに関して図示され、説明されたレジスタ・セットR1からRならびに図示され、本明細書で説明されるオリジナルISAレジスタ・セットを操作するのに利用することができる。
StateTransition <TMS Value>,<TCK cycles>
・このオペコードは、所与の個数のTCKクロック・サイクルの間にTMSの値を使用してTAP状態機械をトラバースするのに使用される。このオペコードは、TAP状態機械の状態の間で一般的な状態遷移を実行するのに使用される。<TMS Value>は、単一ビットを表し、<TCK cycles>は、オペコードの残りのデータ・ビットを表す。
RunTest <startState>,<testState>,<endState>
・このオペコードは、<startState>から<testState>に遷移し、ScanLengthRegisterによって指定される個数のTCKサイクルの間に<testState>でループするのに使用される。このオペコードは、ルーピングの結末として<endState>に遷移するのに使用される。
ScanRegister <source register>,<destination register>[,<expected register>][,<mask register>]
・このオペコードは、ユーザ・データ・レジスタ<source register>内のデータをスキャンし、取り込まれた値をユーザ・データ・レジスタ<destination register>に格納するのに使用される。<expected_register>が存在する場合には、存在するならば最終的に<mask_register>を使用して、取り込まれた値をこれと比較し、それに従ってエラーを送出する。スキャンされるビット数は、ScanLengthRegister内で定義される(0<=n<32)。開始状態、スキャン状態、および終了状態は、ScanStateRegister内で定義される。
ScanRegisterZero <destination register>[,<expected register>][,<mask register>]
・このオペコードは、すべて「0」のベクトル値をスキャンし、取り込まれた値をユーザ・データ・レジスタ<destination register>に格納するのに使用される。スキャンされるビット数は、ScanLengthRegister内で定義される(0<=n<32)。開始状態、スキャン状態、および終了状態は、ScanStateRegister内で定義される。<expected_register>および<mask_register>は、ScanRegister命令と同様に使用される。
ScanRegisterOne <destination register>[,<expected register>][,<mask register>]
・このオペコードは、すべて「1」のベクトルをスキャンし、取り込まれた値をユーザ・データ・レジスタ<destination register>に格納するのに使用される。スキャンされるビット数は、ScanLengthRegister内で定義される(0<=n<32)。開始状態、スキャン状態、および終了状態は、ScanStateRegister内で定義される。<expected_register>および<mask_register>は、ScanRegister命令と同様に使用される。
ScanBlock
・このオペコードは、SUTに対してBlockRegisterによってポイントされるデータをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定する。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。TDOからのデータは、保存されない。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。
ScanBlockCapture
・このオペコードは、SUTに対してBlockRegisterによってポイントされるデータをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定する。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。TDOから取り込まれたデータは、保存される。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。
ScanBlockZeroCapture
・このオペコードは、SUTに対してすべて「0」のデータ・ベクトルをスキャンするのに使用され、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、BlockRegisterによって定義されるレジスタに結果を取り込む。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。
ScanBlockZero
・このオペコードは、SUTに対してすべて「0」のデータ・ベクトルをスキャンするのに使用され、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、結果は取り込まれない。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。
ScanBlockOneCapture
・このオペコードは、SUTに対してすべて「1」のデータ・ベクトルをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、BlockRegisterによって定義されるレジスタに結果を取り込む。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。
ScanBlockOne
・このオペコードは、SUTに対してすべて「1」のデータ・ベクトルをスキャンし、<startState>で始めて、<scanState>のデータをスキャンするのに使用され、<endState>は、そのブロックのStateTraversalFieldによって定義される動作状態を最終決定し、結果は取り込まれない。ScanStateRegisterには、スキャン動作の前にStateTraversalFieldからのデータが取り込まれる。ScanLengthRegisterには、スキャン動作の前にScanLengthFieldからのデータが取り込まれる。ExpectedValueFieldおよびMaskfieldがセットされている場合には、それに従って比較およびエラー生成が行われる。
例示的なTISA命令セットは、明示的な値を使用する次のレジスタ変更命令を含む。
LoadRegisterExplicit <const value>,<register name>
・この命令は、<const value>の定数値を、<register name>によって名前を指定されたレジスタにロードする。
CopyRegister <source register>,<destination register>
・この命令は、<source register>として名前を指定されたレジスタの内容を<destination register>によって名前を指定されたレジスタにコピーする。
例示的なTISA命令セットは、暗黙の値を使用する次のレジスタ変更命令含む。
LoadRegisterImplicit <user data register>,<register name>
・この命令は、名前を指定された<user data register>内の値を、実際のデータが存在するメモリ位置へのポインタ参照として使用し、参照された値を<register name>によって名前を指定されたレジスタに格納する。
例示的なTISA命令セットは、次のレジスタ保存命令を含む。
StoreRegisterImplicit <register name>,<user data register>
・この命令は、名前を指定された<user data register>内の値を、<register name>によって名前を指定されたレジスタ内の値が格納されるメモリ位置へのポインタ参照として使用する。
StoreRegisterExplicit <register name>,<const value>
・この命令は、<register name>によって名前を指定されたレジスタの値を、<const value>によって指定されるメモリ位置に格納する。
例示的なTISA命令セットは、次の、レジスタに対する論理演算を含む。
AND <source register>,<destination register>
・この演算は、<source register>と<destination register>との間の論理AND演算を実行し、結果の値を<destination register>に置く。
OR <source register>,<destination register>
・この演算は、<source register>と<destination register>との間の論理OR演算を実行し、結果の値を<destination register>に置く。
XOR <source register>,<destination register>
・この演算は、<source register>と<destination register>との間の論理XOR演算を実行し、結果の値を<destination register>に置く。
NOT <source register>,<destination register>
・この演算は、<source register>に対して論理NOT演算を実行し、結果の値を<destination register>に置く。
XORM <source register>,<mask register>,<destination register>
・この演算は、「1」の値を含むユーザ・データ・レジスタ<mask register>ビットと位置が合っているビットだけを比較しながらユーザ・データ・レジスタ<source register>とユーザ・データ・レジスタ<destination register>との間の論理XOR演算を実行し、結果の値を<destination register>に置く。比較されないビットは、<destination register>内で「0」の値をもたらすことに留意されたい。
例示的なTISA命令セットは、次の、レジスタに対するその他の動作を含む。
NOP
・いくつかのISA命令セットでアライメントを実現するためのフィルタとして使用されるノー・オペレーション・オペコード。
例示的なTISA命令セットは、付属プロセッサ・アーキテクチャを使用する実施形態のためにストリーミングのサポートを拡張する次の命令を含む。
MemoryWrite
・この命令は、引数<sequence number(シーケンス番号)>、<block offset(ブロック・オフセット)(32ビット・オフセット)>、<number of bytes to transfer(転送すべきバイト数)>、<destination address(宛先アドレス)(指定されたメモリ・ブロック内の)>、<data byte(データ・バイト)(1つまたは複数)>を使用して、ローカル・テスト・メモリに書き込む。
MemoryRead
・この命令は、引数<sequence number(シーケンス番号)>、<block offset(ブロック・オフセット)(32ビット・オフセット)>、<number of bytes to transfer(転送すべきバイト数)>、<source address(ソース・アドレス)(指定されたメモリ・ブロック内の)>を使用して、ローカル・テスト・メモリから読み取る。この命令は、シーケンス番号および転送されるバイト数を用いてタグ付けされたデータ・バイトのストリームを返す。
例示的なTISA命令セットは、スキャン状態に関する次の値を含む。
StartState、ScanState、EndState
・スキャン状態コードは、TestLogicReset(TLR)、RunTest/Idle(RTI)、PauseDR(PDR)、PauseIR(PIR)、ScanDR(SDR)、ScanIR(SIR)を含む。これらは、状態コードあたり4ビットの表現であり、12ビットが、スキャン動作に関する状態遷移シーケンス全体を記述するのに使用される。
本明細書の教示によって情報を与えられた当業者は、さまざまな他のTISA実施態様を、図示され本明細書で説明されるTISAプロセッサ・アーキテクチャと共に使用できることを了解するであろう。たとえば、他のTISA実施態様は、より少数の、より多数の、および/または異なるレジスタを使用することができ、より少数の、より多数の、および/または異なる命令セットを使用することができ、類似物を使用することができ、ならびにそのさまざまな組合せを使用することができる。一実施形態では、異なるプロセッサ・アーキテクチャが使用される場合に、特定の応用例によりよく適するTISA実施態様を提供するためおよび/または任意の他の適切な理由のために、他のTISA実施態様を利用することができる。
上で説明したように、JTAGアーキテクチャでのTISAの使用は、スキャン動作をスキャン・セグメント・レベルで実行することを可能にし、これは、スキャン・パス全体の内部での独立に制御可能な「スキャン・セグメント」の定義を可能にし、これによって、問題空間内で直接にスキャン動作を定義し、実施時にスキャン動作を解決するのに使用できるプリミティブの柔軟で強力なセットを提供する。
一般に、JTAG動作は、すべてのビットが1つずつ直列にスキャン・インされると同時に、ビットが1つずつ直列にスキャン・アウトされるスキャン動作に基づく。これは、スキャン動作を実行できるために、スキャン・チェーン内のビットごとにどの値が必要とされるか(すなわち、入力ベクトルおよび出力ベクトル)の知識が要求されることを意味する。TGTは、通常、BSDLなどの記述言語を介して入手されるシステム・モデルから必要なベクトルを計算することによって、伝統的な構造テスティングのためにこの機能を提供する。さらに、SVFおよびSTAPLのようなフォーマットは、これを反映する。というのは、これらが、ユーザがこれらのベクトルを操作することを可能にするからである。この形でのテスティングは、構造的な(および他のタイプの)テスティングには十分であるが、この形でのテスティングは、スキャン・チェーン全体にアクセスする実際の必要がない対話セット・アップには非常に非効率的である。この非効率性は、例を検討することによって理解することができる。
たとえば、それぞれが16ビットを有する100個の機器からなるスキャン・チェーンを検討されたい。ユーザが、スキャン・チェーン内の76番目の機器のレジスタに0x1234を書き込む必要がある場合には、TGTは、スキャン・チェーン全体のベクトル(100*16=1600ビット)を生成し、スキャン・チェーンに入力するためにこれをTAPインターフェースに送る必要がある。同様に、ユーザが、関連する出力を読み取ることを望む場合には、TGTは、所望の出力情報を抽出できるようになる前に、1600ビットのベクトル全体を受け取る必要がある。この例では、スキャン・ビットの大多数が役に立たないという事実は重要ではない。というのは、スキャン効率が、目標の1つではないからである(そうではなく、この例では、目標は、主にスキャン・チェーンの一特定のエンティティに効率的にアクセスできることである)。
このタイプの手法は、少なくとも次の理由から問題である。(a)長いベクトルを扱うという計算的な必要がある(たとえば、大量のメモリ転送は、性能に対する大きい影響を有する)、(b)ベクトル(1つまたは複数)全体をメモリに格納する必要がある(長いチェーンについて問題になる可能性がある)、(c)メモリ・ストレージが、データ入力およびデータ出力に制限されるのではなく、期待されるデータ、入力マスク、出力マスク、および類似物をも含む(これによって、入力データおよび出力データだけから既に潜在的に過大な負担を受けているメモリ要件を増やす)、および(d)機器−ベクトル−機器の変換を、毎回行わなければならない(これは、計算能力および時間を必要とする)。
スキャン・セグメント・レベル抽象化レベルは、スキャン効率に対する特別な強調を全く用いずに(もちろん、必要な場合にそれを使用可能にする場合であっても)テストされるシステムのスキャン・チェーンの個々のエンティティまたはエンティティのグループへの効率的なアクセスを提供する強力なツールである。
一実施形態では、スキャン・セグメント・レベル抽象化は、スキャン・チェーンを一連のセグメントに分解することと、セグメントのそれぞれに対する1つまたは複数のスキャン動作を定義することとによって実施される。スキャン・チェーンは、複数の要素からなり、各セグメントは、スキャン・チェーンの要素のうちの少なくとも1つを含む。要素を、テストされるシステムの多数のレベルで定義することができ(たとえば、要素を、デバイス、機器、レジスタ、レジスタのセグメント、および類似物、ならびにそのさまざまな組合せとすることができる)、したがって、スキャン・チェーンがそれに分解されるセグメントを、テストされるシステムの多数のレベルで定義することができる(たとえば、セグメントを、1つまたは複数のデバイス、デバイス(1つまたは複数)の一部、1つまたは複数の機器、機器(1つまたは複数)の一部、1つまたは複数のレジスタ、レジスタ(1つまたは複数)の一部、1つまたは複数のレジスタ・セグメント、および類似物、ならびにそのさまざまな組合せとすることができる)。この形で、セグメントは、スキャン・チェーンの最小の制御単位を表すことができる。
一実施形態では、セグメントへのスキャン・チェーンの分解を、階層的とすることができる。たとえば、スキャン・チェーンをセグメントに分解することができ、そのセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、そのサブセグメントのうちの少なくともいくつかを、サブセグメントによって構成することができ、以下同様である。この形で、スキャン・チェーンの階層分解を、あるセグメントを他のセグメントから構成できるツリーベースの構造を有するとみなすことができる。1つのそのような実施形態では、ツリーの葉のセグメントを、セグメントと呼ぶことができ(それらがスキャン・チェーンの最小の制御単位を表すという点で)、ツリーの葉の上に位置するセグメントを、スーパーセグメントと呼ぶことができる。一実施形態では、スキャン・チェーンのセグメントのうちの1つまたは複数を、ユーザ/システムに透過的である形でのみ制御可能である仮想サブセグメントから構成することができることを了解されたい)。スキャン・チェーンの階層分解を、任意の他の適切な形で定義することができる。
セグメント化の使用は、セグメントのタイプおよび/またはセグメント組合せのタイプに関するエンティティの定義を可能にする。エンティティは、あるタイプのターゲットの包括的記述であり、この記述は、そのタイプのターゲットの各物理インスタンスについて有効であり、そのタイプのターゲットの物理インスタンスごとに再利用することができる。たとえば、あるエンティティが、デバイス、デバイスのグループ、デバイスの一部、機器、機器のグループ、機器の一部、および類似物、ならびにそのさまざまな組合せを定義することができる。したがって、スキャン・チェーンを、スキャン・チェーンのセグメントが特定の要素または要素の組合せを含むように分解することができるので、エンティティを、スキャン・チェーンのそれぞれのセグメントおよび/またはセグメントのそれぞれの組合せについて定義することができる。たとえば、スキャン・チェーンが、1つのセグメントが1つの機器を含むように分解される場合には、エンティティを、そのタイプのセグメント(すなわち、そのタイプの機器を含む各セグメント)について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。同様に、たとえば、スキャン・チェーンが、1つのセグメントが複数の機器を含むように分解される場合には、エンティティを、そのタイプのセグメント(すなわち、そのタイプ組合せの機器を含む各セグメント)について定義することができ、そのエンティティを、スキャン・チェーン内のそのタイプのセグメントの物理インスタンスごとに再利用できるようになる。これは、下で説明するように、追加の特徴および機能をサポートすることを可能にする。
セグメント化の使用は、エンティティ(すなわち、制御下のあるタイプのセグメントの記述)を、そのエンティティと通信するのに使用される物理プロトコルと相関させることを可能にする。その結果、記述言語(たとえば、NSDL、P1687 IJTAG PDL、および類似物など)を、特にそのエンティティのために記述することができ、接続性記述部分(たとえば、NSDLまたはIJTAG HDLの構造)は、セグメント化命令の順序付けを記述する。
TISAは、TISA命令がモデルベースの動作ではなくセグメントベースの動作なので、特定のエンティティ・タイプのすべてのオカレンスについて1回定義できる再利用可能なモジュラ性を提供する。したがって、TISAは、モジュラと特定のセグメント内のテストされるエンティティについて自律的との両方であるので、TISAは、既存アーキテクチャに対する大きい利益を提供する。
TISAは、既存のツールが必要とするように接続性全体を静的モデルとして前もって定義する必要なしに、必要な任意の順序でスキャン・プロセス内の任意の点で実行フローに組み入れることのできる再利用可能で移植可能なモジュールへのテスト・データ・レジスタ定義の直接マッピングを可能にする。TISAは、統一された制御フローおよび標準的なコンピュータ・サイエンス技法に基づく単一解空間アーキテクチャとして、スキャン動作との非スキャンであるポート/信号インターフェースの統合を可能にする(ネイティブ言語構造が非スキャン動作へのアクセスを提供するのに使用される解決策に対する大きい利益を提供する)。
TISAは、同一エンティティの複数のインスタンスに関する命令シーケンスの再利用を可能にし、これによって、システム内のコード・ストレージ要件の削減を可能にする。たとえば、管理プログラムによって呼び出される記述言語関数にマッピングされる一般化された関数を記述することができる。この例では、関数のそれぞれは、エンティティを表すネイティブ言語オブジェクトのメソッドであり、システム内で定義されたエンティティごとにこれらのオブジェクトの別々のインスタンスがある場合があるが、これらのインスタンスのそれぞれと通信するのに使用されるコードの単一のコピーがあるものとすることができる。この形で、ネイティブ言語実施態様モデルは、回路の接続性および機能性を指定するのに使用される記述言語を直接に制御する。
上で与えた例を参照すると、スキャン・セグメント・レベル抽象化は、機器1から75を含むセグメントS1、機器76を含むセグメントS2、および機器77から100を含むセグメントS3という3つのセグメントの定義を可能にする。この形で、機器76へのアクセスが、大幅に単純化される。たとえば、機器76へのアクセスを、セグメントS3の「ダミー・シフト」を行うこと(たとえば、ScanBlockZero)と、セグメントS2(すなわち、機器76)について命令(1つまたは複数)を実行することと、セグメントS1について別のダミー・シフトを行うことと、その後、更新を伴って終了することとによって得ることができる。そのようなシーケンスでは、セグメントS2(すなわち、スキャン・チェーン内の特定の機器)へのアクセスは、その長さを除いてセグメントS1またはセグメントS3の知識を全く必要とせずに実現される。これが、単に1つの例であり、したがって、100個の機器の長さのチェーンの別の分解が、他の機器または機器グループへのアクセスを可能にするために可能であることを了解されたい。
図17に、テストされるシステムの例示的スキャン・チェーンの例示的分解を示す、テストされるシステムの高水準ブロック図を示す。
例示的なSUT 1700は、4つのデバイス17101〜17104(集合的にデバイス1710、図17ではそれぞれデバイス1、デバイス2、デバイス3、およびデバイス4と表される)を含む。デバイス1710は、スキャン・チェーン1720を形成するためにSUT 1700内で直列に配置される。スキャン・チェーン1720は、次のようになっている。TAPのTDIは、デバイス17104の入力ポートに接続され、デバイス17104の出力ポートは、デバイス17103の入力ポートに接続され、デバイス17103の出力ポートは、デバイス17102の入力ポートに接続され、デバイス17102の出力ポートは、デバイス17101の入力ポートに接続され、デバイス17101の出力ポートは、TAPのTDOに接続される。
例示的なSUT 1700内では、デバイス1710のそれぞれが、(1)テスト命令レジスタ(TIR)およびテスト・データ・レジスタ(TDR)に入力を供給する入力デマルチプレクサ、ならびに(2)TIRおよびTDRから出力を収集する出力マルチプレクサを含む。各デバイス1710のTIRおよびTDRは、並列レジスタである。デバイス17103は、入力デマルチプレクサが入力を1つのTIRおよび2つのTDRに供給し、その1つのTIRおよび2つのTDRから出力を収集するように、1つの追加のTDRを含み、この1つのTIRおよび2つのTDRは、すべてが並列になっている。TIRおよびTDRは、それぞれ、直列シフト・レジスタとして図示され、それぞれが9個の関連する要素(たとえば、フリップフロップ)を含む。この形で、(a)TIRは、36個の直列要素を含む1つのスキャン・チェーン(テスト命令スキャン・チェーンと表される)を形成し、(b)TDRは、合計45個の要素および36個の直列要素(すなわち、デバイス17103の2つのTDRは並列なので)を含むもう1つのスキャン・チェーン(テスト・データ・スキャン・チェーンと表される)を形成する。
例示的なSUT 1700内では、テスト命令スキャン・チェーンが、デバイス17104のTIRの9個の要素を含む第1セグメントSI4、デバイス17103のTIRの9個の要素を含む第2セグメントSI3、デバイス17102のTIRの9個の要素を含む第3セグメントSI2、およびデバイス17101のTIRの9個の要素を含む第4セグメントSI1という4つのセグメントに分解されている。この形で、テスティング・システムは、SUT 1700の他のTIRの最小限の(それらを構成する要素数以外の)知識を用いて、SUT 1700のTIRのいずれにも個別にまたは組み合わせてアクセスすることができる。
例示的なSUT 1700内では、テスト・データ・スキャン・チェーンは、デバイス17104のTDRの9個の要素を含む第1セグメントSD4、デバイス17103のTDRの9個の要素を含む第2セグメントSD3、デバイス17102の第1TDRの9個の要素(サブセグメントSD2.1と表される)またはデバイス17102の第2TDRの9個の要素(サブセグメントSD2.2と表される)のいずれかを含む第3セグメントSD2、これらは、セグメントの総数を数えるために別々のセグメントとしてカウントされる)、ならびに、デバイス17101のTDRの最初の3つの要素を含む第1サブセグメント(サブセグメントSD1.1と表される)、デバイス17101のTDRの次の4つの要素を含む第2サブセグメント(サブセグメントSD1.2と表される)、およびデバイス17101のTDRの最後の2つの要素を含む第3サブセグメント(サブセグメントSD1.3と表される)という3つの直列サブセグメントにさらに分解される第4セグメントという6つの直列セグメント(合計7つのセグメント)に分解されている。この形で、テスティング・システムは、SUT 1700の他のTDRの最小限の(それらを構成する要素数以外の)知識を用いて、SUT 1700のTDRのいずれにも(またはデバイス17101のTDRのサブ部分にさえ)個別にまたは組み合わせてアクセスすることができる。
図17のSUT 1700が、テストされるシステムのスキャン・チェーン(1つまたは複数)をスキャン・セグメント・レベル抽象化を提供する際の使用のために分解できる形の単に1つの例であることを了解されたい。要素、コンポーネント、および類似物の特定のタイプ、個数、および配置に関して図示され、本明細書で説明されるが、そのスキャン・チェーン(1つまたは複数)が分解されるテストされるシステムが、要素、コンポーネント、および類似物のさまざまな他のタイプ、個数、および/または配置を含むことができることを了解されたい。
本明細書で説明するように、テストされるシステムのスキャン・チェーンの分解は、スキャン動作をセグメントに対して定義することを可能にし、これによってテスティング効率を改善する。分解されたスキャン・チェーンのセグメントに関するスキャン動作を含む命令のセットを生成する、一実施形態による方法を、図18に関して図示し、本明細書で説明する。
スキャン分解およびスキャン・セグメント動作の生成のより詳細な説明を、次で提供する。
一般的な例として、各基板がセグメント(それぞれ第1基板、第2基板、および第3基板に関連してセグメントA、B、およびCと表す)を含む3つの基板を含むスキャン・チェーンを検討されたい。この例では、スキャン・セグメントが階層的である場合に、第1基板上のセグメントAを、複数のサブセグメント(たとえば、サブセグメントA1からAn)から構成することができ、第2基板上のセグメントBを、複数のサブセグメント(たとえば、サブセグメントB1からBn)から構成することができ、かつ/または第3基板上のセグメントCを、複数のサブセグメント(たとえば、サブセグメントC1からCn)から構成することができる。
より具体的な例として、アプリケーションおよびSUTに従って、セグメントを、機器の内部の1つまたは複数のレジスタ、機器、レジスタのクラスタ、1つまたは複数の基板、および類似物、ならびにそのさまざまな組合せとすることができる。
したがって、全体的なスキャン動作は、一連のセグメント・スキャン動作に分解される。その結果、最終的なスキャン・チェーン動作を得るために必要なものは、一連の単純な原子的動作だけである。したがって、スキャン・セグメント・レベル抽象化の実施形態は、これに排他的に限定はされないが、原子的テスト動作がプロセッサ動作のように扱われる実施態様で(たとえば、図示され本明細書で説明されるさまざまなTISA実施態様または原子的テスト動作がプロセッサ動作のように扱われる任意の他の類似する実施態様で)特に有効である。
スキャン・セグメント・レベル抽象化のそのような実施形態では、スキャン・セグメント・レベル・スキャン動作の実際の実施態様が、JTAGにリンクされた1つまたは複数の技術的制約に対処することを必要とする場合がある。たとえば、とりわけTAPマシンの状態を定義する必要およびPause−DR状態(必ず実施されるわけではない)を使用することの危険性などの制約に対処する必要がある場合がある。
スキャン・チェーン内の機器/セグメントの位置に基づいてスキャン・チェーンを介して受け取られる出力ビットストリーム内の機器/セグメント出力を識別するために、スキャン・インされる最初のセグメントが、スキャン・アウトされる最初のセグメントにもなるように(スキャン・チェーンの終りに最も近いので)、スキャン・チェーンを、先入れ先出し(FIFO)システムとして扱うことができる(その直列の性質を考慮して)。
SUTにスキャン・セグメント動作のシーケンスを単一スキャン動作のように「経験」させるために、TCKを、セグメント動作の間に凍結することができる。スキャン・チェーンの内部のすべての要素が同期式なので、この形でのTCKの凍結の効果は、スキャン・チェーンがTCKと一緒に凍結されることである。
TISAベースのテスティング・システムでのスキャン・セグメント・レベルの使用は、少数の例によってよりよく理解することができる。次の例では、テストされるシステム(SUT)が、3つのセグメント(その順番でA、B、およびCと表される)からなり、ユーザが、セグメントBの内部に値Vを書き込む必要があると仮定する。
第1の例として、システムの3つのセグメント(A、B、およびC)が、同一のJTAGデバイスの内部で実施されると仮定する。この第1の例では、3つのセグメントがメモリ内で定義された後に、TISA動作は、
i. Startstate=Run−Test−Idle、Scanstate=Endstate=ShiftDRをセットする
ii. ScanLenghtFieldにセグメントAの長さをセットする
iii. セグメントAにバイパス・シーケンスをスキャンする
iv. Startstate=Scanstate=Endstate=ShiftDRをセットする
v. ScanLenghtFieldにセグメントBの長さをセットする
vi. セグメントBにVをスキャンする
vii. Startstate=Scanstate=ShiftDR、Endstate=Run−Test−Idleをセットする
viii.ScanLenghtFieldにセグメントCの長さをセットする
ix. セグメントCにバイパス・シーケンスをスキャンする
になる。
第1の例に関して、TAP有限状態機械(FSM)をShiftDR状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。これは、第1の例から見ることができ、第1の例では、ShiftDrから出た後にのみUpdateDR状態に達することを考慮すると、ステップ(i)からステップ(ix)までTAP FSMをShiftDR状態に保つことによって、スキャン・チェーンに対する更新がないことが保証される。
さらに第1の例に関して、スキャン・クロックTCKは、スキャン動作中(すなわち、ステップ(iii)、(vi)、および(ix))のみアクティブであり、残りの状態では凍結される。その効果は、SUTが、TCKと同期する動作に基づくSUTの観点から、ステップ(iii)、(vi)、および(ix)を連続ビット・ストリームとみなすことである。
さらに第1の例に関して、「バイパス・シーケンス」は、スキャン・セグメントのプロパティであり、たとえば、所与のシーケンス(すべて0、すべて1、または任意の他の適切なシーケンス)または「ドントケア」とすることができ、そのようなシーケンスを判断することは、TGTに委ねられる。
第2の例として、システムの3つのセグメント(A、B、およびC)が、異なるJTAGデバイス(1つまたは複数のカード内)上で実施されると仮定する。この第2の例では、3つのセグメントがメモリ内で定義された後に、TISA動作は、
i. セグメントAの状態をセットする、すなわち、StartState=RunTest/Idle、ScanState=ShiftIR、EndState=ShiftIR(gateTCKインジケータ)
ii. セグメントAのScanLengthFieldにセグメントAのIRの長さをセットする
iii. セグメントAのBYPASS命令パターンを用いてScanBlockを走行させる
iv. セグメントBの状態をセットする、すなわち、StartState=ShiftIR、ScanState=ShiftIR、EndState=ShiftIR(gateTCKインジケータ)
v. セグメントBのScanLengthFieldにセグメントBのIRの長さをセットする
vi. セグメントBのEXTEST命令パターンを用いてScanBlockを走行させる
vii. セグメントCの状態をセットする、すなわち、StartState=ShiftIR、ScanState=ShiftIR、EndState=RunTest/Idle
viii. セグメントCのScanLengthFieldにセグメントCのIRの長さをセットする
ix. セグメントCのBYPASS命令パターンを用いてScanBlockを走行させる
x. セグメントAの状態をセットする、すなわち、StartState=RunTest/Idle、ScanState=ShiftDR、EndState=ShiftDR(gateTCK)
xi. セグメントAのScanLengthFieldにセグメントAの選択されたDRの長さをセットする(1ビットBYPASS DR)
xii. セグメントAのBYPASSデータ・パターンを用いてScanBlockを走行させる
xiii. セグメントBの状態をセットする、すなわち、StartState=ShiftDR、ScanState=ShiftDR、EndState=ShiftDR(gateTCK)
xiv. セグメントBのScanLengthFieldにセグメントBの選択されたDRの長さをセットする(ピンへのnビットBSR DR)
xv. セグメントBのEXTESTデータ・パターンを用いてScanBlockを走行させる
xvi. セグメントCの状態をセットする、すなわち、StartState=ShiftDR、ScanState=ShiftDR、EndState=RunTest/Idle
xvii. セグメントCのScanLengthFieldにセグメントCの選択されたDRの長さをセットする(1ビットBYPASS DR)
xviii.セグメントCのBYPASSデータ・パターンを用いてScanBlockを走行させる
になる。
第1の例と第2の例との比較において、第2の例に関連する追加の複雑さが、セグメントを選択/選択解除するために各JTAGデバイスの命令レジスタ(IR)を使用する必要に由来することを理解されたい。その場合に、未使用セグメントは、関連するJTAGデバイスを1149.1標準規格のBYPASSモードにすることによって(第2の例のステップ(iii)および(xvii)に示されているように)直接にチェーンから外される。
1つまたは複数のJTAGデバイス上で定義される任意の個数のセグメントを伴う、上の2つの例のすべての合成が可能であることを了解されたい。さらに、上の2つの例が、単にテストされるシステムをテストするためのスキャン・セグメント・レベルの使用を示すために提供される例であり、したがって、スキャン・セグメント・レベルがテストされるシステムのテスティングに使用される実施形態がこれらの例によって限定されることは意図されていないことを了解されたい。
そのような実施形態では、TISA命令の実際のシーケンスは、次のうちの1つまたは複数を含む複数の出所を有することができる。(1)TISA命令を、TGTによって静的に計算することができ、この場合には、ユーザがセグメントにアクセスすることを望むたびに、チェーン全体をスキャンしなければならない(この解決策は、スキャン時間に関しては最適化されないが、限られた計算リソースを有し、時間制約がほとんどまたは全くない組込みシステムに有用である可能性があることを了解されたい)、(2)TISA命令を、アクセス要求を受け取り、これらをスキャン動作に合成するソフトウェア・スケジューラによって発行することができ、かつ/または(3)TISA命令を、ハードウェア・スケジューラによって発行することができる(たとえば、いくつかの高性能プロセッサ内で命令リオーダリングおよびバイパスに関して行われるものなどであるが、これらに限定はされない)。スキャン・セグメント・レベル制御に関連するTISA命令を、任意の他の適切な形で発行することができ、これらの形が、上で説明した方法および/または上で説明した方法のうちの1つもしくは複数の代わりにもしくはそれに加えて使用できる1つもしくは複数の他の適切な方法の組合せを含むことができることを了解されたい。
スキャン・セグメント・レベル抽象化レベルは、IEEE P1687標準規格によって提案されるものおよび他の動的トポロジなどの動的トポロジを処理する強力なツールである。スキャン・チェーンのあるセクションが、アクティブ・スキャン・パスに取り込まれ、外される(たとえば、IEEE P1687標準規格によって提案されるSIBセルまたは任意の他の適切な階層を使用可能にするコンポーネント(1つまたは複数)を使用して)場合には、そのセクションを、1つ(または複数)のセグメントとしてマークすることができる。次に、テスティング・スケジューラは、システム状態から、このセグメント(1つまたは複数)がアクティブであるか否かに関する知識を有し、したがって、このセグメントをTISA命令スケジューリングに含めなければならないかどうかに関する知識を有する。本明細書の教示によって情報を与えられた当業者は、この原理を、ホットスワップ基板(たとえば、状況レジスタからその存在を検出することによって)または任意の他の適切な動的要素など、他の動的要素にも使用できることを了解するであろう。
図18に、スキャン・チェーンのスキャン・セグメント・レベル抽象化を使用する、テストされるシステムのスキャン・チェーンを介してテストされるシステムの一部をテストする方法の一実施形態の高水準ブロック図を示す。
主に直列に実行されるものとして図示され、本明細書で説明されるが、方法1800のステップの少なくとも一部を、同時にまたは図18に関して図示され説明されるものとは異なる順序で実行することができる。
ステップ1802で、方法1800が開始される。
ステップ1804では、スキャン・チェーンを複数のセグメントに分解する。スキャン・チェーンは、複数の要素に分解され、各セグメントは、スキャン・チェーンの要素のうちの少なくとも1つを含む。上で説明したように、スキャン・チェーンを任意の適切な形で分解することができる。本明細書で説明するように、セグメントへのスキャン・チェーンの分解を、開発フロー内のどこにでも適用することができる(たとえば、テスト開発者によって、テスト生成ツールによって、組込み回路モデルによって、および類似物)。
ステップ1806では、命令のセットを生成する。命令のセットは、ISAに関連するプロセッサ命令と、テストされるシステムの一部分をテストするテスト命令とを含む。テスト命令は、スキャン・チェーンのセグメントごとに、そのセグメントに対して実行すべき少なくとも1つのスキャン動作を含む。テスト命令は、従来のテスト命令、TISAのテスト命令、および類似物など、任意のタイプのテスト命令とすることができ、したがって、任意の適切な形で生成することができる。命令のセットを、任意の適切な形で生成することができる(たとえば、に関して図示し、上で説明したものと同一のまたはこれに類似する形で
ステップ1808では、テストされるシステムの一部分をテストするために命令のセットを実行する。命令のセットは、任意の適切な形で実行することができ、この形は、命令のセットの命令のタイプに依存する場合がある。
ステップ1810で、方法1800は終了する。
主にTISAの実施形態がスキャン動作をスキャン・セグメント・レベルで実行することを可能にするのに使用される実施形態に関して図示され、本明細書で説明されるが、図示され本明細書で説明されるスキャン・セグメント・レベル実施形態のうちの1つまたは複数を、TISA様命令アーキテクチャを使用する環境、非TISA命令アーキテクチャ、および/または非TISAテスティング環境実施態様、ならびに類似物で提供することもできることを了解されたい。
図示され本明細書で説明されるように形成し、利用することのできるTISAの例示的実施形態によって使用可能にされる機能強化されたシステム・テスティング機能を説明するために本明細書で「the TISA」に言及するが、TISAがそれのために形成されるプロセッサのISA、TISAがそれのために形成されるSUTの特性、TISAが実行すると思われるテスト・アルゴリズムの特性、および類似物のうちの1つまたは複数、ならびにそのさまざまな組合せなどのさまざまな要因に依存して、多数の異なるTISAを形成できることを了解されたい。したがって、本明細書での「the TISA」への言及は、多数の異なるタイプのTISAを形成できるという点で、より一般的に「a TISA」と解釈することもできる。
仮想インサーキット・エミュレーション(ICE)機能は、本明細書ではJoint Test Action Group(JTAG)ハードウェアのテスティングをサポートするために提供される。一実施形態では、仮想インサーキット・エミュレーション(ICE)機能は、仮想ICEドライバを含み、そのさまざまな実施形態を、本明細書で図示し、説明する。仮想ICEドライバは、任意の標準的なデバッグ・ソフトウェアが柔軟でスケーラブルな形でJTAG対応ハードウェアとインターフェースすることを可能にするように構成される。仮想ICEドライバは、仮想ICEドライバと共に使用されるテスト命令セットがベクトルを計算することを要求されないように構成される。というのは、JTAG動作が、スキャン・セグメントに対するローカル・ネイティブ命令として表され、これによって、ICEリソースに直接にアクセスすることを可能にするからである。仮想ICEドライバは、ICEを機器ベースのJTAG手法(たとえば、IEEE P1687標準規格および他の適切な手法など)と組み合わせられるように構成される。仮想ICEドライバは、本明細書で提供される仮想ICEドライバの説明から理解されるさまざまな他の機能および利益を提供する。本明細書では主に仮想ICEドライバがテスト命令セット・アーキテクチャ(TISA)と共に利用される実施形態の文脈で図示され、説明されるが、仮想ICEドライバを任意の適切なテスト命令セットと共に利用できることを了解されたい。
TISAでは、レジスタの並列制御を、高水準ソフトウェア呼出しを使用し、高水準プログラミング言語およびオペレーティング・システムを活用して実行することができる。その結果、TISAを用いると、ICEインターフェーシングを、ターゲット・ハードウェアのスキャン・トポロジに従うTISAスキャン・セグメント動作の発行を管理するTISAベースの回路制御モデルへの調整された待ち行列に入れられたコマンド呼出しのセットに縮小することができる。したがって、TISAを用いると、ICEインターフェースのそれぞれを、TISAオペコードにマッピングされるデバイス・レジスタに対する動作の独立だが階層的なセットとして記述することができる。言い替えると、ICEインターフェースのそれぞれを、自律的な機器レジスタとみなすことができ、TISAによってサポートされるJTAG抽象化レベルの起因して、TISAは、これらのレジスタを独立のスキャン・セグメントして表すことによって、これらのレジスタのそれぞれを自律的に制御することができる。これは、ベクトルを扱うためにTGTによって使用される回路モデルよりはるかに単純である。というのは、TISAプロセッサが、スキャン・セグメント動作だけをスケジューリングする必要がある(既存解決策で要求されるようにテスティング・ベクトルを再ターゲティングするのではなく)からである。
仮想ICEドライバの上記およびさまざまな他の実施形態ならびに関連する仮想ICEドライバ機能を、図19および20を参照することによってよりよく理解することができる。
図19に、ターゲット・ハードウェアのテスティングで使用されるように構成された仮想ICEドライバを含むシステムの一実施形態の高水準ブロック図を示す。
図19に示されているように、システム1900は、ターゲット・ハードウェア1910、TAPインターフェース1915、仮想ICEドライバ1920、およびICEホスト1930を含む。
ターゲット・ハードウェア1910は、複数のJTAGアクセス可能デバイス19111〜19116(集合的に、JTAGアクセス可能デバイス1911)を含む。JTAGアクセス可能デバイス1911は、第1中央処理ユニット(CPU1)、第2中央処理ユニット(CPU2)、および4つの装着された特定用途向け集積回路(ASIC)(装着されたASIC 1〜4)を含む。特定のタイプおよび個数のJTAGアクセス可能デバイス1911を有するものとして図示され、説明されるが、ターゲット・ハードウェア1910が、任意の適切なタイプおよび個数のJTAGアクセス可能デバイス1911を含むことができることを了解されたい。
CPUを、任意のJTAGアクセス可能CPUとすることができる。たとえば、CPU1およびCPU2の一方または両方を、1149.1 ICEターゲットとすることができる。たとえば、CPU1およびCPU2の一方または両方を、独立にアクセスされる必要がある複数のプロセッサ・コアを有する1149.7 ICEターゲットとすることができる。CPUは、任意の他の適切なタイプのCPUを含むことができる。
装備されたASICを、任意のJTAGアクセス可能ASICとすることができる。たとえば、装備されたASIC 1〜4のうちの1つまたは複数を、P1687 ICEターゲットとすることができる。図1の例では、装備されたASIC 1〜4のそれぞれが、P1687 ICEターゲットである。
ターゲット・ハードウェア1910は、それに関連するスキャン・チェーン・トポロジを有し、JTAGアクセス可能デバイス1911のそれぞれが、そのスキャン・チェーン・トポロジの一部を形成する。
ターゲット・ハードウェア1910のJTAGアクセス可能デバイス1911は、TAPインターフェース1915を介して指令され、TAPインターフェース1915は、仮想ICEドライバ1920に接続される。
TAPインターフェース1915は、ターゲット・ハードウェア1910と仮想ICEドライバ1920との間のインターフェースを提供し、これによって、仮想ICEドライバ1920が、ターゲット・ハードウェア1910のJTAGアクセス可能デバイスにアクセスすることを可能にする。TAPインターフェース1915を、1149.1 TAPまたは他の適切なTAPなど、任意の適切なTAPを使用して実施することができる。
仮想ICEドライバ1920は、待ち行列付き状態機械(Queued State Machine)1921およびTISAプロセッサ1925を含む。仮想ICEドライバ1920は、ICEホスト1930によるターゲット・ハードウェア1910へのアクセスを容易にする。
ICEホスト1930は、ターゲット・ハードウェア1910のテスティングを可能にするように構成される。
ICEホスト1930は、ターゲット・ハードウェア1910のCPU1に関連する第1ターゲットICEコントローラ19311、ターゲット・ハードウェア1910のCPU2に関連する第2ターゲットICEコントローラ19312、およびターゲット・ハードウェア1910の装備されたASIC 1〜4に関連する第3ターゲットICEコントローラ19313を含む複数のターゲットICEコントローラ1931を含む。ICEホスト1930は、より少数またはより多数のそのようなターゲットICEコントローラを含むことができる。ICEホスト1930は、ICEホスト1930のターゲットICEコントローラ1931のそれぞれと仮想ICEドライバ1920との間の通信を容易にするように構成されたホスト・メッセージングAPI 1935をも含む。
第1ターゲットICEコントローラ19311は、CPU1用のGBU GUI 19321およびターゲットICEマネージャ19331を含む。CPU1用のGBU GUI 19321は、それを介してテスタがターゲット・ハードウェア1910上のCPU1をテストするために実行されるテストを構成すできるインターフェースを提供する。ターゲットICEマネージャ19331は、CPU1内に含まれるレジスタを記述する回路モデルを含む情報、CPU1のさまざまなレジスタがCPU1内で配置される形、およびCPU1がターゲット・ハードウェア1910のスキャン・チェーン内の唯一のデバイスである場合にCPU1のレジスタへのアクセスを可能にする情報を有する。ターゲットICEマネージャ19331は、CPU1のスキャン・セグメントへのCPU1のレジスタのマッピングを定義する情報をも有する。GBU GUI 19321を使用して、CPU1のレジスタに対して実行される動作を指定することができる。ターゲットICEマネージャ19331は、ターゲット・ハードウェア1910上のCPU1にアクセスし、これをテストするための適当なスキャン・セグメント動作を生成する。ターゲットICEマネージャ19331は、ターゲット・ハードウェア1910上のCPU1にアクセスし、これをテストするための生成されたスキャン・セグメント動作をホスト・メッセージングAPI 1935に供給し、ホスト・メッセージングAPI 1935は、生成されたスキャン・セグメント動作を仮想ICEドライバ1920に通信する。
第2ターゲットICEコントローラ19312は、CPU2用のGBU GUI 19322およびターゲットICEマネージャ19332を含む。CPU2用のGBU GUI 19322は、それを介してテスタがターゲット・ハードウェア1910上のCPU2をテストするために実行されるテストを構成できるインターフェースを提供する。ターゲットICEマネージャ19332は、CPU2内に含まれるレジスタを記述する回路モデルを含む情報、CPU2のさまざまなレジスタがCPU2内で配置される形、およびCPU2がターゲット・ハードウェア1910のスキャン・チェーン内の唯一のデバイスである場合にCPU2のレジスタへのアクセスを可能にする情報を有する。ターゲットICEマネージャ19331は、CPU2のスキャン・セグメントへのCPU2のレジスタのマッピングを定義する情報をも有する。GBU GUI 19322を使用して、CPU2のレジスタに対して実行される動作を指定することができる。ターゲットICEマネージャ19332は、ターゲット・ハードウェア1910上のCPU2にアクセスするための適当なスキャン・セグメント動作を生成する。ターゲットICEマネージャ19332は、ターゲット・ハードウェア1910上のCPU2にアクセスするための生成されたスキャン・セグメント動作をホスト・メッセージングAPI 1935に供給し、ホスト・メッセージングAPI 1935は、生成されたスキャン・セグメント動作を仮想ICEドライバ1920に通信する。
上で説明したように、GDB GUI 1932は、それを介してテスタがターゲット・ハードウェア1910上のデバイスをテストするために実行されるテストを構成できるインターフェースを提供する。一般に、ICEの目的について、デバッガ(CPU1用のGBU GUI 19321およびCPU2用のGBU GUI 19322などのGDBデバッガを含む)は、本質的に、ターゲット・マシンを、3つの基本要素すなわちレジスタのバック、メモリのブロック、およびスタック・フレームを含む抽象化モデルとみなす。ターゲット・マシンのターゲット・マシン記述を使用して、ICEインフラストラクチャを介して抽象化モデルをターゲット・マシンの実際のハードウェアにマッピングすることができる。ターゲット・ハードウェア1910などのJTAGアクセス可能システムでは、実際のハードウェアは、1つまたは複数のスキャン・チェーン上のJTAGアクセス可能レジスタとして表される。GDBでは、アプリケーション・プログラミング・インターフェース(API)を、(1)インデクシングされたレジスタを読み取る/書き込む関数のセット、(2)メモリを読み取る/書き込む関数のセット、(3)プログラム・カウンタ・レジスタを読み取る/書き込む関数のセット、および(4)スタック・ポインタ・レジスタを読み取る/書き込む関数のセットからなるものとすることができる。GDBでは、これらの関数が、GDB GUI(たとえば、CPU1用のGBU GUI 19321およびCPU2用のGBU GUI 19322)を介して開始されたGDBアクセス要求をターゲットICEに関する(たとえば、ターゲット・ハードウェア1910のCPU1およびCPU2のレジスタに関する)アクセス・コマンドに変換する。これらのアクセス・コマンドは、スキャン・セグメント動作であり、スキャン・セグメント動作は、ターゲット・ハードウェア1910の組込みコンポーネントのレジスタに基づいて定義されるスキャン・セグメント上で指定される。この意味で、各スキャン・セグメントは、テストに使用可能なターゲット・ハードウェア1910のレジスタの全体的に順序付けられたセットのサブセットになる。
本明細書では主にターゲット・ハードウェア1910のJTAGアクセス可能デバイス1911をテストするためのGDBの使用に関して図示され、説明されるが、任意の適切なデバッガを、ターゲット・ハードウェア1910のJTAGアクセス可能デバイス1911をテストするのに利用できることを了解されたい。
第3ターゲットICEコントローラ19313は、装備されたASIC 1〜4のP1687アプリケーション19543を含む。装備されたASIC 1〜4のP1687アプリケーション19343は、それを介してテスタがターゲット・ハードウェア1910上の装備されたASIC 1〜4のうちの1つまたは複数をテストするために実行されるテストを構成できるインターフェースを提供する。装備されたASIC 1〜4のP1687アプリケーション19343は、GDBの機能に似た機能を提供する。装備されたASIC 1〜4のP1687アプリケーション19343は、ターゲット・ハードウェア1910上の装備されたASIC 1〜4にアクセスするための適当なスキャン・セグメント動作を生成する。装備されたASIC 1〜4のP1687アプリケーション19543は、ターゲット・ハードウェア1910上の装備されたASIC 1〜4にアクセスするための生成されたスキャン・セグメント動作をホスト・メッセージングAPI 1935に供給し、ホスト・メッセージングAPI 1935は、生成されたスキャン・セグメント動作を仮想ICEドライバ1920に通信する。
本明細書で示すように、各ターゲットICEコントローラ1931は、スキャン・セグメント動作の順序付けられたセットすなわち、関連するターゲット・ハードウェア1910の内部の1つまたは複数のセグメントへの定義された順序付けられた命令のセットを生成するように構成される。
ホスト・メッセージングAPI 1935は、ICEホスト1930のターゲットICEコントローラ1931のそれぞれと仮想ICEドライバ1920との間の通信を容易にする。
ホスト・メッセージングAPI 1935は、ターゲットICEコントローラ1931によって生成されたスキャン・セグメント動作の順序付けられたセットの、ICEホスト1930のターゲットICEコントローラ1931から仮想ICEドライバ1920への通信を容易にする。
ホスト・メッセージングAPI 1935は、ICEホスト1930のターゲットICEコントローラ1931と仮想ICEドライバ1920との間の通信を容易にするために任意の適切な通信機能を使用することができる。たとえば、ホスト・メッセージングAPI 1935は、物理接続(たとえば、PCI、シリアル、および類似物)、ネットワーク化された接続(たとえば、イーサネットベースの接続、インターネット・プロトコル(IP)ベースの接続、および類似物)、ソフトウェア・アプリケーション(たとえば、パイプ、ファイル、メッセージ、プロセス間通信、および類似物)、および類似物、ならびにそのさまざまな組合せなどの通信機能を利用することができる。
本明細書では主にターゲットICEコントローラ1931が単一のICEホスト(すなわち、ICEホスト1930)に存在する実施形態に関して図示され、説明されるが、他の実施形態では、ICEホスト1930のターゲットICEコントローラ1931が、複数のICEホスト上に存在することができる。ターゲットICEコントローラ1931を、任意の適切な形で複数のホストにまたがって分散させることができる(たとえば、各ターゲットICEコントローラ1931が、それ自体の専用ホスト上で実施され、ターゲットICEコントローラ1931のうちの少なくともいくつかが、1つまたは複数のホストを共有し、および類似物、ならびにそのさまざまな組合せ)。そのような実施形態では、ホスト・メッセージングAPI 1935は、分散されたターゲットICEコントローラ1931の通信を容易にするように構成される(たとえば、物理接続を介して、IP接続および/または任意の他の適切なネットワーク化された接続などのネットワーク化された接続を介して、および類似物、ならびにそのさまざまな組合せ)。
一実施形態では、仮想ICEドライバ1920は、待ち行列付き状態機械1921およびTISAプロセッサ1925を含む。
待ち行列付き状態機械1921は、ICEホスト1930とTISAプロセッサ1925との間のインターフェースとして動作する。待ち行列付き状態機械1921は、ICEホスト1930のターゲットICEコントローラ1931からスキャン・セグメント動作の順序付けられたセットを受け取る。待ち行列付き状態機械1921は、スキャン・セグメント動作のスケジューリングされたセットを作るためにスキャン・セグメント動作の順序付けられたセットを処理し、スキャン・セグメント動作のスケジューリングされたセットは、ターゲット・ハードウェア1910の内部の各スキャン・セグメントの位置を考慮に入れることによって実行され得る。待ち行列付き状態機械1921は、ターゲット・ハードウェア1910のJTAGスキャン・チェーンに必要なおよび/または効率的なスケジュールを使用してスキャン・セグメント動作をスケジューリングするように構成される。待ち行列付き状態機械1921は、スキャン・セグメント動作のスケジューリングされたセットをTISAプロセッサ1925に供給する。
待ち行列付き状態機械1921を、任意の適切な形で実施することができる。
一実施形態では、たとえば、待ち行列付き状態機械1921は、イベント・ループ1922、コマンド・ハンドラ1923、および回路制御モデル1924を含む。
イベント・ループ1922は、ICEホスト1930のホスト・メッセージングAPI 1935からスキャン・セグメント動作の順序付けられたセットを受け取る。スキャン・セグメント動作は、ICEホスト1930のターゲットICEコントローラ1931のうちの1つまたは複数によって発行されるスキャン・セグメント動作を含む。イベント・ループ1922は、スキャン・セグメント動作の順序付けられたセットをコマンド・ハンドラ1923に供給する。
コマンド・ハンドラ1923は、イベント・ループ1922からスキャン・セグメント動作の順序付けられたセットを受け取る。コマンド・ハンドラ1923は、スキャン・セグメント動作の順序付けられたセットを回路制御モデル1924に供給する。
回路制御モデル1924は、コマンド・ハンドラ1923からスキャン・セグメント動作の順序付けられたセットを受け取り、TISAプロセッサ1925に供給されるスキャン・セグメント動作のスケジューリングされたセットを生成する。
回路制御モデル1924は、ターゲットICEコントローラ1931のそれぞれの回路モデルのそれぞれの回路モデル情報を含み、ターゲットICEコントローラ1931のそれぞれによって発行されるスキャン・セグメント動作のハンドリングを可能にするための集合体としてこの情報を管理する。
回路制御モデル1924は、JTAG対応デバイス1911のそれぞれのスキャン・トポロジ、それを介してJTAG対応デバイス1911が相互接続されるスキャン・トポロジ、および類似物、ならびにそのさまざまな組合せなどの情報を含む、ターゲット・ハードウェア1910のスキャン・トポロジをモデル化するためのスキャン・トポロジ情報を含む。各所与の瞬間に、回路制御モデル1924の状態は、ターゲット・ハードウェア1910の状態の鏡像になる。
回路制御モデル1924は、スキャン・セグメント・セットと称する場合もあるスキャン・セグメント・モデルの順序付けられたコレクションを含み、スキャン・セグメント・セットのそれぞれ自体は、他のスキャン・セグメントのサブセットとすることができ、スキャン・セグメント・サブセットのそれぞれは、その順序付けに関してそれ自体を管理することができる。TISAのオブジェクト指向機能は、スキャン・セグメント・セットがそのそれぞれのスキャン・セグメント動作を実行する時の順序付けの、スキャン・セグメント・セットへの委譲を可能にし、さらに、関連するコードが変更されないままである間にスキャン・セグメント・セットが階層全体の中のどこにでも移動することを可能にする。
回路制御モデル1924は、スキャン・トポロジ情報から決定されるターゲット・ハードウェア1910のスキャン・トポロジに基づいて、スキャン・セグメント動作の順序付けられたセットからスキャン・セグメント動作をスケジューリングする。回路制御モデル1924は、受け取られたスキャン・セグメント動作のそれぞれを処理する。回路制御モデル1924は、スキャン・セグメント動作を受け取る時に、スキャン・セグメント動作の所期の宛先(たとえば、ターゲット・ハードウェア1910のJTAGアクセス可能デバイス1911のうちの1つ)を認識するためにスキャン・セグメント動作を処理する。回路制御モデル1924は、スキャン・セグメント動作を、回路制御モデル1924のうちでそのスキャン・セグメント動作の所期の宛先に関連する部分、たとえば、スキャン・セグメント動作に関する適当な関数(1つまたは複数)への呼出し(1つまたは複数)を作成するように構成されたスキャン・セグメント・セットに委譲し、呼び出される関数(1つまたは複数)は、スキャン・セグメント動作を実行するための関連するTISAプロセッサ命令を有する。
回路制御モデル1924は、スキャン・セグメント動作のスケジューリングされたセットをTISAプロセッサ1925に供給する。
回路制御モデル1924が、スキャン・セグメント動作のスケジューリングを実行するのに必要な情報だけを必要とするので、回路制御モデル1924を、ベクトル再ターゲティングに使用されるモデルより大幅に単純にすることができることを了解されたい。
TISAプロセッサ1925は、TAPインターフェース1915を介してターゲット・ハードウェア1910のJTAGアクセス可能デバイス1911を制御するように構成される。TISAプロセッサ1925は、TISAプロセッサ1925によってサポートされるTISA命令を使用して、ターゲット・ハードウェア1910のJTAGアクセス可能デバイスを制御するように構成される。TISAプロセッサ1925は、待ち行列付き状態機械1921からスキャン・セグメント動作のスケジューリングされたセットを受け取り、ターゲット・ハードウェア1910の関連するJTAGアクセス可能デバイス1911のソフトウェアをデバッグするために、ターゲット・ハードウェア1910のTAPインターフェース1915およびスキャン・トポロジを介してスキャン・セグメント動作のスケジューリングされたセットを実行する。TISAプロセッサ1925の展望から、ターゲット・ハードウェア1910は、ターゲット・ハードウェア1910の実際の複雑さに関わりなく、単純にスキャン・セグメントのセットである。TISAプロセッサ1925は、図1〜18を参照することによってよりよく理解することができる。
仮想ICEドライバ1920を、例を考慮することによってよりよく理解することができる。たとえば、ターゲット・ハードウェア1910のCPU2に関連するCPU2用のGBU GUI 19322が、CPU2内のプログラム・カウンタの値の更新を要求するコマンドを発行すると仮定する。ターゲットICEマネージャ19332は、そのコマンドをイベント・ループ1922に渡す。イベント・ループ1922は、メッセージをコマンド・ハンドラ1923に渡す。コマンド・ハンドラ1923は、コマンドを回路制御モデル1924に渡し、回路制御モデル1924は、そのコマンドがCPU2宛であることを認識し、その結果、回路制御モデル1924およびターゲット・ハードウェア1910の現在の状態でCPU2にアクセスするのに必要なTISA命令を生成する。必要な場合には、コマンド・ハンドラ1923は、回路制御モデル1924をCPU2がアクセス可能な状態にするのに必要な命令をも生成する。その後、回路制御モデル1924は、CPU2内の特定のレジスタに書き込めるようになるために、CPU2に関連する回路モデル1924のスキャン・セグメント・セットにコマンドを委譲する。CPU2に適当なベクトルを適用するように構成されたスキャン・セグメント・セットは、CPU2のプログラム・カウンタ・レジスタに書き込むために呼び出される適当なレジスタ関数への呼出しを作成する。CPU2のプログラム・カウンタ・レジスタに書き込むために呼び出されるレジスタ関数は、CPU2のプログラム・カウンタ・レジスタに特定のデータを書き込むためにスキャン・セグメント・コマンドの特定のデータを適用する適当なTISAプロセッサ命令を有する。したがって、データが経時的に変化することができると同時に、データがレジスタに書き込まれる形を制御する関数は、経時的に同一のままになる。
仮想ICEドライバ1920は、TISAを利用することによって、ターゲット・ハードウェア1910のJTAGアクセス可能デバイス1911のそれぞれを独立の自律的なスキャン・セグメントとして扱うことができる。これは、少なくとも部分的に、1149.1 TAPのTCKクロックを命令セット内の任意の所望の点で一時停止することを可能にし、これによって、1149.1 TAPがスキャン動作を一時停止するために安定した状態に切り替わる必要をなくす、TISAの機能に起因する(すなわち、通常、1149.1 TAPインターフェースは、4つの安定した状態のうちの1つでのみTCKをゲーティングする(すなわち、クロックをオフに切り替える))。これは、Scan Segmentプリミティブの特性に関連して、回路制御モデル1924が、単純に、これ自体の内部状態に基づいてコマンド・ハンドラ1923から受け取るTISA命令をスケジューリングしなければならないこと、および回路制御モデル1924がそのTISA命令を変更する必要がないことを保証する。これは、既存のICE手法のベクトル再ターゲティングと比較して、重大な単純化である。
仮想ICEドライバ1920は、TISAを利用することによって、ターゲット・ハードウェア1910の組込みコンポーネント上で実行されるスキャン・セグメント動作を同期化することによってターゲット・ハードウェア1910の組込みコンポーネントの間の同期化を提供することができる。したがって、仮想ICEドライバ1920は、TISAを利用することによって、単に、スキャン・セグメント動作を順序付け、実行する必要がある(ターゲットICEコントローラがスキャン・チェーン・ベクトルを再ターゲティングする必要がある既存のICE手法とは異なって)、すなわち、仮想ICEドライバ1920は、テスト生成ツール(TGT)の使用を必要とするスキャン・チェーン・ベクトルの生成および再ターゲティングを必要とするのではなく、ソフトウェア関数を直接に再ターゲティングする。
仮想ICEドライバ1920は、ターゲット・ハードウェア1910の複数のJTAGアクセス可能デバイス1911への並列アクセスおよびその並列テスティングを可能にし、JTAGアクセス可能デバイス1911は、異なるタイプのデバイス(たとえば、CPU、ASIC、および類似物、ならびにそのさまざまな組合せ)を含むことができ、そのようなデバイスがお互いから分離して処理されるという既存ICE機構の要件を除去し、したがって、既存ICE機構を超えるさまざまな最適化を可能にする(たとえば、ターゲット・ハードウェア1910のリソースの共有、ターゲット・ハードウェア1910のコンポーネントへのアクセスおよびそのテスティングの並列化、および類似物、ならびにそのさまざまな組合せ)。
仮想ICEドライバ1920は、複数のターゲットICEコントローラ1931によるターゲット・ハードウェア1910の複数のJTAGアクセス可能デバイス1911への並列アクセスおよびその並列テスティングを可能にし、任意の所与の時に単一のターゲットICEコントローラ1931だけがターゲット・ハードウェア1910の単一のJTAGアクセス可能デバイス1911だけにアクセスでき、これをテストできるという既存ICE機構の要件を除去し、したがって、スキャン・チェーン・ベクトルの再ターゲティングの必要をなくす。
仮想ICEドライバ1920は、ターゲット・ハードウェア1910のすべてのターゲット・デバイスに関するスキャン・チェーン・ベクトル・セット全体を入手するために(すべてのターゲット・デバイスが同一のスキャン・チェーン上にある場合)、ターゲットICEコントローラ1931によるテスティング・データの前処理(たとえば、ターゲットICEコントローラ1931からのすべてのディレクティブに関する)の必要をなくし、これは、既存のICE手法を用いて提供することがむずかしいか不可能でさえある機能である。既存のICE手法のこの制限が、理論的理由から生じるのではなく、実用的理由から生じることを了解されたい。実際に、そのような応用例のベクトル再ターゲティングは、計算要件とモデリングの必要との両方に関して、非常に複雑になる可能性がある。その結果、ほとんどの既存のテスト生成ツールは、そのような状況を許容しないか、システムに事前に定義され単純化された構成を強制する。対照的に、TISAは、このプロセスをスケジューリング問題に縮小し、このスケジューリング問題は、多数の既知の最適化された解決策を有する古典的な周知の情報理論問題である。
その結果、仮想ICEドライバ1920は、ターゲットICEコントローラ1931が、ターゲット・ハードウェア1910のさまざまなコンポーネントをテストするコマンドを発行するので、そのような処理をリアル・タイムで実行することを可能にする。
仮想ICEドライバ1920は、柔軟でスケーラブルなICE機能を提供し、任意の1149.1対応ターゲット・ハードウェアおよび/または1149.7対応ターゲット・ハードウェアを、基礎になるアーキテクチャを変更する必要なしに制御ソフトウェアに接続することを可能にし、さらに、制御ソフトウェアが必要なだけ大きくなり、ICEホスト1930のリソースのすべてを活用することを可能にする。
仮想ICEドライバ1920は、ターゲット・ハードウェア1910上でホスティングされるGDBまたはP1687アプリケーションの変更を全く必要とせずに、ターゲット・ハードウェア1910のICEベースのテスティングを可能にする。
仮想ICEドライバ1920を、したがって図19のシステムを、要素/機能/関数の任意の適切なグループ化および/または区分を含むことができる任意の適切な形で実施することができる。
一実施形態では、たとえば、仮想ICEドライバ1920は、ICEホスト1930とターゲット・ハードウェア1910との間に配置された独立型の1つまたは複数のデバイスとして実施される。
一実施形態では、たとえば、待ち行列付き状態機械1921およびICEホスト1930は、任意の適切なインターフェース/接続(たとえば、PCI、シリアル、イーサネット、および類似物)を介してTISAプロセッサ1925に接続され得るホスト・マシン内で実施される。この実施形態では、TISAプロセッサ1925は、標準JTAG接続を介してターゲット・ハードウェア1910に接続される。この実施形態では、ホスト・メッセージングAPI 1935を、任意の適切なコンピュータ・サイエンス構造(1つまたは複数)(たとえば、メッセージ・キュー、メールボックス、および類似物、ならびにそのさまざまな組合せ)を使用して実施することができる。
一実施形態では、たとえば、仮想ICEドライバ1920が完全にターゲット・ハードウェア1910内に組み込まれるように、仮想ICEドライバ1920を実施することができる。
一実施形態では、たとえば、ICEホスト1930を、TISAプロセッサとすることができる。この実施形態では、TISAプロセッサ1925は、図13および14に関して本明細書で図示し、説明したように、TISAコプロセッサとして実施される。
そのような実施形態のさまざまな組合せを実施でき、かつ/または任意の他の適切な実施態様を使用できることを了解されたい。
本明細書では主に、ICEホスト1930が複数のターゲットICEコントローラ1931を含み、複数のターゲットICEコントローラ1931がターゲット・ハードウェア1910に並列にアクセスできる実施形態に関して図示され、説明されるが、他の実施形態では、ICEホスト1930は、複数のターゲットICEコントローラ1931のうちの1つだけが任意の所与の時にアクティブである、複数のターゲットICEコントローラ1931を含むことができ、あるいは、ICEホスト1930は、1つのターゲットICEコントローラ1931だけを含むことができる。そのような実施形態では、仮想ICEドライバ1920は、待ち行列付き状態機械1921の使用を必要とせず、したがって、この要素を仮想ICEドライバ1920から省略することができる。そのような実施形態では、仮想ICEドライバ1920は、TISAプロセッサ1925を含み、アクティブの/唯一のターゲットICEコントローラ1931によって供給されるスキャン・セグメント動作は、TISAプロセッサ1925に直接に(すなわち、待ち行列付き状態機械1921を使用せずに)供給され得る。
主に、仮想ICEドライバ1920が単一のTAPインターフェース1915を介してターゲット・ハードウェア1910とインターフェースする実施形態に関して図示され、説明されるが、他の実施形態では、ターゲット・ハードウェア1910は、それに接続された複数のターゲットICEコントローラ1931を有することができる複数の入力ポート(たとえば、1149.1 TAP)を含むことができる。そのような実施形態では、仮想ICEドライバ1920は、ターゲット・ハードウェア1910の複数のTAPインターフェースのそれぞれを介して受け取られたスキャン・ベクトルの、ターゲット・ハードウェア1910の適当なJTAGアクセス可能デバイス1911へのルーティングを管理するように構成される。そのような実施形態では、ターゲットICEコントローラ1931は、実際にはTISAプロセッサのスキャン・セグメント呼出しとしてデータ・ベクトルをターゲット・ハードウェア1910内の適当な点に再マッピングしているTISAプロセッサと通信している時に、それ自体のスキャン・チェーン内のそれ自体のデバイスと通信していると考える。したがって、そのような実施形態では、ターゲット・ハードウェア1910の変更がある場合に、対応する変更は、ターゲットICEコントローラ1931内では要求されず、ターゲット・ハードウェア1910の変更をサポートするために必要な唯一のステップは、TISAプロセッサの回路モデルを再ロードすることになるはずである。
本明細書では主に仮想ICEドライバ1920がターゲット・ハードウェアのソフトウェアをデバッグするのに使用される実施形態に関して図示され、説明されるが、他の実施形態では、仮想ICEドライバ1920を使用して、1149.1 TAPインターフェースをその中に組み込まれた通信デバイス(たとえば、コンピュータ、スマートホン、および類似物)へのリモート更新を実行することができる。
図20に、ターゲット・ハードウェアをテストするのに仮想ICEドライバを使用する方法の一実施形態を示す。図20の方法2000は、図19の仮想ICEドライバに関連して考慮する時によりよく理解することができる。
ステップ2002で、方法2000が開始される。
ステップ2004では、スキャン・セグメント動作を受け取る。スキャン・セグメント動作は、少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成される。ターゲットICEコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する。
ステップ2006では、スキャン・セグメント動作のスケジューリングされたセットを形成するために、スキャン・セグメント動作をスケジューリングする。スキャン・セグメント動作は、ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいてスケジューリングされる。
ステップ2008では、スキャン・セグメント動作のスケジューリングされたセットを、ターゲット・ハードウェアの1つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向けて伝搬させる。
ステップ2010で、方法2000は終了する。
図21に、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。図21に示されているように、コンピュータ2100は、プロセッサ要素2102(たとえば、中央処理装置(CPU)または他の適切なプロセッサ(1つまたは複数))、メモリ2104(たとえば、ランダム・アクセス・メモリ(RAM)、読取り専用メモリ(ROM)、および/または任意の他の適切なタイプのメモリ)、図示され本明細書で説明されるシステム・テスティング機能を実行するように適合されたシステム・テスティング・モジュール/プロセス2105、およびさまざまな入出力デバイス2106(たとえば、ユーザ入力デバイス(キーボード、キーパッド、マウス、および類似物など)、ユーザ出力デバイス(ディスプレイ、スピーカ、および類似物など)、入力ポート、出力ポート、受信器、送信器、およびストレージ・デバイス(たとえば、テープ・ドライブ、フロッピ・ドライブ、ハード・ディスク・ドライブ、コンパクト・ディスク・ドライブ、および類似物))を含む。
図示され本明細書で説明されるシステム・テスティング機能を、ソフトウェアならびに/あるいはソフトウェアおよびハードウェアの組合せで、たとえば、汎用コンピュータ、1つまたは複数の特定用途向け集積回路(ASIC)、および/または任意の他のハードウェア同等物を使用して、実施できることに留意されたい。一実施形態では、システム・テスティング・プロセス2105を、メモリ2104にロードし、プロセッサ2102によって実行して、上で説明したシステム・テスティング機能の少なくとも一部を実施し、かつ/またはその実施態様をサポートすることができる。したがって、システム・テスティング・プロセス2105(関連するデータ構造を含む)を、コンピュータ可読記憶媒体または担体、たとえば、RAMメモリ、磁気ドライブ、磁気ディスケット、光ドライブ、光ディスケット、および類似物に格納することができる。
本明細書でソフトウェア方法として論じたステップのうちのいくつかを、ハードウェア内で、たとえばさまざまな方法ステップを実行するためにプロセッサと協力する回路網として実施できることが企図されている。本明細書で説明された機能/要素の諸部分を、コンピュータ・プログラム製品として実施することができ、ここで、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および/または技法が呼び出されるか他の形で提供されるように、コンピュータの動作を適合させる。本発明的方法を呼び出す命令を、固定媒体または取外し可能媒体に格納し、放送媒体または他の信号担持媒体内のデータ・ストリームを介して伝送し、かつ/または命令に従って動作するコンピューティング・デバイス内のメモリ内に格納することができる。
さまざまな実施形態の態様は、特許請求の範囲で指定される。さまざまな実施形態の上記および他の態様は、次の番号付きの句で指定される。
1.インサーキット・エミュレーション(ICE)を使用してターゲット・ハードウェアの1つまたは複数のコンポーネントをテストする際に使用される方法であって、
少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、複数のターゲットICEコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、
ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、
ターゲット・ハードウェアの1つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させるステップと、
を含む方法。
2.受け取られたスキャン・セグメント動作のうちの少なくとも1つについて、受け取られたスキャン・セグメント動作は、少なくとも1つのICEホストのターゲットICEコントローラによって生成され、ターゲット・ハードウェア上のプロセッサ・コアのためのものである、句1に記載の方法。
3.少なくとも1つのICEホストのターゲットICEコントローラは、デバッガに関連する、句2に記載の方法。
4.受け取られたスキャン・セグメント動作のうちの少なくとも1つについて、受け取られたスキャン・セグメント動作は、少なくとも1つのICEホストのアプリケーションによって生成され、ターゲット・ハードウェア上の特定用途向け集積回路(ASIC)の少なくとも1つのプロセッサ・コアのためのものである、句1に記載の方法。
5.アプリケーションは、P1687アプリケーションであり、特定用途向け集積回路は、P1687標準規格に準拠する、句4に記載の方法。
6.スキャン・セグメント動作は、物理接続およびネットワーク化された接続のうちの少なくとも1つを介して受け取られる、句1に記載の方法。
7.スキャン・セグメント動作は、複数のターゲットICEコントローラの通信をサポートするホスト・メッセージングAPIから受け取られる、句1に記載の方法。
8.方法は、待ち行列付き状態機械によって実行される、句1に記載の方法。
9.待ち行列付き状態機械は、
イベント・ループ、コマンド・ハンドラ、および回路制御モデル
を含み、イベント・ループは、ターゲットICEコントローラによって生成されたスキャン・セグメント動作を受け取り、スキャン・セグメント動作をコマンド・ハンドラに提供するように構成され、
コマンド・ハンドラは、イベント・ループからスキャン・セグメント動作を受け取り、スキャン・セグメント動作を回路モデルに提供するように構成され、
回路制御モデルは、スキャン・セグメント動作のスケジューリングされたセットを作るように構成される
句8に記載の方法。
10.スキャン・セグメント動作のスケジューリングされたセットは、回路制御モデルを使用して作られる、句1に記載の方法。
11.回路制御モデルは、
ターゲットICEコントローラに関連する複数の回路モデルの回路モデル情報
を含む、句10に記載の方法。
12.回路制御モデルは、
ターゲット・ハードウェアのスキャン・トポロジをモデル化するスキャン・トポロジ情報であって、回路制御モデルは、スキャン・トポロジ情報を使用してスキャン・セグメント動作のスケジューリングされたセットを作る、スキャン・トポロジ情報
を含む、句10に記載の方法。
13.受け取られたスキャン・セグメント動作のそれぞれについて、回路制御モデルは、
スキャン・セグメント動作の所期の宛先であってターゲット・ハードウェアのコンポーネントのうちの1つである所期の宛先を認識するために、スキャン・セグメント動作を処理し、
回路制御モデルのうちでスキャン・セグメント動作の所期の宛先に関連する部分にスキャン・セグメント動作を委譲する
句10に記載の方法。
14.回路制御モデルのうちでスキャン制御動作の所期の宛先に関連する部分は、スキャン・セグメント動作に関する少なくとも1つの関数への少なくとも1つの呼出しを作成するように構成されたスキャン・セグメント・セットを含み、少なくとも1つの関数は、スキャン・セグメント動作を実行するように構成されたプロセッサ命令を含む、句13に記載の方法。
15.プロセッサは、ターゲット・ハードウェア内に組み込まれる、句1に記載の方法。
16.方法は、仮想ICEドライバによって実行され、仮想ICEドライバは、ターゲット・ハードウェア内に組み込まれる、句15に記載の方法。
17.複数のターゲットICEコントローラは、単一のICEホストに関連し、プロセッサは、第1プロセッサであり、単一のICEホストは、第2プロセッサを含み、第2プロセッサは、中央処理装置(CPU)として動作し、第1プロセッサは、第2プロセッサのスキャン・セグメント動作のスケジューリングされたセットを処理するためのコプロセッサとして動作する、句1に記載の方法。
18.第1プロセッサおよび第2プロセッサは、TISAプロセッサである、句17に記載の方法。
19.ターゲット・ハードウェアの1つまたは複数のコンポーネントをテストする際に使用される装置であって、
少なくとも1つのICEホストの複数のターゲットICEマネージャによって生成されたスキャン・セグメント動作を受け取ることであって、複数のターゲットICEマネージャは、ターゲット・ハードウェアの複数のコンポーネントに関連する、受け取ることと、
ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングすることと、
ターゲット・ハードウェアの1つまたは複数のデバイスをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させることと
を行うように構成された待ち行列付き状態機械
を含む装置。
20.プロセッサによって実行された時に、プロセッサに、インサーキット・エミュレーション(ICE)を使用してターゲット・ハードウェアの1つまたは複数のコンポーネントをテストする際に使用される方法を実行させる命令を格納したコンピュータ可読記憶媒体であって、方法は、
少なくとも1つのICEホストの複数のターゲットICEコントローラによって生成された複数のスキャン・セグメント動作を受け取るステップであって、複数のターゲットICEコントローラは、ターゲット・ハードウェアの複数のコンポーネントに関連する、ステップと、
ターゲット・ハードウェアのスキャン・チェーンに少なくとも部分的に基づいて、受け取られたスキャン・セグメント動作をスケジューリングするステップであって、これによってスキャン・セグメント動作のスケジューリングされたセットを形成するステップと、
ターゲット・ハードウェアの1つまたは複数のコンポーネントをテストするためにスキャン・セグメント動作のスケジューリングされたセットを実行するように構成されたプロセッサに向かってスキャン・セグメント動作のスケジューリングされたセットを伝搬させるステップと、
を含む、コンピュータ可読記憶媒体。
本発明の教示を組み込まれたさまざまな実施形態を図示し、本明細書で詳細に説明したが、当業者は、これらの教示を組み込まれた、多数の他の変更された実施形態をたやすく考案することができる。