JP2008513853A - マルチコアアーキテクチャーにおけるデバッグ - Google Patents

Abstract

スレッドを処理するための複数のインターコネクトされたプロセッサーエレメントを備えるマルチコアプロセッサーアーキテクチャー内においてスレッドの実行を監視する方法であって、この方法は、１つのスレッドまたは複数のスレッドの機能および／またはアイデンティティーおよび／または実行ロケーションに関する１つ以上のパラメータの複数のスレッドパラメータインジケータを受信するステップと、スレッドパラメータインジケータの中の少なくとも１つを、関心のあるインジケータをそれぞれが表現する第１の複数の予め定義された基準と比較するステップと、上記比較の結果として関心のあるものであると識別されたスレッドパラメータインジケータによって得られる出力を生成するステップとを備える。
【選択図】図１

Description

発明の分野

本発明は、マルチコアアーキテクチャーにおいてデバッグするための方法および装置に関する。

発明の背景

近年、シリコン効率（すなわち、「アプリケーション利用可能」ＭＩＰｓ／ｍｍ^２またはＭＩＰｓ／ｍＷ）を最大化するために、複数のコアを含むプロセッサーを製造する傾向にある。このようなマルチコアアーキテクチャーは、スレッドに基づいてアプリケーションを実行するのに十分に適したものである。なぜなら、スレッドは、実行状態、命令ストリーム、およびデータセットを含む作業の独立パッケージを定義するからであり、定義によって、それは、その他のスレッドと同時に実行してもよい。しかしながら、実行のこの並列化は、それらのマルチコアアーキテクチャーで使用されるソフトウェアデバッグプロセスに付加的な問題をもたらす。ソフトウェアデバッグは、コンピュータアプリケーションを実行するときに発生するエラーを突き止めて修正することを意味する一般的な用語である。

ソフトウェアデバッグにおいて遭遇する大きな問題の１つは、ハイゼンベルグバグ（「プローブ効果」としても知られている）である。デバッグのために、例えば、システム診断のレベルを向上させるために付加されるいかなるコードも、スレッドを同時におよび／または並列に実行するタイミングを微妙に変化させる可能性がある。これは、さもなければそのアプリケーションの生産開始時に観察され得るバグを隠すという危険性をもたらす。また、大規模なデバッグコードがビルド内に存在するとき、有意義な性能測定および性能評価を達成することは、難しいことである。これは、キャッシュ性能およびインターコネクト性能が、付加的なコードによって影響され得ること、およびそれが、コードサイズにより明白な影響を及ぼすことのような二次効果によるものである。

さらに、その製造に使用された大規模なリソースのために、このようなマルチコアアーキテクチャーのために製造されたソフトウェアの再利用性を改善することが強く要望されている。従来、マルチコアアーキテクチャーのためのアプリケーションは、特別注文に基づいて記述され、そのために、あまり移植性のないハードウェア固有アプリケーションをもたらしてきた。さらには、また、これらのアプリケーションのデバッグは、極めて専門化されたものであった。

発明の概要

本発明の第１の態様によれば、スレッドを処理するための複数のインターコネクトされたプロセッサーエレメントを備えるマルチコアプロセッサーアーキテクチャー内においてスレッドの実行を監視する方法が提供され、この方法は、１つのスレッドまたは複数のスレッドの機能および／またはアイデンティティーに関する１つ以上のパラメータを指示する複数のスレッドパラメータインジケータを受信するステップと、スレッドパラメータインジケータの中の少なくともいくつかを、関心のあるインジケータをそれぞれが表現する第１の複数の予め定義された基準と比較するステップと、上記比較の結果として関心のあるものであると識別されたスレッドパラメータインジケータによって得られる出力を生成するステップとを備える。

これは、とりわけ、スレッドレベルのデバッグのために、コードを付加することを必要とせずに、マルチコアプロセッサーアーキテクチャー上で実行されるアプリケーションをスレッドレベルでデバッグおよびトレースする能力を提供する。さらにまた、これは、付加的コードを導入することなく、すなわち、プローブ効果をもたらすことなく、マルチコアアーキテクチャーアプリケーションのデバッグを可能にするという利点を提供する。

本発明のさらなる態様によれば、複数のインターコネクトされたプロセッサーエレメントを有するマルチコアプロセッサーアーキテクチャーのためのスレッドレベルのソフトウェアデバッグコントローラが提供され、それぞれのエレメントは、スレッドを処理するためのリソースを提供し、デバッグコントローラは、上記プロセッサーエレメントのそれぞれと通信できる状態にあり、かつ、マルチコアプロセッサーアーキテクチャー内におけるスレッドの割り付けおよび実行を監視するための監視ロジックを備える。

本発明は、様々な形で実施されてもよい。以下、いくつかの実施形態を、添付の図面を参照して、単なる例として説明する。

特定の実施形態の詳細な説明

図１は、典型的なマルチコアアーキテクチャーの一例のシステムフレームワークの論理的ブロック図を示す。フレームワークは、複数の処理リソース１５０を備え、それらの処理リソース１５０のそれぞれは、マルチコアアーキテクチャー内におけるその他の処理リソース１５０に類似するものであってもよく、あるいは、異なるものであってもよい。処理リソース１５０は、命令を実行することのできるいかなる形態のハードウェアであってもよく、したがって、それに等価なものは、汎用処理リソース１５０を含んでもよく、あるいは、効率的に限定された命令セットを備える処理リソース１５０、例えば、入出力装置を含んでもよい。

システムフレームワークは、また、集中スレッド管理および割り付けシステムを備え、その集中スレッド管理および割り付けシステムは、スレッド管理および割り付けコントローラ１３０と、メモリーインタフェース１８０を介してコントローラに接続された専用密結合メモリー１９０とを含む。それぞれの処理リソース１５０は、インターコネクト１１５を介してコントローラ１３０にアクセスすることができる。図１に示される構成を実施するには、特別なインターコネクトストラテジー（すなわち、コントローラ１３０が、それぞれの処理リソース１５０と通信する構成およびその逆の構成、およびそれぞれの処理リソース１５０が、システムリソース、例えば、メモリー１４０と通信する構成）を必要としないことを理解すべきである。具体的には、処理リソース１５０のそれぞれがコントローラ１３０と直接にまたは間接的に通信することができなければならないということを除けば、ポイントツーポイントリンク、中央システムバス、あるいは、パイプライン型アーキテクチャーでさえもが、同じように使用されてもよい。

図２は、やはり単なる例として、図１の論理的構成を実施するマルチコアプロセッサーを示す。図２のマルチコアプロセッサーは、複数の処理リソース１５０を使用し、それらの処理リソース１５０のそれぞれは、システムインターコネクト１６０を介して接続される。そして、そのシステムインターコネクト１６０は、入力インタフェース１００および出力インタフェース１１０を介して、コントローラ１３０と通信する。図３の例においては、システムインターコネクト１６０は、伝統的な中央バスとして配置され、その中央バスは、処理リソース１５０のそれぞれを、互いに接続し、コントローラ１３０に接続し、また、システムメモリーのような共有システムリソース１４０に接続する。共有システムリソース１４０とのインタフェースは、現時点において利用可能ないくつかのインタフェース技術の１つによって達成されてもよい。メモリーは、現時点において利用可能な中央コンピュータメモリー技術、例えば、スタティックランダムアクセスメモリー（ＳＲＡＭ）、ダイナミックランダムアクセスメモリー（ＤＲＡＭ）、または、ダブルデータレートランダムアクセスメモリー（ＤＤＲ ＲＡＭ）のいずれかから構成されてもよい。

図２からわかるように、複数の処理リソース１５０のそれぞれは、対応するコントローラクライアント１２０を有し、それらのコントローラクライアント１２０は、中央コントローラ１３０から制御情報を受信するように構成され、かつ、受信した制御情報に基づいて処理リソース１５０を管理するように構成される。コントローラクライアント１２０の機能および目的は、以下でより詳細に説明される。また、それぞれの処理リソース１５０は、システムインターコネクト１６０を介してコントローラ１３０と通信するために、対応するインターコネクトエージェント１７０を有する。インターコネクトエージェント１７０は、コントローラクライアント１２０に汎用インタフェースを提供し、その汎用インタフェースは、システムインターコネクト１６０上で使用される下位インターコネクトプロトコルから独立したものである。すなわち、汎用インタフェースは、システムインターコネクト１６０上で使用される通信プロトコルとコントローラクライアント１２０によって使用される通信プロトコルとの間のプロトコル変換を提供する。インターコネクトエージェント１７０を使用することにより、本発明の実施形態のコントローラクライアント１２０は、現時点において利用可能なあらゆるシステムインターコネクトプロトコルとともに使用されてもよい。実際に、それを介してコントローラクライアント１２０がコントローラ１３０と通信するインタフェースプロトコル１１５は、処理リソース１５０と、共有システムリソース１４０、例えば、システムメモリーとの間の通信を可能にするために配置されるインタフェースプロトコル１６０のいずれかまたはすべてと物理的に異なっていてもよく、また、異なる性質を有していてもよい。

マルチコアプロセッサー１０は、全体的に見れば、ターゲットアプリケーションを実行するように構成され、そのターゲットアプリケーションは、スレッドと呼ばれるいくつかの個々のタスクに分解されてもよい。それぞれの処理リソース１５０は、コントローラ１３０によって、適切なスレッドを割り付けられる。この割り付けは、限定はされないが、そのスレッドの優先順位、それぞれの処理リソース１５０のアベイラビリティー、および特定のスレッドを実行する特定の処理リソース１５０の適合性を含む多くのパラメータに基づいて、実行される。

しかしながら、コントローラ１３０およびその専用メモリー１９０を付加することは、プロセッサー１０のレイアウトの再設計を特に必要としないことを理解すべきである。

１つの具体的な構成が、図３に示され、その図３は、典型的なシステムオンチップ（ＳｏＣ）アーキテクチャーをブロック図の形で示し、かつ、実用化されたコントローラ１３０の制御下に置かれた様々な処理リソース１５０を示す。処理リソース１５０は、とりわけ、ＤＳＰのように、比較的に総合的な能力を有してもよく、あるいは、周辺ＩＯのように、比較的に限定された機能を有してもよいことに注意されたい。

図４は、コントローラ１３０、およびその対応する入力インタフェースグループ１００、出力インタフェースグループ１１０、および２つの双方向インタフェースグループ１６０および１８０を示し、それぞれのグループは、コントローラ１３０の周辺に配置される。

システム制御グループ１０２は、コントローラ１３０の正しい動作を保証するのに必要な多種多様な信号を備える。これらには、システムクロック、リアルタイムクロック、およびリセット信号（ＲＳＴ）が含まれる。コントローラ１３０からのすべての出力信号は、システムクロックに同期しているが、それらは、システムによって必要とされるならば、その他のクロックドメインに再同期させられてもよい。処理に先だって、コントローラ１３０へのすべての入力信号は、システムクロックに同期させられる。ＲＳＴ入力は、コントローラ１３０をリセットするための同期リセット信号である。

外部割り込みグループ１０１は、管理および割り付けシステムの外部から発生する外部割り込みのグループからなる。外部割り込みグループ１０１内の信号は、例えば、外部との入力インタフェースから供給されてもよく、あるいは、マルチコアプロセッサーの外部からピンを介して直接に供給されてもよい。外部割り込み入力の数は、マルチコアプロセッサー１０の設計段階中に定義されてもよい。

