JP5548966B2 - テスト、検証及びデバッグアーキテクチャの装置及びシステム - Google Patents

Description

本発明は、コンピュータシステムに関し、特に、コンピュータシステムに対するテスト及びデバッグの基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を提供することに関する。

半導体プロセス及びロジック設計の技術の発展に伴い、より多くの数のロジックを集積回路（ＩＣ）デバイスに組み込むことができるようになってきた。その結果、コンピュータシステムは、システム内に１つの集積回路を含む構成から、複数の集積回路を含む構成へと発展し、複数のコア、複数のハードウェアスレッド及び複数の論理プロセッサが、個々の集積回路に存在し、このようなプロセッサ内にその他のインターフェースも集積されるようになっている。典型的なプロセッサ又は集積回路は、１つの物理的プロセッサダイを含み、プロセッサダイは、いかなる数のコア、ハードウェアスレッド、論理プロセッサ、インターフェース、メモリ、制御ハブ等を含んでもよい。プロセッサ及びコンピュータシステムの両方が複雑になるに従い、これらシステムのテスト及びデバッグも複雑になってきている。

高速・大容量のロジック及び小型化の傾向又はプロセッサの小型化が進むにしたがい、スケジュール通りにコストの掛からない態様で、製品をデバッグ、検証及び発売することが難しくなってきている。現在、テスト及びデバッグの世界は、製造側と消費者／ベンダー側とに二分されており、製造側は、供給するシリコンデバイスに注力し、ベンダー側は、シリコンデバイスと共に集積されるその他のパーツに注力している。シリコンデバイスを悪意を持った損傷及び事故による損傷から守るために、製造側は、ハードウェアのデバッグフックをいかなるレベルにおいてもベンダーに対して公開していないが、これは、このようなアクセスを提供するのに安全な方法が存在しないからである。コンピュータシステムのテストの複雑性が増すにつれ、発見される問題が、製造デバイスに直接関係のないものであっても、製造側は、検証に多額のお金と努力を費やしている。さらに、システム内の異なるデバイス毎（プロセッサ、制御ハブ、グラフィックスデバイス、マザーボード等）に、固有のテスト及びデバッグが行われている場合がある。このように、デバイス毎に異なるテスト／デバッグが行われていることにより、製品の検証に混乱と遅れが生じているまた、従来のプローブを使用するテスト方法は、新型の集積回路の物理的なサイズ制限により、難しくなっている。

さらに、製造側かベンダー側かに関わらず、外部のロジック分析器及びオシロスコープのような検証行う道具は、非常に高価であり、また、訓練された従業員であっても道具を接続し、検証を行うべく正しく使用するのにも時間が掛かる。さらに、これら検証を行うための外部の道具は、相互接続において交換されるプロトコルを把握することができるだけであり、デバイスの相互接続及び状態を完全に解明するのは難しかった。

現在のコンピュータシステムは、多大なお金及び時間を掛けずに、特定の条件下における異なるシステムイベントを検証する方法を提供していない。具体的な例としては、デバイス内部の信号、軌跡又は状態の追跡、ブートプロセスの初期段階における信号の追跡、インバンドメッセージとして統合されているハングイベントのような特定のイベントの判断、新しい高速内部メモリ及び入出力（Ｉ／Ｏ）トラフィック及び／又はプロトコルの把握等が挙げられる。基本的に、現在のところ、様々な方向（プロセッサテスト検証、プラットフォームデバッグ、電気的な境界、マザーボードの診断等）にわたって検証を行う統合された効果的な方法が存在しない。

本発明は、以下に示す例によって説明され、添付の図面によって限定されることを意図していない。

マルチ処理要素プロセッサの論理的表現の一実施形態示した図である。 マルチ処理要素プロセッサの論理的表現の別の実施形態示した図である。 階層構造を有するテストアーキテクチャの論理的表現の一実施形態を示した図である。 ＤＦｘ機能の実施形態の一例を有する複数のプロセッサを含むコンピュータシステムの一実施形態を示した図である。 階層化された相互接続積層構造を利用した双方向接続アーキテクチャのブロック図の一実施形態を示した図である。 信号情報における初期の電力を収集する構成のブロック図の一実施形態を示した図である。 電子システムのブートの間の初期信号を取得する取得ロジックの高レベルブロック図の一実施形態を示した図である。 電力シーケンスの初期における信号情報の取得方法を示したフローチャートの一実施形態を示した図である。 低電力状態の対象の信号取得のためのロジックの一実施形態を示した図である。 １以上のＶＣＵを有するプラットフォームの例の一実施形態を示した図である。 ＶＣＵを使用したソフトウェアからのＤＦｘ要求に応じる方法を示したフローチャートの一実施形態を示した図である。 変化を反映させるべくテストアーキテクチャを更新する一実施形態を示した図である。 テストアーキテクチャの階層化された積層構造の一実施形態を示した図である。 階層化されたアーキテクチャの積層構造を介してＤＦｘ機能にアクセスする方法を示したフローチャートの一実施形態を示した図である。 テストアーキテクチャへの安全なアクセスを提供するロジックの一実施形態を示した図である。 テストアーキテクチャにおける安全なアクセスを提供するフローチャートの一実施形態を示した図である。 プラットフォームにおけるテストアーキテクチャのためのユニバーサルテストアクセスポート（ＵＴＡＰ）の一実施形態を示した図である。 大量生産の接続メカニズムの一例における集積回路パッケージの一実施形態を示した図である。 上面テストピン及びプロービングをサポートする目立たない搭載機能を有するヒートスプレッダの一実施形態を示した図である。 熱的マージンを提供するよう設計されたスモールファクター熱的ツール（ＳＦＦＴＴ）設計の分解図の一実施形態を示した図である。 被試験ユニットへのリモートアクセスの一実施形態示した図である。 被試験ユニットへのリモートアクセスの別の実施形態を示した図である。 サイドバンドバスを介して内部で観察されるとレース情報を提供するロジックの一実施形態を示した図である。 内部観察トレース（ＩＯＴ）データを管理する方法を示すフローチャートの一実施形態を示した図である。 ＩＯＴデータからトレースを再構築するフローチャートの一実施形態を示した図である。 後処理の相違を検出する方法のフローチャートの一実施形態を示した図である。 ＲＴＬデータ構造を高レベルの言語にアクセス可能とするフローチャートの一実施形態を示した図である。 テスト及びシステムイベントを送電網性能と相関付ける機能を含む、オンダイイベントに関する送電網の空間的及び時間的特性及びデバッグを可能とする基盤の一実施形態を示した図である。

特定のプロセッサ構成、制御部、特定の種類の検証／テスト／デバッグのフック、構成要素の位置、セキュリティプロトコル、抽出方法、情報のフォーマット及び配置、物理的なアクセスポート設定及び位置、電源設定等の特定の種類が記載されるが、これらは、本発明の完全な理解を提供するためのものである。しかしながら、これらの特定の詳細事項を採用しなくとも、本発明を実行可能であることは、当業者にとって明らかである。また、特定の又は代替のプロセッサアーキテクチャ、機能及びアルゴリズムを記載するための特定の論理回路／コード、特定の検証制御実装詳細、その他の周知の設計検証フック、周知のセキュリティ及びアクセス方法、及びその他の特定の動作の詳細等の、よく知られている要素又は方法については、本発明を不明瞭にすることを防ぐため、記載を省略する。

本明細書に記載する方法及び装置は、コンピュータシステムのテスト基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を提供する。より詳細には、プロセッサ１００のようなプロセッサを含む典型的なコンピュータシステム内の検証に重点を置いて説明する。しかしながら、本明細書に記載される装置及び方法は、これに限定されず、これに替わるコンピュータアーキテクチャ、及び、テスト、デバッグ、検証等が行われる電子デバイスに関連して装置及び方法が実装される。例えば、本明細書に記載されるテスト基盤は、通信デバイス又はその他の集積回路環境に実装されてもよい。あるいは、テスト基盤は、ＰＤＡ及び携帯電話のような小型デバイスに組み込まれて使用されてもよい。

［プロセッサアーキテクチャの実施形態］
図１には、複数のコアを含むプロセッサの一実施形態が示されている。プロセッサ１００は、マイクロプロセッサ、埋め込みプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサのようなあらゆるプロセッサ、又は、コードを実行するその他のデバイスを含む。一実施形態において、プロセッサ１００は、少なくとも２つのコア、コア１０１及びコア１０２を含み、これらコアは、非対称コア又は対称コア（図示の例）を含む。しかしながら、プロセッサ１００は、対称又は非対称である処理要素を幾つ含んでもよい。

一実施形態において、処理要素とは、スレッド単位、スレッドスロット、処理単位、コンテキスト、論理プロセッサ、ハードウェアスレッド、コア、及び／若しくは実行状態又はアーキテクチャ状態のようなプロセッサの状態を保持可能な他の要素のことを指す。すなわち、ある実施形態では、処理要素とは、ソフトウェアスレッドのようなコード、ＯＳ、アプリケーション又はその他のコードに独立して関連付けることが可能なあらゆるハードウェア指す。物理的プロセッサとは、典型的には、コア又はハードウェアスレッド等の他の処理要素を１以上含む集積回路（ＩＣ）のことを指す。

コアとは、多くの場合、独立して保持されるアーキテクチャの状態がそれぞれ、少なくとも幾つかの専用実行リソースと関連付けられる独立アーキテクチャ状態を保持可能なＩＣに位置するロジックを指す。コアに対して、ハードウェアスレッドとは、典型的には、独立して保持されている複数のアーキテクチャ状態が実行リソースへのアクセスを共有する独立アーキテクチャ状態を保持可能なＩＣに位置するロジックを指す。このように、あるリソースは共有され、他のリソースは１つのアーキテクチャ状態に占有されている場合には、ハードウェアスレッド及びコアという命名の境界線が重複することとなる。しかしながら、やはりコアとハードウェアとは、ＯＳから見れば個別の論理プロセッサであり、ＯＳは、各論理プロセッサに対して独立してオペレーションをスケジュールすることができる。

図１に示すように、プロセッサ１００は、２つのコア１０１及び１０２を含む。ここで、コア１０１及び１０２は、対称なコアである、すなわち、同じ構成、機能単位及び／又はロジックを有するコアである。別の実施形態では、コア１０１は、アウト・オブ・オーダー・プロセッサコアを含み、コア１０２は、イン・オーダー・プロセッサコアを含む。しかしながら、コア１０１及び１０２は、ネイティブコア、ソフトウェア管理コア、ネイティブ命令セットアーキテクチャ（ＩＳＡ）を実行するコア、変換された命令セットアーキテクチャ（ＩＳＡ）を実行するコア、共同設計されたコア、又は、その他のコアといったあらゆる種類のコアから別々に選択されてもよい。コア１０１内に図示されている機能単位については、以下に詳細に説明されるが、コア１０２内の機能単位も同様な態様で動作する。

図に示すように、コア１０１は、２つのハードウェアスレッド１０１ａ及び１０１ｂを含み、これらは、ハードウェアスレッドスロット１０１ａ及び１０１ｂとも称される。したがって、ＯＳのようなソフトウェア実体は、一実施形態においては、プロセッサ１００を４つの別個のプロセッサとして見なすこともでき、すなわち、４つのソフトウェアスレッドを並列に実行可能な４つのプロセッサ又は処理要素として見なすことができる。第１のスレッドは、複数のアーキテクチャ状態レジスタ１０１ａと関連付けられており、第２のスレッドは、複数のアーキテクチャ状態レジスタ１０１ｂと関連付けられており、第３のスレッドは、複数のアーキテクチャ状態レジスタ１０２ａと関連付けられており、第４のスレッドは、複数のアーキテクチャ状態レジスタ１０２ｂと関連付けられている。図に示すように、複数のアーキテクチャ状態レジスタ１０１ａは、複数のアーキテクチャ状態１０１ｂに複製されており、個々のアーキテクチャ状態／コンテキストは、論理プロセッサ１０１ａ及び論理プロセッサ１０１ｂに格納可能である。コア１０１では、命令ポインタのようなその他の小さなリソース及びリネーム割り当てロジック１３０におけるリネームロジックも、スレッド１０１ａ及び１０１ｂについて複製されていてもよい。リオーダ／リタイアメントユニット１３５におけるリオーダバッファ、ＩＬＴＢ１２０、読み込み／格納バッファのようなリソース及びキューは、パーティショニングを通じて共有されてもよい。汎用内部レジスタ、ページ−テーブルベースレジスタ、低階層データキャ主及びデータ−ＴＬＢ１１５、実行ユニット１４０、及びアウト・オブ・オーダーユニット１３５の部分は、完全に共有されてもよい。

プロセッサ１００は、完全に共有される、パーティショニングを通じて共有される、又は、処理要素に専用となるその他のリソースをしばしば含む。図１には、単純に例示することだけを目的としたプロセッサの論理単位／リソースを有するプロセッサの一実施形態が示されている。プロセッサは、これら機能単位の何れを含む又は省略してもよく、図示されていないその他の周知の機能単位、ロジック又はファームウェアを含んでもよい。図に示されるように、コア１０１は、単純化して表示されているアウト・オブ・オーダー（ＯＯＯ）プロセッサコアを含む。ＯＯＯコアは、実行される／選択される分岐先を予測する分岐先バッファ１２０（Ｂｒａｎｃｈ Ｔａｒｇｅｔ Ｂｕｆｆｅｒ：ＢＴＢ）及び命令についてのアドレス変換エントリを記憶する命令変換バッファ１２０（Ｉ‐ＴＬＢ）を含む。

コア１０１は更に、フェッチされた要素をデコードするべく、フェッチユニット１２０と連結されたデコードモジュール１２５を含む。一実施形態において、フェッチロジックは、それぞれスロット１０１ａ、１０１ｂと関連付けられたシーケンサを含む。通常、コア１０１は、プロセッサ１００で実行可能な命令を規定／特定する第１命令セットアーキテクチャ（ＩＳＡ）と関連付けられている。ＩＳＡによって認識される機械コード命令は、一般的に、実行すべき命令又はオペレーションを参照する／特定するオペコード（ｏｐｃｏｄｅ）と呼ばれる命令の一部を含む。デコードロジック１２５は、オペコードから命令を認識し、第１ＩＳＡによって規定されるように処理を行うために、デコードされた命令をパイプラインに渡す。例えば、以下で詳細に説明するように、一実施形態において、デコーダ１２５は、条件コミット命令及び予測チェックポイント命令のような新しい特定の命令を認識するのに使用される又は設計されたロジックを含む。その結果、デコーダ１２５の認識により、アーキテクチャ又はコア１０１は、特定の予め定められたアクションを起こし、適切な命令と関連付けられたタスクを実行する。

一例において、アロケータ及びリネーマブロック１３０は、命令処理結果を格納するレジスタファイルのようなリソースを保存するアロケータ（割り当てルーチン）を含む。しかしながら、スレッド１０１ａ及び１０１ｂは、アウト・オブ・オーダーで実行可能であり、アロケータ及びリネーマブロック１３０は、命令の結果を追跡するためにリオーダ（並び替え）バッファのような、その他のリソースも備える。ユニット１３０は、プログラム／命令参照レジスタを、プロセッサ１００の他の内部レジスタにリネームするレジスタリネーマーを含んでもよい。リオーダ／リタイアメントユニット１３５は、アウト・オブ・オーダー実行及びアウト・オブ・オーダーで実行される順番が最後の方の命令のリタイアメントをサポートするために、上述のようなリオーダバッファ、読み込み（ｌｏａｄ）バッファ、及び格納（ｓｔｏｒｅ）バッファのような要素を含んでもよい。

ある実施形態では、スケジューラ及び実行ユニットブロック１４０は、実行ユニットに対して命令／オペレーションをスケジューリングするスケジューラユニットを含んでもよい。例えば、浮動小数点命令は、利用可能な浮動小数点実行ユニットを持つ実行ユニットの一部にスケジュールされる。また、情報命令処理結果を記憶するために、実行ユニットに関連付けられたレジスタファイルが含まれている。実行ユニットの例としては、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、記憶実行ユニット、及びその他の既知の実行ユニットが挙げられる。

下位層データキャッシュ及びデータ変換バッファ（Ｄ−ＴＬＢ）１５０は、実行ユニット１４０に接続されている。データキャッシュは、メモリコヒーレンシ状態で保持されているデータオペランドのような最近利用／処理されたものを、要素に記憶する。Ｄ−ＴＬＢは、最近の仮想／線形アドレスから物理アドレスへの変換を記憶する。具体的な一例として、プロセッサは、物理メモリを複数の仮想ページに分割するためのページテーブル構造を持つとしてよい。

ここで、コア１０１及びコア１０２は、最近フェッチされた要素をキャッシュする上位層に位置する又はより離れたところに位置するキャッシュ１１０へのアクセスを共有する。ここで、上位層又はより離れた位置とは、キャッシュレベルがより高い又は実行ユニットからより離れていることを指す。一実施形態では、上位層キャッシュ１１０は、プロセッサ１００のメモリ階層の最後のキャッシュであるラストレベルデータキャッシュであり、例えば、第２レベル（２次）データキャッシュ、又は第３レベル（３次）データキャッシュである。上位層キャッシュ１１０はこれに限定されず、命令キャッシュに関連付けられてもよいし、命令キャッシュを含んでもよい。命令キャッシュの一種であるトレースキャッシュを、替わりに、デコーダ１２５の後に連結して、最近デコードされたトレースを記憶してもよい。

図示されている構成では、プロセッサ１００は、システムメモリ１７５、チップセット、ノースブリッジ又はその他の集積回路のような、プロセッサ１００の外部のデバイスと通信を行うバスインターフェースモジュール１０５を含む。メモリ１７５は、プロセッサ１００に専用のメモリであってもよいし、システム内のその他のデバイスと共有されるメモリであってもよい。メモリ１７５の典型的な例には、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、不揮発性メモリ（ＮＶメモリ）、及びその他の周知の記憶デバイスが含まれる。

図１は簡略化して示されており、異なる複数のモジュール、ユニット及び／又はロジックの表現を含むプロセッサの例の論理的表現が示されている。しかしながら、本明細書に説明される方法及び装置を利用するプロセッサは、図示されているユニットを必ずしも含む必要はない。プロセッサは、図示されているユニットのうちの一部又は全てを省略してもよい。加えて、図１には、コアが２つのみ示されているが、プロセッサは、いかなる数のコアを含んでもよく、同じ種類の複数のコアを含んでもよいし、種類の異なる３つ以上のコアを含んでもよい。

図１には、外部のメモリ制御装置（制御ハブ１７０）とインターフェースを使用してポイント・ツー・ポイントで連結されているプロセッサの実施形態が示されている。しかしながら、現在のプロセッサの多くは、オンプロセッサ・メモリインターフェースモジュールを含むようになっており、複数のコアを相互接続するような環状構造（リング）のような様々な相互接続アーキテクチャ、及び、共有キャッシュ及びその他のインターフェースを有するオンチップモジュールを含むようになっている。

このような相互接続アーキテクチャの一実施形態が、図２に示されている。図に示すように、プロセッサ２００は、分配されたキャッシュ、環状相互接続、コア、キャッシュ及びメモリ制御構成要素を含む。しかしながら、図示の構成は単なる例に過ぎず、説明される方法を実装する及び装置に実装されるプロセッサは、あらゆる処理要素、あらゆる種類又は階層のキャッシュ及び／又はメモリ、外部デバイスと通信を行うフロントサイドバス又はその他のインターフェースを含んでもよい。

