JP5496578B2 - 高密度スレッド化ネットワーク・オン・ア・チップにおけるソフトウェア制御の任意ベクトル・オペランド選択をサポートする直接スレッド間通信バッファ - Google Patents

Description

本発明は、コンピュータの分野に関し、具体的にはスレッド化コンピュータ（threadedcomputer）に関する。さらに詳細には、本発明は、ネットワーク・オン・ア・チップ（ＮＯＣ：NetworkOn a Chip）集積回路プロセッサに関する。

ネットワーク・オン・ア・チップ（ＮＯＣ）は、固有の処理装置を作成するために単一チップにネットワーク・アーキテクチャを適用する新規な集積回路である。演算論理装置とメモリとの間、ならびにシステム・バスおよび入出力（Ｉ／Ｏ）バスに沿った演算論理装置と入出力バッファとの間を流れるデータを調整する制御装置を有する標準的な単一フォン・ノイマン・アーキテクチャを利用するのではなく、ＮＯＣはパケットを使用して論理ノード（そのそれぞれがノイマン型プロセッサを利用することができる）間でデータを渡す。各パケットは、そのパケットを受信し処理する予定の論理ノードをアドレス指定するヘッダと、ペイロード（たとえば、データ、命令など）とを含む。しかし、多くの場合、パケット内のデータは、論理ノードのデータ・ロード・プロトコル要件に関して、未整列である（unaligned）か、または整列がずれている（misaligned）。

高スレッド化ネットワーク・オン・ア・チップ（ＮＯＣ）プロセッサ内の任意に整列された（aligned）ベクトル・オペランドを検索するためのコンピュータによって実行される方法、システム、およびコンピュータ・プログラム（computerprogram product）が提示される。

ＮＯＣ内の複数のノードは、単一の圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ：Compressed Direct Interthread Communication Buffer）にアクセスすることができ、そのバッファは整列がずれているが短縮されたセットのオペランドを含む。ＮＯＣ内の特殊目的レジスタ（ＳＰＲ：Special Purpose Register）からの情報を使用して、各ノードは、そのノード内の実行ユニットで使用するためにＣＤＩＣＢから１つまたは複数のオペランドを選択的に抽出することができる。次に、実行ユニットからの出力がＣＤＩＣＢに送信され、短縮されたセットのオペランドを更新する。

本発明の上記ならびに追加の目的、特徴、および利点は、以下の詳細な説明で明らかになるであろう。

本発明に特有なものと思われる新規な特徴は特許請求の範囲に明記されている。しかし、本発明そのもの、ならびにその好ましい使用態様、追加の目的および利点は、添付図面に併せて読んだときに、以下に示す例示的な一実施形態の詳細な説明を参照することにより、最も良く理解できるであろう。

複数のスレッドを有する模範的なネットワーク・オン・ア・チップ（ＮＯＣ）を示す図である。 未圧縮直接スレッド間通信バッファ（Uncompressed Direct Inter-thread Communication buffer）に保管された未整列データを示す図である。 本発明の一実施形態により１つまたは複数のＮＯＣを利用するコンピュータの模範的な一実施形態を示す図である。 図３に描写されている１つまたは複数のＮＯＣの追加の詳細を示す図である。 図４に示されているＮＯＣからのプロセッサ・ノードの追加の詳細を示す図である。 図５に示されているプロセッサ・ノードで検出されるプロセッサ・コアの追加の詳細を示す図である。 単一プロセッサ・コア内の複数のハードウェア・スレッドを示す図である。 圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）およびオペランド・マルチプレクサ（ＭＵＸ：multiplexer）特殊目的レジスタ（ＳＰＲ）を利用して、選択されたオペランドをＮＯＣ内の複数のプロセッサ・ノードに提供する、本発明のＮＯＣの模範的な一実現例を示す図である。 図１〜図８に記載されているＮＯＣ内の整列／圧縮ロジックにより整列がずれ、しかも圧縮されている、整列された未圧縮直接スレッド間通信バッファ（ＵＤＩＣＢ）からのデータを示す図である。 圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）からデータを抽出し整列するためのプロセッサ・ノード内のロジックを示す図である。 プロセッサ・ノードがＣＤＩＣＢから検索したオペランドを整列し、利用し、再度整列をずらす（re-misalign）ために本発明によって行われる模範的な諸ステップの高レベル流れ図である。

特定のソフトウェア・アプリケーションは、ネットワーク・オン・ア・チップ（ＮＯＣ）内の種々のノードを１つのジョブのそれぞれ異なる部分に割り振るように、ＮＯＣを利用する。たとえば、図１に描写されているＮＯＣ１０２について考慮する。ＮＯＣ１０２は、ホスト・コンピュータ１０４内のユーザ・アプリケーション１１２から実行可能ソフトウェア命令を受信し、これらの命令を処理し、次に、実行結果を出力装置１０６（たとえば、モニター、プリンタ、記憶装置など）に出力する。図１に記載されている例では、ＮＯＣ１０２内に４つのハードウェア・スレッド１０８ａ〜１０８ｄが存在し、そのそれぞれがユーザ・アプリケーション１１２によって記述されたジョブの異なる部分を実行する。それぞれのスレッド１０８ａ〜１０８ｄは、１つのハードウェア・プロセッサ・ロジックから構成され、ユーザ・アプリケーション１１２によって実行される全体的なジョブに関する特定のサブタスクを実行するために専門化されたソフトウェア・セットに関連付けることもできる。したがって、スレッド１０８ａは全体的なジョブの第１の部分を処理することができ、その結果、第１の出力がパケット１１０ａ内に置かれ、第２のスレッド１０８ｂに送信される。次に、第２のスレッドはパケット１１０ａからのデータを処理し、その結果、第２の出力がパケット１１０ｂ内にパケット化され、第３のスレッド１０８ｃに送信される。第３のスレッドはパケット１１０ｂからのデータを処理し、その結果、第３の出力がパケット１１０ｃ内にパケット化され、第４のスレッド１０８ｄに送信され、その第４のスレッド１０８ｄはパケット１１０ｄからのデータを処理する。次に、第４のスレッド１０８ｄは、出力装置１０６に送信される最終出力パケット１１０ｄを生成することにより、全体的なジョブに必要な最終操作を完了する。

スレッド１０８ａ〜１０８ｄのうちの模範的な１つのスレッドの追加の詳細は図２にスレッド２０８として提示されている。スレッド２０８内には処理ハードウェア２０２があり、これは、未圧縮直接スレッド間通信バッファ（ＵＤＩＣＢ）２０６からのデータを処理するためのプロセッサ、特定用途向け集積回路（ＡＳＩＣ）などにすることができる。以下に記載するように、ＵＤＩＣＢ２０６は、処理ハードウェア２０２によって実行される計算に使用されるオペランドなどのデータを含む。このデータは、ＮＯＣ内の複数のスレッド（処理ノード）によってアクセスすることができる。各スレッド２０８内には、ベクトル・レジスタ・ファイル２１０と、ベクトル実行パイプライン・データ検索ロジック２１２があり、このデータ検索ロジック２１２により、各行のデータ・ワード（すなわち、データ・ワード集合（data word aggregation））が実行のために１つの単位としてまとめて処理ハードウェア２０２内にロードされる。図２における以下の問題に留意されたい。パケット・バッファ２０６からの各行のデータは、１行に含まれるデータの種類や有無にかかわらず、固定サイズの単一集合として処理ハードウェア２０２内にロードされる。すなわち、図２に描写されている例に示されているように、処理ハードウェア２０２は、実際に１行に含まれるワード数にかかわらず、ロード・コマンドが実行されると必ず、４ワードのライン全体をロードする。したがって、複数のデータ・ワードの集合（行）はそれぞれ異なるサイズのものであるので、ＵＤＩＣＢ２０６には「穴（hole）」ができる。すなわち、行２１４は、３ワードの集合としてデータ・ワード「ａ、ｂ、ｃ」を含み、「ｄ」というワードをまったく持たないデータ集合を保管する。したがって、ＵＤＩＣＢ２０６の行２１４には空のブロック２１６が存在する。データ集合（行全体）が４ワード未満であるので、ＵＤＩＣＢ２０６内に保管されている他の行のデータも同様に空のブロック・セルを有する。伝送トラフィックが（ヌル・データで）膨張し、ＵＤＩＣＢからデータを伝送するために使用されるパケット・バッファはこのような存在しないデータのための空間を確保するのに十分な大きさになるように設計しなければならないので、存在しないワードを伝送し、「バッファリング」すると、システム内、特にＮＯＣ内の全体的な効率が低下する。

図２に提示されている問題を本発明によってどのように対処するかを調べる前に、本発明による１つまたは複数のＮＯＣを利用し、図３に描写されている模範的なコンピュータ３０２について考慮する。描写されている通り、図３は、少なくとも１つのコンピュータ・プロセッサ３０４を含む、模範的なコンピュータ３０２のブロック図を明記している。コンピュータ・プロセッサ３０４は、標準的なノイマン型のプロセッサまたはＮＯＣにすることができる。コンピュータ３０２は、高速メモリ・バス３０８およびバス・アダプタ３１０によりプロセッサ３０４およびコンピュータ３０２の他のコンポーネントに結合されるシステム・メモリである、ランダム・アクセス・メモリ（ＲＡＭ）３０６も含む。

ＲＡＭ３０６には、たとえば、ワード・プロセッシング、スプレッドシート、データベース操作、ビデオ・ゲーム、株式市場シミュレーション、原子量子プロセス・シミュレーション、またはその他のユーザレベル・アプリケーションなどの特定のデータ処理タスクを実行するためのコンピュータ・プログラム命令のモジュールであるアプリケーション・プログラム３１２が保管されている。また、アプリケーション・プログラム３１２は、上記の図１〜図２および以下の図８〜図１１に記載されているものなどの制御プロセスも含む。また、ＲＡＭ３０６には、オペレーティング・システム（ＯＳ）３１４も保管されている。ＯＳ３１４は、アプリケーション・プログラム３１２などのリソースへの透過的ユーザ・アクセスを可能にするためにシェル３１６を含む。一般に、シェル３１６は、ユーザとオペレーティング・システムとの間のインタープリタおよびインターフェースを提供するプログラムである。より具体的には、シェル３１６は、コマンド・ライン・ユーザ・インターフェースに入力されたかまたはファイルから入力されたコマンドを実行する。したがって、コマンド・プロセッサとも呼ばれるシェル３１６は、一般に、オペレーティング・システムのソフトウェア階層の最高レベルであり、コマンド・インタープリタとして機能する。シェルは、システム・プロンプトを提供し、キーボード、マウス、またはその他のユーザ入力媒体によって入力されたコマンドを解釈し、解釈されたコマンド（複数も可）を処理のためにオペレーティング・システムの適切な下位レベル（たとえば、カーネル３１８）に送信する。シェル３１６はテキストベースで行指向のユーザ・インターフェースであるが、本発明は、図形、音声、ジェスチャなどの他のユーザ・インターフェース・モードも等しくサポートすることに留意されたい。