内部制御グループ１１１は、コントローラクライアント１２０およびその対応する処理リソース１５０ごとの同期割り込みからなる。したがって、信号の数は、典型的には、システム内の処理リソース１５０の数に対応し、かつ、マルチコアプロセッサー１０の設計段階中に定義される。内部割り込み信号は、内部スレッドレディー割り込み信号であり、スレッドを実行できるレディー状態にあること、およびそのコントローラクライアント１２０に対応する特定の処理リソース１５０にそのスレッドが割り当てられていることを指示する。

デバッグインタフェースグループ１１２は、次の３つのサブグループからなる。
１．補助デバッグインタフェース。これは、外部デバッグエージェントが、コントローラ１３０におよびシステム全体にデバッグアクセスするのを可能にする。このインタフェースを介して、ブレークポイントおよびウォッチポイントが、内部的かつ外部的にセットされてもよく、そして、システム状態情報が、読み出されてもよい。
２．トレースバッファー出力。これは、一組の予め設定されたフィルタリングガイドラインに基づいて、また、デバッグマネージャー４００の最終的な制御下において、ランタイムシステム状態を提供するストリーミング出力である。
３．外部デバッグイネーブル信号。これは、独立したブレークポイント信号として使用されてもよく、あるいは、処理リソースに固有のイネーブルと組み合わせられてもよい。

上述したデバッグインタフェースグループの特定の形式、構成、および使用法が、以下でより詳細に説明される。

密結合メモリーインタフェースグループ１８０は、コントローラ１３０をそれ自体の専用密結合メモリーリソース１９０にインタフェース接続する。

図５は、専用密結合メモリー１９０の典型的な構造を示す。アドレスパスおよびデータパスの幅は、マルチコアプロセッサー１０の設計段階中に定義される。専用密結合メモリーインタフェース１８０は、メモリーアドレスバス１９１、メモリー読み出しデータバス１９２、メモリー書き込みデータバス１９３、および書き込みイネーブル信号１９４および読み出しイネーブル信号１９６を含む。

付加メモリーは、同期型ＳＲＡＭデバイスであると仮定する。専用密結合メモリー１９０は、ターゲットアプリケーションの必要性に基づいて、マルチコアプロセッサー１０の設計段階中に定義された整数のコントローラメモリーエレメント１９５を含む。現時点において好ましい実施形態においては、それぞれのコントローラメモリーエレメント１９５は、２５６ビットのメモリー空間を消費する。現時点において好ましいさらなる実施形態においては、コントローラは、最大６５，５３６個のコントローラメモリーエレメント（すなわち、１６Ｍｂメモリー）をサポートする。キュー記述子は、以下で説明するように、典型的なシステムにおいてコントローラメモリーエレメント１９５を消費するが、必要とされるコントローラメモリーエレメント１９５の数は、スレッドサポート要件によって決定される。例えば、コントローラ１３０内において４００個のスレッドを同時にサポートすることのできるシステムは、約１２８ｋｂの付加メモリーを必要とする。

図４のインターコネクトインタフェースグループ１６０は、マルチコアプロセッサー１０およびインターコネクトエージェント１７０で使用される選択されたインターコネクトプロトコル（１つ以上）に準拠し、それは、マルチコアプロセッサーの設計段階中に定義される。複数の異なるインターコネクト構造が存在する場合、インターコネクトインタフェースグループ１６０は、恐らくは異なる複数のインタフェースから構成され得る。図示される実施形態においては、バスインタフェースが、使用される。それにもかかわらず、これまでに示唆されたように、その他の様々な形態のインタフェースが同じように使用されてもよいことは明らかなことである。

（コントローラサブブロックの説明および機能）
図６は、コントローラ１３０の主要な論理的コンポーネントを示す。コントローラ１３０の機能は、次の機能を実行する４つの主たる内部並列処理サブブロックに分割される。
１．スレッド入力マネージャー（ＴＳＩＭ）２００。これは、専用密結合メモリー１９０内に存在するフリーコントローラメモリーエレメント１９５のリストを維持するように構成され、かつ、コントローラメモリーエレメント１９５のリカバリーを監視するように構成される。
２．スレッド同期マネージャー（ＴＳＰＭ）２１０。これは、専用密結合メモリー１９０内に存在するペンディングリストおよびタイマーキューを維持するように構成され、スレッド間の同期を達成するように構成され、そして、必要であれば、専用密結合メモリー１９０内に存在するレディーキュー構造へスレッドを昇格させるように構成される。スレッド同期マネージャー２１０は、専用密結合メモリー１９０内に存在するペンディングスレッド記述子の挿入および抽出を介して、ペンディングキューおよびタイマーキュー構造の完全性を維持する。
３．スレッド出力マネージャー（ＴＳＯＭ）２２０。これは、専用密結合メモリー１９０内に存在するレディーキュー構造、および専用密結合メモリー１９０内に存在する処理リソース１５０ごとのディスパッチキューを維持するように構成される。スレッド出力マネージャー（ＴＳＯＭ）２２０は、さらに、コントローラクライアント１２０へ送信される割り込み１１０を生成するように構成される。レディーキュー構造の完全性の維持は、専用密結合メモリー１９０内において、コントローラメモリーエレメント１９５に保持されたスレッド記述子を挿入および抽出することによって、実行される。
４．スレッドスケジュールマネージャー（ＴＳＳＭ）２３０。これは、専用密結合メモリー１９０内に配置されたレディーキュー構造内に処理リソース１５０ごとのスケジューリング決定を提供するように構成される。

さらに、いくつかの二次的な処理サブブロックが、次のサポート機能を提供する。
５．スレッドメモリーマネージャー（ＴＳＭＭ）２４０。これは、付加専用密結合メモリー１９０への集合アクセスを提供するように構成され、相互の排他性およびロッキングを含む。
６．割り込みマネージャー（ＴＳＩＣ）２５０。これは、入力外部システム割り込みを内部同期プリミティブに変換するように構成される。
７．時刻マネージャー（ＴＳＴＣ）２６０。これは、同期のためのタイマー機能、およびそれぞれの処理リソース１５０に対するウォッチドッグタイマー機能を提供するように構成される。
８．システムインタフェース（ＴＳＩＦ）２８０。これは、マルチコア処理リソース１５０およびコントローラ１３０内に存在する個々のサブブロックへのインターコネクトインタフェースおよび設定とランタイムアクセスとを提供するように構成される。
９．サーバーシム（ＴＳＳＳ）２９０。これは、コントローラ１３０とマルチコア処理リソース１５０との間の物理的なインタフェース１１５を提供するように構成される。

上で列挙した主たるサブブロックおよび二次的なサブブロックのそれぞれは、また、デバッグ出力を含み、デバッグインタフェース１１２の一部分を構成し、その信号に対応するそれぞれのサブブロック内において発生したイベントを本発明のデバッグコントローラ４００に通知する。コマンドが、特定の条件を備えてもよい場合、ステータスフラグが、サブブロック内において管理される。

一般論として、コントローラ１３０は、専用コントローラメモリー１９０内に存在するいくつかのキュー構造を維持することによって、スレッドを管理する。これらのキュー構造には、ペンディングキュー、レディーキュー、タイマーキュー、およびディスパッチキューが含まれる。実行を待っているスレッドは、これらのキューの１つ以上の中に保持され、それらのスレッドがレディー状態になれば、適切な処理リソース１５０に割り付けられる。キュー内に存在するスレッドの操作は、主に、プッシュオペレーション、ポップオペレーション、およびソートオペレーションを用いて実行される。コントローラ１３０の動作の十分に詳細な説明は、同時係属出願である米国特許出願第１０／３０８，８９５号に記載されており、その明細書は、その全体が、参照として本明細書に組み込まれる。

ここで、コントローラ１３０内に存在する上述した主たる処理サブブロックおよび二次的なサブブロックの相互作用を詳細に説明する。

それぞれのサブブロックは、一組の関数を他のサブブロックに提供し、それぞれのサブブロックが、そのピアに、専用密結合メモリー１９０内においてそれらのそれぞれが維持する構造を操作するように命令するのを可能にする。関数は、コントローラソフトウェアアプリケーションプログラミングインタフェース（ＡＰＩ）において受信された類似コマンドを受信したとき、特定のサブブロックによってコールされる。

（スレッド入力マネージャー関数）
スレッド入力マネージャー２００は、３つのパブリック関数を、コントローラ１３０内に存在するその他のサブブロックに提供する。

ＦｒｅｅＬｉｓｔＳｔａｔｕｓ関数は、コントローラメモリーエレメント１９５のフリーリストの先頭ポインタ、およびその中に存在するエレメントの数を返す。フリーリストは、現時点において未使用のコントローラメモリーエレメント１９５のリストである。この関数は、コントローラ１３０ソフトウェアＡＰＩにおいて類似コマンドを受信したとき、システムインタフェース２８０だけがコールすることができる。

ＰｕｓｈＦｒｅｅＩｎｄｅｘ関数は、解放されたコントローラメモリーエレメント１９５のインデックスをフリーリスト上にプッシュバックするのに使用される。この関数は、スレッドスケジュールマネージャー２３０だけがコールすることができる。

ＰｏｐＦｒｅｅＩｎｄｅｘ関数は、フリーコントローラメモリーエレメント１９５のインデックスをフリーリストからポップするのに使用される。これは、典型的には、システムインタフェース２８０内のＡＰＩコールサービスルーチン内からコールされる。

（スレッド同期マネージャー関数）
スレッド同期マネージャー２１０は、７つのパブリック関数を、コントローラ１３０内に存在するその他のサブブロックに提供する。

次の５つの関数は、コントローラ１３０のソフトウェアＡＰＩによって受信された類似コマンドに応じて、システムインタフェース２８０だけがコールすることができる。

ＰｕｓｈＰｅｎｄｉｎｇＤｅｓｃｒｉｐｔｏｒ関数は、ペンディングキュー記述子をペンディングキュー記述子のリストに追加するために、ブートプロセス中に使用される。

ＰｕｓｈＴｈｒｅａｄ関数は、従属スレッドを所定のペンディングキューに追加するために、ランタイム中に使用される。

ＧｅｔＴｉｍｅｒＳｔａｔｕｓ関数は、タイマーキューの先頭ポインタおよびその中に存在するエレメントの数を返す。

ＳｅｔＴｉｍｅｒＳｔａｔｕｓ関数は、タイマーキューの先頭ポインタおよびその中に存在するエレメントの数をセットする。

ＳｅｔＰｅｎｄｉｎｇＳｔａｔｕｓ関数は、ペンディングキュー記述子リストのステータスをセットする。

ＧｅｔＰｅｎｄｉｎｇＳｔａｔｕｓ関数は、ペンディング記述子キューの先頭ポインタおよびその中に存在するエレメントの数を返す。

ＳｙｎｃＥｖｅｎｔ関数は、同期プリミティブを所定のペンディングキューに発行するのに使用される。この関数は、スレッド割り込みマネージャー２５０またはシステムインタフェース２８０のいずれかによってコールされる。

ＴｉｍｅＥｖｅｎｔ関数は、タイマーに基づいた同期プリミティブをタイマーキューに発行するのに使用される。この関数は、時刻マネージャー２６０だけによってコールされる。

（スレッド出力マネージャー関数）
スレッド出力マネージャー２２０は、５つのパブリック関数をコントローラ１３０内に存在するその他のサブブロックに提供する。

Ｐｕｓｈ関数は、スレッド記述子をレディーキュー構造内に配置する。このメソッドは、システムインタフェース２８０またはスレッド同期マネージャー２１０のいずかによってコールされてもよく、また、それは、処理速度を増大させるために（例えば、割り込みをハンドルするために）、高い優先順位でコールされてもよい。スレッドが、独立したものであれば（即座にレディー状態となる）、コールは、システムインタフェース２８０から形成され、スレッド記述子が、もともと、従属性を有していれば、コールは、スレッド同期マネージャー２１０から形成される。