一実施形態において、キャッシングエージェント２２１−２２４はそれぞれ、分配され関連付けられているキャッシュを管理する。キャッシングエージェント２２１−２２４は、論理的に共有されているキャッシュのスライスを管理してもよいし、同じメモリ階層の個別のプライベートキャッシュを管理してもよい。一例として、構成要素２２１のようなキャッシュコンポーネントのそれぞれは、配列されたコア、すなわち、分配されたスライスを管理する目的でキャッシュエージェントが関連付けられたコアに対するキャッシュのスライスを管理する。図示されるように、キャッシュエージェント２２１−２２４は、キャッシュ・スライス・インターフェース・ロジック（ＣＳＩＬ）と称されるが、キャッシュコンポーネント、エージェント、又は、その他のロジック、ユニット、又は、キャッシュ又はキャッシュのスライスと結合するモジュールと称される場合もある。キャッシュは、いかなる階層のキャッシュであってもよいが、この実施形態例では、コア２０１−２０４によって共有されるラストレベルキャッシュ（ＬＬＣ）に注目して説明する。

環状相互接続２５０のトラフィック及びキャッシュスライスとの結合を扱うキャッシュエージェントのように、コアエージェント／コンポーネント２１１−２１４はそれぞれ、トラフィック及びコア２０１−２０４とのインターフェースを取り扱う。加えて、図示されている環状構造２５０は、メモリ制御部（ＩＭＣ）２３１及びグラフィックスプロセッサ（図示せず）のようなその他のモジュールと結合するメモリ周辺ハブ（ＩＭＰＨ）２３０及びグラフィックスハブ（ＧＦＸ）２４０を含む。しかしながら、環状構造２５０は、上記のモジュールの何れを含み又は省略してもよく、その他の図示していない周知のプロセッサモジュールを含んでもよい。加えて、ポイント・ツー・ポイント接続又はマルチドロップ接続のような周知の相互接続を介して、同様なモジュールを接続してもよい。

［テスト基盤の実施形態］
一実施形態において、図１及び図２に示したようなプロセッサ又はその他の周知のプロセッシングデバイスを含むコンピュータシステムは、コンピュータシステムにおける様々な側面を、効率的に（コスト及び複雑さの両方において）テスト、検証及びデバッグすることを支援するテスト基盤を含む。この効率的な環境を提供するために、例えば、図３に示す階層構造のような、複数の層（例えば、物理的、通信及びソフトウェアの階層）が存在する。

例えば、物理層３０５は、テストフック（テスト、検証及び／又はデバッグの機能を提供するシステムに設けられたハードウェア又はファームウェア）を含み、テストフックは、コンピュータシステムの複数のデバイス（プロセッサ、相互接続、制御ハブ等）の至る所に含まれていてもよい。一実施形態において、テストフックは、設計により、マイクロコントローラのようなその他のハードウェア／ファームウェアの指示で、又は、コンピュータプラットフォーム内に一体化されているユーザー／ベンダーのデバッグプログラム又はコードのようなソフトウェアの指示で、デバッグ／検証情報を収集する。フックの具体的な例としては、デバイスにおけるアーキテクチャ的及びマイクロアーキテクチャのテスト／追跡測定機能、電気的検証ツール、コンピュータシステム内／オンデバイスロジック分析器、接続プロトコル／トレース測定機能、プラットフォームレベルテスト機能、電源テスト機能（これについては、以下に記載する電源検証の実施形態の章で詳しく説明する）、電源オン／ブート追跡測定機能、検証回路、大量生産テスト機能、及びその他のよく知られたハードウェアベースの測定及びテスト機能が含まれる。

指定されたテストフックを提供することに加えて、一実施形態では、テストフックとテスト／デバッグソフトウェアとの間の通信を提供するのに、通信層３１０が採用される。通信層３１０は、単純に、テストフックへ直接アクセス（テストシナリオを規定する又はテスト結果を取得するための）する能力をソフトウェアに提供するだけのものであってもよい。しかしながら、上記したように、デバイスの設計者は、シリコンテスト機能を、ベンダー又はユーザーからのアクセスに対して難読化させたいと考える場合がある。その場合には、ベンダー又はユーザーのソフトウェアが通信層３１０とやり取りをするように構成し、通信層３１０がハードウェアテスト機能の難読化（抽象化）された概要をソフトウェアに提供するようにする。そして、通信層３１０は、顧客から見た場合に難読化されているような態様で、物理層３０５内のハードウェアとやり取りをする。一実施形態において、検証制御ユニット（ＶＣＵ）とも称されるマイクロコントローラは、様々なテストフックへのアクセスを制御する。ここで、ベンダーソフトウェアは、様々なブレークポイント、マイクロブレークポイント・トリガイベントをプログラムする、格納されたトレースを抽出する、検証情報を提供する、及び、異なるレベルのアクセスを提供する等の様々な検証タスクを調整するようＶＣＵに要求することができる。

最後の例に示されるように、テスト基盤に関して、難読化する程度及びセキュリティのレベルは様々に異なるものを提供してもよい。ここで、シリコン設計者は、含まれているテスト機能の全てに自由にアクセスできるようにし、様々なベンダー、顧客及びユーザーに対しては、アクセスレベルを下げることを望む場合がある。このような場合を考慮し、第１段階は、物理層３０５におけるフックをぼやかすことができる抽象化層３０５を提供することを含む。そして、一実施形態では、第２段階は、アクセスの異なる複数のレベルの間の境界線を引くことができる安全なアクセス方法を提供することを含む。

また、通信層３１０は、検証情報のソフトウェア層３１５への報告を提供する。例えば、オンダイ・ロジック分析器は、プロセッサからのトレース情報を収集する。通信層３１０は、キャッシュ又はシステムメモリのような格納構造に、ソフトウェア層３１５がデータにアクセス、データを認識及び操作可能となるような規定された形式でトレース情報を提供する。そして、アクセス層とも称されるソフトウェア層３１５は、通信層３１０にアクセスし、テストデータ内容を処理するプログラム／ツールを提供する。上記の例に戻り、トレース情報が、格納構造に配置されると、検証及びデバッグプログラムは、トレース情報を解釈する（検証及びデバッグ）ために処理を行ってもよい。

以上の記載では、物理層３０５からのデータへの論理的な又は抽象化されたアクセスについて主に説明がなされた。物理層３０５へどのようにアクセスするかについては、以下で説明する。一例では、このようなアクセスは、物理的アクセスを使用して行われる。ここで、双方向通信（物理的フックへの難読化されたアクセスのためのＶＣＵへの要求のような、抽出されたデバッグ情報の上方向の通信、及び、デバッグ要求の下方向の通信）をサポートするべく、専用又はユニバーサルデバッグ／検証ポートが提供される。このポートは、コンピュータシステム内（プロセッサパッケージ、チップセット、マザーボード内、又は、ユニーバーサル・シリアル・バスインターフェースのような既存のＩ／Ｏインターフェースを介して）のいかなる場所に位置する又は複製されていてもよい。

別の実施形態では、テスト基盤は、リモートアクセスも提供する。例えば、ベンダーが、コンピュータシステム内の一プロセッサを検証しようとしているが、現在のコンピュータプラットフォームの複雑性に起因する問題を有している場合を仮定する。そして、ベンダーには、高階層の難読化（抽象化）されたプロセッサデバッグツールへのアクセスのみが提供されているとする。プロセッサの製造側が、デバッグプロセスを助けるために検証を行うエンジニアを物理的に派遣する替わりに、テスト基盤が、検証及びデバッグのためのリモートアクセスを許可してもよい。さらに、離れた場所に存在する製造者は、シリコンテスト機能をベンダーから秘密に維持しながら、セキュリティプロトコルにより、ハードウェア基盤の大部分にアクセス可能として、問題解決を図る及びデバッグを行ってもよい。リモートでデバッグを行う構成に加えて、図３の層は、ローカルで又はリモートで更新することができ、ファームウェア又はＶＣＵ内のコードを更新するパッチを提供することにより、将来行われる検証に柔軟に及び適切に対応することができる。

図３には、テストアーキテクチャを、３つの主要なカテゴリ（物理、通信及びソフトウェア）に分割した、一般的な階層構造が示されている。しかしながら、テストアーキテクチャの階層構造（スタック）は、あらゆる態様で構成されてもよく、同様なテストインターフェースを提供するその他の層を含んでもよい。例えば、一実施形態では、検証アーキテクチャの階層構造には、目的の層（Ｄｆｘテストの下の物理的ユニット）、トランスポート層（テストを行うべく目的のＤＦｘユニットで実行される高階層の転送メカニズムにとらわれないスタックを採用する層）、抽象化層（アプリケーションと下位層のＤＦｘインターフェースとの間の抽象化された通信を提供する層）、アプリケーション層（ＤＦｘサービスと結合するために、抽象化層と通信を行うアプリケーション、サービス、ツール及びその他のソフトウェアを含む層）、及び、プレゼンテーション層（基本的なデータ、プロトコル及び情報を関連付け、視覚化、及び／又は表示する層）が含まれる。

［検証、テスト及びデバッグのフックの実施形態］
一実施形態において、検証、テスト及びデバッグフックは、プロセッサ及び／又はコンピュータシステム／プラットフォームのシリコンに一体化されており、効率的なテスト、検証及び／又はデバッグをサポートする。最終製品に一体化されている検証フックは、しばしば、デバッグ、検証及び／又はテストのための設計（以下、ＤＦｘと称する）と称される。ＤＦｘは、製品のテスト、デバッグ及び／又は検証をサポートするべく、その製品に含まれている周知のあらゆるフックを含む（自己検証ツール）。以下の説明では、このようなフックの数多くの例が記載されるが、この例のリストは完全なものではない。また、以下に記載するＤＦｘの機能の何れか又は全てを、周知の一体化されたテスト／デバッグ機能と組み合わせてもよいし、省略してもよい。加えて、プロセッサに関して、ＤＦｘの説明が主になされるが、同様なフックは、マザーボード、制御ハブ、埋め込みプロセッサ、グラフィックスプロセッサ、入出力デバイス（Ｉ／Ｏデバイス）等のその他のシリコンデバイス含まれていてもよい。

図４には、ＤＦｘ機能の実施例を説明するための、複数のプロセッサを含むコンピュータシステムの一実施形態が示されている。示されている構成は、説明を行うべく例示を目的としたものである。既知のあらゆるコンピュータシステム構成を利用してもよく、例えば、図１に示したような、従来からのレガシー構成を利用してもよい。さらに、図示を簡潔にするべく４つのプロセッサ（４１０ａ，ｂ，ｃ及びｄ）のそれぞれは、同じ構成要素を有するように描かれているが、異なる非対称な構成を有してもよい。以下では、説明を簡単にするために、プロセッサ４１０ａの特徴について、重点的に説明する。

一実施形態において、コンピュータシステム４００は、シリコンＤＦｘへのアクセスを提供及び制御する１以上の検証制御ユニット（ＶＣＵ）を備える。図示するように、構成要素（プロセッサ４１０ａ−ｂ及び周辺制御ハブ４７０）それぞれは、自身のＶＣＵを含むが、プロセッサ又はコンピュータシステムへのアクセスを制御するべく、いかなる数の又はいかなるレイアウトのＶＣＵが設けられてもよい。ＶＣＵの実施形態及びそれに関係する機能については、以下の「検証制御部の実施形態」の章でより詳細に説明する。したがって、ＤＦｘ機能の実施形態を説明する目的から、このシナリオでは、ＶＣＵ４１２ａは、プロセッサ４１０ａのＤＦｘ機能へのアクセスを提供する。

ＤＦｘ機能の第１の例として、プロセッサ４１０ａは、一体化された（オンダイ又はオンチップとも称される）ロジック分析器（ＯＤＬＡ又はＯＣＬＡ）４１３ａを含む。以前のロジック分析器は、デバイスのデジタル信号を捉える又は表示するべく、多数のプローブ又は外部ポートを介して、部品に接続された個別の物理的デバイスを含んでいた。しかしながら、外部デバイスは、非常に高価である。コンピュータの複雑さが増すにつれ、製品の開発から、その製品と結合することができるロジック分析器の開発までの間の時間差／遅れが、非常に大きくなってきている。その結果、この産業分野では、製品のデバッグ、検証及び発売を、コストが掛からないようにスケジュール通りに行うことができなくなっている。

したがって、一実施形態では、プロセッサ４１０ａは、ロジック分析器のオンダイ機能をサポートするべく、ＯＤＬＡ４１３ａ（ハードウェア、ファームウェア、マイクロコード又はこれらの組み合わせによって構成される）を備える。すなわち、プロセッサ４１０ａは、デジタル信号、状態、トレース等を取得するためにＯＤＬＡ４１３ａを備える。具体的な一例として、プロセッサ４１０ａは、取得点を始動（トリガ）させるブレークポイント（又はマイクロブレークポイント）を設定するロジックを含む。ここで、制御レジスタのようなイベント記憶部には、始動させるシナリオを規定する１つのイベント又は複数のイベントの組み合わせが設定される。そのシナリオに遭遇すると（イベントそれぞれは、シナリオに規定された態様で発生する）、プロセッサにおける関係するステート、信号、トレース等が収集される。トリガ条件又はシナリオは、単純にテスト信号のアサート又はアサート停止であってもよいし、レベル２キャッシュのミスを経験した命令のみに関連付けられた閾値を超えた回数の命令リタイアメント押し出しが発生した場合といったように、マイクロアーキテクチャイベントを組み合わせた複雑なものであってもよい。

ＯＤＬＡ４１３ａは、図４に示されるように、論理ブロック内に物理的にグループ化されていなくてもよい。替わりに、ＯＤＬＡ４１３ａは、プロセッサ４１０ａ内の内部信号又は外部信号を取得する、プロセッサ４１０ａ全体にわたって分配されたロジックを含んでもよい。あるシナリオでは、ＯＤＬＡ４１３ａは、トレース又は回路の論理レベル取得する、プロセッサ４１０ａのアーキテクチャ又はマイクロアーキテクチャ部分と関連付けられたロジック、内部トラフィックを取得する内部相互接続と関連付けられたロジック、メモリトラフィックを取得する、インターフェース４６０ａのようなメモリインターフェースと関連付けられたロジック、及び、インターフェース４５０、４６５、グラフィックスインターフェース（図示せず）、レガシー又はサイドバンドインターフェース（図示せず）のような入出力インターフェース、又は、プロセッサと関連付けられたその他の周知のインターフェースと関連付けれたロジックを含む。

以前の外部ロジック分析器では、結果は、外部デバイスによって取得されていた。これに対し、上記のシナリオでは、プロセッサ４１０ａが、自身のロジック分析器を動作させる。したがって、一実施形態において、ＯＤＬＡ４１３ａは、取得された情報を保持し、利用可能なコンピュータ記憶部を利用する。例えば、ＯＤＬＡ４１３ａは、取得された情報を保持するトレースバッファとして、キャッシュメモリ又はメモリ４２０ａの一部を使用する。一実施形態において、メモリ４２０ａの一部は、ソフトウェアの使用から隔離される。取得された情報は、メモリの隔離された部分に配置される。

ここで、取得された情報は、予め定められた規定された形式で、加工されない状態で配置されてもよく、（アプリケーション層において、製造側又は顧客から提供される）適切なアクセスレベルを有する検証ソフトウェアは、データにアクセス及びデータを操作することができ、例えば、生のデータをタイミングチャート、プロトコルデコード、トレースの表現へ変換する、又は、ロジック分析器のデータのその他の周知の操作を行うことができるようにする。別の実施形態では、ＯＤＬＡ４１３ａは、（そこに含まれるプログラム可能ロジック、コード又はマイクロコードを使用して）生のデータを別のフォーマットへと形式変換し、高階層のレベルのソフトウェアによる解釈のために、メモリに変換後のデータを配置する。

ある実施形態例では、ソフトウェアは、ＶＣＵ４１２ａによって提供される抽象化層のような、通信層によって提供されるアプリケーションプログラムインターフェース（ＡＰＩ）を介して、プロセッサ４１０ａに対して特定のブレークポイントシナリオを要求する。ＶＣＵ４１２ａは、要求を受信して、要求が必須のセキュリティレベルアクセスを有する場合には、ＶＣＵ４１２ａは、プロセッサ４１０ａの制御レジスタに、始動シナリオを設定する。そして、通常の実行の間又は実行のテストモードの間に、制御レジスタに規定されたブレークポイントシナリオに遭遇すると、ブレークポイントが始動される。そして、取得された情報が、オペレーティングシステム（ＯＳ）からは読み取ることができない領域のメモリ４２０ａに格納される。ソフトウェアは、インターフェースＡＰＩを介して、情報にアクセス、及び、情報を操作及び解釈することができ、したがって、外部のロジック分析器又はオシロスコープを使用する必要がなくなると同時に、シリコンデバイスの内部及び外部通信をより詳細及び完璧に調べることができるようになると考えられる。

始動シナリオを設定することに加えて、その他の周知の検証技術を、ＯＤＬＡ４１３ａと一体化及び／又は組み合わせてもよい。例えば、ＯＤＬＡ４１３ａ及びその他のロジックの組み合わせにより、テストケースを設定し、同様なトレース情報を取得することができる。現実には、設計者が、通常の実行の間には容易に再現されないような最悪の場合のシナリオを想定して設計することは、一般的である。その結果、特定の最悪のシナリオを引き起こす要因でプロセッサ４１０ａを起動させて、実際の反応、及び、実際の応答と前もって行われたシミュレーションとの相関関係の両方を特定することは検証に有用であると考えられる。そこで、ＯＤＬＡ４１３ａがデータを収集するシナリオを生成するべく、特定の論理状態を設定する又は特定の入力を提供するロジックを採用する。

上記のＤＦｘの説明では、プロセッサ４１０ａの内部状態を取得するのに、ＯＤＬＡ４１０ａに注目していた。しかしながら、上記で示唆したように、一実施形態では、ＯＤＬＡ４１３ａ及び／又はその他のロジックは、外部インターフェース及び相互接続を検証するのに使用される。外部ロジック分析器を使用する場合のように、デバイス間の通信を観察するのに電気的トレース（配線）にピコプローブを配置する替わりに、シリコンに含まれるＯＤＬＡ４１３ａは、デバイス内の実際のインターフェースにおいて同じ機能を実行することができる。

同様な相互接続フックを、オンプロセッサ・インターフェースに含めてもよい。一例として、図２に戻り、ＤＦｘフックを、環状構造２５０の周辺に散在させてもよく、それにより、環状構造２５０の電気的属性（タイミングマージン、ビットレート、エラーテスト、クロスカップリング、リンギング、アンダーシュート、オーバーシュート等）、環状構造２５０におけるトラフィック、環状構造２５０の通信プロトコル（すなわち、キャッシュコヒーレンシプロトコル）、制御インターフェース２３０／２３１におけるトラフィック／プロトコル、グラフィックスインターフェース２４０におけるトラフィック等を検証してもよい。

その結果、複雑なインターフェースの検証は、シリコンと一体化されたフックを含み、このフックを使用することにより、物理的、電気的特性、ロジックの状態／トレース、及び、高階層のプロトコルのような、相互接続アーキテクチャの積層体の複数の層を検証してもよい。図４には、このようなインターフェース（プロセッサ４１０ａ−ｄを接続するＱＰＩインターフェース４５０、プロセッサ４１０ａ−ｄをメモリデバイス４２０ａ−ｄにそれぞれ接続するメモリインターフェース４６０ａ−ｄ、及び、レガシープロセッサ４１０ｃを周辺制御ハブ４７０に接続するＰＣＩ−Ｅ又はその他のインターフェース）が、検証のためのフックを含む構成が描かれている。グラフィックスインターフェース又はサイドバンド相互接続のような、その他のインターフェースにおいても、同様なＤＦｘフックを利用してもよい。しかしながら、図示されているインターフェースはプロセッサを中心とした構成であることに注意されたい。また、ＰＣＨ４７０のようなその他のデバイスに、同様なＤＦｘフックを含めて、ペリフェラルインターフェース（ＰＣＩ−Ｅ）、ユニバーサル・シリアル・バス（ＵＳＢ）、シリアル・アドバンスト・テクノロジー・アタッチメント（ＳＡＴＡ）、ダイレクト・メディア・インターフェース（ＤＭＩ）及びその他の周知のコンピュータ相互接続構成のようなその他のインターフェースを検証するようにしてもよい。