描写されている通り、ＯＳ３１４は、メモリ管理、プロセスおよびタスク管理、ディスク管理、ならびにマウスおよびキーボード管理を含む、ＯＳ３１４の他の部分およびアプリケーション・プログラム（たとえば、アプリケーション３１２）によって要求される本質的なサービスの提供を含む、ＯＳ３１４用の下位レベルの機能を含むカーネル３１８も含む。

図３の例のオペレーティング・システム３１４およびアプリケーション３１２はＲＡＭ３０６内に示されているが、このようなソフトウェア・コンポーネントは、データ記憶装置３２０としてのディスク・ドライブ上などの不揮発性メモリに保管することもできる。

このコンピュータ例３０２は、ＮＯＣビデオ・アダプタ３２２およびＮＯＣコプロセッサ３２４という本発明の諸実施形態による２つのＮＯＣ例を含む。ＮＯＣビデオ・アダプタ３２２は、ディスプレイ画面またはコンピュータ・モニターなどのディスプレイ装置３４６への図形出力のために特別に設計されたＩ／Ｏアダプタの一例である。ＮＯＣビデオ・アダプタ３２２は、高速ビデオ・バス３２６、バス・アダプタ３１０、および同じく高速バスであるフロント・サイド・バス３２８によりプロセッサ３０４に接続される。

このＮＯＣコプロセッサ例３２４は、バス・アダプタ３１０、フロント・サイド・バス３２８、および同じく高速バスであるフロント・サイド・バス３３０によりプロセッサ３０４に接続される。ＮＯＣコプロセッサ３２４は、メイン・プロセッサ３０４の命令で特定のデータ処理タスクを加速するように最適化される。

このＮＯＣビデオ・アダプタ例３２２およびＮＯＣコプロセッサ例３２４はそれぞれ、統合プロセッサ（「ＩＰ：Integrated Processor」）ブロック、ルータ、メモリ通信コントローラ、およびネットワーク・インターフェース・コントローラを含む、本発明の一実施形態によるＮＯＣを含み、各ＩＰブロックはメモリ通信コントローラおよびネットワーク・インターフェース・コントローラによりルータに対して適合され、各メモリ通信コントローラはＩＰブロックとメモリとの間の通信を制御し、各ネットワーク・インターフェース・コントローラはルータによるＩＰブロック間通信を制御する。ＮＯＣビデオ・アダプタ３２２およびＮＯＣコプロセッサ３２４は、並列処理を使用し、共用メモリへの高速ランダム・アクセスも必要とするプログラム用に最適化される。しかし、一実施形態では、本明細書に記載され、本発明によって使用するために企図されているＮＯＣは、共用メモリへの直接アクセスではなく、パケット・データのみを利用する。この場合も、本発明によって使用するために企図されている模範的なＮＯＣアーキテクチャの追加の詳細は以下の図４〜図１０に提示されることに留意されたい。

引き続き図３について説明すると、コンピュータ３０２は、拡張バス３３４およびバス・アダプタ３１０によりプロセッサ３０４およびコンピュータ３０２の他のコンポーネントに結合されたディスク・ドライブ・アダプタ３３２を含むことができる。ディスク・ドライブ・アダプタ３３２は、データ記憶装置３２０として表されたディスク・ドライブの形で不揮発性データ記憶装置をコンピュータ３０２に接続する。本発明の諸実施形態によるＮＯＣによるデータ処理のためにコンピュータ内で有用なディスク・ドライブ・アダプタとしては、統合ドライブ・エレクトロニクス（「ＩＤＥ：Integrated Drive Electronics」）アダプタ、小型コンピュータ・システム・インターフェース（「ＳＣＳＩ：Small Computer System Interface」）アダプタ、当業者にとって思い浮かぶその他のものを含む。当業者にとって思い浮かぶように、光ディスク・ドライブ、電気的消去可能プログラマブル読み取り専用メモリ（いわゆる「ＥＥＰＲＯＭ」または「フラッシュ」メモリ）などの不揮発性コンピュータ・メモリも実現することができる。

このコンピュータ例３０２は、１つまたは複数の入出力（「Ｉ／Ｏ」）アダプタ３３６も含む。Ｉ／Ｏアダプタ（複数も可）３３６は、たとえば、コンピュータ・ディスプレイ画面などのディスプレイ装置への出力ならびにキーボードおよびマウスなどのユーザ入力装置３３８からのユーザ入力を制御するためのソフトウェア・ドライバおよびコンピュータ・ハードウェアによるユーザ指向入出力を実現する。

模範的なコンピュータ３０２は、他のコンピュータ３４２とのデータ通信のためならびにデータ通信ネットワーク３４４とのデータ通信のために通信アダプタ３４０も含むことができる。このようなデータ通信は、ＲＳ−２３２接続により、ユニバーサル・シリアル・バス（「ＵＳＢ」）などの外部バスにより、ＩＰデータ通信ネットワークなどのデータ通信ネットワークにより、さらに当業者にとって思い浮かぶその他の方法で、シリアルに実行することができる。通信アダプタは、直接またはデータ通信ネットワークを介して、あるコンピュータが他のコンピュータにデータ通信を送信するハードウェア・レベルのデータ通信を実現する。本発明の諸実施形態によるＮＯＣとともにデータ処理に有用な通信アダプタの例としては、有線ダイヤルアップ通信のためのモデム、有線データ通信ネットワーク通信のためのイーサネット（ＩＥＥＥ８０２．３）アダプタ、および無線データ通信ネットワーク通信のためのＩＥＥＥ８０２．ｘアダプタを含む。

ＮＯＣビデオ・アダプタ３２２およびＮＯＣコプロセッサ３２４はＮＯＣの２つの模範的な使い方に過ぎないが、本明細書に記載されているＮＯＣならびに作業パケットの制御は、ＮＯＣがデータ処理に有用であるコンテキストであれば、どのようなコンテキストでも見つけられることに留意されたい。

次に図４に関連して説明すると、本発明の諸実施形態による模範的なＮＯＣ４０２の機能ブロック図が提示されている。ＮＯＣ４０２は、図３に示されているＮＯＣビデオ・アダプタ３２２またはＮＯＣコプロセッサ３２４あるいはその両方として利用可能な模範的なＮＯＣである。ＮＯＣ４０２は、集積回路チップ４００上に実現され、ホスト・コンピュータ１０４（たとえば、図３に示されているプロセッサ３０４）によって制御される。ＮＯＣ４０２は、統合プロセッサ（「ＩＰ」）ブロック４０４と、ルータ４１０と、メモリ通信コントローラ４０６と、ネットワーク・インターフェース・コントローラ４０８とを含む。各ＩＰブロック４０４は、専用メモリ通信コントローラ４０６および専用ネットワーク・インターフェース・コントローラ４０８によりルータ４１０に対して適合されている。各メモリ通信コントローラ４０６は、ＩＰブロック４０４とメモリ（たとえば、オンチップ・メモリ４１４またはオフチップ・メモリ４１２あるいはその両方）との間の通信を制御し、各ネットワーク・インターフェース・コントローラ４０８は、ルータ４１０によりＩＰブロック間通信を制御する。

ＮＯＣ４０２では、各ＩＰブロック４０４は、ＮＯＣ４０２内のデータ処理のためのビルディング・ブロックとして使用される同期または非同期論理設計の再使用可能ユニットを表す。「ＩＰブロック」という用語は、「知的財産ブロック」と呼ばれることもあり、したがって、ＩＰブロック４０４は、ある当事者によって所有され、ある当事者の知的財産であり、半導体回路の他のユーザまたは設計者にライセンス供与される設計として指定される。しかし、本発明の範囲では、ＩＰブロックは任意の特定の所有権の対象とするという要件はまったくなく、したがって、この用語は本明細書では必ず「統合プロセッサ・ブロック」として詳述される。したがって、ここで指定されるＩＰブロック４０４は、知的財産の主題である場合もあれば、主題ではない場合もある、論理、セル、またはチップ・レイアウト設計の再使用可能ユニットである。さらに、ＩＰブロック４０４は、特定用途向け集積回路（ＡＳＩＣ）チップ設計またはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）論理設計として形成可能な論理コアである。

類推によってＩＰブロックを説明すると、ＩＰブロックがＮＯＣ設計のためのものであり、ライブラリがコンピュータ・プログラミングのためのものであり、離散集積回路コンポーネントがプリント回路板設計のためのものであるということになる。本発明の諸実施形態によるＮＯＣでは、ＩＰブロックは、汎用ゲート・ネットリストとして、完全な特殊目的または汎用マイクロプロセッサとして、あるいは当業者にとって思い浮かぶ他の方法で、実現することができる。ネットリストは、高レベル・プログラム・アプリケーションのためのアセンブリ・コード・リストに類似したＩＰブロックの論理機能のブール代数表現（ゲート、標準セル）である。また、ＮＯＣは、たとえば、ＶｅｒｉｌｏｇまたはＶＨＳＩＣハードウェア記述言語（ＶＨＤＬ）などのハードウェア記述言語で記述された合成可能な形で実現することもできる。ネットリストおよび合成可能な実現例に加えて、ＮＯＣは、下位レベルの物理的記述で配布することもできる。シリアライザ／デシリアライザ（ＳＥＲＤＥＳ）、フェイズロック・ループ（ＰＬＬ）、デジタル・アナログ変換器（ＤＡＣ）、アナログ・デジタル変換器（ＡＤＣ）などのアナログＩＰブロック・エレメントは、グラフィック・データ・システムＩＩ（ＧＤＳＩＩ）などのトランジスタレイアウト・フォーマットで配布することができる。ＩＰブロックのデジタル・エレメントもレイアウト・フォーマットで提供されることもある。

図４に示されている各ＩＰブロック４０４は、メモリ通信コントローラ４０６によりルータ４１０に対して適合されている。各メモリ通信コントローラは、ＩＰブロックとメモリとの間のデータ通信を提供するように適合された同期および非同期論理回路の集合である。ＩＰブロックとメモリとの間のこのような通信の例としては、メモリ・ロード命令およびメモリ・ストア命令を含む。メモリ通信コントローラ４０６については、以下の図５においてより詳細に説明する。