次の関数は、コントローラ１３０のソフトウェアＡＰＩにおいて類似コマンドが受信されたことに応じて、システムインタフェース２８０だけがコールすることができる。

ＧｅｔＤｉｓｐａｔｃｈＱｕｅｕｓＳｔａｔｕｓ関数は、ディスパッチキューリストの先頭ポインタおよびその中に存在するエレメントの数を返す。

ＳｅｔＤｉｓｐａｔｃｈＱｕｅｕｅＳｔａｔｕｓ関数は、ディスパッチキューリストの先頭ポインタおよびその中に存在するエレメントの数をセットする。

ＤｉｓｐａｔｃｈＱｕｅｕｅＳｅｔＭｅｔｒｉｃｓ関数は、現時点において実行されているスレッドのメトリックをセットし、それによって、豊富な情報に基づいたプリエンプション決定をなすことができる。

ＤｉｓｐａｔｃｈＱｕｅｕｅＥｖｅｎｔ関数は、スケジューリングイベントをレディーキュー構造からスレッド出力マネージャー（ＴＳＯＭ）２２０によって管理されるディスパッチキューへ伝達する。この関数は、スレッドスケジュールマネージャー（ＴＳＳＭ）２３０だけによってコールされる。

ＤｉｓｐａｔｃｈＱｕｅｕｅＰｏｐ関数は、ディスパッチキューの先頭からスレッド記述子をポップする。

ＤｉｓｐａｔｃｈＷｏｒｋＱｕｅｕｅＰｕｓｈ関数は、ディスパッチキューをスレッド出力マネージャー２２０の作業キュー上にプッシュする。この関数は、スレッドスケジュールマネージャー２３０だけによってコールされ、そのスレッドスケジュールマネージャー２３０は、スケジュール更新の結果としてディスパッチキュー内において必要な変更を出力マネージャー２２０に通知するのにこの関数を使用する。

（スレッドスケジュールマネージャー関数）
スレッドスケジュールマネージャー２３０は、コントローラ１３０内に配置されたスレッド出力マネージャー２２０およびシステムインタフェース２８０に３つのパブリック関数を提供する。

ＰｕｓｈＰｕｓｈＷｏｒｋＥｖｅｎｔ関数は、スレッド出力マネージャー２２０がスレッド記述子をレディーキュー構造に追加した直後に、そのスレッド出力マネージャー２２０によってコールされる。

ＰｕｓｈＰｏｐＷｏｒｋＥｖｅｎｔ関数は、スレッド出力マネージャー２２０がスレッド記述子をレディーキュー構造に移動した直後に、そのスレッド出力マネージャー２２０によってコールされる。

ＦｒｅｅＩｎｄｅｘ関数は、コントローラメモリーエレメント１９５の解放がスレッドスケジュールマネージャー２３０内で進行中のスケジューリングアクティビティーに適切に同期させられるのを可能にする。このコールは、コントローラ１３０のソフトウェアＡＰＩにおいて類似コマンドを受信したとき、あるいは、スレッド出力マネージャー２２０内におけるポップオペレーションの結果として、発行されてもよい。

（コントローラクライアント）
上述したように、処理リソース１５０という用語は、命令がどれほど初歩的であるかに関係なく、その命令を実行することのできるあらゆるリソースに適用される。したがって、入力／出力モジュールのような固定機能を有するリソースも含まれる。処理リソース１５０の種類に依存して、コントローラクライアント１２０を介したシステムインターコネクト１６０と処理リソース１５０との接続は、単方向または双方向のいずれかであってもよい。

図７は、コントローラ１３０とともに使用するためのコントローラクライアント１２０の例示的なブロック図を示す。

例えば、汎用プロセッサーまたはディジタル信号プロセッサーのような適切な処理リソース１５０上において、コントローラクライアント１２０は、典型的には、ソフトウェアとして実施される。しかしながら、処理リソース１５０が限られた機能しか有していない場合、コントローラクライアント１２０は、ハードウェアコンポーネントを必要としてもよい。

ハードウェアコンポーネントが、システムインターコネクト１６０と処理リソース１５０との間に使用される場合、コントローラクライアント１２０は、同様に、同じインタフェースを用いて処理リソース１５０にインタフェース接続する。すなわち、コントローラクライアント１２０は、コントローラクライアント１２０に対する処理リソース１５０のインタフェースと同じインタフェースをインターコネクトエージェント１７０に提供する。場合によっては、例えば、入力／出力装置の場合のように、処理リソース１５０から外へのデータパスと異なるように、処理リソース１５０の中へのデータパスを取り扱うことは、適切なことである。

主たるインタフェースに加えて、コントローラクライアント１２０は、また、ランタイムイベントおよびデバッグイベントのための出力として使用される帯域外インタフェースを提供する。ソフトウェアコントローラクライアント１２０が、使用される場合、これらは、標準的な割り込みを用いて提供され、適切なサービスルーチンをコールし、あるいは、処理リソース１５０に固有のデバッグおよびトレースユニット１５１への入力を形成する。

（コントローラクライアントモードの動作）
それぞれのコントローラクライアント１２０は、完全な割り込み駆動型である。コントローラ１３０から内部割り込みを受信したとき、コントローラクライアント１２０は、専用密結合メモリー１９０内に保持されたその特定の処理リソース１５０に対応するディスパッチキューの先頭からスレッド記述子をポップする。そして、スレッド記述子内の独特な参照が、さらなるスレッド制御情報すなわちスレッド制御ブロック（ＴＣＢ）を主メモリーリソース１４０から読み出すのに使用される。ＴＣＢ内に含まれる情報は、次のいずれかであってもよい。
１．コントローラクライアント１２０設定コンテンツ。この情報は、コントローラクライアント１２０のシステムリソース使用ポリシー、アドレスまたはデータバストリガー設定（デバッグのために）、データ提供モードなどを設定するのに使用されてもよい。
２．処理リソース１５０の設定コンテンツ。これは、処理リソース１５０に特定のスレッドを実行する準備をさせるのに必要な情報である。これは、このスレッドの以前の部分的な実行からのリカバリーまたはオーディオＣＯＤＥＣのようなスペシャリストハードウェアアクセラレータの設定を含んでもよい。
３．命令コンテンツ。固定機能ハードウェアアクセラレータの場合、「命令」は、ターゲットハードウェア処理リソース１５０において暗黙的なものであり、例えば、処理リソース１５０が出力モジュールであれば、出力命令であり、そして、何らかの必要とされるスペシャライゼーションまたは設定は、設定情報内に収容される。ソフトウェアコントローラクライアント１２０との関連で、これは、典型的には、スレッドに対応するファンクションコードへのポインタである。
４．データコンテンツ。このコンテンツは、システムメモリー１４０内における開始アドレスまたは複数アドレス、およびスレッドが処理し得るデータの範囲を定義してもよい。
５．コントローラクライアント１２０の後処理コンテンツ。このコンテンツは、スレッドの実行が完了した後のコントローラクライアント１２０のアクションを決定する。

コントローラクライアント１２０の次の３つの異なる段階が存在する。
１．処理リソース１５０およびコントローラクライアント１２０が特定のスレッドを実行する準備をさせられる設定段階。最も単純な場合、設定段階は存在しない。
２．スレッドが実行されており、かつ、コントローラクライアント１２０が、データを供給しているか、あるいは、リソースの利用を監視し得る実行段階。
３．完了段階。処理の完了は、何のアクションももたらさないか、別のスレッドの生成をもたらすか、同期プリミティブの発行をもたらすか、あるいは、スレッドの生成および同期の組み合わせをもたらす。さらにまた、コントローラクライアント１２０は、スケジューラーメトリックをセットまたは更新し、かつスレッドを終了するように要求され得る。また、スレッドの実行中にさらなるメモリーが結果を記憶するのに必要とされる場合、コントローラクライアント１２０は、このサーバーメソッドを実行しなければならない。

個々のハードウェアコントローラクライアント１２０ｂが動作期間中にシステムインターコネクト１６０の利用可能な帯域幅を最大限に使用する環境においては、最適化されたソリューションは、コントローラクライアント１２０に複数のハードウェア処理リソース１５０の代理として動作させる。このような構成が、図７ｂに示される。これまでの場合と同様に、代理コントローラクライアント１２０ｂは、割り込み駆動型であるが、これまでの例においては、コントローラ１３０からただ１つの割り込みしかルーティングされないが、代理コントローラクライアントモデルにおいては、割り込みは、処理リソース１５０ごとに存在する。コントローラ１３０から受信された割り込みのインデックスに基づいて、代理コントローラクライアント１２０ｂは、識別された処理リソース１５０上で同じステップを実行する。システムインターコネクト１６０の使用ポリシーが必要とされる代理コントローラクライアントモデルにおいては、ハードウェアアダプタ１２０ｃが、処理リソース１５０とシステムインターコネクト１６０との間に残存する。

上述したように、コントローラクライアント１２０は、ソフトウェアとして実施されてもよい。この場合、コントローラクライアント１２０のいくつかの機能、例えば、共有リソース使用ポリシーは、典型的には、処理リソース１５０のハードウェア（例えば、メモリー管理ユニット（ＭＭＵ））内にすでに存在し得る既存のハードウェアコンポーネントを利用する。

その結果として、ソフトウェアコントローラクライアント１２０のアーキテクチャーおよび実施は、部分的に、処理リソース１５０に固有のものとなる。

また、ハードウェアコントローラクライアント１２０は、対応する処理リソース１５０の特異性に基づいたスペシャリスト要件を有してもよい。以下の段落は、ほとんどの場合において適切なものである汎用アーキテクチャーを説明する。

（ハードウェアコントローラクライアントの一般的な例）
ハードウェアコントローラクライアント１２０の基本構造が、図８に示される。設計の機能的中枢には、コントローラクライアント有限状態機械（ＦＳＭ）３００が存在する。この有限状態機械（ＦＳＭ）３００は、３つの段階のすべてにおいて動作状態であってもよい。コントローラクライアントＦＳＭ３００は、コントローラ１３０からの割り込み１１１によって起動される。

最初に、コントローラクライアントＦＳＭ３００は、共有メモリーリソース１４０からＴＣＢを読み出すために、システムインターコネクト１６０を習得し、そのＴＣＢは、それ自体の命令への参照を含む。設定段階中に、コントローラクライアント１２０は、処理リソースインタフェースを習得してもよく、設定コマンドを解釈し、そして、それらを、処理リソース１５０に発行される書き込みサイクルに変換する。さらに、コントローラクライアント１２０は、それ自体のリソースポリシーを設定する。設定状態から実行状態へどのように遷移するかは、処理リソース１５０に固有のものであるが、明示的な実行プリミティブによって、あるいは、ただ単に、データ転移状態へのエントリーによって、指示されてもよい。

コントローラクライアント１２０の観点から、最も単純なアーキテクチャーは、処理リソース１５０上およびシステム側の両方において同じインタフェースプロトコルを有する。この場合、実行段階中に、処理リソース１５０の読み出し書き込みサイクルは、適切な場所を検査することによって、ただ単に、システムインタフェースにマッピングされる。