具体的な例を提供するべく、図５には、階層化された相互接続積層構造（ｉｎｔｅｒｃｏｎｎｅｃｔ ｓｔａｃｋ）を利用した双方向接続アーキテクチャの一実施形態例のブロック図が示されている。図示されている接続構造の例としては、ＰＣＩエクスプレス（ＰＣＩ−Ｅ）及びクイックパスインターコネクト（ＱＰＩ）が含まれる。主にＱＰＩアーキテクチャを参照して、図示されている階層構造が説明されるが、同様に、ＰＣＩ、ＰＣＩ−Ｅ、グラフィックス接続、メモリ接続、周辺機器接続又はその他の周知の接続について構造を適用してもよい。図５に示される層、例えば、物理層５０２は、物理層５０２ａ及び物理層５０２ｂといったように異なるエージェントに実装されてもよい一般的な層の考察を含む。図に示されるように、相互接続積層構造は、５つの層に分けられ、そのうちの１つ又は複数の層は、設計の実装形態に応じて、選択的である場合もある。例えば、一実施形態において、ルーティング層５０４は、リンク層５０３の機能に埋め込まれてもよく、したがって、一実施形態では、ルーティング層は個別の層として設けられない。

ある実施形態では、物理層５０２は、物理的な媒体における情報の電気的転送の役割を担う。例えば、物理的なポイント・ツー・ポイントリンクを、リンク層エンティティ５０３ａ及び５０３ｂの間で利用してもよい。図示の例では、物理リンクは、双方向差分信号ペア５５１及び５５２を有する差分信号スキームを含む。ここで、物理層は、電気的サブブロック及び論理的サブブロックに論理的に分けることができ、物理層は、積層構造の残りの層からの情報の電気的転送からは分離され、リンク層５０３とは通信を行う。

一実施形態において、リンク層５０３は、積層構造の上部層から、物理層５０２を抽象化（難読化）し、信頼性の高いデータ転送及び接続されたエージェント／エンティティ間のフロー制御、及び、物理チャネル／インターフェースを複数の仮想チャネル及びメッセージクラスに仮想化といった、リンクに関係するサービスを提供する。ここで、仮想チャネルは、積層構造の上部層によって使用される複数の仮想ネットワークと見なすことができる。例えば、プロトコル層５０６は、プロトコルメッセージをメッセージクラスに、したがって、１以上の仮想チャネルに、マップするのに、リンク層５０３によって提供される抽象化に依存する場合がある。

一実施形態において、ルーティング層５０４は、ソースから送信先へパケットをルーティングする方法を柔軟に提供する。上記したように、非常に単純化されたトポロジーにおいては、ルーティング層５０４は明確にならず、リンク層５０３の機能に一体化されてもよい。例えば、ルーティング層５０４が、パケットをルートするために、＜ポート，仮想ネットワーク＞の組を特定するのに、リンク層５０３の抽象化に依存する場合がある。ここで、ルーティングテーブル情報は、パケットのルーティング情報を提供するべく保持される。

一実施形態において、トランスポート層５０５は、エンド・ツー・エンドの信頼性の高い送信サービスを提供する。ルーティング層５０４と同様に、トランスポート層５０５は、設計実装形態に基づいて、必要に応じて設けられる。一例として、トランスポート層５０５は、プロトコル層５０６に対する信頼性の高い送信サポートを提供するのに、ルーティング層５０４に依存する。一実施形態では、相互接続アーキテクチャ内において、構成要素のサブセットは、トランスポート層５０５を含む。その結果、この構成要素のサブセットが、トランスポート層５０５に関係するパケットのサブフィールドを規定し、その他の構成要素は、このサブフィールドを規定しない場合がある。

一実施形態において、プロトコル層５０６は、キャッシュコヒーレンス、順序付け、ピア・ツー・ピア通信、割り込み伝達等の、ノード／エージェント間の高階層の通信を実装する。すなわち、プロトコル層５０６は、許容されるメッセージ、要求、応答、フェーズ、コヒーレンス状態等を、ホームノード、ピアノード、キャッシングノード及び非キャッシングノードのようなノード又はエージェントに対して規定する。ホームノードメッセージ、スヌープメッセージ、応答メッセージ等のメッセージの例については以下で説明する。

層及び関連するロジックの考察は、あらゆる態様で組み合わされてもよい。例えば、プロトコルロジックは、物理層、すなわち、送信ロジック又は受信ロジックと結合されてもよい。ここで、図５から分かるように、一実施形態では、プロトコルロジックは、物理層ロジックと直接結合さることなく、その他の層のロジックを介して結合される。さらに、一実施形態において、相互接続積層構造は、キャッシュ制御ロジック又はキャッシュメモリロジックのような内部の構成要素ロジックと結合され、適切なキャッシュコヒーレンスアクションを開始する。

一実施形態において、ＱＰＩベースの相互接続は、Ｍｏｄｉｆｉｅｄ Ｅｘｃｌｕｓｉｖｅ Ｓｈａｒｅｄ Ｉｎｖａｌｉｄ Ｆｏｒｗａｒｄ（ＭＥＳＩＦ：変更・排他・共有・無効・転送）プロトコルを含み、信号及びバスのシリアル化の制限を伴うことなく、スヌーププロトコルと同様なプロトコルを提供する。スヌーピングキャッシュプロトコルのように、ＭＥＳＩＦは、コヒーレンス（一貫性）を維持するのに、データのキャッシュされたコピーを有するノードに依存する。同期及び中央化されたブロードキャスト（一斉送信）ではなく、ポイント・ツー・ポイントリンクを使用すると、タイムワープ（ｔｉｍｅ‐ｗａｒｐ）の問題が起こる、すなわち、異なるノードから見ると、イベントが異なる順番で発生しているように見えてしまう。一例として、ＭＥＳＩＦプロトコルは、タイムワープによって生じる可能性のあるエラーを認識することによってこの問題に対処し、プロトコル又はソフトウェアによる解決方法を提供する。

ホームノードは、多くの場合、データのキャッシュされていないコピーと関連付けられる。その結果として、ホームノードは、ホームノードと関連付けられたデータに関するトランザクションに参加する場合がある。しかしながら、ホームノードは、トランザクションと関連付けられた"クリティカルパス（ｃｒｉｔｉｃａｌ ｐａｔｈ）"に必ずしも含まれる必要はなく、コンフリクト及びタイムワープの問題を解決するために、ホームノードはトランザクションに挿入されてもよい。一実施形態では、このスキームの並列−ブロードキャストの性質があることから、ＭＥＳＩＦは、キャッシュ可能なデータのコピーを取得すると同時に、プロトコルのスヌーピングに関連するレイテンシを低くすることができ、ある場合には、要求−応答を１往復するだけの最小のレイテンシとすることができる。

一実施形態において、ＭＥＳＩＦプロトコルに関する基本的なトランザクションは、全てのピアノード及びホームノードに最初の要求をブロードキャストすることを伴う。コピーが、ステートＥ、Ｆ又はＭコヒーレーンシ状態でキャッシュされる場合には、コピーは応答に含まれる。そして、第２のメッセージが、ホームノードに送信されて、要求が満たされたことを通知する。要求されたラインがキャッシュされていない場合、又は、Ｓステートのコピーのみが存在する場合には、ホームノードに送信された第２の要求を使用して、前の要求を確認する。ホームノードが有する前の要求は、その時までには、メモリからフェッチされていると考えられる。何れの場合にせよ、ホームノードは、同期及びコンフリクトを解消する目的で、第２の要求に応答する（及び、最初の要求、最初の要求及び第２の要求は組み合わせられる場合もある）。ここで、ホームノードは、１以上のキャッシュを有してもよいので、最初の要求にその他のノードと同じように応答してもよい。

一実施形態において、コンフリクトは、分散させた態様で対応される。個々の要求は、任意の時間の長さ分、遅延する可能性があるため、タイムワープの問題により、コンフリクトを検出するのが難しくなっている。しかしながら、各ノードが、要求をした後にコンフリクトをモニタすれば、コンフリクトを検出できる。複数のノードが、コンフリクトを検出することが考えられるが、例として、複数のノードのうちの少なくとも１つがコンフリクトを検出するとする。この場合、一実施形態では、ノードからの応答は、コンフリクト情報を含む可能性がある。

一実施形態において、応答からのデータのコピーを受信するノードは、データを受信するとすぐに内部でそのデータを使用することができるが、そのノードが確認応答（ｃｏｎｆｉｒｍａｔｉｏｎ）を受信するまでは、そのデータの利用をシステムの残りの部分に可視化することはできない、すなわち、グローバルに可視状態とすることはできない。確認応答は、要求ノードがコピーを別のノードに転送し、また自身のキャッシュからそのノードを立ち退かせる（ｅｖｉｃｔ）よう指示する命令を含んでもよい。そして、あるノードがキャッシュされたデータを供給することによって、別のノードからの要求に応答するときに、一実施形態では、そのノードは、ノードがデータを転送したことを確認した旨の応答をホームノードから受信するまで、受信する同じキャッシュラインについてのその他の要求を遅らせるので、全てのノードが、（書き込み可能な）キャッシュラインの転送を同じ順番で観察すると仮定することができる。

上記したように、ホームノードは、キャッシュされていないデータの格納場所となっていると同時に、プロセッサ及びキャッシュを含んでもよい。ホームノードのプロセッサが、キャッシュミスすると、ホームノードは、全てのその他の（ピア）ノードに対して要求をブロードキャストし、ホームノードは、その他の要求がホームノードに到着すると内部で要求を扱う。これは、ホームノードが明示的に、自身に（ホームノード）にメッセージを送信しない特別なケースである。加えて、ローカルにキャッシュされたデータに対する外部からの要求が到着すると、ホームノードは、適切に応答する。

開示されたメッセージプロトコルは、コヒーレンス（キャッシュ及びホーム）エージェント、非キャッシングエージェント及びその他のエージェント（メモリ制御部、プロセッサ等）の間で許可されるメッセージのセットを規定する。コヒーレンシプロトコルは、コヒーレンスな（一貫性のある）考え方を表現するアルゴリズムにおける言語及び文法として、メッセージを使用する。このアルゴリズムは、分別して要求を順番付けし、コンフリクトを解消し、キャッシングエージェント間の相互作用を記述する。上記では、ＭＥＳＩＦプロトコルが説明されたが、必ずしもＭＥＳＩＦキャッシュコヒーレンシプロコルの使用が必要であるわけではない。例えば、Ｆｏｒｗａｒｄ（転送）ステートを使用しなくてもよく、周知のＭＥＳＩプロトコルを使用してもよい。さらに、上記の説明は、ＭＥＳＩＦプロトコルの一実施形態の概論の一例を含むまでである。したがって、上記の様々な構成要素は、別の実施形態では、異なっていてもよい。

上記から分かるように、このような複合体を検証及びデバッグするのは、（電気的及びプロトコルの観点の両方において）非常に煩雑なプロセスとなる。そこで、一実施形態では階層化された相互接続の積層構造全体にわたる検証を助けるべく、図４のプロセッサ４１０ａは、ＤＦｘを含む。例えば、ＯＤＬＡ４１３ａは、始動シナリオ又はその他のイベントに応答して、相互接続の積層構造のトラフィック、トレース又はステートを取得することができる。一実施形態において、ステートとは、デバイス、エージェント及び／又は検証オブジェクト（対象）のその他の構成要素の状態のスナップショットを指す。ステートは、また、アーキテクチャ又は検証オブジェクトの構造的な状態とも称することができる。別の例では、ステートは、状態のスナップショットにおけるパラメータの値の組み合わせによって規定される。したがって、相互接続構造において１００個のパラメータが特定される場合には、これら１００個のパラメータの異なる値の全ての組み合わせが、それぞれ異なる状態を表すと考えられる。

１つのステートが複雑なプロトコルの多数のパラメータを参照することから、キャッシュコヒーレンシプロトコルの１つのステートの非常に単純化した例として、１つのプロセッサが共有コヒーレンシステートの１つのキャッシュラインを有し、２つのプロセッサが無効ステートのキャッシュラインを有し、これらのプロセッサのうちの１つにおいてスヌープが受信された場合を考える。ここで、複数のプロトコルエージェント、複数のステートに保持された複数のキャッシュライン、及び、特定の送信先で受信された要求／メッセージが存在する。このような単純化された例のみで、少ない数のパラメータが存在する。別の例として、データペイロードを有する書き込みトランザクションは、複数のステートになる可能性があり、書き込み先、書き込まれるデータペイロードと関連付けられたキャッシュラインのステート、相互接続のトラフィック、その他のエージェントによる書き込み応答等のその他のパラメータが様々に変更されると考えられる。

したがって、一実施形態では、パラメータとは、プロトコル、物理的ロジック、デバイス、エージェント、又は、様々なステートに変化する又は様々な状態であるグローバルステート／変数における、あらゆる要素を指す。具体的な例としては、キャッシュコヒーレント相互接続プロトコルを有効にする場合、プロセッサ４１０ａのようなキャッシングエージェントに対するパラメータには、スヌープに対するキャッシュ応答が含まれる。ここで、キャッシュ応答パラメータの第１の値として、要求デバイスにスヌープされたキャッシュラインを転送することが含まれ、キャッシュ応答パラメータの第２の値として、そのキャッシュラインのホームノードへの書き込みが含まれる。その他一般的なコヒーレンシプロトコルパラメータには、様々な種類のエージェント、エージェント応答、デバイス応答、相互接続応答、メッセージ応答、応答の種類、特定のアクションに対するその他の応答、応答先、メッセージ、メッセージの種類、メッセージ送信先、要求、要求の種類、要求先、キャッシュの種類、キャッシュのステート、キャッシュロケーション、レジスタのステート等が含まれる。

しかしながら、物理的相互接続、通信プロトコル、又は、その他のプロトコルのようなアーキテクチャは、検証の対象となりうることから、パラメータは、様々な種類の変数を含んでもよい。可能性のあるプロトコル関連のパラメータの例示的であって不完全なリストには、多数のプロトコルエージェント、プロトコルエージェントの種類、エージェントついてのキャッシュ実装の種類、様々な種類のプロトコルエージェントの数、プロトコルエージェントの型、プロトコルエージェントのステート、プロトコルエージェント又はバスにおける回路又はステートマシンのステート、エージェント識別子、多数のプロトコル要求、要求の種類、要求元、要求先、要求のステート、参照されるオペレーション、オペレーションのソース、参照されるアドレス、アクセスされるアドレス、アドレスロケーションの状態、データペイロード、プロトコルエージェントのステート、キャッシュのステート、キャッシュラインのステート、電圧、周波数、電源状態又はその他の物理的プロトコル属性といった物理的プロトコルステートパラメータが含まれる。

物理層５０２ａ、５０２ｂに関して、相互接続の物理的パラメータの幾つかの例には、電圧、アンダーシュート、オーバーシュート、周波数、周期、スペクトル拡散、ジッタ、タイミングマージン、ノイズ等が含まれる。その他のパラメータとしては、接続に関連するステートマシンのステート、エージェントの種類、エージェントのステート、エージェントにおけるＩ／Ｏ回路のステート等が含まれる。しかしながら、アーキテクチャ内のあらゆる可変要素を、パラメータと見なしてもよい。

したがって、一実施形態では、ＯＤＬＡ４１３ａは、目的のインターフェースの全て又は一部分を含んでもよいステート又はトレースを取得するのに採用される。始動シナリオのような規定されたイベントが発生するのに応答して特定のスナップショットを１回取得するのに加えて、ＯＤＬＡ４１３ａは、トラフィック（インターフェースにおける通信の複数のステート）を取得するのに採用される。このシナリオでは、デバイス間で交換されるプロトコルが取得される。データの処理後、高レベルのソフトウェアは、正しいプロトコル交換がインターフェースにおいて発生したかを確認するプロトコルダイアグラムを生成することができる。上記の例の続きを説明する。ＤＦｘシリコンは、排他的コヒーレンシステートのキャッシュラインに対する特定のスヌープメッセージを受信するプロセッサ４１０ａと関連付けられた始動シナリオを生成する又は搭載してもよい。そして、ＯＤＬＡ４１３ａは、プロセッサ４１０ａのスヌープメッセージに対する応答といった情報を、メモリ４２０ａのある部分で取得する。ＶＣＵ４１２ａによって提供されるＡＰＩを介して、適切なアクセスを有する第３者のベンダー（ＴＰＶ）は、メモリ４２０ａの第２部分に保持されている情報に基づいてプロトコルを構築することができ、規定されたステートの環境下で特定のスヌープメッセージに適切な応答が与えられたことを確認できる。

この例から分かるように、同様な方法及び装置を、電気的特性、及び、上記で紹介されたＱＰＩ相互接続４５０のＭＥＳＩＦキャッシュコヒーレントプロトコルのようなプロトコルの検証にも使用することができると考えられる。オンシリコンフックが、階層化された接続構造のようなあらゆるインターフェースの検証を提供できることを示すべく、上記ＱＰＩ相互接続４５０の検証例から推定を行ってもよい。

ＯＤＬＡ４１３ａ及びプロセッサ４１０ａの内部及び外部インターフェースに対する検証フック以外に、その他のシリコンフックを、プロセッサ４１０ａに組み込んでもよい。例えば、一実施形態では、特定のマイクロアーキテクチャフックが、プロセッサ４１０ａに組み込まれる。例えば、同時係属中の出願番号１１／１４３，４２５号明細書"ＥＮＨＡＮＣＥＭＥＮＴＳ ＴＯ ＰＥＲＦＯＲＭＡＮＣＥ ＭＯＮＩＴＯＲＩＮＧ ＡＲＣＨＩＴＣＵＴＲＥ ｆｏｒ ＣＲＩＴＩＣＡＬ ＰＡＴＨ‐ＢＡＳＥＤ ＡＮＡＬＹＳＩＳ（クリティカルパスベースの分析のためのアーキテクチャの性能監視の改善）"には、マイクロアーキテクチャの性能を監視する装置及び方法が説明されている。性能は、シミュレーション、分析的思考、リタイアメント・プッシュアウト測定、全体の実行時間、及び、インスタンス毎のイベントコストのその他の測定方法を通じて、監視される。そして、同様な装置がシリコンに含まれて、マイクロアーキテクチャのイベントに基づく命令のタグ付け／命令のカウント、リタイアメント・プッシュアウトの測定、命令／プログラムの全実行時間の測定、及び、プロセッサのその他の周知の機能の検証／デバッグが行われる。

別の例として、プロセッサ４１０ａは、電力制御ユニット（ＰＣＵ）４１４ａを含み、プロセッサ４１０ａ内の処理要素の電力状態のような電力を調整及び制御する。加えて、ＤＦｘフックをＰＣＵ４１４ａと共にプロセッサに組み込んでもよく、それにより、電力消費レベル、様々な電力状態の継続時間、電力状態遷移の頻度、電力状態遷移のプロトコル、及びその他の周知の電力関係の測定基準のような、様々な電力検証測定基準を取得してもよい。ＯＤＬＡ４１３ａのオペレーションと同様に、要因が供給されると又は始動シナリオの発生に応答して、電力情報が、通常のオペレーションの間に収集されてもよいし、特定の最悪の電力状態のシナリオ（すなわち、インターフェースに送信される最悪のパターンによって生成される最悪の電力共振周波数）の場合のテストモードの間に収集されてもよい。電力のＤＦｘ及びオペレーションについは、図２８を参照して、後に詳細に説明する。

電気的なシステム内のあらゆるデバイスに同様に含まれていてもよいプロセッサ中心のＤＦｘの例示にとどまらず、その他のプラットフォームレベルでのＤＦｘについても含まれると考えられる。上記及び以下に記載されるＤＦｘ（デバッグの機能）は、本明細書に記載されるテストアーキテクチャのその他の部分使用することなく、個別に実装されてもよい。例えば、ブートプロセスの初期段階における信号情報の収集は、図６−８を参照して以下で詳細に説明するが、検証制御ユニット又は階層化され抽象化されたアクセスを使用せずに、レガシーシステムに実装してもよい。