また、図４に描写されている各ＩＰブロック４０４は、ネットワーク・インターフェース・コントローラ４０８によりルータ４１０に対して適合されている。各ネットワーク・インターフェース・コントローラ４０８は、ＩＰブロック４０４同士のルータ４１０による通信を制御する。ＩＰブロック同士の通信の例としては、並列アプリケーションおよびパイプライン化アプリケーションにおいてＩＰブロック間でデータを処理するための命令とそのデータを伝達するメッセージ（たとえば、メッセージ／データ・パケット）を含む。ネットワーク・インターフェース・コントローラ４０８については、以下の図５においてより詳細に説明する。

ルータ４１０およびルータ間のリンク４２０は、図４に示されているＮＯＣ４０２のネットワーク操作を実現する。リンク４２０は、すべてのルータを接続する物理的な並列ワイヤ・バス上に実現されたパケット構造である。すなわち、各リンクは、すべてのヘッダ情報およびペイロード・データを含む、データ交換パケット全体を同時に収容するために十分な幅のワイヤ・バス上に実現される。パケット構造が、たとえば、８バイトのヘッダと５６バイトのペイロード・データを含む６４バイトを含む場合、各リンクの範囲を定めるワイヤ・バスは６４バイト幅であり、したがって、５１２本のワイヤを必要とする。加えて、各リンク４２０は双方向性であり、したがって、リンク・パケット構造が６４バイトを含む場合、ワイヤ・バスは、実際にはネットワーク内の各ルータ４１０とその隣接ルータ４１０のそれぞれとの間の１０２４本のワイヤを含む。１つのメッセージは２つ以上のパケットを含むことができるが、各パケットはワイヤ・バスの幅に正確に収まる。ルータとワイヤ・バスの各セクションとの間の接続をポートという場合、各ルータは、ネットワーク上の４つの方向のデータ伝送のそれぞれについて１つずつと、メモリ通信コントローラおよびネットワーク・インターフェース・コントローラにより特定のＩＰブロックに対してルータを適合させるための第５のポートという５つのポートを含む。

上記の通り、各メモリ通信コントローラ４０６は、ＩＰブロックとメモリとの間の通信を制御する。メモリは、オフチップ・メインＲＡＭ４１２、メモリ通信コントローラ４０６によりＩＰブロックに直接接続されるオンチップ・メモリ４１５、ＩＰブロックとして使用可能になっているオンチップ・メモリ４１４、およびオンチップ・キャッシュを含むことができる。図４に示されているＮＯＣ４０２では、たとえば、オンチップ・メモリ（４１４、４１５）のいずれかをオンチップ・キャッシュ・メモリとして実現することができる。これらの形式のメモリはいずれも、ＩＰブロックに直接付加されたメモリの場合でも、物理アドレスまたは仮想アドレスの同じアドレス空間に配置することができる。したがって、このようなメモリはネットワーク上のどこでも任意のＩＰブロックから直接アドレス指定することができるので、メモリ・アドレス指定メッセージはＩＰブロックに対して全面的に双方向性にすることができる。ＩＰブロック上のオンチップ・メモリ４１４は、そのＩＰブロックまたはＮＯＣ内の任意の他のＩＰブロックからアドレス指定することができる。オンチップ・メモリ４１５は、メモリ通信コントローラに直接付加され、そのメモリ通信コントローラによってネットワークに対して適合されるＩＰブロックによってアドレス指定することができる。また、オンチップ・メモリ４１５は、ＮＯＣ４０２内のどこでも任意の他のＩＰブロック４０４からアドレス指定することもできる。

模範的なＮＯＣ４０２は、２つのメモリ管理ユニット（「ＭＭＵ：MemoryManagement Unit」）４０７および４０９を含み、本発明の諸実施形態によるＮＯＣのための２つの代替メモリ・アーキテクチャを例示している。ＭＭＵ４０７は、特定のＩＰブロック４０４で実現され、そのＩＰブロック４０４内のプロセッサが仮想メモリで動作できるようにし、ＮＯＣ４０２の残りのアーキテクチャ全体が物理的なメモリ・アドレス空間で動作できるようにする。ＭＭＵ４０９は、ポート４１６として参照されるデータ通信ポートによりＮＯＣに接続されたオフチップとして実現される。ポート４１６は、ＮＯＣ４０２とＭＭＵ４０９との間の信号を伝導するために必要なピンおよびその他の相互接続部ならびにＮＯＣパケット・フォーマットから外部ＭＭＵ４０９によって要求されるバス・フォーマットにメッセージ・パケットを変換するために十分な知能を含む。ＭＭＵ４０９の外部位置とは、ＮＯＣ４０２のすべてのＩＰブロック４０４内のすべてのプロセッサが仮想メモリ・アドレス空間で動作することができ、オフチップ・メモリの物理アドレスへのすべての変換がオフチップＭＭＵ４０９によって処理されることを意味する。

ＭＭＵ４０７および４０９の使用により例示される２つのメモリ・アーキテクチャに加えて、ポート４１８として描写されているデータ通信ポートは、本発明の諸実施形態によるＮＯＣにおいて有用な第３のメモリ・アーキテクチャを例示するものである。ポート４１８は、ＮＯＣ４０２のＩＰブロック４０４とオフチップ・メモリ４１２との間の直接接続を提供する。処理経路内にＭＭＵがまったくない場合、このアーキテクチャはＮＯＣのすべてのＩＰブロックによる物理アドレス空間の利用を可能にする。このアドレス空間を双方向的に共用する際に、ＮＯＣのすべてのＩＰブロックは、ポート４１８に直接接続されたＩＰブロックにより向けられた、ロードおよびストアを含む、メモリ・アドレス指定メッセージによりアドレス空間内のメモリにアクセスすることができる。ポート４１８は、ＮＯＣとオフチップ・メモリ４１２との間の信号を伝導するために必要なピンおよびその他の相互接続部ならびにＮＯＣパケット・フォーマットからオフチップ・メモリ４１２によって要求されるバス・フォーマットにメッセージ・パケットを変換するために十分な知能を含む。

図４に示されている模範的なＮＯＣ４０２では、ＩＰブロック４０４の１つはホスト・インターフェース・プロセッサ４０５として指定される。ホスト・インターフェース・プロセッサ４０５は、ＮＯＣ４０２とホスト・コンピュータ１０４（図１に紹介されている）との間のインターフェースを提供する。ホスト・インターフェース・プロセッサ４０５は、たとえば、ホスト・コンピュータからＮＯＣデータ処理要求を受信し、ＩＰブロック間でディスパッチすることを含む、データ処理サービスをＮＯＣ上の他のＩＰブロックに提供する。

ホスト・インターフェース・プロセッサ４０５は、ポート４１７などのデータ通信ポートにより、より大型のホスト・コンピュータ１０４（初めは図１に描写されている）に接続される。ポート４１７は、ＮＯＣ４０２とホスト・コンピュータ１０４との間の信号を伝導するために必要なピンおよびその他の相互接続部ならびにＮＯＣ４０２からホスト・コンピュータ１０４によって要求されるバス・フォーマットにメッセージ・パケットを変換するために十分な知能を含む。図３に示されているコンピュータ３０２内のＮＯＣコプロセッサ３２４の例では、このようなポートは、ＮＯＣコプロセッサ３２４とバス・アダプタ３１０との間のフロント・サイド・バス３３０に必要なプロトコルと、ＮＯＣコプロセッサ３２４のリンク構造とのデータ通信フォーマット変換を可能にするであろう。

各グループの要素４０４、４０６、４０８、および４１０は、ＮＯＣ４０２内のノード４２２として表示し参照することができることに留意されたい。

次に図５を参照すると、本発明の諸実施形態によるＮＯＣ４０２の追加の詳細が提示されている。図４および図５に描写されている通り、ＮＯＣ４０２は、チップ（たとえば、図４に示されているチップ４００）上に実現され、統合プロセッサ（「ＩＰ」）ブロック４０４、ルータ４１０、メモリ通信コントローラ４０６、およびネットワーク・インターフェース・コントローラ４０８を含む。各ＩＰブロック４０４はメモリ通信コントローラ４０６およびネットワーク・インターフェース・コントローラ４０８によりルータ４１０に対して適合される。各メモリ通信コントローラ４０６はＩＰブロックとメモリとの間の通信を制御し、各ネットワーク・インターフェース・コントローラ４０８はルータ４１０によるＩＰブロック間通信を制御する。図５の例では、その構造および動作に関するより詳細な説明を支援するために、メモリ通信コントローラ４０６およびネットワーク・インターフェース・コントローラ４０８によりルータ４１０に対して適合されたＩＰブロック４０４のセット５２２が拡大されている。図５の例のＩＰブロック、メモリ通信コントローラ、ネットワーク・インターフェース・コントローラ、およびルータはいずれも、拡大セット５２２と同じように構成される。

図５の例では、各ＩＰブロック４０４は、１つまたは複数のコア５５０を含むコンピュータ・プロセッサ５２６と、Ｉ／Ｏ機能５２４とを含む。この例では、コンピュータ・メモリは、各ＩＰブロック４０４内のランダム・アクセス・メモリ（「ＲＡＭ」）５２８のセグメントによって表される。図４の例に関連して上述したように、このメモリは、各ＩＰブロック上のその内容がＮＯＣ内の任意のＩＰブロックからアドレス指定可能でありアクセス可能である物理アドレス空間のセグメントを占有することができる。各ＩＰブロック上のプロセッサ５２６、Ｉ／Ｏ機能５２４、およびメモリ（ＲＡＭ５２８）は、一般にプログラム可能なマイクロコンピュータとしてＩＰブロックを効果的に実現する。しかし、上記で説明したように、本発明の範囲では、ＩＰブロックは一般に、ＮＯＣ内のデータ処理のためのビルディング・ブロックとして使用される同期または非同期論理の再使用可能ユニットを表す。したがって、一般にプログラム可能なマイクロコンピュータとしてＩＰブロックを実現することは、説明のために有用な共通の一実施形態であるが、本発明の制限ではない。

図５に示されているＮＯＣ４０２では、各メモリ通信コントローラ４０６は複数のメモリ通信実行エンジン５４０を含む。各メモリ通信実行エンジン５４０は、ネットワーク・インターフェース・コントローラ４０８とＩＰブロック４０４との間の双方向メモリ通信命令の流れ（５４４、５４５、５４６）を含む、ＩＰブロック４０４からのメモリ通信命令を実行できるようになっている。メモリ通信コントローラによって実行されるメモリ通信命令は、特定のメモリ通信コントローラによりルータに対して適合されたＩＰブロックからだけでなく、ＮＯＣ４０２内のどこでも任意のＩＰブロック４０４からも発生することができる。すなわち、ＮＯＣ４０２内の任意のＩＰブロック４０４は、メモリ通信命令を生成し、そのメモリ通信命令の実行のためにＮＯＣ４０２のルータ４１０により他のＩＰブロックに関連する他のメモリ通信コントローラにそのメモリ通信命令を伝送することができる。このようなメモリ通信命令は、たとえば、変換索引バッファ制御命令、キャッシュ制御命令、バリア命令、ならびにメモリ・ロードおよびストア命令を含むことができる。