最も単純なコントローラクライアント１２０の実施は、システムから処理リソース３１０へのパスおよび処理リソースからシステム３２０へのパスの両方においてＦＩＦＯ方式インタフェースを要求する。この性質を有するコントローラクライアント１２０の実行段階中に、データは、メッセージモードまたはストリーミングモードによって、処理リソース１５０へ提供されてもよい。処理の前にデータセット全体がコントローラクライアント１２０内に局所的に蓄積されるメッセージモードは、よりきめの粗いむらのあるインターコネクトビヘイビアを発生させ、それは、より複雑なインターコネクトアービタを実現するのを助けることができる。データがシステムメモリー１４０から処理リソース１５０内へ直接にストリーミングされるストリーミングモードは、ハンドシェーキングをより入念に考察することを必要とし、きめの細かいインターコネクトトランザクションを呈し、かつ、インターコネクト性能に密結合するより大きなシリコン効率のソリューションを提供する。

実行段階から完了段階への遷移は、処理リソース１５０へのデータの提供を測定することによって推定されてもよく、あるいは、処理リソース１５０自体によって明示的に通知されてもよい。完了段階中に、コントローラクライアント１２０は、再度、元々のスレッド制御ブロックによって提供される命令の組から実行する。

場合によっては、処理リソース１５０（例えば、入力／出力装置）の中へのパスおよび処理リソース１５０から外へのパスを異なるものとして取り扱うことが適切であることに注意されたい。対照的に、場合によっては、（例えばＤＳＰのようなアルゴリズム的なアクセラレータ）同じコントローラクライアント１２０のフレームワーク内に存在するデータの消費者と生産者とを結合することが自然であり得る。

処理リソース１５０とその他のシステムリソースとのあるレベルのデカップリングを提供するために、次のいくつかの付加機能が、コントローラクライアント１２０によって提供されてもよい。
ａ）処理リソース１５０によって生成されるアドレスは、比較器３３０および比較アドレスレジスタ３４０を用いて、ベースアドレスおよびオフセットの定義によって定義された期待されるビヘイビアと突き合わせて検査されてもよい。
ｂ）処理リソース１５０によって生成されるアドレスは、オフセットであってもよく、減算器３５０およびオフセットアドレスレジスタ３６０を使用し、処理リソース１５０が与えられたスレッドに対するアドレスマップの正規化された視野、典型的には、正規化されたおおよそのアドレス０ｘ０を有するのを可能にする。
ｃ）デバッグウォッチレジスタは、処理リソースが限られた機能を有する場所に含められてもよく、そのために、それ自体の命令レベルデバッグハードウェアを含まない。そして、このようなレジスタは、命令レベルのデバッグ能力を、さもなければそれが不足している固定機能ハードウェアリソース１５０に与えるために、アドレス使用率を監視するのに使用されてもよい。

（オブジェクト）
コントローラ１３０内で使用されるインスタンスのデータタイプは、パブリックビジビリティー（システムから自由に見ることができ、かつ、システムによって自由に操作される）およびプライベートビジビリティー（コントローラ１３０内においてだけ見ることができ、かつ、コントローラ１３０のサブブロックだけによって操作される）に分類される。複数のエンドアプリケーション間において設計の移植性を保証するために、すべてのスレッド、キュー、および集められたキュー記述子は、共通ベースクラスを用いて、専用密結合メモリー１９０内のコントローラメモリーエレメント１９５に記憶される。

（コントローラメモリーエレメント）
それぞれのコントローラメモリーエレメント１９５は、次の１０個の記述子タイプのいずれかを表現してもよい。
１．フリーリストエレメント。このエレメントは、その他のいずれかの記述子タイプによって自由に使用されてもよい。ユーザ初期化またはランタイム操作は、必要とされない。
２．スレッド記述子（ＴＤ）。これは、アプリケーション／管理スレッドを表現するデータ構造である。この記述子は、専用密結合メモリー１９０内のペンディングキュー、レディーキュー、または、ディスパッチキューのいずれかに存在してもよい。ユーザ初期化は、必要とされないが、ランタイム操作は、必要とされる。
３．スケジューラールート記述子（ＳＲＤ）。これは、スケジューラー階層の最上位記述子である。ユーザ初期化は、必要とされるが、ランタイム操作は、必要とされない。ルート記述子は、親を持たないが、子は、ＳＳＴＤ、ＤＳＴＤ、または、ＴＤのいずれかであってもよい。
４．静的スケジューラー層記述子（ＳＳＴＤ）。これは、静的スケジューラー層記述子であり、その親は、ＳＲＤまたは別のＳＳＴＤのいずれかであってもよい。ＳＳＴＤの子は、別のＳＳＴＤ、ＤＳＴＤ、または、ＴＤのいずれかであってもよい。
５．動的スケジューラー層記述子（ＤＳＴＤ）。これは、動的スケジューラー層記述子である。ユーザ初期化は、必要とされないが、ランタイム操作は、必要とされる。ＤＳＴＤの親は、ＳＲＤまたはＳＳＴＤのいずれかであってもよいが、ＤＳＴＤは、ＴＤの子しか持たない可能性もある。
６．ディスパッチキュー記述子。このタイプの記述子は、対応する処理リソース１５０からのポップオペレーションを待っているスレッド記述子のリストを記述する。ユーザ初期化は、必要とされるが、ランタイム操作は、必要とされない。
７．ペンディングキュー記述子。このタイプの記述子は、同期イベントを待っているスレッド記述子のリストを記述する。ユーザ初期化は、必要とされるが、ランタイム操作は、必要とされない。
８．プール取り付けノード（ＰＡＮ）。ＰＡＮは、スケジューラールート層を処理リソース１５０のプールルート層に取り付けるのに使用される。ユーザ初期化は、必要とされるが、ランタイム操作は、必要とされない。
９．プール静的ノード（ＰＳＮ）。ＰＳＮも、また、スケジューラールート層を処理リソース１５０のプールルート層に取り付けるのに使用される。ユーザ初期化は、必要とされるが、ランタイム操作は、必要とされない。
１０．プールルートノード（ＰＲＮ）。処理リソース１５０のプールごとにただ１つのＰＲＮが存在する。ユーザ初期化は、必要とされるが、ランタイム操作は、必要とされない。

図９は、スレッド記述子、コントローラ１３０、処理リソース１５０、および共有システムメモリー１４０の間の典型的な関係を示す。それぞれのスレッドプリミティブは、固有の参照ｐＲｅｆｅｒｅｎｃｅを含む。この参照は、コントローラ１３０によって解釈または変更されない。ｐＲｅｆｅｒｅｎｃｅは、実行されるべきタスクを定義するシステムメモリー１４０内のデータ構造へのポインタを提供する。典型的には、これは、コントローラクライアント制御ブロック１２５であり、少なくとも次のエレメントを含む。すなわち、関数ポインタ（処理リソース命令ブロック１４５として図９に示される）、スタックポインタ、および引数ポインタ（データブロック１３５として図９にまとめて示される）。さらなるフィールドが、定義されてもよく、それらは、帯域内設定または共有システムリソース全体のセキュリティーを提供する。

しかしながら、アプリケーションおよび／またはターゲット処理リソース１５０に応じて、コントローラクライアント制御ブロック１２５の複雑さは、変化してもよい。とりわけ、さらなるレベルの間接参照が、含められてもよく、それは、適切な「制御」命令コードおよびそれに対応する「データパス」コードが与えられるならば、異種の処理リソース１５０がある環境下において同じデータに同じ機能を実行するのを可能にし得ることに注意されたい。この場合、処理リソース１５０のタイプごとのポインタが存在し、異なる処理リソース１５０によって必要とされる特定の命令ストリームに対応する。異なる処理リソースに同じスレッドを実行させる能力は、また、マルチコアアーキテクチャー内において利用可能なすべての処理リソース間に負荷を分散するのを可能にする。さらに、処理リソースは、一緒にプールされてもよい。

プロセッサーリソースのプールは、特定の処理リソース１５０のインスタンスをただ１つの分散ノード内に集めるのを可能にする。そして、分散ノードは、特定の処理リソースプールに属する個々の処理リソース１５０間において、負荷分散、インテリジェントプリエンプション、および電力管理を提供してもよい。

図１０および図１０ｂは、本発明の実施形態による特徴を取り入れたデバッグシステムフレームワークの基本的な概略ブロック図を示す。図１０において、本発明は、システム全体にわたるデバッグ制御のための集合ポイントを提供し、そして、図１０ｂにおいては、本発明は、すべてのその他のデバッグおよびトレースユニットと同じようにして、外部集中デバッグ制御集合コンポーネントに接続される。

典型的には、それぞれの処理リソース１５０は、命令レベルのデバッグおよびトレースユニット１５１を提供し、命令レベルで、あるいは、それと同等なレベルで、かつ、対応する処理リソース１５０だけに限定して、使用される。これらは、処理リソース１５０に固有のものであるが、同じかまたは類似するデータを用いて動作する。

大まかに言えば、デバッグのためのこのアプローチは、次の２つの領域に分割されてもよい。デバッグ情報の抽出中にシステムが停止させられる静的動作、および情報が、ランタイムにおいて、収集され、監視され、および分配される動的動作である。

静的動作は、数ある中でも、とりわけ、ブレークポイントおよびウォッチポイントのセットアップ設定、停止およびシングルステップの管理、システム状態およびメモリー負荷のスナップショット、観察、および解析を含む。

動的動作は、数ある中でも、とりわけ、プロセッサーサイクル、キャッシュ動作、プロセッサー間通信、およびシステムインターコネクト（例えば、バス）トランザクションの監視を含む。この種の監視は、まとめて、トレースと呼ばれ、それは、システムビヘイビアの「プロファイリング」に使用される。動的なデバッグまたはトレース情報は、典型的には、組み込まれたシステムのコンポーネントによって自律的に生成される。

局所的な命令レベルデバッグおよびトレースユニット１５１は、組み込まれた「トリガー」ロジックを含み、それは、予め定義された所定の環境下において、対応する処理リソース１５０内における命令の処理を停止させるが、トレース情報の蓄積または何らかのその他の機能を開始または終了するのに使用されてもよい。トリガーは、典型的には、予め定義された「トリガーシーケンス」が観察されたことを指示するイベントビットである。

最低限、このようなトリガーロジックは、典型的には、ブレークポイントロジックを含み、そのブレークポイントロジックは、与えられた命令に遭遇すれば、割り込み（トリガー）を局所的な処理リソース１５０に発行する。これらのユニット内に含まれる機能の量は、処理リソース１５０に固有のものであるが、必要であれば、上述したように、コントローラクライアント１２０は、最低限のレベルの命令レベルデバッグおよびトレース能力を提供するためのデバッグウォッチレジスタを含んでもよい。これは、処理リソース１５０が、限られた機能、例えば、専用オーディオＣＯＤＥＣしか有していない場合に必要とされる。

命令レベルデバッグおよびトレースユニット１５１のそれぞれは、デバッグアクセスポート１４１に接続された双方向インタフェース１５５および１つ以上の任意的な局所的トレースバッファー１５２を介してトレースポート１４４に接続されたトレース出力インタフェース１０５と、トレース集合ポイント１４２と、任意的な統合トレースバッファー１４３とを有する。

デバッグアクセスポート１４１は、外部「デバッグホスト」がデバッグプロセスを制御し、かつそれにアクセスするのを可能にする。典型的には、これらのホストは、シリアルポートまたはその他の類似する低速接続インタフェースプロトコルを介して、インタフェース接続する。

トレースポート１４４は、トレースデータへのアクセスを外部装置に提供する。これは、ソフトウェアデバッグプロセスの一部としてトレースデータの観察が発生するのを可能にする。