図６には、信号情報における初期の電力を収集する構成のブロック図の一実施形態が示されている。この実施形態では、ＰＣＨ６０５が、ダイレクト・メディア・インターフェース（ＤＭＩ）６３５を介してプロセッサ６４０に連結されている。通常、電源がＯＮの状態では、最初にＰＣＨ６０５に電力が投入される。多くのシリコンデバイスと同様に、ＰＣＨ６０５は、複数段階で電力投入される。例えば、特定の複数のウェルが特定の順番で電力投入される。純粋に例示するだけの例であるが、クロック６１０が先ず最初に電源投入され、次に、サスペンドウェル、アクティブウェル、リアルタイムクロックウェル等のウェル６１５及び６２０に電源が投入される。最後に、管理容易性エンジン（ｍａｎａｇｅａｂｉｌｉｔｙ ｅｎｇｉｎｅ）及びテストアクセスポート（ＴＡＰ）のようなテストロジック６２５がイネーブルされる。

ある環境下では、特定の電力投入又はテストロジック６２５がイネーブルされる前に遷移する初期信号は、見ることができない（これら信号の発行について可視性が存在しない）が、これは、これら信号に関連付けられた遷移情報が、テストロジック６２５がブートプロセスでイネーブルされるまでに失われてしまうからである。しかしながら、検証及びデバッグの間は、そのような信号についての情報を見ることができる又は収集できるようになれば有用である。このような信号の例には、電力管理制御リセット信号が含まれる。この例では、この信号の遷移により、電力管理制御部に、フェッチ及び実行を開始させるよう命令される。したがって、（１）信号が遷移しなかった、（２）信号が遷移した、及び／又は（３）いつ信号が遷移したか、について判断することができ、電力管理制御部がハングするシナリオ（"固まった"場合のシナリオ）のデバッグを助ける。

このように、一実施形態において、電力投入初期状態の信号取得ロジック（初期ブーストテストロジックとも称されてもよい）は、デバイスに完全に電力が投入される前の、初期状態の信号情報を取得する。トレースのような信号情報を取得するあらゆる周知の方法又は装置を利用してもよい。ここで、信号取得ロジック６３０は、最初の電力投入の後に特定の信号情報を取得し、この信号情報を格納するロジックを含む。そして、テストロジック６２５がイネーブルされると、情報が読み出されて、適切なデバッグオペレーションが実行される。

図７には、電子システムのブートの間の初期信号を取得する取得ロジックの高レベルブロック図の一実施形態が示されている。図に示すように、取得ロジック７００は、対象の信号（すなわち、信号１、２、３、・・・１１のような、ブートの間に監視される信号）についての情報を取得／保持するレジスタのような格納要素７２０を含む。一実施形態において、電力が投入されると、取得ロジック７００は、（ユーザーのトリガ又は第３者のアクセス／プログラミングを必要とすることなく）初期設定としての信号情報の取得を開始する。別の例として、情報の取得は、特定の信号／クロックの遷移又は特定のウェルがイネーブルされた等の特定の条件が発生した時に、開始する。同様に、所定の時間／サイクルの経過、一定期間対象の信号の遷移を検出しなかった時、対象の最後の信号が遷移した時、対象の最後の信号が所定期間遷移しなかった時、特定のウェルがイネーブルされた時、テストロジックがイネーブルされた時、プログラムが取得を止めるべきだと示した時、又は、その他の周知のイベントの発生時のような条件が発生すると、信号の取得を停止させてもよい。

また、（遷移の時間、遷移回数、遷移の方向、トレース等）信号情報取得の周知の装置又は方法を利用してもよく、特定の例の実施形態について、図７を参照して説明する。このシナリオでは、レジスタ７２０が、対象の信号（又は、信号のそれぞれ）がいつ遷移したかの時間を記録する。例えば、レジスタ７２０は、信号名フィールド及びタイムスタンプフィールドを含む。信号名フィールドは、対象の信号を特定するビット表現を保持する（すなわち、対象の特定の信号に対応するように認識可能なビットパターンを保持する）。タイムスタンプフィールドは、信号名フィールドで特定される信号の遷移に対応する時間のビット表現を保持する。あるシナリオでは、タイムスタンプ値は、図６のＰＣＨ６０５のようなデバイスのシリコンスキュー全体にわたって決定性を有するものである。また、タイムスタンプは、デバッグに使用されるシリコンスキュー全体にわたって決定性を有するものである。

さらに、レジスタ７２０は、信号名フィールド及びタイムスタンプフィールド保持有効情報を示す有効値を保持するステータスフィールドを有してもよい。反対に、無効値は、同じレジスタにおける対応するフィールドのステートが無効であることを示す。一実施形態において、レジスタ７２０は、設計者によって決定されるように、又は、後に製造者によって更新されるように、対象の信号全てに関する情報を保持するレジスタアレイを含む。さらに、レジスタ７２０は、Ｎの深さ（Ｎは、正の整数）を有する循環バッファとして実装されてもよく、Ｎ個のエントリのうちの最後のセットを取得して、最後のＮ個の電力ステート遷移の問題の特定を可能にする。

より具体的な例を提供するべく、電力制御ユニットリセット信号（信号１１）を取得／監視すると仮定する。この例では、信号における電力が、ブートプロセスを開始させる。そして、ＰＣＨ６０５のようなデバイスは、電力投入を開始する。レジスタ７２０は、初期値に初期化されてもよい。電力投入信号又は初期の起動信号のその他の遷移に応答して、カウンタ７２５がカウントを開始する。信号１１が遷移すると、パルス生成ロジック７１０がパルスを生成する。パルス生成ロジックは、信号１１（図示せず）のエッジ検出ロジックも含む。その結果、信号１１を特定するビットパターン（電力制御ユニットリセット信号）が、信号名フィールド７３５に格納される。その他の情報が格納されてもよく、例えば、遷移の方向を示すビットが格納されてもよい。加えて、信号名フィールドを更新するために、カウンタ７２５の値（タイムスタンプ）が、タイムスタンプフィールド７３０に格納される。そして、ステータスフィールド７４０に、信号名フィールド７３５及びタイムスタンプフィールド７３０が有効であることを示す高い論理値のような有効値が設定される。

更なる信号の遷移について、このプロセスを繰り返してもよい。上記したように、循環バッファの構成を使用して、循環バッファの深さと同じ数の電力ステート遷移に対する情報を保持してもよい。さらに、信号の遷移が取得されると、一例では、カウンタ７２５は、カウントを継続する（最初のカウントからの絶対的タイムスタンプとなる）。別の例では、カウンタ７２５は、リセットされる（すなわち、１つ前の信号遷移からのタイムスタンプとなる）。さらに、上記したように、信号取得ロジック７００は、最後の信号遷移又は所定期間最後の信号遷移が検出されなかった（ハング又は"固まった"場合のシナリオの可能性）等の所定のイベントが発生すると、信号情報取得を停止する。

一実施形態では、情報の取得が完了すると、レジスタ７２０は、読み出しを受け付けることができる（すなわち、信号情報が可視的となり、信号遷移又は信号遷移が検出されなかったことについての必要なデバッグを実行することができる）。一実施形態において、レガシーシステムでは、レガシーテストアクセスポートを使用して、物理的な接続を行い、レジスタ情報を読み出す。一実施例では、このような読み出しは、ヒューズによってマスクされる又は保護されることなく、管理容易性エンジン（ｍａｎａｇｅａｂｉｌｉｔｙ ｅｎｇｉｎｅ）又はテストポートがイネーブルされた後であればいつでも実行可能であってもよい。別の実施形態では、レジスタ７２０へのアクセスは、本明細書に記載されるような検証アーキテクチャによって提供及び制御される。例えば、検証制御ユニット（ＶＣＵ）は、レジスタに対する抽象化された安全なアクセスを提供することができる。ここで、ソフトウェアは、ＡＰＩを使用して情報を要求することできる。そしてＶＣＵは、レジスタ７２０から情報を読み出し、それを要求元のソフトウェアに提供することができる。本明細書に記載するように、レジスタ７２０の替わり、又は、組み合わせにより、システムメモリをＯＤＬＡのトレースバッファとして使用することについて上記で説明したように、取得された情報をシステムメモリに配置してもよい。

上記では、電力投入の間の制御ハブ内の信号のトレースを取得することに注目して説明がなされた。しかしながら、本明細書に記載する、初期信号のトレースを取得する装置及び方法は、これに限定されない。実際には、デバイスのテストモジュールがイネーブルされる／準備が整う前の、あらゆるシリコンに同様に適用できる。例えば、同様な装置を、プロセッサ６４０又はスモールファクターデバイスに埋め込まれたプロセッサに実装して、関連付けられたテスト／検証ユニットがイネーブルされる前に、信号情報を取得できる。

図８には、電力シーケンスの最初における信号情報の取得方法を示したフローチャートの一実施形態が示されている。フロー８０５において、電力投入イベントが発生する。電力投入イベントは、電力信号のアサート（又はアサート停止）のように単純なものであってもよい。別の例では、情報の取得が、電力投入信号に応答して発生するが、実際の情報取得の開始は、介在する信号の遷移に依存する。例えば、制御ハブの内部信号は、電力投入信号に応答して遷移してもよい。そして、信号情報の取得は、介入する内部信号に直接応答して開始されてもよい。ここで、電力投入イベントには、電力信号、内部信号の遷移又はその両方が含まれてもよい。

フロー８１０では、電力投入の初期状態の信号情報（テストユニットがイネーブルされる前に遷移する可能性がある信号についての情報）が取得される。上記したように、あらゆる周知の装置又は方法を使用して、このような情報を取得してもよい。例えば、電力イベントが発生すると情報を取得するべくプリセットされる単純化されたＯＤＬＡを使用できる。別の例として、上記したような情報取得ロジックを使用してもよい。装置及び方法に関わらず、フロー８１５では、所定の条件が発生すると情報の取得が中止／停止される。所定の条件には、例えば、所定時間／サイクルの経過、対象の信号の遷移が一定期間検出されない、対象の最後の信号が遷移した時、対象の最後の信号が一定期間遷移しなかった時、特定のウェルがイネーブルされた時、テストロジックがイネーブルされた時、プログラムが情報の取得を停止するように指示した時、その他の周知の所定の起動イベントが含まれる。

フロー８２０において、テストポートが利用可能となる。例えば、管理容易性エンジン(ｍａｎａｇｅａｂｉｌｉｔｙ ｅｎｇｉｎｅ)テストアクセスポートが、ブートプロセスの間にイネーブルされる。別の例として、ＶＣＵは、以下に説明されるように、ユニバーサルアクセスポートと共にイネーブルされる。テストポートがイネーブルされると、フロー８１０で取得された信号情報が読み出されてもよく、読み出しは、抽象化層を介す又は直接テストデバイスに読み出されるといったように、安全な態様で行われてもよい。そして、ソフトウェア又はデバッガは、問題又は対処すべき事項が発生したかを判断することができる。その結果、内部信号の可視化を通常提供するロジックをイネーブルする前のような、ブートプロセスの初期の段階での信号遷移を、このような一体化したハードウェアフックを有さないデバッグを行う従来の方法と比較して、安価にそして多大な労力を費やすことなく、効率的に監視及びデバッグすることができる。

上記したような初期の電力投入信号を取得するＤＦｘ機能に加えて、一実施形態では、非常に低い電力ドメインにおける信号軌跡を取得するのにフックを組み込んでもよい。図９には、低電力状態の対象の信号取得のためのロジックの一実施形態が示されている。

電力ステートは、製品に固有のものとして規定されることが多いが、一実施形態では、電力ステートは、電力ステートのＡｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ ｉｎｔｅｒｆａｃｅ（ＡＣＰＩ）種のような、様々な電力規格におけるあらゆるステートを指す。プロセッサの場合、ＡＣＰＩ規格では、３つの基本的なステートが規定されており、Ｃ０（動作／アクティブ状態）、Ｃ１（命令は実行されないが実行ステートへ戻ることはできる、中断（ｈａｌｔ）状態）、Ｃ２（ソフトウェア可視ステートが維持されるがウェイクアップには時間掛かる場合がある、ストップクロック状態）及びＣ３（プロセッサがキャッシュコヒーレントを保たないが、その他の状態は維持する、スリープ状態）である。また、これらのステートの変形も考えられている。例えば、エンハンストＣ１ステートは、低消費電力の場合に使用できる。Ｃ３／スリープの変形は、深いスリープステート（すなわち、より深い又は最も深いスリープステートＣ６）を含み、処理要素が起きるまでにより長い時間を必要とする。これらの電力状態は、単なる例に過ぎず、プロセッサを参照するのに主に使用される。しかしながら、同様なステートは、制御ハブのようなその他のデバイスのためのＡＣＰＩ規格に規定されている。

図に示されるように、デバイス９００は、プロセッサ、制御ハブ、グラフィックスデバイス又はその他の周知のコンピュータ関係デバイスを含んでもよく、低電力状態（すなわち、上記の例で言う動作状態のＣ０ステート以外のあらゆるステート）の間の対象の信号９０１−９０６を取得するロジックを含み。ロジックの第１段階（ライブ取得９２０）は、信号９０１−９０６の生の（ｌｉｖｅ）トレース／値を取得する。例えば、タイミングチャート９７０には、クロック信号９１０に基づく信号９０６の取得が示されている。デバッグイネーブルのようなイネーブル信号を、デバッグモードでない時にクロック９１０を制限する（すなわち、ゲートクロック９１０が段階９２０、９３０をフロップする）のに使用してもよい。図に示されるように、第２段階（格納された値９３０では、電力周期信号９２５で示されるような電力サイクルの開始時に、信号９０１−９０６のそのままの（生の）状態を取得する。例えば、ＰＣＨでは、電力周期信号は、特定の所定のピンのアサート（アサート停止）に応答して生成される。ここで、ブートでない状態の場合には、検証を行うエンジニアは、ピンを切り替えて、システムをリブートする。したがって、このシナリオでは、信号９０１−９０６の最近のバージョン／ステータスが取得され格納される。図示の例では、ブートが成功すると、格納される値９３０は、タイミングチャート９７０に示されるように、最近のブート（起動）に失敗した状態の間の信号９０１−９０６のステータス９５０を保持する。

ロジック９００の動作を例示する具体的な例を提供するため、デバイス／システム９００の５回のブート（起動）を試みると仮定する。第１ブートでは、イネーブルビットが設定されて、ロジックを作動可能な状態にする。ここで、レガシーＪＴＡＧ又はその他のテストインターフェースを使用して、イネーブルビットを設定してもよい。別の実施形態では、ＶＣＵが、イネーブルビットを設定する。第1ブートが成功したと仮定すると、電力周期信号９２５が低（ｌｏｗ）となり、信号９０１−９０６のステータス（状態）が取得される。第２ブートが成功すると、ステータスは、全て１つ論理値を指す（１つ前のブートの成功及びイネーブルビットが作動可能な状態になっている）。しかし、第３ブートに失敗すると、システムは、リスタートされる。この場合、電力周期信号が、例えば、高（ｈｉｇｈ）−低（ｌｏｗ）−高（ｈｉｇｈ）とトグルされ（切り替えられ）て、電力周期信号９２５が低（ｌｏｗ）の時に信号９０１−９０６のステータスが取得される。第４ブートにも失敗したと仮定すると、システムは、同様な態様でリスタートされる。続いて、第５ブートは成功すると、ステータス９５０は、最近の失敗したブートの試み（第４ブート）における信号９１０−９０６のトレース／ステータスを報告する。上記したように、ステータス９５０は、レガシーテスト機器によって読み出されてもよい。または、別の実施形態では、階層化されたテストアーキテクチャを実装するＶＣＵを使用して、ロジック９００へのアクセスを提供及び制御する。

上記した説明の多くが、プロセッサの検証情報を取得することに関してなされ、一部の説明には、ＰＣＨのような制御ハブの信号の状態を取得することについて触れた。しかしながら、ＤＦｘフックはこれらに限定されず、プラットフォームを介してその他の領域に実装されてもよい。上記で簡潔に触れたその他の領域は、電力に関係するハードウェア及び電源供給ネットワークのテスト、検証及びデバックのためのハードウェアフックを提供する。例えば、周波数昇降ロジック又は電圧対時間測定ロジックは、電源供給ネットワークの特性（インピーダンスプロファイルを規定する及び／又は共振周波数を特定する）を明らかにすることができると考えられる。または、測定ロジックを電圧調整器（ＶＲ）によってマザーボードに挿入して、必要な電流量、消費電力、ノイズ等を測定してもよい。

さらに、本明細書に説明されるＤＦｘ及び検証アーキテクチャは、実験室での検証に限られない。ＤＦｘ機能は、プロセッサ、制御ハブ、マザーボード又は大量生産用（ＨＶＭ）試験機器と結合するその他のデバイスに組み込まれてもよい。その結果、周知のＨＶＭテストは、以下に説明するように、ユニバーサルアクセスポートを介してルートされてもよい。製造側は、一実施形態において、安全な階層化された検証アーキテクチャによって、製造側のテストを行う者に、高いアクセス権限（すなわち、含まれるＤＦｘ機能の大部分又は全てに対する低階層のアクセス）を与える。

複数の製品にテストアーキテクチャを提供することにより、プロセッサ、マザーボード等の製品全部にわたって製造欠陥を診断（クロスプロダクト検証）してもよい。テスト結果を階層化されたテストアーキテクチャを介して提供し、複数の製品について比較をソフトウェアによって行うことにより、欠陥及び歪みを容易に特定することができると考えられる。例えば、何千個ものプロセッサを、ＶＣＵ及び階層テストアーキテクチャを介してＤＦｘにアクセスするＨＶＭによってテストしてもよい。そして、テスト結果をソフトウェア／プレゼンテーション層に集めて、ソフトウェアが情報を分析して、歪み、欠陥等の表示可能な情報にまとめることができる。

別の例としては、以前のマザーボードの診断は、専用の外部テスタを使用して、複数のオンボードのテスト点をテストする、回路内プローブテスト（回路基板テスト（ＩＣＴ））に依存していた。フォームファクターが小さくなり、テスト点を形成するのに高いコストが掛かるようになり、ＩＣＴをサポートし続けるのは難しくなっている。したがって、一実施形態では、ＶＣＵ及び高レベルのソフトウェアに対して提供されるＡＰＩ等の本明細書に記載されるテストアーキテクチャを、複数のデバイスにわたる総合的な診断を提供するのに利用する。

以前は、プロセッサ及びチップセットのようなデバイスの欠陥ではなくマザーボードの欠陥であるのに、デバイスが返品（無欠陥返品）されてしまっていたこともあったが、本明細書に記載されるＩＣＴを必要としない簡単なテスト方法により、このような返品を避けることができる。例えば、外部ＩＣＴデバイスを使用する替わりに、ＤＦｘを構築し、ＶＣＵ及びＡＰＩを介してＤＦｘのサポート（アクセス及び制御）を提供することにより、テストのコストの３０％を削減できると考えられる。

［検証制御部の実施形態］
一実施形態では、本明細書に記載したようなハードウェアテスト、検証及びデバッグフックのようなＤＦＸ機能へのアクセス及び制御を提供するために、検証制御ユニット（ＶＣＵ）が設けられる。ＶＣＵは、あらゆるハードウェア、ファームウェア、ソフトウェア、コード、マイクロコード、又はこれらの組み合わせを含み、制御及び／又はアクセスを実装してもよい。図１０には、１以上のＶＣＵを有するプラットフォームの例の一実施形態が示されている。図に示されるように、プラットフォーム１０００は複数のＶＣＵを含み、プロセッサ１０１０内に１つ、そして、プロセッサ１０７５内に１つ含まれている。このシナリオでは、ＶＣＵは、複数のデバイス（プロセッサ、制御ハブ、グラフィックスデバイス、マザーボード又はその他の周知のコンピュータデバイス）内に含まれていてもよい。そして、各ＶＣＵは、対応するシリコンＤＦｘ機能へのアクセス及び制御を担ってもよい。ここで、ＶＣＵ１０１２のようなＶＣＵは、プロセッサ各々に備えられ、プロセッサ１０１０のＤＦＸ機能（アーキテクチャ的及びマイクロアーキテクチャ的ＤＦＸ１０１５、ＯＤＬＡ１０３及びＰＣＵ１０１４）へのアクセス及び制御を提供することができる。プラットフォーム１０００内の複数のシリコンデバイスに分布させることにより、個別の部分のテスト（例えば、ここのパーツのＨＶＭテスト）及びプラットフォームのテスト／デバッグ（例えば、複数のパーツがプラットフォームに一体化されており、システム全体の分析と共にシステムにおける個々のパーツの性能を分析する場合に有用である）を行う際に、ＤＦｘ機能へのアクセス及び制御を可能とする。

