(57)【要約】  本発明は、ｓｙｓｔｅｍ  ｏｎ  ｃｈｉｐ、すなわちＳｏＣの一部を形成する機能コアまたはＩＰコアのテストに関する。本発明は、テスト手段および通信手段を使用して少なくとも１つの機能コアまたはＩＰコアをテストすることによって実施される。テスト手段は、コアが組み込まれたラッパーを備え、このラッパーは、好ましくはＩＥＥＥ  Ｐ１５００標準アーキテクチャを実装するが、他の標準アーキテクチャを実装することもできる。テスト手段は、広範に適用されるＴＣＰ／ＩＰ管理プロトコルである、簡易ネットワーク管理プロトコル、すなわちＳＮＭＰに拡張することができる。通信手段は、通信ネットワークに接続されているテストバスを備える。プロキシエージェントは、中でも特にＳＮＭＰプロトコルを実装する。【選択図】  図６
2007524947.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの機能コアまたはＩＰコアと、
前記機能コアまたはＩＰコアをテストするテスト手段と、
前記テスト手段を外部通信ネットワークに接続する通信手段と
を備える集積回路チップ。
【請求項２】
少なくとも２つの機能コアまたはＩＰコアと、
機能コアまたはＩＰコアごとに、前記機能コアまたはＩＰコアをテストするテスト手段と、
各機能コアまたはＩＰコアの前記テスト手段を前記外部通信ネットワークに接続し、前記外部通信ネットワークから各機能コアまたはＩＰコアの各テスト手段への少なくとも個々のアクセスを有効にする通信手段と
を備える請求項１に記載の集積回路チップ。
【請求項３】
各機能コアまたはＩＰコアの前記テスト手段が、前記機能コアまたはＩＰコアが組み込まれているラッパーを備える請求項１または２に記載の集積回路チップ。
【請求項４】
各機能コアまたはＩＰコアの前記テスト手段の前記ラッパーがＩＥＥＥ  Ｐ１５００標準アーキテクチャを実装する請求項３に記載の集積回路チップ。
【請求項５】
前記通信手段が前記通信ネットワークを介して前記テスト手段のリモート制御を可能にする請求項１〜４のいずれか一項に記載の集積回路チップ。
【請求項６】
前記通信手段が前記テスト手段に接続されているテストバス（ＴＡＭ）、および前記テストバスおよび前記通信ネットワークに接続されているプロキシエージェント（ＰＡ）を備える請求項１〜５のいずれか一項に記載の集積回路チップ。
【請求項７】
前記プロキシエージェント（ＰＡ）がＳＭＮＰプロトコルを実装する請求項６に記載の集積回路チップ。
【請求項８】
前記プロキシエージェント（ＰＡ）が、ＳＭＮＰプロトコルとＰ１５００プロトコルとの間の情報を変換するＳＮＭＰプロセッサを備える請求項４〜７のいずれか一項に記載の集積回路チップ。
【請求項９】
前記通信手段が少なくとも１つのＴＣＰ／ＩＰネットワークインターフェイス回路を備える請求項１〜８のいずれか一項に記載の集積回路チップ。
【請求項１０】
請求項１〜９のいずれか一項に記載の集積回路チップと、
前記集積回路チップの前記通信手段に接続されている通信ネットワークと、
前記通信ネットワークに接続されており、前記通信ネットワークおよび前記集積回路チップの前記通信手段を介して前記集積回路チップの前記テスト手段と通信することができるネットワーク管理局（ＡＴＥ）と
を備える集積回路チップに組み込まれている少なくとも１つの機能コアまたはＩＰコアをテストするためのシステム。
【請求項１１】
前記通信ネットワークがＴＣＰ／ＩＰネットワークである場合、請求項１０に記載の集積回路チップに組み込まれている少なくとも１つの機能コアまたはＩＰコアをテストするシステム。
【請求項１２】
前記ネットワーク管理局（ＡＴＥ）が前記集積回路チップの機能コアまたはＩＰコアの自動テストを実行する場合、請求項１０または１１に記載の集積回路チップに組み込まれている少なくとも１つの機能コアまたはＩＰコアをテストするためのシステム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
本発明は、ルータ、スイッチ、パーソナルコンピュータなど、ネットワークベースの電子システムの深く掘り下げたテストおよび管理を目的としたネットワーク管理プロトコルの実装に関する。本発明は、より詳細には、集積回路の機能コアまたはＩＰコアのテストを目的とした、単一の集積回路チップのレベルのネットワーク管理機能（監視、制御、テスト・・・）の実装に関する。本発明では、ＳｏＣ（ｓｙｓｔｅｍ  ｏｎ  ａ  ｓｉｎｇｌｅ  ｃｈｉｐ）内において好ましく実装される。
【０００２】
Ｄｅｓｉｇｎ−Ｆｏｒ−Ｔｅｓｔ（ＤＦＴ）技術は、電子部品の設計段階でのテスト容易性の特徴を組み込むことにある。現在、集積回路およびシステムの製品テストを行うのに、ＤＦＴ技術は必須となっている。広く使用されているＤＦＴ技術の中に、Ｐ１５００と呼ばれるＩＥＥＥ標準がある［１−５］。［番号］の表記は、本出願の説明の最後にある出版物のリストを指す。Ｐ１５００は、より多くの論理および入力／出力を追加することによって、Ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐｓ（ＳｏＣ）のテスト容易性（制御性および可観測性）を向上させる。ネットワーキング装置を構成するＳｏＣは、数億のトランジスタを組み込んでいる。単一のチップ内のこうした膨大な数のトランジスタによって、信号処理、ネットワーキング、電気通信、計算、記憶などの複雑な機能の実施が可能になる。ＳｏＣの設計は、主に、プロセッサＲＩＳＣ、ＤＳＰ、ＲＡＭ、ＲＯＭなどのＩＰ（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｉｅｓ）の使用および再利用に基づいている［２］。こうしたチップのテストは、半導体業界にとって主要な問題の１つである。ＩＰコア入力／出力はＳｏＣ内に深く組み込まれているので、現在の集積回路の集積密度が増すと、テストの目的でこうしたＩＰにアクセスするのが難しくなる。［４］。ＤＦＴ技術は、管理対象ＴＣＰ／ＩＰネットワークに属する電子システム（ルータ、スイッチなど）の保守性および管理を容易にするために考えられたが、現時点で、既存の通信ネットワークを利用してＳＯＣのテスト機能を向上させる旨の既知の技術提案はない。
【０００３】
これを達成するために、本発明では、単一の集積回路チップは、
・少なくとも１つの機能コアまたはＩＰコアと、
・機能コアまたはＩＰコアをテストするテスト手段と、
・テスト手段を外部通信ネットワークに接続する通信手段と
を備える。
【０００４】
本発明の一態様によれば、単一の集積回路チップは、
・２つ以上の機能コアまたはＩＰコアと、
・機能コアまたはＩＰコアごとに、前記機能コアまたはＩＰコアをテストするテスト手段と、
・各機能コアまたはＩＰコアのテスト手段を外部通信ネットワークに接続し、外部通信ネットワークから各機能コアまたはＩＰコアの各テスト手段への少なくとも個々のアクセスを有効にする通信手段と
を備える。
【０００５】
本発明の別の態様において、各機能コアまたはＩＰコアのテスト手段は、機能コアまたはＩＰコアが組み込まれているラッパーを備え、各機能コアまたはＩＰコアのテスト手段のラッパーは、ＩＥＥＥ  Ｐ１５００標準のアーキテクチャを実装するのが好ましいが、他のタイプのものでもよい。本発明のその好ましいが限定的ではない実施形態のうちの１つにおいて、テスト手段は、必要な論理を拡張することによってＰ１５００  ＤＦＴ技術から恩恵を得て、広く導入されているＴＣＰ／ＩＰ管理プロトコルであるＳＮＭＰ（簡易ネットワーク管理プロトコル）で使用できるようにする。さらに、ＳＮＭＰに準拠して拡張され、作られたＰ１５００などの伝統的なＤＦＴ技術は、ＩＰコアの内部構造へのアクセスを容易にする。これは、高レベルのＳＮＭＰ管理を介して達成される。つまり、ＳＮＭＰ要求から始めて、本発明によって提案された混成のＰ１５００／ＳＮＭＰ  ＤＦＴアーキテクチャは、ＩＥＥＥ  Ｐ１５００ラッパー境界走査操作を実行し、それによってテストおよび監視のサポートが可能になる。
【０００６】
本発明の一態様によれば、集積回路チップの通信手段は、テスト手段に接続されたテストバス、およびテストバスおよび通信ネットワークに接続されたプロキシエージェントを備える。好ましいが限定的ではない実施形態において、プロキシエージェントは、ＳＭＮＰプロトコルを実装する。
【０００７】
本発明の別の態様によれば、集積回路チップの通信手段は、少なくとも１つのＴＣＰ／ＩＰネットワークインターフェイス回路を備える。
【０００８】
複雑なＳｏＣが与えられると、本発明は、ＳｏＣ環境に組み込まれているＩＰコアへのアクセス可能性およびテスト容易性を強化する。本発明は、もともとＴＣＰ／ＩＰローカルエリアネットワークの管理を強化するために提案されたＳＮＭＰを利用する。ＳＮＭＰは、すべてのＩＰコア、および結果的には複雑な電子システムを構成するすべてのＳｏＣのよりよいテスト容易性を得るために、ＳｏＣ内で考えられる。このために、本発明の一態様によれば、Ｐ１５００は、ＩＰコアの内部構造へのアクセスを容易にするために、ＳＮＭＰに準拠して拡張され、作られている。本発明によれば、ＳＮＭＰは、ＳｏＣ内に実装されるため、ネットワーク管理の伝統的なフレームワークを超えて考えられる。
【０００９】
ネットワーク管理システム（ＳＮＭＰ）は、少なくとも２つの主要要素、マネージャおよびエージェントを含む［７−９］［１１］。マネージャ（ネットワーク管理システム：ＮＭＳ）は、ネットワーク管理者がネットワーク管理機能を実行するコンソールである。エージェントは、管理対象オブジェクトを含む、管理されている実際の装置にインターフェイス接続するエンティティである。これらの管理対象オブジェクトは、当の装置の現在の操作に直接関係するハードウェア、構成パラメータ、性能統計などとすることができる。これらのオブジェクトは、管理情報ベースまたはＭＩＢと呼ばれる仮想情報データベースとして知られているものの中に配列される。ＳＮＭＰは、マネージャおよびエージェントが、オブジェクト識別子（ＯＩＤ）と呼ばれる階層識別子を介してこれらのオブジェクトにアクセスする目的で通信できるようにする。
【００１０】
テスト戦略の基幹としてＳＮＭＰを使用することの主な動機および利点は、（ｉ）様々な電子機器の動作の管理、および監視、（ｉｉ）各構成部品の深く掘り下げた状態情報の収集、（ｉｉｉ）ネットワーク障害の検出、とまとめられる。このリストは、限定的、制限的なものとみなされないものとする。
【００１１】
さらに、次の理由、すなわち（ｉ）Ｓｏｃを構成するもののうちＩＰコアを分離するのを助け、（ｉｉ）内部論理へのアクセスの標準機構を提供し、（ｉｉｉ）複数のベンダーから提供されるＩＰコアの混合および相互接続を容易にするという理由のために、Ｐ１５００が考慮される［４］。
【００１２】
ＤＦＴとネットワーク管理との組み合わせを可能にするために、本発明の別の態様に従って混成のＰ１５００／ＳＭＮＰアーキテクチャが提案され、通信手段のプロキシエージェントは、ＳＭＮＰプロトコルとＰ１５００プロトコルとの間の情報を変換するＳＮＭＰプロセッサを備える。
【００１３】
提案されたテスト／管理手法は、以下の理由のために、テストの経済にも重要な影響を与える。
【００１４】
製造テスト費用を低減する。一般に、最初のＳｏＣが製造ラインを離れるとき、チップに実装されたＤＦＴ論理からの恩恵を得ることによって、広範なテストが実行される。しかし、通常、分析を実行するのにしばしば必要となる数百万ドルのテストシステムは、生産テストフロアで常に非常に混んでいる。実際に、テスト時間は間違いなくテスト費用の一構成要素であり、こうした費用の別の部分としては、テストに関与する自動検査装置（ＡＴＥ）の種類がある。ＳｏＣ製造テストに使用されるＡＴＥは、非常に複雑で、非常に費用がかかる［１０］。既存のＴＣＰ／ＩＰネットワークを介してリモートのＳｏＣに対してテストパターンを実行することによって、費用効率が高いＡＴＥの使用が可能になる。
【００１５】
したがって、本発明では、集積回路チップに組み込まれている少なくとも１つの機能コアまたはＩＰコアをテストするシステムは、
・本発明による集積回路チップと、
・集積回路チップの通信手段に接続されている通信ネットワークと、
・通信ネットワークに接続されており、通信ネットワークおよび集積回路チップの通信手段を介して集積回路チップのテスト手段と通信することができるネットワーク管理局と
を備える。
【００１６】
本発明の一態様によれば、集積回路チップの機能コアまたはＩＰコアの自動テストを実行するネットワーク管理局として働くのがＡＴＥである。
【００１７】
本発明の別の態様によれば、集積回路チップの通信手段は、通信ネットワークを介したテスト手段のリモート制御を可能にする。本発明のこの態様は、有利には、テストの従来の技術の遠隔使用を可能にする。最近のＳｏＣベースのシステムでは、ＡＴＥとテスト対象の装置との間に転送されるテストデータの量が非常に多くなりつつある。制限されたメモリリソース、狭いチャネル帯域幅、および低速の結果、高価な最先端のＡＴＥでさえ、ＳｏＣテストを制限している。ＡＴＥの制限を克服するための１つの既知の手法は、パターンを生成し、結果を迅速に分析するために、組み込み自己テスト（ＢＩＳＴ［１２］）を使用することである。テスト対象のＩＰコアがＢＩＳＴを有している場合、提案されたテスト／管理手法は、ＳＮＭＰ  ｓｅｔ−ｒｅｑｕｅｓｔを介してリモートで自己テストを起動させることができ、自己テストが終了するとすぐ、ＡＴＥがＢＩＳＴ署名を取り出すためのＳＮＭＰ  ｇｅｔ−ｒｅｑｕｅｓｔを生成するように、トラップと呼ばれる非請求メッセージを自律的に受信する。
【００１８】
本発明の別の利点は、障害診断の向上であり、基本的なＳＮＭＰ要求（ｓｅｔ−ｒｅｑｕｅｓｔやｇｅｔ−ｒｅｑｕｅｓｔなど）を使用してＩＰコアの内部状態を収集し、ＳｏＣ内の障害診断を向上させるのを助ける。実際に、こうした手法のテスターのオペレーティングシステムに関連付けられている診断ソフトウェアは、ＳＮＭＰ要求を介して組み込みコアと対話する。このソフトウェアは、組み込まれたテストの実行および診断の要求を実行し、実行状況結果または詳細な診断情報を回収する。
【００１９】
本発明によって、よりよい保守性も可能になる。ＩＰコアの動作の管理および監視は、管理ネットワーク領域内の重要な資産を利用することによって可能である。したがって、全体的なシステムの保守性が向上する。というのは、より大きいデジタルシステム内では、数多くのハードウェアレジスタを見つけることが多いからである。一般に、こうした種類のレジスタは、システム内のハードウェア機能を制御し、監視する。各ＩＰコアの機能ブロック（ＦＢ）からレジスタを分離し、この手法で提案された拡張されたＰ１５００論理とレジスタとを相互接続することがよく行われている。これらのレジスタは、ＦＢに接続されたままである。この機能により、その拡張されたＰ１５００論理を介してＳｏＣの各ＩＰコアを管理し、監視することができる。
【００２０】
現在、いくつかの研究が、ネットワークプロトコルおよびアプリケーションを使用したハードウェアベースの解決策に取り組んでいる。セントルイスのワシントン大学にあるＡｐｐｌｉｅｄ  Ｒｅｓｅａｒｃｈ  Ｌａｂ（ＡＲＬ）では、ネットワーキング、切り替え、経路指定、およびアクティブネットワーキングの分野の研究のための１組のハードウェア構成部品が開発されている。しかし、再構成可能なハードウェア内のインターネットパケットを処理する層状のプロトコルラッパーのハードウェア構成部品が提案されている［１３］。したがって、このラッパーライブラリを使用するいくつかのネットワークアプリケーションが開発されている［１３］。例えば、インターネットルータまたはファイアウォールは、ラッパーライブラリを使用して、パケットを経路指定し、フィルタリングする重要なアプリケーションである［１４、１５］。単一のチップを使用して、インターネットＳＰＡＭをフィルタリングし、いくつかのタイプのネットワーク侵入から保護している。
【００２１】
上記の研究は、アプリケーション層のＳＮＭＰハードウェアベースの解決策に取り組んでいない。こうした特徴は、チップレベルで検討される必要があるため、このことは重要である。ＳＮＭＰは、実際にＴＣＰ／ＩＰスイートを使用する（実際にはＵＤＰが使用されている）アプリケーション層プロトコルとみなされる。好ましいが限定的な実施形態では、本発明は、論文［１３］において開発されたラッパーライブラリに関して開発されたＳＮＭＰエージェントを実装する。ＳＮＭＰエージェントは、ＳｏＣ全体の外部テストを助けるために、ＳｏＣ内で開発される。
【００２２】
さらに、Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔ（ＲＦＣ）文書で公表されたより多くのＳＮＭＰバージョンがある。第１のバージョン（ＳＮＭＰｖ１）は、管理機能の簡単さによって特徴付けられる［９］。ＳＮＭＰｖ２（ＲＦＣの１９０１から１９０８）［１８］は、ＳＮＭＰｖ１の強化版である。ＳＮＭＰｖ３フレームワーク（ＲＦＣの３４１１から３４１８）［１９］は、ＳＮＭＰｖ１フレームワークおよびＳＮＭＰｖ２フレームワークから導出され、それらに基づいている。インターネット標準管理フレームワークのすべてのバ―ジョン（ＳＮＭＰｖ１、ＳＮＭＰｖ２、およびＳＮＭＰｖ３）は、同じ基本的な構造および構成部品を共有している。すべてのバージョンに関係する共存の問題は、ＲＦＣ  ３５８４［２８］で入手可能である。ＳＮＭＰｖ３は、新しいメッセージ形式、セキュリティ能力、およびＳＮＭＰパラメータのリモート構成を備えた拡張可能なＳＮＭＰｖ２フレームワークである。
【００２３】
さらに、多くのＤＦＴ戦略の根元は、境界走査技術にある。ＩＥＥＥ１１４９．１［２０］標準に成文化されているその技術は、チップの入力および出力を調べ、プリント基板（ＰＣＢ）の相互接続の保全性をテストする。ＳｏＣのＤＦＴ技術は、チップ回路により深く照準をあて、現在、組み込みコアテストの標準のＩＥＥＥ  Ｐ１５００［１−５］ワーキンググループの焦点となっている。ＩＥＥＥ  Ｐ１５００は、コアベースのＳｏＣテストの次の２つの重要な側面、すなわち（１）コアテスト言語の標準化によるコアプロバイダからコアユーザへのコアテストの知識の転送、および（２）コア内部およびコア外部のテストをサポートするコアラッパーの標準化による組み込みコアへのテストアクセスを標準化している。
【００２４】
ネットワーク管理システム（ＳＮＭＰ）は、エージェントと呼ばれる処理エンティティをそれぞれ組み込むいくつかのノードを含む［７−９］（図１）。エージェントは、エージェントと管理局との間での管理情報の伝達のために使用される、管理手段、少なくとも１つの管理局、および管理プロトコルにアクセスすることができる。プロトコルの操作は、認証および認可のポリシーを定義する管理フレームワーク下で実行される。ネットワーク管理局は、ネットワーク要素を監視し、制御する管理アプリケーションを実行する。ネットワーク要素は、それらの管理情報へのアクセスを介して監視され、制御される。
【００２５】
関連の管理情報、イベント、および関連の実装コンプライアンス要件の定義は、管理情報ベース仕様書またはＭＩＢ仕様書と呼ばれる文書で、「管理情報は、可視情報ストアにある管理対象オブジェクトの集まりとしてみなされる（ＭＩＢ）［７］」と指定されている。関連のオブジェクトの集まりは、ＭＩＢモジュールで定義される。これらのモジュールは、ＯＳＩ（オープンシステム相互接続）の抽象構文記法１（ＡＳＮ．１）［２２］の一部分を使用して書かれる。実際に、ＭＩＢは、ネットワーク接続されたシステムをリモートで監視し、構成し、制御できるように、管理情報の定義を含む仕様書である［７、９］。その一部を定義するためのものが管理情報の構造（ＳＭＩ）である［２３］。ＳＭＩは、次の３つの部分、すなわちモジュール定義、オブジェクト定義、およびトラップ定義に分けられる。ＭＩＢで定義された任意のオブジェクト型の各オブジェクトインスタンスは、ＳＮＭＰ操作で、ｘ、ｙの形のオブジェクト識別子（ＯＩＤ）［２３］と呼ばれる階層識別子によって定義される。ここでは、ｘはＭＩＢで定義された非集合オブジェクト型（ｎｏｎ−ａｇｇｒｅｇａｔｅ  ｏｂｊｅｃｔ  ｔｙｐｅ）の名前、ｙは指定されたオブジェクト型に固有の方法で所望のインスタンスを識別するオブジェクト識別子の断片である。マネージャは、ＵＤＰプロトコルを使用して、１組のＳＮＭＰメッセージをエージェント（ＳＮＭＰｖ１［９］）または他のマネージャ（ＳＮＭＰｖ２［２４］）と交換する。実際に、マネージャがそのエージェントを監視し、構成するには、いくつかの操作が行われなければならない。ｇｅｔ−ｒｅｑｕｅｓｔ、ｇｅｔ−ｎｅｘｔ−ｒｅｑｕｅｓｔ、およびｇｅｔ−ｂｕｌｋ−ｒｅｑｕｅｓｔ（ＳＮＭＰｖ２）は監視のために、ｓｅｔ−ｒｅｑｕｅｓｔメッセージはエージェントの構成のために使用される。マネージャは、所与のｇｅｔ−ｒｅｑｕｅｓｔメッセージを送信することによって開始し、エージェントは、ｇｅｔ−ｒｅｓｐｏｎｓｅメッセージをマネージャに返信することによって、その所与のメッセージに応答する。管理システムの効率を向上させるために、エージェントは、トラップと呼ばれる非請求メッセージを生成することができる。これは、エージェントがそのネットワーク要素における予め設定されているパラメータの出現を観察するときに行われる。
【００２６】
提案された解決策ではＳＮＭＰｖ１が考慮されたが、一般性が失われるのではない。実際に、ＳＮＭＰｖ１は、テスト管理の解決策のすべての要件を十分に満たす。ＳＮＭＰを介した管理（図２）は、テスト情報を取り出し、適用することによって達成される。こうした情報は、電子部品（ＳｏＣ）に関連している。例えば、ＳＮＭＰ要求を使用して（図２）、ＳｏＣ、およびマネージャ（ＮＭＳまたはこの場合はＡＴＥ）を始めとするそのすべての組み込みコアを観察し、監視し、テストする。このように、標準のＳＮＭＰベースの管理ソフトウェアを使用して、テスト応答、地図製作情報（ｃａｒｔｏｇｒａｐｈｙ  ｉｎｆｏｒｍａｔｉｏｎ）、または他のテスト情報が取り出される。
【００２７】
ＳｏＣのテストは、半導体業界にとって主要な問題の１つである。ＩＰコア入力／出力はＳｏＣ内に深く組み込まれているので、現在の集積回路の集積密度が増すと、テストの目的でこうしたＩＰにアクセスするのが難しくなる。
【００２８】
一般に、ＳｏＣテストの問題では、次の新しい課題を必要とする［４］
・設計者からユーザへのＩＰコアテスト情報の効率的な転送
・ＩＰコア入力／出力に到達し、それらをＡＴＥまたはＳｏＣ自己テスト論理に接続することができるように、内部ＩＰコアトインフラストラクチャへのアクセスの向上
・テスト統合化を最適化し、必要な費用の全体に渡って最適な性能を確保すること
・情報ベース（ＭＩＢ）へのリモートアクセスに関する、システムレベルからＩＰコアレベルへの標準管理の確立
・Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ社のＨＰＯＰＥＮ−ＶＩＥＷ（ｃ）など、使用可能なネットワーク管理ソフトウェアツールからの恩恵の獲得
・監視および制御のための機能パラダイムは、ネットワーク操作および管理の、追加の、場合によっては予期しない側面に対応するように十分拡張可能である。
【００２９】
ＳＮＭＰによって要求されるメッセージ（ｇｅｔ−ｒｅｑｕｅｓｔ、ｇｅｔ−ｎｅｘｔ−ｒｅｑｕｅｓｔなど）の数が少ないことはわかっているので、チップのレベルでもシステムのレベルでも、期待されるのはわずかのリソースだけである。
【００３０】
さらに、次の理由のために、Ｐ１５００が考えられる［４］。
・ＳｏＣを構成するもののうちＩＰコアを分離するのを助ける。
・内部論理へのアクセスの標準の機構を提供する
・複数のベンダーから提供されるＩＰコアの混合および相互接続を容易にする。
【００３１】
ＤＦＴとネットワーク管理との組み合わせを可能にするために、混成Ｐ１５００／ＳＮＭＰアーキテクチャが提案される。本発明は、ＩＰコアおよびＳｏＣの両方のレベルでの解決策を提案する。提案されたテスト管理手法は、上述したように、製造テスト費用の低減を可能にする。ＳｏＣ製造テストに使用される現在の自動検査装置（ＡＴＥ）は、非常に複雑で、非常に費用がかかる［１０］。既存のＴＣＰ／ＩＰネットワークを介してリモートＳｏＣに対してテストパターンを実行することによって、費用効率が高いＡＴＥの使用を可能にする。したがって、従来のＴＣＰ／ＩＰネットワーキング技術（図２）を介してＡＴＥからリモートの電子装置にデータを運び出すことができる。
【００３２】
また、本発明は、基本的なＳＮＭＰ要求（ｓｅｔ−ｒｅｑｕｅｓｔやｇｅｔ−ｒｅｑｕｅｓｔなど）を使用してＩＰコアの内部状態を収集することによって障害診断を向上させ、ＳｏＣ内の障害診断を向上させるのを助ける。
【００３３】
ＩＰコアは、ＳｏＣの一部としてコアインテグレータによってテストされる。これは、ＩＰコアプロバイダによって提供されたテストベクトルを使用することによって達成される。実際に、通常、ＳｏＣのインテグレータは、使用されたＩＰコアに関する情報をあまり有していない。ＩＰコアは、ブラックボックスと考えられる。今日、テストポイントの挿入、走査、ＢＩＳＴ挿入など、これまで以上にテスト容易性の問題を念頭に置いてＩＰコアを設計しなければならない［４］。テスト以外に、ＩＰコアの出所および技術の多様性（混合した技術設計）によって、別の問題がもたらされる。ＩＰコアは、使用された通信プロトコル、使用されたバスインターフェイス、周波数など、いくつかの観点から異種のものである。こうした異種のパラメータは、ＩＰコア間の接続および通信の問題を必然的に伴う。したがって、ＩＰコアのユーザによって、柔軟性および互換性がかなり必要とされる。
【００３４】
コアのＰ１５００ラッパー［２−５］やコアテスト言語（ＣＴＬ）などのＳｏＣテスト機構標準を現在開発中である［１］。ＩＥＥＥ  Ｐ１５００標準は、システムチップ相互接続および論理（ＩＰコア）のテスト容易性の機能を向上させ、組み込まれた環境からコアを分離することができる。図３は、Ｐ１５００の拡張可能なアーキテクチャの概要を示している。テストの必要性のため、各ＩＰコアを、Ｐ１５００ラッパーでカプセル化する必要がある。ラッパーの役割は、外部入力の制御を可能にし、周辺の走査パスによってＩＰコアの外部出力を観察することである。さらに、ラッパーは、ＩＰコアの内部走査パスの制御を可能にする。また、ラッパーは、機能モード、周辺シフトモード、内部シフトモードなど、ＩＰコアの動作モードを定義することもできる。そのため、そのテスト情報は、テストバスまたはテストアクセス機構（ＴＡＭ）を介してＳｏＣ内に配布される。
【００３５】
図３は、Ｐ１５００の拡張可能なアーキテクチャの概要を示している。テストの必要性のため、各ＩＰコアを、Ｐ１５００ラッパーでカプセル化する必要がある。ラッパーの役割は、外部入力の制御を可能にし、周辺の走査パスによってＩＰコアの外部出力を観察することである。また、ラッパーは、機能モード、周辺シフトモード、内部シフトモードなど、ＩＰコアの動作モードを定義することもできる。そのため、そのテスト情報は、テストバスまたはテストアクセス機構（ＴＡＭ）を介してＳｏＣ内に配布される。
【００３６】
本発明のこれ以上の特徴、態様、および利点は、以下の説明、添付の特許請求の範囲、および添付の図面との関連で、よりよく理解されよう。
【００３７】
上述したように、好ましい実施形態において、本発明は、Ｐ１５００標準とＳＮＭＰ標準との組み合わせであるＤＦＴ技術を提案する。実際に、ＳｏＣ以外でも、この手法は、ＳＮＭＰに完全に準拠している。
【００３８】
本発明によれば、Ｐ１５００アーキテクチャは、ＳＮＭＰの挙動を追加することによって拡張されている。こうした拡張が与えられると、ＳｏＣは、ＳＮＭＰ要求を理解することができるようになる。ＳＮＭＰは、ネットワーク管理局（ＡＴＥ）とネットワーク要素内のエージェント（ＳｏＣ）との間で管理情報を通信するために使用される。ＳＮＭＰ要求（ｇｅｔ−ｒｅｑｕｅｓｔやｓｅｔ−ｒｅｑｕｅｓｔ）は、ＩＰコア識別子、ＳｏＣ識別子、テストベクトル、テスト技術など、ＳｏＣの管理対象オブジェクトの値を取り出したり、変更したりする。
【００３９】
図４は、シーケンス図を示している。シーケンス図は、ＵＭＬ表記によって表されている［２５］。ｓｅｔ−ｒｅｑｕｅｓｔメッセージ（図４．ａ：ｓｅｔ−ｒｅｑｕｅｓｔ  ＯＩＤ  ＴＶ）は、識別子（ＯＩＤ）およびテストベクトルを指定することによって、ＩＰコアに対してテストベクトルを適用する。この場合、ＯＩＤは、適用されたテストのタイプを区別する。すべてのＳＮＭＰバージョンにおいて、アレイＶａｒＢｉｎｄＬｉｓｔの各変数バインディング（ｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇ）の内容は、応答にコピーされる。エラー状況およびエラーインデックスのフィールドは、成功を示すためにゼロに設定されるか、エラーに関する適切な値に設定される。我々の手法では、これは類似しているが、ｇｅｔ−ｒｅｓｐｏｎｓｅメッセージは、テストベクトルのプレースホルダ値をテスト結果と置き換える。この選択の動機は、ＳＮＭＰ要求数を最低限に抑えることである。つまり、テストベクトルを適用するにはｓｅｔ−ｒｅｑｕｅｓｔ、テスト結果を取り出すにはｇｅｔ−ｒｅｑｕｅｓｔという牽引メッセージの代わりに、テストベクトルを適用し、テスト結果を取り出すのに、ｓｅｔ−ｒｅｑｕｅｓｔメッセージが１つ必要である。しかし、ｇｅｔ−ｒｅｑｕｅｓｔメッセージ（図４．ｂ：ｇｅｔ−ｒｅｑｕｅｓｔ  ＯＩＤ）は、例えば、テスト情報のインスタンスの識別を指定することによって、ＩＰコアまたはＳｏＣのテスト情報を取り出す。処理に際してエラーが起こらなかったとき、ｇｅｔ−ｒｅｓｐｏｎｓｅメッセージは、プレースホルダ値をテスト情報の実際の値と置き換える。したがって、こうした機能を使用すれば、ＳＭＮＰプロトコルは、ＩＰコアの内部構造に到達する。
【００４０】
図５に示すように、ＳＮＭＰプロトコルは、マネージャとエージェントとの間の関係を標準化する。マネージャは、多くのエージェントの指定された機能を監督する責任を負う。プロトコルエンティティ中の通信は、メッセージの交換によって達成され、そのそれぞれは、ＡＳＮ．１の基本符号化規則（ＢＥＲ）［２２、２６］を使用して単一のＵＤＰデータグラム内で完全に、単独で表されている。メッセージは、バージョン識別子、ＳＮＭＰコミュニティ名、およびプロトコルデータユニット（ＰＤＵ）から成る。したがって、ＳＮＭＰアーキテクチャは、２つの部分、すなわちこの場合はＡＴＥを表すクライアント側、およびＳｏＣを表すサーバ側に分けられる。ＳｏＣ側では、層状プロトコルラッパー（ＵＤＰおよびＩＰラッパー）［１３］が使用されるため、ＳＮＭＰアプリケーション層のみが考えられる。
【００４１】
本発明の好ましい実施形態において、テスト／管理の解決策のすべての要件を完全に満たすため、ＳＮＭＰｖ１プロトコル（メッセージ形式）が検討される。また、ＳＮＭＰｖ１は、簡単であり、シリコン面積のオーバーヘッド、およびチップ上で機能する時間のためのリソースを大量には必要としない。しかし、本発明によれば、他のプロトコルを使用することもできる。
【００４２】
アーキテクチャレベルでは、ＳｏＣは、電子装置／システムに組み込まれた分散システムと考えられる。本発明によれば、集積回路チップまたはＳｏＣは、複数の機能コアまたはＩＰコアを備える。これらのＩＰコアのそれぞれは、拡張されたＰ１５００ラッパーを使用することによってラップされる。後者は、ＳｏＣの通信手段の一部であるプロキシエージェント（ＰＡ）によって管理されているＳＮＭＰエージェントを表す（図６）。通常、ＩＰコアは、バスまたは複雑な通信ネットワークによって相互接続される。本発明は、ＰＡ構成部品（図６）を介してネットワーク管理局から始まる提案されたインフラストラクチャの管理を可能にする。そのアーキテクチャが以下で詳述されるＰＡは、ハードウェアベースのＳＮＭＰエージェントである（図６）。これは、全体としてハードウェアに実装される。この構成部品は、テスト対象の組み込みコアを監視し、制御する。
【００４３】
ＰＡは、ＳＮＭＰプロトコルとＰ１５００プロトコルとの間の情報を変換するために使用される。つまり、ＰＡは、管理局がすべてのＳｏＣおよびＩＰコアのインフラストラクチャの安定した管理フレームワークを適用することができるプロトコル変換機能を提供する。したがって、ＰＡは、管理局（またはＡＴＥ）からのＳＮＭＰ要求を取得するＩＰコアと考えることができる。こうした要求は、拡張されたＰ１５００標準に準拠する命令に変換される。
【００４４】
同様の方法で、ＩＰコアの回答は、ＳＮＭＰプロトコル表現（ｇｅｔ−ｒｅｓｐｏｎｓｅまたはＴｒａｐ）に変換される。最後に、テスト結果は、ＳＮＭＰ要求としてＡＴＥに送信される。ＰＡのＭＩＢ（管理情報ベース）は、ＳｏＣに関連するすべてのテスト情報を含む。各ＩＰコアは、ＳＮＭＰエージェントの挙動を表すＭＩＢを組み込む。
【００４５】
図７は、本発明による管理情報ベースＭＩＢの構造を示す。ＩＰコアまたはＳｏＣの場合、ＭＩＢは、Ｐ１５００ラッパーに関連するテスト技術の機能、およびテストプロセスに関係する情報（テストベクトル、テスト結果など）を記載している。
【００４６】
ＭＩＢは、２つの部分、すなわちＳｏＣレベルの情報、およびＩＰコアのレベルの情報に分けられる。ＭＩＢの第１の部分は、ＳｏＣ識別子、基本構成部品の構成など、ＳｏＣ専用である。
【００４７】
ＭＩＢの第２の部分は、ＩＰコア専用である。例えば、「ｉｐＣｏｒｅｓＷｒａｐｐｅｄＰｌ５００Ｔａｂｌｅ」と呼ばれる表は、Ｐ１５００テストアーキテクチャに関する情報に関係する。この表のインデックスは、「ｉｐＣｏｒｅＩｎｄｅｘ」と呼ばれる。これは、ＳｏＣ環境におけるＩＰコアの論理アドレスを表す。ＩＰコアがＩＥＥＥ１１４９．１ラッパーを使用してラップされる場合、ＩＥＥＥ１１４９．１などの他のテスト技術は、ＭＩＢ内で指定することができる。以下の表Ｉは、提案されたテストアーキテクチャによって処理される主なＭＩＢ変数を提供する。
【表１】
2007524947.tif 000003
【００４８】
ＳＮＭＰの要求とＰ１５００の要求との間の関係は、プロキシエージェントのレベルで実装される。これは、表ＩＩに示されている。
【表２】
2007524947.tif 000004
【００４９】
ＳｏＣレベルで、プロキシエージェントは、ＳＮＭＰ要求をＰ１５００命令に変換する。例えば、ＳＮＭＰ要求「ＧｅｔＲｅｑｕｅｓｔ  Ｘ．１．１．１．０」は、フラット化されたＯＩＤ（ｆｌａｔｔｅｎｅｄ  ＯＩＤ）が「１」に等しいＷＳ＿ＧＥＴＲＥＱＵＥＳＴ  Ｐ１５００命令に変換される。フラット化されたＯＩＤは、階層型ＯＩＤ「Ｘ．１．１．１．０」に関係する。ＳｏＣ内では、階層型ＯＩＤの代わりに、フラット化されたＯＩＤが考えられる。この選択の動機は、ＩＰコアごとに階層型ＯＩＤの処理論理を最低限に抑える必要があることである。テストアーキテクチャがどのように働くかをよりよく説明するために、テスト対象のＳｏＣが与えられている場合、第５のＩＰコアに機能テストが必要であると仮定する。そのために、以下のテストベクトル「１１００１１０」が考えられる。ＳＮＭＰを使用すると、要求「ＳｅｔＲｅｑｕｅｓｔ  Ｘ．２．２．１．４．５「１１００１１０」ｂ」が送信される。しかし、この要求は、ＳｏＣ内で、フラット化されたＯＩＤが「１５」に等しいＷＳ＿ＳＥＴＲＥＱＵＥＳＴと呼ばれるＰ１５００命令に変換される。また、階層型ＯＩＤの最後の数（ＩＰＣｏｒｅＩｎｄｅｘ）は、検討されているＩＰコアの論理アドレス（番号「５」）を表す。
【００５０】
提案されたアーキテクチャの設計の再利用を確実にするために、プロキシエージェントは、２つのモード、すなわちブリッジモードおよびリモートモード（図８参照）で動作する。ＳｏＣレベルでは、プロキシエージェントは、ＳｏＣの外部のＴＣＰ／ＩＰネットワーク、およびＳｏＣの内部の専用のＮｅｔｗｏｒｋ−ｏｎ−Ｃｈｉｐｓ（ＮｏＣ）の異なる２つのネットワーク間で動作するため、ルータモードで動作する。ＩＰコアのレベルでは、エージェントは、同じネットワーク内で動作するため、ブリッジモードで動作する。
【００５１】
図９は、各ＩＰコアの周囲に配置された、拡張されたＰ１５００ラッパーのアーキテクチャを示す。この拡張は、図７に示されているＭＩＢの大部分、特に、各ＩＰコアに専用のＭＩＢの一部分を実装する。拡張されたＰ１５００ラッパーのアーキテクチャは、以下のブロックを含む。
【００５２】
ＩＤＩＰ：ＩＰコア識別子（製造業者識別子、バージョンなど）を格納する３２ビットレジスタ
【００５３】
ＴＥＣＴＥＳＴ：使用されたテスト技術（走査、ＢＩＳＴなど）を識別する４ビットレジスタ
【００５４】
ＷＢＹ、ＷＢＲ、ＷＳＩ、ＷＳＯ、ＢＩＳＴ、ＷＩＰ：Ｐ１５００標準［５］によってすでに定義されている基本ブロック。詳細については［２〜５］を参照されたい。
【００５５】
拡張されたＷＩＲ（Ｗｒａｐｐｅｒ  Ｉｎｓｔｒｕｃｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）：この論理は、ＳＮＭＰ命令をサポートするように、従来のＰ１５００命令レジスタを拡張する。実際に、拡張されたアーキテクチャのために、新しい命令が必要である。以下の表は、これらの新しい命令をまとめている。
【表３】
2007524947.tif 000005
【００５６】
ＯＩＤ（オブジェクト識別子）レジスタ：このレジスタは、プロキシエージェントからフラット化されたオブジェクト識別子を取得する。これは、追加されたＰ１５００命令のセマンティクスを完成する。実際に、ＯＩＤ情報は、ＩＰコアレベル（拡張されたＰ１５００ラッパー）で追加のＰ１５００命令を連結する。これによって、適切な動作モードを開始することができる。
【００５７】
ＩＴＣ９９ベンチマーク（ｂ０１からｂ２２）［２７］として知られている２２個の設計ベンチマークを使用して、いくつかの実験が行われた。考えられる設計フローは、Ｓｙｎｏｐｓｙｓ（登録商標）ツールに基づく。取得された結果は、図１０、１１、および表ＩＶにまとめられている。
【００５８】
図１０は、ベンチマークＩＴＣ９９に適合される簡単なＰ１５００ラッパー、および拡張されたＰ１５００ラッパーの合成結果を示す。図１０は、簡単なラッパーによって必要とされる面積と、拡張されたラッパーによって必要とされるシリコン面積との間を比較している。取得された結果は、表ＩＶに詳述している。面積およびタイミング値は、それぞれ「ゲート」アカウントおよび「ｎｓ」で示されていることに留意されたい。
【００５９】
図１０および図１１に示されるように、面積は、提案されたアーキテクチャによってわずかに影響を受ける。これは、表ＩＶにも示されている。
【表４】
2007524947.tif 000006
【００６０】
最初の３行は、ＩＴＣ９９ベンチマークごとの入力ピンおよび出力ピンの数を表している。４行目は、拡張されたラッパーの面積オーバーヘッドを示している。５行目は、ＩＰコア（ＩＴＣ９９ベンチマーク）の総面積に対して拡張されたラッパーによって占められている面積の割合を示している。６行目および７行目は、拡張されたラッパーを通過するデータの遅延に関する情報をドック周期で示している。最後の行は、合成された各ラッパーの最大周波数を示している。要約すれば、考えられるＩＰコアの場合、ＳＮＭＰインターフェイスは、２、３の追加の論理を必要とする。というのは、簡単なラッパーによって占められる面積オーバーヘッドと、拡張されたラッパーによって占められる面積オーバーヘッドとの間の差は、わずか１１９ゲートにすぎないからである。示された結果は、０．１８μＣＭＯＳ技術ライブラリを考慮している。このライブラリは、いくつかの例の産業用集積回路に使用されている。
【００６１】
提案されたアーキテクチャは、費用効率が高い。さらに、（１）従来のＰ１５００ラッパーに１００％準拠している、（２）新しいオブジェクトおよび新しいＯＩＤが追加されたときにＭＩＢの拡張性を保証する、（３）内部プロトコルが影響を受けないといういくつかの利点がある。
【００６２】
図１２は、プロキシエージェントのハードウェアベースのネットワーキングアーキテクチャを示している。［１３］で提案されたプロトコルラッパーが図１２に示されている。これらのラッパーは、次のプロトコル、物理、データリンク、ＩＰ、およびＵＤＰに従って層状化される。しかし、提案されたアーキテクチャを使用して、新しいネットワークアプリケーションインターフェイスは、ＵＤＰラッパーインターフェイスに適合される。
【００６３】
プロキシエージェントは、ＴＡＭを介してＩＰコアと通信する。実際に、提案されたプロキシエージェントは、３つの構成部品、ＳＮＭＰラッパー、ＳＮＭＰプロセッサ、および制御ブロックから成る。
【００６４】
ＳＮＭＰラッパー（図１３）は、２つの構成部品、ＩｎｐｕｔＤｅｖｉｃｅおよびＯｕｔｐｕｔＤｅｖｉｃｅから成る。ＩｎｐｕｔＤｅｖｉｃｅは、ＵＤＰラッパーから要求メッセージを受信する［１０］。ＩｎｐｕｔＤｅｖｉｃｅは、まず、レジスタファイル（ＲＦ、１つのＳＮＭＰメッセージをサポートする）内に要求メッセージを集める。収集されたらすぐに、ＡＳＮ．１［２２］のＢＥＲ［２６］を使用することによって、入ってくるトランスポートメッセージが非直列化（復号）される。次に、ＩｎｐｕｔＤｅｖｉｃｅは、ＡＳＮ．１オブジェクトを構築する。次いで、ＳＮＭＰメッセージのバージョン番号を確認する。一致しない場合、メッセージを破棄し、それ以上の動作を行わない。ＳＮＭＰｖ１メッセージで検出されたコミュニティ名が保存される（将来のセキュリティ機構に入力される）。ＩｎｐｕｔＤｅｖｉｃｅは、次いで、構築されたＡＳＮ．１オブジェクトに対して簡単な構文解析を行う。最後に、ＳＮＭＰｖ１  ＰＤＵオブジェクト（ｒｅｑｕｅｓｔ−ｉｄの値が保存されている）に対応するＡＳＮ．１オブジェクトを構築する。
【００６５】
ＳＮＭＰプロセッサは、ＩｎｐｕｔＤｅｖｉｃｅから受信されたＳＮＭＰｖ１  ＰＤＵを分析する。ＳＮＭＰプロセッサは、２つの構成部品、ＯＩＤ変換器およびＰ１５００命令生成器から成る。ＳＮＭＰプロセッサは、ＳＮＭＰプロトコルとＰ１５００プロトコルとの間の情報を変換する。実際に、ＯＩＤ変換器を使用して、ＳＮＭＰプロセッサは、まず、階層型ＯＩＤをフラット化されたＯＩＤに変換する。さらに、テストされるＩＰコアの論理アドレスを回復する。次に、Ｐ１５００命令生成器を使用して、ＳＮＭＰプロセッサは、Ｐ１５００命令を生成し、変換が終了するとすぐ、テスト対象の組み込みコアのテストを監督するために、制御ブロックを稼働させる。
【００６６】
制御ブロックは、ＳＮＭＰプロセッサから次の出力、すなわちＩＰコアの論理アドレス、フラット化されたＯＩＤ、データテスト、およびＰ１５００命令を受信する。Ｄｅｔｅｒｍｉｎｉｓｔｉｃ  Ｆｉｎｉｔｅ  Ａｕｔｏｍａｔｉｏｎ（ＤＦＡ）を使用して、制御ブロックは、ＷＩＰ信号（Ｗｒａｐｐｅｒ  Ｉｎｔｅｒｆａｃｅ  Ｐｏｒｔ）として知られているＰ１５００制御信号、およびＷＳＩ信号（Ｗｒａｐｐｅｒ  Ｓｅｒｉａｌ  Ｉｎｐｕｔ）として知られているデータ信号を生成する。テストプロセスが終了すると、ＤＦＡは、データバッファ（ＤＢ）内に、ＷＳＯ信号（Ｗｒａｐｐｅｒ  Ｓｅｒｉａｌ  Ｏｕｔｐｕｔ）を介して組み込みコアから来るテスト応答を蓄積する。
【００６７】
図１４は、ＵＭＬ表記法を使用した簡単な形のＤＦＡ状態遷移図を示している。この図は、状態を表す角丸長方形、および状態間の遷移を表すための有向直線セグメントから成る。１つまたは複数の動作を、各遷移に関連付けることができる。第１の段階で、初期状態から始まり、制御ブロックはＰ１５００命令を実行する。しかし、ＤＦＡは、まず、レジスタＷＩＲ（Ｗｒａｐｐｅｒ  Ｉｎｓｔｒｕｃｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）内のデータを捕捉する。実際には、データの並列捕捉はオプションであり、並列ＴＡＭでのみ使用される。次いでＤＦＡは、Ｐ１５００命令をＷＩＲにシフトする。最後に、この有限状態機械は、ＷＩＲにシフトされた命令を更新（稼働）する。第２段階で、制御ブロックは、テストベクトルを適用する。ＤＦＡは、テストベクトルをＷＩＲ回路によって選択されたデータレジスタＷＤＲ（Ｗｒａｐｐｅｒ  Ｄａｔａ  Ｒｅｇｉｓｔｅｒ）にシフトする。次いで、ＩＰコア内のテストベクトルを更新する。最後に、最終段階で、ＩＰコア出力ピンのレベルで応答を待った後、制御ブロックは、応答をＤＢにシフトすることによって、テスト応答を取り出す。
【００６８】
ＯｕｔｐｕｔＤｅｖｉｃｅは、ＳＮＭＰプロセッサからデータ応答を受信する。ＯｕｔｐｕｔＤｅｖｉｃｅは、まず、入力として、保存されているｒｅｑｕｅｓｔ−ｉｄ値、および要求の処理の結果戻されたＥｒｒｏｒ−Ｓｔａｔｕｓ、Ｅｒｒｏｒ−Ｉｎｄｅｘ、ＶａｒＢｉｎｄＬｉｓｔの値を使用して、ｇｅｔ−ｒｅｓｐｏｎｓｅ  ＰＤＵを構築する。ＰＤＵおよびコミュニティ文字列は、ＳＮＭＰｖ１メッセージを生成するために使用される。次いでメッセージは、ＡＳＮ．１のＢＥＲを使用して直列化（符号化）される。次いでＯｕｔｐｕｔＤｅｖｉｃｅは、トランスポートサービスを使用して、要求からのマネージャアドレスにＳＮＭＰｖ１メッセージを送信する。
【００６９】
ＩｎｐｕｔＤｅｖｉｃｅおよびＯｕｔｐｕｔＤｅｖｉｃｅは、それぞれ入力メッセージおよび出力メッセージを復号し、符号化するＢＥＲに基づく。ＢＥＲは、ＡＳＮ．１で指定されたタイプの転送構文について一連の手順を指定する。転送構文は、あるネットワークエンティティから別のネットワークエンティティに送信されるオクテットの実際の表現である。
【００７０】
表Ｖは、プロキシエージェントの実装結果をまとめている。
【表５】
2007524947.tif 000007
【００７１】
最初の３行は、３つのブロック、ＩｎｐｕｔＤｅｖｉｃｅ、ＯｕｔｐｕｔＤｅｖｉｃｅ、レジスタファイルを含むＳＮＭＰラッパーの面積オーバーヘッドを示している。レジスタファイルは、ＩｎｐｕｔＤｅｖｉｃｅによって非直列化されたＳＮＭＰメッセージのフィールドを格納するメモリを表す。次の２行は、それぞれＳＮＭＰプロセッサおよび制御ブロックの両方の面積オーバーヘッドに関係する。次の行には、プロキシエージェントの最大周波数が示されている。実際に、現在のＳｏＣは、非常に複雑であり、数千万ものゲートを組み込んでいる。エージェントプロキシは、使用されたベンチマークのｂ１７など、簡単なＩＰ  ｃａｎｅに等しい追加された論理を必要とする。
【００７２】
以下の文書および出版物は、参照により本明細書に組み込まれ、本発明によって実施された技術およびプロトコルのそれ以上の詳細については、これらを調べることができる。
「文献リスト」
[1] E. J. Marinissen, Y. Zorian, R. Kapur,T. Taylor, and L. Whetsel. Towards a standard for embedded core test: Anexample, In IEEE International Test Conference (ITC), pp 616-627, New Jersey,USA, September 1999. 
[2] Y. Zorian, Embedded Tutorial :System-Chip Test Strategies, 35e"annual ACM IEEE conference on Design AutomationConference, pp 752-757, California, USA, June 1998. 
[3] E. J. Marinissen and Y. Zorian,Challenges in Testing Core-Based System ICs, IEEE Communication Magazine, Vol37, No. 6, pp. 104- 109, June 1999. 
[4] E. J. Marinissen, R. Kapur and Y. Zorian,On Using IEEE P 1500 SECT for Test Plug-n-Play. IEEE International TestConference (ITC), pp 770- 777, New Jersey, USA, October 2000.
[5] IEEE P1500 Web Site. http://grouper.ieee. orglgroups/1500/, March 2004. 
[6] The Internet Engineering Task Force (IETF).RFC document database. http://www. ietf. org/, January 2004. 
[7] D. Perkins and E. McGinnis,Understanding SNMP MJBs, Prentice Hall, mc, New Jersey, 1997. 
[8] D. R. Mauro and K. J. Schmidt,Essential SNMP, O'Reilly, California, 2001. 
[9] J. Case, M. Fedor, M. Schoffstall and1. Davin, A Simple Network Management Protocol (SNMP), RFC 1157, SNMP Research,Performance Systems International, and MIT LCS, May 1990. 
[10] M. Goto and K. D. Hilleges, TheD&num;T-Age ATE ArchitectureThe Multi- Port ATE, in SEMICON SEMI TechnologySymposium (STS), pp. 82-91, Chiba, Japan, December 2000. 
[11] D. Harrington, R. Presuhn and B.Wijnen, An Architecture for Describing Simple Network Management Protocol(SNMP) Management Frameworks, RFC 3411, STD 62, December 2002. 
[12] M. L. Bushnell and V. D. Agrawal,Essentials of-Electronic Testing for Digital, Memory, and Mixed-Signat VLSICircuits, Kluwer Academic, pp 690,2000. 
[13] F. Braun, J. W. Lockwood and'M.Waldvogel, Layered Protocol Wrappers for Internet Packet Processing inReconfigurable Hardware, Proc. of Hot Interconnects 9 (HotI-9), pp. 93-98, California, USA, Aug 2001. 
[14] 1. W. Lockwood, C. E. Neely, C. K.Zuver, J. Moscola, S. Dharmapurikar and D. Lim, An Extensible,System-On-Programmable-Chip, Content- Aware Internet Firewall,Field-Programmable Logic and Applications, FPL'03, pp 859-868, Lisbon, PortugalOctober 2003. 
[15] i. Moscola, J. W. Lockwood, R. P. Louiand M. Pachos, Implementation of a Content-Scanning Module for an InternetFirewall, lith Annual IEEE Symposium on Field-Programmable Custom ComputingMachines, FCCM'03, pp 31-38, California, USA, April 2003. 
[16] John W. Lockwood, James Moscota, DavidReddick, Matthew Kulig and Tim Brooks, Application of Hardware AcceleratedExtensible Network Nodes for Internet Worm and Virus ; Protection, ActiveNetworks, IFIP TC6 5th International Workshop, IWAN'03, pp 44-57, Kyoto, Japan,December 2003. 
[17] J. Postel, User Datagram Protocol, RFC768, ISI, August 1980. 
[18] J. Case, K. McCloghrie, M. Rose and S.Waldbusser, Coexistence between Version 1 and Version 2 of theInternet-standard Network Management Framework, RFC 1908, SNMPv2 Working Group,SNMP Research inc, Cisco Systems inc, Doyen Beach Consulting inc, INS,Standards Track, January 1996. 
[19] D. Levi, P. Meyer and B. Stewart,SNMPv3 Applications, RFC 2273, SNMP Research inc, Secure Computing Corporation,Cisco Systems, Standards Track, January 1998. 
[20] IEEE Standard Board. IEEE std 1149.1-1990,. standard test access port and boundary scan architecture, New York, NY 10017-2394, 1990. 
[22] International Organization forStandardization (ISO), Specification of Abstract Syntax Notation One (ASN. 1),International Standard, ISO- 8824,1987. 
[23] M. Rose and K. McCloghrie, Structureand Identification of Management Information for TCP/IP-based Internets, RFC1155, Performance Systems International and Hughes LAN Systems, May 1990. 
[24] J. Case, K. McCloghrie, M. Rose and S.Waldbusser, Protocol Operations for version 2 of the Simple Network ManagementProtocol (SNMPv2), RFC 1448, SNMP Research, Hughes LAN Systems, Doyen BeachConsulting, Carnegie Mellon University, April 1993. 
[25] J. Rumbaugh, I. iacobson and G. Booch, The Unified Modelling Language ReferenceManual, Addison-Wesley, 1999. 
[26] Information processing systems-OpenSystems Interconnection, Specification of Basic Encoding Rules for AbstractNotation One (ASN. 1), International Organization for Standardization,international Standard, ISO-8825, December 1987. 
[27] Politecnico di Tonna ITC'99benchkmarks, downloadable at the URL. http://www. cad. polito. ititools/itc99.html, 1999. 
[28] R. Frye, D. Levi, S. Routhier and B.Wijnen, Coexistence between Version 1, Version 2, and Version 3 of theInternet-standard Network Management Framework, RFC 3584, BCP 74, August 2003 
【図面の簡単な説明】
【００７３】
【図１】一般的なＳＮＭＰ環境を示す図である。
【図２】ＳＮＭＰベースのＳｙｓｔｅｍ  ｏｎ  ｃｈｉｐ  ＳｏＣのテストの一般的な原理を示す図である。
【図３】ＩＥＥＥ  Ｐ１５００の拡張可能なアーキテクチャの概要を示す図である。
【図４】ＡＴＥによってリモートに管理されているテストを処理する間のネットワーク管理局（ＡＴＥ）と集積回路チップ（ＳｏＣ）との間での情報交換を示しているシーケンス図である。
【図５】ネットワーク管理局（ＡＴＥ）と集積回路チップ（ＳｏＣ）との間の基本的なＳＮＭＰメッセージを示す図である。
【図６】本発明による集積回路チップを示す概略図である。
【図７】本発明による管理情報ベースＭＩＢの構造を示す図である。
【図８】本発明による集積回路チップの通信手段の一部であるプロキシエージェントの動作モードを示す図である。
【図９】本発明による集積回路チップの各ＩＰコアの周りに配置されている拡張されたＰ１５００ラッパーのアーキテクチャを示す図である。
【図１０】ベンチマークＩＴＣ９９に適合する本発明による簡単なＰ１５００ラッパーおよび拡張されたＰ１５００ラッパーの合成結果を示す図である。
【図１１】ＩＰコアの入力／出力数に従ってラッパーによって占められる総面積を示す図である。
【図１２】本発明による集積回路チップの通信手段の一部であるハードウェアベースのプロキシエージェントのアーキテクチャの一例を示す図である。
【図１３】本発明による集積回路チップの通信手段の一部であるプロキシエージェントのアーキテクチャをより正確に示す図である。
【図１４】プロキシエージェント内のＤＦＡ（Ｄｅｔｅｒｍｉｎｉｓｔｉｃ  Ｆｉｎｉｔｅ  Ａｕｔｏｍａｔｉｏｎ）の状態遷移図の概要を示す図である。
【図１】
2007524947.tif 000008
【図２】
2007524947.tif 000009
【図３】
2007524947.tif 000010
【図４】
2007524947.tif 000011
【図５】
2007524947.tif 000012
【図６】
2007524947.tif 000013
【図７】
2007524947.tif 000014
【図８】
2007524947.tif 000015
【図９】
2007524947.tif 000016
【図１０】
2007524947.tif 000017
【図１１】
2007524947.tif 000018
【図１２】
2007524947.tif 000019
【図１３】
2007524947.tif 000020
【図１４】
2007524947.tif 000021
【国際調査報告】
2007524947.tif 000022
2007524947.tif 000023