任意的な局所的トレースバッファー１５２および統合トレースバッファー１４３は、出力する前に、トレースデータを一時的に記憶するのに使用される。これは、システムの実行されている「スナップショット」を記憶し、そして、後のある時点において、トレースポート１４４から読み出すのを可能にする。そうすることによって、デバッグデータがたとえリアルタイムで出力されるにしても、トレースポート１４４は、必要とされ得る高速転送ができなくてもよい。これは、デバッグデータを出力するのに（少なくとも部分的に）専用使用される多数の出力ピンの必要性を除去する。これは、重要なことである、なぜなら、現在、ＩＣダイのサイズを制限するのは、機能ロジック自体のサイズとは対照的に、何らかの特定の集積回路（ＩＣ）ダイ上に取り付けられ得る入力／出力パッドの数であるからである。

トレース集合ポイント１４２は、ただ単に、局所的デバッグおよびトレースユニット１５１から出力される複数のデバッグトレースストリーム１０５をただ１つの出力ストリームに多重化する役割をなし、統合トレースバッファー１４３に記憶する準備ができた状態にあるか、または、統合トレースバッファー１４３が存在しない場合には、ただ単に、トレースポート１４４を介して出力する準備ができた状態にある。

図１０において、局所的デバッグおよびトレースユニット１５１のそれぞれに接続されるのは、本発明のスレッドデバッグコントローラ４００である。また、このスレッドデバッグコントローラ４００は、同様に、１つ以上の任意的な局所的統合トレースバッファーを介して、コントローラ１３０、デバッグアクセスポート１４１、およびトレース出力ポート１４４に接続される。図１０のデバッグフレームワークにおいては、コントローラ１３０は、初期デバッグイネーブル信号４５０を個々のＤＴＵ１５１に提供し、それは、コントローラ内において観察されたイベントから最初に得られたデバッグストラテジーを示唆する。

図１０ｂにおいて、命令レベルデバッグおよびトレースユニット１５１のそれぞれは、デバッグ制御集合ユニットからデバッグイネーブル信号を受信し、そのデバッグ制御集合ユニットは、本発明によって生成されたイベントを含み得る予め定義されたシーケンスのイベントを観察した結果として、このようなイネーブル信号を生成する。図１０ｂのフレームワークは、局所的デバッグおよびトレースユニット１５１または本発明のいずれかから開始されてもよいデバッグストラテジーを可能にする。

図１１は、本発明の実施形態のスレッドデバッグコントローラ４００の具体的な入力および出力を示す。

コントローラ１３０のサブブロック２００〜２８０のそれぞれは、信号をスレッドデバッグコントローラ４００内へ搬送するデバッグインタフェース４１０を有する。これらの入力信号は、サブブロックが、個々のスレッドを管理し、かつそれらを個々の処理リソース１５０間に割り付けるために相互作用するとき、コントローラ１３０の対応するサブブロックのそれぞれにおいて発生するイベントをスレッドデバッグコントローラ４００に通知する。スレッドデバッグコントローラ４００は、また、情報をトレースおよびトリガーするために、サブブロックイベントをフィルタリングしてもよい。

コントローラ１３０のそれぞれのサブブロック内におけるコマンドの実行は、ＥｖｅｎｔＩＤフィールドおよびＥｖｅｎｔＤａｔａフィールドをスレッドデバッグコントローラ４００へ送信することをもたらす。それぞれのサブブロックはそれ自体のスレッドデバッグコントローラ４００への専用インタフェース４４０を有するので、それぞれのイベントが関係するサブブロックは、それらのフィールドがどのインタフェースを介して送信されたかによって決定される。ＥｖｅｎｔＩＤフィールドは、ユーザが定義することができるものであり、そのために、Ｎビット長であってもよいが、本発明の好ましい実施形態においては、ＥｖｅｎｔＩＤは、４ビット長である。それぞれの個々のＥｖｅｎｔＩＤフィールドは、特定のサブブロック２００〜２８０において発生する個々のイベントを識別する。

サブブロック内において発生し得るイベントの例には、キューへのまたはキューからのスレッドのプッシュ／ポップ、コントローラメモリーエレメント１９５への読み出し／書き込みアクセス、同期イベントの生成、および処理リソース１５０とコントローラ１３０との間におけるある形態の低レベル通信を提供するイベントが含まれる。

それぞれのＥｖｅｎｔＩＤを伴うＥｖｅｎｔＤａｔａフィールドは、現時点の好ましい実施形態においては、３２ビット長である。このフィールドは、現時点において実行されているイベントによって使用される主たるデータを含む。通常、これは、コントローラメモリーエレメント１９５の３２ビット長のｐＲｅｆｅｒｅｎｃｅ領域を含むが、さらに、その他のいくつかのデータタイプの中のいずれか１つを含んでもよく、あるいは、それぞれのデータタイプが３２ビット長以下であれば、それらのデータタイプを組み合わせたものを含んでもよい。これらのその他のデータタイプの例には、コントローラメモリーエレメント１９５のインデックス、割り込みマスク、タイマー値、およびサブモジュールＩＤが含まれる。

スレッドデバッグコントローラ４００は、また、時刻インタフェース４２０を有する。このインタフェースは、３２ビット長の時刻指示を提供し、その時刻指示は、スレッドデバッグコントローラ４００がコントローラ１３０の個々のサブブロックのそれぞれからサブブロック入力インタフェース４１０を介してイベントを受信したとき、ログされたすべてのイベントにタイムスタンプを押すために、スレッドデバッグコントローラ４００によって使用される。

補助デバッグインタフェース４３０は、標準的な外部ソフトウェアデバッグシステムビジュアライゼーション制御ツールがスレッドデバッグコントローラ４００にアクセスするのを可能にするための双方向インタフェースである。これらの外部ソフトウェアデバッグツールは、システムの初期化においてデバッグパラメータをセットアップすることおよび結果として得られるトレースデータを捕捉および表示することの両方に使用される。サポートされるインタフェースの例には、ＩＥＥＥ１１４９．１ ＪＴＡＧインタフェースおよびより高性能のＩＥＥＥ Ｎｅｘｕｓ ５００１ ＡＵＸポートインタフェースが含まれる。

チップのバウンダリスキャンを本来は目的としたＪＴＡＧは、シリアルリンクおよび低速クロックストラテジーを備える４線式インタフェースに基づいた技術であり、それは、現在、デバッグデータアクセスを可能にするためのマルチコアアーキテクチャー内において広く使用されている。その帯域幅限界のために、また、インタフェースが低速シリアルリンクを介してデバッグホストによって習得されるという事実のために、ＪＴＡＧの使用は、典型的には、静的動作に限定される。しかしながら、それは、比較的に安価であるので（シリコン面積およびチップＩ／Ｏのために）、また、実施するのが容易であるために、ＪＴＡＧは、オンチップデバッグのための標準的な物理層となりつつある。

Ｎｅｘｕｓ ５００１ ＡＵＸポートインタフェースは、より豊富な一連のデバッグ能力を提供し、例えば、スレッドデバッグコントローラ４００の内部に存在するデバッグレジスタへの動的アクセスのような、多数の動的アクティビティーを含む。

トレースバッファーインタフェース４４０は、現時点において利用可能なバッファー技術とともに使用されるように設計される。特定の実施形態においては、トレースデータは、単純なバイト幅ファーストインファーストアウトインタフェースを介して出力される。図１２ａは、バイト幅インタフェースおよびその対応する制御信号を示し、図１２ｂは、これらのデータおよび制御入力／出力を構成する電気的信号のタイミングを示す。シングルバイト幅インタフェースが、示されるが、当業者には、本発明はこのような範囲に限定されないことが理解できる。

再び、図１１を参照すると、図１０によって説明されたフレームワークにおいては、外部デバッグイネーブル信号グループ４５０は、すべて、局所的デバッグおよびトレースユニット１５１のイネーブル信号である。マルチコアアーキテクチャー１０内に存在する局所的デバッグおよびトレースユニット１５１ごとに１つが提供され、したがって、正確な数は、設計段階中に設定される。これらの信号のそれぞれは、トリガーイベントを検出すると、１つの特定の局所的デバッグおよびトレースユニット１５１をイネーブル状態にすることができる。このような局所的デバッグおよびトレースユニット１５１のイネーブル信号を使用することによって、また、コントローラ１３０の動作を固有のスレッドレベルで抽象化することによって、スレッドデバッグコントローラ４００は、スレッド（すなわち、マクロアーキテクチャー的な）レベルのデバッグ能力を提供し、その能力は、局所的デバッグおよびトレースユニット１５１の局所的命令（すなわち、マクロアーキテクチャー的な）レベルによってゲートされてもよい。これは、きめの粗いスレッドに基づいたデバッグおよびよりきめの細かい命令に基づいたデバッグの両方をソフトウェアエンジニアに提供し、それによって、さもなければプローブ効果を発生させるさらなるデバッグソフトウェアを導入することなく、デバッグプロセスを助ける。

再び、図１１を参照すると、図１０ｂによって説明されたフレームワークにおいては、外部デバッグイネーブル信号グループ４５０は、すべての局所的デバッグおよびトレースユニット１５１のイネーブル信号をデバッグ制御集合ブロックとして集めたイネーブル信号である。このような信号の正確な数は、システム設計者がデバッグ制御集合ブロックへ搬送したい離散的イベントの数によって決定される。そして、トリガーイベントを検出したときにすべてのデバッグイネーブル信号発生源をフィルタリングして適切な局所的デバッグおよびトレースユニット１５１をアサートするのは、デバッグ制御集合ブロックの責任である。上述したように、このような局所的デバッグおよびトレースユニット１５１のイネーブル信号を使用することによって、また、コントローラ１３０の動作を固有のスレッドレベルで抽象化することによって、スレッドデバッグコントローラ４００は、スレッド（すなわち、マクロアーキテクチャー的な）レベルのデバッグ能力を提供し、その能力は、局所的デバッグおよびトレースユニット１５１の局所的命令（すなわち、マクロアーキテクチャー的な）レベルによってゲートされてもよい。しかしながら、この場合、トリガーシーケンスは、コントローラによって開始されなくてもよい。

スレッドデバッグコントローラ４００は、また、いくつかのきめの細かいデバッグ能力を、タスク割り付けコントローラ１３０を構成するサブブロックに提供することに注意されたい。これらの能力については、以下で図１３を参照してより詳細に説明される。

内部デバッグイネーブル信号グループ４６０は、スレッドデバッグコントローラ４００によって、タスク割り付けコントローラ１３０を構成する個々のサブブロック（２００〜２８０）のそれぞれに送信される信号からなる。これらの信号は、スレッドデバッグコントローラ４００が、スレッドデバッグコントローラ４００の設定に基づいて、それぞれのサブブロックにその次の命令をシングルステップで実行させるのに使用され、あるいは、サブブロック全体を停止させるのに使用される。

スレッドデバッグコントローラ割り込み信号グループ４７０は、２つの信号からなる。それらの信号は、スレッドデバッグコントローラ４００からコントローラ１３０へ戻る割り込みのフィードバックを可能にする。これらの割り込みは、コントローラ１３０へのその他のすべての外部割り込みと同じようにハンドルされる。これらの信号の使用は、完全にプログラマブルなものであるが、それらの使用の典型的な例には、アプリケーションにおいて注意を必要とするイベントに関する統計の収集および特定の処理リソース１５０におけるデバッグ監視スレッドの起動が含まれる。