一例では、このように分配されたＶＣＵの実装形態によって、ＶＣＵは、互いに通信可能となる。この通信を、プラットフォーム１０００におけるＶＣＵ１０１２とＶＣＵ１０８０とを結合させるＶＣＵ相互接続（図示せず）を使用して、この接続を直接行ってもよい。これに替えて、ＶＣＵ１０１２及びＶＣＵ１０８０のようなＶＣＵは、対応するデバイス（プロセッサ１０１０及びＰＣＨ１０７５）と結合する既存の相互接続（接続１０６５、例えば、ダイレクト・メディア・インターフェース（ＤＭＩ）、クイックパスインターフェース、ＰＣＩ−Ｅインターフェース又はその他の周知の接続を含む）を介して通信を行ってもよい。これに替えて、ＶＣＵは、共有メモリスペースを介して互いに通信を行ってもよい。例えば、ＶＣＵ１０１２は、オペレーティングシステムからは難読化（抽象化）されているが、ＰＣＨ１０７５／ＶＣＵ１０８０のようなその他のシステムデバイスには可視化されているメモリ部分１０２１に書き込みを行う。その結果、ＶＣＵ１０８０は、ＶＣＵ１０１２によって書き込まれた情報を読み出すことができ、また、その反対も可能である。具体的な例として、検証アーキテクチャにアクセスするのに統合ポートが提供されている場合には、ＶＣＵ間の相互接続／通信を使用して、プラットフォーム全体のＤＦｘ機能へのソフトウェアアクセスを調整する。これついては、以下に詳細に説明する。また、その他の問題についても検出を行い、ＶＣＵ間の通信及び／又は管理容易エンジン（ｍａｎａｇｅａｂｉｌｉｔｙ ｅｎｇｉｎｅ）によって対処してもよい。その他の問題としては、例えば、ライブロック（ｌｉｖｅｌｏｃｋ）、デッドロック、パッチロード同期、電力／性能ステート遷移同期、生存性、トリガ及びトレース設定、ダンプデータのポストコレクション、セキュリティ、及び、取得／報告の範囲が挙げられる。

上記の説明は、主に、プロセッサ、制御ハブ及びマザーボードといった各パーツにおけるＶＣＵの分配についてなされたが、このような分布が必ずしも必須ではない。これに替えて、１つのＶＣＵを、プロセッサ１０１０又はＰＣＨ１０７５のような１つのデバイスに配置してもよい。そして、そのＶＣＵが、デバイスのＤＦｘフックへのアクセスを制御すると同時に、プラットフォームのＤＦｘフックへのアクセスを制御してもよい。さらに、ＶＣＵを分配する実装形態が利用される場合、ＶＣＵは、対照的である必要はない。この場合、シリコンパーツは異なる場合もあることから、ＶＣＵが異なって配置されてもよい。加えて、１以上のＶＣＵが、高い優先順位を有していてもよい（例えば、ヘッドホーム又はマスタＶＣＵが、システムにおけるその他のＶＣＵによるアクセス及び制御を調整する）。これに替えて、各ＶＣＵを、通信マスタと考えてもよい。

一実施形態では、ＶＣＵ１０１２は、プロセッサ１０１０のＤＦｘ機能へのアクセスを制御するプログラム可能エンジン又はユニットを含む。例えば、ＶＣＵ１０１２は、マイクロコントローラを含む。マイクロコントローラは、多くの場合、自身の処理要素、メモリ（フラッシュ、プログラム可能ＲＯＭ、ＳＲＡＭ又はその他の周知のメモリデバイス）及び通信インターフェースを有するデバイスを含む。基本的に、マイクロコントローラは、プロセッサ１０００に埋め込まれる又は内包される小さなコンピュータとして見なすことができる。したがって、処理要素によって実行されると、高階層の方向ではソフトウェアに、下階層の方向ではＤＦｘ機能に、インターフェースを実装する自身のコード／マイクロコードを有してもよい。また、以下に詳細に説明するが、マイクロコントローラを更新して（認証されたパッチ又はアップデートを介してパッチされたメモリに保持されるコードの制御及び動作）、その他の層（ソフトウェア又はＤＦｘ機能）のテスト、検証アーキテクチャにおける変更に適応する新しい機能を提供してもよい。そして、変更を、プラットフォームのＤＦｘ機能又は高階層のソフトウェアに反映させ、ハードウェア（又は、パーツ全体）を交換することなくＶＣＵを適用できるようにする。

マクロコントローラを含むＶＣＵの説明は、純粋な例示に過ぎない。同様なデバイスが、ＤＦｘ機能へのアクセスの同様な制御を行い、高階層の層への同様なインターフェースを提供してもよい。例えば、プログラム可能アレイロジックデバイス、汎用アレイロジックデバイス、複雑なプログラム可能ロジックデバイス、フィールドプログラム可能ゲートアレイデバイス等のプログラム可能ロジックデバイスを使用することができる。また、図では、ＶＣＵ１０１２が、プロセッサ１０１０において１つの論理ブロックとして描かれている。しかしながら、ＯＤＬＡがプロセッサ１０１０全体にわたって分配されてもよいように、ＶＣＵ１０１２の部分も、プロセッサの１０１０のダイ又はパッケージの異なる部分に渡って分配されてもよい。

ＤＦｘ機能の一部とのＶＣＵ１０１２の相互作用の例が、以下に記載される。ＶＣＵ１０１２は、プロセッサ１０１０のレジスタを制御するべく結合されたメッセージチャネルのような、オンコアインターフェース１０１１におけるチャネルへのアクセスを有する。また、ＶＣＵ１０１２は、スキャンアウト信号及びヒューズのようなスキャン信号へのアクセスを有する。したがって、ＶＣＵ１０１２は、様々なマイクロブレークポイント始動イベント（シナリオ）をプログラムすることができ、ＯＤＬＡ１０１３にトレースをメモリ１０２０（又は、オペレーティングシステムからは隠匿されたメモリ１０２１の一部分）に格納するよう指示し、メモリ１０２０に格納されたトレースを抽出し、トレースを高レベルのソフトウェア（例えば、デバッグツール）に届ける。加えて、ＶＣＵ１０１０は、どのＤＦｘ機能にアクセスさせるかを、現在のセキュリティ（アンロック）レベルに応じて制御できる。一実施形態において、ＶＣＵ１０１０は、プロセッサ１０１０のＤＦｘ機能へのアクセスプログラムできるツールを有するＡＰＩを公開させる。

一実施形態では、より高いレベルのソフトウェアから見る場合に、ＤＦｘ機能のハードウェア詳細を分かりにくくさせる又は抽象化させる抽象化層のような、以下に詳細に説明する検証階層アーキテクチャの１以上の層を実装する役割を、ＶＣＵ１０１２が担う。抽象化層が使用されるか否かに関わらず、一実施形態において、ＶＣＵ１０１２は、ＤＦｘ機能への安全なアクセスを提供する役割を担い、これについては、以下の検証基板セキュリティの実施形態の章で詳しく説明する。

図１１には、ＶＣＵを使用したソフトウェアからのＤＦｘ要求に応じる方法を示したフローチャートの一実施形態が描かれている。フロー１１０５では、アプリケーションプログラミングインターフェース（ＡＰＩ）に従って、第３者のベンダーからの、テスト及びデバッグプログラムのようなソフトウェアプログラムの実行に応答して、ＤＲｘ要求が生成される。ここで、ＤＲｘ要求は、ＶＣＵによって提供されるサービス及びルーチンと相互作用するべく提供されているＡＰＩの規格及び規則に準拠してもよい。すなわち、ソフトウェアプログラムは、ＡＰＩによって認識される呼び出し規則のような、ＡＰＩによって規定される"ボキャブラリー"に沿って、書かれていてもよい。

フロー１１１０において、ＤＦｘ要求は、ＶＣＵによって実装されるＡＰＩを使用して解釈される。ここで、ＡＰＩは、ソフトウェアとＤＦｘハードウェアとの間のインターフェース又はファシリテータ（仲介役）として動作する。一例として、ＶＣＵマイクロコントローラのメモリに格納されるコードのような、ＶＣＵに格納されるコードは、ＤＦｘ要求に応答して実行される。このシナリオでは、ＶＣＵに格納されているコードとして、ライブラリ、ルーチン、データ構造、オブジェクトクラス、プロトコル等を含んでもよい。ここで、ＤＦｘ要求が、ＶＣＵにおけるルーチンの呼び出しを含み、ＶＣＵにおけるルーチンの実行により、ＤＦｘハードウェアと関連付けられた幾つかの機能／動作が実行されるものと仮定する。

一実施形態において、以下に詳細に説明するように、ＶＣＵは、ＤＦｘハードウェアへのアクセス（セキュリティ）を制御する。したがって、フロー１１１５において、セキュリティレベルに基づいて、そのＤＦｘ要求が許可されるか否かが判断される。セキュリティについては、以下で詳細に説明するが、単純化した例として、この時点で、ＶＣＵの例示的動作が係属すると仮定する。一例として、ＶＣＵは、安全な（ｓｅｃｕｒｅ）アクセスの複数のレベルを含み、各アクセスレベルは、ハードウェアＤＦｘへの異なる複数のアクセスのレベルを許可する。例えば、各レベルが、暗号化されたパスコードに関連付けられていてもよい。ソフトウェアプログラムが実行を開始するとそのセキュリティレベルを開錠する安全なパスコードが提供され、それによりソフトウェアプログラムがアクセスできる機能が指定されてもよい。そして、フロー１１１５では、ＶＣＵによって予め規定されたアクセスのレベルに従って、ＤＦｘ要求が、ソフトウェアプログラムと関連付けられたセキュリティレベル内で許されるものか否かの判断がなされる。ＤＦｘ要求が許可されない場合は、フロー１１２０において、適切に対処（拒否、実行を行わない、例外処理を実行等）してもよい。

反対に、ＤＦｘ要求が許可される場合は、フロー１１２５において、ＤＦｘ要求が受け付けられる。上記の例の続きであるが、ＤＦｘ要求が、ＡＰＩによって規定されるサービスルーチンの呼び出しを含む場合には、ＶＣＵは、サービスルーチンを実行する。ここで、サービスルーチンには、上記のような、ハードウェアＤＦｘ機能を設定、開始又はやりとりを行うあらゆるルーチンが含まれてもよい。例えば、ＶＣＵは、プロセッサに始動イベントを発生させ、ＯＤＬＡにブレークポイントにおいてトレースを取得させる、マイクロブレークポイント始動イベントを設定してもよい。そして、フロー１１３０において結果（トレース）が抽出されてもよく、例えば、ＯＤＬＡによってトレースバッファとして利用されているメモリへと書き出す。そして、フロー１１３５において、結果がソフトウェアプログラムに提供される。このシナリオでは、ソフトウェアプログラムは、後の解釈／デバッグのためにトレース情報を取得するべく、メモリの読み出しを行うことができる。図１２に示すように、フロー１２０５において、テストアーキテクチャへの変更が決定される。変更には、アーキテクチャのあらゆる層への変更が含まれてもよく、例えば、ＤＦｘハードウェアへの変更、ＶＣＵがどのように別のＶＣＵと関わるかについての変更、ＶＣＵがどのようにＤＦｘハードウェアと関わるかについての変更、ＶＣＵによって提供されるサービスの変更、セキュリティレベル（各々が何に対してアクセスできるか）の変更、ＡＰＩ規格における変更等が含まれる。フロー１２１０において、ＶＣＵは、テストアーキテクチャへの変更が反映されるように更新される。ここで、パッチ、認証されたパッチ又は更新を、ローカルに又はリモートで適用して、変更に対応するべくＶＣＵコードを更新してもよい。その結果、ＶＣＵレベル又は階層化された積層構造における下の層において何か変更があっても、製造側は、ＶＣＵソフトウェアの更新を提供するだけでよい。この例において、ＡＰＩのみが高レベルのソフトウェアに明らかとなることから、第３者のベンダーは、ベンダーのソフトウェアプログラム又はツールを更新する必要がない。ＡＰＩは同じ状態としたまま、テストアーキテクチャにおける変更を反映する更新に基づいて、ＶＣＵのアクションが修正される。その結果、テストアーキテクチャの積層構造に僅かな変更がある場合、階層構造の全ての層を修正する必要がないため、支出（ハードウェアを再設計又は取り替えるコスト）及び時間を余分に費やさなくて済む。

［検証階層構造アーキテクチャの実施形態］
上記でも示唆したように、一実施形態において、テスト、検証及びデバッグのアーキテクチャは、階層化された積層構造に実装される。テストアーキテクチャの階層化された積層構造の一実施形態が、図１３に示されている。図示されている層は、単なる例に過ぎない。その他の層を含めてもよいし、図示されている層のうちの何れかを省略してもよい。さらに、抽象化層１３１５のような図示された層の１以上を実装するロジックの例、例えば、ＶＣＵも、一例に過ぎず、図示される複数の層は、ロジック、ハードウェア、ファームウェア、コード、マイクロコード、ソフトウェア又はこれらの組み合わせに実装されてもよい。

一実施形態において、積層構造１３００は、ハードウェアＤＦｘの実装詳細を難読化する。抽象化層１３１５（サービス層）は、このようなハードウェアＤＦｘ詳細を抽象化するべく提供されると同時に、クライアント層（アプリケーション層１３２０及びプレゼンテーション層１３２５）とのインターフェースを提供する。図示するように、アプリケーション層１３２０に提供されるインターフェースは、複数のＡＰＩ（ＡＰＩ１３１６、１３１７及び１３１８）を含む。

ＡＰＩは、一般的には、アプリケーション層１３２０のようなソフトウェア層が、提供されるサービスの使用及びサービスへのアクセスのために順守する規則及び規定の特定のセットのことを指す。基本的に、ＡＰＩは、異なる層（のソフトウェア、ファームウェア又はハードウェア）間のインターフェースを提供し、異なる層間のやり取りを容易にしている。コンソール、ツール、ソフトウェア、オペレーティングシステム、ライブラリ、アプリケーション又はＡＰＩと結合する又はプログラミングするその他の周知の構造を含んでもよい層１３２０及び層１３２５によって、ＡＰＩはアクセスされてもよい。具体的な一例として、ＡＰＩは、サービス、ルーチン、機能、データ構造、オブジェクトクラス、プロトコル又はその他の周知のＡＰＩ関係の構成概念を含む。

１つのＡＰＩを使用してもよいが、図示する実施形態では、異なる複数のＡＰＩが、抽象化層１３１５によって提供される異なるサービス、ルーチン及びデータ構造へのアクセスのために提供されている。例えば、ＡＰＩ１３１６は、セキュリティ（以下に詳細に説明する）及び低階層の詳細事項の抽象化のために、アプリケーション層１３２０によって使用されるコアサービス及びデータ構造を提供してもよく、それにより、世代間のツールの変更を減らすことができる（異なる抽象化層１３１５のサービス及び／又は異なるＤＦｘ特長を有する次世代のプロセッサにおいても、同じＡＰＩと結合するべく同じツールを使用できる）可能性がある。

また、ＡＰＩ１３１７及び１３１８のようなその他のＡＰＩは、その他のサービス、データ、構造及び抽象化を提供してもよい。一例として、ハードウェアＤＦｘは、層１３１５によって提供される唯一の抽象化ではない。ここで、ＡＰＩ１３１７及び１３１８は、電子検証（Ｅｌｅｃｔｒｉｃａｌ Ｖａｌｉｄａｔｉｏｎ：ＥＶ）、電源供給、管理容易性、セキュリティ、アクセス、又はその他の周知のテスト、検証又はデバック関連の柱と関連付けられたサービス及びデータ構造を提供する。以前は、製造側は、電子検証（ＥＶ）アルゴリズムのような特定のアルゴリズムが、クライアント層に存在するツールによって使用されないように保護していた。現在では、アルゴリズムは提供されない、又は、アルゴリズムのサブセットのみが提供されるようになっており、ＥＶに対するサブスタンダードのベンダーツールとなっている場合が多い。

一実施形態では、ＡＰＩ１３１７は、ＥＶの支柱となるＡＰＩを含み、高レベルの層１３２０、１３２５におけるツール／ソフトウェアによって使用されるこの様なアルゴリズムの完全なセットの抽象化を提供する。したがって、アルゴリズムは、安全な態様（ＴＰＶツールには見えない態様）で提供されてもよく、それにより、良好なＴＰＶテストツールとすることができると同時に、機密のアルゴリズムを、機密状態に抽象化して保つことができる。ＥＶ固有のＡＰＩの柱の例は、あらゆる個別のテスト、検証及びデバッグに関連付けられ、ハードウェア、ファームウェア、ソフトウェア、コード、アルゴリズム、プロトコル等を抽象化するＡＰＩの柱から推定されてもよい。さらに、柱に固有のＡＰＩサービスモジュールを提供することにより、モジュールの更新が容易になる可能性がある。例えば、ＥＶに関連付けられている何かを修正し、更新しようとする場合、コアサービス又はその他のＡＰＩモジュールを更新することなく、ＥＶ ＡＰＩ１３１７を実装するＶＣＵマイクロコントローラに格納されているＥＶコードのパッチの更新が実行される。

上記の例では、ＡＰＩに関しては、抽象化層１３１５及びクライアント層（アプリケーション層１３２０及びプレゼンテーション層１３２５）の間のインターフェースについて、主に説明された。しかしながら、下層に対して、低層の詳細を難読化する、抽象化する又はぼやかすインターフェースを提供するあらゆる周知の装置又は方法を使用してもよく、ソフトウェア／ハードウェアに実装されるそのようなハードウェア又はアルゴリズムを実装してもよい。また、抽象化層１３１５の例は、上記したように、ＶＣＵマイクロコントローラによって実装される。ここで、ＶＣＵマイクロコントローラのメモリデバイスに格納されるコードのように、ＡＰＩ１３１６−１３１８を実装するロジック及び／又はコードは、ＶＣＵに組み込まれる。別の実施形態では、抽象化層１３１５のためにＡＰＩを実装するコード、サービス及びデータ構造は、メモリに保持され、被試験プロセッサのような被試験デバイスによって実行される。

図示するように、積層構造の最も下層には、目的のＤＦｘ層１３０５が含まれ、ＤＦｘ層は、上記したハードウェア機能／フックのような周知のＤＦｘ機能を含んでもよい。また、ＤＦｘ層１３０５は、レガシーテスト／検証機能も含んでもよい。したがって、ある実施形態では、直接アクセス１３５０により、層１３０５内のハードウェアＤＦｘ機能の幾つかに直接アクセスすることが可能となってもよい。別の例では、目的のＤＦｘ層１３０５は、プロセッサ、ＰＣＨ、グラフィックスデバイス、マザーボード又はその他の電子デバイスを含む被試験ユニットを含む。