描写されているメモリ通信実行エンジン５４０のそれぞれは、完全なメモリ通信命令を単独でならびに他のメモリ通信実行エンジン５４０と並列に実行できるようになっている。メモリ通信実行エンジン５４０は、メモリ通信命令の同時スループットのために最適化されたスケーラブル・メモリ・トランザクション・プロセッサを実現する。メモリ通信コントローラ４０６は複数のメモリ通信実行エンジン５４０をサポートし、そのすべてのエンジンは複数のメモリ通信命令を同時実行するために同時に動作する。新しいメモリ通信命令はメモリ通信コントローラ４０６によって各メモリ通信実行エンジン５４０に割り振られ、メモリ通信実行エンジン５４０は複数の応答イベントを同時に受け入れることができる。この例では、メモリ通信実行エンジン５４０はすべて同一である。したがって、メモリ通信コントローラ４０６によって同時に処理できるメモリ通信命令の数のスケーリングは、メモリ通信実行エンジン５４０の数をスケーリングすることによって実現される。

図５に描写されているＮＯＣ４０２では、各ネットワーク・インターフェース・コントローラ４０８は、ルータ４１０によりＩＰブロック４０４間で伝送するためにコマンド・フォーマットからネットワーク・パケット・フォーマットに通信命令を変換できるようになっている。通信命令は、ＩＰブロック４１０によるかまたはメモリ通信コントローラ４０６によってコマンド・フォーマットで公式化され、コマンド・フォーマットでネットワーク・インターフェース・コントローラ４０８に提供される。コマンド・フォーマットは、ＩＰブロック４０４およびメモリ通信コントローラ４０６のアーキテクチャ・レジスタ・ファイルに準拠するネイティブ・フォーマットである。ネットワーク・パケット・フォーマットは、ネットワークのルータ４１０による伝送に必要なフォーマットである。このようなメッセージはそれぞれ、１つまたは複数のネットワーク・パケットから構成される。ネットワーク・インターフェース・コントローラでコマンド・フォーマットからパケット・フォーマットに変換されるこのような通信命令の例としては、ＩＰブロックとメモリとの間のメモリ・ロード命令およびメモリ・ストア命令を含む。このような通信命令は、並列アプリケーションおよびパイプライン化アプリケーションにおいてＩＰブロック間でデータを処理するための命令とそのデータを伝達するＩＰブロック間でメッセージを送信する通信命令も含むことができる。

図５に示されているＮＯＣ４０２では、各ＩＰブロック４０４は、ＩＰブロックのメモリ通信コントローラによりメモリとの間でメモリアドレスベースの通信を送信し、次にそのネットワーク・インターフェース・コントローラによりネットワークにメモリアドレスベースの通信を送信できるようになっている。メモリアドレスベースの通信は、ＩＰブロックのメモリ通信コントローラのメモリ通信実行エンジンによって実行される、ロード命令またはストア命令などのメモリ・アクセス命令である。このようなメモリアドレスベースの通信は、典型的には、ＩＰブロックで発生し、コマンド・フォーマットで公式化され、実行のためにメモリ通信コントローラに受け渡される。

アクセスすべきメモリはいずれも、ＮＯＣ内の任意のメモリ通信コントローラに直接付加されたオンチップまたはオフチップの物理メモリ・アドレス空間内のどこにでも位置することができるか、またはどのＩＰブロックが任意の特定のメモリアドレスベースの通信を発生したかにかかわらず、ＮＯＣの任意のＩＰブロックにより最終的にアクセスすることができるので、多くのメモリアドレスベースの通信はメッセージ・トラフィックで実行される。メッセージ・トラフィックで実行されるすべてのメモリアドレスベースの通信は、（命令変換ロジック５３６を使用して）コマンド・フォーマットからパケット・フォーマットに変換し、メッセージに入れてネットワークにより伝送するために、メモリ通信コントローラから関連のネットワーク・インターフェース・コントローラに渡される。パケット・フォーマットに変換する際に、ネットワーク・インターフェース・コントローラは、メモリアドレスベースの通信によってアクセスすべき１つまたは複数のメモリ・アドレスに依存して、そのパケットに関するネットワーク・アドレスも識別する。メモリアドレスベースのメッセージはメモリ・アドレスでアドレス指定される。各メモリ・アドレスは、ネットワーク・インターフェース・コントローラによってネットワーク・アドレスにマッピングされ、典型的には、ある範囲の物理メモリ・アドレスを担当するメモリ通信コントローラのネットワーク位置にマッピングされる。メモリ通信コントローラ４０６のネットワーク位置は、当然、そのメモリ通信コントローラの関連ルータ４１０、ネットワーク・インターフェース・コントローラ４０８、およびＩＰブロック４０４のネットワーク位置でもある。各ネットワーク・インターフェース・コントローラ内の命令変換ロジック５３６は、ＮＯＣのルータによりメモリアドレスベースの通信を伝送するために、メモリ・アドレスをネットワーク・アドレスに変換することができる。

ネットワークのルータ４１０からメッセージ・トラフィックを受信すると、各ネットワーク・インターフェース・コントローラ４０８は、メモリ命令について各パケットを検査する。メモリ命令を含む各パケットは、受信側ネットワーク・インターフェース・コントローラに関連するメモリ通信コントローラ４０６に手渡され、そのネットワーク・インターフェース・コントローラは、パケットの残りのペイロードをＩＰブロックに送信してさらに処理する前に、メモリ命令を実行する。このようにして、メモリ内容はいつでも、ＩＰブロックが特定のメモリ内容に依存するメッセージからの命令の実行を開始する前に、ＩＰブロックによるデータ処理をサポートする準備ができている。

次に図５に描写されているＮＯＣ４０２に戻ると、各ＩＰブロック４０４は、そのメモリ通信コントローラ４０６をバイパスし、ＩＰブロックのネットワーク・インターフェース・コントローラ４０８によりネットワークに直接、ＩＰブロック間のネットワーク・アドレス指定通信５４６を送信できるようになっている。ネットワーク・アドレス指定通信は、ネットワーク・アドレスによって他のＩＰブロックに向けられたメッセージである。このようなメッセージは、当業者にとって思い浮かぶように、パイプライン化アプリケーション内の作業データ、ＳＩＭＤアプリケーション内のＩＰブロック間の単一プログラム処理のための複数データなどを伝送する。このようなメッセージは、ＮＯＣのルータによりメッセージが向けられるネットワーク・アドレスを把握している発生側ＩＰブロックにより、開始からネットワーク・アドレス指定されるという点で、メモリアドレスベースの通信とは異なるものである。このようなネットワーク・アドレス指定通信は、そのＩ／Ｏ機能５２４によりＩＰブロックによってコマンド・フォーマットでＩＰブロックのネットワーク・インターフェース・コントローラに直接渡され、次にネットワーク・インターフェース・コントローラによってパケット・フォーマットに変換され、ＮＯＣのルータにより他のＩＰブロックに伝送される。このようなネットワーク・アドレス指定通信５４６は、任意の特定のアプリケーションにおけるそれぞれの使い方に応じて、潜在的にＮＯＣの各ＩＰブロックとの間で移行する双方向性である。しかし、各ネットワーク・インターフェース・コントローラは、関連ルータとの間でこのような通信を送受信（通信５４２）できるようになっており、各ネットワーク・インターフェース・コントローラは、関連ＩＰブロックとの間でこのような通信を直接送受信（通信５４６）して、関連メモリ通信コントローラ４０６をバイパスできるようになっている。

図５の例の各ネットワーク・インターフェース・コントローラ４０８は、タイプ別にネットワーク・パケットを特徴付けて、ネットワーク上の仮想チャネルを実現できるようにもなっている。各ネットワーク・インターフェース・コントローラ４０８は、ＮＯＣ上で伝送するためにパケット形式でルータ４１０に命令を受け渡す前に、各通信命令をタイプ別に分類し、ネットワーク・パケット・フォーマットのフィールドに命令のタイプを記録する仮想チャネル実現ロジック５３８を含む。通信命令タイプの例としては、ＩＰブロック間ネットワークアドレスベースのメッセージ、要求メッセージ、要求メッセージへの応答、キャッシュに向けられた無効化メッセージ、メモリ・ロードおよびストア・メッセージ、ならびにメモリ・ロード・メッセージへの応答などを含む。

図５の例の各ルータ４１０は、経路指定ロジック５３０と、仮想チャネル制御ロジック５３２と、仮想チャネル・バッファ５３４とを含む。経路指定ロジックは、典型的には、ルータ４１０、リンク４２０、およびルータ間のバス・ワイヤによって形成されたネットワークにおけるデータ通信のためのデータ通信プロトコル・スタックを実現する同期および非同期論理のネットワークとして実現される。経路指定ロジック５３０は、当業者がオフチップ・ネットワークにおいてルーティング・テーブルと関連付けることができる機能を含み、少なくとも一部の実施形態のルーティング・テーブルはＮＯＣで使用するには遅すぎ厄介なものであると見なされている。同期および非同期論理のネットワークとして実現された経路指定ロジックは、単一クロック・サイクル程度の高速で経路指定決定を行うように構成することができる。この例の経路指定ロジックは、ルータで受信した各パケットを転送するためのポートを選択することによりパケットを経路指定する。各パケットは、そのパケットが経路指定されるネットワーク・アドレスを含む。この例の各ルータは、バス・ワイヤ（５２０−Ａ、５２０−Ｂ、５２０−Ｃ、５２０−Ｄ）により他のルータに接続された４つのポート５２１と、ネットワーク・インターフェース・コントローラ４０８およびメモリ通信コントローラ４０６により各ルータをその関連ＩＰブロック４０４に接続する第５のポート５２３という５つのポートを含む。