ＴＳＩＦシステムインタフェース４１２は、コントローラ１３０のインタフェースマネージャーサブモジュール２８０とスレッドデバッグコントローラ４００との間の通信を可能にする。このインタフェースは、ＳｕｂＢｌｏｃｋＣｍｄスレーブ入力インタフェース４９０およびＧｅｎｅｒｉｃＲｅｇマスター出力インタフェース４８０の両方を備える。マルチコアプロセッサー内に存在するすべての処理リソース１５０およびＴＳＩＦサブブロックは、通常動作およびデバッグ動作のために、例えば、アプリケーションランタイム中にデバッグパラメータをプログラムするために、ＳｕｂＢｌｏｃｋＣｍｄスレーブ入力インタフェース４９０を介してスレッドデバッグコントローラ４００にアクセスしてもよい。同様に、スレッドデバッグコントローラ４００は、ＧｅｎｅｒｉｃＲｅｇマスター出力インタフェース４８０を介してコントローラ１３０のすべての内部サブブロックへフルアクセスすることを許可されてもよい。

図１３は、コントローラ１３０のサブブロックのそれぞれとスレッドデバッグコントローラ４００との間の接続をより詳細に示すブロック図である。スレッドデバッグコントローラ４００は、汎用レジスタすなわちＧｅｎｅｒｉｃＲｅｇインタフェース４８０を用いて、コントローラ１３０のそれぞれのサブブロック内に存在するリソースにインタフェースマネージャー（２８０）を介してアクセスする。このインタフェースは、また、それぞれのサブブロック上で独立してデバッグし、かつシングルステップを実行するのをスレッドデバッグコントローラ４００に可能にさせる。

スレッドデバッグコントローラ４００は、また、システム全体にわたるいくつかの閉ループデバッグ能力を提供する。第１に、割り込みマネージャー（ＴＳＩＣ）２５０は、スレッドデバッグコントローラ４００の付加的なフィードバック割り込み４７０を有する。これらの割り込みは、ウォッチされている特定の一組のユーザ定義可能イベントが発生したことを指示するために、スレッドデバッグコントローラ４００によって使用される。そして、この割り込みは、割り込みマネージャー（ＴＳＩＣ）２５０にＳｙｎｃＥｖｅｎｔを生成させ、そのＳｙｎｃＥｖｅｎｔを待っているシステム管理スレッドを解放するのに使用されてもよい。このように、デバッグシステムは、特定のシステムイベントを検出すると、システム管理スレッドをトリガーすることができる。

第２に、専用ＴＳＩＦシステムインタフェース２８０のコマンドは、３２ビットのデータを保持することのできるＴＳＩＦ ＤｅｂｕｇＥｖｅｎｔを生成することができる。そして、これらは、例えば、処理状態の変化を指示するために、あるいは、ホストデバッガーと処理リソース１５０のそれぞれとの間の低ビットレート通信チャンネルとして、イベントを生成するのに利用されてもよい。

図１４は、スレッドデバッグコントローラ４００の内部の機能的実施を示す。

動的デバッグインタフェース５４０は、スレッドデバッグコントローラ４００の動的動作の細部、例えば、どのようなシステム管理および割り付けイベントがスレッドデバッグコントローラ４００によって探し出されるべきか、および特定のイベントが観察されたとき、どのようなアクションがスレッドデバッグコントローラ４００によって実行されるべきかを制御するのに使用される。

静的デバッグインタフェース５３０は、スレッドデバッグコントローラ４００の静的動作の細部、例えば、静的イベントフィルターを制御するのに使用される。

ＳｕｂＢｌｏｃｋＣｍｄインタフェース４９０は、コントローラ１３０のインタフェースマネージャー２８０が動的デバッグインタフェース５４０にアクセスするのを可能にする。特別に設計されたマルチプレクサ５６０だけが、ＳｕｂＢｌｏｃｋＣｍｄインタフェース４９０から動的デバッグインタフェース５４０にアクセスするのを可能にする。Ｎｅｘｕｓプロトコル変換器４３５は、ＩＥＥＥ Ｎｅｘｕｓ ５００１プロトコル標準を使用する外部デバッグホストからの信号を、スレッドデバッグコントローラ４００のデバッグ動作を制御するのに適した内部信号に変換する。その際、変換器４３５は、また、Ｎｅｘｕｓ推奨レジスタのサブセットを提供する。外部デバッグホストは、動的デバッグインタフェース５４０および静的デバッグインタフェース５３０の両方にマルチプレクサ５６０を介してアクセスすることを許される。外部デバッグホストは、また、コントローラ３００のすべての内部サブブロック２００〜２８０にインタフェースマネージャー２８０の汎用インタフェースを介してアクセスすることを許される。

図１５は、いくつかのデバッグマシン５００の中の１つの論理図を示す。デバッグマシン５００の数は、任意のものであり、設計時に設定される。

デバッグマシン５００は、複数のブレークポイントまたはウォッチポイントをセットアップする柔軟性のある設定可能な方法、および処理リソース１５０のいずれか１つ、プール、または、任意のグループのための複雑なトリガーシナリオを提供する。デバッグマシン５００（１つ以上）は、また、トリガーシナリオの発生を観察した結果として、内部トレース記録モジュールおよび静的イベントフィルター６００をイネーブル状態／ディスエーブル状態にすることができる。

それぞれのデバッグマシン５００は、そのデバッグマシン５００によってウォッチされるべきイベントを記憶するためのＥｖｅｎｔＷａｔｃｈＩｎｓｔファーストインファーストアウト（ＦＩＦＯ）レジスタ５１０、およびＥｖｅｎｔＷａｔｃｈＩｎｓｔＦＩＦＯ５１０から特定のイベントを検出したときに実行されるべきアクションを記憶するためのＡｃｔｉｏｎＬｉｓｔＩｎｓｔＦＩＦＯレジスタ５１５を備える。これらのレジスタは、動的デバッグインタフェース５４０を介して、それらのそれぞれの命令によってプログラムされる。それぞれのデバッグマシン５００は、また、イベントサービスモジュール５２０を備え、そのイベントサービスモジュール５２０は、ＥｖｅｎｔＷａｔｃｈＩｎｓｔレジスタおよびＡｃｔｉｏｎＬｉｓｔＩｎｓｔレジスタの両方からの出力を取り込み、それらの出力を、コントローラ１３０の個々のサブブロックから入力されたシステム管理および割り付けイベントと比較する。そして、イベントサービスモジュールは、次の信号、すなわち、対応する処理リソース１５０の局所的デバッグおよびトレースユニット１５１をイネーブル状態にするときに使用するためのＤｅｂｕｇＥｎａｂｌｅ信号４５０、トレース情報をトレースバッファー４４０へ出力する静的イベントフィルター６００をイネーブル状態（または、ディスエーブル状態）にするためのＴｒａｃｅＥｎａｂｌｅ／Ｄｉｓａｂｌｅ５５０、および現在のデバッグマシン５００と互いに連結されたその他のデバッグマシンを制御するためのＳｙｎｃＥｎａｂｌｅ信号５５０の１つ以上を出力する。デバッグマシン５００は、また、デバッグプログラミングのために、動的デバッグインタフェース５４０からの入力を有する。

図１６は、本明細書で説明される本発明の特定の実施形態におけるデバッグマシン５００の物理的な実施を示す。この実施形態においては、ＥｖｅｎｔＷａｔｃｈＩｎｓｔＦＩＦＯ５１０ａおよびＡｃｔｉｏｎＬｉｓｔＩｎｓｔＦＩＦＯ５１５ａは、実際に、すべてのデバッグマシン５００の間で共有される２つの命令レジスタファイルとして実施される。これらの統合レジスタファイル５１０ａおよび５１５ａは、読み出し制御ロジックシステム５０６および書き込み制御ロジックシステム５０５を介して、論理的に独立したＦＩＦＯとしてアクセスされる。この実施は、ユーザがデバッグマシン５００ごとのＦＩＦＯ深度を特定の実施に適合するように個々に設定するのを可能にする。

図１７は、デバッグマシン５００の連結能力を示す。これは、複数の複雑なトリガーの論理的な組み合わせをプログラムする能力を提供する。デバッグマシン５００のＳｙｎｃＥｎａｂｌｅ信号５５５は、これらの複雑なトリガー組み合わせを生成するのに使用される。図示されるトリガーシナリオにおいては、個々のトリガーイベントのシングルシーケンスの後には、３つのトリガーシーケンスの組み合わせが存在しなければならず、そして、その３つのトリガーシーケンスの組み合わせの後には、アクションが実行される前に、別のシングルトリガーシーケンスが、存在しなければならない。複数のデバッグマシン５００が提供されるために、組み合わせられたトリガー関係は、同時に評価されてもよい。

ＥｖｅｎｔＷａｔｃｈ命令は、コントローラ１３０内に存在する特定のサブブロック２００〜２８０からのシングルイベントを捕捉するのに使用される。それぞれのデバッグマシン５００を制御する有限状態機械（ＦＳＭ）は、ＥｖｅｎｔＷａｔｃｈ命令内に規定されるサブブロックイベントを探し出し、対応するＡｃｔｉｏｎＬｉｓｔ命令内において定義されたアクション（例えば、ブレークポイントイネーブルなど）を実行する。それぞれのＥｖｅｎｔＷａｔｃｈ命令は、４４ビット幅である。２つの主たる種類のＥｖｅｎｔＷａｔｃｈ命令、すなわち、シングルワードＥｖｅｎｔＷａｔｃｈ命令およびダブルワードＥｖｅｎｔＷａｔｃｈ命令が存在する。ダブルワードＥｖｅｎｔＷａｔｃｈ命令は、８８ビット長であり、ＥｖｅｎｔＷａｔｃｈＩｎｓｔＦＩＦＯ５１０内の２つのエントリーを占有する。２つの種類が、次に示される。

両方の種類のＥｖｅｎｔＷａｔｃｈ命令の個々のフィールドは、
１．ＥＷＯｐｃｏｄｅ（）：これは、オペレーションフォーマットを定義する３ビットコードである。これは、次の中のいずれかであってもよい。

２．ＳｕｂＭｏｄｕｌｅＩＤ（）：この５ビットコードは、イベントが関係するサブブロックを定義する。

３．ＥｖｅｎｔＩＤ（）：この４ビットコードは、コントローラ１３０を構成するサブブロック２００〜２８０のそれぞれからインタフェース４１０間において提供されるそれぞれのイベント内において提供されるＥｖｅｎｔＩＤによって説明されるように、個々のサブブロックイベントを定義する。
４．ＥｖｅｎｔＤａｔａ（）：この３２ビットコードは、個々のサブブロック２００〜２８０のウォッチされるイベント、例えば、コントローラ専用コントローラメモリー１９０内のｐＲｅｆｅｒｅｎｃｅフィールドを定義する。

図１８は、シングルワードイベントウォッチのためのデバッグマシン５００内のデータフローを示す。