トランスポート層１３１０は、特定のトランスポートビークルで実行するべく、抽象化層１３１５によって提供されるサービス及びルーチンからのタスクのような情報を適合させるが、サービス及びルーチンは、転送（トランスポート）メカニズムに依存しない（すなわち、どのようにサービス／ルーチンがＤＦｘ層１３０５へと輸送されるか把握しない）。例えば、トランスポート層１３１０は、抽象化層１３１５から情報を取得し、その情報を、層１３０５へと輸送するべく適切なパケット／情報に適合させる、トランスポートハードウェア及び関連するドライバを含む。ここで、輸送媒体としては、プラットフォーム内の相互接続、ポートを介してプラットフォーム又はデバイスへとコンソール／テスタを結合する接続、ホストマシーンにおける層１３１５と離れた場所に位置する非試験ユニットにおける層１３０５との間のリモートアクセスのためのネットワーク、又は、イン・ターゲット・プローブ（ＩＴＰ）デバイス、規定されているデバッグポート、第３者のベンダー（ＴＰＶ）トランスポートデバイス等のその他の周知のテストテスト関連デバイスが含まれる。

ネットワークの例から推定できるように、積層構造１３００の１以上の層を、様々なマシーン及び／又は構成要素に実装してもよい。例えば、目的の層１３０５は、残りの積層構造の１以上の層を実装するホストプラットフォームとリモートで接続される被試験プラットフォームを含んでもよい。別の例としては、クライアント層は、サービス層及び目的の層１３０５を実装する被試験プラットフォーム又はその一部にリモートでアクセスするホストシステムに実装される。リモートアクセスについては、以下の検証アーキテクチャアクセスの実施形態で詳細に説明する。

クライアント層は、ＤＦｘ層１３０５の低階層の詳細を抽象化する抽象化層１３１５及び／又は目的の層１３０５におけるＤＦｘ機能と結合するための、あらゆるツール、コンソール、アプリケーション又はその他のエンティティを含んでもよい。抽象化層１３１５との結合が、ＡＰＩ１３１６−１３１８のような１以上のＡＰＩを介して行われる場合、ピラー（ｐｉｌｌａｒ）固有のＡＰＩモジュールの規定及び規則を含む、規定及び規則に従って、ＡＰＩと結合する／ＡＰＩにプログラムされるように、アプリケーション層１３２０は設計されている。さらに、上記したように、新しい世代の製品が供給されたとしても、クライアント層と抽象化層１３１５との間のＡＰＩ通信規格が同じである限り、クライアント層のツールを新しいバージョンのものに替える必要がない。その替わり、新しい製品（目的のＤＦｘ層１３０５）に対して新しい態様で同じサービスを提供するべく抽象化層を更新する。また、第３者のレガシー及び非サービスアプリケーションを、製造者の付帯品と共に、クライアント層内の１以上のツールソリューションに一体化してもよい。

プレゼンテーション層は、下層のデータ及びプロトコルを相関させる、可視化させる及び／又は表示するツール又は別のエンティティと一体化されていてもよい。この場合、ＤＦｘテストから最終結果を第３者が望むような態様で得られるように第３者の好みの設定によって、これらのツールが設計されていてもよい。この例では、アプリケーション層１３２０は、提供されるサービス及びルーチンを使用して、抽象化層１３１５をプログラムする。層１３０５におけるテストの結果又は層１３１５におけるアルゴリズムの出力のような、これらのサービス及びルーチンからの結果は、アプリケーション層１３２５に渡される。アプリケーション層は、このデータを、解釈（デバッグ）して、人に又はツール解釈のためにデータを表示するプレゼンテーション層に渡す。

図１４には、階層化されたアーキテクチャの積層構造を介してＤＦｘ機能にアクセスする方法を示したフローチャートの一実施形態が示されている。フロー１４０５では、第３者のベンダーツールのようなアプリケーションが、抽象化層にプログラムする。ここで、ツール又はその他のエンティティが、抽象化層と関連付けられたＡＰＩによって規定される抽象化層からのサービスを要求／利用する。そして、フロー１４１０において、そのようなサービスが提供される。ここで、サービスが、抽象化層内のローカルなアルゴリズムを含む場合、情報／データ構造は、アプリケーション層に提供されてもよい。

一方、サービスが、ＤＦｘ機能又は目的の被試験デバイスとの下層との通信を含む場合には、フロー１４１５において、高いレベルのトランスポート方法を問わない積層構造（抽象化層及びアプリケーション層）からの情報が、トランスポートに適用される。例えば、この適用は、抽象化層からの情報を、テストポートプロトコル、相互接続プロトコル、ネットワークプロトコル又はインターネットプロトコルのようなトランスポートプロトコルにフォーマットすることを含む。フロー１４２０において、適用されたフォーマットの通信データが、抽象化層によって要求されたオペレーションを実行する被試験ＤＦＸユニットにトランスポートされる。上記で説明したようなあらゆる周知のＤＦｘオペレーションが実行されてもよい。フロー１４２５において、結果がアプリケーションに供給され、フロー１４３０において、プレゼンテーション層によって結果が解釈される。

上記に説明したフローの１つの典型例の続きとして、テスト及びデバッグツールが、プロセッサのような被試験ユニットに、マイクロブレークポイントをプログラムするように要求し、マイクロブレークポイントに至るまでに、マイクロブレークポイントにおいて又は後に、トレースが取得されると仮定する。この例において、アプリケーションは、アプリケーション層によって提供されるサービスを呼び出してもよい（フロー１４０５）。抽象化層は、呼び出されたルーチンを実行し、ルーチンは、マイクロブレークポイント定義及び積層構造体におけるトレース収集方向を送信することを含む（フロー１４１０）。トランスポート層は、マイクロブレークポイント定義を適用し、テストポートを介してトランスポートされるべきパケットにするといったように、トランスポートからの収集をトレースする（フロー１４１５）。生成されたパケットは、プロセッサに送信される（フロー１４２０）。それに応答して、マイクロブレークポイントが、プロセッサの制御レジスタに設定され、トレース情報が要求に応じて収集される。ここで、データの返送には、積層構造を上方向に戻るパス（ｐａｓｓ）が含まれてもよく、抽象化層を通過してアプリケーション層に戻るパスを含んでもよい（フロー１４２５）。別の例として、トレース情報は、トレースバッファとして使用されるメモリに格納されてもよい。アプリケーションは、メモリからトレース情報を読み戻すことができる（フロー１４２５）。トレース情報を使用して、プレゼンテーションツールは、データを解釈するシミュレーションにおいてプロセッサのトレースを再現することができる（フロー１４３０）。ここで、抽象化層より下の機能へのアクセスのし易さが確保されている、すなわち、アプリケーションからのロックが解除されていない機能へのアクセス要求、又は、アプリケーションのセキュリティ／権限のレベルを超える機能へのアクセスは、拒否されてもよい。このようなセキュリティ強化構成について、以下に説明する。

［検証アーキテクチャに対するセキュリティの実施形態］
上記したように、テスト、検証及びデバッグアーキテクチャの１つの目的として、設計者又は製造者が、明らかにしたくないと望む低いレベル（階層）における詳細を抽象化（難読化）することが含まれる。しかしながら、一実施形態において、このような詳細の抽象化又は難読化は、"セキュリティ"の観点では十分でない場合がある。もし、抽象化層のみが使用されるとすると、抽象化層ＡＰＩとの通信方法が決まれば、エンドユーザーを含め誰でもテストアーキテクチャにアクセスできてしまう。したがって、一実施形態では、テストアーキテクチャへのアクセスは、安全な状態に保たれる、すなわち、認証されていない高階層の層からの要求は、許可されない。

図１５には、テストアーキテクチャへの安全なアクセスを提供するロジックの一実施形態が示されている。ここで、上記でアプリケーション層又はプレゼンテーション層を参照して説明したエンティティの何れを含んでもよいアプリケーション又はコンソール１５１５は、パスコード１５２０を含む。鍵とも称されるパスコード１５２０は、機能への安全な又は鍵のかけられたアクセス、又は、アクセスのレベルを提供する周知のあらゆる形式の値を含む。最初のやり取りで、又は、要求に続くやり取りで、アプリケーション１５１５は、ＶＣＵ１５０７によって実装されるＡＰＩインターフェースのようなインターフェース１５３０を介して、自身のパスコード１５２０を抽象化層に提供する。ここで、アプリケーション１５１５のトポロジーが、論理的にＵＵＴ１５０５から分離されて示されているが、これは例示に過ぎない。替わりに、ＵＵＴ１５０５は、アプリケーションを実行してもよい。ＶＣＵ１５０７は、このシナリオでは、ＵＵＴ１５０５にアクセスするホストシステム／コンソールとして見なされるデバイス１５１５に実装されてもよい。

物理的実装形態に関わらず、抽象化層がパスコード１５２０を受信する時、ＵＵＴ１５０５の汎用レジスタ、制御レジスタ又はモデル固有レジスタ（ＭＳＲ）のような、格納要素１５１０に格納されているパスコードとアプリケーションパスコードとの比較に基づいて、抽象化層は、アプリケーション１５１５にアクセスの程度を提供する。一例として、アクセスのレベルが１つのみ存在するとする（フルアクセス又はアクセスなし）。ここで、アプリケーションパスコード１５２０が、格納要素１５１０保持されているパスコードと一致する場合、アプリケーション１５２０は、ＶＣＵ１５０７によって実装される抽象化層に提供されている全てのサービス（関連するＤＦｘ機能へのアクセス）を利用してもよい。これに替えて、パスコードが提供されていない又は一致しない場合には、アプリケーション１５１５からの抽象化層への要求は、満たされない／許可されない。

一実施形態では、セキュリティの複数のレベルが提供される。例えば、設計者は、異なる顧客又はベンダーについて、アルゴリズム、プロトコル、データ構造、ＤＦｘ機能等への異なるアクセスレベルを付与したいと考える場合がある。そして、設計者／製造者は、抽象化層がＤＦｘ機能及び関連するＵＵＴをテスト、検証及びデバッグするべく抽象化するＤＦｘ機能の低いレベルの詳細への制限されないアクセスを有することを望む。同様に、設計者／製造者は、抽象化層内に完全なアクセスを提供してもよい。

図示されている実施形態では、格納要素１５１０は、パスコードの３つのレベルを保持する。パスコードの１つ（パスコード１５１１）は、レベル０アクセス（ＤＦｘ機能への自由な又は制限のほとんどないアクセス）を提供する製造者パスワードである。パスコード１５１２で表されている第２のレベル（レベル１）は、テストアーキテクチャへの一部選択的／制限されたアクセスを提供する。そして、パスコード１５１３で表されている第Ｎのレベルは、テストアーキテクチャへのより選択的に制限されたアクセスを提供する。ここで、パスコード１５１２が第３者のベンダー（ＴＰＶ）に供給されるように、パスコードはそれぞれ、安全に供給される。このように、ＴＰＶツールを設計する時には、パスコード１５２０としてパスコード１５１２を組み込む又は利用することができる。したがって、アプリケーション１５１５が認証プロセスを通過する時に（パスコード１５２０を、ＶＣＵ１５０７によって実装される抽象化層又はセキュリティそうに提供する時に）、テストアーキテクチャにレベル１アクセスが提供される。この場合、レベル１アクセスは制限されている。したがって、セキュリティレベル（ＤＦｘ機能又は制限されている実装詳細へのアクセス）内でないアプリケーション１５１５からのアクセスは、ＶＣＵ１５０７によって拒否される（許可されない）。

図１６には、テストアーキテクチャにおける安全なアクセスを提供するフローチャートの一実施形態が示されている。フロー１６０５において、アプリケーションのアクセスレベルが決定される。一実施形態において、アプリケーションとテストアーキテクチャのアクセスレベルとを関連付けるのに、あらゆる周知の認証プロセスが使用される。別の例では、上記したようなパスコード検証プロセスを使用して、アプリケーションのアクセスレベルを決定する。この決定は、アプリケーション（プログラム開始時の一般的な認証）実行の開始時点で行われてもよいし、特定の要求の発生時に行われてもよい。

フロー１６１０において、アプリケーションによって、サービス要求が抽象化層ＡＰＩに提供される。ここで、ＡＰＩへのサービス要求は一例に過ぎず、要求には、あらゆるサービス要求又はＤＦｘ機能へのアクセス要求が含まれてもよい。フロー１６１５において、要求の種類又は形式に関わらず、決定されたアクセスレベルに基づいて、要求されたサービスが許可されるか否かが判断される。このシナリオでは、特定のサービス、アルゴリズム、プロトコル、ＤＦｘ機能等は、規定されたセキュリティアクセスレベルに従って、許可可能又は制限されるとして予め定められる。したがって、要求が、アプリケーションの１つのアクセスレベル（又は、より多くのアクセスの１つのレベル）と関連付けられている場合には、フロー１６２５において、要求が許可され、フロー１６３０において（サービスの一部分が）被試験ＤＦｘユニットにトランスポートされる。反対に、要求が、アプリケーションのアクセスレベル内でない場合には、フロー１６２０において許可されない。

［検証アーキテクチャへの物理的アクセスの実施形態］
上記したように、ハードウェアテスト機能へのアクセスは、コンピュータプラットフォームの至るところに存在する複数の結合及び接続されていないポートにわたって、分配されている。これにより、プラットフォームをテストするための接続か、煩雑で高価（様々なポートが存在し、これらのポートを接続するのに異なるツールが必要）なものとなっている。したがって、一実施形態では、複数のプラットフォームテストインターフェースの替わりに、ユニバーサルテストアクセスポート（ＵＴＡＰ）が提供されている。図１７には、プラットフォームにおけるテストアーキテクチャのためのＵＴＡＰの一実施形態が示されている。

プロセッサ１７１０ａ−ｄは、クイックパスインターコネクトのような相互接続１７５０により共に接続されている周知のプロセッサを含み、ＰＣＨ１７７０は、ダイレクト・メディア・インターフェース（ＤＭＩ）のような相互接続１７６５を介してプロセッサ１７１０ｃと結合されている。図示されるように、ＶＣＵ１７１２ａ−ｅは、テスト接続又はその他の周知のインターフェースのような相互接続１７９０で通信を行うことができる。しかしながら、別の実施形態では、上記したように、ＶＣＵは、相互接続１７５０、１７６５を介して通信を行うことができる。その結果、このシナリオでは、ＶＣＵ１７１２ａ−ｅは、互いに通信するように適応され、これにより、ＵＴＡＰ１７８５のような１つの統合されたポートを介して、プラットフォーム１７００のＶＣＵテスト機能にアクセスすることができる。ここで、ＶＣＵ１７１２ａ−ｅは、協働してやり取りを行うことができる。または、ＵＴＡＰ１７８５からのメッセージを好適な意図したＶＣＵへとルートすることができる。

一実施形態において、ＵＴＡＰ１７８５はデバッグ情報を（プロセッサと関連付けられたメモリ又はＶＣＵから）抽出し、ＶＣＵ１７１２ａ−ｅと通信を行う双方向ポートを含む。一例として、ＵＴＡＰ１７８５は、専用テストポートを含む。別の実施形態では、ＵＴＡＰ１７８５は、既存のインターフェース（例えば、ユニバーサル・シリアル・バス（ＵＳＢ）インターフェース、シリアルアドバンストテクノロジーアタッチメント（ＳＡＴＡ）インターフェース、又は、その他の周知のインターフェース）又は二重に使用できる将来のインターフェースのような別のインターフェースを、抱き合わせする。

図示されているトポロジーは、一例に過ぎない。あらゆる数のプロセッサが含まれてもよい。また、ＰＣＨが含まれなくてもよい。加えて、ＵＴＡＰ１７８５は、コンソール、コンピュータ又はテスタのような外部デバイスを結合する物理的なポートを含んでもよい。別の例として、ＵＴＡＰは、ネットワークインターフェースデバイス（例えば、ＮＩＣ）又はホスト又はリモートシステムとの通信を制御する（リモートシステムに関しては、以下でより詳細に説明する）。ここで、制御部は、ベースボード管理制御部（例えば、温度、ファンの速度、電源のステータス等のシステムパラメータを報告する、マザーボードに埋め込まれた埋め込みマイクロコントローラ）を含んでもよく、プラットフォーム１７００とのリモート通信を容易にしてもよい。

ユニバーサルテストポートを提供することにより、プラットフォームのテストを（コスト及び複雑性の両面において）単純化することができる。しかしながら、プロセッサのような個別のパーツの現在のテスト場所には、非効率性も存在する。例えば、典型的なプロセッサは、プロセッサの底面側にテスト及び検証用のピンが設けられ、ピンが限定されることから、パッケージ基板が大きくなりコストも高くなっていた。このようなコストを低減させるために、フックのテスト及びデバッグを大幅に省いていた。その結果、顧客がデバッグしきれなかった部分でエラーが発生し、製造者に返品となってしまう場合があった。

したがって、一実施形態では、集積回路（ＩＣ）パッケージ基板（例えば、プロセッサ、制御ハブ等）の電子部品等が装着されていない上面の領域、例えば、基板の周辺領域等を利用して、テスト及び／又は検証用のピンの一部又は全てを配置する。一例として、これらのピンは、パッケージ基板の外側の金属層にエッチングされて、ソルダレジストによって露出される。

図１８には、大量生産用の接続メカニズムの一例における集積回路パッケージの一実施形態が示されている。この例では、ＩＣは、上側テスト及びデバッグピン１８６５を含むＣＰＵパッケージ１８６０を含む。これらのピンは、関連する使用目的に応じて、様々な方法で接続することができる。使用目的が検証及びトラブルシューティングである場合には、圧縮型のコネクタ機構を使用してピンにアクセスしてもよく、コネクタ機構は、コネクタを直接パッケージ基板に配列させるアライメント機能を含んでもよい。これにより、最大限の許容差を得ることができ、ピンの大きさ及び接続システムを可能な限り小さくすることができる。これらの構造には、多くの場合、ソケット１８５０に受け入れられ合致する構造が含まれ、上面のコネクタとＩＣ１８６０の基板とを接続させることができる。

ＨＶＭ接続シナリオのような、図示の接続シナリオでは、二枚貝のような形状のヒンジ固定部１８２０を含み、それにより、ポゴピン（プローブピン）型の接続のようなＩＣ固定プローブ１８３５を、上面ピン１８６５と接続することができる。そして、ＩＣ固定プローブワイヤ１８１０により、固定プローブ１８３５がコンソール／テスタ１８０５に接続される。その結果、二枚貝ヒンジ１８２０によって、接続メカニズムを開いた状態とすることができ、新たなパーツが挿入され、ヒンジ１８２０が閉じると、テスタ１８０５と上面テスト／デバッグピン１８６５との間の接続がなされる。様々な大量生産テストの利用の場合において、このようなパッケージ上面のピンの接続速度は、最小の許容"打ちつけ速度（ｂｅａｔ ｒａｔｅｓ）"に維持され、接続方法は、図１８に示されるような自動化及び／又は高効率のメカニズムの一種が使用される。

同様にマザーボード１８４０の接続も図示されており、マザーボード固定ワイヤ１８２３は、テスタ１８０５とＭＢ固定プローブ１８２５とを接続する。また図示するように、ベースプローブ１８３０は、マザーボード１８４０のベースに接触している。図示されている二枚貝ヒンジ１８２０は、一例に過ぎず、プローブ、テスタ、ソケット、ＨＶＭツール等のためのあらゆる周知の接続シナリオを採用してもよい。更に、同様なメカニズムを、コントローラハブ又は周辺デバイスのようなその他のＩＣに対して使用してもよい。

図１８には、インテグレーテッド・ヒート・スプレッダ（ＩＨＳ）１８７０が示されており、一実施形態では、ＩＨＳは、上面ピン１８６５を設けるための領域を作り、その領域において固定プローブ１８３５との接続を可能としている。図１９には、上面試験ピン及びプロービングをサポートする目立たない搭載のための機能を有するヒートスプレッダ（放熱板）の一実施形態が示されている。この例では、パッケージ１９０７上の集積回路１９０５は、ＩＨＳ１９１０と関連付けられている。一実施形態において、ＩＨＳ１９１０は、目立たない程度に突出した"搭載耳部"１９１１を含む。図では、搭載耳部１９１１は、直接ソケット搭載（ＤＳＬ）メカニズム１９２０のように、ソケットの搭載メカニズムを可能とするような、ソケット作動搭載点を提供する。このような設計を採用することにより、上面を占める面積を小さくすることができ、上記のような検証のための信号ピン／パッドのためのスペースをより多く確保することができる。