上記でメモリアドレスベースの通信について説明する際に、各メモリ・アドレスは、ネットワーク・インターフェース・コントローラによって、メモリ通信コントローラのネットワーク位置であるネットワーク・アドレスにマッピングされたものとして説明されている。メモリ通信コントローラ４０６のネットワーク位置は、当然、そのメモリ通信コントローラの関連ルータ４１０、ネットワーク・インターフェース・コントローラ４０８、およびＩＰブロック４０４のネットワーク位置でもある。したがって、ＩＰブロック間通信またはネットワークアドレスベースの通信では、アプリケーションレベルのデータ処理においてＮＯＣのルータ、リンク、およびバス・ワイヤによって形成されたネットワーク内のＩＰブロックの位置としてネットワーク・アドレスを表示することも典型的なことである。図４は、このようなネットワークの編成の１つが行と列のメッシュになっており、たとえば、そのメッシュの関連ルータ、ＩＰブロック、メモリ通信コントローラ、およびネットワーク・インターフェース・コントローラからなる各セット用の固有の識別子またはそのメッシュ内のこのような各セットのｘ、ｙ座標のいずれかとして、各ネットワーク・アドレスを実現できることを例示していることに留意されたい。

図５に描写されているＮＯＣ４０２では、各ルータ４１０は２つまたはそれ以上の仮想通信チャネルを実現し、各仮想通信チャネルは通信タイプによって特徴付けられる。通信命令タイプ、したがって、仮想チャネル・タイプとしては、ＩＰブロック間ネットワークアドレスベースのメッセージ、要求メッセージ、要求メッセージへの応答、キャッシュに向けられた無効化メッセージ、メモリ・ロードおよびストア・メッセージ、ならびにメモリ・ロード・メッセージへの応答など、上述のものを含む。仮想チャネルをサポートして、図５に描写されている各ルータ４１０は、仮想チャネル制御ロジック５３２および仮想チャネル・バッファ５３４も含む。仮想チャネル制御ロジック５３２は、それに割り当てられた通信タイプについて各受信パケットを検査し、ポートによりＮＯＣ上の隣接ルータに伝送するためにその通信タイプに関する発信仮想チャネル・バッファ内に各パケットを置く。

各仮想チャネル・バッファ５３４は有限の記憶空間を有する。多くのパケットが短期間に受信されると、仮想チャネル・バッファはいっぱいになる可能性があり、したがって、それ以上パケットをバッファに入れることができなくなる。他のプロトコルでは、そのバッファがいっぱいである仮想チャネル上に到着したパケットは除去されるであろう。しかし、この例の各仮想チャネル・バッファ５３４は、バス・ワイヤの制御信号により、仮想チャネルにおける伝送を中断する、すなわち、特定の通信タイプのパケットの伝送を中断するよう、仮想チャネル制御ロジックにより周囲のルータに勧告できるようになっている。ある仮想チャネルがこのように中断されると、他のすべての仮想チャネルは影響を受けず、全能力で動作し続けることができる。制御信号は、各ルータから各ルータの関連ネットワーク・インターフェース・コントローラ４０８まで全面的に有線になる。各ネットワーク・インターフェース・コントローラは、このような信号を受信すると、その関連メモリ通信コントローラ４０６からまたはその関連ＩＰブロック４０４から、中断された仮想チャネルに関する通信命令を受け入れることを拒否するよう構成される。このようにして、仮想チャネルの中断は、発生側ＩＰブロックまで全面的に、仮想チャネルを実現するすべてのハードウェアに影響する。

仮想チャネルにおけるパケット伝送を中断することによる影響の１つは、図５のアーキテクチャでどのパケットも除去されないことである。たとえば、インターネット・プロトコルなど、何らかの信頼できないプロトコルでパケットが除去される可能性のある状況をルータが検出した場合、バッファ空間がもう一度使用可能になり、パケットを除去する必要性が解消されるまで、図５の例のルータはその仮想チャネル・バッファ５３４およびその仮想チャネル制御ロジック５３２により仮想チャネル内のパケットのすべての伝送を中断する。したがって、図５に描写されているＮＯＣ４０２は、極めて薄い層のハードウェアにより高信頼性のネットワーク通信プロトコルを実現する。

次に図６を参照すると、元々は図５に提示されているコア５５０の追加の模範的な詳細が提示されている。コア５５０は、統一されたレベル２（Ｌ２）キャッシュ６１６と、それぞれ二叉のレベル１（Ｌ１）の命令（Ｉ）キャッシュ６１８およびデータ（Ｄ）キャッシュ６２０とを含む、オンチップ・マルチレベル・キャッシュ階層を含む。当業者にとって周知の通り、キャッシュ６１６、６１８、および６２０は、システム・メモリ（たとえば、図３に示されているＲＡＭ３０６）内のメモリ位置に対応するキャッシュ・ラインへの低待ち時間アクセスを可能にする。

命令取り出しアドレス・レジスタ（ＩＦＡＲ：instructionfetch address register）６３０内に常駐する有効アドレス（ＥＡ：effectiveaddress）に応答して、処理のためにＬ１ Ｉキャッシュ６１８から命令が取り出される。各サイクル中に、条件付き分岐命令の予測による投機的ターゲット経路（speculative target path）および順次アドレスを提供する分岐予測ユニット（ＢＰＵ：branch prediction unit）６３６、フラッシュおよび割り込みアドレスを提供するグローバル完了テーブル（ＧＣＴ：global completion table）６３８、予測された条件付き分岐命令の解決による非投機的アドレス（non-speculative address）を提供する分岐実行ユニット（ＢＥＵ：branchexecution unit）６９２という３つのソースのうちの１つからＩＦＡＲ６３０に新しい命令取り出しアドレスをロードすることができる。分岐履歴テーブル（ＢＨＴ：branch history table）６３５はＢＰＵ６３６に関連するものであり、今後の分岐命令の予測を支援するために条件付き分岐命令の解決がそこに記録される。

ＩＦＡＲ６３０内の命令取り出しアドレスなどの有効アドレス（ＥＡ）は、プロセッサによって生成された命令またはデータのアドレスである。ＥＡは、セグメント・レジスタおよびそのセグメント内のオフセット情報を指定する。メモリ内のデータ（命令を含む）にアクセスするために、ＥＡは、１つまたは複数のレベルの変換により、そのデータまたは命令が保管されている物理的位置に関連する実アドレス（ＲＡ：real address）に変換される。

コア５５０内では、有効／実アドレス変換は、メモリ管理ユニット（ＭＭＵ）および関連のアドレス変換機構によって実行される。好ましくは、命令アクセスおよびデータ・アクセスのために別々のＭＭＵが提供される。図６には、明瞭にするために、単一のＭＭＵ６６１が例示されており、命令ストア・ユニット（ＩＳＵ：Instruction Store Unit）６０１への接続のみを示している。しかし、当業者であれば、ＭＭＵ６１１が好ましくはロード／ストア・ユニット（ＬＳＵ：load/store unit）６９６および６９８ならびにメモリ・アクセスを管理するために必要な他のコンポーネントへの接続（図示せず）も含むことを理解するであろう。ＭＭＵ６１１は、データ変換索引バッファ（ＤＴＬＢ：Data Translation Lookaside Buffer）６１２および命令変換索引バッファ（ＩＴＬＢ：Instruction Translation Lookaside Buffer）６１３を含む。各ＴＬＢは最近参照されたページ・テーブル項目を含み、その項目はデータ（ＤＴＬＢ６１２）または命令（ＩＴＬＢ６１３）についてＥＡをＲＡに変換するためにアクセスされる。ＩＴＬＢ６１３からの最近参照されたＥＡ／ＲＡ変換は、ＥＯＰ有効／実アドレス・テーブル（ＥＲＡＴ：effective-to-real address table）６３２にキャッシュされる。

ＥＲＡＴ６３２によりＩＦＡＲ６３０に含まれるＥＡを変換し、Ｉキャッシュ・ディレクトリ６３４内の実アドレス（ＲＡ）をルックアップした後に、ＩＦＡＲ６３０内のＥＡに対応する命令のキャッシュ・ラインがＬ１ Ｉキャッシュ６１８に常駐しないことをヒット／ミス・ロジック６２２が判断した場合、ヒット／ミス・ロジック６２２は、Ｉキャッシュ要求バス６２４を介して要求アドレスとしてＬ２キャッシュ６１６にＲＡを提供する。このような要求アドレスは、最近のアクセス・パターンに基づいてＬ２キャッシュ６１６内の事前取り出しロジックによって生成することもできる。要求アドレスに応答して、Ｌ２キャッシュ６１６は複数命令のキャッシュ・ラインを出力し、その命令は、おそらく任意選択の事前デコード・ロジック６０２を通過した後、Ｉキャッシュ再ロード・バス６２６を介して事前取り出しバッファ（ＰＢ：prefetch buffer）６２８およびＬ１ Ｉキャッシュ６１８にロードされる。

ＩＦＡＲ６３０内のＥＡによって指定されたキャッシュ・ラインがＬ１キャッシュ６１８内に常駐すると、Ｌ１ Ｉキャッシュ６１８は、分岐予測ユニット（ＢＰＵ）６３６および命令取り出しバッファ（ＩＦＢ）６４０の両方にキャッシュ・ラインを出力する。ＢＰＵ６３６は、複数命令のキャッシュ・ラインを走査して分岐命令を捜し、条件付き分岐命令があれば、その結果を予測する。分岐予測後に、ＢＰＵ６３６は、上述の通り、ＩＦＡＲ６３０に投機的命令取り出しアドレスを供給し、条件付き分岐命令がその後、分岐実行ユニット６９２によって解決されたときに予測の正確さを決定できるように、分岐命令キュー６６４にその予測を渡す。

ＩＦＢ６４０は、複数命令のキャッシュ・ラインが命令変換ユニット（ＩＴＵ）６４２によって変換できるまで、Ｌ１ Ｉキャッシュ６１８から受信した複数命令のキャッシュ・ラインを一時的にバッファリングする。コア５５０の例示されている実施形態では、ＩＴＵ６４２は、ユーザ命令セット・アーキテクチャ（ＵＩＳＡ：user instruction set architecture）命令からの命令を、コア５５０の実行ユニットによって直接実行可能な、おそらく異なる数の内部ＩＳＡ（ＩＩＳＡ：internal ISA）命令に変換する。このような変換は、たとえば、読み取り専用メモリ（ＲＯＭ）テンプレートに保管されたマイクロコードを参照することにより、実行することができる。少なくともいくつかの実施形態では、ＵＩＳＡ／ＩＩＳＡ変換の結果、ＵＩＳＡ命令とは異なる数のＩＩＳＡ命令または対応するＵＩＳＡ命令とは異なる長さのＩＩＳＡ命令あるいはその両方が得られる。結果として得られるＩＩＳＡ命令は、次に、グローバル完了テーブル６３８によって命令グループに割り当てられ、そのメンバは相互に対して順不同にディスパッチし実行することが許可される。グローバル完了テーブル６３８は、それに関する実行を少なくとも１つの関連ＥＡによって完了する必要がある各命令グループを追跡し、その関連ＥＡは好ましくは命令グループ内の最も古い命令のＥＡである。