シングルワードイベントウォッチの場合、次のＥｖｅｎｔＷａｔｃｈ命令は、最初に、ＥｖｅｎｔＷａｔｃｈＩｎｓｔＦＩＦＯ５１０から、イベントサービスモジュール５２０内の２つのＥｖｅｎｔＷａｔｃｈ命令バッファーの中の第１のバッファーにロードされる。次に、ＳｕｂＭｏｄｕｌｅＩＤ、ＥｖｅｎｔＩＤ、およびＥｖｅｎｔＤａｔａ部分が、比較器５２２を用いて、入力するコントローラ１３０のイベントと比較される。これらは、ＥｖｅｎｔＩＤおよびＥｖｅｎｔＤａｔａだけを含むが、ＳｕｂＭｏｄｕｌｅＩＤは、既知である。なぜなら、それぞれのサブブロックは、それ自体の特定のインタフェース４１０を有するからである。そして、比較の結果は、必要であれば、ＯＲロジックブロック５２３を用いて、その他のデバッグマシン５００によって実行されるその他の比較の結果とＯＲ演算される。ＯＲ関数ブロックの出力は、ＥｖｅｎｔＷａｔｃｈ命令内に含まれるＥＷＯｐｃｏｄｅを復号化するＥｖｅｎｔＷａｔｃｈ命令復号器５２４の出力を制御するのに使用される。ＥｖｅｎｔＷａｔｃｈ命令復号器５２４自体の出力は、ＡｃｔｉｏｎＬｉｓｔ命令復号器５２１の出力を制御し、そのＡｃｔｉｏｎＬｉｓｔ命令復号器５２１は、ＥｖｅｎｔＷａｔｃｈ命令に対応するＡｃｔｉｏｎＬｉｓｔ命令を復号化し、そのＥｖｅｎｔＷａｔｃｈ命令は、ＡｃｔｉｏｎＬｉｓｔ命令ＦＩＦＯ５１５からＡｃｔｉｏｎＬｉｓｔバッファー５１６を介して以前にロードされたものである。ＡｃｔｉｏｎＬｉｓｔ命令復号器５２１の出力は、そのデバッグマシン５００に対応する処理リソース１５０の局所的デバッグおよびトレースユニット１５１を制御するためのＤｅｂｕｇＥｎａｂｌｅ信号、このポイント以降からトレースデータを出力するのを可能にするためのＴｒａｃｅＥｎａｂｌｅ信号、およびデバッグマシン５００間の同期を可能にするＳｙｎｃＥｎａｂｌｅ信号のいずれかであってもよい。

シングルワードＥｖｅｎｔＷａｔｃｈ命令内に存在するフィールドに加えて、ダブルワードＥｖｅｎｔＷａｔｃｈ命令は、一組のマスクを含み、それらのマスクは、ＥｖｅｎｔＷａｔｃｈ命令フィールドと対照して評価される前に、ＭａｓｋＯｐフィールド内に規定される命令に基づいて、ＳｕｂｍｏｄｕｌｅＩＤ、ＥｖｅｎｔＩＤ、およびＥｖｅｎｔＤａｔａの入力に適用される。ＭａｓｋＯｐフィールドは、次のいずれかの値を有してもよい。

図１９は、ダブルワードＥｖｅｎｔＷａｔｃｈ命令が実行される場合におけるデバッグマシン５００内のデータフローを示す。シングルワードＥｖｅｎｔＷａｔｃｈ命令の実行との原理の違いは、ダブルワードＥｖｅｎｔＷａｔｃｈ命令のワード１のＳｕｂＭｏｄｕｌｅＩＤフィールド、ＥｖｅｎｔＩＤフィールド、およびＥｖｅｎｔＤａｔａフィールドが、上の表に示されるＭａｓｋＯｐコードの種類に応じて、ダブルワードＥｖｅｎｔＷａｔｃｈ命令のワード０と、ＡＮＤ演算、ＯＲ演算、または、ＸＯＲ演算されることである。

シングルおよびダブルのＥｖｅｎｔＷａｔｃｈ命令の両方は、同じＡｃｔｉｏｎＬｉｓｔ命令を使用する。ＡｃｔｉｏｎＬｉｓｔ命令は、デバッグマシン５００（１つ以上）が、複雑なブレークポイントのトリガー、トレースのイネーブルまたはディスエーブル、および様々なデバッグマシン５００間の同期を達成するのを可能にし、次のフィールドを含む。

図２０は、静的イベントフィルター６００の機能ブロック図を示し、その静的イベントフィルター６００は、システム管理および割り付けイベントをトレースデータフォーマッター圧縮器モジュール７００に転送する前に、捕捉するために、それらのシステム管理および割り付けイベントのフィルタリングを実行する。このフィルターモジュール６００は、また、時刻インタフェース４２０からの３２ビットの入力を用いて、コントローラ１３０から受信されたすべてのイベントにタイムスタンプを押すことを実行する。

静的イベントモジュールは、静的インタフェース５３０を介して、一組のユーザプログラマブルイベントフィルターマスク６１１〜６１３を提供し、そのイベントフィルターマスク６１１〜６１３は、特定のサブブロック２００〜２８０からの特定のイベントが捕捉されるべきかどうかを選択するのに使用される。イベントフィルターマスクは、ＳｕｂＭｏｄｕｌｅＩＤフィールド、ＥｖｅｎｔＩＤフィールド、およびＥｖｅｎｔＤａｔａフィールドに適用される。データのシングルビットごとに、２つのビットが、イベントフィルターマスクごとに割り付けられる。これは、結果として、イベントフィルターマスクごとに割り当てられた７６ビットのフィルターマスクをもたらす。これらの２つのビットのそれぞれの有効な意味は、次の通りである。

ユーザが定義することのできる数のイベントフィルターマスク６１１〜６１３が、４つのイベントフィルターマスクテーブル６１０の中の１つに割り付けられてもよい。それぞれのイベントフィルターテーブル６１０が、ユーザが定義することのできる数のイベントフィルターマスク６１１〜６１３を含んでもよい。しかしながら、この特定の実施形態においては、これらのテーブルは、連続的なフィルターマスクを含まなければならない。これらのテーブルは、フィルターマスクサブセットを提供することによって、さらなるプログラマビリティーおよびハードウェアリソースの効率的な使用を可能にし、個々のデバッグマシン５００がそれらのフィルターマスクサブセットを使用できるようにしてもよい。

図２１は、特定のイベントフィルターマスク６１１〜６１３を特定のイベントフィルターマスクテーブル６１０に割り付けることを示す。この例においては、フィルターテーブル番号３は、使用されていないことに注意されたい。

図２２は、本明細書に説明される本発明の特定の実施形態のトレースデータフォーマッター圧縮器７００の機能ブロック図を示す。

トレースデータフォーマッター圧縮器モジュール７００は、限られた容量のオンチップトレースバッファーモジュールができるだけ効果的に使用されることを保証するために、トレースデータを圧縮する。圧縮モジュールは、トレース集合装置１４２または統合トレースバッファー１４３とともに提供されてもよいが、これらは、処理リソース１５０のそれぞれに対応する局所的デバッグおよびトレースユニット１５１のそれぞれからの命令レベルまたはそれと同等なレベルのデバッグおよびトレースデータを集合させかつ圧縮するように設計される。データの性質がよく知られておりかつ類似するタイプであれば、圧縮は、最適化される。したがって、この圧縮器７００は、スレッドデバッグコントローラ４００からもし存在すれば統合集合ポイント１４２へ出力される前に、静的イベントフィルター６００から得られた周知のタイプのデータおよび類似する形態のデータに作用する。

トレースデータフォーマッター圧縮器７００は、すべてのフィルタリングされかつタイムスタンプを押されたサブブロックイベントを次に利用可能な２エントリーＦＩＦＯ７２０内にルーティングするイベントスイッチ７１０を含み、それらのＦＩＦＯは、フィールドベース相関器７３０への入力を構成する。ＦＩＦＯは、シングルワードイベントまたはダブルワードイベントを記憶するのを可能にするために、２エントリーである。イベントスイッチ７１０は、コントローラ１３０の１０個のサブブロック２００〜２８０からの１０個のイベントを同時に受け入れることができる。イベントスイッチは、常に、現時点において利用可能な最も小さい番号のＦＩＦＯ７２０に書き込む。

すべてのＦＩＦＯ７２０が、少なくとも１つのエントリーを含んでしまえば、あるいは、内部タイマーが、満了して、現在のＦＩＦＯロードサイクルの終了を指示すれば、ＦＩＦＯは、フィールドベース相関器内へプッシュされる。内部タイマーは、少なくとも１つのエントリーが１０個のＦＩＦＯ７２０の中のいずれかに存在すれば、固定値としてロードされ、イベントが読み出されると、再びロードされる。

フィールドベース相関器７３０は、所定の長さのイベントフィールドに対して所定の関数演算を実行し、出力するときのフィールド内のゼロの数を最大化する。これは、第１のＦＩＦＯを基準にしたそれぞれのフィールド内における空間的相関および時間的相関を利用することによってなされる。したがって、第１のＦＩＦＯは、そのままにされる。そして、ＦＩＦＯ２〜１０および変更されないＦＩＦＯ１の結果として得られる所定の長さのフィールドは、イントラシンボルランレングス符号器７５０へ入力される前に、別のフィールド相関ＦＩＦＯ７４０へ出力される。このイントラシンボルランレングス符号器７５０は、それぞれの入力シンボルに対してゼロランレングス符号化を実行し、一組の可変長出力シンボルをもたらす。これらは、最終的な出力ビットストリームをもたらすインターシンボルランレングス符号器７７０内にロードされる前に、再度、一組の出力ＦＩＦＯ７６０に記憶される。最終的な出力ビットストリームは、可変長パケット化器７８０によって、トレースバッファーインタフェース４４０に適した可変長パケットとしてパケット化される。

トレースパケットデータのフォーマットは、物理層に依存する。物理層がパケット信号の明示的な開始点を持たない環境下においては、受信機ＦＳＭは、いくつかのパケットを飛び越えてパケット記述をロックオンするために、固定パターンヘッダーおよびパケット長フィールドを使用してもよい。例としてのパケットフォーマットが、以下に示される。

再び、図１４を参照すると、スレッドデバッグコントローラ５００の内部デバッグ制御モジュール５８０は、個々のサブブロックデバッグイネーブル信号およびシングルステップ機能をコントローラ１３０内のサブブロック２００〜２８０に提供する。デバッグマシン５００のいずれかから内部ＤｅｂｕｇＥｎａｂｌｅ信号を受信すると、内部デバッグ制御モジュール５８０は、指定されたサブブロックをデバッグモードにする。また、ユーザは、動的デバッグインタフェース５４０を介して、指定されたサブブロックにシングルステップで実行させることができる。

本発明の特定の実施形態が、説明されたが、これは単なる例として説明されたものであり、様々な変形が考えられてもよいことを理解すべきである。さらに、本発明は、限定はされないが、例えば、携帯電話またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）ゲートウェイのようなマルチコアプロセッサーを使用する装置または用途に一般的に適用される。したがって、特定の実施形態は、添付の特許請求の範囲によって決定されるべき保護範囲を限定するものと理解されるべきではない。