搭載耳部１９１１の外側の、ＩＨＳ１９１０の外周部には、ＩＨＳ１９１０の外縁に沿った連続的又は非連続的な小さな段が設けられていてもよい。別の例では、外縁は、段を有さなくてもよい。耳部１９１１が図のように搭載される時、パッケージ１９０７がソケットに押し付けられて、ソケットが作動し、ソケットとデバイスパッケージとの間の電気的な接続がなされる。耳部の数は、アプリケーション毎の特定の搭載点の数に依存する（図では２つの耳部が示されているが、これに限定されない）。さらに、耳部１９１１が、図では所定のアプリケーションの搭載点の下（例えば、真下）に位置しているが、ＩＨＳ１９１０の真ん中に必ずしも位置する必要はない。耳部１９１１は、多くの場合（常にではない）、ＩＨＳ１９１０における搭載メカニズムによって印加される力が、ＩＨＳ１９１０／パッケージ１９０７を中心に封じ込めるのに十分な作動力となるような位置に配置される。一実施形態において、搭載耳部１９１０は、搭載メカニズムの搭載ゾーンを完全に覆う特定の長さを有する。例えば、提案されるＩＨＳ耳部は、ＤＳＬ搭載プレート１９２０の搭載長を覆う１ｍｍから５０ｍｍの範囲の長さを有する。ＩＨＳ１９１０組み立ての間に、ＩＨＳシーラントを、耳部１９１１の下に配置して、耳部１９１１を曲げることなく、搭載力をパッケージ１９０７に移動させることができる。

従来の典型的なＩＨＳは、負荷が十分に分散させてソケットを電気接続させるための始動力となるように、周辺部の９０％に搭載の段が設けられていた。これに対し、上記のような搭載耳部を設けることにより、同じ搭載プロセスを、外縁に設けられた少ない数の段を使用して達成することができるので、ＩＣの上面において、テスト／デバッグのためのピン配列及びプロービングのための領域をより広く確保することができる。また、広くなった空間を利用することにより、ＩＨＳ１９１０は、多くの負荷が掛かるＩＨＳ１９１０の部分に位置する目立たない搭載耳部１９１１を有する選択的な形状の棚部を有してもよい。例えば、ＤＳＬ搭載プレート１９２０は、ＩＨＳ１９１０における段の小さな部分に接触する。したがって、耳部１９１１は、ＤＳＬプレート１９２０が負荷を掛ける場所に戦略的に配置される。その結果、新たに確保された何も設けられていない空間を利用することにより、パッケージサイズを大きくすることなく又はＩＨＳ１９１０の放熱領域を小さくすることなく、新たな上面テストピンを設けることができる。

放熱に関して、現在の熱マージンを持たせる設計は、大型化しており、大きな面積が使用されてしまい、信号の信頼性を保つためのマージンが小さくなってしまっている。したがって、図２０には、熱的マージンを提供するよう設計されたスモールファクター熱的ツール（ＳＦＦＴＴ）設計の分解図の一実施形態が示されている。ある実施形態では、このようなマージン化もＤＦｘ機能の１つと考えてもよい。ＳＦＦＴＴ２０００は、次のような１以上の構造を含む。ミニバルク熱電クーラー（ＴＥＣ）アレイ２０２５の下部に半田付けされたカスタム冷却板２０１０、液体金属熱インターフェース材料（例えば、Ｇａ−Ｓｎ液体金属材料）を介して未にバルクＴＥＣアレイ２０２５の上面に取り付けられたマイクロチャネル冷却技術を有する水冷器２０４０、均一な水流の分配を提供する固有チャネル設計されている水冷器２０４０のカバー、デバイスの中心部において、水の流入・流出（流入２０５０及び流出２０６０）、制御部に対するワイヤ・ハーネス・アセンブリ、制御部に温度のフィードバックを提供する冷却板２０１０の中心に埋め込まれたＴ型の熱電対、ＴＥＣクラッキング対策のために水冷器２０４０と冷却板２０１０との間に設けられるスペーサ２０２０、実験用回路基板２０３５を使用してワイヤのストレスを軽減するＴＥＣ２０２５のケーブル管理、及び、温度スイッチのような構造が挙げられる。

このような構造は、ＳＦＦＴＴに対して有益な構成を与えうる。例えば、マイクロチャネル冷却技術を採用した水冷器２０４０では、ダイヤモンドフィン技術の設計よりも、効率的に冷却できる。水冷器のカバーの固有のチャネル設計と共に、流入口と流出口（２５０、２６０）とをＳＦＦＴＴ２０００の中心に配置させることにより、中心からブロックへと冷やされた水を流入させ、温められた水は冷却器の側面を通過させることができるため、冷却のチャネルの長さは、その他のダイヤモンドフィン型の設計と比較して半分で済む。その結果、ＴＥＣ２０２５及び被試験シリコンによって生成される熱により典型的に最も熱が集中する中心部に、最も冷却できる領域を配置させることができる。そして、最終的には、水冷器における温度差を３℃ほど減少させることができ、温度分布が均一になるため、ＴＥＣ２０２５の信頼性が高まる。別の例では、冷却板２０１０をミニバルクＴＥＣ２０２５に取り付けることにより、熱抵抗の層を低減させることができる。さらに、水冷器２０４０と冷却板２０１０との間のスペーサ２０２０は、バルクＴＥＣの場合に生じるＴＥＣ２０２５のクラッキングの問題を防ぐことができる緩衝メカニズムを提供する。実験用回路基板２０３５を使用したケーブル管理は、ワイヤ（配線）ストレスを緩和し、ＴＥＣのリード線の故障率を低減させることができる。

更に説明するため、上記の構造の詳細例を以下に記載する。第１の例として、ミニバルクＴＥＣアレイ２０２５は、最大放散温度が７５℃、設置面積が１５ｃｍ２の最大３９ｍｍ×３９ｍｍの大きさの領域を含む。さらに、アレイ２０２５に、いかなる数のＴＥＣが接続されてもよい。一実施例として、１１個のＴＥＣの２つの組が直列に接続され、別の１１個のＴＥＣの２つの組が並列に接続される。水冷器２０４０のマイクロチャネルフィン設計は、ダイヤモンドフィンの円形の冷却パターンではなく、垂直方向（又は水平方向）の冷却チャネルを提供する。チャネル／フィンは、いかなるサイズであってもよい。例えば、フィンは、高さが２ｍｍ、幅が０．３ｍｍ、そして０．３ｍｍの間隔で設けられたものであってもよい。水冷器２０４０の様々な設計のシミュレーションの一例において得られた性能の概要が、表１に示されている。

同様なシミュレーションで、マイクロチャネル水冷器技術によれば、速度分布及び温度分布が改善されることが確かめられている。この改善により、同様な温度マージン（５℃−１００℃）を提供すると同時に、従来の熱マージンデバイスと比較して、ＳＦＦＴＴのサイズを４０−５０％小さくすることができる。さらに、フォームファクターが小さくなることにより、ボード上の占有面積を小さくすることができ、それにより、チップ同士を近接して配置できるようになることから、信号品質（ＳＩ）マージンを改善することができる。ＳＩマージンにおける改善により、全てのマーケットセグメントのトレンドが、製品の小型化を加速させると考えられる。また、水冷器のカバーにおける固有のチャネル設計により、均一な水流分布を提供でき、それにより、ＴＥＣの信頼性を向上させることができる。さらに、障害部分を分離し、製造者及びベンダーのポストシリコンデバッグ／検証活動の一部として漏れを低減できることから、故障検出の速度を上げることができると考えられる。ベンダーが温度のマージン化の能力を備えることにより、製造者は性能における競争力をつけることができる。また、ベンダーによる検証で発見された事項は、製造者が電気的検証をより効率に行うために有用な情報となり得る。そして、よりエンドユーザーに優しい製品を提供することが可能になると考えられる。

［検証アーキテクチャへのリモートアクセスの実施形態］
以前は、製造者は、多大な資源（時間、人員及び資金）を費やして、ベンダーがデバッグするのを援助していた。実際に、ベンダー自身で、発生した問題のテスト及びデバッグを行えない場合には、製造者／設計者は、ベンダーの工場に検証を行うエンジニアを派遣していた。部品及びプラットフォームの複雑さが増し、検証及びデバッグのプロセスはベンダーにとってさらに難しいものとなり、製造者にとっても煩雑なプロセスとなってきている。したがって、一実施形態では、検証アーキテクチャは、テスト、検証及び／又はデバッグプロセスを助けるリモートアクセスを可能とする。

図２１には、被試験ユニットへのリモートアクセスの一実施形態が示されている。上記したように、テストアーキテクチャ積層構造が、複数のマシーン（及びネットワーク）にわたって実装されてもよい。ここで、リモートホスト２１０５は、上記したような、ツール２１０６（テスト、検証及びデバッグツールを有するアプリケーション層）及び抽象化層２１０７を含む／実装する。層２１０６、２０１７からの伝達情報は、リモートインターフェース、ネットワークインターフェース、周辺機器インターフェース等の周知のインターフェースを含むインターフェース２１３０を介して提供される。一実施形態では、このような伝達情報は、周知の暗号化アルゴリズム２１５０に従って暗号化される。さらに、別の実施形態では、トランスポートに、ＶＰＮ暗号化２１１０が使用される。このシナリオでは、ローカルホスト２１１５（すなわち、リモートホスト２１０５とある態様で結合されるホスト）は、トランスポート方法を感知しない層２１０６、２１０７をトランスポートのために採用するべく、トランスポート層２１１６を被試験ユニット（ＵＵＴ）２１２０に実装する。したがって、上記したテスト、デバッグ、検証及びセキュリティオペレーションは、リモートホストから被試験ユニットのインターフェースに実装されてもよい。

図２２を参照して、被試験テストにリモートアクセスする別の実施形態を説明する。この例では、リモートホスト２２０５は、３つの層（２２０６、２２０７及び２２０８）を含み、被試験ユニット（ＵＵＴ）２２２０との暗号化されたチャネルを介した直接通信を行う。例示されたレイアウトとは異なり、リモートで被試験ユニットとインターフェースするべく、あらゆる結合又はレイアウトを実装してもよい。また、チャネルの設定に、あらゆる認証プロセスを利用してもよい。セキュリティプロトコル（上記したようなプロトコルと同様な）を利用して、様々なレベルのアクセスを検証してもよい。その結果、ベンダー又は製造者は、ユニットに物理的に結合することなく、リモートで、デバイスのテスト、検証又はデバッグを行うことができる。このように、検証を行うエンジニアを物理的にベンダーの工場に派遣することなく、リモートでテスト／デバッグに関連する時間及び費用を大幅に低減させることができる。

［収集情報管理の実施形態］
フックのテスト、検証及びデバッグの実施形態の章で説明したように、プロセッサ、制御ハブ又はその他のデバイスのＯＤＬＡは、一実施形態では、トレース情報のようなオンダイ及び／又はインターフェース情報を収集することができる。メモリをトレースバッファとして使用するといったように、あらゆる態様で情報を伝達してもよい。あるいは、以下で詳細に説明するように、ロジックは、サイドバンド通信バスのようなインターフェースを介して、このようなデータを提供してもよい。そして、情報が、管理（フォーマット、操作、解釈、デバッグ等）のためのツールに提供される。

また、上記したように、パーツを収集及び分析する外部の解析装置を使用するのは複雑でありコストがかかる。例えば、ＰＣＩｅインターフェースのような複雑なインターフェースのプロトコル解析装置は、５０，０００ドルもの値段になる場合がある。高速シリアルインターフェースを介したインバンドメッセージングの一部のように、レガシー信号が統合されるにしたがい、マザーボード上で情報が簡単に利用できなくなってきる。そこで、図２３には、ＪＴＡＧ又はＳＭＢｕｓのようなサイドバンドバス上で、トレース情報をホストシステムに提供するロジックの一実施形態が示されている。取得されるレガシーインバンド信号の例には、ＴＲＤＹ２３２１、ＩＮＴＲ２３２２、ＳＭＩ２３２３及びＳＴＰＣＬＫ２３２４が含まれる。この例では、ＰＣＨ２３２０におけるＯＤＬＡ２３３０は、上記の信号のトレースを取得する。ホストシステム２３６０又は埋め込み制御部２３４０（例えば、抽象化層を実装するＶＣＵ）の指示によるピンの切り替え、ブレークポイントイベントの設定等のイベントに応答して、トレースを取得してもよい。制御部２３４０は、信号についてデータを取得し、それを、サイドバンドバス２３５０を介してホストシステム２３６０に提供する。一例として、このデータの形式としては、対応する信号が、高い状態を保っているか、低い状態を保っているのか、切り替わるのか、切り替わる方向又は切り替え頻度を示す情報を含む。この例では、データを処理する埋め込み制御部２３４０、及び、観察する様々な内部信号を選択するＯＤＬＡ２３４０の機能により、ハードウェアに変更を行うことなく、デバッグ能力を更新することができる。

図２４には、内部観察トレース（ＩＯＴ）データを管理する方法を示すフローチャートの一実施形態が示されている。フロー２４０５において、システムでテストが実行される。例えば、上記したようなテストを、被試験ユニットに実行してもよい。そして、ＯＤＬＡ（オンチップロジック分析器又はＯＣＬＡとも称される）のようなロジックから、ＩＯＴデータが取得される。ＩＯＴデータは、複数のストリーム／ソース（例えば、メモリ、Ｉ／Ｏ、オンコアインターフェース等）を含んでもよい。

フロー２４１０において、ＩＯＴデータがダンプされる。例えば、被試験ユニットと関連付けられているメモリを、ＩＯＴデータのためのトレースバッファとして使用する。しかしながら、ＩＯＴデータを扱う／解釈するコンソール又はホストシステムのようなシステムにデータをダンプ／提供するのに、周知のいかなるインターフェースを利用してもよい。

フロー２４１５において、ＩＯＴデータからトレースデータを再構築して、再生を可能にする。トレースを再構築する及び／又はトレースデータをフォーマットするあらゆる周知の方法を利用してもよい。図２５には、トレースの構築の一実施例が示されている。この例では、ＩＯＴデータの形式がデコードされる。あるシナリオでは、ＩＯＴデータは、特定の規定された形式の複数のストリーム／ソースを含む。フロー２５０５において、このような形式に従ってＩＯＴデータがデコードされる。一例として、ＩＯＴデータに対してソースが特定される。そして、フロー２５１０において、ソースによって、ＩＯＴデータが、分離されグループ化されて、収容（ｂｕｃｋｅｔｅｄ）される。

各ソースに対するモジュール（サービス）、例えば、メモリソースＩＯＴデータに対するメモリモジュール、プロセッサトレースＩＯＴデータに対する内部プロセッサモジュール、クイックパス（Ｑｕｉｃｋｐａｔｈ）インターフェースＩＯＴデータに対するクイックパスモジュール、オンコア相互接続の環状トラフィックのためのオンコアモジュール等はフロー２５１５、２５２０において、対応する各ソ−スに対するトランザクションを再構築する。さらに、一実施形態では、フロー２５２５において、モジュールは、再構築されたトレースデータを、再生するためにフォーマットし直す。図２４に示すように、フォーマットされ再構築されたトレースデータが再生される。その結果、再生によって、検証及びデバッグのための被試験ユニットのオペレーションに対する洞察を提供することができる。

その結果、デバックに掛かる時間及びコストを低減させることができ、製品開発サイクルを増加させることができる。また、再生することにより、ソフトウェアメカニズムは、上記のテストアーキテクチャのような同一の又は同様なＤＦｘの方法を含む製品に対するエミュレーション環境において、バグを再生することができるようになる。エミュレーション環境において、このようなバグを再生することで、被試験システム内におけるシステムの全振る舞いを完全に可視化できるようになり、デバッグを早く行うことが可能となる。そして、ロジック及び経路の境界性（ｍａｒｇｉｎａｌｉｔｙ）についてのバグを解消の一助となる。また、同様な装置及び方法を使用して、大量生産用のテスト内容を開発してもよく、大量生産の場合の迅速で効率的なテスト内容を提供することができ、製品の安定性を高め、部分的に在庫管理を助けることから、コストを削減することができる。

図２６には、後処理の相違（ｄｉｖｅｒｇｅｎｃｅ）を検出する方法のフローチャートの一実施形態が示されている。上記したように、被試験システムでテストが実行される時（フロー２６０５）、データが収集され、全く同じテスト条件をエミュレーション／シミュレーション環境（上記の図２４−２５を参照して説明した同様な方法で動作する環境、フロー２６１０−２６２５）に再生するのに収集されたデータを使用することができる。このプロセスから、検証では、ハードウェアで実行されるテストとソフトウェアモデルにおけるテストとの間の違いを検出することができ、これらの違いが、相違（ｄｉｖｅｒｇｅｎｃｅ）と称される。後処理相違検出は、ＯＣＬＡを使用したＩＯＴのような、ＤＦｘハードウェア機能を活用して、システムの状態を保存する。テストが再生される時に、エミュレーションにおけるＩＯＴに格納されているデータ（再生ＩＯＴデータ２６３５）は、再生の後に処理されて、被試験システムから収集されたＩＯＴに格納されているデータ（収集済みＩＯＴデータ２６１５）と比較され、後処理相違検出結果２６４０が取得される（すなわち、データ２６１５と再生データ２６３５との間の違いが取得される）。実行には高価で特別なハードウェアが必要となることから、再生の間の実行時間はコストが掛かる。したがって、このような再生の間の相違を計算することは、費用の高い実行時間を費やすことになると考えられる。そこで、一実施形態では、システムメモリのような内部のロケーションに保存したシステムステートを使用し、再生段階が完了した後に、費用の高くないハードウェア上で別にデータを処理する。

図２７には、ＲＴＬデータ構造を高レベルの言語にアクセス可能とするフローチャートの一実施形態が示されている。被試験システムからトレースデータが収集される時、通常、収集された特定のデータフィールドが分析され、分析には、トレースからの修正を含む。ＲＴＬは絶え間なく変化するため、ＲＴＬ周辺に設計されたソフトウェアは、常に更新する必要がある。したがって、一実施形態では、ソフトウェアがリリースされる時（フロー２７０５）、ＲＴＬモデルは、ソフトウェアリリースの時点でスキャンされる（例えば、フロー２７１０において、ＲＴＬデータのスナップショットを取得する）。スナップショットから、ＲＴＬデータ種類が、例えば、ＸＭＬのような、より一般的な形式で記録される。この例では、フロー２７１５において、ＲＴＬデータ構造スナップショットデータベースがＲＴＬスナップショットデータから生成される。

ＲＴＬデータが格納される（すなわち、データベースが生成される）と、スナップショットＲＴＬデータ種類定義に基づいて、トレースデータパケットを読み出し、マスク及び修正するソフトウェアメカニズム／サービスが提供される。トレースがどのＲＴＬモデルに由来するのかに基づいて、読み込むスナップショットを選択することにより、重要度の低いＲＴＬ変更の影響をその他のソフトウェアに与えないようにすることができると考えられる。一例として、ソフトウェアが、そのＲＴＬモデルを使用してテストからのトレースデータを解釈又は修正する時（フロー２７２０）、ソフトウェアは、ＲＴＬデータ構造のデータベースを必要とし（フロー２７２５）、その情報をトレースデータ（フロー２７３０）のでコードに使用する。その結果、定常的なＲＴＬモデルに依存しソフトウェアを変更する替わりに、ＲＴＬデータ構造のための柔軟性の高い適応可能なテスト基盤（パケット及び信号形式のモデル）が提供される。