ＵＩＳＡ／ＩＩＳＡ命令変換後に、命令は、命令タイプに基づいて、おそらく順不同に、ラッチ６４４、６４６、６４８、および６５０のうちの１つにディスパッチされる。すなわち、分岐命令およびその他の条件レジスタ（ＣＲ：condition register）変更命令はラッチ６４４にディスパッチされ、固定小数点およびロード・ストア命令はラッチ６４６および６４８のいずれか一方にディスパッチされ、浮動小数点命令はラッチ６５０にディスパッチされる。実行結果を一時的に保管するためにリネーム・レジスタを必要とする各命令には、次に、ＣＲマッパ６５２、リンクおよびカウント（ＬＣ：link and count）レジスタ・マッパ６５４、例外レジスタ（ＸＥＲ：exceptionregister）マッパ６５６、汎用レジスタ（ＧＰＲ：general-purpose register）マッパ６５８、および浮動小数点レジスタ（ＦＰＲ：floating-point register）マッパ６６０のうちの適切なマッパによって１つまたは複数のリネーム・レジスタが割り当てられる。

ディスパッチされた命令は、次に、ＣＲ発行キュー（ＣＲＩＱ：CRissue queue）６６２、分岐発行キュー（ＢＩＱ：branch issue queue）６６４、固定小数点発行キュー（ＦＸＩＱ：fixed-point issue queue）６６６および６６８、ならびに浮動小数点発行キュー（ＦＰＩＱ：floating-point issue queue）６７０および６７２のうちの適切な発行キューに一時的に入れられる。データ依存および逆依存が観察される限り、実行のために発行キュー６６２、６６４、６６６、６６８、６７０、および６７２から、処理装置６０３の実行ユニットに対し適切な機会に命令を発行することができる。しかし、いずれかの命令を再発行する必要がある場合、命令の実行が完了し、結果データがある場合にそのデータが書き戻されるまで、命令は発行キュー６６２〜６７２に維持される。

例示されている通り、コア５５０の実行ユニットは、ＣＲ変更命令を実行するためのＣＲユニット（ＣＲＵ）６９０、分岐命令を実行するための分岐実行ユニット（ＢＥＵ）６９２）、固定小数点命令を実行するための２つの固定小数点ユニット（ＦＸＵ）６９４および６０５、ロードおよびストア命令を実行するための２つのロード／ストア・ユニット（ＬＳＵ）６９６および６９８、浮動小数点命令を実行するための２つの浮動小数点ユニット（ＦＰＵ）６０６および６０４を含む。実行ユニット６９０〜６０４のそれぞれは、好ましくは、いくつかのパイプライン・ステージを有する実行パイプラインとして実現される。

実行ユニット６９０〜６０４のうちの１つにおける実行中に、命令は、実行ユニットに結合されたレジスタ・ファイル内の１つまたは複数の構築レジスタまたはリネーム・レジスタあるいはその両方からのオペランドがある場合にそのオペランドを受信する。ＣＲ変更命令またはＣＲ依存命令を実行しているときに、ＣＲＵ６９０およびＢＥＵ６９２はＣＲレジスタ・ファイル６８０にアクセスし、そのレジスタ・ファイルは好ましい一実施形態では１つのＣＲと、それぞれが１つまたは複数のビットから形成されたいくつかの個別フィールドを含むいくつかのＣＲリネーム・レジスタとを含む。これらのフィールドの中には、ある値（典型的には命令の結果またはオペランド）がゼロより小さいか、ゼロより大きいか、またはゼロに等しいかどうかをそれぞれ示すＬＴ、ＧＴ、ＥＱフィールドがある。リンクおよびカウント・レジスタ（ＬＣＲ）ファイル６８２は、それぞれのカウント・レジスタ（ＣＴＲ）、リンク・レジスタ（ＬＲ）、およびリネーム・レジスタを含み、それによりＢＥＵ６９２は条件付き分岐を解決して経路アドレスを入手することもできる。同期している汎用レジスタ・ファイル（ＧＰＲ）６８４および６８６は、レジスタ・ファイルを複製し、ＦＸＵ６９４および６０５ならびにＬＳＵ６９６および６９８によってアクセスされ生成された固定小数点値および整数値を保管する。浮動小数点レジスタ・ファイル（ＦＰＲ）６８８は、ＧＰＲ６８４および６８６のように、同期レジスタの複製セットとして実現することもでき、ＦＰＵ６０６および６０４による浮動小数点命令の実行ならびにＬＳＵ６９６および６９８による浮動小数点ロード命令の実行の結果として得られる浮動小数点値を含む。

実行ユニットが命令の実行を終了した後、その実行ユニットはＧＣＴ６３８に通知し、そのＧＣＴはプログラムの順序で命令の完了をスケジュールする。ＣＲＵ６９０、ＦＸＵ６９４および６０５、またはＦＰＵ６０６および６０４のうちの１つによって実行された命令を完了するために、ＧＣＴ６３８は実行ユニットに信号を送り、その実行ユニットは、割り当てられたリネーム・レジスタ（複数も可）からの結果データがある場合にそのデータを適切なレジスタ・ファイル内の１つまたは複数の構築レジスタに書き戻す。次に命令は発行キューから除去され、その命令グループ内のすべての命令が完了すると、ＧＣＴ６３８から除去される。しかし、他のタイプの命令は異なる方法で完了される。

ＢＥＵ６９２が条件付き分岐命令を解決し、取るべき実行経路の経路アドレスを決定すると、その経路アドレスはＢＰＵ６３６によって予測された投機的経路アドレスと比較される。経路アドレスが一致する場合、それ以上の処理は不要である。しかし、計算された経路アドレスが予測された経路アドレスと一致しない場合、ＢＥＵ６９２は正しい経路アドレスをＩＦＡＲ６３０に供給する。いずれかの場合、次に分岐命令をＢＩＱ６６４から除去することができ、同じ命令グループ内の他のすべての命令が実行を完了すると、分岐命令をＧＣＴ６３８から除去することができる。

ロード命令の実行後、ロード命令を実行することによって計算された有効アドレスは、データＥＲＡＴ（例示せず）によって実アドレスに変換され、次に要求アドレスとしてＬ１ Ｄキャッシュ６２０に提供される。この時点で、ロード命令はＦＸＩＱ６６６または６６８から除去され、指示されたロードが実行されるまでロード・リオーダ・キュー（ＬＲＱ：load reorder queue）６０９に入れられる。要求アドレスがＬ１ Ｄキャッシュ６２０で見当たらない場合、要求アドレスはロード・ミス・キュー（ＬＭＱ：load miss queue）６０７に入れられ、それにより要求されたデータがＬ２キャッシュ６１６から取り出され、それに失敗すると、他のコア５５０またはシステム・メモリ（たとえば、図５に示されているＲＡＭ５２８）から取り出される。ＬＲＱ６０９は、排他的アクセス要求（たとえば、変更予定の読み取り（read-with-intent-to-modify））をスヌープし、未完了のロードに対して相互接続ファブリック（図示せず）上でフラッシュまたは強制終了し、ヒットが発生した場合、ロード命令を取り消して再発行する。ストア命令は、ストア命令の実行後にストア用の有効アドレスがそこにロードされるストア・キュー（ＳＴＱ：store queue）６１０を利用して同様に完了する。ＳＴＱ６１０からＬ１ Ｄキャッシュ６２０およびＬ２キャッシュ６１６のいずれか一方または両方にデータを保管することができる。

上記の通り、各ノード（たとえば、スレッド１０８ａ〜１０８ｄのそれぞれ）は、１つまたは複数のプロセッサ・コア（たとえば、図５に描写されているプロセッサ・コア（複数も可）５５０のうちの１つ）を含む。このようなプロセッサ・コアの模範的な一実施形態の追加の詳細は図７に提示されている。プロセッサ・コア５５０内には、有効／実アドレス・テーブル（ＥＲＡＴ：Effective-to-Real Address Table）６３２（上記の図６に示されている）が存在し、これは、ユーザ・アプリケーション（たとえば、図１に示されているユーザ・アプリケーション１１２）または作業単位メッセージ（たとえば、図１に示されているパケット１１０ａ〜１１０ｄ）にすることができる作業単位７０８から種々のソフトウェア・スレッド７０４ａ〜７０４ｄをディスパッチするために使用される。作業単位７０８がプロセッサ・コア５５０によって受信されると、レジスタ７１０ｄ、実行ユニット７１２ｄ、および出力バッファ７１４ｄから構成された特定のハードウェア・スレッド７１６は、ソフトウェア・スレッド７０４ｄ内の命令を実行することができる。上記の図６に関連して説明すると、模範的なハードウェア・スレッドは、ＦＰＲマッパ６６０、ＦＰＩＱ６７２、ＦＰＲ６８８、およびＦＰＵ６０４から構成することができる。もう１つの模範的なハードウェア・スレッドは、ＧＰＲマッパ６５８、ＦＸＩＱ６６８、ＦＸＵ６０５、およびＧＰＲ６８６から構成することができる。その他のものはＦＸＵ６９４、ＬＳＵ６９８、ＣＲＵ６９０、ＢＥＵ６９２などを含むものとして企図することができるので、これらは模範的なハードウェア・スレッドである。

もう一度、図７を参照すると、種々のハードウェア・スレッド７１６、７１８、７２０、および７２２は、作業単位７０８からの異なるソフトウェア・スレッドを独立してまたは半自律的にあるいはその両方で実行することができる。