典型的なマルチコアプロセッサーアーキテクチャーシステムの論理的レイアウトを示す概略ブロック図である。 図１の論理的レイアウトの例示的な一実施を示す概略ブロック図であり、スレッド管理および割り付けコントローラが、専用メモリー装置およびコントローラクライアントとともに、汎用マルチコアプロセッサーアーキテクチャー内に組み込まれている。 図２のエレメントを含む最新のシステムオンチップ（ＳｏＣ）バスベースアーキテクチャーの一例をブロック図の形で示す図である。 図１、図２、および図３のコントローラの外部接続をより詳細に示す図である。 図２および図３のメモリー装置をより詳細に示す図である。 図２、図３、および図４のコントローラの内部構造をより詳細に示す図である。 図２および図３に示されるコントローラクライアントを示す概略ブロック図である。 複数の処理リソースの代理の役割をなすシングルコントローラクライアントの場合のシステムを示す概略ブロック図である。 ハードウェアコントローラクライアントをより詳細に示す概略ブロック図である。 スレッド記述子、コントローラ、処理リソース、および共有システムメモリー間の典型的な関係を示す図である。 本発明の実施形態によるデバッグアーキテクチャーを含む典型的なマルチコアプロセッサーアーキテクチャーシステムの論理的レイアウトの例示的な一実施を示す概略ブロック図である。図１０において、コントローラは、デバッグ制御のための中央アービタの役割をなす。 本発明の実施形態によるデバッグアーキテクチャーを含む典型的なマルチコアプロセッサーアーキテクチャーシステムの論理的レイアウトの別の例示的な実施を示す概略ブロック図である。図１０ｂにおいて、本発明の一部を構成しないさらなるコンポーネントは、コントローラを含むマルチコアプロセッサーアーキテクチャー内に存在するすべてのコア間のデバッグイベント集合を提供する。 図１０および図１０ｂに示されるスレッドデバッグコントローラの外部接続をより詳細に示す図である。 図１０および図１０ｂに示されるスレッドデバッグコントローラのトレースバッファーの外部接続をより詳細に示すブロック図である。 図１２ａに示されるトレースバッファーの典型的な出力のタイムチャートである。 図１０および図１０ｂに示されるスレッドデバッグコントローラの外部接続をより詳細に示す別の図であり、図２に示されるコントローラのサブブロックへの接続を含む。 図１１に示されるスレッドデバッグマネージャーの内部構造を示す機能ブロック図である。 図１４に示されるデバッグマシンの中の１つを示す論理的ブロック図である。 図１４に示されるデバッグマシンの中の１つを示す物理的ブロック図である。 図１４に示されるデバッグマシンの連結能力の例を示す図である。 シングルワードＥｖｅｎｔＷａｔｃｈの場合におけるデバッグマシン内の命令データフローを示す図である。 ダブルワードＥｖｅｎｔＷａｔｃｈの場合におけるデバッグマシン内の命令データフローを示す図である。 図１４の例示的な静的イベントフィルターモジュールを示す機能ブロック図である。 図２０に示される静的イベントフィルターモジュール内におけるイベントフィルターマスクの例示的な割り付けを示す図である。 図１４に示されるトレースデータフォーマッター／圧縮器モジュールの例を示すブロック図である。

Claims (32)

1. スレッドを処理するための複数のインターコネクトされたプロセッサーエレメントを備えるマルチコアプロセッサーアーキテクチャー内においてスレッドの実行を監視する方法であって、
   １つのスレッドまたは複数のスレッドの機能および／またはアイデンティティーおよび／または実行ロケーションに関する１つ以上のパラメータを指示する複数のスレッドパラメータインジケータを受信するステップと、
   スレッドパラメータインジケータの中の少なくとも１つを、関心のあるインジケータをそれぞれが表現する第１の複数の予め定義された基準と比較するステップと、
   前記比較の結果として関心のあるものであると識別されたスレッドパラメータインジケータによって得られる出力を生成するステップと、
   を備える方法。
2. 出力を生成するステップが、複数のインターコネクトされたプロセッサーエレメントの中の１つ以上を制御するための制御信号を生成する工程を含む、請求項１に記載の方法。
3. インターコネクトされたプロセッサーエレメントが、局所的な命令レベルのデバッグロジックをさらに備え、前記方法が、前記プロセッサーエレメント制御信号を用いて、前記命令レベルのデバッグロジックをイネーブル状態にするステップをさらに備える、請求項２に記載の方法。
4. マルチコアプロセッサーアーキテクチャーが、いくつかの個々のサブユニットを含むコントローラをさらに備え、出力を生成するステップが、コントローラの個々のサブユニットの中の１つ以上を制御するための制御信号を生成する工程を含む、請求項１に記載の方法。
5. スレッドパラメータインジケータが、コントローラによって生成される、請求項４に記載の方法。
6. スレッドパラメータインジケータが、コントローラ内に含まれる個々のサブユニットの中の１つ以上によって生成される、請求項５に記載の方法。
7. 前記サブユニット制御信号が、コントローラ内に含まれるサブユニットの中の１つ以上を停止させるための信号を含む、請求項４に記載の方法。
8. 前記サブユニット制御信号が、コントローラ内に含まれるサブユニットの中の１つ以上に、スレッドを管理し、かつプロセッサーエレメント間に割り付けるのに必要とされる次のオペレーションをステップで実行させるための信号を含む、請求項７に記載の方法。
9. 出力を生成するステップが、比較の後に発生する複数のスレッドパラメータインジケータのリストを含む出力を生成する工程を含む、請求項１に記載の方法。
10. 比較の後に発生する複数のスレッドパラメータインジケータのリストを含む出力を生成するステップが、前記比較の結果に基づいて開始する、請求項９に記載の方法。
11. マルチコアプロセッサーアーキテクチャーが、複数のユーザ定義可能スレッドパラメータインジケータフィルターをさらに備え、前記方法が、複数のスレッドパラメータインジケータをフィルタリングし、関心のあるインジケータを突き止めるステップをさらに備える、請求項９または１０に記載の方法。
12. マルチコアプロセッサーアーキテクチャーが、グローバル時刻信号をさらに備え、前記方法が、グローバル時刻信号を指示するコードと比較した後に発生する複数のイベントにタイムスタンプを押すステップをさらに備える、請求項１１に記載の方法。
13. マルチコアプロセッサーアーキテクチャーが、スレッドパラメータインジケータのリスティングをフォーマットし、かつ圧縮するためのフォーマッター圧縮器をさらに備え、前記方法が、スレッドパラメータインジケータフィルターから出力されるスレッドパラメータインジケータのリスティングをフォーマットおよび圧縮するステップをさらに備える、請求項１２に記載の方法。
14. コントローラから、または、プロセッサーエレメントの１つ以上から入力信号を受信するステップと、
    前記コントローラまたはプロセッサーエレメントから受信された入力信号に基づいて、複数の予め定義された基準を変更するステップと、
    をさらに備える、請求項１に記載の方法。
15. マルチコア処理アーキテクチャーが、第１のプロトコルに基づいた信号を第２の異なるプロトコルに基づいた信号に変換するためのプロトコル変換器をさらに備え、前記方法が、
    プロトコル変換器から入力信号を受信するステップと、
    プロトコル変換器から受信された入力信号に基づいて複数の予め定義された基準を変更するステップと、
    をさらに備える、請求項１または１４に記載の方法。
16. イベントの少なくともいくつかを、関心のあるインジケータをそれぞれが表現する第２の複数の予め定義された基準と比較するステップと、
    前記第１の比較および第２の比較の結果として関心のあるものであると識別されたスレッドパラメータインジケータによって得られる出力を生成するステップと、
    をさらに備える、請求項１〜１５のいずれか一項に記載の方法。
17. 第１または第２の複数の予め定義された基準が、特定のタイプのスレッドの特定のインスタンスを指示する基準を含む、請求項１または１６に記載の方法。
18. 第１または第２の複数の予め定義された基準が、コントローラの特定のサブユニットを指示する基準を含む、請求項１または１６に記載の方法。
19. 第２の複数の予め定義された基準が、第１の比較と第２の比較との間の関係を指示する基準を含む、請求項１７または１８に記載の方法。
20. 第１の比較と第２の比較との間の関係が、
    ＡＮＤ演算関係、
    ＯＲ演算関係、または、
    ＸＯＲ演算関係、
    のいずれかである、請求項１９に記載の方法。
21. 複数のインターコネクトされたプロセッサーエレメントを有するマルチコアプロセッサーアーキテクチャーにおけるソフトウェアデバッグのためのスレッドレベルデバッグコントローラであって、それぞれのエレメントが、スレッドを処理するためのリソースを提供し、デバッグコントローラが、前記プロセッサーエレメントのそれぞれと通信できる状態にあり、かつ、マルチコアプロセッサーアーキテクチャー内におけるスレッドの割り付けおよび実行を監視するための監視ロジックを備えるデバッグコントローラ。
22. マルチコアプロセッサーアーキテクチャーが、コントローラをさらに備え、前記コントローラが、いくつかのインターコネクトされた個々のサブユニットを備え、監視ロジックが、複数のデバッグマシンをさらに備え、前記デバッグマシンのそれぞれが、予め定義された基準に関して、前記サブユニットのそれぞれからの複数の入力信号を監視するようになっており、前記入力信号が、マルチコアプロセッサーアーキテクチャー内におけるスレッドの割り付けおよび実行を指示する、請求項２１に記載のデバッグコントローラ。
23. マルチコアプロセッサーアーキテクチャーが、プロセッサーエレメントのそれぞれに特有の命令レベルデバッグ監視ロジックエレメントをさらに備え、デバッグマシンのそれぞれが、さらに、特定の基準を検出したことに基づいて命令レベルデバッグ監視ロジックエレメントの中の１つ以上に出力制御信号を提供するようになっている、請求項２２に記載のデバッグコントローラ。
24. 関心のある信号を得るためにマルチコアプロセッサーアーキテクチャー内におけるスレッドの割り付けおよび実行を指示する複数の入力信号をフィルタリングするための複数のフィルターをさらに備え、デバッグマシンのそれぞれが、またさらに、前記複数のフィルターのどれが前記複数の入力信号をフィルタリングするのに使用されるかを制御するためのフィルター制御信号を提供するようになっている、請求項２３に記載のデバッグコントローラ。
25. マルチコアプロセッサーアーキテクチャー内における出力される準備のできたスレッドの割り付けおよび実行を指示するフィルタリングされた複数の入力信号をフォーマットおよび圧縮するためのフォーマッター圧縮器をさらに備える、請求項２４に記載のデバッグコントローラ。
26. 前記複数のデバッグマシンのそれぞれが、検出される準備のできた基準と、前記基準のそれぞれが検出されたときにマルチコアプロセッサーアーキテクチャーによって実行されるべきアクション命令のリストとを記憶するためのメモリーをさらに備える、請求項２２に記載のデバッグコントローラ。
27. 基準を記憶するための前記メモリーが、スレッドデバッグコントローラによって独占使用されるスレッドデバッグコントローラ専用メモリーである、請求項２６に記載のデバッグコントローラ。
28. 前記複数のデバッグマシンのそれぞれが、検出基準を、マルチコアプロセッサーアーキテクチャー内におけるスレッドの割り付けおよび実行を指示する信号と比較するための比較器をさらに備える、請求項２６または２７に記載のデバッグコントローラ。
29. 前記複数のデバッグマシンの出力が、前記デバッグマシン比較器の出力間の関係を制御するための制御ロジックによって互いにインターコネクトされ、デバッグマシン出力間の前記関係が、
    ＡＮＤ演算関係、
    ＯＲ演算関係、または、
    ＸＯＲ演算関係、
    のいずれかである、請求項２８に記載のデバッグコントローラ。
30. マルチコアプロセッサーアーキテクチャー内におけるスレッドの割り付けおよび実行を指示する信号内において検出された１つ以上の検出基準の特定のインスタンスの検出に関連するアクション命令を復号化するための命令復号器をさらに備える、請求項２９に記載のデバッグコントローラ。
31. 複数のフィルターが、基準マスクのリストを備え、前記フィルターのそれぞれが、マスクのリスト内に一組の連続的なマスクを備え、前記フィルターのそれぞれが、フィルターイネーブル信号のアサーションによってイネーブル状態にされる、請求項２４に記載のデバッグコントローラ。
32. 外部デバッグホストからの第１のプロトコルに基づいたデバッグ制御入力信号を、デバッグコントローラを制御するのに適した第２の異なるプロトコルに基づいた信号に変換するためのプロトコル変換器をさらに備える、請求項２１〜３１のいずれか一項に記載のデバッグコントローラ。

Images