［電源検証の実施形態］
ロジックの数が増加し回路が小さくなるにしたがって、回路に発生する問題が急増している。回路のバグは、検出できない場合がある。また、高速でない経路の問題として回路の故障を再生可能とするような、良好な特性評価方法は現在のところ存在しない。そこで、一実施形態では、回路境界性検証（ｃｉｒｃｕｉｔ ｍａｒｇｉｎａｌｉｔｙ ｖａｌｉｄａｔｉｏｎ：ＣＭＶ）方法を利用して、高速でない経路及び高速の経路における問題を発見する。回路境界性の主要な要因には、オンダイ信号信頼性（クロスカップリングに起因するノイズ、ドループ（ｄｒｏｏｐ）イベントに起因するノイズ）、電力供給の信頼性（多くの場合、クロックの開閉に起因する高い続流の発生）、クロックドメインの交差（クロックの非同期）、及び、プロセス、電圧及び温度の変化（電力状態の遷移、シリコンプロセスの変化）が含まれる。

過去、数世代に渡るプラットフォーム検証管理製品分析に基づくと、送電網（ｐｏｗｅｒ ｇｒｉｄ）は、回路のマージン性の大きな要因となっている。そこで、一実施形態では、オンダイイベントに関係する送電網の空間的及び時間的特性評価及びデバッグを可能とする基盤であって、送電網性能とテスト及びシステムイベントとを相関付ける能力を含む基盤を提供する。

図２８には、そのような基盤の一実施形態が示されている。この例では、包括的で一体化された（オンダイ）アーキテクチャであって、時間ベースの空間的な制御及びオンダイ電圧調整を観察を可能とし、このようなイベントを確定的にテスト内容及びシステムイベントと相関付ける能力を有するアーキテクチャを提供する。図示されるように、アーキテクチャ２８１０は、ＶＣＵ２８１５によって実装されていてもよい（上記のような）抽象化層２８０５を介して、ホスト２８００と結合していてもよい。

アーキテクチャ２８００の構成要素には、高バンド幅オンダイ電圧ドループ監視機能（ＶＤＭ２８３０）及びドループ注入メカニズム（ＯＤＩ２８３５）（一実施形態では、これらの両方が、時間的及び空間的に構成されるように採用される）、クロック周期固有のテスト内容同期基盤、決定論的イベント始動及びクロック周期の正確な時間を監視する基盤（ＤＳＣ２８４０）（一実施形態では、これらの構成により、イベントのタイムスタンプ及び再生が可能となる）、イベントと相関するＶＲステート取得のためのＯＤＬＡのようなダイナミックオンダイ電圧制御ステート取得機能、設定可能ハードウェアベースのペイロード修正メカニズム（マイクロブレークポイントロジック２８３０）、修正メカニズムは、システムイベント、テストイベント、及び／又は所定の電力ドメイン又はユーザー／ホスト２８００の最良によるドメインにおける電力ステートの遷移において開始されてもよい。

アーキテクチャの機能に関する不完全なリストには、ＯＤＩ／ＶＤＭ／システム（Ｉ／Ｏ又はコア）イベントを、Ａ／Ｄサンプルを介したアナログ観察点のスナップショット及びステートマシーンイベントの動的スナップショットのような、オンダイ電圧制御間隔の観察と相関付ける機能、ハードウェアベースのペイロード変更を確定的に開始させる機能、ＯＤＩ及び／又はＶＤＭ始動イベントと内部ＶＲイベントとを同期させる機能、内部ＶＲイベントを中断させる機能、内部ＶＲイベントのタイムスタンプを取得する機能、電力管理コマンド問題と実際のＶＲ変化との間の遅延を監視する機能、ＶＤＭ／ＯＤＩ変化を観察する機能、インバウンドの現在の振る舞いと内部イベントとを相関付け、ギア比の変化及び電力分配の効果を観察して、デューティサイクルの検出間隔の計算を提供する機能が含まれる。

アーキテクチャのアプリケーション及びモードの不完全なリストには、送電網の特性解析、システムイベントベースの相関、及び、電力イベントベースの相関が含まれ、これらについては以下で例示される。送電網の場合、特性解析は、ユーザーが柔軟に選択できる、あらゆる方法で行われてもよい。基本的に、このオペレーションモードにある電圧監視回路は、時間軸で電圧を取得するように予め設定されている。電圧は、短時間の期間の間に、リング発振器の振動数を数えることで測定される。テスト又はその他のシステムの動作が行われている時に、特性解析サイクルの間全体におけるサンプルを比較することにより、所定の電力ドメインの局所的場所における最も高いピークと最も低い谷が取得される。ここで、特性解析は、システムが休止状態にある間、ブートサイクルにある間、テストの間、又は、あらゆるシステムイベントの間で実行されてもよい。特徴解析は、いかなる／全てのドメインと同時に行われてもよい。

システムイベントベースの相関の場合には、テストシーケンスの開始（又は、対象のシステムイベント）と送電網サンプリングの開始とを同期させるマイクロブレークポイント基盤を使用して、障害点又は巡回冗長検査（ＣＲＣ）障害（図示の例のような）のような特定のシステムイベントの発生点で、経過時間が取得される。そして、設定可能な態様でオンダイ電圧制御性能を評価するべく、テストシーケンスが確定的に再生され、所定の始動イベントの前、間、又は後に、所与のクロックサイクルを見ることができる機能も与えられる。アナログポイント及びステートデータのデータ収集は、時間における所定の瞬間に、又は、対象の始動イベントに基づく位置において、動的に取得されてもよい。その結果、始動イベント及びアクションが、電力制御ブロック、電力管理、又は、テスト／システム固有のイベントによって提供されてもよいといったように、多様な柔軟性をアーキテクチャに備えさせることができる。

電力イベントベースの相関の場合には、オペレーションは、システムイベント相関と同様である。マイクロブレークポイントのような基盤が、電圧制御回路と一体化することにより、ＶＤＭ２８３０を介した送電網のサンプリング及び／又はＯＤＩ２８３５を介したドループイベントの投入で、数多くのシステムイベントを開始することが可能となる。このモードにおける始動イベントは、一実施形態では、典型的には、特定の電力イベント又はステートで開始される。

本明細書で用いられたモジュールという言葉は、任意のハードウェア、ソフトウェア、ファームウェア又はこれらの組み合わせを意味する。別個のものとして図示されているモジュールの境界は、通常変わることが多く、重複する可能性もある。例えば、第１のモジュール及び第２のモジュールは、ハードウェア、ソフトウェア、ファームウェア又はこれらの組み合わせを共有しているとしてもよいし、独立したハードウェア、ソフトウェア又はファームウェアを持つとしてもよい。一実施形態では、ロジックという用語は、例えば、トランジスタ、レジスタのようなタスクを実行するべく組み合わせられる及び／又は構成されるハードウェアを含む。別の実施形態では、ロジックという用語は、プログラム可能な論理デバイス又はプログラム可能なロジックアレイのようなその他のデバイスを含む。しかしながら、更なる別の実施形態では、ロジックはまた、ハードウェアと一体化されたソフトウェア又はコード、例えば、ファームウェア又はマイクロコードを含む。

また、本明細書で使用されている"値"という言葉は、数、状態、論理状態又は２値論理状態のあらゆる既知の表現を含む。また、明細書で使用されている論理レベル、論理値、又は論理的値は、１又は０といった単純に２値論理状態を意味している場合もある。例えば、１は高い論理レベルを指し、０は低い論理レベルを指す。一実施形態では、トランジスタ又はフラッシュセルのような記憶セルは、１つの論理値又は複数の論理値を保持可能であってもよい。しかしながら、コンピュータシステムにおける値の他の表現が使用されてもいる。例えば、１０進数の１０は、２進値表示では、１０１０と表され、１６進数表示ではＡと表される。したがって、ある１つの値は、コンピュータシステムに保持される情報のあらゆる表示形式を含む。

さらに、状態（ステート）は、値又は値の一部によって表されていてもよい。例えば、論理値の１のような第１の値が、デフォルト状態又は最初の状態を表していてもよく、論理値の０のような第２の値が、非デフォルト状態を表していてもよい。加えて、リセット及びセットという言葉はそれぞれ、ある実施形態では、デフォルト値又は状態及び更新された値又は状態を指す。例えば、デフォルト値は、高い論理値、すなわち、リセットを含んでもよく、更新値は、低い論理値、すなわち、セットを含んでもよい。値のどのような組み合わせを、あらゆる数の状態を表すのに利用してもよい。

上記の方法、ハードウェア、ソフトウェア、ファームウェア、コードの実施形態を、機械アクセス可能な又は機械可読な媒体に記憶され、処理要素によって実効可能な命令又はコードを使用して実装してもよい。機械アクセス可能／機械可読な媒体としては、コンピュータ又は電子システムのような機械によって読み出し可能な形式の情報を提供する（すなわち、記憶及び／又は送信する）あらゆるメカニズムを含む。例えば、有形機械アクセス可能媒体には、スタティックＲＡＭ（ＳＲＡＭ）若しくはダイナミックＲＡＭ（ＤＲＡＭ）のようなランダム・アクセス・メモリ（ＲＡＭ）、ＲＯＭ，磁気的又は光学的記憶媒体、フラッシュメモリデバイス、電気記憶デバイス、光学記憶デバイス、音響的記憶デバイス、又は他の形態の伝播信号（例えば、搬送波、赤外線信号、デジタル信号）記憶デバイス等が含まれる。

上記した方法、ハードウェア、ソフトウェア、ファームウェア又はコードの実施形態は、機械可読媒体に格納されたコンパイラの実行によって、又は、コンパイラによってコンパイルされた機械可読媒体に格納されたコードの実行の一部として、実装されてもよい。コンパイラは、多くの場合、プログラム又はプログラムのセットを含み、ソーステキスト／コードを、目的のテキスト／コードへと変換する。通常、プログラム／アプリケーションコードをコンパイラを使用してコンパイルする場合には、高水準プログラム言語コードを、低水準機械言語コード又はアセンブリ言語への変換する複数の段階又はパスに分けて実行される。しかしながら、簡単なコンパイルには、単一パスのコンパイラを使用することもできる。コンパイラは、既知のコンパイル技術を利用して、字句解析、前処理、構文解析、意味解析、コード生成、コード変換及びコード最適化のような、既知のコンパイルオペレーションを実行してもよい。一実施形態では、コンパイラは、上記の方法を実行するべく、オペレーション、呼び出し、機能、命令等を挿入するコードをコンパイル及び／又は最適化する。

大きなコンパイラは、多くの場合、複数の段階を含み、これらの複数の段階は、主に大きく分けて２つの段階に含まれる。（１）フロントエンド、すなわち、通常、構文処理、意味処理及び幾つかの変換／最適化が実行される段階、（２）バックエンド、すなわち、通常、解析、変換、最適化及びコード生成が実行される段階の２つである。コンパイラの中には、ミドルエンドと呼ばれるものも存在し、これは、フロントエンドとバックエンドのコンパイラとの間の境界を曖昧にした例である。挿入、関連付け、生成又はその他のコンパイラのオペレーションの参照は、上述の段階又はパス、及びその他のコンパイラの段階又はパスのいずれかにおいて実行される。一実施形態では、このようなシナリオは、スタティック及び／又はプログラム全体のコンパイルの間に発生する。別の実施形態では、動的コンパイルの間に、コンパイラコード又は動的最適化コードが、このようなオペレーション／呼び出しを挿入すると共に、ランタイムの間の実行のためのコードを最適化する。あるシナリオでは、コンパイラプログラムのようなハードウェア又はソフトウェアが、プログラム実行の動的プロファイリングを実行してもよい。

また、本明細書における「一実施形態」又は「ある実施形態」という言葉は、実施形態に関連する特定の特徴、構造及び特性が、少なくとも本発明の実施形態の一つに含まれていることを意味する。したがって、本明細書中の様々な箇所で使用されている「一実施形態において」又は「ある実施形態において」という表現は、必ずしも同一の実施形態を示していない。また、１以上の実施形態において、特定の構成、構造又は特徴を、適切な形で組み合わせてもよい。

明細書の上記において、特定の例示された実施形態を参照して、詳細な説明がなされた。しかしながら、添付の特許請求の範囲に記載される本発明の範囲内において、様々な変形及び変更を加えることが可能であることは、明らかである。したがって、明細書及び添付の図面は、発明を制限するものではなく、発明を例示するものであると見なされるべきである。また、上記の実施形態及び他の例で使用された言葉は、同じ実施形態又は同じ例を必ずしも指している必要はなく、異なる及び別の実施形態を指している場合もあるし、同じ実施形態を指している場合もある。

Claims (14)

1. 集積回路に関連するテスト／トレース情報を取得するオンダイロジック分析器（ＯＤＬＡ）を含む前記集積回路と、
   前記集積回路と連結され、前記ＯＤＬＡによって取得された前記集積回路に関連する前記テスト／トレース情報を保持するテスト／トレースバッファとして使用されるメモリと、
   テスト／トレース情報を提供する１以上のハードウェアテストフックと、
   前記１以上のハードウェアテストフックを、ソフトウェア層に対して抽象化し、インターフェースを前記ソフトウェア層に提供する抽象化ロジックと
   を備え、
   前記テスト／トレース情報は１以上のオペレーティングシステムに対して難読化された領域のメモリに格納され、
   前記インターフェースは、前記１以上のハードウェアテストフックと関連付けられたサービスを提供する装置。
2. 前記集積回路は、前記集積回路のインターフェースのテスト／トレース情報を取得して、
   前記メモリは、前記集積回路の前記インターフェースの前記テスト／トレース情報を保持するためのテスト／トレース情報バッファとして使用される
   請求項１に記載の装置。
3. 前記集積回路は、プロセッサにおける１以上の制御レジスタと連結され、ブレークポイントを規定するべく前記１以上の制御レジスタを設定する検証制御部を有する前記プロセッサを内蔵して、
   前記１以上のＯＤＬＡは、前記１以上の制御レジスタが前記ブレークポイントを規定する場合に、前記プロセッサが前記ブレークポイントに遭遇するのに応答して、前記プロセッサに関連するテスト／トレース情報を取得する
   請求項１または２に記載の装置。
4. 前記集積回路は、
   前記集積回路に関連するテスト／トレース情報にアクセス可能なテストポートと、
   前記集積回路の電源ＯＮシーケンスの間に、前記テストポートがイネーブルされる前に遷移する信号の信号ステート情報を取得する初期電源ＯＮ信号ロジックと
   を更に有する請求項１から３のいずれか１項に記載の装置。
5. 前記集積回路は、
   集積回路の電源ＯＮ状態を示すべく遷移する電源ＯＮ信号と、
   前記電源ＯＮ信号の遷移に応答して、カウントを開始するカウントロジックと、
   対象の信号のエッジ遷移を検出するエッジ検出ロジックと、
   エッジ検出ロジックが前記対象の信号の前記エッジ遷移を検出する時に、前記カウントロジックのカウントに基づいて、前記対象の信号の信号識別値及びタイムスタンプ値を保持する格納要素と
   を更に有する請求項１から４のいずれか１項に記載の装置。
6. 前記集積回路は、アクティブ電力状態及び複数の低電力状態に存在して、
   前記集積回路は、前記複数の低電力状態のうちの１つの低電力状態と関連付けられている電力サイクルイベントに応答して、信号の信号ステート情報を取得する低電力信号ロジックを更に有する
   請求項１から５のいずれか１項に記載の装置。
7. 前記集積回路は、
   テストのための複数のハードウェア設計（ハードウェアＤＦＸ）機能と、
   前記複数のハードウェアＤＦＸ機能へのアクセスを提供するマイクロコントローラと
   を更に有し、
   前記マイクロコントローラは、実行されると、前記マイクロコントローラに、１以上のアプリケーション・プログラミング・インターフェース（ＡＰＩ）のアクセスを、前記複数のハードウェアＤＦＸ機能と関連付けられたサービスのソフトウェアに提供するコードを含む
   請求項１から６のいずれか１項に記載の装置。
8. 集積回路内のハードウェアテスト／トレース機能にアクセスすることに関連する要求を、アプリケーションから受信する制御部と、
   複数のアクセスレベルのうち、前記アプリケーションのアクセスレベルを決定するセキュリティロジックと
   を更に備え、
   前記アプリケーションのアクセスレベルが、前記ハードウェアテスト／トレース機能へのアクセスを有する場合には、前記セキュリティロジックは、前記アプリケーションからの前記要求を許可し、
   前記アプリケーションの前記アクセスレベルが、前記ハードウェアテスト／トレース機能へのアクセスを有さない場合には、前記セキュリティロジックは、前記アプリケーションからの前記要求を許可しない
   請求項１から７のいずれか１項に記載の装置。
9. 前記集積回路は、
   信号ピンを下面に、テストプローブと電気的に結合するテストピンを上面に有する集積回路（ＩＣ）パッケージ
   を更に有する請求項１から８のいずれか１項に記載の装置。
10. 前記集積回路は、
    信号ピンを下面に、テストプローブと電気的に結合するテストピンを上面に有する集積回路（ＩＣ）パッケージと、
    テスタ及び前記ＩＣパッケージの前記上面の前記テストピンと電気的に結合される固定プローブを有する大量生産用（ＨＶＭ）接続メカニズムと
    を更に有する請求項１から９のいずれか１項に記載の装置。
11. 集積回路パッケージと、
    前記集積回路パッケージに熱的に結合され、目立たない程度に突出した搭載耳部を有するインテグレーテッド・ヒート・スプレッダ（ＩＨＳ）と
    を更に有する請求項１から１０のいずれか１項に記載の装置。
12. 前記集積回路と熱的に結合する冷却板と、
    熱電冷却アレイと、
    マイクロチャネル冷却フィンを有する水冷器と、
    前記水冷器の中心部に設けられた流入口及び流出口と
    を有するスモールフォームファクター・熱的ツールを更に備える請求項１から１１のいずれか１項に記載の装置。
13. 集積回路内のハードウェアテスト／トレース機能を実装する目的の物理層と、
    抽象化層から前記目的の物理層へと、転送メカニズムを問わない情報を転送するトランスポート層と、
    前記目的の物理層を抽象化し、アプリケーション層に１以上のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する前記抽象化層と、
    前記１以上のＡＰＩの規格に従って、前記抽象化層からの、前記目的の物理層に関連付けられたサービスを要求する前記アプリケーション層と
    を備え、
    前記集積回路は、
    集積回路に関連するテスト／トレース情報を取得するオンダイロジック分析器（ＯＤＬＡ）と、
    前記集積回路と連結され、前記ＯＤＬＡによって取得された前記集積回路に関連する前記テスト／トレース情報を保持するテスト／トレースバッファとして使用されるメモリと、
    テスト／トレース情報を提供する１以上のハードウェアテストフックと、
    前記１以上のハードウェアテストフックを、ソフトウェア層に対して抽象化して、インターフェースを前記ソフトウェア層に提供する抽象化ロジックと、
    を有し、
    前記テスト／トレース情報は１以上のオペレーティングシステムに対して難読化された領域のメモリに格納され、
    前記インターフェースは、前記１以上のハードウェアテストフックと関連付けられたサービスを提供する
    システム。
14. 複数の集積回路と、
    前記複数の集積回路の各々における検証制御部それぞれへのアクセスを提供するユニバーサルテストアクセスポートと
    を備え、
    前記複数の集積回路のそれぞれは、
    集積回路に関連するテスト／トレース情報を取得するオンダイロジック分析器（ＯＤＬＡ）と、
    前記集積回路と連結され、前記ＯＤＬＡによって取得された前記集積回路に関連する前記テスト／トレース情報を保持するテスト／トレースバッファとして使用されるメモリと、
    テスト／トレース情報を提供する１以上のハードウェアテストフックと、
    前記１以上のハードウェアテストフックを、ソフトウェア層に対して抽象化して、インターフェースを前記ソフトウェア層に提供する抽象化ロジックと、
    複数の集積回路の各々のハードウェアテスト機能へのアクセスを制御する検証制御部と
    を有し、
    前記テスト／トレース情報は１以上のオペレーティングシステムに対して難読化された領域のメモリに格納され、
    前記インターフェースは、前記１以上のハードウェアテストフックと関連付けられたサービスを提供する
    システム。