次に、図８に関連して、本発明のコンテキスト内で圧縮直接スレッド間通信バッファ８０２およびオペランド・マルチプレクサ（ＭＵＸ）特殊目的レジスタ（ＳＰＲ）８０４を以下のように模範的に利用する場合について考慮する。グラフィックス・アプリケーション８０６はＮＯＣ８０８内で実行する予定であると想定する。グラフィックス・アプリケーション８０６は、ホスト・コンピュータ８１０からディスパッチされるものであり、ＣＤＩＣＢ８０２およびＭＵＸ ＳＰＲ８０４によって提供される直接スレッド間通信（ＤＩＴＣ）を使用してＮＯＣ８０８の高スレッド化性を利用できるリアルタイム３次元（３Ｄ）投影およびラスタ化グラフィックス・アプリケーションである。より具体的には、ＤＩＴＣにより、グラフィックス・アプリケーション８０６からのグラフィックス・ワークロードの種々の部分を実行するためにノード８１２ａ〜８１２ｄ（そのそれぞれは図４に描写されているノード４２２に類似している）またはスレッド（たとえば、図１に描写されているスレッド１０８ａ〜１０８ｄ）あるいはその両方を割り当てることができる。したがって、ノード８１２ａは、ソフトウェア・パイプラインの状態およびＯｐｅｎＧＬ ｇｌＶｅｒｔｅｘ３ｆ（）呼び出しなどの着信グラフィックス関数呼び出しを処理するホスト・インターフェース・スレッドにすることができる。次に、ノード８１２ａ（ハードウェア・ロジックと、任意選択で、ノード８１２ａに関連する操作の実行に合わせて調整された特定のソフトウェアを含むもの）は、ＮＯＣ作業パケット８１４ａの形のデータおよび制御情報でそのＤＩＴＣ送信箱バッファ（図示せず）を充填し始める。以下により詳細に記載するプロセスおよびハードウェアを使用し、このチップ・パケットは初めに未圧縮で未整列であるが、ＮＯＣ８０８内の次のノード／スレッドに伝送される前に圧縮され整列される。すなわち、図９に示されている未圧縮直接スレッド間通信バッファ（ＵＤＩＣＢ）９０２（図２に提示されているＵＤＩＣＢ２０６に類似している）について考慮する。描写されている通り、ＵＤＩＣＢ９０２は、グラフィックス・プログラムのための赤（Ｒ）、緑（Ｇ）、青（Ｂ）、およびアルファ合成（Ａ−イメージ透過性を制御するためのもの）データを処理するために使用されるデータを含む。しかし、上記の図２に記載されているものに類似したシナリオでは、ＵＤＩＣＢ９０２内のデータは未整列である（ａ〜ｃ、ｅ〜ｇなどの種々のワードの集合間に「穴（hole）」がある）。伝送トラフィックおよびバッファ内の無駄な空間を削減するために、ＵＤＩＣＢ９０２は直接スレッド間通信バッファ（ＤＩＣＢ）圧縮／圧縮解除ロジック９０４によって圧縮され、このロジックについては以下の図１０でより詳細に説明する。このＤＩＣＢ圧縮／圧縮解除ロジック９０４は、図８で前に紹介されている圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）８０２を生成する。同時に、対応するデータが生成され、オペランドＭＵＸ ＳＰＲ８０４に格納される。後述の通り、この対応するデータは、ＣＤＩＣＢ８０２の編成上の保全性を維持するために、ノード内のプロセッサによって使用される前にＣＤＩＣＢ８０２内に保管されたデータを再整列する（re-align）目的で、ならびにそのプロセッサによって使用された後で処理済みオペランドの整列をずらす目的で、ノード内のＭＵＸを制御するためにＭＵＸ ＳＰＲ８０４内に保管されたＭＵＸ制御データである。

ＮＯＣ内の各ノード内に異なるＭＵＸ ＳＰＲ８０４が保管される場合もあれば、ＮＯＣ内のすべてのノードによって単一のＭＵＸ ＳＰＲ８０４が利用される場合もある（図示の通り）ことに留意されたい。いずれのシナリオでも、調整ロジック（ハードウェアまたはソフトウェアあるいはその両方）を利用して、ＣＤＩＣＢ８０２内に保管されたオペランドの配向（すなわち、行のレイアウト）がＣＤＩＣＢ８０２内に保管された元のオペランドとＮＯＣ内のノードによって処理され出力された処理済みオペランドとの間で一貫性を保持することを保証することができる。

図８に戻ると、ホスト・インターフェース・スレッド・ノード８１２ａからの出力は作業パケット８１４ａ内にパッケージ化され、その作業パケット８１４ａはＮＯＣ８０８内のネットワーク（図示せず）を介してノード８１２ｂに送信され、そのノード８１２ｂは作業パケット８１４ａを受信し、頂点３次元変換（vertex 3D transform）、２次元への投影（projection to2D）、照明計算（lighting calculation）など、受信したパケット・データについて操作を実行する。次に、ノード（スレッド）８１２ｂは、ノード（スレッド）８１２ｃに伝送するために結果データおよび制御情報を作業パケット８１４ｂに格納する。ノード８１２ｃは、受信データについてラスタ化操作を実行し、ノード８１２ｄに伝送するために作業パケット８１４ｃに結果を出力する。ノード８１２ｄは、グラフィックス・アプリケーション８０６からのジョブについて最終操作を実行し、そのアプリケーションは表示すべきイメージのテクスチャ処理を含む。この最終操作は、グラフィックス・アプリケーション８０６によって提示されるジョブの実行を完了し、その結果、画面（たとえば、上記の図１に示されている出力装置１０６）上にディスプレイ・イメージを生成するための最終信号（たとえば、デジタル・イメージ表現）が得られる。

ＮＯＣ８０８内のノード８１２ａ〜８１２ｄのそれぞれが異なる専用ナノカーネル８１６ａ〜８１６ｄに関連付けることができることに留意されたい。ナノカーネルは、１）ノード８１２ａ〜８１２ｄ間の作業単位メッセージ（たとえば、パケット８１４ａ〜８１４ｄ）の伝送、および２）ＭＵＸ ＳＰＲ８０４からのオペランド制御データの使用によりＣＤＩＣＢ８０２内のオペランドへのアクセスの管理および制御のみが可能である１つの細かいオペレーティング・システム・ソフトウェア論理として定義される。

次に図１０を参照すると、ノード１０２２（たとえば、図８に示されているノード８１２ａ〜８１２ｄのうちの１つ）内にＤＩＣＢ圧縮／圧縮解除ロジック９０４の追加の詳細が示されている。図８のノード８１２ａ〜８１２ｄのそれぞれについて上述した通り、ノード１０２２はＣＤＩＣＢ８０２からのデータ・ワード（たとえば、ノード１０２２内のベクトル実行ユニット１００２などの実行ロジックに供給する予定のオペランド）にアクセスする。ＣＤＩＣＢ８０２は適切に整列された未圧縮バッファ（たとえば、図９に示されているＵＤＩＣＢ９０２）から整列がずれ／圧縮されているものと想定されることに留意されたい。このような整列ずれ／圧縮は、ハードウェアのみ（図示せず）または次に図１０で説明するソフトウェア制御プロセスのいずれかを使用して実行することができる。

初めに、ＣＤＩＣＢ８０２からのオペランドは、第１のセットのＭＵＸ１００４に入力される。第１のセットのＭＵＸ１００４は、第１のセットのＭＵＸ１００４に付加された制御ライン（図示せず）を使用して、ＣＤＩＣＢ８０２から受信したオペランドの再整列を制御する。これらの制御ラインは、ＭＵＸ ＳＰＲ８０４からの制御データを利用するＭＵＸコントローラ１００６の制御下にある。この制御データは、ＣＤＩＣＢ８０２が上記のようにＵＤＩＣＢ９０２から整列がずれ／圧縮されたときに作成されたものである。すなわち、ＭＵＸ ＳＰＲ８０４内のＭＵＸ制御データは、図９に示されている元のＵＤＩＣＢ９０２内にあるときに結果的にこのようなオペランドが再整列されるように、ＣＤＩＣＢ８０２からのオペランドの「アンパック（unpacking）」を可能にする。次に、オペランド（ブランク・ブロックを含む）のこの再整列フォーマットは、本明細書に記載されている例では各読み取りサイクルで４ワードのデータ行を読み取るベクトル実行ユニット１００２によって理解し処理することができるフォーマットになっている。

再整列された行のオペランドはバッファ１００８に保管され、次にレジスタ・ファイル・アレイ１０１０に保管される。レジスタ・ファイル・アレイ１０１０から再整列された行のオペランドがバッファ１０１２に保管され、そのバッファ１０１２から特定のオペランドが、同じくＭＵＸコントローラ１００６、ＭＵＸ ＳＰＲ８０４、または作業パケット１０１６（たとえば、図１に示されているパケット１１０ａ〜１１０ｄまたは図８に示されている作業パケット８１４ａ〜８１４ｄのうちの１つ）内の情報あるいはこれらの組み合わせの制御下にある第２のセットのＭＵＸ１０１４によって選択的に読み取られる。たとえば、それがオペランドａおよびｂのみを必要とすることを作業パケット１０１６が「把握している（know）」ものと想定する。この「知識（knowledge）」はＭＵＸコントローラ１００６に回され、そのコントローラ１００６は、ＭＵＸ ＳＰＲ８０４によって提供された整列情報により、オペランドａおよびｂのみがベクトル実行ユニット１００２のためのバッファ１０１８に達するように、第２のセットのＭＵＸ１０１４を制御することができる。次にベクトル実行ユニット１００２（図７に示されているものなどの複数の並列実行ユニットまたはハードウェア・スレッドを含むもの）は、オペランドａおよびｂを処理し、処理済みオペランドａ’およびｂ’をバッファ１０２０に出力する。次に、処理済みオペランドａ’およびｂ’は、第２のセットのＭＵＸ１０１４によって抽出されて、ＣＤＩＣＢ８０２内の適切な記憶セルに挿入されるまで、もう一度システムを通過する。処理済みオペランドａ’およびｂ’は、元の（前処理済み）オペランドａおよびｂと同じＣＤＩＣＢ８０２内のセルを占有することに留意されたい。

一実施形態では、第３のセットのＭＵＸ（図示せず）は、第１のセットのＭＵＸ１００４について示されているものと実質的に同様に整列され構成される。第１のセットおよび第２のセットのＭＵＸが提供される場合、第１のセットのＭＵＸはＣＤＩＣＢ８０２からの第１の行のデータの処理専用にすることができ、第３のセットのＭＵＸはＣＤＩＣＢ８０２からの第２の（次の）行のデータの処理専用になる。同様に、２つの単一セットのＭＵＸについて上述したように種々の行のオペランドを同時に処理できるように、追加のセットのＭＵＸを使用して、第２のセットのＭＵＸ１０１４を増強することができる。

本明細書で使用する「圧縮（compressed）」という用語は、上記で論じ例示されているように、バッファ内に空のセルがまったくないように、バッファまたはパケットに保管されたデータ・ワードを記述するものであることに留意されたい。この「圧縮」という用語は、本明細書では、エンコード・アルゴリズムを使用して情報がエンコードされ、その結果、元の未圧縮データを表現するためのビット数が少なくなるデータ圧縮を記述または定義するために使用されるわけではない。

次に図１１に関連して説明すると、圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）からの整列がずれたオペランドを検索し再整列するために行われる模範的な諸ステップの高レベル流れ図が提示されている。開始ブロック１１０２の後、未圧縮直接スレッド間通信バッファ（ＵＤＩＣＢ）で検出されるオペランドは、圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）内で圧縮され（整列がずれ）、このように整列がずれた配向で保管される。ブロック１１０４に記載されているように、この圧縮／整列ずれの時点で、マルチプレクサ（ＭＵＸ）制御データはＭＵＸ特殊目的レジスタ（ＳＰＲ）に保管される。このＭＵＸ制御データは、ネットワーク・オン・ア・チップ（ＮＯＣ）内のノード内の実行ユニットによって使用するためにオペランドを再整列するための後続ステップで使用されることになる。

ブロック１１０６に記載されているように、上記の図１０に記載されているプロセスを使用して、ＭＵＸ ＳＰＲからのＭＵＸ制御データを使用するＮＯＣ内のノードによってＣＤＩＣＢからオペランドが検索される。次に、ＭＵＸ ＳＰＲからの整列データを使用して、ＣＤＩＣＢからのオペランドをＵＤＩＣＢで検出されたものと同じ整列に再整列する（ブロック１１０８）。ベクトル実行ユニット内の適切な実行ユニットに適切なオペランドを供給するために、この再整列編成は、特定の順序／配向でオペランドを読み取る必要がある可能性のあるノード内のベクトル実行ユニットによって要求される。

ベクトル実行ユニット内の実行ユニットが選択されたオペランドを処理した後（ブロック１１１０）、ＭＵＸ ＳＰＲはＭＵＸコントローラに制御情報を提供して、処理済みオペランドを再度整列をずらし、再圧縮し（ブロック１１１２）、それをＣＤＩＣＢに伝送し、そこに保管する（ブロック１１１４）。ＣＤＩＣＢからの他のオペランドはまったく不要であると想定して、プロセスは終了ブロック１１１６で終了する。

本発明の少なくともいくつかの態様は代わって、プログラムを含むコンピュータ可読媒体で実現できることを理解されたい。本発明の諸機能を定義するプログラムは、書き込み不能記憶媒体（たとえば、ＣＤ−ＲＯＭ）、書き込み可能記憶媒体（たとえば、ハード・ディスク・ドライブ、読み書きＣＤ−ＲＯＭ、光学媒体）を無制限に含む、様々な有形信号伝送媒体、ならびに、イーサネット、インターネット、無線ネットワーク、同様のネットワーク・システムなどのコンピュータ・ネットワークおよび電話網などの非有形通信媒体を介して、データ記憶システムまたはコンピュータ・システムに配布することができる。したがって、本発明における方法機能を指示するコンピュータ可読命令を伝達またはエンコードするときに、このような信号伝送媒体が本発明の代替諸実施形態を表すことを理解されたい。さらに、本明細書に記載されているハードウェア、ソフトウェア、またはソフトウェアとハードウェアの組み合わせあるいはそれらと同等の形の手段を有するシステムにより本発明を実現できることは言うまでもない。

８０２ 圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）
８０４ オペランド・マルチプレクサ（ＭＵＸ）特殊目的レジスタ（ＳＰＲ）
８０６ グラフィックス・アプリケーション
８０８ ネットワーク・オン・ア・チップ（ＮＯＣ）
８１０ ホスト・コンピュータ
８１２ａ ノード
８１２ｂ ノード
８１２ｃ ノード
８１２ｄ ノード
８１４ａ 作業パケット
８１４ｂ 作業パケット
８１４ｃ 作業パケット
８１６ａ ナノカーネル（ＮＫ）
８１６ｂ ナノカーネル（ＮＫ）
８１６ｃ ナノカーネル（ＮＫ）
８１６ｄ ナノカーネル（ＮＫ）

Claims (16)

1. 第１の処理ノードと
   前記第１の処理ノード内の少なくとも１つの実行ユニットと、
   前記第１の処理ノードに結合された圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）であって、未圧縮直接スレッド間通信バッファ（ＵＤＩＣＢ）に保管される少なくとも２つのオペランド間に少なくとも１つの空のバッファ・セルを含む前記ＵＤＩＣＢからのオペランドが格納され、前記ＵＤＩＣＢおよび前記ＣＤＩＣＢが複数の異なるオペランド集合を含むＣＤＩＣＢと、
   前記ＣＤＩＣＢおよび前記第１の処理ノードに結合されたマルチプレクサ（ＭＵＸ）特殊目的レジスタ（ＳＰＲ）であって、ＭＵＸ制御データを保管するＭＵＸ ＳＰＲと、
   前記ＭＵＸ ＳＰＲおよび前記第１の処理ノード内の第１のセットのＭＵＸに結合されたＭＵＸコントローラであって、前記ＭＵＸ ＳＰＲからのＭＵＸ制御データおよび前記第１のセットのＭＵＸを利用して、前記第１の処理ノードによって前記ＣＤＩＣＢから検索された元のオペランドを再整列し、再整列された元のオペランドが前記実行ユニットにオペランドを供給するために実行ユニット・アーキテクチャによって要求される編成フォーマットにデータ行によって編成されるＭＵＸコントローラと、
   を含む、ネットワーク・オン・ア・チップ（ＮＯＣ）。
2. 前記少なくとも１つの実行ユニットが再整列されたオペランドを処理して処理済みオペランドを生成し、前記ＮＯＣが、
   前記ＭＵＸコントローラに結合された第２のセットのＭＵＸであって、前記ＣＤＩＣＢに伝送し、そこに保管するために前記処理済みオペランドを再整列し、再圧縮する第２のセットのＭＵＸ
   をさらに含む、請求項１記載のＮＯＣ。
3. 前記ＣＤＩＣＢが、元のオペランドおよび対応する処理済みオペランドについて同じ編成上の整列を維持する、請求項１記載のＮＯＣ。
4. 前記ＮＯＣ内の各処理ノードが異なる専用ナノカーネルに関連し、各ナノカーネルが前記ＮＯＣ内の処理ノードへの作業単位メッセージおよびＣＤＩＣＢＰの伝送ならびに前記ＮＯＣ内のノード間の作業単位メッセージおよびＣＤＩＣＢＰの伝送のみが可能である１つの細かいソフトウェア論理である、請求項１記載のＮＯＣ。
5. 前記実行ユニットがベクトル・プロセッサである、請求項１記載のＮＯＣ。
6. 前記ＮＯＣに結合されたホスト・コンピュータから、前記ＮＯＣ内の処理ノードにユーザ・アプリケーションのための命令が委任される、請求項１記載のＮＯＣ。
7. 前記ＵＤＩＣＢがリアルタイム３次元投影ソフトウェア・アプリケーションによって使用されるデータを含み、前記ＮＯＣ内の第２のノードが、前記リアルタイム３次元投影ソフトウェア・アプリケーションによって作成されたイメージに関する３次元変換、投影、および照明計算の実行専用のものである、請求項６記載のＮＯＣ。
8. 前記リアルタイム３次元投影ソフトウェア・アプリケーションによって作成されたイメージのラスタ化専用の第３のノード
   をさらに含む、請求項７記載のＮＯＣ。
9. 前記リアルタイム３次元投影ソフトウェア・アプリケーションによって作成されたイメージのテクスチャ処理専用の第４のノード
   をさらに含む、請求項８記載のＮＯＣ。
10. 第３のセットのＭＵＸであって、前記第１のセットのＭＵＸが前記ＣＤＩＣＢからの第１の行のオペランドを処理し、前記第３のセットのＭＵＸが前記ＣＤＩＣＢからの次の行のオペランドを処理する第３のセットのＭＵＸ
    をさらに含む、請求項１記載のＮＯＣ。
11. ネットワーク・オン・ア・チップ（ＮＯＣ）における圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）からの任意のオペランド選択を制御するコンピュータによって実行される方法であって、前記方法が、
    未圧縮直接スレッド間通信バッファ（ＵＤＩＣＢ）内のオペランドの整列を圧縮直接スレッド間通信バッファ（ＣＤＩＣＢ）内のオペランドの整列ずれに変換するステップであって、前記ＵＤＩＣＢが前記ＵＤＩＣＢに保管される少なくとも２つのオペランド間に少なくとも１つの空のバッファ・セルを含み、前記ＣＤＩＣＢが前記ＣＤＩＣＢに保管される任意の２つのオペランド間に空のバッファ・セルをまったく含まないステップと、
    前記ＮＯＣ内のＭＵＸ特殊目的レジスタ（ＳＰＲ）にマルチプレクサ（ＭＵＸ）制御データを保管するステップであって、前記ＵＤＩＣＢ内のオペランドの編成の前記変換中に前記ＭＵＸ制御データが生成されるステップと、
    前記ＮＯＣ内の処理ノードで前記ＣＤＩＣＢからオペランドを検索するステップであって、前記ＭＵＸ ＳＰＲからの前記ＭＵＸ制御データを利用して前記処理ノード内の第１のセットのＭＵＸを制御することにより、オペランドが選択的に検索され、前記第１のセットのＭＵＸが前記ＣＤＩＣＢから特定のオペランドを選択的に読み取るステップと、
    を含む、コンピュータによって実行される方法。
12. 前記ＭＵＸ制御データを利用して、前記処理ノード内の実行ユニットによって要求された整列フォーマットに前記ＣＤＩＣＢからのオペランドを再整列するステップと、
    前記処理ノードで再整列されたオペランドを処理し、処理済みオペランドを作成して出力するステップと、
    をさらに含む、請求項１１記載のコンピュータによって実行される方法。
13. 前記ＭＵＸ制御データを利用して、前記出力された処理済みオペランドを圧縮された処理済みオペランドに再度整列をずらし再圧縮するステップ
    をさらに含む、請求項１２記載のコンピュータによって実行される方法。
14. 前記圧縮された処理済みオペランドを前記ＣＤＩＣＢに伝送するステップと、
    前記圧縮された処理済みオペランドを前記元のオペランドと同じ整列ずれで保管するステップと、
    をさらに含む、請求項１３記載のコンピュータによって実行される方法。
15. オペランドを検索する前記ステップがＭＵＸコントローラの制御下にあり、前記ＭＵＸコントローラが１）前記ＭＵＸ制御データおよび２）前記処理ノードに伝送される作業パケットからの制御データの使用により、前記ＣＤＩＣＢからオペランドを検索する、請求項１１記載のコンピュータによって実行される方法。
16. 前記ＮＯＣ内の各ノードが異なる専用ナノカーネルに関連し、各ナノカーネルが、１）前記ＮＯＣ内のノード間の作業単位メッセージの伝送、および２）前記ＭＵＸ ＳＰＲからの前記ＭＵＸ制御データの使用により前記ＣＤＩＣＢ内のオペランドへのアクセスの管理および制御のみが可能である１つの細かいオペレーティング・システム・ソフトウェア論理である、請求項１１記載のコンピュータによって実行される方法。

Images